As lições surpreendentes que aprendi como líder de tecnologia

Olá a todos! Depois de um período de ausência da escrita, estou de volta, tentando retomar o ritmo das coisas. Quero enfatizar que as experiências compartilhadas neste espaço são baseadas em minhas experiências acadêmicas e profissionais. Portanto, é importante lembrar que o que está descrito aqui 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.

Estou muito animado com essa nova fase da minha carreira. Aprendi muito e gostaria de compartilhar um pouco dessa jornada com a comunidade. Espero que as informações apresentadas aqui sejam de grande valor para os leitores.

As Pessoas em Primeiro Lugar - A importância das Soft Skills

Quando participei do meu primeiro processo seletivo, alguns anos atrás, lembro claramente das etapas quase chatas pelas quais passei: entrevista com o RH, teste prático, entrevista com o líder técnico e, por fim, entrevista com o gerente. Ao longo da minha carreira como desenvolvedor, participei de várias entrevistas com diferentes modelos. Naquela época, sempre me senti desconfortável entrevistando com pessoas do RH. Não entendia muito bem o porquê, pensando: “Se eu consigo fazer o que é exigido no teste técnico, já estou mostrando competência suficiente para a vaga.”

Quando assumi minha função de líder de desenvolvimento técnico, uma das minhas responsabilidades era colaborar com o RH (sim, as mesmas pessoas com quem eu não entendia o motivo de participar do processo seletivo) na preparação de um teste técnico e na definição do formato de entrevista para dois candidatos iniciando 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 surgissem 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 que eles apresentam pode influenciar sua adequação à vaga proposta? Essas e outras questões se mostraram tão relevantes quanto o código apresentado por ambos os candidatos, algo que eu não havia considerado anteriormente nos meus primeiros anos como desenvolvedor.

Lembro-me de sentar à mesa de reunião para tomar a decisão final e ficar um pouco surpreso ao perceber o quão pouco foi discutido sobre as habilidades técnicas de cada candidato. Parte disso se deveu ao fato de que eles eram candidatos iniciantes, então era de se esperar que suas habilidades técnicas não fossem tão desenvolvidas, e esse 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 habilidades frequentemente mencionadas. Essas soft skills são fundamentais e podem ser decisivas para o sucesso na função, além das habilidades técnicas. Aliás, esse é meu próximo ponto.

A linha entre Júnior e Sênior (Não, não é nível médio).

Sei que há muita discussão sobre o significado e a classificação de termos relacionados a níveis de experiência, como "sênior". Alguns dizem que "sênior é definido por anos de experiência", outros afirmam que "em algumas empresas, você ganha experiência sênior após um ano". Há também aqueles que dizem que "não há distinção clara entre júnior e sênior" ou que "os seniores apenas fazem revisões de código 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 uma forma mais individual.

Ser um sênior não é apenas sobre 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 em termos de código e arquitetura de sistemas. Manter a qualidade do código, seguir boas práticas de desenvolvimento e ter conhecimento de gerenciamento de projetos são aspectos cruciais.

A principal diferença é que um sênior deve ser capaz de executar tudo isso de forma autônoma 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 apenas lidera e guia a equipe, mas também desenvolve e prepara outros desenvolvedores para assumir novas posições e responsabilidades.

Minha primeira experiência liderando um projeto

Quando assumi meu primeiro projeto, meu chefe sabia que eu não tinha liderado nenhum outro projeto anteriormente. Eu apenas participei do desenvolvimento e trabalhei em algumas coisas que facilitariam o desenvolvimento em termos de comunicação com a gerência. A primeira pergunta que ele me fez foi: "Quantas pessoas e que tipo de serão suficientes para complementar o projeto". Eu não sabia a resposta de imediato, era uma pergunta muito complexa. Como o projeto estava apenas no esboço, não tínhamos ideia da pilha, quanto tempo levaria para concluir cada tarefa e outras métricas de interesse das pessoas acima. Fiz um estudo completo para poder entregar no dia seguinte em várias metodologias de gerenciamento de projetos: Pert, Planning Poker Escolhemos colaborativamente a que mais se adequava e o desafio começou. para cada membro da equipe, qual a melhor plataforma de desenvolvimento, qual a melhor pilha a ser usada, como a arquitetura do sistema funcionará, estudando outras soluções do mercado, monitorando o nível de cada desenvolvedor, reuniões, reuniões e mais reuniões com a gerência .

Quando menos percebi, estava cada vez mais distante do código. Meu papel 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 os desenvolvedores começarem. O resto do trabalho envolvia comunicação com os desenvolvedores, divisão de tarefas, monitoramento de métricas e, basicamente, um olho no Asana (para estimar o tempo de entrega do projeto) e outro no Meet para garantir que meu microfone não estivesse ligado e que nada indesejado tivesse "acidentalmente" passado.

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

Comecei minha carreira como estagiário de desenvolvimento e, curiosamente — e você pode achar um pouco contraditório da minha parte — não tive nenhuma experiência concreta (pelo menos não registrada formalmente no meu registro de emprego) que me classificaria como desenvolvedor júnior, pleno ou sênior. Grande parte da experiência que adquiri veio de projetos pessoais e pesquisas na faculdade. Foi um processo gradual até que percebi que minhas habilidades haviam evoluído desde aqueles primeiros dias.

Mas sim, trabalhei intensamente como desenvolvedor em diferentes níveis e tive a oportunidade de conhecer diferentes tipos de profissionais seniores ao longo da minha carreira:

1. O sênior muito competente e eficaz, mas pouco comunicativo, que resolvia problemas sem dar explicações sobre sua abordagem.
2. O aluno do último ano é excelente em comunicação e ensino, mas frequentemente fica sobrecarregado com tarefas urgentes e não tem tempo para ensinar.
3. O veterano que era entusiasmado com a superengenharia e a centralização da tecnologia, mas que cumpria os prazos e entregava o que prometia.

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