软件作者 Ashley Rolf 在 2 月 12 日发表的博客《Stop trying to engineer your way out of listening to people》，批评了一种在产品和工程团队里非常常见的习惯：当沟通出了问题，大家第一反应不是去理解人，而是继续造流程、造框架、造“系统”，试图把“听人说话”也工程化。

这篇文章没有新概念，也不是方法论大全，但它点得很准。对今天的软件行业来说，真正稀缺的不是再多一个协作框架，而是承认一个不太体面的事实：很多团队并非不会沟通，而是不愿意承担倾听的时间成本、认知成本和组织成本。

问题不在“没有框架”，而在团队拿框架当挡箭牌

Rolf 的核心判断很直接：问题通常不只是“人和人没交流”，更常见的是“交流了，但没人真在听”。她特别反对近年产品圈、设计圈把沟通问题重新包装成工程语言，比如 framework、system，甚至时髦的 socio-technical system。她的意思不是这些概念没用，而是它们常被拿来绕开更难的工作：承认对方知道的世界和你不一样。

这件事在软件行业并不新。敏捷开发从 2001 年写下“个体和互动高于流程和工具”，本来就是在纠正瀑布式开发里“需求文档交接完就算完成沟通”的毛病。可二十多年后，很多团队又把敏捷本身做成了新的流程崇拜：站会、冲刺、路线图、模板、研究回放，一样不少，最后用户还是觉得产品没人懂自己。

这也是这篇文章真正重要的地方。它不是在讨论沟通礼仪，而是在提醒一个商业问题：当团队把“理解人”外包给流程，产品就会越来越像一条按图施工却没人想走的路。作者文中用了《海绵宝宝》里“未完工道路开通”的截图，讽刺意味很重，但放到现实里并不夸张。企业软件、内部系统、医疗健康工具、政务数字化项目里，这种“功能交付了，但没人愿用”的场景到处都是。

听不懂用户，最后会变成更贵的技术债

原文列了一串常见误区，比如把“听”理解成“照单全收”、把别人简单分成“技术”和“非技术”、默认别人拥有和自己一样的精力、技能、金钱和风险承受能力。这些看起来像沟通常识，放进产品开发里，后果却很具体。

最直接的代价，是错误需求被代码固化。作者提到，每一次误解，都会在代码里留下以后还得继续维护的东西。这句话很朴素，但比很多“用户洞察”文章更接近现实。工程团队最熟悉的技术债，往往不是写了多烂的代码，而是把一个被误解的问题，认真地实现了三个月。

这里可以对照一个行业里常见的错位：很多团队愿意花预算采购用户研究工具、埋点分析平台、反馈管理系统，却不愿意给跨职能讨论留出足够时间。前者容易采购、容易汇报、容易做成仪表盘；后者慢、模糊、带摩擦，还可能暴露组织内部谁真正掌握决策权。B2B 软件尤其如此。原文里有个很准确的判断：80 个企业客户，不等于一个“80 人样本”。因为企业采购和使用从来不是单一用户行为，背后有组织关系、隐性权力、部门利益和流程约束。

这也是很多消费互联网从业者转做企业产品时最容易吃亏的地方。To C 的反馈往往能快速反映在留存、转化和投诉里，To B 则经常是采购说一套、管理员要一套、一线员工再来一套。你以为你在做“客户需求”，其实你只听见了会议室里声音最大的人。

最受影响的，不是“用户体验”四个字，而是做决策的人

这篇文章最该读的人，不只是设计师，也不是一线工程师，而是产品负责人、研发主管和企业内部的数字化决策者。因为是否真正倾听，最后体现为资源怎么花、项目怎么排、需求谁说了算。

对工程经理来说，这意味着一个不太舒服的现实：你不能指望靠更详细的 PRD、更多的 Jira 字段、更多同步会议，把理解偏差彻底消灭。文档仍然重要，但文档只能记录已经达成的共识，不能代替共识的生成过程。

对企业客户来说，这也解释了为什么很多数字化项目总在“上线”之后才真正开始返工。尤其在医疗、教育、政府和大型传统企业里，真实使用者的工作状态会随着政策、预算、考核和人员流动而变化。原文提到，人和组织都不是静止的；固定需求、长周期交付天然容易失真。这其实就是很多大型 IT 项目迟迟达不到预期的底层原因：项目按时交付了，现场已经变了。

这里有一个原文没展开、但很关键的限制条件：不是所有团队都能“多听、多聊、多迭代”。受监管行业、强合规场景、外包主导项目，往往合同边界硬、试错空间小、用户接触受限。也就是说，倾听很重要，但它也需要组织愿意付出时间，并接受需求在过程中被修正。这恰恰是许多公司嘴上认同、行动上最难做到的地方。

这不是反对系统化，而是反对拿系统化冒充理解

如果只看标题，这篇文章容易被误读成“反方法论”“反流程”。其实不是。Jobs To Be Done、Outcome-Driven Innovation、同理心地图这些方法，作者都没有否定。她反对的是另一件事：团队把方法当成理解已经发生的证明。

这是今天 AI 产品开发里尤其值得警惕的倾向。越来越多团队习惯用日志、埋点、A/B 测试和模型指标解释一切，好像只要数据够多，就能自动替代人与人之间的解释工作。但在高风险、低频、强情境的使用场景里，数据本身经常不说人话。一个用户没有点某个按钮，可能不是需求不存在，而是流程太复杂、权限不对、或他在那个时刻根本没有余裕去完成你设计的动作。

所以，这篇文章真正不重要的部分，是它并没有提供一个新框架，也没有给出可复制的“听人模板”。如果你期待的是一套立刻落地的产品工具包，这篇文章会让人失望。可它重要的部分，恰好在于逼团队回到一个老问题：在复杂系统里，人仍然不是变量噪音，而是问题本身的一部分。

对软件行业来说，这个提醒来得不早，也不晚。工具越来越多，数据越来越细，AI 让原型和交付速度越来越快，结果往往是产品更容易做出来，也更容易做错。做得越快，听错人的代价越高。