一个稳定的产品更新节奏对产品的成长和用户业务的稳定发展有很大的帮助，那么如何把握这个节奏呢？文章为你分析。
从鹅厂到ThoughtWorks两年，从最初画线路图到现在能带领团队一起交付产品，对产品节奏的体验与日俱增。在“骚窝”中学到的敏捷开发，也让我明白了如何从技术执行层面支持产品的有序发布。做产品就是在用户需求的战场上攻城略地，节奏感就是每一次冲锋中的默契。
为什么产品要有节奏的增长
在开始讨论之前，我们可以先把“产品的节奏”定义为“产品更新的时间间隔和每次更新的内容”，让大家对频率有一个统一的概念。一个成长中的产品需要根据业务需求和用户需求不断更新。形成稳定的产品更新节奏，对产品成长、对用户、对团队都大有裨益。对于用户来说，以稳定的节奏更新产品可以:
定期向用户交付团队新实现的产品价值。
让用户感知产品的持续成长，容忍暂时的不足，期待新版本。
重新激活一些已经丢失的僵尸用户。
对于团队来说，稳定的节奏感的好处也很多:
保持稳定更新的责任可以督促团队尽快展现新功能，避免闭门造车太久而误入歧途。
产品经理可以不断推出一些新功能，供用户实验，验证自己的猜测。
团队可以不断收到用户的反馈，好的反馈可以鼓舞士气，差的反馈可以激发调整的动力。
团队内部可以有默契的配合，产品经理、设计师、开发人员、测试人员都很清楚什么时候该做什么。
节奏感应该怎么控制
现在“产品的节奏”已经定义为“产品更新的时间间隔和每次更新的内容”，控制节奏其实就是这两点。确定产品更新的时间间隔相对容易。对于移动产品，由于每次更新都需要iOS版本经过Google审核，用户每次更新都需要重新下载，所以3~6周发布一个外部版本是合适的(紧急修复严重bug不算)。如果产品处于快速增长期，这个时间可以进一步缩短。比如《打车大战》里的滴滴和快的，新功能发布晚了就是个死。
更重要的是，每次更新什么内容。如果设定4周周期，就意味着一年12个新机会。产品经理的职责就是想办法带领一群兄弟打好这12张牌。如果每次更新都跟adobereader一样，都是几个bug修复让用户提不起兴趣，畏首畏尾，那还不如不做这个产品。如何规划好每个版本，体现了一个优秀的产品经理运筹帷幄，决胜千里之外的掌控力。
在规划每个新版本的内容时，有两种选择:开疆拓土和持续优化。开疆拓土，就是产品要彻底开辟一个全新的疆域，覆盖一个全新维度的用户需求场景，要有野心，要酣畅淋漓。一块土地刚稳定下来，土地还是一片荒芜，后续需要做大量的持续改进工作，设置相关辅助功能，优化产品体验，在这片荒芜的土地上建立生态系统。只要这两个新版本处理得当，相互补充，就会有一个产品成长的框架。
开疆拓土是最能体现一个产品经理创造力的地方。往往意味着从0到1(零到一个豆瓣)打造一个新的空有价值、有市场、为产品带来广阔增长机会的房间。脸书完成关系链，然后搞社交游戏；GoPro最早做运动相机，后来转型做体育直播的传媒公司；滴滴/快的打车然后专车；微信先得到了熟人传播，然后用它来打陌生人和朋友，接着是朋友圈分享，然后是搞公众账号、支付、游戏分发。
这些都是从零开始的积极进步和创造价值的例子。同时，开疆拓土也意味着走很少人走的路，没有经验可借鉴，处处冒坑。不要抱着“憋一个大招，完美打磨然后吓死他们”的心态去做开创性的新功能。一定要按照精益创业的思路，用尽可能低的成本在短时间内发布基本可用的版本，然后看后续的反馈来做调整。看看微信的对讲机，视频聊天，小视频。不都是不温不火的吗？
持续改进就是从0到1后从1到n的过程。这部分比较简单，因为只要从0到1的前一步是对的，后一步就可以由用户根据自己的反馈来推送。用户缺乏足够深入的思考，无法认为更快的马可以被福特汽车取代。但是坐福特车之后，他们还有能力吐槽减震，太傻太费油。在改进的版本中，这类事情主要是这样做的:
优化粗糙界面设计的体会。
可用性测试、用户反馈、转化率漏斗跟踪等。可以反过来做。比如余额宝普及后，余额宝首页优化了日收益。
添加与核心功能互补的功能，比如在微信中更快更方便的通过各种渠道添加好友，在滴滴中添加各种打车优惠券。
增加琐碎的小功能，让核心功能更有用，比如微信里聊天可以置顶，聊天记录可以搜索，不中断。
其实很多中国的产品经理都是以“袖手旁观神的人”的名义，就是每天都在做一些持续改进的事情，修修补补，发完文再发照片、视频、网站、投票、文档。
控制产品节奏所需的支持
项目管理
按照传统的瀑布法做一个APP，需要一个星期规划功能，一个星期设计界面，一个星期实现功能，最后一个星期QA测试+修复BUG。理想情况下，它应该是至少四周的版本。但实际情况更有可能是产品在开发中途需要更改。QA检测出一堆问题，结果越改越多。最后一公里，大家都磕磕绊绊，然后所谓的有节奏的最后期限，发出一堆bug的包裹，或者干脆拖延。这注定是不可能的。
如果项目以敏捷的方式推进，情况会完全不同。首先，你可以每1周或2周定制一个Sprint，把需求分成粒度合适的故事，然后在每个Sprint中设置合适的工作量。团队中的所有角色都能高效协作，并行驱动，这样你就能在冲刺的最后得到一个新的发布。这样可以保证3~6周的对外发布。即使每1周发布一次MIUI，也完全没问题。
技术支持
要稳定地控制产品中的bug风险，实际上需要大量的技术支持，否则很可能代码中总是会有无穷无尽的bug，代码会随着产品的成长而变得越来越复杂，很难拿出一个稳定的、可发布的版本。在XP的敏捷实践中，其实有很多方法可以保证代码的稳定性。
TDD测试驱动开发
TDD会要求开发人员在编写代码之前仔细分析需求，思考要实现的这部分功能对应的测试场景，然后在此基础上编写单元测试，再编写实现。这样做的好处是，有了这些单元测试的保护，代码总是健壮的。即使将来代码变得复杂，或者代码需要重构修改，只要单元测试失败，就不要签入代码，也不会引入bug。
CI持续集成
在每个开发的单元测试都可以贯穿的基础上，我们可以使用CI来监控整个代码。只要Dev挂了CI，技术负责人就可以打他屁股。由于CI是完全自动进行实时运行测试的，只要任何人的签到新代码有问题，都可以及时发现，避免bug的引入和积压，让我们随时有可用的版本。在每一次冲刺的最后给出一个稳定可用的版本，这可不是一件小事。
有节奏地策划产品并批评方遒并不容易。嗯嗯~
作者:朱晨，ThoughtWorks深圳办公室经理，物联网团队负责人，曾在项目中担任UX设计师、业务分析师、项目经理，对企业互联网转型有深入研究。个人博客:http://www.jianshu.com/u/pvxie7
本文由@ThoughtWorks(微信微信官方账号:“管家行者”)原创发布，人人都是产品经理。未经许可，禁止复制。
题目来自PEPEPELS，基于CC0协议。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）