RFC

Não é raro cometermos o erro de achar que algo é de conhecimento geral até você descobrir que não é. Gosto quando isso acontece porque a vida me joga na cara que o mundo é muito maior do que a bolha onde eu vivo. 😛 E foi isso que aconteceu com RFC e este é o motivo pelo qual decidi escrever sobre este assunto.

RFC significa Request for comments (pedido para comentários) e, no princípio, eram documentos técnicos utilizados pelo IETF ( Internet Engineering Task Force), IRTF (Internet Research Task Force ) e IAB (Internet Architecture Board) nas discussões de padrões de protocolos e políticas usados na ou pela internet. O primeiro documento RFC foi escrito em 1969. Você pode encontrar uma RFC que descreve este processo aqui.

Porém, o documento RFC deixou de ser algo específico para padronização de protocolos utilizados na internet e começou a fazer parte do dia a dia de empresas conhecidas como big techs ou startups. Estes documentos são utilizados para diversos tipos de discussões, desde técnicas, negócio e até processos.

E por que as empresas usam RFCs?

Tudo começa quando há um problema para resolver ou uma oportunidade para explorar. Normalmente, a pessoa ou grupo discutem entre si e com pessoas próximas para tomar uma decisão. Porém, nem sempre as pessoas próximas são as que mais podem contribuir porque estão todas dentro do mesmo escopo ou escopos próximos (squads ou tribo). E isso não permite que a decisão seja tomada com uma visão de todo ou identifiquem todos os impactos da mesma. E como alcançar estas pessoas? Como conseguir esta visão?

O documento RFC é uma excelente ferramenta para isso. O problema/oportunidade e a solução proposta são descritos num documento que é acessível à todos da cia, permitindo o compartilhamento com pessoas de diferentes squads, tribos, áreas e expertises. As pessoas colaboram deixando comentários no documento que podem ser perguntas, considerações, explicações sobre impactos e etc. Qualquer pessoa pode responder, fazer observações. Este “diálogo” fica registrado no documento permitindo que qualquer pessoa possa rapidamente entender a discussão.

Usando este documento, a pessoa ou grupo responsável pela RFC entra em contato com diferentes pontos de vista, considerando outras áreas da empresa como negócio ou atendimento, por exemplo. E isso proporciona uma maior qualidade na decisão pois conta com um conhecimento maior e mais abrangente. Mas é importante frisar que a pessoa ou grupo responsável continua sendo o responsável pela decisão. Os comentários e o processo ajudam a tomar a decisão, mas não transferem a responsabilidade para os colaboradores do documento.

Estrutura básica de uma RFC

A estrutura básica de RFC que eu costumo utilizar no meu dia-a-dia é composta por:

• Objetivo: Resume o assunto/contexto do documento. Eu costumo dizer que esta seção é o resumo em um “tweet” do que se trata o documento.
• Contexto ou Motivação: É a seção que explica o contexto ou a motivação que pede uma solução/decisão. Considerando o contexto do desenvolvimento de software, poderia ser a dor do cliente, do usuário por exemplo. Espera-se que a importância do problema/oportunidade seja descrita. Também pode entrar os benefícios que esta decisão pode trazer como impacto na satisfação do cliente ou ganho financeiro. Eu acho esta seção a mais desafiadora para pessoas engenheiras de software pois requer um certo distanciamento da parte técnica ou até mesmo da proposta de solução que temos em mente. Eu costumo dizer que mesmo as migrações de tecnologia ou infraestrutura tem um impacto no nosso usuário ou cliente.
• Proposta de solução: Este é o momento de apresentar a solução e explicar os impactos. Tanto a parte técnica, mas também processos ou procedimentos que possam estar envolvidos ou impactados pela proposta.
• Soluções alternativas: Esta seção nos obriga a pensar. Será que poderíamos resolver o problema de outra forma? Quais seriam as consequências de não fazer nada? Sim, não fazer nada é uma opção a ser considerada. As soluções alternativas são descritas junto com os motivos pelos quais elas não foram selecionadas como proposta de solução.
• Fora do escopo: Eu acredito que esclarecer o que não está no escopo ou que não será discutido é tão ou mais importantes do que o escopo em si. Dizer o que não será feito ou não será discutido ajuda a conduzir a discussão e também não deixar espaço para mal-entendidos.
• RACI: Tenho certeza que você ficou com vontade de me mandar uma cópia do manifesto ágil 😛 Mas calma, eu explico. Esta seção é super importante pois deixa claro quem é o responsável pela tomada de decisão, quem são os aprovadores, consultados e informados.

Além destas seções, adiciono no comecinho do documento os campos status e deadline. O primeiro se refere ao status da RFC. Eu costumo usar Draft (ainda não está pronta para receber comentários), Em revisão (está no período de colaboração através de comentários) e Fechada (a discussão foi encerrada e o documento não aceita mais comentários). Já o segundo, trata o fim do prazo para a tomada de decisão e permite que as pessoas entendam a urgência da decisão e se planejem para colaborar.

Muito mais que decisões de software/produto

Eu acredito que o processo de decisão usando RFC pode ser usado para qualquer decisão, inclusive decisões de gestão. Já usei RFCs para discutir estrutura de times, quais documentações seriam utilizadas e como seriam organizadas, Key Results, formato de daily, processo de atendimento à incidentes e entre outros. O uso da RFC nestes casos permitiu a contribuição do time todo para a decisão e isso tem vários impactos positivos: decisões de maior qualidade e mais democráticas, além de ter reforçado o sentimento de pertencimento das pessoas em relação aos times.

Por fim…

Eu sou uma grande fã do processo de tomada de decisão usando RFCs. A minha experiência com a aplicação deste documento me mostrou vários benefícios que vão além do aumento da qualidade das decisões tomadas. Vou escrever um texto só para contar estes benefícios. Eu recomendo o uso e acho que você deveria dar uma chance para RFC.