# Cynefin模型
Cynefin框架是一个概念性框架用于辅助决策，由戴夫·斯诺登在IBM全球服务部工作时于1999年创建。它是马克斯·博伊索特的I-Space知识模型一种实现，其他实现还有用于DDD战略设计的Wardley的地图模型。
最有效率的领导者知道解决问题并不是“一刀切”的过程。他们知道自己的行动取决于上下文情况，并且通过适应不断变化的情况来做出更好的决策。但是您如何知道在特定情况下应该使用哪种方法？以及如何避免做出错误的决定？
Cynefin框架可通过评估发现的上下文情况来帮助您做出更好的决策。
简单（Simple）场景：代表了已知的知识。
意味着已经有一些现成的规则或最佳实践（Best Practice）存在，状况是稳定的，因果之间的关系是清晰的：如果做X就会得到Y。这种情况下决策者可以采用的策略是：感知（sense）–分类（categorize）–响应（respond）。例如：确定事实（感知），进行分类（分类），然后采取现有规则或者最佳实践进行处理（响应）。这个场景虽然简单，但是领导者要注意过度的简化或者自满（导致不再思考）也会导致事情从Simple场景顺时针转化为混乱的场景。所以，如果事务总是处于简单场景下，也要建议领导者提供一个反馈渠道便于不用看法的员工可以反馈真实情况（如过度自满）。
繁杂（Complicated）场景：由已知的未知组成。 因果关系需要分析或者专业知识，存在很多的正确答案。在这样的场景下，建议领导者采用感知（sense）–分析（analyze）–响应（respond）的方式来处理问题，也就是先评估客观事实，然后分析完毕后，采用比较合适的较好实践来解决问题。比较形象的比喻是深蓝计算机每进行下一步移动时都要经过仔细的分析每一种可能的后果。
复杂（Complex）场景：代表了未知的未知。 因果关系只能通过事后回顾才可能推断出来，并且有可能不存在正确的答案。“指导性的方案可能会出现，如果领导者可以进行一些允许失败的实验”。Cynefin框架建议在这样的场景下采用 探索（probe）–感知（sense）–响应（respond） 的策略。对于类似于战场、市场、生态系统、公司文化这样的复杂系统，一般采用管它三七二十一刺激它两下或者把它大卸八块看它如何反应的方案。（对于大多数的创新公司都会面临这样的场景，所以学习如何在这样的不确定场景下生存成为了当今领导者的必修课）
混乱（Choatic）场景：因果关系是不清晰的。 在这样的场景下，信息非常困扰以至于不能采取理性的相应措施，那么唯一正确的行为就是采取行动（任何行动）。建议领导者采用行动（act）–感知（sense）–响应（respond）的策略。也就是行动起来建立秩序，感知稳定来源，然后转变混乱场景为复杂场景再进一步采取行动防止危机出现或者找到新的机会。
失序（Disorder）区域：在中间的黑色区域。 这时候的状况不清楚应该属于哪个场景，领导者们意见冲突、派系林立、观点杂乱无章。这时候摆脱这个区域的策略是将问题分解后归属与不同的场景分别采取对应的策略进行处置
# 模型应用
# 简单情景：最佳实践领域
简单情景的特点是稳定，而且所有人都能轻易辨别其中明确的因果关系。正确答案往往不言自明而且无可置疑。在这个“众所周知的已知”领域中，决定不会受到质疑，原因是各方的理解相同，几乎不存在变数的问题。
如果一个问题的因果关系非常明了和单一，则这个问题就是一个简单问题。大家对于这个问题的原因有着统一的不言而喻的理解，这个问题的发生原因非常的确定，几乎没有什么变数，即“知道的知道”。
比如，在一个炎热的夏天回到家里，发现房间里也被太阳晒的热烘烘的。这种情况下，我们几乎不假思索就会打开空调，房间立马就凉快下来了。所以对于房间很热这个问题而言就是一个简单问题，可以迅速的找到解决问题的方式。
简单问题，一般的处理方式是：了解-归类-响应。
归类是人类最擅长的处理问题的方式。当遇到一个问题时，首先我们会将这个问题在自己的大脑中进行快速检索，如果这个问题被大脑判断为是一个熟悉的问题，那就调取相应的经验库并在这个经验库中找到匹配这一类问题的答案。这个“类”就是所谓的pattern，它是人的大脑在经验积累的过程中不断对问题进行抽象、分解、简化而形成的。因此，简单领域的问题一般也都会有一些最佳实践。
但是在这个问题域需要警惕落入思维范式的陷阱。大脑在思考问题的时候往往是很偷懒的，本着能不思考就不思考的原则，有时候会拿着pattern去套问题，不管这个问题是不是真的能够被归类。部分大企业管理者经常会通过做冥想来回顾一整天所做的决策，就是为了避免落入思维范式的陷阱，提醒自己不要被偷懒的大脑所蒙蔽。
# 复合情景：专家的领域
和简单问题不同，一个繁杂问题的因果关系往往不是单一和清晰明了的。也就是说，一个繁杂问题可能是由多个原因造成的，并且这些原因并不直观。相比于简单问题可以依赖经验库快速检索、归类找到答案。繁杂问题往往没有经验积累，无从归类。所以遇到这类问题，需要进行分析，即：了解-分析-响应。
一个典型的繁杂问题的场景就是Debug。在生产环境上报出bug之后，开发需要进行问题复现、审查代码、调试、根因分析等等一系列动作之后才能找到原因，而且可能还不止一个。
奔驰车主发现发动机异响后送修4S店，技师进行拆解找到问题，更换零件最终修复。这个问题也是繁杂的，一开始包括技师在内谁也不知道为什么发动机会有异响，是在一层层拆解，打开发动机，找到破损零件之后才定位到问题。这个问题原因的追溯是需要分析过程的，因果关系不是显而易见但是确实存在，即“知道的未知”。这是繁杂问题的特征。
前面说到，繁杂问题一般是新的知识领域的问题，没有经验积累。但是注意，经验是依赖于人的，是相对主观的。也就是说同样一个客观存在的问题对于不同人而言可能是不同域的问题。比如，车辆故障对于刚入行没多久的技师而言是一个繁杂问题，但是对于工作了10多年有丰富经验的技师来说这个问题可能就显而易见，是一个简单问题。所以在这个领域，专家意见尤为重要。
# 复杂情景：规律自行浮现领域
复杂问题的因果关系是事前不可预知的，这个因果关系是不稳定的，即“未知的未知”。这种情况下，解决问题往往没有标准正确答案。
复杂问题跟繁杂问题的区别就像是由零件组成的汽车和由人组成的团队。汽车构造虽然很繁杂，但是拆解之后还是能原样组装回去。任何一个零件的破损可以预测会导致什么样的问题产生，它虽然繁杂但却是一个稳定的静态结构。而团队则不同，人的行为难以预测，更别说团队的组织行为了。团队是一个动态的整体，其中某个队员的一个行为，我们难以预测会对整个团队造成什么影响。
典型的场景，比如在进行团队retro的时候发现这次生产环境无法登陆的问题，可能追根溯源是某个开发在部署的时候配置文件有误造成的。但是为什么这个开发会把配置文件搞错，是因为粗心？还是流程不到位？甚至有没有可能就是这个开发被个人家里的事情所扰，工作状态不好才导致这个问题的呢？即使采取改进措施解决了这次的问题，能否在以后杜绝该类问题的发生？我们发现这里有太多的不确定性。
于是解决复杂领域的问题，就不能单纯靠还原论的解题思路。一个复杂的动态系统整体远大与构成该系统的各个部分之和，同理一个动态系统的问题也不能单纯通过分而析之的方式来解决。
解决这类问题的思路是：试探-了解-响应。
如果可以进行“输得起”的试验，指导性规律就会浮出水面。正是出于这个原因，不必冒进试图采取一系列行动，而是要耐心等待前进的道路自行显露。首先须探寻，然后了解情况，并做出响应。也就是说，这时候的解决方案是经过不断试探之后“涌现”出来的，而非精心设计出来的。
另外一个典型的例子是美国总统特朗普的“推特治国”。对于特朗普而言，他所面临的问题大多是复杂领域的问题，因此他非常精明地采取了probe的方式，即先发一条twitter进行试探，然后看看舆论走向，根据反馈再来调整自己的方案。
# 混乱情景：快速响应领域
如果一个问题的因果关系不可知，完全无法了解问题发生的原因，或者问题的原因太过多变，那么就属于混乱。这个时候，寻找问题答案已经变得没有意义，首要任务是及时止损。迅速采取行动，尝试将所处领域转变为其他领域。
在混乱情景下，寻找正确答案毫无意义，原因在于根本无从确定因果关系，因为它们总是在变化，而且不存在可管理的模式，只有混乱。这是不可知的领域。2001年的“9.11事件”就属于这个类别，此时领导者的首要任务不是发现规律，而是“止血”。领导者必须首先采取措施来建立秩序，然后发现哪里存在稳定性以及哪里缺失稳定性，进而予以应对。具体方法是将局势从混乱变为复杂，进而在复杂情景下识别出自行浮现的模式，这既有助于防止今后的危机，也有助于发现新机会。最直接的自上而下或“广播式”的沟通势在必行，根本没有时间提出“输血”的要求，只能止血。
