对于工程领导者来说，写作不仅是沟通工具，也直接影响团队协作、项目执行和领导力。我们写下的文字，真的值得别人花时间阅读吗？

我们都知道，对于工程领导者来说，大部分工作其实是在写作，而不是编码。但我们很少认真讨论另一个问题：我们写出来的东西，真的值得别人读吗？

在工程管理中，邮件、项目更新、设计文档、提案和团队愿景等书面内容，构成了日常团队沟通的重要部分。写作是否清晰，往往会直接影响信息能否准确传递，以及团队能否形成一致的理解。

在互联网上写作，天然存在一种反馈机制：如果文章质量不高，就很难获得阅读量和互动。到了下一篇，你会主动调整自己的写法，希望改善这些指标。

但在职场中，随着职位和资历的提升，这种反馈机制往往会逐渐消失。你的同事和下属因为工作需要，不得不阅读你的邮件、提案和各种文档，因此你很容易把“有人读”误认为“写得好”。

可现实往往不是这样。

你的同事大概不会直接对你说：

“你的提案我读了三遍，才终于明白你想说什么。”

或者：

“哦，那份会议记录？我直接标记成已读了。”

然而，你的写作质量会直接影响团队的健康度和产品的执行效果。如果团队成员对团队愿景、使命以及未来的发展方向始终缺乏清晰的认识，这本身就是沟通出了问题的信号。

因此，我们应该像打造产品一样对待发给同事的文字：始终把用户——也就是读者——放在第一位，努力为他们创造良好的阅读体验。

工程团队写作：先想清楚你为什么写

在开始写任何一封邮件、一次状态更新、一份提案，或者任何超过几句话的内容之前，先问自己三个问题：

• 你在为谁写？
• 你希望对方读完之后做什么？
• 当他们忘掉你写的大部分内容之后，你最希望他们记住什么？

当然，你为一份文字投入多少精力，应该与它本身的重要程度相匹配。一份每周例会总结和一份描述未来三年产品愿景的文档，显然不需要投入同等程度的时间和精力。

但无论你觉得眼前的写作任务多么不起眼，这三个问题都值得你至少花一分钟认真想一想。

假设你正在阅读另一个团队发来的每周项目进展邮件，内容是这样的：

Foo 团队最新进展（2021 年 4 月 12 日）

本周：

• 已完成：@cameron 对 foo 后端进行了一些追踪分析，记录见此处。
• 已完成：@taylor 和 @jamie 完成了新移动端 UI 原型的用户访谈。
• 进行中：@taylor 正在开始开发新的移动端用户界面。

下周：

• @cameron 将基于追踪分析继续优化延迟，并与 @jess 讨论。
• @jamie 下周休假。
• @taylor 将继续开发 foo 的新移动端用户界面。
• @taylor 将帮助新加入团队的 @jackie 熟悉工作。

看完之后，你很可能会产生几个问题：

我们为什么要做 foo？

如果你不是 foo 团队的成员，读完这封邮件之后，你到底应该做什么？

而且，如果 Taylor 和 Jamie 这周一直在一起工作，Taylor 难道还不知道 Jamie 下周要休假吗？

这种项目汇报通常是怎么形成的？

一般来说，每位团队成员会被要求填写自己的工作进展，用来向经理同步情况。大家都很忙，而经理本身又了解项目背景，所以成员自然不会补充太多上下文。

同样忙碌的经理为了完成“向组织同步项目进展”这项工作，又把这些内部笔记直接整理成一封团队周报，发给更大范围的人。

于是，原本只面向团队内部的信息，被原封不动地扩展到了整个组织。

问题就在这里：受众变了，内容却没有跟着变。

下面是同一个项目的另一种进展更新方式：

Speedy Foo 项目最新进展（2021 年 4 月 12 日）

我们在做什么？

• 团队 2021 年的目标是提升用户留存率。用户调研显示，foo 是用户进入产品后首先使用的功能之一，因此我们希望让 foo 的操作尽可能快速、简单。
• 第二季度我们会重点推进两件事：（1）优化移动端 foo 的加载速度；（2）重新设计移动端界面，让用户能够更轻松地完成[常见任务]。

我们需要哪些帮助？

• 服务端团队：@jess 正在审核 @cameron 撰写的 API 调用整合方案。如果你对[提案中尚未解决的问题]有相关经验，非常欢迎提供反馈；可以联系 @jess 了解最新情况。
• **移动端团队：**预计 @taylor 下周会开始提交一些 Pull Request，因为移动端 UI 开发即将启动（规范见此处）。我们正在与[移动端负责人]协调，希望安排一位联系人帮助解决 @taylor 在[问题]上的阻塞。如果你可以参与，请告诉他们。

对组织中的其他人来说，哪些信息最有价值？

• @cameron 发现 foo 后端服务存在一些重复的 API 调用，并在此处整理了一份分析。如果你也希望对产品的其他部分进行类似分析，可以参考这份材料。
• @taylor 和 @jamie 完成了一轮用户访谈（访谈记录见此处）。其中有一个令人意外的发现：用户真正关心的是能否通过 foo 完成 bar，而他们实际上并没有对 baz 感到困惑。

这封邮件为什么更好？

因为它做对了几件重要的事：

• 它提醒读者：我们为什么要做这项工作。
• 它清楚地告诉读者：每一部分能获得什么信息。
• 它明确说明：团队希望哪些人采取什么行动。
• 它没有假设读者会从头到尾逐字阅读，而是优先呈现最重要的信息。
• 它删掉了在当前语境下并不重要的内容。

如果经理需要了解项目的日常进展，那么团队内部的状态更新当然没有问题。

但没有必要仅仅因为“每周必须发一次更新”，就用大量无关信息塞满其他团队成员的收件箱。

其他团队通常并不关心你每天具体做了什么。他们真正关心的是：能从你的工作中学到什么，以及你是否需要他们采取行动。

把他们真正需要的信息提供出来，并组织成容易阅读和理解的形式。

如果团队日常使用 Worktile 这类项目协作工具，也可以把项目状态、任务进展和相关文档集中到统一的协作空间中，让需要了解情况的人按需查看，而不是把所有细节都塞进一封面向所有人的周报里。

剩下的，删掉。

如何编辑工程文档：从读者的角度重新审视文字

如果你写的只是一份普通的周报或会议记录，当然没有必要花几个小时反复润色。你还有更重要的事情要做。

但对于那些真正重要的文档——设计文档、新项目提案、产品发布公告，以及任何让你反复斟酌的内容——认真进行编辑，往往能显著提升最终质量。

要培养编辑意识，可以重新通读一遍自己的文档。我发现，大声读出来尤其有帮助。

在阅读每一个部分时，可以问自己：

• 我的读者是否掌握了足够的背景信息，能够理解我在说什么？
• 我是不是写得太多，以至于读者会感到无聊或者走神？
• 如果我是读者，我会如何处理这些信息？
• 这一部分是在强化我希望读者记住的核心观点，还是反而分散了他们的注意力？

像对待产品用户一样，你也应该假设：你的读者很忙，没有天然的动力认真阅读你的文档，而且随时可能关掉页面。

职场写作有一个常见风险：作者自己太熟悉背景和细节，以至于很难意识到哪些内容会让读者感到困惑。

所以，你必须在两个极端之间找到平衡。

一方面，不能让读者面对一大段冗长、密不透风的文字；另一方面，也不能为了追求简短，把理解内容所必需的信息删得一干二净。

如果你不确定自己的观点是否表达清楚，可以找一位值得信赖的同事帮你读一遍，然后问他：

“你读完之后，觉得这份文档最重要的结论是什么？”

如果他的答案与你真正想表达的东西不一样，那就说明你的想法还没有表达得足够清楚，需要继续修改。

对于研发团队来说，重要文档还应该尽量避免散落在聊天记录、邮件和个人文件中。比如，可以借助 PingCode 的 Wiki 将设计方案、项目决策、产品发布记录以及研发过程中沉淀的知识统一保存，方便团队后续查阅和复用，也能减少因为上下文缺失造成的沟通成本。

当你已经改得有些疲惫、快要没有精力继续编辑时，还可以问自己最后一个问题：

如果我要把这份文档的链接发给公司的 CEO 或 CTO，我会用一句什么话来解释这份文档？

即使你已经修改过很多遍，到这个时候，你很可能还是会发现一些可以表达得更好的地方。

因为当你意识到阅读者是一位时间极其有限的重要决策者时，你会本能地避免浪费对方的时间，迫使自己更快切入主题、抓住重点。

而这种本能，同样应该运用在你写给其他同事的文字中。

他们的时间也一样宝贵。

清晰写作如何提升工程团队沟通与领导力

说到底，在工作中写得不好，可能并不会立刻带来多么严重的后果。

你不会因此被解雇。即使书面表达能力一般，只要能在其他方面弥补，项目依然可能取得成功。

但如果你能够进行清晰、流畅而有效的书面沟通，成功的概率无疑会大大提高。

写作是工程领导者最重要的工具之一。

它可以凝聚团队，让大家朝着共同的目标前进；

它可以说服别人关注你认为重要的事情；

它也可以帮助你打造一支健康、高效的工程团队。

所以，每次准备写东西的时候，都应该从读者出发：

他们为什么要读？

他们希望从中获得什么？

读完之后，他们应该知道什么，又应该做什么？

始终围绕读者希望从文字中获得什么来选择信息、组织结构和斟酌措辞，你就能真正发挥文字的力量。

也能更有效地用写作来领导团队。