巴比伦塔的管理教训-项目失败的原因

在满足技术条件、目标清晰、人力充足、材料丰富以及时间充足的前提下，为什么项目还会失败？因为缺乏两个方面，其一是交流；其二是交流的结果-组织。

1、项目的交流方式

1.1、工作手册

是项目必须产出的一系列文档进行组织的一种结构。使用项目手册的一个原因是：里面不仅仅记录了设计思路，还有很多项目演进过程中的信息，甚至可以追溯到项目最开始阶段的设计资料。另外一个原因是：控制信息发布，这不是为了限制信息，而是确保信息能到达所有需要它的人的手中。工作手册的目录结构一旦稳定下来，不会轻易修改，可能修改的是分发机制和查询方法。对于编程人员，他可以查阅手册，并了解自己负责的部分，而不是整个系统的开发细节时，他的工作效率更高。前提条件是手册里精确完整地定义所有接口。

工作手册的目的还有一个就是：尽可能在传递完整信息的同时，减少交流而不是增加交流成本。

1.2、项目的组织结构

       良好的组织结构是降低交流成本的关键措施。人力划分和限定职责范围是减少交流的方法，当采用这种方式时，树状管理结构反应出对详细交流的需求会相应减少。管理角色的非重复性导致了管理结构是树状的，同时也是权力和责任的结构。树状结构有利于交流，缺不能用来描述交流沟通，因为交流是通过树状结构进行的。

      对大型项目，它有很多的子项目，其任意一个子项目就是一棵管理子树，子树具备的基本要素。

（1）任务

（2）产品负责人

（3）技术主管或者架构师

（4）进度

（5）人力的划分

（6）各部分之间接口的定义

 

管理树中核心的要素就是：产品负责人和技术主管。

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

技术主管：他对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构，他提供整个设计的一致性和概念的完整性；他控制系统的复杂程度。他的工作几乎是完全技术性的。

存在三种可能的关系。

（1）产品负责人和技术主管是同一个人。这种方式可以非常容易的应用在小型的队伍中，这样的队伍可能有3~6个开发人员，而在大型项目中则不容易获得应用。原因有两个：第一，同时具备管理技能和技术技能的人很难找，第二，大型项目中，每个角色必须全职工作，甚至还要加班。

（2）产品负责人作为总指挥，技术主管充当其左右手。这种方式有一些困难，很难在技术主管不参与任何管理工作的同时，建立其在技术决策上的权威。这种组合很少被应用。

（3）技术主管作为总指挥，产品负责人充当其左右手。这种安排也非常适合小型团队。

 

《人月神话》的作者认为，对于真正的大型项目中的一些开发队伍，产品负责人作为管理者是更合适的安排。

 

对于任何一个项目，交流和交流的结果组织是成功的关键。