在技术领域深耕近二十年，我先后跨越了通信、软件、互联网等多个行业，并在金融科技领域潜心笃行近十年。一路上，我经历了从后端到前端的技能迁移，也完成了从普通工程师到研发管理者的角色跃迁。我曾作为初创成员，从零开始搭建起一支高效的团队；也曾与伙伴们并肩作战，见证了核心业务突破万亿规模的高光时刻。

然而，当技术管理走到深水区，我逐渐感受到了那面无形的玻璃天花板——单纯的技术视角在面对复杂的商业战略、跨部门协同以及宏观市场变化时，常常显得力不从心。

为了突破认知瓶颈，重塑个人品牌，并构建更宽广的资源网络，我选择在职业生涯的黄金期主动求变。2026年，我顺利拿到了上海交通大学安泰MBA综合管理方向的拟录取通知。

这段备考之路，既是一次严苛的自我测试，也是一场关于"取舍"的修行。以下是我的一些实战经验，希望能为正在筹备考研的学弟学妹们提供一些落地、有价值的参考。

一、择校：谋定后动，选择最契合的土壤

对于在职备考的人来说，精力的分配是极其奢侈的，因此择校的精准度决定了备考的性价比。我选择交大安泰MBA，主要基于三个维度的考量：

金融系统出bug和出资损，是两个完全不同的量级。功能写错了，改过来就是；页面丑了，迭代一轮就行；但钱算错了，那是客诉、是赔付、是监管约谈，严重的时候直接停业整改。

我观察到一个很普遍的反应模式：出了资损，先加测试用例；又出一次，加人肉对账；再出一次，加发版审批。每一步都在做加法，每一步都离根本原因更远。因为大部分人把资损当成了一种"严重的bug"，用防bug的思路来防资损。这个认知偏差才是资损反复出现的根源。

资损不是bug的严重版

普通bug和资损的核心区别在于：bug是你功能做错了，资损是你的功能没做错，但钱错了。

一个理财产品页面，把年化收益率3.5%展示成3.8%，这是bug。但用户基于3.8%做了购买决策，实际到账按3.5%结算，用户体验上的落差就是资损——即使从功能角度看，展示模块和计算模块各自都"按逻辑运行"。

更典型的场景：用户申购一笔理财，网络超时，前端重试了一次，后端处理了两笔。这两笔处理的每一笔单独看都没"错"——接口接收请求、参数校验通过、数据库写入成功。但因为缺少幂等约束，结果就是资损。

上周清理日历的时候顺手做了个统计——我所在的技术团队，10个人，一周62个会议。人均每周6.2个，平均每天1.2个。如果按每个会议40分钟算，将近四小时。还没算上会前准备和会后消化，还没算上那些"5分钟碰一下"的临时通话。

这不是个别现象。我跟同行聊过，金融科技领域尤其严重——合规对齐要开会，风险评审要开会，跨团队排期要开会。一个需求的开发周期里，真正写代码的时间可能还不到一半。

很多团队的第一反应是"减会"——砍掉每日站会，缩短周会，设立无会议日。然后呢？信息断了，对齐塌了，出问题的概率反而上升。砍完的会议像野草一样换个形式长回来。

我后来想明白了这件事：会议不是问题，会议是症状。就像发烧不是病，是身体在对抗感染。你把体温压下去，不等于治好了。

每个砍不掉的会，都在替系统还债

技术团队里的会议，大致可以分几类。每一类背后都藏着不同的问题。你不可能一刀切地减掉它们，因为砍掉会议后露出来的那个洞，可能比会议本身更危险。

同步会：你的模块边界画错了

两个子系统需要"定期同步"，这是最常见的一种会。前端和后端每周对齐，A团队和B团队双周同步。听起来很合理，但仔细想想——如果两个模块之间需要定期人工同步，说明什么？

DRY——Don't Repeat Yourself。这四个字母可能是软件工程里被引用最多、被误解最深的原则。

每个程序员入行第一天就被告知：重复代码是邪恶的，看到重复就要提取，看到提取就要抽象，看到抽象就要泛化。于是我们疯狂地消灭重复——公共函数、工具类、基础库、共享模块......代码库越来越"干净"，重复率越来越低，CI里没有任何duplicate code的警告。

然后某一天，一个业务需求来了——需要改动某个"公共"逻辑。你打开那个被47个地方引用的utils函数，改了一行，跑了一下测试——绿了。上线，结果三个业务线同时报警。你突然发现，那三个业务线依赖的是同一个函数的三种不同行为，被那个"公共"函数强制统一了。

你消灭了重复代码，但你制造了耦合。而耦合，是比重复贵十倍的技术债。

重复代码不是问题，问题是不知道为什么重复

所有关于DRY的讨论，都默认了一个前提：重复等于坏。但这个前提本身就是幻觉。

重复代码至少有三种完全不同的面目。

第一种是意外重复——两个开发者不知道对方写了同样的功能，造了两个轮子。这种重复才是真正需要消灭的，因为它意味着信息浪费和潜在的不一致。