产品迭代一直延期，该怎么办？

最近和一个创业小有成就的产品朋友聊天，给我感受最深的一句话就是：“产品经理在版本规划过程中通过把产品想得特别美好，但是产品在开发过程中的表现并不是按照你的计划去进行的”。

下面这张图很形象的说明了计划和实施过程是完全不同的。

刚评审完的版本迭代需求，好像技术在几分钟后，就能有一个大致的开发估时排期。可是一旦到上线前几天，问题就凸显了。需求有问题，开发进度滞后，测试时间不够，老板调整需求等等。这些想必是不少产品经理在推进迭代的过程中碰到的问题。

那问题是出在哪儿？研发能力不行？产品需求有问题？中途有突发事故？……可能还会有更多的问题的。但是产品迭代还是得继续不是？

接下来结合John实际工作经验和项目管理的思考，和大家一起聊聊项目管理中的步骤。

现在大多数项目组都是敏捷开发，我之前的经验是对外发布的版本是：产品在快速扩张阶段保持“双周一个小版本，一个月一个大版本”；产品在稳定阶段保持三周一个版本发布。对内发布的版本永远是双周内迭代版本。（当然所有的紧急情况都是例外且优先处理的哈。）

产品迭代从开始到结束分为几个阶段：需求迭代规划阶段、需求设计评审阶段、需求时间评估阶段、版本开发编码阶段、产品测试验收阶段。

通过这五个阶段根据项目管理来执行，看看如何避免项目延期。

1.需求迭代规划阶段

在需求迭代规划阶段，可以分为两步去敲定需求迭代方向。

第一步是碰需求。根据需求提出方所提出的需求去甄别需求的真伪。这一步主要是碰需求。保证需求的真实有效性；

第二步是选需求。根据第一步所收集的真实有效需求，确定需求的优先级。

真的，需求的收集和甄别在历史文章中已经聊吐了。最后再说一遍。

1.1.碰需求

和需求提出方聊需求，一定要给对方提及很重要的一句话：“这个需求是想为哪些用户在哪些场景下做哪些事情，目的是什么？”

也就是需要需求提出方针对该需求涉及到的业务流程说清楚。如果是单独的无前后端交互的需求（比如加上联系方式等），这种还是比较简单的。一旦牵扯到前后端数据交互、模块连通的需求，那么除了需求提出方说清楚业务流程外，产品经理需要解释清楚需求的难易程度和投入的ROI。（这里并不是让需求提出方就此打消需求，而是需要考虑整体的合理性，是否能为后面版本减轻压力，或者能反哺业务侧有快速增长）

将所有已经确认的需求统一整理到业务需求池。业务需求池给一个模板。（也不用和John的业务需求池模板一样，主要能有效的收集需求即可）

（点击图片看的更清晰）

1.2.选需求

根据沉淀到业务需求池中的需求进行筛选。产品经理在筛选需求一定要根据两个条件来筛选：

• 根据产品目标来筛选需求。通过产品目标来筛选的需求一定是未来两到三个版本需要做的。优先保障业务侧需求才是第一目的。
• 根据产品规划来筛选需求。这儿当然要说到一个前提，产品经理一定需要有产品版本路线图。从产品经理角度知道产品需要怎么走，然后结合产品目标已筛选的需求进行二次筛选。就明晰当前版本的需求大纲了。

当然还有一个点很重要，版本迭代需求最好带有优化类需求。即为新功能需求+优化类需求。

当确认了需求点后，接下来就是产品经理专业技能的兑现了。

2.需求设计评审阶段

需求方案通过产品经理将功能清单、功能流程图、页面原型图和功能逻辑梳理清楚之后。分为几步：

• 产品经理内部评审：产品团队的小伙伴一定要内部评审和走一遍流程。也可以叫上需求提出方，一起碰下产品侧版本解决方案。
• 和研发负责人初稿评审：当内部评审没有问题后，和前后端研发负责人可以初稿评审，主要是针对研发侧流程和项目预期给一个初步时间。同时也让研发可以清晰了解此版本执行难度；
• 和研发细节评估：和研发负责人评审通过后，接下来拉上参与此版本的技术一起整体过一遍。从整体到细节逻辑落地。

当然也能中间还会有细节的缺失。这里就需要在研发过程中多和项目组的小伙伴沟通。尽可能的保障方案的合理性和完整性。

随着三套评审会的落地，产品基本已经敲定了。接下来到了项目估时阶段了。

3.需求时间评估阶段

在需求即将进入设计环节和开发环节时，需要提前确认排期。这里需要开项目估时会。其中包含UI设计和交互所需时间（在UI设计师交付设计清单后，需要开验收会）、后台接口交付时间、前端开发时间、测试用例输出时间（当测试输出测试用例后，需要有测试用例评审会）、测试时间和上线节点。

这里需要注意的是时间评估一定要需要各端负责人参与（可能会出现某个功能或者模块评估时间太长或太短），同时也要根据开发人员的能力来合理安排时间。

以前在技术估时用的一个方法：扑克牌一副或多副够用就行；以开发为例，技术负责人、全部开发每人分10张扑克牌，1-10，每个点可以代表2小时或半天。对于一个任务过了案子就可以大家出牌评估任务时间，如果一次时间偏差大，让偏差大的说出时间的理由，相互讨论说服对方，再次出牌，直到一致或相差比较小时，给出任务时间周期。

然后产品经理根据上面各部门提供的时间表。整理成甘特图：

（点击图片看的更清晰）

当然还可以利用其他项目管理工具沉淀项目进度。这里有一点需要注意的是当清楚时间节点后，需要和运营和相关人员反馈，便于做好市场预热和运营计划。

项目时间已经评估后，接下来就进入产品研发阶段了。

4.版本开发编码阶段

其实开发阶段才是最重要的阶段。这里面埋下的伏笔就是产品经理在评审会上一定告知技术每个需求背后的真正含义是什么？因为包括一部分是为了满足当前版本的实现，一部分是为了后续版本的迭代做准备。

再一点，让技术明白背后的原因有助于帮助技术更好地处理逻辑。

在开发阶段每天的站会必不可少，主要包括昨天做了什么？是否有问题没有解决？今天的主要工作，需要同步给哪些人？

通过这个站会，掌握迭代每天的进度，及时解决团队成员遇到问题（例如：开发同学在开发过程中遇到的开发难题，这时候开发老大可以及时的提供团队内部帮助或者请求专家资源介入），及时了解项目风险（并调整项目计划例如遇到不可抗力的技术难题导致项目延期风险，及时向上级汇报，同时调整迭代计划）。

研发阶段一定要和技术在估时阶段的时间节点有所提前，绝对不能滞后。否则运营的计划都会打乱。上线时间是红线。

随着开发阶段的结束，接下来测试阶段才是最重要的。

5.产品测试上线阶段

当项目提交给产品经理和测试人员之前，需要进行开发自测。主要是发人员根据测试用例自行测试，旨在保证核心流程能够跑通，核心功能能够执行。

当开发自测没有问题后，提交至开发服，测试人员根据测试用例进行流程和功能测试。其中产品经理可以坐体验测试。UI设计师进行UI验收。

当开发服测试没有问题后，提交到测试服，可以邀请需求提出方去体验。同时也可以邀请少部分种子用户进行体验。看具体问题实施。

测试服没有问题后，提交到生产环境。产品经理、UI设计和测试同步线上测。并回归产品重要功能事项。提前让运营准备好相关内容填充。

生产环境问题全部清空后，后台先发布，运营填充版本所需内容，产品经理发版本迭代内容。然后前端发布至各平台。

产品经理线上版本邮件同步：包含发布内容和体验地址。

至此，版本的生命周期才算结束。接下来是新的需求迭代。

最后的思考：

如果延期，只是在项目过程中出现了问题。如果同步好上面的步骤。延期就不再成为习惯。去试试吧。也许你的项目不再延期。

#作者介绍#

John，公众号：产品狗聚集地（ID：Johntalking），现迷你玩产品。专注于教育、电商产品。对用户研究、产品分析、需求把控有自己的理解和方法论。负责过数百万级产品运营。

本文系作者授权发布，未经许可，不得转载。

题图来自 Unsplash，基于 CC0 协议