本章严肃的讨论了 里程碑 ，并推荐了一种工具 —— PERT

项目是怎样延迟了整整一年的时间？…一次一天。
How does a project get to be a year late? … One day at a time.

里程碑

不知道你们是否遇到过，项目看着一切正常，但是又双叒叕延期了。明明计划清晰、目标明确；里程碑、OKR、燃尽图，反正能用的工具都用了，延期顶多也就是迟到，但从不缺席。

书中倒是一针见血指出问题所在，我们先看下书中如何定义里程碑

什么是里程碑

  • 如何根据一个严格的进度表来控制项目？
  • 第一个步骤是制订 进度表 。
  • 进度表上的 每一件事 ，被称为“里程碑”，它们都 有一个日期 。
  • 选择日期是一个估计技术上的问题，在前面已经讨论过，它在很大程度上 依赖以往的经验 。

到这里一切OK，我们也是这么做的，然后

里程碑的选择只有一个原则

那就是，里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义。

以下是一些反面的例子

  • 例如编码，在代码编写时间达到一半的时候就已经“90％完成”了；
  • 调试在大多时候都是“99％完成”的；
  • “计划完毕”是任何人只要愿意，就可以声明的事件。

具体的里程碑是百分之百的事件。要 签字画押 ，要 过了测试 ， 不要自欺欺人 。

当里程碑没有正确反映损失的时间，并对人们形成误导，以致事态无法挽回的时候，它会 彻底碾碎小组的士气 。 慢性进度偏离同样也是士气杀手。

还有一些其它轶闻

对于大型开发项目中的估计行为，政府的承包商做了两项有趣的研究。研究结果显示：

  1. 如果在某项活动开始之前就着手估计，并且每两周进行一次仔细的修订。这样，随着开始时间的临近，无论最后情况会变得如何的糟糕，它都不会有太大的变化。
  2. 活动期间，对时间长短的过高估计，会随着活动的进行持续下降。
  3. 过低估计在活动中不会有太大的变化，一直到计划的结束日期之前大约三周左右。

PERT

一开始我认为大多数人都爱待在自己的舒适区，只有给一定的鞭策，才能激发他们的进取心。所以我成了他们的“小皮鞭”。给他们上OKR，激励他们，但是效果不理想。
但我对PERT的感受是，给每个人树立一个理念，让他们知道自己负责事项延误对全局的后果；就像每人头上多了个达摩克里斯之剑一样。

PERT还能很好的控制风险，明确任务之间的依赖。 我查阅了wiki，以下是一些摘抄。

事件和活动

在PERT图中事件是主要的建构单元，分别为前导事件和后续事件：

  • PERT事件：单纯标记活动开始或完成的点，与时间和资源无关。当事件标记表示一或多个活动的完成时，要一直到导致该事件的所有活动已经完成为止，才会“到达”这个完成标记点。
  • 前导事件：一个事件，紧接在某个其它事件之前，没有任何其它事件介入。一个事件可以有多个前导事件，也可以是多个事件的前导事件。
  • 后续事件：一个紧随于其它事件之后的事件，没有任何其它的介入事件。一个事件可以有多个后续事件，也可以是多个事件的后续事件。

除了事件PERT还具有活动和子活动：

  • PERT活动：此为任务的实际绩效，将消耗时间并且需要资源（如劳动力、材料、空间、机械）。它可以理解为表示从一事件转移到另一事件所需的时间，精力和资源。PERT活动在其前导事件尚未发生之前，并不能被发动执行。
  • PERT子活动：可以进一步将PERT活动分解为一组子活动。例如活动A1可以分解为A1.1，A1.2和A1.3。子活动具有活动的所有属性；特别地，子活动具有像活动一样的前导或后续事件。子活动可以再次分解成更细粒度的子活动。

时间

PERT已经定义了完成一活动所需时间的四种类型：

  • 悲观时间：完成活动（p）或路径（P）所需的最长可能时间，假设一切都出错（但不包括重大灾难）。
  • 乐观时间：完成活动（o）或路径（O）所需的最短可能时间，假设一切都比通常预期的要好
  • 最可能的时间：假设一切正常进行，完成活动（m）或路径（M）所需时间的最佳估计。
  • 预期时间：完成活动（te）或路径（TE）所需时间的最佳估计，考虑到事情并不总是像正常一样进行（这意味预期时间是，如果在很长一段时间内多次重复执行任务，任务所需的平均时间）。
$$\begin{matrix} te = (o + 4m + p) ÷ 6 \\ TE = \sum_{i=0}^{n}te_{i} \end{matrix}$$
  • 时间的标准差：完成活动所需时间的变化范围(σte)或路径的变化范围(σTE) $$\begin{matrix} σ_{te} = (p - o) ÷ 6 \\ σ_{TE} = \sqrt{\sum_{i=1}^{n}σ_{te_{i}}^{2}} \end{matrix}$$

范例

以下范例中有七个任务，分别标记为A到G。某些任务可以并行地完成（A 和 B），而其它任务在前导任务完成之前无法进行（C不能在A完成之前开始）。此外，每个任务都有三个估计时间：乐观时间估计（o），最可能或正常时间估计（m）和悲观时间估计（p）。使用公式（o + 4m + p）÷6 计算预期时间（te）。

活动 前导任务 乐观的(o) 正常的(m) 悲观的(p) 预期
A — 2 4 6 4.00
B — 3 5 9 5.33
C A 4 5 7 5.17
D A 4 6 10 6.33
E B, C 4 5 7 5.17
F D 3 4 8 4.50
G E 3 5 8 5.17

完成此步骤后，可以绘制如下的甘特图或节点图。

  1. 流程图

    graph LR START((start)) --> A START((start)) --> B A -->|4| C A -->|4| D B -->|5.33| E C -->|5.17| E D -->|6.33| F E -->|5.17| G G --> END((end)) F --> END((end))

  2. 甘特图

    gantt dateFormat YYYY/MM/DD start:done, start, 2020/10/27 section group1 A:done, A, after start, 96h B:active, B, after start, 128h C:C, after A, 124h section group2 D:crit, done, D, after A, 152h E:crit, active, E, after B C, 124h section group3 F:active, F, after D, 108h G:after G, after E, 124h

汇报

本章最后提及了汇报，其重点无非两点

  1. 减少角色的冲突。

首先老板必须区别行动信息和状态信息。他必须规范自己，不对项目经理可以解决的问题做出反应，并且决不在检查状态报告的时候做安排。

  1. 评审

不论协作与否，拥有能了解状态真相的评审机制是必要的。PERT 图以及频繁的里程碑是这种评审的基础。大型项目中，可能需要每周对某些部分进行评审，大约一个月左右进行整体评审