隨著游戲制作規(guī)格的上升，游戲制作團隊也越來越大?，F(xiàn)代3A游戲有動輒數(shù)百人的規(guī)模。隨著人員的增加，團隊之間溝通成本呈指數(shù)型增長，項目管理的難度也越來越高。在游戲開發(fā)中，如果團隊無法進行有效的項目管理，那么必然會陷入整體的混亂之中，進而讓游戲質(zhì)量大打折扣。

在GDC大會上，曾有多年3A游戲項目經(jīng)理任職經(jīng)驗，后專職進行敏捷項目管理培訓(xùn)的咨詢師Clinton Keith分享了項目管理的寶貴經(jīng)驗，對項目中可能出現(xiàn)的混亂狀況和應(yīng)對措施進行了詳細的講解。

以下為GameLook聽譯的內(nèi)容：

混亂，他們讓項目陷入無序，但他們總與游戲開發(fā)項目相伴相生。正因如此，我們必須要學(xué)會如何通過控制混亂來避免隨之而來的負面因素，包括項目死線臨近的瘋狂加班，項目廢棄帶來的額外開支，因工期不足而放棄關(guān)鍵功能的上線，或是讓項目沒做完就匆匆發(fā)售等等。盡管做游戲本身只是一門生意，但我們要讓項目的運作更有持續(xù)性。

我認為是倦?。╞urn-out）是我觀察到的一個很大的問題。作為一名項目經(jīng)理，原本的我對待項目極有熱情，在連續(xù)加班加點三個月以后，我開始變得逃避風險，滿腦子只想著趕快完成項目的目標。在倦怠之下，我腦子里想要的只有完全的控制，任何的流程都要越簡單越好。我的關(guān)注點完全停留在項目上，而不在游戲本身。我變成了一個“海鷗經(jīng)理”，闖進項目大鬧一通，然后立刻逃走。我要對開發(fā)者提出的每一個不在計劃內(nèi)的好點子說：“也許聽起來挺有意思的，但做這個賺不了錢，你給我專心完成項目計劃。”

我今天演講的一部分內(nèi)容就是希望避免上面這種情況發(fā)生。盡管我所說的內(nèi)容并不可能適用于任何一種工作室文化，但我希望能把一部分有益的原則介紹給你們。

首先，我想談?wù)勴椖块_發(fā)中的“壓力”。我認為壓力就和在健身房舉鐵有些類似，貿(mào)然上高重量很容易讓你受傷，但用太低的重量練習(xí)反而會讓你的肌肉變?nèi)?，只有在合適的重量區(qū)間中進行鍛煉才能獲得增肌的效果。項目中的壓力也一樣：太低的壓力會讓項目缺少動力，導(dǎo)致游戲的質(zhì)量不及預(yù)期，但太高的壓力會讓所有人陷入壓抑。我們要為游戲開發(fā)找到一個合適的壓力區(qū)間。

我講我的重點分為四個大類：注重結(jié)果而非產(chǎn)出、擁抱風險、管理“負債”、建立工作室文化。

注重結(jié)果而非產(chǎn)出

這部分經(jīng)驗來自于我在任天堂日本總部工作的所見所聞，當時我直接和宮本茂打過交道。宮本茂會走進一個開發(fā)現(xiàn)場，和我們共同探討游戲的設(shè)計點子，然后給我們?nèi)齻€月的開發(fā)經(jīng)費，讓我們沒有后顧之憂地地去尋找一個游戲的樂趣何在，三個月后他會再回來。

當我們回頭審視之前的開發(fā)流程，我們問自己：“我們找到的游戲樂趣到底有多少？”我把他們用這張圖的Y軸來表達出來。

我們的第一任務(wù)就是去尋找游戲的樂趣，如果三個月內(nèi)沒有找到一個游戲的樂趣何在，項目就取消掉。因此，我們項目的混亂主要出現(xiàn)在項目的早期，我們需要不斷實驗各種點子，把各種物品排列組合來找到游戲的樂趣基礎(chǔ)。此外，宮本茂還會要求我們把攝影機控制等基礎(chǔ)的東西先做好，再在其基礎(chǔ)上推進項目。

這樣的好處在于項目的整體變得可控。在探索階段，我們專心尋找樂趣，隨后游戲的形態(tài)開始“涌現(xiàn)”，我們開始在制作攝影機和關(guān)卡設(shè)計的過程中建構(gòu)起屬于這款游戲的樂趣“公式”和“詞匯”，隨后我們只需反復(fù)利用這些公式就可以創(chuàng)造游戲的樂趣。

而與之相對應(yīng)的是另一款游戲《Smuggler’s Run》的開發(fā)歷程，這是一款PS2平臺首發(fā)護航的開放世界賽車游戲。在項目最開始我們說：“嘿，讓我們把環(huán)境做得生動一點吧，在里面加上幾只鹿怎么樣？”后來我們發(fā)現(xiàn)人們很喜歡鹿，他們喜歡追著鹿跑或者開車撞上去，甚至比開車還要癡迷。他們甚至自己設(shè)置了挑戰(zhàn)，比拼規(guī)定時間內(nèi)撞鹿的數(shù)量，然后傳到網(wǎng)上給別人看。這是一個熱門的功能，但我們沒花多少精力做這個。

在傳統(tǒng)的瀑布開發(fā)流程里，我們要經(jīng)歷立項，前期準備，游戲制作，一測二測三測等等各種流程，一切都按部就班地推進，最后把樂趣拼湊成一個完整的游戲。但項目的壓力全部來到了最后階段：我們需要同時優(yōu)化性能，排除bug，為了工期砍掉關(guān)鍵功能；有人想出了很好的游戲點子，能讓游戲變得更有趣，但我們忙成一鍋粥，根本沒空管這些。

一個極端的例子是開發(fā)《Midtown Madness》的過程，當時整個營銷部門都對我們不理不睬，但在游戲A測結(jié)束以后的一瞬間，他們就突然開始緊緊盯著我們的各種動向，給我們提各種各樣的要求。我還聽說有臨近游戲發(fā)售以前，上層看到了游戲的CG動畫，然后他們說不喜歡這種風格，要求我們把十幾個小時的動畫全部重做一次這種事。你們想想這多讓人崩潰。如果他們在早期就看到了試制的動畫并提出了修改意見，以后的流程就可以順暢許多。

因此我推薦你們推行以下這些原則。

1. 和關(guān)聯(lián)部門建立起透明的關(guān)系，鼓勵他們在早期參與游戲的開發(fā)，協(xié)定合作尺度，和各部門建立起信任；
2. 每三個月輸出一個可玩的版本，這樣能夠幫助校正開發(fā)計劃，并及時知會上級最新的開發(fā)境況，獲得許可；
3. 最后關(guān)頭做出的改變并不都是壞的，要能夠利用機會。

當然，這些原則的推行往往會遇到困難。比如現(xiàn)行的合同體系并不允許在項目早期就冒風險。此外，中間管理層有時候會過度要求你交代項目細節(jié)，或者提交各式各樣的文件等等，這些都可能發(fā)生。因此，要盡可能和上層建立信任，向他們展示你的進度，厘清他們的顧慮。

擁抱風險

我們將風險分為兩個維度：是否能被預(yù)知、以及是否能被解決。

首先是我們能預(yù)知到且能解決的風險。這些風險可以提前預(yù)測到，并做好相應(yīng)的準備。即便是采用敏捷開發(fā)流程，我們也需要做一定程度的應(yīng)對來避免混亂的發(fā)生。

其次是我們能預(yù)知到，但尚沒有解決方案的風險。例如，新的Xbox將要發(fā)售了，我們想要在新平臺發(fā)售我們的游戲，但我們還尚不了解如何在新的Xbox平臺進行開發(fā)。盡管微軟告訴你開發(fā)會很容易啦，機器的性能也很強大啦，但機器沒拿到手一切都是未知數(shù)。針對這種狀況，我們需要提前考慮如何應(yīng)對并減少風險的存在。

第三種是我們沒法預(yù)知，但我們能解決的風險。這種情況我們只能硬著頭皮去學(xué)習(xí)如何對應(yīng)。

第四種是我想講述的重點：我們預(yù)知不到，而且我們極難解決的問題。正好有這么一個例子：我們之前在開發(fā)一個《諜影重重》IP的游戲，但我們誰也不知道的是，主演馬特·達蒙的媽媽是一個反電子游戲斗士。因此，馬特·達蒙在項目的后期退出了，連帶著其他演員也跟著他一起退出了，我們不得不找其他演員。最終我們沒能趕上電影上映，游戲的質(zhì)量也受到了影響。

這種事情無論如何都沒法提前備案。因此我想講的是“擁抱風險”，并非避免風險或排除風險，去積極主動地應(yīng)對這些風險的存在。

我們當時學(xué)到的一套流程是：首先，我們要分辨風險。我們會在項目開始之前進行一套“預(yù)復(fù)盤”，去梳理項目可能遇到的問題，例如錯過關(guān)鍵死線。我們再繼續(xù)回推，什么因素會導(dǎo)致這種情況發(fā)生？例如，我們當時使用的一款中間件還沒有移植到這個平臺上來。針對這個中間件會帶來的潛在風險，我們設(shè)置了一個特定的KPI來評估風險的存在性，假如十月一日這個中間件無法使用，我們就認為這個風險存在。然后我們提前思考應(yīng)對措施，譬如通過購買中間件的源代碼，自己來做移植的方式讓中間件盡快投入生產(chǎn)。每隔一到三月，我們就會重新評估這些KPI，并反復(fù)推敲是否有新的風險出現(xiàn)，或者修改此前定下的應(yīng)對預(yù)案。如果KPI未達預(yù)期，我們就當機立斷，開始執(zhí)行此前的備案。

有些工作室文化中會認為這種提前預(yù)知風險的行為是在挫敗士氣，他們只想做到“避免”風險的發(fā)生。但事實是風險很難避免，尤其是你對風險本身都不知情的時候。最重要的是在面對風險時能夠主動出擊，以避免項目遭遇泰坦尼克。

管理“負債”

這里的“負債”是虛指，我們指的是在項目中出現(xiàn)的一些潛在包袱。但和銀行貸款一樣，債務(wù)還清的時間越長，你需要付出的利息就越多。一個bug拖的時間越久，日后想要在代碼山中找到這個bug的難度就越高，類似這種事情。設(shè)計和內(nèi)容開發(fā)方面也是一回事。在敏捷開發(fā)的過程中，我們時常會專注于盡快輸出一個可玩版本，把各種問題拖到A測以后再去解決。但這些問題可能隨著時間積累，越來越難以被解決。

如下圖可見，隨著項目推進得越來越深入，躺在bug數(shù)據(jù)庫里的內(nèi)容越來越多，我們要處理的內(nèi)容也越來越多。等到項目收尾階段，“砰”，混亂又出現(xiàn)了。

在開發(fā)《Midnight Club》這款開放世界賽車游戲的時候，我們在項目的最后階段才意識到我們要把所有的紋理都塞進機器的內(nèi)存里去，于是我們緊急要求美術(shù)繪制新的紋理，但依然趕不上工期。我們的技術(shù)負責人實在沒辦法了，下令把所有的紋理質(zhì)量全部降低75%。我們的美術(shù)同事直到游戲上市才發(fā)現(xiàn)紋理變得極其粗糙，可以想象他們當時有多沮喪。游戲的質(zhì)量就是這么被影響的。

我們后來是這樣進行改進的。每隔三個月，我們就抽上一周對游戲進行整修，處理一部分之前的問題。如此反復(fù)。最終在發(fā)售前，我們的工期還留有余量，也不會面臨地獄式的趕工的情況，游戲的質(zhì)量也不會打折扣。這是多贏的局面。

經(jīng)驗總結(jié)：

1. 不要害怕“負債”，他們是游戲開發(fā)的一部分。不要依賴bug數(shù)據(jù)庫，及時進行處理能夠避免項目在某一個時間點陷入密集的混亂；
2. 有意識地進行“還債”，逐漸改進內(nèi)容整修流程；
3. 改進開發(fā)工具：加入自動化測試，縮短反饋周期等等；
4. 對“完工”給出清晰的定義。

建立健康的工作室文化：讓開發(fā)者如魚得水

這個部分是能夠最有效提升生產(chǎn)力的。創(chuàng)造出一個以工作質(zhì)量為最高衡量標準的工作室文化將會讓項目如虎添翼。

這個世界上有很多低劣的衡量標準。我之前任職的一家工作室的母公司是一家日本企業(yè)，他們認為員工呆在辦公室的時間越多，就意味著員工越勤奮，哪怕員工在摸魚。這和加州的辦公室文化格格不入。后來我們得知，他們在離我們一百英里外的洛杉磯有一個工作室，母公司的人有時會派洛杉磯的員工在凌晨兩點開車路過我們工作室的停車場，看看里面停了多少車。開始他們很光火，因為他們發(fā)現(xiàn)根本沒有多少車半夜停在那。上有政策下有對策，我們和旁邊一家半夜上班的報社達成了一個協(xié)定，讓他們的員工把車停在我們的停車場。也算是解決了問題。

我曾經(jīng)也是一個在項目臨近死線時會要求全體工作室一起加班的項目經(jīng)理，我當時還沾沾自喜，因為我會和整個團隊一起每周工作七十個小時。但后來在我們的檢測中發(fā)現(xiàn)，盡管加班的第一周產(chǎn)出量確實有所提升，但到了第四第五周，我們的產(chǎn)出量反而是在下降的。我意識到，人們會感到疲倦，他們會犯更多的錯誤，進而拖慢整體的辦公效率。在了解到這一點后，我就再沒有要求團隊全體加班過了。

因此，我們需要建立合理的衡量標準。并非是把員工按在辦公室從早到晚不動的標準，哪怕這樣能讓上層更安心。僵化的安排會讓員工感到公司缺乏信任，進而影響員工和團隊整體的工作效率。同理，要求員工事無巨細地提交報告也是表達不信任的一種方式。對應(yīng)地，在這種嚴苛的規(guī)則之下，人們會根據(jù)規(guī)則來調(diào)整自己的工作標準——假如你要求我每日代碼的行數(shù)需要達到一定量，那我就寫大量注水的行數(shù)來應(yīng)付。最終受害的是整體的項目質(zhì)量。

此外，我還想提及一個“心流”的概念。作為游戲開發(fā)者，有時候我們會迷戀我們的工作，早上從床上爬起來，快速地洗漱后，立刻就沖到辦公室開始創(chuàng)作游戲，效率自然也大大提高。我們將這種特殊狀態(tài)稱為“心流”期。而作為項目管理，我們需要知道如何讓開發(fā)者進入“心流期”來擴大開發(fā)效率。

我們認為，決定心流的兩大因素是技術(shù)水平和工作難度：如果工作難度顯著低于技術(shù)水平，那么開發(fā)者會感到無聊；如果工作難度顯著高于能力水平，那么開發(fā)者就會感到高壓和不適從。作為領(lǐng)導(dǎo)層，我們在保證員工盡可能呆在舒適區(qū)的同時，也可以不斷帶領(lǐng)著員工挑戰(zhàn)更復(fù)雜的工作，因為員工的能力也會隨著時間提升。

····· End ·····

需要項目管理資料合集的同學(xué)可先關(guān)注然后私信我哦