结构化的产品开发(doc17)(1).docx

结构化的产品开发(doc17)(1).doc结构化的产品开发产品开发是复杂的。因为产品开发人员必须完成成千上万项工作,而这些工作大部分是与他人工作紧密相关的,协调便成为极其复杂的工作。为了能管理好这些庞大而复杂的工作,产品开发过程必须成为结构合理、定义清楚的过程。所谓结构化,是指相互关联的工作要有一个框架结构,并要有一定的组织原则来支持它,比如,在一个自上而下的层次构架中,上层结构简单一些,越到下层越繁杂越具体。所谓定义,是指每项工作都应清楚楚地明确规定出来。所有与产品开发有关的人应该清楚他们所参与的是什么工作,用什么方法去完成。尽管看起来简单,但令人惊讶的是许多公司并不能真正做到以上这些。在某些公司中,这种产品开发过程仍然是无结构的,大部分工作也未清楚地定义出来。在术语上没有一致性,即每个项目小组单独地确定自己的工作定义,尽管他们的许多定义与其它项目小组相类似。结果,各小组的项目进度表不能互相比较,因为有的小组定义了20项任务,有的小组却定义了1000项任务。这样就无法一致地衡量其进度,也不能用标准的周期时间估算方法来制定进度表。这对那些支持多个项目的人来说就更困难。没有一个共用的构架,产品开发过程便很难得到改进。有些公司的作法完全相反,它们详细地定义了产品开发过程,定义得过于详细了。为了控制每一细节,他们把每项工作应如何完成以及工作完成后应该是什么样子都一一设定好。这种方法最典型的特点是以文档资料为基础,对每项任务部需要准备一套详细编制的文档资料,并申请批准。每项任务的完成情况都受该文档的准备情况和批准情况的控制。这种官僚的管理方法经常是发布厚厚一本的规章制度,并带有详细检验标准,规定这些项目应如何完成。幸运的是,多数情况下,人们并没有真的这么做。按照他们这种做法,开发一个产品就要多花一倍的时间。许多公司由于匆匆定义产品开发过程而忽略了对结构的需要。对有些公司来讲,构架本身并不合适。不是层次定得不对,就是任务放错了位置;通常体现为在太短的时间内需要太多的信息。在PACE中,结构化产品开发在原则和创造力之间达成一种平衡。一个深思熟虑的过程并不会阻碍创造力,它允许开发小组把精力集中到开发产品这个实际问题上,并不需要每次重新建立开发过程。在PACE中,开发活动是以一个层次结构来构架的:从阶段(从最高和最广的一级)到步骤,到任务,最后再到各项活动(最具体的一级)。阶段对所有的项目来说都是一样的。正如第三章中所述,这是第一个决策层次。步骤对所有的项目也是一样的(虽然某些项目可能省略一些步骤),这是第一个制定计划和进度表的层次。任务就某个步骤如何完成提供指南。如果核心小组觉得这些指南合适的话,便可以照此执行。各项活动则完全由核心小组确定。这几点综合起来形成了一个决策、项目进度制定、资源规划、过程衡量以及持续改进的基础。结构和定义在开发过程中的必要性。由于多数公司没有把新产品开发视为一个过程,他们从不按照开发新产品的需要给要做的工作下定义,甚至连基本术语也没定义,例如,每个项目包括一份职责说明书。说明书的定义对参与项目的每一个人来说都应该很清楚,而不应该被某个工程师认为是一份10页纸的小结,被另一个工程师看作一份60页的文件,更不应该被第三个工程师看作一份400页的文件。缺乏统一的术语导致大量的时间和精力被浪费掉了,因为使用这些晦涩难懂过程的人极力想把它槁明白。比较常见的是,会议可能开了不少,但没有什么效果,开会的目的只是了解目前进行的工作。诸如此类的时间浪费,完全是由于缺乏结构所致。例如,一家数据通信公司,由于缺乏结构化过程,不得不为进行中的开发工作多花一倍的资源。根据调查,我们发现人们有30%的时间实际花在了产品设计上,而另外70%的时间全浪费在澄清关于正在做什么和由谁做的事情上。另外,由于术语不一致,使产品的技术规范有四个不同的名称和两套定义。我们在跨行业的许多公司中调查了好几百个从事产品开发的人,询问他们是如何从结构化开发过程中有所获益,得到的结果非常有趣:•小组间的交接常常出现误解和混乱:*在所有的交接任务中有30%引起了混淆和困惑,既浪费力气,又误导工作,不一而足。换句话说,如果一个项目有三件这种交接任务的话,至少有一件肯定会是一团糟。*有趣的是,22%的工作是在明知混淆和困惑的情况下放行的。原因很多,比如计划不周、执行仓促和纪律松驰等。这已经够烦了,但还没完,接到手的工作中还有39%是混乱的。在交接过程中,混乱的工作怎么会从22%增加到39%(相差17%,几乎是原来22%的两倍)呢?这是因为开发过程中不同小组之间关系从根本上说被相互误解了。换句话说,下游部门的需求未能被上游部门理解或欣赏。例如,CAD(计算机辅助设计)部或许不了解生产部的物料清单上需要什么具体的信息和规格,于是就在把任务交接给搞糟了。•由于上游部门出现变化,例如反馈顾客要求太晚、技术规格有错或一些问