有这么一家很典型的公司，不计其数的经理们只在他们有空的时候或是有什么特别原因使会议变得最优先的

时候，他们才参加产品开发小组的会议。由于这种方法产生的效果差，所以公司曾尝试用不同的方法来改变
这种状况。他们建立了专门的项目管理部门，负责监督进度和任务的提交，以明确由谁去做什么以及事情做

了没有。后来，每个部门都给每一个主要项目指定了自己部门的项目经理。但这些方法效果并不理想，只是
增加了毫无价值的劳动，而这种劳动已经太多了。

许多公司建立了项目小组的组织形式，但大多数效果不佳。针对这些不成功的案例，我们发现以下典型原因：

·如果项目小组和职能部门的责权不明确，将造成困惑。
·项目小组没有得到明确授权去实现目标，因而效率低下；在某些情况下，他们只被赋予了责任，却没有相

应的权力和资源。
·缺乏并行工程，一些职能和技能无法和谐地融入到项目小组中去。
·项目领导工作效率低，这源于几个因素：项目领导人没有经验；对项目领导人角色不明确；培训不足；项

目领导人更换频繁；或者项目小组的组织有缺陷。
·项目小组缺乏项目实施所需的人手和技能，因而无法实现目标；各种资源在项目小组间调来调去，缺乏明

确的决定。
·由于没有明确定义项目小组和职能部门之间的协作方法，两者之间便有冲突和困扰。
·小组成员任务分配造成的困扰使整个小组效率低下：比如说，小组成员把自己看作职能部门的评估者或记

录者，而非真正地帮助进行实时决策。

项目小组构成是产品开发流程的一个关键要素。一个高效的项目小组能极大地增进沟通、协作和决策。在评

审初期，我们就发现许多广为接受的项目小组模式效率低下，而低下的原因与上文所述颇为相似。我们开发
了一个新的模式。这个模式既能发挥项目小组这种组织形式的最佳方面，又能克服上述缺陷。我们把它称之

为项目小组构成中的核心小组模式（Core Team Approach）。

核心小组是有权开发特定产品的一个小型跨部门项目小组。一个典型的核心小组有 5—8 名成员，有权力也

有责任管理所有与开发该特定产品相关的任务。这些特定任务分配到核心小组的每个成员身上，每个成员都

利用相应资源完成这些任务。小组成员们为指定给他们的工作确定方向，与职能部门打交道，并作为核心小
组的一员参与集体决策。PAC 则在开发工作的每一阶段通过阶段评审流程赋予核心小组责任和权力。每个核

心小组都有一个指导和引导小组工作的领导人。该小组在执行每一开发阶段时遵守与 PAC 签定的有关重大

“

”

项目目标以及可变动的范围的 合同 。

3、开发活动的结构

开发活动是开发新产品的实质性工作。在 PACE 中，结构化的开发流程明确了应做什么开发工作、相应的先

后次序、其间的关联性以及用于开发项目的标准术语。在评审流程中，我们发现，开发活动的结构中往往存
在三类普遍的缺陷：(1)没有任何明确的产品开发结构的公司；(2)有具体流程手册但并没得到遵循的公司；
(3)有结构化的流程但并不能改进或加快开发进度的公司。

“

”

对第一种情况来说，公司必须在产品开发流程中不断地 重新发明车轮 ，即重新定义产品开发流程。每一
个项目小组都定义其要遵循的流程，结果，每个项目小组即使在执行相同的或相似的任务时，开发流程也迥

然不同。这种模式延长了开发周期，且整个公司的项目小组都易犯同样的错误。

对第二种情况来说，流程被文档化了，但是并没有得到执行。典型的情况是，某个职员在程序手册里定义开
发流程，然后把手册散发出去，天真地期待每个人都会遵守它，结果当然是他们并不遵守。多数情况下，他

们不遵守反而好一点。项目小组又各自将自己的那一套流程搬了出来。

对第三种情况来说，开发流程已得到明确和遵守，可惜这个流程天生就效率低下。令人吃惊的是，许多公司
在规范流程时，只是简单地将他们现有的做法写成文件，哪怕这个流程效率低下，其结果自然是把问题制度

化了。

在评审开发流程时，我们发现普遍存在下列缺陷：
·无章可循的开发活动导致产品不断更新。
·由于对必须完成什么样的开发活动及何时完成有误解，因而造成项目计划不周及准备不足。
·缺乏通用术语以及由此引起的理解问题，导致开发工作不理想。
·产品开发定义过于详细，尤其是缺乏结构化的定义，使得开发效率不高。
·每一步都需要多个签字盖章的官僚流程延缓了开发工作。
·缺乏并行工程，因为它没有被设计到结构化开发流程里。
·缺乏开发活动的周期时间指导，导致项目进度不准确。
·由于没有将责任落实下来，导致未能不断地改进产品开发流程。