我在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中胜出，无法得到多行业业务方认可

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

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

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

答曰：没有边界啊！

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

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

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

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