如何成为优秀的技术主管？你要做到这三点

某个时间段突然一些线上故障频发，各种技术债、业务债被业务方穷追猛打要求还债

如果出现这种现象很大程度这个TL已经失位了，这个团队失控了。

也曾经有人跟我吐槽他的TL把活都分给他们，而TL自己什么都不干！这个技术TL真的什么都不干？

技术管理

团队管理

传统软件公司的PM更多注重于对项目的管理

技术TL更多的职责不再局限于项目角度，而是对业务与技术都要有深入的了解

优秀的管理理念

领导者是一个组织的灵魂

只能是普通的领导与被领导的关系吗？

如果，你作为一个一线技术主管，你会怎么管理团队？

我们试试换位思考，假设自己是技术主管，反推团队成员如何做事才能获得更好的成长。

团队曾经综合实力最强的，我可能会被时间支配而不能再天天写代码，并且，团队充满各种挑战。

依然是每周要写周报，每年要写绩效，想晋升，想加薪、想人生巅峰等等。

在团队只有五、六个人的情况下还好，如果是十几个人的团队的话，会希望有人可以站出来帮我。

首先技术说到底是为业务服务的，除非技术就是业务本身，必须体现它的商业价值。

在很多公司里技术研发真的就成了实现其他部门需求的工具，我觉得这样的技术TL肯定是不合格的。

首先它不能影响业务发展，需求提出方会经过很多转化，如果不是不假思索传递需求，整个过程会失真。

最最重要的是架构设计的能力，可能管理能力还次之。

如果他不是一个业务架构师，不是一个能给团队指明更好方向的人，他最终会沦为一个需求翻译器，产品经理说怎么做就怎么做。

他更多的只是负责保证产品的质量、开发的速度，最终被肢解成一个很琐碎的人。

一旦团队上了一定的规模，团队就会从单纯的需求实现走向团队运营，而运营是需要方向的，业务架构就是一个基于运营和数据的一种综合的能力。

对于管理能力我认为最重要的是对团队的感知能力

因为一旦到了技术TL这个级别，不能脱离一线太远，业务细节可以不清楚，大的方向必须要明确。

如果没有很细腻的感知能力，很多的决策会有偏差。

技术TL要有良好的技术视野，不需要各种技术都样样精通，但是必须要所有涉猎，有所了解

对各种技术领域的发展趋势，主流非主流技术的应用场景要非常了解。

知道在什么场景应用什么技术，业务发展到什么规模应该预先做哪些技术储备

产品架构的设计要有足够的弹性，既能够保证当前开发的高效率，又能够对未来产品架构的演进留出扩展的余地。

技术TL并不需要自己亲自动手写代码，但是如有必要，自己可以随时动手参与第一线的编码工作

技术TL不能长期远离一线工作，自废武功，纸上谈兵。否则长此以往，会对技术的判断产生严重的失误。

另外，技术TL也应该是一个学习能力非常出色的人，毕竟IT行业的技术更新换代速度非常快，如果没有快速学习能力，是没有资格做好技术TL的。

技术TL除了管人和管事之外，其他还有很多事情要做包括建立团队研发文化、团队人才培养与建设、跨部门协调与沟通等

这样以要求技术TL也同时也需要具备良好的沟通和管理能力

为什么我不会喜欢团队喜欢经常抱怨的同学

大促中我们的后端主管说了些很好理解的话：

一个管理十几人的团队主管很难有精力做到面面俱到，去了解所有人的细节，给大家找出合适的方向和机会，甚至认真读完每个人的周报都要用一个下午，很难做到你有一个不错的想法的时候，主管就有时间找你聊聊。如果我是一线主管，我更希望团队同学主动找我聊。

作为主管每天既要处理大量一线信息，又要领导团队做出正确的决策，还要照顾团队的每个成员，做出健康的梯队建设计划等，大部分人是没有这个精力的。

刚开始工作的时候，我们误解主管和下属的关系就是领导与被领导的关系，但其实主管也需要被下属管理，这也就是“向上管理”的由来，简单来讲就是主管也需要下属的协助和推动。

主管大部分时间很忙，这就要求下属在向上管理的时候要尤其注意高效、有质量的沟通，如果我是一线主管，我更希望团队和我交流的方式是让我做选择题、判断题，而不是问答题、思考题。

很多鸡汤文提到老板训斥高管：我请你来不是告诉我为什么不行，而是告诉我怎么实现我的构想。在主管不是拍脑子就做的决定的时候，困难肯定是已经想过了，更希望得到的是下属的帮助。

如果我是一线主管，我希望下属这样帮助我：
1.主动承担团队面临的挑战，给出合理的解决方案；
2.及时向我反馈经过整理的信息和数据，甚至是结论，辅助决策；
3.主动关心同事，组织学习，帮助大家（包括我）进步成长。

除了面对面的交流，和主管最多的沟通机会可能就是周报，这是向上管理的重要途径，然而很多同学把周报当做一种负担，写的极其敷衍，就是一周的流水账，发送出来都是浪费自己和收件人的时间。

团队不会有人认真读完所有人的周报，读谁的取决于周报的质量。个人习惯粗略浏览组内所有人周报（周报有 highlights 多重要），坚持几周就能识别一些需要关注的周报，然后会针对这些人的周报设置邮件规则，必须认真看的，遇到不理解的还要过去问的，其它人的周报就被自动过滤掉了。一个普通员工都是如此，更何况一线主管。可见这么写周报可能在无意中浪费了许多次向上管理的机会。

可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上

技术TL职责一多半的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上

为了保障系统按时交付所需的各种计划、协作、沟通、管理上。

剩余的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。

我当时负责的业务是集团收购一家子公司的业务，在整体技术标规范上与集团的技术标准存在很大的差异。

开发规范可以说是我来到这个团队干的第一件事，

我当时面对的问题是API接口格式混乱，没有标准的RPC服务化，代码没有统一标准的开发规范，技术框架组件非标准化等一系列问题

作为一名业务上的新人，我第一时间制定了一套相对标准、全面的技术开发规范，边写代码边梳理开发规范，引领团队走向统一标准化开发道路。

技术TL职责不仅需要制定日常规范，包括开发规范、流程规范等，推动规范的落地，以公有的强制约定来避免不必要的内耗

命名规范

统一IDE代码模板

Maven使用规范

代码Commit规范

统一API规范

异常处理规范

分支开发规范

统一日志规范

统一MYSQL开发规范

统一工具与框架

目前团队的开发模式还是基于传统的瀑布开发模式

整体开发流程涉及需求评审、测试用例评审、技术架构评审、开发与测试、验收与上线，

这里主要基于TL的角度从需求管理、技术架构评审、代码评审、发布计划评审几个关键重点环节进行探讨，欢迎拍砖。

美国专门从事跟踪IT项目成功或失败的权威机构 Standish Group的CHAOS Reports 报导了该公司的一项研究，该公司对多个项目作调查后发现，百分之七十四的项目是失败的，既这些项目不能按时按预算完成。其中提到最多的导致项目失败的原因就是”变更用户需求”。另外从历年的 Standish Group 报告分析看，导致项目失败的最重要原因与需求有关。Standish Group 的CHAOS 报告进一步证实了与成功项目最密切的因素是良好的需求管理，也就是项目的范围管理，特别是管理好项目的变更。

产品因需求而生，在产品的整个生命周期中，产品经理会收到来自各个方面的需求，但是每一个需求的必要性、重要性和实现成本都需要经过深思熟虑的分析和计划，避免盲目的决定需求或者变更需求，这样很容易导致工作混乱，技术TL如果不能正确的对需求进行把控，会导致整个项目偏离正确的轨道。

需求管理的第一步就是要梳理不同来源的需求，主要包括从产品定位出发、外部用户反馈、竞争对手情况、市场变化以及内部运营人员、客服人员、开发人员的反馈。首先技术TL对产品有足够认知和把控，简单来说就是我的产品是为了满足哪些人的哪些需求而做，产品需求一定要根植于客户的需求、根植于客户的环境。每款产品必定有其核心价值，能够为客户创造更多的价值，基于此考虑往往能得到一些核心需求，摒除价值不大的需求。

需求管理中最重要的就是对发散性需求的管理，往往因此也会导致产品在执行过程中不断的变更或增加需求。由于人的思维是发散性的，所以往往在产品构思的过程中会出现各种新鲜好玩的想法，这些想法可能来自领导或者产品经理自己，但是这些想法往往都是和产品核心方向不相关的，但是由于这些想法能够在当时带来诱惑，因此这些不相关的需求会严重干扰了技术团队的精力，打乱或者延误产品原本的计划。同样技术研发同学也需要建立对产品的深度思考，不要把自己定位成产品需求的实现者，同样需要对需求负责。

很多时候需求的变更或增加是因为我们面临太多选择和想要的太多，没有适当的控制自己的欲望，并以自己的喜好来决定需求，这些因素很容易导致产品没有明确的方向、团队成员疲于奔命，但是却没有实际的成果。所以技术TL一定要能够评估出重新审视产品和筛选需求的优先级，识别每一个需求的必要性、重要性和实现成本。通过深思熟虑给团队明确方向并专注，聚焦资源的支配，确保团队的精力都聚焦在产品的核心需求上。

互联网时代，大家提倡敏捷迭代，总嫌传统方式太重，流程复杂，影响效率，什么都希望短平快，在扁平化的组织中，经常是需求火速分发到一线研发，然后就靠个人折腾去了，其实技术架构评审这同样是一个非常重要的环节。

架构评审或技术方案评审的价值在于集众人的力量大家一起来分析看看方案里是否有坑，方案上线后是否会遇到不可逾越的重大技术问题，提前尽可能把一些事情先考虑到提出质疑其实对项目的健康发展有很大的好处。

基于架构评审，我们的目标核心是要满足以下几点：

架构设计既要保证架构设计的合理性和可扩展性，又要避免过度设计。架构设计不仅仅是考虑功能实现，还有很多非功能需求，以及持续运维所需要的工作，需要工程实践经验，进行平衡和取舍。

架构评审需要以下几点：

其实不同阶段的项目有不同的目标，我们不会在项目起步的时候做99.99%的可用性支持百万QPS的架构，高效完成项目的业务目标也是架构考虑的因素之一。

而且随着项目的发展，随着公司中间件和容器的标准化，很多架构的工作被标准化替代，业务代码需要考虑架构方面伸缩性运维性等等的需求越来越少，慢慢的这些工作都能由架构和运维团队来接。一开始的时候我们可以花一点时间来考虑这些问题，但是不是所有的问题都需要有最终的方案。

代码质量包括功能性代码质量和非功能性代码质量，功能质量大多通过测试能够去发现问题，非功能性代码质量用户不能直接体验到这种质量的好坏，代码质量不好，最直接的“受害者”是开发者或组织自身，因为代码质量好坏直接决定了软件的可维护性成本的高低。代码质量应该更多的应该从可测性，可读性，可理解性，容变性等代码可维护性维度去衡量，其中 CodeReview 是保证代码质量非常重要的一个环节，建立良好的 CodeReview 规范与习惯，对于一个技术团队是一件非常重要核心的事情，没有 CodeReview 的团队没有未来。

每次项目开发自测完成后，通常会组织该小组开发人员集体进行代码 review，代码 review 一般 review 代码质量以及规范方面的问题，另外需要关注的是每一行代码变更是否与本次需求相关，如果存在搭车发布或者代码重构优化，需要自行保证测试通过，否则不予发布。

CodeReview 重点关注的事情

涉及到10人日以上的项目，必须有明确的发布计划，并组织项目成员统一参加项目发布计划review

发布计划包含

为什么要把系统健康度巡检放到技术管理里，我觉得这是一个非常重要的环节。像传统的航空、电力、汽车行业都要有一定的巡检机制，保障设备系统正常运转，同样软件系统也同样需要巡检机制保障业务健康发展。

随着业务的不断发展，业务量和数据量不断的上涨，系统架构的腐蚀是避免不了的，为了保障系统的健康度，需要不断的考虑对系统架构、性能进行优化。

系统的监控与报警能够一定程度发现系统存在的问题，系统存在的一些隐患需要通过对系统的巡检去发现，如果优化不及时在极端情况会导致故障，巡检粒度建议每周巡检一次自己所负责的业务系统。

重点关注的内容

技术规划通常由团队的TL负责，每个财年TL需要从大局的角度去思考每个季度的技术优化规划，去偿还技术债，技术债也是有利息的，因为利息的存在，技术债务不及时偿还的话，会在未来呈现出非线性增长，造成始料不及的损失。

重点关注的内容

在阿里每个人都能感受到拥抱变化，基本上每年组织架构都会调整，甚至有些团队每半年都会调整一次。

14年我也算是被分配到这个团队负责这块业务，这块业务是集团收购一家子公司的业务，整个团队文化和技术体系与阿里有很大的差异化。

一般来说新官上任三把火，新的技术TL空降之后往往会大肆招人，快速推进改革,而且有些技术TL喜欢把原来的一些旧将搬进来。

当时我没有急于这么去做，没有招过一个新员工，而是立足于稳定现有的团队，主要基于以下原因：

团队和业务了解不够深

只有好的制度才能造就好的团队

团队安全感

业务配合不规范

跨团队协作混乱

人往往会高估自己而低估别人

很多时候，我们并不如自己想象的那么强。

管理者在充分理解一些管理的理念之后，不断地在实际的管理工作中去实践并收集反馈和迭代

这样才能够形成自己的管理风格，并找到最适合当前团队的管理方法。

集权式管理

放权式管理

以上这两类管理风格没有对错之分，究竟哪种方式更适合完全取决于团队的状况。

这些年我看到过太多的案例，管理层自己从不真正深入业务，也缺乏对业务的深刻理解，没有找到问题的本质原因。

总是寄希望于招人来解决问题，结果换了一茬又一茬人，问题永远解决不了，而且从来不深刻反思自己是否亲自尝试解决业务问题。

很多时候架构反应出来的问题，其实是组织、流程的问题。

总之，作为管理层，如果自己没有深入一线去发现问题，自己动手去解决问题的决心和勇气的话，那这个团队很难有新的突破和成功。

在我刚参加工作的前几年，就听过一些关于团队文化和企业文化的一些概念，并没有特别深刻的印象。

尤其我读了《基业长青》这本书后

让我感受到对于一个企业而言，决定短期的是技巧，决定中期的是战略，决定长期的是文化

企业文化对一家公司来说真的很重要，同样团队文化对于一个团队来说也很重要，我在带团队之初也曾经忽视了团队文化的冲击

在带领这个团队之初，我私下找一些团队同学做1on1沟通，我发现这里面的问题还是比较严重的，

很多人为了避免故障遭受惩罚，不敢去重构优化代码，

把自己封闭到一个很小的圈子，也没有过多的追求和理想

以前也没有末位淘汰机制，大家觉得可以继续吃大锅饭。

当时部门都是工作多年的老人，老的风气和习惯已经形成了很顽固的不良文化，工作情绪受到很大的影响。

做事情没有积极性

永远不承认自己的错误，永远找借口推卸责任，永远都是别人的问题

不求有功但求无过；责任心差，对待工作自我要求低

对工作安排喜欢讨价还价

在一个不好的文化氛围下，优秀的员工会被排挤，团队没有向心力，也很难留住好的人才，员工流失率会非常高。

我认为衡量一个团队文化氛围是否有吸引力，有一个很重要的指标，新员工的流失率：

如果一个团队氛围非常好，新员工入职以后往往能够快速融入进来，流失率很低；

如果团队氛围差，新员工入职以后比较茫然难以融入，往往会很快离职，流失率非常高

实际上留不住新员工远远比留不住老员工更可怕。

坦诚，公开，透明

平等相处，消除等级感

工作气氛轻松，团队关系和谐

敢于担当，主动承担责任

成就他人，乐于分享。

取决于公司在什么发展时期，需要招聘什么样的人

明确所搭团队的类型

不同类型的技术团队在招聘时也有很大的不同

走过弯路

招聘步骤

招错人的成本比你想象的更可怕

技术TL的成功体现在招到比你更优秀的人

“如果你没有开除或解雇过一位员工，算不上真正合格的管理者”

针对触犯公司文化、原则红线

持续无法跟上公司节奏的员工

把下属从愚昧之巅推向绝望之谷

心要仁慈，刀要快

KPI 考核机制

背景

解决方案

什么样的人有积极性

怎样才算业务负责人