• 0点赞

  • 0收藏

首页 > 运营 > 正文

 

自 16 年 3 月加入百度,到现在已有一年半之久。从运营小白到现在能够独立负责一个小项目的运营,中间踩过多少坑只有自己知道。而今天,我想和大家聊到的是,作为一个运营新人,我们应该如何和研发沟通需求。

适合阅读入群:

  1. 运营新人(0-2 年工作经验);
  2. 工作中需要不断地和研发接触交流;

我为什么会做这个分享:

http://image.woshipm.com/wp-files/2017/09/1B3fGfgm8oBlUhZHzG7L.png

  1. 工作角色:我在百度工作的这一年半,主要负责两个方向的工作。 一是内容运营,二是运营方向对接产品与研发的接口负责人。平时和 研发同学关于业务上的沟通较多;
  2. 踩过深坑:在和研发对接需求,推进项目落地的过程中,遇到过很 多问题,比较常见的例如:无效沟通,重复沟通,需求实现方式与预 期有出入等问题;
  3. 经验总结:当踩过深坑后,一方面需要不断地填坑(解决问题), 另外一方面也是我认为更重要的就是不断地总结经验,这样才能更加 高效地推进项目的执行与落地。

一个运营新人眼中的研发:

http://image.woshipm.com/wp-files/2017/09/Ygb5Boltm5ramZkV6hXx.png

  1. 自我思维的闭环:我在开始决定写这篇文章的时候,和公司的一个

程序员大大有过简单的沟通,他告诉我说,程序员在专心敲代码的时

候会陷入一个自我思维的闭环中,进入这个闭环需要时间,但是,一

旦进入这个闭环,则工作效率会成倍提升。所以,一般程序员同学都 不希望在自己专心敲代码的时候被打扰。

  1. 逻辑性强:关于这一点,是我平时和组内研发同学沟通需求的时候 的发现。例如有一个运营需求需要研发同学提供支持,在需求的预沟

通阶段,研发同学会抽丝剥茧地去问你为什么会有这样一个需求,需

求的实现方式是怎么样的?有没有更好地方法?需求的收益如何?程 序员同学作为需求的实现方,考虑的不仅仅是如何去实现这个需求, 更会去考虑这个需求背后的实质是什么。

  1. 高智力:其实码农的工作性质就要求了一个人必须要有相对较高的智力才能 hold 住各种需求。同时,我想聊一个工作以外的点,我们组

有一个 fe 同学,狼人杀、德州扑克这种需要逻辑与智力以及推演能力

的游戏真是无尽地吊打我。德州扑克几乎次次赢,真是服气!“物以 类聚,人以群分”,想要研发同学认可自己,必须要不断地提升自己。

  1. 工作是敲 bug:我们组有一个非常搞笑的研发同学,他说每天的工作都是敲 bug,但是他又说了一句话:我们研发可以说自己每天的工作

是敲 bug,但是你们运营和产品不能这样说。我把这句话放在这里的目的,是想告诉大家,关于敲 bug 这个事情,大家权当玩笑,不可当真哟。

作为踩坑无数后的运营,我平时这样和研发同学沟通:

当产品出现 bug 了怎么办

推荐做法:明确 bug 的优先级,如果高优先级则直接抛在内部沟通群或者私聊某个研发。如果低优先级,则统一记录后让研发同学解决。

推荐理由:为什么会这样处理?高优先级的问题,影响面广,所以要 及时处理。但是针对优先级较低的问题,如果我们去打断研发手头的

工作,把他从自我思维的闭环中拉出来,他可能会非常地不耐烦,告

诉你:这个问题或者需求发邮件吧!这个时候,你会陷入相对被动的 局面。解决不了问题还碰了一鼻子灰。

http://image.woshipm.com/wp-files/2017/09/fc82RvGgEIkOgeUlKl7K.png

当和研发同学沟通运营需求的时候

推荐做法:研发同学都是逻辑性非常强的一类人,当自己要和研发同 学沟通需求的时候,自己需要梳理逻辑,考虑清楚这样几个问题:项 目的预期收益;项目的需求背景;项目的实现方式;为什么需要研发 提供支持;运营有无可用替代方案。考虑清楚这样几个问题之后,才 能有底气的和研发同学去沟通。

推荐理由:作为需求方,只有明确了需求的前后背景与逻辑,你才能 说服需求的实现方也就是研发接手这个项目,并高效地完成这个项目。同时,在这里我想重点聊一聊预期收益这一块,研发同学的项目 大致可以分为两类,技术项目和业务项目,研发和产品的需求大多数 是业务项目。每做一个项目需要有预期的收益才能让研发同学们有意 愿和想法去高效地完成项目,另外,预期的收益最好是量化的数据, 这样才能更加直观地展现这个项目的意义和价值。

http://image.woshipm.com/wp-files/2017/09/yAmEgH38xW7KHvpN4rUu.png

在某一问题上和研发同学有不同看法时

推荐做法:这类问题的出现场景大多数集中在需求的实现方式上,研 发同学有不同意见的原因大致也可以分为两类:第一类是技术难度与 复杂程度。第二类是研发认为其他方案会更加高效地达到目的。针对 第一种技术难度,如果研发实现难度较大,且优先级不高的时候,可 以接受研发同学的意见。但是一味地为了降低开发难度所产生的异议,作为运营也不能接受。针对第二种,我们首先要判断这种方案和 替代方案的优缺点,然后从目的出发,选择最优的方式。

推荐理由:运营和研发的出发点都是想高效地推动项目落地,为产品 的发展考虑。当出现不同看法的时候,要记住服从于最终的目的。如 果研发同学提供的建议可以更好地达到目的,为什么不接受建议呢?

勇敢地承认自己没有考虑周全远比找各种理由去支撑一个说不过去的 想法要好的多。

http://image.woshipm.com/wp-files/2017/09/CSqSXO625bqprSPD91aq.png

写在最后:

有些经验,必须亲身经历,方可学到。感谢你能阅读到最后,谢谢!

作者:刘君,百度派产品运营,工作原则是把每一件重要的事情做到 极致,喜欢与优秀的人沟通,近期专注焦点:更加职业化地面对工作。

本文由 @刘君 原创发布于人人都是产品经理。未经许可,禁止转载。

 

版权声明:本站部分内容为综合网络现有资源整理并发布的,如果内容上有侵犯您的权益的时候请联系我并附上相关证明材料,核实后会删除。
温馨提示:鉴于部分资源来自于网络由于处理不细致难免出现广告信息,在遇到广告信息请勿相信一切广告信息,以免造成经济损失,本站所有资料均是免费分享。
部分视频苹果手机或者安卓手机无法在线观看的,凡是遇到视频加载失败的文章建议电脑访问观看,提醒大家手机不是万能的。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

在此浏览器中保留我的姓名、邮箱和网站

评论信息

TOP