[2011] 遊戲軟體管理經驗談(6)-執行期的規格變動

遊戲軟體管理經驗談

發佈區域：PTT GameDesign版（telnet://ptt.cc），部落閣Black Straits Historical（http://ndark.wordpress.com/）

版權所有，禁止轉錄

作者：NDark，目前任遊戲公司軟體工程師（專案主程式）
時間：2011 秋

執行期的規格變動

由於遊戲專案的特殊性，執行時期必然會發生規格變動的事件，也就是說很少有一開始決定之後就完全不改的企劃案。這算是遊戲軟體開發最難處理的問題之其二。規格變動的原因有很多，一開始想錯所以做一半要改，做一半發現技術做不出來所以要改，做完了發現不好玩所以要改，老闆不喜歡色調所以要改，做不完了所以要砍規格改，作太快還有很多時間就乾脆改一下，甚至做太久了也要跟著市場潮流改。連設計模式的聖經都告訴我們 “規格是不斷變動”，要認命。

就算是充滿熱忱的軟體人員，經過幾次的改來改去之後都會開始觀望，觀望等到不會變了才想開始做。反正改（做）不完，所以就慢慢做，也就是喪失了熱情，反正做快一點最後也會改。這種現象對團隊文化是種傷害，更不是一個專案管理者所樂見。但是就我觀察並非每個軟體人員一開始都這麼擺老，大部分都是環境改變了他們。

規格變動從結果來看有幾種

1. 完全不同，這幾乎是打掉重練，規劃人員要重新分析規劃，執行人員如果已經實做一半或是完成了，就會吶喊 “還我的青春來”。但是打掉重練多半會重新安排時程。
2. 由大變小，這種變動比較友善，如果原本的有認真規劃階段，多半可以用跳過的來省略。苦的是原本規劃的人員（花時間規劃結果變成白工，超幹），但是對執行人員來說算是鬆了一口氣。
3. 由少變多，原本規劃兩天實裝一刀劈下去的動畫不夠，現在還要有彩帶，火花，背景原本的太陽要變月亮，動畫結束又要變回太陽。這種變化最令人討厭，因為多半是漸漸發生，東接西湊的情形下原本有規劃的系統就會變的很不穩定，執行人員改完之後一定巴不得永遠不要再看到那些程式碼。超時工作後也許做的完。但是對軟體人員來說執行這樣的工作卻是扣分，也就是做完卻沒有得到成就感。

我們都能體認道規格變動的必要性，但是就我的經驗，管理階層卻常常刻意忽視規格變動會連帶影響時程變更這件事（也就是我要看到專案變成我要的樣子，卻不要看到時程會變長）。不管是打掉重練，由大變小，由少變多的哪一種。管理階層都會拿著一開始的時程表來逼著執行人員。這點就造成了團隊鬧翻的萬年理由： “時程不合理”。我們可以理解這種現象是由於時程改變（通常是變多）代表著預算要增加，而通常沒人願意去背那個增加預算的黑鍋。因此只好壓榨底層的執行人員，或是先做看看祈禱有奇蹟會出現，真的不行了才翻出底牌。

但是就我的經驗，當路途的前方發現一個坑，而團隊卻忽視這個風險，掉下坑的可能性幾乎是百分之百。臨時拉來幾匹馬想要加速衝過去的下場都會很慘。最慘的不是真的掉下坑，而是團隊失去了對於呼救的反應能力。對那位真知灼見的先知的忽視可能才是對團隊的嚴重傷害。也就是真正傷害的是團隊內的信任。

當時程不合理的時候，解決方式其實顯而易見：增加時間，減少規格，加人。其實優劣也正如這個順序。但是不容我說，大部分人都不敢壯士斷腕，而寧願用煮青蛙，挖東牆補西牆的作法。而通常這些補出來的東西即便能讓團隊衝過坑，也都會在不久之後碎裂崩壞。

這就跟玩撲克牌大老二很像，有好牌的時候要勇敢打出去來主導牌局，而不是等到快輸了才在想辦法把順子拆成單支。也就是不要被時程逼著逃，而應該反過來勇敢決定一個合理的時程。

執行期的規格變動大概會有這樣的循環：

1. 不知道什麼原因，發現規格要改。
2. 討論規格，要怎麼改。
3. 分析規劃新的時程，若不能被團隊所接受，回到２。
4. 插入或置換原本的時程，確定要改了。
5. 修改規格書（企劃）。
6. 執行（美術，程式，企劃）。

就我的經驗沒有完成這整個循環的規格變動一定會導致災難般的結局。

譬如說只有１與６：一個有力人士跑來，就叫美術把木牌換成石柱。這種例子多半明天石柱就會換成石敢當。

譬如說缺少５：規格書沒有跟著改動，有一天就會有一個天兵再把改過的東西改回舊的規格書。或是測試後一堆錯誤才發現測試規格書是依照舊版企劃規格製作的。甚至最慘的，時間一久原先的規格書就變無用的檔案，最新的規格都只存在大家的腦海中，團隊再也看不到同一個目標。

譬如說缺少３與４：馬上改，原本的時程就被壓縮。或是快到里程碑的時候才發現當初改規格的時候忘記（有意識，無意識，或根本就刻意忽視）把時間加上去，所以當然做不完，當然只好加班。時程不合理，bad end。

其實這整個循環完全跑完鐵定花不少時間，但這也有好處－讓規格要改的決定更加審慎。

順帶一提，我認為這裡面最重要的步驟是４，也就是插入新規格的時間點。當然規格變動大多時候其實派人很快去的改一下是在簡單也不過。可能不超過一個小時就能改完。但是一定數量的 “一個小時”的修正及驗證累積起來造成的時間絕對最終會變為不可忽視。如果原本的時程就已經安排的滿滿，這時候插入的工作必然造成原本的時程延遲。

我個人衷心地認為比較理想的時間點是里程碑後。因為若是插入的時間在里程碑之前，雖然改變的規格可以及早看到，但是多半都是會壓縮到時程的。若是能將改變的規格壓在里程碑之後（也就是下一個版本），對目前的執行人員來說就可以不用多分心，還是持續衝刺好好完成現在在做的工作。下一個版本再以新的規格重新出發，對執行人員來說的傷害會比較小。

我要拿距今兩千五百年前軟體管理祖師爺的智慧嚴正地忠告各位晉升管理的朋友們：

團隊信任最重要，人員去留次之，產品成果擺最後。