中台产品经理方法论( 八 )


由于互联网公司多年来信奉的就是「唯快不破」,团队在做优先级排序时,往往会倾向于去业务价值最明显的事情,有很多重要不紧急的工作就被压在后面,永远没有再被提起过 。
但对中台产品团队需要有不同的要求,中台产品一定要保留力量始终去做一些基础的,重要不紧急的事情,就好像公司如果想要做得长久除了在商业上的持续投入外,一定要保留足够的人力来做基础性的研究,近期华为的海思芯片和鸿蒙操作系统就是最好的例子 。
我们在做中台时,无论外部各个业务需求的压力有多大,始终保持有一个小队始终在做基础组件和规范建设,比如在各套业务产品里的权限体系都还能跑,但某些功能始终无法完美支撑时,我们按照RBAC的方式进行一个新的角色权限系统的设计,并提供了数据迁移方法,也最后为新的业务模块功能开发打下了基础 。
(4)中台价值的量化
即使我们都认为一件事情是正确的,价值量化依然是最重要的事情之一 。中台是一个to B服务,本质是成本的节省和效率的提升,但由于中台的客户是内部业务产品的程序员,这个价值的量化就变得比一个给运营销售用的CRM系统要复杂了 。
中台是提供给多个业务服务的共享服务,任意一个中台服务被业务服务都可以为业务节省成本,因此被越多的接入整体节省的成本越大 。同时由于每个业务在整个事业部里都有不同的优先级,被高优先级业务接入的中台服务,能够产生的价值也越大 。这是符合直觉的,但如何去量化这样的价值呢?
提供以下的计算方法:

假设:
各个业务在事业部的优先级系数 = a1、a2、a3….
中台服务被某一个业务接入后给业务节省的成本(人天) = 业务自研此服务的成本 + 业务自己运维 – 业务产品接入中台服务的成本
可以推导出每个服务开发出来后对整个部门节省的成本是:
总体成本节省 = (a1 * 业务1节省 + a2 * 业务2节省 + …) – 中台开发成本 – 数据迁移(适配层开发) – 中台运维
由于中台团队要同时面对多个业务的需求,根据以上公式,我们也可以得出一些判断需求优先级的基本规则:
  1. 部门战略,也就是业务的优先级的系数 。显然来自战略级业务的需求优先级是高于其他普通业务的 。
  2. 需求靠谱程度 。这里面有包括两个层次:是否是核心的需求,是否是伪需求、提出需求的业务是否靠谱,是否可能很快就被干掉了
  3. 与中台目标自身目标的契合程度 。这也是很好理解 。中台不是业务的外包团队,中台需要有自己的思想和规划 。
需要说明的是,虽然有了这样的计算公式,但我们在实际的工作中并没有直接去量化每一个功能 。主要原因在于教育中台正式立项一年的过程中,团队一直在探索中台设计的套路,比如对如何才能较好的满足需求,快速的被接入,并且在运维层面对业务做到无感知 。
只有在搞清楚这些讨论之后,中台服务才有可能会对节省成本有明显的帮助 。因此量化只是少数几个团队核心成员做规划时参考,而没有直接做为产生的价值而公布出来 。
青山绿水,江湖再见从教育中台组的解散到今天,已经过去差不多五个月了 。在写此文时回忆起中台这一年,感慨万千 。
感谢两位主管Sunner和Genify,Sunner作为中台业务负责人和产品架构师,亲手搭建了整个教育中台的底层基础和业务抽象,包括「爱多思」在内的很多特有的名字都是他取的 。他是我直接的老师,他对爱多思能够成功的坚定信念是我在多次迷惑中也能坚持到最后的最主要原因 。

推荐阅读