架构活动中常见的七种冲突

在统一语义的过程中，发现不同角色在不同的语境中隐藏了很多冲突。日常工作时这些冲突可能并不明显，因为大家都在自己的隔离语境中与几个团队进行了小范围的合作。直到我们把不同语境中的概念，拿到一个统一的语境中来抢夺有限资源的时候，这些冲突才会全面爆发。

其实越早暴露这些冲突，对于架构活动来说越有利。毕竟这些冲突是客观存在的，避免不了。这里列举了架构活动中最常见的七种冲突。

1、优先级的冲突

这是互联网企业中最普遍的冲突，在资源有限的情况下，每个需求方都从自己的视角出发，期望得到最大的支持，导致各方在需求优先级上无法达成一致。

比如营销团队，由行业运营和大促运营两个团队共享，而每个运营团队都认为自己的需求优先级更高。这就是多个依赖方共享一个开发团队导致的。

再比如，弱势角色的高优先级需求很容易被忽视。像合规部门一般没有专职的产品经理，但由于监管形式的变化，合规类需求的优先级其实也很高。不过掌握研发资源的业务团队，却不太愿意让研发人员去开发这类需求。

2、定位的冲突

不同角色之间天然就是互相制约的，这并不是特例，而是企业中普遍存在的现象。因而一个企业内部必须有某种形式的监督和制约机制，以确保整个企业的决策有完整且相对平衡的视角，而不仅仅是单一视角中的最优。需要说明的是，这种冲突独立于架构活动，且长期存在。

举个例子，商家运营的定位是商家增长，那么这个角色就要吸引尽可能多的商家到平台上。而网规团队的定位是减少平台风险，那么这个角色就要尽可能地打击作弊和劣质商家。

如果我们用算法语言来表述，商家运营的定位是最大化召回，网规团队的定位是最大化精度。这就是一对矛盾。

3、团队和个人的冲突

团队或者个人之间也会有敌对情绪。有的公司喜欢赛马，针对同一个垂直领域，会让几个部门用不同的商业模式在市场上竞争。或者针对同一个场景，会用多个技术和算法来实现。

这些定位大致重叠的团队，往往会因为内部竞争形成不小的摩擦。久而久之，团队的关系就会变得不和睦。也有的人日常做事缺乏底线，得罪了同事。这个时候，对立双方很可能会因为参与了同一个架构活动，而将个人冲突引入其中。

4、边界冲突

多个需求方或者执行团队负责的领域边界不够清晰，不确定到底“谁说了算”。这种情况在大公司里尤为常见，语境的差异性也是这种冲突的常见诱因。

边界冲突主要源自以下三个方面：

不同的垂直执行域在定位上本身就有重叠。比如商家团队和商品团队之间，交易团队和资金团队之间，流量团队和导购团队之间。
水平分层上的模糊性。比如前端团队和后端团队之间的分层，业务团队和财务团队之间的分层。
因技术进步带来的执行域边界的迁移。比如前端转全栈工程师，导致前端的职能范围拓展到后端；业务中台化，导致业务线的研发任务迁移到了一个共享的中台里；前端低代码化，导致之前由前端执行的任务，变成了由产品或者后端工程师来完成。

5、问题域到执行域的映射关系的冲突

需求方到执行者领域的映射关系没有形成共识，导致几个团队互相争夺地盘。

同样，如果产品团队已经完成整合，但是技术团队的整合还没有完成，订单域就可能形成一对多的映射情况。这种一对零、一对多、多对零、多对一、多对多的状态，都会造成设计和执行过程的混乱，必须在这个节点解决掉。

6、生存空间的冲突

这是映射冲突中一对多和多对多的情形，在大公司里比较常见，所以值得单独列出。比如一个部门里有多个做网关的团队，平时大家都相安无事。一旦公司要把几个网关合并成一个，生存空间的冲突就不可避免了。

7、决策权的冲突

在规划和执行决策上，有的角色非常强势，导致本来属于架构师的决策权，却被某个领域的领导抢夺了，从而形成架构冲突的热点。

比如某个大厂长期存在这样的现象：对某个领域有控制权的共享技术团队，涉及到他们管辖的领域，需求必须由他们承接，设计也必须由他们决定，谁都不能替代或更改。这就导致任何由这个团队参与的架构活动，一旦涉及这个团队的需求，设计就全都变形了。

所以统一语义的关键作用，就是让你及早看到这些冲突，并及时解决，否则架构活动将会面临很大的不确定性。

此文章为5月Day15 学习笔记，内容来源于极客时间《郭东白的架构课》，推荐该课程。