也許你需要的是多一點瀑布：敏捷的「八不」／敏捷黑手阿伊

在引進敏捷方法的初期，我們付出了許多時間、精神、和心力，也面對了許多亂象，直到一兩年後才慢慢步上正軌。回顧過去幾年的敏捷轉型史，如果可以重來，我們也許會改變一些做法；而本文的目的，就是讓你「早知道」，不必再走同樣的坎坷路。

在 2014 年我剛剛開始接觸敏捷（Agile）時，當時我的角色是新加坡商鈦坦科技的總經理，我覺得敏捷（包含敏捷開發、敏捷專案、敏捷管理）在描繪的是一幅理想中的世界。

就拿敏捷大家族中熱門的Scrum方法舉例來說，在Scrum團隊中沒有主管發號司令，工作由大家一起分工合作完成，也沒有主管指派工作，每個人自行選擇工作事項。團隊成員不會偷懶，會盡力把事情做好，最後的工作成果則是由團隊共享。

至於產品待辦事項是由產品負責人（Product Owner）決定，但如何完成工作是由團隊決定。

簡單的說，就是「各盡所能、各取所需」，這也是共產主義中理想社會的呈現。

各盡所能、各取所需。

──馬克思《哥達綱領批判》

然而，等到真的把頭洗下去，才發現完完全全不是這樣一回事！

團隊沒有主管之後，就陷入了決策困境；在專案進行中，一個小小的決定可以討論個三四天。

少了主管擔任訊息傳遞的角色，團隊的方向和部門、公司總是無法同步；團隊成員各做各的事，站立會議只是好看、過過場。

資深的成員覺得要教資淺的浪費時間，資淺的覺得資深的都不務正業，只做自己喜歡做的事；更別提在這段陣痛期，有些伙伴不習慣新的模式就離開了。

這種種的亂象，直到我們導入敏捷一兩年後，大家掌握了敏捷的精神，才慢慢消失；但也花費了難以想像的時間精神和心力。

回顧過去五年的公司敏捷轉型史，如果一切可以重來，我們也許會改變一些做法，而不會讓過程那麼的曲折。例如：

1. 不是消滅主管，而是要主管做好主管該做的事

在鈦坦科技導入敏捷的時候，我們就把團隊的管理職：組長（Team Leader）取消了，這當然要感謝當時擔任組長的伙伴理解和支持，讓我們順利過渡轉型；但其實這是一招險棋，在大部分組織中，也許會遭遇到很大的阻力、和難以承擔的後果。

如果一切可以重來，我們也許並不會取消全部的組長職務，而是讓所有組員都有輪流擔任組長的機會、讓擔任組長的人做主管該做的事情；而有了組長的領導經驗，成員就能夠更理解公司的營運情況，這也是訓練部門級主管接班梯隊的機會。

什麼是主管該做的事？

對齊公司目標和價值觀、發掘人才、爭取資源、幫助團隊內部和跨團隊溝通、協助團隊成員成長、針對組織系統性的問題做出高品質的決策，這些才是主管該做的事。

2. 不是十項全能，而是當團隊需要的時候「我願意」

在剛剛開始導入的時候，我們希望團隊中的成員都可以是全端工程師：前端、後端、測試都包到完成，所以取消了前端工程師、後端工程師、測試工程師等等職稱，一律改稱為產品開發師（Product Developer）。

這樣做的好處，當然是打破了職務的藩籬，但也造成大家認為每個人樣樣都要會、事事都要精的誤解。

如果一切可以重來，我們還是會取消個別的職稱，但會把焦點放在貢獻自己的專長、學習別人的專長上、在需要的時候原因跳下來幫忙，而不是什麼技能都要學。

我們需要的是團隊整體的技能端到端，而不是每個人的技能都端到端。

3. 不是顧客第一，而是緊緊抓住市場變化的脈動

敏捷宣言第三條說到：「與客戶合作，重於合約協商」，強調與客戶協作的重要性，而我們做的是B2B的生意，所以往往客戶說什麼，我們就做什麼；但我們忘記的是，跟客戶協作只是手段，目的是為了讓生產出來的產品貼近市場需求、有價值、賣得出去。

如果一切可以重來，我們會更關注在交付需求後產生的價值，和客戶檢討每個需求的成效，甚至走到市場上面對真實的消費者，而不是只接收客戶轉來的第二手資訊。

顧客不是第一，賺錢活下去才是。

4. 不是一切透明，而是容易取得幫助工作的資訊

在推行透明化的部分，我們做了薪資透明化的嘗試，80%工程師的薪資都是公開的；當然在實踐上會有很多細節，如基層、中層公開，同一職級同一薪資，獎金不公開等等。

而帶來的影響整體而言，我覺得持平，不好不壞；沒有太大的幫助、也沒有什麼太差的反應，但節省了很多主管煩惱薪資和私底下八卦的時間。除了這個，我們還有許多資訊透明化的嘗試。

如果一切可以重來，我們會更注重的資訊的整合，而不只是單純的公開資訊。每個人的時間有限，資訊量太多的結果就是資訊過載，不知道什麼是重點；這也是我認為主管必須做的工作之一：幫助團隊處理資訊的過濾、整理和翻譯。

透明公開是為了讓工作更有效的手段，而不是目的。

5. 不是共識決，而是搜集意見後做出高品質的決定

Zappos或Morning Star這些普遍認為高度敏捷、開放的公司，在團隊和部門中還是有做營運決策的角色。

而敏捷式組織的制度如合弄制（Holacracy）和全員參與制（Sociocracy）中，每個團隊也都有一位角色專職做營運面的決策，在合弄制稱為領導鏈（Lead Link），在全員參與制中稱為營運領導（Operational Lead）。

我們在導入敏捷後取消組長職位，然後跟團隊說：「現在開始你們就自己組織、自己做決定」；結果想當然耳就是慘不忍睹，不是花很多時間討論沒有共識，就是沒有人要帶頭做決定，或是出事了就推說「這是團隊決定的」。

如果一切可以重來，我們會先跟團隊介紹認可決（Consent）的概念，在制度上分成治理和營運；治理面（如制定遊戲規則）的事情就使用認可決，而營運面（如同按照規則玩遊戲）的決策，則是由主管（或是組長、領導鏈、營運領導）參考大家意見之後拍板決定。

絕對不要使用共識決，畢竟不是每個人對工作都有相同的投入和風險承受度；所以跟組織的命運越高度相關的人，決策權力應該越大。

就算沒辦法使用認可決，寧可獨裁專制由主管決定，也不要用共識決。

6. 不是反官僚，而是由做事的人設計流程解決問題

我接觸敏捷之後，想像的是一個超扁平、無層級的烏托邦世界。

但回到現實面，當組織長大、人數多了之後，為了整體營運的有效性，需要有抽象的層級出現，來整合和調度資源。越接近顧客的層級，處理的事務越具象；越遠離顧客的層級，處理的事務就越抽象。

如果一切可以重來，我們的重點不會放在如何消滅官僚科層系統，而是放在如何讓科層系統運作得更有效，讓資源更有效的整合、讓資訊可以更暢通，讓第一線的人有更大的權限服務顧客。

官僚系統沒有錯，官僚心態才是錯。

7. 不是花大錢教育訓練，而是在工作中反思和成長

我認為，敏捷轉型就是為了變成學習型組織；而公司也花了很多資源和時間，讓伙伴上課和參加教育訓練，甚至產生了過度學習的症狀：上很多課、看很多書、聽很多分享，但來不及消化和吸收。

如果一切可以重來，我們會更注重在如何解決工作上的問題，著重在日常工作上的學習和成長，而不是只關注在提供教育訓練的機會。

能帶來組織改變的才算真的學習，要不然就是自爽自嗨。

8. 不是心靈成長夏令營，而是學習面對殘酷的現實

在導入敏捷後，發現敏捷非常需要有效的溝通，所以我也參與了一系列的溝通課程，包含焦點討論法ORID、人格特質分析DISC、教練、引導、薩提爾等等；其中DISC和ORID的課程也引入公司，成為每年固定開放的基礎內訓課程。

當然，這些對我個人的成長都有很大的幫助；但在商言商，從成本效益來看，除了基礎的溝通課程之外，我並沒有特別感受到「趨近心靈層面的課程」對組織的效益。

更糟糕的是，這會讓大家有「你要重視我的感受」的期待；但這些課程是用來要求自己，並不是拿來要求別人的。

如果一切可以重來，我們會更著重在如何面對衝突、甚至製造健康的衝突，以建立就事論事的文化。

當然並不是說不要重視別人的感受，而是我們在工作上討論事情、看數據，本來就是「白刀子進紅刀子出」血淋淋的現實。表達方法當然可以調整，但現實不會因為我們感受不好就不存在的。

活著才有輸出，活著才有明天，活著才能談心靈成長。

步步血淚的「敏捷八不」

這是從我自身心酸血淚的經驗中體悟的「敏捷八不」，希望能幫助想在組織內導入敏捷的朋友，少跌坑、也少走一些冤枉路：

1. 不是消滅主管，而是要主管做好主管該做的事；

2. 不是十項全能，而是當團隊需要的時候我願意；

3. 不是顧客第一，而是緊緊抓住市場變化的脈動；

4. 不是一切透明，而是容易取得幫助工作的資訊；

5. 不是共識決，而是搜集意見後做出高品質的決定；

6. 不是反官僚，而是由做事的人設計流程解決問題；

7. 不是花大錢教育訓練，而是在工作中反思和成長；

8. 不是心靈成長夏令營，而是學習面對殘酷的現實。

本文改編自作者於2021年7月出版的《敏捷管理生存指南：不是快，而是適者生存》一書。

發源於矽谷的敏捷式開發，在軟體產業如 Google、Facebook 臉書實證成功後，敏捷管理也開始影響各個不同的產業。

透過書中的實例和做法，無論老闆、主管或員工，科技業、服務業、傳產、學界或政府，都能運用敏捷讓自身工作更順心，團隊合作更順暢，企業成長更順利。