2.3 产品开发阶段的职责

产品开发阶段产品经理的工作同样重要，却容易被产品新人忽视。千万不要做“甩手掌柜”，把产品设计出来后就不再关心了，而是要时刻关注产品的开发状态，验收中间成果，排除外界干扰，稳步推进研发进度。

2.3.1　任务排期和跟踪进度

进入产品开发阶段后，产品经理需要辅助研发经理制作WBS（Work Breakdown Structure，工作分解结构），就是把产品功能拆分成若干个具体的可执行的工作任务，并确认责任人和完成时间，拆分的颗粒度越小，对完成时间的预估就越准确。一个任务只能有一个责任人，即使可能有多个人共同开发，其他人也只是参与者。

我们经常会依据WBS，再把每个任务的预计开始和结束时间规划好，利用项目管理工具形成甘特图，这样就掌握了开发排期。甘特图中的任务进度条还可以表示任务之间的关系，如果任务B的前置条件是任务A，就把两个任务进度条用箭头连在一起，含义是完成任务B的前提是任务A必须完成，任务B依赖于任务A。

在甘特图中还可以找到关键路径和关键节点，以便把控风险。例如，以每个开发人员为单位，依次把每个人负责的任务作为一个节点连接起来，在每个任务节点上标注预估时间，形成一条路径，把预估时间求和（预估时间可以按照上面的公式计算），然后找到预估时间最长的一条路径，这就是关键路径，关键路径上预估时间最长的一个任务节点就是关键节点。

关键路径和关键节点是对开发周期影响最大的，如果关键路径上出了问题，项目最终一定会延期。如果在关键路径上的人员经常被其他事务干扰，例如，线上Bug、人员抽调、请假等，项目就会存在很大的风险。因此，出现需求变更时，尽量避免涉及关键路径。如果要压缩整体开发周期，就需要压缩关键路径的时间，或者拆分关键路径。

在实操中，根据任务的预计结束时间，提前1～2天确认每个任务是否能够按预计时间完成，但不要给开发人员太大的压力。

2.3.2　解答问题、完善不足

产品经理要负责解答开发人员、测试人员和设计师的疑问。虽然在需求评审时产品经理和团队成员已经有了充分的沟通，但开发人员、测试人员和设计师在真正开始着手自己的工作时，难免会有细节上的问题需要沟通，这就需要产品经理随时解答。

如果这些疑问仅仅是理解上的问题，产品经理负责解释清楚就好，同时要检查界面原型和产品文档是否有描述不清晰的地方，导致了理解上的偏差，积累经验教训，尽量避免这种情况的发生。

如果发现了产品设计上的问题，就要及时和技术人员一起商讨优化方案，对产品设计作出修正，并更新界面原型、产品文档，做好更新记录。有些设计问题确实在需求评审阶段无法及时发现，随着开发的不断深入才会暴露这些设计上的漏洞，这是比较正常的情况。

2.1.2　小节讲到，在产品开发阶段，测试工程师要编写测试用例，为后续的软件测试做准备。此时，产品经理可以和测试工程师交代一下哪些功能模块需要重点测试，哪些细节需要格外注意。

2.3.3　页面验收

进入产品开发阶段后，UI/UE设计师以低保真界面原型图为蓝本开始设计页面效果图，产品经理要对效果图进行验收，检查页面风格是否符合产品特质、是否有缺失的关键页面、页面上展示的信息字段是否有遗漏、是否有缺省状态的提示等。

效果图验收通过后，前端工程师参照效果图进行页面代码的编写，制作静态页面。静态页面开发完成后，由产品经理和设计师共同验收，检查页面对效果图的还原程度，以及在不同屏幕分辨率、不同设备终端上的页面显示效果。

2.3.4　规划新版本

产品开发阶段的新版本规划，更多地是针对定制开发产品、部分B端产品来说的，这类产品的迭代周期相比互联网产品而言比较长，一般不需要时刻关注运营数据。这类产品的版本迭代可能只是单纯的因为系统过于庞大、功能过于复杂，所以分成若干个版本进行开发，这种情况下，在产品开发阶段，产品经理就要进行新版本的规划了。

互联网产品追求快速迭代、快速上线、快速纠错，可能需要根据当前线上版本的运营数据来规划新版本的功能，所以就要等到当前版本上线运营一段时间后，再规划新版本。 svp5witN10Q1gpeyrQMctkQbh003Mjc0miPF9M1uDzKLXvjc6wgK6eZnhPk8dAXm