需求采集的“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架构模型的第二次转换. 在早些时候我们看到这两个层面的建模内容都由系统分析员承担或完成,在岗位不断细分后我们看到反而会出现忽视了业务建模的问题.

海康威视:形成软件开发方法论,社会经济到了由商业需求拉动的时代

- - 雷锋网
近日,海康威视举行投资者问答会议. 在AI市场机会上,海康认为AI的机遇已经得到行业普遍认同,未来AI成本会持续降低,AI技术在改善产品性能上作用很大,AI算法和大数据等,会带来许多之前想做但做不到的业务机会,也会开拓新玩法,未来会打开更多市场. 在软件投入上,组件化的开发已经是海康确定的软件开发方法论.

分享一个平时工作找需求找竞品的方法:通过产品使用的核心技术库 - 即刻App

- -
分享一个平时工作找需求找竞品的方法:通过产品使用的核心技术库,找使用这个库的 project showcase. 起源是公司内部最近出现了一个我和 leader 都觉得惊为天人的产品. 但是因为是保密项目我们能获取到的信息不够,我们判断这种交互模式和 UI 体验是借鉴了某个海外产品,大概率不是我司的原创.

需求变化与IoC

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

进化而来的需求

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

谈需求和设计

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