紧急救火 vs 战略开发

最近我向工程师们阐述的一个观点，我认为值得更广泛地分享。在进行工程工作时，你会遇到不同类型的任务。有些任务是紧急或短期工作，我们有时称之为"救火"，特别是当工作涉及处理紧急故障或刻不容缓的需求时。

其他任务则具有战略性质。你收集了用户需求信息，设计了解决方案，并有条不紊地朝着目标推进。

救火工作

当你在"救火"时，目标就是灭火。你基本上只想做最小必要的工作来解决问题，以便能回到长期战略工作。在紧急情况下，你应该做"快速而粗糙"的工作，但并不意味着要做糟糕的工作。

火情有多种类型。有时是高管或其他团队带着紧急需求来找你——必须在接下来几周内完成的事情。你要做的就是想办法完成这个任务，然后回到长期战略工作。

实际案例

假设一位高管来找你说："我们有个客户想在下周给我们一百万美元，但在此之前，我们必须提供一张图表显示我们的服务器在高负载下的表现。"但假设你甚至没有任何记录服务器负载的系统。

如果从长期战略角度思考，你可能会说："我们应该建立一个跟踪服务器负载的系统。需要详细设计存储方案、确保准确性、监控机制和测试方法。"但这不可能在一周内完成，而且可能是浪费时间。

相反，你应该说："明天我会编写一个可以从我机器上手动运行的基本负载测试脚本。我将部署一个服务器新版本，只将负载信息写入日志文件，然后基于解析该日志手动制作图表。"这就是解决问题所需的最小工作量。

战略工作

与"救火"相对的另一个极端是：做战略工作。基本上，你有一个明确的目标，并朝着它努力，应用所有基本的软件设计原则，确保考虑到长期影响，并与团队协作创建可持续的解决方案。

如果在战略工作中应用"救火"的方法，将会导致灾难。如果你把每个项目都当作紧急情况，因为"必须明天完成"而"快速粗糙"地完成，最终会一团糟。实际上你会制造更多火情！

两者兼顾

只要应用上述基本原则，一个团队（或个人）就有可能同时处理战略工作和救火任务（至少在同一周或月份内）。诀窍是在救火上做最小化工作，确保处理紧急情况使业务持续运转，然后在火被扑灭后重新专注于战略工作。

毕竟，如果你做得对，战略工作应该是业务最重要的部分——那些你经过研究知道长期来看会产生最大影响的事情。所以扑灭火情后，要回到真正长期重要的工作上。更多精彩内容 请关注我的个人公众号 公众号（办公 AI 智能小助手）公众号二维码

办公AI智能小助手