产品开发是复杂的。因为产品开发人员必须完成成千上万项工作，而这些工作大部分是与他人工作紧密相关的，协调便成为极其复杂的工作。为了能管理好这些庞大而复杂的工作，产品开发过程必须成为结构合理、定义清楚的过程。

所谓结构化，是指相互关联的工作要有一个框架结构，并要有一定的组织原则来支持它，比如，在一个自上而下的层次构架中，上层结构简单一些，越到下层越繁杂越具体。所谓定义，是指每项工作都应清楚楚地明确规定出来。所有与产品开发有关的人应该清楚他们所参与的是什么工作，用什么方法去完成。

尽管看起来简单，但令人惊讶的是许多公司并不能真正做到以上这些。在某些公司中，这种产品开发过程仍然是无结构的，大部分工作也未清楚地定义出来。在术语上没有一致性，即每个项目小组单独地确定自己的工作定义，尽管他们的许多定义与其它项目小组相类似。结果，各小组的项目进度表不能互相比较，因为有的小组定义了20项任务，有的小组却定义了1000项任务。这样就无法一致地衡量其进度，也不能用标准的周期时间估算方法来制定进度表。这对那些支持多个项目的人来说就更困难。没有一个共用的构架，产品开发过程便很难得到改进。

有些公司的作法完全相反，它们详细地定义了产品开发过程，定义得过于详细了。为了控制每一细节，他们把每项工作应如何完成以及工作完成后应该是什么样子都一一设定好。这种方法最典型的特点是以文档资料为基础，对每项任务部需要准备一套详细编制的文档资料，并申请批准。每项任务的完成情况都受该文档的准备情况和批准情况的控制。这种官僚的管理方法经常是发布厚厚一本的规章制度，并带有详细检验标准，规定这些项目应如何完成。幸运的是，多数情况下，人们并没有真的这么做。按照他们这种做法，开发一个产品就要多花一倍的时间。

许多公司由于匆匆定义产品开发过程而忽略了对结构的需要。对有些公司来讲，构架本身并不合适。不是层次定得不对，就是任务放错了位置；通常体现为在太短的时间内需要太多的信息。

在PACE中，结构化产品开发在原则和创造力之间达成一种平衡。一个深思熟虑的过程并不会阻碍创造力，它允许开发小组把精力集中到开发产品这个实际问题上，并不需要每次重新建立开发过程。

在 PACE中，开发活动是以一个层次结构来构架的：从阶段（从最高和最广的一级）到步骤，到任务，最后再到各项活动（最具体的一级）。阶段对所有的项目来说都是一样的。正如第三章中所述，这是第一个决策层次。步骤对所有的项目也是一样的（虽然某些项目可能省略一些步骤），这是第一个制定计划和进度表的层次。任务就某个步骤如何完成提供指南。如果核心小组觉得这些指南合适的话，便可以照此执行。各项活动则完全由核心小组确定。这几点综合起来形成了一个决策、项目进度制定、资源规划、过程衡量以及持续改进的基础。

结构和定义在开发过程中的必要性。

由于多数公司没有把新产品开发视为一个过程，他们从不按照开发新产品的需要给要做的工作下定义，甚至连基本术语也没定义，例如，每个项目包括一份职责说明书。说明书的定义对参与项目的每一个人来说都应该很清楚，而不应该被某个工程师认为是一份10页纸的小结，被另一个工程师看作一份60页的文件，更不应该被第三个工程师看作一份400页的文件。

缺乏统一的术语导致大量的时间和精力被浪费掉了，因为使用这些晦涩难懂过程的人极力想把它槁明白。比较常见的是，会议可能开了不少，但没有什么效果，开会的目的只是了解目前进行的工作。诸如此类的时间浪费，完全是由于缺乏结构所致。

例如，一家数据通信公司，由于缺乏结构化过程，不得不为进行中的开发工作多花一倍的资源。根据调查，我们发现人们有30％的时间实际花在了产品设计上，而另外70％的时间全浪费在澄清关于正在做什么和由谁做的事情上。另外，由于术语不一致，使产品的技术规范有四个不同的名称和两套定义。

我们在跨行业的许多公司中调查了好几百个从事产品开发的人，询问他们是如何从结构化开发过程中有所获益，得到的结果非常有趣：

1．小组间的交接常常出现误解和混乱：

2．由于上游部门出现变化，例如反馈顾客要求太晚、技术规格有错或一些问题被忽略等，造成42％的工作得重做。于是，每五个工作日中有两个被浪费了！如果消灭了重复性的工作，开发机构的生产率将会增加72％（有效工作从 58％增加到100％）而不必增加任何人手。

3．至少有48％的开发工作是“救火”，即解决那些出其不意地冒出的必须立刻加以解决的、无计划的工作。“救火”式的解决办法往往是“贴药膏”，因为时间压力大，资源有限，备选方案有限，而且许多设计已经不能更改了。“救火”式的工作方式是仓促完成的，常常有很多差错。

4．在开发人员个人制定的计划当中，有48％受到经理们或同级部门的质询、怀疑、忽视或被经理们或同级部门否定掉。由于产品开发本身是一个复杂的、涉及多个部门的过程，整个项目的总体进度表是需大量低级进度表的综合而成的。然而，每两个进度表中就有一个被否决。为什么会这样呢？很可能是因为早期的进度表只有45％是准确的！既然早期的进度表常常不准确，因此根本没有人相信它们。还有，管理人员常提出不合理的要求，开发小组就只好扩充进度表。

5．令人惊讶的是，只有28％的开发工作是全新的，也就是说，72％的工作是熟悉的。如果是这样，为什么上述的问题还出现呢？因为没有结构化过程，没能汲取教训。把开发过程结构化是指把以前所做的72％的工作结构化，因为工作流程不畅，阻碍重重，使项目难以进行下去。一旦把这些工作条理化，开发小组就能把精力集中到28％真正新的有创造性的工作上，这才是最具增值的部分。

这些调查结果表明，把开发过程结构化将会带来巨大的机会。

开发过程结构的要素

革新与创造是无法精确地计划和控制的，但是，把日常工作安排得井井有条可使注意力集中到更有创造性的产品开发方面。通常，在纯技术机构中，人们还很关心开发过程的构架。许多人把产品开发看作成一个创造性的过程。不错，产品开发的部分工作需要有所创新。重要的是，一旦搞开发创造的人理解了开发过程结构实际上是把他们从繁杂、单调的任务中解放了出来，使他们能将更多的时间花在创造性的增值工作上。例如，如果不让工程师们把时间花在确定某项功能规范的纲要及格式上，他们就会很有效地把时间用在运用标准格式和定义产品上。

许多人觉得结构把人限制住了，抱怨说它太死板，缺乏灵活性。对此我们表示同意。错误的结构层次会造成大量的书面工作和官僚主义。重要的是，应该针对某种特定产品找到合适它的结构层次。

在与客户的初期交往中，常常听到这样的说法，“结构化开发过程在我们这儿不会有用的，因为我们从来不重复同样的项目。”这话绝对站不住脚，因为即使完全不同的产品也一定有许多共同之处。

而且，如果每次产品开发采用的方式都不同，则会出现两种情况。第一，没有积累的经验可参考，没有应学习的榜样，所以当项目做得越来越大时，开发周期时间也变得越来越长。第二，当某个人拿出改进方法或窍门时，没有把它标准化并运用于其它项目中。如果每次开发过程的步骤不是以同样方式进行，便很难衡量它的过程并加以改进。

许多技术人员对结构感到很不舒服，担心受到约束后，会失去灵活性和创造性。然而，如果真正理解了产品开发工作，就很容易明白其中大部分工作并不是新的。正如前面调查中所述的，大部分产品开发任务并不真正是新的。如果将重复性的任务进行结构化，技术专家就能把更多的精力集中在真正新的，以前没有做过的工作上。

例如，一家做先进系统的公司，有一个高级技术员不相信产品开发能够结构化，当问及她正在进行的新设计时，她最初的回答是，“这都是全新的”。进一步调查之后，我们发现，从硬件意义上讲，在五十六个电路板中，只有两个是新的。然后，在对这两块电路板逐个进行仔细观察后，她确认只有四个ASIC集成电路和一些支持逻辑是新的。

还有另一家公司，是专为大的防御设施承包商设计预警系统的，错误地把产品种类多和小批量生产作为成本超支与赶不上进度的借口。这家公司认为，每个项目是不同的，这种循环不可能调整过来。一旦该公司明白，虽然项目可能是不同的，但也有共同的过程因素，那么，它就能够将过程结构化，提高竞争力。需要进一步结构化的征兆

公司需要进一步结构化的迹象有很多。

术语和定义不一致

每个公司都有它自己的产品开发语言。不幸的是，这种语言太类似于巴贝尔塔的情形，即各人有各人的讲法，但都以为别人和他的理解是一样的。工作的背景和范围由于一个项目间的术语不一致，人们就不能了解工作的背景和范围，在一家公司里，同一个市场评估文件有十个不同的名称。每个版本都稍有不同，但是时间一长这些差异就变得比较模糊不清了。最后，没有人能确切地知道这个文件该有些什么内容。这种混乱导致了大量没有附加价值的活动，因为这些活动是用来理解当人们使用一个术语或说要完成一项任务时它们真正指的是什么。

进度表不准确

产品开发进度表应该和构成它的步骤一样准确，如果对步骤的理解不清楚，那么就很难估计它们要用多长时间。如果它的定义不一致，那么，就不可能用过去的经验作为参考。没有结构化的过程常常导致进度不准确，因为人们制定进度表时依据的假设并不为该机构中的其他人所分享或了解。没有进度表是进度表不准确的极端现象。

无法估计出资源需求

对资源需求的估计必须和对完成每个步骤所需时间的估计一样准确。对每个步骤没有一个好的统一定义，就不可能作出合理的估计。如果估计不准确，公司产品的开发就会连续不断地误期，其项目资源不是不够就是过量。结构化有助于首先确定必须做什么和花多长时间，一旦理解了这一点，就会大大提高对资源需求的准确估计能力。

小组与小组之间的计划不衔接

如果没有结构，就没有做出重要决策的基础。一个职能部门作的计划并不一定和其它部门的工作衔接在一起，结果重要的工作给忽略了。有一家缺乏结构的电子系统公司因没有统一的构架，统一的术语，和统一的定义而饱受其苦。结果，领导人员常常被具体细节搞得晕头转向。每一个项目经理都提出不同的格式、过程和具体标准。执行经理们一般见树不见林。他们抓住不太重要的几点就作出决策。没有从全局上搞清楚它们是如何联系在一起的。如果没有结构，小组之间的计划协调事实上是不可能的。因为每个人对必定出现什么样的情况都有不同的理解。

过量的任务间的相互依赖

当开发过程中的任务受到拖延或排队等候另一项任务完成时，就出现了过量的任务相互依赖现象。没有结构或结构差的过程就会导致这种大量浪费时间的现象。明确过程任务并对每个过程的要求作出定义可以大大地降低任务的相互依赖性，这样，低成本工作就不会拖高成本工作的后腿。

对职责理解不够

结构差使人们不知道谁或哪个小组负责完成哪些具体工作。对那些人们并不能很好地了解重要任务的机构，PRTM常给它们提供咨询。我们发现在一些人员饱和的部门中，没有人确切知道这个部门在干什么。这就是开发过程混乱和工作职责不明晰的重要标志。

注意力集中在“救火”上

过量的“救火”工作是公司产品开发过程结构欠佳的征兆。有一家电脑公司向我们咨询，因为该公司陷入了"救火"的尴尬境地，执行经理热衷于跳将进来，卷起袖子．帮助解决问题。他们觉得，在危机间跳来蹦去，比为每个人制定策略和目标舒服得多。当执行经理要一个项目小组在每大上午八点和下午五点各做一次一小时的最新进展汇报时，这种情况就达到了高潮。每次状态跟踪汇报，小组都得花一个小时做准备，这样每天就浪费了四个小时的有效工作时间。

开发产品没有一个“统一方法”

有一家电子影像业公司，它的每个项目都缺乏统一性。对每个项目来说，开发新产品所遵循的步骤是在不同的地点和时间发生的。许多工作都有不同的命名方法，这样，即使是在该部门工作多年的人也难以理解正在干什么事。结果，没有人利用己经开发出来的好方法。

过多的澄清会议

不良的结构过程导致了为澄清工作而召开大量会议。因为下一个步骤模糊不清，所以就要求这些会议要搞清楚已经完成了什么，下一步必须完成什么，以及由谁来作。过多的会议是不良结构的一种迹象。

中层管理人员太多

如果领导层必须做每一个决策时，就证明需要对新产品开发进行结构。结构化过程使人容易了解每个项目与整个产品系列计划的配合、和研究开发或技术策略的结合，以及它在财务上的合理性。如果没有结构，就需要更多的中层管理人员来处理这种混乱状况。在具有合适结构层次的一些公司里，中层人员就比较少，因为不需要他们来控制过程。

浪费在没有附加值的工作上的时间。

为了解释术语和意图，不得不做大量的没有附加值的工作。这种工作量是非常巨大的。如果没有结构，沟通上的误解就会使人们把更多的时间花在协调工作和重做已经完成的任务上。

一个将开发过程结构化了的系统公司就消除了过程中的一些空白（空白是指所花费的没有给项目带来附加值的时间）。结果这个公司就把新产品的周期时间削减了百分之二十三。一位负责工程的副总裁说，“这件事情的真正价值是我们现在能够把省下来的时间和资源用在别的地方，使我们能够腾出时间和精力开发更多的新产品。”