Blog
Blog
PHODAL

Viewing posts from March, 2019

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

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

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

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

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

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

目录: * [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 是一个角色,而非真实的岗位**,这个角色的意义在于带领其他/她人前进。两者的定义如下图所示: ![Leader vs Boss](https://phodal.github.io/techlead/assets/leader-vs-boss.jpg) 那么回想一下,在你的团队里,你是跟着谁一起干活?在做相关的技术工作的时候,你更愿意听谁的话,是你的领导,还是? 我们希望有人带着我们一起干活,比自己优秀的人一起工作,总能从他/她身上学到一些有用的东西。作为一个技术人员,我们服的是那些技术比自己好的人。同样是一个功能,我们实现起来要一天,而他/她可能只需要一个小时——效率既高,质量又好。这样的一个人,便相当于项目中的 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](https://phodal.github.io/techlead/assets/tech-lead-butterfly.png) 这便是 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](https://phodal.github.io/techlead/assets/tech-lead-circles.png) 图上的内容主要分为三部分: - Developer。作为一个开发人员,我们应该掌握好编程相关的技能:**面向对象编程、函数式编程,结对编程技能,熟练使用各式的工具,迭代和增量式设计,设计模式,重构,自动化测试,类设计**。 - Architect。作为项目中的架构师,我们要考虑的因素有:**跨功能需求,演进式架构,买还是做的决策,系统设计,计划评估,技术风险管理,科技愿景和凝聚力,关注全生命周期,广泛的工具集,基础设施,客户引导**。 - Leadership。作为一个技术上的 Lead,我们要提升这些软技能:**反馈、沟通,教练,动机,关系构建,委托,影响,风险管理,冲突管理,团队管理**。 好吧,我承认要学习的东西太多了,尤其是对于一个目标是 Tech Lead 的程序员来说。即要成为一个优秀的开发人员,还要成长为一个架构师,最后还要在领导上有所提升。首先,我们可以成为那个技术最 NB 的人(best technical person),然后我们才能成为 Tech Lead。至少领导力什么的,在技术准备充分之前,适当地花时间注意练习即可。 ### Tech Lead 能力模型 对应于此,我们也就有了自己的 (ThoughtWorks)的 Tead Lead 自测模型。从下图可以看出,它是在上图的基础上整理出来的: ![Tech Lead Assessment](https://phodal.github.io/techlead/assets/tla.png) (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。 ![Tech Lead in Project](https://phodal.github.io/techlead/assets/tech-action-project.png) 需要注意的是:这里仅列出笔者**觉得重要的部分**(PS:由于是第一个版本,所以也可能缺少一些要点)。对于某些并非那么重要的职责,可以在上述的 Tech Lead 模型中查看到。 ### 技术准备期(磨合期) 在 ThoughtWorks 开启一个项目的时候,会有这么两个时期:Inception、迭代 0。它们全程都需要一个资深的程序员、架构师参与。他/她的主要职责是**设计出符合项目需要的架构**。所谓的项目需要,并不一定是最合适于这个项目的技术方案。它可能受到利益相关者、组织架构等各种因素的影响,而导致最适合的方案无法采用。如最大的领导,喜欢的是 A 方案,而不是最佳的 B 方案。 **Inception**,主要用于验证技术、业务、运营、设计、产品的可行性。过程中需要一个 Tech Lead 作为一个架构师,设计出符合项目需要的软件架构。按照我的理解,相关的过程大概如下所示: ![架构设计的流程](https://phodal.github.io/techlead/assets/architecture-process.jpg) 过程中,要与项目相关的利益相关者进行沟通,与开发人员一起探讨……,最后妥协出一个能勉勉强强满足各方需求的架构。我们还会从相关的讨论中,梳理出项目相关的技术风险。 **Interation 0**。迭代 0,便是在正式开始开发人员,我们所要做的技术工作。它包含的内容有: - PoC 架构验证。验证系统的架构是否真正可靠,并做一些细微的调整。 - 搭建 CI/CD - 编写模式示范代码。以符合系统架构风格和模式的方式,结合业务功能编写示例代码,作为其它人的参考。 除此,在技术准备期,我们还需要: - 对项目成员进行技术培训 - 设计、实施测试策略 - 部署设计及实践 这是一个相当漫长的时期。 除此,在这个时间我们还要做的一件非常重要的是:**隔离其他/她技术人员与业务人员的直接需求对话**。 ![限制授权](https://phodal.github.io/techlead/assets/limit-of-authority.png) 对于团队的其他/她成员来说,任何的功能和需求的来源,只应该是来自于业务人员(源自业务需求),又或者是团队中的技术负责人(技术需求)。而不应该由业务人员直接与其他/她开发人员沟通。哪怕是 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,是一个项目的重要因素。 #### 心流:不同时期的不同挑战 在项目的不同时间里,对于不同的人来说,他/她们都有不同的感受。这便是心流: ![心流](https://phodal.github.io/techlead/assets/flow.png) 项目的初期,对于大部分的人来说,属于挑战水平高,技术水平一般(对项目不熟悉)的水平。而在项目的中后期,对于大部分的人来说,则项目处于无聊或者无感的状态。在焦虑期,指导新人;在无聊期,创建一些技术挑战……。 作为 Tech Lead 则需要在不同地时期,帮助其他/她人成长。从 Interests、Skills、Strengths、Goals 等不同的维度考虑,了解每个人的不同阶段,帮助他/她们成长。 ![甜蜜点](https://phodal.github.io/techlead/assets/sweet-spot.png) 从某种意义上来看,我们需要了解每一个团队人员的当前位置,而后帮他/也成长。而在项目启动的时候,也可以一起进行头脑风暴,了解每个人在这个项目上的四种诉求。 #### 确保团队的多样性 不得不提及的一句话: > 群体能力=平均个人能力+多样性 若是团队里没有反对的声音,取而代之的是沉默,那么团队就是有问题的。所以,要允许反对的声音。哪怕是错的,也需要等他/她说完。 #### 打造学习文化 作为一个 Geek,我们总会想着努力不断地提升自己的技术,想和那些优秀的人一起工作。可往往由于多种因素的限制,优秀的人总会到新的项目上。也只能自己成为一个优秀的人,并带领其他/她人成为优秀的人,便可以与优秀的人一起工作。 为此,我们需要引入相关的知识分享文化技术写作、读书分享、结对编程、代码检视、技术回顾会议等。 #### 赢得信任 Tech Lead 保证技术实施的一个关键是,大家都信任你。一旦大家都不信任你的时候,又或者是你不信任自己的时候,那么这个项目就会出现问题。它需要我们一步步地去构建出信任感。 除此,当你空降到一个新的团队时,你作为 Tech Lead,便面临着不少的挑战。陌生的代码库,试探你能力的成员……。 ### Process 不同的项目都有各种的流程,都有自己所处的时期。这里就需要用到 Bruce Tuckman 的团队发展阶段模型(Tuckman Stages of Team Development Model): ![团队发展模型](https://phodal.github.io/techlead/assets/states-of-group.png) 即: - 组建期。(Forming)项目小组启蒙阶段。 - 激荡期。(Storming)形成各种观念,激烈竞争、碰撞的局面。 - 规范期。(Norming)规则,价值,行为,方法,工具均已建立。 - 执行期。(Performing)人际结构成为执行任务活动的工具,团队角色更为灵活和功能化,团队能量积聚于一体。 - 休整期。(Adjourning) 任务完成,团队解散。 它可以帮助我们对团队有清晰的认识,随后采取相应的行动,来帮助团队成员明确目标。 而针对于不同的人来说,我们还需要即**情境领导模式**: ![情境领导模式](https://phodal.github.io/techlead/assets/situational-leadership-model.png) 对应于不同的人,也就需要不同的方式,来带领他/她们完成任务: - 指导式(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):我的位置很好,得到了同事的认可。 每个人按自己的动机进行排序,而后有针对性地帮助他/她们: ![动机](https://phodal.github.io/techlead/assets/motivators.jpg) #### 处理冲突:谈判 在项目中,难免会遇到各式各样的冲突,诸如业务人员之间的冲突。它依赖于我们采用一定的模式来解决这些冲突。 这个时候,我们就需要 **Thomas-Kilmann 冲突理论 (TKI)**: ![TKI](https://phodal.github.io/techlead/assets/tki.jpg) 再采取相应的策略: ![TKI 策略](https://phodal.github.io/techlead/assets/tki-stratery.jpg) 谈判分为**软式谈判、硬式谈判、原则式谈判**。对于**原则式谈判**(Principled Negotiation): 1. 尽量扩大总体利益(追求双⽅背后的共同目标和利益) 2. 善于营造公开、公平、公正的竞争局面(以共赢为⽬标) 3. 明确目标,善于妥协(认识并善⽤⾃己的相对实⼒力) 4. 讲究信用 5. 求同存异(制定让步和选择空间的战略) 6. 使用客观标准(努⼒理解对方,换位思考) 7. 运用事实 8. 人、事有别(对事不对人;沟通得当) 为此在谈判之前,要做好一系列的准备工作。 #### 管理风险 > 不作准备,就是在准备失败。 从初始阶段起,项目便充满着各种的风险,也包含了很多的技术风险。作为一个 Tech Lead,管理这些风险也是我们的职责所在。其中的某些不确定性,会随着项目的进行,不断地减少。即**不确定性之锥**,描述了项目中不确定性量的演变过程,即不确定性不仅随着时间的流逝而减少,而且也随风险管理,特别是决策的确立而减小。如下图所示: ![不确定性之锥](https://phodal.github.io/techlead/assets/cone-of-uncertainty-for-powerpoint.jpg) 随着更多的研究和开发,有关项目的更多信息被学习,然后不确定性趋于减少,当所有剩余风险被终止或转移时达到 0 %。 为此,我们需要评估一下如何去应对这样的风险,对应的有四个维度的展示方式: - 避免:描述不接受时,它会给你带来什么好处 - 牵制:估计可能性 - 缓和:描述你将采取什么步骤 - 规避:描述风险成为问题时的全部成本 对应的以下是各自的影响: | | 成本 | 大体时间 | 预期结果 | |------|-----|------------|---------------| | ︎避免 | 未来受益 | 未来 | ⬇ 可能性 | | 牵制 | 机会成本 | 现在,未来 | ⬇ 影响 | | 缓和 | 时间,精力,资源 | 现在 | ⬇ 可能性 ⬇ 影响 | | 规避 | 0 | - | - | 相关资料,文章《“不确定性之锥” 告诉你项目难度为何有 16 倍的差距》:https://zhuanlan.zhihu.com/p/32033094 #### 干系人分析 > 项目干系人包括项目当事人、其行为能影响项目的计划与实施,以及其利益受该项目影响(受益或受损)的个人和组织;也可以把他们称作项目的利害关系者。 从他/她的支持程度和赞同程度来看,我们可以在坐标轴上,标出他/她的位置: ![Stakeholder Mapping](https://phodal.github.io/techlead/assets/stakeholder-mapping.jpg) 对应的,则需要采取不同的沟通策略。 #### 影响(Influence) 在团队对话的时候,需要注意一些对话相关的风格。如下是四种不同的对话风格: ![影响](https://phodal.github.io/techlead/assets/influencing-approaches.png) 可以尝试用罗伯特·西奥迪尼《影响力》(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](https://phodal.github.io/techlead/assets/path-to-production.png) (PS:相关的可视化工具见:) 在过程中,我们关注于 Process、People、Tooling、Artifacts 四个部分,来了解一个项目需要哪些流程、人、工具和产物。 除了用于展示的目的,发现每个流程的持续时间(Duration),我们还可以找到项目的痛点( Pain)。 **它需要持续不断地更新**。 ### C4 Model:架构可视化 C4 Model 是一个非常不错的架构可视化工具,它从系统 System、容器 Container、组件 Component 和代码 Code 四个层次,由顶至底来介绍系统的架构: ![C4 Model 示例](https://phodal.github.io/techlead/assets/c4-model.jpg) 它们的关系类似于: ![地图层级](https://phodal.github.io/techlead/assets/c4model-layer.png) **它需要持续不断地更新**。 ### ADR:架构决策记录 ADR 架构决策记录,是一个类似于亚历山大模式(即:设计模式)的短文本文件。(虽然决策本身不一定是模式,但它们分享着力量的特征平衡。)每个记录都描述了一组力量和一个响应这些力量的决策。 ![ADR](https://phodal.github.io/techlead/assets/adr.png) (PS:相关的工具有 adr-tools 和适用于中文语言的 [https://github.com/phodal/adr](https://github.com/phodal/adr) ) **它需要持续不断地更新**。 ### 技术债墙:技术债的可视化 技术债,是你欠下的东西,需要去还。如果只记在心里,那么可能早晚会忘记,所以要可视化出来: ![ 技术债墙](https://phodal.github.io/techlead/assets/tech-debt-wall.png) 而如图所示,并不是所有的技术债都值得立马去修。成本高,而收益低的工作,可以以后再做嘛(很久很久以后,直到所有的人都忘记了)。 ### 技术雷达:保持技术的敏锐度 技术雷达是一个非常不错的季度技术总结。我们可以从中获取,技术专家们对于技术趋势的一些判断,一些可能采用的新技术。而不是自己将时间花费在大量地、不同的技术上,转而可以关注自己需要的那一部分: ![Tech Lead](https://phodal.github.io/techlead/assets/tw-radar-platforms.png) 当然了,也可以建立自己内部的技术雷达。如我在很久以前的项目里,就尝试过: ![TechStack](https://phodal.github.io/techlead/assets/techstack.jpg) 时间太久了,这个审美和今天的差别有点大。 ### 其它 你呢,还有什么工具推荐? - 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

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Engineer, Consultant, Writer, Designer

ThoughtWorks 技术专家

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

开源深度爱好者

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

联系我: h@phodal.com

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

存档

分类

标签

作者