6第五章结构化的产品开发

第五章结构化的产品开发迈克尔·T·安尔尼目录1.1.结构化和定义在开发过程中的必要性。....................................................31.2.开发过程结构的要素....................................................................................41.3.需要进一步结构化的征兆............................................................................51.3.1.术语和定义不一致................................................................................51.3.2.进度表不准确........................................................................................61.3.3.无法估计出资源需求............................................................................61.3.4.小组与小组之间的计划不衔接............................................................61.3.5.过量的任务间的相互依赖....................................................................61.3.6.对职责理解不够....................................................................................61.3.7.注意力集中在“救火”上....................................................................61.3.8.开发产品没有一个“统一方法”........................................................71.3.9.过多的澄清会议....................................................................................71.3.10.中层管理人员太多................................................................................71.3.11.浪费在没有附加值的工作上的时间。................................................71.3.12.到什么程度才够？................................................................................71.4.结构化开发的层次........................................................................................81.4.1.层次结构................................................................................................91.4.2.项目概述..............................................................................................101.4.3.步骤......................................................................................................111.4.4.任务和活动..........................................................................................111.4.5.详细的开发指南..................................................................................121.5.结构化开发的进度表..................................................................................121.5.1.三级进度表..........................................................................................131.5.2.周期指南..............................................................................................131.6.为什么一些公司未能成功地将它们的产品开发过程结构化..................142产品开发是复杂的。因为产品开发人员必须完成成千上万项工作，而这些工作大部分是与他人工作紧密相关的，协调便成为极其复杂的工作。为了能管理好这些庞大而复杂的工作，产品开发过程必须成为结构合理、定义清楚的过程。所谓结构化，是指相互关联的工作要有一个框架结构，并要有一定的组织原则来支持它，比如，在一个自上而下的层次构架中，上层结构简单一些，越到下层越繁杂越具体。所谓定义，是指每项工作都应清清楚楚地明确规定出来。所有与产品开发有关的人应该清楚他们所参与的是什么工作，用什么方法去完成。尽管看起来简单，但令人惊讶的是许多公司并不能真正做到以上这些。在某些公司中，这种产品开发过程仍然是无结构的，大部分工作也未清楚地定义出来。在术语上没有一致性，即每个项目小组单独地确定自己的工作定义，尽管他们的许多定义与其它项目小组相类似。结果，各小组的项目进度表不能互相比较，因为有的小组定义了20项任务，有的小组却定义了1000项任务。这样就无法一致地衡量其进度，也不能用标准的周期时间估算方法来制定进度表。这对那些支持多个项目的人来说就更困难。没有一个共用的构架，产品开发过程便很难得到改进。有些公司的作法完全相反，它们详细地定义了产品开发过程，定义得过于详细了。为了控制每一细节，他们把每项工作应如何完成以及工作完成后应该是什么样子都一一设定好。这种方法最典型的特点是以文档资料为基础，对每项任务部需要准备一套详细编制的文档资料，并申请批准。每项任务的完成情况都受该文档的准备情况和批准情况的控制。这种官僚的管理方法经常是发布厚厚一本的规章制度，并带有详细检验标准，规定这些项目应如何完成。幸运的是，多数情况下，人们并没有真的这么做。按照他们这种做法，开发一个产品就要多花一倍的时间。许多公司由于匆匆定义产品开发过程而忽略了对结构的需要。对有些公司来讲，构架本身并不合适。不是层次定得不对，就是任务放错了位置；通常体现为在太短的时间内需要太多的信息。在PACE中，结构化产品开发在原则和创造力之间达成一种平衡。一个深思熟虑的过程并不会阻碍创造力，它允许开发小组把精力集中到开发产品这个实际问题上，并不需要每次重新建立开发过程。在PACE中，开发活动是以一个层次结构来构架的：从阶段（从最高和最广的一级）到步骤，到任务，最后再到各项活动（最具体的一级）。阶段对所有的项目来说都是一样的。正如第三章中所述，这是第一个决策层次。步骤对所有的项目也是一样的（虽然某些项目可能省略一些步骤），这是第一个制定计划和3进度表的层次。任务就为某个步骤如何完成提供指南。如果核心小组觉得这些指南合适的话，便可以照此执行。各项活动则完全由核心小组确定。这几点综合起来形成了一个决策、项目进度制定、资源规划、过程衡量以及持续改进的基础。1.1.结构化和定义在开发过程中的必要性。由于多数公司没有把新产品开发视为一个过程，他们从不按照开发新产品的需要给要做的工作下定义，甚至连基本术语也没定义，例如，每个项目包括一份职责说明书。说明书的定义对参与项目的每一个人来说都应该很清楚，而不应该被某个工程师认为是一份10页纸的小结，被另一个工程师看作一份60页的文件，更不应该被第三个工程师看作一份400页的文件。缺乏统一的术语导致大量的时间和精力被浪费掉了，因为使用这些晦涩难懂过程的人极力想把它搞明白。比较常见的是，会议可能开了不少，但没有什么效果，开会的目的只是了解目前进行的工作。诸如此类的时间浪费，完全是由于缺乏结构所致。（澄清和达成一致的成本很高）例如，一家数据通信公司，由于缺乏结构化过程，不得不为进行中的开发工作多花一倍的资源。根据调查，我们发现人们有30％的时间实际花在了产品设计上，而另外70％的时间全浪费在澄清关于正在做什么和由谁做的事情上。另外，由于术语不一致，使产品的技术规范有四个不同的名称和两套定义。我们在跨行业的许多公司中调查了好几百个从事产品开发的人，询问他们是如何从结构化开发过程中有所获益，得到的结果非常有趣：1．小组间的交接常常出现误解和混乱：*在所有的交接任务中有30％引起了混淆和困惑，既浪费力气，又误导工作，不一而足。换句话说，如果一个项目有三件这种交接任务的话，至少有一件肯定会是一团糟。*有趣的是，22％的工作是在明知混淆和困惑的情况下放行的。原因很多，比如计划不周、执行仓促和纪律松弛等。这已经够烦了，但还没完，接到手的工作中还有39％是混乱的。在交接过程中，混乱的工作怎么会从22％增加到39％（相差17％，几乎是原来22％的两倍）呢？这是因为开发过程中不同小组之间关系从根本上说被相互误解了。换句话说，下游部门的需求未能被上游部门理解或欣赏。例如，CAD（计算机辅助设计）部或许不了解生产部的物料清单上需要什么具体的信息和规格，于是就在把任务交接给搞糟了。2．由于上游部门出现变化，例如反馈顾客要求太晚、技术规格有错或一些4问题被忽略等，造成42％的工作得重做。于是，每五个工作日中有两个被浪费了！如果消灭了重复性的工作，开发机构的生产率将会增加72％（有效工作从58％增加到100％）而不必增加任何人手。3．至少有48％的开发工作是“救火”，即解决那些出其不意地冒出的必须立刻加以解决的、无计划的工作。“救火”式的解决办法往往是“贴药膏”，因为时间压力大，资源有限，备选方案有限，而且许多设计已经不能更改了。“救火”式的工作方式是仓促完成的，常常有很多差错。（导致更多的“救火”）4．在开发人员个人制定的计划当中，有48％受到经理们或同级部门的质询、怀疑、忽视或被经理们或同级部门否定掉。由于产品开发本身是一个复杂的、涉及多个部门的过程，整个项目的总体进度表是需大量低级进度表的综合而成的。然而，每两个进度表中就有一个被否决。为什么会这样呢？很可能是因为早期的进度表只有45％是准确的！既然早期的进度表常常不准确，因此根本没有人相信它们。还有，管理人员常提出不合理的要求，开发小组就只好扩充进度表。5．令人惊讶的是，只有28％的开发工作是全新的，也就是说，72％的工作是熟悉的。如果是这样，为什么上述的问题还出现呢？因为没有结构化过程，没能汲取教训。把开发过程结构化是指把以前所做的72％的工作结构化，因为工作流程不畅，阻碍重重，使项目难以进行下去。一旦把这些工作条理化，开发小组就能把精力集中到28％真正新的有创造性的工作上，这才是最具增值的部分。这些调查结果表明，把开发过程结构化将会带来巨大的机