技术人跨语境沟通③：不同对象，真的要换一种“人话”

那次和高管同步项目的时候，我其实准备得挺充分的。逻辑图画了三张、技术选型方案写了两页。结果聊了15分钟，对方问的不是“我们选A还是B”，而是：“所以这东西对Q4的客户活跃有帮助吗？”

我愣住了两秒钟。

不是因为不知道答案，而是我没想到他是这样问的。

这不是我第一次在“答了，但没人听懂”的沟通里卡壳了。

我们常说“讲人话”，但其实最大的难点不在翻译，而在于你根本不知道该翻成哪种语言。

跟不同的人说话，像是进了不同的聊天室：

有人关注用户体验，有人只看数字和风险；
有人想知道“这个怎么做”，有人只关心“这对我有什么影响”；
有人听“组件设计”，有人听的是“品牌一致性”。

我们不是真的不会表达，只是搞错了“谁是主语”。

高管不想听你说技术，而是想看你解战略

我们最容易对高管犯的错，是“以为对方关心细节”。

我以前在一个团队里推 Node.js 服务迁移，做了技术路线图，还测了很多 RPS 性能对比。向 VP 汇报时，我讲到第七分钟他突然打断说：

你讲得挺细的，但我其实更想知道，这事对我们 11 月增长目标是正向的，还是只是把基础设施打扫干净。

那一刻我才反应过来，我一直在讲“我们做了什么”，但他要的是“你为什么值得我支持”。

从那之后，我讲给高管听，习惯这样组织：

我们现在面临两个选择：

方案 A 更稳定，但会压缩上线节奏；

方案 B 风险稍高，但能抢下季度前的曝光窗口；

从战略优先级看，这轮如果主打增长，我倾向建议走 B，但要配合一周的灰度机制做风险控制。

**你不需要把技术讲浅，而是要把路径选项讲清，**再链接到他在意的战略目标、时间窗口、竞争态势。

换句话说，让高管做减法，而不是帮你做评审。

跟产品对话：不是对抗，是一起选“代价最小的折中方案”

说实话，我以前和产品沟通经常像是在吵架。

我说这个东西开发太复杂，她说用户就是需要这个功能。最后大家都觉得对方不理解自己。

后来我才明白，问题不在意见，而在我们没把“成本 vs 用户体验”的权衡机制可视化出来。

一次我们在做注册流程优化，产品希望加入手机号动态验证+推荐码逻辑，但这要引入新的三方依赖、重新梳理权限。

我没有直接说“太复杂了”，而是这样讲的：

你这个方案做出来，最理想的确是更安全。但技术上，我们要接两个新 SDK，还要走一次权限审批，可能会延迟发版两周。

如果我们先上线一个只有推荐码逻辑的简化版，用户感知上的差别最多就是安全提示少了一句，但上线能提前两个 sprint。

你觉得现在这个阶段，哪一边的代价更值得？

这不是妥协，而是一起去找那个对用户影响最小、对技术负担可控的最优区间。

产品不怕被 challenge，怕的是被无效阻力挡住。

面对运营团队：别讲查询慢，讲“用户在掉线”

最容易忽略但沟通最难的角色，是运营。

他们节奏快、指标重、关注实效，但我们经常甩出一句“这个功能后端现在卡住了”，对方完全不知道该怎么办。

我后来发现一个很好用的方式是——把问题翻译成“用户感知层”的语言。

例如数据库慢查询，我以前说的是：

现在订单查询接口 P99 在 2.8s，慢查询比例 3%。

后来我换了一种说法：

现在每天大概有 800 个用户，在中午高峰期打开订单页时会卡住 3 秒以上，他们中有一半以上是首次下单的用户，可能直接流失。

这个时候运营立刻就能感受到事情的严重性，因为他在乎的不是慢，而是“丢人”和“流失”。

我们要做的，不是把技术问题简化，而是找到技术和业务目标的接缝处，让对方能“接得住”。

和设计师沟通：不说“代码不好复用”，说“用户会困惑”

有一阵子我总觉得设计师风格不统一。每次交付都多出一堆特殊状态、边角处理、像素级微调。

我说组件复用率低，他们说是为了更好看。

后来我换了种表达：

这个按钮在 5 个页面里交互逻辑不一致，有的是点击后弹窗，有的是跳转，有的是无提示，用户每次要重新学习。

如果我们统一交互，就可以把这个组件封装成 UI 库里的一类，减少出错率，也能让用户记住这套逻辑。

设计师的语言不是函数调用，而是“用户习惯、审美一致性、品牌氛围”。

你得让他们看到，复用率高，不是技术效率，而是用户成本低。

最后一类人：我们自己人

最讽刺的一点是，有时候最难沟通的，不是其他角色，而是我们自己。

有一次跨团队协作，我以为对方会看懂我们发的文档，结果上线前发现对方根本没对接那个核心 API。回头一看，我写的是：

请依照 config schema 提交 payload，参考 demo.md

对方看不懂 schema，根本不知道 payload 长啥样。

我重新写了一段：

我们期望收到的 JSON 长这样：

{ "user_id": "string", "feature_enabled": true, "context": { "source": "web" } }

如果你用的是默认 SDK，调用 sendEvent() 时带上 user_id 就可以自动封装。

这时候对方才秒懂。

别高估工程师的阅读理解，也别低估一个具体例子的力量。

我们以为的技术对齐，其实经常是“术语碰术语”。

写在最后

每种角色都有自己的世界观：

高管看的是风险与下注；
产品关心的是体验与路径选择；
运营紧盯的是指标与即时反馈；
设计师关注的是一致性与用户认知；
工程师之间在意的是接口清晰与对接成本。

我们想要被听懂，不是因为我们要讨好谁，而是因为：真正复杂的项目，靠的不是技术通不通，而是语境通不通。

你越能把同一件事，用不同角色的语言讲一遍，别人就越愿意把复杂问题交给你。

因为你不是说得最对的人，而是那个说了能动起来的人。