迈克尔•e•麦克哥拉斯产品开发过程演变的阶段(编辑修改稿)

迈克尔•e•麦克哥拉斯产品开发过程演变的阶段(编辑修改稿)内容摘要：

开发过程，又没有成熟和过硬的职能部门或项目管理技巧以克服无组织性。 这是个非正式或随意性的阶段，每个开发项目都被作为有史以来的第一个项目对待。 项目的组织、管理没有一贯的模式。 如果企业遇到外来压力，就会随意成立或改变不同的专门小组。 在这种被动的环境中，资源往往流向管理人员注意到哪 些项目。 这些应急措施通常是针对某一问题或客户投诉。 没有一个改进和衡量进展的过程，只有个人从中学到一些新东西，而公司的整体财务状况是衡量开发过程是否成功的唯一工具。 甚至连产品战略、技术管理、管道管理之类的高级过程都不被看作是过程。 处于零阶段的公司，难以定期定量地将成功产品推向市场。 偶然的成功又 因缺乏相应的产品促销手段而无法保持竞争优势。 单个项目开发周期的长短无 法预料，但总体开发时间往往拖得非常长，因此，相当多的项目最终无法完 成。 管道的测量没有记录。 如果有记录，就会显示很大比例的开发资源被用于 非开发性活动，如技术服务和生产支援等。 6 多数有生存和发展能力的公司都会进入第一阶段或通过第一阶段，但是有 相当一部分的公司仍停留在零阶段或保留着零阶段公司的某些特点。 一些零阶 段的公司部有某一强项（如工程方面）及几个弱项（如生产和市场部门）。 例 如，一家由学院著名人士创立的生物技术公司或许要寻求一家有名气的药品公 司将其某一新产品推向市场。 一些处于第一阶段的公司可能因为忽略了开发活 动，原先已形成的结构发生裂变，结果倒退至零阶段。 处于零阶段的企业所面临的中要挑战是如何正视并改进其职能部门的 弱 点。 同时制定一些新产品开发活动所涉及的原则，如基本的项目管理技巧等。 如果零阶段公司能从职能上重视其产品开发及项目管理的薄弱环节，它就会进 入第一阶段。 如果它能加大产品开发力度，跨部门改进产品开发的过程，则它 有可能直接进入第二阶段，但所做的努力和所负的责任不应有一丝松懈。 第一阶段 第一阶段的主题是职能部门的有效管理。 零阶段的问题在于特定职能部门 的失误和失衡。 随着各部门找到其特长并逐步实行正规化运作，这些难题便迎 刃而解。 与零阶段的非正式的、随意性的过程不同，在第一阶段中，各职能部 门发展和 应用了一系列己归档并可以重复的流程。 组织结构也是以职能部门为 单位的。 由于更多地强调职能部门的优秀表现，所以，停留在第一阶段的公司 往往将大量的精力用于各个部门间的沟通上。 产品开发被视为职能部门的责任。 在一些公司里，某一职能部门如工程部或研究与开发部或市场部对产品开发负全责。 在另一些公司里，产品开发的主要责任在不同时期落在不同的职能部门上。 从一个部门转移到另一部门的责任交接点上往往是矛盾重重和问题成堆，简直成了部门之间的“战场”，尤其是当一个部门将责任以“扔过墙去”的方式转到另一部门时，更是如此。 这样，某些在开发早期并未得到妥善处理的问题也被一起“扔过墙去”。 “扔过墙去”的方法在第一阶段很普遍，因为毕竟开发过程中有许多堵这样的墙。 企业以各种方式试图改善这种互相扯皮的现状。 有时，它们制定详细的流 程文件以捕捉每项职能部门的责任及跨部门的依托关系，但往往由于过分复杂 和缺乏弹性而渐渐不为所用。 更多的努力似乎花在了详细说明各部门的共同职 责上，而没有花在寻求简化部门间相互配合的方法上。 有时，处于第一阶段的企业为了改善它们的系列化流程而积极地寻求推倒 这些墙的方法。 例如，有的公司要求生产 工程师承担部分开发工程师的职责， 以保证项目启动前能完成各项任务。 有一家公司的文档编制组在不知不觉中承 担了产品功能规格编写的任务，而这样的编写在开发过程中是很笼统的，所以 也从来没有确定下来。 7 在第一阶段，项目的组织结构较零阶段好些。 但各小组的组成缺乏专一性 和连贯性，项目经理也没有恰当地发挥作用。 从一个项目到另一个项目，攻关 小组的构成都不同，而且常常在进入职能部门的迷宫后还不断发生变化。 一旦 他们的工作重心稍有转移，项目管理者们便毫不犹豫地调整各小组的成员。 处于第一阶段的公司倾向于使 用负责相对较弱项目的经理。 他们的角色更 象是行政管理人员、记录人员、协调人员，而不是领导者。 有时我们将这类管 理者称为“我是克劳狄”式的项目经理，他们会如实记录罗马被焚烧的全过 程，而不为大火所动，他们只会记录项目的历史，却不会有力地影响其进程。 这一阶段中的计划几乎无一例外地缺乏精确性。 一旦有什么闪失，就一再 隐瞒，只在万不得己时才告诉管理者。 由于项目的责任人常常变化，计划进度 便常常只包括开发项目的一部分。 制定各职能部门进度表的人似乎与项目一开 始时设制的总体进度表没有什么关系，其结果是总体进度 计划缺乏完整性，也 得不到及时的补充或修正。 实际计划进展没有及时地向管理层汇报，因为没有 人对此负有全责。 当我们向处于第一阶段企业的开发人员询问其项目进展计划 时，得到的回答通常是：“你想看哪一份呢。 ” 由于职能部门所拥有的权利和责任往往比项目开发组多，贡任的划分就变得很模糊。 当我们分析第一阶段项目开发受阻的企业时，发现一条规律，即责任随着项目的展开而不断转移。 一个职能部门作出的决定到了下一个部门便被否决了。 每次责任的移交成了重新界定项目的机会。 开发组成员对其所在职能部门的忠诚远远超过其对公司或项目 的忠心程度，这就导致他们决策的狭隘性。 一旦出了问题，部门之间就相互抱怨及推诿责任，备忘录中常常出现这样的字眼：“市场部认为„„”或“工程部的看法是„„”，或“生产部觉得„„ ”。 处于第一阶段的企业在决策过程采用逐个签字把关的程序。 这是一项费时 且颇具政治倾向的活动。 一项已签字通过的决定在任何一个关键的部门可能会 遇到私下抵触。 此外，整个程序没有任何时间压力。 一旦出现问题，如对某一 产品的看法不一致时，逐个签字把关就会使开发活动停下来。 在纪律性强的公 司里，这种做法会延误时机。 在组织相对松散的公司里， 最终解决此公开问题 的时间会无限期地向后推。 开发人员不得不在未得到某些签字的情况下继续工 作，希望会有好的结果。 如果出现问题，那些未签字的人便会站出来否定这一 项目。 预算是用来分清优先次序的机制。 年度拨款划到各个职能部门，再由他们 将资源下拨。