产品迭代周期的规划和节奏

产品的应用类型（APP、WEB）、技术实现方式、部署方式、产品应用的规划（应用数量）、工程依赖、组织结构的设计等因素，都会影响到产品迭代周期的规划。一个组织中的每个产品甚至同一产品的不同发展阶段，也会存在多种不同的规划方式和节奏，要根据产品和团队的特点，应用适用于自己的规划方式和节奏。

90%以上的互联网产品组织都符合多产品组织，通常，他们至少有一个前台产品和一个后台产品。

偏向于自上而下推进工作的团队，就需要有一个稳定且相对较长的迭代周期，有利于组织协调相关资源，进行业务的推进和自上而下的控制，统筹性较好；

偏向于自下而上推进工作的团队，往往不会固定迭代周期，使用相对灵活的发布策略。（前后台产品迭代周期通常1-2周，中台产品3-4周），敏捷性较好；

小瀑布模式

固定窗口期发布

根据上文中提到的因素，为产品设定一个固定的发布窗口期，通常在3-4周（可浮动）或一个固定日期（Deadline），规划一批需求，作为一个发布版本。迭代周期决定了需求的数量，而不是需求数量决定了迭代周期。

固定版本发布

产品按需求关联性和业务要求，参考相对固定的周期，通常在3-4周，规划一批需求，作为一个发布版本。需求数量决定了迭代周期，而不是迭代周期决定了需求数量。

特点

  • 容易形成批量交付、批量接收，造成的上下游团队间等待时间长的问题；

  • 需求响应速率低（迭代周期较长），通常一年只有12-18次机会改变产品；

  • 交付周期长，周期内发生的变化也会多，容易因必要的需求变化或评估的准确性等因素，影响上线时间，或者需求妥协；

  • 团队为了确保计划的有效性，需要尽可能屏蔽变化，团队较少受变化因素影响，有利于找到适合团队的工作节奏；但若屏蔽变化，则变化的响应效率低，若放开变化，则计划变更的频率高，打乱内部节奏，计划的有效性和价值低；

  • 产品规划和发展节奏容易自上而下的控制，但对变化的敏捷性较差；

  • 资源利用不均衡，团队人少或能力不足，需求的交付就跟不上，相反，则人员闲置。多产品的团队需要配合迭代计划进行人员调配，团队间资源协调容易产生死锁；

  • 迭代容易前松后紧，导致迭代后期工作量激增，质量问题多，很多问题没有时间发现，被发布到生产；

迭代节奏

迭代节奏-小瀑布模式

图中橘色部分显示了一个完整的需求流转过程，一个需求实际处理周期是7周（从需求选择到需求交付）

持续交付模式

持续交付模式与上文提到的批量交付模式，对于产品规划阶段来说，是近似的。主要区别在于，批量交付的模式，单次迭代的需求数量多，交付周期长，持续交付的模式，重规划而轻计划，交付周期灵活。

通常，互联网产品中的前后台产品，更倾向于对需求进行持续的分析、开发、上线（需求粒度控制在一周完成，功能由小到大、由简到繁的发展，某几个需求完成后即上线）。持续交付模式不会通过固定的周期或固定的版本来归集需求，进行迭代，而是促进需求快速完成，然后在合适的时机，选择可以交付的功能集，发布上线。

持续不等于没有大的规划，来一个需求做一个需求，而是确定一个较大的产品发展目标/方向和范围，设立若干里程碑，在基于较大范围的需求选择后，持续的进行若干次小迭代，从而完成产品的一个里程碑，进而完成产品发展目标。

以产品版本号举例，版本号通常由“大版本号”+“中间版本号”+“小版本号”组成，例如：v2.7.3，对应到产品规划中来说，大版本号就是产品年度发展方向的达成，中间版本号就是产品里程碑的达成，小版本号就是里程碑达成经历的每个迭代。

灵活的发布策略（持续交付）与固定的发布策略（小瀑布、批量交付）相比，会缩小需求响应周期（已完成的需求等待未完成的需求时间短），提升用户需求或业务机会的响应速度和灵活性，减少小瀑布式的批量规划、批量交付而导致上下游团队等待时间长的情况，减少需求并行，让团队可以聚焦于快速交付当前的需求，提升需求响应的效率。

当然，具备一定的条件，才可以更好的实践持续交付模式，需要形成端到端的价值流转模式、DevOps支撑、合适的部署机制、技术成熟度、代码管理方式等等。另外，组织结构、工作模式的设计，应更多的向敏捷机制靠拢，对变化能做到敏捷的响应，关注点以价值流动的效率为主，资源效率为辅。

特点

  • 需求响应速度快，需求从选择到上线的时间短；

  • 不易产生效率竖井，上下游团队之间衔接平稳，等待时间短；

  • 灵活性高，适应随时而来的变化；

  • 可做到快速试错，尽快发布给用户，接收线上反馈，验证效果，快速调整产品；

  • 可以即时发现和解决缺陷，不会挤压到迭代后期大面积出现，系统始终接近于可发布状态；

  • 需要具备持续交付的能力（DevOps、工作模式）；

  • 产品团队需要有较高的需求整理和产品演进式规划能力；

迭代节奏

迭代节奏-持续交付模式

图中的每一段，可能是下列其中之一：

  • 一个需求；
  • 关联性较强的一组需求；
  • 一个大需求，经过拆分后的一个或一组小需求；
  • 一个线上缺陷；

本系列文章是一个不依赖实际产品、团队、技术架构的，进行了泛化、抽象化的一个指南性质的文章。将分几部分来阐述“互联网产品的研发模式和提升研发效能”这个主题的关键点及可行实践，意在抛砖引玉。在实际落地时，可参考此指南，根据组织、产品及团队的特性，进行组合或优化使用。

1.引言
2.几个重要的观念
3.形而上
4.设计组织架构
5.1.工作模式设计——需求处理
5.2.工作模式设计——迭代规划
5.3.工作模式设计——其它事务
6.建立可视化协作机制
7.进行评估和激励
8.附录