完成战略探索之后，下一步就是进行战略诊断。所谓战略诊断，是指理解这项工程战略必须面对的限制条件、现实约束和关键挑战。尤其重要的是，在充分理解问题的细节、背景和边界之前，不要急着寻找解决方案。

如果你很想跳过诊断阶段，直接进入方案设计，那么你也许需要先意识到一点：我见过的所有失败战略，几乎都源于诊断过于草率，或诊断本身并不准确。只要诊断正确，战略失败的概率就会大幅降低；而如果诊断错误，战略几乎不可能成功。

简单来说，战略诊断的核心价值在于：先判断问题是什么，再决定应该如何解决问题。对于工程管理者、技术负责人和参与战略制定的人来说，这是制定有效工程战略的基础。

本章将讨论以下内容：

为什么诊断是有效工程战略的基础，以及有效的指导方针如何依赖准确诊断；反过来，跳过诊断又如何导致战略失败。

如何逐步诊断你的战略环境。

如何有效地将数据纳入诊断，以及在补充数据时应该重点关注哪些方面。

如何处理诊断中存在争议的部分，例如承认自身执行能力也是需要解决的挑战之一。

为什么把困难视为需要解决的问题，而不是阻碍前进的障碍，会更有成效。

为什么缺乏谦逊和自省，几乎不可能做出有效诊断。

下面进入正文。

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

为什么诊断是工程战略的基础

评估战略的一大难点在于：事后看来，许多有效战略往往显而易见，甚至显得平淡无奇。同样，大多数无效战略的缺陷也会显得非常明显，以至于让制定者看起来像是没有认真思考。

这是因为，随着战略推进，其背后的现实会逐渐变得清晰。在制定战略时，你也许并不确定自己能否说服同事采用新的 API 规范方法；但一年之后，你通常就能非常明确地知道，这件事到底是否可行。

构建战略诊断，就是在制定应对方案和指导方针之前，准确识别战略必须解决的背景问题。如果诊断做得好，后续撰写战略的步骤往往会变得顺理成章。也正因如此，我认为战略诊断是工程战略的基础。

探索阶段并不要求你做出评估，而诊断阶段则完全围绕评估展开：团队目前的真实状态如何？那个项目为什么失败？上一版战略为什么没有达到预期？为了让新战略成功，我们必须克服哪些干扰因素？

不过，并非所有评估都同样有效。如果你只是直接给出自己的判断，很容易遭到反驳。而有效的诊断并不容易被轻易推翻，因为它由相互关联的观察、事实和数据构成。即使有人不同意你的结论，也很难忽视证据本身的分量。

战略测试——详见“完善”部分——正是利用了这样一个事实：实践比推测更容易暴露问题。它提出了一种递归式的诊断过程，通过不断检验和修正，直到获得战略确实有效的实践证据。

如何进行战略诊断

如果不从有效诊断开始，你的战略几乎注定会失败。但“如何进行诊断”却常常被忽视。

原因在于，对大多数人来说，诊断确实像是一门神秘的艺术：缺乏明确方法，缺少充分讨论，也很难被完全掌控。我自己也曾犯过这样的错误。在《工程主管入门指南》中，关于战略的章节就完全没有说明如何进行诊断。

当然，说诊断过程往往是自然演进、有机形成的，而不是严格结构化、机械化的，这种说法并非没有道理。不过，随着经验积累，我逐渐形成了一套相对结构化的方法：

首先，进行头脑风暴。从一张白纸开始，写下你对当前战略环境中各种影响因素的最佳理解。写完后，先把这张纸放到一边。

然后，在一张新纸上总结你的探索过程。回顾此前的探索内容，提取那些与你当前情况相似、并且能够引发共鸣的诊断。这既包括内部因素，也包括外部因素。对于每一项诊断，都标注它是完全适用，还是需要结合当前情况进行调整。完成后，再把这张纸放到一边。

接着，拿出另一张空白纸，刻意挖掘不同观点。去和那些很可能不同意你最初想法的利益相关者和同事交流。你的目标不是认同他们的反馈，而是理解他们如何看待这个问题。

Richard Rumelt 在《关键》中也采用了类似方法来构建诊断，并强调“测试、调整和改变框架或视角”的重要性。

随后，将各种观点整合成一个内在一致的视角。有时，你收集到的不同观点并不完全兼容。它们可能对问题的根本原因存在明显分歧，这在平台团队与产品工程团队之间尤其常见。你的目标，是在诊断中充分呈现每一种观点，即使其中有些观点你并不认同。这样，在后续评估方案时，你才能根据每种观点来检验自己的方法。

整合反馈不佳时，通常会出现两类问题。

第一类问题是，作者的个人立场过于鲜明，反而让读者对诊断产生怀疑。你的目标并不是赞同每一种观点；同样，你的分析也不应该把某一种观点奉为唯一正确答案。读者应该能够看到不同观点的存在，而不会明显感受到作者的偏见。

第二类常见问题是，一个团队试图共同完成综合分析，结果却造成了观点分裂，而不是形成统一判断。我的经验是，由一位作者负责代表所有观点，通常最能避免这两类问题。

完成初步诊断后，你需要从不同角度测试草稿。找那些你预计会强烈反对的人坐下来讨论。反复修改，直到他们承认你已经准确捕捉到了他们的观点。

他们可能仍然不同意某些判断，但他们应该能够承认：确实有人持有这些观点。他们也可能认为，你提供的数据无法完整反映他们的处境。遇到这种情况，你可以补充说明：相关团队认为这些数据并不完整。

在初步诊断阶段，不必过度追求细节上的完美。你的目标，是找到一些关键信息，为下一阶段——战略完善——做好准备。与其追求绝对精确，不如先确保方向正确，这样才能快速覆盖更广的范围。过早纠结于细节，往往会让你过早陷入单一视角。

到这里，你大概已经能够预料到我会如何总结这套战略制定方法：如果你觉得这些步骤过于机械，请根据自己的情况进行调整，让它们变得更自然、更顺手。毕竟，理解复杂问题并不存在完美方法。

不过，如果你感到迷茫，或者对自己过往经验并不完全有信心，我仍然建议你以上述方法作为起点。

如何将数据纳入战略诊断

海外某技术团队在创建一款 Ruby 类型检查工具时，其背后的诊断分析就包含了一系列数据，用来帮助读者理解他们的判断。例如，这份分析涵盖了相关团队的人员配置情况，以及 Ruby 代码库的测试覆盖率。

如果每个人都拥有相同的数据，并且对这些数据未来可能如何变化持有相同假设，那么评估战略就会简单得多。

数据也是你支持或质疑不同观点的工具。撰写诊断时，你会收集到许多相互竞争的看法；对于公正的读者来说，数据通常比情绪更有说服力。如果你确信某个观点正确，就提供数据来支持它。如果你认为另一个观点被夸大了，就提供足够的数据，让读者能够得出同样的结论。

在工程战略场景中，数据通常分散在目标、需求、项目、开发、测试、发布和知识沉淀等多个环节，因此诊断本身也依赖这些信息能否被持续记录和串联。比如，PingCode 这类智能化研发管理工具，能够将研发过程中的目标、反馈、需求、项目进展、测试发布和知识经验连接起来，让战略诊断不只依赖访谈和直觉，也能建立在更完整的研发过程数据之上。

提供数据分析时，最好同时附上完整数据的链接，而不是让读者在阅读过程中自行解读零散数据。随着战略文件传播，读者难免会要求查看不同版本的数据，以理解你的思路。提供原始数据链接，可以有效减少这类反复沟通。

如果你需要的大部分数据目前都不存在，也不必意外。这在战略工作中相当常见：如果能够轻松支持决策的数据早已存在，你大概率早就做出决定了，也就不需要再进行结构化思考。

下一章关于战略完善的内容，将介绍一些在数据不足的环境中建立信心的工具。

如何处理战略诊断中有争议的部分

我曾经任职的一家公司推行过一个类似海外某些大型科技公司“招聘把关人”制度的流程，要求所有新员工都必须经过团队外部面试官的审核。我当时花了不少时间反对增加这个环节，因为我不明白我们这样做的目的是什么。更让我惊讶的是，管理层似乎并不关心这个新流程是否真的能提升绩效。

直到很久以后，我才意识到：大多数高层领导其实并不信任他们的一位同事。他们推出“提高标准”计划的唯一目的，是在首席技术官不愿追究这位领导责任的情况下，建立一种机制来约束这位经理的招聘标准。

我还了解到，这些领导并不怎么关心这项政策的执行情况，导致“提高标准”计划中的失败案例经常被忽视。不过，这部分内容会在“战略运营”章节中讨论。

这是一个很好的例子：有些战略只有在完整诊断的基础上才说得通；如果没有完整诊断，它们就显得意义不明。而问题在于，诊断中的某些部分几乎不可能被公开说出来。即使是高层领导，通常也不能写一份文件，直白地说：“产品工程总监是一位糟糕的招聘经理。”

在制定战略时，你经常会发现自己必须在两个棘手选项之间做选择：

要么说出一些关于公司或某位员工的尴尬事实；

要么在诊断中遗漏一个关键部分，而这个部分对于理解整体思路至关重要。

每当遇到这类争议，我的建议都是：想办法把诊断结果纳入考量，但要把它重新表述成更容易被接受的说法，避免把问题过度狭隘地归咎于某个人。

举几个具体例子会更清楚。首先是一个私募股权投资场景，其诊断可能包括：

按照惯例，我们新的私募股权所有者很可能会要求我们通过裁员来降低研发人员成本。不过，目前我们还没有任何具体细节，无法据此做出结构化决策；而且，我们采取的方法也会随着裁员规模不同而大幅变化。

制定这项战略的人，可能对现状有很多情绪。首先，他们或许对新的私募股权所有权可能导致同事被裁员感到不满。其次，他们也可能对缺乏明确行动计划感到沮丧，因为他们不得不为各种可能结果提前准备。

无论他们内心如何感受，他们都坚持陈述事实。

第二个例子，可以看看海外某出行平台公司的服务迁移战略：

在基础设施工程部门，目前有一个由四名工程师组成的团队负责服务部署。虽然我们组织的增长速度与产品工程部门相近，但新增人员并没有直接分配给服务部署团队。我们预计这种情况不会改变。

这个团队并不是认为人员不应该增加；他们只是承认，这是自己必须面对的现实。他们把这一点作为事实陈述出来，并没有附加多余解释。

在这两个例子中，作者都以专业、克制、不带偏见的方式承认了他们正在解决的问题。也许他们原本希望负责这些决策的领导者能够明确承担责任，但如果他们在战略文件中直接这样写，反而会削弱战略工作的成效。

如果诊断中遗漏关键信息，你的战略就会变得难以评估、难以复制，也难以复盘。为了让战略真正有效，你必须把那些关键信息表达出来，只是要用更委婉、更得体的方式。

一如既往，战略更多取决于现实，而不是理想。

将障碍重新定义为战略诊断的一部分

当我与职业生涯早期的领导者讨论战略时，经常听到一种观点：一旦发现某个重大问题，就意味着战略制定已经无从谈起。例如，他们可能会认为，在目前这家公司里，由于高管团队朝令夕改，根本无法开展战略工作。

这个核心洞见很可能是正确的。但如果把它重新表述为一种诊断，就会更有力量：

如果我们无法迅速找到展示具体进展的方法，并以此激励管理团队，那么我们的战略很可能会失败。

这样一来，原本阻碍战略实施的因素，就被转化成了战略必须解决的问题。

每当你发现某个因素使你的战略似乎不太可能奏效，或者让整项战略看起来难以实施时，你其实找到了诊断中的一个重要环节。并不存在什么让战略绝对无法成功的理由；真正存在的，是你尚未识别出的诊断。

例如，在海外某公司为工程驱动型项目分配资源时，我们知道，公司非正式的优先级排序方式不会改变。即使我们说服产品管理部门的同事改变计划方式，仍然会受到高管团队非正式规划方式的影响，而这种方式也不会改变。

这些因素并没有阻碍我们实施战略。相反，它们帮助我们更清楚地认识到，什么样的方法才可能真正奏效。对于更偏通用协作的团队，也可以借助 Worktile 这类项目协作系统，把目标、任务、文档、日历、甘特图和审批等信息统一承载起来，让管理团队更容易看到持续进展，而不是只在阶段性汇报中被动接收结论。

自我意识在战略诊断中的作用

今天的每一个问题，都或多或少源于过去的决策。如果你已经在公司工作了一段时间，这意味着你很可能直接或间接地对诊断中应当指出的部分问题负有责任。

因此，能够认识到自己过去的行为如何影响当前诊断，是自我认知能力的重要体现。这也说明，下一步战略能否成功，取决于你是否能够清醒看待自己过去的选择。

不要害怕承认过去工作的失败。

在没有新数据的情况下改变主意，是混乱领导的表现；而基于新数据改变主意，则是深思熟虑的领导方式。

小结：做好战略诊断，才能制定有效工程战略

因为诊断是制定有效战略的基础，所以我一直认为，它是战略制定过程中最令人畏惧的阶段。虽然这种畏惧在某种程度上不可避免，但我希望本章内容能让你在面对这一挑战时更有准备。

最重要的是记住以下四点：

在决定如何解决问题之前，先完成诊断。

务必努力捕捉那些你最初并不认同的观点。

尽可能用数据补充直觉。

同时也要接受这样一个事实：有时候，你会缺少充分理解问题所需的全部数据。