原文参见本人博客：技术管理 之 技术
Tech Lead 的 “Tech” 指明了Tech Lead日常工作的核心内容和管理重心。那么作为Tech Lead，究竟需要关心哪些Tech相关的内容呢？又具体需要做哪些事情呢？
指导技术解决方案
首要的当属对技术解决方案的把控和指导，这个工作感觉很像一个架构师的职责。没错，当团队在各种场景下需要给出解决方案时，技术管理者就要戴上架构师的帽子，设计架构，做技术决策。
这里可能有很多种情况，跟项目的具体情况，以及技术管理者接手时项目所处阶段有关，比如：
- 全新项目开始前：全新的业务需求，架构设计和解决方案尚未确定。
- 项目初始阶段：项目已经有了解决方案的大致方向，包括技术选型、系统职责、集成关系等。
- 项目中后期：可能已经是一个遗留系统，在设计解决方案时可能有各种约束，或者坑。
这三个阶段对于Tech Lead的挑战是逐渐递增的，全新的项目在这里是相对简单的场景，澄清业务需求以及各参与部门或系统之间的职责和关系，结合业务及技术目标设计架构和解决方案，Tech Lead有足够的灵活度来处理各种需求带来的问题。
而对于已经有了方案基础，或者开发了一段时间的系统（也可能是年久失修的遗留系统），在做解决方案设计时需要考虑很多内容：
- 既有架构设计的问题：特别是针对遗留系统，有哪些问题，严重程度如何，是否有规划中的方案等。
- 既有架构设计初衷以及业务目标是否还成立，是否有新增的需求，是否能够满足未来业务演进的需求。
- 当前是否有更优的架构设计方案，是否需要做技术架构的迁移。
相较于全新的项目，对已有系统设计解决方案之前，要充分了解系统中的技术债，结合架构设计的长远目标，可用资源以及开发周期，给出相对合理的方案。通常一个完整的技术解决方案会包括下面的内容：
- 应用架构设计
- 部署架构设计
- 数据架构设计
- 技术栈选型
- 集成方案设计
- 专项解决方案设计
- 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，肩负着指导项目技术解决方案和统一团队方向的重任，看问题的视角需要打开。在决策时，需要考虑决策产生的影响，比如未来是否需要返工，是否会带来运维工作量的增加，是否会对其他团队产生不良影响等等。更需要站在更长远的视角，考虑软件架构演进的方向，考虑系统未来需要承载的业务增长量等等，也要有意识培养整个团队站在更长远的视角看问题，避免引入技术债和技术风险。
