如何成为优秀的技术主管？你要做到这三点
2022-07-08 19:45:51 8 举报AI智能生成
技术主管
作者其他创作
大纲/内容
技术主管是什么？
这个技术TL真的什么都不干？
某个时间段突然一些线上故障频发，各种技术债、业务债被业务方穷追猛打要求还债
如果出现这种现象很大程度这个TL已经失位了，这个团队失控了。
也曾经有人跟我吐槽他的TL把活都分给他们，而TL自己什么都不干！这个技术TL真的什么都不干？
互联网公司的技术团队管理
技术管理
技术主管，又叫「技术经理」，英文一般是 Tech Leader ，简称 TL。
随着工作经验的不断积累，能力的不断提升，每个人都有机会成为Team Leader。
在机会到来前，必须提前做好准备，对TL的工作职责有一定了解。<br>
当然，这也会为当下更好地配合TL工作打下基础。
「技术主管」是开发团队中的某位程序员需要对一起创建系统的整个开发团队负责时所承担的角色。
通常他既要对最终交付的软件系统负责，另外也会像一个程序员一样去开发实现系统。
团队管理
互联网公司的技术TL与传统软件公司的PM有很大区别
传统软件公司的PM更多注重于对项目的管理
包括项目任务拆解、项目进度以及风险等。
技术TL更多的职责不再局限于项目角度，而是对业务与技术都要有深入的了解
就像黑夜里的灯塔，能够引导和修正团队成员前进的航向。
综合技术和业务角度去深度思考问题，
具备一定的前瞻性，并在技术领域投入持续的学习热情，。
向团队成员传道，补齐短板，提高整个团队的战斗力
平凡人、非凡事
优秀的管理理念
阿里有句土话“平凡人、非凡事”，
管理大师彼得·德鲁克说：“组织的目的，就是让平凡的人做出不平凡的事。”
其实每个公司、每个团队的背景不太一样，从管理学的角度探讨一些问题，没有统一标准的答案
包括我最为尊敬的通用电气CEO杰克·韦尔奇、苹果CEO乔布斯、Intel CEO格鲁夫，国内我最推崇的技术管理者robbin（丁香园的技术副总裁）。
领导者是一个组织的灵魂
然而，不是任何一群平凡的人聚集到一起，都能做出不平凡的事。
甚至一群优秀的人聚集到一起，也可能只是一个平庸的组织。
大到一个国家，小到一个团队，任何一个卓越的组织，都必须有一个卓越的领导者。
领导者是一个组织的灵魂，领导者在很大程度上决定了组织所能达到的高度。
技术团队同样如此，管理者的战略眼光、管理方法、人格魅力等，都会给团队的工作结果带来决定性的影响。
技术主管和团队成员应该是什么关系？
只能是普通的领导与被领导的关系吗？
如果，你作为一个一线技术主管，你会怎么管理团队？
我们试试换位思考，假设自己是技术主管，反推团队成员如何做事才能获得更好的成长。
如果我是一线技术主管
团队曾经综合实力最强的，我可能会被时间支配而不能再天天写代码，并且，团队充满各种挑战。<br>
依然是每周要写周报，每年要写绩效，想晋升，想加薪、想人生巅峰等等。<br>
在团队只有五、六个人的情况下还好，如果是十几个人的团队的话，会希望有人可以站出来帮我。<br>
技术TL的核心职责到底是什么？
技术研发不能是实现其他部门需求的工具
首先技术说到底是为业务服务的，除非技术就是业务本身，必须体现它的商业价值。
在很多公司里技术研发真的就成了实现其他部门需求的工具，我觉得这样的技术TL肯定是不合格的。
首先它不能影响业务发展，需求提出方会经过很多转化，如果不是不假思索传递需求，整个过程会失真。<br>
架构设计的能力
最最重要的是架构设计的能力，可能管理能力还次之。
如果他不是一个业务架构师，不是一个能给团队指明更好方向的人，他最终会沦为一个需求翻译器，产品经理说怎么做就怎么做。
他更多的只是负责保证产品的质量、开发的速度，最终被肢解成一个很琐碎的人。
一旦团队上了一定的规模，团队就会从单纯的需求实现走向团队运营，而运营是需要方向的，业务架构就是一个基于运营和数据的一种综合的能力。
管理能力（对团队的感知能力）
对于管理能力我认为最重要的是对团队的感知能力
因为一旦到了技术TL这个级别，不能脱离一线太远，业务细节可以不清楚，大的方向必须要明确。
如果没有很细腻的感知能力，很多的决策会有偏差。
技术TL应该具备哪些素质？
技术视野良好，解决问题能力与架构设计能力出色<br>
技术TL要有良好的技术视野，不需要各种技术都样样精通，但是必须要所有涉猎，有所了解
对各种技术领域的发展趋势，主流非主流技术的应用场景要非常了解。
知道在什么场景应用什么技术，业务发展到什么规模应该预先做哪些技术储备
产品架构的设计要有足够的弹性，既能够保证当前开发的高效率，又能够对未来产品架构的演进留出扩展的余地。
动手能力要强，学习能力出色
技术TL并不需要自己亲自动手写代码，但是如有必要，自己可以随时动手参与第一线的编码工作
技术TL不能长期远离一线工作，自废武功，纸上谈兵。否则长此以往，会对技术的判断产生严重的失误。
另外，技术TL也应该是一个学习能力非常出色的人，毕竟IT行业的技术更新换代速度非常快，如果没有快速学习能力，是没有资格做好技术TL的。
沟通和管理能力
技术TL除了管人和管事之外，其他还有很多事情要做包括建立团队研发文化、团队人才培养与建设、跨部门协调与沟通等
这样以要求技术TL也同时也需要具备良好的沟通和管理能力
技术TL喜欢的雇员应该有的样子
不抱怨
为什么我不会喜欢团队喜欢经常抱怨的同学
1.主管每天也很忙，听抱怨很消耗时间；
2.团队有人抱怨，说明团队自然是有问题了，需要花一定的时间梳理出问题，需要及时给出解决方案，甚至要安抚对方情绪；
3.一个喜欢抱怨的人会影响整个团队的士气。
其实大部分开发抱怨的工作内容很相似，团队成员不配合做事，PD 提了无理的需求等。
大促中我们的后端主管说了些很好理解的话：
“看到大促有这么多问题，我很激动，这种情况很好。
问题越多说明机会越大，如果都是稳定健壮的系统、完善的流程、合作良好的团队，那么，要大促 PM 干什么呢？”
如果问题都是机会的话，那就没有抱怨的必要。但是，如果真的就是有问题，还不能说了吗？
向上管理<br>
一个管理十几人的团队主管很难有精力做到面面俱到，去了解所有人的细节，给大家找出合适的方向和机会，甚至认真读完每个人的周报都要用一个下午，很难做到你有一个不错的想法的时候，主管就有时间找你聊聊。如果我是一线主管，我更希望团队同学主动找我聊。
作为主管每天既要处理大量一线信息，又要领导团队做出正确的决策，还要照顾团队的每个成员，做出健康的梯队建设计划等，大部分人是没有这个精力的。
刚开始工作的时候，我们误解主管和下属的关系就是领导与被领导的关系，但其实主管也需要被下属管理，这也就是“向上管理”的由来，简单来讲就是主管也需要下属的协助和推动。
主管大部分时间很忙，这就要求下属在向上管理的时候要尤其注意高效、有质量的沟通，如果我是一线主管，我更希望团队和我交流的方式是让我做选择题、判断题，而不是问答题、思考题。
很多鸡汤文提到老板训斥高管：我请你来不是告诉我为什么不行，而是告诉我怎么实现我的构想。在主管不是拍脑子就做的决定的时候，困难肯定是已经想过了，更希望得到的是下属的帮助。
如果我是一线主管，我希望下属这样帮助我：<br>1.主动承担团队面临的挑战，给出合理的解决方案；<br>2.及时向我反馈经过整理的信息和数据，甚至是结论，辅助决策；<br>3.主动关心同事，组织学习，帮助大家（包括我）进步成长。
除了面对面的交流，和主管最多的沟通机会可能就是周报，这是向上管理的重要途径，然而很多同学把周报当做一种负担，写的极其敷衍，就是一周的流水账，发送出来都是浪费自己和收件人的时间。
团队不会有人认真读完所有人的周报，读谁的取决于周报的质量。个人习惯粗略浏览组内所有人周报（周报有 highlights 多重要），坚持几周就能识别一些需要关注的周报，然后会针对这些人的周报设置邮件规则，必须认真看的，遇到不理解的还要过去问的，其它人的周报就被自动过滤掉了。一个普通员工都是如此，更何况一线主管。可见这么写周报可能在无意中浪费了许多次向上管理的机会。
技术主管的时间分配<br>
60% ～ 70% 的时间<br>
可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上
技术TL职责一多半的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上
30% ～ 40% 的时间
为了保障系统按时交付所需的各种计划、协作、沟通、管理上。<br>
剩余的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。
和团队管理者不同的是，技术主管的大部分管理工作都是针对具体研发任务和技术事务的。
技术TL职责不仅需要制定日常规范，包括开发规范、流程规范等，推动规范的落地，以公有的强制约定来避免不必要的内耗
01、开发规范
背景
我当时负责的业务是集团收购一家子公司的业务，在整体技术标规范上与集团的技术标准存在很大的差异。
开发规范可以说是我来到这个团队干的第一件事，
我当时面对的问题是API接口格式混乱，没有标准的RPC服务化，代码没有统一标准的开发规范，技术框架组件非标准化等一系列问题
作为一名业务上的新人，我第一时间制定了一套相对标准、全面的技术开发规范，边写代码边梳理开发规范，引领团队走向统一标准化开发道路。
技术TL职责不仅需要制定日常规范，包括开发规范、流程规范等，推动规范的落地，以公有的强制约定来避免不必要的内耗<br>
内容
命名规范
我自己非常注重搭建项目结构的起步过程，应用命名规范、模块的划分、目录（包）的命名
如果做的足够好，别人导入项目后可能只需要10分钟就可以大概了解系统结构。
具体规范包括包命名、类的命名、接口命名、方法命名、变量命名、常量命名。
统一IDE代码模板<br>
约定了IDEA/Eclipse IDE代码的统一模板，代码风格一定要统一，避免不同开发人员使用不同模板带来的差异化以及代码merge成本。
使用IDEA的同学可以安装Eclipse Code Formatter插件，和Eclipse统一代码模板。
Maven使用规范
所有二方库、三方库的版本统一定义到parent pom里
所有业务应用工程统一继承parent pom里所指定的二方库、三方库的版本
统一框架与工具的版本
(Spring、Apache commons工具类、日志组件、JSON处理、数据库连接池等)
生产环境禁用SNAPSHOT版本
升级通用框架与工具的版本，只需要应用工程升级parent pom即可。
代码Commit规范
基于Angular Commit Message规范生成统一的ChangeLog，这样一来对于每次发布release tag非常清晰
Mac下都需要安装对应的插件，IDEA也有对应的插件
具体可以参考阮一峰老师的《Commit message 和 Change log 编写指南》。
此刻忽然想起Linus面对pull request里的骚操作所发的飚：Get rid of it. And I don’t ever want to see that shit again. ——Linus
代码的commit的规范对团队非常重要，清晰的commit信息生成的release tag，对于生产环境的故障回滚业非常关键，能够提供一些有价值的信息。<br>
统一API规范
Rpc服务接口规范
统一Rpc服务接口的返回值ResultDTO
success代表接口处理响应结果成功还是失败，
errorCode、errorMsg表示返回错误码和错误消息
module表示返回结果集
把ResultDTO定义到common-api顶层二方库<br>
这样以来各个应用不需要来回转换返回结果。
Http Rest接口规范
Http Rest接口规范约定同ResultDTO相差无几
加解密规范
签名规范
版本管理规范
异常处理规范
包括内容
狭义上，遇到了Exception，怎么去处理
各种业务逻辑遇到错误时，怎么去处理
服务层
service服务层捕获的异常主要包括BusinessException(业务异常)、RetriableException (可重试异常) 到 common-api
定义一个公共异常拦截器，对业务异常、可重试异常进行统一处理
对于可重试的异常调用的服务接口需要保证其幂等性。
其他业务层
另外有些特殊异常不需要拦截器统一处理，内部可以进行自我消化处理掉
根据场景对应的处理原则主要包括：
降级处理
直接返回<br>
抛出异常
重试处理<br>
熔断处理
弹力设计
这又涉及到了弹力设计的话题，我们的系统往往会对接各种依赖外部服务、Api，
大部分服务都不会有SLA，即使有在大并发下我们也需要考虑外部服务不可用对自己的影响，会不会把自己拖死。
总是希望
尽可能以小的代价通过尝试让业务可以完成
如果外部服务特别重要，我们往往会考虑引入多个同类型的服务，根据价格、服务标准做路由，在出现问题的时候自动降级。
如果外部服务基本不可用，而我们又同步调用外部服务的话，我们需要进行自我保护直接熔断，否则在持续的并发的情况下自己就会垮了；
推荐使用Netflix开源的hystrix容灾框架，主要解决当外部依赖出现故障时拖垮业务系统、甚至引起雪崩的问题。
目前我团队也在使用，能够很好的解决异常熔断、超时熔断、基于并发数限流熔断的降级处理。
分支开发规范<br>
早期的时候源码的版本管理基于 svn，后来逐步切换到 git，分支如何管理每一个公司（在Gitflow的基础上）都会略有不同。
针对分支开发规范，指定如下标准
分支的定义（master、develop、release、hotfix、feature）
分支命名规范<br>
checkout、merge request流程
提测流程
上线流程
Hotfix流程
好处
虽然这个和代码质量和架构无关，按照这一套标准执行下来，能够给整个研发团队带领很大的便利
减少甚至杜绝代码管理导致的线上事故<br>
提高开发和测试的工作效率，人多也乱
减少甚至杜绝代码管理导致的线上事故
方便运维处理发布和回滚
让项目的开发可以灵活适应多变的需求，多人协同开发
统一日志规范
关于日志
日志是产品必不可少的一个功能
具备可回溯性、能够抓取问题现场信息是其独一无二的优点
尤其在生产系统上问题定位等方面具有不可替代的作用
针对异常的日志规范
WARN和ERROR的选择需要好好考虑
WARN
记录可自恢复但值得关注的错误
ERROR
代表了不能自己恢复的错误
对于业务处理遇到问题用ERROR不合理，对于catch到了异常也不是全用ERROR
记录哪些信息，最好打印一定的上下文
记录哪些信息，最好打印一定的上下文
（链路TraceId、用户Id、订单Id、外部传来的关键数据）
而不仅仅是打印线程栈。
考虑日志脱敏问题
记录了上下问信息，是否要考虑日志脱敏问题？
可以在框架层面实现，比如自定义实现logback的ClassicConverter。
why
正确合理的使用日志，能够指引开发人员快速查找错误、定位问题
因此约定了一套日志使用标准规范，现在可以更多的参考《阿里经济体开发规约——日志规约》。
统一MYSQL开发规范<br>
表的设计和 Api 的定义类似，属于那种开头没有开好，以后改变需要花10x代价的
一开始在业务不明确情况下，设计出良好的一步到位的表结构很困难，但是至少可以做的是有一个好标准
统一工具与框架<br>
对开发过程中所用到的公共组件进行了统一抽象与封装
dao 层框架mybatis
cache 组件 jetcache
httpclient组件
common-tools (公共工具)
同时抽取出公共组件<br>
全局唯一ID<br>
分布式锁
幂等
把以上公共组件进行集成到各个应用
把以上公共组件进行集成到各个应用，进行统一升级、维护<br>
这样以来方便大家将更多的精力集中到业务开发上。
02、开发流程<br>
背景
目前团队的开发模式还是基于传统的瀑布开发模式
整体开发流程涉及需求评审、测试用例评审、技术架构评审、开发与测试、验收与上线，
这里主要基于TL的角度从需求管理、技术架构评审、代码评审、发布计划评审几个关键重点环节进行探讨，欢迎拍砖。
需求管理<br>
美国专门从事跟踪IT项目成功或失败的权威机构 Standish Group的CHAOS Reports 报导了该公司的一项研究，该公司对多个项目作调查后发现，百分之七十四的项目是失败的，既这些项目不能按时按预算完成。其中提到最多的导致项目失败的原因就是”变更用户需求”。另外从历年的 Standish Group 报告分析看，导致项目失败的最重要原因与需求有关。Standish Group 的CHAOS 报告进一步证实了与成功项目最密切的因素是良好的需求管理，也就是项目的范围管理，特别是管理好项目的变更。
产品因需求而生，在产品的整个生命周期中，产品经理会收到来自各个方面的需求，但是每一个需求的必要性、重要性和实现成本都需要经过深思熟虑的分析和计划，避免盲目的决定需求或者变更需求，这样很容易导致工作混乱，技术TL如果不能正确的对需求进行把控，会导致整个项目偏离正确的轨道。
需求管理的第一步就是要梳理不同来源的需求，主要包括从产品定位出发、外部用户反馈、竞争对手情况、市场变化以及内部运营人员、客服人员、开发人员的反馈。首先技术TL对产品有足够认知和把控，简单来说就是我的产品是为了满足哪些人的哪些需求而做，产品需求一定要根植于客户的需求、根植于客户的环境。每款产品必定有其核心价值，能够为客户创造更多的价值，基于此考虑往往能得到一些核心需求，摒除价值不大的需求。
需求管理中最重要的就是对发散性需求的管理，往往因此也会导致产品在执行过程中不断的变更或增加需求。由于人的思维是发散性的，所以往往在产品构思的过程中会出现各种新鲜好玩的想法，这些想法可能来自领导或者产品经理自己，但是这些想法往往都是和产品核心方向不相关的，但是由于这些想法能够在当时带来诱惑，因此这些不相关的需求会严重干扰了技术团队的精力，打乱或者延误产品原本的计划。同样技术研发同学也需要建立对产品的深度思考，不要把自己定位成产品需求的实现者，同样需要对需求负责。
很多时候需求的变更或增加是因为我们面临太多选择和想要的太多，没有适当的控制自己的欲望，并以自己的喜好来决定需求，这些因素很容易导致产品没有明确的方向、团队成员疲于奔命，但是却没有实际的成果。所以技术TL一定要能够评估出重新审视产品和筛选需求的优先级，识别每一个需求的必要性、重要性和实现成本。通过深思熟虑给团队明确方向并专注，聚焦资源的支配，确保团队的精力都聚焦在产品的核心需求上。
技术架构评审
互联网时代，大家提倡敏捷迭代，总嫌传统方式太重，流程复杂，影响效率，什么都希望短平快，在扁平化的组织中，经常是需求火速分发到一线研发，然后就靠个人折腾去了，其实技术架构评审这同样是一个非常重要的环节。
架构评审或技术方案评审的价值在于集众人的力量大家一起来分析看看方案里是否有坑，方案上线后是否会遇到不可逾越的重大技术问题，提前尽可能把一些事情先考虑到提出质疑其实对项目的健康发展有很大的好处。
基于架构评审，我们的目标核心是要满足以下几点：
1. 设计把关，确保方案合格，各方面都考虑到了，避免缺陷和遗漏，不求方案多牛，至少不犯错。
2. 保证架构设计合理和基本一致，符合整体原则。
3. 维持对系统架构的全局认知，避免黑盒效应。
4. 通过评审发掘创新亮点，推广最佳实践。<br>
架构设计既要保证架构设计的合理性和可扩展性，又要避免过度设计。架构设计不仅仅是考虑功能实现，还有很多非功能需求，以及持续运维所需要的工作，需要工程实践经验，进行平衡和取舍。
架构评审需要以下几点：
1. 技术选型：
为什么选用A组件不选用B、C组件
A是开源的，开源协议是啥？
基于什么语言开发的，出了问题我们自身是否能够维护？
性能方面有没有压测过？
2. 高性能：
产品对应的TPS、QPS和RT是多少？
设计上会做到的TPS、QPS和RT是多少？
实际上整体随着数据量的增大系统性能会不会出现明显问题？
随着业务量、数据量的上升，系统性能如何去进一步提高？
系统哪个环节会是最大瓶颈？
是否有抗突发性能压力的能力
大概可以满足多少的TPS和QPS？
怎么去做来实现高性能
3. 高可用：
是否有单点的组件，非单点的组件如何做故障转移？
是否考虑过多活的方案？
是否有数据丢失的可能性？
数据丢失如何恢复？出
现系统宕机情况
对业务会造成哪些影响？
有无其他补救方案？
4. 可扩展性：
A和B的业务策略相差无几，后面会不会继续衍生出C的业务策略，随着业务的发展哪些环节可以做扩展，如何做扩展？
5. 可伸缩性：
每个环节的服务是不是无状态的？
是否都是可以快速横向扩展的？
扩容需要怎么做手动还是自动？
扩展后是否可以提高响应速度？
6. 弹性处理：
消息重复消费、接口重复调用对应的服务是否保证幂等？
是否考虑了服务降级？
哪些业务支持降级？
支持自动降级还是手工降级？
是否考虑了服务的超时熔断、异常熔断、限流熔断？
触发熔断后对客户的影响？
服务是否做了隔离，单一服务故障是否影响全局？
7. 兼容性：
上下游依赖是否梳理过，影响范围多大？
怎么进行新老系统替换？
新老系统能否来回切换？
数据存储是否兼容老的数据处理？
如果对你的上下游系统有影响，是否通知到上下游业务方？
上下游依赖方进行升级的方案成本如何最小化？
8. 安全性：
是否彻底避免SQL注入和XSS？
是否有数据泄露的可能性？
是否做了风控策略？
接口服务是否有防刷保护机制？
数据、功能权限是否做了控制？
小二后台系统是否做了日志审计？
数据传输是否加密验签？
应用代码中是否有明文的AK/SK、密码？
9. 可测性：
测试环境和线上的差异多大？
是否可以在线上做压测？
线上压测怎么隔离测试数据？
是否有测试白名单功能？
是否支持部署多套隔离的测试环境？
测试黑盒白盒工作量的比例是怎么样的？
10. 可运维性：
系统是否有初始化或预热的环节？
数据是否指数级别递增？
业务数据是否需要定期归档处理？
随着时间的推移如果压力保持不变的话系统需要怎么来巡检和维护？
11. 监控与报警：
对外部依赖的接口是否添加了监控与报警？
应用层面系统内部是否有暴露了一些指标作监控和报警？
系统层面使用的中间件和存储是否有监控报警？
只有充分考虑到各个环节的监控、报警，任何问题会第一时间通知到研发，阻止故障进一步扩散。
其实不同阶段的项目有不同的目标，我们不会在项目起步的时候做99.99%的可用性支持百万QPS的架构，高效完成项目的业务目标也是架构考虑的因素之一。
而且随着项目的发展，随着公司中间件和容器的标准化，很多架构的工作被标准化替代，业务代码需要考虑架构方面伸缩性运维性等等的需求越来越少，慢慢的这些工作都能由架构和运维团队来接。一开始的时候我们可以花一点时间来考虑这些问题，但是不是所有的问题都需要有最终的方案。
代码评审
代码质量包括功能性代码质量和非功能性代码质量，功能质量大多通过测试能够去发现问题，非功能性代码质量用户不能直接体验到这种质量的好坏，代码质量不好，最直接的“受害者”是开发者或组织自身，因为代码质量好坏直接决定了软件的可维护性成本的高低。代码质量应该更多的应该从可测性，可读性，可理解性，容变性等代码可维护性维度去衡量，其中 CodeReview 是保证代码质量非常重要的一个环节，建立良好的 CodeReview 规范与习惯，对于一个技术团队是一件非常重要核心的事情，没有 CodeReview 的团队没有未来。
每次项目开发自测完成后，通常会组织该小组开发人员集体进行代码 review，代码 review 一般 review 代码质量以及规范方面的问题，另外需要关注的是每一行代码变更是否与本次需求相关，如果存在搭车发布或者代码重构优化，需要自行保证测试通过，否则不予发布。
CodeReview 重点关注的事情
确认代码功能
代码实现的功能满足产品需求，逻辑的严谨和合理性是最基本的要求。同时需要考虑适当的扩展性，在代码的可扩展性和过度设计做出权衡，不编写无用逻辑和一些与代码功能无关的附加代码。
在真正需要某些功能的时候才去实现它，而不是你预见到它将会有用。<br>—— RonJeffries
编码规范
以集团开发规约、静态代码规约为前提，是否遵守了编码规范，遵循了最佳实践。除了形式上的要求外，更重要的是命名规范。目标是提高代码的可读性，降低代码可维护性成本。
潜在的BUG
可能在最坏情况下出现问题的代码<br>
线程安全
业务逻辑准确性
系统边界范围
参数校验
存在安全漏洞(业务鉴权、灰产可利用漏洞)的代码
文档和注释
过少（缺少必要信息）、过多（没有信息量）、过时的文档或注释，总之文档和注释要与时俱进，与最新代码保持同步
其实很多时候个人觉得良好的变量、函数命名是最好的注释，好的代码胜过注释
重复代码
当一个项目在不断开发迭代、功能累加的过程中，重复代码的出现几乎是不可避免的，通常可以通过PMD工具进行检测。
类型体系之外
封装到对应的Util类或者Helper类中
类体系之内
通过继承、模板模式等方法来解决
复杂度
代码结构太复杂（如圈复杂度高），难以理解、测试和维护。
监控与报警
基于产品的需求逻辑，需要有些指标来证明业务是正常work的
如果发生异常需要有监控、报警指标通知研发人员处理
review业务需求对应的监控与报警指标也是Code Review的重点事项
测试覆盖率
编写单元测试，特别是针对复杂代码的测试覆盖是否足够。
实际上维护单元测试的成本不比开发成本低，这点团队目前做的的不到位。
针对以上每次代码review所涉及到的经典案例会统一输出到文档里，大家可以共同学习避免编写出同样的Ugly Code。
发布计划评审
涉及到10人日以上的项目，必须有明确的发布计划，并组织项目成员统一参加项目发布计划review
发布计划包含
明确是否有外部依赖接口，如有请同步协调好业务方
发布前配置确认各种配置，尤其各种环境下的差异化配置项
配置文件
数据库配置
中间件配置
二方库发布顺序，是否有依赖
应用发布顺序
数据库是否有数据变更和订正，以及表结构调整
回滚计划，必须要有回滚计划，发布出现问题要有紧急回滚策略
生产环境回归测试重点Case
03、技术规划与管理
我在带技术团队的这些年，对团队一直有一个要求，每周都要做系统健康度巡检，未雨绸缪、晴天修屋顶，避免在极端场景下某些隐藏的bug转变成了故障。
系统健康度巡检
为什么要把系统健康度巡检放到技术管理里，我觉得这是一个非常重要的环节。像传统的航空、电力、汽车行业都要有一定的巡检机制，保障设备系统正常运转，同样软件系统也同样需要巡检机制保障业务健康发展。
随着业务的不断发展，业务量和数据量不断的上涨，系统架构的腐蚀是避免不了的，为了保障系统的健康度，需要不断的考虑对系统架构、性能进行优化。
系统的监控与报警能够一定程度发现系统存在的问题，系统存在的一些隐患需要通过对系统的巡检去发现，如果优化不及时在极端情况会导致故障，巡检粒度建议每周巡检一次自己所负责的业务系统。
重点关注的内容
系统指标
系统CPU、负载、内存、网络、磁盘有无异常情况波动，确认是否由发布导致，还是系统调用异常。
慢接口
通常rt大于3s的接口需要重点关注，极端并发场景下容易导致整个系统雪崩。
慢查询
MYSQL慢查询需要重点关注，随着数据量上涨，需要对慢查询进行优化。
错误日志
通过错误日志去发现系统隐藏的一些bug，避免这些bug被放大，甚至极端情况下会导致故障。<br>
技术规划
技术规划通常由团队的TL负责，每个财年TL需要从大局的角度去思考每个季度的技术优化规划，去偿还技术债，技术债也是有利息的，因为利息的存在，技术债务不及时偿还的话，会在未来呈现出非线性增长，造成始料不及的损失。
重点关注的内容<br>
架构优化：
一些结构不良、低内聚高耦合的代码则会使得哪怕是微小的需求变更或功能扩展都无从下手，修改的代价很可能超过了重写的代价。
同样系统之间的耦合也需要重点去关注，遵循微服务化的原则，系统也要遵循单一职责原则
对于职责不清晰的系统去做解耦优化，进行一些模块化改造、服务隔离、公用服务抽象。
性能优化：
基于财年对于业务量、数据量的发展评估，根据目前系统服务的QPS\RT,需要提前规划对系统性能进行一些升级策略
包括重点关注对一些慢接口、慢查询的优化。
弹性与可靠性：
系统提供的服务需要保障括数据一致性、幂等、防重攻击
同时也需要从熔断降级、异地多活的角度去考虑存在哪些问题，
目前系统的SLA指标是否能够达到高可用，需要做哪些优化保障系统的高可用。
可伸缩：
应用服务是否保证无状态，关键节点发生故障能够快速转移、扩容，避免故障扩大化。
团队建设
拥抱变化
在阿里每个人都能感受到拥抱变化，基本上每年组织架构都会调整，甚至有些团队每半年都会调整一次。
14年我也算是被分配到这个团队负责这块业务，这块业务是集团收购一家子公司的业务，整个团队文化和技术体系与阿里有很大的差异化。
一般来说新官上任三把火，新的技术TL空降之后往往会大肆招人，快速推进改革,而且有些技术TL喜欢把原来的一些旧将搬进来。
立足于稳定现有的团队的原因
当时我没有急于这么去做，没有招过一个新员工，而是立足于稳定现有的团队，主要基于以下原因：
团队和业务了解不够深
对于目前的团队的人员以及业务，我不够了解，不清楚这里面有哪些坑和陷阱，
一旦初战不利，领导的信任度被透支，在公司恐怕难有立足之地，更不用谈论改造团队，发挥自己的才能了。
只有好的制度才能造就好的团队
针对团队现状存在的一些问题，我初步判断并不是人的问题，很多问题是一些组织、流程、制度上的问题。
我认为只有好的制度才能造就好的团队，在没有解决现有团队的痼疾之前招聘新人
不但不会带来新的生产力，反而会造成团队的混乱
应该先打下一个好的根基，再招人，才能事半功倍。
团队安全感
（1）不想让团队现有的成员感觉一朝天子一朝臣，担心自己在团队中会被边缘化，成为弃儿。
（2）让现有团队心理比较安全，可以安心地好好工作，不至于发生更多的动荡。
当时团队存在的问题和原因
业务配合不规范
产品、运营、研发部门之间配合没有建立合理的工作流程
比如对于产品需求的PRD评审没有标准
对于运营需求没有量化指标
大家都是疲于奔命做需求，导致大家的积极性不够高。
解决方案
制定了相对合理、规范的产品合作流程
把协作流程规范梳理了一番<br>
同产品同学约法三章，明确了PRD输出的标准和规范
运营的业务需求也统一由产品输出
杜绝一句话需求
同产品、前端、UED、QA团队的协作统一标准流程
下游对上游依赖方输出的工作必须有明确的标准规范
口头说的统统无效，拒绝合作。
跨团队协作混乱
跨部门之间的工作配合毫无规范可言
部门之间相互推诿，随便什么业务人员都会随时给研发人员下命令，
长此以往，伤害了研发团队的积极性。
产生背景
由于研发部门不是直接创造收入的业务部门，而是承担业务部门的服务者角色。<br>
作为一个服务者，往往站在一个被动和弱势的位置上，很容易被业务人员举着收入的大棒指挥你无条件的服从。
业务部门人员随便指派任务，随意变更需求，团队同学无所适从。
这样一来，部门内部无论怎样合理的计划都会被外部的力量轻易打破，让团队同学无所适从，导致大家的工作积极性不高，喜欢互相推卸责任。
久而久之，员工就产生了自我保护意识，凡工作尽量往后退，凡责任尽量往别处推，不求有功但求无过。
目的
为打破员工养成的这种自我封闭的保护意识，鼓励员工更加积极主动做事情
解决方案
把这些责任都扛在自己身上，亲自去协调每项工作，让团队成员没有后顾之忧
让团队同学相信我可以搞定他们担心的事情，出了任何问题我可以来背锅
给自己的团队创造一个相对宽松和自由的工作空间，保护团队不被外部的各种杂事伤害到
团队管理
找到最适合当前团队的管理方法
人往往会高估自己而低估别人
很多管理者都会觉得手下交上来的工作做得不够完美，这里考虑不周那里做的啰嗦
但很多时候你只是看到了他人不擅长的地方，或者只是对方和你的出发点不同给出了不同的解决方案而已。
很多时候，我们并不如自己想象的那么强。
管理者在充分理解一些管理的理念之后，不断地在实际的管理工作中去实践并收集反馈和迭代
这样才能够形成自己的管理风格，并找到最适合当前团队的管理方法。
两种风格管理策略
集权式管理
风格概述
管理者的风格是偏细节的
定义清晰的工作目标，并且把工作目标分解得非常细致
让手下的团队能按照整个计划步步为营往前推进
这是一种风格，相对来讲比较集权。
具体内容
参加每一次需求评审，无论需求大小
和研发同学一起去写代码
对研发团队我会做详细的code review
亲自带领研发团队做技术交流和分享
参与技术讨论确认架构方案
目的：和大家建立起了充分的信任
使用场景
带团队第一年的时候可以用
放权式管理
风格概述
定义大的目标，把握大的方向，做关键性的决策。
多数技术人员他们喜欢被领导，不喜欢被管理
但是并不深入每个细节去管控手下团队的执行细节，以结果为导向。
使用场景
团队建设一年之后
业务流程已经清晰的建立起来了
骨干员工在业务上能够完全领会并且达到我的要求
注意事项
对于一个制度刚刚建立，流程还没有跑顺畅，团队残缺，骨干员工业务能力不及格的团队，采用放权式管理是错误的。
你必须事无巨细，从第一线的业务细节抓起
手把手的带员工，教会他们怎么正确的做事情
怎样达到你的要求，手把手的培养业务骨干，搭建团队核心架构。
目的：充分调动团队的自主性和创造性
以上这两类管理风格没有对错之分，究竟哪种方式更适合完全取决于团队的状况。
深入一线去发现问题
这些年我看到过太多的案例，管理层自己从不真正深入业务，也缺乏对业务的深刻理解，没有找到问题的本质原因。
总是寄希望于招人来解决问题，结果换了一茬又一茬人，问题永远解决不了，而且从来不深刻反思自己是否亲自尝试解决业务问题。
很多时候架构反应出来的问题，其实是组织、流程的问题。
总之，作为管理层，如果自己没有深入一线去发现问题，自己动手去解决问题的决心和勇气的话，那这个团队很难有新的突破和成功。
团队文化
团队文化很重要
在我刚参加工作的前几年，就听过一些关于团队文化和企业文化的一些概念，并没有特别深刻的印象。
尤其我读了《基业长青》这本书后
让我感受到对于一个企业而言，决定短期的是技巧，决定中期的是战略，决定长期的是文化
企业文化对一家公司来说真的很重要，同样团队文化对于一个团队来说也很重要，我在带团队之初也曾经忽视了团队文化的冲击
1on1沟通的结果
在带领这个团队之初，我私下找一些团队同学做1on1沟通，我发现这里面的问题还是比较严重的，
很多人为了避免故障遭受惩罚，不敢去重构优化代码，
把自己封闭到一个很小的圈子，也没有过多的追求和理想
以前也没有末位淘汰机制，大家觉得可以继续吃大锅饭。
当时部门都是工作多年的老人，老的风气和习惯已经形成了很顽固的不良文化，工作情绪受到很大的影响。
老的不良的文化
做事情没有积极性
永远不承认自己的错误，永远找借口推卸责任，永远都是别人的问题<br>
不求有功但求无过；责任心差，对待工作自我要求低
对工作安排喜欢讨价还价
团队文化氛围是否有吸引力的指标——新员工的流失率
在一个不好的文化氛围下，优秀的员工会被排挤，团队没有向心力，也很难留住好的人才，员工流失率会非常高。
我认为衡量一个团队文化氛围是否有吸引力，有一个很重要的指标，新员工的流失率：
如果一个团队氛围非常好，新员工入职以后往往能够快速融入进来，流失率很低；
如果团队氛围差，新员工入职以后比较茫然难以融入，往往会很快离职，流失率非常高
实际上留不住新员工远远比留不住老员工更可怕。
给团队树立的文化
坦诚，公开，透明
对团队坦诚，才能和团队之间形成信任
首先，我觉得坦诚无论对于一个 TL 还是团队成员来说，坦诚也是一种价值观，对于一个团队的发展来说是非常重要的。
作为一个 TL，带领一支团队，我觉得最重要的是 TL 本人必须做到坦诚的态度
只有对团队坦诚，才能和团队之间形成信任，只有和团队形成了信任，才能成为一支默契的团队。
什么是信任？坦诚的力量
通用电气 CEO 杰克·韦尔奇说过：什么是信任？当一个领导真诚、坦率、言出必行的时候，信任就出现了，事情就是这么简单。
为什么坦诚精神能行得通？很简单，因为坦诚有化繁为简的力量！
坦诚的性格是管理者最基本的要求
只有管理者坦诚，才能获得团队的信任
作秀式的演讲和奖励并不能够真正获得团队的心，还是需要在工作中脚踏实地一点一滴去做好最平凡普通的事情。
要求坦诚能够让你直面自身的缺陷，有针对性地改变自己，解决团队的问题，造就一个互相信任的团队氛围。
尽量坚持坦诚的态度，否则最终的结果可能远远偏离你的目标。
苹果创始人乔布斯是一个对自己、对别人坦诚得可怕的人，坦诚的残酷，直面事情最真实的一面。
的确坦诚的态度在很多时候会让别人感觉不舒服，乔布斯粗暴的坦诚态度也备受争议
但我觉得，如果你是一个结果导向的人，还是应该尽量坚持坦诚的态度，否则最终的结果可能远远偏离你的目标。
比较典型的案例
日常工作中主管对于下属不够坦诚，下属与主管的平时一些工作沟通中
下属做的不够好的地方，主管不及时进行沟通与辅导，结果最后KPI 考核被打了低绩效。
换位思考一下，这个被打低绩效的人是我，我也会不服气，有问题你为啥不提前告诉我，让我提前去改正。
对待下属要有勇气，敢于指出他们的问题，对于表现不好的员工要敢于批评和管理，例如为什么解雇你。<br>
这些谈话和冲突往往让人感到不舒服，我也承认每次谈低绩效是硬着头皮的，但是你必须有这样的勇气
坦诚不仅仅要对那些表现良好的人，还要对那些表现糟糕的人。
平等相处，消除等级感
让大家感受到你的亲和力
让大家感受到你的亲和力，不是一个高高在上的领导。
比如很多时候团队一些技术方案的决策不是你一个人来决定，有时候还是要善于倾听一下团队成员的意见，要允许团队成员challenge你。
国内外要求下属服从的企业文化很普遍
其实，国内外要求下属服从的企业文化很普遍，这不一定是坏事
特别是公司如果有想法的人太多，想法又无法统一起来，公司的整体战略呈现精神分裂状态，那基本上就离死不远了。
所以管理层统一公司战略，一线员工强调使命必达。
国内的外企格外强调下属的服从性
国内的外企格外强调下属的服从性，把这一点作为员工的基本职业素养来培训
常用来讲解的故事就是《把信送给加西亚》
强调上司安排一项工作以后，下属不允许谈任何条件，不允许challenge上司，必须无条件服从，克服一切困难也要完成工作任务，以解领导之忧。
这种执行力让上司感觉很舒服，而且公司管理实施难度也比较低。
多数管理者都喜欢比较听话的下属，认为顺从的下属更好用
心态上高人一等，不会放低心态倾听下属的意见，即使自己错了也不会承认错误，
为什么不主动道歉 ？
挑战权威，害怕自己的权威被挑战
爱面子，害怕向下属认错，觉得抹不开面子
我也曾经道歉过
我不是圣人，作为TL曾经也犯过一些错误，我也曾私下里和个别同学道过歉
放开心态，不需要过多的太在意别人的看法，这些我觉得都是无所谓的小事。
允许你的下属挑战你
从我个人自身的一些经历来看，其实一味地要求下属服从是有害的，要适当允许你的下属challenge你。
如果团队只为了服从上级命令，坏处
导致团队的人缺乏思考，只是一味的按照 TL 的想法去执行<br>
当下属内心并不认可工作本身，仅仅出于职业性完成工作，成绩最多是合格，很难达到卓越。
导致下属缺乏工作积极性主动性，容易养成下属逃避责任的习惯。
一味地要求下属服从，不能进行任何反驳
尽量给予下属更自由的空间，允许下属去challenge你
尽量给予下属更自由的空间，不要设置过多形式主义的约束；要允许下属去challenge你，参与你的决策，甚至质疑你的决策。
相反我觉得作为 TL 一定要鼓励下属积极主动地思考，让下属能够自己设定成长目标，对工作拥有归属感和责任感；<br>
用这种方式增加下属对工作的归属感，工作责任心更强，更积极主动，能够自我驱动。
当你的决策错误的时候，下属可以帮你纠错，集体的智慧毕竟高于个人，俗话说“三个臭皮匠赛过诸葛亮”。
工作气氛轻松，团队关系和谐
工作中出现的80%问题都是由沟通不当造成的
根据美国普林斯顿大学的调查报告，在所有对工作产生影响的因素中，沟通占的比例高达 75%。
而我们工作中出现的80%问题都是由沟通不当造成的，可见沟通的重要性。
多数时候，我们只想着表达自己的观点，只关注自己想说什么
我们会尽量使用漂亮的PPT、华美的语言、一堆的数据、甚至引章据典，而不关心别人听懂没有，没有思考别人是否想听，别人是否听得懂。
沟通在我们的工作中无处不在，你会发现尤其在技术这个圈子里，能够进行高效沟通的人占比会更少一些
按照沟通对象类型，沟通的分类
向下沟通(同下属沟通)
最为有效沟通方式：一对一沟通。
横向沟通(跨团队沟通)
向上沟通(同老板沟通)
一对一沟通介绍
what
一对一沟通，又被称作一对一会议、One-on-one 等，是互联网公司常用的沟通方式。
一对一沟通虽然被广泛使用，但是涉及的文章却很少
书籍推荐
《创业维艰》的作者本·霍洛维茨是硅谷的顶级VC，投资了Facebook、Twitter等公司。
《格鲁夫给经理人的第一课》格鲁夫是 Intel 公司的总裁，成功带领 Intel 公司完成了从半导体存储器到微处理器的转型，也是我非常欣赏的一位CEO。
why
格鲁夫对「一对一沟通」的介绍
在英特尔，一对一会议通常是由经理人召集他的部属召开的，这也是维系双方从属关系最主要的方法。
一对一会议主要的目的在于互通信息以及彼此学习。
经过对特定事项的讨论，上司可以将其技能以及经验传授给下属，并同时建议他切入问题的方式；而下属也能对工作中碰到的问题进行汇报。
一对一沟通的意义
背景：技术研发同学多数比较内向，不轻易向别人表达自己内心的一些想法。<br>
使得信息从下而上地传递，同时可以把一些疑问、想法、意见、问题、规划等等和管理者做沟通，从而获得在其它渠道不易获得的信息，保证透明。
除了在一对一沟通中交流之外，可以了解到雇员真实情况外，很难找到别的渠道来有效解决。
通过这些1on1的沟通，真的可以得到很多反馈信息，甚至得到的一些信息令我感到吃惊，原来还有这些细节问题我没有做好。
一对一沟通构造了一个渠道，这个渠道自下而上，使得以上这些内容都能够被倾听，从而被解决。
How
参考《创业维艰：如何完成比难更难的事》
1.你有没有认为自己的价值和能力被低估了吗？为什么？<br>2.你觉得在工作中能学到东西吗？你最近学到了什么？你还希望在哪些领域进行学习？<br>3.近期这段时间，对自己有哪些满意、不满意的地方？<br>4.目前工作中，有哪些困惑？希望我如何去帮助你？<br>5.对团队和我的一些期待和建议。<br>6.在公司战略和目标方面，你最不清楚的是什么?
Tip
找个私密的环境
找个空会议室或者别人听不到谈话的角落，不要在工位或嘈杂的环境中进行
因为私密的环境才能降低沟通中某些话被他人听到的心理压力，才能更轻松和真实的表达自己。
最好提前告知1on1的团队成员
一般需要提前1周把1on1沟通的话题、具体时间通知到团队成员
好处：团队成员可以提前准备下聊的内容，因为临时性的沟通很容易出现因为人类记忆力的问题，导致一些想聊的问题在当时没想到。
定期进行
《创业维艰》
本·霍洛维茨认为一对一沟通需要保证至少一个月一次。
《给经理人的第一课》
需根据部属对工作的熟悉度，而进行不同程度的掌控。
事情变化的速度也是影响一对一沟通频率的因素。
落地：作为技术研发部门，我通常会1-2月进行一次1on1沟通。
用心倾听并行动
沟通要有效，用心倾听、保持真诚是必要的前提，否则员工不可能将心中的问题提出来。
保持真诚需要不敷衍任何团队同学提出的问题，不管这个问题有多尖锐。
如果你也不知道如何解决这个问题，不妨和团队同学一起讨论讨论，看看大家能不能一起寻找可行的办法。
切忌不要讲空话和套话，一旦团队同学发现这是一个无效的沟通渠道之后，「自下而上」的通道就被关闭了。
适当引导
并不是每一个员工都懂得一对一沟通的重要性，也不是每一个员工都能主动倾述问题，寻求帮助。
很多程序员的性格都是比较内向的，有一些甚至不善于表达自己。
所以，虽然员工是一对一沟通的「主角」，但是上司也是需要进行适当的引导。
对于上司已经发现的员工工作中的困难，可以适当的主动提出来，以便于更好地讨论，这也会让员工感到很体贴。
敢于担当，主动承担责任
owner 意识
Why
自私确实是人的天性，不是自己的东西，很难谈什么责任感，更不用说主动性了。
因此，团队管理就是要努力地培养大家的责任感，主人翁意识，
How
增强团队成员的参与感
让他们知晓并理解所做事情的价值、来龙去脉，不断地强化使命感。
For Example
将系统、业务范围等根据团队成员的兴趣点、以往项目经历等多种因素划分给指定人负责，并明确赏罚机制。
可以要清晰地传达一种思想
这块东西就是你的，干好了评优、升职、加薪等都会优先考虑；
干不好，出事情了，你要负责，我也会负责。
Purpose
如果有一天你看到团队成员像呵护自己的孩子一样，去对待自己的工作，那么你的目的已经达到了，他已经完全具备 owner 意识了。
What（主要体现在两个层面）
认真负责的态度
认真负责是工作的底线，
积极主动的精神
积极主动是“Owner 意识”更高一级的要求。
成就他人，乐于分享。
建立学习型的组织
What
团队成员要尽可能地分享自己的知识和想法，大家互相学习，也通过分享能够总结自己学习过程中零散的知识点。
Purpose
如何建立人才梯队的，其实就是要建立学习型组织，让大家积极参与学习与分享。
当然，一开始的团队可能没有这样的意识，就需要你作为管理者强行去推动，把要求列入KPI，很认真地考核他，慢慢地，团队就会形成这样的氛围和文化。
For Example（具体做法）
KPI里设置一项技术分享与团队贡献，团队内部轮流进行技术分享
【技术储备】让大家去学习、研究一些前沿技术，尤其是团队可能会用到的一些技术储备
【费曼学习】如果他真的能把这个技术给大家讲明白的话，那他就是真的掌握了
【共同进步】让其他人开始了解并学习这项技术
【软技能提升】锻炼其演讲与口才
鼓励团队成员敢于去分享，乐于去分享，开放心态成就他人。
【团队技术能力提升速度惊人】
你就会发现整个研发团队的技术能力的提升速度是非常惊人的，并且不会再占用太多额外的时间。
把技术培训和分享坚持下去，形成这样一种学习型的文化以后
【新员工快速成长】当你再招一个资历较浅的新员工时，他也在能在这种环境中快速提升，通常半年左右时间就能达到非常好的水平。<br>
读书分享会
把读的一些书籍感受分享给大家
团队的wiki知识库
把一些日常的技术方案、项目总结、故障总结通过文档的形势积累起来
招聘与解雇
对于一个团队来说，人才是最核心、关键的。招聘和解雇尤其对于一个新上任的技术TL，都是一个很大的挑战，接下来我们重点讨论这两个话题。
招聘
取决于公司在什么发展时期，需要招聘什么样的人
【初创时期】
本不太可能招聘到清一色的专家人才
活下来比啥都重要
态度和味道是重点看的
【高速发展】
引进能带来新思路的一些人才
这取决于业务、技术、组织三者的对齐。
既要高技能，又要好的做事态度、习惯。
明确所搭团队的类型
在搭建技术团队招聘前，要先明确所搭团队的类型，
三种不同类型的技术团队
项目驱动型
业务驱动型
技术驱动型
不同类型的技术团队在招聘时也有很大的不同
技术驱动型团队
需要一个在中间件、语言功底非常深厚
有大局观者
业务驱动型的团队
需要有业务sense
具备良好技术和业务架构能力者
走过弯路
阶段1
一开始我对候选人的背景、语言功底、架构能力以及运维、数据库方面比较关注
希望能招到全栈的技术人才
阶段2
后来发现我忽视了一个很重要的点沟通与协作能力、态度。
后来导致新人来到团队后，虽然技术牛B，但喜欢闭门造车，不喜欢和别人沟通，团队协作能力不够好，整体产出和效率不高。
总结
技术层面
在招聘新人的过程中，不能够只盯着候选人有什么经验，会什么框架等技术面
综合素质
着重考量他们的综合素质，一个领导力好的候选人，能够非常快速地融入团队，也能够非常快的学习一些知识。
招聘步骤
根据搭建团队的目标，做好招聘计划
根据团队自身的定位，招聘合适的人才。
作为TL要对候选人的成长负责
切忌因人设岗、因单独项目而招人
比如前端团队招聘一些后端开发，工程团队招聘算法
后果
候选人进来后很难融入到团队
候选人没有存在感
长时间下来，会导致新人离职
确定招聘需求（定岗定责）：
招聘需求归根结底是需要什么样的人，依据整体业务和组织发展匹配。<br>
列出每个岗位的职责、需要具备的技能及其他要求。
合理利用人才招聘渠道
低级中级人才
互联网招聘渠道
朋友推荐
高级别人才
采用猎头定向挖人
人才筛选
作为技术面试官，对于人才的筛选也是非常重要关键的一个环节
要根据自己团队的目标来选取合适的人才，设定完成的时间期限，将面试的重点放在专业技能、管理能力、价值观（公司认同）等方面
一般要求
1.和岗位需要的专业技能高度匹配：专业技术技能面试过关，定岗定责；<br>2.沟通力强：理解公司的业务，知晓管理层，了解公司的发展方向；<br>3.责任心：凡事有交代，件件有着落，事事有回音；<br>4.靠谱并自带正能量：不抱怨，主动解决问题，懂得纪律的重要性，一诺千金；<br>5.价值观认同：认同公司，有目标有理想、有激情有冲劲；<br>6.背景调查：非常有用的一个办法，可以大幅度降低选人风险，不用怕麻烦，这个工作的付出永远都是值得的。<br>
甄别人才的能力
技术面试官需要有一定甄别人才的能力，同时有意识地提高这方面的能力
几点建议
如果对候选人有些犹豫和纠结，请你放弃这个候选人，你最担心的问题往往很大概率上会发生。
明确我们招聘的候选人标准
比如后端JAVA研发：JAVA基础和分布式领域知识技能考察是必须的，少问记忆性问题和太理论性问题，更多地从候选人的一些实践经历中，提取出对这个候选人的更有价值的判断。
一面非常重要，要保证客观、公平，后面的交叉和终面往往参考前面的评价反馈
不仅是为我们的团队选拔人才，更是为公司选拔人才，还是要高标准的要求。
从心理学角度讲，必须要交叉面试，而且交叉面试官的给出的反馈往往是比较客观、中肯的，而且要以交叉面试官的评价为主。
从候选人的经历中去考察综合能力
面试官切忌拿自己擅长的东西去考察候选人
需要认真的看候选人的简历，从候选人的经历中去考察这个人的综合能力。
招错人的成本比你想象的更可怕
一个团队的健康发展，最重要的是核心技术人，所以招聘工作必须谨慎，
一旦有人加入就等于在上了一艘船，其中的纠结、痛苦、欢喜都要一起面对。
不仅仅是薪资那么简单。
所以请一定要放过那些经验不错、资质不错但是很犹豫匹配度、落地融入堪忧的面试者，其结局大部分都是彼此痛苦。
技术TL的成功体现在招到比你更优秀的人
作为技术TL最成功的是招到比你更优秀的人，你不需要担心自己会不会被取代
成就个人和成就团队
作为TL应该抱着如何成就团队的发展思路
不能让自己成为天花板，本身技术就不应该是你最擅长的事情
兼容并蓄，发展多样性
刘邦善用汉初三杰，单项能力不如韩信、张良。
TL不要已自己的长短来衡量招聘的人，而是看团队技能视图的缺口和发展项。
解雇
“如果你没有开除或解雇过一位员工，算不上真正合格的管理者”
解雇员工通常更多的是针对触犯公司文化、原则红线，或者持续无法跟上公司节奏的员工进行的处理。
大多数技术管理者性格比较随和，不喜欢开除员工。
整体上“慈不掌兵”
在开人这件事情上，高级管理者不要过于犹豫，为了一两个人最后影响整体团队的士气反而得不偿失。
针对触犯公司文化、原则红线
出现触犯红线的员工或者跟不上节奏的员工，尤其是不认可团队价值观的同学，
会把一些负面情绪、行为影响到团队其他同学
因杀伐决断，当机立断采用合适的方法让员工离开
持续无法跟上公司节奏的员工
推荐给其他公司适合的岗位
让和自己一起奋战过的兄弟有一个好归宿
让在职的员工感觉温暖
把下属从愚昧之巅推向绝望之谷
心理学上有个著名的邓宁-克鲁格效应，又称达克效应。
大意是，人很容易对自我产生认知偏差，最简单来说，就是会过于高估自己。
达克效应的曲线图：
上面的图片上反映出，大部分人其实都处于愚昧之巅。
人能够成长为智者和大师要先从愚昧之巅，掉到绝望之谷，然后辛苦攀爬，积累知识和经验，成为智者和大师。
有担当的管理者的一个重要责任，就是把下属从愚昧之巅推向绝望之谷，至于能否爬上开悟之坡，看个人造化。
一个合格的技术TL必须要给团队成员塑造一个绝望山谷，同时还要让他看到一个开悟之坡，这样员工会不断突破自我。
心要仁慈，刀要快
作为一个有担当的管理者，我们不应该是一个老好人的角色，也要有冷酷无情的一面
当团队中出现一些达不到团队要求的人，管理者应该主动去拉他一把
如果多次尝试，最终达不到预期，应该请他离开。
因为到了中途，再被残酷淘汰，无论对组织，还是对个人，损失都更大。
KPI 考核机制
一家公司在成长，组织肯定要升级，人员的新老交替也是正常的。
多数互联网公司对于技术人员都有相应的KPI考核，对于达不到预期的人员会进行淘汰。
“不经历3.25的人生，不是完美的阿里之旅”，
当你处于发展的低谷时，经历一次末位考核结果也许能够让他彻底清醒，认识到自己的不足，彻底激发自己的潜能，能够触底反弹。
如果团队成员的表现达不到预期，不通过 KPI 考核机制告诉他，也许他不会意识到自身的一些问题，他永远不会成长起来
相对短期这些经济回报而言，个人的成长更为关键重要。
解雇尤其对于新上任的技术主管还是有一定挑战的，我相信人的本性还是善良的，作为技术TL不想让团队成员面对这一难题，包括我自己在内。
常见问题
每天忙不完的业务怎么办<br>
背景
抱怨声：自己每天很辛苦，想拼命忙完业务后做一些技术的东西，造个轮子什么的
但一个需求还没做完，另外一个需求就安排过来了。
解决方案
把团队面临的问题分一下级
1.重要&紧急，不能按时完成，则都是失败；<br>2.重要不紧急，是个很好的机会；<br>3.技术想法，很好的撬动业务的点；<br>4.单分析只是个业务需求，看不出明显的兴奋点。（Kano模型）
团队的人可能也有几种特性
1.能力强，在某领域是专家；<br>2.能力一般，有潜力，但是非常有积极性；<br>3.能力一般，主动性一般。<br>
分配任务的思路
1.重要&紧急的事情：<br>
只能交给能力强的人去做
意愿上如果有问题，也要说服对方去做
因人成事，可见能力强有多重要
2.重要不紧急的事情
借事修人
如果做得好，这个人以后就有信心了，团队多了一员干将
做不好也有能力强的人给保底，不会造成业务问题
3.技术想法
交给有积极性的人做
这必然占用一些时间
4.业务需求，看不出明显的兴奋点
能力一般，有潜力，但是非常有积极性的人，手头上无关痛痒的事情
只好交给能力一般，主动性一般的人来做。
实际上按照这个向上管理的思路，需要主管去分配任务的时候，你就已经输了，甚至主管来找你问进度的时候也已经输了。<br>
当然每个合格的主管都需要发现、解决团队人才培养的问题，不可能放任问题发生。
什么样的人有积极性
能力强的人很好识别
那什么样的人才是有积极性的，看过一个 AE 快速升 P8 的同学写的文章，他有个很好的习惯。
无论大小难易，永远不满足于做出来指定的事情，一定要给人惊喜。<br>
如果我是一线主管，我不会凭空把一件重要的事情交给某个人去做，我会更期望：
1.团队同学来教育我某件事情很重要，想去尝试；
2.在很多微不足道的小事情上做出了惊喜，有理由相信这件更大的事情也可能做出惊喜；
3.我被分配了纯业务事情怎么办？
上面也提到了简单分析只是业务需求，近五年在阿里将见了太多事在人为的案例，每个人身边肯定也有不少这样的案例。
我们以为自己在做业务，很多时候是因为两个误区：
这不是技术项目：
没有什么所谓的技术项目，所有的技术项目除非是显而易见的项目
，否则肯定脱胎于业务，只有业务一线的同学才可以抽象出来，做业务需求不是坏事情，拿着完成任务的心态做业务才是最要命的。
没目标：
所有做的事情都要契合自己的目标，而自己的目标大部分时候应该和团队目标 match。
今天让我开发一个前端组件，我要看到的是这个需求反应了我营销体系对某个分类能力的缺失，需求归纳到我营销可视化体系完善的目标中，在阿里这种人才济济的环境中目标不清晰的人和咸鱼没什么区别。
怎样才算业务负责人
很多小伙伴已经是实际的业务负责人，和三、四个小伙伴一块解决特定业务领域问题，但尴尬的是级别相同，在分配任务的时候会不好意思，觉得对方也有自己的”技术项目”要做，我得求他把这个业务需求做一下。
这种其实不算真正的业务负责人，如果业务负责人仅仅是分配任务，那么任何人辛苦一些都可以做。业务负责人的核心特质应该是有一条是了解业务的发展、引导相关人的个人目标。<br>
这样可以把业务需求转换成每个人目标中的一环，和上面提到的自己做事情思路是一样的，无非就是写代码的那个人不自己。其实即使主管也不可能命令团队成员去做某事，采用命令那样的方式，团队早晚散伙。<br>
最后，如果我是一线技术主管，我希望团队的业务负责人时刻在两个方面提醒自己：可衡量、可体系化。
0 条评论
下一页
