需求采集的“Z方法”

标签: 产品设计 用户研究 需求分析 | 发表时间:2014-04-02 23:40 | 作者:漓江
出处:http://www.woshipm.com

前段时间总结出了个 “Y理论”,最近又整理出一个“Z方法”,个人感觉便于实操,大家看着玩儿。

需求采集,或者说用户研究的方法很多,比较经典的分类就是按“ 定性  vs  定量;说 vs ”二维。先回顾一下我在 《人人都是产品经理》里说的:

横向,定性与定量。

定性研究可以找出原因,偏向于了解;而定量研究可以发现现象,偏向于证实。两者都很重要,缺一不可,只定量会“以标代本”,看到问题但不知道原因,只定性会“以偏概全”,很可能被部分样本的特殊情况带入歧途。人们认知新事物的过程通常都是从定性到定量再定性再定量,并且螺旋上升,而了解和证实也是在不断迭代进化的。

纵向,用户的说和做。

怎么说表现了目标和观点,怎么做反映了行为,用户怎么说和怎么做经常是不一致的。两方面都很重要,我曾经认为“耳听为虚,眼见为实”,所以看到用户怎么做会比听他们说更真实有用,但后来体会到,只了解做是没办法知道背后原因的,而不知道问题的原因也就意味着没法从根本上解决问题。所以我们既要看用户怎么做,也要听用户怎么说,虽然他说的不一定是真话。

而四象限中,最常见的方法又如下—— 用户访谈、调查问卷、可用性测试、数据分析。这块内容,其实早就提过,只不过,最近把这些方法攒出了一个“Z”字,方便同学们记忆,可说是需求采集最简单的组合拳。

需求采集的“Z方法”

说和做、定性与定量,合理的搭配组合使用,才能发挥最大的作用,而对于一个产品来说,正好在不同的时期可以用不同的方法,下面举一个典型的例子,正好是用到了上述4种办法,按照时间顺序,“自上而下,从左到右”在图里画出一个大写的“Z”:

第一轮,产品规划阶段。听用户定性地说,确定产品方向,做什么?随机抽样了40个用户做访谈,据此写出需求列表。

第二轮,某个项目的早期。听用户定量地说,确定需求优先级,先做什么?投放了20万份调查问卷,确定了需求优先级的排序。

第三轮,项目实施过程中。看用户定性地做,要先做的那几个需求,应该怎么做?一边设计,一边陆续的找了10个用户来验证,做可用性测试。

第四轮,上线后的优化阶段。看用户定量地做,根据产品的用户使用情况做数据分析,不断地改进产品。

具体怎么做,去看其他材料把。当然,这是一个比较重要的产品,所以在用户研究上投入了较多的时间与人力,更多的时候,我们会视情况采取简化的方案。

作者:苏杰

原文地址: http://iamsujie.com/1000/1018/


微信号:woshipm,干货天天推荐,欢迎关注

相关 [需求 方法] 推荐:

产品方法论:需求变更

- 盛开 - 所有文章 - UCD大社区
IT行业中失败项目的比例可以说明“项目管理”是很难做好的事情,项目失败的原因千千万,我认为需求管理、需求变更管理是个很重要的因素. 恰恰PM的工作缺不了项目管理,更缺不了对于需求的管理,偶然的原因,和团队分享了我对于项目进行中“需求变更”的理解和管理方法. 忽然发现之前写过很多产品思考和细节思考的东西,但从没有整理出方法论,后续应该多整理下方法论.

需求采集的“Z方法”

- - 人人都是产品经理
前段时间总结出了个 “Y理论”,最近又整理出一个“Z方法”,个人感觉便于实操,大家看着玩儿. 需求采集,或者说用户研究的方法很多,比较经典的分类就是按“ 定性  vs  定量;说 vs 做”二维. 先回顾一下我在 《人人都是产品经理》里说的:. 定性研究可以找出原因,偏向于了解;而定量研究可以发现现象,偏向于证实.

软件需求获取方法

- - 研发管理 - ITeye博客
软件需求获取是软件需求开发的关口环节,关口没把守好,后面就会全面溃败. 软件需求获取个人认为有以下几个方法:. 现有产品和竞争对手的描述文档;. 面谈是获取软件需求的最有用的方法之一. 面谈对象:与系统相关的涉众,并具有代表性,保证涵盖到每个角色. 谁会受到系统结果的影响,谁来监管该系统. 面谈问题:需保证与背景无关,保证获取信息的公正性.

获取产品需求的五种方法

- - CSDN博客推荐文章
    很多公司都谈到产品战略规划,那么产品需求到底从何而来,如何获得这些需求.     笔者认为,产品需求主要有三种来源渠道:(1)从已有的市场需求中提炼;(2)策划并激活市场新需求(也叫创造需求);(3)从组织所建设的若干类似项目中提炼出产品需求.     围绕产品需求的这三种来源渠道,笔者认为有五种产品需求获取的方法:.

再谈需求

- - 人月神话的BLOG
谈需求工程方面的文章前面写过很多,本文仅做最近思考的一些点滴记录. 首先我们谈下业务建模层面,对于从用户提出最初的业务需求到交付一个完整的系统,在建模层面涉及到两个层面的抽象,其一就是业务建模解决现实世界本身的抽象描述,其二就是软件架构设计,解决从业务模型到IT架构模型的第二次转换. 在早些时候我们看到这两个层面的建模内容都由系统分析员承担或完成,在岗位不断细分后我们看到反而会出现忽视了业务建模的问题.

需求变化与IoC

- - 酷壳 - CoolShell.cn
【感谢 Todd投递本文 – 微博帐号:@ weidagang 】. 程序员XX遭遇车祸成植物人,医生说活下来的希望只有万分之一,唤醒更为渺茫. 可他的Lead和亲人没有放弃,他们根据XX工作如命的作风,每天都在他身边念:“XX,需求又改了,该干活了,你快来呀. ”,奇迹终于发生了,XX醒来了,第一句话:“需求又改了.

进化而来的需求

- - 极客公园-GeekPark
[核心提示]需求是可以创造,可以进化的. 在需求的“博尔赫斯库”中,我们要做的,仅仅是模拟规则,让需求,优胜劣汰. 如果本文的标题和导语引起了坐在电脑前的你的兴趣,同时又产生了些许的疑惑,那么恭喜我自己,我的目的达到了 (真是恶趣味……). 那么,在对它们进行解释之前,还容我卖个关子,先从几个有趣的见闻讲起.

谈需求和设计

- - 人月神话的BLOG
在这里再谈下需求和设计的边界问题,我们最终的业务系统实现出现的偏差,究竟是需求的问题还是设计的问题. 如果边界不清楚则很难明确的区分. 对于需求本身有原始需求,用户需求,产品需求和系统需求的各种阶段;而对于需求的过程也本身存在原始需求的收集,需求分析,需求挖掘,和需求相关的业务建模. 而对于设计同样存在总体的企业架构设计,到单个应用的总体设计和架构设计,概要设计和详细设计.

解决方案与需求

- - 扯氮集--上海魏武挥的博客 - 扯氮集--上海魏武挥的博客
曾经有一个很有名的段子,大致意思就是说在汽车尚未出现的马车时代,你去做消费者调研,只会得到这样的答案:我需要一匹更快的马,而不会得到:我需要汽车. 因为对于消费者来说,他从来没有看到过汽车,怎么可能回答你需要汽车呢. 这个段子,似乎充分说明了,创新,尤其是颠覆式创新、破坏性创新是不可能通过需求调研出来的.

如何做需求分析

- - 人人都是产品经理
这段时间我做了两个大项目,其中一个项目算是商业模式上和使用规范上的调整,另一个项目是之前功能的重做,为什么重做我下面会说到. 关于需求分析,我认为把需求抽象成产品功能花费的时间占到了软件开发周期的40%,产品设计到评审完的时间大概是20%,也就是说实际开发之前产品团队介入的工作占据项目的60%,在需求分析阶段我有一些个人观点.