授权把决策范围交给成员后，成员仍会带着具体问题来求助。管理者需要判断该直接介入，还是引导成员自己完成判断。这里记录辅导的具体做法。
先说触发我写这篇的场景。授权做了几周之后，来找我的人没有变少，只是问题换了一种：以前是”这事你来定”，现在是”这事我遇到个坎，你看怎么办”。
这种求助频率是我此前未遇到的。以前带 3 到 4 个人的小团队，成员大多能自己把问题想清楚，来找我讨论时往往已带着成型的方案，我要做的只是给意见；辅导不成体系，因为需求不成规模。新团队里求助变多了，每个人卡住的原因还各不相同：有的缺方法，有的缺信息，有的只是缺一个确认。同一套回应方式应付不过来。
我一开始听完就直接给方案。当时处理很快，但一个月后发现同类问题会反复出现，成员在场景变化后仍会卡住，因为他们得到的是结论而非判断过程。另一个极端我也试过，谁来找我都先反问”你觉得呢”，结果一个时间很紧的问题被我反问了两轮，成员自己摸了半天，差点误了交付（待确认：补充这次延误的具体背景）。培训的辅导模块正好对着这个问题：辅导还是直接介入，按问题本身的性质分流。
先分流：这个问题该介入还是该引导
成员带着问题过来，我先在脑子里过三个问题，再决定怎么处理。
影响面是否超出授权范围。问题还在成员自己的授权范围内，该他自己想清楚；已经波及协作方、客户或者线上稳定性，管理者要进场。
决定是否可逆。方案选错了能撤回的，值得让成员自己走一遍；撤回代价高的，比如对外承诺口径、动线上数据，先止损。
时间窗有多长。当天必须定的事，没有走完整梳理的余地；还有一两周缓冲的，正好是练判断的机会。
三个问题中任一项指向高风险时，我会直接介入，说明判断、依据和后续处理方式。介入不代表这次就白教了：事后找时间把当时的判断依据摊开讲一遍，为什么我认为不可逆、为什么这个时间窗等不起。判断依据说得出来，成员下次就能自己先分流一遍，不会什么都往上送。判断依据说不出来，只说一句”这事太急我先定了”，那这次介入就只是一次代劳。
三个问题都落在安全侧，就进入引导。
引导时用一组固定的问题帮他梳理
培训给的做法是用问题帮成员把问题拆开，我按实际用下来的顺序记成四组。
先说目标。这件事要达成什么，验收标准是什么。很多卡住的问题聊到这一步就松动了：卡住的原因是目标本身模糊，或者把手段当成了目标。有个概括性的例子：成员来说某个重构方案推不动，问下来发现他要的结果只是去掉一个重复的校验逻辑，重构是他自己加的手段，换个小改法就够了（待确认：补充这次讨论的具体项目背景）。
再说事实。已知的情况是什么，哪些是他确认的，哪些是猜测。这一步的作用是把他脑子里的东西倒出来摆平。很多问题在说的过程中自己就解了，因为他说到一半会发现某个前提根本没验证过。
然后列备选。除了他现在卡住的这条路，还有什么走法，各走法的代价是什么。只准备了一个方案来求助的，我会让他回去再想一个再来。两个方案摆在一起，比较才有对象，只对一个方案问”好不好”，容易变成让我给他的既有结论签字。
最后问风险和验证。每个方案最坏的情况是什么，用什么小动作能提前验证。验证动作要具体到他明天就能做的程度：跑一个原型、查一段历史数据、找协作方确认一个前提。
四组问题用于将模糊问题拆分为目标、事实、选项和风险。成员可以在后续问题中复用这种分析方式。
管理者要补上成员没有的那一块
用问题引导有个前提：成员缺的是梳理方法，不是信息。如果他缺的是信息，比如背景约束、之前的承诺、上游的打算，那再高明的问题也问不出答案，因为答案不在他脑子里。
梳理过程中需要判断，成员卡住的部分是管理者应补充的信息，还是成员需要自行分析的问题。管理者应直接补充团队优先级、跨团队约定和成员未知的历史决策。“你自己想办法”会遗漏这些上下文，并将信息缺失误判为成员能力问题。这与第 6 篇反馈中的第三项自检相同：先确认管理者应提供的条件。
这个判断在新团队里更难做。以前成员背景整齐，谁缺什么我大致有数，卡住多半是想岔了，很少缺信息；现在成员来自不同的项目和团队，掌握的历史上下文差异大，卡住既可能是方法问题，也可能是根本不知道某个前提。不先分辨缺哪一块，引导就容易问错方向。
还有一种情况要补的是资源。方案定了但人手不够、时间不够、依赖方排不上，这些超出成员职权的事由我去办。辅导帮助成员梳理问题，不替代管理者应承担的资源和协作协调。
谈到方案就收尾成行动
我以前容易犯一个毛病：讨论很充分，聊完双方都觉得有收获，然后没有下文。下周再来问，方案还停在讨论那天的状态。
现在的做法是，方案一出来就当场约定三件事：这个决定由谁下（通常在授权范围内就是他自己）、第一个验证点是什么时间看什么、什么时间一起回顾结果。三件事说完，辅导才算结束。验证点尽量挂在已有的节奏上，站会、周会、下次一对一，不额外发明新的检查。到点看一眼，符合预期就翻篇，不符合就把当时的判断过程拿出来对照，看是事实变了还是判断错了。
若讨论不形成行动，辅导无法产生可检查的结果，也难以支持能力发展。
把反复用到的问法整理成清单
同类问题辅导过两三次之后，我把反复用到的问法整理成一页纸的清单，放在团队 wiki 里。成员来之前先自己过一遍，过完还卡住，带来的就是一个拆过一遍的问题，辅导的起点往前挪了一截。
这里有个分寸要守住：清单里只留提问的框架，不写某次得出的答案。若将某次答案写成“标准做法”，成员可能将其套用于条件不同的新场景。小团队里这个问题不明显：人少、场景相似、答案口口相传，套错了旁边马上有人纠正。10 多人的团队里业务场景杂，写下来没人解释的答案，会被拿去套在写答案时没想过的情况上。框架的作用是让每个人自己把新场景拆开，答案每次都得自己走一遍。
辅导中的常见问题
连续追问可能被成员理解为审问，无法有效了解其判断过程。我的约束是，一组问题里他答不上来的地方，先判断是缺信息还是缺方法，缺信息我补，缺方法我示范一次这个格子怎么想，再继续往下问。
在成员缺少必要信息时要求独立决策。这条前面已经说过，这里列为误用再强调一次：它最容易被”锻炼一下”包装过去。
为了培养能力忽略交付风险。辅导有成本，成本就是时间。时间窗紧、影响面大的问题，先止损再谈辅导，顺序不能反。拿一次关键交付去换练习机会，代价由整个团队承担，这个交换不成立。
小结
辅导需要先判断成员缺少的是分析方法还是必要信息。缺少方法时，用问题引导；缺少信息时，管理者直接补充。判断错误会使引导失去作用，或使管理者只是在代答。
辅导的结果要落到明确的决定、验证点和回顾时间。这样既不会把管理者变成代答者，也能在成员缺少信息、资源或处于高风险场景时及时补位。
