技术管理 之 技术

Tech Lead必备技能

Tech Lead这个词中包括“Tech”和“Lead”两个词,“Tech”指明了Tech Lead的日常工作核心内容和管理过程中的重心。那作为Tech Lead,需要关心哪些Tech相关的内容呢?又具体需要做哪些事情呢?

指导技术解决方案

首要的当数对技术解决方案的把控和指导,这个工作感觉很像一个架构师的职责,没错,当团队在各种场景下需要给出解决方案时,技术管理者就要承担架构师的职责,做技术决策。

这里可能有很多种情况,跟项目的具体情况,以及技术管理者接手时项目所处阶段有关,比如:

  1. 全新项目开始前,需要澄清业务需求,各参与部门或系统之间的职责和关系等等,根据梳理后的需求,结合业务及技术目标设计解决方案。

  2. 项目初始阶段,在项目开始前,已经有了解决方案的大致方向,包括技术选型、系统职责、集成关系等。

  3. 项目中期接手,甚至可能是个遗留系统,在设计解决方案时可能有各种约束,或者坑。

全新的项目在这里是相对简单的场景,技术管理者有足够的灵活度来处理各种需求带来的问题。而对于已经有了方案基础,或者开发了一段时间的系统(也可能是年久失修的遗留系统),在做解决方案设计时需要考虑很多内容:

  • 架构设计目标:需要满足哪些业务目标,包括未来业务可能的演进方向。

  • 既有设计的初衷以及问题:特别是针对遗留系统,现在有哪些问题,严重程度如何,是否有规划中的方案等。

相较于全新的项目,对已有系统设计解决方案之前,要充分了解系统中的技术债,结合架构设计的长远目标,可用资源以及开发周期,给出相对合理的方案。

通常技术解决方案可能包括下面的内容:

  1. 应用架构设计

  2. 部署架构设计

  3. 数据架构设计

  4. 技术栈选型

  5. 集成方案设计

  6. 专项解决方案设计

  7. CFR

上面的1~4是系统的整体架构设计,在项目之初就需要设计好,包括相应的架构设计原则。随着开发过程的进行,一定会对架构整体设计进行调整,推荐使用 ADR(Architecture Decision Records) 记录架构调整的决策。

更值得一提的是集成方案设计和专项解决方案设计,这两项在日常开发中的占比更大,也更容易出问题。集成方案涉及第三方系统,限制有很多,比如因第三方系统的接口技术比较落后而需要做大量的适配,因第三方系统的开发周期很长,集成要考虑到Toggle等灵活应对风险,因双方理解不一致而导致联调失败,无法上线。专项解决方案是针对特定需求而定制的解决方案,通常也是Tech Lead接手项目后为解决当前系统的一些问题而设计的解决方案。

最后是 CFR(Cross-Functional Requirements),永远不要忘记CFR,CFR帮忙定义了解决方案的更多细节,并规避一些安全、基础设施等风险。

统一团队方向

除了架构师的职责,另一个重要的职责就像黑夜中海上的“灯塔”,把团队引领到一个统一的方向上。当团队成员产生分歧时,能够协调团队成员达成一致,并守护大家达成一致的结果。

通过一个小例子来看看团队成员意见不一致可能产生的问题:

在团队中有2个非常有经验的开发同学,两个同学各有所长,一个同学追求函数式编程,另一个同学更崇尚面向对象编程,并且在各自的方向都有比较深入的研究和见解。两个同学写出的代码风格完全不同,在个别问题上还会争个面红耳赤,逐渐演变成了两种设计风格之争,各有立场,甚至不愿意去碰对方写过的代码。

上面的场景相信在开发中并不少见,好学的同学总是能引入一些新的想法或技术到项目中,这某种角度来看这是我们推荐的,但确实会对项目既有的一些设计原则和实践带来冲击,如果放着不管,就会逐渐形成上面的情况,团队内的分歧会越来越多,甚至对团队共同承担的责任都有分歧,你的代码你改,你的设计你负责,边界感越来越强。

破坏规则很容易,但守护规则需要所有人一起努力。Tech Lead需要有敏锐的观察力,及时发现项目中的不一致,引导大家找到问题的本质原因,建立统一的方向,并带领团队守护方向,涉及的内容包括:

  • 架构设计原则

  • 代码设计原则

  • 团队内约定的流程和实践

  • 处理问题的原则

管理技术风险

即便再优秀的团队,再一致的团队,也无法避免风险。从专业的视角来看,技术风险的管理职责就落在了Tech Lead身上,责无旁贷,因为只有足够的技术背景才能够感知技术风险,并准确评估技术风险带来的影响。

Tech Lead需要带领团队一起识别风险、排列优先级并逐个消除风险。类似 技术债管理,风险需要通过有效的可视化手段,帮助团队快速理解问题并重视起来,持续跟踪风险的状态,保证风险得到尽快的解决。

更多技术风险管理的内容参见 风险管理

更长远的视角

Tech Lead中的“Tech”,看起来和技术更相关,但却不仅仅是技术,也是权衡的艺术。

一个团队中的决策大大小小很多种,有些是大家一起讨论决策,有些是Tech Lead决策,也有很多是开发人员自己来决策。开发人员可以依据经验、知识和自己的技术观来决定如何设计一个解决方案,或如何写一段代码,这种决策也是权衡的结果,是开发人员基于自己视角的权衡。

作为Tech Lead,责任更重,看问题的视角就需要打开。需要考虑决策的不良后果,比如未来是否需要返工,是否会带来运维工作量的增加,是否会对其他团队产生不良影响等等。Tech Lead需要更长远的视角,也需要有意识培养整个团队站在更长远的视角看问题并做决策,避免引入更多的技术债和技术风险。

All rights reserved
Except where otherwise noted, content on this page is copyrighted.