1 需求管理流程
产品的需求管理有需求采集、需求分析和需求筛选几个阶段，经过这几个阶段之后才会进入立项的阶段。
需求管理流程图
2 用户研究方法
需求采集主要是从用户的角度进行需求的采集，横向看，用户有说和做，顾名思义，说，就是让用户说话，而做，就是让用户实际去做；用户的说和做，往往是不完全一致的。纵向来看，用户的研究有定量研究和定性研究，定性研究一般是用户研究较早阶段，从无到有，找出原因，偏于理解，而定量研究，一般是从有到精确，偏向深入研究和证实。
用户研究方法（图片来自网络）
3 需求采集
需求采集一般会有：明确目标、选择采集方法、制定采集计划、执行采集、资料整理等步骤，苏杰将最常用的需求采集方法归纳为“Z方法”（具体参见苏杰的“需求采集的”Z方法“），需求采集分为定性地说、定量地说、定性地做、定量地做。
需求采集“z方法”
3.1 定性地说：用户访谈
-
用户说和做不一致
在访谈过程中用户所讲和用户所做可能并不一致，原因可能是用户说的只是没有经过大脑思考的结果，实际不会做；也可能是因为用户觉得说出实际结果会会让访谈者不满意，所以编造一个访谈满意的结果；或者是因为做了坏事而不愿意承认。
一般情况下用户讲做了什么事情，然后由什么样的感想或者结论可信度会高一点，如果用户讲“我觉得”、“我认为”可信度要大打折扣。
-
样本量选择
5个访谈样本可以解决85%的问题。因此访谈样本量的选择，一般是在后续访谈中，没有发现新的需求和问题，那么就可以结束继续访谈。
-
访谈时间和话题把控
访谈过程切记千万不要去主导被访谈者，也不要用带有引导性的方式去访谈和问问题，更不要被参与访谈者的人牵着鼻子走，要时刻记住访谈的目的和方向，跑题了要及时拉回来。
焦点访谈（focus group）：定性地说的另一种方式，由一个经过训练的主持人以一种无结构的自然的形式与小组的成员交流，一般认为是一种一对多的访谈形式。
3.2 定量地说：调查问卷
-
长尾理论：“沉默的大多数”和“骑墙的大多数”
沉默的大多数：站出来的人总是很少，更多的人选择沉默，所以主动站出来的人不能代表整体；
骑墙的大多数：大多数人没有自己明确的观点，最开始的表态的人容易引导整个观点的走向。
调查问卷可以避免如焦点访谈过程中所带来的长尾理论。
-
问卷设计
问卷一般不要太长，
一般开篇放简单不需要思考的问题，
中间放自己想知道的问题，
最后放访谈者个人信息，以免个人信息放前面引起填问卷人的顾忌。
-
问卷样本选择（选择偏差）
虽然需要参与问卷的人尽可能设计方方面面，样本需要具有代表性，但是在样本总是会因为各种原因具有偏差，比如无应答偏差，愿意回答的人，可能与整体样本有所不同；选择偏差，可能参与问卷的人是因为某种利益的诱惑才参与的。所以在样本选择过程，最好不要用物质诱惑，而是鼓励。
-
问卷质量
可能参与填写问卷的人并没有认真填写，而是随机选择，从严谨的角度可以将意思相近的问题分开放置，看回答是否一致。
-
多选项和评分
有的问题深浅程度不一衡量，可以用多选或者打分的形式，比如问对食堂菜品喜欢程度，可以用0~7分代表非常不喜欢到非常喜欢。
位置偏差：指的是答案与选项位置有关系，比如价格，可能大众偏向中间的价位。解决方法可以设置不同类型的问卷来避免位置偏差。
灰度发布：互联网发布新产品的一种方式，先让少部分的用户看到和使用新产品，根据反馈进行改进，然后将产品展现给大众。
3.3 定性地做：可用性测试
可用性测试（UT，usability testing),设计过程中用来改进易用性的一系列方法。
- 可用性不等于易用性
-
测试产品，而不是测试用户
明确告诉参与可用性测试的用户，是要找出产品的漏洞和改进产品，而不是测试用户，避免用户心里有所顾忌，紧张而不能找出产品的不足。
-
千万不要进行引导
不要对用户进行引导或者暗示，否则不能有效找出产品的不足和问题。
发声思维：让用户一边做一边说，记录用户思考的过程。
3.4定量地做：数据分析
-
不要迷信数据
尽管是客观的数据，但是有的时候为曲解数据。比如一般用均值（means）来衡量中间水平，比如全班同学平均身高，但是如果是平均财富，可能土豪会将平均值大幅度拉高，这个时候均值不显得那么重要，可能需要中位数来衡量。（所以我在想，人均GDP是不是也会因此而影响）
-
未雨绸缪，防范于未然
数据分析可能存在于各个阶段，产品上线之后也会有各种数据分析，所以为了防止需要做数据分析的时候手足无措，在产品设计的时候就应当考虑数据分析，记录访问量、交易量等。
3.5单项需求卡片（6W2H）
| 需求编号（可由需求人员填写） | 需求类型（可由需求人员填写） |
|---|---|
| “采集时刻+采集者” | 功能需求、非功能需求 |
| 来源（who） | |
| 产生需求的用户:最好有该用户的联系方式等信息用户背景资料：受教育程度、岗位经验、以及其他与本单项需求相关经验 | |
| 场景（where、when） | |
| 产生该需求的特定时间、地理、环境等 | |
| 描述（what） | |
| 尽量用（主语+谓语+宾语）结构，不要加入主管修饰词 | |
| 原因（why） | |
| 为什么会有这样的需求，以及采集者的解释 | |
| 验收标准（how） | 需求重要性权重（how much） |
| （如何确认这个需求被满足了）1.尽量用量化的语言2.无法量化的举例解释 | 满足后（“1：一般”到“5：非常高兴”）未实现（“1：略感遗憾”到“5：非常懊恼”） |
| 需求生命特征（when） | 需求关联（which） |
| 1.需求的紧急度2.时间持续性 | 人：和此时需求关联的任何人2.事：和此事需求关联的用户业务与其他需求3.物：和此需求关联的用户系统、设备，以及其他产品等 |
| 参考材料 | 竞争者对比 |
| 在需求采集活动中的输入材料，只要引用一下，能找到即可 | 按照“1分：差”到“10分：好”进行评估：1.竞争者对该需求的满足方式2.用户、客户对竞争者及公司在该需求上的评价 |
单项需求卡片模板（参考苏杰《人人都是产品经理》）
4 需求分析
4.1 需求
4.1.1 用户需求与产品需求
用户需求：用户自己认为需求的请求，经常表达为用户的解决方案。
产品需求：产品经理分析找到的真是需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正的需求，再转化为产品需求的过程。
用户需求与产品需求的关系
技术分析：树干——树枝——树叶
需求分析：树叶——树枝——树干——树干——树枝——树叶
4.1.2 Y理论
Y理论（图片取自http://iamsujie.com/1000/1017/）
苏杰在博客中给我们讲述了需求分析实际上是从1->2->3的过程，将用户需求转化为产品需求再转化成产品功能，从1->2通过“why”尽心归纳，从2->3通过“how”进行逐步演绎。产品需求取决于公司和产品的定位。（详情见苏杰·需求分析的“Y理论”）
4.1.3 满足需求的三种方式
-
提高现实
最直接也是最笨的方法，比如食堂饭菜不咋地，同学们希望食堂饭菜能够好吃的需求，提高现实地方法就是请大厨，做美味。
-
降低理想
告诉同学们，其他学校的食堂比起我们学校的食堂不知道差到哪里去了，我们学校的食堂已经是食堂中的佼佼者。
-
转移需求
虽然我们食堂饭菜不好吃，但是菜量足，价格低呀。
4.1.4 创造需求
创造需求需要天赋，并且是非常伟大的天赋。电灯泡、手机、电脑，谁能离开？
4.2 需求分析流程
需求分析流程（图片取自苏杰《人人都是产品经理》）
-
第一步：需求转化
需求转化也就是将用户需求转化为产品需求。这中间需要发挥产品团队最大的价值。
- 第二步：确定基本属性
| 需求属性 | 属性说明 |
|---|---|
| 编号 | 需求的顺序号，唯一表示 |
| 提交人(*) | 需求的录入PD，负责解释需求 |
| 提交时间 | 需求的录入时间，辅助信息 |
| 模块(*) | 根据产品的模块划分(一般5±25±2)个模块 |
| 名称(*) | 用简洁的短语描述需求 |
| 描述(*) | 需求描述：无歧义、完整性、一致性、可测试性等 |
| 提出者 | 即需求的原始提出者，有疑惑时便于追溯 |
| 提出时间 | 原始需求的获得时间，辅助信息 |
| bug编号 | 将一些bug视为需求，统一管理 |
需求的基本属性(表格取自 苏杰·《人人都是产品经理》
| 需求属性 | 属性说明 |
|---|---|
| 分类 | 新增功能、功能改进、体验提升、bug修复、内部需求等 |
| 层次 | 基础、扩展（期望需求）、增值（兴奋需求）（参见KANO模型） |
需求的种类（表格取自 苏杰·《人人都是产品经理》）
- 第三步：分析商业价值
| 需求属性 | 属性说明 |
|---|---|
| 重要性 | 重要程度，辅助信息 |
| 紧急度 | 紧急程度，辅助信息 |
| 持续时间 | 持续时间，辅助信息 |
| 商业价值(*) | 行业优先级，不考虑实现难度，群体决策 |
需求的商业价值（表格取自 苏杰·《人人都是产品经理》）
- 第四步：初评实现难度
| 需求属性 | 属性说明 |
|---|---|
| 开发量(*) | 需求的开发工作量，表征实现难度，如以“人天”为单位 |
需求的种类（表格取自 苏杰·《人人都是产品经理》）
-
第五步：计算性价比
性价比=商业价值÷实现难度性价比=商业价值÷实现难度
| 需求属性 | 属性说明 |
|---|---|
| 性价比(*) | 商业价值/开发量，用于决定先做哪个 |
需求的种类（表格取自 苏杰·《人人都是产品经理》）
5 需求筛选
需求筛选
产品线划分团队：产品规划不容易被改变，线性领导，资源有保证。
职能划分团队：有利于资源共享，稳扎稳打，但单个产品速度降低。
5.1 需求打包
将可用的工作量对应到预计的工作量中。个人理解就是将工作量化和细化的过程。
5.2 BRD制作
BRD，Business Requirement Document，商业需求文档，包括项目背景、商业价值、功能需求描述、非功能需求描述、资源评估、风险和对策等内容。
对应的两个概念：
MRD, Market Requirement Document，市场需求文档
PRD，Product Requirement Document，产品需求文档。
5.3 产品会议
通过产品会议来讨论产品需求、商业价值等。
6 完整需求信息
6.1 跟踪信息
除了应当有基本的需求属性外，还需要有一些跟踪信息来记录需求的进展情况。
| 需求属性 | 属性说明 |
|---|---|
| 状态(*) | 需求生命周期：待讨论、暂缓、拒绝、需求中、开发中、已发布 |
| 负责PD(*) | 状态进入“需求中”后确定 |
| 开发工程师 | 状态进入“开发中”后确定 |
| 项目名称 | 需求的发布项目 |
| 发布时间 | 需求的发布时间 |
| 备注 | 其他任何信息，如：1.被拒绝的理由2.被暂缓的理由和重启条件3.相关文档 |
6.2 完整的需求属性
| 需求属性 | 属性说明 |
|---|---|
| 编号 | 需求的顺序号，唯一表示 |
| 提交人(*) | 需求的录入PD，负责解释需求 |
| 提交时间 | 需求的录入时间，辅助信息 |
| |模块(*) | 根据产品的模块划分(一般**5±25±2**)个模块 |
| 名称(*) | 用简洁的短语描述需求 |
| 描述(*) | 需求描述：无歧义、完整性、一致性、可测试性等 |
| 提出者 | 即需求的原始提出者，有疑惑时便于追溯 |
| 提出时间 | 原始需求的获得时间，辅助信息 |
| bug编号 | 将一些bug视为需求，统一管理 |
| 分类 | 新增功能、功能改进、体验提升、bug修复、内部需求等 |
| 层次 | 基础、扩展（期望需求）、增值（兴奋需求）（参见KANO模型） |
| 重要性 | 重要程度，辅助信息 |
| 紧急度 | 紧急程度，辅助信息 |
| 持续时间 | 持续时间，辅助信息 |
| 商业价值(*) | 行业优先级，不考虑实现难度，群体决策 |
| 开发量(*) | 需求的开发工作量，表征实现难度，如以“人天”为单位 |
| 性价比(*) | 商业价值/开发量，用于决定先做哪个 |
| 状态(*) | 需求生命周期：待讨论、暂缓、拒绝、需求中、开发中、已发布 |
| 负责PD(*) | 状态进入“需求中”后确定 |
| 开发工程师 | 状态进入“开发中”后确定 |
| 项目名称 | 需求的发布项目 |
| 发布时间 | 需求的发布时间 |
| 备注 | 其他任何信息，如：1.被拒绝的理由2.被暂缓的理由和重启条件3.相关文档 |
完整的需求属性
6.3 需求管理完整流程
- 需求周期图
需求周期
从需求采集到需求分析、讨论、打包和产品会议，一直到产品开发，可能是一个多次循环改进的过程。
- 需求管理详细图
需求管理详细图
需求采集主要有四个维度：定量和定性、说和做，用户需求采集围绕这四个维度展开。
需求分析从需求转化、到确定基本需求属性、分析商业价值、初评实现难度，以及计算性价比。需求转化是从用户需求到产品需求，基本属性来记录需求的具体内容，商业价值是衡量需求的意义锁子啊，实现难度以开发量来统计，衡量实现的工作量，性价比确定需求的优先级。
需求筛选通过将需求打包，合并相同和相近的需求，制作BRD，对项目背景、商业价值、功能需求描述、非功能需求描述、资源评估、风险和对策等内容进行分析阐述，最终通过产品会议来确定其具体的商业价值和是否进入开发状态。