腾讯高级工程师的自述：如何管理技术团队

测试积点老人

       任何项目都需要经过团队的共同作用才能最终实现。对于游戏项目来说也是一样，只有团队里的成员心力都往一处使，才能发挥最好的效果。但是要想管理好游戏技术团队可不是什么容易的事。不过我们或许可以从一位腾讯高级工程师那里学到一些管理方法。

　　从2001年在网易成为一名项目经理，到2011年进入腾讯，我经历了从“领导”几个人到几百个人的好几种管理岗位，名字有的叫“总监”，有的叫“经理”，还有什么O之类的。但是在十年之后，现在的我没有一个下属，一般的人看来似乎有点不可理解。正常来说，中国人的传统是“学而优则仕”，管人的总比做事的看起来要“高级”一点。

　　那么，为什么我要“急流勇退”呢?其实并不是我觉得做一般的管理工作力不从心，也不是因为厌倦了管人，或者想要做闲云野鹤，而是我发现，如果要真正的管理好一个技术团队，还是要从技术方面下手。而这些真正能对技术团队管理有帮助的技术，不实际的去学习和实践，是非常难以掌握和熟练的。

　　技术团队有多难管，从人员流动这个事上，就能最直接的体会到。我记得我第一次参加网易的校园招聘，招聘了的几十个应届毕业生，这些毕业生在一年之内，有70%都离职了。他们有的是去考研、有的去留学、还有继承家族生意和考公务员的。当然留下来的那批，也有一部分在两年之内跳槽了。按理说网易也算是不错的公司，尚且面临如此之高的离职率，其他的公司可能会更加严重。

　　我在这个事情上，花了无数的精力希望打造一个“具备凝聚力”的团队，试图降低这种流动性。但是无论如何努力，技术团队还是会“维持”着某个流动率，所以我意识到，如何降低人员流动对工作的冲击，才是一个必须要做的事情。我们知道，软件开发的交接，不是一个简单的事情。因为软件开发的文档、代码、工作关系，甚至很多工作的经验，都是以一种智力形式存在的。这种智力产品，如何从一个人的大脑迁移到另外一个大脑，如果不借助任何工具，无异于师徒传授技艺，是一个效率很低，结果非常不确定的过程。所以我认为，技术知识在团队内的共享，必须要有一些强而有力的技术工具来保障，才能成功。

　　技术团队的管理除了要应付人员流动的挑战外，如何衡量技术人员的工作量，从而预估工期和掌控开发进度，这也是一个巨大的挑战。这方面关于“项目管理”的知识也算汗牛充栋了。在实际的工作过程中，我们也尝试各种方法，但是不管使用什么“项目管理”的方法，我们总会发现，在项目经理的表格，到产品里可运行的代码之间，总有一道深深的鸿沟。

　　不管我们的开发进度预留多少buff，也不管我们的项目进度报告的周期，从月、周细化到日甚至小时，都无法真正的准确的回答——现在项目开发到什么地步、将来的某个时间点，项目可能开发到什么程度。所以我开始承认，掌控技术项目开发进度，在一些需求变更特别频繁的领域，特别是互联网、游戏这类没有明确客户代表的领域，是一个非常模糊而且复杂的工作。我们必须抛弃工业时代对于某个“项目”的管理思路，而采用更新的思路，以及更有效的技术工具，才能真正的对项目管理提供有效的推动。

　　管理技术团队，我们就必须对技术团队的产出负责：软件的质量和开发效率。我们既需要稳定的软件质量，尽量少的BUG，尽量好的性能和扩展性，也需要能跟随市场快速变化的软件迭代速度。而我们的技术团队总会抱怨，需求变化太快，没有时间去重构系统，导致代码的质量下降，开发效率也受影响等等。

　　如果我们仅仅是通过提高技术团队的个人技术能力，或者刺激开发者更多的“主观能动性”，结果还是会不尽人意的。因为个人的技术能力成长需要时间和实践经验，而且人员也很有可能会流动;如果主观能动性被刺激成无休止的加班，到头来最后还是会降低团队的工作效率，因为疲劳的开发者只会制造更多的BUG和怨言。因此我们不能单靠传统的工商管理的思路去解决技术团队的产品质量问题，而应该看到软件开发本身是一种具有鲜明特色的行业，要提高产品质量和生产效率，还需要使用更先进的软件生产工具和生产流程。

　　人员流动、项目进度控制、软件质量提升，是我在管理技术团队中，碰到的最多也是最大的三个挑战。在深刻的思考和做了大量的管理实践后，我深深的认识到，作为一个技术团队的管理者，最需要的往往不是所谓的“管理能力”，而是对软件开发这个行业，更专业的技术能力。

　　这些技术能力，大体包含了所谓的“软件工程”知识，以及大量的软件开发工具以及最佳行业实践的经验。所以我认为认真的去研究、实践、开发这些，能有效提高技术团队开发效率、准确掌控项目进度、降低人员流动性影响的技术，是具有非常重要的意义的。我在这里所说的这种“技术”，具体包含些什么呢?概括一下，无非有这几类：软件模式知识、开发工具和实践、需求领域知识。

　　软件模式知识，主要是来自软件工程类，包括如何写出可读性好的代码，面向对象或者结构化编程的知识，设计模式、架构模式等等。其中最基础也最重要的，就是“编写可读性好的代码”，与其说这是一种知识，还不如说是一种态度。

　　无可否认大多数工科、理科出身的程序员，对于写文章的训练都比较少，所以也不难理解为何对此没有“感觉”。其实要编写可读性好的代码，最简单的方式就是重视“命名”。顾名思义是人类最简单的阅读体验，代码中的变量、函数、类的名字如果是“有意义”的，那就会大大提高代码的可读性。

　　但是，怎样才能定义一个有意义的名字，而不是仅仅根据技术功能实现的需求来设计名字呢?我知道我们都爱循环变量int i，但那是因为我们都熟悉它的这个含义。对于可能阅读代码的人来说，还有什么是确定大家都会比较熟悉的呢?肯定就是业务领域的内容，因为要接触这份代码，肯定就是那些要在这个业务领域工作的人，所以使用业务领域的内容词汇是最好的。但是，由于我们的代码往往会有很多层的抽象和封装，所以在某些层次也许无法找到业务领域词汇去对应，这确实需要一些想象力和抽象能力，但是不管这种想象的是否合理，一定会比不假思索的用Controllor或者Manager这样的名字来的“有意义”。

　　除了命名以外，代码可读性还有各种各样的需求，而业界也对这一类要求，总结出很好的规范，他们就是各种“代码风格规范”，最著名的有Google公司开放的规范，包含了多种编程语言的版本。更重要的是，我们还可以用类似cpplint这类的“代码静态检查工具”来自动的检查代码是否符合这样的规范。就连Google这样业界知名的公司，也会要求所有程序员写出来的代码，都要像是一个人写出来的那样(出自《Google软件测试之道》)，我们还有什么理由去追求各种代码编写层面的奇技淫巧呢?

　　除了静态代码检查工具，我们也可以组织一些代码检视(Code Reivew)来保障这个方面，所幸的是，市面上的大多数IDE都支持某些Code Review的插件，寻找一个好的代码检视工具，然后在实践中用好这个软件，也是一种让人愉快的体验。更重要的是，如果一个新入职的程序员，能发现自己的代码是受人关注的，在编码上的技巧和问题是有人指导的，也会加强对团队的信任和凝聚力，从另外一个意义上看，这也是一种有效的降低团队流动性的手段。反过来说，如果不时的参加代码检视或者其他代码监管的活动，管理者也能更准确的了解成员的编码水平，从而做到赏罚有据。

　　在良好的代码可读性基础之上，对于代码模块和模块抽象，也是需要一定的专门技术的。这里要接触到的就是“结构化编程”和“面向对象”两种概念。这两方面的书籍汗牛充栋，但是我觉得需要强调的是，“结构化编程”并不和“面向对象”是冲突的，它们之间的关系非常密切。如果你能把某个需求有逻辑性的细分下去，必须要有足够的抽象思考和业务领域理解知识。

　　面向对象是一种面向名词的思考方式，结构化的思维同样需要用到。所以结构化编程的思维同样是面向对象设计的基础。这方面的专业论述有很多，但是最可惜的是，我们很多技术团队，仅仅把这些看成是程序员的“个人修养”，而不是一个团队的必要要求，所以我们的代码质量往往参差不齐。其实和“代码风格规范”一样，代码模块的设计也是必须要符合一定的规范的，这个在不同的团队和业务领域中可能不一样，但是没有规范或者指导思想，是最差的一种。

　　因为这个层面的知识，由于业务需求和领域的不同，往往很难有完全统一的业界标准，所以更加需要团队的管理者来制订和执行。这也是对一个技术团队管理中最具挑战性的部分——如何定义、抽象、管理业务模型。而这部分也是很多管理者忽视的部分，他们有太多行政工作要做，反而认为这些事情应该交由其他人代劳。在这个事情上，如果不是有业务领域经验丰富的人去做抽象，就一定避免不了模型和需求不对应产生的修改工作量;如果不具备丰富的代码设计能力，如设计模式的人去设计，需求变更造成的工作量可能会毁掉整个项目。

　　优秀的程序员——往往都成了管理者，必须要发挥自己的这些智力优势来提高技术团队的产出，而不是去做别的一些没有什么“技术要求”的工作。况且这些设计工作是那么的有挑战性和趣味性，工作量(从开发时间看)也不是那么大。

　　如果管理者在系统的设计过程中和团队密切的互动，解释和宣导自己的想法，在执行过程中监督这些设计的实施，本身也是对产品质量的一种把控，不管是评价下属的工作量，还是理解项目的进度和瓶颈，都是拥有第一手资料的。这种情况，就是我认为的技术管理工作，最后还是要落实到技术工作之中的重要理由。

　　当然，你可能会说，如果一个非常大型的团队，CTO也是需要这样去管理吗?听起来似乎不太可能，但实际上任何一个团队，在某个时间点上，一定会有一些非常重点的项目，或者一些关键的问题要解决，CTO并不是简单的做做规划想想点子，而是要针对关键的业务问题，去做具体的解决方案的。