第四章 硬件生命周期阶段识别:T0–T6 阶段划分、关键里程碑与技术成熟度窗口
1. 适用场景
本章适用于产品规划团队、硬件项目经理、系统架构师及研发主管,在以下场景中必须使用 T0–T6 阶段框架进行需求时间节点映射:
- 新产品立项:从概念到量产的全周期里程碑定义
- 客户需求导入:将用户时间节点需求拆解到各硬件阶段
- 技术成熟度评估:判断当前技术方案是否匹配目标时间窗口
- 资源与预算规划:按阶段分配人力、物料及测试资源
- 跨部门对齐:统一研发、测试、生产、供应链对阶段的理解
核心提示:T0–T6 是硬件 Roadmap 与用户需求时间节点映射的“锚点坐标系”,阶段划分的准确性直接影响后续所有排期与交付承诺。
2. 前置条件
进入本章节操作前,团队必须完成以下准备:
- 已完成 产品需求文档(PRD) 初稿,包含关键用户需求及期望交付时间
- 已确认 硬件技术基线(如主芯片、传感器、通信协议选型初选)
- 已组建 阶段评审委员会,明确各阶段决策人
- 已获取 历史项目阶段数据(至少 3 个同类项目各阶段实际耗时)
- 已定义 技术成熟度等级(TRL) 与硬件阶段的对应关系表
3. 操作步骤:T0–T6 阶段识别与里程碑定义
以下步骤指导团队从零建立阶段化硬件生命周期框架:
-
步骤 1:定义 T0(概念与需求定义)
完成 产品概念说明书 和 用户需求清单,确定核心功能指标。
关键里程碑:概念评审通过 → TRL 1–2。 -
步骤 2:定义 T1(系统架构与可行性验证)
输出 系统架构图、技术可行性报告,完成关键器件选型。
关键里程碑:架构评审通过 → TRL 2–3。 -
步骤 3:定义 T2(详细设计与原型开发)
输出 原理图、PCB Layout、结构 3D 文件,制作工程样机。
关键里程碑:原型设计冻结 → TRL 3–4。 -
步骤 4:定义 T3(工程验证测试 — EVT)
完成 EVT 测试报告,覆盖功能、功耗、信号完整性。
关键里程碑:EVT 评审通过 → TRL 4–5。 -
步骤 5:定义 T4(设计验证测试 — DVT)
输出 DVT 报告(含可靠性、EMC、安规),修正设计缺陷。
关键里程碑:DVT 评审通过 → TRL 5–6。 -
步骤 6:定义 T5(生产验证测试 — PVT)
完成 PVT 试产报告、良率分析,确认产线工装与流程。
关键里程碑:PVT 评审通过 → TRL 6–7。 -
步骤 7:定义 T6(量产与生命周期管理)
输出 量产放行书,启动 ramp 爬坡,进入持续工程支持。
关键里程碑:量产放行 → TRL 7–8。
经验窗口参考:消费类硬件 T0→T6 典型总周期为 12–18 个月;工业类 18–30 个月;汽车电子 24–48 个月。技术成熟度每上升一级平均占用 1.5–3 个月。
4. 输入输出物清单
| 阶段 | 主要输入物 | 主要输出物 |
|---|---|---|
| T0 概念 | 市场分析报告、用户需求原始清单 | 产品概念说明书、需求优先级矩阵 |
| T1 架构 | 概念说明书、竞品拆解报告 | 系统架构图、技术可行性报告、器件选型表 |
| T2 原型 | 架构评审纪要、器件 Datasheet | 原理图、PCB Layout、结构 3D、BOM 初步清单 |
| T3 EVT | 原型样机、测试用例 | EVT 测试报告、问题跟踪表 |
| T4 DVT | EVT 问题闭环清单、修订版原理图 | DVT 报告(可靠性/EMC/安规)、设计变更通知 |
| T5 PVT | DVT 放行书、试产工艺文件 | PVT 试产报告、良率分析、产线放行确认 |
| T6 量产 | PVT 放行书、供应链备料计划 | 量产放行书、爬坡计划、ECN 流程激活 |
5. 责任边界
| 角色 | T0–T1 | T2–T3 | T4–T5 | T6 |
|---|---|---|---|---|
| 产品经理 | 主导需求定义 | 参与原型验证 | 确认需求闭环 | 生命周期决策 |
| 硬件架构师 | 主导架构设计 | 评审原理图 | 指导问题攻关 | 技术支持 |
| 硬件工程师 | 参与可行性分析 | 主导设计与调试 | 主导测试与改版 | 持续改进 |
| 测试工程师 | 评审测试策略 | 编制测试用例 | 主导 EVT/DVT/PVT | 监控量产质量 |
| 项目经理 | 制定阶段计划 | 跟踪里程碑 | 推动问题关闭 | 放行决策组织 |
常见责任错位:T3–T4 阶段研发与测试之间的“问题修复责任”未书面约定,导致阶段延期。必须在 T2 结束时签署 阶段责任矩阵。
6. 记录材料
每个阶段必须归档以下 4 类记录:
- 阶段评审纪要:含评审结论、遗留项、负责人、关闭日期
- 技术成熟度评估表:TRL 自评 + 专家复核得分
- 阶段偏差分析:实际耗时 vs 计划耗时,偏差原因及改善措施
- 需求时间节点映射更新:将阶段里程碑更新到 Roadmap 时间轴
示例:阶段评审纪要模板(T3 EVT)
──────────────────────────────
项目名称 :XYZ 智能传感器 V2
阶段 :T3 (EVT)
评审日期 :2025-06-10
评审结论 :有条件通过
遗留项 :#EVT-012 功耗超标 15%,需在 DVT 前优化
责任人/关闭日 :李明 / 2025-06-30
下一阶段计划 :T4 DVT 启动日期 2025-07-05
7. 异常处理
| 异常场景 | 触发条件 | 处理预案 |
|---|---|---|
| 阶段超期 > 20% | 某阶段实际耗时超过计划 1.2 倍 | 启动“阶段压缩冲刺”,裁剪非关键测试项,经变更委员会批准后进入下一阶段 |
| TRL 未达标 | 阶段结束时 TRL 低于目标等级 | 增加“技术成熟度补强 Sprint”,最多延长 2 周,否则降级为概念验证项目 |
| 关键器件交期断裂 | 选型器件交期超出阶段窗口 | 执行 BPL(备选器件列表)切换,同步更新 DVT 测试计划 |
| 用户需求变更冲击阶段 | 需求变更导致已冻结设计需改动 | 触发“需求变更影响评估”,重新计算阶段起点,必要时回退到 T1 重新架构 |
异常决策原则:所有阶段异常必须在 48 小时内完成影响评估并向阶段评审委员会报告,“延期”不能作为默认选项,必须优先考虑范围裁剪或资源增补。
8. 验收标准
本章节内容是否被正确掌握,通过以下 5 项标准 衡量:
- 团队能准确说出 T0–T6 每个阶段的中文名称、英文缩写及核心交付物
- 能在空白模板上画出 T0–T6 时间轴并标注每个阶段的 TRL 区间
- 能根据一个给定的用户需求时间节点,反向推导该需求必须在哪个阶段之前完成定义
- 能识别至少 3 种阶段异常场景并说出对应的处理预案名称
- 能独立完成一份阶段评审纪要(含遗留项、责任人、关闭日期)
自测卡片:如果用户需求要求在“项目启动后第 14 个月”交付量产样机,按照典型消费类周期,T4 DVT 必须在第几个月前完成?
→ 参考答案:第 11–12 个月(预留 2–3 个月给 PVT 和量产放行)。
→ 参考答案:第 11–12 个月(预留 2–3 个月给 PVT 和量产放行)。
T0–T6 阶段划分与技术成熟度对应关系图
本章要点自评清单
| # | 检查项 | 掌握状态 |
|---|---|---|
| 1 | 能默写 T0–T6 各阶段名称与英文缩写 | □ 已掌握 □ 需复习 |
| 2 | 能说出每个阶段的关键里程碑交付物 | □ 已掌握 □ 需复习 |
| 3 | 能对照 TRL 等级判断阶段技术成熟度是否达标 | □ 已掌握 □ 需复习 |
| 4 | 能为一个实际项目绘制 T0–T6 时间轴并标注里程碑 | □ 已掌握 □ 需复习 |
| 5 | 能识别阶段异常并选择正确的处理预案 | □ 已掌握 □ 需复习 |
阶段滥用警告:禁止将 T3/T4/T5 合并为一个“测试大阶段”,这会导致里程碑模糊、技术成熟度无法准确评估。每个阶段必须有独立的评审入口和放行标准。