概述
没有特殊原因，项目延期，这个字眼是不能随便说的，如果项目才开始不久或者还有一半的时间，就开始提延期，是不负责任的行为。因为还有很多努力的空间呢，如何解决如何应对才是你该想的事情。如果有些风险，就要延期，是很难跟老板、业务方交代的，同时也会让老板觉得，你态度和能力都有问题。
但是呢，我们还是要好好分析可能导致项目延期的原因，并做好的一些预防的动作，尽量避免由于项目失控，搞的项目的相关参与人手忙脚乱，压力山大的。
可能的一些原因
产品PRD问题
- 不清晰，PRD不清晰，描写的不清楚，看完后，有一种感觉就是：【你猜，我要做什么】？这种几乎是属于致命的问题，因为会给各个项目阶段，带来极大的沟通成本。无论是在需求评审阶段，还是在开发和测试阶段。有人可能会提出，不是能在需求评审的时候，对齐吗？不要指望需求评审，需求评审阶段，N多人有疑问，觉得PRD没讲清楚，产品经理调整完PRD后，会暂时达到一致。但是从实际的项目经历来看，一旦PRD从一开始就不清晰了，靠需求评审后去调整，后续也是有一堆不清晰的问题暴露出来，这个其实是写这个PRD的产品经理的能力问题，他/她压根就无法写出一个清晰的PRD。后续前后端和开发和测试人员，会经常性的在群里问问题或者开会对齐问题，浪费了非常多的时间，也就压缩了开发和测试人员做本职工作的时间。
- 不完整，也即是PRD有遗漏的地方，没考虑到。这种会加大开发和测试人员的工作量。
- 产品功能的设计过于烦琐，大而全，兼复杂。本来可以简化的功能设计的太复杂了，这个会导致不可控制性和复杂度的加大。产品经理也需要有项目的视角，多从项目整体执行和风险性的角度审视自己写的PRD的复杂性。
产品PRD是源头，如果在这个阶段出现了问题，一般都是致命的。产品经理写完PRD后，最好产品之间有内审，且提前跟开发和测试多沟通，尽量保证PRD的质量。具体的可以看一下技术经理成长复盘-产品研发要配合好。
开发和测试时间预估不准确
也即是过于乐观了，原本可能需要两周的工作量，却只评了3、4天。这种一般加班加点，也比较难搞定了。
- 开发时间的评估，稍微复杂一些的模块，最好让熟悉业务的资深开发帮忙评估一下，会相对准很多。另外也尽量有技术设计和技术评审这些环节，技术设计是逼自己努力想清楚，具体要做什么，有哪些关键的任务需要重点做。而技术评审，是请其他人review，尽量往正确的方向走。
- 测试时间的评估，同样的方式，需要让熟悉业务的资深测试协助评估。
沟通问题
也即是没有及时把风险同步出来。比如说，开发人员开发任务进行到一半的时候，觉得实现难度很高，但是想硬扛，在项目关键里程碑节点快到的时候，才提出来，耽误了工期。这种的话，只能通过监控的手段来避免。你可以在项目的每个里程碑节点的前几天，都主动去询问和了解进度，让相关人员及时出声。注意，不是说要搞每日站会哈。
第三方依赖的问题
因为第三方依赖它不可控，如果没有及早的梳理和对清楚，到了项目后期才暴露出问题，那真的是回天无力了。无论你多急都没用，第三方公司就是有自己的节奏和规章制度，不会听你的。像美团、支付宝、微信、外包公司等等，只要项目有涉及到第三方的，一定提前把所有事情都对清楚。
需求变更
这个可能是PRD质量有问题，也可能是来自外部的原因，比如说，业务方或者大老板有新的想法。
无论需求变更是大还是小，出于降低风险的角度出发，开发、测试都需要重新认真评估的，这无疑又会多出来很多工作量。
研发流程体系不完善
前面列到的几种原因，很多都是研发流程系统不完善导致的。项目要有序执行，除了靠人，还需要靠流程体系。
研发流程体系，不只是研发内部需要遵循，研发外部的产品、运营等业务方也需要遵守。因此需要有一个强有力的老大去落地推广这套体系，这个真的很重要，如果没有这号人的话，基本上流程要很好的落地，都是极其渺茫的。
标签：PRD,项目,评审,问题,开发,产品,延期,原因 来源： https://blog.csdn.net/linsongbin1/article/details/122823043
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。