产品经理的进阶——需求的成长史

第二章 需求的成长史：

目录

第二章 需求的成长史：

2.2需求采集

定性：用户访谈

定量：调查问卷

定性：可用性测试。

定量：数据分析 according to the data.

需求采集人人有责：

需求采集的方法：P65

2.3听用户的但不要照着做

需求分析：用户需求vs产品需求。

满足需求的三种方式：

2.4活下来的少数

需求打包：

BRD：商业需求文档——性价比

少就是多

---

2.2需求采集

定性：用户访谈

Q1：说和做不一致。

A1：用户和产品交互下访谈 + “我做了什么”可信度大于“我认为，我觉得”

Q2：样本少，以偏概全。

A2：尽量随机 + 识别可能引起偏差的因素，标注 + 增量的方式做访谈。

Q3：用户过于强势。

A3：时刻牢记访谈目的 + 把我流程。

Q4：我们过于强势。

A4：牢记访谈目的，管好自己的嘴。

1. 避免一组固定的问题。
2. 首先关注目标，任务其次。
3. 避免让用户成为设计师。
4. 避免讨论技术。
5. 鼓励讲故事。
6. 避免诱导性问题。

定量：调查问卷

Q1：调查问卷vs用户访谈

A1：

调查问卷——封闭问题+大量用户信息搜集+不够深入+获得某些明确问题答案+不适合安排问答题。

用户访谈——开放式问题+适合心里比较疑惑时区寻找产品方向+较少用户+深入交流。

Q2：问卷设置。

A2：

不超过10分钟+开篇是简单不需要思考的问题+想知道的，需要思考的敏感性问题放中间+个人信息问题放最后。

注意问卷的客观性+多份问卷之间的独立性。

Q3：样本偏差。

A3：

尽可能的覆盖目标群体用户+保证各类用户样本的比例接近全体的比例+加上筛选条件，并标明+把目标群体定义成一系列问题，方便筛选。

Q4：样本过少。

A4：不要用百分比表示。

Q5：问卷内容细节的问题。

A5：

问题表述无引导性+答案的顺序设置，多设置几种问卷+小范围试答，调整后，再大面积投放【互联网产品灰度发布。

定性：可用性测试。

可用性测试：让实际用户使用产品或者原型的方法来发现界面设计中的可用性。

步骤：

1. 招募测试用户：尽可能的代表将来的真实用户。
2. 准备测试任务：提前准备好一系列要求用户完成的任务，实际使用中的典型任务。
3. 测试过程：用户完成+组织者记录操作过程和发现的问题。
4. 测试结束后：询问用户对于产品整体的主观看法或感觉 + 询问当时的想法，为什么做出那些操作。
5. 研究和分析：分析记录产出一份产品的可用性问题列表 + 对问题的严重程度进行分级 +根据项目进度选择哪些优先处理。

Q1：测试做得太晚，产品要上线了。

A1：任何阶段都可以做可用性测试。

       尚无任何成型产品时——那拿竞争对手的产品给用户做。

       产品只有纸面原型时——拿手绘的产品加纸笔给用户做。

       产品只有页面demo时——那demo给用户做。

       更多时候，产品已经可以运行时——拿真实的产品给用户做。

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

A2：简化步骤，做比不做好。5个左右的用户才可以发现大部分共性问题。

Q3：明确测试的是产品，不是测试用户。

A3：不要让用户听到“可用性测试”的术语，而是说“来试用一下我们的产品”，减轻用户压力。

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

A4：

       开始时——告知用户持续时间+要做哪些事情，让用户心中有数，愉快的完成任务。

测试中——要求用户“发生思维”，在试用过程中同时说出自己的思考过程，想先做什么，后做什么，为什么有某个动作……

过程中——不能有任何的引导和暗示，只观察和记录 + 用户行为和预想的不一样时可以提问 + 测试进行不下去时，可以给予提示。核心原则：一切都是产品的错，用户不会错。

结束后——送小礼品感谢用户 + 尽快总结，反馈给用户 + 建立长期和谐的“用户参与产品设计”的氛围。

       最重要的——这份总结用于指导产品改进。

产品改版的建议：

1. 先从部分次级页面改起。
2. 新旧版本共存一段时间，允许用户自由选择。
3. 小面积试验，选择一小批测试用户放出新版本，监测效果，做用户调研。
4. 傍上一个用户已经习惯的风格。

定量：数据分析 according to the data.

Q1：过于学术，性价比不高。

A1：培养一种对数据的敏感，对商业的敏感。

Q2：数据不会主动骗人，但是我们经常有意或无意的误读数据。

A2：学习统计学知识，提供自己的水平 + 不要为了迎合一个观点而去找数据，减少利益牵扯。推荐《黑天鹅》+《统计数字会撒谎》两本书。

Q3：临时抱佛脚。

A3：在产品设计的时候把数据分析的需求加进去，记录每个按钮的点击次数、统计每个用户的登录频率。对产品的可持续发展很必要。

需求采集人人有责：

生孩子：产品诞生前，产品人员驱动，主动采集需求——直接去潜在目标用户那里采集。

养孩子：产品已经运营一段时间，收到很多被推过来的需求 + 用户提出的需求 + 二手需求。

二手需求采集工具——单项需求卡片。P63

需求采集的方法：P65

1. 现场调查。
2. AB测试。
3. 日记研究。
4. 卡片分类法。
5. 自己提需求

2.3听用户的但不要照着做

需求分析：用户需求vs产品需求。

       用户需求：用户以为的需求，经常表达为用户的解决方案。

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

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

注意：权衡短期利益vs长期利益。

满足需求的三种方式：

1. 改变现状。
2. 降低理想。
3. 转移需求。
4. 产品设计的最高境界：创造需求，教育用户。

需求检测步骤：

用户需求转换为产品需求——>确定产品需求的基本属性 + 商业价值 + 实现难度 + 性价比。

用户需求转换为产品需求：头脑风暴 + 功能列表Feature List。

确定需求基本属性：基本属性表P73

需求种类：分类（新增功能、功能改进、体验提升、Bug修复、内部需求等）+层次KANO（基础、期望、兴奋）。

商业价值：重要性 + 紧急度 + 持续时间 +商业价值

实现难度：简化为工作量=开发量。

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

2.4活下来的少数

需求打包：

       做项目终极目标：多快好省Time Resource Quality Quantity——范围大、时间短、品质高、资源省。——推崇【敏捷方法】

1. 需求打包最好打包相似的功能点 + 通过业务逻辑图可视化。
2. 需求依赖，功能之间有互相依赖的关系。
3. 需求的粒度大小问题：需求粒度尽量细 + 需求列表里出现的任意一行，工作量不要超过“5人天”。

BRD：商业需求文档——性价比

1. 项目背景：我们在哪里？为什么做这个项目？解决什么问题？——可列出一些数据说明项目必要性。
2. 商业价值：我们去哪里？【最关键】——要说在点子上；预测相关数字变化；提出项目的商业目标。
3. 功能需求描述：我们怎么去？通过做哪些事情达到目标？——把打包好的需求描述一下，用功能列表表达，画出业务逻辑关系；技巧性的东西，故意加入一点让老板砍的需求。
4. 非功能需求描述。
5. 资源评估：【第二个重点】——成本，达成目标需要多大的花费。
6. 风险和对策：预估风险；给出对策；让老板把关。

少就是多

       100%的质量去实现75%数量。吸引用户的往往是功能里的一两个点。

       做得少不如做的巧。

       尽可能多的放弃。