紧急救火与长期策略

最近我向工程师们强调了一个观点，认为广泛分享会很有价值。在工程工作中，你会接到不同类型的任务。有些任务是紧急或短期的，我们常称之为“救火”，尤其是当工作涉及紧急修复或立即需求时。

其他任务本质上是战略性的：你收集了用户需求信息，设计了解决方案，并系统智能地推进。

理解你正在处理哪种工作类型，并以不同方式思考它们，这很重要。

救火

当你救火时，目标是灭火。你基本上想做最少量工作来灭火，以便回归长期战略工作。你不应该围绕救火构建庞大、复杂的永久系统。紧急情况下，你应该做“快速而粗糙”的工作——这不意味着做糟糕的工作，但不应建立长期高维护的系统。

火情有多种。有时高管或其他团队带来紧急需求——必须在几周内完成。你应该想办法完成任务并摆脱它，以便回归战略工作。

其他时候，你有实际紧急情况，如中断。这时更清楚：只需修复中断，不做额外事情。中断不是写设计文档或下周与高级工程师评审的时候。任何火情都如此——不是应用长期软件设计方法的时机。

示例

举个具体例子。假设高管来说：“有客户想下周给我们一百万，但之前我们必须生成图表显示服务器高负载下的表现。”但假设你甚至没有记录服务器负载的系统。

如果以长期战略方式思考，你可能会说：“啊，我们应该有个系统跟踪服务器负载。必须详细设计存储、准确性、监控和测试。然后与用户体验设计师合作，通过用户研究确保图表易理解。”

但这无法在一周内完成，也是浪费时间。你实际上不知道火情是否会重现。仅因一次紧急需求，不代表这是长期需要。它可能看似是，你可以猜测是，但为什么猜测长期设计？无需猜测长期工作——做长期工作时，你有时间研究实际用户需求。所以基于研究构建，而非猜测。

相反，你应该说：“好吧，明天我会写个基本负载测试脚本手动运行。部署服务器新版本，只写负载信息到日志文件，然后手动解析日志制图。”所有这些都是解决问题的最小工作量。

但此方案有风险：你修改服务器记录负载相关日志。可能后来有人认为这是长期支持的机制，依赖它设计良好——但事实并非如此。这突显重要点：绝不在救火时做长期决策或实施长期解决方案。

事实上，你可能想故意撤销救火时的工作，如删除日志行，以免他人认为你做了长期决策。

此规则不仅适用于技术实现细节，也适用于组织变更或任何决策。例如，假设中断持续中，中断时不是讨论如何预防未来发生或改变日常流程的时候。

唯一安全基于火情做长期决策的时候是“事后分析”——火被扑灭后理性回顾情况。然后你可以坐下说：“好吧，我们想做什么战略工作预防此类火情？”或“我们学到了什么可改变工作方式？”

此规则极其重要。违反它会积累疯狂，摧毁团队。如果你仅基于极端紧急时的决策建立公司政策和工作模式，公司最终会显得完全疯狂，可能失败。

战略工作

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

类似地，如果你将“救火”方法应用于战略工作，会导致灾难。如果你将每个项目视为紧急情况，“快速而粗糙”地完成，因为“必须明天做完”（即使并非如此），你会搞成一团糟。实际会发生的是你制造火情！系统设计如此差劲，会崩溃、引发问题、难以维护，最终让你完全忙于救火。

当你将救火原则应用于战略工作，你永远无法完成战略工作。如果你看到工程组织似乎无法长期完成事情，这通常是原因——他们对待一切如世界着火，因此无法真正前进。

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

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

做两者

只要你应用上述一般原则，一个团队（或一个人）可以同时处理战略工作和火情（至少在同一周或月内）。技巧是在火情上做最小工作，确保紧急情况处理，业务继续运行，然后火灭后聚焦回战略工作。

毕竟，如果你做对了，战略工作应该是对业务最重要的东西——你研究过并知道长期交付会产生最大影响的事情。所以扑灭火情，回归做长期真正重要的事情。

-Max