时间: 2021-07-30 11:03:09 人气: 19 评论: 0
编辑导语：做B端产品的时候，重要而且不能忽略的一个步骤就是收集和分析客户的需求，并且根据需求来设计和改进产品。如果不了解客户需求，产品可能就**脱离客户，从而难以达成目标。由于To B 和 To C 有很大的不同，那么在ToB领域，应该如何收集和分析客户需求呢？
目前，C端产品的需求分析方法已经非常成熟，各位大佬已经提出了自己非常专业的视角。前文有提到，B端产品主要是面向企业的“组织欲望”，为企业“降本增效”（具体可见《To B 产品与 To C 产品的区别》）。
那么，B端产品需求，多数情况下不**像C端产品那样具有普遍性（saas类除外），更多的B端产品需求更加偏重个性化和定制化。
今天，猫爸就结合自己的个人经历，总结和分享一下，面对个性化、定制化的产品从0~1该如何进行用户的需求收集和分析。以供大家共同学习交流；由于专业及领域限制，难免存在认知限制，还请各位前辈指点一二，在下感激不尽。
在分析之前，我们先理解一下，什么是“用户需求”？
套用李叫兽《需求三角模型》模型，概括成一句话：用户需求，就是理想与现实之差。而对于企业客户来说，就是企业的理想与现实之差；即企业期望达到“降本增效”的理想，与现实工作中“高成本、低效率”的差别。
所以，当我们要做B端产品时，就必须要面向企业进行需求的收集和分析，了解清楚他们的理想与现实之间的差距究竟有哪些表现层面，落实到具体的工作中，又**有哪些流程需要梳理。
无论是对内的产品还是对外的产品，在落地设计之前，都需要进行需求收集和整理，B端产品的需求的来源一般分为如下：
1）客户调研
B端产品的需求，最直接的来源即为企业客户；前文也提到B端产品的本质是满足企业的“组织欲望”，所以B端产品的需求，一般都**根据企业客户调研进行需求的收集分析。
针对企业的B端产品，可以大致分为内部产品和对外服务的产品，但无论是哪种，都需要找到对应的企业需求发出人，然后进行采集分析。
2）竞品分析
对于SaaS级产品或标准化服务的产品，我们也可以根据市场上已有的竞品情况，进行收集分析，具体的分析方法本文不做赘述，大家可以参考之前的文章《B端产品如何做竞品分析》。
当然，在做竞品分析之前，我们也**时刻关注市场的变化情况，进而自主判断需要增加哪方面的产品需求，这种方式一般**与竞品分析进行合并梳理。
3）其他渠道
其他的渠道包括不限于销售业务反馈、售前售后咨询、公司老板提需求等等；此处不过多赘述，我们根据实际情况来酌情判断即可。
记得曾经遇到过一个面试题：当我们接到任务，要对某一家客户进行需求收集，或者对公司的某一项内部流程进行产品化；这个时候，我们一般**怎么做呢？当然，那个时候的我，有点懵逼。
首先分析我们在实际工作中面临的问题：
其实我们做产品，最本质的是“如何系统的梳理复杂的业务流程”，只有复杂的业务流程搞透彻了，我们才知道该如何将其线上化，产品化。
而这个“复杂”不仅仅是纯业务流程的复杂，还有可能是客户之间的内部关系的复杂，利益链条的复杂等等。所以，我们需要有自己的节奏和标准，做到“心中有杆秤，遇事不慌张”。
1）建立调研标准
在开展调研之前，我们自己要要有一个评判标准，主要有两个目的：梳理可以产品化的业务形态、判断需求的优先级。
B端产品的建立，都是基于目前目标客户的业务形态来进行的，所以必要的了解目标客户的业务形态，是非常重要的，常见的客户业务形态分类如下：
在需求调研之前，另一件非常重要的事情就是有自己的优先级判断，对于优先级比较低的业务逻辑，不要花费过多的精力去研究。
优先级的判断方式有很多，例如C端经常用的KANO模型等等。对于B端定制化方面的需求，常见区分优先级的方式比较简单粗暴：
需求优先级比较难定义；所以按照职能级别，老板级别最高，中高层就低一些。
因为老板**去看这个系统，然后中高层**去点头，然后才能付款。有些公司可能老板是甩手掌柜，但是最终还是老板拍板付款，所以有时候如何抓住老板的认可也要一定的技巧。
在同一级别里面，也要区分子级别，例如都是中层管理者，哪个人的需求该优先，哪个该延后，这些也是需要评估的。
一般情况下，**根据需求实现难易程度，需求发出者对业务的帮助贡献度、多名同级人员在公司的重要程度等等来进行区分（此处有点“势利眼”的成分哈）。
2）把控调研的节奏
有了自己的调研标准，那么接下来就是实际的业务调研了，在调研的过程中，我们必须有一定的章法节奏。一般通过下面四个方法，可以有条不紊的开展工作。
方法一：提前了解行业知识
B端产品经理，大多面向的对象都是各行各业，在做需求收集之前，我们必须要提前了解行业概况，了解这个行业的一些常见的专业知识和专业术语，这样我们在收集需求时，才能够跟需求方有共同话题，对方说一些专业的流程，我们不至于发懵。
一般的，行业知识的了解渠道如下：
方法二：私下沟通调研
找到对应业务的业务接口人，私下了解业务的方向，涉及到的部门人员，关键节点等等；重点是对客户的项目进行一个全貌的了解。
其实是伴随着**议沟通同步进展的；甚至前期应该先进行一轮私下沟通。**议沟通，一般是了解对方的战略方向，期望等；而私下沟通，有些**议中不能提及的问题，消耗时间的业务细节，**更容易了解。私下沟通重点关注以下内容：
方法三：召开调研**议
熟悉了一些行业知识后，首要任务就是开始调研了解对方的诉求。
可能前期商务关系的介入，大概的客户诉求是明确的，但是为了保障后续方案落地顺利，产品经理需要再进行详细的调研和挖掘，深入分析和了解对方的业务流程和业务方式，此时召开**议是非常有效的手段之一。
方法四：排除调研干扰
有时候，我们在调研客户需求经常不是那么一帆风顺的，抛去客观因素，我们还**遇到例如业务流程遭遇非业务部门干预、两个部门对于流程的意见不相符、调研对象拒绝沟通等情况。
此时，我们要可以尝试通过以下方法来解决：
业务流程了解清楚，需求收集完成后，我们就要开始进行业务需求的分析和梳理了。在分析梳理之前，我们需要了解到，关注这个产品的目标人群，他们的关注点有哪些：
想要满足这些，我们需要把用户需求进行梳理，形成可具象的落地方案。在梳理的时候，面对复杂多变的需求点，我们该如何做呢？
分析需求，本质上就是分析企业实际的业务场景，而任何的场景，都是由“人+事”组成，不同于C端产品的场景化思考，B端产品的场景化更加直接，我们可以直接面向目标对象来进行分析。
1）对人的分析
首先，我们分析需求时，需要了解到，这个需求到底是给谁用的？这个人在企业中扮演什么角色？他的这个角色是什么样的群体？这个群体在企业里面的组织架构是处于什么层级？这样我们可以获取到一个角色的图谱。
基于上述的角色图谱，这个角色有什么样的使用权限， 日常业务中能够访问哪些内容等等。
2）对事的分析
接下来，我们需要了解的是，假如我们完成了某个产品，那么这个产品能够帮助“人”做成什么事儿？“人”用这个产品可以做什么事情，角色的日程工作流程是什么样的？有些事儿的审批流程是如何的？每一个流程可能**涉及到的功能有哪些？哪些功能可以合并成一个大的功能模块？这些问题都需要分析了解。
无论是无论是对内的产品，还是为客户定制化的B端产品，一般的业务流程都相对复杂，该如何进行复杂业务流程的梳理呢？
1）step1：单一化业务流程
企业的复杂业务，一般都是由众多的角色一起参与完成的；但是常规情况下，都**有一个任务需求方发起任务，此时我们可以根据之前收集到的需求，通过初步的分析筛选，将业务流程单一化。
在单一化流程中，重点可以通过以下维度进行关注：
公司的产品线有哪些？这些产品线中，哪些是主流程？通过梳理，把众多主流程明确下来。
例如：虚拟物品下单流程中，浏览——下单——支付——发货——收货。这是一个主流程，我们可以基于这个主流程进行业务分析。
但是这个主流程里面，充满了多个分支流程；比如支付流程，就**衍生出第三方支付、银联支付等等，但是在进行业务分析下单流程时，将“支付”模块当做“黑盒”进行分析。如果是分析支付流程，那么就需要将对应的分支流程画出来，从而进行分析。
2）step2：定位关键角色
完成主流程的梳理后，每一条主流程，都**有一个需求角色，而其他角色均属于参与者。
例如：合同审批流程，需求方可能是业务方（销售、售前等），而参与的角色可能**有部门经理、分管副总、法务、财务、总经理等等，所以把这几个关键的角色找到，然后理清楚前后顺序，将他们的主流向图画出来。
需要注意的是，有时候，关键角色不一定是人，也有可能是系统，比如第一步的例子中，发放虚拟币可能就是系统自动发放，而不是某个人来发放。
3）step3：异常流程补充
主流程梳理完毕后，我们需要了解，对于单一化的业务中，有没有可能**出现异常的情况，如果是简单的异常逻辑，我们可以画在主流程中。
如果一个异常流程，需要处理和涉及的角色**更多，就**产生分支流程。此时我们把这条分支流程作为另外的一条单一的业务流程，重新进行step1、step2进行梳理。
在梳理流程的过程中，可以采用一个“台阶模型”的方式进行梳理（名字是我自己取的，勿喷），如下图：
把梳理的单一业务流程，按照上述图进行绘制，这样就可以清晰的明确一条流程中，有哪些节点，**有哪些参与角色。
通过以上的分析，我们最终能够将收集到的需求进行分析、汇总、归类。文档不需要非常详细，但是要给大家知道能够评估这个项目能不能做，具体怎么做，都有哪些东西需要做。
需求分析的文档一般包括以下部分：
1）项目背景
主要介绍当前项目的情况，包括的问题有客户的业务背景、产品背景情况：
2）目标
产品的目标是什么，产品能够为自己的公司，为客户的公司带来什么样的价值。
3）期望
对于客户来说，有哪些期望，包括不限于上线时间，投入产出比等等。对于公司来说，又有哪些期望，也一并列举出来。
4）详细需求列表
一份详细的需求列表，主要记录的客户关注的重点需求的所有细节，包括类别、提出部门、提出人、提出时间、需求描述、需求背景、需求的目标、提出需求的期望、涉及到的角色、权限、业务流程。
5）产品架构图
如果是一个完整的业务架构，还应该根据业务流程绘制出对应的产品架构图，方便大家一眼能够了解整体的产品架构及相互之间的耦合关系（注：架构图不是结构图，两者不是一个东西）。
我们最后产出的《需求分析文档》重点不是为了产出文档，而是为了各方在一起初步进行需求评估，从而为接下来需求是否能落地来进行准备。
所以在进入初期的评估阶段，公司的技术人员就必须介入进来参与评估。
通过整体的文档介绍我们也能够了解到需求工作是非常庞杂的，所以我们在前期的收集、分析阶段，一定要把控好节奏，根据项目情况进行灵活的应变及应对。
对于一个复杂的项目，要做好长期进行需求收集确认的准备。
需求收集是一个不断变化的过程，我们有可能面临着，不同人员对于需求的理解不同导致需求多次变更情况；也有可能面临需求提出者睡一觉就**改变主意的情况；也有可能是我们需求在评估过程中，研发说技术上无法完成的情况，更有可能是在设计阶段发现需求不合理的情况……
这些都**导致需要进行变更，我们需要时刻跟进项目情况，不断做出调整和协调，最终将项目落地。
作者：两只猫爸；公众号：PMGrow ，我**持续分享更多自己的心得，与大家一起交流成长~
本文由 @两只猫爸 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
