《我的專案筆記 #5》專案在交版前一天爆炸了，怎麼辦？– Hero米

這幾個月專案上發生一個狀況，有一位PM負責的專案，在開始的版本時，沒甚麼大問題，在中間的版本，也是順利交版，但是，有趣的來了，在交付最後版本的時候，開始出現大問題了，修完一個BUG，跑出四個BUG，最後又產生八個BUG，導致在交版前一天，需要讓所有的工程師一起協助處理，才能在最後一刻交付測試…。

其實，這樣的狀況，在專案開發上幾乎是必然發生的現象，尤其是第一次合作的專案，有些人會怪罪說是工程師技術能力太差、有些人會怪罪說專案時間太短、需求不明確、規格一直在變動…。確實，有非常多的原因導致這樣的狀況發生，但是事出必有因…。

約莫十年前，那時候剛進遊戲業不久，正當有一股衝勁想在遊戲業大展拳腳，但是也在那個時候看透很多現實，怎麼說呢？因為，那個時候公司政策是要求每個專案必須半年Demo一次，其實以專案管理的角度，這是沒有錯的，就像是我們會制定里程碑，然後拆解各項工作包，再細分需要執行的任務項，所以半年要Demo一次，不過就是公司面向的里程碑，確保專案進行。

就跟所有管理工具一樣，上有政策，下有對策。

確實，當時的製作人都把這半年一次的展示當成爭取更多資源的舞台，於是開始各種華麗的簡報、動畫、影片，卻不是遊戲本身的展示，結果就是參與這項半年一次展示的遊戲專案，變成動畫製作團隊，每半年推出一支看起來很厲害的遊戲影片，讓公司高層非常開心。但是，兩年過去，依然做不出任何東西。

還有一種狀況，就是專案預估需要2年的開發，但是擔心公司覺得2年太長，因此自己就砍成1年半，然後再被公司高層縮減成1年，於是就要1年做2年工，到了要展示當天，就只好推出看起來很厲害的影片，讓高層覺得專案開發是完全沒問題的。

其實，這些年一直在遊戲專案的體悟，大部分的遊戲製作人，雖然知道要開列里程碑，也知道要安排工作給團隊成員，也知道需要做很多很多的事，才能完成遊戲專案，但是在台灣，卻不太有遊戲製作人真的願意學習專案管理，所以專案總是在最後一刻就…你知道的。

回到這次的主題：專案在交版前一天爆炸了，怎麼辦？

在思考前，先讓我們定義一下問題，交版前一天爆炸了，是指什麼？
要先釐清問題的本質，才會有下一步的動作。
以這次遇到的專案為例，在專案交付前兩周，發現有很多的BUG怎麼修都修不好，不是修A了，就壞了B，就是修了B，A又壞了；舊的BUG一直跑出來；BUG越修越多…。導致交付前BUG只有增加的趨勢，沒有減少，交版Delay的風險就直接突破天際了…。

這時候可以使用常見的思考方式【三問為什麼】
Q1. 為什麼專案可能Delay，導致無法如期交付？
A1. 因為交版前BUG修不完，導致壓縮到交付日期

Q2. 為什麼交版前BUG會修不完？
A2. 因為修完一個BUG，出現一個新BUG，BUG生生不息、源源不絕…

Q3. 為什麼BUG會一直不斷出現？
A3. 因為工程師沒有辦法處理這些BUG

其實到這邊差不多已經接近尾聲
Q4. 為什麼工程師沒有辦法處理這些BUG？
A4. 可能有下列幾項的原因
(1) 工程師對於開發引擎的掌握度不足
(2) 工程師對於開發遊戲的經驗不足
(3) 工程師對於開發語言的熟練度不足
(4) 工程師過去的開發習慣不好
(5) 工程師過去的開發經驗與現在的開發模式衝突
(6) 工程師太過於內向害羞，有問題不敢提出
(7) 工程師並無獨力開發的能力
(8) …
這個階段就要盡可能的列出所有的因素，再一一思考對策。

※這邊推薦一個搭配使用的分析法【MECE分析法】
MECE分析法是麥肯錫第一位女諮詢顧問，在金字塔原理這本著作中，提出得很重要的原理，主要是由下列這兩點所構成
(1) 各部分之間相互獨立 （Mutually Exclusive）
(2) 所有部分完全窮盡 （Collectively Exhaustive）
白話來說，就是【 不遺漏、不重疊 】，窮盡一切所有可能。
例如：性別，由【男性、女性】所組成，就包含了所有的性別。

當我們盡可能的把所有的【可能原因】都列出來後，會需要另一套管理工具【PDCA】來輔助改善，之後會再寫一篇說明【PDCA】的實作概念。有興趣的朋友可以先去找來看。【PDCA傳送門】

所以，當【專案在交版前一天爆炸了，怎麼辦？】

第一步，快速止血，先盤點可用人力、資源，以最快的速度先處理問題。
第二步，定義問題，重新確認問題發生的原因。
第三步，解決方案，針對原因，思考一系列的解決方案。
第四步，優化改善，落實在專案開發中，重新思考流程是否需要調整。
第五步，成效追蹤，在優化改善的過程中，務必要實實的追蹤，確認是否有落實在專案開發上。

套句近幾年常聽到的一句話【小步快跑，快速迭代】，加速產品開發的進化。