騰訊TAPD合作王者榮耀：自研游戲項目管理經驗
(1)客戶介紹
從2008年起，騰訊高級項目經理 張瑨燁 先后擔任了QQ飛車、天天飛車、極限三國、AOV的項目經理，已有接近10年的自研游戲項目開發經驗，現任職騰訊Arena of Valor(王者榮耀國際版)高級項目經理。
以下是根據其多個項目的經驗，總結出的在騰訊自研比較通用的模式。具有一定代表性，但肯定不適用于所有，僅供參考哈。
(2)項目背景
1 版本和迭代
在開始一個項目之前，我先說下版本和迭代的概念：
版本
• 版本所實現的組合特性決定其整體價值；
• 應從全局的視野規劃版本的內容，確保版本的各部分內容組合能實現價值最大化，避免局限于單一功能的實現而忽略全局。
迭代
在確定迭代時要注意以下三點：
• 一個版本包含多個迭代；
• 每個迭代都實現版本的主要特性；
• 之后迭代是前面迭代的優化或增量實現。
我經歷過的幾個項目，由于規模較大（都是50人以上的團隊），一般都是一周一個迭代，采用“3+2”或者“4+3”的版本節奏，即 3-4個迭代用來開發，2-3個迭代用來測試 。如果是小型的輕量級項目，也可以采用3天開發，2天測試這樣在1個迭代就能閉環完成的形式，將會更加敏捷。由于我沒有參與過這樣的項目，所以本文主要介紹規模較大項目的管理方式。
2 版本研發流程
版本研發流程概括來說就是： 需求評審 > 迭代開發 > 研發測試 > 運營測試 幾個環節不斷循環的過程。
下圖是將流程按照角色和階段進行分解，可以清楚看到每個階段不同角色需要做哪些事情。
將需求的工作流梳理出來，這些流程都可以在TAPD中進行自定義，通過TAPD便可以實現不同角色對于同一個需求的流轉。
介紹完總體流程，我將針對迭代周期的各個環節的實踐，談談自研游戲項目該如何進行高效管理。
需求評審
1 需求方向評審
在每個版本開始前，我們內部會先對該版本要做的需求進行方向評審。
我們一般是在當前版本在進行迭代開發時，來規劃N+2版本的需求方向，同時策劃寫N+1版本的策劃案。
策劃和運營確定需求方向，開發根據需求方向預估大致規模，允許有較大誤差。
隨后召開核心組會議，綜合需求的 優先級和開發成本 ，進行需求初篩。
通過篩選后的需求，才會安排策劃寫策劃案。
這樣做主要是為了 避免資源的浪費 ，以往每個版本的需求總會超量，有時甚至要拖走一半的需求。通過需求方向評審，我們可以將需求超量控制在20%-50%以內。
2 需求編寫
無論大小需求甚至是小優化項，一旦確定要做都要寫策劃文檔。
TAPD的需求模板功能，可以為系統功能、運營需求等配置不同模板，規定好每個需求要覆蓋的內容和字段。
比如我們的策劃在些需求時，都要寫 設計目的、術語表、系統概述、詳細設計、美術需求和數據上報 等內容，并且標注 需求優先級、用戶感知度 等信息。
這樣能夠保證策劃內容的質量，避免遺漏。
3 需求管理
隨后在需求列表建立Backlog來管理需求。
通過需求分類實現 版本、需求池 的管理，并且在列表中排列需求的優先級。
4 需求評審
需求評審又分為需求預審和需求評審會。
需求預審
需求預審階段，要督促開發提前閱讀策劃案。線下點對點溝通，可以提升評審會效率。
有爭議和風險的內容在需求單的評論中標注，作為評審會重點議題討論。
需求評審會
需求評審會上，主要是對需求進行拆分和工時估算。
（1）需求拆分
大的功能需求要進行拆分，拆分時主要注意以下三點：
• 單個需求（story）關鍵路徑最好不超過一個迭代周期，控制在2-3天為宜；
• 所拆分的子需求合集應該覆蓋父需求所有部分， 遵循MECE（Mutually Exclusive Collectively Exhaustive）原則，做到“相互獨立，完全窮盡” ；
• 每一個子需求要以產品視角可驗收作為基本標準。
（2）工時估算
由程序和美術進行任務分解及工時估算。
• 預估工時 ：客戶對于完成需求或任務所估計的時間，以人時或者人天為單位（根據項目中度量單位的設置決定）。
分配工時之后，需要通過總工時來衡量整個版本的工作量是否合適，能否在一個版本中完成。
確認之后，便可以將整個版本中的需求，按照優先級等拆分到迭代中。
二、迭代開發
1 迭代啟動會（IPM會議）
角色
PM、程序、美術、技術美術、策劃
輸入
• 客戶端、服務器和策劃已更新上一個迭代的任務/需求狀態
• 策劃已準備好版本內容及初版迭代目標
活動
• PM召集特性團隊（客戶端、服務器和美術）參加迭代計劃會
• 策劃與程序確定迭代完成的story、任務和迭代目標
• 程序提出臨時/正式資源需求及 截止日期
• 客戶端和服務器確認 聯調日期 ，并在TAPD任務上標注
• 美術確定技術美術資源合入時間節點
• PM根據資源需求和策劃意見確定迭代美術資源優先級
• PM在TAPD調整迭代Story、任務列表
輸出
迭代目標
任務列表-TAPD
2 創建并規劃迭代
在TAPD上創建迭代，將確定要做的需求拖入迭代。
當需求拆分不合理或開發進度延期時，可能會出現需求有任務沒完成，需要跨迭代，此時建議將整個需求移到下個迭代中，以便于任務的跟蹤和需求的完成度的整體驗收。
3 分配任務和確認工時
給程序分配任務，并且確認每個任務的預估工時是否合適。
4 需求跟進：狀態流轉
在迭代開發過程中，各環節需要通過TAPD上需求的狀態流轉，來實現對需求的跟進。
測試和運營在需求下填寫測試重點，程序完成需求后進行狀態流轉，并通過“源碼”功能提交關聯代碼。
5 需求跟進：更新任務
程序根據實際情況更新任務的花費和剩余工時。
這個環節一般都是難點所在，PM需要提醒程序及時更新任務狀態，最好能夠培養程序的更新習慣。
• 花費 ：在一個需求或者任務上已經花費的工時。
• 已完成工時 ：一個需求/任務上所有“花費”的總和。
• 剩余工時 ：為完成需求/任務還需要的工時，在默認情況下，“剩余工時”等于“預估工時”減去“已完成工時”。當剩余工時為0時，此時需求/任務工時完成，進度達到100%。
• 進度 ：對象的進度 = 已完成工時 / （已完成工時 + 剩余工時） * 100
6 需求跟進：工時花費報告
TAPD的報表中提供了工時花費報告。
回顧一周工時的消耗情況，查看明細可以看到具體完成的任務情況。
工時開銷不足的同學為主要風險點，重點溝通跟進；工時開銷超量的同學，可以提出表揚。
(3解決方案
角色
核心組、PM、需求Owner
輸入
• 程序已完成自測
• 策劃已驗收當前迭代完成的Story
• 策劃已配置好資源及數值 策劃已更新Story最新狀態
• 程序和美術已更新任務最新狀態
活動
• PM確定特性組展示的順序，并準備會議環境，一般安排每周五下午定時showcase
• PM召集核心組成員參與showcase
• 需求Owner向核心組介紹迭代目標，展示當前迭代成果
• PM記錄、整理反饋意見和變更，會后與需求Owner一并將反饋轉化為需求/任務/Bugs錄入至TAPD中
輸出
反饋意見及變更
Q&A 需求變更和緊急需求該如何管理？
以下是我們一般的做法，供大家參考：
• 所有需求一旦通過評審，不允許更改。
• 所有的需求變更另立新單 ，同時需要開發參與做工時估算。
• 在迭代開發期所有的需求變更都等同于新需求，按照緊急需求處理。
• 所有緊急需求在完成工時估算后， 超過0.5-1天的需求，需上升給核心組，進行審核 。
• 核心組評估緊急需求的風險、成本和進度的影響， 給予對應的資源支持或者調整發布計劃 ，未通過的緊急需求放到下個版本處理。
(3)解決方案
1 轉測試要求
創建版本號和基線號，所有需求都必須由特性Owner驗收通過后方能轉測試。
2 創建缺陷
利用TAPD的缺陷模板功能，為缺陷單添加基本的模板字段，這樣能夠提高溝通效率，方便開發快速定位和解決問題。
比如，我們就要求提BUG時，必須要填寫 測試環境（機型、接入點、包名、大區、帳號、時間）、操作步驟、實際結果和預期結果。
不符合要求的缺陷單一律打回。
3 管理缺陷
在管理缺陷的過程中，會使用TAPD中的“缺陷統計報表”來推動BUG修復進度。
四、運營測試
國內項目 的運營測試重點是渠道平臺能力測試和iOS預審。
國際項目則需要覆蓋本地化測試，和覆蓋區域的專項測試。
運營測試 一般在研發版本穩定后才開啟，只有穩定的版本測試才有價值。
(4)價值體現
版本總結每個版本發起一次，提出一些開放性問題，比如，這個版本中做得好的地方（Well），以及做得不夠好需要改進的地方（Less Well），讓大家匿名反饋。
針對正向反饋進行公開表彰，改進建議則由leader單獨輔導溝通，幫助其提升。
這樣有助于團隊樹立榜樣，建立好的團隊文化和氛圍。
