這篇文章將嘗試把從0到1的游戲項目管理過程抽象成標準sop，盡可能把需要做的事情標準化，希望能通過這種方式探索出一條合適的游戲項目管理之路。

游戲項目的一大特點在于立項初期追求敏捷，這時相較于工具&規范，PM應該更多關注如何快速響應變化和產出demo，因此以下會從兩個方面實操PM參與項目的過程。

Part1 親身參與項目的管理方式(項目內)

當項目經理親身參與項目時，對項目的目標和實現目標的方式會有更多參與的空間，除了基礎的項目管理工作外，需要分出一部分精力參與到思考項目的實際設計中來，和團隊成員一同思考論證項目方向的可行性。

初創團隊

①明確項目范圍和成本，制定預研計劃

對于新的項目，相對于流程和工具，最開始讓項目運轉起來更重要的是大家有著明確的目標，方向一致。

一個不到5人的小團隊，期望做一款運動品類的游戲合集，在正式開工之前，項目經理和團隊一起確定了里程碑計劃，明確關鍵時間節點和需要交付的內容范圍。

②制定工具&規范

工具&規范這塊，只需要幾個簡單必要的晨會周會等輕量化流程能讓項目正常運轉下去即可。

由于項目體量不大并且有明確的目標，立項初期大家通過teambition給自己/彼此開單的方式記錄每日的工作內容，每周五固定時間做一次當周的進度總結，體驗目前的版本(PC/手機)，記錄問題并討論解決方案。不斷重復這個過程直到demo review會。

③承擔一些項目內的公共任務

在研發過程中，項目經理需要跟著團隊一起成長，從各方面為團隊提供幫助，調整工作重心以適應團隊需求。

在demo階段項目經理不需要對流程和工具投入太多精力，可以將空出來的時間投入到項目研發中，比如項目可能需要更多調研競品，收集目標用戶反饋。這時項目經理可以和團隊一起參與調研的過程，打入競品/論壇內部了解玩家的真實想法，嘗試訪談一些核心玩家，為明確項目方向提供助力。

④根據項目進展適當引入新的流程機制

當項目運轉發現問題或痛點時，考慮適當引入合適的流程，由淺入深逐步推進，如果一開始就實施完整流程sop，不但影響效率，也很容易引發大家的抵觸情緒。

項目demo進度穩定，到了需要背景音樂/音效的階段，這時項目經理可以參考已有項目的規范，適當裁剪，形成適合目前團隊的音效提需/回收流程。

中途加入團隊

①團隊訪談了解情況

項目經理中途加入團隊，首先需要了解團隊成員的情況和團隊目前的運轉方式，收集各自的痛點，包括團隊負責人和團隊成員各自關心的問題(通常位置不一樣面對的問題同樣也會不一樣)

團隊負責人認為團隊的溝通效率不高，感覺美術需求一直爆單但是實際上做出來的資源最終實裝至游戲內的卻不多。項目經理通過和團隊成員逐一訪談，發現是因為需求確定時間較晚，美術同學做的時候是根據提需求的順序做的，而不是需求的優先級，因此會出現實際做出來的低優先級資源因為程序帶寬不足無法實裝至游戲內。

②將信息整合在一起，將收集到的問題排列優先級，先處理高優問題

在訪談的過程中能收集到各種各樣的問題，這時項目經理需要判斷這些問題的影響范圍，優先處理影響范圍大的問題，下面簡單列一些過往訪談收集到的問題，因為每個團隊的情況不一樣，大家可以自行判斷應該優先處理哪個問題(已做模糊處理)。

團隊成員策劃A：驗收流程不明確，缺少自測，提交驗收的內容有明顯bug;美術資源在實裝后還出現對效果不滿意需要反復調整的情況，并且改動也沒有對應的單子追蹤，大多是口頭需求，無法跟進最終效果。團隊成員程序B：人手不足，按編制我們團隊應該有10人，但是實際上目前只有8人，其中包括兩名校招生;開發時間比較緊張，出現過策劃案還沒完全定下來就搶先一步宣講的情況;有時會出現開始功能開發但是前置美術資源還沒做完的情況，也不知道對應的資源什么時候做完。團隊成員美術C：插單和臨時需求多，并且提的太晚了;信息同步有問題，有時候策劃改了需求但是美術同學沒被通知到;不清楚同組其他同事手上在做什么;主美審核返工比較多，特別是到交付節點的時候，經常卡在審核這邊。

③處理問題的過程中觀察并記錄團隊的狀態

一些問題的解決方案往往需要團隊成員的配合，在方案確定后提前和重要干系人溝通討論方案可行性，確保得到足夠的支持后再落地推進方案。每天記錄下當日發現的問題，對于需要額外支持的問題有計劃地尋求幫助。

推進方案的過程中也是了解每位團隊成員的好時機，利用這個機會逐步建立信任。

④定期(版本、sprint或自然月)回顧團隊的工作總結，根據實際反饋調整策略

每達到一個關鍵里程碑節點，最好根據實際工作產出和計劃做對比，觀察團隊的需求完成情況，并以此為依據作為未來版本需求承接能力的參考。

每個人都有自己的估時習慣，也許過于樂觀、也許過于保守，過程中項目經理需要盡量了解每個人的估時偏好，做到自己心里有數。

⑤每一到兩個季度重新對團隊進行訪談，再回到第2步開始

不同階段團隊面對的問題可能是不同的，定期訪談(通常是年中和年終兩次績效考核之前)一方面是了解大家的工作狀態，另一方面是和團隊成員溝通對過往反饋問題的解決情況。

Part2 作為中臺支持項目的管理方式(項目外)

作為中臺支持項目管理的特點之一是不實際參與項目內的管理或只是協助團隊成員制定項目的大計劃，對接的項目數量通常較多，且每個項目團隊的情況各異，不一定有完全符合所有團隊的標準流程，這時一方面需要通過訪談，了解各個團隊目前遇到的困難和核心訴求，拆解各個團隊的業務鏈路，看看過程中哪些是特殊的，哪些是可以共用的，可以考慮制作一套完整的流程，針對不同團隊的特點做裁剪和適配，每個團隊只用這個流程中的一部分，有這份流程作為底子在，最終目標是能用一套流程應對各種情況。

①和每個團隊負責人訪談

對于了解團隊現狀來說，訪談總是一個好的打開方式，通過和不同團隊的負責人聊天，項目經理在建立聯系的過程中還能收集到一手信息，其中最重要的是團隊的業務目標和遇到的實際問題。

業務目標是團隊存在的意義，遇到的實際問題是項目經理需要投入精力解決的方向。接下來還是舉幾個實際存在的栗子，分別代表這三種不同的問題類型，讓讀者有個基礎概念(已做模糊處理)。

團隊A主打休閑競技品類，希望打造移動端的糖豆人體驗。目前遇到最大的問題是使用的自研引擎，對3C的支持不夠完善，引擎底層還在打磨3C的體驗，但是項目等著用，出現了卡脖子的情況。團隊B主打社交品類，希望打造一個絕美的場景，并在場景內加入各種互動元素，讓進入其中的玩家能通過游戲中的內容實現社交的目的。目前遇到的問題在于美術資源產出速度不達預期，并且因為對美術品質要求較高，經常出現資源返工的情況。團隊C主打家園養成品類，希望打造一個有趣的生態，通過設計足夠的目標和激勵，讓玩家有動力建造自己的家園并和好友們分享，最終實現正向循環。目前遇到的問題是上層雖然對項目的最終形態有一致預期，但是對于實現的路徑有各自的看法，導致項目方向遲遲無法確定，產生了一些開發資源浪費，影響了整個團隊的節奏。

②嘗試為每個團隊定制解決方案

之前已經收集了每個團隊的信息，下一步可以case by case地處理每個團隊的問題，這么做是希望減少外部因素干擾，單純為當前團隊做出最有利的方案。下面針對上面三個團隊，嘗試給出一些解決思路。

對于團隊A，如果自研引擎接受定制需求，那么可以參考成熟的商業引擎整理一份需要的3C功能清單，和引擎團隊共同討論引擎的后續發版規劃;如果自研引擎不接受定制需求，那么需要考慮是團隊A的業務目標重要，還是使用自研引擎開發更重要，做一次取舍。

對于團隊B，需要考慮項目目前處于驗證階段還是鋪量階段。對于驗證階段的項目，美術的問題可能是資源管線還沒完善，可以從流程的角度看是否存在優化空間;對于鋪量階段的項目，如果流程管線都沒問題，則可以看是不是人出了問題。

對于團隊C，可以考慮設置每個版本的關鍵里程碑，XX/XX確定需求、XX/XX封版提測、XX/XX發布，通過時間節點的壓力倒排上層需要給出結論的時間。

③還原各團隊完整流程，并嘗試抽象成一個包羅萬象的“超級流程”

現在已經針對各種類型的問題給出了一些解決方案，我們可以從解決方案作為切入點，還原各個項目優化后的完整流程，形成自己的流程庫，并在過程中嘗試抽象出一個包容不同團隊的“超級流程”。比如在需求準備階段，哪些職能需要在什么節點做哪些事;在封版提測階段，如何定義封版，提測的條件有哪些等。

④裁剪出適合的流程給新團隊使用

上面我們已經有了一個“超級流程”，如果有新團隊需要，可以考慮為其挑選其中適合的部分。

⑤不斷迭代

在各個團隊實際運作過程中迭代各自的流程，反哺至“超級流程”中，不斷循環。

-從0到1的項目經歷對每個人來說都是一筆寶貴的財富，也是項目經理職業成長的必經之旅，上面的內容不一定適合所有項目，掌握自己的方法論，以不變應萬變，擁抱這個充滿變化的世界~