Já escrevi alguns artigos sobre desenvolvimento profissional e carreira em TI. Se ainda não os leu e está preocupado com sua carreira em desenvolvimento ou em conseguir um emprego mais desafiador, sugiro fortemente a leitura. Veja alguns abaixo:
- Desafios na carreira de um desenvolvedor
- Um guia prático para passar em entrevistas para desenvolvedor de software
- Um guia para você conseguir um bom emprego como desenvolvedor de software
Entretanto, um leitor me fez alguns questionamentos bem interessantes, praticamente um desafio:
O que fazer se essas dicas forem seguidas, mas ainda assim tudo der errado? E se o profissional se prepara bastante, mas no fim falha nas entrevistas de emprego? E se, apesar de bastante esforço, o profissional não for respeitado e reconhecido pelos seus colegas e líderes?
Sinceramente não estou à altura para dar uma resposta definitiva para situações como essas. Provavelmente nunca estarei. Particularmente creio que cada situação que passamos na vida tem um propósito bem definido e particular. Não é possível generalizar.
Entretanto, o que posso fazer é compartilhar como superei alguns de meus fracassos e como eles claramente contribuíram para futuras empreitadas de sucesso.
Projeto fracassado
Há alguns anos fui designado para um projeto do maior cliente da empresa onde trabalhava. Estava tudo atrasado e com diversos problemas crônicos. O projeto estava sofrendo de um fenômeno chamado scope creep, isto é, quando os requisitos vão mudando descontroladamente ao longo do tempo e torna-se impossível chegar ao fim. O cliente mudava de opinião a todo momento, pois não havia um único responsável pelos requisitos nem clareza das necessidades de cada um dos stakeholders.
Além disso, o cliente designou alguns gerentes para acompanhar o projeto, que me ligavam e mandavam e-mails várias vezes por dia. Foi num desses dias a primeira e única vez que perdi a paciência com alguém no trabalho. E quem me conhece deve imaginar o que seria necessário para fazer isso! 😀
Após alguns meses, novos projetos iam começando e os outros membros da equipe começavam a “pular para outros barcos”, até que chegou o momento em que eu era o único técnico responsável. O próprio analista de negócios, responsável pelo entendimento das regras de negócio mais complexas, foi para outro projeto, deixando-me como o único responsável dentro da empresa. O problema é que eu não tinha o conhecimento necessário sobre leis, regulamentações e contabilidade para atender corretamente as demandas do cliente.
Mas em tudo isso ainda não residia o problema principal: eu sabia que o projeto ia fracassar. Muita gente sabia, mas ninguém, inclusive eu, fez nada até ser muito tarde.
Um dia chamei o CEO da empresa para um versa e coloquei tudo em pratos limpos. Ele já sabia que havia problemas e também não tinha tomado alguma atitude drástica. Mas nesse dia eu simplesmente cheguei e disse: “não vamos entregar o projeto“. Ele tomou algumas poucas atitudes, nada drástico. O projeto andou melhor por pouco tempo, até que saí de férias. Quando retornei, para minha surpresa, o projeto havia sido cancelado. Um misto de fracasso e alívio.
No entanto, apesar do que provavelmente você está pensando agora, não colocarei de forma alguma a culpa em minha liderança, colegas ou no cliente. Embora atitudes gerenciais drásticas pudessem ter sido tomadas, o desenvolvedor, aquele que executa o trabalho e vê a situação mais de perto, poderia ter tomado uma atitude mais contundente com relação a tudo isso.
Nós, desenvolvedores, somos os responsáveis finais pelos requisitos. O cliente tem necessidades. Analistas podem traduzir as necessidades do cliente em requisitos de negócio. Mas somente desenvolvedores tem a capacidade técnica necessária para analisar se os requisitos de negócio estão claros o suficiente, se há viabilidade técnica de implementação.
Em suma: eu devia ter “batido o pé” e exigido as informações necessárias para a conclusão do projeto. Mas, pelo contrário, eu acabei entrando no jogo de fazer e refazer o trabalho para agradar ao cliente, sabendo que inevitavelmente o cliente teria que aceitar um sistema que não atendia suas necessidades ou, como ocorreu, cancelar o projeto.
É comum requisitos mudarem, mas quando isto ocorre, é tarefa do desenvolvedor ou analista técnico informar o impacto a quem pede a mudança. Mas, para tentar agradar o cliente ou os interessados, nós muitos vezes assumimos riscos que não conseguiremos arcar. Começamos a remendar o sistema, tapando buracos aqui e ali, pensando que isso vai sanar o problema. Desenvolvemos certas funcionalidades sem clareza e com várias incertezas, pensando que depois será fácil fazer só alguns ajustes. Só para percebermos que tudo vai estourar no pior momento possível, em cima da data de entrega, quando nada estará realmente funcionando.
Desenvolvedores e gerentes maduros não devem ficar correndo através de folhas ao vento sem nunca alcançar o objetivo. Provavelmente eu não teria maturidade suficiente na época, mas a única atitude sã teria sido refazer um reboot quase total do projeto. Ter a coragem de voltar aos requisitos e refazê-los corretamente, sem remendos. Se o cliente não gostasse, então que fosse tudo cancelado meses antes do barco afundar.
Fica a lição. Ao ver o barco afundando, calcule se há tempo de consertar as estruturas do navio, nem que tenha de voltar à mesa de projeto. Em caso negativo, não fique tocando violino até a água alcançar você. Pule fora o mais rápido possível.
Entrevista fracassada
Há poucos anos fiz uma entrevista para uma vaga internacional, muito difícil, para trabalhar nos Estados Unidos, numa das maiores empresas de TI do mundo. Conseguir tal emprego era como ganhar na loteria, só que não dependia tanto da sorte. 🙂
Fiz todo o processo, passei por diversas fases de entrevistas técnicas que abordaram temas desde design de sistemas, arquitetura, desafios de programação e regras de negócio. Tudo em Inglês.
Cheguei à última fase, mas em minha opinião com desempenho mediano. Não fui chamado. É claro que eles não iriam oferecer uma daquelas vagas para um desempenho mediano.
Além de falar Inglês mal, pisei na bola algumas vezes. Um dos casos foi quando o entrevistador pediu para eu escrever o código de uma fila (FIFO). Por uma série de razões, me distraí e acabei fazendo uma pilha (FILO).
Foi um grande choque na época. Choque por ter sido chamado para fazer uma entrevista de nível tão alto, no estilo do Google. Choque por ter conseguido ir tão longe. Choque por não ter sido chamado depois de passar por tudo.
Mas tudo isso me mudou completamente por dentro.
Primeiro, isso abriu novas possibilidades. Saber que existem empresas assim, profissionais de altíssimo nível, recrutadores procurando por talentos. Por um lado nós ouvimos histórias sobre isso, por outro achamos que está sempre longe do nosso alcance.
Segundo, isso me deu um objetivo a ser alcançado. Conhecendo o nível da entrevista, pude ter uma melhor visão de como “chegar lá”. Desde então, comecei a estudar e me aprofundar nos pontos mais fracos. Antes disso eu gostava de estudar e aprender, mas não tinha foco definido para uma carreira específica.
Terceiro, cada falha que lembro de ter cometido ficou gravada em minha mente. Algumas vezes, num momento de tranquilidade, no banho ou na estrada, me peguei repassando várias situações e pensando em como poderia ter sido diferente.
Não iria repetir os mesmos erros!
Com tudo isso em mente, as novas situações da vida ganharam uma nova perspectiva. Por exemplo, a partir de agora, quando estudo uma tecnologia nova, coisa que faço ora por necessidade ora por hobby, eu já considero como aquilo se encaixa num cenário mais amplo, isto é, na prática profissional, além do que aquilo vai agregar para o perfil profissional que desejo alcançar.
O resultado é que, pouco mais de um ano depois, consegui atingir um dos meus objetivos, que é o de passar numa entrevista do mesmo nível da que fracassei anteriormente (acompanhe o Blog por um tempo se quiser saber mais detalhes).
Eu não teria passado na segunda entrevista, caso não tivesse falhado na primeira.
Considerações
Neste artigo, expus duas situações onde passei por apuros e decepções. Ao mesmo tempo, tentei mostrar como elas me fizeram um profissional melhor.
Vou exemplificar essa realidade com um gráfico ilustrando o conhecimento pelo tempo, destacando como um fracasso passado foi essencial para meu amadurecimento profissional e sucesso futuro:
As principais conclusões a que posso chegar são:
- Não tenha medo de fracassar. Não falta em entrevistas, exames e outros por medo.
- Aproveite a experiências e até a vergonha da derrota para não repetir mais os mesmos erros.
