编辑导语：中台入门的要点之一就是模型，本篇文章详细分析了中台模型的概念以及模型的原理，帮助理解中台入门中比较重要的知识，详略得当地运用案例讲解产品能力模型是什么和怎么做，推荐想要学习中台模型的群体阅读。

中台的落地就两个事情最关键，一个是抽象能力模型，一个是领域分层。能力模型是抽象出来的，领域分层是中台不断的沉淀能力的过程中进化出来的，他们的目的都是为了中台能够高度复用和高度可扩展。

由于内容过多，本篇文章先讲解抽象能力模型。

一、什么是能力模型

接触了中台产品经理后，你会经常听到中台的产品经理在说模型，而且只要模型不大动，对中台来说都是小需求。那么模型到底是什么呢？在讲中台需求之前，我们一定要先普及模型的概念。

先说个题外话吧，为什么我们一定要讲某些东西的概念呢？我们现在用的、学的很多东西是学者、教授、专家在跨世纪之前就使用并总结过的，而且对概念做了足够的抽象和定义，如果我们做事情的时候能够先将概念理解透，再按照概念划分好的边界去执行和实施，那我们做的事情就是一个明确的看得懂的事情。

所以如果你做某件事情最初没有方向的时候，不妨先去摸索一下这个事情的定义，进而围绕定义做些产品方法论的扩充。

我们了解了模型的概念以及模型的原理之后，就对我们工作中如何去抽象产品能力模型有了一定的理论基础。

针对模型的概念，我主要援引 CSDN 的一篇文章，以通俗易懂的语言讲清楚了模型。

以下是引用的内容：

模型是对客观现实的事物的某些特征与内在联系，所作的一种模拟或抽象。

一切客观存在的事物及其运动形态统称为实体，模型是对实体的特征及其变化规律的一种表示或者抽象，而且往往是对实体中那些所要研究的特定的特征定量的抽象，可以说，模型是把对象实体通过适当的过滤，用适当的表现规则描绘出的简洁的模仿品，通过这个模仿品，人们可以了解到所研究实体的本质，而且在形式上便于人们对实体进行分析和处理。

模型=针对某一实体的主体（因为文中提到「过滤」，我们可以理解为是将某个实体过滤后，保留主要部分而暂时丢弃边缘部分）进行概念和规律的抽象。进而使模型可以推理出更多的概念和结果。

我们上学时期接触最多的就是数学模型，比如通过1+1=2这个基础数学模型，可以推导出1+2=3。

所以某个产品模块的模型就是针对某个功能的主体部分进行概念以及数据、流程规律的抽象。

抽象的过程，是一个将原来的东西打散了，拆成了各种不同的元素之后，把元素进行归纳总结和分类，然后将分好类的元素再重新组合的过程。

想了解如何更好的归纳总结分类，推荐《金字塔原理》。

为了更好的理解模型的概念，我们还是举个例子更形象一些。

比如一个用户账号合并流程。

项目背景是：某平台因为要保护用户隐私，没有将全局用户唯一 id 给到对接的商户，也就是可能一个人访问了商户的小程序之后，又访问了商户的公众号，如果不通过其他辅助信息，只通过某平台的 unique id 或者 union id 是无法判断该用户是否为同一个人的，只有当用户给出了身份证号或者手机号等其他信息，我们才能判断用户是否为同一个人。

但是在获取这些信息之前其实用户账号已经存在了，用户在给出这些信息之后，我们就会涉及到用户身份账户的合并。

在我们的体系里，用户有多种身份角色类型，我们暂且称为ABC三种类型，这三种类型之间有着各种业务逻辑，一个人可能既是A又是B。业务产品从业务角度考虑，他的需求是下面这种：

需求最后的结论就是最终筛选出一个唯一用户身份账号来，多余的账号做了其他处理。这个图形其实已经简化了业务逻辑，真正的业务逻辑并不止于此，因为每两个角色之间的比对流程都有诸多的判断和校验。

业务侧按照上述逻辑处理是完全没有问题的，因为在业务侧用户角色是已知且确定的，按照自己的业务走向，大概率不会再出现第四种角色，这个逻辑是写完这一次就可能用几年的逻辑，而且实现起来非常快速。

但是中台就不能这样处理了，为什么不能这样处理我稍后会详细讲解，这里我直接说中台最终的产品方案。

最后中台的这个产品方案就是该诉求下的产品能力模型，这个模型将整个用户合并逻辑抽象成为了一个处理流，以后不管出现什么用户角色，都可以用这个流来处理，而且未来可以支持各个业务侧自定义每个流程节点的比对属性，自定义属性的优先级高低。

并且在中台内部的除了账号体系领域外的其他领域，也会因为账号合并而带来各个领域数据的合并，他们都用这个流状的模型。

这个流状的结构可以狭义理解为一个模板，这个模板的主要组成元素就是比对节点、比对属性的优先级、比对结果的处理。任何一个相似的诉求的东西都可以套用这个模板，只要套用时定义好触发的事件，再配置不同的属性不同的优先级不同的结果，就可以应用到其他领域的数据合并中了，达到了抽象复用的目的。

回到上面中台为什么不可以复用业务逻辑的原因，大家可以设想一下，如果中台用业务侧的逻辑，每出现一个角色，就不仅仅是针对两个角色单独处理逻辑那么简单，中台的业务属性过强，逻辑将会非常的复杂，如果每个业务都有不同的角色，那就相当于为每一个业务都写了N套逻辑，那么中台存在的意义又是什么呢？

所以，抽象模型是在中台落地过程中非常非常重要的一个过程，是真正落笔写需求的大前提。往往中台产品经理的需求并不是针对某个功能而写的需求，而是针对产品能力模型而出的需求。

所以我们现在总结的方法论，不光是以抽象一个能力模型为目的的，更是以能够抽象出可复用的中台能力为目的的。

二、如何抽象产品模型

既然产品能力模型这么重要，我们应该怎么做才能输出一个抽象的可复用的产品能力模型呢？这里就介绍一些工作思路和方法，可以不断练习逐步具备抽象产品模型的能力。

前面推荐的《金字塔原理》这本书，非常详细的介绍了该如何锻炼自己的抽象能力。我们日常的工作方法也就是用本书所阐述的两个方法：演绎法和归纳法。

日常的工作注意事项就是：横向广度和纵向深度。

结合起来就是：结合演绎法和归纳法，横向挖掘所有功能，纵向将功能方案、逻辑、流程等深度拆解并重新归纳的过程，就是抽象产品能力模型的过程。

1. 演绎法和归纳法

演绎法和归纳法是贯穿整个工作全流程的工作方法，演绎法全称为演绎推理法，归纳法全称为归纳推理法。演绎推理法是指，人们以一定反应客观规律的理论认识为依据，从服从该事物的已知部分，推理得到事物的未知部分的思维方法。

比如说，前提结论“人是善变的”，你是人，所以你也是善变的。

归纳推理法是一种由个别到一般的推理方法。由一定程度的关于个别事物的观点过渡到范围较大的观点，由特殊具体的事例推导出一般原理、原则的解释方法。

比如说，世界上的人，用性别归类，可以归纳为男人、女人；用年龄段分类可以归纳为婴幼儿，儿童，青少年，中年，老年；用结婚与否来归纳为已婚、未婚。

关于归纳法和演绎法，我这里就只讲概念，更深刻的实践和案例可以看《金字塔原理》这本书，我这里重点讲一下归纳法和演绎法的运用过程，那就是：比较、归类、分析与综合以及抽象与概括等手段。

比较的目的是为了发现对象的共同点和差异点，然后再根据共同点和差异点进行下一步的归类。由于归类是建立在比较基础之上的，比较的过程已经将相同和差异区分出来后，让人更容易看到对象的全貌和细枝末节。

经过比较和归类后，我们需要对经过比较和归类的对象进行拆解性分析以及综合性组合。分析的过程就是把已经归类好的同类实体对象进行拆解的过程，将实体对象的诸多元素全部拆解出来后，看清楚元素组合方式、过程、原理后再经过综合的过程将元素进行重新组合。

分析和综合其实是对对象的内部结构进行比较归类的过程，目的是看清对象的内部构造，看到的是更加体系化的实体对象。

最后，对已经被摸清楚看透彻的实体对象进行抽象和概括，抽象的过程是找出整个实体对象最关键和核心部分的过程，概括就是在抽象出核心之后，将对象推理到其他对象的过程。

这里讲的概念性比较抽象，我们后面会以案例来讲解。

2. 横向广度和纵向深度

顾名思义，正如标题的字面意思所说，横向的目的是为了更广，纵向的目的是为了更深。

为什么要更广和更深呢？有一个中台大佬曾经说过：中台的能力就像是在漆黑的路上的路灯，我们要用尽量少的灯照亮尽可能多的路，就要让灯足够高，只有灯足够高了，才能照亮足够宽的路。

当我们还不具备直接树立一盏灯的能力的时候，我们就应该先看看路，看到了路再往高处抽象灯，就变得容易的多了。所以横向和纵向两个角度即是工作习惯和方法，也是工作目的。

其实有时候方法论不如熟能生巧的主观感觉来的有用，对于已经进入到感觉中的人来说，横向梳理功能时，看一眼就知道某个东西是可以通用可以拿出来做模型变成复用的，因为功能的深度处理方法和逻辑都是通用的，时间久了一下就能知道该怎么办。

但是在没进入到感觉中时，确实需要一些耐心一点一点儿的做梳理，挖的足够深，看得才足够透彻。
我为什么要在第二步说这个，是因为功能的拆解是最为麻烦和详细的过程，不但要从产品层面梳理，甚至要渗透到研发的实现方案中去，这样才能更好更深的理解它，也更有利于我们在抽象的过程中找到依据，找到更多可复用的维度。

3. 实战案例

为什么我在讲完基本方法论之后才来举案例，这不符合我惯用的写作手法啊，那是因为在广度和深度上结合演绎法以及归纳法，是贯穿在整个产品模型的抽象过程中的，在任何一个步骤举例都会显得节奏混乱，一个具体案例结合完整的工作方法的方式更容易展示全貌。

案例项目名称：周期性任务能力模型。

先看业务诉求。

在上图中，我们能看到在三个模块中都需要按照一定周期去执行某个任务。

（1）业绩考核周期

先定一个考核周期，在考核周期下针对导购的销售行为设定销售目标，然后每年都是按照这个周期去考核，目标数值也是相同的。在考核周期内每天0 点跑业绩达成数据，在考核周期结束时去跑业绩达成数据。

（2）创建导购任务

在为导购创建日常跟进客户的任务时，会规定哪些任务是在某个阶段内按周期循环的，比如今年 10 月 1 日-10 月 31 日是双十一预热阶段，要让导购每周都联系客户给客户推广双十一活动，并制定推广的目标值。在任务周期结束时去跑业绩达成数据。

（3）微客等级规则

这个大家就一目了然了，熟悉的同学都知道，这就是个规则和定时任务，按照约定定期去跑用户的等级条件值，然后看用户会属于哪个等级。业务侧期望每天 0 点跑一次，每天 10 点跑一次，每隔 2 小时跑一次。

上述业务大概描述清晰了之后，我们按照横向和纵向的比较、归类、分析与综合以及抽象与概括来执行。横向扩展方面，我为了举例简洁，在本文只罗列了业绩、任务、等级三个模块，但是实际上还有关系链、线索等其他模块。

这里简单介绍抽象归纳的思路过程：

（1）比较

我们可以发现：

• 都是在某一时间段内做一件事情，但是时间段有的很明确有的不明确；
• 都是在某个时间点做事情，比如每天 0 点，每天 10 点，每天 15 点…每周，每月，每季度，每年，每个整点；
• 做的事情分两类：复制某种数据，或者去按照某个约定跑某个数据的值。

（2）归类

这个案例比较明确了，大的模块就归类为：

• 时间段：永久类和固定类；
• 时间点：每天某个时间点类（0 点，10 点，15 点等等），按常规标准类（天，周，月的开始和结束节点）；
• 任务：创建数据类，执行定时任务类；

（3）分析与综合

时间点在时间段内循环，循环的规则也是周期模型的一个重要元素。

• 当时间段大于小时时，时间点可以每小时循环；
• 当时间段大于天时，时间点可以每天循环；
• 当时间段大于周时，时间点可以每周循环；
• 当时间段大于月时，时间点可以每月循环；
• ……

（4）抽象与概括

• 周期模型的主体包括：时间段，时间点，任务；
• 周期模型的边缘属性为：循环属性、名称属性；
• 以后可扩展逻辑为：循环的条件、时间点条件，任务条件等；
• 然后，因为小时、天、周、月的概念都是国际通用的，但是季度、财务年度可能是业务侧有自己的概念，所以需要业务提前定义的有：季度、年度的概念；
• 未来可以应用于每个定时任务的频率设定。

最后，用图形表示最终抽象出来的能力模型是这样的东西：

文档中整个模型需要阐述的需求内容包括这些：

至此，整个周期性生成和执行任务的能力模型就完成了，短期内的未来我们无论怎么加需求，都是在时间段、时间点、任务这个主干下增加玩法、类型、条件，都不会脱离这个模型。时间段、时间点、任务这三个东西，就组成了一盏明亮的足够高的灯，照亮了周期性生成和执行任务这条路。

最后我想说，本文为了比较好理解，举的例子都比较简单，一方面是为了读者容易理解，也为了我作为作者会比较容易表达。真正工作中一定会遇到比案例更复杂的情况，但是举一反三触类旁通是产品的基本岗位能力，需要对方法论多加锻炼并不断形成习惯，把方法论变成本能反应，就可以在工作中信手拈来了。

另外，中台是不断迭代的，就算中台是由非常牛逼非常了解业务的人来做，毕竟做业务的人和做中台的人也不是同一个人，很可能会出现业务的玩法在中台的预料之外的事情，那么中台很可能就会迭代模型或者更改底层设计。所以不能追求中台的产品模型一开始就是完美的，要有不断优化的心理预期。

作者：初愚，公众号：产品杂谈录

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

题图来自 Unsplash，基于CC0协议