Cynefin框架案例：五个问题，为什么要换五种处理方式

Cynefin框架帮助团队判断：眼前的问题适合照已有流程处理、交给专家分析、通过有限尝试学习，还是先采取行动恢复可控状态。方法本身执行得很熟练，也可能因为用错情境而无效。

这篇用一个虚构的社区维修工作坊贯穿说明。我们不复制官方框架图，而是做一份“问题—依据—行动—观察”的原创记录，检查同一个团队为什么需要不同处理方式，以及什么时候应修改最初判断。

先问处在什么情境，再挑熟悉的方法

Cynefin官方介绍强调在具体情境中作决定。官方知识库进一步说明，方法有适用边界。某种做法在一个地方有效，不代表换个问题仍应继续使用。

入门时可先区分四类情况：关系明确、已有可靠做法的Clear；需要专业分析才能弄清的Complicated；需要通过互动来学习的Complex；需要先稳定局面的Chaotic。Confused表示还没有弄清自己面对什么，不能直接当作混乱失控。

领域说明页还涉及过渡、边界状态等内容。下面只是入门案例，不把完整框架压缩成固定四格测试，也不声称通过几道题就能自动分类。

同一个工作坊，可能同时存在不同问题

假设社区维修工作坊由志愿者运营，有预约登记台、共用工作台、每周新手活动和小型材料柜。团队列出下个月要改进的事项，其中却混着很多不同层次的问题。

有人忘记自己的台位，可以查登记；两个活动反复占用同一张桌子，需要调查安排；新成员来过一次不再回来，可能与欢迎方式、时间或期待有关；现场指令冲突时，又可能需要先暂停动作。

不要把整个工作坊贴上“复杂组织”的标签就结束。把问题缩小到有用的层次：一次取号可以有明确程序，而新人是否愿意再来，未必能由同一套程序决定。

Clear：已有规则时，照规则做，也保留例外

虚构问题： 一位参与者到了现场，忘了预约的台位。登记表上有唯一匹配的姓名、时间和台位号，值班人员也有查询权限。

这种情况下，查记录、核对并指引到台位即可。每次都开一次头脑风暴，只会增加负担。产出应是一份短小的处理步骤，而不是重新发明整套流程。

但步骤要写清何时停止：出现两个同名记录、没有预约信息，或者表上位置与现场布局不一致，就不能继续假装明确。应把差异交给负责人核查，看看原有条件发生了什么变化。

因此，检查的不只是执行速度，还包括记录与现实是否一致。一个存在清单的任务，不会因为清单存在就永远属于Clear。

Complicated：关系可以调查，就认真分析

虚构问题： 两场活动反复需要同一张工作台，可排期表看起来并没有时间重叠。团队手上有预约、设备需求和布置记录，只是还没有系统对照。

经验较多的协调员发现，活动开始之前要布置，结束之后要清理，而原排期只计算了对外公布的活动时间。把完整占用区间补进去，过去的冲突就有了可检查的解释。

下一步是分析区间、修改分配，再用之前几次冲突验证。这时专业经验很有用，因为关系可以通过调查发现。让大家投票选“看起来最合适的开始时间”，不会自动修复遗漏的布置条件。

保留调查证据：看了哪些记录、缺了哪个时间段、排除了什么解释。如果新模型解释不了过去的问题，就继续查，而不是因为答案来自专家就停止验证。

Complex：通过有边界的互动学习

虚构问题： 新成员报名来过一次，之后很少再来。志愿者提出几种可能：开场让人紧张、时间不方便、不知道要带什么、活动与预期不符。改变欢迎方式，还可能改变来的人和老成员的行为。

继续把计划表做细，未必能在行动之前找到一个可靠答案。团队可以设计两个规模有限、可撤回的尝试：某几次活动由指定志愿者做简短到场交流；另几次提前发送朴素的活动预期说明。原来向人求助的渠道仍然保留。

开始之前就写好要观察什么，例如新人到场问了什么、觉得是否能参与、第二次到来是否容易些。人数变化可以提供背景，但小样本涨跌不能直接证明某个欢迎动作有效。

边界同样重要：限定活动次数、负责人、回看日期，以及参与者感到受压时的停止条件。不能因为尝试便宜，就认定失败没有影响。对受影响的人可接受、对团队可控制，才是设计条件的一部分。

可能的结果包括继续某种做法、修改它、两种都停止。即使某一组参与者反应较好，也不能推断所有未来人群都会如此。反例和不同感受应留在记录里。

Chaotic：先恢复足够的协调，再研究原因

虚构问题： 布置现场时，几份临时房间安排同时传播，几名志愿者开始相互冲突地搬同一批材料，没有人知道哪个指令有效，正常协调暂时失灵。

协调员可以先暂停搬动，确定一个沟通窗口，明确当前生效的房间安排。眼前目标是停止互相抵消的动作，而不是在干扰持续时立即解释所有排期错误。

稳定之后，再把遗留问题分开：排期逻辑可能需要专业分析；指令发布方式可能需要小范围测试；已经明确的核对事项可以形成程序。稳定行动让后续调查变得可能，但不应该成为长期的管理方式。

这里只用低风险的协调问题解释处理方式的差异，并不是事故处置指南。真实危险场景应遵循适用的安全流程和责任分工，不能拿入门管理练习替代。

Confused：先拆开混在一起的报告

虚构问题： 一位志愿者说“我们的系统太差，整个工作坊都做不下去了”。这句话可能同时指预约遗漏、新人不再来、成员分歧和一次现场协调失败。

先请大家描述具体事件：发生了什么，原来期待什么，实际看到了什么。把不同叙述拆成可检查的问题，再决定哪些已有明确做法、哪些需要分析、哪些只能先探索。

不必靠多数票把整个局面塞进一个领域。投票可以记录大家的判断，不能把尚未知晓的因果关系变成已知。暂时写“尚不能确定”是可以的，但要同时留下下一步怎样获得证据。

用一份会变化的记录承接判断

下面的表不模仿官方框架图，只保存这次行动的依据与回看问题。

每行补负责人和日期。新证据推翻依据时，行动也要随之改变，而不是只改标签。保留旧版，可以看见团队为什么调整，避免把事后知道的结果写成事前就掌握的知识。

三个容易把框架用偏的地方

第一，把Complicated理解成“大型任务”，把Complex理解成“大家还不够努力”。在案例中，增加排期分析对占用冲突有用，却不保证能解释人们不断变化的归属感。

第二，把任何小改动都叫实验。一个能带来学习的尝试，要有问题、观察信号、边界和回看。如果从不考虑停止条件，只反复执行偏好的方案，就很难知道自己究竟学到了什么。

第三，把昨天有效的做法提升成普遍规则。一次欢迎谈话让某组人舒服，也可能让另一组人感到被打扰。即使是明确的操作程序，也要留例外出口；复盘时记录的是成立条件，而不只是成功故事。

让下一次讨论落到可检查的行动

Pugh矩阵适合在比较方式确实适用时，把明确方案按准则评估；名义小组法可以征集并排序成员的优先事项。它们本身不能证明团队已经正确理解情境。

挑一个尚未解决的问题，在无限白板上做出上面的记录。在CodePic中可以手工摆放文本、形状与连接线，行动后再回到同一份材料。这里不提供官方认证、专业评估或自动领域分类器。

下一次开会，重点回答“观察到什么，使我们需要改变处理方式”。如果暂时没有证据，就保留不确定性，把调查再缩小一些，让下一步能够实际执行并回查。