腾讯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单独辅导沟通，帮助其提升。
这样有助于团队树立榜样，建立好的团队文化和氛围。
