需求分析可以说是产品从业人员的核心技能了，若分析不够轻则需要反复调研，重则导致产品定位不清晰、不满足需求，需要推倒重来。本文主要介绍本人在B端产品需求分析实践过程中的思考和注意事项。
上篇文章《B端产品需求采集的实践与思考》介绍了B端产品需求采集的方法和注意事项。我们将采集回来的需求称为用户需求，用户需求转换为产品需求需要经历一个需求分析的过程。
一、概念解释
在正式进入如何进行需求分析之前，我们先来理解下什么叫做需求。
《人人都是产品经理》一书作者苏杰曾指出：“减少甚至消除理想与现实的差距的愿望，就产生了需求”。
本人认为这是从宏观方向的解释，若从软件或互联网产品这个微观角度解释的话：需求是在特定的角色特定的场景想要达成某种目的内心的渴望。也就是在研究需求的时候，不可将角色、场景和内心渴望分开来讨论，否则就容易导致需求不满足的情况。
具体案例下文将会有，这里不做太多赘述。
理清需求的概念后，需求分析过程本质上就是找出用户在具体场景下内心的渴望，然后通过软件的方式帮助实现这种渴望。但是并不是所有的渴望会被满足或立即被满足。
二、需求分析案例实践
通过前期的需求采集大行动，我们的需求池里存储了大量的需求。面对众多未经过分析的需求，不禁反问自己：
这些纷繁杂乱的需求都应该被满足吗？
如何筛选掉伪需求？
如何挖掘用户的潜在需求？
带着这些问题，我们一起探讨下本人在需求分析实践过程中的方法论。
1. PSP方法
P：即Peson，角色
S：即Scenes，场景
P：即Paths，路径
脱离角色谈需求，适用用户则不明确；脱离场景谈需求，则需求适用业务范围不明确；脱离路径谈需求，则业务流程不明确，因此PSP方法可以很好的帮助分析人员明确具体的需求。
案例实践1：
下表为需求池当中的1条需求，其中需求描述为客户提出的原始需求
在B端产品中，很多时候我们会拿到这种角色和场景不太明确的需求， 拿到这种需求之后，切忌直接动手开始设计，否则带来的后果轻则后期改动所带来的成本消耗，重则需要全部推倒重来，面向B端产品，常常涉及到多角色，因此在思考任何一个需求的时候，一定要加入角色，通俗的讲就是思考什么类型的用户在什么样的场景下想要做什么事，等到我们理清了这些思考，需求将会变得越来越明确和合理，下表即本人在针对上表需求的PSP方法过程，内容仅供大家参考，重在帮助理解该方法。
可以看到将不明确的需求依据角色、场景和路径进行划分可以得到一个个明确的需求。
2. 需求三法（加法、减法、挖掘）
1）需求减法
需求采集回来的林林总总的需求，要学会做减法，目的是保证产品定位更清晰，用户体验更好，以下为本人总结需求做减法的情况：
影响产品定位，每个产品为了适应市场的竞争会形成自己的差异性定位，若是需求会影响到产品的定位，一定要非常的谨慎，否则会导致产品臃肿、定位不清晰，影响会很大。在B端项目中采集回来的需求，需求若合理但不符合产品定位的情况，可放到项目中实现，但不应在产品中实现。
影响用户体验，当我们的用户经常抱怨产品界面充斥着很多无用功能、界面重点信息不突出，用户上手困难，学习成本高的时候，可能需要对需求做减法了，很多需求是产品人员不考虑用户的实际情况自己构造出来，若是不符合用户需求，应该果断砍掉。
暂时不实现，需求合理，但现阶段因各种因素不能满足实现的情况下，可安排到以后的版本，待时机成熟时再实现。
2）需求加法
很多时候满足了用户提出的合理需求，依然不能很好地满足实际的应用，或者产品无亮点，不能形成自己的优势，这个时候我们需要头脑风暴，对需求做加法，然后进行验证，进而强化产品的功能、定位和用户体验，
案例实践2：
科室人员制定需求计划的时候，可以手动选择物料填写采购数量。这样做存在的问题是：科室人员必须非常清楚需要什么物料，且每个物料需要手动选择，工作量大；另外填写采购数量受主观因素影响，未必合理。
为了解决上述问题，我们给需求做了一个加法：依据历史消耗量自动生成采购数量，其功能取名为辅助决策，就是自动带出该科室历史周期消耗量作为采购数量；支持编辑，该功能可以大幅提升录入效率，这样就能很好的满足自动选择或者自动生成的实际应用场景了。
3）需求挖掘
需求的挖掘是建立对用户的了解和业务经验基础之上为了更好的满足产品的需要而进行的行动。
案例实践3：
实际的仓库业务中，安全库存和最小库存是库房人员一直关注的重点。若当前库存小于这两个值，会影响到库存的周转甚至经营，因此隐含的需求就是及时地补充安全库存和最小库存量。
经过挖掘，明确了安全补仓这个需求；然后与用户进行了验证，用户惊喜地确认了需求。因此建立在对用户和业务了解上，不断地深入场景进行分析，挖掘出让用户惊喜的需求。
3. 做一次需求评估
通过上面的方法找出了用户真实的需求。但能否转换产品需求还需要一个过程那就是需求评估，需求评估的过程其实是对对需求的商业价值、迫切程度、实现难度、性价比评估的一个过程。
案例实践4：
下表内容为本人评估辅助决策的过程，仅供大家参考
其中：
强度为对该需求的渴望程度；
频率为该需求会出现的次数；
持续时间为该需求出现的时间范围；
实现难度也就是我们常说的开发量；
性价比=商业价值/实现难度
优先级是建立在前面的分析的基础上评估的开发顺序，也就是四象限法则。
四象限法则提倡优先处理重要而不紧急的事情，当然突发的重要且紧急的事情也应该优先处理。不过该类情况的发生通常是因重要且不紧急的事情规划不当引起的，因此应该根据实际情况进行优先级的处理。
关于四限法则具体的理论和解释大家可自行了解，本文就不做过多的赘述了。
1. 业务经验不足
B端产品因涉及到具体的行业和业务知识，如金融后台、ERP、CRM等系统，因此要求产品人员具备较深的业务背景知识。
刚入行的产品新人，往往会因业务经验不足导致需求分析无从下手；首先不要灰心，成长需要一个过程，可以先尝试不涉及太多行业知识的需求进行入手，然后要做的是多请教、多学习、多跑系统积累行业经验。
2. 思维逻辑不够严谨
思维逻辑不够严谨主要体现在需求的分析和撰写上，这种情况通常是考虑不到位或者不够全面造成的。
其实产品人员很难保证说自己做的需求分析是绝对严谨的，但是我们能做的是尽量的严谨，注重细节多思考、多总结各种可能性，逐渐提升自己的思维严谨度。
3. 眉毛胡子一把抓
出现这样情况往往是没有做深入的需求分析和评估引起的，分析不够则判断需求是否合理困难，不会做减法；缺少需求评估则缺少实现合理需求的优先级排序。
避免该类的情况发生的方法是可按照上文的方法做深入的需求分析和需求评估。
4. 不加思考，全盘接受领导安排需求
领导提出的需求不一定全是合理的，产品人员要把控好每个需求，面对不合理的需求，要敢于提出来，多思考为什么会提出这样需求，这样才能在共同理解的基础上进行沟通。
5. 不加思考，完全照搬需求
很多时候，从竞品照搬需求貌似是一个省心省力的工作，但是若是不加思考的完全照搬则是一个不明智的做法，照搬的需求可能不一定适合产品的定位或者不是在本版本实现，这里本人想提的是一定要有独立思考的能力，过手的每个需求都是经过深度思考的。
很多时候，产品人员会头脑风暴产生需求，很多令用户眼前的一亮的功能就是来源此，但是该类需求一定要做可用性测试快速验证是否合理，避免出现闭门造成的情况。
四、总结
以上就是本人对B端产品需求分析的实践和思考，重点阐述了需求分析中PSP、需求三法、做一次需求评估的理解和运用。
另外为了避免再次入坑，总结了本人在B端产品需求分析中容易碰到的坑。当然由于行业和经验的差异，以上所述可能并不通用，仅供大家参考。
感谢大家的阅读，另外预告下篇文章内容主题—如何进行B端产品的设计。
