《人人都是产品经理》--需求

• 产品经理的价值：听取用户需求表述（但不要照着做），经过分析，把用户需求转化为产品需求（满足用户的本质需求而不是口头上的表象），千万不能当用户的“传声筒”。
• 用户与客户的区别：用户是使用产品的人--User；客户是购买产品的人--Customer。两者可以互相交叉。例如老板买软件，老板是管理员用户。
• 需求采集方法：用户访谈、调查问卷、可用性测试、数据分析

需求采集方法.png

一、用户访谈（定性的说）：单个用户访谈、焦点小组
问题1：用户说的和做的不一致。例如用户说喜欢黄色的衣服、而买的时候缺买的灰色。
对策1：尽量让用户做一次，以验证说法；区分用户说的事实和观点，如“做了什么、步骤如何、遇到什么问题”比较可信，而“我觉得、我认为”则需要慎重，带着问号去听。
问题2：样本少，以偏概全。例如访谈对象都是男性、都是某个地区子公司的员工。
对策2：识别可能引起偏差的因素，操作时避免或报告中标明；用增量的方式访谈，例如先访谈5个用户，得出基本结论，再访谈5个用户验证结论是否有变，若有变动则反复上一过程，若没有变动则结束访谈，节省成本。
问题3：用户过于健谈，访谈话题偏题或描述过于冗长
对策3：及时扳回来，如果多次无效就结束，换下一个。
问题4：我们过于健谈，用户被说服，真实想法无法表达
对策4：牢记访谈目的和主题，管住嘴。
二、调查问卷（定量的说）：通过访谈的开放式问题和沟通为问卷采集设计封闭式问题
问题1：样本偏差，即样本与想了解的目标用户群体出现偏差。
对策1：尽量覆盖各类型用户，如年龄、性别、行业、收入等；保证各类型用户的样本比例接近全体比例，如用户中男女比例为7：3，那么样本也应该保持这个比例；标明调研约束和限制条件等筛选条件；把目标群体特征定义成一系列问题，放入问卷，以便筛选使用和调整比例偏差。
问题2：样本总量过少。
对策2：报告中只能说“5个用户中3个选择了A”，除了补充外没其他太好办法，统计意义不大。
三、可用性测试（定性的做）：让测试用户通过使用产品或原型来发现界面设计中的可用性问题，通常只需要少数几个用户，观察用户怎么做，并不时询问、记录问题。
问题1：做的太晚，即使发现问题也来不及修正了。
对策1：产品的各个阶段都可以做，从原型有了交互行为开始，各功能测试、版本上线都可以抓很少的1，2个用户尽早的做。
问题2：组织者说的过多或带有引导性，影响用户自主性和操作真实性。
对策2：少说多看，管住嘴，多提问，多记录，时候讨论。
四、数据分析（定量的做）：用户的操作日志、后台管理系统日志、访问信息。
问题1：统计使用不得当而误读数据。
对策1：统计学知识补充，常回顾、检查。
问题2：平时不下功夫，临时抱佛脚。
对策2：数据采集要从产品设计时就考虑进去，方式、途径、内容、频次，以及重要的检测点和检测对象设定。

• 一手需求VS二手需求
  一手需求类似“生孩子”：在产品诞生前，没有用户使用，由产品人员驱动，发挥空间大，是从潜在用户那里“拉”来的需求。
  二手需求类似“养孩子”：已经运行的产品，用户已经在使用，由用户驱动，按需改进，是已有客户“推”给产品的需求。
• 需求采集的补充方法
  现场调查：融入业务一线，需要一定时间。
  AB测试：基于大用户量使用。
  日记研究：互联网新兴个人应用，往往是同行意见。
  卡片分类法：把需求单独写在便利贴上，让用户去分类，了解用户是怎么给产品划分模块的。
  自己提需求：自己用自己的产品。
• 用户需求VS产品需求
  用户需求：用户自以为的需求，经常表达为用户的解决方案。
  产品需求：经过产品人员的分析，找到的真实用户需求，并且表达为产品的解决方案。
  示例：用户说我想加其他人为好友，其他仔细询问过后才知道他想得到其他人的文章更新提示，因此产品中增加“订阅用户新文章功能”就够了。
• 需求分析过程就是把用户零散的真实需求，分类抽象提炼为最终用户需求，转换为对应产品功能，指导开发。
• 满足需求的三种方式
  改变现状：开发或更新产品功能，最笨。
  降低理想；“打预防针”、“丑话说在前头”等。
  转移需求：引导用户关注更重要的功能。
• 需求的检查过程
  相应工具见《用户需求清单》《产品需求清单》《需求开发清单》

需求的检查过程

• 需求的生老病死

需求生老病死

• 一个需求的奋斗史

一个需求的奋斗史

Tips

• 以用户为设计指导、以老板为实际出发，协助老板更好的实现用户价值。
• 要根据重要程度将用户进行分类排序，不同程度的满足，毕竟资源和约束限制是必定要考量的。
• 用户需求优先级应该结合商业目标作出评价和甄选。
• 产品需求规划的各阶段目标和用户主体不同，因此需要动态调整用户需求优先级。
• 比用户说的和做的更重要的是背后的原因，多向用户问为什么，刨根问底。
• 避免让用户设计产品功能或与用户讨论技术实现细节，抓住访谈主题和目的。
• 鼓励用户以故事的方式讲出来，是最好理解用户的方式。
• 无论线上还是线下问卷，最好不要超过10分钟，自己要先测试答一下。
• 问卷开篇问题应简单、少思考；中篇应重点、需思考、较敏感；末篇应个人信息。
• 样本总量少时，使用百分比分析是没有意义的，结果不稳定；要使用百分比的话，最好约有100份有效的调研结果。
• 问卷表述应无引导性，与用户访谈类似。
• 对于重要的问卷，需采用先小范围试答，根据反馈修改后，再大面积投放的方式，类似产品的灰度发布。
• 招募测试用户时应尽可能贴近真实用户群体。
• 可用性测试前组织者应给用户准备好一系列典型、重要、频繁操作的业务。
• 改版上线前的可用性测试和AB测试很重要，需要给自己留退路。
• 在一个团队里，应统一一种记录用户需求的形式，如mindmap。
• 用户需求和产品需求可能出现多对多情况，因此需要在《用户需求清单》给用户需求编号，在《产品需求清单》中标注对应用户需求；产品需求也应在《产品需求清单》中编号，在《需求开发清单》中标注对应的产品需求。
• 做项目的终极目标：多快好省。范围大、时间短、品质高、资源省。
  敏捷迭代、一般2-4周，把类似的功能点、业务逻辑上关系密切的放在一次迭代中。
• 功能互相之间依赖。那些只能先做的功能，应该在产品需求列表里注明；功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能由团队里的特定成员来做。
• 需求的粒度大小。商业价值很高的功能，如果细分的话，会发现其中也有价值相对低的部分，所以需求的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内。经验是，在需求列表里出现的任意一行，工作量最好不要超过5人天。
• 情愿把一半的功能尽可能完美也不要把全部功能做成半吊子。