作者：瑞恩 （Terrence Ryan）
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
布道之道：引领团队拥抱技术创新试读：
本书赞誉
在这本书里，Terrence Ryan对常见但又难以捉摸的人性——怀疑，清晰地进行了概括。同时，他也针对推动循序渐进的改变给出了切实可行的解决方案。人类确实经常会莫名其妙地抗拒遵循最佳实践，但Terry的这本书不仅有助于认清人们抵制改变的原因，还会告诉你如何在逆境中成功。Ben Nadel，Epicenter咨询公司首席软件工程师
人际关系是让技术人员最头疼的一个话题，也是技术图书中很少涉及的一个话题。Terrence在本书中颇有见地而又有条有理地对这个话题进行了剖析。本书可以帮你理解各种反对者类型（既有理性的也有非理性的），帮你有策略地把人们引导到你的技术方向上来。Bill Karwin，《SQL反模式》作者
Ryan以工程师的眼光、心理咨询师的洞见、一线战士的经验，为读者提供了一整套解决最迫切问题的系统方案，以及如何在技术工作中变得更有创造力和更少挫折感的大局观。本书完全贴近最需要学习Ryan成功的组织管理的读者的切身感受。Jeff Porten，国际咨询顾问
这是第一本讲述如何推广技术成果的书，它回答了从事应用或Web开发的程序员都关心的问题。Terrency Ryan的语言风格幽默风趣，丰富的实例让人身临其境。读罢恍如作者刚刚在你们公司会议室里做完演示一样。Brian Rinaldi，Adobe公司Web社区经理
致谢
没有Dave Thomas和Andy Hunt，就没有这本书。如果不是读过《程序员修炼之道》，我不可能知道自己迫切需求的技术和工具。从看他们写的书到为他们的出版公司写书，我完成了一个自己曾经认为不可能完成的任务。
Jackie Carter是这本书的编辑。她对我的情况可以说是了如指掌，每当我写不下去的时候，她总会及时地出现。她还给我出谋划策，确保了这本书的可读性和容易理解。还要感谢本书的技术审校，感谢他们对本书的润色和修饰：Rachel Davies、Ben Nadel、Karl W. Pfalzer、Craig Riecke、Johanna Rothman和Brian Rinaldi。
我必须感谢沃顿商学院的所有同事。无论是质疑过我的人，还是被我说服的人，他们教会了我很多，特别是在做技术布道的时候，该做什么，不该做什么。其中，特别要感谢Dave Siedell、Bob Zarazowski、Gerry McCartney和Deirdre Woods，感谢他们哪怕是心里并不服气，但仍然宽宏大度，一贯支持。
我还要感谢目前Adobe公司的同事。我们这个组都是做技术推广工作的。我们的第一次内部会议考验的是每个人的音量。我特别想感谢我的顶头上司Kevin Hoyt，感谢他提出的中肯建议。Ryan Stewart则是灵感、斗志和鼓舞的源泉。Adam Lehman对我帮助很大，也是和我斗嘴的好搭档。Ben Forta是我最初的榜样，他让我知道自己必须站出来说服大家去争取更大更好的成绩。
Avish Parashar是我身边的老师，他告诉我怎么讲话、站立以及倾听。他教会了我先去做了再说。这本书就是这种思维方式的产物，如果没有他，就不会有这本书。
老爸、老妈，还有Casey，谢谢你们撑起了这个家，在这个家里，通过学习提升自己是一种高尚的行为。Jack还有Ellie，给你们换尿布、喂奶，哄你们笑，让我觉得这辈子都值得了。
最后，我要把最重量级的感谢送给我的贤妻Janice。你从来都不怀疑我能做任何事。你对我的这种信心感染了我。谢谢你相信我可以做到。如果不是为了你，我还真做不到。
第一部分导言
本部分内容● 第1章 为什么写这本书● 第2章 开宗明义● 第3章 解决正确的问题
第1章为什么写这本书
我曾经在一家非常有代表性的公司上班，时不时和一群非常有代表性的人在一起，开那么一次非常有代表性的会议。我掌管着公司的Web应用服务器。工作职责包括维护软硬件、推行最佳实践，说服人们不断做技术升级。我一直都忙着想办法让人们升级。
事实上，会议的主题就是升级。“我想让你们给我一个从ColdFusion 6迁移到ColdFusion 8的时间表。”我说。这已经是第五次在类似会议上给他们下最后通牒了。
不出所料，有人叹了口气说：“我们不能迁移到新服务器。每次把应用迁移到新服务器都会遇到麻烦和不兼容的问题。我们就是不想再给用户添麻烦了。”
我还击道：“这个问题很正常。你们想过在切换版本的过程中，使用单元测试来验证新版本的优势吗？并不是只有应用服务器存在这个问题，Web服务器、数据库服务器，还有你们的基础代码都存在这个问题。版本升级是谁也逃避不了的。你们可以使用单元测试嘛。”
然后，各种借口都涌过来了，“升级会占用太多时间。”“为什么这件事非做不可呢？”“我们不知道怎么做单元测试。”
我可以告诉你，我是在跟他们辩论。我还可以把辩论的情形描述得更详细一些。但那又有什么用呢？结果是明摆着的，我没有把他们争取过来，我始终无法说服他们。
在从事那项工作的时间里，我得想方设法地说服人们在某方面加以改进或采取某种新技术。刚才描述的争论场面以及类似的情景，我经历了很多很多次了。我输掉了大部分争论，也赢了一些，有些争论到最后终于两败俱伤。不过，我倒是总结出了一些模式：● 同一类人所持观点相同；● 有些人始终都乐于接受新事物；● 另一些人则在别人转变之后才肯改进；● 有些人你永远也说服不了；● 某些观点对有些人有用对另一些人没用；● 有时候让管理层插手是让人们服从的唯一方法。
总结出以上模式之后，我又据以做了很多笔记，明白了某些策略只对部分人有用，永远不能一概而论。然后，我基于不同问题针对同一批怀疑者采取了相同的战术。成功率节节攀升，说服人们有所改进变得简单了。
本书的主要内容就是这些改进、模式，以及争论。但愿我的经验能成为读者的前车之鉴，让大家能够避免不会有结果的争吵，减少挫折感，真正推动组织的技术进步。1.1 本书组织方式
这是一本讲模式的书。换句话说，本书的主题将围绕一系列重复的形式，也就是模式展开。本书两个主要部分各自包含一组模式，其中一部分模式适用于怀疑者，着重分析某些人抵制的原因。另一部分主要谈方法论，包含一套可以用来反击怀疑者的方法和技巧。如此一来，本书这两部分中各章的结构自然也就极为明晰了。
除了讨论你的同事以及如何对付他们的有关模式的这两部分之外，本书最后一部分将把焦点从模式转移到策略。策略能排序出要先说服谁，不要招惹谁，以及如何真正推动技术进步。1.2 为什么要看这本书
本书的目标是使你能够说服自己的同事采用新工具和新技术。为了达到这个目的，你不必像政客一样在办公室里玩阴谋诡计。当然，我可不是说不需要讲策略，只不过用不着那么邪恶罢了。
这本书要牵扯到一大批人物，其中一些人会让你觉得似曾相识——哎，这不就是那谁吗！好，只要你能让现实当中的某个人与书中的人物对号入座，就可以在本书中找到对付他们的方法。对那些怀疑者使用这些方法应该讲究策略，这些本书都会向你一一道来。然后，变化就会魔法般地发生了。
好吧，哪能靠什么魔法啊！你还得靠自己的工作和努力。只不过现在你的目标明确了。看完这本书，相信你一定会有相见恨晚的感觉。而只要你依照本书的策略行事，随着经验的增长，更多的好处还在后面等着你呢。1.3 本书目标读者
本书的目标读者是搞技术的人，比如开发人员或者程序员。具体来说，可以是服务器管理员、网络工程师或硬件工程师，抑或数据库管理员，甚至是与技术人员协同工作的设计师。
至于你到底搞什么技术，其实并不重要。只要你掌握某种技术，需要与别人沟通，这本书都适合你看。
本书要讲的故事和描述的情景主要涉及开发人员。非常抱歉，我本人就是一名开发人员。但实际上，无论你使用什么工具、什么语言，都没有问题。说到底，不管你是.NET程序员、搞Java开发的，还是开源的拥趸，或者对某家公司的技术情有独钟，都不影响你看这本书。这本书要讲的就是怎么让你的同事改变他们的工作方式，至于改变成哪种方式，那是你自己的事。第2章开宗明义
本书讨论如何向怀疑者推销业内发展成果。在讨论这个问题之前，我想还是有必要解释一下前面这句话，为此要回答以下问题。● 什么是业内发展成果？● 怀疑者指的是谁？● 为什么需要推销？2.1 什么是业内发展成果
业内发展成果包括各种工具和技术，使用这些工具和技术可以让你的开发更富有成效，让你的产品更不容易蒙受损失，让你的代码更容易被自己的搭档理解。这个定义涵盖面比较广，因此还需要具体解释一下。
说到提高工作效率，人们往往会首先想到自动化和代码生成，这两种技术都能让你在相对短的时间内产出更多代码。实际上，语言本身也有效率的差异。如果换一种语言就可以用更少的代码实现更多功能，那这也算。虽然可能会引发争议，但我个人还是认为：选一款得心应手的操作系统，也将提高你的工作效率。
至于降低受损害的风险，恐怕头等大事就要数源代码管理了。今天，要是没有进行某种形式的源代码管理，你就不会有安全感。可光有源代码管理还不够。你还得通过单元测试来降低Bug的威胁，就像做UI测试一样。代码评审也可以提高安全系数。总之，只要是能让你晚上睡觉睡得更安稳，或者说即使哪个人意外离职也不会影响开发正常进行的技术，都算是可以降低损害的。
最后，我们经常忽视让团队成员之间更好地沟通的价值。想一想，那些关于写注释、用制表键，还有如何命名变量的争论，归根结底都是缺乏沟通的表现。让其他开发人员轻松看懂你的代码可不是件小事。这里边可能意味着要遵守公司的编码约定，或者要使用某个代码框架。但无论如何，专业的开发人员都必须熟练掌握类似的工具，因此这也算一条。
千万不要因为我没有列举某种工具或技术，就认为它不包含在内。要是你有疑问，可以这样想：它有没有提高我的工作效率，降低我的风险，或者增进我与他人的理解？如果答案是肯定的，那这种工具和技术就是我们所说的业内发展成果。2.2 怀疑者指的是谁
所谓怀疑者，基本上就是你的同事，他们没有使用你希望他们使用的工具或技术。至于为什么不用，有些人属于不知情，有些人属于不在乎，而有些人则是知道但拒绝使用。怀疑者是有模式之分的，后面我们将会详细讨论各种怀疑模式。
关于这些怀疑者，最重要的是要搞清楚为什么他们还没有使用某种技术，以及为什么他们会对我们的好意不屑一顾。原因很多，有技术上的，有出于小团体利益考虑的，甚至还有个人好恶的因素。（有点匪夷所思吧？）为此，最关键的是要站在他们的立场上，找到他们之所以怀疑的思想根源。
在这里，我特意挑选了“怀疑者”这么个词，而不是感情色彩更浓的不识好歹的人、鼠目寸光的人、心怀敌意的人，甚至你能想到的更激烈的词汇。在身心俱疲的时候，我们很容易把他们当成赛场上的对手、反对派，甚至是敌对分子。偶尔这么想一想倒也能让自己发泄发泄，但千万不能陷入这种思维定式。他们都是你的同事、你的朋友，也许你过去还对他们中的某个人扮演过类似的角色呢。这一点可是不能忽视的。2.3 为什么需要推销
推销这个词通常是指让人们为了得到某件东西而付钱给你。而说到推销业内发展成果，大多数情况下意味着要让人们付出另外一种代价。这种代价就是时间和精力，即让人们投入时间和精力去学习新东西。而投入时间和精力到底能得到什么回报，有时候人们并不理解，尤其在他们正被手头的工具折腾得疲于奔命而又徒劳无功的情况下，就更不容易理解了。在疲于奔命的状态下，他们很难后退一步、更全面地去看问题：他们是在浪费时间，原因就是使用的方法和工具太不给力。
除了时间和精力，有时候还需要一些不太好说清楚的投入。程序员是喜欢拿语言来给自己贴标签的：“我是Java程序员。”或者说：“我是一个.NET程序员。”要让一个Java程序员使用Ruby，可远远不是光让他们花时间那么简单，还涉及他们对自己的重新定位问题，哪怕只是调整一点点。如果是让他们切换OS平台，那麻烦恐怕就更大得不得了了。
还有可能是其他更加说不清道不明的东西。当人们认为自己在某个领域已经可以“一览众山小”的时候，这些东西就会出现。比如说，不用再看参考文档的时候，或者在某个领域里已经摸爬滚打了10年之久了，也可能是拿到一个更高的学位之后。总之，会有一个标志性的事件作为转折点，过了这个转折点，有些人就会觉得自己无所不知了。你说的明明是：“某某技术也许能改进他们的方法。”他们听到的却是：“我认为你错了。”如果他们现在错了，大概过去这几年他们就一直那么错着。这顶大帽子，就算是最明白、最开通的人，恐怕也是轻易不能接受的，因为你不仅在混淆他们的身份，同时也在伤害他们的自尊。
上述种种迹象表明，你并不仅仅是想让他们掏点钱就完事了。你想让他们付出时间、精力、身份转换，乃至牺牲尊严的代价。这些东西哪一样都比钱更有价值。如果说为了得到钱必须得推销的话，那么为了得到这些东西，你推销的难度就会更大。
好了，现在你对工具和技术相关的问题已经有了明确的认识了。你知道了业内发展成果的含义，知道了自己工作的对象，也知道了为什么需要推销。但是，还有一个问题也不能不考虑：能不能一上来就推销你的工具和技术呢？下一章我们帮你分析这个问题。第3章解决正确的问题
在采取行动说服别人接受我们的方案之前，必须问自己一个非常重要的问题：我们是在解决问题，还是在推行方案？如果是解决问题，那很好；因为对于团队来说，你是在治病救人。如果是推行方案，那最多只是一种中立的情况，通常不会有人欢迎。然而，实际上推行方案的情况却屡见不鲜。这又是为什么呢？
当你发现了解决方案，为之兴奋莫名之时，往往就会忽略一点，即你的目的是要解决问题。而且你还忘了大多数问题都不止有一个解决方案。结果，你专心致志地推行自己的解决方案，而这个解决方案可能并不适合要解决的特定问题。尽管你推荐的工具确实也是解决问题的一个途径，但从团队的技术氛围、能力组合以及组织策略这几方面综合来看，很可能还有更好的方案可供选择。
就像我们说服别人时不希望人家固执己见一样，我们自己也要持开放的态度。为此，就必须保证自己的解决方案真的合适，再也找不到其他更好的方案了。只有这样你才有可能放弃自己偏爱的方案，信心十足地去推行最适合团队的方案。Rails 开路Chris是Java开发人员，但突然间红遍社区的Ruby让他移情别恋了。Ruby on Rails①那个“10分钟构建博客”的演示，让他着了魔似地迷上了Ruby。他爱死Ruby了。Rails真的让他工作效率倍增。他迫不急待地想让自己使用Java的同事们都赶紧试一试。① Rails是一个使用Ruby语言的快速Web应用开发框架。要了解更多信息，请参考Agile Web Development with Rails, 3rd Edition[RTH08]。他的同事们也确实需要Rails。大家一直在使用公司自己开发的框架逐个逐个地写应用，但使用那个框架必须做很多琐碎的工作。结果，很多时间都花在了编写重复的代码上，而花在设计界面或可持续的模型上面的时间却少得可怜。他刚一跟大家提出这件事，就有很多人抵制。没有人想学习一门新语言，或者一个新框架。有人已经向他们灌输了一些关于Ruby的FUD②，他们认为使用基架（scaffolding)固然好，可就是为了使用它必须新学一门语言，这代价有点太高了。② FUD，即Fear（害怕）、Uncertainty（不确定性）和Doubt（怀疑）；详见第17章的解释。Chris问了一圈，发现团队中不少人或多或少都关注过Groovy。Chris知道有个Grails项目，他又花了一些时间熟悉Grails。有Java和Rails经验，学习Grails并不难。他又劝说大家来了，但这次推销的是Grails③。以前因为Ruby FUD而心存畏惧的怀疑派不见了，语言的问题已经不存在了。唯一的问题就是要学习一个新框架。对于这个问题，团队成员认为基架能提高工作效率，还是值得尝试的。③ Grails是一个类似于Rails的快速Web应用框架，但使用的是Groovy语言。要了解更多信息，请参考Getting Started with Grails[Rud07]。他们接下来的项目就是使用Grails开发的，现在，这个团队已经离不开Grails了。
这个例子表明，Chris曾经想要兜售Ruby on Rails。而他们团队面临的问题是需要找到一种方法，既能提高工作效率降低劳动强度，又可以把精力主要集中到真正创造价值的地方。Ruby on Rails只是解决这个问题的众多方案之一。重写公司自己开发的框架，增加代码生成功能，或者找一个能简化数据建模的IDE，乃至使用Grails，这些都是可能的解决方案。为此关键是要迈出下一步——寻找其他方案，然后客观地权衡利弊。3.1 为什么要布道
之所以说要在推销方案前先努力想清楚问题所在，主要的原因有以下几个：● 这样做可以先让自己弄明白到底是不是真的存在问题；● 这样做可以强制你站在听众的角度来思考问题；● 这样做可以让你拿出最适合听众的解决方案。
甚至，你都得问问自己，到底有没有需要解决的问题？在前面那个小故事里，确实还真有一个问题。也可能那个项目团队已经在用Grails了。如果遇到这种情况，你就必须扪心自问，Ruby on Rails能给那个团队带来些什么？说实在的，技术平台移迁就算花钱也花不了太多。此时此刻，最要紧是得搞明白，你是真的想帮团队成员提升工作效率呢，还是只是希望说服别人跟你一样成为某种新技术的粉丝。只有确定真的有问题，才能弄清楚是什么问题，以及这个问题是否值得解决。
确定了真的存在问题之后，接下来就要考虑它是否值得解决，或者说值得你的团队兴师动众的到底是什么。也许团队要做的事太多了，也许他们只不过要将这些难题都推给那些新成员，想让新成员在实践中得到锻炼；那些老资格的人则专注于模型和UI。在这种情况下，这个团队的解决方案反倒比你所预测的更有价值。你必须给自己推销方案换个更合适的理由，同时还必须考虑到，假如把难题解决了，那些失去锻炼机会的新成员又该怎么办。
此外，在问题存在一个现成解决方案的情形下，还必须清楚你要推行的是不是一个定制的方案。无论是干裁缝，还是在IT行业，定制的产品总是能要到更高的价钱。原因其实都一样，定制的方案是“量体裁衣”，本身就已经埋下了成功的种子。为团队专门量身打造一套合适的方案，可以减少推行过程中的摩擦，或者一些磕磕绊绊。3.2 考虑方案
要解决正确的问题，最困难的莫过于把目光从自己最倾心的方案转移到其他方案了。为此，必须要有兼容并包的胸怀，勇于放弃先入为主的成见。做到以下几点，会更容易克服这个困难。3.2.1 研究问题
对于要解决的问题，参考一下其他组织的解决方案。在寻找解决方案时，记住要从问题出发，而不要从特定的实现方法出发。
具体来说，要寻找：● 源代码控制工具，而不是SVN；● 快速应用程序开发手段，而不是Ruby on Rails；● 富Internet应用开发框架，而不是Flex；● 对象关系映射库，而不是Hibernate。
但有时候要做到这一点是不可能的。问题很明确，但就是找不到相应的解决方案。怎么办？可以考虑另一种技术方案，比如：● OS X中类似Visual Studio的工具；● Exchange的开源版本；● Linux中的Safari。3.2.2 摸底调查
接下来要做的就是对团队的技术能力和思想倾向做一次摸底调查。像前面故事中的Chris那样，找几个人聊一聊。看看大家了解什么情况，对问题有什么看法。在此期间，可以验证你的一些猜疑，或者，找到一种完全不同的解决问题的途径。不管怎么样，即使摸底调查没有给你带来什么灵感，但至少可以通过谈话了解人们当前的困惑程度，知道他们可能接受你提出的什么解决方案。3.2.3 开列清单
强迫自己列出各种可能的替代方案，就算不是太好也不要紧。总之，你得把自己调研过的那些方案一一地列出来，以便自己参考。如果你跟别人说：“没有别的替代方案。”人家不会相信你。你可以说自己的方案无与伦比，但却不太可能说它是唯一的解决之道。替代方案始终都会有的，即使你到头来不会采用，但至少还得考虑它们。
况且，列出替代方案反而有助于证明你的观点更有吸引力。开列清单本身就说明你研究过了，也精心准备过了，绝非随随便便地碰上一个算一个。总之，能够让你的听众们感觉眼前一亮。3.3 面临的挑战
这时候的主要挑战就是做不到真正客观地考虑替代方案。越是公平公正地对待替代方案，就越能像第14章概括的那样充满战斗激情，你的心胸也就会更加宽广，掉进这个陷阱的可能性就越低。
另一个困难是这个过程需要耗费时间。如果公司需要你尽快拿出方案来，那恐怕你来不及充分调研。不过，这种风险比较低，因为只要你能说明白尚未确定哪个方案更好，大多数组织都会在全面实施新方案以前选择维持现状。3.4 几点建议
假如你在评估替代方案的时候遇到了麻烦，可以试一试下面几条建议。● 在拿出你的解决方案之前，先做一番研究，看看那些创建方
案的人是想用它解决什么问题。● 学习一种能替代你的解决方案的技术。不一定非要成为该技
术的专家，但至少要能搞明白替代方案是怎么回事。● 扮演怀疑者的角色。想象一下你很反感这个解决方案，因此
想要竭尽所能来阻止公司实施这个方案。你反对的理由是什么？
然后再想一想，现实当中是不是真有这种合乎常理的因素。
显然，你应该让自己推动的解决方案能够适合公司并真正对公司有帮助，但实际上很多人做不到这一点，并且还遭受了不应有的苦难。在我们这个行业里，由于决策者自己陷入困境而没有找准要解决的问题，导致项目成员度日如年的例子已经太多了。亲爱的读者，你千万不要做这种人，一定要推行那些真正对组织有用的技术和工具。这样不仅会让自己更容易达成目标，更重要的是，你在做正确的事。第二部分怀疑者模式
本部分内容● 第4章 了解身边的人● 第5章 孤陋寡闻型● 第6章 随波逐流型● 第7章 百般挑剔型● 第8章 激情燃尽型● 第9章 时间紧迫型● 第10章 发号施令型● 第11章 不可理喻型第4章了解身边的人
接下来的几章我们介绍几个模式，也就是那些质疑技术变革的人可以归入的类别。通过了解这些模式，你就可以分辨出自己身边的人有谁属于这些模式。
知道了要跟谁打交道，才能找出与其打交道的方法。后面，我们还会针对这些怀疑者模式给出一系列应对的技巧。不过首先，必须得知道他们是谁。
我们要介绍的怀疑者模式包括：● 孤陋寡闻型（uninformed）；● 随波逐流型（herd）；● 百般挑剔型（cynic）；● 激情燃尽型（burned）；● 时间紧迫型（time crunched）；● 发号施令型（boss）；● 不可理喻型（irrational）。
一开始，要弄清楚谁属于哪种模式恐怕有点困难。看着每种模式的说明，你心里可能会嘀咕：“George有点喜欢挑刺儿，可他还没有那么离谱。”这说明George属于百般挑剔型，但还不严重。本书中描绘的这些模式，多少都有点演绎，因为我们只是想说明问题。这里面最关键的是要看有没有那种行为，而不是看行为的严重程度。在现实当中，相信大多数人都会比较专业，不会像我们这里给出的有些夸张的例子中所描述的那样。
同样，也不要为了确定某个人到底属于百般挑剔型还是激情燃尽型而死盯着细节不放。每个人都有可能同时属于不止一个怀疑者模式，这很正常。比如，发号施令型和时间紧迫型的特点经常会在同一个人身上体现出来。对一种技术漠不关心而百般挑剔的人们，对另一种技术而言，往往又是激情燃尽型的。这是一件好事，因为这样一来，大多数怀疑者模式都会有一些通用的制胜技巧。对这些多重类型的怀疑者，可以集中应用通用技巧，而不必费额外的工夫。
假如你觉得这些类型的人实在不好区分，可以参考如下提示：● 孤陋寡闻型的人不可能同时是激情燃尽型的人；● 大多数人多少都有一点时间紧迫症；● 很难把随波逐流的人定性为怀疑者；● 不可理喻型的人经常会伪装成其他怀疑者。
好吧，现在就来看看我们身边这些每天都会见面的、普普通通的怀疑者。第5章孤陋寡闻型
周五晚上六点钟，你在帮一位同事的忙，他的硬盘昨天坏了。他已经重装了机器，也恢复了备份，可他周三、周四干的那些活儿都丢了——其中还包括修复一些Bug的重要代码。你提醒他，这些代码是可以从源代码控制服务器上取回来的。他反问道：“什么是源代码控制？”
可想而知，他没有使用源代码控制；事实上他根本就没有听说过源代码控制。他见过你发的那些关于新Subversion①服务器的邮件，可见过并不等于就看过啊。 他们并不认为Subversion服务器是自己应该关心的事儿。①Subversion是一个集中式的版本控制系统。要了解更多信息，请参考Pragmatic Version Control using Subversion, 2nd Edition[Mas06]。
那些口口声声“无知是福”的人，从来不知道在周五晚上七点，绞尽脑汁把从备份中恢复的内容与一个名叫“main–copy20070811”的文件夹对应起来是一种什么滋味。而我们呢，我们知道无知并不是福。我们要聆听自己同事的抱怨，因为“办公专家应该知道怎么不让他们犯那么愚蠢的错误”，然后忙到晚上九点回家。5.1 他们为什么不用这种技术
原因通常是他们不了解这种技术。有些人是从来就没有听说过，而有些人可能知道有这种技术，但不清楚它能解决什么问题。更重要的是，他们并没有意识到自己就有要用这种技术解决的问题。
不管是什么原因，总之就是他们有需求，但自己却浑然不觉。5.2 深层次原因
人们不了解某种技术的原因有很多。并不是所有人都会看博客，跟踪行业最佳实践，由此造成的无知有时候是有意为之的结果。某些人是地地道道的“朝九晚五”式上班族，他们不在乎提高自己的技能。不过，更多时候恐怕还要归咎于我们这个行业。这个行业中的信息多得令人目不暇接，除非你有目的地去找，否则不可能什么都知道。5.3 有效的应对策略
孤陋寡闻型的人一般不会“自己走向山”，因此你必须“把山唤到他面前”。①对付孤陋寡闻型的人，最有效的策略就是给他们提供信息，以下几章都有介绍：① 这句话源自穆罕默德唤山的故事。先知穆罕默德，带着他的四十门徒在山谷里讲道，他说，“信心”是成就任何事物的关键。一位门徒对他说：“你有信心，你能让那座山过来，让我们站在山顶吗？”穆罕默德对他的门徒满怀信心地把头一点，对山大喊一声：“山，你过来！”山谷里响起了他的回声，回声终于消失，山谷又归宁静。大家都聚精会神地望着那座山，穆罕默德说：“山不过来，我们过去吧！”他们开始爬山，经过一番努力，到了山顶，他们因信心使希望实现而欢呼。这是人们熟知的一个典故。山并没有过来，穆罕默德却翻过了那道山。这个典故提示人们，在改变不了客观环境的时候，人要改变自己的主观信念。唤山不来，可以走向山。——译者注（摘自网络）● 第13章，“取得经验”；● 第14章，“传达理念”；● 第3章，“解决正确的问题”；● 第15章，“展示技术”；● 第18章，“公之于众”。5.4 几句忠告
首先说好消息：把孤陋寡闻型的人转变为其他怀疑者模式的人极其容易。所要做的，无非就是告诉他们这种技术——唰地一下，他们就不再孤陋寡闻了。说说坏消息吧：他们很可能会皈依别的怀疑者模式，而不是被你说服。
为此，我不会指望跟他们坐下来，聊聊什么是版本控制或单元测试就让他们心服口服。除此之外，必须要使用反击手段，尤其是“展示技术”。不仅要向这些人解释清楚这是一种什么样的技术，更要摆出采用这种技术的理由。第6章随波逐流型
今天是代码评审的日子。花费大量时间翻阅了整整200页打印出来的代码之后，你发现其中大部分都是常规性的CRUD①代码，完全可以拿一些通用对象或某种ORM②方案取而代之。你可以预见，在代码评审中提出重大改进意见将带来激烈的争吵。① 表示Create、Read、Update和Delete（创建、读取、更新和删除）。这四种操作在任何使用数据库的应用中都是最基本的。② 即Object Relational Mapping（对象关系映射），是一种在面向对象系统中将数据记录映射为数据库对象的技术。
这是Hector与团队合作的第一个重要应用。他刚刚走出校门不久，而这是他为公司开发出的第一个重要成果。评审会一开始，Hector就有点如坐针毡，而你担心的是在告诉他“用几个通用对象就可以减少75%的代码”之后，他会有什么反应。
这一刻到来了，你就在他对面。然而，没有生气，没有争吵，也没有怒发冲冠掀翻桌子，他只是那么直勾勾地看着你，说：“我可以那样做吗？当时我也想过，可我不知道你们会同意我那么做。”他的回答令人震撼，你怀疑自己是不是听错了：居然有人明知道怎么做才是对的，但还是按照自己觉得不好的方式去写代码，浪费时间！这种现象在普通开发人员中是相当普遍的。6.1 深层次原因
随波逐流型的人之所以随波逐流，因为他们的身份是追随者，而不是领导者。对于一个组织来说，保持领导者与追随者之间的平衡至关重要。领导太多，组织的发展反而会举步维艰。为什么？每个领导都希望团队去实现自己的思路。不过在实际当中，还是追随者太多而领导者太少的情况更为常见。在这种情况下，前面故事中提到的情景就会出现。说来也怪，随波逐流型的人虽然通常是追随者，但他们有时候也会成为团队的领导，结果当然无所建树了。
随波逐流型的人，也分为两种：● 不知道自己有领导能力的人；● 不以当领导为目标的人。
不知道自己可以当领导的人一般来讲都比较年轻。他们走上工作岗位的时间不长，缺乏自我激励的人生经验。这些人很有想法，也愿意去尝试新鲜的事物，可他们尚未领会到做领导的要诀：只要有人提拔，你就可以做领导，但能否成为领袖，却不是由别人说了算的。
不以当领导为目标的人经常会受到激进程序员的鄙视。这些人朝九晚五，循规蹈矩，靠工作维持生活，只在上班时间工作，下班回家就一心扑在自己的其他追求上：家庭、爱好、社区，等等。他们不会主动意识到一直学习最新技术有什么好处。6.2 有效的应对策略
随波逐流型的人不会主动寻求领导的帮助。你必须主动找他们，向他们提要求。激励他们进步的手段会有效果，但十分有限，而某些强制性措施或许对他们更好使。而且，随波逐流型的人不会对强制他们进步有抵触情绪，这一点与其他类型的人有所不同。他们愿意被人领导。因此对这种类型的人有效的策略很多。以下各章都给出了针对随波逐流型的人的一些有效策略：● 第13章，“取得经验”；● 第15章，“展示技术”；● 第21章，“来点刺激”；● 第20章，“搭一座桥”；● 第18章，“公之于众”。6.3 几句忠告
随波逐流型的人是第二容易被说服的类型。基本上就是你带领他们，他们跟在你后面。虽然简单但仍然要付出努力，你必须得运用自己的领导力。看起来这点代价算不了什么，也很直截了当，但领导工作会使人烦躁不安。举个例子，可以把这种工作当成维护应用程序。相对于构建应用程序来说，维护应用程序的代价总是要高得多。不间断的领导工作或做思想工作的过程，需要付出比刚开始说服他们多得多的努力。我并不是想打消你的积极性，只想提醒你做好这件事也不容易。当然，要是你能发现并简拔几位年轻人加入你的队伍，这份投资还是相当划算的。第7章百般挑剔型
你刚刚给自己的团队作了一场20分钟的展示，关于源代码控制。是，他们根本就没有做源代码控制。没错，就是一丁点儿都没有，似乎近20年来计算机科学就从未有过任何发展成果。不过，晚采用总比不采用好，更何况只要做源代码控制，就比不做好，因为一次误删就可能酿成灾难。你已经做了充足的准备，而且自己也反复测试过了。一个方案不理想，接着再试验下一个方案。试验来试验去，考虑到当前这个特定的用户群、方案的成熟度、工具的易于获取，以及行业的认可度，最终你还是觉得Subversion合适。不管怎样，你的方案已经讲完了，现在该回答别人的问题了。“我听说Subversion已经不怎么流行了，随着Git正逐渐成为源代码控制领域的下一个焦点，难道我们选择Subversion就是为了先撑两年吗？”Cindy问。
对此你已经胸有成竹：“问得好，Cindy。我比较了很多方案，也包括Git。最关键的是，我们这个小组需要能够集成到Eclipse的工具。我个人认为针对Eclipse的Git工具还没有出现。一两年以后也许会有，但我们对解决方案的需求是迫在眉睫的。因此，目前对我们而言，Subversion就是一个合适的解决方案。假如我们真的需要Git那样的功能，也有很多工具可以从Subversion迁移到Git，所以我并不担心这个问题。”
你想当然地认为，如此滔滔不绝地讲完之后，这个问题就算解决了。可就在这时候，Cindy又抛出一个问题来。“我听说Subversion会向项目里添加各种元数据，项目越大，被加入的元数据就越多。而且，我听说这种元数据很容易因为没人管而变成垃圾。”“确实存在这个问题，不过好在我们的项目都不太大，所以也不会有什么严重问题。对于我们那些比较大的项目，很多前人总结的最佳实践都可以参照和借鉴。”你杀了个回马枪。
接着又这么来来回回地过了几招儿。有时候，你能把问题解释清楚，但有时候也说不清楚。有时候，你甚至会想Cindy是不是在维基百科中找到Subversion条目，然后只看了“目前的问题和局限性”一节的内容。要不然，一个从来没有接触过Subversion的人，怎么会知道它的那么多缺点呢？
最后，Cindy用貌似权威的语调宣布：“既然问题这么多，而且我们一直没用它也都过来了，所以我认为没有理由给我们的开发环境增加额外的复杂性。”
在场的其他人也许不完全同意Cindy的这个结论，可他们坐在那看你们俩人打口水仗已经好一会儿了，大家的咖啡可没少喝。你跟Cindy唇枪舌箭，短兵相接，考验了大家的耐心，也考验了他们的膀胱。原本该是一次精彩的技术布道秀，现在反倒闹成了人事斗争。
这样的场面，只要面对百般挑剔的人，就会一次一次上演。7.1 深层次原因
这种行为的原因有很多。有些人可能就是喜欢争论。还有些人喜欢证明自己比别人聪明。再有一些人可能已经在行业里混迹了些年头了，但一直四处碰壁，因而对任何事儿都不会看到其有利的一面。
但是，之所以你会碰到这样一种人，其实还有一个非常重要的原因，那就是：在我们这个行业里，这种行为会有所收获。
我们这个行业之所以能赚到钱，大多数都是建立在人们的想法之上的。聪明固然重要，但比真正聪明更重要的，则是让人觉得聪明。
真正聪明在哪里都可以一显身手，不一定非要当着观众的面去表演，所以也就经常不会被人注意到。实际上，置身众目睽睽之下，思想更容易不集中，反而会影响人的发挥。每次跟某个小组讨论问题之前，你通常都要精心准备一番，正是这个原因。坐在自己私密的小隔间里，你完全可以相信自己到时候能够调动起每一个脑细胞来。可一旦你面对一群人，各种预料不到的情况就会出现，加上自己精神紧张，有时候再碰上坏运气，结果就会导致你无法发挥出自己的全部潜能。苛求是好的，有意挑刺就不好了咬文嚼字可不是件容易的事。对某一个人的有意挑刺，对另一个人而言或许就是尽职调查。我不希望你把百般挑剔的人提出的每一条批评意见都看成是一次攻击。为你选择的工具或技术辩护是你的责任。谁都不应该盲目地接受别人替自己选择的哪怕是正确的道路。然而，我在这里把批评说成是挑错并非为那些不称职的布道者开脱。挑错的意思是指纯粹为了阻挠而阻挠，或者说就是想要给人出难题。这样说应该可以帮你辨别这种类型的人了。实在不行，你还可以参考Potter Stewart在1964年说过的关于猥亵的一句话：“是不是猥亵，我一看便知。”*百般挑剔也是如此，它很难定义，但很容易感觉到；有时候，一些人提出反对意见是为了给所有人争取一个最好的结果，而有时候一些人百般诘难，其实是想逃避自己的进步，或者是以其他人为代价来伪装自己的聪明。* Potter Stewart当时是美国最高法院大法官，在判定一起有关猥亵的案件时，曾说过一段著名的话：“今天，我不会再尝试按照我认为能够理解的方式对这个概念（‘赤裸裸的色情描写’）下定义；也许我永远也找不到一个能让人容易理解的说法。不过，是不是猥亵，我一看便知。”
而另一方面，看起来聪明，则只需要有观众并能给人一种聪明的印象，就不必费力劳神地实际去做出来了。
这跟为数众多的百般挑剔型的人有什么关系呢？有两种方式可以让人看起来聪明：● 在观众面前表现得非常聪明（这一点我们已经说过了，很难做
到）；● 在观众面前表现得比某些人聪明。
第二条比较容易做到，而这也正是百般挑剔型的人最常用的方式。你提出的每一个观点，他都要反驳一下，给你施加压力，以示自己并不比你考虑得少，这样他们看起来就很聪明了。只要从你准备的材料中找出一个弱点来，他们就可以借题发挥，让自己看起来比你厉害。7.2 有效的应对策略
应对百般挑剔型的人，无非两方面：● 让他们少开口，别给他们机会；● 作好充分准备，避免被其驳倒。
让他们少张口，首先就是不能让他们逮着任何提问题的机会。比如，你可以在说话时让自己的语气保持连贯，可以提前设想一些可能的问题，然后在宣讲的过程中自问自答。如果你都已经做好准备，而他们真的提出这个问题，那就先请他们稍安勿躁，告诉他们答案已经在你的资料中。只有这样，你才能控制整个对话的局面，而不致喧宾夺主。
从另一方面讲，准备得再充分也不可能万无一失。谁也不可能想到所有的问题。首先，要用不容置疑的口气来回答他们的问题；就算你不知道怎么回答，也必须非常自信地说出“我不知道”这四个字。然后，要尽量全面了解相关主题的知识，用这些知识来武装自己，不让他们通过出你的洋相而抬高自己的阴谋得逞。
为了能顺利地把以上策略付诸实践，以下这些对付怀疑者的方法也都十分有效：● 第13章，“取得经验”；● 第14章，“传达理念”；● 第 3 章，“解决正确的问题”；● 第15章，“展示技术”；● 第21章，“来点刺激”；● 第18章，“公之于众”；● 第20章，“搭一座桥”。7.3 几句忠告
假设你像前面所说的那样，准备充分而且驳倒了他们，那你通常也会赢得整个组的尊重。通过你的传达方式和专业内容，你的方案也会成为聪明的选择。既然选择这个方案很聪明，那么质疑它的人就会显得不够聪明。在不愿被人看扁的心理压力下，他们自然也就不会再找你的麻烦了。没准，要是你能把自己的方案包装得足够好，他们还能成为你最有力的支持者。第8章激情燃尽型
几位开发人员已经凑成了一个小组，开始制定下一个项目的计划了。此时此刻，正好是说服他们采用某些工具和技术的最佳时机。在公司的某个项目中推广Hibernate可是你一直以来的梦想，而眼下这个项目再合适不过了。这个项目要为一个简单的数据库开发一个巨大的前端管理系统。它足够复杂，完全有使用ORM的必要；同时，它又不是特别复杂，项目团队不会因为它而面临一些想象不到的难题。
你提出了使用Hibernate①的建议。① 针对Java的一个便利的ORM（Object Relational Mapping，对象关系映射）框架。“我以前用过Hibernate……”Bernard响应道。
你简直欣喜若狂；说服这个组已经问题不大了。只要Bernard站在你这一边，那就不用费事了。
Bernard继续说：“太可怕了。整个系统一下子就不动了。除了添乱一点用都没有。要做一次更新，都得从数据库中查出一整条记录，还要外带其他表中有关系的行。这么多工夫实际上却只完成了一条简单的更新语句的工作。所以，对你的好意，我只能说不！”
就像Lucy对Charlie Brown那样，Bernard刚为你点燃了希望之火，随即一口气又把它吹灭了。他的负面评价基本上已经不可能让你对这个组的说服工作再向前迈进一步了——不是因为他说的一定对，而是因为他有经验。他曾经被这种技术伤害过，如今他不想再重温旧梦了。厌倦变化型在刚开始写这本书的时候，我曾考虑过另外一个怀疑者类型，叫厌倦变化型。想来想去，最终还是觉得“厌倦变化”其实就是激情燃尽型。好的变化会让人付出很多，但通常都不至于令人消沉。变化之后人们想的只是休息一下，而不是永远地休息下去。坏的变化会导致人厌倦变化，但更常见的是，坏的变化只会造就让人一眼就能看出来的激情燃尽型的人。激情燃尽型的根本问题在于，他们厌倦变化并不是因为变化的好或坏，而是因为变化除了变化本身之外，什么都不是。于是，他们的激情，没有了往日的温度。假使他们以前没有经历过类似的事情，这会令他们心生厌烦；如果他们已经经历过了类似的事情，那要说服他们将势比登天。不会带来积极结果的变化就是坏的变化，哪怕不是什么灾难，而仅仅只把人搞得哈欠连连。所以，厌倦变化就是激情燃尽，即便是激情慢慢燃尽。8.1 深层次原因
这种类型的人很容易识别。导致他们没有激情的原因，是他们曾经用过你打算推行的工具，但那工具不好使。他们在使用工具时遇到了什么问题？什么问题都有可能。可能是使用了该技术，但进步不大。也可能是因为使用它而导致了严重的挫败。抑或只是安装过，但之后不知道怎么使用它而已。不管是哪种可能的情况，也无论他们尝试的深度，对其他人而言，他们的话都是可信的，因为他们拥有第一手的经验。结果，不仅他们怀疑的态度更容易被人接受，而且也为你反驳平添了不少难度。8.2 有效的应对策略
要想应对激情燃尽型的人，最关键的是要弄明白他们经历过什么事。要是有使用Hibernate的经验，那你就会知道Bernard曾经遇到的问题了。也许，在之前使用Hibernate的时候，有人可能在取得数据时搞错了方式，或者延迟加载弄得不知道哪儿不合适了。这个人可能就是Bernard，也可能是别人，但最终的结果没有什么不同——他们对Hibernate的实现存在严重的缺陷。这个例子本身可能不足以说明一切，但也很有可能Hibernate对之前的项目根本就不合适。试想，选择了不合适的工具，即便配置使用方法都正确，Hibernate也逃脱不了被摒弃的命运。
因此其次，你必须得知道自己建议的方案是不是用得其所。这个工具真的值得你去扭转激情燃尽型的人的成见吗？是否存在一个更好的技术，能让激情燃尽的人更容易接受它，同时还能实现类似的功能？
最后，你要尽力把自己的所思所想讲给激情燃尽型的人听。你得想方设法让他们明白自己从前的实现是有问题的，并且不要涉及会让他们神经紧张的话题。他们必须信任你才行。在与他们沟通交流的过程中，必须小心翼翼地平衡正反两方面的说法。
在这些条件下，可以参考下列技巧：● 第 3 章，“解决正确的问题”；● 第13章，“取得经验”；● 第14章，“传达理念”；● 第15章，“展示技术”；● 第21章，“来点刺激”；● 第18章，“公之于众”；● 第17章，“建立信任”；● 第20章，“搭一座桥”。8.3 几句忠告
要想让这种人完全转变观念是相当困难的。人本来就不太喜欢花时间学习新东西。曾经尝试过的新玩艺，让自己吃到了苦果，而今要再去尝试一遍，怎能不进行激烈的思想斗争呢？有时候选择一项替代性的技术，倒是比较容易驱散人们“重温噩梦”的阴影。不过，经过不懈努力，加上其他人的支持，对于正常的激情燃尽型的人，还是能让他们回心转意的。第9章时间紧迫型
我们继续以第1章中提到的那次会议为例，在那次会上，我在跟其他经理讨论是否需要把应用服务器升级到新版本。
反对的主要原因是他们对代码已经有了自信。如果迁移到另一个服务器上，就得重新测试，重新测试就有可能漏掉Bug，而漏掉Bug又会让他们在客户面前丢脸。我对这个问题给出的解决方案是单元测试，但听到的第一个拒绝的理由就是“单元测试太费时间”。
事实上，我跟这个团队之间的每一次争论，最终都会跑到时间不够用这个老生常谈的话题上来。就算单元测试能缓解该团队面临的许多其他问题，就算单元测试可以很大程度上解决导致时间不够的那些麻烦，他们都无动于衷。这些人思想上存在的问题就是：“没时间去做正确的事，但有时间重复做错误的事。”9.1 深层次原因
说时间不够用的，往往是那些目光短浅、“丢了西瓜捡芝麻”的人，或者那些看不清问题实际成本的人。平心而论，让谁站在那些人的立场上，可能也都很难看清问题所在。但人们多数时候都不愿意改变计划来适应新事物，尤其是在他们对结果心存疑虑的情况下。这样说吧，他们现在的方法可能会浪费时间，但他们清楚地知道会浪费多少时间。而新方法肯定是要花时间去学习的，但付出学习的时间就一定能得到相应的回报吗？不一定。反而有可能会因此拖他们的后腿，导致时间比以前更加紧张。
进一步看，有些人之所以感到时间紧迫，是因为他们的工作量没有足够的资源保证。缺少人手，过度承诺，以及其他形式的计划不周，都是造成这种局面的原因。这些人无时无刻不感到时间紧迫，要想让他们挤出点时间来，真要比登天还难。
另外一些人呢，并不是时刻都感觉到时间紧迫。很多行业的需求都有周期性的特点，他们也会因此忙一阵，闲一阵。就拿美国的高等教育行业来说吧，主要的学期从每年9月份开始，12月份结束。然后会放一小段假，随后就是1月到5月的春季学期。接下来又放一小段假，然后是较短的夏季学期。在学校里开发软件的人，上学期的9月份都是忙得脚不沾地儿的。在冬季假期中，他们也忙于升级。之后，他们会在夏季投入到新项目中。一年中的其他时间，他们只是维护自己的软件或者给软件打一些补丁。向这些人推销新的想法，最合适的时机是他们比较悠闲的时候，而不是他们忙得焦头烂额的时候。换句话说，8月份的时候，向这些时间紧迫型的人推销，一般都能得到他们的积极回应。总之，造成这种局面的原因是他们的工作具有周期性，并非他们的思想有什么问题。
最后，的的确确是有那么一些工作属于对时间要求比较苛刻的类型。按期完成这些工作是最重要的，至于完成工作的方法是不是最合适，就较次要了。有一次，我为本地负责竞选的一个办事处开发软件。他们需要一个最基本的CRUD应用，当时距离“选举日”只有24天。而“选举日”一过，那个应用就没什么用了。对这项工作而言，考虑什么可维护性或者可扩展性，都是多此一举。而要向负责类似工作的人推销这种功能，也只能是枉费心机，徒劳无功。
因此，问题的关键在于搞清楚时间紧迫到底是什么原因造成的：人的思想有问题？你选择的时机不合适？还是那个项目的类型不合适？第一种情况居多。但是，同样也要有这个意识——不要在不恰当的时机，或者向不恰当的人推销，这样会节省你的宝贵时间。9.2 有效的应对策略
要想成功地说服时间紧迫型的人，就得让他们认识到你推销的技术或工具确实能够减轻他们的负担。他们不光要听，还要眼见为实，有时候可能还需要利用其他节省时间的方式打动他们。无论如何，都得让他们相信，只要选择了你推荐的方法，一定能节省出比投入的多的时间。为此，以下几章提到的方法能派上用场：● 第3章，“解决正确的问题”；● 第15章，“展示技术”；● 第16章，“适当妥协”；● 第21章，“来点刺激”；● 第20章，“搭一座桥”；● 第19章，“注重合力”。9.3 几句忠告
没有人想被时间逼着做事。这是一种非常不爽的感觉，时不时地会让人进退维谷。谁不想摆脱这种境地呢？他们可能只是不知道怎么做才好罢了。
不管怎么说，对付这些人，就是要讲条件的。你只要能给他们节省时间，他们就愿意跟你合作。最难的地方就是让他们相信一定能够节省时间。不过，要是真让他们相信了这一点，那他们急于走出时间困境的心理对你就十分有利了。第10章发号施令型
老板让你到她的办公室开个例会。会议一如往常，她讲，你听；你讲，她玩黑莓。你谈了当前正在负责的几个项目，还有那些已经完工的项目。把这些该说的都说了之后，你觉得该跟她谈谈自己那个小项目了。
你自己一直都在搞一个自动化引擎项目，它可以分析数据库，构建CRUD应用，并让这个应用具备公司要求的统一的外观。等创建好这个项目后，你打算花点时间调整一下它的模型，修饰一下它的UI，让这个应用更趋完美。虽然这个辅助应用很简单，但它真的非常棒。
你把这些也跟老板说了，她似乎没听明白，只问你在这上面花了多少工夫了。你如实回答，原来不怎么感兴趣的她，莫名其妙地恼怒起来。她说，你赶紧把这个事儿停下来，别继续做了。然后她就让你走，好跟其他下属开会。
你一下子从信心满满变得垂头丧气，怅然若失地走出老板办公室。以上情景通常会在你向管理者推荐一些专业技术的时候发生。10.1 深层次原因
管理者抗拒专业技术的一个最大的原因，就是他们不理解这些技术。这话可能有点不好听，但实际上他们就是不理解。懂技术不属于他们的职责范围。即使是那些有程序员背景的管理者，只要他们不再做开发工作了，他们就可能会纳闷为什么你会需要那些他们从来用不上的东西。而如果他们在管理的同时还继续做开发，那他们几乎肯定是时间紧迫型的（参见第9章），所以很有可能会对你推荐的技术置若罔闻。这算不诚实吗向管理者推荐技术，最难办的是找到与他们经历类似的场景，然后以他们听得进去的方式跟他们解释。可能有读者会拒绝接受我的这个建议，因为他们认为这听起来像是在骗人或者不诚实。可是，我们日常的行事方式确实是类似这样的。即便是提供服务，收银员也会说“请”和“谢谢”。我们面试的时候一般会穿西装，而实际上大多数程序员都讨厌穿着西装写代码。如果你想到国外旅游，通常会先学几句那个国家的日常用语。简言之，对别人投其所好，并用他们的语言跟他们沟通并不是不诚实，而是务实。在对别人有所求的情形下，必须要能够换位思考，而不是按照自己的意愿行事。至于管理者嘛，我们只不过是向比自己权力更大的人顺从一下而已。想一想这样做的价值
试读结束[说明：试读内容隐藏了图片]