管理技术团队，就必须对技术团队的产出负责：软件的质量和开发效率。我们既需要稳定的软件质量，尽量少的 Bug，尽量好的性能和扩展性，也需要能跟随市场快速变化的软件迭代速度。

而我们的技术团队总会抱怨，需求变化太快，没有时间去重构系统，导致代码的质量下降，开发效率也受影响等等。

如果我们仅仅是通过提高技术团队的个人技术能力，或者刺激开发者更多的“主观能动性”，结果还是会不尽人意的。

因为个人的技术能力成长需要时间和实践经验，而且人员也很有可能会流动；如果主观能动性被刺激成无休止的加班，到头来最后还是会降低团队的工作效率，因为疲劳的开发者只会制造更多的 Bug 和怨言。

因此我们不能单靠传统的工商管理的思路去解决技术团队的产品质量问题，而应该看到软件开发本身是一种具有鲜明特色的行业，要提高产品质量和生产效率，还需要使用更先进的软件生产工具和生产流程。

人员流动、项目进度控制、软件质量提升，是我在管理技术团队中，碰到的最多也是最大的三个挑战。

在深刻的思考和做了大量的管理实践后，我深深地认识到，作为一个技术团队的管理者，最需要的往往不是所谓的“管理能力”，而是对软件开发这个行业，更专业的技术能力。

这些技术能力，大体包含了所谓的“软件工程”知识，以及大量的软件开发工具以及最佳行业实践的经验。

所以我认为，认真地去研究、实践、开发这些，能有效提高技术团队开发效率、准确掌控项目进度、降低人员流动性影响的技术，是具有非常重要意义的。

技术管理者需要研究的三种“技术”

在这里我所说的这种“技术”，具体包含些什么呢？概括一下，有如下几类：

• 软件模式知识。
• 开发工具和实践。
• 需求领域知识。

01 软件模式知识

软件模式知识主要来自软件工程类，包括如何写出可读性好的代码，面向对象或者结构化编程的知识，设计模式、架构模式等等。

其中最基础也最重要的，就是“编写可读性好的代码”，与其说这是一种知识，还不如说是一种态度。无可否认大多数工科、理科出身的程序员，对于写文章的训练都比较少，所以也不难理解为何对此没有“感觉”。

其实要编写可读性好的代码，最简单的方式就是重视“命名”。顾名思义是人类最简单的阅读体验，代码中的变量、函数、类的名字如果是“有意义”的，那就会大大提高代码的可读性。

但是，怎样才能定义一个有意义的名字，而不是仅仅根据技术功能实现的需求来设计名字呢？我知道我们都爱循环变量 int i，但那是因为我们都熟悉它的这个含义。

对于可能阅读代码的人来说，还有什么是确定大家都会比较熟悉的呢？肯定就是业务领域的内容，因为要接触这份代码，肯定是那些要在这个业务领域工作的人，所以使用业务领域的内容词汇是最好的。

但是，由于我们的代码往往会有很多层的抽象和封装，所以在某些层次也许无法找到业务领域词汇去对应，这确实需要一些想象力和抽象能力，但是不管这种想象的是否合理，一定会比不假思索的用 Controllor 或者 Manager 这样的名字来得“有意义”。

除了命名以外，代码可读性还有各种各样的需求，而业界也对这一类要求，总结出很好的规范，他们就是各种“代码风格规范”，最著名的有 Google 公司开放的规范，包含了多种编程语言的版本。

更重要的是，我们还可以用类似 cpplint 这类的“代码静态检查工具”来自动的检查代码是否符合这样的规范。

就连 Google 这样业界知名的公司，也会要求所有程序员写出来的代码，都要像是一个人写出来的那样（出自《Google 软件测试之道》），我们还有什么理由去追求各种代码编写层面的奇技淫巧呢？

除了静态代码检查工具，我们也可以组织一些代码检视（Code Reivew）来保障这个方面，所幸的是，市面上的大多数 IDE 都支持某些 Code Review 的插件，寻找一个好的代码检视工具，然后在实践中用好这个软件，也是一种让人愉快的体验。

更重要的是，如果一个新入职的程序员，能发现自己的代码是受人关注的，在编码上的技巧和问题是有人指导的，也会加强对团队的信任和凝聚力，从另外一个意义上看，这也是一种有效的降低团队流动性的手段。

反过来说，如果不时地参加代码检视或者其他代码监管的活动，管理者也能更准确地了解成员的编码水平，从而做到赏罚有据。

在良好的代码可读性基础之上，对于代码模块和模块抽象，也是需要一定的专门技术的。这里要接触到的就是“结构化编程”和“面向对象”两种概念。

这两方面的书籍汗牛充栋，但是我觉得需要强调的是，“结构化编程”并不和“面向对象”是冲突的，它们之间的关系非常密切。

如果你能把某个需求有逻辑性的细分下去，必须要有足够的抽象思考和对业务领域的理解能力。

面向对象是一种面向名词的思考方式，结构化的思维同样需要用到。所以结构化编程的思维同样是面向对象设计的基础。

这方面的专业论述有很多，但是最可惜的是，我们很多技术团队，仅仅把这些看成是程序员的“个人修养”，而不是一个团队的必要要求，所以我们的代码质量往往参差不齐。

其实和“代码风格规范”一样，代码模块的设计也是必须要符合一定规范的，这个在不同的团队和业务领域中可能不一样，但是没有规范或者指导思想，是最差的一种。

因为这个层面的知识，由于业务需求和领域的不同，往往很难有完全统一的业界标准，所以更加需要团队的管理者来制订和执行。

这也是对一个技术团队管理中最具挑战性的部分——如何定义、抽象、管理业务模型。而这部分也是很多管理者忽视的部分，他们有太多行政工作要做，反而认为这些事情应该交由其他人代劳。

在这个事情上，如果不是有业务领域经验丰富的人去做抽象，就一定避免不了模型和需求不对应产生的修改工作量；如果不具备丰富的代码设计能力，如设计模式的人去设计，需求变更造成的工作量可能会毁掉整个项目。

优秀的程序员——往往都成了管理者，必须要发挥自己的这些智力优势来提高技术团队的产出，而不是去做别的一些没有什么“技术要求”的工作。

况且这些设计工作是那么的有挑战性和趣味性，工作量（从开发时间看）也不是那么大。

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

这种情况，就是我认为的技术管理工作，最后还是要落实到技术工作之中的重要理由。

当然，你可能会说，如果一个非常大型的团队，CTO 也是需要这样去管理吗？

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

这里提一点题外的例子，比如二战时德国装甲兵总监古德里安，除了多次打报告要求组建强大的装甲兵集团，还自己去找了两辆卡车装上铁皮，安排模拟的坦克训练。

这类高级管理者做具体工作的例子非常多，最重要的是要抓到问题的关键点去做。我们最常见的毛病反而是不关注难点重点，一味高屋建瓴的提要求而不找解决方案，这是管理的大忌。

如果一个团队能关注代码模块的抽象，能经常讨论诸如设计模式、重构这些设计问题，那么就能有机会在更高的抽象层次上，使用更有价值的设计理论，比如架构模式。

最近几年无论是 Web service、SOA、restful，还是所谓云（PaaS、SaaS），这些流行的名词，从某种意义上来说，都是一种架构上的创新：结合最新的技术和最新的业务领域。

使用什么技术，上什么架构，是一个技术团队管理者必须随时学习和思考的问题，固步自封肯定会有稳定可靠的好处，但也是让一个产品腐烂落后的原因。

勇于挑战和尝试，才是一个积极向上的技术团队应有的气氛，而这个气氛首先要考验的是管理者的勇气。

02 开发工具和实践

关于先进的开发工具和实践，一直以来都有推陈出新，从最简单的版本管理工具，到各种高级的 IDE 软件、缺陷管理系统、知识库管理等等……其中自动化测试技术，是最重要的一种。

《人月神话》中写到，由于没有版本管理工具，作者所在的团队花了巨大的努力，制定了各种管理规范，来解决代码分支和覆盖的问题，甚至要靠把源代码打印到纸上，堆得比人还高。

我们常常把测试认为是一种“质量检查”的工作，但实际上，测试是代码生产的生产线。

我们如果以测试驱动开发的角度来看，需求首先变成测试用例代码，具体实现代码的首次运行也是在测试用例代码中，最后整体项目的运行，也是由测试代码来启动。

这个过程中，测试代码就好像产品的模具，保障整个产品是设计的样子。可惜我们常常并不愿意花时间去打造模具，就好像我们直接用手工直接去做产品一样。

但问题是，如果我们的产品只是一次做出来就好，但是软件系统往往需要大量的，不同部分的修改，没有测试系统的保障，我们肯定会改了 A 地方，B 功能就会出错。

一个项目如果测试用例足够全面，就算功能代码全部丢失了，凭借测试用例，也能很快地重建出功能代码来。

更重要的是，测试代码还能保证多个层次的代码，都维持一个稳定的“样子”，这对于项目团队的人员交接，是有重要意义的。

我们在项目管理的过程中，常常会苦于不知道项目进度如何，但如果你有一个完整的测试驱动开发的流程，这个问题就不会那么棘手：

• 需求明确的工作可以看测试用例的编写进度。在编写测试用例的过程中，大量的模糊不清的需求，都会被落实成代码，这也排除了很多日后延期的可能。

如果在比较复杂的系统中，代码的抽象层次有多个，那么测试用例也许同样会有很多组。

但不管怎么说，每一层的设计最后都落实成为测试用例的话，整个项目的需求也会因此稳定下来。

• 如果我们是针对这些测试用例去做开发，那么每天我们都可以统计到有多少个用例被完成，这比从或空洞或繁琐的程序员日报里，可以获得的信息准确的多。
• 在产品运营的过程中，我们可以把所有发现的故障和缺陷，都补充为测试用例，这样就可以确保项目的质量逐渐稳定下来。

当我们真的需要重构的时候，只要有这些测试用例，就能放心大胆的去修改代码，因为只要通过所有的测试用例，项目的质量就一定是可靠的。

所以一个自动化、高覆盖率的测试系统，是一个项目在管理上最有效的工具。

测试工作有那么多好处，但为啥总会觉得有很多困难无法实践呢？关键点就是测试中的各种依赖很难构建，这就是一个比较专业的技术问题——Mock 和 Fack 系统。

所以我们的问题又一次回到了技术上，构建足够专业的 Mock 和 Fack 系统。

03 需求领域知识

需求领域知识，从某种方面来说，不算是“纯技术”的领域，但对于特定开发某个业务领域的团队，这些知识的掌握程度，往往是至关重要的，因为只有在深刻地理解了需求，才能真正用好各种抽象、模式等软件工程知识。

程序员们往往都会有一些误区，认为只有技术领域才是自己应该关注的，有些人可以非常熟悉 Linux 内核的各种实现细节，但却对最近的一个项目的市场情况漠不关心。

很多程序员往往会认为，计算机科学中的那些知识，才是知识，而他们所接触的其他业务领域，都不是他们应该关心的。

可惜的是，大部分的程序员，也叫软件工程师，都是需要解决计算机科学以外的业务问题的。所谓工程师，就是利用已有的工具，去解决实际的问题。

所以，对于实际要解决的问题领域，不进行完整细致的学习理解是不行的。

事实上，计算机科学，也是因为其他业务领域的需求而发展起来的，比如军事、金融等。

要深入地去学习一个业务行业领域的知识，也是需要很多时间的，这往往和程序员希望自己的技能通用化有冲突。

但我认为这个世界上没有那么多“通用”的知识可以用，能专心做好某一个领域已经很不错了。

所以你花时间深入到具体的业务领域上，去学习和实践各种技术解决方案，会比只是空泛的“领导”一队人做事更能发挥作用。

小结

技术团队的管理，如果仅仅从一般意义的“管理”上去解决问题，往往是无解的。但彼得·德鲁克说：管理本质就是创新。

我的理解是：管理就是要去找解决问题的方法，如果这个方法看起来很不像一般意义上的管理，那也无所谓，因为解决问题才是目的。

打破对“管理”的看法，求真务实的去寻找解决问题之道，才是真正的“管理”。技术团队的管理问题用技术手段解决，是我切身体会的最好的解决方法。