Todos os dias, precisamos tomar uma série de decisões. Desde qual roupa vestir, o que comer até decisões mais importantes como qual linguagem de programação adotar ou qual serviço de nuvem escolher. Boas decisões, tomadas no tempo certo e com a informação necessária é o diferencial de times/empresas de sucesso.
Porém, o processo de tomada de decisão fica mais complexo a medida que uma equipe cresce, uma empresa cresce. Quanto maior e mais complexo é o ambiente, mais difícil é para alguém entender todos os impactos que uma determinada decisão pode ter. É impossível que alguém conheça todos os detalhes envolvidos.
O caminho natural é envolver pessoas com conhecimentos complementares e que estejam o mais próximo possível da situação ou problema sobre qual a decisão será tomada. Isso permite que os impactos sejam melhores identificados com o trabalho deste grupo multidisciplinar.
Porém, mesmo com trabalho de grupos multidisciplinares, corre-se o risco de não gerar um output de boa qualidade a partir desta discussão. Se o grupo não tem clareza de qual decisão precisa ser tomada e até quando precisa ser tomada, muito tempo é gasto em discussões circulares ou buscando consenso e perde-se o momento certo para a tomada de decisão.
Andrew Grove, ex-CEO da Intel, considerado pai dos OKRs e influenciador de CEOs de big techs como Mark Zuckerberg, afirma que decisões tem mais chance de gerar um output de alta qualidade e em tempo hábil quando se tem clareza das expectativas. Para ajudar nisso, ele sugere que as 6 perguntas abaixo sejam respondidas:
- Qual decisão precisa ser tomada?
- Quando ela precisa ser tomada?
- Quem vai decidir?
- Quem precisará ser consultado antes da decisão?
- Quem aprovará ou vetará a decisão?
- Quem precisará saber da decisão?
Ele afirma ainda que o modelo ideal de tomada de decisões tem um passo-a-passo definido. O primeiro passo consiste numa discussão livre e saudável de ideias, num espaço seguro onde as pessoas possam dizer o que pensam. Este grupo precisa explorar premissas e alternativas e até tentar reunir informações que derrubem a hipótese/argumento inicial. O segundo passo é uma definição clara dos termos da decisão que podem ser obtidos respondendo as 6 perguntas. E por fim, tomar a decisão e ter o apoio de todos os envolvidos. Segundo Andrew, este era o processo que levou a Intel a tomar boas decisões e obter resultados impressionantes enquanto esteve à frente da empresa.

Isso soa familiar, certo? É exatamente o processo de tomada de decisão proposto com a adoção do uso de RFCs. Um documento RFC responde todas as perguntas propostas por Andrew e também segue o passo-a-passo adotado por ele. O documento tem o objetivo de apresentar a motivação/contexto/problema a ser resolvido, a proposta de solução, alternativas de solução exploradas, quem será o responsável por decidir e até quando o documento estará aberto para comentários.
Esta familiaridade não é coincidência. Basta lembrar que o uso de RFC foi utilizado para a tomada de decisões que ajudaram a criar a internet e sua infraestrutura. Desde a criação da world wide web, RFCs apoiam o processo de tomada de decisão de vários projetos open source de destaque como React, Ember e Rust. Eu os considero projetos de muito sucesso.
Além de todos estes argumentos (clareza, discussão livre, etc) que justificam a razão pela qual o uso de RFC nos conduz a output de boa qualidade, há um que eu considero muito importante e não foi citado. Você precisa escrever. Exatamente, escrever. Não é apresentar um ppt ou falar numa reunião, é escrever. Para escrever, você precisa estruturar seu raciocínio, estabelecer uma narrativa, expor a situação de forma lógica e refletir sobre o que você está “colocando no papel”. Este processo faz o cérebro trabalhar e até pode trazer ideias novas trazendo à tona fatores/alternativas que ainda não tinham sido pensados. Eu considero que este exercício é um dos grandes responsáveis pelo aumento da qualidade da tomada de decisão.
Tomar boas decisões não é o único benefício deste processo. Times que eu acompanhei o processo de adoção de RFC relatam que:
- Ajuda e escala o onboarding de novos membros no time pois estes documentos ajudam os novatos a entender o contexto por trás de uma decisão sem precisar conversar com várias pessoas. E ainda vai além, ajuda a entender o porque esta foi alternativa escolhida em detrimento de outras.
- Torna mais fácil e ágil adicionar novos membros ao grupo de discussão. Não é raro que, no meio de uma discussão, o grupo peça ajuda a alguém que não estava envolvido até ali pois descobriu-se que seus conhecimentos poderiam ajudar. Com o apoio da documentação, o novo membro se insere rapidamente e no mesmo ponto dos demais porque conhece quais tópicos já foram discutidos, quais perguntas já foram feitas, o que já foi descartado e etc.
- Torna mais fácil obter apoio de todos com a solução escolhida ou decisão tomada mesmo que alguns membros discordem. O processo permite que todos participem do processo, conheçam a trilha que levou até esta decisão final e tenham certeza que a mesma foi tomada levando em consideração vários pontos de vista.
- Tornou-se uma ferramenta ainda mais poderosa com o crescimento do trabalho remoto. O novo modelo de trabalho imposto pela pandemia requer comunicações assíncronas. Num cenário onde times são formados por pessoas com rotinas domésticas diferentes e até em fusos horários diferentes, não é viável depender da agenda de todos para marcar reuniões de discussão ou esperar a resposta de um colega (que pode demorar 4-5 horas). O documento RFC permite discussões assíncronas e documenta a história do time/empresa.
- Escala o compartilhamento de conhecimento e evita que parte da história se vá juntamente com alguém que deixou o time. Acredito que todos nós já passamos por uma situação em que questionamos alguma decisão ou porque o time faz algo desta forma e alguém do time nos respondeu que foi iniciativa da pessoa X mas que a pessoa X não está mais na empresa. Se a pessoa X escreveu um documento RFC, é fácil responder estas questões.
- Ajuda na formação e desenvolvimento de membros mais juniores do time. Através da leitura de documentos RFC, membros menos experientes aprendem como membros mais experientes estruturam uma solução, quais fatores precisam ser considerados, qual linguagem é utilizada para permitir que membros não técnicos também sejam incluídos e possam colaborar.
Diante de todos este benefícios, eu espero que cada vez mais o uso de RFC saia do grupo de tecnologia e alcance outras áreas da empresa. Dado a origem do uso de RFCs, muitas pessoas ainda acreditam que é um documento exclusivo para discussão e tomada de decisões de TI (arquiteturais, infraestrutura, linguagem de programação, ferramentas). Mas veja que é possível usar RFCs para discutir qual estratégia de marketing adotar para o produto Z, qual é a melhor cidade ente W e Z para construir um parque industrial, qual é o melhor processo de meritocracia para a empresa e por aí vai.
Se o seu time/empresa ainda não adota este documento como parte do processo de tomada de decisões no dia-a-dia, eu te encorajo a dar uma chance. Muitas vezes, a documentação é vista como sinal de burocracia, porém acho que já deu para perceber que não é este o caso. E para quem diz que RFC burocratiza o desenvolvimento ágil, lembre-se que:
Indivíduos e interações mais que processos e ferramentas. E não ausência de processos e ferramentas.
Software em funcionamento mais que documentação abrangente. E não ausência total de documentação.
Colaboração com o cliente mais que negociação de contratos. E não a ausência completa de contratos e acordos.
Responder a mudanças mais que seguir um plano. E não a ausência de planejamento.

Deixe um comentário