GAMASUTRA 原文：A Producer's 10 Lessons Learned the Hard Way
資深索尼計算機娛樂歐洲公司製作人大衛·曼努埃爾（David Manuel）分享了他多年以來看到的秘密，他看到開發人員無法從他們過去在專案上所犯的錯誤中吸取教訓，並就整合到您製作過程中的重要經驗提供建議。
去年，在我曾經居住的澳洲布里斯班，發生了30多年來最嚴重的洪水。然而，在過去的幾個世紀中，發生了好幾起此類的洪水襲擊了這座城市。
每次洪災之後，都有一個委員會來研究減輕將來洪災的方法。然而，大多數建議都被忽略了，並且繼續在洪氾平原上進行建設。世界各地發生的許多事件似乎都是如此-無論是洪水，火災還是動亂。成立了一個委員會，提出了建議，然後我們將它擺在一旁，然後忘記它，直到它再次發生。
主機遊戲製作中也會發生同樣的事情。我們經常花時間編寫檢討報告-但是這些課程是否得到了注意？令人沮喪的是，看到了同樣的舊問題，例如功能的漸變，激進的工作，士氣的低落，缺乏目標及方向，團隊內部或（和）開發人員與發行商之間的溝通問題，以及糟糕的技術和生產線一次又一次地出現。
作為一個行業，我們經常無法對所學知識採取行動。
在過去的十年中，我們聽到了很多有關敏捷生產方法理論以及要擁抱變革這樣的訊息，這是有道理的。但是，即使使用敏捷方法，也會出現類似的問題，在某些情況下還會加劇。
本文的目的是討論在新專案開始時最大程度地減少這些問題的方法，主要是透過建立堅固的基礎和前置計劃。換句話說，即使天氣變幻莫測，建造水壩和避免在洪水侵襲的平原上蓋房子也比等待下一次洪災的成本要便宜得多，而且更好。
1. 落實先前的建議
並非所有團隊都在專案結束時寫了一個事後檢討報告，可能是沒興趣或他們覺得沒意義。但是，如果我們要開始從錯誤中學習，那麼所有專案，特別是完成的專案，都需要進行事後檢討。
它也必須是一個公平的，委婉的過程，但同時又不能對於正確之處，錯誤之處及下次可以改進的地方留下情面。
一旦檢討報告完成並得到相關人員的同意，就需將它提供給工作室的所有成員 -- 最好是透過公司的內部網路，以便可以隨時輕鬆地拿它作參考，而不會遺忘在電子郵件裡或隱藏在已存檔的資料夾中。
當開始一個新專案時，請確保公司定期實施和檢查檢討報告中的所有相關建議，以避免遺忘這些建議及相同的問題不斷發生。
2. 從頭開始，從小處開始
對於財務的最大影響之一是管理開發團隊規模的高峰和低谷，尤其是在專案與專案之間。通常，下一個專案只有在目前專案結束後才會真正開始執行。不幸的是，這產生了一個問題，那就是太多的員工閒著發慌，而那些設計專案的人員才正開始訂出遊戲及其整體構想的基礎。
相反的，如果可以的話，最好在當前專案期間提前開發下一個遊戲，而一支精煉的團隊人員大約佔最終團隊規模的10％左右。
我個人會將以下的人員加入：專職首席設計師，負責基本構思，研究和遊戲設計；製作人訂定完成日期，開發預算，市場潛在範圍，並與客戶簡報進行緊密合作；還有一位概念美術將最初的想法形象化。當然，他們需要定期與將在以後加入團隊的關鍵人員保持聯絡，例如首席程式和首席美術。
還建議透過演講等方式使準備轉移到新專案上的每個人都知道其進展情況。否則，如果人們處於未知的黑暗中，他們可能會對新專案感到不滿或者覺得事不關己。如果只是簡單地將人員打入開發中的專案，他們可能會覺得自己比團隊中有價值的人更像是一種工作資源。
這個想法是，當多數生產人員開始進行原型製作的工作時，許多基礎工作已經就緒。注意 -- 這不會阻止在概念階段或之後的迭代，彈性或創意的延續。它主要是用來啟動遊戲和原型設計所應該關注的內容，而不是讓太多的開發人員在黑暗中絆倒尋找想法，而又沒有足夠的時間進行研究和思考。在這個階段不應該有大量的遊戲開發文件在等待著他們。
3. 從開始就安排關鍵人物
首席設計師和製作人儘早開始一個新專案的問題是，他們很有可能還在製作另一個處於中期或後期的專案。為了解決這個問題，我主張在專案上採用錯開首席設計師和製作人 -- 意思是著即使是只有一個專案的工作室，總會有一個可用的首席設計師和製作人未完全投入生產。這項額外的支出會很划算，因為回報遠遠大於風險。
如果我們吝嗇在一項資源，特別是前期的資源，那麼影響可能會很嚴重。如果您在最初就不確定某人來扮演關鍵角色的能力，那麼在後期製作中換掉他們的成本會更高，因為他們的工作很可能要重做。
確保您對這些關鍵人員有最大的信心。如果有明顯技術缺少的部份，請開始花費大量時間進行徵才，以填補所需要的職位，或者實施培訓計劃。
4. 與客戶建立關係
無論是公司內部的股東和/或像是發行商和授權商之類的外部客戶，領導生產團隊的人員進行面對面的交流並瞭解簡報，就方向達成共識並建立工作關係至關重要。
這看起來似乎很明顯，但多數時候這還是發生的不夠早，甚至根本沒發生。我們有像是Alpha，Beta和Master這樣有他們定義的嚴格的里程碑，但是還不等於早期預設的里程碑也會將這包含在內。這有點像是假設它將會發生。
有多少次問題的產生可以追溯到公司之間的不良關係，最初的誤會以及沒搞清楚就開始生產？
我強烈主張這些先期的面對面會議。我知道一個工作室由於旅行預算的限制而不允許任何的製作團隊人員飛往授權商會面。但是，幾百萬美元成本的專案所節省的開發工作帶來的好處很容易超過幾千塊美元的成本。
跟那些只透過電子郵件及電話會議的人，與已經面對面見過(即使只有一次)的合作來相比，會有很大的不同，因為您可以更好地了解他們，他們的舉止以及他們如何思考。
重要的是，100％完全參與專案工作的關鍵生產團隊（尤其是製作人）與股東進行會見，而不僅僅是那些開發工作室中高層級人員。這樣可以形成一種直接的關係，溝通不會被漫長且無效率的指揮鏈所過濾。
5. 釐清每個人的角色
在任何團隊中，很重要的一點是成員都必須了解自己的職責以及他們如何融入團隊。不要認為這是理所當然的，因為如果一個角色模糊不清，那麼人們將不知道對他們的期望為何以及團隊的架構如何運作。事情會被遺漏，其他角色可能會被不必要地削弱，甚至在兩個人之間產生競爭。確定誰該負責遊戲的方向，誰該負責路線的檢討等等。
在從一個專案轉移到另一個專案的過程中不可避免的改變期間，最好與團隊成員協商並創造就職的機會，這是可以合理預期的。如果有空缺，請打開這些職位，讓任何人都可以應徵並提出自己的理由。
我也強烈建議對周遭進行360度檢視，以便讓人可以評估他們的同儕，他們向哪些人報告以及那些向他們報告的人。這是對團隊成員和管理人員的能力進行更全面了解的極佳方法，從而可以自我提昇。
頭腦清晰和有組織性並不會減弱主動性和彈性。就像足球（也就是說，美式足球）團隊一樣，人們需要了解自己的角色以及隨之而來的期望。是一個前鋒有機會進球得分，還是一個中場有機會進球？
當然，一份工作內容說明並不能包涵人們所完成的所有任務，人們很自然地會提供工作內容之上和之外的協助 -- 中場球員也可以得分。但是，什麼都包會導致許多不必要的問題。
對於團隊之外的利害關係人（資深開發管理人員，發行商，授權商等）而言，這一點特別重要。存在太多人參與核准過程所產生的危險，這會導致不確定誰負責簽署和/或處理衝突的回饋。相反的，應從一開始就同意這些角色，回饋過程和周轉的時間。
6. 建立和維護長期計劃
在專案開始時，有許多未知數，但是從一開始就需要訂定長期的計劃。在最初時，關鍵日期會非常的高層級，例如專案的正式啟動、什麼時候開始預開發、什麼時候開始生產，Alpha, Beta和Submission各個版本。
在此時，會需要確定預算，里程碑日期和遊戲的大綱。確立了遊戲的概念後，就可以估算其他更多的東西。如果日期改變了，計劃也將隨之改變。
重要的是，長期計劃不僅僅只是為了討好利害關係人而匆忙準備的概述，而要等到生產線嚴重超時時才進行重新審視。可以保持敏捷並保持最新的長期計劃。這對於依賴關係特別重要，因為如果只按照里程碑來關注相關功能，則將錯過某些關鍵點。
(原文共分三頁進行說明，此為第一頁翻譯，若對後續有興趣請先參考原文)
