《人月神话》的笔记- 为什么巴比伦塔会失败?

《人月神话》的笔记- 为什么巴比伦塔会失败?

4830发表于2017-05-14

巴比伦塔具备了所有的我们认为的必备条件,为什么还会失败呢。


他们还缺乏两个方面﹣交流,以及交流的结果﹣组织。


原文中是上帝制造了混淆,使得各个部落之间互相猜忌最终导致了项目的彻底失败。在实际的项目中,可以说这种混淆是不可避免会存在的,不是人为主观制造,首先一个项目在需求的获取过程中就会存在着用户与需求获取人员之间的理解差异,或许同样的一句话,经过获取人员的理解转述后就会有不一样的意义,更别说转义为书面语言正式成为文档,即便是在看文档的过程中,再规范的文档都会有令人迷惑的部分,此时就体现出了交流的重要性,团队中的每个人员都有必要进行积极的交流,以求在交流的过程中消除混淆,保证项目的正常进行。


团队之间的交流途径,通过可能的所有途径:


非正式途径:电话… 会议:常规项目会议 工作手册:在项目的开始阶段应该准备正式的项目工作手册。


工作手册不是一个严格的项目技术文档。

它是对项目必须产出的一系列文档进行组织结构的一部分

我的理解是这个所谓的工作手册在今天看来实际上就可以说是项目的wiki(注意这本书的作者是在1986年写的啊啊啊啊)和show diff的选项。


?大型项目的组织结构

让我们考虑一下树状编程队伍,以及要使他们有效,每棵子树所必须具备的基本要素:

1、任务(a mission) 

2、产品负责人(a producer) 

3、技术主管或结构师(a technical director or architect) 

4、进度(a schedule) 

5、人力的划分(a division of labor) 

6、各部分之间的接口协议(interface definitions among parts)

产品负责人 vs. 技术主管或结构师
产品负责人(producer)
职责:组建团队,划分工作及指定进度表。争取,并保证必要的资源。
这意味着他主要的工作是与团队外部进行向上的沟通和水平的沟通。他建立团队内部的沟通和报告方式。最后,他确保进度目标的实现,根据环境的变化调整资源和团队的架构。

技术主管或结构师(technical director / architect)
提供整个设计的一致性和概念完整性,控制系统的复杂程度。当某个技术问题出现时,他提供问题的解决方案,或根据需要调整系统设计。
他的工作几乎完全是技术性的。

在各个职能安排何划分中,产品经理和技术主管的角色安排是最难的,两种角色的任意组合都可以是非常有效的。通常情况下,会有几种方案:

1、技术主管和产品经理是同一个人。-- 这种情形对于3~6人的小团队非常容易应用,但对于大型的项目则不容易获得应用。原因一,同时具有管理技能和技术技能的人很难找到;原因二,工作量。。

2、产品负责人指挥,技术主管充当左右手。这种情况相当难,很难在技术主管不参与任何管理工作的同时,建立起其在技术上的权威。

-- 这种配置的关键在于,技术主管在技术决策上的权威要得到肯定,另外产品负责人必须在基本的技术理论上和技术主管具有相似的观点,并支持后者的技术决定。

3、技术主管作为总指挥,产品经理作为其左右手。还是适用于小型团队。

在构建大型开发团队时,往往还是产品经理作为决策者,我们可不可以这样认为,在以后的公司诉求中,会有这么一种情况发生,就是技术主管可以先由小的项目开始进行锻炼,加上相关管理知识的学习以及在大型项目中充当副手见习的经验渐渐转型为可以胜任产品经理工作的人?

也就是说,一个好的公司运作,不仅仅是要有好的技术人才,其实更需要的是一个产品经理对其产品进行高瞻远瞩式的决策以减少相应的损失。

综上,团队内外量好的沟通以及良好的团队架构均是一个项目能否成功的关键所在

============

项目经理的基本职责是使每个人都向着相同的方向前进,所以他的主要工作是沟通,而不是作出决定。

项目经理的任务是制定计划,并实现计划。

只有书面计划是精确和可以沟通的。 ...... 通过遵循文档开展工作,项目经理能够更清晰和快速的设定自己的方向。

小编蓝狐