第1章 TF（技术功能）评审SOP

TF（Technical Function，技术功能）评审是硬件产品开发流程中首个正式的技术基线质量闸口，旨在验证产品设计是否满足需求规格、是否具备进入下一阶段（如PCB Layout、模具开发）的条件。本章以SOP形式完整定义TF评审的适用场景、前置条件、操作步骤、跨部门签字流程及Checklist模板。

1.1 适用场景

• 产品阶段：原理图设计完成、PCB Layout启动之前；结构3D图冻结之前。
• 产品类型：包含硬件主控板、电源板、传感模组、射频模组等自研硬件的所有产品。
• 触发条件：硬件系统方案已确认，关键元器件选型已冻结，设计文档完成度为100%。
• 相邻节点：前序节点为“系统方案评审”，后续节点为“PCB Layout评审”或“模具T1评审”。

1.2 前置条件

以下条件必须全部满足，方可发起TF评审：

1. 设计完成度：原理图完成率100%，关键元器件选型BOM已确认；结构3D完成率≥90%。
2. 文档就绪：产品需求文档（PRD）、硬件设计说明书、原理图封装库审核报告、关键器件datasheet齐套。
3. 样机/原型：至少1台工程验证样机（EVT样机）组装完成，可上电测试基本功能。
4. 测试报告：完成核心功能自测，输出《硬件功能自测报告》，通过率≥95%。
5. 人员就位：评审会主席（硬件部负责人）已确认时间，所有签字角色已预约参会。

1.3 操作步骤（含跨部门签字流程）

TF评审按以下5个步骤执行，其中步骤③为跨部门集中评审与签字环节：

步骤③ 跨部门签字流程（详细）

签字顺序为“自检签字 → 审核签字 → 会签 → 批准签字”，不可逆序或缺席：

1. 硬件工程师（自检签字）：确认Checklist自检项全部完成，对设计正确性负责。
2. 硬件部负责人（审核签字）：审核设计规范符合性、资源投入合理性。
3. 测试部负责人（会签）：确认测试方案已覆盖所有功能与性能指标，测试资源已安排。
4. NPI/生产部负责人（会签）：确认可制造性（DFM）初步分析无严重问题，NPI导入计划可执行。
5. 质量部负责人（会签）：确认质量目标（如直通率、DPPM）已分解到设计指标中。
6. 产品经理/系统工程师（批准签字）：最终决策——批准通过、有条件通过或驳回重审。

1.4 输入输出物

1.5 责任边界

1.6 记录材料（含Checklist模板）

TF评审Checklist模板

评审会议纪要模板

以下为会议纪要的标准结构，需在评审会后24h内发出：

项目名称：{项目名称}
评审类型：TF技术功能评审
评审日期：{YYYY-MM-DD}
评审地点：{会议室/线上链接}
参会人员：{姓名-部门，姓名-部门，...}

一、评审结论
[ ] 通过  [ ] 有条件通过  [ ] 不通过

二、遗留问题清单
| 问题描述 | 责任人 | 计划闭环日期 | 状态 |
|---------|-------|------------|------|
| {问题1} | {姓名} | {YYYY-MM-DD} | 待处理 |

三、签字确认
硬件工程师：______  硬件部负责人：______  测试部负责人：______
NPI部负责人：______  质量部负责人：______  产品经理：______

四、附件
1. TF评审Checklist（已签署）
2. 评审问题跟踪单
3. 整改计划表

1.7 异常处理

1.8 验收标准

TF评审通过的验收标准为以下5项全部达成：

1. Checklist全绿：所有检查项结果为“通过”，或“不通过”项已制定整改计划且责任人已确认。
2. 签字完整：6个签字角色（硬件工程师、硬件部负责人、测试部负责人、NPI部负责人、质量部负责人、产品经理）全部签署完成，无遗漏。
3. 问题单闭环：评审产生的遗留问题全部录入《问题跟踪单》，且计划闭环日期不晚于下一阶段评审节点。
4. 结论明确：评审结论为“通过”或“有条件通过”，结论书面通知所有相关部门。
5. 文档归档：评审纪要、Checklist、签字表、问题跟踪单在评审结论发布后2个工作日内归档至项目文件夹。