Quando comecei a trabalhar com software em 2005, na Grande São Paulo, as aplicações eram bastante limitadas. Lembro que as oportunidades de projetos se resumiam a construir e-commerces e intranets.
A maioria das empresas não era de tecnologia — tinham times de TI. Mesmo tendo tido contato cedo com metodologias que colocavam as pessoas técnicas no centro, como o XP (Extreme Programming), demorou para eu conseguir colocar em prática o protagonismo da pessoa engenheira e a ideia de ciclos de entrega organizados e efetivos. Muitos projetos da época sequer foram entregues. Eu só consegui ver isso funcionando quase 10 anos depois, na Vérios. Lá, as pessoas engenheiras estavam a par do negócio e influenciavam diretamente na evolução do produto e da empresa. Eu estava vivendo um sonho.
Mas, enquanto eu estava isolado nesse “dream team”, nossa área evoluía — e demorei a perceber que o rumo tomado era, no mínimo, duvidoso. Surgiram novas siglas: PM, GPM, EM, GM. E processos cada vez mais burocráticos para a velha arte de programar softwares.
Na minha visão, essa evolução precisa ser revista. Acredito que muitas empresas de tecnologia foram tomadas por pessoas sem profundidade técnica, que não sabem, na prática, o que é um software.
Você pode estar se perguntando: qual o problema disso?
Te dou um exemplo: o que faz alguém sem familiaridade com tecnologia ao ver 10 itens no backlog e descobrir que a equipe atual consegue entregar apenas 1 por vez? Essa pessoa contrata mais 9 equipes, para “paralelizar” o trabalho. Pronto, problema resolvido.
Já consegue ver o real problema? Com essas 10 equipes, surgem novas lideranças e gestores para coordenar tudo — traduzindo as necessidades do negócio em software. Muitas dessas pessoas, mais uma vez, sem profundidade técnica.
Mas o problema não está apenas nessas novas figuras que tornam o desenvolvimento de produto lento. Nós, líderes técnicos, talvez também tenhamos nos afastado demais do dia a dia. Em que momento passamos a achar normal um desenvolvedor alternar, numa mesma semana, entre Rust, Java, Swift e Golang?
“Quem programa uma linguagem, programa qualquer outra” — pensou o líder corrompido.
A realidade é mais dura: mudanças bruscas de contexto cobram um preço alto. É preciso buscar padrões e boas convenções.
E, por falar em contexto, há um que toda pessoa engenheira deveria protagonizar: o contexto de negócio. Quem disse que engenheiros não entendem de negócios? Será que realmente não entendem? Ou será isso uma consequência da evolução inflada de algumas organizações, que acabam delegando o rumo do software a pessoas sem profundidade no assunto?
Enfim, ao meu ver, muito do que aconteceu na evolução das áreas de tecnologia precisa ser revisitado. As novas estruturas de times geram ineficiências. Para mim, é hora de voltar nossa atenção ao que realmente importa: o software.
Tenho muito a compartilhar e discutir sobre o que pode ser uma área de tecnologia eficiente. A ideia deste blog é exatamente essa: ser um espaço para mim e para meu time compartilharmos experiências e provocações.