“产品需求”是产品经理基础能力中最重要的一项，贯穿了整个行业生涯。下面这篇文章是笔者分享总结通用的需求分析产品方法论并结合实际工作场景的内容，令大家再重新认识B端需求分析。为了不辜负笔者的好意大家一起来看看吧！
如果选一项能力作为产品基础能力中最重要的一项，那我会毫不犹豫的选择“需求分析”。可随着工作的推进,我相信大部分产品经理会变得麻木，不再去分析需求的真实性，不再去考虑技术的可行性。
会变成需求的翻译器，业务提什么就是什么，画个原型直接开发应付了事就好了。说实话很长时间我也陷入到这种状态之中，甚至丧失了思考的能力。但需求分析作为产品经理最最重要的能力之一，一旦丢弃也就相当于放弃了产品生涯。
今天我将总结通用的需求分析产品方法论并结合实际工作场景与大家重新认识B端需求分析！
如果说一句话概括需求分析，那么我的回答是：挖掘用户需求背后最真实的想法并转化为性价比最高的产品需求。
这句话中涉及到的关键词有：
B端需求分析可大可小，通常可分为用户需求（用户在工作中或产品使用中产生的功能性需求），业务需求（满足业务在某一场景下的系统支撑需求），产品需求（根据产品经验或行业标准提出的规划性需求）。
写到这里我突然发现好像没办法有一套通用的需求分析模板去应对不同类型的B端需求。且C端常用的KANO模型、Y模型、马斯洛需求层级理论等好像都不是特别适用。因为B端的侧重点更在于业务的高效运作，用户的体验往往不是决定作用。所以我将对不同的B端需求类型提出自己的思考。
（往往涉及多角色、多场景、多模块）在B端工作中业务场景的支撑是很常见的一类需求，比如供应链金融产品方案的资方对接，业务数据四流合一校验。这类需求往往包含了多个具体场景以及需要多系统，多模块之间的配合才能支撑业务流程的运作。清晰的梳理出不同场景下，不同角色的诉求至关重要。
此处以供应链金融经理最常接触的金融产品资方对接为例。所谓的金融产品资方对接就是将银行提供的支撑公司供应链场景下的某一类金融产品方案，形成内部系统与资方系统的全流程对接，支撑客户在该场景下的授信、支用、还款等主要操作。
那么在接手这样一个庞大的业务需求后如何开展呢？我认为可以抽象成以下几步：
1）了解项目背景
在了解项目背景这一步往往需要具备一定的领域知识，在本例中就需要了解金融产品方案要素，业务模式，以及与需求的各个参与方沟通，明各方在本需求中期望实现的结果。
2）业务场景分析
在进行业务场景分析时需要明确在该需求中存在的核心场景有哪些，可以是通过线下用户调研了解，也可以是通过行业标准化的东西去制定，这也需要产品经理具备一定的行业知识。
就本案例来说如果不了解供应链金融的运作流程，是无法从关键节点切入进行分析的。当了解到关键的运作节点有客户授信，客户支用，客户还款以后就可以从这三大主流程切入进行需求分析了。
以客户授信举例，需要梳理出在这一关键场景下，各参与角色的背景、诱因及期望。可采取5W1H的方法进行细致拆分。
3） 核心业务流程梳理
在完成了核心业务场景分析后，我们就需要进行核心业务流程的串联，这一步至关重要。在这一步通常需要进行泳道图的绘制。
将核心场景中的参与角色进行串联形成完整的作业流。这里的流程可能不是由产品决定的，其实往往是由业务决定的。所以产品需要反复与运营、资方进行沟通以确保流程能够满足各方的需要。
这一步的分析将很大程度的影响后续在产品设计中能否满足用户的核心需求。因此在分析过程中对于各方的侧重点需要深入挖掘。对于资方来说它在意的是客户的详细数据获取以最大程度的支持授信风险判断；对于运营来说更在意的是在推广业务时流程和客户操作的便捷性最大程度的提升授信额度。
4）产品需求
在了解了项目背景，业务场景及业务流程后，我们终于可以开始进行产品需求的转换。我们需要着重考虑在业务流程中各系统应该提供什么样的功能来支撑业务流程的高效运作，并完美的与现有系统融合，以及后续产品迭代的拓展性。以及设计的功能能否满足每个用户最核心的诉求。
下图为我在本案例中涉及的工作任务：
用户需求的提出往往是针对非常具体的一个业务场景，它也可能包含在业务需求之中，在业务需求中定义好每一个模块后可能仍需对具体模块进行需求分析。那如何进行这类需求的分析呢？可参照C端需求分析方法。
1）需求澄清
用户在提出需求的时候往往不会的特别具体，甚至他自己也不知道自己的核心诉求是什么。他可能只说了一句话，但如果不进行澄清的话，直接按照个人主观判断去做很可能得到的并不是用户想要的。这里仍可以采取5W1H方法。
那么对于上面业务需求的客户授信场景下，会存在这样一个需求，客户基础数据的收集并推送资方。采取5W1H可拆分进行分析。
经过以上的分析可以得出哪些产品设计的关注点呢？
使用客户多对PC端操作不熟悉，更多使用移动端，信息收集尽量简便、多采取下拉选择方式。收集节点在授信审核前，因为在授信前会有运营同学在现场可指导客户操作，为满足资方对客户数据的维护也需要与资方沟通确认采集字段，并尽量与资方争取简化满足客户高效填写的问题避免损失客户耐心。
这样一来毫无头绪的一句话的简单需求在脑海中就更加清晰了，也能够指导我们下一步的工作以及产品设计的侧重点。
2）需求甄别
在日常需求工作中，产品经理会接收到大量的需求，如果全盘接收，那么开发的招聘将永无止境。因此在进行产品设计前还需要确定需求是否值不值得，应不应该做。可以从以下几个方面考虑：
前面几点都很好理解，但对于是否为硬性要求来说需要考虑的是业务场景中合规要求、合作方硬性要求等等。
3）需求优先级
如下图所示：
紧急与不紧急的判断在B端可以根据影响业务运行的程度来判断，重要不重要可以根据提升业务的价值程度来判断。
P序列：按照优先级划分P0>P1>P2>P3>…>Pn，如下图所示：在工作中产品经理经常会碰到多个需求，没办法绝对判断出哪个需求是P1、哪个需求是P2的顺序。这种情况下，建议按照经验执行就好，不要那么纠结，反而浪费时间。
4）确定产品需求方案
确认需求方案，其实就是根据前面在需求分析的过程中，所提炼出的目的及流程，针对性的去设计出满足需求的产品方案。包括但不限于：系统流程设计，页面流程设计，原型设计，交互设计等等。
当然对于一个问题的解决方案有很多，作为B端产品可能还需要由业务决定，可将你认为合理的方案全部提供出来由业务拍板，当然也要有自己的思考和立场。
在日常产品工作中，产品经理可能会根据自己或行业的经验提出对现有功能的迭代或新的功能点，更有可能是领导的一句话需求。对于这类需求需要注意的是避免陷入自嗨，觉得自己想到个新功能直接原地起飞，在一年半的工作里没少干这些事。还是要将需求放在业务场景之中，多做竞品分析及用户调研，结合业务发展现状及价值综合分析。
在B端产品分析中可能没有C端那样侧重用户体验的分析，更多的分析重点是业务运作本身。对于业务需求及用户需求两者经常会结合在一起。通过分析业务需求得出产品整体架构，再通过用户需求分析对具体的功能模块或功能点最大程度的满足各方需要。
当然还有一些其它的需求分析方法论，比如用户体验地图、KANO模型、Y模型等等，更多的会偏向C端一点。在B端这里UML统一建模也是迈向更高级产品分析的一门好课程，有兴趣的可以深入了解一下。最后欢迎大家交流自己的思考和批评指正！
本文由 @爱健身的产品小白 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。