简介：作为一个技术 TL（Team Leader），除了本身技能，还会面临诸多团队治理上的艰难和挑战。如何定义和明确团队的指标？怎么建设优良的工程文化？让团队长期施展战斗力和创新能力的外围是什么？本文作者基于四年的团队治理教训，分享他在招聘、指标治理、团队沟通和工程文化等方面的思考与总结，介绍相干的教训办法，并举荐几本对于体验、思考的书籍。心愿对同学们有所启发。

曾子曰：吾日三省吾身，反思是人类进化进去的一项异样贵重的能力。我在阿里带团队也有四年多的工夫，有必要总结一下此间得失；另外，前几天和一个刚开始带团队的同学聊天，他感觉角色转变对于他有不小的挑战，因而我想做一点不算成熟的总结并分享进去。当然，此文第一不代表我必然是一个如许成熟的管理者；第二不代表我的总结放之四海而皆准（事实上很多人的治理形式和我推崇的办法是反的，然而如果从某些角度评估，这些人更胜利）；第三我并无雄心壮志解答所有问题。总结仅仅是冀望通过反思，帮忙本人成为更好的管理者，而分享是心愿可能多多少少帮忙到其余的管理者。

本文会重点讲述我对招聘、指标治理、团队沟通和工程文化的了解。筛选这几个主题讲述，次要是因为在带团队的这一段时间内，我认为这几个因素是团队长期施展战斗力和创新能力的外围。失去这个意识对我来说并不容易，市面上有纷繁复杂的书籍（机场书店尤其多）尝试通知你什么叫领导力，公司也有相干的培训介绍，四周也有很多 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
原文链接
本文为阿里云原创内容，未经容许不得转载