一文管好中台产品日常工作

中台产品经理的工作多为接收前台业务线需求、抽象设计产品架构、处理各种线上问题，日常需求量大、工作琐碎，工作内容难以管理，价值难以量化。如何管理好中台产品的日常工作，量化体现日常工作的价值，成为每个中台产品经理都要思考的问题。

近期国内大厂都在争相学习亚马逊，通过文档来组织和管理日常工作，在周、月、季维度检查工作进度，用同一片文档承载了工作规划、管理、周报、月报、季报的职能，减少了管理者和一线员工的攒汇报材料的工作量，非常实用。

笔者结合自身实际工作实践总结出一套文档，用以管理相对成熟的中台产品的日常工作。但文档终究只是一种管理形式，以下分享关于中台产品日常工作和价值的思考，这些思考最终形成了文档的目录结构和文档内容的填写原则。

一、中台产品的两个基本特点

1. 中台产品服务于前台产品

中台产品可能不直接为业务人员或用户提供服务，但一定为前台产品提供服务，前台产品通过集成中台产品能力来为最终的用户提供服务，这意味着中台产品除了要建设带有人机交互界面的各类用户端、管理端外，还需要建设以 API/MQ/SDK/大数据 为产品形态的开放服务，以便前台产品可以通过 API/MQ/大数据 来集成中台能力。以下几个例子来进一步说明这个特点：

• 订单中台：在以电商业务为核心（例如京东零售、淘宝天猫）的公司里，一般来说都会建设订单中台，使用到订单中台的前台有淘宝APP、天猫APP、闲鱼APP、商家工作台、小二工作台等。一方面为了让这些前台产品I查询消费者或店铺的订单，订单中台提供了一组API；一方面订单中台为了能让公司内部的运营同学迅速排查异常订单的原因，提供了一个订单运维平台；另一方面为了让各业务线看到自己的订单量、交易金额等数据，订单中台将自身数据抽到大数据平台，大数据平台将订单数据加工成各类看板提供给各类角色。
• 账号中台：账号的注册、登录、密码修改能力是每个系统最基本的能力，企业通常期望通过一套账号为客户提供多种服务。例如支付宝、淘宝、天猫、咸鱼等APP公用一套账号体系，这些APP各自提供了账号密码安全登录、密码修改的能力，这些能力统一由账号中台提供；商家开放平台、商家工作台等PC端系统也公用一套账号体系，这些系统通过引用账号中台的单点登录SDK来为客户提供统一的登录页面；当账号密码发生修改时，账号中台发送MQ，各系统收到MQ后强制退出当前账号，要求用户重新登录。

2. 中台产品提供领域统一服务

中台产品针对产品所属领域，提供统一领域服务，统一领域服务意味着在中台产品的日常工作中可能要做两件事，一是如果企业里存在同类服务，那么应该想办法替代掉这个服务；如果中台产品内部针对同一个能力存在多项服务，那么应该想办法合并这些服务；这两部分工作就是消灭烟囱，是领域服务治理工作的一部分，最终目的是降低研发成本、提升支持业务的效率。这样说可能有点饶，还是以订单中台和账号中台为例来说明这个特点。

• 订单中台：公司决定依托于淘宝、天猫业务的订单模块建设订单中台，订单中台建设初期，闲鱼有自己的订单模块；订单中台建设两年后，开始想办法用订单中台能力替代闲鱼的订单模块，替代成功后闲鱼订单模块的产研资源合并到订单中台并做人员裁剪，由此节约了研发硬件、人力成本；订单中台建设三年后发现给淘宝、天猫、闲鱼提供的订单查询能力完全是三套不同的能力，需要各自升级运维，于是构建了通用的订单查询能力，将原有三套不同的能力的底层切换到通用能力上，这样就进一步提升了产品服务迭代的效率。以上中台产品的演变过程可以总结为「提供统一领域服务」的过程。
• 账号中台：账号中台建设初期，淘宝、菜鸟各有一套账号，使得商家使用两个产品时要创建两套账号，为了提升商家体验，账号中台合并了这两套系统，商家下的淘宝账号、菜鸟账号被合并到了一起，统一管理，最终菜鸟裁掉了自己的账号团队，并且将账号数据和账号权益统一托管在账号中台进行管理，即提升了商家体验，又降低了研发人力、硬件成本。

3. 实际工作应用

中台产品的这两个基本特点决定了产研团队的工作内容和工作方式，在月报模版中，「业务洞察」章节关注前台BP的产品规划，「产品广度价值」章节和「领域服务治理」章节关注领域服务的“统一”程度。

二、驱动中台产品工作的三股力量

1. 业务变化

在业务产品变更、运营流程变更等业务发生变化的情况下，除前台产品一定会随之变更外，中台产品也要识别是否需要更新自身能力，这里有几类中台产品，他们受业务驱动的路径大不相同：

• 基础型中台产品：例如账号、权限、打印、支付，这些中台产品支持的业务线范围非常广，但自身能力建设受业务影响一般比较小，因为基础能力几乎不因具体上层业务发生变化，例如支付中台，不管做什么样的电商业务，对于支付中台来说需要提供的支付能力总逃不过余额支付、借记卡支付、信用卡支付、货到付款这么几种。
• 单据型中台产品：例如订单中台、运单中台、商品中台、店铺中台，这些中台产品的领域划分就是根据业务交易或运营过程中的流程环节或涉及的实体来的，一旦业务诉求发生变更，这些中台产品的能力必然要随之变更，但这类中台产品一般不直接服务于客户或者业务，躲在前台产品的后面。
• 职能型中台产品：例如人资中台、财务中台、客服中台，这些产品严格来说不能算是中台产品，因为其本身已经服务了一个具体人群，但考虑到企业往往把他们定义为业务中台（业务中台的各职能部门服务于各个业务线），同时在系统架构上这些产品确实是服务于各个业务线的，所以也划分到中台里来。这些中台产品的建设一方面受直接服务的人群的影响，另一方面首具体业务线影响。例如财务中台，财务人员变更出账的规则，则财务中台肯定会发生变更，业务线人员增加了费用科目，财务中台肯定也要发生变更。

2. 用户之声

除了满足业务的诉求外，中台产品还需要在该领域内深度解决终端用户、前台产研、各级老板等各类用户角色的痛点/槽点，分为几块工作：

• 终端客户体验：前台通过集成中台能力来为用户提供服务，中台能力弱、服务不稳定一定影响最终的用户体验。用户对于终端产品的槽点一般也要通过IT团队分发到中台，例如用户抱怨无法按XXX条件筛选订单、不能使用余额和银行组合支付，这些可能是由于中台能力不足导致，如果是做ToB业务，则还需要特别注意KA客户的反馈，KA客户的诉求往往直指中台基础能力的不足。、
• 前台产研体验：影响前台产研体验的点一般为中台产品的能力完善度和接入使用中台能力的过程中的体验，翻译成大白话就是有没有这个能力，用起来方不方便。在这里特别要提到的是这个接入能力的建设，接入能力也是中台产品的一项能力，接入能力强，则各BP接入使用的成本就低，接入能力弱，则会造成比较差的体验，影响中台产品推广。
• 各级老板诉求：例如客服老板抱怨异常卡单太多，这说明中台的单据状态机和异常监控能力可能不完善；例如业务老板想做充值卡业务，则财务中台就需要建设余额支付相关的能力。老板的诉求其实可以归为业务诉求，但老板的诉求往往涉及多个中台产品建设大量0-1的能力，所以老板的诉求往往需要当一个项目来做，系统性地补充一批中台能力。

3. 研发预算

一般来说，在负责的领域服务范围不变的情况下，中台的研发预算应该不变或逐年减少，这与中台建设的终极目标——降本增效 是一致的。具体的：

• 建设初期：中台有大量从0到1的能力建设，这阶段的研发投入可能会在最初基础上有所增加；
• 建设中期：但是当中台能力建设两三年之后，中台产品的工作就在单纯的能力建设基础上增加了提升服务效率相关的工作——如何更快更好地服务用户，这个阶段预算就不再增加，或者说叫做业务增长但预算不变；
• 收益期：业务增长但预算不变的状态通常只持续一两年，此后应该看到中台建设的收益，包括人力和硬件在内的研发预算都应该逐年降低，通常这个阶段会进行领域服务治理相关的工作；

以上提到两个关键工作——提升服务效率、领域服务治理；

• 提升服务效率：一般指提升接入效率和需求吞吐的效率，其中，提升接入效率重在能力的标准化上和配套文档的完善性上，个人对于能力标准化的理解是同类能力只有一个或少数几个服务入口（服务入口指研发上的API或功能页面）、同一个能力的几个服务入口的区别清晰易懂、API等技术服务有清晰的SLA承诺、不同种类的问题有清晰的的答疑流程机制，配套文档的完善性体现在用户能通过文档对号入座找到想用的能力、能力有配套的使用说明、有常见使用场景的最佳实践；提升需求吞吐效率重在架构设计和研发过程管理上，架构设计得好则能低成本的拓展能力，不至于业务要一个什么能力就得重构系统，研发过程管理得好则可以提升研发资源利用效率，近年的敏捷开发过程即可有效提升团队交付速度和质量，但对产研任务拆解的要求较高。
• 领域服务治理：一般指烟囱治理和数据治理，其中消除同类系统（烟囱治理）能显而易见地降低研发人力、硬件成本，这在前文已经讲过；数据治理指的是领域服务内的垃圾数据清理（清理商品中台N年内从未上架过的SKU）、数据分级储存（将半年内的数据存储在MySQL内，半年外的数据结转到硬盘）、数据分层查找（近三个月内订单可在200ms查找到，近三年订单可在1000ms内查找到）等，这些措施能够有效降低硬件成本。

4. 实际工作应用

在月报模版中，以上驱动因素所带来的影响被体现在了「业务洞察」和「领域服务治理」两个章节中，「业务洞察」关注业务组织架构、业务产品规划、领导层的重点项目，并思考产品侧要采取的行动；「领域服务治理」章节编写领域内的烟囱、数据等各种“乱象”的治理目标和进展，治理过程是一个非常漫长的过程，在不同阶段设置不同的治理目标，通过3年左右的时间让领域内的服务逐渐变得整洁、高效。

三、影响中台产品设计的两个因素

1. 领域知识

对领域认知的深刻程度决定了中台产品设计的好坏，认知又分为理论和实践两部分。

1. 理论知识：一般来说一个领域的理论知识不随所处行业发生改变，例如订单领域关注交易要素的记录，其中交易要素包括交易主体、所购产品、交易地点、交易方式、交易金额、支付方式等，在零售、物流、金融行业都是一样存在这些要素。理论知识通过书籍、总结即可学来，学习起来并不是十分困难。
2. 实践知识：一般中台产品由在公司呆了3年及以上经验丰富的产品经理负责设计，这个产品同学在这个企业对这个领域的实践（踩坑）则形成了这家企业对这个领域的独特诉求，例如订单领域在零售行业中交易产品的是具体的商品，商品有库存即则可售，但在物流行业等卖服务的行业，则要考虑产品供给和产能问题，例如你想寄快递到新疆偏远村庄，一般快递是不支持的（产品供给问题），例如你想退货需要1小时内上门取件发现预约已满，因为快递员的数量是固定的，服务了别人就没法服务你了（产能问题），这就是订单领域在物流行业的特殊领域知识。

拥有理论知识后就可以设计出最基本的产品架构，拥有实践知识后才能完善出适用于这家企业的产品架构，切实解决企业业务问题。

2. 同行/竞品

常见的产品设计过程中就会参考同行做法或者竞品的做法，但中台产品因其“躲在前台产品后面”、“为前台服务”，出现了两个很有意思的现象：

• “市面上没有竞品可以参考”：例如订单中心，谁也不知道阿里的订单中心到底是什么样的，因此设计订单中心的时候几乎只能靠自己对于领域的理解和企业的实际需求来。
• “市面上的竞品没有可参考性”：每家企业情况不同，即便都是订单中心，两家企业的设计可能也是完全不同的。

这两个现象导致大多数产品经理在设计中台产品的时候只从企业自身需求出发，近乎闭门造车，他们忽略了同行企业在发展过程中的趋同效应，两家客户群原本完全不同的企业为了获取更多层次的客户一定会相互借鉴，因此同行现在拥有的能力虽然我们现在不需要，但在设计中却可以考虑到，以便将来迅速扩展出所需能力。另外市面上虽然找不到直接竞品，却能从同行的前台产品中推测出竞品的能力和实际，例如我们发现闲鱼的订单居然可以在淘宝中查到，由此推测订单中台同时具备B2C和C2C两种订单的交易能力。

3. 实际工作应用

在月报模版中，「业务洞察」章节的一个子章节就是竞品动态，一般写竞品新上的能力或运营政策、我方是否应该跟进。依据领域知识做出的产品建设规划则体现在「领域能力建设」章节中，并且设有「认知迭代」子章节，目的是不断驱动大家思考，加深对于领域的认知。

三、衡量中台产品价值的两个维度

独立的中台产品并不能为客户提供完整的业务服务，因此不能直接用业务的收入、交易转化等业务指标中台产品的价值。但不意味着中台产品与最终业务达成毫不相干，事实上，中台产品的好坏直接影响影响客户的系统使用体验，可以想见订单查询慢、账号被盗号会给用户带来多么糟糕的体验。

另一方面，前中台架构的初衷就是提升研发效率，因此一定需要衡量中台产品带来的企业效率提升。根据笔者实际的工作经验，将中台产品价值衡量维度拆为深度和广度。

1. 产品价值的深度

指的是产品创造了多大的单点价值，单点价值指的是单次使用你的产品和其他同类产品的差异，例如现在要新做一个淘特APP，直接使用订单中台和自建订单管理能力在研发成本、周期上有多大的差异，订单中台提供的订单创建、订单列表查询、订单详情查询等核心服务相比于自建服务的稳定性高多少。通常又可以从以下几个维度衡量产品价值的深度：

终端用户体验：前台通过集成中台能力来为用户提供服务，因此中台产品一定影响最终的用户体验。

• 技术类体验：如果前台产品通过API等形式使用中台能力，那么相应的指标是订单查询速度、订单查询成功率、下单速度等，这类指标一般由研发同学负责，但可能需要产品同学一起来优化（详见后文领域服务治理）。
• 产品类体验：如果前台产品还嵌入了中台产品的人机交互页面，或者中台产品提供独立的管理端供用户专门完成某种任务，那么相应的指标就与一般的工具型产品没有差异，常见的有完成XXX任务的体验、解决XXX问题的速度。

研发成本和效率：中台产品如果做不到降本增效，那就失去了做中台产品的最基本价值。

• 前台：通过接入中台产品，前台开发某个功能的周期缩短XX%；前台建设某类功能的研发成本减少XX%；
• 中台：通过优化中台产品架构/系统架构，需求交付效率提升XX%，研发人力减少XX，硬件资源减少XX；

企业成本和效率：有些中台产品会直接影响企业，例如财务中台的好坏直接影响出账效率和回款效率，风控中台的好坏直接影响资金利用效率和客户投诉率，这类指标就没有模版可言，完全取决于领域特性。

2. 产品价值的广度

产品价值的深度证明了产品创造价值的潜力，但只有大家实际使用你的产品了才能创造实际的价值，这点与典型B端产品是一样的。衡量产品在多大范围内创造了价值的角度有两个：

• 系统覆盖率：中台产品服务于前台，那就得衡量服务了多少前台，通用的指标有系统覆盖率 = 使用中台能力的系统数量 / 有该领域能力需求的系统数量，也可以按业务线来衡量 服务复用率 = 使用中台能力的业务线数量 / 有该领域能力需求的业务线数量，通过服务复用率可以看出我们需要与哪些业务线开展合作，通过系统覆盖率可以看出与各业务线实际合作的进展以及产品实际推广使用的进展。
• 业务覆盖率：最终产品应该通过服务业务创造价值，所以最终还是要看业务维度的覆盖率，通用的指标有 需求覆盖率 = 实际使用了该中台能力的需求数量 / 总的需要使用该能力的需求数量，单量覆盖率 = 该能力影响的单据数量 / 总单量。

系统覆盖率是纯技术视角的产品应用范围，通常来说应该通过提升系统覆盖率来间接提升业务覆盖率。

3. 实际工作应用

通过以上两个角度，结合实际领域服务，可以演化出多种指标，例如注册成功率、订单渗透率等，形成产品的价值指标体系，并持续追踪这些价值指标的变化，如下图示例：

在实际工作过程中，我们基本都是产品能力建设（深度）和产品推广使用（广度）两手抓，但每个阶段工作总有侧重点，一般来说将某个指标当做全年工作的北极星指标，每个季度每个人负责提升北极星指标下面的一两个子指标。所以在实际的产品月报中，只记录本阶段要优化的指标，并针对这个指标开展工作计划、进度追踪，具体格式如下：

特别的，我们单设一个章节来做认知迭代，很多时候我们都是边摸索边做事，并非有一个想法就一定能落地，所以一定要总结经验。在「认知迭代」中，针对产品当前的处境，设置几个问题，引导大家持续思考。通用的问题有：

• 现在的衡量指标是否合适，是否能反映产品真实的效率和体验?
• 现在的衡量指标是否合适，是否能反映产品真实的使用范围?
• 现在举措没产生预期效果的话，原因是什么？是否需要采取其他举措？
• 有哪些新的关键合作伙伴？
• 消灭XXX烟囱真的有价值吗？

根据实际情况还可以设置跟领域相关的问题，例如：

• 现在的订单查询速度够快了吗？
• 现在的账号中台接入过程够便捷了吗？

写在结尾

在月报模版中还有注解了诸多关于月报编写的技巧，、笔者个人习惯是 在同一个文档模板上每月产生一个文档（简称月报），文档中的模块的内容按照周、月、季度不同的频次更新，并且所有内容均由一线同学更新。在本文档实践后，不再需要一线同学写周报，笔者自己不用再专门写月报、季度工作规划，同时产品线纷繁复杂的工作也得到了有序管理，一线同学工作更加能长期聚焦到目标上，受益匪浅。

需要特别注意的是，文档中的表述都要简洁，写到关键的定性定量描述即可，没有关键信息模块可以空着不写，切勿长篇大论，稍不注意控制这个文档就会变得又臭又长，笔者建议控制在10~15分钟内能阅读完的篇幅范围内。

关于中台产品的建设规划可以看我的另一片文章《如何做好B端产品规划？这“一揽子工具”帮到你！》，祝大家工作顺利年年加薪！

本文作者 @彬哲 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！