遥远的相似性：足球理论和技术架构五大相通之处

欢迎大家关注公众号「JAVA前线」查看更多精彩分享文章，主要包括源码分析、实际应用、架构思维、职场分享、产品思考等等，同时欢迎大家加我微信「java_front」一起交流学习

足球是一项复杂而精妙的运动项目，其中蕴含的一些思想和方法论，与其它领域有相通之处。本文探讨足球理论和技术架构与管理五大相通之处：

• 先定战略，再定战术
• 划分职责，积极补位
• 洞察特点，扬长避短
• 关注要素，关注连接
• 守好底线，突出箭头

1 先定战略，再定战术

足球是团体项目，如果场上队员每人一个想法，那么必然是一盘散沙，比赛所表达内容也必然不知所云。所以一定要明确战略与战术之关系，其层次关系是：比赛战略，团队战术，个人战术。

比赛战略是决定性的，为球队在本场比赛定下基调。常见战略有侧重进攻，防守反击，侧重防守。对于同一个球队而言，战略不是一成不变的，而是根据队员特点和对手不同而选择。

团队战术是对比赛战略的落实与细化。常见战术有控球，长传冲吊，边路进攻，人盯人防守，区域联防，全场紧逼，任意球战术，角球战术。

团队战术通过比赛阵型体现。基础阵型有442，352，343，433，532阵型。在基础阵型之上调整队员站位可以变阵为4213，4231，3232，3142等阵型。比赛战术一定要结合队员特点。例如343在进攻时比较依赖两个边路，那么要求左右两边锋突破能力强，中锋头球能力强。4231要求中锋具有很强支点能力。

个人战术是主教练结合队员特点，为其量身定制的战术。队员特点越鲜明，其任务定制化程度越高。例如高中锋任务是支点和头球，速度快且进攻能力强的边后卫要适时插上进攻。还有个人特点更加鲜明的战术，例如前英超球员德拉普界外球扔得又远又准，所以主教练为其制定了手榴弹战术，甚至在中线附近可以通过界外球直接发起进攻。

IT技术同样要先定战略，再定战术。如果你是一家新公司CTO，你会如何确定使用什么技术架构？如果看到大厂用什么你就用什么，未必会达到良好的效果。因为大厂技术架构是随着业务规模的变化一步步迭代而成。

新公司业务规模一开始并不大，所以技术架构先短平快，随着发展再迭代。所以4A架构中第一步先确定业务战略，第二步构建业务架构（BA），第三步构建数据架构（DA）和应用架构（AA），第四步构建技术架构（TA），先后顺序要理清楚。

在DDD实践中一定是先有战略设计，再有战术设计。战略设计主要是使用一些方法论如四色分析法或者事件风暴，划分清楚业务边界，这是重中之重。战术设计是怎么搭建工程，怎么命名实体，怎么分包，这一层面偏向于术。试想如果领域划分得一团乱麻，即使工程结构再精密也于事无补。

战略指导战术，战术服务战略。如果战略错误，即使战术再精密也只是事倍功半，甚至南辕北辙。如果战略得当，即使战术有瑕疵也可以纠正。

2 划分职责，积极补位

在足球比赛的正常情况下，如果是对方球权，你方所有队员会全部扑上去抢球吗？很显然不是。同理如果是你方球权，你方会所有队员会全部冲入对方禁区参与进攻吗？很显然也不是。这是因为球场上每个队员有负责的区域和担负的责任。

在防守战术中有两种类型：人盯人防守，区域联防。区域联防就是将球场划分为若干区域，每位队员负责一个区域的战术。当对方队员进入A队员负责区域时，A队员就要破坏这次进攻。当对方队员离开并进入B队员负责区域，A队员就将防防守责任交给B队员。

在IT团队管理中也是同理，由于业务复杂性，一个人不可能熟悉所有领域，所以IT团队都会划分业务领域，例如订单，商品，营销，支付，会员，物流，履约等等，每个团队要做好本领域本职工作，这是立身之本。

假设对方队员离开B队员防守区域，进入C队员防守区域，但是由于C队员压上进攻未能及时落位，这时出现防守真空，此时即使不在B队员防守区域，B也应该继续跟着对方队员，而不能放任不管，这就是补位。

同理在技术团队管理中，在同一个团队内，技术人员要尽量做到精通一个领域，熟悉多个领域，这样当一名成员任务过重时，其它成员可以先补位。如果涉及跨团队支持，例如公司项目攻坚时，团队之间也要互相支持。

精通一个领域做起来并不难，因为分配给某个成员一个领域，这个成员一直在做这个领域的设计和开发，久而久之必然最熟悉，当然也要此成员注意总结与积累。

熟悉多个领域实践起来并不容易，因为不是自己做的，有些细节并不清楚，这应该怎么办呢？面对这种情况，在实践中要求第一是规范技术方案详细设计，第二是提测前互相代码review，第三是定期组织分享会。

补位不应该是常态。如果一个位置的队员频繁失位，那么就要考虑第一是不是这个位置是否压力过大，战术层面本身不合理。第二队员是不是适应这个位置，是否需要调整至其擅长和熟悉的位置。

3 洞察特点，扬长避短

在足球运动中每个队员都是有自己特点，特点有正反两面的影响。例如一个中后卫具有高大的特点，正面影响是高空球争顶有优势，反面影响是速度不快，转身慢，容易被突破。例如一个前锋具有小快灵的特点，正面影响是进攻或者反击速度可以提起来，反面影响是头球争顶不足，导致边路传中和定位球战术受限。

特点必然具有正反两面性，所以作为主教练是不能苛责队员的。主教练第一应该用好这些特点，扬长避短，把合适的人放在合适的位置。第二不同特点队员搭配使用，例如两个中锋可以一高一快，高可以头球攻门，快可以反击提速。两名中后卫也可以搭配一高一快（当然中后卫身高有一定要求）既可以防守高空球，也兼顾防守时速度要求。

在技术团队中每个人性格，技能与禀赋是不同的，甚至有些方面截然不同，那么作为技术管理者，首先要洞察到这些特点，其次要善用这些特点。例如一个团队成员喜欢钻研技术，但是不善于沟通，那么应该把一些技术攻坚任务交给他，而不是让他承担过多沟通的任务。一个团队成员沟通能力很强，那么应该把对外沟通，项目推进任务交给他。

如果一名成员有一些特殊特点，那么管理者可以放大这些特点，增加一些特殊武器。例如第一章节中提到前英超球员德拉普，界外球投掷又远又准，时任斯托克城主教练为此专门制定了通过界外球发起进攻的战术，称为手榴弹战术。

4 关注要素，关注连接

在足球比赛中如果对方在本方后场控球，你方两名前锋上前逼抢，如果球在谁脚下就过去抢谁，那么当你扑上来时，因为对方有明显人数优势，对方后卫只要传给没人防守的队友即可。这样是很难形成有效逼抢效果的。

所以不能仅仅关注队员这个要素，还要关注要素之间的连接。此时你方前锋队员要切断向前传球路线。 由于对方中路进攻利益最大化，所以你方队员要站在对方后卫与对方中路队员的连接线上，把对方后卫出球路线逼向边路或者盲目开大脚，那么对方进攻成功率将大大降低。

在技术团队管理中如果一个成员（要素）工作出现了问题，那么作为管理者你不能只归咎于这个成员，而是要找与这个成员的连接。例如管理者有一个优先级非常高的需求A，你找到A成员，但是此时他已经在做需求B在，无法将需求A排进去。

如果需求A没有完成，你能归咎于A成员没有执行吗？这肯定不行。技术管理者应该站到一个更高维度去解决问题，求之于势，不责于人。这种情况下技术管理者要去找连接，组织需求A和需求B的相关方和业务主管，比较两个需求优先级，最终确定哪个先做，哪个后做。

5 守好底线，突出箭头

在足球比赛获胜条件是比对方多进一个球，反而言之比对方少丢一个球也是获胜。我个人排兵布阵习惯使用532阵型，这个阵型特点是：第一是立足防守，第二是中场渗透，第三是一高一快两个中锋配合进攻。

在技术架构设计中为保证系统高可用性，高可用核心策略一般包含：冗余+故障转移策略，降级策略，延时策略，隔离策略。高可用实际应用方案多种多样，但一般都在落实上述策略，从而构建一个稳定的高可用技术系统。

在足球比赛中稳固防守同时也不代表固守，也可以适当进行变化，突出一些箭头。532阵型变化是：第一是两名边后卫可以插上进攻，第二是如果比赛后半段时间比分落后，一名进攻型高大中后卫可以提到中锋位置。

在技术架构设计中在做好系统高可用性同时，不能裹足不前，而是用技术拓展业务边界，敢于探索新业务，敢于探索新技术。

6 延伸阅读

DDD理论建模与实现全流程

反脆弱与技术系统高可用性

六个分层维度：SpringBoot工程分层实战

欢迎大家关注公众号「JAVA前线」查看更多精彩分享文章，主要包括源码分析、实际应用、架构思维、职场分享、产品思考等等，同时欢迎大家加我微信「java_front」一起交流学习