【51CTO.com原创稿件】 技术管理本身是一种“软”实力，对它的理解取决于你对于事物的理解，而对于事物的理解是伴随着你的生活、工作阅历的增加而变化的。
本文作者以“打游戏”为例，分为如下六部分阐述技术团队管理之道：
- 球员的安抚
- 年轻球员的优势
- 安排尝试多个位置
- 节约开支
- 安排合理的训练
- 选择合适的队长
球员的安抚
以玩足球游戏为例，游戏中的球员，特别是一些很有个性的球员，他们很容易会出现问题。
比如说受不了自己拿钱比别人少，要求加薪的；比如说年纪小，离家远的球员，要求被挂牌出售；比如说比赛中好久没有使用他了，让他感觉没有提升了，也会要求被挂牌出售。
比如说觉得自己职业生涯前景渺茫的，主动要求培训他掌握场上其他位置所需要具备的技能的球员。诸如此类，各种情况都有。
面对不同的情况，我们首先要做的就是安抚，而不是指责，而安抚的最佳方式是从事情的根源着手。
为什么这些球员会出现这样的问题？我们可以扪心自问，真的完全是他们个人的问题吗？我觉得不全是，很多时候是我们的工作没有做到位，也就是说，我们犯错了。
不管你的意愿如何强烈，又做出多大努力，这是不可避免的：在生命的某个时候，你会犯错。错误难以消化，所以我们有时会孤注一掷或回避他们，而不是直面它们。
这时候，我们在确认事物的认知上会产生偏差，导致我们寻求着证据试图来证明自己所坚持着的信念。
比如，被你加塞挡在后面的车的保险杠上有一个小凹痕，你显然会认为是后车司机的错。
这种情况心理学家称之为认知失调，即当我们持有两种相互冲突的想法、信念、观点或态度时所感受到的压力。
比如，你可能认为自己是个善良、公正的人，那么当你在开车时粗暴地加塞到其他车前面时，则会经历这种失调。
为了应对它，你会否认自己的错误，坚称那个司机本该看见你或你有先行的权力，尽管事实上并不是这样。
《错不在我》这本书的作者 CarolTavris 认为：“认识失调是我们在自我认知——我是聪明、善良的，我坚信这是真的——受到事实挑战时产生的感受，显示我们做了不聪明的、伤害其他人的事，证明我们之前的想法是错的”。
回到技术领域。如果你知道大家正在寻找的问题的根源出在你的程序上面，那么请你主动站出来，简要地解释一下存在什么问题，出现问题的原因，以及你能提出的解决对策。
在专业领域，出现这种大规模讨论的原因，往往是由于主导者在情况变得糟糕时得不到直接的答复。
如果能够及时向他们提供信息，说明问题出在哪里、正在采取哪些措施以最大限度地降低问题再度发生的可能性，他们就能对问题的影响做出准确的评估了。
敢于承认错误，并积极地弥补错误所造成的损失，是一种非常可贵的精神，值得我们竖起大拇指表扬。
这让我想起来爱迪生的一位学徒，不小心打碎了一天的劳动成果，实验室其他人都在责备他的粗心，只有爱迪生安慰他，并让他继续担任成果传递的工作。
这一经历最终造就了一位科学家，而不是在这孩子还很年幼的时候就无情地打击，希望那些持这类态度的领导能够看到这个故事。
如果哪一个领导因为你主动承认错误，一股脑把责任全部推给你，那你也应该离开他了，通过这次事件看清楚这个人的品德，挺好的。
年轻球员的优势
游戏中有这种情况，当一个位置上有两名候选球员时，如果他们的能力差不多，我会不由自主地选择年轻球员。
因为他们的可塑能力强，说不定多比赛还能有较大程度的提升，而老球员，可能也就那样了。这是内心真实的想法，管理一支球队必须考虑球队的未来发展。
回到技术管理领域。坦白说，我也会有为什么年轻人机会比我多的想法，这也确实是存在的现实问题。
毕竟，基层岗位上的老兵的性价比在很多时候比不上年轻人了，你不能深夜加班，你不愿意周末放弃与家人的陪伴时间到公司加班，等等，诸如此类的情况在老板眼中都成了很纠结的事情。
我们能做什么改变这样的现状吗？有的。我们应该直面这样的情况，多多利用自己的经验，在有限的时间里快速学习新的知识。
如果可以，我的建议是工作上一定要跟进最新技术的发展动向，某种程度上这和炒股差不多，看好业绩的话提前埋伏进场。
比如若干年前刚有安卓、iOS 的时候，很多人还在塞班上开发，但眼光好的技术人第一时间就转行到了安卓、iOS。
因为先占了坑在最稀缺的时候抢占了先机，与比你晚两年转行的人相比差距可能会越来越大。当然也有可能赌输了，例如 Windows 编程。
每一次业界的革命，都会让一些公司落寞而让另一些公司崛起，程序员工作也是一样的，每一次技术换代也都会导致一些程序员没落而让另一些程序员崛起。
在技术换代面前，之前的工作经验不至于一文不值，但也会大打折扣。另外，正因为技术不断换代，学的快的才比单纯年轻的有优势。
如果技术完全停滞，干五年左右技术就不再成长，那么毕业五年后还当基层程序员的失业风险就越来越大。
这也是某通信大厂被传闻的所谓“35 岁裁员”的写实，听说 35 岁主要针对的就是这些基层程序员，45 岁针对的是基层程序员和技术一线管理者。
不断的盼望着（如果能力够强也可以自己创造）新技术的出现，并且自己保持着不亚于年轻人的学习能力，自然就降低了高龄失业风险。
至于做管理，也是一种出路，因为在管理的经验积累上很难有天花板的说法，十年管理经验可能有很大一部分确实是后五年积累的。
不像写代码，不过也要考虑做管理和技术脱节的问题，得保证这个公司不要你了，你的管理经验是能用在其他公司的。
只有积极地面对每一天的挑战，你才有可能在你的职业生涯上走得更远，否则，很危险的。
安排尝试多个位置
大多数球员都可以胜任多个位置，你可以尝试在不同的比赛中安排他们不同的场上位置。
同一个位置上的使用不能仅观察一场比赛，你需要给他们机会，让他们多试几次，也许你就会有不一样的收获。
我曾经使用一名叫 Lemar 的法国球员，在左边前卫的位置上他表现得不温不火，但是当移动到右边锋位置时，他连续几场比赛均有破门，这让我对他刮目相看，也更加丰富了我的阵容选择。
回到技术管理领域。一位来自浙大的师弟描述自己工作 3 年，现在带领 6 个人的团队做后端技术开发，但是觉得自己还处在技术上升期，想去阿里这样的公司锻炼技术，但又有点放不下现在的职位，咨询我的看法。
我建议他先去锻炼技术，无论是不是去阿里（也不要太相信该厂或其他大厂，还是要以所在部门承担的技术工作职责为优先考虑），都需要加深自己的技术深度。
倒不是说技术管理我做得来，他就不能做，其实并不是这样的。
我的认知是技术积累是一辈子的事情，只有到了一定程度，即你可以花较少的时间学会一项新技术或者架构的时候，你才要去做技术管理的工作，因为技术管理工作会占用你一部分工作时间。
我记得有华为内部某个产品总监评价李一男，他回忆一个场景，李一男完全不懂一个产品的技术，在去 21 楼的会议室路上向他简单介绍后，李一男就能够在会议室无障碍地参与这次技术的讨论，借此事说明李的技术很强。
我不知道这件事情是否真实，我只是觉得这是有可能的。因为技术本身是相似的。
比如分区概念，可以用在 GC 的设计上，也可以用在 HBase 的设计上，在 Oracle 里也有这个概念，而且设计思路和目标基本一样。
那么当一个人的技术基础很好时，他就会很容易理解你所讲的技术，能够最快时间内掌握。
这就是一个人的学习能力，有点类似于慕容复的“以彼之道还施彼身”，只有功力深厚的人才能做到。
再者，你怎么知道他没有学过？也许私下他早就看过很多资料了，杰出的程序员都是有很强烈的主动学习动力和能力的。
什么时候成为技术管理者？这没有恒定的标准，但我的建议是，先打好技术基础，当你觉得每天只用 50% 时间做技术，或是比你的大多数下属都了解技术细节的时候，你可以尝试给自己加上技术管理的工作量。
节约开支
管理一支球队所需要面对的问题也包括财务问题，好球员的收入很高，这时你球队的整体财政赤字就会不断上升。
而解决这类问题的最佳方式是卖出不再需要的球员，或者解雇已经完全没有位置的球员，听起来很残酷，但是必须这么做。
回到技术管理领域。一家公司如果遇到了危机，那么它会立即进行的措施通常有两种，一是裁员，二是业务转型。
2008 年的金融危机影响了很多以海外业务为主的公司，特别是外包公司。有朋友曾和我分享，危机爆发后的一年，公司准备大裁员，大家陆陆续续都被劝退了。
对于那些严重依赖单一收入来源，技术含量又不高的 IT 公司来说，一旦出现危机，首先能做的，也可能是唯一的方式，就是裁员。
这个措施针对的可能是收入、年龄均较高的员工；可能是普通员工；也可能是高管，这要看股东制定的策略。
再来看第二种方式，业务转型，可能是单纯业务方向、产品的转移，也可能会涉及具体技术方向，当然，两者都需要的也很正常。
转型没有裁员这么直接，但是对员工的影响也不小，毕竟每一个人都有自己擅长的技能、感兴趣的业务和技术方向。
如果业务出现大范围转型，那么意味着你需要学习新的技能，而且是快速学习、上手，不然可能会走上前一条路：被裁员。
对于学习能力、自我调节能力较差的员工来说，内心会很不愿意做这样的转变，甚至可能出现抵触情绪。
也有另外一种情况，比如原来写 Java 的，现在公司业务转型，要求你用 Python 编程，这时候就会有一些工程师不愿意了，积累了多年的技能，不想轻易丢弃。
无论是什么原因，如果不按照管理层指定的策略转型，最后的结果都是走人。
对于这类情况，我觉得既然从一开始就选择了工程师职业，最好能够做好终身学习的思想准备，并付诸实际行动。
毕竟外部环境在不断变化，科技公司好好坏坏都用不了三十年，几年就河东河西了。
无论是否跟着公司转型，都需要我们具备较强的自我学习能力，不断强化自己的综合能力，跟上技术的变迁，为自己的转型提前做好准备。
安排合理的训练
一名球队的主教练，需要合理安排大家的训练时间，这一点很重要。
因为这直接决定球员的体力，如果你安排的训练过于频繁，那么就会出现球员上场比赛时体力都只有 80% 的情况，这样导致他们不能在最佳状态下比赛了。
回到技术管理领域。做过项目的团队管理者一般都有这样的经历，团队成员正在专心处理现场问题，但却莫名其妙被人投诉。
投诉可能来自市场部门，也可能来自技术支持，或者兄弟研发部门，也容易出现团队成员每天被大量无用的会议烦扰，不去的话就要被投诉，这类情况在大公司司空见惯。
我们要学会保护团队成员，让他们免受组织中每日泛滥不绝的各种问题、争议和“机会”的干扰。
在大一些的公司内部，官僚主义政治会通过各种文书工作来忽略或者缓冲每天的各种请求和问题。
在小一些的公司里，面对挑战的是各种销售驱动的机会、客户驱动的争议问题，以及管理驱动的想法，作为团队领导者，你可能是他们最后或者唯一的防线。
很多团队管理者的大部分工作内容是理解、评估、讨论、协商、推迟、记录，以及最后统一或拒绝去处理这些问题。
如果你让你的下属去处理这些问题，那么最终他们会淹没在这些繁杂事情的洪流之中，会极大地降低他们的程序设计效率。
通过保护你的员工，可以让他们避免把宝贵的时间浪费在临时事务上。而且也能让他们工作得更愉快。
因为某些问题可能会演变成完整的流言，让人担心项目变更，担心收购、重组或裁员，这些流言会大大降低士气，并导致各种损坏工作效率的猜测和抱怨。
另外一种你必须提供的保护是，保护你的员工免受开发之外的同事或者部门的攻击。
这些攻击或者抨击往往并没有充足的信息或事实根据，有些抨击是出于好心的，有些则是恶意的，甚至可能包括个人攻击。
对这种情况我的建议是保持警惕，处理之前先充分了解情况，如果确实存在无根据的抨击，事发当时或事后私下沟通，告诉那个发出抨击的人，指出他的行为是不恰当的，已经让你无法容忍，让他知道事情的严重性，而不是一味指责自己的员工做得不够好。
有一个情况我想特别说明。公司内部非重要部门组织的会议，尽量不要放在周五的晚上、休息日进行。
放在这种休息时间，看起来很有效率，其实是在过度使用研发资源、过度消费员工对公司的满意度。
周五晚上、休息日可以打扰研发人员的事情是：
- 现场问题，必须立即处理（不处理会损害公司未来利益）。
- 重要客户提出需求，要求立即做出回复（不处理会损害公司当前利益）。
- 特别重大的突发事件（对你、对公司都很重要）。
选择合适的队长
游戏中每场比赛都需要指定场上队长，我记得加里内维尔在曼联期间一直担任着副队长，这是因为他应该算是曼联青训营出来的那帮 95 黄金一代里最为勤奋的。
但是他是副队长，这又是因为他的体格和性格在球员中都太普通了，真的遇到强悍的对手时就会有点怂了，所以需要基恩这样的硬汉来担任队长。
在游戏中，我通常指定领导力、沟通力、决断力、技术能力都较好的球员担任队长。
回到技术管理领域。我们在选择队长（Leader）之前，先来看看团队的组成。
我们假设现有团队全部由普通程序员（能够完成交代的工作，但是没有主动创造能力）组成，这时候其实团队中没有任何一位成员会成为合格的技术经理。
除非他们遇到特别复杂的环境，逼迫着他们做出自我改变和自我激励，否则他们会一直保持现状。
这种情况下，我们需要做的是招聘 1-2 位杰出的程序员，这一步要耐心，明确候选人是否是真正的杰出程序员。
因为只有招聘到真正正确的人才才能让工作高效，如果招到的员工很差，那么你就没有时间去处理其他的工作了（总是有各种问题不停地困扰着你）。
这就是为什么平庸的团队需要有集技术和管理丰富经验于一身的高手空降到团队的原因。
但是可惜国内很多公司都不愿意这样做，因为担心现有团队成员会比较排斥，也担心空降的人能力不到位，这其实是能力评估方法论的问题。
很多团队倾向于让系统架构师担任团队负责人（队长），但是需要注意的是，一些系统程序员/架构师往往在团队里显得有点格格不入，这是因为他们很多都是“独狼”，他们可能脾气很差，也可能技术上很有个人主义。
这也是个人成就差别最大的群体。和这类人不同，杰出的程序员能够以一种优雅而简洁易懂的设计来架构大型的复杂系统。
这些优秀的系统往往能让所有其他程序员的工作都更加轻松，因此，单人就能带来巨大的杠杆效应。
我的理解是需要让系统程序员/架构师深入到开发工作，不要让他们只设计、不编码，应该把他们引导成为杰出程序员。
否则他们最终可能成为团队的鸡肋，其实真正的架构师本身就是团队的领导者。
后记
每个人都有自己的优势，努力在职业生涯中找到自己的优势，最大程度发挥它、利用它，你会有收获的，加油，诸位。
作者：周明耀
简介：毕业于浙江大学，工学硕士。13 年软件开发领域工作经验，近 10 年技术管理经验，4 年分布式软件开发经验，提交发明专利 17 项。目前出版《大话Java性能优化》、《深入理解JVM&G1 GC》、《技术领导力程序员如何才能带团队》等三本书籍。微信号 michael_tec，微信公众号“麦克叔叔每晚10点说”。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
