小张入职了一家软件公司,他负责一条业务线,小白负责另一条

小张入职了一家软件公司，这家公司只有一个 SaaS 系统，两条业务线都在这个系统下。小张负责一条业务线，小白负责另一条，他们都是前端主管。小白比小张先入职，起初他们相安无事地在同一个仓库里面工作，随着业务的加大，彼此的影响越来越多，甩锅的情况也越来越多。

一天，小张决定用微前端技术来解构他们的仓库，给出了完整的技术方案，并获得了 CTO 的支持，他紧锣密鼓地改造自己负责的业务，但小白不愿意改。

你猜为什么小白不愿意改？

这涉及到权力的博弈。在技术选型背后，往往隐藏着资源分配与权力边界的重新划分。

小白拒绝微前端改造，是基于职场生存的理性选择。在巨石应用中，代码的深度耦合给维护带来了痛苦，也形成了技术壁垒。

小白的代码逻辑可能散落在各个角落。这种“你中有我，我中有你”的混乱，是一种不可替代性。如果系统离了小白就跑不起来，那么混乱就是小白的职场护城河。一旦小张完成了拆分，小白负责的部分就变成了一个标准的、可替换的插件。

还有另一个更主要的原因。从明面上来看，小白和小张是同级，在背后隐含的是，他比小张工作年限长，先入职，且跟着合伙人入职。相比之下，小张跟着一个技术经理入职，这位技术经理跟着 CTO 入职，CTO 也是合伙人之一。

两条业务线对应着两个合伙人，这意味着巨石仓库的拆分不仅是拆分代码，还有势力范围的划分。小张的方案虽然得到了 CTO（合伙人 A）的支持，但小白入职的背书人是合伙人 B。

在没有清晰边界的情况下，小白可以渗透到整个系统中，形成一种相互制衡的模糊感，一旦他接受微前端改造，在系统架构的感知上，等同于他的业务被并入小张的管辖范围。

对于一个资历更深且背后有合伙人支撑的老员工来说，这不仅是技术改造，更是职场地位的降级。

在最后，小张确实完成了技术方案的完整落地，但结局并不是一个 happy ending。小白从 xxx 业务线前端技术经理的位置上替换了下来。按小张的说法：“不需要他改了”。

小张最后从这家公司离职了，这是技术工具人的宿命，也是一个好的选择。因为做完技术改造后，他在该公司的履历溢价达到了峰值，而后续的办公室政治属于内耗。