规范项目流程，让团队高效运转

流程是为效率服务的。一个游戏项目，会涉及很多团队，项目经理需要梳理必要的项目流程，以此来更好地为效率服务。

如果负责的项目是单一且简单的，项目组有一些牛人就可以比较好地搞定项目，但手游项目，通常情况下都是“大兵团作战”，涉及的人员众多，这个时候，规范化的流程是才是最安全可靠的。

好的流程，也可以大大地提升项目研发的效率。如图1所示，是某大厂的游戏项目研发流程，通过规范化的流程，来让团队成员清楚地知道每个阶段该做什么事情，让团队形成自运转。      

图1 游戏项目研发流程

再详细来说：

（1）需求是统一用TAPD来进行管理的，策划将需求提交到TAPD，处理人统一为项目经理。（TAPD：腾讯的项目管理工具）

（2）需求提交之后，并不是项目经理马上就分配到具体负责的成员，而是要先组织或者策划内部组织对需求进行评审，也即前面谈到的需求管理组，所有提交的需求必须要经过策划内部评审通过，达成一致意见。如果涉及大的系统或者有争议的功能，务必要邀请老板或工作室制作人参与，共同确定。

（3）需求确定之后，项目经理开始组织具体负责的项目团队成员（策划、开发、美术、测试）对需求进行评审。

（4）需求评审完，开发、美术、测试人员各自对需求进行工作量评估，在约定的时间内汇总给项目经理，项目经理收集后，根据制订计划的原则，制订科学、客观、合理、有效的项目计划，在和具体负责人核对之后，再和主要相关方核对，然后才是同步到老板，若老板对计划有疑义，则需要再对计划进行调整；若无其他意见，则同步项目成员，开始按计划执行。

（5）团队成员按照自己评估的时间开始完成各自的工作，开发侧的编码，美术侧对美术进行设计，测试对需求进行用例设计，项目经理和具体需求负责人（策划人员）则关注整个需求实现的过程，及时掌握需求开发的进度，一旦有什么问题，则第一时间进行沟通。这里还有一点非常重要，美术资源通常都会要求先行，这样才可以更好地匹配上开发的进度。

（6）开发完成需求功能的实现后，要对需求完成的情况进行自测，若有和美术资源相关的验收，则需要在PC端先周知美术人员对美术效果进行验收，这样可以比较好地，也可以很快速地在PC端就先解决掉一些很明显的美术效果问题。而构建版本之后，美术负责人还需要在手机上对版本的美术效果进行验收，以确保需求转到策划验收时，美术效果是符合设计预期的。

（7）开发自测完，美术对效果进行验收后，相应的需求单或版本则转给策划对功能进行验收了，具体需求负责人要对需求功能进行全面的验收。一个需求的实现，根据做游戏项目通常的惯例，必然会有很多体验意见提出来的，还有很重要的一点，需求负责人是对其负责的需求最了解的，验证的过程中也可以清楚地知道，是否是按照需求设计的预期实现的，是否有需要调整的地方。每个需求实现后，需求负责人验收务必要输出体验意见，并整理好优先级同步给项目经理；同样，这些体验意见也是以需求单的形式，提交到TAPD上。

（8）需求实现后，对应的体验意见修改完，没有严重阻塞的问题，即该需求是验收通过的，需求负责人（策划人员）则将需求转给测试人员进行测试，这里包括各个维度的测试，测试对需求功能测试通过，对应的bug也验证完成，则对应的需求单转为已实现。至此，一个需求的流程才全部完成。

对应的项目开发流程，是有一套完整的需求自动流转流程的，同样是基于TAPD项目管理工具来设定的。因为所有的需求都统一在TAPD进行管理，那么在设定需求自动流转流程时，会先对需求进行分类。

需求分类的主要目的是明确跟进负责人，是产品需求的，由对应模块的策划人员来验收；是美术优化的，都是由美术侧来验收；是程序优化的，比如性能、帧率等，由开发自己验收后，转测试验收；体验优化方面，项目经理或策划都可以承担验收的工作。具体解释参考如图2所示。

产品功能：产品的功能需求，都放到这个类别下。责任人是策划人员，当查看这个类别的时候，可以在右侧很方便地看到各个功能模块是哪个策划负责。

体验优化：是每个功能模块转体验后，功能方面的体验意见都提交到这个类别。各项目可根据项目实际情况，体验优化的需求或提给项目经理，或直接分发给开发模块负责人。

图2  需求分类设置

美术优化：功能模块转体验后，美术方面的体验意见，包括UI的表现、特效、动作、3D等，都提交到这个类别。这个类别的负责是美术设计师。美术设计师要负责对这个功能进行验收，验收完才转给策划再验收，形成双闭环。

程序优化：是在版本体验过程中，发现有卡顿、loading不流畅等问题，提交到这个类别。这个类别的需求，负责人都是开发。

程序bug：在版本体验中，若发现有功能方面的bug，还未正式转测试时，提交到这个类别。同程序优化，负责人也是开发。

基础建设：主要包括帧率、size处理、内存、IDIP、经分等需求，负责人是开发。

需求类别设置完成后，再进一步规范需求自动流转流程，这个自动流转的流程就是将各个团队串起来的“齿轮”，让团队可以高效地自运转，同时更进一步的目的是，释放项目经理的精力，不用事无巨细地要项目经理去催、去问进度，如图3所示。

图3  需求流转流程

流程中各字段的表述为：

规划中：策划提交的需求，所有的状态全部为规划中，处理人为项目经理。

已规划：项目经理和前后台主程沟通确定，也可以根据自己了解的团队成员的情况，将对应各个需求转给具体模块负责人，处理人为开发人员；若需求涉及美术，则转给APM（美术项目经理），处理人为APM。

实现中：开发或美术接到需求后，将需求状态变更为实现中，处理人为开发人员或美术人员。

产品验收：需求完成后，达到可验收的状态，则将状态转为产品验收，并转给对应策划负责人，处理人为策划人员。这里也是需求分类的一个重要的承接原因。因为需求分类定义好了，开发人员清楚地知道需求是哪位策划人员负责的，从需求评审、需求实现过程的沟通，到功能实现，都可以直接转给对应策划人员进行验收。不用再转给项目经理，由项目经理转一次，可大大地节省沟通成本。

转测试/已实现：策划验收通过产品功能需求，则将状态转为转测试，处理人为测试负责人；若是体验意见或美术优化方面的需求，则直接转为已实现，需求流转结束。

已拒绝：是各个状态下的需求，当需求不在规划到迭代，则转为已拒绝状态。一般情况下不做删除处理，作为记录，以便有需要的时候，可以查阅或重新打开。

此外，在这个流转流程里面，蕴含一个双闭环的验收，如图4所示，意思是，需求在开发侧务必要进行自测通过后，才能转策划验收；如果是UI或其他美术方面的需求，开发自测完后，必须是先美术侧验收通过，才能转策划验收。

图4  双闭环验收流程

关于规范流程方面，还有一个必要的流程，是项目经理需要去建立和规范的，那就是需求的变更流程。

在快速小跑、迭代试错的大环境下，需求变更是不可避免的。作为项目经理，不能一味地去阻止流程的变更，需要具备产品思维、用户思维，更好地去拥抱变化，但这并不意味着策划（产品）是可以随意变更需求的，因此还是需要针对性地规范好变更流程，如图5所示，是我们项目的需求变更流程。

图5  变更流程图

当有需求变更的时候，需求负责人第一时间和项目经理沟通，项目经理组织相关人员对变更的需求进行评估，包括变更需求的工作量、对现有计划的影响、可能带来的风险、变更可能会带来的效益，然后提交核心策划团队决策（通常是核心管理层和需求管理组的大部分成员），核心策划团队决策该需求是否变更，不变更则取消，该需求流到下一个迭代。

如果决定变更，则执行变更，项目经理根据新的工作量评估，刷新计划，然后同步全项目团队，在变更需求同步之后，还有很重要的一环，需要验证需求变更后的实际效果，比如对数据的提升，对收入的提升。

记录验收变更后的效果，主要是用来进行一段时期的纵向比较，以便确定变更的有效性，从另外一个维度来驱动策划在每个需求开始的时候思考得更多一些，更广一些，更深一些，减少在项目过程中的变更，减少项目中的无效加班。

项目中的流程并不是越复杂越好，关键还是在于对团队来说否是适用和高效。围绕着“流程是为了效率服务”这个基本原则，必要的规范化在项目执行过程中是必不可少的，而且好的流程会让项目团队事半功倍。

当然，流程是需要持续优化的，是需要适应团队需要的。在具体执行的过程中，切忌一味地照搬流程，否则，不仅不能提升效率，而且会适得其反。

所以，不断持续地优化流程，让流程为效率服务，是项目经理要持续关注的部分。