遇到麻烦先重命题，不要直接扑向解法

第一次用，别挑最复杂的组织难题。先拿一个最近反复冒出来、大家已经开始急着提方案的小问题练手。

最小闭环只要求留下四样东西：一句现象描述、一个当前题目、一张归属划分、一个带副作用检查的处理决定。

先给现场降速十分钟

不是拖延，是防止团队把第一反应误当成正确题目。

要做的不是立刻更聪明，而是先让症状、题目、归属和解法暂时分开。只要这四样不再混着说，问题质量通常就已经开始变好。

把现象写成一句最笨的话

先只写可观察到的现象：

• 客服差评在本周集中上升
• 三个版本都在最后两天延期
• 办公区下午两点后讨论声变多

故意写笨，是为了拦住"我已经知道怎么回事"的幻觉。

避开原因词和评价词。不要写"流程设计不合理"，先写"最近三次上线都在最后两天集中返工"。你写得越像摄像头看到的东西，后面越不容易被主观解释带偏。

追问两次"所以困扰我的到底是什么"

第一句通常还是症状。"客户差评多。"

再问一次。"用户在计费规则这里集中崩溃。"

多数题目只要这样追两层，就已经比原来深了很多。如果连续追两次之后还是一团，说明现场信息可能还不够——先记下几个竞争题目，不假装自己已经看清全部。

分清谁在承受后果、谁在制造条件、谁有权改结构

现场最容易搞混的是：谁最痛，谁就成了归属方。

不对。客服很痛不等于问题属于客服。项目经理很累不等于延期属于项目经理。先列清三件事：

• 谁在承受后果
• 谁在制造条件
• 谁有权改动结构

三者一分开，很多伪题目会自动塌掉。

再补一列也有用：谁有动力推动解决。因为有权改结构的人不一定最痛，最痛的人未必有改动能力。把这几层拆开后，很多本来想自己扛的事会显出"该升级、该移交、该暴露"的轮廓。

写下第一反应方案，再查它的副作用

把最想做的事写出来，然后强制补一行："如果我这样做，最大的副作用是什么？"

再补两问：

• 这个方案是在解决症状，还是在改结构？
• 如果方案成功，谁会更轻松，谁会承担新的麻烦？

只要开始问这两句，很多"看起来很爽"的解法都会露出代价。

边界清楚后，才决定做不做、做到哪

不是每个问题都值得彻底解决。有些该移交，有些该暴露，有些只该先止血。

做决定前看三件事：

• 这是不是我该负责的那一段
• 现在最值得处理的是结构还是症状
• 做到什么程度，收益已经开始小于副作用

决定一旦做出，把处理类型也写清：止血、移交、暴露、重构、还是暂时不做。不要只写"跟进"。

中途发现又滑回方案讨论了

讨论到一半大家又开始只谈方案，退回来查三件事：

• 现在说的还是最初那个题目吗
• 当前方案是在改根部还是在搬运麻烦
• 现在最急的是继续定义题目还是先做一轮止血

跑完一次最少留下：一句现象、一个当前题目、一张归属划分、一个副作用检查、一个明确的处理类型。

不是问题立刻消失才算完成——团队不再把症状、题目、责任和解法混成一团，就已经够了。