前言
- 项目进度发生偏离时，通常不是重大灾难导致的，而是以一种难以察觉、但残酷无情的方式落后的。
- 一天一天的进度落后比起重大灾难更加难以识别、更不容易防范和更加难以弥补。
里程碑 Or 沉重的负担
大型项目的控制需要进度表，进度表的制定包括两个部分
- 里程碑
- 日期
首先说日期评估是一个技术上的问题，在很大程度上依赖于以往的经验。
如何将以往的经验抽象、量化、保存、分析是日期评估的重点
里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义。判断里程碑是否合理的办法是观察它能否再细分。例如，某个里程碑在某个时间点可以被定义为完成了90%，那就是不合理的。例如“说明文档获得结构师签字认可”就是合理的。
里程碑必须是只包含yes和no两种状态的事件
对于里程碑来说，边界明显且没有歧义比容易被老板核实更为重要。只要做到无法自欺欺人，程序员就很少会在里程碑上弄虚作假。老板需要真实的消息，而不是让人愉快的消息。
好的里程碑是服务于团队的，是产品经理对于团队的服务，而模糊的里程碑则是难以处理的负担。当里程碑没有正确反映损失的时间，并对人们形成误导，以致事态无法挽回的时候，将会彻底打击团队的士气。虽然慢性的进度偏离也会打击士气，但毕竟有可以挽回的空间。
如果你错过了一个最终期限，请确保完成下一个最终期限
进度表研究统计结果：
- 项目开始之前给出的进度表，即便每周修订，到开始的那一刻不会有太大变化
- 开发过程中，高估了所需时间的里程碑，实际用时会持续下降
- 开发过程中，低估了所需时间的里程碑，在临近项目收尾的时候，实际用时会持续增加
“其他的部分反正会落后”
对于软件开发队伍来说“进取”是非常必要的，进取提供了缓冲和储备，使得开发团队能够处理常规的灾祸。正确理解开发团队的“进取”应该有两个方面：
- 培养能够比团队要求更加努力尝试的开发人员，比要求的上班时间更长的上班时间，比要求的代码质量更高的完成成果，比要求的进度表更快的完成速度。
- 努力防止任务计算和工作量评估对人员的“进取”造成消极的影响，我们必须关心到每一天的滞后，它是大问题发生的基本组成元素。
并不是所有进度的偏离都等于灾难，可以采用一些方法来对进度偏离进行评估——关键路径法。它能显示哪些是关键节点，关键节点滞后会影响最终的完成日期。另外，还能评估某个任务在成为关键节点之前，可以落后的时间。
关键路径法是很复杂的运筹学问题，我觉得不值得为这样的精细化产生额外的工作量
使用科学的方法进行项目推进，可以堵住泄气的借口，它为个人展示了如何使自己的工作原理关键路径，需要超前多少，也提供了补偿其他部分丢失时间的建议。
地毯的下面
所有的污垢都应该被隐藏在地毯之下，这里的污垢指的是队伍出现计划偏离，隐藏在地毯之下指的是项目经理自己寻找对应方法，而不是报告给老板。
老板需要得到两种信息：
- 有必要采取行动的问题
- 用于分析状态的数据
但老板得到真相是困难的。只要项目经理认为自己可以独立解决问题，他就不会告诉老板。因为老板采取行动之后，会降低经理的威信，搞乱其他计划，二者是有内在冲突的。有两个办法可以把毯子下面的污垢展示给老板，这是两种必须被采用的办法。
一、减少角色冲突和鼓励状态共享
老板必须区别行动信息和状态信息，规范自己，绝不在检查状态的时候做安排。需要把会见、评审、会议等工作明确标记为状态检查（status-review）和行动安排（problem-action），并相应控制自己的行为，整个过程对减少角色冲突以及鼓励状态共享会非常有帮助。
二、猛地拉开地毯
拥有能了解状态真相的评审机制是必要的。频繁、明确的进度表是这种评审的基础。大型项目可能每周要进行部分评审，每月进行整体评审。
下面是一段报告摘录，这样一份报告作为会议议程，每个人都将知道问题所在。产品经理应该准备解释延时的原因，什么时候结束，采取的步骤和需要的任何帮助。
image.png
- 计划日期来自于顶层经理的工作，代表了经过协调后的项目整体工作计划。
- 估计日期来自于基层经理的工作，代表了现有资源、先决条件以及承诺，是对实际实现日期的最佳判断。
如何获得没有偏见的估计，而不是合乎心意的乐观估计，或者自我保护的保守估计。项目经理应该把工作重心放在如何让评估更加精确上，而不是怀疑基层经理的判断。
计划和控制（Plan & Control）
进度表需要团队（1~3人）来关注他的更新、修订和报告。对大型项目，计划和控制小组的价值是非常可贵的。小组的职权仅限于向产品经理询问他们什么时候设定或者更改里程碑，以及是否达到了里程碑。产品经理和老板仅仅需要作出决策。
向计划和控制职能进行适度的技术人力投资是非常值得赞赏的。它在项目中的贡献和直接开发软件产品不同，它能明白的指出不易察觉的延迟，并强调关键的因素，作为早期的预警系统，防止项目以一次一天的方式落后一个月。
以上就是《人月神话》第14章——孵化灾难（也译：祸起萧墙）的全部内容
软件开发本身是一个具有无序趋势的活动，流水化的作业方式与开发工作内在的发展规律是相悖的。软件开发是思维创造的活动，如同诗歌、乐曲一样，人类历史上还没有为创造性的工作进行流水化的尝试。我们所有的计划和控制只不过是为了提供一个稳定的承载基础。
还记得“对复杂性的控制”是软件行业的共同问题么，聪明的项目经理会寻找同一类型的项目中所存在的共性，以此来达到控制的目的。在若干项目的实践中，我总结出了最小的文档集合应该包括如下：
- 需求文档
- 项目计划
- 框架设计
- 设计元素说明
其中，项目计划不仅仅是进度，而是从软件配置管理、生命周期、资源分配、风险分析、培训等当面进行描述。这部分的内容往往不局限于单个项目，而是在同一类型的项目中具有共性，因此可以在不同的项目中共享。
使用这些正式的文档作为自己的数据基础（哪怕他们非常简单），一旦开始意识到它们的普遍性和重要性，那么文档就会成为工具，友好的利用起来，而不会让它成为令人厌烦的任务。通过遵循文档开展工作，项目经理能更清晰更快的设定自己的方向。
网友评论