怎么排除计划中的“延期地雷”

不难发现，很多程序员是根本不做估算的，原因有很多，但总体来说，可以归结为一个原因：嫌麻烦。

一个程序员朋友曾经说过这样一段话：“我们是创业团队，领导一拍脑袋给个最后期限，时间差不多了我们就开干。如果到时候上不了线，我们就再加班呗！反正计划都是倒排的，估不估工作量，问题不大。”

问

为什么要做计划？

这种现象很普遍，那么，为啥一定要做计划呢？

在项目管理中，计划是贯穿项目始终的重要课题，是各个角色协同工作的基准。作为程序员，你在承担项目管理职责的时候，会有个特别明显的优势，就是对项目中涉及的架构设计、技术难点等问题，有非常深刻的理解，因此，你对技术类风险会有更高的把控力。

但是，你还需要从全局的视角出发，去推进项目整体目标的落地，优化各个角色的协同过程。作为项目经理，你要利用一切可以利用的资源、尽自己最大的努力达成项目目标，而计划是你可以借助的重要工具。

问

计划的本质是什么？

那么，计划到底是什么？计划是用来做什么的呢？

实际上，计划是“市场需求或发起人的期望”和“团队生产力”之间平衡的结果。从本质上来讲，计划是用来对焦的！做计划，是个集体对焦的过程。如果我们省去对焦的步骤，就会给后续的执行工作埋下很多“延期地雷”。在执行过程中，这些“延期地雷”一旦被引爆，就会把我们的项目拖向失控的深渊。

问

怎样清除“地雷”呢？

我们都知道，好的计划是成功的开始。但是，在做计划时，我们很容易遭遇一些雷区，下面我们就一起来了解应该如何正确应对雷区。

有个程序员朋友小勤，在得到领导提拔后升任项目经理，工作中突然多了很多困惑，尤其是在做计划时，她遇到了很多问题。现在，我们来看看她在做计划时遇到的典型问题。这些问题涉及5大常见雷区，希望通过下面雷区的分析，你能对导致计划失败的原因有更清晰的理解。

雷区1：不够具体

小勤的第一版计划是这样的：网课2.0升级项目计划于9月18日提测，10月1日正式上线。

你可能会说，这也太简单了吧？实际上，在程序员自己管理的项目中，这种一句话式的计划是很常见的。这份计划规定了提测和上线时间，也算是有了基本的约定。

但是，你可能忘记了计划的定义，计划是一种集体对焦的方式。好的计划，不仅要给出时间节点，还要给出依据和来源，这样才能更有效地对焦。

这里需要引入一个概念，叫做WBS（Work Breakdown Structure）工作分解结构，这是我们做计划的第一个标准动作。

作为一个描述思路的规划和设计工具，WBS可以清晰地表示各项目工作之间的相互联系，帮助团队高效地管理项目。

WBS是项目管理领域非常重要的方法。创建WBS的过程，也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程。

简单来说，WBS就是把大象放进冰箱的过程，在做计划的时候，我们要把“大象”，也就是我们要做的这件事情真正拆解开，明确到底分成多少块工作内容，涉及哪些角色和环节的工作项，你需要将工作项拆解到3个工作日以内，将每项任务都对应到个人。

在跟小勤沟通后，她很认真地做了改进，以下是她修改后的第二版计划。

从这份计划中，我们可以看到，小勤对开发任务进行了详细地拆解，每个人的工作都很明确。你觉得很好了，对不对？

不！这恰恰是计划中最容易忽视的一种延期地雷。这份计划，看似很详尽，实际上仍然是个任务的集合，没有办法指引我们有效地达成目标。

做计划的方式的转变，背后其实是思维方式的根本转变。小勤在做程序员时，她的目标就是完成开发任务。当她成为项目经理后，她本能地将设定目标默认为完成一堆开发任务。她还没有意识到，作为项目经理自己还需要做些什么。

雷区2：不够全面

项目管理是运用当前一切可用的资源，去完成整个项目目标。这份计划的最大问题是只有任务列表，没有识别关键资源和关键依赖，也没有考虑研发之外其他环节。这样的计划无法让我们明确实现目标的关键路径，也无法明确是否可以完成目标及如何完成目标。

识别依赖并画出关键路径是做计划的第二个标准动作，这一步意味着我们开始从目标的角度对资源进行统筹考虑。

关键路径是决定项目工期的进度活动序列。它是项目中最长的路径，关键路径的工期决定了整个项目的工期。所以，任何关键路径上的延迟都将直接影响项目的预期完成时间。

明确这一点之后，小勤又进一步调整了计划，下面这张图是小勤做的第三版计划。

从图中可以看出，小勤已经把工作流程中的先后依赖关系识别出来了，这样一来，关键路径也明确了，这份计划比较成型了。清晰了关键路径之后，我们要对其进行持续关注，把关键路径上的风险作为最高优先级应对。

除此之外，在核心部分计划出炉以后，我们还要对项目涉及的其他合作环节，进行全面的规划和安排，为各个阶段设定合理的里程碑节点，确保考虑周全。

听完建议后，小勤再一次改进了她的计划，把其他合作环节也明确地标注出来，如下图所示。

 

明确了和其他合作环节的时间节点后，建议使用 Visio 工具，把整个过程可视化出来，让计划更加直观。

雷区3：不够准确

修改过几轮计划之后，小勤对于日常排期越发驾轻就熟，她再一次来找我时，情况已经好了很多。不过，她又碰到了一些新问题。

排在首位的问题是，当计划在执行中出问题时，总是会产生很多纠纷，大多是因为大家对一些节点的定义理解不一致，比如什么叫提测，什么叫里程碑完成。

有一次还发生了“乌龙事件”，在项目临近上线时，开发的人跟她说：“拜托！我从来没说过 XX 号完成交付，我说的是 XX 号开发完，你去看看聊天记录！”这让她很难堪。

对小勤来讲，这时迫切要做的就是让时间节点的定义形成共同的标准。这就要引出做计划的第三个标准动作，定义完成标准。

简单地说，完成标准就是某时间点需要完成的事项列表，或者是应该达到的某项指标（特定水平的 Bug 数量 / 性能指标等）。进度计划中的任何重要时间节点，都应该有一组完成标准。越早定义完成标准，计划按照期望完成的概率就越大。

以最关键的几个常见时间节点为例，完成标准如下。

✤需求 / 设计确认：执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。值得一提的是，有些团队还会对需求稿或设计稿做一定的要求，比如把未处理的反馈意见数小于多少作为标准。

✤功能完成 / 提测：所有定义的功能都已经完成（比如冒烟测试通过率高于 90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作 Bug 来跟踪。基础比较好的团队，也可以把 CI 自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为细节具体的完成标准。

✤里程碑完成：质量已经达到适当水平（如不存在 P0 及 P1 优先级的 Bug），可以上线发布，或者可以开始下一个里程碑。

雷区4：没有共识

事先定义完成标准，就好比提前约法三章，让计划有更准确的指向作用。当我继续深挖小勤的烦恼之后，你会发现，她做计划还有个毛病，就是进度计划的文档只在她自己的电脑里，在执行计划的过程中，她只和几个开发人员口头说过，从来没有以任何公开的方式发布过，甚至都没有发邮件、公告等与全员同步信息，更别说开专门的规划会了。

她只是“做”了一份计划，而不是在“做计划”。这是个惊人的发现。

其实，做计划本身并不是最难的，真正难的是对焦！没有达成共识的计划，是不具备任何效力的。

事实上，项目经理在召开规划会之前，排期的内容已经准备得差不多了。在全员规划会上，除了对齐信息之外，更重要的是当面达成共识，这其实也是仪式感和承诺的象征，对计划后续的有效执行是至关重要的。因此，达成共识并公开透明，是做计划的第四个标准动作。

对于一些小项目，即便没有全员规划会，项目经理至少要在确认计划之后，向所有项目组成员包括项目的所有相关方发送计划邮件，正式周知，这可以尽早地发现共识的偏差。

雷区5：不够及时

计划就像冰箱里的酸奶，即时的才是有效的。虽然订计划是个谨慎的过程，但我们也需要看到，计划绝不是固定不变的。

在整个项目周期中，由于随时可能会出现变更，加上对估算的不断细化，做计划永远是个反复修正、渐进明晰的过程，我们要对计划进行持续的跟进与调整。

重要的是，每次进行调整都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策。而及时调整变更就是做计划的第五个标准动作。

需要注意的是，与进度计划有关的任何变更，都需要提交给项目管理人员，最好由团队中对应功能小组的成员及其他相关方共同讨论，明确计划变动可能对各方造成的影响，最终做出决策，并公开告知所有项目组成员。

总 结

以上做计划的五大雷区全部介绍完了，针对这些雷区，本文给出了做计划的 5 个标准动作：WBS 工作分解、识别依赖及各环节关键路径、定义完成标准、达成共识并公开透明、即时调整变更。

最后，针对雷区的特征，可用下面这张图片来总结一下好计划应该具有的特点。希望你在做计划时，能够对照下表进行梳理，以免埋下“延期地雷”。

项目管理学习资料合集需要的同学可留言