除了淘宝还有哪些购物网站,网站设计一般要求,网站建设的客户需求调查与分析,企业注册登记流程简介#xff1a; 作为一个技术TL#xff08;Team Leader#xff09;#xff0c;除了自身技能#xff0c;还会面临诸多团队管理上的困难和挑战。如何定义和明确团队的目标#xff1f;怎样建立优秀的工程文化#xff1f;让团队长期发挥战斗力和创新能力的核心是什么#… 简介 作为一个技术TLTeam Leader除了自身技能还会面临诸多团队管理上的困难和挑战。如何定义和明确团队的目标怎样建立优秀的工程文化让团队长期发挥战斗力和创新能力的核心是什么本文作者基于四年的团队管理经验分享他在招聘、目标管理、团队沟通和工程文化等方面的思考与总结介绍相关的经验方法并推荐几本关于体验、思考的书籍。希望对同学们有所启发。 曾子曰吾日三省吾身反思是人类进化出来的一项异常宝贵的能力。我在阿里带团队也有四年多的时间有必要总结一下此间得失另外前几天和一个刚开始带团队的同学聊天他觉得角色转变对于他有不小的挑战因此我想做一点不算成熟的总结并分享出来。当然此文第一不代表我必然是一个多么成熟的管理者第二不代表我的总结放之四海而皆准事实上很多人的管理方式和我推崇的方法是反的但是如果从某些角度评价这些人更成功第三我并无雄心壮志解答所有问题。总结仅仅是期望通过反思帮助自己成为更好的管理者而分享是希望能够多多少少帮助到其他的管理者。
本文会重点讲述我对招聘、目标管理、团队沟通和工程文化的理解。挑选这几个主题讲述主要是因为在带团队的这一段时间内我认为这几个要素是团队长期发挥战斗力和创新能力的核心。得到这个认识对我来说并不容易市面上有纷繁复杂的书籍机场书店尤其多尝试告诉你什么叫领导力公司也有相关的培训介绍周围也有很多 TL 用每日的言行告诉你他们是怎么做的。但是我认为这些来自周围的知识很多是无效的有更多是错误的。例如有 TL 每天在办公室坐到半夜下班给团队巨大的加班压力表面看起来是奋斗实际上会让大家趋向于更多关注工作时长从而降低对了对工作价值的思考又有一些例子是当团队同学犯错后把故障和绩效强关联在我看来这不仅无助于大家深入思考系统健壮性更是鼓励推责扼杀创新更常见的例子可能是 TL 积极向上汇报承诺超出团队负责的交付能力导致团队完全无视工程师文化久而久之优秀的人才逐渐流失团队整体研发能力实则越来越弱。
很多事情是知易行难的技术 TL 实践更是这样之后不断学习执行反思才能慢慢做得更好。如果我团队的同学在离开这个团队五年或者十年后回想起这段时间会感慨“我们当时的团队多好啊大家一起做了很多有意思的事情。” 那我这个技术 TL 的工作就算做的出色了。
一 招聘
招聘的第一原则是宁缺毋滥。这么说出来大家都会认同但是实际执行往往会因为短期压力而变形尤其是招聘越来越难好不容易面到一个看起来差不多的同学难免会内心有点小倾斜算了先招进来了。这其实是非常危险的因为一旦招聘了错误的人对于 TL 需要耗费的管理时间会成倍增加这些时间本来可以用来做更重要的时间。更危险的是错误的人可能会对团队整体产生负面的影响例如需要其他人不断地补位或者和人不断争吵消耗大家的精力。
因此招聘一定是要严格要求的如何面试我就不详细讲了通常我会关注以下一些方面基本上是缺一不可
coding 能力对技术的热情能简明扼要地沟通积极乐观对团队目标的认同
招聘是个长期的事情如果仅仅是在有名额的窗口去找人通常是非常困难的。遇到合适的人我会长期和他保持沟通了解对方工作的状态这其实也是一个不断建立信任的关系。当机会合适的时候对方肯定会优先考虑你。
当候选人选择机会的时候团队的 TL 是个怎样的人肯定是他重点考虑的因素之一。因此 TL 一定要做技术发声不论是开源项目的参与撰写技术文章还是在技术大会做演讲都是充分体现 TL 个人技术能力技术思考以及个人特质的重要机会。
二 目标
团队之所以为团队是因为这些人有共同的目标如果没有共同目标这些人就是散兵游勇不可能相互协同无法成就巨大价值。而团队的目标主要还是由 TL 去负责定义和明确的。
近期比较流行谈 OKRObjectives and Key Results目标与关键成果法我认为这就是一种协同团队聚焦目标的方法。定方向 OObjective定数字目标 KRKey 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 PanicTL 会面临各种各样的压力目标变化目标难以达成绩效考核人和人之间的冲突团队很团队之间的冲突这个时候大家都在看着你怎么处理。在这么多压力下人的自然反应就是焦虑甚至惊慌失措。我们知道在运动的时候演讲的时候过度的焦虑会导致动作变形乃至连自己的正常水平都无法发挥。而 TL 在这种状态下更容易做出错误的判断而且严重焦虑的情绪很容易传导给整个团队。越是这种时刻越好稳住自己在有限的条件下努力做出最合理的判断我们必须要承认自己再怎么聪明勤奋也只是普通人而已并不是漫威中的超级英雄。
耐心点。程序员可能是最没耐心的一批人代码写下去首先期望机器必然给反馈其次期望机器立刻给出反馈对了还是出错了一切都要清清楚楚明明白白。可当程序员的角色转变成管理者的时候一切就发生了巨大的变化。你给团队宣导的目标可能有人记住了有人没记住你给同学指出的问题可能他几个月半年都改不了或者他根本不想改你想在团队建立的工程文化好像进展非常慢和预期相差太远。其实这一切都很正常人脑接受和转化信息除非是性命攸关的信息否则效率都是很低的一个人自身积累几十年的行为模式哪怕做出细微的变化也需要很长的时间。因此重要的信息不要嫌麻烦可以说三遍甚至更多而当你好心给同学指出问题也不要期望对方立刻接受并改变很多时候他不做任何改变也是很正常的。但这也不是我们不做正确事情的理由如果十个同学中有一两个因为你的指导在职业生涯上突破了自己的一些瓶颈那已经作为 TL 能实现的巨大成就了。
六 延伸阅读
杨绛有一句话我非常喜欢她在一封回复青年学生的时候写了这么一句话 你的问题主要在于读书不多而想得太多。 在我看来今天在工作中看到的很多人的所谓创新所谓 idea都是属于读书不多而想的太多的瞎折腾。做技术领导者也一样体验、思考是必要的但是如果仅仅靠自己思考和体验往往会走很多弯路甚至南辕北辙。因此我建议大家阅读一些相关的书籍。以下是我读过的一些推荐给大家
《赢》
《如何定义公司》 人才至关重要。 《驱动力》 除了使用金钱之外如何激励人。 《门后的秘密》 为什么 1-on-1 沟通如此重要以及如何做好 1-on-1。 《非暴力沟通》 说话大家都会但是好好说话很多人就不会擅于倾听的人更是少见。 作者开发者小助手_LS
原文链接
本文为阿里云原创内容未经允许不得转载
