当我们还不具备直接树立一盏灯的能力的时候，我们就应该先看看路，看到了路再往高处抽象灯，就变得容易的多了。所以横向和纵向两个角度即是工作习惯和方法，也是工作目的。
其实有时候方法论不如熟能生巧的主观感觉来的有用，对于已经进入到感觉中的人来说，横向梳理功能时，看一眼就知道某个东西是可以通用可以拿出来做模型变成复用的，因为功能的深度处理方法和逻辑都是通用的，时间久了一下就能知道该怎么办。
但是在没进入到感觉中时，确实需要一些耐心一点一点儿的做梳理，挖的足够深，看得才足够透彻。 我为什么要在第二步说这个，是因为功能的拆解是最为麻烦和详细的过程，不但要从产品层面梳理，甚至要渗透到研发的实现方案中去，这样才能更好更深的理解它，也更有利于我们在抽象的过程中找到依据，找到更多可复用的维度。
3. 实战案例为什么我在讲完基本方法论之后才来举案例，这不符合我惯用的写作手法啊，那是因为在广度和深度上结合演绎法以及归纳法，是贯穿在整个产品模型的抽象过程中的，在任何一个步骤举例都会显得节奏混乱，一个具体案例结合完整的工作方法的方式更容易展示全貌。
案例项目名称：周期性任务能力模型。
先看业务诉求。

文章插图
在上图中，我们能看到在三个模块中都需要按照一定周期去执行某个任务。
（1）业绩考核周期
先定一个考核周期，在考核周期下针对导购的销售行为设定销售目标，然后每年都是按照这个周期去考核，目标数值也是相同的。在考核周期内每天0 点跑业绩达成数据，在考核周期结束时去跑业绩达成数据。
（2）创建导购任务
在为导购创建日常跟进客户的任务时，会规定哪些任务是在某个阶段内按周期循环的，比如今年 10 月 1 日-10 月 31 日是双十一预热阶段，要让导购每周都联系客户给客户推广双十一活动，并制定推广的目标值。在任务周期结束时去跑业绩达成数据。
（3）微客等级规则
这个大家就一目了然了，熟悉的同学都知道，这就是个规则和定时任务，按照约定定期去跑用户的等级条件值，然后看用户会属于哪个等级。业务侧期望每天 0 点跑一次，每天 10 点跑一次，每隔 2 小时跑一次。
上述业务大概描述清晰了之后，我们按照横向和纵向的比较、归类、分析与综合以及抽象与概括来执行。横向扩展方面，我为了举例简洁，在本文只罗列了业绩、任务、等级三个模块，但是实际上还有关系链、线索等其他模块。
这里简单介绍抽象归纳的思路过程：
（1）比较
我们可以发现：

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

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

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

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

稿源：(人人都是产品经理)

【傻大方】网址：/c/1201b0M92021.html

标题：方法论|最实用的中台入门介绍（三）模型篇( 三 )