第 3 章描绘全局

先讲一个我最喜欢的故事，关于一个缺少全局视图的团队。我所在的某个组织即将召开一次全员大会。大家可以提前提交议题，其中有人问到了一个关键系统——我们姑且叫它 SystemX——它引发过几次故障。这个问题被指派给我来回答。我在准备发言要点的时候，几乎同时收到了三条私信：

第一条：“请让大家放心，我们知道 SystemX 一直有问题，但我们正在给负责它的团队增加人手，并添加副本来帮助它扩展。我们预计不会再出故障了。”
同一时间：“太好了，终于有人问这个问题！我们应该强调 SystemX 已经被废弃了，所有人都应该计划迁移出去。”
还有：“嘿，能不能告诉大家，我已经成立了一个工作组，研究 SystemX 该如何演进。我们会在下个季度公布计划。有人想加入工作组的话，可以联系我。”

这样的公开场合本来是一个很好的机会，可以让大家了解这三条非常合理的前进路线中的任何一条。但为什么会有三个不同的计划？

在第 2 章的结尾，我们完成了对组织现有藏宝图的探索。如果你的团队已经有了这样一张地图——一个单一、有说服力、被充分理解的目标，以及实现它的计划——那么你的全局就已经完整了。你可以直接跳到第二部分，我会在那里讲如何执行大型项目。但很多时候，Staff 工程师会发现目标并不清晰，或者计划存在争议。如果你正处于这种情况，请继续读下去。

在第一部分的这最后一章里，我们要讨论如何描绘全局。当道路未经定义、令人困惑时，有时你需要让大家就一个计划达成一致，绘制出那张缺失的地图。这张地图通常以技术愿景的形式出现，描述你想要达到的未来状态；或者以技术战略的形式出现，概述你打算如何应对挑战、实现具体目标。我会先介绍这两种文档，包括你为什么需要它们、它们可能是什么形态、里面可能包含哪些内容。然后我们会看看如何以团队的方式来创建这类文档。我们会讨论创建文档的三个阶段：方法、写作和发布。¹ 最后，我们会通过一个虚构的案例研究，看看其中一些技巧的实际运用。我们现在就先把这个场景摆出来，这样你就可以开始思考你会如何着手。

场景：SockMatcher 需要一个计划

SockMatcher 成立于几年前，起初是一家只有两个人的初创公司，目标是解决一个重要问题：落单的袜子。丢了一只袜子的人通过公司的移动应用上传图片或视频，后端一个复杂的机器学习算法会尝试找到另一位丢了同款袜子中另一只的用户。如果两位袜子主人中有一位想把自己落单的袜子卖给另一位，算法还会给出建议价格。每一次袜子所有权的变更都会记录在一个分布式的“袜子链”账本中。

你可以想象，风险投资人为之疯狂。² SockMatcher 迅速成长为互联网上最大的落单袜子交易市场。公司不断扩张，与多家定制袜子制造商建立了合作，推出了个性化袜子推荐，甚至还扩展到了手套和纽扣。它还推出了一个外部 API，第三方可以用它来进行袜子分析，即“袜子分析即平台”（SaaaP）。客户很喜欢这些新功能。

公司的架构是自然生长起来的。一切都围绕着单一的中央数据库和数据模型构建，一个单体二进制程序负责登录、账户订阅、计费、匹配、个性化、图片和视频上传等等。产品特定的逻辑被写进了每一个功能里。比如，计费代码里包含了如何向客户收费的逻辑：袜子按每次成功匹配收费，纽扣则按季度订阅收费。袜子数据和客户数据存储在同一个大型数据存储中，其中包括客户的敏感个人身份信息（PII），比如姓名、信用卡号和鞋码。

出于竞争原因，SockMatcher 一直优先考虑尽快把新功能推上应用，而不是以可扩展或可复用的方式来构建。例如，团队把手套功能实现为现有袜子匹配功能的一个特例，在袜子数据模型中添加了一个字段，用来把物品标记为“左”或“右”。当用户上传一张手套图片时，软件会生成一张镜像图片，然后把手套当作另一种袜子来处理。

当公司决定增加纽扣匹配时，几位高级工程师主张，是时候重新设计架构，创建一个模块化系统，让添加新类型的可匹配物品变得容易。但业务压力占了上风，纽扣匹配同样被实现为袜子的一个特例，在数据模型中增加了新字段，用来指定一套纽扣的数量和每颗纽扣的孔数。计费代码、个性化子系统以及其他组件都包含硬编码的定制逻辑，来处理袜子、手套和纽扣之间的差异，这些逻辑大多以散落在代码库各处的 if 语句来实现。

现在有了一个新的业务目标提案：公司希望扩展到匹配食品保鲜盒和盒盖。这个产品的特点与现有产品不同。和袜子不一样，保鲜盒和盒盖并不相同。团队将需要不同的匹配模型和逻辑，以及一整套新的供应商和合作关系，以便在找不到匹配时为客户提供全新的替换盒盖或盒子。公司最新的产品战略演示文稿还设想了未来增加耳环、拼图块、轮毂盖等更多品类。

新组建的食品保鲜盒团队已经准备好开始界定这个功能的范围。他们并不想在现有的单体里开始工作：他们非常希望构建自己独立的匹配微服务，配有自己的数据存储。但即使这样做，他们仍然需要用到认证、计费、个性化、安全处理 PII 以及其他共享功能的代码——而这些目前都是针对袜子模型优化的。如果想独立自主地工作，他们就需要把这些功能从单体中暴露出来，或者重新实现。无论哪种做法都需要时间，所以他们预计会面临一些压力，被要求把食品保鲜盒宣布为一种袜子，在现有代码中工作，必要时在手套和纽扣旁边再加上更多边界情况。对于下一步该怎么走，团队内部意见不一。

还有一些其他挑战：

共享给第三方的 API 没有版本管理，所以很难修改；随着新的集成计划推进，这个问题拖得越久就越难解决。
自研的登录功能，套用三年前编写它的那位工程师的话说，一直“有点凑合”。它还能撑几年的增长，但没有人会为这段代码感到骄傲。
匹配功能是市场上最好的，客户很满意，但有时即使存在匹配项，它也找不到。
一位团队成员有一个关于新算法和新系统的想法，能用现在一小部分的时间找到匹配。他们对此非常兴奋。
负责运维单体的团队跟不上它的增长，一直在被动应对扩展问题。他们每天都会因为磁盘写满、部署失败和软件缺陷被呼叫好几次。
随着越来越多的工程师在同一个代码库中工作、复用现有功能，意料之外的行为越来越多，用户可见的缺陷也被越来越频繁地推上线。几乎每一次故障都会影响到几乎每一个团队和用户。
名人和网红出售自己的袜子时，曾造成用户流量 100 倍的激增，导致服务完全中断。食品保鲜盒的发布可能会把名厨吸引到平台上，进一步增加需求。
每一个新功能都会拖慢单体的构建时间，那些无人负责、时好时坏的测试也雪上加霜：构建并部署一个新版本通常需要三个小时，这让大多数事故的持续时间被拉长。
移动应用在 App Store 上的评价开始走下坡路；许多一星评价都提到可用性很差。

虽然这个场景包含了大量问题，但其中很多都有直接的技术解决方案。每个新加入公司的人都会提出改进建议：对数据存储做分片、给 API 加版本、把功能从单体中拆分出来，等等。各种工作组也纷纷成立。它们总是以一屋子 20 个人开场，大家都非常在意，却意见不一，然后因为没有人有时间专注于此而陷入停滞。毕竟，还有功能开发要做，那些工作感觉更重要，也更有可能成功。工程组织似乎没办法为任何一项举措凝聚起推进的势头。

你会怎么做？我们会在本章结尾回到这个场景。

什么是愿景？什么是战略？

你应该把新功能构建成可复用的平台，还是作为某个特定产品的一部分？团队应该学习那个难用的新框架，还是坚持用那个流行但已被废弃的框架？也许每个团队可以自己做决定：去中心化的决策可以让组织行动更快，自己解决自己的问题。但当每个团队各自为政时，也可能会有一些弊端：

可能会出现“公地悲剧”：各个团队在不与他人协调的情况下追求对自己最好的行动，最终导致对所有人都不利的结果。这又是那个局部最优。
共同关心的问题可能会被忽视，因为没有哪个团队有权力或动力去独自解决它们。
团队可能缺少足够的上下文来做出最好的决策。采取行动的人可能不是承受后果的人，或者与后果之间隔着一段时间。

当存在重大的悬而未决的决策时，项目就会变慢或受阻。没有人愿意为了一场漫长而痛苦的争论——为了做出一个有争议的决定或选定一个标准——而推迟自己的项目。于是，各个团队做出局部来看不错的决策，解决自己眼前的问题。每个团队根据自己的偏好，或者根据关于组织技术方向的传闻来选择方向——而且常常把这些选择固化到他们构建的解决方案中。

推迟这些重大的底层问题，只会让它们在以后更难解决。³

当组织意识到需要解决其中一些重大的底层问题时，愿景和战略这两个词就会被频繁提起。你会听到人们有时把它们混用，有时又用它们表示不同的东西。为了避免术语上的混淆，我们先给出一些工作定义，在本章中通用。

什么是技术愿景？

技术愿景描述的是目标达成、最大的问题得到解决之后，你所希望的未来的样子。描述工作完成之后一切会是什么样子，能让每个人更容易想象那个世界，而不会被如何到达那里的细节所困住。

你可以在任何范围内撰写技术愿景，大到整个工程组织的宏伟蓝图，小到单个团队的工作。你的愿景可能继承自更大范围的文档，也可能影响更小范围的文档（图 3-1 给出了一些例子）。

愿景创造了一个共同的现实。作为一名能看清全局的 Staff 工程师，你大概能想象出你的架构、代码、流程、技术和团队可以达到的更好状态。问题在于，你身边的许多其他资深人士很可能也能想象得到，而你们的想法未必一致。即使你认为大家意见一致，也很容易做出假设或略过细节，直到重大分歧引发冲突时才发现。文字的巨大力量在于，它让彼此误解变得困难得多。

图 3-1. 根据问题的大小，你可以从整个工程组织的愿景开始，也可以从团队范围的愿景开始，或者介于两者之间。除非你需要，否则不要创建愿景、战略等文档。

技术愿景有时被称为“北极星”或“山巅之城”。它并不打算做出所有决策，但它应该消除冲突和模糊的来源，让每个人都能自主选择自己的道路，同时确信自己最终会到达正确的地方。

撰写技术愿景的参考资源

如果你打算撰写一份技术愿景文档，以下是我推荐的一些资源：

Fundamentals of Software Architecture，Mark Richards 和 Neal Ford 著（O’Reilly）
Making Things Happen 第 4 章，Scott Berkun 著（O’Reilly）
“How to Set the Technical Direction for Your Team”，Amazon 的 James Hood 著
“Writing Our 3-Year Technical Vision”，Eventbrite 的 Daniel Micol 著

愿景应该是什么样子，并没有特定的标准。它可以是一句精炼而鼓舞人心的“愿景宣言”，可以是一篇 20 页的长文，也可以是一份演示文稿。它可能包括：

对高层价值观和目标的描述
一组用于做决策的原则
已经做出的决策的总结
一张架构图

它可以非常详细，深入到技术选型；也可以保持在高层，把所有细节留给负责实施的人。

无论你创建的是什么，它都应该清晰而有主见，应该描述一个现实可行的更好未来，并且应该满足组织的需要。如果你能挥一挥魔杖就大功告成，你的架构、流程、团队、文化或能力会是什么样子？那就是你的愿景。

什么是技术战略？

战略是一份行动计划。它是你打算如何实现目标、如何绕过沿途会遇到的障碍的方式。这意味着既要了解你想去哪里（这可以是我们刚才讨论的愿景！），也要了解路上的挑战。在本章中，当我使用战略这个词时，我指的始终是一份具体的文档，而不仅仅是指具有战略性思维。

技术战略可能是业务战略或产品战略的支撑。它可能是技术愿景的配套文档，也可能只处理该愿景的一部分，比如愿景所涵盖的某个组织、产品或技术领域。它也可能完全独立存在。

和技术愿景一样，技术战略应该带来清晰——不是关于目的地，而是关于通往目的地的道路。它应该以现实的方式应对具体的挑战，提供强有力的方向，并明确团队在途中应该优先采取的行动。战略不会做出所有决策，但它应该包含足够的信息，以克服阻碍团队到达目的地的任何困难。

撰写技术战略的参考资源

关于战略的经典著作是 Richard Rumelt 的 Good Strategy/Bad Strategy（Currency）。如果可以的话，我建议你花时间读一读。其他优秀的资源包括：

“Technical Strategy Power Chords”，Patrick Shields 著
“Getting to Commitment: Tackling Broad Technical Problems in Large Organizations”，Mattie Toia 著
“A Survey of Engineering Strategies”，Will Larson 著
Technology Strategy Patterns，Eben Hewitt 著（O’Reilly）
Rands Leadership Slack，特别是 #technicalstrategy 和 #books-good-strategy-bad-strategy 这两个频道

和技术愿景一样，战略可以只有一两页，也可以是一份 60 页的庞然大物。它很可能包括对当前现状的诊断，包括需要克服的具体挑战，以及应对这些挑战的清晰路径。它可能包括一份按优先级排列的待处理项目清单，或许还附有这些项目的成功标准。根据其范围的不同，它可以包含宽泛的高层方向，也可以针对一组具体的艰难抉择做出决策，并解释每个抉择的取舍。

在 Good Strategy/Bad Strategy 中，Rumelt 描述了“战略的内核”：对问题的诊断、指导方针，以及绕过挑战的行动。我们逐一来看。

诊断

“这里到底发生了什么？”对现状的诊断需要比纷乱的现实更简单，比如从噪声中找出模式，或者借助隐喻和心智模型让问题变得易于理解。你要做的是把所处的局面提炼成最本质的特征，从而真正理解它。这件事很难，需要时间。

指导方针

指导方针是你绕过诊断中所描述障碍的方法。它应该给你一个清晰的方向，让随后的决策变得更容易。Rumelt 说，它应该简短而清晰，是“一个路标，标示着前进的方向”。

连贯的行动

一旦有了诊断和指导方针，你就可以具体说明你要采取哪些行动——以及不采取哪些行动。你的行动几乎肯定不只涉及技术：可能会有组织调整、新的流程或团队，或者项目的变更。这一点我怎么强调都不为过：你会把时间和人力投入到这些行动上，而不是一开始摆在桌面上的那一长串其他想法。这种聚焦很可能意味着，你和其他人没法去做一些你们一直跃跃欲试的事情。事情就是这样。

战略应该利用你的优势。例如，伦敦的工程经理 Isaac Perez Moncho 在为一家公司撰写工程战略时，就致力于打造正反馈循环。他告诉我，那家公司的产品工程团队面临许多问题：缺少工具、事故太多、部署质量差。但他有一个优势：一支出色的 DevOps 团队，只要有更多时间，就能解决这些问题。他的指导方针是为 DevOps 团队腾出一些时间。给他们留出空间，让他们得以把流程自动化，从而腾出更多时间，形成一个正反馈循环，使他们能够去解决其他问题。想一想如何以自我强化的方式放大你的优势。

最后，战略不是对别人在完美世界里会怎么做的理想化描述。它必须现实，必须承认你所处情境的约束。一份在你的组织里配不齐人手的战略，就是在浪费你的时间。

你真的需要愿景和战略文档吗？

技术愿景和战略能带来清晰，但在很多情况下可能是大材小用。不要给自己制造不必要的工作。如果你想达到的状态或想解决的问题很容易描述，那么你真正需要的可能更像是设计文档里的目标一节，甚至只是一个拉取请求（pull request）的描述。⁴ 如果没有这份文档大家也能达成一致，你可能就不需要它。⁵

如果你确定需要某种文档，就想一想它应该是什么形态。要适应组织的需要和它能够支持的东西。例如，如果缺乏方向正在拖慢所有人，你也许可以召集一群人，先创建一个抽象的高层愿景，再具体讨论如何实现它。如果你们正在为公司的增长做准备，你的 CTO 可能会请你召集整个工程部门的人，描述三年后你们的架构和流程会是什么样子。但如果你们的团队一再卡在某一个缺失的架构决策上，就不要在理念上花太多时间：针对阻碍你们的那个具体问题做出决定。

撰写技术愿景或战略需要时间。如果能用更轻量的方式达到同样的效果，那就那样做。只创建组织需要的东西，不多做。

方法

创建愿景、战略或任何其他形式的跨团队文档都是一个大项目。会有大量的准备工作，然后是大量的迭代和对齐。请记住，让人们达成一致并不是横亘在你和解决问题这项真正工作之间的杂务：达成一致本身就是工作。你给项目带来的任何洞见或大胆愿景，只有在你能带着大家一起走完这段旅程时才有价值。就像你不会欣赏把时间花在一个无视物理定律的工程方案上一样，去倡导一个你明知无法说服组织去做的项目，也不是对你时间的良好利用。

虽然到目前为止我是分开讨论战略和愿景的，但在本章接下来的部分，我不会过多区分它们。它们是非常不同的东西，但都涉及把人聚到一起、做出决策、带动组织跟上，以及讲好一个故事。你也可以用同样的方法来创建其他全局性的文档，比如技术雷达或一套工程价值观。

创建这些文档中的任何一种，都是典型的“百分之一的灵感加百分之九十九的汗水”的工作，但如果准备得当，你就能提高发布一份真正被使用的成果的几率。我会谈谈一些能为成功打下基础的准备工作，然后请你仔细思考这些准备工作的产出，评估你能否成功，并决定是否让这个项目正式立项。

拥抱无聊的想法

我不知道你怎么样，但我刚入行的时候，以为非常资深的工程师都是巫师，每天都在为极其深奥可怕的技术问题想出富有洞见、改变格局的解决方案。我想象中的场景就像是 Star Trek: The Next Generation（《星际迷航：下一代》）中的某一集：曲速核心的反物质约束即将失效，或者诸如此类的情况，所有人都束手无策、惊慌失措，然后突然间，Geordi La Forge 或 Wesley Crusher 大喊一声：“等等！要是我们 <一大串技术黑话>”，然后在触摸屏上点了八个字符，企业号在最后几秒钟得救了。呼！

现实生活有点不一样。好吧，有时候“要是我们 <一大串技术黑话>”确实就是答案：尤其是在非常小的公司里，有时你们真的会一筹莫展，直到一位经验丰富的人出现，描述出一个解决方案，挽救局面。但如果周围有资深的人，很可能好主意已经足够多了。缺的是让所有人就该做什么达成一致。

当你着手这个创建愿景或战略的项目时，要做好准备：你的工作将涉及的是已有的想法，而不是全新的想法。正如 The Manager’s Path 的作者 Camille Fournier 所写：

我有点觉得，关于工程战略的文章之所以难写，是因为好的战略相当无聊，写起来也有点无聊。而且我觉得，人们一听到“战略”就会想到“创新”。如果你写出了什么有趣的东西，那它很可能是错的。这在方向上似乎是对的，大多数战略无疑都是综合提炼，而这一点很少被人提及！

Will Larson 补充道：“如果你忍不住想把自己最绝妙的想法塞进这个过程，那就把它们放进你的前期工作里。把你所有最好的想法写进一份巨大的文档，删掉它，然后再也不要提起其中任何一个。现在……你的头脑已经清空，可以开始接下来的工作了。”

在写作时，创造出一份感觉“显而易见”的东西可能会让人觉得虎头蛇尾：我们都希望带着一个天才般的远见卓识登场，拯救 USS Enterprise（企业号）！但通常真正需要的，是一个愿意权衡所有可能的解决方案、论证该做什么和不该做什么、让所有人达成一致，并且有足够勇气做出（可能是错误的！）决定的人。

加入一支已在途中的探险队

如果已经有人在做你想创建的那类文档，不要竞争——加入他们的旅程。有三种方式可以做到：

共同领导

你可以在不接管的前提下为现有项目带来领导力。提议一种正式的分工，让你们每个人都有机会以有意义的方式发挥领导作用。例如，一个人负责整体项目，另一个人领导其中的一些具体举措。你也可以提议共同领导：轮流担任主要作者，在工作推进的过程中分配任务。如果领导者们对彼此的想法充满热情，并且都朝着同一个方向努力，这可以组成一支非常高效的团队。

追随他们的领导

放下自我，按照他们的计划走。如果他们的经验不如你，你可以通过把他们往正确的方向推一推、帮助把工作做到最好，产生巨大的影响。做一个饱经风霜、经验丰富的最佳配角，是一个很棒的角色。⁶ 你可以用自己深厚的技术知识来弥补他们技能上的不足，比如深入遗留代码库，弄清某个东西到底是如何运作的。你还可以在他们不在场的场合为这个计划发声。支持他们，帮助把事情做成。

抽身离开

第三种方式当然是：判断这项工作没有你也会成功，为它感到高兴，然后去找别的事情做。如果这个项目不需要你，就去找一个需要你的项目。

当别人的方向并不是你计划要去的方向时，让他们来领导可能很难。科技公司的晋升体系可能会激励工程师，让他们觉得自己需要“赢得”某个技术方向，或者成为某个项目的门面。这种竞争可能导致“猿猴游戏”：争夺支配地位、搞办公室政治，每个人都试图把自己确立为这个领域的领导者，把别人的想法视为威胁。这对协作是有毒的，会让成功变得难得多。

我的朋友 Robert Konigsberg 是 Google 的 Staff 工程师和技术负责人，他总是说：“别忘了，一个想法出自你的大脑，并不意味着它就是最好的想法。”如果你倾向于把正确等同于“赢”，那就退后一步，专注于真正的目标。练习换位思考：他们的方向是错的，还是只是不同？如果你想走的那条路是同事的想法，你还会同样卖力地为它争取吗？即使它更好，也要警惕为了一条只是稍好一点的路而争执不休，结果什么决定都没做成。正如 Will Larson 所写：“对那些正在努力推动改进的其他领导者，要迅速给予支持。即使你不同意他们最初的方法，一位值得信赖的人领导项目，几乎总能得到好的结果。”

如果你不认为对方的想法或领导力能行得通，即使有你的支持也不行，那该怎么办？虽然有时你需要灵活变通，但这不应该延伸到为你认为危险或有害的想法背书。即便如此，也要尽量加入现有的旅程并改变它的方向，而不是从零开始另起一个与之竞争的举措：那里已经有现成的盟友和已经积累起来的势头，你也能从他们迄今为止所做的工作中学到东西。

如果确实没有办法让多个人在同一个项目上都获得成功而又不陷入猿猴游戏，那就考虑去一个有更多可用范围（以及更健康文化）的地方。

找一位发起人

除了最草根的文化之外，任何没有高层支持的大型工作都不太可能成功。愿景或战略可以在没有发起人的情况下开始，但之后要把它变成现实将是一个挑战。即使在早期，发起人也能帮助明确这项工作并证明其合理性。如果你的总监或 VP 从一开始就认同你的计划，那么你所创建的东西就隐含地成了组织的藏宝图，而不仅仅是你的——这降低了你浪费时间的风险。发起人还可以为那些原本会陷入追求共识的团队增加层级结构。发起人可以设定成功标准，并在决策卡在委员会里时充当打破僵局的人。他们可以指定一位负责人或“决策者”——有时称为直接负责人（directly responsible individual，DRI）——在团队陷入僵局时拥有最终决定权。你不一定需要这样做，但请记住这是一个可用的选项。

找到发起人可能并不容易。高管们都很忙，而你实际上是在请他们把资源、人力和时间投入到你的提案上，而不是他们原本打算做的其他事情上。要最大化你的机会，就要带给潜在发起人他们想要的东西。一个对公司有好处的提案是个很好的开端，但如果提案契合总监自己的目标，或者解决了他们关心的问题，你会走得更远。弄清楚是什么在阻碍他们的目标，看看你要解决的问题是否与之契合。发起人还会有一些“永远成立的目标”：如果你能让他们的团队更有生产力或（真正地）更快乐，这可能就是他们支持你工作的一个有力理由。

在试图说服发起人支持你的项目之前，先想好并练习你的“电梯演讲”：如果你不能用 50 个字说服他们，你可能根本就说服不了他们。我曾经试图说服当时在 Google 担任工程总监的 Melissa Binde 为一个我非常在意的项目担任发起人。我讲了各种各样的细节，试图让她也觉得这件事很重要。我的说辞一点都不打动人——但 Melissa 好心地借这个机会指导了我：“你讲这个故事的方式没法让我在意，也不会让其他任何人在意。再试一次——换个角度讲这个故事。”她让我尝试了几种不同的项目理由，并告诉我哪些能引起共鸣。你几乎永远不会得到这样的机会，所以要带着已经打磨好的说辞去。

Staff+ 工程师能当项目发起人吗？根据我的经验，不能，至少不能直接担任。发起人需要有权力决定组织把时间和人力花在什么上，而这类决定通常取决于当地的总监或 VP。

一旦获得了发起人的支持，要经常确认，确保你仍然拥有这份支持。Reddit 的首席工程师 Sean Rees 说，Staff+ 工程师可能犯的最大错误之一，就是没有维护好高管层面的支持：“我认为这个问题很隐蔽，因为你可能一开始得到了支持，但随着现实情况的变化，支持逐渐减弱……然后你就不得不在险恶的水域中摸索，重新取得一致。”

选择你的核心团队

有些人非常自律，一旦踏上旅程就不会被支线任务分心，但我们大多数人都能从一点问责中受益。与他人合作会给你带来这种问责。当一个人分心或泄气时，其他人会让势头继续保持下去；而且知道自己需要汇报工作进展，本身就是一种强大的动力。以团队方式工作还能让你们汇集彼此的人脉、社会资本和信誉，从而触及组织中更广泛的人群。你需要努力让所有人保持一致，但既然最终你需要和整个组织达成一致，先让核心团队达成一致，就能帮你尽早发现潜在的分歧。

目标是招募一个小型核心团队来帮你创建文档，再加上一个更广泛的盟友和支持者群体。当然，如果你加入了别人的旅程，那你就会成为他们核心团队的一员。（为简单起见，本章接下来的部分假设由你来领导这项工作。）

你希望团队里有谁？拿出你的地形图。你需要谁站在你这边？谁会反对？如果有些反对者会讨厌任何没有他们参与的决定，你有两个选择：要么确保你有足够的支持来抵消他们的反对声音，要么从一开始就把他们拉进来。如果你理解他们为什么反对这项工作、他们希望看到什么样的结果，把他们拉进来就会更容易。

虽然你可能有很多同事关心你在写的东西并且想帮忙，但要让核心团队保持在可控的规模：两到四个人（包括你）是最理想的。时间承诺在这里会有帮助：如果核心团队的每个人都需要每周为这项工作投入 8 或 12 个小时，你就能在不排斥任何人的情况下保持团队规模小巧。（这也是让“观光客”不碍事的好方法。）在核心团队之外，你可以提供更轻量的参与方式：你会采访他们，尽量在工作中体现他们的观点，并让他们评审早期草稿。

一旦有了核心团队，就要准备好放手让他们工作！从一开始就明确你认为自己是这个项目的负责人和最终决策者，还是更像是平等成员中的第一位。如果你之后会想动用打破僵局的权力或者以职级压人，那就从一开始就强调你作为负责人的角色，比如在你创建的启动文档中加一个“角色”章节。

但无论你是不是负责人，都要让你的团队成员提出想法、推动项目前进、谈论这个项目，而不是把所有问题都转给你。给他们提供领导的机会，在他们主动出击时给予支持。他们的势头会帮助你更快前进，所以不要拖他们的后腿。

至于更广泛的盟友群体，要让他们保持参与：采访他们，并使用他们提供的信息。向他们发送文档进展的更新。邀请他们对早期草稿发表意见。如果有一群有影响力的人支持你所做的事，你的道路会顺畅得多，而他们从组织各处带来的知识也会产生更好的结果。

设定范围

当你思考要解决的一个或多个具体问题时，考虑一下它们在组织中蔓延得有多广。你是想影响整个工程部门、一个团队，还是一组系统？你的计划的范围可能与你作为 Staff 工程师的角色范围一致，但也可能远远超出它。⁷

目标是覆盖足够的范围来真正解决问题，但要清楚自己的技能水平和影响力范围。比如说，如果你想对网络做一次重大变更，明智的做法是把网络团队的某个人纳入核心团队，并在那个团队中建立信誉。否则，你就是在给自己埋下冲突和失败的种子。如果你想为公司中远在你影响力范围之外的领域制订计划，就要确保你有一位在那里有影响力的发起人——最好还有一些对组织中那些部分有清晰地图的核心团队成员。

对可能做到的事情要务实。如果你对未来的愿景涉及完全不受你控制的事情，比如更换 CEO 或改变客户的购买模式，那你就已经陷入了魔幻思维。要绕着固定的约束来工作，而不是无视它们或希望它们有所不同。

话虽如此，如果你只是为公司中你负责的部分撰写愿景或战略，要明白更高层的计划可能会打乱你的计划。即使你写的是覆盖整个工程部门的东西，业务方向的变化也可能让你所有的决策失效。要准备好定期回顾你的愿景，确保它仍然适合你的组织。随着你在愿景或战略上取得进展，你可能会发现范围发生了变化。这没关系！只要明确说明范围已经变了就行。

还要明确你打算创建什么样的文档。我建议一开始就让每位核心团队成员非常明确地说出，他们希望在工作结束时出现什么样的文档、演示文稿或汽车贴纸。然后选择一种对你来说合理的文档类型和格式，最重要的是，对你的发起人来说也合理。如果他们对某种特定的方法充满热情，那么在做其他选择之前，先好好自我反省一下。不要让自己的日子过得比必要的更艰难。

确保它是可实现的

当你思考接下来的项目时，你看到了多少大问题？是否有一些你真的不知道该如何做出的决策，或者巨大的技术难题？有一两个不知道如何解决的问题，并不意味着你不应该涉足，但要想一想这个问题到底是否可解。

在这里你可以采取的一个实际步骤是：找一个以前做过类似事情的人聊一聊。可以这样问：“我正在写一份愿景/战略，目前我看到前面有三个问题，还不知道该如何解决。我愿意尝试，但如果这根本无解，我不想浪费时间。你能凭直觉帮我判断一下我会不会走进死胡同吗？”或者也许是：“前面的一切看起来都可行，我只有一个问题，那就是我的老板认为这是浪费时间，想让我专注于完全不同的事情。这还值得继续吗？”⁸

也许你认为这个问题很重要、也可以解决，但目前不应由你来解决。有没有一位教练或导师可以帮助你拓展能力去做这件事？还是说，就你目前的职业阶段而言，这件事实在太大了？如果你是一名 Staff 工程师，在一个为首席工程师设定范围的问题面前望而却步，这并不说明你不行：你实际上是在做相当不错的风险分析。

如果在分析结束时，你认为这个问题无法解决，或者至少不是你能解决的，你有五个选择：

自欺欺人，祈祷好运，硬着头皮做下去。
招募一个拥有你所缺少技能的人，要么和他们一起工作，要么请他们领导这个项目（并分给你其中一个子部分来磨炼你的技能）。
缩小范围，把固定约束考虑进去，带着一个形态不同的问题从本章开头重新开始。
接受没有人会写一份愿景/战略来解决你所看到的问题这一事实，得出结论：没有它，你的公司大概也能过得去，然后去做别的事情。
接受没有人会写一份愿景/战略来解决你所看到的问题这一事实，得出结论：没有它，你的公司不会好过，然后更新你的简历。

让它正式立项

在继续之前，我们先回顾一下一路上提出的那些问题。下面是一份在开始创建技术愿景或战略之前需要考虑的检查清单。

☐ 我们需要它。
☐ 我知道解决方案会是无聊而显而易见的。
☐ 目前没有已在进行中的同类工作（或者我已经加入了）。
☐ 有组织层面的支持。
☐ 我们对要创建的东西达成了一致。
☐ 这个问题是可解的（由我来解决）。
☐ 在以上任何一项上，我都没有自欺欺人。

针对最后一个问题稍微自省一下。如果你不能勾选所有这些方框，我的看法是你不应该继续。如果你把时间花在愿景或战略上，而不是其他需要 Staff+ 工程师的工作上，机会成本是很高的。

不过，如果你确实觉得已经准备好了，那么还有最后一个问题：你准备好投入这项工作，并开始“公开地”推进它了吗？现在也许是一个好时机，把创建愿景或战略正式设立为一个项目，配上启动文档、里程碑、时间表以及汇报进展的预期。如果你有任何拖延或容易分心的倾向，这些结构就尤其重要。

你在这里的透明程度，取决于你对组织的了解：想想你在上一章绘制的地形图。如果你能公开地进行这类工作，人们会更容易给你带来信息，也更愿意聚拢到你身边来帮忙。如果你觉得需要秘密地创建愿景或战略，要弄清楚原因。这是否意味着你没有足够的支持？你是否对自己的信心和投入程度没有把握？如果你需要先做一点工作，好让自己相信你会坚持下去，好吧，我不会评判你，但要尽快让它正式立项。如果你设定好了所有人的预期，你就不太可能遇到与之竞争的工作——或者至少能尽早发现它们。

写作

准备工作已经完成，项目已经正式立项，你有了发起人，有了核心团队，也选定了文档格式。你要做的工作已经有了框架和范围。是时候真正开始撰写文档了。

写作循环

在本节中，我将介绍一些真正创建愿景、战略或其他宏观文档的技巧。我们会讨论写作、采访他人、思考和做决策，以及在此过程中如何保持一致。这些技巧并不一定按照我列出的顺序进行。事实上，大多数步骤你可能都会做很多次（见图 3-2），随着视角的变化，甚至偶尔会回到“方法”一节中的步骤。

信息总是会越来越多，所以要留意这个循环何时开始出现收益递减。愿景或战略很容易一直拖下去，尤其是当它不是你的主要项目时，所以要给这项工作设定时间盒，并给自己定一些截止日期。如果你设立了里程碑，就把它们当作提醒，停止迭代、收尾。即使它并不“完美”，也不要害怕停下来：你可以——也应该——定期回顾这份文档，看看有哪些上下文发生了变化。如果你遗漏了什么，以后还有机会补上。

图 3-2. 迭代撰写愿景或战略。

初步想法

下面是你在最初考虑创建愿景或战略时可能会问的一些问题。这些问题只是一个起点：会有许多利益相关者和视角，这只是一个练习，帮助你在与他人交谈之前理清自己的思路。

已经有哪些文档了？如果有涵盖你的愿景或战略的上层文档，比如公司目标或价值观，或者已发布的产品方向，你就应该“继承”它们设定的所有约束。这时，你从定位地图中获得的视角就会派上用场。如果你在撰写一份大范围的技术愿景，你应该知道组织希望在未来几年内实现什么。你所设想的未来应该包括这些既有计划的成功，以及支撑它们所必需的技术变革。

如果存在比你的范围更小的团队级或小组级文档，也要了解它们。有时，一份范围更广的愿景或战略不可避免地会迫使范围更窄的文档做出改变，但要了解这会造成怎样的扰动，并在考虑取舍时把它纳入权衡。

什么需要改变？目前什么是困难的？如果你的团队抱怨被对其他团队的依赖所阻塞，你可能想强调自主性。如果新功能上线很慢，也许你想要的是快速迭代。如果你的产品宕机的时间和正常运行的时间一样多，也许你需要聚焦于可靠性。

根据你对公司的了解，你们的团队应该在哪些方面投入？Mark Richards 和 Neal Ford 谈到了软件中的“架构特性”：可扩展性、可延展性、可用性等等。⁹ 随着业务的扩张或变化，你需要在哪些特性上投入？

要往大处想。如果你在一个需要一天时间才能构建和部署的代码库中工作，你可能会忍不住希望来点渐进式的改进：“这得缩短到半天！”但要想得更远一些。如果你设定了 20 分钟完成部署的目标，朝这个目标努力的团队就有动力提出更大、更大胆的想法。也许他们会考虑替换 CI/CD 系统，或者抛弃一个永远无法与该目标兼容的测试框架。激励人们发挥创造力。（但正如我会在本章后面讨论的，不要设定组织不可能实现的目标。）

现在有什么是很好的？如果你们拥有灵敏的性能、坚如磐石的可靠性，以及简洁清爽的 UI，要确保你们的未来状态包括保留这些运作良好的东西。也许最终你们会有意识地用其中一部分优点去换取你们更想要的其他东西，但不要在无意识中这样做。

什么是重要的？你可能已经注意到了一个规律——这个问题到目前为止在每一章都出现过（而且以后还会再出现）。你的愿景或战略将影响许多资深人士的工作。不要把他们或你自己的时间浪费在无关紧要的事情上。例如，如果你要让团队从一个系统迁移到另一个系统，付出高昂的代价，那么终点最好真的有宝藏。需要付出的努力越大，宝藏就需要越好。

未来的你会希望现在的你做了什么？最后一个！我很喜欢一个技巧：设想与未来的我进行一场对话，那时的我年长两三岁（希望也更有智慧）。我会问那时的世界是什么样子，我们做了什么，以及我们希望当初做了什么。哪些问题每个季度都在变得更糟一点，如果被忽视，将来会变成真正的烂摊子？如果可以的话，帮未来的自己一个忙，不要忽视它们。我把这些举动叫作“往未来送一块饼干”：这是现在的你送给未来的你的一份小小但真心的礼物。

动笔写作

思考完这些问题之后，你可能已经开始识别出一些主题，并对什么最紧迫有了自己的看法。这可能是开始写一份粗略初稿的好时机。不过，要做好准备让别人改变你的想法，甚至可能大幅改变。在与他人交谈、决定下一步做什么的过程中，你会不断编辑和迭代。

以团队方式写作可能会很棘手。下面是两种方法：

由负责人撰写初稿供讨论

一种选择是由团队的负责人（同样，我假设就是你）写出一份初稿供讨论。这种方法非常适合让文档保持一致的口吻和关注点。但要注意，这份草稿不可避免地会受到作者的兴趣和所属立场的影响。评审者和编辑者会受到草稿中已有内容的影响而产生偏见，尤其是当撰写者比他们更有影响力或更资深时。

你可以在动笔之前花大量时间进行团队讨论，以帮助减轻这种影响。如果你对某些决策并没有强烈的看法，甚至是随意选择的，就要清楚地标明：“这个方向是我掷骰子选的。如果我们无法做出决定，我觉得它是一个合理的默认选项。不过我敢打赌我们能做得更好。”一定要确保任何在这个系统上比你更懂行的人都能放心地反对你。“强观点，弱坚持”只有在你把这一点说得一清二楚时才行得通。

汇总多份初稿

另一种方法是核心团队中的每个人各自写一份初稿，然后由某个人进行汇总。¹⁰ Zapier 的工程总监 Mojtaba Hosseini 给我讲过他在之前的公司里一个采用这种方法的团队。他说，拥有多份文档是收集每个人不带偏见的意见的好方法，但一些参与者最终对自己的文档投入了感情，批评别人的文档，而不是为它们做出贡献。那个团队没有指定任何人来合并草稿，也没有指定在两人意见不一时打破僵局的人。Hosseini 建议，要事先明确这些文档都只是一份最终文档的输入，每个人最后都可以评审那份最终文档——没有哪一份文档会是“赢家”。要明确由谁来撰写最终版本、由谁来调解分歧。

访谈

核心团队的想法和观点只会反映团队成员自己的经历。对于你所在团队以外的其他团队面临什么困难，你可能不知道自己不知道什么——所以，放下你的成见，去和人们交谈。和很多人交谈。不要只挑你已经认识并且喜欢的同事：他们很可能在组织上和你挺近的。去寻找其他领域的领导者、有影响力的人以及贴近一线工作的人。

在早期，你可以在访谈中问一些宽泛的开放式问题。

“我们正在为 X 制订一个计划。有哪些重要的内容应该包含进去？”
“和……一起工作是什么感觉？”
“如果你能挥一挥魔杖，……会有什么不同？”

当你已经为工作界定了范围、搭好了框架，你可以通过描述你对这个主题的思考、分享一份进行中的文档，或者请对方对一个稻草人方案发表看法，来给对话限定范围。要尽量获取尽可能多的有用信息，并让受访者觉得自己是你所做之事的一部分。我总是这样结束这类访谈：“还有什么是我应该问你却没问的？有没有什么重要的东西被我遗漏了？”

访谈还有另一个好处：它向受访者表明，你重视他们的想法，并打算把这些想法纳入你所写的内容中。你会听到一些你没有考虑过的问题，以及对你已知问题的新看法。对于最大的问题是什么，其他人可能和你意见不同。保持开放的心态，认真对待他们的想法。

思考时间

无论你和你的团队喜欢以何种方式处理信息（在白板上推演、写作、画图、结构化辩论、静坐盯着墙壁），都要确保给自己留出大量时间来做这件事。我最擅长通过写作来思考，所以在制订愿景或战略时，我需要把想法写下来，然后花很长时间去打磨和修改，直到它们在我看来更说得通。我也从和同事一起把想法聊透中收获良多：我们互相提问，试图把细微之处拆解清楚。相比之下，我的同事 Carl 喜欢把大量信息装进脑子里，然后睡一觉：第二天早上他通常会有新的洞见。在某些情况下，你可以构建原型来检验你的想法。在另一些情况下，战略会更偏高层，你只能以思想实验的方式推演其后果。

对思维上的转变保持开放。随着你在识别重点领域或待解决的挑战方面取得进展，你会注意到自己找到了谈论它们的新方式。顺势而为，促成这种转变。你构建的心智模型和抽象会帮助你思考更大的问题。

思考时间也是审视自身动机的好时机。留意你是否在用一个已经选定的解决方案来描述问题——这可能是很多工程师的思维障碍。我们一开始是在比较要解决的问题，却发现自己在谈论那些我们“应该”使用、能让一切变得更好的技术或架构。正如 Cindy Sridharan 所说：“一位有魅力或有说服力的工程师，可以成功地把自己热衷的项目包装成对组织有益的项目推销出去，而其好处充其量只是表面上的。”尤其要警惕你在向自己推销什么！在审视你提议要做的工作时，一遍又一遍地问“是的，但是为什么？”，直到你确信这个解释能够对应回你想要实现的目标。如果这种关联很牵强，就要诚实地承认。你心爱的项目总会有它的时机，但不是现在。

做出决策

在创建愿景或战略的每个阶段，你都需要做出决策。本章已经讨论了许多早期决策：创建什么样的文档、让谁参与、请谁担任发起人、如何界定你的雄心、聚焦于哪些目标或问题、采访谁，以及如何为工作搭建框架。在推进愿景或战略的过程中，你需要权衡取舍、决定如何解决问题，并决定哪一群人的愿望无法实现。

取舍

决策之所以困难，是因为所有选项都有利有弊。无论你选择什么，都会有缺点。提前权衡你的优先级，可以帮助你决定愿意接受哪些缺点。优点也是一样：每种解决方案很可能都有它的长处！

在我见过的厘清取舍的方法中，最好的之一是比较你想要的结果中的两个正面属性。我听人把这称为“甚于”（even over）陈述。当你说“我们将优先优化易用性，甚于性能”或者“我们将选择长期支持，甚于上市时间”时，你就是在说（引用《敏捷宣言》的话）：“尽管右项有其价值，我们更重视左项的价值。”这种表述方式让取舍一目了然。

建立共识

有时，摆在桌面上的选项没有一个能让所有人满意。确实要努力达成一致，但不要因为没有达成完全共识而卡住：你可能会永远等下去，这样你就又回到了隐含地选择维持现状。可以借鉴互联网工程任务组（IETF）的做法。IETF 的决策原则以拒绝“国王、总统和投票”而闻名，它推崇所谓的“粗略共识”，认为“没有分歧比达成一致更重要”。换句话说，要把握团队的总体意见，但不要坚持每个人都必须完全同意。与其问“大家都同意选项 A 吗？”，不如问“有谁实在无法接受选项 A 吗？”

IETF 的工作组在做决策时，寻求的是团队中的绝大多数人同意，并且主要的反对意见已经得到处理和辩论，即使并没有让所有人都满意。也许不存在让所有人都高兴的结果，他们对此也能接受。Mark Nottingham 在 Stephen Ludin 和 Javier Garza 所著的 Learning HTTP/2（O’Reilly）的序言中，谈到了他在这样一个工作组中的经历：“在少数情况下，大家一致认为向前推进比某一个人的论点占上风更重要，于是我们就通过抛硬币来做决定。”

如果粗略共识无法让你们得出结论，而你们又不准备抛硬币，那就需要有人拍板。这就是为什么最好事先确定你或其他某个人是否拥有明确的领导权威，可以充当打破僵局的人。如果没有人担任这个角色，你可以请发起人来裁决，但要把它作为最后的手段。你的发起人很可能离这个决策太远，不掌握全部上下文；你会占用他们大量的时间；而且他们最终选出的道路可能谁都不满意。

不做决定也是一种决定（只是通常不是一个好决定）

当你在选项 A 和选项 B 之间做选择时，还有一个隐含的第三选项 C：不做决定。人们常常默认选择选项 C，因为这让他们可以骑墙观望，不得罪任何人。这是你能做的最糟糕的事情。决策会约束可能性，让推进成为可能。不做决定本身就是一个维持现状的决定，同时也维持了围绕现状的不确定性。虽然无限期地保留选择余地可能会让你觉得自己拥有灵活性，但从长远来看，你的解空间会一直很大。依赖于这个决策的其他决策不得不两头下注，为你之后可能选择的任何方向做好准备。

如果你意识到需要更多信息才能做出明智的决策，那么你期望获得哪些额外信息，又打算如何获得？如果你选择等待，你在等待的是什么？请记住，你通常不需要做出最好的决策，只需要做出足够好的决策。如果你卡住了，就给它设定时间盒。与其说“我们要选出全世界最好的存储系统”，不如试试说“我们在接下来两周研究存储系统，并在两周结束时做出选择”。

有时，推迟决策也有充分的理由。一个出色的决策网站 The Decider 列出了几种情况：当你为做决定所需投入的时间和精力根本不值得该决策能带来的任何好处时；当决策出错会带来沉重的代价，而做对了却回报甚微时；或者当你怀疑情况可能会自行消失时。但关键在于，你是决定不做决定。你把“不做决定（维持现状）”加入你的选项清单，并有意识地选择它。而不是两手一摊，转身走开。

当你无法确定自己的决策是否是一个好决策时，想一想可能会出什么问题。你能否加入一些方式来纠正方向，或缓解任何负面后果？让自己即使错了，也不至于酿成大祸。

展示你的推理过程

无论你以何种方式做出决策，都要把它记录下来，包括你考虑过的取舍，以及最终是如何得出这个决策的。不要略去缺点：要把它们说得非常清楚，并解释为什么你认为这仍然是正确的道路。在某些情况下，确实不可能让所有人都满意，但你至少可以表明，你理解并考虑过所有的论点。把这些信息告诉同事，不仅是对他们的尊重，还能降低风险，避免每当有新人加入项目、以为你没有注意到他们所看到的缺点时，就不得不重新争论这个决策。

遗憾的是，在创建战略或愿景时，让某些人不高兴是不可避免的。如果每个人都如愿以偿，你很可能并没有做出任何真正的决策。要有同理心，能解决的时候尽量解决每个人的问题，但要果断拍板，并说明你为什么做出这样的选择。

达成一致并保持一致

弄清楚你最终的受众是谁。你需要说服的是少数几位开发者同事？整个公司？还是公司以外的人？想一想如何带着每个群体和你一起踏上这段旅程。

让你的发起人随时了解你的计划和进展。这并不意味着在你还在琢磨自己到底想表达什么的时候，就把一份未经编辑的 20 页文档发给他们。花点时间理清思路，这样你就能给他们带去一份摘要，说明你打算如何处理各种问题、有哪些选项。除非他们想看进行中的工作，否则只分享你所写内容的要点，而不是那些繁琐的细节。特别是，如果你在写战略，要确保至少在几个主要检查点上保持一致：在你确立了诊断之后、在你选定了指导方针之后，以及在你提出了一些行动之后。如果发起人认为你走错了路，你会希望在投入更多时间之前就发现这一点。

保持合理

你的道路应该有抱负，但不能是不可能实现的。有些变革的代价实在太高，根本不值得投入。另一些工作就是无法在你的组织中赢得支持。政治学中有一个概念叫奥弗顿窗口（图 3-3）：在公共话语中可以被容忍、而不显得过于极端、愚蠢或冒险的观点范围。如果你的想法对于那些需要相信它的人来说过于超前，同事们就会对你的文档不屑一顾，你也会失去信誉（第 4 章会详细讨论）。要清楚你的组织能接受什么，不要去打一场赢不了的仗。

图 3-3. 奥弗顿窗口显示了在特定时间内哪些观点在政治上是可接受的（来源：基于 Toronto Guardian 的一张图片）。

根回（Nemawashi）

如果你一路上都让利益相关者保持一致，你的文档就永远不会出现这样的时刻：把一份完成的文档分享给一群第一次听说它的人。我和 Asana 的支柱技术负责人 Zach Millman 聊起他在那里创建战略的经历时，他告诉我，他使用了根回（nemawashi，即事先疏通）的方法，这是丰田生产方式的支柱之一。它的意思是分享信息、打好基础，以便在做出决策时，意见上已经达成了共识。¹¹ 如果有人需要为你的计划点头，你会希望这些人在参加任何决策会议时，就已经确信这项变革是正确的。我一直把这概括为“在确定你有足够的票之前，不要发起投票”，但得知有一个专门的词来形容它，我很高兴。

Keavy McMinn 讲过一个类似的故事，是关于她在 Github 时创建的一份战略。等到她准备好与全公司分享这份文档时，她已经获得了老板以及老板的老板的完全认可，并且在幕后做了大量的前期工作。决策者们已经知道这项工作应该配备人手。发布这份文档仍然为这项工作积累了势头、激发了热情，并帮助更广泛的受众厘清细节、认同这些决策。

不要忘记，达成一致并不只是说服别人。它是双向的。在讨论你的愿景或战略计划时，这些计划可能会发生变化。你可能会发现，很多人纠结于文档中某个对你来说并不真正重要的方面，于是你最终把它删掉了。你可能会在某个引起冲突的点上做出妥协，或者突出某个对你来说并不十分重要、却真正引起受众共鸣的内容。你甚至可能真的找到一个更好的目的地。这些都没关系，这也正是撰写这样一份文档需要时间的原因。

打磨你的故事

一份并非人人都知道的愿景或战略，对你来说没什么价值。如果在你不在场影响人们决策的时候，他们仍然沿着既定方向前进，你就知道这个方向已经被充分理解了。但要做到这一点，你需要把信息装进每个人的脑子里。如果你给组织一份很长的文档让大家去记，是做不到这一点的；你需要帮帮他们。这正是我前面提到的那种精炼的一句话或“汽车贴纸”式口号大放异彩的地方。Mark Barnes 在他的文章“Making the Case for Cloud Only”中写到，他们想出了“Cloud only 2020”（2020 全面上云）这个口号，作为一种有力的方式，让 Financial Times（《金融时报》）的每个人都能轻松记住他们的云战略。Sarah Wells 在谈到同一次迁移时补充说：“这无疑是我们技术战略中开发者能够随口引用的那一条。”如果你的团队知道、理解并不断重复他们要去往何方的故事，你们就更有可能到达那里。

如果你能让人们相信他们想要去往你所描述的地方，你的项目也更有可能成功——而且耗费更少的社会资本。在写作时，想一想你的文字会被如何接受，并清楚你想讲的是一个什么样的故事。回到绘制藏宝图的比喻：想象你已经画好了地图，现在你坐在海盗酒馆里，把藏宝图在桌上摊开，试图让同桌的人想要跟你一起去。你会对他们说些什么？

你需要一个易于理解、能引起共鸣、让人感到舒适的故事。

首先，你要确保故事易于理解。一个简短、连贯的故事远比一串互不相关的任务更有说服力。人们很难对自己不理解的东西产生热情，而且你也会错失让他们在你不在场时替你讲述这个故事的机会。即使他们被你的热情所感染，如果他们并不真正理解这个计划，也无法为它摇旗呐喊。

要确保故事能引起共鸣。宝藏之所以让你兴奋的理由，对其他人来说可能毫无吸引力，所以你如何讲述这个故事真的很重要。如果你的愿景是你自己的团队解决了最烦人的问题、过上了更快乐的生活、还能吃冰淇淋，这非常有吸引力……对你团队里的人来说。如果实现这个愿景需要其他团队的工作，你就需要更多东西。要展示你的工作也会如何让他们的生活变得更好。

同样，记住奥弗顿窗口，确保故事让人感到舒适。一个带领人们从 A 走到 B 的动人故事，只有在他们确实位于 A 时才有效。如果他们离 A 还远得很，你也许更有可能成功的做法是：先说服他们接受 A，等这个想法被认为是合理且被广泛接受之后，再带他们走下一步。

你的故事在人们执行计划时也会帮助他们。正如 Mojtaba Hosseini 告诉我的：“当事情变得困难时，每个人都需要知道困难是意料之中的，而且是可以克服的。不要只讲旅程终点的金子。当出现问题时，你需要能够强调：这正是故事中英雄们掉进坑里的那一段……但随后他们又爬出来了！”

完成定稿

当你花了几周甚至几个月创建一份文档后，可能很难相信，但并不是每个人都会兴致勃勃地去评审它。不要觉得被冒犯！虽然人们可能有最好的意愿，但一份冗长的文档可能会在浏览器标签页里开着很久很久。想一想如何让它易于阅读，或者用其他方式分享要点。避免密密麻麻的大段文字。使用图片、要点列表和大量留白。如果你能找到一种方式让你的观点清晰、令人难忘，就会有更多人领会它们。

一种方法是使用“用户画像”：描述一些受你的愿景或战略影响的人——开发者、最终用户，或者你的任何利益相关者——并描述他们在工作完成前后的体验。另一种方法是描述一个对当前业务来说困难、昂贵甚至不可能的真实场景，并展示它将如何改变。要尽可能具体。除非你只面向同一领域的工程师做展示，否则要避免使用行话。一些读者在遇到几个他们不认识的缩写或技术术语之后，就会开始走神。

你可能会发现，用另一种类型的文档来配合你所写的文档会很有用。如果你要在全员大会或类似场合上做展示，你就需要一份演示文稿。你可能既需要一份详细的长文式或要点式文档，也需要一份只有一页、包含高层想法的电梯演讲稿。如果你愿意与公司以外的人分享，你可以写一篇对外的博客文章：这也可能是触达内部受众的又一个机会。

发布

一份代表某个人想法的愿景文档，与一份由公司或组织正式认可、各团队都在为之努力的北极星式愿景，二者是有区别的。我见过太多文档在这一步夭折，因为作者不知道如何让它们成为现实。

让它成为正式文件

你的文档是你的还是组织的，区别在哪里？主要在于信念。这首先要获得在你的文档所需范围内拥有最终权威的人的认可。通常，这是人员管理链条顶端的那个人：你的总监、VP、CTO 或其他高管。如果你一直在运用根回，与那些意见举足轻重的人保持一致，那么这个人可能已经认同了。如果是这样，看看他们是否愿意发一封邮件、在文档上署名以示认可、在描述下个季度的目标时引用它、邀请你在规模合适的全员大会上展示你的计划，或者做出其他一些公开表态，表明接受这个计划是真实有效的。如果你没有得到他们的支持，请你的发起人帮你推销这个想法。

确保你的文档看起来像回事。把它托管在一个看起来很正式的内部网站上。关闭所有剩余的评论，删除所有待办事项。考虑关闭评论功能，改为留下一个用于反馈的联系地址。如果你能把部门负责人或类似的人列为联系人，那会比只在顶部写上工程师的名字有分量得多。

一份经过正式认可的文档，为人们提供了一个可以用来做决策的工具。然而，让文档成为现实还有另一个重要部分：真正为其中的工作配备人手。如果你提议了新项目或跨组织的工作，你可能需要编制——还需要真正的人来填补这些编制。如果你需要预算、计算资源或其他资源来推进工作，这种需求应该在就方向达成一致的过程中就已经提出了，但现在你将面对真正获取它们的现实。和你的发起人谈谈，如何在常规的优先级排序、编制、OKR 或预算流程中开展工作。

根据组织的不同，你可能需要亲自负责开始执行战略，也可能把它交给其他人去落实。根据我的经验，如果你一直跟进下去，确保在愿景或战略转化为实际项目的过程中，工作保持势头、计划保持清晰，你们所有人都会更成功。

保持更新

发布了愿景或战略，并不意味着你可以不再想它了。业务方向或更广泛的技术背景可能会发生变化，你需要随之调整。你也可能会发现自己选择的方向是错的。这种事会发生。要准备好在一年后重新审视你的文档，如果你意识到它不起作用，就更早一些。如果愿景或战略已经不能解决你的业务问题，不要害怕对它进行迭代。解释你获得了哪些新信息或者发生了什么变化，更新文档，讲一个新的故事。

案例研究：SockMatcher

是时候回到我们在 SockMatcher 的朋友们那里了。当你读到本章开头的场景时，也许你已经对他们该做什么有了一些想法。从某些方面来说，技术问题很容易解决。但做出一个影响许多人的变革，可一点都不容易。

假设你是 SockMatcher 的一名 Staff 工程师。下面是你的方法、写作和发布的故事。

方法

你的上一个项目刚刚收尾，你正在寻找下一件有影响力的事情来做，最好是有点挑战性的事情。为公司中争议最大的核心架构制订一个计划，无疑符合要求。这也感觉是一个重要的问题，能够对业务产生巨大的影响。

你的经理很谨慎。之前已经有很多人尝试过解决这个架构问题——这可能是一片无法穿越的沙漠！你提议花几周时间弄清楚之前的尝试为什么失败。如果你找不到一个令人信服的理由，相信你的旅程会有所不同，你就不做这件事。

之前的尝试为什么没有成功？

你先和两位过去尝试过重构单体架构的 Staff 工程师聊了聊。

第一位是 Pierre，他花了三个月为单体及其周边架构制订了一份详细的技术设计。其他团队并不买账：他们不同意 Pierre 做出的一些取舍，这个方向与他们对自己组件的规划不符，而且他们不喜欢被直接塞给一个现成的方案去实施。由于无法激起大家的热情，Pierre 认定这个问题无法解决（至少以现有的这批工程师无法解决）。他至今对此仍然相当不满。

另一位工程师 Geneva 在尝试重构架构之前，先着手建立联盟。她成立了一个工作组，引起了大量关注。各位参与者起初都很愿意合作，但工作组陷入了争论，无法就一条路线达成一致。长达数小时的会议变成了时间黑洞，人们不再参加，包括 Geneva 自己。

在与这几位以及其他对“解决”单体问题有看法的工程师交谈时，你注意到了两个规律。第一，大多数人心中都有一个具体的解决方案：“问题在于我们没有微服务”或者“我们只需要对数据存储做分片”。每个人都希望自己的方案“胜出”，所以达成共识是不可能的。第二，每个人都只关注技术问题。技术上站得住脚的想法有很多，但没有人规划如何让组织认同一条前进的道路。

你认为，如果把组织层面的一致作为问题的关键来处理，你会更有可能成功。你决心找到一位高管发起人，并确保你提出的任何方向不仅是好的技术方案，而且在这个组织中是可行的。你会务实、放低自我，帮助现有的想法取得成功，而不是试图让自己的方向占上风。

发起人

上一个项目结束后，你在“银行”里存了一些社会资本和信誉（见第 4 章），但你知道这不足以说服所有关心单体的众多团队。你也知道，你将不得不做出一些决策，无法让所有人都满意。如果你需要完全的共识，你就不会成功。此外，你制订的任何计划都可能催生出工程项目。如果你无法为这些工作配备人手，你宁愿早点发现，以免浪费时间。你需要一位高管发起人。

你先找了 Jody，她是负责运维单体的那些团队的总监：让单体更容易维护符合她的切身利益。但她见过自己的人被卷入之前两次改变架构的尝试，她想保护他们的时间。他们有自己的项目，她不希望他们被又一个新举措分散注意力。虽然她赞成重构架构，但那是一种“希望明年吧，也许”的态度。她无意为这项工作投入任何人。

你的下一站是 Jesse，他是负责食品保鲜盒发布的总监。随着这个备受瞩目的项目启动，Jesse 可能更容易获得人手；如果你能让他的成功指标与你的保持一致，他很可能会支持这项工作。在与 Jesse 交谈时，你描绘了这样一个未来：产品团队可以自主工作，产品工程师更快乐，新功能能够快速交付。Jesse 不太确定。那是一个美好的未来，但食品保鲜盒今年就必须发布；他们等不起一次大规模的架构重构。你表示同意：任何解决方案都必须让食品保鲜盒团队以最小的阻力完成发布。Jesse 被说服了。他同意担任发起人并支持你的工作。

其他工程师

你在寻找合著者，也就是几位能为这项工作带来不同视角和知识的同事。你还希望在整个组织中建立盟友，并争取那些会对你的计划持怀疑态度或与之唱反调的人。

你先找了 Pierre，就是那位之前提出详细方案的 Staff 工程师。他倾注心血做出一个周全的方案，却遭遇了彻底的冷漠，至今仍然有些心存芥蒂。他说了一些关于公司领导层的泄气（而且有点刻薄）的话，并明确表示他认为你的工作是在浪费时间。你问他能否把他之前的计划作为你工作的一部分输入，并承诺对你最终采用的任何部分都注明是他的功劳——不过你也提前说明，你会以不同的方式界定项目范围。想到自己的工作能被派上用场，他变得稍微愿意帮忙了。他仍然不愿加入你的团队，但同意接受采访，并在之后评审你的计划。

你邀请 Geneva 一起努力时，抱有更高的期望。她答应加入。让你意外的是，她告诉你，她之前的工作组在某种程度上仍然存在：三位高级工程师每周碰面讨论架构。他们对单体问题思考得非常多，你知道他们能看出一些对你来说并非一目了然的细微之处。你邀请他们一起合作，请他们每周投入两天，至少持续两个月。其中一位工程师 Fran 同意了；另外两位愿意提供建议，但无法投入大块时间。你答应每隔几周回到工作组的会议上同步进展。

你还和其他一些潜在的盟友进行了沟通：

食品保鲜盒项目的团队负责人倾向于把问题看得比实际更容易解决，尤其是涉及分配给单体维护团队的工作时。“他们为什么不直接在单体里构建隔离的模块呢？”她问。但只要有计划，她就会支持。
数据库负责人担心你的项目会给他的团队带来意料之外的工作。（这种担心是合理的：以前发生过这种事。）你承诺会让他随时了解情况，并让他尽早评审计划。
编写最初袜子匹配代码的那位 Staff 工程师资历很深，而且非常有影响力。如果她被说服了，很多其他人也会被说服。她有一些想法，也希望成为早期评审者。

范围

你的核心团队——你、Geneva 和 Fran——讨论了你们想做什么、什么可能会成功。Fran 很想为你们整个架构的演进创建一份技术愿景，但这并不适合你们的情况：你没有那么大范围的影响力，你的发起人也没有。此外，这么大范围的项目也无法赶在食品保鲜盒发布之前准备好。

那么，针对核心单体架构的愿景呢？那会明确你们要去往何方，但各团队在如何到达那里的问题上仍会存在分歧。你们决定，你们需要的是一份针对单体的宏观架构规划，以及一份明确包含食品保鲜盒发布的、如何实现这一规划的战略。你们的目标是描述一年的工作，并保持在高层。你们承诺偶尔会做出一些较低层次的技术决策，但只限于那些没有负责人的决策：大部分实现细节会留给实际承担工作的团队。而且你们的战略必须是正式的：它不能只是一个计划；它必须是组织选定的计划，否则你们不会认为这个项目取得了成功。

当你们达成共识后，你把要做的事写了下来：“制订一份高层次的一年期技术战略，在演进核心单体架构的同时，支持食品保鲜盒的发布。”这有点模糊，但这是个开始！

你们进一步讨论了范围和问题，收集了之前工作的链接和工作组的笔记，让你们自己（以及你们共享的术语）保持一致。你们的文档还很粗糙，不是可以分享给核心团队以外的人看的东西，但它把你们的想法集中在一处，让你们每个人都可以在想到新东西时随时补充。

一旦你有了一份关于目标的电梯演讲，你就去找你的发起人 Jesse 沟通。他认同这个范围以及你们要创建的文档类型。他对于如何让你们的计划正式化的建议是：为它添加一个组织层面的 OKR，并把你的名字列为直接负责人（DRI）。这有点让人望而生畏，但它无疑会给你带来你一直期望的正式认可。他主动提出确保 Jody 和其他总监对此没有异议，并把这个 OKR 加进去。

你为这项工作创建了一个讨论频道，在其他可能有相关人士的频道中宣布了它，并分享了关于范围以及你们所借鉴的已有成果的笔记。你特别强调，你想和有想法的人聊一聊，并且仍然欢迎每周至少能投入两天时间的合作者。前者非常多——后者一个都没有。你开始列出要交谈的人，着手撰写你们的战略。

写作

在跳到解决方案之前，你希望非常清楚自己要解决的是什么问题。你最初界定的范围“制订一份高层次的一年期技术战略，在演进核心单体架构的同时，支持食品保鲜盒的发布”还需要更清晰，但你也不想直接跳到解决方案。你需要诊断现状，准确描述正在发生的事情。

诊断

你可以考虑的事实实在太多了：

当前有一个支持食品保鲜盒的迫切产品需求，而且有迹象表明产品线将来还会进一步扩展。
运维单体的团队被呼叫得太频繁了：这是不可持续的，需要改变。
你们的匹配算法有点慢，命中率还可以更高。
你们的系统目前应对不了流量激增。
用户对你们的可用性不满意。
登录系统很老旧，背负着大量技术债务。
部署新代码既慢又令人沮丧。
外部用户依赖着一些你们希望能够修改的 API。
新增可匹配的产品需要对几个核心组件的逻辑进行重大修改。
许多开发者就是不喜欢在单体里工作。

而这还不是完整的清单！你着手挑选出最重要的事实，讲一个简单得多的故事。你们的团队花了一些时间进行头脑风暴，讨论什么是重要的、什么运转不良、什么现在就很好。你们设想未来的自己面对同一个代码库，工程师人数翻了一倍，产品又多了五个。如果这些产品也都以边界情况的方式实现，那么为每个功能理清业务逻辑将会变得可怕，而在那种情况下修改任何东西都会复杂而危险。构建会更慢，部署会更频繁地失败。更多的名人用户意味着更多的故障。如果你们不采取任何行动，这就是未来。你们最好采取些行动！

虽然头脑风暴之后你们有了很多想法，但你们还不想过早地投入其中。相反，你去和一些产品团队成员，以及工程领导者和一线从业者聊了聊，目的是了解对他们来说什么是重要的。你了解到了一些新信息：

虽然你曾推测名人代言带来的流量激增可能是可用性下降的原因，但实际上由过载引起的故障并不常见，而且持续时间很短：每月只有几分钟的停机时间。虽然你们当然应该在这方面有所改进，但这些故障并不是可用性差的最主要原因。¹² 事实证明，真正造成损害的是一些平平无奇的代码缺陷，以及部署一个修复需要三个小时这一事实。之前提升可靠性的尝试集中在为发布流程增加更多测试上——但这实际上拖慢了部署时间，延长了故障时间。
许多工程团队抱怨在单体里工作，但他们真正讨厌的是发布代码。很大比例的变更会产生意料之外的行为。很难确定你的变更不会破坏别人的东西，而推出一个修复需要半天时间。各个团队因为不断应对故障而变得神经紧张。
计费和个性化子系统是代码库中争议最大的部分，远超其他部分。大多数重大功能变更都会伴随着对这两部分功能之一或两者的相应修改，而它们的逻辑非常复杂，即使做一些简单的修改，也很容易产生意料之外的副作用。

你还了解到了更多东西：你交谈过的每个人都有不同的话题想告诉你。但这些访谈逐渐汇聚成一种模式，让你看清了正在发生的事情。你选出了最重要的那一部分事实，讲了一个简单得多的故事。

下面是你的诊断：

每一次新功能变更都需要对一组共享组件进行复杂的逻辑修改。修改这些组件既慢又困难。意料之外的相互影响意味着各团队不断干扰彼此的工作，并造成长时间的故障。每新增一种可匹配物品，都会增加这些共享组件内部的耦合点数量，让问题变得更糟。我们的系统需要能够应对更多的可匹配组件以及更多添加这些组件的团队，而不会让开发陷入停滞。

选择聚焦点可能是撰写战略过程中最痛苦的部分之一。在这个案例中，未做版本管理的 API 仍然是个问题，糟糕的登录代码最终也会成为问题，而改进匹配功能是一个真正的机会，只是你们现在不打算去争取。这些问题和机会都是真实存在的，但你们做出了一个艰难的决定，暂时忽略它们。

有了诊断之后，你去找发起人 Jesse 沟通，确保他同意你们聚焦在了正确的领域。你还把你们没有聚焦的那些挑战的清单也给他看了，以表明你们看到了它们，只是认为它们不应该排在首位。Jesse 表示同意。

指导方针

既然你已经清楚地了解了正在发生的事情，你就可以决定如何应对了。

桌面上已经有一个提议的指导方针：你的一些同事正在推动彻底拆分单体。他们说，重构架构能让添加新产品变得更容易，还能减少意外故障的数量，并缩短出问题时构建和部署代码修复所需的时间。但各团队仍然需要对共享组件进行有风险的修改。这还意味着所有团队都要开始运维自己的服务，其中一些人将平生第一次承担值班（on-call）职责。最后，这样的变革至少需要三年时间，而在此期间没有任何发布产品的解决方案。所以，虽然“我们改用微服务吧”对于一家约束条件不同的公司来说可能是完美的解决方案，但它没有正视当前的状况。

相反，你着眼于那些花少量工作就能产生巨大影响的地方。一个显而易见的杠杆点就是那两个因集成而拖慢团队的关键共享组件：计费和个性化。如果这两个组件易于扩展，而不是为每个产品硬编码逻辑，其他团队就可以安全地添加新的可匹配物品类型。故障会更少，团队就能腾出时间投入到功能开发和进一步改进系统上。这是一个良性循环。

下面是你的指导方针：

计费系统和个性化系统应该易于集成，且集成起来安全。

你也写了一些关于你们没有选择的指导方针的笔记。你描述了你们考虑过微服务的原因以及那条道路会带来的好处，但也解释了为什么它们解决不了你们的问题。

行动

你着手列出你们的团队需要采取的行动，以应对挑战并贯彻你们的指导方针。

行动必须现实，这一点很重要，所以你去和计费团队、个性化团队及其领导层沟通，确认他们认同你们的方向。计费团队的待办事项里本来就有一些相关工作：提供一个计费功能菜单，让其他团队可以通过设置配置项来进行选择。个性化团队的人曾经考虑过一种插件架构，拥有稳定的核心功能，并为每种可匹配物品隔离出独立的逻辑。添加新物品的团队只需要修改自己的插件组件。这两项变更都会让共享组件更加模块化，支持自助式接入，而这两个团队也乐于有个理由在这些工作上投入时间。

不过，这里存在一个“先有鸡还是先有蛋”的问题：这些都是大型的、有风险的变更。重构这些核心组件很可能会导致许多故障，所以这两个团队一直没有把这项工作列为优先事项。你建议增加通过功能开关（feature flag）发布变更的能力，这样一旦出现回退，只需快速切换回去，而不必再进行一次部署。更安全的部署会降低这项工作的成本和风险。

隔离工作不会一蹴而就，而食品保鲜盒团队在此期间需要与这两个组件进行集成。个性化团队和计费团队愿意把食品保鲜盒团队当作试点客户，以帮助他们成功为优化目标，包括在现有系统中编写他们集成的第一个版本，并在自助模式可用时将其迁移过去。但以目前的人手，这两个团队无法同时承担隔离工作和集成工作。Jesse 同意把原本分配给食品保鲜盒项目的一部分编制让出来，让这两个团队都得以扩充。

下面是你们的行动：

增加一个功能开关系统，支持分阶段发布和快速回滚。
为支付团队增加两名工程师，为个性化团队增加一名工程师。
修改计费和个性化子系统，使新增可匹配物品变得简单、安全，并且可以自助完成。
让计费团队和个性化团队把食品保鲜盒产品接入他们的系统，然后将其迁移，作为新自助方式的试点客户。

这些行动都是高层次的，相关团队拥有设计解决方案和做出大量决策的自主权。但这种方法给了他们一个方向和一些具体的后续步骤。关于行动的其他建议还有非常非常多：你交谈过的每个人都有一长串他们认为应该做的工作，以便让单体更健康。但你们的指导方针让你们得以集中精力，保持清单简短。

你提名 Fran 作为主要作者撰写计划，你和 Geneva 则提出了许多修改建议。这份文档坦诚地说明了你们计划中的取舍，以及你们考虑过的替代方案和没有选择它们的原因。

在与发起人达成一致之后（他建议修改一些措辞，但总体上热情支持），你把初稿分享给几位盟友，对计划进行实地检验。有些人留下了评论。你当面采访了其他一些人，消除了一些顾虑。

每讲一次，你的故事就变得更紧凑一些。你逐步把文档分享给越来越广泛的群体，并开始在一些会议上进行展示。

发布

坦白说吧：你们的计划并没有受到所有人的喜爱。一些同事觉得平淡无奇（而且也许有点生气）：你们的文档并没有比他们的任何想法更有“远见”；它有点无聊！有些人坚持认为这个问题根本不需要一份战略；你们只需要“直接决定”要做什么，而这条路本来就是显而易见的决定。

另一些声音很大的派别则不认为你们的道路是显而易见的：他们认为它根本就是错的。有一群人仍在主张把所有东西都迁移到微服务。另一群人希望更多地关注应对负载激增。而且，虽然食品保鲜盒团队可以把部分功能构建为微服务，但他们仍然需要在单体内部进行大量开发——其中一些人对此不满。不过，由于你们花时间记录了已知的缺点以及考虑过的替代方案，这些都不是新鲜事。抱怨并没有改变计划。

令人高兴的是，支持的声音更响亮。大多数人因为有了一个单一的、正式的、获得一致认可的方向而备受鼓舞。那些从一开始就一路同行的盟友尤其坚定地支持你们。覆盖整个工程部门的 OKR 提升了你们的可见度，你的发起人和他的同级们都认同这项工作，并愿意为其配备人手。你们的计划会为单体维护团队减轻一些负担，而无需他们投入大量精力，所以 Jody 出乎意料地提出让他们帮忙：他们会提供功能开关系统。

在接下来的一年里，你一直跟进这个项目，直接参与计费模块化项目，并担任个性化工作的顾问。就在食品保鲜盒团队庆祝发布成功之后，产品团队立即宣布了一项新工作：匹配丢失的桌游配件。你们的工作意味着桌游团队可以使用新的隔离功能，直接开始构建。随着系统趋于稳定，单体维护团队不再疲于应对：他们已经开始着手改善开发者体验，并让系统更能抵御负载激增。

通过集中精力，你们消除了增长的障碍，也移除了一道拖慢所有人的壁垒。而你也准备好迎接下一个项目了。让我们前往本书的第二部分：执行。

回顾

技术愿景描述的是未来的状态。技术战略描述的是行动计划。
这样的文档通常是集体努力的成果。虽然创建它的核心团队通常规模很小，但你也需要从更广泛的群体那里获得信息、意见和普遍的善意。
事先就要计划好如何让文档成为现实。这通常意味着要有一位高管担任发起人。
有意识地就文档类型和工作范围达成一致。
撰写文档需要多次迭代：与他人交谈、完善想法、做出决策、写作，以及重新对齐。这需要时间。
你的愿景或战略的好坏，取决于你能围绕它讲出怎样的故事。

我们聚焦于愿景和战略，但这些技巧适用于任何重大的集体决策：工程价值观、编码规范、跨组织的项目计划，等等。 ↩
如果有人想聊聊种子轮融资，欢迎联系我。 ↩
你可能会注意到，这类话题仍然在代码评审和设计评审中占用大量讨论时间，尽管它们并不是任何一个具体变更的核心。如果出现了这种情况，或者你看到一些设计中固化了相互矛盾的假设，那就说明你需要独立于任何具体项目或发布，做出一些重大的核心决策。 ↩
我会在第 5 章讨论项目执行时谈到这类文档。 ↩
话虽如此，Stripe 的 Staff 工程师 Patrick Shields 曾告诉我，他鼓励人们为各种事情都写一些小型战略，因为“在进入 NBA 之前，你得先学会打业余篮球”。说得非常好。 ↩
需要提醒一点：如果你总是甘居幕后、为他人喝彩，请确保你的组织认可这种领导力。如果不认可，请确保你也有一些展现自己的机会。我会在第 4 章谈到信誉和社会资本。 ↩
如果你直接跳到了这个战略章节，跳过了本书前面那些“你的工作到底是什么？”的自我反思，那么你的范围就是你觉得自己负有责任的领域、团队或多个团队。它通常与你的经理所负责的范围相同，但并不总是如此。 ↩
这个问题的答案通常是否定的。 ↩
在他们的著作 Fundamentals of Software Architecture（O’Reilly）的第 4 章中，有一份详尽的清单。 ↩
本书的开发编辑 Sarah Grey 说，如果处理不慎，这可能会成为编辑的噩梦，而一想到要汇总所有这些草稿，她就头疼。如果你选择这条路，要清楚自己将面对什么。 ↩
正如他所写的，你希望在一对一会议中听到那些“辛辣的意见”，并在决策者开会之前根据需要调整你的计划。 ↩
如果放弃一部分名人流量会被视为负面公关或错失良机，你可能仍然会优先处理它。上下文决定一切。 ↩

Keyboard shortcuts

The Staff Engineer's Path（中文版）