遊戲開發專案管理那些事

原文連結: 石匠的Blog

為什麼需要專案管理

專案管理可以理解為為了達到一個特定的目標，所實施的一系列對專案過程要素的管理，內容包括人員，資源，關係和技術等。專案管理的三個核心要素是：成本，時間，質量。通過平衡協調各方面的資源最終完成既定目標。

小專案通常不需要啟動專門的專案管理方法論，僅通過核心管理人員的粗放式管理把控即可基本上滿足需求。但是當專案規模越來越大，涉及的各方資源和人員越來越多，粗放式管理舉步維艱，需要更科學的專案管理方法論才能支撐專案的如期交付。

而在網際網路專案，特別是遊戲專案中，市場和行業日新月異，專案的需求變化更頻繁，完成專案需要的參與各方更緊密流程配合，更需要專案管理在開發過程中發揮作用，彙總資源，管理變化，掌控進度，把控質量，如期交付。

專案管理能夠將專案的開發過程和各方資源進度情況比較透徹清晰的呈現出來，便於資源協調和專案開發人員對總體情況的把握，從而更好的完成自己的本職工作。同時，也能給老闆，投資方或者合作伙伴一個清晰可見的專案情況。

遊戲開發中的專案管理

遊戲行業中，如果遊戲能夠歷經九九八十一難最終取得成功，完整的歷程一般包括以下幾個階段：

1. 專案需求提出階段。主策劃/製作人根據自己的市場分析或者老闆、投資人或渠道代理等權勢要求，提出一個遊戲專案總體方案。包括市場行情，競品分析，遊戲的核心玩法，美術風格，2D/3D,遊戲型別，特色系統玩法，資源需求，人員需求，專案預算等等內容。方案目的是要打動上位者，獲得各方資源支援，讓專案能夠成功立項。
2. 專案啟動階段。立項成功後，根據專案型別和要求組建核心開發團隊，包括前後端主程，主美等（更多情況是，在第一階段專案需求提出時，製作人就已經召集好了核心開發團隊）。製作人規劃好版本開發計劃，特別是核心玩法demo計劃，並同時開始召集更多的普通研發人員。
3. demo製作階段。雖然立項成功，獲得了一定資源，但是如果真正想得到資源的全力支援，遊戲行業的規則是拿出一個令人滿意的核心玩法demo。這個demo不需要紛繁複雜的各種系統功能，只需要完成遊戲的核心玩法，通過該核心玩法向老闆們展示遊戲的價值和特色，從而得到真正的立項和完整的資源支援。
4. 遊戲基本框架搭建階段。前後端程式根據需求搭建可以承載目標遊戲的基礎程式框架；策劃繼續完善和細化方案；美術和程式確定好資源製作規範，經過demo階段的磨合，各部門已經可以可行的開發流程。（很多時候這個階段會弱化，因為核心團隊可能之前就配合過，相互瞭解；而且跟多情況，前後端程式並不會重頭開發，會基於之前的遊戲專案刪繁就簡）。
5. 鋪量開發階段。系統功能策劃案已經完善，和美術也溝通順暢，程式基本架構已經完成，剩下的就是各路開發人員分工協作大量的開發各種系統功能，包括但不限於賬號，聊天，好友，工會，組隊，任務，副本，競技場，排行榜等等系統。
6. 完成第一個可測試的alpha版本。這是一個純粹對內的版本，能夠跑通策劃設定的基本遊戲流程，各個核心遊戲功能都已經具備，只是量還不夠。比如，任務只有10個，副本只有3個等等。為了細化迭代週期，可能alpha版本還會有好幾次迭代，不斷收集內部的反饋持續改進，直到達到外部測試的完成度。
7. beta版本階段。這個階段，遊戲的功能已經全部完成，鋪量的部分也達到了對外測試需要，需要發放給外部真正的使用者進行測試體驗，檢驗遊戲是否得到玩家認可，並收集玩家意見，將優秀建議整合進遊戲中。為了做出自己滿意，老闆滿意，渠道代理滿意，玩家滿意的“爆款”，這個階段也可能會迴圈多次，不斷改進。
8. 正式公測上線。所有準備就緒以後，接受真正的考驗，開始上線收費。能不能證明投資人火眼金睛，早就看好了這個遊戲和團隊？能不能通過自己的努力讓老闆財務自由？能不能做出一款說出去別人都知道的遊戲，從而功成名就？開發成員能不能湊夠自己的首付/彩禮,或者買車買房？所有對遊戲的付出和努力是否能夠得到回報，都在這個階段可以看到。
9. 持續迭代。如果到這裡遊戲還沒有死掉，已經戰勝了市面上90%的遊戲了。接下來就是根據新的需求或者玩家反饋，一個個版本持續迭代。不在迭代中數錢數到手抽筋，就在迭代中慢慢死去。（現實是殘酷的，也存在另外一種可能：同志們嘔心瀝血加班加點做成功了遊戲，把老闆送上了財務自由之路，但是當初的承諾並未得到兌現，然後被卸磨殺驢，落得慘淡出局一場空；有的人忍氣吞聲，有點人負氣出走，有點人無奈轉行，有的人刪庫跑路。。。）

通過以上幾個階段知道了遊戲開發從前到後大致會經歷哪些步驟。而專案管理，就是要把這個過程有效管理起來，並確保在各種艱難情況下都能夠不斷前行，如期上線。

在這個過程中，需要建立團隊，獲取外部資源，形成團隊內部的有效溝通機制，定義和細化需求，討論分工，制定版本計劃，管理需求變更，跟蹤和管理進度，持續有節奏的按計劃迭代前進。

為什麼遊戲專案管理難做

不重視

老闆不重視，有一些不懂研發的老闆只關注眼睛可見的產品，對其他冰山之下的部分並不重視，甚至認為是多餘。

製作人不重視，有太多團隊事物，專案溝通事宜，人員管理問題，甚至外部對接事宜需要處理，“沒有空”進行精細化專案管理。

核心人員不重視，研發團隊和核心成員是專案執行過程中最有發言權的團體，很多遊戲開發人員並未經過嚴格專案管理訓練，都是野路子，自己摸索出來的。而且不少人還有足夠的之前的遊戲專案經驗，“我們之前是這麼做的”，從而順理成章現在也這麼做。

專案管理能力欠缺

遊戲團隊中，專案管理的實際執行人很多時候是主策劃/製作人。因為研發的最終產品就是根據他們的方案來執行，他們對遊戲設計有深入的理解，是前端，後端，美術等工種的共同銜接人，所以由他們來掌控專案是比較自然的。

遊戲開發涉及美術，策劃，前端，後端甚至輔助管理&資料分析後臺，對外還有美術外包，商務運營對接的時間排期因素，是否能夠把專案內容版本規劃做得各個工種和部門高度契合，協同工作，是一件高難度的事情。完美的契合就像互相咬頜的齒輪，能夠無縫配合，激發更大的生產力。相反，沒配合好就會出現工作分配協同不平衡，忙的忙死，閒的閒死，最後還導致版本delay，怨氣橫生。

更有甚者，其他來路不明的人掌控專案，對遊戲，團隊管理，專案管理並不擅長，更多是自己邊做邊總結。導致摸索過程中必然會不斷交學費。如果掌控人能力不足以支撐整個研發週期的專案管理，這樣的專案管理，自然會變成東施效顰，然而這樣的情況並非個例。

多頭指揮

多頭指揮是指，專案執行過程中，各小組的組織架構關係和溝通流程規則並沒有很好的得到規範，導致多個人對同一個人分配任務的情況。更可怕的多頭指揮是來自老闆，大部分員工很難違背，只能順從。

正常情況下是主策劃的需求提給前後端主程，他們分析確認後確定任務分配給相應的組員開發並確定好時間週期。如下虛構場景是典型的多頭指揮：

• 某策劃A直接找到某前端開發人員B提一個功能開發需求，前端主程可能都不知道這個事情。
• 某運營C直接找後臺開發人員D做一個活動功能，而後端主程並不知道這件事，同時D也還在做之前的任務。
• 老闆直接找到了UI設計師E，讓他修改按鈕風格，而主美被繞開了。（老闆稱其為“扁平管理”）。

多頭指揮會打亂正常的研發流程和節奏，自然會導致專案管理的失效。

趕時間

由於遊戲行業競爭激烈，市場變化快，聽得最多的就是”趕時間“，”時間視窗已經快關閉了“，”XX競品3個月後要上線了，我們必須趕在之前怎麼怎麼樣“，”我們能不能提前一個月出產品？”，“我們先出一個版本上限，其他東西后面再補”等等。趕時間導致各種資源被壓縮，而專案管理是需要花一定時間代價換取專案的長遠可靠性保證。

需求變化快

專案的需求變化問題，在另一篇文章裡面討論過。主客觀原因導致的需求變化，也會給專案管理增加難度。

另外關於遊戲需求變化，可以附加一點：從某種意義上說，遊戲產品可以認為是一件藝術品，藝術品沒有絕對的好壞對錯，每個人都有自己的喜好和審美，導致有發言權的人都會是專案需求變化的發起者。

開發人員背景能力參差不齊

遊戲開發團隊人才背景錯亂參差不齊，有科班出身，有的非科班自學成才，有的轉行過來。他們的知識結構和做事方法都千差萬別，就像把正規軍軍規直接在山上的游擊隊裡直接執行，起難度可想而知。

人員流動大

遊戲團隊人員流動較大，甚至會遇到換了3，4波人還未研發完成的遊戲專案。成員對專案的熟悉程度，自我歸屬程度等都不一樣，很難採用體系化的專案管理方法一概而論。

專案管理混亂的危害

優秀而高效的專案管理是專案如期高質量交付的有效保障手段，而專案管理混亂會給團對和專案帶來各種問題，如下面的幾方面問題：

1. 專案情況混沌不清。混亂的專案中，很難說清楚當前專案的進度情況，各人員的工作內容，當前遇到的問題，下個版本的可靠交付時間。
2. 專案delay。專案管理混亂導致很難按計劃完成版本任務，導致delay是高概率事件。
3. 團隊不能成長。混亂的管理並不能為團隊的成長帶來幫助，即使當前專案摸爬滾打最終到了終點，那麼下個專案還會重複一遍所有的痛苦，團隊沒有任何成長和積累。
4. 成員不能成長。管理混亂，沒有章法，導致團隊浮躁，會讓成員懷疑這樣團隊的前途。成員不僅需要技術和專業能力的提升，更需要團隊協作，做事做人方式方法的提高。
5. 激發矛盾。一旦混亂後，事情就沒有了頭緒，各種事情就交織在一起，必然導致各方無規則碰撞，從而產生矛盾與相互埋怨。
6. 增加不信任感。混亂導致成員之間不信任，也會導致老闆對團隊能力不信任。

如何改進遊戲專案管理

專案管理是一個複雜的系統工程，不僅包括專案產品管理還包括團隊人員管理。事情本身的複雜性導致很難有銀彈畢其功於一役，不過可以從以下幾個方面做改進：

1. 團隊成員構建。專案是由人構成的團隊開發出來的，所有首先要構建一個高素質團隊。團隊核心成員最好是有經驗老將，每個都能獨當一面。如果他們還曾經互相配合過，那就更好。至於普通開發人員可以酌情吸納一些基礎素質好的新人。專案管理就像軍訓走正步，如果都是軍人那自然簡單易行；其次是有經驗的老兵帶經過層層選拔的素質新兵；再次是所有都是新兵，自然需要採坑自己摸索；如果淪落到瘸子或者幼兒園的小朋友都召集進來了，這個正步走起來恐怕將舉步維艱。
2. 提高團隊專案管理意識。需要在團隊中上下都統一思想，充分認識到利用專案管理的方式管理開發對團隊和個人的長遠益處。讓所有成員都自覺執行和完善專案管理事項。
3. 儘量完善專案規劃。遊戲專案涉及面廣，人員和工種多，需要分工協作密切配合，所以專案初期對專案的總體規劃，里程碑劃分，各個階段的任務目標作出清晰完善的定義，便於參與人員開展工作。
4. 做好需求變更管理。需求不變是不可能的，只能儘量控制變化，不產生根本性變化，少產生變化。變化少了之後，就會減少對既有工作節奏和流程擾亂。
5. 專職的專案管理人員。專案管理的執行三天打魚兩天曬網，那麼組員就會慢慢失去對專案管理的敬畏和信心。如果製作人忙於各種事情很難精細化專案管理和持續跟蹤，可以考慮找專人負責專案管理和進度維護跟蹤同步。有專人持續跟蹤，有助於專案管理事項真正落地執行產生正面效果，也有助於團隊養成正確科學的做事習慣。
6. 梳理科學的組織架構和成員管理體系。從組織架構，工作流程和任務分配上形成固定的負責體系，避免多頭指揮帶來問題。需求都通過組長評估後分發，並納入專案管理計劃中。不允許繞過必要的環節私下交涉需求和改進。
7. 人員/溝通管理。形成坦誠和有效的團隊內部溝通和反饋氛圍，使得成員有問題可以被發現和解決，同時他們也有渠道和氛圍能夠主動溝通。將一些潛在的問題事先解決，而不是等到問題變大甚至不可收拾時才後知後覺。順暢和坦誠的溝通環境可以減少內部矛盾，進而減少人員流動風險。
8. 借用專案管理工具。工具是位了更高效的完成任務，只要是能夠提高效率，合適自己適合團隊即可。如：project，PPM，甘特圖，XMind，excel等等都可以。