《人人都是产品经理1》阅读摘要笔记1.0

前言：

只摘要本人觉得重要的部分，比较混乱。

第二章 一个需求的奋斗史

2.1 常用的采集方法：数据分析、调查问卷、用户访谈

2.2 “把用户需求转化为产品需求”

1. 确定需求的基本属性

2. 分析需求的商业价值

3. 初评需求的实现难度

计算出需求的“性价比”

2.3 需求开发：产品需求文档、用例文档

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

2.4 用户访谈：

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

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

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

4. 避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。

5. 鼓励讲故事：故事是最好的帮助设计师理解用户的方法。

6. 避免诱导性的问题：典型的诱导问题是“如果有××功能，你会使用么？” 一般来说用户会给出毫无意义的肯定答复。

2.5 记一次用户大会：

1. 明确目的

   • 会前最重要的是明确这次用户大会的目的和意义，这在争取资源的时候会更有说服 力，比如：产品二期卖点确认，辅助运营决策；三期需求收集；现有产品用户体验改进等。

2. 资源确定

   • 时间：日期、几点、时长。要考虑淘宝卖家的空闲日子和时间段。另外注意要 把整个活动各项准备的时间点掐准，留余量。

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

   • 人物

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

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

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

   • 材料：用户数据、产品介绍材料（测试环境确保当时可用，静态Demo备用）、 可用性测试（ 可用性测试（Usability Testing）是指在设计过程中被用来改善易用性的一系列方法。

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

3. 现场执行

   • 辅助工作：场地布置（轻松一点，不要像开会）；引导/拍照/服务/机动；进场 签到（给礼品）；全程主持（进度控制）；送客/收拾残局。

   • 主流程

     产品介绍：重点是卖点介绍，与用户互动，观察用户更关注哪些功能，辅助上线前的运营决策，到底主推哪些卖点； 抽取部分用户做焦点小组的讨论，收集后续的需求，产品三期开始启动； 同时抽取部分用户做可用性测试，帮助产品二期做最后的微调； 最后，合影留念。

4. 结束以后

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

   • 运营：本次活动在淘宝论坛发贴；内部邮件。

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

2.6 调查问卷

调查问卷和用户访谈的提纲是有区别的：

      用户访谈的提纲通常是开放式问题，适用于我们心里还比较疑惑的时候去寻找产品的方向，适合与较少的访谈对象进行深入的交流；而调查问卷通常封闭式问题比较多，适合大用户量的信息收集，但不够深入，一般只能获得某些明确问题的答案，调查问卷不是考试卷，不适合安排问答题。用户访谈与调查问卷之间也有联系，我们经常通过前者的开放式问题，为后者收集具体的封闭式问题。

调查问卷的常见问题：

1. 样本的偏差，即样本与想了解的目标用户群体出现偏差。

2. 样本过少的问题。

3. 问卷内容的细节问题。

2.7 可用性测试

可用性测试的常见问题：

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

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

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

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

   做测试的过程中千万不要有任何的引导与暗示，而只是观察和记录，因为任何引
   导都可能使得原本可以发现的问题无法暴露。用户行为和预想的不一样时，可以提问，
   实在进行不下去的时候，给予提示。记住，一切的错都是产品和我们的错，用户绝对
   没有错。如果真觉得用户错了，那也是你找错人了，不是这个人错了。

2.8 数据分析

数据分析的常见问题：

1. 过于学术，沉迷于“科学研究”。

2. 虽然数据不会主动骗人，但我们经常无意或有意地误读数据。

3. 平时不烧香，临时抱佛脚。

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

2.9 需求采集

单项需求卡片

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

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

需求编号（可由需求人员填写）	需求类型（可由需求人员填写）
包含“采集时刻 + 采集者”信息	功能需求、非功能需求等
来源（Who）（重要信息，方便追根溯源）
产生需求的用户：最好有该用户的联系方式等信息 用户背景资料：受教育程度、岗位经验，以及其他与本单项需求相关经验
场景（Where、When）（重要信息，用来理解需求发生的场景）
产生该需求的特定的时间、地理、环境等
描述（What）（最重要的信息）
尽量用（主语+谓语+宾语）的语法结构，不要加入主观的修饰语句
原因（Why）（需求人员要保持怀疑的心，很多时候理由是假想出来的）
为什么会有这样的需求，以及采集者的解释
验收标准（How）	需求重要性权重（How much）：
（如何确认这个需求被满足了） 1. 尽量用量化的语言 2. 无法量化的举例解释	满足后（“1：一般”到“5：非常高兴”） 未实现（“1：略感遗憾”到“5：非常懊恼”）
需求生命特征（When）	需求关联（Which&#x