痛點之尺 · 拆解《專案管理胃痛圖鑑》
作者 山姆（謝冠生）・喵喵書評創辦人
發布
讀過近千本商業書，這篇不複述內容——只用《痛點》的 P.A.I.N. 之尺，挑這本書最該被戳的那一格，講一句你帶得走的判斷。拆一本書的四個步驟 →
最貴的胃痛，是把沒人要的專案做到完美
楊孟真（Sylv!a）把專案裡那些讓人反胃的時刻，做成了一本圖鑑。《專案管理胃痛圖鑑》把三十一種專案常見的失靈，當成三十一種病，分進六大科別。每一帖的走法都一樣：先還原現場，讓你邊看邊點頭「對，我就卡在這」；接著快篩病根，把症狀底下真正的毛病挑出來；最後開處方——而且理想解之外，還附一帖 Plan B，給那種老闆已經拍板、硬要往前衝的日子。
她這身功夫是磨出來的。二〇一三年進軟體業，從測試和開發做起，二〇一七年轉做 PM，一路把手伸進 IT、行銷、行政、流程。這本書改寫自 iThome 鐵人賽拿下冠軍的那一系列，所以它讀起來像一個在急診室待久了的人，把她親手經手過的病歷攤開給你看。
它最誠實的地方，是不假裝專案能被完美控制。它承認會出事，然後教你出事時怎麼止血、怎麼在混亂裡還被人信任、怎麼在 PM、工程師、主管三方各說各話時，找出一個大家都咽得下去的出口。這些是 AI 一時半刻還接不了的手感。
但這把手術刀有個前提：專案已經躺上手術台了。刀開得再漂亮，也是在事情發生之後才動的。而《痛點》這把尺，想把你往前拉一步——拉到還沒推進手術室、甚至還沒生病之前。
她把混亂，一格一格做成了門診
這本書真正厲害的，是它把「專案好亂」這種說不清的難受，拆成看得見、對得上號的病症。你不再只是胃悶，你知道自己得的是哪一種、掛哪一科、該吃哪一帖。光是這件事，就足以讓一個在專案裡快窒息的 PM 喘一口氣——原來這種難受有名字、有前人踩過、也有解法。
它也很老實地畫出那張三方賽局的圖。PM 想守住承諾，工程師想守住可行，主管想守住場面，三邊的痛不一樣、話術也不一樣。書教你當那個站在中間、把三種語言翻成同一種的人。全是實戰裡熬出來的手感，讀起來很解氣。
病根往回追一步，是「這需求是不是真的」
圖鑑教你追病根。需求一改再改、範疇像水一樣漫出來、時程被壓到骨頭，這些症狀底下，書會帶你找出組織裡那個真正的病灶。這一步做得很好。
《痛點》想追的，是再上游一格的那個病根。很多讓 PM 半夜驚醒的專案，毛病其實出在它從第一天起就不該存在——那是一個沒人真的想要、只是某個位子上的人拍腦袋要的東西。你把它管得再好、時程守得再準、三方協調得再圓，成果也只是一件沒人要的事，被做得又快又漂亮。這種專案不會在中途爆給你看，它會一路綠燈交付，然後上線那天沒人用。那才是最深、最貴、最遲才發作的一種胃痛。
快篩，也可以用在動工之前
圖鑑的快篩，是拿來判斷「這個已經在燒的專案，火源在哪」。同一套快篩的精神，其實搬得到動工之前——用在需求本身。
方法一樣不浪漫：別問「這個功能聽起來合不合理」，那種問法永遠得到客氣的點頭。要問的是，有沒有一個活生生的人，已經為這件事真的痛過、甚至掏過一次錢或繞過一次遠路。需求文件寫得再工整，都只是症狀的描述；真正的病歷，是有人為了它流過血。找不到那個人，這張需求單就先別急著排進時程——它很可能是個健康的人在裝病。
會議室裡最容易被當成證據的，是熱鬧本身。有人在群組敲碗、老闆轉了一篇報導、隔壁團隊也在做同樣的東西，這些都很像需求，卻都還不是。它們是體溫計上升了一格，離「這裡真的爛了一塊、爛到有人肯付錢請你補」還有一段距離。快篩就是拿來卡在這一步，別讓一時的熱度，把整個團隊直接送進手術房。
三方賽局裡，其實還有第四把椅子
PM、工程師、主管——這三方，書寫得很滿。但一個專案之所以值得存在，靠的是第四把椅子上那個人：那個本來該因為這件事被解決而鬆一口氣的使用者、客戶、真正的痛主。很多專案的悲劇在於，三方在會議室裡吵得面紅耳赤，第四把椅子卻一直空著，沒有人真的去把那個人請進來問一句：你到底在痛什麼、痛到什麼程度。
我讀過一整面牆的專案管理書，多數都在教你怎麼把已經接下的事管得更順。這本書難得的地方，是它不裝神，它承認專案會生病，然後教你當一個穩得住的急診醫師。而痛點想補的那一格更早：在把整個團隊推上手術台之前，先確認這個病人，真的病了。
動工前，先給需求開一張門診單
所以，下一個專案排進來、下一份需求單擺到你桌上時，先別急著分科、開帖、排時程。先把那張門診單，開給需求本身：這件事，有沒有一個叫得出名字的人正在痛；他為這個痛，已經付出過什麼。等這一格答案是實的，你再把圖鑑那身好功夫全使出來。到那時候，你救的就是一個真正值得被救活的專案。