中台产品经理宝典：业务标准化与能力抽象（第四篇）

导读：本书偏重业务中台的讲解，第1-4章介绍中台的发展历史、现状和内涵。第5-10章详细阐述业务中台的设计和建设全过程。第11-12章介绍数据中台和技术中台，但这两章偏科普性质，且有不少的偏误，建议研究数据中台和技术中台的读者另寻它本。总之，本书对中台的概念有较好的解释和比喻，可以作为中台的入门读物。

第7章 预建：业务标准化

7.1 组织结构的中台化改造

• 初期电商公司组织架构的弊端
  • 公共测试部在多条业务线之间切换，学习成本较高，测试速度较慢。
  • 伴随业务线独立发展的技术团队在完成相同的业务时可能选用不同的技术组件和实现方法，导致同样的功能在稳定性和迭代速度方面截然不同。
• 中台研发的组织架构
  • 将测试等只能部门划归业务线，从而让前台拥有一个完整的开发（仅负责开发前台个性化需求）-设计-测试的生产团队。
  • 与原技术人员协商，将其负责的一些公共模块下沉给中台研发人员进行开发，从而让整个公司的中间件、自动化脚本、数据库查询等技术工具统一由中台团队开发和维护。
  • 中台的定位：负责所有的公共事务研发。
  • 将研发人员分为3类：
    • 前台业务研发人员：响应一线用户需求，较少考虑系统性能。比如修改按钮形状名称、新增个性化业务模块等。
    • 中台研发人员：负责维护工具，优化工具的性能提供给前台使用。
    • 后台研发人员：底层物理机管理与支持、技术架构选型等。

7.2 业务流程的中台化改造

• 业务流程的中台化改造：是指将业务中我们要进行的而各个环节找寻出来，从而将一个非常抽象的业务定义为若干个标准动作+关键节点所组成的程序化流程。以向餐饮商家推广外卖系统为例。
• 第一步：业务抽象归类。根据泛产品架构，任何一个产品都是由研发产品主体和市场运作两者协作完成的，即任何产品涉及的业务都可以归类为这两个部分，实际对业务归类时会更加细分，比如线上运营业务。
• 第二步：业务程序化。这一步强调对业务动作的规范化，比如将【线下地推】这个推广业务进行节点标准化拆解，如下图所示。

7.3 业务线的核心公式

• 完成了企业内部业务标准化后，需要寻找一些数据指标对业务进行考核，同时也是数据中台的监控目标。
• 例如，在上面的例子中，地推人员的成单率=（客户线索数*转化率）/客群总数，可以监控这个指标、其衍生指标、达到该指标阈值的时间等。

第8章 设计成功中台产品的核心原则

8.1 原则1：独立的中台研发团队

• 独立中台研发团队的意义：
  • 兼任型研发模式的弊端在于当团队对业务进行抽象建模的时候，会无意识地参照当前团队业务进行设计。适当地参考是有益的，但完全按照单一业务线的发展规划去抽象就会导致中台业务抽象的深度不够。
  • 当多条业务线对同一场景由互斥的需求时，独立中台团队能够选择更符合企业整体利益的办法，而不是忠于某一条业务线。
• 中台研发团队的人员组成：
  • 高管：负责中台大方向定义与公司资源协调。
  • 中台产品经理：负责中台业务范围定义并确定项目演进方向。
  • 中台技术人员：负责落地中间件服务的开发实现。
• 中台研发团队需要与业务线保持动态的、定时的沟通，比如利用周报机制获得业务线当前周版本计划、版本中的重要功能、下一阶段的规划功能等3个部分。

8.2 原则2：中台建设需求边界管理

• 中台建设的3个方向：
  • 复用化。对某个具体业务的模块，剥离其特殊部分，使其变成一个公共的、与业务独立的模块。
  • 标准化。将中台的公共模块与之前调用的业务模块进行内部统一，把包括模块名称、对象、属性、类型等。
  • 能力化。设计公共模块的输入输出接口，方便前台调用。
• 中台需求分析的2种模式：
  • 自上而下：通过分析公司现有业务向下拆分中台应该覆盖哪些模块。优点是可以精准地进行需求分析，找准模块的核心特点，缺点是性价比低，不建议使用。
  • 自下而上：通过将现有业务中的各个模块不断进行归类，从而向上统一抽象出中台架构。实践中常用这种模式。

第9章 现有业务的能力抽象

9.1 中台业务场景分析：动态产品画像

（1）产品在产品线中的定位

• 产品线：是指为达成企业某一目标的多个相关需求解决发难组成的集合，产品线可以由多个产品组成，也可以由多个功能模块组成。
• 产品线布局：三级火箭理论，即将一个商业目标拆分为多个子目标，再将子目标交由不同的产品去执行，最终实现核心目标。
  • 第一级：流量获取，通过给用户补贴抢占市场，建立起稳定的流量供给渠道。
  • 第二级：流量留存，将用户沉淀至可拓展的高频商业场景中，实现产品方向的演化。
  • 第三级：流量变现，推出核心付费环节，开始盈利。

（2）产品的用户群

• 确定用户的核心价值指标：例如，产品刚上线阶段，用户的核心价值指标是产品体验度（引导用户达成指标）。发展一段时间后，核心指标就是付费。
• 判断用户群的状态
  • 若【新增用户数】>【流失用户数】，产品处于高速增长期，用户体量保持增长态势；
  • 若【新增用户数】=【流失用户数】，稳定期，需要寻找新增长源；
  • 若【新增用户数】<【流失用户数】，下滑阶段，此时最重要的是拉新与留存。
• 判断用户的生命周期
  • 用户感知：例如通过线下广告投放使用户感知产品。
  • 用户转化：游客转变为本产品的用户，例如完成下载并进入应用。
  • 用户核心事件触发：例如对于社交类应用，完成添加好友并发送消息。
  • 用户留存：用户持续使用该产品。
  • 用户流失：用户未访问时间超过流失周期。
• 我们的目标是：让用户在不同的产品层级进入对应的生命周期，例如在产品的第一级【流量获取】阶段，我们需要用户进入【用户转化】周期；在第三级【流量变现】阶段，需要让用户完成【用户核心事件触发】。

（3）评估中台需求的优先级

• （逻辑混乱，思维零碎）
• 快速熟悉业务：5W1H，共6个维度24个问题。
  • what：当前公司生产什么产品？
  • why：本产品要解决什么问题？
  • where：用户场景是什么？
  • when：用户何时使用本产品，占用用户的时间是多少？
  • who：主要的用户群体?
  • how：如何实现需求？
• 根据5W1H的回答整理一份产品功能矩阵图：可以用来评估中台的需求优先级
  • 核心功能：留存高，活跃高。例如，主流程功能，要吸收到中台架构中。
  • 通用功能：留存低，活跃高。一般是流量关键入口，但留存不高说明有改进的空间。
  • 其他功能：留存低，活跃低。不纳入中台建设，业务线自己负责建设。
  • 个性功能：留存高，活跃低。酌情考虑是否纳入中台建设。

9.2 业务中台化抽象

• 产品功能模块拆解✨：动作分析法，即用户为完成某个事件需要在应用中做出的动作集合，简单来讲就是 分角色的动作流程图， 下图中展示了2个事件、2个角色和5个动作。
  • 划分事件：例如登录流程可以被拆分为：用户输入账户信息事件、校验账户信息事件等。
  • 区分角色：事件中交互的所有角色，比如一个校验事件涉及登录用户和软件系统两个角色。
  • 划分动作：动作是用户在应用内的每一次操作，例如点击输入框、敲击键盘等动作组成一个行为。

• 统一输入输出：模仿微服务的做法，将每个角色动作的输入和输出进行统一，例如【账户信息输入】的输入统一为”10位数字的用户账号和包含大小写数字的8位账户密码"，输出为结构化（json）的账户信息，送去校验系统进行校验。（管道理论，将每个模块各个节点的输入和输出进行统一，从而建立起通过一的向外通道设计）
• 对于热点功能模块，业务线之间对模块的需求可能是互斥的，此时中台应该首先根据“变现的业务模块为基准，其他业务线的需求都向此靠拢”。

9.3 中台方案框架

• 第一步：中台立项
• 第二步：产品画像
• 第三步：通道设计。基于管道理论，对节点输出的信息流进行归类，当有多个节点输出的信息流相同时，就可以进行单独抽离，填入节点信息流统计表中，并据此判断节点是否为共性节点，将共性节点纳入中台建设成为企业的公共服务。

模块	信息流	重叠次数
用户中心	账号信息	4
司机中心	司机信息	2
支付中心	账户信息	2

---

To be continued…