职权不是决定因素
绝大多数工程师对于变革有种无力感。这种无力感源于这样的想法：我不是管理人员，没有足够的职权，无法改变自己的组织。当这种感觉足够强烈的时候，它作带来的挫败感会使我们失去进一步行动的能力。
然而这种无力感无论是中层管理者、执行副总裁甚至首席执行官都会存在。论及变革，没人具有足够的权力。这是因为变革中最核心的问题不是改变组织的结构、战略或文化，而是改变人的行为与意愿——改变人的工作方式以及在工作中所关心的内容。 职权的确会让某些事情变得容易，有些大范围的变革还必须巧妙借助职权的力量——比如涉及组织结构调整的改变，但它不一定是变革成功的决定因素。
从2007年开始，国内很多软件企业开始尝试采用敏捷方法，其中不乏有中高层领导以行政命令推行敏捷方法的做法。我曾经在敏捷中国大会上碰到一位朋友，他跟我讲了他们公司的故事：他们公司里负责研发副总裁听说了敏捷方法之后，对于测试驱动开发非常感兴趣，认为这是提高软件质量的好方法。于是在公司内要求所有的研发人员都必须要开始采用测试驱动的方法进行编程，并制定了相应的考核制度。而最后的结果是，研发人员为了应对考核指标，写了很多无用的测试，花了额外的时间不说，对软件质量的提高并没能带来实质性的帮助。最后纵使在报告上有不错的测试覆盖率统计，绝大多数人——包括那位研发副总裁自己——都不认为这次变革是成功的，因为人们的工作方式和内容并没有真正地发生改变：他们并没有变得更注重质量，也没有采用自动化的方式来保证软件质量不受破坏。
比起职权我们更应该学会影响他人，驱动他们在行为上发生改变 。无论是否具有职权，成功地驱动变革都不是件容易的事情。拥有职权仍然需要小心使其发挥作用，没有它也不意味着我们完全被束缚了手脚，不能采取任何行动。关于职权在变革中的作用我们将在下一章讨论，在那之前首先需要讨论的是成功驱动变革的核心因素——如何驱使行为改变。
什么可以带来行为的改变？
有一种可以带来行为改变的方法，其主要模式可以表述为“分析—思考—改变”：
- 针对特定问题向人们展示数据或者分析结果；
- 通过数据或者分析的论证影响他们的思考方式；
- 借由新的思维方式带来行为模式的改变。
这种方式天然受到工程师的喜爱。作为工程师，我们接受过严格的逻辑思维训练。我们相信数据以及理性的分析，并愿意根据分析结果调整自己的行为。我们理所当然地认为这是最合乎情理也是最客观理性的方法。不过令人意外的是，变革管理大师John P. Kotter的研究表明，“分析—思考—改变” 这种方式很少能真的发挥效果。他说对于“只对数据感兴趣的工程师”可能会有效果，但以我个人的经验来说，哪怕是对工程师，这招也没那么管用。
理智的局限
工程上的很多问题我们虽然知道优劣之分，但是难以量化和度量。比如Ruby到底比Java和.NET在研发效率上快多少？RESTful的架构风格比SOA（Service Oriented Architecture）在开放性和扩展性上好多少？采用结对编程的方式和不采用结对编程的方式在代码质量上有多少提高？我们明确地知道Ruby比Java和.NET的开发效率高、RESTful比SOA有更好的弹性、结对编程产出的代码质量更好，但是一旦论及多少和数量，却不是那么容易能够给出明确的答案。
那么我们要如何改变Java和.NET程序员的思维，让他们认为Ruby是值得尝试的？要如何改变具有多年SOA经验的架构师的思维，让他们相信RESTful是更好的选择？要如何改变从没有结对经验的项目经理，让他们理解结对并不是浪费时间和金钱呢？
此外，分析结果对人们思维的改变，远没有达到我们想象的那种程度。哈佛大学商学院Andrew McAfee教授富有洞鉴地指出：我们通常会高估新技术带来的效果和影响，大约三倍，而低估已有技术和方法的效能，大约也是三倍，只有在新旧技术相差十倍的时候，我们才会有明显的改变意愿。换句话说，如果我们希望发生的改变没有在某方面带来十倍以上的提升，人们的思考方式不会因为我们的分析而发生明显的变化。所以当你希望重构代码结构以获得更好的架构时，当你希望更换不同的数据库以获得更好的开发效率时，通常不会受到特别热烈的响应——这些改变虽好，但是远没有十倍以上的差距。
最后，也是最重要的，分析结果的确能够改变人的思维，但却很少能够有效地改变人的行为方式。比起思维，情感更能驱动人们作出行为的改变，而很少有分析结果能真正地打动人心，建立情感上的纽带。
几年前在推广Ruby的时候，我和几位同事组织过厦门Ruby用户组，期间我分享过一个主题：从面向对象技术发展的历史来看，为什么Ruby是更好的面对象语言。会后有位朋友私下找我沟通，他说：“从你提供的资料和分析，我或许相信Ruby这门语言有它的根源和发展；但是我实在无法想象在企业应用的开始中去使用它，因为我是企业级Java开发人员啊。”
这番话很有代表意义，Java对于这位朋友而言，与自我认知有关。他和Java有更深的感情联系——这是定义我的角色和身份的技术。所以他虽然能在思维上认可我给出的资料和分析，却很难真的作出改变。
感受带来改变
那么什么才是带来行为改变更有效的方法呢？答案是：目睹—感受—改变。
照John P.Kotter的话讲，这是“大多数在变革中取得成功的组织都会采用模式”。其模式可表述为：目睹是指通过一些戏剧性的、引人注意的情景或可视化展示（visualization）来帮助人们发现问题；在看到问题之后，引发人们情绪和感受上的冲击，让他们开始从内心深处作出反映，削弱那些阻碍变革的情绪，比如自满、愤怒、怀疑或恐惧。增加紧迫感、乐观或者信任等有益于变革的情绪；这些正向情绪开始改变原有的行为，或者强化新的行为模式。
这种模式常常会产生较深远的影响，除了能够带来行为改变之外，在这个过程中所产生的戏剧性的、引人注意的情景或是可视化展示的手段会被广为流传，对越来越多的人产生影响，它所产生的效果是非常惊人的。这里我有两个案例要和大家分享。
第一个例子是戏剧化的展示。
我曾经帮助某客户团队实施自动化测试。在这团队里，从部门领导到团队成员，普遍认为他们所处理的系统功能点杂、业务流程多变，实施自动化测试会有很高的脚本编写成本。此外，这家公司有独立的测试部门，但是由于这个团队做的是内部运营系统，测试部门并没有给予足够的重视和配合，反而是一再降低他们系统的测试优先级。从测试部门获得帮助几乎是不可能的奢望，所以所有人都认为自动化测试是不可行的， 但是他们愿意给我一个机会。
经过调研之后，我觉得数据驱动的功能测试非常适合这个团队的现状。经过了不到一周的准备，我迎来了第一次进度展示。为了帮助团队树立信心，并强调测试成本并没有想象中的那么高，我设计一个略有戏剧性的场景：在展示会当场把针对一个流程的测试，扩展为真对八个流程的测试——而这个改动仅仅涉及测试数据，没有任何测试代码的变化。也就是说，在2分钟内，测试案例个数提高八倍（当然，基数是一个自动化测试案例，这没什么可骄傲的）。没有行业数据、没有理论分析、没有特殊工具，就像变魔术一样提高八倍。
最终的结果也颇具戏剧效果，团队里除了产生了乐观的态度和对我的信任之外，我还收到一张速写。画了一个胖子站在投影幕布前面，幕布上整屏幕翻滚着测试执行日志和弹出的测试用浏览器。画的作者跟我说，当时他看到这一幕感到非常震撼，从来没有想过自动化测试可以凭空出现一般突然多出很多。此后我也在这个团队之外的地方听到了这个故事，与之相伴的是，很多实施自动化测试成功的案例。
第二个例子是没那么戏剧性的可视化展示。
很多年以前，那个时候微软刚刚推出WPF（Windows Presentation Foundation），我所在的一个团队就采用了这个技术，为某客户开发新一代客户关系管理系统。由于WPF在当时还是比较年轻的技术，很多实践都不是很成熟，我们做了很多的探索。一段时间以后，团队感觉到测试覆盖率偏低。不是测试报告上展示出来的数值低，而是根据缺陷的修复时间和缺陷的泄漏数量得到的一个直观感受。当时团队里有人有这样一个议论：因为WPF本身有很多自动生产的代码，同时很多交互功能以及样式渲染与WPF API绑定过死而难以测试。那么WPF最高测试覆盖率到底是多少？如果在WPF上最高测试覆盖率只能做到40％，那么我们的测试覆盖率还是很高的呢。毕竟我们使用了MVP（Model-View-Presenter）模式，对于可测试性还是有很大帮助的。
这是一种典型的自满情绪，这种情绪对于变革的推进是非常不利的。因为在这种情绪支配下，行为惯性很大且非常不容易接受其他建议。于是我们做了一个很简单的可视化展示，把当前团队的测试覆盖率写在一张卡片上，然后把这种卡片悬挂在团队最显眼的地方。如果我没有记错的话 ，初始数据是32％。然后有意思的事情就来了，这个数据当时是全办公室的最低值。毕竟其项目都是Web项目，以当时的能力要做到100％也不是不可能的。很多其他组的同事路过的时候，都会询问一下原因——毕竟这个数值实在太低了。可能是问得人多了终于有些同事受不了，开始反思32％是不是我们能做到的最好结果？答案当然是：不是，很多新的技术和技巧被发明出来用以改善WPF下的测试问题。几个月以后这个组的测试覆盖率接近60％。
有意思的是很多年后Android开始流行，另外一个项目组再做Android项目的时候遇到了类似的问题，也是测试覆盖率较低。他们准备放弃的时候，有人给他们讲了这个故事，特别提到了当时我们组挂在外面的那个测试覆盖率卡片。只不过讲故事的人说：我记得看到的数字是百分之五十几，所以你们做到这个数字也该不难吧。
“分析—思考—改变”与“目睹—感受—改变”最大的差异就在于，前者着眼于具体问题的分析和解决，而后者注重建立情感上的联系。成功的变革最终都会解决一些具体问题，但单刀直入式地从解决问题开始，并不一定是驱动人们作出行为改变的最佳方式。而当人们在情感上建立联系之后，往往会作出更有效的分析，也更容易接受思维上的改变。
在这个过程中最核心的步骤是感受， 通过情感上的冲击消除不利于改变的情绪而提升变革的意愿。变革的意愿越强烈，成功改变行为的几率就越高。有两种感受与改变的意愿密切相关：信任感与紧迫感。所以驱动行为改变最重要的步骤是获取信任、确立愿景以及提升紧迫感。
更多精彩洞见，请关注微信公众号：ThoughtWorks洞见
