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

文章图片
（团队拓扑TeamTopologies知识图谱，来源于《高效能团队模式：支持软件快速交付的组织架构》一书作者总结。）
首先让我们来看看团队拓扑在团队职责方面的定义，分为四种类型的团队。
业务流团队：与源源不断的业务变化形成的业务价值流对齐的团队，具备跨职能的技能组合，不需要等待其他团队就能够增量地交付价值。
平台团队：致力于构建底层平台的团队，通过底层平台来支持业务流团队的交付。平台让复杂技术变得简单，而使用复杂技术的团队认知负载也因此降低。
赋能团队：在转型或学习过程中协助其他团队掌握或者修改软件的团队。
复杂子系统团队：专门负责一个子系统的团队，这个子系统对于普通业务流团队或平台团队来说处理起来特别复杂。这种团队不是必须的，只有在必要时才会成立。
四种类型团队的分类相对有效地帮助组织架构师们建立了一个模型范式，当发现一个团队所处理的业务有超越这个团队负荷极限时，我们可以从不同的视角去划分工作，推动形成适配的团队结构。
可以从业务视角进行切分，建立新的业务流团队来处理拆分出来的业务功能，切分后的两个业务流团队保持工作上的相对独立。
可以从技术视角进行剥离，建立新的平台团队或复杂子系统团队来形成技术上的封装，降低现有团队需要处理的技术复杂度。比如针对一个复杂核心逻辑进行DSL建模，简化现有团队的使用成本。
可以从能力视角进行赋能，通过外部赋能团队引入新方法和实践，提升现有团队认知能力。很多组织从小团队开始尝试采用敏捷开发就是这样的形式。
面对复杂场景，团队拓扑通过团队职能的分工给我们提供了不同的解决方案视角。当然仅仅是团队分类显然还是不够的，还需要明确团队间的“接口” ，即团队间合理的合作模式。这个方向上团队拓扑提炼了三种典型的合作方式。
协作：两支团队在一起紧密地工作。
一切皆服务（Xasaservice）：通过服务消费对方能力或者提供能力给对方，几乎不需要紧密协作。
促进：帮助对方或者接受对方的帮助来扫除障碍。
以上三种合作模式的提炼相对抽象，但已经给我们提供了很好的切入点，团队拓扑社区也在通过实践案例总结TeamAPI ，团队接口。大家可以参考Github上的模板来细化团队在对外协作方面需要具备的能力：https://github.com/TeamTopologies/Team-API-template 。
通过分类团队和定义团队接口，团队拓扑也给我们揭示了过去忽视的小团队管理的复杂度。正是由于这种复杂度的存在，才造成我们在技术架构的长期演进上知易行难，开始的热忱往往在日常各种琐事中消磨殆尽。所以，作为一个大型研发组织，即使我们难于一步过渡到采用组织架构来描述技术架构的实践，也应该在当下开始增加组织架构的梳理到技术架构设计的过程中去，让逆康威定律不再是停留在PPT上的根因分析。
组织建模的有效实践借助团队拓扑，我们明确了“技术架构地图”上的标的物（团队）的分类和之间的关系，是时候讨论一下地图的坐标系了。本着敏捷价值驱动的一贯原则，坐标系的一轴应该是“价值”；而这个数字化时代组织的基石就是“以客户为中心” ，必然要求我们从客户视角来审视价值。
地图上的物体——团队——除了分类和关联关系外，还需要考虑在一个企业里的定位。比如大型商业银行可能有一个相当规模的自有云平台团队，构建其自身的私有云；而一些小型金融机构可能就只有一个小型的云赋能团队，保证业务开发团队能够使用好公司合作的云平台。这样的考虑在过去的IT组织里是一个经典辩论：购买还是自建（BuyorBuild）。