项目延期在产品经理的工作生涯中是再常见不过的问题，但延期意味着某项环节出现问题，对后续的运营等动作也会有影响。如何能尽量避免项目延期呢？本文对此进行了分析，希望对你有帮助。
一、项目为什么容易延期？
1. 软件研发是一项创造性工作
项目延期是一种普遍现象，管理者最为头疼的一个问题。但是外人并不理解。明明是你们自己做的计划，怎么总会出现这么多问题。说到底，这是由于我们的工作特性决定的。我们做的是一个创造性的工作，他不像建房子，有特定的步骤。我们实现一个功能，怎么写，有多少行代码，我们在写之前是不知道的。
基于我自己的经验，我觉得项目延期还有以下两个方面的原因：
2. 工作中的突发事件多
我们在评估工作量的时候，都是基于过往的经验。这种经验性评估在真实环境中并不可靠，你无法应对突发问题，而我们真实开发的过程中突发问题太多了。
3. 协作之间的耦合性高
技术人员工作的耦合性太高。从最开始产品经理提出需求、UI设计原型、UE设计体验、程序员做系统设计，写代码、测试人员编写测试用例。环环相扣，其中一个环节出了“意外”，时间就得往后延。
二、工作中常见的延期原因
我这里列了工作中常见的延期原因：
- 需求变更，一般指新增需求或者需求细节一直在变；
- 需求评估的工作量不足，低估了功能实现的难度；
- 需求理解不对，功能做错了。等最后测试或对接的时候才发现；
- 有临时需求插入。比如线上突然出现了一个bug，需要修复；
- 新需求本身存在逻辑问题，做之前都没发现，在做的过程中才发现。
- 自测不仔细，测试发现问题太多，bug越改越多；
- 临时人员变动；
- 偏离计划后没有做好应对措施；
- 技术难点调研出了问题，实现方案得改；
- ……
那是不是我们就没办法了呢？也并不是。方法总比问题多，只要所有出现的问题都有应对方案，准时上线也是可能的。当然面对复杂问题，想一次性解决很难，但好在我们可以迭代。每一次项目结束都应该对项目做一次复盘。
三、如何解决项目延期问题？
这是我应对项目延期的解决方案：复盘 —— 找问题 —— 拆解问题 —— 制定解决方案 —— 迭代 —— 复盘。
1. 复盘，找问题
复盘：上一次我们延期的原因是什么？把问题原因找出来。比如上次是需求变动导致的。
2. 拆解问题，制定解决方案
接着就是拆解问题。为什么需要变动？因为这个功能更重要。这是答案是真的吗？这个功能真的很重要吗？好，是真的。那么评判标准是什么？如果没有。那么我需要制定出来。有了标准，下次遇到新增需求，我们就能很快决定是否加入到这个版本里。好，我们还可以继续拆，是新增需求导致的延期？对，因为新增需求而且并没有修改上线时间。那我们下一次面对新增需求是不是可以对外争取更长一点的开发时间？
这个方法的优点是，每次进步都能感受的到。缺点是，时间周期太长。但好在，我们别人的经验是可以学习的。别人趟过的坑，我们没有必要再趟一次。
四、解决项目延期的关键三要素
基于我多年的项目管理经验，我认为要解决项目延期问题，必须做好三件事。
1. 项目开始前：需求管理
项目开始前的需求管理有四个关键步骤。
1）达成需求优先级排序的共识
首先，我们要达成给需求优先级排序的一个共识。什么样的需求是最重要的，一定要完成的？每个公司可能不一样。我自己是基于商业价值和用户价值两个维度来排序的。
商业价值，就是那些直接给公司带来利润，能够降低运营成本、完成公司长期战略目标等功能。而用户价值是，那些能够提升用户体验、提高用户使用效率，解决用户痛点问题的功能。
基于这两个维度，我们可以画一个四象限图，把我们所有的需求按照商业价值、用户价值两个维度给归类到不同象限里。对于商业价值高、用户价值高的产品。我们应该马上去做。至于优先级排第二的是商业价值高、用户价值低的需求；还是商业价值低、用户价值高的需求，要根据公司实际情况来定。
为什么要给需求分优先级？时间有限，要做的功能太多。如果根据商业价值和用户价值拆解后，还有很多需求，我们还可以继续用重要紧急两个维度来拆。
2）弄清楚需求的目的
达成了共识后，第二步就是在需求评审时，要求产品先讲解需求的目的。不只是说明我们要做什么，还要说明我们要达到什么目标。这样做有两个好处。
让所有人参与其中，发挥团队所有人的价值，通过集体共创可以获得更好的解决方案。
在事后，我们可以很清晰的看到，我们做的功能是不是往目标更前进了一步。如果没有。那么复盘的时候，能更有指向性的去找问题的原因。
3）弄清楚需求细节
第三步，就是开发者需要弄清楚需求细节。每一个开发人员都应该养成这样一个看透细节的能力。
代码的世界里只有0和1，没有随便。产品在给我们讲需求的时候，并不知道系统的具体实现。有些细节他也不知道。这会导致很多需求在做的过程中有很多细节需要反复确认，如果做的不好，很多细节问题都会在测试的时候体现出来。
举个例子，当产品说我们这次做一个活动，用户下单满29包邮。看起来很简单的一个需求，但如果你系统足够复杂，开发人员应该要想到，跨店的情况怎么办？含虚拟商品怎么办？如果店家设置了其他活动，冲突了怎么办？需求后期会不会变成49包邮？如果这些在评审的时候没有想到，那么在做的过程中一定要和产品保持沟通。有些新人刚来的时候不好意思问，其实没啥，每个人都是这么过来的。这种能力是需要时间积累的。
需求理清了也有两个好处：
评估的工作量会跟精准。
更早的发现需求里潜藏的问题。
4）输出完整的项目上线计划表
第四步，就是上下同步需求，生成需求计划表。首先我们拆解需求，大需求变成小需求。然后评估小需求的工作量。输出自己的个人计划表。然后部门内部整合需求，输出部门的计划完成表。最后是与团队其他成员生成整体的项目计划表。一般会做成甘特图。这样在做的过程中更容易发现问题。
异常情况：
这四个关键步骤，说起来简单，但要真正做好不容易。如果能做到，那需求管理基本不会存在大的问题了。当然也会有一些异常情况。比如需求确定后，能不能变动？一般需求确定下来后，最好不要做临时变动。除非特殊情况。
那什么是特殊情况？这就是制定需求优先级规则的好处了，如果确实有更紧急、成本低的高商业价值、高用户价值的需求。我们可以变动。只要团队内成员都认可这个规则，做需求变动就会比较好实施。
那如果是领导不按规则变动需求怎么办？
谁担责谁决策。因为站的角度不一样，我们认为的高价值任务不一定对。这是一条职场通用原则，在需求确定做不做之前，作为项目组成员，你可以表达自己的建议，但如果最终负责人拍板要做，那就坚决执行。
2. 项目开始中：过程管理
过程管理的关键是要解决信息不同步的问题。我的解决方案是：
1）每天都开站立晨会
很多人说早上开晨会没有用，是管理者没有其他办法，只能通过会议来推进工作的一种表现。我倒不觉得，晨会并不复杂，也不会花费很多时间，但正是因为有了这样一个固定”沟通“事项，每个人心里都会想着这件事，自然会把当下的工作按计划推进。这里我介绍一下我公司开站立晨会的具体步骤：
首先团队之间达成共识。明确晨会的目的是协同，而非汇报。每个人时间就2分钟。控制发言时间。
确定汇报的内容。每个人讲讲当天的计划和实际进度是否一致。是否遇到了什么问题，是否需要什么支持。
固定发言顺序，发言过程中，其他人不评论，不解答。具体的问题等到会后在找相关人员一起讨论。
晨会的主持人很关键，他需要控制流程和时间，对于偏离主题的发言要给予提醒。
最后就是要做会议纪要，只记录某人遇到的问题或请求以及整个项目的进度是否正常。
开会时间推荐在正式上班时间30分钟后，比如9点上班。9点30开始。10点前结束。备注：我公司弹性上班可以9点半到公司。
晨会能很好的解决团队内部信息不对称的问题，大家能更好地了解到彼此的项目进度并做好配合。而且人都要面子的，如果自己制定的计划未完成，还要自己当众说出来没按计划完成的原因，是很有压力的，这种压力会在潜意识里影响到自己每天任务的完成度以及专注度。
很多公司把晨会开成了汇报会，最后就变成了一个没有太多信息量的务虚会议。并不是这个工具不好用，而是你没有用对方法。记住上面我说的几个原则，相信你能组织好一场适合团队的晨会。
2）如果是跨部门协作，每日要进行“对表”
如果是跨部门协作。我们每天也要进行”对表“，也就是同步信息。
3）关键节点的跟进
千万不要等到上线了在来看项目进展，这样即使发现问题，你也没有时间来解决。
4）制定异常问题的处理机制
所有的异常情况，都需要设计一个应对的应对方案，有了应对方案，至少解决问题的流程有了，心理就不会慌。解决起来就容易很多。
5）建立自己的问题清单库
很多大公司都有这样一个产品问题清单库。客服同事在处理用户问题时候，通过关键字搜索就能找到通用的解决方案。这极大地提高了客服处理问题的效率。同样的方式其实也可以用在开发上。也许很久之前某个同事遇到的问题，其他同事也能遇到。这种情况下，通过关键字搜索，原来要花半天才能解决的问题，可能一分钟就给解决了。需要注意的是在做这个问题清单库的时候，一定要先定义好格式。这样才好管理。
那是不是做到上面这些就能保证项目能准时上线了？也不一定。因为这里面最关键的是执行的人。人的管理是一门艺术。这里以后再详细讲。
3. 项目结束后：对项目做复盘
复盘会：全员参与。
做的好的，要想办法将其标准化、可复制。
做的不好的，要想办法制定应对的方案。
五、防止项目延期的几个方案
最后，说一下我在防止项目延期上的个人经验。
1. 大项目要分阶段转测试
不要把测试和设计工作都集中在一个时间段。版本迭代的时长也不要超过一个月。
2. 预留测试时间
开发人员每次做完一个任务后，都要预留测试时间。同时和开发人员要达成一个共识，如果开过程中出现延期，要自己通过加班时间赶上进度，不能影响其他同事的进度。
3. 制定常见异常情况的处理标准
也就是最开始讲到的，如果真的有需求变更，那么就一定要做好变更需求的标准。需求可以变，变了之后如何处理。这个也需要明确。有些是可以直接放到版本里通过加班解决，有些可以舍弃掉一些需求。尽量不在要发布的时候做变更。
4. 做好PLAN B计划
遇到一些突发时间的预案是什么。比如有人员临时请求，怎么办？有技术难点攻克不了怎么办？作为管理者需要提前想好备选方案。
5. 制定两个发布计划
一个计划是对内的，根据大家工作计划整合之后的发布时间，还有一个是对外上线的计划。我们团队要追求对内时间上线。但如果出现问题，预留出的时间就是我们的缓冲带。当然也可以对外给出一个模糊的上线时间，比如对内9月10号上线，对外9月中旬上线。
以上，是应对项目延期的一些经验。希望给大家带来一些启发。
