如何有效与同事沟通：减少重复提问的实用技巧How to Talk to Your Coworkers

明明之前在两三个地方已经解释过同样的问题，他们却还在重复提问。为什么他们不明白呢？明明答案就在 Jira 上，他们为何还要问同样的问题？他们是愚笨吗？还是懒惰？难道不花时间阅读吗？

开发者们经常抱怨这种情况：明明写了清晰的文档和说明，人们仍要求他们打电话沟通。这种问题太频繁了，值得探讨。信息过多和过少一样令人困惑。但需要补充的是，重复是正常的。实际上，重复应该是一种常用工具。

作为开发者，我们阅读指令来完成任务。这些任务通常以精心编写的文档形式呈现，包含可实施和检查的要点、需求和验收标准。有时，你甚至无需了解功能实际作用，只需按说明实现即可。

在其他非技术岗位中，工作依赖对话——一种有损信息的传递方式。例如，非技术经理提出新功能需求时，会与软件架构师对话，而架构师需将对话转化为开发者能执行的规范。

一方用指令沟通，另一方用对话交流。这就是他们常互相误解的原因。

每当听到开发者抱怨有人反复询问已解答的问题，就知道是因为双方使用了不同的“语言”。

即使你提供了答案，也不代表所有人看到或理解。比如你通过描述 API 交互来解释功能原理，但受众可能根本不了解 API 协同工作的概念，甚至不知道什么是 API。

类似地，若管理者认为会议是开发流程的必要环节，可能会发现他人拒绝参会。对他们而言，会议是工作方式，而其他人更依赖书面指令。

简单来说，解决这个问题的办法是：翻译并重复。

这里的“翻译”不是指语言转换，而是指调整表达框架。提供信息时容易陷入过度技术化或细节化的陷阱，但信息过量等于无效。与其强调解决方案的实现过程，不如聚焦其最终效果。

例如，我曾修复一个显示月度销售数据的组件问题：少数客户投诉后发现，“夜间运行的任务”对某些用户来说是白天。他们在任务执行前访问该组件，数据缓存长达一天，导致最多看到24小时前的旧数据。我们通过重构数据展示逻辑（移除缓存、改用实时更新的规范化表格）解决了问题，避免了复杂查询的需求。

内部我们创建了新的 API 并重构了数据库表。在 UI 上显示的只是几个简单的数字，但实际背后的逻辑要复杂得多。不过向经理解释时，他们不需要了解 cron 任务、缓存策略，或者新旧系统的对比细节。

他们只需要知道：

“我们更新了小部件以显示实时数据，并为性能添加了更智能的缓存策略。”

这就是全部答案。如果他们想要技术细节，我们可以另开一谈。

但开发者通常会先进行技术层面的复盘——因为如果另一个开发者问起，我们也希望得到这样的回答。我们需要根本原因、堆栈跟踪、PR 链接。问题是，不同受众需要不同的信息。

如果在会议上先抛出技术拆解，虽然听起来很专业，但非技术参会者会一脸茫然地离开，随后在 Slack 上重复提问。目标不是完全消除疑问。事实上，无论你怎么调整语言适配听众，总有人会重复你已解答过的问题。这正是重复的价值所在。

观察孩子学习的过程很有趣。当我和孩子们做一年级数学题时，加减法都用同样的方法教。最初他们就是听不懂。我会掰手指、用冰棍棒，甚至脚趾头辅助计算。我的方法对他们来说有时并不直观，做完一整份作业我能看出他们只是在机械应付。但我们每天坚持用同一套流程，毫无偏差。最终，他们居然真的学会了算数。

当然不能把同事比作小孩，但对所有人而言，重复都有效。每次听你的解释，他们能多理解一点内容。当你反复说“我们升级了支付 SDK”时，他们可能完全不懂，这时停下来单独解释这个概念并不会让他们豁然开朗。但他们或许会后自己搜索“SDK”“支付 SDK”。下次你再次解释时，他们的理解程度就更深一层。每一次重复都在帮助他们逐步拼凑全貌。

对依赖沟通来协调工作的管理者同样适用。虽然从会议中提取明确需求很难，但信息本就存在，只需提炼和重组。坦诚地说，对话往往是启动项目的不错方式。

设想一下：如果带着僵化的详细指令而来，却完全不了解代码库的实际运作情况。通过对话，功能才能逐渐成型。开发者可以提出异议、指出问题，并根据当前基础设施状况调整范围。

这种你来我往的讨论，正是将原始创意转化为可执行方案的关键过滤机制。

所以你在 Jira 或 Slack 里写满认证流程和令牌过期逻辑的详细注释却被无视，并非同事懒惰——而是你用了一种他们无法理解的“语言”。他们再次追问，并非想惹恼你，而是从你提供的信息中无法提取所需答案。

你不需要写更长的注释或用粗体强调更多内容。相反，先问自己：所写的内容是否针对了正确的受众？然后将其转化为更易理解的形式。并做好多次重复的准备，直到真正传达到位。