写工程策略

我觉得写工程策略很难，因为好的策略往往都很"无聊"，写起来也很无聊。当人们听到"策略"时他们可能更多想到的是"创新"。

- Camille Fournier

很少有公司了解他们的工程战略和愿景。这种不确定性的一个后果是，业界认为这些文档很难编写。在一些对话中，你可能会觉得你在谈论一些神秘的东西——但这些只是普通的文档。现实情况是，好的工程策略很无聊，编写有效的策略比编写糟糕的策略更容易。

为了编写工程策略，你需要编写5个设计文档，并找出其中的相似性。这就是你的工程策略。要写一个工程愿景，你只要写5个工程战略，并预测它们对未来两年的影响——于是你就得到了你的工程愿景。

如果你无法抗拒想把你最聪明的想法写进文档过程的冲动，那么你可以将它们包含在你的前期工作中。把你所有最好的想法写在一个巨大的文件里，删除它，并且再也不要提及它们。现在，这些想法已经从你的脑海中消失了，你的头脑已经为未来的工作扫清了障碍。

持久有用的工程策略和愿景是迭代的、自底向上的组织学习的输出。因此，所有的学习都有助于组织的战略和愿景，但你的贡献不必如此抽象。即使你不直接负责这项工作，你也可以采取一些切实可行的步骤来推进公司的战略和愿景，从现在开始。

什么时候以及为什么写策略

在深入研究如何创建有效的策略和愿景之前，一个好的开始问题是:“我应该在什么时候以及为什么要创建它们?”战略是促使团队积极配合的工具，使团队能够快速和有信心地行动。策略能让每个人——而不仅仅是少数人——迅速、自信地做出决定，否则他们可能要花一周的时间来讨论。策略也是将你的许多模糊不清的未来具体到足以让你写出一个现实的愿景的基石。如果你意识到你已经重复了相同的讨论三到四次，是时候写一个策略了。当未来太过朦胧，无法确定值得进行的投资时，是时候再写一个愿景了。如果这两个问题听起来都不熟悉，那就先去做其他的工作，然后再回来。

编写5份设计文档

设计文档描述了您在特定项目中所做的决定和权衡。你的公司可能会称它们为RFC或技术规格，当然也会有其他奇怪的名字;优步一开始称这些文档为鸭子（DUCKS），直到后来统一叫做RFC。一个好的设计文档描述一个特定的问题，调查可能的解决方案，并解释所选择的方法的细节。有许多格式可供选择；这里有几篇文章可以作为你的参考：Design Docs, Markdown, and Git, Design Docs at Google, and Technical Decision-Making and Alignment in a Remote Culture。

一个项目是否需要设计文档取决于个人判断，但下面是一些我认为有用的准则：你应该为任何项目编写设计文档，这些项目的功能将被未来的许多项目所使用；你还应该为那些对你的用户有意义的项目编写设计文档；对于任何需要超过一个月工程时间的工作，你都应该编写一份设计文档。

5份设计文档是编写有效策略的理想元素，因为不像是那些糟糕的策略文档，设计文档是基于现实和详细细节的。同一个团队中的两个好心的工程师很容易以不同的方式解释一个抽象的策略，但当真正开始落实实现一个特定的解决方案时，基本上不太会出现这种冲突。

下面是一些建议:

• 从问题开始。问题陈述越清晰，解决方案就越明显。如果解决方案不明显，花更多的时间澄清问题。如果你无法清晰地表达问题，向五个人讲述你的状况，并问他们有什么想补充的:新的眼睛总是能看到真相。

• 保持模板简单。大多数公司都有一个设计文档模板，这是一个很好的模式。然而，这些模板经常被扩展以服务于太多的目标。过于复杂的模板从一开始就阻碍人们编写设计文档。要偏向于用最精简的设计文档模板，允许作者选择最有用的部分，并坚持只对风险最大的项目的详尽细节。

• 团队一起review，但是写要单独写。你不可能指望自己写一个特定主题的文档的时候拥有所有相关背景知识。在深入文档写作之前，要从相关人士那里收集意见，特别是那些依赖于你的设计文档的产出的人。然而，我们应该对使用这种协作方式来进行设计文档写作持谨慎态度。大多数人写文档要比编辑别人的文档做的更好。也就是说，要想通过编辑一组文档把它们修改成清晰的文字，比指定某个具体的人来从头写一个清晰的文档要困难得多。广泛收集观点，但要自己一个人写。只是要注意，在你和别人一起review之前，不要太把自己写的东西当回事。

• 好用胜于完美。写一份好的文档并把它摆在别人面前，总比为了一些稍微好一点的东西拖延要好。当你在给别人的设计提供反馈时，也一定要注意这样的换位思考。我们很容易落入这样的思维误区，即期望别人的设计应该和自己最好的设计一样好。特别是当你的职位越来越高时，让每个设计都满足自己最好的作品标准是有害的心态。应该专注于如何推动设计变得更好，而不是只看到自己认为的最高质量标准。

编写优秀的设计文档需要大量的实践。如果您想要改进您的设计，我的最佳建议是在完成项目实现之后重新阅读一开始的设计，并研究一下最终实现偏离刚开始计划的地方——是什么导致了这些偏离?最后，当然了，一定要继续不断地写新的设计文档。

将这5个设计文档整合成策略

在您的组织编写了5个设计文档之后，坐下来一起阅读它们。寻找在多个设计中出现的有争议的决定，特别是那些很难达成一致的决定。我最近遇到的一个问题是，Redis是适合作为持久存储还是只适合作为缓存。比起在每次设计文档审核中从零开始，如果我们能够回顾一下我们最近关于使用Redis的决定，反思我们是如何做出这些决定并将其作为一种策略而记录下来，是不是会让我们的工作更容易一些?

好的策略指导如何做利弊权衡，并解释背后的基本原理。糟糕的策略是不加解释地陈述一项政策，这将它们与制定它们的环境脱钩。如果没有背景，你的策略很快就会变得难以理解——他们为什么要这么做?——也很难随着潜在环境的变化而适应。有一些有趣的策略可以阅读，当你在思考自己的写作时，比如《负责任的创新框架》(A Framework for Responsible Innovation)和《Slack的技术变革有多大》(How Big Technical Changes Happen at Slack)。

如果你是一个《好战略，坏战略》的信奉者——这本书完全改变了我对策略的看法——那么你会注意到这个策略的定义是“诊断”和“指导政策”部分，在设计文档要服从“连贯的行动”。

我对撰写战略文档的最佳建议是:

• 从你所处的位置开始写。在制定策略时，我们很容易被工作中固有的巨大模糊性所麻痹，但你必须投入其中并开始写作。等待丢失的信息不起作用:每个丢失的文档都是有原因的。无论你写什么都需要修改，如果你写的特别糟糕，你很快就会意识到需要修改。你现在所在的地方永远是最好的起点。

• 写细节。写，写到你开始想要归纳总结位置。如果你不能明确细节，那就等到你写了更多设计文档后再说。具体的细节创造真正的共识，泛泛而谈的内容只会误导大家产生有共识的错觉。

• 要有主见。好的策略是有主见的。如果他们没有主见，那么他们就没办法在决策过程提供清晰思路。然而，光有主见是不够的。你还需要展示你的工作成果。

• 展示你的工作成果。从小到大，在数学课上，你必须展示你的成绩才能得到满分。在这里，你也必须表明你的观点背后的理由。展示你的工作成果可以在文档的第一个版本中建立信心，但更重要的是，通过展示你的成果，你可以让其他人在潜在的环境变化时修改和扩展你的工作成果。

当你在写一些最好的策略时，你可能会觉得"这也太明显了吧"而干脆不写了。也许“我们应该何时编写设计文档?"就是一个值得一写的策略。“我们在哪些使用场景中使用哪些数据库?”是一个值得写的策略。“我们应该如何分阶段从monolith过渡到微服务?”也是值得写的。当我们不再把战略当做是一种才华的展示，我们可以开始写更多的战略，我们可以更随意地写它们。如果它最终没有派上用场，大不了以后弃用它。

从五种战略中推导出一个愿景

当你收集到更多的策略时，你就会越来越难以解释这些不同的策略是如何相互作用的。也许您的策略之一是运行更少的软件，更多地依赖云解决方案，但是另一个策略是尽可能地将复杂性转移到数据库。如果您确定了一个数据库，它将允许您消除大量的复杂性，但您的云供应商却没有提供这种服务，那么如何协调这些策略呢?

从你最近的五个策略中，推断出它们之间的互相制约在未来两到三年内会如何影响你们。当您编辑这些矛盾的点并将其编织融合在一起时，您就编写了一个工程愿景。最终的版本将给你Tanya Reilly所说的《对未来的坚定信念》(a robust belief in the future)，这将使你更容易理解你现有的策略是如何相互影响，并简化编写经得起时间考验的新策略的流程。

对于一个有用的愿景，有几件事需要关注:

• 写时间范围在两到三年的愿景。公司、组织和技术的变化都非常快，考虑太遥远的未来是杞人忧天的。当然如果你写的愿景6个月后就到期了，那也没用——在这6个月的期限内，你会实际写多少策略呢?试着专注于两到三年;如果你是一家相当成熟的公司，你可以适度扩展一下这个时间范围。

• 立足于你的业务和你的用户。有效的愿景立足于为用户和企业服务。这种紧密的联系使愿景与领导团队的核心价值观——用户和业务——保持一致。糟糕的愿景将使用高级的技术视为一种raison d’être（法语，存在的理由），而你的公司的领导层从来没有认同过这种观点。

• 要乐观，但不要鲁莽。愿景应该是雄心勃勃的，但不应该是鲁莽的。它们应该是可达成的，但一定是可达成目标中最好的那个。写下假设每个项目都能按时完成，没有重大挫折的话，你能完成的事情。不要写你认为只有用无限的资源才可能达成的东西。

• 保持详细和具体。愿景越具体就越有用。一般的泛泛之论很容易让人同意，但无助于调和相互冲突的策略。要详细到让你自己都有点不舒服。愿景中的细节通常是描述性的，而不是声明性的。愿景给人一种未来的触感，而不是一种把人们绑在一起的保证书。

• 保持一到两页的长度。事实是，大多数人都不会阅读冗长的文档。如果你写了5到6页的东西，读者会开始在没有读完它的情况下离开(或者会快速浏览它，而没有关注细节)。强迫自己编写一些紧凑的内容，并通过链接到其他文档来引用额外的上下文，以满足那些希望了解完整细节的人的需求。

在您完成您的愿景之后，人们通常采取的第一步是在工程组织中广泛地共享它。愿景背后有很多工作——每个策略文档有5个设计文档，一个愿景有5个策略文档——当你完成时很难不感到兴奋。太兴奋了，当你发现人们对你的策略的反应几乎总是沉默时，你会很容易被打击。这种沉默的反应有几个原因。首先，你的愿景的核心受众是撰写策略的人，这是一个相对较小的群体。其次，一个伟大的愿景通常是如此明显，以至于它让人感到乏味，而不是令人兴奋。

不要用最初的兴奋程度来衡量愿景。相反地，你可以通过比较阅读两年前的和上周的设计文档去衡量它;如果有明显的改善，说明你的愿景制定得很好。