作者：Hao
️遊戲策劃→研發PM
8年從業經驗，20+項目經曆
遊戲設計丨項目管理丨靈活教練
知乎專欄丨小紅書丨小宇宙
一、甘特圖與裡程碑規劃
在遊戲項目管理的過程中，随着團隊人數的增加，這時需要引入一些工具提升團隊工作效率，對齊目标，本文将介紹從如何使用Visio制作甘特圖和裡程碑規劃圖，幫助你高效管理項目。
Visio：WBS 及甘特圖
我們使用的工具是 Visio。作為 Office 官方提供的圖表工具，Visio 可以幫助我們輕松直覺地建立甘特圖、流程圖、組織結構圖等。
接下來，我們會從頭開始，制作一份WBS 工作分解後的甘特圖。
Step 1：選擇并建立甘特圖
在 Visio 中選擇“建立”後，你就會看到各個類型的模闆，你可以搜尋或者直接選擇甘特圖。選擇好樣式之後，你就可以點選“建立”，獲得模闆。
建立完成後，你會得到一個标準的甘特圖模闆（以基本甘特圖為例）。其中，橫軸是分解的各個任務，縱軸是我們需要展示的屬性。
Step 2：按照 WBS 工作分解，增 / 删任務
選中表區後，點選右鍵，就可以看到建立 / 删除任務的操作連結。這時，你需要逐條地錄入 WBS 工作項。
Step 3：拆解子任務（升 / 降級）
對于小型項目來說，一個層級的任務就可以滿足需求了。但對于比較複雜的項目來說，你還需要進行子任務的拆分。在 Visio 的甘特圖中，你使用降級來完成把任務降為子任務的動作，用更新來完成把子任務轉為任務的操作。
在具體操作時，選中任務之後（支援多選），點選右鍵，将其降級，這時，你選中的任務就會自動成為表格中上一級任務的子任務。子任務在格式上會有縮進，而主任務在右側的日期區域會擁有辨別。
Step 4：配置任務屬性（如資源名稱、持續時間等）
在完成任務拆解後，我們就可以開始配置任務屬性了。
在制作甘特圖時，我們希望重要的資訊能夠得到充分的展現。是以，除了基礎的任務名稱、開始時間、結束時間等，我們往往還會添加一些屬性，比如資源名稱、完成百分比、持續時間等。
另外，除了計劃的時間，你還可以添加實際開始 / 結束 / 持續時間，來記錄項目的完成情況。
在選中表區之後，可以點選右鍵，插入列并選擇想要插入的列類型。Visio 也支援使用者自定義的字段，還是比較靈活的。
Step 5：設定任務依賴關系
在項目規劃中，我們需要厘清任務依賴關系，并借助連結任務功能，來完成在圖上的展示。
在具體操作上時，你可以參考下表。在選中有依賴關系的兩個任務之後，右鍵選擇“連結任務”就可以了。如果你要取消依賴關系，可以點選“取消連結任務”，也可以在日期區域，直接選中任務間的連線并删除。
三個區域的配置完成後，我們的甘特圖就比較完整地呈現出來了。其他幾個甘特圖模版的具體操作步驟也是類似的，隻是最初的模闆與樣式有略微的不同，你可以根據自己的喜好進行挑選與調整。
到這裡，一個甘特圖就做好了：
Visio：裡程碑規劃
在任務規劃期間，除了 WBS 工作分解及甘特圖，我們還需要一個可以反映各個階段時間節點的整體裡程碑規劃。
裡程碑規劃圖的繪制也可以在 Visio 中輕松做到，同樣也是 5 個步驟。
Step 1：選擇并建立日程表
首先，你要搜尋日程表模闆，并且選擇合适的日程表模闆，然後就可以開始我們的裡程碑制作了。
Visio 主要提供四種模闆：日程表（空白畫布提供日程表形狀）、塊狀日程表、垂直塊狀日程表和展開的塊狀日程表（用于展示日程中某一部分的詳細資訊）。
Step 2：選擇日程表形狀，繪制時間線
需要注意的是，日程表的使用和甘特圖有所差別，日程表主要是通過使用 Visio 工具中的日程表形狀來完成展示。拖動下圖中的形狀到畫布，并進行相應屬性的配置。
除了模闆中提供的時間線，我們還可以自行拖拽選擇三種：圓柱形、線形和塊狀。
将圖形拖拽到畫布以後，會自動彈出配置日程表的選項。在這些選項中，你可以選擇時間段與刻度，這時，基礎的設定就完成了。
Step 3：設定裡程碑時間
接下來，你需要将裡程碑和間隔形狀拖拽到畫布上，進行日期的配置和形狀的調整，以标記重要日期。
可選的裡程碑形狀有線形、菱形、針形、雙三角形、X 形、三角形、圓形和正方形等，你可以根據自己的使用習慣與定義來進行使用。
當然，需要調整時，你可以右鍵配置裡程碑的屬性，更換裡程碑類型。
Step 4：設定時間間隔
除了特殊的裡程碑節點外，我們有時候還會标記一些重要的時間間隔。你可以選取左側形狀中的間隔，把它拖拽到時間線上，并進行間隔的屬性設定，這時，就可以完成時間間隔的标注了。
Visio 提供的時間間隔類型有方括号間隔、花括号間隔和塊狀間隔。
Step 5：增加今日标記
在項目的程序中，今日标記也是一個非常實用的功能。你可以選擇“自動描述位置”，在項目進度的檢視中，也可以把它作為一個标簽，來進行進度的觀察與把控。
到這裡，一個完整的裡程碑規劃圖就做好了。
二、PMP認證攻略
要不要去考 PMP？PMP 認證的含金量怎麼樣？老實說，我一向認為，認證考級不是最終的目的，千萬不要舍本逐末，為了證書去考試。讓考級最大程度地幫助自己提升專業技能，才是最重要的。
為什麼要考 PMP？
在決定投入精力考證之前，我們要先搞清楚，為什麼要考 PMP？
PMP®認證近幾年在國内的前沿行業很受歡迎。截至 2019 年 10 月，全球 PMP 有效認證人數為 99 萬。其中，中國的 PMP 認證人數占總人數的三分之一。
PMI 的研究報告預測，2027 年，中國的項目管理職位空缺将達到 4600 萬個。未來在中國，項目管理崗位将成為最熱門的職業之一。
PMI 的中國代表曾經去過騰訊、網易等一線網際網路公司訪談調研。他們想要了解，PMP 認證在中國推廣了這麼多年，它的價值到底在哪裡。
調研小組從多個方面進行了探讨，最後得出的最重要的一條結論就是，PMP 認證的普及為我們創造了項目管理專業的共同語境。比如，我們會自然地讨論“根據目前的 WBS 工作分解，計劃中的關鍵路徑是什麼”“風險管理計劃要怎麼做”，等等。
不要小看這個标準術語帶來的好處，統一的共同語境為管理者正确地認知項目管理的作用、為項目運作建立良好的組織環境，都做了非常好的鋪墊。
實際上，PMP 的認證過程也是我們學習并掌握一門項目管理的國際标準語言的過程，就好比是學會了另一門英語。
回到很多同學關心的問題上：“PMP 認證有用嗎？值得考嗎？”其實，這些問題背後的疑惑是：“考了這個證，會給我帶來什麼？升職加薪？還是增加面試和錄用機會？”
我想說的是，對于想嘗試轉崗項目管理的同學來說，PMP 認證的确可以作為“敲門磚”，在一定程度上增加你擷取專業面試的機會。但是，在大多數企業中，PMP 認證隻是一個基礎項，決定你是否被錄取的，還是你的實戰經驗和實戰水準。再進一步去看的話，還有建立在實戰經驗之上的、你對專業方法論的掌握和應用水準。
是以，學習中最怕的就是本末倒置。PMP 證書的含金量不在于證書本身，而是在這個準備考試的過程中你所付出的大量努力，以及你把理論架構和親身實戰融會貫通之後，你的自身能力得到的提升。
是以，我建議你在具備一定的實戰經驗之後再去系統化地學習這門課程。否則，對你來說，考這個證無異于超大濃度的理論灌輸加知識記憶。如果大量的知識無法被消化和吸收，它們就會成為你的“知識障”，屏蔽你進行自我思考和嘗試的動力。
如何有效備考 PMP？
如果你已經具備了實戰經驗，決定要考 PMP 了，就要提早了解一些 PMP 認證攻略，不打無準備之仗。
接下來，我會介紹一下備考 PMP 的幾個關鍵步驟。
第一步：确定考試的目标時間
PMP 每年有 4 次考試，分别在 3 月、6 月、9 月和 12 月。确定要考之後，你要做的第一步就是安排合适的考試時間，給自己錨定一個目标點。
怎麼确定什麼是合适的時間階段呢？
首先，你要確定至少完整地經曆過兩到三個項目周期，從啟動、規劃、執行、監控一直到收尾，自己有切身的實踐體會。
其次，避開工作高峰期，選擇自己相對空閑的季度。這是因為，要考 PMP 的話，你需要投入大量的時間和精力，至少要留出三個月的備考期。對于這一點，你要提前做好準備，因為它真的會占用你所有的業餘時間。
必須要提醒你的是，你一定要提前确認 PMP 認證官方要求的報名條件。實際上，你并不一定需要有明确的項目經理崗位，隻要有相應的項目經驗，并且達到足夠的時長積累，就可以報名了。
第二步：完成中英文報名
PMP 考試屬于國際認證，報名需要兩個步驟，先進行英文報名，後進行中文報名。确定好考試日期之後，你至少要提前 3 個月完成英文報名，提前 2 個月完成中文報名。
為什麼我要把“報名”這條單獨列出來呢？因為我想提醒你，英文申請全年都可以送出，沒有時間限制，但是有 5——7 天的稽核時間，稽核成功後，賬戶有一年的有效期。如果英文申請沒有通過，是不能完成中文報名的。是以，我建議你盡量在中文報名開始之前完成英文報名，以不耽誤考試。
第三步：課程學習和備考
PMI 規定，報名考生需要具備 PMI 授權的教育訓練機構所頒發的 35PDU 教育訓練證書。一般來說，各類教育訓練班的開班時間通常會至少提前三個月，分别在 12 月、3 月、6 月和 9 月。
總體來說，教育訓練班通常分為線下和線上兩種。線下教育訓練的話，學習的互動感更強，建議你盡量挑選你所在城市的正規教育訓練機構，線下組隊形成學習小組，互相督促，一起學習，效果會更好。
時間受限的同學也可以選擇線上教育訓練的方式。我當時就是選擇的線上教育訓練，因為時間更靈活，随時可以補課，對于自律性好的同學來說，效果是一樣的。
接下來，我們再聊聊備考 PMP 的學習材料，其實主要就是《PMBOK 指南》。這本書很經典，但即便我現在讀起來，都感覺并不輕松。全書有 600 多頁，而且大多是理論方法的描述說明，很容易讓人望而生畏。
為了幫助你達到更好的學習效果，我結合我的經曆，為你梳理、總結出了三步學習法。
1. 通讀
對于十大知識領域五大過程組來說，不同階段的各種方法浩如煙海，這第一步就好比是在知識的森林裡，到處逛一圈，先做個路标。
第一次閱讀時，你可以單純地浏覽一下，别求全部看懂，也不要追求速度。在讀的過程中，建議你結合自己的項目經驗，随時做批注，在書上畫圈圈，把你感興趣的内容或者暫時不了解的内容都先标記下來。
2. 精讀
參加教育訓練期間，你要根據老師的講解和講義，并結合自己的項目經驗和問題，重新檢視并深入了解每個概念，建立起對體系結構的清晰認知。
在這個階段，我建議你跟着教育訓練進度，逐個精讀這本書的每個章節，特别要留心那些跟你在實際工作中差距比較大的部分，以及之前做好的路标。
要真正把教育訓練老師當作你的資源，遇到問題多思考、抓住時機多提問，在弄懂方法原理的同時，更要去主動思考，你如何将這個學習引入自己的工作。隻有這樣去學的話，你才能把枯燥的考級過程變成一個很好的實戰能力提升機會。
3. 記憶
在考試之前，你要按照老師劃的重點和考點進行必要的記憶，并完成足量的刷題練習。一般來說，教育訓練機構在考前都會為你準備包含記憶點及重點題型的小冊子，内容每年會有一定的翻新。
這個階段的重點是，多總結學習和做題過程中遇到的問題，回顧書上的常見考點，反複加深了解。對于那些重點、難點，你要刻意去背誦下來。在考試之前，你要對熟練掌握各個知識點，并達到融會貫通的效果。
以前，我自己在學習的過程中，往往會重了解、輕背誦，特别是對這種應試型的死記硬背，我一點也不“感冒”，不自覺地總會忽視。後來我發現，經典的背誦式學習也是一種科學的學習方法。
舉個例子。小時候，我們總被要求背誦詩文，可我當時并不了解，甚至還有些抗拒。但是，那些反複背誦下來的詩就好像刻錄進了我的深層意識。在我遇到某些情景時，它們就會自然地跑出來，時常讓我覺得驚歎不已。從死記硬背到真正了解詩歌在表達什麼，需要時間和閱曆。
在 PMP 的學習中，有很多東西會超越你目前的經曆。如果你實在無法了解，那就允許自己先囫囵吞棗，考前把它們先背下來，耐心地等待它們自己醞釀、發酵。總有一天，當你遇到合适的情景時，這些記憶就會跳出來，真正地在實戰中幫助到你。
項目管理進階之路
除了拿到 PMP 認證，有些同學還想在項目管理之路上繼續進階，甚至已經在考慮轉型去做專業的項目經理了。這個時候，你需要考慮哪些因素呢？
首先，一旦涉及到職業選擇，最關鍵的一點就是，盡可能不要讓自己被很多外在的因素所左右。你要回歸自己的内心，問問自己為什麼要做項目管理。
不知道你是否有下面這兩種心态。
心态一：
“Leader 安排我做項目管理，可能是看我能擔事吧，就把越來越多的事，都往我這裡塞。”
如果你目前處于這個階段，我建議你先不要着急進階，而是留些空間給自己，先想好，如果沒有 Leader 的影響和要求，你自己個人的決定到底會是什麼。
如果你發現自己的答案也是要做，那就調整心态，變被動為主動，為自己的職業道路負起責任；如果在嘗試之後，你覺得自己确實不适合做項目管理，那就主動去和你的 Leader 溝通，把精力用在更适合你發揮專長的領域。這對公司來說，也是更好的選擇。
心态二：
“程式員這個工種，可能沒法幹到老，我年紀也不小了，得提前為自己找條出路。”
主動為自己規劃未來，這樣的做法值得肯定。但是，這種心态最大的問題是，如果說程式員這個崗位不适合你一直幹下去，那麼，你如何确定項目經理就适合你呢？
實際上，想要确認這個職業與自己的比對度，你需要注意的是，性格内向或外向并不是影響轉型的決定性因素。外向者在資訊擷取上會更有優勢，但内向者普遍擁有更加敏銳的感覺能力。對成為項目經理而言，這兩種性格各有優劣，不分伯仲。那麼，到底該如何确認呢？
答案其實很簡單，就是看這項工作是否能夠激發你更大的熱情。程式員和項目經理這兩個職位的最大不同就在于，前者研究的是機器，後者研究的是人。如果說，程式員研究的是“一堆代碼在一起，如何運作會更好”，那麼項目經理研究的就是“一群人在一起共同做一件事，如何運作會更好”。
要想成為一名專業的項目經理，你需要對人有敏感度，并且要發自内心地認為研究人比研究代碼更加有趣。這也是我自己雖然在這條路上遇到了很多挑戰，但依然樂此不疲的原因。
除此之外，在擁有熱情的前提下，經驗背景的差異都是可以用時間彌補的。隻要你堅持将學習與實戰相結合，不斷在實踐中整合自己的經驗，你就一定會不斷精進。
總結
實戰永遠是我們不變的基調。隻有你把 PMP 的認證過程當作對自己的一次系統化的理論充電，讓實戰經驗與理論架構充分碰撞，你才能真正地吸取 PMP 給你帶來的真正價值。
三、項目複盤
複盤原本是圍棋術語，是指每次博弈結束之後，雙方棋手把剛才的對局複演一遍，分析對局當中得失的關鍵，是提升自己棋力的好方法。其實，複盤是對思維的訓練。通過複盤，當類似的局面再次出現在你面前的時候，你就能夠快速地預測接下來的動态和走向，并且更好地應對。
而項目複盤會，可以說是項目團隊有意識地向過去的行為經驗學習的過程。在項目或裡程碑完結之後，項目經理會組織召集項目成員，一起回顧一下，在項目的整個曆程中，團隊做對了哪些事，做錯了哪些事，再來一次，如何做得更好，借此把項目行進過程中産生的集體智慧沉澱下來。
但是，現實情況經常是，項目一個接一個地做，忙上線、忙變更、忙返工，哪有時間坐下來複盤？又有多少複盤會，是為了複盤而複盤，逐漸地流于形式，成為了可有可無的擺設？除此之外，還有很多複盤會，成為了追責者的工具，除了鍛煉出花樣百出的各種甩鍋技能之外，留下的隻有“一地雞毛”。
由此可見，要想做好項目複盤，并不是一件容易的事情。今天，我們來看一看，如何做好項目複盤，以及如何通過複盤去培養團隊的持續改進能力。
複盤會的基調設定
我們都知道複盤很重要，但實際上，在複盤會之前，想清楚我們複盤的目的，設定好複盤的基調，其實更為重要。
我曾組織過一個複盤，叫作“坑爹功能”大搜羅。參與複盤的十多位同學，在現場寫了好幾頁紙，滿滿當當地羅列着我們曾經做的、卻沒什麼人用的功能。實際上，隻有當大家真正攤開不太願意面對的真相，去認真思考背後的深層原因時，我們才能共同進入真正的集體反思區。這樣坦誠地直面問題的複盤，才能促發有意識的集體學習。
要想讓參與者真正進入集體反思區，會前就要設定好開放的複盤基調。其實，我們每個人都可以在自己所處的環境中，看到各種各樣的問題。如果複盤是出于追責，那麼在會議剛開始時，大家就可以迅速地感受到，這樣一來，每個人都會小心地避開自己的問題，轉而去說别人的問題，這樣的複盤就失去了意義。那麼，如何設定開放的基調呢？
在會議剛開場，就要展示出自己的開放與坦誠，給複盤會奠定基調：這次複盤不是來挑問題的，而是為了找到問題的根源并改進的。在那次複盤會上，項目負責人特意講了自己半年來的深刻反思，這就帶動大家敞開心扉，直面問題。那次會上，大家自發地找到了在各個環節有效避免無用功能的方法。會議結束以後，這個部門還發起了一項“整風運動”，從增強使用者意識的講座，到使用者調研方法的教育訓練，再到激勵與考核制度的挂鈎，讓複盤會反思的成果，逐漸滲透到了每個人的日常工作中。
複盤會的會前準備
除了設定基調，你還需要充分的會前準備。在複盤會之前，你要去梳理整個版本的曆程，包括項目或裡程碑的各項資料和資訊、目标和達成結果、進度計劃、需求變更、品質狀況等，這些是客觀資料的總結。同時，你還可以提前收集這個版本期間，團隊滿意度的問卷調查，為複盤會引入更多主觀的輸入。
其實，複盤會的基調設定，以及會前的準備工作，在開會之前，就很大程度地決定了複盤會的效果，你一定要特别留意。
了解了這些之後，我們就來看看複盤會的流程。
複盤會的流程
複盤會的流程，其實并不複雜。在實戰中，我總結出了一套高效的複盤流程。
- 現場回顧總結項目 / 裡程碑的整體概況，包括目标達成情況、進度計劃及變更情況、需求變更情況、品質報告等項目曆程記錄。
- 與會人員用便簽紙寫下項目過程中做得好的以及做得不好的 3 個點，按照項目的各個環節分類，分别貼在白闆上，確定大家的意見能夠充分、自由地表達。
- 在白闆前逐條 review 大家的意見，共同發現問題，并有針對性地展開讨論。
- 對大家總結出的好和不好的點，進行集體投票。
- 由項目經理整理投票結果，對于做得好的環節，總結經驗；對于做得不好的環節，當場讨論出改進方案
我們來看看一次項目複盤會的投票結果：
無法促發行動的複盤，說得再好都是空談！一開始開複盤會，大家會期待，解決的問題越多越好，但焦點增多之後，哪個都是蜻蜓點水地過一遍，哪個都沒改徹底。下次再開會的時候，大家發現之前回報的問題依然還在，那誰還有動力繼續提問題呢？
是以，改進措施一定要落地，重點行動不要太多，一個就夠了！如果每次複盤聚焦于改進項中的 Top 1，確定改進措施真正落地，長期堅持下去，就會促進持續的能力提升。同時，複盤的次數也不要太多，你并不需要每個版本、每個疊代都例行公事地去做一遍，確定每個季度有一到兩次裡程碑複盤，可以完整地對項目做系統化的梳理，達到真正的落地效果，才是更重要的。
打造團隊持續改進能力
其實，項目複盤不隻是一次會議，它更應該成為團隊持續改進的推動力。那麼，怎樣才能讓一次成功的複盤發展成為複盤文化，激發團隊自主地持續精進呢？
實際上，想要讓團隊進入自發改進的正向循環，你需要更好地激發團隊的主人翁意識，讓團隊成為複盤的主角，而不是你。最重要的是，你不僅要關注事，還要關注人。
另外，越是困難時期，越是塑造團隊能力的大好機會。在團隊遇到重大困難時，你也可以及時組織一場複盤會，深度關注和調整個人的狀态。我就曾經試過讓每個人畫出自己進入這個項目組以後的狀态變化曲線，跟大家分享自己的“高光時刻”和“至暗時刻”。在業務低落期，這樣的複盤會會成為一個重要的轉折點，讓團隊的力量得到深度聚合。
這些對人的關注，都會讓複盤會超越問題解決的層面，在推進事的同時，促使團隊自發地推進問題的解決，并把經驗内化下來，進而不斷提升團隊的持續精進能力。
總結
好了，讓我們對複盤做個小結。其實，當人們在說複盤時，往往會把焦點放在複盤會本身。但我卻認為，決定複盤成功與否的關鍵，不在會議本身，而在于複盤會的一前一後兩個環節。
複盤會前，複盤基調的設定是否開放，複盤會前的各項準備是否充分，對于複盤會的效果非常關鍵。組織一個複盤會本身并不難，難的是在複盤會後，持續跟進這些反思，落地為切實的改進措施，讓團隊真正看到效果，進而打開團隊持續改進的正向循環。
最後，我建議你認真地做好一次複盤，每次複盤後聚焦一個改進點。再提醒你一句：聚焦點别太多，一個就夠了！
四、研發工作流
1.0——研發階段
研發流程在遊戲開發的過程中是非常重要的一環，遊戲研發流程，可以簡單拆解為三個子流程——内容生産工作流和美術需求工作流。
内容生産工作流
這裡的内容生産工作流主要以玩法和功能産出為主。
遊戲本身是一個個功能組成的産品，它之是以好玩，是因為有至少一個核心的玩法，但是一個玩法并不足以支撐起一款遊戲，可以圍繞玩法建構系統，多個系統結合起來，才能稱之為遊戲。
遊戲和其他網際網路産品一樣，開發過程也是通過完成一個個功能需求而逐漸成型的，這裡簡單介紹單個功能需求的全生命周期：
功能需求生命周期流程圖
PM參與其中的時間點标記了出來，可以看出一旦需求評審通過，PM就要參與到這個功能需求中去，直到ta被驗收通過。
圖中的每個環節雖然隻有簡單的幾個字，背後都需要有一套完整的流程支撐，讓每個團隊成員知道在什麼時候應該做什麼事，最大地降低delay風險。
美術需求工作流
在功能開發的過程中，美術資源往往是沒有全部到位的，這時可以使用尺寸相同（至少是接近）的白模代替。用來驗證功能的完整性。
如果說單個需求主要是以程式視角出發的話，美術其實是在特定時間點加入進來的，往往玩法功能在設計的早期就需要美術協同參與，一方面是提供思路參考，另一方面也是提前思考概念設計方案，確定美術設計先于程式開發進行，在功能開發完成後替換成品美術資源，是比較合理的開發模型。通常美術需求的生命周期的流程圖如下：
美術需求生命周期流程圖
結合内容生産和美術需求，整理了一個簡化版本的研發工作流：
2.0階段——上線後
項目上線之後，通常會制定一系列更新計劃，這時1.0模式的開發模型已經不能完全滿足需求。
為了維護線上版本的穩定，通常隻會在某個開發版本的功能全部測試通過後才會推至線上，是以此時需要至少兩個開發分支——線上版本和開發版本。
最簡雙版本開發模型
上圖是一個最簡版雙分支開發模型圖，從圖中可以看出，線上版本是最長那一條直線，在A點拉出一個資料片1的開發分支，在B點資料片1完成時合入線上版本。
需要注意的是在A→B階段線上版本理論上是不更新的，期間如果有修複bug，則需要同步至資料片1的分支，確定在B點合入時不會出現沖突。資料片2階段同理。
無論是研發中還是上線後，流程管理都是關鍵的一環，當中有很多坑，往往需要踩過一次之後才能有更深的感觸，上面列出的都是最最簡化版本的流程示意，僅僅是介紹全流程的概念。
更深的内容，需要在實際工作中逐漸摸索。
五、制定流程
PM在日常工作中最繞不開的話題，就是“流程”。
“做xxx的流程是什麼樣的？”、“怎麼給xx提需求？”、“我送出了xxx之後還需要做什麼嗎？”...
其實大家工作一段時間之後，對正常工作流都會有一定的了解，你可能會通過觀察或其他方式學習到公司的基本規則。但真正令人頭疼的往往是基本規則之下的具體執行方式，因為其中可能有大量的模糊地帶，這些模糊地帶有時會造成一些跨部門間的沖突。PM的重要職責之一就是消除這些模糊地帶，讓每個角色都明确知道自己的責任範圍。
在上一篇文章中，我們講了大緻的研發工作流。今天我們嘗試着把工作流中的每一步拆分得具體一些，明确每個角色在不同時間點應當承擔的職責。
比如在内容生産工作流的第一步“需求設計”中，
看似簡單的四個字，其實需要回答一系列問題：
- “它的設計目的是什麼？”（如增加留存）
- “使用什麼手段實作這個設計目的？”（如設計每日寶箱系統）
- “這個手段可以拆分成哪些子子產品？”（如活躍可以提升寶箱獎勵）
- “每個子子產品的功能和作用是什麼？”（簡單的系統可能無需回答這個問題，比如上面舉例的每日寶箱系統）
- “實作這些功能需要哪些角色支援？”（如需要UI設計領獎界面、需要前端實作xxx部分、後端實作xxx部分等）
- “如何驗證功能上線後是否達到預期？”（如先灰階測試一部分使用者，檢視資料差異，沒有灰階條件的也可以用埋點做）
- ...
上述問題存在的意義其實是希望你真正想清楚自己的設計，最終達到自洽，自己信服的設計才有可能讓别人信服，如果被程式/美術同學随便提幾個問題就問住了，你的專業性會被懷疑。
但需求設計說白了是一件可以獨立完成的任務，隻需要一個文檔模闆就可以解答上面那些問題，更有挑戰性的部分在于需要跨部門配合的任務中，接下來我們嘗試以一個3D遊戲的皮膚商城界面為例梳理其中可能涉及的流程。
假設皮膚商城界面開發需要四個子產品：2D、3D、用戶端和音效。
每個子產品都有各自的開發流程，當需要跨部門協作時，PM需要統籌這幾個部門的開發工作流，規劃時間節點， 確定大家都在同一個軌道工作。
下圖是一個可能的融合後跨部門開發流程圖案例：
雖然流程圖可以直覺地看出各部門的工作順序，但是每個節點工作的具體内容，則需要通過流程表格呈現，表格中需要明确各個時間節點，每個角色需要做什麼事，結果是什麼等等。可能是下圖這樣的表格：
UI流程表格
不過制定流程并不是越詳細越好，找到适合自己團隊的精細程度更重要。
制定流程本質上是為了明确每個角色的責任邊界和解放PM的生産力，畢竟團隊大了之後，可能會管不到每一個需求，白紙黑字的文檔比口口相傳的效率更高。
六、制定計劃
裡程碑與周版本
裡程碑
遊戲研發分為多個階段，每個階段都有比較重要的節點，這些節點被稱之為“裡程碑”。
在項目的MVP階段，裡程碑可能是關乎生死的MVP評審，通過就立項，不通過就砍掉。而在項目的營運期，裡程碑可能是一個有一個的玩法版本和活動，為了拉新，為了促活，為了讓遊戲的生命周期得以不斷延長。
是以，裡程碑計劃，是遊戲生命周期裡的一系列重要規劃節點，是項目團隊運作的一個個進度目标。
研發全流程
對于MVP階段，裡程碑計劃需要着重打磨核心玩法，展現出遊戲的特色。而對于α開發階段，則應繼續着力于提升核心玩法的完成度。而在β開發階段，一般要開始玩法鋪量、完善周邊系統和增加新手引導。到了管道測試和産品上架階段時，需要開始考慮和發行、營運等部門的合作。
周版本
有了裡程碑計劃之後，在執行的過程中，還需要将裡程碑計劃細化到每一個周版本計劃，即每周完成一個可以體驗的無阻斷遊戲版本。
通常團隊會将周中設定為版本日，這樣能避免周末加班。到版本日時，當周版本的單子需要通過測試，才能實作我們定義的“可以體驗的無阻斷遊戲版本”。
周版本流程
舉一個裡程碑計劃轉化成周版本計劃的例子。
假設S項目需要在1月1日進行CE測試。
首先在研發側，将本次測試的版本内容拆分為疊代功能和新增功能。獲得這些資訊需要和策劃溝通，同時考慮開發人力，得出受到認可的版本内容。然後考慮合作部門的需求（如發行營銷），最後增加一周組内體驗的時間確定版本品質。
接着将裡程碑範圍拆分為一個個具體的任務，如裡程碑範圍其中之一為增加多人互動玩法，拆分後的任務為具體哪些玩法。如圖所示
裡程碑範圍拆分
拆分出所有任務後，為每一個環節進行估時，這需要PM和每個負責制作的同學确認。
S項目總體計劃密集，很多任務并行開發，PM在評估各時間節點後給出的大緻開發排期為：
- 策劃寫PRD 1——2周；
- PRD評審、UX、UI設計等1周；
- 程式開發2——3周；
- 測試1周
接下來需要觀察每個環節的開始時間。特别是需要留給策劃足夠的時間寫PRD，保證後續任務能順利開始。
個人的高效不一定能帶來團隊的産出高效。PM在細化周版本計劃的時候，不應局限在當周每個團隊成員工作量是否飽和。而應該從裡程碑計劃目标出發，以能否達成最終目的為前提考慮問題。
制定開發計劃
我們已經知道遊戲研發有不同的階段，雖然不同階段的項目有很大的差異性，但制定計劃的思路是一緻的。包括：整理需求、拆分需求、排優先級、估工時、人員分工、确認上下遊排期等。下面我們就以MVP階段為例介紹制定開發計劃的方法。
MVP階段的特點是充滿了不确定性和時間比較緊。不确定性是指需求可能頻繁變更，技術實作方式也是一樣。此外還有其他例如團隊磨合不夠和人力不足等。在這種人力不足、時間緊且需求未确定的情況下，做計劃時需要有一個明确的最小需求範圍。
比如，某個非對稱競技玩法遊戲的MVP，最小需求範圍是2個職業和對應的技能，1個場景，3種場景互動道具。
确定最小需求範圍後，聯系對應的美術、開發、QA等同學預估工作量，如果發現工作量超出可承受範圍，則需要縮減範圍或更改制作方式。在這個階段可以多考慮使用公司美術庫内風格接近的資源。
針對需求頻繁變更而導緻工期難以預估的情況，可以考慮将版本周期從通常的周版本縮減為雙日版本或日版本。縮減版本周期能讓版本内的需求進一步明确，有利于進行需求拆分和預估工作量。
日版本計劃圖
雖然MVP階段需求和明确對标的産品還不确定，但是評審的時間是确定的，是以我們通過倒推的方法得到開發疊代的時間。在評審之前，最好提前一周停止新功能開發，用于回歸測試和修bug，防止最後階段出現嚴重阻斷bug影響評審。
在遊戲研發過程中，主要采用漸進明細的靈活開發方式，根據需求靈活制定計劃是關鍵。
七、範圍管理
遊戲每次版本更新時，通常會對外釋出一份版本更新文檔，文檔裡描述了本次更新的變化，比如新增了某個玩法、修改了某個怪物的數值等。這一份文檔的全部内容，就是這個版本所包含的“範圍”。
項目範圍是指為了傳遞産品必須完成的工作集合，包括具體的業務需求（比如遊戲中有哪些功能玩法，包含哪些美術表現等）和傳遞承諾（比如傳遞時間，遊戲完成度等）。
對範圍的管理通常分為四步來做，如圖所示：
範圍管理
分析範圍
分析範圍是指确定項目要做什麼，不要做什麼，确認之後開始拆分需求，把所有想做的内容拆成一個個獨立可落地的需求，然後進行優先級排序。每個需求都應該有具體的傳遞标準，用來定義這個需求“做完了”，比如遊戲幀率達到xx幀、支援最大同屏人數xx人、特效數量xx個等。
确認需求之後，策劃開始整理需求文檔，需求文檔的作用是對需求進行精準定義，其中部分内容需要和上下遊環節的幹系人讨論決定。一份合格的需求文檔，至少需要回答這五個問題：
- 需求的使用場景：描述需求的具體使用場景，能夠幫助相關方了解需求的背景和特點。如項目需要一批美術資源驗證某個玩法是否可行，這些場景最終不會被使用，那麼美術資源完成度過高反而浪費成本。
- 需求的功能描述：描述需求想要實作的效果。
- 需求的邊界條件：特殊情況的說明，如弱網、頂号等。
- 需求涉及的部門：需求需要哪些部分支援，如UI、動作、特效等。
- 需求優先級
可以根據以下幾點協助判斷優先級。
- 投産比：低投入高産出的需求優先級更高
- 需求來源：來自高層管理者的需求需要重點考慮
- 需求依賴關系：主要考慮需求依賴的上下遊能否提供足夠的支援確定需求實作
定義範圍
需求文檔整理好後，接下來會通過需求宣講會的形式來定義範圍，參與者在宣講會上對需求文檔提出各自的疑問。宣講會的目的是讓所有參與者對需求的了解達成一緻，最終策劃将共識統一整理到需求文檔中，産出最終版需求文檔。
定義範圍的核心是對需求進行拆解，目的是更準确的估算工作量。
常用的方式是按照需求環節拆分。以角色需求為例，可以拆分為概念原畫、模型、動作等，如果還是難以估算工作量，就對其進一步拆分，模型拆出白模、高模等中間環節，直到能比較準确的估算工作量為止。
角色需求拆分
拆分需求時需要注意：
- 每一個拆出來的需求節點，都要有明确的責任人；
- 拆分的顆粒度根據需求具體情況決定，對于複雜、跨部門多的需求，需要拆的更細；
- 漸進明細，對于即将要做的需求應該拆的更細一些，對于未來的需求，沒有必要一上來就把它拆得很細；
- 拆完檢查確定沒有遺漏。
控制範圍
項目開發的過程中，不可避免的會遇到各種各樣的變更情況，控制範圍就是管理這些變更，確定所有變更都經過同意的變更流程，防止範圍蔓延。
- 判斷需求是否應該變更時，除了關注需求本身，也要關注與之相關聯需求的情況，綜合判斷對項目的影響程度，再得出結論。
- 當需求發生變更時，也要給對應需求的幹系人同步需求變更的原因和後續計劃。
- 已确認的變更，對應的文檔也應該更新。
驗收範圍
驗收範圍就是檢查已完成的成果，目的是確定項目暗示保質保量完成，并獲得重要幹系人驗收确認。
驗收形式通常是周版本、sprint review、月版本等。
驗收過程可以是展示資源、視訊示範、真機體驗等，過程中記錄幹系人的建議，驗收會後，項目組成員統一評估哪些建議需要納入後續版本計劃中。
八、資料分析
在項目的整個生命周期中，風險無處不在，PM的重要職責之一就是對風險進行監控和處理，而資料分析就是一種項目監控的方式，它能幫助PM及時發現和應對風險。在和項目幹系人溝通時，資料分析能幫助PM展示客觀準确的項目資訊，提升溝通效率。
在PM的日常資料分析中，主要關注項目管理四要素：範圍、時間、成本和品質，這四者共同組成了項目管理鐵三角
項目管理鐵三角
具體可以分為以下幾個方面：
1. 品質：如代碼品質、包體品質等
這裡的品質是指QA負責的代碼包體品質，監控品質是通過盡可能暴露遊戲中的潛在bug并修複，以此提升遊戲的整體品質，是以單純追求bug數量少是不可取的，因為bug少可能是因為缺陷沒有被發現。
（ps.如果一段時間内品質标準相同且bug發現率一緻，可以用bug數量多少代表整體品質好壞）
2. 範圍：如開發的進度等
可以用分角色分階段的統計方式來記錄準确的進度，也可以按功能子產品記錄整體進展是否符合預期，這兩者的顆粒度不同，實際運用時按需實施。
3. 時間：如開發的速率等
記錄方式和樓上的範圍一樣，主要關注點在于團隊開發進度是否按計劃完成，團隊整體效率是否正常。
4. 成本：如人力分布情況等
在人力資源中，PM需要對現有和未來視野内可能出現的人力風險進行及時的跟進和處理，主要關注：
- 目前總體人力是否足夠完成裡程碑目标
- 團隊成員比例是否存在瓶頸，如某個角色人數過少導緻上下遊都得等的情況
接下來通過一些案例應用日常工作中記錄的資料。
案例1 項目開發到了一半，加班嚴重，團隊士氣低落，每天都有人請病假或事假，你是PM，希望和團隊leader溝通對應的解決方案，應該如何溝通？
回答1：“最近大家連續加班，士氣低落，效率也不高，要不要考慮取消周日的加班計劃？”
回答2：“根據最近的開發資料顯示，雖然需求都進了周版本，但是和以往同期的版本相比，嚴重阻斷bug增多，算下來，加班的時間基本都投入到修bug上了，整體進度和以前差不多，是否考慮減少加班，讓團隊調整好狀态以提高效率，回到以前的狀态？”
回答1的結論籠統和主觀，缺乏說服力。
回答2中PM通過整理現有開發資料發現加班無法提高團隊産能，向團隊leader展示客觀資料，提出适當減少加班調整團隊狀态，會更容易達到溝通的目的。
在和團隊leader溝通類似問題時，需要站在對方立場思考“團隊為什麼要加班？團隊leader的需求是什麼？” 加班是為了加快産品進度，但是我們通過資料統計發現，加班帶來的絕對效率并沒有增加，甚至降低了，也就證明了目前通過加班無法實作預期。而且加班還會帶來團隊的負面情緒，對團隊穩定性産生影響。
案例2 遊戲下個月就要開啟測試了，但是剩餘的需求和bug數量還不少，團隊leader比較關注這次測試，向你确認進度，你該如何回答？
回答1：“（我覺得）做不完，一直有臨時需求加塞，原計劃上周完成的單子也有delay，這次測試有風險。”
回答2：“從這次測試比較重要的兩個子產品：角色和副本的進度來看，開發預估還需要2個月才能全部完成，趕不上這次測試規劃的時間節點，風險很大。”
回答3：“根據我們的測試計劃，想要按時測試，需要提前2周給到QA進行測試，也就是說隻剩2周的功能開發時間。從目前記錄的開發資料來看，我們每周能完成80人天的需求，每周的臨時需求大概是20人天。如果想要在2周後送出QA測試，需要将剩餘需求控制在140——160人天。現在剩餘需求是260人天，需要至少削減100人天的需求或至少延期2周。”
回答1的問題在于：
- 結論偏主觀，難以令人信服
- 隻提出了問題，但沒有給相應的解決方案，PM應該站在“快速解決問題”的角度去處理工作，是以“問題”和“解決方案”往往是成對出現的
回答2比較接近日常工作中的實際場景，通過計算關鍵路徑來估算項目裡程碑的最後完成時間，但是在人力緊張時，可能會出現沒有充分利用所有人力的情況。
回答3根據團隊積累的曆史資料，充分估算了所有人力情況，給出了具體的人力資料，還針對現狀給出了對應的解決方案。是資料分析應用在項目管理中的最佳實踐。
九、風險管理
“項目風險是一種不确定的事件或條件，一旦發生，就會對一個或多個項目目标的範圍、進度、成本和品質造成影響。項目風險可能有一種或多種起因，一旦發生就可能造成一項或多項影響。我們認為項目風險源于任何項目中都存在不确定性。” ——PMBOK
風險管理是在這些不确定性事件發生或造成影響之前，對其進行識别、控制和處理的過程。對風險的管理貫穿整個項目生命周期中，在項目管理的各個子產品都能看見風險管理的影子，對風險管理的好壞直接決定着項目能否平穩運轉。
識别風險
風險是影響項目目标最終實作的各種不确定性因素。
對于已經發生或者一定會發生的，對實作項目目标有影響的事件，是問題而不是風險。可以通過發生機率和影響大小建議一個簡單的風險識别圖。
風險識别圖
風險分為正面和負面的，正面的風險稱為機會，負面的風險稱為威脅。
我們遇到的風險，大部分情況下都是負面的。我們讨論的“風險管理”主要也是針對負面的風險。
案例1：
下一次上線計劃定在9月30日，希望趕在十一之前完成，讓項目組好好放個假。版本排期定下來後，所有人都對目前的排期表示認可，看起來非常順利，可是真的是這樣嗎？
在拉會讨論各個重要feature的落地方案時，發現了好幾個潛在風險：
某個重要功能涉及三部門聯調，最終實作需要依賴A部門提供底層能力支援，B部門設計方案和實作功能，C部門負責接入并最終呈現給使用者。
在聊詳細方案時，發現目前的排期隻考慮了A部門和B部門的開發時間，沒有考慮C部門接入的時間。
同時，由于此功能在其他項目沒有完整實作過，程式同學給的排期也是非常樂觀的評估，無法保證按時完成。
發行同學已經訂好了宣傳物料的時間計劃，但是美術同學還不知道送出資源的ddl和需要哪些物料以及對應的尺寸和格式要求。
看似沒問題的計劃下藏了這麼多影響最終傳遞的“雷區”。
評估風險
識别到風險之後，需要進一步對風險進行評估，判斷影響範圍，通常把風險從上至下分為四種，分别是：企業級風險、業務級風險、部門級風險、崗位風險。
風險層級
上層風險發生時，往往伴随着下層風險。當下層風險沒有得到妥善處理時，也可能引發風險更新，造成上層風險。
判斷風險所處的層級後，需要調動對應層級的力量去推動解決。通常PM日常工作中遇到的風險都是部門級和崗位級的，可以通過建立标準流程規範、調整人員安排等一系列措施應對風險。
如果是業務級或企業級的風險，需要第一時間将資訊傳達給對應層級的管理層。
應對風險
通常有四種方式應對風險，規避、接受、減輕和轉移。
規避：指改變項目計劃，以排除風險。比如換一種實作方式，調整項目範圍等。
接受：指接受風險和結果。比如核心人員可能出現離職而影響項目進展，可以主動接受并儲備後備力量。
減輕：指設法把風險的後果減輕至可接受的範圍内。比如遊戲品質不穩定，bug多，可以通過每日測試前一天的版本，增加全員測試等方式暴露問題，集中修複。
轉移：指設法将風險的後果連同應對的責任轉移到第三方。比如項目合作的外包QA，可能在測試過程中毀約而影響項目進度。這時可以通過與外包代理公司合作，将潛在風險轉移到外包代理公司。
在應對風險之前，首先對其進行拆分，根據具體風險事件，找到風險的原因，整理風險的後果；然後制定解決方案和後續跟進人。
風險應對
案例2：
日常工作中的非固定假期是容易忽視的風險。
公司每年下半年都會組織團建旅遊，今年的時間安排在10月下旬，但是項目11月中旬會釋出一個重要的大版本，加上十一假期的影響，團建旅遊可能會對項目計劃和進度帶來風險。
為了應對版本釋出，采取了一系列措施：
- 統計能參與旅遊的人員名單（有加入時間要求）
- 團隊規模很大的情況下，分部門分批參與旅遊，確定關鍵崗位有人能響應問題（沒有stand by的崗位需要帶電腦旅遊）
- 提前鎖資源，為留下的同僚提供穩定的工作環境
- 根據實際進度組織統一加班
最終避免了旅遊帶來的風險，確定版本按時釋出。
不同職能對風險的評估角度不同，從某個視角看來不是問題，換一個視角可能就有較高的風險。大家可能更關注自己手上的工作，而沒有關注整個任務的風險。PM作為有全局視角的角色，需要收集各個職能對風險的判斷并進行整合彙總，綜合考慮各個因素，從專業角度給出整體的項目管理判斷。
最後，在項目管理中有兩個不變的金科玉律：
- 所有計劃都留好緩沖
- 永遠都有Plan B
十、品質管理
品質管理是指建立品質标準，并通過策劃、測試和改進等一系列動作實作的全部活動。
在遊戲項目中，品質可以分為兩部分
- 設計層面：遊戲是否好玩，足夠有吸引力讓玩家持續玩下去
- 研發層面：遊戲的bug數量如何，是否有影響遊戲運作的嚴重bug存在
好玩且bug少的遊戲才是一款好産品。下面也會以這兩部分為例說明pm如何參與到品質管理的過程中去。
設計層面
“這遊戲的畫面很好，打擊感還不錯，運作起來也挺流暢，但是主線結束後的日常還是傳統的一條龍模式，玩了兩天就不想繼續玩了，感覺就是什麼都好，就是不好玩！“
——taptap中某遊戲的玩家評論
對于一款遊戲産品來說，“不好玩”就是原罪，沒有人需要一個各方面都很完美但是不好玩的遊戲。
品質管理在這個階段承擔兩個職責，第一是讓設計通過充分的評審，第二是確定最終做出來的内容和設計一緻。
紙面評審
關于第一點，策劃在設計新玩法時會有一系列天馬行空的想法。在正式投入資源制作之前，需要有一套評審的規則，讓其他策劃、策劃主管共同參與，對這些想法的可玩性、可操作性做充分評估，主要目的有三個：
- 策劃主管對方向進行把控
- 設計優缺點頭腦風暴
- 熟悉自己和他人的開發内容
紙面評審
demo評審
紙面評審通過後，會留一段時間（1——4周）使用臨時資源做demo，demo評審會是指策劃主管或高層針對demo的表現決定是否進入後續開發環節。
demo評審
研發層面
研發層面的驗收貫穿整個遊戲制作的生命周期中，也是開發者對于自己制作内容品質和範圍的基本保證。
和設計層面的驗收相比，研發層面的驗收更偏重于對遊戲内每一個實作細節的打磨，在日常工作中，具體的執行方式通常是開發自測&策劃驗收、輔助性驗收和Bug Bash。
開發自測&策劃驗收
1、前後端開發完沒有聯調，直接甩給測試，開始測試後，測試同學發現某個重點功能無法走通，開發回去修複；
2、送出了代碼後，測試同學走主流程時發現另一個子產品的互動出了問題，開發繼續回去修複；
3、測了一半時，發現本次需求的一個重要的功能未能正确實作，需要重新設計，開發完需要全部重新回歸測試。
——關于缺少開發自測的經典場景
開發自測是指在編碼完成後，開發同學通過在本地或者開發環境進行接口調試、前後端聯調、全流程驗證等，确認本次新增功能都已實作，以及對原來主要功能沒有影響，確定遊戲流程能完整跑通。
開發自測在很大程度上決定了産品的品質和項目的進度，如果不重視自測甚至沒有自測，測試同學将花費寶貴的測試時間進行主流程确認，開發來回送出代碼，嚴重影響項目研發進度。
開發自測完成後，策劃根據功能需求單逐個驗收内容，确認制作内容覆寫所有需求點。
開發自測&策劃驗收
有同學可能會好奇為什麼不是測試同學直接進行測試的效率會更高呢，專業的人做專業的事不是更好嗎？
簡單來說，預防勝于檢查。原因涉及到産品品質成本的概念，産品品質成本通常分為兩類：一緻性成本和非一緻性成本。
一緻性成本是指為了預防品質問題付出的成本，如送出測試前的策劃驗收。
非一緻性成本是指為了修複品質問題付出的成本，如修複測試過程中發現的bug。
輔助驗收
輔助驗收是指其他職能輔助策劃進行需求品質、範圍的驗收，輸出可供參考的資訊。
需要進行輔助驗收的原因是策劃不一定具有全面的專業知識，需要依賴更專業的職能對于實作的需求給出其範圍内的專業意見，協助策劃共同驗收需求的效果品質。輔助職能包含UE、UI、美術效果跑查等。
輔助驗收
Bug Bash
Bug Bash是指所有團隊成員在版本釋出前，一起參與體驗遊戲找bug的過程，是QA的補充。
- 團隊集體試用，發現需求
- 厘清釋出前還有什麼地方做的不夠好
- 遊戲化激勵團隊（找bug競賽）
Bug Bash的時間點需要格外關注，太早——系統不穩定，太晚——來不及修複，根據以往經驗，在QA完成兩輪測試之後進行Bug Bash比較合适。
Bug Bash
以上是關于品質管理概念的簡單介紹，具體執行環節可以根據各個項目團隊的實際情況探索合适的落地方案。
品質管理的核心在于 過程和結果的監控，強化評審和驗收環節，輔助全民參與測試，盡可能打造出讓團隊成員滿意的品質。
但是也要意識到，品質管理能盡可能規避風險，但不能百分百避免風險。是以PM同樣要關注補救的方法，例如熱更流程，這裡就不較長的描述了——
十一、版本管理
遊戲版本管理在PM的日常工作中有着舉足輕重的地位，開發者通過一個個遊戲版本将内容帶給玩家，本文将通過一個極簡的版本模型介紹遊戲版本管理的基本步驟。
版本管理，是對軟體開發過程中特定功能的集合或特定代碼建構結果進行管理，主要包括版本編号的管理、版本的前期規劃、版本開發時的需求變更應對以及版本釋出上線後的總結回顧等内容。
版本開發流程可以根據版本狀态拆分為三個階段，分别是“準備階段”、“開發階段”和“營運階段”，我們再将這三個階段拆分為一個個相對具體的節點，大緻如下圖
準備階段
計劃階段的核心是确定版本的目标和釋出政策，再根據實際情況（可能存在的各種限制）将目标和政策拆分為一個個具體的需求。
版本規劃
常見的遊戲版本目标大緻分為四類：拉新、留存、促活和增收。
在實際場景中，大家自然是全都想要，但由于開發資源有限，一個版本能承載的需求量是有上限的，這時需要根據遊戲目前的資料情況，制定符合長線發展的版本目标。是以通常會從中選擇一到兩個作為主要的版本目标，投入大部分開發帶寬。
釋出政策是指遊戲版本開發完成後，投放給玩家的方式。通常會先在測試服釋出，驗證數值和暴露Bug，一段時間後再全量釋出，這樣做能降低風險，就算版本有嚴重惡性Bug，影響範圍也相對可控。
如《英雄聯盟》會在新英雄正式放出之前，先在測試服驗證新英雄的表現；《夢幻西遊》會動态挑選線上伺服器作為新功能/玩法的試點，收集一線玩家的回報并作出相應調整。
版本号也是版本規劃中必不可少的一環，此時可以考慮使用業界通用的規範，關于版本号的使用說明網上已有大量介紹，可根據項目實際情況自行選擇，這裡貼一篇搜尋引擎排名靠前的文章連結。
軟體版本命名規則
cloud.tencent.com/developer/article/1834484
确認版本需求範圍
版本規劃完成之後，接下來需要探索實作目标路徑。
當版本目标是提升留存時，有很多種方式看起來都能提升留存，比如增加遊戲深度、增加營運活動、改善核心玩法體驗、豐富外圍系統等。此時團隊需要選擇具體的路徑。
假設《代号C》是一款武俠遊戲，新版本希望提升長線留存，團隊認為需要繼續打磨核心玩法，并将其和競品做出明顯的差異化，以此為賣點留住玩家。
對此，團隊将“打磨核心玩法”拆分成了更具體的任務：
- 增加門派特色——門派專屬技能
- 豐富戰鬥政策——添加更多增益減益類型
- 完善基礎戰鬥體驗——優化戰鬥表現和打擊感
- ...
通過不斷拆分，最終将抽象的目标變為可落地的需求點。
開發階段
在準備階段産出了一批需求，我們将在開發階段将它們逐一實作。
版本資源生産
版本資源可以分為文檔資源和美術資源。
比較理想的情況是策劃提前兩個版本完成文檔編寫，美術提前一個版本完成美術資源制作，這樣程式在開工時能拿到确定的方案和正式美術資源，能有效降低風險。
如下圖所示，1.2版本的策劃案是在1.0版本功能開發期間準備完成的。
一個理想情況
然而往往由于種種現實因素，無法實作上述這種理想情況。
因為遊戲市場競争激烈且外部環境變化較快，幾個月前準備的策劃案可能已經不适合當下的市場環境了，需要做出疊代或者推翻重新設計。如果是下遊還沒開工的策劃案倒還好，影響相對有限，如果已經有美術/程式開始開發，則需要通過變更控制來確定整體風險可控。
變更控制流程值得單獨寫一篇文章，先挖個坑。
在策劃案準備完成後，可以組織資源宣講會，此時策劃會和參與需求制作的美術描述需求詳情。美術評估&拆解實作需求所需的素材清單。需求對清楚之後就可以排期制作了。
版本功能開發
到了這一步，程式将開始實作策劃案裡的功能。
這時PM需要對開發進度做整體把控，通過晨會、周會等各種正式&非正式管道獲得資訊，了解開發過程中是否出現了阻塞或其他特殊情況（如請假、需求變更等），及時暴露風險并制定相應的後處理方案。
版本驗收&測試
這裡的版本驗收&測試是指開發封版後的QA統一回歸測試。
每個版本功能點的驗收&測試應該是貫穿開發過程中始終需要策劃/美術/程式密切配合的，并不是程式自己做完覺得沒問題就結束了，而是整個功能點涉及的制作者都對效果驗收通過才算結束，其中策劃重點驗收功能和各種邊界條件，美術重點驗收功能的表現效果。這裡也非常考驗團隊配合，往往需要一段時間的合作才能把這一步跑順。PM可以根據排期設定一些節點，提醒制作者參與到過程驗收中來。同時也鼓勵美術/程式将開發中的過程版本展示到開發群中，讓大家了解功能目前的進展。
關于測試通過的标準，通常會有一些定量的名額，功能方面會有各類Bug率的名額，如
A類Bug=0，B類Bug<10等
性能方面也會有對應的要求，如
低端機幀率達到20
版本釋出
當版本終于通過測試之後，這時可以進行版本釋出的流程。過程中會有一些分支切換/合并的動作，完成後QA去線上服白名單跑回歸，回歸通過後版本就正式見玩家了。
版本釋出流程還是比較複雜的，上面隻是簡單概括了下大緻流程，PM需要提前和相關同僚确認好發版過程中各種突發情況的處理方案，確定風險可控。
營運階段
版本釋出後，我們将能收到真實玩家的回報，此時PM需要關注回報問題跟蹤和版本複盤。
回報問題跟蹤
玩家在進行遊戲的過程中會通過客服或社群回報遇到的問題；線上日志也會暴露一些測試環境很難發現的問題。
PM此時可以定期組織團隊，對收集到的問題/回報進行優先級排序，逐一處理。對于一些影響嚴重的問題，如大量crash、充值失敗等，在收到問題的第一時間就需要采取行動，在最短時間内解決問題。
這裡牽扯到線上回報問題的分級處理，有機會開新坑。
版本複盤
複盤的重要性不言而喻，可以回顧下第三章-項目複盤。
至此，一個遊戲版本的完整閉環就結束了。
和之前一樣，上面描述的版本管理模式僅僅是一個極簡模型，真實的項目可能比這個複雜得多，但整體思路架構是不變的，還是需要通過多實踐掌握版本管理的精髓。
十二、過程管理
往往我們在做計劃的時候，明明已經想的比較周全了，可當版本真正開始做之後會發現，很多事情沒有那麼簡單。
這次我們以一個案例開場：（已做脫敏）
項目A是一個射擊RPG遊戲，計劃在年底推出一部大的資料片，對遊戲中的槍械體驗做更新，希望與場景形成關聯，在實戰中衍生出更多政策選擇，豐富玩家體驗。
在版本規劃時，相關研發同學對功能涉及的子產品進行了拆分和估時，起初判斷工作量雖然比較大，但是難度不高，努努力可以在版本節點之前傳遞。
但是真正開工之後卻發現這個需求涉及的範圍沒有想象中簡單，牽扯面很大，底層架構也比較老，盤根錯節不好下手，目前看來工作量至少是原來的兩倍，甚至更多！
這個資料片是年底版本最重要的賣點，如果延期，所有人的名額都完不成。。。
在項目管理的日常工作中，心态絕對是最需要修煉的技能之一。即使規劃時做好了“萬全”的準備，在項目實施的過程中，依然會遇到各種意料之外的情況，甚至是影響項目生死的突發事件，這時需要通過及時有效的溝通推進問題解決。
之前接觸過的很多負責任的同僚，當ta們在執行中遇到困難，往往習慣于自己消化，不到最後一刻絕不會暴露問題尋求幫助。這時的進度通常已經和預期偏差很大了。
承認自己遇到了問題需要幫助，其實是件非常困難的事情。畢竟，很多人都有“想要把事情做好，讓老闆有個好印象”的心态。
但是，作為項目管理人員，當事情已經超出了你的可控範圍時，我們首先要做的，是第一時間直面問題，呈現事實和回報遇到的困難。這種真實坦誠的态度，對于整個項目而言，反而是最有利的。
今天我們就來梳理一下項目管理日常做彙報的幾個方法。
正常工作彙報
一份常見的項目周報可能長這樣：
一個極簡的版本
周報裡記錄了一些任務，但是項目整體的進展狀态、風險情況等資訊，周報裡都沒有展現，而這兩者恰恰是周報最應該展現的内容。為了更直覺地展示項目狀态，我們可以嘗試引入天氣圖示，把項目分成幾個等級。
使用天氣圖示分級
加入天氣圖示展示項目整體進展，再結合風險分析，可以得出一份更清晰的周報：
需要注意控制下一份周報的長度，閱讀量控制在5分鐘以内，是以切忌事無巨細地羅列任務，關注重點即可。
緊急問題彙報
當項目遇到了影響範圍很大的突發事件或者風險時，如上面說到的嚴重延期、線上事故、大客戶投訴等，項目經理需要向全組或主要幹系人第一時間同步項目的變化資訊，以此協調應對方案。
對于彙報形式可以不用拘泥于模闆，畢竟事出突然，言簡意赅地傳遞資訊并組織應對才是關鍵。一份緊急彙報可以包含幾個基本元素：問題描述、影響結果、初步分析、處理方案、需要的支援。
以文章開頭的例子來說，一份緊急彙報可以是這樣的：
問題描述：資料片核心功能重大延期風險；
影響結果：該功能處在版本的關鍵路徑上，可能會造成版本延期1個月；
初步分析：資料片中的槍械更新功能，部分代碼和底層架構混在一起，需要重構，且最初負責該功能的開發已經離職。之前對這部分功能的拆分&評估不充分，改動風險較高，可能會影響局内戰鬥的穩定性，具體還需要詳細評估；
處理方案：主程參與進行技術評估工作，本周四之前給出細化的拆分排期；主策介入評估方案調整的可行性，本周内給出結論；
需要的支援：版本結束後的大團建。
通過一份緊急彙報，制作人/老闆會第一時間了解團隊正在面臨的問題和可能的後果，同僚也會知道即将采取什麼方案去處理。如果有條件，第一時間面對面溝通的效果會更好。
項目開發過程中的各種緊急情況，其實很考驗項目經理的素養。項目經理自身不能着急，需要直面分體，在緊急時刻勇于承擔責任，協助決策者選擇更好的應對方式。
資料彙報
項目經理很容易陷入細節地工作中，今天催版本進度，明天推需求規劃，可是卻發現大家不配合你。事實上，預期每天挨個盯梢做一個監工，不如使用工具，把項目的狀态展示在所有人面前。
在版本的關鍵階段，定時在大群同步版本研發進展，慢慢就會發現，問題被處理的速度加快了。
Bug
開發進展
出了手動制作的開發進度圖之外，Jira本身也提供了一些常見的項目儀表盤，用于展示項目進展和每位團隊成員的工作安排情況，快速定位研發過程中的瓶頸。
項目儀表盤
工具千千萬，适合最重要。在使用工具之前，項目經理需要結合目前團隊需要重點改進的事項，選擇合适的工具，将資訊“透明”給大家。
項目進展彙報是項目經理面向所有幹系人的重要溝通平台，使用得好則可以成為一個有力的杠杆，引用一位前輩的話：想要改善什麼，就去透明什麼！