聊聊IPD中技术评审那些事（四）实践案例分享（结尾篇）

前面已经和大家详细的介绍了华为IPD体系中7个TR的目的和工作内容，但在很多企业的具体执行中，由于业务模式不同、产品不同，在研发流程中技术评审设置也会不同。在IPD流程下，除了商业决策评审，其他的都是技术评审，仅仅大家熟知的7个技术评审是远远能够满足项目质量管理需要，因此，企业必须结合业务具体情况设置技术评审点，下面就给大家分享一个某企业的具体实践案例。

2004年12月8日，联想收购IBM的PC部门，鉴于二者体量的差距以及IBM在研发管理方面的优势，在并购后的新联想，虽然设置了一定的过渡期，但随着业务的整合，公司开始全面采用IBM IPD体系进行所有研发战略及新产品开发项目的管理，并在2009年邀请PRTM对研发管理体系进行了全面梳理升级，以满足业务发展的需要。新梳理后的评审点设计如上图。

在业务管理层面，设置了项目启动、概念、计划、发布、停止营销及停止服务六个决策点。有从技术管理和项目管理层面设置了多个技术评审点，下面对技术评审点进行详细的介绍。

（一）概念阶段

从技术管理角度设置了一个评审点：CDR（Concept Design & Offering Definition Review 概念设计及产品方案评审），该评审点就是我们前面提到7个TR中的TR1，该评审主要关注需求的完善程度及现有技术对需求的支持情况。该评审也会会被称为DPR1，在评审结束后，根据评审建议修改后的产品方案需求会被作为需求基线提交管理团队进行决策。

（二）计划阶段

从技术管理的角度会安排两个评审：（SDR：System Design Review 系统设计评审）及WMR（Working Mockup Review 功能手板评审）。在这里，SDR基本上对应的是TR3，即从技术角度评估需求的可实现性，为技术承诺做好准备。WMR是研发团队在拿到第一台可点亮的系统安排的评审，主要是从外观和功能实现的角度进行风险评估，并不会去做兼容性、可靠性的评测。

从项目管理层面，还会安排EPR（Execution Plan Review，执行计划评审），每个职能都需要参加评审，检查项目工作准备情况，确保项目团队能够提交一个可实现的、高质量的产品开发计划。SDR（TR3）也可以被看作是EPR的一部分。

因为PC产品架构相对成熟，在其流程中并不会安排正式的系统设计和规格评审（TR2），但一般会在研发团队内部进行沟通讨论，确保技术规格的完整性。除了提到的以上几个评审外，还有一些与产品特点密切相关的评审，如工业设计评审，因为PC产品是个人用品，特别强调外观、交互等方面的体验，所以会从用户体验角度特别安排工业设计评审，确保产品的易用性。

（三）开发阶段

开发阶段是工作任务最密集、技术评审最多的阶段。从技术管理的角度会安排：BBFV/SDV Entry、SDV Exit/SIT Entry、SIT Exit几个评审。其中BBFV是由各专业职能部门主导的、横跨概念、计划、开发三个阶段的工作，在SDV开始前会对各个子系统、模块进行统一的检查，确保各个子系统、模块的状态已满足SDV测试的准入条件，即这些部件已经可以放在同一个系统中进行测试了，该评审对应TR4。SDV Exit/SIT Entry是在SDV测试结果的评审，确认整个产品在技术上的成熟度，评估存在的问题和风险，并要针对问题给出改进计划，确保产品能够从技术上为生产做好准备，该评审对应TR4A。SIT Exit是针对SIT测试结果的评审，这是对产品设计问题、技术成熟度及合规情况的评估活动，确认产品方案的需求已经得到满足，项目活动各个方面（不仅仅是产品）都已经为最终的量产出货做好了准备，该评审对应TR5。

PC产品属于大宗货产品，对供应链的要求很高，所以设置了很多供应链相关的评审。这些评审有：

-SCAR：Supply Chain Assessment Review，供应链评估评审，主要是对供应链准备情况进行早期的评估，并对存在的风险给出应对计划。

-SCRR：Supply Chain Assessment Review，供应链准备评审，对交付成果进行评估，确保供应通道及供应承诺可靠性。

-SCR：Supply Commit Review，供应承诺评审，确认系统级别的供应承诺及库存天数。

-MDRR：Manufacturing Development Readiness Review，制造和开发准备评审，确保开发已经完成；并且制造部门准备接收并制造产品。它是对技术组件、构建模块、子系统或系统平台进入批量生产准备状态的评价，这是一个被特别重视的评审。

（四）验证阶段

从技术管理的角度会安排一个评审：SVT Exit。SVT是系统验证测试，该测试阶段用来验证制造流程，并利用批量部件和订购部件来确保设计的完整性，是对出货水平的产品和生产流程进行的测试。该评审对应TR6。

为了保证产品能够正常生产和前端能够顺利接单，从项目层面还会安排其他评审：

-DSRR：Data & System Readiness Review，数据和系统准备评审，确定端到端流程中数据和IT订单支持系统的准备情况。

-SRR: Software Readiness Review,软件准备评审，在软件发布给工厂之前确认其准备情况。

小结

技术评审/项目评审主要集中在概念、计划、开发、验证几个阶段，本文介绍的仍不够全面，但也应该是超出了大部分人的认知。可能大部分人认知中，项目中的评审就是决策评审和7个TR。但从联想执行的案例可以看到，在项目实际执行中，技术/项目评审点远远超过7个，并且没有特别的强调技术评审重要性，而是强调项目一体化管理，即项目中的任何评审工作都是为了按时保质的向客户提交产品，最终实现让客户满意。项目执行期间的所有技术/项目评审，都是对阶段性工作内容的符合性检查，尽可能的发现阶段性工作中的问题并进行修正，帮助阶段性项目目标的达成，并为商业决策提供依据。所以在技术/项目评审时，我们首先一定要保证评审结果的真实性，其次要通过评审尽可能的发现问题，并制定跟踪计划解决问题，切忌把评审当作关卡来使用，而是要从全局出发、从对项目最有利的角度给出评审结论建议。

案例分享：比如在SVT阶段，如果因为某个部件的良率问题造成生产线直通率不达标，按照标准是不能够正常出货的，质量团队完全可以坚持原则。但从对项目最有利的角度，按时出货肯定是首选项。这时质量团队就需要和研发、工厂沟通，评估问题的严重性、可能的解决方案是什么、方案导入周期多长、对生产线的影响多大等等，在质量团队承担风险的情况下允许挑选出货或者暂时放行，并对出货量或出货时间加以限制，保证质量风险在可控范围内，从而给质量问题的解决预留时间，以保证企业利益的最大化。

企业的业务模式、产品方案特点、管理水平、组织结构、IT系统等都会对技术/项目评审点、评审内容、通过标准等产生影响，所以评审点的设计一定要结合企业的具体情况进行，不能照搬照抄其他企业的实践结果，简单了会影响质量控制效果，复杂了会让团队不堪重负，适合的才是最好的。

附录：聊聊IPD中技术评审那些事（三）错误修正

（三）开发阶段 第二段 第15行，“在SIT测试完成后，需要安排一个技术评审，确定SDV测试结果已经达到预期要求，可以进行SIT测试。”修改为：需要安排一个技术评审，确定SIT测试结果已经达到预期要求，可以进行SVT测试。
（四）验证阶段 最后一行   “TR5，对应系统验证评审”，修改为 “TR6，对应系统验证评审”