需求分析

以前讲过需求采集的事儿，需求采集了不少，但从哪里着手？用户帮咱们想好了怎么作，照用户说的作吗？

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

 

一、明确咱们的价值

对于采集的需求，首先要明确的知道，一个是用户需求，一个是产品需求，这中间的转化过程，就是这篇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/

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

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

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

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

知足需求的三种方式：

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

①提升现实

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

②下降理想

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

③转移需求

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

 

二、给需求作一次“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%的收益，因此，这个需求，必须实现，但难度又很大。。。。。。

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

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