你经常会看到一些杂乱无章的想法被贴上“战略”的标签。即使这些文档内容很多，也往往很难读懂。这也是为什么很多工程师会说，他们所在的公司没有清晰战略。

不过，根据我的经验，所有公司其实都在遵循某种战略，只是这种战略未必被明确写成文档。对于工程管理者和技术负责人来说，真正的挑战不是“有没有战略”，而是如何用结构化方法制定一套清晰、可信、可执行的工程战略。

本章将介绍一种可重复、结构化的工程战略制定方法。它会概览这套方法中的每个步骤，而这些步骤也会在后续章节中进一步展开。

本章将讨论以下内容：

这五个步骤如何相互配合，帮助你制定工程战略，尤其是如何防止实践者跳过那些令人尴尬、困难或不熟悉的步骤。

第一步，探索。也就是研究整个行业围绕你当前战略问题所形成的理念和实践。探索的目的，是了解哪些最新研究可能改变你的方法，以及自你上一次处理类似问题以来，相关技术和实践已经发生了哪些变化。

第二步，诊断。也就是理解问题的具体细节。在尝试解决问题之前，人们往往很难放慢脚步，真正弄清问题是什么。但如果没有清晰诊断，几乎不可能把事情做好。

第三步，完善。也就是对一组未经验证的原始想法进行现实检验。为了支持这一验证过程，本章会引入三种方法：战略测试、系统建模和沃德利地图。

第四步，制定方针。也就是通过权衡取舍和做出决策，来回应诊断结果。这些决策覆盖范围很广，可能涉及软件架构设计，也可能涉及拉取请求的评审方式，还可能涉及组织内部的人力分配。

第五步，运营。也就是将方针转化为组织内部实际行动的具体机制。这些机制可以是提醒你注意某些缺少相应测试的代码变更，也可以是每周召开一次会议，用来讨论迁移工作的推进情况。

这些步骤究竟是不可动摇的，还是可以灵活调整和试验的？当你个人觉得某些步骤无效时，是否仍然应该坚持尝试？本章也会讨论这些问题。

读完本章后，你将对工程战略制定的每个步骤形成整体认识，并可以决定接下来想深入阅读哪一部分。

本文是《制定工程战略》中的一个章节。

工程战略制定的五个步骤如何汇聚成战略

制定有效战略，并不是机械背诵某个公式。你不能仅仅因为遵循了这些步骤，就保证一定能制定出优秀战略。

然而，我一直发现，战略失败更多时候并不是因为根本性的思维缺陷，而是因为一些本可以避免的错误。忙碌的人往往会跳过某些步骤，尤其是那些他们不喜欢、觉得尴尬，或者过去曾经失败过的步骤。

这些步骤的价值，就在于帮助你减少这类错误。通过定期练习，你会逐渐养成良好的战略思考习惯，并培养出判断当前战略最适合采用哪种方法的能力。它们也有助于把战略制定变成一种共同实践，让你、你的同事，以及更广泛的工程生态都能参与其中。

每一步都是下一步的输入。探索是做出可靠诊断的基础。诊断能帮助你从广阔的方针空间中，找到当前真正需要解决的问题。运营机制则能帮助你把方针转化为支持战略的积极力量，而不是让它停留在抽象理论层面。

如果你对这些步骤持怀疑态度，当然可以保持怀疑。但在完全放弃之前，不妨先尝试几次。你或许也会从战略制定中关于“理论与实践如何结合”的相关章节中获得启发。

第一步：探索工程战略的问题空间

探索，是指在决定采用某种战略之前，有意识地研究该战略所处的问题空间和解决方案空间。

它包括了解其他公司和团队如何处理类似问题，以及他们的方法是否适用于你当前的情况。它也包括理解：为什么你在上一家公司取得巨大成功的方法，未必就是当前组织的最佳解决方案。

海外某出行平台公司的服务迁移战略，就采用了探索式方法。它通过阅读行业文献来理解服务生态系统：

作为起点，我们发现，阅读关于海外某大型科技公司大规模集群管理实践的论文，以及关于数据中心细粒度资源共享的论文很有帮助。前者为后来一些容器编排方法提供了思路；后者则描述了另一类资源调度和服务编排方法。

该战略还使用沃德利地图来探索云计算生态系统。

2014 年服务编排的演进。

更多详情，请阅读“探索”章节。

第二步：诊断工程战略需要解决的问题

诊断，是指在制定应对方针之前，努力准确识别战略需要解决的具体情境。

从探索中获得的经验，以及你对当前情况的理解，会共同构成诊断的基础。诊断过程会迫使你推迟思考解决方案，直到你真正理解问题的细微差别。

诊断可以在很大程度上依赖数据。例如，在制定私募股权所有权过渡战略时，诊断中可能会写道：

今年我们的工程人员成本同比增长了 15%，去年同比增长了 18%。人员数量分别增长了 7% 和 9%。人员数量增长与人员成本增长之间的差异，主要来自以下几个方面：薪酬等级调整（4%）、重点招聘高级岗位（3%），以及在高成本地区增加招聘（1%）。

诊断也可以较少依赖数据，而更多用于总结问题。例如，某次收购整合战略在交易完成前，总结了技术整合中的已知信息和未知信息：

为了按时实现目标，我们需要迅速整合被收购的初创公司。目前，我们对具体整合过程了解甚少。我们只知道，销售点终端会直接处理支付信息。例如，销售点终端知道它读取到的信用卡信息。

我们的合规义务要求，此类活动只能在“令牌化环境”内进行。这是一个高度安全且隔离的环境，可以直接访问支付详情。该环境会将支付详情转换为唯一令牌，其他环境可以使用该令牌对支付详情进行操作，而不必承担直接访问底层支付详情所带来的合规成本。

在真实的工程管理场景中，诊断质量也取决于研发过程数据是否完整、连续、可追溯。比如，PingCode 这类智能化研发管理工具，可以覆盖从团队目标、客户反馈、需求评审、项目开发、测试发布到 Wiki 知识沉淀的全生命周期，帮助团队把分散在研发链路中的信息连接起来，让战略诊断更容易建立在真实数据之上，而不是只依赖访谈和经验判断。

“诊断”章节会详细介绍诊断方法，以及诊断过程中常见的挑战。

第三步：完善工程战略，包括测试、地图和模型

战略完善，是一套方法工具箱，用来识别诊断中哪些部分最重要，并验证你解决诊断问题的方法是否真正有效。

本章将深入探讨三种方法的具体应用：战略测试、系统建模和沃德利地图。

用户、负载均衡器和服务器之间的请求成功与失败情况。

系统建模图示例。

这些技术也体现在若干战略案例研究中，例如 LLM 生态系统的沃德利地图，或者用于说明如何在不降低岗位级别的情况下填补岗位空缺的系统模型。

更多详情，请阅读“完善”章节。

为什么战略完善不能更早或更晚进行？

一个常见分歧是：有人认为完善战略应该发生在诊断之前。

另一个分歧是：绘制地图和建模应该拆分成两个不同步骤。绘制地图应该发生在诊断之前，而建模应该发生在方针制定之后。

第三种观点则认为，完善应该是战略制定的最后一步，从而让整个过程形成一个循环。

这些观点都有合理之处，所以我想详细说明一下，为什么我会采用当前这种结构。

对于大多数战略而言，最大的风险并不是建模太早，或者绘制地图太晚，而是这两个步骤被完全跳过。我最关心的是，如何尽可能降低绘制地图和建模所需的投入门槛，让更多人能够完成这些步骤。

在探索和诊断之后进行完善，可以让你把精力集中在少数几个真正关键的区域。

当然，在制定战略的过程中，对某些部分进行多次调整是很常见的。你可能需要进行三次小调整，也可能需要进行一次大调整。

第四步：制定工程战略方针

制定方针，是将诊断结果转化为具体计划。

这个计划还必须切实可行。因此，你既需要仔细研究公司内部已经证明有效的方法，也需要结合探索当前问题时发现的新思路。

方针的范围可以很广。它可以是方向性的指导，例如用户数据访问控制战略中的这段指导：

良好的安全讨论，不会把决策框定为安全性和可用性之间的二选一。我们会寻求多维度权衡，以同时提升安全性和效率。如果讨论被局限在安全性与实用性之间，那就说明我们的讨论方向错了，我们应该重新思考方法。

我们将优先考虑那些能够自动授权，并自动记录客户数据访问理由的机制。最明显的例子是：对于已经分配给某位客服人员的未解决工单，系统会自动授予这位客服人员访问权限，并在工单被重新分配或解决后撤销该访问权限。

方针也可以是承诺暂时不做某个决定。比如，在某次收购整合战略中，就做出了这样的安排：

关于是否引入 Java 的决定，将推迟到以后再做。引入 Java 与我们现有的工程战略并不兼容，但目前我们尚未能与各利益相关方就如何解决这个问题达成一致。此外，我们认为，试图在当前阶段解决这个问题，会分散我们按时实现六个月内推出联合产品这一目标的注意力。

我们将在首发版本发布后，再展开相关讨论。

本章会进一步探讨如何评估方针、如何处理难以确定方法的模糊情况，以及如何制定新的方针。

详情请阅读“方针”章节。

第五步：让工程战略运营落地

即使是最好的方针，也需要被解释和执行。

方针制定者不可能预料到所有新情况。而且，即使这些制定者早已离开组织，方针仍然可能继续生效。运营机制，就是让方针真正落地执行的具体方式。

最简单的机制，是明确的升级路径。海外某冥想应用公司的产品工程战略中，就包含了这样的规定：

例外情况需经首席技术官批准，并且必须以书面形式记录。上述方针有意设计得较为严格。有时，这些规定可能并不完全适用于现实情况，我们会酌情做出例外处理。

然而，每一项例外都必须经过深思熟虑，并基于我们共同关注的具体问题，包括我们想要解决什么问题，以及打算如何解决这些问题。如果我们各自为政，朝着各自偏好的解决方案努力，那么我们不仅无法成为推动产品发展的引擎，反而会给公司带来负面影响。

从这个起点出发，机制可能会变得复杂得多。本章将探讨如何评估机制、如何制定行动计划，以及我在各种战略中见过的最常见行动机制类型。对于需要把战略拆解到日常协作中的团队，Worktile 这类通用项目协作系统也可以作为运营机制的一部分，用任务、项目、文档、目标、日历、甘特图、工时和审批等能力承载具体行动，让战略不只停留在文档里，而是进入团队每天的协作流程。

更多详情，请阅读“运营”章节。

工程战略制定结构是否不可更改？

当有人苦于撰写战略文件时，人们最先推荐的工具之一，往往是战略模板。

模板当然很有用。它们能把原本范围宽泛、难以把握的项目简化成更容易操作的结构。如果你还在犹豫是否应该用模板来制定战略，那么我的建议是：当然可以，大胆尝试。

然而，我也发现，许多初衷良好、设计周全的模板，最终却会变成笨拙、生硬、毫无用处的文档，对任何人都没有好处。

优秀模板的秘诀在于，必须有人负责维护它。而且，这个人首先必须关心模板撰写者自身的需求，而不是那些想在战略制定过程中不断加入要求的各方利益相关者。

计划的安全性、合规性和成本当然重要。但许多组织会开始在这类文档中堆砌越来越多的要求，最终让撰写战略文件本身变成一件极其痛苦的事情。

对于那些正在尝试撰写战略的人，我能给出的最佳建议是：只要你能解释清楚某个要素原本想解决什么问题，就可以舍弃所有阻碍你继续前进的要素。

例如，如果你在起草战略时找不到任何合适的运营机制，没关系，可以直接删掉那一部分。

归根结底，战略的结构并不是不可动摇的。真正重要的，是各部分背后的思考。