我的同事王健最近寫了一篇文章——《從汽車貼膜看專業團隊》。看了之後感觸良多，特別是文中提到的現場管理和全功能團隊兩點。
我有一個觀點，說到專業性，傳統行業比我們IT行業要強得多。從這篇文章可以看出，不管是管理人員的現場管理能力，還是全功能團隊中一線人員的全棧能力，傳統行業都比我們要強一些。相信有人會有些不服，不管什麼現場管理，全功能團隊我們也在做呀。
說的沒有錯，但是，在IT行業裡還真不容易找到這麼專業的一個團隊。而在傳統行業裡，這種水平的一個團隊已經越來越常見了。這是為什麼呢？按說大家都是人，通常來講，IT行業的人能力素質不是還高一點嗎？在我們這個行業中，專業團隊不是應該更常見嗎？雖然我們不一定要比你強，但是也不會比你弱得這麼明顯啊。
當然，一方面是由於我們這個行業的工作比較複雜，不容易做到全棧，但我覺得更重要的是，IT行業屬於知識工作，知識工作者的現場非常不明顯，極難做到現場管理。
我們IT行業的管理者，不管是專案經理，產品經理，還是技術領導者，大家也基本都和團隊坐在一起。但是坐在一起，並不意味著就能夠真的在現場。
我們看到在那個貼膜團隊裡，團隊領導只需要看一眼，發現有氣泡，就知道質量有問題。也就是說，在傳統行業進行現場管理的時候，問題都是非常直觀的，非常容易發現。在軟體行業想做到一點就難的多，記得幾年前我的同事熊節也曾經寫過一篇文章，文章的核心洞見就是軟體開發的現場在程式碼裡。
這個想法在ThoughtWorks有很多擁護者，公司裡有很多人提出過類似的觀點，於是我們的很多方法就是構建於這些類似的觀點之上。
然而，如果我們想要追求IT工作者開發效率的極限，這個洞見還不夠極致。經過幾年的工作，我發現，程式碼只是軟體開發工作的第二現場，軟體開發工作的第一現場，在語言裡。
這裡說的語言，不是程式語言，也不是廣義的人類語言，比如漢語、英語。指的是我們在從事軟體開發工作中所使用的一系列術語和相關的一系列呈現方式和溝通工具。借用一個技術術語，我們所說的語言是一套僅供軟體開發所有相關人員使用的、組合的DSL，DSL全稱：Domain specific language，中文名叫做：領域特定語言。
DSL就DSL，還組合的DSL，為什麼要說的這麼拗口呢？什麼叫組合的DSL?我們知道在軟體開發的過程當中，需要各種不同的角色參與。每個角色有自己特定的領域，泛泛的講可以分為三類：我們把產品經理和設計人員所使用的領域特定語言叫做設計語言；把開發和測試使用的語言叫做技術語言；把業務人員、組織管理者使用的語言，叫做業務語言。
所以我們使用的這套領域特定語言是把這三類語言組合在一起而形成的一套語言。這就意味著我們這套語言非常容易充滿歧義，造成每個角色自說自話卻難以被發現。
軟體工程裡的核心觀點是：一個問題被發現的越晚，修正的成本就越高。比程式碼更早的是溝通，比溝通更早的就是語言。我們用語言去描述溝通的錯誤，去描述程式碼中的錯誤，我們用什麼來描述語言的錯誤呢？還是語言，這就使得整個工作困難重重，難以達成共識。所以我們更需要非常嚴肅的對待軟體開發工作的第一現場。
之前一些方法試圖建立純粹的統一語言，所有人都說一套語言，事實上這個方法已經被行業放棄了，我們要承認，各自不同的語言有些部分可以簡單統一成一種表達以消除歧義，有些部分只能結合。也就是說相關人員要懂多門語言。這個現實是我們必須接受的，軟體正在吞噬世界，語言只會越來越複雜。就像我們再努力消除汙染，也不能幻想世界回到工業文明以前了。無論我們多麼努力的去建立統一語言，也不可能形成一門簡單的語言，只能是多門DSL的一個雜合體。
不過由於歷史的原因，在行業放棄的過程中，由於“反對預先設計”走的過了頭，“不談建模，不談標準化”成了一種奇怪的政治正確，導致很多優秀的工具和方法被邊緣化了。其實我們憎恨的只是預先設計造成的反饋速度變慢，只是在這個過程中連帶上了憎恨預先設計時代的一些工具，這就有點上綱上線了。
幸而最近幾年，各種領域建模的設計方法又重新迴歸。最近大行其道的領域驅動設計，就是在很嚴肅的對待業務語言的設計和使用。而在前端領域，Design System試圖解決前端開發和設計師之間的語言分歧問題。我個人在從事軟體開發工程師的培養方面發現，很多傳統的視覺化工具，比如說UML。如果不以繁重的預先設計為目的，來使用這些工具，僅把它們用作提高溝通效率的工具，他們的威力是十分驚人的。
以我本人的團隊為例，我們使用ant design為基礎，設計了design system。使得我們可以在三天之內得到一個可以點選的軟體原型，並在此基礎上，進行各利益相關方之間的需求交流和反饋。在交流的過程當中，我們也刻意的統一了語言，使得我們儘管是一個遠端團隊，但是在交流的時候，能夠很清楚的知道我們在對資訊架構在哪一層進行反饋。這不但使得業務方可以反饋技術方，其實技術方也在引導業務方。語言的影響是雙向的。
在技術領域裡，我們也選擇了隔離性更好的技術架構，使得MVP的程式碼不會變成我們演進道路上必須長期揹負的負累。而之所以在一篇聊“語言”的文章裡提技術架構，是因為我們認為真正的架構不是紙上的，也不是程式碼裡的，而是每個團隊成員心裡的架構。實施一個架構必然也是要進行大量溝通，也需要統一語言。
而在交流業務的時候，我們刻意的劃分了各種不同的子領域，又在每個領域當中統一了名詞。統一名詞還是比較簡單的，最難的是劃分領域，我們為此投入了大量的工作，也犯了一些錯誤，但這些付出是值得的，這之後，我們的溝通變得非常流暢。
具體的實踐有機會再跟大家分享。在這裡僅僅聊一下溝通順暢帶來的價值，溝通順暢的威力並不僅僅表現在溝通的時候可以很順暢的傳遞資訊，最重要的是當有團隊成員對資訊理解出現錯誤的時候，可以很容易的發現和給予反饋。
這個優勢在IT行業至關重要。IT行業的人員流動率接近25%，這意味著每年我們團隊中至少有1/4的新人加入。即便我們想盡方法讓我們的團隊保持穩定，隨著敏捷和精益創業的相關思想慢慢成為我們的工作常識，每個專案存在的時間都不會太長，這使得IT團隊經常性的重組，有時是團隊被打散，有時是同一個系統從一個團隊交給了另一個團隊。如果缺乏一種有效的反饋機制，那麼無論是人員流動還是組織重組，所造成的切換成本都是一個很大的。儘管這個切換成本無法消除，但是儘量減少切換成本是我們每個專業人員應該追求的，尤其是團隊中的技術領導者。
技術領導者重音在“領導”，而不在“技術”。尤其在Tech@Core的今天，技術就是業務。優秀的技術領導者更不能把自己變成一個救火隊員，只是被動的響應，儘管救火隊員常常因為很容易被人看到而獲得一些關注和讚揚，但在中國的文化裡，我們都知道還有更高一層的境界，這個境界存在於很多典故中，比如上醫治未病，善戰者無赫赫之功。同理，軟體開發領域的技術領導者們也應該努力使大多數問題發生的基礎消滅於無形，這就需要我們走出舒適區，深入到軟體開發的第一現場，進行現場管理。