集成产品开发IPD培训稿课件.ppt

研发管理系列课程之RDM001,IPD集成产品开发,课程目录,2. IPD概述,1、案例分析,3. IPD模式下市场如何驱动研发,7.IPD的优化与实施,4. IPD的组织与团队,0、公司及培训课程介绍,5.IPD的产品开发流程,6.IPD的业务决策与技术评审,我们对企业核心价值链的理解,课程清单（一）,课程清单（二）,课程清单（三）,课程清单（四）,单元一、案例分析,案例分析一,请阅读案例资料，各小组讨论15分钟，从流程的角度来分析该公司产品开发过程中存在的问题，总结5-7条，各小组选派一名代表分享讨论成果,思考？,从这个失败的产品开发案例的分析中，有哪些原因我们公司也在发生？,单元二、IPD概述,产品开发管理的发展历程,摘自下一代的产品开发,产品开发是可以管理的,对一个公司开发的所有产品来说，其过程都是相似的 这种相似性使得产品开发流程可以进行规范、定义和管理 产品开发是一个流程（建立一个有效的开发机制，为企业新产品的开发提供思路、途径和组织保证）,为什么需要产品开发流程,将公司产品开发的成功经验固化在公司 使注意力集中到更具有创造性的产品开发方面 将重复性的任务进行结构化，技术专家就能够把精力集中在真正新的、以前没有作过的工作上 看似简单和清楚的问题并不能够真正做到： 与产品开发相关的人应该清楚他们所参与的是什么工作，应该用什么方式去完成,业界最佳实践的研发管理模式,IPD的框架,产品开发流程在企业整体运作中的位置,流程体系设计需要结构化、层次化,产品开发流程和项目管理的关系,产品开发的阶段划分 项目管理的九大知识领域和五个过程组,PMI PMBOK （2004年版）,成功的产品开发流程所具备的特点,清晰的层次结构可管理 明确的阶段划分可控制 明确的阶段交付可衡量 统一的术语定义易沟通 明确的角色职责易分工 明确的绩效指标易评价,产品开发流程管理所面临的挑战,对流程的认识和固有的工作习惯 各类流程形同虚设，对流程没有信心 没有建立与流程相匹配的组织,流程是一种用来取代旧模式，年复一年地指导公司活动的方法，他不是特殊的，也不是暂时性的，更不是用来应付一阵子然后就抛弃的东西。 Thomas H .Berry 整体质量变化的管理,演练与问题讨论,各小组讨论公司产品开发流程方面存在的主要问题，总结57条，选派一名代表分享讨论成果。,单元三、IPD模式下市场如何驱动研发,市场管理方面存在的主要问题,市场管理参与的角色过于单一，或者没有明确定义 市场需求的收集和分析没有成为一个例行的活动 市场需求仅侧重功能，忽视了性能、可靠性等 市场需求变化太多，导致项目反复改变方向和成本昂贵的返工 被动响应市场需求，抑制了产品平台的创建,市场管理流程与产品开发流程之间的关系,进入产品开发流程管道,产品市场管理流程的几个阶段,正确的理解市场（如何寻找潜在的机会和目标） 进行市场细分（定义初步的细分目标市场） 产品组合分析（竞争环境、投资机会等的分析） 制定业务计划（整个产品线或产品系列的业务计划） 管道管理及资源平衡（排定项目优先级）,如何正确的理解市场,环境分析（PEST法） 市场分析 （市场、客户、销售渠道和网络） 竞争分析（波特的竞争力模型） 对公司自身的分析（SWOT分析、优先级排序）,市场细分的三大原因,市场需求差异程度越来越大 企业资源相对有限 竞争越来越激烈 只有在完全了解环境和准确的市场细分的基础上，企业才能最大限度地发挥资源优势，降低经营风险，使经营目标建立在比较可靠的基础上。,如何进行市场细分,如何细分市场：八种细分市场的类型,什么地方什么时间 如何使用,产品/服务使用场合,地理位置,人口特征,使用行为,利润潜力,价值观/生活方式,需求/动机/购买因素,态度,细分市场的各种类型,针对产品类别和沟通渠道的态度,价格 品牌 服务 质量 功能/设计,一级城市 二级城市 农村,年龄 性别 收入 教育程度,使用量 费用支出 购买渠道 决策过程,收入 获取成本 服务成本,宏观的价值取向和态度,市场细分要注意的问题,市场细分的目的是便于企业集中资源在高利润回报的消费群体，寻找到企业的蓝海 不存在一个“唯一”、“绝对”的细分市场方法 实现一个好的、实用的细分市场需要大量有关行业，消费者/用户，竞争对手，利润/成本方面的信息和数据 目标细分市场要具有内在的吸引力，企业要具有服务于细分市场的竞争优势，二者缺一不可,案例：细分市场简介模板,组合分析,组合分析要回答的问题 当前的业务方案与战略是什么？产品的组合是否能够实现业务战略的需要？ 业务战略哪些地方比较薄弱，哪些地方可以改进？ 我们是否发现利润区？如何获取利润区的利润？ 可以怎样改进当前的业务方案？可替换的新方案有哪些？ 客户更喜欢哪种方案？,战略地位分析（SPAN）,案例：总体策略区域SPAN分析,2005年1-10月总投资规模 预测单位：亿元,大区销售 占有率,西北,4 3 2 1,2 4 6 8 10 12 14 16 18 20,潜力市场,维持市场,鸡肋市场,优势市场,巩固市场,产品组合分析的业务定位,2,3,1,不同,多样化,新市场 新销售渠道,相同市场 新销售渠道,新市场相同 销售渠道,相同,相同,当前 生产品类,相似产品,相似技术,新技术,不同,多样化商业计划,新办企业,市 场,产品技术,新业务风险,安索夫矩阵提供了支撑目标的框架,产品路标规划的流程,案例：产品路标规划,产品路标规划的制定,产品路标规划制定的责任中心 产品线管理部门（跨产品开发全流程团队） 产品路标规划制定的周期 根据公司的情况一年24次，不断刷新 路标规划的时间范围 产品路标规划的时间范围通常是最长开发周期时间的23倍,由产品开发团队和产品市场人员制定路标评审材料，报产品线总监，确定产品线责任人 由市场部负责路标规划的人员同产品线路标负责人确定材料的完备性，拟出修改的计划 召集产品开发团队及产品市场人员确定资料编写和修改的责任人及时间 召集部分技术专家，产品开发团队及产品市场人员预审 组织产品管理团队会议，进行产品路标规划评审,产品路标规划的评审步骤,讨论&演练,根据公司当前的产品组合，整理出公司产品的波士顿矩阵，每一小组派一名代表上台发表之！,市场需求管理的流程,收集市场需求的12种方法,收集市场需求的12种方法,直接方法,间接方法,与开发相关的,与支持相关的,其他方法,客户建议团队 公司决策中心 客户简报,研发高层交流 解决方案团队 标杆管理 产品试用,售后服务高层交流 现场支持 服务热线800,各种会议 客户满意度调查,客户需求分析是指从产品的价格、可获得性、包装、性能、易用性、保证性、生命周期成本和社会接受程度八个方面（即$APPEALS）来了解客户对产品的需求，并依此与业界主要对手进行对比分析，确定细分市场的产品需求定位和竞争策略。,不就是与客户吃饭吗？,客户需求的评估方法,价值分析曲线,市场需求分配机制,市场需求,哪条路径,1、针对现有产品开发团队的单产品需求,现有产品开发团队,接纳现有的需求，PCR流程,PL-RMT,C-RMT,2、长期需求,3、跨产品需求,4跨产品线需求,协调跨产品线工作,协调跨产品的工作,纳入市场管理流程，输出产品路标规划,市场需求的分配关系到： 市场管理流程 新产品开发流程（NPD） 涉及到部门或者角色： 产品开发团队 实现现有产品 制定NPD流程 产品线需求管理团队PL-RMT 制定PL的业务计划书 产品路标规划 公司级的需求管理团队C-RMT 管理跨产品线需求,市场需求的执行与验证,客户所想所需,市场 需求,产品包 需求,设计 需求,产品规格书,开发 需求,测试,需求的执行,需求的验证与确认,讨论&演练,根据自己的工作经验和企业的实际，选择一款产品（或者以某款手机为案例），作价值曲线分析，每一小组派一名代表上台发表之！,单元四、IPD的组织与团队,一些公司的做法,未能明确规定组织产品开发项目的方法 虽然能够描述他们的组织方法，却无法调动其小组有效地工作 不断尝试各种各样的组织方法，希望有一天找到能行的通的路,成功的产品开发小组的特征,小组成员间能够十分有效、又非常自如地进行沟通（纵向&横向） 习惯于协调无数个须同时进行的活动 高效的决策（达成共识，主动决策而不愿任由问题发生）,职能型组织结构,项目型组织结构,矩阵型组织结构,不同组织结构类型的特点,外围组,核心组,CHAIRMEN,决策层：公司层面，决定产品/项目投资策略,投资评审团队,外围组,核心组,LEADER,产品管理团队,管理层：管理产品交付,外围组,核心组,产品经理/项目经理,产品开发团队,执行层：执行产品开发管理,业界最佳产品管理团队的层次,产品开发团队中的角色,不是名字，不等于职位 角色，是承担一类相同活动的主体，强调对职责的描述，相同角色的工作性质、类别完全相同，完成工作所需条件也基本一样，如软件工程师就是一个角色 同一个人可能承担多个角色，同一角色可能有多个人来承担,PDT是临时小组 在项目开始时成立 在产品成功发布后解散 PDT成员在概念阶段一起作整个项目的计划 PDT成员在计划阶段一起管理整个项目,PDT：Product（Project） Development Team 产品（项目）开发团队,核心项目小组的构成,Project Team or Core Development Team,Extended Team involving the Functions,Functional Manager,案例：某公司核心项目小组的构成,领导整个项目小组： 建立和领导整个PDT团队 召集PDT核心组，将项目职责分配到PDT核心组成员个人 启动项目和保持项目正常沟通，当无法达成一致时做出决策 与管理层进行沟通： 作出各DCP的日程安排，将业务计划书提交和呈现给公司管理层 从公司管理层获得承诺，并确保所需要的资源的到位 及时向公司管理层提供项目的进展情况,核心项目小组组长LPDT的职责（一）,管理整个项目小组： 确保财务、开发、制造、技术支持、采购、市场行销和销售计划互相耦合 组织制定WBS，并指导各功能部门的核心项目组成员详细制定各功能领域的WBS 制定和维护项目计划，确保根据时间表、预算和规格说明书执行各类活动 进行风险评估和制定风险管理计划 管理和控制整个项目执行过程中的变更,核心项目小组组长LPDT的职责（二）,了解业界相关的技术 了解业务决策的影响 具有沟通价值的能力 具有推行流程的能力,管理整个团队 强大的分析能力 有效的计划技能 能够解决不同业务部门间的分歧 能够建立良好的人际关系,富有想像力，创造性思维 了解公司的愿景和核心业务 从客户的角度考虑问题 具有沟通愿景的能力,幽默感 很强的领导能力 勇于面对变革 很强的计划技能,技术知识,分析和谈判技能,想像力,个人特征,项目经理具备对于引导变革至关重要的特征。,领导意识全球观念创造力,团队建设技能,谈判和沟通,业务知识,领导能力,责任感,技术技能,项目经理的能力模型,2019/11/17,63,可编辑,素质特征： 有管理经验，是一个精明而讲究实际的管理者 有个性魅力，使项目组成员快乐而有生气 有全流程的丰富的工作经验 具有创造性思维 具有灵活性，同时具有组织性和纪律性,项目经理的素质特征,性格特征： 诚实、正直、热情 善于沟 多面手 自信、有进取心,项目经理的性格特征,沉着、冷静、果断 敏感、反应敏捷 精力充沛、坚韧不拔 善解人意,培养项目经理所需要的能力,周边部门锻炼，提高产品全流程意识和技能 通过在项目经理助理等岗位进行培训，获取经验 参加项目经理知识和技能培训 与一些具有你想学习的技能的项目经理进行深入的交流和探讨 自我批评总结，不断学习总结，改正错误,小组的职能专家 解决本职能领域的问题 在设计和项目决策时代表职能部门 共同负责小组的最终结果 对计划、预算、关键问题等的进展情况进行汇报 对功能部门的交付负责 与职能部门沟通的桥梁 向职能部门经理汇报项目情况 应用职能部门的策略、工具和标准 协同外围小组的活动 管理职能部门的项目计划和预算 负责PDT与职能部门间的信息交换 在职能部门内对设计/项目进行评审,核心小组成员的角色及义务,独立完成产品定义、设计、开发和测试等工作 关注于特定的功能性任务，“Just do it” 在特殊情况下，PDT小组可能没有外围小组 非常小的项目职能部门在项目中的工作不多,外围小组成员的角色及义务,提供职能领域的技术领导 定义职能部门的策略、指导原则、工具和标准 建立职能部门的技术发展路标 建立职能部门的技术管理体系 建立优异的职能部门团队 执行职能部门预算 建立专业任职资格标准，雇佣/解雇员工、培训员工及对员工进行绩效考评 领导职能部门的技术项目 支持PDT工作 确定参与项目的人员及资源 参与设计及评审，贡献专业能力,职能部门经理的角色及义务,核心项目小组的方法实现很好的授权,高层管理人员可以就产品作出重大战略决策 核心小组成员则为产品开发制定所有实施决策或战术性的决策。这为公司带来两大益处： 行政领导把时间花在制定战略方向和控制上，而不是在微观上管理下级部门的决策或解决职能部门之间的争执； 大多数与项目有关的决策都是由开发项目关系最密切的核心小组作出的，因为核心小组成员与开发项目朝夕相处，他们掌握了决策的必要信息。,一些公司采用核心项目小组未能成功的原因,职能部门与项目小组的权责划分不清 小组成员的角色和责任不明晰 对跨部门的团队的运作理解不一致 核心项目小组没有得到适当的授权 小组成员没有全心投入到工作中去 与之相关的文化变革没有跟上,项目组织演变的阶段,目前公司产品开发团队的组织形式存在哪些问题？ 在了解业界项目经理的素质模型之后，请结合公司的实际情况，采用画像和拼像的方式讨论公司优秀的项目经理模型 每个小组选派一名代表上台发表之,演练与问题讨论,单元五、IPD的产品开发流程,为了管理好产品开发，产品开发必须成为结构合理、定义清楚的流程 结构合理：自上而下的层次架构中，上层结构简单一些，越到下层越具体 定义清楚：每项工作都应清清楚楚地明确规定出来，所有与产品开发有关的人应该清楚他们所参与的是什么工作，用什么方法去完成,为什么要把产品开发流程结构化,层次结构 阶段（Pocket Card） 步骤（如：软件开发） 任务和活动（如：概要设计、详细设计） 详细的开发指南（指导书、模板、表单、CHECKLIST（经验、主动性、前瞻性）,结构化产品开发的层次,流程体系设计需要结构化、层次化,案例分析:某公司的产品开发流程,流程图中的表示方式,从繁杂、单调的任务中解放出来，将更多的时间花在创造性的增值工作上（如：报告的格式） “结构把人限制住了，太死板，缺乏灵活性” “结构化开发流程在我们这里不会有用的，因为我们从来不重复同样的项目” 没有积累的经验可参考和应学习的榜样，没有标准化并运用于其它项目中（愚蠢的错误）,产品开发流程结构化的几个常见问题,产品开发流程是无结构的（项目组自己定义） 产品开发流程定义得过于详细了（文档准备和批准） 原则和创造力之间的平衡,产品开发流程结构化的两种做法,到什么程度合适？,术语和定义不一致（测试报告） 过多的澄清会议 中层管理人员太多 进度表不准确（所依据的假设不能被分享和了解） 无法估计出资源需求 小组与小组之间的计划不衔接（对必定出现什么情况有不同的理解）,需要进一步结构化的征兆,过量的任务间的相互依赖（低成本工作拖高成本工作的后腿） 对职责理解不够 注意力集中在“救火”上（卷起袖子解决问题） 开发产品没有一个“统一方法” 浪费在没有附加值的工作上的时间（协调、重做）,需要进一步结构化的征兆（续）,它们定义了所有的产品开发活动，但是没有为这些活动定义任何结构 流程结构不当，没能使第一级负责决策，下一级负责计划和进度和任务管理 流程尚未有效实施 流程可能定义得太僵化、太官僚，需要大量的、证明完工的书面材料,为什么有些公司未能成功实施,产品开发流程演变的阶段,案例分析,请按照DesignFlow的流程设计的方法论画出公司的产品开发流程，并找出改进的机会点,单元六、IPD的业务决策与技术评审,研发战略与业务决策管理中存在的典型问题,研发战略不清晰 决策效率低 决策与执行脱节 研发资源不能落实 缺乏有效的决策支持信息,为什么需要阶段决策评审,来源：Winning at New Product,决策的意义 引导产品开发、实施产品战略、授权项目组开发新产品 决策什么 优先级排序和分配开发资源 决策中的问题 缺乏效率、滞后、优柔寡断等 谁的过错 决策的错位,将研发战略和规划落实,高层领导在产品开发中扮演的角色,制定产品发展规划（角色混淆、责任颠倒） 决策（提前参与到产品开发中） 培育产品开发流程（所有项目从中受益） 激励（下班就回家&通宵加班） 聘用最好的开发人员,产品审批委员会（PAC）的权力和责任,提出新产品开发项目 取消或重新制定项目的优先次序 确保进行开发的产品符合公司战略 分配开发资源,业务决策评审,产品开发流程中包括了四个主要的决策评审点 在每个决策评审点上产品开发团队需要要准备特定的材料来为公司产品管理团队提供必要的信息以做出明确的决策：继续、终止或者重新定向,阶段决策评审是保证产品竞争力，提高效率的好办法，但要真正让它发挥作用，必须遵循一定的评审方法论： 1、何时进行评审（商业风险、什么时候该管、无为而治） 2、谁来评审（对资源的控制、保证公司部门优先级一致） 3、评审什么（不要陷入细节） 4、下什么结论（避免会议没有结果或形不成决议、无人下结论或拍板）,决策评审的方法论,管理决策过程演变的阶段,目前的决策机制存在什么问题，有什么改进思路？,演练与讨论,技术评审和子评审,技术评审： 用于检查开发实施到一定阶段以后产品的技术成熟度，发现遗留的技术问题，评估存在的技术风险，给出技术上的操作建议 根据产品的不同一般可设置57个技术评审点 子评审： 产品开发子流程实施过程之中，对输出的工作产品的技术检查、评估和优化的活动 一般由工作产品的责任人召集相关专家实施,优化设计 及时发现设计中欠考虑的方面及其原因 发现错误 使产品项目的选择、问题和错误尽早明朗化，避免下游阶段对前期隐藏的缺陷无法纠正或者被迫耗费巨大的人力、物力和时间才能纠正,技术评审的目的,跟踪需求： 确保在设计中考虑到了所有技术风险，并且在产品包设计中进行了充分考虑以满足规定的产品包需求 质量评估： 评估设计成熟度，在项目关键点上评估产品包开发的状况，为产品项目的决策提供有力的依据 风险规避： 明确设计中存在的风险，根据评审结论可以采取相应的风险规避措施或其它具体行动,技术评审的目的（续）,考虑“好消息”和“坏消息”，并进行详细讨论 关注于发现未得到满足的需求，而不是坚持进度 以合理的速度去花时间阅读材料 不应因为缺少时间和预算而将评审省略,技术评审的原则,要让技术评审发挥作用，必须明确： 何时进行评审时间计划 谁来评审责任人 评审什么（不要陷入细节）重点 下什么结论（避免会议没有结果或形不成决议、无人下结论或拍板）不流于形式,技术评审的方法论,评审计划 （时间、 职责、 交付件 分工）,评审要素表 自检,评审材料 准备 （报告初 稿或会议 胶片）,技术评审 会议,生成 或 优化 评审报告,产品（项 目）经理 审核报告,评审报告 发布,评审结论 执行,技术评审 度量,评审报告 会签,技术评审的一般过程,技术评审材料的准备,评审责任人应按评审计划提前准备评审材料，按时提交评审 文档应套用规定的模板 评审材料需要团队内部预审或检视，避免显而易见的错误提交给评审专家 主审人应加强对评审材料质量的把关，不符合质量要求的评审材料不允许提交评审,技术评审检查要素表,技术评审要素表示例,技术评审要素表的使用,评审前先要把评审材料和评审要素表提前发给各评审专家，给评审专家以足够的时间 主审人可以根据评审专家的专业特点分配不同的评审专家审核不同的评审要素表 主审人要对评审专家提交的结论进行审核，确认专家的评审结果是否有效 评审专家要对评审要素表中的内容做逐一审核，对于违反评审要素的问题，要进行记录和并给出自己的意见,如何召开技术评审会,主审人应控制会议规模，参与人不要太多，适当为好 评审要有重点，避免漫议 评审应主要围绕评审专家提交的预审意见进行，不应直接走读要素表,技术评审报告,技术评审报告示例,SE“技术指导者” PQA“过程主持人” PDT核心组反映部门问题，代表本领域提出专业意见，并代表功能部门承担责任 技术专家贡献个人才智，不承担直接责任 LPDT以业务需要为出发点对技术问题做决策,技术评审中的角色和职责,Go 没有遗留问题和只是一些没有解决风险可以很快解决的问题 Go with risk 遗留问题的解决存在一定风险，但不影响下一步活动的启动 Redirect 遗留问题影响到下一步活动的启动，必须首先解决,技术评审的三个结论,技术评审中各角色的责任,技术评审常见的问题,演练与问题讨论,讨论公司现有的产品开发流程中一级技术评审点有哪些？ 目前技术评审方面存在的主要问题是什么？有何改进思路？,单元七、IPD的实施与优化,管理不在于“知”，而在于“行” 即使再好的方案也存在如何实现的问题 公司管理优化的几个层次如下：,QCC、合理化建议、案例分析学习,变革管理重点在于行,变革对组织的影响,强调跨部门的流程，建立E2E的流程体系 职位的变化（经常会非常显著的发生） 跨越了部门间的障碍 新的企业文化的建立（文化的变革） 新的绩效衡量标准的建立,任何变革都会给个人和组织带来不便和不确定性 对变革和