Devo ter medo de ser um profissional especialista? E se eu fosse generalista?
No início mês de agosto (2018), dia 4, fiz um treinamento de Kanban com a Ana G. Soares onde, em uma parte do treinamento, ela facilitava um jogo do site getKanban. Nesse jogo, gerenciamos uma equipe fictícia de desenvolvimento de software com o objetivo de entregar o máximo de valor possível num curto espaço de tempo. Assim como na vida real, em alguns momentos tínhamos que decidir entre treinar os membros do time ou contratar novas pessoas especialistas em determinadas atividades. Não vou dar spoiler pra vocês sobre qual a melhor decisão pra ir bem nesta dinâmica do jogo, mas esse treinamento me lembrou de decisões que eu tomei na minha carreira e que agora fazem mais sentido pra mim do que faziam antes.
Eu trabalho com desenvolvimento de software desde 2012 e, de lá até agora, eu já encontrei diversas pessoas que são muito boas em algo, são referências em uma determinada tecnologia ou ferramenta, são especialistas. Eu sempre admirei esse status, mas até agora não me vejo trilhando um caminho onde serei reconhecido como especialista em algo — e tudo bem.
Sou um generalista…
Eu escolhi me esforçar para aprender um pouco de tudo, treinar algumas habilidades diferentes da maioria dos meus colegas. Minha cadeira eletiva da graduação não foi nada relacionada com o meu curso, me matriculei numa cadeira de Oficina de Criatividade do curso de Publicidade e Propaganda, onde eu não conhecia ninguém. Fiz aquilo pra sair da zona de conforto, pra me forçar a falar na frente de pessoas que eu não conhecia — eu lembro que na época eu me perguntava: será que isso aqui não é perda de tempo?
Não foi.
Como diria o Murilo Gun no TEDx dele, “eu desenvolvi habilidades genéricas, habilidades cinto do Batman”. Fazer um curso de Dicção, Oratória e Desinibição fez eu melhorar minha comunicação com as pessoas, a forma como eu coloco minhas ideias e o jeito de me apresentar; O treinamento de Desenvolvimento e Liderança fez eu aprender muito sobre mim mesmo e priorizar os objetivos da minha vida, isso me ajudou a entender as minhas dificuldades e enxergar o porquê da importância de tomar uma atitude pra resolver aquilo. Essas coisas me fizeram um profissional melhor, um solucionador de problemas melhor e - mesmo que não tanto com habilidades técnicas - um desenvolvedor de software melhor.
E falando em habilidades técnicas…
No meio dessa caminhada eu desisti de algumas certificações relacionadas a tecnologias com as quais eu trabalhava. Isso faz parte do jogo, é priorização! Até agora não me arrependi. Talvez eu tenha feito isso por ter medo de ficar rotulado como “Profissional da tecnologia XPTO” (como já fui um dia!), medo de depender financeiramente de um mercado específico, de não me permitir largar essa tecnologia e correr o risco até de afundar com ela — por exemplo, você correria o risco de estudar um framework javascript durante anos pra virar um especialista nele? Eu provavelmente não.
Falando em rótulo, o último que me foi atribuído tecnicamente foi “coringa”, por jogar em várias posições. Eu considero um elogio porque num time multidisciplinar, tenho capacidade pra tocar a maioria das tarefas, mas ao mesmo tempo sei que nem todos jogos são jogados com coringas. Tem situações em que você precisa de um especialista.
Quando digo pra pessoas de RH ou de tecnologia que sou desenvolvedor de software, geralmente a primeira pergunta que me fazem é: “- de quê?”, com o intuito de saber de qual linguagem de programação e qual tecnologia. Minha resposta geralmente é “de software”. Foi o que eu disse na entrevista de emprego na Zenvia, empresa onde trabalho hoje. Independente de tecnologia, meu objetivo é ajudar a resolver um problema e, às vezes, o meio para isso é desenvolvendo software. Ei, mesmo que você seja desenvolvedor, resolver um problema sem implementar sequer uma linha de código pode ser um bom motivo para se orgulhar!
Aliás, considero que uma das melhores decisões da minha carreira foi o desapego de tecnologias na minha última troca de emprego: depois de mais de 5 anos trabalhando com a plataforma .NET, fui trabalhar onde quase tudo era novidade. Aprender outras linguagens de programação e tecnologias me fez ver perspectivas diferentes e entender o que é melhor para cada problema de negócio. A foto abaixo realça bem o impacto da mudança que fiz em 2017.
Depois disso, percebi que a habilidade mais importante que vejo nesse meu momento é a de aprender. Aprender a usar uma nova tecnologia, a ler documentações de ferramentas, a usar um terminal com linhas de comando, a interpretar contextos enxergando seus problemas e desenhar soluções. E como a gente desenvolve essa habilidade? Aprendendo, é óbvio! Praticar o aprendizado, seja do que for, deve fazer parte da nossa rotina. Projetos pessoais, resolver problemas da sociedade ou aceitar freelas geralmente fazem nós, desenvolvedores, evoluirmos consideravelmente nesse aspecto técnico.
Nessa mesma linha de raciocínio, nos últimos anos eu tenho me esforçado mais pra conseguir fazer os especialistas ao meu redor compartilharem seus conhecimentos com outras pessoas do que efetivamente ser um especialista técnico em algo.
Fazer as perguntas certas na hora certa pode ser mais valioso do que programar uma funcionalidade com excelência. Algumas das perguntas que me ajudaram a agregar mais valor do que (ou tanto quanto) codificando, foram:
Estamos fazendo a coisa mais importante pro nosso cliente / usuário / empresa / time / etc? Nem sempre a coisa mais importante é a user story de quem grita mais alto numa priorização. Às vezes a coisa mais importante nem é uma funcionalidade nova ou a correção de um bug. Refatorar o código para nos dar produtividade no futuro tem um grande valor!
Não existe alguma solução mais simples do que essa proposta que agregue valor mais rápido para nosso cliente / usuário? Esse tipo de pergunta nos ajuda a seguir o princípio do KISS (Keep It Simple, Stupid), seja em questão de design geral de uma solução ou de método pequeno que deve fazer uma coisa — e apenas uma. Nos faz pensar também num pilar da agilidade referente a agregar valor o quanto antes.
Nós sabemos todas as tarefas que são necessárias pra realizar essa entrega? Algumas entregas mais complexas podem ter dependências de outros times, outras áreas ou até outras empresas. Ter a visibilidade de tudo que deve ser feito é importante pra estimar a complexidade e mapear possíveis bloqueios nas tarefas. Aliás, as tarefas não são referentes só ao desenvolvimento de software, às vezes é sobre alinhar o que vai ser produzido com a área de marketing para que façam uma campanha daquela entrega. Às vezes é importante ver se alguém vai precisar de treinamento pra utilizar as funcionalidades daquela entrega também.
Enfim, como você já deve ter imaginado quando leu o título, não é necessário ter medo de ser um desenvolvedor especialista. Tanto os especialistas como os generalistas são requisitados no mercado, a minha experiência me disse que, nesses primeiros 8 anos de carreira, focar mais em habilidades generalistas me trouxe vantagens e aprendizados que talvez eu não tivesse se seguisse um caminho de me especializar numa tecnologia XPTO.
E aí, o que achou do texto? Se identificou? Tem alguma sugestão? Tá com alguma dúvida? Escreve aí!
