规划：排除计划中的“延期地雷”
我发现 ，有很多程序员是根本不做估算的。原因有很多 ，但总体来说 ，可以归结为⼀个：嫌⿇烦。 我的⼀个 程序员朋友曾经跟我说过这样⼀段话：“我们是创业团队 ，领导⼀拍脑袋给个deadline ，时间差不多了我们 就开⼲ 。如果到时候上不了线 ，我们就再加班呗！反正计划都是倒排的 ，估不估⼯作量 ，问题不⼤。 ”
这种现象很普遍 ，那么 ，为啥⼀定要做计划呢？
在项⽬管理中 ，计划是贯穿始终的重要课题，是各个⻆⾊协同⼯作的基准。程序员在做项⽬管理的时候 ，会 有个特别明显的优势 ，就是对项⽬中涉及到的架构设计、技术难点等问题 ，有着⾮常深刻的理解 ，因此 ，你 对技术类⻛险会有更⾼的把控⼒。
但是 ，你还需要学习的是 ，从全局的视⻆出发 ，去推进项⽬整体⽬标的落地 ，优化各个⻆⾊的协同过程。作 为项⽬经理 ，你要利⽤⼀切可以利⽤的资源、尽⾃⼰最⼤的努⼒达成项⽬⽬标 ，⽽计划是你可以借助的重要 ⼯具。
那么 ，计划到底是什么？ 计划是⽤来做什么的呢？
实际上 ，计划是“市场需求或发起⼈的期望”和“ 团队⽣产⼒ ”之间平衡的结果。从本质上来讲，计划是⽤来对焦的！做计划，是个集体对焦的过程。 如果我们省去对焦的步骤 ，就会给后续的执⾏⼯作埋下很多“地 雷”。在执⾏过程中 ，这些“地雷”⼀旦被引爆 ，就会把我们的项⽬拖向失控的深渊。
扫雷游戏
我们都知道 ，好的计划是成功的开始。但是 ，在做计划时 ，我们很容易遭遇⼀些雷区 ，下⾯我们就⼀起来玩 ⼀个“扫雷游戏”。
我有个程序员朋友⼩勤 ，她升任项⽬负责⼈之后 ，在⼯作中突然多了很多困惑 ，尤其是在做计划时 ，她遇到 了很多问题。现在 ，我就带你来看看她在做计划时遇到的典型问题。
这些问题涉及五⼤常⻅雷区 ，希望通过这些讨论 ，你能对导致计划失败的这五⼤雷区有更深刻的理解 ，提早 规避。
雷区1：不够具体
⼩勤的第⼀版计划是这样的：
⽹课2.0升级项⽬计划于9⽉18⽇提测 ，10⽉1⽇正式上线。
你可能会说 ，这也太简单了吧？ 实际上 ，在程序员⾃⼰管理的项⽬中 ，这种“⼀句话式” 的计划是很常⻅ 的。这份计划规定了提测和上线时间 ，也算是有了基本的约定。
但是 ，你还记得我们刚刚对计划的定义吗？ 计划是⼀种集体对焦的⽅式。好的计划，不仅要给出时间节点，还要给出依据和来源，这样才能更有效地对焦。
这⾥需要引⼊⼀个概念 ，叫作WBS⼯作分解（WorkBreakdownStructure），这是我们做计划的第⼀个标准动作。
作为⼀个描述思路的规划和设计⼯具 ，WBS可以清晰地表⽰各项⽬⼯作之间的相互联系 ，帮助团队更⾼效地 管理项⽬ 。
WBS是项⽬管理领域⾮常重要的⽅法。创建WBS的过程，也就是把项⽬⼯作按阶段可交付成果分解成较⼩的、更易于管理的组成部分的过程。
简单来说 ，WBS就是“把⼤象放进冰箱” 的过程 ，在做计划的时候 ，我们要把“⼤象” ，也就是我们要做的 这件事情真正拆解开 ，明确要分成多少块⼯作内容 ，涉及哪些⻆⾊和哪些环节的⼯作项 ，你需要将⼯作项拆 解到3个⼯作⽇以内 ，每项任务都对应到个⼈。
在跟⼩勤沟通好WBS之后 ，她很认真地做了改进 ，以下是她修改后的第⼆版计划：
从这份计划中 ，我们可以看到 ，⼩勤对开发任务进⾏了详细地拆解 ，每个⼈的⼯作都很明确。你觉得这样很 好了 ，对不对？
No！这恰恰是做计划时最容易忽视的⼀种“延期地雷”。这份计划 ，看似很详细 ，实际上仍然是个任务的 集合 ，没有办法指引我们有效地达到⽬标。
做计划的⽅式的转变，背后其实是思维⽅式的根本转变。⼩勤在做程序员的时候 ，她的⽬标就是完成开发任 务。但当她的职责扩⼤之后 ，她本能地将设定⽬标默认为完成⼀堆开发任务 ，她还没有意识到 ，作为项⽬负 责⼈ ，⾃⼰还需要做些什么。
雷区2：不够全⾯
我刚刚说过 ，项⽬管理是运⽤当前⼀切可⽤的资源 ，去完成整个项⽬⽬标。这份计划的最⼤问题就是 ，只有任务列表，没有识别关键资源和关键依赖，也没有考虑研发之外其他环节。这样的计划 ，⽆法让我们明确实 现⽬标的关键路径 ，也⽆法明确是否可以完成⽬标以及如何完成。
识别依赖并画出关键路径，就是我要讲的做计划的第⼆个标准动作，这⼀步意味着我们开始从⽬标的⻆度对资源进⾏统筹思考。
关键路径是决定项⽬⼯期的进度活动序列。 它是项⽬中最⻓的路径 ，关键路径的⼯期决定了整个项⽬的⼯ 期。所以 ，任何关键路径上的延迟都将直接影响项⽬的预期完成时间。
明确了这⼀点之后 ，⼩勤⼜进⼀步调整了计划 ，我们来看看⼩勤做的第三版计划。
从图中可以看出 ，⼩勤已经把⼯作流中的先后依赖关系识别出来了 ，这样⼀来 ，关键路径也明确了 ，这份计 划总算有个模样了。清晰了关键路径之后 ，我们要对其进⾏持续关注 ，把关键路径上的⻛险作为最⾼优先级 应对。
除此之外 ，在核⼼部分计划出炉以后 ，我们还要对项⽬涉及到的其他合作环节 ，进⾏全⾯地规划和安排 ，为 各个阶段设定合理的⾥程碑节点 ，确保考虑周全。
听完我的建议之后 ，⼩勤再⼀次改进了她的计划 ，把其他合作环节也明确地标注出来了 ，如图所⽰：
明确了和其他合作环节的时间节点之后 ，我建议你使⽤Visio⼯具 ，把整个过程可视化出来 ，让计划更加直 观。
雷区3：不够准确
修改过⼏轮计划之后 ，⼩勤对于⽇常排期越发驾轻就熟。她再⼀次来找我时 ，情况已经好了很多。不过 ，她 ⼜碰到了⼀些新问题。
排在⾸位的是 ，当计划在执⾏中出问题的时候 ，总是会产⽣很多纠纷 ，⼤多是因为⼤家对⼀些节点的定义理 解不⼀致 ，⽐如什么叫提测 ，什么叫⾥程碑完成。
有⼀次还发⽣了“乌⻰事件”。在临近上线时 ，开发同学跟她说：“拜托！我从来没说过XX号完成交付，
我说的是XX号开发完 ，你去看看聊天记录！”这让她很是难堪。
对⼩勤来讲 ，这时迫切要做的 ，就是让节点的定义形成共同的标准。这就要引出做计划的第三个标准动作了，就是定义完成标准。
简单来讲 ，完成标准就是某时间点需要完成的事项列表 ，或者是应该达到的某项指标（特定⽔平的Bug数 量/性能指标等）。进度计划中的任何重要时间节点 ，都应该有⼀组完成标准。越早定义完成标准，计划按照期望完成的概率就越⼤。
以最关键的⼏个常⻅时间节点为例 ，完成标准如下：
需求/设计确认：执⾏所需的需求稿或设计稿已经完成 ，⽽且公开评审通过 ，团队已经准备好要编写产品 代码了。值得⼀提的是 ，有些团队还会对需求稿或设计稿做⼀定的要求 ，⽐如把未处理的反馈意⻅数⼩于 多少作为标准。
功能完成/提测：所有定义的功能都已经完成（⽐如冒烟测试通过率⾼于90%） ，团队已经准备好将焦点 转移到质量保证上 ，并将所有剩余问题都当作Bug来跟踪。⼀些质量基础⽐较好的团队 ，也可以把CI⾃动 回归⽤例集通过率、静态代码检查分数、单元测试覆盖率等 ，作为更加细节具体的完成标准。
⾥程碑完成：质量已经达到适当⽔平（如不存在P0及P1优先级的Bug） ，可以上线发布 ，或者可以开始 下⼀个⾥程碑。
雷区4：没有共识
事先定义完成标准 ，就好⽐提前约法三章 ，会让计划有更准确的指向作⽤ 。 当我继续深挖⼩勤的烦恼之后 ， 我发现 ，她做计划还有个⽑病 ，就是进度计划的⽂档只在她⾃⼰的电脑⾥ ，在执⾏计划的过程中 ，她只和⼏ 个开发⼝头说过 ，从来没有以任何公开的⽅式发布过 ，甚⾄都没有发邮件、公告等与全员同步信息 ，更别说 开专⻔的规划会了。
她只是“做” 了⼀份计划 ，⽽不是在“做计划”。这真是个惊⼈的发现。
其实 ，做计划本⾝并不是最难的 ，真正难的是什么？ 对焦！没有达成共识的计划，是不具备任何效⼒的。
事实上 ，PM在召开规划会之前 ，排期的内容已经准备得差不多了。在全员规划会上 ，除了对⻬信息之外， 更重要的是当⾯达成共识 ，这其实也是仪式感和承诺的象征 ，对计划后续的有效执⾏ ，是⾄关重要的。 因 此 ，达成共识并公开透明，就是做计划的第四个标准动作。
对于⼀些⼩项⽬ ，即便没有全员规划会 ，我也强烈建议你⾄少要在确认计划之后 ，向所有项⽬组成员 ，包括 项⽬的所有⼲系⼈ ，发送计划邮件 ，正式周知 ，这可以尽早地发现共识的偏差。
雷区5：不够即时
计划就像冰箱⾥的酸奶 ，即时的 ，才是有效的。 虽然定计划是个谨慎的过程 ，但我们也需要看到 ，计划绝不 是固定不变的。
在整个项⽬周期中 ，由于随时会可能出现变更 ，加上对估算的不断细化 ，做计划永远是个反复修正、渐进明 晰的过程 ，我们要对计划进⾏持续地跟进与调整。重要的是，每⼀次进⾏调整，都要确保项⽬中的每个⼈知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策。 ⽽及时调整变更，就是做计划的第五个标准动作。
你需要注意的是 ，与进度计划有关的任何变更 ，都需要提交给项⽬管理⼈员 ，最好由团队中对应功能⼩组的 成员（该功能模块涉及的策划、设计、开发、测试）及其他相关⼲系⽅共同讨论 ，明确计划变动可能对各⽅ 造成的影响 ，最终做出决策 ，并公开告知所有项⽬组成员。
总结
好了 ，做计划的五⼤雷区我都介绍完了 ，针对这些雷区 ，我给出了做计划的5个标准动作 ，分别是WBS⼯作分解 ，识别依赖及各环节关键路径 ，定义完成标准 ，达成共识并公开透明 ，即时调整变更。 最后 ，针对雷区 的特征 ，我⽤⼀张图⽚来总结⼀下好计划应该具有的特点。希望你在做计划时 ，能够对照着下表进⾏梳理 ， 以免埋下“延期地雷”。
