4、结果评估：如何量化项目成果？关键绩效指标（KPI）与关键结果（OKR）的对比
项目做完了，复盘会上最怕什么？
最怕大家凭感觉说话。「我觉得这次还不错」「我感觉进度有点慢」——这种话一出口，讨论就变味了。
我做了十几年嵌入式项目，踩过最大的坑就是：没有量化标准，复盘变成甩锅大会。
所以这一章，咱们就聊聊怎么用数字说话。核心就是两套工具：KPI 和 OKR。
4.1 先搞清楚：KPI 和 OKR 到底有什么区别？
很多人把这两个混着用，其实它们干的活完全不一样。
我打个比方你就明白了：
- KPI 是后视镜——告诉你过去开得怎么样，车速多少，油耗多少。
- OKR 是导航仪——告诉你接下来要去哪，距离目的地还有多远。
一个管过程监控，一个管目标牵引。在嵌入式项目里，两者缺一不可。
核心观点：
KPI 保证你不跑偏，OKR 保证你跑得远。
复盘时，先用 KPI 看「做没做到」，再用 OKR 看「做得好不好」。
下面这张图，把两者的关系画清楚了：
4.2 嵌入式项目里，KPI 怎么定才不虚？
说实话，我见过太多团队定的 KPI 根本没法用。
比如「提高代码质量」——这怎么量化？你告诉我什么叫「提高」？
我自己的习惯是：KPI 必须能直接从工具或流程里拿到数据。
4.2.1 嵌入式项目常用的 KPI 清单
下面这张表，是我这些年反复打磨出来的。每个指标都对应一个具体的采集手段：
| 维度 | KPI 名称 | 计算公式 / 采集方式 | 典型目标值 |
|---|---|---|---|
| 质量 | Bug 密度 | Bug 数 ÷ 代码行数（KLOC） | ≤ 0.5 个/KLOC |
| 质量 | 静态扫描违规数 | MISRA-C 规则违反次数 | ≤ 10 次/版本 |
| 进度 | 任务按时完成率 | 按时完成任务数 ÷ 总任务数 | ≥ 90% |
| 进度 | 里程碑偏差 | 实际完成日期 - 计划完成日期 | ≤ 3 个工作日 |
| 效率 | 编译通过率 | 成功编译次数 ÷ 总编译次数 | 100% |
| 效率 | CI 流水线通过率 | CI 成功次数 ÷ 总触发次数 | ≥ 95% |
| 资源 | Flash 占用率 | 实际 Flash 用量 ÷ 芯片 Flash 总量 | ≤ 80% |
| 资源 | RAM 峰值占用 | 运行时最大堆栈 + 堆使用量 | ≤ 芯片 RAM 的 70% |
我的经验：
KPI 不要超过 8 个。超过 8 个，团队就记不住了。
我一般只盯 5 个核心指标：Bug 密度、任务按时完成率、编译通过率、Flash 占用率、CI 通过率。
其他指标作为辅助，复盘时按需调出来看。
4.2.2 避坑：KPI 不能只看结果，还要看趋势
我曾经带过一个项目，版本发布前 Bug 密度是 0.3 个/KLOC，看起来挺好。
但复盘时我多看了一眼趋势图——发现前两周还是 0.1，最后一周突然飙到 0.3。
这说明什么？说明团队在赶进度，测试不充分，Bug 都堆到最后才报出来。
注意：
KPI 复盘一定要看时间序列，不能只看最终值。
一个突然恶化的 KPI，比一个一直很差的 KPI 更值得警惕。
4.3 OKR 在嵌入式项目里怎么落地？
OKR 这东西，互联网公司用得很多。但在嵌入式领域，很多人觉得「太虚了，不接地气」。
我不这么看。问题不在 OKR 本身，在于你不会翻译。
4.3.1 把业务语言翻译成工程语言
举个例子：
- 业务目标（O）：提升产品市场竞争力
- 工程翻译（O）：将系统启动时间缩短 50%
你看，这么一翻译，工程师就知道该干什么了。
关键结果（KR）也要跟着翻译：
- KR1：Bootloader 阶段从 2.5s 优化到 1.0s
- KR2：操作系统初始化从 1.8s 优化到 0.8s
- KR3：应用层自检从 1.2s 优化到 0.5s
OKR 落地三原则：
- O 要有挑战性——不是「维持现状」，而是「跳一跳够得着」
- KR 必须可测量——每个 KR 都要有明确的数字或百分比
- KR 要对应具体任务——每个 KR 下面都要有可执行的 Action
4.3.2 复盘时怎么用 OKR？
我一般分三步走：
- 第一步：打分——每个 KR 完成度 0-1.0 分，0.7 算不错，1.0 说明目标设低了
- 第二步：找差距——没完成的 KR，是目标不合理，还是执行出了问题？
- 第三步：定改进——下一轮 OKR 要不要调整方向？资源要不要重新分配？
举个例子，我去年做的一个车载项目：
- O：提升 CAN 总线通信可靠性
- KR1：总线错误帧率从 0.1% 降到 0.01%（完成度 0.8）
- KR2：重传机制覆盖率从 60% 提升到 100%（完成度 0.6）
- KR3：故障注入测试通过率从 70% 提升到 95%（完成度 0.9）
复盘时发现，KR2 没完成是因为硬件资源不够，重传缓冲区太小。下一轮 OKR 就加了一条「优化缓冲区管理算法」。
4.4 KPI 和 OKR 怎么配合使用？
很多人问我：到底用 KPI 还是用 OKR？
我的回答是：两个都要用，但用在不同的地方。
下面这张表，是我在项目里实际用的配合方式：
| 项目阶段 | 主要工具 | 关注点 | 举例 |
|---|---|---|---|
| 日常开发 | KPI | 过程是否稳定 | 编译通过率、CI 通过率 |
| 版本迭代 | OKR | 目标是否达成 | 启动时间缩短 50% |
| 里程碑评审 | KPI + OKR | 既看过程又看结果 | Bug 密度 + 功能完成度 |
| 项目复盘 | KPI + OKR | 全面评估 | 所有指标综合打分 |
我的习惯：
每周站会用 KPI 看板，快速扫一眼有没有异常。
每个迭代结束用 OKR 做回顾，看看目标完成得怎么样。
项目整体复盘时，把 KPI 和 OKR 放在一起看——KPI 告诉你「有没有做对」，OKR 告诉你「有没有做对的事」。
4.5 量化成果的终极公式
说了这么多，最后给一个我自己的总结公式：
项目成果 = KPI 达标率 × OKR 完成度 × 团队满意度
三个维度缺一不可：
- KPI 达标率：过程是否规范，质量是否可控
- OKR 完成度：目标是否达成，价值是否交付
- 团队满意度：人有没有成长，流程有没有优化
最后一个指标，很多人会忽略。但我告诉你，一个项目做完，团队累得半死、怨声载道，那这个项目就是失败的——不管 KPI 和 OKR 多好看。
所以复盘的时候，我总会问一句：「如果重来一次，你愿意用同样的方式再做一遍吗？」
答案如果是「不愿意」，那说明我们的量化体系里，还缺了点什么。