Desafios e Aprendizados como Líder Técnico - Minha primeira experiência com um projeto real

Olá Pessoal! Depois de um período de ausência na escrita, estou de volta, tentando retomar o ritmo. Quero ressaltar que as experiências compartilhadas neste espaço são baseadas nas minhas vivências acadêmicas e profissionais. Por isso, é importante lembrar que o que aqui está descrito pode representar apenas uma fração da realidade e não deve ser interpretado como uma fórmula definitiva para processos, procedimentos ou serviços específicos.

Atualmente, estou muito empolgado com esta nova fase da minha carreira. Tenho aprendido muito e gostaria de dividir um pouco dessa jornada com a comunidade. Espero que as informações aqui apresentadas sejam de grande valor para os leitores.

People First - A importância das Soft Skills

Quando participei do meu primeiro processo seletivo, há alguns anos, lembro claramente das etapas quase maçantes pelas quais passei: entrevista com o RH, teste prático, entrevista com o líder técnico e, finalmente, entrevista com o gestor. Ao longo da minha carreira como desenvolvedor, participei de várias entrevistas com diversos modelos. Naquela época, eu sempre me sentia desconfortável com a entrevista com o pessoal do RH. Não compreendia muito bem o motivo, pensando: “Se eu consigo realizar o que é demandado no teste técnico, já estou mostrando competência suficiente para a vaga.”

Quando assumi meu cargo como líder técnico de desenvolvimento, uma das minhas responsabilidades foi colaborar com o RH (sim, aqueles mesmos com quem eu não entendia o motivo de participar do processo seletivo) na elaboração de um teste técnico e na definição do formato de entrevista para dois candidatos iniciantes na área de backend. Eu achava que já sabia o que um desenvolvedor iniciante na área de backend deveria entregar e o que seria considerado um diferencial no teste. No entanto, o que eu não esperava era que, apesar da importância do código, outras demandas surgiram além da entrega do projeto: **como avaliar os candidatos em termos de comunicação? Qual é o interesse deles na vaga? E como o contexto apresentado por eles pode influenciar a adequação ao cargo proposto? Essas e outras perguntas revelaram-se tão relevantes quanto o código apresentado por ambos os candidatos, algo que eu não havia considerado anteriormente em meus primeiros anos como desenvolvedor. **

Lembro-me de quando me sentei à mesa de reunião para tomar a decisão final e fiquei um pouco surpreso ao perceber que pouco foi discutido sobre as habilidades técnicas de cada candidato. Parte disso se deve ao fato de que eram candidatos iniciantes, então, era de se esperar que suas habilidades técnicas não estivessem tão desenvolvidas, e isso não era o foco principal da discussão.

No entanto, mesmo para vagas mais avançadas, especialmente para cargos de nível sênior, é crucial considerar habilidades como comunicação, documentação, adaptabilidade, proatividade e outras competências muitas vezes mencionadas. Essas soft skills são fundamentais e podem ser determinantes para o sucesso no papel, além das habilidades técnicas. Inclusive, esse é meu próximo ponto.

A linha entre Júnior e Sênior(Não, não é o pleno).

Sei que há muita discussão sobre o significado e a classificação dos termos relacionados a níveis de experiência, como "sênior". Alguns dizem que "sênior é definido pelos anos de experiência", outros afirmam que "em algumas empresas, você ganha experiência de sênior após um ano". Há também quem diga que "não há uma distinção clara entre júnior e sênior" ou que "sêniores só fazem code reviews e aprovam PRs". Algumas dessas afirmações são cômicas, outras têm um fundo de verdade. O fato é que o conceito de "sênior" é bastante variado e não cabe a mim definir um padrão universal, mas posso oferecer algumas orientações para entender essa classificação de maneira mais individual.

Ser sênior não se resume apenas ao conhecimento técnico, embora isso seja, sem dúvida, muito importante. Um verdadeiro sênior, ou pelo menos um bom sênior, é alguém capaz de resolver problemas complexos tanto em termos de código quanto de arquitetura de sistemas. Manter a qualidade do código, seguir boas práticas de desenvolvimento e ter noções de gerenciamento de projetos são aspectos cruciais.

A diferença chave é que um sênior deve ser capaz de executar tudo isso com autonomia e, mais importante, colaborar com equipes de diferentes níveis e setores para entregar o melhor projeto possível. Além disso, um sênior de verdade (ou pelo menos os melhores) não só lidera e orienta a equipe, mas também desenvolve e prepara outros desenvolvedores para assumirem novas posições e responsabilidades.

Minha primeira experiência liderando um projeto

Quando assumi meu primeiro projeto, meu chefe sabia que anteriormente eu não tinha líderado nenhum outro. Apenas participado do desenvolvimento e elaborar algumas coisas que facilitassem o desenvolvimento a nível de comunicação com a gestão. A primeira pergunta que ele me fez foi: "Quantas pessoas e de que níveis será o suficiente para complementar o projeto". Eu não sabia a reposta prontmente na hora, era um pergunta muito complexa. porque o projeto estava apenas no esboço, não tínhamos noções da stack, de quanto tempo vai ser necessário para completar cada task e outras métricas de interesse do pessoal lá de cima. Fiz um estudo completo para poder entregar no dia seguinte sobre várias Metodologias de gestão de projetos: Pert, Planning Poker. Colaborativamente escolhemos a que melhor se adequadava e o desafio começou. Dividir a task para cada interegrante da equipe, qual a melhor plataforma de desenvolvimento, qual a melhor stack para usar, como vai funcionar a arquitetura do sistema, estudar outras soluções do mercado, acompanhar o nível de cada desenvolvedores, reuniões, reuniões e mais reuniões com a gestão.

Quando menos percebi, eu estava cada vez mais distante do código. Minha função passou a ser sugerir melhorias e corrigir alguns bugs críticos para que o projeto pudesse funcionar, ou pelo menos fornecer uma base sólida para que os desenvolvedores pudessem começar. O restante do trabalho envolvia comunicação com os desenvolvedores, divisão de tarefas, acompanhamento das métricas e, basicamente, um olho no Asana (para estimar o prazo de entrega do projeto) e outro no Meet para garantir que meu microfone não estivesse ligado e nada indesejado escapasse "sem querer".

Conclusão e um olhar sobre o passado - ao mestre com carinho

Comecei minha carreira como estagiário em desenvolvimento e, curiosamente — e você pode achar até um pouco contraditório da minha parte —, não tive experiências concretas (pelo menos não registradas formalmente na carteira de trabalho) que me classificassem como desenvolvedor júnior, pleno ou sênior. Grande parte da experiência que adquiri veio de projetos pessoais e de pesquisa na faculdade. Foi um processo gradual até eu perceber que minhas habilidades haviam evoluído desde os primeiros dias.

Mas sim, trabalhei intensamente como desenvolvedor em diferentes níveis e tive a oportunidade de conhecer diversos tipos de profissionais sêniores ao longo da minha trajetória:

1. O sênior muito competente e eficaz, mas pouco comunicativo, que resolvia problemas sem fornecer explicações sobre sua abordagem.
2. O sênior excelente em comunicação e didática, mas frequentemente sobrecarregado com tarefas urgentes e sem tempo para ensinar.
3. O sênior que era um entusiasta da engenharia excessiva e centralizava a tecnologia, mas que cumpria prazos e entregava o que prometia.

O mais importante é que, apesar de suas falhas justificáveis (Apesar de ser possível é muito díficil equilibrar demandas), todos esses profissionais tinham algo valioso a ensinar. Essas experiências ajudaram a moldar minha carreira e me proporcionaram uma visão clara do que funciona e do que não funciona no desenvolvimento de sistemas.