质量 vs 速度：什么时候该妥协

一句话速记

质量和速度不是对立的——在给定的时间和人力下，你做的所有 trade-off 不是在”质量”和”速度”之间，而是在”哪些质量的哪些部分”和”哪些功能的哪些部分”之间。核心原则：① 正确性不妥协——付了钱没订单、数据丢了，这是系统在骗用户；② 韧性可分级——新功能可以先不做到 99.99%，手动恢复可接受；③ 优雅可延迟——“不够漂亮”永远不是 bug。上线决策 = 以当前的质量水平上线，出问题的后果能不能接受？

通俗解释（5 分钟版）

错误的 trade-off 思考方式：
  "PM 逼着这周上线，只能牺牲质量了。"
  → 牺牲的是什么质量？所有质量？代码乱写？测试不写？
     这种"牺牲质量"的模糊说法，导致上线后事故频发。

正确的 trade-off 思考方式：
  "这周上线的话，我们可以：
    ✓ 核心路径（下单→支付→发货）质量不变：全量测试 + 灰度
    ✗ 次要路径（优惠券校验降级时的手动恢复）：先不做自动恢复，
      出一个 runbook，oncall 人手动恢复
    ✗ 管理后台的一个筛选功能：可以先不做，下周补
    ✗ 代码可以下周重构一轮（现在有重复代码但不影响功能）
   
   所以下周能上线，风险区间是：
     - 优惠券校验挂了 → oncall 手动恢复（10 分钟）
     - 概率：过去类似模块的故障率约每月 1 次
     → 后果可接受。上。"

关键细节

质量分层

质量不是一块铁板——分层，每一层有不同的妥协空间：

层 1：安全 — 绝对不妥协
  涉及用户数据、钱、越权访问的——没有任何理由。
  再赶也不能：SQL 拼接、明文密码、越权不做校验。
  原因是：这些不是线上故障，是线上事故 + 合规风险。
  出一次 = 公司可能被罚款百万。

层 2：正确性 — 核心路径不妥协，非核心可观察
  核心路径（用户的核心操作）：不能有数据错误。
    如果订单创建了但扣款没记录，这是公司在亏钱。
  非核心路径（如用户偏好设置显示不对）：
    可以不完美，但错误必须可被发现（有日志 + 有监控）。

层 3：韧性 — 可分级
  核心路径：必须有降级 + 手动恢复方案
  非核心路径：挂了可以给用户报个错，下次重试就行
  内部工具：挂了就挂了，上班再修
  （注意：对内部工具的标准和对用户的完全不同）

层 4：完备性 — 可分期交付
  一期上线：覆盖 80% 用户场景
  二期：覆盖剩余 20%（比如边缘的设备/浏览器/地区）
  如果你要等到所有情况都完美才上线，
  你就永远上不了线。

层 5：优雅 — 可无限延迟
  代码重构、变量命名、模块拆分——这些永远值得做，
  但永远不值得阻塞上线。用 TODO 标记，下个 sprint 改。

上线前决策问题

每次上线前，TL 问自己三个问题：

1. 如果这个功能现在上线，最差的结果是什么？
   （不要问"可能"，问"最差"）

2. 这个最差的结果，我们的监控能在几分钟内发现？
   （如果答案是"不知道"或者"可能要等用户投诉" → 不上）

3. 如果最差的结果发生了，我们能在多长时间内修好？
   （如果答案是"不知道"或"可能要回滚整个服务" → 不上）

如果 3 个问题都能具体回答（具体到"3 分钟发现，15 分钟修复"），
就可以上——即使方案不完美。

不同阶段的取舍策略

0-1 阶段（新产品 / 新功能）：
  核心问题：这个东西有用户需要吗？
  质量策略：核心路径质量拉满，非核心路径可以粗糙。
  因为：你最大的风险不是"某些边缘 case 挂了"，
       是"做了 6 个月结果用户完全不需要"。

1-10 阶段（增长期）：
  核心问题：用户量在涨，系统能不能跟上？
  质量策略：开始建立质量标准——CI、灰度、监控、oncall 流程。
  这阶段投入在质量上是"省未来的时间"。

10-N 阶段（成熟期）：
  核心问题：稳定性——一次事故可能影响千万用户。
  质量策略：质量和速度的 trade-off 偏向质量。
  此时"慢一点上线"的成本低于"出事故"的成本。

延伸追问

• Q：如果 PM 施压一定要按时上线，但你知道质量不够，怎么办？ → 不争辩”不能上”。把风险翻译成 PM 能听懂的后果：“如果按现在的质量上，预期有 5% 的订单会遇到 XX 问题，每次需要运营手动处理 10 分钟。我们能承担吗？“让 PM 一起做风险评估。如果 TA 说”可以承担”，那也告诉老板——不是告状，是让老板知道这个 trade-off 你和 PM 一起做的。
• Q：怎么跟团队传达”速度优先”但又不鼓励写烂代码？ → 说清楚边界。“这周我们需要先上核心功能。代码可以有 TODO 标记——这些 TODO 在接下来两周的 sprint 里要修完。“让团队知道：快是有代价的，但这个代价有时效——不能永远欠着。
• Q：线上故障后，怎么在复盘里不让 trade-off 变成”谁批准上线的”追责？ → 如果 trade-off 是公开做的（在群聊/文档/会上明说的、后果被评估过的），出问题了是”评估的信息不够准确”而不是”某人冒进”。这就是为什么你不应该一个人在脑子里做 trade-off——把它记录下来、沟通出去，大家一起承担。

我的记法

• 质量分层：安全 > 正确性 > 韧性 > 完备性 > 优雅。每层有不同的妥协底线
• 上线三问：最差结果？多久发现？多久修复？——三个答不上 = 不上
• 0-1 vs 1-10 vs 10-N：不同阶段有不同的质量优先级
• 一句话：「质量 vs 速度不是对立——你 trade-off 的不是质量，是哪些质量在哪些路径上可以暂时放一放」

状态

• 已背速记
• 能讲通俗版
• 能答追问