1.1 沟通能力
← 非技术技能 | 首页 | 下一节: 1.2 团队协作 →
邮件礼仪
核心原则：清晰、尊重、珍惜读者时间。
关键规则（18 条框架）：
- 选对沟通渠道：邮件不一定是最佳方式。敏感话题、需要反复讨论的事项，电话或面谈更高效。邮件适合确认下一步、分享决策或同时通知多人。
- 善用 CC / BCC / Reply All：CC 是"知会但不强制回复"；BCC 用于大群发或隐私保护；Reply All 仅当回复对所有人都有意义。
- 清晰的标题行：写明主旨而非泛泛的"Hello"或"问题"，如"Q3 预算时间线的疑问"。
- 恰当的问候语和署名：首次接触用正式称呼，内部同事可用更随意的风格，匹配对方的语气。不确定时，选更正式的风格然后调整。
- 简洁完整：开头就说明目的，单一主题，结构清晰。包含所有相关信息，让收件人无需追问就能行动。
- 专业语气：避免俚语、过度随意或被动攻击的语气。追求礼貌和温暖，同时展现自信。
- 慎用表情和幽默：外部沟通最好不用 emoji；幽默在文字中容易被误解。
- 描述附件：说明附件的用途和期望对方做什么（请审阅？请签署？）。使用描述性文件名，常见格式，控制文件大小。
- 把每次见面/电话讨论复述为邮件：创建书面记录，避免误解。
- 每封邮件都是永久记录：可被转发、截图、下载、打印。情绪上头时别写、别发。
- 发送前校对：拼写、语法、日期、收件人姓名。
- 24 小时跟进原则：收到邮件尽量 24 小时内回复；发出邮件至少等 24 小时再跟催。
- 外出自动回复：休假前设定，告知离开日期和紧急联系人。
评估邮件质量的"7C"框架：Clear（清晰）、Concise（简洁）、Concrete（具体）、Correct（正确）、Coherent（连贯）、Complete（完整）、Courteous（礼貌）。
即时通讯最佳实践
- 使用消息线程组织讨论：将特定话题的讨论收敛在线程中，避免频道被单一话题刷屏。线程支持独立的通知管理、可单独打开窗口查看。
- 避免碎片化沟通：一次把话说完整，减少"在吗？""ping"式的无内容消息。
- 减少不必要的 @全体成员。
打断的真实成本
Game Developer Magazine 对 86 名程序员的 10,000 次编程会话分析和 414 份程序员调查揭示：
- 一次打断损失半小时：普通人被重大打断后需要约 23 分钟恢复，程序员至少再加 10 分钟才能重新开始编辑代码。
- 在编辑方法过程中被打断，只有 10% 的情况下能在 1 分钟内恢复工作。
- 程序员每天平均只有一段不被打断的完整两小时。
- 打断发生的时机越糟——记忆负荷越高——影响越大。
- 从高记忆负荷切换到低记忆负荷状态需要约 7 分钟，打断几乎从不"无代价"。
- 被中断时长与恢复时间成正比。
Paul Graham 的两种日程理论
- Maker's Schedule（创造者日程）：程序员、作家等需要深度专注的人。一个会议就能"毁掉整个下午"——将下午切为两段，每段都太短。更糟的是连锁效应：知道下午会被打断，上午就更不愿意启动有挑战性的任务。"一个精心安排的会议就能杀死最有野心项目所需要的士气。"
- Manager's Schedule（管理者日程）：按小时切分，随时有下一件事。对管理者来说会议不是问题——日程本就是按小时组织的。
对策：设定核心编码时段（如"上午不开会"）、使用番茄钟、尽量减少即时消息打扰、用异步沟通替代同步打断。
来源
- Grammarly — Email Etiquette: Definition, Rules, and Examples: https://www.grammarly.com/blog/email-etiquette-rules-to-know/
- Slack Help Center — Use threads to organize discussions: https://slack.com/intl/en-es/help/articles/115000769927
- devm.io — And it's gone — The true cost of interruptions: https://devm.io/careers/aaaand-gone-true-cost-interruptions-128741
- Paul Graham — Maker's Schedule, Manager's Schedule (referenced within)