如何做好技术 Team Leader?

简介: 作为一个技术TL(Team Leader),除了自身技能,还会面临诸多团队管理上的困难和挑战。如何定义和明确团队的目标?怎样建立优秀的工程文化?让团队长期发挥战斗力和创新能力的核心是什么?本文作者基于四年的团队管理经验,分享他在招聘、目标管理、团队沟通和工程文化等方面的思考与总结,介绍相关的经验方法,并推荐几本关于体验、思考的书籍。希望对同学们有所启发。

 

image.png

 

曾子曰:吾日三省吾身,反思是人类进化出来的一项异常宝贵的能力。我在阿里带团队也有四年多的时间,有必要总结一下此间得失;另外,前几天和一个刚开始带团队的同学聊天,他觉得角色转变对于他有不小的挑战,因此我想做一点不算成熟的总结并分享出来。当然,此文第一不代表我必然是一个多么成熟的管理者;第二不代表我的总结放之四海而皆准(事实上很多人的管理方式和我推崇的方法是反的,但是如果从某些角度评价,这些人更成功);第三我并无雄心壮志解答所有问题。总结仅仅是期望通过反思,帮助自己成为更好的管理者,而分享是希望能够多多少少帮助到其他的管理者。

本文会重点讲述我对招聘、目标管理、团队沟通和工程文化的理解。挑选这几个主题讲述,主要是因为在带团队的这一段时间内,我认为这几个要素是团队长期发挥战斗力和创新能力的核心。得到这个认识对我来说并不容易,市面上有纷繁复杂的书籍(机场书店尤其多)尝试告诉你什么叫领导力,公司也有相关的培训介绍,周围也有很多 TL 用每日的言行告诉你他们是怎么做的。但是我认为这些来自周围的知识,很多是无效的,有更多是错误的。例如有 TL 每天在办公室坐到半夜下班,给团队巨大的加班压力,表面看起来是奋斗,实际上会让大家趋向于更多关注工作时长,从而降低对了对工作价值的思考;又有一些例子是,当团队同学犯错后,把故障和绩效强关联,在我看来这不仅无助于大家深入思考系统健壮性,更是鼓励推责,扼杀创新;更常见的例子可能是 TL 积极向上汇报,承诺超出团队负责的交付能力,导致团队完全无视工程师文化,久而久之优秀的人才逐渐流失,团队整体研发能力实则越来越弱。

很多事情是知易行难的,技术 TL 实践更是这样,之后不断学习,执行,反思,才能慢慢做得更好。如果我团队的同学在离开这个团队五年或者十年后,回想起这段时间,会感慨:“我们当时的团队多好啊,大家一起做了很多有意思的事情。” 那我这个技术 TL 的工作,就算做的出色了。

一 招聘

招聘的第一原则是宁缺毋滥。这么说出来大家都会认同,但是实际执行往往会因为短期压力而变形,尤其是招聘越来越难,好不容易面到一个看起来差不多的同学,难免会内心有点小倾斜,算了,先招进来了。这其实是非常危险的,因为一旦招聘了错误的人,对于 TL 需要耗费的管理时间会成倍增加,这些时间本来可以用来做更重要的时间。更危险的是,错误的人可能会对团队整体产生负面的影响,例如需要其他人不断地补位,或者和人不断争吵,消耗大家的精力。

因此招聘一定是要严格要求的,如何面试我就不详细讲了,通常我会关注以下一些方面,基本上是缺一不可:

  1. coding 能力
  2. 对技术的热情
  3. 能简明扼要地沟通
  4. 积极乐观
  5. 对团队目标的认同

招聘是个长期的事情,如果仅仅是在有名额的窗口去找人,通常是非常困难的。遇到合适的人,我会长期和他保持沟通,了解对方工作的状态,这其实也是一个不断建立信任的关系。当机会合适的时候,对方肯定会优先考虑你。

当候选人选择机会的时候,团队的 TL 是个怎样的人肯定是他重点考虑的因素之一。因此 TL 一定要做技术发声,不论是开源项目的参与,撰写技术文章,还是在技术大会做演讲,都是充分体现 TL 个人技术能力,技术思考,以及个人特质的重要机会。

二 目标

团队之所以为团队,是因为这些人有共同的目标,如果没有共同目标,这些人就是散兵游勇,不可能相互协同,无法成就巨大价值。而团队的目标,主要还是由 TL 去负责定义和明确的。

近期比较流行谈 OKR(Objectives and Key Results,目标与关键成果法),我认为这就是一种协同团队聚焦目标的方法。定方向 O(Objective),定数字目标 KR(Key Result),就是期望团队能够凝聚在一起,朝共同的方向努力,相互理解和支持。量化的指标(KR)用来指导方向,暴露问题。我比较反对用 KR 或者其他量化指标来简单粗暴地考核工程师,数字指标如果用来考核,很容易导致大家舍本逐末。例如有人 KR 完成了 200%,却挖了一堆坑;而有人 KR 完成 50%,但的确解决了棘手问题,代码扎扎实实。我必然会把好的绩效给后者,差的绩效给前者。

定义团队目标实际上是个非常困难的事情,因为这个目标的定义要求你回答:

  • 是否和你的用户/客户做了充分沟通,是否理解他们真正需要什么,你能给他们解决什么问题,他们的工作因为有了你团队会发生怎样的改变。
  • 和上下游协作方能够做好协同,要兑现你给客户承诺的价值,你会依赖于谁做什么事情?需要谁和你一起参与?这些依赖和协作方,是否认同你的目标?
  • 你定义的目标和价值,和你自己的的 TL 的目标,或者自己部门的目标,是否是一致的?
  • 在技术团队,你的目标定义中有没有考虑技术竞争力?持续建设技术竞争力不仅能帮助团队长期发展得更好,也能帮助吸引更多优秀的人才。

当然,如果这个目标有那么点理想主义,那就更好了。工程师骨子都有那么点容易被理想主义吸引。有了清晰的团队目标后,就是要和团队不断的沟通了,让每个人都清晰地理解目标,不要怕重复,不要怕啰嗦。

下一步是把团队目标分解为每个人的目标,这件事本质上是产品架构或者技术架构。为什么这么说呢?在做软件设计的时候,我们都会说高内聚,低耦合;会说面向契约设计。人与人协作的时候,我们也希望每个人的目标足够清晰(对比软件交付功能的定义,或者非功能性指标的度量),以及人和人之间的协作边界清晰(对比软件系统之间的契约)。因此我们要不断去思考团队负责产品的架构,和团队同学不断讨论细化,直至架构及目标足够清晰。当然还有一些横向的目标,或者项目管理的工作目标,需要有同学去承担,这没什么问题,但我非常不建议在研发团队中,让一个同学有超过一半的时间在做横向,因为技术没有深度是谈不上广度的。

三 沟通

如果团队同学找你,那就要尽可能立即响应。立即响应的意思是,如果你当下有时间,就立刻和他沟通;如果你白天时间排满了,那就晚上和他沟通;如果你实在晚上的时间也被占了,那就立刻安排明天一个时间,发出会议邀约。同学如果没有他认为重要的事情,一般是不会主动找主管沟通的,立即响应是和同学建立信任的重要方式。如果同学找你一次两次都没得到响应,或者响应比较慢(给人不重视的感觉),那慢慢的很多事情就不会找你了。最差的情况,同学下次找你的时候可能是提转岗了。

要尽量和同学做 1-on-1,国外专职做管理岗位的,把 1-on-1 作为一个非常正经的日常工作在做,频率也很高,例如两周一次。在阿里巴巴,技术 TL 通常没有这么多的时间,因为身上承担的职责除了管理外,还要带技术,带项目等等。但还是应该做好日常的 1-on-1 沟通,而不仅仅是绩效季。比较理想的频率是一个月一次。在 1-on-1 的时候,一方面要给到非常具体的反馈,例如:

  • 你做的 x 方案,在设计上非常好,考虑到了和隔壁团队的协作。
  • 你近期的代码,在 UT 覆盖上做的不够。
  • 我看到你推进的 y 项目,进展不及理想,是遇到了什么问题吗?需要我提供什么帮助?

除了反馈 1-on-1 更重要的是倾听,同学在表述自己工作的时候,状态好不好?在什么地方遇到了问题,作为 TL 能提供什么帮助?_其实很多时候,即使你暂时帮不了什么,但是用认真的态度去听一下同学的心情,无论这个心情是充满热情,还是沮丧,还是迷茫,对于同学来说都是非常重要的。我在做 1-on-1 的时候,都会做个简单的记录,留着下次 1-on-1 的时候 review,做好追踪。

四 工程文化

要建设一支有战斗力的团队,优秀的工程文化是必不可少的。什么是优秀的工程文化?那就是对自己写代码,写的测试,写的设计,做的产品,所有这些工程师的产出物,对其质量和细节有足够的尊重。为什么说,优秀的工程师文化必不可少,我通过以下几点解释下:

  • 从团队产品的长期发展来看,只有保证优秀的质量,才能保证产品可以长期,高效率的,持续的迭代。如果设计凌乱,代码质量差,无测试覆盖,那么渐渐所有人的精力都会被消耗在各种”安全生产“问题上。渐渐的,一个需求的上线实现,从数小时演变成了数天,甚至数周。
  • 只有拥有优秀工程文化的团队,才能吸引优秀的工程师。优秀的工程师,真心把编程当作一门手艺,以自己的手艺为傲。如果团队 TL 不认为这是一门应当引以为傲的手艺,大家渐渐的大家都把事情看成和搬砖无异的性质,区别只是工资高低。这样的氛围下,团队的人才构成必然是二流甚至是三流的。

建设工程文化,就是要鼓励大家做 Code Review,写 UT,做好 CI,做知识分享。这些事情听起来很容易,难的是,如何在项目压力很大的时候,依旧坚持住。另外,就是要承认技术债的存在,产品上线一段时间后,必然会有很多“临时方案”存在,作为 TL 要给团队创造空间,鼓励他们花时间去偿还技术债。

工程文化是技术团队的根基,可以让所有人有一个正确的参照,什么是对的,什么是应该学习的,什么是需要遵守的。我们可以看到很多丢失了工程文化的团队,演变成一个什么样的状态,写看起来都差不多的 PPT,天天拉会推动这个推动那个,遇到问题自己不去查根究底弄清楚原理,而是拉群,组会,沟通…… 渐渐的这样的团队的技术人才会逐渐流失,剩下的人继续用他们擅长的非技术技能生存。

五 TL 对自己说

除了对外,我还经常对自己说:

  • 做真实的自己
  • Don’t Panic!
  • 耐心点

做真实的自己。每个人都有自己的性格特质,虽然因为人生经历,人的个性会发生变化,但在短时间内一个人最本质的东西是不会变化的。或温文儒雅,或狭义豪情,或积极勤奋…… “真实不装”是阿里价值观中我最喜欢的一条。伪装一时是很容易做到了,常年累月把自己伪装成一种人设,一来自己会非常累,二来团队同学也不是傻子,早晚会看出这其中虚伪的一面。而一旦一个 TL 让人感到虚伪,那就无从谈起信任的建立了。当然,对自我分析,认识自己也并不是一件简单的事情,心理学分析的书浩如烟海,我喜欢夜深人静的时候读一些。

Don’t Panic!TL 会面临各种各样的压力,目标变化,目标难以达成,绩效考核,人和人之间的冲突,团队很团队之间的冲突,这个时候大家都在看着你怎么处理。在这么多压力下,人的自然反应就是焦虑,甚至惊慌失措。我们知道,在运动的时候,演讲的时候,过度的焦虑会导致动作变形,乃至连自己的正常水平都无法发挥。而 TL 在这种状态下,更容易做出错误的判断,而且严重焦虑的情绪很容易传导给整个团队。越是这种时刻,越好稳住自己,在有限的条件下,努力做出最合理的判断,我们必须要承认自己再怎么聪明勤奋,也只是普通人而已,并不是漫威中的超级英雄。

耐心点。程序员可能是最没耐心的一批人,代码写下去,首先期望机器必然给反馈,其次期望机器立刻给出反馈,对了,还是出错了,一切都要清清楚楚,明明白白。可当程序员的角色转变成管理者的时候,一切就发生了巨大的变化。你给团队宣导的目标,可能有人记住了,有人没记住;你给同学指出的问题,可能他几个月半年都改不了,或者他根本不想改;你想在团队建立的工程文化,好像进展非常慢,和预期相差太远。其实这一切都很正常,人脑接受和转化信息,除非是性命攸关的信息,否则效率都是很低的,一个人自身积累几十年的行为模式,哪怕做出细微的变化,也需要很长的时间。因此,重要的信息,不要嫌麻烦,可以说三遍甚至更多;而当你好心给同学指出问题,也不要期望对方立刻接受并改变,很多时候他不做任何改变也是很正常的。但这也不是我们不做正确事情的理由,如果十个同学中有一两个因为你的指导,在职业生涯上突破了自己的一些瓶颈,那已经作为 TL 能实现的巨大成就了。

六 延伸阅读

杨绛有一句话我非常喜欢,她在一封回复青年学生的时候,写了这么一句话:

你的问题主要在于读书不多而想得太多。

在我看来今天在工作中看到的很多人的,所谓创新,所谓 idea,都是属于读书不多而想的太多的瞎折腾。做技术领导者也一样,体验、思考是必要的,但是如果仅仅靠自己思考和体验,往往会走很多弯路,甚至南辕北辙。因此我建议大家阅读一些相关的书籍。以下是我读过的一些,推荐给大家:

《赢》

《如何定义公司》

人才至关重要。

《驱动力》

除了使用金钱之外,如何激励人。

《门后的秘密》

为什么 1-on-1 沟通如此重要,以及如何做好 1-on-1。

《非暴力沟通》

说话大家都会,但是好好说话很多人就不会,擅于倾听的人更是少见。

作者:开发者小助手_LS

原文链接

本文为阿里云原创内容,未经允许不得转载

 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/514423.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

android应用控制百度地图,Android中应用百度地图API开发地图APP实例-显示百度地图...

场景效果在使用百度地图API之前需要先在百度地图开放平台中申请API_KEY申请API_KEY登录百度开放平台后找到控制台下的应用管理-创建应用依次输入应用名,应用类型选择Android SDK然后下面需要输入发布版SHA1和包名获取应用SHA1首先来到.Android文件所在的位置&#x…

数禾云上数据湖最佳实践

简介: 数禾科技从成立伊始就组建了大数据团队并搭建了大数据平台。并在ECS上搭建了自己的Cloudera Hadoop集群。但随着公司互联网金融业务的快速扩张发展,大数据团队承担的责任也越来越重,实时数仓需求,日志分析需求,即…

程序员只能吃“青春饭”?IT行业年龄焦虑如何破局?

2019 年搜狐科技《中国互联网简史》报告显示,国内近一半的程序员年龄在 25-29 岁之间,其次为 30-34岁,占比 24.6%,35 岁 -39 岁的程序员占比 6.1%,而 40岁 的程序员仅占 1.2%。由于程序员需要长时间面对电脑工作&#…

对容器镜像的思考和讨论

简介: 常言道,startup 有 startup 的好,大厂有大厂的好,那么大厂究竟好在哪呢?拿硅谷老牌大厂们 FLG 来说,如果要问最令人怀念的是什么?Free food 和基础设施(Infrastructure)一定是会上榜的&am…

android 高度上分权重,Android LinearLayout weight权重使用

在日常的开发过程中,我们通常或多或少会使用到LinearLayout的weight属性来进行权重设置,进而达到按比例显示布局的意图通常我们在使用时,会这样使用android:layout_width"match_parent"android:layout_height"match_parent&qu…

实时计算pv/uv Demo

简介: 本文由阿里巴巴高级技术专家邓小勇(静行)分享,主要用 Demo 演示如何通过实时计算 Flink 实时计算pv/uv的场景。 本文由阿里巴巴高级技术专家邓小勇(静行)分享,主要用 Demo 演示如何通过实…

《天际友盟DRP数字风险防护报告(2021年上半年)》重磅发布

今天,数字化正在发生,整个社会正在步入数字化革新。根据市场研究公司IDC的预测,到2023年超过50%的全球经济将由数字经济所驱动。在中国,2021-2024数字化转型总支出将达到1.5万亿美元,年均增长率超过17%。由此可见&…

Android Native crash 处理案例分享

简介: Android Native crash 处理案例分享 1. 背景 目前 mPaas[1] Android使用Crash SDK对闪退进行的处理,CrashSDK 是 Android 平台上一款功能强大的崩溃日志收集 SDK,有着极高的崩溃收集率和完整、全面的崩溃日志信息,生成的日…

Mendix:低代码与无代码的异同点与用例

投稿 | Mendix 编辑 | 宋 慧 头图 | 付费下载于 IC photo 低代码和无代码应用开发都遵循着代码抽象化原则来实现建模的可视化。但基于这两种方法构建的应用在规模和类型却有着根本性的区别。 低代码与无代码的相同之处 低代码和无代码开发平台都无需编写代码就能构建软件应用…

解读:云原生下的可观察性发展方向

简介: 非常有幸参加了云原生社区Meetup北京站,有机会和众多业内的大牛一起讨论云原生相关的技术和应用,本次Meetup上我和大家分享了关于云原生下的可观察性相关的议题,本篇文章主要是视频的文字性总结,欢迎大家留言讨论…

一文读懂 Serverless,将配置化思想复用到平台系统中

简介: 搭建一个 aPaaS 平台是需要很长时间的,当然也可以基于一些公有云产品的 Serverless 方案实现现有系统的灵活性与扩展性,从而实现针对于不同客户的定制。 写在前面 在 SaaS 领域 Salesforce 是佼佼者,其 CRM 的概念已经扩展…

9.9 元福利价,解锁校园满分计划

移动云开发者社区致力于为广大开发者提供技术交流和能力输出,是移动云开发者交流汇聚地、移动云产品首席体验官工作台、移动云技术能力布道者讲台和移动云能力输出窗口。通过移动云开发者社区,在帮助移动云开发者用好云、好用云的同时,还可以…

亲历者说 | 完整记录一年多考拉海购的云原生之路

简介: 考拉海购的整个云化改造是从 2019 年 10 月份开始的,当时的唯一目标就是短时间内快速完成迁移。在不到 4 个月的时间里,考拉团队唯一考虑的是如何以最快的速度完成使命,云原生是我们选择的最合适的一条路。 前言 考拉海购的…

为了一个HTTPS,浏览器操碎了心···

作者:轩辕之风O来源:编程技术宇宙 浏览器我是一个浏览器,每到夜深人静的时候,主人就打开我开始学习。为了不让别人看到浏览记录,主人选择了“无痕模式”。但网络中总是有很多坏人,他们通过抓包截获我和服务…

深度 | 阿里云蒋江伟:什么是真正的云原生?

简介: 而今,云原生成了耳熟能详的热门词,似乎不提云原生就落伍了,加入 CNCF 也成了云厂商引以为傲的技术优势。 我们也看到各种云原生的定义,有来自 CNCF 的“微服务容器持续交付DevOps”,也有来自不同云厂…

媒体智能-淘宝直播流媒体互动实践 | D2 分享视频+文章

背景:今天给大家带来的分享主题是《媒体智能-淘宝直播流媒体互动实践》,内容分为5个部分,首先看看在淘宝直播的直播间里主播可以怎样给用户拜年;然后具体讲如何制作一个手势拜年的特效;接着介绍我们媒体智能整体的方案…

从云网络时延看应用部署架构

简介: 介绍云网络时延的构成,并对其进行量化的分析,以及从云网络时延看不同应用对应的部署架构。 也简单的分析了5G时代对应用部署架构的影响和度量云网络时延的产品和工具。 在引出云网络时延这看起来比较专业的话题前,先看几个比…

mPaas 研发流程和线上运维介绍

简介: mPaas 研发流程和线上运维介绍 1. 背景 金融级移动开发平台 mPaaS[1](Mobile PaaS)为 App 开发、测试、运营及运维提供云到端的一站式解决方案,能有效降低技术门槛、减少研发成本、提升开发效率,协助企业快速搭…

html翻转切换div效果,图片翻转效果

图片翻转效果* { margin: 0; padding: 0;}ul { list-style-type: none;}body { font: 14px "Microsoft Yahei"; overflow-x: hidden; background-color: #2B2B2B; }h1 { width: 900px; margin: 40px auto 100px; font: 32px "Microsoft Yahei"; text-align…

Apache Flink 在实时金融数据湖的应用

简介: 本文由京东搜索算法架构团队分享,主要介绍 Apache Flink 在京东商品搜索排序在线学习中的应用实践 一、背景 在京东的商品搜索排序中,经常会遇到搜索结果多样性不足导致系统非最优解的问题。为了解决数据马太效应带来的模型商品排序多…