【实战派×学院派】02｜技术和业务吵翻了，BA夹在中间两边不是人

学院派：别当传话筒，要做调解官

本文出自系列文章：

“实战派”常踩的坑，“学院派”如何补上 —— 业务分析师的理性修炼指南 

你是不是也遇到过这种局面：

——“这个字段没用啊，业务又不懂技术！”

——“这个逻辑必须这样走，不然系统就跑不通。”

——“那你们搞清楚再来找我，我们需求都讲了三次了！”

会议现场火药味十足，业务吐槽技术不懂业务，技术嫌弃业务不懂系统逻辑，而BA像个夹心饼干，被两边推来推去、疲于解释、左右不是人。

一边说你“站业务”，一边说你“帮技术”，你努力传达，却没人满意。

---

✅ 实战派误区：只传话不调解，陷入“沟通中转站”

很多 BA 在这种场景下会陷入一个误区：“我只负责传话，不负责判断。”

他们做的工作往往是：

• 会议记录谁说了什么 → 转发给对方
• 业务有抱怨 → 整理成“问题清单”发给技术
• 技术回反馈 → 回复给业务，但不解释、不协调

看似中立，实则失职：

行为	看起来像在沟通，实际是在制造误解
转述原话不加工	情绪被放大，立场更对立
避免表达观点	双方找不到平衡点
不做结构分析	真问题被掩盖，讨论陷入拉扯

你不是对讲机，更不是快递员。你要的是打通，不是转发。

---

🎓 学院派补法：观点-证据模型 + 技术翻译术 + 利益平衡图

真正能稳住场面的 BA，不是中立传话，而是结构化调解 + 多语言翻译 + 利益博弈撮合。

① 用“观点—证据模型”澄清分歧源头

技术和业务吵，其实吵的不是“对错”，而是立场、担忧、底层假设。

用这个简单的结构，快速澄清双方争论点：

谁	观点（Claim）	背后证据 / 担忧（Evidence）
业务	“用户一定要能随时修改资料”	市场部反馈修改率高、客户常填错
技术	“不能随便改，会影响数据一致性”	修改会影响订单处理逻辑，导致异常工单暴增

分歧 ≠ 敌对，很多时候只是缺少翻译。

---

② 用“技术翻译术”搭桥，让业务理解系统边界

业务常常不知道技术在担心什么，比如“影响数据一致性”“调用链崩了”“异步逻辑出错”等。

BA要做的，不是把话原封不动转给业务，而是把“技术话语 → 业务影响”翻译出来：

技术术语	翻译成业务能懂的话
数据一致性问题	“客户改了地址，但发货信息没更新，快递就寄错地方了”
缓存失效	“你查到的数据不是最新的，系统要花几秒重新更新”
后台接口超时	“你点‘下一步’时页面卡住，就是后台超时了”

技术不是“不配合”，而是“表达方式不同”。BA要懂技术逻辑，但更要会”说人话”。

---

③ 画出“利益平衡图”，找出共赢解法

技术看重系统稳定、可维护性，业务看重灵活性、用户体验，两者看似冲突，实则可以拆解时间和方案维度：

需求点	技术担忧	业务期望	可调解方案
修改用户信息	实时改会导致异常	用户希望随时改资料	改为每日凌晨同步或加审批机制
导出客户数据	数据量大、系统压力高	市场要随时导数据	改为定时批量导出 + 邮件通知下载
动态字段配置	配置项太多容易出错	运营希望自己加字段	限制字段类型 + 配置项上线审批流程

不是非黑即白，而是有第三种选择。你就是那个画出“第三种选择”的人。

---

⚠️ 学院派别补错了：别用“假中立”掩盖“真推责”

有些学院派 BA 看似逻辑缜密，实则不愿承担判断责任，做成了“标准型中立人”：

行为	潜在问题
总是“你们先谈谈”	自己不参与判断，反而加剧对立
文档很全，但从不下结论	业务和技术都在猜“他到底偏谁”
做很多“澄清会”“对齐会”	会议很多，实质进展很少

中立 ≠ 回避判断。调解是策略，不是逃避。

---

🎯 学院派的“调解型补法”：中立有立场，判断有逻辑

原则	实操建议
有判断，但不站队	拆解立场和证据，让每一方都觉得“被理解”
有翻译，但不降维	技术翻译成业务语言，但保留逻辑严谨，不“和稀泥”
有方案，但不包揽	给出调和路径，不强推一方，给双方留下空间

调解不是“让大家都满意”，而是“让大家都觉得公平”。

---

💬 更“接地气”的说法，你可以这样说：

• “你说得对，但我理解他们也有系统顾虑。我们一起找个两边都能接受的做法。”
• “这不是技术故意卡你，是这个设计确实可能导致数据错乱。”
• “我来帮大家对照一下，看看有没有折中方案，别直接撕了。”

---

🧾 写在最后：

项目中的技术和业务，从来不是真的敌人，只是彼此关注的东西不同。

真正的 BA，不是中立得像空气，而是能听懂两种语言、看懂两种立场，做出结构性判断的人。

你不是“谁说了算”的传话人，而是“怎么说才算”的设计者。

调解，不是“我中立”，而是“我有逻辑、有翻译、有共识机制”。

下次再遇到吵翻的场面，你可以这样说：

“我们不争对错，我们找结构性的解决方案。”