下载APP
关闭
讲堂
算法训练营
企业服务
极客商城
客户端下载
兑换中心
渠道合作
推荐作者
05 | 规划：排除计划中的“延期地雷”
2019-11-07 雷蓓蓓
项目管理实战20讲
进入课程
讲述：雷蓓蓓
时长13:55大小12.76M
你好，我是雷蓓蓓。今天，我们来聊一聊如何排除计划中的“延期地雷”。
我发现，有很多程序员是根本不做估算的。原因有很多，但总体来说，可以归结为一个：嫌麻烦。我的一个程序员朋友曾经跟我说过这样一段话：“我们是创业团队，领导一拍脑袋给个 deadline，时间差不多了我们就开干。如果到时候上不了线，我们就再加班呗！反正计划都是倒排的，估不估工作量，问题不大。”
这种现象很普遍，那么，为啥一定要做计划呢？
在项目管理中，计划是贯穿始终的重要课题，是各个角色协同工作的基准。程序员在做项目管理的时候，会有个特别明显的优势，就是对项目中涉及到的架构设计、技术难点等问题，有着非常深刻的理解，因此，你对技术类风险会有更高的把控力。
但是，你还需要学习的是，从全局的视角出发，去推进项目整体目标的落地，优化各个角色的协同过程。作为项目经理，你要利用一切可以利用的资源、尽自己最大的努力达成项目目标，而计划是你可以借助的重要工具。
那么，计划到底是什么？计划是用来做什么的呢？
实际上，计划是“市场需求或发起人的期望”和“团队生产力”之间平衡的结果。从本质上来讲，计划是用来对焦的！做计划，是个集体对焦的过程。如果我们省去对焦的步骤，就会给后续的执行工作埋下很多“地雷”。在执行过程中，这些“地雷”一旦被引爆，就会把我们的项目拖向失控的深渊。
扫雷游戏
我们都知道，好的计划是成功的开始。但是，在做计划时，我们很容易遭遇一些雷区，下面我们就一起来玩一个“扫雷游戏”。
我有个程序员朋友小勤，她升任项目负责人之后，在工作中突然多了很多困惑，尤其是在做计划时，她遇到了很多问题。现在，我就带你来看看她在做计划时遇到的典型问题。
这些问题涉及五大常见雷区，希望通过这些讨论，你能对导致计划失败的这五大雷区有更深刻的理解，提早规避。
雷区 1：不够具体
小勤的第一版计划是这样的：
网课 2.0 升级项目计划于 9 月 18 日提测，10 月 1 日正式上线。
你可能会说，这也太简单了吧？实际上，在程序员自己管理的项目中，这种“一句话式”的计划是很常见的。这份计划规定了提测和上线时间，也算是有了基本的约定。
但是，你还记得我们刚刚对计划的定义吗？计划是一种集体对焦的方式。好的计划，不仅要给出时间节点，还要给出依据和来源，这样才能更有效地对焦。
这里需要引入一个概念，叫作 WBS 工作分解（Work Breakdown Structure），这是我们做计划的第一个标准动作。
作为一个描述思路的规划和设计工具，WBS 可以清晰地表示各项目工作之间的相互联系，帮助团队更高效地管理项目。
WBS 是项目管理领域非常重要的方法。创建 WBS 的过程，也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程。
简单来说，WBS 就是“把大象放进冰箱”的过程，在做计划的时候，我们要把“大象”，也就是我们要做的这件事情真正拆解开，明确要分成多少块工作内容，涉及哪些角色和哪些环节的工作项，你需要将工作项拆解到 3 个工作日以内，每项任务都对应到个人。
在跟小勤沟通好 WBS 之后，她很认真地做了改进，以下是她修改后的第二版计划：
从这份计划中，我们可以看到，小勤对开发任务进行了详细地拆解，每个人的工作都很明确。你觉得这样很好了，对不对？
No！这恰恰是做计划时最容易忽视的一种“延期地雷”。这份计划，看似很详细，实际上仍然是个任务的集合，没有办法指引我们有效地达到目标。
做计划的方式的转变，背后其实是思维方式的根本转变。小勤在做程序员的时候，她的目标就是完成开发任务。但当她的职责扩大之后，她本能地将设定目标默认为完成一堆开发任务，她还没有意识到，作为项目负责人，自己还需要做些什么。
雷区 2：不够全面
我刚刚说过，项目管理是运用当前一切可用的资源，去完成整个项目目标。这份计划的最大问题就是，只有任务列表，没有识别关键资源和关键依赖，也没有考虑研发之外其他环节。这样的计划，无法让我们明确实现目标的关键路径，也无法明确是否可以完成目标以及如何完成。
识别依赖并画出关键路径，就是我要讲的做计划的第二个标准动作，这一步意味着我们开始从目标的角度对资源进行统筹思考。
关键路径是决定项目工期的进度活动序列。它是项目中最长的路径，关键路径的工期决定了整个项目的工期。所以，任何关键路径上的延迟都将直接影响项目的预期完成时间。
明确了这一点之后，小勤又进一步调整了计划，我们来看看小勤做的第三版计划。
从图中可以看出，小勤已经把工作流中的先后依赖关系识别出来了，这样一来，关键路径也明确了，这份计划总算有个模样了。清晰了关键路径之后，我们要对其进行持续关注，把关键路径上的风险作为最高优先级应对。
除此之外，在核心部分计划出炉以后，我们还要对项目涉及到的其他合作环节，进行全面地规划和安排，为各个阶段设定合理的里程碑节点，确保考虑周全。
听完我的建议之后，小勤再一次改进了她的计划，把其他合作环节也明确地标注出来了，如图所示：
明确了和其他合作环节的时间节点之后，我建议你使用 Visio 工具，把整个过程可视化出来，让计划更加直观。
雷区 3：不够准确
修改过几轮计划之后，小勤对于日常排期越发驾轻就熟。她再一次来找我时，情况已经好了很多。不过，她又碰到了一些新问题。
排在首位的是，当计划在执行中出问题的时候，总是会产生很多纠纷，大多是因为大家对一些节点的定义理解不一致，比如什么叫提测，什么叫里程碑完成。
有一次还发生了“乌龙事件”。在临近上线时，开发同学跟她说：“拜托！我从来没说过 XX 号完成交付，我说的是 XX 号开发完，你去看看聊天记录！”这让她很是难堪。
对小勤来讲，这时迫切要做的，就是让节点的定义形成共同的标准。这就要引出做计划的第三个标准动作了，就是定义完成标准。
简单来讲，完成标准就是某时间点需要完成的事项列表，或者是应该达到的某项指标（特定水平的 Bug 数量 / 性能指标等）。进度计划中的任何重要时间节点，都应该有一组完成标准。越早定义完成标准，计划按照期望完成的概率就越大。
以最关键的几个常见时间节点为例，完成标准如下：
需求 / 设计确认：执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。值得一提的是，有些团队还会对需求稿或设计稿做一定的要求，比如把未处理的反馈意见数小于多少作为标准。
功能完成 / 提测：所有定义的功能都已经完成（比如冒烟测试通过率高于 90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作 Bug 来跟踪。一些质量基础比较好的团队，也可以把 CI 自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为更加细节具体的完成标准。
里程碑完成：质量已经达到适当水平（如不存在 P0 及 P1 优先级的 Bug），可以上线发布，或者可以开始下一个里程碑。
雷区 4：没有共识
事先定义完成标准，就好比提前约法三章，会让计划有更准确的指向作用。当我继续深挖小勤的烦恼之后，我发现，她做计划还有个毛病，就是进度计划的文档只在她自己的电脑里，在执行计划的过程中，她只和几个开发口头说过，从来没有以任何公开的方式发布过，甚至都没有发邮件、公告等与全员同步信息，更别说开专门的规划会了。
她只是“做”了一份计划，而不是在“做计划”。这真是个惊人的发现。
其实，做计划本身并不是最难的，真正难的是什么？对焦！没有达成共识的计划，是不具备任何效力的。
事实上，PM 在召开规划会之前，排期的内容已经准备得差不多了。在全员规划会上，除了对齐信息之外，更重要的是当面达成共识，这其实也是仪式感和承诺的象征，对计划后续的有效执行，是至关重要的。因此，达成共识并公开透明，就是做计划的第四个标准动作。
对于一些小项目，即便没有全员规划会，我也强烈建议你至少要在确认计划之后，向所有项目组成员，包括项目的所有干系人，发送计划邮件，正式周知，这可以尽早地发现共识的偏差。
雷区 5：不够即时
计划就像冰箱里的酸奶，即时的，才是有效的。虽然定计划是个谨慎的过程，但我们也需要看到，计划绝不是固定不变的。
在整个项目周期中，由于随时会可能出现变更，加上对估算的不断细化，做计划永远是个反复修正、渐进明晰的过程，我们要对计划进行持续地跟进与调整。重要的是，每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策。而及时调整变更，就是做计划的第五个标准动作。
你需要注意的是，与进度计划有关的任何变更，都需要提交给项目管理人员，最好由团队中对应功能小组的成员（该功能模块涉及的策划、设计、开发、测试）及其他相关干系方共同讨论，明确计划变动可能对各方造成的影响，最终做出决策，并公开告知所有项目组成员。
总结
好了，做计划的五大雷区我都介绍完了，针对这些雷区，我给出了做计划的 5 个标准动作，分别是 WBS 工作分解，识别依赖及各环节关键路径，定义完成标准，达成共识并公开透明，即时调整变更。最后，针对雷区的特征，我用一张图片来总结一下好计划应该具有的特点。希望你在做计划时，能够对照着下表进行梳理，以免埋下“延期地雷”。
畅所欲言
如果你是我在这一讲开头提到的那位创业团队的程序员，你被老板要求倒排时间，你会怎么办？请尝试运用今天所学的知识，梳理一下自己的行动方案。
欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
04 | 启动：识别项目中的四类干系人
下一篇
06 | 执行：打造品质，要从头开始“闭环”
写留言
精选留言(29)
2019-11-07估计那位兄台的公司这么干下去，创业成功率堪忧…
好歹画个甘特图，列个里程碑，拍脑袋也得给关键的衔接定个流转的标准，如果能量化那就是极好的了，记得把大家聚一块，为的是上面这些事儿说清楚了，立头名状歃血为盟做不到好歹邮件标清楚了留个底儿，别跟海峡两岸一中各表到时候再扯就扯不清了.....．然后还得经常的盯着点，有谁那有变化得让大家伙儿都知道了，有必要改调就得调
另外觉的老师对焦这个概念用的特别传神…正是这些词汇的巧妙运用，使得老师讲解的非常到位，加上音色又美，更是由衷感谢
听老师的课，平静，舒心，有收获…这剧追的值展开作者回复: 你给了经典的通俗演义版，比我讲的好！哈哈
2 3
2019-11-07我公司的计划就是任务列表，在共识，公开透明，即时做得欠缺，老师今天的讲解让我豁然开朗，马上去买网易一千零一夜。😀展开作者回复: 感谢支持！
2
2019-11-07倒排时间在很多公司是很常见的，所以避无可避。首先我们要判断的是倒排的时间是不是合理的控制范围内，其次要明确项目的整体诉求，对其做一个基本规划，而在这个阶段最忌讳的是马上动手开发，我们都知道磨刀不误砍柴工，前期准备越充足，后期出问题后付出的代价就越小，把可控的时间周期做里程碑分解，项目明确各交付结点，后面我们要做风险的监控，进度的监控，确保在出现影响进度的情况下能快速响应与解决。展开作者回复: 棒！
2
2019-11-07如果被要求倒排计划，按照5个标准动作的话，我理解不一定有先后顺序，我会
1. 先宣贯一下项目完成标准；
2. 再统一共识，宣贯项目配置管理，做到资料共享机制；
3. 把需求按照WBS进行分解，这里有个疑问，是不是每个子任务的工时都不要超过3天呢？？？
4. 根据分解出来的任务，识别出关键路径；
5. 做好变更的整理和及时通知变更。展开 2
2019-11-07哇，老师太厉害了。
内容都是直指根源，用专业并且易懂的名词阐述了完整的主题，真是专业的人做的专业的事。
在极客时间上的程序员我估计以开发的较多，PM的估计没几个，我们这些开发的都是学而优则仕的被赶鸭子似的被推到team主管位置，全面负责开发和项目管理的工作，我以前做计划还真的是一句话的总结就搞定了，因为实在不知道怎么列计划，即使老板要求详细点，也只能列出来第二版那种，看完今天的内容，才知道一份合格的计划应该是怎样的，感谢。展开作者回复: 谢谢！读你的评论，超有能量，你能学以致用就是对我最大的鼓励。
2
2019-11-07思考题：
先明确要达到的目标，质量、效果、时间
然后针对要完成的效果进行工作拆分，找出关键路径，根据质量和时间要求跟对应任务的成员确定完成的标准，将整个规划整理好后组织评审会议，在项目进行中有问题及时处理和同步展开作者回复: 鼓励下深夜学习的好同学！
2
2019-11-07文稿中给出的例子是个典型的原型。如果项目是迭代或者增量，就可以把这个原型套用到一个个子任务中，这么宝贵的财富再加上老师动听的声音，这课太值了。展开作者回复: 谢谢🙏
1
2019-11-10老师好，想知道小勤第3版的计划是用什么软件做的～
另，吹爆一千零一夜，真的好看，作者回复: visio哈，谢谢🙏
1
2019-11-10讲得真好，做为一名开发，看了也很有感觉，结合自己的项目经历加上老师的讲解，整理了一下自己方法论：
1.任务分解：WBS（Work Breakdown Structure），把项目中的任务分解为原子粒度大小，并明确评估出工时
2.只有具体的任务分解是不够的，需要识别出项目依赖的资源，以及项目的关键节点。所以，需要在任务分解的基础上，形成关键路径。第一步和第二步，可以借助ominiplan工具
3.根据关键路径，需要产出里程碑或者鱼骨图。明确各个时间节点，比如开发开始（结束）时间、提测时间等
4.定义标准，为避免共同做项目的同学对节点等定义的歧义，需要明确标注。比如，达到什么的标准，才符合提测的定义。【这个是避免项目中互相扯皮比较重要的一步】
5.没有达成共识的计划，是不具备任何效力的。在确认计划之后，向所有项目组成员，包括项目的所有干系人，发送计划邮件，正式周知
6.在整个项目周期中，由于随时会可能出现变更，加上对估算的不断细化，做计划永远是个反复修正、渐进明晰的过程，我们要对计划进行持续地跟进与调整。重要的是，每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策。展开作者回复: 很棒的总结，记得学以致用哦
2019-11-091. 项目经理需要懂技术吗？
2. 如果一个项目比较大，是需要一个总项目经理和几个分部项目经理来管理吗？比如，开发一个智能电子设备，涉及到结构设计、硬件、固件、UI设计、app、以及工厂的试产等等，直到完成样品给客户送样并用app使用测试通过，项目才算完成，这种大型项目怎样进行项目管理比较好？是一两个部分配一个项目经理，来合作，还是分配一个项目总经理来协调处理呢？比如，硬件和结构设计一个人负责，固件和app另一个人负责。展开- 2019-11-09我觉得计划与我,就如同小勤的第一版一般简陋。
这一讲我反复听了6遍，直到第5遍才有点明悟，计划与我是一件困难的事情
但是从小勤的改进步骤，我可以看出我也许可以与小勤一样，先做第一版在优化至最终版
1、 先标出重点，如开发完成时间（包括单元测试），提测时间，上线时间
2，分解出开发任务项
3，标注出依赖，以及关键路径，和合作环节节点
4，定义计划中术语的含义，最好开一场公布会澄清术语所代表的含义
5，即时更新计划，以及更新之后即时发布计划，加强沟通反馈。
我曾听过一个说法，大会议是用来同步信息的，而商讨解决方案只要几个关键人在一起做出决策展开作者回复: 好认真！说的很棒，尽量开小会，开短会，开有准备的会。
1 
2019-11-09这期的干货不错。展开
2019-11-09目前团队的计划表就是按功能进行分割的排期，相互之间的依赖关系非常模糊。大家对整体路径并没有概念，进度控制就靠项目经理人盯人展开
2019-11-09感觉小勤的计划表里，没有对某个具体任务的详设，coding，单元测试的时间做具体区分。任务还是不够原子化。展开作者回复: 嗯，没错，目前是从可交付工作包的角度在拆，还不是原子任务
3
2019-11-08谢谢蓓蓓老师的讲解，很详细，也解决了很多做计划中的疑惑。另外，想请教蓓蓓老师两个疑问：
1、计划变更的时候难免会影响到各个里程碑的时间节点，而节点变更通常又意味着项目延期。变更的主观因素影响力又较强，这会不会引起两种结果：一是影响项目组成果；二通过变更使延期“合法化”。
2、计划表中的前置任务什么意思？怎么计算呢？展开
2019-11-08感谢雷姐的讲解有点豁然的感觉，我这里有个问题，我是个开发，如果我现在在做一个功能，策划找我对功能和给出进度的时间，那我之前为了完成马上完成手头的工作，就根据经验随便给了个时间，并没有考虑依赖路径和具体细节，导致给的时间表及其不准确，可是如果我要花时间给出进度的话，那务必耽误我手头的工作导致功能延期，这个怎么解决呢，还有我有时候忙着手里的活，老有人找我解决其他问题，耽误我的功能开发，这个又怎么办？展开 1
2019-11-08我理解所谓倒排时间，本质上与项目管理流程是不冲突的，只不过是在任务分解的时候，需要根据时间倒排每个任务的时间，其它的保持不变展开
2019-11-08虽然没有那么多人协作，制定规划多数时间都是给领导看下，剩下都是自我督促的一个工具，让自己开发上线有个计划，可以对整体时间有一个把控。当初有总监让我写立项，很多上边涉及的内容都觉得没什么用，不过听完你讲的视乎渐渐理解了很多。原来写完立项或问题确认，都让我发邮件确认，我开始不理解为什么不过去直接问，他说这回头有证据可以甩锅，今天再结合你讲的，应该是达成共识，跟免责声明似的。展开
2019-11-07雷老师：两个问题烦请解答下
1：关键路径是什么意思，是分配给每人的时间周期吗？
2：当项目进度出现问题存在延期，wbs表要随时更改吗？那以前的计划排期还需要吗？如果需要在哪里查看？展开作者回复: 关键路径，就是项目计划整体梳理下来，从开头到结尾，时间最长的那条路径，这条路径决定了整个项目的工期。
以前的计划需要存档，文档系统中各个版本的计划， 应是可查可追溯的。 2- 2019-11-07蓓蓓老师好，我是做项目群管理的，一个项目管理初学者。一个项目可以用project做计划，40多个并行的项目一块管理的话，有没有好的工具可以推荐？（目前是整好excel表格，查询跟进提醒，操碎了心…）
另外，前几期有讲十大领域，五大过程组，想请教蓓蓓老师，关于变更管理，有没有什么好的经验和要注意的地方？中国《易经》，“一阴一阳之谓道”，事物不断的发展变化，根深的传统观念，是否也影响中国人更注重变更管理？
“天人合一”，“中庸观”等中国管理观念和现代项目管理，蓓蓓老师您怎么看？展开
