我工作近 10 年，是程序员出身，有大概 5 年的管理经验，最多管理过 40 人的技术团队。本文是个人的一些观点和建议，以及这些年的一点感悟，希望对于管理人员，特别是中层管理者有点用处。
管理技术团队，其实也是管理的一种。我个人认为，管理能力的核心包含两方面，一是针对人，对人性的了解程度以及沟通能力。二是对事，是否有强大的统筹规划协调能力。
当然，这是对于广义上管理能力的定义，对于技术团队，其本身有一些特殊性（不同性质的团队都有特殊性），所以在管理技术团的时候，要充分考虑到这些特殊性，然后通过管理上的一些手段，才能使技术团队在正常的秩序下有高水平的发挥。下面，我们就技术团队管理的几个方面来探讨一下。
首先，我们来看看技术团队成员有些什么样的特征。一般，搞技术的人，例如软件攻城师，前端攻城师， UI 设计师，运维攻城师等等，他们都是典型的技术型人才，你问我什么是技术型人才？那我问你什么是业务型人才？这样一比较，就出来个大概。技术型人才性格内敛，脸皮比较薄，性格高傲，不喜欢被制度限制，不善交流沟通，喜欢独立思考，契约精神较强，对 IT 圈的资讯比较敏感，崇尚科学技术甚至迷信科学技术等等。（我这里列举的这些特征是对大多技术人员性格的抽象，一定会有例外，但是并不会影响整体。）如果你带领这样一个团队，却采用管理行政人员或者业务人员的方式去管理，那肯定最后会把团队整垮，还落个坏名声。那么，对于这样一群技术型人才，究竟应该怎么管理呢？
1.能去除的制度限制尽量全部去除。
比如，上下班打卡，不能再座位上打盹儿，不准在座位上吃零食、喝饮料，上班必须穿正装等等。为什么要去除这些限制呢，因为研发的工作本质上来说属于一种创作，和作家写文章，画家画画是一样的。在创作的时候，需要保持一种最佳的“舒适状态”，才能发挥最极致。另外，既然是一种创作，肯定有“灵感来了”“状态好”这些因素，所以在一天工作 8 小时内，不可能和车床工人或者其他常规工作者一样，不停地做，做完就好。可能中午别人在休息，我的状态比较好，写了一中午代码，到了下午 2 点多想休息会，如果这时候有硬性规定不让休息，那么势必会影响到下个阶段的发挥，甚至会招来不满。更有些攻城师喜欢在下班后相对安静的环境中码代码，可能晚上会工作到比较晚，但是第二天如果有硬性规定必须 9 点打卡，肯定是不合适的。
2.粮草的保障。
对于技术团队来说，大多数人都是拿死工资，最多有点项目奖金，而且大家都是打工的，不就是为了这份工资么。如果管理者一天到晚画大饼，结果每个月发的和说的又对不上，那么这个团队迟早完蛋。所以对于技术团队的管理者来说，无论是多么慷慨激昂的动员会，还是天花乱坠的期权规则，都不如每个月实实在在的按时按量发放工资来的有效。当然，如果季度有些奖金，年底有年终奖那就更好了。毕竟对于 IT 行业来说， 13 薪几乎已经成了行规。
3.要结果导向而不要过程导向。
我们在管理 IT 团队的时候，最出现的几个词汇就是：进度，需求，变化。其实管理者相当于一个司令，你的任务是下命令，而不是下了命令跟着军队去行军。对于一项任务，管理者只需要分配给责任人，并且评估出预计完成时间即可。在每个检查点，需要检查一下完成进度，对于大的需求，可能时间跨度比较大，所以检查点比较多，对于小的需求，可能一周之内就 OK ，所以管理者需要做的是关心完成的状况与质量，以及是否按时完成，而不是去关心责任人在完成过程中又上了几次厕所，午饭时间又超过了几分钟等等。可能在过程中管理者唯一要介入的理由，就是过程中出现了比较大的异常，这个时候就需要你出来把局面拉入到正常轨道。
我举个例子，有次我把一个比较重要且比较大的需求交给团队里面的一位资深工程师，时间点，进度，等等都确认没问题，总体时间大概 3 周。结果开始一周后，他告诉我最后那一周他需要请婚假，我的第一反应就是能不能找人接手，后来发现不行，这一块一直都是他在负责。后来他跟我说不用担心进度，他会利用空闲时间完成任务并且保证质量，我也就签批了他的请假申请。后来需求 2 周就完成了，最后一周他人不在现场，但是总算需求完成的比较好，测试下来遇到些问题他也可以通过电话沟通来解决。总之，我想说的意思就是，只要最后能保证成果，过程中的不合理或者你认为的不对头，都不太要紧。
4.认真倾听下面的声音，不要太自我。
很多管理者习惯独断独行，认为自己所掌握或者自己所了解的就是真实的，正确的。其实这是管理的大忌。如果把管理比作一杆天平，那么天平的两端分别站着稳定和民主（这个比喻是不是很熟悉？）。如果管理者绝对的独断独行，那么整个团队表现出来的状态是相当稳定的，但是，要搞清楚，稳定不代表认同。但是如果反过来，一个团队事事都是大家一起决定，那一定出大乱子，管理者的决策权何在？谁来为问题买单？所以，作为团队管理者，必须要倾听来自底层的声音，并且加以考虑，有些情况，确实存在问题，就必须要纠正，有些人，对团队有影响，就要解决，不能一味的沉浸在自己的认知里面。
沟通其实是一门大学问，沟通的方式也多种多样。作为团队的管理者，在面对不同的人的时候，需要采用不同的沟通方式，完全强势，或者完全商量肯定不行。沟通的最终目的就是双方或者对方达成一致，得到一个共同认可的结果，如果每次沟通达不成一致，也出不了结果，反而跟吵架似的，那就失去了意义。
5.事前做计划，事中做追踪，事后做分析。
其实这一条并不仅限于团队管理。我们在做任何事情的事后，都应该养成这样的习惯。我们开发一个项目，或者简单的实现一个需求，都需要做计划。为什么？计划就像一根尺子，用来比对你在实际完成过程中的状态是否正常。所以事中的追踪，就是比对过程。当实际情况与计划误差较大时，我们就可以判定是异常，这个时候我们需要分析具体原因。（分析的过程暂且不讨论，在项目管理的书籍和教材中有详细的介绍。）事中追踪的意义在于，当发现与计划的差异时，分析原因，找到问题，让整个事情回到原来的轨道上，不至于失控。事情完成以后，对事情进行回顾和分析，从而得到经验教训，如果团队有自己的经验库或者知识库，那是再好不过了，可以让这些精华得以保存。
6.为团队成员解决问题，让团队成员完成任务。
一个好的管理者与团队成员的关系，应该是管理者解决成员的问题，成员完成管理者布置的任务。我举个栗子，比如现在决定做一个 B2C 电子商务网站，那么团队的架构师告诉你要考虑高并发，并且采用负载均衡啊，缓存啊，集群啊等等一系列技术。那么你首先要评估一下这些解决方案是否合适，如果合适，需要怎么去达到方案的要求：买服务器，买软件，买 license 等等，这些就是你需要去跟上级申请的工作，说白了，是你需要厚着脸皮去搞定老板掏钱的事情。再比如，某个工程师跟你说最近某个 Job 跑的很不稳定，需要在半夜监控，那么是不是可以调一下班甚至加一些补贴。在你评估这是个合理要求后，就又该你上场了，一方面你要向工程师表态，放心的做，后面的事情你会帮他搞定，另一方面，你要说服老板，这些东西都是必要的，确实要为工程师调班并且加一些补贴等等。只有这样，你的团队成员才会放心的全身心的投入到工作中，因为他们知道你会去解决他们的后顾之忧。当然，这里的后顾之忧指的是合理的，确实需要的要求，如果一个员工跟你说一个普通周末要加班并且要 3 倍工资，那你完全可以拒绝并且附上一句 “ 你咋不上天呢？ ” 。
后话
其实管理是一件很复杂的事情，但是我认为管理技术团队相对并不复杂。可能是大多数技术人员都还是比较单纯吧。技术团队的管理者，特别是中层管理者，其实就是个夹心层，经常受夹包气。其实你想想，作为一个承上启下的职位，压力同时来自于下面和上面，收夹包气也就正常了。但是如果我们能够科学的规划任务，分配工作量，调动团队积极性，我想再困难的任务也能够分解成一个一个不困难的小任务，分而破之。而对于团队内的一些声音，能够耐心倾听，加以思考，再汇报给上面，从而采取一些对应措施，那么团队成员也会因为问题得到解决而欣慰。总之，想把技术团队管理好，多看，多听，多想，让老板满意你的执行力，让团队成员有归属感，你就成功了。
