项目管理第三招：做好计划，拥抱变化

​ 前两篇写完后，第三招很容易的就想到了，这一招也是项目经理们每时每刻都在做的事情，但是要做好这件事情很不容易。这个事情就是：

• 做好计划
• 处理变更

​ 所以，我这个系列中的第三招就是：做好计划，拥抱变化。怎么做计划，怎么管理变化，关于这两个话题，网上已经有足够多的资料和内容来学习，所以我这篇文章就不在这个方面去班门弄斧，还是只拿程序员向项目经理转身的几个关键问题出来有针对性的说一说，大部分也是我自己的一些经验，不一定适用于所有人。

做好计划

​ 我的这个系列不会搬大段大段的理论知识和书本上的东西过来。主要就是站在程序员转项目经理的这个角度去看，在做好计划这个问题上要注意下面几件事情：

合适的工期估计

• 做计划不要太乐观。大部分的程序员都是乐观主义者，根据我自己的经验来说的话，是因为程序员生活在一个相对较简单的环境中，从而没有认识到“变化”才是每个项目的本质；而每个搞技术的人永远是那么迷信自己手里的技术：

  • 很难认识到客户业务会变，也就是业务需求会变，也就是范围会变。
  • 更难认识到客户人的想法会变，自己的想法会变，同事的想法会变，甚至你当天的心情啥的都会影响到项目的进展。

  所以，每个项目计划都需要留出必要的时间来处理这些“变化”。至于留出多少来，则是每个人/每个项目不同的。我自己的习惯是，最起码***多计划出四分之一的时间来***。因为我觉得，一个人每天8个小时的工作时间，能高效工作6个小时已经是非常ok的，总要留点时间出来摸鱼的。

• 相对应的，做计划也不能太悲观。一个计划如果明显的超出预期，项目经理多数的结果是被替换掉，就是这么的残酷。有这么一个比较通用的工期估算方法：
  $$合理的工期=\frac{乐观估计+4\ast 中间估计+悲观估计}{6}$$

PDCA：

​ 狭义的计划是指计划本身，而项目经理更多的是要关注广义的计划：计划制定+计划执行。有一个经典的管理方法论可以用于这个广义的计划，也就是PDCA，我理解这是一个思维的工具和指导方法，用于思考和指导项目经理的日常工作。

• plan，计划。包括方针和目标的确定，以及活动规划的制定。也就是我们经常提到的狭义的计划。
• do，执行。一般的项目经理也会想到这一层。
• check，检查。这是初转项目经理的程序员们容易忽视的问题。事项按照计划制定和执行后，执行的效果是否是设想当中的样子？是否有些微或者较大的偏差？如果忽视了这一个步骤，整个项目会慢慢朝着不可控的方向改变。
• act，处理。较上一步更加深入一点的动作就是发现有偏差之后对计划和资源的调整。发现了偏差必须进行调整。当然这个调整有很多中方法：根据项目的不可能三角去进行取舍，协调更多更好的资源来进行补充等。
• 循环，嵌套。PDCA是一个一个的小循环，现在的敏捷开发基本上是走的这条路子。每个迭代属于一个小的PDCA循环。一个大版本属于大一点的循环，再往外就是一个产品，再是解决方案等等。这里给项目经理的一个启示是：持之以恒，项目的计划和执行是贯彻在日常工作中的每一天，而不是随着感觉走。

今日事今日毕

​ 在《人月神话》这本书中提到一点：*当人们听到某个项目的进度发生了灾难性偏离时,可能会认为项目一定遭受了一系列重大灾难。然而,通常灾祸来自白蚁的肆虐,而不是龙卷风的侵袭。同样,项目进度经常以一种难以察觉,但是残酷无情的方式慢慢落后。实际上,重大灾害是比较容易处理的,它往往和重大的压力、彻底的重组、新技术的出现有关,整个项目组通常可以应付自如。*也就是说，一个项目的成败很大一部分不是因为有看得见的巨大困难和资源匮乏来决定的，而是日常中的一点一滴的小事的成败来决定的。

​ 我觉得有几个小技巧来处理这个问题：

1. 前面提到的任务分解WBS要执行到位，每个叶子节点都是可评价的工作量，这样就可以保证你的计划的可靠的。而不是完全拍脑袋出来的，这对今日事今日毕是一个前提条件。
2. 站立晨会或者是下班前的站立会。这样可以跟踪到每个成员的进展和困难，请注意这个范围不要太大，最好是5-6个人左右。
3. 在团队内部不停的宣传这个观点，并以身作则。重要的是需要不停的进行主张。

工作任务分类

​ 经过WBS分解之后，所有的事项可以分成4个象限：

1. 紧急且重要
2. 紧急且不重要
3. 不紧急且重要
4. 不紧急且不重要

​ 如何协调资源去做这些事情？一般第一反应是，协调重兵来解决紧急且重要的事情。应该说这样是对的，但又不全对。为什么这么说呢，我们生活中有一个经典的例子，我妈妈是一个比较节俭的人，一旦一顿饭多煮了一点剩了一些饭，到了下一顿为了不浪费就会先吃这些剩饭，但是还是按照平时的量去煮，导致每顿饭都会有剩饭，每顿饭又都在吃剩饭。

​ 发现这个问题了么？在项目中，往往因为各种变化会导致各种紧急情况的出现，不停的会有紧急且重要的事情出现，一旦将所有的兵力用于解决这些问题，导致本来需要解决的一些重要问题被耽误，从而导致更多的紧急情况，进入到一个负向循环中。就会出现我们在开场中描述的问题：“救火队员” 比 “保安队长”更多，而且好像还更受关注，其实这是一个项目不健康的表现。

​ 怎么解决这个问题呢？我个人是这么认为的：

1. 梳理出WBS中的关键路径和关键问题来，并设置一个尖刀小分队来保障这条关键路径。
2. 不停的提醒自己，不管出现什么情况，这个小分队的人不能动。将很大一部分精力推动这个小分队按照既定计划稳步推进。
3. 审视每个紧急情况，是不是真的那么紧急。拿项目的目标去进行比对和审视，对这些紧急事项不停的做减法和取舍。这一条又再一次强调了项目开始时目标的重要性。

拥抱变化

调整心态

​ 俗话说得好，计划永远没有变化快。在当今互联网这个快速变化的行业中，不变的只有不停的变化。另外，面向人的项目比面向机器的代码，不确定因素是成几何倍数增加的。这对从程序员转身项目经理的人来说，面向这些不确定性是对自身的一个挑战。

​ 我自己在转身成项目经理之后，有过两种典型的心态：

1. 紧张。一旦需求，人员，时间等因素发生变化，自己就会变得非常的紧张和不安。会不停的怀疑自己制定的项目计划，更甚者就是产生自我怀疑。然后作为一个程序员出身的项目经理，着急的想参与到每个问题的解决当中，从而试图去让项目回到当初的计划中。这样做的一个问题就是会落入细节而忽视整个目标，所谓的只见树木不见森林。
2. 拒绝。因为认识到计划的重要性，往往对于外界的变化都是抱着拒绝的心态去和他人合作。就会让自己变得像个刺猬一样去和项目的上下游进行交流，导致项目无法继续推进。比如不接受需求的变更等，这才导致了开场篇里提到了程序员与产品经理互砍，项目经理和项目组内的每个人互相拆台。

​ 所以，作为项目经理，面对变化的第一件事就是正视变化，用积极的心态来面对变化。除了积极的心态，当然我们还要有几个小工具来帮助我们更好的应对变化。

应对变化

​ 我来说说我工作中用到的几个小工具和小技巧来应对变化。

1. 制定标准的变更流程。项目怕的不是变化，而是无序的变化和对变化的无序处理。因此，项目经理的重要工作就是将这些部分全部有序化。

   • 统一的变更入口，而不是任何人都可以往项目组内传递变更。
   • 统一的干系人列表和责任界面，这样能保证项目团队责权分明。
   • 固定（请注意是固定而不是固化）的处理工作流程。从入口到所有干系人的传递方式也节点都是有明确的责任人和时间约束的，这样才能保证变更能传到到相关人员。

2. 建立起反馈渠道。这一点也是至关重要，变更的传递是双向的，而不是只是从入口往其他干系人身上传递的。而是针对每个节点有一定的反馈机制，保证每个节点的传递是无误的，是没有变形的打折的。

3. 鼓励团队内面对面的交流。程序员们往往喜欢用消息，邮件代替其他交流方式。实际上交流方式在有效性上的排序应该是面对面交流大于电话（电话无法观察对方的表情），电话交流大于邮件和消息（连语气和语速等信息都丢失了）。

   以上三条基本上可以保证在开场篇中的需求变形和他怎么不知道的问题。

4. 划分好各种粒度的里程碑并追踪。这一点实际上是提前去识别和处理变更，或者说提前去消除风险。将一个大的时间周期划分成若干个子周期，然后再划分成子子周期。我自己的习惯是划分到以周为单位的周期就差不多了，这样的周期和任务就是可跟踪的，在这样一个小周期的里程碑内去控制变更和风险，远比只有一个周期，到了最后才发现问题的方式更好。

5. 记住一点：预防 > 治疗。

这一招的最后

​ 和上面的两招不太一样，这一招是贯穿了整个项目过程，这一招用的好不好的一个关键因素就是：是否持之以恒，是否只是在纸上谈兵，只有在事上去磨才能将这一招用的炉火纯青，无招胜有招。

​ 与各位看客互勉。