職權(quán)不是決定因素
絕大多數(shù)工程師對于變革有種無力感。這種無力感源于這樣的想法：我不是管理人員，沒有足夠的職權(quán)，無法改變自己的組織。當(dāng)這種感覺足夠強烈的時候，它作帶來的挫敗感會使我們失去進一步行動的能力。
然而這種無力感無論是中層管理者、執(zhí)行副總裁甚至首席執(zhí)行官都會存在。論及變革，沒人具有足夠的權(quán)力。這是因為變革中最核心的問題不是改變組織的結(jié)構(gòu)、戰(zhàn)略或文化，而是改變?nèi)说男袨榕c意愿——改變?nèi)说墓ぷ鞣绞揭约霸诠ぷ髦兴P(guān)心的內(nèi)容。 職權(quán)的確會讓某些事情變得容易，有些大范圍的變革還必須巧妙借助職權(quán)的力量——比如涉及組織結(jié)構(gòu)調(diào)整的改變，但它不一定是變革成功的決定因素。
從2007年開始，國內(nèi)很多軟件企業(yè)開始嘗試采用敏捷方法，其中不乏有中高層領(lǐng)導(dǎo)以行政命令推行敏捷方法的做法。我曾經(jīng)在敏捷中國大會上碰到一位朋友，他跟我講了他們公司的故事：他們公司里負責(zé)研發(fā)副總裁聽說了敏捷方法之后，對于測試驅(qū)動開發(fā)非常感興趣，認為這是提高軟件質(zhì)量的好方法。于是在公司內(nèi)要求所有的研發(fā)人員都必須要開始采用測試驅(qū)動的方法進行編程，并制定了相應(yīng)的考核制度。而最后的結(jié)果是，研發(fā)人員為了應(yīng)對考核指標(biāo)，寫了很多無用的測試，花了額外的時間不說，對軟件質(zhì)量的提高并沒能帶來實質(zhì)性的幫助。最后縱使在報告上有不錯的測試覆蓋率統(tǒng)計，絕大多數(shù)人——包括那位研發(fā)副總裁自己——都不認為這次變革是成功的，因為人們的工作方式和內(nèi)容并沒有真正地發(fā)生改變：他們并沒有變得更注重質(zhì)量，也沒有采用自動化的方式來保證軟件質(zhì)量不受破壞。
比起職權(quán)我們更應(yīng)該學(xué)會影響他人，驅(qū)動他們在行為上發(fā)生改變 。無論是否具有職權(quán)，成功地驅(qū)動變革都不是件容易的事情。擁有職權(quán)仍然需要小心使其發(fā)揮作用，沒有它也不意味著我們完全被束縛了手腳，不能采取任何行動。關(guān)于職權(quán)在變革中的作用我們將在下一章討論，在那之前首先需要討論的是成功驅(qū)動變革的核心因素——如何驅(qū)使行為改變。
什么可以帶來行為的改變？
有一種可以帶來行為改變的方法，其主要模式可以表述為“分析—思考—改變”：
- 針對特定問題向人們展示數(shù)據(jù)或者分析結(jié)果；
- 通過數(shù)據(jù)或者分析的論證影響他們的思考方式；
- 借由新的思維方式帶來行為模式的改變。
這種方式天然受到工程師的喜愛。作為工程師，我們接受過嚴格的邏輯思維訓(xùn)練。我們相信數(shù)據(jù)以及理性的分析，并愿意根據(jù)分析結(jié)果調(diào)整自己的行為。我們理所當(dāng)然地認為這是最合乎情理也是最客觀理性的方法。不過令人意外的是，變革管理大師John P. Kotter的研究表明，“分析—思考—改變” 這種方式很少能真的發(fā)揮效果。他說對于“只對數(shù)據(jù)感興趣的工程師”可能會有效果，但以我個人的經(jīng)驗來說，哪怕是對工程師，這招也沒那么管用。
理智的局限
工程上的很多問題我們雖然知道優(yōu)劣之分，但是難以量化和度量。比如Ruby到底比Java和.NET在研發(fā)效率上快多少？RESTful的架構(gòu)風(fēng)格比SOA（Service Oriented Architecture）在開放性和擴展性上好多少？采用結(jié)對編程的方式和不采用結(jié)對編程的方式在代碼質(zhì)量上有多少提高？我們明確地知道Ruby比Java和.NET的開發(fā)效率高、RESTful比SOA有更好的彈性、結(jié)對編程產(chǎn)出的代碼質(zhì)量更好，但是一旦論及多少和數(shù)量，卻不是那么容易能夠給出明確的答案。
那么我們要如何改變Java和.NET程序員的思維，讓他們認為Ruby是值得嘗試的？要如何改變具有多年SOA經(jīng)驗的架構(gòu)師的思維，讓他們相信RESTful是更好的選擇？要如何改變從沒有結(jié)對經(jīng)驗的項目經(jīng)理，讓他們理解結(jié)對并不是浪費時間和金錢呢？
此外，分析結(jié)果對人們思維的改變，遠沒有達到我們想象的那種程度。哈佛大學(xué)商學(xué)院Andrew McAfee教授富有洞鑒地指出：我們通常會高估新技術(shù)帶來的效果和影響，大約三倍，而低估已有技術(shù)和方法的效能，大約也是三倍，只有在新舊技術(shù)相差十倍的時候，我們才會有明顯的改變意愿。換句話說，如果我們希望發(fā)生的改變沒有在某方面帶來十倍以上的提升，人們的思考方式不會因為我們的分析而發(fā)生明顯的變化。所以當(dāng)你希望重構(gòu)代碼結(jié)構(gòu)以獲得更好的架構(gòu)時，當(dāng)你希望更換不同的數(shù)據(jù)庫以獲得更好的開發(fā)效率時，通常不會受到特別熱烈的響應(yīng)——這些改變雖好，但是遠沒有十倍以上的差距。
最后，也是最重要的，分析結(jié)果的確能夠改變?nèi)说乃季S，但卻很少能夠有效地改變?nèi)说男袨榉绞?。比起思維，情感更能驅(qū)動人們作出行為的改變，而很少有分析結(jié)果能真正地打動人心，建立情感上的紐帶。
幾年前在推廣Ruby的時候，我和幾位同事組織過廈門Ruby用戶組，期間我分享過一個主題：從面向?qū)ο蠹夹g(shù)發(fā)展的歷史來看，為什么Ruby是更好的面對象語言。會后有位朋友私下找我溝通，他說：“從你提供的資料和分析，我或許相信Ruby這門語言有它的根源和發(fā)展；但是我實在無法想象在企業(yè)應(yīng)用的開始中去使用它，因為我是企業(yè)級Java開發(fā)人員啊?！?/p>
這番話很有代表意義，Java對于這位朋友而言，與自我認知有關(guān)。他和Java有更深的感情聯(lián)系——這是定義我的角色和身份的技術(shù)。所以他雖然能在思維上認可我給出的資料和分析，卻很難真的作出改變。
感受帶來改變
那么什么才是帶來行為改變更有效的方法呢？答案是：目睹—感受—改變。
照John P.Kotter的話講，這是“大多數(shù)在變革中取得成功的組織都會采用模式”。其模式可表述為：目睹是指通過一些戲劇性的、引人注意的情景或可視化展示（visualization）來幫助人們發(fā)現(xiàn)問題；在看到問題之后，引發(fā)人們情緒和感受上的沖擊，讓他們開始從內(nèi)心深處作出反映，削弱那些阻礙變革的情緒，比如自滿、憤怒、懷疑或恐懼。增加緊迫感、樂觀或者信任等有益于變革的情緒；這些正向情緒開始改變原有的行為，或者強化新的行為模式。
這種模式常常會產(chǎn)生較深遠的影響，除了能夠帶來行為改變之外，在這個過程中所產(chǎn)生的戲劇性的、引人注意的情景或是可視化展示的手段會被廣為流傳，對越來越多的人產(chǎn)生影響，它所產(chǎn)生的效果是非常驚人的。這里我有兩個案例要和大家分享。
第一個例子是戲劇化的展示。
我曾經(jīng)幫助某客戶團隊實施自動化測試。在這團隊里，從部門領(lǐng)導(dǎo)到團隊成員，普遍認為他們所處理的系統(tǒng)功能點雜、業(yè)務(wù)流程多變，實施自動化測試會有很高的腳本編寫成本。此外，這家公司有獨立的測試部門，但是由于這個團隊做的是內(nèi)部運營系統(tǒng)，測試部門并沒有給予足夠的重視和配合，反而是一再降低他們系統(tǒng)的測試優(yōu)先級。從測試部門獲得幫助幾乎是不可能的奢望，所以所有人都認為自動化測試是不可行的， 但是他們愿意給我一個機會。
經(jīng)過調(diào)研之后，我覺得數(shù)據(jù)驅(qū)動的功能測試非常適合這個團隊的現(xiàn)狀。經(jīng)過了不到一周的準(zhǔn)備，我迎來了第一次進度展示。為了幫助團隊樹立信心，并強調(diào)測試成本并沒有想象中的那么高，我設(shè)計一個略有戲劇性的場景：在展示會當(dāng)場把針對一個流程的測試，擴展為真對八個流程的測試——而這個改動僅僅涉及測試數(shù)據(jù)，沒有任何測試代碼的變化。也就是說，在2分鐘內(nèi)，測試案例個數(shù)提高八倍（當(dāng)然，基數(shù)是一個自動化測試案例，這沒什么可驕傲的）。沒有行業(yè)數(shù)據(jù)、沒有理論分析、沒有特殊工具，就像變魔術(shù)一樣提高八倍。
最終的結(jié)果也頗具戲劇效果，團隊里除了產(chǎn)生了樂觀的態(tài)度和對我的信任之外，我還收到一張速寫。畫了一個胖子站在投影幕布前面，幕布上整屏幕翻滾著測試執(zhí)行日志和彈出的測試用瀏覽器。畫的作者跟我說，當(dāng)時他看到這一幕感到非常震撼，從來沒有想過自動化測試可以憑空出現(xiàn)一般突然多出很多。此后我也在這個團隊之外的地方聽到了這個故事，與之相伴的是，很多實施自動化測試成功的案例。
第二個例子是沒那么戲劇性的可視化展示。
很多年以前，那個時候微軟剛剛推出WPF（Windows Presentation Foundation），我所在的一個團隊就采用了這個技術(shù)，為某客戶開發(fā)新一代客戶關(guān)系管理系統(tǒng)。由于WPF在當(dāng)時還是比較年輕的技術(shù)，很多實踐都不是很成熟，我們做了很多的探索。一段時間以后，團隊感覺到測試覆蓋率偏低。不是測試報告上展示出來的數(shù)值低，而是根據(jù)缺陷的修復(fù)時間和缺陷的泄漏數(shù)量得到的一個直觀感受。當(dāng)時團隊里有人有這樣一個議論：因為WPF本身有很多自動生產(chǎn)的代碼，同時很多交互功能以及樣式渲染與WPF API綁定過死而難以測試。那么WPF最高測試覆蓋率到底是多少？如果在WPF上最高測試覆蓋率只能做到40％，那么我們的測試覆蓋率還是很高的呢。畢竟我們使用了MVP（Model-View-Presenter）模式，對于可測試性還是有很大幫助的。
這是一種典型的自滿情緒，這種情緒對于變革的推進是非常不利的。因為在這種情緒支配下，行為慣性很大且非常不容易接受其他建議。于是我們做了一個很簡單的可視化展示，把當(dāng)前團隊的測試覆蓋率寫在一張卡片上，然后把這種卡片懸掛在團隊最顯眼的地方。如果我沒有記錯的話 ，初始數(shù)據(jù)是32％。然后有意思的事情就來了，這個數(shù)據(jù)當(dāng)時是全辦公室的最低值。畢竟其項目都是Web項目，以當(dāng)時的能力要做到100％也不是不可能的。很多其他組的同事路過的時候，都會詢問一下原因——畢竟這個數(shù)值實在太低了?？赡苁菃柕萌硕嗔私K于有些同事受不了，開始反思32％是不是我們能做到的最好結(jié)果？答案當(dāng)然是：不是，很多新的技術(shù)和技巧被發(fā)明出來用以改善WPF下的測試問題。幾個月以后這個組的測試覆蓋率接近60％。
有意思的是很多年后Android開始流行，另外一個項目組再做Android項目的時候遇到了類似的問題，也是測試覆蓋率較低。他們準(zhǔn)備放棄的時候，有人給他們講了這個故事，特別提到了當(dāng)時我們組掛在外面的那個測試覆蓋率卡片。只不過講故事的人說：我記得看到的數(shù)字是百分之五十幾，所以你們做到這個數(shù)字也該不難吧。
“分析—思考—改變”與“目睹—感受—改變”最大的差異就在于，前者著眼于具體問題的分析和解決，而后者注重建立情感上的聯(lián)系。成功的變革最終都會解決一些具體問題，但單刀直入式地從解決問題開始，并不一定是驅(qū)動人們作出行為改變的最佳方式。而當(dāng)人們在情感上建立聯(lián)系之后，往往會作出更有效的分析，也更容易接受思維上的改變。
在這個過程中最核心的步驟是感受， 通過情感上的沖擊消除不利于改變的情緒而提升變革的意愿。變革的意愿越強烈，成功改變行為的幾率就越高。有兩種感受與改變的意愿密切相關(guān)：信任感與緊迫感。所以驅(qū)動行為改變最重要的步驟是獲取信任、確立愿景以及提升緊迫感。
更多精彩洞見，請關(guān)注微信公眾號：ThoughtWorks洞見
