都說游戲項目管理難做 如何實現高效管理

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

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

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

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

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

項目需求提出階段

主策劃/制作人根據自己的市場分析或者老板、投資人或渠道代理等權勢要求，提出一個游戲項目總體方案。包括市場行情，競品分析，游戲的核心玩法，美術風格，2D/3D,游戲類型，特色系統玩法，資源需求，人員需求，項目預算等等內容。方案目的是要打動上位者，獲得各方資源支持，讓項目能夠成功立項。

項目啟動階段

立項成功后，根據項目類型和要求組建核心開發團隊，包括前后端主程，主美等(更多情況是，在第一階段項目需求提出時，制作人就已經召集好了核心開發團隊)。制作人規劃好版本開發計劃，特別是核心玩法demo計劃，并同時開始召集更多的普通研發人員。

demo制作階段

雖然立項成功，獲得了一定資源，但是如果真正想得到資源的全力支持，游戲行業的規則是拿出一個令人滿意的核心玩法demo。這個demo不需要紛繁復雜的各種系統功能，只需要完成游戲的核心玩法，通過該核心玩法向老板們展示游戲的價值和特色，從而得到真正的立項和完整的資源支持。

游戲基本框架搭建階段

前后端程序根據需求搭建可以承載目標游戲的基礎程序框架;策劃繼續完善和細化方案;美術和程序確定好資源制作規范，經過demo階段的磨合，各部門已經可以可行的開發流程。(很多時候這個階段會弱化，因為核心團隊可能之前就配合過，相互了解;而且跟多情況，前后端程序并不會重頭開發，會基于之前的游戲項目刪繁就簡)。

鋪量開發階段

系統功能策劃案已經完善，和美術也溝通順暢，程序基本架構已經完成，剩下的就是各路開發人員分工協作大量的開發各種系統功能，包括但不限于賬號，聊天，好友，工會，組隊，任務，副本，競技場，排行榜等等系統。完成第一個可測試的alpha版本。這是一個純粹對內的版本，能夠跑通策劃設定的基本游戲流程，各個核心游戲功能都已經具備，只是量還不夠。比如，任務只有10個，副本只有3個等等。為了細化迭代周期，可能alpha版本還會有好幾次迭代，不斷收集內部的反饋持續改進，直到達到外部測試的完成度。

beta版本階段

這個階段，游戲的功能已經全部完成，鋪量的部分也達到了對外測試需要，需要發放給外部真正的用戶進行測試體驗，檢驗游戲是否得到玩家認可，并收集玩家意見，將優秀建議整合進游戲中。為了做出自己滿意，老板滿意，渠道代理滿意，玩家滿意的“爆款”，這個階段也可能會循環多次，不斷改進。

正式公測上線

所有準備就緒以后，接受真正的考驗，開始上線收費。能不能證明投資人火眼金睛，早就看好了這個游戲和團隊?能不能通過自己的努力讓老板財務自由?能不能做出一款說出去別人都知道的游戲，從而功成名就?開發成員能不能湊夠自己的首付/彩禮,或者買車買房?所有對游戲的付出和努力是否能夠得到回報，都在這個階段可以看到。

持續迭代

如果到這里游戲還沒有死掉，已經戰勝了市面上90%的游戲了。接下來就是根據新的需求或者玩家反饋，一個個版本持續迭代。不在迭代中數錢數到手抽筋，就在迭代中慢慢死去。(現實是殘酷的，也存在另外一種可能：同志們嘔心瀝血加班加點做成功了游戲，把老板送上了財務自由之路，但是當初的承諾并未得到兌現，然后被卸磨殺驢，落得慘淡出局一場空;有的人忍氣吞聲，有點人負氣出走，有點人無奈轉行，有的人刪庫跑路。。。)

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

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

為什么游戲項目管理難做

自我破壞規則

項目管理就是通過種種方法和工具制定一些實施規則，大家通過規則約束和協調互相的工作。而因為種種原因，規則的制定者(老板/制作人等)不能有效的執行規則，導致項目管理流于形式，甚至制定者自己反復破自我壞規則，導致項目成員徹底失去對規則的敬畏。

不重視

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

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

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

項目管理能力欠缺

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

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

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

多頭指揮

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

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

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

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

趕時間

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

需求變化快

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

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

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

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

人員流動大

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

項目管理混亂的危害

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

項目情況混沌不清。混亂的項目中，很難說清楚當前項目的進度情況，各人員的工作內容，當前遇到的問題，下個版本的可靠交付時間。

項目delay。項目管理混亂導致很難按計劃完成版本任務，導致delay是高概率事件。

團隊不能成長。混亂的管理并不能為團隊的成長帶來幫助，即使當前項目摸爬滾打最終到了終點，那么下個項目還會重復一遍所有的痛苦，團隊沒有任何成長和積累。

成員不能成長。管理混亂，沒有章法，導致團隊浮躁，會讓成員懷疑這樣團隊的前途。成員不僅需要技術和專業能力的提升，更需要團隊協作，做事做人方式方法的提高。

激發矛盾。一旦混亂后，事情就沒有了頭緒，各種事情就交織在一起，必然導致各方無規則碰撞，從而產生矛盾與相互埋怨。

增加不信任感。混亂導致成員之間不信任，也會導致老板對團隊能力不信任。

如何改進游戲項目管理

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

團隊成員構建。項目是由人構成的團隊開發出來的，所有首先要構建一個高素質團隊。

團隊核心成員最好是有經驗老將，每個都能獨當一面。如果他們還曾經互相配合過，那就更好。至于普通開發人員可以酌情吸納一些基礎素質好的新人。

項目管理就像軍訓走正步，如果都是軍人那自然簡單易行;其次是有經驗的老兵帶經過層層選拔的素質新兵;再次是所有都是新兵，自然需要采坑自己摸索;如果淪落到瘸子或者幼兒園的小朋友都召集進來了，這個正步走起來恐怕將舉步維艱。

提高團隊項目管理意識。需要在團隊中上下都統一思想，充分認識到利用項目管理的方式管理開發對團隊和個人的長遠益處。讓所有成員都自覺執行和完善項目管理事項。

盡量完善項目規劃。游戲項目涉及面廣，人員和工種多，需要分工協作密切配合，所以項目初期對項目的總體規劃，里程碑劃分，各個階段的任務目標作出清晰完善的定義，便于參與人員開展工作。

做好需求變更管理。需求不變是不可能的，只能盡量控制變化，不產生根本性變化，少產生變化。變化少了之后，就會減少對既有工作節奏和流程擾亂。

專職的項目管理人員。項目管理的執行三天打魚兩天曬網，那么組員就會慢慢失去對項目管理的敬畏和信心。如果制作人忙于各種事情很難精細化項目管理和持續跟蹤，可以考慮找專人負責項目管理和進度維護跟蹤同步。有專人持續跟蹤，有助于項目管理事項真正落地執行產生正面效果，也有助于團隊養成正確科學的做事習慣。

梳理科學的組織架構和成員管理體系。從組織架構，工作流程和任務分配上形成固定的負責體系，避免多頭指揮帶來問題。需求都通過組長評估后分發，并納入項目管理計劃中。不允許繞過必要的環節私下交涉需求和改進。

人員/溝通管理。形成坦誠和有效的團隊內部溝通和反饋氛圍，使得成員有問題可以被發現和解決，同時他們也有渠道和氛圍能夠主動溝通。將一些潛在的問題事先解決，而不是等到問題變大甚至不可收拾時才后知后覺。順暢和坦誠的溝通環境可以減少內部矛盾，進而減少人員流動風險。

借用項目管理工具。工具是位了更高效的完成任務，只要是能夠提高效率，合適自己適合團隊即可。如：project，PPM，甘特圖，XMind，excel等等都可以。