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

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

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

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工程分层实战

相关推荐
hqxstudying5 分钟前
java依赖注入方法
java·spring·log4j·ioc·依赖
·云扬·13 分钟前
【Java源码阅读系列37】深度解读Java BufferedReader 源码
java·开发语言
martinzh1 小时前
Spring AI 项目介绍
后端
Bug退退退1231 小时前
RabbitMQ 高级特性之重试机制
java·分布式·spring·rabbitmq
小皮侠1 小时前
nginx的使用
java·运维·服务器·前端·git·nginx·github
打好高远球1 小时前
如何用AI破解相亲信息不对称
架构
前端付豪1 小时前
20、用 Python + API 打造终端天气预报工具(支持城市查询、天气图标、美化输出🧊
后端·python
爱学习的小学渣1 小时前
关系型数据库
后端
武子康1 小时前
大数据-33 HBase 整体架构 HMaster HRegion
大数据·后端·hbase
前端付豪1 小时前
19、用 Python + OpenAI 构建一个命令行 AI 问答助手
后端·python