如何做好游戏研发项目管理

主要从以下四个方面来谈一下在初涉游戏行业项目管理过程中遇到的一些问题和自己的观点。
1.启动计划   2.进度跟踪   3.团队管理   4.会议效率

一

制作新功能伊始，当策划确定策划案之后，排定时间开展功能会。在功能会上由策划阐述具体设计，程序、测试及时提出可能存在的实现问题、设计缺陷。在功能会结束之后，程序回去按照给定修改好的策划案，完成功能的拆分，逐项估时，每项的颗粒度在0.5d~2d，并且当总体研发期大于5d，我们还会在中间定义可见点，由策划进行中间验收，避免。在这两个会上，会有主程全程参与，功能会上主程会从游戏整体触发，并且考虑未来的可扩展性，协助执行程序一起制定实现方案或是提醒通用逻辑的服用，从设计阶段就避免一些将来可能存在的问题，或是重复造轮子。

但是在做计划时，我们经常总是假定一切都能顺利如期进行。

比如，最近的一个功能，在完成上述流程进入研发期后的第一天，和另一个部门B支持的接口其实可以复用，但是到了第二天，B又表示用途不同，最好不要复用，但可以支持重新开发，这都是过程中不可预料的因素影响。
 

二

在完成上面的估算计划之后，进入研发期。如何在研发期中进行有效的进度跟踪，也是项目管理中的很重要的一环。

曾经的做法，是在各组大群中，每天晚上6点左右，发今天一天的工作以及完成进度，我来收集更新进排期表汇总。这样做的弊端是，没有办法清楚地定义每个人的百分比标准，可能有点表面繁荣的“假象”。

现在的做法是，每日早上开站会，参与者有策划、程序、主程、PM。在会上主要程序汇报昨日进展和今日预计进行的任务。

在实际的过程中，很容易出现，在站会上程序之间聊起如何实现，拉长站会时间，而这些并不是站会需要关心的，并且因为还有策划参与，策划并不需要了解实际实现过程如何。

点对点催进度不是好的项目管理方式

最初，我的工作方法是逐个询问任务进度状况，但次数多了，时间久了，给了我一种很挫败的感觉。并且有的时候需求比较散、比较碎，逐一确认的话，需要耗费的时间、精力跟能够得到的收益并不相匹配。一部分可能涉及到自身的性格以及语言表达风格；另一部分则是有时候对方已经陷入泥潭或是深度思考中，而打断别人工作思路确实不是一种好方式。

所以想办法另辟蹊径。

1.任务系统的“预计解决日期”

项目使用的任务系统，因为一系列历史原因，“预计解决日期字段”被无视，导致的结果比如某项任务完成，但是不及时修复任务，而在工作流下游的测试同学，不知晓已经完成，无法开始测试，当临近版本阶段，这样的问题对测试会造成比较大的压力。所以首先，将这一字段，使用起来，号召将所有的工作体现在JIRA上，根据JIRA的任务单子修复情况判断是否完成。这样做的好处之一是不再需要一对一询问任务是否完成。

2.借由主管的力量，确认情况。

在群里列出当天需要解决完成的工作事项，@对应的主管，得到反馈，并且这样做的好处还可以及时对进度信息进行同步。
 

三

在PM监控过程，涉及大团队的协作，流程管理、工作规范等。流程管理中，对每一项工作应该要清楚的对应到每一个人，设定时间节点，做到权责分明，尽可能减少模糊地带。

比如，游戏研发中，涉及到大量的配表工作，在研发过程中，需要随功能的实现有一些测试数据。对于这点，明确定义为配表为策划工作，对应功能策划在程序研发过程中，应该要及时协助程序进行配表。

在使用JIRA进行任务管理过程中，团队成员一度无视“预计解决日期字段”。后来经过要求，由各组主管具体执行，情况有所好转。

但是现在出现的问题是，主管一手包办。由主管每天晚上统一修改时间。具体表现为，每个2~3天，在某天早上check的识货，就会出现一波大批量延期任务单。主管没有传导：标注日期为当天需要结束的工作，需要及时反馈是否能完成。当前的状况经常是主管，每天抽出不定的时间对日期进行修改。一旦当天遗忘这件事，则第二天就会出现大批量未修复。

在研发过程中，会制定各种规则、规范。如何保证确实能够具体落实到位是个很重要的命题，毕竟规则的建立是为了解决问题。

所以规则的建立，需要注意的是其本身是否合理、是否是切实可行的，需要长期在执行的过程中，不断针对实际情况进行完善。如果每次只是当问题发生，对具体的问题进行规则的制定，容易头疼医头脚疼医脚。

比如，测试组的同学，拥有一套自行制定的类似交叉测试的测试方法，做到赏罚分明。并且以这个规则作为他们组内规则的主线，执行到底。测试组在规则中明确时间，每天固定的时间段无特殊时间就会在会议室开始交叉测试，规则具体到迟到的扣分规则、发现bug积分规则，积分结算排行等。
 

关于项目管理意识的认识：开发是一整个环节，需求的提出，从产品、设计、开发、运营等的状态、情况。项目中的角色、参与人是一种什么样的状态，做出闭环，能够获得相对全面的反馈信息，验证最初的设计想法是不是ok。