运营需求你听懂了吗

需求来源概述）依渠道优先级进行排序，需求来源如下用户反馈、领导、运营、数据反馈、竞品、开发测试反馈、合作部门

运营网站累吗

运营网站需要钱吗

网站运营

及时关注该渠道，并做好妥善处理，否则会造成用户报障量增大，用户情绪爆发，一旦蔓延到其它社交网络上就会演化成毁灭性灾难；领导需求：上级下的需求，一般是在战略层面需求，可能是新功能的接入、新业务的接入；这里的新功能和新业务不一定对等

跟领导对接需求时，应视需求的熟悉程度，判断是否需要问清楚目标、场景，这对后续的推动工作有重要作用

我们有必要让开发同事、UI同事明白某需求的意义与价值

运营需求：一般为活动性需求，其目的是拉新、促活；接到这种需求一般验证其活动形式的支撑功能，在过去是否有过同类逻辑的功能，如果有则可修改调用、或增加一种活动类型；若无，则需验证其过程逻辑，重新开发一套

除活动策划外，运营人员也是后台系统的主要使用对象，会提出后台的业务性需求

其目的为提高工作效率、减少重复性工作

接收这种需求之后，需要进行一遍验证，查验其需求的真实性，并与技术同事分析可行性，寻找最有方案；产品自发需求：自行进行验证，其流程为发现问题-提出方案-验证方案；通过流程体验、数据表现、竞品动态等渠道尽可能挖掘需求；目前提出一个需求后，笔者会通过对比竞品功能、数据表现等方式去验证需求

需求沟通踩过的坑列举两个例子，是作为新人，笔者亲身踩过的坑，以血泪史的形式记录下来

其一：被开发打脸，需深入了解原有逻辑客户端有过一个发卡券的需求，要求是分发量大、即时性强，在实现过程中，原需求为卡券到账用户即可收到一个提示弹窗；后台已经存在一套首页广告弹窗逻辑，以及卡券分发逻辑；笔者对原逻辑没有深刻理解，重新提出一套卡券关联逻辑和卡券广告弹窗逻辑

结果是开发关都没有过，打回重新调整需求；最后还是接入原有的首页广告弹窗逻辑，并且沿用原有的卡券分发逻辑；其二：被运营打脸，需换位思考，说运营话曾跟运营沟通一个很简单的需求，在浏览器的自家网站上线一个B广告位

笔者很傻逼的表述：图片尺寸高度不统一，在切换的过程会很不友好，切换到该图片，高度会缩小

以上，导致了一幕崩溃的沟通场景

总结：深入了解原有的业务逻辑+沟通表达需谨慎，三思而后言