作为一个游戏公司，我们运营的是一款游戏，游戏本身是在不断迭代中的。所以在某些版本上，一定会有不足，会有设计上的偏 差。游戏成功的核心是游戏性，在游戏本身没有硬伤的情况下，假使某一个版本上出现了不足；这个时候，游戏的运营人员要身先士卒，用各种运营方法，做活动也 好，搞舆论也好，要让游戏渡过这个不足的阶段；保持用户和收入的良好延续，顺利交接到下一个版本。
它强调的是产品与运营的协同合作！而不是把一坨屎拉出来丢给运营，让运营把臭味去除，变成香味，甚至点屎成金。
产品和运营是两个轮子，这个公司是自行车；加上开发，是三轮车；再加上市场，就变成了汽车。
轮子如果一只圆一只方，这车肯定走起来又问题，轮子如果都是圆的，但大小不一样，那走起来也不会稳当。
这里的话题就直接被替换成了，如何让产品和运营协同合作，共同走向幸福的美好生活。
办法是有的，但是在实际过程中，一定会出现「屁股决定脑袋」，减少这种现象的发生，才能让业务跑得更快，这里有几个方法，有些方法是给人力资源看的，有些方法是给产品、运营看的，各取所需。
我经历过项目组架构，也经历过扁平化架构，个人的体会是，项目组架构下，可以最大化的保障产品、运营、开发三个组织的沟通的便利程度、协同的积极程度。
因为项目组架构下，大家对业务的交流和理解会更同步，业务的目标一致，背负共同的KPI，想不通力合作都不行，想互相指责都没机会。
扁平化不是不好，但扁平化对于产品经理的协调能力，对整个组织成员的主动性都有极高的要求。
有时候扁平化更容易出现排期扯皮、责任互相推的现象，因为不论产品、运营、开发，做的都不仅仅是一个项目，这个时候想要通力协作，比较难。
产品在做设计前，要考虑运营的可行性；运营则要考虑产品的复杂度。
很多时候，产品、运营、开发会互相吐槽：「这事儿很简单啊，你怎么OOXX」
运营提出的一个小需求，可能涉及多个系统，这些系统，运营并不一定完全了解，产品甚至都不如开发了解。
产品做一个小改动，可能造成很多影响，譬如，支付宝9.0去除锁屏密码这个动作，我认为在设计前产品经理可能是对用户的负面反馈没有比较深度的认知的。
保持沟通，非常重要，很多人说，但很多人停留在嘴上。
产品经理要能够听取运营的反馈，并愿意花时间从专业的角度给出结论。
运营要能够敏锐的从运营数据中找到用户的潜在需求，并可以用产品经理能够简单理解的方式来表述需求点，讲究需求的逻辑性。
每一次版本变更涉及的功能，产品应当去与运营进行沟通，大家用数据来说话，改了什么，为什么改，需要运营做哪些动作，引导、公告、安抚、活动，这些事情要提前沟通，预案提前准备。
大版本发布前，产品、运营要一同加入测试，从逻辑层面、操作层面、用户感知等各项层面对大版本的调整有充分的认知，并做好各项准备工作。
不管是产品、运营、开发、市场，很容易看到业务上的一些风险，但角度不一样。
这个时候，千万不要认为只要自己做好自己这一块就好，别人的部分，别人自然会去做，就算做不好，锅也不是我背。
把你看到的有关业务的风险share出来，让相关人员知晓并进行评估，非常重要。
虽然这一点理应放入沟通的范畴，但我认为这还真的值得拿出来单独说一句。
不要用运营能力去掩盖产品上的瑕疵。正视并对症下药，才是解决之道。
