【读书笔记】一个需求的奋斗史-如何发现问题

一、需求来源

以用户为中心的思想，但也不要试图满足所有用户

1.1用户是需求之源

• 人类为什么有需求

生活中有很多不满意（现实与理想的差距）
需求：去减少或者消除差距

• 用户VS客户：

用户是User，有时也叫做终端用户，End User，是使用产品的人；
客户是Customer，是购买产品的人、为产品付钱的人

• 以用户为中心的思想&不要试图满足所有用户

• 需求的本质就是“问题”，问题的本质就是“理想与现实的差距”。作为产品经理，我们每天都在设法满足用户的需求，其实就是在解决各种各样的问题。
• 优先满足哪些用户需要和产品的商业目标要结合起来考虑，简单说就是看KPI是什么，值得注意的是，不要把KPI狭义地理解成一些数字，可以把它想象成一种综合的指标，也可以包含客户的满意、员工的开心等。

1.2你真的了解用户吗

• 体会真实的用户：空想是无用的

• 试着描述用户：Persona

• 用户研究

横向，用户的说和做：怎么说表现了目标和观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。
纵向，定性与定量：定性研究可以找出原因，偏向于了解；而定量研究可以发现现象，偏向于证实。

具体来说
第一轮，听用户定性地说，确定产品方向，做什么？随机抽样40个用户做访谈，据此写出需求列表。
第二轮，听用户定量地说，确定需求优先级，先做什么？投放了20万份调查问卷，确定了需求优先级的排序。
第三轮，看用户定性地做，要先做的那几个需求，应该怎么做？一边设计，一边陆续找了10个用户来验证，做可用性测试。
第四轮，看用户定量地做，根据产品的用户使用情况做数据分析，不断改进产品。

二、需求采集

• 需求采集过程：

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

2.1 用户访谈

• 用户访谈常见问题&策略

1. 说和做不一致
   a. 一边交互一边访谈
   b. 区分用户说的事实or观点
2. 样本少，以偏概全
   a. 随机
   b. 识别偏差因素&标注在报告里
   c. 增量式访谈
3. 用户过于强势：要把控访谈方向&进度
   4.我们过于强势：牢记访谈目的&管好自己的嘴

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

2.2 调查问卷

• 调查问卷常见问题&策略
  1.样本偏差
  a. 识别偏差因素&标注在报告里
  b. 目标群体特征定义成问题，回收时再筛选
  2.样本过少：增加样本
  3.内容细节问题
  a. 无引导性
  b. 准备答案顺序不同的问卷
  c. 小范围试答，再大面积投放

2.3 可用性测试

• 流程
  1.招募测试用户：代表将来真实的用户
  2.准备测试任务：实际使用中的典型任务
  3.测试过程：用户通过使用产品来完成所要求的任务，同时组织者在一旁观察用户操作的全过程，并把发现的问题记录下来。
  4.测试结束后：组织者可以询问用户对于产品整体的主观看法或感觉。另外，如果用户在测试的过程中没有完全把思考的过程说出来，此时也可以询问他们当时的想法，询问他们为什么做出那些操作。
• 可用性测试常见问题&策略
  1.如果可用性测试做得太晚（往往在产品将要上线的时候）：什么时候都能做
  2.总觉得可用性测试很专业，所以干脆不做。（杜绝）
  3.明确是测试产品，而不是测试用户。
  4.测试过程中，组织者该做的和不该做的。
  该做的：持续时间；要做什么；观察&记录；小礼物
  不该做的：引导&暗示

2.4 数据分析

• 数据分析常见问题&策略

1. 过于学术，沉迷于“科学研究”。
   一切的一切需要的只是一种感觉，一种对数据的敏感，对商业的敏感。
2. 虽然数据不会主动骗人，但我们经常无意或有意地误读数据。
   a. 无意地误读数据，这个问题的对策，是学习统计学的知识，努力提高自己的水平。
   b. 主动地误读数据，一个简单的对策就是对数据保持中立的态度，尽量不要“为了迎合一个观点而去找数据”，减少利益牵扯。
3. 平时不烧香，临时抱佛脚。
   在产品设计的时候就把数据分析的需求加进去

2.5 需求采集方法

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

三、需求评审

3.1明确我们的价值

用户跟福特要一匹更快的马，福特却给了用户一辆车。这就是我们存在的价值。

• 用户需求VS产品需求

用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。【注：“Y理论”】

需求分析的Y
完整的需求分析是一个“分-总-分”的过程。一方面不能漏掉提炼用户需求的这个过程，目的是透过现象看本质【注：“心智模型学习”】，另一方面也不能停在本质上，试想如果做到“树干”就结束，后端的执行人员可能还是不知道要做什么东西，所以我们还要继续把树干再重新分解成树枝、树叶。

小秦出现了，他说要吃牛肉火锅（用户需求），160，他碰到了小张。
“真的想吃？”
“想吃！”
“为什么？”
“我饿了……”（找到了本质！）
“哦，这里是两个馒头（产品需求），请你吃，才1块钱。”

“……”
小秦无比不爽，但没办法，真的饿，还是吃了。
小张是这样分析的，想吃牛肉火锅，这个用户需求无非两个原因——饿了或者馋了。如果他真的是馋了，那就吃吧，不过如果是饿了，那我完全可以用一个低成本的解决方案——馒头。虽然小秦眉头紧锁，但现在经济不景气，毕竟节省了98.75%的成本啊！

• 满足需求的三种方式

1. 提高现实：去开发
2. 降低理想：不要忽略嘴遁的力量
3. 转移需求：寻找更强烈的需求

• 创造需求

我们千万不要——没有乔布斯的命，却有乔布斯的“病”！

3.2 给需求来次DNA检测

检测流程

• 用户需求—>产品需求
• 确定需求的基本属性：编号；提交人；提交时间；模块；名称；描述；提出者；BUG编号；...
• 需求分类：性能需求；维护需求；运营需求；功能需求；...
• 需求层次：基础；期望需求；兴奋需求；【注：“KANO模型”】
• 需求的商业价值：重要性；紧急度；持续时间；【注：“如何对一个需求做价值判断”】
• 需求实现难度：开发量；

• 性价比=商业价值：实现难度

  
  
  一个需求的DNA

四、需求筛选

4.1需求PK

做项目，终极目标就是：多快好省，即范围大、时间短、品质高、资源省。互联网、软件项目，比较推崇敏捷方法，所以有比较固定的项目时间，专业点叫“迭代周期”

1. 需求打包：业务逻辑图
2. 需求依赖，功能之间的相互依赖
3. 需求粒度大小问题

• 产品会议

商业需求文档BRD：项目背景；商业价值；功能需求描述；非功能需求描述；资源评估；风险和对策；

4.2做精不做多

情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。

• 做得少不如做的巧
• 问题基本解决
• 尽可能的多放弃

五、与需求同行

产品反复地经历着需求采集、需求分析、需求筛选的过程，不断进化。

5.1 需求的生老病死

5.2 需求的管理

• 统计每个“提交人”的需求数量
• 统计“提交时间”、“发布时间”等信息
• 统计每个“模块”的需求数量
• 统计每个“分类”的需求数量

5.3 永远保持对产品的热爱——和需求一起奋斗

一个需求的奋斗史