实际的工作中，到底采用何种需求采集方法，往往取决于可用资源。比如人员数量和能力、时间、经费等等。
不过通常来讲，这些用户研究或者说需求采集过程，往往有如下几步：
明确目标、选择采集方法、指定采集计划、执行采集、资料整理，最后，进入需求分析阶段。
上一篇随笔中有一个用户研究方法的思维导图，将其简化为下图的需求采集方法：
其中四个步骤分别对应下面的集中需求采集方法。
1、定性的说：用户访谈
用户访谈一般采用访谈者一对一或一对多的形式，围绕几个特定的话题，我们问，用户答，用户说，我们听，这是一种典型的定性研究。
用户访谈常用于新产品方向的预研工作中，或通过数据分析发现现象后，探索现象背后的原因。
用户访谈常见问题与对策
①、用户“说”和用户“做”经常不一致
其实大多情况下，用户不是故意欺骗我们，可能是：他们被问了自己也没仔细想过的问题，又不想回答不知道，或者用户在回答时候都是下意识的回答他们觉得我们希望得到的答案，
而不是自己的真实想法。（想深入了解的话，可以去看看社会心理学，里面有详细论述）
我们需要尽可能的让用户“说”的时候同时“做”，注意区分用户说的事实与观点，是否清晰明确，对“我觉得、我认为”等词语，带着问号去听。
②样本少，以偏概全
比如有时候我们的用户层涉及的范围比较广（地域、年龄等），但大量的样本成本又太大，性价比不高。
这时候就需要尽量做到随机，然后从中选取不随机的例子，分析出可能造成差异的原因，并在访谈记录里注明；
还可以使用增量的方式，多进行一些样本，然后统计其变化规律，和预定的结果偏差大小，如果没有改变或偏差较小（可联想下幂等性的属性），即可停止访谈活动。
（关于样本选取，这属于概率与统计学范畴，想深入了解的话，可以自行查阅）
③用户过于强势，把我们往沟里带
有时候会遇到一些个性比较鲜明或者表达欲望较强的用户，要解决这个问题，需要牢记访谈的目的。
如果发现话题不对，就立刻扳回来，若多次扳不回来，就需要尽快结束，用户很多，不要在不合适的对象上花费太多时间。
④我们过于强势，把用户往沟里带
这个问题的对策，同样，牢记访谈目的，言多必失。
推荐一本书：《软件观念革命：交互设计精髓》，作者是软件交互之父Alan Cooper，感兴趣的话可以自行查阅资料。
下面摘录一些关于用户访谈的要点：
△避免一组固定的问题：应准备好一个问题清单，但清单只是引导
△首先关注目标，任务其次：比用户行为更重要的是行为背后的原因
△避免让用户成为设计师：听用户说，但不要照着做
作者苏杰提出了一个种子用户的概念，具体可参考其博客链接：http://iamsujie.com/1000/1024/
△避免讨论技术：不要与用户纠缠产品的实现方式
△避免诱导性问题：一般来说遇到这类问题，用户给出的答案毫无意义
2、定量的说：调查问卷
同样是听用户说，常见的定量研究方法是————调查问卷。
调查问卷和用户访谈的区别：
用户访谈：通常是开放式的问题，适用于我们还比较疑惑时寻找产品方向，适合较少的访谈对象进行深入交流；
调查问卷：封闭式问题较多，适合大用户量数据收集，但不够深入，一般采取前者来为后者服务；
调查问卷注意事项：
无论线上线下，最好不要超过5分钟，开篇一般是简单不需思考的问题，需要思考和比较敏感的问题放中间，关于访谈者个人信息的问题放最后，避免访谈者顾忌而影响结果。
调查问卷常见问题与对策
①样本偏差，即样本与用户群体出现偏差
用户访谈由于样本量的限制，得出的答案比较模糊，而调查问卷的客观性，多分问卷的独立性，可以有效避免该问题。
在采用调查问卷时，应尽可能覆盖目标群体中各类型用户，要保证各类型用户样本比例接近全体比例，将一些潜在筛选条件标明。
②样本过少
样本量过少时，采用百分比来分析是没有意义的；抛开严谨的统计学概率不谈，最少要有大约100份及以上的问卷答案。
③问卷内容的细节问题
首先，问题表述应毫无引导性；其次，答案的顺序也影响被调查者的选择优先级，应多备几种形式的问卷，每种问卷答案的排列顺序都不同；
还有个通用办法就是先进行小范围的试答，根据反馈结果修改后，再大面积投放（这与我们产品发布上线的灰度发布很类似）
3、定性的做：可用性测试
可用性测试：通过让实际用户使用产品或原型的方法来发现界面设计中的可用性问题
可用性测试主要的过程如下：
①招募用户
主要原则是这些用户要能尽可能的代表将来的真实用户；比如产品主要用户特质是新手，那么就应该选择对产品不熟悉的用户；
②准备测试任务
测试前测试的组织者应准备好一系列要求用户完成的任务，任务应当是一些实际使用中的典型任务；
③测试过程（重点）
用户通过使用产品来完成所要求的任务，同时组织者在一旁观察用户操作全过程，并把发现的问题记录下来；
④测试结束
组织者可以询问用户对产品整体的主观看法或感觉，以及用户在使用中的一些想法，以及为什么做出这些操作；
⑤研究分析
可用性测试结束后，需要根据记录进行分析并产出一份可用性问题列表，对问题严重度进行分级，根据项目进度决定优先处理；
可用性测试常见问题与对策
①如果可用性测试做的太晚，发现问题也于事无补
其实在项目的各个阶段都可以做可用性测试。比如上线运行阶段，可以用真实的产品给用户做测试；产品只有页面demo时，拿demo给用户做测试；在产品只有直面原型时，拿手绘产品
加纸笔给用户做测试；甚至尚无任何成型产品时，拿竞争对手的产品给用户做测试，目的是为了避免我们犯同样的错。
②觉得可用性测试很专业，干脆不做
可用性测试，听起来很专业，但收益无法量化，且经常因为时间紧张和投入有限等原因被略过；
但可以简化步骤，根据产品类型适当进行测试，效果也比不做好很多。
③测试产品，而不是测试用户
邀请用户来测试使用产品前，应明确告诉用户，测试的目的是发现软件产品中的问题，而不是测试用户是否有能力使用产品（可以对用户说：试试我们的产品，提点意见）；
④测试过程中，组织者该做和不该做的
开始时可以告诉用户大概持续的时间、要做什么，让用户心中有数，轻松愉快完成任务；测试中要求用户在使用过程中提出自己的一些想法以及做的原因等；
过程中不能有任何引导和暗示，而只是观察和记录；结束后和用户做一些互动，赠送一些礼品，让用户觉得时间没有白费；尽快总结结果，并发给用户等。。。
4、定量的做：数据分析
数据分析是一种定量的研究方法，无论是考察用户目标全体或是采样，都完全可控且最难被驳倒。
2013年开始火爆的大数据概念，全面提出了“全样本”分析方法。
PS：通常来讲，数据分析只能发现一些现象和问题，并不能了解原因。
数据分析常见问题与对策
①过于学术，沉迷于“科学研究”
数据分析，科学研究通常只注重“性价比”的性，只要结果好，方向新，往往不计投入，但实际生产环境中，就需要考虑到性价比，特别是小步快跑的创业团队，不可能在每次分析
前都去验证样本群体是否符合某种统计分布，也不需要“人工神经网络”等高大上的手段，甚至“A＞B”的结论时也不用做“显著性校验”，一切只需要一种感觉，一种对数字的敏感，
对商业的敏感。
②数据不会主动骗人，但经常被有意无意误读
无意误读数据，举个例子，经常看到各地平均工资，然后各路人马纷纷感叹被平均，拉了后腿，其中以北上广深最甚，其中种种，大家都明白的。
这个问题的对策，多学学统计学的知识，就明白了。推荐《黑天鹅》和《统计数字会撒谎》这两本统计类图书，内容生动，比较适合工作的人群阅读。
有意的误读，这个就比较有趣了，在提取数据分析前，可能我们心中已经有了答案，无非是想通过数据分析验证它，对此，能力越强的人越容易做到这点；对此的对策就是对数据
保持中立的态度，尽量“不要为了迎合一个观点去找数据”，比如为了证明老板的判断，或为了保持自己的拍脑袋结果等。
③平时不烧香，临时抱佛脚
这是个实际的问题，很多人都是在做决策时才想起数据分析，但发现手头没有可分析的数据。为了避免此类问题，应在产品设计时就加入数据分析的需求，比如记录按钮的点击次数，
统计用户的登录在线频率，这是一种典型的非功能需求，但对产品长期规划发展非常必要。
数据分析如何转化为商业价值？
整体思路是：对产品足够熟悉的基础上，先做方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研
修正解释，最终指导产品发展方向和市场运营等。
5、需求采集，人人有责
关于需求采集，苏杰本人提出过这么一个概念：直接采集＞间接采集。可参考其博客，链接：http://iamsujie.com/1000/1025/
当然，还有一个关于需求采集的场景问题，不同场景采用不同的适合的方法，也很重要。同样可参考其博客，链接：http://iamsujie.com/1000/1020/
要做需求采集，首先必须明确一点：产品需求工作不只是需求分析人员的事，而是涉及到产品的每个干系人的义务，至少要参与“采集”的过程。
需求采集，有一点很重要，那就是：尽可能的多采集！
下面列举几个常用的需求采集例子：
①现场调查
简单说，就是去客户现场，看看客户在说什么，做什么，不过受众面较小，持续时间较长，要注意不要被用户“带到沟里去”；
②AB测试
基于大用户量比较合适，一般的做法是基于某个不确定的功能点，发布一个beta版本，随机选择一部分用户使用，一段时间后根据用户的使用结果来决定，正式发布怎么做。
不过，这是土豪大公司玩的游戏，一般中小型公司，受制于资金等因素，玩不起啊。。。
③日记研究
互联网新兴个人应用比较适合，产品发布后，大多产品经理都会尝试写一些使用体会，用户报告，但这往往是同行的结论，可参考。
④卡片分类法
很多时候，用户想法和产品人员的想法总是不同的，可以让用户提出自己心中的关于产品或某个模块是什么样的，然后产品设计人员做参考，否则很容易导致用户的理解和使用
困难，这样做的目的是使产品更符合用户的心理模型。（关于这点，可以延伸阅读学习“设计模型”和“用户模型”的概念）
⑤自己提需求
每个靠谱的产品都有一批忠实用户，产品人员自己多用相关产品，多看相关的报告内容，多和这批用户交流，会发现用户可以给你带来很多惊喜。
产品只有在使用过程中，才能辨别好坏，特别是自己的产品。自己多提需求，才能从侧面使得产品更完美。
最后，说说需求采集，其实和任何领域的知识一样，建议首先建立知识框架，然后“需求驱动学习”，即：需要什么，学习什么。。。