中台; 是英雄? 是悲剧? 解决之道又是什么?

Read Time:42 Second

前言:

在软件开发的历程当中，我们从认同 “Software Reuse” 、延伸到 “中台” 的架构与开发。

然而, 中台是英雄, 也是个悲剧, 为何？！解决之道也许没有我们想像中的那么的复杂？！

“Software Reuse”、“中台” 让我们懂得如何的将企业或团队内最优秀、经验也最丰富的一群人的专业、代码转换为可供企业或团队内的其他成员可以 “重复使用” 的 “API”。

然而，“中台”、“中台团队” 在企业或团队中能获得认可、尊重、公平合理对待的却不多，为什么？！

全世界应该不会有任何的一个 “业务团队” 会愿意主动的将产品在市场上的成功、荣耀、利益与 “中台团队” 分享的；但是，却只有在需要 “甩锅” 的时候，会 “自动” 的记得 “中台团队”。
“中台团队” 就只能 “靠自己” 去证明自己在企业内存在的价值。
当 “中台团队” 只能 “靠自己” 才能在企业内存活的时候，“中台团队” 、“中台” 就会离 “业务团队” 越来越远⋯
当 “中台团队”、“中台” 离 “业务团队” 越来越远的时候；“中台团队” 、“中台” 在企业内的下场就可想而知了 ?!

我们也许应该是要从另一个视角、另一个解决方案来达到 “中台团队”、“中台” 所要达到的目的，所要做的事情；“重复使用”。

Pipelines； 在 “业务团队” 内建立起产品研发、开发、集成、测试、审查、布署的全流程的 Pipelines；使得 “业务团队” 的每一个成员，每一天的产出都能 “完整”、“自动” 的存储、积累在 Pipelines 当中。
在 Pipelines 当中所存储、积累的将不只是 “代码”，而是 “可重复使用” 的产品研发、开发的 “经验” 与 “智慧”。
业务团队需要什么样的技术、算法、代码, 应该是由业务团队的 Pipelines 当中积累、演进、筛选而来的。