写在前面的共识基础

为了方便后面的内容展开, 我们需要理解几个基本的道理.

故事的开始: 小而美的小作坊

很好理解, 一小群人, 一小撮系统(很可能就是一个), 干就玩了。

自然而然的早期增长

如果"小作坊"试点成功了, 我们再多干几单就是了. 事情多了, 队伍再大一点, 研发也简单, "再加点功能呗"或者"抄就是了"

然后发现点"小问题"

1. 系统有点大了,

2. 好像有点重复了

于是...

平台出现了: 拆! 合!

这个问题容易呀, 咱是科班呀, "抽象"懂不懂, "复用"懂不懂, 咱"优雅"起来最讨厌"复制粘贴"

分一分呗:

1. 重复的事情, 我们合并下, 搞个平台, 我们大家都能用. 对了, 人也是, "专业的人干专业的事"嘛

2. 其他小伙伴(蓝色), 咱们继续冲, 在业务的第一线(简称"业务线"), 去服务客户, 去做产品.

"平台"怎么 run 起来?

系统和人都分好了, 我们怎么合作呢?

容易:

他为啥能快的呢? 嗨, 还不是小作坊的底子.

好呀, 那给我来个 10 倍增长.

貌似又难受了...

"冰糖葫芦"/ "收费站"问题来了

去过些大厂, 带个大项目, 你可能就有感觉

"群太多了"

"会议太多", "要拉的人好多"

"链路长", "平台人不够, 等他们排个期"

是的, 系统越来越多, 链路越来越长(冰糖葫芦), 人越来越多, 合作好难(层层找人,像"收费站"), 这到底是为啥呢? 还是前面说的, 不再"小而美"了.

问题的本质: 认知负荷超载

1. 系统复杂度: 人的知识有上限, 超人没那么多

2. 业务(信息)复杂度: 业务花样越来越多, 不搞花样, 就要输了

3. 协作(人与人)复杂度: 信息传递

一种可能解法, 叫"中台"

是的, 信息瓶颈的问题解法很多, 其中一个方向:

1. 提升知识抽象层次, 产品赋能, 解决方案输出.

"我就是开个车, 不需要学热力动学", 搞个开放区(绿色部分), 包装个门面.

业务线(人员)和平台线(人员)都能搞得明白的, "大家都能搞"

1. 打破(融合)系统/组织边界

对于"门面"部分, "没啥你的我的, 都能上"

中台的基本运作原理: 解耦

这套机制会出现两种横竖型的项目

1. 业务型项目, 就是要快速交付业务结构.

2. 平台型项目, 就是把平台的做的"深入浅出", 给上面"标准化"的能力, 理想的情况, 是让上面的人自己去"搭乐高", 下面的人把积木造的专业.

注意: 这里没有区分技术/产品经理/测试职能, 严格来说, 每个阵营(红蓝绿)都应该有各个职能的成员, 才能完整完成交付.

所以核心原理还是一样, 本质还是形成小团队

那要怎么做到"中台"?

思路 1: 偏技术流, "新平台"

起点一般是以技术架构, 搞个"中台系统", 把下层能力原子化, 标准化, 然后在中台系统, "重组编排", 听上去有点像个"业务工作流引擎(BPM)".

但是这套东西, 还不只是一个技术型, 因为要给上游"非专业"非平台的技术人员, 产品人员看到, 所以还有一趴配套的规范/机制, "可视化"展现的东西. 总之, 要让蓝色阵营(或者说任何阵营,新手)都能快速上手,自助搞定.

一般来说, 这个过程, 是由红色阵营发起的, 打算把"专业"的东西"搞个简单可视化"的内容出来.

行业黑话, "aPaaS", 不过具体名字, 可能在不同厂内叫法不一, 总之听上去很高大上.

不过嘛, 貌似过程有点艰难

感觉系统总是建不完:

1. 想要的多呢, 工作流, 可视化, 可测试, 灵活发布. 工作量大了, 那消耗就多了.

2. "标准"貌似总是定不完. 每个人一个说法, 每个团队都讨论过"什么是产品","什么是服务", "什么是能力".... 还要有全局的权威拍一拍, 定个啥标准. 过段时间再优化优化, v1.0, v1.1, v1.2....

3. 定了标准,有了系统, 还要往里搬内容不是, 历史系统,历史知识, 重组,迁移都是巨大的工程.

总体来路,这个是漫长的路, 越大的公司越需要这些机制, 然而工作也越艰巨好大.

思路 2: 先从人入手, "共建吧"

等系统是来不及了, 业务也是不等人的("需求倒排"咱都懂), 那赶紧先上吧.

上面(蓝色)人多,也着急,就派人下来, 帮平台快速改造下.

下面(红色)的人也不放心别人来设计方案, 修改系统, 也出了人,"把控"/"扶持" 上面的人.

这种方式比较实干, 人动要比系统动更快.

这种模式运作下去, 其实可能出现的一种情况是, 出现新的角色(绿色), 是种赋能型团队, 用这种"专家"的能力和知识来帮上面解决问题, 产出解决方案; 也牵引下面, 别让下面闭门造车.

风险:人能动, 是优势也是风险

因为人嘛, 学新东西是不排斥, 但是总有个度, 临时借调还好, 长期战役状态, 吃不消了, 压力大.

• 上面的人过来的人(蓝转绿), 在别人地盘上干活, 管理/情感/考核等方面都比较难处理. 常见的双线汇报/虚线汇报, 其实也都是比较模糊的解决这个问题.

• 下面的人来辅导(红转绿)

这些原因导致的可能结果, 就离职走人了, 团队就出现很大的稳定因素.

两种思路, 其实是殊途同归

还记得前面说的康威定律吗, 组织(人)和应用架构/业务结构, 最终都会趋同.

所以面对的都是各自成熟度提升:

1. 成熟系统

历史负载, 架构重构, 标准的持续更新维护难

2. 成熟人员

人员培养难跟进信息增长

小结: 对抗增长的复杂度很艰难,没有银弹

不管大家是否主观愿意, "中台"(可能这么叫, 也可能换个名字)都会在增长的阶段出现.

所以虽然不同公司不同部门可能处于不同阶段. 大家首先要理解当面的阶段的原因, 别光吐槽, 也预知后续趋势和可能出现的问题, 做好预备。

另一方面， 也不用迷信或者纠结， “我们要不要做中台”。 如何对抗增长的复杂性是个长期准备， 不同阶段不同准备。

最后的笔者自我介绍:

考虑了一下, 还是写完这篇完整, 再介绍一下笔者大概的情况, 也方便大家判断我的执笔偏好.

1. 本人在杭州某大厂从事 10+年, 比较完整经历过以上不同的周期, 所以对过程和问题一些亲身体验

2. 本人经历过本文"红蓝绿"阵营的一线或者管理角色, 理解其中的比较全面的视角.

所以本人自认视角比较中立. 但是由于能力/视野局限, 最终也是主观成文 ,可能有不周之处, 欢迎指教.

但是谢绝空评中台好坏之类问题.