工程战略 (Engineering Strategy)
原始链接: https://staffeng.com/guides/engineering-strategy
我觉得写工程战略挺难的，因为好的战略通常很枯燥，写起来也无聊。而且人们一听到“战略”，往往会联想到“创新”。 —— Camille Fournier
很少有公司真正理解工程战略和愿景，这就导致大家普遍觉得这些文档极难撰写，甚至觉得它们高深莫测。但实际上，好的工程战略不过是一份平淡无奇的日常文档，而且写一份管用的战略比写一份烂战略更容易。
简单来说： 写 5 份设计文档，提炼出它们的共性，这就是你的工程战略。 写 5 份工程战略，预测它们在未来两年的影响，这就是你的工程愿景。
如果你脑子里总冒出各种“绝妙的点子”，可以先建个草稿，把这些点子全写下来，然后直接删掉，以后再也别提。清空大脑，咱们来做真正的工作。
持久好用的工程战略和愿景，是组织自下而上不断迭代学习的产物。即使你不是直接负责人，你也可以采取实际行动，从现在开始推动你们组织的战略和愿景。
何时写，为什么写？
战略的目的是帮助团队“提前对齐”，让团队能快速且自信地推进工作，避免在决策上浪费几周时间。它们也能帮你缩小未来的不确定性，让你能写出切合实际的愿景。
- 如果你发现你们把同一个问题反复讨论了三四次，就说明该写战略了。
- 如果未来太模糊，导致你们不知道哪些投资是值得的，就说明该写愿景了。
- 如果你没有遇到这两个问题——那就先去忙别的工作，以后再说。
第一步：写 5 份设计文档
设计文档（有些公司叫 RFC 或技术说明，比如 Uber 统一使用 RFC 作为标准）记录了具体项目中的决策和权衡。一份好的设计文档会描述具体问题、罗列可选方案，并解释选中方案的细节。参考模板有：Design Docs, Markdown, and Git、Google 的设计文档、以及远程文化中的技术决策与对齐。
什么项目需要写设计文档？
- 该项目的功能将被未来多个项目使用。
- 项目会对用户产生重大影响。
- 项目开发时间超过一个月。
收集 5 份设计文档是写出好战略的最佳素材，因为它们包含了烂战略最缺乏的东西：基于现实的详细细节。工程师面对空泛的战略很容易产生不同理解，但在落实具体方案时，是很难“假装达成一致”的。
撰写建议：
- 从问题出发： 问题越清晰，方案就越明显。卡壳时，把现有内容给 5 个人看看，局外人总能一针见血。
- 模板要简单： 不要用承载太多目标的复杂模板，那会让人不想动笔。保持最简，只对风险最高的项目要求事无巨细。
- 集体讨论，独立撰写： 多听取相关人员（尤其是下游依赖方）的意见，但文档最好由一个人主笔。把一群人的想法揉成一篇清晰的文章很难，指定一个人写清楚要容易得多。
- 完成比完美更重要： 写出一份好文档并让大家看到，比为了追求完美而拖延要强。在评审别人的设计时，也不要用你心目中的最高标准去苛求对方。
第二步：将 5 份设计文档提炼成战略
凑齐 5 份设计文档后，一起通读它们。寻找那些在多个文档中反复出现且难以达成共识的争议性决策（比如：Redis 到底该做持久化存储还是只做缓存？）。把这些决策和背后的原因记录下来，就成了战略。
好的战略指导权衡，并给出解释；坏的战略只给规定不给原因，一旦脱离当时的背景就会让人一头雾水。推荐阅读：负责任的创新框架 和 Slack 是如何进行重大技术变革的。推荐书籍：《好战略，坏战略》。
撰写建议：
- 立足当下直接写： 别因为信息不全就停滞不前（信息缺失总是有原因的）。直接开始写，如果写得很烂，你很快就会知道需要修改哪里。
- 写具体细节： 一旦你发现自己开始写大话、空话了，就停笔。如果写不出具体内容，说明你需要先去写更多的设计文档。具体才能带来共识，空泛只会带来共识的错觉。
- 要有明确观点： 没有立场的战略无法指导决策。
- 展示推导过程： 就像做数学题要写步骤一样，你要写出观点背后的逻辑。这不仅能建立信任，也方便以后情况变化时别人对战略进行调整。
有些战略写出来可能觉得像废话，比如“何时该写设计文档？”、“单体架构如何迁移到微服务？”——别管那么多，都值得写。战略不是为了炫耀聪明才智，写得随意一点没关系，没用的话以后作废就行。
第三步：将 5 份战略推演成愿景
随着战略变多，它们之间可能会冲突。比如一个战略说要少运行软件（多用云服务），另一个战略说要把复杂度下放到数据库。如果云服务商不提供你想要的复杂数据库，你怎么选？
拿出你最近的 5 份战略，推演它们在未来两三年内会如何演变。解决其中的矛盾，把它们串联起来，这就成了工程愿景。最终版本会给你带来 Tanya Reilly 所说的 对未来的坚定信念。
撰写建议：
- 展望未来两三年： 变化太快，看太远没意义；看太近（比如半年）又不够写出多少战略。2-3 年正合适。
- 扎根业务和用户： 有效的愿景必须服务于用户和业务，这样才能和高层的价值观保持一致。千万别为了证明技术先进而搞技术。
- 乐观，但不异想天开： 描绘一个“所有项目都按时顺利完成”的美好未来，但不要假设你拥有无限的资源。
- 具体且实在： 越具体越有用。用具体的细节来描绘未来的“风味”，而不是做死板的承诺。
- 控制在 1 到 2 页： 太长没人看。保持精简，把补充信息通过链接引向其他文档。
当你把愿景分享给整个工程团队时，大家的反响通常会很平淡，不要因此气馁。因为愿景的受众主要是那些写战略的人，而且好的愿景通常看着非常“理所当然”，理所当然到有些无聊。
衡量愿景好坏的标准，不是看它最初能激起多大的热情，而是拿两年前的设计文档和上周的设计文档做对比，如果质量有明显提升，那你的愿景就是成功的。
下一篇: 管理技术质量 (Manage technical quality)
上一篇: 做重要的事情 (Work on what matters)
书籍推荐
如果你喜欢 staffeng.com 上的故事和指南，你可能也会喜欢 《Staff Engineer: Leadership beyond the management track》，本书收录了许多类似的指南和故事。
