上上周末，蹭了一个公司的 Tech Lead 培训—— Coach 来自 ThoughtWorks 中国区的两个资深 Tech Lead 和 ThoughtWorks 澳大利亚联邦区的资深 Tech Lead。两天的培训下来，学习到了不少的东西。内容只进不出，过些日子怕是会忘记了。于是，便有了这篇文章，一来记录下自己学习的东西；二来，结合自己的 “经验” 做一些总结。
文章较较较较较较较长长长长长长长，分为四部分的内容（PS：幸好 Phodit 编辑器（phodit.com），支持标题折叠的功能）：
- Tech Lead 定义
- Tech Lead 需要哪些能力？
- 项目生命周期中的 Tech Lead？
- Tech Lead 关注哪些内容？
- 提升 Tech Lead 能力
- Tech Lead 工具箱
考虑到文章的长度，先上几张图：
或许，你注意到了：我们说的是 Lead，而不是 Leader。因为当我们说 Leader 的时候，指的往往是领导（leader）——一个正式领导职务的人，肩负着领导（lead）团队、组织前进的职责。而当我们说 Lead 的时候，说的则是一个带领我们前进的人。这个人可以是领导（leader），也可以是其他/她人。也因此，Tech Lead 是一个角色，而非真实的岗位，这个角色的意义在于带领其他/她人前进。两者的定义如下图所示：
那么回想一下，在你的团队里，你是跟着谁一起干活？在做相关的技术工作的时候，你更愿意听谁的话，是你的领导，还是？
我们希望有人带着我们一起干活，比自己优秀的人一起工作，总能从他/她身上学到一些有用的东西。作为一个技术人员，我们服的是那些技术比自己好的人。同样是一个功能，我们实现起来要一天，而他/她可能只需要一个小时——效率既高，质量又好。这样的一个人，便相当于项目中的 Tech Lead，他/她并非真实的领导（leader）。但是在技术上，我们都听他/她的。在他/她的帮助下，我们可以提升自己的技术，构建更好的应用。
如果你身处在金字塔关系的科层制组织中，再回忆一下，谁是你的管理者经常夸奖技术好的人？从某种意义上，他/她便相当于是项目的 Tech Lead。你的管理者会向他/她咨询一些技术上的问题，相关的结论也往往会在你们的项目上使用。
对于 Tech Lead 来说 ，重要的不是管理，而是 Lead。那么问题来了，到底什么是 Tech Lead？
也因此，那些自称是 “技术负责人”（Tech Lead）的人，往往不一定是真正的技术负责人。他/她们承担项目的开发工作，只是作为一个项目或者是团队的负责人，来管理这个项目；对这个项目进行一些技术决策——使用什么框架、使用什么服务、进行接口对接，不做一些编码工作。他/她们相当于是这个项目的技术管理者（Tech Manager）。
为此，我们不得不再提及管理者这个角色。管理者分为四种类型：
- Expert：某一方面技术能力很强，是某个领域的专家
- Manager：擅长发布任务，设定目标，保证目标的达成
- Coach： 具有发展他人、团队的能力
- Leader：知道如何用正确的方式达成目标，激励人
Tech Lead 便在这四种角色之间不断的转换。首先 Tech Lead 是技术上的 Expert，能解决项目上的复杂技术问题。又是一个 Coach，需要帮助到项目中的成员成长。还是一个 Leader，能以身作则，告诉其他/她人怎么做。在需要的时候，还会成为项目上的 Manager，来完成团队的目标。
而受限于不同公司的组织结构影响，Tech Lead 往往包含了多种角色——既是项目经理，又是技术负责人，又是……。如在 ThoughtWorks，Tech Lead 可以是一个纯粹的技术岗位，有的则还要充当项目经理的职责。如果只以 Tech 来看待 Lead 这个角色，那么它是：
- 架构师、技术专家。与项目经理，技术管理者相比，他/她不仅仅关注于项目的技术实践和进度，还得去解决那些最复杂的技术问题。
- 技术榜样。Tech Lead 更像是一个精神 “领袖”，他/她需要让项目中的其他/她人看到前进的方向。
- 开发人员。他/她在项目中抽取时间来编写代码，如 在培训上所定义的那样，至少需要 30% 的时间来编写。一来，掌握项目相关的一系列技术；二来，不断提升技术能力，而不是成为管理者。
除了技术上的工作，他/她还需要懂业务，以此才能开发出符合业务需求的软件。还需要能管理风险（主要是技术相关的风险），才能对应变化。
这便是 Tech Lead 的相关领域模型。
首先，看运气……。每个组织的坑位都是有限的——一个萝卜一个坑。我第一次当 Tech Lead 的时候，是在毕业一年左右的日子。项目上的 TL 和 PM 相继离职创业去了，剩下的人里，我大概是最熟悉项目相关的业务知识和技术知识。我就这么莫名其妙地承担了相关的角色。不过，这并不重要，重要的是有这个坑位突然空出来给你了。
其次，展示你的气质和技术专长。除了你自己，没有人知道你擅长哪些东西。这样一来，你就很可能成为项目上的 2nd Tier（第二梯队，简称备胎）。一旦人们觉得你是个好苗子，那么成为 Tech Lead 就会从 0.01% 提升到了 1%。
最后，还是看运气……。若是你们的组织里，一直有一个人技术比你好，而且这个人一直和你在一个项目里。天晓得，你这个万年老二，什么时候才能翻身。你还年轻，你熬过对方的。
不过，这些也都不重要——不要靠天吃饭，还是要靠嘴吃饭。我们所要做的是，时刻准备着——提升技术，掌握 Tech Lead 技能。
In my option，a Tech Lead should have those skills:
- 首先，要会吹 NB。
- 其次，知道怎么画饼。
- 然后，还要精通 PPT。
- 最后，还会精通 markdown 编程。
哦，好像不太对，上述都是瞎扯。
下图是 Patrick Kua （前 ThoughtWorks 大不列颠及北爱尔兰联合王国区的 Principal Technical Consultant ）提出的 Tech Lead 的责任范围。换句话来说，它便是 Tech Lead 所要做的工作。
图上的内容主要分为三部分：
- Developer。作为一个开发人员，我们应该掌握好编程相关的技能：面向对象编程、函数式编程，结对编程技能，熟练使用各式的工具，迭代和增量式设计，设计模式，重构，自动化测试，类设计。
- Architectue。作为项目中的架构师，我们要考虑的因素有：跨功能需求，演进式架构，买还是做的决策，系统设计，计划评估，技术风险管理，科技愿景和凝聚力，关注全生命周期，广泛的工具集，基础设施，客户引导。
- Leadership。作为一个技术上的 Lead，我们要提升这些软技能：反馈、沟通，教练，动机，关系构建，委托，影响，风险管理，冲突管理，团队管理。
好吧，我承认要学习的东西太多了，尤其是对于一个目标是 Tech Lead 的程序员来说。即要成为一个优秀的开发人员，还要成长为一个架构师，最后还要在领导上有所提升。首先，我们可以成为那个技术最 NB 的人（best technical person），然后我们才能成为 Tech Lead。至少领导力什么的，在技术准备充分之前，适当地花时间注意练习即可。
对应于此，我们也就有了自己的 （ThoughtWorks）的 Tead Lead 自测模型。从下图可以看出，它是在上图的基础上整理出来的：
（PS：欢迎基于 https://phodal.github.io/tla/ 开发你们的 Tech Lead 模型。自测工具使用：1. 从 1 ~ 5 为自己的相关能力打分，再一一连接对应的点数。 2. 在自己想提高的分数上画点，再绘制成圈 2。）
相比之下，我们的 Tech Lead 模型倒是相对比较简单——事项比较少：
- Leadership。关注于情绪智力、持续影响、积极地发展他/她人、提升效率、积极地打造团队、积极的风险管理、开放沟通
- Developer。关注于好的编码技能、全栈开发的经验、模式意识、熟悉代码库、持续提升、明确出问题、关注业务价值、沟通桥梁。
- Architect。关注于架构远景、聚焦于原则，系统、而非软件，支持跨职能需求，未来思考。
但是呢，从技术上来看，每个的维度却远比上述的责任边界要重。从 Leadership 来看，则更有所侧重——侧重于，以技术为主的软技能。
这样一看，确实说了很多的东西，但是过于抽象，反而显得没有一点实际的价值。我们还是对 Tech Lead 要做的事情，还是缺少一个宏观的认识。在那之前，还是让我们回到项目上，来看看项目上的 Tech Lead 的日常
在大部分的组织里，一个 Tech Lead 做的事情，每个人在日常中，到底还是看得一清二楚。可是呢，项目上的每一个人，并非都是从一开始就在这个项目中的。有一些是一开始加入的，一些是早期加入的，还有的则是中途加入的。
也因此呢，我便根据 Tech Lead 要做的一些事情，再按照之前定义的项目三步曲，绘制了一个在项目不同时间的 TODO Lists。
需要注意的是：这里仅列出笔者觉得重要的部分（PS：由于是第一个版本，所以也可能缺少一些要点）。对于某些并非那么重要的职责，可以在上述的 Tech Lead 模型中查看到。
在 ThoughtWorks 开启一个项目的时候，会有这么两个时期：Inception、迭代 0。它们全程都需要一个资深的程序员、架构师参与。他/她的主要职责是设计出符合项目需要的架构。所谓的项目需要，并不一定是最合适于这个项目的技术方案。它可能受到利益相关者、组织架构等各种因素的影响，而导致最适合的方案无法采用。如最大的领导，喜欢的是 A 方案，而不是最佳的 B 方案。
Inception，主要用于验证技术、业务、运营、设计、产品的可行性。过程中需要一个 Tech Lead 作为一个架构师，设计出符合项目需要的软件架构。按照我的理解，相关的过程大概如下所示：
过程中，要与项目相关的利益相关者进行沟通，与开发人员一起探讨……，最后妥协出一个能勉勉强强满足各方需求的架构。我们还会从相关的讨论中，梳理出项目相关的技术风险。
Interation 0。迭代 0，便是在正式开始开发人员，我们所要做的技术工作。它包含的内容有：
- PoC 架构验证。验证系统的架构是否真正可靠，并做一些细微的调整。
- 搭建 CI/CD
- 编写模式示范代码。以符合系统架构风格和模式的方式，结合业务功能编写示例代码，作为其它人的参考。
除此，在技术准备期，我们还需要：
- 对项目成员进行技术培训
- 设计、实施测试策略
- 部署设计及实践
这是一个相当漫长的时期。
除此，在这个时间我们还要做的一件非常重要的是：隔离其他/她技术人员与业务人员的直接需求对话。
对于团队的其他/她成员来说，任何的功能和需求的来源，只应该是来自于业务人员（源自业务需求），又或者是团队中的技术负责人（技术需求）。而不应该由业务人员直接与其他/她开发人员沟通。哪怕是 Tech Lead 和业务人员不在的时候，也需要减少此类事情的发生。
无论是上一个时期，还是这一个时期，我们不得不妥协于业务开发的进度，而忽视一些技术上的追求。这也就导致了，我们在技术实践上缺乏一些更好的实施。
也因此，作为一个 Tech Lead，我们需要建立一系列的规范：
- 着手建立技术债的白板。开始一步步偿还一些技术债，诸如测试覆盖率不足的问题。
- 创建团队的技术文化。知识分享、知识传递等。
- 关注于团队成员的成长。
过程中，不断发布新版本的应用，也因此稳定了系统的部署架构。
到了这个阶段，作为一个 Tech Lead，我们所要关注的内容，主要有两部分：
- 架构演进。系统已经偏向于稳定，只是我们可以探索新的方式，来帮助我们解决当前的问题。
- 人员的培养和成长。团队的大部分成员在这个时期，已经处于 “无聊” 阶段，需要一些新的元素来帮助他/她成长。
这并不代表其他/她的几个方面是稳定的。仍然会出现一些变化，只是这些变化的影响范围并没有那么大。比如，一些关键的利益相关者更换了，那么还需要重新的摩擦一断时间。
最后不得不提及的一点是：受多种因素的影响，项目的开发速率会先从落后于标准速率开始，而后追平，最后随着平均水平的提高，便超过平均速率。
所以在这个过程中，需要 Tech Lead 在合适的时期，采用合适的策略。
作为一个 Tech Lead，我们在项目上主要关注于三个部分：
- Programming
- People
- Process
同样的，在不同的项目时期，也会执行不同的工作——部分内容我们在三步曲中已经介绍过。
编程，是 Tech Lead 的基本功。不论我们多忙，我们总需要深入代码库，了解代码中的问题。
作为一个 Tech Lead，要想提升项目的代码质量，保证项目的可维护性；又要能解决项目中的复杂问题，那么你一定是要加入到项目的开发中。离开一线的时间一远，那么便缺少代码相关的上下文，也难以成为 Tech Lead，转而变成一个 Tech blabla。升职是一件好事，但是编程依然很重要。
依我们的培训结论来看，写代码的时间应该是 >30%。我并不知道这个值的来源，但是差不多是 1/3 的数值，所以你懂的。
关于哪门语言是最好的？ 2 个空格还是 4 个空格？它们有太多的争议。作为一个 Tech Lead，我们需要在磨合的过程中，保证出代码库的一致性，尽可能在这方面减少多样化。当然了，还要适当保留一定的多样化，如允许 Vim/Emacs 的存在，编辑器和 IDE 的论战是有益的一件事。
它们值得我们花时间去讨论，而不是搁置争议。
作为一个 Tech Lead，我们有理由保持一种好的团队技术文化。试着去回答这些问题：
- How long does the build stay broken?
- Do people avoid conflict?
- Do people offer new ideas?
- Do people feel okay to admit being wrong?
- Do people flag when they need help?
再去想想问题出在哪里。
我们需要一个好的技术远景，领先于业界，又或者是保持一流的水平。
People，是一个项目的重要因素。
在项目的不同时间里，对于不同的人来说，他/她们都有不同的感受。这便是心流：
项目的初期，对于大部分的人来说，属于挑战水平高，技术水平一般（对项目不熟悉）的水平。而在项目的中后期，对于大部分的人来说，则项目处于无聊或者无感的状态。在焦虑期，指导新人；在无聊期，创建一些技术挑战……。
作为 Tech Lead 则需要在不同地时期，帮助其他/她人成长。从 Interests、Skills、Strengths、Goals 等不同的维度考虑，了解每个人的不同阶段，帮助他/她们成长。
从某种意义上来看，我们需要了解每一个团队人员的当前位置，而后帮他/也成长。而在项目启动的时候，也可以一起进行头脑风暴，了解每个人在这个项目上的四种诉求。
不得不提及的一句话：
群体能力=平均个人能力+多样性
若是团队里没有反对的声音，取而代之的是沉默，那么团队就是有问题的。所以，要允许反对的声音。哪怕是错的，也需要等他/她说完。
作为一个 Geek，我们总会想着努力不断地提升自己的技术，想和那些优秀的人一起工作。可往往由于多种因素的限制，优秀的人总会到新的项目上。也只能自己成为一个优秀的人，并带领其他/她人成为优秀的人，便可以与优秀的人一起工作。
为此，我们需要引入相关的知识分享文化技术写作、读书分享、结对编程、代码检视、技术回顾会议等。
Tech Lead 保证技术实施的一个关键是，大家都信任你。一旦大家都不信任你的时候，又或者是你不信任自己的时候，那么这个项目就会出现问题。它需要我们一步步地去构建出信任感。
除此，当你空降到一个新的团队时，你作为 Tech Lead，便面临着不少的挑战。陌生的代码库，试探你能力的成员……。
不同的项目都有各种的流程，都有自己所处的时期。这里就需要用到 Bruce Tuckman 的团队发展阶段模型（Tuckman Stages of Team Development Model）：
即：
- 组建期。（Forming）项目小组启蒙阶段。
- 激荡期。（Storming）形成各种观念，激烈竞争、碰撞的局面。
- 规范期。（Norming）规则，价值，行为，方法，工具均已建立。
- 执行期。（Performing）人际结构成为执行任务活动的工具，团队角色更为灵活和功能化，团队能量积聚于一体。
- 休整期。（Adjourning） 任务完成，团队解散。
它可以帮助我们对团队有清晰的认识，随后采取相应的行动，来帮助团队成员明确目标。
而针对于不同的人来说，我们还需要即情境领导模式：
对应于不同的人，也就需要不同的方式，来带领他/她们完成任务：
- 指导式（Directing）、告知式，对成员的角色和目标给予详尽的指导，并密切监督员工的工作成效，以便对工作成果给予经常的反馈。
- 教练式（Coaching），向团队成员解释工作内容以及工作方法，同时继续指导成员如何完成任务。
- 参与式（Participating），和团队成员共同面对问题，制定解决方案，并给予鼓励和支持；
- 委托式（Delegating），提供适当的资源，完全相信成员的能力，将工作任务交由员工全权负责、独立作业。
事实上，这都是一些方法的总结，在我们日常在也都各自用到了。
随后，我们还需要掌握好，如何进行有效的表达：
- 定：定方向，明确沟通的目的以及重要性，为什么会有这次沟通谈话
- 理：理情况，理清当前的事实，有哪些问题、疑虑，相互交换信息
- 想：想方案，针对当前的问题有哪些解决方案，需要什么样的支持，需要哪些资源等等
- 明：明做法，制定出行动计划，如何进行后续的追踪，发生变化如何应对
- 做：做总结，总结这次沟通的要点，给予 信心/鼓励
方法论真是太多，太多了~。
既然我们设定了 Tech Lead 的三个维度，那么相应的提升也就放在三个维度的提升上。
对于 Developer 来说：面向对象编程、函数式编程，结对编程技能，熟练使用各式的工具，迭代和增量式设计，设计模式，重构，自动化测试，类设计……，一个都不能少。
所以，此处省略一万个字……。
关于架构相关的部分，我们已经在上面的部分里，划定了要学习的一些重点。这里就强调一下演进式架构和跨功能性需求。
演进式架构是一种支持将增量式、指导式的变更作为跨多个维度中的第一原则的架构。
大概，这是我司强调的重要架构吧~。
跨功能性需求，又可以称为非功能性需求，是指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求。它们一般以 “xx性” 结尾，即英文都是以 “ility” 结尾，如稳定性（stability，可移植性（portability）。维基百科上，有一份相关的列表：List of system quality attributes。这些需求又可以分为两类 1：
- 运行质量（Execution qualities），可以在系统运作时观察到的质量，例如保安性及易用性等。
- 发展质量（Evolution qualities），和软件系统结构及开发过程有关的质量，例如软件可测试性、可维护性、可扩展性、可伸缩性（scalability）等
这些跨功能需求，是我们在启动项目（Inception）的时候，需要不断咨询干系人才能得到想要的内容。如向客户，寻问他/她们当前的用户数，以计算支持的并发数。了解客户对于网站的可用性要求，即一年时间内网站允许的宕机时间：
描述 | 通俗叫法 | 可用性级别 | 年度宕机时间 --------|------------|-----------| 基本可用性 | 2 个 9 | 99% | 87.6 小时 较高可用性 | 3 个 9 | 99.9% | 8.8小时 具有故障自动恢复能力的可用性 | 4 个 9 | 99.99% | 53 分钟 极高可用性 | 5 个 9 | 99.999% | 5分钟
更高的可用性，意味着更高的投入成本，才能降低服务器的宕机时长。
推荐书单
- 《架构整洁之道》
显然，对于一个 Geek 来说，软技能才是最大的考验。
为了正确的激励自己和他/她人，就需要识别出真正能影响内在驱动力因素。在《管理 3.0》一书中提到的 CHAMPFROGS Model，即 10 个内在动机：
- 好奇心（Curiosity）：我有很多事情需要调查研究和思考。
- 荣誉感（Honor）：我个人的价值体现在团队中，这大大提高了我的忠诚度。
- 接受度（Acceptance）：我周围的人能够证明我做了什么，我是谁。
- 精通（Mastery）：我的工作对我的能力是一种挑战，但这种挑战依然在我能力范围之内。
- 能量（Power）：我有足够的空间去影响我周围发生的事情。
- 自由度（Freedom）：我与其他的人相互独立，我有自己的工作和责任。
- 关联性（Relatedness）：我与我周围的人有良好的社会关系。
- 有序（Order）：有足够的规则和政策能够构建一个稳定的环境。
- 目标（Goal）：我生活的目标体现在我所做的工作中。
- 状态（Status）：我的位置很好，得到了同事的认可。
每个人按自己的动机进行排序，而后有针对性地帮助他/她们：
在项目中，难免会遇到各式各样的冲突，诸如业务人员之间的冲突。它依赖于我们采用一定的模式来解决这些冲突。
这个时候，我们就需要 Thomas-Kilmann 冲突理论 （TKI）：
再采取相应的策略：
谈判分为软式谈判、硬式谈判、原则式谈判。对于原则式谈判（Principled Negotiation）：
- 尽量扩大总体利益（追求双⽅背后的共同目标和利益）
- 善于营造公开、公平、公正的竞争局面（以共赢为⽬标）
- 明确目标，善于妥协（认识并善⽤⾃己的相对实⼒力）
- 讲究信用
- 求同存异（制定让步和选择空间的战略）
- 使用客观标准（努⼒理解对方，换位思考）
- 运用事实
- 人、事有别（对事不对人；沟通得当）
为此在谈判之前，要做好一系列的准备工作。
不作准备，就是在准备失败。
从初始阶段起，项目便充满着各种的风险，也包含了很多的技术风险。作为一个 Tech Lead，管理这些风险也是我们的职责所在。其中的某些不确定性，会随着项目的进行，不断地减少。即不确定性之锥，描述了项目中不确定性量的演变过程，即不确定性不仅随着时间的流逝而减少，而且也随风险管理，特别是决策的确立而减小。如下图所示：
随着更多的研究和开发，有关项目的更多信息被学习，然后不确定性趋于减少，当所有剩余风险被终止或转移时达到 0 ％。
为此，我们需要评估一下如何去应对这样的风险，对应的有四个维度的展示方式：
- 避免：描述不接受时，它会给你带来什么好处
- 牵制：估计可能性
- 缓和：描述你将采取什么步骤
- 规避：描述风险成为问题时的全部成本
对应的以下是各自的影响：
| 成本 | 大体时间 | 预期结果 | |
|---|---|---|---|
| ︎避免 | 未来受益 | 未来 | ⬇ 可能性 |
| 牵制 | 机会成本 | 现在，未来 | ⬇ 影响 |
| 缓和 | 时间，精力，资源 | 现在 | ⬇ 可能性 ⬇ 影响 |
| 规避 | 0 | - | - |
相关资料，文章《“不确定性之锥” 告诉你项目难度为何有 16 倍的差距》：https://zhuanlan.zhihu.com/p/32033094
项目干系人包括项目当事人、其行为能影响项目的计划与实施，以及其利益受该项目影响（受益或受损）的个人和组织；也可以把他们称作项目的利害关系者。
从他/她的支持程度和赞同程度来看，我们可以在坐标轴上，标出他/她的位置：
对应的，则需要采取不同的沟通策略。
在团队对话的时候，需要注意一些对话相关的风格。如下是四种不同的对话风格：
可以尝试用罗伯特·西奥迪尼《影响力》（Influence: Science and Practice）一书中，介绍的影响力的六大原则来构建相关的影响力，即：
- 互惠互利。
- 承诺一致。
- 社会认同。
- 好感。
- 权威。
- 稀缺。
每个人都有自己擅长的部分，从自己擅长的部分出发。
当我们空降到一个新的团队，成为一个 Tech Lead，要让其他/她人信服，并不是一件容易的事。为此，我们可以尝试这么去做：
- Foreign -> Inclusion：优秀的自我介绍，快速熟悉项目的信息，理解、并倾听当前项目的问题，快速熟悉团队，展示你的能力和承诺
- Inclusion -> Influence：了解相关的技术细节，明确表明行动，主动，同理心，以身作则，从小的成功开始
- Influence -> Openness：收集忧虑，要求/给反馈，聊八卦，显示我们的弱点，承认错误，促进会议/分享，一起做个饭，社交活动
这些都只是一些方法论，首先去 证明你自己的价值，然后拉近和其他/她人的关系。
接下来，我们将介绍一些工具来帮助我们更好的开展 Tech Lead 相关的工作。值得注意的是，它们都需要不断扡维护。
Path to Production 是以可视化的方式，来展示应用是如何上线的。如下图所示：
（PS：相关的可视化工具见：https://phodal.github.io/path/）
在过程中，我们关注于 Process、People、Tooling、Artifacts 四个部分，来了解一个项目需要哪些流程、人、工具和产物。
除了用于展示的目的，发现每个流程的持续时间（Duration），我们还可以找到项目的痛点（ Pain）。
它需要持续不断地更新。
C4 Model 是一个非常不错的架构可视化工具，它从系统 System、容器 Container、组件 Component 和代码 Code 四个层次，由顶至底来介绍系统的架构：
它们的关系类似于：
它需要持续不断地更新。
ADR 架构决策记录，是一个类似于亚历山大模式（即：设计模式）的短文本文件。（虽然决策本身不一定是模式，但它们分享着力量的特征平衡。）每个记录都描述了一组力量和一个响应这些力量的决策。
（PS：相关的工具有 adr-tools 和适用于中文语言的 https://github.com/phodal/adr ）
它需要持续不断地更新。
技术债，是你欠下的东西，需要去还。如果只记在心里，那么可能早晚会忘记，所以要可视化出来：
而如图所示，并不是所有的技术债都值得立马去修。成本高，而收益低的工作，可以以后再做嘛（很久很久以后，直到所有的人都忘记了）。
技术雷达是一个非常不错的季度技术总结。我们可以从中获取，技术专家们对于技术趋势的一些判断，一些可能采用的新技术。而不是自己将时间花费在大量地、不同的技术上，转而可以关注自己需要的那一部分：
当然了，也可以建立自己内部的技术雷达。如我在很久以前的项目里，就尝试过：
时间太久了，这个审美和今天的差别有点大。
你呢，还有什么工具推荐？
- Risk-storming（风险风暴）
- 六顶思考帽
万能的坐标轴法，只要能设计各个维度，就可以进行相关的分析了。
- 文章《技术领导者即服务》： https://zhuanlan.zhihu.com/p/27535777
- PPT 《第一次当 Tech Lead 时，我希望知道的事》：https://www.slideshare.net/thekua/what-i-wish-i-knew-as-a-first-time-tech-lead
- 文章《Tech Lead 的责任环》：https://www.thekua.com/atwork/2015/06/tech-lead-circles-of-responsibility/
- 文章《准备好开启你的领导力之路了吗？》：https://insights.thoughtworks.cn/be-a-excellent-leader/
- 画重点： PPT《Technical Lead Skills for Developer》：https://www.slideshare.net/thekua/tech-lead-skills-for-developers
- 文章《可视化架构设计——C4介绍》: https://insights.thoughtworks.cn/c4-model/
- PPT《Create Lasting Influence》：https://www.slideshare.net/sumeet.moghe/create-lasting-influence