原著推荐的进度分配比例是多少？
| 阶段 | 占比 |
|---|
| 计划 | 1/3 |
| 编码 | 1/6 |
| 构件测试和早期系统测试 | 1/4 |
| 系统测试（所有构件已完成） | 1/4 |
- 与常规做法的差异: 计划时间更多、测试时间接近一半、编码只占六分之一;
- 现实对照: 很少项目为测试分配一半时间, 但大多数项目实际花掉了进度中一半的时间;
- 后果: 不为系统测试留足时间, 等于把延迟安排到项目快结束时爆发;
里程碑应该满足什么标准？
- 唯一原则: 里程碑必须是具体的、特定的、可度量的事件, 能清晰定义;
- 反面例子: 编码"90% 完成"、调试"99% 完成"、"计划完毕";
- 正面例子: "结构师和实现人员签字认可的规格说明"、"100% 源代码编制完成并输入到磁盘库"、"测试通过了所有测试用例";
- 为什么重要: 里程碑无歧义比容易被核实更重要--无法自欺欺人时, 很少有人谎报进度;
- 服务性: 好的里程碑是团队向经理提出合理要求的依据, 模糊的里程碑则是沉重负担和士气杀手;
如何判断哪些进度偏离是关键偏离？
- 需要的工具: 关键路径法, 书中统称 PERT 图;
- 它回答的问题: 谁需要什么、谁在关键路径上、某项滞后会拖累哪个最终日期、某项任务在成为关键路径前还能落后多久;
- 最有价值的部分: PERT 的准备工作--展开网状结构、识别任务依赖、估计各任务链;
- 反借口作用: 为"其他部分反正会落后"提供答案, 展示某人需超前多少才能离开关键路径;
为什么下属倾向于隐瞒进度问题？
- 利益冲突: 一线经理担心汇报后老板会采取行动, 取代自己的作用、降低威信、打乱其他计划;
- 自我安慰: "可以自己弥补偏差, 何必麻烦老板", 于是污垢被藏在地毯下;
- 老板的反应模式: 若老板一看到状态报告就打电话发号施令, 会彻底压制信息公开;
- 老板需要两类信息: 需要采取行动的问题信息, 和用于分析、早期预警的状态数据;
老板如何让状态信息浮出水面？
- 区分会议: 把状态检查会议与问题-行动会议明确标记, 并相应控制自己的行为;
- 约束自己: 不对项目经理能解决的问题做出反应, 不在检查状态报告时做安排;
- 保留评审机制: PERT 图加频繁的里程碑是评审基础; 大型项目可每周评审部分、每月整体评审;
- 引入计划与控制小组: 一至三人, 作为老板的延伸, 只负责询问里程碑何时设定、是否达到, 并处理全部文字工作;
计划日期和估计日期有什么区别？
- 计划日期: 项目经理的工作产物, 代表经协调后的整体工作计划;
- 估计日期: 最基层经理的工作产物, 代表在现有资源和先决条件到位时对实际实现日期的最佳判断;
- 经理的正确做法: 停止怀疑这些日期, 转而让它们更精确, 从而得到没有偏见的估计, 而不是合乎心意或自我保护的估计;
- 价值: 一旦两类日期在每个人脑中形成清晰印象, 经理就能预见到"不采取措施就会出问题"的地方;