5 够好即可的软件

把质量写成用户参与的需求合同，用阈值、代价和验收边界决定当前版本是否够好。

学习目标

能把“5 够好即可的软件”中的质量拆成用户目标、质量属性、场景、最低阈值和验收方式
能用“提示8：将质量要求视为需求问题”与用户共同排序质量、时间、功能和可靠性的取舍
能在质量延期或静默降级出现时记录代价、批准人、停止规则和回归证据，而不是用“够好”结束讨论

为什么 5 够好即可的软件不是降低标准

“5 够好即可的软件”讨论的是有限资源下的质量决策。没有任何系统能同时把所有质量属性做到最高，真正危险的是团队假装没有取舍：把不可接受的风险藏在“先上线”，把用户未同意的降级写成默认，把延期成本推给未来维护者。

“够好”必须由场景和用户定义。一个内部报表可以接受较长延迟，一个支付确认不能悄悄丢失；一个早期原型可以暂时缺少自动化导出，一个涉及权限的数据系统不能省略审计。质量不是开发者独自决定的实现细节，而是需求合同的一部分。

Quality Requirement 让“质量”进入需求讨论，要求写出谁需要什么结果以及失败会造成什么影响。

Quality Context 防止把一个场景的阈值复制到所有系统；没有上下文，数字看起来精确却无法指导取舍。

Minimum Bar 不是平均目标，而是不能被静默越过的底线。越过后要暂停、回退、缩小或升级。

Tradeoff Record 让团队在下一次复盘时知道当时知道什么、谁做了决定、哪些条件尚未验证。

User Acceptance 不是一次礼貌演示。用户必须知道限制、替代方案和风险，才能确认“当前够好”是否成立。

把质量变成需求

先描述用户结果

不要从“接口延迟必须很低”开始，而要说明谁在什么场景完成什么任务，延迟、错误、恢复或数据丢失会怎样影响他们。用户结果决定哪些质量属性真正重要。

再定义质量上下文

提示8：将质量要求视为需求问题要求把 Quality Context 放回讨论：用户类型、峰值、数据敏感性、法规、设备、依赖、时间和发布阶段不同，Minimum Bar 也可能不同。

最后协商取舍

排序质量属性，写出 Tradeoff Record：本版本保证什么，暂时不保证什么，延期代价是什么，谁批准剩余风险，何时重新评估。没有 User Acceptance 的静默降级不能被称为“够好”。

先预测：团队说“性能以后再优化”时，最先应追问的是使用场景、最低阈值、延期代价还是用户批准？写下排序，再把它变成质量需求表。

质量合同与验收链

提示8把质量从开发者私下取舍带回需求、上下文、阈值和用户验收。

一条质量链是 用户目标 → Quality Requirement → Quality Context → Minimum Bar → Tradeoff Record → User Acceptance。每一步都要有责任人和拒绝条件：需求不清就不能测，场景不清就不能复制阈值，底线未定就不能谈“够好”，取舍未记录就不能把延期当免费。

质量合同应允许拒绝当前版本。拒绝不是失败，而是让风险在仍然可控的范围内被看见。若用户接受的是“可用但不满足某项高级能力”，这个限制必须进入发布说明、监控和下一次计划。

三步够好决策路径

分步1 / 3

先写用户场景与质量属性

确定用户、任务、数据和影响，列出可靠性、性能、安全、可用性、可维护性等 Quality Requirement，补充 Quality Context。

提示8把质量从开发者私下取舍带回需求、上下文、阈值和用户验收。

阈值不是装饰数字

“够好”需要场景、底线、代价和用户知情确认，不能由平均指标或沉默替代。

Minimum Bar 要能被观察和行动。比如支付确认场景可以要求：成功交易有可追踪确认，重复提交不造成重复扣款，异常时用户得到明确状态，审计记录完整。性能阈值要说明分位、峰值、数据规模和观察窗口；安全阈值要说明拒绝条件和应急响应。

不要把所有指标平均化成一个分数。一个平均延迟很好看的系统，如果高风险用户在峰值时持续超时，不能用平均值掩盖问题。够好是逐场景的合同，而不是一个漂亮总分。

取舍、延期与静默降级

提示8把质量从开发者私下取舍带回需求、上下文、阈值和用户验收。

延期不是天然错误，静默延期才危险。可接受的延期包含：明确缺什么、谁批准、用户如何被影响、补偿措施是什么、何时复评、超限后如何停止。把限制写进用户可见的行为、监控和运行手册，团队才不会忘记剩余风险。

quality_contract:
  unit: tpp20-topic-05-good-enough-software
  claim: 够好必须由用户在具体上下文和底线下确认
  scenario: 支付确认与重复提交
  quality_requirements:
    - 不重复扣款
    - 状态可追踪
    - 审计可重建
    - 异常可恢复
  minimum_bar: 重复提交不产生第二笔扣款，异常状态在观察窗口内可解释
  tradeoff: 延后高级报表，不延后幂等、审计和失败提示
  acceptance: 用户代表在正常、峰值、依赖失败场景确认
  decision: 接受、缩小、回退或升级

选择与拒绝矩阵

评审问题	可以接受的证据	应拒绝当前判断的信号
需求	Quality Requirement 说明用户结果和质量属性	只说“质量要高”，不说明谁需要什么
上下文	Quality Context 固定场景、数据、峰值和约束	把一个场景的指标复制到所有用户
底线	Minimum Bar 有测量、窗口、责任人和触发动作	用平均数掩盖不可接受的边界失败
取舍	Tradeoff Record 写批准人、延期代价和复评	用“以后优化”隐藏风险转移
验收	User Acceptance 包含限制、拒绝理由和真实场景	只有开发者演示或默认同意
决策	失败时可缩小、回退或升级	因为投入已发生就继续越过底线

常见误区

本章回顾

掌握 5 够好即可的软件，不是学会为不完整系统辩护，而是能按提示8把质量当成需求问题：明确 Quality Requirement，固定 Quality Context，设定 Minimum Bar，记录 Tradeoff Record，让 User Acceptance 在真实和边界场景中确认当前是否够好。任何未获同意的静默降级都应被拒绝。

可验证练习

练习

本组练习覆盖 5 够好即可的软件 和 提示8：将质量要求视为需求问题，要求提交质量需求、阈值、取舍记录和用户验收。

问题 1： 支付系统本周必须上线，哪些质量不能只写“以后优化”？

问题 2： 如何实践“提示8：将质量要求视为需求问题”？

问题 3： 用户演示通过，但峰值场景越过最低阈值，是否算够好？

名词解释

本章出现的专业名词，用大白话再讲一遍。

Quality Requirement: 在具体场景下对用户、系统和组织质量结果的可观察期待。
Quality Context: 决定质量阈值含义的用户、数据、时间、法规、设备和依赖环境。
Minimum Bar: 当前场景中不可接受被静默越过的最低质量边界。
Tradeoff Record: 记录质量取舍、延期代价、批准人和剩余风险的决策工件。
User Acceptance: 用户或授权代表根据场景和阈值确认版本可接受并保留限制。

前后导航

来源与改写范围

Pragmatic Programmer 作者页面：核对 Topic 5 和提示8的版本位置与主题范围。
中文目录页面：核对 5 够好即可的软件与提示8：将质量要求视为需求问题的公开目录范围。
出版社书目信息：交叉核对中文译本的出版信息与版次边界。