《SCRUM敏捷實戰手冊》：凡事都要等委員會才能做決定，簡直是找死

文：J.J. 薩瑟蘭（J.J. Sutherland）

加速決策

你碰到一個問題，這是你剛發現的問題。

這可能是任何狀況。也許你正在構建某個東西，卻發現整套設計都必須變更；也許是你規劃工作時突然發現意料之外的狀況，於是你必須決定接下來要怎麼做。應該先處理那個緊急狀況嗎？還是再等一會兒，先處理以後會變得很有價值的重要事項？

這就像是艾森豪總統（Dwight D. Eisenhower）著名的決策四象限（decision quadrant），他是根據重要性和緊急程度來排序工作：

所以現在你卡住了，必須先決定剛剛碰上的難題屬於哪個象限。

你必須先跟誰聯絡嗎？你必須等委員會開會才能決定？大家的行程都塞滿了，你無法在今天做出決定，也許要拖到明天，搞不好是後天？問題拖下去會衍生多少成本？

決策延遲

幾年前，史丹迪士集團創辦人兼董事長吉姆・強森（Jim Johnson）發覺這個問題很有趣。史丹迪士集團主要透過訪談、焦點小組（focus group）和調查，研究世界各地怎麼做專案。他們從1985年到現在一直在做這項研究，調查過成千上萬個專案，定期發布「CHAOS」報告，裡頭會有各式各樣關於專案成功與失敗的有趣資料。

跨國專案採用敏捷管理的狀況是這樣的（見圖1）：敏捷專案（大多數都是以Scrum完成）的失敗率甚至不到傳統專案的一半，而且成功率更高。這是無可動搖的事實。

不過我們明白的說，並不是每個敏捷專案就一定會順利完成。Scrum公司（Scrum Inc.）和吉姆一直在研究，為什麼還有50％的敏捷專案最後會出問題、時程延誤、超出預算或者讓客戶不滿意。

這些專案失敗的根本原因是什麼？為什麼Scrum專案會更容易成功？有一天吉姆採訪一位幾年前在麻薩諸塞州政府領導採購部門的主管，才發現問題出在哪裡。

「他說他以前在波士頓市政廳工作，」吉姆說：「要先獲得副市長的決定才能進行某項專案。那時候總共有60家包商在等這個決定。結果60人在那兒耗了6週，什麼也做不了。做個決定就得拖那麼久。」

吉姆很震驚，這件事實在太離奇。所以他開始在研究中加入一道問題：「你做決策有多快？」當他研究那些出問題的專案，才發現這種狀況一點也不離奇，反而很常見。那些失敗的專案中，很多人根本沒有做出決策。他覺得最奇怪的是，那些決策大多數並不特別複雜或困難，往往只是尋常可見的決策而已。但就是不斷拖延，猶豫不決！

他提出這個問題以後一再發現同樣的狀況，所以他開始進行基準測試，測量人們在做專案時，得花多久才能做出決策。畢竟不管是什麼專案，我們都要做很多決定。

「結果，」吉姆說：「數據顯示我們在專案中大概每花1000美元就要做一次決策；所以100萬美元的專案，大概就要做出1000個決策。」這樣算下來，決策數量很快升高。而且決策花費時間愈長，成本也就愈高，這是根據愛因斯坦廣義相對論的完美推理：時間不但是空間，時間更是金錢！所以吉姆想出一個衡量標準，來計算確定需要做決定到實際做出決定總共花了多少時間。這個衡量標準稱為「決策延遲」（decision latency）。然後，他把這些數據和專案的成敗做比對。他研究全球幾百項專案，結果發現，狀況比我們想像得還要嚴重。

如圖2所示，比對彙整幾百項專案後發現，能夠在一小時以內迅速做出決策的專案，成功率高達58％（而且是在預算之內準時完成）。但要是決策耗時超過五個小時，成功率就會大幅下降到只剩18％。而且不過是五個小時，就有如此大的差異。

不過，吉姆可是拖了一年才公布這項研究，因為結果實在太驚人，也因此他在研究報告出版之前，就在一些商學院和研討會上發表。

「大家的反應非常有趣呢！」吉姆回憶道：「起初大家都說，『不會吧？這怎麼可能！這不會是最主要的失敗原因啊。』後來他們又想了一會兒才承認：『你可能說得沒錯！』」

而且最奧妙的是：這些遭到延遲的決策，其實大都是小事或是很簡單的決定。但是，當組織僵化、階層分明，整個決策流程從基層送到高層再轉回來，可能就要花很長一段時間。

我們以前合作過一家跨國汽車大廠，決策採用的是日本常見的「稟議制」（ringi）。這個制度講求讓管理階層對於要做什麼決策先有共識，一旦有人提出議案，就會傳送到決策圈公告周知；等到大家都同意而且高層領導也簽字認可後，才能做出決定。這套方法的關鍵在於，先在幕後悄悄運作來達成共識，之後的提案就能順利進行。日本人說這套做法叫「根回」nemawashi，原本的意思是樹木移植之前要先把根鬚修一修。

但是讓我告訴各位，這套做法有多讓人心灰意冷。假設你在美國一家汽車廠工作，準備花錢買一些東西，例如添購某樣新設備。這筆錢雖然已經編入年度預算，也分配好要作為添購新設備的資金，你還是要先寫一份提案，而且是書面報告。這份採購報告你要寫得很詳細，而且說明清晰有力，上頭才會知道為什麼要花這筆錢。還要附上所有必要的會計數字：總共要花多少錢、錢從哪裡撥下來、最後要付款給誰；當然這些資料也都要在書面報告上詳明。然後，你還要進行環保審查：新機器需要多少電力、有沒有氣體或汙水排放的問題。所有的項目都要白紙黑字寫清楚，而這些文件就叫做「稟議」。

然後，提案必須獲得批准，於是首先得送交中央規劃小組審查。但是就像某位工程師跟我說的那樣：「他們要先做檢查，檢查一大堆我們根本不了解的東西。」然後這個中央規畫小組可能會駁回提案，要我們再做修改，如果都沒有問題才會批准。

如果提案獲准，文件上頭就會有一堆簽名。書面提案嘛，所以是親筆簽名。首先是提案人的主管簽名，然後是高階主管、部門經理、總經理，接著可能是副總裁。啊，還有中央規劃小組的經理、資深經理、集團經理、總經理和副總裁也都要簽名。因為這是在製造工廠，也許還要送交工安部門的主管簽字。

這樣還沒簽完喔。這個上頭簽了一堆名字的提案報告，再來要移交財務部門，然後又是一連串的簽名批准。要是跟資訊部門也有關係，那麼資訊部門的總經理和副總裁桌上也都會出現這份提案。如果這項提案的規模夠大、夠重要，大概整批文件還要送到企業總部，在各個相關部門之間周遊列國、層層審批。

我採訪的工程師只是要做個小專案，金額只有六位數，這樣就需要大概35位主管簽名，而且都是親筆簽在那份紙本文件上（這還不算多，有些提案報告上頭簽了50幾個人的名字）。這樣的流程就要跑四、五個月，甚至更久。現在，他們的採購案甚至還要先做一個前置提案，才能讓公司先撥點錢下來做車輛開發（但這些錢其實早就已經編入預算）。

後來，公司指派一個小組進行改革，要讓整套流程自動化。他們很自然就採用Scrum來做。目標是什麼呢？擺脫紙本文件。要讓紙本文件在許多主管之間轉來轉去，對我們來說簡直慢得要死！同時他們也要讓中央規畫小組的一些審查作業自動化。

這會帶來兩個好處。首先，整個過程一清二楚。原先那套作業方式，大家都不知道文件到底躺在誰的桌上，所以也沒人知道事情到底進展到什麼程度。流程快跑完了嗎？還是只到一半？是不是因為我們不知道的某個原因，已經被某個人叫停了？現在，這些困惑都不會再出現！其次，如果是跟過去類似的提案，你得先找到當時的承辦人，希望他還保留整份紙本卷宗（可能有也可能沒有），你才能再複製一份。檔案數位化以後，至少就能找到獲得批准的提案報告，要複製也不是問題。

由於設置這麼多層級關卡，簽核文件的人常常都不是最後做決策的人。然而決策有各式各樣的範疇，有些屬於技術層面、有些可能是業務方面，有些或許涉及人事和人資；有些決策也許很重要，也會有些決策沒那麼重要。既然有各種不同的決策，就應該由相關領域的人來做決定。畢竟碰上問題需要做決定的時候，你一定希望是由知道最多、了解最深入的人來負責。

「Scrum的做法就是乾淨俐落，可以讓團隊自己做決策。」吉姆說：「如果採用Scrum，決策只要經過兩層：產品負責人和團隊，所以決策比較少牽扯到利害關係人和管理階層。」

關鍵就在這裡！只有真正掌握最多資訊、了解最深入的人才能做決定。這也是整個團隊作業可以加快速度的原因。如果做個決定要花五個小時以上，八成就是要層層請示、逐級批准。

我們設定的目標就是一個小時，決策就是要這麼快。凡事都要等委員會才能做決定，簡直是找死。那麼我們要怎麼加快決策的速度呢？

你參加的會議有效率嗎？

現在，你需要做決策，所以你決定先開個會。假設這場會議有20人參加，需要一小時才能做出決定。你可以算出這個決定要花多少錢。而且這還只是時間而已，光那一個小時到底值多少錢。然後各位再想想，你每個禮拜開了多少根本沒意義的會議。

我有位朋友以前在常春藤盟校工作。他說有時候走進會議室都不知道自己在那裡做什麼。而且就算他知道為什麼要參加會議，會也是開得沒完沒了。這些會議的成本其實都算得出來，每場會議大概花費1000美元，然後他每個星期要開10-15次的會議。你看這些金額加起來有多少。

但實際上更嚴重的問題是：會議中做的決定還是會被推翻。根據史丹迪士集團資料顯示，開會中做的決定被推翻的比例竟然超過40％！比方說，這次會議做了一個決定，而下次會議在一週以後。所以這次開完會，大家根據決策結果開始執行工作。結果到了下次會議，大家又改變主意、做出新的決定。結果所有人不但浪費掉一週，還都在做白工。這就像是挖個洞之後又把它填起來，根本毫無意義！

根據史丹迪士集團的研究，會出現這種情況有兩個原因：參加會議的人和沒有參加會議的人。真正去開會的人當中，其實是嗓門最大的人在做決定；他會逼大家做出他想要的決定。等到會議結束，大家回到辦公室才覺得：「哎呀！我現在想到那個決定真是不敢苟同，下週開會絕對要提出覆議！」

還有那些沒去開會的人，也許他們應該去開會但沒去，或是覺得自己也應該到場。這些人會覺得這件事怎麼沒先問我呢？這下可好，下次開會他們一定會出席發表高見。

吉姆・強森說，很多專案就是這樣一天腐敗一點點。每天拖延一下子，於是敗象漸露。每天只是浪費一點時間，就緩緩走向災難。

先決定要做什麼決定

Scrum就是要揭露那些讓你變慢的問題，把障礙攤在陽光下，讓你知道問題出在哪裡。隨著衝刺一段接一段的進行，問題會不斷出現，團隊當然希望這些問題可以解決，當然有些人會開始說Scrum才是最大問題。但是問題始終都還是存在。

最麻煩的問題是問題有許許多多不同的類型。而解決這些問題的辦法當然不在總公司管理階層的主管身上，而是在實際跟客戶直接接觸的人，也就是所謂的「節點」（nodes）上。那些逐漸升官往上爬的人，距離第一線工作愈來愈遙遠，通常卻更加相信自己的解決辦法最好。

未來工業（Mirai Industry Company）是推動決策的精彩案例。這家公司製造電氣設備材料，包括開關盒、電纜、管線等。他們跟大多數日本公司不一樣，從來不採用稟議制。

未來工業的創辦人是山田昭男，在2014年去世前長期擔任執行長，他認為稟議那一套做法相當荒謬，所以從不採行。他這樣跟員工說：「就按照你們認為最好的方式來工作，讓親自執行工作的人來負責。」山田昭男在著作《員工最愛的幸福企業》（The Happiest Company to Work For ）中寫道：「我是笨蛋啊！所以怎麼會是由我來判斷？」他常常是在看到員工遞出的新名片，才知道自己的公司又在日本的哪個地方開設新的銷售點。租下大樓辦公室、聘用新員工開始培訓，這些都由員工自己決定。他說，要是這些事情不授權給大家自己做決定，那麼員工一定要花很多力氣說服老闆，因為老闆對這些事情根本就不了解。

但是，在大多數公司裡，老闆都堅持員工一定要匯報所有狀況，好讓他做出最後裁決。結果，做決定的人就是最狀況外的人。而且，老闆擔心沒有足夠資訊，於是要求大家提供更多資訊。整個系統因此遭到延誤。然後，老闆又害怕犯錯，於是召集委員會一起承擔決策責任。

我知道有一家大銀行設置一個超過40人的委員會專門控管風險，不管是什麼提案，都要先經過這個委員會的批准。他們會在電話會議上爭論好幾個小時、吵個沒完，所有人都心力交瘁。等到做出決定的時候，早就搞不清楚到底是誰的想法，也不曉得是要解決什麼問題。即使到最後證實做錯決策，也沒有人會被追究責任。這個委員會其實只是為了保護銀行而設置，因為這家銀行過去曾經做出一些草率的決定，遭到政府罰款好幾千萬美元。

為了根絕這種狀況，他們安排所有重要的主管組成委員會，做給主管機關看：「我們的高層領導團隊現在會確保公司不會再犯錯啦！」然而現在這個風險委員會不只會阻止錯誤的決定，還會阻擋掉所有的決定。他們一拖就要好幾個月，而且這幾十個人搞到最後終於做出決定時，所有人都認為既然已經投入這麼多政治資本，保證這絕不是錯誤的決定，而且一點都不會有錯；有這麼多聰明的高層花費這麼多心力做決策一定不會出問題，所以如果真的出錯，問題一定出在沒有按照決策做事的討厭鬼身上！然而，這種風險委員會如今在金融界很常見，想來真是悲哀。

其實，問題在於控制功能（control functions）常常變來變去，原本定義非常精確的職權範圍很快就會擴大，超出原本的界線。這些人也都不是壞人，但是他們建立一套決策控制系統，爭取到大家的信任，卻不只會減慢速度，還保證那些決策都會出錯，因為他們做出決定的時候早就事過境遷！在延宕不決的那幾天或幾個星期裡，那些問題已經以某種方式被處理過了。沒做決定，其實就是一種決定。

書籍介紹

本文摘錄自《SCRUM敏捷實戰手冊：增強績效、放大成果、縮短決策流程》，天下文化出版
＊透過以上連結購書，《關鍵評論網》由此所得將全數捐贈聯合勸募。

作者：J.J. 薩瑟蘭（J.J. Sutherland）
譯者：陳重亨

當「複雜」成為組織面對的常態
「敏捷」就是最佳解答

SCRUM執行長 睽違5年後 正宗權威演示專書
即刻超強部署 一次解決組織與個人荒謬的浪費

只有迅速採取行動的人，才能真正抓住機會。

在這個全球化影響力不斷擴大的新時代，任何人為或天然災難造成的連鎖效應，都有可能迅速擴及全世界，導致政治、外交、經濟版圖產生巨變，沒有人或組織可以倖免。

面對不斷變動的局勢，過去的工作方式已經無法應對未來的問題，我們需要採用新的工作方式，Scrum正是解答。

Scrum是放眼未來、快速回應的工作法，運作方式非常簡單，首先，找出3種角色：

• 產品負責人：負責按照價值排定工作優先順序，建立產品待辦事項清單。
• Scrum大師：幫助團隊提升速度，除去一切障礙。
• 團隊成員：完成工作的主力人員。

接下來，就可以進行最重要的5項活動：

• 衝刺規劃：展示產品待辦事項清單，選定衝刺期要做的任務。
• 衝刺：配合團隊狀況選擇最佳的工作節奏，但一週的衝刺最適合。
• 每日Scrum（立會）：花15分鐘報告工作進度與當天目標。
• 衝刺檢視：衝刺結束後，向利害關係人與客戶展示已經完成的工作與成果。
• 衝刺回顧：產品負責人、Scrum大師和團隊成員一起討論進展順利的部分、檢討應該改進的部分，以及下次該如何調整。

改變傳統的結構，改變激勵誘因，改變績效管理方式，就能實現人類的摩爾定律，用最少的時間完成最多的工作。

責任編輯：潘柏翰
核稿編輯：翁世航