什么是需求分析

1.需求分析的目的

　　听到过一个说法，说需求分析与技术分析的最大的不同是思路的本质差异，技术分析是“树干——树枝——树叶”的任务分解过程，技术人员很适应并乐于用这种方式思考，可以把大问题分解成小问题，发现难点逐一攻克。很多做需求的人都是开发出身的，所以开始往往会用这种思路做需求，听到客户提到的功能点，直接想怎么做系统设计了，有时候需求分析甚至已经越俎代庖到“详细设计”的职责了。而真实情况是，需求分析是“树叶——树枝——树干”的分析过程，一定不能漏掉提炼用户需求的这个过程。

　　但是把需求分析说成是“树叶——树枝——树干”的描述并不完整，它只是前半部分，提炼用户需求的部分。其实完整的“需求分析”是一个先归纳后分析的过程，试想如果做到“树干”就结束，后端的开发人员还是不知道要做什么东西，所以我们还要继续把树干再次重新分解成树枝、树叶。

　　需求分析的目的是把从客户那里收集到的“用户需求（更接近Want，有时候甚至是解决方案，但我们不能不假思考的照做）”做归纳，然后得到一个总体概念（用户的Need，真正的欲望所在）后再分析、分解为“产品需求（给出我们的解决方案）”。

　　举个例子结束：小明说要吃肥牛火锅（18元），我们分析认为他是饿了，不是馋了或者真的想吃牛肉，最后给出我们的方案，扔给他2个馒头（0.5元*2），结果他虽然眉头一皱，但考虑到性价比（省了94.4%的成本啊！他省的多我们的利润空间也会大些），还是很愉快的吃了……

2.需求到底怎么定

　　产品团队的一项日常工作就是采集产品干系人，即“广义用户”，提过来的各种需求，并整理转化为产品需求，即“需求转化”，通常转化之前我们用mindmap较自由的表达，转化之后就成了excel里的功能列表。采集到这个需求的PD，自己可以先“确定属性”，即这个需求是属于产品的哪个模块？是基本、扩展、增值功能？是功能、性能、用户体验方面的？等等，属性的维度大家可以按照产品的不同自由定义，原则是为了便于需求的管理。

　　这样我们得到的feature list，就有必要每隔一段时间、或是新需求积累到一定数量、或是由特别事件触发，拿出来大家一起过一遍，这是最关键的，即“确定商业价值（产品内PK）”。我们的经验，商业价值由单个PD确定风险很大，所以这个步骤是PD团队集体讨论，再叫上有必要的干系人，比如销售、服务。对于商业价值可以从多个维度描述，并加权平均得到综合的商业价值，但绝大多数情况下，我们发现只用一个值的高中低，或者5、4、3、2、1分来衡量就足够了。具体讨论的时候，大家充分表达意见，最终往往是会场上级别最高的人综合以后说一个数字，这是现实，也是一种高效的办法，我想过投票、群体打分的方式，可是实施起来成本太高。

　　注意一点，讨论商业价值的会议上，会把所有状态为“待讨论”的功能点都过一遍，散会的时候，它们的状态一定要变化，或是进入“需求中”、或是被“拒绝”、或是“暂缓”。拒绝的需求是被认为对产品的商业目的没有价值的，而暂缓的需求是“有价值，但是现在不做”的，通常要表明重启的条件，比如“3个月后再拿出来讨论”、“某相关产品实现某功能后再拿出来讨论”等等。

　　对于状态变为“需求中”的功能点，下一步就是初定工作量了，因为需求不明确，所以只是简单的评估，和真实情况的匹配程度很取决于经验,要靠不断的实践来反复修正。我们通常经历的项目，三大类人力资源是“产品、开发、测试”，用团队里的瓶颈资源做评估基准，所以我们一般评估每个功能点的开发工程师工作量，因为在我们的团队里通常产品、测试资源相对可以调配，这个大家视自己团队的情况灵活应用。具体的评估，通常是类似技术经理的角色来做，评估者按照自己做需要多少时间，乘以一个系数确定，这个系数一般大于1。

　　继续，既然对于每个迭代周期，我们有多少时间、多少人是早就知道的，那么可用工作量是多少“人日”，也就知道了。有了每个功能点的商业价值和工作量，很自然的就能算出性价比，简单的说即“商业价值/开发工作量”，我们把feature list按照性价比从大到小排序，再对应考察每行评估出来的开发工作量，从上到下依次纳入项目，我们的可用工作量能做多少个功能点，一目了然。

　　上面谈到的这些，也就是一步步确定某个项目能做多少需求的过程。

　　最后，我们把这些要做的功能点合在一起，把“需求打包”，再往下就要做这个项目的BRD（Business Requirement Document）了。BRD通过，立项之后，再全程跟踪某个需求的进度。

　　上述整个过程就是一步步确定某个需求的各种属性的过程，而对某个需求的描述，主要必填项：提交人、模块、名称、描述、商业价值、开发量、性价比、状态、负责PD。

　　这个过程完全是定量的，也就回答了“做多少”的问题。但，真实情况哪会这么简单明了，下面再说几个需要注意的地方。

　　第一，需求打包最好打类似的功能点，是否类似取决于需求的属性，“确定属性”这步做的事情起作用了，一般来说业务上有逻辑关系的需求才会包含一个项目里，否则就是一个纯粹修修补补的“小需求项目”了。

　　第二，需求依赖，功能点互相之间有依赖关系，那没办法，只能先做某些功能，应该在feature list里注明；功能点与人力资源之间的依赖关系也会经常存在，在这里评估工作量的时候不会考虑“谁来做”的问题，但是在后续立项，组建团队的时候需要注意，当然长期来说，为了避免这类风险，提升与平衡团队成员的能力是王道。

　　第三，功能点的粒度大小问题，商业价值很高的功能，如果细分的话，我们也会发现其中有价值相对低的部分，所以功能点的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内。具体细到多少，也只能具体情况具体分析，我想工作量的最小单位总不能超过“5人日”吧。

　　总结步骤：

　　用户需求--->产品需求--->确定属性--->确定商业价值--->（对于“需求中”的功能点）初定工作量--->性价比排序--->需求打包--->BRD--->立项

3.需求采集的方法

　　定性研究可以找出原因，偏向于了解；而定量研究可以发现现象，偏向于证实。两者都很重要，缺一不可，只定量会“以标代本”，看到问题但不知道原因，只定性会“以偏概全”，很可能被部分样本的特殊情况带入歧途。人们认知新事物的过程通常都是从定性到定量再定性再定量，并且螺旋上升，而了解和证实也是在不断迭代进化的。

　　怎么说表现了目标和观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。两方面都很重要，我曾经认为“耳听为虚，眼见为实”，所以看到用户怎么做会比听他们说更真实有用，但后来体会到，只了解做是没办法知道背后原因的，而不知道问题的原因也就意味着没法从根本上解决问题。所以我们既要看用户怎么做，也要听用户怎么说，虽然他说的不一定是真话。

　　最常见的方法又如下——用户访谈、调查问卷、可用性测试、数据分析。

　　说和做、定性与定量，合理的搭配组合使用，才能发挥最大的作用，而对于一个产品来说，正好在不同的时期可以用不同的方法：

　　第一轮，产品规划阶段。听用户定性地说，确定产品方向，做什么？随机抽样了40个用户做访谈，据此写出需求列表。

　　第二轮，某个项目的早期。听用户定量地说，确定需求优先级，先做什么？投放了20万份调查问卷，确定了需求优先级的排序。

　　第三轮，项目实施过程中。看用户定性地做，要先做的那几个需求，应该怎么做？一边设计，一边陆续的找了10个用户来验证，做可用性测试。

　　第四轮，上线后的优化阶段。看用户定量地做，根据产品的用户使用情况做数据分析，不断地改进产品。

　　当然，这是一个比较重要的产品，所以在用户研究上投入了较多的时间与人力，更多的时候，我们会视情况采取简化的方案。

郑重注明：

　　文章整理自人人都是产品经理。

　　摘录地址：

　　http://iamsujie.com/1000/1007/

　　http://iamsujie.com/1000/1014/