中台建设方案

中台产品经理宝典 【刘天】 读书笔记

1.互联网颠覆变革的出现	互联网上半场和下半场	消费互联网	消费者个人
		产业互联网	企业
	产业发展规律	技术时代	生产工艺门槛、核心技术、垄断	引入期
			宣传：技术参数：16核、折叠屏幕、后置四摄
		产品时代	技术攻关掌握了技术打破垄断	成长期
			用户体验、满意度、口碑
			差异化、用户痛点
			产品人的黄金时代
			宣传：差异化功能，Opp品牌前置摄像头、锤子手机发短信确认等
		市场时代	产品差异化缩小、同质化严重	成熟期
			市场运作和产品分发能力
			更多的渠道、品牌运作
			上下游议价能力
		产业升级	重回市场时代
			最近的一次产业升级：4G、视频产业
			目前的互联网从产品时代进入了市场时代将迎来变革
			目前是一个市场相对饱和又缺乏创新的互联网环境
	业务模式特征	互联网上半场：前后台模式	增量市场
		互联网下半场	特征1：以企业服务为业务核心对象	存量客户，企业主体
				成本管理、优化供应链体系等
				子主题
			特征2：渠道中间商新价值	赋能渠道商与代理
				互联网企业不强调去中间化
			特征3：千人千面的业务	B端业务的现状
					非标准化互联网时代

3.中台化浪潮	中台≠微服务≠Saas
	产品微服务	解决代码量指数上升带来的高维护成本
		避免单个模块故障导致系统整体崩溃（单点故障）
		“大代码库”划分为多个“小代码库”
		业务拆分模块化	每个子模块自成体系，独立运行完整流程
			每个服务有通用的标准、输入、输出有清晰的边界
	Saas	软件服务	钉钉...
		中台目的是提高企业自身研发效率，不给客户直接提供服务
	什么样的企业需要中台	公司的发展阶段	是否支持腾出手来支持基础服务的建设？
			如果是努力抢市场阶段则不适合，生存第一
			两类企业适合	初创企业
				业务线复杂企业
		公司战略目标	是否聚焦本行业
		公司业务线	是否业务发展到一定程度？
			是否沉淀了一定量的IT资产（数据、业务流程、运营模式）
			是否已验证符合市场需求的最优解？
		评价指标
		总结	多条产品线	提取成功经验
			有功能成熟 盈利的产品 已被市场验证
	中台发展趋势	芬兰Supercell游戏公司（阿里巴巴201）	9名员工开发了多个爆款游戏产品	统一支付网关、算法引擎
				统一SDK、素材、模型
				搭积木方式开发
		国内中台先驱：阿里巴巴	小前台+大中台	一处研发、多处使用
			2008年共享平台事业部
			大中台：统一提供服务的部门做大做强
			小前台：让业务部门少研发，技术团队变小
			案例：阿里一年立项近百款产品、上线十几款
		腾讯	2018成立技术委员会
			七大事业群+技术委员会
		中台产品的发展与演进	三个阶段	共享代码平台
				共享服务平台
				共享能力平台
			中台产品分类	技术中台
				业务中台
					数据中台

5.中台建设路径	中台是企业信息化建设纲领
	市场宏观认知	企业外部调研（行业研究）	行业高度进行业务规划
			对下一步业务的预判
		企业内部调研	商业模式、用户调研	避免成为业务线的外援开发团队
	企业标准化	企业管理流程标准化（各业务执行环节程序化改造）
		各业务线执行环节有可量化的指标（透明化）	案例：客户拜访
		中台建设是互联网企业内部的一次管理升级
		梳理业务需求与数据需求
	解决方案设计	业务建模	核心场景剥离
			核心业务拆解
			模块组合打包（功能合并、合集）
			基础服务确定
			中台能力输出
		特征列表	建立特征列表
			分析共性部分
7.业务标准化	组织结构中台化改造	独立中台研发团队
		反例：矩阵组织架构	人员灵活调配，频繁切换业务组
			大大提升人员重新认知的时间成本
		中台团队	定位：公共事务研发
			中间件、自动化脚本、数据库查询等工具研发
			撇开繁琐的业务需求，专心研究技术平台、如何提高性能等
		前台团队	负责一线客户需求
			目标：实现业务目标
			较少考虑性能
	业务流程的中台化改造	产品经理	应站在公司角度对各条业务线进行一个标准化梳理
			做到对公司各项目心中有数
		业务抽象归类	泛产品架构分类（整改公司视为一个产品）
			产品=产品主体+产品推广标准流程+运营后台
			运营后台=产品运营反馈循环+推广运营反馈循环
		业务量化	整个业务进行考核指标的设计
			实现数字化运营
			找到企业数据中台的监控目标
9.现有业务能力抽象	各产品在产品线中的定位	流量获取
		流量留存
		流量变现
	各产品用户群情况
	5W1H分析法	对象（What）	6个问题梳理公司各产品功能矩阵
		目的（Why）
		场景（Where）
		时间（When）
		用户（Who）
		方法（How）
	业务中台化抽象	拆解模块	拆解公司所有产品功能模块	提取共性
			避免漫无边际地将各个应用任意需求加入中台
			站在全公司视角思考解决方案
		动作分析法	事件
			动作
		案例1：登录	事件	本人校验事件
				个性化配置载入
				进入页信息灌装
			角色行为	登录用户
				业务系统
			动作	每一次操作
				输入信息
				点击按钮
		案例2：地图应用	用户中心	高频模块剥离
			位置管理
	中台方案架构	中台立项
		产品画像	最忌讳：成为业务线的外部中心
			排除大而全的设计
		通道设计	如何判断共性节点
			管道理论	统一各模块不同的输入、输出
				建立起统一的向外通道
11.数据中台设计实战	闭环产品体系设计
	建立数据运营中心	公司级用户画像
		整个公司的交易量变化
		公司核心指标发展情况
		横向纬度分析指标
	数据采集埋点	粒度太细（资源消耗过大）
		粒度太大（无法具体定位问题）
	阶段目标	层级1：战略指标	GMV、用户数、总利润
		层级2：战术指标	业务进展
		层级3：行动指标
	指标体系	OneData	指标类名词规范
		OneID	打通用户体系	建立用户画像
				数据监控
后记：优秀的产品经理是什么样的一群人	M-P能力模型	M（Market）部分：市场运作能力	A.需求翻译	需求变为设计
			B.项目管理	按期交付
		P（Product）部分：需求生产能力	C.市场推广	触达用户，占领市场
			D.商业变现	实现商业目标
	能力层次	战略型	ABCD
		筹划型	ABC
		高级执行	AB
		低级执行	A
	优秀的产品经理	掌握了M-P模型偏市场能力
		能以大局观看待整个产品
2.为创新而生：中台战略	2019中台规模化元年：腾讯、美团、字节跳动
	基于“前后台”架构演化而来	项目初期是较为省时、省事的一种架构
		建设中不需要考虑系统的扩展性，有很大的自由度
		反而节省研发人力
	前后台模式的根本弊病	现有产品模式由：标准化产品变为以用户为单位的定制化产品
		快速迭代、落地终端，软件生命周期变短
		案例：电商APP版本迭代周期为6个月。而某AO系统每2个月一次大迭代
		这样就暴露了前后台模式的根本弊病：响应速度太慢
		生产流程:烟囱式架构	资源和信息孤岛
		大量底层支撑部分建设与等待时间：对用户而言为无效工作
		用户能感知的在于前台，不为系统底层架构建设而买单
		举例：新项目建设	前端重新设计界面
			后端重新设计服务接口与数据表
			新业务从底层工作开始，底层重复建设
		新的解决方案	最少改动底层或只开发上层从而满足绝大部分的需求
	前后台模式向下发展的瓶颈	公司内外发展冲突	公司外部需要快速迭代
			内部每次迭代都需要伤筋动骨
		前台+后台的齿轮速度匹配失衡	匹配新业务不断增加新模块，系统越来越庞大
			无法满足前台业务所带来的改版，无法按时上线
		公司内部的二次统一	管理性名言（战斗力、二次统一）	组织架构统一
				思考角度上统一
					反例	每个产品线圈地为王
			每个部门决策只从本部门利益出发
			每个团队互相隔离、不同事业部重复建设
			需要时跨部门多次对接
			中台的出现可以说是互联网企业在管理学方面的集体提升
		揭开中台神秘的面纱	做菜案例	对接简化作用
	前后台模式架构
	中台业务架构
	核心本质		前台业务提供服务共享
			目标	前台业务规模化创新
				或大规模试错
			高速增长的企业值得借鉴中台的思路
	中台解决方案的定义		能力输出	核心竞争力？战略目标
				提炼共性模块
				归到中台统一建设
				为不同的前台业务提供可以重复使用的能力，形成一次建设、多次使用
				将功能抽象为能力
					避免过度建设
				标准化中间件		定义统一化的输入与输出
					统一通用属性
			中台方案的威力			大幅降低边际成本	量产摊薄前期投入成本
						提升内部服务的复用能力	公司核心力量聚集，覆盖全公司
				进阶开发由公司技术带头人负责
				最优解通过中台同步给全公司基础员工（技术中台）
	举例：数据库访问
	统一管理
	提供全局化视野和全量数据模式			公共数据池
	提升应用的TTM			统一各项目共有部分
					统一用户感知	不同项目发展长短不一，品质不一
						案例：不同项目的登录界面
	不良现象
				使用中台登录组件
	4.C端和B端各需要什么样的中台					C端业务	流量红利衰退
				精细化运营
				建设目标	满足细分用户的偏好
					快速创新、高频试错提供支持
			B端业务	帮助企业更好地经营自己
				B端产品的两个误区	唯日活论	追求高净值客户，不是用户数量
					虚荣指标	指标不能指导产品达成商业目的
				B端唯一评价指标	营业收入、利润
		ROI（投资回报率）
个性化需求控制以ROI为导向
功能可配置
MVP：低成本快速试错
6.宏观市场探查	宏观市场分析	产品经理角色的转变
		分析通用框架	宏观经济趋势（定性）
			产业发展趋势（定性）
			行业发展现状（定量）
	中台用户研究（业务线人员）	用户研究方法	用户访谈	和业务线产品、运营长时间深入交流
					情景访谈	模拟真实用户某个场景
					问卷调查	终端用户
					研究行动点	圈定研究人员	产品经理、运营、项目经理、公司高层
			设计研究问题的大纲	设计与未来中台使用者的对话
			中台访谈计划表	第一轮：业务熟悉访谈	输出
		第二轮：公司IT资源方法
		第三轮：高层目标访谈
		8.设计成果中台产品的核心原则	原则1：独立的中台研发团队	兼任的弊端	抽象层次和深度不够的问题
					无意识按照该产品线的业务进行设计，让中台失去意义
				高管的介入	协调各业务线放弃自己的部分利益
打破原有的利益格局
与业务线建立沟通机制	发现高频需求
	各业务线周报机制			当周的版本计划
				版本中重要功能
				下一阶段规划
原则2：中台建设需求边界管理	模块改造		复用化	剥离特殊部分
			标准化	业务线统一操作对象
					能力化	接口化
			需求的边界	业务需求	输入、输出
	数据需求			描述数据、评价指标
	两种建设模式		自上而下	拆分中台
				覆盖匹配各业务模块
				A系统的功能B系统可用
				得出全量功能
				改造B系统模块
			自下而上	归类现有各业务系统的模块
				向上统一抽象出中台架构
	10.业务中台从0到1建设路径（解决方案）		企业架构	管理业务生产各个要素之间的关系集合
分类		业务架构		运营模式
				组织结构
				生产流程
		IT架构		内部管理运营系统
				数据架构
				应用架构（产品）
				技术架构（代码）
作用		部门配合统一协调
		决策依据
		创新
		提效
		降本
企业架构与中台		属于IT架构层面的产物
业务中台建设的启动		建设模式	分布替换式建设	对业务系统模块一个个改造
				优点：逐步抽象
				缺点：建设周期长
			完整式建设	独立建设中台
				启动新项目沉淀原有业务
				业务系统前台保持不变
				前后台接口调用替换为中台
				优点：独立项目快速迭代
				缺点：用一套系统翻新所有项目，建设成本高
		中台用户优先级	第一层级	利润、市场占有率“双高”
			第二层级	利润低、市场占有率高
			第三层级	“双低”创新型业务
业务中台建设路径		公司全景功能地图	业务线+产品+功能
		功能相似度确定	通道数：模块的输入输出信息
			相似度=（相同的输入通道数+相同的输出通道数）/总通道数
			评价复用次数	复用次数高则中台化优先级高
		核心业务能力抽象	通用流程而非业务线中的公共需求堆砌
			从企业的业务出发设计一个大体的模块架构
			提取公司级核心业务流程	电商平台案例
					企业级数据模型搭建	业务线反馈：格式不一致问题..
						抽象方法
							去重
			企业级数据模型案例 179
				业务中间件研发 181			解决数据内容不一致无法统一存储的问题
						字段剥离
			对接后台业务系统
			最终架构 184
			中台需求管理	原始需求
				关键要素
					管理技巧
				业务中台路线图		开发流程
							对接流程
								业务中台建设KPI	指标1：模块复用率	复用率高的留在中台
					复用率低的放回业务线（中台不再维护）
			指标2： 业务开发TTM		软件从立项研发到上线的时间（成本）
					节省的开发人天=原模块研发所用人天-中台化研发该模块人天
				被使用的产品越多，则节省的成本越多
				总成本节省 = （业务1节省成本 + 业务2节省成本+...） - 业务中台开发成本 - 业务方迁移中台成本 - 中台系统运维成本
			12.技术中台实战设计	技术中台体系架构	技术前台	核心价值体系在对业务逻辑的理解与实现上
						技术开发能力标准要求低
					技术中台	承上启下的中间层
						对下封装复杂的实现逻辑
						对上提供统一化工具
						技术能力标准要求高	性能调优
							打磨技术工具
								将技术能力和业务能力分离
								技术中台原理	一个独立单元只完成一件事情
					业务线切割后的事件已封装为服务单元
				中台拓展、能力增多	业务线需要自主研发的就越少
				如何搭建技术中台	SOA	微服务	将业务拆分成独立的模块，每个模块独立上线运行
	注册中心	统一管理微服务，向各业务线提供微服务模块运行信息与地址，动态获知服务的更新
	部署运维	K8S
		Docker
	技术实现定义：中台实际就是将每一个复用的模块作为一个独立的应用进行开发与上线，再通过服务调度来实现复用