程序员为何难以管理？_【人邮IT书坊】

程序设计作为一种严肃的职业已经存在60多年了。在美国，从事程序设计工作的程序员数以百万计，而全球这个数字更大...

程序设计作为一种严肃的职业已经存在60多年了。在美国，从事程序设计工作的程序员数以百万计，而全球这个数字更大。这些数字还不包括人数众多的学生与编程爱好者，他们非常认真地编写程序，但并不以此为谋生之业。

尽管历史悠久，从业人数众多，但“软件工程师”却因难于管理而闻名。出现这种现象有以下几点原因。

第一，作为一种严肃的职业，程序设计不同于电气、土木工程等相关的工程职业。从 1968 年开始，人们将程序设计这门艺术称作软件工程（software engineering）。但是，与新建土木、电子工程这样的实践相比，从零开始编写新程序更像写小说。新程序的起始往往类似于一张白纸，而传统工程项目则通常是对各种组件库，按照严格的合格性准则进行组装。本书将使用程序设计（programming）一词来称呼“软件工程”，因为相对于严格定义的工程实践来说，程序设计更多的是一门技艺。

从零开始编写新程序更像写小说。

第二，任何人都可以成为程序员。不需要接受正式教育，也没有必需的证书标准或考试。只需要一份程序员的工作即可。

第三，受前两个原因的部分影响，尽管人们做过多种尝试来规范软件工程的流程（如CMMI 1～5级），但这些尝试的影响其实很小。多年来，由大量程序员继续开发的许多软件并不遵循这样的规范框架。而且即便遵循时，也只是对流程有所改进，却无法将程序设计转变为一个纯粹的工程实践。此外，规范化的框架只解决了编写软件的流程问题，但没有涉及程序员管理的问题。遵循流程对管理程序员的问题只能起到最低限度的帮助。程序设计经理们仍然只能依靠自己的方法工具来对下属程序员进行管理。

尽管有很多书籍、文章和网站涉及软件工程与软件开发流程管理，但关于如何有效管理程序员的例子却十分稀少。任何一个棒球队经理都会告诉你，棒球队技术细节的管理比球员个性的管理要容易得多，程序员的管理也是类似的情况。

从计算机出现的早期开始，程序员管理就是一个极具挑战的难题，如下面这段由第二次世界大战（WWII）期间成为世界上第一批程序员的Grace Hopper写于1961年的文字所述：

程序员是一个古怪的群体……他们崛起的速度很快，很快就形成了独立的职业，并且过早地感染了不愿做出改变的抗性。我曾经听说有些程序员因为客户不愿意修改自己的商业系统而斥责客户，而有时走进我的办公室说“但我一直是这么做的”的也正是这些人。出于这个原因，我在办公室悬挂了一个逆时针走动的时钟。

管理程序员的第一步是更好地了解他们。是什么吸引着数以百万计的人投身于“计算机程序设计艺术”呢？答案有时非常简单：它是一份收入优渥而　且可以整天待在办公室里上班的工作。然而很多程序员会告诉你，现实中的答案通常没有这么简单。给出那种简单回答的人，通常最终没有坚持程序员这个职业。

事实上，只有特定类型的人才能成为程序员，而只有非常特别的一类人才能成为杰出的程序员。要想知道怎么才能成为杰出的程序员，首先需要了解程序员都做什么。

1　程序员都做什么

首先，程序员的工作很有趣！Fred Brooks在软件工程的经典名著之一《人月神话》中很好地总结了程序设计充满乐趣的原因。

“第一，是纯粹的创造的愉悦……”
“第二，是做出对其他人有用的东西而带来的快乐……”
“第三，是设计组装谜题一样环环相扣的复杂部件，并观看着它们巧妙地运转而产生的吸引力……”
“第四，是持续学习的乐趣，这来源于任务的无重复特性……”
“第五，工作的对象是可以自由驾驭的代码，令人开心。程序员，像诗人一样，操作的是与纯粹思维事物只差一点点的代码”。

既然多数程序员都很享受工作，你就可以理解为什么难以管理他们了。如果有人付钱让你开心地玩，你还会愿意受制于人吗？受人管制就会减少工作中的乐趣！

这也能解释为什么程序员常常难以共事。在计算机出现之前，许多程序员可能会成为工程师、会计师或者教育工作者。我们这么多年来招聘的程序员中约有50%属于这种情况，另外的50%则比较难以归类，许多可能会成为艺术家、音乐家、作家等“右脑型”人才，他们本质上更加自由奔放。更令人惊讶的是，这类“右脑型”人群中产生的天才程序员更多。

此外，程序员的工作“与纯脑力劳动只有细微差别”的特点助长了自由散漫的工作作风，使得程序员几乎无法管理。设计与实现程序时，没有广泛使用严格、规范、全面的工具。往往程序员可以从一张白纸开始设计编写程序。

把这两类不同的程序员混合成一个团结、高效的软件开发团队，给管理工作带来了极大的挑战。管理工程师相对来说比管理艺术家、音乐家和作家要容易一些。如果没有外界的干扰，许多程序员在独自面对自己的设备时通常都会很投入地写代码，一边写一边设计。程序设计经理必须培养建立在可靠的开发实践基础上的软件开发文化，否则程序设计项目就可能失败。

尽管可以对程序员进行分类，但成功管理他们的关键却是要认识到他们是独立的个体。程序员之间的差异很大，你必须努力地让每个人的长处都得到发挥，同时尽力提高或者至少抵消每个人的短板。这条原则适用于任何领域的管理，不过在管理程序员时尤为重要。

即便有着良好的软件实践和开发过程，当项目产品本身难以捉摸的时候，你如何能够知道项目的进度？几乎在所有的软件中，程序的实际有形结果（即打印的报告、输出的数据甚或用户界面）与实际程序的完成状态都是不成正比的。Mickey在Evans & Sutherland公司工作期间，曾与一名杰出的系统程序员共事，这名程序员为一个非常复杂的设备驱动程序设计和编写所有的代码，但在几个月的开发期中，甚至都没有进行过一次完整的编译。再来看另一种极端情况：Ron到富士通公司之前的那3个月时间里，富士通公司的程序设计团队每周都会告诉领导，再等一周产品的功能就能完全实现。对于这两种情形，我们无法通过进度估计来预测项目成功完成的时间。如果程序能够给出我们想要的结果，但设计和/或实现都很糟糕，以致改进或维护完全不现实，那就更麻烦了。即便是资深的程序员也难以注意到程序中这些隐藏的或者无法预见的方面。

坦率地讲，许多（也许是大多数）程序员的工作是对已有的程序进行修改，而且这些程序多半是别人写的。即便程序是他们自己写的，恐怕也是半年之前的事情了，根据伊格尔森定律（Eagleson’s Law）：“自己写的代码如果有半年时间没有看过，就跟别人写的代码没啥区别了。”这句话的意思是，代码看起来会很混乱，难以理解，并且同样无法通过进度估计来预测项目成功完成的时间。

类似地，对许多管理者（尤其是CEO或CFO等技术性不那么强的管理者）来说，原型似乎已经是比较“完善的”产品了。软件难以捉摸的特性使得在企业内部判断其完成状态的难度更大，这与程序产生的结果是好是坏无关。程序设计经理必须能够借助于经验、工具以及深入的观察来把握程序的进度。

避免这些问题的最好办法是招聘杰出的程序员——那些能为计算机程序设计艺术带来纪律和方法的特殊程序员。这些杰出的程序员到底是艺术家、工程师还是匠师呢？

尽管现在对计算机程序设计艺术的讨论很多，但纯粹从字面上理解的话，很少有程序员认为自己是艺术家。

类似地，尽管软件工程是我们的目标，但从字面上讲，如今很少有程序员能称得上是软件工程师。尽管IEEE 提供了软件工程方面的规范认证项目，但根据我们的经验，这些认证程序不仅得不到大多数专业程序员的重视，而且知名度在学术圈和极少数公司之外也并不高。普通程序员在软件工程培训方面不会花费很多精力，甚至可以说没有这样的需求。

那么“匠师”这个说法怎么样呢？很多核心程序员认为，把程序员比喻为匠师更合适。匠师不是与生俱来的顶尖高手，他们需要当多年的学徒、多年的熟练工作，在证明自己的技能并获得业绩之后才能赢得顶尖高手的称号。用知识、经验和成功的过往业绩来认证程序员比较切合实际，而正规的认证程序则难以给出这样的认证。我们认为“匠师”这个比喻比其他称谓更适合我们所说的那种“杰出的程序员”。

杰出的程序员是如何产生的呢？仅仅具备程序设计方面的天赋是远远不够的。事实上，程序设计方面的天赋对杰出程序员的技能反而有副作用。杰出的程序员是大师级的人物，做事有条不紊、遵守纪律。他们能够凭直觉把代码和程序组织好，能够约束自己总是在编写代码之前进行设计，能够在最少的时间内编写出清晰、简洁、实用、高质量的代码并获得预期的结果。换言之，杰出的程序员是大师级的匠师。

如果程序员的动力主要来源于时间计划表、管理层压力或金钱，那他通常不会是一名杰出的程序员。对大多数杰出的程序员来说，动力事实上来源于更高的要求：在世界上产生影响，并且做出人们实际使用的程序或产品。杰出的程序员希望并且需要为具有世界影响的项目工作，他们希望能够感受到自己的工作是有意义的，哪怕只在某个很小的方面有意义。杰出的程序员偏爱能够满足他们更高要求的公司和项目，他们非常在意自己所做的事情，常常为了想要的结果而超限度地工作。

杰出程序员的工作效率往往比称职的普通程序员高一个数量级（即10倍以上）。

然而世上的杰出程序员实在太少了，不可能让每个项目团队都拥有杰出的程序员。而且多数团队也只能容忍队伍中有一两名杰出的程序员。我们发现大多数的程序或项目主要依靠的是普通程序员，而不是杰出程序员。普通程序员通常是称职的、专业的、能干的，但他们可能会把程序设计视为一种工作。

现在我们面临的挑战是：如何找到并雇用一个能干的程序员团队，如何激励并训练其中一部分人成为杰出的程序员，如何管理剩下的人使他们获得成功的结果，以及如何保证整个团队的持续进步，即使其中大部分或者所有的人都仅能算是称职的程序员。

2　成功的程序设计经理为什么难当

大多数杰出的程序员并不热衷于当其他程序员的经理。他们知道团队需要软件经理，但乐得让别人来做实际的管理工作。他们通常不喜欢管理人员或项目。

管理程序员是很难的！“管理程序员很像是在放牧一群猫”——这句话常被引述，它揭示了高效、成功的程序设计经理难当的本质原因。猫的自由主义、个人主义色彩浓厚，而且狡猾、贪玩、好奇、独立。程序员也一样。

根据我们的经验，非常能干的软件经理是很稀少的。而只有这类很少见的软件经理才能成功地管理无拘无束的程序员并且乐在其中。

因为程序员都是些无拘无束的人，常见的激励方法往往不能奏效。除了进行必要的技术监督并把开发实践和过程落实到位之外，善于利用程序员的自我意识和改变世界的欲望也很关键。这就需要一类既能理解程序员的工作方式，又能理解工作本身的软件经理，他们不仅能有效地激励程序员超常发挥，而且能按时交付结果。

对许多职业来说，报酬是主要的动力源泉；但对程序员来说，工作本身和工作环境的重要性要比报酬高得多。程序设计是一个创新的过程，需要有效地处理特殊情况。优秀的经理必须注意到这些情况，并营造有助于程序设计的工作氛围。

本书从头至尾一直在表达这样的观点：成为高效、成功的程序设计经理是可能的。但我们认为，一般只有优秀的或杰出的程序员才能成为成功的程序设计经理。

当然，这通常只是问题的一部分。大多数程序设计经理被提拔为经理就是因为他们曾经是优秀的或杰出的程序员并且表现出了一定的人际交往能力—在引导其他程序员的行为方面展现出了自己的能力甚至可以说是兴趣。

程序设计经理一般都没有接受过正规的管理培训，他们的管理经验通常来自工作和他人的指责。在这些菜鸟经理中，一部分人获得了成功，一部分人很快就失败了，多数人则是经过一段时间之后才宣告失败。

对获得成功的程序设计经理而言，在他们所在的组织或者圈子里面，一般都会有一位导师，引领他们取得成就，并且在他们犯错误的时候给予保护。我们担任程序员以及程序员经理的时间差不多有近40年了，这些年我们招聘、管理过数以千计的天才程序员并当过其中很多人的导师。我们希望本书能够提供导师所能给予的指导，能够为那些在程序员管理方面只能独自奋战的经理们担任代理导师。

本书的目的不是改变程序员，事实上也做不到这一点。他们仍然会在设计之前编写代码，仍然只在必要时才提供有形的结果。我们的目标是提供一些见解、建议、工具、方法以及经验法则来帮你“放牧”软件项目中的“猫”，并且帮你管理团队中看似难以管理的程序员。

本文摘自《告别失控：软件开发团队管理必读》，由人民邮电出版社异步社区出版，一本专为聘用、激励和领导顶尖软件开发团队撰写的管理指南，是两位作者加起来70多年的丰富从业经验的智慧结晶，充满软件研发管理、人员管理、团队管理方面的真知灼见。预计6月初上架。

点击【阅读原文】可进入样章试读