作者
魔笛责编
伍杏玲出品
程序人生（ID：coder_life）
“延期”这个词对于开发者来说真是太熟悉了，它是指项目没有在承诺的时间规定范围内交付。引起这个问题原因是综合性的，在这列举几个可能的因素：资源配置不适合，进度评估过于乐观，需求设计缺陷，团队自身问题等等。
下面对于预防延期提几点建议，希望对大家有用。
合理资源配置
延期有一个很容易忽略的原因是资源不足。因此项目开始之前，PM或者项目Leader去整合资源是必要的，去寻找项目需要的参与者和三方资源，让项目可以顺利的启动。可以从下面几项考虑：
人员配置，项目开始之前，PM可以先考虑一下人员配置。根据项目工作量大小，相关工作经验安排谁去做或者多少人去做。并且还要做好人员梯度，我当然希望团队里面都是经验丰富的“大哥”，但是事实上，“大哥”工资高，小弟扛不住啊。一般合理的做法都是有一个团队梯度，以老带新。
知识配置，项目可能涉及到多端，多个方面，包括产品、UI、开发、测试等。最好可以配置相关工作经验的人员参与，如果没有，可过通过招聘或者通过知识调研等方式补充知识空白。
资源配置，项目所需的服务器资源，三方软硬件资源等等尽量考虑在内。
资源合作，在某些团队中，技术授权凌驾于需求和设计授权之上；在其他团队中，则是从属其下；而在最佳的团队中，这几种类型的授权之间会有一种合作的关系。
明确的需求评审
需求文档是一个产品从无到可视化的过程，是后期一切工作的重要依据，如果后续的工作过程中好要不断的重新回顾整理需求流程的话，无疑是浪费时间的。因此一份明确的需求是非常重要的，从初稿到最终原型，可以通过一些评审来不断精炼。
评审建议参与项目的人员都参与，包括PM、产品经理、开发、测试等。
评审的目的：
让参与项目的人充分了解项目；
找出需求中的不足和补充，并做好记录，为下次评审或者后面的工作修改；
让参与项目的人同意，并认可这个项目要做的事情；
风险把控。
评审并不会只有一次，但尽量用最少的次数输出一些完整的原型
评审的质疑和提问，这并不是否定产品，而是通过提问来推进产品审评的过程，让大家跟了解将要的做的事情。
最终的输出是大家都一直理解并认同的原型文稿
必要的“业务需求转化成技术需求”
这个过程其实是项目过程中的必要阶段，但是大多团队往往会忽略，或者做的不够充分，引起后期代码开发者的疑惑。也有团队觉得这也OK的，我们的工程师经验很丰富，代码结构了然于胸，但是缺乏记录的过程，往往会让后续维护人员无从下手。
这一部分工作会根据业务的不同有不一样的答案，每位IT架构师对此问题的答案的
