Os principais mitos da área de tecnologia — Parte 2
Olá!
Continuando o artigo anterior sobre os mitos da área de tecnologia, vamos abordar mais alguns hoje.
Mito 11: Certificações são muito importantes.
Falso.
Quando eu comecei na área (por volta de 2011), o caminho vendido pelos meus professores da faculdade era: fazer uma SAP Academy e conseguir uma certificação e depois ganhar uma tonelada de dinheiro programando em ABAP, fazendo ERP para multinacional. Essa junção de coisas é tudo que eu não quero fazer de maneira alguma na minha carreira hoje em dia.
Hoje em dia nenhum tipo de certificação é mais necessário se você trabalha com desenvolvimento. Ao meu ver, a única área que ainda faz sentido é se você trabalha com infra-estrutura. Mas, com o advento de práticas de DevOps e o aumento do uso de software open source, até isso eu vi decair vertiginosamente ao longo dos anos.
Existe um outro cenário que é útil: consultorias costumam usar profissionais certificados como argumento de venda de vez em quando. De qualquer forma, a esmagadora maioria das pessoas desenvolvedoras que eu conheci (> 90%) não eram certificados e estão ai trabalhando. Os que eram, não me recordo de diferenças salariais significativas.
Em resumo: se é importante para a empresa que você está e você vai conseguir algum retorno imediato em termos salariais, certifique-se. Fora isso não vejo valor em certificados.
Mito 12: É possível ganhar R$ 20.000,00 por mês trabalhando com tecnologia.
Verdadeiro.
É a mesma explicação do mito 7 do artigo anterior. O fator principal é um só: o quanto raro aquele profissional é.
Se você sabe muito de uma stack relevante, manja de Docker, Kubernetes, sistemas distribuídos em profundidade e é capaz de entregar software com boas práticas de qualidade, esse salário não tá muito longe se você tiver próximo a uns 10 anos de experiência como pessoa desenvolvedora (só falta achar a empresa que paga salários competitivos).
Há poucos anos atrás esse salário era impossível para uma pessoa desenvolvedora. A demanda dobrou recentemente. Agora essa remuneração se tornou possível devido a escassez de profissionais.
Mito 13: Na minha máquina funciona.
Verdadeiro, desde que você use Containers.
Eu poderia elaborar um pouco dos problemas que era entregar software sem isso antigamente e como essa desculpa era usada para quase todos os problemas em produção. Mas vou ser mais sucinto: aprenda Docker.
Esse problema de divergência de configuração de ambientes que fazia o sistema funcionar na máquina da pessoa desenvolvedora e quebrar em produção já foi resolvido na indústria com o uso de Containers. Espero que essa frase hoje em dia seja usada somente como piada.
Mito 14: Você não pode ser amigo dos seus liderados.
Depende.
Se você consegue garantir que: o seu julgamento não será afetado ao ter que demitir um amigo verdadeiro por algum problema de performance ou devido a um corte de funcionários e o seu amigo irá aceitar um feedback negativo separando o pessoal do profissional, eu digo que é possível ser amigo do time sim.
Caso você não tenha 100% de certeza de alguns desses pontos, sugiro cautela nessa parte.
Existe uma frase que eu ouvi no motto corporativo de um lugar que eu trabalhei que eu levo até hoje: para ser sério não é necessário ser sisudo. É possível agir com leveza, brincar com o time e afins e mesmo ser assim ser um líder que faz o que é necessário.
Acho que o conceito de Radical Candor reflete bem uma abordagem que mistura pragmatismo com leveza. Recomendo que você estude sobre isso se esse tópico é importante para você de alguma forma (se você está tentando virar gestor(a) ou é recém-promovido(a), por exemplo).
Mito 15: Não é necessário saber soft skills para ser gestor em tecnologia.
Falso, mas muito falso mesmo.
Existe um ciclo nocivo em tecnologia que gostaria de abordar nesse item que eu acredito que seja a causa de algumas pessoas proferirem esse mito com tanta convicção.
Devido ao clubismo típico da área, é capaz de um desenvolvedor passar por todas as cadeiras (de Junior até Gestor, por exemplo) sem precisar de fato exercer algumas habilidades não técnicas, como empatia, alteridade e comunicação não-violenta. Isso se deve porque o gestor que promove esse desenvolvedor provavelmente passou pelo mesmo ciclo e — como acha que soft skills é besteira, afinal ele é gestor sem isso — promove outros "brothers" no processo.
E assim o ciclo de homens despreparados em posições de liderança se perpetua. E eu uso o termo homens me referindo a seres do sexo masculino mesmo e não como sinônimo de humanidade, pois o percentual de mulheres em posições de liderança de tecnologia é de 11% na média global e 16% na América Latina, daqui.
Detalhe: E qual não foi minha surpresa ao conversar com uma coach especializada em gestores de tecnologia, que me informou que a desculpa mais usada ao recusar o serviço dela era o mesmo para 99% deles: eu não preciso de soft skills para ser gerente de tecnologia, pois cheguei onde cheguei sem isso.
Minha critica aqui é simples: olhe de perto o time da pessoa que profere isso. Vai ser um time disfuncional em vários aspectos, além de não ser inclusivo e tudo mais. Um time disfuncional não performa bem, por mais que seus líderes achem que sim.
Se você não acredita em mim, faça a seguinte reflexão: pensa nos piores líderes que você já teve. Agora pensa nos melhores. O que as melhores gestoras e gestores que você teve tinham em comum? Spoiler: era junção de Hard e Soft Skills.
Um(a) líder completo(a) precisa de ambas as habilidades para atender o que o time espera dele(a).
Mito 16: É possível ser gestor em tecnologia somente com Soft Skills.
Falso.
Uma pessoa em posição de liderança que não é técnica sempre gera dois problemas: ela toma decisões ruins com uma frequência alta (o que atrapalha o time no processo e costuma desperdiçar dinheiro junto). E talvez o pior de todos: não consegue obter o respeito do time.
Pessoas desenvolvedoras não respeitam líderes não-técnicos.
O seu time pode até não dizer na sua frente, mas eles irão tomar decisões técnicas sem você porque não podem contar com o seu conhecimento.
Se você se considera uma pessoa não-técnica e é gestor de tecnologia, você pode ser estupendo(a) em gestão, indicadores e técnicas de liderança. Mas no final, o que importa mesmo é se o seu pitaco faz sentido na hora de ajudar a galera a se desenvolver tecnicamente.
Existe uma tendência das pessoas desenvolvedoras a superestimar a importância de hard skills. Isso dura até a pessoa querer alçar degraus mais altos, ai depois a pessoa percebe que precisa de habilidades interpessoais também (geralmente acomete os Seniores que querem virar líderes ou especialistas, por exemplo). Mas, até lá, o que esperam de um gestor é uma referência técnica com uma boa gestão de pessoas.
Acho que essa expectativa de uma base técnica é mais forte se você é líder direto de um time de pessoas desenvolvedoras. Após uma transição para líder de líderes, a importância do técnico acredito que diminua um pouco e as expectativas passam a ser outras (como boas noções de estratégia e negociação).
Mito 17: Soft skills não se aprende.
Depende.
Todo mundo opera em padrões de comportamento. Alguns padrões são naturalmente vistos como algo desejáveis no mundo corporativo (como comunicação, extroversão e um senso de urgência natural que algumas pessoas possuem). Portanto, seria leviano da minha parte dizer que alguns perfis não levam vantagens em relação a outros dadas essas expectativas.
Porém, se você quebrar essa grande amálgama de habilidades interpessoais em partes menores, acredito que seja possível desenvolvê-las sim. Seria até contraditório da minha parte se eu não acreditasse nisso, dado que eu tenho um curso sobre o tema publicado, certo?
Aqui vai uma imagem das habilidades mais valorizadas pelo Mercado que achei no Google, só para ilustrar as mais comuns:
Então, se você precisa escrever melhor, faça um curso de português. Se você precisa falar melhor, faça um curso de oratória. Se você quer saber como priorizar melhor, gestão de tempo. Liderança? Tem curso disso. Negociação? Idem. Uma junção de tudo isso pensado no mundo digital? Meu curso!
O único complemento aqui é que eu vejo que existe uma habilidade que não é possível aprender em curso, mas que técnica nenhuma vai te salvar se você não tiver essa (e eu também não consigo ensinar isso nos materiais que produzo): Que é se importar genuinamente com as pessoas.
Acredito que essa frase expresse bem meu complemento a essa questão:
Pensamentos conduzem a sentimentos. Sentimentos conduzem a ações. Ações conduzem a resultados. (T. Harv Eker)
O que você pensa é como você age. Se você despreza sua equipe, isso irá submergir. Se você odeia seu chefe, idem. Se você não está feliz onde está, também. Você nunca será um líder de fato tendo uma essência egoísta, por exemplo. Ainda bem, imagine se pessoas ruins sempre saíssem impunes ou virassem políticos?
Se você quer evoluir nesse ponto rápido, meu conselho é: trabalhe suas crenças fundamentais sobre pessoas, relações de poder e afins. Em outros termos: o melhor curso de soft skills que eu conheço passa por autoconhecimento falando com um terapeuta, não em cursos.
Mas você pode comprar o meu curso mesmo assim se quiser para apoiar o meu trabalho, ok? obrigado! =)
Mito 18: Testar atrasa a entrega.
Falso.
Também encontrada na versão: Vamos entregar a feature primeiro, testes a gente vê depois.
É possível argumentar a favor de testes de diversas formas. Porém, vou usar o argumento econômico aqui ao invés do argumento de qualidade (que curiosamente não costuma fazer muito efeito, porque muita gente simplesmente não se importa com qualidade, infelizmente).
Imagine que você dê manutenção em um sistema web qualquer que não possui testes de unidade implementados. No ciclo de fazer uma alteração, compilar o código, subir o sistema manualmente e navegar até a tela para ver a alteração, você leva, em média, de 5 até 10 minutos.
Agora, multiplique isso pela quantidade de vezes que você faz isso para uma única feature e você terá o custo de desenvolvimento daquela funcionalidade em horas, certo?
Contando um dia típico de uma pessoa desenvolvedora, dá umas 3 horas por dia gasta nesse ciclo (em uma estimativa conservadora) e que a empresa possui 30 pessoas fazendo isso (o que nem é uma equipe tão grande assim).
3 horas/dia por pessoa x 30 pessoas x 22 dias úteis no mês = 1980 horas.
Assumindo que a média da hora de uma pessoa desenvolvedora é 50 reais, dá R$ 99.000,00 de custo esse processo de desenvolvimento, por mês. Desconsidere o tempo gasto com as outras 5 horas das pessoas desenvolvedoras aqui, que podem ser gastar em outras coisas. Eu nem considerei o custo de interrupções (que eu já abordei aqui) e nem o custo da correção dos bugs gerados por esse processo sem testes.
Agora, imagine que essa mesma equipe implementou testes de unidade nesse sistema, é que elas conseguem realizar o mesmo ciclo de checagem de funcionalidades rodando uma suite de testes que roda em 1 minuto, por exemplo (o que é uma suíte bem lerda, inclusive). Uma suíte de testes bem feita roda em 500ms e olhe lá (e melhor: ela roda verificando o sistema inteiro e não somente a classe que você tá mexendo naquela hora, por exemplo). Aqui tem um valor intangível: testes avisam se você quebrar uma outra parte do sistema sem custo adicional. E isso aumenta muito o grau de confiança na hora de fazer alterações sem medo, o que inclui pessoas menos experientes ao time com mais facilidade.
Mas, voltando aos números. Agora a conta fica simples: 1 hora por dia x 30 pessoas x 22 dias úteis = 660 horas. 660 horas x 50 reais = R$ 33.000.
33000/99000 = 33,33% do tempo original.
Redução de 66% de custo recorrente em troca de um investimento de alguns dias ou semanas gastos implementando testes de unidade. Mesmo que você gaste muito tempo implementando testes (o que acaba não acontecendo), ainda sim valerá a pena do ponto de vista econômico, sempre. A explicação vem a seguir.
O maior custo de um sistema está na manutenção. Você escreve código uma vez e lê centenas ou milhares de vezes. Por isso que boa parte das práticas de melhoria de manutenção se pagam ao longo do tempo. Eu já vi vários valores para o custo de manutenção, de 40% até 90% do custo total do ciclo de vida do software, por exemplo. A literatura clássica diz que a manutenção pode variar entre 2x até 100x o custo de desenvolvimento. Como complemento, acho que vale mencionar o custo da entropia também, que você encontra aqui.
Portanto, a mensagem é: escrever testes compensa.
Mito 19: Está pronto, só falta testar.
Falso.
Se está faltando testes, não está pronto, pois eu espero que tenha ficado claro a importância de testes se você leu até aqui.
A recomendação aqui para reduzir a quantidade de vezes que as pessoas falam essa frase vem da agilidade: implementar um critério claro e objetivo do que é estar pronto, chamada DoD (Definition of Done).
Para cada tarefa do time, experimente discutir claramente o DoD, você verá que essa frase não será mais proferida com tanta frequência.
Mito 20: É possível estimar prazo de entrega.
Depende.
Seres humanos são ruins em estimar com precisão a quantidade de horas, por exemplo. Portanto, toda e qualquer estimativa sem técnica é um chute sofisticado e só. Existem algumas técnicas que se utilizam de pontos e não são muito confiáveis como análise de ponto de função e story points (técnica criada por Ron Jeffries, signatário do manifesto ágil, que ele mesmo disse que foi um erro, mais detalhes aqui).
Porém, para fornecer uma técnica útil, recomendo o seguinte algoritmo para resolver esse problema: reúna a quantidade de cards entregues do time por período de tempo desejado (nesse caso, vou usar uma sprint de 2 semanas).
Faça isso para umas 6 iterações e você já terá uma média de cards entregue por sprint, por exemplo. Mantendo o mesmo método de quebra de tarefas sendo feito entre sprints, você sabe que um time de 5 pessoas entrega 10 tarefas a cada 2 semanas (uma média de 2 tarefas por pessoa, por sprint).
Com essa informação, chegou um projeto novo na sua squad. Após a quebra de tarefas, o resultado foi 40 tarefas no backlog. Qual o prazo de entrega com uma relativa confiança para essa quantidade de tarefas? Ceteris paribus, 4 sprints.
Pronto, você deu uma estimativa baseada em uma técnica estatística correta ao invés de um chute puro e simples (e não gastou tempo na planning estimando com pontos). Estatística é melhor que chute, pelo menos.
O legal dessa técnica é quanto mais o tempo passa, mais precisa ela fica, pois quanto mais dados, menor a incerteza.
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
