停止测量噪声：软件工程中真正重要的生产力指标
Source: Dev.to
请提供您希望翻译的正文内容，我将为您翻译成简体中文。
介绍
生产力 已经在工程领域成为一个脏字。
在 Slack 频道里提到它，大家立刻会假设管理层在寻找解雇底层 10 % 员工的理由，或者麦肯锡又推出了另一份有争议的报告。（值得一提的是，他们 2023 年的报告实际上警告不要使用过于简单的衡量标准——比如产出的代码行数或提交次数——而不是推荐使用这些指标。反弹主要来自他们方法的其他方面。）
这种怀疑是有原因的。数十年来，软件工程中的生产力指标一直被用来微观管理个人贡献者，而不是优化系统。
但完全忽视指标同样危险。当你凭“氛围”和轶事证据来运营工程组织时，你实际上在玩一场传话游戏：现场实际情况在层层管理传递中被扭曲，你失去了真实的底层数据。
问题不在于是否应该衡量生产力。
问题在于应该衡量什么。
为什么旧仪表盘噪声大
- 在 AI 编码工具时代，DORA 指标已不再足够。
- 大多数标准仪表盘充斥着噪声。
DORA 指标 – 一个很好的烟雾报警器，而非诊断工具
| 指标 | 它告诉你的信息 | 它不告诉你的信息 |
|---|---|---|
| 部署频率 | 发行速度 | 为什么速度在变化 |
| 变更交付时间 | 从提交到生产的时间 | 工作流中的瓶颈 |
| 变更失败率 | 发布的稳定性 | 失败的根本原因 |
| 失败部署恢复时间 | 恢复的速度 | 导致失败的系统性问题 |
DORA 在发出某事出错的信号（例如，变更失败率的激增）方面表现出色，但它并未解释原因。
AI 工具已经打破了“速度”作为单一指标的概念
- 开发者现在可以用 LLM 在 30 秒内生成 500 行的 PR。
- 编码阶段的周期时间看起来惊人，但如果这些代码是幻觉般的混乱，导致审查过程被卡住三天，个人速度就是以团队吞吐量为代价的。
研究亮点 – Tilburg University 分析 GitHub 活动发现：
- 经验较少的开发者从 AI 工具中获得生产力提升。
- 核心开发者现在审查 6.5 % 更多代码，且他们自己的原始代码生产力下降 19 %。
- 时间转移到了审查 AI 生成的提交上。
系统思维方法：三层测量
| 层级 | 测量内容 | 示例指标 |
|---|---|---|
| 投入 | 我们正在投资的内容 | 人员数量、工具成本、云支出 |
| 内部 | 工作实际是如何进行的 | PR 工作流、返工、专注时间、上下文切换 |
| 产出 | 我们交付的内容 | 可靠性、功能采纳、客户价值 |
Source: …
2025 年四个关键指标
1. 重构率（最被低估的指标）
定义：代码在合并后不久被重写或回滚的比例。
为何重要：在 AI 辅助的环境中，快速交付低质量代码变得容易。对数百个工程团队的分析数据显示，AI 采纳呈现 U 形曲线：
| AI 使用水平 | 重构率 |
|---|---|
| 低（手动） | 标准 |
| 高（模板化） | 低（AI 在单元测试和脚手架方面表现出色） |
| 混合（25‑50 % AI） | 最高 |
红旗：周期时间在提升 且 重构率上升 → 你在更快地累积技术债务。
行业数据 – GitClear 对 2.11 亿行代码的分析：
- 代码 churn 预计在 2024 年翻倍，相较 2021 年基线。
- 7.9 % 的新代码在两周内被修改（2020 年为 5.5 %）。
- 复制粘贴代码比例从 8.3 % → 12.3 %。
可视化：如 Span 的 AI Code Detector 等工具现在能够以 95 % 的准确率（Python、TypeScript、JavaScript）识别 AI 生成的代码，为你提供采纳模式和质量影响的真实数据。
2. 阴影工作比率
定义：工程师在“不可见”工作上花费的时间比例，这类工作不会出现在工单或路线图中。
典型划分（工程副总裁视角）
- 40 % 新功能
- 20 % 技术债务
- 40 % KTLO（保持系统运行）
工程师的真实情况
“我在平台团队，但每周要花 20 小时修复 Checkout 的 bug，因为只有我熟悉旧代码库。”
IDC 研究 – 开发者时间分配：
- 16 % 用于实际的应用开发。
- 84 % 用于会议、上下文切换和“阴影工作”。
三类不可见工作（Anton Zaides，工程经理）
- 不可见的生产支持 – 警报、临时请求。
- 技术粘合工作 – 代码审查、规划、指导、文档。
- 阴影待办 – 非正式的产品经理请求、未经批准的“正确事”。
案例研究：一名高级工程师有 >40 % 的时间花在不可见工作上；内部团队记录了约 65 % 的阴影工作，却没有成本代码或计费。
红旗：阴影工作比率高 → 容量被悄悄吞噬。
3. 专注时间利用率
定义：工程师拥有的不中断的深度工作时间（编码、设计、问题解决）的百分比。
为何重要：上下文切换的代价巨大。研究表明一次中断会导致 15‑30 分钟 的生产力损失。
衡量方法：
- 跟踪日历中的 “专注块” 与实际会议时间的对比。
- 使用 IDE 插件记录活跃编码时间与空闲时间。
- 与 PR 吞吐量和缺陷率关联分析。
目标：每周工作时间中 ≥60 % 作为受保护的专注时间。
4. AI 生成代码质量指数（AGCQI）
定义：综合评分，融合 重构率、合并后缺陷密度 与 AI 代码检测比例。
公式（示例）
AGCQI = (1 – ReworkRate) × (1 – DefectDensity) × (1 – AI_CodePct)解读
- 接近 1 → 质量高，重构少，风险 AI 代码低。
- 接近 0 → 重构频繁，缺陷多，严重依赖低质量 AI 输出。
行动：设定季度阈值（例如 AGCQI ≥ 0.85），并对任何下降进行调查。
综合起来 —— 快速启动检查清单
-
为你的技术栈装配监控
- 部署 AI 代码检测工具（Span、GitHub Advanced Security）。
- 启用 PR 分析（GitClear、Linear、Jira）。
- 捕获专注时间数据（Clockify、RescueTime、IDE 插件）。
-
创建仪表盘，展示上述四个指标，按团队和时间段（每周、每月）拆分。
-
设定基线阈值（例如，返工红旗：仅依赖项目管理数据会掩盖实际工作投入的去向）。
新工程智能平台
像 Span 这样的平台通过分析 git 活动自动对工程工作进行分类，创建一个 “工程时间的自动损益表”。
- 它们使用数据而非猜测来回答问题。
- 它们能够高精度检测 AI 编写的代码，并将其与下游指标（返工率、审查周期、缺陷密度）关联。
关键指标追踪
1. 重工率
跟踪编写代码时间与审查代码时间之间的关系。
- 随着 AI 即时生成代码，审查者成为新的瓶颈。
- Tilburg 大学研究：每位核心贡献者现在每年审查约 10 个额外的 PR。
2. 投资分布
- 类似 Span 的平台通过挖掘提交、PR 和审查活动，对工作（维护、创新、迁移等）进行分类。
- 示例洞察：“创新”团队将70 % 的时间用于维护。
3. 审查负担
- Faros AI 分析： 随着 PR 量超过审查者容量，代码审查时间 ↑ 91 %。
- 同期 PR 大小 ↑ 154 %，缺陷率 ↑ 9 %。
| 情境 | 指标 | 风险 |
|---|---|---|
| 太快 | 大量 AI 生成的 PR 在几分钟内获批 | 质量问题迫在眉睫 |
| 太慢 | 审查负担过重 | 高级工程师陷入“审查地狱”，导致倦怠和创新停滞 |
红旗警示： “LGTM” 文化 vs. “挑剔” 文化 —— 在速度与彻底性之间取得平衡。
4. 碎片化时间
- 衡量深度工作时间块（≥ 2 小时）与被会议和打断碎片化的时间。
研究（加州大学欧文分校，Gloria Mark 教授）：
- 中断后完全恢复任务的平均时间为 23 分 15 秒（2020 年）。
- 2023 年更新的“注意力跨度”研究：恢复时间约为 25 分钟；屏幕前的平均注意时长从 **2.5 分钟（2004）**下降至 47 秒（2021）。
- 如果日历数据表明约 40 %的工程产能因上下文切换（会议之间的 30 分钟死区）而损失，最廉价的生产力提升方式是取消会议。没有工具能修复破碎的日程表。
文化风险
- 指标误用： 对工程师进行排名或激励游戏化（例如，将一个 PR 拆成十个小 PR）会破坏信任。
- 黄金法则： 指标用于调试系统，而不是人。
| 坏问题 | 好问题 |
|---|---|
| “为什么 Alice 比 Bob 慢？” | “为什么 Checkout Team 的代码审查时间是 Platform Team 的两倍？是需要更好的工具还是技术债务难以管理？” |
领导者应致力于构建一个充当 中立第三方 的仪表盘，提供客观数据来验证工程师在 1:1 中的说法（例如，“我被维护工作压得喘不过气来”）。
实施指标
| 指标 | 衡量方法 |
|---|---|
| 返工率 | 跟踪代码编写所花时间与 PR 审查所花时间的对比（git 日志、审查时间戳）。 |
| 投资分布 | 使用 AI 驱动的标签，对提交/PR 按目的（维护、功能、迁移）进行分类。 |
| 审查负担 | 统计每位审查者的 PR 数量、平均审查时间和 PR 大小；与审查者的容量进行对比。 |
| 碎片化时间 | 提取日历数据（会议块），计算 ≥ 2 小时的连续不受打扰的时间窗口。 |
| AI 代码质量 | 检测 AI 编写的代码（Span 的代码级检测），并将其与缺陷密度、返工率和审查周期关联。 |
第一步： 了解实际交付了多少 AI 生成的代码。大多数团队依赖不可靠的自报调查；请改用自动化检测。
反直觉的洞见
- 这并不是要减少 AI 的使用。
- 那些指导工程师将 AI 用于完整、范围明确的任务（而不是混合人类‑AI 工作）的团队，能够取得更好的结果。
工程智能的未来
- 旧的代理（lines of code, commit counts）已失效。
- 即使是像 cycle time 这样的现代标准，单独使用仍然不足。
为了在未来几年中前行，需要理解 human creativity 与 AI leverage 之间的相互作用。衡量 AI code quality，而不仅仅是量。
采取行动
- 采用工程智能平台（例如 Span）以获取自动化、准确的指标。
- 审计你的日程——消除分散深度工作的低价值会议。
- 指导工程师有意识地在完整任务中使用 AI。
- 使用指标来调试系统，而不是对人员进行排名。
如果你准备摆脱虚荣指标，深入了解你的工程组织，请查看 Span，了解工程智能平台如何帮助团队衡量真正重要的内容。