0%

后平台行业分离时代面临的开发问题

我在18年年底入职,正值菜鸟仓储的平台行业分离时代战役启动。目前基本完成了平台化改造和内核升级,所有切换也基本进入长尾,计划近期会完成平台行业分离战役前的老应用/链路的物理下线。在当前这个【后平台行业分离时代】,作为一名亲历的一线开发小二,谈谈正在面临的一些技术困境。

中途岛的初心和成果

平台化改造自不必说,即是秉承集团大中台,小前台的思想,也是在顺应仓储业务多垂直行业的前提下构建的。

而内核改造,说白了,就是在做基础模型的标准化。

为什么要做基础模型标准化,我认为主要有两个原因:

  • 通用语言定义,降低沟通成本。在仓储领域,Hu和Task的概念都由来已久,通过基础模型标准化可以统一术语,沉淀领域知识。
  • 仓储的作业核心模型是仓储所有业务的载体,模型的是否合理,对于仓储业务的可扩展性至关重要。

关于基础模型的改造过程可以看以下两篇内容:

【HU】

【TASK】

中途岛战役成果是显著的,Hu模型已经贯穿了B2C链路上的出库、B2B链路的出入库,Task模型也已经普及到出库,库内,入库等多实操环节。

基础模型改造的优点是显著的:

  • 分工明确,内核团队负责Hu模型的标准能力、事件提供,业务平台基于内核的标准能力构建业务抽象,垂直行业将平台的标准能力落在实际的业务场景下。
  • 数据&算法团队的解放,可以基于统一的模型ETL&训练算法。

等等不胜枚举,可以到上面提及的ATA中查看详情。

困境其一:我们现在在服务哪些业务?


归根到底,技术的价值必须在实际的业务中得到体现。

我们做技术改造,降低开发成本,固然是技术价值的体现,但是做着做着,是不是不知不觉偏离了初心:搞业务。

作为业务平台的技术小二都总被人问说,平台行业分离之后,平台是不是就没什么事情可做了。

那内核团队的同学岂不是更甚。

我在当时参与Hu内核改造的时候就被问到了,是不是在闭门造车臆想了一个Hu内核标准,没有站在使用方的视角去看抽象是否合理。

所以这条链路上的所有技术小二,总要时不时的扪心自问,到底对业务创造了什么价值。

这个需要不断自驱的拷问和思考,就是第一个考验,如果没了这点,就会迷失在技术的幻觉中,越走越远。

在管理上,更暴露了KPI制度的一大缺陷:没有OKR从上而下的目标拆解。

困境其二:垂直行业同学的成就感在哪里?

据我的浅见,仓储垂直行业的同学面临两大难题:

  • 如何Push平台同学完善平台能力,实现本行业的业务诉求?
  • 基于一个牛逼平台能力之上构建出来的行业能力,我的成就感和价值在哪里?

从17年年初开始做平台化改造之后,各个垂直行业如同雨后春笋一般一时无比繁荣,猫超标准版(含4PL),魅力惠(奢品),零售通等等,但是这每一个垂直行业,都像一团又一团绚烂的烟花,一个又一个行业发布后,带来的维护成本,实施成本,标准化的定制成本,都像是烟花炸开后的一地鸡毛。不仅如此,在平台能力缺失时的灌进标准行业的众多兜底逻辑,在后续的维护过程中又是不停的阵痛。

但是不慌,所谓近水楼台先得月,垂直行业开发同学有个先天的优势,最贴近业务。直播,大农业,阿里健康,都是行业同学先进来一探究竟,这时候的机遇和挑战,跟随新业务成长的激情澎湃,都是无与伦比的体验。

这时候,垂直行业同学需要做的是什么?

  • 能够有挑战平台系统开放性设计的魄力,前提就是对于业务的深度洞察
  • 组件化的技术能力的提炼
  • 业务需求的咀嚼和深度思考,商业价值思维能力的锻炼

困境其三:行业成长缓慢时,平台扩展能力的投入ROI在哪?

当垂直行业一个又一个涌现,带来一个又一个新的输入时候,中台/平台的成长也是顺水推舟的。

但是所谓厚积才能薄发,当有诉求的行业数量是不尴不尬的个位数的时候,平台的业务流程抽象化该怎么做?投入的ROI在哪里?

如果平台没有扩展能力支持,就把更多的鸡毛,撒在了上一节的垂直行业同学面前。可惜这些鸡毛并不能成为说服平台和内核ROI看板上的令箭。

平台能力在往高峰攀登时候,突然燃油不够了,这时候急需的是:

  • 对平台发展的预判(技术能力的储备)
  • 对业务的贴近(托令箭的福)

典型的例子就如我们团队孵化的WPT。这个概念为什么在提出两年后才真正落地,首先是需要对平台发展时期的正确判断(什么时候才需要WPT),其次是依托一个实际的业务场景(2B调拨)。

困境其四:开发要当做自己的产品经理

有一个看似奇怪实则必然的现象:业务平台&内核团队很长时间内是没有产品经理的。

原因有两个:

  • 业务的需求往往只透传到行业层面
  • 平台的产品经理往往是要拒绝行业的需求的,所以存在感不高
  • 平台产品发起的方案难以在BBB中胜出,无法得到多行业业务方认可

所以逐渐的,产品经理都投入到离业务更近的具体业务项目中了,没有能够专职打磨平台&内核能力的人。

这个时候,技术开发要承担的工作,就不仅仅是技术的编码,更是产品能力的思考。

还记得有一次问一个前辈,那我们从技术的角度去思考这个问题,边界在哪呢,到某个产品形态还是业务场景?

答曰:没有边界啊!

在这个时候破局的思路就是:

  • 没有边界的思考,主动发现平台上所承载的业务中存在的问题
  • 推动想法落地的软实力,巧妙依托业务项目将自己的想法落地

这一点的挑战是最难的,意味着开发身份的转变和思考路径的拓展。

关于这个命题,后续会继续展开探讨。

加入星球与我交流