我参加过一些工程会议，会上有人说：“我们应该只做快速版本，”或者“我们需要用正确的方式构建这个，不走捷径。”两种说法听起来都合理。两者往往都是错的。问题不在于人们不知道权衡的存在，而在于他们不知道自己权衡的是什么。
不理解权衡的实际内容，就无法做出好的权衡。
你将不断面临的权衡
如果你管理着一个数据团队，你会不断面临这些决策：
- 速度与准确性。 快速的近似答案与较慢的精确答案。你是运行一个快速近似计算，还是等待三个小时获取精确计数？
- 成本与性能。 昂贵的基础设施与有时较慢但更便宜的系统。你是始终为峰值负载配置资源，还是接受在流量激增时有2%的请求会超时？
- 灵活性与简单性。 通用解决方案与针对性解决方案……
- 技术债务与快速交付。 为了快速上线而接受不完美的代码，与投入时间进行重构以保持长期可维护性。
- 新工具与技术栈 vs 现有技能与稳定性。 采用可能更高效但团队不熟悉的新技术，与使用已知的、可能效率稍低但更稳定的现有工具。
一个五问题决策框架
为了更系统地应对这些权衡，我提出了一个包含五个问题的框架。在做出重大技术决策之前，团队应该共同回答这些问题：
- 我们试图解决的核心问题是什么？ （明确问题定义，避免解决方案追逐问题。）
- 每个选项的直接成本（时间、金钱）和间接成本（维护负担、学习曲线）是多少？
- 每个选项的短期收益（下周可以交付什么？）和长期影响（一年后这个系统会是什么样子？）是什么？
- 这个决策的可逆性如何？ （我们以后改变主意有多容易？这通常决定了你是应该快速实验还是深思熟虑。）
- 如果我们什么都不做（或者推迟决定），会发生什么？ （这有助于评估紧迫性与风险。）
应用框架：一个实例
假设你的团队需要决定是为一个临时数据分析项目构建一个一次性脚本，还是投资构建一个可重用的数据管道。
- 核心问题： 快速支持一个一次性的业务报告需求，但类似的需求在未来几个月可能会重复出现。
- 成本： 一次性脚本（低成本，开发时间短）；可重用管道（高初始成本，需要设计、测试和文档）。
- 收益： 一次性脚本（短期快速满足需求）；可重用管道（长期节省时间，提高未来请求的处理速度和质量）。
- 可逆性： 从脚本开始，以后再构建管道是相对可逆的（虽然会有些浪费）。从一开始就构建管道则更不可逆（投入了大量前期工作）。
- 不作为的后果： 推迟构建管道意味着未来每个类似请求都需要手动工作，累积的技术债务会增加。
基于这个分析，团队可能会决定从一次性脚本开始（因为可逆性高，且能立即满足需求），但在路线图中规划可重用管道（因为长期收益明显，且不作为的长期成本高）。这是一个基于分析而非感觉的决策。
结论
技术决策不应是信仰的飞跃或个人偏好的较量。通过采用一个结构化的框架来审视权衡——明确问题、评估成本与收益、考虑可逆性、审视不作为的后果——团队可以将讨论从“我感觉我们应该……”转向“基于以下分析，我们建议……”。这不仅能产生更好的技术成果，也能培养更协作、更以数据驱动的工程文化。停止凭感觉做决策，开始基于明确的利弊分析做决策。