如何制定工程战略？解决工程战略缺失的实用方法

在我的职业生涯中，我经常听到同事、团队成员，甚至素不相识的网友抱怨同一个问题：

“我们公司没有工程战略。”

所谓工程战略，并不是一句宏大的口号，而是帮助工程组织在技术决策、架构演进、研发效能和资源投入上形成一致判断的方法。我认为，缺少战略并不是工程部门独有的问题。产品、设计和业务团队中，也经常有人抱怨公司缺乏战略。

为什么这么多公司缺少清晰的业务战略或产品战略？对此我不敢妄下结论。但为什么这么多工程团队没有清晰的书面工程战略？对此我有一些自己的观察。

我很幸运，曾参与过多家公司的架构设计工作，也参与过某海外支付科技公司多个阶段的架构演进。这些经历让我受益匪浅。基于这些经验，我曾多次尝试写过工程战略相关内容：

• 通过大量探索，整理某海外支付科技公司工程战略的公开版本；
• 提出一种“先写五份设计文档，再综合提炼”的方法，用来帮助个人贡献者推动工程战略；
• 讨论工程负责人应该如何主导公司的工程战略；
• 收集其他人撰写的工程战略资源，并整理到一本面向资深工程师的书籍附录中。

在这次演讲中，我希望把这些想法整合起来，形成一套更统一的工程战略理论。尤其重要的是，我想讨论：即使你不是公司的 CTO，也如何推动工程战略的制定和落地。

换句话说，我希望通过这次演讲，尝试“解决工程战略危机”——也就是解决很多人反复向我咨询的问题。

本文将讨论什么

围绕工程战略，我会讨论五个主题：

1. 工程战略 = 诚实诊断 + 务实方法；
2. 工程战略很有用：它能提高开发速度，降低组织摩擦；
3. 工程战略其实无处不在，只是很少被写下来；
4. 书面工程战略更有力量；
5. 你也可以推动公司的工程战略发展。

什么是工程战略？

每当我思考战略时，都会从《好战略，坏战略》这本书开始。书中提出，有效战略有三大支柱。

1. 诊断

诊断是一种对挑战本质的解释。它要回答的是：真正的问题是什么？

一个好的诊断，应该能指出问题背后的根本原因。

例如：“在制品过多，导致我们无法完成任何事情。因此，每个迭代周期结束时，我们都比上一个周期更加落后。”

这就是一个不错的诊断。它不是简单说“团队效率低”，而是指出了效率低背后的具体机制。

2. 指导方针

指导方针是一组用于应对挑战的通用原则。

好的指导方针通常包含显性或隐性的取舍。

例如：“只为最紧急的团队招聘，不要把招聘资源平均分散到所有团队。”

这就是一条指导方针。它明确表达了取舍：我们选择集中资源解决最关键的约束，而不是追求表面上的平均公平。

如果某条指导方针没有暗示任何取舍，你就应该对它保持怀疑。

例如，“更加努力地完成任务”并不是真正的指导方针。更真实的说法可能是：“让员工持续高强度工作，并准备接受高离职率。”

这才是它背后的真实取舍。

3. 协调一致的行动

协调一致的行动，是一组由指导方针引导、用来应对挑战的具体行动。

这是战略中最重要的部分，也是我最感兴趣的部分。因为它明确指出：只有当战略能够促成协调一致的行动时，战略才真正有意义。

这个定义对我非常有帮助，也深刻影响了我对工程战略的理解。

特别是，我认为工程战略可以归结为两个核心要素：

第一，诚实诊断。
直面组织当前的真实需求和真实挑战。

第二，务实方法。
在承认现实限制的前提下，提出可以推进工作的实际做法。

这听起来不错，但到底意味着什么？

我们来看一个很多人在职业生涯中可能都遇到过的例子。

一个常见的工程战略失败案例

假设你加入了一家新公司。

你的团队使用 Python 单体架构来构建 Widget 产品。

你的 CTO 讨厌单体架构，于是强制要求团队迁移到服务化架构。

随后，你加入了另一个团队，开始在新的服务体系中构建全新的 Hammer 产品。

两年过去了，你原来的团队和 Widget 产品仍然留在那个庞大的单体系统里。

而你现在完全不知道，应该如何在 Widget 和 Hammer 之间共享代码。

我认为，这类事情之所以不断发生，是因为工程战略失败。而一个好的工程战略，是可以避免这种情况的。

为了理解原因，我们先拆开来看。

什么是糟糕的诊断？

在这个例子里，糟糕的诊断往往会把愿望当成事实。

例如：

“我们可以在三个月内把单体架构迁移到服务架构。”

“只要把一个复杂组件从单体系统中拆出来，我们就能降低风险。”

“我们愿意大力投资服务化转型，即使这会在短期内降低产品迭代速度。”

“我们愿意扩充开发者工具团队，让他们同时支持现有单体架构和新的服务架构。”

这些说法听起来像是战略判断，但如果它们没有经过现实验证，就更像是愿望清单。

对于一家只有一款简单产品的小型创业公司来说，在几个月内从单体架构迁移到服务架构，或许真的可行。

但对于一家规模更大的公司来说，这通常几乎不可能。

诚实诊断的关键，是基于现实评估自己所处的处境。

没有绝对诚实的诊断，也没有绝对糟糕的诊断。但有些诊断更接近现实，有些则只是在表达偏好。

什么是更诚实的诊断？

在这个例子中，一个更诚实的诊断可能是：

“我们的单体系统已经支撑了大量产品逻辑，迁移成本远高于预期。”

“服务化可能带来长期收益，但短期内会显著增加工具、运维和跨服务协作成本。”

“开发者工具团队目前没有足够能力，同时高质量支持单体架构和服务化架构。”

“如果我们允许所有新产品直接采用服务架构，那么未来几年内，我们很可能同时维护两套不成熟的开发体验。”

这类诊断不一定令人兴奋，但它更接近现实。

它不会说“我们想要什么”，而是先说明“我们现在真实处在什么状态”。

务实方法：明确取舍，而不是喊口号

一旦你有了基于现实的诚实诊断，战略的第二部分就变成了务实方法。

最重要的一点是：务实方法必须明确权衡取舍，并承认现实限制。

例如，以下说法虽然写起来可能有点痛苦，但它们是不错的方法：

“我们希望迁移到服务架构，但不愿增加开发者工具团队人手。因此，迁移将在工具建设完成后的 12 个月内逐步进行。”

“即使我们更喜欢其他编程语言，也不会轻易采用它们，因为我们没有能力长期支持更多语言生态。”

这些方法的优点，不在于它们听起来宏大、优美或令人振奋。它们的优点在于：它们具体说明了组织将如何面对限制。

回到前面的 Hammer 和 Widget 案例，一个更务实的方法可能是：

• 明年将开发者工具团队扩充 2 名工程师；
• 新增工程师优先投入服务化工具建设；
• 在正式开放服务化迁移之前，先将 Widget 产品迁移成服务，并用它验证服务化开发体验；
• 如果 Widget 团队在服务架构下的生产力无法超过单体架构，则迁回单体；
• 在 Widget 迁移被验证成功，并且取得显著改进之前，不允许其他产品启动新服务；
• 改进效果用两个指标衡量：产品工程团队花在功能开发上的时间占比，以及与去年相比 Widget 主要产品发布数量的变化。

遗憾的是，真正可行的方法必然取决于公司和具体情境。

即使你照搬完全相同的方案，在另一家公司里也可能产生糟糕结果。这也是为什么很多高层领导者在新公司重新使用熟悉策略时，常常会失败。

希望到这里，你已经能够接受这个定义：

工程战略 = 诚实诊断 + 务实方法。

接下来，我想说明：这个定义确实有用。

工程战略为什么有用？

我们可以通过一些真实经历中的工程战略案例，来说明工程战略的价值。

以下案例中的公司名称均做了泛化处理。

案例一：某海外支付科技公司——“我们在单一代码库中运行单体应用”

诊断

这家公司所处行业受到大量动态外部因素影响：不同国家和地区的监管机构、众多金融合作伙伴，以及不断增长的企业客户需求。这些外部因素经常变化，而且难以预测。

它还需要与数千个外部金融基础设施集成，而这些外部系统往往技术质量参差不齐、接口不一致、漏洞频出，并且夹杂大量人工流程。

同时，它内部还有一个相当复杂的金融平台，其他产品都构建在这个平台之上。

方法

它的核心方法是：

• 把主要风险预算用于应对外部变化；
• 通过在单一代码库中运行 Ruby 单体应用，降低内部技术风险；
• 大量投资开发者工具，确保 Ruby 和单一代码库能够在大规模下运转；
• 例外情况很少，只在少数特殊领域允许偏离。

影响

这套战略的影响非常明显：

• 大部分创新预算投入到产品，而不是基础设施重建；
• 避免了当时很多科技公司耗费多年经历的微服务转型之路；
• 技术栈足够收敛，使得开发者工具投资可以集中到少数关键方向，例如静态类型、代码库规模化和开发体验优化。

案例二：某海外冥想应用公司——“我们是一家产品工程公司”

诊断

这家公司曾花大量时间争论是否应该采用新技术。

团队似乎经常出于“想学习新技术”或“想尝试新技术”的兴趣而引入新技术。

同时，公司正在推进一项长期服务化迁移，但实际上只迁移了少量基础设施和平台组件。所有产品工程代码仍然留在单体架构中。

开发者工具团队也被拆成两部分：一部分支持单体架构，另一部分支持服务化工作流。

方法

最终形成的方法是：

1. 我们是一家产品工程公司；
2. 我们采用新技术，是为了创造有价值的产品功能；
3. 我们不会出于其他原因采用新技术；
4. 除非存在明确功能需求，否则所有代码都写在单体架构中；
5. 例外情况必须由 CTO 批准，并在工程公共频道中以书面形式发布。

影响

这套战略带来的影响包括：

• 团队不再反复争论技术投资方向；
• 少数不愿接受这套战略的工程师最终离开；
• 工具投资得以整合到 TypeScript 单体架构中；
• 创新资源重新投入到产品改进中，例如基于用户行为推荐内容的机器学习算法，以及让内容团队自助管理内容的后台界面。

一开始，有些人认为这会“降低乐趣”。但最终，它反而让团队有更多时间做真正有趣的工作：既能锻炼工程能力，又能帮助用户。

案例三：某海外出行平台——“我们运行自己的硬件”

诊断

当时，这家公司正处在快速地域扩张期。

其中一些地区缺乏稳定可用的云服务。

公司当时已经达到非常大的运营规模，拥有数万台服务器。因此，自主管理硬件如果能降低 20% 到 30% 的总体拥有成本，就具备显著经济价值。

同时，公司愿意承担无法使用某些云服务的代价。

方法

对应的方法是：

• 完全运行在自有专用机房硬件上；
• 不在云上存储数据或进行计算；
• 可以在云上做网络接入，例如 TLS 终止，类似接入点架构；
• 任何超出接入点范围的云实验，都需要 CTO 批准。

影响

这套战略带来了几个重要结果：

• 公司得以进入并留在一些依赖云服务的竞争对手难以持续运营的地区；
• 在特定市场中，公司能在较短时间内搭建本地数据中心，而不需要把其他地区数据托管到那里；
• 但这也带来了大量“自己造轮子”的工作，用来替代常见云工具。

这并不轻松，我也不一定推荐所有公司这么做。

但这正是战略的本质：人生就是权衡取舍。即使是好战略，也会带来不好的后果。

为什么这些工程战略有效？

这些战略之所以有效，主要有几个原因。

第一，许多有价值的特性，只有在广泛采用时才能获得。
例如，“我们运行自己的硬件”只有在全公司层面执行时才真正有意义。

第二，战略能把工具投资集中到更小的空间。
例如，“我们在单一代码库中运行单体应用”，让开发者工具投资可以高度集中。

第三，战略能减少冲突造成的能量损耗。
例如，“我们是一家产品工程公司”，减少了关于是否采用新技术的反复争论。

第四，战略能控制组织的创新预算。
所有案例都体现了这一点：战略决定了组织把创新资源花在哪里，也决定了不花在哪里。

第五，新员工，尤其是资深新员工，必须明确参与战略，而不是选择忽略它。
当战略被写清楚之后，每个人都必须与它互动。

这就是在整个组织内做出明确、一致的权衡取舍所带来的力量。

缺乏战略，也会体现战略的价值

除了正面案例，我们也很容易找到反面案例：缺乏战略，或者战略不一致，会造成巨大痛苦。

例如：

某海外社交新闻网站曾花费数年完成一次大版本迁移。整个代码库几乎完全重写，包括新数据库、新前端、新后端和新算法。虽然他们对挑战的分析并不糟糕，但采用的方法极不切实际。

某海外支付科技公司曾引入 Java，但评估标准不够清晰，花了数年才判断它是否真正有效。这源于对当前问题的错误诊断。

某海外出行平台曾在相互竞争的路线规划技术上投入巨资，导致内部摩擦不断。根源在于同时采用了互相冲突的方法，却没有达成一致解决方案。

我相信，你也能从自己的职业经历中想到类似例子。

工程战略无处不在，但书面战略很罕见

有趣的是，许多知名科技公司都有实际存在的工程战略，但它们并不一定积极地把这些战略写下来。

我逐渐相信三件事：

1. 大多数公司都有工程战略；
2. 组织对这些工程战略的理解往往并不一致；
3. 书面工程战略非常罕见。

这是本文第一个真正重要的结论：

只要把现有战略写下来，就已经解决了一半的工程战略危机。

接下来，我们来解决另一半。

书面工程战略更有力量

为什么书面战略优于隐性战略？原因有很多，但我认为以下几点尤其重要：

• 你可以获得相关反馈；
• 你可以更新战略；
• 你可以解释为什么更新它；
• 你可以澄清令人困惑的地方；
• 你可以表达必要的细微差别，而这些在口口相传的战略中几乎不可能做到；
• 它能让技术决策不再局限于少数架构师，而是扩展到更多人；
• 你可以要求不遵守战略的人承担责任；
• 新员工可以主动学习，而不是通过不断犯错来学习。

书面战略不是为了制造文档，而是为了让组织能够围绕同一组判断、取舍和行动方式协作。对于研发团队来说，这类战略如果能够和目标、需求、开发、测试、发布以及 Wiki 知识沉淀连接起来，就更容易从“共识文件”变成“落地动作”。像 PingCode 这样的智能化研发管理工具，可以帮助团队把工程战略拆解到研发全生命周期中，并通过工具链集成让相关数据持续流转，从而更清楚地看到战略是否真正改变了交付方式。

你可以主导工程战略

推动工程战略，主要有两种方式。

第一种是自上而下：如果 CTO 已经认同方向，你可以帮助推广和落地。

第二种是自下而上：即使你并不是 CTO，也可以通过设计文档和局部策略逐步推动战略形成。

自上而下推动工程战略

这种方法的核心在于：

如果你制定的战略符合 CTO 的真实意图，就很容易获得支持。

为此，你需要做到以下几点：

• 经常沟通，并花时间理解和调试对方反馈；
• 保持值得信赖的好奇心，让人们知道你会认真倾听，并努力理解他们的观点；
• 务实，而不是教条；
• 通过实际行动积累信任；
• 把战略包装成低风险实验，例如“我们先试三个月，然后重新评估”；
• 让 CTO 决定如何解决僵局。

如果你读到这里，脑子里最大的想法是：

“我的 CTO 肯定不会让我这么做。”

那么大概率有两种可能。

第一，你写出的战略并不符合 CTO 真正想要的方向。

第二，CTO 不愿或无法解决组织内部冲突。

第二种情况会更棘手，但你仍然可以尝试下一种方法。

自下而上推动工程战略

自下而上的方法，可以概括为“先写五个，再综合”。

具体做法是：

1. 撰写 5 份设计文档；
2. 将这 5 份设计文档综合成一个“局部战略”；
3. 重复这个过程 5 次，得到 5 个局部战略；
4. 将这 5 个局部战略再综合成一个总体工程战略。

这样，你就写出了一份非常扎实的工程战略。

这种方法确实需要较长时间，但我见过它多次奏效。

即使你当前的战略存在漏洞，把它提炼成一份明确的战略文件，也总会让修补这些漏洞变得更容易。

在这个过程中，战略形成往往不是单个文档的问题，而是多个团队围绕任务、会议、文档、目标和审批持续协作的问题。Worktile 这类通用项目协作系统，可以帮助跨职能团队把讨论、行动项、时间安排和审批流程集中起来，让自上而下或自下而上的战略推进都更容易形成稳定节奏。

总结：如何解决工程战略危机

本文讨论了以下几点：

• 工程战略 = 诚实诊断 + 务实方法；
• 工程战略很有用，它能提高开发速度，降低组织摩擦；
• 工程战略无处不在，只是很少被写下来；
• 书面战略比隐性战略更有力量；
• 即使你不是 CTO，也可以推动公司的工程战略发展。

解决工程战略危机的方法，令人失望地简单：

第一，把现有战略写下来。

第二，无论采用自上而下还是自下而上的方式，持续提升现有战略的质量。

这可能不是你在寻找“如何更具战略性地制定年度目标”时期待看到的答案。

但它确实有效。