前言

去年我加入阿里的一个创业项目。最开始，大家都信心满满，当时大家挂在嘴边的口号是“我要把这个业务做上市”。在经历第一次大促、疫情好转、换帅、集团战略调整等事件之后，最近这个项目发生大的人员调整，项目上所有集团内部技术岗位人员（P6~P8）都被裁了一个不剩。我以一个开发的视角来复盘整个过程，顺便也讲讲我的看法。

创业背景

2019年年关发生的疫情导致国外供应链体系遭受重创，中国在体制优势下疫情防控工作做的很好，最先恢复过来。彼时国外疫情的扩散势态仍然没有得到有效的抑制，大量工厂无法复工复产。同时，为了防止疫情扩散，很多出口国也关闭了商品的出口通道，进一步加剧了短缺现象。
（比如：2020年初的国内猪价大涨，正是因为猪肉无法进口而短期内又受到猪的生长周期的限制，导致猪肉大涨）
在疫情肆虐的大环境下，大量消费场景由线下转到线上。正是在这个大背景下，中国多年的的电商经验以及最先复工复产的优势非常明显，大量创业者开始入局跨境电商，当时最流行的一句话就是“在风口上，猪都能飞起来”。

前期的基建

我们选择的赛道是轻时尚，针对国外Z世代的用户提高供性价比的女装。轻时尚本身就是一个比较新的领域，加上我们的供应链体系既不是纯粹的自营也不是纯粹的商家仓发，
可以说是介于两者之间的一种新的形式。供应链体系的创新加上对轻时尚领域的陌生导致根本无法借鉴集团现有的经验和已有的产品能力，无法快速的定位市场的需求。
所以，在这个阶段，我们借助集团中台，搭建了自己的供应链体系，开始摸索轻时尚领域。整个基建过程中大致经历3到4个月，到这个阶段我们的整个体系大致搭建起来了，整个系统也在运转，业务也在不停地探索创新。

准备大促

大概是在7月，整个团队的业务和技术还有产品一起开了一个KO大会。会议的大概主题是确立今年的考核指标以及第一次大促的时间，想通过大促来检验我们的阶段性成果，方便后续调整。
当然，我们定的大促时间是在黑五（黑色星期五）可以说有很长的准备时间。我们还专门组织了outing(团建，一人1000经费)，提升团队凝聚力。

去中台化

在准备大促的过程中发生了好几起大的生产事故，都是由于中台自身设计问题，坐在家里也有故障发生（轻则数据错乱，重则服务不可用）。
抛开线上事故来说，当时使用中台开发也有很多痛点，大致体现如下几点：

1. 开发效率低下。 我当时刚上手，花了2天才懂了如何给响应数据中添加一个字段，扩展点太多而且没有文档介绍，找中台的人问问题，回复也很慢。
2. 系统边界不清晰。 中台分为平台和站点，按照我的思路应该是将平台作为一个SDK集成到站点，站点作为一个应用对外提供服务。但是实际上却是将平台作为一个应用，将站点作为一个jar直接导入到平台中。
3. 单基线+对全体开发开放平台代码提交权限。 这意味着所有人都可以对平台中共用的功能点做更改，一旦某个业务线提交的代码不兼容其它业务线，就会导致其他业务线在发布之后出现生产事故。同时，因为要快速迭代需求，所以业务开发没兴趣去抽取其他业务线也会用到的能力，把它放到平台层。反而是把正对自己业务特性的代码直接放到平台层，导致平台和站点的界限越来越模糊，代码更是越来越像米田共 球”。
4. 中间件未隔离。 这是因为很多共用功能是读取同一个分布式配置，如果某一个业务线变更了这个配置，那其他业务线也跟着受影响。
5. 问题排查困难。 几乎所有功能都是通过扩展点进行集成，一旦出现错误，根本没法确定哪里报错，因为错误日志里没有打印错误堆栈！！！所以只有两种方式排查，一是根据请求入参、出参，自己去看代码。二是远程debug,但是debug不能卡太久（大致是2分钟），否则健康检测机制会认为机器出现故障，导致机器被重启，debug会断掉。

正式基于这样的一个背景下，我们CTO决定去中台化。当然，这也是有个漫长的过程，大概是从十月开始做这个事情，但是直到写博客的今天为止，也并不是所有功能都从中台抽离出来。
因为，我们还得迭代业务，所以资源投入业有限。不过，我所在的商品团队已经将所有功能迁移。但迁移过程也是很心酸，预计一个半月上线，然后花一周做灰度发布。实际情况却是，开发两个月，测试一个月。
因为这期间前端投入不足，导致一直在等待前端资源。同时，上线完后，我们灰度也用了两周，才完全切换过来。也正是有这个经历之后我才明白，在运转的系统中换系统架构，无异于在一架飞行中的飞机上换引擎。

大促成果

老实说，整个黑五期间，我并没有太多感受。一是本身业务量不太大，没有需要应急处理的特殊情况。 二是，在黑五期间都会封网（非必要不发布，发布要走审核）。而B端系统，在单量很少的情况下，基本很少出故障。

在黑五复盘大会上，CEO也是跟我们晒了一些成果。大致讲的是“取得了阶段性成果，但尚未成功，同志们仍需努力”。不过，对当时的我来讲，因为我没有过创业经历，我也不知道这到底是好还是不好？好在哪里？有多好？换句话说就是“心里没数”。

但是，通过这种战果通晒的方式确实能鼓舞（迷惑）人心。后面一段时间里，技术人员都认为业务前景一片大好（至少我和我身边的同事都这样认为），有机会直接走向人生巅峰。

团队换帅

在大促之后不久，我们CTO转岗回到菜鸟，换了一个“负责人”。因为之前CTO是P9，新来的老大是P8，所以大家只用“负责人”来称呼他。
其实，这个时候大多数技术、业务都失去了信心。因为团队突然换帅，会打击大家的信心。
同时，也会传递一些消极信息，大家可能会担心这个业务是否还能继续做下去。但是，我当时没多想，也很少和业务交流，所谓“两耳不闻窗外事，一心一意写代码”。

当然，这么做的不止我一个。我清楚的记得，12月的时候还和至易师兄一起吃晚饭。当时，我们聊到这个业务的前景。
我说：“留给这个业务的时间不多了。国外疫情恢复之后，风口的风会停下来，这个时候如果我们的品牌力不够，那就会被市场淘汰。不过，即使最后做不好，可能会以一个子部门的形式存在，毕竟集团没有轻时尚的其他业务部门，而且目前现有平台模式不太适合轻时尚。”
师兄却说：“我们不会失败，因为我们是阿里，我们能创造不可能”。

外部环境变化

在过去的一年里发生了很多大事儿。反垄断力度加大、阿里各个阵地失守、经济周期性调整、海外疫情恢复等等这些问题加上业务单量冲不上去，这让我们部门雪上加霜。2022年阿里开启裁员模式（其实不止阿里，其他地方也在裁），首先就是在4月，裁掉了之前还信心满满的至易师兄，还有一个P8和一个P6。
就在我们以为裁员风波过了的时候， 4月的最后一个星期，项目中所有集团内部技术人员都被拉去做“预期管理”。裁员的名额不是固定的，是一个区间值。所谓“预期管理”，就是通知你，你被加入到了裁员名单。
很不幸，最终这个项目中的所有集团内部技术，无一幸免。令我感到惋惜的是，一起奋斗的闻安师兄和袖石小姐姐最终也逃不过被裁掉的命运。

写在最后

至一起奋斗过的同事

我觉得很后悔，因为我从未想到过大家会以这种方式离别。我以为大家还有大把在一起的时间，所以我留了好多问题还没来得及问。
我想知道关于师兄们晋升的事儿、我想知道集团曾经里面发生的趣事儿、我想知道如何平衡工作和生活。现在看来，这些问题都只能留给我自己了。

还有，最重要的是苟富贵，勿相忘！！！

至逃过一劫的人

在大风波里逃过一劫的人，都是幸运的。但是，很多时候其实我们应该更“敏感”。比如：业务团队在去年10月份开始就产生一些对业务不看好的想法，我们却是直到别人被裁了才知道业务营收不好。
这里其实也是有很大一部分是做技术人的通病，这里以我自身为例，列举下。（个人观点，不喜可喷）

• 业务不敏感。 只关注程序实现，很少关注业务。比如：让你开发一个功能，你会不会有这些疑惑。这个功能有多少人用？这个功能带来的实际价值是多少？怎么衡量功能的价值？
• 不喜欢社交。 很少和不经常打交道的人搭话，即使只是简单的打个招呼。最明显的例子是，我通过outing认识了业务侧的TL，但也是就见过那一次，后面有几次遇到了，都假装不认识，扭头就跑。
• 表达能力差。 很多东西和业务沟通不了，需要通过产品。只针对功能来表达观点，很多表达方式没有和业务侧对齐，导致很难和业务进行交流。因此，你就白白丢掉了能最直观的了解到业务运转状况的时机。
• 看低软技能。 只培养写代码能力，认为软能力不重要。这里的软技能指跟人打交道的能力。很多人认为和程序员打交道最多的是程序，但是回头看看一周的时间表，会发现和你打交道最多的是人，大部分时间都在和人在打交道。
• 不敢和领导交流。 天然的惧怕领导。我工作到现在为止，从来没有和领导一对一谈过话。后面我才明白，因为领导也是人，你约他去喝个咖啡，谈谈最近的工作，就当闲聊，领导也很愿意的。对你而言，好处就是，你总能得到一些有用的信息，对领导而言，他能更好的了解你。