“延期”这个词对于开发者来说真是太熟悉了，它是指项目没有在承诺的时间规定范围内交付。引起这个问题原因是综合性的，在这列举几个可能的因素：资源配置不适合，进度评估过于乐观，需求设计缺陷，团队自身问题等等。

下面对于预防延期提几点建议，希望对大家有用。

合理资源配置

延期有一个很容易忽略的原因是资源不足。因此项目开始之前，PM或者项目Leader去整合资源是必要的，去寻找项目需要的参与者和三方资源，让项目可以顺利的启动。可以从下面几项考虑：

• 人员配置，项目开始之前，PM可以先考虑一下人员配置。根据项目工作量大小，相关工作经验安排谁去做或者多少人去做。并且还要做好人员梯度，我当然希望团队里面都是经验丰富的“大哥”，但是事实上，“大哥”工资高，小弟扛不住啊。一般合理的做法都是有一个团队梯度，以老带新。
• 知识配置，项目可能涉及到多端，多个方面，包括产品、UI、开发、测试等。最好可以配置相关工作经验的人员参与，如果没有，可过通过招聘或者通过知识调研等方式补充知识空白。
• 资源配置，项目所需的服务器资源，三方软硬件资源等等尽量考虑在内。
• 资源合作，在某些团队中，技术授权凌驾于需求和设计授权之上；在其他团队中，则是从属其下；而在最佳的团队中，这几种类型的授权之间会有一种合作的关系。

明确的需求 & 评审

需求文档是一个产品从无到可视化的过程，是后期一切工作的重要依据，如果后续的工作过程中好要不断的重新回顾整理需求流程的话，无疑是浪费时间的。因此一份明确的需求是非常重要的，从初稿到最终原型，可以通过一些评审来不断精炼。

• 评审建议参与项目的人员都参与，包括PM、产品经理、开发、测试等。
• 评审的目的：

1. 让参与项目的人充分了解项目；
2. 找出需求中的不足和补充，并做好记录，为下次评审或者后面的工作修改；
3. 让参与项目的人同意，并认可这个项目要做的事情；
4. 风险把控。

• 评审并不会只有一次，但尽量用最少的次数输出一些完整的原型
• 评审的质疑和提问，这并不是否定产品，而是通过提问来推进产品审评的过程，让大家跟了解将要的做的事情。
• 最终的输出是大家都一直理解并认同的原型文稿

必要的“业务需求转化成技术需求”

这个过程其实是项目过程中的必要阶段，但是大多团队往往会忽略，或者做的不够充分，引起后期代码开发者的疑惑。也有团队觉得这也OK的，我们的工程师经验很丰富，代码结构了然于胸，但是缺乏记录的过程，往往会让后续维护人员无从下手。

这一部分工作会根据业务的不同有不一样的答案，每位 IT 架构师对此问题的答案的关注点都或多或少有自己的特别之处。

下面提供一个建议流程：

• 抽象出服务模型，以客户为核心整理出我们将要提供的服务。
• 服务流程，从客户体验服务开始，客户端，服务端以及其他服务商交互流程的整理。
• 任务分解，将流程中的任务分解成小任务，尽量细化，并输出work list，每一个work单独评估完成时间。

合理的进度

首先要说进度表的目的是什么，有三点：

• 第一：是承诺，是对什么时候完成任务的承诺，确定每个人在什么时间交付什么工作成果。
• 第二：每个人努力把自己的任务当成整个项目的整体的一部分，可以把自己的任务和他人的任务结合起来，如果每个人都可以按时合理的完成自己的任务，从而不影响他人的工作，对于整个进度就是一个良性的促进作用。
• 第三：就是提供了一种能够追踪项目和把工作分成若干个易于管理的小块的工具。把工作分成一天或者两天的量，能够帮助团队更好地理解他们到底需要做些什么。

我们需要用好工具去管理进度。记录，追溯，合作开发是项目必备，聪明的团队会找一些工具，或者自己开发一些工具来帮助自己，例如Jira、GitLab WorkFlow。

我个人也比较喜欢开发或者寻找一些工具来提升团队效率，因为任何书面式，人为监督的规章，规范都不如用一个工具来监控，提示，帮助大家来的更有效果。建议团队根据自己的情况，不断积累经验，找到最合适的团队的工具，还是那句话，最终的目的是"Everything is OK!"

建立有凝聚力的团队

不断让自己的团队有凝聚力，是应对任何延期的问题最有力的武器。PM或者团队leader可以从以下几个方面努力：

沟通

项目整个过程都伴随一个重要的元素，沟通，准确的说是有质量的沟通。沟通的5个基本的状态：传达、收到、理解、同意、转换成有效的行动。

沟通也经常失败，原因传达不够明确，没有倾听，理解上的误差导致团队由对事情的意见转为人身攻击，嘲讽都是有的。团队是由每一个自然人组成的，刚刚成立的项目组彼此之间的陌生和不信任是可能的。

这里有几个建议：

1. 明确角色和各自担任的工作任务；
2. 自我介绍，通过过往的工作和生活背景，让大家更了解彼此；
3. 激励，挑战。每一个角色通过努力输出成果，从而取得彼此的信任；
4. 明确的项目目标，让每一个角色忽略一些不必要的，向同一个目标努力；
5. 项目经理从自己做起，努力帮助他人，让团队更加团结。

给团队适当的压力

压力是一种强制而令人受约束的影响力或力量 施加压力和缓解压力是每个团队应该考虑到的问题，分为：

1. 施加压力可以是人为赋予的正面的压力，在艰难时期更加努力工作和提高效能的人，就会得到奖励（例如加薪、提升、奖金），也有负面压力，包括斥责、使人产生罪恶感，或者威胁，通过这类方式让众人努力工作。我个人提倡多用一些正面压力估计他人，适当的用一些负面情绪。根据项目情况而定的一种战略而已。
2. 缓解压力，大多是放下暂时的工作，组织运动，用经费（如果团队里面多的话）旅游，我个人比较喜欢茶话会。喝茶的同时可以让大家彼此了解。

适当的英雄情结

其实少量的英雄主义对于整个团队来说是一件好事，可以提高团队的整体效率和竞争力。但是过于英雄主义或者是黑客的电影看多了可能会让项目引起不稳定的因素。

以过往的工作经验来看，出现在程序员的工作里面比较多，尤其是工作一两年的，或者是刚刚进去某个团队急于证明自己，甚至是工作很多年的， 主要表现在，没有合理的代码设计，有需求直接上代码。过渡自信的评估时间。只为自己而做，对于他人的工作漠不关心，也不会积极配合。

所以在之后的程序员面试中我往往都会问一些相关问题，例如，你有没有觉得过往公司的同事中谁的技术比较好？有没有从他那里学习到什么或者你觉得谁的代码设计比较给力？这样来看看对方的团队意识如何。

勇敢面对错误

迭代开发难免会有很多的问题，随时准备应对并解决各种问题的团队才是强大的。

解决问题的思维闭环：项目平稳进行 --> 问题出现 --> 认识到这确实是一个严重的错误 --> 冷静一下 --> 寻找问题处在哪里 --> 解决并上线 --> 问题不在出现 --> 项目平稳进行

尽量做到周期尽短，项目由平稳最终再到平稳的闭环，有必要的话最后开一个问题复盘会议。

最后，我们需注意的是，延期并不是否定自己的团队和自己付出的努力，PM应该带领大家复盘项目，总结项目经验。在下一个迭代周期不要有同样的错误发生，取得团队流程上的进步才是最重要的。