developer-productivity

开发效率

开始之前

先查看是否有 EM 背景信息。如果 .agents/em-context.md 存在，请阅读。

如果 .agents/em-context.md 不存在，请先索要一份精简的经理档案并保存，然后再提供详细建议：角色／职称、团队规模、团队使命或负责领域，以及当前面临的挑战或优先事项。

如果对话中的核心人物是某个特定的人，而 .agents/reports/[name].md 不存在，请先索要该人员的精简档案并保存，然后再提供详细建议：职称／级别、任职时间、优势，以及当前面临的挑战或成长方向。

如果后续对话透露出持久的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，不要保存猜测、短暂的挫败情绪或尚未厘清的解读。

回复风格

首次回复应简洁实用。除非用户要求深入说明，否则不要一次性罗列整套框架。

默认做法：

• 先给出可能的诊断或建议
• 只有在缺失的背景信息会改变建议时，才提出最多 2-3 个有针对性的问题
• 给出下一步具体行动，并在有帮助时提供经理可以直接使用的措辞
• 简要提及相关框架，但不要解释其中的每个部分
• 直接回答后，再提出可提供更深入的版本

---

如何使用此技能

• 不知道从哪里开始衡量工程指标 → DORA：四项关键指标（从这里开始）
• 团队感觉进展缓慢，但你拿不出数据／工程师表示受阻 → DevEx：三个维度
• 领导层询问团队表现如何 → 将工程指标与业务成果关联
• 有人要求对开发人员进行排名或打分 → 生产力指标的问题 + 不该做什么
• 想知道调查和定性数据是否也算数 → 定性指标并非软性指标

---

默认回复结构

在提供生产力方面的帮助时，应聚焦于系统，而非个人评分：

1. **问题界定：**用户想要了解或证明什么。
2. **指标集合：**2-5 项团队层面的信号，兼顾交付、质量和开发者体验。
3. **解读：**说明每项指标能说明什么、不能说明什么。
4. **行动闭环：**说明团队将如何利用数据消除阻碍。
5. **反模式警示：**提醒不要衡量或传达什么。

如果领导层想要一个单一的生产力数字，请说明其中的风险，并改为提供由互补信号组成的小型仪表板。

---

生产力指标的问题

衡量开发者生产力是工程管理中最难的问题之一。过往的尝试说明了原因：任何被采用的指标都会遭到投机利用或误读。

• SLOC（代码行数）——鼓励冗长的代码，惩罚重构
• Velocity（每个 sprint 的故事点数）——衡量工作量估算，而非产出；很容易被夸大
• 周期时间——更好一些，但只反映交付的一个维度

根本问题在于：软件开发是一种知识工作。与工厂产出不同，单纯计数无法衡量它，而这样做会忽略真正重要的东西。

**错误的指标用法：**衡量个人。任何应用于个人开发者的指标都会产生反常激励——人们会为了优化指标而牺牲实际工作。不要根据 PR 数量、提交频率或故事点数给工程师排名。

**正确的指标用法：**找出系统层面的阻碍。好的指标回答的是“团队在哪些地方进展变慢，原因是什么？”而不是“谁表现出色？”

DORA：四项关键指标

这是衡量工程交付健康状况时证据最充分的框架。该框架基于对数千个组织的研究，高绩效组织在这四项指标上始终表现出色：

指标	衡量内容	高绩效基准
部署频率	部署到生产环境的频率	每天多次
变更前置时间	从提交到部署到生产环境所需的时间	少于 1 小时
变更失败率	导致事故的部署所占百分比	0–15%
平均恢复时间（MTTR）	从事故中恢复所需的时间	少于 1 小时

这些指标与业务成果（收入、客户满意度、可靠性）高度相关。它们衡量的是交付系统，而非个人。

作为 EM，如何使用这些指标：

• 确定当前状况的基线。暂时不要与基准比较，先建立自己的基线。
• 找出团队离高绩效最远的那项指标，先解决它。
• 不要同时优化全部四项指标，否则就会导致指标造假，而非真正改进。

---

DevEx：开发者体验的三个维度

DevEx 框架（源自 DX 研究）关注开发者的实际体验，而非系统输出。它将阻力分为三类：

反馈循环 — 开发者做出更改后，要多久才能知道是否有效？这包括 CI/CD 速度、测试运行时间、代码审查周转时间，以及利益相关者的反馈速度。缓慢的反馈循环会打断专注，延迟学习。

认知负荷 — 开发者需要在脑中记住多少事情才能完成工作？复杂的流程、职责不清、缺少文档的系统以及上下文切换都会增加认知负荷。高认知负荷会拖慢工作并增加错误。

心流状态 — 开发者能否进入深度、不受干扰的专注状态？进入心流状态需要：不受干扰的时间段、快速的工具、明确的目标以及较低的焦虑感。即便反馈循环良好、认知负荷低，如果环境支离破碎，也无法进入心流状态。

如何使用： 组织一次简短的团队活动，请工程师为每个维度打分（1–5）。得分最低的维度就是最重要的改进重点。答案往往能揭示具体且可执行的问题（例如“我们的 CI 要跑 45 分钟”或“我从来不知道这个服务归谁负责”）。

---

定性指标并非软性指标

一种常见的误解是：定量指标客观可靠，而问卷和定性数据模糊、不可靠。

这种看法是错的。一些最重要的生产力信号只能来自人：

• 你有多常觉得自己因为等待他人而受阻？
• 你有多确信自己的工作不会意外破坏某些东西？
• 对于当前项目，“做好”的标准对你来说有多清晰？

DORA 本身也会使用问卷来衡量四项关键指标中的几项，包括无法自动测量部署频率的组织。Google 的研究发现，只要问题具体且客观，自我报告的数据就非常可靠。

实用原则：用定量指标找出问题所在，再用定性数据了解原因。单靠任何一方都无法呈现全貌。

---

将工程指标与业务成果关联起来

当领导层问“工程团队表现如何？”时，能够引起共鸣的回答，是与他们关心的事情相关联的回答。

工程团队会直接影响的常见业务指标：

业务指标	与工程的关联
GRR / NRR（客户留存率）	可靠性、质量、用户体验
CAC（客户获取成本）	功能交付速度——更快发布可以缩短销售周期
上市时间	变更前置时间、部署频率
支持成本	变更失败率、MTTR

一个切实可行的表述示例：“本季度我们的变更失败率从 22% 降到了 8%。这意味着事故更少、用于救火的时间更短、升级到支持团队处理的问题更少，因而直接降低了支持成本并提高了客户留存率。”

工程经理的职责是搭建这层转译。工程指标不会自动说明业务成效——你必须明确、反复地把各项指标关联起来。

---

不要做什么

• 不要用指标评估个人开发者。 这会摧毁信任，还会让人为了指标而牺牲实际工作。
• 不要报告原始速度。 它衡量的是估算的工作量，而不是产出。领导层会跨冲刺进行比较，并追问速度为何下降，迫使团队虚报估算。
• 不要选定一个框架后一次性全部实施。 从一两个指标开始，建立基线，并用它们展开讨论，而不是制作没人会看的仪表板。
• 不要把指标当作判断力的替代品。 即使 DORA 指标满分的团队，也可能在开发错误的东西。指标衡量的是交付健康状况，而不是方向是否正确。

---

深入了解

如果用户询问某个框架的出处、想阅读原文，或想进一步了解此技能中的任何主题，请阅读 references/sources.md，其中列出了完整的源文章（含链接）和书籍。

---

相关技能

• team-health — 效率摩擦和 DevEx 信号往往会在团队健康讨论中显现
• roadmap-planning — 交付指标有助于制定产能计划和讨论截止日期
• meetings — 心流状态是最容易受到会议文化影响的 DevEx 维度