完成战略探索之后下一步就是进行战略诊断。所谓战略诊断是指理解这项工程战略必须面对的限制条件、现实约束和关键挑战。尤其重要的是在充分理解问题的细节、背景和边界之前不要急着寻找解决方案。如果你很想跳过诊断阶段直接进入方案设计那么你也许需要先意识到一点我见过的所有失败战略几乎都源于诊断过于草率或诊断本身并不准确。只要诊断正确战略失败的概率就会大幅降低而如果诊断错误战略几乎不可能成功。简单来说战略诊断的核心价值在于先判断问题是什么再决定应该如何解决问题。对于工程管理者、技术负责人和参与战略制定的人来说这是制定有效工程战略的基础。​本章将讨论以下内容为什么诊断是有效工程战略的基础以及有效的指导方针如何依赖准确诊断反过来跳过诊断又如何导致战略失败。如何逐步诊断你的战略环境。如何有效地将数据纳入诊断以及在补充数据时应该重点关注哪些方面。如何处理诊断中存在争议的部分例如承认自身执行能力也是需要解决的挑战之一。为什么把困难视为需要解决的问题而不是阻碍前进的障碍会更有成效。为什么缺乏谦逊和自省几乎不可能做出有效诊断。下面进入正文。本文是《制定工程战略》中的一个章节。为什么诊断是工程战略的基础评估战略的一大难点在于事后看来许多有效战略往往显而易见甚至显得平淡无奇。同样大多数无效战略的缺陷也会显得非常明显以至于让制定者看起来像是没有认真思考。这是因为随着战略推进其背后的现实会逐渐变得清晰。在制定战略时你也许并不确定自己能否说服同事采用新的 API 规范方法但一年之后你通常就能非常明确地知道这件事到底是否可行。构建战略诊断就是在制定应对方案和指导方针之前准确识别战略必须解决的背景问题。如果诊断做得好后续撰写战略的步骤往往会变得顺理成章。也正因如此我认为战略诊断是工程战略的基础。探索阶段并不要求你做出评估而诊断阶段则完全围绕评估展开团队目前的真实状态如何那个项目为什么失败上一版战略为什么没有达到预期为了让新战略成功我们必须克服哪些干扰因素不过并非所有评估都同样有效。如果你只是直接给出自己的判断很容易遭到反驳。而有效的诊断并不容易被轻易推翻因为它由相互关联的观察、事实和数据构成。即使有人不同意你的结论也很难忽视证据本身的分量。战略测试——详见“完善”部分——正是利用了这样一个事实实践比推测更容易暴露问题。它提出了一种递归式的诊断过程通过不断检验和修正直到获得战略确实有效的实践证据。如何进行战略诊断如果不从有效诊断开始你的战略几乎注定会失败。但“如何进行诊断”却常常被忽视。原因在于对大多数人来说诊断确实像是一门神秘的艺术缺乏明确方法缺少充分讨论也很难被完全掌控。我自己也曾犯过这样的错误。在《工程主管入门指南》中关于战略的章节就完全没有说明如何进行诊断。当然说诊断过程往往是自然演进、有机形成的而不是严格结构化、机械化的这种说法并非没有道理。不过随着经验积累我逐渐形成了一套相对结构化的方法首先进行头脑风暴。从一张白纸开始写下你对当前战略环境中各种影响因素的最佳理解。写完后先把这张纸放到一边。然后在一张新纸上总结你的探索过程。回顾此前的探索内容提取那些与你当前情况相似、并且能够引发共鸣的诊断。这既包括内部因素也包括外部因素。对于每一项诊断都标注它是完全适用还是需要结合当前情况进行调整。完成后再把这张纸放到一边。接着拿出另一张空白纸刻意挖掘不同观点。去和那些很可能不同意你最初想法的利益相关者和同事交流。你的目标不是认同他们的反馈而是理解他们如何看待这个问题。Richard Rumelt 在《关键》中也采用了类似方法来构建诊断并强调“测试、调整和改变框架或视角”的重要性。随后将各种观点整合成一个内在一致的视角。有时你收集到的不同观点并不完全兼容。它们可能对问题的根本原因存在明显分歧这在平台团队与产品工程团队之间尤其常见。你的目标是在诊断中充分呈现每一种观点即使其中有些观点你并不认同。这样在后续评估方案时你才能根据每种观点来检验自己的方法。整合反馈不佳时通常会出现两类问题。第一类问题是作者的个人立场过于鲜明反而让读者对诊断产生怀疑。你的目标并不是赞同每一种观点同样你的分析也不应该把某一种观点奉为唯一正确答案。读者应该能够看到不同观点的存在而不会明显感受到作者的偏见。第二类常见问题是一个团队试图共同完成综合分析结果却造成了观点分裂而不是形成统一判断。我的经验是由一位作者负责代表所有观点通常最能避免这两类问题。完成初步诊断后你需要从不同角度测试草稿。找那些你预计会强烈反对的人坐下来讨论。反复修改直到他们承认你已经准确捕捉到了他们的观点。他们可能仍然不同意某些判断但他们应该能够承认确实有人持有这些观点。他们也可能认为你提供的数据无法完整反映他们的处境。遇到这种情况你可以补充说明相关团队认为这些数据并不完整。在初步诊断阶段不必过度追求细节上的完美。你的目标是找到一些关键信息为下一阶段——战略完善——做好准备。与其追求绝对精确不如先确保方向正确这样才能快速覆盖更广的范围。过早纠结于细节往往会让你过早陷入单一视角。到这里你大概已经能够预料到我会如何总结这套战略制定方法如果你觉得这些步骤过于机械请根据自己的情况进行调整让它们变得更自然、更顺手。毕竟理解复杂问题并不存在完美方法。不过如果你感到迷茫或者对自己过往经验并不完全有信心我仍然建议你以上述方法作为起点。如何将数据纳入战略诊断海外某技术团队在创建一款 Ruby 类型检查工具时其背后的诊断分析就包含了一系列数据用来帮助读者理解他们的判断。例如这份分析涵盖了相关团队的人员配置情况以及 Ruby 代码库的测试覆盖率。如果每个人都拥有相同的数据并且对这些数据未来可能如何变化持有相同假设那么评估战略就会简单得多。数据也是你支持或质疑不同观点的工具。撰写诊断时你会收集到许多相互竞争的看法对于公正的读者来说数据通常比情绪更有说服力。如果你确信某个观点正确就提供数据来支持它。如果你认为另一个观点被夸大了就提供足够的数据让读者能够得出同样的结论。在工程战略场景中数据通常分散在目标、需求、项目、开发、测试、发布和知识沉淀等多个环节因此诊断本身也依赖这些信息能否被持续记录和串联。比如PingCode这类智能化研发管理工具能够将研发过程中的目标、反馈、需求、项目进展、测试发布和知识经验连接起来让战略诊断不只依赖访谈和直觉也能建立在更完整的研发过程数据之上。提供数据分析时最好同时附上完整数据的链接而不是让读者在阅读过程中自行解读零散数据。随着战略文件传播读者难免会要求查看不同版本的数据以理解你的思路。提供原始数据链接可以有效减少这类反复沟通。如果你需要的大部分数据目前都不存在也不必意外。这在战略工作中相当常见如果能够轻松支持决策的数据早已存在你大概率早就做出决定了也就不需要再进行结构化思考。下一章关于战略完善的内容将介绍一些在数据不足的环境中建立信心的工具。如何处理战略诊断中有争议的部分我曾经任职的一家公司推行过一个类似海外某些大型科技公司“招聘把关人”制度的流程要求所有新员工都必须经过团队外部面试官的审核。我当时花了不少时间反对增加这个环节因为我不明白我们这样做的目的是什么。更让我惊讶的是管理层似乎并不关心这个新流程是否真的能提升绩效。直到很久以后我才意识到大多数高层领导其实并不信任他们的一位同事。他们推出“提高标准”计划的唯一目的是在首席技术官不愿追究这位领导责任的情况下建立一种机制来约束这位经理的招聘标准。我还了解到这些领导并不怎么关心这项政策的执行情况导致“提高标准”计划中的失败案例经常被忽视。不过这部分内容会在“战略运营”章节中讨论。这是一个很好的例子有些战略只有在完整诊断的基础上才说得通如果没有完整诊断它们就显得意义不明。而问题在于诊断中的某些部分几乎不可能被公开说出来。即使是高层领导通常也不能写一份文件直白地说“产品工程总监是一位糟糕的招聘经理。”在制定战略时你经常会发现自己必须在两个棘手选项之间做选择要么说出一些关于公司或某位员工的尴尬事实要么在诊断中遗漏一个关键部分而这个部分对于理解整体思路至关重要。每当遇到这类争议我的建议都是想办法把诊断结果纳入考量但要把它重新表述成更容易被接受的说法避免把问题过度狭隘地归咎于某个人。举几个具体例子会更清楚。首先是一个私募股权投资场景其诊断可能包括按照惯例我们新的私募股权所有者很可能会要求我们通过裁员来降低研发人员成本。不过目前我们还没有任何具体细节无法据此做出结构化决策而且我们采取的方法也会随着裁员规模不同而大幅变化。制定这项战略的人可能对现状有很多情绪。首先他们或许对新的私募股权所有权可能导致同事被裁员感到不满。其次他们也可能对缺乏明确行动计划感到沮丧因为他们不得不为各种可能结果提前准备。无论他们内心如何感受他们都坚持陈述事实。第二个例子可以看看海外某出行平台公司的服务迁移战略在基础设施工程部门目前有一个由四名工程师组成的团队负责服务部署。虽然我们组织的增长速度与产品工程部门相近但新增人员并没有直接分配给服务部署团队。我们预计这种情况不会改变。这个团队并不是认为人员不应该增加他们只是承认这是自己必须面对的现实。他们把这一点作为事实陈述出来并没有附加多余解释。在这两个例子中作者都以专业、克制、不带偏见的方式承认了他们正在解决的问题。也许他们原本希望负责这些决策的领导者能够明确承担责任但如果他们在战略文件中直接这样写反而会削弱战略工作的成效。如果诊断中遗漏关键信息你的战略就会变得难以评估、难以复制也难以复盘。为了让战略真正有效你必须把那些关键信息表达出来只是要用更委婉、更得体的方式。一如既往战略更多取决于现实而不是理想。将障碍重新定义为战略诊断的一部分当我与职业生涯早期的领导者讨论战略时经常听到一种观点一旦发现某个重大问题就意味着战略制定已经无从谈起。例如他们可能会认为在目前这家公司里由于高管团队朝令夕改根本无法开展战略工作。这个核心洞见很可能是正确的。但如果把它重新表述为一种诊断就会更有力量如果我们无法迅速找到展示具体进展的方法并以此激励管理团队那么我们的战略很可能会失败。这样一来原本阻碍战略实施的因素就被转化成了战略必须解决的问题。每当你发现某个因素使你的战略似乎不太可能奏效或者让整项战略看起来难以实施时你其实找到了诊断中的一个重要环节。并不存在什么让战略绝对无法成功的理由真正存在的是你尚未识别出的诊断。例如在海外某公司为工程驱动型项目分配资源时我们知道公司非正式的优先级排序方式不会改变。即使我们说服产品管理部门的同事改变计划方式仍然会受到高管团队非正式规划方式的影响而这种方式也不会改变。这些因素并没有阻碍我们实施战略。相反它们帮助我们更清楚地认识到什么样的方法才可能真正奏效。对于更偏通用协作的团队也可以借助 Worktile 这类项目协作系统把目标、任务、文档、日历、甘特图和审批等信息统一承载起来让管理团队更容易看到持续进展而不是只在阶段性汇报中被动接收结论。自我意识在战略诊断中的作用今天的每一个问题都或多或少源于过去的决策。如果你已经在公司工作了一段时间这意味着你很可能直接或间接地对诊断中应当指出的部分问题负有责任。因此能够认识到自己过去的行为如何影响当前诊断是自我认知能力的重要体现。这也说明下一步战略能否成功取决于你是否能够清醒看待自己过去的选择。不要害怕承认过去工作的失败。在没有新数据的情况下改变主意是混乱领导的表现而基于新数据改变主意则是深思熟虑的领导方式。小结做好战略诊断才能制定有效工程战略因为诊断是制定有效战略的基础所以我一直认为它是战略制定过程中最令人畏惧的阶段。虽然这种畏惧在某种程度上不可避免但我希望本章内容能让你在面对这一挑战时更有准备。最重要的是记住以下四点在决定如何解决问题之前先完成诊断。务必努力捕捉那些你最初并不认同的观点。尽可能用数据补充直觉。同时也要接受这样一个事实有时候你会缺少充分理解问题所需的全部数据。