交付|创造价值，持续交付：B端产品经理的方法论(13) 交付|互联网产品|持续|产品经

文章插图
2）活动拆分和时间表规划
在传统的瀑布软件开发方法中，工作任务的分解时根据活动阶段来划分的。
如下图所示，产品的端到端开发被切割成不同阶段，只有由上一个阶段的全部完成才会开始下一个阶段，这使得项目产品直到最后联调测试阶段才知道开发的效果；这样造成业务无法及时验证产品有效性，而且这样一次性所有产品点都做，同时开发，没有主次之分，通常的开发时间都比较冗长，无法面对业务快速变化；业务的重点价值实现的落地被其他低优先级的开发事项拖延。

文章插图
而从业务视角出发，将一个项目的所有业务需求划分为多个小的业务功能模块，每个功能模块以业务用户的视角来描述它形成用户故事，方便介绍和了解背后的业务价值。
需求的拆分是解析一个产品的构成的范围和内容实质，这一过程中产品经理可以使用MEMC、WBS等方法工具来辅助进行。

文章插图
用树形图的方式，把每个功能模块模拟成树枝，然后把每个用户故事挂在相应的树枝上。
那么，每次交付的内容，是以业务价值为中心的；通过选择在不同树枝上的，高价值和优先级的故事卡片，组成当下迭代里最有业务价值的产品交付；之后再重复这个过程。
这种方式让业务人员能够及时得到可以开展业务的产品，获得市场反馈；同时，给与产品开发团队实时的反馈，以便于评估开发效果、调整和优化产品、响应市场变化。

文章插图
支撑这一操作的基本理念是精益思维和敏捷开发，每次上线的产品点总是某一功能树枝上优先级高的故事卡；因此，很多时候已经上线的功能模块的并没有包含全部功能点，这也赋予了产品各个功能模块及其特性以时间的属性。
小批量，持续的交付，尽早的获得收益，加速价值流动——这样的方式，也带来了交付的灵活性；一旦外界和业务发生变化，团队可以快速处理手中的任务，转向其他事务，同时还可以保证系统的完整性。
需要强调的是——虽然这种开发方式可以快速带来收益反馈，但是也有成本代价；除了每次迭代后要将开发完成的产品部署到生产环境，还要回归测试前期交付的所有软件功能可以正确进行；验证成本投入会逐步增加。
从微观来看，每次迭代，产品经理最为需要注意的是把握每次迭代的产品价值，以此为中心来规划交付内容；而从宏观来看，2B类型的产品往往比较复杂，且工作量大，需要多个迭代的持续交付来实现的。
有时还会出现某个最小功能集合依然无法在一个迭代内完成的情况，另外，多数产品功能需要跨团队的配合来实践；这样总情况下，产品经理就需要搭建整体产品项目时间计划表。预先把所有的功能或故事点，按迭代来排期做初步规划，通过这个项目时间计划表来统筹各个参与方的节奏和工作内容。
项目时间表的搭建对产品经理有着非常重要的意义。
第一，在拆分具体项目活动的过程就是同相关参与人员共同交叉确定产品范围理解，查漏补缺和预估工作量的过程；在此过程中，参与人员可以同步对于开发事项的理解，充分讨论需求的边界上下文，交流初步技术方案的预想，对开发目标、质量标准和验收条件达成一致，建立共识；这里也需要用到上一章节讲述的产品经理的技术开发能力。
第二，确定开发活动的优先级和事件之间的依存关系，确保每个事项有对应的负责人和完成时间节点；一个事项一定要有对应的负责人，如果需要拆分成多个负责子事项给不同人员，也需要指定出一个总体协调负责人员，避免“人人负责”变成没有人负责。
第三，项目计划表的搭建是个反复优化和调整的过程；首先，项目总体时间必须在预先确定的时间范围内，如果产品总体交付时间超过预期，那么需要针对整体交付产品的范围和关键路径，特别时分组合作的情况下，进行分析和优化；其次，初次整体产品项目排期的完成，只是反应了当时的产品功能点所蕴含的价值优先程度；基于整体的项目规划框，动态的秉承敏捷的理念，可以周期性的根据业务价值调整交付物；最后，MVP和精益思维可以用于指导项目计划表的搭建和优化
第四，项目时间表还承担了沟通和协调开发进度的作用，产品经理在负责项目管理的时候，可以使用时间表来监控和控制开发进度；因为所有的需求点都是相关人员共同参与讨论过的，所有产品经理针对偏离正常进度的事项更加有信心来纠正；同时也给了开发人员明确的时间框架和开发事项，做到责任到人，奖惩清晰。