游戏运营必备的三张表

    我做游戏运营的时候，习惯找研发索要的三张表，被我称呼为运营三张表。

    1、系统总览表：列出这游戏当前计划版本和下一个版本的全部系统并且按【自定义的逻辑】进行分类。

    为什么要？做运营的固然是需要去熟悉游戏，但是不管游戏还是半成品状态或者游戏已经上线但是运营人员刚刚接手，是非常常见的情况，这个时候就需要通过研发或者自己设定这样性质的表，对要负责的游戏大概是什么，自己具备一个实际体验加策划文档理解的整体概念。

    2、系统开发节奏表：在系统总览表的基础上，和研发沟通，知晓目前各个系统的开放节奏，这个表完成的基础上，才有可能根据自己的经验和历史数据，还有目标，具备出一个谈调整或者不调整的可能。

    3、核心系统付费测算表：在前两个表的基础上，进一步的对商业化的部分进行测算，分别假定免费用户和付费用户能达到的极限值,以及相同条件下，不同付费系统的战力提升性价比（例如，X级情况下不同系统花费1元后可买的战斗力），这个表成型后，才能说是通过文档阶段，具备对游戏的基本了解和梳理，这样才能就如何相对有效的调整付费有共同的讨论基础。

    去要运营三张表的时候，会有什么常见问题和解决方法呢？听我细细到来。

1、系统总览表：

    实践中的问题：不给，打死也不给，为啥呢？因为这玩意其实是一个极简状态的游戏整体再梳理，而一个项目都到了这阶段了，能出这个表的人要么懒得写，要么可能有无谓的警惕心。

    解决办法：总之，如果权责不对等，那只能自己去反推一个，然后和看起来还愿意说话的策划私下沟通——当然，从好的地方讲，这也是一个非常方便和快速的校验器，通常仅需提出需求和2到3天看反馈结果，就可以方便自己从非“正常业务角度”判断，这个项目未来的合作可能是一个什么状态。

2、系统开发节奏表：

    常见的问题：总表能顺利给出来，这个表一般也跟着就出来，只是很容易和线上实际跑出的体验不符，因为通常配给这个表的，主要是从历史总纲性文档（而非实际变更后的策划文档）里去汇总。

    解决办法：也没什么好办法，申请下对方策划文档的只读权限，多读读更新列表，多实际跑跑游戏，然后一个系统一个系统的去一起过。

3、核心系统付费测算表

    常见问题：前2个表都能顺利出来的， 数值策划严重不配合：“你想做什么？”“你在教我做事？”“你是数学系的吗？”

    解决方法：其实吧，都这一步了，还遇见这样的问题，最好的解决方法是远离这个项目，如果做不到，因为所有的调整，你都不可能绕过数值，而研发体系里数值策划自己不情不愿，甚至仅仅只是要个这样的表就引发“你在教我做事”的抵触，那可真的是大大的不妙。——我是分割线——觉得好可点个【在看】