北極熊的喃喃自語:專案開發的風險與應對 - 上

lancelee

「為什麼事情老是做不完？」
「為什麼milestone又delay了？」

遊戲開發的過程中總有許多的原因，會造成專案的表現與進度不盡理想，
這些原因，統稱為專案開發的【風險】。

風險越高，專案越容易失敗。

因此，盡可能地降低/控制專案開發的風險，是確保專案運作順暢的基本精神，
有些風險顯而易見，比較容易排除；
而有些風險是隱性的，常常會在不知不覺間，墊高專案的成本，造成專案的延宕。

這篇文章，簡單地羅列了一些，在北極熊經歷的專案開發中，所遭遇過的風險，以及我認為可能可以應對的方式。

每個人的經驗與專案的狀況都不同，你也可以有屬於你的應對處理方式。


寫在前面

• 控制風險不能保證你的專案成功，但可以降低它失敗的機率。
  

• 預防勝於治療。
  

• 降低風險，是專案中所有成員的共同責任。
  不是只有老闆、主管或製作人可以控制風險，這些人可以做的可能比較多，但專案中的每個人都可以做到一些事情，來降低專案的風險。
  

• 每個專案都有不同的難處，建議方式不一定適用於每個專案。
  尤其是強烈客戶需求導向的專案，因為自主空間有限，很多建議可能都難以被運用。
  

• 我這篇原本是寫給業內人員看的簡報，因此有些詞彙會比較硬一點，但我懶得去調整了。 (毆飛～
  

開案前階段

風險一
目標與時程的不對稱
可能造成的原因：

• 開案前的人力/時程預估太過樂觀 (能力或經驗不足)。
  

• 因為市場機會或客戶需求，或為了爭取成案，主動壓縮了研發時程。
  

• 研發團隊想做的事情太多了，以為總要面面俱到產品才會賣的好。
  

• 有時不是依據可以做多少事情來建立milestone，是先給deadline和要做的事情，硬湊成milestone。
  

建議解法：

• 在可能的範圍內，盡可能合理化，
  因為軟體研發具有不可分割性，一個媽媽生小孩要10個月，十個媽媽生小孩也要10個月。
  但是，每個專案的資源都是有限的，客戶的需求與市場的機會也可能稍縱即逝，因此時程的規劃不可能做到100%讓大家都覺得很舒服，只能說應該要盡可能合理化。
  

• 開案前的人力/時程預估，應由有經驗的資深人員負責，而非提案者提諸。
  可能的話，甚至應該由兩三組人交叉處理後相互比對，評估的精準度才會高。
  

• 綠燈審核應更加嚴格，盡量避免因隱藏成本而過關的情況。
  看過一個案例：提案者說20個人9個月就可以做完一款MMO，審核者聽起來覺得好棒，就讓他過了，結果開案後花了超過40個人做了2年...
  

• 控制規格，避免一開始就想要做多。應先專注於核心與亮點，內容和素材的部份可以日後添加。
  遊戲的核心機制夠出色，才是影響一個專案成敗的關鍵，而不是內容量。
  常常看到新人自己做的MMO企劃書，都要有上百個副本、上千個任務，銀行、公會、拍賣場也是缺一不可。
  
  但問到戰鬥系統是什麼？遊戲有沒有獨特的核心機制？都達不出個所以然來。
  
  這種過度重視內容量與衛星系統，但核心系統缺乏亮點的案子，通常死掉的機會比較大，或是日後要花數以倍計的成本來補核心。
  

• 由專案外單位，定期檢驗與更新專案開發狀況，對於偏離原本預估的專案開出黃燈或紅燈警告，並限期改善。
  由獨立的第三者，依據既定的標準來審核才客觀。
  專案自己會有本位主義，專案的上級單位可能會為了不想要成本白花，都不夠客觀。
  但至於開出黃、紅燈後，要如何應對，每個公司應建立自己的規範與流程。
  

• 紅燈又無法改善的專案，應評估是否停止開發。
  有時候，停損是有必要的，和股票一樣，有時候死抱著不放，只會從腰斬變成膝蓋斬...
  品質與進度嚴重出問題專案，很少能在上市後有亮眼的表現的，一直跳票產品還能有好表現的，全世界應該只有Blizzard一家而已...
  

• 可以採用專案總成本制，但需要相當的配套。
  一次啟動/投資數個專案，給每專案一筆錢執行第一個milestone，成果通過階段審核才有下一筆錢，反覆執行這個動作。
  錢燒完後如果不如預期，整個案子就直接砍掉，可能只有少數的案子會活到最後上市。
  
  這比較接近創投或大型發行商的作法，一般要在公司內執行會相當困難，因為會有人要去哪裡的問題。不可否認的，這種制度比較不近人情，但為什麼創投或大發行商會採用，因為是真的比較有效的風險控管方式。
  

風險二
Pre-Production準備不足
可能造成的原因：

• 開案前的測試人員不是核心人員。
  

• Pre-Production時間不夠，甚至沒有。
  

• 核心成員沒有全部到位就開案。
  

• 開案後核心成員更換，新的成員、新的想法，造成專案方向調整或變更
  

• 核心玩法、世界觀與營收方式尚未完全被驗證可行，量產人力就到位，提前進入量產期，後期修改成本更大 (和前面提到的milestone規劃方式有關)
  

建議解法：

• 核心成員應該要在Pre-Production階段就到齊，並且避免頻繁進出的狀況。
  案子之間的銜接，通常不會剛好這麼順利，一個結束後另一個才開始，而是會有交疊的時間。因此有時候，核心成員會卡在其他還在運作的案子當中。
  若Pre-Production階段是由非核心成員執行的話，品質與嚴謹度是一個擔心，另外，當核心成員到位時，會不會有不同的想法也是一個隱憂。
  

• 確認核心成員對專案的認同感。
  若打從心裡不認同專案，能力再強也沒用，可設法溝通，但若無效應替換。
  

• 若有核心成員流動，應重新確認所有人對專案的想法與認知一致。
  每個人對遊戲有會有一套自己的理解，越是資深的成員，想法越多，因此凝聚專案成員的想法，並達到共識很重要。
  專案初期，至少核心成員的想法要達成一致。
  

• 綠燈會議應建置更多階段的審核流程，除了一開始的創意審核階段，也應該要另外增設目標與成本、核心驗證(Prototype)等審核階段。
  有些專案的提案過程，只有一個文件審核階段，文件過了就開案了，後面也缺乏稽核機制，這都是非常危險的事情。
  

• Prototype應該被定義在正式開案之前，而非在開案之後。
  再很多的專案規劃中，Prototype是屬於開案後的階段，Pre-Production只有處理設計文件與概念圖。但我覺得這是有問題的，因為Prototype做出來的結果，和對當初對文件的想像，可能是會有差異的。
  
  文件看起來很有趣，但Prototype做出來以後覺得不好玩怎麼辦？
  繼續做下去嗎？用後面的時間來調整？
  
  要知道，Prototype一旦決定後，80%的遊戲核心都被定型了，能改變的不多，除非翻案，那成本又更高了。更何況，後面的milestone原本是有其他事情要處理的，一旦決定用後面的時間處理，milestone就會被壓縮到。而且我們怎麼知道要調多久才能調好？如果核心有問題，不是調整可以解決的怎麼辦？
  
  因此我強烈建議，Prototype應該要被定義在開案之前，等到Prototype被驗證通過後，才加入大量人力，進入量產期。
  

• Prototype通過前，都應該只維持小團隊，避免因成本壓力而強制縮短Pre-Production時間，或即便發現Prototype有問題，也強制進入量產期的情況發生。
  資源不是無限的，控制成本，才可能會有更完整Pre-Production，在Prototype遇到嚴重問題時，也才有進行第二次Prototype的可能。
  

轉載自「北極熊的喃喃自語」