在满足技术条件、目标清晰、人力充足、材料丰富以及时间充足的前提下,为什么项目还会失败?因为缺乏两个方面,其一是交流;其二是交流的结果-组织。
1、项目的交流方式
1.1、工作手册
是项目必须产出的一系列文档进行组织的一种结构。使用项目手册的一个原因是:里面不仅仅记录了设计思路,还有很多项目演进过程中的信息,甚至可以追溯到项目最开始阶段的设计资料。另外一个原因是:控制信息发布,这不是为了限制信息,而是确保信息能到达所有需要它的人的手中。工作手册的目录结构一旦稳定下来,不会轻易修改,可能修改的是分发机制和查询方法。对于编程人员,他可以查阅手册,并了解自己负责的部分,而不是整个系统的开发细节时,他的工作效率更高。前提条件是手册里精确完整地定义所有接口。
工作手册的目的还有一个就是:尽可能在传递完整信息的同时,减少交流而不是增加交流成本。
1.2、项目的组织结构
良好的组织结构是降低交流成本的关键措施。人力划分和限定职责范围是减少交流的方法,当采用这种方式时,树状管理结构反应出对详细交流的需求会相应减少。管理角色的非重复性导致了管理结构是树状的,同时也是权力和责任的结构。树状结构有利于交流,缺不能用来描述交流沟通,因为交流是通过树状结构进行的。
对大型项目,它有很多的子项目,其任意一个子项目就是一棵管理子树,子树具备的基本要素。
(1)任务
(2)产品负责人
(3)技术主管或者架构师
(4)进度
(5)人力的划分
(6)各部分之间接口的定义
管理树中核心的要素就是:产品负责人和技术主管。
产品负责人:他组建团队,划分工作以及制定进度表。他争取,并一直保证必要的资源。这意味着他主要的工作是与团队外部进行向上沟通和水平沟通。他建立团队内部的沟通和报告方式。最后,他确保进度目标的实现,根据环境的变化调整资源和团队的架构。
技术主管:他对设计进行构思,识别系统的子部分,指明从外部看上去的样子,勾画它的内部结构,他提供整个设计的一致性和概念的完整性;他控制系统的复杂程度。他的工作几乎是完全技术性的。
存在三种可能的关系。
(1)产品负责人和技术主管是同一个人。这种方式可以非常容易的应用在小型的队伍中,这样的队伍可能有3~6个开发人员,而在大型项目中则不容易获得应用。原因有两个:第一,同时具备管理技能和技术技能的人很难找,第二,大型项目中,每个角色必须全职工作,甚至还要加班。
(2)产品负责人作为总指挥,技术主管充当其左右手。这种方式有一些困难,很难在技术主管不参与任何管理工作的同时,建立其在技术决策上的权威。这种组合很少被应用。
(3)技术主管作为总指挥,产品负责人充当其左右手。这种安排也非常适合小型团队。
《人月神话》的作者认为,对于真正的大型项目中的一些开发队伍,产品负责人作为管理者是更合适的安排。
对于任何一个项目,交流和交流的结果组织是成功的关键。