rfc 查看工具_使用技术RFC作为管理工具的6课-CSDN博客

rfc 查看工具

作为工程主管，我非常重视信任，并相信个人贡献者应参与架构和高级技术决策。我认为每一行代码都是代表其他人（包括您将来的自己）做出的决定，拥有一支快速成长的分布式团队会使技术决策尤其难以管理。

在构建拼车共享应用程序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角色的混合VP（全栈执行？）。在这种情况下，我使用RFC来了解在体系结构级别上做出的决策，并且我将批准（或委托批准）这些决策，而无需进行微观管理或指示如何解决问题。如果对企业的风险很高，例如在较大的重写/重构或向堆栈中添加工具的情况下，如果我看到学习机会处于可控风险中，那么我可以拒绝或批准提议。今天在伊丽莎白和克拉克（Elizabeth＆Clarke）就是这样，我周末在这里工作。

在Splice，我仅负责工程组织，并与我们的首席技术官Matt Aimonetti合作，后者负责我们的技术指导。作为高级领导，我们对在工程和技术各个层面上做出的决策负责。 RFC使Matt可以看到我们团队的成员如何通过技术指导进行思考，并允许他管理风险并在正确的级别参与技术决策，并可以在必要时进行更深入的研究或委托。他不需要经常将整个系统放在脑子里，这也很好。