从10大管理看产品经理的日常工作——产品进度管理
大家对产品经理的日常工作有所了解吗？产品经理在日常工作中又怎么样做好产品的进度管理呢？大家一起来看一下下面这篇文章了解一下吧！
管理产品进度，保证产品准时上线是产品经理日常工作之一，传统的产品研发思路是将所有功能都研发完成之后再上线，研发周期可能横跨数月甚至数年，所以留给产品经理的进度管理空间通常比较充裕，产品经理只要确保产品能够在截止日期前上线即可，期间对需求的规划和管理相对比较灵活。
而互联网产品，尤其是 MVP 产品的研发思路，要求以敏捷开发的思路来对产品进行研发，功能以版本形式进行迭代发布，每个版本的研发周期可能只有1-2周甚至更短。
因此对产品经理的进度管理能力提出了更高的要求，一方面要求产品经理精准规划好当前版本的需求，同时需要产品经理对产品的迭代方向要有精准的把控，能够同时进行未来多个版本的规划。
另一方面，产品经理还需要把控好每个版本上线的时间，既要确保当前版本的准时上线，又要确保下一版本的任务能够准时衔接，避免出现版本发布后，开发没有任务做的情况。
也就是说， 产品经理既要把控好版本的研发进度，同时又要把控好产品的规划进度，确保产品研发与规划间的无缝衔接。
本文结合产品版本管理的思路，分享产品经理在日常工作中如何做好产品的进度管理。
一、定义任务
定义任务指的是明确当前需要研发的版本的目标，但这有点太抽象，换个思路，要定义版本的任务，首先需要明确当前版本需要实现什么业务目标，进而明确为了实现业务目标需要实现哪些功能，最后明确为了实现功能需要实现哪些需求。
这样，问题最后就转换成了当前版本需要实现哪些需求，而需求管理正是产品经理所擅长的领域。
举个例子，假设当前版本的业务目标是实现用户的注册登录，这个业务目标可以拆分成两个功能点，分别是用户注册和用户登录。
用户注册的功能点可以进一步拆分成账号密码注册、手机号注册以及第三方账号注册的需求，也可以将“第三方账号”注册列为功能点，将需要实现的第三方平台账号对接作为具体需求，划分颗粒度可以根据具体产品来决定，用户登录功能也是同样拆分成多个需求。
二、确定优先级
关于如何确定需求优先级，我在《从10大管理看产品经理的日常工作——产品需求管理》（下称《产品需求管理》）一文中有介绍过可以按四象限评分、需求关联（依赖）度、开发难度、开发周期等多种维度进行多维评分来确定需求优先级，此处不再赘述，这里想再补充另外一种确定需求优先级的方法——紧前关系绘图法。
在《产品需求管理》一文中分享过，需求的依赖条件一般有需求依赖、设备依赖、政策依赖、开发依赖、环境依赖、安全依赖等，紧前关系绘图法就是通过确定每个需求之间的依赖关系，最终推导出每个需求之间优先级顺序的方法。
这种方法一般会综合多维度进行划分，对于依赖关系比较密切的需求可以快速划分出它们之间的优先级。
以购物车为例，假设现在需要做针对购物车功能实现以下需求：
添加购物车、删除购物车、清空购物车、购物车支付、修改商品数量、选择商品、统计选择商品数量、统计选择商品金额。
如果要对这一堆功能划分优先级，基本上除了“添加购物车”需求是最先能够被确定的之外，其他需求的优先级就很难定，好像先做谁都可以，这个时候，我们就可以通过“紧前关系绘图法”来推导优先级。
首先我们在图上把所有需求先画出来。
然后找到每一个需求的“紧前关系”，记住，一定是要找紧前关系，就是实现当前的需求之前需要先实现的需求，如果你找“紧后关系”，你会发现，除了“添加购物车”需求第一个做，其他功能都可以作为“添加购物车”的“紧后关系”，就会变成如下图所示：
这样的优先级是没有太大的参考价值的，所以需要找紧前关系，找紧前关系需要遵循的原则是：每个需求都需要找到紧前关系，并且是联系最紧密的那个需求。
针对上述需求，我们可以来尝试找一下每个需求的紧前关系，如下图：
从上图我们可以发现，原本我们以为做了“添加购物车”的需求之后，直接做“购物车支付”的需求也可以，但通过紧前关系来进行推导，发现实现“购物车支付”需求，需要先实现“统计选择的购物车商品金额”的需求，而在此之前，需要实现“选择购物车商品”的需求，在这之前，才是“添加购物车”需求。
我们按思维导图的形式把这个图重新梳理一下，就可以得到一个“紧前关系图”：
通过上图，我们除了可以知道每个需求的优先级以及他们之间的依赖关系，我们甚至可以在图中找出本次开发任务的主线，比如我们此次的业务目标是让用户可以将商品添加到购物车并支付，那么我们只要找到最终目标“购物车支付”，然后顺着紧前关系一直往前找，就会找到本次开发任务的主线，如下图：
如此你会发现，即使有很多的功能没有开发，也不会影响本次业务目标的实现，这就是在上文“定义任务”中所提到的“确定需要实现的业务”的重要性。
三、估算资源
估算资源之所以放在进度管理中，是因为资源对进度有着至关重要的影响，相同的需求，5个人开发和10个人开发，进度肯定是不一样的。
在产品研发的不同阶段，由于需求不同，因此所需的资源也不尽相同，所以估算资源需要在确定了任务和需求之后才可以进行。
资源可以分得很细，但一般习惯性将它分为两大类：人力资源和支撑资源。
人力资源很好理解，就是本次产品研发需要的人员，核心点一般就是3个：岗位、人数、职级。
岗位指的是本次研发需要用到哪些岗位的人员，比如：产品经理、UI 设计师、前端开发工程师、后端开发工程师等。
人数指的是每个岗位需要的人数，比如：需要2名产品经理，1名 UI 设计师，2名前端开发工程师和4名后端开发工程师等。
职级指的是每个岗位人员的能力级别，比如：4名后端开发工程师中，要求至少1名高级工程师和至少2名中级工程师。
以上3个是最容易对进度的评估和控制产生影响的因素。
支撑资源则是指除了人力资源以外，一切支撑产品研发的资源。比如产品开始研发时，需要的服务器、数据库等资源。
支撑资源也是需要根据需求进行评估，比如做验证码登录，需要开通短信包资源；比如做移动支付，需要开通支付接口等。
资源的申请时间和到位时间也是估算时间的重要评价标准，比如开通移动支付，申请和审核预计需要7个工作日，并且期间有可能审核不通过，需要重新审核，这些因素都不能不考虑，否则有可能出现某个版本快做完了，发现支付没有接，一问，说还没申请下来，这种对于产品研发的进度管理简直就是灾难性的。
因此，在开始一个版本之前，就需要先评估好需要哪些资源，并且确认好这些资源落实的时间，确认哪些资源是必须在开始研发前到位的，哪些是可以在研发进行过程中申请和推进的。
这个时候我们会发现，我们在上一阶段确定优先级的时候，只针对需要开发的需求确定了优先级，实际上在整个进度管理过程当中，申请或等待资源落实也会占用时间，因此也应该把申请资源之类的任务也放到“紧前关系图”中。
比如我们需要在“添加购物车”需求开始的同时进行“申请开通支付接口”的任务，那就需要在在图中添加一个“申请开通支付接口”的任务了，非需求的任务我们可以用另外的颜色标注出来，如下：
“添加购物车”和“申请开通支付接口”并列进行，没有紧前关系，所以可以增加一个开始节点来代替，从新的图中我们可以更加清晰地看到，“购物车支付”有两个紧前任务，只有当这两个紧前任务都完成的情况下，“购物车支付”任务才可以开始。
四、估算时间
确定需要开发的需求和所需资源之后，就可以对每个需求的开发时间和每个资源的落实时间进行评估，这个阶段需要研发人员介入，对每个任务进行详细评估。
评估时间一般依靠评估人员的经验和综合分析得到，最终需要将评估的结果反映到“紧前关系图”中，评估时，并不是简单的评估好每个任务所需要的时间就够了，还要考虑到4种“关系”和两个“量”：
4种关系：
- 完成-开始（FS）：紧前活动完成，紧后活动才能开始。比如：“添加购物车”的功能做完之后，才可以开始做“清空购物车”的功能。
- 完成-完成（FF）：紧前活动完成，紧后活动才能结束。比如：“统计选择商品金额”和“选择商品”可以同步开发，但在“选择商品”功能开发完成之前，没有办法验证“统计选择商品金额”功能是否正确实现，所以必须在“选择商品”的功能开发完成之后，“统计选择商品金额”功能才能完成。
- 开始-开始（SS）：紧前活动开始，紧后活动才能开始。比如：“统计选择商品金额”需要等“选择商品”开始之后才能开始，否则如果突然取消“选择商品”这个需求，那么“选择商品金额”这个需求就没有意义了。
- 开始-完成（SF）：紧后活动开始，紧前活动才能结束。假设“申请支付接口”和“获得支付接口”是一组紧前紧后任务，在获得支付接口之前，可能会有多次审核，因此要不断申请，只有“获得支付接口”的任务完成之后，“申请支付接口”的任务才能结束。
从上文的第3点和第4点可以看出，紧前紧后关系并不是绝对的，相同的紧前紧后活动在不同的场景下可以有不同的定义，对工期的评估自然也会有不同的影响。
两个“量”：
- 提前量：相对于紧前活动，紧后活动可以提前的时间量。比如“统计选择商品金额”活动可以提前3天开始，不用等“选择商品”活动开始，这个“3天”就是提前量，在算工期的时候，可以减去这个时间。
- 滞后量：相对于紧前活动，紧后活动需要推迟的时间量。比如“开通支付接口”申请提交后，需要等7天完成审核，之后才能对接支付通道，这个“7天”，就是滞后量，在算工期的时候，需要加上这个时间。
由此我们会发现，不仅是每个任务的时间会影响整体工期，紧前紧后的关系以及提前量和滞后量也会影响整体工期，评估后，同样需要将每个活动的时间、它们之间的关系以及提前量或滞后量标注在“紧前关系图”中，如下：
关于“紧前关系绘图法”的一些基本概念，本文就介绍到这里，各位如果对此比较感兴趣，可以去网上查找资料深入学习，在此基础上结合“关键路径法”，可以计算出整个项目的工期，甚至每个活动的最早开始时间、最早完成时间、最晚开始时间、最晚完成时间以及总浮动时间等。
五、制定进度计划
由于互联网产品的迭代速度极快，现在已经几乎没有产品经理会为了某个版本去专门制定一份书面计划，但不是说可以不做计划，一般推荐用项目管理软件来管理每个版本的计划。
目前市面上有很多项目管理软件，一般都是以需求或任务为单位，对需要完成的需求或任务进行详细描述，并指派负责人员以及规划好开始和结束时间，各成员在开发需求或执行任务过程中需对计划更新。
通过管理软件看板就可以清晰了解到每个需求或任务的状态以及完成度，做的比较细的项目管理软件甚至还会提供各种维度的数据统计报表，如下是某项目管理软件的部分界面截图：
六、监控进度
监控进度的节点称为“监控点”或“里程碑”，一般在制定进度计划时会约定将某个任务完成或某个具体的日期作为“监控点”，在任务完成或到达约定日期时，对产品研发进度进行监控，根据版本的大小，监控点可能很密，也可能很少，一周一更的产品甚至有可能没有设置监控点，只在最后进行验收。
得益于项目管理软件的应用，监控产品研发进度也变得更加直观和简单，关于监控进度的工作，主要记住以下几点就可以了：
- 判断当前产品研发进度的状态：进度超前、正常还是落后。
- 对可能引起进度变更的因素施加影响，使其朝有利方向发展，比如申请开通支付接口过程中，有可能资料审核不通过，需要重新提交资料，容易影响到后面支付功能的开发，所以一定要及时关注动态，确保不会因为申请过程延误太长时间而影响到产品研发。
- 判断项目进度是否已经发生变更，并在变更发生时，使用变更控制流程对其进行管理。
变更控制流程在之前的《从10大管理看产品经理的日常工作——产品整体管理》中有提过，这里不再赘述。
七、控制进度
控制进度主要是在进度超前和进度落后时介入。
进度超前未必是一件好事，当进度超前时，需要进行“3个核实”：
- 核实产品是否按照设计正确实现。比如是否有规划好的需求没有开发。
- 核实产品质量是否达到既定指标。比如查询性能是否达到合理的指标，查询时间是否在预先确定的范围内。
- 核实进度计划是否合理。比如制定计划时，是否将原本3天可以实现的需求写成5天。
如果核实发现问题，需要进行干预，比如要求按照设计优化产品，或重新修正进度计划等，如果经过以上“3个核实”都没有发现问题，那么这个进度超前，就目前为止来讲，就是一件好事。
进度落后就一定不是一件好事，当进度落后时，同样需要进行“3个核实”：
- 核实造成进度落后的原因。
- 核实实际落后的进度。
- 核实落后的进度是否已经对整体的进度产生影响。
核实原因是为了解决问题，核实落后进度是为了提供针对性的改进方案，核实对整体进度的影响是为了确认是否需要调整整体的进度计划。
针对落后的进度，一般有以下几种改进方法：
- 赶工。就是加班，但注意这种方式可能会影响成员情绪，需要做好人力资源管理（关于产品研发过程中的人力资源管理后续有机会整理专门的文章分享）。
- 快速跟进。将原本按顺序进行的任务改为并列进行，可能会有返工危险，需要做好产品质量管理（后续有机会专门分享）。
- 使用高素质人才。将初级工程师暂时替换成高级工程师，以期提高工作效率，降低返工风险。
- 改进技术。比如使用更加成熟或更加容易维护的系统框架。
- 加强质量管理。产品质量管理需要在整个产品研发过程中持续关注，确保不会因为早期没有发现的产品质量问题而导致后期需要返工。
- 在获得批准后，删减部分依赖程度较小的需求。比如上文举例的，业务目标是实现添加购物车并支付，后来发现相关的几个需求实现难度比想象复杂，进度严重落后，则可以在经过审批并获得同意后，将与业务目标依赖性较小的需求删掉，放到后续的版本完成。
以上便是本文的全部内容，感谢阅读。
