什么是产品需求呢?产品需求就是对达到某个既定目标需要实现的产品功能和特性的描述,可以从以下几个维度来划分:
1.外部需求和内部需求
前者来自各个渠道收集的用户反馈,如微博微信qq群客服邮箱客服电话,以及产品自身的反馈渠道(如论坛的客服专区、在线即时咨询窗口等);后者来自公司内部,如老板和其他部门的反馈。这些反馈通常都不会很明确,需要运营同学进行整理挖掘,沟通调研进而提炼出需求。如果不经整理提炼就统统丢给研发同学去处理的话——会被鄙(qia)视(si)的……
2.改进型需求和新建型需求
它们俩是从1到10和从0到1的区别。我个人的建议是已有的产品如果改进优化后能用,尽量不要另起炉灶,除非是原有的产品从定位到风格全都跟新需求不一致。这就要求运营对现有产品定位跟功能了如指掌,能够根据需求制定出合理的问题解决方案,有时甚至可以不需要产品改动就达到目的。这样不是效率很高吗~
最怕的是拍脑袋就做个产品,不考虑是否能利用已有的,导致留下一堆半截子工程,说能用也凑合能用,彼此间定位不清晰,后期运营推广也不好做;同时系统里很多冗余代码难以维护,如果负责人一离职就再也没人能说清这产品的来龙去脉,于是又推倒重来一遍……对人力物力的极大浪费啊。
3.笼统型需求和精确型需求
前者如“现在这个编辑器太难用了换一个吧,好多代码格式都不支持”,后者如“需要一个除现在支持的代码格式外,还能够支持markdown语法的编辑器”。很多用户反馈的需求就是前者那样的,必须深入了解分析,否则过于笼统不具体的需求,是无法实现的,即使勉强上马,也一定会因为需求不明确而导致工期延误和反复修改,最终应付了事,所有参与人忙得够呛都不开心,宁可早期多用一些时间把需求搞清楚。
4.解决问题的需求和提高效率的需求
“我需要一个能给用户群发邮件的后台”和“我需要能够自己导出符合某些特征的用户邮箱列表给他们群发邮件”。不过后者需要评估使用频度,如果是高频使用需求,开发一个还是有必要的,否则每次都要找研发同学给导出邮箱也确实麻烦;如果是为了某个临时性的项目用,或者一年也用不了几次的低频需求,那就没必要开发一个专门的功能了。
为什么要从这些维度来划分呢,因为实现产品需求的资源通常是有限的,因此必须对需求的合理性和优先级做出明确判断,并以此来决定开发的资源投入以及排期先后。