每天一例｜紧急需求总是插队，但我们从没认真复盘过它们
那个需求是在版本封板前被塞进来的。排期已经确认，测试在做回归，开发手里剩下的都是收尾工作，但这个需求被标记为“必须马上处理”，理由很简单.....不做会影响当前客户使用。没有人再讨论优先级，也没有人问清楚背景，排期被直接打乱，原本计划中的工作全部让路，几个人被临时拉出来加班推进。那几天大家都很清楚，这不是第一次，也不会是最后一次。
需求最终还是赶在版本里上线了。功能能用，问题解决，客户没有再反馈。从结果看，这是一次成功的紧急响应，但团队付出的代价并不小：连续加班、原本的计划被推迟、测试时间被压缩。版本发完之后，所有人都松了一口气，然后很自然地进入了下一个迭代，好像这件事从来就该这样发生。
真正的问题在于，事情到这里就结束了。 没有复盘，没有追问为什么会紧急，也没有讨论是否存在更早发现的机会。紧急需求被当成一种不可讨论的事件，只要解决了，就默认流程已经完成。它像一场突发事故，被处理掉之后，大家只想尽快回到原来的节奏，而不是回头看路是怎么断的。
久而久之，这种默认值开始反噬团队。紧急需求越来越多，正常排期不断被打断，“先插一下”“这个更急”成了常态。团队对“紧急”的敏感度逐渐下降，从最初的高度紧张，变成疲惫应付，再到后来的一种麻木接受。当一切都紧急，其实就没有真正的紧急了，只剩下被持续打断的节奏。
后来我们做的改动非常小，但很关键：每一个紧急需求上线后，必须补一次极简复盘。不写长文档，不开大会，只回答三个问题，为什么会紧急、哪个节点可以提前发现、是否需要调整流程。控制在十几分钟内，只讲事实，不讨论责任。这一步不是为了追究谁的问题，而是把“紧急”重新拉回到可以被理解、被分析的范围里。
慢慢地，紧急需求真的开始变少了。不是因为问题消失了，而是因为团队开始更早地看见问题。复盘不是为了证明谁做错了，而是为了防止同样的紧急一再发生。当“紧急”被认真复盘过，它才不会成为一种默认状态；当紧急不再被复盘，它就一定会变成常态。
