你经常会看到一些杂乱无章的想法被贴上“战略”的标签。即使这些文档内容很多也往往很难读懂。这也是为什么很多工程师会说他们所在的公司没有清晰战略。不过根据我的经验所有公司其实都在遵循某种战略只是这种战略未必被明确写成文档。对于工程管理者和技术负责人来说真正的挑战不是“有没有战略”而是如何用结构化方法制定一套清晰、可信、可执行的工程战略。本章将介绍一种可重复、结构化的工程战略制定方法。它会概览这套方法中的每个步骤而这些步骤也会在后续章节中进一步展开。本章将讨论以下内容这五个步骤如何相互配合帮助你制定工程战略尤其是如何防止实践者跳过那些令人尴尬、困难或不熟悉的步骤。第一步探索。也就是研究整个行业围绕你当前战略问题所形成的理念和实践。探索的目的是了解哪些最新研究可能改变你的方法以及自你上一次处理类似问题以来相关技术和实践已经发生了哪些变化。第二步诊断。也就是理解问题的具体细节。在尝试解决问题之前人们往往很难放慢脚步真正弄清问题是什么。但如果没有清晰诊断几乎不可能把事情做好。第三步完善。也就是对一组未经验证的原始想法进行现实检验。为了支持这一验证过程本章会引入三种方法战略测试、系统建模和沃德利地图。第四步制定方针。也就是通过权衡取舍和做出决策来回应诊断结果。这些决策覆盖范围很广可能涉及软件架构设计也可能涉及拉取请求的评审方式还可能涉及组织内部的人力分配。第五步运营。也就是将方针转化为组织内部实际行动的具体机制。这些机制可以是提醒你注意某些缺少相应测试的代码变更也可以是每周召开一次会议用来讨论迁移工作的推进情况。这些步骤究竟是不可动摇的还是可以灵活调整和试验的当你个人觉得某些步骤无效时是否仍然应该坚持尝试本章也会讨论这些问题。读完本章后你将对工程战略制定的每个步骤形成整体认识并可以决定接下来想深入阅读哪一部分。本文是《制定工程战略》中的一个章节。工程战略制定的五个步骤如何汇聚成战略制定有效战略并不是机械背诵某个公式。你不能仅仅因为遵循了这些步骤就保证一定能制定出优秀战略。然而我一直发现战略失败更多时候并不是因为根本性的思维缺陷而是因为一些本可以避免的错误。忙碌的人往往会跳过某些步骤尤其是那些他们不喜欢、觉得尴尬或者过去曾经失败过的步骤。这些步骤的价值就在于帮助你减少这类错误。通过定期练习你会逐渐养成良好的战略思考习惯并培养出判断当前战略最适合采用哪种方法的能力。它们也有助于把战略制定变成一种共同实践让你、你的同事以及更广泛的工程生态都能参与其中。每一步都是下一步的输入。探索是做出可靠诊断的基础。诊断能帮助你从广阔的方针空间中找到当前真正需要解决的问题。运营机制则能帮助你把方针转化为支持战略的积极力量而不是让它停留在抽象理论层面。如果你对这些步骤持怀疑态度当然可以保持怀疑。但在完全放弃之前不妨先尝试几次。你或许也会从战略制定中关于“理论与实践如何结合”的相关章节中获得启发。第一步探索工程战略的问题空间探索是指在决定采用某种战略之前有意识地研究该战略所处的问题空间和解决方案空间。它包括了解其他公司和团队如何处理类似问题以及他们的方法是否适用于你当前的情况。它也包括理解为什么你在上一家公司取得巨大成功的方法未必就是当前组织的最佳解决方案。海外某出行平台公司的服务迁移战略就采用了探索式方法。它通过阅读行业文献来理解服务生态系统作为起点我们发现阅读关于海外某大型科技公司大规模集群管理实践的论文以及关于数据中心细粒度资源共享的论文很有帮助。前者为后来一些容器编排方法提供了思路后者则描述了另一类资源调度和服务编排方法。该战略还使用沃德利地图来探索云计算生态系统。2014 年服务编排的演进。更多详情请阅读“探索”章节。第二步诊断工程战略需要解决的问题诊断是指在制定应对方针之前努力准确识别战略需要解决的具体情境。从探索中获得的经验以及你对当前情况的理解会共同构成诊断的基础。诊断过程会迫使你推迟思考解决方案直到你真正理解问题的细微差别。诊断可以在很大程度上依赖数据。例如在制定私募股权所有权过渡战略时诊断中可能会写道今年我们的工程人员成本同比增长了 15%去年同比增长了 18%。人员数量分别增长了 7% 和 9%。人员数量增长与人员成本增长之间的差异主要来自以下几个方面薪酬等级调整4%、重点招聘高级岗位3%以及在高成本地区增加招聘1%。诊断也可以较少依赖数据而更多用于总结问题。例如某次收购整合战略在交易完成前总结了技术整合中的已知信息和未知信息为了按时实现目标我们需要迅速整合被收购的初创公司。目前我们对具体整合过程了解甚少。我们只知道销售点终端会直接处理支付信息。例如销售点终端知道它读取到的信用卡信息。我们的合规义务要求此类活动只能在“令牌化环境”内进行。这是一个高度安全且隔离的环境可以直接访问支付详情。该环境会将支付详情转换为唯一令牌其他环境可以使用该令牌对支付详情进行操作而不必承担直接访问底层支付详情所带来的合规成本。在真实的工程管理场景中诊断质量也取决于研发过程数据是否完整、连续、可追溯。比如 PingCode这类智能化研发管理工具可以覆盖从团队目标、客户反馈、需求评审、项目开发、测试发布到 Wiki 知识沉淀的全生命周期帮助团队把分散在研发链路中的信息连接起来让战略诊断更容易建立在真实数据之上而不是只依赖访谈和经验判断。“诊断”章节会详细介绍诊断方法以及诊断过程中常见的挑战。第三步完善工程战略包括测试、地图和模型战略完善是一套方法工具箱用来识别诊断中哪些部分最重要并验证你解决诊断问题的方法是否真正有效。本章将深入探讨三种方法的具体应用战略测试、系统建模和沃德利地图。用户、负载均衡器和服务器之间的请求成功与失败情况。系统建模图示例。这些技术也体现在若干战略案例研究中例如 LLM 生态系统的沃德利地图或者用于说明如何在不降低岗位级别的情况下填补岗位空缺的系统模型。更多详情请阅读“完善”章节。为什么战略完善不能更早或更晚进行一个常见分歧是有人认为完善战略应该发生在诊断之前。另一个分歧是绘制地图和建模应该拆分成两个不同步骤。绘制地图应该发生在诊断之前而建模应该发生在方针制定之后。第三种观点则认为完善应该是战略制定的最后一步从而让整个过程形成一个循环。这些观点都有合理之处所以我想详细说明一下为什么我会采用当前这种结构。对于大多数战略而言最大的风险并不是建模太早或者绘制地图太晚而是这两个步骤被完全跳过。我最关心的是如何尽可能降低绘制地图和建模所需的投入门槛让更多人能够完成这些步骤。在探索和诊断之后进行完善可以让你把精力集中在少数几个真正关键的区域。当然在制定战略的过程中对某些部分进行多次调整是很常见的。你可能需要进行三次小调整也可能需要进行一次大调整。第四步制定工程战略方针制定方针是将诊断结果转化为具体计划。这个计划还必须切实可行。因此你既需要仔细研究公司内部已经证明有效的方法也需要结合探索当前问题时发现的新思路。方针的范围可以很广。它可以是方向性的指导例如用户数据访问控制战略中的这段指导良好的安全讨论不会把决策框定为安全性和可用性之间的二选一。我们会寻求多维度权衡以同时提升安全性和效率。如果讨论被局限在安全性与实用性之间那就说明我们的讨论方向错了我们应该重新思考方法。我们将优先考虑那些能够自动授权并自动记录客户数据访问理由的机制。最明显的例子是对于已经分配给某位客服人员的未解决工单系统会自动授予这位客服人员访问权限并在工单被重新分配或解决后撤销该访问权限。方针也可以是承诺暂时不做某个决定。比如在某次收购整合战略中就做出了这样的安排关于是否引入 Java 的决定将推迟到以后再做。引入 Java 与我们现有的工程战略并不兼容但目前我们尚未能与各利益相关方就如何解决这个问题达成一致。此外我们认为试图在当前阶段解决这个问题会分散我们按时实现六个月内推出联合产品这一目标的注意力。我们将在首发版本发布后再展开相关讨论。本章会进一步探讨如何评估方针、如何处理难以确定方法的模糊情况以及如何制定新的方针。详情请阅读“方针”章节。第五步让工程战略运营落地即使是最好的方针也需要被解释和执行。方针制定者不可能预料到所有新情况。而且即使这些制定者早已离开组织方针仍然可能继续生效。运营机制就是让方针真正落地执行的具体方式。最简单的机制是明确的升级路径。海外某冥想应用公司的产品工程战略中就包含了这样的规定例外情况需经首席技术官批准并且必须以书面形式记录。上述方针有意设计得较为严格。有时这些规定可能并不完全适用于现实情况我们会酌情做出例外处理。然而每一项例外都必须经过深思熟虑并基于我们共同关注的具体问题包括我们想要解决什么问题以及打算如何解决这些问题。如果我们各自为政朝着各自偏好的解决方案努力那么我们不仅无法成为推动产品发展的引擎反而会给公司带来负面影响。从这个起点出发机制可能会变得复杂得多。本章将探讨如何评估机制、如何制定行动计划以及我在各种战略中见过的最常见行动机制类型。对于需要把战略拆解到日常协作中的团队Worktile 这类通用项目协作系统也可以作为运营机制的一部分用任务、项目、文档、目标、日历、甘特图、工时和审批等能力承载具体行动让战略不只停留在文档里而是进入团队每天的协作流程。更多详情请阅读“运营”章节。工程战略制定结构是否不可更改当有人苦于撰写战略文件时人们最先推荐的工具之一往往是战略模板。模板当然很有用。它们能把原本范围宽泛、难以把握的项目简化成更容易操作的结构。如果你还在犹豫是否应该用模板来制定战略那么我的建议是当然可以大胆尝试。然而我也发现许多初衷良好、设计周全的模板最终却会变成笨拙、生硬、毫无用处的文档对任何人都没有好处。优秀模板的秘诀在于必须有人负责维护它。而且这个人首先必须关心模板撰写者自身的需求而不是那些想在战略制定过程中不断加入要求的各方利益相关者。计划的安全性、合规性和成本当然重要。但许多组织会开始在这类文档中堆砌越来越多的要求最终让撰写战略文件本身变成一件极其痛苦的事情。对于那些正在尝试撰写战略的人我能给出的最佳建议是只要你能解释清楚某个要素原本想解决什么问题就可以舍弃所有阻碍你继续前进的要素。例如如果你在起草战略时找不到任何合适的运营机制没关系可以直接删掉那一部分。归根结底战略的结构并不是不可动摇的。真正重要的是各部分背后的思考。