产品2-需求

人人都是产品经理

需求

1. 用户是需求之源，常用需求采集方式：数据分析、调查问卷、用户访谈，可用性测试等
2. 听用户的但不要照着做，明确产品经理的价值，把用户需求转化为产品需求，即需求分析，确定需求的基本属性，分析商业价值，评估实现难度，从而计算出需求的性价比
3. 资源有限，进行需求筛选，有时候只能做高性价比的需求
4. 需求管理，相关需求文档，用例文档
5. 发现一个问题，设法将其转化为一个任务来解决

需求采集人人有责，尽可能多地采集

用户访谈常见问题

1. 用户说的问题可能跟实际有偏差
2. 样本少，以偏盖全的问题，尽量随机
3. 用户过于强势，访谈被带偏
4. 我们过于强势，把用户带偏

牢记访谈目的，围绕访谈目的聊，避免诱导性问题

用户大会

邀请用户到某一集中地点开发，耗费资源较多，要充分利用

1. 明确目的
2. 资源确定， 时间，地点
3. 现场执行
4. 结束以后

调查问卷

1. 样本要具有代表性
2. 样本较少时，百分比分析没有意义
3. 问卷内容细节，不要有引导性，总要问卷应该先小范围试答，然后根据反馈修改后再大面积投放

可用性测试

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

对于改版升级，要把“暴力革命”变成温柔和谐的“和平演变”

数据分析

数据分析时，根据不同的目的，数据来源多种多样，常见的有用户使用产品的日 志、客户管理系统里的信息、网页访问情况的统计信息等

需求采集方法

1. 现场调查
2. AB测试，基于大用户量比较合适
3. 日记研究，互联网新兴的个人应用比较适合，很多业内朋友会写一些对于新产品的使用体会
4. 卡片分类法，把产品的各种需求写在便利贴上，让用户一起讨论并完成分类
5. 用户自己提需求，每个靠谱的产品都有一群粉丝用户，他们会主动提需求，要提供相关反馈渠道

用户需求VS产品需求

用户需求：用户自以为的需求

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

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

销售人员常说：用户是为想要的东西买单，而不是需要的

满足需求的三种方式

需求来源于理想和现实的差距，那么减少这个差距就有3种方式

1. 改变现状
2. 降低理想
3. 转移需求

创造需求，提供更优质的产品

需求的种类

需求属性	属性说明
分类	新增功能、功能改进、体验提升、Bug修复、内部需求
层次	基础、扩展（期望需求）、增值（兴奋需求）

其实产品需求远非我们直接可以想到的功能需求，还包括了很多非功能需求，比 如：性能、可培训、可维护、可扩展……有很多需求不是为终端用户做的，而是为销 售、服务、测试团队的同学做的

层次：把需求分成“基础、扩展（期望需求）、增值（兴奋需求）”三层，理论 依据参见KANO模型

KANO 模型以东京理工大学教授狩野纪昭（Noriaki Kano）的名字命名，是一种对顾客需求或者说对绩效指标的 分类，通常在满意度评价工作前期作为辅助研究模型，KANO 模型的目的是通过对顾客的不同需求进行区分处 理，帮助企业找出提高企业顾客满意度的切入点。

需求的商业价值

任何一个需求都要满足一定的商业目的，商业价值极其重要，可用重要性、紧急度、持续时间3个指标来衡量。

重要性：可以参考时间管理里“重要与紧急”的概念。这里的重要度又可细分为： 满足后“一般”到“非常高兴”；未实现“略感遗憾”到“非常懊恼”，更多可以学 习 KANO 模型加深理解。

紧急度：在时间维度上判断这个需求是否迫切，紧急不重要的需求通常表现为解
决了短期的问题，如果熬过去没做，对长期影响不大；或者解决了局部的问题，如果 不做对于大多数用户没有影响。比如某个用户是大老板的朋友，通过大老板“天外飞 仙”地提过来一个需求，就很可能是一个超级紧急的需求，但重要性未必很高。

持续时间：需求是有生命的，有的长寿有的短寿，比如迎合过年过节的运营活动 需求，一般就比较短寿。试想 8 月我们录入了一个庆国庆的主题运营活动，如果到了 9 月底还没资源做，那一年内也就不用再考虑这个需求了。

初评需求的实现难度

大部分情况下需要考虑人力成本，即工作量，又时会考虑资源的消耗，如额外的硬件成本。

工作量瓶颈多表现为 开发量，需要技术经理评估。

需求的性价比

性价比 = 商业价值÷实现难度（简化为开发量

需求筛选

小团队多采用按产品线划分，产品经理按自己想法做
大团队可以按职能线划分，对多个产品间的资源共享有利，但是效率不高，激励产品经理

鲶鱼效应即采取一种手段或措施，刺激一些企业活跃起来投入到市场中积极参与竞争，从而激活市场中的同行业 企业。其实质是一种负向激励，是激活员工队伍之奥秘。

准备出发-需求打包

1. 需求打包最好打包类似的功能点，可通过业务逻辑图的方式可视化展示

2. 需求依赖，功能相互之间有依赖关系，组建团队的时候要重点考虑
3. 需求的粒度大小问题，需求的颗粒度要尽量细

商业需求文档

我们刚刚把需求打好包，接下来就要描述一下这个包了，这就是商业需求文档， Business Requirement Document，简称 BRD，它也是我们参加资源争夺战的武器。

BRD怎么写？

1. 项目背景:我们在哪里，为什么做，解决什么问题
2. 商业价值：我们去哪里？最关键的重点，项目完成后有什么价值，可预测相关数字的变化，提出这个项目的商业目标
3. 功能需求描述：我们怎么去，通过哪些事情来达到目标，最好能画出业务逻辑关系
4. 非功能需求描述：如运维、分析用需求
5. 资源评估：项目成本
6. 风险和对策：潜在的风险

ps ：少做就是多做，做得少不如做的巧，性价比，产出价值>投入是根本