如果选一项能力作为产品基础能力中最重要的一项，那我会毫不犹豫的选择“需求分析”。可随着工作的推进,我相信大部分产品经理会变得麻木，不再去分析需求的真实性，不再去考虑技术的可行性。会变成需求的翻译器，业务提什么就是什么，画个原型直接开发应付了事就好了。说实话很长时间我也陷入到这种状态之中，甚至丧失了思考的能力。但需求分析作为产品经理最最重要的能力之一，一旦丢弃也就相当于放弃了产品生涯。今天我将总结通用的需求分析产品方法论并结合实际工作场景与大家重新认识B端需求分析！一、什么是需求分析？ 如果说一句话概括需求分析，那么我的回答是：挖掘用户需求背后最真实的想法并转化为性价比最高的产品需求。这句话中涉及到的关键词有：
挖掘：用户不是已经说了他想要什么了吗？为什么还要挖掘？用什么方式挖掘？
最真实的想法：用户想要的到底是什么？
性价比最高：解决问题的方式有很多，哪种才是当下最应该选择的也是投入回报最大的呢？
二、B端需求分析有哪些类型？ B端需求分析可大可小，通常可分为用户需求（用户在工作中或产品使用中产生的功能性需求），业务需求（满足业务在某一场景下的系统支撑需求），产品需求（根据产品经验或行业标准提出的规划性需求）
写到这里我突然发现好像没办法有一套通用的需求分析模板去应对不同类型的B端需求。且C端常用的KANO模型、Y模型、马斯洛需求层级理论等好像都不是特别适用。因为B端的侧重点更在于业务的高效运作，用户的体验往往不是决定作用。所以我将对不同的B端需求类型提出自己的思考。
三、如何针对不同类型的需求进行分析？1、业务需求（往往涉及多角色、多场景、多模块）
在B端工作中业务场景的支撑是很常见的一类需求，比如供应链金融产品方案的资方对接，业务数据四流合一校验。这类需求往往包含了多个具体场景以及需要多系统，多模块之间的配合才能支撑业务流程的运作。清晰的梳理出不同场景下，不同角色的诉求至关重要。 此处以供应链金融经理最常接触的金融产品资方对接为例。所谓的金融产品资方对接就是将银行提供的支撑公司供应链场景下的某一类金融产品方案，形成内部系统与资方系统的全流程对接，支撑客户在该场景下的授信、支用、还款等主要操作。 那么在接手这样一个庞大的业务需求后如何开展呢？我认为可以抽象成以下几步：
1.1 了解项目背景 在了解项目背景这一步往
