文章目录：
一、运营人员、产品人员、设计师、程序员四者该怎样合理共存呢?
谢谢邀请！
其实在回答这个问题之前，我多少有一些犹豫，所以我没有在被邀请的第一时间来回答这个问题。虽然跟在岗位后面的动物所具备的某些特性跟岗位有那么一丝契合（有相似性），但还是感觉多少有一些不妥，就像我们平时说的很多对岗位的描述是无法放到台面上的一样。
所以我在回答这个问题之前，我首先声明一下，我并没有认可岗位和动物之间的关系，更没有不尊重任何人的意思，请勿对号入座。
我程序员出身、目前也带软件开发团队多年，经历过大大小小很多项目，自然跟运营、产品、设计、程序都打过交道，这些角色有各自的任务，同时又有太多的交集，虽然大目标是统一的，但是毕竟各自的岗位职责不同，有的时候冲突也在所难免。这么多年来，我也总结了一些经验，今天就这个问题，跟大家分享一下。
首先，我把岗位再细化一下，我把产品经理、策划、运营统一到产品阵营，把架构师、视觉设计、交互设计划入设计阵营、把项目经理、前端开发、后端开发都归入程序员阵营。
产品阵营负责产品的定位、功能等内容，产品阵营赋予产品的灵魂。设计阵营出方案，而程序阵营则负责实施。这三个阵营中，产品阵营早期跟设计阵营交互，设计方案确定之后交给程序阵营，然后项目经理负责项目的进度和质量，最终把产品在规定的时间周期内交付给产品阵营验收，如果一切顺利的话，这三个阵营会非常愉快，但是往往不会那么顺利。
这么多年以来，导致产品阵营与设计阵营和程序阵营矛盾重重的原因无非就是以下几点：
第一，产品阵营调整需求很随意（或者给其他阵营的感觉是这样），导致其他阵营被动接受。
第二，产品阵营不认可其他阵营为此付出的劳动成果。
第三，由于产品阵营的问题导致项目延期，结果其他两个阵营被动背锅。
所以，不能和谐共处的原因，在我看来还是制度出了问题。为了解决这几个问题，我们团队制定了以下规则：
第一，产品阵营在调整需要时要进行严格论证，要有理有据，至少要经过两次集中论证，在第二次论证时要求公司的产品总监、财务负责人、设计、项目经理共同参加，当确认需求之后，马上为此次需求拨付专项资金。
第二，设计阵营出新版设计，计入一定比例的绩效工资和奖金。
第三，程序阵营立即封板，以完成情况定绩效和奖金，这主要是认可程序员的工作。
实际执行过程中可以灵活一些，如果产品（上线前产品，上线后运营）要求新增加一些小功能，只需要程序阵营直接对接时，那么直接定绩效就可以了，这跟医院的“挂号看病、付费取药”多少有些类似，每一次调整都需要产品确认。
我的研究方向是大数据和人工智能，我会陆续在头条上写一些相关的科普文章，感兴趣的朋友可以关注我的头条号，相信一定会有所收获。
如果有大数据相关的问题，也可以咨询我。
谢谢！
二、产品和运营这亦敌亦友的关系,是时候做一个了结了
一个互联网产品团队，核心角色是产品、运营、研发、UI/交互。这四者之间的关系分两种：
但是在产品和运营协同工作的过程中，会出现很多复杂又难以解决的问题，分别举例如下：
运营认为，产品不重视运营，但运营却要为产品背负责任：
产品认为，运营总是没起到应有的作用：
以上描述虽极端，但很有代表性，相信很多公司的产品和运营同学都有过类似感受。因此，让这两个角色配合默契、有序运转、形成合力，并不容易。下面就聊聊产品和运营这亦敌亦友的关系。
1.原因是什么
产品和运营配合出现问题的根本原因是：两者目标不一致，导致从出发点到具体执行都是两条平行线，不能拧成一股绳，就无法形成合力。由此可见，将产品和运营的目标统一，是解决这个问题的核心点。
为什么会存在目标不一致的现象呢，因为屁股决定脑袋。从组织架构的角度说，很多公司的产品和运营分属两个团队，由两位不同的老大负责。
既然团队和老大都是两个，那么目标肯定也是两个，否则就无法衡量这两个老大和两个团队的价值。比如，两个人炒一盘菜，一人负责切，一人负责炒，那色香味俱全是谁的功劳，味如嚼蜡谁又是幕后黑手，就很难分辨了。如果两个人互相推脱责任，就进入到扯皮阶段了，很难根治。
一般在团队分工时，都会避免工作内容和目标有重合，保证团队或个人的独立性。这样做的目的是保证员工的个人发展空间，也便于清晰的衡量工作产出，暴露所存在的问题。
综上可知，因为团队分工的问题，导致了产品和运营的目标不统一。除此之外，两个团队的架构，还会带来其他负面效应。比如两个老大为了争夺话语权，出现对峙的情况。这种状态的起因是私利，而非工作，势必会影响到决策的合理性，最终影响产品的进展。
2.如何解决
说到这里，想起自己在百度的经历。第一年时，产品和运营是分开的两个独立团队，原因见上文。虽然整体上还算正常，但也会出现各自为战的情况，运营做活动、核心用户和内容策划；PM为了不断提升转化等数据，做着各种产品优化。单独看任何一方的工作都是正常合理的，但两边同时来看就能发现交集和协作很少。
第二年时，为了孵化独立的新项目，优化了团队架构，每个新项目都成立独立团队，每个团队都有一位PM作为负责人。虽然每个团队都不到十个人，但所需角色都有，比如产品、运营、研发、设计，麻雀虽小五脏俱全。
在这个小团队里，虽然每位成员分工不同，但关注的目标是一样的，只是大家通过完成自己的任务去达成这个目标。比如，
不仅如此，在每天的晨会（站会，10分钟）和每周的例会（1个小时）里，大家会抛开自己的分工，一起加入产品的讨论。虽然经常会有不靠谱的建议，但这才像一个团队。
但这个模式也有缺点，就是只适合5-20人的小团队。如果人数增加到30人，就肯定行不通了。原因是：
所以，如果可以拆分成小团队，或者本是小团队的公司，可以尝试上述的方案。一旦团队规模变大，就不再适用了，这也是业内都很羡慕团队「小而美」的原因吧。
当然，大团队也不是无解，可以通过扁平化的团队架构，来缓解产品和运营配合不好的问题。比如一个总监同时管理产品和运营团队，这两个团队分别有1个经理级中层，再各带一个小团队。这样的三层团队设置，从层级上来讲是可以接受的，承担30人的团队也是没问题的。
3.谁更有话语权
说起产品和运营的关系，就不得不说话语权的问题。这两者一定会存在强势和弱势的关系，不可能有一碗水端平的状态，只是强弱差或大或小而已。当然，谁都希望能主导项目，但是有时候并非是自己能左右的。
决定一个团队是产品驱动还是运营驱动，有两个因素：
一个工具型产品，肯定是产品驱动的，比如天气、笔记、拍照类app，即使渠道的作用很大，但也不会成为驱动方；一个O2O产品，肯定是运营驱动，比如团购、到家类app。
所以，如果要看一个团队里哪个角色更有话语权，哪个角色是主导地位，就从上面两个因素中就可以看出。
4.该怎么配合
团队架构就说到这，那么产品和运营应该怎么配合，才是合理的，是可以发挥双方合力的。我认为，分为产品上线前和上线后两个阶段。当然，可能没有这样纯粹的阶段，但有这样的状态。
上线前：
第一步：产品的功能规划以及发展方向，都是老板的决策。在决策完成之后，应该告知团队全员，项目的背景、方向和规划，让大家充分了解信息，对于后续执行的过程是有帮助的。
第二步：之后执行环节的规划，就是产品和运营协同工作的开始。比如，受众人群、功能特点、版本节奏、运营规划等，应该双方一起参与讨论，得出一个大概的框架和计划。
第三步：按照框架计划，大家开始分头行动。产品去画原型，定功能细节；运营做准备内容、流量渠道和核心用户，以及策划上线后的爆点。在这个阶段，产品和运营可以暂时分离开，不必有频繁的协作。但由于有了前两步的铺垫，在分头行动的过程中，双方也了解对方的计划和进展，所以信息是互通的。
第四步：上线前的准备阶段，之前分头行动的产品和运营的双方，就要再次回到一起，交出之前的作业。也就是大家为产品上线所做的准备，进展、遇到问题和后续计划是什么，拿出来互通和讨论。问题都解决后，就可以上线了。
上线后：
进入到产品正式运转阶段，产品和运营再次结合在一起协同工作。在这个阶段需要高频次的沟通，以及互相推动彼此的工作。
运营，主要关注用户反馈。
产品，协助运营的规划和执行工作
当然，在产品上线前后可不只是做这些事，上面只是提到需要产品和运营配合的节点。由于每个项目的情况都很复杂，所以上述事项肯定也不全，只能是作为一个思路，举例说明。
4.为什么不少运营想转PM
其实产品和运营的关系，描述起来非常简单。产品负责功能设计，也是研发和设计师等支持满足方的接口；运营负责维护、拉动和推广，机器不能解决的问题，都需要运营来解决。
在我看来，产品和运营是两类不同但平等的职位，所需人才的类型也是不同的。但为什么现在很多新人更愿意从事产品工作，甚至已经做运营的同学也希望转做产品，主要是因为「产品经理被神话」而带来的供求不平衡造成的。
主要原因是李开复、周鸿祎等明星Boss，都公开宣称自己是产品经理，把这个职位的工作内容描述的过于理想化，这样就吸引了更多优秀的年轻人投身到这个领域。另外，公司深受影响，更重视产品经理这样的岗位，愿意花更高的薪水去请这样的人才。
在这样的供求关系带动下，优秀的年轻人愿意加入，感觉职位高大上且薪水高；公司也愿意高价请人，认为产品经理重要，且只有高价才能请来。这就是有些运营人员希望转做产品的原因。
其实，产品经理当然也要从基层做起，甚至从打杂做起。有很多PM已经从业一两年了，还在团队里打杂救火，或者做一些边缘化的事，这都是很正常的情况。
写完了。
到此，以上就是小编对于产品和运营在一起了的问题就介绍到这了，希望介绍关于产品和运营在一起了的2点解答对大家有用。
