Blog

Blog

PHODAL

迈向 Tech Lead 之路

目录:

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 是一个角色,而非真实的岗位,这个角色的意义在于带领其他/她人前进。两者的定义如下图所示:

Leader vs Boss

那么回想一下,在你的团队里,你是跟着谁一起干活?在做相关的技术工作的时候,你更愿意听谁的话,是你的领导,还是?

我们希望有人带着我们一起干活,比自己优秀的人一起工作,总能从他/她身上学到一些有用的东西。作为一个技术人员,我们服的是那些技术比自己好的人。同样是一个功能,我们实现起来要一天,而他/她可能只需要一个小时——效率既高,质量又好。这样的一个人,便相当于项目中的 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% 的时间来编写。一来,掌握项目相关的一系列技术;二来,不断提升技术能力,而不是成为管理者。

除了技术上的工作,他/她还需要懂业务,以此才能开发出符合业务需求的软件。还需要能管理风险(主要是技术相关的风险),才能对应变化。

Technical Lead 模型 1

这便是 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 所要做的工作。

Tech Lead Circles

图上的内容主要分为三部分:

  • Developer。作为一个开发人员,我们应该掌握好编程相关的技能:面向对象编程、函数式编程,结对编程技能,熟练使用各式的工具,迭代和增量式设计,设计模式,重构,自动化测试,类设计
  • Architect。作为项目中的架构师,我们要考虑的因素有:跨功能需求,演进式架构,买还是做的决策,系统设计,计划评估,技术风险管理,科技愿景和凝聚力,关注全生命周期,广泛的工具集,基础设施,客户引导
  • Leadership。作为一个技术上的 Lead,我们要提升这些软技能:反馈、沟通,教练,动机,关系构建,委托,影响,风险管理,冲突管理,团队管理

好吧,我承认要学习的东西太多了,尤其是对于一个目标是 Tech Lead 的程序员来说。即要成为一个优秀的开发人员,还要成长为一个架构师,最后还要在领导上有所提升。首先,我们可以成为那个技术最 NB 的人(best technical person),然后我们才能成为 Tech Lead。至少领导力什么的,在技术准备充分之前,适当地花时间注意练习即可。

Tech Lead 能力模型

对应于此,我们也就有了自己的 (ThoughtWorks)的 Tead Lead 自测模型。从下图可以看出,它是在上图的基础上整理出来的:

Tech Lead Assessment

(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 做的事情,每个人在日常中,到底还是看得一清二楚。可是呢,项目上的每一个人,并非都是从一开始就在这个项目中的。有一些是一开始加入的,一些是早期加入的,还有的则是中途加入的。

也因此呢,我便根据 Tech Lead 要做的一些事情,再按照之前定义的项目三步曲,绘制了一个在项目不同时间的 TODO Lists。

Tech Lead in Project

需要注意的是:这里仅列出笔者觉得重要的部分(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。这些需求又可以分为两类 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分钟

更高的可用性,意味着更高的投入成本,才能降低服务器的宕机时长。

推荐书单

  • 《架构整洁之道》

Leadership

显然,对于一个 Geek 来说,软技能才是最大的考验。

激励

为了正确的激励自己和他/她人,就需要识别出真正能影响内在驱动力因素。在《管理 3.0》一书中提到的 CHAMPFROGS Model,即 10 个内在动机:

  • 好奇心(Curiosity):我有很多事情需要调查研究和思考。
  • 荣誉感(Honor):我个人的价值体现在团队中,这大大提高了我的忠诚度。
  • 接受度(Acceptance):我周围的人能够证明我做了什么,我是谁。
  • 精通(Mastery):我的工作对我的能力是一种挑战,但这种挑战依然在我能力范围之内。
  • 能量(Power):我有足够的空间去影响我周围发生的事情。
  • 自由度(Freedom):我与其他的人相互独立,我有自己的工作和责任。
  • 关联性(Relatedness):我与我周围的人有良好的社会关系。
  • 有序(Order):有足够的规则和政策能够构建一个稳定的环境。
  • 目标(Goal):我生活的目标体现在我所做的工作中。
  • 状态(Status):我的位置很好,得到了同事的认可。

每个人按自己的动机进行排序,而后有针对性地帮助他/她们:

动机

处理冲突:谈判

在项目中,难免会遇到各式各样的冲突,诸如业务人员之间的冲突。它依赖于我们采用一定的模式来解决这些冲突。

这个时候,我们就需要 Thomas-Kilmann 冲突理论 (TKI)

TKI

再采取相应的策略:

TKI 策略

谈判分为软式谈判、硬式谈判、原则式谈判。对于原则式谈判(Principled Negotiation):

  1. 尽量扩大总体利益(追求双⽅背后的共同目标和利益)
  2. 善于营造公开、公平、公正的竞争局面(以共赢为⽬标)
  3. 明确目标,善于妥协(认识并善⽤⾃己的相对实⼒力)
  4. 讲究信用
  5. 求同存异(制定让步和选择空间的战略)
  6. 使用客观标准(努⼒理解对方,换位思考)
  7. 运用事实
  8. 人、事有别(对事不对人;沟通得当)

为此在谈判之前,要做好一系列的准备工作。

管理风险

不作准备,就是在准备失败。

从初始阶段起,项目便充满着各种的风险,也包含了很多的技术风险。作为一个 Tech Lead,管理这些风险也是我们的职责所在。其中的某些不确定性,会随着项目的进行,不断地减少。即不确定性之锥,描述了项目中不确定性量的演变过程,即不确定性不仅随着时间的流逝而减少,而且也随风险管理,特别是决策的确立而减小。如下图所示:

不确定性之锥

随着更多的研究和开发,有关项目的更多信息被学习,然后不确定性趋于减少,当所有剩余风险被终止或转移时达到 0 %。

为此,我们需要评估一下如何去应对这样的风险,对应的有四个维度的展示方式:

  • 避免:描述不接受时,它会给你带来什么好处
  • 牵制:估计可能性
  • 缓和:描述你将采取什么步骤
  • 规避:描述风险成为问题时的全部成本

对应的以下是各自的影响:

成本 大体时间 预期结果
︎避免 未来受益 未来 ⬇ 可能性
牵制 机会成本 现在,未来 ⬇ 影响
缓和 时间,精力,资源 现在 ⬇ 可能性 ⬇ 影响
规避 0 - -

相关资料,文章《“不确定性之锥” 告诉你项目难度为何有 16 倍的差距》:https://zhuanlan.zhihu.com/p/32033094

干系人分析

项目干系人包括项目当事人、其行为能影响项目的计划与实施,以及其利益受该项目影响(受益或受损)的个人和组织;也可以把他们称作项目的利害关系者。

从他/她的支持程度和赞同程度来看,我们可以在坐标轴上,标出他/她的位置:

Stakeholder Mapping

对应的,则需要采取不同的沟通策略。

影响(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 是以可视化的方式,来展示应用是如何上线的。如下图所示:

Path to Production

(PS:相关的可视化工具见:https://phodal.github.io/path/

在过程中,我们关注于 Process、People、Tooling、Artifacts 四个部分,来了解一个项目需要哪些流程、人、工具和产物。

除了用于展示的目的,发现每个流程的持续时间(Duration),我们还可以找到项目的痛点( Pain)。

它需要持续不断地更新

C4 Model:架构可视化

C4 Model 是一个非常不错的架构可视化工具,它从系统 System、容器 Container、组件 Component 和代码 Code 四个层次,由顶至底来介绍系统的架构:

C4 Model 示例

它们的关系类似于:

地图层级

它需要持续不断地更新

ADR:架构决策记录

ADR 架构决策记录,是一个类似于亚历山大模式(即:设计模式)的短文本文件。(虽然决策本身不一定是模式,但它们分享着力量的特征平衡。)每个记录都描述了一组力量和一个响应这些力量的决策。

ADR

(PS:相关的工具有 adr-tools 和适用于中文语言的 https://github.com/phodal/adr

它需要持续不断地更新

技术债墙:技术债的可视化

技术债,是你欠下的东西,需要去还。如果只记在心里,那么可能早晚会忘记,所以要可视化出来:

 技术债墙

而如图所示,并不是所有的技术债都值得立马去修。成本高,而收益低的工作,可以以后再做嘛(很久很久以后,直到所有的人都忘记了)。

技术雷达:保持技术的敏锐度

技术雷达是一个非常不错的季度技术总结。我们可以从中获取,技术专家们对于技术趋势的一些判断,一些可能采用的新技术。而不是自己将时间花费在大量地、不同的技术上,转而可以关注自己需要的那一部分:

Tech Lead

当然了,也可以建立自己内部的技术雷达。如我在很久以前的项目里,就尝试过:

TechStack

时间太久了,这个审美和今天的差别有点大。

其它

你呢,还有什么工具推荐?

  • 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

  1. https://zh.wikipedia.org/wiki/%E9%9D%9E%E5%8A%9F%E8%83%BD%E6%80%A7%E9%9C%80%E6%B1%82 

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Engineer, Consultant, Writer, Designer

ThoughtWorks 技术专家

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 最新技术分享

标签