第四章160160项目组织的核心小组法(编辑修改稿)

第四章160160项目组织的核心小组法(编辑修改稿)内容摘要：

些要 求转给工程部，制作出产品规格，并开始产品设计。 生产部就根据设计制造出 样品和测试产品；销售部把生产出来的产品派发到各个分销渠道。 最后，客户 服务部开始发挥作用，支持初期销售工作并处理客户投诉。 如果一个项目 的先后工作顺序明确、重复很少，那么使用职能部门的方法 可能很好，但一般来说，这种方法并不是十分适用于产品开发。 我们发现，使 用职能部门的方法容易造成“各人自扫门前雪”的态度，也就是说，每个部门 完成他们那一摊子任务后，项目的其它事就撒手不管了。 很多时候，这个问题并未能被人揭示出来，因为项目组织忙得根本就没时间回头将整个项目的实际表现与最初的目标进行比较。 使用职能产品开发的方法还有一个弊端，那就是这种方法使得签字审批手 续繁杂，没完没了地转来转去，造成机构臃肿不堪。 在过去出现的问题当中， 这种耗时的 体制尤其多见。 一旦问题得以解决，就有人做出决定，以后如果要 避免类似问题，应采用正式签字的方式，各个职能部门对产品进行审视、批准 后方可进入下一步工作。 这样通过保留审查纪录，出现问题时就可查到责任人 是谁。 虽然过一阵后，问题不再出现了，但是关卡却越设越多，开发时间也变 得更长了。 例如，有一家生产电子设备的公司在样品材料上比预算多花了 860 美元。 管理层于是制定了一个工作程序，规定生产一种新产品要购买样品材料时，需要四名副总裁签了批准。 结果大量的时间花在找人签字上，这样大大增加了产品开 发成本，也无谓 地延长了把产品推向市场的时间。 职能部门的体系纵向层次繁多，往往缺乏必要的横向网络，不利于进行有 效的沟通、协调和作出迅速的决策，而在产品开发上要有所作为，必须要有有 效的沟通、协调和迅速的决策。 复杂的结构层次可能会导致部门沟通渠道不畅， 从而拖延制定新产品的决策。 例如，如果生产部门非得等到产品设计上正式得到 批准之后才去订购样品材料，那么在连续的各个步骤间拖延就蔓延开了。 一些 最初有控制点的体系往往演变成官僚本义的迷宫，人们在里面打转转，而不是 花时间将其改正过来。 对于一些产品开发周期长的公司，这 些是典型的症状。 7 图 4－ 2 说明了职能组织方法中相当混乱的沟通情况。 在职能组织体系中， 要开发新产品，信息在组织中必须横向流向多个职能部门，还要纵向穿过多个 组织阶层。 沟通渠道迅速增加，每个渠道都会延长整个开发周期的时间。 当职能组织法运作好时，进度却很慢；但如果运作得不好，很少有产品能 及时推出而且具有竞争力。 当产生矛盾时，皮球就踢到下一级，让他们去解决。 最终，有关产品的决策是由嗓门最大或权利最大的人来作出，而不是由最了解 设计和顾客的人员来制定。 职能组织法最主要的缺陷在于其结构本身。 在任何一个职能部门中，工作 人员的工作表现和奖惩完全是按该部门的工作目标评定的。 因此，参与产品开 发的人员一般会努力争取在该职能部门中表现出色。 很多情况下，那些在具体 职能部门中表现最好的人员，对产品或对公司整体而言却并非很好。 职能部门 的工作目标与公司的工作目标不能总是保持一致，而且也经常跟其它职能部门 的工作目标不一致。 有一家微电脑公司的项目小组是按照职能组建的，设有市场推广和销售部、 研究开发部、技术工程部、前期生产部、生产部和客户服务部。 每个部门都负 责新产品开发过程中不同阶段的工作。 开发 工作通常从市场推广部开始，由市 场推广部提出它认为新产品应该有的一系列需求。 市场推广部将市场需求文件 （ MRD）交给技术工程部。 技术工程部随后根据市场需求文件决定该做什么、不该做什么。 产品功能规格（ PFS）技术工程部提出设计要求。 不幸的是，市场需求文件（ MRD）和产品功能规格（ PFS）往往不一致。 只有到制造试制品时，生产部门才会加入到项目中来。 由于工程师负责订 购所有部件并制造他们自己的样品，所以生产部的工作必须从零开始。 他们要 8 花很多时间去搞清设计要求、找出标准和合适的部件。 最后，在第一批货 即将 发运给客户时，客户服务部才猛然发现原来有这么一个项目。 当然，从战略的 角度来说，所有零部件都应合理散布在全国各地。 这使得生产部更加手忙脚乱， 而工程部就要把各种技术工程上的许多要更改的地方尽快地定下来。 由于采用了职能组织法，该公司开发一个新产品，要比它的竞争对手花多 一倍的时间。 后来，该公司被卖给一家外国公司。 这家外国公司想做一些改进， 却被其根深蒂固的“职能观念”弄得一筹莫展。 不同职能部门里的个人通常熟知自己本行当的事，但未必知道对于其它职 能部门而言什么是重要的。 图 43 说 明了一个职能部门的专家认为有用且有趣 的事情，另一个职能部门的专家却常常并不以为然。 个人所做的每一个工作步 骤，都深深打上了个人专业兴趣的烙印。 这种观念偏差所形成的产品，经常与 成功背道而驰。 在一家电脑制造公司里，市场部指出一种新电脑应该满足从工业到军事的 各领域广泛的需求。 工程技术部在规格里又附加注明这种电脑应拥有最先进的 处理器技术，而这种技术在一年后才面世。 尽管这些过分的要求并不是非要不 可的，但根据设计意见，产品还是包括了这些要求。 一年后，该公司意识到开 发这样的产品既费时又费钱。 于是重新 进行产品定位，着眼于现实的需要。 产品开发采取职能组织结构的做法，往往在产品种类不多又关系密切的小 公司内运作良好。 在这些公司，每个人都互相认识，而且一般情况下他们在一 起工作都很有经验。 初建的公司往往使用这种方法，并已成为这种方法运作的 典范。 然而，当一个小公司只开发一个新产品时，整个公司就是一个产品开发 小组。 有些大公司为了有效地沟通、协调和决策就试图效仿小公司的组织结构。 交 流 障 碍 研发工程经理 市场营销经理 科技界 获奖的技术成就 商业界 获益的商业成就 图 43 职能型构架蕴育障碍（在各自的专业领域，人们彼此孤立） 9 他们成立了规模较小的自治事业部，自负盈亏而且在财务上有自主权。 这种组 织结构在该事业部内部的优势 确实有所体现，但对外交流就越发显得困难了。 结果，公司白白失去了对公共资源及其它规模经济资源的利用，而利用这些资 源正是大公司的优势所在。 核心小组的方法是力求达到一种更好的平衡。 核心小组法 当我们第一次与客户一起改进产品开发过程时，我们推出核心小组从作为 组织产品开发小组的备选方案。 在多次运用核心小组概念并取得意想不到的成 绩后，我们意识到核心小组是一种组织、指导和管理项目小组的良策。 现在， 我们相信它是针对产品开发的最佳项目组织形式。 虽然核心小组通常由 5～ 8 个具有不同技术的成员及一个核 心小组组长组 成，它并不采用传统的分级管理办法。 所有产品开发责任都分配到各个小组成 员身上，每个小组成员的职责通常与其技术能力相关。 我们认识到有必要消除 垂直等级制度、严格的部门分工及按级别付酬等政策。 我们认为核心小组的结 构应用一个不间断的圆形结构图来表示。 如图所示，所有的小组成员地位相同。 也没有任何一个部门的地位比其它部门高。 此外，这个圆形结构图还表明每个小组成员都面临相同的挑战：不惜一切 代价尽快地把产品送到客户手里。 这就是说小组成员要完成对能超出其严格意 义上的部门范围的任务或是低于他们 身份的工作。 小组成员不光要为本部门着想，但更多地是为项目的最后成功而努力工作。 他们通常不把自己限制在通常工作岗位定义的框架内；他们工作弹性大，以小 组身份去做该做的事。 核心小组成员直接而独立地履行职责，监督。