【曼報】給一事無成的公司（或個人）的衛教單張

「當一切都很重要但什麼都沒完成」

（When Everything is Important But Nothing is Getting Done）

好文分享，
這些流程很多人很多主管很多老闆都知道。
但真正做到面對真實的自己，卻很難。
再輔導企業做數位轉型時，也是最常遇到的不承認企業（自己）有問題，但還是到處問、到處請人輔導，然後繼續原地踏步。
分享給大家共勉之

===============================

出處 : 《曼報》 / FB  Manny YH Li

【曼報】給一事無成的公司（或個人）的衛教單張

​

最近朋友分享了一篇標題為「當一切都很重要但什麼都沒完成」（When Everything is Important But Nothing is Getting Done）的長文，光是看到標題我就知道「中了，中了」，仔細讀完後更是感到不得了。

​

本文是我寫給自己的精華版，並且加了很多的感觸。

​

-

▋前言

​

作者 Roman Kudryashov 是傳統意義上的文科生，在學期間主修政治哲學與服務設計，過去十多年來在醫療、軟體與電商產業中擔任行銷與產品主管。雖然 Kudryashov 不是工程師出身，但我近年發現「人」的問題不因職務有顯著差別，解決人性或組織問題的能力也與出身背景無關。

​

該篇長文是 Kudryashov 記錄自己在上一份工作過程中遭遇的挑戰，以及如何花九個月的時間克服。談解決問題的文章這麼多，為什麼這篇特別精彩？因為如 Kudryashov 所說，太多文章只講「解法」（自從我們導入敏捷開發後就好棒棒了），而沒有細講問題以及問題發生的脈絡（context）。

​

-

▋問題

​

Kudryashov 的公司（中型企業）在產品開發上遇到了什麼問題？

​

• 超多專案同時進行中

• 每一個專案都說是超重要

• 沒有人有完整的鳥瞰視野

• 速度慢、結果差、士氣低

• 高達 50% 的離職率

​

聽起來就像是一個進入死亡螺旋的公司，對吧？此時 Kudryashov 站出來說他願意改變這一切，理由很簡單：「還能多差呢？」他建議每個人如果遇到這種機會都應該挺身而出，因為下檔風險有限，上檔報酬無限。看到這不禁笑出來，因為這跟我過去一段職涯選擇一模一樣。

​

-

▋解決問題的第一步：承認有問題

​

「解決問題的第一步是提出解法。」錯，錯得離譜。解決問題的第一步是讓所有人都承認有問題。

​

有種常見的畫面是這樣：對工作有高度熱忱，每天都在找問題，並總是興致勃勃地跟主管或老闆提出解法。然而，一旦解法不被採用後就會悻悻然地認為「這間公司沒救了」，最後在「失望」下辭職，然後繼續到下一間公司重蹈覆轍。

​

「如果只有你覺得有問題，那麼你就是問題。」這句話很殘酷，但這就是人性。解決問題的第一步不是提出解法，而是讓所有人意識到問題，但這通常只能靠兩種方式達成：極為強大的說服能力，或是不見棺材不掉淚。很可惜，在人性的限制下，大部分的情況都是後者。

​

Kudryashov 的處境當然也是後者，因為狀況已經糟到不能再糟，沒有人懷疑公司出了問題，只覺得問題不可能被解決。

​

-

▋解決問題的第二步：了解問題

​

過了心態這一關後，緊接著要查核事實。公司內的每個人都很忙，但到底都在「忙什麼」？Kudryashov 請總數 40 人的產品與工程團隊清點手上所有的工作，最後發現有超過 300 件任務，即便經過清理後還是高達 140 件。

​

值得一提的是清點工作並不容易，因為散落在各種角落。有被管理的任務散落在 Jira 或各種試算表中，而沒被管理的任務就更五花八門了，像是某個 PM 因為跟某工程師比較好就請他額外幫忙弄一件事，或是某個工程師覺得某功能應該要遷移所以就自幹了...等等。

​

看到這段時我有一種被安慰的感覺，原來不是外國的月亮比較圓，而是這都是身為人就會犯的錯，以及由人構成的組織就會累積的問題。

​

-

▋解決問題的第三步：排序

​

當有了任務清單，接著就是排序。傳統上人們習慣用單維的「高－中－低」來排序任務重要性，但 Kudryashov 認為這個排序法有三個缺點：

​

❶ 當任務超過三個的時候，就會出現重複的排序選項，而重複選項無法再被排序。

​

❷ 每個人心中的「高－中－低」不同，無法對話，且容易淪為政治工具，例如高階主管或最會吵鬧、最難搞的人所發出的任務就比較重要。

​

❸ 「高－中－低」是結果論，不是一種可討論的標準。

​

比「高－中－低」更好的排序法是常見的二維「緊急 X 影響」矩陣。緊急（urgency）由時限與相依程度決定，例如這個任務是否明天就要完成，或是這個任務如果不完成則別的任務無法推進；影響（impact）由潛在價值與創造該價值的可能性決定。

​

透過「緊急 X 影響」的矩陣，可得到四個象限：

​

• 低影響低緊急：不要做

• 低影響高緊急：可能瞎忙

• 高影響低緊急：過度樂觀

• 高影響高緊急：立刻去做

​

我特別有感的是「高影響低緊急」。當公司有餘裕時，通常幕僚單位會提出一些當下不緊急，但邏輯上來說具有高影響力的策略，而這些策略多少都會有「對結果有最好想像」的傾向，畢竟不這樣策略怎麼會吸引人呢？至於如何避免落入這個陷阱，改天會再用一篇貫穿《好策略，壞策略》與《好策略的關鍵》兩本書的長文來探索。

​

-

▋解決問題的第四步：暴露組織限制

​

Kudryashov 開始帶領工程與產品團隊一起專心做第一重要的任務，他形容這段過程為「開火車」。當頭號任務列車發現路上有障礙時一律掃除；當發現路上有一節車廂很適合加入一起做事就把它吸納進來；當發現自己身上有一節車廂不堪用時就把它捨棄。

​

這種做法很極端，並不適用於所有公司，但 Kudryashov 認為當一間公司的狀態已經非常糟糕的時候，「只做一件事」也好過「什麼都做不了」。

​

有趣的是當 Kudryashov 率領團隊執行頭號任務時，其他任務不是進度擱置就是完全停擺。「為什麼一啟動頭號任務列車，其他車輛就不動了？」這點揭露了公司更深層的問題：組織架構帶來的生產力限制。

​

❶ 大部分的專案都有很高的跨團隊相依問題，每個團隊都參與了別的專案的一小部分。這若不是因為專案範疇（scope）設定得太大，就是團隊一開始並非以「能獨立作業」為前提組成，或以上皆是。

​

❷ 由於每個團隊都參與了自己以外的其他專案，整間公司有超多的「開發中」（Work in Progress，WIP）專案，而一個團隊手上的 WIP 專案數量與其完工效能成反比，因為：

​

⑴ 越多 WIP 專案就會分掉越多時間

⑵ 人不是機器，切換任務也會需要準備時間

⑶ 做事的人跟管理者不同，需要時間專注

⑷ 當 WIP 專案還得跨團隊協調時更是雪上加霜

​

❸ 主要專案的範疇都設定得太大。過大的範疇會產生「自體蔓延」現象，因為有更多時間發現新的使用者需求，或讓團隊想到新的功能。過大的範疇一定會拖長開發時間，而這將放大人員離職、預算變更等帶來的系統性風險。

​

-

▋解決問題的第五步：組織重組

​

上一步所暴露的組織限制中，最需要被改變的就是跨團隊相依問題，因為該問題同時衍生了有過多 WIP 專案的狀況，且讓公司無法高效率地「平行作業」。

​

解決之道相當顯而易見，就是俗稱的 Reorg（組織重組），因為真正的問題並不是「人不對」，而是「沒有把人放對」。由於此時公司已清理出全員同意的任務重要度列表，接著就是依照任務需求重新編組，並確保每個團隊都能獨立作業，減少彼此的相依性。

​

然而，概念與方法總是簡單的，困難的是如何執行。很多企業喜歡三不五時 Reorg 一下，但通常弄越多次、員工之間的嫌隙就越多。Reorg 本質上是在破壞人與人之間的關係，例如本來在上司心中是明日之星的員工被分到可能看他不順眼的新任主管底下時，心理的不安全感會大幅影響其工作表現。

​

對此，Kudryashov 分享了他的 Reorg 之道，相當細緻且具有參考價值。

​

❶ 預熱：由於還不確定怎麼「說」會比較好，先依序透過幾場工作坊、與主管及團隊的會談，從每次對話過程中收集人們對哪些說法特別敏感或防備，再以此為依據進行調整。

​

❷ 一對一：一對一訪談非常重要，必須盡可能地安排公司中的重要成員參與，尤其必須注意那些一旦不滿意就會暗中搞破壞的人。同樣，在訪談過程中也可進一步收集到更真實的對話反應，藉此調整之後的對話內容。

​

❸ 路演：將千錘百鍊的說法與完整的行動方案向全公司的人公告，確保每個人收到的版本都是一致的，以免最後又以訛傳訛。

​

更詳盡的 Reorg 之道還可參考知名的 Lippit-Knoster 模型，該模型整理了任何一個群體要做出困難改變時所需要的關鍵要素，包括：願景、共識、技能、誘因、資源、方案。

​

-

▋解決問題的第六步：明確定義何謂「完工」

​

在產品開發領域，最讓人害怕的東西還有一個：殭屍（zombie）專案，也就是生死未判，介於需要維護與不用維護的專案。殭屍專案的最大缺點就是會增加 WIP 專案的數量，而這點自然對生產力有害。Kudryashov 認為在決定一個專案是否完工前，必須問三個關鍵問題：

​

❶ 使用者有用它解決問題嗎？常見的一種回答是：「有，但使用者又有新問題了。」這種回答需要的是再起一個新專案，而不是繼續擴充原本專案的範疇。

​

❷ 成果交到使用者手上了嗎？很多時候工程團隊內會用「程式碼寫好了」來代替「完工」，但只要東西還沒交到使用者手上它就不算完工。

​

❸ 成果有被使用「足夠長」的時間嗎？「足夠長」是個浮動的指標，依每個專案想達到的目標而異，但每個專案應該都要建立蒐集回饋的機制，以此確定該專案是否有被使用、甚至有解決問題。

​

-

▋解決問題的第七步：沒有停下來的權利

​

Kudryashov 在最後清楚地指出，前面做的每一件事都不是一勞永逸。公司內永遠有人會想要插隊跟打亂重要性排序，原本可獨立作業的團隊最後也會越長越不獨立，說好的敏捷開發也可能中斷，本來很滿意的組織架構又到了需要 Reorg 的階段...

​

只要是人組成的公司，就沒有一成不變；只要不是一成不變，就必須一直與問題共處，無時無刻想辦法解決它。

​

-

▋寫在最後：若把自己當作一家公司

​

總結 Kudryashov 整篇長文，可得到以下七個重點。一邊細讀的同時，除了反思自己曾經面對過與現在正面對的組織挑戰，也在想其實這些重點也很適用於個人。

​

❶ 承認有問題：對公司來說，承認問題是第一步；對個人而言也是如此。不用幻想眾人皆醉我獨醒，但也不要死鴨子嘴硬。

​

❷ 完整掌握現況：對公司來說，無法掌握每個人的工作狀態就無從下手；對個人而言，無法掌握自己的時間與心力運用就無從進步。

​

❸ 建立優先排序：對公司來說，建立一個大家都同意的優先排序邏輯有助於推進事情；對個人而言，要盡量避免瞎忙或自欺欺人的樂觀。

​

❹ 一次做好一件事：對公司來說，先求有能力做好一件重要且緊急的事，再思考平行作業；對個人而言，就算現代人難以維持長時間專注也沒關係，重點是找到自己的首要志業並持之以恆。

​

❺ 解決組織限制：對公司來說，若無法有效平行作業則一定存在某些組織限制，要積極找出成因並透過組織重組來解決；對個人而言，也許沒有組織限制，但無法做好某些事通常都是存在一些心理限制，認真與自己對話，並且勇於尋求協助。

​

❻ 明確定義何謂完工：對公司來說，越少 WIP 與殭屍專案越好，要持續讓公司保持在往前推進的狀態；對個人而言更是如此，不要徒留一堆爛尾或斷尾的事情然後期待未來的自己或別人可以幫忙收拾。

​

❼ 永不停歇：問題永遠沒有解決完的一天。

​