4. 状态转换原则：转换条件、审批要求、回退机制

适用场景

当IoT原型完成某一阶段里程碑（如硬件BOM锁定、整机功能联调、小批量试产验证），需要将原型状态从当前阶段推进至下一阶段（如从“工程验证”向“设计验证”迁移）；或在测试验证中发现重大不符合项，需要将原型状态回退至前置阶段重新迭代时，启用本章定义的状态转换原则进行操作。

前置条件

• 状态矩阵完成定义：项目组已按照第3章要求，完成本产品所有原型状态（EVT、DVT、PVT、MP等）的完整定义，并通过基线评审。
• 角色与权限已配置：在原型管理平台中已指定各状态的所有者（Owner）、审批人（Approver）、执行人（Executor），且权限与组织架构一致。
• 统一登记册建立：已建立项目级或产品级《原型状态登记册》，支持状态变更记录与追踪。

操作步骤

1. 触发转换请求：由当前状态负责人（如硬件开发Lead）根据任务实际完成情况，在原型管理系统中发起“状态转换申请”，填写目标状态及转换理由。
2. 条件自检与审查：申请人对照《状态转换条件检查矩阵》逐项自检，并上传证明材料（如测试报告、BOM清单、评审纪要）。系统或专职QA审计条件满足度。
3. 审批流转与会签：根据目标状态等级，推送至对应审批链（如从EVT→DVT需产品经理+技术负责人+质量经理三方会签）。审批人对照转换条件进行批复。
4. 执行转换或触发回退：审批通过，由配置管理员执行状态变更操作，锁定当前基线并创建新基线。审批驳回或审计不通过，自动进入回退流程。
5. 记录归档与广播：状态转换完成后，登记册自动记录转换人、时间、结果及审批意见，并通过邮件或即时通讯工具向项目组全员广播。

输入输出物

责任边界

以下通过简化的RACI矩阵明确各角色在状态转换过程中的责任边界：

记录材料

• 《原型状态转换日志》：记录每一次状态变更的流水，包括申请号、申请人、转换路径、审批链、执行结果、回退标记。
• 《转换条件检查矩阵（含签章）》：作为附件与对应转换日志关联，保存至项目文档库，至少保留至产品EOL后12个月。
• 《审批记录表》：包含每位审批人的批复意见、签章、时间戳，不可篡改。

异常处理

1. 异常1：条件不满足仍强行申请。
   处理流程：QA审计发现条件不满足或证据缺失，直接拒绝申请并打回至当前状态。系统自动向申请人及其主管发送《条件不满足通知》，限期（如3个工作日）整改后重新提交。
2. 异常2：审批超时。
   处理流程：审批任务超过约定的审批节点SLA（如24小时）未完成，系统自动将审批任务升级至审批人的上级主管，并抄送项目总监。同时在项目群组中广播“审批超时预警”。
3. 异常3：阶段内发现严重缺陷需立即回退。
   处理流程：启动紧急回退预案。由发现人发起《紧急回退申请》，技术负责人和产品经理在2小时内完成联合审批。审批通过后，配置管理员执行状态回滚，变更基线上锁，并通知所有依赖方暂停该原型相关活动。

验收标准

• 可追溯性：所有状态转换（包括正常转换和回退）均在《原型状态登记册》中留有可读的时间戳和责任人记录，不可删除或覆盖。
• 防绕过：系统流程禁止越级转换（如从EVT直接跳至PVT），禁止在条件检查未通过状态下完成状态变更操作。
• 回退时效：紧急回退从申请发起到状态冻结完成，总耗时不得超过2小时；普通回退不超过8小时。
• 闭环率：每月度或里程碑节点统计状态转换闭环率（完成审批并执行变更的申请数 / 总发起申请数），目标值 ≥ 95%。