會議室的空氣彷彿凝結了。

在你的左手邊的是堅持「規格開清楚才能動工」的工程師代表，而你右手邊則是不斷強調「要快速迭代搶市場、這個功能一定能搶佔先機獲得好成效」的業務主管，剛剛才結束一場激烈的辯論後，你對面的老闆，只淡淡的問了一句：「所以到底什麼時候可以好？」

這一刻的你，應該感覺胃的某個地方，又開始隱隱作痛。

噢，或者是頭痛。

如果你對上述場景感到一絲熟悉，那麼，歡迎來到專案管理的急診室。

我永遠記得，在多年前的一個專案驗收會議上，團隊明明確確地按照業務單位提出要求做出的成果，就因為業務單位的主管說了一句「我當時不是這樣說的」，直接驗收失敗。雖然我清楚知道，團隊一定是有按照需求去執行的，但又因為我並沒有任何一個白紙黑字證明，於是團隊只能在最緊迫的時程下加班趕工，做出臨時需求變動的要求。

那時候的我非常的自責，自責的原因不是需求變更，而是我讓團隊背上了「沒有按照需求方的需求做出成果」的黑鍋。

從那天起，我就開始零零散散的記錄下每一個讓我頭痛、胃痛的時刻。

所以，這一系列的文章不是教你怎麼考取 PMP （我相信網路上有很多資源了），更像是避坑指南，或是我的災難覆盤筆記，把我走過的冤枉路、踩過的坑、流過的血淚，濃縮成一份份真實的「病歷」，希望讓未來想走上 PM 路的你，能少痛幾次。

接下來的 30 天，我們不談空泛的理論，只看血淋淋的案例，而每篇文章內預計會包含：

• 保護性改編的真實臨床案例：如有雷同純屬巧合的真實案例改寫，拆解當時的狀況。
• 可能或許應該有效的處方簽：一些希望讓你可以馬上參考、照著做的檢查清單或實用框架等等。
• Plan B：沒有天天在過年的，總是會有一些不按牌理出牌、例外狀況需要面對處理。

好了，話不多說，請挑好一個舒適的位子，來欣賞各種我曾經遇過的專案災難。

在接下來的旅程中，非常歡迎大家在留言區分享你的「併發症」、質疑我的「處方」、提出你的「獨門秘藥」，或僅僅是留下一個「+1」，讓我知道同在專案管理江湖裡的你還活著 :D