产品开发流程演变各阶段的特征Word格式.docx

产品开发流程演变各阶段的特征Word格式.docx

《产品开发流程演变各阶段的特征Word格式.docx》由会员分享，可在线阅读，更多相关《产品开发流程演变各阶段的特征Word格式.docx（5页珍藏版）》请在冰豆网上搜索。

总体的开发周期往往太长，甚至相当大一部分的项目都没去最终完成。

管道衡量结果没有保留，假如有的话，从中可以看到，许多资源没入了那些非开发的活动之中，像技术服务和生产支持等。

已经有许多公司达到了第一阶段或更高阶段，但仍有惊人数量的公司外于零阶段或者还拥有零阶段的特点。

一些处于零阶段的公司在某项职能上很强（如工程），但在许多方面很弱（如生产或市场）。

例如，一家依靠某学院成立的生物技术公司只有转换为制药公司后，才能将其产品投向市场。

某些处于第一阶段的公司可能忽视了它们的开发实践，原有的开发结构崩溃了，其结果是它们只能又回到零阶段。

处于零阶段的公司面临的主要挑战是，发展新产品开发所需的要素如基本的项目管理的技能）时，能否改善它们在职能上的弱点?

假如零阶段的公司能从职能上改善它在产品开发和项目管理上的弱点，那它就能发展到第一阶段。

假如它还有余力致力于改善跨职能的产品开发流程，那么它就能直接进入第二阶段，但需要付出的努力和担当的义务不能削减。

第一阶段

第一阶段的主题是以职能为主。

零阶段中因详细部门的职能缺陷和部门间不平衡等产生的问题，通过每个部门营造自己的竞争力、积累实践等努力都已经克服了。

与零阶段不同，由于拥有非正式的和特地的流程，故而在第一阶段的各个职能层面上，都有成文的、可重复的流程在发挥作用。

组织结构也是智能型的。

由于在职能优势上投入了如此多的关注，所以公司在第一阶段上投入的能量许多都着力于查找与职能联系的途径和方法。

产品开发被视为职能的责任。

在一些公司中，某些职能部门，如工程、开发或市场研究部门，被看作是产品开发的担当者。

在其他一些公司中，产品开发的领导职责则依据产品开发流程不同的点，在不同的职能部门之间传递移交。

交接点上往往矛盾重重和问题成堆，简直成了部门之间的“战场”，尤其是当一个部门将责任以“扔过墙去”的方式转到另一部门时，更是如此。

这样，某些在开发早期并未得到妥当处理的问题也被一起“扔过墙去”。

“扔过墙去”的作法在第一阶段很普遍，因为究竟开发流程中有很多这样的墙。

企业以各种方式试图改善这种相互扯皮的现状。

有时，它们制定具体的流程文件以捕获每项职能部门的责任及跨部门的依托关系，但往往由于过分复杂和缺乏弹性而慢慢不为所用。

更多的努力好像花在了具体说明各部门的共同职责上，而没有花在寻求简化部门间相互协作的方法上。

有时，处于第一阶段的企业为了改善它们的系列化流程而积极地寻求推倒这些墙的方法。

例如，有的公司要求生产工程师担当部分开发工程师的职责，以保证项目启动前能完成各项任务。

有一家公司的文档编制组在不知不觉中担当了产品功能规格编写的任务，而这样的编写在开发流程中是很笼统的，所以从来没有确定下来。

在第一阶段，项目的组织结构较零阶段好些，但各小组的组成缺乏专一性和连贯性，项目经理也没有恰当地发挥作用。

从一个项目到另一个项目，小组成员的构成都不同，而且常常在进人职能部门的迷宫后还不断发生变化。

一旦他们的工作重心稍有转移，项目管理者们便毫不迟疑地调整各小组的成员。

处于第一阶段的公司倾向于拥有一些相对较弱的项目经理：

他们的角色更像是行政管理人员、记录人员、协调人员，而不是领导者。

有时，我们将这类管理者称为“我是克劳迪厄斯（1.Claudius）”式的项目经理，他们会照实记录罗马被焚烧的全过程，而不为大火所动。

他们只会记录项目的历史，却不会有力地影响其进程。

这一阶段中的计划几乎无一例外地缺乏精确性。

一旦有什么闪失，就会被一再隐瞒，只在万不得已时才被告知管理者。

由于项目的责任常常变化，计划进度便常常只包括开发项目的部分。

制定各职能部门进度表的人好像并不在意项目开头时设制的总体进度表，其结果是总体进度计划缺乏完整件.也得不到准时的补充或修正。

计划的实际进展没有准时向管理层汇报，因为没有人对此负有全责。

当我们向处于第一阶段的企业的开发人员询问其项目进展计划时，得到的回答通常是，“你想看哪一份?

”

由于职能部门所拥有的权利和责任往往比项目开发组多，责任的划分就变得很模糊。

当我们分析第一阶段项目开发受阻的企业时，发觉了一条规律，即责任随着项目的绽开而不断转移。

一个职能部门做出的打算到了下一个部门便被拒绝。

每次责任的移交成了重新界定项目的机会。

开发组成员对其所在职能部门的忠诚远远超过其对公司或项目的忠心程度，这就导致他们决策的狭隘性。

一旦出了问题，部门之间就相互埋怨及推诿责任，备忘录中常常出现这样的字眼：

“市场部认为……”，或“工程部的看法是……”，或“生产部觉得……”。

处于第一阶段的企业的决策流程采用逐个签字把关的程序。

这是一项费时且颇具政治倾向的活动。

一项已签字通过的打算在任何一个关键的部门可能会遇到私下抵触。

此外，整个程序没有任何时间压力。

一旦出现问题，如对某一产品的看法不全都时，逐个签字把关就会使开发活动渐渐停下来。

茁纪律性强的公司里，这种做法会延误时机。

在组织相对松散的公司里，最终解决问题的时间会无限期地向后推。

开发人员不得不在未得到某些签字的状况下连续工作，期望会有好的结果。

假如出现问题，那些未签字的人便会站出来否定这项目。

预算是用来分清优先次序的机制。

年度拨款划到各职能部门，再由他们将资源拨到各个开发项目。

这样一来，经常会发生优先次序冲突，阻碍整体资源调拨的优化，造成延误。

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

第一阶段工作的不断完善是在各职能部门这一级完成的。

由于第一阶段的重点是优化职能部门，因此对某些职能步骤作具体的定义和归档并不少见，但对另一些同样重要的职能步骤却并没有定义和归档也是常见的。

例如，有一家测试公司是世界一流的，但开发流程的效率却极低。

虽然它有高水平的测试经验法则，但在现实环境里却是一贯地超成本运作。

没有人能改善部门间的联系。

因为各部门都小心翼翼地守护着自己的职能，没有人会主动担当改进整个开发流程的责任，缺乏协同作战、共同开发的动力。

处于下游的职能部门，如生产和服务部等往往到项目的后期才参与进来。

由于在开发项目后期调整困难重重，而且费用很高，因此缺乏协同作战就势必会造成超支和延误。

处于第一阶段的公司或许在职能部门内部有较好的衡量尺度，但对于整个开发流程往往缺乏精确的衡量尺度。

没有像样的开发项目衡量尺度，比如上市时间或对无效开发的衡量等，就很难为开发流程的完善制定合理的目标，也很难为详细的项目制定精确的目标。

所以，相对以后的两个阶段而言，其预估的精确性差便是意料中的事。

在后面的两个阶段中，周期指导方针是设立详细目标的良好基础。

由于没有客观的运作目标，高级管理层便常常随心所欲。

他们或认定原进度计划太虚而要求速度放慢一倍，或因察觉到市场的机会而将某一完成日期强加给开发人员。

开发人员往往会对这类强加给他们的目标置之不理，或者因此而土气大跌。

有的开发人员甚至备有两份进度表，一份是给管理层看的，另一份则是用于指导项目活动的实际进度表。

上述的一切致使项目原计划目标与实际运作脱节。

在第一阶段，产品战略通常是无原则性的。

即使制定了长期产品规划，也只是存放在市场部，与实际上马的项目可能没什么关系。

这一阶段的通病是想做的事情太多，或是满意全部客户的全部要求。

由于开发周期比内部认同的要长，所以产品规划就不会长远。

留意力总是集中在下一个产品，而不是把产品看作产品系列的一部分，或是把产品系列看作产品平台的一部分。

这样，项目筛选流程就难免不带有盲目性和随机性。

基础技术开发也面临类似的问题。

职能部门各自为政，导致管理层打算投资的项目不一定与企业的战略目标有任何关联。

研发部的管理者不相信市场部的人会有长远的眼光，因而期望独立选择应当支持哪些项目。

其结果是，在努力取得较好的项目和资源平衡的同时，绽开的项目往往过多，对项目采取周期性的删减（往往是无效的）也过于频繁。

处于第一阶段的企业确定有新产品上市，但其周期相当长，大约是处于第二阶段的公司的两倍。

制定管理决策时效率不高，使得有些项目迟迟未能取消，无效开发比例却在上升，远远超过了第二阶段。

在条件不成熟的状况下迫于时间压力，草率地将产品推向市场往往会增加后期的成本，甚至当产品上市之后，公司仍要为此付出昂贵的代价。

处于第一阶段水平的运作在某些行业中仍具有略微的竞争力，原因是这些行业进行产品开发管理的优化绽开较迟，但这种状况不会持续太久。

对时间极为敏感的行业如电子业来说，处于这一阶段的企业仍旧很难生存。

处于第一阶段的公司所面临的主要挑战是怎样在项目层次上综合各部门的力气进行产品开发，并获得这一步改进带来的全部好处。

第二阶段

在第二阶段，企业取得巨大的进步。

通过协调实施产品开发项目的各职能部门的力气，这些公司奇迹般地缩短了开发周期，提高了开发效率。

一个简洁的总体流程联合了全部的职能部门。

这一流程的界定清楚，结构简洁。

它汲取了第一阶段中形成的职能部门运作的精华部分，精简并纳入各部门共有的最佳方面。

在处于第二阶段、较成熟的公司里，这一流程几乎涉及全部方面，100%的合理项目都使用这一流程。

第二阶段中，一个共同的做法就是成立小规模的、专一的跨部门小组，如核心小组，其成员组成有一定的标准，因项目的复杂程度和大小而容许有一定的差别。

在实施全部项目的相关事宜中，这些小组有效地履行了它们的功能或职责。

作为一个整体，它们对整个项目负责，从而削减了第一阶段中常见的部门之间相互扯皮的现象。

它们由项目经理带领，有效地通过跨部门运作来达到项目的目标。

第二阶段中，管理决策的制定流程有了巨大的提高。

建立了有决策能力的跨部门管理机构，如产品审批委员会（PAC）。

在一些关键的决策点上，委员会通过有效的、针对研发事件的阶段性评审流程，将各开发小组的表现清晰地呈现在管理层面前。

第一阶段中频繁的状况汇报因费时和不得要领而不再使用。

每个阶段性审核后都要进行决策。

这样就排解了因决策拖延而造成的占总数40%的无效开发。

因为这些综合管理小组既有企业战略策划人员又有主要资源的管理人员，所以不大可能制定背道而驰的决策。

打算实施某个项目就要同时打算供应项目所需的资源。

这种从高级管理层到核心小组层面的跨部门沟通，使企业的决策始终保持全都。

第一阶段中的项目进度计划伴有很大的随便性，而第二阶段因为有了周期指导方针，状况就截然不同了。

这些指导方针是针对开发流程的每个步骤制定的，它们依项目的特点不同而有所不同。

这些特点包括项目的复杂程度和对新技术的依靠程度。

随着流程的深人，周期指导方针会得到定期的修正。

所谓周期指导方针实际上就是时间的标准开支。

把留意力放在开发的内容上，而不是放在评价制表人的动机如何上，就可改进项目计划进度表的制定。

计划进度表精确性的提高，有利于处于第二阶段的公司更合理地规划项目和安排资源，削减了项目经费不足的状况。

处于第二阶段的企业采用了共同开发的方法。

由于各主要职能部门自始至终都是项目开发的一部分，所以从一开头各方面的人员都期望把事情办好。

生产部门在项目开发初期就加入，开发人员也不会在要加