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