Pular para conteúdo

RFC-001: Processo de RFC com Reuniões Quinzenais

Campo Valor
Status Aprovada
Author Time de Tecnologia
Created 2026-01-15
Updated 2026-03-05
Reunião 2026-02-20
Deciders Todo o time técnico

Status

Valores possíveis:

  • 🟡 Draft: RFC em elaboração, ainda não apresentada
  • 🔵 Em Revisão: RFC apresentada e em discussão na reunião
  • ✅ Aprovada: RFC aprovada pelo time, pronta para implementação
  • ❌ Rejeitada: RFC rejeitada após discussão
  • 🟠 Deprecada: RFC anteriormente aprovada mas não mais válida

Contexto e Problema

Decisões técnicas importantes são tomadas de forma ad-hoc e informal, causando:

  • Falta de documentação: Não sabemos por que certas decisões foram tomadas
  • Ausência de discussão estruturada: Decisões importantes são tomadas em conversas de corredor
  • Falta de rastreamento: Não temos histórico de decisões passadas
  • Dificuldade de onboarding: Novos membros não entendem o contexto das decisões
  • Decisões isoladas: Nem todo time participa de discussões importantes
  • Retrabalho: Às vezes retomamos discussões já resolvidas

Por que resolver isso agora?

  • Time está crescendo e precisa de processos mais estruturados
  • Decisões arquiteturais importantes precisam de mais visibilidade
  • Necessidade de documentar o "porquê" além do "como"
  • Aprendizados precisam ser preservados e compartilhados

Impacto de não resolver

  • Continuar tomando decisões importantes sem registro adequado
  • Perder contexto histórico e aprendizados
  • Dificuldade em entender trade-offs de decisões passadas
  • Onboarding mais lento e menos efetivo

Proposta de Solução

Implementar processo de RFC (Request for Comments) com reuniões quinzenais para discussão e aprovação.

Componentes do Processo

1. Status das RFCs: - 🟡 Draft - Em elaboração - 🔵 Em Revisão - Apresentada e em discussão - ✅ Aprovada - Aprovada e pronta para implementação - ❌ Rejeitada - Rejeitada com justificativa - 🟠 Deprecada - Anteriormente aprovada mas não mais válida

2. Reuniões Quinzenais: - Calendário fixo: 1ª e 3ª sexta-feira do mês - Horário definido (ex: 14h-16h) - 20-30 minutos por RFC - Estrutura: Apresentação (10min) + Discussão (15min) + Decisão (5min)

3. Template Estruturado: - Contexto e problema - Proposta de solução - Alternativas consideradas (com prós/contras) - Análise de impacto - Plano de implementação - Métricas de sucesso

4. Processo Documentado: - Fluxo completo documentado - Checklists para autores e revisores - Templates de agenda e mensagens - Boas práticas e casos especiais

Níveis de RFC

  • Alto Impacto (30min): Arquitetura, novas tecnologias - requer aprovação de todo time
  • Padrão (20min): Padrões, processos - requer aprovação de 2+ pessoas
  • Informativa (10min): Documentação de decisões - apenas para conhecimento

Alternativas Consideradas

Opção 1: RFCs Assíncronas (sem reuniões)

Descrição: Apenas documentos escritos, decisões via comentários em PRs

Prós: - Mais flexível com agenda de cada um - Permite tempo para reflexão - Menos overhead de reuniões - Discussões podem ser mais profundas

Contras: - Discussões podem se arrastar indefinidamente - Falta de alinhamento em tempo real - Mais difícil chegar a consenso - Feedback pode ser superficial - Menos engajamento do time

Custo/Esforço: Baixo

Por que não escolhemos: Experiência de outras empresas mostra que RFCs assíncronas tendem a ficar estagnadas. Reunião garante decisão em prazo definido.

Opção 2: Reuniões Semanais

Descrição: Reuniões toda semana para discutir RFCs

Prós: - Decisões mais rápidas - Mais oportunidades para discussão - Menos backlog de RFCs

Contras: - Overhead grande para time pequeno - Reunião pode ficar sem conteúdo algumas semanas - Pressão para criar RFCs mesmo quando não necessário - Cansaço de reuniões

Custo/Esforço: Alto (tempo do time)

Por que não escolhemos: Time pequeno, reuniões semanais seriam overhead desnecessário. Quinzenal é equilíbrio melhor.

Opção 3: ADRs (Architecture Decision Records) apenas

Descrição: Documentos mais simples, sem processo formal de revisão

Prós: - Mais simples e leve - Menos burocracia - Foco em decisões arquiteturais

Contras: - Não garante discussão do time - Decisões podem ser feitas isoladamente - Menos estrutura para análise de alternativas - Não cobre decisões de processo

Custo/Esforço: Baixo

Por que não escolhemos: ADRs são bons para documentar, mas RFCs promovem discussão ativa. Queremos ambos: discussão + documentação.

Análise de Impacto

Impacto Técnico

Times afetados: - Todo time de desenvolvimento (precisa participar ou acompanhar RFCs)

Sistemas afetados: - Documentação (novo processo a ser seguido) - Todos

Dependências: - Criar templates e documentação - Agendar reuniões recorrentes - Treinar time no processo

Impacto em Negócio

  • ✅ Decisões técnicas mais bem fundamentadas
  • ✅ Menos retrabalho por decisões mal pensadas
  • ✅ Onboarding mais efetivo (histórico de decisões)
  • ✅ Conhecimento distribuído no time
  • ⚠️ Overhead de reuniões (2h/mês)
  • ⚠️ Decisões podem levar mais tempo (mas são melhores)

Riscos Identificados

Risco 1: Processo se tornar burocrático

  • Mitigação: Níveis de RFC (fast-track para decisões simples), revisar processo periodicamente
  • Impacto: Médio
  • Probabilidade: Média

Risco 2: RFCs se acumularem

  • Mitigação: Limite de RFCs por reunião (2-3), priorização clara
  • Impacto: Baixo
  • Probabilidade: Baixa

Risco 3: Time não engajar com processo

  • Mitigação: Demonstrar valor com primeiros exemplos, celebrar boas RFCs
  • Impacto: Alto
  • Probabilidade: Baixa

Plano de Implementação

Fase 1: Documentação (Semana 1)

Tasks: - [x] Criar documentação do processo (rfc/process.md) - [x] Criar template de RFC (rfc/template.md) - [x] Criar página index explicando RFCs (rfc/index.md) - [x] Documentar esta decisão como RFC-001

Responsável: Arthur Ferreira Prazo estimado: 3 dias

Fase 2: Setup (Semana 1-2)

Tasks: - [x] Agendar reuniões recorrentes (quinzenais) - [ ] Criar templates de agenda e mensagens

Responsável: Arthur Ferreira Prazo estimado: 1 dia

Fase 3: Primeira Reunião (Semana 2)

Tasks: - [x] Agendar primeira reunião RFC - [x] Apresentar RFC-001 (este processo) - [x] Coletar feedback sobre o processo - [x] Ajustar se necessário

Responsável: Arthur Ferreira
Prazo estimado: 2h (reunião)

Fase 4: Iteração (Mês 1-2)

Tasks: - [ ] Executar 2-3 ciclos de reuniões - [ ] Coletar feedback contínuo - [ ] Ajustar processo conforme aprendizados - [ ] Documentar casos especiais que surgirem

Responsável: Todo o time
Prazo estimado: Contínuo

Métricas de Sucesso

Após 1 mês

  • ✅ Ao menos 2 reuniões realizadas
  • ✅ Ao menos 3 RFCs discutidas
  • ✅ Time confortável com o formato
  • ✅ 100% de participação nas reuniões

Após 3 meses

  • ✅ Ao menos 8-10 RFCs documentadas
  • ✅ Decisões importantes passando pelo processo
  • ✅ Feedback positivo do time sobre o processo
  • ✅ Histórico de RFCs sendo consultado para referência
  • ✅ Onboarding usando RFCs como material

Após 6 meses

  • ✅ Processo se tornou natural para o time
  • ✅ Redução em decisões refeitas ou revertidas
  • ✅ Novos membros conseguem entender contexto através de RFCs
  • ✅ Time sugere melhorias no processo

Decisão da Reunião

Data da Reunião: 2026-02-20

Participantes:

  • Maria Alice Jovinski
  • Arthur Felipe da Silva Ferreira
  • Igor Santiago
  • Marcio Vignoli de Lima

Discussão Principal:

Arthur Felipe Da Silva Ferreira propôs um sistema centralizado de documentação de desenvolvimento de software com governança compartilhada via processos de Request for Comments (RFC), que combina o ciclo de desenvolvimento de software (SDLC) e um fluxo de status como draft e aprovado. Eles definiram as RFCs como o meio para formalizar propostas de mudanças arquiteturais e processuais, diferenciando-as de tarefas individuais e correções de bugs. A cadência de reuniões para discussão de RFCs será quinzenal com flexibilidade, e Arthur Felipe Da Silva Ferreira, juntamente com Igor Santiago (Santi), Marcio Vignoli de Lima, e Maria Alice Jovinski, discutiu a necessidade de endereçar a segurança e a privacidade da documentação pública, além de definir o fluxo de trabalho do Gitflow como o próximo tema de reunião.

Feedback Recebido:

  • Todos entenderam o modelo proposto e o feedback foi bem positivo.

Ações Requeridas :

  • Alterar o Status de RFCs para (Padrão , Alto impacto e Informativa)
  • Restringir o acesso ao sistema

Resultado: Aprovada

Referências