如果要一句话概括，大多数原因来自市场风险和项目控制风险，市场风险：玩家对于一款游戏的认可度对运营商而言很大程度上属于不可控因素，市场预期很好的产品可能反馈很差，预估一般的产品反而可能很好，所以长尾理论在这里起了作用：构建广泛兼容&快速发行的平台，拼命上产品，只要少数获得市场成功，就可以赚取可观利润。

好了，言归正传，谈我们可以控制的项目管理风险。

目前看来最大的风险是产品中的问题不能被及时解决。产品运营是一个复杂的问题，它往往纵向覆盖产业价值链上下游，而在运营商内部又横跨多个部门组织，涉及的角色包括：研发，产品经理，QA，运维，客服，甚至渠道、市场、公关等。问题处理要求在这个信息链上传递和反应的速度足够快，而不是在有问题时一味的寄希望于危机管理。

第三方代理型产品，出了问题例如bug修复和根治需要依赖研发商，这一方面与双方约定的合同有关，另一方面还有势--运营商和研发商双方的强弱势关系。比如中文语言版的客户端有一个严重bug，而研发商（韩国）正直假日，无人上班，该研发商在全球范围的内同款游戏的收入很高，不care中国大陆地区这个版本的收入分成，这个时候对于运营商而言可能就比较被动。

对于自主研发的产品，研发的角色在公司（集团）内部，为下属部门或全资、控股子公司（工作室），或许看官您觉得好办了？其实不然，在部门林立的公司内部，对于发现的问题如何定级，究竟谁说了算，谁来主导PDCA的过程，信息能否有效的自下而上传递，相关的部门是否都对结果买单并快速做出响应，这些都是问题。认识问题严重性的人不能主导过程，影响力、话语权、职权不够，在沟通上缺乏技巧，或信息不能被有效传递。

第三种情况，当涉及第二个外部研发商（例如中间件、反外挂组件、IGA）的时候，这种沟通就更复杂。

对于这些问题，有几个改善的方面：

1.强化治理结构：

1.1定义清晰的权责，产品的每个模块都必须有唯一负责人；完全的绩效激励，利润分成，例如项目失败则团队解散，驱动研发团队必须对产品成败负责。

1.2变传统部门式管理为项目（流程）主导的矩阵式管理，淡化部门间隔阂，提高项目经理的地位，并确立对应的高层项目负责人员（VP以上）

2.强化沟通能力，这几乎是个无法回避的问题，光精通技术是不行的，游戏负责人（包括技术负责人）必须擅长沟通，或者至少懂得如何利用自己的上司去沟通，确保问题得到处理。例如即便在利润驱动型的治理模式下，研发有时候也能懒则懒，把问题转嫁于运维，寄希望于运营IT架构或中间件调整，这种情况下要求项目经理能在公司内纵横捭阖，驱动研发团队解决问题。

3.强化内部流程，提供科学的指导方法以加快处理速度并保证效果。

4.建立事前应对，事中变通处理的风险规避方案，而不完全求助于事后应对

5.鼓励创新，在产品或运营IT架构中植入自动反应模块，加速处理或简化过程

（待续）