关于将技术 RFC 用作管理工具的 6 堂课

作为一名工程领导者，我重视信任，并认为个人贡献者应该参与架构和高层次的技术决策。我认为每一行代码都是代表他人（包括您未来的自己）做出的决定，而拥有一个快速增长的分布式团队使得技术决策管理起来尤其困难。

在构建共享出行应用 Ride 的早期，在最初的六个月里，我们的团队从三个人增长到超过 25 人，涵盖产品、设计和工程部门。我们的任务是将一个早期的 拼车平台原型 在 Web、iOS 和 Android 上实现。更具挑战性的是，我们还分布在美国、墨西哥、哥伦比亚、巴西、阿根廷和爱尔兰。

在构建我们的应用程序的过程中，我收到一位“不太高兴的前端工程师”的 Slack 私信，他问道

如果我们的前端技术栈是基于 Ember 的，为什么数据仪表板是用 React 构建的？

这让我很快意识到一些我不应该错过的要点

• 我不知道我们已经在技术栈中添加了一个新工具。
• 其他团队成员——本应知道这件事的人——也不知道。
• 有人代表我们整个团队做出了一个重要的决定，但团队并没有参与其中。
• 没有人，包括我自己，喜欢这个意外。

这种情况是流程失败的结果。鉴于流程是我（作为工程副总裁）所负责的，我也负责改进流程，以避免团队再次陷入这种情况。我们需要一种团队决策方式，该方式能够

• 使个人贡献者能够为他们负责的系统做出决策；
• 允许领域专家在他们不直接参与构建特定系统时对决策提供意见；
• 管理已做决策的风险；
• 让团队成员参与，而不会变成“委员会设计”；
• 为未来提供背景信息快照；
• 是异步的；以及
• 并行处理多个项目。

我们不是第一个遇到这个问题的人，所以我们研究了开源软件项目如何处理这些情况，并得出结论，采用征求意见稿 (RFC) 流程将有助于我们共同做出更好的决策。

RFC 流程在开源项目中被广泛使用，用于收集来自贡献者和其他利益相关者的反馈，它已成为我管理分布式工程团队最喜欢的工具之一。加入 Splice 后不久，我就实施了它，并在 Elizabeth & Clarke 也采用了它。我仍在学习它如何帮助我领导的组织做出决策。鉴于过去三年在生产环境中使用 RFC 的总体积极经验，我想分享一些实用经验，以防您想尝试一下。

1. 决定何时编写 RFC 很难。

考虑到决策的复杂性、对背景的了解程度、工程师专业知识的差异以及经常缺乏对主题的理解，确定何时编写 RFC 是整个过程中最具挑战性的问题。

一般来说，如果您在问，

“我应该为此编写 RFC 吗？”

答案可能就是，

“如果您需要问，您可能就应该编写。”

为了方便流程，我们制定了指南来决定何时编写 RFC 提案。

在以下情况下，您应该编写 RFC

• 从头开始构建某些东西（新的端点、组件、系统、库、应用程序等）；
• 脑海中闪过“重写”的想法；
• 怀疑某事会影响多个系统或其他团队成员；
• 想要定义客户端或系统之间的合同或接口；
• 正在添加新的依赖项；
• 正在技术栈中添加或替换语言或工具；或
• 想知道是否应该编写一个。

2. 包容性需要责任。

我发现，在团队中产生归属感的最好方法莫过于让人们参与决策。在工作中产生影响很重要，而其中一些影响是通过决策实现的。如果我们参与重要的决策，我们的工作就有可能更具影响力，这赋予了工作目标感。通过让团队成员有机会评论他人提出的决策，RFC 成为促进包容性的绝佳工具，并促成可以对工作产生影响的参与。

如果您想被包括在内，您必须参与。

我们的 RFC 实施建议提案保持开放以供评论至少两天，最多一周，但允许更短或更长时间，具体取决于具体情况。此外，工程师不是必须参与——但如果他们没有及时参与，他们就会失去被包括在内的机会。

RFC 减少了管理者听到令人恐惧的问题“为什么没有就 X 咨询我？”的次数。此外，当管理者可以参考文档时，如果个人贡献者 (IC) 没有注意到重要的决策（这些决策是他们职责的一部分），则可以对他们的绩效进行具体的反馈。

值得衡量的是 RFC 的参与率。低参与率（参与者/团队总人数）可能表明后台潜伏着一些问题。如果您看到参与率低，那么您的团队成员可能正在应对以下挑战

• 他们手头的事情太多。
• 他们不感兴趣。
• 用于流程管理的工具没有为他们提供良好的用户体验。
• 他们可能需要更好的个人时间管理。

我发现，如果您在一周内的固定间隔安排评审时段，并帮助成员围绕它组织自己，一些工程师会提高他们的参与度。

3. 信任问题变得更加明显。

做出能够转化为软件的技术决策，并体验这些决策的后果，是学习如何构建软件的重要途径。在某些情况下，团队成员可能会因为缺乏信任而阻止队友做出决策。我们发现 RFC 提高了系统中谁在做决策的可见性，这有助于管理者识别出信任问题正在阻止 IC 做出决策的情况。尽早发现信任问题对于维护团队中有效的协作非常重要。

4. 权力动态可以被管理。

使用 RFC 使我们能够为通常不会在技术决策中发挥主导作用的团队成员创造空间。鼓励管理者和高级 IC 任命不那么强势的成员作为 RFC 的作者。成为作者明确表明您是负责提案的人。这是一种明确授权您发挥主导作用的方式，而无需成为团队中最吵闹或最强势的成员。

拥有非强势成员参与的可见记录也让我能够评估管理者如何处理权力差异，这会对团队的整体幸福感产生影响。

5. 新手 标签能够实现心理安全。

资深开发人员不是凭空出现的，你必须给新人机会。

— ☠️Buriticá ☠️ (@buritica) 2014 年 7 月 25 日

为了具有包容性，工程流程设计应考虑具有不同经验水平的人员的意见，包括职业水平和技术深度。例如，我可能已经编写 JavaScript 多年了，但在 Go 方面没有太多背景。

作为一个团队，我们一致认为，任何标记为 [newbie] 的评论或提案都表明其作者来自一个脆弱的位置。无论是出于缺乏专业知识、背景还是信心，这个标签都允许我们犯错误，同时知道我们处于一个心理安全的环境中，这个环境支持资深和初级成员的学习。

6. 工程领导可以在适当的抽象级别参与。

在 Ride，我被期望运营工程组织并提供技术方向，担任工程副总裁/CTO 的混合角色（全栈高管？）。在这种情况下，我使用 RFC 来了解在架构级别做出的决策，并且我会批准（或委派批准）这些决策，而无需微观管理或指示如何解决问题。如果对业务的风险很高，例如在大型重写/重构或向技术栈添加工具的情况下，如果我能看到在可控风险下的学习机会，我可以拒绝或批准提案。这就是今天在 Elizabeth & Clarke 的运作方式，我在周末担任首席技术丈夫。

在 Splice，我只负责工程组织，并与我们的 CTO Matt Aimonetti 合作，他负责我们的技术方向。作为高级领导者，我们对所有级别工程和技术方面的决策负责。RFC 让 Matt 能够了解我们团队成员如何思考技术方向，并使他能够在适当的级别管理风险并参与技术决策，并可以选择在必要时深入研究或委派。他不必 постоянно 将整个系统记在脑海中，这也很不错。

RFC 是我的最爱

让团队成员（包括现在和未来）了解决策的原因和方式，使我能够运营更快乐、更高效的分布式工程组织。现在，当有人问我“这些人当时在想什么？”时，我不再试图敷衍地回答，而是指向可能解决所有疑问的文件，并让我的团队成员戴上软件历史学家的帽子。

本文最初发表在 Juan Pablo Buriticá 的博客 Juan's And Zeroes 上，经许可转载。