技术管理 之 技术

原文参见本人博客：技术管理 之 技术

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