导图社区 NPDP3新产品开发流程
这是一篇关于NPDP3新产品开发流程的思维导图。包括:产品开发流程产品开发流程模型的对比与总结、产品开发流程的治理、产品创新章程。
编辑于2021-10-20 10:15:24新产品流程
产品开发:一个“风险与回报”的过程
库珀(2001)
产品开发过程大致等同于一个“风险管理”的赌局,赌局的规则:
如果不确定性高,则赌注下得少些
随着不确定性降低,赌注增加
PDMD 2012 年的一项调查显示,新产品的成功率为61%(马卡姆和李,2013)。成功率很大程度上取决于企业采用的新产品开发实践和流程的质量
在表现好的公司,成功率达到82%
其他公司成功率为59%
管控新产品失败风险
新产品开发的累计成本
风险随成本增加而下降
知识能够改变决策,降低不确定性
标准的决策框架
做出正确决策所需的知识、信息和数据的来源
组织记录
组织员工
外部顾问
发表的文献
专利
竞争对手
客户,等等
产品开发流程中“前端”的重要性(模糊前端,Fuzzy Front End)
在进入正式的产品开发流程之前,组织在该阶段识别机会、形成概念
该阶段包括:创意生成阶段、初始概念开发阶段和高级业务阶段
在早期,成本相对较低。在原型开发后期以及规模化到商业化的过程中,成本开始大幅上涨。“模糊前端”使得在相处较低的成本下,组织有机会较为清晰地探索新产品的潜力
产品开发流程
新产品流程定义(卡恩,2013)
为了将最初的想法不断转化为可销售的产品和服务,公司所开展的一系列条理化的任务和工作流程
博斯、艾伦和汉密斯顿(1982) 6 阶段
探索(Exploration)
筛选(Screening)
商业评估(Bussiness Evaluation)
开发(Development)
测试(Testing)
商业化(Commercialization)
新产品开发流程
门径管理流程(Stage-Gate)——库珀和艾杰特(20 世纪 80 年代)
门径管理流程的基本模型
门径管理流程的主要阶段
发现(Discovery)
寻找新的机会和新产品创意
筛选(Scoping)
初步评估市场机会、技术需求以及能力的可获得性
立项分析(Bussiness Case)
简历在筛选阶段之上的一个关键阶段,包括更为深入的技术、市场以及商业可行性分析
开发(Development)
产品设计、原型制造、可制造型设计、制造准备和上市规划
测试与修正(Testing and Validation)
测试产品及其商业化计划的所有方面,以修正所有假设和结论
上市(Launch)
产品的完整商业化,包括规模制造以及商业化上市
门径管理流程阶段、数量调整取决于
新产品上市的紧迫性。时间越紧张,流程受到挤压,阶段就越少
与新产品的不确定性或风险水平相关的技术和市场领域的现有知识。现有知识面越广,风险越小,所需的阶段也就越少
为降低风险,当不确定性越大时,所需的信息越多,导致流程更长
门径管理流程的简化示意图
阶段(Stage)
含义
阶段时整个产品开发流程中的一个确定区域
包括
活动(Activities)
项目负责人和团队成员依照项目计划必须完成的工作
综合分析(Integrated Analysis)
通过跨职能部门间的交流,项目负责人和团队成员综合分析所有只能活动的结果
可交付成果(Deliverables)
综合分析结果的呈现,这是团队必须完成并在进入关口时索要提交的内容
关口(Gate)
含义
关口是产品开发流程中一个确定节点。流程进展至此处时,需要作出有关项目未来的关键决策
包括
可交付成果(Deliverables)
关口评审点的输入内容。可交付成功是前一阶段行为的结果,是实现确定的。在每个关口有一个可交付成果的标准清单
标准(Criteria)
评判项目时所采用的标尺,由此决定项目是否通过以及项目的优先级。这些标准通常被设计为一个包括财务标准和定性标准在内的打分表
输出(Outputs)
关口评审的结果。关口处必须给出明确的输出内容,包括决策(通过/枪毙/搁置/重做)及下一个阶段的路径(通过审批的项目计划、下一个关口的日期和可交付成果)
门径管理流程的优势和局限性
优势
为产品开发提供了准则和约束
强调要有质量地决策
对所有参与者而言都是透明的
是用于多种类型的组织
局限性
有可能变得过度官僚化
在没有完全理解的情况下,可能引起过于僵化和成本高昂的误解
遵循准则和约束可能一定程度上创造力有所扼杀
门径管理流程的发展和应用
库珀(2014)
虽然流程的基本原理始终不变,但应该不管修改门径管理流程的应用以适应具体的情境
集成产品开发(Integrated Product Development,IPD)
集成产品开发的概念是由 20 世纪 90 年代中被广泛应用于航空航天产品中的“并行工程(Concurrent Engineering)”发展而来
温纳等人(1988)
并行工程是一种集成、并行设计产品及其相关过程的系统方法,包括制造和支持。这种方法使得开发商从一开始就要考虑产品生命周期中的所有要素。从概念到实施,从质量、成本、进度到用户需求
并行工程的基本前提
产品生命周中的所有要素,从功能性、可制造性、装配、测试、维护、环境影响到最终处置和回收,都是在早期设计阶段被主义考虑的
考虑到并行推动流程能显著提高生产力和产品质量,前述的设计活动都用同时进行,即并行
瀑布模型(Waterfall Model)
温斯顿·罗伊斯(1970),21是基础广泛应用在软件行业
5 各阶段
要求
了解涉及产品所需的功能、用途、用户需求等
设计
确定完成项目所需的软件和硬件,随后将它们转化为物理设计
实施
根据项目要求和设计规范编写实际代码
验证
确保产品符合客户期望
维护
通过客户确定产品设计中的不足或错误,进而修正
集成产品开发的定义(卡恩,2013)
系统地、综合地应用不同职能体系的成果和理念,有效、高效地开发新产品、满足客户需求的方式
IBM 由瀑布转向集成产品开发流程
满足客户需求,遵守法律部法规,达到安全标准,减少维护成本并优化利用企业资源
产品生命周期管理
IBM PLM方案(2009)
实现目标
从产品开发基本工具的应用推进到项目管理的应用,在推进到客户心声、战略联结,最终构建出基于知识获取和管理的学习文化
基于集成产品开发系统的组织实践层级
特点
特别注重学习和持续改进
精益开发(Lean)
什么是精益产品开发(精益产品开发是有关生产率(Productivity))的(马斯特利,2011)
每小时或每个单元产生的利润
对设计者或开发者的有效利用
更短的上市时间
单位时间内完成更多的项目
在更多的时间内积累更多满意的客户
更少的浪费
潜在的浪费来源
混乱的工作环境
缺乏可用资源
缺乏明确的优先级次序
不同职能间的沟通存在障碍
糟糕的产品需求定义
缺乏对克制造性的早期考虑
过度设计
太多的无成效会议
太多的电子邮件
新产品开发的建议
建立由客户定义的价值,去掉无法带来增值的浪费
在产品开发前端投入更多精力,全力探索所有可能的解决方案,最大化设计空间
创建高水准的产品开发流程
实施严格的标准化流程,以降低变数,创造灵活性,产出可预见的结果
建立首席工程师体系,由他从头到尾负责开发流程的整合
平衡职能专长和跨职能整合
培养每位工程师的能力
充分整合供应商,将其纳入产品开发体系
建立学习与持续改进的理念
营造支持卓越和不断改进的组织文化
采用与人员和流程相匹配的技术
通过简单的可视化沟通,使整个组织协同一致
善用有效的标准化工具和组织学习工具
精益产品开发的优势和局限性
优势
流程的聚焦点在于信息的顺畅流动,而非严厉管控
通过事件驱动方法简化合作,优化设计
重视对进度、成本、绩效和质量方面的风险的积极管控
适用于各种规模的项目
用于记录和进展、判定优先级和解决问题的工具通常是简单的、可视化的
局现象
参与人员必须是相当敬业且经验丰富的。如此才能够为系统改进提出建议,对系统变化做出积极响应
需要改变组织的机构和文化。特别是,组织应具有统一坚定的项目文化以及适当的支持性组织结构
需要强有力的供应商管理。若要进行精益产品开发或实现准时交付,就需要与供应商协调同步,保持良好沟通
组织有意愿且有能力接受项目目标和方向上的变化
精益产品开发过程的核心概念
敏捷开发(Agile)
敏捷
敏捷方法是在合作环境下由自由组织的团队进行产品迭代开发的过程
通过渐进式的迭代工作步骤,团队可以应对未来预期的事项,这也被称为冲刺(Sprints)
敏捷开发在软件行业的应用较为普遍
2001 年 2 月,17 位软件开发者在犹他州开会讨论轻量级的开发方法、发布敏捷开发宣言
尽管在每一句话中,右侧的事项确有价值,但我们认为左侧的是想更重要、价值更大
个体和交互胜过过程和工具
可运行的软件胜过面面俱到的文档
客户合作胜过合同谈判
相应变化胜过遵循计划
敏捷产品开发的关键原则
我们的首要任务是通过尽早和持续可交付有价值软件来满足客户
即使在开发后期,我们也欢迎需求变更。敏捷流程将这些变化转化为客户的竞争优势
频繁地交付可运行的软件,数周或数月交付一次,时间间隔越短越好
项目期间,业务人员与开发者共同工作
招揽积极主动的人员来开发项目,为他们提供所需的环境和支持,相信他们能做好自己的工作
开发团队里最省时有效的信息传递方式是面对面交流
可运行的软件是衡量进展的主要指标
敏捷流程有利于可持续发张。发起人、开发人员和用户应始终保持一个固定的前进步伐
持续关注先进的技术和优秀的设计,提高敏捷性
简洁——令待办工作最少化的艺术是一切的基础
只有自组织团队才能做出最好的架构和设计
团队定期反思如何提高工作效率并且调整工作流程
敏捷产品开发过程的关键要素
产品待办列表(Product Backlog)
产品待办列表是一份包含系统所需的一系列事项要求并将他们按优先次序排列的清单,包括功能性和非功能性的客户需求,以及技术团队的需求
虽然产品待办列表有多种来源,但是确定优先级次序是产品主管的独有职责
一个产品代办列表项是一个足够小的工作单元,团队能够在一次冲刺迭代周期中完成
敏捷流程(Scrum)
含义——(萨瑟兰,2014)
敏捷流程是由杰夫·萨瑟兰在1993年创建的一种流程,灵感来自橄榄球队的“争球”Ccrum阵
敏捷流程是最流程的敏捷实施框架。通过该方法,软件生成得以按规律的步调进行,并有一系列固定长度的迭代过程开发出新产品
冲刺(Sprint)
含义
冲刺是指完成特定任务,使开发阶段得以进入审查环节的一段时期
规划会议
规划会议是每个冲刺的起点。规划会议上,产品主管(分配工作的人)和团队开发商商讨并确定此次冲刺所要完成的工作。冲刺周期由敏捷教练决定
冲刺规划会议
冲刺
冲刺开始后
产品主管暂停工作,有开发团队主持工作
冲刺结束时
团队将完成的工作交给产品主管。产品主管将依次按照冲刺会议上设定的标准,决定接受或否决这些工作
产品主管(Product Owner)
是谁
在划分产品待办列表的优先级和罗列需求时,产品主管是代表客户利益、拥有最终决定全的人
任务
团队必须随时可以联系到他,特别是在冲刺的规划会议期间
冲刺开始后,产品主管不应当再管理团队,也不应当再变更任务
产品主管的主要职责是平衡竞争关系的利益相关者之间的利益
敏捷教练(Scrum Master)
敏捷教练是团队和产品主管之间的协调者。他的工作职责不是管理团队,而是帮助团队和产品主管
敏捷教练帮助团队和产品主管的方式
消除团队和产品主管之前的障碍
激发团队的创造力,给团队授权
提升团队上产率
改进工程工具和实践
确保团队得以进展的信息实时更新,让各方成员均可见
敏捷团队(Scrum Team)
敏捷团队通常由 7 个人组成,也可以增加或减少 2 个人
为实现冲刺目标,团队成员通常由多个职能部门、不是专业(跨职能团队)的人员组成
软件开发团队成员包括软件工程师、架构师、程序员、分析员、质量专家、测试员以及 UI 设计师等
在冲刺期间,团队实现自组织的方式实现冲刺目标
团队在实现目标的方法上有选择自主权,并需对这些目标负责
分解敏捷流程
敏捷产品开发的优势和局限性
优势
对于业务要求很难被量化或难以成功的产品开发而言,敏捷流程带来了新的可行机会
拼接敏捷方法,快速变化中的前沿开发得以被迅速编码和测试。一旦出现问题,也可以很容易地纠正
通过定期会议经常性地更新工作进度。敏捷是一种轻量级的管控方法,因此项目开发有明显的可视性
向任何其他敏捷方法一样,其本质是迭代,需要来自用户的连续反馈
由于冲刺周期短、反馈及时,团队更容易应对变化
通常日常会议可以评估个体的生产力,从而提高团队成员的生产率
通过日常会议可以提前识别问题,随后迅速解决问题
敏捷方法与任何技术或编程语言兼容,特别是快速发展的网络 2.0 项目或新媒体项目
在流程和管理方面的运营成本最小,因此项目进展更快、花费更少
局限性
敏捷是出现“范围蔓延”问题的主要原因。这是因为,除非有一个明确的截止日期,否则项目管理相关者会不管要求团队交付新功能
如果任务的定义不明确,对项目成本和时间的预估是不准确的。在这种情况下,可以将任务分散为多次冲刺
如果团队成员没有全力以赴,项目奖永远不会完成或将失败
因为敏捷方法可以由小型团队完成,它适用于快速变化的小型项目
敏捷方法需要有经验的团队成员。如果团队中有新手,项目可能无法按时完成
若敏捷教练信任手下的团队,敏捷方法与项目管理的配合效果更好。若敏捷教练对团队成员实行过于严格的控制将会给团队成员带来极大的挫败感,导致团队缺乏动力、进而导致项目失败
任何一个团队成员在开发过程中离开都会对项目开发产生巨大的负面效果
项目质量经理难以将实施和量化落地,除非测试团队能够在每次冲刺后进行回归测试
设计思维(Design Thinking)
产品开发流程模型的对比与总结
某个模型将其应用在一些特定情况下 是合适的,但大多数情景需要将多个模型恰当组合
敏捷与精益
精益
精益旨在减少浪费,提高运营效率,特别适用于制造过程中常见的重复性任务
对于产品开发而言,精益方法的真正价值在于,他的聚焦点——一系列核心原则或指导方针——是新产品开发流程的基础
精益步是一个确定的流程,不是一个专注于成功开发新产品所需的特定行为和任务流程
敏捷
敏捷设计初衷是在短时间内执行任务,与客户进行频繁互动并能够对变化做出迅速响应
在应用于产品或产品组件的开发时,敏捷的结构、流程和角色都有明确的定义。简言之,敏捷体现了以时间为中心的迭代哲学——以循序渐进的方式构建产品,以小件形式交付产品
优势之一是在任意阶段都具有适应和变化(取决于反馈、市场条件、企业障碍等),并只提供与市场相关的产品
精益与敏捷在本质上毫不相关,你不需要在开发新产品时追求精益,也不需要在提高运营效率时追求敏捷
敏捷与门径管理
门径管理
门径管理流程
门径管理流程不是一个项目管理或围观规划模型。相反,他是一个全面的、完整的、从创意到上市阶段的体系,是一个宏观的规划流程,是跨职能的(涉及技术产品开发人员,以及销售、营销和运营部门)
极其关注关口
关口构成了一个投资决策模型的基础,关口处需要解答的关键问题
你在做正确的项目吗
你是否在正确地做项目
敏捷
敏捷是专为快速开发软件而设计的
实践中,开发阶段包括一系列的冲刺,每个冲刺或迭代产生一个工作产品(可运行代码或软件)并可以向利益相关者(客户)展示工作产品
一次迭代可能无法为产品添加足够的功能或使用产品达到发布要求,但在每次迭代结束时都会有一个潜在的可用版本,这是迭代的目标
若要发不一个产品或新功能,则通常需要进行多次迭代。一次冲刺通常为 3~5 周
子主题
敏捷和门径管理的关系
库珀(2015)
敏捷和门径管理是无法相互替代的。相反,敏捷是一种有效的围观规划工具和项目管理工具,可以用于门径管理流程中,以加快某些阶段——可能是阶段 3 和阶段 4 。
门径管理与敏捷
软件开发时敏捷在门径管理中的作用(库珀,2015)
集成产品开发与其他流程管理
集成产品开发
集成产品开发提供一种产品开发中的功能、角色和行为集成起来的框架
定义
系统地、综合地应用不同职能体系的成功和理念,有效、高效地开发新产品、满足客户需求的方式
门径管理模型的宏观规划特性和决策基础,敏捷模型的微观规划和灵活性,精益地减少时间与精力浪费的重视,以及学习型组织对产品开发的综合集成是潜在可互补的,而不是相互排斥的
每个模型中的元素融合为一个真正适合于产品开发流程的模型,并以学习和持续改进为重点,才是正真先进的产品开发实践的标志
产品开发流程的治理
“治理”这个术语通常用来描述董事会的工作内容,其重点是思考战略问题,而不是业务的日常运营
定义(美国项目管理协会(Project Management Insitute))
用来指导项目、程序和项目组合管理中的活动的框架、功能和流程。在组织的项目管理中,治理为组织的项目管理的战略执行框架提供了指导、决策和监督
从治理角度来看需要回答的问题
是否针对与组织及其产品或服务有关的需求调整了产品开发流程?整个组织是否很好地沟通、理解和接受了这一流程?
新产品或服务的结果是否要满足一下可度量的目标?这些目标被产品开发中的所有相关人员所了解和接受吗
是否存在与流程相关的度量指标,如实际花销与预算、里程碑的时间点、整体开发周期时间?这些度量指标是学习和持续改进的基础吗
你是否恰当地平衡了管理权限和个人责任?
决策协议和流程能否促成有效且及时地决策?是否存在任何重大的、不必要的、可能导致失败和延误的障碍?
是否基于组织的跨职能部分输入信息、输出信息和流程度量指标,定期审查产品开发流程?
产品创新章程
产品创新章程是指,一份关键的战略性文件,使组织推进新产品商业化过程的核心。它涵盖了项目立项原因、目的、目标、准则和边界。他回答了产品开发项目中“谁、什么、哪里、何时、为什么”这 5 个问题
产品创新章程的内容
背景
确认项目——项目的目的、与经营战略和创新战略的关系。为什么组织要做整个项目?
项目的范围——项目的关注点有多宽或多窄?
项目团队在实施项目目标中的作用
项目限制——资源、资金、制造、市场营销等任何形式可能影响项目成功的因素
任何现有和未来的关键技术
环境、行业和市场分析,能够解释新产品所处的情景——客户、竞争对手、法律法规等
重点舞台
舞台(arena)一词主要是指体育或文艺界表演的场所。这个含义已经扩展到了商业领域,以表示呈现并完成业务活动的地点
产品创新章程的重点舞台包含
目标市场(表演的发生地)
关键技术和营销方法(如何表演)
支持项目成功的关键技术和市场规模
竞争对手的优势和劣势(其他表演)——技术、营销、品牌、市场占有率、制造等
目标和目的
为经营战略做出贡献的特定目标
如:在新市场中的份额、当地市场份额的增长
经营目标——利润、销售量、成本消减、生产力增加
项目相关的目标——财务预算、上市时间
每个目的或目标应该对应着具体的、可衡量的成功标准——绩效指标
特别准则
项目团队内的工作关系——如何、何时召开会议
项目汇报——频率、形式、利益相关者
预算支持责任
外部机构的参与
如:监管机构
与上市时间或产品质量有关的特别规定