5 结构化的产品开发

-1-结构化的产品开发迈克尔·T·安东尼产品开发是复杂的。因为产品开发人员必须完成成千上万项工作，而这些工作大部分是与人工作紧密相关的，协调便成为极其复杂的工作。为了能管理好这些庞大而复杂的工作，产品开发过程必须成为结构合理、定义清楚的过程。所谓结构化，是指相互关联的工作要有一个框架结构，并要有一定的组织原则来支持它，比如，在一个自上而下的层次构架中，上层结构简单一些，越到下层越繁杂越具体。所谓定义，是指每项工作都应清清楚楚地明确规定出来。所有与产品开发有关的人应该清楚他们所参与的是什么工作，用什么方法去完成。尽管看起来简单，但令人惊讶的是许多公司并不能真正做到以上这些。在某些公司中，这种产品开发过程仍然是无结构的，大部分工作也未清楚地定义出来。在术语上没有一致性，即每个项目小组单独地确定自己的工作定义，尽管他们的许多定义与其它项目小组相类似。结果，各小组的项目进度表不能互相比较，因为有的小组定义了20项任务，有的小组却定义了1000项任务。这样就无法一致地衡量其进度，也不能用标准的周期时间估算方法来制定进度表。这对那些支持多个项目的人来说就更困难。没有一个共用的构架，产品开发过程便很难得到改进。有些公司的作法完全相反，它们详细地定义了产品开发过程，定义得过于详细了。为了控制每一细节，他们把每项工作应如何完成以及工作完成后应该是什么样子都设定好。这种方法最典型的特点是以文档资料为基础，对每项任务都需要准备一套详细编制的文档资料，并申请批准。每项任务的完成情况都受该文档的准备情况和批准情况的控制。这种官僚的管理方法经常是发布厚厚一本的规章制度，并带有详细检验标准，规定这些项目应如何完成。幸运的是，多数情况下，人们并没有真的这么做。按照他们这种做法，开发一个产品就要多花一倍的时间。许多公司由于匆匆定义产品开发过程而忽略了对结构的需要。对有些公司来讲，构架本身并不合适。不是层次定得不对，就是任务放错了位置；通常体现为在太短的时间内需要太多的信息。在PACE中，结构化产品开发在原则和创造力之间达成一种平衡。一个深思熟虑的过程并不会阻碍创造力，它允许开发小组把精力集中到开发产品这个实际问题上，并不需要每次重新建立开发过程。在PACE中，开发活动是以一个层次结构来构架的：从阶段（从最高和最广的一级）到步骤，到任务，最后再到各项活动（最具体的一级）。阶段对所有的项目来说都是一样的。正如第三章中所述，这是第一个决策层次。步骤对所有的项目也是一样的（虽然某些项目可能省略一些步骤），这是第一个制定计划和进度表的层次。任务就某个步骤如何完成提供指南。如果核心小组觉得这些指南合适的话，便可以照此执行。各项活动则完全由核心小组确定。这几点综合起来形成了一个决策、项目进度制定、资源规划、过程衡量以及持续改进的基础。结构和定义在开发过程中的必要性由于多数公司没有把新产品开发视为一个过程，他们从不按照开发新产品的需要给要做工的工作下定义，甚至连基本术语也没定义。例如，每个项目包括一份职责说明书。说明书的定义对参与项目的每一个人来说都应该很清楚，而不应该被某个工程师认为是一份10页-2-纸的小结，被另一个工程师看作一份60页的文件，更不应该被第三个工程师看作一份400页的文件。缺乏统一的术语导致大量的时间和精力被浪费掉了，因为使用这些晦涩难懂过程的人极力想把它搞明白。比较常见的是，会议可能开了不少，但没有什么效果，开会的目的只是了解目前进行的工作。诸如此类的时间浪费，完全是由于缺乏结构所致。例如，一家数据通信公司，由于缺乏结构化过程，不得不为进行中的开发工作多花一倍的资源。根据调查，我们发现人们有30％的时间实际花在了产品设计上，而另外70％的时间全浪费在澄清关于正在做什么和由谁做的事情上。另外，由于术语不一致，使产品的技术规范有四个不同的名称和两套定义。我们在跨行业的许多公司中调查了好几百个从事产品开发的人，询问他们是如何从结构化开发过程中有所获益，得到的结果非常有趣：1.小组间的交接常常出现误解和混乱：*在所有的交接任务中有39％引起了混淆和困惑，即浪费力气，又误导工作，不一而足。换句话说，如果一个项目有三件这种交接任务的话，至少有一件肯定会是一团糟。*有趣的是，22％的工作是在明知混淆和困惑的情况下放行的。原因很多，比如计划不周、执行仓促和纪律松弛等。这已经够烦了，但还没完，接到手的工作中还有39％是混乱的。在交接过程中，混乱的工作怎么会从22％增加到39％（相差17％，几乎是原来22％的两倍）呢？这是因为开发过程中不同小组之间关系从根本上说被相互误解了。换句话说，下游部门的需求未能被上游部门理解或欣赏。例如，CAD（计算机辅助设计）部或许不了解生产部的物料清单上需要什么具体的信息和规格，于是就在把任务交接给搞了。2.由于上游部门出现变化，例如反馈顾客要求太晚、技术规格有错或上些问题被忽略等，造成42％的工作得重做。于是，每五个工作日中有两个被浪费了！如果消灭了重复性的工作，开发机构的生产率将会增加72％（有效工作从58％增加到100％）而不必增加任何人手。3.至少有48％的开发工作是“救火”，即解决那些出其不意地冒出的必须立刻加以解决的、无计划的工作。“救火”式的解决办法往往是“贴药膏”因为时间压力大，资源有限，备选方案有限，而且许多设计已经不能更改了。“救火”式的工作方式是仓促完成的。常常有很多差错。4.在开发人员个人制定的计划当中，有48％受到经理们或同级部门的质询、怀疑、忽视或被经理们或同级部门否定掉。由于产品开发本身是一个复杂的、涉及多个部门的过程，整个项目的总体进度表是需大量低级进度表的综合而成的。然而，每两个进度表中就有一个被否决。为什么会这样呢？很可能是因为早期的进度表只有45％是准确的！既然早期的进度表常常不准确，因此根本没有人相信他们。还有，管理人员常提出不合理的要求，开发小组就只好扩充进度表。5.令人惊讶的是，只有28％的开发工作是全新的，也就是说，72％的工作是熟悉的。如果是这样，为什么上述的问题还出现呢？因为没有结构化过程，没有能汲取教训，把开发过程结构化是指把之前所做的72％的工作结构化，因为工作流程不畅，阻碍重重，使项目难以进行下去。一旦把这些工作条理化，开发小组就能把精力集中到28％真正新的有创造性的工作上，这才是最具增值的部分。这些调查结果表明，把开发过程结构化将会带来巨大的机会。开发过程结构的要素革新与创造是无法精确地计划和控制的，但是，把日常工作安排得井井有条可使注意力-3-集中到更有创造性的产品开发方面。通常，在纯技术机构中，人们还很关心开发过程的构架。许多人把产品开发看作成一个创造性的过程。不错，产品开发的部分工作需要有所创新。重要的是，一旦搞开发创造的人理解了开发过程结构实际上是把他们从繁杂、单调的任务中解放了出来，使他们能将更多的时间花在创造性的增值工作上。例如，如果不让工程师们把时间花在确定某项功能规范的纲要及格式上，他们就会很有效地把时间用在运用标准格式和定义产品上。许多人觉得结构把人限制住了，抱怨说它太死板，缺乏灵活性。对此我们表示同意。错误的结构层次会造成大量的书面工作和官僚主义。重要的是，应该针对某种特定产品找到合适它的结构层次。在与客户的初期交往中，常常听到这样的说法，“结构化开发过程在我们这儿不会有用的，因为我们从来不重复同样的项目”。这话绝对站不住脚，因为即使完全不同的产品也一定有许多共同之处。而且，如果每次产品开发采用的方式都不同，则会出现两种情况。第一，没有积累的经验可参考，没有应学习的榜样，所以当项目越做越大时，开发周期时间也变得越来越长。第二，当某个人拿出改进方法或窍门时，没有把它标准化并运用于其它项目中。如果每次开发过程的步骤不是以同样方式进行，便很难衡量它的过程并加以改进。许多技术人员对结构感到很不舒服，担心受到约束后，会失去灵活性和创造性。然而，如果真正理解了产品开发工作，就很容易明白其中大部分工作并不是新的。正如前面调查中所述的，大部分产品开发任务并不真正是新的。如果将重复性的任务进行结构化，技术专家就能把更多的精力集中在真正新的，以前没有做过的工作上。例如，一家做先进系统的公司，有一个高级技术员不相信产品开发能够结构化，当问及她正在进行的新设计时，她最初的回答是，“这都是全新的”。进一步调查之后，我们发现，从硬件意义上讲，在五十六个电路板中，只有两个是新的。然后，在对这两块电路板逐个进行仔细观察后，她确认只有于四个ASIC集成电路和一些支持逻辑是新的。还有另一家公司，是专为大的防御设施承包商设计预警系统的，错误地把产品种类多和小批量生产作为成本超支与赶不上进度的借口。这家公司认为，每个项目是不同的，这种循环不可能调整过来。一旦该公司明白，虽然项目可能是不同的，但也有共同的过程因素，那么，它就能够将过程结构化，提高竞争力。需要进一步结构化的征兆公司需要进一步结构化的迹象有很多。术语和定义不一致每个公司都有它自己的产品开发语言。不幸的是，这种语言太类似于巴尔塔的情形，即各人有各人的讲法，但都以为别人和他的理解是一样的。工作的背景和范围由于一个项目间的术语不一致，人们就不能了解工作的背景和范围，在一家公司里，同一个市场评估文件有十个不同的名称。每个版本都稍有不同，但是时间一长这些差异就变得比较模糊不清了。最后，没有人能确切地知道这个文件该有些什么内容。这种混乱导致了大量没有附加价值的活动，因为这些活动是用来理解当人们使用一个术语或说要完成一项任务时它们真正指的是什么。进度表不准确产品开发进度表应该和构成它的步骤一样准确，如果对步骤的理解不清楚，那么就很难估计它化要用多长时间。如果它的定义不一致，那么，就不可能用过去的经验作为参考。没-4-有结构化的过程常常导致进度不准确，因为人们制定进度表时依据的假设并不为该机构中的其他人所分享或了解。没有进度表是进度表不准确的极端现象。无法估计出资源要求对资源需求的估计必须和对完成每个步骤所需进时间的估计一样准确。对每个步骤没有一个好的统一定义，就不可能作出合理的估计。如果估计不准确，公司新产品的开发就会连续不断地误期，其项目资源不是不够就是过量。结构化有助于首先确定必须做什么和花多长时间，一旦理解了这一点，就会大大提高对资源需求的准确估计能力。小组与小组之间的计划不衔接如果没有结构，就没有做出重要决策的基础。一个职能部门作的计划并不一定和其它部门的工作衔接在一起，结果重要的工作给忽略不。有一家缺乏结构的电子系统公司因没有统一的构架，统一的术语，和统一的定义而饱受其苦。结果，领导人员常常被具体细节搞得晕头转向。每一个项目经理都提出不同的格式、过程和具体标准。执行经理们一般见树不见林。他们抓住不太重要的几点就作出决策，没有从全局上搞清楚它们是如何联系在一起的。如果没有结构，小组之间的计划协调事实上是不可能的，因为每个人对必定出现什么样的情况都有不同的理解。过量的任务间的相互依赖现象。没有结构或结构差的过程就会导致这种大量浪费时间的现象。明确过程任务并对每个过程的要求作出定义可以大大地降低任务的相互依赖性，这样，低成本工作就不会拖高成本工作的后腿。对职责理解不够结构差使人们不知道谁或哪个小组负责完成哪些具体工作。对那些人们并不能很好地了解重要任务的机构，PRTM常给它们提供咨询。我们发现在一些人员饱和的部门中，没有人确切知道这个部门在干什么。这就是开发过程混乱和工作职责不明晰的重要标志。注意力集中在“救火”上过量的“救火”工作是公司产品开发过程结构欠佳的征兆。有一家电脑公司向我们咨询，因为该公司陷入了“救火”的尴尬境地，执行经理热衷于跳将进来，卷起袖子，帮助解决问题。他们觉得，在危机间跳来蹦去，比为每个人制定策略和目标舒服得多。当执行经理要一个项目小组在每天上午八点下午五点各做一次一小时的最新进展汇报时，这种情况就达到了高潮。每次状态跟踪汇报，小组都得花去一个小时做准备，这样每天就浪费了四个小时的有效工作时间。开发产品没有一个“统一方法”有一家电子影像业公司，它的每个项目者缺乏统一性。对每个项目来说，开发新产品所遵循的步骤是在不同的