用定性指标衡量开发者生产力：为什么企业应重视来自开发者的数据

衡量开发者生产力，一直是一项复杂而艰巨的工作。传统指标通常聚焦于开发周期、交付速度和吞吐量，但这些指标存在明显局限，也很难单独回答“开发者生产力究竟如何”这一问题。

相比之下，定性指标提供了一种更有价值的路径：通过来自开发者自身的数据，理解他们的工作状态、协作体验、交付阻碍和真实感受。对企业而言，在衡量开发者生产力和工程效能时，不应只依赖来自系统的数据，更应重视来自人的数据。

此时此刻，在某个地方，或许正有一位技术高管对团队负责人说：“我们需要一种方法，来衡量工程团队的生产力。”于是，一个工作小组被迅速组建起来，开始研究可能的解决方案。几周之后，他们提出了一组指标：变更前置时间、部署频率，以及每位工程师创建的拉取请求数量。

不久后，高级工程管理者们坐在一起，审查新建成的指标仪表盘。很快，各种问题和疑虑接踵而至。一位负责人说：“我们的变更前置时间是两天，按照这些基准来看似乎属于‘低效’，但这真的说明我们有问题吗？”另一位负责人说：“有些团队的部署频率低于其他团队，这并不意外。但我不确定，这是否真的意味着存在改进机会。”

如果你对这个场景感到熟悉，并不奇怪。许多组织都经历过类似情况，其中也包括一些海外大型科技企业。当以交付速度、部署频率等为核心的指标，无法提供管理者真正需要的洞察时，开发者生产力衡量项目走向失败，并不罕见。

不过，还有一种更好的方法。

这种方法不只是依赖速度、产出等基础指标，而是将重点放在从开发者自身获取洞察上。许多组织已经开始转向这种以人为本的衡量方式，并从中显著提升了对开发者生产力、开发者体验和软件研发效能的理解。

本文讨论的，正是定性衡量。我们将结合大量组织实践，对这一方法作简要介绍。首先，我们会定义什么是定性指标，以及如何推动组织接受并使用定性指标；随后，我们将介绍如何收集、跟踪和使用这类数据。

如今，在预算收紧、人工智能快速发展等背景下，开发者生产力已经成为企业关注的焦点。同时，随着企业希望进一步深化敏捷、DevOps、平台工程和开发者体验建设，越来越多的管理者意识到：如果没有可靠的衡量指标，就很难指导决策、识别瓶颈并跟踪改进成效。

而要做到这一点，定性衡量至关重要。

需要说明的是，本文所说的“开发者生产力”，并不是指开发者个人绩效，而是指开发者能否顺畅、高效、低阻力地完成工作。事实上，一些组织认为“开发者生产力”这一说法容易引发误解，因为开发者可能会将其理解为对个人产出的考核。因此，在实际沟通中，我们更建议使用“开发者体验”这一表述。它更容易被开发者接受，也更能体现衡量工作的真实目的。

什么是定性指标？为什么它能用于开发者生产力衡量

我们将定性指标定义为：由人提供的数据所构成的衡量结果。

这是一个偏实践的定义。在社会科学领域，“定性”本身并没有一个完全统一的权威定义，而我们在实践中见过的一些替代定义，也常常存在问题。

“指标”这个概念相对明确，但“定性”并没有那么容易界定。有研究曾指出，关于定性研究的定义有很多，但如果要寻找一个真正能够说明其“定性”特征的定义，相关文献反而并不充分。这也揭示了一个有趣的悖论：研究者似乎知道什么是定性研究，却很难给出一个清晰、统一且连贯的定义。

我们也常听到另一种说法：定性指标衡量“质量”，定量指标衡量“数量”。但这个定义并不严谨。

首先，“定性指标”本身包含“指标”二字，而指标通常意味着输出结果会被表示为某种测量值。其次，质量往往通过等级量表进行衡量，而等级量表又经常会被转换为数值和分数。也就是说，所谓“质量”在实际应用中也常常会被量化。

还有一种观点认为，只要最终输出结果是数字，就属于定量指标。例如，情感分析会输出分数，因此有人认为它是定量结果。我们同意，情感分析的输出可以是量化数据。但按照本文的定义，只要这些数据来源于人的表达、感受、判断或反馈，它仍然可以被视为定性衡量的一部分。

除了定义上的混乱，还有一些常见说法也值得警惕。例如，“软指标”这个词就不太恰当。它容易让人误以为，从人那里收集的数据不如从系统中收集的“硬指标”可靠。我们也不建议使用“主观指标”来指代所有定性指标，因为这忽略了一个事实：从人那里收集的数据，既可以是主观的，也可以是客观的。

举例来说，开发者对某个工具是否满意，这是主观感受；但开发者报告“从提交代码到上线通常需要多久”，则是在提供关于事实和事件的客观信息。

在进入具体方法之前，我们先看一个实际场景。某海外科技公司将定性指标作为开发者生产力衡量策略的核心。该公司每半年开展一次开发者体验调查，由负责技术赋能和开发者体验的团队统一组织。每次调查会随机抽取约一半开发者参与。这样一来，每位开发者每年只需填写一次问卷，既减少了问卷负担，又能确保数据具有足够的代表性。

该团队负责人曾解释说：工程师不是机器人，他们是人。只关注系统里的基础数据，并不能反映完整情况。企业需要通过更全面的方式理解开发者的整体体验。

这正是定性衡量的价值所在。

如何推动组织使用定性指标衡量开发者生产力

许多高管会天然怀疑定性指标的可靠性和实用性。即使在一些高度重视科学方法的海外大型科技企业中，也需要先克服这种偏见。

工程管理者之所以更偏爱系统指标，是因为他们习惯通过遥测数据观察系统状态。系统能记录构建时间、部署频率、工单流转和代码提交等信息，这些数据看起来清晰、客观、可追踪。但问题在于，人不是系统。衡量人的工作体验、协作阻力和生产力环境，不能完全套用衡量机器或流水线的方法。

因此，在推动定性指标时，一个重要原则是：不要把定性指标和定量指标对立起来。

我们见过一些组织陷入内部“指标之争”：一方坚持系统数据才可靠，另一方强调人的反馈更重要。这样的争论通常既浪费时间，也无助于解决问题。更好的方式，是把定性指标和定量指标视为互补工具。

定量指标可以告诉我们发生了什么，定性指标则能帮助我们理解为什么会发生，以及这些现象对开发者意味着什么。

人们反对定性数据，往往源于一些常见误解。下面我们逐一说明。

误解一：定性数据只是主观感受

传统职场调查通常侧重员工满意度、情绪和感受，因此许多工程管理者会直觉地认为，调查只能收集主观数据。

但事实上，调查同样可以收集客观信息。

例如，以下问题都可以通过调查获得相对客观的回答：

• 从代码提交到代码在生产环境中成功运行，通常需要多长时间？
• 你的团队多久会将代码部署到生产环境或发布给最终用户？
• 当生产环境出现用户可感知的问题时，通常需要多长时间恢复？

这些问题并不是在询问态度，而是在询问开发者亲身经历过的事实和事件。因此，定性数据并不等于主观数据。它既可以包含主观态度，也可以包含客观行为和事实。

误解二：定性数据不可靠

许多组织对调查数据不够信任，一个重要原因是：他们过去接触过太多设计不佳的问卷。

在企业内部，调查问卷常常由缺乏专业训练的人编写。问题可能含糊不清、引导性太强，或者一个问题里同时询问多个事项。这样的问卷当然难以产生可靠数据。

但这并不意味着调查本身不可靠。经过专业设计、测试和分析的调查问卷，可以产生准确且稳定的数据。关键不在于“调查是否可靠”，而在于“调查是否被正确设计和使用”。

有些组织还担心开发者会在调查中撒谎。确实，如果开发者认为调查结果会被用于考核个人、比较团队或追责，他们就可能产生防御心理。但如果调查被明确定位为识别瓶颈、改善体验和提升工程效能的工具，开发者通常没有动机去操纵结果。

同时，系统指标也并不像很多人想象中那样天然准确。许多组织尝试通过流水线数据衡量 CI 构建时间，结果发现，必须投入大量精力清洗数据，例如排除后台任务、处理并行任务、过滤异常运行记录等，才能得到相对可信的结果。

换句话说，系统数据也需要清洗、解释和校准。它并不天然比人的数据更可靠。

两类定性指标：态度指标与行为指标

定性指标主要可以分为两类：态度指标和行为指标。

态度指标反映人们对某一主题的感受、意见或态度。例如：

“你对当前 IDE 的使用体验满意吗？”

“你是否认为团队的代码质量处于健康水平？”

“你是否有足够时间进行深度工作？”

这些问题反映的是开发者的感受和判断，因此属于态度指标。

行为指标则关注与个人工作经历相关的事实或事件。例如：

“将一次变更部署到生产环境通常需要多长时间？”

“你多久会因为等待代码评审而被阻塞？”

“你每周大约会被多少次会议打断深度工作？”

这些问题虽然通过调查收集，但它们并不是单纯的情绪表达，而是开发者对实际工作经历的报告。

在实践中，许多技术从业者一提到定性指标，就只想到满意度、情绪和主观感受，却忽略了行为指标。事实上，在海外一些软件工程研究和工程效能实践中，行为类调查指标已经被广泛使用。

例如，某项海外 DevOps 研究长期通过调查方式收集变更前置时间、部署频率、变更失败率和服务恢复时间等数据，并据此建立行业基准。很多人可能没有意识到，这些看似“工程化”的指标，实际上也可以通过定性方法收集。

下面是几类典型问题。

变更前置时间

对于你主要负责的应用程序或服务，从代码提交到代码在生产环境中成功运行，通常需要多长时间？

• 超过六个月
• 一个月到六个月
• 一周到一个月
• 一天到一周
• 不到一天
• 不到一小时

部署频率

对于你主要负责的应用程序或服务，团队多久会将代码部署到生产环境或发布给最终用户？

• 少于每六个月一次
• 每月一次到每六个月一次
• 每周一次到每月一次
• 每天一次到每周一次
• 每小时一次到每天一次
• 按需部署，即每天多次部署

变更失败率

对于你主要负责的应用程序或服务，有多少比例的生产环境变更或面向用户的发布会导致服务降级，并因此需要补救，例如热修复、回滚、前滚修复或补丁？

• 0%—15%
• 16%—30%
• 31%—45%
• 46%—60%
• 61%—75%
• 76%—100%

服务恢复时间

对于你主要负责的应用程序或服务，当发生影响用户的服务事件或缺陷时，通常需要多长时间恢复服务？

• 超过六个月
• 一个月到六个月
• 一周到一个月
• 一天到一周
• 不到一天
• 不到一小时

能够同时收集态度数据和行为数据，是定性衡量的一大优势。

例如，行为数据可能显示：团队的发布流程很快，变更通常一天内就能上线。但只有态度数据才能告诉我们：这个流程对开发者来说是否顺畅？他们是否觉得部署过程安全、可控、低压力？他们是否担心一旦出错就会被追责？

这些感受会直接影响开发者的工作体验、职业倦怠和留任意愿。

可以用一个非技术场景来类比：假设你觉得身体不舒服，于是去看医生。医生测量了血压、体温和心率，然后说：“这些指标都正常，所以你没问题。”你一定会感到困惑，并说：“可是我确实感觉不舒服。”

开发者生产力也是如此。系统指标可能显示“一切正常”，但开发者自身的体验可能说明问题远未解决。

定性指标对开发者生产力衡量的三大优势

支持定性指标的一个常见理由是：它可以减少开发者被管理层“监控”和“衡量”的感受。与直接从代码仓库、工单系统或开发工具中提取个人级数据相比，通过合理设计的匿名或半匿名调查收集反馈，确实更容易被开发者接受。

不过，这并不是定性指标最重要的价值。

在衡量开发者生产力方面，定性指标至少有三大核心优势。

一、定性指标能衡量系统数据难以覆盖的因素

系统指标可以反映流水线、代码仓库和工单系统中的一部分状态。例如，构建需要多久、部署频率如何、工单流转速度怎样、代码评审等待时间多长。

但开发者生产力远不止这些。

要真正理解开发者能否高效工作，企业还需要回答更多问题：

• 开发者是否有足够时间进行深度工作？
• 他们是否经常被会议、临时需求或上下文切换打断？
• 他们是否能轻松理解和修改代码库？
• 他们是否能快速找到所需文档？
• 他们是否信任构建、测试和发布流程？
• 他们是否认为当前技术债务处于可控范围？
• 他们是否能够安全地提出问题和表达不同意见？

这些问题很难仅靠系统自动记录来回答。它们存在于开发者的日常体验、判断和感受之中。

技术债务就是一个典型例子。某海外大型科技企业曾开展研究，希望找到可以衡量技术债务的客观指标。研究者分析了上百个候选指标，但最终发现，没有任何单一指标或指标组合能够稳定、有效地衡量技术债务。

这并不令人意外。技术债务本质上涉及一个判断：当前系统或代码库的状态，与它理想中应有的状态之间，存在多大差距。而这个判断很难完全脱离人的经验和上下文。

换句话说，在衡量技术债务时，人的判断不是噪声，而是关键信号。

二、定性指标能弥补跨团队和跨系统的可见性缺口

工单系统和流水线指标只能展示开发者工作的一部分。大量重要工作并不会完整体现在工单、提交记录或构建日志中。

例如：

• 设计关键功能方案；
• 澄清模糊需求；
• 协调跨团队依赖；
• 指导新成员上手；
• 参与架构讨论；
• 排查复杂线上问题；
• 改善团队开发流程；
• 推动长期技术改进。

这些工作对团队生产力至关重要，但很难被系统完整记录。即便理论上可以通过更多工具和埋点收集数据，实际操作中也会遇到很多困难。

第一个困难，是不同团队流程不一致。

例如，如果企业想衡量“任务从开始到完成需要多久”，可能会尝试从工单系统中提取数据。但不同团队对“开始”和“完成”的定义并不一致。有的团队会在需求澄清阶段创建工单，有的团队只在开发开始后创建工单；有的团队会严格更新状态，有的团队则把工单状态当作事后补充。

在这种情况下，系统数据看似统一，实际含义却并不一致。

相比之下，直接询问开发者“从你真正开始处理一项任务，到它完成并交付，通常需要多久”，有时反而能更快建立可用基线。

第二个困难，是跨系统可见性不足。

小型团队可能只依赖一个工单系统和一条部署流水线，就能大致衡量服务恢复时间。但在大型组织中，一次变更可能跨越需求管理、代码仓库、CI/CD、发布平台、监控告警、事故管理等多个系统。要把这些系统打通，并形成端到端指标，往往需要大量工程投入，甚至可能持续数月或更久。

而通过开发者调查，组织可以更快获得基线数据，先识别主要问题，再决定是否值得投入更多系统化建设。

三、定性指标能为定量数据提供背景

技术团队很容易过度关注量化指标，因为它们看起来清晰、客观、直观。但如果缺乏背景信息，量化指标可能会误导决策。

代码评审就是一个典型例子。

很多团队希望缩短代码评审时间。这听起来很合理，因为等待代码评审确实会浪费时间，也可能造成上下文切换。于是，团队开始衡量代码评审耗时，并推动评审者更快响应。

但如果只关注速度，就可能带来副作用。评审者可能为了缩短指标而草率通过代码；开发者可能为了尽快合并，选择最容易批准的人，而不是最合适的专家；团队也可能忽视代码评审在知识共享、风险识别和质量保障方面的作用。

代码评审的目的不只是“快”，更是为了交付高质量软件、降低安全风险、促进团队知识共享，并避免开发者长时间被阻塞。要判断这些目标是否实现，仅靠评审耗时是不够的，还需要开发者反馈。

开发者入职也是类似例子。

如果只看新员工的首次提交时间、提交频率或工单完成数量，组织可能会误以为自己已经很好地完成了入职支持。但这些指标无法回答更重要的问题：

• 新开发者是否理解团队目标？
• 他们是否知道遇到问题该找谁？
• 他们是否敢于提问？
• 他们是否与产品、设计、测试、运维等角色建立了协作关系？
• 他们的想法是否被团队充分听见和利用？

软件开发是一项团队活动。只衡量个体产出，很容易忽略真正影响长期生产力的协作因素。

如何获取高质量定性指标和开发者体验数据

许多技术从业者低估了设计一份好问卷的难度。事实上，问卷设计涉及心理测量学、工业与组织心理学、统计学和行为科学等多个领域。

因此，组织如果希望认真开展开发者体验调查，应尽可能引入或培养相关专业能力。

以下是几条基础原则，可以帮助避免最常见的问题。

第一，问题必须清晰、具体、谨慎措辞。

一个问题只应询问一个事项。例如，“你的构建和部署流程是否快速且可靠？”就是一个不理想的问题，因为它同时询问了“快速”和“可靠”。如果受访者认为构建很快但不可靠，就很难选择答案。

第二，如果希望比较不同轮次调查结果，就不要轻易修改题目措辞。

哪怕只是轻微改动，也可能改变受访者理解问题的方式，从而影响可比性。例如，“我有足够时间进行深度工作”和“我有足够时间完成重要工作”看起来相似，但实际测量的内容并不完全相同。

第三，如果必须修改题目，就应进行必要的统计检验和解释说明。

在调查研究中，一份“好的调查”通常意味着它具备良好的信度和效度。

效度指的是：调查题项是否真正测量了你想测量的内容。信度指的是：同一题项是否能在目标人群中、在不同时间点产生相对一致的结果。

对技术从业者来说，可以把问卷作答过程理解为一个在大脑中运行的“算法”。

当一个人看到调查问题时，通常会经历四个步骤：

阶段	具体过程
理解	阅读问题和说明，理解问题在问什么，识别关键词，并将其与相关概念联系起来
检索	回忆相关经历，寻找具体事件或一般印象，并补全必要细节
判断	评估记忆是否完整、相关，整合不同信息，并形成总体判断
回答	将判断结果映射到选项中，必要时调整表达，并提交答案

如果问题表述不清，受访者在“理解”阶段就会出错；如果问题跨度过大，受访者在“检索”阶段就会困难；如果选项设计不合理，受访者在“回答”阶段就无法准确表达真实判断。

因此，开发一份好问卷，需要像设计软件一样，经过严谨设计、测试、验证和迭代。

不过，问卷设计只是第一步。真正成功的开发者体验调查，还需要解决参与率、数据分析、结果解读和后续行动等问题。

以下是一些实践建议。

按团队和角色细分结果

组织领导者常犯的一个错误，是只看公司整体平均值。

整体结果当然有价值，但它很容易掩盖具体问题。开发者体验高度依赖团队环境、技术栈、业务领域和角色类型。不同团队之间，体验差异可能非常明显。

例如，后端开发者可能对部署流程比较满意，但移动端开发者可能长期受到发布周期和审核流程影响；资深工程师可能觉得代码库尚可维护，但新成员可能觉得入门门槛很高；平台团队可能认为工具已经足够完善，但业务开发团队可能仍然觉得使用成本很高。

因此，调查结果应尽可能按团队、角色、资历、任期、技术方向等维度进行细分。只有这样，组织才能发现隐藏在平均值背后的真实问题。

重视开放式反馈

定性指标通常以量表和选择题形式呈现，但开放式文本反馈同样非常重要。

开发者在自由文本中，往往会提供选择题无法覆盖的信息。他们可能会解释某个问题为什么存在，指出某项流程具体卡在哪里，或者提出非常具体的改进建议。

开放式反馈还可以帮助组织发现问卷本身没有覆盖的领域。例如，如果大量开发者在评论中提到“文档难找”或“跨团队依赖不清晰”，说明下一轮调查可能需要增加相关题项。

如果评论数量较多，可以借助大语言模型工具进行主题聚类、摘要提取和建议归纳。但需要注意，模型分析只能作为辅助，最终仍应由熟悉组织背景的人进行判断和校准。

更重要的是，调查结束后要向受访者反馈结果。开发者愿意花时间填写问卷，是因为他们期待问题被看见、被重视并被改善。如果调查之后没有任何反馈和行动，参与率会迅速下降。

将结果与基准进行比较

单独看一个分数，往往很难判断问题严重程度。

例如，很多开发者都会对代码质量表达一定程度的不满。仅仅知道“开发者对代码质量不够满意”，并不能说明这是普遍现象，还是本组织特别严重的问题。

更有价值的问题是：

• 我们的代码质量满意度，是否明显低于其他团队？
• 某些团队的得分，是否显著低于组织平均水平？
• 我们当前结果，与上一轮调查相比是改善了还是恶化了？
• 我们与外部同类组织相比，处于什么水平？

基准比较可以帮助管理者判断问题优先级，避免把资源投入到并不关键的领域，也能帮助团队识别真正值得关注的改进机会。

在适当场景使用事务型调查

除了定期开展综合性开发者体验调查，组织还可以在特定场景使用事务型调查。

事务型调查关注开发者在某个具体流程、工具或接触点上的即时反馈。例如：

• 开发者创建新服务后，询问门户体验是否顺畅；
• 开发者完成一次发布后，询问发布流程是否清晰、安全；
• 新成员完成入职后，询问文档、环境配置和导师支持是否充分；
• 开发者使用内部平台能力后，询问功能是否满足需求。

事务型调查的优势是反馈更及时、更具体，可以帮助平台团队、效能团队或工具团队快速发现问题。

不过，事务型调查不应替代周期性的整体调查。前者适合发现局部体验问题，后者适合观察组织层面的趋势和系统性瓶颈。两者结合使用，效果更好。

避免调查疲劳

很多组织一开始调查参与率很高，但几轮之后，参与率明显下降。原因往往不是调查太多，而是开发者看不到后续行动。

如果开发者反复填写问卷，却从未看到结果公开、问题跟进或实际改进，他们自然会认为调查没有意义。

因此，避免调查疲劳的关键不是简单减少调查频率，而是建立完整闭环：

1. 明确说明调查目的；
2. 控制问卷长度和填写成本；
3. 在调查结束后及时分享主要发现；
4. 明确哪些问题会被优先处理；
5. 持续跟踪改进进展；
6. 在下一轮调查中反馈变化。

对大多数组织来说，每季度或每半年开展一次综合性调查，是相对合适的频率。某些团队也可以将更轻量的调查融入回顾会议、平台反馈或工具使用流程中，但前提是必须保证反馈真正被使用。

开发者体验调查模板

下面是一组简单的开发者体验调查题项，可用于快速启动。随着衡量体系逐渐成熟，组织可以根据自身情况扩展问卷内容。

需要注意的是，成熟组织的开发者体验调查通常并不短。有些海外大型科技企业或互联网平台的开发者调查，填写时间可能达到 20 到 30 分钟。但在初期阶段，保持问卷简洁更有利于提高参与率。

问题一

在【插入组织名称】担任开发者或技术贡献者，你觉得完成工作的难度如何？

• 非常困难
• 有些困难
• 既不容易也不困难
• 比较容易
• 非常容易

问题二

对于你主要负责的应用程序或服务，从代码提交到代码在生产环境中成功运行，通常需要多长时间？

• 超过一个月
• 一周到一个月
• 一天到一周
• 不到一天
• 不到一小时

问题三

你多久会感到自己工作效率很高？

• 从不
• 很少
• 有时
• 大多数时候
• 总是如此

问题四

请评价你对以下陈述的同意程度。

陈述	强烈不同意	不同意	中立	同意	强烈同意
我的团队遵循良好的开发实践。	□	□	□	□	□
我有足够的时间进行深度工作。	□	□	□	□	□
我对项目中的自动化测试覆盖率感到满意。	□	□	□	□	□
对我来说，部署到生产环境很容易。	□	□	□	□	□
我对团队 CI/CD 工具的质量感到满意。	□	□	□	□	□
我可以比较容易地为团队代码库做出贡献。	□	□	□	□	□
结合团队目标来看，当前技术债务水平是合理的。	□	□	□	□	□
我们会根据用户反馈持续重新审视并调整需求优先级。	□	□	□	□	□

问题五

请分享任何关于如何改进开发者体验的其他反馈。

在分析选择题时，可以使用平均分，也可以使用“最高二档比例”。

平均分的计算方式是：为每个选项赋予 1 到 5 的分值，然后计算平均值。最高二档比例则是统计选择“同意”和“强烈同意”等积极选项的回答占比。

开放式回答也必须认真分析。它们往往包含最有价值的解释、案例和改进建议。分析完成后，应将主要发现反馈给受访者，让开发者知道，他们的意见确实被看见并产生了影响。

如何结合定性指标和定量指标提升开发者生产力

定性指标和定量指标并不是互相替代的关系，而是互补关系。

定性指标通常来自调查、访谈和文本反馈，可以提供对开发者生产力和体验的整体理解。它既能反映主观感受，也能捕捉客观经历。

定量指标则具有自身独特优势。

第一，定量指标更适合高精度测量。

开发者可以告诉你，CI/CD 构建过程整体上是快还是慢，例如更接近一分钟还是一小时。但他们不可能精确报告每次构建耗时多少毫秒。如果企业需要非常精确的构建时间、排队时间或执行时间，就需要依赖系统数据。

第二，定量指标更适合持续监控。

组织通常不会每天或每周都向开发者发送综合性调查。多数情况下，调查频率最多是每季度或每半年一次。如果希望持续监控某些指标变化，例如构建耗时、部署失败率、流水线排队时间等，就需要从系统中自动采集数据。

因此，最佳方式不是在定性和定量之间二选一，而是采用混合方法。

许多组织的有效实践是：先用定性指标建立基线，识别最值得关注的问题；然后针对具体问题，引入定量指标进行深入分析；最后同时使用定性和定量指标跟踪改进效果。

例如，调查结果显示开发者普遍认为“构建太慢”。这时，组织可以进一步分析 CI 系统数据，查看构建耗时、排队时间、失败重试比例等具体指标。对于希望将这类数据贯穿研发全流程的企业，也可以借助 PingCode 这类智能化研发管理工具，打通目标、需求、项目、测试、发布、知识沉淀以及外部研发工具中的数据，让研发管理更加自动化、数据化和智能化。改进完成后，再通过系统数据观察构建时间是否下降，同时通过调查了解开发者是否真正感到体验改善。

某海外大型科技企业也曾建议工程管理者：先查看调查数据，再查看日志数据。原因很简单：日志数据只能告诉你某个数字是多少，却无法直接告诉你这个数字是好是坏、是否真的构成问题、对开发者产生了什么影响。调查数据可以为系统指标提供必要背景。

混合方法的基本路径可以概括为三步：

第一，利用定性数据发现最重要的改进机会。

第二，在明确改进方向后，使用定量数据进行深入诊断。

第三，同时使用定性和定量指标跟踪改进进展。

只有将尽可能多的数据结合起来，包括来自人的数据和来自系统的数据，组织才能更全面地理解开发者生产力。

归根结底，企业投入大量资源聘请高素质开发者，而这些人每天都在观察、感受并处理系统指标无法揭示的问题。他们知道哪些流程真正顺畅，哪些工具只是看起来可用；他们知道哪些环节在消耗时间，哪些协作正在制造阻力；他们也知道哪些改进最可能带来实际价值。

因此，衡量开发者生产力，不应只是观察系统，更要倾听开发者。

通过认真收集、分析和使用来自开发者的数据，企业能够获得过去难以获取的洞察，也能更准确地发现瓶颈、确定优先级，并持续改善开发者体验。对于希望提升工程效能和软件研发效能的组织来说，定性指标不只是补充手段，而是理解开发者生产力的关键入口。