产品研发中的技术评审该如何搞？.docxVIP

IPD中对TR的定义

技术评审（TechnicalReview）：是指在IPD体系中，通过召集企业内、外部专家资源，对产品开发过程的技术要素进行的一系列分层次、多角度、跨领域的评审活动，以保证产品开发的过程质量和交付质量

TR的主要作用

需求的跟踪

识别问题并给出解决方案

识别风险并给出风险规避措施

评估质量标准的达标情况

提供产品开发项目管理的决策输入

系统、子系统、模块、部件、接口之间的关系示意图

技术评审体系三层架构（静态）

系统层技术评审：

在系统级的层面上对产品进行把关的评审，是对项目关键路径中各关键交付件的评审

此类交付件涉及了系统层面的需求、方案、设计、测试等方面，是项目中最基础、最关键的交付件

一般包括七大TR评审点，由PQA组织SE负责。评审结果反应产品包的质量

子系统层技术评审：

在各个专业子系统层面上对产品开发的每一个过程结果进行评审，（如电路、软件等子系统的概要设计评审等）。是正式评审点，由项目组组织，对子过程活动输出质量把关

模块层技术评审：

模块层是在子系统层面再往下细分的层次（如电路板上的某个功能模块，软件的详细设计等），为同行设计和问题讨论

技术评审体系运作机制（动态）

TR：产品开发到一定阶段后，由PDT组织的技术评审，用于评估风险，检查计划和目标的达成情况，并且给PDT提出改正意见和建议。

Sub-TR：由IPD子流程的Owner确定，可以是在开发过程中工作产品完成前的检视，在工作产品完成后组织一次集中评审，作为最终交付给PDT前的一次评估和优化（如硬件流程），也可以采用在开发活动进行中实施检视，在工作产品最终交付给PDT前对检视中发现的问题进行回归检查。（如软件流程）

结构化的技术评审体系分层模型

IPD中TR评审过程

TR的三个结论

案例：

TR评审的两种方式

方式一中TR评审各角色的职责

方式二中TR评审各角色的职责

通过TR评审的六道关卡

通过(Go)，没有遗留问题或只是一些可以很快解决的问题；

条件通过（GowithRisk）遗留问题的解决存在一定风险，但不影响下一步活动的启动；

不通过(Redirect)，遗留问题影响到下一步活动的启动，必须首先解决。

TR是基于过去进行评估，DCP是基于未来进行决策，一个看做的怎么样，一个是看说的怎么样

TRG

TRG是指由PDT成员以外的公司各专业领域专家所组成的评审委员资源池虚拟组织，包括公司内部各领域资深人员和公司外部专家委员会成员。

TRG由TRG主任进行统一管理，通过遴选、资格认证、日常工作测评等环节，担当起参与产品开发TR、提供技术建议、建立和维护TR要素表等重要职责

TRG的组织结构与职责

参与产品开发技术评审

提供相关技术建议

建立和维护技术评审要素表

TRG例会制度

每季度由TRG主任组织TRG成员召开TRG工作例会。

对当季度发现的技术问题进行总结讨论，对TR要素表进行优化。

TRG主任对各个TRG成员工作评分进行公示，并对各成员工作表现进行点评，分析并与各成员共同确定改进方向。

TRG主任每季度根据评审工作开展情况，向公司总经理提交评审工作总结报告。

例会制度不适用外部TRG成员。

TR评审工具1--TR汇报材料：

TR评审工具2--评审要素表

1，知识传承与经验总结

评审要素表是企业产品开发过程中核心知识经验的总结和提炼

高频、关键的风险点

关键的开发设计准则

设计过程的规范性

2，提高评审工作效率

提升PDT团队工作效率，通过自检发现问题

有助于各评审专家聚焦于相关技术领域对项目风险进行聚焦

通过结构化的方式，提高评审效率

PDT团队自检

产品开发过程中，PDT团队使用评审要素表对所做的工作进行自评

提升过程交付质量和效率

预审辅助

各领域评审专家根据评审要素表，对项目组提交的评审材料进行预审

在评审会议召开前，预先识别风险项，并进行会前沟通

对问题进行聚焦

评审会议线索

评审过程中，评审要素表将作为关键线索，指引评审过程

对评审结论形成关键支撑

TR评审工具2--评审要素表的维护与更新

TR要素的几个层次

技术评审常见问题举例

没有技术评审计划

专家选择不合适

没有充分的准备

评审过程偏离了主题和重点

评审过程中过多的争执，占用了大量的时间

评审中发现的问题没有得到闭环跟踪

没有严格根据评审要素表的指导

评审要素表更新不及时

预审不充分，未预留充足的预审时间，直接开会

将评审会议搞成解决方案讨论大会

会议开成人身攻击，批斗大会

会议变成科普会