<人人都是产品经理> - 需求管理

需求管理

一个需求的奋斗史

需求采集人人有责

• 一手需求
  主动从用户那里拉需求

一手需求采集方法

1、 定性地说：用户访谈

常见问题与对策——

第一，“说”和“做”不一致的问题
尽量在用户可以和产品产生交互的场合下进行，让用户在“说”的同时也在“做”，且区分用户说的事实与观点。

第二，样本少，以偏概全的问题
尽量识别出各种可能引起偏差的因素，并在访谈的报告里标明，让读者了解。且可参考以增量的方式做访谈，通过加大样品量验证先前得出的基本结论。

第三，用户过于强势，把我们往沟里带
时刻牢记访谈的目的，不要在一个不合适的对象上花费太多时间。

第四，我们过于强势，把用户往沟里带
时刻牢记访谈的目的，并且管好自己的嘴。

用户访谈的注意点——

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

2、定量地说：调查问卷

常见问题与对策——

第一，样本的偏差，即样本与想了解的目标用户群体出现偏差
尽可能覆盖目标群体中各种类型的用户；要保证各种类型用户的样本比例接近全体的比例。在报告中把潜在的筛选条件表明，让读者知道数据获得的方法和来源；也可以把目标群体的特征定义成一系列问题。

第二，样本过少的问题
样本量过少时采用百分比分析没意义。要给出百分比答案，至少得约有100份的答案。

第三，问卷内容的细节问题
问题表述应无引导性；答案的顺序节能产生“顺序偏差”或“位置偏差”。可以先进行小范围的试答，根据反馈修改后再大面积投放。

3、定性地做：可用性测试
招募近可能地代表将来真实用户的测试者，准备一些实际使用中的典型任务，用户通过使用产品来完成所要求的任务，同时组织者在一旁观察用户操作的全过程，并把发现的问题记录下来。结束后，可以询问用户对于产品整体的主观看法或感觉。最后，分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得我们可以根据项目进度来选择哪些优先处理。

4、定量地做：数据分析

数据来源常常是用户使用产品的日志、客户管理系统里的信息、网页访问情况的统计信息等。通过EXCEL、统计软件或数据库软件等进行数据分析。可以在产品设计的时候把数据分析的需求加进去，比如记录每个按钮的点击次数、统计每个用户的登录频率等。对产品的可持续发展非常必要。

数据分析转化为商业价值的整体思路——

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

• 二手需求
  老板、销售、服务等人员推过来的需求

工具——单项需求卡片

需求卡片

• 其他采集方法
  • 现场调查：持续时间长，受众面小
  • AB测试：基于大用户量比较合适
  • 日记研究：日记的作者往往是同行，而不是主流用户
  • 卡片分类法：深入了解用户是怎么给产品划分模块的
  • 自己提需求：对象是粉丝用户

需求分析

需求来源于理想与现实的差距，减小差距的3种方式是：

• 改变现状
  方法最常用，也最笨
• 降低理想
• 转移需求
  人的行为是需求驱动的，想改变人的行 为，可以寻找更强烈的需求展现给他，而让他不再纠结于原来的需求

改变现状

改变现状——需求分析过程

需求转化即将用户需求转化为产品需求。

伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西。

将产品需求按上述步骤进行分析后，整理出 功能列表，并按照性价比从大到小依次排序：

功能列表-示例

需求筛选

战场：产品会议

筛选过程

需求打包
列表里有那么多需求，先做哪些需求

终极目标：多、快、好、省，即范围大、时间短、品质高、资源省。

我们经常在上述4个要求中求平衡。能变的常常只能是量——项目范围。

依据 功能列表，以可用工作量（“人天”为单位）为基准，从上往下依次纳入项目，能做多少，一目了然。

需要注意的地方——

• “需求打包”最好打包类似的功能点（通过业务逻辑图的方式可视化，能更直观地给别人讲解）
• 需求依赖，功能互相之间有依赖关系
• 需求的力度大小问题
  需求列表里出现的任意一行，工作量最好不要超过“5人天”

商业需求文档

包含哪些内容——

• 项目背景
• 商业价值*
• 功能需求描述
• 非功能需求描述
• 资源评估*
• 风险和对策