在大部分后台产品工作中，我们都可以结合“抽象”和“具象”的思维方式或工具来达成需求提炼和实现。这篇文章里，作者便讨论了怎么通过抽象具象来做业务需求，一起来看看吧。

一、抽象和具象的定义

引自百科https://baike.baidu.com/item/%E6%8A%BD%E8%B1%A1/9021828

抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。具体地说，抽象就是人们在实践的基础上，对于丰富的感性素材通过去粗取精、去伪存真、由此及彼、由表及里的加工制作，形成概念、判断、推理等思维形式，以反映事物的本质和规律的方法。

实际上，抽象是与具体相对应的概念，具体是事物的多种属性的总和，因而抽象亦可理解为由具体事物的多种属性中舍弃了若干属性而固定了另一些属性的思维活动。

抽象和具象，是产品工作中达成需求提炼和实现的无往不利的工具，能够运用在大部分后台产品工作中。

产品工作的抽象和具象过程包括两步：一、业务需求的抽象和具象；二、产品化的抽象和具象。前者决定了我们对于业务理解的透彻度；后者决定了我们实现方案的好坏。本文主要讨论怎么通过抽象具象来做业务需求。

二、利用抽象理解需求本质

产品前辈们提出了KANO模型、马斯洛、5W2H等方法做需求理解和分析。这些需求方法本质上就是抽象的过程和结果，达成对需求的理解。学会抽象，一招抵多招。

1. 抽象用户群体

抽象用户群体大致分为：用户标签化和群体分类、特定业务的群体提取。

1）用户标签化和群体分类

用户标签化和群体分类是一个通用性工作。在我们接手一块业务时，就需要有意识的建立用户画像，在工作开展过程中逐步加深用户理解并完善画像。ps：这里的用户画像不是说搭建一套用户画像系统，只是简单的用户画像建立，可以是你心中有数；也可以是沉淀为你的文档资料库。这也是地基性工作，会很大程度上提高我们承接需求的处理效率。

第一步：用户画像初步建立，从业务模式找用户群体。

首先，对用户分类。举两个简单的例子：

例1：电商提供撮合商家和消费者的平台。从交易达成角度，用户分类包括商家、消费者。从业务流程角度，为了达成支付功能，衍生出对应群体是支付服务商；为了商品端到端的送达，衍生出物流服务商群体。从运营管理角度，有运营、客服、数据、管理层…而事实上，基于电商业务可以继续衍生出仓管需求、推广需求、商家的供应，而后衍生出更多用户群体。

例2：快递撮合收寄方，提供配送服务。从交易达成角度，用户分类为收件方、寄件方。从业务流程角度，为了收件、送达，衍生出末端网点和快递员；为了实现物品跨区域运转，衍生出车队、分拨。

其次，设定用户标签。

以快递的寄件方举例子，由于寄件需求不同，衍生寄件方的标签，从规模可以分：大商家、小商家、个人..；从配送速度和品质的诉求上可以分：普通时效、普通时效、贵重物、生鲜件等。

第二步：用户画像的迭代。通过你对业务加深，校正群体分类和标签；在业务不同阶段，用户画像也需要不断迭代。

2）特定用户群体的提取

在开展具体业务需求的用户定位时，其实就是从用户群体库中，抽取当下业务场景的客群。当用户向你提需求时，如果你不了解你所负责产品的用户画像或者判断错用户群体，你很容易偏离本质。

需要明确定义：需求提出方 ≠ 产品使用者，产品使用者 ≠ 目标用户。

1. 需求提出方 ≠ 产品使用者：管理者提出做一套oa系统管理员工。需求提出方=管理者，产品使用方=员工。

2. 产品使用者 ≠ 目标用户：运营人员通过优惠券活动管理实现配置化活动运营。产品使用者=运营，目标用户=参加活动的客户。

后台产品常常有个现象是，业务部门的下属员工在上级要求的基础上给我们提需求，或者下级提需求约束下级员工的使用行为。千万不要进入直觉误区，我们需要抽取需求提出方是在为谁提出需求，希望谁来使用，谁真正使用。

2. 抽象问题

后台产品多着重于降本增效，存在实际的业务场景。因此需求理解分析，着重在抽象问题。抽象问题决定你挖掘需求的侧重点以及优先级。

抽象问题是向上提炼的过程，通常可以概括为：

1. 做这个事情是为了解决/预防什么问题？业务方表达的需求可能和他背后的目的存在失调。抽象问题的过程是去伪存真的过程。

2. 这个问题产生的原因是什么？解决问题表象是一种纠正型方案。进一步抽象原因，解决原因，是预防性方案，我认为是更推荐产品经理们给出的方案。

举个例子，我遇到过业务向我提出”对于一个自动化流程中间增加人工审核节点”需求。这是一个很典型既存在认知失调，又是一个纠正型方案的案例。

1. 业务做这个事情是为了解决/预防什么问题？通过调研，我了解到提出这个需求的背景是，大批量分公司向他反馈现有某自动奖惩机制薅羊毛行为损害他们利益，他们希望能够停用这个机制或者支持申诉审核，所以业务向研发团队提出增加人工审核流中断奖惩的发放。从这里可以得出结论，业务核心诉求是为了避免薅羊毛行为，平抚分公司不满。

2. 那么这个问题产生的原因是什么？进一步剖析薅羊毛行为的产生原因是什么？其一，利益点驱动薅羊毛。其二，活动判定奖励规则存在漏洞导致薅羊毛。

如果采取业务提出的增加人工审核节点方案，存在几个缺点：

1. 开发审核流配套页面功能，研发周期长。
2. 业务既没有想好怎么做审核，而且还有投入当前本就稀缺的审核人力做更多审核。那么也就意味着人工审核方案并不一定能够安抚分公司，也不一定能够人工判断出薅羊毛的订单，所以这是一个认知失调点。
3. 也是更重要的一点，增加人工审核节点违背了当初奖惩活动的出发点，可能导致这个活动本身的失效。

再结合抽象出来的问题原因，相对于后置性解决风险的方案，我们还可以考虑通过前置性预防方案，通过完善奖惩规则来解决问题。最终我们通过增加1个规则，半天上线这个迭代，解决了90%以上的薅羊毛行为。

三、利用具象做需求验证和场景补充

从现状做抽象，是对特例做总结的过程；再从抽象回归具象，是对总结通用性验证过程。

需知，我们做产品时对口业务水平是参差的，他们对自己业务了解深浅是不同的；需知，人的考虑视角是有限的，我们抽象问题时会陷入思维茧房。所以从抽象回归具象，是验证需求的理解；基于抽象，延伸更多具象，可以补足可能场景。这是一个查漏补缺的步骤，也是设计出可拓展性产品方案的重要基石。

比如我们从制定指标规则来看怎么回归具象反哺规则制定。物流有个常用考核指标“揽件及时率”，顾名思义即在约定时间内及时完成揽件的订单占比，通过考核揽件及时率要求站点的揽件履约时效。为了更好达成对站点的考核要求，一般设定率值计算规则时，我们通常回归具象，就是去穷尽揽件场景，找到非站点原因导致履约不及时订单场景进行降噪。

回归具象，最常用手段就是不断推导业务流程下衍生的场景，构造树一样不断建设既定会发生或假定会发生场景。我认为能够覆盖到大部分分支场景就能进入到产品化步骤。这种方式既可以用在0-1需求上，也可以用在1-n功能优化。

另一种回归具象的手段是数据验证，建立评价指标抽取过往数据分析验证。这种方式对于小公司的后台产品可适用场景较少，更多适用在后台用户较多、角色比较复杂，流程性功能或数据型功能优化上。