遊戲軟體管理經驗談 發佈區域：PTT GameDesign版（telnet://ptt.cc），部落閣Black Straits Historical （http://ndark.wordpress.com/） 版權所有，禁止轉錄 作者：NDark，目前任遊戲公司軟體工程師（專案主程式） 時間：2011 秋 執行期的人力安排 同樣的人力安排為何又要再講一次？ 原因是當專案開始進行之後，事情的發展可能不如預期順利。 有工作會延遲完成，有人力會閒置。 當有人力離開團隊或是當工作延遲，下一個工作又應該要開始時該怎麼辦？ 這就是先分派人力的一個盲點。 先分派人力的好處是可以估出比較完整的時程。但是缺點就是，工作不可能估的非常準確 。若執行的人員早已知道下一個工作什麼時候該開始，就會急著完成前一個工作來達到表 面上的 "on schedule"，甚至會草率完工（常聽到的藉口就是做完了但是還沒測）。如果 沒有驗證清楚就放過關，未來一定會付出代價回來修。反過來如果驗證非常清楚，就是不 讓他過關。下一個工作當然就鐵定延遲開始。難道要拿鞭子鞭笞工程師加班嗎？若真的非 常重要的工作項目，則必然其他人會來幫忙擦屁股。這樣耽誤到其他人的工作來完成這項 工作算是誰的credit？ 我們一開始就講了工作時程規劃是規劃未來，而未來就是說不準的。在專案的進行中都會 有莫名奇妙的工作冒出來。簡簡單單把電源供應器裝上開發機主機板，就是會有人把板子 燒掉，然後只好等新的料件來，工作就（莫名奇妙）遲了一天。 先分派人力還有另一個遊戲業常見的風險，遊戲業的規格變化的比其他產業頻繁得多 （［註］好吧，看來知名手機廠hTC已經追上遊戲產業了）。 除非很有定見的製作人或企劃，多半開發到一半，規格早就不知道飄到哪裡去。 當規格變化太快，先前的規劃就完全的失準，這時若拿著先前規劃的時程來要求開發團隊 準時完工，那就是明朝的劍斬清朝的官。 因此規格改變時，分析與規劃當然要適度的再執行，這時卻也造成時間的浪費（又規劃了 好幾次），也造成團隊內的不信任感（感覺需求不停在變，沒有做完的一天等等）。 ［註］ "高工時工程師（HTC工程師）" http://www.mobile01.com/topicdetail.php?f=566&t=2370096&last=30927800 相對於先分派（告知團隊，所有工作的執行人是誰），我嘗試的是另一種動態分配，規劃 期作出來的工作項目與人力分派只是為了估計時程，真正執行期誰來執行並不十分明確， 等到前一項（依存的）工作項目即將完成，下一項即將開始時，才真正指派人力。這種做 法看似很不科學，對於整體時程很不精確。但是就我的經驗，工作人員在沒有下一個工作 追趕的情形下，才會真正的把自己該做的工作做好，管理人員也才能夠狠下心來打槍那些 半成品，也就是勇敢的把不成熟的工程師與程式碼留在原地； 反過來講，工作項目都能 "及時"的被 "空閑"人力展開。 這個管理方式的一個明顯的缺點就是而那些工作能力強的軟體人員， 就會接比較多工作（但絕不是用超時工作），也當然顯而易見的那些做比較多工作項目的 人員是比較有產出的人員。 這樣動態的管理方式是需要團隊的技術力盡量接近，可以臨時調配互相支援； 強迫開發人員寫註解，強迫開發人員互相溝通，減少搭配合作上的困難； 以及開發中不會有太過份難以理解的程式碼，技術力不可過分集中， 避免支援人員完全無法接手的情形發生。 -- "May the Balance be with U"(願平衡與你同在) 視窗介面遊戲設計教學，討論，分享。歡迎來信。 視窗程式設計（Windows CLR Form）遊戲架構設計（Game Application Framework） 遊戲工具設計（Game App. Tool Design ） 電腦圖學架構及研究（Computer Graphics） --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.160.139.160 ※ 編輯: NDark 來自: 118.160.139.160 (10/28 21:31) ※ 編輯: NDark 來自: 118.160.139.160 (10/28 21:33) ※ 編輯: NDark 來自: 118.160.139.160 (10/28 21:36)