技术上更合理的方案，为什么没被选中？一次真实的架构决策复盘
最近做了一个需求，过程挺有意思。不是技术难，而是：方案明明想清楚了，却没被选中。
复盘发现，这不只是“表达”问题，而是从一开始就埋下了认知偏差。
一、 背景：一个典型的“跨系统查询”
场景很简单：查询用户在全平台参与的审批流程。
- 现状： 数据散在 N 个微服务，用户得先选系统，再查数据。
- 痛点： 体验稀碎。业务方目标很明确： “要一次查询，把所有数据都搜出来。”
二、 两个方案的博弈
我当时脑子里迅速跳出了方案 A，觉得这才是“技术正确”：
-
方案 A（我的）：先看分布。
查询各系统“待办条数” -> 返回分布（系统甲 5 条，系统乙 10 条） -> 用户点击具体系统看明细。
- 优点： 性能极佳，逻辑简单。
-
方案 B（最终落地）：暴力聚合。
公共系统去请求所有下游 -> 拿回所有条数 -> 再去拿明细 -> 内存分页展示。
- 代价： 至少两轮跨服务调用，耗时长，复杂度高。
三、 为什么“更合理”的方案出局了？
复盘时我意识到，我掉进了三个坑：
1. 语义陷阱：“一次查询”自带光环
在讨论会上，“一次查完”天然等同于“用户体验好”、“简单”。
而我的方案“先看分布，再点进去”，在直觉上就被打上了**“多一步”**的标签。我没能打破这个直觉上的劣势。
2. 没把性能损耗“量化”
我脑子里知道方案 B 慢，但我没明确说出： “这个方案实际上会比现在慢 2 秒以上”。
结果大家默认理解成：一次查询 = 更高效。
3. 忽视了 Trade-off 的本质
方案 A 牺牲的是“点击次数”，换取的是“响应速度”。
方案 B 牺牲的是“系统稳定性与速度”，换取的是“少点一下”。
但我当时没有把这个“交换公式”摆在桌面上，大家是在信息不对称的情况下做的决策。
四、 最大的收获：一次查询 更快看到结果
这是我这次复盘最大的认知升级：
- 方案 B： 看起来少点一次，但因为要聚合所有慢接口，用户可能要盯着转圈圈看 3 秒。
- 方案 A： 看起来多点一次，但分布信息 200ms 就出来了，用户能立刻获得有效信息。
“系统交互少”不等于“用户获得结果快”。
五、 如果重来一次，我会怎么做？
- 先理解痛点： 问一句“现在体验不好，是因为点那一下麻烦，还是因为找不到数据在哪？”。
- 别急着对抗，先给“代价”： 我会支持“一次查询”的方向，但同步给出它的代价——“如果要一次查完，耗时会从 200ms 变成 2s，这个成本业务能接受吗？”
- 把决策权抛回去： “我们是在用系统的复杂度和响应延时，去换取减少一次点击，大家觉得值吗？”
写在最后
架构设计，本质上就是交换（Trade-off） 。
很多时候，不是你的方案不合理，而是你没能把**“交换的筹码”**讲清楚。在大家达成共识之前，再完美的方案也只是你一个人的“技术自嗨”。
先确认大家在解决同一个问题，再聊怎么交换。
