PM基本功 — 專案要爆炸(延遲)了，怎麼救？

拯救delay的三步驟：簡單做、調資源、同步改

專案要爆炸(延遲)了，怎麼救？

扁鵲是神醫，他們家有三兄弟，都是醫生。有天魏文王就問扁鵲說，你們三兄弟中，誰醫術最高明呀？

扁鵲說：「大哥最高！二哥第二，我最差」

魏文王：「那為什麼大家都叫你神醫，沒有這樣稱呼他們？」

扁鵲：「我大哥治病，光看一眼，就知道這個人快生病了，趕快幫他調理一下，還沒生病就治好了，所以大家都以為他不會治病

我二哥治病，只要稍微接觸一下病人，就能找出剛開始的病灶，趕緊趁擴大前消除，所以大家都以為他只會治小病

我看病，都是在病很嚴重的時候，要大刀闊斧，插針放血敷藥手術，所以救回來大家都以為是我高明，名滿天下，事實上我根本遠不及我兩個哥哥呀！」

1. 簡單做
2. 調資源
3. 同步改

一、簡單做

一個版本內可能有很多功能要做，這些功能可能又有考慮多周詳、要覆蓋到什麼程度的問題，厲害的產品經理一開始在設計功能的時候，先盡量讓功能沒有相依性，不會一個功能卡一個功能，等到要delay時，就可以把優先順序沒這麼高的功能先捨棄。這是最常見的做法。

還有一種簡單做的點，就是功能還是做，但是先不考慮某些少數人會碰到的狀況，少做一點error handling，其實對工程師要考慮的事情就會少很多。不過要記得，這邊的減少要跟QA的測試項目同步一下，不然最後還是測出一堆bug，還要釐清，也很花時間。測出這些bug如果早就知道不在重新定義的範疇內，不會改，還讓QA花時間規劃和測試，其實QA那邊很浪費時間，也很傷士氣。

另外一種簡單做的點，就是bug了，bug當然要有優先順序，發生機率低，影響又小的，基本上就捨棄了，接著我會視情況捨棄「發生機率高但影響小的」以及「要特殊操作方法，才會發生的」，就是要一個個看還有討論的。

不過這邊要小心的是，現在的簡單做或是先不改的bug，都有可能變成之後的技術債，就好像你在生活或工作上，一時沒時間沒精力把事情做好，先隨便做一下，結果後面補救要花很多時間，建議之後如果有下一個版本，還是多抓些時間把這些技術債清一清。

二、調資源

很多人聽到這個，就會說「猴！人月神話！加資源沒用還會花更多時間！」但我常說PM不要只記得教條，這其實要看狀況。

如果你的團隊不是只做你的案子的專案團隊（很常見），那「調資源」可以是「先把這些人在其他專案的資源call回來」，其他案子先不做，這也是一種調資源呀！這樣其實不會有加人帶來的問題。

或者是，工程師除了專案本身，其實有很多其他事要做，例如處理客服問題、一些定期會議、讀書會分享會，PM幫忙能減的先減，讓大家把資源先花在衝刺上，也是一種調資源。

另外如果有一些比較獨立的功能或是bug，還沒開始做的，就有機會找其他人支援，但的確要注意人月神話的問題，如果團隊還要花時間交接給這個人，還要跟他解釋一些邏輯和因果關係，那不如不加這個資源。

另外要注意的是，要先做完「簡單做」這個步驟，再去調資源，因為你把資源call回來，是會影響其他專案的，這需要老闆同意，否則你怎麼知道其他專案的商業價值或是優先順序，不是比你的專案高呢？

PM要取得老闆協助，絕對不是一delay就去求老闆，這樣老闆第一個反應就是：「那我要你幹嘛」（很殘酷）。所以要讓老闆知道，你已經能砍的都砍，能橋的都橋，資源都盤點好了，帶著解決方案直接請他協助，甚至你可能跟其他專案的PM都確認好影響了，再去找他，都能增加你爭取資源的成功機率。

三、同步改

我那時得知客戶拿到版本之後，自己還要測試一個月，才會正式上線，這個資訊就是PM的有力武器了！我們可以「偷」一點客人的時間！（所以我昨天說，PM不只要知道自己專案的schedule，也要知道客戶的schedule呀！）

我當時就跟客戶說，既然他們也要一些時間做測試，測完如果有bug我們也要修改，目前我們有些bug還沒改完，能不能我先提供beta版本，我先列出known issue，你們一邊測、一邊回報問題，我們這邊也同步修改呢？目標多兩週的時間把這些問題收斂，客戶還有兩週做最後驗收。

客戶因為我承諾他們回報的bug會改，他也想趕緊進他們QA的排程，這麼一來，我就偷到兩週的時間了。

另外一種做法是，假設專案有十個功能，先切幾個版本，前面幾個功能做完測完，就先給客人測試，在客人測試的時間，我們做下幾個功能，至少前面的功能是可以驗收出貨的，後面頂多剩下一兩個功能沒完成，或是bug沒改完，損害會比一整個版本都delay還要小。

至於要跟客戶協調哪一種做法，要看你對客戶的熟悉度，還有他們的驗收上線流程，所以我一直強調，資訊是PM最重要的武器，能對客戶瞭解越多，能掌握的調整空間就越大，誤踩客戶雷的機會也越大。

以上就是拯救專案delay的三種做法，你還有什麼方法？歡迎跟我分享！