项目管理：如何避免项目延期？

在项目的整个周期中，每个流程都有可能导致项目延期，所以把控好每个环节，找到自己在每个环节中的驱动力才是产品经理解决项目延期问题的根本。本文将围绕以下4点原因展开讨论如何避免项目延期。

01 哪些原因**导致项目延期？

1. 产品需求经常变动

对于产品需求经常变动，我们要问自己3个问题，产品需求为什么**经常变动？需求经常变动**产生什么样的负面影响？我们要采用什么样的处理方法才能避免需求经常变动？

产品需求经常变动的原因如下：

• 前期思考不到位，把问题想的太简单以至于好多细节和逻辑没有考虑进去，到开发阶段才发现诸多问题，从而不得不增加需求点或者更改原需求。
• 技术调研不到位，自己认为可以做的功能在基于系统现在的支撑时无法按时间迭代出来，导致只能使用替换方案，变更需求。
• 前期制定的方案对需求的理解有偏差，经过后期的对接和沟通发现理解错误然后变更需求。

2. 需求经常变动将产生什么影响？

需求是为了解决产品或者市场中某些问题和漏洞而产生的，所以所有的需求对整个产品而言一定是有正向意义的。在产品的生命周期中，需求的确定是第一流程。

如果需求经常变动**导致产品设计，开发逻辑和测试用例的重构或者已完成的工作量作废清零。

变更需求的次数越多导致团队的整体工作量增加，时间却在减少，自身和团队的工作压力就**越大，当压力过大时，经常变动需求就**很容易使团队和谐受到冲击，久而久之**让团队质疑产品经理自身的工作能力，降低产品经理在团队中的公信力，自己也**质疑自身的工作能力，产生不自信的表现，形成恶性循环。

案例：

之前在触摸屏终端做了一个横向版不可滑动的时间轴功能，任务时间段接近时**导致文字显示不全，但还是坚持把这个需求做了下来，时间轴的展示逻辑，前端开发和测试都投入了很多精力。但是后来用户反馈说那个时间轴完全用不上还是做成列表更实用一些。复**的时候总结了问题最根本的原因是臆想了用户的使用场景，没有和用户充分沟通，导致需求重做，工作量增加，和前端同学也产生了一些摩擦。

3. 我们如何避免需求经常变动？

1）使用工具辅助梳理逻辑

当面对逻辑复杂的模块时可以使用脑图和流程图辅助梳理逻辑，以安防应用其中一个小模块为例，可以使用脑图和流程图辅助梳理逻辑，避免有遗漏的数据，功能和逻辑。

案例-工具辅助：

2）极值思考

即当产品中的数据为0或为最大值时处理的逻辑应该是什么。为避免逻辑，页面和功能的缺失，采用极值条件思考，将产品中产生数据的地方统计总结并且做出数据值为0或最大值的假设来校验需求是否有缺失。

案例-极值思考：

如知乎的稍后答功能，当数据为0时，展示空页面，并引导用户查看推荐的问题。

3）前期技术调研

为了避免已经制定的需求因为现有资源和特定时间段内不能完成的情况，需求、方案要和团队进行充分的技术调研和沟通，可以上网查看相关的资料，和技术人员多讨论多沟通，确保方案基于现有的技术实力和可控的时间范围内是可行的。

4）需求调研

对比竞品，做市场调研和客户进行充分的沟通，可以先和客户讲解自己的设计方案，确保需求是真实的，并且能够解决用户面临的问题和痛点，保证自己对需求的理解是正确的。

 02 客户临时加需求

1. 客户临时加需求**产生什么影响？

当客户临时提出增加需求时，若人员数量不变，则时间成本增加，或者是增加项目人员数量。无论哪种方案无疑**使项目的成本增加，团队压力变大，当项目收入大于支出时**造成项目的资金亏损。

接手过一个类似的项目，为快速满足客户提出的需求而投入过多人员，导致项目接近完成后大批量的裁员，而根本原因就是项目的投入和产出比例失调，为保证项目的收益只能缩减人员。

2. 何如对待客户临时增加的需求？

1）获取真实需求

为了避免后期需求变动或者大家加班加点做出的功能不符合预期，被全**否掉的情况发生，当遇到客户临时增加需求时更加需要和客户确定好他的真实需求。和客户尽行充分的沟通，为便于客户能够直观理解设计方案，可使用图文并茂的讲解方式。如果有条件最好处于客户的使用场景中，体验客户使用的痛点从而挖掘出客户想要的功能。

2）替换需求

在保证客户正常使用产品功能的前提下，为了更加合理化的分配项目资源，可以基于产品现有逻辑和功能合理的替换客户提出的需求并提供原因和解决方案。了解客户想解决的究竟是什么问题，综合系统现有资源比对哪几种方案可行，并提供出性价比最高的解决方案。

3）需求阉割

为了将核心需求在一定时间内做到最好的效果，将需求划分优先级并将优先级较低的需求暂时放在下一版本中，利用系统现有资源，采用逻辑简单，较易实现的方案，这样付出成本小，效果达到了，如果方向正确，后期可进行迭代优化。

03 风险预报周期太短

1. 风险预报周期短的原因是什么？

1）重大问题发现的时间太晚，或者临近发版时发现一堆问题，导致无法及时处理问题从而影响发版。可能因为在团队协作中缺少充分的沟通，比如团队对需求的理解不清晰，对需求的优先级没有掌握或者是bug堆积，测试打包频率不够等等原因都**导致这种情况的发生。

2）需求没有分优先级,研发进度没有安排好，将所有的需求按照相同优先级去处理，导致优先级高的任务没有按时完成。

3）工作流程出现问题，缺少有效的处理机制，同一问题经常发生时很可能是流程上出了问题，这时应该自下而上去完善缺少的处理机制。

2. 在研发和测试两个流程中，产品可以驱动的方式有哪些呢？

1）每天跟踪项目进度

为了及时掌握和处理项目在开发阶段遇到的问题，在研发过程中，可以将需求按照前后端的分工拆成小的功能点，定好开发的人员和时间，每天跟踪进展。当一个小的任务有延期时可以一起评估延期风险，有必要时可以重新调整人员分配，如开发人员遇到技术难题可以开**讨论最优解，当实际任务量和预计任务量有很大差距时可以及时调整。

2）产品功能验收

当开发人员完成一组功能时，产品可以先去验收这一组功能，如果产品设计有问题时可以及时改正，如果研发实现有问题时也可以尽早修复bug。可以减少产品质量验收时的压力和工作量，bug可以尽早处理，发现逻辑有问题时也可以尽早改正，对产品的质量和项目的进度都有正向推进的作用。

3）制定需求优先级

在测试过程中可以将需要测试的功能模块分好优先级（一般按需求的优先级来），先测需求重要和逻辑复杂的模块，避免发版前出现较难解决的故障。研发人员修复bug时，也应评估bug的优先程度去修复。

 04 临近发版才发现某一功能与需求不符

这点和第三点-【风险预报周期太短】有重合的地方，在发版前发现功能实现或逻辑和需求不符这种情况虽不常出现，但是一旦发生，那么项目面临延期的风险将大大提高，所以单独把他列为第四点讨论解决方案。

1. 造成这种问题的原因是什么呢？

1）文档阐述不清晰或者不详细，导致不同人理解之间的偏差，比如文档说明支持拖动排序，但没有写具体的排序方法是替换排序还是顺序排列，导致有A，B两种实现方式，产品认为使用方案A，开发理解的是方案B，产生理解偏差而且问题还不容易被发现。

2）产品，研发和测试人员没有充分的沟通，各自都以自己的理解去想问题，是第一点的衍生情况，当文档已经产生歧义时，又没有线下的充分沟通才**导致需求和实现的功能不符。

3）没有功能验收，功能完成后，产品同学没有去验证是否和自己要求一致，可能是公司没有设置这一流程，但是产品同学做好功能验收可以把最严重的问题在第一时间暴露出来从而可以及时改正。

2. 产生的影响

这种重大的失误不仅**导致项目延期，还因为涉及的人员过多导致相互甩锅影响团队和谐，引发团队矛盾。因为功能不能按时准确的完成，往往需要其他的方案或者更多的时间来补救。

所以如何避免这种情况的发生尤为重要？

• 优质的需求文档：将产品文档写的详尽一些，简单易懂的描述自己想要的是什么，如果语言组织上出现问题时可以参照市面上已有的功能，转化成口语形式去描述。
• 团队沟通：和研发，测试人员充分沟通，确保他们理解你想要的功能是什么样的，可以用原型辅助演示自己想要达到的效果。
• 产品先验收后测试：产品经理可以在开发人员开发完成后，测试之前，先验收功能的一致性和逻辑的正确性，保证产品的走向是正确的。如果在错误的基础上进行测试，那么就浪费了员工的精力，时间，最终还没有达到预期的效果。
• 质量验收：在测试完成后进行产品的质量验收，此时的产品应没有重大，明显的bug，产品主要是对页面的美观度，操作的流畅度进行验证，验证无误后即可进行发版。

05总结

希望产品同学多以自身为驱动力，找到自己在每个环节中的问题才能找到自己能做的解决方案。

本文由 @菜菜子  原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Pexels，基于CC0协议