自16年3月加入百度，到现在已有一年半之久。从运营小白到现在能够独立负责一个小项目的运营，中间踩过多少坑只有自己知道。而今天，我想和大家聊到的是，作为一个运营新人，我们应该如何和研发沟通需求。
适合阅读入群：
运营新人（0-2年工作经验）；
工作中需要不断地和研发接触交流；
我为什么会做这个分享：
1.工作角色：我在百度工作的这一年半，主要负责两个方向的工作。一是内容运营，二是运营方向对接产品与研发的接口负责人。平时和研发同学关于业务上的沟通较多；
2.踩过深坑：在和研发对接需求，推进项目落地的过程中，遇到过很多问题，比较常见的例如：无效沟通，重复沟通，需求实现方式与预期有出入等问题；
3.经验总结：当踩过深坑后，一方面需要不断地填坑（解决问题），另外一方面也是我认为更重要的就是不断地总结经验，这样才能更加高效地推进项目的执行与落地。
一个运营新人眼中的研发：
1.自我思维的闭环：我在开始决定写这篇文章的时候，和公司的一个程序员大大有过简单的沟通，他告诉我说，程序员在专心敲代码的时候会陷入一个自我思维的闭环中，进入这个闭环需要时间，但是，一旦进入这个闭环，则工作效率会成倍提升。所以，一般程序员同学都不希望在自己专心敲代码的时候被打扰。
2.逻辑性强：关于这一点，是我平时和组内研发同学沟通需求的时候的发现。例如有一个运营需求需要研发同学提供支持，在需求的预沟通阶段，研发同学会抽丝剥茧地去问你为什么会有这样一个需求，需求的实现方式是怎么样的？有没有更好地方法？需求的收益如何？程序员同学作为需求的实现方，考虑的不仅仅是如何去实现这个需求，更会去考虑这个需求背后的实质是什么。
3.高智力：其实码农的工作性质就要求了一个人必须要有相对较高的智力才能hold住各种需求。同时，我想聊一个工作以外的点，我们组有一个fe同学，狼人杀、德州扑克这种需要逻辑与智力以及推演能力的游戏真是无尽地吊打我。德州扑克几乎次次赢，真是服气！“物以类聚，人以群分”，想要研发同学认可自己，必须要不断地提升自己。
4.工作是敲bug：我们组有一个非常搞笑的研发同学，他说每天的工作都是敲bug，但是他又说了一句话：我们研发可以说自己每天的工作是敲bug，但是你们运营和产品不能这样说。我把这句话放在这里的目的，是想告诉大家，关于敲bug这个事情，大家权当玩笑，不可当真哟。
作为踩坑无数后的运营，我平时这样和研发同学沟通：
1.当产品出现bug了怎么办
推荐做法：明确bug的优先级，如果高优先级则直接抛在内部沟通群或者私聊某个研发。如果低优先级，则统一记录后让研发同学解决。
推荐理由：为什么会这样处理？高优先级的问题，影响面广，所以要及时处理。但是针对优先级较低的问题，如果我们去打断研发手头的工作，把他从自我思维的闭环中拉出来，他可能会非常地不耐烦，告诉你：这个问题或者需求发邮件吧！这个时候，你会陷入相对被动的局面。解决不了问题还碰了一鼻子灰。
推荐做法：研发同学都是逻辑性非常强的一类人，当自己要和研发同学沟通需求的时候，自己需要梳理逻辑，考虑清楚这样几个问题：项目的预期收益；项目的需求背景；项目的实现方式；为什么需要研发提供支持；运营有无可用替代方案。考虑清楚这样几个问题之后，才能有底气的和研发同学去沟通。
推荐理由：作为需求方，只有明确了需求的前后背景与逻辑，你才能说服需求的实现方也就是研发接手这个项目，并高效地完成这个项目。同时，在这里我想重点聊一聊预期收益这一块，研发同学的项目大致可以分为两类，技术项目和业务项目，研发和产品的需求大多数是业务项目。每做一个项目需要有预期的收益才能让研发同学们有意愿和想法去高效地完成项目，另外，预期的收益最好是量化的数据，这样才能更加直观地展现这个项目的意义和价值。
3.在某一问题上和研发同学有不同看法时
推荐做法：这类问题的出现场景大多数集中在需求的实现方式上，研发同学有不同意见的原因大致也可以分为两类：第一类是技术难度与复杂程度。第二类是研发认为其他方案会更加高效地达到目的。针对第一种技术难度，如果研发实现难度较大，且优先级不高的时候，可以接受研发同学的意见。但是一味地为了降低开发难度所产生的异议，作为运营也不能接受。针对第二种，我们首先要判断这种方案和替代方案的优缺点，然后从目的出发，选择最优的方式。
推荐理由：运营和研发的出发点都是想高效地推动项目落地，为产品的发展考虑。当出现不同看法的时候，要记住服从于最终的目的。如果研发同学提供的建议可以更好地达到目的，为什么不接受建议呢？勇敢地承认自己没有考虑周全远比找各种理由去支撑一个说不过去的想法要好的多。
写在最后：
有些经验，必须亲身经历，方可学到。感谢你能阅读到最后，谢谢！
