集成产品开发IPD培训稿

输入标题,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,124,研发管理系列课程之,RDM001,IPD集成产品开发,课程目录,2. IPD,概述,1,、案例分析,3. IPD,模式下市场如何驱动研发,7.IPD,的优化与实施,4. IPD,的组织与团队,0,、公司及培训课程介绍,5.IPD,的产品开发流程,6.IPD,的业务决策与技术评审,我们对企业核心价值链的理解,课程清单一,类别,序号,课 程 名 称,课时,研发战略管理,RDM001,研发管理总裁班如何打造有竞争力的研发管理体系（,Promoting Innovation,）,1,天,RDM002,技术创新和产品创新管理（,Technology Innovation and Product Innovation,）,2,天,RDM003,创建市场导向的流程型研发组织（,Market-oriented Process Organization of R&D,）,1,天,RDM004,研发变革管理（,Change Management in R&D,）,1,天,RDM005,研发战略管理（,Strategy Management in R&D,）,1,天,课程清单二,类别,序号,课 程 名 称,课时,研发业务管理,RDM010,市场驱动的产品开发流程管理（,Market-Driven NPD Process Management,）,2,天,RDM011,研发项目管理（,R&D Project Management,）,2,天,RDM012,软件项目管理（,Software Project Management,）,2,天,RDM013,研发项目计划与控制（,R&D Project Plan & Control,）,2,天,RDM014,产品需求管理（,Requirements Management,）,2,天,RDM015,产品测试管理（,Testing,）,2,天,RDM016,从样品走向量产（,Piloting,）,2,天,RDM017,研发质量管理（,R&D Quality Management,）,2,天,RDM018,模拟新产品开发管理实战训练（,NPD Simulation,）,3-5,天,RDM019,CMM/CMMI,高级实务（,CMM/CMMI,）,2,天,RDM020,研发项目的组合管理（,Managing Multiple Projects in R&D,）,2,天,RDM021,产品平台与共享模块的建设（,CBB,）,2,天,RDM022,如何提升研发组织的能力（,How to upgrade Process Capability of R&D,）,2,天,RDM023,系统工程在产品开发中的应用（,The Application of System Engineering in NPD,）,2,天,单元一、案例分析,案例分析一,请阅读案例资料，各小组讨论,15,分钟，从流程的角度来分析该公司产品开发过程中存在的问题，总结,5-7,条，各小组选派一名代表分享讨论成果,思考？,从这个失败的产品开发案例的分析中，有哪些原因我们公司也在发生？,单元二、,IPD,概述,产品开发管理的开展历程,摘自?下一代的产品开发?,产品开发是可以管理的,对一个公司开发的所有产品来说，其过程都是相似的,这种相似性使得产品开发流程可以进行标准、定义和管理,产品开发是一个流程建立一个有效的开发机制，为企业新产品的开发提供思路、途径和组织保证,为什么需要产品开发流程,将公司产品开发的成功经验固化在公司,使注意力集中到更具有创造性的产品开发方面,将重复性的任务进行结构化，技术专家就能够把精力集中在真正新的、以前没有作过的工作上,看似简单和清楚的问题并不能够真正做到：,与产品开发相关的人应该清楚他们所参与的是什么工作，应该用什么方式去完成,业界最正确实践的研发管理模式,IPD,的框架,产品开发流程在企业整体运作中的位置,流程体系设计需要结构化、层次化,产品开发流程和工程管理的关系,产品开发的阶段划分,工程管理的九大知识领域和五个过程组,PMI PMBOK 2004年版,启动,计划,监控,执行,收尾,成功的产品开发流程所具备的特点,清晰的层次结构,可管理,明确的阶段划分,可控制,明确的阶段交付,可衡量,统一的术语定义,易沟通,明确的角色职责,易分工,明确的绩效指标,易评价,产品开发流程管理所面临的挑战,对流程的认识和固有的工作习惯,各类流程形同虚设，对流程没有信心,没有建立与流程相匹配的组织,流程是一种用来取代旧模式，年复一年地指导公司活动的方法，他不是特殊的，也不是暂时性的，更不是用来应付一阵子然后就抛弃的东西。,Thomas H .Berry ?整体质量变化的管理?,演练与问题讨论,各小组讨论公司产品开发流程方面存在的主要问题，总结,5,7,条，选派一名代表分享讨论成果。,单元三、,IPD,模式下市场如何驱动研发,市场管理方面存在的主要问题,市场管理参与的角色过于单一，或者没有明确定义,市场需求的收集和分析没有成为一个例行的活动,市场需求仅侧重功能，无视了性能、可靠性等,市场需求变化太多，导致工程反复改变方向和本钱昂贵的返工,被动响应市场需求，抑制了产品平台的创立,市场管理流程与产品开发流程之间的关系,战略规划,市场信息,客户反馈,同行信息,技术趋势,当前产品组合,理解市场,市场细分,组合分析,制定业务策略和计划,调整和优化业务计划,管理业务计划，评估绩效,Y,N,任务书？,进入产品开发流程管道,产品市场管理流程的几个阶段,正确的理解市场如何寻找潜在的时机和目标,进行市场细分定义初步的细分目标市场,产品组合分析竞争环境、投资时机等的分析,制定业务方案整个产品线或产品系列的业务方案,管道管理及资源平衡排定工程优先级,如何正确的理解市场,环境分析PEST法,市场分析 市场、客户、销售渠道和网络,竞争分析波特的竞争力模型,对公司自身的分析SWOT分析、优先级排序,市场细分的三大原因,市场需求差异程度越来越大,企业资源相对有限,竞争越来越剧烈,只有在完全了解环境和准确的市场细分的根底上，企业才能最大限度地发挥资源优势，降低经营风险，使经营目标建立在比较可靠的根底上。,如何进行市场细分,如何细分市场：八种细分市场的类型,什么地方什么时间,如何使用,产品/效劳使用场合,地理位置,人口特征,使用行为,利润潜力,价值观/生活方式,需求/动机/购置因素,态度,细分市场的各种类型,针对产品类别和沟通渠道的态度,价格,品牌,效劳,质量,功能/设计,一级城市,二级城市,农村,年龄,性别,收入,教育程度,使用量,费用支出,购置渠道,决策过程,收入,获取本钱,效劳本钱,宏观的价值取向和态度,市场细分要注意的问题,市场细分的目的是便于企业集中资源在高利润回报的消费群体，寻找到企业的蓝海,不存在一个“唯一、“绝对的细分市场方法,实现一个好的、实用的细分市场需要大量有关行业，消费者/用户，竞争对手，利润/本钱方面的信息和数据,目标细分市场要具有内在的吸引力，企业要具有效劳于细分市场的竞争优势，二者缺一不可,案例：细分市场简介模板,组合分析,组合分析要答复的问题,当前的业务方案与战略是什么？产品的组合是否能够实现业务战略的需要？,业务战略哪些地方比较薄弱，哪些地方可以改进？,我们是否发现利润区？如何获取利润区的利润？,可以怎样改进当前的业务方案？可替换的新方案有哪些？,客户更喜欢哪种方案？,战略地位分析SPAN,案例：总体策略区域,SPAN,分析,2005年1-10月总投资规模 预测单位：亿元,大区销售,占有率,西北,华北,东北,华中,华南,华东,西南,4,3,2,1,2 4 6 8 10 12 14 16 18 20,潜力市场,维持市场,鸡肋市场,优势市场,稳固市场,产品组合分析的业务定位,2,3,1,不同,多样化,新市场,新销售渠道,相同市场,新销售渠道,新市场相同,销售渠道,相同,相同,当前,生产品类,相似产品,相似技术,新技术,不同,多样化商业方案,新办企业,市,场,产品技术,新业务风险,安索夫矩阵提供了支撑目标的框架,产品路标规划的流程,IBM ThinkPad,产品线,92,93,94,95,96,97,98,99,ThinkPad700,ThinkPad700C,ThinkPad750,ThinkPad755,ThinkPad750C,ThinkPad755C,ThinkPad300,ThinkPad380,ThinkPad380D,ThinkPad560,ThinkPad770,ThinkPad500,ThinkPad510C,ThinkPad,755CD/CV,ThinkPad760,ThinkPad570,ThinkPad240,ThinkPad390X,ThinkPad600X,ThinkPad1400,ThinkPad1500,ThinkPad390E,2000,高档家族,中档家族,低档家族,案例：产品路标规划,产品路标规划的制定,产品路标规划制定的责任中心,产品线管理部门跨产品开发全流程团队,产品路标规划制定的周期,根据公司的情况一年24次，不断刷新,路标规划的时间范围,产品路标规划的时间范围通常是最长开发周期时间的23倍,由产品开发团队和产品市场人员制定路标评审材料，报产品线总监，确定产品线责任人,由市场部负责路标规划的人员同产品线路标负责人确定材料的完备性，拟出修改的方案,召集产品开发团队及产品市场人员确定资料编写和修改的责任人及时间,召集局部技术专家，产品开发团队及产品市场人员预审,组织产品管理团队会议，进行产品路标规划评审,产品路标规划的评审步骤,讨论,&,演练,根据公司当前的产品组合，整理出公司产品的波士顿矩阵，,每一小组派一名代表上台发表之！,市场需求管理的流程,需求收集,确定外部来源：,客户,行业分析报告,竞争对手动态,各种展览,专业媒体,技术论坛,确定内部来源：,开发团队,技术规划团队,预研,市场团队,销售团队,整理有价值需求,需求分析,需求分配,需求执行,需求验证,需求过滤：,解释,过滤,检视,需求分析：,分类,排序,证实,需求分配,产品的市场管理,产品路标规划,具体的版本规划,PCR,的分析,决策,需求纳入：,业务计划,/,产品路标规划,项目任务书,PCR,开发需求：,新方案,新产品,加入正在开发的产品,需求的跟踪和变更控制,验证需求,收集市场需求的,12,种方法,收集市场需求的,12,种方法,直接方法,间接方法,与开发相关的,与支持相关的,其他方法,客户建议团队,公司决策中心,客户简报,研发高层交流,解决方案团队,标杆管理,产品试用,售后效劳高层交流,现场支持,效劳热线800,各种会议,客户满意度调查,客户需求分析是指从产品的价格、可获得性、包装、性能、易用性、保证性、生命周期本钱和社会接受程度八个方面即$APPEALS来了解客户对产品的需求，并依此与业界主要对手进行比照分析，确定细分市场的产品需求定位和竞争策略。,Performance,Packaging,Ease of Use,Availability,Life Cycle,Social Acceptance,$ Price,Assurances,不就是与客户吃饭吗？,客户需求的评估方法,价值分析曲线,市场需求分配机制,市场需求,哪条路径,1,、针对现有产品开发团队的单产品需求,现有产品开发团队,接纳现有的需求，,PCR,流程,PL-RMT,C-RMT,2,、长期需求,3,、跨产品需求,4,跨产品线需求,协调跨产品线工作,协调跨产品的工作,纳入市场管理流程，输出产品路标规划,市场需求的分配关系到：,市场管理流程,新产品开发流程NPD,涉及到部门或者角色：,产品开发团队,实现现有产品,制定NPD流程,产品线需求管理团队PL-RMT,制定PL的业务方案书,产品路标规划,公司级的需求管理团队C-RMT,管理跨产品线需求,市场需求的执行与验证,客户所想所需,市场 需求,产品包 需求,设计 需求,产品规格书,开发 需求,测试,需求的执行,需求的验证与确认,讨论,&,演练,根据自己的工作经验和企业的实际，选择一款产品或者以某款 为案例，作价值曲线分析，每一小组派一名代表上台发表之！,单元四、,IPD,的组织与团队,一些公司的做法,未能明确规定组织产品开发工程的方法,虽然能够描述他们的组织方法，却无法调动其小组有效地工作,不断尝试各种各样的组织方法，希望有一天找到能行的通的路,成功的产品开发小组的特征,小组成员间能够十分有效、又非常自如地进行沟通纵向&横向,习惯于协调无数个须同时进行的活动,高效的决策达成共识，主动决策而不愿任由问题发生,公司总裁,人力资源总监,财务总监,市场部总监,工程部总监,制造部总监,采购部总监,客服部经理,内销部经理,进出口部经理,系统工程经理,电子工程经理,软件工程经理,机械工程经理,制造部经理,装配部经理,检测部经理,生产计划经理,生产采购经理,行政采购经理,职能型组织结构,公司总裁,人力资源部总监,财务部总监,项目,A,项目经理,项目,B,项目经理,工程部经理,市场部总监,法律部总监,系统,机械,软件,制造部经理,制造,检测,组装,供应部经理,采购,品保,质检,咨询顾问团队,设计评审,培训,工程部经理,系统,机械,软件,制造部经理,制造,检测,组装,供应部经理,采购,品保,质检,咨询顾问团队,设计评审,培训,工程型组织结构,公司总裁,人力资源部总监,财务部总监,项目总监,软件部经理,研发总监,市场总监,制造总监,技术支持总监,硬件部经理,测试部经理,解决方案经理,产品部经理,装配部经理,检测部经理,生产计划经理,工程部经理,客服部经理,项目,A,客户,项目经理,A,项目,B,客户,项目经理,B,项目,C,客户,项目经理,C,张工,王工,小李,牛工,陈工,吴工,陈工,刘工,周工,陈工,郑工,季工,卢工,钟工,小王,王工,李工,何工,庞工,乔工,周工,王工,苗工,施工,矩阵型组织结构,组织类,型,项目特点,职能型组织,矩阵型组织,项目组织,弱矩阵型,平衡矩阵型,强矩阵型,项目经理的,授权程度,很少或没有,有限,低,中等,中等,-,高,高,-,几乎全权,项目全职人员的百分比,几乎没有,0-25%,15-60%,50-95%,85-100%,项目经理的角色,兼职,兼职,全职,全职,全职,项目经理的名衔,Project Coordinator / Project Leader,Project Coordinator / Project Leader,Project Manager / Project Officer,Project Manager / Program Manager,Project Manager / Program Manager,项目管理行政事务人员,兼职,兼职,兼职,全职,全职,不同组织结构类型的特点,外围组,核心组,CHAIRMEN,决策层：公司层面，决定产品/工程投资策略,投资评审团队,外围组,核心组,LEADER,产品管理团队,管理层：管理产品交付,外围组,核心组,产品经理/工程经理,产品开发团队,执行层：执行产品开发管理,业界最正确产品管理团队的层次,产品开发团队中的角色,不是名字，不等于职位,角色，是承担一类相同活动的主体，强调对职责的描述，相同角色的工作性质、类别完全相同，完成工作所需条件也根本一样，如软件工程师就是一个角色,同一个人可能承担多个角色，同一角色可能有多个人来承担,PDT是临时小组,在工程开始时成立,在产品成功发布后解散,PDT成员在概念阶段一起作整个工程的方案,PDT成员在方案阶段一起管理整个工程,PDT：ProductProject Development Team 产品工程开发团队,核心工程小组的构成,Project Team or Core Development Team,Extended Team involving the Functions,Functional Manager,Sales & Marketing,R & D,Mfg,Quality & Test,Vendors,Materials,(Procurement),PM,Product Planning,Finance,案例：某公司核心工程小组的构成,领导整个工程小组：,建立和领导整个PDT团队,召集PDT核心组，将工程职责分配到PDT核心组成员个人,启开工程和保持工程正常沟通，当无法达成一致时做出决策,与管理层进行沟通：,作出各DCP的日程安排，将业务方案书提交和呈现给公司管理层,从公司管理层获得承诺，并确保所需要的资源的到位,及时向公司管理层提供工程的进展情况,核心工程小组组长LPDT的职责一,管理整个工程小组：,确保财务、开发、制造、技术支持、采购、市场行销和销售方案互相耦合,组织制定WBS，并指导各功能部门的核心工程组成员详细制定各功能领域的WBS,制定和维护工程方案，确保根据时间表、预算和规格说明书执行各类活动,进行风险评估和制定风险管理方案,管理和控制整个工程执行过程中的变更,核心工程小组组长LPDT的职责二,了解业界相关的技术,了解业务决策的影响,具有沟通价值的能力,具有推行流程的能力,管理整个团队,强大的分析能力,有效的方案技能,能够解决不同业务部门间的分歧,能够建立良好的人际关系,富有想像力，创造性思维,了解公司的愿景和核心业务,从客户的角度考虑问题,具有沟通愿景的能力,幽默感,很强的领导能力,勇于面对变革,很强的方案技能,技术知识,分析和谈判技能,想像力,个人特征,工程经理具备对于引导变革至关重要的特征。,领导意识全球观念创造力,团队建设技能,谈判和沟通,业务知识,领导能力,责任感,技术技能,工程经理的能力模型,素质特征：,有管理经验，是一个精明而讲究实际的管理者,有个性魅力，使工程组成员快乐而有生气,有全流程的丰富的工作经验,具有创造性思维,具有灵活性，同时具有组织性和纪律性,工程经理的素质特征,性格特征：,老实、正直、热情,善于沟,多面手,自信、有进取心,工程经理的性格特征,沉着、冷静、果断,敏感、反响敏捷,精力充分、坚韧不拔,善解人意,培养工程经理所需要的能力,周边部门锻炼，提高产品全流程意识和技能,通过在工程经理助理等岗位进行培训，获取经验,参加工程经理知识和技能培训,与一些具有你想学习的技能的工程经理进行深入的交流和探讨,自我批评总结，不断学习总结，改正错误,小组的职能专家,解决本职能领域的问题,在设计和工程决策时代表职能部门,共同负责小组的最终结果,对方案、预算、关键问题等的进展情况进行汇报,对功能部门的交付负责,与职能部门沟通的桥梁,向职能部门经理汇报工程情况,应用职能部门的策略、工具和标准,协同外围小组的活动,管理职能部门的工程方案和预算,负责PDT与职能部门间的信息交换,在职能部门内对设计/工程进行评审,核心小组成员的角色及义务,独立完成产品定义、设计、开发和测试等工作,关注于特定的功能性任务，“Just do it,在特殊情况下，PDT小组可能没有外围小组,非常小的工程职能部门在工程中的工作不多,外围小组成员的角色及义务,提供职能领域的技术领导,定义职能部门的策略、指导原那么、工具和标准,建立职能部门的技术开展路标,建立职能部门的技术管理体系,建立优异的职能部门团队,执行职能部门预算,建立专业任职资格标准，雇佣/解雇员工、培训员工及对员工进行绩效考评,领导职能部门的技术工程,支持PDT工作,确定参与工程的人员及资源,参与设计及评审，奉献专业能力,职能部门经理的角色及义务,核心工程小组的方法实现很好的授权,高层管理人员可以就产品作出重大战略决策,核心小组成员那么为产品开发制定所有实施决策或战术性的决策。这为公司带来两大益处：,行政领导把时间花在制定战略方向和控制上，而不是在微观上管理下级部门的决策或解决职能部门之间的争执；,大多数与工程有关的决策都是由开发工程关系最密切的核心小组作出的，因为核心小组成员与开发工程朝夕相处，他们掌握了决策的必要信息。,一些公司采用核心工程小组未能成功的原因,职能部门与工程小组的权责划分不清,小组成员的角色和责任不明晰,对跨部门的团队的运作理解不一致,核心工程小组没有得到适当的授权,小组成员没有全心投入到工作中去,与之相关的文化变革没有跟上,Phase 1,Phase 2,Phase 3,Phase 4,随意组合,“消防队员”即应急的人员往往比项目经理更受尊重,小组成员变化很大,职能部门之间的矛盾大,领导权易手快或无法确定,类似核心小组模式的小型、跨部门专业小组已经建立,强有力的项目管理,经验丰富的核心小组通常开发多代产品,利用核心小组作为产品开发平台及进行技术开发,工程组织演变的阶段,目前公司产品开发团队的组织形式存在哪些问题？,在了解业界工程经理的素质模型之后，请结合公司的实际情况，采用画像和拼像的方式讨论公司优秀的工程经理模型,每个小组选派一名代表上台发表之,演练与问题讨论,单元五、,IPD,的产品开发流程,为了管理好产品开发，产品开发必须成为结构合理、定义清楚的流程,结构合理：自上而下的层次架构中，上层结构简单一些，越到下层越具体,定义清楚：每项工作都应清清楚楚地明确规定出来，所有与产品开发有关的人应该清楚他们所参与的是什么工作，用什么方法去完成,为什么要把产品开发流程结构化,活动,任务,步骤,阶段,层次结构,阶段Pocket Card,步骤如：软件开发,任务和活动如：概要设计、详细设计,详细的开发指南指导书、模板、表单、CHECKLIST经验、主动性、前瞻性,结构化产品开发的层次,流程体系设计需要结构化、层次化,电脑设计,PWB,Dev.,原型,0,概念评估,1,策划,/,规范,2,开发,3,评估,4,产品发布,概念评估,产品功能描述,产品开,发计划,可靠性,/,环境测试,实地测试,包装设计,机械设计,加工周期,软件设计和开发,生产及测试过程开发,用户服务过程开发,分析,开实验局,批量生产,阶段,4,评审,阶段,3,评审,阶段,2,评审,阶段,1,评审,0,阶段评审,投入市场过程,案例分析:某公司的产品开发流程,流程图中的表示方式,从繁杂、单调的任务中解放出来，将更多的时间花在创造性的增值工作上如：报告的格式,“结构把人限制住了，太死板，缺乏灵活性,“结构化开发流程在我们这里不会有用的，因为我们从来不重复同样的工程,没有积累的经验可参考和应学习的典范，没有标准化并运用于其它工程中愚蠢的错误,产品开发流程结构化的几个常见问题,产品开发流程是无结构的工程组自己定义,产品开发流程定义得过于详细了文档准备和批准,原那么和创造力之间的平衡,产品开发流程结构化的两种做法,到什么程度适宜？,术语和定义不一致测试报告,过多的澄清会议,中层管理人员太多,进度表不准确所依据的假设不能被分享和了解,无法估计出资源需求,小组与小组之间的方案不衔接对必定出现什么情况有不同的理解,需要进一步结构化的征兆,过量的任务间的相互依赖低本钱工作拖高本钱工作的后腿,对职责理解不够,注意力集中在“救火上卷起袖子解决问题,开发产品没有一个“统一方法,浪费在没有附加值的工作上的时间协调、重做,需要进一步结构化的征兆续,它们定义了所有的产品开发活动，但是没有为这些活动定义任何结构,流程结构不当，没能使第一级负责决策，下一级负责方案和进度和任务管理,流程尚未有效实施,流程可能定义得太僵化、太官僚，需要大量的、证明完工的书面材料,为什么有些公司未能成功实施,Phase 1,Phase 2,Phase 3,Phase 4,对能否推出新产品的担忧多于对其它有关开发流程的考虑。,各职能部门的职责明确。,难于协调。,对开发流程的依赖程度相差很大。,开发流程有一定的结构，并有清楚但简单的定义。,是综合各职能部门的简单整体调配过程。,适用于所有项目。,开发流程已植根于企业文化中。,产品开发流程与产品战略和技术过程有效地结合起来。,产品开发流程演变的阶段,案例分析,请按照DesignFlow的流程设计的方法论画出公司的产品开发流程，并找出改进的时机点,单元六、,IPD,的业务决策与技术评审,研发,战略与,业务决策管理中存在的典型问题,研发战略不清晰,决策效率低,决策与执行脱节,研发资源不能落实,缺乏有效的决策支持信息,为什么需要阶段决策评审,100,90,80,70,60,50,40,30,20,10,0,项目时间的百分比,7,6,5,4,3,2,1,观念的数目,筛选和评估,商业分析,开发,测试,商业化,一项成功,的产品,每七个观念中，有一个能获得成功。每四个开,发项目中，只有一个成为商业上的成功者！,来源：?Winning at New Product?,决策的意义,引导产品开发、实施产品战略、授权工程组开发新产品,决策什么,优先级排序和分配开发资源,决策中的问题,缺乏效率、滞后、优柔寡断等,谁的过错,决策的错位,将研发战略和规划落实,高层领导在产品开发中扮演的角色,制定产品开展规划角色混淆、责任颠倒,决策提前参与到产品开发中,培育产品开发流程所有工程从中受益,鼓励下班就回家&通宵加班,聘用最好的开发人员,产品审批委员会PAC的权力和责任,提出新产品开发工程,取消或重新制定工程的优先次序,确保进行开发的产品符合公司战略,分配开发资源,业务决策评审,产品开发流程中包括了四个主要的决策评审点,在每个决策评审点上产品开发团队需要要准备特定的材料来为公司产品管理团队提供必要的信息以做出明确的决策：继续、终止或者重新定向,阶段决策评审是保证产品竞争力，提高效率的好方法，但要真正让它发挥作用，必须遵循一定的评审方法论：,1、何时进行评审商业风险、什么时候该管、无为而治,2、谁来评审对资源的控制、保证公司部门优先级一致,3、评审什么不要陷入细节,4、下什么结论防止会议没有结果或形不成决议、无人下结论或拍板,决策评审的方法论,Phase 1,Phase 2,Phase 3,Phase 4,非正式且非常被动的,管理层注意到什么项目，资源就流向什么项目,通过年预算确定项目的优先等级；,建立了项目进展状况的汇报渠道，但往往很费时。,职能部门管理者确定项目的优先次序时，实际上往往自相矛盾,资源分配困难,跨部门的领导小组（如：,PAC,）依照有效的、以产品开发事件为依据的阶段性审核，确定项目的优先次序,资源的分配与项目的优先顺序保持一致,决策基于已充分开发的产品和技术策略；,项目的优先次序依管道的状况和技能综合计划而定,有关产品平台的决策越来越受重视,管理决策过程演变的阶段,目前的决策机制存在什么问题，有什么改进思路？,演练与讨论,技术评审和子评审,技术评审：,用于检查开发实施到一定阶段以后产品的技术成熟度，发现遗留的技术问题，评估存在的技术风险，给出技术上的操作建议,根据产品的不同一般可设置,5,7,个技术评审点,子评审：,产品开发子流程实施过程之中，对输出的工作产品的技术检查、评估和优化的活动,一般由工作产品的责任人召集相关专家实施,优化设计,及时发现设计中欠考虑的方面及其原因,发现错误,使产品工程的选择、问题和错误尽早明朗化，防止下游阶段对前期隐藏的缺陷无法纠正或者被迫消耗巨大的人力、物力和时间才能纠正,技术评审的目的,跟踪需求：,确保在设计中考虑到了所有技术风险，并且在产品包设计中进行了充分考虑以满足规定的产品包需求,质量评估：,评估设计成熟度，在工程关键点上评估产品包开发的状况，为产品工程的决策提供有力的依据,风险躲避：,明确设计中存在的风险，根据评审结论可以采取相应的风险躲避措施或其它具体行动,技术评审的目的续,考虑“好消息和“坏消息，并进行详细讨论,关注于发现未得到满足的需求，而不是坚持进度,以合理的速度去花时间阅读材料,不应因为缺少时间和预算而将评审省略,技术评审的原那么,要让技术评审发挥作用，必须明确：,何时进行评审时间方案,谁来评审责任人,评审什么不要陷入细节重点,下什么结论防止会议没有结果或形不成决议、无人下结论或拍板不流于形式,技术评审的方法论,评审方案,时间、,职责、,交付件,分工,评审要素表,自检,评审材料,准备,报告初,稿或会议,胶片,技术,评审,会议,生成,或,优化,评审报告,产品项,目经理,审核报告,评审报告,发布,评审结论,执行,技术评审,度量,评审报告,会签,技术评审的一般过程,技术评审材料的准备,评审责任人应按评审方案提前准备评审材料，按时提交评审,文档应套用规定的模板,评审材料需要团队内部预审或检视，防止显而易见的错误提交给评审专家,主审人应加强对评审材料质量的把关，不符合质量要求的评审材料不允许提交评审,技术评审检查要素表,技术评审要素表例如,技术评审要素表的使用,评审前先要把评审材料和评审要素表提前发给各评审专家，给评审专家以足够的时间,主审人可以根据评审专家的专业特点分配不同的评审专家审核不同的评审要素表,主审人要对评审专家提交的结论进行审核，确认专家的评审结果是否有效,评审专家要对评审要素表中的内容做逐一审核，对于违反评审要素的问题，要进行记录和并给出自己的意见,如何召开技术评审会,主审人应控制会议规模，参与人不要太多，适当为好,评审要有重点，防止漫议,评审应主要围绕评审专家提交的预审意见进行，不应直接走读要素表,技术评审报告,技术评审报告例如,SE“技术指导者,PQA“过程主持人,PDT核心组反映部门问题，代表本领域提出专业意见，并代表功能部门承担责任,技术专家奉献个人才智，不承担直接责任,LPDT以业务需要为出发点对技术问题做决策,技术评审中的角色和职责,Go,没有遗留问题和只是一些没有解决风险可以很快解决的问题,Go with risk,遗留问题的解决存在一定风险，但不影响下一步活动的启动,Redirect,遗留问题影响到下一步活动的启动，必须首先解决,技术评审的三个结论,技术评审中各角色的责任,该问题在,TR,报告中是否有准确描述,TR,报告中该问题是否有改进计划,该问题是否被落实到项目计划中,责任人,有,没有,没有,PDTL,有,有,没有,PQA,没有描述或者,有但不准确,任何情况,任何情况,SE,，相应领域,PDT,核心组成员负连带责任,没有，但核心组成员会签时有该方面描述并持保留意见,任何情况,任何情况,SE,技术评审常见的问题,演练与问题讨论,讨论公司现有的产品开发流程中一级技术评审点有哪些？,目前技术评审方面存在的主要问题是什么？有何改进思路？,单元七、,IPD,的实施与优化,管理不在于“知，而在于“行,即使再好的方案也存在如何实现的问题,公司管理优化的几个层次如下：,QCC,、合理化建议、案例分析学习,流程优化,变革,变革管理重点在于行,变革对组织的影响,强调跨部门的流程，建立E2E的流程体系,职位的变化经常会非常显著的发生,跨越了部门间的障碍,新的企业文化的建立文化的变革,新的绩效衡量标准的建立,任何变革都会给个人和组织带来不便和不确定性,对变革和其含义的有限理解,觉察到的对工作平安的威胁,影响力、权威性和控制力的改变,社会地位的丧失,专业技术的损失,需要学习新技能,习惯的改变,低承受力,沟通方式或信息流的改变,变革管理中人的问题,变革期间绩效很可能会下降，对这些下降因素的管理对变革的全面成功非常重要,如何成功实施产品开发管理优化,变革管理过程中短期的业绩下降,产品开发流程变革的阶段划分,第一阶段,第二阶段,第三阶段,“培训松土“,确认产品策略与竞争环境,了解研发流程现状,了解研发工程管理现状,了解研发组织现状,识别潜在的改进时机,确定改进框架,第一阶段的诊断报告,设计未来的研发流程体系包含总流程、子流程、使能流程,设计未来的研发工程管理体系,设计未来的研发组织体系包含研发组织结构、职位体系、 考核与鼓励机制,确定推广实施策略,新体系培训与宣传,选择试点工程试运行,跟踪试点工程，对问题跟踪与记录,不断修正新体系,开始全面推行,现状诊断,体系设计,体系推行和修正,变革管理团队结构,工程指导委员会,改进小组,改进小组,工程经理,提供支持、承诺,提供方向指导,工程重大决策,调度工程的资源,领导核心组工作,控制工程进度和质量,实施、内部宣传,及时安排高层参与阶段报告会议,参与访谈和相关的研讨会,分析问题，设计解决方案，并指导实施,编写文档体系，参与评审,参与评估,客户方高层、,咨询方高层,客户方工程经理、,咨询方工程经理,客户方工程成员、,咨询方参谋团队,交流与沟通贯穿变革始终,各种正式的和非正式的消息、宣传文章、讲解和讨论，伴随和支撑变革全过程,转变大家的观念，接受新方法,给恰当的人提供正确的信息,帮助员工理解并接受变革的好处,鼓励全体员工积极参与,提供对工程进展的修正，确保工程质量,克服企业内部的惰性和疑心主义。,“削足适履 “先僵化、后优化、再固化,充分准备高瞻远瞩&被动实施,规划性战地医院的护士,循序渐进有效、及时的培训,不断的改善,如何成功实施产品开发管理优化,成功实施的关键,管理层为公司的利益作出妥协、经过考验脱颖而出,协调仅发布一个命令是不够的,最高层管理人员愿景、目标、总是能站出来为变革保驾护航，坚信公司是沿着正确的方向前进,如何成功实施产品开发管理优化,高层领导的作用,Q&A,1,、,2,、,3,、,4,、,5,、,课程结束，祝大家事业进步！,谢,