1、项目的过程管理

    项目管理工作是一个非常幸苦的工作，一个项目一般最忙的是项目经理，而且对人的综合能力要强很高。不光在管理方面有知识与经验要求，而且一个好的项目管理一般都需要懂自己所负责的项目每一个环节的实现细节，甚至最好你能精通某一环节（比如你是程序转的项目经理熟悉程序开发环节），这样在推动项目的时候与执行团队能有共同语言。

    项目经理一天的日常工作内容，主要是围绕如何让自己的项目有效向前推动开展的，做的所有事，开的所有会，最终本质都是这个目的。

2、项目过程管理目的

    为了有效推动项目的正常开展，对项目经理来说，主要力求做到两个方面：“可控”与“透明”

2.1、可控度

    还记得“计划篇”中说的“管理无定法”吗，这里也是一样的。要做到可控，并没有一个标准的方法，只有项目经理觉得当前对整个进度是否能可控。如果觉得不可控就需要加强管理，如果觉得“尽在掌控”就可以保持当前力度或适当减少管理力度。

    具体使用什么样的管理方法来督促项目、来达到可控需要根据不同项目、不同进度、不同环境来选择。如果管理粒度过粗，就会不透明、可控性差，导致容易失控。如果过细，管理成本就会直线高、影响工作效率。

2.2、透明度

    软件项目开发过程中，人是主要过程管理对象。游戏研发中经常会遇到需要预研的功能，或者底层的（不可见）的功能。项目经理遇到这种问题，没做好的话会导致，项目经理无法信任、控制项目进度，这个时候需要通过某些手段把这些黑盒透明化，比如拆解出几个小步骤，让这件事的过程可以通过这些步骤来体现出进度

    比如一个某一个美术资源的产出，如果你对美术资源不关心的话，只要结果管理就可以了。但你发现这件事占用时间非常长，而且风险很高，管理结果完全不可控，你可以把按步骤拆解。比如画一个这样的图，把每个环节可视化出来。

    当然这只是一个举例，总结来说“透明化”就是一个拆解的过程，但要讲究一个度，因为你的精力有限。

3、日常推进

    日常推进进度占据项目管理80%工作内容。

3.1、沟通时间

    每天项目经理需要把项目进度做一次跟踪。一般可以跟着某一团队开早会，可以了解这一团队每个人的进度。比如跟着客户端团队开会，如果把客户端成员每个人的工作进度都了解到了，那会后就可以只去找服务器和其他团队了解了。

    程序员、美术做执行的人一般不希望在工作中经常被打断，所以一般固定一个时间去了解进度，例如我们都选早上的时间段。

3.2、沟通方式

    一定要面对面沟通，尽量不要rtx或邮件，除非对方是外包公司或异地团队。这样可以大大减少沟通时间，提升沟通效率。

3.3、沟通对象

    这是最重要的一个需要考虑的因素，你可以有这几个选择

    和任务本人沟通，这是最常用的方式，也是管理粒度最细的方式，优点是你能最大限度的了解真实情况，缺点是通常一个任务有许多人负责，你要和每个人沟通来了解实际情况。

    也可以选择和他的组长来沟通进度，对于一些小组，组长能力强，而且你够信任，你可以选用这种方式，比如我们UI组，UI方面的进度一般都只和他对。

    和负责这个功能的策划来沟通，这个做法表面上是让策划了解自己负责功能的进度，其实好处是也可以促进他们了解自己负责的功能的实现情况，因为在对进度的时候会要了解大量的实现细节，这对项目是非常有好处的。

3.4、关键事件

    在跟进的时候经常会有些突发任务、重要任务或关键节点，这里我建议找个白板，做“管理看板”，放在项目组附近，让大家每天都会看到，开早会的时候可以看到，无时不刻不在提醒大家。而项目经理也需要单独对这些事情进行跟踪。注意，这些事情列在白板上一定要列上负责人和完成时间。

    对与项目中一些非常关键的任务或问题，除了刚才说的在一个看板上列出，项目经理要专项对待，在任务优先级中排出一个特殊的优先级。对于形成的解决方案，需要做记录，因为选择这个解决方案可能关系到项目的命运。每周在周报中对这些重要的事情做专门阐述。

3.5、需求说明会

    这个是一个任务从设计到开发中间的一个关键里程碑，项目经理一定要拉上这个任务的干系人都参与，其实在开这个会之前就应该拉好沟通的群，来讨论一些需求细节。注意这里的干系人一定包括“UI”、“测试”甚至还有“运营”，因为他们往往能提出很多需求设计上的缺陷。

3.6、设计讨论会

    在一些复杂功能程序拿到需求后，会要求开设计讨论会，主要是针对需求的实现方案。这里策划是必须要出现的，因为往往有些很难实现的功能，也许策划改改需求，就可以绕过这个设计难点，当然这个需要双发充分的讨论。这对整个项目是非常有好处的。项目经理应该鼓励大家开这个类的会。

3.7、需求边界的动态调整

    一般从需求说明会开始、UI设计、程序实现一直到测试，都有可能出现意外情况，比如发现还需要开发一个衍生系统，或者版本时间有限部分功能无法在版本内完成，又或者无意遗漏的一些实现细节。这些都会导致边界的调整，甚至产生新的需求。对于这问题，项目经理应该要及时做好版本计划的维护、调整以确保版本计划上是真实情况的反映。另外还要记录下来，在版本总结的时候，当成经验分享给大家。

4、外包管理

    关于外包管理是项目管理的一个难点，因为很多外包商的进度都非常难把控。为了尽量避免延期，可以在合同上约定清楚惩罚措施、在任务开始前让对方尽量早的提交制作计划。项目经理需要设计一个专门的表格来管理他们的进度，因为不可控因数太多了，这里强烈建议每天和外包对进度，而且要预留好计划外时间，尽量不能让外包负责关键路径的工作。

    外包的质量把控需要“业务对接负责人”项目经理只能管进度，计划中也要预留出质量不好的返工时间，经验来看是3/1的制作时间，如果没用到就是赚到了。

    外包商平时就要多积累，不要只找需要的数量，永远要有一个备用的，不行就换。因为外包质量一般都是逐步下降的。

    外包管理表格注意包括：各个节点（里程碑）的时间，一定要做到透明与清晰。

5、质量管理

    质量管理是保证产品最终品质的重要组成部分，虽然一般有质量经理，但对项目经理来说也是重点关注的部分。

5.1、测试用例

    一般测试团队在需求说明会后就可以开发测试用例了。在测试用例编写完，不管是质量经理、还是策划、还是交叉检查，建议要有一个测试用例评审的环节，这样可以尽量保证测试用例的全面性。

    另外对于用例管理，这里我强烈建议使用Excel表格化、模块化，这样的测试用例未来复用性很好，比如可以可以重新组合成一个回归测试流程。一般测试用例包括：前置条件、操作步骤、预期结果，甚至也可以有衍生的bug编号，这些你都可以根据你的管理实际情况进行修改

5.2、问题处理流程

    一般团队都会有工单系统，比如禅道(bugfree)、Jira、QC、TAPD等等反正你得有一个，在上面跑bug跟踪流程。项目经理需要每周对项目的质量情况数据做分析，比如bug产生数、解决数，每个模块的质量情况，bug最多的模块，问题最多的人等等

5.3、开发过程质量管理

    对于软件开发一般除了一般bug外有两种需要特别关注的，

5.3.1、低级问题

    说白了一看就知道程序员提交后自己都没运行一下，比如模块都打不开、按钮无法点，告诉测试可以测了。对于这种问题要单独列出来，记录下来在例会进行反馈。这样才能让程序员养成良好的自测习惯。

5.3.2、阻塞性问题

5.4、游戏产品质量的关键点

    除了一般的功能测试、回归测试外，产品品质还需要其他的测试来保证

5.4.1、客户端性能测试

    目的是测试客户端的“内存泄漏”，“快速点击产生的并发问题”。一般用暴力点击测试法、反复循环操作测试法，常用工具是“按键精灵”。比如不断进出房间、不断打开关闭某个功能、不断战斗，观察连续操作几小时后，内存情况，功能情况等等

5.4.2、客户端弱网测试

    手机游戏这个是重点，目的是测试客户端在网络环境差，甚至短暂断网的情况下，断线重连这个功能情况。这里首先需要策划、技术出弱网应对设计方案，一般包括：地图延迟同步策略、超时策略等，注意这里不是一个系统，是要列出所有系统的策略，比如战斗中多长时间服务器判断客户端断开，服务器是否给予自动托管，自动托管中客户端重连是否会拉回战斗，如果托管超过多长时间算真正退出，或者在判断战斗结束时，恰好客户端断开会怎么样......。这项测试弱网策略是最重要的。

5.4.3、服务器协议测试

    目的是为了做服务器的漏洞测试。比如购买数量，通过改协议发一个整数最大值或最小值（负数）过去，又或者重复发送一些协议，看服务器是否处理。一般都能发现非常多的问题，这个测试对服务器品质的保证非常重要，而且一般也要求对每个功能写测试用例，和一般功能的测试用例放在一起用类型分开就好。

5.4.4、服务器性能测试

    目的是为了测试服务的性能，这个测试方法很多，一般包括并发测试、高负载测试、疲劳测试。另外就是建议做个过载实验，找到服务器的瓶颈，和极限峰值，方便运维做负载预警系统。做这个测试前，先让技术给一个性能基线（并发人数等。。。），按这个基线进行测试，这个测试是必须要过关的。

    这个测试与协议测试一样建议技术他们提供测试工具，可以通过配置方式来灵活实现测试场景。

5.4.5、破坏性测试与故障演练

    目的是为了验证服务器在部分故障情况的表现。现在的服务器架构一般不会采用单服制来设计，一般会多个服务器甚至微服化，这样需要测试下看看某些服务器关闭后，对整个游戏的影响，以及应对策略。比如正常起服后，聊天服关闭，是否只是聊天不了了，客户端会不会因为连不上聊天服而发生什么状况，一般我们预期是只有对应的功能无法使用，而不能影响其他系统的正常使用，而且在这种极限情况下，客户端的体验需要设计，不要出现“不停的弹出报错对话框”等等。又比如在10台战斗服坏了一台，之前他上面的负载的玩家是否会自动分配到其他服上去，客户端的表现又是什么样的。还有看看服务器在这种情况下重启是否能恢复服务，而不是再也回不来了。只有考虑了这些，设计了这些，做了这个测试才能保证服务器集群是一个健壮的柔性可用的服务器集群

5.5.6、数据测试

    目的是为了测试数据是否错误，这个测试不光是研发阶段要做，产品上线后，DBA也需要定期对线上数据进行检查。这个测试最重要的环节是，设计什么样的日志数据。比如设计所有的玩家购买行为日志数据，玩家等级升级日志数据，玩家背包日志数据等等..... 。通常会要求几个日志之间是要有一定的逻辑关系的，比如购买日志的购买行为，一般会触发背包新增日志。这样做最大的好处是防止玩家因为某些bug刷东西，通过这些数据分析，可以很快发现玩家数据的异常情况。

    测试在研发阶段一定要保证这些日志的准确性，关于数据日志不要嫌繁琐，遇到事了你会庆幸有这些日志，因为就算没有刷东西的情况，老板也会找你要各种数据分析的，因为这是游戏产品的一个特点。

6、临变管理

    关于变更是项目管理中最常见的一个事了，关键看你的管理粒度，对与不同的变更采用不同的应对策略。一般的变更可以管到天、周(几天)、节点3类。一般严重的会影响到节点的比如里程碑或版本完成的为最高级，需要通报和记录，最细的天级一般是这个团队经常出问题，可以采用这种严格的管理方式，直到情况好转。为什么不一直采用最细的管理粒度呢？还是那句话，你的管理重心和精力是有限的。一般小的临变还有很多变通的方式来做，比如用工单系统，在里面加一个临变需求的类型，这样可以保证这个事会有效执行，又可以简单的统计到临变数据

7、项目日志

    项目日志是记录项目过程的一个工具，当项目发生一些事件的时候可以记录一下，因为后面会有各种人找你要时间点，你可以直接查这个日志可以轻松应对。

7.1、功劳簿与过失簿

    在项目开发过程中难免会有人犯错，难免会有人失误，需要把这些问题记录下来，作为一个重要的经验记录下来。

    当然对于一些有突出贡献的同学，对等的也应该记录在功劳簿里。方便在适当的时候可以激励下，或者作为KPI的依据

8、人的管理

    项目管理也是一种管理，管理不光是管事，更重要的是管人。管理者在管人这个方面心态一定要是：你是一个服务者，你是来为大家提供服务的，你是来为大家解决问题的。这篇里面讲的各种管理方法、经验都只是工具，如果人心齐了你的管理会很轻松，可以减少很多管理成本。所有重要的与他们的相处，如果团队大而你又不能顾及到所有人，这里建议你重点关注意见领袖，大部分的时候他们是骨干。而管人的具体方法得看你的情商了，诀窍还是文章开头所提的，你和他们的共同语言，如果你连和他们沟通的基础都没有，就谈不上什么互相理解了