GitChat·技术管理 | Cynefin 框架和不确定性管理思维

GitChat 作者：吴穹 AdamWu
原文： Cynefin 框架和不确定性管理思维
更多IT技术分享，尽在微信公众号：GitChat 技术杂谈

Cynefin Framework

Cynefin框架是由威尔士学者Dave Snowden提出，它以人、体验、情境之间的关系为基础，描述了五种不同的情境类型以及相应的解决方案（如图所示）。Cynefin 是威尔士语，读作[kεv]，它字面上的意思是“栖息地”，但它真正的含义是一个孕育你的环境（例如：文化，宗教，地理位置，种族等等）。

Cynefin框架帮助管理者了解组织所处的情境，注意危险讯号，避免执着于以往偏好的管理模式而犯下错误。同时强调在现实中，一个组织内部往往多类情境并存，管理者需要将其进行拆分，根据每个情境的特点采用适当的决策方式。这五类情境分别为：

这种场景就好像一个习惯了在地中海航行的舰队，被派去探索没有海图的美洲大陆，这是精确到天的确定性的航海计划和里程碑会害死这只舰队。在历史上，这种例子并不少见，像南北朝时的宋文帝刘义隆的元嘉北伐。刘义隆应该是个不错的管理专家，他继续实行父亲刘裕的治国方略，在东晋义熙土断的基础上清理户籍，下令免除百姓欠政府的“通租宿债”，又实行劝学、兴农、招贤等一系列措施，使百姓得以休养生息，社会生产有所发展，经济文化日趋繁荣，史称元嘉之治。但是，不幸的是他将他的确定性管理思维应用到了战场上，“遥制兵略，至于攻日战时，莫不仰听成旨”，可以说是以严格执行战役计划的方式去打仗，结果“元嘉草草，赢得仓皇北顾”。

在这种情况下，如果产品经理请研发承诺一个特性的上线时间，那么研发的初始反映是给出150天承诺，即便有85%的可能性可以在60天内交付。于是“合同游戏”开始了：

产品经理：“150天太离谱了吧，这个特性哪有那么复杂

研发经理：“你不编程序，你不懂，这个功能很复杂的，要给很多处程序的”

。。。

产品经理：“我之前也做过研发的，别唬我”

研发经理：“你那时候技术简单，现在技术好复杂的”

。。。

产品经理：“领导要的急呀，再想想办法吧”

研发经理：“要不100天

产品经理：“那就100天吧，不要延期哦，尽快开始哦”

。。。

新开发同学：“经理，这个功能应该45天搞定了吧，用不了100天吧”

研发经理：“哎，我们这边环境复杂，你还不懂，慢慢你就明白了”

在付出了“合同游戏”的扯皮成本之后，这种确定性估算承诺制度的恶果才刚刚开了个头。既然承诺了100天完成，就没有60天交货的道理了。那就先派一个新同学投入这个项目，其他同学可以投入其他项目。这样的做法无形中扩大了团队的并行工作数量，减慢了反馈速度，最终造成项目成本攀升。而某些不幸时间可能导致这个项目在80天出现了风险，最终120天才能交付，被业务投诉，这样研发团队吸收的教训会是未来进行更保守的预估和承诺。

从某种程度来说，这个确定性估算和承诺问题和项目管理思想（PMP）被滥用有很大关系。项目是指为完成某一独特的产品或服务所做的临时性努力，临时性是指项目有确定的开始日期和结束日期。目前的大多数企业是在做产品开发，但是其中的产品特性却被当成一个个项目来管理，被要求需求一出来就要明确启动时间和结束时间，这种确定性管理方式的误用是需要创新型企业陷入混乱的根源之一。在《精益企业》一书中作者也表达了相似观点，“传统的IT项目管理模式不适合快速的创新周期。然而这些传统模式却深深地根植在管理的方方面面，从运营、客户服务到预算、治理和企业 战略，无不如此。在最近十年里，支撑在大型组织中采用以产品为中心的管理范式的 各种元素悉数出现，但它们并没有以一种系统化的方式贯通和展现出来。”。

确定性资源分配

这种任务可以精确估算的“钟表研发”式思想导致的下一个行动，就是试图对人力资源进行确定性的管理。这其实是一种农耕思维的延伸，保证每块地上都种上尽可能多的庄稼，却能确保最好的收成。现在管理者把团队日程表的一个个空格当成一块块田地，管理者的职责变成要保证每个空格都要填满。在DonReinertsen的《ThePrinciples of ProductDevelopment Flow》一书中指出，根据参与他培训的管理者的反馈，平均人员利用率是98.5%。

但是，根据排队理论，高资源利用率就会意味着更长的等待队列，更慢的响应速度。这在移动互联网时代是不可接受的，因为速度决定成败。这时中层管理的局部优化行为“填满日历”和企业的整体目标“快速响应”就不匹配了。

不确定性中存在确定性

虽然世界的本质是不确定的，但是在这种不确定当中，存在一些统计上的确定性。例如，量子系统的物理行为可以用波函数来描述，波函数的绝对值平方是量子系统的概率分布。因此，不确定性管理也是要追求确定性的，但是不应该使用第二节中那些掩耳盗铃不承认不确定性存在的确定性管理手段，而应该使用一些基于统计思维的不确定性管理手段。

例如，对于确定性估算和承诺的确定性管理行为，就可以用“基于历史数据的服务水平协议”来替代。例如，根据2.3的韦伯分布图，上游系统可以提前60天提供一个普通需求，这个团队有85%的概率按时完成，如果希望这个需求有98%的概率按时完成，则需要提前150天提出需求。

看到这里，许多同学会提出，这里需求大小不一样呀。其实大量的研究显示，由于创新研发过程的低流动效率，交付前置时间（Lead Time）和需求规模之间的关联性很低，反而与交付系统特征、需求服务等级等因素更为相关，这是近几年国外兴起抛弃估算运动（No Estimate）的根本原因。

不确定性不能被彻底消除，但可以在不同要素间迁移

如海森堡不确定性原理表述的，位置不确定性和动量不确定性会此消彼长，相互转化，但是无法同时减少两者的不确定性。这代表了一个环境中大多数不确定性因素之间的关系，互相可以转化，但是无法同时根除。

例如，在项目管理中，有些项目是进度不确定性成本最高，延期公司就会损失惨重，这时可以利用提高项目范围不确定性来降低进度不确定性。另一种场景，对于电信设备公司、医疗仪器公司这种质量成本非常高的企业，如果产品质量出现不确定性，那么可以通过延长项目进度的方式，降低质量不确定性。但是，希望同时锁死范围、质量、进度、成本不确定性，而依靠前期仔细计划估算，后期精确执行的确定性项目管理方式在复杂研发创新项目中，这种想法是必败无疑的。

降低不确定性发生成本

确定性管理是以正态分布（a）为基础，不确定性管理是以幂律分布（b）为基础的。

来源：软件供应链