码农的产品思维培养第2节----一个需求的奋斗史（人人都是产品经理）

今天我们继续坚持每日一节的产品思维培养，我喜欢在纸上画，喜欢做笔记。不是为了自己后面回去看，而是为了当时更好理解。不知道大家是否认同这点。

今天看到苏杰的一句话，其实和我之前讲过的是一致的，看来英雄所见略同，还是给大家分享一下“和学习任何领域的知识一样，建议大家在了解了知识框架之后，坚持“需求驱动学习””。

第二章，讲述的是一个需求的奋斗史。其实就是描述如何从用户那里得到需求，得到需求后如何处理的一个过程。今天，我们这一节讲如何从用户那里拿到需求。

用户研究,或者说需求采集的过程,都会有如下几步:明确目标、选择采集方法、制定采集计划、执行采集、资料整理,然后进入下一步的需求分析阶段。

根据定量和定性以及说和做，我们可以将需求采集的方法分为如下：

定性地说:用户访谈

    一对一的聊天，在每一而用户身上花费较多的时间，可能从几十分钟到几个小时。常常用在新的产品预研中。因为那个时候你也没太多的信息基础，你最好和用户进行深度的开放性聊天，然后在交流中采集用户的需求。

然而，每一种用户采集方法都有它的弊端，存在的问题。用户访谈存在的问题及对策：

1）“说”和”做“不一致的问题。

你问的一些问题，用户没碰到过，不熟悉，然后用户会给出一个无关痒痛的答案，甚至用户会去猜测你的心理，会去迎合你。所以给出一个他觉得你想要的答案。

所以，尽量让用户发生交互，在说的同时也做，就比如索尼的那个游戏机案例，他说喜欢黄色，结果拿的却是黑色。

还要注意点“我做了什么，我的步骤是xxx，我碰到了什么问题”这样的客户访谈内容会比“我觉得，我认为”要可信度高。所以，注意区分收集到的信息的质量分类。

2）样本少，以偏概全的问题

对于这个问题，主要是回来访谈的人毕竟少数，而会来访谈本身也说明了有个刷选过程，可能就和实际的客户群体有偏差了。还有，你说要调查全国，但你可能只调查深圳，甚至是科技园的码农。那都是会受到影响的。对于这些问题，解决的方法是：尽量识别出各种引起偏差的因素；以增量式进行访谈。

3）用户过于强势，把我们往沟里带

这个主要是，用户访谈的过程，用户开始讲故事了。慷慨激昂的讲自己的故事，结果一个下午下来，你的访谈目标没有一个完成。听了一下午的故事。记住时刻牢记访谈的目的，记得拉他回来，如果跑题了，如果拉不回那就早点结束访谈。

4）我们太强势，把用户往沟里带

这个主要是我们的访谈员太强势，当用户可能对我们的产品说出问题的时候。我们的人心里不爽，然后争辩，最后用户服了，就差道歉了。所以，要记住自己的目标是收集用户需求，不是卖我们的产品多好用。

最后，记一次用户大会

  确定以产品卖点，明确产品需求优先级，培养种子用户。

定量的说：调查问卷

    都是听用户说，但是调查问卷和用户访谈是有区别的。

用户访谈是提供一些开放式问题，深入的去交流。它在我们对产品方向也不是很清楚的时候用；而调查问卷往往在用户访谈之后，或者至少我们知道产品方向了。这个时候需要收集大量用户信息，但不需要特别深入的信息。调查问卷只提供选择题，不提供作答题，最好不能太长，几分钟就搞定。而且问题的顺序要讲究，比如一开始应该特别容易的，让用户不排斥，然后中间放重要的，这个时候用户已经投入进去了，基本不会或者说不好意思不去作答，最后要收集用户隐私的时候，放到后面，因为其实用户是特别反感自己的联系方式等等被收集的，所以如果放在前面，那么他所有的题都不会做就走的。就算他不留电话什么的，至少他已经作答了前面的问题，所以，顺序绝对要仔细考虑。

作者还说了一个东西就是，用户有其特点----沉默与骑墙的总是大多数。随机的初始值决定了结果。-----《长尾理论》

调查问卷也有很多弊端以及如何避免。

例如样本偏差，例如样本过少，例如问卷的设计细节等等。

一个真是的问卷案例是苏杰自己的书的问卷调查。http://iamsujie.com/

定性的做：可用性测试

    可用性测试：让实际用户使用产品或者原型方法来发现界面设计中的可用性问题。补充一个UGC的概念。

UGC（User Generated Content，用户产生内容，想到了优酷没有）。

怎么做可用性测试呢？主要的步骤如下：

1）招募测试用户，尽量代表真实的用户。跟用户不要说什么可用性测试，那样他会有戒备心里。而应该说“来试用一下我们的新产品，提点意见”。

2）准备测试任务，那些任务肯定是典型的任务。

3）测试过程。测试的时候，一定要观察用户的测试过程，最好允许发声测试，就像用户在打游戏的时候，让他说，问他，你为什么要走这里，他会告诉你理由，这种交互是非常有用的。记录下过程中暴露的问题。

4）测试结束后，问用户对产品的整体感受。并送人家礼物，作为对人家时间耗费的补偿。

5）研究与分析。

可用性测试中也会碰到很多的问题，以及作者给出了相应的对策。

第一,如果可用性测试做得太晚(往往在产品将要上线的时候),这时发现问题也于事无补了。

其实，产品的每个阶段都可以做可用性测试的，没产品的时候用静态原型也可以，用铅笔给用户画都好。

第二,总觉得可用性测试很专业,所以干脆不做。其实，如果徒省事，你可以叫一个项目外的用户来试一试也是可以的，总比没有更好。

第三,明确是测试产品,而不是测试用户。千万不要带着培训的心去做可用性测试。你要的是用户来暴露你的问题。

第四,测试过程中,组织者该做的和不该做的。

允许发生测试，不得有暗示或者引导。

定量的做：数据分析

这里就体现了日志系统的重要性，记得在产品的一开始就有意的去加入统计代码，比如页面的点击次数，按钮的点击等等这些。数据相对是不会说谎的。

将数据转化为商业价值。

最后，提倡所有的人都参与到需求采集中，理解“一手需求”与“二手需求”，作者还提到了单项需求卡片。这样就方便不专业的同事也可以带着卡片去收集信息。

好今天到这里。