上上周末,蹭了一个公司的 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 工具箱
考虑到文章的长度,先上几张图:
1. 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 技能。
2. 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。作为一个开发人员,我们应该掌握好编程相关的技能:面向对象编程、函数式编程,结对编程技能,熟练使用各式的工具,迭代和增量式设计,设计模式,重构,自动化测试,类设计。
-
Architectue。作为项目中的架构师,我们要考虑的因素有:跨功能需求,演进式架构,买还是做的决策,系统设计,计划评估,技术风险管理,科技愿景和凝聚力,关注全生命周期,广泛的工具集,基础设施,客户引导。
-
Leadership。作为一个技术上的 Lead,我们要提升这些软技能:反馈、沟通,教练,动机,关系构建,委托,影响,风险管理,冲突管理,团队管理。
好吧,我承认要学习的东西太多了,尤其是对于一个目标是 Tech Lead 的程序员来说。即要成为一个优秀的开发人员,还要成长为一个架构师,最后还要在领导上有所提升。首先,我们可以成为那个技术最 NB 的人(best technical person),然后我们才能成为 TechLead。至少领导力什么的,在技术准备充分之前,适当地花时间注意练习即可。
Tech Lead 能力模型
对应于此,我们也就有了自己的 (ThoughtWorks)的 Tead Lead 自测模型。从下图可以看出,它是在上图的基础上整理出来的:
Tech Lead Assessment
(PS:欢迎基于�0�2https://phodal.github.io/tla/�0�2开发你们的 Tech Lead 模型。自测工具使用:1. 从 1 ~ 5 为自己的相关能力打分,再一一连接对应的点数。 2. 在自己想提高的分数上画点,再绘制成圈 2。)
相比之下,我们的 Tech Lead 模型倒是相对比较简单——事项比较少:
-
Leadership。关注于情绪智力、持续影响、积极地发展他/她人、提升效率、积极地打造团队、积极的风险管理、开放沟通
-
Developer。关注于好的编码技能、全栈开发的经验、模式意识、熟悉代码库、持续提升、明确出问题、关注业务价值、沟通桥梁。
-
Architect。关注于架构远景、聚焦于原则,系统、而非软件,支持跨职能需求,未来思考。
但是呢,从技术上来看,每个的维度却远比上述的责任边界要重。从 Leadership 来看,则更有所侧重——侧重于,以技术为主的软技能。
这样一看,确实说了很多的东西,但是过于抽象,反而显得没有一点实际的价值。我们还是对 Tech Lead 要做的事情,还是缺少一个宏观的认识。在那之前,还是让我们回到项目上,来看看项目上的 Tech Lead 的日常
3. 项目生命周期中的 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 在合适的时期,采用合适的策略。
4. 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),提供适当的资源,完全相信成员的能力,将工作任务交由员工全权负责、独立作业。
事实上,这都是一些方法的总结,在我们日常在也都各自用到了。
随后,我们还需要掌握好,如何进行有效的表达:
-
定:定方向,明确沟通的目的以及重要性,为什么会有这次沟通谈话
-
理:理情况,理清当前的事实,有哪些问题、疑虑,相互交换信息
-
想:想方案,针对当前的问题有哪些解决方案,需要什么样的支持,需要哪些资源等等
-
明:明做法,制定出行动计划,如何进行后续的追踪,发生变化如何应对
-
做:做总结,总结这次沟通的要点,给予 信心/鼓励
方法论真是太多,太多了~。
5. 提升 Tech Lead 能力
既然我们设定了 Tech Lead 的三个维度,那么相应的提升也就放在三个维度的提升上。
Developer
对于 Developer 来说:面向对象编程、函数式编程,结对编程技能,熟练使用各式的工具,迭代和增量式设计,设计模式,重构,自动化测试,类设计……,一个都不能少。
所以,此处省略一万个字……。
Archicture
关于架构相关的部分,我们已经在上面的部分里,划定了要学习的一些重点。这里就强调一下演进式架构和跨功能性需求。
演进式架构
演进式架构是一种支持将增量式、指导式的变更作为跨多个维度中的第一原则的架构。
大概,这是我司强调的重要架构吧~。
跨功能性需求
跨功能性需求,又可以称为非功能性需求,是指依一些条件判断系统运作情形或其特性,而不是针对系统特定行为的需求。它们一般以 “xx性” 结尾,即英文都是以 “ility” 结尾,如稳定性(stability,可移植性(portability)。维基百科上,有一份相关的列表:List of system quality attributes。这些需求又可以分为两类�0�2[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):我的位置很好,得到了同事的认可。
每个人按自己的动机进行排序,而后有针对性地帮助他/她们:
动机
处理冲突:谈判
在项目中,难免会遇到各式各样的冲突,诸如业务人员之间的冲突。它依赖于我们采用一定的模式来解决这些冲突。
这个时候,我们就需要�0�2Thomas-Kilmann 冲突理论 (TKI):
TKI
再采取相应的策略:
TKI 策略
谈判分为软式谈判、硬式谈判、原则式谈判。对于原则式谈判(Principled Negotiation):
-
尽量扩大总体利益(追求双�9�1背后的共同目标和利益)
-
善于营造公开、公平、公正的竞争局面(以共赢为�9�0标)
-
明确目标,善于妥协(认识并善�9�2�9�3己的相对实�9�0�0�7)
-
讲究信用
-
求同存异(制定让步和选择空间的战�0�8)
-
使用客观标准(努�9�0�0�6解对方,换位思考)
-
运用事实
-
人、事有别(对事�0�3对人;沟通得当)
为此在谈判之前,要做好一系列的准备工作。
管理风险
不作准备,就是在准备失败。
从初始阶段起,项目便充满着各种的风险,也包含了很多的技术风险。作为一个 Tech Lead,管理这些风险也是我们的职责所在。其中的某些不确定性,会随着项目的进行,不断地减少。即不确定性之锥,描述了项目中不确定性量的演变过程,即不确定性不仅随着时间的流逝而减少,而且也随风险管理,特别是决策的确立而减小。如下图所示:
不确定性之锥
随着更多的研究和开发,有关项目的更多信息被学习,然后不确定性趋于减少,当所有剩余风险被终止或转移时达到 0 %。
为此,我们需要评估一下如何去应对这样的风险,对应的有四个维度的展示方式:
-
避免:描述不接受时,它会给你带来什么好处
-
牵制:估计可能性
-
缓和:描述你将采取什么步骤
-
规避:描述风险成为问题时的全部成本
对应的以下是各自的影响:
成本 | 大体时间 | 预期结果 | |
---|---|---|---|
�1�4避免 | 未来受益 | 未来 | �8�9 可能性 |
牵制 | 机会成本 | 现在,未来 | �8�9 影响 |
缓和 | 时间,精力,资源 | 现在 | �8�9 可能性 �8�9 影响 |
规避 | 0 | - | - |
相关资料,文章《“不确定性之锥” 告诉你项目难度为何有 16 倍的差距》:https://zhuanlan.zhihu.com/p/32033094
干系人分析
项目干系人包括项目当事人、其行为能影响项目的计划与实施,以及其利益受该项目影响(受益或受损)的个人和组织;也可以把他们称作项目的利害关系者。
从他/她的支持程度和赞同程度来看,我们可以在坐标轴上,标出他/她的位置:
Stakeholder Mapping
对应的,则需要采取不同的沟通策略。
影响(Influence)
在团队对话的时候,需要注意一些对话相关的风格。如下是四种不同的对话风格:
影响
可以尝试用罗伯特·西奥迪尼《影响力》(Influence: Science and Practice)一书中,介绍的影响力的六大原则来构建相关的影响力,即:
-
互惠互�0�9。
-
承诺一致。
-
社会认同。
-
好感。
-
权威。
-
稀缺。
每个人都有自己擅长的部分,从自己擅长的部分出发。
空降 Tech Lead
当我们空降到一个新的团队,成为一个 Tech Lead,要让其他/她人信服,并不是一件容易的事。为此,我们可以尝试这么去做:
-
Foreign -> Inclusion:优秀的自我介绍,快速熟悉项目的信息,理解、并倾听当前项目的问题,快速熟悉团队,展示你的能力和承诺
-
Inclusion -> Influence:了解相关的技术细节,明确表明行动,主动,同理心,以身作则,从小的成功开始
-
Influence -> Openness:收集忧虑,要求/给反馈,聊八卦,显示我们的弱点,承认错误,促进会议/分享,一起做个饭,社交活动
这些都只是一些方法论,首先去�0�2证明你自己的价值,然后拉近和其他/她人的关系。
6. 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 和适用于中文语言的�0�2https://github.com/phodal/adr�0�2)
它需要持续不断地更新。
技术债墙:技术债的可视化
技术债,是你欠下的东西,需要去还。如果只记在心里,那么可能早晚会忘记,所以要可视化出来:
技术债墙
而如图所示,并不是所有的技术债都值得立马去修。成本高,而收益低的工作,可以以后再做嘛(很久很久以后,直到所有的人都忘记了)。
技术雷达:保持技术的敏锐度
技术雷达是一个非常不错的季度技术总结。我们可以从中获取,技术专家们对于技术趋势的一些判断,一些可能采用的新技术。而不是自己将时间花费在大量地、不同的技术上,转而可以关注自己需要的那一部分:
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/
-
画重点:�0�2PPT《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