理解程序员
从许多方面看，程序员之间的差异都非常大，只有很了解程序设计的人才能完全理解这一点。大多数公司的高层管理者对所有的程序员一视同仁，这是一个可怕的错误。微软公司的Bill Gates和Adobe Systems公司的John Warnock都没有犯这样的错误，因为他们俩本质上也都是程序员。
这种差异为什么很重要？也许不应该很重要，但事实上，这种差异真的很重要。历经多年的程序员管理工作之后，我们仍然惊叹于程序员之间的巨大差异，需要有区别地进行问题处理和激励。对我们而言，有一点是毫无疑问的：要想成功地管好程序员，首先必须真正地了解每个程序员。
有一点值得重视：我们发现一般情况下，程序员的年龄、性别、种族或文化不会造成太大的差异。根据我们对数以百计的程序员招聘与管理的经验，程序员之间的差异主要来自个人内在因素，而不是外在属性。当然，后天的训练和经历肯定是有影响的，但个人的天赋和与生俱来的特点才是真正的区别所在。
理解程序员的方法有很多种，我们从以下几个不同的角度来考虑：
- 程序设计工种；
- 程序员的类型；
- 领域知识；
- 程序员的工作要求与能力；
- 工作地点与关系；
- 代系特点；
- 个人特点。
1.程序设计工种
了解程序员的第一种方法是分析他们的程序设计工作可以归为哪些类型。程序设计工作通常有下面4种类型：
- 客户端程序员；
- 服务器程序员；
- 数据库程序员；
- Web开发人员及其他脚本编写者。
当然，可能有许多特殊的程序设计工作难以确切地归结为上述某种类型。但总的来说，这4种类型已经覆盖了世界上的绝大多数程序员，其中每一种程序员擅长的问题解决方法、使用的工具以及侧重的产品方向都各不相同。一些极有天分的程序员能够胜任所有工作，但大多数程序员认为自己虽然能完成所有的程序设计任务，但其实最多只能把其中一种做好。
一般情况下，我们建议为不同类型的工作任务安排不同的程序员，不要指望哪个程序员能同时兼任多种类型的工作，否则你很可能最终会为这个决策感到后悔。因此，在雇用程序员或者为项目安排人手之前，首先必须明确自己需要什么类型的程序员。
1.1 客户端程序员
把所有曾经从事过程序设计工作的程序员都统计在内，大部分程序员都属于客户端程序员。这里术语客户端（client）指的是程序所在的位置，通常是终端用户的计算机上。个人电脑的出现催生了无数的“客户端程序”——文字处理软件、电子表格、工作效率程序、游戏以及众多的实用工具（包括微软的Word与Excel、Brøderbund的Myst游戏以及Lemke的GraphicConverter工具等）。而在个人电脑出现之前，程序员所编写的大多数程序都在中央系统中运行。程序的开发者负责把“客户端结果”传输到非智能终端或者智能终端，或者通过打印出的报告提交“客户端结果”。这些程序开发者也是客户端程序员。
随着低成本微处理器的普及，客户端程序员逐渐把业务拓展到嵌入式应用领域，所开发和交付的应用可以在游戏控制台、手机、iPad以及其他的消费电子设备和终端用户设备上运行。
为什么把这些程序员都归类为客户端程序员呢？因为他们在工作时几乎可以完全控制自己的资源。客户端程序员的任务范围通常是有限的，所需要交付的产品也是明确的。因此，客户端程序员/团队的职责很明晰，除了服务器端传来的数据外也几乎不依赖其他东西。
1.2 服务器程序员
这里术语服务器（server）不仅指出了程序所处的位置，还表明了编写程序的目的通常是向远程客户端传输信息和数据。服务器程序所在的机器通常离终端用户都很远，而且大多数这样的程序必须能够同时处理来自多个客户端的多种行为，这就使得服务器程序通常比客户端程序员开发的程序更复杂一些。在编写和部署服务器程序时，通常还要求在增加新机器与资源时能不用改变程序的基本结构，这又进一步增加了开发服务器程序的复杂度。
随着互联网的出现，术语客户/服务器（client/server）就成了Web浏览器与（“在网上某个地方的”）Web服务器之间交互方式的代名词。基于客户端的Web浏览器很复杂，但实践证明，创建能够使数以百计或数以千计的终端用户同时访问同一台Web服务器的服务器程序，确实是一项更为复杂的工作。构建这样的系统通常离不开在各个服务器系统与程序之间进行接口转发、数据传输及同步的工作。这类工作是典型的服务器程序员需要完成的任务。
1.3 数据库程序员
数据库程序员与客户端程序员或服务器程序员不同，他们使用完全不同的程序设计语言和工具，编写的程序给出的结果也截然不同。数据库程序员通常是对终端用户或应用程序所使用或产生的数据进行组织、存储和提取工作。
这些年来，不同数据库系统之间的差别逐年减少，数据库程序员在一个数据库系统中积累的“基本”技术技巧也更容易迁移到别的数据库系统了。尽管像Hadoop这样用于访问TB级数据的“大数据”系统已经涌现出来，但最常用的数据系统仍然是关系数据库，包括Oracle、Microsoft SQL Server、IBM DB2、MySQL、Postgres和Berkeley DB。这些系统中的多数关键概念是相同的，它们都使用SQL语句（以及等价的API）来访问数据。因此，有人可能会认为，其中某个系统的专家很可能也是另一个系统的专家。但根据我们的观察，除非是最基本的数据库操作，否则在特定数据库系统上的实战经验仍然是必需的。
数据库程序员就像是汽车修理工。你可能会随便找一个汽车修理工帮你换轮胎或者雨刮器；但是对于保时捷汽车上的重要问题，你绝不会让一个完全不了解保时捷的修理工来做。数据库程序员也是如此：我们可能会随便找一个数据库程序员撰写报告来访问Oracle数据库中的数据；但需要在数据库系统（如Oracle、SQL Server）上进行重要的开发时，绝不会考虑实战经验不足的程序员。
1.4 Web开发人员及其他脚本编写者
许多Web开发人员使用的开发工具完全不同于其他程序员，在大多数开发工作中，其他类型的程序员通常使用C、C++、C#、Java、Ruby等核心程序设计语言，Web开发人员通常使用格式化标记语言（如HTML、XML、CSS、ASP/JSP）和脚本工具（如Perl、PHP、JavaScript）。Web开发人员的工作有时可以归纳为“剪切、粘贴和修改”（复制一些现成的代码，进行适当的修改以完成不同的任务）。他们也会使用更高层次的工具（如Flash、Dreamweaver或Cold Fusion）来简化脚本编写和部署过程。这就意味着只从事Web开发的程序员虽能够从正规的计算机科学训练中受益，但又不像其他程序员那么依赖正规的计算机科学训练。
另一方面，更多的处理工作逐渐从服务器移至浏览器，通过JavaScript和基于AJAX的框构来完成，这一变化也对Web开发产生了深远影响。浏览器兼容性问题是Web开发人员长期面临的棘手问题。在客户端引入更多的逻辑会加剧这些问题，要求Web开发人员引入更多的传统程序设计原理，所引发的需求，要求Web程序员像客户端程序员一样技术精湛。Web开发人员越来越需要学习客户端程序设计及其所面临的问题了。
前面描述的4种程序员类型是一般性的情况，一些技术高深的程序员实际上可以胜任所有这4种工作。但是，大多数程序员都只专精于其中一个领域，只有在编写“适合自己”类型的代码时才能获得最大的产出。让程序员加入风格不合的项目往往只会引发灾难。程序员也许能够胜任其他类型的工作，但大多数程序员对此没什么兴趣。而如果程序员对自己所从事的工作没有兴趣，那就迟早要出问题了。
2 程序员的类型
为了选择合适的职员，我们还需要理解另一种看待程序员的方法。在上一节讨论的几种类型中，我们侧重考虑了程序员所从事的工作的类型（即客户端、服务器、数据库、Web）。实际上，从技术知识、实践经验和程序员的专长角度去考虑也是很重要的，按这样的思路可以把程序员分类为：
- 系统工程师/架构师；
- 系统程序员；
- 应用程序员；
- 非真正意义上的程序员。
2.1 系统工程师/架构师
在所有开发类职员中，系统工程师/架构师是最有技术和经验的。要想理解所有相关的系统组件（操作系统、通信系统、数据库、在线/离线访问、安全性、硬件等）之间的复杂关系，需要对所有这些技术和系统都有丰富的专业知识和经验。通常，在一个规模合理的团队中，只会有一两个“真正的”系统工程师/架构师。杰出的系统工程师/架构师可以使团队中的其他人表现得更好。他们的系统工作起来会更可靠，通常看起来也更简洁。
Gracenote就是由一个技术和经验都很丰富的系统工程师/架构师创立的，纯粹由他完成的设计和实现创造出了一种令人难以置信的可靠、可扩展而且灵活的服务。Google公司的联合创始人Larry Page和Sergey Brin也是类似的系统工程师/ 架构师，他们在设计和实现上培育的优雅风格帮助Google公司在技术和商业领域都取得了成功。
2.2 系统程序员
大多数系统工程师/架构师都是从系统程序员做起的。系统程序员理解系统中所有组件的工作原理，包括客户端和/或服务器端的操作系统和通信系统。Alan Kay在他的博士论文中引用了Bob Barton对其他程序员如何看待系统程序员的总结：
系统程序员相当于民间宗教中的大祭司。
——Bob Barton
系统程序员负责编写与硬件交互的设备驱动程序，创建能够为设备驱动程序和应用程序执行提供运行时环境的操作系统，为其他程序员创建编译器和调试工具，通常还会为其他程序员提供工具和服务用于交付程序。
在过去，对社交能力正常的人来说，被称为系统程序员几乎可以说是一种侮辱。我们认识许多系统程序员，他们的着装和举止如今已成为代表性的极客造型并流行开来。每当我们想起自己认识的那许多系统程序员，就会想到“我当极客的时候，极客还不受欢迎”这句话（顺便提一下，我们两位也曾经是系统程序员）。
2.3 应用程序员
在专业程序员、学生以及自称为程序员的业余爱好者中，绝大部分都属于应用程序员。应用程序员开发的程序或其结果通常给终端用户直接使用。应用程序员开发的程序包括文字处理软件、电子表格、日历、Web浏览器、iTunes与Windows Media Player之类的媒体播放器、游戏等。应用程序也可以由数据库程序员开发，以便对数据库中取出或存入的数据执行特定的操作。数据库应用程序包括财务软件、机票预订系统以及Oracle Financials之类的数据挖掘工具等。
一些应用程序员能够跳出代码本身的束缚，与应用程序的用户产生同感，真正从用户的角度看问题，从而很好地把握各种可视化、交互式的设计之间的细微差别。这样的应用程序员很适合从事用户界面（UI）的开发。如果让这样一位有天分的应用程序员与一名UI设计师（通常不仅有图形设计背景，而且对人性甚至认知心理学都有所研究）合作，将产生一加一远大于二的效果。
有一些项目（如MacOS的桌面UI——Mac Finder）侧重于UI，要求整个团队都由这种有天分的应用程序员组成。因此，Ron在苹果公司领导Mac Finder团队时，在寻找和面试候选人的过程中，特别看重程序设计技巧和用户视角。他认为：“只懂得程序设计技巧的程序员在那个团队中是无法取得成功的。”
2.4 非真正意义上的程序员
开发团队中有一些被称为“程序员”的技术人员其实并不是真正意义上的程序员。他们当中有些人使用图形用户接口（GUI）指定程序逻辑或商业逻辑，然后生成用户可访问的应用程序；有些人则通过创建脚本或修改配置文件来定制显示的内容。这些“程序员”与真正的程序员之间的主要差别在于：他们使用现成的工具或应用程序，而不是自己直接写代码。
这类“程序员”有其重要性和价值，但他们的技术深度通常不能与我们所讨论的其他类型的程序员相提并论。随着程序设计工具的出现和日益强大，像这样的程序员正变得越来越多，但在本书中我们不会直接讨论他们。
我们所介绍的许多程序设计技术也适用于这种另类的“程序员”。但根据我们的经验，他们中的多数人仅满足于把自己的工作做好，而不像“真正的”程序员那样渴求学习、动力十足。
3 领域知识
程序员在组织所处领域或行业的背景与知识也各不相同。
我们发现职位的分类、描述和需求中对经验的要求是随着经济状况而变化的。经济状况较好时，组织需要具有宽广领域知识的技术人员和技术经理，希望他们能贡献出创造性的思维、集体的智慧以及在其他领域已经得到运用的最佳实践。例如，Ron受雇从产品领域进入金融服务IT行业时，他的团队已经有了丰富的交互计算经验（Mac操作系统）和娱乐产品（游戏与多媒体工具）。Web在1996年属于新生事物，Schwab需要一个外部技术专家来领导其团队为投资者构建具有高度交互性的Web工具。
而当经济状况不好时，组织则会控制规模、缩减开支，只在核心领域功能方面进行有效、有限的发展。企业在这一时期只能够招聘极少数的新雇员，为了降低风险，它们倾向于招聘在特定领域具有多年知识背景的专业人士。
不管经济状况如何，每个团队都可以由具有程序设计天赋、领域知识、分析能力以及技术交流能力的人员混合构成。其中领域知识在雇用程序员团队时是一个重要的考量因素。
4 程序员的工作要求与能力
要想成功地招聘和管理程序员，首先要认识到每个程序员都有其独特的能力。就像雪花一样，任何两个程序员都不会是完全一样的。我们常常会说，程序员之间写代码的能力可能相差一个数量级。这种差异是怎么出现的呢？教育、经验、天赋以及直觉，还有其他无形的因素，都有可能导致这样的差异。
多数程序员不需要借助显式的排名或者头衔，从直觉上就能理解同行之间的差异。但是如果能把程序员的类型与等级正式记录下来，并简要描述每种类型与等级的职位要求与能力（见表2-1），那么管理工作将会轻松很多，项目经理将更容易找到各种任务和项目的最佳人选，高级管理层也将能对组织及其构成有更深刻的认识。
表2-1 客户端程序设计等级指南
| 程序设计等级 | 客户端程序员 |
|---|---|
| 入门级 | 程序员3 |
| 1～5年经验 | 程序员2 |
| 有经验（5～10年） | 程序员1 |
| 有经验（10～20年） | 高级程序员2 |
| 很有经验（超过12年） | 高级程序员1/架构师 |
每个程序设计等级都关联着一组评价标准，程序员必须符合相关条件才能被录用或者提拔到该等级。当然，对工作年限的要求不是绝对的，但可以用于粗略地指出相应程序设计等级所需要的经验。每个程序员都有自己独特的技巧和经验，上述提法并不意味着很有天分和经验的程序员会因为工作年限不够而受到压制。最后，评价程序员不能看他们在入职时能带来什么，而要看他们在入职后能产出什么。
根据Ron和Mickey的经验，最优秀的程序员往往并不是最有经验的，也不是薪酬最高的。希望大家不要把这种情况看成一个问题，而要将其视为一种机会——用更高的薪水或更好的特殊待遇对出类拔萃的程序员进行奖励的机会。一旦有了程序员等级，这样的奖励将会更加恰当。我们为明显很优秀的程序员争取奖励时极少会遭遇来自高级管理层的阻力，不过这样做也会影响对表现欠佳的程序员的处理。
表2-2展示了前面讨论过的不同程序员类型，应当如何安排程序设计等级。
表2-2 程序设计等级指南
| 客户端程序员 | 系统程序员 | 数据库程序员 |
|---|---|---|
| 程序员3 | 系统程序员3 | 数据库开发人员3 |
| 程序员2 | 系统程序员2 | 数据库开发人员2 |
| 程序员1 | 系统程序员1 | 数据库开发人员1 |
| 高级程序员2 | 高级系统程序员2 | 高级数据库开发人员2 |
| 高级程序员1/架构师 | 高级系统程序员1/架构师 | 高级数据库开发人员1/架构师 |
制定一组能够与程序员的成长相适应的、要求逐步提高的程序设计等级评判标准是非常重要的。表2-3给出了针对客户端程序员的等级评判标准。本书最后的“工具”部分提供了一份完整的等级系统示例，读者可在修改后应用于自己所在的组织。
表2-3 客户端程序员：等级标准
| 程序员3（入门级） |
|---|
| 了解Windows、Mac或Linux |
| 对良好的编码实践有初步的认识 |
| 了解因特网技术/对因特网技术有兴趣 |
| 了解数据库技术/对数据库技术有兴趣 |
| 了解C/C++ |
| 适应团队工作，能根据指导完成工作 |
| 能够配合领导制订工作计划 |
| 程序员2（有一些经验） |
| 开发过一个或多个商业应用软件 |
| 熟悉Windows、Mac或Linux |
| 有良好的编码实践经验 |
| 熟悉因特网技术 |
| 熟悉数据库技术 |
| 有扎实的C/C++功底 |
| 能够自我激励，能根据指导完成工作 |
| 能够独立制订工作计划 |
| 程序员1（有经验） |
| 开发过两个或更多个商业应用软件 |
| 熟悉两种平台 |
| 熟悉因特网技术 |
| 熟悉数据库技术 |
| 精通C/C++ |
| 有良好的沟通能力 |
| 能够自我激励，需要的指导很少 |
| 有良好的项目规划和工期预估能力 |
| 能发现问题并协助团队进行调整 |
| 高级程序员2 |
| 开发过两个或更多个商业应用软件 |
| 熟悉两种平台 |
| 理解跨平台的问题 |
| 熟知因特网技术 |
| 熟知数据库技术 |
| 深刻掌握C/C++ |
| 具有良好的沟通能力 |
| 能够自我激励，需要的指导很少 |
| 有优秀的分析、项目规划和工期预估能力 |
| 能够密切关注形势的变化，并制订调整计划 |
| 高级程序员1 |
| 开发过两个或更多个复杂的商业应用软件或技术 |
| 透彻理解两种平台 |
| 理解跨平台的问题 |
| 拥有精湛的因特网技术知识 |
| 深刻理解数据库技术 |
| C/C++专家 |
| 软件设计实践专家 |
| 沟通能力强，业界关系广泛 |
| 能够自我激励，独立工作 |
| 有优秀的分析、项目规划和工期预估能力 |
| 提出、改进并推广新的思想 |
| 密切关注形势的变化，并制订调整计划 |
当然，对于这个程序设计等级的描述来说，你真正想要的是每种职位的详细职位描述。程序员以崇尚自由和轻视正式文件而闻名，但根据我们的经验，程序员也非常希望获得职位描述，非常希望清晰地了解所在组织的晋升之道。尽管也存在一些例外，但绝大多数程序员在有了这套体制，并清晰地知道你和组织中的其他管理层对其所处等级的看法之后，会干得更好。
制订详细的职位描述是一项非常艰巨的任务。在过去的15年中，Mickey探索出了一组能反映前述程序设计等级的结构化的职位描述。图2-1以程序员3为例，给出了这些职位描述的基本格式。
图2-1 职位描述示例
如该例所示，职位描述包含以下三部分内容：
- 基本信息，包括头衔、部门、直接领导、状态、工作地点；
- 职位概述，包括工作职责和预期表现；
- 岗位最低要求。
这一格式稍作改动之后，几乎可用于任何职位描述。但我们建议大家不要只写一份职位描述，而要多写几组，以体现不同工作的能力要求。根据我们的经验，写一组职位描述所需要的时间比只写一份职位描述多不了多少。如果每个职位都有一组职位描述，就能很容易地回答职业发展和晋升方面的问题了。前期多花几分钟，后期能节省好多个小时的时间。这样做的话，你不仅会成为HR部门眼中的英雄人物，还能获得一件有助于管理程序设计团队的优秀工具。
本书最后的“工具”部分提供了一些职位描述的示例，你可以根据所在组织、部门和职位的具体需求加以修改使用。
5 工作地点与关系
近年来，软件开发管理的复杂度比以前大了很多。也许你很幸运，仍然保持在简单的环境中，但这样的日子很快就不会再有了。即使现在不受影响，早晚都会受到影响的；否则，你的企业将不再具备竞争力。
以前，听到的问题都是：“去哪里找一个程序员来做项目？”后来逐渐开始思考是招聘现场全职雇员还是招聘合同工的问题。现在，在哪里完成工作、怎样完成工作往往涉及大量的决策，需要仔细考虑。
通常，这些决策不由你来做出，它们可能是由你的领导或者项目情况而定的。无论如何，要想取得成功，必须解决好工作地点和工作关系的多样性问题。
管理中可能涉及的程序员工作地点与工作关系的情况有以下5种：
- 内部雇员（in-house employees）；
- 远程雇员（geographically distant employees）；
- 合同工（contractors）；
- 合同管理团队（contracted managed teams）；
- 外包公司（outsourcing companies）。
可以将这些类型的关系视为一组“约束关系”，排序的依据就是相应的约束程度。约束力度越大（对内部雇员的约束力度最大），你对程序员工作的控制力和能见度就越强；约束力度越小（对外包公司的约束力度最小），所需做的间接管理工作就越多，通常只能通过规格说明和交付成果进行的，而无法直接管理人员。
5.1 内部雇员
本章已讨论过的大多数工具都是为内部雇员设计的。招聘内部雇员意味着你和你的公司为了使雇员好好干活，除了支付报酬之外，还要明确承诺提供一系列经过商定的额外待遇以及专属的工作环境。这是一种常见的合同。
但合同中还包含许多隐含的假定，至少根据我们的经验是这样。内部雇员希望能干一番事业，而不仅仅是打一份工。因此，你还必须考虑为他们提供：
- 专业技能的提升和职业的成长，以及能够对此产生促进作用的机会；
- 定期的反馈；
- 就公司新闻和大事的交流；
- 有待发现的、几乎无穷无尽的其他需求。
不过，如果你能和内部雇员建立起密切的关系，就可以大大减少有效管理所需的沟通。
5.2 远程雇员
从根本上讲，远程雇员的管理方法与内部雇员的管理方法是一样的。你仍然要满足他们的众多需求，他们也仍然要好好干活。但管理这种不常见面或定期碰头的雇员时，传达指示和沟通交流都会更麻烦。
Evans & Sutherland（E&S）的创始人，曾告诉Mickey一种如何有效判断沟通难度的方法：
沟通的效果，在国内，是距离平方的倒数，跨越了国界，就是距离的立方的倒数。
——David C. Evans
根据我们的经验，这条经验法则很正确。我们见过太多因为对方不在身边而沟通失败的例子了。距离越远（楼下、相邻的楼中、相邻的时区、世界的另一端），沟通越困难。如果这种距离是跨国的，由于时差、语言和口音的挑战以及文化的障碍等影响极大，沟通受到的妨碍往往更大。
因此，当你准备招聘一名远程雇员（或者有雇员即将迁居其他州或国家，而你打算留用他）时，一定要了解为了保证足够的沟通，所需要做出的努力。即使你已经预料到远程管理很难，但实际的难度可能会超出你的想象。
远程雇员的另一个问题是，他们所能从事的项目类型几乎肯定是受限制的。也许你的公司或组织能提供很多项目供远程程序员独立工作，但大多数公司都不是这样的情况。只有很特别的程序员才能超越时空的束缚，与远程的团队紧密协作并获得高效的产出。在招聘远程雇员之前，请确保他是这种特别的程序员，或者你有足够多的、很大程度上可由他独立完成的项目。
5.3 合同工
决定雇用合同工而不是全职雇员，不能随随便拍板，通常需要视具体情况而定。如果某项任务工作量很有限，或者全职雇员全都没有时间来完成，那么雇一名合同工是不错的决定。
根据定义，合同工是以获取报酬为目的而帮你干活的“枪手”。合同工不应有隐含的需求。开工前，所有的需求都必须在合同中阐明。
在我们讨论的各种关系中，公司与合同工的这种关系一般是最简单的，简单的原因在于，它可以随时终止，而不需要任何理由或提醒。但这并不是说这种关系不可能变得复杂。如果变得复杂了，毫无疑问是你的过失。你应当制定规则并适时做出决策。
那这种简单的关系怎么会变得复杂呢？通常是由于你并没有按照合同工的经典定义，找合同工做某项具体的工作。很多时候，你想要找的是全职雇员，但暂时找不到合适的或者不确定已找到的人是否合适，于是，你就先招了一个合同工，但却将其视为全职雇员来对待，这就会导致合同工也有了类似于全职雇员的隐含需求，而这些需求有时经过诉讼会得到法庭的支持。因此，在我们担任过经理的公司中，人力资源部门和法律部门都明确要求程序设计经理不得为合同工提供额外的福利（衬衫或者外部的团队活动）。
所以，请特别留心你为合同工设定的需求和待遇。要将他们视为拿报酬的枪手来对待，不要因为他们的待遇不同于全职雇员而不安。他们不是雇员。
5.4 合同管理团队和外包公司
我们认为一线的程序设计经理不应当接受管理外包关系的任务，因此外包团队和公司的管理问题本书不拟讨论。外包管理需要专门的技巧和格外的小心。当项目的某一部分可能需要外包时，只有在你能得到具有这方面管理经验的人士的帮助与支持的情况下，才可以选择接受外包。否则，接受外包会连累身为程序设计经理的你。
管理外包资源本身就是一份需要全身心投入的工作，第5章将讨论从海外合同工那里获得价值的挑战。
6 代系特点
在工程师和程序员中，代系差异是一直存在的，而今这些差异已经对职场产生显著的影响。当前，团队的成功必须依赖三代程序员的通力协作，而这三代人的价值观、想法和驱动力都不同。
为了把工作做好，我们不仅需要了解自己的工作风格，还要掌握手下员工的工作风格。一种常见的办法是从代系的角度来看待他们，但问题在于人们对代系的划分还未达成广泛的共识。传统上是按出生时间来区分的：
- 婴儿潮一代（1946～1964年出生）；
- X一代（1965～1979年出生）；
- 千禧一代（1980～2000年出生），有时也称为Y一代、婴儿潮二代、次世代或者网络一代。
但用这种分法来考虑代系差异并不完全合理。一个人的“真实”年龄不仅取决于出生时间，还取决于其个人思想。我们都见过那些行为与年龄严重不符的人，有的“少年老成”，有的则“过于天真”。因此，简单地基于出生时间来对待人是很危险的。
当然，不管实际年龄如何，同一代系内的成员之间总有着一些共同的特性和价值观。表2-4给出了一些对代系成员进行分类的方法。
表2-4 代系差异
| 代系* | 婴儿潮前期 | 婴儿潮后期 | X一代 | 千禧一代 |
|---|---|---|---|---|
| 出生年份 | 1945～1955 | 1956～1965 | 1966～1985 | 1986～2005 |
| 音乐 | 黑胶唱片 | 盒式磁带 | CD | iPod/Pandora |
| 大众传媒 | AM广播、广播电视、报纸 | FM广播、有线电视、报纸 | 有线电视、网站 | 网站、Facebook、Twitter |
| 技术† | 模拟（如电吉他）、电话、美国邮件 | 个人电脑、传真、电子邮件 | 因特网、电子邮件、文本消息 | 移动技术、文本消息、Facebook、Twitter |
| 特点† | 愿意使用技术，但通常只与家庭成员及朋友联系 | 适应因特网、社会媒体和移动技术；喜欢技术但很少会狂热于技术 | 热衷于那些能增强自身独立性的技术，以及能改善生活的数码产品 | 移动技术是他们的典型特点：发短信、出行时匆忙地制订聚会计划、把身份信息装在手机中随身携带 |
| 核心价值观§ | 不随大流，追求基于个人价值和精神发展的完美生活方式 | 喜欢团队工作，具有稳定的工作，对公司忠诚 | 在经济和心理上拥有“幸存者”心态；敢于质疑权威，不轻易作出承诺；有志向，有主见；努力在工作、家庭和个人生活之间寻求平衡 | 在对美德和价值的追求中逐渐成熟，容易被任务目标较高的组织所吸引。技术悟性高、态度积极、敢闯敢拼，用一句话概括就是“希望能在岗位上有所作为” |
* 代系的定义划分有很多种，并且相互之间都不兼容。本书使用的代系划分是整理并结合了那些最有用的且和本章讨论的话题最一致的划分定义。
† Charles S. Golvin et al., The State of Consumers and Technology: Benchmark 2009, US (Forrester Research, 2009).
§ Dan King, “Defining a Generation: Tips for Uniting Our Multi-Generational Workforce,” www.careerfirm.com/generations.htm.
从表2-4可以看出，这些不同代系的程序员在个人成长过程中所受的影响是截然不同的。更重要的是，他们相互迥异的核心价值观导致在职场上表现各不相同。
- 婴儿潮一代乐观而忠诚，希望拥有稳定的事业。他们当中许多人都是工作狂，希望能超额完成任务以促进公司及个人事业的发展。
- X一代有点愤青，他们很自立，更看重个人的自由发展而不是对公司的忠诚。他们认为时间是一种自己不愿意分享或放弃的商品。
- 千禧一代具有个人主义倾向，但也有集体观念。他们有志向，有自信，兼具乐观、坚韧和无畏的特质，且这种特质在“9·11”事件引发的民族团结中得到了强化。与X一代类似，千禧一代也将时间看作是一种自己不愿意分享或放弃的商品—他们认为工作是两个周末之间的事情。
不难看出，如果在办公室里大家必须均摊工作，那么这种不和谐的核心价值观会造成严重后果。要想成为一名成功的管理者，一个重要的前提就是，能针对这些不同代系的程序员制定个性化的管理方法。
7 个性特点
程序员除了具有不同的类型之外，还普遍存在着个性特点、特质和习惯，这些因素各自都面临着一些挑战。
学术界有着许多关于个性、如何对个人进行分类以及如何管理个性的理论。在这些理论中，迈尔斯和布里格斯的工作值得花一些时间来理解，他们俩在1942～1962年间建立了个性测试的理论基础，并提出了对个性进行分类的体系。迈尔斯-布里格斯类型指标（Myers-Briggs Type Indicator，MBTI）个性清单的作用是，使C. G. Jung描述的心理类型理论易于理解，在生活中更实用。他们的工作在1984年出版的《请理解我》（Please Understand Me）一书中得到了推广，该书以一种易于理解的形式介绍了迈尔斯-布里格斯方法。
Jung最初描述的类型是外向（extroversion，E）/内向（introversion，I）、感觉（sensation，S）/直觉（intuition，N）、思考（thinking，T）/感觉（feeling，F）和感知（perceiving，P）/判断（judging，J）。值得注意的是，研究表明相当一部分程序员属于INTJ（内向/直觉/思维/判断）类型，Mickey和Ron也都具有这一个性特点。
这本书中有许多值得学习的地方，尤其是在人际关系方面。然而，用这种公式化的方法来应对多样化的技术个性特点是充满危险的，我们也没有发现它在团队管理方面特别有用。我们建议你避开公式化的个性分类，而把精力放在已知个性特点的管理方面。
根据自身的经验，我们给出了一些你在管理程序员时可能会碰到的个性特点类型。这个清单并不详尽，但我们基本上解释了你可能会管理到的不同个性类型，并给出了一些辨别方面的建议。
7.1 左脑型的人与右脑型的人
右脑理论与左脑理论源于Roger W. Sperry的工作，他的研究表明，大脑的左半球和右半球具有针对不同任务的专门功能。左脑通常专用于分析任务和语言表达任务。左脑的表达能力比右脑强得多，而右脑主要用于空间感知任务、音乐等。
如果你是一名程序员或者技术人员，你很可能属于“左脑型”，这意味着语言、逻辑和分析使用得更多，也更客观。其实称为“左脑为主型”更恰当，因为我们只有一个大脑，两个半球始终是同时工作的。因此，你既可以是“左脑型”的人，又可以具有非语言交流、直觉、想象力较多且更主观等强烈的“右脑型”倾向——这些倾向通常更多地与音乐家、作家、艺术家等创新型人才相关联。
对于一名优秀的程序员来说，强大的左脑分析能力是必不可少的。不过，与右脑相关的活动往往也同样重要，这是因为程序设计是一门很有创意的艺术（如第1章讨论的那样，更像是写小说）。事实上，我们（和其他人一样）发现，一些最顶尖的程序员同时也是音乐家。Mickey在大学一年级刚接触程序设计时就是一名专职音乐家。“我刚开始做程序设计时，就对媒体很有兴趣，那时我已经是一名音乐家了。音乐理论都是基于数学的，长时间的练习需要专注和纪律。我发现演奏和/或作曲时的创造性部分与设计并实现程序时的创造性部分非常相似。令人惊讶的是，甚至程序调试也在某些方面类似于歌曲的演奏学习——你需要一遍又一遍地演奏歌曲中的某一部分直至完全正确，这就如同反复运行程序直到能够正确运行一样。我甚至发现自己在做程序设计的时候完全没有时间概念，这与我练吉他的情形非常相似。从那时起，尽管我还在继续演奏音乐、作曲和作词，但程序设计已变成了我的主要创新活动。”
在我们认识的众多程序员中，这样的故事并不是唯一的。事实上，音乐已经成了对有希望的候选人进行第一次面试时的常见问题。如果候选人是音乐家，那么讨论他们喜欢什么样的音乐、演奏什么样的音乐、音乐理论以及音乐在他们生活中的地位，不但可以展现深刻的见解，而且有助于使他们在面试的开始阶段保持放松。成为音乐家不是成为优秀程序员的必要条件，但我们也从来不将其视为成为优秀程序员的障碍！
7.2 夜晚型的人与白天型的人
多数企业中的多数雇员属于白天型的人，与他们不同，多数程序员属于夜晚型的人。他们往往在正常上班时间过了好久之后才到单位，并且工作到下班以后很久，当关键性的项目或者自己感兴趣的项目进展到中途时常常能工作到深夜。一般说来，如果你关注的是结果，而这些起床很晚的人能给出符合或者超出你预期的结果，那就不是什么问题。然而，沟通经常是个问题；也就是说，他们需要出席会议并交流信息。
在《编程之道》（The Tao of Programming）中，Geoffrey James提到：
经理走到程序员们跟前说：“关于工作时间：你们必须上午9点到，下午5点走。”听到这里，所有的程序员都很生气，有几个当场就提出辞职。
于是经理说到：“好吧，只要你们能按计划完成项目，可以自己安排工作时间。”程序员们这才感到满意，从此每天中午来上班，一直干到第二天凌晨。
为了避免这样的问题，我们强烈建议你别要求夜晚型的人早上9点就到。我们的建议是，你设定一些希望所有人都遵守的“核心时间”，以确保整个团队之中能有最低限度的合理沟通**。商定核心时间可以帮每个人节省大量的时间，且易于避免苦闷。注意，隔一段时间就要重申一下核心时间，因为程序员会感觉到日程的变化，他们对核心时间的遵守会渐渐不那么严格。
还有一个问题需要解决，那就是公司其他部门对你的团队的看法。在我们俩工作过的每个企业，我们都听到过“你的手下直到中午才来上班”这样的批评。针对这样的话，你需要主动突出强调你的团队投入了多少时间，他们写完并提交代码的时间有多晚。确保把那些最有名的夜猫子挑出来，让大家都看到他们按自己的工作习惯所做出的业绩。这一切都要主动去做，不要等到出现批评之后才着手。
7.3 “牧童”与“农民”
大多数程序员倾向于当“牧童”而不是当“农民”。也就是说，当问题出现时，他们的第一反应是“跳上马离开”去独自解决问题。他们常常跳过规划，最终得到一次性的解决方案。实际上，可以在标准、实践和团队之间取得更好的平衡。
我们希望软件开发更像种地。农民会有条不紊地了解地形、研究土地的化学组成、种植、浇水、除草，最后收获。可靠、可扩展、可维护的软件就是这样有条不紊地开发出来的。
因此，识别出牧童，并确保他们受到限制而不能快速冲出去是很关键的。这样开发出来的解决方案最终才能用于解决其他问题。
很多程序员都有牧童倾向，因此更高的要求是营造以下的软件开发文化：禁止牧童行为，所有的主要项目都遵循系统的软件开发生命周期。
不过，有时候，你还真的想要一个“牧童”而不是想要一个“农民”，这些时候需要做的通常是小型的、一个程序员就能完成的概念验证项目或者原型项目。我们发现，如果身边有一个能解决这种问题的“枪手”，对他对你都很有利。把你的需求和程序员的基本个性匹配起来，双方都会更开心，结果也会更好。
许多“牧童”都是优秀的程序员，但你必须小心地对他们进行管理，以获得想要的结果。他们有着当主角和引起纷争的倾向，所以务必对他们保持密切关注，一旦出现问题要马上采取措施。
只能当“牧童”的程序员通常都不会在企业待太久。要么是你对他们总是自顾自地向前冲感到厌烦而辞退他们，要么是他们对长期受限制感到厌烦而主动辞职。
7.4 英雄
英雄指的是承担需要超人的努力才能完成的任务，并最终取得成功的人。在付出超人的努力方面，英雄与牧童是相似的。但英雄能够在团队工作和开发过程中获得成果。英雄是培养出来的，通常会在企业中崛起为超级明星。
管理英雄的挑战是：如果你总是期望他们付出超人的努力，很容易就毁了他们。偶尔期望一下是可以的，总是这样期望就不行了。认真关注他们的福利，把他们选择性地用于重要的举措或者关键的项目。
Mickey和Ron在从事程序设计工作的时候，常常承担难度较大的项目，并（在熬了若干通宵或者进行马拉松式的工作之后）出乎意料地完成任务。这对我们工作过的公司是很有益处的：为Kenway和E&S实现了关键产品的发布；完成了里程碑式的苹果电脑产品演示，这对于苹果当时最新的计算机生产线是很关键的；为我们的公司储备了专利技术；为了客户和公司的利益，不断挑战我们自身的极限和已知的技术极限。在我们成为经理之后，这样的经历对于判定选择性的超人努力与毁灭性的用人方式之间的界限是非常有用的。
7.5 内向的人
你的一些职员非常沉默、非常内敛，几乎感觉不到他们的存在。他们可以把工作完成得很出色，但是对团队动力或在会议上几乎没什么贡献。他们在一对一的时候能进行交流，但退回到人群里以后就几乎消失了。
在会议上让他们发言时，当他们分享自己的意见或见解时，要给予正面的支持，这样可以逐步帮助他们建立自信——自己对团队是有贡献的。找机会跟他们交谈，当面认可他们的贡献。与他们的交流要一个一个地进行。通过一些小事情与他们建立特殊的联系，比如分享经验或者一本书。总之，想方设法建立更紧密的联系。
Mickey想起了Brøderbund公司的一名内向的技术作家。Mickey与这名作家是通过角色扮演游戏建立联系的。Mickey的鼓励促使他进入了游戏设计领域，最终成为了Brøderbund的游戏设计经理，后来又在其他一些公司担任小有名气的出版作家和游戏设计师。
多年来，这一联系以及其他一些类似的联系对我们俩来说也是一种回报，因为我们亲眼看到了谦虚的人经过我们的鼓励之后有所成长，并展现了自己的才华。
7.6 愤世嫉俗的人
尽量避免雇用心存极大愤懑的人。他们会通过挑拨离间和散布不满情绪来毒害整个开发团队，并对组织造成严重的破坏。如果没有他们，那些情绪可能永远不会出现。
愤世嫉俗的问题在于它是植根于现实的，但在组织内部的影响极大、极深。例如，“管理层不在乎程序员”可能是真的。但即便实际情况并非如此，愤世嫉俗的人们也会抓住每个机会来强调这句话的真实性。他们会把每一次非故意的怠慢（如办公室冰箱中饮料的变化）说成是“管理层用来惩罚程序设计人员的密谋”。用最客气的话说，这样的言论是公然藐视真理和道德的。你甚至发现自己根本无法度假，如果不希望回来时发现自己的团队处于混乱、脱轨甚至“造反”状态的话。
7.7 奇葩
有些人只不过是奇葩（jerk）。他们粗鲁、刻薄、中毒不浅。当然，他们或许也有些可取之处。他们可能是很有才华、很有技术天赋的优秀程序员。但才华并不能匹配你雇用他们所需要付出的代价。离他们很近正是问题所在。
遵循“不招收奇葩”的法则。根据我们的经验判断，如果你不这样做一定会后悔的。最好将该法则扩展到愤世嫉俗之人和傻瓜。你的职员会对此很赞赏，你的工作也会轻松很多。
第5章和第7章还会详细谈论愤世嫉俗的人、笨蛋和奇葩。
8 小结
本章的目的是帮助大家认识到，理解程序员并不是一项简单的任务，即使你当过程序员也不例外。我们提供的多种视角，只能帮助你找到最适合你的方法来管理那些必须雇用的程序员。管理人是很困难的，有些最有天赋的程序员同时也是最难管理的人。这是一把“双刃剑”。
我们列出了多种个性类型供大家了解，但强烈建议大家不要简单地按这些类型对人进行分类。把每个人都作为不同的个体看待，你这位程序设计经理会更成功。
9 工具
我们为团队管理提供了许多辅助工具。电子表格和Word文档提供了完整的示例，稍作修改即可用于你自己的组织。全书最后的“工具”部分给出了工具网站的链接，在那里可以下载下列工具：
- 程序员级别样例；
- 各程序员级别的职位描述样例；
- 独立合同工协议样例；
- 角色和排名系统。
本文来自已上市的《告别失控 软件开发团队管理必读》
软件开发常常难以管理。新闻中充斥着各种项目计划拖延与预算超支的悲剧故事。虽然在开发过程中引入一些正式的规范状况能得到改善，但没有哪种手段完全解决了问题。投入了这么多时间和资金来加强对软件开发的控制，为何仍然如此难以控制？
在本书中，Mickey W. Mantle和Ron Lichty通过一个简单的观察发现回答了这个困扰已久的问题：首先必须让程序员和软件团队变得可控。也就是说，你需要先理解你的员工——如何招聘、激励他们，并带领他们开发和交付杰出的产品。Mantle和Lichty总结了他们合起来超过70年的软件开发管理经验，并结合其他成功管理者的洞见和智慧，为需要为了成功交付软件来管理员工与团队的你提供了充分的指导。
不论你是软件管理新手还是老手，还是已经有多年经验，都会欣赏本书中丰富的实用知识和实践工具。
推荐这本书的理由：
“Lichty和Mantle为我们聘用、激励和领导顶尖的软件开发团队编撰了指南。他们的经验法则和指导性建议所构成的宏伟蓝图对软件工程经理中的新手与老手都适用。”——Tom Conrad，Pandora公司首席技术官
“真希望自己能在多年前就拥有这本书。我从书中看到了很多有价值的内容，为了成为更优秀的管理者，我将会一次又一次地用到这些内容。书的写作风格很好，个人轶事我也很喜欢。”——Steve Johnson，DigitalFish公司用户解决方案副总裁
“如果你真心打算建立可持续发展的软件团队，使其始终能够交付符合预期的高质量解决方案，那么这是一本必备的参考书。针对世界各地的软件管理者常面临的实际问题，书中给出了许多非常实用的建议和技巧。本书综合运用了经过实践检验的方法和对软件团队成员个性与背景的敏锐理解，如剥洋葱皮般把管理软件开发者（不管是位于同一地点的一小撮程序员，还是分散在世界各地的数以千计的程序员）的过程层层剥开，使我们无需“为剥皮流泪”。最后，这是一本软件工程类的书，致力于帮助管理者解决如何使程序员团队高效地协同工作这一难题。软件管理者应当人手一本。”——Phac Le Tuan，Reepeet首席技术官，PaceWorks首席执行官
“要想成为杰出的工程领导者，仅仅知道技术细节是不够的。Ron和Mickey提供了一本实用手册，展现了工程领导力重要的柔性一面，适用于任何软件开发组织。”——Paul Melmon，NICE Systems工程副总裁
“这是一本极好的书。结构合理、逻辑清晰，含有丰富的亲身体验和许多精辟见解。你们俩干得非常出色，在理论与实践之间达成了一个极好的平衡，信息量很丰富。”——Joe Kleinschmidt，Leverage Software首席技术官兼联合创始人
“在阅读至理名言那一部分时，只看了不到4页纸的内容，我的认识就有了提高。这些至理名言最令我触动的地方在于，我能感受到本书的起源：两位技艺精湛的大师互相从对方身上学习。大多数书籍给我的感觉是老师在枯燥地讲述‘应该怎么做’，但读完仍然存有‘这在“现实生活”中是否有效？’的疑问。而阅读本书中的至理名言时，给我的感觉是，在从一位值得信赖的导师那里获取指导：这位导师不仅是我所信赖的，而且他还相信我能够掌握这些哲理、理解其局限性并正确地加以运用。这部分侧重的是技术管理智慧，就像这一领域的《读者文摘》一样。”——Mike Fauzy，1stMediCall有限责任公司总裁兼首席执行官
“本书为软件经理提供了许多有价值的指导，有些是显而易见的，有些则不是那么明显。真希望自己能在刚开始管理团队时就拥有这本书，当然现在它对我来说仍然很有启发性。对于转向管理岗位的程序员来说，最大的困难是学习软技能。Ron和Mickey的这本书非常值得推荐，它不仅指出了行动的理由，还给出了行动的方案。”——Bill Hofmann，Klamr.to工程副总裁
“围绕软件开发中人的因素而展开的独特对话，有点相见恨晚的感觉。”——Mark Friedman，GreenAxle Solutions首席执行官兼创始人
“……书中关于新员工上班第一天该做的事情看起来很独特，非常有用！”——Steven Flannes，博士，Flannes & Associates负责人
“本书提供了针对程序员这一特殊人群的深刻见解。全球的公司都在探索如何最优地开发出软件产品。对程序员的管理是成功开发软件产品的核心。总体来说，许多项目和组织的领导者都不擅长管理程序员和软件开发。我认为这本书能够使软件组织的领导者们耳目一新，可以帮助他们理解甚至深入了解程序员，从而成为更有成效的领导者。”——Michael Maitland，WhereTheGeeksRoam首席执行官（主管极客）
“阅读本书令我非常享受，真希望10年前就能拥有这本书——这样我很可能会少犯一些错误。书中的很多内容于我来说已不是初见，但把如此之多的相关内容集成在同一本书中却是我前所未见的。这就是我想要的书，我觉得自己已经从中受益了。”——David Vydra，持续交付的倡导者、TestDriven.com的软件匠人
“我现在读这本书仍然很受益——尽管我已经从事了几十年的管理工作，但它仍然能提升我对员工的敏感度。”——Margo Kannenberg，HighWire出版社应用开发助理总监
“在我初次担任程序设计经理时，Mickey 是我的上司。他手把手的务实指导对我的管理工作有着深远的影响。如今，我在培养和指导管理人员方面遇到难题时，仍然会向他‘取经’。很高兴他能抽空把自己的宝贵经验整理成书，这样就有更多的新老管理人员能从中受益了。”——H. B. Siegel，IMDB.com（Amazon的全资子公司）首席技术官
“真希望5年前刚当上经理时就能拥有这本书！”——Kinnar Vora，Sequoia Retail Systems产品开发与运营副总裁
“Mantle和Lichty透彻地阐明了抽象的原理，为提高软件开发组织的有效性提供了经过验证的方法。每一个希望建立优秀开发团队、创造人人乐在其中的办公文化的软件经理，都应该在真实的（或虚拟的）书架上放上这本书。本书的价值尤其体现在它能告诉管理人员不应该做哪些事，以及如何处理所有组织都不可避免会遇到的问题。”——Anthony I. (Tony) Wasserman，卡内基·梅隆大学硅谷校区软件管理实践教授，ACM会士，IEEE终身会士
“20世纪70年代中期，Mickey在长岛工作，当时的团队是Pixar的前身，他在那里做出了许多成功的软件产品。近20年后，他作为Pixar的管理人员，带领团队取得了一个又一个的胜利。他知道自己在说什么。”——Alvy Ray Smith，Pixar联合创始人
“Ron和Mickey清楚地知道从事有影响的项目对程序员的重要性，以及创建并培育独特的创新文化对管理人员的必要性。”——Kathy Baldanza，Perforce Software工程副总裁
“本书汇集了大量宝贵的实践经验，可以使你成为更高效的软件开发经理。”——Chris Richardson，原CloudFoundry.com的创始人，POJOs in Action的作者