曾子说：吾日三省吾身。反思是人类进化出来的一种极其宝贵的能力。本人在阿里带队四年多，有必要在这里总结一下得失；另外，前几天和一个刚带队的同学聊天。他觉得角色转换对他来说是一个不小的挑战，所以想做一个不太成熟的总结分享一下。当然，本文第一并不意味着我一定是一个成熟的管理者；第二并不代表我的总结是普适的（其实很多人的管理方法和我推荐的方法是相反的，但是如果从某些角度来说，这些人是比较成功的）；第三，我没有回答所有问题的野心。总结只是希望通过反思帮助自己成为更好的管理者，而分享则是在一定程度上帮助其他管理者。本文将重点阐述我对招聘、目标管理、团队沟通和工程文化的理解。选择这些主题的主要原因是在带领团队期间，我认为这些元素是团队长期战斗力和创新能力的核心。得到这样的理解对我来说并不容易。市场上（尤其是机场书店）有很多复杂的书籍试图告诉你什么是领导力。公司也有相关的培训介绍。身边也有很多TL，他们用日常的一言一行告诉你。他们是怎么做到的。但是我觉得身边的很多知识都是无效的，更多的是错误的。比如有个TL，每天在办公室坐到半夜才下班，给团队带来了巨大的加班压力。表面上看是斗争，实际上会让大家更倾向于关注工作的长短，从而减少对工作价值的思考；还有一些例子是，当队友犯错时，失败和表现是强相关的。在我看来，这不仅无助于大家深入思考系统的健壮性，反而助长指责，扼杀创新；一个比较常见的例子可能是TL是positiveReporting，承诺超出了团队的交付能力，导致团队完全忽视了工程师文化。久而久之，优秀的人才逐渐流失，团队的整体研发能力其实越来越弱。很多事情知道起来比做起来容易，尤其是在技术TL实践中。经过不断的学习、执行、反思，才能慢慢的做的更好。如果我团队的同学在五年后、十年后离开团队，回首这段时间，他们会觉得：“当时我们的团队多好，我们一起做了很多有趣的事情。”然后我的技术TLWork，就算做得好。一、招聘招聘的首要原则是宁缺毋滥。这点大家都会认同，但实际执行起来往往会因为短期压力而变形，尤其是招人越来越难。好不容易遇到了一个长得差不多的同学，心里难免有些倾斜。算了，先招进来。向上。这其实是很危险的，因为一旦用错人，TL所需要的管理时间就会成倍增加，而这些时间本可以用在更重要的时间上。更危险的是，选错了人，可能会对团队整体造成负面影响，比如要求别人不断地填补，或者不断地与人争论，耗尽大家的精力。因此，招聘必须严格要求。如何面试我就不多说了。通常，我会重点关注以下几个方面，这几个方面基本缺一不可：编码能力、对技术的热情、能够简明扼要地积极乐观地与团队目标沟通承认招聘是一个长期的事情，通常很难找到人们只能在有配额的窗口中。遇到合适的人，我会和他保持长时间的沟通，了解对方的工作状态。这实际上是一种持续建立信任的关系。机会合适的时候，对方肯定会优先考虑你。候选人在选择机会的时候，团队的TL是一个什么样的人，一定是他重点考虑的因素之一。所以，TL一定要发技术发声。无论是参与开源项目、撰写技术文章，还是在技术会议上发表演讲，都是充分体现TL个人技术能力、技术思维和个人特点的重要机会。2.目标团队是一个团队，因为这些人有共同的目标。如果没有共同的目标，这些人就是散兵游勇，不可能相互合作，也无法实现巨大的价值。团队的目标主要由TL定义和阐明。最近比较流行讲OKR（ObjectivesandKeyResults，目标和关键结果法）。我认为这是一种协调团队专注于目标的方式。设定方向O（Objective），设定数值目标KR（KeyResult），是期望团队凝聚在一起，朝着共同的方向努力，相互理解，相互支持。用量化指标（KR）来指引方向，暴露问题。我比较反对用KR或者其他量化指标来简单粗暴的评价工程师。如果用数字指标来考核，很容易造成大家血本无归。比如有人完成了200%的KR，却挖了很多坑；虽然有人完成了50%的KR，但他们确实解决了难题，而且代码很扎实。我一定会给后者表现好的，给前者表现差的。定义团队目标其实是一件非常困难的事情，因为这个目标的定义需要你回答：你是否和你的用户/客户进行了充分的沟通，你是否明白他们真正需要什么，你能为他们解决什么问题，以及他们工作因为你的团队将如何改变。与上下游合作者良好合作。实现你对客户承诺的价值，你靠谁做事？你需要谁和你一起参加？这些依赖者和合作者是否同意你的目标？你定义什么？目标和价值观是否与自己的TL目标或本部门的目标一致？在技??术团队中，你在目标定义中是否考虑过技术竞争力？不断打造技术竞争力，不仅可以帮助团队从长远来看得到更好的发展，还可以帮助吸引更多的优秀人才。当然，如果这个目标再理想化一点就更好了。工程师自然会被理想主义所吸引。有了明确的团队目标之后，就要不断的和团队沟通，让大家清楚的明白目标，不要怕重复，怕啰嗦。接下来就是把团队的目标分解成大家的目标，本质上就是产品架构或者技术架构。你为什么这么说？做软件设计的时候，我们都说高内聚低耦合；我们说面向契约的设计。人们协作的时候，我们也希望大家的目标足够明确（相对于软件交付功能的定义，或者非功能指标的度量），人与人之间协作的边界清晰（相对于契约）。所以，我们要不断思考负责产品的团队架构，不断和团队成员一起讨论、细化，直到架构和目标足够清晰。当然，还有一些横向的目标，或者说项目管理的工作目标，需要学生去承担。深度不是广度。3.沟通如果团队成员找到你，你应该尽快回复。即时响应，就是如果你现在有时间，马上和他沟通；如果你白天吃饱了，那就晚上和他交流；如果你晚上真的很忙，那就马上安排一个明天的时间，发出会议邀请。如果一个同学没有他认为重要的事情，他一般不会主动和导师交流。即时回应是与同学建立信任的重要途径。如果一个同学问你一两次没有得到回应，或者回应很慢（感觉好像没注意），那么慢慢很多东西就不会来找你了。最坏的情况下，下次有同学找你的时候，说不定就是提出了调动工作。尝试与同学进行一对一的交流。国外全职管理岗位把1-on-1作为一项很认真的日常工作，频率也很高，比如两周一次。在阿里巴巴，技术型的TL通常没有那么多时间，因为除了管理之外，他们的职责还包括技术、项目等等。但还是做好日常的1对1沟通，不仅仅是表演季。理想的频率是每月一次。1-on-1的时候，一方面，你需要给出非常具体的反馈，比如：你做的x方案设计的很好，考虑到和隔壁团队的协作。您最近的代码没有做足够的UT覆盖。我看到您正在推广的y项目没有按预期进行。你遇到什么问题了吗？你需要什么样的帮助？除了1对1的反馈，更重要的是倾听。学生发表作品时，状态好吗？?你在哪里遇到问题，作为一个TL，你会如何帮助？_其实很多时候，即使暂时帮不上忙，也应该以认真的态度去倾听同学的感受，无论是否情绪是否充满热情、压抑或迷茫对学生来说很重要。我在做1对1的时候，总是做一个简单的记录，留着下次1对1的时候复习，以备不时之需。4、工程文化要打造一支具有战斗力的团队，优秀的工程文化必不可少。什么是优秀的工程文化？那就是对所有这些写代码、写测试、写设计、做产品的工程师输出的质量和细节有足够的尊重。为什么优秀的工程师文化必不可少？我通过以下几点来说明：从团队产品的长远发展来看，只有保证优秀的品质，才能保证产品的长期、高效、持续迭代。如果设计凌乱，代码质量差，没有测试覆盖率，那么慢慢地大家的精力就会消耗在各种“安全生产”问题上。渐渐地，一个需求的在线实现已经从几小时发展到几天甚至几周。只有具有优秀工程文化的团队才能吸引优秀的工程师。优秀的工程师真诚地将编程视为一门手艺，并以自己的手艺为荣。如果团队TL不认为这是一项值得骄傲的手艺，大家就会逐渐将其视为搬砖一样，区别只是薪水。在这样的氛围下，球队的人才构成肯定是二流甚至三流的。建设工程文化就是鼓励大家做CodeReview，写UT，做好CI，做知识共享。这些事情听上去很简单，但难的是在项目压力很大的时候如何坚持。此外，还要承认技术债的存在。产品推出一段时间后，难免会出现很多“临时方案”。作为TL，有必要为团队创造空间，鼓励他们花时间偿还技术债务。工程文化是技术团队的根基，让大家有一个正确的参照，什么是对的，什么应该学，什么需要遵循。我们可以看到有多少失去了工程文化的团队已经演变成现在这样的状态。写类似的PPT的时候，天天推这个推那个。就是拉群、组织会议、交流……渐渐地，这样一个团队的技术人才会逐渐流失，剩下的人会继续用自己的非技术技能来生存。5.TL对自己说，除了外面的世界，我经常对自己说：BetruetoyourselfDon'tPanic！要有耐心，忠于自己。每个人都有自己的性格特征。虽然一个人的性格会因为生活经历而改变，但是一个人最本质的东西是不会在短时间内改变的。或温文尔雅，或狭隘傲慢，或积极勤奋……“真而不假”是我最喜欢的阿里价值观之一。伪装一时容易，伪装多年会很累，其次，队员们也不是傻子，迟早会识破虚伪。而一旦一个TL让人觉得虚伪，就谈不上信任的建立。当然，对于自我分析来说，认识自己并不是一件简单的事情。心理分析的书太多了，我喜欢在夜深人静的时候看一些。不要恐慌！TL会面临各种压力，目标变更，目标难以达成，绩效考核，人与人之间的矛盾，团队与团队之间的矛盾，此时大家都在看着你处理。在如此大的压力下，焦虑甚至恐慌是人类的自然反应。我们知道，在锻炼或演讲时，过度的焦虑会导致动作变形，甚至无法发挥正常水平。这种状态下，TL更容易做出错误的判断，严重的焦虑也很容易传染给整个团队。越是这种时刻，越能让我们稳定自己，尽量在有限的条件下做出最合理的判断。我们必须承认，无论我们多么聪明和努力，我们也只是普通人，而不是漫威的超级英雄。要有耐心。程序员可能是最没有耐心的一群人。写完代码，一是期待机器反馈，二是期待机器立即反馈。是的，如果出了问题，一切都必须清楚明了。但当程序员的角色转变为管理者时，一切都发生了翻天覆地的变化。有些人可能记得你向团队宣扬的目标，有些人可能不记得；你给同学指出的问题，可能几个月半年都改不了，也可能根本不想改；你想在团队中建立的工程文化，似乎进展很缓慢，与预期相差太远。其实这一切都是正常的。人脑接受和转化信息，除非是危及生命的信息，否则效率很低。一个人几十年的行为模式积累起来，哪怕是一点点的改变，也需要很长的时间。所以，重要的信息不要太麻烦，可以说三遍以上；而当你好心向同学指出问题时，也不要指望对方马上接受并改变。很多时候，他不做任何改变也是很正常的。但这不是我们不做正确事情的理由。如果十个同学中有一两个因为你的指导而突破了事业上的一些瓶颈，那已经是TL能够取得的巨大成就了。
