寫在前面：
“出於技藝的追求，工程師常常會以開放的心態去嘗試新的工具和做法。其中有些完全可以由我們自己掌控，比如使用哪種文本編輯器、採用什麼樣的控制檯、是VIM還是Emacs風格快捷鍵等等。但更多的情況是，我們發現的“更好的方法”不僅會影響我們自己，還會影響到團隊、部門甚至整個公司。如果我們堅信自己的選擇並由衷地希望以更好的方式工作，那就必須能夠說服其他人，讓他們認可我們的做法，並在工作上作出改變。”
本文是徐昊所寫的《驅動變革》第一篇，後續他還將從“職權不是決定因素”、“行為的改變”、“獲取信任和確立願景”以及“提升緊迫感”等幾個角度分別闡述驅動變革的意義及方式。敬請期待。
作為工程師的我們為什麼要學習驅動變革？為什麼必須成為變革者？請先試想一下這兩個場景：
• 你在代碼庫中發現非常多的重複代碼，這些代碼不僅功能趨同而且結構類似。在進行了簡單的重構之後，你發現這些代碼其實是一類公用組件，可以在很多業務場景下重複使用。這個時候，你準備把它提取成一個單獨的共用項目或者叫基礎模塊，在消除掉這些重複的同時，改善代碼結構並且讓未來的功能開發更加簡單有效。你希望其他人支持你的做法，並著手修改他們所負責的代碼。
• 你所工作的小組正在為某企業客戶開發一款調查問卷軟件的升級版，採用的技術棧
是 .NET、ASP .NET MVC和SQL Server。隨著項目的進行，你發現所有數據都可以由問卷實體進行聚合（aggregating）。如果使用關係型數據庫，這種聚合關聯關係複雜而且效率不高。而使用文檔數據庫（Document Database）不僅能簡化開發，而且常用查詢的執行效率會提高很多倍。你希望能由SQL Server切換到文檔數據庫——比如MongoDB。
這兩個場景你應該覺得非常熟悉，這是工程師經常遇到的境況：由於非常瞭解手頭所做的工作，通常會比組織中其他人更早、也更敏銳地發現更好工作方式。比如更好的編碼方式、更恰當的編程語言和工具，還有更合理的工程實踐等等。出於技藝的追求，我們會以更開放的心態去嘗試新的工具和做法。其中有些完全可以由我們自己掌控，比如使用哪種文本編輯器、採用什麼樣的控制檯、是VIM還是Emacs風格快捷鍵等等。但更多的情況是，我們發現的“更好的方法”不僅會影響我們自己，還會影響到團隊、部門甚至整個公司。如果我們堅信自己的選擇並由衷地希望以更好的方式工作，那就必須能夠說服其他人，讓他們認可我們的做法，並在工作上作出改變。
作為工程師，通常我們對這個問題最直接的反應是以結果說話。相信只要有更先進的技術、更好的結果、更多的產出，那麼我們所期待的變化就會自然而然地發生。然而實際情況恰恰不是這樣的，我們容易低估變革的難度和阻力，而高估技術因素在變革中的影響力。比如上面所說的兩個場景： 第一個是重構代碼並調整項目結構，第二個是更換技術棧中的組件。看起來都是收益明確的“技術決定”，但這些決定帶來的變化可能是非常深遠的，阻力也可能完全來自意想不到的地方。
架構與組織結構改變
首先來看第一個例子——重構代碼並調整項目結構。這裡的盲點是Conway法則——組織結構是軟件架構的倒影，阻力來自因為架構變化帶來的組織結構變化。
你所重構出來的公共模塊會在很多業務場景下重複使用，假使讓所有使用了這些模塊的小組共同維護這些組件，就會帶來非常大的溝通成本。無論是API的變化還是特性的取捨，都沒有辦法在某個小組內單獨決定，因為它現在已經是共用模塊了。最簡單的情況是由某個人——很可能就是你——來協調對公共模塊的修改。那麼在不久的將來，如果公共模塊的需求足夠多，實際上就會出現一個獨立的公共模塊小組或團隊。這是由技術決策帶來的團隊結構和人力分配的調整。如果不能把這個因素納入考量，重構就可能會失敗。
你可能會想這真的會發生嗎？重構一下代碼結構能有這麼大的影響嗎？這當然不是編造的，我來講個現實中發生的案例。
曾經有一個團隊，他們採用的技術棧是 .NET。最開始的架構也很簡單，前端採用
ASP.NET MVC，後端使用Entity Framework進行存儲。然而這個系統的領域模型比較複雜，有很多小的細力度對象。使用Entity Framework進行持久化的時候，類型映射的代碼非常複雜，但這些對象引用關係相對比較簡單。這時候有個技術非常不錯的小夥子，為了解決底層的持久化問題，開始尋找不同的解決方案。於是他邊寫功能代碼邊自己做了一套不同於Entity Framework的持久化框架，通過SQL Server的XML字段和 .NET對象序列化完成所有持久化的操作。
他做完演示之後，大家都覺得很不錯，於是就開始著手重構其他代碼。這時候麻煩來了，他做框架的時候，是根據他所熟悉的業務進行的抽象，有很多沒有考慮到的地方。不過他手很快，白天提的需求晚上就能改好，後來慢慢發現由於整組人都在用這個東西，別人又沒他了解的多，不如讓他專門來做這個框架。漸漸他就不做其他的需求而是專門來做框架，於是他自己就成了一個小團隊。
這就是因重構而產生團隊結構變化的例子。這個案例之所以能夠成功，除了他個人的一些做法之外，主要是因為這個團隊負責整個軟件的交付，責任結構比較簡單，內部分工的變化對整體交付沒有影響。如果不是這樣的結構，又不事先考慮組織變革的成本，那麼架構重構基本上就會失敗。
很多年前，我在Java社區認識一個朋友，他所在的公司在國內某行業做定製軟件開發。這家公司的團隊是按業務模塊進行劃分的，每個小組負責一個模塊的交付。我這位朋友算是想法比較活潑的，他希望能夠抽取與業務相關的公共組件，從而在現有的項目中提煉出產品和行業解決方案。他在他負責的小組內做了嘗試，並取得了一定成功。
他的領導讓他徵求其他團隊的意見，看看是否有推廣的前途。然而在這個過程中，他受到項目其他模塊團隊的質疑：如果公共模塊出了問題誰來負責？當他回答說，“我可以用業餘時間儘量幫助大家”的時候，最終實施結果也就可想而知了。沒有人願意把交付的成敗依靠在某個人的業餘時間投入上，而領導又沒有足夠的動力改變整個團隊的結構，那麼這個方案也就不了了之了。
核心組件與技能要求
再看第二個例子——更換技術棧中的組件。這裡的盲點是協作部門的技能變更。
你所作出的技術決定是正確的。針對這種聚合關係的對象結構，無論從數據存儲的效率、查詢的效率還是開發的效率來說，文檔數據庫都會是更好的選擇。但是開發僅僅是整個軟件生命週期中的一環，除了開發之外還有運維支撐，比如監控、備份、數據恢復、故障診斷等方面，也是非常重要的。特別是對於已經運營了一段時間的軟件產品來說，就更是這樣了。
在這個例子裡，因為是後續升級而不是全新系統，那麼客戶已經圍繞SQL Server建立了完整的運維體系。那麼如果把數據庫換成MongoDB，就需要圍繞MongoDB建立新的運營方式，那麼運維團隊就需要新的技能和工具才能繼續運營這個產品。這是因技術決策而為協作部門帶來新的技能要求，如果不能把這個因素納入考量，就會影響軟件的最終投產。
同樣為了告訴你這樣的事情真的會發生，我舉個例子。
最近有個團隊，在幫助某客戶研發醫療管理系統。該系統是個有多年曆史的遺留系統。由於設計的早，架構上有很多不盡合理的地方。在這次的研發中，客戶希望可以擷取業內較好的工程實踐，以支撐未來的架構演化。這個團隊採用了micro-service的方式架構整個應用，把獨立的模塊分解成獨立的服務。部署上為了更好的彈性，拋棄了原有系統的應用程序服務器模型，而是採用內嵌Web容器的方式。
在開發了一段時間之後，有醫院方的人員來參加成果展示。這時候，負責這個系統運營的IT部門表達了強烈的不滿。原因是，他們的運營人員主要通過應用程序服務器的控制檯管理所有應用程序。而一旦變成多進程的micro-service後，原有運維工作就需要依賴linux平臺上的日誌、進程管理監控工具才能完成。他們的運維人員完全沒有這方面的經驗。當時的結果是，micro-service僅在測試環境中使用，而生產系統必須採用應用服務器的模式。
這是好的、先進的技術因為沒有預估好協作部門的技能水平而失敗的例子。當然，考慮到這個問題而把一些相對激進的好技術推行成功的故事也是有的。
在Ruby還不是很流行的時候，有個團隊想在項目中使用Ruby Watir作自動化功能測試。而客戶的情況是：他們已經花了大價錢購買了HP的Quality Center和QuickTest Pro。這兩個都是商業軟件，都需要高昂的版權費用。這兩個軟件分別由業務人員和QA團隊使用，業務人員使用Quality Center來記錄需求和測試案例，自動化功能測試主要由QA團隊完成。QA團隊主要採用錄製腳本結合VB Script的方式來編寫測試，測試全部由QuickTest Pro執行。
力主使用Ruby Watir的是研發團隊，因為當時ruby很新潮同時Watir的執行效率比QuickTest Pro要好很多，但QA團隊並沒有表現出對Ruby的熱衷。這時候團隊裡的工程師研究了QuickTest Pro的編碼風格。發現QuickTest Pro中測試主要依賴三個部分：Object Repository用於表示頁面元素和常量、Data Sheet用於記錄測試數據、VB Script用於實現測試步驟。於是他們使用Ruby做了一套框架：PageObjet用於表示頁面元素和常量、Fixture用於記錄測試數據、定製的領域專用語言（DSL）用於實現測試步驟，同時整合Quality Center以統計測試報告。這個框架讓QA團隊感覺到工作方式其實沒有什麼太大變化，基本都能與QuickTest Pro中的概念一一對應，並且不會影響Quality Center的使用。就同意嘗試
使用它。大約四周之後，整個測試部門就開始了由QuickTest Pro到Ruby Watir的遷移，QuickTest Pro就完全廢止不用了。所以只要方法正確，這種看似不可能的變化——拋棄已經採購的商業軟件轉而使用開源軟件和不知名的小語種——也是可以順利完成的。
我還可以列舉出非常多的例子，看起來都是好的技術決策，然而最終左右這些決策成功與否的並不全是技術因素。我想你已經大概明白我的意思了：僅有更好方案是不夠的。更先進的技術、更好的結果、更多的產出，並不能讓我們所期待的變化自然而然地發生。哪怕只是某些技術上的改進，單單是個體的變化已經不夠了。那麼如果我們不希望年復一年地工作在腐爛的代碼庫上，使用陳舊的技術棧、落後的工具、過時的工程實踐，我們必須學會驅動變革，成為卓有成效的變革者。
技術雷達十年：https://www.bagevent.com/event/1591013
閱讀更多 ThoughtWorks 的文章
