首页  ·  知识 ·  软件项目
从哪采集需求?这十方面就够了
许洵  产品中国  综合  编辑:首君   图片来源:网络
人们常常把产品经理的工作重点落在需求分析上,透过现象看人性看本质,而忽略了需求采集的工作

人们常常把产品经理的工作重点落在需求分析上,透过现象看人性看本质,而忽略了需求采集的工作。以至于在很多小型创业公司,需求往往仅出自几个公司成员拍脑袋。所谓巧妇难为无米之炊,如果需求采集没有针对性,采集目标不够典型,数量过少,采集方法不科学,没有整理跟进,光靠几人拍脑袋,拍出几个自以为的用户需求,我想,再牛的产品经理也分析不出你所谓的痛点在哪,除了你拍疼的脑袋。

外部采集(面向用户)

用户访谈

用户访谈适用于产品规划阶段,通常是一对一聊天的形式。围绕特点的话题,我们问,用户说,从中了解用户的观点。从用户的角度出发,确定产品的研究方向。

blob.png




























焦点小组

焦点小组是我们与用户进行一对多聊天的沟通形式。相比用户访谈,它能在较短时间内从用户身上获取较多的信息。需要注意的事,虽然都是与用户直面沟通,但各自的招募对象,访谈话题,调研目的等都存在差异。

blob.png























问卷调查

我们确定了产品的研究方向后,由于取样少,需要证实。问卷调查可以帮助我们,同时也能了解在细节问题上,用户是如何选择的。

blob.png


























可用性测试

在项目实施阶段的早期,我们有必要进行可用性测试。通过让实际用户使用产品或原型来发现设计中的可用性问题。当我们将用户需求转为产品需求,表达为产品的解决方案,可用性测试可以帮助我们了解用户在使用产品的过程中,是否会遇到问题,有时也能产生新的需求。

blob.png






















用户反馈

需求采集贯穿产品的整个生命周期,而不仅仅是产品规划、执行阶段。产品上线后,部分用户会积极发出反馈声音,或吐槽,或建议,或赞赏,我们也需要倾听这时候用户的声音。为了便于收集用户反馈,设计产品功能时要考虑反馈模块,运营部门要规划意见收集活动等。












内部采集(面向我们)

Bug转需求

测试人员提出的有些Bug,本质上正如我在“可用性测试”里说的,是在使用产品,达成某一目标的过程中产生的新需求。这就需要纳入需求池了。

头脑风暴

头脑风暴目的是通过自由思考,放飞思想,从而发挥集体智慧,迅速地获得大量的新设想与创意。参加者应该不受限制,脑洞大开,让暴风雨来的更猛烈些。需要特别注意的是,脑暴过程中,我们不要对任何点子进行评价。我们可以提出自己的新创意,也需要在别人的创意上继续联想拓展,产生思想碰撞。















需求卡片

需求采集人人有责,公司任何一名同事都有可能在他的日常工作生活中,了解到某种需求。需求卡片可以有效的帮助产品经理收集这部分需求。


















数据分析

这里的数据指的是产品的使用数据和行业数据。使用数据包括使用时长、使用频率、使用时间段、页面访问路径、事件跟踪数据等。可以在APP中集成第三方SDK获得这些数据。行业数据主要来自公共调研机构的数据报告。

百度指数 http://index.baidu.com

阿里指数 https://alizs.taobao.com

企鹅智库 http://re.qq.com

艾瑞资讯 http://report.iresearch.cn

竞品分析

我们可以直接在用户身上找需求,也可以在已有的同类产品中,思考分析产品设计背后的原因,挖掘它们所满足的用户需求。


本文作者:许洵 来源:产品中国
CIO之家 www.ciozj.com 微信公众号:imciow
    >>频道首页  >>网站首页   纠错  >>投诉
版权声明:CIO之家尊重行业规范,每篇文章都注明有明确的作者和来源;CIO之家的原创文章,请转载时务必注明文章作者和来源;
延伸阅读
也许感兴趣的
我们推荐的
主题最新
看看其它的