一个需求的奋斗史

什么是一个需求的奋斗史？

“从需求被发现到决定实现”，这就是一个需求的奋斗史。

全过程：用户——用户研究——需求采集——需求分析——需求筛选——需求开发    （需求管理）

“从用户中来到用户中去”，做任何一个产品都是一个端到端的过程，端即用户，所以用户是需求之源，要以“用户为中心思想”。

与用户接触的过程就是需求采集的过程。常见的几种需求采集方法：“数据分析”、“调查问卷”、“用户访谈”。把用户需求转化为产品需求，这一过程即需求分析过程。

产品经理要通过“给需求做一次DNA检测”，来“确定需求的基本属性”、“分析需求的商业价值”、“初评需求的实现难度”，从而计算出需求的“性价比”。

实际工作中到底采用哪种用户研究方法，取决于资源，人员数量与能力，时间和经费。

需求采集过程：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。

定性地说 用户访谈：

一对一的聊天，一问一答的方式。经常用在新产品的预研工作中，通过数据分析发现现象以后，去探索现象背后的原因。

用户访谈经常出现的问题：

“说”，“做”不一致的问题。索尼游戏机的故事，出现了一个现象，索尼找了一些用户，问他们是喜欢黄色的游戏机还是黑色的游戏机，结果发现说喜欢黄色游戏机的偏多。为了感谢用户的配合，将送一台游戏机给他们，颜色随意挑选，然而带走的黑色游戏机偏多，有部分说喜欢黄色游戏机的用户带走了黑色游戏机。

用户倒不是故意欺骗，他们估计也没有仔细想过这个问题，又不知道怎么回答，就现场编造了一个有理有据的理由，或是在讨好访谈者的心理，他们会回答你希望听到的答案，而不是真正的想法。

防止被骗的情况下，可以让用户和产品发生交互的情况下进行，在用户“说”的同时也“做”。

样本少，以偏盖全的问题：

选择样本时需要注意，尽量做到随机。

首先，尽量识别出各种可能引起的偏差因素，并在访谈报告里标明。其次，用尽可能少的样本取得尽可能正确的结论。

例：先访谈五个用户，得出基本结论，然后再访谈五个用户，观察结果是否有所改变，有改变就加大样本量。思考问题是否合适，样本集是否合适？没有改变就停止访谈，节省成本。

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

被用户牵着走，要牢记我们访谈的目的。发现问题不对就尽快结束访谈，自行把握。

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

这个问题也是要牢记访谈的目的，并且管好自己的嘴。

避免一组固定的问题：不要让被访谈者产生被审问的感觉，应该准备好问题清单，但清单只是起到一个引导作用，并不用照着读。

首先关注目标，任务其次：比用户行为更为重要的是行为背后的原因，多问问用户为什么这么做。

避免用户成为设计师：听用户说，但不要照做，用户的方案通常短浅、片面。

避免讨论技术：遇到一些懂一点技术的用户，不要纠缠产品的实现方式。

讲故事：故事是最好帮助设计师理解用的方法。

避免诱导性的问题：典型的诱导性问题“如果有XX功能你会使用吗？”一般用户都会毫无疑问的说出肯定的回答。

用户大会

用户大会是邀请产品的用户到某一集中地点开会，人数一般几十到几百人不等，可短时间内从多人处收集大量信息，是一种特别的访谈形式。

明确目的：

如：产品的二期卖点，辅助运营决策，三期需求收集，现有产品用户体验改进等。

资源确定：

时间:日期，几点，时长。活动各项准备时间点掐准，留有余量。考虑用户空闲日子和时间段。

地点：场地、宣传用品、it设备、礼物、食品饮料、桌椅。

人物:工作人员：大家一起上，人人有事做，分工分组，注意产品、运营、开发人员的搭配，要有冗余。

用户：确定目标用户，数据提取，预约，要充分考虑人数弹性。

嘉宾：相关老板，合作部门同事，不管来不来，邀请要发到。

材料：用户数据、产品介绍材料（测试环境确保当时可用，静态Demo备用）、可用性测试材料。

各项备用方案的准备，用户大会前两天开一次“确认会”。

现场执行：

辅助工作：场地布置；引导/拍照/服务/机动；进场签到（给礼品）；全程主持（进度控制）；送客/收拾残局。

主流程:

产品介绍：重点是卖点介绍，与用户互动，观察用户更关注哪些功能，辅助上线前的运营策略，到底主推哪些卖点。

抽取部分用户做焦点小组的讨论，收集后续的需求，产品三期开始启动。同时抽取部分用户做可用性测试，帮助产品二期做最后的微调；最后，合影留念。

结束后：

资料整理：卖点总结报告、需求收集报告、可用性测试报告。

运营:本次活动论坛发帖，内部邮件。

整个活动的资料整理归档，包括照片、各项材料/报告信息、用户数据等。

定量的说：调查问卷

调查问卷通常封闭式问题比较多，合适大用户量的信息收集，但不够深入，一般只能获得某些明确问题的答案，调查问卷不是考试卷，不适合安排问答题。用户访谈与调查问卷之间也有联系，我们通常是以前者的开放式问题，为后者收集具体的封闭式问题。

无论是网上还是线下，作答时间不超过10分钟，否则很多人就会被吓跑。开篇一般放一些不需要思考的问题，敏感的放中间，个人信息题目一般放最后，以免作答者回答这些问题有顾及。

调查问卷的常见问题与对策

调查问卷一人一份，独立作答，可消除“焦点小组”、“论坛发帖征集需求”等具有群体讨论性质的方法的弊端。因为用户有其特点——沉默与骑墙的总是大多数：沉默的总是大多数，站出来的总是很少数，而往往非典型用户，不能保证其代表了目标用户的想法，大多数人是没有明确观点的，常见的情况下，就是开始表态的几个人的观点引导了群体的观点，随机的初始值决定了结果。

调查问卷的客观性、多份问卷之间的独立性，可有效避免上述问题。

但容易出现的问题：

样本的偏差，以及样本与想了解的目标用户群体出现偏差。

调查问卷的样本选择，就有几个注意点：尽可能覆盖目标用户群体中各种类型的用户，如性别、年龄、行业、收入等，要保证各种样本用户的比例接近全比例，如目标用户中男女比例为3：7，那么我们的样本比例也应该保持这个比例。

还有一个小技巧，就是可以把目标群体的特征也定义成一系列问题，放入问卷中，待我们收回问卷以后，就可以通过这写问题评估作答者是否能够代替目标群体。

样本过少的问题

样本过少采用百分比的方式来分析，是没有意义的。

例：如果问了5个人，3个人选A，就在报告中说有百分之六十的用户选A，这很不严谨。那另外再选5个人做一次，很可能是百分之四十，而这样的数字百分比要具备稳定性才有价值。所以，此时只能说“问了五个人，三个人选A”，抛开严谨的统计学不谈，要给出百分比答案的话，至少要有100份的答案。

问卷的内容问题

问题表述应无引导性，就如：用户访谈中你问用户是否喜欢这个产品一样，这时用户就会考虑提问者的感情而回答问题。正确的问法是：你是否喜欢某个产品？

还有就是答案的顺序，可能产生“顺序偏差”和“位置偏差”，即被调查者选择的答案可能与该答案的排列顺序位置有关。有研究表明，对陈述性选项被调查这趋向于选第一个和最后一个答案，特别是第一个答案；而对一组数字，打分或价格，则趋向于中间位置。为了减少顺序偏差，可以准备几种形式的问卷，每种形式的问卷排列的顺序都不同。

因此，对于重要的问卷，为了避免上述问题，还有个通用的办法就是进行小范围的试答，根据反馈修改后，再大面积的投放。

一份实际的问卷

先想清楚目的，明确样本对象，调查渠道，时间计划等，最后才是问卷内容。

问卷目的：

样本对象：

调查渠道：

时间计划：

问卷内容：不断优化。

首先，是一些简单的问题，帮助我对作答者进行分类。

然后，是一些我最想知道的问题。

接着，想了解一些你的情况。

最后，还有什么想说的？

定性地做：可用性测试

通过实际用户使用产品或原型方法来发现界面设计中的可行性问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。

它是UGC理念的一种很漂亮的实践，在目的明确的前提下，简单介绍一下主要过程。

首先招募测试用户，这些用户要尽可能的代表以后的真实用户，如主要用户是新手，那么应当选择一些对产品不熟悉的用户。

然后是准备测试任务，测试组织者应在测试前准备好一系列的任务要求用户完成，这些任务应是一些实际使用中的典型任务。

测试过程，组织者全程记录用户使用产品，并把发下的问题记录下来。

测试结束后：组织者可以询问用户对产品整体的主观看法或感觉。如果用户再测试过程中没有完全把思考的过程说出来，此时可以询问他们当时的想法，询问他们为什么做出那样的操作。

最后是研究和分析：组织者分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得我们可以根据项目进度来选择哪些优先处理。

可用性测试的常见问题与策略

如果可用性测试做的太晚，（往往在产品即将上线的时候）这时候发现问题就于事无补了。

其实可用性测试在产品各个阶段都可以做，在尚无成型的产品时，可以拿竞争对手的产品给用户做；在产品只有纸面原型时，可以拿手绘的产品，加上纸笔给用户做；产品只有页面Demo的时候，可以拿Demo给用户做；更多的时候，在产品已经可以运行以后，可以拿真实的产品给用户做。

总觉得可用性测试很专业，所以干脆不做。

可用性测试通常来说做5个左右的用户可以发现大部分共性问题，前前后后的准备也耗时不少，但只做一个用户，并且简化步骤，也比不做要好。可用性测试效率很高。

明确是测试产品，而不是测试用户。

邀请用户测试产品时，可以明确的告诉用户，这个测试的目的是发现软件产品中的问题，“可以说：来试用一下我们的新产品，提点意见。”

测试过程中，组织者该做和不该做的。

刚开始可以告诉用户要做哪些事，大概持续多少时间。在测试过程中，可以采用一种“发声思维”的方法，在使用产品的同时说出自己思考的过程。

在测试的过程中，千万不要给用户引导或暗示，而只是观察和记录。

定量地做：数据分析

数据分析如何转化为商业价值。整体思路：在对产品足够熟悉的基础上，先做出方向性的假设，再提取相应的数据分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向。

需求采集人人有责

单项需求卡：产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与“采集的过程”。

一张单项需求卡片描述了一个用户需求到底包含哪些内容，重点是描述用户场景谁在什么时间、地点产生了何种需求。

一张有价值的需求卡片，至少得有“需求描述”、需求编号、来源、场景最好也要有。

尽可能多地采集

需求采集，并不是产品设计之前的工作，而是一个贯穿始终的过程。

现场调查：简单来说：就是和客户一起工作一段时间，深度了解需求。这是一种典型的定性分析，持续时间长，可能是几小时也可能是几个月，既能听到用户怎么说，也能看到用户怎么做，不过受众面积极其狭窄。

AB测试：基于大用户量比较合适，比如一个按钮不知道放在页面的左边好还是右边好，如果有十万用户，那就先挑选少量用户发布这个按钮，1000人放左边，1000人放右边，然后过一段时间分析结果。再决定剩下的百分之九十八的用户该怎么办。

需求分析：一个是用户需求，一个是产品需求，而这中间的转化过程就是需求分析。

用户需求VS产品需求

用户需求：用户自以为的需求，并且表达为用户自己的解决方案。

产品需求：经过我们分析，找到真实的需求，并且表达产品的的解决方案。

需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。

需求分析首先：树叶——树枝——树干，其次：树干——树枝——树叶的分析过程，不能漏掉提炼用户需求的过程，目的是透过现象看本质，一方面也不能停留在本质。

伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说用户真正想要的东西，这就是——我们存在的价值。

满足需求的三种方式

需求来源于理想与现实的差距，那么减小这个差距就有三种方式：

改变现状。是我们最常用的，去开发某种产品，但也是最笨的办法。

降低理想。不要忽视精神的力量，什么“打预防针”、“丑话说在前头”，这类句子想必大家都听说过。

转移需求。因为人类的注意力是有限的，人的行为是需求驱动的，想改变人的行为，可以寻找更强烈的需求展现给他，而让他不在纠结于原来的需求。

也谈创造需求

产品设计的最高境界——创造需求！

给需求做一次DNA检测

需求转化——确定基本属性——分析商业价值——初评实现难度——计算性价比

把用户需求转化为产品需求

Excel来记录需求——删除一些不靠谱的需求

需求的基本属性：编号、提交人、提交时间、模块、名称、描述、提出者、提出时间、BUG编号

需求的种类

分类：新增功能、功能改进、体验提升、Bug修复、内部需求等。

层次：基础、扩展（期望需求）、增值（兴奋需求） 理论参考KANO模型

分析需求的商业价值

一个公司做任何产品，一个产品做任何需求，最终都要满足一定的商业目的，所以需求的商业价值是最关键的内容。

三个指标来衡量商业价值

重要性、紧急度、持续时间

商业价值描述：需求的卖点是什么、可以给用户提供什么价值、对公司有什么帮助。

初评需求的实现难度

绝对不能因为某个需求的商业价值很大就马上去做，也不能因为某个需求的商业价值不大就不做。

知道每个需求的商业价值，接下来做哪一个的关键指标就是——实现难度。

技术代表参会，会后与相关的PD讨论确定。

实现难度——简化为人力成本，即工作量，简化为开发量。

开发量是非评估不可的，我们把它叫做“初评"，允许误差，并且会让经验丰富的人来评估，通常是技术经理，或系统分析师、架构师。

性价比啊性价比

我们已经做了需求采集，把用户需求转化为产品需求，知道了某个需求的基本属性、种类、商业价值、开发量，现在似乎可以开始写文档了、干活了，但经验告诉我们不是这样：

性价比=商业价值÷实现难度（简化为开发量）

活下来的永远是少数

需求PK

需求筛选：需求打包——BRD制作——产品会议————立项

做项目，终极目标就是：多快好省，即范围大、时间短、品质高、资源省。

需求打包，最好打包类似的功能点。

需求依赖，功能互相之间有依赖关系。

需求的粒度大小问题。在需求列表里出现的每一行，工作量最好不要超过“5人天”。

商业需求文档（BRD）怎么写

项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列举出一些数据说明项目的必要性。

商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般会预测一下相关数字的变化，提出这个项目的商业目标。

功能需求描述：我们怎么去 ？通过做哪些事情来达到目标，把打包好的需求描述一下，可以用功能列表的形式表达，最好能画出业务逻辑关系。

非功能需求描述：提一下重要的非功能需求，如果有的话。

资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后，才能做出决策。

风险和对策：有的项目会有一些潜在的风险，不妨抛给老板看看，并且给出自己的策略。