数字化企业敏捷建模之组织建模( 二 ) 作者|肖然出品|CSDN（ID：CSDNn

根据逆康威定律，我们构建的这个“技术架构地图”的标的物就应该是为了研发相关产品和系统而相互关联的一组团队。
我们中国有句俗话——“船小好调头” ，为了灵活，大家自然是希望团队规模小。然而随着“软件吞噬世界” ，随着元宇宙的浮现，软件的复杂度是与日俱增的。复杂度增长带来团队规模的扩大是不可避免的现实。这里也就产生了一个矛盾的情况，如果我们划分过细，就很容易陷入精细化管理的怪圈，让后续的调整变得困难重重。
另一个极端情况，是否有可能在团队规模变大时，仍然坚持不拆分，这样沟通结构就保持了最大限度的灵活性呢？显然答案是不可能。团队过大不仅很难保证组织效率，实质上就难于形成一个团队。
邓巴数（Dunbar'snumber）某种意义上给我们提供了这样的团队规模“上限” ，特别是在软件研发这样高度依靠脑力劳动的领域里，这种团队人数的限制就越发明显。

文章图片
（邓巴数， https://en.wikipedia.org/wiki/Dunbar%27s_number 。能与某个人维持紧密人际关系的人数上限，通常认为是150人左右。对于大型软件研发组织，很多企业把150人作为拆分办公室的一个阈值。）
邓巴数提醒我们在面对复杂软件研发时，必然是需要划分团队的，只有控制团队规模才可能保证研发的效能。这就产生了类似amazon经典的“2pizzateam”的结构，每个开发团队的规模控制在了10人左右。为了追求高绩效团队，我们希望划分出的小团队是能够共享目标、协作亲密无间的，所以企业往往追求的小团队规模是瞄准了更小的15人。
值得警惕的是，小团队结构并不代表我们能够突破康威定律的魔咒，实际上“小团队僵化”在很多所谓实施了敏捷开发的组织里比比皆是。比较典型的现象是越来越繁琐的集成联调工作需要协调；越来越控制不住的“小”团队规模扩大，从10人很快到了15、20人。
所以真正长效的软件技术架构治理应该来自于小团队组织架构的设计和演进，而如何去定位每个小团队的职责、如何设定每个小团队的演进路线就成为了技术架构设计的关键。
团队拓扑带来的突破确定了我们技术架构地图上的物体是互相关联的团队后，让我们来看看具体如何认定这些团队的职责，并针对性地设定团队的目标和工作方法。
这是一个曾经让软件研发组织非常头痛的问题，由于软件相关技术发展迅速，并且种类繁多，划分和定位小团队比较困难。在落地敏捷开发时，我们也仅仅是给出了所谓的“特性团队”和“组件团队”两种模式。前者主要是面向业务需求的端到端交付，后者更多是从技术模块化的角度，形成技术沉淀和复用。这样的基础划分实际上并不能指导大型研发团队进行有效的团队设计，往往造成业务希望全面特性团队简化沟通，而技术希望大量组件团队固化架构。
团队拓扑（TeamTopologies）带来了这个领域新的突破，改变了团队划分的出发点——团队的认知负载（cognitiveload），简单讲就是一个团队可以驾驭的知识工作的极限。前面提到了邓巴数的原则，为了小团队的高效运作，我们希望控制每个小团队在15人左右。而15人的团队在认知上就是有极限的，我们不会期望这样一个小团队能够掌握一个上百万行代码库的方方面面。如果这个百万行代码就是我们的一个应用系统，那么组织就需要划分成多个这样的15人小团队，每个团队的职责和互相之间的协作就需要清晰定义。团队拓扑的理论和方法就这两个方向给出了总结和提炼，指导大家能够从组织架构的视角去完成技术架构的设计。（记住逆康威定律！）