告別996？資深遊戲PM：遊戲專案開發的高效祕訣

市場環境

手遊行業類似於風潮行業，需要觀望當前的遊戲風向。但是資訊的獲取都有置後性，一款遊戲的研發週期為1~2年，當廠商跟進風潮的時候，往往是其他廠商已經成功收穫大量紅利的時候。這樣就會面臨專案上線時風潮是否已過，以及能否吃到被成功產品洗過剩下玩家的紅利等等，種種問題。

手遊行業的研發廠商不得不用加班、趕工、反覆變更方向適應風潮等方法，用龐大的人力、時間成本，去追趕那稍縱即逝的風潮，與其他研發廠商廝殺，覬覦能在尚未變成紅海的藍海中爭取到一席位置。這也是導致遊戲行業加班的其中一個原因。

卡牌、回合制、FPS、MMORPG社交、二次元、MOBA、SLG、傳奇頁遊風、吃雞、沙盒…跟隨風潮席捲而來的就是這麼一堆堆品類彼此相似的手遊產品。

也存在有研發廠商試圖引領風潮，這些團隊需要不斷的試錯重做，進行內測市場驗證，長時間的積累沉澱設計經驗。其中耗費的試錯成本難估計，上線之後的瘋狂買量刷榜的成本，團隊承擔的巨大心裡壓力，在這些因素的影響下成功者寥寥可數。

當然廠商也可以跟隨著經過市場驗證的成功方向去製作遊戲，即成熟IP+成熟品類的方式。此模式下的主流思路，在可量化的方向上，達到最優。

比如，美術上達到高質量，在shader、紋理、渲染上表現出極致；

比如，IP版權購買，世界一線大IP；

比如，文案設計包裝，足夠新奇創新，擁有吸引力；

比如，基礎玩法上的高標準，戰鬥突出強烈爽感打擊感，槍械模擬真實彈道，極為舒適的玩家付費體驗，流暢的即時反饋體驗… …

整體遊戲的製作方向即在已經成熟的框架品類基礎上加上這些高標準，並進行微創新。日後遊戲的發展的趨勢也會不可避免地走持續精品化道路。

遊戲成功上線之後，還要面臨著手遊行業獲取使用者成本上升，傳統買量策略不能起到預期中效果的問題。18年初，安卓仙俠類遊戲買量CPA 50~60，19年遊戲CPA 150左右並不遙遠，另外19年各投放渠道騰訊、百度、位元組跳動等，開啟收割模式，CPA勢必會直線上升！在如此高的CPA下，ROI回本關鍵：搶奪大R高付費玩家群體。

期望管理

期望管理是領導力的體現之一，這也是管理工作中最難的部分，管理好期望可以有效的增加團隊凝聚力。達成統一的專案期望，形成明確目標。

由於遊戲研發需要三個團隊的共同協作，但三個團隊的職業技能、思維方式又各不相同，致使每個部門的期望也不同，也容易造成各部門之間溝通的阻塞。

以一個系統模組功能的製作為例，下面是三個部門的思考方式。

策劃團隊：體驗合理性、設計趣味性等

程式團隊：邏輯嚴謹性、技術應用性等

美術團隊：美術表現力、美感程度等

不僅部門之間期望互相不同，同部門中的期望也不盡相同，戰鬥策劃與系統策劃，在思考設計功能上的側重點就不同，伺服器程式和客戶端程式在互相配合階段，思考的側重點也不同。不禁感嘆，如果我們都像三體人一樣，思維透明，那麼我們的工作體驗就會截然不同，效率異常高效。

期望的混亂會嚴重拖後團隊的工作效率，影響團隊內氛圍。管理好期望即統一思想，以最優的力量完成目前最需要完成的任務，減少人力及專案資源的浪費，好鋼要用在刀刃上。當成功統一思想之後，團隊的整體效率也會提高。

管理期望的關鍵，保持資訊的及時共享同步，以及確認策劃、程式、美術真正能理解核心思想並且統一認同。給團隊成員同步資訊，這一點其實很容易做到，但是讓團隊成員認同共同的期望卻很難，這裡面考驗製作人、管理人員的管理水平，人際關係技能，話術技巧等等。這過程中注意一點，如果雙方在統一思想過程中都各退一步達成妥協，那麼最後的結果普遍是“雙輸”。

需求收集

由專案發起人或者製作人確定專案或者里程碑的目標，然後根據目標進行拆解需求，這些需求的目的是使專案或者里程碑最終的目標達成並通過相關方的驗收，最後所有的需求需要最終通過製作人或者發起人的稽核。

遊戲面向的使用者是玩家，不同玩家對遊戲的需求點也不同，有一些需求是否可以滿足遊戲特定玩家的特點呢？遊戲使用者經過這幾年手遊環境的洗禮，劃分出了不同的玩家群體，典型一點的卡牌玩家、二次元玩家、MMORPG玩家等等，這些群體普遍對應上文中提到的遊戲類別。這些遊戲玩家各有個的特點，這些總結下來就是玩家使用者畫像。

從需求角度出發，某些需求可能會直接偏離原有遊戲方向上對應的目標使用者，這樣的結果可能導致遊戲的整體風格類別產生偏移，致使出現這兩個類別使用者都不接受的現象。

比如，海戰類遊戲中，加入MMORPG的元素，這雖然不失為一種創新，但是在體驗上海戰玩家可能並不買賬。

比如，MOBA遊戲中，加入了遊戲外裝備飾品強化這類對局之外為玩家戰力挖的坑，會導致MOBA失去原有的公平性原則。

但是，這類的創新也有成功的一面。私以為這取決於能否抓住遊戲型別的核心，即這類玩家玩遊戲的核心追求點究竟是什麼，在合理融合玩法元素的基礎上，不破壞核心追求點，就是成功的創新。

這裡既然說到了玩家追求，提一下利益交換原則，玩家玩設計者的遊戲或者設計的時候他究竟會得到什麼？

這裡暫時分成兩層，一層，遊戲中對自我情緒的影響，比如以自己畫符抽卡，妄以此來預測這一段時間的運氣，如果能抽中集齊全部SSR，就證明自己歐氣爆棚，使得玩家達到自我的滿足；另一層，遊戲對現實生活的影響，比如最強王者帶妹上分，奔現成女朋友，滿足自己的社交需求。如果想細化，還可以繼續深入劃分。

上面提的這些其實是覬覦希望可以驗證需求的正確性，做正確的事情遠比正確的做事重要，減少不必要的甚至是錯誤的需求，可以節省團隊開發的時間，避免推倒重來、反覆修改的噩夢。但是，在實際開發中，這種情況真的很難避免，只能極力去減輕。

專案規劃

管理進度的前提是，根據需求列出具體的執行條目，這樣才能逐步的推進，這個在PMBOK(專案管理指南)中有專業的術語，即建立工作分解結構，把獲得的需求分解成更容易執行的任務事項。

比如一個遊戲的大系統，按照團隊工種可以分解成：策劃——系統設計、程式——程式需求、美術——美術需求。

按照具體執行人還可以細分為：數值設計(數值策劃)、規則及配置表(系統策劃)、UI互動設計(UI策劃)、戰鬥內設計(戰鬥策劃)、關卡設計(關卡策劃)；程式：底層框架設計(主程)、客戶端UI邏輯(客戶端程式)、伺服器協議邏輯(伺服器程式)、戰鬥內邏輯(客戶端程式)；美術：特效設計(特效師)、原畫設計(原畫師)、模型物件設計(角色建模師)、動作製作(動作師)、動畫製作(動畫師)、場景設計(場景)。

然後根據分解之後的事項，各個組開始分配人員，最好每一項任務分配一個人，如果硬要分配多人完成任務的話，一定要確定對這項任務最終負責的人。

執行任務的執行人要反饋真的確切理解了任務內容，以及完成任務之後要交付的成果。

這樣我們就得到了一份這個里程碑或者這個階段具體可執行的任務條目表，接下來就開始估期了。管理大師彼得德魯克提到有一類工作者叫做知識工作者，他們脫離了機械化的工作，比如1分鐘擰10個螺絲，他們學習新的知識，並且在工作中應用知識。

遊戲行業從業者就是知識工作者，學習-消化-應用，是知識工作者的工作模式。每個人的學習接受知識水平不一樣，有的人快，有的人慢，有的人天賦高，有的人天賦低。這也是造成了估期不準確的原因之一。

講價式估期(專家判斷)，可以保證一定的估期準確性，先讓執行人評估完成時間，然後再讓組長(專家)評估完成時間，雙方達成共識，這裡的關鍵是組長(專家)對於組員能力的瞭解程度，越瞭解估期越準確。

經驗式估期(類比估算)，也可以保證一定的估期準確性，以之前做過類似功能的完成時間為參考，對本次功能模組進行估期，參照越相似估期也就越準確。

組長對於團隊成員的培訓，也可以提高估期的準確性，知識經驗的傳承，統一的規範，通用的方法論，有助於團隊成員提高自身能力的同時，準確把握自身能力範圍。

擁有估期之後，就可以按照任務先後進行時間排序，任務之間有的擁有前後置關係，我們可以縷清這些關係形成甘特圖。甘特圖是可以清晰看出任務之間的關係及與時間的關係，在發生延期情況時，可以清晰看出受影響的關聯任務。

至此專案規劃階段算是告一段落了，這裡面需要著重記錄的資訊點是：明確的任務執行項、具體的負責人、準確的時間點。

進度管理

這部分比較程式化，跟進專案進度，強調任務的時間節點，強調什麼時間，完成了什麼事情。

每日的控制進度審查，一般分為每日站會(Daily Scrum)和每日工作總結。

每日站會(Daily Scrum)，基於小組形式的15分鐘小型會議，屬於敏捷開發中的一種管理方法，團隊成員只說今天做了什麼，將要做什麼，遇到什麼困難。每日站會的原則是高效溝通，減少一切可能浪費資源的行為。

每日工作總結，是一種資訊收集的方式，每天的結尾收集團隊成員今天任務的完成情況及遇到困難，是一種拉式的溝通方式。

每週的控制進度審查，一般為專案週會，一般安排在每週的開始或者結束階段，主要為各個組，程式、美術、策劃進行同步目前進度狀態，主要主旨為同步展示目前專案組的進度狀態，同步資訊。

估期節點審查，在估期的節點進行詢問此任務的目前狀態，主動管理、主動詢問、遇到問題解決問題、持續推進，保證任務可以持續的推進下去。這個節點可以是任務開始節點、也可以是任務執行中的關鍵節點、也可以是任務的完成節點，這個度需要在具體情況下具體分析。

這些審查的核心作用是，收集正確資訊掌握目前專案狀態，確切瞭解目前團隊的狀態才能更好的控制進度，管理進度，推進專案，有效決策。

有一些工具軟體可以很好的幫助專案組進行專案管理，像Teambition、JIRA、TAPD、Microsoft Project等等，各種軟體也擁有各有各的優點。

Teambition較為通用，有多種模版，滿足日常的專案管理需求，其基本思想加入了敏捷方法，可以把任務具象化，強調任務的流轉過程，主要結構為任務 + 執行人 。操作方便，視覺化程度高。

JIRA開源，團隊可以根據自己的需求來定製屬於自己專案的功能，滿足專案管理的基本需求，缺點是使用互動較為死板，操作視覺化程度較低。

TAPD是騰訊推出的專案管理工具，應用了騰訊特有的敏捷方法，如果想體驗騰訊敏捷方法論，可以嘗試一下。

Microsoft Project是微軟推出的專案管理軟體，功能強大，完全支援專案管理的需求，包括專案預算的計算，人力資源的分配整合，操作比較複雜，設定變數偏多，視覺化程度低。

這些軟體都提到了敏捷方法，在網際網路行業中，敏捷方法是較為推崇的開發方式。敏捷方法的核心是迭代。敏捷的需求承載體為故事，但是故事其實是一個朦朧的概念，需要通過頻繁變更迭代來讓故事變得清晰與明確。從這一角度來講其實很適合應用到遊戲開發中來。

如果流程偏離了原有的作用——收集正確資訊掌握目前專案狀態，最終變成了形式化，任何流於表面的形式化流程都是無效的。

總結

在專案管理中，時間、成本、範圍和質量等指標歷來被視為確定專案是否成功的最重要的因素(S-TQC)。這四個因素互相拉扯緊密聯絡在一起。

遊戲開發過程中，總會突然冒出大大小小的問題，這些問題可能會引起時間的增加、成本的上升、範圍的擴大以及質量的下降，專案管理或者專案管理流程或許就是為了避免這些問題、解決這些問題而存在的。

問題解決方法通常包括以下要素：

定義問題；識別根本原因；生成可能的解決方案；選擇最佳解決方案；執行解決方案；驗證解決方案的有效性。

高效的開發過程不可能一蹴而就，也不存在標準通用的流程規範，這些都是需要一步一步去迭代優化剪裁而成。當然還要團隊成員的集體配合磨合才能達到最優的效果。

希望可以借鑑剪裁專案管理體系中的知識框架來提高完善遊戲開發過程，如果有寫的不嚴謹或者思路不正確的地方，歡迎提出糾正。

作者：陸拾肆院
來源：遊戲陀螺
地址：http://www.youxituoluo.com/521048.html