2. 人月神话

进度拖延的原因：

• 乐观主义
• 人月互换思维
• 缺少持续估算
• 缺少跟踪和监督
• 「重复」产生的进度灾难

向进度落后的项目增加人手，只会使进度更加落后

3. 外科手术队伍

本节讲述效率和快速的平衡性

人员数量影响开发中的沟通成本，小型精干的开发团队拥有更高的效率

对于大项目，又该如何组织？如果仅追求效率，采用小型精干团队，则系统无法在规定时间完成

如果一拥而上，直接往上叠加人力，必定会降低一定的效率

如果平衡？Mills 的建议：

• 对大型系统进行拆分，每部分由一个团队解决，团队内的大部分信息仅在本团队流动，降低沟通成本
• 团队内成员组织方式：避免每个人各自去截取问题，而是由一个人把控整体并分解问题以保证概念一致性（外科医生），其余人员专业化分工并给与支持
• 团队内角色：编辑（润色外科医生的文档，文档管理）；。。。

团队之间的协作？下文会讲到

4. 贵族专制、民主政治和系统设计

概念完整的重要性

个人风格

将政治制度类比于系统设计

系统结构师在本书的概念有点像产品经理+技术经理的角色，而非技术上的架构师

抛出了几个问题并回答

• 系统结构师是一种无需歉意的「贵族专制统治」，先保证统一，无法整合的 idea 先放一边，量多了才对系统进行重新设计
• 结构师获得创造的快乐，剥夺了实现人员的创造力：否，实现本身也是一种创造工作。
• 设计和开发时间分工怎么安排？
  • 简单回答是完成说明的时候才雇佣实现人员。如同先有建筑师画图，再招工开发。
  • 如果要压缩进度，可以在设计有初步雏形时就开始构思

【注】：这种方式，实现人员没有参与设计讨论，和现代的需求评审有些不符，是否为过时经验？

下一章会讲到

5. 画蛇添足

建筑为例，结构设计时估价，后续承包商会验证并修正

时间不够，分期做: 一期、二期...

结构设计师应该警惕二期，经常会把子功能当主功能做

6. 观测执行

13. 未雨绸缪

技术转管理应该以调动而不是晋升的名义

14. 祸起萧墙

一点点落后导致的进度延迟较难被发现

里程碑定义不能模糊化，比如 90%完成、计划完毕等，而应该用100%源码编制完成，xx模块开发完成、完成测试等切实的里程碑

必须关心每一天的滞后

进度滞后的信息同步，项目经理是否应该同步老板？

• 同步

wip

PERT 图

15. 另外一面

讲述了文档维护的问题

提到了用程序自动生成文档的好处

16. 没有银弹

一些感想

结构设计师，而非产品经理，说明那个年代还没分工到那么细致，偏向技术产品