
Read Time:42 Second
前言:
中台是英雄, 也是个悲剧
在软件开发的历程当中,我们从认同 “Software Reuse” 、延伸到 “中台” 的架构与开发。
然而, 中台是英雄, 也是个悲剧, 为何 ?!解决之道也许没有我们想像中的那么的复杂 ?!
本文:
为何中台是英雄, 也是个悲剧 ?!
“Software Reuse”、“中台” 让我们懂得如何的将企业或团队内最优秀、经验也最丰富的一群人的专业、代码转换为可供企业或团队内的其他成员可以 “重复使用” 的 “API”。
然而,“中台”、“中台团队” 在企业或团队中能获得认可、尊重、公平合理对待的却不多,为什么?!
- 全世界应该不会有任何的一个 “业务团队” 会愿意主动的将产品在市场上的成功、荣耀、利益与 “中台团队” 分享的;但是,却只有在需要 “甩锅” 的时候,会 “自动” 的记得 “中台团队”。
- “中台团队” 就只能 “靠自己” 去证明自己在企业内存在的价值。
- 当 “中台团队” 只能 “靠自己” 才能在企业内存活的时候,“中台团队” 、“中台” 就会离 “业务团队” 越来越远⋯
- 当 “中台团队”、“中台” 离 “业务团队” 越来越远的时候;“中台团队” 、“中台” 在企业内的下场就可想而知了 ?!
解决之道:Pipelines
我们也许应该是要从另一个视角、另一个解决方案来达到 “中台团队”、“中台” 所要达到的目的,所要做的事情;“重复使用”。
- Pipelines; 在 “业务团队” 内建立起产品研发、开发、集成、测试、审查、布署的全流程的 Pipelines;使得 “业务团队” 的每一个成员,每一天的产出都能 “完整”、“自动” 的存储、积累在 Pipelines 当中。
- 在 Pipelines 当中所存储、积累的将不只是 “代码”,而是 “可重复使用” 的产品研发、开发的 “经验” 与 “智慧”。
- 业务团队需要什么样的技术、算法、代码, 应该是由业务团队的 Pipelines 当中积累、演进、筛选而来的。
结论:
当我们旅游的时候,走错了路,很正常的。但,发现走错了路,却不懂得换条路走,还在继续的错下去;假如是这样子的话,也许,我们就永远到不了我们所想要到达的目的地了?!
软件的开发也是一样的道理的,同意吗?