灭火与战略

作者：Max Kanat-Alexander
发布日期：2020年3月15日

最近我向工程师们强调了一个观点，我认为如果更广泛地分享这个观点会很有价值。

当你从事工程工作时，会遇到不同类型的任务。有些任务是紧急情况或短期工作。我们有时称之为"灭火"，特别是当工作涉及处理紧急故障或需要立即完成的事情时。

其他任务本质上是战略性的。你收集了用户需求和期望的信息，设计了解决方案，并有条不紊、明智地朝着目标努力。

理解你正在从事哪种类型的工作，并以不同的方式思考它们，这一点非常重要。

灭火

当你"灭火"时，目标就是扑灭火焰。你基本上希望完成最小必要的工作来解决问题，以便能够回到长期战略工作中。你不希望为了灭火而构建庞大、复杂且将永久存在的系统。紧急情况是你应该进行"快速而粗糙"工作的时候。

这并不意味着你应该做糟糕的工作。但你不应该围绕灭火构建一些长期、高维护的系统。

有不同类型的"火灾"。有时高管或其他团队带着即时需求来找你——必须在接下来几周内完成的事情。你应该做的是找出如何完成这项任务并把它解决掉，以便能够回到长期战略工作中。

其他时候，你会遇到某种实际的紧急情况，比如服务中断。在这种情况下更清楚的是，你应该只是修复中断，而不是四处奔波做一堆其他事情。服务中断不是你说"好吧，让我们等待编写设计文档，下周与我们的高级工程师一起评审"的时候。任何"火灾"都是如此——火灾不是应用长期软件设计方法和系统的时候。

示例

让我们举一个更具体的例子来说明我的意思。假设一位高管来找你说：“我们有一个客户想在下周给我们一百万美元，但在此之前，我们必须制作一个图表，显示我们的服务器在高负载下的表现。“但是，假设你甚至没有任何记录服务器负载的系统。

如果你以长期、战略的方式思考这个问题，你可能会说：“啊，好吧，我们应该有一个跟踪服务器负载的系统。我们必须详细研究这个系统的存储如何工作，如何确保其准确性，如何监控它，以及如何测试它。然后我们应该与用户体验设计师合作，通过进行标准用户研究并从中制定UI设计，确保其生成的图表能够被用户很好地理解。”

这在一周内无法完成。而且，这是浪费时间。你实际上不知道这种"火灾"是否会再次发生。仅仅因为有人带着紧急需求来找你一次，并不意味着这将成为长期需求。它可能看起来会是这样，你可以猜测会是这样，但为什么要猜测长期战略设计呢？没有必要猜测长期工作——当你从事长期工作时，你有条件进行研究，找出实际的用户需求和需求。所以这样做，并基于此构建东西，而不是基于你的猜测。

相反，你应该说的是：“好的，我明天会制定一个非常基本的负载测试，可以从我机器上的脚本手动运行。我将推出一个新版本的服务器，只是将其负载信息写入日志文件，然后我将基于解析该日志手动制作一个图表。“所有这些基本上都是解决问题所需的最小工作。

然而，即使这个解决方案也带有风险——你配置了服务器来记录与负载相关的内容。有可能后来有人会认为你打算将其作为跟踪系统负载的长期、受支持的机制，并依赖它是经过良好设计和深思熟虑的，而实际上并不是。这突出了一个非常重要的观点：在灭火期间永远不要做出长期决策或实施长期解决方案。

事实上，你可能甚至想要有意撤销在灭火期间所做的所有工作，比如删除那个日志行，只是为了不让其他人认为你做出了某种长期决策。

这个规则不仅适用于技术实现细节，也适用于组织变更，或者实际上任何决策。例如，假设有一个持续的服务中断。在中断期间不是讨论如何防止它将来发生，或者你应该如何改变日常流程的时候。

基于"火灾"做出长期决策的唯一安全时机是当你进行"事后分析"时——在火灾被"扑灭"后对情况进行理性审查。然后你可以坐下来问：“好的，我们想要做什么样的战略工作来防止这样的火灾再次发生？“或者"我们从中学到了什么可以用来改变我们的工作方式？”

这个规则极其重要。违反它会积累疯狂，可能摧毁团队。如果你仅基于在极端紧急情况下做出的决策来构建公司的所有政策和工作模式，最终它看起来会是一个完全疯狂的公司，并可能失败。

战略工作

与"灭火"相对的另一端（这是一个频谱，不是非黑即白）是：做战略工作。基本上，你有一个已知的目标，并朝着它努力，应用所有软件设计的基本原则，确保你考虑长期，并与你的团队智能合作，创建可持续的东西。

类似地，如果你将"灭火"的方法和系统应用于战略工作，你将导致灾难。如果你将每个项目都视为紧急情况，只是因为"必须在明天完成”（即使实际上并非如此）而"快速而粗糙"地完成，你最终会得到一团糟。实际会发生的是你将创造火灾！你的系统设计如此糟糕，以至于它会崩溃，引起麻烦，难以维护，并最终完全消耗你在围绕这个设计糟糕的混乱中灭火。

当你将灭火的原则应用于战略工作时，你实际上永远无法完成战略工作。如果你看到一个工程组织似乎无法长期完成事情，这通常就是原因——他们一直把一切都当作世界着火了，因此永远无法真正前进。

战略工作需要经常说：“好的，我们理解你的需求。感谢你告诉我们你的问题。我们正在为你构建解决方案，我们正在以正确的方式做这件事，这需要一点时间。不是永远，但需要一些时间来完成。”

我认为有时高管们担心，如果他们告诉工程师"花足够的时间”，工程师会变得懒惰，永远无法完成工作。在一些公司中，这可能是合理的担忧，当然高管们有兴趣让事情继续推进，以便公司能够交付产品！但在鼓励人们按时交付和确保他们遵循长期软件开发流程和程序之间必须取得平衡。一般来说，在进行战略工作时，最好在做过多的设计、过多的评审等方面犯错。我不是说过度行事并停止构建东西，或者仅仅因为某事"可能需要"就让每个人都经历不必要的评审。我只是说，如果你不确定，这是你应该犯错的方向。

同时处理两者

只要你应用上述一般原则，一个团队（或一个人）就有可能同时处理战略工作和灭火（至少在同一周或同一个月内）。诀窍是在灭火上做最小的工作，确保紧急情况得到处理，业务继续推进，然后在火灾扑灭后重新专注于战略工作。

毕竟，如果你做得对，战略工作应该是对业务最重要的事情——你经过研究并知道如果交付它们将在长期产生最大影响的事情。所以扑灭火灾，回到长期实际上重要的事情上。

-Max