今天我们继续坚持每日一节的产品思维培养。我喜欢在纸上画，喜欢做笔记。
不是为了自己后面回去看。而是为了当时更好理解。不知道大家是否认同这点。
今天看到苏杰的一句话，事实上和我之前讲过的是一致的，看来英雄所见略同。还是给大家分享一下“和学习不论什么领域的知识一样，建议大家在了解了知识框架之后，坚持“需求驱动学习””。
第二章，讲述的是一个需求的奋斗史。事实上就是描写叙述怎样从用户那里得到需求，得到需求后怎样处理的一个过程。今天，我们这一节讲怎样从用户那里拿到需求。
用户研究,或者说需求採集的过程,都会有例如以下几步:明白目标、选择採集方法、制定採集计划、运行採集、资料整理,然后进入下一步的需求分析阶段。
依据定量和定性以及说和做。我们能够将需求採集的方法分为例如以下：
定性地说:用户訪谈
一对一的聊天。在每一而用户身上花费较多的时间。可能从几十分钟到几个小时。经常常使用在新的产品预研中。
由于那个时候你也没太多的信息基础，你最好和用户进行深度的开放性聊天，然后在交流中採集用户的需求。
然而，每一种用户採集方法都有它的弊端，存在的问题。
用户訪谈存在的问题及对策：
1）“说”和”做“不一致的问题。
你问的一些问题，用户没碰到过。不熟悉，然后用户会给出一个无关痒痛的答案，甚至用户会去推測你的心理，会去迎合你。所以给出一个他认为你想要的答案。
所以，尽量让用户发生交互。在说的同一时候也做。就比方索尼的那个游戏机案例，他说喜欢黄色，结果拿的却是黑色。
还要注意点“我做了什么。我的步骤是xxx，我碰到了什么问题”这种客户訪谈内容会比“我觉得，我觉得”要可信度高。
所以。注意区分收集到的信息的质量分类。
2）样本少，以偏概全的问题
对于这个问题，主要是回来訪谈的人毕竟少数，而会来訪谈本身也说明了有个刷选过程。可能就和实际的客户群体有偏差了。还有，你说要调查全国。但你可能仅仅调查深圳，甚至是科技园的码农。那都是会受到影响的。对于这些问题，解决办法是：尽量识别出各种引起偏差的因素。以增量式进行訪谈。
3）用户过于强势。把我们往沟里带
这个主要是，用户訪谈的过程，用户開始讲故事了。大方激昂的讲自己的故事。结果一个下午下来，你的訪谈目标没有一个完毕。听了一下午的故事。记住时刻牢记訪谈的目的，记得拉他回来。假设跑题了，假设拉不回那就早点结束訪谈。
4）我们太强势，把用户往沟里带
这个主要是我们的訪谈员太强势，当用户可能对我们的产品说出问题的时候。我们的人心里不爽，然后争辩。最后用户服了，就差道歉了。
所以，要记住自己的目标是收集用户需求，不是卖我们的产品多好用。
最后，记一次用户大会
确定以产品卖点。明白产品需求优先级，培养种子用户。
定量的说：调查问卷
都是听用户说。可是调查问卷和用户訪谈是有差别的。
用户訪谈是提供一些开放式问题。深入的去交流。
它在我们对产品方向也不是非常清楚的时候用；而调查问卷往往在用户訪谈之后。或者至少我们知道产品方向了。这个时候须要收集大量用户信息，但不须要特别深入的信息。调查问卷仅仅提供选择题，不提供作答题，最好不能太长。几分钟就搞定。
并且问题的顺序要讲究，比方一開始应该特别easy的，让用户不排斥，然后中间放重要的。这个时候用户已经投入进去了，基本不会或者说不好意思不去作答，最后要收集用户隐私的时候，放到后面，由于其有用户是特别反感自己的联系方式等等被收集的。所以假设放在前面。那么他全部的题都不会做就走的。
就算他不留电话什么的。至少他已经作答了前面的问题。所以。顺序绝对要细致考虑。
作者还说了一个东西就是，用户有其特点----沉默与骑墙的总是大多数。随机的初始值决定了结果。
-----《长尾理论》
调查问卷也有非常多弊端以及怎样避免。
比如样本偏差，比如样本过少，比如问卷的设计细节等等。
一个真是的问卷案例是苏杰自己的书的问卷调查。
定性的做：可用性測试
可用性測试：让实际用户使用产品或者原型方法来发现界面设计中的可用性问题。补充一个UGC的概念。
UGC（User Generated Content，用户产生内容，想到了优酷没有）。
怎么做可用性測试呢？基本的过程例如以下：
1）招募測试用户。尽量代表真实的用户。跟用户不要说什么可用性測试。那样他会有戒备心里。而应该说“来试用一下我们的新产品，提点意见”。
2）准备測试任务。那些任务肯定是典型的任务。
3）測试过程。
測试的时候。一定要观察用户的測试过程。最好同意发声測试。就像用户在打游戏的时候。让他说，问他，你为什么要走这里。他会告诉你理由。这样的交互是很实用的。
记录下过程中暴露的问题。
4）測试结束后。问用户对产品的总体感受。并送人家礼物。作为对人家时间耗费的补偿。
5）研究与分析。
可用性測试中也会碰到非常多的问题，以及作者给出了对应的对策。
第一,假设可用性測试做得太晚(往往在产品将要上线的时候),这时发现问题也于事无补了。
事实上，产品的每一个阶段都能够做可用性測试的，没产品的时候用静态原型也能够。用铅笔给用户画都好。
第二,总认为可用性測试非常专业,所以干脆不做。事实上，假设徒省事，你能够叫一个项目外的用户来试一试也是能够的，总比没有更好。
第三,明白是測试产品,而不是測试用户。千万不要带着培训的心去做可用性測试。
你要的是用户来暴露你的问题。
第四,測试过程中,组织者该做的和不该做的。
同意发生測试，不得有暗示或者引导。
定量的做：数据分析
这里就体现了日志系统的重要性。记得在产品的一開始就有意的去增加统计代码。比方页面的点击次数。button的点击等等这些。数据相对是不会说谎的。
将数据转化为商业价值。
最后，提倡全部的人都參与到需求採集中，理解“一手需求”与“二手需求”，作者还提到了单项需求卡片。
这样就方便不专业的同事也能够带着卡片去收集信息。
好今天到这里。