人月神话（7）巴比伦塔为什么失败
人月神话（7）巴比伦塔为什么失败
文章目录
思维导图
巴比伦塔的管理教训
具备哪些先决条件
- 清晰的目标
- 人力充足
- 材料齐全
- 足够的时间
- 足够的技术
失败的主要原因
缺乏交流和交流的结果——组织
大型编程项目中的交流
如何进行相互之间的交流沟通
- 非正式途径——清晰定义小组内部的相互关系和充分利用电话，鼓励大量的沟通，从而达到对书写文档的共同理解
- 会议——常规项目会议。每个人都进行简要的技能陈述
- 工作手册——在项目的开始阶段，应该准备正式的项目工作手册
项目工作手册
是什么？
项目手册不是一篇独立的文档，它是对项目必须产出的一系列文档进行组织和一种结构
项目的所有文档都必须是该结构的一部分。这包括目的，外部规格说明，接口说明，技术标准。内部说明和管理备忘录
为什么？
事先将项目工作手册设计好，能保证文档结构本身是规范的，而不是杂乱无章的。另外，有了文档结构，后来书写的文字就可以放置在合适的章节中
控制信息发布，并不是为了限制信息，而是确保信息能达到所有需要它的人的手中
如何制作手册
第一步：对所有的备忘录编号，从而每个工作人员可以通过标题列表来检索是否有他所需要的信息
第二步：使用树状结构来讲备忘录索引进行构建，这个可以使用数结构中的子树来维护发布列表
处理机制
我们使用计算机已经有的文本编辑系统，对实时维护有着不可思议的帮助
- 首先，必须在页面上标记发生改变的文本
- 分发的变更页附带简短，独立的总结性文字，对变更的重要性以及批注进行记录
现在我门使用的git就有这样的功能，git不光只是用来管理代码，还可以管理安装程序，项目开发手册，技术文档等等
如何入手？
精准，完整地定义所有接口
组织架构
减少交流的方法
人力划分和限定职责范围，当使用人力划分和职责限定时，树状管理结构反映出对详细交流的需要会相对应减少
树形组织架构的产生
树形组织架构师作为权利和责任的结构而出现的。其基本原理——管理角色的非重复性——导致了管理结构的树状的。
子树的基本要素
- 任务
- 产品负责人
- 技术主管或结构师
- 人力的划分
- 各部分之间的接口定义
两个角色
产品负责人
- 他组建团队，划分工作及制定进度表。它争取，并一直保证必要的资源。
- 主要的工作是与团队外部进行向上的沟通和水平的沟通
- 建立团队内部的沟通和报告方式
- 确保进度目标的实现，根据环境的变化调整资源和团队的架构
技术主管
- 他对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。
- 他提供整个设计的一致性和概念完整性，控制系统的复杂程度
- 当技术问题出现的时候，他提供问题的解决方案，或者根据需求调整设计
- 沟通交流在团队中是首要的，他的工作几乎完全是技术性的
存在的三种关系
- 产品负责人和技术主管是同一个人
- 产品负责人作为总指挥，技术主管充当其左右手
- 技术主管作为总指挥，产品负责人充当其左右手
总结
交流和交流的结果——组织，是成功的关键。交流和组织的技能需要管理者仔细思考，相关经验的积累和能力的提高同软件技术本身一样重要