此篇文章分两部分进行总结

1. 用户研究
2. 需求奋斗史（即需求采集到确定需求的过程）
3. 项目kick off

用户研究

用户是需求之源
以用户为中心的思想
需求采集，做哪些？做多少？怎么做？

需求采集过程
与用户接触的过程

需求采集方法
数据分析、调查问卷、用户访谈等

需求分析过程
对于用户说出的需求 ，PM“听用户的但不要照着做”，必须明确存在的价值
把用户需求转化为产品需求（PM存在的价值）.

a. 筛选需求
b. 确定需求基本属性
c. 分析需求的商业价值
d. 初评需求的实现难度
e. 计算出需求的性价比

需求筛选
尽可能多的放弃需求
发现一个问题，设法将其转为一个任务来解决

需求奋斗史

需求管理：需求采集 —> 需求分析—> 需求筛选

需求奋斗史缩略图

需求奋斗史思维导图

从用户中来到用户中去

需求是从用户中来的，所以我需要到用户中去了解用户需求

需求

生活中存在太多的问题，从而产生了不满意，而问题就是”理想与现实的差距“，那么人类很自然的产生了“减少甚至消除这个差距”的愿望，这就产生了需求

需求本质

问题

问题本质

理想与现实的差距

用户和客户

用户
终端用户 end user，使用产品的人
客户
customer，购买产品的人，为产品付钱的人
试图满足所有用户的需求是一个灾难，那会让产品变成一个臃肿不堪，谁都不满意的四不像
而以用户为中心，到底以哪些为中心？我们无法满足所有用户的需求，应该优先照顾哪些人？
优先满足哪些用户需要和产品的商业目标要结合起来考虑，简单 的说就是看KPI是什么
我们无须满足所有用户的需求

用户研究

用户研究的方法创建persona，即人物角色，方便新人进入团队时，迅速了解用户、理解产品、老板可利用persona迅速进入状态.

方法

1. 说和做
   

2. 定性和定量
   
   第一轮
   
   第二轮
   
   第三轮
   
   第四轮
   

需求采集

不怕发现荒谬的需求，就怕错漏合理的需求

过程

1. 明确目标
2. 选择采集方法
3. 制定采集计划
4. 执行采集
5. 资料整理
6. 进入下一步的需求分析阶段

步骤

用户研究方法的简化

说和做：”怎么说“表现了目标和观点，怎么做反应了行为，用户怎么说怎么做经常不一致
定性研究：可以找出原因、偏于了解
定量研究：可以发现现象，偏向于证实*

需求采集方法

步骤a. 定性的说 — 用户访谈
确定产品方向、做什么 听用户定性的说，通过用户访谈方式，了解用户需求，列出需求列表
一对一聊天方式；围绕特定的话题，问，答；说，听
听用户怎么说，即他们的目标和观点

用户访谈场景
新产品方向的预言工作中；
通过数据采集的第四步骤定量做的数据分析发现现象后，去探索背后的原因

常见问题和策略

1. 说和做不一致问题
   策略:
   a. 尽量在用户可以和产品发生交互的场合下进行，让用户在说的同时也做，但访谈成本> 电话访谈/邀请用户访谈；
   b. 注意区分用户说的事实和观点：如“我做了什么，步骤如何，碰到什么问题”可信度更高；“我觉得、我认为”需要带着大大的问好去听；

2. 样本少，以偏概全问题
   策略:
   a. 尽量做到随机；
   
   b. 尽量识别出各种可能引起偏差的因素，并在访谈报告标明，让读者了解；
   c. 为了用尽可能少的样本得到尽可能正确的结论，以增量的方式做访谈；
   
   

3. 用户过于强势，把我们往沟里带
   用户罗里吧嗦扯其他话题
   策略：
   牢记访谈的目的；发现话题不对，赶紧往正道上扳，多次扳不过来，可以考虑尽快结束访谈；

4. 我们过于强势，把用户往沟里带
   访谈者罗里吧嗦扯起话题
   牢记访谈目的；管好自己的嘴；

用户访谈注意点：

1. 避免一组固定的问题：
   固定的问题让被访者产生被访问的感觉；应准备好问题清单，引导作用，不用照读；
2. 关注目标，任务其次：
   
3. 避免用户成为设计师：
   ，用户的解决方法通常短浅、片面
4. 避免讨论技术：
   especially略懂技术的用户，不要与其纠缠产品实现方式
5. 鼓励讲故事
   故事是最好的帮助设计师理解用户的方法
6. 避免诱导性的问题
   典型的诱导问题：如果有xxx功能你会使用吗，一般用户给出毫无意义的肯定答复

用户大会
用户访谈如何准备、操作

步骤b. 定量的说 — 调查问卷
听用户说怎么做，确定需求优先级，先做什么
作答时间不超过10minutes；

问卷组成
开篇，简单不需要思考问题；
中间，想知道的内容，需要思考，较敏感的问题；
卷后，有关访者个人信息的题目；

调查问卷一人一份，独立作答，可消除“焦点小组”、“论坛发帖征求需求”等有群体讨论性质的方法的弊端；（用户特点：沉默与骑墙的总是大多数）

用户特点
沉默与骑墙的总是大多数；
沉默的多数，少数的不能保证其代表了目标用户的想法；
骑墙的是大多数没有明确的观点，开始表态的那几个人的观点引导了群体的观点，随机的初始值决定了结果；
调查问卷的客观性、多份问卷之间的独立性，可避免，但存在问题：如下

常见问题 + 策略

1. 样本偏差，样本与想了解的目标用户群体出现偏差
   策略：
   a. 尽可能覆盖目标群体中各类型的用户，比如性别、 年龄段、行业、收入等，要各种类型用户的用样本比例接近全体的比例，比如目标用户中用男女比例为 7:3，那􏲦我们的样本也应该保持这个比例。
   b. 把潜在的筛选条件标明，让报告的读者知道数据获取的方法与来源；

2. 样本过少问题
   样本过少，采用百分比是无意义的；
   要给出百分比答案，至少有100分答案；
   只能说“问了x个用户，y个用户选A

3. 问卷内容的细节问题
   问题表述（类似用户访谈）；如”你喜欢某个产品吗“ 改为 "你是否喜欢某个产品"
   策略：
   a. 答案的顺序，可能产生顺序偏差，位置偏差；即用户选择的答案可能与改答案的排列顺序有关；
   b. 陈述性选项，用户趋向于第一个或最后一个答案，特别是第一个；
   c. 对于一组数字，如价格，打分，趋向于选中间位置
   d. 为减少顺序偏差，课准备几种形式问卷，每种形式的问卷选项排列顺序不同；
   e. 先进行小范围试答，根据反馈修改后在大面积投放，与互联网产品的灰度发布有同样的理念（灰度发布：上线常用形式，先让少量用户看到新产品，利用他们的反馈进行修改，逐步把新产品展现所有用户眼前）

步骤c. 定性的做 — 可用性分析
怎么做？确定先做的需求是怎么做？一边做一遍找10个用户来做可行性分析

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

根本目的
用于指导产品改进

步骤过程

1. 招募测试用户。
   用户尽可能代表将来真实的用户，如产品的用户是新手，应该选择对产品不熟悉的用户

2. 准备测试任务。
   实际使用中的典型任务

3. 测试过程 ——重头戏
   用户使用产品来完成所要求的测试任务，组织者在旁边观察用户操作过程并记录发现的问题。

4. 测试结束后，
   询问用户对于产品整体的主观看法或感觉；
   询问测试中他们当时的想法；为什么作出这些操作

5. 研究和分析：可用性测试结束后，
   分析记录并产生一份产品的可用性问题列表，并对问题的严重程度进行分级，
   可根据项目进度来选择哪些优先处理。

使用场景
产品改版

常见问题 + 策略

1. 可用性测试做太晚（往~产品将要上线时）,发现问题也于事无补。
   

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

3. 明确是测试产品，而不是测试用户
   告诉用户测试目的是发现软件产品中的问题，而不是要测试用户是否有能力来很好的使用软件。
   “试用一下新产品，提点意见”说明这点有助于减轻用户的压力，使得他们像真实环境下使用软件，而不是让用户听到“可用性测试”字眼。}$

4. 测试过程中，组织者该做的和不该做的。
   a. 告知用户大概持续的时间，要做哪些事，让用户心中有数，愉快的完成任务。
   b. 让用户在测试过程使用，即使用产品同时说出自己的思考过程，如c. 为了完成某个任务，
   d. 测试过程避免任何的引导和暗示，只是观察和记录，引导会使得原本可以发现的问题无法暴露

5. 结束后，尽快总结 并发给用户，感觉到是一件有意义的事情。
   表示感谢的同时。建立长期和谐的“用户参与设计”的氛围
   这份总结用于指导产品的改进，——

步骤d. 定量的做 — 数据分析
通过数据分析，发现现象，来确定需求怎么做
数据分析只能发现现象和问题，并不能了解原因，分析完后通常伴随一些用户访谈，听听用户怎么解释

场景
日志分析的商业价值

数据分析方法
Excel表格，
复杂的：统计软件、数据库软件，自写程序解决

常见问题 + 决策

1. 过于学术，沉迷于“科学研究”
   策略：
   a. 科学研究注重性价比的性，只要结果好，往~不在乎投入，相对于科研结果不是为了马上应用，而是为了证明实力；
   b. 实际生产环境更注重综合的性价比；需要的是一种

2. 数据不会主动骗人，但经常有意无意的误读数据
   策略：
   a. 学习统计学知识，提高水平
   b. 对数据保持中立的态度，不要“为了迎合一个观点而去找数据”，减少利益牵扯，比如为了证明老板的判断或保持自己之前拍脑袋的英明形象等。

3. 平时不烧香，临时抱佛脚
   经常在做决策时才想起来数据分析，忽然发现没有数据可分析。
   策略：
   避免此情况，应该在产品设计时就把数据分析的需求加进去，如记录每个按钮的点击次数、统计每个用户的登录频率等，非功能需求。

用户访谈与调查问卷区别

即定性的说与定量的说区别

• 用户访谈提纲是开放式问题，适用于我们心里较疑惑时去寻求产品方向，适合与较少的访谈对象进行深入交流；
• 调查问卷是封闭式问题较多，类似判断题和选择题；适合大用户量的信息收集，不够深入，一般只能获取某些明确问题的答案；不适合安排问答题；
• 两者之间的联系：通过前者的开放性问题，为后者收紧具体的封闭式问题

有特点的方法

坚持“需求驱动学习”
现场调查，AB测试、日志研究、卡片分类法、自己提需求。
现场调查
和客户一起工作一段时间，深度了解需求；听用户怎么说怎么做。

AB测试
一个按钮不知放左边右边，先挑选少量用户发布这个按钮，1000人放左边，1000放右边，过一段时间分析结果，让用户参与设计

卡片分类法
a. 把各种需求写在便利贴上，让用户一起讨论并完成分类，深入了解用户怎么给产品划分模块，认为这个网站该是什么结构。
b. 产品设计人员和用户的思维不一样，导致用户理解困难
c. 让产品更加符合用户的心理模型。

自己提需求
自己使用产品，发动认识的人都来用

需求采集人人有责

产品人员驱动，去主动采集需求，直接去潜在的目标用户采集
产品部门至少应该和销售 、服务等部门有平等的地位，坚持不断的从终端用户那里直接获得需求，保证产品的可持续发展。

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

b. 理想状态：产品的所有干系人都参加“需求采集”培训，日常工作养成主动提交需求给产品人员的习惯。

c. 作为专业的需求分析人员，应该尽量降低同事们，比如销售、服务、技术人员提交需求的要求。

d. 单项需求卡片包含？重点是描述用户场景，谁在什么时间、地点产生了什么需求？

e. 至少包含“需求描述”，需求编号、来源、场景；

拿到卡片 跟提交人交流，完善内容；

需求分析

PM存在的价值：伟大的需求分析师，可以无视用户想要的东西，去探索他内心真正的渴望，再给出更好你的解决方案，或者说用户真正需要的东西;
听用户的但不要照着做;

明确我们存在的价值

用户需求 VS 产品需求
用户需求
用户自以为的需求，且经常表达为用户表的解决方案。

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

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

技术分析和需求分析
技术分析
树干 —— 树枝 —— 树叶
大问题分解成小问题，发现难点逐一攻克
需求分析
分 —— 总 —— 分
树叶 —— 树枝 —— 树干
其次：树干 —— 树枝 —— 树叶

满足需求的三种方式

从问题本质出发，寻找新路。
需求来源于理想与现实的差距，减少差距就是三种方式

1. 改变现状
   去开发某种产品，对产品进行改进等

2. 降低理想
   不忽视精神的力量；
   人们更在意的是相对而不是绝对，减少抱怨，但是一种低水平的满足需求，对产品美誉没有帮助

3. 转移需求
   引导用户去关注其他事物；人的行为是需求驱动的，想要改变人的行为，可以寻找更强烈的需求展现给他，而让他不再纠结原来的需求；
   满足用户的需求不一定要做新产品，新功能，是否有“四两拔千斤”的妙招

创造需求
产品设计的最高境界 —— 创造需求 需要天赋
如乔布斯；
需求分析过程也需要有创造需求的成分

给需求做一次DNA检测

过程

1. 需求转换-用户转为产品
2. 确定需求基本属性
3. 分析商业价值
4. 初评需求的实现难度—
5. 计算性价比

产品需求列表的属性
模块、子模块、feature、任务描述、商业价值、商业属性、商业优先级、开发量、性价比、备注

需求的基本属性
编号、提交人、提交时间、模块、名称、描述、提出者、提出时间、bug编号
a. 需求种类
新增功能、功能改进、体验提升、bu修复、内部需求等
b. 需求层次
基础、扩展（期望需求）、增值（兴奋需求）

分析需求商业价值
需求属性：重要性、紧急度、持续时间、商业价值（不考虑实现难度）

初评需求的实现难度
绝对不能因为某个需求的商业价值很大而马上去做，也不能因为另一个需求的商业价值不大而不做。

性价比
性价比 = 商业价值 / 实现难度（简化为开发量） = 商业价值/ 开发量
绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度很大就不做

需求筛选

少做就是多做
需求PK

需求筛选

过程

1. 需求打包
2. 产品会议
3. 商业需求文档（描述打包的需求，用于资源争夺）

需求打包
做项目，终极目标是，多快好省，即范围广、时间短、品质高、资源省。
需求打包最好打包类似的功能点
是否类似取决于需求的基本属性（需求分析中做的事情，需求的基本属性）

需求依赖，功能相互之间有依赖关系
功能与人力资源的依赖关系也经常存在，如特定功能依赖于某个特定的人员做。

需求的粒度大小
尽量细分
需求列表出现的任意一行，工作量最好不超过不超过5人天

产品会议
对资源的争抢

商业需求文档
BRD
参与资源争夺的武器

怎么写BRD
a. 项目背景
我们在哪里，为什么要做这个项目，解决什么问题，列出数据说明项目的必要性

b. 商业价值— 重点1
我们去哪里，有什么价值，提出商业目标

c. 功能需求描述
我们怎么去，通过什么事情达到目标，把打包好的需求描述一下，可用功能列表的形式表达，画出业务逻辑图

d. 非功能需求描述
重要的非功能需求

e. 资源评估 — 重点2
成本
了解达到目标需要多大的花费后才能作出决策

f. 风险和对策
潜在风险
是否存在与公司将来的战略冲突

少做就是多做
情愿把一般的功能尽可能完美也不要把全部功能都做成半吊子。
当发现一个功能可有可无时，甚至只要是没有强烈的理由要做时，
要明确的选择：不做！

做的少不如做得巧！—— 转移需求（满足需求的三种方式中之一）
动手前先找找有没有成本低，收获大的解决方案。

尽可能多的放弃

尽可能多的采集需求，尽可能多的放弃。相互矛盾，反应我们对事物的认识过程，只有在收集过程阶段没有遗漏，才可能完整的看到事物的全貌，有了大局观，在放弃的时候才知道孰轻孰重，也更下得了手

需求的生老病死

产品的不断迭代：反复的需求分析、需求分析、需求筛选

需求的生老病死

需求简报

项目

需求采集 —> 需求分析 —> 需求筛选 —> 立项 —> 写文档（BRD、PRD等） —> 产品原型 —> 概要设计、详细设计 —> 评审 （需求评审、设计评审、测试评审）
产品原型可在产品会议前可开始，即需求筛选后的产品会议

项目缩略图

立项阶段的工作内容

立项做的事情

kick off 做的事情
WBS拆分任务

kick 0ff - WBS.png

立项后做的事情-写文档

立项-写文档.png

日常需求发布流程

项目 - 需求发布流程

bug状态流转图

bug状态流转图