Tech Lead（技术经理） 带人之道
博主：爱码叔
个人博客站点： icodebook
公众号：漫话软件设计
专注于软件设计与架构、技术管理。擅长用通俗易懂的语言讲解技术。对技术管理工作有自己的一定见解。文章会第一时间首发在个站上，欢迎大家关注访问！
本文个站链接
当你成为Tech Lead 后，将面临各种各样带人的问题。比如不好意思给团队成员安排工作；团队成员工作漏洞百出；团队成员能力停滞不前；团队成员缺乏主动性；团队成员个性强，很难带。如何带团队、如何带人，对于技术出身的Tech Lead是一个全新的领域，面对问题很容易陷入一筹莫展的境地。本文聊一聊 Tech Lead 如何带人。
带人的心理关
昨天还是在一起 pair 写代码、一起吐槽前 TL 和 PM 的好兄弟，今天你却要开始给他分配任务还要教他做事情。这是不是有点尴尬？
太熟了，有点下不去手？大多数新任 TL 可能都有这个问题。心里会觉得曾经一起干活的兄弟，现在却要给他安排工作、追问进度，不好意思开口。
其实大可不必。这是你作为TL的工作职责，没有什么不好意思的。大家各司其职而已。
你表现得更为优秀、经验更加丰富，时机也已成熟。你光明正大地晋升为TL，行使自己的职责，有什么可担心的？
你要能够把控自己的团队，那么必须迈过心里这道坎。碍于以往的关系会导致工作无法正常推进。
其实你在意的这些，对方可能并不在意。也有可能对方不适应你身份的转变，甚至对你的工作安排有所抵触和抗拒。但记住，这不是你的问题。作为团队的 Tech Lead，不可能由你去适应他。而是他需要融入到你负责的团队之中。否则只能是他走人。
自信点，你现在是团队的 Tech Lead，做你应该做的事情，不要有私人关系和感情上的顾虑。
构建自己的影响力
作为新组建团队的 Tech Lead，你跑到某位团队成员身边说：你好，我经验很丰富，技术也不错，我来教你做事情？
对方肯定一脸懵逼：你想干嘛？
上面的例子有些夸张，但作为团队的新 Tech Lead，你还未在团队中建立起足够影响力，很多事情不能操之过急。
利用好团队组建期和风暴期
我在《Tech Lead 如何应对团队发展不同阶段》一文中介绍过团队在组建期以及风暴期的状态，以及TL应该关注的事项。对于团队而言，此时是磨合阶段，各成员间逐步建立起信任。对于 Tech Lead 而言，这也是构建自己影响力的最佳时期。
风暴期会有很多激烈的讨论。身为Tech Lead，需要在讨论时能够输出有价值并且令人信服的观点。这也是 Tech Lead 快速赢得团队信任的方法之一。对于含糊不清的技术问题，Tech Lead 需要立刻付之行动。在快速学习、实践后，给团队讲解清楚。这会让团队成员对你心生敬佩。
在此阶段，展现出你对技术卓越的追求非常重要，并且一定要有理有据坚持自己的观点，而不是左右摇摆。如果只是坚持自己的观点，那么很容易做到。但是做到有理有据让人信服，则非常不容易。首先需要你对问题有充分的调研，另外也需要一定的口才。如果不做足准备，只是以TL的身份强推自己的观点，只会适得其反。
亮出你的代码
大家都是开发，亮出你的代码比夸夸其谈一个小时让人信服得多。
可以通过如下亮代码的方式提升你的影响力。
1、完成一个功能，给团队打样。展现出你优秀的编程思想和代码风格
2、遇到技术问题，主动承担调研解决，并给团队分享
3、开发底层代码
4、开发技术难度最大的需求
5、和团队成员 Pair 开发
TL 切忌远离代码。尤其在团队组建期，哪怕加班也要开发代码，否则你建立起的“影响力” 如同在沙滩上盖楼。
TL 的工作繁杂，写代码的时间非常有限，需要有选择性地写代码。关于TL应该写哪些代码，在另一篇文章《Tech Lead 如何应对编码时间下降》中有更为详细的分析，这里就不再赘述。
分析团队
如果是你亲手组建的队伍，你对团队的情况当然是了如指掌。但也有可能是你接手一支队伍。那么你首先要了解这支队伍。团队成员的技术栈是什么，代码能力如何，是否有本项目的经验等等。具体要考虑的几个方面和组建团队考虑的一样，可以参考我之前写的《Tech Lead 如何组建你的全明星团队》
当你对团队有了充分了解后，需要结合项目短期和中长期的需要，对每一位团队成员进行分析，找到其擅长的工作和需要提升的地方。分配工作时，需要考虑如何充分发挥每个人的特长以及给予其一定的提升空间。
分析完团队成员后，需要和每位成员对齐期望和他个人的诉求。工作中尽量为其提供机会，帮助其成长。
目标的制定和跟进
如何分配工作
有了目标和计划，最终还是需要在项目中得到锻炼和成长。下面我们看看如何合理地分配工作，帮助团队成员不断成长。
Tech Lead 分配工作时需要平衡两个方面：
-
项目的质量和进度
-
个人成长需求
如果只考虑项目的质量和进度，会导致团队成员一直做自己擅长的工作。但久而久之，团队成员会失去工作的热情。最终结果可能团队变得懈怠，也可能有团队成员觉得无聊离开团队。
但如果只考虑个人成长需求，安排的都是非常有挑战性的工作，那么出问题的概率必然大幅上升。面临的后果可能是项目失败，或者团队成员屡屡受挫，自信心受到沉重打击。
我们以工作挑战性高低以及人员能力高低为横纵坐标，绘制下图。
舒适区是团队成员工作效率最高，心态也最好的区域。团队成员沿着 “flow” 上升，能力和承担工作的难度同步提升。这是我们想要达到的理想状态。
我们假设团队成员目前处于舒适区中。此时给团队成员分配的工作需要略带挑战，使其跨出舒适区，处于轻微焦虑的状态。这可以促使其在可以承受的压力下，努力提升自己的能力，再回到舒适区中。此时他已经沿着flow向上移动，无论是能力还是可以胜任的工作，都上了一个台阶。反复这个过程，他的能力将得到不断提升。
另一种情况是团队成员能力提升后，工作难度却没有变化。团队成员进入无聊区。此时 Tech Lead 需要尽快提升他的工作难度，让其回到舒适区。否则他对工作会产生懈怠，能力也会止步不前。
如果团队成员的工作挑战性太强，则会造成拔苗助长，功未练成，精神、肉体已练废。
给团队成员分配略带挑战性的工作，观察团队成员的状态，根据能力的提升，适时调整工作难度。这些工作需要 Tech Lead长期关注。
何时“教”别人做事
Tech Lead 作为团队中综合能力数一数二的存在，承担着培养团队成员的重任。
培养的方式有很多种。对于初级开发，需要将他要做的事情掰开了揉碎了，告诉他如何一步步去完成。对于有一定经验的开发则会给他更大的自由度。在过程中， Tech Lead 可以给予帮助，发现问题时及时纠正。
大部分 Tech Lead 心中都有因材施教的概念，但是并不很清楚如何去实践。有一个非常好的理论模型能够帮助我们解决这个问题。
情景领导力-Situational Leadership，由Situational Leadership和Ken Blanchard在1969年提出，他们认为应当根据团队成员的成熟度不同，选择正确的领导风格，才能获得领导的成功。
情景领导力模型如下。
根据团队成员的不同发展阶段分为四个象限。分别为热情的初学者、憧憬幻灭的学习者、谨慎能干的初学者、独立自主的完成者。
热情的初学者
回想一下团队中最近刚加入的毕业生。虽然他能力确实有限，但是对技术抱有极高的热情，如饥似渴。他们会为技术问题苦恼，也会因为攻克一个问题而兴奋不已。
**对于热情的初学者，Tech Lead更多采用指定工作的方式。**将团队成员的工作进行分解，并告诉其这么拆解的原因。受限于认知能力，此时他可能并不能完全理解如此拆解的原因，但并不重要。他关注的是拆解后的每个具体任务如何去实现。这就像我们学习羽毛球，都需要从一个个基本动作练起。
完成任务的过程中，初学者的关注点在于如何正确处理DB中的数据、如何写一个API、如何写测试等等。不要觉得这些任务都很基础。将项目中涉及的各种技术正确运用起来，完成一个完整的功能，对于初学者来说并不是一件容易的事情。
Tech Lead 对于热情的初学者，应尽量将任务拆分到可以直接执行的粒度，然后按照时间表去检查初学者的进度。
憧憬幻灭的学习者
可以肯定地说，这是最为痛苦的一个阶段。一腔热血的初学者，很快就开始四处碰壁，最终灰心丧气，情绪低落。
还记得我的孩子第一次去练习跳绳时的情景。下楼前他信心满满，觉得很快就能一展身手。但练了半小时后，还是不能连贯跳过三次，导致情绪崩溃，哇哇大哭。
工作中我们学习一项新技能，往往也是如此。
初学者面对各种各样的技术栈，问题不停冒出。一开始还能勉强招架，但随着学习的深入，慢慢就会感觉到力不从心。在熬了几个通宵，头发也掉了一大把后，面对依旧堆积如山的问题，初学者的憧憬将走向幻灭。
在这个时期，作为 Tech Lead 需要在情绪上疏导团队成员。来自 Tech Lead 的鼓励非常重要。在精神上给予团队成员支撑，让其坚定地走下去。
只有鼓励当然是不够的。Tech Lead 需要帮助其制定合理的学习成长计划，给出学习的指导和建议，帮助他尽快度过此阶段。
如果团队成员认为当前工作难度过大，导致自己过于焦虑，也可以适当降低他的工作难度。
能干谨慎的贡献者
这个阶段的团队成员已经具备独自完成一些工作的能力。但是缺乏一些自信，而且在一些细节上还需要Tech Lead指点和帮助。
此时，Tech Lead 应该鼓励他独自制订方案，然后倾听他的方案。如果觉得方案有可以改进的地方，需要采用引导的方式帮助其完善方案。
在方案的执行阶段，Tech Lead需要向其提供所需的资源，给予必要的支持。持续跟踪方案的执行，确保能够成功实施。
按上述方式，团队成员成功实施几次方案后，无论能力还是自信心都会有较大的提升，从而顺利度过这个阶段。
独立自主的完成者
此阶段的团队成员已经能够独立自主完成任务。Tech Lead 此时应该给予团队成员充分的信任，让其主导方案设计以及时间计划。
Tech Lead 需要和团队成员充分沟通任务的重要性以及他是否有意愿和信心去完成。如果他的能力和信心都没有问题，那么可以放手让其独立完成，Tech Lead 只需要关注最终结果。当然，为了避免执行上的偏差，过程中还是需要按照时间表关注工作进展。在这个阶段，时间表应由团队成员来主导创建。
情景领导力小结
上述四个阶段，并不是每位团队成员都会经历，并且每个阶段的时间长度也会因人而异。同一个人，对于不同的工作，会重新经历这几个阶段。
作为 Tech Lead，需要分析当前工作对于特定的团队成员，处于什么阶段。根据不同阶段的特点，针对性地帮助其完成工作。
正确使用委托
对于独立自主的完成者，Tech Lead 应该多采取委托行为。在这里，我想再多聊两句委托。
委托在《现代汉语词典中》的解释为 “把事情托付给别人或别的机构”。比如当事人委托律师出庭。再比如房屋买卖中委托家人过户。我认为委托有两个特点，一是被委托人有足够的专业技能，二是对被委托人有足够的信任。
项在项目中，我常听到有的 Tech Lead 说：“xxx，我忙不过来了，这个事情委托你做一下吧。”
似乎委托是解放 Tech Lead 带宽的救命稻草。但在 “委托”之后，时常会出现被委托人执行得不尽如人意。甚至最后搞砸了，还得 Tech Lead 来收场。这样不但未能解放 Tech Lead 的带宽，而且被委托人也会信心受挫。
在委托前，需要先问自己一个问题：对于被委托的事情，受托人已经达到 “独立自主的完成者” 阶段了吗？
如果受托人从来没有做过这项工作，你却很信任地 “委托”给他，并且过程中也没有参与，那么往往结果会不尽如人意。这种 “委托”，只能称之为偷懒，并不是真正意义上的委托。
信任的产生，需要一个过程。对于陌生的人、陌生的事都是如此。在信任建立起来之前，要小心行事。切忌盲目信任，滥用委托。
根据被委托人的能力和其对委托工作的熟悉程度，Tech Lead 需要做到事先沟通、事中检查、事后复盘。这是对工作负责、对项目负责、也是对被委托人负责。不要因为工作繁忙而不分场景的使用 “委托”。
总结
Tech Lead 跨过带人的心理关以及构建起自己的影响力都不是太大的问题。带人的难点在于因材施教。这需要Tech Lead 分析每位团队成员的情况，根据情景领导力模型，找到其所处的阶段。根据每个阶段的特点来指导团队成员工作。