用户研究：
横向，用户的说和做。怎么说表现了目标和观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。
纵向，定性与定量。定性研究可以找出原因，偏向于了解；而定量研究可以发现现象，偏向于证实。
第一轮，听用户定性地说，确定产品方向，做什么？随机抽样40个用户做访谈，据此写出需求列表。
第二轮，听用户定量地说，确定需求优先级，先做什么？投放了20万份调查问卷，确定了需求优先级的排序。
第三轮，看用户定性地做，要先做的那几个需求，应该怎么做？一边设计，一边陆续找了10个用户来验证，做可用性测试。
第四轮，看用户定量地做，根据产品的用户使用情况做数据分析，不断改进产品。
用户需求VS.产品需求用户需求：用户自以为的需求，并且经常表达为用户的解决方案。产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。
满足需求的三种方式
改变现状。是我们最常用的，去开发某种产品，但也是最笨的办法。
降低理想。不要忽视精神的力量，什么“打预防针”、“丑话说在前头”这类句子想必大家都经常听到。
转移需求。因为人类的注意力是有限的，所以引导用户去关注其他事物，他就会觉得这个差距没那么可憎了。我们也可以说，人的行为是需求驱动的，想改变人的行为，可以寻找更强烈的需求展现给他，而让他不再纠结于原来的需求。
把用户需求转化为产品需求
现在我们就要发挥出“我们存在的价值”，在这个阶段，团队经常举行头脑风暴[插图]，大家天马行空地讨论一番之后，对用户提出的需求有了比较全面的了解，对用户的内心世界有了比较统一的认识，对我们的解决方案也有了一些不成熟的想法，然后通常每个人分一块，去把它们都转化为产品需求，最后记录在一起。
确定需求的基本属性
分类：可以分为“新增功能、功能改进、体验提升、Bug修复、内部需求”等。
举几个例子，“论坛需要支持1000人同时在线”，这是一个性能需求；“系统功能升级，必须在发布2 周以前完成对客服部门的培训”，这是一个培训需求；“如果硬件压力突增，应该有报警，具体细节是……”，这是一个运维部门的维护需求；“在用户数增加10倍的情况下，硬件投入必须小于10倍”，这是一个可扩展需求；“此功能的用户操作日志需要记录”，这是一个内部数据分析的需求。
层次：把需求分成“基础、扩展（期望需求）、增值（兴奋需求）”三层，理论依据参见KANO模型[插图]。
小明：“我想到一个手机的例子，打电话、发短信是基本功能；给电话录音是扩展功能，和基本功能相关；而如果这个电话特别结实，可以当锤子砸钉子，或者当砖头防身，那就是增值功能了。”
分析需求的商业价值
一个公司做任何产品，一个产品做任何需求，最终都是要满足一定的商业目的，所以“需求的商业价值”是最关键的内容，有条件的团队最好利用群体智慧，我们通常在这个时候举行“需求讨论会”。
初评需求的实现难度
绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。
性价比 = 商业价值÷实现难度（简化为开发量）
做项目，终极目标就是：多快好省[插图]，即范围大、时间短、品质高、资源省。
但是，需求那么多，不可能每次都把所有的需求拿出来讨论，所以我们必须有所选择，这也就意味着需要标明需求的状态。需求的状态随时改变，但每个阶段都是谁来负责？所以我们还需要知道需求在各个阶段的负责人，以及其他一些需求跟踪的信息。
需求状态。通常有“待讨论”、“拒绝”、“暂缓”、“需求中”、“开发中”、“已完成”几个状态，可按照实际情况有所增减，比如管理的粒度细一点，还可以增加“测试中”。
负责PD。在需求状态变为“需求中”时指定，最可能是此需求的提交人，在需求的整个生命周期中，此人要从头到尾跟进，是这个需求的主人。
开发工程师。在需求状态变为“开发中”时指定，负责这个需求的技术实现，以及将来可能的故障解决。其他比如测试负责人，项目经理，大家可以按需要决定是否填写。
项目名称。辅助信息，在需求进入“开发中”时确定，用来筛选某个项目的需求。
发布时间。辅助信息，在需求状态变为“已发布”时填写，用来查看某段时间发布的需求。
备注。其他任何信息都可以写在这里，如：需求被拒绝的理由，需求被暂缓的理由和重启条件，其他相关文档，等等。
若有收获，就点个赞吧
0 人点赞
