技術的迷失

每一個ThoughtWorker都知道TW的三個柱子,江湖人稱三個P(屁)。第一個P聚焦客戶是我們生存的根本,第三個P社會公正是我們超越生存層面的精神追求。而第二個P追求技術卓越,我想那首《我們不一樣》特別能夠表達很多人的內心世界。但是最近在項目中和其它工作中遇到了一些事情讓我開始有了一個疑問:我們追求的P2究竟是什麼,技術卓越中的技術究竟是什麼,什麼可以稱爲技術,什麼又不是技術,所謂卓越又是什麼含義,怎樣做纔算做到了卓越,卓越的對立面又是什麼?

先說兩個真實的故事:

  • 第一個故事是在一次交付項目的Review中,有一位項目成員A的buddy提出了來自A的反饋,A說目前這個項目和他原本想的不太一樣,項目中的大部分工作都是適用DDD(領域驅動設計)來把客戶的需求建模並實現了,而A心中覺得這種東西沒有什麼技術價值,他覺得如果項目中有高併發處理,大數據,人工智能算法什麼的纔算有技術含量,而現做的這些更多偏向業務。

  • 第二個故事是我在一次和同事B溝通微服務和DDD(領域驅動設計)相關建模實踐的時候,同事B提到感覺我們公司現在做的很多事情都是更偏向業務的,而關於微服務設計和DDD建模這些技術問題纔是更有意思的,這種基於技術的討論比業務更有意義。

1.什麼是技術

這兩個故事讓我覺得很有必要弄清楚一下什麼是技術,爲什麼大家很容易把技術和業務對立的來看,這兩者真的就是水火不融嗎?
這讓我想起了2017年讀過的一本讓我印象非常深刻的書,Brian Arthur的《技術的本質》,雖然我在2017年一共讀完了60本各種類型的書,但是這本書是可以在在60本書中排到前三名的。


Brian Arthur在這本書中通過嚴謹的邏輯論述了:技術是什麼,以及是如何進化的。在這本書的‘第三章現象’中,作者給出了他對技術本質的定義:

相對於只將技術看作實現目的的手段,我們現在有了更直接的描述:技術是被捕捉到並被使用的現象,或者更準確的說,技術是哪些被捕捉並加以利用的現象的集合。或者說,技術是對現象有目的編程

我知道這個定義可能太過於抽象了,讓我們用例子來對這個定義解釋一下:

  • 比如汽車燃油發動機這種技術,就是捕捉到能源燃燒會導致空氣膨脹現象,通過力學現象可以把前後推拉力轉換成旋轉力,還有利用高溫融化金屬現象而發展出的冶煉鑄造,等等很多種對各種現象有目的利用並組合在一起纔有了發動機技術
  • 再比如我們公司最熟悉的微服務技術,就是捕捉到了基於http協議的API通信越來越成熟,網絡通信速度越來越快,雲服務開始商業化,通過開源方式可以讓全球聰明人一起來進行貢獻,大型單體應用不好進行擴展和維護,還有使用了SOA的企業遭遇的各種問題等等現象,然後針對這些現象進行有目的的編程,就形成了今天不論是在微服務理論,還是微服務工具層面能夠全面支撐的微服務全家桶。

如果基於這個廣義的技術定義,我們會發現不論是人文領域的小說寫作技術,經濟分析技術,心理分析技術;還是自然領域的核能技術,飛機發動機技術;或者是在計算機領域的各種大數據技術,人工智能技術,DDD(領域驅動設計)技術都能夠使用這個定義來進行解釋了。

2.技術職業玩家

再回到開頭的兩個故事,對於第一個故事,當我們使用DDD分析客戶的業務的時候,其實就是對軟件工程領域需求和開發有Gap的現象,通過利用領域語言達到減少Gap,並且還能夠根據模型的邏輯嚴謹性反過來推動業務。這個過程和我們根據神經網絡現象來編寫人工智能算法,根據排隊現象來實現高併發處理本質上來說都是一樣的技術。

我們作爲技術領域的職業玩家,技術不僅僅是DEV的玩具,不論角色是Sales,PM,QA,還是BA都應該明白自己每一天的日常工作都是和技術相關的,

  • Sales對博弈現象進行利用來獲得合同是技術,
  • PM對項目工作之間有依賴關係的現象加以利用得出更有效的項目計劃是技術
  • QA對測試工作經常重複的現象加以利用編寫自動化測試腳本是技術,
  • BA對開發很難理解業務的現象加以利用把業務變成領域通用語言也是技術

對於第二個故事,很多年前在IBM時中國區的首席架構師一個埃及人給我講過,所有的軟件架構必須要根據業務來進行設計,脫離於業務的軟件架構是脆弱的。我認爲這句話不僅僅適用於軟件架構設計技術,所有的技術都是從業務土壤上生長出來的。因爲按照前面技術的定義,現象是從具體的業務中來的。

我們在日常工作中也很容易發現一個問題,當脫離一個業務案例討論一個技術的時候,很容易出現雙方誰也說服不了誰的爭論,但是當引入了一個具體的業務以後,大家就很容易在技術觀點上達成一致了。所以以後當我們在工作中討論技術問題的時候,應該有人提出這個問題:“能不能用一個業務例子來解釋一下?” 我相信這個問題能夠幫助大幅提高會議效率。

3.如何技術卓越

前面已經明確了技術的定義,那麼怎樣做才能讓我們進行編程的過程能夠卓越呢?對於這個問題我想使用一個對專業技術人士的專業評價體系,這個體系是前蘇聯物理學家朗道發明的,他一生有三個重要貢獻,第一個是朗道變換,他也因此獲得了1962年的諾貝爾物理學獎;第二個是朗道壁壘,這是一系列越來越難的理論物理練習題,通過這套練習題,物理學學生可以知道自己的水平;第三個他提出了按照水平和貢獻來評價物理學家的方法。

仿照朗道的方法,吳軍在“硅谷來信”中也把工程師分成了五個級別,而工程師正是發明和應用技術的人,所以我認爲這個工程師的五個等級劃分,可以幫助給出技術卓越的方向。下圖就是這個五級金字塔,從第五級到第一級越來越難。

  • 第五級要求能夠熟練的獲取和應用工作所需的技術來解決問題,並獨自完成工作。舉例來說,項目中需要能夠分析用戶行爲數據,那麼他需要知道數據在哪,如何獲取。也知道根據不同的數據量級,如何進行分析。還有根據業務對數據的實效性要求,知道應該採用什麼技術來計算數據,如果計算有性能問題應該如何處理,怎麼在開發階段驗證這些問題。最終的數據應該採用各種方式進行展現,如何根據業務的變化進行調整等等。如果做不到這一點,就算不上合格的五級工程師。
  • 第四級要求有領導能力和在工程上把大問題化解成小問題的能力,能夠尋找出實現比較大目標的道路。如果第五級強調的是個人完成獨立的分析用戶行爲數據的任務,那麼第四級則是能夠帶領一個團隊在資源限制條件下完成一個運營分析系統。能否成爲合格的第四級工程師,要看能否最好地解決了一個有規模的實際問題。
  • 第三級要求能夠獨立的帶領團隊做出一個爲公司掙得利潤的產品了。除了上面兩級的能力外,還需要有市場的判斷和營銷能力。接着上面用戶分析的例子,第三級是能夠根據運營分析系統來創造一個可以複用的數字化運營解決方案,或者直接可以做出一個能夠滿足很多客戶的運營分析產品。這一級的工程師,是需要有良好工程素養的人,能夠心胸開闊願意接受各種意見和建議。
  • 第二級要求能夠做出先前沒有人做出的東西,世界因爲他們多少有點不同。比如創造了微信的張小龍,創造很多軟件思想我司的老馬,Google雲計算的發明人迪恩。能夠看到相比於前面三級,這一級的難度是很大的,大部分的工程師都走不到這一級別。
  • 第一級要求能夠開創一個產業,比如愛迪生開創電燈產業,福特開創汽車流水線產業,貝爾開創電話產業,喬布斯開創智能手機產業。能夠做到這一級的人基本是可以名留史冊了。

根據這個工程師五級金字塔,可以比較清楚的知道自己處在哪個級別,如何努力才能滿足這個級別的要求,來達到技術卓越。

最後思辨

這片文章起名叫技術的迷失,先拋出了技術是什麼這個問題,然後通過Brian Arthur對技術的定義來擴大了技術這個概念的範圍,然後用這個定義論證了日常工作和技術的相關性,最後使用朗道的專業技術人員評價體系尋找如何才能技術卓越的路線。整篇文章看似邏輯嚴謹,但是也存在着瑕疵的。

一個是關於技術的定義由於過於抽象,所以解釋性很強,會讓人覺得這個定義是萬金油,什麼都能用。好吧,我承認使用這個定義是故意的,我希望通過這種方式能夠讓大家對與技術的認知能夠更open一點,擴大邊界,這也可以讓日常的所有工作都可以用來去達成技術卓越。

另外一個是最後把技術卓越這個命題,通過工程師是創造和使用技術的主體,換成了工程師卓越。之所以這樣轉換一個是因爲有朗道這種大師的邏輯支撐,這個五級體系從邏輯上是嚴謹的,另外一個我自己的私心是希望大家能夠明白除了編寫各種電腦裏跑的程序是技術,領導團隊,分解任務,市場判斷,營銷運營也都是技術,我們不是象牙塔裏的科學家,我們通過工程來讓這些技術落地並給這個世界創造價值。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章