刚评审完的需求，也完成了一个看似不错的开发排期，可总是在快到上线前的那么几天掉链子，求天天不灵，求地地不理，欲哭无泪？这里给大家分享一些在产品迭代项目管理中的实操心得，希望能对大家有所帮助。

刚评审完的需求，半天后也完成了一个看似不错的开发估时排期，可总是在快到上线前的那么几天掉链子，求天天不灵，求地地不理，真是欲哭无泪——想必不少产品经理在推进迭代的过程中碰到过这样的问题。

那问题出在了哪里呢？估时不准确吗？中途的突发事故吗？大家偷懒摸鱼吗？

嗯，问题多了去了呢，但工作还是得继续不是？

这里就给大家分享一些个人在从业这些年的项目管理心得和体会，分享一些一支十多人的延期老王怎么逆风翻盘的故事精华。

我们这里要讲的是一个正常的产品迭代的项目管理心得，一般这种迭代两周一个到两个不等，属于正常的产品线迭代。

而一个标准的产品迭代的开始一般是一个idea或者一个大概的（模糊的）需求的提出，一个迭代的结束我们以上线为结束（后续的数据分析我们不讨论哈）。

从开始到结束，完整的一个迭代一般包含以下阶段：迭代规划阶段，需求方案设计阶段，开发阶段，测试阶段，验收阶段。

那下面我们就从迭代的这些阶段来进行解读和分析，如何做好迭代（项目）管理，避免延期。

1. 迭代规划阶段

一个迭代规划的时间节点制定一般分为两次，一次是需求方案还没确定时的需求评审时间，另一次是需求完成评审后的开发排期（上线节点也明确了）。

1.1 需求评审时间制定：需求合理拆解

在迭代开始之前，必定是已经知道了这个迭代的核心目标，即已经明确了这个迭代需要做什么事儿（需求）；但是，这个事儿一般比较大，需要产品经理进行理解后再拆解成流程和功能点，然后才能开始做规划。

例如以前做智能客服产品的时候客户会提出说希望要一个能够转人工的功能，因为xxx，所以xxx；对于客户来说就是简单的三个字和一个动作。

但是，作为一个产品经理在拿到这个需求之后，需要进行流程设计，再把这个流程拆解成功能点，然后才能大概的给出一个需求内审和开发评审的时间。

1.2 开发估时：按照实际个人能力估时

在这个阶段，强调的是【实际个人能力】这点，开发老大按照组员的实际能力布置任务，进而各人员自行估时，再由开发老大复核确认（需要说明的是不同的公司会有不一样的估时方法，这里仅作参考）。

因此这里就要求开发老大必须是实际一线coding的人员（只有这样才对实际工程量有准确的认知），同时要求开发老大对各成员的能力比较熟悉（这也同时要求了团队规模不能太大）。

2. 需求方案设计阶段：多沟通，确保方案的合理型和完整性

开发同学在开发过程中最怕什么？需求变更！

那产品经理能够完全做到需求不变更吗？ 不可能！

这样岂不是产品和开发的矛盾不可调和？还是有可能的～

只要不在开发过程中发生核心流程变更（发现核心流程有缺陷），或者重大功能变更，开发过程中的一些小交互变更或者是缺失的小逻辑补充还是能够接受的。

那么产品经理要怎么做才能够在方案设计这里就最大限度的保证方案的合理性和完整性呢——多沟通。

把一个模糊的需求拆解成业务流程和功能点的时候，可以先产品团队内部先碰一下，三个臭皮匠，胜过诸葛亮嘛。

同时，在正式进行需求内审之前，很有必要找开发老大碰一遍方案，他会站在开发的角度上审视一遍方案，提出不足，或者基于自己的技术知识提出一个你之前没有想过的方案，同时也避免了后续和开发评审时的过多讨论风险。方案完成后走需求内审，接着走开发评审，最后再走一次测试用例评审。

从一开始的方案沟通到需求内审，再到开发评审，最后用例评审，总共四轮沟通，严格且完整的走下来，基本保证了方案不存在大的漏洞。

我们大都是凡人，很难凭一己之力完成一个完美方案的缔造，既然如此，那何不利用群众的智慧？

3. 开发阶段：目标同步，进度同步，风险同步

3.1 目标同步

这里的目标同步指的是，在评审的时候，就要让开发知道每一个功能背后的意义和动因，而不是只告诉开发你需要怎样怎样做。

这样的话，开发同学在遇到一些小的开发问题的时候（例如换一个更好使的多选组件），会有自己的判断，同时也会与产品经理的目标保持一致（还有一点没说的是也会更少的询问产品经理细节问题，哈哈哈）——力往一处使很重要！

3.2 进度同步，风险同步

这里有个小窍门——每日早上的站会，同步昨天做了什么（包括是否完成了昨天的任务），遇到什么问题，今天准备做什么。会议时间保证十分钟左右，同时会上只同步信息，不解决问题；散会后有问题干系人留下讨论即可。

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

晨会，只要保证上面说的时间和事项，保证站着开（很重要！站着的会才会想快点开完），用过的谁说好～

4. 测试阶段：明确目标，分阶段推进

测试阶段一般包含以下阶段：开发自测，开发服测试，测试服测试，生产环境验收。

• 开发自测：开发人员根据测试用例自行测试，旨在保证核心流程能够跑通，核心功能能够执行。
• 开发服测试：测试人员执行测试用例，重点测试迭代核心流程和核心功能。
• 测试服测试：测试人员执行测试用例，在保证核心流程和功能正常执行的同时，检查功能的完整性。
• 生产环境回归：产品经理和测试人员线上验收功能，并回归产品重要功能事项（一般都是列好的，每次上线都需要回归的项目）。

同样的，以上测试阶段也因公司和迭代的紧急程度不同，仅作参考。

5. 验收阶段：及早验收，保证核心

在整个验收阶段，产品经理要及早参与，建议可在测试人员完成核心流程和功能测试后即可介入测试，进行功能验收，旨在确保开发的产出与预期是一致的。

这时候若是发现一些出入，调整的时间还算充足，最好不要等到线上验收才发现功能不对，那问题就真的大了。

同时，在验收的时候，先进行核心流程和核心功能的验收，这些通过了，然后才是交互等细节的验收。最后还需要回归线上固定回归事项，保证当前迭代不会对产品和之前的数据产生影响。

6. 写在最后

别让延期成为一个习惯，破罐子破摔。

准时的上线，团队脸上人人有光；使命必达，团队要有自己的节奏和责任感。

本文由 @王小二家的猪 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议