运营和研发建立良好合作的重要性
通常一个互联网项目团队包括如下几个职能的人员（排名不分先后，且根据具体情况和不同时期人员配置会有增减）：产品、设计、研发、测试、运维、运营、市场、商务，其中的产品主要起到业务需求方（运营 / 市场 / 商务）和技术研发之间的桥梁纽带的作用，那么运营作为典型的业务需求方，只要把需求跟产品沟通清楚就好了，为什么还要和研发建立良好的合作呢？
第一、很多时候，运营要承担一部分产品的工作，必须和研发打交道
产品都是有生命周期的，一般来说，产品从无到有的孵化阶段是以产品人员和研发人员为主导，确保产品按需完成，如期上线；当产品上线后进入相对稳定的上升发展期时，运营逐渐成为主导角色，收集提炼出大量来自用户的，和运营过程中调研挖掘的产品需求，推动产品不断迭代优化。
而且很多公司里，产品和研发资源并不是完全从属于某一个产品线，这个产品上线稳定一段时间后，可能就会调去参与其它项目，不会有很多精力能够投入该产品的持续优化了。这个时候运营就必须责无旁贷地承担起一部分产品的工作，要和研发同学直接打交道。
第二、运营是最终担业绩的人，但无法独立完成业绩，需要其它职能的配合
在几乎所有的互联网产品中，运营都是最终承担 KPI 的人，而且运营的工作相对容易量化，可以各种数据指标的变化来衡量。
但互联网产品数据的提升，是不能仅靠运营单方面来达成的，一定是各个职能多方面通力合作的结果：产品界面不友好，运营拉来用户也留不住；系统性能不稳定，经常闪退或者报错，运营每天处理用户吐槽和救火就疲于奔命了，哪里还有精力去完成业绩。
可是往往运营又并不具备能够充分调动产品和研发资源的权限，如果自己团队有配备专属的产品研发还好，否则只能是多方面寻求资源协作，能否与研发建立良好的合作关系就尤为重要了。
第三、靠谱的研发能避免很多不必要的资源浪费
见识过不靠谱的研发，你就知道能有靠谱的研发是多么幸福的事情。
靠谱的研发，不会拍着胸脯说这东西简单得很两天就上线，但是一旦承诺了排期就不会拖延；
靠谱的研发，会保证产品开发质量，提交测试基本就是没有 bug；
靠谱的研发，不会想方设法推卸责任，很多拖了很久悬而未决的问题，到他手里研究一番就可以得到完美的解决；
靠谱的研发，能结合运营的需求，做出方便又好用的后台，大大提升运营工作效率；
跟靠谱研发合作，运营不需要无休止地重复测试，提交 bug；不需要没完没了地开需求沟通会，天天追着问进度；不需要担心某个需求无法实现，从而无法开展新业务。你说如果你是运营，是不是一定要努力找出那些靠谱的研发小伙伴组队啊？运营如何和研发建立良好的合作
第一、谨慎处理需求，不要让研发白做工
通常技术都是业务的支持部门，技术要为业务服务，运营会结合业务发展不断提出需求改进产品是很正常的，但提需求绝不是随意的和漫无边际的。
一定是：
经过充分的论证调研——
现有产品确实无法满足业务发展——
研发成本不会超出现有资源范围——
才靠谱。
心血来潮、拍脑袋就上、不顾实际资源情况就开干的项目多半最后都是惨淡收场，参与人员付出的时间和精力也就白搭了。
研发最怕什么？最怕辛辛苦苦加班加点做出来的产品，最后没人用啊！等于研发这段工作的价值没有得到承认。
你如果说我不在乎，反正做什么不是做，每周都要写工作周报哦，我是研发只管实现你的需求就好了，做完了有没有用那是你们业务部门的事情跟我没关系。这样想的研发也就是混日子的心态，最后业务没发展、公司没发展难道研发日子就会好过吗？
真的有想法有上进心的研发绝不会这样想的，一定是希望自己开发的产品真的能够得到实际的应用，对公司的业务能够起到很好的支撑，进而自己的价值也得到了体现。
我曾经亲眼见过真实的案例：
业务方迫切地要做一个新产品，理由是旧有的产品不适应客户的需求了，必须要有新的产品来承载客户需求的变化，而且给出了要实现的时间点（还比较紧迫）。
当时技术部门派出了最精英的程序员来负责这个产品的开发，产品如期做完了，结果业务方的反馈是：这不是他们要的东西……
后来我自己负责的项目运营中应用过该产品，觉得还是比较好用的，为什么业务方会否定它我个人不得而知，也许公司战略、需求变更、客户变化种种都是可能的原因，但最后的结果是这个程序员被这个项目伤了心，不久离职了。
还有更极端的案例：业务方把业务未完成的原因归结于产品研发不给力，不能对客户的需求做到 7*24 小时响应，百分百解决，客户投诉也让研发来背锅，也许研发可能是存在一些问题，但是这样的合作方式只能是双输，业务完成了吗？也并没有。
所以说运营在处理需求时是一定要谨慎的，关于如何提炼产品需求，我以后会专门发文陈述我的观点。
第二、充分说明需求，调动研发的积极性
上文说过，靠谱的研发，有想法有上进心的研发，一定不是机械地只管接活干活的人。
他们对业务也有自己的理解和想法，有时甚至能从别的角度给出更好的解决方案，前提是要让他们充分了解这个需求的来龙去脉，这个需求的背景，不仅仅是知道我们要做什么事，更重要的是我们为什么要做这个事：现在的这个产品需求是我运营经过调研分析确定的，我的解释是否能让你足够清楚明白了？然后从研发的角度，请你看看是不是有其他的隐藏问题？你有没有更好的解决方案？我们一起再探讨。
最后达成共识确定的需求，并不是运营单方面「压下来」的需求，而是经过业务方和研发讨论后共同认可的需求，研发也充分认识到了这个需求的价值和意义，你说他不会积极主动地完成吗？一定会的。
而且事先双方确认了需求和排期，后期的责任也非常明确，即使又有了临时紧急的需求变更（有时不可避免），也会更容易沟通。
相反，如果运营只是说我要做某个东西，告诉研发我要这样这样实现，你不要管为什么总之你必须给我做了，还得在指定时间点完成，否则到时影响业绩责任在你……这样研发就成了被动接工单的角色，如何规避风险避免担责任是他们要考虑的首要问题。
这过程中各种扯皮推卸互撕都有可能出现，程度轻重取决于工程大小和工期长短。如果遇到在公司里地位相对强硬的研发，还可能出现项目进度推迟甚至根本无法推进的情况。姑且不论责任究竟出在哪一方，宝贵的时间就这么耗过去了，错过了多少好业务。最后谁获利了？都没有啊。
第三、掌握沟通技巧，研发最怕频繁打扰
运营的工作广泛而又琐碎，很多时候要求「多线程任务并行」，经常要和各种用户打交道，因此运营的思维是比较发散的，需要具备相当的灵活性，这是运营工作的特点决定的。
研发则是逻辑性非常强的工作，要求考虑完整周密，天天跟机器打交道，非 1 即 0，非正即负，没有模糊的中间状态可言。
写代码按照一定的逻辑顺序来，据说有人写代码激情迸发，写到 high 了物我两忘，完全沉浸在代码的世界里也是有的。
如果，隔个几分钟就打扰他一下，改个这里，修个那里，问个问题……研发的思路就中断了，这些单线程的同学们多半会抓狂。
所以我们必须利用工具来管理需求。把所有产生的需求统一放到项目管理工具中，如 JIRA 就是一种很常用的工具，汇总一批需求定期（这个时间间隔可以和研发事先沟通好，比如每周一次）和研发沟通，确定优先级和排期。
如果是紧急的需求，或者重大的 bug 出现（比如用户无法登录了），这种可以随时找研发处理，但是尽量不要零敲碎打地报需求，尤其是不要用即时沟通的方式，比如 qq，电话给研发报需求，容易遗漏，不好统计和反馈，而且也给研发造成打扰。
第四、最好懂点技术，方便跟研发沟通
看到这里你可能会说：运营要懂技术还要研发干什么？这个当然不一样。
这里指的懂技术不是说运营要会亲手写代码，而是说对技术的一些基本概念，名词，表现形式和行业趋势有点了解是很有好处的。
研发是专业性较强的工作，在和研发沟通产品需求和进度的时候，多少要涉及一些技术相关的问题，如果遇到善于沟通又懂些业务的研发，他能尽量用非技术人员能够理解的方式跟你沟通，但这类人真心不多，能做到的基本都是技术管理层了。有些人还有一种研发范儿的傲娇，哎你们运营连这都不懂……
从我个人经验看来，如果有产品人员在，那么运营基本不用懂技术，只要把业务需求跟产品理清楚，就让产品去跟研发沟通好了；但是在缺乏产品资源，或者要直接和研发合作的场景，以及运营做到一定年限和职位的时候，懂一些技术的运营跟研发沟通会更有优势。
表现在沟通更加顺畅，省去了很多专业方面的铺垫，提需求时能够从研发角度进行一定的考虑，研发提出的方案和排期，心里基本也能有数，效率提高很多。
现在各种学习编程的资源非常丰富，我个人觉得运营学习一些编程知识，对思维的锻炼，产品的了解，视野的提升都有益。
第五、发掘共同利益，大家好才是真的好
说到底，运营的目标是要最大化产品的价值。这中间无论运用何种手段，只要合理合法不违反公司规定都是没问题的。
但如果总想着利用别人，占点便宜，也许一时可以，长久都是不奏效的。
最好的方式：是让参与的人有共同的利益，这事成了，大家都获利，而不只是单纯的部门之间工作配合或者帮忙而已。
一方面，需要从组织结构上理顺，为一个产品线配备齐全人员的产品事业部制，就比按职能划分按任务派活的大部门制更能激发员工对产品的责任感和积极性；
另一方面，要舍得分享，赏罚分明，产品做得好了，大家都有功劳，该分钱分钱，该团建团建。大家都知道跟你做事不吃亏，时间长了，靠谱的人会愿意持续跟你配合，你的口碑和职场信誉也就建立起来了。
运营眼中的靠谱研发是什么样的？
技术好，还用多说么。。。
还懂点业务，理解需求快，而且能结合需求完善更好的解决方案；
好沟通，能换位思考，我曾经合作过的一位研发 leader，需求完美解决不说，还会自己主动琢磨「怎么把这个后台做得让你们运营好用一些」，好感度提升一万点啊！
最后，颜值还高……这算附加值了，能把自己打理得干净整洁精神焕发的研发更是稀少，遇上请务必珍惜。
IT常识 
