项目评审
电控软硬件项目评审
本文档整合自项目评审旁听两次对话记录，涵盖：旁听收获、评审标准流程、各参与角色价值创造分析。
一、收获
1. 了解评审的核心目的
项目评审旨在提高产品研发质量、降低设计缺陷风险，确保产品符合技术规范、安全标准及用户需求。
通过旁听，可以深刻理解"把问题消灭在设计阶段"的质量管理理念。
2. 掌握跨部门协作模式
本次评审涉及多个角色协同工作，亲历了以下职能如何在审中发挥作用：
| 参与角色 | 职责说明 |
|---|---|
| 项目经理 | 介绍项目背景、里程碑及市场失效数据 |
| 硬件/软件工程师 | 说明设计方案、变更点及风险 |
| 设计可靠性工程师 | 主持评审、记录问题、输出会议纪要 |
| 电控评价工程师 | 参与评审、输出测试方案 |
| 品质可靠性 | 行使一票否定权，把控可靠性风险 |
3. 认识实际产品问题的复杂性
通过本次评审内容，亲眼见到了真实项目中的典型问题，例如：
- 软件溢出 Bug：倒计时 261 分钟因超过 256 溢出变成 6 分钟，这类底层逻辑问题在测试阶段必须严格排查
- 硬件可靠性：密封胶塞装配不紧导致进水问题，涉及结构与工艺的交叉影响
- 交互逻辑：休眠与非休眠状态下唤醒响应不一致，影响用户体验
4. 建立"风险思维"
评审过程中大量使用 DFMEA（设计失效模式与影响分析），帮助建立从"可能出现什么问题"出发的逆向思维，这是工程师必备的系统性思考能力。
5. 理解评审结论的严肃性
评审结论分为通过、有条件通过、不通过三类，不满足条件的项目不得进入下一阶段，体现了研发流程的严格管控。
二、项目评审标准流程
📋 第一阶段：评审前准备
① 资料准备（由项目组完成）
- 项目简介（背景、需求、平台、里程碑）
- 电器/电控物料选型方案说明
- 初版图纸及规格书
- 摸底测试结果（能力、温升、环境适应性、寿命）
- 设计规范 Checklist 及降额表
- 借用/参考机型市场失效数据分析
- 初版 DFMEA（四新、变更及继承高风险）
- 整机手板及电器件实物
② 资料预审
- 项目组至少提前2 个工作日** 将资料提交给设计可靠性工程师
- 设计可靠性工程师在 1 个工作日内 反馈预审结果
- 预审通过后，至少提前 1 个工作日 发送会议通知及资料
⚠️ 评审触发条件（缺一不可）：方案明确且核心参数定型 + 摸底测试合格 + 评审资料完整
🔄 第二阶段：线下预检讨
在正式评审会前，项目组需完成：
- 技术方案线下检讨
- DFMEA 预评审
- 专业评审 Checklist 初稿讨论
🏛️ 第三阶段：正式评审会议（核心流程）
| 步骤 | 内容 | 执行人 |
|---|---|---|
| ① 项目背景说明 | 介绍项目情况、里程碑、借用机型 | 项目经理 |
| ② 设计方案说明 | 详细说明选型方案、差异点、图纸、摸底结果、Checklist | 工程师 |
| ③ 市场失效分析 | 介绍参考机型及器件的市场失效数据 | 项目经理 |
| ④ 风险识别 | 针对 DFMEA 进行分析说明 | 工程师 |
| ⑤ 专家评审讨论 | 各专家针对实物提出意见，技术决策者给出方案结论 | 评审专家组 |
| ⑥ 问题确认 | 评审记录员确认问题是否遗漏，明确跟进方式 | 记录员 |
| ⑦ 评审结论输出 | 输出评审会议纪要，含结论、问题清单、技术方案建议 | 设计可靠性工程师 |
📌 第四阶段：问题管理与闭环
- 评审输出：正式会议纪要、问题分类清单、问题录入问题管理系统
- 问题闭环：由设计可靠性工程师根据测试数据或设计变更单号确认问题关闭质量，必要时组织问题关闭评审会，逐一评审关闭状态与方案
🔧 电控专项评审五步思路
- 系统级需求与边界对齐 —— 确认功能需求是否清晰
- 原理图与负载特性匹配度审查 —— 硬件电路合理性
- PCB Layout 与结构防护审查 —— 布局合规性与防护设计
- 软件逻辑与时序交互审查 —— 逻辑正确性与交互一致性
- 测试验证与极限摸底闭环 —— 通过测试数据验证方案
三、各参与角色如何创造价值
色价值全景概览
| 参与角色 | 核心价值定位 | 价值创造方向 |
|---|---|---|
| 项目经理 | 信息枢纽与推进驱动 | 对齐目标、资源协调、进度管控 |
| 硬件工程师 | 物理层风险识别与方案落地 | 选型合理性、电路可靠性、防护设计 |
| 软件工程师 | 逻辑层缺陷消除与体验优化 | Bug 修复、逻辑正确性、OTA 策略 |
| 中试工程师 | 设计可制造性与量产可行性验证 | 测试验证、工艺问题暴露 |
| 设计可靠性工程师 | 评审流程主控与质量闸门 | 主评审、输出纪要、问题闭环 |
| 品质可靠性 | 独立监督与风险否决 | 行使一票否决权、可靠性基线维护 |
| 电控评价工程师 | 测试方案设计与客观验证 | 测试项设计、数据支撑评审结论 |
1. 项目经理 — 战略对齐与资源调度价值
核心职责： 介绍项目背景、里程碑节点、借用/参考机型市场失效数据
价值体现：
- 目标对齐价值：明确产品型号、项目编号、电脑板编码等基础信息，保所有参与方在同一信息框架下讨论，避免方向偏差
- 风险预判价值：通过提供 S66/S52 等量产机型三年维修率数据（PPM），将过往失效经验转化为本次设计的风险输入
- 进度管控价值：在保证质量的前提下协调加快项目推进，平衡质量与交期之间的张力
本次评审具体贡献：推动维修率分析报告的提交，以数据支撑参考机型选择，避免主观判断导致的基线偏差。
2. 硬件工程师 — 物理层可靠性构建价值
核心职责： 主板、显示板、Wi-Fi 模块等部件的配置变更说明与风险识别
价值体现：
- 选型合理性价值：通过替换底层 MI 芯片、增加电子质子模块等变更决策，确保硬件配置满足新国标要求及功耗目标
- 防护设计价值：针对玻璃面板静电防护提交单体报告，从源头消除静电损伤风险
- 系统协同价值：优化主板溢流保护逻辑，确保显示板休眠时主板能独立检测溢流信号并触发排水泵，解决多部件协同中的逻辑盲区
本次评审具体贡献：识别主板溢流保护在显示板休眠状态下的潜在失效场景，这是跨部件协作中极易被忽视的系统性风险。
3. 软件工程师 — 逻辑层缺陷消除与体验优化价值
核心职责： 软件版本变更说明、Bug 修复方案、OTA 策略制定
价值体现：
- 缺陷消除价值：
- 修复倒计时溢出 Bug（261 分钟超 256 字节上限溢出变为 6 分钟），防止底层数据类型错误引发户感知异常
- 修复强力再生等长周期程序中倒计时显示持续递减不准确问题
- 逻辑优化价值：
- 将在线检敲击允许时机从全程有效调整为排水阶段结束后生效，减少误触发风险
- 统一长按唤醒触发机制，解决休眠/非休眠状态响应不一致带来的用户体验割裂感
- 升级策略价值：完成 OTA 升级包开发与验证，制定内外销差异化 OTA 发布策略
本次评审具体贡献：溢出 Bug 的暴露与修复体现了软件工程师在边界条件测试中的专业价值——若未在评审阶段发现，将导致大批量出厂产品出现倒计时显示错误，影响用户信任度。
4. 中试工程师 — 设计验证与量产可行性价值
核心职责： 测试验证、工艺问题暴露、量产可制造性评估
价值体现：
- 测试验证价值：执行煮水测试，发现并定位密封胶塞装配不紧导致进水的问题，将结构工艺风险在量产前暴露并推动整改
- 可制造性价值：对新物料、新功能的实装可行性进行验证，确保设计方案能够顺利落地到生产线
- 数据支撑价值：为评审结论提供实测数据，使评审从"经验判断"升级为"数据驱动"
本次评审具体贡献：煮水测试中发现的进水问题是典型的"设计-工艺接口风险"，若未经中试验证直接量产，将导致批量售后返修，维修率 PPM 大幅上升。
5. 设计可靠性工程师 — 评审流程主控与质量闸门价值
核心职责： 主持评审会议、组织预审、输出评审纪要与问题清单、推动问题闭环
价值体现：
- 流程保障价值：确保评审资料提前 2 个工作日提交、1 个工作日内完成预审反馈，维护评审流性
- 问题沉淀价值：将评审中识别的变更点与风险识别点系统性录入问题管理系统，形成可追溯的质量档案
- 闭环管控价值：根据测单号确认问题关闭质量，必要时组织问题关闭评审会，确保每项问题真正得到解决而非停留在纸面
本次评审具体贡献：作为评审的"裁判员"，确保 10 项待办事项（OTA 升级包验证、静电防护报告提交等）均有明确责任人和时间节点，避免问题"悬空"。
6. 品质可靠性 — 独立监督与风险否决价值
核心职责： 独立于项目组，行使一票否决权，维护产品可靠性基线
价值体现：
- 独立视角价值：不受项目进度压力影响，从纯质量
浙公网安备 33010602011771号