编辑导语：在项目实施过程中，产品经理会成为项目负责人并承担其项目经理的身份及责任，那产品经理是如何管理版本迭代的？本文作者从项目管理角度，整理项目实施过程中的迭代管理，我们一起来看一下。
一、制定迭代计划
1. 为什么要制定迭代计划
首先以图1为例，简单说明迭代与开发工作的关系。
图中迭代B是从开发、测试到正式发版的一个工作周期，版本是开发过程中的实际产出，迭代任务根据实际情况安排计划后；通过多次开发与测试，最后以一个稳定版本交付至客户，就完成了一次迭代。
图1 迭代与版本的关系
如果系统以迭代的方式不断完善，有以下几个优势：
1）减少错误成本
由于客户的需求不断变化，部分需求也无法在规划的初期就完全确定，通过迭代的方式不断地让客户试用反馈，可以更准确地把握客户的需求，最终以更少的成本达成客户期望。
2）提高进度把控
当产品经理规划或搭建一个系统时，由于任务多时间跨度长，前期工作会不断影响后续任务的进度；因此通过迭代计划把项目分解成若干阶段，降低对项目把控的难度。
3）限定范围
由于资源是有限的，要达到资源利用的最大收益，需要把资源用到关键节点，解决当前最重要的问题；而且限定范围更利于建立短期目标，团队成员在落实工作时将更有方向，可以感知项目当前的进度并提前做好规划。
4）管理客户期望
当系统投入项目现场使用之后，客户会迫切地期望完善系统功能；但由于团队资源有限，需要制定工作计划，确保团队工作符合上级期望。
5）维持系统稳定
系统上线运行后，快速的更新迭代是客户关注的，但更重要的是客户能在稳定的系统上处理业务，一味的追求系统更新，增加了团队工作量的同时还会增加系统出问题的风险；因此以迭代形式统一更新，既能减少了团队的工作量又能提高系统质量。
2. 如何制定迭代计划
1）确定工作范围
制定迭代首先需要根据项目现状、需求池、待办事项、客户反馈等信息，评估任务优先级并输出具体的工作范围。
2）预估工作时间
确定范围后，初步预估工作量并与主要负责人（领导或客户等）确认计划是否符合预期。
若不符合上级预期，根据优先级进一步调整，必要时还要增加资源的投入。
3）制定迭代计划
确定具体迭代任务后，根据优先级及工作量将任务放至不同的迭代计划中，准备投入开发的迭代必需将任务落实至具体责任人并制定详细计划，建立表1所示的责任人清单。
注意：由于团队内不同成员的个人能力存在差异，分配任务时除了考虑各成员的时间安排外，还需要注意任务难度与对应负责人的能力是否匹配，以降低执行时的风险。
表1 责任人清单
二、管理迭代计划
制定迭代计划，是团队资源与客户期望达成一致的过程，主要考验项目负责人的沟通能力；但到了计划的落实，除了考验沟通能力之外，还需要项目负责人有强大的执行力，及时推动问题的解决，避免最终进度的落后。
1. 开发进度管理
把控开发进度可以从提高进度可控性以及减少延期风险两个维度进行。
第一个：提高可控性
提高可控性的重点，是对团队成员工作进度的把控，主要方式是制定详细计划。
详细计划是团队成员分配到具体任务后，根据任务细化自己的工作内容并预估完成时间的工作清单——其目的是让产品经理通过对每个子任务节点把控，实现对整个任务进度的控制。
以自身经历的项目为例，团队成员需要根据任务细化工作内容，而且时间跨度不可多于3天，以保证计划的可控。
表2 任务详细计划
第二个：降低延期风险
通过表2完成详细任务分解后，对任务之间的安排大致有如下印象，整个迭代完成最终取决于最长路径的完成时间。
因此要保障进度正常，需要重点关注耗时最长的任务路径，降低此路径延期的风险。
图3 红线比蓝线耗时长为重点关注路径
针对风险降低大致有以下方式：
1）确保开发对需求的正确理解
在需求文档中除了对功能的描述之外，还需要清楚地传达需求的使用场景及其真正目的，同时通过详细设计评审时发开人员对需求的复述，确保开发对需求的正确理解。
2）及时排查进度障碍
开发在实现需求时，容易陷进问题里面，最终消耗大量时间却没办法解决问题；另外如果有第三方的对接工作，第三方的配合程度也需要重点关注。
为了减少类似情况的发生，可以通过每天15分钟短会对团队成员进度进行简单了解，主要目的是排查团队成员在需求实现、对接等问题上是否存在困难；例如在需求实现上存在疑问需要及时提供解决思路，如果是技术瓶颈或对接问题，则要尽早协调资源处理。
3）选择更优的实现方式
需求在实现的过程中，存在多种实现方式，不同的实现方式又对应不同的难度，还会给系统带来不同的影响，此时需要项目负责人根据现场实际情况，选择最佳的实现方式。
例如有一个需求，需要对特殊的用户发送消息通知，A方案相对简单，但只能发给科室节点下的用户；B方案改造量较大且有性能风险，但用户在任何节点都可以接收消息通知。
此时如果产品经理确定接收通知的用户都在科室节点下，使用A方案即可满足需求，既可以在保证质量的同时，降低开发成本。
4）引起团队重视
由于开发远离项目一线，只专注于系统问题的处理，必要时需要适当地传递一线的压力；例如现场对此需求的关注程度、影响的用户范围、对整个项目的意义等，以引起负责人的重视。
实际上当各负责人知道自己工作的影响或意义，会更加主动更有责任心。
5）保障项目资源
除了降低团队内部风险发生的概率，如果团队成员不是项目的专属资源，还会有派往其他项目的风险；在说服上级以保障项目资源的过程中，迭代计划可以让领导更清晰的了解项目的规划，更放心的把资源投入到项目当中。
2. 控制任务变更
控制任务变更的过程需要使用大量的沟通技巧，在此过程中负责人需要评估范围变更的影响，通过多次沟通在团队可承受范围内达成最大效益。
主要通过两个维度进行控制：
1）减少需求调整
团队内部减少需求的调整，需要规范需求评审的过程，通过使用业务流程图、系统流程图、详细的原型设计及需求规格说明文档确保对需求完整考虑；除此之外，在评审过程中还需要开发、测试的充分参与，尽早评估实现难度。
但即使再充分的规划，难免会在开发时发现遗漏的细节，需要对需求进行调整或补充，并根据实际情况立即处理或记录至下一迭代优化。
2）控制新增任务
项目在推进过程中总会有突发的工作任务，此时必需根据当前进度做好影响分析（包括目前资源安排、新任务优先级评估与对比、对迭代进度的影响等），必要时需要做好沟通工作，例如减少原迭代任务或增加资源的投入。
3. 发版管理
系统发版更新需要与客户确认一套完整的申请流程，其主要目的是确保各环节负责人了解本次更新的时间、详细工作、风险等内容。
为了保障发版的顺利，还需要做好以下工作：
1）用户通告
系统停机更新，特别是已经上线运行的系统，必需减少更新对用户带来的不便；因此更新前要做好通告工作，同时尽量选择用户量较少的时间段进行更新，避免更新过程中由于客户使用而引发需要二次处理的问题。如果有新功能或者旧功能有较大调整，还需要提前做好用户培训功能或者准备好帮助手册。
2）规范更新文档
在正式更新前，需要准备好更新的清单，例如迭代任务清单、测试报告、配置清单、待更新的程序包等文件，避免更新过程中遗漏更新文件或配置，具体按照实际情况与团队达成一致。
3）制定发版标准
更新完成后需要对系统进行验证并及时修复问题，需要与上级或现场共同制定通过标准，例如严重问题是否必需全部解决，其余问题处理时限及后续更新机制，版本回滚机制等，再根据现场实际情况考虑如何执行。
4）资源保障
正式更新过程中，必需保证资源到位，确保发版各阶段具体任务顺利执行，例如前期公告发布、数据备份；中期系统验证与修复；后期系统巡查或用户使用情况监控等，建立资源表保障系统顺利发版。
表3 系统发版资源表
三、写在最后
每一次迭代就是一次小的项目管理，推动项目的前进需要依赖产品经理丰富的沟通技巧以及极强的执行能力。
项目管理涉及范围、进度、成本、质量、资源、沟通、风险等各类技巧的灵活运用；而本文仅提供了一个基础的框架，希望本文可以让刚入门的新人对版本迭代以及项目管理有一个基础的认识。
最后附带一个版本的命名规则，以供参考：
表4 版本命名规则
产品教练
若有收获，就点个赞吧
0 人点赞
