阿里工程师的自我修养 <119总结大家不知道有没有类似的经历，某个时间段突然一些线上故障频发，各种技术债、业务债被业务方穷追猛打要求还债，如果出现这种现象很大程度这个 TL 已经失位了，这个团队失控了。也曾经有人跟我吐槽他的 TL 把活都分给他们，而 TL 自己什么都不干！这个技术 TL 真的什么都不干？曾经有一段时间我也在思考技术 TL 的核心职责到底是什么？技术 TL 应该具备哪些素质？首先技术说到底是为业务服务的，除非技术就是业务本身，必须体现它的商业价值。在很多公司里技术研发真的就成了实现其他部门需求的工具，我觉得这样的技术TL 肯定是不合格的。首先它不能影响业务发展，需求提出方会经过很多转化，如果不是不假思索传递需求，整个过程会失真。第二个，我认为最最重要的是架构设计的能力，可能管理能力还次之。对于管理能力我认为最重要的是对团队的感知能力，因为一旦到了技术 TL 这个级别，不能脱离一线太远，业务细节可以不清楚，大的方向必须要明确。如果没有很细腻的感知能力，很多的决策会有偏差。如果他不是一个业务架构师，不是一个能给团队指明更好方向的人，他最终会沦为一个需求翻译器，产品经理说怎么做就怎么做。他更多的只是负责保证产品的质量、开发的速度，最终被肢解成一个很琐碎的人。一旦团队上了一定的规模，团队就会从单纯的需求实现走向团队运营，而运营是需要方向的，业务架构就是一个基于运营和数据的一种综合的能力。关于技术层面，技术 TL 需要具备如下素养：●技术视野良好，解决问题能力与架构设计能力出色。技术 TL 要有良好的技术视野，不需要各种技术都样样精通，但是必须要所有涉猎，有所了解，对各种技术领域的发展趋势，主流非主流技术的应用场景要非常了解。知道在什么场景应用什么技术，业务发展到什么规模应该预先做哪些技术储备。产品架构的设计要有足够的弹性，既能够保证当前开发的高效率，又能够对未来产品架构的演进留出扩展的余地。
120> 阿里工程师的自我修养●动手能力要强，学习能力出色。技术 TL 并不需要自己亲自动手写代码，但是如有必要，自己可以随时动手参与第一线的编码工作，技术 TL 不能长期远离一线工作，自废武功，纸上谈兵。否则长此以往，会对技术的判断产生严重的失误。另外，技术 TL 也应该是一个学习能力非常出色的人，毕竟 IT 行业的技术更新换代速度非常快，如果没有快速学习能力，是没有资格做好技术 TL 的。技术 TL 除了管人和管事之外，其他还有很多事情要做包括建立团队研发文化、团队人才培养与建设、跨部门协调与沟通等，这样以要求技术 TL 也同时也需要具备良好的沟通和管理能力，以上观点仅是个人的一些思考和观点，仅供参考。
阿里工程师的自我修养 <121在阿里做了五年技术主管，我有话想说作者：云狄 高级技术专家阿里妹导读：《如何成为优秀的技术主管？》中，阿里巴巴高级技术专家云狄从开发规范、开发流程、技术规划与管理三个角度，分享对技术 TL 的理解与思考。接下来，他将继续深入探讨这一话题，从管理的角度分享技术 TL 的核心职责，主要包括团队建设、团队管理、团队文化、沟通与辅导、招聘与解雇等。背景互联网公司的技术团队管理通常分为 2 个方向：技术管理和团队管理，互联网公司的技术 TL 与传统软件公司的 PM 还是有很大的区别，传统软件公司的 PM 更多注重于对项目的管理包括项目任务拆解、项目进度以及风险等。对于多数互联网公司而言，技术 TL 更多的职责不再局限于项目角度，而是对业务与技术都要有深入的了解，就像黑夜里的灯塔，能够引导和修正团队成员前进的航向。综合技术和业务角度去深
122> 阿里工程师的自我修养度思考问题，具备一定的前瞻性，并在技术领域投入持续的学习热情，向团队成员传道，补齐短板，提高整个团队的战斗力。技术 TL 职责不仅需要制定日常规范，包括开发规范、流程规范等，推动规范的落地，以公有的强制约定来避免不必要的内耗，另外一多半的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上，剩余的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。管理大师彼得·德鲁克说：“组织的目的，就是让平凡的人做出不平凡的事。”然而，不是任何一群平凡的人聚集到一起，都能做出不平凡的事。甚至一群优秀的人聚集到一起，也可能只是一个平庸的组织。大到一个国家，小到一个团队，任何一个卓越的组织，都必须有一个卓越的领导者。领导者是一个组织的灵魂，领导者在很大程度上决定了组织所能达到的高度。阿里有句土话“平凡人、非凡事”，技术团队同样如此，管理者的战略眼光、管理方法、人格魅力等，都会给团队的工作结果带来决定性的影响。其实每个公司、每个团队的背景不太一样，从管理学的角度探讨一些问题，没有统一标准的答案，本文中一些观点仅是个人观点，更多从我个人成长为技术 TL 一些观点理念，同时我也是吸取了前辈们一些优秀的管理理念，包括我最为尊敬的通用电气 CEO 杰克·韦尔奇、苹果 CEO 乔布斯、Intel CEO 格鲁夫，国内我最推崇的技术管理者 robbin（丁香园的技术副总裁）。
阿里工程师的自我修养 <123团队建设从 2014 年开始带这块业务技术团队，至今有 5 个年头。回想起来，团队管理中所有能遇上的问题都遇到过了，其中的磕磕绊绊数不胜数，完全是在实践当中吸取教训，团队建设这块在这里和大家简单分享一下，当然这里面也有做得不够好的地方。在阿里每个人都能感受到拥抱变化，基本上每年组织架构都会调整，甚至有些团队每半年都会调整一次。14 年我也算是被分配到这个团队负责这块业务，这块业务是集团收购一家子公司的业务，整个团队文化和技术体系与阿里有很大的差异化。一般来说新官上任三把火，新的技术 TL 空降之后往往会大肆招人，快速推进改革 , 而且有些技术 TL 喜欢把原来的一些旧将搬进来。当时我没有急于这么去做，没有招过一个新员工，而是立足于稳定现有的团队，主要基于以下原因：●团队和业务了解不够深：对于目前的团队的人员以及业务，我不够了解，不清楚这里面有哪些坑和陷阱，一旦初战不利，领导的信任度被透支，在公司恐怕
124> 阿里工程师的自我修养难有立足之地，更不用谈论改造团队，发挥自己的才能了。●流程与制度：针对团队现状存在的一些问题，我初步判断并不是人的问题，很多问题是一些组织、流程、制度上的问题。我认为只有好的制度才能造就好的团队，在没有解决现有团队的痼疾之前招聘新人，不但不会带来新的生产力，反而会造成团队的混乱，应该先打下一个好的根基，再招人，才能事半功倍。●团队安全感：不想让团队现有的成员感觉一朝天子一朝臣，担心自己在团队中会被边缘化，成为弃儿。另外一方面能够让现有团队心理比较安全，可以安心地好好工作，不至于发生更多的动荡。经过了几个月的摸底了解，大概清楚当时团队存在的一些问题和原因：●业务配合不规范：产品、运营、研发部门之间配合没有建立合理的工作流程，比如对于产品需求的 PRD 评审没有标准，对于运营需求没有量化指标，大家都是疲于奔命做需求，导致大家的积极性不够高。●跨团队协作混乱：跨部门之间的工作配合毫无规范可言，部门之间相互推诿，随便什么业务人员都会随时给研发人员下命令，长此以往，伤害了研发团队的积极性。针对以上问题，我主要把协作流程规范梳理了一番，制定了相对合理、规范的产品合作流程，同产品同学约法三章，明确了 PRD 输出的标准和规范，运营的业务需求也统一由产品输出，杜绝一句话需求。同产品、前端、UED、QA 团队的协作统一标准流程，下游对上游依赖方输出的工作必须有明确的标准规范，口头说的统统无效，拒绝合作。针对跨团队协作乱的情况，我特别想说明一下，由于研发部门不是直接创造收入的业务部门，而是承担业务部门的服务者角色。作为一个服务者，往往站在一个被动和弱势的位置上，很容易被业务人员举着收入的大棒指挥你无条件的服从。业务部门人员随便指派任务，随意变更需求，团队同学无所适从。这样一来，部门内部无论怎样合理的计划都会被外部的力量轻易打破，让团队同学无所适从，导致大家的工作积
阿里工程师的自我修养 <125极性不高，喜欢互相推卸责任。久而久之，员工就产生了自我保护意识，凡工作尽量往后退，凡责任尽量往别处推，不求有功但求无过。为打破员工养成的这种自我封闭的保护意识，鼓励员工更加积极主动做事情，我能够做的就是把这些责任都扛在自己身上，亲自去协调每项工作，让团队成员没有后顾之忧，让团队同学相信我可以搞定他们担心的事情，出了任何问题我可以来背锅，给自己的团队创造一个相对宽松和自由的工作空间，保护团队不被外部的各种杂事伤害到。团队管理人往往会高估自己而低估别人，很多管理者都会觉得手下交上来的工作做得不够完美，这里考虑不周那里做的啰嗦，但很多时候你只是看到了他人不擅长的地方，或者只是对方和你的出发点不同给出了不同的解决方案而已。很多时候，我们并不如自己想象的那么强。管理者在充分理解一些管理的理念之后，不断地在实际的管理工作中去实践并收集反馈和迭代，这样才能够形成自己的管理风格，并找到最适合当前团队的管理方法。
126> 阿里工程师的自我修养作为一个团队的管理者，通常会有两种风格管理策略，简要概括为集权式的管理风格、放权式的管理风格。集权式管理：管理者的风格是偏细节的，定义清晰的工作目标，并且把工作目标分解得非常细致，让手下的团队能按照整个计划步步为营往前推进，这是一种风格，相对来讲比较集权。可以说我带这个团队的第一年是这种风格，我甚至会参加每一次需求评审，无论需求大小，会和研发同学一起去写代码，对研发团队我会做详细的 code review，亲自带领研发团队做技术交流和分享，参与技术讨论确认架构方案，这样以来和大家建立起了充分的信任。放权式管理：定义大的目标，把握大的方向，做关键性的决策。但是并不深入每个细节去管控手下团队的执行细节，以结果为导向。我到这个团队一年后，业务流程已经清晰的建立起来了，骨干员工在业务上能够完全领会并且达到我的要求，这个时候放权可以充分调动团队的自主性和创造性，多数技术人员他们喜欢被领导，不喜欢被管理。以上这两类管理风格没有对错之分，究竟哪种方式更适合完全取决于团队的状况。其实这里我更想说一下关于放权式的管理风格，对于一个制度刚刚建立，流程还没有跑顺畅，团队残缺，骨干员工业务能力不及格的团队，采用放权式管理是错误的。你必须事无巨细，从第一线的业务细节抓起，手把手的带员工，教会他们怎么正确的做事情，怎样达到你的要求，手把手的培养业务骨干，搭建团队核心架构。这些年我看到过太多的案例，管理层自己从不真正深入业务，也缺乏对业务的深刻理解，没有找到问题的本质原因。总是寄希望于招人来解决问题，结果换了一茬又一茬人，问题永远解决不了，而且从来不深刻反思自己是否亲自尝试解决业务问题。很多时候架构反应出来的问题，其实是组织、流程的问题。总之，作为管理层，如果自己没有深入一线去发现问题，自己动手去解决问题的决心和勇气的话，那这个团队很难有新的突破和成功。
阿里工程师的自我修养 <127团队文化在我刚参加工作的前几年，就听过一些关于团队文化和企业文化的一些概念，并没有特别深刻的印象。尤其我读了《基业长青》这本书后，让我感受到对于一个企业而言，决定短期的是技巧，决定中期的是战略，决定长期的是文化。企业文化对一家公司来说真的很重要，同样团队文化对于一个团队来说也很重要，我在带团队之初也曾经忽视了团队文化的冲击。在带领这个团队之初，我私下找一些团队同学做 1on1 沟通，我发现这里面的问题还是比较严重的，很多人为了避免故障遭受惩罚，不敢去重构优化代码，把自己封闭到一个很小的圈子，也没有过多的追求和理想，以前也没有末位淘汰机制，大家觉得可以继续吃大锅饭。当时部门都是工作多年的老人，老的风气和习惯已经形成了很顽固的不良文化，工作情绪受到很大的影响。老的不良的文化包括：●做事情没有积极性；
