失控

時光荏苒，轉眼間從事程式設計師這份很有前途的工作已經十多年。

差不多10年前，在Bas Vodde的極力推廣下，我當時所在的開發小組開始實施敏捷開發(Agile)模式。這大概也是中國最早的一個敏捷小組吧（後來Bas開了自己的敏捷培訓機構，同事中有的轉行也成了中國最早的一批Agile認證培訓師）。經過了這麼多年，回想一下，心裡有了很多感觸。現在總結一下，也許會對現在的敏捷開發有所啟發。所有的文字都是絕對獨家，在敏捷手冊裡你可找不到。

現在說起敏捷開發，往往會遇到兩個極端：要麼很好，要麼很糟！這和當年軟體企業推廣ISO9000或者後來的CMM區別很大。

做ISO9000對企業來說就是做出一堆文件，裝幀漂亮後，放進檔案櫃，鎖好，然後……就沒有然後了。所有工程師們對這些內容基本無感。ISO9000畢竟誕生於傳統的機器生產工業時代，用這套老辦法來衡量新興的不斷變化中的軟體企業，實在有些彆扭。

然後就有了CMM。CMM（Capability Maturity Model for Software）聽著就大氣了很多，“軟體能力成熟度模型”，不是什麼冰冷的“標準”，程式設計師們看著這個模型就受用很多。一家企業能評上CMM的高級別是件很榮耀的事情。一時間各企業紛紛大上快上CMM評級。但是在CMM實施過程中，很多一執行緒序員仍然無感。最大的區別就是鎖在櫃子裡的由一堆工業標準文件變成了另一堆更有軟體業特色的標準文件。而且在所有獲得了CMM5級的頂尖企業中，某國的軟體外包企業佔了很大的比例，而一些無論從技術含量、創新能力或產品品質都屬於全球頂尖的企業卻只獲得了更低的3或4的評級。這其實是很奇怪的事情！

其實，無論ISO9000還是CMM，它們的核心都在於“控制”。

管理者們希望通過各種流程、各種規則來控制軟體開發過程中的資訊、思想、行為，來獲得對未來的產品的安全感。

但是軟體世界早就在不知不覺中發生了鉅變。最典型的例子就是Linux。

人們傳統印象中，作業系統是最複雜的軟體系統。要製作出這樣的系統，一定是世界頂尖公司裡的大量一流程式設計師在嚴密科學的流程管理制度下完成的。就如IBM和微軟所做的那樣。但Linux居然是由分佈在全世界各地、成千上萬名互相不認識的程式設計師來完成的！沒有繁瑣的流程、堅硬的規章制度、專職的直線經理、強硬的專案經理，在幾乎一切的傳統管理手段都缺位的情況下，軟體行業的一個劃時代的偉大產品卻誕生了！而這是前所未有的事情。

十多年前，微軟無疑是世界上的IT業霸主。記得1998年前後有一本在業界很有影響力的書叫做《Microsoft Secrets》，這本書從微軟公司內部各個層面揭示了微軟是如何執行的。當時給我印象最深刻的就是微軟的Daily Build和Auto Testing系統。這是當時大多數軟體公司想都不敢想的軟體工業之理想境界，而擁有當時最複雜而龐大的Windows95與Office程式碼庫的微軟居然能夠做到！要知道Windows95的程式碼量大概有1500萬行左右，這完全超出了當時絕大多數軟體企業的能力。

時過境遷，現在很多軟體企業、第三方組織都已能夠輕鬆建立起這種程式碼規模系統的自動整合系統，甚至更大的程式碼規模也不在話下。計算機軟硬體技術及網路技術的發展，已經使小規模的開發組織獲得了空前的快速迭代能力。

工具的進化引發的人類協作方式的變化其實並不罕見，最典型的是武器與軍隊組織形態的變化。武器越來越精確、威力越來越大、射程越來越遠，原來需要大規模地面部隊付出很大代價才能完成的地面攻擊任務，現在只需要較少數量機動靈活的地面部隊依託各軍種遠端火力支援就能完成了。這時與敵人直接接觸的一線部隊規模雖然變小了，但他們能召集的火力其實是更大了。同時，每個士兵的能力要求也不同了。他不僅要懂怎麼用自己手中的槍，還要懂步坦協同、炮兵戰術、空地一體打擊、遠端偵察、電磁壓制，甚至未來的個人戰場網路系統。因為士兵本身也是武器系統的一部分。一流的武器落在三流的士兵手裡也只是多了一根燒火棍。這種例子在現代戰爭中屢見不鮮，比如全美式現代化重灌備的某國政府軍屢次被一些靈活機動的游擊隊整建制地擊潰。

現在的網路技術能越來越快速地把個體創造的資訊連結到一起，最後這些資訊以一種新的形態展現出來，成為新的產品。組織形式越能匹配這種趨勢，組織就越能把組織內外的資訊價值有效組合起來，形成自身的資訊價值或產品價值。（從這個意義上講，那些線上SAAS就是這個目的。如果那些開發SAAS的軟體公司能夠敢於把自身的組織運作完全基於SAAS，那麼它離成功也就不遠了！）

在產品開發團隊中，使用什麼模式能更有效完成這個資訊連結？

無論是傳統開發模式，還是敏捷開發模式，其目的是相同的：都是為了開發出好的產品和服務，但手段其實大不同：一個是用盡量控制的手段，而另一個是用盡量不控制的手段。這個就如傳統教育和現代教育之間的區別：我們究竟是要把孩子人生中最重要的選擇權交給孩子自己，還是竭盡全力代替孩子做一個看似最完美的選擇？這個答案在中國這個轉型中的傳統大國中見仁見智。傳統開發模式好，還是敏捷開發模式好？這個答案在現在這個網際網路時代成型期，自然也是見仁見智的。

無論如何，“在程式碼中創造世界，在失控中享受自由”，也許就是程式設計師這個職業的樂趣所在。

扁平

2007年初第一次見到Jeff Sutherland本尊。他標誌性的一頭油亮亮的白髮打理得整齊精神，加上緊身筆挺的西裝領帶，更像一個精幹的華爾街精英，而不是程式設計師。但他確實是一名程式設計師：他不僅能碼程式碼，還寫了怎麼碼程式碼的書。

他還有一個身份：Scrum敏捷管理的創始人。

很多有名的洋程式設計師的職業經歷和國內的程式設計師很不一樣。Jeff就是這樣。

Jeff之前是一名職業軍人，但不是普通的大頭兵。他畢業於the United States Military Academy（也就是西點軍校），後成為美國空軍RF-4C戰鬥偵察機部隊指揮官中的精英，在越戰中的執行過大量戰鬥任務。入行IT界還是11年軍事生涯結束後去大學讀博士的事了。所以在他Scrum方法體系中也能看出在世界頂尖空軍部隊服役的經歷對他的影響。

殘酷的戰爭使人們面臨生死存亡的競爭，在這種壓力下，人們會最大限度地摒棄一切多餘的條條框框、改進組織制度，以提高自己的作戰效能和存活的機率。

美軍在20世紀60年代就建立了領先於全球的C4I系統。什麼是C4I？C4I就是指揮、控制、通訊、電腦和情報的整合系統，通過計算機及網路通訊技術，對戰鬥人員和武器進行指揮和控制。這樣的系統和組織方式實現了高效又靈活的資訊流，比如，它不僅能夠實現武裝部隊總司令（也就是美國總統）在1-3分鐘內能夠把命令下達到第一線的作戰部隊，而且一線的士兵也可以輕易獲得整個戰場的情報。同時，美軍的組織結構和指揮系統也進行了改革，推行了“任務式命令”（“委託式指揮法”），最大限度地將作戰決策權下放到各級作戰單元，以最大發揮各級人員的主動性。甚至後來還用法律的形式確定了這種自主決策權，打破了海陸空各軍種之間壁壘，大大減少了指揮的層次。因此，美國得以憑藉不是很多的常備軍力，卻能在全球範圍內快速有效地應對各種各樣的威脅和挑戰（BTW，對於中國軍事現代化，大家經常把注意力只集中在新的武器上，其實軍事組織的扁平化並不比製造殲20的發動機更簡單，甚至更重要）。

整個美軍的軍事系統就是一個超大型的“企業集團”，裡面有各種各樣差異巨大的“事業群”，大的可分為空軍、海軍、陸軍、海軍陸戰隊，再分還可以分成各個高度專業的軍種，它們的“業務”就是一起完成各種戰鬥任務、實現各種戰術戰略目標。“任務式命令”依託C4I系統實現了這個超大型團隊的扁平化，從而最大化激發了各級團隊成員的主動性和創造性。

資訊科技實現了商品銷售的扁平化、軍事指揮的扁平化，它自然也會導致技術創新和產品研發的扁平化。Scrum的本質就是通過各種Scrum工具實現產品開發的扁平化管理，以最大限度的激發工程師的主動性和創造力。

有做專案管理的同學提出無法理解上一篇文章裡提到的“儘量不控制”。這裡舉兩個例子也許可以幫到有此類疑惑的同學。

Michael Jordan時代Chicago Bulls的傳奇教練Phil Jackson一直有個習慣：他在賽場上很少去請求暫停，即便是球隊落後的時候，他往往都是讓球員自己去解決問題，除非是球隊真的是出現了無法解決的問題。教練做的更多的是觀察、協助、服務和啟發的工作。

Steve Jobs雖然以極強的控制慾著稱，但更被稱為是個“好教練”，他“鼓勵員工互相競爭”，“對於結果，他很苛刻，但總是非常公正”，“總是能讓人受益匪淺”。蘋果公司採用扁平的環狀組織結構，員工的工作都“十分獨立，只有很少的微觀管理”。或者說，蘋果的這種控制，更多的是拒絕平庸，而不是要控制工程師。

軟體網際網路產品開發風險有很多，根本上就是一個：“不確定性”。面對不確定性，更多地控制動作並不會使它變得更確定。也許正是因為這個優美的不確定性帶來了更多的可能性和創造性，所以Donald Ervin Knuth和Eric S. Raymond會把Programming稱之為藝術(Art)。面對“不確定性”，有時候管理者不妨“讓子彈再飛一會”。

扁平化管理並不是敏捷開發的專利，但無論如何，扁平化並不容易實現，過程中會遇到各種各樣的阻礙。有的阻礙來自組織能力，有的來自過去的成功經驗，有的甚至來自文化習慣。（所以，有的時候組織沒被拍扁，卻被拍爛了。）

以前私下裡曾和一位管理著一千多名跨國工程師團隊的外籍VP聊起中國工程師和歐美工程師的差異，那個老外說不明白中國工程師為什麼特別喜歡做管理崗位，技術職位做一陣子總想跳到管理崗位上。他反覆問why，因為在他們國家完全不是這個樣子……

在商業企業、特別是在以受過高等教育的年輕人為主體的IT企業中為什麼會出現讓外國資深研發管理者無法理解的現象呢？下面兩個例子也許會提供一些線索。

案例一：以前在某公司曾同時帶了幾個開發團隊。有一次其中一個team的一位中籍工程師私下找我做溝通，提出要個title，比如team leader、scrum master什麼的，哪怕給個更小的頭銜也行，甚至說不用給他漲年度工資、只要給個title都願意。工作好多年了，因為沒有一個“官銜”，他自己會被父母數落，遇到親戚朋友同學問起來更會很丟臉！

案例二：在一次某公司開發部門中高層管理會議上，有的leader感嘆：“我們這些做leader的很辛苦啊，下面有這麼多工程師要養活！”其他很多leader們聽罷也紛紛點頭讚許。
……

外國工程師無法理解中國工程師的這些價值觀和想法，反過來，中國工程師自然也難以輕易理解和接受工程師文化的價值觀和方法論。

工程師文化廣泛根植於歐美社會。在文藝復新時代，受盧梭等思想啟蒙者的影響，上至王公貴族、下至平民百姓，大家都十分熱衷於工具製作和技術創新。美國最有影響力的開國元勳和政治家Benjamin Franklin也是歷史上著名的發明家。現在美國各地隨處可見的巨大的五金工具商場，普通的美國家庭經常會擁有一套比我們的汽修店還要齊全的專業工具。這些都是和工程師文化一脈相承的。

但中國工程師對工程師文化既不熟悉，也不感冒。哪怕是那些自認很西化的中國人，無論他是否意識到，他的血液中也很難避免中國傳統文化中的某個顯性基因。

相對中國工程師，那些從小就熱衷於自己動手進行工具和產品的持續改進創新的西方工程師顯然更能適應敏捷。

管理離不開文化基礎。扁平化的管理似乎更能與工程師文化相匹配。

扁平化的組織更能對事對結果負責、對總體目標負責。工程師文化，使上層和底層有很大的共性，上層聽得懂下層在說什麼，下層也聽得懂上層在說什麼。扁平的組織結構，使資訊損失扭曲最小，上下層的資訊都能互相聽到。
……

一般來說，大家都認同“人才是IT企業的核心競爭力”。同時，很多組織也經常抱怨自己沒有好的人才。這裡舉個例子來看看敏捷模式怎麼幫助組織解決這個問題。

曾有一個比較大的開發專案，由超過兩百名跨國軟體工程師團隊一同完成。按照當時的敏捷流程，產品構架設計每一次更新都會發給所有的工程師做review，以讓所有工程師瞭解產品全域性的需求和構架設計。有一次的關鍵構架設計書發出後，一位普通工程師指出了其中一個重要的構架漏洞，而當時所有的技術專家對這個漏洞都無法提出快速有效的解決方案。眼看milestone就要被推遲，最後還是這位並不在該領域工作的普通工程師通過自己的研究給出瞭解決方案。

Eric Schmidt在《How Google Works》中強調：“ When it comes to communications, default to open. Maximize the velocity and volume of information flow.”（談到溝通，最基本的就是開放。這樣使得資訊流動的速度和數量最大化。）

但在扁平化的敏捷組織中，由於資訊的充分流動，有才華的工程師可以有更多的機會給產品直接帶來價值，也更容易因為自我實現而被“激勵”。其實優秀的工程師就在那裡，他們需要的只是一個沒有資訊圍欄的舞臺！

現在的世界已經是扁平的世界，充滿不確定性！擁抱變化，就是要擁抱不確定性！任何一個管理者都不會認為一個熱衷於迷幻劑、不會碼程式的文青會成為全球IT界的大神，任何一個管理者也不會認為“一群找不到工作的年輕人”能創立世界上最大的電商企業。今天做遊戲軟體的公司，明天會去做手機；今天做支付系統的公司，明天會去造汽車、甚至星際火箭。資訊圍欄除了最終圍住了自己的手腳和競爭力、其實什麼也圍不住。

計算機領域中有個古老而簡單有效的演算法叫氣泡排序（Bubble Sort）。Bubble Sort能夠把一個失序的系統重新排序，同時並不需要把整個系統全部推倒重新排序，而只需要系統中的每個物件和自己身邊的物件做個比較，根據比較結果來交換位置，這樣只需要很少的幾輪交換，最後整個系統就象氣泡在水中自然而然地上浮那樣自然而然地實現了排序。扁平化的工程師文化就象這個Bubble Sort一樣，能夠把整個組織中各個成員的創新和價值最快地呈現出來。

所以，不管是不是使用敏捷模式，資訊的通暢高效流動都是工程師團隊在充滿不確定性的IT世界倖存的關鍵之一。管理是作為價值的連結者和傳遞者而服務於資訊流動、服務於創造力。

某大俠曾說過：“員工的離職原因很多，只有兩點最真實: 1、錢，沒給到位; 2、心，委屈了。 這些歸根到底就一條：幹得不爽。”在BAT剛剛創立、都還沒有成長為高富帥的時代，市面上軟體工程師的薪水並不高。那時很多年輕人拒絕事業編制或公務員的職業機會而入了IT行業，其中重要原因之一就是被IT業“開放平等”的職場文化所吸引。所以我也一直很欣賞阿里的“花名”文化，它和外企中直呼英文姓名的傳統有異曲同工之處，都是推崇一種“平等開放”的工作氛圍，也有利於在研發部門建立起工程師文化。還有堅持實話實說的“阿里味”、橫跨各個技術領域的ATA論壇（阿里內部技術交流社群）等等，都有利於資訊的流動和組織的扁平化。這些都是管理服務於資訊流動、服務於創造力的例子。

沒有敏捷開發，也可能開發出好的產品。應用了敏捷開發，也未必能開發出好的產品。這就像很多企業都在學豐田的精益生產（Lean Production，或稱看板生產），但能做到豐田那樣的屈指可數。因為你可以學豐田的流水線和管理流程，但你學不到豐田的工程師文化！

無論如何，扁平化管理對於有長久工程師文化傳統的歐美工程師也是很大的挑戰，而對於中國工程師更是難上加難。對於那些下了決心要實施敏捷的組織來說，光靠那些老外的理論和經驗是遠遠不夠的，因為你將遇到那些老外從來不曾遇到的困難和問題。

殊途同歸，幾乎每個組織都在聲稱它多麼地渴望變得敏捷靈活。但當真的面對敏捷型組織時，你真的準備好了麼？

作者：濟巔