需求管理

先给结论：发布记录不是"文档"，而是版本治理的账本 去年双十一前一周，我陪一家做 SaaS 的客户做发布流程复盘。运维在白板上写了一行字：v3.8.2 已上线。…

去年冬天我陪一个团队做上线复盘，会开到一半，产品负责人突然问：“三个月前把导出功能改成分页的那次发布，是哪一版？”会议室安静了大概十秒，最后是测试同学翻聊天记录翻出来的。而那次改动…

2023 年我参与过一家 600 人规模 SaaS 公司的发布事故复盘。三个季度里他们出了 7 次 P1 故障，每一次都能定位到具体服务、具体接口，但没有一次能当场说清楚三件事：这…

去年冬天，我帮一家做 B 端 SaaS 的公司做缺陷治理复盘。会议开始前，项目负责人投出一页很干净的数据：本季度缺陷关闭率 96.4%，遗留缺陷 47 条，全部为 P3。会议室里没…

2024 年 11 月，一家 600 人规模的工业软件公司，把一个原定 10 月 15 日发布的 V6.2 版本拖到了 12 月 6 日。延期 52 天，版本内容从立项时的 34 …

去年十一月，我在一家做 SaaS 的客户那里复盘他们全年 38 个版本的发布记录：11 个版本在上线后 48 小时内打了热修复补丁，占比 29%；其中 7 个补丁的根因不是代码写错…

去年冬天，我帮一家 280 人的 SaaS 公司做版本节奏复盘。翻出他们过去 12 个月的 26 个版本记录，我发现一个很刺眼的数字：对外承诺 26 次，按期发布 9 次，按期率 …

去年第三季度，我陪一个 300 人规模的研发组织做版本发布复盘。他们把过去 12 个月的发布记录摊在会议桌上，结果很难看：一个季度计划 12 次版本发布，实际按期发出 7 次，5 …

先说一个反常识的观察：把缺陷标成 P0，并不会让它修得更快。我在 2024 年复盘过一个 300 人研发团队的缺陷库，连续 11 周的数据显示，被标为最高等级的缺陷平均修复时长是 …

我复盘过自己经手的 11 个研发团队、约 4700 条缺陷单，得到一个反常识的结论：一份平均 186 字的缺陷描述里，真正能称为“操作序列”的内容平均只有 23 个字，占比 12%…