能在1個小時內快速做出決定的項目,58%都獲得了成功。如果花超過5個小時來做決定,成功率就幾乎為零。決策拖延越久,代價就越高。Scrum的關鍵經驗是,讓最接近工作的人來做決定,速戰速決。

你突然遇到一個問題——你剛剛發現了它。

它可以是任何情況。比如,你在建造東西時,意識到設計需要調整;或在計劃工作時,遇到未曾預料到的情況,需要你立即做出反應。我應該馬上做那件緊急的事情,還是把緊急的事情放一放,去做那些非常重要的、以後會非常有價值的事情?

這就像德懷特·艾森豪威爾著名的決策象限,根據重要性和緊迫性對事情進行排序:

假設你被困住了,你必須決定新遇到的棘手問題屬於哪個象限。你需要與誰核實?要等委員會開會嗎?是不是每個人的日程表都排得滿滿的,今天,或者明天,甚至後天,都沒辦法做出決定?如此延誤的代價是什麽?

決策延遲

斯坦迪什集團的創始人兼董事長吉姆·約翰遜幾年前就開始對決策延遲問題產生興趣。斯坦迪什集團通過訪談、分組座談會和問卷調查等方式,對項目如何在全球運行進行初步研究。他們從1985年就開始在這麽做,研究了數以萬計的項目。他們定期發布問題報告,其中包含說明項目成功或失敗原因的各種各樣令人著迷的數據。全球采用Scrum的項目成功率如下圖所示:

比較而言,敏捷項目的平均成功率為42%,而傳統項目的平均成功率誒26%。

Scrum是大多數敏捷項目的實現方式。與傳統項目相比,敏捷項目失敗的可能性不到一半,但成功概率要高得多。這是切切實實、有據可查的數字。

但是我們要清楚:並不是每個敏捷項目都有很好的結果。吉姆和Scrum公司的同事一直在研究為什麽有50%的敏捷項目仍然麵臨挑戰、延遲、預算超支或讓客戶不滿意等問題。

項目失敗的根本原因是什麽?是什麽使Scrum項目比傳統項目更有可能成功?幾年前,吉姆在采訪馬薩諸塞州采購處處長時,突然想到了這個問題。

“處長給我講了自己親曆的事情,”吉姆說,“那位處長以前在波士頓市政廳工作過。他談到一種情況,當時有個項目,他們必須得到副市長的批準,才能推進這一項目。他們有60個承包商在等待副市長的批示,60個人在6個星期內都無法行動,做一個決定需要花6周時間。”

吉姆很是驚愕,認為這一定是一種反常現象。所以他開始給自己的研究加上一個問題:“你做決定的速度有多快?”對許多有問題的項目進行深入研究之後,吉姆意識到決策延遲並不是反常現象,而是普遍現象。在失敗的項目中,人們總是當斷不斷。吉姆發現,真正不可思議的是,所涉及的決定多數時候並不特別複雜,也不特別困難,通常都是司空見慣的日常決策,但決定愣是做不出來。

自從就決策速度問題開始提問之後,吉姆一次又一次地碰到當斷不斷的問題,於是他便開始進行基準測試——實際測量人們在知道必須做出決定的情況下,需要多長時間才能做出決定。因為在任何項目中,都要做很多決定。

“結果如何呢?”吉姆說,“數據顯示,對於一個項目而言,平均每花費1000美元,就要做一個決定。對於一個百萬美元的項目,需要做出上千個決定。”決定拖延越久,代價就越高,成本呈現快速累加的趨勢。這要歸因於愛因斯坦廣義相對論的奇妙推論:時間不僅和空間是同一回事,和金錢也是同一回事。因此,吉姆提出一個衡量標準,用來衡量從明確需要做出決定到做出決定需要多長時間,他稱之為“決策延遲”標準,然後將其與項目成功的可能性進行比較。他研究了全球數百個項目,得出了什麽結果?情況比你想象的還要糟。

2013-2017斯坦迪什集團

圖表顯示了數百個項目的最終結果。對於可以在1個小時內快速做出決定的項目,58%都獲得了成功(按預算準時完成)。如果花超過5個小時來做決定,成功的概率就會直線下降:隻有18%的項目能成功。5個小時不是很長的時間。

因為結論觸目驚心,吉姆花了一年的時間才決定發表研究成果。慎重起見,在成果出版之前,他還到商學院和研討會上做了演講。

“聽眾的反應特別有趣,”吉姆回憶道,“一開始他們說,‘這不可能是真的。這不可能是根本原因。’然後他們考慮再三,改變了看法,對我說,‘你可能真正參透了其中的奧秘。’”

最關鍵的問題是:大部分決定都是簡單瑣碎的。但如果企業行事死板,等級森嚴,決策必須沿著審批鏈層層上報,然後再層層下發,那麽決策過程就會耗時良久。

我們與一家大型全球汽車公司有過合作,他們使用的是一種通用的日式審批製度,叫作“稟議”(ringi[1])。其目的是就應該做出什麽決定在管理層中達成共識。有人拿出提議後,該提議就會在決策鏈中的每個人中間流通;等每個人都同意,最後經過高層領導簽字同意,決定就做出了。稟議製的理念是,你必須在幕後默默工作,以建立共識,為一項提案創造肥沃的土壤。日本人把這個叫作“根回し”(nemawashi[2]),字麵的意思是“修根”,即準備移植樹木時,圍繞樹根開挖。

讓我講一個故事,來說明稟議製這種運作方式如何令人沮喪。假設你在美國的一家汽車工廠工作,想花錢買點東西,比如為工廠添置一台新設備。盡管在年度預算中已經為新設備撥過款,但你還得提交一份書麵“稟議”,也就是必須寫一份詳細的、有說服力的商業案例來說明為什麽要花這筆錢,還必須包括所有的會計數據:要花多少錢,錢從哪裏來,流向誰。再說一遍,同樣要提交書麵文件,然後還要提交環境評估報告,明確這台機器將使用多少電,可能會產生什麽排放影響。所有這些都要寫在紙上,這疊紙就是“稟議”。

然後,“稟議”必須得到批準。首先報送規劃中心,一個工程師告訴我:“規劃中心必須對‘稟議’進行審查,核實一大堆我們不明所以的東西。”審查後,規劃中心要麽將其打回,要求修改,要麽予以批準。

一旦核準,就必須走簽字程序,別忘了,整個流程都是以書麵形式進行的。首先,需要由申請者的經理簽署,然後由高級經理簽署,然後是集團經理、總經理,可能副總裁也要簽署。然後經理、高級經理、集團經理、總經理再度簽字確認,分管規劃中心副總裁也必須簽字。由於是在製造廠工作,可能還得讓負責安全生產的總經理簽字。

就這還不算完。下一步,所有簽過名的文件必須走財務流程,通過同樣的審批鏈。如果新設備涉及信息技術部,信息係統總經理和分管副總裁的辦公桌上也必須出現這些文件。如果決策足夠重大,全套“稟議”文件可能還要呈送集團總部,再次經過層層審批。

與我交談的那位工程師隻是要做一個小的項目,花費在四五十萬美元,卻需要35位負責人用鋼筆在同一張紙上弄出35個簽字(這還不算極端,有時一份文件需要50人簽名)。這需要4~5個月的時間,甚至可能需要更長的時間——長得多的時間。沒辦法,他們現在所做的是創建一種“稟議”前的“稟議”,以便提前得到一些錢,來啟動汽車開發(請注意,這筆錢已經被列入預算)。

他們組建了一個團隊,其任務是使整個過程實現最低限度的自動化。自然,他們使用的是Scrum。他們的目標是什麽?擺脫繁文縟節。在無數的反饋回路中流轉文件,可以說是非常緩慢的。他們還將使規劃中心所做的一些檢查實現自動化。

這將帶來兩個好處。第一,自動化將使過程清晰可見。現在的問題是,沒有人知道文件傳到了誰的辦公桌上,所以也沒有人掌握整個過程的進展情況。是差不多簽完了,還是簽了一半?是不是因為我們不知道的原因,被某人耽擱了?第二,照目前的情況看,如果你想複製一份幾年前的“稟議”,因為你要做的事情與那份“稟議”請求做的事是一樣的,你就必須找到提起“稟議”的人,並希望他們存有紙質副本,然後從那裏複製。他們可能存有紙質副本,也可能沒有。通過數字化,至少可以回頭看看已經被批準的“稟議”並複製下來。

所有這些層麵,所有這些審批鏈,往往導致錯誤的人最終做出特定的決定。有不同類型的決定:有些是技術上的,有些是業務上的,有些是人事上的。雖然有些決定很重要,但也有一些並不重要。不同類型的決定應該由不同類型的人做出,需要由最了解情況的人根據既定情境做出決定。

“Scrum之所以如此簡潔,是因為可以將決策下放到團隊層麵,”吉姆說,“在Scrum中,隻有兩個決策者,產品負責人和團隊。因此,需要由利益相關者或主管做出的決策較少。”

這是關鍵。隻有真正擁有最多知識、最了解情況的人,才應該做決定。這樣才能速戰速決。如果做一個決定要花5個多小時,那麽這幾乎是一個肯定的信號,表明你必須把它送上審批鏈。

1個小時。這就是目標,就是做出決定需要的時間。等待委員會做出決定無異於與命運女神訂立自殺協議。那麽,該如何縮短決策時間呢?

衡量會議的成本

假定你需要做一個決定,所以你決定開個會。假設召集20個人參加會議,要花1個小時才能做出決定。你不妨捫心自問:做出這個決定要花多少錢?單單是時間成本,單單是這1小時所消耗的金錢。現在想想,你每周要參加多少毫無意義的會議。

我的一個朋友曾經在一所常春藤盟校工作。他告訴我,有時甚至直到走進會場時,他都不知道要開的是什麽會。即使他知道開的是什麽會,會議也一直沒完沒了地開下去。在此不妨做些數學運算。我們估算,每次會議大約花費1000美元。這位朋友每周至少要去開10~15次會,加起來要花費多少時間成本?

然而,真正的問題甚至更糟:在會議中做出的決定很可能被推翻。根據斯坦迪什的數據,有超過40%的會議決定被推翻。假設在會議上做出一個決定,假設離下次會議還有一周時間。在這一周內,開始執行第一個決定,但在下次會議上,每個人都改變了主意,做出一項新決定。所以,不僅是浪費了一周時間,現在還不得不撤銷剛剛完成的工作。這就像挖一個坑,挖了再填,勞而無功。

根據斯坦迪什集團的研究,出現這種情況的原因有兩個:一是參加會議的人,一是沒有參加會議的人。實際上,會議室做出來的決定往往是由會議室裏嗓門兒最大的人做出的。他們猶如推土機,強力推壓別人,以得到他們想要的決定。會議結束後,人們各回各的辦公室,心中憤憤不平:哼,回頭再想想,我不同意這個決定。我要在下周的會議上提出來。

還有那些沒有參加會議的人。他們也許應該參加,卻沒能參加。無論如何,他們都覺得自己應該參加會議。為什麽不征求他們的意見?好吧,他們肯定會在下次會議上露麵,讓眾人聽取他們的意見。

吉姆·約翰遜說,倘若一個項目每天失敗一點點,每延遲一天,項目失敗的可能性就增加一分。一天一天,慢慢走向災難。

決定做哪些決定

實施Scrum是為了發現拖累你的問題。Scrum能夠揭露問題,把問題暴露於光天化日之下。當然,當問題在一個衝刺接著一個衝刺中不斷出現,而團隊也期望這些問題能夠得到解決時,一些人就會開始說問題是Scrum造成的,並不在於問題本身。其實,問題始終是存在的。

問題在於,有各種各樣的問題。而解決各種問題的辦法並不在於那些坐在總部辦公室中的管理層主管,而在於那些與客戶直接接觸的人——如果你願意的話,也可以說解決問題的辦法在於各個“節點”。通常,人們躋身管理層之後,地位升得越高,離第一線實際發生的事情就越遠,同時也越相信自己對解決方案有最好的洞察力。

將決策層踢開的一個激進的例子是未來工業株式會社。未來工業株式會社生產電氣安裝設備——開關箱、電纜、導管之類的產品。與大多數日本公司不同的是,未來工業株式會社完全不搞“稟議”那一套,該公司的創始人是山田昭夫。山田長期擔任公司首席執行官,直至2014年去世。山田認為“稟議製”極其荒唐,所以取締了“稟議製”。他對員工們說,你認為怎麽做最好,就怎麽做;又說,讓最接近工作的人來做。山田在其著作《員工最愛的幸福企業》中寫道:“我是個傻瓜,不這麽做,叫我怎能做出判斷呢?”在他自己的公司裏,他經常是看到某某員工的新名片後,才了解到日本某地新開了銷售辦事處。員工們自己決定創建新辦事處時,就會找一座大樓,在裏麵租一塊地方,雇用和發展新員工。山田寫道,如果他不允許員工通過這種方式做出自己的決定,員工將不得不花費大量精力說服領導,領導就不得不去做完全不熟悉的事情。

然而,在大多數公司裏,領導們堅持要了解一切,掌控一切,做出最後的決定,從而導致對情況了解最少的人做出種種決定。因為擔心得不到足夠的信息,領導們就要求得到更多的信息,因而耽誤係統的運行。然後,領導又開始擔心自己可能會犯錯誤,於是就召開委員會會議來分散決策權。

就我所知,一家大銀行成立了一個風險委員會,成員有40多人。銀行的任何提案都必須得到這個委員會的批準。委員會召開沒完沒了、扼殺靈魂的電話會議,一討論就是好幾個小時。等到真正做出決定時,已經搞不清是誰提出的主意,也搞不清一開始想解決什麽問題了。如果結果證明這是一個壞主意,也沒有人會被追究責任。該銀行曾經做出過一些草率的決定,結果被政府罰款數千萬美元。設立風險委員會是為了保護該銀行,管理層真心不希望再度發生失誤,所以把一幹要人統統派到風險委員會,告訴監管機構:看,我們高層領導正在確保不再犯類似錯誤。然而,至此,風險委員會不僅阻止了做出糟糕的決定,而且完全阻止了做出任何決定,最終做出一個決定需要幾個月時間。幾十個人經過曠日持久的討論,投入大量政治資本,最終做出一項決定,已經確保萬無一失,它不可能是錯誤的決定。因為在這個問題上施加了如此多的行政智慧,出錯是不可能的。可結果還是會出錯。於是,他們得出結論:一定是那幫執行決定的討厭鬼沒有落實好。不幸的是,這種風險委員會在金融領域非常普遍。

最初定義非常簡單的事項很快就會超出其初衷。委員會成員不是壞人,但他們建立決策控製係統為的是獲得認同,這不僅會減緩事情的發展,而且幾乎可以確保做出錯誤的決定。因為,幾乎可以肯定的是,當他們終於做出決定的時候,時機已經錯過。在做決定期間的幾天或幾周時間裏,問題已經以某種方式得到解決。哪怕你選擇不做決定,你還是做出了選擇。

Scrum在這裏行不通

我經常從Scrum懷疑論者那裏聽到一種論調:Scrum在這裏行不通。我們做的事情太複雜,太不可預測,Scrum這樣給予團隊自主權的係統難以做到。我實在搞不明白他們為什麽相信傳統的項目管理方式可以處理他們獨特的項目,搞不明白他們為什麽對此深信不疑。我也搞不明白:為什麽他們認為對於軟件業來說,Scrum可能很好,但是他們的領域超級複雜,比搞軟件要困難得多,所以Scrum不適用。

我經常教授對公眾開放的課程。令人難以置信的是,來聽課的人所從事的專業五花八門,從銀行家、製造商、出版商、生物製藥生產商,到研究人員、服務提供商、教育工作者和非營利組織工作者,形形色色,幾乎無所不包。學生們的行業、專業知識和角色的多樣性令人驚歎。

但是,如果你是懷疑論者中的一員,我想和你分享一個人的經驗,他在一個(可能)比你試圖完成的任務風險更高、變化更快、錯誤空間更小的領域中實現了Scrum。

幾年前,美國海軍指揮官喬恩·哈斯打電話給我,說不久前接手了一個代號為EODMU2的部隊,即第二爆炸物處理機動中隊,他想在部隊中實施Scrum,想在地球上最苛刻的環境中,以更快的速度、更高的質量前進。

爆炸物處理中隊是美國特種部隊中最小的軍種,人數隻有數千。但他們必須能夠在地球上任何環境下與任何其他部隊一起合作,任務是摧毀一切可能爆炸的東西,使之失效,從地雷和炮彈,到簡易爆炸裝置。他們能夠在陸地工作,也能夠在水下工作,甚至可以使世界上最致命的武器,那些裝有核、化學或生物載荷的武器,變得安全。他們也執行其他機密任務,恕我在此不便言明。

喬恩決定用Scrum來管理他指揮的這支三軍中要求最為苛刻的部隊。鑒於喬恩的工作性質,很少有人能采訪到像喬恩這樣的人。盡管如此,我還是向喬恩提了12個問題,關於Scrum和他的工作內容。他被允許通過電子郵件回答其中的9個問題。我不想把話塞進他的嘴裏,所以我將分享一下從他那裏收到的電子郵件。

喬恩的回應以如下免責聲明開頭:

以下內容僅代表作者本人的觀點,不代表海軍遠征作戰司令部、海軍部、國防部和美國政府的觀點。

問:你第一次聽說Scrum是什麽時候?

我第一次聽說Scrum是在我準備當指揮官的時候。我聯係了一些導師,整理出一份閱讀清單,內容涵蓋從領導力、管理手段到溝通技巧、情商等多個主題。正是通過這個過程,我找到了Scrum。看到Scrum後,我決心通過閱讀《敏捷革命》來深入學習。大約兩年前,我開始了學習敏捷性和Scrum的旅程。

問:是什麽促使你在爆炸物處理中隊實施Scrum的?

我們盡可能地去嚐試,而不是做決定。做實驗要具有一定的必要條件。首先,成本必須低,風險必須極低。實驗在性質上也必須是暫時的,即使證明是不成功的,也必須是可逆的。最後,必須有可以監測的度量標準,以查看實驗是否達到預期結果。

Scrum滿足了所有這些需求。

開始Scrum不需要花錢;實施Scrum的風險很低;Scrum實驗是暫時的,如果不成功,可以很容易掉轉槍頭;Scrum還包含了速率(Velocity)等指標來評估其有效性。通過度量每周的工作效率,可以跟蹤每周的生產率,由此可知團隊速率。

問:Scrum的結構是什麽樣的?你是怎麽設置的?

我們規劃了Scrum的結構,使之與Scrum的角色、活動和工具一致。Scrum主管由主任參謀擔任,產品負責人由指揮官擔任,而Scrum團隊則由剩下的關鍵參謀人員構成。隨著我們對司令部每個成員所支持的產品和服務的理解不斷完善,小組的組成也隨之發生調整。

問:產生了什麽樣的直接效果?

團隊速率從每天提高4個點開始,穩步增長到每天提高50個點。其直接效果是改善溝通、優先順序、成就任務。

問:影響最大的因素是什麽?為什麽?

影響最大的因素是確定所有活動的目標和議程。雖然許多活動反映了軍事生活中的習慣行為,但我們缺乏通過實施Scrum所獲得的目標和議程的清晰度。

時間定量(Timeboxing)也成為我們日常生活中必不可少的一部分。

時間定量和理解每個項目的目標對我們如此重要的原因是,我們可以在每次團隊會麵時,對照共同的、被充分理解的、深思熟慮的目標來衡量我們的效率。這使我們能夠更加專注,進而促使我們能夠完成更有意義的工作。

問:你能舉個例子說明可以用Scrum做一些以前不能做的事情嗎?

作為一名領導者,我能更加適應自己的行為對團隊的影響。通過嚴格的衝刺回顧,我知道我的行為是如何影響團隊幸福感的。

舉個例子。在一個衝刺中,我督促團隊完成一個特定的目標,這個目標與我們進入該衝刺時的優先事項不一致。在衝刺回顧會上,我征求團隊的意見,並得到了我的行為是如何導致團隊幸福感急劇下降的真實反饋。如果沒有Scrum,團隊就不會有向我提交反饋的機製,我也永遠不會知道我行為的結果。

問:遇到了什麽困難?你需要修改什麽嗎?

很難說服團隊,讓每個成員都相信所有的項目都需要進行衝刺。雖然人們廣泛接受了每日立會,但有人對我們在會議上花費了大量時間進行待辦事項清單改進和回顧表示不理解。逐漸地,隨著團隊開始理解這些事情的影響,比如擁有一個幹淨的、準備好的待辦事項清單,或者在衝刺回顧會議上獲得有關團隊幸福感的數據反饋並征求團隊持續改進的建議,團隊對這些事情更加認可,更為接受。

問:在整個衝刺過程中,你是如何以及在哪裏執行每一個項目的?

衝刺從星期一早上開始,我們在每周的協同化會議上會見所有的排。這使我們能夠征求指揮部內所有小組的反饋。

在此之後,我們進入了製訂衝刺計劃階段,將剛剛收到的信息納入衝刺計劃中。衝刺計劃完成後,我們進入每日立會,討論如何工作。這些都是在我們的會議室裏完成的。

我們在同一個會議室使用團隊展示板進行每日立會,指揮部中的任何人都可以看到這個展示板。周三下午,我們在團隊展示板前開會,對待辦事項進行優化梳理,包括討論和確定要優先完成的工作。周五,我們召集全體水手,向他們介紹我們所完成的工作。這是我們的衝刺複查,下午,我們在團隊展示板前集合團隊進行衝刺回顧。

問:你離開後,Scrum還會繼續嗎?

未來不可預知,但是基礎已經打好,基礎設施已經存在,可以確保Scrum在我任期結束後繼續存在。

現在,回想一下剛剛讀到的內容。去掉偶爾提到的軍職和水手等內容,把注意力集中在要點上。這不是一個軍事案例,這是Scrum在複雜、困難和不可預測環境中工作的一個例子。

哈斯指揮官和他的隊伍向來技藝精湛,積極上進。作為特種部隊,他們可以說是毋庸置疑的佼佼者中的佼佼者。然而,實施Scrum之後,哈斯和他的團隊發現,在18個月的時間裏,生產率從每天提高4個點增長到每天提高到50個點,實現了1250%的增長。

盡管他們所做的工作涉及高科技,但這不是一個軟件初創企業的故事,甚至也不是一個產品開發團隊的故事。在某種程度上,他們相當於一家服務公司,提供高度專業化、危險和致命的服務。自從我和喬恩一起工作以來,一直有源源不斷的海軍特種兵來上我的課。這些人尤其關注結果,對於不能讓他們更快、更有效的事情一概零容忍。

作為一名前記者,我知道抱有懷疑精神是有益的。但懷疑精神必須與接受證據相平衡,否則,懷疑精神就會適得其反,甚至具有破壞性。懷疑精神一旦成了害怕改變的偽裝,就尤其有害。

把規則控製在最低限度

20世紀80年代初,在密歇根大學的所在地安娜堡,有一位名叫克裏斯托弗·蘭頓的研究生,此人著迷於在計算機中建立生命模型,開始研究他所謂的元胞自動機(Cellular Automata)。

元胞自動機是網格上的細胞,其狀態根據一組規則隨時間變化。每個細胞都在其他細胞的鄰域中,其他細胞的狀態會影響它們。最簡單的鄰域就是細胞間的相互接觸。規則可以很簡單:例如,如果我旁邊的單元格是打開的,我也打開。更複雜的情況是,如果我的兩個鄰居是開著的,一個鄰居是關閉的,我就關閉。

這很快就會變得非常複雜。數學太過難懂,在此還是免談為妙。蘭頓所做的是根據規則集是否引起很大的變化,來對規則集進行分類。他將度量標準稱為λ。λ值越高,規則集引起的變化就越多。λ值越低,驅動的變化就越少。元胞自動機的有趣之處恰在於此。如果λ值過低,整個係統很快就會凍結和靜止。如果λ值過高,係統則會陷於混亂。但是,在惰性和無序兩種狀態之間存在一個相變。規則不能太嚴格,太嚴格會使係統癱瘓;規則也不能太寬鬆,太寬鬆會使係統無序。必須有剛剛好的結構,不多不少,正好處於要混亂還沒有混亂的邊緣。

事實證明,這種混沌邊緣學說不僅在數學和計算方麵很有趣,還可以描述很多不同的事物。它所描述的對象被稱為自適應係統。在自適應係統中,隻有係統運行起來,你才能看到結果。即使你完全了解係統的每個部分,也隻有當這些部分開始相互影響時,你才會從中看到顯露出的屬性來。此前,你無法預測這些屬性會是什麽。

我父親說,自適應係統就是推動Scrum誕生的頓悟。他讀到蘭頓的論文時,正在一家銀行管理一個大型瀑布項目。蘭頓的論述使他明白了為什麽他的項目拖延了好幾年,而且超出預算數千萬美元。蘭頓從混亂的邊緣看到了數字生活中最高的進化速度——這正是Scrum的設計初衷。

以交通為例。每天早上,地球上的人們,彼此之間沒有經過什麽討論,便一躍而上,開著數億輛汽車,在上班的路上奔馳。你就是其中一員。咖啡在手,你就成了交通係統的一部分。可能出了事故,有人減速,想看一看究竟。然後,後麵的人再慢一點,然後是下一個人,很快就產生了漣漪效應,導致整條高速公路交通堵塞。你決定脫離困境,離開高速公路,開到當地街道上。但你並不是唯一產生這種想法的人,很快,車輛就在住宅區的街道上狂奔,堵塞街道。所以你試著走另一條路,發現如果沿著小巷開車,穿過雜貨店的停車場,可以繞過擁堵。既成秩序就是這樣,需要通過個人行動尋求解決方案。

不僅僅是元胞自動機以複雜的自適應方式行動,經濟、生態、神經係統、團隊,甚至是社會本身均以複雜的自適應方式行動。倘若規則太嚴格,則什麽都無法改變,文化僵化,一事無成,最終,結構崩潰。但如果規則太鬆散,就會陷入混沌,街頭騷亂,人人為己,社會完全喪失凝聚力。

混沌邊緣是發生有趣變化的地方,最好能把結構的狀態剛好控製在混沌邊緣,駕馭它。這樣,創造力就會開花結果,創意得以產生和應用。這樣既有表達自由,但也有對表達自由的控製。

這種係統的另一個奇怪之處是,微小的變化可以以非線性、動態的方式放大。換言之,如果改變一件事,整個係統都會改變。這使得單個元素能夠自發地、動態地解決問題。這也使得在過程一開始無法確定接下來會發生什麽,盡管最後的結果可能看起來很明顯,給人的感覺是事情本來就應該是這樣的。以美國革命為例。今天看來,殖民地起義、丟棄英國人、建立美利堅合眾國,似乎都是不可避免的。但閱讀當時的資料就會發現,沒有人知道會發生革命,也沒有真正的革命計劃,直到事情趕到那裏,殖民地的居民才知道發生了什麽,其成功可謂僥幸。

我想起了亞瑟·韋爾斯利是如何談到滑鐵盧戰役的。滑鐵盧戰役一勞永逸地結束了拿破侖時代,韋爾斯利稱之為“你一生中見過的最接近功虧一簣的勝利”。他在一封信中這樣描述滑鐵盧戰役:

一場戰役的曆史,就像一場舞會的曆史一樣。有些人可以回憶起所有的小事件,而這些小事件的重大結果是戰爭的勝利或失敗,但沒有人能回憶起這些事件發生的順序或確切的時間,而這些事件的價值和重要性卻因此而大不相同。

事後,一切似乎都顯而易見。然而,沒有人能真正回憶起所有當時起過作用的個體力量。可能就是因為一個人的一次行動,因為在某一時刻,做了正確的事情,結果一切都變了。我發現,在一個有時個人行為似乎沒有影響的時代,如果恰到好處地觸動既成秩序,一個人就可以改變一切。這一發現讓我歡欣鼓舞。

傳統管理層對複雜問題的常見反應是建立更多的控製機製和更多的規則,以控製混亂;更多的紅綠燈和更多的攝像頭,從而使整個體係的齒輪停止轉動,決定根本無法做出。

Scrum試圖給人們一個工具,來管理各種類型的係統。Scrum不是試圖限製係統,而是構建適度的結構和適度的規則。它並不是刻舟求劍,而屬於精益化管理。每個人,都能貢獻自己的價值。

一家全球性石油公司請我們與他們的一些團隊合作,從而決定他們在哪裏鑽新井。他們有一套精密的階段門係統,它需要大量的監督、大批的文檔和許許多多的會議,工程師們必須通過這一係統工作。Scrum公司的教練到達那裏後,把團隊變成Scrum團隊,我們告訴管理層:不要再告訴他們該做什麽。相反,要成為他們的導師。每個團隊成員都是一個單獨的行動者,大家一起工作,以實現共同目標,即交付新油井。給他們行動的自由!當然,團隊確實需要拿出一些文件和數據來,進行正確的研究,但是他們弄清楚了需要什麽來做出鑽探的決定。我們讓他們做的就是談論他們在每個階段實際生產的東西,並把結果掛在牆上,使每個人都能看到。然後,通過忽略傳統的步驟,轉而專注於可交付的成果,他們就可以確定工作的優先級:他們可以看到團隊如何協同工作,如何以增量的方式交付成果。他們對階段門係統進行限製,並將其轉化為可執行的待辦事項清單。

在Scrum中,團隊中的每個人都貢獻自己的感想、創意和洞察力,從而塑造整體。在傳統結構中,這些想法被係統所壓製。係統指揮一切,限製一切,組織越來越繁複。整個體係越拖越慢,齒輪最終停止轉動。

Scrum繞開傳統管理結構,關注並利用不確定性和複雜的係統動力學。Scrum不是通過將決策集中在一個地方來實現的,而是通過將決策轉移到各個“節點”上來實現的,是通過將決策轉移到團隊和產品所有者來實現的,學問在“節點”上。因此,通過轉移決策,事情實際上可以不用等待就完成了。Scrum是一個有目的的複雜係統。或者用蘭頓的話來說,是具有確定性的混沌。

完美是良好的敵人

無論做什麽決定,真正的答案隻會從係統中各個元素的相互作用中產生。在此不妨再引用艾森豪威爾的話,以資佐證:

計劃毫無價值,但規劃就是一切。二者的區別非常大,當你為緊急情況做計劃時,必須從這一點開始:“緊急情況”的定義就是情況出乎意料,因此它不會按計劃發生。

但是人們喜歡計劃(尤其是他們自己的計劃),於是就製訂出很多計劃。人們想要完美的計劃,於是就需要更多的報告和數據來幫助其做出正確的決定。然而,這不可避免地需要越來越長的時間。結果,非但做出決定的目標無法實現,做出決定的過程反而成了目標。經過三番五次的研究、聽證、辯論,實際上勞而無功,一無所成。決策的過程可能會持續很久,這取決於決策的性質,因為每個人都想要完美的計劃,以為隻要掌握足夠的信息,就可以使之完美。

然而,完美的計劃是不存在的,因為係統是動態的,不可能預知其結果。人們唯一能做的就是嚐試些什麽,並得到反饋。有行動總比沒有行動好,不要猶豫不決,行動起來。在某種程度上,做什麽並不重要;重要的是為了學習和進步,要有所行動,有所做才能有所作為。

Scrum所做的就是給你一個快速的反饋,讓你知道一個決定是好是壞。Scrum允許你轉向,改變主意,尋找一條不同的道路,朝著目標前進。每一個快速的決定都會為下一個決定提供情報。道路從實踐中產生。

1999年,在IBM公司工作的戴夫·斯諾登想出一種看待問題的方法,幫助領導者了解其麵臨的是什麽樣的問題,應該尋找什麽樣的解決方案。斯諾登稱這種方法為Cynefin框架。Cynefin一詞來自威爾士語,意思是“暫棲地”“立足之地”。斯諾登用這個詞為自己的理論命名,是因為他認為想解決問題,首先必須弄清楚自己的立足點。

在斯諾登的框架中,第一類問題是簡單問題,或者說明顯問題。簡單問題是一種已經解決了的問題,實際上它一直存在最佳的有效解決方法,一旦能確定問題很簡單,就可以從魔術袋中拿出一個已知的秘訣來運用。如果你在打撲克,千萬不要把牌亮給對手,就像銀行不應該向資產負債率不明之人放貸。在簡單的問題中,因果關係不僅清晰,而且顯而易見。

第二類問題是困難問題。困難問題是一種已知方法的未解難題。以石油公司為例:當地質學家進行地震勘測以了解在哪裏可以開采石油時,他們知道自己不知道答案,但知道如何找到答案。這是專家的職責領域。一旦確定了問題可以解決,就可以找出解決方案,盡管解決起來可能很棘手。如果掌握足夠的知識,就可以找出因果關係。我把汽車開進維修店時,總會想到這個。汽車發出一種奇怪的聲音,我很擔心。我不知道如何解決這個問題,但我知道技工要麽知道如何解決這個問題,要麽能夠弄明白問題的所在並想辦法解決。

第三類問題是複雜問題。複雜問題是我們一直在討論的問題,隻有在事後才能弄清楚事情發生的原因。解決這類問題,必須采取一些行動。在再次行動之前,需要做一些嚐試,來看看會發生什麽。

複雜問題是我們大多數人都要麵對的問題。我們始終麵對複雜問題,答案不得而知,各種力量也不得而知,但我們必須做點什麽。做點什麽之後,接下來發生的事情會讓你大吃一驚。

讓我講講Twitch公司的故事。可能有人對Twitch公司不明所以,在此不妨做一番簡單說明。它是一家電子遊戲直播平台,若不是事後諸葛亮,很少有人會覺察到它是一款爆品。Twitch公司獲得了不可思議的成功。2014年,亞馬遜以9.7億美元的價格收購了Twitch。

Twitch公司第一個產品的創意是什麽?是與穀歌郵箱(Gmail)集成的日曆。當然,之後穀歌自己推出了穀歌日曆,無奈,Twitch公司隻好決定進入直播領域。其中一位公司創始人開始直播自己的所有生活,他頭戴攝像頭,背裝有電腦的大背包,每周7天,每天24小時,不間斷地進行直播。他們建立了極快的直播平台,可供很多人同時直播。但事實證明,沒有人願意看他們直播。於是,他們腦洞大開,想出個點子來——人們會不會希望直播自己?這個創意在當時的市場上也沒能行得通。雪上加霜的是,他們的資金即將耗盡。後來,他們注意到很多人喜歡看人們打電子遊戲的直播。他們雖然覺得不可思議,但還是跟進了,結果發現有一批狂熱的粉絲和娛樂遊戲玩家想觀看頂級選手的比賽。頂級選手可以通過遊戲直播賺很多錢。

這是一個極端的例子,滿足了一種無人知曉的需求。今天,我們在商業、政治和社會上所麵臨的問題都很棘手,我們常常根本沒有解決之道,甚至不知道如何尋找解決之道。

所以你需要做的是嚐試做些什麽,看看會發生什麽。參照結果,微調正在做的事情。然後再嚐試,再微調,如此反複,讓解決方案出現。這就是Scrum:在短時間內進行一係列小實驗,以找到解決複雜問題的方法。

賽尼芬框架中的最後一類問題是混沌問題,即危機。正如艾森豪威爾所言,緊急情況是無法製訂計劃的。應對緊急情況所需要的是領導層迅速而確定的行動。假設發生了海嘯,或者石油鑽井平台爆炸,或者股市崩盤,首先要做的是迅速采取行動,並開始采取步驟來描述問題,界定問題的極限,使其脫離混亂,成為複雜問題。舉個例子,我在阿拉伯的某一天晚上,一群人決定衝進議會大廈,或者類似的地方。總之,數萬人抱成一團,向議會大門猛衝過來。我被裹挾進人群中間。突然,尖叫聲從一邊傳來,人群一下子變得混亂不堪,人們四處亂竄,不知如何是好,一個個單一的個體瞬間轉化成山呼海嘯的群氓。

我當時正和一個年輕的美國學生站在中間,我雇了她做阿拉伯語翻譯。我告訴過她,現在我也會告訴你,在騷亂中該怎麽辦。首先,不要恐慌,這一點怎麽強調都不為過。盲目的恐懼會招致踩踏,乃至丟了性命。其次,找不容易被撞倒的東西,一定要牢固,如路燈柱之類的,靠近它。奇怪的是,人群會像河流遇到石頭一樣,從你身邊分開。這樣,你就把混亂問題化解成了複雜問題。深呼吸,冷靜一下,找出逃生路線,你自由了。倘若你像眾人一樣,裹在人群中,如同屍體般被拋來甩去,你就隻能聽天由命了。但是,假如你能擺脫噪聲和恐懼,你就可以開始想出一個計劃來。

這裏,速度很重要。推遲做出決定隻會使問題惡化。通過快速迭代——嚐試,觀察反應,再嚐試——最終可以成功地控製危機。在當下,這種試錯法會讓人感到恐怖。但這也是一種機會。當人們試圖弄清楚如何在前一天不存在的環境中工作時,新的做事方式就會出現。

不要等待,要行動

2001年9月11日上午,肯尼斯·霍爾頓和副手邁克爾·伯頓還是市政府內部一個鮮為人知的官僚機構——設計與建設局的領導,負責監督街道修繕、圖書館和法院的建造合同,他們的工作職責在紐約這座龐大城市中是微不足道的細枝末節。那個致命的周二早上,飛機撞上世貿中心後,沒有人知道該怎麽辦。紐約市大肆宣傳的應急管理辦公室也沒有采取行動。霍爾頓和伯頓所知道的是,必須向世貿中心現場提供大量設備和專業知識,以便開始在殘骸中進行挖掘,尋找幸存者,清理巨量瓦礫。

他們隻是在幾個小時前才開始思考,並沒有宏大的戰略。雖然救援工作原本不是他們的分內之事,他們還是開始給以前簽過合同的建築公司打電話。當天晚上,他們設法接了電,裝上電燈,以便在黑暗中繼續營救工作。他們繞過所有正常的規則和程序,選擇了四家認識的建築公司開始作業。

起初,警察和消防部門抵製他們。但二人一直在做決定:搜查這棟樓安全嗎?大致安全。通常,這種災難是由聯邦應急管理局和陸軍工程兵團聯合來處理的。但這一次,聯邦機構詢問情況時,卻被告知有哪些工作正在進行中——並被告知不要插手此事。伯頓沒有征求任何人的許可。

他們效率極高,完成了大量工作。項目工程龐大,他們的協調卻十分出色。市長魯道夫·朱利安尼為之折服,他告訴其他市政機構,即那些本該負責的機構,退後,讓設計與建設局來掌控大局。他們在一家幼兒園的教室裏建立了指揮中心,正如威廉·蘭吉埃斯切在其傑作《美國土地:重建世界貿易中心》中描述的那樣:

沒有人有時間衡量如何做出選擇、如何製訂計劃。需要的是行動,純粹的行動。由於需要明確的溝通,伯頓在幼兒園的一間教室裏召開大型會議,每天兩次。這是一種簡單、低技術含量的管理係統,卻特別適合應對室外的大災難。伯頓的推理像往常一樣清晰,他說:“對我來說,能夠控製局勢的唯一辦法是讓所有人都來這裏。沒有時間分發備忘錄,也沒有時間等待指揮係統逐級傳達命令。每個人都要聽到問題是什麽,就必須做出決定,每個人都必須親耳聽到這些決定。必須確保每個人都朝著同一個方向前進。”

邁克爾·伯頓後來被稱為“世貿中心沙皇”。他定義、促成並協調了3000人在不到一年的時間裏清除了150萬噸瓦礫、灰燼和鋼鐵。行動,純粹的行動,是把混亂局麵拉回到複雜局麵所必需的。

這裏的關鍵經驗是,在幾乎每一種情況下,首先要弄清楚你所處的環境,然後開始嚐試,看看你是不是真的在你所認為的地方。要做決定,不要等待。拖拖拉拉者會被事件壓倒,采取行動者則能抓住自己創造的機會。

授權給適合的決策者

大多數人甚至不考慮時間因素,不明白每一刻都十分寶貴,一旦失去,就無法找回。他們沒有意識到,每次等待,都在增加失敗或拖延的可能性。如果你隻能做一件事,就一件,一定要確保這件事是和所有需要做決定的人進行每日立會。像聚在一起討論這樣簡單的事情,會大大降低決策延遲。通過授權團隊和產品負責人去做決定,你自己就不必親自做決定,你不必做的決定越多,決策過程就越快。這是一件簡單的事情,但你的機構將開始成為一個讓最了解問題的人決定如何解決問題的組織。

不妨再舉一個拿破侖的例子:拿破侖的大軍像波浪一樣橫掃歐洲,取得一個又一個勝利,短短幾年就征服了整個歐洲大陸。當時,當某部隊的士兵看到敵人時,一般的規則是不交戰,而是上報給司令部,請示該怎麽辦。拿破侖用兩條簡單的規則改變了這一切。第一,見到敵人就開槍。第二,馳援槍響之處!這兩條規則允許數萬法國軍隊自發地迅速將全部兵力投入戰爭,而無須征得任何人的許可或指示。一支部隊開火,附近的部隊也會衝過來開火,就像野火一樣蔓延開來,越來越多的法國軍隊向需要的地方開火。這兩條規則永遠地改變了戰爭。

不要等待,要行動!

回顧

不要等著做決定。1個小時。這就是目標。1小時就是做出決定所需要的速度,等待委員會做出決定無異於與命運女神訂立自殺協議。如果做一個決定要花5個小時以上,這幾乎肯定是一個信號,表明你必須把決定送上審批鏈進行審批。

授權給適合的決策者。這是關鍵。隻有真正最有學問、最了解情況的人才應該做出決定,這樣才能做得快。解決問題的辦法不在於管理層的領導,而在於管理層之外的節點上那些與客戶直接接觸的人。

把規則控製在最低限度。若規則過於死板,則改變無從發生,文化僵化,一無所成。若能將組織的狀態剛好控製在混沌邊緣,則會發生意想不到的變化。

用簡單駕馭複雜。簡單的規則產生複雜的適應行為。複雜的規則隻會給簡單、愚蠢的行為留下空間。Scrum的結構恰如其分,規則不多不少,看似混亂,實則明晰。Scrum反對僵化,重在精益化管理。

待辦事項清單

√下次要開會做決定時,為會議計時,計算會議成本。包括與會者的工資成本,計算有多少時間被浪費在等待做出決定上。

√思考你或你的組織最近一次麵臨的危機。行動能再快一點嗎?或者,你對組織的迅速行動和反應感到驚訝嗎?下次你如何改變決策過程?

√要得到想要的結果,你能做的絕對最小值是多少?你能停止做什麽?

√想象一下你每天都要處理的複雜的流程。如果你關注的是價值而不是過程,將會是什麽樣子?

[1] Ringi來自日語“稟議”,特指在公司裏對於要審批的事項,不舉行會議,僅由具審批權的上司或相關人員以書麵形式予以審批通過。這個詞常被譯為集體決策(collectivedecisionmaking),或分享決策。

[2]基本意思是修根、整根(移植樹木時,提前一兩年從根部周圍挖開,切斷除主要根之外的旁根,使須根先充分生長)。引申意義是事先疏通,底下打招呼。事前向相關人說明意圖、情況等,以取得某種程度的理解。在管理學中,在決定某些事情的時候,為了避免混亂而事先取得大家的同意,這種手段被稱為“根回し”。