作者：Derek Lidow

為什麼「排名」是個壞工具#

聰明的領導者都知道，自己的工作本質就是辨識取捨——「不做什麼」與「做什麼」同樣重要。在資源有限的情境中，給各項計畫排權重是領導力的試金石。

但作者強烈反對「排名（rank ordering）」這個常見方法。

• 被排到後段的主管會被去動機（demotivating）
• 幾乎一定會引發地盤之爭與內部對立
• 排名常是政治結果，而不是策略結果

回到第一原理：objectives、resources、timing#

執行任何計畫都需要三個互相依賴的變數：

1. 目標（objectives）
2. 資源（resources）
3. 時間（timing）

這三者像三角形的三個邊：壓擠任何一邊，另兩邊就會被迫調整。

三者都重要，但資源至高無上。沒有專屬資源，計畫就只是幻想。當領導者把「哪些資源、在多長時間內、為達成什麼目標」明確化，排名就不再有意義——只剩下三類優先順序：critical、important、desirable。

三類策略優先順序#

1. Critical（關鍵）：時間與目標固定，資源可變#

必須在某個時間點之前完成，沒有妥協空間。例如：

• 必須在客戶招標日之前贏下訂單
• 工廠必須在某天前完全運轉

當目標與時間都已鎖定，唯一能調動的就是資源（錢、人、設備）。

宣稱一個專案是「critical」其實意味著對該專案開出事實上的空白支票——專案經理可以在組織內隨時調用其他可用資源。所有的 critical 優先順序在類別內彼此平等，沒有再細分。

2. Important（重要）：資源固定，目標或時間可變#

對績效有顯著正面影響的計畫。資源被鎖定，可變動的是時間或目標。例如：

• 「這一季 Miguel 與 Aisha 全職投入這個專案」——組織理性的話應該接受該固定投資能換到的進展程度
• 「Miguel 與 Aisha 安裝新軟體，無論需要多久」——組織必須對時間有耐心

Important 優先順序意味著當目標可變時組織要包容、當時間可變時組織要耐心。

3. Desirable（期望）：資源與時間皆為變數#

組織希望有結果，但無法絕對承諾在某段時間內投入特定資源。例如：

• 「Miguel 與 Aisha 在不被 critical 產品上市專案需要時，會去做軟體升級」

只有在資源出現空檔時，才會有進展。

因為 critical 與 important 的資源都是固定的，當 critical 專案需要動用「空白支票」般的支援時，這些資源必須來自 desirable 的工作。

這意味著：你不能憑良心宣稱一件事是 critical，除非你也同步指定了哪些 desirable 專案會在必要時被立刻挪出資源。

四步驟分配資源#

Step 1：列出可用資源#

把所有可用資源列在一欄。例如：

• 東岸 10 位業務、西岸 7 位、中西部 4 位、南部 3 位
• 差旅預算 $10,000
• 1 台展示車

Step 2：列出想完成的計畫#

橫向列出計畫、改善或新倡議，並註明既有的時間限制。例如：

• 在四個區域續約客戶
• 在新工廠 3 月 1 日開幕前贏得 IBM 合約
• 在四個區域分階段導入 Salesforce.com

Step 3：在預期情境下分配資源#

把資源寫入對應的格子。例如：

• 每區安排 3 位業務續約客戶
• 7 位業務、展示車、半個差旅預算投入 IBM 合約

Step 4：宣告 critical 並標記可調用資源#

宣告 1 到 2 個 critical 專案，標出其他可被該 critical 在必要時呼叫的資源。

若宣告超過一個 critical，必須確認它們不能依賴同一個 on-call 資源池。

舉例：若 IBM 合約是 critical，問該專案負責人「真有困難時還可能需要哪些資源、會從哪裡調？」這可能包含東岸 Salesforce 導入用到的部分 IT 資源——這意味著 Salesforce 專案被歸為 desirable，且不能期待人員在固定時間內完成。

不是 critical、也不被列為 critical 隨時備援來源的專案，落入 important 類別——時間或目標其中之一可變。

為什麼這個矩陣比排名更有效#

隨著計畫推進，這份矩陣本身就成了一份策略文件。專案完成時可重新分配釋出的資源；危機（依定義就是新的 critical）出現時可重新調配；策略改變時亦然。

透明的資源分配與「對情境變化的回應」會：

• 讓團隊對齊、避免內部對立
• 讓主管不再覺得「讓出資源 = 地位下降」——他們是在執行 critical 優先順序的關鍵角色
• 用公平、不可動搖的邏輯取代加總不起來的排名