研发评价的核心不是把工程师变成“被计件的人”，而是帮助管理层看见系统性瓶颈，帮助 BG 找到项目风险，帮助工程团队减少返工和无效等待。本报告建议采用少量、团队级、可自动采集、能驱动改善的指标。
建议先建立一套“10+6”指标：10 个公司级核心指标用于高层和 BG 对标，6 个诊断指标用于专项分析。第一年不要追求完整覆盖，先打通项目、问题、评审、变更和试产数据，并明确区分研发可控因素与客户、供应链、产线等外部因素。
核心看研发可控偏差、阻塞事件、变更来源、样机轮次和关键问题闭环。不要用加班时长、会议次数、图纸数量、代码行数这类活动量指标。
DI、FPY、Reopen 重要，但偏结果。要补充设计评审发现率、问题前移率、失效预防覆盖率、验证一次通过率等过程质量指标。
按 BG、产品族、客户类型、OEM/ODM/JDM、项目复杂度和阶段分层，否则指标会误伤高难度团队，也会掩盖低复杂度项目的问题。
消费电子项目特别是 OEM 项目，很多周期和变更并非研发单方面可控。因此效率评价不能简单统计“是否延期”和“用了几天”，而要评价研发是否提前识别风险、是否把阻塞透明化、是否把可控问题闭环。
阶段是否达成只作为项目经营事实，不直接评价研发。评价研发时只看研发可控延期、风险提前预警和跨部门阻塞闭环。
评审等待、一次通过、变更响应对时间戳要求高，第一年不作为公司级硬指标，只在试点项目或痛点专题中抽样使用。
不要求工程师逐日填报阻塞工时。只对影响里程碑的阻塞事件登记开始日、解除日、责任域、原因码和影响节点。
指标体系分为三层：公司层看趋势和对标，BG 层看改善责任，项目层看风险闭环。每个指标都必须明确数据源、统计口径、使用场景和管理动作。
关注研发效率、研发品质、复用能力和风险前移的趋势。适合月度经营会和季度治理委员会。
按产品类型和复杂度校准后对标，识别流程瓶颈、资源冲突、客户变更和质量短板。
用于项目周会、Gate 评审和试产复盘，推动异常及时升级和问题闭环。
效率指标不建议衡量“工程师做了多少”，而应衡量研发可控事项是否被及时识别、透明升级和有效闭环。对客户、供应链、产线搭建导致的偏差，要作为经营风险管理，而不是研发绩效扣分。
| 指标 | 定义与公式 | 建议数据源 | 统计方法 | 管理动作 | 低抵触原因 |
|---|---|---|---|---|---|
| 阶段偏差归因率 | 对未按计划完成的 EVT、DVT、PVT 或内部阶段，完成原因归因的比例。已完成归因的阶段偏差数 / 阶段偏差总数 × 100% | 项目计划、Gate 记录、NPI 系统 | 月度滚动；原因分客户输入、研发技术、供应链、产线/设备、品质验证、资源冲突、法规/认证、其他；只统计影响里程碑的偏差 | 把“延期事实”转成“可管理原因”，明确哪些需要研发改进，哪些需要高层协调 | 不把阶段延期简单算到研发头上，工程师抵触更小 |
| 研发可控延期率 | 阶段或关键交付延期中，主因归属于研发可控事项的比例。研发可控延期数 / 已归因延期数 × 100% | 项目管理、PLM、ALM、任务系统 | 只在完成归因后统计；研发可控原因包括方案成熟度不足、设计返工、评审准备不足、验证计划不足、资源安排不当 | 用于识别研发体系需要改善的真实短板，而不是把外部不确定性混在一起 | 把不可控因素剥离，避免指标失真 |
| 评审退回率 | 因资料不完整、关键证据不足、方案明显不成熟导致退回重审的比例。退回重审数 / 实质技术评审数 × 100% | 评审系统、会议纪要、PLM 流程记录 | 第一年可人工抽样；只统计关键 Gate 和重大设计评审；带条件通过不算退回 | 反推评审准入条件、模板有效性和前置自查质量 | 比一次通过率更不鼓励“形式通过”，也降低精确取数压力 |
| 评审排队异常数 | 关键评审因专家排期、资料补正、跨部门确认等原因超过约定服务时限的事件数。超 SLA 评审事件数；按原因统计 | 评审系统、邮件流程、PLM | 不要求精确到小时；建议按自然日和红黄灯记录；第一年只覆盖关键 Gate 评审 | 优化专家池、评审排期和资料准入条件 | 只记录异常事件，管理成本低，工程师也欢迎减少等待 |
| 需求/规格稳定度 | 需求冻结后新增、删除、重大修改的比例。冻结后重大变更数 / 冻结需求数 × 100% | 需求系统、客户变更记录、ECR/ECO | 必须标记变更来源：客户、内部设计、供应商、法规、制造；不把客户变更简单归责研发 | 识别客户协同、前端澄清和需求基线管理问题 | 保护研发免受外部变化误伤 |
| 重大变更影响评估及时率 | 客户或内部重大变更在约定时限内完成影响评估的比例。按期完成影响评估的重大变更数 / 重大变更数 × 100% | PLM、ECR/ECO 系统 | 只统计重大变更；按客户变更、内部设计变更、供应商/物料变更、制造变更分层；OEM 项目单独看客户来源占比 | 减少跨部门等待，避免变更影响迟迟不清 | 不追踪所有小变更，只管会影响节点、成本、质量的重大变更 |
| 样机迭代轮次 | 达到阶段目标所需样机版本或试制轮次。阶段内样机版本数 / 项目数；按阶段统计 | 试制记录、BOM 版本、样机申请、NPI 系统 | 按产品复杂度和创新程度分层；不能简单追求轮次越少越好 | 判断前端验证充分性和设计成熟度 | 使用客观版本记录，避免主观评价 |
| 研发阻塞事件 | 影响项目关键路径或里程碑的阻塞事件数量、累计自然日和责任域分布。阻塞事件数；累计阻塞自然日 = Σ(解除日 - 开始日 + 1) | 项目红黄灯、周例会纪要、问题系统、项目经理台账 | 只统计红黄灯项目和关键路径事件；字段控制在 6 个：项目、节点、开始日、解除日、责任域、原因码 | 把项目不动的原因显性化，推动供应链、产线、客户确认和研发资源协同 | 不要求逐日填工时，只登记事件，且能帮助工程师暴露外部阻塞 |
质量指标要从“后端缺陷”向“前端预防”扩展。DI、FPY、Reopen 仍然保留，但要补充设计成熟度、问题前移、失效预防和验证充分性，否则管理动作容易滞后。
| 指标 | 定义与公式 | 建议数据源 | 统计方法 | 管理动作 | 低抵触原因 |
|---|---|---|---|---|---|
| DI 值 | 缺陷指数，用于衡量阶段内缺陷密度或严重度加权缺陷水平。建议：Σ(缺陷数 × 严重度权重) / 交付规模或样本规模 | 问题系统、测试系统、试产问题库 | 公司需统一严重度权重；按阶段、专业、产品复杂度分层；只看趋势不做跨复杂度粗暴排名 | 识别设计薄弱专业和阶段质量风险 | 已有质量管理习惯，关键是统一口径 |
| 验证 FPY | 首次验证通过率，包括设计验证、可靠性测试、试产测试等。首次通过项数 / 首次验证总项数 × 100% | 测试系统、实验室记录、DVT/PVT 报告 | 按测试类型分层；需区分客户新增要求、设备异常、样品异常和设计问题 | 反推验证计划质量、设计成熟度和测试准备充分性 | 使用已有测试结果，不要求工程师额外解释每个通过项 |
| 问题 Reopen 率 | 已关闭问题被重新打开的比例。Reopen 问题数 / 已关闭问题数 × 100% | 问题系统、8D 系统、Jira/禅道等 | 按严重度统计；区分关闭标准不清、验证不足、根因错误和措施失效 | 提升根因分析、关闭准入和验证有效性 | 工程团队通常认可“少返工”的价值 |
| 问题前移率 | 在设计评审、仿真、EVT 前期发现的问题占比。前端发现问题数 / 全生命周期问题数 × 100% | 评审问题库、测试问题库、试产问题库 | 按项目阶段定义“前端”；关注严重问题前移率，不鼓励刷低价值问题 | 评价质量策划和评审是否真正有效 | 鼓励早暴露问题，减少藏问题倾向 |
| 逃逸缺陷率 | 前一阶段应发现但逃逸到后一阶段的问题比例。后阶段发现且归因前阶段的问题数 / 后阶段问题总数 × 100% | 问题系统、阶段复盘、试产/量产问题库 | 阶段归因需由复盘确认；避免由单一部门裁定责任 | 补强评审清单、测试覆盖和准入标准 | 指标聚焦流程防线，而非单点追责 |
| 失效预防覆盖率 | 关键功能、特殊特性、高风险设计是否完成 DFMEA、验证计划和控制措施。已覆盖高风险项 / 识别高风险项 × 100% | DFMEA、DRBFM、风险清单、控制计划 | 只针对高风险项统计；第一年不要强求所有项目全量 FMEA | 把问题预防前移，支撑 APQP 思路落地 | 聚焦高风险，不铺开重表格 |
| 重大问题闭环周期 | A/B 类或客户关注问题从创建到验证关闭的时间。验证关闭时间 - 问题创建时间；看 P80/P90 | 问题系统、客户问题清单、8D 系统 | 按严重度和责任类型分层；超期问题看阻塞原因 | 保障重大风险及时收敛，减少试产和量产冲击 | 只盯重大问题，避免大量低价值跟踪 |
| 重复问题率 | 同类根因、同类失效模式在不同项目或同项目不同阶段重复出现的比例。重复问题数 / 问题总数 × 100% | 问题库、失效模式库、8D 复盘 | 需建立失效模式分类字典；先从 Top 20 问题族开始 | 推动经验库、评审清单和设计规范更新 | 工程师会直接受益于少踩旧坑 |
指标落地的关键不在公式，而在数据采集成本。建议第一阶段只取“系统自动生成字段 + 少量必填原因码”，不新建大表格，不要求工程师写长篇解释。
计划节点、实际节点、问题状态、版本发布、重开标记、评审结论等已有记录优先；时间戳不完整的场景先做事件统计。
客户输入、研发技术、物料供应、测试资源、制造/产线、质量验证、资源冲突、外部依赖。分类太细会迅速失真。
低等级问题只做自动统计；重大延期、重大质量问题、客户关注问题才做根因复盘和人工校准。
| 系统/记录 | 可取指标 | 最低字段要求 | 落地提醒 |
|---|---|---|---|
| PLM / ECR / ECO | 重大变更影响评估及时率、变更来源、需求稳定度、BOM 版本变化 | 创建时间、批准时间、关闭时间、变更等级、变更来源 | 先统一来源分类和等级定义 |
| 项目管理/NPI 系统 | 阶段偏差归因率、研发可控延期率、样机轮次、风险红黄灯、阻塞事件 | 项目类型、阶段计划、实际完成、复杂度、风险状态、偏差原因 | 项目复杂度是公平对标的关键字段 |
| 问题/8D 系统 | DI、Reopen、闭环周期、重复问题率、逃逸缺陷率 | 严重度、创建阶段、发现阶段、根因分类、关闭时间、重开标记 | 先做 Top 问题族，不追求一次性完美分类 |
| 评审系统/PLM 审签 | 评审退回率、评审排队异常数、评审发现率、问题前移率 | 评审类型、结论、退回原因、异常原因、问题数、问题等级 | 要区分形式审签和实质技术评审 |
| 实验室/测试系统 | FPY、验证覆盖率、测试等待时间、测试失败原因 | 测试项、样本数、首次结果、失败原因、测试开始/结束时间 | 设备异常与设计失败要分开统计 |
| 字段 | 填写方式 | 说明 |
|---|---|---|
| 项目 / 阶段 / 影响节点 | 项目经理选择 | 只登记影响关键路径或里程碑的阻塞，不登记日常小等待 |
| 开始日 / 解除日 | 自然日 | 无需精确到小时；未解除则每周滚动更新 |
| 责任域 | 单选 | 客户、研发、供应链、制造/产线、品质/测试、设备/工装、采购/供应商、公司资源 |
| 原因码 | 单选 + 可选备注 | 分类不超过 8 类；备注只在红灯事件或高层协调事项中必填 |
| 当前动作 / 责任人 | 一句话 | 用于推动闭环，不用于个人绩效排名 |
统计建议：月度看阻塞事件数、累计阻塞自然日、Top 原因和未关闭红灯事件。不要要求工程师填写“阻塞工时”，否则成本高且很快失真。
研发指标最大的问题不是没有数据，而是数据被错误比较。建议采用分层、分位数、滚动窗口、趋势判断和少量抽样校准。
这些指标可以作为局部诊断数据，但不建议用于 BG 排名或个人绩效。它们管理成本高、解释空间大，容易造成工程师抵触和行为扭曲。
| 不建议指标 | 主要问题 | 替代方案 |
|---|---|---|
| 个人图纸数、代码行数、提交次数 | 活动量不等于贡献，容易鼓励拆分提交、堆数量和低价值产出 | 团队级关键任务流动周期、评审质量、交付结果 |
| 个人缺陷数排名 | 复杂任务天然缺陷多，会惩罚承担难题的人，也会诱导藏问题 | 团队级 DI、逃逸缺陷率、问题前移率，按复杂度分层 |
| 问题关闭数量 | 容易鼓励快关、误关，导致 Reopen 增加 | 重大问题闭环周期 + Reopen 率 + 关闭质量抽样 |
| 会议次数、评审次数 | 只反映活动频率，不反映决策质量和问题发现价值 | 评审排队异常数、评审退回率、评审发现的高价值问题数 |
| 简单跨 BG 排名 | 客户、产品复杂度、业务模式不同，排名会误导管理判断 | 同类项目对标、历史趋势改善、复杂度校准后的雷达图 |
| 相对初始 BOM 的降本额 | 如果初始方案或初始报价偏高，后续降本会被虚增，甚至诱导团队先用贵方案、报高价 | 相对目标成本、Should Cost、基准方案和最终中标/量产利润的综合评价 |
成本指标要衡量“在满足功能、质量、进度和客户报价竞争力前提下，研发方案对利润的真实贡献”。不建议用初始 BOM 降价额单独评价，否则会诱导先报贵、后降本。
初始 BOM 只能用于过程跟踪，正式贡献要和目标成本、Should Cost、历史同类方案、客户中标价格和量产成本一起校准。
降本是否有价值，最终要看是否提升毛利、是否守住性能质量、是否帮助项目中标和量产爬坡。
如果初期方案明显高于 Should Cost 或历史基准，后续降本不计入研发正向贡献，必要时还要计入前端成本策划不足。
| 指标 | 定义与公式 | 建议数据源 | 统计方法 | 管理动作 | 防博弈设计 |
|---|---|---|---|---|---|
| 目标成本达成率 | 方案在关键 Gate 或报价节点达到目标成本的程度。目标成本达成率 = 目标 BOM 成本 / 当前 BOM 成本 × 100%；达到或低于目标成本记为达成 | 目标成本表、BOM、采购报价、成本工程数据库 | 目标成本必须在方案冻结或 RFQ 早期锁定；按产品复杂度、客户、项目类型分层 | 推动研发、采购、供应链在前端共同做 Design-to-Cost | 基准在早期锁定，不能用人为偏高的初始 BOM 制造降本空间 |
| Should Cost 偏差率 | 当前 BOM 或关键物料报价相对 Should Cost 的偏差。Should Cost 偏差率 = (当前成本 - Should Cost) / Should Cost × 100% | 成本工程模型、历史报价、材料/工艺/良率模型、供应商报价 | 先覆盖 Top 成本物料和关键模块；Should Cost 由成本工程、采购、研发共同确认 | 识别高估报价、过度设计、供应商议价空间和替代方案机会 | 用独立成本模型约束初始方案，减少“先贵后降”的空间 |
| 设计降本有效贡献 | 由研发设计变更、模块复用、规格优化、工艺协同带来的可验证成本下降。有效贡献 = (基准成本 - 新成本) × 预计量产数量 × 研发贡献系数 | BOM 版本、ECR/ECO、采购价格、量产预测、成本复盘 | 只统计已通过验证、不降低质量和客户体验、并进入报价或量产基线的方案 | 鼓励研发做结构优化、物料替代、模块复用和测试/装配简化 | 贡献基准取目标成本、Should Cost、历史同类最低合理成本中的较严者 |
| BOM 毛利贡献率 | BOM 成本改善对项目毛利率的贡献。BOM 毛利贡献率 = BOM 成本改善额 / 项目销售收入；或 Δ毛利率 | 项目报价、销售价格、BOM 成本、财务测算 | 按中标版、量产版分别统计；不把客户降价压力下的被动让利算作研发贡献 | 把工程降本和项目经营结果打通 | 必须结合中标率、报价竞争力和量产毛利，防止只看账面降本 |
| 复用成本收益 | 复用成熟模块、优选物料、测试方案或工装带来的成本与周期收益。复用收益 = 新开发/新物料方案成本 - 复用方案成本；可附加验证周期缩短收益 | 模块库、优选物料库、BOM、测试/工装记录 | 只统计满足性能、可靠性、供应安全的复用；区分一次性 NRE 和量产 BOM 收益 | 推动跨 BG 模块库和优选物料库建设 | 复用必须过质量和供应护栏，避免为降本牺牲可靠性 |
| 前端成本风险暴露率 | 在报价或方案冻结前识别 Top 成本风险并形成动作的比例。已识别并闭环的 Top 成本风险数 / Top 成本风险总数 × 100% | 成本评审、报价评审、BOM Top 20 分析、风险清单 | 聚焦 Top 20 成本项、长周期物料、单一供应源、良率不确定项 | 把成本问题前移，减少报价后被动降本 | 奖励早暴露风险，不奖励后期“救火式”降本 |
| 口径 | 建议做法 | 原因 |
|---|---|---|
| 基准成本 | 采用“目标成本、Should Cost、历史同类方案、客户/市场可接受报价”四者校准，不单用初始 BOM | 防止初始成本虚高导致降本贡献虚高 |
| 贡献归属 | 按研发、采购、供应链、制造、客户规格变化分摊；研发只认设计方案导致的成本改善 | 避免把采购议价、客户降规格或市场降价都算给研发 |
| 质量护栏 | 降本方案必须通过 DVT/PVT、可靠性、客户体验和量产良率验证 | 防止为了降 BOM 牺牲质量，后续用返工、客诉和良率损失还债 |
| 报价护栏 | 若初始报价导致项目丢失或毛利不可接受，即使后续有降本动作，也不计正向贡献 | 研发成本管理的目标是赢单和盈利，不是制造降本故事 |
| 阶段口径 | 分别统计 RFQ/立项版、方案冻结版、中标版、量产版 BOM 成本 | 看成本是否前端收敛，而不是量产前被动压缩 |
第一版看板建议极简：只放 6 个核心趋势、6 个异常清单和 3 个专项跟踪。看板的目标是触发管理动作，不是展示所有数据。
| 阶段 | 优先指标 | 动作 | 验收标准 |
|---|---|---|---|
| 0-3 个月 | 阶段偏差归因率、DI、FPY、Reopen、重大问题闭环周期 | 统一偏差原因码、质量口径和重大问题分级，建立历史基线 | 主要 BG 可出月度基线表，且延期原因能区分研发可控与外部因素 |
| 3-6 个月 | 评审退回率、评审排队异常数、重大变更影响评估及时率、问题前移率 | 选择试点 BG，用抽样方式校准评审和变更口径 | 能识别 Top 3 流程瓶颈，且不依赖高精度时间戳 |
| 6-12 个月 | 逃逸缺陷率、重复问题率、失效预防覆盖率、研发阻塞事件、目标成本达成率 | 建立问题族、原因码和目标成本机制，开展质量与成本专项改善 | 试点项目形成可量化改善案例，且成本贡献不依赖初始 BOM 虚高 |
指标设计参考了研发管理、软件交付、产品开发质量和开发者体验领域的通行原则。落地到 Goertek 时，应以内部系统数据和项目复盘校准。