【舊文搬家】
我的同事王健最近寫了一篇文章。名字叫《從汽車貼膜看專業(yè)團隊》?？戳酥蟾杏|良多。特別是現(xiàn)場管理，和全功能團隊兩點。

我有一個觀點，說到專業(yè)性，傳統(tǒng)行業(yè)比我們IT行業(yè)要強得多。從這篇文章，我們可以看出來，不管是管理人員的現(xiàn)場管理，還是全功能團隊，也就是一線人員的全棧能力，傳統(tǒng)行業(yè)都比我們要強一些。我相信有人就會有些不服了，不管什么現(xiàn)場管理，全功能團隊我們也在做呀。

說的沒有錯，但是，你在it行業(yè)里還真不容易找到這么專業(yè)的一個團隊。而在傳統(tǒng)行業(yè)里，這種水平的一個團隊現(xiàn)在是越來越常見了。這是為什么呢？按說大家都是人，通常來講，IT行業(yè)的人不是素質(zhì)還高一點嗎？我們這個行業(yè)的專業(yè)團隊，不是應該更常見嗎？雖然我們不一定要比你強，但是也不會比你弱得這么明顯啊。

這當然一方面是由于我們這個行業(yè)的工作比較復雜，不容易做到全棧，但我覺得更重要的是，it行業(yè)是屬于知識工作，知識工作者的現(xiàn)場是非常的不明顯，極難做到現(xiàn)場管理。
我們IT行業(yè)的管理者，不管是項目經(jīng)理，產(chǎn)品經(jīng)理，還是技術領導者，大家也是基本和團隊坐在一起。但是坐在一起，并不意味著，就能夠真的在現(xiàn)場。

我們看到在那個貼膜團隊里，團隊領導只需要看一眼，發(fā)現(xiàn)有氣泡，就知道質(zhì)量有問題。也就是說，在傳統(tǒng)行業(yè)進行現(xiàn)場管理的時候，問題都是非常直觀的，非常容易發(fā)現(xiàn)。在軟件行業(yè)想做到一點就難的多，幾年前，我記得我的同事熊節(jié)也曾經(jīng)寫過一篇文章，文章的核心洞見就是軟件開發(fā)的現(xiàn)場，在代碼里。

這個洞見指導思特沃克工作很多年 ，公司里有很多人提出過類似的觀點，于是我們的很多方法就是建筑在這些類似的觀點之上。

然而，如果我們想要追求IT工作者開發(fā)效率的極限的話，這個洞見還不夠極致。經(jīng)過幾年的工作，我發(fā)現(xiàn)，代碼只是軟件開發(fā)工作的第二現(xiàn)場，軟件開發(fā)工作的第一現(xiàn)場，在語言里。
這里說的語言，不是，編程語言，也不是廣義的人類語言，比如漢語、英語。指的是我們在從事軟件開發(fā)工作中所使用的一系列術語，和相關的一系列呈現(xiàn)方式和溝通工具。借用一個技術術語，我們所說的語言是一套僅供軟件開發(fā)所有相關人員使用的、組合的DSL，DSL全稱：Domain specific language，中文名叫做：領域特定語言。

DSL就DSL，還組合的DSL，為什么要說的這么拗口呢？什么叫組合的DSL?我們知道在軟件開發(fā)的過程當中，需要各種不同的角色參與。每個角色有自己特定的領域，泛泛的講可以分為三類：我們把產(chǎn)品經(jīng)理和設計人員所使用的領域特定語言叫做設計語言，把開發(fā)和測試使用的語言叫做技術語言，把業(yè)務人員、組織管理者使用的語言，叫做業(yè)務語言。

所以我們使用的這套，領域特定語言，是把這三類語言組合在一起而形成的一套語言。所以這就意味著我們這套語言非常容易充滿歧義，造成每個角色自說自話卻難以被發(fā)現(xiàn)。

軟件工程里的核心觀點是一個問題發(fā)現(xiàn)的越晚，修正它的成本就越高。比代碼更早的是溝通，比溝通更早的就是語言。我們用語言去描述溝通的錯誤，去描述代碼中的錯誤，我們用什么來描述語言的錯誤呢？還是語言，這就使得整個工作困難重重，難以達成共識。所以我們更需要非常嚴肅的對待，軟件開發(fā)工作的第一現(xiàn)場。

之前一些方法試圖建立純粹的統(tǒng)一語言，所有人都說一套語言，這個方法已經(jīng)被行業(yè)事實上放棄了，我們要承認，各自不同的語言有些部分可以簡單統(tǒng)一成一種表達以消除歧義，有些部分只能結(jié)合。也就是說相關人員要懂多門語言這個現(xiàn)實是我們必須接受的，軟件正在吞噬世界，語言只會越來越復雜。就像我們再努力消除污染，也不能幻想世界回到工業(yè)文明以前了。就算我們再努力的去建立統(tǒng)一語言，也不可能是一門簡單的語言，只能是多門DSL的一個雜合體。

不過由于歷史的原因，在行業(yè)放棄的過程中，由于反對預先設計走的過了頭，不談建模，不談標準化成了一種奇怪的政治正確，導致很多優(yōu)秀的工具和方法被邊緣化了。其實我們憎恨的只是預先設計造成的反饋速度變慢。連帶著憎恨預先設計時代的一些工具，就有點上綱上線了。

幸而最近幾年，各種領域建模的設計方法又重新回歸。最近大行其道的，領域驅(qū)動設計，就是在很嚴肅的，對待業(yè)務語言的設計和使用。而在前端領域，Design System試圖解決前端開發(fā)和設計師之間的語言分歧問題。我個人在從事軟件開發(fā)工程師的培養(yǎng)方面發(fā)現(xiàn)，很多傳統(tǒng)的可視化工具，比如說UML。如果不以繁重的預先設計為目的，來使用這些工具，僅把它們用作提高溝通效率的工具，他們的威力是十分驚人的。

以我本人的團隊為例，我們使用ant design為基礎，設計了我們的design system。使得我們可以在三天之內(nèi)得到一個可以點擊的軟件原型，并在此基礎上，進行各利益相關方之間的需求交流和反饋。在交流的過程當中，我們也刻意的統(tǒng)一了我們的語言。使得我們盡管是一個遠程團隊，但是當我們在交流的時候，很清楚的知道我們在對信息架構在哪一層進行反饋。這不但使得業(yè)務方可以反饋技術方，其實技術方也在引導業(yè)務方。語言的影響是雙向的。

在技術領域里，我們也選擇了隔離性更好的技術架構，使得我們MVP的代碼不會變成我們演進道路上必須長期背負的負累。而之所以在一篇聊“語言”的文章里提技術架構，是因為我們認為，真正的架構不是紙上的，卻也不是代碼里的，而是每個團隊成員心里的架構。實施一個架構必然也是要進行大量溝通，也需要統(tǒng)一語言。

而在交流業(yè)務的時候，我們刻意的劃分了各種不同的子領域又在每個領域當中統(tǒng)一了名詞。統(tǒng)一名詞還是比較簡單的，最難的是劃分領域，我們?yōu)榇送度肓舜罅康墓ぷ?，也犯了一些錯誤，但這些付出是值得的，這之后，我們的溝通變得非常流暢。

具體的實踐有機會再跟大家分享。我在這里僅僅聊一下溝通順暢帶來的價值。溝通順暢的威力并不僅僅表現(xiàn)在溝通的時候可以很順暢的傳遞信息，最重要的是當有團隊成員對信息理解出現(xiàn)錯誤的時候，可以很容易的暴露和給予反饋。

這個優(yōu)勢在IT行業(yè)至關重要。IT行業(yè)的人員流動率接近25%，這意味著每年我們團隊中至少有1/4的人是新人。而即便我們想盡方法讓我們的團隊保持穩(wěn)定，隨著敏捷和精益創(chuàng)業(yè)的相關思想已經(jīng)慢慢成為我們的工作常識，每個項目存在的時間都不會太長，從而使得IT團隊是經(jīng)常性的重組，有時是團隊被打散，有時是同一個系統(tǒng)從一個團隊交給了另一個團隊。如果缺乏一種有效的反饋機制，那么無論是人員流動還是組織重組，所造成的切換成本都是一個可觀的數(shù)字。盡管這個切換成本是無法消除的，但是盡量減少切換成本是我們每個專業(yè)人員應該追求的，尤其是團隊中的技術領導者。

技術領導者重音在領導，而不在技術。尤其在Tech@Core的今天，技術就是業(yè)務。優(yōu)秀的技術領導者更不能把自己變成一個救火隊員，只是被動的響應，盡管救火隊員往往很容易被人所看到而獲得一些關注和贊揚，但在我們中國的文化里，我們都知道還有更高一層的境界，這個境界存在于很多典故中，比如上醫(yī)治未病，善戰(zhàn)者無赫赫之功。同理，我們軟件開發(fā)領域的技術領導者們也應該努力使大多數(shù)問題發(fā)生的基礎消滅于無形，這就需要我們走出我們的舒適區(qū)，深入到軟件開發(fā)的第一現(xiàn)場，進行現(xiàn)場管理才能達成。