金山游戏运营之我见

      加入金山2年，很荣幸的是，第一年在安全软件呆了一年，有很多的机会参与到其安全产品的运营支撑系统研发之中。第二年又到了游戏部门，负责其一个海外版本的运营研发支持，有幸初步了解了当前金山游戏的产品运营的一些做法及思路。有意思的是，无论是安全软件还是网络游戏，都在努力地尝试向互联网方向转移，这一点在金山游戏公司体现的可能更为明显。

      目前金山游戏的产品运营在业内看来一直是个阿斗，金山游戏的研发就像是辅佐其政务的诸葛亮，双方在过去的很长的时间里都谈不上有什么太多良性的互动。大多数时间里，金山的研发对于运营有着绝对的话语权，这在业内也算是一个特例了。

      金山游戏的运营大体流程如下：

      1. 策划对于游戏内容进行设计，游戏内容的创意来源有以下几个渠道：a. 游戏的历史传承，主要是基于游戏原来的设计背景衍生的一些功能。b. 特定的节日活动，一般是跟着当前的日历走，包括农历节日和公历的一些节假日。c. 原有一些旧功能的调整，包括玩法、数值等方面的调整。d.其他一些创意内容来源，如运营部门提出的需求等（但这方面较少，多数情况是策划主动提）。

         在内容方向确定后，一般会开始相关内容的框架到细节的设计（游戏世界内），主要关注的点有内容的背景设定、特定活动流程的设计、数值平衡计算及奖励设定等。此外，还会关注的方面有：a.活动推出的配套市场行为（一般会与运营、客服部门沟通确定），包括推广合作方的选择、推广成本预算、相关日程计划等。b. 游戏内容的研发资源确定，这需要与产品研发团队（程序、测试及版本制作）进行沟通，确定相关开发计划和日程表。c.其他可能需要关注的方面，如美工风格设定等。

      2. 一般而言，策划在初步完成内容的框架后，就会将内容交由程序着手开发，在双方商定的发布时间点前，一般会一边进行开发，一边进行设计上的调整。从实际的版本开发制作情况上看，在测试到发布的过程中，也出现过需求变更的情况。

          从策划角度看来，内容的设计和跟进始于创意的出现，止于最终的详细设计文档的提交。

          在产品研发组织内部，在版本正式发布之前，会有两个测试阶段，包括了新游戏内容的测试和发布前的最后全面测试。在产品完全通过两个测试阶段后，最终得以通过版本发布平台对外发布。

      3. 版本的发布一般都会需要互联网或者其他媒体的配合宣传，在版本发布之后，论坛和客服会成为版本问题反馈的主要渠道。

      以上是游戏一个版本从设计到制作发布到投入市场的整个运营流程的简要描述，我们可以看到，当中涉及到的部门和功能环节是相对繁杂的。就笔者观察的实际情况而言，产品研发部门的工作量相对较大，加班加点是家常便饭。产品的版本周期是一周一个版本，也许这也是造成工作量大的一个主要原因吧（目前我对于每周一个版本周期尚存疑问，不知道这样设定的原因是为何....:[）。版本运营流程可以用图简化描述如下：

     从上图我们可以比较清晰的看到，当前的产品运营基本是以产品研发为核心进行组织的（为简化计，美术、运营等团队并未在上图体现）。产品研发部门（策划原则上也属于研发的团队）基本上就能够决定运营中版本的内容，整个流程的关键节点有两个，一个是游戏设计，这里的决定团队是游戏策划；另一个是产品研发，这里的决定团队是程序。这两个团队的核心成员（主程序和主策划）即决定了产品的运营方向。在金山的传统上，主策划往往承担了更多的运营方面的决策权。同时，部分内容也受到游戏部门直接领导的一些影响。

      这里一个比较重要的问题可能在于，无论是策划还是程序，都不是一个能直接面对客户的团队（也没有必要和精力，每周一个版本压力下，还能挤出时间分析用户需求的策划只能是Superman了）。因此，对于客户下一步需求的理解就来源于文章前面提到的几个来源，这在很大程度上就造成了外界看来所谓“拍脑袋”的情形。最终的结果只能是离客户的需求越来越远，不可避免进入衰退。

      从目前看来，整个运营流程可以改善，也是亟待改善的环节就是需求分析环节，可以考虑的一个方案是强化运营体系的需求搜集功能，基于数据的搜集和分析，一定程度减少决策中的盲目性。如此以来，上述的流程就演化为下面的结构：

      这里，我们加入了一个产品运营的部门，同时将其与策划、程序提升到同一个量级。这时，相较之前的结构，发生了一些有意思的变化。

      1. 客服部门不再直接向程序反馈相关产品实现上的反馈（当然，出现紧急情况除外，如程序上的严重bug造成物品的非法获得），程序将会集中精力处理设计实现上的问题。

      2. 产品的推广运营计划工作将移交给产品运营部门，策划不再需要消耗精力思考内容的推广安排，可以将精力集中在功能设计的完备性上。

      3. 产品运营部门需要进行竟品市场的分析和产品运营数据的分析，得出游戏内容需要调整改变的方面。

      4. 产品的运维支撑平台也由运营部门负责进行架设并维护，程序只有在紧急情况下才需要对运维的资源进行直接处理。

      5. 运营体系内的产品数据平台也作为策划内容分析的有效手段，增强需求设计的针对性和有效性。

      6. 需求将主要由运营发起，策划与运营基于版本需求进行协作。

      7. 基于以上架构，策划、产品研发将主要作为运营的主要支撑，运营将会以市场为主要导向，多方协作完成游戏产品的持续运营。

      8. 这种情况下，运营人员的能力，尤其是对产品本身的理解能力和数据分析能力将会尤为重要。

 

      本文只是从笔者了解到的情况对现状进行了简单的分析，业内由很多同仁在游戏运营上都做出了极为出色的成绩，笔者也希望有机会能实际了解更多的成功案例。文章也就相当于抛出一块砖，希望能有更多业内的同仁能不吝指正，以期能在将来把文章修改好。