行业案例

black;王者荣耀国际版;自研游戏项目管理经验

扫一扫分享此案例

从2008年起，腾讯高级项目经理 !!#e69138 张瑨烨!! 先后担任了QQ飞车、天天飞车、极限三国、AOV的项目经理，已有接近10年的自研游戏项目开发经验，现任职腾讯Arena of Valor(王者荣耀国际版)高级项目经理。

以下是根据其多个项目的经验，总结出的在腾讯自研比较通用的模式。具有一定代表性，但肯定不适用于所有，仅供参考哈。

## 自研游戏项目的一般流程

### 1   版本和迭代

在开始一个项目之前，我先说下版本和迭代的概念：

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788184_11.png)

__版本__ 
• 版本所实现的组合特性决定其整体价值；
• 应从全局的视野规划版本的内容，确保版本的各部分内容组合能实现价值最大化，避免局限于单一功能的实现而忽略全局。

__迭代__ 
在确定迭代时要注意以下三点：
• 一个版本包含多个迭代；
• 每个迭代都实现版本的主要特性；
• 之后迭代是前面迭代的优化或增量实现。

我经历过的几个项目，由于规模较大（都是50人以上的团队），一般都是一周一个迭代，采用“3+2”或者“4+3”的版本节奏，即 __3-4个迭代用来开发，2-3个迭代用来测试__ 。如果是小型的轻量级项目，也可以采用3天开发，2天测试这样在1个迭代就能闭环完成的形式，将会更加敏捷。由于我没有参与过这样的项目，所以本文主要介绍规模较大项目的管理方式。

### 2   版本研发流程

版本研发流程概括来说就是： !!#e69138 需求评审 > 迭代开发 > 研发测试 > 运营测试!!  几个环节不断循环的过程。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788240_89.png)

下图是将流程按照角色和阶段进行分解，可以清楚看到每个阶段不同角色需要做哪些事情。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788250_96.png)

将需求的工作流梳理出来，这些流程都可以在TAPD中进行自定义，通过TAPD便可以实现不同角色对于同一个需求的流转。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788258_81.png)

介绍完总体流程，我将针对迭代周期的各个环节的实践，谈谈自研游戏项目该如何进行高效管理。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788266_1.png)

## 一、需求评审

### 1   需求方向评审

在每个版本开始前，我们内部会先对该版本要做的需求进行方向评审。

!!#e69138 我们一般是在当前版本在进行迭代开发时，来规划N+2版本的需求方向，同时策划写N+1版本的策划案。!! 
策划和运营确定需求方向，开发根据需求方向预估大致规模，允许有较大误差。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788288_66.png)

随后召开核心组会议，综合需求的 !!#e69138 优先级和开发成本!! ，进行需求初筛。

通过筛选后的需求，才会安排策划写策划案。

这样做主要是为了 !!#e69138 避免资源的浪费!! ，以往每个版本的需求总会超量，有时甚至要拖走一半的需求。通过需求方向评审，我们可以将需求超量控制在20%-50%以内。

### 2   需求编写

无论大小需求甚至是小优化项，一旦确定要做都要写策划文档。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788315_69.png)

TAPD的需求模板功能，可以为系统功能、运营需求等配置不同模板，规定好每个需求要覆盖的内容和字段。

比如我们的策划在些需求时，都要写 !!#e69138 设计目的、术语表、系统概述、详细设计、美术需求和数据上报!! 等内容，并且标注 !!#e69138 需求优先级、用户感知度!! 等信息。

这样能够保证策划内容的质量，避免遗漏。

### 3   需求管理

随后在需求列表建立Backlog来管理需求。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788346_19.png)

通过需求分类实现 !!#e69138 版本、需求池!! 的管理，并且在列表中排列需求的优先级。

### 4   需求评审

需求评审又分为需求预审和需求评审会。

__需求预审__ 
需求预审阶段，要督促开发提前阅读策划案。线下点对点沟通，可以提升评审会效率。

!!#e69138 有争议和风险的内容在需求单的评论中标注，作为评审会重点议题讨论。!!

__需求评审会__ 
需求评审会上，主要是对需求进行拆分和工时估算。

__（1）需求拆分__ 
大的功能需求要进行拆分，拆分时主要注意以下三点：

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788378_60.png)

• 单个需求（story）关键路径最好不超过一个迭代周期，控制在2-3天为宜；
• 所拆分的子需求合集应该覆盖父需求所有部分， !!#e69138 遵循MECE（Mutually Exclusive Collectively Exhaustive）原则，做到“相互独立，完全穷尽”!! ；
• 每一个子需求要以产品视角可验收作为基本标准。

__（2）工时估算__ 
由程序和美术进行任务分解及工时估算。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788407_80.png)

•  __预估工时__ ：客户对于完成需求或任务所估计的时间，以人时或者人天为单位（根据项目中度量单位的设置决定）。

分配工时之后，需要通过总工时来衡量整个版本的工作量是否合适，能否在一个版本中完成。

确认之后，便可以将整个版本中的需求，按照优先级等拆分到迭代中。

## 二、迭代开发

### 1   迭代启动会（IPM会议）

__角色__ 
PM、程序、美术、技术美术、策划
 __输入__ 
• 客户端、服务器和策划已更新上一个迭代的任务/需求状态
• 策划已准备好版本内容及初版迭代目标
 __活动__ 
• PM召集特性团队（客户端、服务器和美术）参加迭代计划会
• 策划与程序确定迭代完成的story、任务和迭代目标
• 程序提出临时/正式资源需求及 __截止日期__ 
• 客户端和服务器确认 __联调日期__ ，并在TAPD任务上标注
• 美术确定技术美术资源合入时间节点 
• PM根据资源需求和策划意见确定迭代美术资源优先级
• PM在TAPD调整迭代Story、任务列表
 __输出__ 
迭代目标
任务列表-TAPD

### 2   创建并规划迭代

在TAPD上创建迭代，将确定要做的需求拖入迭代。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788449_2.png)

当需求拆分不合理或开发进度延期时，可能会出现需求有任务没完成，需要跨迭代，此时建议将整个需求移到下个迭代中，以便于任务的跟踪和需求的完成度的整体验收。

### 3   分配任务和确认工时

给程序分配任务，并且确认每个任务的预估工时是否合适。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788466_21.png)

### 4   需求跟进：状态流转

在迭代开发过程中，各环节需要通过TAPD上需求的状态流转，来实现对需求的跟进。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788477_94.png)

测试和运营在需求下填写测试重点，程序完成需求后进行状态流转，并通过“源码”功能提交关联代码。

### 5   需求跟进：更新任务

程序根据实际情况更新任务的花费和剩余工时。

这个环节一般都是难点所在，PM需要提醒程序及时更新任务状态，最好能够培养程序的更新习惯。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788492_87.png)

•  __花费__ ：在一个需求或者任务上已经花费的工时。
•  __已完成工时__ ：一个需求/任务上所有“花费”的总和。
•  __剩余工时__ ：为完成需求/任务还需要的工时，在默认情况下，“剩余工时”等于“预估工时”减去“已完成工时”。当剩余工时为0时，此时需求/任务工时完成，进度达到100%。
•  __进度__ ：对象的进度 = 已完成工时 / （已完成工时 + 剩余工时） *  100

### 6   需求跟进：工时花费报告

TAPD的报表中提供了工时花费报告。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788520_48.png)

回顾一周工时的消耗情况，查看明细可以看到具体完成的任务情况。

工时开销不足的同学为主要风险点，重点沟通跟进；工时开销超量的同学，可以提出表扬。

### 7   Show Case 会议

__角色__ 
核心组、PM、需求Owner
 __输入__ 
• 程序已完成自测
• 策划已验收当前迭代完成的Story
• 策划已配置好资源及数值 策划已更新Story最新状态
• 程序和美术已更新任务最新状态
 __活动__ 
• PM确定特性组展示的顺序，并准备会议环境，一般安排每周五下午定时showcase
• PM召集核心组成员参与showcase
• 需求Owner向核心组介绍迭代目标，展示当前迭代成果
• PM记录、整理反馈意见和变更，会后与需求Owner一并将反馈转化为需求/任务/Bugs录入至TAPD中
 __输出__ 
反馈意见及变更

__!!#ff0000 Q&A!!__    __需求变更和紧急需求该如何管理？__

以下是我们一般的做法，供大家参考：

• 所有需求一旦通过评审，不允许更改。
•  !!#e69138 所有的需求变更另立新单!! ，同时需要开发参与做工时估算。
• 在迭代开发期所有的需求变更都等同于新需求，按照紧急需求处理。
• 所有紧急需求在完成工时估算后， !!#e69138 超过0.5-1天的需求，需上升给核心组，进行审核!! 。
• 核心组评估紧急需求的风险、成本和进度的影响， !!#e69138 给予对应的资源支持或者调整发布计划!! ，未通过的紧急需求放到下个版本处理。

## 三、研发测试

### 1   转测试要求

创建版本号和基线号，所有需求都必须由特性Owner验收通过后方能转测试。

### 2   创建缺陷

利用TAPD的缺陷模板功能，为缺陷单添加基本的模板字段，这样能够提高沟通效率，方便开发快速定位和解决问题。

比如，我们就要求提BUG时，必须要填写 !!#e69138 测试环境（机型、接入点、包名、大区、帐号、时间）、操作步骤、实际结果和预期结果。!!

不符合要求的缺陷单一律打回。

### 3   管理缺陷

在管理缺陷的过程中，会使用TAPD中的“缺陷统计报表”来推动BUG修复进度。

![图片描述](/tfl/pictures/201811/tapd_20106291_1542788619_10.png)

## 四、运营测试

!!#e69138 国内项目!! 的运营测试重点是渠道平台能力测试和iOS预审。