Posted by: Phodal Huang in 杂谈 April 16, 2019, 7:13 p.m.

技术影响力这个东西，每个人都有自己的想法，有的人觉得是个好事，有的人觉得会浪费时间；每个人都有自己的目的，有的想赚一些业余的钱，有想提供一些 KPI，这些都无可厚非。

Posted by: Phodal Huang in 杂谈 April 1, 2019, 8:58 p.m.

规模化的组织，经常要面临这样的挑战：每个应用的基础设施是相同的，部分的代码也是相同的，甚至于它们可能只是数据模型不同而已。结果却导致了，他/她们要一次又一次地重新编写一个应用。

Posted by: Phodal Huang in 杂谈 April 1, 2019, 12:50 p.m.

但是，在 9012 年的今天，前端应用走向了 MV* 的架构方案，也有了一层很重的 View 层——类似于过去的后端应用，或者后端应用。相似的架构，也可以在前端项目中使用。

Posted by: Phodal Huang in 杂谈 March 25, 2019, 8:58 p.m.

Copy-Paste 是一件非常有效的开发方式，但是它们一点儿也不适合维护——为了改一个拼写错误，要去修改代码中的七八个文件，打人的心都有了。

Posted by: Phodal Huang in 杂谈 March 21, 2019, 9:21 p.m.

基于 Web 与混合应用框架的架构，设计一个实时聊天工具，并不是一件轻松的工作。

Posted by: Phodal Huang March 18, 2019, 8:54 p.m.

自我开始练习画插画以来，经常会有人寻问相关的事宜，诸如使用什么工具，选择什么软件，以及有什么相关的模仿对象等等的问题。既然大家都觉得它相当的有价值，那么也就有必要写一篇文章来介绍相关的内容了。

Posted by: Phodal Huang March 13, 2019, 8:07 p.m.

无论是向新人介绍项目，又或者是上到一个新的项目，我们都需要事无巨细地列出一个个的关注点。既然如此，那么为什么创建一个检查清单，用来帮助我们一个个的检查一遍呢。

Posted by: Phodal Huang in GitHub March 11, 2019, 8:57 p.m.

每天打开 GitHub Trending，都是各种面试指南，这样的生活真难受。如果你的项目是金子，那么请读读这篇文章。

Posted by: Phodal Huang in Serverless March 4, 2019, 8:03 p.m.

最近的几年里，每个人在密码上都遇到越来越多的挑战，即需要一个复杂的密码，又需要能记得住它们——两者几乎不可兼得。于是乎，我们开始使用上各式各样的密码管理器，并为之付上了费。又或者是一些开源的、不能同步的密码管理工具——毕竟服务器是要钱的。

Posted by: Phodal Huang March 3, 2019, 3:44 p.m.

目录： * [Tech Lead](#tech-lead) * [为什么我们需要 Tech Lead？](#%E4%B8%BA%E4%BB%80%E4%B9%88%E6%88%91%E4%BB%AC%E9%9C%80%E8%A6%81-tech-lead%EF%BC%9F) * [什么是 Tech Lead？](#%E4%BB%80%E4%B9%88%E6%98%AF-tech-lead%EF%BC%9F) * [如何成为 Tech Lead？](#%E5%A6%82%E4%BD%95%E6%88%90%E4%B8%BA-tech-lead%EF%BC%9F) * [Tech Lead 需要哪些能力？](#tech-lead-%E9%9C%80%E8%A6%81%E5%93%AA%E4%BA%9B%E8%83%BD%E5%8A%9B%EF%BC%9F) * [Tech Lead 责任边界](#tech-lead-%E8%B4%A3%E4%BB%BB%E8%BE%B9%E7%95%8C) * [Tech Lead 能力模型](#tech-lead-%E8%83%BD%E5%8A%9B%E6%A8%A1%E5%9E%8B) * [项目生命周期中的 Tech Lead](#%E9%A1%B9%E7%9B%AE%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F%E4%B8%AD%E7%9A%84-tech-lead) * [技术准备期（磨合期）](#%E6%8A%80%E6%9C%AF%E5%87%86%E5%A4%87%E6%9C%9F%EF%BC%88%E7%A3%A8%E5%90%88%E6%9C%9F%EF%BC%89) * [业务回补期](#%E4%B8%9A%E5%8A%A1%E5%9B%9E%E8%A1%A5%E6%9C%9F) * [成长优化期](#%E6%88%90%E9%95%BF%E4%BC%98%E5%8C%96%E6%9C%9F) * [其它](#%E5%85%B6%E5%AE%83) * [Tech Lead 关注哪些内容？](#tech-lead-%E5%85%B3%E6%B3%A8%E5%93%AA%E4%BA%9B%E5%86%85%E5%AE%B9%EF%BC%9F) * [Programming](#programming) * [自己的编码时间：>30%。](#%E8%87%AA%E5%B7%B1%E7%9A%84%E7%BC%96%E7%A0%81%E6%97%B6%E9%97%B4%EF%BC%9A30%E3%80%82) * [建立规范、原则、模式](#%E5%BB%BA%E7%AB%8B%E8%A7%84%E8%8C%83%E3%80%81%E5%8E%9F%E5%88%99%E3%80%81%E6%A8%A1%E5%BC%8F) * [构建团队文化（技术）](#%E6%9E%84%E5%BB%BA%E5%9B%A2%E9%98%9F%E6%96%87%E5%8C%96%EF%BC%88%E6%8A%80%E6%9C%AF%EF%BC%89) * [创造技术远景](#%E5%88%9B%E9%80%A0%E6%8A%80%E6%9C%AF%E8%BF%9C%E6%99%AF) * [People](#people) * [心流：不同时期的不同挑战](#%E5%BF%83%E6%B5%81%EF%BC%9A%E4%B8%8D%E5%90%8C%E6%97%B6%E6%9C%9F%E7%9A%84%E4%B8%8D%E5%90%8C%E6%8C%91%E6%88%98) * [确保团队的多样性](#%E7%A1%AE%E4%BF%9D%E5%9B%A2%E9%98%9F%E7%9A%84%E5%A4%9A%E6%A0%B7%E6%80%A7) * [打造学习文化](#%E6%89%93%E9%80%A0%E5%AD%A6%E4%B9%A0%E6%96%87%E5%8C%96) * [赢得信任](#%E8%B5%A2%E5%BE%97%E4%BF%A1%E4%BB%BB) * [Process](#process) * [提升 Tech Lead 能力](#%E6%8F%90%E5%8D%87-tech-lead-%E8%83%BD%E5%8A%9B) * [Developer](#developer) * [Architecture](#architecture) * [演进式架构](#%E6%BC%94%E8%BF%9B%E5%BC%8F%E6%9E%B6%E6%9E%84) * [跨功能性需求](#%E8%B7%A8%E5%8A%9F%E8%83%BD%E6%80%A7%E9%9C%80%E6%B1%82) * [Leadership](#leadership) * [激励](#%E6%BF%80%E5%8A%B1) * [处理冲突：谈判](#%E5%A4%84%E7%90%86%E5%86%B2%E7%AA%81%EF%BC%9A%E8%B0%88%E5%88%A4) * [管理风险](#%E7%AE%A1%E7%90%86%E9%A3%8E%E9%99%A9) * [干系人分析](#%E5%B9%B2%E7%B3%BB%E4%BA%BA%E5%88%86%E6%9E%90) * [影响（Influence）](#%E5%BD%B1%E5%93%8D%EF%BC%88influence%EF%BC%89) * [空降 Tech Lead](#%E7%A9%BA%E9%99%8D-tech-lead) * [Tech Lead 工具箱](#tech-lead-%E5%B7%A5%E5%85%B7%E7%AE%B1) * [Path to Production：上线可视化](#path-to-production%EF%BC%9A%E4%B8%8A%E7%BA%BF%E5%8F%AF%E8%A7%86%E5%8C%96) * [C4 Model：架构可视化](#c4-model%EF%BC%9A%E6%9E%B6%E6%9E%84%E5%8F%AF%E8%A7%86%E5%8C%96) * [ADR：架构决策记录](#adr%EF%BC%9A%E6%9E%B6%E6%9E%84%E5%86%B3%E7%AD%96%E8%AE%B0%E5%BD%95) * [技术债墙：技术债的可视化](#%E6%8A%80%E6%9C%AF%E5%80%BA%E5%A2%99%EF%BC%9A%E6%8A%80%E6%9C%AF%E5%80%BA%E7%9A%84%E5%8F%AF%E8%A7%86%E5%8C%96) * [技术雷达：保持技术的敏锐度](#%E6%8A%80%E6%9C%AF%E9%9B%B7%E8%BE%BE%EF%BC%9A%E4%BF%9D%E6%8C%81%E6%8A%80%E6%9C%AF%E7%9A%84%E6%95%8F%E9%94%90%E5%BA%A6) * [其它](#%E5%85%B6%E5%AE%83-1) * [小结](#%E5%B0%8F%E7%BB%93) * [相关资料](#%E7%9B%B8%E5%85%B3%E8%B5%84%E6%96%99) 2019 年 1 月 19 日 ~ 2019 年 1 月 20 日，蹭了一个公司的 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 工具箱 ## 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 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？ 首先，看运气……。每个组织的坑位都是有限的——一个萝卜一个坑。我第一次当 Tech Lead 的时候，是在毕业一年左右的日子。项目上的 TL 和 PM 相继离职创业去了，剩下的人里，我大概是最熟悉项目相关的业务知识和技术知识。我就这么莫名其妙地承担了相关的角色。不过，这并不重要，重要的是有这个坑位突然空出来给你了。 其次，展示你的气质和技术专长。除了你自己，没有人知道你擅长哪些东西。这样一来，你就很可能成为项目上的 2nd Tier（第二梯队，简称备胎）。一旦人们觉得你是个好苗子，那么成为 Tech Lead 就会从 0.01% 提升到了 1%。 最后，还是看运气……。若是你们的组织里，一直有一个人技术比你好，而且这个人一直和你在一个项目里。天晓得，你这个万年老二，什么时候才能翻身。你还年轻，你熬过对方的。 不过，这些也都不重要——不要靠天吃饭，还是要靠嘴吃饭。我们所要做的是，时刻准备着——提升技术，掌握 Tech Lead 技能。 ## Tech Lead 需要哪些能力？ In my option，a Tech Lead should have those skills: - 首先，要会吹 NB。 - 其次，知道怎么画饼。 - 然后，还要精通 PPT。 - 最后，还会精通 markdown 编程。 哦，好像不太对，上述都是瞎扯。 ### Tech Lead 责任边界 下图是 Patrick Kua （前 ThoughtWorks 大不列颠及北爱尔兰联合王国区的 Principal Technical Consultant ）提出的 Tech Lead 的责任范围。换句话来说，它便是 Tech Lead 所要做的工作。  图上的内容主要分为三部分： - Developer。作为一个开发人员，我们应该掌握好编程相关的技能：**面向对象编程、函数式编程，结对编程技能，熟练使用各式的工具，迭代和增量式设计，设计模式，重构，自动化测试，类设计**。 - Architect。作为项目中的架构师，我们要考虑的因素有：**跨功能需求，演进式架构，买还是做的决策，系统设计，计划评估，技术风险管理，科技愿景和凝聚力，关注全生命周期，广泛的工具集，基础设施，客户引导**。 - Leadership。作为一个技术上的 Lead，我们要提升这些软技能：**反馈、沟通，教练，动机，关系构建，委托，影响，风险管理，冲突管理，团队管理**。 好吧，我承认要学习的东西太多了，尤其是对于一个目标是 Tech Lead 的程序员来说。即要成为一个优秀的开发人员，还要成长为一个架构师，最后还要在领导上有所提升。首先，我们可以成为那个技术最 NB 的人（best technical person），然后我们才能成为 Tech Lead。至少领导力什么的，在技术准备充分之前，适当地花时间注意练习即可。 ### Tech Lead 能力模型 对应于此，我们也就有了自己的 （ThoughtWorks）的 Tead Lead 自测模型。从下图可以看出，它是在上图的基础上整理出来的：  （PS：欢迎基于 [https://phodal.github.io/tla/](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 做的事情，每个人在日常中，到底还是看得一清二楚。可是呢，项目上的每一个人，并非都是从一开始就在这个项目中的。有一些是一开始加入的，一些是早期加入的，还有的则是中途加入的。 也因此呢，我便根据 Tech Lead 要做的一些事情，再按照之前定义的[项目三步曲](https://www.phodal.com/blog/short-time-project-best-practise/)，绘制了一个在项目不同时间的 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 关注哪些内容？ 作为一个 Tech Lead，我们在项目上主要关注于三个部分： - Programming - People - Process 同样的，在不同的项目时期，也会执行不同的工作——部分内容我们在三步曲中已经介绍过。 ### Programming 编程，是 Tech Lead 的基本功。不论我们多忙，我们总需要深入代码库，了解代码中的问题。 #### 自己的编码时间：>30%。 作为一个 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 People，是一个项目的重要因素。 #### 心流：不同时期的不同挑战 在项目的不同时间里，对于不同的人来说，他/她们都有不同的感受。这便是心流：  项目的初期，对于大部分的人来说，属于挑战水平高，技术水平一般（对项目不熟悉）的水平。而在项目的中后期，对于大部分的人来说，则项目处于无聊或者无感的状态。在焦虑期，指导新人；在无聊期，创建一些技术挑战……。 作为 Tech Lead 则需要在不同地时期，帮助其他/她人成长。从 Interests、Skills、Strengths、Goals 等不同的维度考虑，了解每个人的不同阶段，帮助他/她们成长。  从某种意义上来看，我们需要了解每一个团队人员的当前位置，而后帮他/也成长。而在项目启动的时候，也可以一起进行头脑风暴，了解每个人在这个项目上的四种诉求。 #### 确保团队的多样性 不得不提及的一句话： > 群体能力=平均个人能力+多样性 若是团队里没有反对的声音，取而代之的是沉默，那么团队就是有问题的。所以，要允许反对的声音。哪怕是错的，也需要等他/她说完。 #### 打造学习文化 作为一个 Geek，我们总会想着努力不断地提升自己的技术，想和那些优秀的人一起工作。可往往由于多种因素的限制，优秀的人总会到新的项目上。也只能自己成为一个优秀的人，并带领其他/她人成为优秀的人，便可以与优秀的人一起工作。 为此，我们需要引入相关的知识分享文化技术写作、读书分享、结对编程、代码检视、技术回顾会议等。 #### 赢得信任 Tech Lead 保证技术实施的一个关键是，大家都信任你。一旦大家都不信任你的时候，又或者是你不信任自己的时候，那么这个项目就会出现问题。它需要我们一步步地去构建出信任感。 除此，当你空降到一个新的团队时，你作为 Tech Lead，便面临着不少的挑战。陌生的代码库，试探你能力的成员……。 ### Process 不同的项目都有各种的流程，都有自己所处的时期。这里就需要用到 Bruce Tuckman 的团队发展阶段模型（Tuckman Stages of Team Development Model）：  即： - 组建期。（Forming）项目小组启蒙阶段。 - 激荡期。（Storming）形成各种观念，激烈竞争、碰撞的局面。 - 规范期。（Norming）规则，价值，行为，方法，工具均已建立。 - 执行期。（Performing）人际结构成为执行任务活动的工具，团队角色更为灵活和功能化，团队能量积聚于一体。 - 休整期。（Adjourning） 任务完成，团队解散。 它可以帮助我们对团队有清晰的认识，随后采取相应的行动，来帮助团队成员明确目标。 而针对于不同的人来说，我们还需要即**情境领导模式**：  对应于不同的人，也就需要不同的方式，来带领他/她们完成任务： - 指导式（Directing）、告知式，对成员的角色和目标给予详尽的指导，并密切监督员工的工作成效，以便对工作成果给予经常的反馈。 - 教练式（Coaching），向团队成员解释工作内容以及工作方法，同时继续指导成员如何完成任务。 - 参与式（Participating），和团队成员共同面对问题，制定解决方案，并给予鼓励和支持； - 委托式（Delegating），提供适当的资源，完全相信成员的能力，将工作任务交由员工全权负责、独立作业。 事实上，这都是一些方法的总结，在我们日常在也都各自用到了。 随后，我们还需要掌握好，如何进行有效的表达： - 定：定方向，明确沟通的目的以及重要性，为什么会有这次沟通谈话 - 理：理情况，理清当前的事实，有哪些问题、疑虑，相互交换信息 - 想：想方案，针对当前的问题有哪些解决方案，需要什么样的支持，需要哪些资源等等 - 明：明做法，制定出行动计划，如何进行后续的追踪，发生变化如何应对 - 做：做总结，总结这次沟通的要点，给予 信心/鼓励 方法论真是太多，太多了~。 ## 提升 Tech Lead 能力 既然我们设定了 Tech Lead 的三个维度，那么相应的提升也就放在三个维度的提升上。 ### Developer 对于 Developer 来说：面向对象编程、函数式编程，结对编程技能，熟练使用各式的工具，迭代和增量式设计，设计模式，重构，自动化测试，类设计……，一个都不能少。 所以，此处省略一万个字……。 ### Architecture 关于架构相关的部分，我们已经在上面的部分里，划定了要学习的一些重点。这里就强调一下演进式架构和跨功能性需求。 #### 演进式架构 > 演进式架构是一种支持将增量式、指导式的变更作为跨多个维度中的第一原则的架构。 大概，这是我司强调的重要架构吧~。 #### 跨功能性需求 跨功能性需求，又可以称为非功能性需求，是指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求。它们一般以 “xx性” 结尾，即英文都是以 “ility” 结尾，如稳定性（stability，可移植性（portability）。维基百科上，有一份相关的列表：[List of system quality attributes](https://en.wikipedia.org/wiki/List_of_system_quality_attributes)。这些需求又可以分为两类 [^wiki_nonfun]： - 运行质量（Execution qualities），可以在系统运作时观察到的质量，例如保安性及易用性等。 - 发展质量（Evolution qualities），和软件系统结构及开发过程有关的质量，例如软件可测试性、可维护性、可扩展性、可伸缩性（scalability）等 [^wiki_nonfun]: https://zh.wikipedia.org/wiki/%E9%9D%9E%E5%8A%9F%E8%83%BD%E6%80%A7%E9%9C%80%E6%B1%82 这些跨功能需求，是我们在启动项目（Inception）的时候，需要不断咨询干系人才能得到想要的内容。如向客户，寻问他/她们当前的用户数，以计算支持的并发数。了解客户对于网站的可用性要求，即一年时间内网站允许的宕机时间： 描述 | 通俗叫法 | 可用性级别 | 年度宕机时间 --------|------------|-----------| 基本可用性 | 2 个 9 | 99% | 87.6 小时 较高可用性 | 3 个 9 | 99.9% | 8.8小时 具有故障自动恢复能力的可用性 | 4 个 9 | 99.99% | 53 分钟 极高可用性 | 5 个 9 | 99.999% | 5分钟 更高的可用性，意味着更高的投入成本，才能降低服务器的宕机时长。 **推荐书单** - 《架构整洁之道》 ### Leadership 显然，对于一个 Geek 来说，软技能才是最大的考验。 #### 激励 为了正确的激励自己和他/她人，就需要识别出真正能影响内在驱动力因素。在《管理 3.0》一书中提到的 CHAMPFROGS Model，即 10 个内在动机： - 好奇心（Curiosity）：我有很多事情需要调查研究和思考。 - 荣誉感（Honor）：我个人的价值体现在团队中，这大大提高了我的忠诚度。 - 接受度（Acceptance）：我周围的人能够证明我做了什么，我是谁。 - 精通（Mastery）：我的工作对我的能力是一种挑战，但这种挑战依然在我能力范围之内。 - 能量（Power）：我有足够的空间去影响我周围发生的事情。 - 自由度（Freedom）：我与其他的人相互独立，我有自己的工作和责任。 - 关联性（Relatedness）：我与我周围的人有良好的社会关系。 - 有序（Order）：有足够的规则和政策能够构建一个稳定的环境。 - 目标（Goal）：我生活的目标体现在我所做的工作中。 - 状态（Status）：我的位置很好，得到了同事的认可。 每个人按自己的动机进行排序，而后有针对性地帮助他/她们：  #### 处理冲突：谈判 在项目中，难免会遇到各式各样的冲突，诸如业务人员之间的冲突。它依赖于我们采用一定的模式来解决这些冲突。 这个时候，我们就需要 **Thomas-Kilmann 冲突理论 （TKI）**：  再采取相应的策略：  谈判分为**软式谈判、硬式谈判、原则式谈判**。对于**原则式谈判**（Principled Negotiation）： 1. 尽量扩大总体利益（追求双⽅背后的共同目标和利益） 2. 善于营造公开、公平、公正的竞争局面（以共赢为⽬标） 3. 明确目标，善于妥协（认识并善⽤⾃己的相对实⼒力） 4. 讲究信用 5. 求同存异（制定让步和选择空间的战略） 6. 使用客观标准（努⼒理解对方，换位思考） 7. 运用事实 8. 人、事有别（对事不对人；沟通得当） 为此在谈判之前，要做好一系列的准备工作。 #### 管理风险 > 不作准备，就是在准备失败。 从初始阶段起，项目便充满着各种的风险，也包含了很多的技术风险。作为一个 Tech Lead，管理这些风险也是我们的职责所在。其中的某些不确定性，会随着项目的进行，不断地减少。即**不确定性之锥**，描述了项目中不确定性量的演变过程，即不确定性不仅随着时间的流逝而减少，而且也随风险管理，特别是决策的确立而减小。如下图所示：  随着更多的研究和开发，有关项目的更多信息被学习，然后不确定性趋于减少，当所有剩余风险被终止或转移时达到 0 ％。 为此，我们需要评估一下如何去应对这样的风险，对应的有四个维度的展示方式： - 避免：描述不接受时，它会给你带来什么好处 - 牵制：估计可能性 - 缓和：描述你将采取什么步骤 - 规避：描述风险成为问题时的全部成本 对应的以下是各自的影响： | | 成本 | 大体时间 | 预期结果 | |------|-----|------------|---------------| | ︎避免 | 未来受益 | 未来 | ⬇ 可能性 | | 牵制 | 机会成本 | 现在，未来 | ⬇ 影响 | | 缓和 | 时间，精力，资源 | 现在 | ⬇ 可能性 ⬇ 影响 | | 规避 | 0 | - | - | 相关资料，文章《“不确定性之锥” 告诉你项目难度为何有 16 倍的差距》：https://zhuanlan.zhihu.com/p/32033094 #### 干系人分析 > 项目干系人包括项目当事人、其行为能影响项目的计划与实施，以及其利益受该项目影响（受益或受损）的个人和组织；也可以把他们称作项目的利害关系者。 从他/她的支持程度和赞同程度来看，我们可以在坐标轴上，标出他/她的位置：  对应的，则需要采取不同的沟通策略。 #### 影响（Influence） 在团队对话的时候，需要注意一些对话相关的风格。如下是四种不同的对话风格：  可以尝试用罗伯特·西奥迪尼《影响力》（Influence: Science and Practice）一书中，介绍的**影响力的六大原则**来构建相关的影响力，即： 1. 互惠互利。 2. 承诺一致。 3. 社会认同。 4. 好感。 5. 权威。 6. 稀缺。 每个人都有自己擅长的部分，从自己擅长的部分出发。 #### 空降 Tech Lead 当我们空降到一个新的团队，成为一个 Tech Lead，要让其他/她人信服，并不是一件容易的事。为此，我们可以尝试这么去做： 1. Foreign -> Inclusion：优秀的自我介绍，快速熟悉项目的信息，理解、并倾听当前项目的问题，快速熟悉团队，展示你的能力和承诺 2. Inclusion -> Influence：了解相关的技术细节，明确表明行动，主动，同理心，以身作则，从小的成功开始 3. Influence -> Openness：收集忧虑，要求/给反馈，聊八卦，显示我们的弱点，承认错误，促进会议/分享，一起做个饭，社交活动 这些都只是一些方法论，首先去 **证明你自己的价值**，然后拉近和其他/她人的关系。 ## Tech Lead 工具箱 接下来，我们将介绍一些工具来帮助我们更好的开展 Tech Lead 相关的工作。值得注意的是，它们都需要不断扡维护。 ### Path to Production：上线可视化 Path to Production 是以可视化的方式，来展示应用是如何上线的。如下图所示：  （PS：相关的可视化工具见：） 在过程中，我们关注于 Process、People、Tooling、Artifacts 四个部分，来了解一个项目需要哪些流程、人、工具和产物。 除了用于展示的目的，发现每个流程的持续时间（Duration），我们还可以找到项目的痛点（ Pain）。 **它需要持续不断地更新**。 ### C4 Model：架构可视化 C4 Model 是一个非常不错的架构可视化工具，它从系统 System、容器 Container、组件 Component 和代码 Code 四个层次，由顶至底来介绍系统的架构：  它们的关系类似于：  **它需要持续不断地更新**。 ### ADR：架构决策记录 ADR 架构决策记录，是一个类似于亚历山大模式（即：设计模式）的短文本文件。（虽然决策本身不一定是模式，但它们分享着力量的特征平衡。）每个记录都描述了一组力量和一个响应这些力量的决策。  （PS：相关的工具有 adr-tools 和适用于中文语言的 [https://github.com/phodal/adr](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

Tags:
• tech lead