專案上最沒辦法避免的一件事情恐怕就是開會了。

而我老實說還滿排斥開會。 因為總覺得開會是件很浪費時間的事情。 一屋子的人，可是常常不一定有需要或是幫得上忙；尤其要是會議前準備沒做好的，更是惡夢，可以變成超級無效率的聚會呢。

但無效率的專案會議到底有甚麼特徵呢？

最明顯的特徵就在於「問題沒有重點」；問題雖然不斷的被報告出來，但與會者卻完全分不出各項的重要狀況。 比方說，某 PM 可能準備了一份「上周工作狀態」，然後在會議上逐條報告：

「咳… 上周狀況是這樣的。」

「首先，手冊第三章撰寫時碰到問題，因為 SD 模組還沒做出。 所以技術人員停擺了下來，但是 SD 模組這周應該會好，所以問題應該會解決。」

「那剛剛提到 SD 模組 Delay 是因為 A 君上週生病，所以才晚了三天。 那預定這禮拜三會做好。」

「Y 模組則在測試中發現 3 個重大 Bug。 Beta Team 已經在試圖解決，會盡快解決。」

「此外，D、S、還有 B 模組發現遭遇技術問題，已經請求技術Team支援，下禮拜應該能開始研究。」

「B 君還有 C 君在參與 K 模組時出了錯誤。 我建議應該送他們去參加資策會下周要辦的 X 課程。 預定學費是一個人 3000 元，可以參加嗎？」

「D 君、E 君還有 F 君因為流感，所以請假在家裡休息，他們手上的工作會順延三天交出。 那大家自己評估這件事情會不會造成你手上工作的影響。」

「有嗎？ 有嗎？ 你也有？ 你們也都有？ 那我們一項一項評估。」

這是還滿讓人目瞪口呆的專案會議的開法。

但是有趣的是，這種專案進度會議的開法在很多地方還確實是如此。 每周由 PM 或是案子的負責人，「逐條」檢討前一周所有發生的事情。 碰到問題了，也一個一個的詢問狀況，並試圖在會議上解決每項問題。 小型一點的案子，這種開法恐怕數小時跑不掉的；而尺度稍微大型的案子，這樣的會議往要個半天一天恐怕也不奇怪。

但這樣的專案管理方式有甚麼問題呢？ 或是有問題嗎？

我覺得最大的問題，就在於相關人等其實完全沒辦法當場評估事情的「輕重緩急」。 上面的對話中，所有我們知道的只是 Delay 以及有問題。 但是這些 Delay 是大是小？ 是嚴重還是輕微？ 其實聽到報告的人根本無法判斷。 如果只是三項、五項還好，但當報告的問題是 20 條或是 50 條時，其實到後面聽的人早就麻木了、根本也就失去警覺心了。 最後常常也只是聽完流水帳，然後就散會，根本無法真正解決核心問題。

再來，如果這專案尺度小，大事小事或許都很重要，一兩個人也確實可以親力親為的處理一切問題。 但若專案尺度大時呢？ 如果做為一個專案的負責人，沒有切割權限並把工作分層下放時，那這樣的負責人恐怕是很無能的！ 你或許會疑惑，為何是無能？ 為何親力親為不是負責任呢？ 就拿高鐵施工這樣大規模的專案而言吧，如果你是殷琪這樣的階層，你會因為某天彰化的一根柱子挖到地下水而跑去查看並謀求補救措施嗎？ 要是不能分工負責的話，那不是成天要東奔西跑，而沒時間去思考或討論這位階該去思考的事情了(如長期經營策略)。

實際上，做為一個有能力的管理者，碰到問題時第一步不是先想怎麼解決，而是應該要區分「輕重緩急」。 因為人的時間一天只有 24 小時，絕不可能凡事都親力親為。 有些事情或許要親自處理，但有些事情必須要讓你的同伴、讓你的下屬、或讓你的團隊來幫忙解決。

實際的運作當然還有很多眉角之處，但簡單的講，分輕重緩急的中心思想其實就是「抓大放小」這四個字。

坊間很多教人時間管理的書，大多會教到一個大原則（你可以用在日常生活或是平時的工作中）。 就是拿一張白紙，把它分成四個象限，分別在 X 與 Y 座標標註「重要」以及「緊急」。 當碰到一件事情，先來判斷這件事情的狀況是落在哪個象限中。 除非是掉在緊急與重要的區塊內，可能才需要立刻處理。 而那些不重要不緊急的，則就可以慢慢的請其他人協助、甚至暫時放著不管搞不好都沒什麼關係。

當然，這裡是講得很簡單，實際的狀況可能複雜得多。 緊急的部分我這次先不打算多聊，留待下次來談，這篇先專注於談「重要的事」。

事情可能一次冒出來十件二十件，他們或許都不很緊急，但是誰該先處理呢？ 可能就是靠重要性來排列了。 那重要性要如何定義？ 這可能很難一體適用，但我自己在日常生活中是傾向用 Impact 的狀況來做考慮。

換句話說，這件事情對於未來長期的影響如何？ 對於中期的影響如何？ 又對於今天明天的影響如何？ 未來的影響我會給予略高一些的權重，而當下的影響若無關痛癢，那甚至可以直接忽略的。

舉例而言，放假一天要念書準備考試，可是又想要痛快的玩一天。 那因為考試對於將來的影響可能比今天能開心來的重要，所以我會把時間分配給讀書。 大致是這麼樣的一個概念。

當這樣的一個評量機制建立後，就可以把日常生活碰到的大小事給予一個評分，然後據此處理。 生活上，我還是再一次建議大家可以嘗試使用「工作清單」。 比方說我在生活管理上很依賴 Outlook，會把每日想到要做的大小事都記錄在 Outlook 上。 一來時間到了系統會提醒我，二來還可以跟手機 /PDA 同步，隨時都有辦法查看。 而這類工作清單的概念之前也都有介紹，唯一這次要多談的，就在於每項工作你其實可以去設定「權重」，或是「分類」。 這樣，當同時間出現好幾件事情急待處理時，你就知道哪些該先處理，哪些稍微等一下也沒關係。 如此，就能把握「捉大放小」這原則啦。

而在專案中又該怎麼辦呢？ 我們前兩篇提到了要能綜觀全局，你需要一個專案全貌。 而當你有這樣一個專案全貌時，你其實可以透過排程找出所謂的「專案要徑」。 而要徑，就是你「抓大放小」的依據了。

甚麼是要徑呢？ 「要徑」指的就是影響專案最後完成日的那一條連續工作堆疊而成的連線。

如上圖，所有紅色工作的連線將會影響專案最終完成時間。 藍色三角型的位置是完成時間點。 若紅色任何一個長方型能縮短，藍色三角型就會往左邊移動，這代表專案提早；反之，若紅色長方型任何一個變長了，藍色三角型就會往右邊移動，這表示專案 Delay。 而其他綠色的長方形的縮短拉長則不一定會有影響。

換句話說，專案到底何時做完，會受到紅色連線上的所有工作影響。 這條連線上有工作 Delay，那專案完成日就會被推延；這條連線上若有工作提早完成，那專案完成日就會提早。 所以這條路徑上的工作，是最重要的一群工作。

但因為是連線，所以在同一個時間切點，並不會有一堆要徑作業都在上面（見下圖）。 而可能只有一兩個作業是真正關鍵，是會影響專案完成日的。 這些才是這類會議上，大家應該花心思去注意的事情。

如果這些工作有任何變動（不管是出問題、有人生病、可能有些潛在問題），那會議上應該被提出、強調、甚至尋求解決之道。 加上專案通常都有資源的限制，必要時，甚至可能犧牲一些不這麼急迫的工作，來拯救這幾個要徑上的關鍵工作。

但一樣，你若不知道全貌，就不知道哪些是要徑。（所以為何要能看到全貌是我放在最前面談的一件事。 因為你必須要先能掌握全貌、了解目的，否則後面的任何決策都絕對會是錯的。）不知道哪些是要徑，所有事情看起來就都很麻煩，很嚴重，必須馬上解決。 若所有事情都一樣重要，那會議中就甚麼都是問題，並造成會議無法聚焦。 而無法聚焦，就不知道如何分配有限的資源、更無法協調與調度。 在這結果下，自然事情就變得好像很多、永遠也處理不完，時間更是永遠不夠。

更慘的是，這還會變成惡性循環。 問題解決不完會造成更多問題；更多問題讓處理時間更短、緊急事件變多，造成越來事情不知道該從何下手。 PM 將變成救火隊；到處有火燒起來，到處得去滅火。 而等到事情多到延長工作時間也解決不完、周末來上班也解決不完、甚至整天住在公司也解決不完時，你將更沒辦法把事情分出去或是抓大放小，也更無力解決問題。

那這時候，往往只能兩手一攤，等著…砍掉重練了。

(喂，不是自殺啦、我是說專案就沒救了…)

 

那有沒有辦法導向正向循環呢？ 這是下周要談的 …

本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。