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

（圖片來源：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 小時

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

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

（圖片來源：www.reqdb.com）

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

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

（圖片來源：http://www.areait.info/）

「專案管理」聽起來是一個很酷炫的 Buzz Word，如果用一句《神奇寶貝》裡的名言比喻，專案管理就像是個「可愛又迷人的反派角色」一樣，經常讓人對它又愛又恨。在之前的「經驗與管理的迷思」以及「Peopleware：腦力密集產業的人才管理之道」這兩篇文章裡，已經討論過「人」這項因素對於開發團隊的重要性。然而在一個企業、公司或團隊中，如果只注重人的因素仍然是不足夠的，因為即使是能力再強的領導者或管理者，也無法一天八小時盯住每一項工作的執行細節。如果說在管理學中常聽到的「領導統御」是著重於「人」的層面，則「流程管理」就是著重於「事」的層面。良好的管理制度，將能夠補足「人」所力有未逮之處。

專案管理，最初由時間管理 (Time Management) 的概念衍生而來，而時間管理的概念則存在於我們每一個人的生活當中；當你身為一個學生的時候，如何管理一天的生活？如何管理二個月的暑假生活？如何管理一整個學期的生活？如果只是放任著時間流去，最後或許會發現自己什麼事情也沒有完成，什麼東西也沒有留下。對於遊戲開發來說亦然如此，專案的功能清單與臭蟲列表上，總是存在著難以計數的項目等待進行；有多少事情需要完成？有多少人手可以用？六個月之內可以看到什麼樣的成果？專案管理，必須要能夠妥善地回答這些問題。

舉個實際的例子，假設你身為一位程式設計者，在夙夜匪懈、含辛茹苦地讀完 C++ 語言、視窗程式設計與 DirectX 繪圖 API 之後，終於能夠開始動手寫遊戲了！一開始，目標不要訂得太高，先從 2D 的小小遊戲開始好了。首先確立了遊戲的玩法與各項設計要素後，就可以準備開始寫程式了！但是在真正動手寫程式之前，總得先有個目標與方向，列出遊戲中各項必須具備的功能系統：

• 繪圖系統
• 音源系統
• 特效系統
• 角色系統
• 操控系統

嗯，看起來很不錯，已經把一個小遊戲所需完成的基本系統全部條列出來了。然而，這些項目的定義，對於工作的執行者來說，太過於模糊而簡略；例如其中的「角色系統」究竟指的是角色的動作系統，還是角色的屬性系統？角色有沒有包含怪物的相關功能？為了釐清這些問題，我們必須進一步地將這些系統大項，分解成為比較詳細的功能小項：

• 繪圖系統：
  • 2D 圖件功能
  • 背景圖件功能
• 音源系統：
  • 音效播放功能
  • 音樂播放功能
• 特效系統：
  • 圖片半透明效果
  • 淡入淡出效果
• 角色系統：
  • 角色動畫功能
  • 怪物 AI 功能
• 操控系統：
  • 鍵盤輸入功能
  • 滑鼠輸入功能

這種由上而下分解的階層架構 (Top-Down Hierarchy)，讓我們能夠將原來不知如何下手的「遊戲系統」這個龐然巨物，一層層分解為可對付的任務。如果目前的清單仍然過於模糊不清，也可以繼續往下分解，直到階層架構能夠清楚傳達每項工作的意義為止。經過階層分解所得的這份清單，也就是所謂的 To Do List（待辦項目清單），理論上我們只要把上面所列出來的項目通通完成，第一個自己製作的遊戲就大功告成了！

然而，除了工作項目以外，另一項不能忽略的程序，就是估算每個工作項目所需的執行時間：

• 繪圖系統：
  • 2D 圖件功能：16 小時
  • 背景圖件功能：12 小時
• 音源系統：
  • 音效播放功能：8 小時
  • 音樂播放功能：8 小時
• 特效系統：
  • 圖片半透明效果：12 小時
  • 淡入淡出效果：16 小時
• 角色系統：
  • 角色動畫功能：24 小時
  • 怪物 AI 功能：24 小時
• 操控系統：
  • 鍵盤輸入功能：8 小時
  • 滑鼠輸入功能：8 小時

在遊戲專案的計畫中，有了系統功能的細節項目，以及每個工作項目的執行時間之後，接下來就能夠排定各個工作項目的執行順序。排定工作的優先順序，需要取決於每個項目的關鍵性、重要性以及項目與項目之間的相依關係；以這個例子來說，特效系統中的半透明功能與淡入淡出功能，都需要等待繪圖系統完成後，才有辦法開始動手進行。

經過優先順序排列之後的工作項目列表，如下所示：

• 操控系統：
  • [1] 鍵盤輸入功能：8 小時
  • [2] 滑鼠輸入功能：8 小時
• 繪圖系統：
  • [3] 背景圖件功能：12 小時
  • [4] 2D 圖件功能：16 小時
• 角色系統：
  • [5] 角色動畫功能：24 小時
  • [6] 怪物 AI 功能：20 小時
• 音源系統：
  • [7] 音效播放功能：8 小時
  • [8] 音樂播放功能：8 小時
• 特效系統：
  • [9] 圖片半透明效果：12 小時
  • [10] 淡入淡出效果：16 小時

在此我會將操控系統列為製作遊戲的第一優先選擇，因為有了鍵盤與滑鼠的輸入功能，將會比較便於後續的開發與測試程序。接著要在畫面上顯示出東西，所以必須完成基本的背景圖件與 2D 圖件功能；有了圖件功能後，就能夠接著進行角色與怪物動畫的功能製作。完成以上主要的功能項目後，再繼續製作與其他系統比較沒有依存性的音效與音樂功能。為什麼把半透明和淡入淡出效果排在最後的順序？因為這兩項都不算是遊戲中的「必要」(Must-Have) 功能，而是「有也不賴」(Nice-to-Have) 的附加功能；雖然能夠使畫面更美觀，不過並不是非完成不可的功能。

以上，就是一個以程式設計者觀點出發的「遊戲專案時程」計畫程序。

在一個完整的開發團隊中，專案的時程安排與進度管理狀況往往比上述的例子複雜許多。一般來說，專案管理者會將每位工作者都視為一項可分配使用的資源 (Resource)，完成一項工作則需要 1 至多項不同的資源配合。而每個人與其他人之間，幾乎都會存在著某種程度的依存性 (Dependency)。例如，我所預計進行的這項工作，需要等待美術同仁的建模工作完成後才能夠開始；或者是程式的紙娃娃裝備功能，除了企畫的裝備部位設定資料以外，還需要先拿到美術的裝備模型與貼圖檔案，才有辦法進行實際測試。

工作項目與工作項目之間，存在依存關係，而工作者與工作者之間，同樣也存在著依存關係。程式設計者與程式設計者之間，需要彼此合作，因此難以避免地會有彼此間的依存關係存在，而對於企畫與美術設計者來說亦然如此。所以如果專案中的時程沒有安排妥當的話，將很有可能造成專案進度的延誤，或者是某些人做得要死，另外一些人卻閒置無事的糟糕情境。

正因為工作項目依存性的緣故，團隊中的專案時程，就像是一張錯綜複雜的蜘蛛網。專案管理者必須從中訂定出專案執行的關鍵要徑 (Critical Path)，確定哪一些項目才是最為關鍵的部分。如果以 RPG 的術語來比喻，關鍵要徑就像是遊戲中的主線任務；不論你的支線任務解了成千上百，如果不完成主線任務，故事劇情就無法推展下去，也就自然無法打倒最終魔王，並且看到美好的結局動畫與遊戲成品。

如果你現在只是一位單純的美術設計者、企畫設計者或者程式設計者，沒有身負管理職務的責任，或是對管理職務沒有半點興趣的人，可能會想問：「專案管理又與我有什麼關係？」其實專案管理的重要性，就如同每個人自身的時間管理一樣，正確的時間管理，可以讓一個人活得充實而滿足，而正確的專案管理，則能夠讓專案健康地成熟長大。不是因為學會專案管理，就可以當主管，然後可以管理一堆下屬員工。專案管理的出發點，在於幫助我們解決問題、達成目標，然後得以順利地完成專案。

身為業界中的小小工作者，我們或許偶爾都會抱怨：「為什麼總有開不完的會議、做不完的報告加上寫不完的文件？為什麼除了『做遊戲』之外，還需要做這麼多繁雜又無趣的事情？」如果能夠從專案管理的觀點來思考，就會清楚瞭解良好的管理制度可以幫助我們更加順利地執行專案，讓專案能夠早日完成並且順利上市，接著大紅大紫，最後賣到翻掉。專案管理能夠幫助團隊，迅速且有效地檢視目前的各項執行狀況、提供統計數據，並且找出潛在的問題；反之，如果在進度執行之後的數個星期、甚至數個月之後，才發現專案中的天大問題，此時縱使管理者突然腦袋開竅、大徹大悟，可能也早已造成難以挽回的慘烈局面了。

如果與其他產業相比，遊戲產業與傳統製造業或高科技製造業所需使用的管理方法，可以說是大相逕庭。我們可以訂立出非常嚴謹的 SOP（標準作業程序），每個人的每一項步驟都按照標準程序操作；然而即使從頭到尾每一項步驟都執行無誤，生產出了一件合格的商品，也無法保證最終所產出的成果，是一件「好玩」的遊戲成品。再者，即使這次花費了 18 個月、500 萬美金與 30 人團隊，成功了做出一套銷量百萬的遊戲大作，同樣無法保證能夠在相同的條件下，達成一樣的成功結果。

為什麼？

因為，「Creating fun can not be planned」；因為遊戲產業與其他產業不同之處，就在於「創造樂趣的時程難以管理」；也正是因為「樂趣無法規劃」的因素，所以遊戲產業不能夠與軟體產業劃上等號。這也是為什麼多數的遊戲專案，幾乎都會遭遇某種程度的進度落後與時程延遲的主要原因。所以如果身處上位的老闆與管理者，以為能夠複製別人成功的模式、複製自己過去成功的方法，或者是以製造業的思維來治理公司或者管理遊戲專案，都很有可能使得團隊陷入危險的處境中，專案的完成之日自然也遙遙無期。

（圖片來源：http://www.pigs-in-lipstick.co.uk/）

然而，做為遊戲的開發者以及員工的身份，我們無法對著老闆與發行商說：「因為樂趣無法規劃，所以專案進度勢必要向後延遲 N 個月！」在遊戲業中，只有這麼一間 id Software，能夠在發行商詢問遊戲何時完成時說出「It’s done when it’s done.」這樣豪邁爽快的話。也只有受萬人景仰膜拜的 Blizzard Entertainment（現已合併成為 Activision Blizzard），可以在公布遊戲影片的十數個月之後才正式釋出，同樣能夠賣破數百萬套以上的遊戲。所以，做為大大業界裡的小小公司、小小主管或者小小開發者，我們必須努力地找出時間、預算與品質三者之間的平衡點以及折損點。

有的老闆或者主管，喜歡三不五時在辦公室裡走來晃去地「巡視」員工的工作情形，我想這應該是大部分人都不願意使用的「專案管理」形式。以專案管理之名，不論是要以紙本的方式或者以電子檔案的方式指派任務，不論是要由工作者主動回報進度或者被動地由主管詢問進度，管理者都需要時常反省現行制度的真正用意為何，才不會使原來是一番美意的良好制度走了調，反而成為徒具形式的惱人雜務。如果各種文件、方法與手段，不能夠有效地幫助我們達成目標，產生出更好的成果，就毫無意義可言了。

專案管理到底在管些什麼，你是否已經有了答案？ ：P

在遊戲專案的開發過程中，除了排定工作項目之外，還有許許多多需要進行的流程：要由誰來估算工作時程？要怎麼估計某個工作項目需要花費多少時間？怎麼估算比較準確？如何驗證進度與成果？如何考評工作績效？下篇文章裡，將繼續探討與工作時程相關的主題。

一直到出了社會，經過幾年的工作歷練以後，我才深深地體會到以前在學校中大部分的課程作業與考試，往往太過於注重個人的程式能力，卻忽略了團隊合作的重要性。「一個人能夠將程式完成；一群人卻反而未必能將程式完成。」現今的大專院校設立了許許多多的資訊相關科系，但是對於有志朝向軟體相關產業發展的學生，卻很少有機會學習合作開發的相關知識，更缺乏與同學共同撰寫程式系統的實作經驗，實在是一件很令人惋惜的事情。

除了「《Top 10 Traits of a Rockstar Software Engineer》：明星程式設計師必備的十項特質」中所提到的十點必備特質以外，我認為對於程式設計者來說，最重要也最關鍵的特質就是溝通技巧與協調能力。「溝通」以及「協調」，聽起來是再尋常也不過的普通字眼，有什麼重要性？又有誰做不到呢？在現實世界中，不會每件事情都如課本中的理論般，達到準確無誤的理想狀態。如果能夠與同儕間達成良好的溝通與協調，撰寫程式也會變得容易許多；反之，如果無法達到雙方都能接受認可的滿意狀態，將會造成許苦痛、誤解，甚至對立的情勢。

無論是正式的會議或非正式的會談，溝通的程序，經常會佔去許多工作上的時間。在《人月神話：軟體專案管理之道》中提到，當專案中的成員數目往上增加時，彼此之間的溝通成本也會相對地提高，達到門檻上線之後，增加成員就幾乎無法對專案產生任何正面效益了。而除了與企畫設計者、美術設計者以及專案管理者的溝通以外，許多程式設計者經常忽略的層面，反而是與程式部門的內部溝通程序。

在遊戲專案的程式系統開發流程中，分工是必然為之的自然法則。在分工合作的開發模式下，通常會有一位主程式設計者 (Lead Programmer)，負責撰寫最關鍵的主系統功能，並且整合其他所撰寫的子系統功能。主程式設計者通常是由部門中最資深的程式設計者擔任，而部門內其他的程式設計者，則會分別負責使用者介面系統、人物系統、場景系統，以及特效系統等等不同項目的子系統。

由於遊戲專案中的程式碼檔案往往成千上百，同時也會隨著專案的進展而不斷演化成長。因此不可能等到程式設計者全然瞭解專案中所有的程式碼以後，才開始動手撰寫新的程式功能。在這樣的情境之下，缺乏部門內的溝通協調，就會造成糟糕的後果。舉一個常見的例子，假設在開發中的 MMO 遊戲專案裡，具備 5 種角色職業可供玩家選擇。對於負責開發角色系統的程式設計者來說，很自然地會利用列舉值定義的方式，撰寫出以下的程式碼：

// @ file Character.h
enum CharacterCareer
{
    Career_Warrior,
    Career_Rogue,
    Career_Priest,
    Career_Witch,
    Career_Paladin,
};

class Character
{
    // My super character class!
};

有了 CharacterCareer 列舉值的定義之後，就能夠在 Character 類別以及與角色系統相關的程式碼中使用 switch-case 敘述句，很便利地對不同的角色職業進行個別處理。

然而，專案中的另外一位程式設計者，負責撰寫使用者介面系統的功能項目，同樣也會需要對各種不同的角色職業進行個別處理。在缺乏內部溝通，同時也沒有檢視過人物系統程式碼的狀況下，很可能會寫出這樣的程式碼：

// @ file CharacterUI.h
enum CareerUI
{
    UI_Warrior,
    UI_Rogue,
    UI_Priest,
    UI_Witch,
    UI_Paladin,
};

class CharacterUI
{
    // This is CharacterUI!!!!!
};

一項是定義在 Character.h 中的 CharacterCareer 列舉值，另一項則是定義在 CharacterUI.h 中的 CareerUI 列舉值，其實兩者的用意完全相同。如此一來，遊戲專案就需要同時維護兩份功能作用相同、定義名稱略有不同的程式碼。如果又有第三位程式設計者，負責製作與公會或組隊相關的系統功能，可能又會出現第三種版本的角色職業列舉值。像這樣重複性的程式碼，非常容易導致系統維護上的陷阱與潛在的問題。

如果這兩位程式設計者，能夠在下手撰寫程式之前，多考慮一點其他的可能性，或者向部門內的同儕稍事詢問，就能夠將這種各子系統都需要使用的列舉值定義，獨立出來寫在一個表頭檔中，就能夠讓任何需要的系統自行取用，而不會再寫出重複多餘的程式碼。假設部門內的其他程式設計者，目前並沒有撰寫角色職業相關的列舉值，經過詢問之後，也能確保在他以後有需求時，會先想到你曾經寫過這部份的程式碼，因而降低了撰寫重複程式碼的可能性。

上述的案例，其實只是最旁枝末節、影響最微不足道的情節。在程式設計者的真實世界中，經常會遭遇更感人肺腑或者賺人熱淚的情景。例如，在人物系統中存在著一個名為 CSingleton 的類別，而在特效系統中又存在著另一個叫 Singleton 的類別，兩個類別的功能用途幾乎完全相同；或者是 70% 的功能相同，30% 的功能不同的類別或函式等等，多到不勝枚舉的狀況。在撰寫一項獨立的功能之前，只要事先詢問同儕是否有撰寫過功能相同或相似的程式碼，就能夠避免產生出重複的程式碼。正如「明星程式設計師必備的十項特質」中的項目所述：善用既存的程式碼；所謂的既存程式碼，理所當然也包含同儕所寫的程式碼！

另一方面，如果以子系統程式設計者的角度出發，由於最終的子系統成品都要交付給主程式設計者進行整合，所以子系統程式設計者應當要將主程式設計者視為客戶的角色，主動去瞭解使用層面的需求，才能夠讓整合與維護的程序更加順遂。在理想狀態中，主程式設計者應該不需要去探究子系統的實作細節，而只需閱讀類別介面與系統的設計文件，就能夠完善地使用這些已完成的子系統組件。

因此為了建立雙方都能夠認可的子系統溝通介面，在子系統與主系統程式設計者之間，可以使用 Design by Contract（依合約設計）的方式進行系統規劃與設計。所謂的 Design by Contract，就是如同契約般白紙黑字的設計模式；兩人事先約定好，只要你能夠給我 A、B 與 C 的參數值，我就可以保證輸出 X、Y 與 Z 的結果給你。以特效系統為例：

特效系統函式契約

函式用途：創建特效物件
函式名稱：CreateEffect

參數 1：std::string 型別，指定特效的檔案名稱。
參數 2：Vector3 型別，設定特效播放的座標。
參數 3：bool 型別，設定特效是否循環播放。
回傳值：Effect* 型別，創建的特效物件指標。

注意事項：特效物件使用完畢後，需要交回特效系統進行回收與毀滅的行為，不可自行使用 delete operator 刪除。

依照契約般的合作方式，不僅能夠使主程式設計者事先考慮子系統的 Use Case（使用案例），相對地也會使子系統程式設計者得到更明確的設計需求規格。主程式設計者不能總是做個善心人士，不論子系統程式設計者交出什麼長相的程式介面一律照單全收，導致原來只要 1 個函式就可以解決的功能程序，卻需要拐好幾個彎，多使用 3 個函式呼叫才能完成。所謂兵來將擋、水來土淹的作法，並不適合用於這樣的開發情境中。

溝通，並不僅止於以「語言」的形式進行。有時候，甚至存在著更微妙的溝通形式。

為了建立起程式部門內部的有效溝通管道，更有效的一項方法是採用 Code Review（程式碼檢閱）的程序。根據 Wikipedia 的定義，Code Review 是一種系統化的程式碼審閱方法，能夠用來早期發現且早期治療錯誤，增進整體的軟體品質以及開發者的技能。Code Review 有正式與非正式等許多不同的形式，簡單來說，就是將程式碼交由撰寫者以外的人進行檢閱與審核。一般的 Code Review 程序，經常是由資深的程式設計者檢視新手撰寫的程式碼，並且給予適當的指正與引導。這樣的方法，一來能夠協助新手更迅速地進入專案的狀態中，二來也能夠避免新手犯下無心之過，而對專案造成難以彌補的慘劇。

但是這樣一對一的 Code Review 程序，並不能夠完全發揮最佳的溝通作用。事實上，如果能夠訂立出週期性的 Code Review 程序，使程式部門中的所有人共同參與，不僅能夠集眾人的智慧找出程式碼中潛在的問題與臭蟲，同時也很有利於統一專案程式碼中的寫作風格與命名慣例。然而，在專案時程緊迫，每個人總有做不完的功能與除不完的蟲的情況下，Code Review 會花費許多額外的時間，目的只是為了檢視已經完成的程式碼，這樣做值得嗎？

撰寫程式碼的時間減少了，檢閱別人的程式碼以及溝通協調提問的時間增加了，反而能夠使程式系統更加穩固，有效降低後續除錯與維護所需的心力，因此實行 Code Review 實際上並不會延宕專案的時程。參與檢閱的程式設計者，能夠以很短的時間瞭解其他同儕撰寫的功能系統，而對於被檢閱者來說，也能夠學習到許多自己原來不熟悉的設計作法。當 Code Review 成為專案中每週例行的程序以後，每位程式設計者在平常撰寫程式碼時，只要想到這是必須給所有同儕檢閱的內容，也會更加地謹慎仔細思考。只要妥善地實行 Code Review 程序，將能夠在部門內形成一股良好的正向循環風氣，對團隊中的每位成員產生出正面的效益。

當然 Code Review 並不是萬無一失的銀子彈，管理者仍然需要視團隊狀況小心調整程序的實行細節；例如，需要注意會議時間不可過長、注意團隊中的討論氣氛，以及做出適當的裁定與指示等等，才不會反而招致負面的成效。關於 Code Review 的一些實際執行狀況與心得，可以參考黑暗執行緒中的「Darkthread’s Code Review Theory」這篇文章。

我並不是很願意承認這件事，但是我認為國內的遊戲業界，在「合作開發」這件事上，還有很長、很長，很長足的進步空間。在遊戲業界中，我見過許多個人能力很強、各有擅場的程式設計者，但其中有許多人總是習慣於單兵作戰，與他人合作共同撰寫程式時，卻反而綁手綁腳般地難以發揮實力。其實他們並不是沒有能力或者不願意與其他人合作，有時候只是缺乏了流程制度的推動與溝通管道的建立，以及一位恰如其份的居中協調者。如果身為程式部門主管的角色，請盡量少一點動手寫程式碼，多花一點心思建立部門內的橋樑，多花一點心力製造出無形的溝通形式吧！

回過頭來想，程式設計本來就是一種很需要個人獨處空間，以及高度專注力與集中力的工作。包括我自己在內，在思索臭蟲來源與架構設計問題時，經常都會像失了魂似地盯著螢幕想、吃東西時想、上廁所想、開會時也想，所以難免會減少了與同儕之間的溝通互動行為。因此，身為管理者的角色，要能夠把程式設計者從埋頭苦幹與獨群索居的自然習性中，稍微拉出來一點點，讓大家都能夠自願地、自然地探頭呼吸與說話，才能夠使團隊中的每位成員都可以在工作中獲得成長，同時也會使程式設計者對進行中的專案更具有認同感以及向心力。

我並不會妄想遊戲業界能夠一下子大刀闊斧地推行 Agile Development、Test-Driven Development 或 Pair Programming 等新穎的軟體工程方法，但是如果我們希望國內的遊戲業界朝向大成本、大市場、大製作與大團隊的開發模式邁進，當務之急就是必須捨棄以往業界中常見的「英雄開發模式」，一步步學習如何真正發揮 Teamwork 的本事，使開發者與開發者之間不再是單純的加減法效應，而是發揮出乘法般的正面效應與戰鬥能力！

身為程式設計者的妳或你，今後，也要愉快地 PvP 唷！ ：）

他們在好幾年、甚至超過十數年的資歷中，可能經歷過大大小小許多間的公司，也參與過很多完成與未完成的專案。從一開始可能誤打誤撞的進入了業界，一待就是八、九個年頭過去。一路走來，做為一個職員，表現一直都屬良好。於是在幾次的轉換公司或內部拔擢之中，他們理所當然地成了管理職務的候選者。機緣巧合下，他們得到上層的賞識與信任，終於晉升成為管理職，頭銜變好聽了，薪水增加了，公司也得到有能力的主管，從此大家都一帆風順、過著幸福快樂的日子。

然而事實真的是這樣嗎？

做為一個管理者所需承擔的責任，往往與單純的開發者大不相同。管理者要做的事情，不單僅是分派工作、回報上層而已；除了部門內部的工作管理、做出決策與監督之外，還要能與其他部門進行溝通協調，並且適時擔任上層與開發者間的橋樑角色。因此管理者每日的工作時間，常會被各種大大小小的會議佔據去許多時間，與人面對面交談的時間多過於使用電腦的時間，也需要定期製作報表或表格等行政管理方面的事務。

然而有些管理者會對於自己遠離開發實務這個事實感到忐忑不安而難以適應，所以對許多開發的細節事項總是極欲親力親為，沒有辦法下放部分權責，最終的結果可能就是過於專注細節層面而見樹不見林，忽略了其他更重要的管理面任務。以現實情況來看，糟糕的是在業界人手普遍不足的情況下，主管職通常還是需要自己跳下海來做開發實務面的工作；例如程式主管仍須負責一部份的功能開發與維護，企畫主管仍然需要進行設定數值的調整等等。這樣的情況下，管理者難以意識到自身角色的責任重心改變，同樣會造成擔綱職務上的不良適應。

遊戲業界一般採取比較扁平式的組織，沒有太多太複雜的管理階層，因此中階主管的角色（通常是部門主管），就顯得十分關鍵而且重要。被拔擢成為主管的職員，自然是從前做為一個開發者的角色時，有良好表現、貢獻與經驗的老手居多。但是如果他們從未學習過管理的相關知識，或未曾接觸過管理的實務流程，如何能期待他們晉升到管理者職位後，就能夠自然而然地開竅、自動自發地上手，成為一個稱職的主管呢？

於是這種情況下，很容易就會導致彼得原理的現象：

在一個層級制度中，每一個職員總傾向於晉升到他所不能勝任的職位。

第一眼看到這句論述，總覺得有點弔詭而難以理解。這是什麼意思呢？更進一步說明，彼得原理闡述的事實為：

在一個層級分明的組織中，在原有職位上工作表現良好的人會被升遷到更高一級的職位，直至到達他所不能勝任的職位。最終組織的每個職位都有被不能勝任的員工佔據的傾向。主因是組織時常以「升遷」做為獎勵員工的手段，但是卻未考慮員工是否已做好準備。因此，員工會因為表現良好，被升遷到他不能勝任的職位。

更糟的後果是，會導致更嚴重的彼得反轉與彼得瓶頸現象：

• 彼得反轉：在組織中員工能否勝任，往往是由上司來判定。如果上司已到達無法勝任的層級，很可能就會以制度的價值來評斷部屬，於是那些方法重於目標、缺乏獨立判斷能力、只會服從的員工，反而會被組織認為是能勝任的工作者，而有資格獲得晉升。
• 彼得瓶頸：組織因為被無法勝任的上司佔據了職位，阻礙了其他員工升遷的管道。

這是一個很諷刺卻也是很實在的論述。彼得原理的發生，可以預想到的結果就是職員流動率過高，難以留住較為資深並且對公司有所貢獻的人才。無可避免地，最終公司裡的管理階層全都被難以勝任的職員所佔據，造成公司組織整體的向下沈淪。

另外，也需要考慮到會有某部分的資深職員，本身沒有意願或明顯不適合擔任管理職。在這樣的情況下，要如何能夠留住資深職員的心，也是一個相當不可忽視的問題。以工程師的職務來舉例，實行晉升雙軌制能夠使資深的職員選擇往管理階層發展，或是往資深工程師階層發展。而管理者與資深工程師兩個角色之間的權重與責任如何分配，則又是另一個需要仔細思考的議題。

的確，豐富而深厚的經驗，可以幫助我們在遇到各種突發問題時，不至於慌亂了手腳，也能夠很快洞悉問題的根源。所以可以說是：沒有足夠的經驗與智慧，則難以勝任管理者的角色。然而同樣要謹記慎行的是：即使擁有深厚的經驗，也不能保證合適於擔任管理者的角色。

經驗與管理，存在著相對但並非絕對的關連性，若僅以年資經驗來決定管理者的人選，很容易就會使公司組織陷入彼得原理的困境。對於目前的遊戲業界來說，最需要重視的課題之一，就是管理者的培養與經驗的傳承。