前言

看到一篇讨论质量指标的文章。

文中描述了 3 个过时的不推荐继续使用的指标。

平心而论，作者认为这 3 个指标没什么用，这点我是完全赞同的。

本质就是这 3 个指标里有 2 个是过程指标，而不是结果指标。

过程指标只能说明你做了什么，而不能说明你做的好不好。

质量的结果指标是非常难去度量的，很多对结果指标的罗列只不是过隔靴搔痒而已。

所以作者的思路从度量结果指标转变成了度量最终用户的满意度。

这点非常正确，但在极度内卷的今天，没有完备的过程指标实际上会让团队及质量团队的管理者寸步难行。

所以求同存异吧。

正文

这些年，我见证过各种”专家”试图”测量”或”实现”质量。我必须承认，我感到不堪重负并想尖叫。如果这篇文章冒犯到你，我提前道歉。

质量无法被客观或全面地衡量，但可以通过代理指标和反馈评估的结合来进行判断。我坚信客户满意度——无论使用何种具体指标——才是真正反映质量感知水平的唯一参数。实现 100%的代码覆盖率或解决所有已知缺陷，并不能保证在 Play Store 或 Apple Store 等平台获得正面评价。归根结底，质量就是满足客户期望，而这些期望由于其主观性本质，本身就难以量化。

质量无法被实现。（如果无法衡量，你如何知道自己是否实现了它？哈哈）。质量是副产品。质量只能被间接追求。将质量设为主要目标现实吗？当你直接追求”质量”时，你可能会忽视那些真正促成质量的关键因素，比如需求、标准化、反馈循环、员工参与度等。相反，通过关注基础要素，质量自然会作为副产品出现。可以这样理解：你不会直接追求孩子的”健康”，而是确保他们获得适当营养、定期锻炼、充足睡眠、情感支持、在安全有爱的环境中成长等等。同理，在组织内部，有无数直接或间接影响整体质量水平的活动。

首先，我想分享个人的挑战经历，希望我的见解能给你新的视角。以下是我认为被高估的三大指标[又名无用指标]：

1. 编写/执行的测试用例数量

测试用例提升质量的方式，就像膳食补充剂增进健康一样——其实并不能，甚至可能通过拖慢进度造成伤害。我不反对检查清单，但坚决反对将测试用例作为独立产物创建或使用测试用例管理系统。作为质量经理这么说可能很奇怪，请容我解释。

大量测试用例会带来虚假的信心。专业的探索性测试至关重要，但在集成环境中执行预先编写的手动测试用例只是检查。W. Edwards Deming 说得好：”检查不能改进质量，也不能保证质量。检查为时已晚。质量，无论是好是坏，已经存在于产品中。”

让我用一个故事说明关键观点。休产假期间，我所在公司因核心团队超负荷而雇佣外包团队完成某些目标。由于没有足够时间传授质量管理方法，他们沿用原有流程。其中一项任务是为产品添加自定义标签。虽然这个功能相对较小，但对系统影响重大——这些标签出现在使用不同技术栈编写的数十个服务中。

当我回归时，发现团队正在准备大版本发布前的完整回归测试。自动化 UI 测试资源有限，我们通常的全系统回归测试周期（含修复时间）需要 1 天。但当询问时间安排时，测试工程师骄傲地展示了数百个手动测试用例（大部分重复步骤）和精美的历史执行图表。他们的回归测试预估？仅一个功能就需要 2.5 天！

关键在于：在他们的世界里，测试这样一个功能需要 2.5 天，整个应用程序的手动测试可能需要半年/次。

我决定研究该功能。花费 30 分钟调查功能与系统的集成后，发现了五个不同严重程度的缺陷。随后要求准备关键步骤检查清单和影响分析图，并同意在发布期间分配 1 小时进行回归测试。然后礼貌地请他们废弃我不在期间创建的所有内容——包括那些精美但无用的图表。

在不评判公司困难时期决策的前提下，这种情况凸显了测试用例的低效。

我们早已不再用代码行数衡量开发者绩效，但仍有公司通过测试编写/执行数量评估测试团队表现。请停止！

2. 单元测试覆盖率百分比

我在另一篇文章《可调节测试漏斗》中详细讨论过这个话题。这里简要总结：这可能不是主流观点，但我认为单元测试被高估了。当工程师批判性思考代码时单元测试很有价值，但这些测试不能保证功能按预期工作。实际上，投资集成和系统测试可能比专注单元测试更具经济效益。毕竟企业关心系统行为，而非实现细节。

先说指标。常见问题是管理者设置质量门禁（比如低于 80%单元测试覆盖率禁止合并 PR）。结果数量优先于实际质量，团队最终创建无意义的单元测试来勾选复选框。管理者骄傲报告”单元测试覆盖率提升至 95%“，却忽视这些测试的实际价值存疑（部署时间也增加了，但嘘…）。

此外，我曾”有幸”与认为测试是”单元测试”或”别人的问题”的开发者共事。这种心态导致许多问题，特别是环境差异导致的问题。你肯定听过经典借口：”在我本地环境能运行！”（我敢说单元测试覆盖了）。

当然现实中你可能遇到需要强制设置此类门禁的情况（真心希望你不会）。最终，质量关乎评估项目风险，理解团队能带来的纪律和专注程度。这正是 Jurgen Appelo 在《管理 3.0》中提到的”敏捷盲点”：

“以人为本”的理念很棒，直到你发现团队由两个巨魔、一只鹦鹉、一个理发师，和相对聪明但聋哑盲的项目经理组合。

3. 发现/解决的缺陷数量

首先，”不解决所有已知缺陷就不发布”的策略通常会导致员工偷偷摸摸和发布日期延迟，除非你身处医疗或航空等高危行业。

其次，仅看缺陷数量会产生虚假安全感。例如在小功能中修复 10 个缺陷，并不自动意味着高质量。有个测试原则叫”无错误谬误”——提醒我们无论修复多少缺陷，功能仍可能存在关键安全问题或无法满足用户需求。

此外，将缺陷作为工单提出成本很高，因为这迫使团队重复整个开发流程。有时修复后软件可能比之前有更多缺陷。错误难免发生，我们只是凡人。应该专注于预防：编写清晰的高质量需求、尽早向 QA 团队或产品负责人演示功能（在 PR 前）、建立良好代码评审规范、投资多层级回归测试自动化。

不过长期跟踪缺陷率可能有帮助。但上下文决定一切。你在同类比较吗？缺陷率飙升可能是因为新开发者加入，或团队高压加班。数字只讲部分故事。要真正改进，需同时考虑定量和定性指标，并着眼全局。

最后，有些公司为已知缺陷创建独立看板，但说实话：专用缺陷看板往往成为问题的坟墓。将缺陷纳入待办事项更有效。最好实现自动化提醒：如果缺陷三个月未解决，系统自动关闭卡片。

应该怎么做？关注驱动质量的要素

平衡速度和质量常带来挑战，导致公司做出权衡——有时为赶工期牺牲质量。因此组织必须建立与优先级一致的清晰可衡量目标，比如”在保持或提升 NPS 和 eNPS 的前提下缩短交付周期”。这样做能在异常时获得预警。例如即使 NPS 因期待已久的功能交付而提升，eNPS 下降可能暗示深层问题。当代码质量存疑时，员工很难满意交付。更多信息可参考我的文章《从成本中心到业务推动者：将质量嵌入公司 DNA》。

在关注任何指标前，组织应确定需要几个 9。没有 100%可靠的事物。这就是 1970 年代 AT&T 提出”五个九”可靠性概念的原因，确保电话系统几乎始终可用。该理念迅速成为关键系统的黄金标准，专注于最小化停机时间（通常量化为 99.999%可用性）。这常用于航空航天和医疗设备等高可靠性行业。

• 99%可用性：年停机 3.65 天
• 99.999%可用性：年停机 5.26 分钟

考虑以下因素确定系统可容忍的不可用时间：

1. 了解导致客户不满的可靠性水平
2. 分析停机对业务的影响（财务损失、声誉损害等）
3. 权衡高可靠性的成本与收益
4. 考虑公司当前阶段（初创公司可能优先灵活性和速度，成熟公司可能投资可靠性）
5. 行业监管标准
6. 竞争对手的可靠性水平

实现极致可靠性需要基础设施、流程、测试和维护的重大投资。平衡质量与创新和快速上市需求更重要。随着系统发展和客户群扩大，公司可增加可靠性投资。

确立可靠性目标后，即可开始指标讨论。指标的终极目标是通过测量开启对机会的理解。指标宜精不宜多。过多数据会导致分析瘫痪，使聚焦困难并浪费资源。应结合定性反馈和定量数据来纵览全局。定量指标提供数字洞察，但无法解释”为什么”；只有定性指标能提供确定下一步的必需洞察。调查是评估难以量化方面和识别痛点的宝贵工具。定性指标必须与定量指标对应；若存在差异，通常是定量指标出问题。员工可能在操纵指标。Karen Phelan 在《抱歉我搞垮了你的公司…》中强调：指标是手段而非目的。

“人们为指标而管理！有时甚至操纵指标！指标看板就像汽车仪表盘。如果只盯着它不看路，就会撞车！”

在讨论具体指标前，我坚决反对收集关注个人绩效的指标。这些指标常具有误导性和片面性，会分裂团队，迫使他们关注个人目标而非团队最优解，甚至玩弄系统。当然有时需要数据来决定奖惩，但有更好的解决方法。归根结底，你可以参考 Simon Sinek [卓越的绩效 vs 信任曲线]，直接问团队：”谁是混蛋？”

相较于个人指标，我专注于收集能洞察团队动态、突出工作流瓶颈且不破坏信任的数据（重申：质量是副产品）。通常将指标分为四类：

1. 如何确保客户满意度？
2. 如何加速产品交付？
3. 系统可靠性是否符合客户预期？
4. 工作方式有哪些改进空间？

如何确保客户满意度？

客户反馈是质量问题的预警系统，帮助识别风险与机会，产生可操作的改进见解，推动必要纠正措施。可通过分析客户投诉、支持请求和报告问题有效开展评估。常用指标包括 NPS、CSAT、CES、留存率、流失率等。

此类评估的终极目标是验证产品假设并回答关键问题：”我们做的是正确的事吗？”这是证据驱动管理的核心。

如何加速产品交付？

交付速度直接影响质量。更短的交付周期通过减少反馈循环加速问题识别与解决。缺乏严格流程或某些流程未自动化会导致错失机会。例如因优先级混乱，数月前产生的缺陷可能突然变成紧急问题。宝贵想法和改进可能卡在待办列表等待审核。

要加速交付，可以从测量工作流每个环节开始。许多工具能自动化此过程，但通过观察手动收集近似数据也是良好起点。像”评估时间”（从创意产生到评估的时间）能突出决策延迟。”设计交付周期”（完成设计阶段的时间）有助于识别原型设计、线框图或用研中的瓶颈。”待办事项年龄”（创意加入待办列表的时间）是检测流程停滞的另一个有价值指标。

有几个流行的工程指标能提供交付速度的关键洞察。例如周期时间和交付时间跟踪任务从开始到完成的时长（取决于团队对’开始’和’完成’的当前定义）。团队可约定跟踪”少于 N 行代码的 PR 百分比”以确保变更尽量小。监控提交频率、部署频率、构建时间和 PR 响应时间等指标有助于突出每服务的流程效率。此外，跟踪未计划工作或返工的比例能发现拖慢流程的环节。

注意分析交付时间指标时，不要过度依赖平均值。虽然平均值提供高层视图，但可能导致误解。要获得更清晰的画面，请使用百分位数指标（如 P50、P90、P95、P99）。

系统可靠性是否符合客户预期？

可靠系统还能建立信任。当用户知道可以依赖你的产品时，他们更可能坚持使用，即使替代方案更便宜。预防问题比处理重大故障的后果更容易（也更便宜）。通过整合持续监控、主动事件管理和强大安全措施，组织创建的不仅是高性能系统，更是弹性和安全的系统。

持续监控：自动化监控工具对实时跟踪应用延迟、正常运行时间、正常/峰值负载下的 CPU 使用率、长时间数据库查询等性能指标至关重要。确保设置性能阈值警报。同时监控服务依赖项以确保第三方服务/API 的稳定性。可能需要定义 SLA 并测量达标率。

事件管理：快速解决事件很重要，但应与客户预期和团队能力匹配。否则团队可能从价值驱动工作转向事件驱动工作。几个关键指标能全面反映事件生命周期：

1. 首次响应时间（FTTR）：确认事件发生所需时间
2. 平均修复时间（MTTR）：反映团队解决不同严重性事件的速度
3. 事后审查完成率（PIR）：完成事后分析的百分比

按服务跟踪事件和问题也很有帮助。如果你熟悉软件测试中的缺陷聚集原则，就知道这能揭示应用中需要特别关注的不稳定区域。

安全审计：定期安全审计对评估系统和基础设施弹性至关重要。可使用内部资源或第三方公司。ISO 27001、GDPR、SOC 2、PCI DSS 等标准提供全面指南，但无需从大处着手。小步骤也能见效——比如约定当 Sonar 等静态分析工具检测到漏洞时不合并代码。但这些行动只有在组织具有强大的安全问题管理政策并持续测量政策遵循情况时才有效。

工作方式有哪些改进空间？

这个问题将焦点转向团队协作方式。在”亚里士多德计划”中，Google 分析 180 个团队来回答”什么造就高效团队？”研究发现最关键因素是心理安全，其次是可靠性（”成员可靠完成任务并达到高标准”）。

除非你的创意和代码完全由 AI 生成，否则数字无法提供全貌。你愿意以员工幸福感为代价加速交付吗？不考虑员工在使用工具、技术、流程和公司文化时的整体体验，质量改进就不可能实现。

全面的员工参与度调查能揭示如何改进流程以及哪些改变能推动实质性改进。这是提升员工满意度和运营效率的强大工具。

例如跟踪深度工作时间（如确保员工至少有一天无会议）反映其专注力和生产力。eNPS（员工净推荐值）捕捉整体满意度和忠诚度，团队健康调查评估士气和福祉。规划准确性和自助文档可用性等指标表明员工获得的支持程度。交付顺畅度评估任务完成的无摩擦程度。参与度还与组织价值观一致性（通过调查评估）和有效一对一会议质量（员工感到被倾听）相关。最后，根据个人职业抱负制定发展计划能促进成长和动力。

无论实施何种改进，请记住约束理论：

“在瓶颈之外所做的任何改进都是幻觉。” ——Gene Kim，《凤凰项目：一个关于 IT、DevOps 和助力企业胜利的故事》

最后自问：值得测量吗？

Gregg Stocker 在《避免企业死亡螺旋》中将”数字执念”描述为”组织衰退的预警信号：过度关注财务指标，几乎无视企业不可测量的方面（如士气、文化、领导力发展等）”。

关键在于：当管理层试图测量一切时，员工最终会觉得什么都不重要。许多公司陷入这个陷阱，认为必须测量所有事物，因为这是他们唯一知道的改进方式。事实是测量需要时间、工具和精力——这是非常昂贵的过程。因此每个指标都必须有目的。开始测量前，先问：

1. 指标目的是什么？ 应指导可操作的决策。如果结果不会引发任何改变，就不值得测量
2. 现在是正确时机吗？ 内外部因素（如公司重组）可能影响数据准确性。此时测量可能浪费资源或导致误导性见解
3. 准备好根据发现行动了吗？ 如果公司缺乏根据数据调整流程/工具的能力，请考虑推迟测量

未能评估测量需求会导致观察者偏差——人们只关注易得数据，忽略隐藏的重要洞察。这被”路灯效应”幽默诠释：

警察看到醉汉在路灯下找东西。”找什么？”“钥匙”。两人找了一会。警察问：”确定丢在这？”“不，在公园丢的”。”那为什么在这找？”“因为这里有光”。

不要陷入只在容易处寻找的陷阱——确保你的测量服务于有意义的目的，并与可操作目标一致。

将注意力转向更广泛的指标

正如《2024/25 世界质量报告》建议的，质量工程需要实现范式转变：

• 超越流程效率和自动化覆盖率的测量
  停止纠结于”我们执行了多少测试”或”自动化覆盖率多高”这类表面指标。这些数字就像餐厅只统计洗碗数量却忽视菜品口味——它们无法说明客户是否真正获得了价值。

• 评估质量工程对业务目标的贡献
  建立质量指标与商业成果的直接联系，例如：

  • 客户满意度提升带来的复购率变化
  • 质量改进对客户生命周期价值（CLV）的影响
  • 缺陷预防节省的运维成本
  • 系统可靠性增强带来的品牌溢价

• 采用全链路质量视角
  开发《质量影响矩阵》追踪关键决策的质量连锁反应。例如： | 产品决策 | 架构影响 | 测试策略调整 | 运维复杂度变化 | 客户感知风险 | |—|—|—|—|—| | 引入 AI 推荐引擎 | 需要新的性能监控指标 | 增加模型漂移测试 | 需部署模型回滚机制 | 推荐准确性波动可能引起投诉 |

构建质量感知型组织

最终，质量管理的最高境界是将质量意识融入组织基因。这需要：

1. 培养质量共治文化

• 举办跨部门的”质量洞察工作坊”，让开发、运维、客服共同分析客户旅程中的质量痛点
• 建立”质量大使”制度，每个团队指定专人负责质量倡导
• 实施”质量故事分享会”，用真实客户案例唤醒质量意识

2. 打造自适应质量体系

• 开发动态质量模型，根据业务发展阶段自动调整质量阈值
  （初创期：容忍更高故障率但快速迭代；成熟期：强调稳定性和合规性）
• 创建《质量技术雷达》，持续评估新兴工具/方法的质量赋能潜力
• 实施”质量压力测试”，定期模拟极端场景检验质量体系韧性

3. 量化质量的经济价值

• 计算质量投资回报率（QROI）： QROI = （质量改进带来的收益 - 质量投入成本）/ 质量投入成本 × 100%
• 开发《质量资产负债表》，将技术债、缺陷库存等质量要素转化为财务语言
• 在董事会报告中设立质量专项章节，展示质量指标与股价波动的相关性分析

最后的思考：质量即体验

在星巴克，店员会记住常客的口味；在苹果商店，Genius Bar 提供个性化技术支持——这些企业深谙质量的真谛：质量不是产品属性，而是情感共鸣。当我们将质量从冰冷的 KPI 转化为温暖的客户体验时，才能真正实现”质量无形，润物无声”的境界。

下次当你准备测量某个质量指标时，不妨先问问：这个数字能让我们的客户会心一笑吗？如果不能，或许你正在测量错误的东西。毕竟，最好的质量指标，往往是客户眼角的那抹笑意。

原文地址

https://medium.com/@daria_kotelenets/top-3-useless-quality-metrics-and-what-to-measure-instead-0b52cb5ac77f