为什么为变更组建团队比为变更设计更难？
- 设计的准备手段: 细致的模块化、可扩展的函数、精确完整的模块间接口设计、完备的文档、表驱动技术;
- 最重要的措施: 使用高级语言和自文档技术, 以减少变更引起的错误;
- 变更阶段化: 每个产品都应有数字版本号、日程表和冻结日期, 之后的变更属于下一个版本;
- 组织难度: 每个人被分派的工作必须是多样的、富有拓展性的, 从技术角度整个团队可以灵活安排;
- 具体做法: 大型项目中, 项目经理需要两三个顶级程序员作为技术轻骑兵, 在工作最密集时急驰飞奔解决各种问题;
为什么程序员不愿写设计文档？
- 表面原因: 惰性或者时间压力;
- 真实原因（Cosgrove 的观察）: 设计人员不愿提交尝试性的设计决策, 因为文档化意味着把自己暴露在每个人的批评之下, 必须为每个结果辩护;
- 后果: 如果团队架构因此受到任何形式的威胁, 就没有任何东西会被文档化, 除非架构是完全受保护的;
- 管理含义: 要为"尝试性决策"提供心理安全的制度空间, 否则文档工作必然落空;
如何让管理人员和技术人才可互换？
- 前提: 只要管理人员和技术人才的天赋允许, 老板必须对他们的能力培养给予极大关注;
- 目标: 使管理人员和技术人才具有互换性, 从而能在技术和管理角色之间自由分配人手;
- 培训要求: 管理人员需要参与技术课程, 高级技术人才需要进行管理培训;
- 信息共享: 项目目标、进展、管理问题必须在高级人员整体中得到共享;
- 准备状态: 高层人员必须时刻做好技术和情感上的准备, 以管理团队或亲自参与开发工作;
两条晋升线的社会障碍如何克服？
- 障碍一: 管理人员自己常认为高级人员太"有价值", 舍不得让他们做实际编程工作;
- 障碍二: 管理人员拥有更高的威信;
- 制度手段一: 如 Bell Labs 的一些实验室废除所有职位头衔, 每个专业人士都是"技术人员中的一员";
- 制度手段二: 如 IBM 的一些实验室保持两条职位晋升线, 相应级别在概念上相同;
- 待遇对齐: 很容易建立一致的薪水级别, 但要建立一致的威信更难--需要相同的办公室大小和布局、相同的秘书和支持;
- 调动规则: 从技术线向管理同级调动不能伴随待遇提升, 且应以"调动"而非"晋升"的名义; 反向调整则应伴随待遇提高, 以补偿传统意识;
外科手术队伍为什么是灵活组织架构的解决方案？
- 对晋升问题的冲击: 组建外科手术队伍式团队后, 高级人才编程和开发不会感到自降身份, 清除了剥夺创造性乐趣的社会障碍;
- 对变更问题的冲击: 该组织架构的设计目标是最小化成员间的接口, 使系统在最大程度上易于修改;
- 重组成本低: 当组织架构必须变化时, 为整个"外科手术队伍"重新安排不同的软件开发任务会相对容易;
- 作者判断: 对于灵活组织架构问题, 这的确是一个长期行之有效的解决方案;