没有固定的管理模式，管理方法是实现预期管理结果的方法，项目管理也是如此。在游戏项目管理中，不同的项目规模、不同的项目阶段、不同的团队和不同的人可能有不同的管理计划。这里只列出我的经验和要点。当你面对不同的环境时，选择你认为最理想的管理计划。关键是在你选择某种方法后，你应该评估它是否真的有效，并记住“合理是最重要的”

    设定目标是一个非常重要和复杂的过程。项目越大，就越复杂。然而，只要我们一个接一个地做，我们就能做好计划。所有的计划都有变化的风险，计划不如变化，但必须有计划。这一点必须向参与项目计划的人解释。没有必要因为害怕变化而不敢做出决定。经验丰富的主要旅程、主要美容和主要计划可以最大限度地降低变化的风险。这张图解释了预测与现实的区别

 2.1 开发流程

     在制定计划之前，首先要了解当前的开发流程，不同行业的不同开发流程，不同的项目也有不同的开发流程。以游戏市场的典型开发过程为例，它包括版本规划、规划设计、UI设计、软件开发和测试。中间有几个关键里程碑，一个是制定版本内容(版本规划)，另一个是要求说明会(明确相信规划案例)、规划审查(开发完成准备计划核对)

    此外，艺术的制作过程也大不相同，这里以3D场景的过程为例，包括策划设计、原画设计、3D场景物品模型、场景地图编写(烘焙、减面)、游戏连接等环节还包括两个重要的里程碑，要求说明会(表示设计意图)和规划审查(产出资源审查)

 

2.2 版本规划与需求池

    一个版本的娱乐项目开始前，第一步是由制片人和主策划定版本内容。还记得上一篇文章(规划文章)中提到的产品规划吗，可以直接参考它制定，大多数情况下自然会根据实际情况进行调整。还记得上一篇文章(规划文章)中提到的产品规划吗，可以直接参考它制定，大多数情况下自然会根据实际情况进行调整。
此外，版本规划不仅有规划要求，还有与技术相关的底层要求和与艺术相关的资源需求。因此，目前的版本规划必须参与讨论和制定的主要程序、主要美容和业务。

    还有一种制定方法，那就是“需求池”。它指的是规划和集中管理已经规划和设计的地方。需求池的规划内容可能是制作人的想法、设计或玩家反馈、业务反馈、老板反馈等，无论最终制作人的来源是什么，主规划决定进入需求池，以避免以后的版本计划和忘记。这种类型在游戏上线后一般用于项目管理，非常实用。需求池一般包括要求内容、优先级、开发版预估、情况、规划责任人、需求来源等。

举例

制定2.3版本计划

    学过PMP的人应该知道WBS。首先，他们在计划下一个版本内容时进行任务分解。这里的经验是，将需求任务分解到一个人可以及时完成这个粒度，便于管理。

    分拆后，如果外包附有外包接口人，将责任人分配给每项任务。人员分配过程比较复杂，因为每个人的工作能力不同，能做的任务也不同。这里有一个易于使用的技能，一般可以设置一个分配的原则，可以简化人员分工问题，例如，程序员分配，可以设置几个小分类，相对固定，如A组主要从事游戏开发，B组承担系统开发等，有分工，根据分工，然后根据具体分配（分配不均匀）进行调整，此外，这个过程需要由主、主美核心，因为她最了解他们。

 

   Power管理法，这是一种优化条形图(甘特图)的管理方法，包括:内容、优先、责任人、情况、时间表，排名应分为以下颜色。

 

   Power管理法

，这是一种优化的条形图（甘特图）管理方法，包括：内容、优先级、负责人、情况、时间表，排名应使用以下颜色。这比传统的甘特图更真实，更符合软件和游戏项目的管理。当然，他忽略了一些重叠部分的可能性，但这部分不会影响每个工作，所以不会太薄或太厚。

    这里的审计包括两个里程碑：需求评审会议和规划审批时间。艺术也可以用这个来解决这个案例。例如，您可以根据您的工作流程灵活定义它

    跟踪进度后，每日项目经理需要在墙上标记一个“*”来解释这件事真的在做，没有问题，如果有问题，你可以写注释或调整计划。这个表格是整个项目“真实情况的体现”。

界限说明会

，在计划获得版本计划后，主计划需要首先向所有计划解释，以便每个人都能理解“需求目的地”和“内容界限”，然后计划在消化后尽快与源程序、主UI等相关负责人同步。由于他们必须根据您的“要求目标”和“内容界限”进行长度评估

   

经验

：“内容界限”是最关键的，这取决于任务量。负责完成这一需求的负责人应充分预测其难度和计划的隐藏要求，这是对负责人经验的考验。

   

经验：当任务过于复杂时，请尝试将其拆分为一个版本和一个实施负责人的粒度

2.4 计划时间安排

    然后是分配时间，这通常是从前到后规划的设计时间，一般规划试图在版本逐渐设计的一部分，在版本开始之前，其他人都在等待计划。

    规划说明会，记得在规划案例后面安排一个规划说明会(里程碑)的时间，规定规划会在后续工作中逐步进行。

    计划会议，记住在计划案例的后面有一个计划会议（里程碑），并规定计划在后续工作中逐步进行。有两种目的，一种是确定计划案例，另一种是让所有参与这项任务的人一起交流和表达他们的观点。

   

经验：提前将规划案件发送给所有相关负责人。本次会议的目的不是在会议上讨论细节。细节规划应与主要规划和相关负责人明确沟通，并尽量保持会议能够通过规划案件。但是，如果策划案写得不好，没有事先沟通，被程序和UI重写，重新要求解释会的概率会很大。

   

经验

：规划说明会，既能了解规划的设计能力，又能体现项目负责人的经验。

2.5 UI的时间安排

    UI持续时间最大的变化是风格的不确定性。在计划时，考虑给更大的相关人员（通常是制片人甚至老板）审批时间，并建议尽快向他们展示效果图。此外，程序逐渐需要UE设计交互逻辑。为了节省时间，架构在设置交互后首先完成，UI架构和交互逻辑首先提交给程序以实现逻辑，UI图片的细节可以并行完善。

   

经验

：一般来说，固定风格会改变几个版本，甚至整体风格。

2.6 流程的时间安排

    娱乐项目通常有一个特点。程序部分通常由客户端程序员和服务器程序猿合作。因此，一般来说，在制定计划后，我们需要看看两个程序员的工作是否有效。如果排列不科学，经常会出现开发后没有时间联合调整的现象。按照前面提到的，尽量关联小组责任制，可以减少这种矛盾。

   

经验

：一般游戏项目组的客户端程序员和服务器程序猿准备是2：1比例，也就是说，客户端会有更多的人，因为客户端的相对任务量会很大，所以一般根据客户端的长度来评估所有技术的时间，服务器可以确保客户端可以进行，而且，一般服务器可以平行工作多种类型

2.7测试时间安排

    娱乐项目开完需求说明会后，可以通过测试来写用例。这里不需要管理他的时间，只有他们在开始测试之前才能完成。在最后阶段，一个版本通常会在一个专业的一周内进行测试和回归，这用于版本回归测试。

2.8艺术的时间安排

    艺术方案的特点是时间相对固定。如果你自己做，你通常会得到很好的评价。如果是外包，你必须考虑外包修改的时间。如果外包商在分包前进行测试，请尝试在任务开始前完成，否则任务将推迟。

    计划完成后，就是找到关键路径，一般是最长的，看看他的优先级，如果很高，尽量提前做。

    计划完成后，就是找到关键路径，通常是最长的，看看他的优先级，如果很高，试着提前做。风险评估强的任务最好分配实力相对较高的学生，尽量减少延迟。    经验：如果一项任务不能在回归测试前完成软件开发，基本上就有风险不能进入包，写在风险评估项目中，提前通知制片人。     工单管理工具有很多，禅是什么？(bugfree)，JIRA，可根据实际情况进行选择。计划制定后，可逐步向各负责人发放订单。工单管理步骤可根据使用的工具灵活选择，但上传订单是一个非常痛苦的过程，调整计划后的调整订单更痛苦，所以我们只用人单来管理小任务(方案中没有的临时任务)和bug，这是一个典型的订单步骤，订单状态的定义可以根据实际情况来定义，关键是每个人都能统一：