1、管理无定法，有效最关键
管理没有固定模式，管理方法是有达到管理预期结果的手段，项目管理也是如此。游戏项目管理中不同的项目规模、同一个项目不同的时期，同一个时期不同的团队、不同的人，管理方法可能都不一样，这里只列出我的经验和要点，当你面对不同环境的时候，选择一个你认为最合适的管理方法就好。关键的是你选择某一个方法后，要评估这个方法是否真的有效，记住“有效最关键”
2、版本计划
制定计划是非常重要而复杂的一个过程，项目越大越复杂，但是只要按照这个一部一部做，一定可以把计划做好。任何计划都是有变更风险的，计划不如变化但必须有计划。这点必须要给参与项目计划制定的人讲清楚，不要因为怕变更而不敢做决策，一个有经验的主程、主美、主策划都能把变更风险降到最低。这张图说明的是预测与现实的差距
2.1 开发流程
做计划之前先要搞清楚当前的开发流程，不同的行业不同的开发流程，不同的项目不同也有不同的开发流程。这里以一个游戏行业典型的开发流程举例，他包含版本规划、策划设计、UI设计、程序开发、测试几个阶段。中间有几个关键里程碑一个是制定版本内容（版本规划），一个是需求说明会（确定相信策划案），策划评审（开发完成准备策划进行确认）
另外美术的制作流程也是差异很大的，这里以一个3D场景的流程为例，包括策划设计、原画设计、3D场景物件建模、场景地图编辑（烘培、减面）、游戏接入等环节，也包括2个较重要的里程碑，需求说明会（说明设计意图）和策划评审（对产出资源的评审）
2.2 版本规划与需求池
游戏项目的一个版本开始前，第一步由制作人、主策划定出版本内容。还记得上一篇（规划篇）中提到的产品规划吗，可以直接参考它来制定，当然大部分的情况下都会根据实际情况进行调整。另外，版本规划中不光有策划的需求哟，一般还会有技术相关的底层需求，还有美术相关的资源需求，所以这个版本规划是需要主程、主美、运营共同参与讨论制定的。
还有另一种制定方法，就是“需求池”。这是指策划把已经规划、设计好的需求集中管理的一个地方。需求池的策划内容可能是制作人的一个想法，一个设计，也可能是某个版本上线后的玩家反馈、运营反馈、老板反馈，等等，不管来源是什么最终制作人、主策划决定要搞了就先放到这个需求池里，防止后面做版本计划的时候又忘了。这种一般在游戏上线后的项目管理应用比较多，非常实用。需求池一般包括需求条目、优先级、预期开发版本、状态、策划负责人、需求来源等。
举例
2.3版本计划制定
学过PMP的应该都知道WBS，首先在策划定出的版本内容上进行任务分解，这里的经验是：把需求任务分拆到一个人可以独立完成这个粒度，这样方便管理。
做完分拆后，对每个任务进行负责人分配，如果是外包写上外包接口人。这个人员分配步骤比较复杂，因为每个人工作能力不一样，适合做的任务也不一样。这里有个实用的技巧，一般可以设定个原则来进行分配，这样可以简化这个人员分工问题，举个例子，程序员的分配，可以设定几个小分组，相对固定，比如A小组主要负责玩法的开发，B小组负责系统的开发等等，有了这个分工，先按这个分工来，再根据后面的实际分配情况（分配不均）再做微调，另外，这个过程可以由主程、主美主导，因为他最了解他们。
Power管理法，这是一个改进的条状图（甘特图）的管理方法，包括：内容、优先级、负责人、状态、时间排期，而排期是用如下颜色区分的。这个比传统的甘特图更直观，更符合软件、游戏项目管理现状。当然他忽略掉了某些重叠部分的可能，但那部分不会对各工作造成影响，这样不会过细，也不会过粗。
这里的审核包括，需求评审会、策划审核两个里程碑的时间。而美术也可以用这个来计划比如这样，你可以根据你的工作流来灵活定义
每天项目经理在跟进完进度后需要在上面标一个“*”号来说明这个事情确实在做，没问题，如果出现问题了，可以写上备注，或者调整计划。一个版本下来这个表格就是整个项目的“真实情况的反映”。
边界说明会，策划拿到版本规划后，主策划需要先讲解给所有策划，让大家了解“需求目的”与“内容边界”，然后策划在消化后尽快同步给主程序、主UI等相关负责人。因为他们要根据你的“需求目的”与“内容边界”进行时间评估
经验：“内容边界”是最重要的这个决定了工作量，负责实现这个需求的负责人要充分预估他的难度，和策划的隐性需求，这个非常考验负责人的经验。
经验：当一个任务过于复杂，请负责人尝试把他进行拆分，拆到一个版本、一个执行负责人的粒度
2.4 策划的时间分配
分配完人之后就是分配时间了，这个一般是从前往后先排策划的设计时间，一般策划尽量把一部分在版本开始前就设计好，这样不至于出现版本开始前其他所有人在等策划了。
策划说明会，记住一定要在策划案后排一个策划说明会（里程碑）的时间，要求策划在后续工作开始前进行这个会。目的有两个，一是为了确认策划案，二是让所有参与这个任务的人在一起交流发表自己的观点。
经验：提前把策划案发给所有相关负责人，这个会的目的不是为了在会上聊细节，细节策划要提起和主策划、相关的负责人沟通清楚，尽量保证会上能通过策划案。当然如果策划案写得差，没有事先沟通，被程序、UI一顿屌，重新写策划案，重新开需求说明会的概率会很大。经验：策划说明会，可以看出策划的设计能力，同时也能反映出技术负责人的经验。
2.5 UI的时间分配
UI时间最大的变数在于，风格的不确定，这个在计划的时候考虑给最大干系人（一般是制作人甚至是老板）的审核时间，建议效果图尽可能早的给他们看。另外，程序开始前需要UE设计交互逻辑，为了节省时间，在定出交互后先实现框架，UI框架、交互逻辑先提交给程序实现逻辑，UI画面细节可以同时并行完善。
经验：一般定风格都会改几版，甚至整体风格。
2.6 程序的时间分配
游戏项目一般有个特点，程序部分一般是由客户端程序员和服务器程序员共同完成，所以一般在制定完计划后需要分别看两个程序员的工作是否排布合理，如果排布不合理经常会出现开发完了没时间联调的情况。按前面所说，尽量绑定小组负责制，可以减少这种冲突的情况。
经验：一般游戏项目组的客户端程序员、服务器程序员配比是2：1的比例，也就是客户端的人会多些，因为客户端相对工作量会大，所以一般按客户端的时间来评估整个技术的时间，服务器能保证在客户端完成的时候可以完成就可以了，而且一般服务器是可以多项工作并行的
2.7测试的时间分配
游戏项目中在开完需求说明会后，测试就可以开始写用例了，这里就不需要管理他们的时间，只有他们在开始测试前写好就可以了。而一个版本通常会在最后阶段排一个专门的一周进行测试回归，这个用来进行版本回归测试。
2.8美术的时间分配
美术的计划特点是时间相对固定，如果是自己人做一般都比较好评估，如果是外包，则一定要考虑，外包返工修改的时间，而发包前的外包商测试，则尽量在任务开始前完成，不然这个任务铁定延期。
3、风险评估
计划做好后，就是把关键路径找到，通常是最长的那个，看看他的优先级如果比较高，尽量提前做吧。风险评估高的任务最好都安排实力相对强的同学做，尽量避免延期。
经验：如果一个任务不能在回归测试前完成程序开发的话，基本也有打不进包里的风险，风险评估项里写进去，提前告诉制作人。
4、工单管理
工单管理工具有很多，什么禅道(bugfree)，JIRA，可以根据实际情况选择，可以在计划制定完成后，开始给各负责人派发工单，工单管理流程可以根据使用的工具灵活选择，不过录入工单是一个非常痛苦的过程，而调整计划后的调整工单更痛苦，所以我们只用工单来管理小任务（计划上没有的临时任务）和BUG，这是一个典型的工单流程，工单的状态定义可以自己根据实际情况来定义，关键是大家都能统一：
