运营如何提需求?不要只想着靠产品经理!

浏览量:32 次

提产品需求是运营同学日常工作之一,看似简单,其实并不容易。

什么是产品需求呢?产品需求就是对达到某个既定目标需要实现产品功能和特性描述,可以从以下几个维度来划分:

1.外部需求和内部需求:

前者来自各个渠道收集用户反馈,如微博、微信、QQ群、客服邮箱、客服电话,以及产品自身反馈渠道(如论坛客服专区、在线即时咨询窗口等);

后者来自公司内部,如老板和其它部门提出需求。这些反馈通常都不会很明确,需要运营同学进行整理挖掘、沟通调研进而提炼出需求。如果不经整理提炼就统统丢给产品跟研发同学去处理话——会被鄙(qia)视(si)……

2.改进型需求和新建型需求:

它们俩是从1到10和从0到1区别。我个人建议是已有产品如果改进优化后能用,尽量不要另起炉灶,除非是原有产品从定位到风格全都跟新需求不一致。这里一方面关系到效率,能否快速运用已有产品达到业务目标,而不是只能等着新产品上线错过宝贵窗口期;另一方面关系到借势,是否能够借助已有流量或者品牌优势来加速业务目标实现。

这就要求运营对公司内部现有产品定位跟功能了如指掌,对公司外部可以利用现成平台和资源也非常熟悉,从而能够根据需求制定出合理问题解决方案,有时甚至可以不需要产品改动和新增就能达到目

比如:

做一个媒体,先以微信公众号起步,就比直接开发一个App实际地多;

要推广一个新产品,是自己从零开始建一个产品官网一步步做内容做流量拉用户来得快,还是和能够直接接触到该产品潜在用户渠道合作来得快?

最怕是拍脑袋就做个产品,不考虑是否能利用已有平台资源,导致留下一堆半截子工程,说能用也凑合能用,但又缺乏清晰定位和维护,后期运营推广也不好做;同时系统里留下很多冗余代码,如果负责人一离职就再也没人能说清这产品来龙去脉,于是又推倒重来一遍……对人力物力都是极大浪费。

3.笼统型需求和精确型需求:

前者如:「现在这个编辑器太难用了换一个吧,好多代码格式都不支持」;

后者如:「需要一个除现在支持代码格式外,还能够支持markdown语法编辑器」。

很多用户反馈需求就是前者那样,必须深入了解分析,否则过于笼统不具体需求,是无法实现,即使勉强上马,也一定会因为需求不明确而导致工期延误和反复修改,最终应付了事,所有参与人忙得够呛都不开心,宁可早期多用一些时间把需求搞清楚。

4.解决问题需求和提高效率需求:

例如:「我需要一个能给用户群发邮件后台」和「我需要能够自己导出符合某些特征用户邮箱列表给他们群发邮件」。

不过后者需要评估使用频度,如果是高频使用需求,开发一个还是有必要,否则每次都要找研发同学给导出邮箱也确实麻烦;如果是为了某个临时性项目用,或者一年也用不了几次低频需求,那就没必要开发一个专门功能了。

为什么要从这些维度来划分呢,因为实现产品需求资源通常是有限,因此必须对需求合理性和优先级做出明确判断,并以此来决定开发资源投入以及排期先后。

另外有些似是而非「产品需求」,实际上并不是需求而是bug,bug和产品需求区别及处理方式不同如下:

产品需求:

针对还不存在功能提 解决是「不好用」问题 实现周期通常较长 发给产品经理处理(这个要看具体团队构成和分工,是否有专门产品经理来处理需求,如果运营兼负责产品那就由提出需求同学自己处理了)

产品bug:

针对已经存在功能提 解决是「不能用」问题 解决时间视bug严重程度,通常要求尽可能快地处理 可直接发给研发人员解决

提需求和提bug流程

产品需求描述

产品经理通常需要把收到各路需求整理成产品原型文档,但对于运营同学来说并没有那么严格文档要求,只要让产品同学能够明白你意思就可以;不过为了提高沟通效率,有必要参照一定格式来描述你需求,这里举个我现在团队例子:

1.需求名称:产品名称+功能+提出时间,如「编辑后台改进产品需求-2015-8-17」

2.目:有助于产品同学充分理解你需求必要性和重要程度,如「为了提高编辑发稿工作效率」或「为了统一网站整体风格而进行UI重新设计」。

3.优先级和时间要求:这个也很重要,因为产品经理通常会收到大量需求,如何安排优先级处理顺序?如果你在需求里有明确说明,那么处理效率会高一些。如「第一优先级,需要六月15日前完成」。

4.需求描述:说明用户身份(外部用户和内部用户处理方式有区别),页面需要包含哪些元素,期待布局和风格,排列顺序,是否必选项,有何特殊要求,是否需要查询及查询条件设定,是否需要权限管理等信息,尽可能详细,最好给出参考案例或类似竞品截图。

什么情况下需要提产品需求

如果以上你都已经烂熟于心,对于如何提产品需求应该是没有问题了。

但是且慢,知道怎么做只是最基础,对于合格运营来说,更重要是判断要做什么和不做什么。

用户需求永无止境,运营不能只是需求传声筒,需要深入分析用户需求背后和隐藏问题,如果能够用已有产品达到,就尽量不要重复建设做新产品;如果能用运营手法解决,更不必兴师动众地动用产品和研发;如果能够利用已有成熟渠道跟平台借势推广,又何苦非要做一个「自己」独立平台一切从零开始呢?

做加法永远比做减法容易,另起炉灶似乎也比在原有基础上修补改进要痛快(某些情况下,也被看做是业绩体现),但是资源永远都有限,无论是人力还是时间,即使你有一组强悍产品和研发同学 24 小时无条件配合,仍然要评估需求真实价值有多少,衡量投入产出比。

运营强项在于给你一个产品,你能够发掘它一千零一种用法(玩法)并将其传递给用户来满足业务需求,如果一接到新需求就要做个新产品,而不是先看看运用已有产品是否能够解决问题,运营自身价值何在呢?

案例一:数据分析后台

曾经有同事负责运营一个垂直专业领域群组,提出要做一个数据分析后台,能够根据加入群组用户填写个人信息自动生成各种维度分析图表,「就像专业数据分析报告那样」,他说。

这并不是一个实现起来很简单需求,虽然对用户数据分析是有必要做。但是该群组目前注册用户只有几千人,且新用户增加速度非常缓慢,用户数据分析时效性并不是非常高,因此最终解决方案是导出用户数据到Excel中,运营自己根据统计需求,利用Excel生成分析图表,至于是否像专业报告,那就看自己Excel造诣啦~如果未来用户量和增长速度达到一定规模,人工统计无法满足,才是需要开发数据统计后台时候。

案例二:大会报名App

我所在社区运营团队曾经负责组织公司开发者大会报名,通过社区各个渠道向开发者用户进行宣传,使用是社区活动报名系统,可以汇聚各个渠道报名数据到后台数据库。

有同事提议说开发一个大会报名App,以后组织大会都可以让用户通过App报名,这样推广时只要通过App推送提醒就可以啦~~~我说你这个创意不错,你先想法让用户都装上这个App,然后。。就没有然后了。。。

总之收集到需求后,先问自己以下几个问题:

目标足够明确吗? 已有产品确实无法满足工作要求吗? 已有产品缺陷已经极其影响工作效率吗? 成本是否合适?

如果答案有任何一条是否定,那就需要重新审视这个需求合理性,并且和需求方积极沟通确定最终解决方案。

如何促使需求尽快实现

需求表述明确,沟通清楚,提交流程规范:该自己做一定要做到位 按流程提交需求后最好再当面跟产品经理沟通,尽快落实需求并启动 必要时要舍得砍需求,确保快速上线 充分利用各项资源来达到目标:平时和产品设计研发同学搞好关系,甚至必要时通过老板推动都是方法(但此大招不可常用)

几点总结

产品改进通常落后于业务需求,这是正常现象 互联网产品改进伴随整个产品生命周期,不是一次性 产品改进通常是由运营驱动,由产品(不了解运营)驱动多半失败 再好产品,不重视运营也是白费 对内容运营和社区运营来说,产品是辅助手段,不是目标 具备一定产品能力运营会有更多职业发展机会

 

作者:张媛 ,八年社区运营从业者,微信公众号:技术创业空间(ID:itstarter)

本文由 @技术创业空间 授权发布于人人都是产品经理 ,未经许可,禁止转载。

 
®关于本站文章™ | 若非注明原创,默认 均为网友分享文章,如有侵权,请联系我们™
㊣ 本文永久链接: 运营如何提需求?不要只想着靠产品经理!