多个团队的技术方案冲突,怎么决策

作为一个架构师或技术Leader而言,技术方案的决策是常见的要做的事,毕竟很多时候并不会只有一条路能走到目的地,这个时候到底怎么决策很容易成为一个巨大的纠结点,在涉及多团队合作的情况下,甚至有可能会成为block整件事进展的关键因素,这篇文章就来聊聊这个。

自从我开始做一些比较大的跨多团队的基础技术项目后,就会经常面临一些技术方案的决策的事,从一开始的不知所措,痛苦无比,到现在,也算是积累了一些经验和方法,技术方案的决策上,最难的其实就在于可能多个技术方案都是可以走到目的地的,这个时候怎么选择,尤其是多个团队产生冲突的时候,怎么去选择就更加复杂化了。

对于一个由多个技术团队共同完成的大的技术方案而已,会出现两种情况。

一种情况比较简单,就是每个团队各尽其职,分工清晰,这个时候大的技术方案通常不会产生太多的冲突,可能会产生的就是A团队对B团队所负责的部分的技术方案有质疑,这种情况下通常其实不会太难办,大的技术方案是需要一个大架构师的,这个架构师需要定义出整个技术方案的设计原则(之后准备写一篇什么是看起来很虚但其实是核心的设计原则),只要在遵循了设计原则的情况下,我认为B团队所负责的部分的技术方案其他团队就不需要去质疑,谁负责哪块谁决定哪块的技术方案。

另外一种情况就会比较复杂,就是这个大的技术方案中,有所做的部分重叠的不同团队,这个时候就非常容易产生技术冲突,不同团队很有可能会给出不同的方案,这个时候作为整个大技术方案的owner或架构师,怎么去决策就是巨大挑战了,毕竟就算大技术方案的架构师是独裁的,但独裁的还是要有些道理的,不能完全靠行政手段,在这样的情况下,我的观点是这个时候的选择可以基于以下几点考虑去做:

1. 设计原则

多年前在写设计文档中的设计原则时,总是会觉得没什么值得写的,松耦合等等经常会成为常用词,但貌似然并卵,近几年才越来越明白其实设计原则是设计文档中的精髓所在,看起来通常设计原则会很短的几条,但好的架构师会通过这几条控制好整个项目的技术风险,确保各团队的技术方案不偏离关键航道,设计原则里写的点要在每部分的技术方案中贯穿,否则就和没写没什么区别,更形象一点说就是设计原则是在排技术方案细节中关注的重点的优先级,例如有些项目中平滑切换是最高优先级,有些项目中技术创新是最高优先级,设计原则这个部分很值得专门写篇文章,因此这里就不再展开了。

在多个冲突的技术方案选择时,设计原则是其中关键的衡量因素。

2. 团队分工、核心价值和定位

对于产生冲突的团队,需要站在公司角度来做一个判断,产生冲突的部分的技术要做成,核心成功的关键技术点到底掌握在哪个团队手里,还有是对于哪个团队而言是更为核心的价值,只有是那个团队的核心价值才能在人力投入,未来持续发展上有保障,每个团队在一个大的组织里都是有分工的,分工也对应到了其核心价值,在多个冲突的技术方案选择时,一定要考虑这个关键的衡量因素,显然在考虑这个因素的时候要非常中立,站在公司层面而不是小团队层面来考虑,以便确保最后的决策是符合组织对每个团队分工的期望的。

举我自己经历过的两个case来说说。

Case I: 在某个大的技术方案里,有两个团队在某个技术点上都有自己的实现方案,但我最后的决策是选择了当时相对而言反而更不成熟的一方,原因就是我的判断是这个技术点要做成,核心技术其实在这个当时还不是那么成熟的团队手里,

Case II: 在某个大的技术方案里,同样也是几个团队在同一个技术点上都有自己的方案,我最后选择的那个团队基于的判断是:我相信对于公司而言,那个团队才是应该掌控这项技术的组织。

3. 团队能力状况

除了团队分工外,团队的能力状况也是关键,有可能会出现一种状况是从组织层面考虑而言,是应该在B团队做最合适,但B团队的能力在当前可能不具备,反而是另外一个团队更具备,这个时候需要做的决策会是由另外一个团队承担起来,但同时逐步的操作组织层面的变化,确保在整个大的技术方案落地后,以后有持续发展的保障。

从上面这三个衡量因素可以看出,一个大技术方案的owner或架构师,光有技术是远远不够的,在多个冲突的技术方案选择时,更主要的不是评判技术方案的优劣,一旦陷入纯粹技术方案的优劣之争,其实是很难有结果的,越大的项目越是如此,通常来说其实方案可能没有优劣之分(当然,少数冲突的情况下是有明显的优劣之分的),而是哪个更适合的问题,甚至有些时候不同方案在最终多次迭代后走向的是同一方案,只是路径不同,和语言之争类似,所以作为大技术方案的决策者,首先要做的不是去评判技术方案的优劣,而是大家先一起对齐目标、设计原则,然后清晰阐述自己做选择的因素,最后做出决策,当然因为因素毕竟有主观性,要完全得到认可仍然是不容易的,但至少让参与大项目的大伙们清楚的知道你决策的原因,这样大家才能更好的理解整个技术方案,确保最终项目的实现和落地。

文章标签: 架构师


关注微信公众号“架构说”,加入Q群微群,让架构师带你飞︿( ̄︶ ̄)︿。


原文链接: 阅读原文
免责申明: 架构说任何转载的文章都会明确标注原文链接。如有侵权,请与本站联系。
转载说明: 架构说原创文章转载时请务必注明文章作者、链接和来源。