读《人月神话》seven 为什么巴比伦塔会失败？
全文更新索引：读《人月神话系列 zero》<—点击查看
巴比伦塔
这是《圣经·旧约·创世记》第11章故事中人们建造的塔。当时人类联合起来兴建希望能通往天堂的高塔；为了阻止人类的计划，上帝让人类说不同的语言，使人类相互之间不能沟通，计划因此失败，人类自此各散东西。
这个项目，影响成功的因素有哪些？清晰的目标:我要造一个高塔，通往天堂。清楚明白。也许你觉得这不可能完成，因此一开始就放弃吧，做什么都比这个好。那么，这项工程甚至连一个普通楼房的高度都没有完成。明白我的意思吗？我是说，远没有达到我们需要考虑“清晰的目标”这个因素之前，它就已经失败了。
仔细想想吧，人生有多少事情，在根本没有达到需要考虑目标的可行性之前，就已经被我们放弃了？
人力：肯定时充足的。材料:他们用砖块代替石头，用沥青代替灰泥（建造房屋）。材料？ 在美索不达米亚有着丰富的泥土和柏油沥青。时间：没有任何时间限制技术：没有达到需要更好的技术之前，这项工程就已经失败了。
于是作者从而引出他重视的一点。这个群体性的活动，需要交流、以及交流的结果：组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。通过史书的字里行间，我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。很快，部落开始分裂——大家选择了孤立，而不是互相争吵。
大型编程项目中的交流
上述的案例在现实生活中屡见不鲜。比如大型编程项目中，因为左手不知道右手在做什么，所以进度灾难、功能的不合理和系统缺陷纷纷出现。
那么交流的可能的途径有哪些？
- 非正式途径
也就是先定义好各个部门，组织。大家通过社交软件等沟通，有时候文字存在二义性，所以电话沟通也是常用的。 - 会议
组织常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。 - 项目工作手册
在项目的开始阶段，应该准备正式的项目工作手册。
项目工作手册
是什么？
他不是一篇独立的文档，而是针对项目中会存在的一些文档做一个组织。项目 所有 的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录.为什么？
- 技术说明是必要的。技术人员在工作中就某个功能去查相关的用户手册，那么他将发现别人的处理方式、为什么用那个方法。这样技术人员既可以获得一种思路、也能看到之前的建议、设计解释。这样开发人员会豁然开朗。新人上任也不会盲目。
- “未来产品”的质量手册将诞生于“今天产品” 的备忘录。做好了工作手册，之后出用户手册、质量手册所花费的代价将非常少。如果技术人员不记录，那么第一个忘记的人就是他自己。
- 控制信息发布。确保信息能到达所有需要它的人的手中。
怎么做？
- 先是对于所有的备忘录进行编号、也就是“建立索引”，这样每个工作人员可以快速检索到自己需要的信息。
- 接着，每隔办公室保留一份工作手册的拷贝。
- 保持工作手册的实时更新。这边作者使用的是纸质版。采用活页夹的方式，更新一部分只把那部分替换掉。更新后，接收新信息的人员值观的知道更改了哪些，需要理解现在某概念的定义是什么。因此我们要对工作手册持续文档维护，强调、标记重要的文字。
之后作者的实践之后发现手册十分庞大。于是使用了微缩胶片的方式。还有：使用专门建立和维护文档的后台系统。
卡内基－梅隆大学的 D.L.Parnas 提出：编程人员仅了解自己负责的部分，而不是整个系统的开发细节时，工作效率最高。这种方法的先决条件是精确和完整地定义所有接口。
大型编程项目的组织架构
如果项目有 n 个工作人员，则有个相互交流的接口，有将近 2n个必须合作的潜在团队,团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。
减少交流的方法是：人力划分（division of labor）和限定职责范围（specialization of function）
一个公司的组织结构展现出来往往是个树状图，这是因为管理角色的非重复性。但是人员之间的交流却不是，这是一个网状图。很多工程领域中，树状图也不能很精确的描述其组织结构。
树状编程队伍，要使它行之有效，每棵子树所必须具备的基本要素：
- 任务（a mission）
- 产品负责人（a producer）
产品负责人的角色:组建团队，划分工作及制订进度表。他要求，并一直要求必要的资源。这意味着他主要的工作是与团队外部，向上和水平地沟通。他建立团队内部的沟通和报告方式。最后，他确保进度目标的实现，根据环境的变化调整资源和团队的构架。
- 技术主管和结构师（a technical director or architect）
技术主管的角色:对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。他提供整个设计的一致性和概念完整性；他控制系统的复杂程度。当某个技术问题出现时，他提供问题的解决方案，或者根据需要调整系统设计。用Al Capp 所喜欢的一句谚语，他是“攻坚小组中的独行侠” （inside-man at the skunk works.）。他的沟通交流在团队中是首要的。他的工作几乎完全是技术性的。
- 进度（a schedule）
- 人力的划分（a division of labor）
- 各部分之间的接口定义（interface definitions among the parts）
上述产品负责人和技术主管的角色需要的技能不一样，这些技能可以按照不同的方式组合。
作者说了三种方式：
一： 产品负责人和技术主管是同一个人:这种是在小型队伍中，大约3-6个人。
大型的项目应用不太行，原因如下：
第一，同时具有管理技能和技术技能的人很难找到。思考者很少，实干家更少，思考者－实干家太少了.
第二，大型项目中，每个角色都必须全职工作，甚至还要加班。对负责人来说，很难在承担全部管理责任的同时，还能抽出时间进行技术工作。对技术主管来说，很难在保证设计的概念完整性，没有任何妥协的前提下，担任管理工作。
二： 产品负责人作为总指挥，技术主管充当其左右手：技术主管很难在不参与任何管理工作的同时，建立在技术决策上的权威。产品负责人必须给定技术主管的权威，在测试用例上支持他的决定。这两个人之间要是不和就炸了。
三：另外，在二的基础上，还有一些技巧。例如，产品责任人可以通过一些微妙状态特征暗示来（如，办公室的大小、地毯、装修、复印机等等）体现技术主管的威信，尽管决策权力的源泉来自管
理。如果说技术主管不太会管理，那么这会是个好方法。
这里有个小插曲：Robert Heinlein 在《出售月球的人》（“ The Man Who Sold the Moon “ ）中，用一幅场景描述了这样的情节：
Coster 低下 头， 双手捂着脸， 接着， 抬起头。“我知道。 我了解需要做什么——但每次我试图解决技术问题时， 总有些该死的笨蛋要我做一些关于卡车、 或者电话、 以及其他一些讨厌的事情。我很抱歉。 Harriman 先生，我原以为我可以处理好。”
Harriman非常温和的说：“ Bob ，别让这些事烦你。近来好像睡眠不大好，是吗？告诉你吧。 我将在你的位子上干几天，为你搭建一个免于这些事情干扰的环境。 我需要你的大脑工作在反向量、 燃油效率和压力设计上， 而不是卡车的合同。”
Harriman 走到门边 ， 扫了一圈，点了一个可能是、也可能不是办公室主要职员的工作人员。
“嘿，你！过来一下。”
那个人看上去有些惊慌，站了起来，走到门边说道，“什么事？”
“把角落上的那个桌子和上面所有的东西搬到本层楼的一个空的办公室去，马上。” 他监督着 Coster 和他的桌子移到另一个办公室， 看了看，发现新办公室的电话没有接上。
接着 ， 想了一下 ， 搬了一个长沙发过来。“ 今晚我们将安装一个投影仪、绘图仪、书架和其他一些东西” 他告诉 Coster 。“把你工程 所需要的东西列一个表。”
他回到了原来的总工程师办公室，愉快地想了想如何进行工作组织，以及是否有什么不妥。 过了四个小时，他带 Berkeley 进来 ，与 Coster 会面。这位总工程师正在他的桌子上睡觉， 头枕在臂弯里。 Har ri ma n 慢慢 地退出去， 但 Coster 醒 了过来。“喔，对不起，”他有点不好意思地说，“我肯定是打了个瞌睡。”
“这就是我 给你带来长 沙发的原因，” Harriman 说道。“它更 加舒适。 Bob ，来见一下Jock Berkeley 。他是你的 新奴隶，你仍是总工程师，毫无疑问的老板。 Jo ck 是其他一 切 的主管。从现在起，你不需要担心其他的任何问题，除了建造登月飞船的一些细节问题。”
他们握了一下手。“ Coster 先生，我 只想问一件事，” Berkeley 认真的说 ，“ 所有你需要做的事，我都无权过问——你即将进行一个技术演示——但是看在上帝的份上，能否记录一下， 从而让我了解一下。 我将会把一个开关放在你的桌上， 它会开启桌上的一个密封的录像机。”
“好的！” Coster 正看着他， Harriman 想，够年轻的。
“如果要做任何非技术的事情，不需要自己动手。只需按个按钮知会一声，它们就 会
被完成！” Ber ke le y 扫了 Harriman 一眼 。“老板说 他想同你谈一谈实际的工作。我得先走 ，去忙去了。”他离开了。
Harriman 坐了下来， Coster 整了整衣服，说道，“喔！”
“感觉好一些了？”
“我喜欢 Berkeley 这小伙子的样子。”
“太好了！不用担心，他现在就是你的孪生兄弟。我以前用过他。你可以认为你正住在一个头等的疗养院里。”
这个故事几乎不需要任何的分析解释，这种安排同样能使工作非常有效.
对于真正大型项目中的一些开发队伍，作者认为产品负责人作为管理者是更合适的安排。
巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个。
交流和交流的结果——组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。
总结:
本章节，以巴比伦塔的失败讲述了沟通交流的重要性，交流和组织（交流的结果）的问题。后面讲了管理人员和技术主管之间的角色安排和沟通问题。这些多少我们会日常有些思考，但是看作者讲述出来，感觉清晰了很多，想到自己的公司，问题显露无疑。
说实话，我实在无法做出简洁的总结，我觉得必须自己去看这本书，很多东西，只言片语，囫囵吞枣的说出来，没有任何意义。细嚼慢咽，滋味截然不同。
今天就到这里了。拜了个拜。
| to be continued |
| NEXT -> 读《人月神话》eight 胸有成竹（Calling the Shot） |
|---|
来源：CSDN
作者：莫莫绵
链接：https://blog.csdn.net/qq_36428889/article/details/103381070