高效沟通，让每个人都能参与

默认公开、兼顾不同成员的参与需求、主动提供充分的背景信息——这三项沟通原则，能帮助工程团队更好地协作，推动工作向前进展。

清晰的沟通是软件团队高效运作的关键。充分的背景信息和一致的目标，能够帮助团队更快地交付真正需要的产品。反之，沟通不清、背景缺失，轻则让团队失去方向，重则造成混乱。

对于采用远程或混合办公模式的分布式团队，这一点尤为重要。更加开放、透明且兼顾不同成员需求的沟通方式，能让工程师更自主地开展工作，从而提高效率。建立知识共享的文化，让必要的信息在组织内充分流动，有助于大家朝着共同目标前进，同时减少不必要的干扰和不确定性。

默认公开沟通

对许多组织而言，让重要沟通公开透明并不容易，但这种转变至关重要。

所谓“默认公开”，是指日常工作沟通应优先选择组织内部的公开渠道，尽量避免把有共享价值的信息留在私信、非公开会议或其他封闭的交流中。当然，有些情况适合私下沟通，下文会具体说明。

人们常常担心，公开沟通会带来更多信息，分散大家的注意力。这种担忧可以理解，但公开沟通的影响不能仅用信息量的多少来衡量。

我见过许多这样的例子：默认公开沟通，能够促进参与，帮助人们更全面地理解工作背景，并围绕共同目标达成一致。关键在于提高有效信息的比例，减少无关噪声。即使人们因此需要投入一些额外的注意力，这种投入也有价值：需要或希望了解某项信息的人，能够及时找到它。

帮助团队获取所需的信息

默认公开之后，大量信息随之涌现，人们起初可能不知道该如何筛选。

这时，管理者就需要发挥作用，帮助团队成员理解和使用信息，并引导大家判断：哪些信息值得关注，又应在什么时候关注。

只要给予团队足够的信任，你很快就会发现，成员通常会把注意力放在推进工作所需的信息上。真正的收益在于，他们现在能够接触到整个组织的信息，从中了解更完整的工作背景，并发现与他人合作的机会。

选择合适的沟通范围

决定在哪里沟通时，我通常会先考虑：这件事与谁有关？

• 个人层面：内容仅涉及某个人，且适合私下交流，可以使用私信。
• 团队层面：内容涉及某个团队的工作，应在相应的团队渠道中讨论。
• 跨团队层面：内容涉及多个团队，应选择相关团队都能访问的沟通渠道。

这只是一个起点，实际选择还需要考虑其他因素。但它提醒我们，许多工作讨论并没有必要私下进行。即使问题是向某个人提出的，答案也可能对其他人有用。

哪些情况适合私下沟通？

私下沟通有其必要性，只是不应成为组织的默认方式。涉及敏感信息的讨论、同事之间的日常闲聊，以及针对个人的直接反馈，通常更适合私下进行。

让无法在场的人也能参与

这里所说的“包容”，是指在沟通时主动考虑更广泛的参与者，尤其是那些无法实时在场的人。“默认公开”关注的是信息是否可见，而包容的沟通还要进一步确保：人们能够获取关键信息、表达意见并参与协作。

我们都遇到过这样的情况：休假归来，或只是外出看了趟医生，就错过了一场重要会议。为了弄清楚发生了什么，不得不四处找人询问，也失去了在讨论中表达意见的机会。

其实，我们可以做得更好。

每场会议都应有议程和配套文档

高效的会议需要一份目标明确的议程。在此基础上，还可以准备一份持续更新的共享文档，为会前准备、会中讨论和会后跟进提供支持。

准备文档的过程，能帮助组织者明确希望通过会议达成什么，也能让其他人提前理解会议目标。有时，大家通过文档就能解决问题，甚至不必再开会。

提前发送材料，还能让无法参会的人有机会提出意见，并在会后查阅讨论记录。

共享文档也是形成共识、记录决策和跟进行动的有效方式，同时能让参会者共同承担记录工作。会议组织者仍应负责制定议程、推动讨论，但所有受邀者都可以在同一份文档中补充信息、记录要点并参与协作。

这套做法也可以融入团队已有的协作流程。例如，使用 Worktile 这类兼具项目、任务和文档功能的协作工具时，可以用文档整理议程和讨论结论，再把后续行动落实为任务，明确负责人和截止时间。这样，未能参会的人既能了解决策背景，也能知道接下来需要做什么。

配套文档应包含哪些内容？

具体内容取决于会议类型，但通常应考虑以下几个方面：

• 议程与目的：这次会议或这份文档要讨论什么、解决什么问题？
• 预期成果：希望达成什么共识、作出什么决定，或明确哪些后续行动？
• 讨论价值：为什么值得讨论？这次讨论能为工作带来什么帮助？
• 意见与记录：为参与者留出补充问题、建议和背景信息的空间，并记录会议中的讨论要点。

案例：两种不同的会议方式

下面两场会议的目标相同：就一项需要多个团队协作的新功能达成共识，并争取在季度末前完成交付。

示例一：未充分考虑参与者的需要

约翰安排了一场名为“功能协调”的会议，时长为30分钟，没有提供议程。

多位团队负责人收到了邀请，却不清楚会议的具体目的，也不知道团队里谁最适合参加。由于缺少信息，他们决定亲自出席。其中一位负责人因故无法参会。

会议的前10分钟用于展示幻灯片，介绍会议目的和讨论要点。接下来是约15分钟的问答，但其中只有两个问题与约翰真正希望讨论的内容有关。最后5分钟，大家根据幻灯片中的设计方案匆忙作出决定，认为可以在季度末前交付这项功能。

此时，仍有一些问题尚未解答，后续行动也没有明确。不过，约翰认为，除未能出席的负责人外，其他团队负责人都已认可季度末交付的安排。

示例二：让未能在场的人也能参与

约翰同样安排了一场30分钟的会议，主题是“确认功能 X 的交付方案，协调季度末交付安排”。邀请中附有明确的议程：

本次会议将讨论功能 X 的交付方案，目标是在季度末前完成交付。我希望大家就交付方式达成共识，并指出方案中的潜在问题。

请提前查看演示材料（链接）和共享文档（链接）。我们将通过共享文档收集意见、记录后续行动，确保无法参会的人也能参与。

如有问题，请提前写入文档，我们将在会上讨论。

预期成果：

• 就功能 X 的交付预期达成一致。
• 识别潜在问题，明确后续行动。
• 评估按季度末期限完成交付的把握。

多位团队负责人收到了邀请。由于会议目的明确，一位负责人安排了团队中的一名同事参加，因为这次讨论能为其提供有价值的成长机会；另一位负责人判断本次讨论不需要本团队提供意见，因此谢绝了邀请。

还有一位负责人无法出席，但他提前阅读了演示材料和共享文档，并留下意见：“要在本季度末前交付功能 X，必须先完成 Y，否则无法按期交付。”他还补充了原因和可能的解决办法。

会议开始后，大家只用了5分钟快速回顾演示材料，因为大多数人已经提前阅读，并在文档中提出了问题。一部分问题会前就已解决，其余问题也在接下来的5分钟内得到解答。

随后，大家用10分钟讨论那位缺席负责人提出的关键问题。借助他提供的背景信息和建议，与会者明确了现有方案的障碍，并讨论了可行的解决办法。

接着，大家在共享文档中记录了需要调整的设计和后续行动，并快速评估了按期交付的把握。所有人都表示，在完成这些调整后，有信心按期交付。

会议提前5分钟结束。约翰很高兴：他既获得了团队的支持，也明确了交付前必须完成的工作。

这两个例子说明了什么？

两场会议结束时，约翰都认为自己已经掌握了季度末交付所需的信息。但第一次会议带来的信心，可能并没有充分依据。由于缺少那位未能参会者的意见，团队很可能无法按期交付，或不得不在最后关头匆忙修改方案。

第二次会议则让关键意见得到了充分考虑。一位团队负责人为同事提供了成长机会，另一位负责人免去了不必要的参会时间，可以专注于其他工作。

会议还提前5分钟结束，并留下了书面记录。即使没有参会，其他人也能方便地了解会议决定及后续安排。

主动提供充分的背景信息

要让沟通有效，就应站在接收者的角度组织信息，让对方能够理解问题并采取行动。

案例：两种不同的提问方式

下面是同一个问题在团队即时通信工具中的两种沟通过程。

示例一：信息零散，依赖反复追问巴里（9:00）：**大家好，我有个关于 X 项目的问题。

巴里（10:00）：这个问题很急，有人能帮忙吗？

格蕾丝（10:30）：嗨，巴里，需要什么帮助？

巴里（10:36）：嗨，格蕾丝，谢谢！我想问一下你们用来更新 X 项目客户信息的 API。

格蕾丝（10:38）：可以，具体是什么问题？

巴里（10:40）：调用接口时，我发现有些请求头的要求不太清楚，不知道应该填写哪些信息。

格蕾丝（13:30）：抱歉，巴里，我这几个小时一直在开会。你不清楚的是某个请求头，还是所有请求头？相关文档里的说明够用吗？

巴里（14:15）：没关系。我今天上午看过文档，但感觉不是最新的。我遇到问题的是 person 请求头。

格蕾丝（14:20）：使用 person 时具体遇到了什么问题？

巴里（14:35）：每次调用都返回 400: Bad Request。

格蕾丝（14:48）：我在日志里看到了格式有误的请求，已经更新文档，补充了正确的请求头要求。你试试看能不能解决问题。

巴里（14:50）：太好了，谢谢格蕾丝，现在可以了。

示例二：一次提供足够的信息

巴里（9:25）：大家好，我正在调用接口 /update/customer/id:{customer_id}，但一直收到 400: Bad Request 错误。

查看文档（链接）后，我把问题定位到了 person 请求头。日志（链接）显示其中需要一个 title 字段，但文档（链接）中没有说明这一要求。

这个问题比较紧急：它阻碍了我正在开发的新功能，而且团队里另一位同事的功能也依赖我的功能先发布。

请问是我的请求有问题，还是文档遗漏了说明？

格蕾丝（10:30）：嗨，巴里，收到。我会尽快查看并回复。

格蕾丝（10:35）：巴里，你说得对，文档确实漏写了 title 字段的要求。你可以先参考这个示例（链接）修改请求，我会尽快更新文档。试试看是否解决了问题。

巴里（10:40）：问题解决了，谢谢格蕾丝！祝你今天愉快。

这两个例子说明了什么？

首先，这类对话的大部分回复都适合放在同一条消息的讨论串中，方便集中阅读和后续查找。更重要的是，两种提问方式带来了截然不同的沟通效率。

第一个例子从提出问题到解决，花了近6个小时；第二个例子只用了1小时15分钟。虽然巴里在第二个例子中多花了一些时间收集信息、整理问题，但这份准备让格蕾丝能够直接着手处理，减少了反复追问和等待。

两次沟通最终都解决了问题，但第二次留下的记录更完整，其他人也更容易理解问题的背景、原因和解决办法。

当然，巴里和格蕾丝也可以通过一次实时通话，减少这些来回。但这首先要求巴里知道该找谁，也要求对方能暂时放下手头工作。如果通话内容没有记录并共享，后来遇到同样问题的人仍然需要重新求助。

因此，问题解决后，还应把有复用价值的信息整理到团队的知识文档中。对于研发团队，可以借助 PingCode 的研发管理与 Wiki 知识记录能力，在推进需求、开发、测试和发布的过程中，持续记录背景信息、方案调整和问题处理经验。后来接手工作的成员便有据可查，提问时也更容易提供完整的上下文。

从日常沟通开始改变

落实这些做法，需要组织逐步改变既有的沟通文化。随着时间推移，收益会越来越明显：团队之间能更好地协调，成员也能更清楚地理解组织的目标和优先事项。

这些做法未必会立刻大幅提升交付速度，但充分的背景信息和一致的目标，能帮助团队把精力放在正确的事情上。此外，它们还能节省时间、为成员提供成长机会、改善文档，并减少不必要的会议。

不妨从以下几个问题开始，审视团队的日常沟通：

• 每场会议是否都有明确的议程和预期成果？
• 除确有必要保密的内容外，工作沟通是否默认在组织内部公开？是否有本应共享的信息被留在私下交流中？
• 大家是否理解并认同共同的愿景？如果没有，怎样沟通才能增进理解、形成共识？
• 提问、讨论或作出决定时，是否提供了足够的背景信息，让相关人员能够理解并参与？