先说结论：我不太信“小步快跑”这四个字。至少在我们那个 12 人的 SaaS 团队里，它差点把后台权限系统跑成麻花。我们做门店巡检 SaaS，后台 2.3 万企业用户，日活 6800，付费企业 870 家。2021 到 2023 年，我一共跟了 47 个版本，最密的时候 Q2 发了 11 个版本，平均每 8 天一个。当时觉得自己挺敏捷，后来拉数据一看，63% 的需求上线 30 天后没人用，还有 7 次因为权限和计费改动回滚。问题不在需求评审，也不在开发速度，而在我们把所有迭代都当成同一种东西。
我后来的做法很简单：不按需求列表排期，按“可逆性”分层。可逆需求是改了能撤回、撤了没数据后遗症的，比如文案、排序、运营位、埋点。半可逆需求是能撤但有点脏的，比如新增 API 字段、缓存 key、webhook、通知模板。不可逆需求是撤了要洗数据、改账单、补权限的，比如数据库表结构、权限模型、计费口径、账号体系、数据删除。这个分类很土，但它救了我们后半年的版本节奏。
对比一下以前和后来：以前是版本列车，固定两周发车，老板插队也塞进去，上线即完成，回滚靠运维手动 SQL。后来是可逆性迭代，A 类 1-3 天发，B 类 1-2 周发，C 类 4-8 周单独走变更单，必须带灰度、双写、影子表和回滚脚本。以前复盘看上线数量、工时、加班时长。后来复盘只看决策质量、回滚次数、护栏指标。上线数量从 KPI 里删掉后，季度需求吞吐反而涨了 18%，因为没人为了发版而发版。
| 维度 | 版本列车（以前） | 可逆性迭代（后来） |
|---|---|---|
| 排期依据 | 需求列表+老板插队 | A/B/C可逆性分层 |
| 发布节奏 | 固定两周，所有需求挤一起 | A类1-3天，B类1-2周，C类4-8周 |
| 灰度 | 全量或10%一天 | 1%/5%/10%/25%/50%/100%，每层24-72h |
| 回滚 | 运维手动SQL | 功能开关+双写+影子表，目标15分钟内 |
| 复盘 | 上线数量、工时 | 决策质量、回滚次数、护栏指标 |
具体步骤我按我们踩坑顺序写：
1）给每个需求打 A/B/C 标签。A 可逆：文案、颜色、排序、运营弹窗、埋点。B 半可逆：API 新增字段、缓存 key、第三方 webhook、通知模板。C 不可逆：表结构、权限模型、计费口径、账号体系、数据删除。规则只有一条：C 类需求不准塞进两周 sprint，必须单独写变更单。
2）版本火车只拉 A/B。每周二发 A，隔周周四发 B。C 类走变更委员会，成员是后端负责人、DBA、测试、产品、客服。变更单必须写清楚：影响哪些表、回滚脚本、数据修复方案、负责人。没有回滚脚本，不准上。
3）灰度别凭感觉。我们的比例是内部员工 1%，种子客户 5%，然后 10%、25%、50%、100%。观察窗口：1% 和 5% 看 24 小时；10% 和 25% 看 48 小时；50% 看 72 小时。护栏阈值：接口错误率 >0.5% 停；P95 延迟 >800ms 停；支付成功率下降 >0.3% 停；核心转化率下降 >5% 停；客服工单量增加 >20% 停。只看 DAU 会死得很惨。
4）埋点最多 3 个核心指标 + 2 个护栏指标。核心看功能使用率、任务完成率、次周留存；护栏看崩溃率、接口错误率。命名用 feature_version_action_result，别用 click1。事件属性至少带 user_id、company_id、plan_type、version、ab_bucket。我们之前用 button_click，47 个版本的数据混在一起，清了两周才分清。
5）复盘每周五 30 分钟，只问四个问题：哪个决策错了？回滚了几次？哪个指标没动？下个版本少做什么？不评工时，不评加班。负责人轮流讲，讲错不扣钱，但同一个错犯两次要写进变更单模板。
工具上我们没用什么高级货。需求用 Linear，功能开关用 Unleash，错误监控用 Sentry，看板用 Grafana，行为数据用 Mixpanel，账单对账用 Metabase。真正有用的不是工具，是“不可逆需求”这四个字带来的刹车。产品迭代的真实成本不是开发工时，而是不可逆决策的利息。你发一个 C 类功能，代码可能两周写完，但后面每个月都要还利息：数据迁移、兼容逻辑、客服解释、测试用例、权限补丁、报表口径。2022 年我们把计费单位从“门店数”改成“设备数”，代码两周上线，后面 7 个月都在修发票、对账、权限和报表。如果按可逆性分层，这个需求应该先做影子计费，跑 60 天，新旧账单差异 <0.1% 再切。我们当时直接全量，结果 13% 客户账单异常。
所以我的独立观点是：产品迭代不是比谁快，是比谁错得起。大多数团队不是被慢拖死的，是被不可逆功能拖死的。把需求分成 A/B/C，把 C 类当房贷一样审，把回滚当第一功能，把上线数量从 KPI 删掉。这事不高级，甚至有点笨，但我用 47 个版本换来的教训是：能撤回的迭代，才配叫小步快跑。我也没完全做到，C 类需求偶尔还是被老板塞进火车，但至少现在我们会为它单独留一节车厢。