研发项目管理 IPD流程管理课件

研发项目管理——IPD流程管理研发项目管理——IPD流程管理1引言一个故事：麦当劳和天津狗不理包子的故事。思考：为什么麦当劳全球32000多门店能够保证味道和服务都基本一致？天津狗不理包子在其他地方味道却相差甚远？作为企业应该如何管理才能让创造出可以持续发展的价值？如何从依赖个人英雄到依靠管理制度来推出有竞争力的高质量产品？引言一个故事：麦当劳和天津狗不理包子的故事。2目录IPD简介结构化端到端的流程介绍变更管理产品开发流程各阶段关键活动介绍产品开发模型介绍目录IPD简介3IPD（集成产品开发）的思想来源于美国PRTM公司的PACE理论，在这套理论中详细描述了业界最佳的产品开发模式所包含的各个方面。经过IBM公司的实践，IPD已经成为一套包含企业产品开发的思想、模式、工具的系统工程。IPD强调以市场需求作为产品开发的驱动力，将产品开发作为一项投资来管理。什么是IPD？客户需求、产品规划、Charter开发产品开发上市生命周期IPD（集成产品开发）的思想来源于美国PRTM公司的PACE4IPD的核心目标IPD的目标是实现产品开发的准、快、低准：开发满足细分市场客户需求的产品。快：向市场快速提供成功的产品。低：实现低成本的产品开发以及产品的低成本设计。IPD的核心目标IPD的目标是实现产品开发的准、快、低5IPD能给企业带来什么好处？通过成功实施IPD的要素，能给公司带来典型好处：产品投入市场时间缩短40％～60％；产品开发浪费减少50％～80％；产品开发生产力提高25％～30％；新产品收益（占全部收益的百分比）增加100％（来自国际著名PRTM咨询公司的统计）IPD能给企业带来什么好处？通过成功实施IPD的要素，能给公6IPD的核心思想产品开发是一项投资基于市场的创新(客户需求分析)跨部门的协同结构化开发流程异步开发重用（CBB）跨部门团队结构化流程基于市场的创新优化投资组合异步开发公共基础模块

产品流程重组市场管理产品重组项目和管道管理IPD的核心思想产品开发是一项投资跨部门团队结构化流程基于市7候选项目产品开发团队（PDT）满意的顾客

$$$$生命周期发布验证开发计划概念集成组合管理团队（IPMT）

理解市场市场细分组合分析制定市场细分策略及计划调整&优化业务计划管理市场细分并评估绩效市场信息客户反馈竞争对手信息技术趋势产品组合目的IPD（集成产品开发）是一种管理系统，用于优化成功的产品的开发过程及交付质量。所有利益相关者早期参与的标准化方法规范化的带里程碑的流程项目管理考评关键要素跨部门团队管理 -IPMT执行 -PDT结构化流程6个阶段 4个决策评审点一流的子流程项目管理 系统工程以用户为中心的设计CBB-重用$APPEALS 管道管理标杆比较 技术管理考评平衡记分卡IPD工具共用工具-业务，技术DevMfgMktSvcFinSWFullProcIPD市场管理

IPD框架OR需求管理SP/BP路标CharterPCR候选项目产品开发团队（PDT）满意的顾客生命周期发布验证开发8Page9IPD基本团队

主要使命主要职责主要成员投资评审委员会（IRB）实现长期战略整体投资回报的最大化。管理整体战略与跨产品线的产品和技术投资。主任(公司GM)，产品线、中央研究部、公司Marketing、公司运作及质量管理部、销售、采购、制造、技术支援和财务等部门的主要代表。集成组合管理团队（IPMT）实现产品线的业务组合，使投资回报最大化。管理并使本产品线的产品组合合理化，批准产品线内的投资，执行所选细分市场的策略。主任，产品线研发、产品线Marketing、产品线产品行销、产品线运作管理、采购、制造、技术支援和财务等部门的主要代表。

产品开发团队（PDT）根据最新的市场需求，将产品包推向市场。管理向市场的交付，执行与IPMT签定的合同。PDT经理、市场代表、开发代表、财务代表、采购代表、技术支援代表、制造代表、PQA、POP。三者之间的汇报关系：PDT向IPMT汇报，并从IPMT获得指导与支持；IPMT主任对其IPMT成员进行管理并用PBC的方式考核；各产品线IPMT直接向IRB汇报，并从IRB获得指导与支持，IRB管理并用PBC的方式考核IPMT。

IPD基本团队主要使命主要职责主要成员投资评审委员会（IR重量级团队设置跨部门团队是IPD集成的最佳产品开发要素之一跨部门团队是由市场、开发、制造、采购、财务、用服等来自不同功能部门人员组成的团队。跨部门团队给我们带来：–团队关注于产品，为产品的成功负责；–团队的决策综合考虑各功能部门情况，使决策更全面，减少偏颇–充分利用团队成员的跨领域知识，提高决策质量–团队成员代表各自功能部门，保证沟通渠道的顺畅，“推倒”部门间的“墙”传统功能型组织缺点：1、串行：开发总周期长，易产生鞭子效应。2、部门墙：职责频繁转移、信息层层衰减，易滋生本位主义和厚厚部门墙。重量级团队设置跨部门团队是IPD集成的最佳产品开发要素之一传10目录IPD简介结构化端到端的流程介绍变更管理产品开发流程各阶段关键活动介绍产品开发模型介绍目录IPD简介11结构化开发流程定义为了管理好新产品项目开发，项目开发必须成为结构合理、定义清楚的全流程管理：结构合理：自上而下的层次架构中，上层结构简单一些，越到下层越具体，分为阶段、步骤、任务和活动四个层次三级计划体系定义清楚：每项工作都应清清楚楚地明确规定出来，所有与产品开发有关的人应该清楚他们所参与的是什么工作，用什么方法完成全流程：由起始端到结束端的基于市场需求和客户交付的全流程活动定义：具备四要素：唯一的责任人，明确的输入输出模板与样例，明确的评价要素，以及明确的时间界限结构化开发流程定义为了管理好新产品项目开发，项目开发必须成为12结构化与流程和组织的关系活动阶段步骤任务一级计划一级流程二级计划二级流程三级计划三级流程结构化的设计思想结构化与流程和组织的关系活动阶段步骤任务一级计划13集成产品开发（IPD）结构化流程层次划分第一层次：阶段（一级流程）作用：决策层进行阶段评审和投入，总体把握研发进程第二层次：步骤（二级流程）作用：管理层识别和设置各阶段关键步骤项目概念项目计划研制试产上市销售概念决策评审计划决策评审发布决策评审项目计划技术评审1技术评审2技术评审3技术评审4、5产品包概念产品规格小试中试试验第三、四层次：任务和活动（三级流程）作用：执行层具体完成流程中的活动，是操作说明集成产品开发（IPD）结构化流程层次划分第一层次：阶段（一级14研发项目管理IPD流程管理课件

产品开发项目结构性流程概览需求分析技术评审1概念计划开发验证发布概念决策评审计划决策评审可获得性评审生命周期结束评审决策评审点系统设计概要设计详细设计测试验证发布技术评审2技术评审3技术评审4技术评审5技术评审6技术评审点实施服务项目管理PPT（M）需求变更管理工程项目管理客户关系管理PDT（R）产品开发项目结构性流程概览需求分析技术评审1概念计划开发验16产品结构化开发流程概念计划开发验证发布概念决策评审CDCP计划决策评审PDCP可获得性评审ADCP生命周期结束评审决策评审点生命周期GA最终产品包需求实现和验证产品包需求维护优化产品包交付产品包Charter初始产品包需求Charter评审通过意味着投资方同意立项，以及概念阶段的资源投入CDCP评审通过意味着投资方同意产品计划阶段的资源投入PDCP评审通过意味着投资方同意产品开发验证阶段的资源投入；而产品开发团队需要按照签署的合同要求开发并交付产品包EDCP评审通过意味着产品包达到足够质量要求，投资方同意针对某一特定的机会提前销售该产品包ADCP评审通过意味着投资方同意发布阶段的资源投入，产品可以大批量上市产品结构化开发流程概念计划开发验证发布概念决策评审计划决策评17决策评审点和技术评审点决策评审点DCP：IPD流程分为不同的阶段，通过DCP决策实现投资方和承诺方的互动，资源分批受控投入，既满足项目进展需要，又避免项目投资失控风险。DCP：DecisionCheckPoint投资决策评审点PDT准备，IPMT决策。技术评审点：针对产品包需求的技术评审控制点，确保各阶段任务达到预期要求。评审点关注点责任人参与人DCP商业决策IPMT主任/BMT主任产品线财经管理部部长、产品线质量与成本部部长、产品线产品行销部部长、产品线产品服务部部长、产品线研发管理部部长、产品线采购专家团副主任、产品线供应链产品管理部部长、产品线子产品线总裁等TR产品包成熟度SEPDT相关成员和相关领域专家决策评审点和技术评审点决策评审点DCP：IPD流程分为不同的18DCP运作准备DCP材料PDT检视投资决策委员会预审更新材料PDT经理汇报投资决策委员会作出决策DCP评审DCP评审结果：Go：继续，项目获得批准进入下一个阶段，投资方向项目组提供下一个阶段的资金和资源。NoGo：终止，项目被有序的终止，包括项目归档和关闭工作，然后重新分配资源。Redirect：重新确定方向，投资方指示PDT将项目重新定位到一个具体的方向上，或者搜集更多的信息，然后再重新上会。DCP运作准备DCP材料PDT检视投资决策委员会预审更新材料19为什么要进行TR评审为什么要进行技术评审？技术评审不是测试，评审是一种在产品开发过程中尽早发现缺陷的手段。

根据IBM的一项统计数据显示，产品过程中的缺陷有2/3是在需求和设计阶段引入的。因此通过评审尽早的发现缺陷并修复额成本远远低于在后期测试过程中发现缺陷才进行修复的成本。

测试是产品运行时的动态分析，相对的，评审是一种静态分析，评审的对象是技术文档、测试方案、测试报告等。包含各领域，汇集专家智慧。使各个阶段的活动及质量及时、充分的得到审视及控制。将每一个阶段的事情充分做好。技术评审开展不到位的常见原因：1、没有评审计划，没有进行充分的准备；2、专家选择不合适3、评审会议偏离主题，过多的争论技术问题占用大量时间；4、没有评审检查表作为指导；5、问题修改后跟踪不力；…为什么要进行TR评审为什么要进行技术评审？技术评审开展不到位20

TR关注点TR1TR2TR3TR4TR4ATR5TR6产品需求、产品概念产品级规格概要设计详细设计、BBFV测试结果原型机的质量（SDV）和初始产品的准备情况初始产品质量（SIT）BETA、制造系统验证、认证和标杆测试结果技术评审1概念计划开发验证发布概念决策评审计划决策评审可获得性评审技术评审2技术评审3技术评审4技术评审5技术评审6规格（功能、性能、结构）采购制造资料技术支援可获得性TR4模块、单板级功能完成并进行了调测开发物料采购不能发货TR4A系统级的功能测试完成、少量的性能测试，产品稳定性和可靠性不能保障试制物料到达启动试制，工艺文件初步归档资料开发完成不能发货TR5系统级的功能、性能完成内部测试，但没有进行认证测试和外部测试选定最终供应商，批量物料采购工艺装备完成开发，并部分验证资料测试完成进行可服务性、可安装性的测试，培训完成少量早期发货（BETA和EDCP后）TR关注点TR1TR2TR3TR4TR4ATR5TR6产品21TR运作各领域沟通预审更新材料PDT正式评审会议开发团队根据评审要素表进行自检拟制TR评审报告材料会签发布TR评审TR评审结果：Go：达到评审要求通过；GoWithRisk：带风险通过，基本达到评审要求；仍存在风险，但风险可控。Redirect：未达到评审要求，需要项目重新做补充工作，再做TR评审。项目团队可以根据项目大小等开展SUB-TR活动技术评审裁剪原则：技术评审的裁剪不能损害质量目标的达成；确定裁剪时，需获得受影响的相关部门的认同；技术评审的裁剪应与流程、活动的裁剪相匹配；评审要素的裁剪必须经过PQA确认才能生效；TR入口检查OKTR运作各领域沟通预审更新材料PDT正式评审会议开发团队根据22目录IPD简介结构化端到端的流程介绍变更管理产品开发流程各阶段关键活动介绍产品开发模型介绍目录IPD简介23新产品开发和老产品优化的关系——ABC类变更新产品开发和老产品优化的关系——ABC类变更24ABC类变更定义A类变更：产品（项目）的主要需求发生重大变化，或者产品（项目）定位的细分客户群发生变化；并且当前产品（项目）开发无法支撑此类变化的变更。例如：产品（项目）的主要需求发生了重大变化；例如需求由原来的解决口渴的问题，变为解决肚子饿的问题。产品（项目）定位的客户群发生了改变；例如由原来的面向低端客户的低端产品，变为面向高端客户的高端产品。 此类变更相当于一个新产品（项目）的开发，需要通过研发与市场委员会（或产品部）决策评审，需要重新立项并成立PDT团队进行产品开发（定制项目）流程。B类变更：产品（项目）的需求发生变化，不能在当前概要设计下实现这部分需求；但在当前产品（项目）的系统平台下是可以实现的。例如：在当前产品的基础上添加了基于此技术平台的新功能模块；在当前产品的基础上某个模块的需求发生变更，此模块变更需要重新进行概要设计；影响到关键路径二级计划的设计变更；没有成熟的共享模块基础的变更； 此类变更一般会影响到一级计划的变更，在明确需求的前提下需要从计划阶段开始重新往下走；需要重新进行系统设计和概要设计，并修订一级计划；此类变更也需要通过上级部门严格审批，并将修改后的一级计划上报计划部；此类变更的审批与此项目原来审批一致；C类变更：产品（项目）开发过程中不会涉及到概要设计变化的变更；此类变更不会影响要关键路径的二级计划的变更。例如：不会影响到关键路径二级计划的设计变更；非关键元器件的变更；成熟货架模块替换的变更； 此类变更不会对一级计划产生影响，此类变更一般要从开发阶段切入，重新进行详细设计。此类变更经过产品经理审批即可。ABC类变更定义A类变更：产品（项目）的主要需求发生重大变化25需求变更管理1、PCR:计划决策评审之后，如果承诺的变化超出合同规定的范围，则需要提交计划变更请求（PCR）给IPMT/BMT批准。任何影响到计划DCP合同日期（包括客户交付时间），资源或者财务指标的更改均需要IPMT/BMT批准，对于项目范围（需求）的重大更改也是同样如此。2、CCB（ChangeControlBoard）每项变更都需要由项目管理团队或变更控制委员会（CCB）进行管理（接收请求、评审请求、决策）。CCB需要分层设置，在产品开发中存在产品CCB和项目CCB。CCB的一般成员(根据CCB的层级不同人员范围也不同)：CCB最小应该由下面几部分组成：高层经理、技术专家（SE等）、项目经理(技术负责人)、配置管理负责人、质量保证负责人、测试负责人。（可能会有成本管理负责人、客户方代表）变更控制委员会一旦批准项目变更，就要及时传递批准通知书及相关文件，同时，与项目参与各方积极沟通。正式评审通过后的变更结果应再次基线化，确保变更管理的有序。对变更申请进行充分的分析评估，这涉及它对系统性能，接口，可用性，成本，进度，合同的影响程度，还应对它对软件产品的安全性，可靠性，可维护性，可移植性及效率的影响程度的评估。所有变更都需要进行评审；所有对项目计划的变更都必须文档化且受控；变更链上任何一处变更，都需要知会变更链上其他环节。需求变更管理1、PCR:所有变更都需要进行评审；26变更流程提出变更需求\想法结束（变更撤销或以其他方式实现）变更影响分析和方案论证CCB：变更决策发出变更通知、相关文档更改并基线变更实施变更验证变更初审不通过

通过归档基线变更流程变更流程提出变更需求\想法结束（变更撤销或以其他方式实现）变27目录IPD简介结构化端到端的流程介绍变更管理产品开发流程各阶段关键活动介绍产品开发模型介绍目录IPD简介28单元一：IPD总体流程单元二：概念阶段流程(TR1)单元三：计划阶段流程(TR2、TR3)单元四：开发及验证阶段流程(TR4、TR4A、TR5、TR6)单元五：发布阶段流程(GA)单元六：生命周期管理流程第一部分子目录单元一：IPD总体流程第一部分子目录29样例：端到端流程详解样例：端到端流程详解30样例：面向角色对象的二级支持流程样例：面向角色对象的二级支持流程31样例：流程操作指导书，流程管理制度文件样例：流程操作指导书，流程管理制度文件32单元一：IPD总体流程单元二：概念阶段流程(TR1)单元三：计划阶段流程(TR2、TR3)单元四：开发及验证阶段流程(TR4、TR4A、TR5、TR6)单元五：发布阶段流程(GA)单元六：生命周期管理流程第一部分子目录单元一：IPD总体流程第一部分子目录33概念及计划阶段需求分析及计划活动总结产品包需求验证、分析和整理定义产品设计需求定义和评估备选概念概念阶段首先要了解为什么需要这一系统然后确定想做什么然后明确

怎么做产品包需求分解与分配产品规格SRS概要设计实施细节TR1TR2TR3计划阶段需求与分析产品架构与系统设计项目计划制定项目各功能领域概念阶段的详细计划制定初步的整体项目计划制定初步的质量策划方案预估不同方案的费用、人力细化目标成本制定完整的项目计划各领域各层次制定详细计划制定生命周期整体计划分析并定义项目目标成本费用及人力估计与预算概念及计划阶段需求分析及计划活动总结产品包需求验证、分析和整34概念阶段的目标、关注点和交付物目标

对产品机会的总体吸引力及是否符合公司的总体策略做出快速评估。关注分析市场机会，确定备选方案评估是基于有效的假设，而不是详细的数据。若概念得到批准，则在计划阶段将对假设进行证实；若概念没有得到批准，则不浪费资源。交付

初步商业计划端到端概要项目计划，产品开发一级计划初稿

产品包需求、设计需求、产品概念

概念决策评审材料概念概念阶段的目标、关注点和交付物目标对产品机会的总体吸引力35概念阶段主要活动概念阶段主要活动36概念阶段（1）--组建团队概念阶段（1）--组建团队37概念阶段（2）技术层面共同开发产品包需求，进行TR1概念阶段（2）技术层面共同开发产品包需求，进行TR1概念阶段（3）业务层面完成业务计划书，进行CDCP概念阶段（3）业务层面完成业务计划书，进行CDCP39概念阶段重点关注1——资源分配和开工会议强调项目管理与产品开发同绩效管理的结合：每一阶段都要做；但概念阶段可能会涉及到多概念选择的几个小组；如果方案比较明确，也可能直接明确系统工程师要求明确每个项目组成员是强矩阵还是弱矩阵；评估项目组成员的工作量所占比重；确定项目组成员的考核办法，并制定PBC。概念阶段重点关注1——资源分配和开工会议强调项目管理与产品40概念阶段重点关注2——多概念选择及质量计划与监控分析功能需求，然后多个小组选择最接近的一个概念（方案），去评定：分析需求功能；选择多个备选概念：依据以往的经验先选一个初始系统概念，然后再找出现有系统和新系统之间在功能上的差距。解决这些差距可以有不同的方法，包括重新设计或者甚至干脆放弃并替换现有系统的某些部分；初步确定各方案的功能分解，一直要找到可能的技术；根据实际情况，公司经多个系统工程师一起评定（可以根据进度，资源以及方案的研发或更改难度，以及可维护和可安装以及可生产性以及成本等），选择一个概念；确定一个系统级工程师开始产品包的需求说明书或再次进行验证；之后其他系统级工程师进行评审；并确定质量计划的监控重点。概念阶段重点关注2——多概念选择及质量计划与监控分析功能需求41概念选择的分解备选概念的讨论可以自上而下进行也可以自下而上进行，或者两种方式兼而有之。自上而下的设计从系统所要求的全套功能开始，再将它们分为适当的子项，直至为它们各自找到了可能的技术。概念选择的分解备选概念的讨论可以自上而下进行也可以自下而上进42概念阶段重点关注3——TR1评审TR1关注点：重点关注的是产品包需求和设计需求；目标是检查产品需求和设计需求（如制造、市场、可测试性、可服务性方面的需求）；根据评审标准对产品技术进行生命周期、成熟度和风险方面的评估；确认已经对关键器件的成熟度进行评估；评审产品部件可重用计划。交付件责任人产品包需求SE产品设计需求SE产品备选概念SE标准策略SE软硬件共用计划SE包开发主计划RDPDT需求跟踪表单SE评审要素：TR1交付件：TR1入口包需求100%转化为设计需求？DFX落入包需求并经过评审？完成需求跟踪？TR1交付件完成评审且都已经归档基线？TR1入口：概念阶段重点关注3——TR1评审TR1关注点：交付件责任人43概念阶段重点关注4——对新供应商启动认证流程在TR1后如果涉及到新的关键技术或关键器件的外购和外协，可以提前启动新供应商认证；在提前采购决定评审完后，再启动采购。概念阶段重点关注4——对新供应商启动认证流程44概念阶段重点关注5——业务计划书评审重点及监控在目前重点评审项目管理的计划管理与资源配置和风险，市场部分分步加入，但一定要分析竞争和产业链：重点关注进度计划与成本计划；同时，确定各层次的开发，明确要走哪些流程；项目交付完成后或产品交付完成后，完成哪些单机与整机及内部模块的产品化；评审关键路径的关键资源；评审主审人的资源和时间以及任职资格是否匹配；关键路径和关键活动是否高配，如果有高配，是否有监控人；初步的财务指标（可以在计划阶段细化）。概念阶段重点关注5——业务计划书评审重点及监控在目前重点评45单元一：IPD总体流程单元二：概念阶段流程(TR1)单元三：计划阶段流程(TR2、TR3)单元四：开发及验证阶段流程(TR4、TR4A、TR5、TR6)单元五：发布阶段流程(GA)单元六：生命周期管理流程第一部分子目录单元一：IPD总体流程第一部分子目录46计划阶段的目标、关注点和交付物目标

清晰地定义产品及其竞争优势，理解业务计划，制定项目计划及资源计划，确保风险可以被合理地管理。关注

最终的商业计划，这一商业计划定义了产品、市场需求及需要的各个业务部门的支持；评估是基于事实数据（而不是假设），因此若计划得到批准，则团队将与IPMT签订一个合同来完成产品开发；若计划没有得到批准，则不会浪费资源。对概念阶段的假设进行证实。通过与IPMT达成的“合同式”协议，PDT得到授权。在项目每个后续阶段的目标及整个项目的目标上达成共识。交付

最终的商业计划项目合同产品规格说明书端到端详细项目计划和修改的一级计划高层总体方案书（软件概要设计硬件概要设计结构概要设计）计划计划阶段的目标、关注点和交付物目标清晰地定义产品及其竞争优47计划阶段主要活动计划阶段主要活动48计划阶段（1）概念阶段计划阶段扩建PDT团队培训增加扩展组成员并修改项目文档开工会制定计划阶段开始项目执行监控产品包需求分解与分配系统设计与设计规格定义Mini项目准备优化/制定开发计划产品级的测试设计开始Mini项目启动系统规格基线化技术评审2注：mini项目—软件项目/硬件项目（模块）产品由多个软件项目/硬件项目组成计划阶段（1）概念阶段计划阶段扩建PDT团队培训增加扩展组成49开始监控设计规格更改产品概要设计SRS产品数据结构设计测试与验证计划信息开发计划翻译计划订单履行计划物料需求计划……产品概要设计：软件（子系统）概要设计；硬件（子系统）总体方案；单板总体设计方案；结构（子系统）造型总体方案计划阶段（2）SRS基线化更新市场计划参与做提前采购决定技术评审3概要设计基线化制定/优化各业务计划关键和备选供应商谈判拟制合同书PDCP评审更新项目数据库和经验总结计划阶段开发阶段开始监控设计规格更改产品概要设计SRS产品数据结构设计测试与50计划阶段重点关注1——需求分解分配与CBB及标准计划的关系需求分解分配确定是选用成熟模块，还是开发新模块；对选用成熟CBB，直接采用相应的产品标准；对需开发的新模块，在开发过程中要同步制定是否能共享的产品标准（即：新模块开发与验证的流程与产品标准）。计划阶段重点关注1——需求分解分配与CBB及标准计划的关系需51计划阶段重点关注2——需求分解分配与三级计划的接口进行需求分解分配，确定哪些模块要改动，改动的模块制定二级计划；根据二级计划制定三级计划，并修订一级计划；确定二、三级计划的资源配置和关键路径、关键资源；在计划阶段决策评审完成后，确定哪些模块要做提前验证计划；哪些三级计划要先做定型再做渐增测试和验证。计划阶段重点关注2——需求分解分配与三级计划的接口进行需求分52计划阶段重点关注3——计划阶段再次验证市场，寻找并开发新的CBB再次分析外部市场和内部市场需求，包括客户需求、整机单机需求、模块内部需求等各层次需求，寻找各层次新的CBB，分层次进行市场验证在新模块标准计划形成过程中，对能够成为新的CBB模块，要考虑共享方面的开发要求计划阶段重点关注3——计划阶段再次验证市场，寻找并开发新的C53计划阶段重点关注4——提前采购决策如果是成熟模块，长周期采购物资及长周期外协，做出提前采购决策和实施；非成熟模块，要先做技术定型；再做采购决定，否则风险较大。计划阶段重点关注4——提前采购决策如果是成熟模块，长周期采购54计划阶段其他重点关注要素销量预测与承诺要分内部、外部，预测单板、单机、整机、系统的销量；通过预测的销量决定流程要做到小批量，还是批量，还是转产。市场验证验证产品包含：单板、单机、整机和分系统资料开发资料开发以IPD核心内容为主，根据客户的需要可以设立专业工程师，走专业化的道路。计划阶段其他重点关注要素销量预测与承诺55TR2评审TR2关注点：目标是检查系统设计规格。在TR2中评估技术风险；确保已经选用合适的设计方案；检查产品部件的重用度；更新产品功能规格。交付件清单需求分解分配设计规格总体设计方案/产品设计说明书系统架构设计系统配置DFX设计说明书架构评审报告系统级FMEA报告整机系统设计方案接口文档命令行规范目标成本产品测试与验证计划产品开发计划书TR2交付件：TR2评审要素：TR2入口评估：TR2入口：上一阶段遗留问题已解决关闭？设计需求100%转换为设计规格？需求分解分配已完成，各领域参与充分评审？已经就不同功能配置和物理子系统方案进行权衡并且已经选择最佳设计；已经完成子系统之间的接口设计和子系统总体方案设计；本阶段交付件已全部完成评审并归档基线？TR2评审要素：TR2评审TR2关注点：交付件清单需求分解分配设计规格总体设56TR3评审TR3关注点：TR3的目标是对系统配置进行评审，包括硬件、软件、机械、光器件、射频等；在TR2和TR3之间，要求：系统和子系统规格已经分配到各功能模块的总体方案中；模块总体方案中包括系统配置定义；TR3中：各功能领域的专家分析技术风险；对技术规格进行评审，评估技术成熟度；决定方案设计是否已经足够充分，可以进行详细设计；交付件清单产品标准计划需求规格说明书需求SRS分析文档build计划软件接口文档测试与验证计划资料开发计划概要产品功能清单产品主打胶片需求矩阵度量表TR3交付件：TR3评审要素：TR3入口评估：TR3入口：上一阶段遗留问题已解决关闭？SRS已完成评审？概要设计完成评审？本阶段交付件已全部完成评审并归档基线？TR3评审TR3关注点：交付件清单产品标准计划需求规格说明书57概念及计划阶段需求分析及计划活动回顾产品包需求验证、分析和整理定义产品设计需求定义和评估备选概念概念阶段首先要了解为什么需要这一系统然后确定想做什么然后明确

怎么做产品包需求分解与分配产品规格SRS概要设计实施细节TR1TR2TR3计划阶段需求与分析产品架构与系统设计项目计划制定项目各功能领域概念阶段的详细计划制定初步的整体项目计划制定初步的质量策划方案预估不同方案的费用、人力细化目标成本制定完整的项目计划各领域各层次制定详细计划制定生命周期整体计划分析并定义项目目标成本费用及人力估计与预算概念及计划阶段需求分析及计划活动回顾产品包需求验证、分析和整58单元一：IPD总体流程单元二：概念阶段流程(TR1)单元三：计划阶段流程(TR2、TR3)单元四：开发及验证阶段流程(TR4、TR4A、TR5、TR6)单元五：发布阶段流程(GA)单元六：生命周期管理流程第一部分子目录单元一：IPD总体流程第一部分子目录59开发阶段的目标、关注点和交付物目标

设计产品，并将在经过批准的最终业务计划中的特有技术开发、制造及营销策略和计划内容进行集成。

关注

确保产品在市场上成功，评审市场及客户需求，评审产品及财务假设设计和集成满足产品规格的产品；准备和构建产品原型；确保制造准备就绪：明确、处理及减少风险和非确定性因素至可接受的水平；确保产品具有可制造性；准备发布制造过程技术文档；验证计划阶段的假设。交付

可供Beta验证的产品包测试和验证计划详细的产品发布计划

Beta测试/试用客户选择产品文档开发开发阶段的目标、关注点和交付物目标设计产品，并将在经过批60开发阶段主要活动开发阶段主要活动61开发阶段（1）计划阶段开发阶段Mini项目2BBITMini项目1Mini项目3Mini项目4……..测试准备与更新测试计划测试研发准备和开发BBFVUT/MIT/MSTBBFV：BuildingBlockFunctionVerificationBBIT:BuildingBlockIntegratedTest(测试）开发阶段（1）计划阶段开发阶段Mini项目2BBITMini62开发阶段（2）SDV测试（原型机）BUILD1测试转系统测试更新相关测试方案BUILD测试报告BUILDn测试转系统测试更新相关测试方案BUILD测试报告BBFVSDV技术评审4技术评审4A可安装性可服务性测试模块BETA测试预安装模板开发阶段验证阶段初始产品SIT技术评审5开发阶段（2）SDV测试（原型机）BUILD1测试转系统测试63开发阶段活动流图PLSWETCSEQA详细设计单元测试用例参与评审编码参与检视单元测试系统测试联调参与评审参与评审组织评审参与评审组织评审参与评审参与评审参与评审参与评审组织检视参与检视参与检视CMO文档及代码基线化项目监控PLLLD评审参与检视UT用例评审代码检视阶段结束及TR准备会议开发测试TR3TR4开发阶段活动流图PLSWETCSEQA详细单元测试用例参与评64根据用户需求、系统规格等，分析要进行的测试类型。进行简要的功能交互分析，确定新需求和老需求的兼容性，和其它接口的配合等问题。对各模块内部具体分析，以指导后续的用例设计和开发。与开发对应的测试过程测试方法和技术、环境和工具；测试重用策略；明确转测试通过的标准、预测试安排；明确测试轮次及各轮测试重点；产品测试结束的准则（测试覆盖率的要求等）；需求阶段设计编码单元测试集成测试内部发布测试计划测试需求分析测试设计预测试测试执行测试评估解决问题回归版本开发过程主要活动测试过程主活动项目总结确定测试策略支持开发评审项目计划测试开发概念阶段测试需求分析阶段计划阶段测试设计阶段测试执行阶段测试评估阶段产品包需求测试需求根据用户需求、系统规格等，分析要进行的测试类型。与65TR4评审TR4关注点：TR4的目标是评估子系统原型（如一块单板）是否已经可以进行集成，这项工作在SDV前完成。模块和BBFV的测试结果；确定每个风险的规避计划；确定可重用性；交付件清单软件设计说明书目标程序单元测试用例及报告BBFV测试用例及报告构建指导书代码检视报告测试执行策略试验局方案PCB绘制图PCB加工工艺要求硬件BOM清单研发样机调测报告TR4交付件：TR4评审要素：TR4入口检查项是否达标单元测试、系统测试已完成？系统联调完成，SDV入口满足？系统规格已全部实现？TR4阶段交付件已全部归档？Pclint清零？TR4入口：TR4评审TR4关注点：交付件清单软件设计说明书目标程序单元66（产品级）渐增测试模型BBITSDVSDVTR4TR4.TransfertoTestSDVSDVBBITSDVTR4TR4TR4aBB1BB2SITTR4TR4aSITBetaTestBuildeBuildcBuilddBuildaModule(s)UT/MIT/MSTS/WorH/WDevelopModuleLevelValidation(UT/MIT/MST)BuildingBlockIntegrateTest(BBIT)SystemLevelVerificationBBFVSDVBBFT和SDV是Building的活动对每个Building都要进行BBFV和SDV的活动TR4和TR4A是基于Building的技术评审进行Beta测试和进行初始产品测试（SIT）的Building必须进行TR4A

每个Building进行功能验证（SDV）之前要进行TR4Buildb（产品级）渐增测试模型BBITSDVSDVTR4TR4.Tr67TR4A评审TR4A关注点：原形机的质量SDV结果和初始产品的准备情况TR4A的目标是确定功能需求已经得到满足，性能需求已经基线化；TR4A控制未成熟产品进入样机生产的节奏来确保产品技术已经达到SIT的要求；TR4A主要关注SDV（系统设计验证）测试。SDV通过执行IBTbuild计划来集成系统功能模块直到一个功能完备的原型机完成组合和测试；交付件清单SDV测试报告配置手册TR4A交付件：TR4A入口检查项是否达标SDV测试用例执行率98%以上？SIT入口满足？遗留问题DI值<30？无致命和严重遗留问题。TR4A阶段交付件已全部归档基线？TR4A入口：TR4A评审TR4A关注点：交付件清单SDV测试报告配置手册68验证阶段的目标、关注点和交付物目标

执行为满足产品需求所做的设计更改，刻画产品特点并验证产品，发布最终的工程规格及相关文档。关注

确保产品在市场上成功、审视市场及客户需求、审视产品及财务假设、审视发布计划；确保产品功能方面的信心，形成最终的产品规格，修改设计以满足规格要求（在工作原型中表现出来）；确保制造准备就绪：形成最终的制造过程技术文档；对供应商是否已验证进行确认；验证是否已开发主要制造工艺并且在可接受的范围内发挥作用证实开发阶段的假设。交付

修正的产品规格制造能力及产能计划生产构件（productionbuild）的制造文档合格的产品及最终的产品发布计划验证验证阶段的目标、关注点和交付物目标执行为满足产品需求所做69验证阶段（1）验证阶段（1）70验证阶段（2）开发阶段验证阶段BETA测试SVTBETA测试模板系统认证测试和标杆测试模板制造牵头的压力测试等ADCP评审技术评审6准备产品评估（发布准备评估）更新项目数据库和经验总结验证阶段发布阶段SITSVT验证阶段（2）开发阶段验证阶段BETA测试SVTBETA测试71用户试点（ESP）和Beta测试是不一样的Beta测试的目标是在客户环境中获得对产品特征的早期评估（比如质量、功能、性能、可用性等）。Beta测试通常在验证阶段开始。用户试点的目标是确认产品已经满足GA（量产供货点或一般性可获得点）的条件。关注点是测试、安装、文档、分销渠道以及服务支持，以确保具备GA的条件。如果Beta与试点是一个客户，则最好用户试点（ESP）和Beta测试是不一样的Beta测试的目标72开发与验证阶段重点关注要素验证新单元（单板、单机和新器件）新单元要提前进行验证，完成成熟度评估后，再与系统进行联调开发阶段例会与专题会会议，以及质量、计划、成本及绩效等内控标准要进行内部培训要建立内部项目组成员组成与职责及内控标准规范系统工程师监控和管理需求、规格和配置，并制定企业标准和内控标准PQA监控产品质量目标和计划做好“内部认证/标杆测试”和“外部系统认证测试和标杆测试”定制项目在开发阶段如果经市场验证是产品，除了该项目可以作为第一个ESP外，还要再次确定其他BETA和ESP，可以分层次进行开发与验证阶段重点关注要素验证新单元（单板、单机和新器件）73TR5评审TR5关注点：系统级的功能、性能完成内部测试，但没有进行认证测试和外部测试TR5的目标是确保初次生产产品性能需求已经满足，所有已知的技术问题已经解决。TR5在SIT后进行；在TR5中：评估每个子系统的技术风险；识别潜在技术风险；识别风险发生的可能性及会造成的影响；对每个风险制定规避计划；和支援组一起评估可能的功能资源限制；交付件清单SIT测试报告版本说明书资料测试用例/报告TR5交付件：TR5评审要素：TR5入口检查项是否达标SIT测试用例执行率98%以上？遗留问题DI值<20？无致命和严重遗留问题。TR5阶段交付件已全部归档？TR5入口：TR5评审TR5关注点：交付件清单SIT测试报告版本说明书资74TR6评审TR6关注点：TR6的目标是评估生产级的技术成熟度，并且确认要进入量产阶段的风险。输入准则：SVT已经完成；产品认证和BETA相关的生产设计变更已经完成；可生产性方面已经可以提高产量并进入量产和GA阶段；交付件清单SVT测试报告可靠性测试方案报告版本说明书TR6交付件：TR6入口检查项是否达标SVT测试用例执行率98%以上？遗留问题DI值<10？无致命和严重遗留问题。TR6阶段交付件已全部归档？TR6入口：TR6评审TR6关注点：交付件清单SVT测试报告可靠性测试方75单元一：IPD总体流程单元二：概念阶段流程(TR1)单元三：计划阶段流程(TR2、TR3)单元四：开发及验证阶段流程(TR4、TR4A、TR5、TR6)单元五：发布阶段流程(GA)单元六：生命周期管理流程第一部分子目录单元一：IPD总体流程第一部分子目录76发布阶段的目标、关注点和交付物目标

发布产品并制造足够数量的产品以满足客户在性能、功能、可靠性及成本目标方面的需求。关注

验证制造准备计划；评估市场发布计划并进行必要的修改；准备生命周期管理计划；证实验证阶段的假设确保产品在市场上成功。交付

生命周期管理计划对PDT与IPMT签订的合同进行评估发布发布阶段的目标、关注点和交付物目标发布产品并制造足够数量77发布阶段主要活动发布阶段主要活动78发布阶段重点关注要素做好量产到转产的准备；做好向生产操作切换；做好发布产品包；做好监控供应链；做好销售实施。发布阶段重点关注要素做好量产到转产的准备；79PDT向LMT移交概念设计开发验证发布生命周期PDTLMT产品包交付件、运营绩效目标、营销计划、生命周期计划等各功能领域的移交制造、市场、服务导入PDT向LMT移交概念设计开发验证发布生命周期PDTLMT产80单元一：IPD总体流程单元二：概念阶段流程(TR1)单元三：计划阶段流程(TR2、TR3)单元四：开发及验证阶段流程(TR4、TR4A、TR5、TR6)单元五：发布阶段流程(GA)单元六：生命周期管理流程第一部分子目录单元一：IPD总体流程第一部分子目录81生命周期阶段的目标、关注点和交付物目标

在产品稳定生产到产品生命终结期间内对产品进行管理。关注

管理产品直至产品生命终止，注意收集内部和外部信号，以确定产品过渡/替换，制定产品过渡策略，为客户提供产品工程支持以满足客户需求；证实发布阶段的假设。交付

终止/替换产品生命周期生命周期阶段的目标、关注点和交付物目标在产品稳定生产到产品82生命周期阶段主要活动生命周期阶段主要活动83生命周期管理阶段重点关注要素做好生命周期目标成本管理和损益评估；做好市场营销策略及价格策略；产品包维护和改进；LMT的成立，明确绩效目标，以及PDT考核并解散。生命周期管理阶段重点关注要素做好生命周期目标成本管理和损益评84生命周期管理内容目的：对产品上市后的营销/销售、制造/交付、服务/支持、重用/处置的管理，以提高收入，降低运作成本、保证客户满意度，达到组合绩效最优。三大内容：1、生命周期策略和计划：2、绩效管理：营销和销售绩效；生产绩效；服务/支持绩效。绩效管理进行例行运作，基于生命周期检查表，定期审视，驱动不断改进；建立月度绩效报告机制。3、终止管理:EOMEOPEOS该日起停止接受订单该日起停止生产（含备件），相关生产资源全部释放该日起停止所有服务，关闭有关BOM和数据库，不能查询对外对内EOM确认书EOP确认书EOS确认书EOMDCPEOMADEOPDCPEOSDCPEOPADEOSAD备件停产公告停止销售公告停止服务公告生命周期管理内容目的：对产品上市后的营销/销售、制造/交付、85目录IPD简介结构化端到端的流程介绍变更管理产品开发流程各阶段关键活动介绍产品开发模型介绍目录IPD简介86产品开发V模型产品开发V模型87软件开发模式-瀑布模型软件开发模式-瀑布模型88软件开发模式-迭代模型概念设计开发测试验证发布概念TR规格TR概要TR准入TR验证TR概念设计开发测试验证发布概念设计开发测试验证发布迭代A模型：适用于需求明确，但是开发工作量大的项目迭代B模型：适用于需求不明确或需要多次交付的项目概念设计开发测试验证发布概念TR规格TR概要TR准入TR验证TR迭代一迭代二迭代三迭代四迭代五迭代一迭代二项目总周期概念TR规格TR概要TR准入TR验证TR验证TR准入TR概要TR规格TR概念TR软件开发模式-迭代模型概念设计开发测试验证发布概念TR规格T89迭代模型举例1、快速响应变化，快速支持交付。2、敏捷开发的基础设施：CI持续集成的坏境，自动测试框架、测试用例高度自动化、3、对开发测试人员要求都更高。开发测试融合。4、对需求规格的分解也更高，需要按照可测试的颗粒度来分解。5、版本的计划要求也更高。人员提前到位，依赖关系管理，避免出现迭代未达到质量目标反而成为一团糟的开发模式。迭代模型举例1、快速响应变化，快速支持交付。90敏捷开发模式敏捷开发模式91研发项目管理——IPD流程管理研发项目管理——IPD流程管理92引言一个故事：麦当劳和天津狗不理包子的故事。思考：为什么麦当劳全球32000多门店能够保证味道和服务都基本一致？天津狗不理包子在其他地方味道却相差甚远？作为企业应该如何管理才能让创造出可以持续发展的价值？如何从依赖个人英雄到依靠管理制度来推出有竞争力的高质量产品？引言一个故事：麦当劳和天津狗不理包子的故事。93目录IPD简介结构化端到端的流程介绍变更管理产品开发流程各阶段关键活动介绍产品开发模型介绍目录IPD简介94IPD（集成产品开发）的思想来源于美国PRTM公司的PACE理论，在这套理论中详细描述了业界最佳的产品开发模式所包含的各个方面。经过IBM公司的实践，IPD已经成为一套包含企业产品开发的思想、模式、工具的系统工程。IPD强调以市场需求作为产品开发的驱动力，将产品开发作为一项投资来管理。什么是IPD？客户需求、产品规划、Charter开发产品开发上市生命周期IPD（集成产品开发）的思想来源于美国PRTM公司的PACE95IPD的核心目标IPD的目标是实现产品开发的准、快、低准：开发满足细分市场客户需求的产品。快：向市场快速提供成功的产品。低：实现低成本的产品开发以及产品的低成本设计。IPD的核心目标IPD的目标是实现产品开发的准、快、低96IPD能给企业带来什么好处？通过成功实施IPD的要素，能给公司带来典型好处：产品投入市场时间缩短40％～60％；产品开发浪费减少50％～80％；产品开发生产力提高25％～30％；新产品收益（占全部收益的百分比）增加100％（来自国际著名PRTM咨询公司的统计）IPD能给企业带来什么好处？通过成功实施IPD的要素，能给公97IPD的核心思想产品开发是一项投资基于市场的创新(客户需求分析)跨部门的协同结构化开发流程异步开发重用（CBB）跨部门团队结构化流程基于市场的创新优化投资组合异步开发公共基础模块

产品流程重组市场管理产品重组项目和管道管理IPD的核心思想产品开发是一项投资跨部门团队结构化流程基于市98候选项目产品开发团队（PDT）满意的顾客

$$$$生命周期发布验证开发计划概念集成组合管理团队（IPMT）

理解市场市场细分组合分析制定市场细分策略及计划调整&优化业务计划管理市场细分并评估绩效市场信息客户反馈竞争对手信息技术趋势产品组合目的IPD（集成产品开发）是一种管理系统，用于优化成功的产品的开发过程及交付质量。所有利益相关者早期参与的标准化方法规范化的带里程碑的流程项目管理考评关键要素跨部门团队管理 -IPMT执行 -PDT结构化流程6个阶段 4个决策评审点一流的子流程项目管理 系统工程以用户为中心的设计CBB-重用$APPEALS 管道管理标杆比较 技术管理考评平衡记分卡IPD工具共用工具-业务，技术DevMfgMktSvcFinSWFullProcIPD市场管理

IPD框架OR需求管理SP/BP路标CharterPCR候选项目产品开发团队（PDT）满意的顾客生命周期发布验证开发99Page100IPD基本团队

主要使命主要职责主要成员投资评审委员会（IRB）实现长期战略整体投资回报的最大化。管理整体战略与跨产品线的产品和技术投资。主任(公司GM)，产品线、中央研究部、公司Marketing、公司运作及质量管理部、销售、采购、制造、技术支援和财务等部门的主要代表。集成组合管理团队（IPMT）实现产品线的业务组合，使投资回报最大化。管理并使本产品线的产品组合合理化，批准产品线内的投资，执行所选细分市场的策略。主任，产品线研发、产品线Marketing、产品线产品行销、产品线运作管理、采购、制造、技术支援和财务等部门的主要代表。

产品开发团队（PDT）根据最新的市场需求，将产品包推向市场。管理向市场的交付，执行与IPMT签定的合同。PDT经理、市场代表、开发代表、财务代表、采购代表、技术支援代表、制造代表、PQA、POP。三者之间的汇报关系：PDT向IPMT汇报，并从IPMT获得指导与支持；IPMT主任对其IPMT成员进行管理并用PBC的方式考核；各产品线IPMT直接向IRB汇报，并从IRB获得指导与支持，IRB管理并用PBC的方式考核IPMT。

IPD基本团队主要使命主要职责主要成员投资评审委员会（IR重量级团队设置跨部门团队是IPD集成的最佳产品开发要素之一跨部门团队是由市场、开发、制造、采购、财务、用服等来自不同功能部门人员组成的团队。跨部门团队给我们带来：–团队关注于产品，为产品的成功负责；–团队的决策综合考虑各功能部门情况，使决策更全面，减少偏颇–充分利用团队成员的跨领域知识，提高决策质量–团队成员代表各自功能部门，保证沟通渠道的顺畅，“推倒”部门间的“墙”传统功能型组织缺点：1、串行：开发总周期长，易产生鞭子效应。2、部门墙：职责频繁转移、信息层层衰减，易滋生本位主义和厚厚部门墙。重量级团队设置跨部门团队是IPD集成的最佳产品开发要素之一传101目录IPD简介结构化端到端的流程介绍变更管理产品开发流程各阶段关键活动介绍产品开发模型介绍目录IPD简介102结构化开发流程定义为了管理好新产品项目开发，项目开发必须成为结构合理、定义清楚的全流程管理：结构合理：自上而下的层次架构中，上层结构简单一些，越到下层越具体，分为阶段、步骤、任务和活动四个层次三级计划体系定义清楚：每项工作都应清清楚楚地明确规定出来，所有与产品开发有关的人应该清楚他们所参与的是什么工作，用什么方法完成全流程：由起始端到结束端的基于市场需求和客户交付的全流程活动定义：具备四要素：唯一的责任人，明确的输入输出模板与样例，明确的评价要素，以及明确的时间界限结构化开发流程定义为了管理好新产品项目开发，项目开发必须成为103结构化与流程和组织的关系活动阶段步骤任务一级计划一级流程二级计划二级流程三级计划三级流程结构化的设计思想结构化与流程和组织的关系活动阶段步骤任务一级计划104集成产品开发（IPD）结构化流程层次划分第一层次：阶段（一级流程）作用：决策层进行阶段评审和投入，总体把握研发进程第二层次：步骤（二级流程）作用：管理层识别和设置各阶段关键步骤项目概念项目计划研制试产上市销售概念决策评审计划决策评审发布决策评审项目计划技术评审1技术评审2技术评审3技术评审4、5产品包概念产品规格小试中试试验第三、四层次：任务和活动（三级流程）作用：执行层具体完成流程中的活动，是操作说明集成产品开发（IPD）结构化流程层次划分第一层次：阶段（一级105研发项目管理IPD流程管理课件

产品开发项目结构性流程概览需求分析技术评审1概念计划开发验证发布概念决策评审计划决策评审可获得性评审生命周期结束评审决策评审点系统设计概要设计详细设计测试验证发布技术评审2技术评审3技术评审4技术评审5技术评审6技术评审点实施服务项目管理PPT（M）需求变更管理工程项目管理客户关系管理PDT（R）产品开发项目结构性流程概览需求分析技术评审1概念计划开发验107产品结构化开发流程概念计划开发验证发布概念决策评审CDCP计划决策评审PDCP可获得性评审ADCP生命周期结束评审决策评审点生命周期GA最终产品包需求实现和验证产品包需求维护优化产品包交付产品包Charter初始产品包需求Charter评审通过意味着投资方同意立项，以及概念阶段的资源投入CDCP评审通过意味着投资方同意产品计划阶段的资源投入PDCP评审通过意味着投资方同意产品开发验证阶段的资源投入；而产品开发团队需要按照签署的合同要求开发并交付产品包EDCP评审通过意味着产品包达到足够质量要求，投资方同意针对某一特定的机会提前销售该产品包ADCP评审通过意味着投资方同意发布阶段的资源投入，产品可以大批量上市产品结构化开发流程概念计划开发验证发布概念决策评审计划决策评108决策评审点和技术评审点决策评审点DCP：IPD流程分为不同的阶段，通过DCP决策实现投资方和承诺方的互动，资源分批受控投入，既满足项目进展需要，又避免项目投资失控风险。DCP：DecisionCheckPoint投资决策评审点PDT准备，IPMT决策。技术评审点：针对产品包需求的技术评审控制点，确保各阶段任务达到预期要求。评审点关注点责任人参与人DCP商业决策IPMT主任/BMT主任产品线财经管理部部长、产品线质量与成本部部长、产品线产品行销部部长、产品线产品服务部部长、产品线研发管理部部长、产品线采购专家团副主任、产品线供应链产品管理部部长、产品线子产品线总裁等TR产品包成熟度SEPDT相关成员和相关领域专家决策评审点和技术评审点决策评审点DCP：IPD流程分为不同的109DCP运作准备DCP材料PDT检视投资决策委员会预审更新材料PDT经理汇报投资决策委员会作出决策DCP评审DCP评审结果：Go：继续，项目获得批准进入下一个阶段，投资方向项目组提供下一个阶段的资金和资源。NoGo：终止，项目被有序的终止，包括项目归档和关闭工作，然后重新分配资源。Redirect：重新确定方向，投资方指示PDT将项目重新定位到一个具体的方向上，或者搜集更多的信息，然后再重新上会。DCP运作准备DCP材料PDT检视投资决策委员会预审更新材料110为什么要进行TR评审为什么要进行技术评审？技术评审不是测试，评审是一种在产品开发过程中尽早发现缺陷的手段。

根据IBM的一项统计数据显示，产品过程中的缺陷有2/3是在需求和设计阶段引入的。因此通过评审尽早的发现缺陷并修复额成本远远低于在后期测试过程中发现缺陷才进行修复的成本。

测试是产品运行时的动态分析，相对的，评审是一种静态分析，评审的对象是技术文档、测试方案、测试报告等。包含各领域，汇集专家智慧。使各个阶段的活动及质量及时、充分的得到审视及控制。将每一个阶段的事情充分做好。技术评审开展不到位的常见原因：1、没有评审计划，没有进行充分的准备；2、专家选择不合适3、评审会议偏离主题，过多的争论技术问题占用大量时间；4、没有评审检查表作为指导；5、问题修改后跟踪不力；…为什么要进行TR评审为什么要进行技术评审？技术评审开展不到位111

TR关注点TR1TR2TR3TR4TR4ATR5TR6产品需求、产品概念产品级规格概要设计详细设计、BBFV测试结果原型机的质量（SDV）和初始产品的准备情况初始产品质量（SIT）BETA、制造系统验证、认证和标杆测试结果技术评审1概念计划开发验证发布概念决策评审计划决策评审可获得性评审技术评审2技术评审3技术评审4技术评审5技术评审6规格（功能、性能、结构）采购制造资料技术支援可获得性TR4模块、单板级功能完成并进行了调测开发物料采购不能发货TR4A系统级的功能测试完成、少量的性能测试，产品稳定性和可靠性不能保障试制物料到达启动试制，工艺文件初步归档资料开发完成不能发货TR5系统级的功能、性能完成内部测试，但没有进行认证测试和外部测试选定最终供应商，批量物料采购工艺装备完成开发，并部分验证资料测试完成进行可服务性、可安装性的测试，培训完成少量早期发货（BETA和EDCP后）TR关注点TR1TR2TR3TR4TR4ATR5TR6产品112TR运作各领域沟通预审更新材料PDT正式评审会议开发团队根据评审要素表进行自检拟制TR评审报告材料会签发布TR评审TR评审结果：Go：达到评审要求通过；GoWithRisk：带风险通过，基本达到评审要求；仍存在风险，但风险可控。Redirect：未达到评审要求，需要项目重新做补充工作，再做TR评审。项目团队可以根据项目大小等开展SUB-TR活动技术评审裁剪原则：技术评审的裁剪不能损害质量目标的达成；确定裁剪时，需获得受影响的相关部门的认同；技术评审的裁剪应与流程、活动的裁剪相匹配；评审要素的裁剪必须经过PQA确认才能生效；TR入口检查OKTR运作各领域沟通预审更新材料PDT正式评审会议开发团队根据113目录IPD简介结构化端到端的流程介绍变更管理产品开发流程各阶段关键活动介绍产品开发模型介绍目录IPD简介114新产品开发和老产品优化的关系——ABC类变更新产品开发和老产品优化的关系——ABC类变更115ABC类变更定义A类变更：产品（项目）的主要需求发生重大变化，或者产品（项目）定位的细分客户群发生变化；并且当前产品（项目）开发无法支撑此类变化的变更。例如：产品（项目）的主要需求发生了重大变化；例如需求由原来的解决口渴的问题，变为解决肚子饿的问题。产品（项目）定位的客户群发生了改变；例如由原来的面向低端客户的低端产品，变为面向高端客户的高端产品。 此类变更相当于一个新产品（项目）的开发，需要通过研发与市场委员会（或产品部）决策评审，需要重新立项并成立PDT团队进行产品开发（定制项目）流程。B类变更：产品（项目）的需求发生变化，不能在当前概要设计下实现这部分需求；但在当前产品（项目）的系统平台下是可以实现的。例如：在当前产品的基础上添加了基于此技术平台的新功能模块；在当前产品的基础上某个模块的需求发生变更，此模块变更需要重新进行概要设计；影响到关键路径二级计划的设计变更；没有成熟的共享模块基础的变更； 此类变更一般会影响到一级计划的变更，在明确需求的前提下需要从计划阶段开始重新往下走；需要重新进行系统设计和概要设计，并修订一级计划；此类变更也需要通过上级部门严格审批，并将修改后的一级计划上报计划部；此类变更的审批与此项目原来审批一致；C类变更：产品（项目）开发过程中不会涉及到概要设计变化的变更；此类变更不会影响要关键路径的二级计划的变更。例如：不会影响到关键路径二级计划的设计变更；非关键元器件的变更；成熟货架模块替换的变更； 此类变更不会对一级计划产生影响，此类变更一般要从开发阶段切入，重新进行详细设计。此类变更经过产品经理审批即可。ABC类变更定义A类变更：产品（项目）的主要需求发生重大变化116需求变更管理1、PCR:计划决策评审之后，如果承诺的变化超出合同规定的范围，则需要提交计划变更请求（PCR）给IPMT/BMT批准。任何影响到计划DCP合同日期（包括客户交付时间），资源或者财务指标的更改均需要IPMT/BMT批准，对于项目范围（需求）的重大更改也是同样如此。2、CCB（ChangeControlBoard）每项变更都需要由项目管理团队或变更控制委员会（CCB）进行管理（接收请求、评审请求、决策）。CCB需要分层设置，在产品开发中存在产品CCB和项目CCB。CCB的一般成员(根据CCB的层级不同人员范