编辑导语：在做B端产品时，业务部门有时会随着业务发展以及管理诉求的变动，提出一个个需求。这种时候，该如何有效地、高价值地处理这些需求呢？本文作者对此作出了分析总结，一起来看一下吧。

在从事B端以来，发现业务部门会随着业务发展以及管理诉求的变动，提出一个个需求。当一个个需求扑面而来，如何有效面对、高效精准处理，现笔者将个人分析方法总结如下。
当一个需求反馈过来后，该如何处理呢？请随着笔者的思路往下看。

一、业务剖析

当业务部门提出需求时，首先要做的就是业务剖析，具体步骤如下：

1. 需求目的

首先需要弄清楚业务提出需求，背后所需要解决的问题，如上文《需求管理中的常见疑问剖析》中所讲，业务部门所提的需求，大多都经过了一定的包装，业务部门通过自己的理解消化以自己的口吻进行阐述，故需求深入刨地探查到业务部门的真实目的。

2. 角色与诉求

在探查到需求目的后，因为B端业务一般均有其复杂性，不像C端一般只有一个角色，故需要对涉及到的角色进行分解。需特别注意的是业务流中会存在纯线下的角色，也需要纳入考虑，对于大型业务来讲，还需要将管理者角色与执行者角色进行区分，两者诉求一般不一致（管理者角色一般侧重于总体业务运转情况，以及异常业务提醒方便及时介入）。

在梳理角色后，需要分别了解每个角色的职责与诉求，分别了解到每个角色的关注点，如果需求过于庞大，可能还需要现场调研。

如果对所对应角色不太了解，还需要对其进行初步了解，如其办公环境、文化素养等，否则后续可能会出现场景不适合的解决方案，如A角色没有电脑并且还来回走动，故不能使用电脑端而是手机端的解决方案。

3. 业务流程

分别梳理角色后，需要针对整体业务流程，进行全盘流程梳理。其中特别需要注意不同情况下业务流程分叉，进行出不同的分支流程，还需要关注同一事件不同角色的查看、处理、审批、监管等不同的权限。

在整理时，如果为纯线下无法线上的操作，也需要纳入梳理范围，确保涵盖整个业务流程。

4. 业务问题

在梳理业务流程后，那么结合业务本次提出的问题点，确定业务急迫需要解决的问题点。
哪怕业务只是一句话诉求，还是需要还原业务流程，对其进行全面梳理，做到心中有全貌。

二、问题诊断

在对业务剖析后，各位已经对业务诉求有了一定的了解，那么后续该进行业务问题诊断。

1. 问题的本质

上述描述中，已经对本业务问题有了一定的了解，那么为了准确把握业务核心，需要对该业务问题产生的原因进行分析，一般B端业务的问题主要是业务问题、经营问题、管理问题、财务问题等维度，如提高对目标用户的服务水平，带来更大应收，或提高内部效率降低成本，或从财务角度进行分析，提前进行财务收支的考量等。

2. 问题的探索

一般来讲，问题深层次原因分析，是有一定方法的，有经验的可能能直接洞穿核心目的，但也可以通过5why法则，层层深入分析，一层层解剖，直到无法在深入为止，那么可以把握到核心的本质。

在追问时还需要注意，需不断进行纠偏，防止在不断追问中进入错误的岔路，因此需要逆推，也最好能正着推理一遍，并进行论证。

三、方案解析

经过上述分析后，业务背景、项目目标有了深刻了解，也对涉及角色、诉求有了了解，也绘制出了业务流程图，那么接下来该如何完成产品方案的解析呢？

1. 数据建模

需要对业务中处理事项进行模拟建模，分别建立一个个数据实体，围绕数据实体可形成一个个的基础数据层级，数据建模的步骤可以分为 梳理核心流程 – 提取名词 – 找到关键要素 – 提炼围绕表单的人事物。

举例，引用《决胜B端第2版（19）：业务数据建模》一文中的案例，首先整理核心流程，“小李是XX公司的采购员，工作日每天，小李都需要拿着M公司的业务员发给他的最新商品清单和报价，检查自己所在门店的缺货情况，购买黄瓜、土豆等蔬菜，整理记录在自己的记事本上，然后仔细核对后，将本次采购清单用微信发送给M公司的运营人员，等待对方确认”。

在整个流程中，我们将所有名词标出作为备选数据实体。然后找出这个流程中的关键表单，在上述中，我们将采购清单作为关键表单，也就是订单。最后，我们找到围绕关键表单的人、事、物，将刚标记的名词，做合并同类项，我们可以抽象出商品、用户等实体。

2. 梳理关系

确定实体关系后，我们要梳理实体之间的关系，判断哪些实体有关系，是什么关系。实体之间的关系一般有一对一，一对多，多对多三种关系。

在梳理关系后，还需要对各实体之间的关键属性进行梳理。

3. 功能流程梳理

在梳理数据实体，彼此间的关联关系，以及其属性后，可以结合业务流程，绘制功能流程图，可按照不同实体在业务流程下，其属性如何变化，有一定关联下，彼此如何影响。

4. 其他注意点

在梳理完成上述分析后，还有几个点需要注意：

• 首先需要考虑业务的可能发展模式，考虑其兼容性，避免随着时间推移兼容性降低，无法满足后续功能迭代需求
• 需分析与现有功能的联系性如何，需整理出相关联的影响性
• 系统性能，是否有较为庞大的计算性能需要考虑，那么将其纳入考虑，或者以前预研
• 用户权限，不同的操作功能，用户权限是否一致需进行判断

5. 功能清单

在经过上述分析后，可以整理输出功能清单，对涉及功能点以及功能描述进行整理，并对优先级进行判断，可依据业务情况进行分期实现。

四、价值分析

其实价值分析，是上一步”方案解析”的一部分，笔者将其单独拿出，进行描述。是因为很多人在进行方案中，常常忘了对方案价值度的分析，从而可能会做一些低价值度的工作。对价值的分析，可以让我们提炼一些更有价值的事情，也可以让我们的方案价值度更高，下面笔者对多个价值维度进行分析。

1. 业务价值

在完成分析后，需再次回顾对业务的价值点，是否完成了业务目标，对业务的价值提升点在哪里，业务价值度大小。可以用来判断事项的紧急度以及重要程度，以及上线后对业务的价值度大小。此时可以对一些伪需求以及价值度低的需求调低优先级。

2. 方案成本

在考虑方案后，需考虑方案的成本情况，如果价值度一般但成本较大，则可以考虑不做，或换一种低成本的实现方式。

3. 方案亮点

回归到产品方案本身，那么对产品方案的提炼，考虑其扩大化价值以及其他额外价值，是需要再次进行提炼的。扩大产品价值的范围，或者深化产品逻辑，可以从信息化的角度，多思考下，下一步对技术的赋能是哪些。最好能做到做一步看一步想一步，多往前思考几步。

五、原型设计

在上述方案完成后，就需要对原型进行设计了。一般来讲，这个是产品常规的操作动作，笔者就不深入展开了，就简单讲几个提效的方法。

1. 原型内容模块化

原型为了快速绘制，可以整理常用的axure架构文档，如可以将文档日志、背景目的、流程图、管理后台、APP端等不同的内容，模块化掉，这样在axure中可快速按照目录快速绘制。

2. 备注表格清单化

在绘制原型外，还需要增加备注描述，那么笔者推荐清单化的备注方式，可以整理备注的表格模板，在绘制时直接按照模板近快速备注。这样形成规范后，可以按照内容快速输入，技术也可以按照此模板形成习惯。

3. 功能模块组件化

为了快速绘制原型，可以整理组件库，按照常用模块，如后台样式，app样式等，梳理组件库。在绘制时可快速拖拽形成高标准的低保真原型。

4. 检视清单可视化

在完成原型设计后，可能存在快速完成原型，出现遗漏的情况，可建立检视清单，对重点项与常遗漏项建立清单，后续可核对数据。此表格可常看常新。

六、业务模拟

到第五步为止，方案已经成型，那么为何这里还要多此一步呢？因为对于B端业务来讲，其大多数对系统并无想象能力，单纯通过对系统的了解，无法想象出实际操作的场景，因此按照传统瀑布流的操作方式，业务往往在上线后才知道实际使用场景，故会出现对需求返工的现象，故结合敏捷思维，增加业务模拟步骤。

1. 模拟演示

在快速迭代中强调价值驱动与风险驱动，故对着原型将业务流程重新模拟一遍，在结合业务流程后，可以保留该方案使用中可能产生的风险，并在模拟中让一线感知到系统对业务的帮助，进一步强化业务价值。同时该过程也是对方案与业务匹配度的核实过程。
注：该过程也业务确认的区别在于，业务确认过程是以自己为核心给业务灌输方案，而模拟演示是在引导下业务自驱完成模拟。

2. 运营策略

在模拟演示后，核实方案无误后，还需要讨论商量运营策略。即该模块上线后业务方准备如何推广，如何让一线使用起来的策略。该策略也是最后体现方案价值的点，故也需要深入思考。

以上是笔者对完成B端需求设计的总结，希望能对此时阅读的你有帮助。欢迎各位来留言哦~

本文由 @王常耑 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议