不知道身為 PM 的你有沒有過這樣的經驗，當你走進公司大樓電梯，沒想到公司高階主管也走了進來並關上了電梯門（因此你想逃也逃不掉），緊接著，他冷不防地問你：「那個ＸＸＸ專案現在的狀況怎麼樣了？」
他不是你的直屬老闆，只是你老闆的上司或更高層的上司，所以平時你並沒有直接向他報告的機會，這個時候你會怎麼做呢？
搭乘電梯的時間很短，大概就十幾二十秒，了不起一分鐘， 專案細節這麼多，肯定講不完。你也許會想，大不了跟他出電梯，邊走邊報告完不就好了，有什麼關係？
我在此要由衷地提出警告，這件事對你的關係可大了，千萬別輕忽它對你的影響！
首先是，你可能正要去主持會議，非準時不可，不一定可以這麼做。其次，你的長官未必希望這樣做，他可能只是隨口問問，自己等會兒也有重要的事要辦。那麼，如果你沒講完，長官又走了，結果會怎樣？
嗯，很簡單，那就是你有很高的機率會就此黑掉！
據我多年的職場經驗，這類高階主管大都不會當場表達對你的評價，但卻會在心裡默默把你貼上「這個 PM 不行」的標籤。而且，基於對專案的擔憂，他也會找你的直屬老闆聊聊這件事，甚至是直接要求把你給換掉。一旦落得如此下場，你在公司的 PM 生涯也就玩完了。
你意識到了嗎？不是平時你有多努力就行了，你還得在這種隨堂考上保住你的小命，不會莫名其妙就掛掉。「抓重點報告」的技巧，絕對是一個 PM 最重要的能力之一。
別說是 PM 在路上被隨堂考了，就算是一般的會議，不少人也很欠缺這樣的能力，在報告工作狀態的時候，常常不自覺地兜圈子，或是有意地避重就輕，總是讓別人聽得一頭霧水，讓會議拖得又臭又長。所以，人人學會抓重點報告，也是提升開會效率的重要手段。
那麼，到底報告該怎樣做才好呢？
一. 專案績效總結（Summary）
拿以前我在手機公司服務的情況來舉例，在管理手機軟體專案的時候，我們都會用簡單的紅／黃／綠燈來表示專案的健康狀況，這也是專案的「風險程度」。紅燈代表「有 PM 處理不了的狀況，需要協助」，有高度風險；黃燈代表「有 PM 可掌握的狀況，需要知會上級」，屬於中度風險；綠燈代表「有 PM 可掌握的狀況，無需知會上級」，為低度風險。
這裡所說的風險可能是，功能做不出來、功能的品質無法達標、進度延誤、成本超支，或是這些的組合。這幾個部分就是專案的範疇（Scope）、品質（Quality）、時程（Schedule）和成本（Cost）四大面向，不僅是專案管理的重點，也是專案的績效衡量基準（Project Performance Assessment Baseline）。
當我們 PM 被這類高階長官逮到的時候，首先就得告訴他們這個燈號，也就是我們對專案的「自我績效總結」。如果你在公司的名聲不錯，只要不是紅燈，長官們多半是直接放過你，懶得再多問。
不過，如果你在公司還沒建立好名聲，或者是長官還不太認識你，就算你宣稱是綠燈，他們通常也會繼續往下問，「這個案子現在到哪個 Stage 了？」
二. 階段和里程碑（Stages and Milestones）
由於你們之間還沒建立穩固互信，所以他們會想取得更多資訊來做交叉比對，看看你說的綠到底是不是真的綠，還是其實你有色盲。當然，他們也擔心，你會不會因為怕被問倒而有意忽悠他們。
那麼，為什麼是先問「階段（Stage）」而不是先問其他的問題呢？原因其實也很簡單。
「階段」是傳統式專案管理常用的手法，也是衡量專案進度和節奏的簡單依據，這些人能做到高階主管，都有很多把刷子（不是兩把），對公司各種產品專案的開發節奏沒有不熟的，哪個階段大概需要幾週，甚至是幾天，裏頭應該有哪些里程碑必須被達成，數據門檻是多少，一切都瞭若指掌，可能比你這個 PM 還要熟。
比方說，手機軟體專案大致可以拆為幾個連續的階段：Boot Up（開機）、Code Complete（CC，程式碼寫完）、Alpha（初步整合版本）、Feature Complete（FC，功能做完）、User Trial、Beta（用戶隨機測試）、Engineering Release Candidate（ERC，內部最終版本）、Customer Beta（CB，外部客戶測試版本）、Code Freeze（CF，嚴審程式碼變更）、Customer Release Candidate（CRC 外部客戶出貨版本）。當這些階段完成之後，也就是達成了相應的主要里程碑（Key Milestones），而且這些里程碑都有它們一定的過關條件。
除了主要里程碑之外，當然還有次要的里程碑，例如，System Stress Test（SST，系統穩定度壓力測試）。SST 的數據，是衡量手機軟體是否穩固牢靠，足以當成出貨版本（CRC）的重要依據。還有像能耗（Power Consumption）、效能評比（Performance Benchmark）等其他的測試數據，也都是類似的重要指標。
所以，當一個 PM 向長官報告專案是綠燈的時候，當下階段之前的所有里程碑就應該是 100% 達成，如果不是這樣，那你很可能就會被認為是在胡說八道，除非你能提出合理的解釋。比方說，之前已經達成 SST 的標準，但最近又被未知的問題給搞爛掉之類的。
前述的各種術語和定義，不僅是公司上上下下的專案管理溝通語言，也是專案管理的重要節奏感，PM、RD、QA、Art 等所有專案團隊成員都要很清楚熟悉，這樣「跨部門溝通」才會精準有效率。
如果長官認為你報告的 Stage 和相關里程碑的達成度和數據都沒問題的話，你就過關了。那如果你報給長官的是黃燈的話，長官可能還會這樣問下去，「目前有哪些 Gating Issues？」
三. 卡關議題（Gating Issues）
什麼是 Gating Issues？是在 Gate 什麼？接下來一樣繼續用手機專案來做說明。
3.1 缺陷（Issues／Bugs）
做專案沒有不遇到 issue 的，一支手機裡有很多的韌體（Firmware）、驅動程式（Drivers）、應用程式（APP）和作業系統（OS）等軟體，這些夯不啷噹加起來至少有幾百支軟體程式，參與專案的 RD 和 QA 等團隊成員，動不動也是兩三百人（這還沒算上外部的 third party 合作團隊），這麼多經驗和專長都不同的人一起合作，怎麼可能會沒有製造出缺陷呢？
萬一這個專案是年度旗艦機的大案子，產品會被遍及全球的七八十家電信業者預約採購，為滿足不同客戶的多樣需求，專案內的設定和客製化，組合起來也是天文數字，這樣的專案，缺陷總數經常都是上萬條的規模，在任何時刻，Open Issues（尚未結案的缺陷）也常態性地維持在好幾千條的規模，PM 你是要怎麼向長官報告這些缺陷的狀況？
當然不可能全報，這豬都知道。既然無法全報，那到底要報哪些？長官才會滿意（重點在這裡，重點在這裡，重點在這裡）？
你一定會直覺認為，「廢話，當然是那些影響比較重大的啊！」好，問題來了，我問你，哪些才叫做影響比較重大的？「重大」又是怎麼定義的？再來，你要怎麼從海量的 Open Issues 當中把它們篩出來？
3.2 專案卡關缺陷（Project Gating Issues）
專案管理之所以難，很大一部分就是在這裡，Issue Tracking（缺陷監管）是極為耗神耗時的工作，會佔掉 PM 絕大部分的時間。
你沒有看錯，「做好專案管理計劃」對我們來說不過是小菜一碟，快則幾十分鐘，了不起幾小時也能搞定。但是要從海量 Open Issues 當中，篩選出那些影響重大的，PM 就必需先對「所有的」Open Issues 都有掌握，否則根本無法有足夠的信心做出判斷，因為，只要有「一條」漏掉，專案就有可能出大包。
這些影響重大的 issues 的數量，會跟專案難度和客戶數量有極大的關聯，差異巨大，不過大約是 Open Issues 總數的 1/10 左右。這些缺陷非解決不可，否則就無法結案，它們就叫 Project Gating Issues（專案的卡關缺陷）。
你也許會覺得怪怪的，那其他的缺陷不用解決就可以出貨嗎？我的答案是：Yes，but PM 的判斷要非常精準無誤。專案管理之所以難，另一處就在這裡，你必須對用戶和客戶（重要利害關係人）的想法有「非常非常高」的掌握，這又是另一門高深的藝術。
回過頭來看專案的卡關缺陷，它們可能還是有數百條之譜，依然是很大量，你還是無法向長官報這麼多條 issue 啊！那怎麼辦？
這裡就要帶出一個非常重要的觀念，就是，這些 Project Gating Issues 其實「只要」在專案結案之前被解決掉就好了，在執行專案的大部分的時間裏，它們「不一定都非常緊迫」。那你猜，哪些 Issues 才會是「當下比較緊迫」的呢？
ㄟ，當然不能用猜的！這是有方法的，這時候「階段」就可以幫上忙了。
3.3 階段和里程碑卡關缺陷
其實，Project Gating Issues 裏，只有「一小部分」會造成「當下」所在階段和該階段內的里程碑卡關，可是 Project Gating Issues 瞬息萬變，有時候突然被解掉了幾條，有時候又突然冒出很多條，所以 PM 要「天天」盯著「所有的 Open Issues」，時時更新自己監管的 Project Gating Issues 清單，因此工作量就會非常巨大。
在這種情形之下，PM 必須更專注在「排除當下階段和里程碑的 Gating Issues」，專案才不會被卡關，進度才不會延誤。這也就是為什麼長官們會問 Gating Issues 的原因，而且就是指當下階段和里程碑的 Gating Issues。
這些當下階段和里程碑的 Gating Issues 理應不多，太多就是 PM 你有很大的問題，不是沒有採取適當手段在「源頭阻斷」它們發生，就是沒把它們「夠快收斂在可控規模」。結論就是，你沒管理好這個專案。
正常狀況下，這些當下階段和里程碑的 Gating Issues 應該在個位數，那你要全部都報給長官聽嗎？好像可以，是不是？
當然不是！還記得你現在是在電梯裡，你只有幾十秒的時間報告嗎？所以，你只能再從中篩選出「最重要」的兩三條 Gating Issues 向長官報告。注意，「最重要」隱含的意義是，這位長官最關心的議題是什麼？不是 PM 你想報告什麼就報告什麼，這就叫做利害關係人管理。
做到這種程度，PM 應該夠到位了吧？
不夠，當然還不夠。
3.4 缺陷處理對策（Gating Issue Actions）
當篩選出最重要的兩三條 Gating Issue 之後，PM 你有沒有想過，該怎麼「系統化」地向長官陳述，他才會滿意？如果沒有，那也是前功盡棄。難得有越級表現的機會，這不是太太太可惜了嗎？
如果你只會陳述問題（Gating Issue），卻沒有對策（Actions），這只是把問題丟給長官；如果你已經為每條 Gating Issue 都提供了對策，可是卻沒有指出對策各自的負責者（Owner），這樣的對策，可信度也還是不夠的；如果你既提供了對策，也為每個對策指出了負責者，卻沒有為每個對策指出期限（Due Day）或下次查核時間點（Check Point），這樣也是無法讓長官放心的。
所以不論是口頭或是書面，報告一條 Gating Issue 一定要有簡述（Brief）、對策，以及各對策的負責者和期限。
比方說，某 issue 為：拍照時會當機（Brief），RD 部門的王高手已經找到原因並正在測試解決方案，預計下午一點會有結果（Action 1／Owner 1／Due Day 1），QA 正在同步複驗整合版本，預計今天下午五點會有結果（Action 2／Owner 2／Due Day 2）。
確實掌握以上的要點，保證你的報告一定過關，不但能活著回來，還可以在長官心中留下好印象，讓他不想重用你都不行。
好了，報綠燈會被追殺，報黃燈也會被追殺，那如果專案是紅燈，你真的敢如實報告嗎？手腳會抖嗎？
不怕，不怕，我挺你！
四. 升級呈報（Escalation）
如果你有盡心盡力，做到底了（也就是，就算是讓你老闆來管這專案，狀況也不會比你好到哪裡去的程度），那麼你就應該要能無愧於心，天不怕地不怕才對（不然叫老闆自己來管看看，你來啊～來啊～）。
比方說，我曾經負責過一個旗艦機種專案，該案使用的是高Ｘ公司同步開發中的首款雙核心 CPU，新東西問題當然很多，一點也不令人意外，其中包括，過熱、能耗過大，效能不彰等，不過其中有個最棘手、最嚴重的，就是會「隨機當機」。
數個使用同款 CPU 的專案，都投入了大量的 RD、QA、PM 人力和測試機台，日夜輪班測試，企圖縮小問題的根因的範圍，可是進展卻一直很緩慢。直到有一天，我們終於發現了一些「頗為明確」的線索，兇手極可能是來自於控制 CPU 的韌體。
由於這部分被高Ｘ公司保護起來，我們並沒有其原始程式碼可做進一步的調查，所以只好向高Ｘ公司回報，請他們盡速優先協助解決，可是顯然高Ｘ公司並不這麼認為，配合調查的步調依舊非常牛步（對啦，他們又不是只有我們這家客戶...）。
我們 PM 人微言輕，屢推不動高Ｘ這隻大牛，只好緊急將這些困難層層上報到最高主管（包括 CTO 和 CEO）那邊去求救。這些最高主管們也立即意識到問題的嚴重和緊迫，便立即去電高Ｘ公司高層（全球業務副總裁和 CEO）施壓。
藉由高Ｘ公司全球業務副總裁的積極協助，一路由上往下釘，這才把他們的 Software RD、FAE、Logic 等部門的最高主管們（VP 等級）全都給踢出來，和當時駐點在高Ｘ公司總部的我和其他隊友們日夜緊密合作。
在這樣雙方公司都積極投入巨量人力物力，24 小時不分時區，接力緊密合作的情況之下，我們還搞了三個多月才終於釐清了此 issue 的根因，兇手果然就是新 CPU 的硬體和韌體缺陷。
在這個案例當中，我們幾個案子的 PM 就都是一路把專案亮紅燈，刻意引起高層主管關注，加上團隊的努力高層都看在眼裏（做到底了），所以當我們把問題升級呈報求救的時候，並沒有遭到任何的責難，反而是得到了滿滿的有效協助，最後專案才能壓線及時結案，順利大量出貨。
（你看起來只是輕描淡寫，真實過程可是血淚的很啊～）
專案出的包，有時候就像上例一樣，非戰之罪也，不能歸咎於 PM，只要 PM 做到底了，並能及時升級呈報求救，這樣 PM 就不用害怕。不過，如果紅燈是因為「應注意而未注意」，「可避免卻未避免」，「該喊救命卻太慢喊」，那這就是你的管理不善了，恐怕神佛上帝都救不了你。
結語
專案管理的重點，從來就不在於是否能清掉所有的 issues，而是在於，對各階段和里程碑的 Gating Issues 的掌握，這也是專案管理的重要節奏感。管理好這個專案品質領域，專案的進度（Schedule）就能守得住。
做 PM 真的要三頭六臂，要能使命必達，要有問題緊迫性的靈敏嗅覺，要是客戶和用戶肚裡的蛔蟲，能掌握哪些 issues 可在以後更新（Patches）就好，用空間換取時間，這樣 PM 你才能以有限的時間和精力，把海量的 Project Gating Issues 逐漸收斂到「零」，並且還能游刃有餘，同時 handle 好幾個專案，全部準時結案出貨。
掌握前述的這四大法寶，盡心盡力做，不管你的專案燈號是紅、是黃、是綠，你就不用害怕被高階長官隨堂考。這確實不簡單，不過也不是像登天那麼難，是吧？
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
