为什么从事技术的人普遍都比较难沟通？

admin

刚看到自己之前记的技术沟通吐槽时，忍不住笑了 —— 木讷到接话能冷场、做着需求突然 “消失”、QQ 消息像石沉大海，这些场景我这几年做产品设计时也碰到过不少。但聊得多了发现，“技术人难沟通” 更像个 “双向错位的误会”，不是真的 “人有问题”，而是大家站在不同的 “沟通坐标系” 里。

先说说你提到的三个现象，其实我问过身边几个做技术的朋友，他们的 “难沟通” 背后藏着挺多无奈：

比如 “木讷没礼貌”，有个后端同学说，他每天对着代码改 bug，思维里只有 “逻辑对不对”“能不能跑通”，突然被拉去开会聊 “用户感受”“进度细节”，脑子得先从 “代码逻辑” 切换到 “语言逻辑”，反应慢半拍就容易显得 “没礼貌”—— 不是故意怼人，是真没意识到 “这句话听着不舒服”。
8 t6 Y2 m* }0 z" W
再比如 “不主动说进度”，我之前对接个前端，他中途停了需求去改另一个 bug，没跟我讲。后来聊起，他说 “觉得改 bug 是紧急且临时的，等解决了再继续做你的需求，没必要中途打断你”—— 技术思维里 “结果优先”，却忽略了需求方 “知道进度才安心” 的诉求。

至于 “不回 QQ”，更常见的是 “沉浸式工作”：对着屏幕调接口、找漏洞时，消息弹窗会打断思路，他们习惯 “把手上的事做完再统一回消息”，却没考虑到对方可能在等回复推进流程。
* v/ d6 h5 j7 w0 _' x# q/ W% n
但反过来想，沟通从来不是单向的 —— 就像你遇到的甲方大佬，他提 “又强又轻又便宜” 的材料时，其实也是 “不会沟通” 的：他的核心需求是 “减重 + 提强度”，却用 “不可能的技术指标” 包装了需求。如果当时你直接怼 “这不是人话”，事儿肯定黄了；但你做了 “沟通翻译”—— 把他的 “异想天开” 拆成 “用特种钢降厚度、保强度”，反而成了双赢。
/ Z' c! e- y! z2 F8 x6 [
这其实点透了 “技术沟通难” 的核心：双方都在用自己的 “专业语言” 说话，却没做 “翻译”。
) U% L9 q& [0 H) y' d
. W! `9 i3 o2 o( m  z技术人习惯 “用逻辑和结果说话”，需求方（比如你我）习惯 “用感受和过程说话”，比如：
6 ]+ i" L2 _6 [& n8 F

• 需求方说 “这个功能能不能快点？”，技术人可能会想 “‘快点’是多久？今天还是明天？优先度比手上的 bug 高吗？”；
  

• 技术人说 “这个接口要重构，得三天”，需求方可能会慌 “重构是啥？会不会影响现有功能？三天后真的能好吗？”。
• 
  

如果想减少这种错位，其实两边都能做点小调整：
. |( H2 _2 n+ _: ]0 R
对技术同学来说，不用学 “油嘴滑舌”，只要多补一步 “信息同步”：比如做需求时，每天花 1 分钟发句 “今天在调登录接口，明天能联调”；临时改任务时，说句 “刚接了个紧急 bug，你的需求会延后半天，我处理完马上回”—— 不用多复杂，却能让对方少很多焦虑。
: ~. Q/ {8 ?, Z& |; m1 L  o: x
) R9 U" X" g' F3 E4 i8 @对我们需求方来说，也可以多给点 “沟通锚点”：比如提需求时不说 “快点”，而是说 “这个功能下周三要上线，你看能不能排优先级？如果有困难，咱们可以先砍次要功能”；发消息时，如果不是紧急事，加句 “不用马上回，你有空时说下进度就行”—— 给技术留够 “不被打断” 的空间，反而能减少 “不回消息” 的情况。
# o, d0 u" g9 h- J7 A' P5 D5 P% q9 U
7 |0 C) E2 _7 b4 {2 V# Q其实我身边也有沟通特别顺畅的技术：有个后端会主动说 “这个需求我评估要 5 天，其中第三天要等设计图，到时候可能要跟你确认细节”；还有个前端会把 “技术难点” 转成 “用户能感知的影响”，比如 “这个动画效果如果要做，加载速度会慢 2 秒，你看是保速度还是保效果？”—— 他们不是天生会沟通，而是懂了 “沟通的本质是对齐认知，不是比谁更专业”。
4 Y6 c6 \) x/ l4 W. W
最后想问问大家：你遇到过哪些 “技术沟通崩溃瞬间”？是怎么解决的？不管是技术同学还是需求方，都来聊聊 —— 毕竟把 “错位” 聊透了，下次合作才能少点糟心，多点顺畅～


! f. ?7 z& P3 I# t4 \; p