紧急救火 vs. 战略规划

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

最近我向工程师们强调的一个观点，我认为广泛分享会很有价值。

在进行工程工作时，你会接到不同类型的任务。有些任务是紧急事务或短期工作，我们有时称之为"救火"，特别是当工作涉及紧急修复或立即需要的任务时。其他任务则具有战略性：你收集了用户需求信息，设计了解决方案，并有条不紊地推进。

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

紧急救火

当你在"救火"时，目标就是扑灭火焰。你基本上只想做最少的工作来解决问题，以便回归长期战略工作。你不应该为了救火而构建庞大复杂的永久性系统。紧急情况下应该进行"快速而粗糙"的工作——这并不意味着要做糟糕的工作，但不应围绕救火构建长期高维护的系统。

救火有不同类型：有时高管或其他团队提出紧急需求（必须在几周内完成）。你的目标应该是完成任务并回归战略工作。其他时候是真正的紧急情况（如系统中断），这时你只需修复问题，而不是做其他无关事项。系统中断时不该说"我们先写设计文档，下周请高级工程师评审"——任何救火场景都不适合应用长期软件设计的方法体系。

实例分析

假设高管对你说：“有客户下周要支付100万美元，但前提是我们必须提供显示服务器高负载性能的图表。“而你的系统甚至没有记录服务器负载的功能。

若以长期战略思维处理，你可能会说：“我们需要建立服务器负载追踪系统，详细规划存储方案、准确性保障、监控和测试流程，还要与用户体验设计师合作确保图表易读性。“但这无法在一周内完成，且可能是浪费时间——你根本不确定这类需求是否会重复出现。

正确的做法是：“明天我会编写基础负载测试脚本，部署记录负载日志的服务器版本，然后手动解析日志生成图表。“这才是解决问题的最小工作量。

但此方案存在风险：后来者可能误认为这是经过设计的长期负载追踪机制。这凸显了关键原则：绝不在救火期间做出长期决策或实施长期解决方案。你甚至应该有意撤销救火期间的工作（如删除日志行），避免他人误解。

该原则不仅适用于技术实现，也适用于组织变革或任何决策。例如系统中断期间不适合讨论未来预防措施或日常流程改进。

唯一安全的长期决策时机是"事后分析”——火情扑灭后理性复盘：“我们应该采取哪些战略工作防止类似问题？“或"从此事件中学到什么可改进工作方式？”

违反此原则会积累导致团队崩溃的混乱。如果公司政策和工作模式仅基于紧急决策，最终会显得疯狂并可能失败。

战略工作

与"救火"相对的是战略工作：你有明确目标，应用软件设计基本原则，确保长期思考，与团队协作创建可持续方案。

反之，若将救火方法应用于战略工作会导致灾难。如果每个项目都当作紧急任务"快速粗糙"完成（即使并非真紧急），最终会制造混乱——系统设计低劣会导致故障频发、维护困难，使你陷入不断救火的恶性循环。

将救火原则用于战略工作永远无法完成长期目标。如果一个工程组织长期无法完成事项，往往是因为他们总把一切当作火烧眉毛的急事。

战略工作需要经常表态：“我们理解需求，正在以正确方式构建解决方案，这需要合理时间（不是永远，但需要时间）。”

有时高管担心给工程师"足够时间"会导致懈怠。虽然确保公司产品交付是合理关切，但必须在鼓励按时交付与遵循长期软件开发流程间取得平衡。进行战略工作时，宁可稍微过度设计、过度评审（但非过度工程化或无故评审），不确定时应该偏向更严谨的方向。

平衡二者

只要遵循上述原则，团队（或个人）可以同时处理战略工作与救火任务（至少在同一周/月内）。诀窍是对救火做最小化处理，确保业务持续运转，火情扑灭后立即回归战略工作。

毕竟，如果做法正确，战略工作应该是对业务最重要的部分——经过调研确认长期能产生最大影响的事项。所以扑灭火焰后，请回归真正重要的长期工作。

评论节选
David Schachter：对于构建短期系统回答"我们能做这个吗？““有人关心这个吗？“的原型开发有何看法？
Max Kanat-Alexander：真正的原型应遵循"存活不超过两周并彻底丢弃"的规则。许多原型工具使之可行。超出此限制的通常不是原型，而是逃避软件设计实践或规划不完整的项目。