利用RFC进行透明的跨团队决策

利用RFC进行透明的跨团队决策

内源项目如果想实现高参与率，并为每个参与者做出最好的决定，就需要想办法在整个软件生命周期中建立易于参与式的环境。发布内部征求意见稿（RFC）文件，可以在设计过程的早期就进行讨论，并促进在参与各方在高参与度下建立解决方案的机会。

为了使内源项目健康发展，它持续需要大量的贡献者。这些贡献者（或团队）可能对给定的项目有不同的要求。例如，他们可能想在项目中添加彼此不兼容的功能，或导致架构的不健康的膨胀。

在过程的后期发现这种分歧或误解，例如，一旦软件已经建成，就会付出很大的代价。这些分歧可能会导致所有参与方的挫败感，甚至会破坏项目中合作文化的健康。常见的分歧是，一个变更请求（pull request）被搁置了很久，因为变更请求的作者和项目的维护者基本上都不同意进行拟议的变更。

对于内源项目来说，当项目由公司内的多个团队一同维护时，这种情况更经常发生，即共享所有权。

一个项目，或由多个项目组成的应用程序，由许多不同的团队维护，每个团队负责不同的项目或应用程序的不同领域。这些团队确实对彼此的领域做出了内源的贡献，但更大的、跨领域的变化只由团队的技术负责人共同推动，或者根本就没有发生。这导致大多数工程师无法实现大规模、跨领域的变革，减少了创新和合作的机会。

通过实施RFCs的流程和模板，团队和个人被授权通过一个透明的决策过程提出大型的、跨领域的变化，并在各团队之间进行异步磋商。这促进了更大的创新，更紧密的合作，以及更多的知识传播。这有赖于各层级的所有专家的认同，以及一个心理安全的环境，以便人们可以公开提出和辩论想法。

像任何过程一样，这必须被不断地改进。可能需要对RFC模板或流程进行修改，以确保其具有包容性、协作性和有效性。

我们选择了一个类似于RFC的程序来增加我们跨团队决策过程的透明度（也见请求评论）。

该方案的重要内容有：

实施类似于RFC的流程被证明是有价值的，因为它使跨团队的决策过程对每个人来说都更加透明，使所有的声音都能被听到。

可观察到的积极效果。

RFC方法也有我们想要指出的风险。

它并不总是有效的！例如，有些人可能仍然反对已经通过RFC做出的决定。然而，在这些情况下，将决策过程写成文字仍然是有益的，因为你可以指出人们是在什么时候和为什么做出某个决定的。
将设计方案（架构、协议等）写在前面，有一种瀑布式的设计元素，不适合许多开发团队喜欢的迭代式开发方法。记住："工作的软件胜过全面的文档"（敏捷宣言）。RFC过程应该尽可能的轻巧。
一个RFC可能会变得很大，太不方便了。这往往表现在冗长的评论和围绕RFC的讨论。在这种情况下，我们可能会决定用同步交流的方式来补充RFC，比如工作小组和面对面的会议。但时间仍然可以节省，因为人们可以在会议之前阅读RFC，而不是在会议期间分享所有的信息。

多年来，RFC在开源世界中证明了自己。对于互联网整体而言，RFC在制定标准方面发挥了重要作用（例如，见30 Years of RFCs），对于其他开源项目也是如此，它们采用这种方法来促进社区的透明决策（例如，RUST，ZeroMQ）。

在内源的背景下，其他公司也分享了他们在类似RFC方法方面的经验，例如Uber和Europace。

对于纯粹的软件设计决策之外的决策，透明的决策模型也是有效的，例如在努力实现开放组织的时候。一个例子见Red Hat的Open Decision Framework（2016年6月7日公开发布）。

BBC iPlayer & Sounds - 如2020年ISC秋季峰会利用内部RFCs加强合作所述。
Europace - 如在开放组织中所述。在开放中设置跨团队的标准和最佳实践。
Uber - 根据Gergely Orosz的这篇博文：通过RFCs扩展工程团队：将事情写下来。
Google Design Docs - 根据Malte Ubl的博文Google的Design Docs的描述。
DAZN (10/2021) - DAZN做出技术决定的一种方式是通过RFCs。RFCs仅用于适用于工程范围内流程的决定！RFCs存在于GitHub中。RFCs存在于GitHub仓库中，然后技术标准逐渐被他们的工具和工程师所采用。一个RFC可以由任何工程师提出，并由所有工程师投票表决。如果支持率超过反对率，RFC就会被采纳。值得注意的是，RFC的投票过程至今没有因为任何争议的决定引发"压力测试"。- 正如Lou Bichard在这篇博文中所描述的：建立一个DX团队：经验教训

结构化

最后更新于8个月前