Exemplo De Um Conflito

Entendendo conflitos na prática do dia a dia

Conflito é basicamente quando duas pessoas ou sistemas chegam em lugares diferentes sobre a mesma coisa. Já vi muita gente chamar isso de "problema", mas na verdade é só um sintoma de que ninguém coordenou o trabalho antecipadamente. A pergunta certa não é "como resolver" mas sim "onde a coordenação falhou". No meu caso, recentemente fiquei preso com um problema em uma migração de banco. O sistema era legado, rodava em Oracle 11g, e a equipe queria migrar para PostgreSQL 14. Do lado da empresa, tinha pressão de diretoria pra acabar até o final do trimestre. Do lado técnico, eu sabia que o mapeamento das stored procedures ia dar trabalho, porque tinham loops embutidos que o plpgsql não traduz de forma nativa.

Um exemplo de conflito que apareceu na nossa equipe

O conflito real aconteceu quando dois desenvolvedores começar a refatorar tabelas ao mesmo tempo sem conversar. Um estava removendo colunas obsoletas da tabela "clientes", outro estava adicionando índices novos na mesma estrutura. Quando tentaram subir pra staging, o deploy quebrava todo dia às 3 da madrugada porque os scripts de migração executavam em ordem aleatória. A gente descobriu que o conflito não era técnico - era de processo. Ninguém havia definido quem era o guardião daquele schema. Eu propus um modelo simples: quem quiser mudar uma tabela precisa abrir uma issue no Jira com o ticket de migração anexado, e só quem tiver o ticket como "em análise" pode rodar o script naquele janela de manutenção. A equipe de QA passou a testar só após o merge do PR, não mais em tempo real. O problema é que isso aumentou o tempo de wait em cerca de 4 horas por dia útil. Mas pelo menos o staging ficou estável. Às vezes a gente paga estabilidade com velocidade, e tem projeto que não pode ter instabilidade nenhuma. Nesse caso, o trade-off foi aceito porque o sistema processava pagamentos e qualquer erro significava perda financeira direta.

O que funciona e o que não funciona

Reuniões semanais de alinhamento técnico costumam funcionar melhor que qualquer documentação. Eu já vi times que investiram R$ 50 mil em ferramentas de colaboração e ainda assim tinham conflitos diários. O problema era simples: as pessoas não sabiam o que o colega do lado estava fazendo. Uma chamada de 15 minutos toda segunda-feira resolve isso de graça. Outra armadilha comum é tentar resolver conflito com mais reunião. Se o problema é falta de clareza nas responsabilidades, juntar 8 pessoas num zoom de uma hora não resolve. O certo é mapear quem decide o quê, escrever isso num lugar visível, e atualizar toda vez que alguém mudar de time. Também tem o conflito de prazo versus qualidade. Já fiquei nessa situação: a gerência pedia pra entregar uma feature em duas semanas, mas a base técnica exigia refatorar três classes que estavam acopladas de errado. Eu escolhi entregar a feature do jeito que estava, documentando o débito técnico no backlog, e negociando com a gerência que a parte de instabilidade seria resolvida no sprint seguinte. Eles aceitaram porque entendiam o risco, e no final das contas a refatoração demorou só 4 dias, não 2 semanas.

Quando o conflito é inútil

Tem conflito que não agrega valor nenhum. Quando duas pessoas insistem numa opinião só porque "não querem parecer erradas", isso é ego, não técnica. Nesses casos, a solução é simples: colocar um dado concreto na mesa. Se não tem dado, pega um terceiro pra decidir. Às vezes eu uso o princípio do "disagree and commit" - você pode discordar, mas quando a decisão for tomada, executa como se fosse sua. Conflito sobre arquitetura também costuma ser perda de tempo. Já vi time discutir se usava microserviço ou monolito por três semanas. No final, a decisão foi fazer um monolito bem estruturado, porque o time tinha só 4 pessoas e não ia sustentar a complexidade de múltiplos serviços. Anos depois, quando o negócio cresceu, dividiram em dois módulos internos. A lição: não adianta antecipar problemas que ainda não existem. O pior tipo de conflito que já enfrentei foi entre product e engineering. Eles queriam uma funcionalidade nova, nós sabíamos que a arquitetura não suportava sem quebrar o sistema atual. A solução foi fazer um protótipo rápido de um dia pra demonstrar o problema. O product entendeu na prática, e conseguimos chegar num meio termo: lançamos a feature mais simples possível, com uma limitação técnica explicada claramente no release notes. Ninguém ficou feliz, mas o sistema não caiu.

Se você tá passando por um conflito agora, a primeira pergunta é: isso é sobre fato ou sobre opinião? Fato se resolve com dados. Opinião se resolve com conversa. Se for ego, aí é outra história - e aí o melhor é envolver alguém de fora pro mediar. Eu já vi conflitos durarem meses porque as pessoas tinham orgulho demais pra admitir que o caminho delas não era o melhor.