摘要: 在IPD（集成产品开发，Integrated Product Development）体系中，技术评审（TR，Technical Review） 是确保产品质量、规避技术风险、保障项目成功交付的核心机制。它并非简单的“找茬”会议，而是一套结构化的、分层的、由技术专家主导的质量把关与决策支撑体系。
在产品开发中，最理想的状态是把问题消灭于萌芽之中。实践证明，缺陷发现的越晚，解决的费用就越高，消除一个缺陷的成本，假如在需求分析阶段发现并解决的话要花1块钱，那么在系统测试阶段发现并解决就得花30~70块钱，到上线运行阶段被客户发现后再去解决它可能就要花1000块。这就是IPD技术评审的价值。
在IPD（集成产品开发，Integrated Product Development）体系中，技术评审（TR，Technical Review） 是确保产品质量、规避技术风险、保障项目成功交付的核心机制。它并非简单的“找茬”会议，而是一套结构化的、分层的、由技术专家主导的质量把关与决策支撑体系。
如果说IPD流程中的业务决策评审（DCP，Decision Check Point） 回答的是“做不做、能否继续投钱”的问题，那么技术评审（TR） 回答的就是“做得对不对、技术风险是否可控、质量是否达标”的问题。
01
技术评审的定义及目标
02
技术评审的流程
（二）评审实施阶段
1）开场介绍：评审会议开始时，由评审主持人介绍评审的目的、流程、规则和时间安排，同时介绍评审团队成员和开发团队成员。
2）开发团队汇报：开发团队成员对评审对象进行详细汇报，包括技术方案的设计思路、关键技术的解决方法、设计成果的特点和性能指标等。汇报过程中，应允许评审团队成员随时提问和质疑。
3）评审团队讨论和质疑：评审团队成员根据开发团队的汇报和评审资料，对评审对象进行全面的讨论和质疑。讨论的内容包括技术方案的合理性、可行性、可靠性、可制造性、可维护性等方面，以及存在的问题和潜在的风险。评审团队成员应充分发表自己的意见和建议，形成共识。
4）总结和形成评审意见：评审主持人根据评审团队的讨论和质疑，对评审对象进行总结，明确存在的问题和改进建议。评审意见应包括对评审对象的评价、存在的问题、改进措施和建议、下一步工作计划等。评审意见应经评审团队成员签字确认后生效。
（三）评审后续阶段
1）制定改进计划：开发团队根据评审意见，制定详细的改进计划，明确改进的目标、措施、责任人、时间节点等。改进计划应提交给评审团队和项目管理团队进行审核。
2）跟踪改进进度：项目管理团队负责跟踪开发团队的改进进度，定期检查改进措施的落实情况和改进效果。对于改进过程中出现的问题，应及时协调解决，确保改进计划的顺利实施。
3）重新评审：当开发团队完成改进工作后，应提交重新评审申请。评审团队根据改进情况，决定是否进行重新评审。如果改进效果满足要求，则通过评审；如果仍存在问题，则需要继续改进，直到通过评审为止。
（四）组织与角色：谁来做？
技术评审的成功与否，很大程度上取决于组织架构的清晰度。
1）SE（系统工程师）：作为技术评审的组织者和流程执行者。负责准备评审材料、召集会议、跟踪遗留问题。SE必须保持技术中立，对产品的技术完整性负责。
2）评审专家（通常来自TMT，技术管理团队）：评审的核心决策者。这些专家来自不同领域（硬件、软件、结构、测试、制造、采购等），独立于PDT团队。他们拥有“一票否决权”。
3）PDT经理（产品开发团队经理）：评审的受邀者。虽然PDT经理不直接决定技术评审是否通过，但需要承诺提供资源解决评审中发现的问题。
4）QA（质量保证人员）：负责流程审计。检查TR是否按流程执行，评审标准是否达标，数据是否真实。
03
产品开发各阶段的技术评审
在产品概念阶段，对产品的市场需求、技术可行性、商业可行性等进行评审。评审的内容包括产品的市场定位、目标客户、市场需求分析、技术方案初步设计、成本估算、项目计划等。通过概念阶段评审，确定产品是否值得开发，以及开发的总体方向和目标。
（二）计划阶段评审（TR2-TR3）
在产品计划阶段，对产品的详细开发计划、技术方案、质量计划、成本计划等进行评审。评审的内容包括产品的总体设计方案、关键技术的解决方案、零部件的选型和设计、工艺方案的制定、质量控制计划、成本预算、项目进度计划等。通过计划阶段评审，确保产品开发计划的合理性和可行性，为产品的详细设计和开发提供依据。
（三）开发阶段评审（TR4、TR4A）
在产品开发阶段，对产品的详细设计成果、样品测试结果等进行评审。评审的内容包括产品的零部件设计图纸、装配图纸、技术文件、样品的性能测试报告、可靠性测试报告、环境适应性测试报告等。通过开发阶段评审，及时发现设计和测试中存在的问题，确保产品的设计质量和性能指标满足要求。
（四）验证阶段评审（TR5）
在产品验证阶段，对产品的小批量试生产结果、市场验证结果等进行评审。评审的内容包括产品的生产工艺、生产流程、生产设备、产品的质量稳定性、市场反馈意见等。通过验证阶段评审，确保产品能够满足大规模生产的要求，并且市场接受度良好。
（五）发布阶段评审（TR6）
在产品发布阶段，对产品的发布准备情况进行评审。评审的内容包括产品的技术文档、用户手册、售后服务体系、市场推广计划等。通过发布阶段评审，确保产品能够顺利发布，并且为产品的市场销售和售后服务提供保障。
04
技术评审的关键成功要素
很多企业在实施IPD时，技术评审容易流于形式，变成“走过场”。要避免这种情况，需注意以下几点：
1）建立“质量门”意识：
TR是“不进则退”的硬性关卡。必须设定TR准入准出标准。例如：未通过单元测试不准进入TR4；遗留缺陷未关闭不准进入TR6。如果标准未达标，必须亮红灯（停止）或黄灯（有条件通过），严禁带着重大风险强行通过。
2）专家权威与独立：
评审专家不能是“老好人”。专家必须拥有独立于行政命令的技术决策权。企业应建立技术专家资源池，实行专家轮值或任命制，确保评审的客观性。
3）评审前移，而非集中开会：
评审会议不应成为“读书会”或“问题发现大会”。70%的工作应在评审会前完成：资料必须提前分发，专家应提前审阅并反馈意见。会议只针对争议点、风险点进行讨论和决策。
4）重视跨功能部门（FUNCTIONAL）的参与：
很多研发主导的企业，TR往往只关注功能和性能，而忽略了可制造性（DFM）、可测试性（DFT）、可服务性（DFS）。必须在TR1阶段就将制造、采购、服务的代表纳入核心评审组，确保他们的需求在设计中落地。
5）建立技术评审与业务决策评审的强关联：
没有通过TR3，原则上不能进入计划决策评审（PDCP）；没有通过TR5，原则上不能进入发布决策评审（ADCP）。将技术成熟度作为投资决策的关键依据，能有效避免“虚假繁荣”导致的项目后期崩盘。
05
技术评审常见误区
再特殊的产品，企业都需要投入人力、物力、财力，并且最终交付给客户，不管是内部还是外部客户，而评审的目的是加快进度，降低成本，不管对于哪类项目都是适用的。
2、“我们项目进度太紧张，别做评审了”
进度太紧张，那更应该评审了。想想看是不是有N多的项目，急急忙忙的把单板投出去，或者急急忙忙的发布个版本，结果99.9%都有问题，然后再返工，再打补丁，实际上算起来，多的时间都花了，项目看起来挺热火朝天，但没有有效的结果。
3、“项目成员挺有经验的，无需评审”
这个经验是在哪上面的经验？就算有同类产品的经验，可是我们立项开发项目，一定是和原有产品不同，如果一模一样，那还用立项吗，直接卖老产品不就行了。
4、“评审都是走过场，流于形式，没效果”
这是很多企业心中的痛，我们都知道评审有好处，可是每次评审要么发现不了什么问题，要么叫相关人员，人也不来。为什么评审发现不了问题？需要分析是被评审的材料质量太好了，大家找不到其中的问题；还是被评审的材料质量太烂了，大家懒得说问题；还是评审来的人水平不高，发现不了其中的问题；又或者是评审的人应付了事，走马观花的看评审材料。为什么评审叫人人也不来？需要分析有没有提前告知评审者，约好可行的时间；评审者是不是和项目的利益相关；评审者尽心尽力提了意见，对个人有没有好处；对于评审者提出的问题，作者是否接受和修改并且及时反馈给评审者等等。先进行根因分析，然后再采取应对方法。
5、“后面有测试，因此不需要评审”
我们看一下评审和测试的区别，测试的对象通常为原型、中间产品和最终产品，评审对象比较广泛，通常是技术文档、计划、方案、测试用例、测试数据、测试结果等；就代码来说，评审的覆盖率可以直接达到100%，但是有些代码，测试用例无法全部覆盖，另外测试不会发现代码的可读性和违反编程规范的缺陷，但是评审可以发现这些缺陷；阶段上，在需求、设计等阶段无法开展测试，只能在项目后半段开展测试，项目的成本和风险都变得较高。
也有不少企业的技术评审做了但是没有达到预期的效果，有以下方面的原因：
技术评审是一个体系的概念，不仅仅只一次技术评审会，而是一系列分层次、多角度、跨领域的评审活动。产品通常由系统、子系统、模块、部件组成。我们常说的技术评审TR，是指在系统级的层面上的评审，而且TR评审不仅仅包括研发领域的评审，还包括制造、采购、技术服务等领域的评审，是对产品包成熟度的评审，参与评审的人员主要是项目各领域的代表，保证各领域实现了产品包需求；而子系统和模块级的评审，通常定义为Sub TR，也有的企业称之为交付件评审，如硬件总体设计评审、软件概要设计评审、原理图评审、PCB评审、测试方案评审等项目中基础的交付件的评审，参与评审的人员是技术同行，从技术方面对技术设计提出问题。Sub TR评审是TR评审的基础，先保证各模块、子系统设计的正确性，确保发现的问题都已经解决，再评估整个产品包的技术成熟度。
不少企业把Sub TR和TR混在一起，对评审人员的选择不正确，评审偏离主题和重点，眉毛胡子一把抓，没有建立层次化的技术评审机制，因此评审效果不理想。
正式的评审有4个特点：具有定义好的过程、角色、目标和度量。
过程：上图的7个步骤；
目标：发现并消除缺陷；
度量：对数据的收集和处理有明确的要求；
角色 ：作者、组织者、评审者、记录员、讲解员。
作者主要做三件事：一是收集和提供需要的评审材料，二是需要时提供介绍，三是根据评审意见修改交付件；组织者要组织管理整个评审过程，保证评审效果，组织者很重要，不仅要控制整个评审的进程，还要控制气氛。在评审中，经常会出现大家为了一个问题争论不休，或讨论着就跑题了，预审时评审者没提供预审意见，或者评审会变成人身攻击会，又或者评审会上大家一言不发……这些都需要组织者来处理和掌控；记录员负责在评审会上记录评审者提出的意见、问题和缺陷；讲解员负责在评审会上对要评审的材料进行讲解，帮助评审者更好的理解评审材料；评审者主要做两件事：一是在预审时评审对象，记录评审问题和意见；二是参加评审会议并发表意见。
华为的技术评审在业界来说开展的比较好，华为IPD体系中的技术评审在上述方法论的基础上进行了适配和定制，如下图所示：
华为的TR评审是线上和线下流程相结合的形式，TR预审通过电子流完成，TR评审会是线下正式会议。在华为的TR评审中，有三个关键的因素：
第一是“TR评审要素表”，该要素表是企业产品开发过程中的知识传承和经验积累，包括关键的开发设计准则和开发过程的规范性。有助于各评审专家聚焦于产品包成熟度，避免陷入某个技术细节，提高评审效率。而且TR评审要素表不是一成不变的，需要根据产品类型特点以及市场和客户的需求不断优化，不断积累企业的智力资产。不同的TR评审目标和关注内容不同，通过TR评审要素表来指导评审，避免偏离重点，每个TR点的关注内容如下：
TR1：产品概念和系统需求的完备性
TR2：产品架构设计、系统设计和需求的分解分配
TR3：子系统的概要设计
TR4：产品详细设计和BBIT的结果
TR4A：原型机的质量和初始产品的准备情况
TR5：初始产品的质量
TR6：产品的批量制造能力和发布准备情况
第二是TR在线预审及前期的准备，通常在TR节点前，RQA至少提前两三周会通过邮件把TR评审要素表发给对应的TR评审人，TR评审人即刻对照TR评审要素的要求检查产品的质量状态，项目全员会加班加点、全力以赴地解决所有不满足要求的问题，这样当正式的TR在线预审到来时，所剩的不满足要求的问题已较少，可以保证高效的完成TR预审。
第三是评审人员的选择，一般TR评审人员的选择遵循如下的原则：
· PDT核心代表
· 本次TR评审涉及的PDT扩展组成员
· 本次TR评审涉及的关键技术人员
· 下阶段接收产品的关键技术人员
IPD 技术评审是产品开发过程中不可或缺的重要环节，它对于确保产品开发质量、降低开发风险、提高产品的市场竞争力具有重要意义。企业应充分认识到技术评审的重要性，建立完善的技术评审体系，明确评审标准和流程，组建合适的评审团队，做好充分的评审准备，加强评审过程中的沟通和协作，严格评审后续管理，及时解决评审中出现的问题。
不同的企业有不同的产品、不同的文化和不同的制度，在具体实施技术评审时，需要充分理解技术评审的目的和意义，结合评审的经典方法论，借鉴技术评审的优秀实践，同时匹配企业自身的特点，设计出符合企业实际运作的技术评审机制，使项目组和干系人对项目阶段性交付成果的技术成熟度达成共识，有效提升产品质量，降低成本，帮助企业在快速成长的过程中让成功从偶然变成必然，构筑企业可持续发展的竞争力！
CopyRight ©2018-2022
深圳中天华夏企业管理咨询有限公司
版权所有
粤ICP备12059297号
150 1376 9565
深圳市南山区科兴科学园B3栋
contact@ztchina.com.cn
中天华夏咨询
研发管理在线