通过 RFC 扩展工程团队

Uber 从几十人到数千人的过程中一直使用的规划流程：在构建之前写 RFC，发给全公司所有人评审。

Key Takeaways

1. 五个步骤：
2. 构建之前先做规划（白板或团队讨论）
3. 把规划写下来（简短文档即可）
4. 找几个人批准，类似代码审查的质量门
5. 发给全公司的工程师，邀请任何人评论（这正是听起来疯狂的那一步）
6. 迭代轻量级的 RFC 流程，让它在你的组织里跑起来
7. 写作的力量：写下来 = accountability（责任归属）+ 更周全的决策
8. 文化塑造：把规划文档推送给所有人，本身就是一种信任与责任的信号
9. 天然的自平衡：跨团队透明让自我纠错自然发生——印度团队看到美国团队的设计，指出本地化的漏洞
10. 模板演进：随着公司成熟，模板自然演化，加入可靠性、安全、可访问性等关注点

与 Google Design Docs 的对比

维度	Google Design Docs	Uber RFCs
范围	单个系统/功能的设计	任何超过简单复杂度的项目
分发	设计评审会议	全公司邮件，人人可评论
持续	生命周期 4 阶段	与 Uber 的规模一起迭代
关键差异	更正式的结构	更强调透明度和开放性

Related

• [[wiki/summaries/design-docs-at-google|Design Docs at Google]] — 同一种思想的不同实现
• [[wiki/concepts/rfc-vs-design-doc|RFC vs Design Doc]] — 对比分析
• [[wiki/concepts/writing-as-leverage|写作作为杠杆]] — RFC 是写作能力在组织级的最高体现