一个产品项目团队通常包括如下几个工种的成员(具体情况和不同时期人员配置会有增减)：产品、设计、研发、测试、运维、运营、市场、商务、渠道。
在产品开发初期，产品和研发同学会作为主导，让产品从无到有，并且确保产品按需完成。产品上线后的日常管理和数据指标就会变成由运营来扛，产品的用户量能够有几个“0”就看运营和市场、渠道、商务童鞋能做多少事啦。
在为产品攻城略地的运营过程中，我们会大量收到来自用户的功能和需求的反馈，有时候为了近一步提升产品数据也会为自己的运营项目提产品迭代需求。这时我们就需要向产品提需求、技术提排期，UI提交互…紧接的就是一场漫长而又不得不做的沟通等待着去面对。
美国著名学府普林斯顿大学对一万份人事档案进行分析，发现：“智商”、“专业技术”和“经验”只占成功因素的25% ，其余75%决定于良好的人际沟通;另外，哈佛大学就业指导小组调查结果显示，在500名被解职的男女中，因人际沟通不良而导致工作不称职者占82%。
运营为了让自己不被解雇，与团队其他成员是否能够建立良好的沟通就显得尤为关键。
做过运营的人都知道，在公司里需要我们经常去沟通的人有三种，分别是产品、技术、UI，(少部分的商务、渠道的童鞋)，下面进行一一的沟通方式说明，希望对的项目推动沟通有所帮助。
一、运营如何与产品良好的沟通?
自从有了运营和产品两个岗位之后，他俩关系向来是最微妙的，非常容易产生相互瞧不起对方的情况。如果公司把运营和产品独立成个部门，分别由不同的领导带领，估计他俩是各自盯着对方，抓住问题随时开撕。
在运营来看，产品占用了那么多的开发资源，大部分时候做出的是粑粑一样的功能，每次还得帮他们擦屁股，做他们的接盘侠。
在产品看来，运营除了小打小闹发奖做活动，带来一波对产品发展并没什么卵用的羊毛党，其他好像也没什么大的作用，就不能整点让我一样影响产品震惊行业的事情嘛…
运营和产品这样相互不对眼可能出现的一个问题是，运营的项目推动排不上期，产品的功能没后续运营管理，甚至连最核心的产品日活数据也都会下降。姑且不论责任究竟出在哪一方，宝贵的时间都耗在了吐槽上，最后谁获利?
破这种局的解决方法有花钱和不花钱的，如果公司预算允许可以运营团队招产品经理，产品团队招运营人员。不想多花钱的话从组织结构上理顺，为一个产品线配备齐全人员的产品事业部制，就比按职能划分按任务派活的大部门制更能激发员工对产品的责任感和积极性;(似乎调组织架构并不简单)，要么咱们运营以身作则好好沟通了哈。
1.同频道的语言沟通
运营每天比较多的工作是做内容、写策划书、写PPT，产品则做是用户需求分析、竞品的功能分析、需求文档的撰写、画原型图…..做的工作不同，决定了我们沟通的载体和方式不同。
运营用对的运营和产品做沟通，不能只是拿这一份策划书就去了，还需要写一份产品需求文档(MRD)，这是能够快速让产品知道我们的需求以及他们需求做什么的文档，初次沟通细节并不一定都要标清，但核心功能点的交互需求必须写明。
2.告知收益，不邀功
运营从细节的优化出发，产品则是做产品层面比较大的迭代。运营和产品的所有工作本质目标都是为了最大化产品的价值，只是手段和思考方式不一样。
作为运营在跟产品沟通项目的功能需求时，可以明确告知该项目对他现在所负责的产品的收益。产品关心的收益无外乎，自己做的产品有更多人在使用，或者证明自己做的那些功能对产品的核心目标数据有促进作用，例如你的项目直接复用产品团队的某个功能，然后再立项时直接点名感谢某产品经理的功能支持，估计就会沟通起来顺畅些。
3.虚心学习，不情绪
心理学发现，当人们发现领袖出现一点个人主义的苗头，就会变得冷漠，甚至出现敌对的情绪。相反，藏身幕后、不那么抛头露面的领导更会受到普遍的尊重。
《纽约世界报》的创始人和出版人普利策就曾对他的编辑们说，如果在一个紧急时期他所发的命令违背了该报的政策的话，编辑们可以不予理睬。学会谦让，在人际交往中绝对是“退一步海阔天空”的事。
作为运营我们可以想到各种各样好玩的创意和点子，产品在逻辑上比较好，对产品的所有数据和接口都比较了解。对于小的项目运营的确是可以独立完成产品需求文档的撰写，但是大的产品迭代需求，最好是虚心学习，不情绪，如果能跟产品一起商量合作的话，估计能够起到更好的效果，至少是和技术沟通的时候会把所有产品的细节想的更清楚。
4.借力领导，不冲突
有一次自己在深圳做分享，有童鞋问道“运营如何更好的跨部门沟通”?当时我给的建议是“可以先尝试自己沟通解决，然后如果实在没办法解决，为了避免冲突可以发邮件抄送部门领导，然后让领导帮助推进项目。在贴吧那会，看到有一位销售，把邮件抄送给了副总裁，然后产品立马把问题解决了，哈哈!如果你平常人缘好，可能会有另外更好到方式”。
为了项目推荐借力领导，需要提前跟领导知会，让他们来指导你这封邮件要写哪些内容。运营需要做的就是在与领导进行知会沟通时，告知项目背景、项目收益、项目现状、目前遇到的需求问题、然后需求优先级排序(哪些功能必须要做，不做就没办法完成项目)，希望得到产品怎样的支持。
二、运营如何与设计良好的沟通?
在优化/开发产品的某项功能时，当运营和PM将功能的原型完成之后，就需要UI针对原型上的文字和互动模块进行视觉的设计了。
对用户来说，在这个看脸的年代美观性是决定他们是否会使用这项功能的关键;对于运营来说，功能的视觉效果直接影响的是项目数据，因此运营与UI之间的沟通直接决定了功能的质量和项目数据的好坏。
按理说只要把原型图画好，然后给到设计师，我们等着出图收货就好。但是真实的情况是做项目时在与UI的合作过程中会经常出现以下状况，不知道你是否有同样的问题：
a.UI不在意功能的逻辑，只关注产品的美观，比如“投票按钮的旁边的点赞拇指原本是凸显这个按钮表示“支持”，但在UI的说这会让页面显得很拥挤，就直接变成了文字“支持”。
b.UI童鞋设计出的页面效果，差强人意没有达到运营预期，得返工修改
c.为了让功能更有趣，运营和产品经常能够沟通出新的交互方式，UI童鞋不愿意修改，觉得没那个必要。d.产品、运营、UI都对页面的视觉很满意，但自己的直属领导觉得不行，需要设计继续修改。
e.功能的视觉做好了，可功能迟迟不上线，UI童鞋老催进度。
良好的合作是建立在尊重与交流上的，要相信对方的专业水平。UI设计师最怕什么?
最怕自己设计出来的页面最后没上线，等于自己这段工作的价值没有得到承认，作品又只是躺在磁盘的PSD，本质上他们也是希望能够让自己作品让更多的用户看到，但是他们需要运营给予更多持续修改的动力。所以，通常情况下，遇到需要修改的时候，运营可以尝试用下面这些方式规避和做说服沟通。
1.提前参与，有效设计
运营在功能设计的初期就可以让设计参与进来，在和产品画原型图时可以咨询他们的建议，毕竟人家是专业做设计的，看的交互方式和页面比我们多，指不定能够有更好的功能呈现方式。当然，最重要的是设计的提前参与能够在后续的页面设计过程中，少花时间去重复解释原型图每个按钮的交互，设计师也更能够理解每个按钮放置在运营层面的思考。
2.迂回说服，给予肯定
每一个设计师背后都有一群指点江山的神:“你这样做不好看，把左上角的字放大，颜色调深，整个风格扁平化不够”。
没有人喜欢被否定，如果对于产品视觉设计上有自己的看法那么最好的沟通方式是“如果把这个按钮填充成蓝色，把页面色系统一下是不是会看着更舒服，当然这只是我的想法，毕竟我没有你专业，你可能会有更好的修改方案”。
积极的员工，大家都是在为一个好的结果努力，建立在良好的沟通上一切都是可以商量的，当然前提是不能因为自己的原型失误导致的频繁修改。
对于有更好的交互完善修改需求，在提自己的修改需求前可以先对他的作品给予肯定“现在这版设计很好啦，我和产品沟通后觉得，这个按钮可能变成跳动的球可能会更符合整个页面的风格哈，不知道你是否也怎么认为?”
3.群组沟通，进度互通
运营作为功能发起人要确保技术、产品、设计各方信息不通，千万别成为一个传话筒疲于奔命了，哪里还有精力去思考完成数据目标的其他事情。群组沟通就是拉一个项目讨论组，让UI设计师跟技术对接页面图层分布和切图逻辑，让设计师来及时响应技术关于颜色RGB数据。
然后技术也可以第一时间在群组里同步开发进度，设计师也更能够知道整个项目的开发进度，不至于认为是运营不把它的页面设计作品搁置了。
三、运营如何与技术良好的沟通?
当UI设计师把页面制作出来以后，运营需要拿着它和产品童鞋完善的产品需求文档到技术部门寻求排期。为了不需要天天询问进度，不需要担心某个需求无法实现，不需要无休止地重复测试提交 bug，为了项目的顺利上线，运营在与技术沟通时需要注意以下问题。
1.充分说明，调动积极性
程序猿都喜欢自嘲为码农，如果你真把他们当作只负责写代码的互联网农民工，那就悲剧了。技术跟运营不是一个部门，只有合作关系没有领导被领导的关系，千万别只是运营单方面压需求下去，说自己要做某个东西，告诉研发自己要这样这样实现，而且必须在指定时间点完成。
为什么现在越来越多的技术同学能够转型做产品经理甚至创业做CEO，因为靠谱的研发有想法有上进心的研发，一定不是机械地只管接活干活的人。
他们对业务也有自己的理解和想法，有时还能从专业的技术角度给出更好的解决方案。前提是要让他们充分了解这个需求的来龙去脉，这个需求的背景，不仅仅是知道我们要做什么事，更重要的是我们为什么要做这个事：现在的这个产品需求是我运营经过调研分析确定的，我的解释是否能让你足够清楚明白了?然后从研发的角度，请你看看是不是有其他的隐藏问题?你有没有更好的解决方案?我们一起再探讨。
2.明确需求，别轻易改动
运营的工作广泛而又琐碎，很多时候要求「多线程任务并行」，经常要和各种用户打交道。因此运营的思维是比较发散的，需要具备相当的灵活性，这是运营工作的一大特点，也是在沟通中存在最大的问题。
对功能设计阶段添加和修改新的需求，可能还可以沟通，如果在开发阶段还对需求有所改动的话，估计和技术的同学友谊的小船离翻不远了。
所以，明确需求，别轻易改动(锦上添花的需求就等下一版来晚完善吧)，给到的技术的开发文档和页面最好是最终版的，改动的越大你的项目被其他项目排期挤压掉的可能性就越大，项目的不能顺利落地，估计设计也会跟你急。
3.模块沟通，让问题沉淀
技术人员和数据代码打交代，基本是单进程工作，为了提高单位时间里码代码的效率，他们基本上是需要处于“飞行”工作模式，写到 high 了物我两忘，完全沉浸在代码的世界里也是有的。
如果运营隔个几分钟就打扰他一下，改个这里，修个那里，问个问题……研发的思路就中断了，这些单线程的同学们多半会抓狂。所以运营和技术沟通必须利用工具来管理需求。把所有产生的需求说明和建议统一放到项目管理工具中，如 JIRA 就是一种很常用的工具(在大公司基本上也有自己的开发需求沟通工具)，汇总一批需求定期和研发沟通，确定优先级和排期。
如果是紧急的需求，或者重大的 bug 出现(比如用户无法登录了)，这种可以随时找研发处理，但是尽量不要零敲碎打地报需求，尤其是不要用即时沟通的方式，比如 qq，电话给研发报需求，容易遗漏，不好统计和反馈，而且也给研发造成打扰。
会沟通的运营才是好运营
沟通的本质是——让他明白你想要什么，你明白他想要什么”，就是在团队中每个人都在自己工作的前提下主动去了解团队其他成员的工作内容，不关关跟技术、设计、产品同学，和市场部、渠道部也是多沟通可提前知道能够帮助自己提升数据的可借力的点。
运营的目标是要最大化产品的价值。这中间无论运用何种手段，只要合理合法不违反公司规定都是没问题的。但如果总想着利用别人，占点便宜，也许一时可以，长久都是不奏效的。
最好的沟通合作方式：不只是单纯的部门之间工作配合或者帮忙而已，是让参与的人有共同的利益，要舍得分享，赏罚分明，产品做得好了，大家都有功劳，该分钱分钱，该团建团建。大家都知道跟你做事不吃亏，时间长了，靠谱的人会愿意持续跟你配合，你的口碑和职场信誉也就建立起来了。
【版权声明】行行出状元平台欢迎各方(自)媒体、机构转载、引用我们原创内容，但要严格注明来源：；同时，我们倡导尊重与保护知识产权，如发现本站内容存在版权问题，烦请提供版权疑问、身份证明、版权证明、联系方式等发邮件至service@hhczy.com，我们将及时沟通与处理。
