技术管理 之 技术

Tech Lead必备技能

Tech Lead 的 “Tech” 指明了Tech Lead日常工作的核心内容和管理重心。那么作为Tech Lead,究竟需要关心哪些Tech相关的内容呢?又具体需要做哪些事情呢?

指导技术解决方案

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

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

  1. 全新项目开始前:全新的业务需求,架构设计和解决方案尚未确定。
  2. 项目初始阶段:项目已经有了解决方案的大致方向,包括技术选型、系统职责、集成关系等。
  3. 项目中后期:可能已经是一个遗留系统,在设计解决方案时可能有各种约束,或者坑。

这三个阶段对于Tech Lead的挑战是逐渐递增的,全新的项目在这里是相对简单的场景,澄清业务需求以及各参与部门或系统之间的职责和关系,结合业务及技术目标设计架构和解决方案,Tech Lead有足够的灵活度来处理各种需求带来的问题。

而对于已经有了方案基础,或者开发了一段时间的系统(也可能是年久失修的遗留系统),在做解决方案设计时需要考虑很多内容:

  • 既有架构设计的问题:特别是针对遗留系统,有哪些问题,严重程度如何,是否有规划中的方案等。
  • 既有架构设计初衷以及业务目标是否还成立,是否有新增的需求,是否能够满足未来业务演进的需求。
  • 当前是否有更优的架构设计方案,是否需要做技术架构的迁移。

相较于全新的项目,对已有系统设计解决方案之前,要充分了解系统中的技术债,结合架构设计的长远目标,可用资源以及开发周期,给出相对合理的方案。通常一个完整的技术解决方案会包括下面的内容:

  1. 应用架构设计
  2. 部署架构设计
  3. 数据架构设计
  4. 技术栈选型
  5. 集成方案设计
  6. 专项解决方案设计
  7. CFR

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

更值得一提的是集成方案设计和专项解决方案设计,这两项在日常开发中的占比更大,也更容易出问题。

集成方案涉及第三方系统,限制或风险有很多,比如:

  • 因第三方系统的接口技术比较落后而需要做大量的适配。
  • 因第三方系统的开发周期很长,要考虑Toggle等灵活应对方案。
  • 因双方理解不一致而导致联调失败,无法上线。

专项解决方案是针对特定需求而定制的解决方案,通常也是Tech Lead接手项目后为解决当前系统的一些问题而设计的解决方案,也是当前项目架构设计的一些特定关注点,比如针对历史数据的迁移方案,针对当前业务的分库分表方案,针对当前项目业务数据量定制的报表设计方案等。

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

统一团队技术方向

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

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

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

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

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

  • 架构设计原则
  • 代码设计原则
  • 团队内约定的流程和实践
  • 问题处理的流程和原则

管理技术风险

再优秀的团队也无法完全规避风险,从专业的视角来看,只有足够的技术背景才能够感知技术风险,并准确评估技术风险带来的影响,Tech Lead责无旁贷要承担这个职责。

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

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

演进的视角

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

一个团队中的决策大大小小有很多,有些是大家一起讨论做出决策,有些是Tech Lead 依据经验进行决策,也有很多是开发人员自己来决策。大到如何设计一个解决方案,小到如何写一段代码,这些决策都是权衡的结果,是决策者基于自己的认知对项目所处环境中各种约束的权衡。

作为Tech Lead ,肩负着指导项目技术解决方案和统一团队方向的重任,看问题的视角需要打开。在决策时,需要考虑决策产生的影响,比如未来是否需要返工,是否会带来运维工作量的增加,是否会对其他团队产生不良影响等等。更需要站在更长远的视角,考虑软件架构演进的方向,考虑系统未来需要承载的业务增长量等等,也要有意识培养整个团队站在更长远的视角看问题,避免引入技术债和技术风险。