上一個故事是關(guān)于自治團隊解放生產(chǎn)力的，除了生產(chǎn)力之外，交付的另一個關(guān)鍵因素是軟件架構(gòu)，架構(gòu)是在軟件開發(fā)過程中并不那么容易改變的東西。然而與過去時代所不同的是，今天的軟件架構(gòu)并不是所謂的架構(gòu)師高高在上做出的一些決策后就不再改變了，在這個技術(shù)快速變化的時代，今天的架構(gòu)更像是在時間線上一系列的輕量技術(shù)決策積累的一個結(jié)果。

而這個故事，就是關(guān)于技術(shù)決策的。

明線：所有權(quán)?經(jīng)營權(quán)?決策權(quán)?監(jiān)督權(quán)?

與A記不同的是，我們的客戶C記并沒有自己的IT團隊，也沒有一個明顯的IT部門。與C記的合作時間就更長了，這么長久的合作過程，卻是從一段“黑歷史”開始的。

在2009年到2010年的時候，C記項目上一個技術(shù)決策的過程基本上是這個樣子的：客戶說，“我們只能用SQL Server”。我們聽到這個消息之后，一方面在心里暗想，“為啥要選SQL Server，為啥喜歡微軟”，另一方面，我們發(fā)現(xiàn)，客戶并沒有提究竟用什么 ORM 框架，于是便“我們自己搞一個吧”。接下來發(fā)生的事情是，我們自己搞出來了一個NoSQL的文檔數(shù)據(jù)庫嫁接在SQL Server之上。從這個項目上線的***天起，就開始被打臉：性能問題，維護成本，數(shù)據(jù)遷移的難度，我們花了非常大的代價，才讓這套東西基本上能夠工作。

在那段時間里，這并不是唯一一個“魯莽的“技術(shù)決策，而這一切到底是如何發(fā)生的?實際上，存儲框架的決策比起采用什么樣的數(shù)據(jù)庫來說，要重要的多，然而這樣重要的決策卻沒有被拿到桌面上正兒八經(jīng)的和客戶一起討論。我們并不是糟糕的工程師，然而我們卻把自己的才智與精力放在了錯誤的地方。

沒有業(yè)務(wù)的引導(dǎo)，技術(shù)決策就更“技術(shù)導(dǎo)向”而不是“業(yè)務(wù)導(dǎo)向”。

我不得不給客戶寫一封郵件來解釋為什么我們要花很大的代價，從一個 homemade 的存儲框架，切換到更加成熟的方案，而我直到現(xiàn)在依然可以很清楚的記得當時的尷尬。

客戶當然非常不高興，***的回復(fù)是，“至少我們開始討論這些事情了”。于是這正是我們開始做的，我們開始在作出重要技術(shù)決策的時候邀請客戶參與。設(shè)置一個技術(shù)治理小組，每個月對技術(shù)方向進行討論，用技術(shù)債雷達來可視化和積極的應(yīng)對技術(shù)債，這些都是在客戶的參與下發(fā)生的。

一方面，這是為了把更多的信息透明給客戶，然而更為關(guān)鍵的另一方面是，為了作出慎重的技術(shù)決策，我們需要知道客戶所面臨的約束，我們需要能夠從中驗證自己的假設(shè)，從而更好的尊重這些約束。

Tech Lead 的傾向從追逐”正確“的決策，變成了開始作出”合適“的技術(shù)決策。

于是事情開始向好的方向發(fā)展，從2011到2014年期間，homemade 的存儲框架的搭橋手術(shù)成功，能夠讓我們逐漸遷移到成熟的方案;我們開始構(gòu)建了更多的產(chǎn)品，微服務(wù)的技術(shù)架構(gòu)也逐漸成型;隨著新系統(tǒng)的上線和老系統(tǒng)的退休，整個平臺遷移到了RackSpace上，加上自動化部署流水線，發(fā)布變得越來越頻繁。

Happy ending?可惜并不是，2014年，客戶方的技術(shù)負責(zé)人被調(diào)動到了另一個部門，另一個人接手了他的工作。與前任不同的是，他對于技術(shù)決策的參與度非常高。甚至有時候會為團隊做決策，然后讓團隊承擔(dān)決策的后果。

這導(dǎo)致了另一個問題，當團隊所得到的只是一個決策結(jié)果，沒有一個重新思考和衡量約束的過程，團隊無法在不斷變化的技術(shù)環(huán)境中持續(xù)的驗證以前的假設(shè)。一方面，我們喪失了很多采納新技術(shù)的機會，更重要的是，團隊需要能夠自己做出決策，承受自己決策的后果，并從中自己的決策中學(xué)習(xí)和成長。

于是我們建議客戶能夠更多的分享上下文，而不是做決策，決策由團隊來出，但是客戶保留否決的權(quán)力。如果客戶不認可決策，在分享了原因之后，團隊可以更好的提出別的方案。

去年C記的團隊成功交付了一個新的產(chǎn)品，替換掉了好幾個花了三年多時間開發(fā)的老產(chǎn)品。由于大多數(shù)的功能都已經(jīng)服務(wù)化，所以新產(chǎn)品的開發(fā)只花了半年多時間就上線了。用客戶的話說，我們“able to leap tall buildings in a single bound”。這是正確的技術(shù)決策壓過了錯誤技術(shù)決策之后的結(jié)果。

聆聽、理解和尊重客戶約束，在技術(shù)決策上謹慎的前行，同時，隨著技術(shù)的發(fā)展不斷去反思和檢查這些約束假設(shè)是否依然成立，從而持續(xù)的保持技術(shù)架構(gòu)演進的方向與業(yè)務(wù)能力的對齊。

這是C記的故事的明線。

暗線：尋找時間之矢

有意思的是，如果倒過來讀C記的故事，會發(fā)現(xiàn)如果加以打磨，依然可是一個好故事：剛開始的時候，客戶強控制技術(shù)決策，我們很suffer，然后，慢慢信任，逐漸放棄控制，***，我們贏得了客戶的信任，開始獨立做決策，happy ending。雖然并不真實，然而卻是一個更好的故事。

這就如同物理學(xué)定律中，時間是對稱的一樣，決策機制在這個故事中，也是時間對稱的，那么決策機制就并不是進化的關(guān)鍵因素。然而在物理學(xué)中，熵增卻是時間之矢的指向，那么這里的時間之矢到底是什么?

從郭曉的演講中，我找到了想要的答案。

就如同交易成本的不斷降低，打破了壁壘，促進了無數(shù)的人投身創(chuàng)業(yè)一樣，技術(shù)成本的不斷降低，技術(shù)壁壘的不斷降低，也會帶來更大范圍的結(jié)構(gòu)性變化。

比如說自動化測試技術(shù)干掉了傳統(tǒng)的測試部門，數(shù)據(jù)庫的自動化技術(shù)干掉了DBA，部署、運營的自動化干掉了運營，云化、安全內(nèi)嵌也許將要干掉采購和安全。當這些東西，因為技術(shù)的進步而標準化后，當全面的數(shù)字化平臺in place之后，那么剩下的就僅僅是業(yè)務(wù)解決方案、技術(shù)棧與實現(xiàn)代碼了，在這個畫面里，不寫代碼的傳統(tǒng)IT部門的麻瓜們是摻和不進來的，于是把決策權(quán)交給開發(fā)團隊是一個自然而然的選擇……

[[201694]]

于是隨著開發(fā)團隊的權(quán)力越來越大，意味著更大的責(zé)任，在這種新形勢下進行技術(shù)決策保障也需要轉(zhuǎn)變思路。建立共同愿景，讓團隊找到自己為了什么來工作的理由，找到自己的 purpose，把自己與日俱增的 power 用到合適的地方，這才是作為技術(shù)***應(yīng)該做的工作。

那么我們C記的故事的暗線也就浮出了水面，故事中所建立起的決策機制本質(zhì)上是在營造安全感，我們的傳統(tǒng)企業(yè)客戶多多少少都有類似的決策機制(所謂的架構(gòu)組)，說白了是用增強控制來應(yīng)對新形勢下的心態(tài)失控。

然而，能控制得了的東西卻越來越少，技術(shù)之矢使控制本身越來越?jīng)]有價值，反而成了阻礙和包袱。在IT部門滅亡之前，也許就如同我們與C記故事的后半段一樣，在事情變好之前，會先變壞，但熵增的車輪，是不會停下的。

也正是這種反抗之力如此頑強，每每當傳統(tǒng)企業(yè)想要甩掉包袱往前快跑的時候，重重的阻礙卻并不來自于領(lǐng)導(dǎo)層。透過傳統(tǒng)企業(yè)繁冗的流程和層級，背后是一個個“企業(yè)架構(gòu)師”、“系統(tǒng)架構(gòu)師”，一個個在這樣一種新的形勢下即將“被干掉”從而失去自己職業(yè)發(fā)展的人。

那么，你現(xiàn)在的職位是什么呢……

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文