安徽登克尔旅游用品有限公司

新产品研发流程

研发中心新产品开发一共有18过程，有16关键点。

每个过程都有开始条件、工作程序、标准规范、结束事件。工作程序，标准规范请参照公司文件及指标，过程的结束事件即为关键点。

※关键点1：新产品开发输入资料评审

评审时检验资料：《新产品开发可行性、适宜性分析报告》

《市场需求分析报告》

《APQP小组人员名单》

《新产品APQP总计划表》

《初始成本估价表》

《新产品开发提案书》：包含功能要求或产品说明书，结构包

装要求，法律法规要求，新产品奖金分

配方案，工程安装方式等。

评审人员：产品中心、研发中心、销售中心

结束标志：制作《新产品开发输入资料登记表》

制作《新产品开发资料输入评审报告》通过评审

所有资料转交给研发中心。

■过程1：硬件概要设计

启动条件：

1、通过新产品开发输入资料评审；

2、收到产品中心输入资料。

过程要点：

1、制做《新产品开发计划表》包含：过程、关键点、时间、人员等规划，结合软件、结构流程。

2、制作《硬件概要设计报告》包含：硬件设计方框图、标准法规、技术参数、生产方式、检测方法、采购说明、技术难点。制作《样件拆分记录表》。制作《新产品特殊特性清单》。制作《新增设备/仪器/工装清单》。 ※关键点2：硬件概要设计评审

评审时检验资料：《硬件概要设计报告》

《样件拆分记录表》

《新产品特殊特性清单》

《新增设备/仪器/工装清单》

《新产品开发计划表》

《仪器设备工装夹具评估表》

《产品规格书》

必须参与的评审人员：研发总监、项目经理、研发项目成员

结束标志：制作《硬件设计评审报告》，通过评审。

■过程2：软件概要设计

启动条件：

1、通过新产品开发输入资料评审；

2、收到产品中心输入资料。

过程要点：

1、制作《新产品开发计划表》包含：过程、关键点、时间、人员等规划，结合硬件、结构流程。

2、制作《软件概要设计报告》包含：产品的详细功能说明书、主流程图 ※关键点3：软件概要设计评审

评审时检验资料：《软件概要设计报告》

《新产品开发计划表》

必须参与的评审人员：研发总监、项目经理、研发项目成员

结束标志：制作《软件设计评审报告》，通过评审。

■过程3：外形结构概要设计

启动条件：1、通过新产品开发输入资料评审

2、收到产品中心输入资料。

过程要点：制作《新产品开发计划表》包含：过程、关键点、时间、人员等规划，结合电子流程。

制作：《外形概要设计报告》包含：外观要求、安装方式要求、尺

寸要求，或外观草图

※关键点4：外形结构概要设计评审

评审时检验资料：《新产品开发计划表》

《外形概要设计报告》

必须参与的评审人员：研发总监、项目经理、研发项目成员，产品中心，销售中心，制造中心

结束标志：制作《外形结构设计评审报告》，通过评审。

■过程4：原理图设计

启动条件：通过硬件概要设计评审

过程要点：初步验证没有不熟悉的功能电路

规划出新器件，购买新新器件样品，验证新器件的功能。

评估新器件的采购事项

制作《新器件、新功能评估表》

※关键点5：原理图评审

评审时检验资料：《原理图》

《新器件、新功能评估表》

必须参与的评审人员：研发总监、项目经理、硬件软件工程师

结束标志： 制作《原理图评审报告》，通过评审。

■过程5：物料初步确定

启动条件：硬件工程师填写联络单和采购单

过程要点：确定市场货源，价格，供应商，样品等提交硬件工程师 ■过程6：流程图设计

启动条件：通过软件概要设计评审

过程要点：制作《流程图》包含：主流程图，各子流程图，重要标志位，关键

字的定义、通讯接口协议、数据的定义、其他代码编写说明

※关键点6：流程图评审

评审时检验资料：《流程图》

必须参与的评审人员：研发总监、经理、研发软件工程师

结束标志：制作《流程图评审报告》，通过评审。

■过程7：工业设计

启动条件：通过外形结构概要设计

过程要点：设计多款外形以供评审用 ，工艺要求，结构要求

※关键点7：工业设计评审

评审时检验资料：外形图

必须参与的评审人员：总经理、副总经理、产品总监、营销中心相关负责人

员、研发总监经理、结构工程师、工业设计师。

结束标志：制作《外形评审报告》，通过评审。

■过程8：结构设计

启动条件：通过工业设计评审

过程要点：设计结构图纸

设计PCB板草图

※关键点8：结构设计评审

评审时检验资料：结构图纸

PCB板草图

必须参与的评审人员：产品总监、研发总监、经理、结构/电子工程师 结束标志：制作《结构评审报告》，通过评审。

■过程9：手板制作

启动条件：通过结构设计评审

过程要点：将零部件确认图发外制作手板，并进行跟进。

※关键点9：手板评审

评审时检验资料：手板样品

必须参与的评审人员：产品总监、研发总监、经理、结构/工程师

结束标志：制作《手板评审报告》，通过评审。

■过程10：模具设计

启动条件：通过手板评审

过程要点：联系供应商开模，试模，改模。

模具每次改动都需要填写《设计过程表》。

制作《总装图》《零部件确认图》

《模具/样品验收报告》

※关键点10：模具设计评审

评审时检验资料：《总装图》

《零部件确认图》

装机后的样品

必须参与的评审人员：产品总监、研发总监、经理、结构工程师，工程部 结束标志：制作《模具评审报告》，问题点验证关闭，确定通过评审签字。 ■过程11：包装设计

启动条件：通过手板设计评审

过程要点：设计好包装图纸，打样，测试

■过程12：说明书设计

启动条件：通过手板设计评审

完成代码编写

完成PCB板设计

过程要点：收集产品说明书文字、图片内容

说明书排版。

※关键点11：包装、说明书评审

评审时检验资料：包装图纸和样品、说明书样品

必须参与的评审人员：产品总监、研发总监、经理、产品开发设计工程师、营

销中心相关负责人员

结束标志：制作《包装说明书评审报告》，问题点验证关闭，确定通过评审签字。

■过程13：代码编写

启动条件：通过流程图评审

过程要点：每天进行同行评审，主程序，每个子程序都必须进行同行评审填写

《设计过程表》

※关键点12：代码评审

评审时检验资料：《设计过程表》

整个代码

必须参与的评审人员：项目经理、同行软件件工程师

结束标志：制作《软件评审报告》，问题点验证关闭，确定通过评审签字。 ■过程14：PCB板设计

启动条件：通过原理图评审

通过结构设计评审

过程要点：为软件设计提供测试板，结合结构，软件，采购，生产工艺，测试

方法一起完成PCB板的最终设计，整个过程中允许三次PCB板打

板。

在验证性能时填写与每次改动参数时填写《设计过程表》

测试各种功能，性能。每次试验数据，方法采用《设计过程表》

※关键点13：PCB评审

评审时检验资料：《PCB板图》

装机后的PCB样品

《设计过程表》

必须参与的评审人员：研发中心，产品中心，制造中心，品管部等

结束标志：制作《PCB板评审报告》，问题点验证关闭，确定通过评审签字。 ■过程15：组合测试

启动条件：通过PCB板评审

通过代码评审

通过模具设计评审

过程要点：研发中心或其他部门非设计人员进行测试，每天必须填写《测试记

录表》。

测试产品所有功能，性能

《产品特殊特性检验标准》

※关键点14：组合测试评审

评审时检验资料：《原理图》《PCB板图》《零部件确认图》《说明书》《产

品总装图》《产品接线图》

必须参与的评审人员：研发总监、经理、产品设计、测试工程师

结束标志：所有测试问题点解决，项目经理评估。

制作《PCB板评审报告》，问题点验证关闭，确定通过评审签字

通过包装说明书评审

■过程16：中试部测试

启动条件：通过组合测试评审

过程要点：硬件工程师制作正式样品提供给中试部。

中试部按要求测试，每天填写好《测试记录表》 ，检验合格出《样

品（试验）报告》

制作：正式《初时BOM清单》《设计验证报告》《新产品开发达成表》

制作成品与半成品样件

收集核对更新样件鉴定报告所需的所有资料

■过程17：资料核对

启动条件：《样品试验（检测）报告》中试部判断通过

过程要点：《bom清单》和《新器件采购一览》表给采购。

所有样件鉴定报告所需的所有资料与样品给工程部核对 ■过程18：采购转化工作

启动条件：收到硬件工程师的联络单

过程要点：收集新器件样品，承认书，供应商，制作《新器件采购一览》 ※关键点15：样件鉴定会

评审时检验资料：上述所有关键点需要检验的资料

必须参与的评审人员：总经理、副总经理、产品总监、研发总监、项目工程师

以及营销中心、采购、工程、PMC、生产、品管、

稽核中心相关负责人员

结束标志：通过评审，《样件鉴定报告》判定OK。

※ 研发项目总结会：

评审时检验资料：统计产品物料的通用率

统计资料错误率。

统计计划按时达成

分析项目管理过程中的好与坏

分析技术上的成功与失败

必须参与的评审人员：研发总监，项目组成员

结束标志：制作《项目总结报告》

第二篇：新产品研发项目流程中七要素

引言：PACE在产品开发过程中的应用和扩展是一种实实在在的挑战，而那些成功运用PACE方法论和工具的企业也必将从这种挑战中得到显著的回报。PACE（Product And Cycle-time Excellence，产品及周期优化法）是美国管理咨询公司PRTM于19xx年提出的。经过多年的改进和完善，PACE已经成为产品开发事实上的标准过程参考模型，包括IBM、Motorola、杜邦、华为等在内的许多公司已把PACE的各种理念方法付诸实施。产品开发流程的七要素（一）产品开发流程可以分为七个相关要素，每一个要素都有其常见的不足之处。PACE提供了各种方法、技巧和手段，以克服每一个要素的不足之处。下文对这七个相关要素作了介绍，对一些常见的不足之处进行了总结，并针对每一个要素简单介绍了PACE的解决办法。在以后的章节里，将进一步详述PACE的每一个要素。1、决策所有的公司都有一个新产品决策流程，尽管他们有可能并没有认识到这是一个有明确定义的流程。在决策流程薄弱的公司，因优柔寡断造成的延误很普遍。例如，如果某个实际流程是顺序性的，要求许多经理一一确认某产品设计概念的优劣，那么，起动就会延误。我们看到，许多良机的错失只是因为产品先驱们不知道如何运用这种不正规的决策流程。我们曾经帮助过的一家电脑公司有一个效率低下的决策流程，可以说它是我们所见过的许多流程当中的典型。在这家公司里，项目评审已沦为一系列面向不同听众的冗长的汇报。参加的人很多，提出的问题也很多，但这些汇报会并不是决策会议。评审并没有在开发流程的适当时机进行以促使决策，合适的信息也没有提供出来以推动决策。高层管理人员回避了评审，并且没有其他机制来推动适时决策。然而，并非所有明确定义的决策流程都是有效的。有些流程要么设计得很糟糕，要么实施不当。在这些情况下，一个正正规规的流程实际上对产品开发构成了管理障碍。花费大量时间，却收效甚微，这样的决策流程早已不能推进产品开发。在产品开发评审中，我们发现因决策流程不当会引发下列问题：·由于高层管理人员不知道应该由谁来作出决策，或者需要什么样的一致意见，所以他无意识的延迟决策或修订决策。·信息不够充分或细节不清楚导致决策质量低劣。·没有及时解答疑问。·未定义决策控制点，以至在适当的重要阶段又出现了评审工作。·需要投入的资源过多，以至无法按期完成任何事情。·授权审批和设定优先顺序的人没有明确批准给予产品开发项目的拨付资金。·决策太迟——经常是在产品已经设计出来之后。·没

有用周期指导来证实项目进度。·高层领导没有作出战略决策，却由开发人员在无奈中作出这种决策。在PACE流程中，新产品决策是通过阶段评审流程进行的，这种阶段评审需要在开发流程中具体定义的点上作出决策。一个产品开发项目必须在预定时间内达到明确定义的目标，才能获准进入下一阶段。产品审批委员会（Product Approval Committee, PAC）是指在一个部门或一个公司内负责主要新产品决策的高层领导小组。PAC有权在开发周期内的具体决策点通过给新产品拨付资金或修改新产品的途径来批准或拒绝新产品。PAC负责通过产品开发活动实施公司的战略，因此，他们具有资源分配权，以推进新产品的开发。PAC一般通过阶段评审流程来作出决策和进行资源分配。没有这样一个流程，高层领导就难以有效地引导新产品的开发。然而，只有一个评审流程（或类似的一个流程，如把关流程或阶段开发流程）是不够的。定义不清、实施不当或与开发流程中的其他必要要素不协调，都可能使评审流程效率低下。阶段评审流程在产品开发中还扮演着另一个重要角色。通过它，PAC可以直接明了地授权项目小组分阶段地开发产品。项目小组为产品制定详细的建议，提交产品开发计划，并申请下一阶段所需的资源。如果PAC批准工作小组的各项建议，它会赋予项目小组以权力、责任以及实施小组计划的下一阶段所需要的资源。2、项目小组构成在评审中我们发现，尽管大多数公司有正规的项目小组，但多数并不成功。总的来说，由于这些项目小组的构成、角色和责任没有明确的定义，结果使沟通、协调和决策效率低下、纷繁混乱。有这么一家很典型的公司，不计其数的经理们只在他们有空的时候或是有什么特别原因使会议变得最优先的时候，他们才参加产品开发小组的会议。由于这种方法产生的效果差，所以公司曾尝试用不同的方法来改变这种状况。他们建立了专门的项目管理部门，负责监督进度和任务的提交，以明确由谁去做什么以及事情做了没有。后来，每个部门都给每一个主要项目指定了自己部门的项目经理。但这些方法效果并不理想，只是增加了毫无价值的劳动，而这种劳动已经太多了。许多公司建立了项目小组的组织形式，但大多数效果不佳。针对这些不成功的案例，我们发现以下典型原因：·如果项目小组和职能部门的责权不明确，将造成困惑。·项目小组没有得到明确授权去实现目标，因而效率低下；在某些情况下，他们只被赋予了责任，却没有相应的权力和资源。·缺乏并行工程，一些职能和技能无法和谐地融入到

项目小组中去。·项目领导工作效率低，这源于几个因素：项目领导人没有经验；对项目领导人角色不明确；培训不足；项目领导人更换频繁；或者项目小组的组织有缺陷。·项目小组缺乏项目实施所需的人手和技能，因而无法实现目标；各种资源在项目小组间调来调去，缺乏明确的决定。·由于没有明确定义项目小组和职能部门之间的协作方法，两者之间便有冲突和困扰。·小组成员任务分配造成的困扰使整个小组效率低下：比如说，小组成员把自己看作职能部门的评估者或记录者，而非真正地帮助进行实时决策。项目小组构成是产品开发流程的一个关键要素。一个高效的项目小组能极大地增进沟通、协作和决策。在评审初期，我们就发现许多广为接受的项目小组模式效率低下，而低下的原因与上文所述颇为相似。我们开发了一个新的模式。这个模式既能发挥项目小组这种组织形式的最佳方面，又能克服上述缺陷。我们把它称之为项目小组构成中的核心小组模式（Core Team Approach）。核心小组是有权开发特定产品的一个小型跨部门项目小组。一个典型的核心小组有5—8名成员，有权力也有责任管理所有与开发该特定产品相关的任务。这些特定任务分配到核心小组的每个成员身上，每个成员都利用相应资源完成这些任务。小组成员们为指定给他们的工作确定方向，与职能部门打交道，并作为核心小组的一员参与集体决策。PAC则在开发工作的每一阶段通过阶段评审流程赋予核心小组责任和权力。每个核心小组都有一个指导和引导小组工作的领导人。该小组在执行每一开发阶段时遵守与PAC签定的有关重大项目目标以及可变动的范围的“合同”。3、开发活动的结构开发活动是开发新产品的实质性工作。在PACE中，结构化的开发流程明确了应做什么开发工作、相应的先后次序、其间的关联性以及用于开发项目的标准术语。在评审流程中，我们发现，开发活动的结构中往往存在三类普遍的缺陷：(1)没有任何明确的产品开发结构的公司；(2)有具体流程手册但并没得到遵循的公司；(3)有结构化的流程但并不能改进或加快开发进度的公司。对第一种情况来说，公司必须在产品开发流程中不断地“重新发明车轮”，即重新定义产品开发流程。每一个项目小组都定义其要遵循的流程，结果，每个项目小组即使在执行相同的或相似的任务时，开发流程也迥然不同。这种模式延长了开发周期，且整个公司的项目小组都易犯同样的错误。对第二种情况来说，流程被文档化了，但是并没有得到执行。典型的情况是，某个职员在程序手册里定义

开发流程，然后把手册散发出去，天真地期待每个人都会遵守它，结果当然是他们并不遵守。多数情况下，他们不遵守反而好一点。项目小组又各自将自己的那一套流程搬了出来。对第三种情况来说，开发流程已得到明确和遵守，可惜这个流程天生就效率低下。令人吃惊的是，许多公司在规范流程时，只是简单地将他们现有的做法写成文件，哪怕这个流程效率低下，其结果自然是把问题制度化了。在评审开发流程时，我们发现普遍存在下列缺陷：·无章可循的开发活动导致产品不断更新。·由于对必须完成什么样的开发活动及何时完成有误解，因而造成项目计划不周及准备不足。·缺乏通用术语以及由此引起的理解问题，导致开发工作不理想。·产品开发定义过于详细，尤其是缺乏结构化的定义，使得开发效率不高。·每一步都需要多个签字盖章的官僚流程延缓了开发工作。·缺乏并行工程，因为它没有被设计到结构化开发流程里。·缺乏开发活动的周期时间指导，导致项目进度不准确。·由于没有将责任落实下来，导致未能不断地改进产品开发流程。在PACE方法中，核心小组用结构化开发流程开发产品，这将确保一致性，并避免小组创立各自的流程。基于一个通用的结构化流程，就可以使用通用的周期时间指南并为持续改进打下基础。按照PACE的方法，一个结构化开发流程包括几个等级。在阶段评审流程所提供的框架中，一般有15—20个主要步骤来定义一个公司的产品开发流程；每一步又分成10—30项任务，规定每一个步骤如何在公司里得以实施。这些任务又为每一个步骤定义出标准周期时间，因此可以根据这些基本步骤编制进度表、预估资源需求、制定计划及进行管理。每一项任务还可进一步细分成各种各样的开发活动。根据任务的性质，每一步骤的开发活动数量从几个到30或40个不等。总的来说，各步骤与任务永远适用于各种项目，而开发活动则因项目不同而不同。4、开发工具与技术各种设计技术，例如质量功能配置（quality function deployment, QFD）、装配设计（design for assembly, DFA）和可制造性设计（design for manufacturability, DFM），能促进产品成功并达到相应的运行效果。然而，这些技术中没有哪一个能单独地解决产品开发中的所有问题。举例来说，一个规模宏大、部门众多的高科技公司选择QFD作为其最终的解决方案。公司投入巨资来培训全公司人员的设计技术，并培养了内部QFD专家和顾问，进行相应的宣讲介绍。9个月后，产品开发仍不见起色，项目小组也就解散了。由此，QFD技术受到不公正的指责，这只

是因为人们期望有一项技术能弥补整体综合方案的缺乏。在过去的5—10年中，许多新型自动设计工具已被开发出来，它们可以极大地辅助产品开发流程。这些工具包括计算机辅助工程（CAE）、面向对象的软件开发工具、产品数据管理系统、模拟工具以及用于项目计划、进度和决策的工具。同样，没有单独的一种工具能提供一个完整的解决办法。每种工具都可以更大地提高工作流程的生产率，但所有的工具都需要一个结构化的流程，这是一个先决条件。至于这些工具和技术的使用，我们发现，许多公司犯着这样或那样的错误：要么是没有使用正确的方法或工具，要么是使用效率不高，这些都是因为他们缺乏整体产品开发流程。特别是，下列问题比较普遍：·设计技术效率低下，因为不能很好地融入清晰的产品开发流程。·人们期望某一种设计技术，如QFD，能解决所有产品开发问题。·因为没有使用恰当的设计技术，造成新型产品不可制造或不耐用。·因为没有使用自动化工具，导致产品开发时间比应花的时间要长。·因为产品定义不断变更，导致自动开发工具没有产生预期的效果。PACE流程没有给新技术或新工具下定义，其关注的焦点是在整体产品开发流程这个环境中，适时地运用合适的技术或工具。PACE描述了一系列技术设计和自动开发工具，并表明了它们是怎样适用于该流程的。5、产品战略流程产品战略是新产品开发的起点。通过产品战略，公司定义了要开发的产品的类型、如何区分自己与竞争对手的产品、如何将新技术引入新产品以及开发新产品的优先顺序。选择开发的产品应与整个产品战略保持一致，但情况往往不是这样。产品战略常常没有被定义或表述清楚，即使在公司内部组织过非正式的讨论。如果没有一个清楚的产品战略，开发人员在提议新产品及执行开发项目时就必须进行猜测，他们往往是通过反复试验才得知哪些合适，哪些不合适。有时产品战略与开发项目相离太远，以至于前者仅是一纸厚望，对于实际选择的项目没有任何作用。有一家公司，压倒一切的战略目标就是去开发多种新产品。当再无其他指导，或在缺乏产品思想的评估框架和优先顺序的设立框架的情况下，许多项目是根据开发人员个人或经理们的提议下启动的。尽管有的取得了技术上的成功，但这些项目中的大多数永远不可能完成，或永远不能商品化。该公司的CEO告诉我们说，“如果我早知道他们都在做些什么，我会尽早制止他们。他们的大多数项目与我们的战略并不一致。”我们的经验表明，产品战略制定和交流的常见

不足之处如下：·公司将眼光过分集中于个体产品，而对产品平台的重视不够。·公司里没有人明确负责产品战略。·既然产品战略没有一个正式流程，它往往成为年度预算流程中的一项表面工作。·由于公司不能有效地评估其产品战略机遇，开发出了平庸的产品。·产品战略过时，原因是将眼光集中在当前而非将来顾客的需要和市场潮流上。·由于产品战略是内部驱动而非客户驱动，因而造成产品不具竞争力，竞争性分析肤浅，竞争定位不明确。·由于没有产品战略愿景来指导项目开发工作人员，所以实际产品开发与初衷不符。与盛行的信念相反，最佳产品战略并非来自于令人眩目的革新念头，也不是从数百张充满图表的市场分析报告中得来。例如，数字设备公司只用三页纸定义未来VAX平台，这就概述了计算机历史上最成功的产品战略之一。有效的产品战略来自于一个严格的产品计划定义流程，这些产品计划的制定依据是对市场交替变化、技术进步和竞争态势所带来的机遇的理解。在PACE内，产品战略提供了一个框架，供PAC在阶段评审流程中决策和设立优先顺序之用，并同时为核心小组确立了指南，供其定义产品时使用。产品战略包括明确定义了扩展现有产品线和创造新产品线的机遇。尽管每个公司都有自己的商业战略做法、机构建设、产业及竞争地位等，从而使得具体的产品战略因公司的不同而有所不同，但产品战略仍可作为一个流程来管理。PACE产品战略要素对这一流程进行了定义。6、技术管理技术管理是整个产品开发流程的一个组成部分，技术管理的作用是发现应用新技术的机会，并且启动技术开发项目，从而扩大公司的核心竞争力，并使多种产品受益。我们已经觉察到，一些技术型公司并没有积极管理他们潜在的技术。一些公司过于将注意力放在产品开发上，以至于最后他们只把技术开发当作产品开发工作中的一个次要项目。我们也曾看到一些面临困境的开发项目，跌入技术难题之中，原因在于公司没有意识到他们缺乏开发那些产品所需要的最基本的技术知识。产品开发依赖于技术，无论这技术是内部开发的，还是别人许可使用的，或是从公司外部获得的。要想及时地利用那些可用的技术，就必须了解当前和未来的核心技术，因为技术的开发和技术联盟的建立需要时间。要达到这一点，不应强行要求正在搞产品开发的项目小组去创造或获取这些必要的核心技术。项目开发的风险大小是由其不可避免的、最具风险的因素决定的。假如该因素是核心技术开发，则其不确定性和潜在的延误是不可估量

的。例如，某家公司不懂技术管理，它的研发部门致力于各种技术的开发，其有用期“从现在起持续3—10年”。然而，大多数这样的研发工作没有充分利用公司现有的技术基础。结果，他的核心技术到期后没有其他的核心技术来替代。研发经费的短缺使得一些关乎产品线的核心技术过时了，面对市场份额的节节丢失，公司不得不大量投资以便迎头赶上。在评审产品开发的流程中，我们发现了以下常见的技术管理上的缺陷：·由于技术上出现的意外，使产品开发延迟。如果当初技术准备充分，这些意外本来是可以避免的。·由于公司没有给现在或将来的核心技术进行投资而导致技术效能下降。·由于技术开发没有从产品开发中脱离出来，造成了不必要的开发周期延长。·由于对技术风险控制不足而引起项目失败。PACE内的技术管理要素定义了技术开发流程，以及由技术向产品开发的转换，它澄清了产品开发和技术开发两者之间的区别，并定义了它们与产品战略的联系。7、管道管理最后，当公司消除了产品开发中以项目为基础的各个方面的不足之处后，很明显，它将进一步需要一个更好的管理模式，来管理所有产品开发项目。随着各个项目对有限资源的竞争趋于明朗化，管道管理就成为下一个首选对象。我们发现下面几个问题可由管道管理来解决：·低效的资源调度系统常常导致资源调度过度，从而延迟了开发项目。·作“救火”决策时未考虑到项目的优先顺序。·职能部门预算与项目资源分配不一致。·项目技能要求与部门资源不一致。·产品开发决策没有考虑到公司的增长、产品组合或长/短期侧重点等目标。这些问题存在于所有产品开发项目，也应在所有项目中得到很好的处理。PACE管道管理要素解决这些问题的方法是给项目优先次序的确定和跨项目资源管理提供一种框架，并且将职能部门能力和项目要求协调起来。