「專案 delay」，應該是很多 PM 的惡夢，卻也是專案經理天天在面對的事情，跟大家分享一個我之前在商業思維學院分享過的案例。
那時，我負責一個公司重要客戶的專案，專案已經進行一段時間，公司當時採用瀑布式開發（所以你知道真的年代久遠）。
我們在專案預計要 release 前一個月時，我們發現有些功能趕不及， bug 也比預期的多，根本改不完，我當時請工程師重新估了一個時程，結果發現還要多六週左右才能完成，delay 一個半月！客戶根本不可能接受！
這時的你，該怎麼做呢？
首先我要先說，一開始就要減少 delay 的危機！雖然很幹話但是是事實，你需要預留緩衝，然後建立很多檢查點，一有風險的味道就毛豎起來趕緊處理，不要像我當時太菜，快 release 才發現，能夠做的事情就很少了。
大家有沒有聽過扁鵲三兄弟的故事？以下大致整理敘述跟大家分享：
扁鵲是神醫，他們家有三兄弟，都是醫生。有天魏文王就問扁鵲說，你們三兄弟中，誰醫術最高明呀？
扁鵲說：「大哥最高！二哥第二，我最差」
魏文王：「那為什麼大家都叫你神醫，沒有這樣稱呼他們？」
扁鵲：「我大哥治病，光看一眼，就知道這個人快生病了，趕快幫他調理一下，還沒生病就治好了，所以大家都以為他不會治病；
我二哥治病，只要稍微接觸一下病人，就能找出剛開始的病灶，趕緊趁擴大前消除，所以大家都以為他只會治小病；
我看病，都是在病很嚴重的時候，要大刀闊斧，插針放血敷藥手術，所以救回來大家都以為是我高明，名滿天下，事實上我根本遠不及我兩個哥哥呀！」
控 schedule 也是這種道理，厲害的 PM 根本不會讓 delay 這種事情，等到快爆炸才發現，有些產品開發方法也可以減少這種情況，例如 Agile 敏捷開發法。大家有興趣的話可以敲碗我整理出「delay 的原因和避免的方法」。
這篇文章講的是「在 Waterfall 的開發流程中，專案已經要爆炸了，專案經理的救火法」。
我那時採取了三個步驟：
- 簡單做
- 調資源
- 同步改
一、簡單做
一個版本內可能有很多功能要做，這些功能可能又有考慮多周詳、要覆蓋到什麼程度的問題，厲害的產品經理一開始在設計功能的時候，先盡量讓功能沒有相依性，不會一個功能卡一個功能，等到要 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 的三種做法，你還有什麼方法？歡迎跟我分享！
