产品开发过程演变的第一阶段 - 蓝博思—专注技术创新TRIZ、研发管理IPD、质量可靠性咨询培训

第一阶段的主题是职能部门的有效管理。零阶段的问题在于特定职能部门的失误和失衡。随着各部门找到其特长并逐步实行正规化运作，这些难题便迎刃而解。与零阶段的非正式的、随意性的过程不同，在第一阶段中，各职能部门发展和应用了一系列己归档并可以重复的流程。组织结构也是以职能部门为单位的。由于更多地强调职能部门的优秀表现，所以，停留在第一阶段的公司往往将大量的精力用于各个部门间的沟通上。

产品开发被视为职能部门的责任。在一些公司里，某一职能部门如工程部或研究与开发部或市场部对产品开发负全责。在另一些公司里，产品开发的主要责任在不同时期落在不同的职能部门上。从一个部门转移到另一部门的责任交接点上往往是矛盾重重和问题成堆，简直成了部门之间的“战场”，尤其是当一个部门将责任以“扔过墙去”的方式转到另一部门时，更是如此。这样，某些在开发早期并未得到妥善处理的问题也被一起“扔过墙去”。“扔过墙去”的方法在第一阶段很普遍，因为毕竟开发过程中有许多堵这样的墙。

企业以各种方式试图改善这种互相扯皮的现状。有时，它们制定详细的流程文件以捕捉每项职能部门的责任及跨部门的依托关系，但往往由于过分复杂和缺乏弹性而渐渐不为所用。更多的努力似乎花在了详细说明各部门的共同职责上，而没有花在寻求简化部门间相互配合的方法上。

有时，处于第一阶段的企业为了改善它们的系列化流程而积极地寻求推倒这些墙的方法。例如，有的公司要求生产工程师承担部分开发工程师的职责，以保证项目启动前能完成各项任务。有一家公司的文档编制组在不知不觉中承担了产品功能规格编写的任务，而这样的编写在开发过程中是很笼统的，所以也从来没有确定下来。

在第一阶段，项目的组织结构较零阶段好些。但各小组的组成缺乏专一性和连贯性，项目经理也没有恰当地发挥作用。从一个项目到另一个项目，攻关小组的构成都不同，而且常常在进入职能部门的迷宫后还不断发生变化。一旦他们的工作重心稍有转移，项目管理者们便毫不犹豫地调整各小组的成员。

处于第一阶段的公司倾向于使用负责相对较弱项目的经理。他们的角色更象是行政管理人员、记录人员、协调人员，而不是领导者。有时我们将这类管理者称为“我是克劳狄”式的项目经理，他们会如实记录罗马被焚烧的全过程，而不为大火所动，他们只会记录项目的历史，却不会有力地影响其进程。

这一阶段中的计划几乎无一例外地缺乏精确性。一旦有什么闪失，就一再隐瞒，只在万不得己时才告诉管理者。由于项目的责任人常常变化，计划进度便常常只包括开发项目的一部分。制定各职能部门进度表的人似乎与项目一开始时设制的总体进度表没有什么关系，其结果是总体进度计划缺乏完整性，也得不到及时的补充或修正。实际计划进展没有及时地向管理层汇报，因为没有人对此负有全责。当我们向处于第一阶段企业的开发人员询问其项目进展计划时，得到的回答通常是：“你想看哪一份呢？”

由于职能部门所拥有的权利和责任往往比项目开发组多，贡任的划分就变得很模糊。当我们分析第一阶段项目开发受阻的企业时，发现一条规律，即责任随着项目的展开而不断转移。一个职能部门作出的决定到了下一个部门便被否决了。每次责任的移交成了重新界定项目的机会。开发组成员对其所在职能部门的忠诚远远超过其对公司或项目的忠心程度，这就导致他们决策的狭隘性。一旦出了问题，部门之间就相互抱怨及推诿责任，备忘录中常常出现这样的字眼：“市场部认为……”或“工程部的看法是……”，或“生产部觉得……”。

处于第一阶段的企业在决策过程采用逐个签字把关的程序。这是一项费时且颇具政治倾向的活动。一项已签字通过的决定在任何一个关键的部门可能会遇到私下抵触。此外，整个程序没有任何时间压力。一旦出现问题，如对某一产品的看法不一致时，逐个签字把关就会使开发活动停下来。在纪律性强的公司里，这种做法会延误时机。在组织相对松散的公司里，最终解决此公开问题的时间会无限期地向后推。开发人员不得不在未得到某些签字的情况下继续工作，希望会有好的结果。如果出现问题，那些未签字的人便会站出来否定这一项目。

预算是用来分清优先次序的机制。年度拨款划到各个职能部门，再由他们将资源下拨到各个开发项目。这样一来，经常会发生优先次序冲突，妨碍整体资源调拨的优化，造成延误。

由于没有关键的阶段性审核，管理层通常要求开发小组成员经常汇报开发进展情况，高层管理人员以这种方式来对项目进行监督既费时又往往效果不佳。

第一阶段工作的不断完善是在各职能部门这一级单位完成的。由于第一阶段的重点是优化职能部门，因此对某些职能步骤作详细的定义和归档并不少见，但对另一些同样重要的职能步骤却并没有定义和归档也是屡见不鲜。例如，有一家测试公司，是世界一流的，但开发过程的效率却极低。虽然它有高水平的测试经验法则，但在现实环境里却是一贯地超预算运作。没有人能改善部门间的联系。因为各部门都小心翼翼地守护着自己的职能，没人会主动承担改进整个开发过程的责任，缺乏协同作战、共同开发的动力。处于下游的职能部门如生产和服务部等往往到项目的后期才参与进来。由于在开发项目后期的调整困难重重而且费用很高，因此缺乏协同作战就势必会造成超支和延误。

处于第一阶段的公司或许在职能部门内部有较好的衡量尺度，但整个开发过程往往缺乏准确的衡量尺度。没有象样的开发项目衡量尺度，比如上市时间或无效开发的衡量等，就很难为开发过程的完善制定合理的目标，也很难为具体的项目制定精确的目标，所以相对以后的两个阶段而言，其预测的准确性差，便是意料中的事。在后面的两个阶段中，周期指导方针是设立具体目标的良好基础。

由于没有客观的运作目标，高级管理层便常常随心所欲。他们或是认定原进度计划太虚而要求速度放慢一倍，或是因窥视到市场的机会而将某一完成日期强加给开发人员。开发人员往往会对这类强加给他们的目标置之不理，或者因此而士气大跌。有的开发人员甚至各有两份进度表，一份是给管理层看的，另一份则是用于指导项目活动的实际进度表。上述的一切致使原计划目标与实际运作脱节。

在第一阶段，产品战略通常无原则性。既使制定了长期产品规划，也是存放在市场部，可能与实际上马的项目没什么关系。这一阶段的通病是想做的事情太多或是满足所有客户的所有要求。由于开发周期比内部认同的要长，产品规划就不会长远。注意力总是集中在下一个产品，而不是把产品看作产品系列的一部分，或是把产品系列看作产品平台的一部分。这样，项目筛选过程就不免带有盲目性和随机性。

基础技术开发也面临类似的问题。职能部门各自为政导致管理层决定投资的项目不一定与企业或其战略目标有任何关联。研发部的管理者不相信市场部的人会有长远的眼光，因而希望独立选择应该支持哪些项目。其结果是，在努力取得较好的项目和资源平衡的同时展开的项目往往过多，对项目采取周期性的删减（往往是无效的）也过于频繁。

处于第一阶段的企业肯定有新产品上市，但其周期相当长，大约是处于第二阶段公司的两倍。制定管理决策时效率不高，使得有些项目迟迟未能取消，无效开发比例却在上升，远远超过了第二阶段。在条件不成熟的情况下，迫于时间压力，草率地将产品推向市场，往往会增加后期的成本，甚至当产品上市

处于第一阶段水平的运作在某些行业中仍具有稍许的竞争力，原因是这些行业产品开发管理的展开较迟，但这种状况不会持续太久。对时间极为紧迫的行业如电子业来说，处于这一阶段的企业仍然很难生存。