05 | 规划：扫除五大“延期地雷”，计划是用来对焦的

估计那位兄台的公司这么干下去，创业成功率堪忧… 好歹画个甘特图，列个里程碑，拍脑袋也得给关键的衔接定个流转的标准，如果能量化那就是极好的了，记得把大家聚一块，为的是上面这些事儿说清楚了，立头名状歃血为盟做不到好歹邮件标清楚了留个底儿，别跟海峡两岸一中各表到时候再扯就扯不清了.....．然后还得经常的盯着点，有谁那有变化得让大家伙儿都知道了，有必要改调就得调 另外觉的老师对焦这个概念用的特别传神…正是这些词汇的巧妙运用，使得老师讲解的非常到位，加上音色又美，更是由衷感谢 听老师的课，平静，舒心，有收获…这剧追的值

感谢雷姐的讲解有点豁然的感觉，我这里有个问题，我是个开发，如果我现在在做一个功能，策划找我对功能和给出进度的时间，那我之前为了完成马上完成手头的工作，就根据经验随便给了个时间，并没有考虑依赖路径和具体细节，导致给的时间表及其不准确，可是如果我要花时间给出进度的话，那务必耽误我手头的工作导致功能延期，这个怎么解决呢，还有我有时候忙着手里的活，老有人找我解决其他问题，耽误我的功能开发，这个又怎么办？

讲得真好，做为一名开发，看了也很有感觉，结合自己的项目经历加上老师的讲解，整理了一下自己方法论： 1.任务分解：WBS（Work Breakdown Structure），把项目中的任务分解为原子粒度大小，并明确评估出工时 2.只有具体的任务分解是不够的，需要识别出项目依赖的资源，以及项目的关键节点。所以，需要在任务分解的基础上，形成关键路径。第一步和第二步，可以借助ominiplan工具 3.根据关键路径，需要产出里程碑或者鱼骨图。明确各个时间节点，比如开发开始（结束）时间、提测时间等 4.定义标准，为避免共同做项目的同学对节点等定义的歧义，需要明确标注。比如，达到什么的标准，才符合提测的定义。【这个是避免项目中互相扯皮比较重要的一步】 5.没有达成共识的计划，是不具备任何效力的。在确认计划之后，向所有项目组成员，包括项目的所有干系人，发送计划邮件，正式周知 6.在整个项目周期中，由于随时会可能出现变更，加上对估算的不断细化，做计划永远是个反复修正、渐进明晰的过程，我们要对计划进行持续地跟进与调整。重要的是，每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策。

哇，老师太厉害了。 内容都是直指根源，用专业并且易懂的名词阐述了完整的主题，真是专业的人做的专业的事。 在极客时间上的程序员我估计以开发的较多，PM的估计没几个，我们这些开发的都是学而优则仕的被赶鸭子似的被推到team主管位置，全面负责开发和项目管理的工作，我以前做计划还真的是一句话的总结就搞定了，因为实在不知道怎么列计划，即使老板要求详细点，也只能列出来第二版那种，看完今天的内容，才知道一份合格的计划应该是怎样的，感谢。

可以讲这些常用的表格传到GitHub或者网盘上吗，老师

倒排时间在很多公司是很常见的，所以避无可避。首先我们要判断的是倒排的时间是不是合理的控制范围内，其次要明确项目的整体诉求，对其做一个基本规划，而在这个阶段最忌讳的是马上动手开发，我们都知道磨刀不误砍柴工，前期准备越充足，后期出问题后付出的代价就越小，把可控的时间周期做里程碑分解，项目明确各交付结点，后面我们要做风险的监控，进度的监控，确保在出现影响进度的情况下能快速响应与解决。

如果被要求倒排计划，按照5个标准动作的话，我理解不一定有先后顺序，我会 1. 先宣贯一下项目完成标准； 2. 再统一共识，宣贯项目配置管理，做到资料共享机制； 3. 把需求按照WBS进行分解，这里有个疑问，是不是每个子任务的工时都不要超过3天呢？？？ 4. 根据分解出来的任务，识别出关键路径； 5. 做好变更的整理和及时通知变更。

加班回来的路上听语音课程，回来后又盯着文中的图表看了好几次。我不是一个管理者，但是作为开发人员，我觉得这一章节同样给我很大启发，之前写计划就是觉得很麻烦，一笔带过，仔细对比思考一下自己周边比自己优秀的人，计划和实现方案都写的很详细，我现在明白了为什么没有我技术好的同事也可以担以重任了，代码之外的软技能，恰恰是我所欠缺的，真诚感谢

我公司的计划就是任务列表，在共识，公开透明，即时做得欠缺，老师今天的讲解让我豁然开朗，马上去买网易一千零一夜。😀

雷老师：两个问题烦请解答下 1：关键路径是什么意思，是分配给每人的时间周期吗？ 2：当项目进度出现问题存在延期，wbs表要随时更改吗？那以前的计划排期还需要吗？如果需要在哪里查看？