TechLead是什么？

是一个称号，是一个角色；是团队交付的力量，也是公司中间的力量；是社区的主力，还是BU的动力。（后文简称TL）

TechOps又是什么？

是支撑公司运营的“神秘”组织，在你的工作中，除了你的客户他们管不了，其它的基本他们都管。

那么在TechOps做TechLead又是一种什么样的体验呢？还是让我抿口水，慢慢说来。

缘起

6月的武汉早早抖起了精神，一大早就迫不及待的告诉你这将是另一个疯狂的夏天。

第一天上班！早早地寻到公司，还以为自己走错了，难道这就是那个传闻前些年世界第一难面的公司在武汉的分公司？一张A4纸做的路径导航，一块小小的大门，一眼能看全的办公区。要不是热情的HR，加上TW发光的logo，我才肯定没有搞错。

还没来得急顺口气，就加入了自己在TW的第一个项目，加上我成员就仨，一个TL，白亮；一个QA，黑旷；一个Dev，我。

白亮举起他圆圆的膀子，边擦汗边告诉我，我们现在首要任务就是将该项目顺利接到武汉来。

从曼彻斯特来的原全功能团队- 1 TL + 1 BA + 1 QA + 2 DEV + 1BA，会向我们持续轰炸一个月。在这之前，就两天的时间熟悉代码，还是自己不了解的技术栈。

现在回想起来，就好像是黑白双煞和我的精神力量组成羸弱三人组，还不忘自己对自己说，先定一个小目标，再干一番大事业。

不过，一下子就接触到了两个TL，真是冥冥中的万幸。

一面是白亮为了确保能完整的接下整个项目，短短一周以内就能自己给我画出完整的项目架构图，不仅包括整体框架，代码层级；还能讲清楚整个项目的部署流程，以及CI/CD的实际工作原理。以确保我不会云里雾里，不知所云。

一面是Paul（全功能团队TL，后简称小P）给我们传授敏捷大法，最佳实践，以确保我尽快融入敏捷工作环境。

我因该感恩，感恩有这么给力的队友给我无死角的帮助；更因该感叹，感叹TL快速的学习能力和敏捷的coach节奏感是多么的重要！

对于TL而言，技术当然是立身之本，需要快速的学习能力，而这个学习速率就是亮刺刀，取决于平常对知识体系的梳理，如对框架抽象总结，才能做到举一反三，面向行业编程；对工具比较加理解，才能做到恰到好处，为我所用； 等等。

眨眼到了月未，我们顺利的接过了项目，有了稳定的持续交付。小P达成所愿，给我们留下坚毅的背影，安心回到了曼城。

蹒跚学步

项目是顺利交接了，能力建设刻不容缓。不过因该补哪些？怎么补？工作时间和业余时间怎么配合？这些通通都是TL需要解答的问题。

白亮大眼珠子一转溜，早已有了答案。

在日常工作中，细致入微。

挑卡后，Kick off前，一起分析业务需求，不明确的地方要明确，不合理的地方，要拒绝。

准备工作也要做足，先做好Tasking，统一思路后，才开始动手TDD。

Desk check前，自己先过一遍所有的Test scenarios。

不仅要让大家坚持这些原则，更重要的是让大家懂得坚持的意义。

业余时间，讲Session，做Workshop，尽快让大家对技术框架统一理解，将关键知识点吃透消化。

代码层面的技术是看得见，摸得着的。补足也直接，差就补，不会就学。需要融会贯通并长期沉淀的是敏捷实践，更准确的说是适合团队的敏捷实践。

TechOps是内部项目，但并不意味着因为是内部项目，所以我们就可以为所欲为了。恰恰相反，还正因为是内部项目，反而对敏捷的纯粹性要求甚高。敏捷的布道者，自身的敏捷都做得不够，就像宋江的军师 – 无用。

一个月的时间，照葫芦画瓢是够了，不过这个时候容易出现的问题是大家对于敏捷的理解不一致，有生搬硬套的，也有积极创新的，还有随便的。

这时候好用的是对内自检和引入培训，让团队找到自己节奏。以团队为单位来自检，通过系统讲解，来帮助自己梳理敏捷体系。从外部引入培训，可以让敏捷做得流畅的团队来一场内部咨询，从不同的角度多看看自身的问题。

Tips:

帮助团队理解需求

让团队对项目架构统一和完整地理解

明确需要坚持的实践和代码标准

帮助PO明确项目风险

初生之犊

就这样，白亮带着做了大半年，在另一个项目殷切期盼下，他翘首离去，留给我们圆圆的背影。

对于团队来说，这很正常，有人上项目就有人下项目。对于咨询公司，健康的成长环境，正常的人员成长速率，也是竞争力的重要组成部分。

做为新的TL接手项目，摆在面前问题很多，首当其冲的就是在不太合理的团队leverage实际情况下，还要保证大家的成长速度，最终能保证团队正常交付。

既然当前团队的leverage是不合理的，首先要做的事情就是找出最薄弱的一环，找到合适的人选，让TA快速的成长。这一步既要做到心中有数，又不能武断专行。因为在全功能团队里，公平公正，信息透明是一条不可逾越的底线。我不会简单的告诉你，去找RM要人，和PO打好组合拳，因为这很难解决当前的实际问题，而是因该做好长线准备，尽量避免出现这种更因该在组织结管理上规避的问题。

紧随其后的挑战就是来自不同文化的冲击。

因为TechOps这样的内部大环境，先天优势就是敏捷基因根正苗红，还有就是来自内部的客户，两者的关系是相辅相成。

如果项目交付压力大，团队背着一座座KPI大山，马不停蹄追赶着步步紧逼的时间节点，敏捷很容易被挤压变形，这和团队由谁组成并没有直接关系，毕竟交付团队的首要目标一定是交付。

因为有了这样的客户，有了这样的基因，嗅觉灵敏的RM自然就会想到，这里的一方水土是打磨尤物的优质资源，一定会物尽其用。

锋锐的敏捷思想，丰富的外来经验，在这方宝地上自由驰骋，碰撞出惊涛骇浪。

这就是一把双刃剑，敏捷是个方法论，敏捷宣言里用的量词都是“重”和“轻”，怎么让外来经验生出敏捷翅膀，很重要的一步就是快速帮大家定位好自己在团队中的位置，扫清敏捷误区，用敏捷的语言来描述经验。

Tips:

编码

移除技术壁垒

足够灵活的适应多种工作环境

成为团队的role model

公平公正

技术栈管理

胸无城府

随着TechOps中国区组织结构越来越清晰，自增长，平台化服务需求声音越来越强劲。再跨一步，机会和挑战从来都是结伴而行。

时间怎么安排？团队怎么办？PO同不同意？怎么将好的实践推广到其它团队？又如何将其它团队的沉淀反哺团队？

你有时间来做更多的事情，前提条件一定是团队leverage建设健康，成员成长速度跟得上。

让团队做到自组织，自管理，一直都是我们前进的方向。那就意味着给足信任空间，提供足够的支持，让大家接受挑战，并从中成长，最终还得把活给干漂亮喽。

信任的建立很漫长，本身很脆弱。在这个前提下，不要所有的技术方案都由你一个人来定，尽量让大家得到更多的机会来磨练。

自身也需要保持业物知识和技术细节的更新，至于怎么更新，从哪儿更新，更新多少，就得看团队的状态。

尽可能多的和大家一起用业务语言进行讨论，这样可以带来的一种好处是PO能方便的从团队了解相关的信息，不局限于你。

TechOps团队同根同源，闭门造车也终归被时代抛弃。走出去，带着团队的积累，构建更多的联系和信任；领回来，捧着经验和教训，百花齐放，取长补短。

TechOps global更是一大宝藏，我们也需要在这个大舞台上，发出更多来自中国区的声音。平台既服务，离我们那么近，想想都有点小激动。

Tips:

学会授权

找时间编码，但不要满额编

用业户语言描述技术框架，用业务语言沟通需求

花时间和团队成员面对面一对一交流

不要做所有技术相关的决定，多留机会给其它人

团队文化，自组织管理

TechOps的TechLead，只要敢想，三生三世哪里又够。