[心得] 遊戲軟體管理經驗談(5)-執行人力

[NDark (溺於黑暗)]

遊戲軟體管理經驗談

發佈區域：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)
推 jimmibear:很感謝這連串分享 看到這裡很有感觸 尤其是關於Agile
→ jimmibear:現在正在為下個案子開始前作準備 但是前一個案子中
→ jimmibear:Agile執行的不是很理想,所以我最近都在想要怎麼改進.
→ jimmibear:尤其是團隊較大(flashx3 phpx3 artxN designer在美國)
→ jimmibear:所造成的溝通困難的問題. 書上是說最好分成6人的scrum
→ jimmibear:team, 但是實現起來好像不是那個單純的一件事情...