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