建立“防洪系統” ！ 製作人分享做好專案前期管理的10條經驗

去年，在我曾經居住過的澳大利亞布里斯班，發生了30多年來最嚴重的洪災。然而過去的幾個世紀裡，這座城市經歷了好幾次這樣的洪水。

每次洪水過後，委員會都會研究討論未來減輕洪災的方法。然而大多數建議都被忽視了，重建工作依舊在洪泛平原上展開。這種現象存在於世界各地的種種事件中——無論是洪水、火災還是暴亂。我們成立委員會，提出建議，然後擱置它們、遺忘它們直到事件再次發生。

同樣的情況發生在電子遊戲製作領域。我們經常花時間寫反思——但人們真的聽取這些教訓了嗎？功能蔓延、高強度加班、士氣低落、缺乏重心和方向、團隊內部或開發者與發行商之間的溝通問題、缺乏技術和管理方法，看到這些老問題不斷重現令人沮喪。

從整個行業的角度來看，我們往往沒能把習得的經驗應用到實踐中。

過去十多年來，我們聽過許多人談論敏捷開發以及必須擁抱變化，這些都很有道理。然而，即便我們採用敏捷開發，相似的問題還是會發生，甚至在某些情況下加劇了。

本文旨在討論如何在專案初期最大程度減輕這些問題，主要是通過打牢基礎和提前計劃實現的。換句話說，即便天氣難以預料，修建堤壩和避免在洪泛區上開展重建工作總比坐等下一次洪水來襲明智得多。

1. 確保先前專案的經驗得到運用

不是所有團隊都會在專案結束後寫反思，他們要麼對此漠不關心，要麼認為這毫無意義。然而，如果我們想從錯誤中學習，我們必須對所有專案進行事後分析，尤其是那些被取消的專案。

這個過程必須是公正合理的，既要建立在平等友好的基礎上，同時必須不留餘地、全面深刻地反思什麼是對的、什麼是錯的以及今後如何改進。

相關人員撰寫完反思並一致同意通過後，應該把它提供給工作室的全體成員——最好放在公司內部網站上，確保成員們能夠輕鬆找到並查閱它，而不需要在成堆的郵件和摺疊資料夾中搜尋。

開始新專案時，確保反思中的相關經驗有運用到實踐中並定期檢查，以避免人們遺忘這些建議，從而導致同樣的問題再次發生。


2. 儘早開始準備專案，從小做起

公司財務狀況最大的影響因素之一是開發團隊規模的管理（成員數量的峰值和谷值），特別是在新舊專案過渡時。通常情況，當前專案結束後，下一個專案似乎才剛剛起步，這導致了許多成員無所事事，因為專案設計者才剛剛開始構建遊戲的基礎和總體願景。

更好的做法是提前規劃，如果可能的話，在當前專案進行過程中規劃下一款遊戲，挑選出一個骨幹團隊（成員數量大概是最終團隊數量的10%）進行這件事。

我個人建議該骨幹團隊的成員組成如下：一名負責規劃願景、研究和設計遊戲的全職總設計師；一名負責制定時間表、預算、專案範圍、聯絡客戶的製作人；以及一名為遊戲最初概念提供視覺化參考的概念設計師。當然，他們需要定期聯絡未來將加入團隊的核心員工——例如主程式設計師和美術主管。

此外，最好通過PPT演講等形式，向這些未來成員及時介紹新專案的進展。如果成員們一直被矇在鼓裡，他們會對新專案產生憎惡和疏離感。如果人們突然得知自己將被派去做一個進行到中期的專案，他們可能會感覺自己更像一個臨時的資源，而不是一名有價值的團隊成員。

在團隊成員聚在一起為遊戲建模之前，應該先做好大量的基礎工作。注意——這並不會阻礙概念階段或之後的迭代、靈活性或創造性。這麼做主要是為了讓團隊有個方向，使他們明白應該把重點放在哪裡，從而避免人們在黑暗中摸索尋找創意，浪費了寶貴的研究和思考的時間。在這個階段應避免使用大量遊戲開發檔案，以免加重他們的負擔。

3. 讓關鍵人物儘早加入團隊

讓首席設計師和製作人儘早開始新專案的一個問題在於，他們很有可能還在進行手頭專案的中後期製作。對此我的建議是讓一些首席設計師和製作人投入研發，剩下一些作為幫襯——意味著總有一名首席設計師和製作人沒有完全投入研發（處於待命的狀態），即便你們的工作室只有一個專案。這樣做會產生額外的開銷，但這是划算的，因為它帶來的回報遠遠大於風險。

如果為了節省經費而導致人手不足，特別是在前面領頭的人，後果將會很嚴重。如果你無法在一開始確定某人的能力，後期換掉他們將產生更大的費用，因為他們的工作很可能要被推倒重做。

確保你對這些關鍵人物有充分的信心。如果你發現團隊存在明顯的技能短板，必要時通過招聘或員工培訓補充缺失的崗位。

4. 與客戶建立良好關係

無論是公司內部的利益相關者還是外部客戶，例如發行商和IP授權方，這些製作團隊的領導者應進行面對面交流確保雙方理解專案的工作簡報（brief），在方向上達成一致，並建立良好的工作關係。

雖然這似乎顯而易見，但許多時候人們沒能儘早著手去做這件事，甚至忽略了它。我們為遊戲開發過程設立了許多里程碑——Alpha、Beta，並且清楚理解它們的定義，然而這件事沒有被納入到任何早期的里程碑中。我們彷彿假定它將會發生。

許多問題產生的根源都可以追溯到合作公司之間糟糕的關係、最初的誤解以及模糊的方向。

我強烈建議人們進行這些早期的面對面交談。據我所知，有一家工作室由於差旅預算方面的限制，無法允許製作人員飛去見授權方，但雙方面談有助於減輕這些預算高達數百萬美元的專案的工作負擔，它帶來的好處足以抵消這幾千美元的成本。

相比於僅僅通過郵件和電話會議和對方打交道，如果你能和他們面對面交流——哪怕只有一次——這將對合作產生巨大的影響，因為你能更好地瞭解對方，他們的習慣和行為邏輯。

應該讓100%參與專案的關鍵人員（尤其是製作人）與利益相關者見面，而不僅僅是工作室的高層。這將促進雙方建立直接聯絡，從而實現更高效的溝通。

5. 明確分工

對於任何團隊來說，各個成員們瞭解自己的責任以及如何融入團隊是很重要的。不要把這想得理所當然，如果團隊成員的角色是模糊的，人們不清楚公司對他們的期望是什麼，也不知道團隊結構是怎樣運作的。許多事情會因此被忽略，某些崗位的責任會被稀釋，甚至引發人們對崗位的爭奪。因此必須明確誰負責方向指導，誰負責審查，等等。

在專案交替、不可避免地出現崗位變動時，最好與團隊成員共同商議。如果出現了崗位空缺，開放這些崗位，讓所有人都可以來應聘。

我強烈推薦採用全方位評估，讓人們評價他們的同事和上下級。這是一種全面瞭解團隊成員能力和團隊管理的方式，並且有利於自我改進。

明確團隊結構並不會降低主動性和靈活性。就像在足球隊裡，球員們需要清楚自己的角色和隨之而來的期望。他們是負責得分的前鋒，還是負責創造機會的中場？

當然，崗位說明無法涵蓋所有工作責任，人們常常會突破崗位職責的限制——中場球員照樣可以得分——但讓人們自由選擇承擔職責會引發很多不必要的問題。

對於團隊以外的利益相關者——管理高層、發行商、授權方等，這一點尤為重要。參與審批的人太多是一件危險的事，這會導致簽字確認/處理矛盾反饋的責任人不明確。因此，應該一開始就確定分工，反饋流程以及週轉時間。

6. 制定並堅持實施一個長期計劃

專案剛啟動時存在許多未知數，但制定一個長期計劃是必要的。在專案初期，長期計劃包含了許多關鍵日期——例如專案正式啟動日期，什麼時候進入前期開發，什麼時候開始製作，Alpha版製作，Beta版製作，什麼時候提交專案。

在這個階段，必須制定預算、時間表和遊戲專案的工作簡報。遊戲概念確立後，我們可以進一步估算其它事物。如果日期發生變動——計劃也隨之而變。

注意，長期計劃不只是為了取悅利益相關者而匆匆制定出來的一個概況，直到專案嚴重滯後時才被重新審視。保持敏捷開發的同時遵循並實時更新長期計劃，這對於保持功能相關性來說尤為重要，因為如果我們僅以不同階段審視產品功能，可能會遺漏關鍵方面。

7. 明確里程碑的含義

與所有利益相關者正式確定各個里程碑含義——特別是早期里程碑，例如檔案歸檔、結束前期開發、建模、垂直切片。在遊戲設計完成前進行這些可能有些奇怪。但如果你們清楚瞭解產品的工作簡報、預算、所需時間和整體遊戲概念，你們完全可以進行更高層次的定義。

舉個例子，如果遊戲從設計到完成的時間為18個月，那麼你們可能有5個月進行前期開發。但5個月後交付到客戶手上的具體是什麼呢？是100頁的設計文件？是證明遊戲玩法很有趣的灰盒測試結果，加上一個展示藝術風格的demo？還是一個可試玩的demo，作為遊戲（畫面和音效）最終打磨完成後的效果參考？

這裡我要特別指出一個誤區：許多團隊會花上數月製作一個精緻的demo，佔用製作時間，導致進度嚴重滯後。客戶那邊往往會給大量修改意見，導致團隊深陷修改demo的泥潭。

因此，最好在前期製作開始前，與客戶就各個階段交付成果的質量、時間、預算達成一致，從而樹立合理的期望並提供遠見。

8. 鼓勵合作和替代方案

一般來說，最好不要一股腦地投入到第一個想法中，全然不考慮其它替代方案。它或許是個好主意，但可能存在更好的想法，並且在不權衡其它可能性的情況下，一個想法的缺點可能會被暫時掩蓋，直到最終凸顯出來——到時遊戲早已進入製作階段，改變基本原則為時已晚。

設計之初，允許任何團隊成員和利益相關者貢獻自己的想法，但具體的責任和決定權仍然在首席設計師手中，首席設計師應該對這些想法進行篩選。

這個過程將大大提高團隊的認可度和參與度。從人際關係策略的角度來看，讓利益相關者加入其中是明智的——特別是客戶(無論是發行商還是授權方)——因為如果他們參與到這個過程中，他們將更可能同意某個方案。

有時客戶可能選擇不參與這一層面的工作，但我建議向他們提供一些有限的方案選擇，而不是單個關於遊戲方向的想法。這是為了避免客戶一開始就不太喜歡遊戲方向，因而變得冷漠。如果他們在日後製作過程中要求對遊戲做重大更改，這可能會導致很多問題。因此，你要確保他們參與其中，興奮不已並且全身心投入。

9. 尊重並遵守期限

想象你在參加一場1個小時的考試，一共有6道題，每道題的分數佔總成績的六分之一。你不可能把前30分鐘全花在解答第一道題上。然而，在遊戲開發過程中，有時我們花了很長時間進行前期製作，不停地延後期限。有時我們覺得自己後期可以趕上進度，或者由於交付日期離我們還很遠，我們絲毫不考慮滯後帶來的財務影響。

這一點對那些和電影同期發行的遊戲來說尤為重要。如果為了打磨某個關卡不斷延後前期製作，則團隊很可能要趕工完成剩下的關卡，導致遊戲質量大打折扣。

延長時間不一定能提高質量。我們都聽說過一些耗費了大量時間的遊戲專案——主要是由於製作延誤導致的——最終卻一敗塗地，因為別的遊戲從創意和技術方面超越了它們。遊戲開發一再出現延誤，伴隨人員流動率上升，這會導致團隊士氣大減和遊戲質量嚴重滑坡。

因此，雖然我們不可能每次都在規定期限內完成任務，我們必須盡最大努力。除了提前做好計劃外，另一種方式是確保團隊成員清楚瞭解期限。過去，我曾經將把截止日期張貼在牆上，並在團隊的wiki上釋出里程碑資訊，因此每個人都清楚什麼時候該製作Alpha版，等等。這讓成員們更好地認識到時間的寶貴。

10. 保持果斷

我發現優柔寡斷是另一個影響開發進度的因素，甚至是在前期製作開始時。雖然前期製作主要從研究、思考創意和替代方案開始，但時間還是照常流逝，遊戲開發必須取得進展。這意味著我們必須及時做出關鍵決策。有時讓人們聚在一起做一個相對簡單的決策就像趕一群貓一樣難以控制。決策可能被擱置、移交然後被遺忘。

然而，在沒有充分理由的前提下推遲決策，可能比做一個壞的決策更糟糕。這不是鼓勵人們草率地決策，而是在審視了所有替代方案並權衡利弊後，及時決定並繼續前進。

不斷改變決策同樣是一種優柔寡斷的表現，這會損耗員工士氣並浪費時間。保持靈活性很重要，但若決策結果一再變動，則適得其反。更好的方法是把一些重大的、高層次的事情定下來，作為日後決策的基石。這樣隨著遊戲開發進行，我們可以對那些尚未成型的事物進行調整同時不改變基本原則，除非我們有令人信服的理由這麼做並且審視了它對進度造成的影響。

總結

上面的內容也許看起來很理想化，對某些專案來說確實如此。然而，基於我的個人經驗，我相信如果我們在專案啟動時，有意識地追求更好的開發理念，這將幫助我們及時完成遊戲製作、把成本控制在預算內，併產出高質量的遊戲。我見證並參與制作了一些專案——甚至考慮了工作室控制範圍之外的情況——通過這些專案發現，我們本可以通過一些早期的簡單決策大大減少日後的痛苦。

因此無論人們採取何種方式製作專案，我都會鼓勵他們在保持靈活性的同時採取一定的穩定性措施，在迭代的基礎上做好長期規劃。遊戲製作人可以採取適當的策略提高穩定性並做好長期規劃——但若得不到利益相關者的支援——尤其是開發人員、發行商和授權方——再努力也是白費。上述理念必須一開始就得到相關人員的認可。

換句話說，若他人毫不在意，試圖自己建立防洪系統是沒有意義的。


作者：David Manuel
來源：遊戲邦編譯
原譯文
https://www.gamasutra.com/view/feature/167831/a_producers_10_lessons_learned_.php?page=1