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.问题处理流程
大多数团队都会有一个工单系统，比如禅道（）、Jira、QC、TAPD等。无论如何，你必须有一个在上面运行bug跟踪流程。项目经理需要分析项目的质量数据每周，比如产生和解决的Bug数量、每个模块的质量、Bug最多的模块、出现问题最多的人等。
5.3. 开发过程质量管理
对于软件开发来说，除了一般的Bug之外，还有两类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. 临时变更管理
变更是项目管理中最常见的事情。 关键取决于你的管理粒度，针对不同的变化采用不同的应对策略。 一般变更可以按三类进行管理：日、周（多少天）和节点。 一般来说，那些会严重影响节点的，比如里程碑或者版本完成度，是最高级别的，需要报告和记录。 最小的级别通常是团队经常出现问题的时候。 可以采取这种严格的管理方法，直到情况好转为止。 为什么不总是使用最精细的管理粒度呢？ 再次强调，你的管理重点和精力是有限的。一般来说，有很多替代方法来处理小的临时变更，例如使用工单系统并在其中添加一类临时变更需求。 这样既可以保证事务有效执行，又可以简单统计临时变更数据。
7. 项目日志
项目日志是记录项目过程的工具。 当项目中发生一些事件时，你可以记录下来，因为后面各种人都会向你询问时间，你可以直接查看这个日志来轻松处理。
7.1. 信用簿和过失簿
项目开发过程中，难免有人犯错误，也难免有人犯错误。 这些问题需要作为重要的经历记录下来。
当然，一些做出突出贡献的学生也应该记入学分册，可以在适当的时候作为激励，或者作为KPI的依据。
8.人员管理
项目管理也是管理的一种。 管理不仅是管理事，更重要的是管理人。 管理者管人的心态一定是：你是服务者，你是来为大家提供服务的，你是来为大家解决问题的。 本文提到的各种管理方法和经验只是工具。 如果人们团结起来，你的管理就会很容易，可以减少很多管理成本。 与他们相处很重要。 如果团队规模很大，你无法照顾到所有人，建议你重点关注意见领袖。 很多时候他们是骨干。具体管人的方法就看你的情商了。 技巧就如文章开头提到的那样。 如果你和他们有共同语言，如果连沟通的基础都没有，就不会有相互理解。
