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

运营如何提需求 ？不要只想着靠产品经理 ！ 提产品需求是运营同学的日常工作之一 ，看 简单 ，其实并不容易。 什么是产品需求呢 ？产品需求就是对达到某个既定目标需要实现的产品功能和特性的描述 ，可以从 以下几个维度来划分 ： 1.外部需求和内部需求 ： 前者来自各个渠道收集的用户反馈 ，如微博、微信、Q Q群、客服邮箱、客服电话 ，以及产品自身 的反馈渠道 （如论坛的客服专区、在线即时咨询窗口等 ）； 后者来自公司内部 ，如老板和其它部门提出的需求。这些反馈通常都不会很明确 ，需要运营同学进 行整理挖掘、沟通调研进而提炼出需求。如果不经整理提炼就统统丢给产品跟研发同学去处理的 话——会被鄙 （qia ）视 （si ）的…… 2.改进型需求和新建型需求 ： 它们俩是从1到10和从0到1的区别。我个人的建议是已有的产品如果改进优化后能用 ，尽量不要另 起炉灶 ，除非是原有的产品从定位到风格全都跟新需求不一致。这里一方面关系到效率 ，能否快速 运用已有产品达到业务目标 ，而不是只能等着新产品上线错过宝贵的窗口期 ；另一方面关系到借势 ，是否能够借助已有的流量或者品牌优势来加速业务目标的实现。 这就要求运营对公司内部现有产品定位跟功能了如指掌 ，对公司外部可以利用的现成平台和资源也 非常熟悉 ，从而能够根据需求制定出合理的问题解决方案 ，有时甚至可以不需要产品改动和新增就 能达到目的。 比如 ： 做一个媒体 ，先以微信公众号起步 ，就比直接开发一个A pp实际地多 ； 要推广一个新产品 ，是自己从零开始建一个产品官网一步步做内容做流量拉用户来得快 ，还是和能 够直接接触到该产品潜在用户的渠道合作来得快 ？ 最怕的是拍脑袋就做个产品 ，不考虑是否能利用已有的平台资源 ，导致留下一堆半截子工程 ，说能 用也凑合能用 ，但又缺乏清晰的定位和维护 ，后期运营推广也不好做 ；同时系统里留下很多冗余 代码 ，如果负责人一离职就再也没人能说清这产品的来龙去脉 ，于是又推倒重来一遍……对人力物 力都是极大的浪费。 3.笼统型需求和精确型需求 ： 前者如 ：「现在这个编辑器太难用了换一个吧 ，好多代码格式都不支持」 ； 后者如 ：「需要一个除现在支持的代码格式外 ，还能够支持markdow n语法的编辑器」。 很多用户反馈的需求就是前者那样的 ，必须深入了解分析 ，否则过于笼统不具体的需求 ，是无法实 现的 ，即使勉强上马 ，也一定会因为需求不明确而导致工期延误和反复修改 ，最终应付了事 ，所有 参与人忙得够呛都不开心 ，宁可早期多用一些时间把需求搞清楚。 4 .解决问题的需求和提高效 的需求 ： 例如 ：「我需要一个能给用户群发邮件的后台」和 「我需要能够自己导出符合某些特征的用户邮箱 列表给他们群发邮件」。 不过后者需要评估使用频度 ，如果是高频使用需求 ，开发一个还是有必要的 ，否则每次都要找研发 同学给导出邮箱也确实麻烦 ；如果是为了某个临时性的项目用 ，或者一年也用不了几次的低频需求 ，那就没必要开发一个专门的功能了。 为什么要从这些维度来划分呢 ，因为实现产品需求的资源通常是有限的 ，因此必须对需求的合理性 和优先级做出明确判断 ，并以此来决定开发的资源投入以及排期先后。 另外有些 是而非的 「产品需求」 ，实际上并不是需求而是bug ，bug和产品需求的区别及处理方式 的不同如下 ： 产品需求 ： 针对还不存在的功能提的 解决的是 「不好用」的问题 实现周期通常较长 发给产品经理处理 （这个要看具体团队构成和分工 ，是否有专门的产品经理来处理需求 ，如果运 营兼负责产品那就由提出需求的同学自己处理了 ） 产品bug ： 针对已经存在的功能提的 解决的是 「不能用」的问题 解决时间视bug严重程度 ，通常要求尽可能快地处理 可直接发给研发人员解决 提需求和提bug的流程 产品需求描述 产品经理通常需要把收到的各路需求整理成产品原型文档 ，但对于运营同学来说并没有那么严格的 文档要求 ，只要让产品同学能够明白你的意思就可以 ；不过为了提高沟通的效率 ，有必要参照一定 的格式来描述你的需求 ，这里举个我现在团队的例子 ： 1.需求名称 ：产品名称+功能+提出时间 ，如 「编辑后台改进产品需求-2015-8- 17」 2.目的 ：有助于产品同学充分理解你的需求的必要性和重要程度 ，如 「为了提高编辑发稿的工作 效率」或 「为了统一网站整体风格而进行U 重新设计」。 3.优先级和时间要求 ：这个也很重要 ，因为产品经理通常会收到大量的需求 ，如何安排优先级处理 顺序 ？如果你在需求