在吉姆·柯林斯的《伟大的选择》中，他提出了先发射子弹，后发射炮弹的概念。他的前提是，在完全投入新想法之前，你应该以低成本测试新想法。你的组织只能发射少量的炮弹，但它可以提供更多的子弹，那么为什么不使用子弹来消除炮弹弹道的风险呢？
本章介绍了一系列我个人在达到炮弹阶段之前用来有效完善策略的具体技术。我们将概述策略细化，包括：
- 策略细化实践介绍
- 为什么战略细化是战略创建中影响最大的步骤
- 混合激励通常会导致跳过细化，即使跳过会导致更糟糕的组织结果
- 通过选择各种细化技术（例如策略测试、系统建模和Wardley 映射）来构建您的个人工具包来细化策略。
- 对每种细化技术的简要介绍，以提供足够的背景来选择哪些技术可能对您正在制定的策略有用
- 对跳过细化或制造同意以制造细化假象而不提供好处的反模式的调查
本书的细化部分详细介绍了每种细化技术，例如系统建模，包括特定工程策略的具体应用。
这是一本关于工程策略的书的探索性草稿章节，我正在#eng-strategy-book中集思广益。因此，一些链接指向其他草稿章节，包括已发布的草稿和非常早期的未发布的草稿。
什么是策略细化？
大多数策略之所以成功，是因为它们在更广泛的策略中正确地解决了狭隘的问题。虽然可以实施整个策略来验证该方法，但这既低效又缓慢。更糟糕的是，你很容易因各种细节而分心，以至于忽视了使你的策略产生影响力的杠杆。
策略细化是一个方法工具包，用于识别那些最重要的狭窄问题，并验证您对这些问题的解决方案是否有效。工具包中合适的工具会根据您正在制定的策略而有所不同。它可能会使用 Wardley 映射来了解生态系统的演变将如何影响您的方法。或者可能是系统建模来确定迁移的哪一部分是最有价值的杠杆。在其他情况下，它会减慢对你的策略的承诺，直到你完成了一次狭窄的测试，以消除你还不太确信的部分的风险。
到目前为止，无论您在工作中依赖什么工具来完善策略，总有新的完善工具可供选择。本书对我认为可靠有用的几种工具进行了可行的介绍，同时为部署您为策略细化而开发的其他技术提供了更广泛的基础。
精致重要吗？
在 Stripe，工程主管一次性推出了敏捷技术作为工程开发所需的方法。这一变化是为了解决我们在超过一个月的时间内进行规划的困难，当我们开始与希望我们在签署合同时承诺特定功能的企业合作时，这正成为一个越来越大的挑战。另一方面，该方法效果不佳，因为它假设问题是工程经理普遍不熟悉敏捷技术。采用的挑战不是意识，而是在拒绝拒绝的环境中对众多利益相关者的要求进行优先排序的困难。
在这次敏捷部署中，缺乏共享规划范式是一个真正的、恰当的问题。然而，该解决方案解决了问题中最简单的部分，而没有解决更混乱的部分，因此未能取得有意义的进展。这种情况发生的数量令人惊讶，并且可以通过少量的改进来很大程度上避免。
另一方面，我们完全通过细化来创建 Uber 的服务采用策略，因为基础设施工程团队没有任何权力来强制进行更广泛的更改。相反，我们依靠两种不同的改进来集中我们的交互努力。首先，我们使用系统建模来了解我们需要关注采用的哪些部分。其次，我们使用策略测试通过将各个产品工程团队迁移到新平台来学习。
在敏捷采用的例子中，未能细化将一个中等挑战性的问题变成了战略失败。在服务迁移的例子中，专注于精细化，将一个极其困难的问题转化为成功。根据我的经验，细化是有效战略的核心。
如果重要的话，为什么会被跳过呢？
当一个小团队制定一个策略，即所谓的低姿态策略时，他们几乎总是花费大量的时间来完善他们的策略。这并不是因为大多数团队都相信精益求精。相反，这是因为大多数团队缺乏权力迫使其他团队与他们的策略保持一致。这种权力的缺乏意味着他们必须逐步证明自己的方法，直到其他团队或高管认为值得与之保持一致。
高海拔战略通常是高管的领域，他们通常有能力强制采用，并经常跳过细化阶段，即使它的成本低廉并且几乎可以保证使他们更加成功。这是为什么？当高管开始担任新职务时，他们知道给人留下早期印象很重要。不幸的是，他们还知道，听起来雄心勃勃往往比有效的工作更能引起领导团队的共鸣。因此，虽然他们确实希望最终取得成效，但他们很早就启动了一些雄心勃勃的举措，例如对代码库进行大规模检修，相信这将树立他们作为公司有效领导者的声誉。
这并不是唯一的行政失败，它也经常发生在宽松的战略组织中，这些组织需要雄心勃勃的高杠杆项目才能晋升为高级工程职位。例如，您可能在公司中实施了一种新颖的网络或授权方法，在解决了一些更简单的证明点后，该方法的采用失败了，并将其遗产追溯到晋升标准。在许多情况下，晋升将在部署停止之前进行，从而抑制了想要晋升的工程师过于担心这是否对组织产生净积极影响。负责晋升标准的高管最终会认识到这个缺陷，但对于他们来说，在一个创新太多、同时赋予个人权力的组织和一个几乎没有浪费但创造力空间有限的组织之间进行选择并不是最容易的权衡。
精炼被跳过的另一个原因是，有时你被迫紧急制定并承诺一项策略，通常是因为你的老板告诉你这样做。这实际上并不会阻止改进——只是说你已经承诺并改进了——但这种互动常常会让战略家失去理智，欺骗他们在理智上认为他们无法改变他们的方法，因为他们已经承诺了。这从来都不是真的，所有的决定都需要通过适当的证据进行审查，但是当你周围的人要求每周更新完成项目时，需要一定的勇气来完善。
策略细化被跳过的另一个重要原因是：许多人还没有建立一个工具包来执行策略细化，也没有与拥有工具包的人一起工作。
构建你的工具包
我永远感激我的父亲，一位经济学教授，在我高中的一个夏天，他带我去波士顿参加一个系统建模研讨会。这让我看到了推理问题的广阔技术世界，系统建模成为我策略细化工具包中的第一个工具。
关于细化的部分将详细介绍三种细化技术：策略测试、系统建模和Wardley 映射，以及调查策略顾问更常见的一些其他技术。我很早就采用了系统建模，而 Wardly 映射是我在写这本书时才学到的。很少有人能熟练使用许多优化工具，但是解锁您的第一个工具非常强大，并且随着时间的推移慢慢扩展您对其他工具的体验是值得的。所有工具都有缺陷，并且每种工具都最擅长解决某些类型的问题。
如果所有这些都不熟悉，那么浏览所有这些并选择一个似乎最适合您当前正在解决的问题的一个。您将通过尝试解决许多不同问题的工具并与参与的同行讨论结果来积累专业知识。
在练习时，请记住，分享的重要内容是从这些技术中学习，并尽量避免过于沉迷于分享技术本身。我见过这些技术有意义地改变了策略，但我从未见过这些改变通过细化技术本身的内在洞察力而成功地证明是合理的。
策略测试
有时，您需要一种策略来解决模棱两可的问题，或者对诊断阻碍进展的问题知之甚少的问题。在 Carta，我们解决的一个策略问题是提高代码质量，这是这两个问题的一个很好的例子。很难就什么是代码质量达成一致，同样也很难就改进代码质量的适当、具体步骤达成一致。
为了解决这种模糊性，我们花了相对较少的时间来思考正确的初始解决方案，并花费了大量的时间来部署策略测试技术：
- 确定策略中最窄、最深的可用部分。迭代应用该切片，直到看到一些它正在起作用的证据。
- 在迭代时，确定可帮助您验证该方法是否有效的指标。
- 相信人们都是善意的，而策略的失败是由于过度的摩擦和不良的人体工程学造成的。
- 不断完善，直到您确信策略的细节在实践中有效，或者需要从新的方向来实施该策略。
在这种情况下，我们取得了一些小胜利，资助了一些我们认为可以长期改善问题的具体赌注，并在没有做出重大组织承诺的情况下提前结束了该计划。你可能会说这是一次失败，但我的经历却截然不同：出现问题并不意味着你有一个优雅的解决方案，策略测试可以帮助你验证解决方案的效率和人体工程学是否可行。
如果您正在处理一个非常模糊的问题，并且对于您所操作的现实的本质没有达成一致，那么策略测试是一个很好的开始技术。
系统建模
当您不确定复杂系统中的杠杆点可能位于何处时，系统建模是一种有效的技术，可以轻松地确定哪些杠杆可能有效。例如，在乘车共享应用程序中引入司机的系统模型表明，重新吸引离开平台的司机比在成熟市场中引入新司机更重要。
同样，在 Uber 服务迁移示例中，系统建模帮助我们专注于消除服务启动期间的前期步骤，转向合理的默认设置，并避免迫使团队在新服务平台表现出对他们有用的功能之前就学习新服务平台。
虽然您当然可以在不建模的情况下获得这些见解，但建模往往会使这些见解立即可见。如果您的模型不能立即阐明最重要的事情，那么研究模型的预测如何与现实世界的数据相冲突将指导您了解您的假设在哪里扭曲了您对问题的理解。
如果您大致了解一个问题，但需要确定在哪里集中精力才能产生最大的影响，那么系统建模是值得部署的技术。
沃德利测绘
许多工程策略隐含地假设我们正在运行的生态系统是静态的。然而，这肯定是错误的。许多经验丰富的工程师和工程领导者拥有出色的判断力和直觉，但仍然部署了有缺陷的策略，因为他们停留在对事物如何工作的记忆上，而不是注意到事物如何随着时间的推移而变化。
如果您不想被它们击中，而是想将这些变化纳入您的策略中，那么Wardley 地图是一个很好的工具，可以添加到您的工具包中。
Wardley 地图允许您绘制用户及其需求，然后研究这些需求的解决方案将如何随着时间的推移而变化。例如，如今，基于大型语言模型的最新进展而构建的窄平台不断增多，但研究 LLM 生态系统的 Wardley 地图表明，该生态系统很可能会整合为更少、更广泛的平台，而不是保持如此广泛的分散不同的供应商。
如果您的战略涉及采用高度动态的技术，例如 2010 年代的可观测性，或者如果您的战略打算在五年多的时间内运作，那么 Wardley 映射将有助于揭示行业演变将如何影响您的方法。
细化中的反模式
我们已经讨论了为什么经常跳过细化，这是最常见和最严重的细化反模式。在 Calm，我们热衷于将单一代码库分解为微服务；我们没有理由相信这会提高开发人员的生产力，但我们继续推行这一策略一年后才意识到我们正在遭受跳过细化的困扰。
第二个最常见的反模式是通过制造同意来营造策略细化的印象。一位新的高级领导者加入了 Uber，并要求制定完整的技术范围架构，并通过许多内部领导者在其团队中成功采用相同技术的证据来部分证明这一点。在与这些内部领导人交谈时，他们自己也怀疑该提案是否有意义，尽管事实上他们的表面协议被用来说服更广泛的组织相信他们相信新方法。
最后，经常会进行精炼，但反证据会被丢弃，因为精炼团队正在针对某种副目标进行优化。我在 Yahoo 的第一个团队采用 Erlang 作为Yahoo!的关键组件。构建您自己的搜索服务，事实证明，它是解决我们想要使用 Erlang 的问题的绝佳解决方案，但对于当前的核心问题来说，这是一个值得怀疑的解决方案。我们十五人团队中只有三名工程师愿意接触 Erlang 代码库，但反证据被忽略，因为它与次要目标相冲突。
概括
本章介绍了策略细化的概念，调查了三种常见的细化技术——策略测试、系统建模和 Wardley 映射——并提供了构建个人细化工具包的框架。当您准备好了解更多详细信息时，本书中还有一个部分专门介绍应用这些技术的细节，从策略测试开始。