项目管理可以理解为为了达到一个特定的目标，所实施的一系列对项目过程要素的管理，内容包括人员，资源，关系和技术等。项目管理的三个核心要素是：成本，时间，质量。通过平衡协调各方面的资源最终完成既定目标。
小项目通常不需要启动专门的项目管理方法论，仅通过核心管理人员的粗放式管理把控即可基本上满足需求。但是当项目规模越来越大，涉及的各方资源和人员越来越多，粗放式管理举步维艰，需要更科学的项目管理方法论才能支撑项目的如期交付。
而在互联网项目，特别是游戏项目中，市场和行业日新月异，项目的需求变化更频繁，完成项目需要的参与各方更紧密流程配合，更需要项目管理在开发过程中发挥作用，汇总资源，管理变化，掌控进度，把控质量，如期交付。
项目管理能够将项目的开发过程和各方资源进度情况比较透彻清晰的呈现出来，便于资源协调和项目开发人员对总体情况的把握，从而更好的完成自己的本职工作。同时，也能给老板，投资方或者合作伙伴一个清晰可见的项目情况。
游戏行业中，如果游戏能够历经九九八十一难最终取得成功，完整的历程一般包括以下几个阶段：
项目需求提出阶段
主策划/制作人根据自己的市场分析或者老板、投资人或渠道代理等权势要求，提出一个游戏项目总体方案。包括市场行情，竞品分析，游戏的核心玩法，美术风格，2D/3D,游戏类型，特色系统玩法，资源需求，人员需求，项目预算等等内容。方案目的是要打动上位者，获得各方资源支持，让项目能够成功立项。
项目启动阶段
立项成功后，根据项目类型和要求组建核心开发团队，包括前后端主程，主美等(更多情况是，在第一阶段项目需求提出时，制作人就已经召集好了核心开发团队)。制作人规划好版本开发计划，特别是核心玩法demo计划，并同时开始召集更多的普通研发人员。
demo制作阶段
虽然立项成功，获得了一定资源，但是如果真正想得到资源的全力支持，游戏行业的规则是拿出一个令人满意的核心玩法demo。这个demo不需要纷繁复杂的各种系统功能，只需要完成游戏的核心玩法，通过该核心玩法向老板们展示游戏的价值和特色，从而得到真正的立项和完整的资源支持。
游戏基本框架搭建阶段
前后端程序根据需求搭建可以承载目标游戏的基础程序框架;策划继续完善和细化方案;美术和程序确定好资源制作规范，经过demo阶段的磨合，各部门已经可以可行的开发流程。(很多时候这个阶段会弱化，因为核心团队可能之前就配合过，相互了解;而且跟多情况，前后端程序并不会重头开发，会基于之前的游戏项目删繁就简)。
铺量开发阶段
系统功能策划案已经完善，和美术也沟通顺畅，程序基本架构已经完成，剩下的就是各路开发人员分工协作大量的开发各种系统功能，包括但不限于账号，聊天，好友，工会，组队，任务，副本，竞技场，排行榜等等系统。完成第一个可测试的alpha版本。这是一个纯粹对内的版本，能够跑通策划设定的基本游戏流程，各个核心游戏功能都已经具备，只是量还不够。比如，任务只有10个，副本只有3个等等。为了细化迭代周期，可能alpha版本还会有好几次迭代，不断收集内部的反馈持续改进，直到达到外部测试的完成度。
beta版本阶段
这个阶段，游戏的功能已经全部完成，铺量的部分也达到了对外测试需要，需要发放给外部真正的用户进行测试体验，检验游戏是否得到玩家认可，并收集玩家意见，将优秀建议整合进游戏中。为了做出自己满意，老板满意，渠道代理满意，玩家满意的“爆款”，这个阶段也可能会循环多次，不断改进。
正式公测上线
所有准备就绪以后，接受真正的考验，开始上线收费。能不能证明投资人火眼金睛，早就看好了这个游戏和团队?能不能通过自己的努力让老板财务自由?能不能做出一款说出去别人都知道的游戏，从而功成名就?开发成员能不能凑够自己的首付/彩礼,或者买车买房?所有对游戏的付出和努力是否能够得到回报，都在这个阶段可以看到。
持续迭代
如果到这里游戏还没有死掉，已经战胜了市面上90%的游戏了。接下来就是根据新的需求或者玩家反馈，一个个版本持续迭代。不在迭代中数钱数到手抽筋，就在迭代中慢慢死去。(现实是残酷的，也存在另外一种可能：同志们呕心沥血加班加点做成功了游戏，把老板送上了财务自由之路，但是当初的承诺并未得到兑现，然后被卸磨杀驴，落得惨淡出局一场空;有的人忍气吞声，有点人负气出走，有点人无奈转行，有的人删库跑路。。。)
通过以上几个阶段知道了游戏开发从前到后大致会经历哪些步骤。而项目管理，就是要把这个过程有效管理起来，并确保在各种艰难情况下都能够不断前行，如期上线。
在这个过程中，需要建立团队，获取外部资源，形成团队内部的有效沟通机制，定义和细化需求，讨论分工，制定版本计划，管理需求变更，跟踪和管理进度，持续有节奏的按计划迭代前进。
为什么游戏项目管理难做
自我破坏规则
项目管理就是通过种种方法和工具制定一些实施规则，大家通过规则约束和协调互相的工作。而因为种种原因，规则的制定者(老板/制作人等)不能有效的执行规则，导致项目管理流于形式，甚至制定者自己反复破自我坏规则，导致项目成员彻底失去对规则的敬畏。
不重视
老板不重视，有一些不懂研发的老板只关注眼睛可见的产品，对其他冰山之下的部分并不重视，甚至认为是多余。
制作人不重视，有太多团队事物，项目沟通事宜，人员管理问题，甚至外部对接事宜需要处理，“没有空”进行精细化项目管理。
核心人员不重视，研发团队和核心成员是项目执行过程中最有发言权的团体，很多游戏开发人员并未经过严格项目管理训练，都是野路子，自己摸索出来的。而且不少人还有足够的之前的游戏项目经验，“我们之前是这么做的”，从而顺理成章现在也这么做。
项目管理能力欠缺
游戏团队中，项目管理的实际执行人很多时候是主策划/制作人。因为研发的最终产品就是根据他们的方案来执行，他们对游戏设计有深入的理解，是前端，后端，美术等工种的共同衔接人，所以由他们来掌控项目是比较自然的。
游戏开发涉及美术，策划，前端，后端甚至辅助管理&数据分析后台，对外还有美术外包，商务运营对接的时间排期因素，是否能够把项目内容版本规划做得各个工种和部门高度契合，协同工作，是一件高难度的事情。完美的契合就像互相咬颌的齿轮，能够无缝配合，激发更大的生产力。相反，没配合好就会出现工作分配协同不平衡，忙的忙死，闲的闲死，最后还导致版本delay，怨气横生。
更有甚者，其他来路不明的人掌控项目，对游戏，团队管理，项目管理并不擅长，更多是自己边做边总结。导致摸索过程中必然会不断交学费。如果掌控人能力不足以支撑整个研发周期的项目管理，这样的项目管理，自然会变成东施效颦，然而这样的情况并非个例。
多头指挥
多头指挥是指，项目执行过程中，各小组的组织架构关系和沟通流程规则并没有很好的得到规范，导致多个人对同一个人分配任务的情况。更可怕的多头指挥是来自老板，大部分员工很难违背，只能顺从。
正常情况下是主策划的需求提给前后端主程，他们分析确认后确定任务分配给相应的组员开发并确定好时间周期。如下虚构场景是典型的多头指挥：
某策划A直接找到某前端开发人员B提一个功能开发需求，前端主程可能都不知道这个事情。某运营C直接找后台开发人员D做一个活动功能，而后端主程并不知道这件事，同时D也还在做之前的任务。老板直接找到了UI设计师E，让他修改按钮风格，而主美被绕开了。(老板称其为“扁平管理”)。
多头指挥会打乱正常的研发流程和节奏，自然会导致项目管理的失效。
赶时间
由于游戏行业竞争激烈，市场变化快，听得最多的就是”赶时间“，”时间窗口已经快关闭了“，”XX竞品3个月后要上线了，我们必须赶在之前怎么怎么样“，”我们能不能提前一个月出产品?”，“我们先出一个版本上限，其他东西后面再补”等等。赶时间导致各种资源被压缩，而项目管理是需要花一定时间代价换取项目的长远可靠性保证。
需求变化快
项目的需求变化问题，在另一篇文章里面讨论过。主客观原因导致的需求变化，也会给项目管理增加难度。
另外关于游戏需求变化，可以附加一点：从某种意义上说，游戏产品可以认为是一件艺术品，艺术品没有绝对的好坏对错，每个人都有自己的喜好和审美，导致有发言权的人都会是项目需求变化的发起者。
开发人员背景能力参差不齐
游戏开发团队人才背景错乱参差不齐，有科班出身，有的非科班自学成才，有的转行过来。他们的知识结构和做事方法都千差万别，就像把正规军军规直接在山上的游击队里直接执行，起难度可想而知。
人员流动大
游戏团队人员流动较大，甚至会遇到换了3，4波人还未研发完成的游戏项目。成员对项目的熟悉程度，自我归属程度等都不一样，很难采用体系化的项目管理方法一概而论。
项目管理混乱的危害
优秀而高效的项目管理是项目如期高质量交付的有效保障手段，而项目管理混乱会给团对和项目带来各种问题，如下面的几方面问题：
项目情况混沌不清。混乱的项目中，很难说清楚当前项目的进度情况，各人员的工作内容，当前遇到的问题，下个版本的可靠交付时间。
项目delay。项目管理混乱导致很难按计划完成版本任务，导致delay是高概率事件。
团队不能成长。混乱的管理并不能为团队的成长带来帮助，即使当前项目摸爬滚打最终到了终点，那么下个项目还会重复一遍所有的痛苦，团队没有任何成长和积累。
成员不能成长。管理混乱，没有章法，导致团队浮躁，会让成员怀疑这样团队的前途。成员不仅需要技术和专业能力的提升，更需要团队协作，做事做人方式方法的提高。
激发矛盾。一旦混乱后，事情就没有了头绪，各种事情就交织在一起，必然导致各方无规则碰撞，从而产生矛盾与相互埋怨。
增加不信任感。混乱导致成员之间不信任，也会导致老板对团队能力不信任。
如何改进游戏项目管理
项目管理是一个复杂的系统工程，不仅包括项目产品管理还包括团队人员管理。事情本身的复杂性导致很难有银弹毕其功于一役，不过可以从以下几个方面做改进：
团队成员构建。项目是由人构成的团队开发出来的，所有首先要构建一个高素质团队。
团队核心成员最好是有经验老将，每个都能独当一面。如果他们还曾经互相配合过，那就更好。至于普通开发人员可以酌情吸纳一些基础素质好的新人。
项目管理就像军训走正步，如果都是军人那自然简单易行;其次是有经验的老兵带经过层层选拔的素质新兵;再次是所有都是新兵，自然需要采坑自己摸索;如果沦落到瘸子或者幼儿园的小朋友都召集进来了，这个正步走起来恐怕将举步维艰。
提高团队项目管理意识。需要在团队中上下都统一思想，充分认识到利用项目管理的方式管理开发对团队和个人的长远益处。让所有成员都自觉执行和完善项目管理事项。
尽量完善项目规划。游戏项目涉及面广，人员和工种多，需要分工协作密切配合，所以项目初期对项目的总体规划，里程碑划分，各个阶段的任务目标作出清晰完善的定义，便于参与人员开展工作。
做好需求变更管理。需求不变是不可能的，只能尽量控制变化，不产生根本性变化，少产生变化。变化少了之后，就会减少对既有工作节奏和流程扰乱。
专职的项目管理人员。项目管理的执行三天打鱼两天晒网，那么组员就会慢慢失去对项目管理的敬畏和信心。如果制作人忙于各种事情很难精细化项目管理和持续跟踪，可以考虑找专人负责项目管理和进度维护跟踪同步。有专人持续跟踪，有助于项目管理事项真正落地执行产生正面效果，也有助于团队养成正确科学的做事习惯。
梳理科学的组织架构和成员管理体系。从组织架构，工作流程和任务分配上形成固定的负责体系，避免多头指挥带来问题。需求都通过组长评估后分发，并纳入项目管理计划中。不允许绕过必要的环节私下交涉需求和改进。
人员/沟通管理。形成坦诚和有效的团队内部沟通和反馈氛围，使得成员有问题可以被发现和解决，同时他们也有渠道和氛围能够主动沟通。将一些潜在的问题事先解决，而不是等到问题变大甚至不可收拾时才后知后觉。顺畅和坦诚的沟通环境可以减少内部矛盾，进而减少人员流动风险。
借用项目管理工具。工具是位了更高效的完成任务，只要是能够提高效率，合适自己适合团队即可。如：project，PPM，甘特图，XMind，excel等等都可以。