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

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

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

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

相关推荐
qq_4419960517 分钟前
Mybatis官方生成器使用示例
java·mybatis
巨大八爪鱼23 分钟前
XP系统下用mod_jk 1.2.40整合apache2.2.16和tomcat 6.0.29,让apache可以同时访问php和jsp页面
java·tomcat·apache·mod_jk
码上一元2 小时前
SpringBoot自动装配原理解析
java·spring boot·后端
计算机-秋大田2 小时前
基于微信小程序的养老院管理系统的设计与实现,LW+源码+讲解
java·spring boot·微信小程序·小程序·vue
魔道不误砍柴功4 小时前
简单叙述 Spring Boot 启动过程
java·数据库·spring boot
失落的香蕉4 小时前
C语言串讲-2之指针和结构体
java·c语言·开发语言
枫叶_v4 小时前
【SpringBoot】22 Txt、Csv文件的读取和写入
java·spring boot·后端
wclass-zhengge4 小时前
SpringCloud篇(配置中心 - Nacos)
java·spring·spring cloud
路在脚下@4 小时前
Springboot 的Servlet Web 应用、响应式 Web 应用(Reactive)以及非 Web 应用(None)的特点和适用场景
java·spring boot·servlet
黑马师兄4 小时前
SpringBoot
java·spring