人月神话（7）巴比伦塔为什么失败

人月神话（7）巴比伦塔为什么失败

思维导图

巴比伦塔的管理教训

具备哪些先决条件

• 清晰的目标
• 人力充足
• 材料齐全
• 足够的时间
• 足够的技术

失败的主要原因

缺乏交流和交流的结果——组织

大型编程项目中的交流

如何进行相互之间的交流沟通

• 非正式途径——清晰定义小组内部的相互关系和充分利用电话，鼓励大量的沟通，从而达到对书写文档的共同理解
• 会议——常规项目会议。每个人都进行简要的技能陈述
• 工作手册——在项目的开始阶段，应该准备正式的项目工作手册

项目工作手册

是什么？

项目手册不是一篇独立的文档，它是对项目必须产出的一系列文档进行组织和一种结构
项目的所有文档都必须是该结构的一部分。这包括目的，外部规格说明，接口说明，技术标准。内部说明和管理备忘录

为什么？

事先将项目工作手册设计好，能保证文档结构本身是规范的，而不是杂乱无章的。另外，有了文档结构，后来书写的文字就可以放置在合适的章节中
控制信息发布，并不是为了限制信息，而是确保信息能达到所有需要它的人的手中

如何制作手册

第一步：对所有的备忘录编号，从而每个工作人员可以通过标题列表来检索是否有他所需要的信息
第二步：使用树状结构来讲备忘录索引进行构建，这个可以使用数结构中的子树来维护发布列表

处理机制

我们使用计算机已经有的文本编辑系统，对实时维护有着不可思议的帮助

• 首先，必须在页面上标记发生改变的文本
• 分发的变更页附带简短，独立的总结性文字，对变更的重要性以及批注进行记录

现在我门使用的git就有这样的功能，git不光只是用来管理代码，还可以管理安装程序，项目开发手册，技术文档等等

如何入手？

​ 精准，完整地定义所有接口

组织架构

减少交流的方法

人力划分和限定职责范围，当使用人力划分和职责限定时，树状管理结构反映出对详细交流的需要会相对应减少

树形组织架构的产生

树形组织架构师作为权利和责任的结构而出现的。其基本原理——管理角色的非重复性——导致了管理结构的树状的。

子树的基本要素

• 任务
• 产品负责人
• 技术主管或结构师
• 人力的划分
• 各部分之间的接口定义

两个角色

产品负责人

• 他组建团队，划分工作及制定进度表。它争取，并一直保证必要的资源。
• 主要的工作是与团队外部进行向上的沟通和水平的沟通
• 建立团队内部的沟通和报告方式
• 确保进度目标的实现，根据环境的变化调整资源和团队的架构

技术主管

• 他对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。
• 他提供整个设计的一致性和概念完整性，控制系统的复杂程度
• 当技术问题出现的时候，他提供问题的解决方案，或者根据需求调整设计
• 沟通交流在团队中是首要的，他的工作几乎完全是技术性的

存在的三种关系

• 产品负责人和技术主管是同一个人
• 产品负责人作为总指挥，技术主管充当其左右手
• 技术主管作为总指挥，产品负责人充当其左右手

总结

交流和交流的结果——组织，是成功的关键。交流和组织的技能需要管理者仔细思考，相关经验的积累和能力的提高同软件技术本身一样重要

人月神话系列索引

人月神话（1）焦油坑
人月神话（2）人月神话
人月神话（3）外科手术队伍
人月神话（4）系统设计
人月神话（5）画蛇添足
人月神话（6）贯彻执行
人月神话（7）巴比伦塔为什么失败
人月神话（8，9）胸有成竹与削足适履
人月神话（10）提纲挈领
人月神话（11）未雨绸缪
人月神话（12）干将莫邪
人月神话（13,14,15）整体部分 祸起萧墙与另外一面