开发者生产力怎么提升：用目标、信号和指标替代电子表格

很多团队的开发者生产力和研发效能改进，都是从一张电子表格开始的。

一开始，这张表可能只是用来收集几个基础数据。但很快，或者说迟早，它会演变成一个跨团队指标追踪工具。接下来，你会发现，每个团队都在追踪十几个指标，其中大部分还需要手动维护。大家定期开会讨论这些数字，却很难看出真正的改进方向。

坦率地说，这种做法很少带来理想结果。

如果你曾经尝试用电子表格解决工程效率问题，这完全可以理解。通过指标发现机会，是一种非常常见、也经常有效的方法。比如你想降低云资源成本，查看支出数据并从不同维度拆解，确实是一个合理的起点。你可以通过部门、项目、服务、环境或供应商来分析成本，从而发现范围更广、影响更大的优化机会。

当你试图提升工程团队生产力时，这种方法看起来似乎也同样合理。

但问题在于，过于宽泛的指标会分散你的精力和注意力，反而降低成功概率。当你同时查看多个团队、十几个指标时，你会看到大量有趣但相互矛盾的信息，也会看到很多必须结合具体背景才能理解的数据。

试图通过电子表格来寻找工程效率提升机会，就像让产品经理在从未与客户交流的情况下开发产品一样。

仪表盘和电子表格当然有价值。它们能提升透明度和责任感，前提是你已经知道自己想要达成什么目标。但如果你还处在发现问题、理解机会的阶段，它们通常并不擅长提供真正可行动的洞察。

推动开发者生产力和工程效能提升所需的洞察，往往不来自表格的行列，而来自与团队成员的坦诚对话。你需要了解团队层面以及整个工程组织到底是如何运转的。

提升开发者生产力前，先明确你想解决什么问题

读完这篇文章后，你应该能够建立一套设定目标的方法，用来真正推动组织层面的开发者生产力提升。

但在此之前，我们需要先弄清楚：你为什么会走到这一步？

也许你感觉事情不像过去那样顺畅了。

也许在新的混合办公模式下，你更难判断团队工作是否顺利。

也许董事会认为公司在软件工程师身上投入了大量成本，却很难理解这些投入到底带来了什么价值。

针对这些情况，我们当然可以列出一堆指标，用来验证或反驳这些担忧。事实上，只要足够努力，并征求足够多人的意见，你很快就能整理出一整张表格。

但如果换一种方式定义问题呢？

与其追踪一大堆数字来证明某个问题存在，不如先把问题重新表述成一个目标。

上述所有问题，都可以被重新表述为：

我们需要切实提高软件工程组织的生产力。

这个目标暂时还没有说明你打算如何解决问题，也没有定义如何衡量“生产力”，更没有解释问题是如何产生的，或者它在整体优先级中处于什么位置。

但这些现在都不是重点。

尽管这个目标描述仍然比较宽泛，它已经完成了第一步使命：明确我们需要提升生产力，并且需要让高层管理者真实看到这种改进。

那么，接下来应该怎么做？

请先戴上你的产品经理帽子，然后去和你的用户沟通。

任何提升生产力的项目都有用户，你的项目也不例外。你的用户，就是公司里的软件工程师。

借助工程师群体智慧，而不是只看表格

工程师用户，是你最重要的信息来源之一。

所以，先暂时放下电子表格，去和他们聊聊。

尽可能多地与不同工程师群体面对面交流，包括资深工程师、新入职工程师、产品工程师、后端工程师、平台工程师等。你当然也可以使用问卷调查，但我强烈建议至少与几个团队进行面对面交流。

因为在真实对话中，往往会出现很多问卷无法捕捉的发散性想法。

你可以使用类似这样的问题：

如果我们只能改进你当前工具链中的一个方面，你希望改进什么？

现在让开发者感到烦恼的问题，未来有没有可能变成真正的风险？

什么能帮助公司更快学习、更快验证想法？

这里需要特别强调：不要把问题设计成“在其他条件都不变的情况下，如何从工程师身上榨取更多产出”。

无论你的生产力目标是什么，都不应该以这种方式展开。

你听到的许多想法，甚至大多数想法，可能最终都会对应到技术解决方案。例如改进构建系统、优化测试、提升发布自动化、改善开发环境。

但不要忽视那些无法单靠代码解决的问题。人为因素、流程因素、组织因素、优先级冲突、跨团队协作障碍，往往同样会显著影响工程效率。

有时候，在不增加工程时间的情况下提升工程效率，反而会带来巨大的回报。对于这类跨角色、跨团队的改进，如果团队需要把任务、项目、文档、目标、日历和审批等信息统一起来，也可以借助 Worktile 这类通用项目协作系统，让沟通、决策和行动过程更透明，减少因信息分散带来的协作损耗。

目标、信号和指标：开发者生产力改进的关键框架

当你收集到一系列想法后，下一步就是选择一个方向。

它不一定非得是“最佳方案”。只要在讨论中获得了足够多的共识，它就可以成为一个很好的起点。

它可能只是某个更大计划中的一小部分。如果你是第一次尝试这种方法，最好选择那些能够较快执行、对现有工作影响较小的方案。尽量避免一开始就选择需要产品团队投入大量精力、却没有对应激励的项目，也不要选择需要超过两个季度才能完成的方案。

即使是很好的想法，如果没有基于指标的论证，也很难持续获得支持。

指标当然重要，但它们应该是经过认真思考之后得出的结果，而不是一开始就被随意堆进表格里。

在这里，“目标、信号、指标”框架会很有帮助。请注意，“指标”排在最后。

目标关注的是你想要达成的结果，而不是预设的实施方式。

信号是人们可以观察到的迹象，用来判断你是否正在朝正确方向前进。

指标是你实际衡量和汇报的内容，用来追踪目标进展。

在这个框架下，第一步是让团队共同承认：确实存在一个值得解决的问题。

第二步，是设定一个目标。如果这个目标达成，就能清楚说明你们已经朝着解决问题迈出了重要一步。

第三步，是进行一次“我们如何知道自己正在取得进展”的讨论。哪些陈述如果为真，会让大家点头同意“事情确实在变好”？这些就是信号。

最后，你才开始设计指标。

但这里需要提醒一句：如果大家已经广泛认同某个清晰信号足以说明成功，或者这项改变已经对业务产生了更显著影响，就不必为了衡量而过度纠结某些指标。

对开发流程进行指标化管理确实有很大价值，但并不是所有生产力指标都容易衡量。有些指标很难准确衡量，有些甚至根本无法被直接衡量。

很多时候，实现目标的第一步，是建立现状基线。而实际情况可能与你根据经验做出的判断不同。

所以，请始终关注最终结果，而不是指标本身，也不是某个具体策略。你的重点应该是：如何让工程师的工作更顺畅，并以此为动力提升流程可观察性，抓住真正的改进机会。

同时也要接受一个事实：量化数据有时会与你从团队那里听到的感受相矛盾。此时不要急于否定任何一方，而是进一步理解原因。

一开始，你可能很难为每项指标设定明确目标。这不仅没问题，而且很正常。

刚开始解决问题时，更应该关注趋势：它是在上升，还是下降？是在变快，还是变慢？是在变得更顺畅，还是更拥堵？

如果你决定在接下来的几个季度持续关注这个问题，就会逐渐积累足够信息，从而设定更明确的目标或可接受阈值。

如果你发现自己正在用指标来反推目标，那就停下来。

不妨想象一下：如果这件事成功了，你会在团队群里发出一条怎样的庆祝消息？然后围绕这条消息来设定目标。

研发效能改进：分布式推进，还是集中式推进？

一个非常有效的项目，往往不一定完全依赖中心化管理，也不一定完全依赖各团队自行推进。

有些组织会由中央团队统一负责指标衡量和进展追踪，但具体改进动作则由各团队根据自身情况完成。这种方式的前提是，公司充分认识到问题的重要性，也愿意给予团队足够信任。

例如，组织可以设定一个明确目标：在年底前，将整体平均周期时间缩短几天。高层领导也可以明确支持这件事，使它的优先级高于部分产品需求。

对每个团队来说，最直接的目标，就是把自己的周期时间逐步缩短到低于公司整体平均水平。最终，各团队会找到适合自己的实现方式。

这个例子说明，对于某个具体目标，到底采用集中式推进，还是采用分布式推进，完全取决于组织情况。

有些目标更适合由中央团队统一推动，例如平台能力建设、统一工具链、工程基础设施改进。

有些目标则更适合由各团队分布式推进，例如优化本团队代码评审流程、减少本团队等待时间、改进本团队交付习惯。

正确答案很大程度上取决于你的组织架构，以及你能为负责提升开发者生产力的人提供多少支持。

如果团队希望将目标、信号和指标真正沉淀为可持续追踪的研发效能改进机制，就不能只停留在电子表格或单点数据上。比如 PingCode 这类智能化研发管理工具，可以覆盖从目标、客户反馈、需求清理、评审排期，到开发、测试、发布上线和 Wiki 知识沉淀的研发全生命周期，并打通研发工具链，让过程数据、质量数据和经验知识顺畅流转，从而帮助团队更系统地发现问题、验证改进效果并提升研发效能。

开发者生产力指标如何与领导层沟通？

你用来验证某个项目进展的指标，不一定就是你向董事会或高层领导汇报时应该使用的指标。

因此，你需要主动告诉他们应该关注什么，避免他们自行选择不合适的指标，并据此做出错误判断。

你可能更关注节省了多少等待时间，但有些时间节省，尤其是流程相关改进，很难被准确衡量。

一定要抵制以活动量为导向的指标，例如“每位开发者每天完成多少操作”。你的目标不是让工程师敲更多代码，而是让他们更快学习，并为业务创造价值。

同样，也要谨慎使用纯粹基于情绪的目标。开发者满意度很重要，但你无法控制所有影响满意度的因素，有些满意度下降可能与你正在推动的项目无关。

此外，不要要求自己每个季度都向上级汇报大量战术指标。通常，两到三个关键指标已经足够。

那么，应该怎么做？

团队周期时间、生产事故数量等关键指标，有助于你管理具体工作。但如果高层过度关注这些指标，也可能导致过度反应或矫枉过正。

在设计用于展示长期总体进展的指标时，可以考虑类似“P80 开发者体验”这样的概念。

它承认你不可能让每个人都满意，但它通常能帮助你发现仍有改进空间的地方。即使 P50 体验看起来没有太大变化，P80 体验也可能暴露出一部分开发者正在承受明显摩擦。

但不要每周机械地追逐这类指标，也不要轻率设定过于精确的目标。因为很多变化很难直接归因。

如果你无法直接或间接接触你的受众，无法了解他们如何看待这个问题，你将很难推动真正的改变。

这时，需要有一位级别足够高、具备技术理解力、又能被非技术领导层信任的发起人，向高层解释开发者生产力、开发者体验和工程效能之间的关系。

这个人未必是项目的实际负责人，但他必须理解项目的技术背景，也必须能赢得业务和管理层的信任。

不要寻找唯一的开发者生产力指标

如果领导层执意要求用一个“生产力指标”衡量所有工程绩效，那么很遗憾，这件事很可能无法成功。

因为开发者生产力并不是这样运作的。

一个包罗万象的生产力指标，只会让你陷入徒劳，甚至比塞满各种指标的电子表格更糟糕。

但这并不意味着你不能在一段时间内重点追踪一个指标。

关键在于：所有人都必须清楚，这个指标具体代表什么，不代表什么。

例如，你可以在某个阶段重点追踪周期时间，因为当前最重要的问题是工作流动过慢。但这并不意味着周期时间就是生产力本身。

你也可以在某个阶段重点关注构建失败率，因为当前最大的摩擦来自不稳定的 CI。但这同样不意味着构建失败率可以代表整个工程组织的效率。

单一指标可以作为阶段性焦点，但不能成为对生产力的整体定义。

超越电子表格：与用户沟通，推动真正的研发效能提升

如果你正处于效率提升的起步阶段，很容易想要广泛撒网，寻找所有值得解决的问题。

但更有效的方法，是把目标与具体痛点以及解决痛点的思路联系起来，并制定明确目标，逐步减轻或消除这些痛点。

这可能与你以往的工作方式不同，但这正是预期之内的事。

毕竟，你面对的是人，而不是机器。

如果你刚开始采用这种方式，务必为目标和指标调整留出空间。你会边做边学，不要因为某个决定是之前做出的，就必须一直坚持下去。

这一点在战术执行上尤其重要。你应该乐于接受各种有创意、创新且简单可行的实现方式。

真正应该在较长时间内保持稳定的，是结果导向的目标，而不是具体指标或具体策略。

再次强调，你的目标不是更多代码行数、更多故事点、更多拉取请求，也不是更多部署次数。

这些都可以成为观察进展的指标，但如果你把它们作为激励目标，往往会失败。

你的目标，是让团队更快学习，并更快为业务创造价值。

在实现这个目标的过程中，最重要的一点是：始终把人放在首位。