Por que alguns profissionais de TI adquirem experiência mais rapidamente?

Post esclarecedor, de autoria de Paulo Farias, publicado por aqui de forma integral a partir do iMasters.

Um profissional de TI experiente é alguém que tem excelência em tudo que faz. É alguém capaz de tomar decisões rapidamente, entender um problema, intuir e agir produzindo um resultado muito bom sem demandar um grande esforço. Parece algo inato e difícil de conseguir, mas na realidade não é. Os mais experientes têm uma postura e método diferentes daqueles que evoluem muito pouco e não sabem o porquê.

A experiência em si é a presença do profissional em várias situações do trabalho: crises de infraestrutura, negociações com fornecedores, problemas com prazo e escopo de projetos, clientes problemáticos, quedas de performance, bugs de software, problemas de requisitos, etc. O contato com esses objetos e as suas representações na nossa mente é que determinam a experiência. A experiência proporciona informações que podem nos fazer melhorar. Podem porque não necessariamente nos fazem melhorar. Para melhorarmos, esta deve ser acompanhada por algo que nos torne excelente. Algo que dependa exclusivamente do profissional. Quando pensamos após uma experiência, estocamos mais um episódio da nossa vida. A sua análise crítica permite o estoque de novos conhecimentos. Ficamos assim mais sábios. Mais na frente, diante de uma experiência semelhante, sacamos o episódio e todo o conhecimento resultante da crítica, e o aplicamos da melhor forma possível diante da situação.

Há algum tempo, enviei uma comunicação sobre uma mudança num sistema que afetaria um cliente. O conteúdo descrevia o que estava sendo feito para minimizar os riscos. Sem perceber, mencionei as ações a serem feitas a posteriori e recebi uma resposta agradecendo pela antecipação aos problemas. A palavra “antecipação” ficou gravada na minha memória e literalmente “caiu a ficha”. Percebi que sempre explicitar nas comunicações os próximos passos, mesmo que replanejados no futuro, aumenta a percepção de controle de uma melhor gestão. Pois a atividade parece ser conduzida por alguém com uma maior bagagem, alguém mais experiente. Guardei esta técnica e atualmente faço isso sem perceber em todas as minhas comunicações. Ou seja, a experiência só foi útil porque decidi mudar e explorar a forma da minha comunicação.

Os profissionais experientes utilizam o dia-a-dia para explorar ao máximo as suas experiências. Por exemplo, durante um problema na performance de um banco de dados, um técnico interage com uma solução de storage. Este poderia resolver o problema acionando o fornecedor – previsto em contrato – sem explorar o que aconteceu em detalhes. Mas pode aproveitar a oportunidade para entender o problema técnico e todos os conceitos, comparar com outras soluções, identificar problemas semelhantes em outro hardware. Pode também explorar os eventos da ocorrência tais como o tempo de identificação do problema, a cortesia no atendimento, o SLA, etc. A crítica da técnica e do episódio podem ser tão detalhadas e aprofundadas quanto se queira, e quanto mais se explora, mais conhecimento profissional se adquire. A crítica do episódio, sequência de eventos,  tem um outro produto: o contexto.

O contexto de uma determinado episódio é o conjunto de todas as circunstâncias que o cercam. É, por exemplo, o fato de o cliente ter razão ou não, ou se está apenas argumentando; é entender que existe uma questão política; é perceber que o problema é de definição e não de execução ou admitir que você está errado e se posicionar como tal. O profissional experiente entende melhor o contexto e o seu curso de ação é baseado neste entendimento. Por exemplo, a comunicação detalhada das causas raízes de um problema de infraestrutura se aplica dentro de TI, mas o bom senso recomenda reduzir o volume de informações para comunicações externas a TI. Nesse caso, vale a regra: quanto menos informação, melhor. Pois o cliente interno desconhece a tecnologia e provavelmente qualquer crítica será destrutiva e só amplificará o problema. O que é adequado para um contexto, pode não ser para outro. Capturar esses nuances não é tarefa fácil e requer muita análise crítica e comparação com conceitos existentes.

Os profissionais experientes entendem melhor todas as variantes da mesma situação e as associam aos conceitos. Problemas são associados a gestão de crises e análise de causa raiz. Quedas de performance são associadas a plano de capacidade, SLA e equipes de alta performance. Problemas de projetos são associados a gestão de escopo, a gestão de prazo e custos. É sempre possível associar alguma situação a um conceito e resgatá-la no futuro. A associação com o conceito permite uma comparação entre as melhores práticas e a ação. O profissional experiente faz isso num piscar de olhos, resgatando os seus antigos episódios e conceitos relacionados.

Podemos concluir que um profissional de TI experiente não é necessariamente alguém “velho” pois a experiência vem muito mais da reflexão do que da kilometragem. Este parece possuir um estoque de conhecimentos interminável pois está sempre aprendendo com todas as situações. Explora a técnica em detalhes ao mesmo tempo que determina o contexto de cada situação de trabalho. Mentalmente associa as situações aos conceitos e os desvios desses batimentos determinam as suas ações. Lê bastante mas entende que a leitura por si só não é origem do conhecimento mas somente a reflexão sobre o que lê e a sua utilização prática faz dele um pessoa mais experiente.

Afinal, o que seria um profissional sênior?

Mais um post sobre o embate “Currículo, Certificações, Siglas X Experiência na área”. Ficam meus parabéns ao Emerson Macedo pelo conteúdo. Retirado do Codificando.com.

Certo dia um amigo com alguns bons anos de experiência e trabalhando na função de pleno, achou que era a hora de mudar de cargo para sênior. Chegando no seu gerênte, recebeu a seguinte resposta: “fulano, não posso te passar pra sênior porque você não conhece o framework xyz e a lingaugem abc“. Esse meu amigo chegou perto de mim bem cabisbaixo e me contou o que tinha acontecido. Simplesmente achei o fato ridículo. Talvez ele realmente não fosse o momento de se tornar sênior (i.e. em relação ao cargo), mas esse argumento realmente não cola.

Como já mencionei em outros posts nesse mesmo blog, nossa área de desenvolvimento de software/informática está cheia de termos/nomenclatura que se confundem facilmente (e.g. as discussões no GUJ sobre DTO). Mais uma vez, falarei sobre um deles: a classificação júnior, pleno, sênior.

Dando uma passeada pelos sites de emprego de informática, é fácil ver vagas para analista de sistemas / programador / desenvolvedor júnior, pleno e sênior, etc. Acontece que a maioria das pessoas (inclusive os gerêntes de TI) não sabem muito bem fazer essa distinção entre os níveis, causando uma grande confusão na cabeça de todo mundo, inclusive na hora de negociar o cascalho. Portanto, vamos começar pelo básico …

Master Yoda

Não sou uma pessoa entendida de RH, muito menos sei a história sobre como começou essa nomenclatura de júnior, pleno e sênior. Mas como trabalho na área de TI fazem 12 anos e já passei por um bocado de empresas, acho que posso dar meu pitaco sobre o assunto. As melhores definições que consegui na internet para sênior foram: ancião, velho, pessoa com mais experiência em alguma profissão. De cara tem alguma coisa estranha na resposta que o tal gerente deu pro meu amigo, mas não para por ai.

No início da minha carreira, nas empresas onde passei, geralmente o cara sênior era um cara com mais experiência, uma pessoa que viveu mais situações, uma pessoa mais madura (não necessáriamente velha ou idosa). Por muitas vezes, essa pessoa não conhecia uma ferramenta ou outra de trabalho que eu conhecia, mas isso de maneira alguma me colocava no mesmo nível daquele profissional, pois tomando conhecimento da existência daquela ferramenta e utilizando um pouco do seu tempo, a tal ferramenta estava absorvida por este.

E o que eu quero dizer com isso? Eu quero dizer que se você começou agora, mesmo que você saiba python, ruby, java, erlang, haskell, xpto, brainfuck, você é Júnior ainda. Lógico que é ótimo saber diversas ferramentas e eu recomendo a todos estudar para isso. O mesmo princípio se aplica ao profissional sênior. Fatalmente tem algumas coisas que lhe fogem ao conhecimento, porém a diferência é que esse naturalmente conhece muitas ferramentas  devido a sua experiência ao longo dos anos. Não foi simplesmente um livro que leu ou um tutorial da internet que fez, mas projetos reais que participou. Um sênior deve saber debater com seus superiores sem medo, com argumentações bem formuladas, sabendo exatamente a sua posição, mas sem muito se intimidar quando conversa com outro profissional acima na hierarquia. Deve chamar a responsabilidade para si em momentos críticos, deve ajudar e ensinar os demais simplesmente porque isso é de sua responsabilidade.

Saber ou não uma determinada linguagem ou ferramenta não faz necessáriamente de você nem júnior nem sênior, pois isso as vezes depende da sua trajetória de carreira. Eu por exemplo não sei nada de ABAP, pois nunca trabalhei com SAP ou algo que use essa linguagem. Talvez você esteja aprendendo Java nesse momento mas tem 10 anos de experiência com C/C++ e tem ótimas práticas de programação. Em fim, é bem relativo.

Pra finalizar, certa vez um amigo me disse que sênioridade é algo como um estado de espírito. Vou até um pouco além disso. Acredito que sêrionidade é um estado avançado de profissionalismo aliado a maturidade alcançada ao longo do tempo.