长久以来的一个共识是，将结构化和持续性流程贯穿应用于组织中是产品开发成功的关键因素。
提高新产品成功率是可行的，调查表明，开发实践和流程是成功率提升的基础。

管控风险

在整个产品开发流程中，随着产品开发往前推进，累计成本大幅增加。产品开发者面对的挑战是，如何确保随着成本增加产品失败(不确定水平)的风险下降。

☆ 知识能够改进决策和降低不确定性
产品开发流程的成功建立在一系列正确的决策之上，决策来自知识信息和数据。

这个基本框架正是后文要讨论的诸多产品开发流程模型的基石。

作出正确决策所需的知识信息和数据的来源十分广泛：

• 组织记录
• 组织员工
• 外部顾问
• 发表的文献
• 专利
• 竞争对手
• 客户

模糊前端

产品开发项目的前端是一个早期阶段的起点。在进入正式的产品开发流程之前，组织在该阶段识别机会、形成概念。该阶段包括创意生成阶段，初始概念开发阶段和高级业务阶段。一些文献，将其称为“模糊前端”，主要是因为它是项目中定义最不明确的一个阶段。

在早期，成本相对较低，在原型开发的后期以及规模化的商业化的过程中，成本开始大幅上涨。“模糊前端”使得在相对较低的成本下，组织有机会较为清晰的探索新产品的潜力，在这个早期阶段，明智的决策能够明显的减少不确定性，并为持续投资该项目提供信心。

新产品开发流程

新产品流程被定义为：为了将最初的想法不断转化为可销售的产品和服务，公司所开展的一系列条理化的任务和工作流程。
必须强调的是，新产品流程不具有一个适用于所有组织或产品的统一定义。新产品流程应当与组织及其产品或服务的具体需求相符。

在20世纪60年代中期，博斯、艾伦和汉密尔顿等人设计了一个由六个基本阶段构成的流程，这一流程为近年来推出的众多流程奠定了基础，这六个阶段是：

• 探索
• 筛选
• 商业评估
• 开发
• 测试
• 商业化

门径管理流程

新产品流程的定型及其在工业界的广泛应用发生于20世纪80年代。这要归功于80年代早期出现的库珀的门径管理流程。

主要阶段：

• 发现
  寻找新的机会和新的产品创意。
• 筛选
  初步评估市场机会，技术需求以及能力的可获得性。
• 立项分析
  建立在筛选阶段之上的一个关键阶段，包括更为深入的技术市场以及商业可行性分析。
• 开发
  产品设计、原型制造、可制造性设计、制造准备和上市规划。
• 测试与修正
  测试产品及其商业化计划的所有方面，以修正所有假设和结论。
• 上市
  产品的完整商业化，包括规模制造以及商业化上市。

随着行业需求的不断变化，这一流程也在不断更新。
在门禁管理流程中，划分出的阶段数量应根据具体情况进行调整，这取决于：

• 新产品上市的紧迫性。时间越紧张，流程就越受到挤压，阶段就越少。
• 与新产品的不确定性和风险水平相关的技术和市场领域的现有知识。现有的知识面越广，风险越小，所需的阶段也就越少。
• 为降低风险，当不确定性越大时，所需的信息越多，这将导致流程更长。
  

☆ 什么是阶段？
阶段是整个产品开发流程中的一个确定区域，包括：

• 活动

项目负责人和团队成员依照项目计划必须完成的工作。

• 综合分析

通过跨职能部门间的交流，项目负责人和团队成员综合分析所有职能活动的结果。

• 可交付成果

综合分析结果的呈现，这是团队必须完成并在进入关口时所要提交的内容。

☆ 什么是关口？
关口是产品开发流程中的一个确定节点。流程进展至此处时，需要作出有关项目未来的关键决策，包括：

• 可交付成果：关口审评点的输入内容。

可交付成果是前一阶段行为的结果，是事先确定的，在每个关口都有一个可交付成果的标准清单。

• 标准：评判项目时所采用的标尺。

由此决定项目是否通过以及项目的优先级。这些标准通常被设计为一个包括财务标准和定性标准在内的打分表。

• 输出：关口评审的结果。

关口处必须给出明确的输出内容，包括决策（通过、枪毙、搁置、重做）以及下一阶段的路经（通过审批的项目计划，下一个关口的日期和可交付成果）。

☆ 优势

• 为产品开发提供准则和约束
• 强调有质量地决策
• 对所有参与者而言都是透明的
• 适用于多种类型的组织

☆ 局限性

• 有可能变得过度官僚化
• 在没有完全理解的情况下，可能引起过于僵化和成本昂贵的误解
• 遵循准则和约束，可能一定程度上创造力有所扼杀

☆ 发展和应用
门径管理流程，至少在其早期的迭代过程中，呈现出明显的串行和线性特征，但这从来不是原创者的本意。
近年来，库柏在诸多文章中介绍了门径管理流程为适应不同产品开发环境、满足不同的公司需求而发展的新过程。
库柏强调，虽然流程的基本原理始终不变，但应该不断修改门径管理流程的应用，以适应具体的环境。

瀑布流程

瀑布流程的首次开发要归功于温斯顿罗伊斯。在20世纪初，瀑布流程被广泛应用在软件行业。

瀑布流程的五个典型阶段是：

• 要求
  了解设计产品所需的功能、用途、用户需求等。
• 设计
  确定完成项目所需的软件和硬件，随后将它们转化成物理设计。
• 实施
  根据项目要求和设计规范编写实际代码。
• 验证
  确保产品符合客户期望。
• 维护
  通过客户确定产品设计中的不足和错误，进而修正。

今年来，瀑布模型在软件行业中的普及度下降，它变为集成产品开发模型的前身。

并行工程

并行工程是一种集成并行设计产品及其相关过程的系统方法，包括制造和支持。这种方法使得开发商从一开始就要考虑产品生命周期中的所有要素，从概念到实施，从质量、成本、进度到用户需求。

并行工程的基本前提建立在两个概念上。

• 其一，产品生命周期中的所有要素，从功能性、可制造性、装配、测试、维护、环境影响到最终处置和回收，都应在早期设计阶段被逐一考虑。
• 其二，考虑到并行推动流程能显著提高生产力和产品质量，前述设计活动都应同时进行，即并行。

这样一来，就能够在设计过程中的早期阶段，即仍可灵活处置项目时发现错误、重新设计。尽早定位和修复问题可避免当项目推进至更复杂设计建模阶段和硬件的时机制造阶段时，出现代价高昂的错误。

通常认为，并行工程取代了传统流程瀑布模型。

集成产品开发

集成产品开发的概念是由20世纪90年代中被广泛应用于航天产业中的并行工程发展而来的。
集成产品开发的定义为：系统地、综合地应用不同职能体系的成果和理念，有效、高效地开发新产品，满足客户需求的方式。

近年来，一些机构致力于以集成产品开发原理为核心，利用循序渐进的方式来改进整体的产品开发体系，以实现以下目标：从产品开发基本工具的应用推进到项目管理的应用，再推进到客户心声战略连结，最终构建出基于知识获取和管理的学习文化。

上图为“基于集成产品开发系统的组织实践层级”，它说明：集成产品开发更多的是为产品开发的改进提供框架，而不仅仅是一个模型或流程。这个框架囊括了大多数常见的产品，开发流程中的基本原则，而且特别注重学习和持续改进。

精益产品开发

精益产品开发建立在丰田首创的精益方法（TPS）的基础之上。TPS基于消除Muda，日语中的意思是无用 —— 没用的、惰性的、浪费的。设计TPS的主要目的是从制造流程中去掉Muda或浪费。这一原理被引用至产品开发流程中。

精益产品开发是有关生产率**的：

• 每小时或每单元生产的利润
• 对设计者或开发者的有效利用
• 更短的上市时间
• 单位时间内完成更多的项目
• 在更多的时间内积累更多满意的客户
• 更少的浪费

潜在的浪费来源包括：

• 混乱的工作环境
• 缺乏可用资源
• 缺乏明确的优先级次序
• 不同职能间的沟通存在障碍
• 糟糕的产品需求定义
• 缺乏对可制造性的早期考虑
• 过度设计
• 太多无成效会议
• 太多的电子邮件

詹姆斯在《丰田产品开发系统 —— 员工、流程和技术的整合》一书中，就产品开发给出了以下建议：

1. 建立由客户定义的价值，去掉无法带来增值的浪费。
2. 在产品开发前端投入更多精力，全力探索所有可能的解决方案，最大化设计空间。
3. 创建高水准的产品开发流程。
4. 实施严格的标准化流程，以降低变数，创造灵活性，产出可预见的结果。
5. 建立首席工程师体系，由他从头到尾负责开发流程的整合。
6. 平衡职能专长和跨职能整合。
7. 培养每位工程师的能力。
8. 充分整合供应商，将其纳入产品开发体系。
9. 建立学习与持续改进的理念。
10. 营造支持卓越和不断改进的组织文化。
11. 采用与人员和流程相匹配的技术。
12. 通过简单的可视化沟通，使整个组织协同一致。
13. 善用有效的标准化工具和组织学习工具。

☆ 优势

• 流程的聚焦点在于信息的顺畅流动，而非严厉管控。
• 通过事件驱动方法简化合作，优化设计。
• 重视对进度、成本、绩效和质量方面的风险的积极管控。
• 适用于各种规模的项目。
• 用于记录学习和进展，判定优先级和解决问题的工具通常是简单的、可视化的。

☆ 局限性

• 参与人员必须是相当敬业，且经验丰富的。如此才能够为系统改进提出建议，对系统变化作出积极响应。
• 需要改变组织的结构和文化。特别是，组织应具有统一坚定的项目文化以及适当的支持性组织结构。
• 需要强有力的供应商管理。若要进行精益产品开发或实现准时交付，就需要与供应商协调同步，保持良好的沟通。
• 组织有意愿且有能力接受项目目标和方向上的变化。

精益产品开发过程的核心概念，如图：

敏捷产品开发

敏捷方法是在合作环境下，由自组织的团队进行产品迭代开发的过程。其中，通过渐进式的迭代和工作步骤，团队可以应对未预期的事项，这也被称为冲刺。
敏捷开发，在软件行业的应用极为普遍，与硬件行业不同，软件行业的特点是变化不断。

2001年2月，17位软件开发者在犹他州开会讨论轻量级的开发方法，他们发布了敏捷软件开发宣言。

☆ 敏捷软件开发宣言
我们正在寻找更好的开发软件方法，我们全力以赴，同时也在相互帮助，在探索之路上我们总结出了以下几点：

• 个体和交付胜过过程和工具
• 可运行的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

尽管在每一句中，右侧的事项确有价值，但我们认为左侧的事项更重要，价值更大。

☆ 敏捷产品开发的关键原则

1. 我们的首要任务是通过尽早和持续交付有价值的软件来满足客户。
2. 即使在开发后期，我们也欢迎需求变更。敏捷流程将这些变更转化为客户的竞争优势。
3. 频繁地交付可运行的软件，数周或者数月交付一次，时间间隔越短越好。
4. 项目期间，业务人员与开发者共同工作。
5. 招揽积极主动的人员来开发项目，为他们提供所需的环境和支持，相信他们能做好自己的工作。
6. 开发团队里最省事最有效的信息传递方式是面对面交流。
7. 可运行的软件是衡量进度的主要标准。
8. 敏捷流程有利于持续开发。发起人、开发人员和用户应始终保持一个固定的前进步伐。
9. 持续关注先进的技术和优秀的设计，提高敏捷性。
10. 简洁 —— 令待办工作最少化的艺术是一切的基础。
11. 只有自组织团队才能做出最好的架构和设计。
12. 团队定期反思如何提高效率，并调整工作流程。

☆ 敏捷产品开发过程中的关键要素
虽然敏捷产品开发的具体应用可能会依组织而改变，但基本要素通常保持不变，包括以下内容：

• 产品代办列表
• 敏捷流程
• 冲刺
• 产品主管
• 敏捷负责人

• 敏捷团队

• 产品待办列表

产品待办列表是一份包含系统所需的一系列事项要求，并将他们按照优先次序排列的清单，包括功能性和非功能性的客户需求，以及技术团队生产的需求。虽然产品需求列表有多种来源，但是确定优先级次序是产品主管的独有职责。一个产品需求列表，像是一个足够小的工作单元，团队能够在一次冲刺迭代周期中完成。

• 敏捷流程

敏捷流程是由杰夫在1993年创建的一种流程，灵感来自于橄榄球队的争球阵。
可以说，敏捷流程是最流行的敏捷实施框架。通过该方法，软件生成得以按规律的步调进行，并由一系列固定长度的迭代过程开发出产品。

• 冲刺

冲刺是指完成待定任务，使开发阶段得以进入审查环节的一段时期。规划会议是每次冲刺的起点。在会议上，产品主管和开发团队商讨并确定此次冲刺所要完成的工作。冲刺周期由敏捷负责人决定。冲刺开始后，产品主管暂停工作，由开发团队主持工作。在冲刺结束后，团队将已经完成的工作提交给产品主管。产品主管将依照冲刺会议上设定的标准，决定接受或否决这些工作。

• 产品主管

在划分产品待办列表的优先级和罗列需求时，产品主管是代表客户利益、拥有最终决定权的那个人。团队必须随时可以联系到他，特别是在冲刺的规划会议期间。在冲刺开始后，产品主管不应当再管理团队，也不应当再变更任务。产品主管的主要职责是平衡有竞争关系的利益相关者之间的利益。

• 敏捷负责人

敏捷负责人是团队和产品主管之间的协调者。他的工作职责不是管理团队，而是通过以下方式帮助团队和产品主管：

• 销售团队和产品主管之间的障碍
• 激发团队的创造力，给团队授权
• 提升团队生产率
• 改进工程工具和实践
• 确保团队取得进展的信息实时更新，让各方成员均可见

☆ 敏捷团队
敏捷团队通常由7个人组成，也可增加或减少2个人。为实现冲刺目标，团队成员通常由多个职能部门、不是专业的人员（跨职能团队）组成。软件开发团队的成员，包括软件工程师，架构师，程序员，分析员，质量专家，测试员以及UI设计师。在冲刺期间，团队通过自我管理的方式实现冲刺目标，团队在实现目标的方法上有选择自主权，并需对这些目标负责。

下图展示了分解敏捷流程

图片来自网络

☆ 优势

• 对于业务要求很难被文化或难以成功的产品开发项目而言，敏捷流程带来了新的可行机会。
• 凭借敏捷方法，快速变化中的前沿开发得以被迅速编码和测试。一旦出现错误，也可以很容易的纠正。
• 通过定期会议，经常性的更新工作进展。敏捷是一种轻量级的管控方法，因此项目开发有明显的可视性。
• 像任何其他敏捷方法一样，其本质是迭代，需要来自用户的连续反馈。
• 由于冲刺周期短，反馈及时，团队更容易应对变化。
• 通过日常会议可以评估个体的生产力，从而提高团队成员的生产率。
• 通过日常会议可以提前识别问题，然后迅速解决问题。
• 敏捷方法与任何技术或编程语言兼容，特别是快速发展的网络2.0项目或新媒体项目。
• 在流程和管理方面的运营成本最小，因此项目进展更快、花费更少。

☆ 局限性

• 敏捷是出现“范围蔓延”问题的主要原因。这是因为，除非有一个明确的截止日期，否则项目管理相关者会不断要求团队交付新功能。
• 如果任务的定义不明确，对项目成本和时间的预估是不准确的，在这种情况下，可以将任务分散为多次冲刺。
• 如果团队成员没有全力以赴，项目将永远不会完成或将失败。
• 因为敏捷方法可以有小团队完成，它适用于快速变化的小型项目。
• 敏捷方法需要有经验的团队成员，如果团队中有新手，项目可能无法按时完成。
• 若敏捷负责人信任手下的团队，敏捷方法与项目管理的配合效果良好。若敏捷负责人对团队成员实行过程过于严格的控制，将会给团队带来极大的挫败感，导致团队缺乏动力，进而导致项目失败。
• 任何一个团队成员在开发过程中离开都会对项目开发产生巨大的负面效果。
• 难以实施和量化项目质量管理，除非测试团队能够在每次冲刺后进行回归测试。

流程模型的对比

上述的这些模型都有特定的优势和局限性，虽然从中选出某个模型并将其应用在一些特定情况下是合适的，但大多数情景需要将多个模型恰当组合。

敏捷与精益

敏捷和精益的区别很容易理解。虽然大多数人觉得他们在某种程度上是相同的，但是事实并非如此。

精益旨在减少浪费，提高运营效率，特别是适用于制造过程中常见的重复性任务。对于产品开发而言，精益方法的真正价值在于，它的聚焦点 —— 一系列核心原则或指导方针 —— 是产品开发流程的基础。精益不是一个确定的流程，不是一个专注于成功开发新产品所需的特定行为和任务的流程。

敏捷的设计初衷是在短时间内执行任务，与客户进行频繁互动，并能够对变化作出迅速响应。在应用于产品或产品组件的开发时，敏捷的结构流程和角色都有明确的定义。简言之，敏捷，体现了以时间为中心的迭代哲学 —— 以循序渐进的方式构建产品，以小件形式交付产品。它的主要优势之一是，在任一阶段都具有适应和变化的能力（取决于反馈，市场条件，企业障碍等），并只提供与市场相关的产品。

如你所读，精益与敏捷，在本质上毫不相关，你不需要在开发新产品时追求精益，也不需要在提高运营效率时追求敏捷。

敏捷与门径管理

门径管理流程不是一个项目管理或微观规划模型。相反，它是一个全面的完整的从创意到上市阶段的体系，是一个宏观规划流程，是跨职能的（涉及技术产品开发人员，以及营销销售和运营部门）。它极其关注关口，关口构成了一个投资决策模型的基础，在关口处要解答的关键问题是：你在做正确的项目吗？你是否在正确地做项目？

与此相反，敏捷是专为快速开发软件而设计的。在实践中，开发阶段包括一系列的冲刺，每个冲刺或迭代生产一个工作产品（可运行代码或软件）并可以向利益相关者（客户）展示该工作产品。一次迭代，可能无法为产品添加足够的功能，或使产品达到发布要求，但在每次迭代结束时都会有一个潜在的可用版本，这正是迭代的目标。若要发布一个产品或新功能，则通常需要进行多次迭代，一次冲刺通常为3~5周。

罗伯特·库珀对门禁径管理和敏捷的特点进行了很好的解释， 他依照普遍共识 —— 门禁管理，适用于硬件开发，而敏捷适用于软件开发，得出的结论是，这两种方法是互斥的。

同时他提到：敏捷和门径管理是无法相互替代的。相反，敏捷是一种有效的微观规划工具和项目管理工具，可以用于门禁管理流程中，以加快某些阶段 —— 可能是阶段3和阶段4。

集成产品开发与其他

顾名思义，集成产品开发，提供一种将产品开发中的功能、角色和行为集中起来的框架。
它被定义为：系统的、综合的应用，不同职能体系的成果和理念，有效、高效地开发新产品，满足客户需求的方式。

已经融入集成产品开发模型的一个功能是“学习和持续改进”。
专注于产品开发过程和技术的组织，如何发展为以知识为基础的学习型组织。

按理说，门径管理模型的宏观规划特征和决策基础，敏捷模型的微观规划和灵活性，精益相对减少时间与精力浪费的重视，以及学习型组织对产品开发的综合集成，是潜在互补的，而不是相互排斥的。将两个模型中的元素融合的一个真正合适于产品开发流程的模型，并以学习和持续改进为重点，才是真正先进的产品开发实践的标志。

流程的治理

“治理”这个术语通常用来描述董事会的工作内容，其重点是思考战略问题，而不是业务的日常运营。

美国项目管理协会，将治理定义为：用来指导项目、程序和项目组合管理中的活动的框架、功能和流程。
在组织的项目管理中，治理为组织的项目管理的战略执行框架提供了指导、决策和监督。

美国项目管理学会的定义与董事会的工作本质类似。换言之，治理意味着采取高层级和战略性的视角，而不是陷入过程和项目细节。

高级经理或管理团队应当承担的治理责任之一是，保证新产品开发流程的整体有效性。也就是说，正确的过程应当是既有效又高效地专注于提供正确的结果。

从治理的角度看，你应当能够回答以下问题：

• 是否针对组织及其产品或服务有关的需求调整了产品开发流程？整个组织是否很好的沟通理解和接受了这一流程？
• 新产品和服务的结果是否要满足一些可度量的目标？这些目标对产品开发中的所有相关人员所了解和接受吗？
• 是否存在与流程相关的度量指标，如实际花费与预算、里程碑的时间点、整体开发周期时间？这些度量指标是学习和持续改进的基础吗？
• 你是否恰当的平衡了管理权限和个人责任？
• 决策协议和流程是否促成有效且及时的决策？是否存在任何重大的不必要的可能导致失败的延误的障碍？
• 是否基于组织的跨职能部分输入信息输出信息和流程度量指标，定期审查产品开发流程？

产品创新章程

产品开发项目成功实施的基础是建立在创新战略之上的明确意图和方向。该基础的确切定义由产品创新章程提供。

产品创新章程是指：一份关键的战略性文件，是组织推动新产品商业化过程的核心，它涵盖了项目的立项原因，目的目标准则和边界。他回答的产品开发项目中，谁、什么、哪里、何时、为什么这五个问题。
在探索阶段，对市场偏好，客户需求，销售潜力和利润潜力作出假定。在开发阶段，经过原型开发和市场测试，以上假定可能遭遇挑战。随着项目的逐阶段发展，业务需求和市场条件将会随之变化，项目开发者必须确保项目不偏离原有的发展轨道。在开发阶段必须将实际相当于该规程进行反复对比核查，以确保该规程仍然正确，项目未发生偏离，并且与此同时，项目的发展机会仍然存在。

☆ 产品创新规程的内容
产品创新规程通常是一个相对简短的总结性文件，以及一些其他附加文件，如项目计划、附录。
它包含以下几个具体部分：

• 背景
• 重点舞台
• 目标和目的
• 特别准则

☆ 背景

• 确认项目 —— 项目的目的，与经营战略和创新战略的关系，为什么组织要做这个项目？
• 项目的范围 —— 项目的关注点有多宽或多窄？
• 项目团队在实现项目目标中的作用。
• 项目限制 —— 资金，资源，制造，市场营销等任何可能影响项目成功的因素。
• 任何现有和未来的关键技术。
• 环境、行业和市场分析，能够解释新产品所处的情景 —— 客户、竞争对手、法律法规等。

☆ 重点舞台
舞台一词主要是体育或文艺界表演的场所，这个行业已经扩展到了商业领域，以表示呈现并完成业务活动的地点。
产品创新规程应该包含：

• 目标市场（表演的发生地）
• 关键技术和营销方法（如何表演）
• 支持项目成功的关键技术和市场规模
• 竞争对手的优势和劣势（其他表演者） —— 技术、营销、平台、市场占有率、制造等。

☆ 目标和目的

• 为经营战略作出贡献的特定目标。例如，在新市场中的份额，当前市场份额的增加。
• 经营目标 —— 利润，销售量，成本消减，生产力增加。
• 项目相关的目标 —— 财务预算，上市时间。
• 每个目的或目标应该对应着具体的，可衡量的成功标准 —— 绩效指标。

☆ 特别准则

• 项目团队的工作关系 —— 如何、何时召开会议。
• 项目汇报 —— 频率、形式、利益相关者。
• 预算支出责任。
• 外部机构的参与，如监管机构。
• 与上市时间或产品质量有关的特别规定。