之前讲过需求采集的事儿，需求采集了很多，但从哪里着手？用户帮我们想好了怎么做，照用户说的做吗？

关于这一点，《人人都是产品经理》的作者苏杰，用了这样一个title：听用户说但不要照着做。

1、明确我们的价值

对于采集的需求，首先要明确的知道，一个是用户需求，一个是产品需求，这中间的转化过程，就是这篇blog的主题——需求分析。

用户需求 VS 产品需求

用户需求：从用户采集到的、用户自以为的需求，并且经常表达为用户解决方案；

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

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

关于需求分析，可以先看看下面的一幅图：

这个过程可以形象化为“Y”，“需求分析”的过程就是经历图中的“1 –> 2 — >3”，把“用户需求”转化为“产品功能”。

“Y”的越上面越是解决方案，越下面越是背后的目的。“1-用户需求”，大多表现为用户的解决方案，往往是不好的，但好的“3-产品功能”一定是从用户需求转化而来，而不是凭空而来。

so，“听不听用户”都是一个意思，更准确的说是“听用户的，但不要照着做”。同时，也不要误解“创造需求”，你创造的只能是满足用户需求解决方案——产品功能，而不是用户需求。

1–>2，通过问“Why”，逐步归纳，2–>3，通过问“How”，逐步演绎。过程中都要用到各种辅助信息，比如数据、竞品、行业等。

把“2-产品需求”追溯到“4-马斯洛需求”的过程是可选的，画为虚线，只是为了这个理论的完备，如果感兴趣，每个产品需求总能挖到马斯洛的层面。

“2-产品需求”的点如何选择，我们到底应该挖到那个层面上，作为产品需求，取决于公司和产品的定位。

PS：关于需求分析，关于“Y理论”，苏杰还有一篇更详细的“Y理论”，跳转链接:http://iamsujie.com/1000/1017/

需求分析和技术分析的区别：

技术分析：“树干————树枝————树叶”，即将大问题拆分为小问题，然后发现难点，逐一攻克。

需求分析：首先“树叶————树枝————树干”，然后“树干————树枝————树叶”的分析过程，即“分————总——-分”过程。

核心思想：即不能漏掉提炼用户需求的这个过程，另一方面也不能只停留在本质上。

满足需求的三种方式：

之前讲过，需求来源于理想与现实的差距，减小这种差距，就有如下三种方式。

①提高现实

即我们最常见也最常用的办法：开发某种产品，但也是最笨的办法；

②降低理想

还记得以前那个著名的“暗室滴水试验”吗？永远不要忽视心理暗示的力量，“打预防针”、“丑话说在前头”听得不要太多；

③转移需求

引导用户去关注其他事物，或者这么说：人的行为都是需求驱动，想改变，需求更强烈的需求给用户，而不是纠结于原来的需求。

2、给需求做一次“DNA检测”

整个检测过程可以用如下的这幅示意图来表示：

如上图所示，我们先把用户需求转化为产品需求，然后一步步确定每个产品需求的基本属性、商业价值、实现难度、性价比等。

其中，基本属性，可以结合Google的测试分析法：特质+组件，来进一步思考；链接：http://www.cnblogs.com/imyalost/p/6593817.html

①把用户需求转化为产品需求

经过之前的需求采集等过程，现在我们有很多需求，接下来就是整理需求，建议一个项目组或团队里，采用统一的记录方式，比如Word、excel等。

接下来，“明确我们的价值”。建议团队成员一起开展一次“头脑风暴”，对需求有个全面的了解，然后每个人分一块，将其转化为产品需求，最后记录在一起。

我们要明确一点：用户需求和产品需求是多对多的关系，可能用多个功能来满足一个用户需求，也可能用一个功能满足多个用户需求，甚至多个产品需求满足多个用户需求，并没有一一对应的关系。

当然，一般而言我们采集整理后的产品需求很多，所以在需求转化中，需要“忍痛”做一轮筛选，把明显不靠谱的用户需求剔除，当然，其中的尺度自己把握。

②确定需求的基本属性

当然，产品需求需要一直维护，可以指定一个人维护，或者共享模式，大家一起维护。需求总有一些“基本属性”，可以见下图：

编号：作为需求的唯一标识，方便指明需求，快速查找

提交人：必填，提交人是PD，有充分的义务理解原始的用户需求

提交时间：辅助信息，记录提交人何时提交该需求

模块：一般而言，根据人类记忆特点，产品由5±2个模块比较合理，如果超过，就要考虑增加一个基本属性叫“二级模块

名称：用简洁的短语描述需求，要给用户提供什么样的功能，比如：黑名单

描述：用来具体的描述名称中的功能是什么意思，描述只需要说明此功能做什么，无须解释怎么做；注意语言的无歧义性、完整性、一致性和可测试性等

提出者：用户需求提出者，有疑惑时便于进一步追溯

提出时间：原始需求提出时间，区别于提交时间，这是个辅助信息

BUG编号：可选，一般来说，产品的某些BUG也可以视为需求，当然，也可以用其它方式管理BUG

③需求种类

说到需求种类，可以看看下面这个表格所示：

分类：除了上面的表格内容之外，还包括很多非功能性需求，比如性能、可培训、可维护、可扩展......有很多需求更是为了公司其他业务部门同事做的。

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

其实，对需求的种类划分没这么绝对，取决于很多因素，比如商业目的变了，或者功能类型变更，都会有影响。

《人人都是产品经理》的作者苏杰有这样的解释：

雪中送炭：指产品的基本功能，对用户很重要，产品缺了这个功能，就无法操作使用；

锦上添花：非必须的功能，用户有时会用到，可以更便于用户使用；

④、分析需求的商业价值

一个公司做任何产品，一个产品做任何需求，最终都是要满足一定的商业目的，无论是直接还是间接产生的效益。

所以，需求的商业价值是最关键的内容，值得我们用不同的指标来判断衡量，如下面的表格所示。

重要性：可以参考时间管理里面“重要与紧急”的概念（推荐一本书：《高效能成功人士的七个习惯》）。

紧急度：从时间维度上判断这个需求是否迫切，以及做或不做对产品的影响。

持续时间：一个产品是有生命的，需求也是，有的很长，有的很短（比如“双11”）。

商业价值：或者称为商业优先级，是对上述几种商业价值指标的综合评判，这点是整个需求列表中最重要的一部分。

⑤需求的实现难度

这一点，特别是对于开发童鞋来说，就是工作量化，可以从以下几点来说：

工作量：即人力成本、额外的硬件成本、其他资源的消耗等。

开发量：需求实现难易程度，开发的时间成本（一般来说，大多的公司开发人员都比较忙。。。）等。

PS：当然，还有运维童鞋的部署维护资源投入，测试童鞋的测试所需时间、人力成本等等。

⑥性价比

性价比=商业价值÷实现难度

决不能因为某个需求实现难度很小就马上去做，也不能因为另一个需求实现难度大而不做。

说到这里，想起之前发生在我建的技术交流群的一件事：

事情是这样的：有位在斗鱼性能测试组的大神，某天他提了一个问题，其实用纠结这个词来形容更好，问题就是：斗鱼有10%的用户用的WindowsXP系统，而且浏览器

是IE8及以下，这样就导致了他们的兼容和性能问题比较明显，但是这10%的用户为斗鱼提供了20%的收益，所以，这个需求，必须实现，但难度又很大。。。。。。

上面这件事，从商业价值考虑，是必须要做的，但实现难度较大，开发量可能比较大，所以又回到了性价比这个问题。

所以，关于性价比这个话题，还要综合多方因素来考虑。

product（1.3）需求分析