Discordem de mim (mas eu sou o chefe)

Toda vez que levo uma ideia de arquitetura para o time, faço a mesma brincadeira:

"Sintam-se livres para discutir e discordar de mim. Se a minha ideia for melhor, seguimos com ela. Se a sua for melhor, seguimos com a sua. Se a nossa for melhor, melhor ainda. Mas se a sua for melhor e eu quiser fazer a minha, faremos a minha, porque eu sou o chefe."

O pessoal ri. Mas a brincadeira tem duas metades sérias, e eu levei um tempo para chegar nelas.

Eu entregava a arquitetura pronta

Durante muito tempo, eu montava a arquitetura da solução sozinho. Desenhava as features de maneira geral, decidia como cada peça ia conversar com a outra e passava a tarefa já arquitetada para os devs executarem. Em parte era falta de tempo. Em parte era o jeito que eu tinha aprendido a trabalhar em 15 anos de consultoria, onde quase sempre eu era a pessoa mais experiente na sala e o prazo era curto.

Funcionava, no sentido de que a entrega saía. O que não saía era o porquê. O time sabia o que fazer, mas não sabia por que estava fazendo daquele jeito. E quem não sabe o porquê não consegue decidir sozinho quando a situação muda um pouco.

A pergunta que eu não sabia responder

Quando o time começou a crescer com gente júnior, um dev veio com uma dúvida de modelagem. A tela de pedidos precisava mostrar o status de cada pedido (aguardando pagamento, pago, enviado, entregue), mas a tabela de pedidos não tinha uma coluna de status. Dava para descobrir olhando outros campos: se tem data de pagamento, está pago; se tem código de rastreio, foi enviado. A pergunta dele era: posso criar um método no model que calcula o status na hora?

Para mim a resposta era óbvia: nesse caso, não. Ele devolveu com a pergunta mais simples do mundo: "mas por que é óbvio?".

Eu não soube explicar na hora. Era óbvio para mim por causa de anos fazendo aquilo, mas eu nunca tinha colocado em palavras. Depois, com calma, consegui. O método funciona bem enquanto você olha um pedido de cada vez. O problema aparece quando alguém pede a lista de todos os pedidos pagos e ainda não enviados. Como o status não está no banco, a consulta não consegue filtrar por ele, e o sistema precisa carregar todos os pedidos e calcular um por um. Com cem pedidos ninguém percebe. Com cem mil, a tela trava. A regra que eu seguia sem saber que seguia era essa: se uma informação vai ser usada para filtrar e listar, ela precisa estar no banco. E, como quase tudo em arquitetura, depende: se ninguém nunca for filtrar por status, o método resolve e é mais simples.

Naquele dia eu entendi que muita decisão minha de arquitetura era assim: certa, provavelmente, e impossível de ensinar do jeito que estava, porque morava só na minha cabeça.

Deixar o raciocínio errado ir até o fim

Há pouco mais de um ano mudei o jeito de discutir uma feature. Em vez de chegar com a arquitetura pronta, levo a ideia, explico por que cheguei naquela linha de pensamento e peço para o time discordar.

A parte difícil não é pedir. É aguentar a resposta. Quase sempre alguém propõe um caminho que eu sei que não é o melhor, e a vontade é cortar na hora e explicar por quê. O que eu tento fazer é não cortar. Deixar a pessoa argumentar até o fim, mesmo sem conhecimento suficiente, mesmo indo para o lado errado, e perguntar como ela chegou ali.

A minha aposta é que é nessa hora que aparece o que eu mais preciso saber: como aquela pessoa pensa. O raciocínio errado raramente é burro. Costuma partir de uma informação que falta ou de uma premissa que ninguém contou para ela. No ano passado, um dev nosso resolveu um problema de performance subindo de dois para oito o número de nós do Kubernetes. O gargalo sumiu. A conta da AWS foi de 200 para 800 dólares numa semana. A lógica dele fazia sentido: tinha gargalo, mais máquina resolve gargalo. O que faltava era entender o que aquele número significava e quanto ele custava. Ninguém discutiu antes: ele me contou depois, quando o gargalo já tinha sumido, e a conta veio na sequência. Se aquele raciocínio tivesse aparecido numa discussão, talvez a peça que faltava surgisse antes da fatura.

Depois que a pessoa termina, aí sim eu tento explicar por que aquele não é o melhor caminho. E explico com o motivo, não com a autoridade. Se eu não consigo dar o motivo, é sinal de que eu preciso pensar de novo, e aí vale a regra da brincadeira: se a ideia dele for melhor, seguimos com a dele.

Me explica o que você está fazendo

A mesma lógica vale fora das reuniões. No começo, quando alguém travava, eu sentava do lado, olhava o código e resolvia o problema pela pessoa. Hoje eu tento pedir: me explica o que você está fazendo.

Não é porque eu não entendi. A ideia é que, para explicar, a pessoa precisa organizar o próprio pensamento, e às vezes a solução aparece no meio da explicação, sem eu dizer nada. Eu viro um pato de borracha que faz perguntas. Demora mais do que resolver por ela, e para mim essa demora é justamente o ponto.

E o "porque eu sou o chefe"?

É a segunda metade séria da brincadeira. Discutir não é votar. Liberdade para discordar não quer dizer que a decisão sai por consenso, nem que eu posso terceirizar a responsabilidade para o time. Alguém precisa decidir e segurar a decisão quando ela der errado, e esse alguém sou eu.

A brincadeira deixa isso claro sem pesar. Todo mundo sabe que quem decide sou eu, então ninguém precisa ficar medindo palavra com medo de "ganhar" do chefe. E, como a regra é dita em voz alta e com risada, a minha esperança é que fique mais fácil discordar de verdade.

Se for tentar

Não sei se é o jeito certo, e o custo é claro: a discussão fica mais lenta. Uma feature que eu arquitetaria sozinho passa a depender de uma conversa com o time. Se você lidera gente e quiser experimentar, as sugestões que eu deixo são poucas:

• Leve a ideia crua, com o seu raciocínio junto, e não a arquitetura pronta.
• Quando alguém for pelo caminho errado, segure a vontade de cortar e pergunte como a pessoa chegou ali.
• Na hora de discordar, explique com o motivo. Se não houver motivo, talvez a ideia do outro seja melhor.
• Deixe claro, sem peso, quem decide e quem segura a decisão depois.

E um efeito que eu não esperava: ter que explicar me obrigou a saber por que as minhas decisões são as minhas decisões, coisa que em 20 anos fazendo arquitetura eu achava que já sabia.