- Em uma empresa com grande dívida técnica, surgem ineficiências causadas por código duplicado e frameworks desatualizados
- Durante a execução do projeto, a perda de confiança da gestão e a resistência à mudança dentro da organização atuam como principais obstáculos
- A causa raiz da dívida técnica são fatores humanos, como requisitos pouco claros, prazos irreais, preferência por tecnologias antigas, respostas de curto prazo da liderança e orgulho pessoal
- Não apenas os resultados técnicos, mas também a gestão de percepção e a comunicação são essenciais para o sucesso de um projeto
- Além da capacidade técnica, engenheiros precisam de habilidade para colaborar dentro da organização e coordenar relações humanas
Problemas de dívida técnica e código duplicado
- Em uma empresa onde trabalhei no passado, havia uma dívida técnica grave: milhões de linhas de código, ausência de testes unitários e uso de frameworks com mais de 10 anos
- Para executar um módulo exclusivo de Windows no Linux, isso foi resolvido com copiar e colar centenas de milhares de linhas de código
- Com isso, surgiram duas bases de código, e a adição de funcionalidades e a correção de bugs passaram a precisar ser feitas separadamente em cada uma
- Esse tipo de situação leva a uma estrutura impossível de manter, e a divergência entre os códigos aumenta com o tempo
Dívida técnica causada por problemas humanos
- Projetos de dívida técnica são difíceis de vender para a liderança e, como no fim quase não há mudança visível de funcionalidade, faltam resultados perceptíveis
- O projeto atrasa e a confiança da liderança se perde
- A essência do problema não é tecnologia, mas sim a atitude das pessoas e a cultura organizacional
- Muitos desenvolvedores resistem à mudança e se acomodam às formas antigas de trabalhar
- A estrutura do código reflete a personalidade do autor e o quanto ele aceita mudanças
- A dívida técnica nasce de requisitos pouco claros, promessas irreais, escolhas tecnológicas ultrapassadas, decisões da liderança de interromper iniciativas e orgulho pessoal
- Quanto mais forte for, em uma equipe, a tendência de evitar mudanças, mais o código também refletirá essa rejeição à mudança
- Vários desenvolvedores vinham trabalhando havia anos exatamente da mesma forma, e chegou-se até a ouvir: “não quero aprender nada novo”
- Em um ambiente assim, a dívida se acumula mais rápido do que pode ser organizada, então, antes de reduzi-la, a prioridade é impedir que ela continue aumentando
- Como na analogia da triage (classificação de prioridade) de um pronto-socorro, primeiro é preciso “estancar o sangramento”
A distância entre o mundo ideal e a realidade
- Quase não existe um ambiente ideal em que problemas de engenharia possam ser resolvidos separadamente da política ou do contexto organizacional
- A maioria dos projetos tem partes interessadas não técnicas
- A postura de “confie na gente porque estamos fazendo isso” não funciona
- Gerir a percepção dos resultados é tão importante quanto os resultados em si
- Como pessoas não técnicas não entendem intuitivamente a necessidade de lidar com dívida técnica, é preciso explicá-la em valor quantitativo e valor de negócio
- Quando a liderança não tem formação em engenharia, é necessário apresentar números e efeitos visíveis
- No fim, parecer que a equipe é produtiva também é tão importante quanto a produtividade real
Competências necessárias para engenheiros sêniores
- Em cargos de nível sênior ou acima, a capacidade de colaborar entre departamentos e coordenar relações humanas é indispensável
- A formação em ciência da computação não ensina a lidar com pessoas, como personalidade, orgulho e gestão de relacionamentos
- Mesmo um engenheiro com grande excelência técnica pode ter dificuldade com problemas que exigem mudanças amplas e organizacionais
- A produtividade individual pode ser alta, mas a influência organizacional é limitada
- O papel de
Heads up coder é importante
- Alguém que mantém profundidade técnica, mas também consegue perceber cedo os riscos do projeto e ajustar a equipe
- Em vez de trabalhar sozinho e rápido como um núcleo único, atua para conduzir toda a equipe de forma eficiente
- Diferentemente de um engenheiro puramente técnico, consegue agir lendo ao mesmo tempo o contexto organizacional e os riscos
Resumo
- Na raiz dos problemas técnicos, sempre há pessoas
- A maioria dos problemas técnicos acaba se reduzindo a problemas de pessoas, cultura e comunicação
- Dívida técnica não é um problema de código, mas o resultado de padrões de comportamento e da cultura da organização
- Para resolver dívida técnica, é preciso antes haver aceitação de mudanças organizacionais e entendimento da liderança
- E existem problemas que não se resolvem apenas com excelência técnica, esperando em palcos maiores das fases mais avançadas da carreira
- Um verdadeiro engenheiro sênior é um líder equilibrado, capaz de lidar tanto com tecnologia quanto com compreensão humana
2 comentários
Para quem quiser saber mais sobre isso, recomendo a leitura de Peopleware!
Opinião do Hacker News
Percebi que a maioria dos problemas são problemas de comunicação
Os engenheiros estão desconectados da visão do produto ou dos clientes, e a equipe de produto trata os engenheiros como uma simples equipe terceirizada interna
Vendas e CS não entendem como as promessas que fazem afetam o roadmap do produto
No fim, objetivos e métricas de sucesso ficam desalinhados, e todos acabam remando em direções diferentes
A solução não é “pessoas melhores”, mas fazer com que todos estejam comprometidos com o mesmo objetivo e entendam como seu papel se encaixa no todo
O mesmo vale para a antiga dívida técnica: ela não desaparece só porque foi ignorada. É preciso quantificar o custo e o risco que essa dívida traz para a empresa, equilibrá-los com outras metas e montar um plano para ir quitando isso
São sessões em que, como o usuário está bem ao seu lado, você o encontra pessoalmente, vira amigo dele e aprende sobre seu dia a dia e contexto
Elas são agendadas automaticamente a cada 3 semanas e acontecem sem itens de ação separados. Toda vez as pessoas se surpreendem, pequenos bugs são resolvidos e conexões são criadas
Estou operando isso com um agendador automático integrado à API do Slack, e a parte mais difícil é conciliar agendas e incentivar a participação
A liderança não ouve quem está abaixo, e quem está abaixo compete por atenção
Recentemente, no nosso departamento, um consultor sugeriu migrar para uma nova plataforma; ninguém concordou, mas não foi possível parar. No fim, ninguém escuta ninguém
À pergunta “por que estamos fazendo isso?”, a resposta que volta é algo como “confia em mim”
Não acho que esse comportamento de PM vá mudar. Então os engenheiros estão assumindo diretamente funções de produto para eliminar a lacuna de comunicação
Percebi que muita gente, na prática, não sente orgulho do trabalho
Para algumas pessoas, é só um salário
Especialmente colegas mais velhos já viram sistemas ruírem e querem evitar que isso aconteça de novo
Sempre que entro em um novo emprego, tento estabelecer diretrizes claras dentro de um plano de 90 dias, mas no fim o essencial é a equipe
Algumas equipes têm sede de mudança, e outras atrapalham qualquer mudança
Fica mais difícil quando o líder é ignorante ou só escolhe a opção mais rápida e barata
Também me lembra casos como o escândalo dos Correios britânicos, em que o problema era conhecido internamente, mas foi bloqueado
No passado, mais da metade era autônoma; hoje restam algo em torno de 10%
O que produzimos agora não é “nosso”, é “do empregador”
Mesmo se você trabalhar mais, não será recompensado; ao contrário, só vai acabar assumindo mais trabalho
No fim, as pessoas são tratadas como recursos e, quando deixam de ser necessárias, são descartadas
Em uma crise, os primeiros a serem demitidos são os funcionários, enquanto o CEO recebe milhões de dólares
Numa estrutura assim, é impossível esperar que os funcionários se dediquem à empresa
Quem trabalha menos recebe mais, e você pode ser demitido por causa de um substituto que ganha metade do seu salário
As entrevistas estão cada vez mais difíceis, o mérito é roubado e a inflação corrói os salários
No fim, “por que o orgulho desapareceu?” parece um mistério, mas a resposta é bem óbvia
Mas as empresas sabem que a maioria das pessoas não consegue fazer o que quer e, em vez disso, focam em processos e workflows
Para o indivíduo, o melhor é fazer algo de que gosta e ainda ser bem remunerado
A fala de um desenvolvedor de que “não quer aprender coisas novas” não é necessariamente ruim
O cansaço com frameworks que mudam todo dia, como no ecossistema JavaScript, é diferente da estabilidade técnica baseada em Go ou LTS
Estabilidade também ajuda na agilidade do produto
Talvez seja preciso negociar com um engenheiro sênior que cuida de uma base antiga em C++, mas chamar isso simplesmente de dívida técnica é preconceituoso
Só o IC líder responsável pela base de código e o gerente dele podem julgar se isso é dívida técnica ou não
Mencionar problemas humanos numa entrevista é uma ótima forma de ser reprovado
Muitos entrevistadores tratam apenas respostas técnicas como corretas e ignoram percepções humanas
Eu, ao contrário, valorizo bastante esse tipo de visão, mas preciso travar batalhas de convencimento com meus colegas
Quando ele disse que, dependendo da taxa de processamento de mensagens, um processamento em lote poderia ser suficiente, esse entrevistador concluiu de imediato que ele “não entendia de filas”
Ele disse que trabalhava há mais de 10 anos com produtos de dados em escala de petabytes, mas foi rejeitado porque isso não se encaixava no design de sistema daquele entrevistador
E agora essa equipe está colocando todos os microsserviços atrás de uma única API
Se a equipe não consegue entender esse equilíbrio, então você não precisa entrar nela
Como engenheiro de dados em Big Tech, os dois problemas mais difíceis são estes
Primeiro, por causa da Lei de Conway, cada departamento tem uma toolchain e uma filosofia de dados diferente
Segundo, cada silo insiste que só seu jeito está certo, mas ao mesmo tempo quer os dados dos outros
O motivo de a padronização ser impossível é que os líderes de cada departamento acreditam que seu próprio método é a única solução
Na prática, a maioria das abordagens está certa e errada ao mesmo tempo
Parece um problema técnico por fora, mas no fim é um problema de pessoas
Como não há aviso de mudanças nos sistemas upstream, só ficamos sabendo quando o alarme dispara no downstream
Há tantos pedidos improvisados que os sprints perdem o sentido, e existe conhecimento demais que nunca foi documentado
Experiências assim me deram motivação para estudar ciência da computação em níveis mais baixos
Para conduzir mudanças, é preciso construir uma rede, unir pessoas e propagar a mudança com transparência
Mas, para haver mudança de verdade, é necessário apoio de líderes mais altos, como diretores ou VPs
A AWS publicou um guia para esse tipo de mudança organizacional, e o AWS Prescriptive Guidance é um excelente modelo
Tudo começa com “vamos unir todos em uma solução só”, mas logo se fragmenta em projetos separados por departamento
Para impedir isso, é preciso um líder com autoridade forte
Isso é ainda mais difícil no setor público, onde muitas vezes os grupos se odeiam; no setor privado, ao menos existe o objetivo comum de manter os empregos
Como Jerry Weinberg disse em 『Secrets of Consulting』,
“Mesmo que por fora pareça um problema técnico, é sempre um problema de pessoas”
A raiz dos problemas técnicos está, no fim, nas escolhas, na comunicação, na gestão e na capacidade das pessoas
Trabalhei como analista em um projeto de substituição de sistema
O sistema antigo distribuía trabalho por um simples round-robin, mas o novo sistema fazia uma distribuição mais justa considerando a carga de trabalho de cada pessoa
Só que alguns funcionários manipulavam o sistema para parecer ocupados, e com isso os funcionários mais dedicados acabavam assumindo mais trabalho
Explicamos claramente que a essência do problema não era técnica, mas a falta de supervisão, porém no fim fomos obrigados a adotar uma solução técnica
Pela natureza humana, o trabalho tende a se expandir para ocupar todo o tempo disponível, e esse tipo de incentivo perverso precisa ser controlado tecnicamente
Se você desenhar um sistema partindo do pressuposto de seres humanos ideais, ele vai falhar
Jerry Weinberg, desde 『The Psychology of Computer Programming』 (1971),
enfatizava o princípio de que “mesmo que pareça um problema técnico, é sempre um problema de pessoas”
Os livros dele continuam valendo a leitura até hoje
Eu detesto essa atitude de culpar as pessoas por “não terem orgulho do próprio trabalho”
A maioria dos funcionários não é dona do próprio trabalho; a dona é a empresa
Se a empresa impõe uma direção específica e pune quem discorda, por que alguém iria lutar contra isso?
Somos apenas engrenagens da máquina e, se somos tratados assim, só estamos agindo de acordo
A postura egocêntrica do autor me soa desagradável
Hoje sou bem sênior e trabalho diretamente com patrocinadores de orçamento e responsáveis por requisitos
Eles perguntam “faz isso pra gente, quanto custa?”, mas eu tenho que dar uma estimativa aproximada já aos 18 minutos de uma reunião de 30
Eles não entendem de tecnologia, mas entendem perfeitamente a linguagem do dinheiro e da política
Houve problema que resolvi com uma única mensagem de texto, e o orçamento era de 6 milhões de dólares
Em outro caso, um projeto foi parar em outra equipe, que queimou 35 milhões de dólares e fracassou
Os patrocinadores que controlam o orçamento quase sempre colocam a política acima de tudo, e o objetivo deles é “o próximo cargo”
Quando você olha a carreira deles, muitas vezes pensa: “como essa pessoa chegou até aí?”