详情
这是一本系统阐述面对混乱而容易失控的技术开发团队时，如何管理、建设和强化团队，成功交付开发成果的大作。两位作者以合起来近70年的开发管理经验为基础，通过深刻的观察和分析，找到了软件开发管理的核心问题——人的管理，并围绕如何真正理解程序员、找到合适的程序员、与程序员沟通这几个核心话题，一步步展开，最终扩展到如何以人为本地进行团队建设、管理和项目管理。
书名：告别失控：软件开发团队管理必读
ISBN：978-7-115-41531-8
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 [美] Mickey W. Mantle Ron Lichty
译 赵普明 黄 倩 张维维 钱 昊
责任编辑 杨海玲
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
这是一本系统阐述面对混乱而容易失控的技术开发团队时，如何管理、建设和强化团队，成功交付开发成果的大作。两位作者Mickey W. Mantle和Ron Lichty以合起来近70年的开发管理经验为基础，通过深刻的观察和分析，找到了软件开发管理的核心问题——人的管理，并围绕如何真正理解程序员、找到合适的程序员、与程序员沟通这几个核心话题，一步步展开，最终扩展到如何以人为本地进行团队建设、管理和项目管理。
本书适合初级开发管理人员，可以说是一本从初级管理人员成长为高级管理人员的必备之书。同时，也适合有志于走向管理岗位的程序员、产品或其他技术公司员工。
Authorized translation from the English language edition, entitled Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, 9780321822031 by Mickey W. Mantle and Ron Lichty, published by Pearson Education, Inc., publishing as Addison-Wesley, Copyright © 2013 by Pearson Education, Inc.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.
CHINESE SIMPLIFIED language edition published by PEARSON EDUCATION ASIA LTD. and POSTS & TELECOM PRESS Copyright © 2016.
本书中文简体字版由Pearson Education Asia Ltd.授权人民邮电出版社独家出版。未经出版者书面许可，不得以任何方式复制或抄袭本书内容。
本书封面贴有Pearson Education（培生教育出版集团）激光防伪标签，无标签者不得销售。
版权所有，侵权必究。
“谨以此书献给所有的程序员，尤其是我领导过的程序员，他们做了很多实际工作但却鲜为人知。”
——Mickey
“献给我的孩子Jean和Mike，他们不仅为我提供了训练管理能力的绝佳机会，而且还是我思想、灵感和快乐的源泉。”
——Ron
“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的作者
团队管理的关键是人的管理。软件开发团队也是如此。甚至可以说，正因为软件开发的高度不可预测性，以及开发本身多样性的挑战，软件开发团队的管理，在各类工程行业中，一直跻身最难捉摸之列。
本人在软件开发行业摸爬滚打多年，一度自认为对技术团队的管理有一定理解。但拜读了Ron和Mickey两位技术管理前辈的呕心沥血之作后，才真正见识到什么叫“失控”（unmanageable），意识到什么叫技术管理。
本人曾经以为工程延期、bug丛生、沟通冗长、人心浮动这些现象只是我的个人经历，原因可能是个人管理能力或经验不足，也可能是中国的IT行业太年轻，难免各种混乱。看到本书中对美国IT行业的技术管理的各种描述后，我才明白，这些问题在全世界都是普遍现象，而且背后都是有着深刻原因的！并不是我们行业混乱，而是因为没像他们那么透彻地经历过、总结过、分析过、实践过。
一章章翻译的过程，也正是一个倾听、体会和学习的过程，读到了两位作者娓娓道来的亲身经历，以及诸多管理大师的灼思洞见，结合自身的经历，也能感觉到某种升华。本书并不像其他管理学书籍那样尝试阐述各种理论，而是脚踏实地地把日常管理中遇到的问题一一总结分析，并把作者多年来解决问题的实践措施，以生动的方式展示出来，配以实用的工具，让读者立刻就可以尝试并从中获益。本书是两位作者合起来近70年软件开发行业管理经验的心血总结。他们发现，软件开发管理中的各种问题，都可以通过对人的管理来解决。因此本书的内容都是围绕如何管理人而进行的。落实到软件开发，核心就是如何管理程序员。
欲管理人，必先了解人。程序员之所以难以管理，首先在于他们各种不同的个性。第1章和第2章详细描述了两位作者遇到过的各种类型的程序员，及其各种不同的性格，分析了其对软件开发的影响。了解了各类程序员的特点之后，便可以根据团队和项目的需求，寻找合适的程序员。第3章详细介绍了如何寻找和招聘合适的程序员。这一章内容尤其丰富实用，详细描述了从职位规划、职位描述、招聘预算、简历筛选、面试到后续跟踪等招聘的每一个步骤，并辅以实际经历的故事和详实的辅助工具。第4章介绍了新员工如何迅速融入新的工作环境。这里作者提到新员工入职流程中，开发团队可以做的多项准备，以及上手项目的设置，说得非常详细。译者个人感觉，这一方面国内的技术公司做得不够充分，很值得借鉴。
本书的第5章和第6章详细介绍了作为程序设计经理最重要的工作：管理。按照管理对象区分，分别讨论了向下管理（管理团队）、向上管理（管理领导）、向外管理（管理跨部门、跨公司的关系）以及自我管理的内容。第7章和第8章则进一步深化了管理的核心内容：向下管理。这两章分别深入讨论了团队管理的两个重要方面：激励和文化。这两方面在技术管理圈中往往没有得到足够的重视，很大程度上是因为技术管理人员大多从开发人员做起，所以对管理的人文因素了解不够。本书通过浅显易懂的分析，帮助读者迅速把握团队管理中最重要的因素，并提出了实际可行的方案。激励和文化的建设，也是团队建设和成长的途径。
最后，第9章综合前面对程序员的管理实践，最终落实到项目开发中。这一章对开发流程和程序设计经理在各阶段所应当行使的职责，以及如何获得最佳的效果进行了详细阐述，并辅以翔实的案例。最终，熟练掌握人员管理技巧的技术经理，参考本书的指导方案，将更容易带领团队成功地开发和交付优秀的软件。
另外，本书还总结了大量软件开发行业的真知灼见，并集成语录。配合各章的内容，将这些经验法则和名家之言融入自己的管理思维和管理用语中，可以更有效地进行管理。
详实的故事、示例，是本书的一大特色。本书的内容来源于两位作者多年的管理实践，所以每一个话题都配以他们个人的经历、故事，以及行动的细节，从而以生动的方式向读者展示了如何解决问题。通过这些故事和示例，可以感受、见识到很多关于管理的意料之外的知识。在本书中，可以看到苹果、Silicon Graphics等知名公司中的开发管理实践。
本书的另外一大特色，是在正文论述之外，配备了大量实用的管理工具文档，诸如招聘时的职位描述示例、面试事项清单、入职清单等。在每章的话题结束之后，都会总结使用到的工具，并可以在配合的网站上下载。这些管理工具都是作者实际工作中用到的，非常实用。
这是一本关于技术团队管理的实践之书，你可以把它当成一本故事集，也可以把它当成一套工作指南，甚至有的章节会让你想把书页撕下来直接使用。可以说，从软件工程师转变为技术管理者的人，一定可以从中看到自己成长的影子。
翻译这本书本身也让我深深感到了“失控”。本书由4位译者共同翻译，而由于个人工作生活的原因，本书拖延了很久才交稿，让编辑老师操碎了心，深表歉意。另外，尽管我已尽最大努力用心使译文准确、完善，但仍然难免有疏漏之处。读者若发现问题，欢迎发邮件指正。我的电子邮箱是：zhaopuming@gmail.com。
赵普明
2016年5月
软件开发常常被认为是难以管理的。进度安排和费用预算完全不靠谱的软件项目比比皆是。规范化的软件开发实践对这一状况有所改善，但也未能真正解决问题。我们软件开发行业已经积累了超过60年的技术经验，并已经投入了大量的时间，以及美元/日元/卢比/欧元来尝试把管理规范化，但为什么软件开发至今仍然如此难以管理呢？
本书用一个简单的观察结果来回答这个长期存在的问题：管理者首先必须学会管理程序员和软件团队的技巧。也就是说，必须学会了解员工—如何聘用他们，激励他们，进而领导他们开发并交付杰出的产品。本书基于我们自身的经验，以及我们所认识的几乎所有类型的软件行业的优秀管理者的经验，来为读者讲述如何开展软件开发的管理工作。如果把我们两位对各类软件程序和项目的开发与交付方面的经验加起来，都有70多年了，其中有超过55年的时间是在管理交付软件程序和软件项目的程序员和团队。希望本书能够帮助读者避免我们曾经犯过的许多错误，也希望我们学到的思想和技能能够帮助读者获得成功。
在我们职业生涯的初期，还都是程序员的时候，我们俩就都读过Fred Brooks写于1975年的《人月神话》（The Mythical Man-Month）一书。该书面世后很快就被程序员们奉为经典，其真知灼见直到今天仍有着重大意义，被认为是软件管理艺术方面的一部权威著作。与其他许多读者一样，我们最难忘的部分是Brooks的那些只有一行的至理名言，例如：“向进度落后的项目中增加人手，只会使进度更加落后。”在管理软件项目时，我们无数次地引用过这句名言。我们希望能够找到其他类似的令人难忘的经验法则，这也是写作本书的灵感和动力来源。
在我们俩成为富有经验的管理者后，作为朋友，我们开始定期碰面，讨论各自正在从事的工作以及软件开发中遇到的挑战性问题。我们发现彼此都能从对方那里获得帮助，时不时还能共同总结出一条至理名言或经验法则。我们把这些至理名言和经验法则带回到工作中，整合到管理方法中，并与团队分享。我们从阅读过的书籍和访问过的网站上收集法则和名言，但从未发现一组专门用于管理程序员和软件开发团队的法则或名言。出于对这组法则或名言的需要，我们最终决定撰写这本书。
当我们开始写作并与经理、总监、首席技术官们交流时，我们的眼界更加开阔了。显然，我们可以从自身的行业经验出发进行撰写，而不只是提供我们所收集的那些经验法则。我们还可以分享自己开发的工具，以及在创业公司和各种规模的组织中工作所获得的见解。
当然，有些领域是我们在职业生涯中没有触及的，如大规模政府订单和国防系统。但我们的经验适用于当前从事软件开发的大多数公司，包括那些致力于前沿创新的公司。在后面所说的这类公司中，管理人员往往比较年轻，普遍缺乏（或很少有时间接受）正规的管理培训和组织上的支持。遗憾的是，现在太多的管理者都是如此，都只能在工作中边做边学。
我们希望写一本能够为程序设计经理提供指导的书——一本富含见解、故事和指导的书，这些见解、故事和指导都是多年来我们在为获取成功而走过的艰辛历程中得来的。
我们觉得还可以在书中分享多年来自己开发过的一些工具，使管理变得更容易。这些工具包括职位描述、排名电子表格、项目工作手册、团队技术详单、程序员首日日程模板和招聘检查清单等。如果管理者所在的组织很不成熟，不能为其手下的员工提供所需的工具（在快速发展的软件开发领域中这种现象很普遍），那么这些工具可以帮助管理者节省下从头开始做的时间。我们真希望在当年刚开始从事管理工作时就能拥有这些工具。
我们曾经思考过是否有必要把这些与软件开发相关的内容写成一本书。毫无疑问，随着大量与工程软件、管理过程和管理项目有关的书籍、文章和网站的出现，一些杰出的工程管理人员一定已经分享了他们的秘诀。然而我们发现，与我们职业生涯初期的那个年代相比，专注于管理程序员和软件开发团队的实例并没有增加多少。
对于新上任的开发经理而言，管理、领导、指点和评价程序员团队的工作没有一般性的方法，很多时候，他自己加入该团队也才几天而已。现成的管理方法是不存在的。与项目经理不同（项目经理需要在自己规划的职业道路上花大量的时间学习以获取证书），开发经理一般都是优秀编码员出身，有一点点人事关系处理能力。
在我们所能找到的书籍中，没有一本像本书一样包含了各类幕后故事和趣闻。这些故事和趣闻是直接围绕着如何处理管理者面对的各种具体情况而展开叙述的。
在本书的各章中，我们分享了从编程、管理以及跨越公司和环境这两个管理生命期交付软件等经历中所获得的宝贵经验。我们把自己的见解提炼为9章，其中夹杂着经验法则与至理名言，以及一些我们亲历的轶事。
第1章讨论为什么将程序员作为个体和群体管理时很特殊。由于程序员的个性各不相同，不能简单地凭借一本管理书籍来管理整个程序员团队。
第2章为观察团队中的程序员提供多个视角，这些视角将有助于发现每个程序员的个性，提醒管理者对他们进行区分管理。
第3章对如何寻找、招募和聘用杰出的程序员进行分步式的指导。这一章最初的读者都发现这一章的内容很适合把书页撕下来单独使用。所以你也可以单独阅读这一章。但要想得到最佳的阅读效果，最好是结合前两章的内容（了解你聘用的是谁），并加入第7章和第8章中的文化和驱动力的内容。
第4章讨论如何使求职者从“同意入职”到开始工作的这段时间一直保有激情，如何避免“买主后悔”，以及如何在求职者入职后迅速、有效、高产地将他们整合到你的工作过程和实践中来。新上任的管理者往往以为在求职者接受录取通知后，他们的招募角色就已经扮演完毕了，但实际上，很多时候还会出现各种状况，例如，求职者第一天没有来上班，难以融入团队，或者一直做不出业绩，等等。
第5章直击管理的核心——向下管理，内容包括团队的日常运作方式和具体做法、成功管理程序员所需的工作和互动。
第5章和第6章之间插入了一些多年来被证明对我们有价值的经验法则和至理名言，为了便于翻阅，这部分使用了浅色阴影页面。这些内容来自众多的程序员、开发经理和软件大师①。恰当地使用这些格言中的智慧，能帮助你表达立场、赢得争论、重塑对话，或者在借助一点小幽默缓和紧张的谈话气氛后阐明你的观点。
第6章指出，成功的程序设计经理还应善于向上管理（管理老板，甚至老板的老板）、向外管理（管理与同级同事的关系、影响公司内部的其他部门或其他人、整合外部资源和关系），以及最终的自我管理（自己的优先级、自己的风格、自己的时间、自己的发展以及自己的生活）。
第7章又回到团队以及激励程序员完成杰出业绩并交付有难度的项目这一关键任务上。这一章开篇介绍了马斯洛、麦格雷戈和赫兹伯格的激励理论。把握激励因素与消极因素（与人们通常的想法相反，它俩差别很大）之间的差异对我们自身管理水平的提高有着至关重要的作用。考虑到每个程序员都有自己的特性，因此不存在通用的激励高招，但我们的框架可以帮助你思考激励团队的方法，以及识别并避免消极因素的方法。
第8章探讨企业文化，并给出了即便在最恶劣的企业文化中，也能获得成功的营造开发亚文化的方法。只有极少数的管理者能认识到，自己在创建团队文化以获得成功的过程中起着至关重要的作用。第5章和第6章介绍了管理的基本方法，而第7章和第8章讨论的，则是能使你的管理工作与众不同且更容易获得成功的两套软技巧。
第9章又回到基础内容。前8章的最终目标是：成功发布软件。这一章讨论的不是项目管理，而是一个很少被关注的角色：团队管理者在软件发布过程中不可或缺的角色。要想取得成功，除了心态之外，还需要具备前面各章所涉及的技巧和努力。
“工具”部分提供一些有用的工具，包括清单、表格、报告等，这些都是我们为招聘、雇用以及有效地管理和激励程序员成功交付高质量软件而设计的。我们相信这些工具一定能对你有所帮助，并能帮你节省下从头开始创建这些工具的时间。这些工具可以从www.managingtheunmanageable.net在线下载。
程序员和软件团队未必是难以管理的，致力于挑战看似难以管理人群的有为管理者可以胜任这一管理工作。我们可以断言，撰写本书（以及法则、工具和把想法转换为文字进行分享过程中的对话）使我们俩成为了更优秀的管理者，使我们的工作更轻松了，使我们的团队更快乐了，也使我们的项目更成功了。我们也希望书中给出的法则、工具和见解能够使读者的工作更轻松。
撰写本书的过程中得到了许多人的帮助。首先，我们要分别感谢自己的妻子，她们在本书起草、改写并最终成书的过程中，始终给我们以鼓励，没有她们的耐心、帮助和建议，本书是不可能完成的。其次，我们要感谢Addison-Wesley出版社的Peter Gordon和Kim Boedigheimer多年来给予我们的持续支持和建议，以及坚信我们创作的这本书是值得他们付出时间和精力来促使其出版。尤其是Peter对本书组织结构的建议在写作后期帮了大忙。再次，我们必须要感谢本书所包含的众多经验法则的提出者们，他们反复重审的先见之明是本书的源动力，我们对如此简短的语句中所包含的见解的深度感到由衷的赞叹。
我们还必须感谢花费大量时间和精力提供详细反馈信息的众多审稿人。多年来，他们在修订内容和提高写作方面为我们提供了很多有益的指导，其中包括Brad Appleton、Carol Hoover、Carrie Butler、Clark Dodsworth、Daniel J. Paulish、David Vydra、Dinesh Kulkarni博士、George Ludwig、Harinath V. Thummalapalli、Jean Doyle、Joe Kleinschmidt、KinnarVora、Margo Kannenberg、Mark Friedman、Michael Maitland、Patrick Bailey、Rama Chetlapalli、Stefano Pacifico、Steve Johnson、Steven Flannes，以及一些匿名的审稿人。经过他们深思熟虑的反馈，本书毫无疑问变得更好了。
最后，我们要感谢在职业生涯中所工作过的各家公司中与我们共过事的众多程序员、管理者以及高层领导们。正因为有了他们以及与他们共事时所获得的经验，本书的面世才成为可能。
Mickey W. Mantle
Ron Lichty
2012年7月
Mickey和Ron的软件职业生涯涉及系统软件、多媒体、界面开发、压缩打包产品、软件即服务、嵌入式设备、信息技术、因特网应用、专业服务以及数据仓储与分析，但他们发现困扰软件开发的那些问题很少是特定于某个领域或渠道的。
困扰软件开发的问题之间有许多共性，但它们也都有自己的独特性—这种独特性更多地来自挑战、压力以及它们所属组织的有机发展，而不是来自技术或工业领域的差异。
从事软件开发工作超过40年，Mickey设计了若干硬件和软件产品，也领导过多个开发团队。从犹他大学（众多计算机工业界的名人都是他的同期同学，如WordPerfect、Silicon Graphics、Netscape、Adobe Systems以及Pixar等企业的创始人）毕业后，Mickey的第一份工作是1971年在Kenway Engineering（后改名为Eaton-Kenway）为美国海军一个占地6英亩的飞机返修设备，开发总体控制软件和实时机器人控制。其后，Mickey加入了三维计算机图形学的先驱—Evans & Sutherland（E&S），并在那里与人合作编写了最初的三维图形库，为Silicon Graphics的GL（后来演变为OpenGL）奠定了基础。他在E&S期间参与完成了许多著名的计算机图形学产品，并且首次开始管理程序员和编程团队。
1984年，Mickey离开E&S并加入了卡内基·梅隆大学的孵化企业—Formative Technologies，在那里，他使用业界的第一批工作站（PERQ和Sun Microsystems）为映射和CAD应用处理大型位图。但他仍然心系三维图形学，1986年，他加入了刚被Steve Jobs收购并从Lucasfilm有限责任公司剥离出来的Pixar。在Pixar期间，Mickey领导了所有外部产品（包括Pixar Image Computer、Pixar Medical Imaging System和RenderMan）的软件开发。RenderMan是三维真实感绘制软件的黄金标准。截至2010年，过去15年中每一件获得奥斯卡最佳视觉效果奖的作品都使用了RenderMan，最近的50件获得最佳视觉效果奖提名的作品中有47件选用了Pixar的RenderMan。
后来，Pixar的业务重心逐渐远离了外部软件产品，而转向制作长篇三维动画电影。为此，Mickey于1991年离开了Pixar，加入了Brøderbund Software，担任工程副总裁和首席技术官（CTO）。在Brøderbund期间，他领导了一个庞大的开发组织，业务范围涵盖应用与系统编程、艺术与动画、音效设计与音乐合成，以及质量保证。这个组织开发出了大量备受赞誉的PC/Mac游戏，如Where in the World is Carmen Sandiego?、Kid Pix、Myst以及Living Books。
1997年年底，Mickey加入了International Microcomputer Software公司，担任研发副总裁和首席技术官，领导团队为大量的Windows/Mac应用（如MasterClips）和专业级的产品（如TurboCAD）进行现场和海外的开发与支持。
1999年，Mickey加入了Gracenote，担任高级开发副总裁（自2008年起Gracenote成为索尼的全资子公司），负责与业界领先的基于网络的CDDB音乐信息服务（该服务使iTunes、WinAmp、Sonic Stage等数以百计的数字音乐播放器应用成为可能）相关的所有开发、运营和专业服务。Gracenote的产品用到了从网络服务、关系数据库到嵌入式系统和移动应用的众多技术，这使得Mickey对今天我们所开发的各类软件的广泛需求都有其独到的见解。2011年年初，为了完成本书、开发移动/平板应用以及与各种公司和组织讨论软件人员和团队的管理，Mickey从Gracenote退休。
他的经验包括，指导全球的研发团队和管理跨学科的团队进行7×24小时的高效工作以交付成功的产品。凭借在印度、俄罗斯、加拿大和日本挑选、创建和管理离岸开发机构的经验，他对使用跨时区、跨地域的不同人员和团队进行软件开发所面临的管理挑战有深刻的见解。
Ron有着30年的软件开发经验，其中有20多年是在做开发经理、工程总监和工程副总裁。在从事软件开发之前，他的第一份职业是在纽约、怀俄明和加利福尼亚当作家。在当作家期间，他写了数以百计的文章、发表了大量的照片并撰写了两本书。他的软件开发生涯始于位于加利福尼亚硅谷中心的Softwest，主要参与文字处理产品的代码编写、编译器代码生成器的编程、嵌入式微控制器设备（如基于智能卡的邮资机、酒店磁卡锁闭系统）的制造，以及计算机动画演示（苹果公司在启动个人计算机和提升用户体验时所使用的）的设计和开发。他在压缩算法领域获得了多项软件专利授权，并撰写了两本被广泛使用的程序设计教材。
1988年，Ron加入了苹果公司，担任开发工具产品经理。后来领导Apple II和Macintosh产品线的Finder与应用程序团队，负责发布苹果公司的“秘制酱料”—用户界面。
1994年，Ron加入了伯克利系统（Berkeley Systems）公司，领导开发当时全球最流行的消费软件—After Dark屏幕保护程序，以确保开发其娱乐产品的7个团队的工程可预测、可重现。接着，Ron加入了富士通，领导开发其久未面世的WorldsAway娱乐产品，他砍掉了6个月的过度设计时间，只用了11周就使产品面世了。
Ron随后在Schwab.com领导开发了第一批为投资者服务的软件工具，包括使知名的传统实体企业经纪公司再次成为在线金融服务的知名品牌。在Schwab担任首席信息官的3年里，他通过技术创新把所有业务部门中用不同程序设计语言进行的软件开发移植到了一个全公司统一的高效平台上，他本人也因此被提拔为Schwab的副总裁。
自此开始，他一直以雇员和顾问的双重身份担任工程副总裁和产品副总裁，一直致力于使软件开发变得充满活力。他先后领导了Avenue A | Razorfish（全球最大的因特网专业服务机构）加利福尼亚办公室的技术部门、Forensic Logic（犯罪侦查和预防公司）的产品和开发部门、Socialtext（第一家商业化的wiki公司）的工程部门、Check Point消费者防火墙生产线的工程部门以及HighWire（最大的因特网学术出版供应商）的出版商服务部门。在美国和欧洲从事咨询工作的过程中，他帮助开发团队排除困难、解开组织机构方面的死结，提高他们的生产力。
Ron为开发者大会以及专业小组提供的演讲和在线讲座包括Agile与Scrum的实现，用户组别、团队合作和网络社区的重要性，以及如何使软件开发由混乱变得清晰。他是6家创业公司的顾问。他是SVForum（硅谷最大、历史最悠久的开发者组织）新兴技术特别兴趣组的联合主席，创办了它的软件架构特别兴趣组，曾担任东湾创新组软件管理最佳实践特别兴趣组的主席，曾是SVForum的董事会成员。
程序设计作为一种严肃的职业已经存在60多年了。在美国，从事程序设计工作的程序员数以百万计，而全球这个数字更大。这些数字还不包括人数众多的学生与编程爱好者，他们非常认真地编写程序，但并不以此为谋生之业。
尽管历史悠久，从业人数众多，但“软件工程师”却因难于管理而闻名。出现这种现象有以下几点原因。
第一，作为一种严肃的职业，程序设计不同于电气、土木工程等相关的工程职业。从 1968 年[1]开始，人们将程序设计这门艺术称作软件工程（software engineering）。但是，与新建土木、电子工程这样的实践相比，从零开始编写新程序更像写小说。新程序的起始往往类似于一张白纸，而传统工程项目则通常是对各种组件库，按照严格的合格性准则进行组装。本书将使用程序设计（programming）一词来称呼“软件工程”，因为相对于严格定义的工程实践来说，程序设计更多的是一门技艺。
从零开始编写新程序更像写小说。
第二，任何人都可以成为程序员。不需要接受正式教育，也没有必需的证书标准或考试[2]。只需要一份程序员的工作即可。[3]
第三，受前两个原因的部分影响，尽管人们做过多种尝试来规范软件工程的流程（如CMMI [4] 1～5级），但这些尝试的影响其实很小。多年来，由大量程序员继续开发的许多软件并不遵循这样的规范框架。而且即便遵循时，也只是对流程有所改进，却无法将程序设计转变为一个纯粹的工程实践。此外，规范化的框架只解决了编写软件的流程问题，但没有涉及程序员管理的问题。遵循流程对管理程序员的问题只能起到最低限度的帮助。程序设计经理们仍然只能依靠自己的方法工具来对下属程序员进行管理。
尽管有很多书籍、文章和网站涉及软件工程与软件开发流程管理，但关于如何有效管理程序员的例子却十分稀少。任何一个棒球队经理都会告诉你，棒球队技术细节的管理比球员个性的管理要容易得多，程序员的管理也是类似的情况。
从计算机出现的早期开始，程序员管理就是一个极具挑战的难题，如下面这段由第二次世界大战（WWII）期间成为世界上第一批程序员的Grace Hopper写于1961年的文字所述：
程序员是一个古怪的群体……他们崛起的速度很快，很快就形成了独立的职业，并且过早地感染了不愿做出改变的抗性。我曾经听说有些程序员因为客户不愿意修改自己的商业系统而斥责客户，而有时走进我的办公室说“但我一直是这么做的”的也正是这些人。出于这个原因，我在办公室悬挂了一个逆时针走动的时钟[5]。
管理程序员的第一步是更好地了解他们。是什么吸引着数以百万计的人投身于“计算机程序设计艺术”呢？答案有时非常简单：它是一份收入优渥而且可以整天待在办公室里上班的工作。然而很多程序员会告诉你，现实中的答案通常没有这么简单。给出那种简单回答的人，通常最终没有坚持程序员这个职业。
事实上，只有特定类型的人才能成为程序员，而只有非常特别的一类人才能成为杰出的程序员。要想知道怎么才能成为杰出的程序员，首先需要了解程序员都做什么。
首先，程序员的工作很有趣！Fred Brooks在软件工程的经典名著之一《人月神话》[6]中很好地总结了程序设计充满乐趣的原因。
既然多数程序员都很享受工作，你就可以理解为什么难以管理他们了。如果有人付钱让你开心地玩，你还会愿意受制于人吗？受人管制就会减少工作中的乐趣！
这也能解释为什么程序员常常难以共事。在计算机出现之前，许多程序员可能会成为工程师、会计师或者教育工作者。我们这么多年来招聘的程序员中约有50%属于这种情况，另外的50%则比较难以归类，许多可能会成为艺术家、音乐家、作家等“右脑型”人才，他们本质上更加自由奔放。更令人惊讶的是，这类“右脑型”人群中产生的天才程序员更多[7]。
此外，程序员的工作“与纯脑力劳动只有细微差别”的特点助长了自由散漫的工作作风，使得程序员几乎无法管理。设计与实现程序时，没有广泛使用严格、规范、全面的工具。往往程序员可以从一张白纸开始设计编写程序。
把这两类不同的程序员混合成一个团结、高效的软件开发团队，给管理工作带来了极大的挑战。管理工程师相对来说比管理艺术家、音乐家和作家要容易一些。如果没有外界的干扰，许多程序员在独自面对自己的设备时通常都会很投入地写代码，一边写一边设计。程序设计经理必须培养建立在可靠的开发实践基础上的软件开发文化，否则程序设计项目就可能失败。
尽管可以对程序员进行分类，但成功管理他们的关键却是要认识到他们是独立的个体。程序员之间的差异很大，你必须努力地让每个人的长处都得到发挥，同时尽力提高或者至少抵消每个人的短板。这条原则适用于任何领域的管理，不过在管理程序员时尤为重要。
即便有着良好的软件实践和开发过程，当项目产品本身难以捉摸的时候，你如何能够知道项目的进度？几乎在所有的软件中，程序的实际有形结果（即打印的报告、输出的数据甚或用户界面）与实际程序的完成状态都是不成正比的。Mickey在Evans & Sutherland公司工作期间，曾与一名杰出的系统程序员共事，这名程序员为一个非常复杂的设备驱动程序设计和编写所有的代码，但在几个月的开发期中，甚至都没有进行过一次完整的编译。再来看另一种极端情况：Ron到富士通公司之前的那3个月时间里，富士通公司的程序设计团队每周都会告诉领导，再等一周产品的功能就能完全实现。对于这两种情形，我们无法通过进度估计来预测项目成功完成的时间。如果程序能够给出我们想要的结果，但设计和/或实现都很糟糕，以致改进或维护完全不现实，那就更麻烦了。即便是资深的程序员也难以注意到程序中这些隐藏的或者无法预见的方面。
坦率地讲，许多（也许是大多数）程序员的工作是对已有的程序进行修改，而且这些程序多半是别人写的。即便程序是他们自己写的，恐怕也是半年之前的事情了，根据伊格尔森定律（Eagleson’s Law）：“自己写的代码如果有半年时间没有看过，就跟别人写的代码没啥区别了。”这句话的意思是，代码看起来会很混乱，难以理解，并且同样无法通过进度估计来预测项目成功完成的时间。
类似地，对许多管理者（尤其是CEO或CFO等技术性不那么强的管理者）来说，原型似乎已经是比较“完善的”产品了。软件难以捉摸的特性使得在企业内部判断其完成状态的难度更大，这与程序产生的结果是好是坏无关。程序设计经理必须能够借助于经验、工具以及深入的观察来把握程序的进度。
避免这些问题的最好办法是招聘杰出的程序员——那些能为计算机程序设计艺术带来纪律和方法的特殊程序员。这些杰出的程序员到底是艺术家、工程师还是匠师呢？
尽管现在对计算机程序设计艺术的讨论很多，但纯粹从字面上理解的话，很少有程序员认为自己是艺术家。
类似地，尽管软件工程是我们的目标，但从字面上讲，如今很少有程序员能称得上是软件工程师。尽管IEEE [8]提供了软件工程方面的规范认证项目，但根据我们的经验，这些认证程序不仅得不到大多数专业程序员的重视，而且知名度在学术圈和极少数公司之外也并不高。普通程序员在软件工程培训方面不会花费很多精力，甚至可以说没有这样的需求。[9]
那么“匠师”这个说法怎么样呢？很多核心程序员认为，把程序员比喻为匠师更合适。[10]匠师不是与生俱来的顶尖高手，他们需要当多年的学徒、多年的熟练工作，在证明自己的技能并获得业绩之后才能赢得顶尖高手的称号。用知识、经验和成功的过往业绩来认证程序员比较切合实际，而正规的认证程序则难以给出这样的认证。我们认为“匠师”这个比喻比其他称谓更适合我们所说的那种“杰出的程序员”。
杰出的程序员是如何产生的呢？仅仅具备程序设计方面的天赋是远远不够的。事实上，程序设计方面的天赋对杰出程序员的技能反而有副作用。杰出的程序员是大师级的人物，做事有条不紊、遵守纪律。他们能够凭直觉把代码和程序组织好，能够约束自己总是在编写代码之前进行设计，能够在最少的时间内编写出清晰、简洁、实用、高质量的代码并获得预期的结果。换言之，杰出的程序员是大师级的匠师。
如果程序员的动力主要来源于时间计划表、管理层压力或金钱，那他通常不会是一名杰出的程序员。对大多数杰出的程序员来说，动力事实上来源于更高的要求：在世界上产生影响，并且做出人们实际使用的程序或产品。杰出的程序员希望并且需要为具有世界影响的项目工作，他们希望能够感受到自己的工作是有意义的，哪怕只在某个很小的方面有意义。杰出的程序员偏爱能够满足他们更高要求的公司和项目，他们非常在意自己所做的事情，常常为了想要的结果而超限度地工作。
杰出程序员的工作效率往往比称职的普通程序员高一个数量级（即10倍以上）。
然而世上的杰出程序员实在太少了，不可能让每个项目团队都拥有杰出的程序员。而且多数团队也只能容忍队伍中有一两名杰出的程序员。我们发现大多数的程序或项目主要依靠的是普通程序员，而不是杰出程序员。普通程序员通常是称职的、专业的、能干的，但他们可能会把程序设计视为一种工作。
现在我们面临的挑战是：如何找到并雇用一个能干的程序员团队，如何激励并训练其中一部分人成为杰出的程序员，如何管理剩下的人使他们获得成功的结果，以及如何保证整个团队的持续进步，即使其中大部分或者所有的人都仅能算是称职的程序员。
大多数杰出的程序员并不热衷于当其他程序员的经理。他们知道团队需要软件经理，但乐得让别人来做实际的管理工作。他们通常不喜欢管理人员或项目。
管理程序员是很难的！“管理程序员很像是在放牧一群猫”——这句话常被引述，它揭示了高效、成功的程序设计经理难当的本质原因。猫的自由主义、个人主义色彩浓厚，而且狡猾、贪玩、好奇、独立。程序员也一样。
根据我们的经验，非常能干的软件经理是很稀少的。而只有这类很少见的软件经理才能成功地管理无拘无束的程序员并且乐在其中。
因为程序员都是些无拘无束的人，常见的激励方法往往不能奏效。除了进行必要的技术监督并把开发实践和过程落实到位之外，善于利用程序员的自我意识和改变世界的欲望也很关键。这就需要一类既能理解程序员的工作方式，又能理解工作本身的软件经理，他们不仅能有效地激励程序员超常发挥，而且能按时交付结果。
对许多职业来说，报酬是主要的动力源泉；但对程序员来说，工作本身和工作环境的重要性要比报酬高得多。程序设计是一个创新的过程，需要有效地处理特殊情况。优秀的经理必须注意到这些情况，并营造有助于程序设计的工作氛围。
本书从头至尾一直在表达这样的观点：成为高效、成功的程序设计经理是可能的。但我们认为，一般只有优秀的或杰出的程序员才能成为成功的程序设计经理。
当然，这通常只是问题的一部分。大多数程序设计经理被提拔为经理就是因为他们曾经是优秀的或杰出的程序员并且表现出了一定的人际交往能力—在引导其他程序员的行为方面展现出了自己的能力甚至可以说是兴趣。
程序设计经理一般都没有接受过正规的管理培训，他们的管理经验通常来自工作和他人的指责。在这些菜鸟经理中，一部分人获得了成功，一部分人很快就失败了，多数人则是经过一段时间之后才宣告失败。
对获得成功的程序设计经理而言，在他们所在的组织或者圈子里面，一般都会有一位导师，引领他们取得成就，并且在他们犯错误的时候给予保护。我们担任程序员以及程序员经理的时间差不多有近40年了，这些年我们招聘、管理过数以千计的天才程序员并当过其中很多人的导师。我们希望本书能够提供导师所能给予的指导，能够为那些在程序员管理方面只能独自奋战的经理们担任代理导师。
本书的目的不是改变程序员，事实上也做不到这一点。他们仍然会在设计之前编写代码，仍然只在必要时才提供有形的结果。我们的目标是提供一些见解、建议、工具、方法以及经验法则来帮你“放牧”软件项目中的“猫”，并且帮你管理团队中看似难以管理的程序员。
[1] 软件工程这个术语创造于1968年，用于描述“系统的、严格的、可量化的开发、运营与维护软件的实践”。参见《科学美国人》1994年9月的“Software’s Chronic Crisis”（软件的严重危机）一文。
[2] 美国计算机协会（Association for Computing Machinery，ACM）在20世纪80年代初期曾有一个职业认证项目，但后来终止了。20世纪90年代末，ACM调查了软件工程职业认证的可能性，但最终认为这种职业认证对业界的软件工程实践来说是不合适的。参看www.acm.org/public-policy上的“ASummary of the ACM Position on Software Engineering as a Licensed Engineering Profession”。
[3] 很多类似于微软、苹果、思科这样的机构都提供认证课程与测试，在业界广泛采用，但这些认证只针对特定的专业领域。它们可能是从事某项工作所必需的，但并不是整个行业所必需的。
[4] 能力成熟度模型集成（the Capability Maturity Model Integration，CMMI）是由软件工程研究所（the Software Engineering Institute，SEI）研发的流程改进方案，为机构提供必需的有效流程元素来提高他们的表现。参见www.sei.cmu.edu/cmmi。
[5] Quoted in G. Pascal Zachary, _Show-Stopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft_ (The Free Press/Simon & Schuster, 1994).
[6] Frederick P. Brooks Jr., _The Mythical Man-Month, Anniversary Edition_ (Addison-Wesley, 1995; originally published in 1975)。这本程序设计的经典书籍，是每一个管理程序员或者软件开发项目的人的必读之物。
[7] 多位业界领袖都表达过类似的观点，认为音乐家可以成为非常杰出的程序员。Mickey本人也是一位音乐家，所以从内心认同这个观点。
[8] 电气和电子工程师协会（the Institute of Electrical and Electronic Engineers，IEEE）提供对软件开发职业工程师的认证（Certified Software Development Professional，CSDP），它大体是根据软件工程知识体系（Software Engineering Body of Knowledge，SWEBOK；www.swebok.org）列出的实践设置。虽然这种认证是否值得追求本身仍是一个颇具争议的话题，但值得一提的是，在“正统”的工程领域里，认证机制是普遍常态。
[9] For a pragmatic look at certification, see Jack Ganssle, “More on Certification,” September 7, 2005, www.embedded.com/ columns/embeddedpulse/170701175.（译注：该链接已失效，请参见http://www.embedded.com/ electronics-blogs/-points/ 4025582/More-on-Certification。）
[10] Pete McBreen, _Software Craftsmanship_ (Addison-Wesley, 2001).
从许多方面看，程序员之间的差异都非常大，只有很了解程序设计的人才能完全理解这一点。大多数公司的高层管理者对所有的程序员一视同仁，这是一个可怕的错误。微软公司的Bill Gates和Adobe Systems公司的John Warnock都没有犯这样的错误，因为他们俩本质上也都是程序员。
这种差异为什么很重要？也许不应该很重要，但事实上，这种差异真的很重要。历经多年的程序员管理工作之后，我们仍然惊叹于程序员之间的巨大差异，需要有区别地进行问题处理和激励。对我们而言，有一点是毫无疑问的：要想成功地管好程序员，首先必须真正地了解每个程序员。
有一点值得重视：我们发现一般情况下，程序员的年龄、性别、种族或文化不会造成太大的差异。根据我们对数以百计的程序员招聘与管理的经验，程序员之间的差异主要来自个人内在因素，而不是外在属性。当然，后天的训练和经历肯定是有影响的，但个人的天赋和与生俱来的特点才是真正的区别所在。
理解程序员的方法有很多种，我们从以下几个不同的角度来考虑：
了解程序员的第一种方法是分析他们的程序设计工作可以归为哪些类型。程序设计工作通常有下面4种类型：
当然，可能有许多特殊的程序设计工作难以确切地归结为上述某种类型。但总的来说，这4种类型已经覆盖了世界上的绝大多数程序员，其中每一种程序员擅长的问题解决方法、使用的工具以及侧重的产品方向都各不相同。一些极有天分的程序员能够胜任所有工作，但大多数程序员认为自己虽然能完成所有的程序设计任务，但其实最多只能把其中一种做好。
一般情况下，我们建议为不同类型的工作任务安排不同的程序员，不要指望哪个程序员能同时兼任多种类型的工作，否则你很可能最终会为这个决策感到后悔。因此，在雇用程序员或者为项目安排人手之前，首先必须明确自己需要什么类型的程序员。
把所有曾经从事过程序设计工作的程序员都统计在内，大部分程序员都属于客户端程序员。这里术语客户端（client）指的是程序所在的位置，通常是终端用户的计算机上。个人电脑的出现催生了无数的“客户端程序”——文字处理软件、电子表格、工作效率程序、游戏以及众多的实用工具（包括微软的Word与Excel、Brøderbund的Myst游戏以及Lemke的GraphicConverter工具等）。而在个人电脑出现之前，程序员所编写的大多数程序都在中央系统中运行。程序的开发者负责把“客户端结果”传输到非智能终端或者智能终端，或者通过打印出的报告提交“客户端结果”。这些程序开发者也是客户端程序员。
随着低成本微处理器的普及，客户端程序员逐渐把业务拓展到嵌入式应用领域，所开发和交付的应用可以在游戏控制台、手机、iPad以及其他的消费电子设备和终端用户设备上运行。
为什么把这些程序员都归类为客户端程序员呢？因为他们在工作时几乎可以完全控制自己的资源。客户端程序员的任务范围通常是有限的，所需要交付的产品也是明确的。因此，客户端程序员/团队的职责很明晰，除了服务器端传来的数据外也几乎不依赖其他东西。
这里术语服务器（server）不仅指出了程序所处的位置，还表明了编写程序的目的通常是向远程客户端传输信息和数据。服务器程序所在的机器通常离终端用户都很远，而且大多数这样的程序必须能够同时处理来自多个客户端的多种行为，这就使得服务器程序通常比客户端程序员开发的程序更复杂一些。在编写和部署服务器程序时，通常还要求在增加新机器与资源时能不用改变程序的基本结构，这又进一步增加了开发服务器程序的复杂度。
随着互联网的出现，术语客户/服务器（client/server）就成了Web浏览器与（“在网上某个地方的”）Web服务器之间交互方式的代名词。基于客户端的Web浏览器很复杂，但实践证明，创建能够使数以百计或数以千计的终端用户同时访问同一台Web服务器的服务器程序，确实是一项更为复杂的工作。构建这样的系统通常离不开在各个服务器系统与程序之间进行接口转发、数据传输及同步的工作。这类工作是典型的服务器程序员需要完成的任务。
数据库程序员与客户端程序员或服务器程序员不同，他们使用完全不同的程序设计语言和工具，编写的程序给出的结果也截然不同。数据库程序员通常是对终端用户或应用程序所使用或产生的数据进行组织、存储和提取工作。
这些年来，不同数据库系统之间的差别逐年减少，数据库程序员在一个数据库系统中积累的“基本”技术技巧也更容易迁移到别的数据库系统了。尽管像Hadoop这样用于访问TB级数据的“大数据”系统已经涌现出来，但最常用的数据系统仍然是关系数据库，包括Oracle、Microsoft SQL Server、IBM DB2、MySQL、Postgres和Berkeley DB。这些系统中的多数关键概念是相同的，它们都使用SQL语句（以及等价的API）来访问数据。因此，有人可能会认为，其中某个系统的专家很可能也是另一个系统的专家。但根据我们的观察，除非是最基本的数据库操作，否则在特定数据库系统上的实战经验仍然是必需的。
数据库程序员就像是汽车修理工。你可能会随便找一个汽车修理工帮你换轮胎或者雨刮器；但是对于保时捷汽车上的重要问题，你绝不会让一个完全不了解保时捷的修理工来做。数据库程序员也是如此：我们可能会随便找一个数据库程序员撰写报告来访问Oracle数据库中的数据；但需要在数据库系统（如Oracle、SQL Server）上进行重要的开发时，绝不会考虑实战经验不足的程序员。
许多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种工作。但是，大多数程序员都只专精于其中一个领域，只有在编写“适合自己”类型的代码时才能获得最大的产出。让程序员加入风格不合的项目往往只会引发灾难。程序员也许能够胜任其他类型的工作，但大多数程序员对此没什么兴趣。而如果程序员对自己所从事的工作没有兴趣，那就迟早要出问题了。
为了选择合适的职员，我们还需要理解另一种看待程序员的方法。在上一节讨论的几种类型中，我们侧重考虑了程序员所从事的工作的类型（即客户端、服务器、数据库、Web）。实际上，从技术知识、实践经验和程序员的专长角度去考虑也是很重要的，按这样的思路可以把程序员分类为：
在所有开发类职员中，系统工程师/架构师是最有技术和经验的。要想理解所有相关的系统组件（操作系统、通信系统、数据库、在线/离线访问、安全性、硬件等）之间的复杂关系，需要对所有这些技术和系统都有丰富的专业知识和经验。通常，在一个规模合理的团队中，只会有一两个“真正的”系统工程师/架构师。杰出的系统工程师/架构师可以使团队中的其他人表现得更好。他们的系统工作起来会更可靠，通常看起来也更简洁。
Gracenote就是由一个技术和经验都很丰富的系统工程师/架构师创立的，纯粹由他完成的设计和实现创造出了一种令人难以置信的可靠、可扩展而且灵活的服务。Google公司的联合创始人Larry Page和Sergey Brin也是类似的系统工程师/ 架构师，他们在设计和实现上培育的优雅风格帮助Google公司在技术和商业领域都取得了成功。
大多数系统工程师/架构师都是从系统程序员做起的。系统程序员理解系统中所有组件的工作原理，包括客户端和/或服务器端的操作系统和通信系统。Alan Kay在他的博士论文[1]中引用了Bob Barton对其他程序员如何看待系统程序员的总结：
系统程序员相当于民间宗教中的大祭司。
——Bob Barton[2]
系统程序员负责编写与硬件交互的设备驱动程序，创建能够为设备驱动程序和应用程序执行提供运行时环境的操作系统，为其他程序员创建编译器和调试工具，通常还会为其他程序员提供工具和服务用于交付程序。
在过去，对社交能力正常的人来说，被称为系统程序员几乎可以说是一种侮辱。我们认识许多系统程序员，他们的着装和举止如今已成为代表性的极客造型并流行开来。每当我们想起自己认识的那许多系统程序员，就会想到“我当极客的时候，极客还不受欢迎”这句话（顺便提一下，我们两位也曾经是系统程序员）。
在专业程序员、学生以及自称为程序员的业余爱好者中，绝大部分都属于应用程序员。应用程序员开发的程序或其结果通常给终端用户直接使用。应用程序员开发的程序包括文字处理软件、电子表格、日历、Web浏览器、iTunes与Windows Media Player之类的媒体播放器、游戏等。应用程序也可以由数据库程序员开发，以便对数据库中取出或存入的数据执行特定的操作。数据库应用程序包括财务软件、机票预订系统以及Oracle Financials之类的数据挖掘工具等。
一些应用程序员能够跳出代码本身的束缚，与应用程序的用户产生同感，真正从用户的角度看问题，从而很好地把握各种可视化、交互式的设计之间的细微差别。这样的应用程序员很适合从事用户界面（UI）的开发。如果让这样一位有天分的应用程序员与一名UI设计师（通常不仅有图形设计背景，而且对人性甚至认知心理学都有所研究）合作，将产生一加一远大于二的效果。
有一些项目（如MacOS的桌面UI——Mac Finder）侧重于UI，要求整个团队都由这种有天分的应用程序员组成。因此，Ron在苹果公司领导Mac Finder团队时，在寻找和面试候选人的过程中，特别看重程序设计技巧和用户视角。他认为：“只懂得程序设计技巧的程序员在那个团队中是无法取得成功的。”
开发团队中有一些被称为“程序员”的技术人员其实并不是真正意义上的程序员。他们当中有些人使用图形用户接口（GUI）指定程序逻辑或商业逻辑，然后生成用户可访问的应用程序；有些人则通过创建脚本或修改配置文件来定制显示的内容。这些“程序员”与真正的程序员之间的主要差别在于：他们使用现成的工具或应用程序，而不是自己直接写代码。
这类“程序员”有其重要性和价值，但他们的技术深度通常不能与我们所讨论的其他类型的程序员相提并论。随着程序设计工具的出现和日益强大，像这样的程序员正变得越来越多，但在本书中我们不会直接讨论他们。
我们所介绍的许多程序设计技术也适用于这种另类的“程序员”。但根据我们的经验，他们中的多数人仅满足于把自己的工作做好，而不像“真正的”程序员那样渴求学习、动力十足。
程序员在组织所处领域或行业的背景与知识也各不相同。
我们发现职位的分类、描述和需求中对经验的要求是随着经济状况而变化的。经济状况较好时，组织需要具有宽广领域知识的技术人员和技术经理，希望他们能贡献出创造性的思维、集体的智慧以及在其他领域已经得到运用的最佳实践。例如，Ron受雇从产品领域进入金融服务IT行业时，他的团队已经有了丰富的交互计算经验（Mac操作系统）和娱乐产品（游戏与多媒体工具）。Web在1996年属于新生事物，Schwab需要一个外部技术专家来领导其团队为投资者构建具有高度交互性的Web工具。
而当经济状况不好时，组织则会控制规模、缩减开支，只在核心领域功能方面进行有效、有限的发展。企业在这一时期只能够招聘极少数的新雇员，为了降低风险，它们倾向于招聘在特定领域具有多年知识背景的专业人士。
不管经济状况如何，每个团队都可以由具有程序设计天赋、领域知识、分析能力以及技术交流能力的人员混合构成。其中领域知识在雇用程序员团队时是一个重要的考量因素。
要想成功地招聘和管理程序员，首先要认识到每个程序员都有其独特的能力。就像雪花一样，任何两个程序员都不会是完全一样的。我们常常会说，程序员之间写代码的能力可能相差一个数量级。这种差异是怎么出现的呢？教育、经验、天赋以及直觉，还有其他无形的因素，都有可能导致这样的差异。
多数程序员不需要借助显式的排名或者头衔，从直觉上就能理解同行之间的差异。但是如果能把程序员的类型与等级正式记录下来，并简要描述每种类型与等级的职位要求与能力（见表2-1），那么管理工作将会轻松很多，项目经理将更容易找到各种任务和项目的最佳人选，高级管理层也将能对组织及其构成有更深刻的认识。
表2-1 客户端程序设计等级指南
| 程序设计等级 |
客户端程序员 |
|---|---|
| 入门级 |
程序员3 |
| 1～5年经验 |
程序员2 |
| 有经验（5～10年） |
程序员1 |
| 有经验（10～20年） |
高级程序员2 |
| 很有经验（超过12年） |
高级程序员1/架构师 |
每个程序设计等级[3]都关联着一组评价标准，程序员必须符合相关条件才能被录用或者提拔到该等级。当然，对工作年限的要求不是绝对的，但可以用于粗略地指出相应程序设计等级所需要的经验。每个程序员都有自己独特的技巧和经验，上述提法并不意味着很有天分和经验的程序员会因为工作年限不够而受到压制。最后，评价程序员不能看他们在入职时能带来什么，而要看他们在入职后能产出什么。
根据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种：
可以将这些类型的关系视为一组“约束关系”，排序的依据就是相应的约束程度。约束力度越大（对内部雇员的约束力度最大），你对程序员工作的控制力和能见度就越强；约束力度越小（对外包公司的约束力度最小），所需做的间接管理工作就越多，通常只能通过规格说明和交付成果进行的，而无法直接管理人员。
本章已讨论过的大多数工具都是为内部雇员设计的。招聘内部雇员意味着你和你的公司为了使雇员好好干活，除了支付报酬之外，还要明确承诺提供一系列经过商定的额外待遇以及专属的工作环境。这是一种常见的合同。
但合同中还包含许多隐含的假定，至少根据我们的经验是这样。内部雇员希望能干一番事业，而不仅仅是打一份工。因此，你还必须考虑为他们提供：
不过，如果你能和内部雇员建立起密切的关系，就可以大大减少有效管理所需的沟通。
从根本上讲，远程雇员的管理方法与内部雇员的管理方法是一样的。你仍然要满足他们的众多需求，他们也仍然要好好干活。但管理这种不常见面或定期碰头的雇员时，传达指示和沟通交流都会更麻烦。
Evans & Sutherland（E&S）的创始人，曾告诉Mickey一种如何有效判断沟通难度的方法：
沟通的效果，在国内，是距离平方的倒数，跨越了国界，就是距离的立方的倒数。
——David C. Evans
根据我们的经验，这条经验法则很正确。我们见过太多因为对方不在身边而沟通失败的例子了。距离越远（楼下、相邻的楼中、相邻的时区、世界的另一端），沟通越困难。如果这种距离是跨国的，由于时差、语言和口音的挑战以及文化的障碍等影响极大，沟通受到的妨碍往往更大。
因此，当你准备招聘一名远程雇员（或者有雇员即将迁居其他州或国家，而你打算留用他）时，一定要了解为了保证足够的沟通，所需要做出的努力。即使你已经预料到远程管理很难，但实际的难度可能会超出你的想象。
远程雇员的另一个问题是，他们所能从事的项目类型几乎肯定是受限制的。也许你的公司或组织能提供很多项目供远程程序员独立工作，但大多数公司都不是这样的情况。只有很特别的程序员才能超越时空的束缚，与远程的团队紧密协作并获得高效的产出。在招聘远程雇员之前，请确保他是这种特别的程序员，或者你有足够多的、很大程度上可由他独立完成的项目。
决定雇用合同工而不是全职雇员，不能随随便拍板，通常需要视具体情况而定。如果某项任务工作量很有限，或者全职雇员全都没有时间来完成，那么雇一名合同工是不错的决定。
根据定义，合同工是以获取报酬为目的而帮你干活的“枪手”。合同工不应有隐含的需求。开工前，所有的需求都必须在合同中阐明。
在我们讨论的各种关系中，公司与合同工的这种关系一般是最简单的，简单的原因在于，它可以随时终止，而不需要任何理由或提醒[4]。但这并不是说这种关系不可能变得复杂。如果变得复杂了，毫无疑问是你的过失。你应当制定规则并适时做出决策。
那这种简单的关系怎么会变得复杂呢？通常是由于你并没有按照合同工的经典定义，找合同工做某项具体的工作。很多时候，你想要找的是全职雇员，但暂时找不到合适的或者不确定已找到的人是否合适，于是，你就先招了一个合同工，但却将其视为全职雇员来对待，这就会导致合同工也有了类似于全职雇员的隐含需求，而这些需求有时经过诉讼会得到法庭的支持。因此，在我们担任过经理的公司中，人力资源部门和法律部门都明确要求程序设计经理不得为合同工提供额外的福利（衬衫或者外部的团队活动）。
所以，请特别留心你为合同工设定的需求和待遇。要将他们视为拿报酬的枪手来对待，不要因为他们的待遇不同于全职雇员而不安。他们不是雇员。
我们认为一线的程序设计经理不应当接受管理外包关系的任务，因此外包团队和公司的管理问题本书不拟讨论。外包管理需要专门的技巧和格外的小心。当项目的某一部分可能需要外包时，只有在你能得到具有这方面管理经验的人士的帮助与支持的情况下，才可以选择接受外包。否则，接受外包会连累身为程序设计经理的你。
管理外包资源本身就是一份需要全身心投入的工作，第5章将讨论从海外合同工那里获得价值的挑战。
在工程师和程序员中，代系差异是一直存在的，而今这些差异已经对职场产生显著的影响。当前，团队的成功必须依赖三代程序员的通力协作，而这三代人的价值观、想法和驱动力都不同。
为了把工作做好，我们不仅需要了解自己的工作风格，还要掌握手下员工的工作风格。一种常见的办法是从代系的角度来看待他们，但问题在于人们对代系的划分还未达成广泛的共识。传统上是按出生时间来区分的：
但用这种分法来考虑代系差异并不完全合理。一个人的“真实”年龄不仅取决于出生时间，还取决于其个人思想。我们都见过那些行为与年龄严重不符的人，有的“少年老成”，有的则“过于天真”。因此，简单地基于出生时间来对待人是很危险的。
当然，不管实际年龄如何，同一代系内的成员之间总有着一些共同的特性和价值观。表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可以看出，这些不同代系的程序员在个人成长过程中所受的影响是截然不同的。更重要的是，他们相互迥异的核心价值观导致在职场上表现各不相同。
不难看出，如果在办公室里大家必须均摊工作，那么这种不和谐的核心价值观会造成严重后果。要想成为一名成功的管理者，一个重要的前提就是，能针对这些不同代系的程序员制定个性化的管理方法。
程序员除了具有不同的类型之外，还普遍存在着个性特点、特质和习惯，这些因素各自都面临着一些挑战。
学术界有着许多关于个性、如何对个人进行分类以及如何管理个性的理论。在这些理论中，迈尔斯和布里格斯的工作值得花一些时间来理解，他们俩在1942～1962年间建立了个性测试的理论基础，并提出了对个性进行分类的体系。迈尔斯-布里格斯类型指标（Myers-Briggs Type Indicator，MBTI）个性清单的作用是，使C. G. Jung描述的心理类型理论易于理解，在生活中更实用。[5]他们的工作在1984年出版的《请理解我》（Please Understand Me）[6]一书中得到了推广，该书以一种易于理解的形式介绍了迈尔斯-布里格斯方法。
Jung最初描述的类型是外向（extroversion，E）/内向（introversion，I）、感觉（sensation，S）/直觉（intuition，N）、思考（thinking，T）/感觉（feeling，F）和感知（perceiving，P）/判断（judging，J）。值得注意的是，研究[7]表明相当一部分程序员属于INTJ（内向/直觉/思维/判断）类型，Mickey和Ron也都具有这一个性特点。
这本书中有许多值得学习的地方，尤其是在人际关系方面。然而，用这种公式化的方法来应对多样化的技术个性特点是充满危险的，我们也没有发现它在团队管理方面特别有用。我们建议你避开公式化的个性分类，而把精力放在已知个性特点的管理方面。
根据自身的经验，我们给出了一些你在管理程序员时可能会碰到的个性特点类型。这个清单并不详尽，但我们基本上解释了你可能会管理到的不同个性类型，并给出了一些辨别方面的建议。
右脑理论与左脑理论源于Roger W. Sperry的工作[8]，他的研究表明，大脑的左半球和右半球具有针对不同任务的专门功能。左脑通常专用于分析任务和语言表达任务。左脑的表达能力比右脑强得多，而右脑主要用于空间感知任务、音乐等。
如果你是一名程序员或者技术人员，你很可能属于“左脑型”，这意味着语言、逻辑和分析使用得更多，也更客观。其实称为“左脑为主型”更恰当，因为我们只有一个大脑，两个半球始终是同时工作的。因此，你既可以是“左脑型”的人，又可以具有非语言交流、直觉、想象力较多且更主观等强烈的“右脑型”倾向——这些倾向通常更多地与音乐家、作家、艺术家等创新型人才相关联。
对于一名优秀的程序员来说，强大的左脑分析能力是必不可少的。不过，与右脑相关的活动往往也同样重要，这是因为程序设计是一门很有创意的艺术（如第1章讨论的那样，更像是写小说）。事实上，我们（和其他人一样）发现，一些最顶尖的程序员同时也是音乐家。Mickey在大学一年级刚接触程序设计时就是一名专职音乐家。“我刚开始做程序设计时，就对媒体很有兴趣，那时我已经是一名音乐家了。音乐理论都是基于数学的，长时间的练习需要专注和纪律。我发现演奏和/或作曲时的创造性部分与设计并实现程序时的创造性部分非常相似。令人惊讶的是，甚至程序调试也在某些方面类似于歌曲的演奏学习——你需要一遍又一遍地演奏歌曲中的某一部分直至完全正确，这就如同反复运行程序直到能够正确运行一样。我甚至发现自己在做程序设计的时候完全没有时间概念，这与我练吉他的情形非常相似。从那时起，尽管我还在继续演奏音乐、作曲和作词，但程序设计已变成了我的主要创新活动。”
在我们认识的众多程序员中，这样的故事并不是唯一的。事实上，音乐已经成了对有希望的候选人进行第一次面试时的常见问题。如果候选人是音乐家，那么讨论他们喜欢什么样的音乐、演奏什么样的音乐、音乐理论以及音乐在他们生活中的地位，不但可以展现深刻的见解，而且有助于使他们在面试的开始阶段保持放松。成为音乐家不是成为优秀程序员的必要条件，但我们也从来不将其视为成为优秀程序员的障碍！
多数企业中的多数雇员属于白天型的人，与他们不同，多数程序员属于夜晚型的人。他们往往在正常上班时间过了好久之后才到单位，并且工作到下班以后很久，当关键性的项目或者自己感兴趣的项目进展到中途时常常能工作到深夜。一般说来，如果你关注的是结果，而这些起床很晚的人能给出符合或者超出你预期的结果，那就不是什么问题。然而，沟通经常是个问题；也就是说，他们需要出席会议并交流信息。
在《编程之道》（The Tao of Programming）[9]中，Geoffrey James提到：
经理走到程序员们跟前说：“关于工作时间：你们必须上午9点到，下午5点走。”听到这里，所有的程序员都很生气，有几个当场就提出辞职。
于是经理说到：“好吧，只要你们能按计划完成项目，可以自己安排工作时间。”程序员们这才感到满意，从此每天中午来上班，一直干到第二天凌晨。
为了避免这样的问题，我们强烈建议你别要求夜晚型的人早上9点就到。我们的建议是，你设定一些希望所有人都遵守的“核心时间”，以确保整个团队之中能有最低限度的合理沟通**。商定核心时间可以帮每个人节省大量的时间，且易于避免苦闷。注意，隔一段时间就要重申一下核心时间，因为程序员会感觉到日程的变化，他们对核心时间的遵守会渐渐不那么严格。
还有一个问题需要解决，那就是公司其他部门对你的团队的看法。在我们俩工作过的每个企业，我们都听到过“你的手下直到中午才来上班”这样的批评。针对这样的话，你需要主动突出强调你的团队投入了多少时间，他们写完并提交代码的时间有多晚。确保把那些最有名的夜猫子挑出来，让大家都看到他们按自己的工作习惯所做出的业绩。这一切都要主动去做，不要等到出现批评之后才着手。
大多数程序员倾向于当“牧童”而不是当“农民”。也就是说，当问题出现时，他们的第一反应是“跳上马离开”去独自解决问题。他们常常跳过规划，最终得到一次性的解决方案。实际上，可以在标准、实践和团队之间取得更好的平衡。
我们希望软件开发更像种地。农民会有条不紊地了解地形、研究土地的化学组成、种植、浇水、除草，最后收获。可靠、可扩展、可维护的软件就是这样有条不紊地开发出来的。
因此，识别出牧童，并确保他们受到限制而不能快速冲出去是很关键的。这样开发出来的解决方案最终才能用于解决其他问题。
很多程序员都有牧童倾向，因此更高的要求是营造以下的软件开发文化：禁止牧童行为，所有的主要项目都遵循系统的软件开发生命周期。
不过，有时候，你还真的想要一个“牧童”而不是想要一个“农民”，这些时候需要做的通常是小型的、一个程序员就能完成的概念验证项目或者原型项目。我们发现，如果身边有一个能解决这种问题的“枪手”，对他对你都很有利。把你的需求和程序员的基本个性匹配起来，双方都会更开心，结果也会更好。
许多“牧童”都是优秀的程序员，但你必须小心地对他们进行管理，以获得想要的结果。他们有着当主角和引起纷争的倾向，所以务必对他们保持密切关注，一旦出现问题要马上采取措施。
只能当“牧童”的程序员通常都不会在企业待太久。要么是你对他们总是自顾自地向前冲感到厌烦而辞退他们，要么是他们对长期受限制感到厌烦而主动辞职。
英雄指的是承担需要超人的努力才能完成的任务，并最终取得成功的人。在付出超人的努力方面，英雄与牧童是相似的。但英雄能够在团队工作和开发过程中获得成果。英雄是培养出来的，通常会在企业中崛起为超级明星。
管理英雄的挑战是：如果你总是期望他们付出超人的努力，很容易就毁了他们。偶尔期望一下是可以的，总是这样期望就不行了。认真关注他们的福利，把他们选择性地用于重要的举措或者关键的项目。
Mickey和Ron在从事程序设计工作的时候，常常承担难度较大的项目，并（在熬了若干通宵或者进行马拉松式的工作之后）出乎意料地完成任务。这对我们工作过的公司是很有益处的：为Kenway和E&S实现了关键产品的发布；完成了里程碑式的苹果电脑产品演示，这对于苹果当时最新的计算机生产线是很关键的；为我们的公司储备了专利技术；为了客户和公司的利益，不断挑战我们自身的极限和已知的技术极限。在我们成为经理之后，这样的经历对于判定选择性的超人努力与毁灭性的用人方式之间的界限是非常有用的。
你的一些职员非常沉默、非常内敛，几乎感觉不到他们的存在。他们可以把工作完成得很出色，但是对团队动力或在会议上几乎没什么贡献。他们在一对一的时候能进行交流，但退回到人群里以后就几乎消失了。
在会议上让他们发言时，当他们分享自己的意见或见解时，要给予正面的支持，这样可以逐步帮助他们建立自信——自己对团队是有贡献的。找机会跟他们交谈，当面认可他们的贡献。与他们的交流要一个一个地进行。通过一些小事情与他们建立特殊的联系，比如分享经验或者一本书。总之，想方设法建立更紧密的联系。
Mickey想起了Brøderbund公司的一名内向的技术作家。Mickey与这名作家是通过角色扮演游戏建立联系的。Mickey的鼓励促使他进入了游戏设计领域，最终成为了Brøderbund的游戏设计经理，后来又在其他一些公司担任小有名气的出版作家和游戏设计师。
多年来，这一联系以及其他一些类似的联系对我们俩来说也是一种回报，因为我们亲眼看到了谦虚的人经过我们的鼓励之后有所成长，并展现了自己的才华。
尽量避免雇用心存极大愤懑的人。他们会通过挑拨离间和散布不满情绪来毒害整个开发团队，并对组织造成严重的破坏。如果没有他们，那些情绪可能永远不会出现。
愤世嫉俗的问题在于它是植根于现实的，但在组织内部的影响极大、极深。例如，“管理层不在乎程序员”可能是真的。但即便实际情况并非如此，愤世嫉俗的人们也会抓住每个机会来强调这句话的真实性。他们会把每一次非故意的怠慢（如办公室冰箱中饮料的变化）说成是“管理层用来惩罚程序设计人员的密谋”。用最客气的话说，这样的言论是公然藐视真理和道德的。你甚至发现自己根本无法度假，如果不希望回来时发现自己的团队处于混乱、脱轨甚至“造反”状态的话。
有些人只不过是奇葩（jerk）。他们粗鲁、刻薄、中毒不浅。当然，他们或许也有些可取之处。他们可能是很有才华、很有技术天赋的优秀程序员。但才华并不能匹配你雇用他们所需要付出的代价。离他们很近正是问题所在。
遵循“不招收奇葩”的法则。根据我们的经验判断，如果你不这样做一定会后悔的。最好将该法则扩展到愤世嫉俗之人和傻瓜。你的职员会对此很赞赏，你的工作也会轻松很多。
第5章和第7章还会详细谈论愤世嫉俗的人、笨蛋和奇葩。
本章的目的是帮助大家认识到，理解程序员并不是一项简单的任务，即使你当过程序员也不例外。我们提供的多种视角，只能帮助你找到最适合你的方法来管理那些必须雇用的程序员。管理人是很困难的，有些最有天赋的程序员同时也是最难管理的人。这是一把“双刃剑”。
我们列出了多种个性类型供大家了解，但强烈建议大家不要简单地按这些类型对人进行分类。把每个人都作为不同的个体看待，你这位程序设计经理会更成功。
我们为团队管理提供了许多辅助工具。电子表格和Word文档提供了完整的示例，稍作修改即可用于你自己的组织。全书最后的“工具”部分给出了工具网站的链接，在那里可以下载下列工具：
[1] Alan Kay是一位富有影响力的计算机科学家，因为Smalltalk语言和他对面向对象程序设计的贡献而闻名。参见www.vpri.org/html/people/founders.htm。
[2] Bob Barton是Burroughs 5000的主架构师，并且是犹他大学的教授。Alan Kay就是在犹他大学获得的博士学位，他的博士论文可参见www.computer.org/portal/web/awards/barton。
[3] 这些程序开发等级与大多数薪金调查服务（如Radford Survey和Salary.com）具有一致性。这些服务提供薪金对比和总体报偿信息，这些信息对于管理软件团队非常有价值。通过把程序员的程序开发等级与所在公司使用的薪金调查服务匹配起来，可以保证管理团队时有最可靠的信息辅助。
[4] 这么做的前提是你使用了合适的合同，包含了不需理由或提醒就可“随时终止合同”的权力。任何标准的合同工协议里都应当包含类似的条款。本书最后的“工具”部分提供了一份包含着这种条款的独立合同工协议示例。
[5] The Myers & Briggs Foundation, MBTI Basics, www.myersbriggs.org/my-mbti-personalitytype/mbti-basics/.
[6] David Keirsey and Marilyn Bates, Please Understand Me: Character & Temperament Types(B & D Books, 1984).
[7] C. Bishop-Clark and D. Wheeler, “The Myers-Briggs Personality Type and Its Relationshipto Computer Programming,”Journal of Research on Computing in Education 26, no. 3 (Spring1994): 358-70.
[8] 1981年，诺贝尔生理学或医学奖分成了两份，其中一份颁发给了Roger W. Sperry，“因为他发现了大脑半球的功能机制”，另一份颁发给了David H. Hubel和Torsten N. Wiesel，“因为他们发现了视觉系统中的信息处理机制”。参见www.nobelprize.org/nobel_prizes/medicine/laureates/1981/。
[9] Geoffrey James, The Tao of Programming (Info Books, 1986). 如果你的团队成员工作于不同的时区或海外工作，我们也会做出相同的建议。
