从0到1设计后台产品（三）：产品功能解构

在业务需求理解清楚后，就进入了产品设计的阶段。
那么如何设计一款后台产品，该当从哪几个方面去设计呢？我们先看一下一个物流运输管理系统大致的流程是什么。

功能域划分

功能域，指的是在知足某个业务流程时，将线上的操作流程拆分身分歧的功能闭环。

划分功能域是在产品设计的初期阶段比较主要的一个事情。
如果在产品设计的一开始就可以划分一个比较合理的功能域，在后面产品设计的时候，就可以按照功能域进行拆分设计，不同功能域之间以接口的办法进行对接。
这样一来可以减少系统的繁芜性，降落设计本钱。
二来可以减少不同功能之间的耦合性。
防止一个功能进行迭代或者优化就会牵一发而动全身。

产供销模式

功能域划分可按照经典的供应链产供销的思路进行划分；产供销在供应链中指的是生产、供应、发卖；指的是某个货色的完全的供应链体系。
这里供应链体系不同的是所通报的不是货色，而是数据或者某个流程的结果。
这种模式比较适宜操作性比较强的业务系统。

以是这里的产供销引申为：数据的天生部分，数据的处理部分，数据的末了经由系统系统流转产生的结果，也是其代价所在。

比如要设计一个大件货色的物流运输管理系统：

生产：货品/客户数据录入功能，车辆信息、司机信息的录入，城市信息/点位仓库的录入，运输操持的天生，我们可以将其划分为数据生成功能域；数据生成功能域一样平常来说属于最上游的功能域，以是与系统内的往来来往的交互不会太多，一样平常其他的操作流程都是从这里取数，反而与一些承载其他的业务诉求的系统有所交互，比货品/客户的数据可能是从仓储系统或者交易系统直接拿过来的数据，车辆信息、司机信息时直接从供应商系统拿过来的数据。
但是理论上说，它所有的逻辑都是向上耦合而不会向下耦合的。

供应：为了达到末了的结果的流程业务功能。
一样平常来说如果划分供应功能域的话，所划分的领域都是比较核心的领域，是紧张业务流程的承载。
对付物流运输系统来说，便是可以说是排线、装车流程。
以及全体的任务跟踪流程，包括实时运力的报告预警，车辆调度，在途跟踪，司机在此过程中的送货、签收、回款等一系列流程。

发卖：这块一样平常是已经完成了核心业务流程后所要拿到结果的部分，也是整套流程的代价所在。
对付物流运输系统来说，可以是全体用度结算模块，根据之前的所有的流程或者内容终极的一个产出。
向下流程的内容实在也属于这块的内容，比如物流任务完成后终极给财务系统，给交易系统的一个数据流转，也会放在这个功能域中。

进销存模式

还有一种思路是按照供应链的进销存的思路进行划分，这也是划分子系统的其余一个角度。

进销存指的是采购、入库、发卖这样的一个过程。
这种模式比较适宜逻辑繁芜，中台系统，或者中间业务流转系统。
与产供销模式不同的是，一个倾向于产出，通过某个办法天生数据，完成业务流程。
一个倾向流转，以自己本身的业务流程属性进行承上启下或者承接核心业务流程。

比如订单交易系统，可以采取进销存的模式。

第一：订单数据的产生来源是用户下单，以是产生订单的过程可以作为采购的流程；

第二：订单数据产生后，整体的处理过程，比如订单状态根据不同操作的流转、订单的算价等；

第三：订单处理完成后，对各个下贱系统的分发，可以作为发卖环节；比如订单在客服系统、CRM等系统中的下贱逻辑处理；

这些是我在平时事情中的一些总结，肯定还有许多业务流程没有办法按照这个思路去划分功能域，总之可以按照一个思路：功能域之外只管即便形成闭环，通过只管即便少的接口就可以知足不同功能域之间的数据流转，协作完成各个功能域之间的事情就可以。

主线产品设计

在划分功能域后，我们可以按照不同的功能域进行产品的设计，每一个功能域中都可以拆分为主线产品及非主线产品。

例如在物流运输管理系统中，我们已经按照产供销的模式将系统拆分了不同的子功能域，第二个子功能域是业务流程的处理，数据的处理部分，那么针对这个环节中，其全体核心的流程便是从物流运输管理系统中排线，装车，在途运输，签收回款这样一条业务流程的核心链路。

那么，该当如何去判断这条链路是核心链路呢？

可以秉承这逐一句话：这条链路跑通后，可这个子功能域的基本业务流程可以跑通，没有比较大的功能毛病；

有时候，我们无法确认哪些是核心链路。
接过来一堆的业务诉求，梳理了一个弘大而繁琐的产品流程；

在这条流程里面，我们可以进行梳理和拆解，这个过程中，我们可以遵照以下几个原则将核心链路梳理出来。

第一：业务闭环是什么

这个子功能域中，最开始的节点，和末了的节点分别是哪些；比如物流运输管理系统中，第二个子功能域的第一个环节是排线，末了一个环节是签收回款，或者司机返仓（有返仓环节的流程），那么可以确认的是，这两个环节一定是主链路之内的；

接着，通过这个链路今后推，往前推，直至将整条链路闭环。
比如排线后接下来的环节是关照司机，则这个环节也是主链路之内的；司机接单后进行装车，这样是从前今后推，直至末了的环节；

其余，为了担保终极的结果精确，我们可以从后往前再推一遍，比如末了的节点是司机返仓，那前一个环节是司机吸收到了货款，再前一个环节是司机到达客户现场进行送货；

第二：如果没有XX功能，该怎么办

对付某个功能我们实在难以取舍的时候，我们可以考虑一下，如果上线的时候没有这个功能，我们可以怎么做？比如如果没有内置导航的功能，司机可以通过高德、百度舆图的APP直接导航利用；如果没有装车后拍照留存功能，可以拉一个微信群，在微信群里面上传照片；如果没有排线功能，那业务数据将无法流转，无法给司机下发任务；以是哪些功能是主线功能，哪些是非主线功能，就显而易见了。

那么，为什么我们须要梳理出一个主线产品呢？

第一，后台产品是繁芜而弘大的，我们无法一口吃成一个胖子，就须要将功能拆解开来做，以是这个时候就必须梳理出一个主线产品；

第二，在产品线上跑起来之前，所有的设计都是空中阁楼，没有经由实际的验证，如果这个时候我们将产品设计的特殊繁芜，一旦个中某个环节涌现了问题，就会涌现船大难调头的尴尬局势；

第三：好多的功能，是业务没想清楚，我们也没想清楚的，只有产品真正用起来之后，才能之后这个产品须要什么，以是在产品最开始的阶段，当务之急是让产品先运作起来，然后再根据实际的情形决定后续的产品怎么去做；

非主线产品设计

非主线产品功能，即指的在某个功能域之内主线产品之外的功能，这些功能不会影响到主链路，但是如果加上这些功能可以让产品更加完善，更符合业务诉求。

比如我们在确定了物流运输管理系统中如果没有装车后的拍照留存功能，可以让司机通过微信群上传照片的办法进行操作；但是在主线功能上线之后，针对付每一笔订单都会用到的这个操作，这样的操作无疑就相称的繁琐了。
以是此时候的功能线上化就十分有必要了。

在已经将主线产品设计出后，非主线产品相对来说就会比较好设计一些。
设计非主线产品时，可以参考以下几个设计原则：

1. 主线产品每个环节的补充

在我们将主线功能中的排线环节设计完成后，排线所要涉及的其他点，比如运单天生后的打印，排线时须要先核对订单各个SKU的数量以及仓储数量，这些流程是依托于主线流程，或者主线流程的扩充的，完善主线功能的某个流程的。

2. 可以形成一个业务小闭环

某些功能可能根本就和主线流程关系不大， 但的确也属于全体业务流程之内的，比如在许多的物流运输管理系统中会将与司机签订条约的功能与放到里面；这个流程可以说是完备在系统中开辟了一个新的独立的业务小闭环，我们在设计的时候，要把稳做到最小可用即可，精力更多的还是须要放在主线流程及对应的非主线流程上。

数据功能设计

数据产品的设计中包括报表设计，数据仪表盘等产品设计。
这个功能可以说是后台产品的必备功能之一。
在设计报表功能时，须要把稳的设计内容有：

一、自上而下的设计，即这个功能因此管理诉求出发，基于不同的管理者希望看到什么样的数据来确定报表设计的内容。
以是一样平常需求的来源大部分可能是管理者，较少部分的情形下才为操作者，比如CRM系统中某个人须要看自己本日拜访了多少客户。

二、不同行业的报表标准都有哪些，在不同的行业中可能会有一些固定衡量的指标来确定某一次业务流程的结果如何，比如在物流运输管理系统中的提货定时率 / 到货定时率 / 货损货差率 /回单返回率 / 车辆装载率 等等这些比较标准的数据做成线上报表。

三、在设计报表的时候，须要在一开始的时候就把稳取数字段的设计，有时候在产品功能中可能不须要在数据库中新增一个字段来存储，但是为了后面报表取数比较随意马虎，最好还是可以在数据库中冗余一个字段。
这样在后期跑数据的时候一是可以减少开拓的事情量，二来可以减少跑数的韶光。

四、设计报表的时候，最好是带入到不同的利用场景中去设计，不能为了设计报表而设计。
所天生的数据一定要故意义，确切的用到某个地方才去取这个数据。

非功能性设计

非功能性产品紧张包括两个部分：

1. 知足降本增效的目的，在现有功能产品之上确定的一些产品策略

这些策略是为了让系统更加的坚实可用。
这个我认为也是之以是我们要将某些业务流程线上化的缘故原由，由于这些功能的存在，我们可以让原来繁琐的业务流程变得更加精简高效；

比如在我们将tms的业务功能产品已经做得足够完善时，须要考虑的便是这个别系可以如何更好的做事于业务，让业务的操作可以更精简，效率可以更高；这个时候我们就须要考虑一些人做不到的时候，比如排线策略，根据以往的排线数据，可以推算出某个订单的最优线路，在给某个司机进行派单时自动将最佳的订单进行聚合天生运单。
在司机装车时，根据货色的摆放原则（密度大的放不才方，易损的放在上方），先到后装（优先派送的放在末了装车），不超载等原则自动匹配配载的策略；

这些功能可能都是人为操作难以实现或者须要一个很繁芜的打算的，但是这些我们通过产品本身不断优化的策略，可以让产品变得更加完善和健壮。

2. 非功能性产品包括在业务流程之外的一些产品能力

比如一些管控诉求，关键节点须要某些职位的领导进行审批；如果是从0 到1在培植完成的系统时须要设计的权限系统，账户系统；等等这些内容，须要知足整体的产品闭环流程不可短缺的环节。

接口设计对内的接口

在上文中所述，设计产品的一开始须要划分子功能域，那么不同的功能域之间的能力即通过接口进行连接。
之以是通过接口进行对接，可以担保不同子功能域之间的耦合程度比较低，在进行功能迭代时，如果只涉及到某个功能域的改动，不须要全体链路都改造，只改造自己本身内部即可，只要对其他功能域所输出的接口没有变动，则对其他功能域无感知。

在设计对内的接口时，无需考虑到的点有如下：

1. 接口的调用频率，调用次数。
由于作为一个统一的系统，所有系统的技能能力都是统一的，完备的，这些信息更多的该当是技能去考虑的。

2. 同一个别系中，不同子功能域的主数据是同等的。
基于此，我们在设计接口的时候，就不须要考虑接口中过多的参数，如果一旦涉及到某个数据，只须要将表中的主键作为参数进行通报即可。
比如在物流运输管理系统中，供应子功能域须要生产子功能域供应被禁用的司机名单，以便勾选司机的时候将其置灰。
那供应子功能域只须要将司机ID给到，由供应子功能域直接去主数据中查询即可。

对外的接口

对外的接口，既包括对功能内部的不同系统的业务能力支持接口，也包括可能对外涉及的OpenAPI。
相对付对内的接口，由于这些接口是对外露出的，其他业务系统的能力不受本系统的掌握。
以是在设计的过程中会比对内的接口繁芜一些，设计时也须要更加的谨慎；

在设计对外接口的时候，须要考虑的点有以下：

1. 是主动调用接口还是推送接口。
主动调用接口指的是调用方由于自己的需求调用我方系统的接口，然后我方进行一定的逻辑处理后返回给调用方。
这种情形多见于调用方发起业务操作，比如TMS在于WMS进行交互时，如果TMS想要获取WMS中的货品数据，则须要主动要求WMS，将一定的参数（一样平常包括必要的条件，比如哪个城市、哪个订单，多少货）等传给WMS，然后WMS返回给对应的数据。

如果是推送接口，即我方系统由于数据变革或其他缘故原由，主动推送给调用方的办法。
比如WMS中某个货品由于不合格下架了，但是之前的数据已经推送给TMS了，这个时候就须要WMS主动推送给TMS。

2. 同步接口还是异步接口。
同步接口指的是进行数据通报时，吸收方将结果实时返回给调用方，接口一贯保持通信。
同步接口的好处为：信息处理比较及时，各个别系之间的操作会比较平滑。
缺陷为一旦数据量大的时候，接口随意马虎超时，导致数据传输失落败。
这种情形下，全体系统的操作相称于都被中断 。

异步接口指的是，我吸收到调用方传过来的数据后，前辈行逻辑处理，处理成功后将结果再返回给调用方，这种办法的好处和同步接口比较针对大量数据的处理有了明显的提升。
但是有一点，由于调用方吸收接口不及时，如果逻辑处理不好，很随意马虎涌现下贱系统数据连续进行，但是上游后面返回一个失落败的结果，这样就会导致全体系统的逻辑错乱。

3. 接口的调用频次和量级。
一个别系所能承受的压力是有限的，在设计接口的时候，也一定要考虑到系统接口所能承受的压力是多少。
这一点实在技能考虑的可能更多一些，但是对付产品来说，可能不同的压力承受值会对产品方案有所影响，比如某个HRM系统中，员工同步的借口一次最多许可传10000个员工，则我们须要考虑正常的操作链路中比如Excel导入是否也须要将操作限定于10000。

兜底逻辑、熔断机制

系统在运行的过程中，难免会由于并发量过大，系统bug产生一些问题，这些问题轻则影响业务的正常进行，重则直接宕机，丢失数据等严重的情形。
以是在设计产品的时候，要考虑到如果一旦系统产生问题，怎么样可以使产生的灾害降到最低；

兜底逻辑指的是由于某些不可预见性的问题，比如系统bug，产品逻辑没有考虑到等成分，发生了非常情形或者数据的情形下，系统应该进行的操作。
设计一个产品的兜底逻辑须要对这个业务十分熟习，并且有着自己比较精准的业务判断，否则会导致一种十分恐怖的情形是兜底缺点，造成了比原来更恐怖的缺点。

比如在物流运输管理系统中，由于司机早上须要发货，须要将所有的排线任务在晚上十二点之前全部完成，否则就会影响后续的流程。
正常情形下，规定排线人员必须在12点前完成，一旦由于排线员工自身缘故原由，或者网络非常，系统bug等无法完成排线任务，兜底逻辑会使系统则会按照历史排线规则自动分发任务。

熔断机制指的是如果某个操作系统剖断为非常业务流程了，那么急速会进行系统流程的割断，以免发生悲剧。
比如说某一套物流运输系统，通过测算给某司机发放运输任务人为时，由于系统问题或者操作失落误问题，本来运送5次该当发放1000元，实际发放了10000元。
这个时候，系统就该当设置一套熔断机制，设置某个操作的阈值。
比如1单配送最高金额为300元，则司机运送5次最多发放1500元，该套熔断机制检测到金额超过阈值，则直接将流程割断，并且将非常抛给系统管理员。

在设计一套繁芜的后台产品时，须要考虑的点可以说是方方面面。
上面是我关于在设计后台产品中设计产品方面的一些想法，接下来会先容一下后台产品的交互该当如何设计。

干系阅读：

从0到1设计后台产品（一）：给后台产品分个类

从0到1设计后台产品（二）：如何定义业务需求？

#专栏作家#

执迷，微信"大众号：执迷有悟，大家都是产品经理专栏作家，一个后台产品经理。

本文原创发布于大家都是产品经理。
未经容许，禁止转载。

题图来自 unsplash，基于 CC0 协议