遊戲開發入門:專案時程怎麼估?

gantt-chart在專案管理領域中,所謂的時程,也就是一般常聽到的 Schedule 一詞。當上司、主管或者指導教授交付給你一項工作時,需要知道這項任務的預估完成時間。我們身為遊戲開發者以及工作執行者的身份,應該要使用什麼方法來預估工作的時程?如何達到預估的準確性?工作時程中又隱含著些什麼樣的秘密呢?

經過前篇文章「遊戲開發入門:專案管理管什麼?」的介紹之後,相信即使是從未接觸過專案管理領域的讀者,也能夠對於專案管理的基本概念有一些基礎的概念與認識。接下來,本篇將深入時程的層面,探討在專案管理中相當重要的專案時程估算議題。

(圖片來源:www.codinghorror.com)

任何一項工作的時程安排,都需要具備三項條件:起始日期結束日期以及與其他工作的依存關係。在專案管理領域以及專案時程表中,最受到廣泛使用的甘特圖 (Gantt Chart),可以用清楚易懂的圖示來描述工作項目的這三項條件。而另外一項在專案時程中會經常聽到的術語是 Work Breakdown Structure(工作分解結構),或經常簡稱為 WBS。簡單來說,WBS 近似於前篇文章裡所提到的「工作項目階層分解程序」,能夠將原來非常龐大的功能項目,逐步往下分解為可處理的單一工作項目。

在遊戲開發流程中,為什麼我們需要制訂出專案時程表

首先假設一下:如果今天你幸運地獨得大樂透頭彩,很豪邁地決定撥個幾千萬出來,投資製作一款自己夢寐以求的遊戲大作。於是你找來了擁有數十年業界經驗的資深遊戲製作人以及超強的研發團隊,準備開設一間全新的遊戲公司。然後,遊戲製作人拿出一份超棒的企畫設計文件,告訴你說:「只要給我二年時間加上四千萬資金,我一定能夠做出擊敗《楓之谷》、超越《魔獸世界》的遊戲作品!」

請問,你會不會相信他?你能不能夠安心地把自己的金錢與時間交付給他?

一款遊戲作品,從無到有的開發製作,少則需要花費 12 個月,多則需要 24 個月,甚至是 36 個月以上的時間。相對於企畫層面的設計文件,專案時程表就像是執行層面的計畫,可以用來告訴出錢的投資者無須擔心;例如說我們預計在三個月內完成遊戲雛形製作、六個月完成遊戲功能、九個月完成測試與調校,接著第十個月就可以上市,然後就開始蹺腳收錢!所以我們需要時程表,告訴自己目前的工作進度狀況如何,告訴團隊成員我們正在邁向偉大的航道,告訴投資者他們的錢沒有白花!當然所有的這些良好意圖,都必須建立在計畫時程估算準確的前提條件之下,才能夠發揮時程表計畫的原意。

How does a project get to be a year late?…… One day at a time.

如果你已經在遊戲業界裡打滾,經歷過了幾個專案的工作經驗,可能會想說:「誰家的專案不 Delay?」或者說:「所謂的專案時程,本來就是拿來 Delay 用的啊!」除去政治因素的考量,我想我們必須從專業的知識理論中學習,試著減少專案的延遲情形才是正確的態度。就像《人月神話:軟體專案管理之道》書中所提到:「為什麼專案會落後一年?……因為每次落後一天。」當工作進度只延遲一天的時候,看起來並不嚴重,但也就是這樣一次一點點的延遲,最終就會導致專案產品數個月,甚至長達數年的延遲。

今天上頭指派了一件任務給你,以工作執行者的觀點來看,對於交付的任務我們可以說:「完成 X 項目概略需要花費 Y 工作時間。」但如果工作項目的時程,是由管理者而非實際的執行者進行預估與安排,很容易就會變成「在 X 時間內必須完成 Y 項目」的過度強勢壓力或者過度樂觀想法。試問如果不是真正執行工作的人,如何能夠準確預估工作項目所需的時間?當然,時程估算並不是放任執行者開心地隨意自訂時程,所以管理者本身需要具備一定的專業知識能力,才能夠對各執行者交付的時程預估做出合理的判斷。

帕金森定律 (Parkinson’s Law):無論配置多少工作時間,該工作都會把配置的時間耗光。

如果帕金森定律是真實成立的理論,那麼管理者只需要盡可能壓縮每項工作的分配時程,就能夠獲得越來越好的生產力與工作效率;但很顯然地,事實並非如此。在《Peopleware:腦力密集產業的人才管理之道》書中,對於這項著名的帕金森定律進行反駁;由研究機構調查的統計數據顯示,將工作交由程式設計師進行預估所得到的生產力,反而遠大於交由監督者進行預估所得到的生產力。除非管理者對每個工作者的能力、經驗與心理狀態瞭若指掌,否則在大部分的情況下,還是只有執行者能夠最準確地估算出工作項目的執行時程。正如此書最後所提,應該將帕金森定律修改為「組織裏沒有效益的白工,傾向於會把工作時間耗光」才是真實而令人戒慎恐懼的理論。

「無論如何,我就是要在一個星期後,看到這項功能完成!」如果管理者只是一意孤行地想在有限的時程內塞入不合理的工作項目,不管是加班爆肝還是燃燒小宇宙,只是逼迫執行者自己想辦法解決,反而經常會造成難以收拾的後果。正所謂「上有政策,下有對策」,對於無理的時程安排,如果積極的抗議與建言無效,執行者的消極應對方法最後通常都會演變為「犧牲品質以拯救時程」的結論。「反正只要交出結果就好,不是嗎?」像這樣只重視結果而忽略過程的遊戲開發流程,往往會在專案後期遭受到嚴重的災難反噬。

至此,假設你已經說服老闆或管理者,可以把工作時程的生殺大權掌握在自己手上,那麼又應該要注意哪些工作時程估算的細節?

錯誤的工作時程預估,往往是使得整個專案不斷往後延遲的罪因之一。為了達到比較良好的預估準確度,首先必須要將工作任務進一步分解至合理的規模大小。一般情況下,主管只會就系統面或功能面進行任務指派,例如「製作武器的拖曳軌跡特效」工作項目。而如何妥善地分解工作項目,就是屬於執行者的職責;在分解完成之後,單一一項任務的執行時間不應該多過於 24 小時,也不應該少於 4 小時。如果你無法妥善地分解功能項目,表示你對工作任務的內容並不完全瞭解,很可能是你不熟悉的領域或者具有困難度的任務,請先尋求主管或同事的建議與協助後再行預估。

工作項目:武器的拖曳軌跡特效

  • 特效系統架構設計:8 小時
  • 特效系統實做:24 小時
  • 拖曳軌跡 Shader 製作:12 小時

工作總時數:44 小時

如果工作者被分派到的是完全沒接觸過或者不太熟悉的工作項目,例如研究一項全新的 Shader 技術、Scripting 語言,以及美術製作的新工法等等,往往需要花費一段比較長期而且連續的時間,最好是一次以三到五天為一個單位,由管理者設定研究探索的目標與停損點,在一段工作的期間完畢之後,檢視目前的成果,然後再決定是否繼續投注人力研究這些知識與技術。

除了遊戲功能面的一般任務以外,時程表中還有一些易於被忽略的隱形項目,包括文件撰寫功能測試以及除錯工作在內。關於文件撰寫,事情是這樣的:「你沒有安排時間的項目,就不會自動自發地被執行與完成。」非常合理,但許多管理者總是傾向於當個樂觀主義者,相信所有人都能夠迫不及待地完成那些額外的工作。比較好的執行方式,應該是將撰寫文件的工作也列入正式的工作項目時程之中。

而另外一個時程預估入門者常犯的錯誤,就是沒有將功能測試程序以及後續除錯工作所需花費的時間排入時程之中,結果自顧自地完成了指派的功能項目,卻沒有安排充分的時間以進行測試。即使已經預先排定了測試的時程,在專案時間吃緊的狀況下,測試程序往往也是第一個被犧牲的項目。與撰寫文件相同,最好在工作項目之中將測試程序明確地安排進去,而不是把測試這件事,理所當然地視為功能設計或者功能實做任務中的一部份。

時程安排的另一項重要議題,在於如何驗證工作成果。當工作者完成了工作項目並且遞交成果之後,應當如何驗證成果的正確性?缺少驗證機制的時程安排,也就等同於忽略了非常關鍵的測試與除錯程序工作時間。以傳統程式設計的領域來說,在完成一段程式碼或系統功能之後,必須進行功能面的單元測試 (Unit Testing) 程序,以確保即使遭遇各種邊界條件或者異常資料,也不會對程式系統造成損害。如果專案採用測試驅動開發 (Test-Driven Development) 的方法,一開始就先由測試套件著手進行開發,應該就能夠達到更加良好的驗證效果。

此外,時程表還具備另一項比較隱性的功能作用,就是拿來做為個人績效考核的參考材料。在交付日期之前提早完成,能夠獲得比較好的績效考核;如果發生工作進度的延遲情形,就會減損考績的表現。然而,像這樣非黑即白,不是加分就是扣分的時程考核制度,久而久之就會使工作者在預估工作時程的時候,隱匿性地預留緩衝時間,以避免自己的進度落後因而影響工作獎金或分紅的情形。到最後,這樣的方式反而會衍生出時程上的隱形陷阱,使整個專案都遭受到進度延遲的負面效應。

如果你是業界的工作者,或許會對以下的這個例子感到有些熟悉:「我能夠在 24 小時左右完成這項功能,但是萬一發生某些狀況,或許會花費多至 36 小時的工作時間。」很多時候,由於熟悉度或者困難度的緣故,我們可能無法明確地估算工作的完成時間。為了解決這個模糊的估算問題,在國外的討論區,我看到有人提出一個有趣的想法,不再只是使用單一估計值,而是使用了雙估計值加上雙信心指數的時程預估方法。舉例來說:

工作項目:武器的拖曳軌跡特效

  • 70% 信心指數:24 小時
  • 30% 信心指數:36 小時

工作時程期望值:24 * 70% + 36 * 30% = 27.6 小時

與傳統非黑即白的單點預估值不同,雙估計值方法具有合理的誤差範圍值,使我們能夠使用比較精準的數字,來代替原先模糊不清的「應該」、「或許」與「萬一」用詞。其中的信心指數,可以先由管理者制訂出固定的比例,然後再由執行者預估在這兩個信心指數下完成工作的時間。如果所有的工作者都使用這個方法預估工作的時程,遊戲專案的製作人,就能夠根據這些資料,計算出在最好的狀況下、最差的狀況下,以及平均期望值下的專案時程進度

project-schedule在專案管理的理想世界中,只要妥善地安排好所有的 WBS 項目,制訂出完美的時程表,每個人就能夠按照著圖表中的時程計畫,分毫不差地進行且完成各項工作。但是在現實世界中,往往沒有這麼美麗可人的專案時程。並不是在專案正式開始之前,預先分解完所有的細節項目,讓所有的人完全按照時程表工作,就保證可以製作出優秀的遊戲成品。與遊戲企畫面的設計文件相同,專案時程表並不是死的東西;時程計畫需要具備適應變動的能力,才能夠隨著設計需求與實際執行成果的回饋,不斷地朝著正確的方向修改、演進以及成長。

(圖片來源:www.reqdb.com)

不論是漂亮的甘特圖或是詳細的 WBS 項目,目的都是為了幫助我們掌握專案的執行狀況,所以當時程表與專案的實際執行情況背離時,就毫無作用可言了。因此至少需要每週進行一次進度檢核,找出工作項目執行面的問題;如果團隊中的成員發生了進度延遲的情形,最重要的是幫助他解決問題,而不是一眛地指責批判或者施加壓力。當管理者謹守著自己預想中的時程表,而底下的工作執行者卻擁有自己的「私人時程表」,那麼最終導致專案延遲的後果也不是什麼令人訝異的事情了。

總而言之,遊戲開發並不像是在鐵軌上行駛的火車,能夠不偏不倚地沿著既定的規劃路線前進,而比較像是航行在海上的船艦;當我們訂立了終點目標與前進方向之後,仍然需要視海流、風向、氣候等等狀況,持續地調整揚帆的角度、划槳的力道與轉舵的方位,才能平安抵達預定中的目的地。你的時程進度表,是否真真切切地呈現出專案的執行現況?

6 Replies to “遊戲開發入門:專案時程怎麼估?”

  1. 我碰到的專案到後期幾乎都在除錯,debug和測試過程的時間真的是容易被忽略。

    另外一個是後天無法控制的出包:軟硬體故障

    像我曾經硬碟掛掉,整整兩個工作天沒辦法工作~

    幾乎所有專案的日期都要加上25%的專案保險時間才行。

    尤其debug還要把程式的功力計算進去。:D

  2. @阿涼:
    硬碟掛掉真的是超級無敵囧…… 裡面的資料有救回來嗎? XD

    以我的經驗來說,最好是在每項子系統功能完成之後,就先安排一段進行測試與除錯的時程,才能夠有效減少專案後期的整合測試除錯時間。如果只是一直趕進度而把測試除錯的工作向後推移累積,在專案末期才開始進行測試,經常會發生莫名其妙就是想不透、摸不著又解不開的臭蟲問題,因而需要加班、熬夜甚至是燃燒工作者的小宇宙。

    這樣可是會嚴重損害到程式設計者的肝指數吶。 XD

  3. 恩…重頭讀到現在,怎麼對於未來職場的情況愈來愈偏向陰暗面發展。

    嘖嘖,有點恐怖的感覺。

Leave a Reply