Existe um novo 80/20 do desenvolvimento de software (RFCs) que quase ninguém trata com a seriedade que merece. Não estou falando de burocracia, documento bonito ou ritual de processo para agradar gestor. Estou falando de um mecanismo simples que reduz retrabalho, desalinha menos o time e transforma discussão solta em decisão operacional.
Quando um time cresce, o gargalo deixa de ser só código. Vira clareza. Vira decisão. Vira o custo invisível de mudar de direção no meio da sprint porque ninguém explicitou contexto, trade-off e critério de sucesso antes de implementar. Se você quer sair de execução reativa para construção previsível, RFC bem feita entrega uma alavanca desproporcional.
O melhor código não compensa uma decisão mal formulada; RFC existe para impedir que erro de pensamento vire débito técnico.
Por que RFC virou o novo 80/20 no desenvolvimento de software
Em muito time técnico, a maior parte do caos não nasce de incapacidade de programar. Nasce de decisões implícitas. Alguém assume uma arquitetura, outro interpreta um requisito de outro jeito, o comercial promete algo que o produto ainda não definiu e a engenharia descobre tarde demais que estava construindo em cima de premissas erradas.
É aqui que RFC entra como alavanca de alto impacto. Um documento curto, objetivo e discutido antes da implementação captura o que quase sempre fica perdido em call, mensagem ou na cabeça de quem lidera. O ganho não é teórico. Você corta retrabalho, reduz debate circular e melhora a qualidade das decisões sem depender de memória ou carisma.
O ponto brutalmente honesto é este: time sem RFC normalmente acredita que está ganhando velocidade. Na prática, só está empurrando ambiguidade para frente. E ambiguidade adiada volta mais cara, porque volta em produção, volta em bug, volta em refactor e volta em conflito entre áreas.
Quando eu falo em 80/20, é exatamente isso. Uma fração pequena de esforço na fase de definição evita uma parcela enorme de desperdício na fase de execução. Não é glamour. É infraestrutura de pensamento aplicada ao software.
Como RFCs de software reduzem retrabalho antes da primeira linha de código
O valor real de uma RFC não está em documentar o passado. Está em forçar precisão antes do commit inicial. O documento obriga o autor a escrever problema, objetivo, contexto, restrições, alternativas consideradas, risco e critério de sucesso. Isso parece básico, mas quase nenhum time faz isso de forma consistente.
Quando você escreve uma RFC de verdade, descobre rápido onde a ideia ainda está fraca. Às vezes o problema está mal definido. Às vezes a solução proposta já nasce enviesada por preferência técnica. Às vezes o suposto requisito de negócio não passa de opinião mal testada. Escrever revela buracos que falar costuma esconder.
Existe também um efeito importante de assincronia. Em vez de depender de uma reunião com dez pessoas improvisando opinião em tempo real, a RFC permite revisão crítica com mais qualidade. Cada pessoa lê, comenta e contesta com contexto. Isso melhora a decisão e diminui o ruído político típico de discussões ao vivo.
O resultado é menos retrabalho estrutural. Não aquele retrabalho inevitável de produto vivo, mas o retrabalho idiota: API redesenhada por requisito que ninguém alinhou, fila escolhida sem discutir volume, feature lançada sem definição clara de sucesso. RFC não elimina erro. Elimina erro previsível.
Estrutura de RFC para desenvolvimento: o mínimo que já muda o jogo
Você não precisa transformar RFC em tese acadêmica. Na verdade, quando o documento cresce demais, ele começa a falhar no objetivo principal, que é acelerar decisão. O formato mais útil é o que cria clareza suficiente para o time decidir sem transformar cada mudança em cerimônia.
Uma boa estrutura de RFC costuma incluir alguns blocos fixos: problema, objetivo, contexto, proposta, alternativas rejeitadas, riscos, impacto técnico e critério de sucesso. Esse conjunto já resolve grande parte do desalinhamento. O segredo não está no template em si, mas na disciplina de não pular as partes desconfortáveis.
Se a proposta parece boa só porque ninguém precisou explicitar trade-off, ela ainda não está pronta. Se o texto não deixa claro por que essa abordagem venceu outras, o time vai rediscutir tudo no meio da execução. E se não existe critério de sucesso, ninguém saberá depois se aquilo funcionou ou apenas foi entregue.
- Defina. Escreva o problema em uma frase objetiva antes de propor qualquer solução.
- Compare. Liste pelo menos duas alternativas reais e explique por que foram descartadas.
- Nomeie. Explicite riscos técnicos, operacionais e de negócio sem tentar parecer confiante demais.
- Meça. Determine o que vai indicar sucesso ou fracasso após a implementação.
- Decida. Registre quem aprovou, o que foi aprovado e quais premissas sustentam a decisão.
Esse tipo de estrutura muda o jogo porque reduz dependência de contexto tácito. O time não precisa adivinhar intenção. A decisão fica auditável. E, quando o cenário muda, dá para revisar a premissa original sem recontar toda a história do zero.
O processo de RFC que separa times que constroem de times que improvisam
Ferramenta não resolve processo ruim. Você pode escrever RFC no Notion, no Google Docs, no Git ou em qualquer outro lugar. O que define resultado é o ritmo operacional em volta do documento. Quem escreve, quem revisa, quanto tempo fica em aberto, o que exige RFC e o que não exige.
Times maduros tratam RFC como mecanismo de decisão, não como arquivo morto. Existe uma janela clara de comentários. Existe dono da proposta. Existe responsabilidade para responder objeções. E existe critério de quando parar de discutir e decidir. Sem isso, a RFC vira só um jeito mais sofisticado de procrastinar implementação.
Outro ponto que quase ninguém fala: RFC também protege o time de decisões arbitrárias vindas de cima. Quando você exige que mudanças relevantes passem por contexto, trade-off e impacto, o nível da conversa sobe. A discussão deixa de ser “faz porque eu acho melhor” e passa a ser “mostra por que essa decisão compensa o custo”. Isso é governança técnica de verdade.
O oposto também é verdadeiro. Time que rejeita RFC em nome de agilidade muitas vezes está só preservando um ambiente onde tudo depende de herói, urgência e memória informal. Isso até funciona em estágio inicial. Depois quebra. E quebra justamente quando o negócio mais precisa de previsibilidade.
Quando usar RFC no desenvolvimento de software e quando ela atrapalha
A crítica mais comum contra RFC é que ela burocratiza. Às vezes, essa crítica está certa. Nem toda decisão merece documento. Criar RFC para ajuste pequeno de interface, correção local ou experimento isolado é exagero. O objetivo não é aumentar fricção. É aplicar clareza extra onde o custo de errar é maior.
Use RFC quando houver impacto arquitetural, mudança de domínio, integração relevante, novo fluxo com dependência entre áreas, alteração de prioridade com efeito em roadmap ou qualquer decisão difícil de reverter depois. Nesses casos, o custo de não escrever quase sempre supera o custo de escrever.
Evite RFC quando o escopo é pequeno, reversível e de baixo risco. O filtro mais útil é simples: se a decisão tem alto impacto, múltiplos trade-offs ou dependência de alinhamento entre pessoas diferentes, documente. Se é algo local, trivial e facilmente reversível, resolva sem criar teatro processual.
A honestidade aqui importa. RFC não substitui liderança, repertório técnico ou bom senso. Também não impede erro estratégico. Mas, se bem usada, ela aumenta muito a chance de o erro aparecer cedo, quando ainda custa pouco. E esse é exatamente o tipo de vantagem que compõe um novo 80/20 de software: menos energia desperdiçada, mais decisão certa por unidade de esforço.
Perguntas frequentes sobre o novo 80/20 do desenvolvimento de software (RFCs)
O que é RFC no contexto de desenvolvimento de software?
RFC é um documento curto de proposta e decisão usado para alinhar mudanças relevantes antes da implementação. Ele registra problema, contexto, solução proposta, alternativas, riscos e critérios de sucesso.
RFC substitui reunião de alinhamento técnico?
Não totalmente, mas reduz muito a dependência de reunião como lugar principal de decisão. A RFC melhora a qualidade do debate porque organiza o pensamento antes da conversa e preserva o histórico depois.
Quando vale a pena criar uma RFC em um time pequeno?
Vale quando a decisão tem impacto alto, envolve trade-offs relevantes ou afeta mais de uma pessoa ou área. Mesmo em time pequeno, isso evita retrabalho e protege a velocidade futura.
Qual é a diferença entre RFC e documentação técnica comum?
Documentação técnica normalmente descreve como algo funciona ou foi implementado. A RFC existe antes da implementação e serve para decidir o que fazer, por que fazer e quais alternativas foram rejeitadas.
Como implementar RFC sem deixar o processo burocrático?
Use um template enxuto, defina claramente quais tipos de mudança exigem RFC e limite o tempo de revisão. O objetivo é melhorar a decisão, não criar um ritual pesado para qualquer tarefa pequena.