← #791

别再试图用工程手段绕开倾听他人

查看原文 HN 讨论

文章摘要

软件行业一直在尝试用各种”工程化的方法”去回避一个本质问题：和人沟通、真正听懂人。作者 Ashley Rolfmore 在这篇文章里直接戳破：很多团队搞 JTBD、Outcome Driven Innovation、empathy mapping、用户旅程图等等所谓”框架”，本质都是在自欺欺人——你不是在更好地理解用户，你是在用流程把”听人说话”这件累人的事情外包出去。她毫不客气地写道：”问题不在于你缺少框架，而在于你正在逃避做这件事。”

文章给出了 9 个最常见的”伪倾听陷阱”：

1. 把”听”当成”照做”：理解用户真正需要什么，和原样执行他们的字面要求，是完全两码事。
2. 专家盲区：你高估了别人在你这一行的常识，导致鸡同鸭讲。
3. 过度简化”懂技术”：知识有谱系，不是只有”懂代码”和”小白”两类人。
4. 忽视资源差异：用户的精力、技能、预算、风险承受度差异极大，决定他们关心的问题。
5. 把单点案例泛化：见过一个有某种特征的人，不代表所有这种人都一样。
6. 假设一切静态：人和组织都在变化，需求和优先级会随时间漂移。
7. 混淆话语和思想：人们说出口的，往往不是他们脑子里真正想的。
8. 下评判：一旦预设对方在胡说，你就再也听不到东西了。
9. 把群体当成铁板一块：尤其在 B2B 场景里，每一个具体的关系才是关键。

后果就是企业在做出错误判断后还浑然不知——错失市场机会、错配资源、累积技术债，最终一切都会以代价的形式回到团队头上。文章最后的呼吁很简单：放下那些华丽的工具，去和人坐下来真正聊天。

HN 评论精华

• nlawalker：用文章里那张”剪彩仪式”的漫画隐喻补了一刀——很多项目里”不沟通”和”不倾听”并不是失误，而是因为大多数人本来就不要那条路、只要那个剪彩仪式，结果他们如愿以偿了。这个评论极其犀利，把问题从沟通技巧推到了组织激励层面。

• apsurd：同意问题真实存在，但认为这篇文章读起来更像一次抱怨。”沟通是人类共同的难题”，把锅一股脑甩给开发者”不会听”显得居高临下。最优秀的沟通者其实是翻译者——把信息变得不解自明。也正因为人不会主动改变沟通习惯，组织才不得不去搞系统和工程化的兜底机制，骂个人是无效的。

• onion2k：补了一个对偶版：”你假设别人嘴里说的就是他脑子里想的”——反过来同样成立：”说话的人也假设听的人和自己脑子里在想同一件事”。所以真正的解药是写下来：如果一个会议的 PPT 上某个目标只用了一行 6 个字的 bullet 来说明，意味着没有人真正理解它；连一页文档都写不出来的人，根本没想清楚自己要什么。

• sublinear：直接揶揄文章第 8 条”你在评判别人”——结果作者自己一上来就预设读者动机不良。”假设对方有恶意会立刻杀死所有生产力”，所以他读到一半就关掉了。他认为没有捷径，只能在低风险环境里反复经历困难对话，慢慢攒经验。

• yogigan：高度认同”专家盲区”那一条。他承认自己曾对用户不懂某些他多年内化的常识感到沮丧，但反过来想——这些用户在他们各自的领域里也内化了同样厚的知识，知识不是缺席，而只是在别处。

• faangguyindia：站在工程师的立场吐槽——和非技术人沟通最累的不是听不懂，而是对方习惯说”能不能加个 X”、”能不能改下 Y”，却从不思考每一个动作的成本。”我什么都能做，但每个动作都有代价”。

• hyfgfh：警告未来更糟——AI 时代沟通会进一步退化。当所有人开始用”yes-and 的自动补全”对话，对方只会说”Great idea!”，所有真实信号都会被淹没。