NPDP框架新产品流程

组合管理

显而易见.产品开发是一个涉及多个学科的组织行为,需要基于一系列来源不一的 输入内容做出正确的决策。长久以来形成的一个共识是,将结构化和持续性流程贯彻应 用于组织中是产品开发成功的关键因素。随着新产品流程的发展,一系列模型应运而生。 每个模型都有其独特之处,适用于不同的情境中口

第3章新产品流程

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

罗伯特•库珀提出了一个有趣的说法,他将产品开发比作赌博(库珀,2001 )。产 品开发过程大致等同于一个“风险管理”的赌局,赌局的规则是:

-如果不确定性高,则赌注下得少些;

-随着不确定性降低,赌注增加。

埃隆•马斯克,太空探索技术公司(SpaceX)的创始人、首席执行官和首席技术官, 特斯拉(Tesla Motors)的首席执行官和产品架构师,他曾说:“来冒险吧!做点刺激的 事儿!你不会为此后悔的。”虽然他的胆气令人钦佩,但大多数蛆织考慮到新产品失败 的历史记录,会选择规避风险的发展之路.大多数研究显示,新产品失败率超过50%。

対•大多数组织而言,•个关键问题是:“是否有可能降低失败率?”如果有可能, 如何降低?

2012年,PDMA的一项调査显示,新产品的成功率为61% (马卡姆和李,2013 L 成功率在很大程度上取决于企业采用的新产品开发实践和流程的质量。

•在表现最好的公司,成功率达到82%;

・其他公司成功率为59%。

显然,提高新产品成功率是可行的。调查表明,开发实践和流程是成功率提升的基础,

X管控新产品失败风险

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

开发阶段

图3.2风险随成本增加而下降

>知识能鑽改进决策,降低不确定性

产品开发流程的成功建立在一系列正确的决策之上。决策来自知识、信息和数据。

图3,3是--个应用广泛的标准的决策框架。这个基本框架正是后文所要讨论的诸多 产品开发流程模型的基石。

图3.3标准的决策框架

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

・组织记录;

•组织员工;

•外部顾问;

,发表的文献;

•专利;

•竞争对手;

・客户,等等。

我们将在工具与绩效度量、市场研究这两章中进一步讨论知识收集工具。

~产品幵发流程中“前端”的重要性

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

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

区L练习3 1

你所在的组织是否注重在 '模糊前端”阶段做出决策?

在顶目早期阶段,你所在的组织为了改进决策、降低深入开发和产品上市的不确定性 而有哪些率措?

I 3.2几个产品幵发流程

在过去的50年里,产品开发流程的研究和应用迅猛发展。因此出现了多种流程, 很多流程是为不同的行业、产品或市场而设计的。

新产品流程被定义为:

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

必须强调的是,新产品流程不具有一个适用于所有组织或产品的统一定义。新产品 流程应当与组织及其产品或服务的具体需求相符。

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

产品开发流程的早期定义可以回溯到化学产品开发八阶段流程——出现于20世纪 40年代。在20世纪60年代,美国宇航局(NASA)将阶段化开发的概念加以应用。美 国宇航局使用的是“阶段评估流程”,即项目开发被划分为多个阶段,在每个阶段完成 之后进行一次评估。

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

•探索(Exploration );

•筛选(Screening );

•商业评估(Business Evaluation );

•开发(Development );

•测试(Testing);

•商业化(Commercialization )。

新产品流程的定型及其在工业界的广泛应用发生于20世纪80年代。这要归功于80 年代早期岀现的库珀的门径管理流程(Stage-Gate®, http://www.prod-dev.com/)o

在过去的30年中,我们目睹了一系列新产品流程的发展,旨在满足特定组织基于 不同的产品和市场环境而产生的需求。本章的后续内容包括对一部分新产品流程的介 绍,以及在特定情景下各个流程的优缺点的概述。这些流程包括:

・门径管理流程(Stage-Gate®);

•集成产品开发(Integrated Product Development, IPD );

・精益开发(Lean);

・敏捷开发(Agile);

•设计思维(Design Thinking )。

练习3.2

在深入学习本童内容之前,请思考你所在的组织采用的产品幵发流程:

・流程是如何组织的?

•由谁管理9

•有谁参与?

•是否持续应用于整个组织中?

3.2.1门径管理流程

库珀和艾杰特在20世纪80年代早期首先提出了门径管理流程(Stage-Gate40 Process )o随着行业需求的不断变化,这一流程也在不断更新(Product Development Institute Inc®, http://www.prod-dev.com/ )0 图 3.4 展示了门径管理流程的基本模型。

门径管理流程的主要阶段是:

•发现(Discovery):寻找新的机会和新产品创意。

*筛选(Scoping):初步评估市场机会、技术需求以及能力的可获得性,

•立项分析(Business Case ):建立在筛选阶段之上的一个关键阶段,包括更为深入 的技术、市场以及商业可行性分析。

・开发(Development):产品设计、原型制造、可制造性设计、制造准备和上市 规划。

♦测试与修正(Testing and Validation ): 产品及其商业化计划的所有方面,以

修正所有假设和结论。

・上市(Launch ):产品的完整商业化,包括规模制造以及商业化上市。

在门径管理流程中,划分出的阶段数量应根据具体情况进行调整,这取决于:

•新产品上市的紧迫性。时间越紧张,流程受到挤压,阶段就越少。

*与新产品的不确定性或风险水平相关的技术和市场领域的现有知识。现有的知识 面越广,风险越小,所需的阶段也就越少。

・为降低风险,当不确定性越大时,所需的信息越多,这将导致流程更长(见图3.5 )。

图3.5门径管理流程的简化示意

〜什么是阶段(Stage)

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

・活动(Activities ):项目负责人和团队成员依照项目计划必须完成的工作,

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

・可交付成果(Deliverables):综合分析结果的呈现,这是团队必须完成并在进入 关口时所要提交的内容。(产品开发研究公司®)

独什么是关口(Gate)

关口是产品开发流程中的一个确定节点。流程进展至此处时,需要做岀有关项目未 来的关键决策,包括:

•可交付成果(Deliverables ):关口评审点的输入内容。可交付成果是前一阶段行 为的结果,是事先确定的。在每个关口都有一个可交付成果的标准清单。

•标准(Criteria ):评判项目时所釆用的标尺,由此决定项目是否通过以及项目的 优先级。这些标准通常被设计为一个包括财务标准和定性标准在内的打分表n

•输出(Outputs):关口评审的结果。关口姓必须给出明确的输岀内容,包括决策 (通过/枪毙/搁置/重做)及下一阶段的路径(通过审批的项目计划、下一个关口 的日期和可交付成果)□(产品开发研究公司®)

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

1. 优势

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

•强调要有质量地决策;

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

•适用于多种类型的组织。

2. 局限性

・有可能变得过度官僚化;

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

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

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

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

案例:根据具体情景修改门径管理流程

一家有着悠久历史、坚实技术专长和良好制造能力的冰激凌公司要进行一条 简单产品线延伸的开发口在这种情况下,开发的复杂程度是非常低的,成功的概 率较商、失败的风险也较小这家公司可能只需要开展一个简短的流程,包括初 始立项分析,进而进入迭代规划(或设计)阶段、通过产品测试,最终将产品推 向市场“开发周期时间可能为1~3个月。

另一个例子是一家在目标市场内累和了一定经验但技术能力有限的公司,希 望开发一款适合10-12岁儿童驾驶的模型玩具车:目标市场所期待的产品特性和 滲在需求都具有较大的不确定,性.在这种情况下,不确定姓不仅仅存在于产品概 念和设计规范中,还存在于设计和制造过程的复杂性。可以预想到,此时门径管 理流程包括的阶段更多、更强调关口处的评审,以保证公司的决策是正确的,并 减少不确定性“此时,应当特别聚焦于“模糊前端”的槪念发展阶段和初始业务 分析阶段.还可以预想到,在流程后期应对设计制造、市场测试、最终可行性分 析和规模制造投入更多关注,以使产品成功上市。开发周期时间预计为6个月至 2年。

3.2.2集成产品开发

集成产品开发的概念是由20世纪90年代中被广泛应用于航空航天产业中的“并行 工程”(Concurrent Engineering)发展而来的。“并行工程是一种集成、并行设计产品及 其相关过程的系统方法,包括制造和支持。这种方法使得开发商从一开始就要考虑产品 生命周期中的所有要素,从概念到实施,从质量、成本、进度到用户需求。”(温纳等人, 1988 )

并行工程的基本前提建立在两个概念上。其一,产品生命周期中的所有要素,从功 能性、可制造性、装配、测试、维护、环境影响到最终处置和回收,都应在早期设计阶 段被逐一考虑。其二,考虑到并行推动流程能显著提高生产力和产品质量,前述设计活 动都应同时进行,即并行。这样一来,就能够在设计过程的早期阶段,即仍可灵活处置 项目时,发现错误、重新设计。尽早地定位和修复问题可以避免当项目推进至更复杂的 计算建模阶段和硬件的实际制造阶段时,出现代价高昂的错误。

通常认为,并行工程取代了传统流程“瀑布模型”(Waterfall Model)。瀑布流程的 首次开发要归功于温斯顿•罗伊斯(罗伊斯,1970 )□在21世纪初,瀑布流程被广泛应 用在软件行业(见图3.6)。

瀑布流程的5个典型阶段是:

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

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

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

*验证:确保产品符合客户期望。

•维护:通过客户确定产品设计中的不足或错误,进而修正。

圏3.6瀑布流程

近年来,瀑布模型在软件行业中的普及度下降,它变为集成产品开发模型的前身& 集成产品开发的定义为:“系统地、综合地应用不同职能体系的成果和理念,有效、

高效地开发新产品、满足客户需求的方式丁(卡恩,2013)。

在20世纪80年代早期,在采用了瀑布流程-•段时间后,【BM逐渐转向了集成产品 开发流程0 IBM给出了选择这一转变的理由:"(IBM必须)满足客户需求,遵守法律法 规,达到安全标准,减少维护成本并优化利用企业资源。为了满足这些复杂的要求,公 司已在数个最佳软件系统上投入巨资。问题是,对这些软件系统的整合并不总是成功的, 这些软件系统反而发展成了支离破碎的产品信息孤岛。IBM发布的产品开发集成框架 (PDIF )强调了在产品开发的生命周期中管理这一复杂冋题的必要性(见图3.7 )厂(IBM PLM 方案,2009)

图3.7集成产品开发框架示例

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

图3.8说明,集成产品开发更多的是为产品开发的改进提供框架,而不仅仅是一个 模型或流程。这个框架囊括了大多数常见的产品开发流程中的基本原则,且特别注重学 习和持续改进。

写出集成产品幵发的基本原理。

你认为集成产品开发、门径管理流程和瀑布流程之间的共性和差异性有哪些?

3.2.3精益产品开发

精益产品开发(Lean Product Development)建立在丰田首创的精益方法(Toyota Production System, TPS )的基础上。TPS基于消除Muda,日语中的意思是无用 没

用的、惰性的、浪费的。设计TPS的主要目的是从制造流程中去掉Muda或浪费。这一 原理被引用至产品开发流程中。

X什么是精益产品幵发

精益产品开发是有关生产率(Productivity )的(马斯特利,2011

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

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

-更短的上市时间;

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

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

•更少的浪费。

N潜在的浪费来源包括:

•混乱的工作环境;

•缺乏可用资源;

•缺乏明确的优先级次序;

・不同职能间的洶通存在障碍;

•糟糕的产品需求定义;

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

•过度设计;

・太多的无成效会议;

•太多的电子邮件。

詹姆斯•摩根和杰弗里.莱克在《丰田产品开发系统——员工、流程和技术的整合》 (The Toyota Product Development System: Integrating People.Process and Technology) (2006,生产力出版社)一书中,就产品开发给出了以下建议;

1. 建立由客户定义的价值,去掉无法带来增值的浪费;

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

空间;

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

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

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

6. 平衡职能专长和跨职能整合;

7. 培养每位工程师的能力;

8. 充分整合供应商,将其纳入产品开发体系;

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

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

11. 釆用与人员和流程相匹配的技术;

12. 通过简单的可视化沟通,使整个组织协同一致;

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

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

1.优势

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

・通过事件驱动方法简化合作,优化设计;

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

・适用于各种规模的项目;

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

2. 局限性

・参与人员必须是相当敬业且经验丰富的。如此才能够为系统改进提出建议,对系 统变化做岀积极响应。

•需要改变组织的结构和文化。特别是,组织应具有统一坚定的项目文化以及适当 的支持性组织结构。

•需要强有力的供应商管理。若要进行精益产品开发或实现准时交付,就需要与供 应商协调同步,保持良好的沟通。

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

精益产品开发过程的核心概念如图3.9所示。

图3.9精益产品开发过程的核心概念

回练习3.4

写出精益产品开发的基本原则。

在你所在的组织中,写出3个或4个产品开发中可以经由精益幵发而完成改诳的环节。

3.2.4敏捷产品开发

敏捷方法是在合作环境下由自组织的团队进行产品迭代开发的过程匚其中,通过渐 进式的迭代工作步骤,团队可以应对未预期的事项,这也被称为冲刺(Sprints )o敏捷 开发在软件行业的应用极为普遍。与硬件行业不同,软件行业的特点是变化不断。有关 敏捷产品开发的进一步介绍可阅读参考书目。

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

〜敏捷软件幵发宣言

“我们正在寻找更好的开发软件的方法。我们全力以赴,同时也在互相帮助。在探 索之路上,我们总结出了以下几点:

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

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

・客户合作胜过合同谈判;

・响应变化胜过遵循计划。

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

(http://www.agilemanifesto.org/)

1敏捷产品幵发的关键原则

以下是敏捷产品开发的关键原则概述。(http://agilemanifesto.org/principles.html)

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

2. 即使在开发后期,我们也欢迎需求变更。敏捷流程将这些变更转化为客户的竞 争优势;

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

4. 项目期间,业务人员与开发者共同工作;

5. 招揽积极主动的人员来开发项目,为他们提供所需的环境和支持,相信他们能

做好自己的工作;

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

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

8. 敏捷流程有利于可持续开发。发起人、开发人员和用户应始终保持一个固定的 前进步伐;

9. 持续关注先进的技术和优秀的设计,提高敏捷性;

10. 简洁一待办工作最少化的艺术是一切的基础;

11. 只有自组织团队才能做岀最好的架构和设计;

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

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

虽然敏捷产品开发的具体应用可能会依组织而改变,但基本要素通常保持不变,包括:

•产品待办歹U表(Product Backlog );

・敏捷流程(Scrum );

•冲刺(Sprint );

•产品主管(Product Owner);

•敏捷教练(Scrum Master );

•敏捷团队(Scrum Team )o

〜产品待办列表

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

N敏捷,流程

敏捷流程是由杰夫•萨瑟兰在1993年创建的一种流程,灵感来自橄榄球队的“争 球” (Scrum )阵。(萨瑟兰,2014)

可以说,敏捷流程是最流行的敏捷实施框架。通过该方法.软件生成得以按规律的 步调进行,并由一系列固定长度的迭代过程开发出产品。

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

图3.10冲刺规划会议

〜产品主管

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

原词为Scrumc 译者注

决定权的那个人。团队必须随时可以联系到他,特别是在冲刺的规划会议期间。在冲刺 开始后,产品主管不应当再管理团队,也不应当再变更任务。产品主管的主要职责是平 衡有竞争关系的利益相关者之间的利益。

,敏捷教练

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

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

・激发团队的创造力,给团队授权;

・提升团队生产率;

・改进工程工具和实践;

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

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

图3.11分解敏捷流程

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

1. 优势

-对于业务要求很难被量化或难以成功的产品开发项目而言,敏捷流程带来了新的 可行机会。

・凭借敏捷方法,快速变化中的前沿开发得以被迅速编码和测试。一旦出现错误, 也可以很容易地纠正。

・通过定期会议经常性地更新工作进展。敏捷是一种轻量级的管控方法,因此项目 开发有明显的可视性。

-像任何其他敏捷方法一样,其本质是迭代,需要来自用户的连续反馈。

・由于冲剌周期短、反馈及时,团队更容易应对变化。

-通过日常会议可以评估个体的生产力,从而提高团队成员的生产率。

・通过日常会议可以提前识别问题,随后迅速解决问题。

・敏捷方法与任何技术或编程语言兼容,特别是快速发展的网络2.Q项目或新媒体 项目。

•在流程和管理方面的运营成本最』、,因此项目进展更快、花费更少。

2. 局限性

・敏捷是岀现“范围蔓延”冋题的主要原因。这是因为,除非有一个明确的截止日 期,否则项目管理相关者会不断要求团队交付新功能。

•如果任务的定义不明确,对项目成本和时间的预估是不准确的。在这种情况下, 可以将任务分散为多次冲刺。

・如果团队成员没有全力以赴,项目将永远不会完成或将失败。

・因为敏捷方法可以由小型团队完成,它适用于快速变化的小型项目。

•敏捷方法需要有经验的团队成员。如果团队中有新手,项目可能无法按时完成。

・若敏捷教练信任手下的团队,敏捷方法与项冃管理的配合效果良好。若敏捷教练 对团队成员实行过于严格的控制将会给团队带来极大的挫败感,导致团队缺乏动

力,进而导致项目失败。

•任何-个团队成员在开发过程中离开都会对项冃开发产生巨大的负面效果。

・项目质理经理难以将实施和量化落地,除非测试团队能够在每次冲刺后进行回归 测试口

0练习3.5

写出敏捷产品开发的整个过程。

敏捷产品开发是贯穿于产品幵发中的一个管理流程吗?还是说,它主要聚焦于整个产 品幵发中的一些特定要素?

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

随着对成功的产品开发条件的深入理解,组织逐渐适应并改进了流程方法,以满足 特定的组织环境和产品类别的需求。研究人员和从业人员已经认识到,“一刀切”的方 法在产品开发流程中不起效。在前几节中我们介紹了一些近年来已被开发和应用的重要 模型。这些模型都有特定的优势和局限性。虽然,从中选出某个模型并将其应用在一些 特定情境下是合适的,但大多数情景需要将多个模型恰当组合。

3.3.1敏捷与精益

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

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

这些准则被丰田首先采用。

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

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

3.3.2敏捷与门径管理

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

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

罗伯特-库珀对门径管理和敏捷的特点进行了很好的解释,如表3.1所示。他依照 普遍共识一门径管理适用于开发硬件,而敏捷适用于开发软件,得出的结论是这两种 方法是互斥的如图3.12所示。库珀提到:“敏捷和门径管理是无法相互替代的。相反, 敏捷是一种有效的微观规划工具和项目管理工具,可以用于门径管理流程中,以加快某 些阶段——可能是阶段3和阶段4。”(库珀,2015 )0

表3.1门径管理与敏捷

客户或用户

不太复杂的小型项目可以选择座缩流程:采用2 ~ 3个关口

图3.12软件开发时敏捷在门径管理中的作用(获得授权复印,库珀,2015)

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

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

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

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

13.4产品开发流程的治理

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

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

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

本章所提及的每个新产品开发流程在基本结构和基本原则上都有其显著优势。但每 个流程也可能仅仅考虑了自己的原则,导致流程重于结果。例如,交付团队通常会制作 必需的文件,如需求文档或架构文档,仅仅为了通过关口。高级经理或管理团队应当承 担的治理责任之一是,保证新产品开发流程的整体有效性。也就是说,正确的过程应当 是既有效又高效地专注于提供正确的结果。

从治理的角度来看,你应当能够回答以下问题:

1. 是否针对与组织及其产品或服务有关的需求调整了产品开发流程?整个组织是

否很好地沟通、理解和接受了这一流程?

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

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

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

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

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

[ZL练习3.6

现在你已经掌握了一系列产品幵发流程,请绘制一份表格,按照以下问题对比这些流程:

•它是否对整个产品幵发流程逬行管理?

•它是否专注于跨职能团队的使用?

•它能加快上市速度吗?

•它最适用于什么类型的产品和行业?

•它如何降低产品失败的风险?

•它是线性的还是迭代的?

3.5产品创新章程

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

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

〜产品创新章程的内容

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

•背景;

•重点舞台;

•目标和目的;

•特别准则。

每个部分的内容如下所述。

1产品创新章程一背景

•确认项目一项目的目的、与经营战略和创新战略的关系。为什么组织要做这个 项目?

•项目的范围——项目的关注点有多宽或多窄?

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

•项目限制——资源、资金、制造、市场营销等任何可能影响项目成功的因素。

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

•环境、行业和市场分析,能够解释新产品所处的情景——客户、竞争对手、法律 法规等。

独产品创新章程一重点舞台

“舞台” (arena) 一词主要是指体育或文艺界表演的场所。这个含义已经扩展到了商 业领域,以表示呈现并完成业务活动的地点。产品创新章程应该包含:

•目标市场(表演的发生地);

•关键技术和营销方法(如何表演);

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

•竞争对手的优势和劣势(其他表演者)一技术、营销、品牌、市场占有率、制 造等。

、产品创新章程一目标和目的

•为经营战略做出贡献的特定目标。例如,在新市场中的份额、当前市场份额的增 加。

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

•项目相关的目标一财务预算、上市时间。

•每个目的或目标应该对应着具体的、可衡量的成功标准——绩效指标(见第5章 的详细介绍)0

肘产品创新章程一特别准则

•项目团队内的工作关系——如何、何时召开会议;

•项目汇报一频率、形式、利益相关者;

•预算支出责任;

•外部机构的参与,如监管机构;

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

什么是产品创新章程的关键组成部分?简要概述每个组成部分。

为你熟悉的产品写一份产品创新章程,只包括一些基本信息即可,不要尝试涵盖太多 的细节。

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

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

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

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

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

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

—关注战略一致性;

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

-强调将利益相关者的输入信息融入设计决策;

-应用跨职能团队;

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

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

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

参考文献

1. Agile Manifesto for software development, 2001. http://www.agilemanifesto.org/

2. Booz and company, 1982. New products management for the 1980's

3. Cooper, R G 2001. Winning at New Products, p 124, 3rd Edition Wiley

4. Cooper, R G 2011. Winning at New Products: creating value through innovation, 4th Edition, Basic Books

5. Cooper, R.G 2014. What's next after Stage-Gate®, Research-Technology Management, Jan-Feb, 2014, pp 20-31

6. Cooper, R G, 2015. Stage-Gate® and Agile development: debunking the myths http://www.stage-gate.com/resources_stage-gate_agile.php

7. IBM PLM Solutions,2009, ftp://public.dhe.ibm.com/software/plm/ resources/ IBM_ Product_Development.pdf

8. Kahn, Kenneth B, 2013. ed. PDMA Handbook, 3m Edition Wiley

9. Luchs, M G, Swan, SK and Griffin, A. 2015. Design thinking. John Wiley &Sons

10. Markham S K and Hyunjung Lee. Product Development and Management Association's 2012 Comparative Performance Assessment Study. Journal of Product Innovation Management, Vol 30 No 3

11. Morgan J M and Jeffrey K. Liker, 2006. The Toyota Product Development System, Integrating People, Process and Technology, Productivity Press

12. Mascitelli, Ronald, 2011. Mastering Lean Product Development: A practical event-driven process fbr maximizing speed, profits and quality

13. Pichler, R, 2013. Agile Product Development with scrum: creating products that customers love

14. Product Development Institute® http://www.prod-dev.com/

15. Royce, W W (1970). "Managing the Development of Large Software Systems" in: Technical Papers of Western Electronic Show and Convention (WesCon) August 25—28, 1970, Los Angeles, USA

16. Sutherland, Jeff, 2014. Scrum: The Art of Doing Twice the Work in Half the Time

17. Winner, Robert L, Pennell, Janies P., Bertrand, Harold E., and Slusarczuk, Marko M. G (1991). "The Role of Concurrent Engineering in Weapons System Acquisition", Institute for Defense Analyses Report R-338, December 1988