变更分级

凌晨两点，一次本该十分钟完成的版本上线，因为数据库迁移脚本与线上索引冲突，耗时四十多分钟才回滚。事后复盘时，团队发现发布清单里有“数据库变更已评审”一项，却没有人确认评审的是哪个版…

很多 PMO 在推动发布管理制度时，都会遇到同一个困境：制度文档写得非常完整，评审流程、变更控制、灰度策略、回滚预案一应俱全，但上线三个月后，研发觉得流程是负担，运维觉得制度管不到…

很多团队在复盘线上事故时，都会翻出那张发布审批单：技术负责人签了，测试负责人签了，运维签了，部门总监也签了。签字栏排得密密麻麻，但事故照样发生。更尴尬的是，那张单子从提交到签完往往…

凌晨 1 点 40 分，发布群里第七个人发来同一句话："我这边验证没问题，可以继续。"没有人说得清这句话是基于哪条监控指标，也没有人知道如果现在回滚，数据会不会…

我见过最长的上线计划有47页，包含312个任务项，精确到每15分钟一个检查点。这份计划在上线当晚的第4个小时就彻底失效了，不是因为团队不努力，而是一个没人预料到的第三方支付回调超时…

去年十一月，我陪一个约 300 人规模的研发团队做发布复盘。他们的发布流程文档有 27 页、上线检查单 43 项，写得非常认真；但上一个季度仍然出了 3 次 P1 级线上故障，其中…

去年十一月，我在一家做客服 SaaS 的公司会议室里，看他们的发布审批流。一张审批单上排了 11 个节点：产品经理、测试负责人、前端负责人、后端负责人、DBA、运维、安全、客服主管…

进度管理计划真正难的地方，从来不是“把任务拆成甘特图”这件事本身，而是当项目横跨产品、研发、测试、设计、市场、运营六个部门、上百号人、多个外部供应商时，计划赶不上变化，变化又追不上…

去年第四季度，我参与复盘了一家约 180 人规模研发组织的交付数据。那个季度他们共有 27 个任务发生延期，其中 19 个在延期之前经历过至少一次任务负责人变更，占比 70.4%。…

去年 Q4，我参与复盘过一次跨部门交付事故。一个原属硬件团队的结构件验证任务，因为原负责工程师调岗，被口头转给了软件团队的一名测试同学。三周后，这个任务在交付清单上消失了，没人认领…