1. 第四章 项目组织的核心小组法
迈克尔·T·安东尼
目 录
目 录................................................................................................1
. 成功项目小组组织的特征............................................................................1
. 沟通........................................................................................................2
. 工作的协调............................................................................................4
. 决策........................................................................................................5
. 产品开发的职能组织....................................................................................6
. 核心小组法............................................................................................9
. 核心小组组长......................................................................................10
. 核心小组成员......................................................................................11
. 全员项目小组......................................................................................11
. 核心小组协调人..................................................................................12
. 职能经理..............................................................................................12
. 产品上市时间及项目组织..........................................................................13
. 授权..............................................................................................................14
. 实施并行工程..............................................................................................15
. 一些公司采用跨职能项目小组未能成功的原因......................................17
新产品的开发需要许多人的共同努力——这些人应用不同的技术，共同克服
成千上万的困难来开发一个新产品。为了合作成功，他们需要步调一致、相互沟
通并且要共同做出决策。为此，应有一个有效的项目小组组织。
项目组织是产品开发中的一个最重要因素，但是很少公司能够在这方面采取
一套持续而又有效的方法。一些公司甚至连组织产品开发项目的方法也未能明确
规定；它们让每个开发小组自己去想怎么组织。没有明确界定的项目组织，就好
比挑选了一些人组成一个足球队，然后就直接让他们上场踢球。这些队员对应该
踢哪一个位置一无所知，更不知道如何进行团队合作。他们甚至不知道谁该什么
时候上场以及每个队员该做些什么。一个足球队如果这样子一团混乱，要想赢球
难过登天。
还有一些公司虽然能够描述他们的组织方法，却无法调动其小组有效地工作。
这通常是因为组织内有冲突，或者组织成员在如何进行小组工作的问题上理解不
一致。一些公司不断尝试各种各样的组织方法，希望终有一人找到能行得通的那
条路。每当碰到大难题，他们就改变一套项目组织方法，希望借此推进产品开发。
一个配合默契、迅速将产品推向市场的开发小组，与一帮徒然将时间浪费在
每周例会上的各职能部门代表的聚合，两者之间的区别在哪里呢？前者在沟通、
协调以及决策方面卓有成效。这是一个成功的小组所必须具备的最基本的素质。
为了获得这些素质，PRTM 开发了一套用于达成项目组织的核心小组法。这
套方法通过有效的沟通、协调以及决策，达到尽快将产品推向市场的目的。核心
小组法同时也提供了一个给小组真正授权的基础，以及产品开发过程中并行工程
工作的实施基础。
.成功项目小组组织的特征
成功项目小组组织的秘诀在于组织小组进行有效的沟通、协调以及制定决
策。表现出色的小组成员彼此间能够十分有效、又非常自如地进行沟通。让小
组成员习惯于互相通报各自工作的进度、问题和主要决策，这是第一个特征。
在多数情况下，沟通是自然而然的一种事情，而且本该如此；沟通能够使事务
迅速得以执行、将错误迅速消除，而在产品开发中，发生错误是最常见不过的
事。
成功的项目小组习惯于协调无数个必须同时进行的活动，这是第二个特征。
每个小组成员都知道哪些工作必须与小组成员一起仔细处理、哪些工作可以独
立完成。他们知道谁对各种各样的工作都负有责任、什么时候需要小组成员间
的互相帮助。优秀的小组能够有效地进行这种协调，而不需要通过各种文山会
海或其它不能带来增值的行政手段来促成这一点。
高效的决策是优秀的产品开发小组的第三个特征。小组成员对必须作哪些
决定、什么时候作决定都有共识。小组成员心里明白，哪些决策是在他们个人
的控制范围内的、哪些决策在策略上或技术上有更高的侧重点，因而需要其他
队友的参与。他们主动决策，而不愿任由问题发生。
.沟通
由于产品开发中存在大量的不确定因素和变动，因此良好的沟通就显得尤其
重要。同在一个项目组的人有必要与其他小组成员沟通，将工作结果告诉他们，
并指出会影响同组其他人工作的问题。如果产生了问题，应该告知那些能够帮忙
解决的人。至于技术细节以及规格，则应该告知那些使用这些资料的人。很多问
题，都应该及时提出、及时作答。
要想沟通富有成效，就必须同时进行纵向和横向的沟通。纵向沟通不考虑等
级或官职等因素；横向沟通必须跨越部门界限。传统的沟通方式是通过发布一串
指令来进行的，这样不但速度很慢，而且容易发生错误。很显然，项目涉及的人
越多，有效沟通所需时间也就越多。如果在沟通中要求一个人向另个人传达相同
信息，那就容易造成延误。各项目小组之间需要进行无缝的沟通，而且在项目进
展的关键时刻，应该能够与行政管理层进行沟通。
实际或真实的信息通过组织的层层过滤以后就会大量丢失。例如，经理向
主管汇报工作时有意隐瞒情况，想以此来赢回一些时间把项目重新搞上去，而主
管在向副总裁们汇报情况前，也同样经过了筛选，如此这般。当这一条信息
传到高级经理耳朵里时，己经过滤得很纯净，以至于他们可能误以为项目进展
一切顺利。最终，当他们看到项目“出人意料”地与原计划有出入，便十分惊
讶。假设每个人都有效地进行沟通，那么高级经理也许可以采取措施帮助小组，
以免局面出现失控。（这说明了人的责任心和道德观在这里最重要，当然如果培
养开放的沟通环境和组织气氛是很少的。但不能一蹴而就）
要横向跨越部门界限、纵向越过等级界限、保证迅速有效地沟通的另外一
个原因是为了避免理解有误。有一种小孩子玩的游戏，是将一条信息悄悄地告
诉个人，然后让他悄声往下传，但发现传到最后一个人耳中时，原意全变了。
这种事情在很多公司并不鲜见。
最后一点要说明的是，很多产品缺陷或项目延误都是因为缺乏沟通之故。
需要沟通的人没有沟通。举个例子说，在一个项目中，项目经理制定一个计划，
打算花一周时间加工产品。采购人员知道加工某个部分需要十二周时间，但计
划书上没有估计加工周期。人人都自以为沟通过了，但实际上并没有。结果产
品延迟了四个月推出，由于违约，客户跑了。
当产品构想演变成一系列潜在特征和功能之时，就需要开始进行有效的沟
通了。在这段时间里，市场推广部和产品开发部之间需要频繁、几乎是连续不
断的沟通。只有在产品开发小组内部进行有效的沟通，才能够对产品功能、特
征划分、竞争对手意向分析、公司实力、市场窗口预测、市场需求等等问题作
出平衡的决策。从市场推广部门、设计工程部到制造车间，如果是采取单线传
递信息的沟通方式，很少能够行得通的。产品开发小组的组织结构可能使得沟
通更加容易、有效，也可能使沟通变得更加困难。
有些公司为了弥补沟通上的不足，而采用大量的书面文件。开发小组很可能
会因此陷入大量不增值的工作之中而无法脱身，诸如准备状态更新报告、准备管
理宣讲报告及协调正式批准的签字把关等。例如，有一个制造工控机的公司，开
发小组里有技术骨干，但这些人员却将 30％的时间花在与完成项目无关的事务
上。他们每个星期要发两份行政简报，每个星期必须向其它部门做三次有关项目
的汇报，并就他们的伟人设想进行技术演示。
这么多时间花在与完成项目开发无关的事务。我们估计，如果他们减少这些
不必要的活动，可以将计划进程缩短六个月。他们不相信，认为这不可能。我们
就鼓动他们每星期只用一天时间，把精力完全集中在产品开发的工作上，不作报
告、不开会、也不参加任何管理动态课程，只准许参加设计和开发活动。这个小
小的改变引起了显著的变化，结果该小组主动决定进一步减少与项目开发无关的
活动。最后，该产品投放市场所需时间之短创下了记录，而质量水准比该公司历
史上任何其他项目开发的产品都高。
如果一个既定项目的参与人数增加，那么可能存在的沟通渠道就会以几何级
数增长。比方说一个小项目的开发成员只有四个人，那么在这四位成员 A、B、
C、和 D 之间就会有以下十二种沟通渠道：
然而，产品开发通常牵涉到更多人。图 4-1 说明了当更多人参与项目开发时，
沟通渠道迅速增长（N *（N— 1））的情况。如果六十个人参与了产品设计，那
么每个问题或每条信息就可能有三千五百多种沟通方式；当每个月要进行沟通的
问题或信息多达数百个时，就显得相当杂乱无章了。
.工作的协调
开发新产品要求开发人员完成数以千计甚至数以万计的开发活动；其中很
多活动互有联系。要有效地做好这无数件工作，就要相互协调好。而随着产品
的复杂化或市场渠道的增加，要求为管理好项目而进行协调的工作量也随之增
加。
如果协调不力，就可能导致项目延迟或效率降低。有一个跨国仪器公司就
曾经遇到过这个问题。由于他们的产品开发组织错综复杂，用于将产品推向市
场的时间大部分被用于资源协调工作上，如决定哪些技术专家应该在工作中的
关键时刻调过来帮助开发小组或去顶设计人员的缺，因为他们早就被调到别的
项目救火去了。
协调不力还可能造成工作次序混乱。工程师在市场部确定产品的要求之前
就着手产品的开发工作，这样的事会一而再，再而三地出现。例如，一个公司
为一台新电脑设计、制作了六种印刷电路板的工作样品，结果发现，当产品要
求最终确定时，这些电路板都必须做很大改变。白白浪费了八人年的技术骨干
力量。
一些公司试图通过使用综合计划体系来克服协调问题，例如使用详细的项
目评估及审核技术（简称 PERT）图表。一般来说，这样做需要大笔管理费用，
而且不能有效地对工作进行协调。曾经有一个公司想要使用 PERT 图表来协调一
个复杂的项目，他们的 PERT 表大得将一面 30 英尺高的墙都覆盖了。有两名全
职工作人员不间断地对该表内容进行更新，但谁也不知道谁哪一天应该干什么。
并行工程需要将各部门之间的有效协调贯穿项目始终，在项目早期更是如此。
有许多公司想要实施并行工程法，但却无法实现，因为协调工作是一只拦路虎。
他们的项目小组组织并没有提供产品开发所需的协调。
成功的项目小组能够有效地进行协调，而白费精力的事情却很少。他们清楚
什么应该做、谁该做什么。只需召开短短的小组会议，他们就可以协调下一步的
工作。他们懂得利用小组的组织结构，而不是把调度体系作为主要的协调过程。
.决策
进行一种新产品的开发，需要作出无数次的决策。有些决策事关大局，更多
的只是小决定，但所有决策都必须有效地制定出来。是否能够及时作出正确的决
策，是决定一个项目小组成功与否的另外一个因素。
有效的项目小组能够作出更好的决策。不同的观点、技能和背景令他们作决
策时起到了一种增效的作用。在研讨会上，我们做了一个练习，对此进行了说明，
这个练习叫做“迷失在海上”。在这个练习中，假设参加练习的人在茫茫大海上漂
流，要求每个人按优先顺序排列出他将随身携带的十六种物品。然后分小组再进
行这个练习，按美国海岸警卫队排列标准给每套答案打分。结果很明显，集体得
分高于个人得分，这说明凭借团队的力量就能制定出更好决策。（正确）
产品开发的决策还必须及时制定。如果一个决策数个星期甚至数个月都迟迟
制定不出来，就可能导致项目悬而不决，延长产品推向市场的时间。这是导致产
品开发延迟的最主要的一个原因。举个例子，有一个公司无法确定产品应该使用
哪一种微型处理器。这确实是一个不好决定的问题，但是，这个问题拖了差不多
十八个月，一直没有解决。六个月后，工程师在还没有明确决策的情况下就开始
产品设计。最后，当决策出来时，整个设计工作几乎必须重来一遍，结果造成产
品延迟一年推向市场。如果上头没有指示，设计小组还是会无事找事干，即使是
不对路也会照样做下去。（及时）
对项目小组授权的观点很普遍。这样，在需要时，小组自己有权作决定。
然而不幸的是，这种授权往往因为项目小组的权责不明而无法发挥作用。
.产品开发的职能组织
虽然在产品开发中，跨部门的项目组织取得了成功，但很多公司依然根据
职能来组织产品开发。使用这种方法，每个职能部门依次对产品开发起作用，
与接力赛跑差不多。开发周期是从市场部提出产品要求开始的。然后，这些要
求转给工程部，制作出产品规格，并开始产品设计。生产部就根据设计制造出
样品和测试产品；销售部把生产出来的产品派发到各个分销渠道。最后，客户
服务部开始发挥作用，支持初期销售工作并处理客户投诉。
如果一个项目的先后工作顺序明确、重复很少，那么使用职能部门的方法
可能很好，但一般来说，这种方法并不是十分适用于产品开发。我们发现，使
用职能部门的方法容易造成“各人自扫门前雪”的态度，也就是说，每个部门
完成他们那一摊子任务后，项目的其它事就撒手不管了。很多时候，这个问题并
未能被人揭示出来，因为项目组织忙得根本就没时间回头将整个项目的实际表现
与最初的目标进行比较。
使用职能产品开发的方法还有一个弊端，那就是这种方法使得签字审批手
续繁杂，没完没了地转来转去，造成机构臃肿不堪。在过去出现的问题当中，
这种耗时的体制尤其多见。一旦问题得以解决，就有人做出决定，以后如果要
避免类似问题，应采用正式签字的方式，各个职能部门对产品进行审视、批准
后方可进入下一步工作。这样通过保留审查纪录，出现问题时就可查到责任人
是谁。虽然过一阵后，问题不再出现了，但是关卡却越设越多，开发时间也变
得更长了。
例如，有一家生产电子设备的公司在样品材料上比预算多花了 860 美元。管
理层于是制定了一个工作程序，规定生产一种新产品要购买样品材料时，需要四
名副总裁签了批准。结果大量的时间花在找人签字上，这样大大增加了产品开
发成本，也无谓地延长了把产品推向市场的时间。
职能部门的体系纵向层次繁多，往往缺乏必要的横向网络，不利于进行有
效的沟通、协调和作出迅速的决策，而在产品开发上要有所作为，必须要有有
效的沟通、协调和迅速的决策。复杂的结构层次可能会导致部门沟通渠道不畅，
从而拖延制定新产品的决策。例如，如果生产部门非得等到产品设计正式得到
批准之后才去订购样品材料，那么在连续的各个步骤间拖延就蔓延开了。一些
最初有控制点的体系往往演变成官僚本义的迷宫，人们在里面打转转，而不是
花时间将其改正过来。对于一些产品开发周期长的公司，这些是典型的症状。
图 4－2 说明了职能组织方法中相当混乱的沟通情况。在职能组织体系中，
要开发新产品，信息在组织中必须横向流向多个职能部门，还要纵向穿过多个
组织阶层。沟通渠道迅速增加，每个渠道都会延长整个开发周期的时间。
当职能组织法运作好时，进度却很慢；但如果运作得不好，很少有产品能
及时推出而且具有竞争力。当产生矛盾时，皮球就踢到下一级，让他们去解决。
最终，有关产品的决策是由嗓门最大或权利最大的人来作出，而不是由最了解
设计和顾客的人员来制定。
职能组织法最主要的缺陷在于其结构本身。在任何一个职能部门中，工作
人员的工作表现和奖惩完全是按该部门的工作目标评定的。因此，参与产品开
发的人员一般会努力争取在该职能部门中表现出色。很多情况下，那些在具体
职能部门中表现最好的人员，对产品或对公司整体而言却并非很好。职能部门
的工作目标与公司的工作目标不能总是保持一致，而且也经常跟其它职能部门
的工作目标不一致。
有一家微电脑公司的项目小组是按照职能组建的，设有市场推广和销售部、
研究开发部、技术工程部、前期生产部、生产部和客户服务部。每个部门都负责
新产品开发过程中不同阶段的工作。开发工作通常从市场推广部开始，由市场推
广部提出它认为新产品应该有的一系列需求。市场推广部将市场需求文件
（MRD）交给技术工程部。技术工程部随后根据市场需求文件决定该做什么、
不该做什么。产品功能规格（PFS）技术工程部提出设计要求。不幸的是，市场
需求文件（MRD）和产品功能规格（PFS）往往不一致。
只有到制造试制品时，生产部门才会加入到项目中来。由于工程师负责订
购所有部件并制造他们自己的样品，所以生产部的工作必须从零开始。他们要
花很多时间去搞清设计要求、找出标准和合适的部件。最后，在第一批货即将
发运给客户时，客户服务部才猛然发现原来有这么一个项目。当然，从战略的
角度来说，所有零部件都应合理散布在全国各地。这使得生产部更加手忙脚乱，
而工程部就要把各种技术工程上的许多要更改的地方尽快地定下来。
由于采用了职能组织法，该公司开发一个新产品，要比它的竞争对手花多
一倍的时间。后来，该公司被卖给一家外国公司。这家外国公司想做一些改进，
却被其根深蒂固的“职能观念”弄得一筹莫展。
不同职能部门里的个人通常熟知自己本行当的事，但未必知道对于其它职
能部门而言什么是重要的。（而产品开发是系统性的工作，对于某职能部门来说
是最优的，对于产品和公司来说未必是最优的。所以各环节的人都应该有系统性
的观点）图 4-3 说明了一个职能部门的专家认为有用且有趣的事情，另一个职能
部门的专家却常常并不以为然。个人所做的每一个工作步骤，都深深打上了个人
专业兴趣的烙印。这种观念偏差所形成的产品，经常与成功背道而驰。
在一家电脑制造公司里，市场部指出一种新电脑应该满足从工业到军事的
各领域广泛的需求。工程技术部在规格里又附加注明这种电脑应拥有最先进的
处理器技术，而这种技术在一年后才面世。尽管这些过分的要求并不是非要不
可的，但根据设计意见，产品还是包括了这些要求。一年后，该公司意识到开
发这样的产品既费时又费钱。于是重新进行产品定位，着眼于现实的需要。
产品开发采取职能组织结构的做法，往往在产品种类不多又关系密切的小公
司内运作良好。在这些公司，每个人都互相认识，而且一般情况下他们在一起工
作都很有经验。初建的公司往往使用这种方法，并已成为这种方法运作的典范。
然而，当一个小公司只开发一个新产品时，整个公司就是一个产品开发小组。
有些大公司为了有效地沟通、协调和决策就试图效仿小公司的组织结构。他
交
流
障
碍
研发
工程
经理
市场
营销
经理
科技
界
获奖的技术成
就
商业
界
获益的商业成
就
图 4-3 职能型构架蕴育障碍（在各自的专业领域，人们彼此孤立）
们成立了规模较小的自治事业部，自负盈亏而且在财务上有自主权。这种组织结
构在该事业部内部的优势确实有所体现，但对外交流就越发显得困难了。结果，
公司白白失去了对公共资源及其它规模经济资源的利用，而利用这些资源正是大
公司的优势所在。核心小组的方法是力求达到一种更好的平衡。
.核心小组法
当我们第一次与客户一起改进产品开发过程时，我们推出核心小组法作为组
织产品开发小组的备选方案。在多次运用核心小组概念并取得意想不到的成绩后，
我们意识到核心小组是一种组织、指导和管理项目小组的良策。现在，我们相信
它是针对产品开发的最佳项目组织形式。
虽然核心小组通常由 5～8 个具有不同技术的成员及一个核心小组组长组成，
它并不采用传统的分级管理办法。所有产品开发责任都分配到各个小组成员身上，
每个小组成员的职责通常与其技术能力相关。我们认识到有必要消除垂直等级制
度、严格的部门分工及按级别付酬等政策。我们认为核心小组的结构应用一个不
间断的圆形结构图来表示。如图所示，所有的小组成员地位相同。也没有任何一
个部门的地位比其它部门高。
此外，这个圆形结构图还表明每个小组成员都面临相同的挑战：不惜一切代
价尽快地把产品送到客户手里。这就是说小组成员要完成对能超出其严格意义上
的部门范围的任务或是低于他们身份的工作。
小组成员不光要为本部门着想，但更多地是为项目的最后成功而努力工作。
他们通常不把自己限制在通常工作岗位定义的框架内；他们工作弹性大，以小组
身份去做该做的事。核心小组成员直接而独立地履行职责，监督分派给自己的人
员，协调各部门的专家。
核心小组法与其它项目组织形式截然不同，因为核心小组直接对项目的成功
负责。在职能组织形式中，职责是强加的；而在核心小组结构中，责任是自愿接
受的。在等级结构中，通常由更高级别的领导做出或批准详细的决策，但在核心
小组结构中，通常由最熟悉问题的人尽可能在现场做出决策。为帮助小组成员做
出最佳决策，核心小组可以从各部门专家那里获取建议、咨询及指导。
一个核心小组包括四个要素：核心小组组长、核心小组、全员项目小组及核
心小组协调人。核心小组的结构见图 4-4。
核心小组组长
核心小组组长是核心小组的核心人物，他的职责是保证产品符合面市时间。
质量、开发费用及产品成本等项要求。核心小组组长扮演的角色与矩阵组织的
.核心小组组长
核心小组组长是核心小组的核心人物，他的职责是保证产品符合面市时间、
质量、开发费用及产品成本等项要求。核心小组组长扮演的角色与矩阵组织的项
目经理有细微但又是重要的差别。他是小组队长而不是个兼职老板。重点在于领
导而不是独裁。核心小组组长是枢纽前卫（套用一句美国橄榄球的术语），带领
并激励核心小组去完成产品设计，实现项目目标。
此外，核心小组组长还负责管理项目预算、资源及日程安排。同时，负责解
决核心小组成员之间的矛盾、小组成员与职能部门之间的矛盾。出现问题时，核
心小组组长帮助找出解决方案。
一个优秀的核心小组组长不会对其小组存有不合理的要求。相反，最好的核
心小组组长应具备出色的处理人际关系的技巧。曾经有一家电讯公司让一个颇有
经验的产品经理担任核心小组组长组织开发一个重要的新产品，但此人未能完全
理解职责，他经常拍桌子瞪眼睛，叫嚷着说他们误了工时而且开支超过预算，结
果与核心小组中的工程人员及生产人员产生隔阂。这种做法对激励核心小组把项
核心小组组长
协调人
目带上正轨起到了反面作用。
.核心小组成员
核心小组成员在核心小组组长的指导下进行各自的工作。核心小组将根据开
发的产品、产品的复杂性及市场来确定小组的具体组成形式。如果是小型简单的
开发项目，一个核心小组可能只有 4 个或 5 个成员。而大而复杂的开发项目，就
需要一个大一点的核心小组来管理众多的成员。例如，由一个 10 人组成的核心
小组管理一个有 1，800 人的大项目。无论是何种情况，一个核心小组一般都包
括来自工程部门、生产部门、市场部门及客户服务部门的成员。
核心小组成员可以为不同的特殊部门协调项目工作。他们把各职能部门的需
求传递到开发工作中，并把项目要求反馈到职能部门（图 4-5）。这可以保证产品
具有可生产性、耐用性并能满足客户的需求。
核心小组成员还管理其负责的项目活动的资源。例如，一个在数据通讯开发
小组中的电子工程核心项目的成员负责管理工作在处理器、通讯、接口板以及底
板和电源系统等方面的工程师。这些工程师是全员项目小组的成员。全员项目小
组成员负责过程中某些特定点的产品开发工作。全员项目小组成员加入项目并完
成他们的工作后，就退出这个项目。全员项目小组成员的工作表现由核心小组的
相应负责人给予评定。
有一个美国消费电子公司在核心小组中不再设有质量控制人员。因为该公司
在提高质量方面己经非常成功，质量己经成为每个人工作中不可分割的一部分。
质量不再需要它的质控代表，因为质量意识已经在小组中扎下了根。
.全员项目小组
核心小组的下一结构层是全员项目小组。全员项目小组成员来自各个不同部
门，他们参与项目中的一部分工作，该项目由核心小组内一个专门成员负责。全
员项目小组成员可以是直接分配给该项目的人员，也可以是参与新产品支援的职
能经理。
直接委派的小组成员主要是完成不同项目任务的产品开发工程师、技术人员
及专家。例如，可派 10 位软件工程师去开发软件。全员项目小组成员可以是长
期委派的或是临时委派的，也可以是全职的或兼职的。他们的工作由某一指定的
核心小组成员进行协调。
职能经理及其他专家可作为全员项目小组的一部分参与协调某些特殊工作。
例如，元器件工程师及采购工程师可参加一个新供应商的资格认证工作。
核心小组成员负责的全员项目小组里经常有些成员不是固定在其所属职能部
门的。例如，一个硬件核心小组成员负责的全员项目小组里的成员常常来自 CAD
（电脑辅助设计）、调配、元器件工程、采购、生产工程等职能部门。
全员项目小组成员有全职的也有兼职的，视其工作范围和工作强度而定。他
们通常在项目需要的时候才加入。核心小组成员有责任与各职能部门经理协商项
目开发所需要的时间。核心小组成员通常为全员项目小组的个人绩效考评提供依
据。
.核心小组协调人
核心小组协调人在产品开发过程中协助核心小组组长和核心小组成员的工作。
他们把过程改进重点与项目重点进行区别对待。多数人认为他们在是线辅助系统，
即在开发过程过程中有步骤地引导核心小组或通过初级阶段审核来引导核心小
组。
协调人帮助核心小组利用产品开发过程取得尽可能好的结果。他们是过程工
程师，知道该怎么做。此外，他们还经常协助核心小组组长编制计划、进度及协
调项目的各项工作。
除此之外，核心小组协调人还要了解开发过程的进度，密切注意发展方向，
改进工作计划以及应用新工具。他们的职责是管理产品过程，并协助在所有项目
中实施这个过程。
.职能经理
一开始，许多职能经理对在组织中实施核心小组结构感到不自在，因为核心
小组制定所有组织内项目级的决策，所以他们怀疑自己在组织中所起的作用。
事实上，对职能经理们来说，让其在管理一个或两个以上的开发项目的同时
还要履行其在本部门的职责是不太可能的。一些职能经理想通过写详细的进度报
告方法来解决这个问题，而另一些职能经理却采用每周写概要的形式，但所有这
些只能帮助他们了解项目的现状，却不能使他们在推动项目的进程上起任何作用。
结果是管理费用浪费过多，内部决策缓慢，而且职责不明。
按要求，职能经理需每日过问产品开发实施详情，而核心小组结构则取消了
这种要求。这样一来，职能经理可专心于完善本部门的工作：促进本组织内技术
水平的提高，制定长远计划和战略以及给多个核心小组配备资源。他们的工作效
率提高了，经验也得到更好的发挥。
对于一个职能经理来说，进入核心小组结构也许有些冒险。那些过去常请示
上级批准决定的人，现在自己要作出实施上的决策或与核心小组成员一起决策，
会感到很不适应。这通常需要个过渡阶段，因为这些人对自己在核心小组中的职
责还不是很明确，所以对自己的决策能力缺乏信心。职能经理也需要看看决策的
成功例子后才愿意移交权力。
.产品上市时间及项目组织
图 4－6 解释了项目小组的组织方式是怎样直接影响产品的上市时间的。图
中上面的水平轴表示资源投入的方法：有成员指定的任务所涉及的责任，还有用
于项目组的专项资源。下面的水平轴则表示在开发新产品过程中需要多少协调和
沟通工作。一般来说，随着投入到项目中的专有资源的增多，所需的协调与沟通
则会减少。
在纵轴上，项目管理的方法从“基本没有管理”到“自始至终负责的单一项目
经理”，其间有多种变化形式。右侧的纵轴表示的是决策所需要的时间。决策的
时间从慢到快，因为项目管理越有针对性，决策所需要的时间越短。
图中还列出了包括核心小组在内的七种不同的项目组织形式，以说明各种方
法的不同工作效果。越是靠近图表右上方的组织形式，协调沟通越充分，而且决
策更有效。图中显示核心小组及自治小组组织有上佳的表现，但自治小组太极端
了，没要任何职能部门参与。
一间制造电讯产品的公司通过改变其项目组织的途径提高了开发项目的效
率。按惯例，公司有专门的职能任务小组或专家参与指定产品设计中次要因素的
处理。这些次要因素由一个任务小组进行优化，但是没有人对产品有全局观念。
因为有许多人员参与这个项目，每人都认为自己的观点是对的，这使公司须花费
数周时间做出一些最简单的决定。协调工作由一个被称为项目管理部的大型指挥
部来做。该部门的宗旨是要对众多从事高层次工作的个人进行协调（问题是项目
管理部凭什么来调派这些人？）。沟通在部门组织内呈直线上升趋势，然后横向
跨越各部门，最后又呈下降趋势。
从制定技术规范开始到大批量生产审批，给主要项目配备所需的资源和选择
一位项目经理有助于大大地缩短该公司产品的上市时间。过去需要 50 个月的项
目，现在只须 30 个月就可以完成，而且决策更具时效性，协调及沟通也更有效。
通过这些改进，该公司的指标就能从图 4－6 的左下侧的区段上升到右上侧的区
段。在沿着对角线移动时，产品上市时间也缩短了。
.授权
授权就是给一个团体做某件工作的责任及权利。这是一个影响很大的概念，
但人们常常应用不当。一位产品开发顾问这样概括授权的涵义：“项目小组可以
开发他们想要开发的任何产品，而且在招聘人才、资金投入等方面可不受公司政
策的限制，无须经过审批。”其实这样理解授权的含义是错误的。
为了项目的成功，在核心小组成员努力去达到共同目标时，给他们所需要的
权力和责任其实并不难。权力与责任的真谛在于给核心小组授权，使他们在工作
表现上达到有限的、可衡量的里程碑式的目标，同时给予他们开发资源的使用权。
通过建立一个拥有行政管理人员（PAC，产品审批委员会）和直接从事新产
品开发的技术人员（核心小组）的二级组织，PACE 就可使授权产生效果。为了
优化职能部门及加快非项目问题的解决，各核心小组成员直接向其部门经理报告
并由部门经理对此做出评价。有关产品开发方面的问题，核心小组成员由核心小
组组长评定，核心小组组长则由 PAC（产品审批委员会）做出评价。产品审批
委员会在项目的各个阶段给核心小组分配资源并授予核心小组在所有具体事务
执行上的决策权，以此来给核心小组授权。
当授予核心小组在产品开发过程中具体实施事务上的决策权时，决策变得更
快更有效。大家都明白谁做出了什么样的决策，这些决策在需要了解的人之间得
到充分沟通。
应用核心小组法，高层管理人员可以就产品做出重大战略决策，而核心小组
成员则为产品开发制定所有实施决策或战术性的决策。这为公司带来两大益处：
1．行政领导把时间花在制定战略方向和控制上，而不是在微观上管理下级
部门的决策或解决职能部门之间的争执。
2．大多数与项目有关的决策都是由与开发项目关系最密切的核心小组作出
的，因为核心小组成员与开发项目朝夕相处，他们掌握了决策的必要信息。
有一家拥有 300 名员工的大型电脑公司，它的一位副总裁喜欢对每一项重要
产品作出决策。他后来才意识到向核心小组授权的好处。然而各部门经理还是经
常不断地催促他作出战略性技术决策。自从该公司建立核心小组结构之后，这位
副总裁总算解脱出来，开始把目光瞄准未来开发的发展方向。同样值得一提的是，
开发产品的人又学到了制定好的开发决策的良方。
.实施并行工程
并行工程指同时开发产品及改进其所有相关过程（比如生产、服务和分销
等）。核心小组结构允许公司实施并行工程。并行工程把有关的职能部门适时地
引入到开发项目。核心小组组建后，公司不但要开发新产品，而且要改进相关的
生产、分销、服务及支援过程。并行工程的目标是在新产品上市前把所有事情安
排妥当。如在设计过程中处理好这些问题，则新产品的上市时间会变短些。由于
优化了生产和其它过程，并行工程能显著降低产品的成本。
通过实施核心小组结构及让并行工程真正根植于产品开发中，那么在职能部
门一心想着能为新产品开发做些什么的时候，公司可以引导这些部门，使之变得
比以往更强。他们的任务不再是为建立一个个独立王国而优化其职能部门，而是
给正在实施的项目和产品开发提供适当的人员和支持。
图 4-7 是根据 PRTM 的一项调查做出的，说明有最佳实践经验的公司在产品
开发过程中何时引入各职能部门，以及这些部门参与的程度有多大。纵轴列出了
参与新产品开发的各职能部门和团体。图表上方列出了从产品概念到批量生产稳
定性的各个阶段。阴影部分则表示在开发过程各个时期各职能部门的参与程度。
技术研究在初始阶段占的分量很大，以保证技术从实验室向观察应用状态转
换。工程技术在整个开发过程中占有很大的分量，整个开发过程包括把设计出来
的样品交给生产部门的这一移交环节。生产部门在开发的早期阶段就大量地参与
进来，以保证设计的产业化，避免在设计的后期阶段才发现问题。市场营销部门
不是对开发工作置之不理，而是自始至终参与开发过程以做出产品适销性方面的
决策，并为市场宣传推销做好准备。销售部门及时了解即将推出的产品，并在产
品测试阶段做好培训和销售准备工作。在产品和过程设计中，质量控制部门起了
积极的作用。服务部门适度参与，以发现产品耐用方面的问题。财务部门自始至
终监督开发工作，以确保项目在财务上是合理、正当的，符合预算要求。采购部
门和主要供应商参与从规格制定开始的所有工作，保证所有零部件和部件装配线
组合方便，完全可用（如清华的最有名的那个创业例子，就是由于设计的东西很
好，但是却没有合格的配套零部件。需要明确这个例子）。最后，产品的概念和
规格以及测试品才能被客户认可。
通过采用核心小组组织结构实施并行工程，公司还可打破项目修订周期（参
看图 4－8）。此项目修订周期在项目工作发生问题时开始运行。如果采用核心小
组法实施并行工程，则这些问题就可以避免或会得到较好的管理。这些问题通常
在紧要关头会引起项目的更改。有时不得不改变产品的适用范围或功能；有时需
要调换一些核心小组成员或需要一个新的核心小组组长。这样改变项目就要重新
组织小组和重新计划，因此开发时间势必会延长。
开发时间延长后，会导致恶性循环，因为市场对产品要求已经转向，于是公
司不得不又要费一番苦心迎头赶上。如果技术发生了变化，那么情况就会更加糟
糕。
一个热激活电源开关制造商在这个项目修订周期游戏中输了。这个公司不断
修改他们开发中的新产品，于是项目完成日期一拖再拖：开始是 3 个月，然后
是 6 个月，最后拖了整整一年。在这段时间里，有一个竞争对手采用了一项新技
术，以低于 90％的成本开发产品。结果，这家在项目修订周期中打转转的公司
不得不关门停产，使 260 位员工下岗。
.一些公司采用跨职能项目小组未能成功的原因
最近，采用跨职能小组这种方式的公司越来越多。其中一些公司成绩卓著，
而另外一些公司却毫无起色。仅仅是把许多人从各部门抽调出来组成小组的做法
是不够的。通过研究，我们发现一般情况下都缺少以下一些因素：
职能部门与项目小组的权责划分不清。
小组成员的角色和责任不明晰。
小组领导在统率跨职能小组时没能起到有效的作用。
小组在完成任务时没有得到适当的授权。典型的现象是根本没有给他们
授权的过程。
小组成员没有全心思投入到工作中去。
小组办事仅停留在于书面上，流于形式，不能有效地管理开发项目的实
施。
