我接触过不少研发团队：需求评审、开发、测试、发布都在转，版本交付周期却越拉越长。线上出了问题，往往要翻代码、对日志、再人工对一遍版本号，才能拼出完整链路。大家也想改，但周会上争来争去，说不清瓶颈到底卡在需求、开发还是发布。
看板不是没做过。更常见的情况是：Excel 导了三份、口径对不齐，会上半小时在解释「这个数怎么来的」，改进动作反而排不上。多数团队不是缺指标，是缺一套能驱动决策的度量逻辑——指标有了，却落不到「改流程、调资源、补测试」上。
接下来按我们实际推体系时的顺序写：先定目的，再选指标，再接数据，最后跑闭环。口径和例子按 50—300 人团队整理；更小的团队文末单独说。
一、先定目的：发现瓶颈，不是考核个人
动手前先把三个问题说清楚：指标给谁看、要解决什么问题、看完要推动什么决策。
研发负责人和项目经理看的不是同一套数。前者更关心交付节奏和质量有没有系统性下滑，后者关心某个版本为什么又延期。测试负责人可能盯着缺陷集中在哪个阶段。目的不同，指标组合就不该一样——「缩短交付周期」「降低变更失败率」「提高资源利用率」看着相近，选出来的指标往往完全不同。
这一点最容易在启动阶段被忽略。我见过有团队把「评审耗时」挂到个人考核里，两三周后评审记录是齐了，改动质量没上去，大家反而学会拆小 PR 应付统计。走过场评审、凑发布频率、放松测试标准，都是把度量当考核后的典型反弹。数据一旦不被信任，体系基本就废了。
所以启动时就要和团队讲明白，最好写进制度：指标只服务流程改进和资源调配，不用于绩效排名。效能度量回答的是「流程哪里卡住了」；个人绩效回答的是「谁完成了什么」。两件事可以并存，但不能混在一张表里。
## 二、怎么选指标：从目标反推，别从工具菜单里挑
1. 从业务目标往下拆，而不是反过来
行业里常用 GQM：先定目标，再拆成要回答的问题，最后才是指标。道理不复杂，难在克制——很多人先买了看板，再倒推「系统里有哪些字段能统计」，最后指标和业务目标对不上。
举个实际推导：目标是缩短版本交付周期，先要回答「从提交到上线，哪一段等待最长」，对应指标往往是变更前置时间。如果目标换成降低线上故障，问题会变成「哪类变更最容易引入缺陷」，指标可能就变成变更失败率或缺陷密度。目标一变，整组指标都要重排，不能照搬上一版的清单。
回到开头的两个痛点：交付越来越慢，优先盯变更前置时间和交付频率；定位问题要靠人工串数据，说明需求、代码、流水线、发布还没打通——这既是数据问题，也会直接拖长交付链路。两个痛点，往往指向同一类建设：先把链路串起来，再谈细指标。
2. 组织、团队、项目，三层够用，不必一次做全
| 层级 | 谁在看 | 典型问题 | 常看的方向 |
|---|---|---|---|
| 组织层 | 研发负责人 | 交付稳不稳、质量有没有系统性下滑 | 交付频率、变更失败率 |
| 团队层 | 技术经理 | 流水线健不健康、评审是不是总堵在同一处 | 流水线成功率、评审耗时 |
| 项目层 | 项目经理 | 这个版本交付多久、缺陷集中在哪 | 需求交付时长、缺陷密度 |
三层要能下钻。组织层变更失败率抬头，得能追到是哪个团队、哪个代码库、哪几次提交，而不是停在「整体偏高」四个字上。50—300 人的团队，我一般建议先做组织层加团队层；20 人以下决策链短，往往项目层两个指标就够驱动排期和测试调整。
3. DORA 四项可以打底，但别当标准答案抄
Google《State of DevOps》里的 DORA 四项，对「以代码变更驱动发布」的软件团队仍然好用：交付频率、变更前置时间、变更失败率、服务恢复时间。硬件、嵌入式团队需要改口径，「变更」可能要定义成固件或整机版本发布，不能生搬。
| 指标 | 主要在衡量什么 |
|---|---|
| 交付频率 | 发布有多勤 |
| 变更前置时间 | 从提交到上线要多久 |
| 变更失败率 | 上线后出故障的比例 |
| 服务恢复时间 | 出了故障多久能恢复 |
第一次搭体系，我会建议只上两个：变更前置时间加变更失败率。一个看速度，一个看稳定，数据采集成本相对可控。等团队习惯用数据开会了，再补交付频率或服务恢复时间。每层指标控制在三到五个，多了解释成本会压过改进本身。
代码行数、纯提交次数、工时填报，不建议当核心指标。它们好凑、好操纵，和业务价值的关系也不稳定——一次重构删掉三百行，行数下降，质量可能反而上去。每个指标上线前，团队里有人能回答「看完我们具体改什么」，再加；答不上来，就先不加。
三、数据从哪来：手工报表撑不久
每周从代码库、CI、项目管理各导一份表，是最常见的起步方式，也是最容易烂尾的方式。口径各人对各人的，数据滞后一周，度量会死在「维护报表」上，而不是死在「没有好指标」上。
选工具或验收现有平台，我通常只看三件事：
一是跨环节同源关联。一次提交能不能关联到需求单、流水线记录和发布结果。
二是常用口径自动计算。评审耗时、流水线成功率等能不能自动算、且全团队一致。
三是看板可下钻。从异常能不能定位到具体代码库或某次 PR。
界面好不好看排在后面——链路不通，看板再漂亮也是摆设。
Jenkins 加 GitLab 的组合很常见，数据贯通往往还要自己做集成和口径维护。如果代码、CI/CD、制品和度量本来就在同一套 DevOps 平台里（例如 GitFox），同源数据会省不少对接成本；继续用现有工具也完全可行，按上面三条逐项验收就行。项目管理侧若用禅道管需求、任务和缺陷，代码和交付侧用 GitFox 管托管和流水线，需求到发布能串起来，度量才算有完整链路。
## 四、跑通闭环：从一个指标开始，别一口气铺十个
度量、分析、改进、验证，四步听起来像口号，关键是验证阶段别偷改口径。
1. 一个完整闭环示例
说一个我们见过的路径：某团队移动端代码库的 PR 评审耗时，连续三周明显高于其他库。第一次复盘会上有人紧张，担心要对个人追责；后来重申「只看流程、不看排名」，才愿意把数据摊开。下钻后发现，这个库的 PR 平均改动文件多，评审又长期落在一个人身上。改进动作很具体：拆小 PR、补第二位评审人。之后用同一个指标、同一套统计口径看了四周，耗时才明显回落。
也有反例：上了十个指标，周会轮播一遍，没有任何一个对应到改流程的动作；或者评审耗时下来了，变更失败率却往上走——说明改进打偏了，需要回到第二节重新对目标。
2. 起步方式与自查清单
起步时只选一个与业务目标强相关、且已经能自动采到的指标，两轮迭代（大约两周一轮）跑通闭环，再扩到三到五个。不要先买看板再倒推指标，顺序一反，体系很容易变成摆设。
如果现在要动手，可以按下面五项自查：
- 目的能不能用一句话说清；
- 业务目标和团队共识是否一致；
- 每个候选指标是否对应一个具体动作；
- 看板数据是否还需要每周人工整理；
- 有没有至少一个改进动作落地，并用同一口径复测过。
五项都答得上来，比堆十张报表有用。
五、几个常被问到的问题
问：会不会变成变相考核？
可以不变相考核，但默认很容易滑向考核——尤其当指标异常时，管理者第一反应往往是「谁的问题」。要在启动时写清楚边界，第一次复盘就对照：上次异常，我们改的是流程还是追责个人。
问：二十来人的小团队要不要搞完整体系？
不必。交付频率和变更失败率先跑起来，闭环走通一轮，再考虑加指标。
问：和项目管理软件是什么关系？
项目管理管计划和过程记录；效能度量要从代码和流水线里得出「该改哪里」的结论。两者分工不同，串起来才有从需求到发布的完整视图。
如果你接下来只做一件事：选一个指标，定清楚给谁看、看完改什么，跑完一轮「发现问题—改流程—用同一口径验证」。这比一次性建「大而全」的体系可靠得多。
