有个场景在金融科技公司几乎每周都会上演:产品经理说"这个需求很简单,就是加个按钮",工程师听到的是"又要改架构"。

会议室里的氛围瞬间凝固。产品经理觉得技术团队在找借口,工程师觉得业务方根本不懂技术。双方都没说错,但都没说对。

这不是沟通技巧的问题,是认知框架的断层。

信息在组织边界丢失

我观察过一个现象:同一个需求,产品经理在需求评审会上讲五分钟,工程师回去讨论要两小时。

不是工程师理解力差,是信息在跨部门传递时发生了质变。

产品经理说"支持用户自定义理财目标",他脑子里是一个完整的业务场景:用户设定目标金额和期限,系统推荐合适产品,定期提醒达成进度。这个场景在产品原型里是完整的,在用户故事里是清晰的。

但工程师听到的是什么?

前端听到的是:新增表单、字段校验、状态管理、埋点上报。后端听到的是:数据库表设计、接口规范、权限校验、数据迁移。全栈工程师听到的更复杂:前后端联调、缓存策略、异常处理、监控告警。

同样五个字,解析出来的工作量相差十倍。

这就是组织边界的代价。产品经理思考的是"用户价值",工程师思考的是"技术实现"。两者的抽象层级不在同一个维度,信息当然会失真。

做技术管理这些年,我发现一个有趣的现象:越是成功的技术Leader,越不愿意分享自己踩过的坑。大家都在讲"如何打造高效团队"、"OKR落地实践"、"技术人才培养体系",却很少有人聊那些让人坐立不安的尴尬时刻。

但恰恰是那些尴尬时刻,构成了技术管理的真实底色。

当你意识到自己是瓶颈

2019年,我负责的前端团队刚从5人扩到10人。团队扩张后的第三个月,我突然发现一个问题:所有人都在等我review代码。

不是他们不主动,而是我在无意识中给自己设置了一个隐形职责——"技术质量守门人"。每个PR我都要亲自看一遍,每个技术方案我都要参与讨论,每个难题组员都会第一时间找我。

表面上看这是负责任,实际上是灾难。

团队的吞吐量被我一个人的工作时间卡死了。更糟糕的是,我发现自己在培养"等待型工程师"——遇到问题不是先思考,而是先找Leader确认。这不是我想要的团队文化。

那段时间很煎熬。一方面我知道必须放手,另一方面又担心代码质量下滑。最让人尴尬的是,当我试图"授权"时,发现自己根本不知道该怎么做。

过去几年里,我习惯了"事必躬亲就能保证质量"的工作方式。现在要求我"不插手也能保证质量",完全是另一套技能。

写在前面

前几天和一个创业公司的 CTO 聊天，他说他们团队 5 个后端开发，已经拆了 12 个微服务。我问他为什么要拆，他说"为了未来的扩展性"。然后我问他现在的 DAU 是多少，他说"几千"。

这让我想起很多年前见过的一个场景：一个刚起步的业务，还在验证商业模式，技术团队已经开始讨论服务网格和分布式追踪了。最后业务没做起来，技术架构倒是挺先进的。

微服务这几年被捧得太高了。很多团队在根本不需要的时候就开始拆服务，结果把自己搞得焦头烂额。今天想聊聊这个话题，不是说微服务不好，而是大部分团队真的不需要它，至少不是现在。

微服务的真实成本

开发成本的指数级增长

很多人以为微服务只是把代码拆开而已。实际上，从单体到微服务，你需要解决的问题是指数级增长的：

服务间通信：HTTP 调用、gRPC、消息队列，你得选一个。然后你会发现，本来一个本地函数调用，现在变成了网络请求。网络不可靠，你得处理超时、重试、熔断。原本简单的代码，现在要考虑各种边界情况。

最近在和几个技术管理者交流时，发现他们都在规划或已经落地了BFF（Backend for Frontend）架构。问为什么要做BFF，得到的答案惊人地一致："解耦前后端"、"提升开发效率"、"这是最佳实践"。

但当我问："你们团队有多少后端开发？前端开发呢？"，答案通常是"后端6-8人，前端3-4人"。这让我意识到一个问题：大部分团队上BFF，可能不是因为真的需要，而是因为"别人都在用"。

我想聊聊这个话题，不是要否定BFF的价值，而是想说：很多团队高估了BFF的收益，低估了它的成本。

BFF真正解决的问题

先说清楚，BFF不是伪需求。它在特定场景下确实有价值：

场景一：多端适配。你的后端API是为Web设计的，现在要支持移动端、小程序、IoT设备。不同端的数据需求、交互逻辑差异很大，用一套API很难搞定。这时候BFF可以为每个端定制API，后端保持稳定。

场景二：聚合调用。前端一个页面需要调用5-6个后端服务，串行调用太慢，并行调用又要处理复杂的依赖关系。BFF可以在服务端聚合这些调用，减少前端的复杂度和网络开销。