新产品流程

产品经理认证NPDP知识体系指南思维导图，第3章：新产品流程知识总结。

第3章 新产品流程（20%，40题）

经组织理解认可的开发新产品或改进现有产品的途径

产品开发是跨学科的组织行为，将结构化和持续性流程贯彻应用于组织中，是产品开发成功的关键因素

3.1 产品开发：一个“风险与回报”的过程

开发实践和流程是新产品成功率的基础

管控新产品失败的风险

产品开发者面对的挑战，如何确保随着成本增加，产品失败（不确定性水平）的风险下降

知识能够改进决策，降低不确定性

产品开发流程的成功建立在一系列正确的决策之上，决策来自

知识

信息

数据

决策所需知识、信息和数据的来源

组织记录

组织员工

外部顾问

发表的文献

专利

竞争对手

客户

产品开发流程中“前端（Front End）”的重要性

模糊前端（Fuzzy Front End）

项目中定义最不明确的阶段

正式产品开发流程之前

识别机会、形成概念

包括创意生成阶段、初始概念发展阶段和高级业务阶段

使得在相对较低的成本下，组织有机会较为清晰地探索新产品的潜力

明智的决策能够显著减少不确定性，并未持续投资该项目提供信心

3.2 几个产品开发流程

新产品流程定义

“为了将最初的想法不断转化为可销售的产品和服务，公司所开展的一系列条理化的任务和工作流程。”——卡恩，2013

新产品流程不具有普适性的统一定义，应与组织及其产品或服务的具体需求相符

各种产品开发流程的介绍和对比

历史

化学产品开发八阶段流程——20世纪40年代

NASA 阶段评估流程——20世纪60年代

6阶段流程——20世纪60年代中期

探索（Exploration）

筛选（Screening）

商业评估（Business Evaluation）

开发（Develpment）

测试（Testing）

商业化（Commercialization）

当前

门径管理流程（Stage-Gate）

集成产品开发（Integrated Product Development，IPD）

精益开发（Lean）

敏捷开发（Agile）

设计思维（Design Thinking）

3.2.1 门径管理流程

主要阶段

发现（Discovery）

寻找新的机会和新产品创意

筛选（Scoping）

初步评估市场机会、技术需求以及能力的可获得性

立项分析（Business Case）

建立在筛选阶段之上的一个关键阶段，包括更为深入的技术、市场以及商业可行性分析

开发（Development）

产品设计、原型制造、可制造型设计、制造准备和上市规划

测试与修正（Testing and Validation）

测试产品及其商业化计划的所有方面，以修正所有假设和结论

上市（Launch）

产品的完整商业化，包括规模制造以及商业化上市

阶段数量的划分依据

新产品上市的紧迫性

时间越紧张，流程受到挤压，阶段就越少

与新产品的不确定性或风险水平相关的技术和市场领域的现有知识

现有知识面越广，风险越小，所需阶段也越少

为降低风险，当不确定性越大时，所需的信息越多，这将导致流程更长

什么是阶段（Stage）

阶段是整个产品开发流程中的一个确定区域

活动（Activities）

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

综合分析（Integrated Analysis）

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

可交付成果（Deliverables）

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

什么是关口（Gate）

关口是产品开发流程中的一个确定节点，需作出有关项目未来的关键决策

可交付成果（Deliverables）

关口评审点的输入内容

可交付成果标准清单

标准（Criteria）

评判项目的标尺

打分表

财务标准

定性标准

输出（Outputs）

关口评审的结果

决策

路径

门径管理流程的优势和局限性

优势

为产品开发提供准则和约束

强调要有质量地决策

对所有参与者而言都是透明的

适用于多种类型的组织

局限性

有可能变得过度官僚化

在没有完全理解的情况下，可能引起过于僵化和成本昂贵的误解

遵循准则和约束可能一定程度上创造力有所扼杀

门径管理流程的发展和应用

早期迭代，串行和线性特征

应程序修改流程的应用以适应具体情境——库珀，2014

3.2.2 集成产品开发

并行工程（Concurrent Engineering）

“并行工程是一种集成、并行设计产品及其相关过程的系统方法，包括制造和支持。”

基本前提

产品生命周期中的所有要素，都应在早期设计阶段被逐一考虑

前述设计活动应同时进行，即并行。发现错误，重新设计

并行工程取代了传统流程“瀑布模型”（Waterfall Model）

瀑布流程

首次开发——罗伊斯，1970

20世纪初，广泛应用于软件行业

5个典型阶段

要求

了解设计产品所需的功能、用途、用户需求等

设计

确定完成项目所需的软件和硬件，随后将它们转化为物理设计

实施

根据项目要求和设计规范编写实际代码

验证

确保产品符合客户期望

维护

通过客户确定产品设计中的不足或错误，进而改正

集成产品开发模型的前身

集成产品开发

“系统地、综合地应用不同职能体系的成果和理念，有效、高效地开发新产品、满足客户需求的方式。“——卡恩，2013

IBM PLM方案，2009

软件系统整合不总是成功

软件系统发展成了产品信息孤岛

发布产品开发集成框架（PDIF），强调管理这一复杂问题的必要性

目标

从产品开发基本工具的应用推进到项目管理的应用

在推进到客户心声、战略连接

构建出基于知识获取和管理的学习文化

组织实践层级

基本工具

项目与团队

项目管理

跨职能团队

可制造型设计

聚焦客户

客户心声

基于客户需求进行设计

战略与组合

产品战略

项目选择战略

绩效度量

知识、技能与创新

知识获取与管理

能力开发

创新文化开发

3.2.3 精益产品开发

Lean Product Development

建立在丰田首创的精益方法（Toyota Production System，TPS）基础上

主要目的

从制程中去掉Muda或浪费

这一原理被引用至产品开发流程中

精益产品开发是有关生产率（Productivity）的——马斯特利，2011

每小时或每单元产生的利润

对设计这或开发者的有效利用

更短的上市时间

单位时间内完成更多的项目

在更多的时间内积累更多满意的客户

更少的浪费

潜在的浪费来源包括

混乱的工作环境

缺乏可用资源

缺乏明确的优先级次序

不同职能间的沟通存在障碍

糟糕的产品需求定义

缺乏对可制造性的早期考虑

过度设计

太多的无成效会议

太多的电子邮件

解决浪费的建议

建立由客户定义的价值，去掉无法带来增值的浪费

在产品开发前端投入更多精力，全力探索所有可能的解决方案，最大化设计空间

创建高水准的产品开发流程

实施严格的标准化流程，以降低变数，创造灵活性，产出可预见的结果

建立首席工程师体系，由他从头到尾负责开发流程的整合

平衡职能专长和跨职能整合

培养每位工程师的能力

充分整合供应商，将其纳入产品开发体系

建立学习与持续改进的理念

营造支持卓越和不断改进的组织文化

采用与人员和流程相匹配的技术

通过简单的可视化沟通，使整个组织协同一致

善用有效的标准化工具和组织学习工具

精益产品开发的优势和局限性

优势

流程的聚焦点在于信息的顺畅流动，而非严厉管控

通过事件驱动方法简化合作，优化设计

重视对进度、成本、绩效和质量方面的风险的积极管控

适用于各种规模的项目

用于记录学习和进展、判定优先级和解决问题的工具通常是简单的、可视化的

局限性

参与人员必须是相当敬业且经验丰富的

需要改变组织的结构和文化

需要强有力的供应商管理

组织有意愿且有能力接受项目目标和方向上的变化

3.2.4 敏捷产品开发

敏捷开发是在合作环境下由自我管理的团队进行产品迭代开发的过程

渐进式

冲刺（Sprints）

轻量级

敏捷软件开发宣言

个体和交互胜过过程和工具

可运行的软件胜过面面俱到的文档

客户合作胜过合同谈判

响应变化胜过遵循计划

敏捷产品开发的关键原则

首要任务是通过尽早和持续交付有价值的软件来满足客户

即使在开发后期，我们也欢迎需求变更

敏捷流程将这些变更转化为客户的竞争优势

频繁地交付可运行的软件，数周或者数月交付一次，时间间隔越短越好

项目期间，业务人员与开发者共同工作

招揽积极主动的人员来开发项目，为他们提供所需的环境和支持，相信他们能做好自己的工作

开发团队里最省时最有效的信息传递方式是面对面交流

可运行的软件是衡量进展的主要标准

敏捷流程有利于可持续开发

发起人、开发人员和用户应始终保持一个固定的前进步伐

持续关注先进的技术和优秀的设计，提高敏捷性

简洁——令待办工作最少化的艺术是一切的基础

只有自我管理的团队才能做出最好的架构和设计

团队定期反思如何提高效率并调整工作流程

敏捷产品开发过程的关键要素

产品待办列表（Product Backlog）

一份包含系统所需的一系列事项要求并将它们按优先次序排列的清单

包括功能性和非功能性的客户需求，以及技术团队产生的需求

敏捷流程（Scrum）

“争球阵”——萨瑟兰，2014

最流行的敏捷实施框架

软件生成得以按规律的步调进行，并由一系列固定长度的迭代过程开发出产品

冲刺（Sprint）

指完成特定任务，使开发阶段得以进入审查环节的一段时期

规划会议是每次冲刺的起点

冲刺周期由敏捷负责人决定

冲刺阶段由开发团队主持工作

冲刺结束，产品主管依照会议设定的标准，决定接受或否决这些工作

产品主管（Product Owner）

在划分产品待办列表的优先级和罗列需求时，产品主管是代表客户利益、拥有最终决定权

冲刺开始后，产品主管不再管理团队，也不应再变更任务

主要职责是平衡有竞争关系的利益相关者之间的利益

敏捷负责人（Scrum Master）

团队和产品主管之间的协调者

子主题

工作职责是帮助团队和产品主管

消除团队和产品主管之间的障碍

激发团队的创造力，给团队授权

提升团队生产率

改进工程工具和实践

确保团队取得进展的信息实时更新，让各方成员均可见

敏捷团队 （Scrum Team）

通常有7人组成，也可增加或减少2人

通常多部门、非专业的人员组成

软件工程师

架构师

程序员

质量专家

测试员

UI设计师

冲刺期间，自我管理，方法上自主权，并对目标负责

分解敏捷流程

产品需求列表——冲刺需求列表——冲刺——软件的可运行增量

敏捷产品开发的优势和局限性

优势

成功的新的可行机会

快速开发和测试，快速纠正

轻量级，进展更新，可视性

本质是迭代，需用户连续反馈

更易应对变化

通过评估，提高团队成员生产率

提前识别问题，迅速解决

适应面广

运营成本小，进展快，花费少

局限性

“范围蔓延”风险

定义不明确，则成本与时间预估不准确。可分为多次冲刺

团队如果不全力以赴，则项目永远不会完成或将失败

可由小型团队完成，适用于快速变化的小型项目

需有经验的团队成员

敏捷负责人的信任与控制，影响团队的积极性与动力

团队成员离开，对项目开发产生巨大负面效果

难以实施和量化项目质量管理，除非测试团队能够在每次冲刺后进行回归测试

3.3 产品开发流程模型的对比与总结

3.3.1 敏捷与精益

精益

旨在减少浪费，提高运营效率

特别适用于制造过程中常见的重复性任务

它所聚焦的一系列核心原则或者指导方针，是新产品开发流程的基础

不是一个确定的流程，不是一个专注于成功开发新产品所需的特定行为和任务的流程

精益产品开发的13条准则，被丰田首先采用

敏捷

短时间内执行任务，频繁互动，迅速响应

产品开发时，敏捷的结构、流程和角色定义明确

以时间为中心的迭代哲学，以循序渐进的方式构建产品，以小件形式交付产品

优势之一，在任一阶段都具有适应和变化的能力（取决于反馈、市场条件、企业障碍等），并只提供与市场相关的产品

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

3.3.2 敏捷与门径管理

门径管理流程

不是一个项目管理或微观规划模型，是一个全面、完整、从创意到上市阶段的体系，宏观规划流程，跨职能

极其关注关口，关口构成了一个投资决策模型的基础

敏捷

为快速开发软件而设计

开发阶段包括一系列冲刺

通常一个产品或新功能需要多次迭代

一次冲刺通常为3~5周

门径管理适用于开发硬件，敏捷适用于开发软件，无法相互替代

”敏捷是一种有效的微观规划工具和项目管理工具，可用于门径管理流程中，以加快某些阶段——可能是阶段3和阶段4“——库珀，2015

门径管理与敏捷的区别列表

门径

方法类型

宏观计划

范围

从创意到上市，端点到端点

组织宽度

跨职能——技术、市场、制造

重点

在市场上发布一个新产品

决策模型

投资模式：生/杀模式，高层管理者参与

敏捷

方法类型

宏观计划，项目管理

范围

只在开发和测试阶段

组织宽度

技术（码农、工程师、IT员工）

重点

开发和测试后的软件产品

决策模型

主要是战术性的：下一次冲刺所需的行动

软件开发时敏捷在门径管理中的作用——获得授权复印，库珀，2015

发现阶段

关口1

创意筛选

互动：客户或用户

第1阶段 筛选

关口2

2次筛选

互动：客户或用户

第2阶段 立项分析

关口3

进入开发

互动：客户或用户

第3阶段 开发

关口4

进入测试

互动：客户或用户

第4阶段 测试和修正

关口5

进入上市

互动：客户或用户

第5阶段 上市

PLR

上市后审查

互动：客户或用户

3.3.3 集成产品开发与其他流程模型

提供一种将产品开发中的功能、角色和行为集成起来的框架

定义为”系统地、综合地应用不同职能体系的成果和理念，有效、高效地开发新产品、满足客户需求的方式

“学习与改进模型已融入集成产品开发模型

各流程潜在可互补，而不是相互排斥。将每个模型中的元素融合为一个真正适合于产品开发流程的模型，并以学习和持续改进为重点，才是真正先进的产品开发实践的标志

3.4 产品开发流程的治理

重点是思考战略问题，而不是业务的日常运营

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

治理意味着采取高层级和战略性的视角，而不是陷入过程和项目细节

正确的过程应当及有效又高效地专注于提供正确的结果

治理角度的问题

是否针对与组织及其产品或服务有关的需求调整了产品开发流程？整个组织是否很好地沟通、理解和接受了这一流程？

新产品或服务的结果是否要满足一些可度量的目标？这些目标被产品开发中的所有相关人员所了解和接受吗？

是否存在与流程相关的度量指标，如实际花费与预算、里程碑的时间点、整体开发周期时间？这些度量指标是学习和持续改进的基础吗？

你是否恰当地平衡了管理权限和个人责任？

决策协议和流程能否促成有效且及时地决策？是否存在任何重大的、不必要的、可能导致失败和延误的障碍？

是否基于组织的跨职能部分输入信息、输入信息和流程度量指标，定期审查产品开发流程？

3.5 产品创新规程

产品开发项目成功实施的基础是建立在创新战略之上的明确意图和方向，该基础的确切定义由“产品创新规程”（Product Innovation Charter）提供

产品创新规程指一份关键的战略性文件，是组织推动新产品商业化过程的核心。它涵盖了项目的立项原因、目的、目标、准则和边界。

产品创新规程的内容

通常是一个相对简短的总结性文件以及一些其他附加文件。

包含

背景

验证项目

项目的范围

项目团队在实现项目目标中的作用

项目限制

任何现有和未来的关键技术

环境、行业和市场分析，能够解释新产品所处的情景

重点舞台

“舞台”（arena），在商业领域表示呈现并弯沉业务的地点

目标市场

关键技术和营销方法

支持项目成功的关键技术和市场规模

竞争对手的优势和劣势

目标和目的

为经营战略作出贡献的特定目标

经营目标——利润、销售量、成本消减、生产力增加

项目相关的目标——财务预算、上市时间

每个目的或目标应该对应着具体的、可衡量的成功标准——绩效指标

特别准则

项目团队内的工作关系——如何、合适召开会议

项目汇报——频率、形式、利益相关者

预算支出责任

外部机构的参与，如监管机构

与上市时间或产品质量有关的特别规定

总结

在整个公司采用结构化的、持续性的流程能够大大提供产品开发的成功率

产品开发本质上是一个风险与汇报的过程。应用条理化的流程和实践是为了降低不确定性水平、提升产品成功概率

在整个新产品开发流程中，随着新产品开发往前推进，成本大幅增加，特别是在最后的设计、原型制作和从规模化到商业化阶段。至关重要的一点是，应当在新产品开发的早期（经常称为”模糊前端“）投入大量精力，以保证有关项目成功率的决策是切实可靠的

多种流程模型，每种流程模型都有其优势，其应用一般与整个新产品开发流程中的某些阶段相匹配。门径管理流程囊括从创意到上市的整个流程，而大多数其他流程这聚焦在整个流程中的某些阶段

美景管理、集成开发、瀑布、敏捷、精益和设计思维模型在特定的公司和产品的应用上各有优势。深入理解每种模型的原理非常重要。如此，才能将最恰当的模型应用于具体的公司情境。通常采用的是两种或者更多模型的组合

所有流程模型均遵循以下共同原则

关注战略一致性

基于知识进行决策，以降低产品失败的风险

应用跨职能团队

是一个结构化框架，要被整个组织所理解和应用

在产品开发上取得真正成功的组织能够理解新产品成功的基本原则，他们向其他组织学习，致力于不断改进

产品开发成功实施的基础是关于创新战略和特定产品开发项目的意图的确切定义。这一定义被写入产品创新规程