其实很多中国的产品经理冠着“站在上帝身边的人”之名，也就是每天在做些个持续改进的事情，修修补补，做完发文字再做发照片、发视频、发网址、发投票、发文件。

　　控制产品节奏感所需要的支持

　　项目管理

　　依照传统的瀑布流方式来做APP的话，先花一周来规划功能，再花一周来设计界面，然后花上一周来实现功能，最后一周QA测试+改BUG，最理想的情况下也是至少4周一个版本。但实际情况更可能是开发做了一半时产品要改个需求，QA测出一堆问题给开发改结果越改越多，最后一公里大家跑的磕磕绊绊然后受迫于所谓节奏感的deadline把带着一堆BUG的包发掉，或者就干脆延期。这样势必是不行的。

　　如果依照敏捷方式来推动项目，情况会完全不同。首先可以将每1周或每2周定做一个Sprint，将需求切分成合适颗粒度的story，然后在每个Sprint内设定好合适的工作量，团队里各个角色高效协作、并行驱动，就可以确保在Sprint结束时得到可发布的新版本。这样的话，3~6周的对外版本发布是可以保障的。即便是MIUI这样的每1周做一次发布，也完全没问题。

　　技术支持

　　想要稳定地控制产品中的BUG风险，其实是需要相当多的技术力量做保障的，否则很可能代码里总是会有无穷无尽的BUG，代码随着产品成长还会越来越复杂，想拿出一个稳定可发布的版本都难。在XP的敏捷实践里其实是有很多方法来保障代码稳定的。

　　TDD 测试驱动开发

　　TDD会要求开发在写代码之前先仔细分析好需求，想好要实现的这部分功能对应的测试场景有哪些，然后基于此来先写好单元测试，再来写实现。这样做的好处是有了这些单元测试的保护，代码始终是健壮的。即便以后代码变得复杂，或者要重构修改代码，只要单元测试跑不过时不要check-in代码，就不会引入BUG。

　　CI 持续集成

　　在每个开发的单元测试都能跑过的基础上，我们可以用CI来监控整体的代码。只要有Dev搞挂了CI，技术lead就可以打他屁股了。由于CI是完全自动化地在实时run测试，所以只要任何人check-in的新代码有问题，就可以及时查出来，这样就可以避免Bug引入并积压，让我们随时都有可用的版本。那每个Sprint结束时给一个稳定可用的版本还不是小意思。

　　想要有节奏地规划产品，挥斥方遒，其实挺不容易的呢，嗯哼~

　　作者：朱晨，ThoughtWorks深圳办公室经理，物联网团队负责人，曾经在项目中担任过UX设计师，业务分析师和项目经理角色，对企业的互联网转型有深入研究。个人博客：

　　本文由 @ThoughtWorks (微信公众号：“思特沃克”) 原创发布于人人都是产品经理。未经许可，禁止转载。

　　题图来自PEXELS，基于CC0协议