O que eu penso sobre “Júnior”, “Pleno” e “Sênior”

Vocês já pararam alguma vez para pensar sobre o significado da classificação “Júnior-Pleno-Sênior”? Eu já. Diversas vezes. Quando comecei a dar atenção a ela, percebi que era muito comum, naqueles anúncios-padrão de vagas de TI, a definição baseada EXCLUSIVAMENTE em tempo de experiência: júnior (até 2 anos de experiência), pleno (de 2 a 4), sênior (acima de 4 anos). Simples assim.

Nem preciso perder muito tempo para dizer que a classificação acima é limitada demais, para não dizer péssima. Qual a diferença precisa entre um profissional com 3 anos e 11 meses de experiência e um profissional com 4 anos?

Para tentarmos entender o que significam esses três níveis de experiência, precisamos entender primeiro o que é experiência:

“Ação ou efeito de experimentar; conhecimento adquirido pela prática da observação ou exercício”. Ou ainda “Empirismo, prática de vida, ensaio”.

Sendo assim, “júnior” tem pouca experiência, “pleno” tem boa experiência e “sênior” tem bastante experiência. Agora, sem um intervalo bonito de tempo, fica bem mais complicado, não é?

Vou explicar com mais detalhes. Mas atenção: isso não é uma tentativa de definir exatamente cada um dos níveis. Não é algo objetivo assim, mas dá para se ter boa ideia.

Júnior
– Executa, mas muitas vezes sem saber o “porquê” das coisas.
– Segue, na maioria das vezes, algum código de exemplo ou o que lhe é passado por alguém de mais experiência.
– Aceita o que o cliente pede, sem questionar, propor alternativas ou identificar possíveis impactos negativos.
– Tem mais dificuldade em entender o problema e conceber uma solução do início ao fim (tanto em nível de funcionalidade como em nível de software).

Pleno
– Entende melhor o “porquê” das coisas e por isso já consegue propor outras alternativas além daquelas passadas por outros de mesma ou maior experiência.
– Consegue conversar melhor com o cliente, propondo soluções ao invés de aceitar o “como” vindo do cliente.
– Como o nome sugere, faz o trabalho em sua “plenitude”, ou seja, entende o problema e consegue implementar a solução do início ao fim.

Sênior
Além do que foi mencionado para o “Pleno”, ele:
– Entende e aplica boas práticas, princípios e técnicas com o objetivo de produzir soluções de maior qualidade (externa e interna), preocupando-se também com requisitos não-funcionais.
– Consegue analisar o “todo” do projeto, ou seja, preocupa-se também com a estratégia e não somente com a tática.
– Repassa o conhecimento aos demais membros do time.

Para complementar os itens acima, vale a pena dar uma lida no conceito Shuhari, vindo das artes marciais, e o Modelo Dreyfus de aquisição de habilidades.

Vamos considerar alguns fatores importantes:

1. A evolução de um nível para outro não está associada simplesmente à técnica da pessoa e sim à sua maturidade como indivíduo. Então, como dito no início deste artigo, o tempo de experiência é sim importante, pois nós, seres humanos, não nascemos prontos. Precisamos passar por experiências negativas e positivas para aprender.

2. Quanto tempo para passar de um nível para outro? Depende de cada um. O fato é que acho bastante improvável, para não dizer impossível, que alguém atinja um nível de maturidade e evolua tão rápido em pouco tempo de experiência. Por isso, me dá arrepios ver no LinkedIn alguns “desenvolvedores sênior” ou “arquitetos de ….” com poucos anos de estrada, com 1 ou 2 softwares desenvolvidos na vida. Sendo assim, é preciso cicatrizes de guerra, ter errado muitas vezes, ter feito de formas diferentes e, é claro, ter tirado lições de tudo isso.

3. Assim como classificar meramente por tempo de experiência, também é bizarro classificar apenas por quantidade de “skills” técnicas e cursos/certificações. Fulano é “sênior” e Beltrano é “pleno” somente porque Fulano tem 2 pós-graduações e Beltrano nenhuma? Mais uma vez: depende! Depende de outras “skills” que eles tiverem. Depende de todos os pontos citados anteriormente.

CONCLUINDO (OU COMPLICANDO TUDO)

Como empresas trabalham com tecnologias, práticas e métodos diferentes e, portanto, possuem níveis de exigência diferentes, não é certo afirmar que um pleno da empresa X será também pleno na empresa Y.

Em casos extremos, é realmente mais simples. Um júnior com apenas 6 meses ou 1 ano de experiência, certamente será júnior em qualquer lugar. Mas e um pleno ou sênior?

Enfim, esse assunto rende muita discussão e é possível que eu revisite-o futuramente. Espero, ao menos, ter deixado claro alguns pontos que definem cada nível e como é impossível manter um padrão de mercado para eles.

31 comentários em “O que eu penso sobre “Júnior”, “Pleno” e “Sênior”

Adicione o seu

  1. Parabéns! Muito bacana seu artigo e isso toca profundamente em muitas seleções. A questão provoca reflexões e devemos considerar que estas classificações são oriundas de gestão de RH/Administração. Algumas agências já tem um entendimento que júnior, pleno e sênior referem-se a, respectivamente, a) quem precisa de acompanhamento e orientação; b) quem tem auto capacidade de resolubilidade, mas que não coordena ou difunde o conhecimento e c) quem tem o domínio técnico da área e é a referência para a equipe. Casa muito bem com os questionamentos e conclusões apresentados no seu artigo. Então pode-se até fazer sentido um grupo júnior selecionando um pleno, mas será que faz sentido na seleção de um sênior ? Eu, particularmente, entendo que a seleção deva ser para quem não tem experiência (júnior) e para quem tem experiência (pleno). Uma vez que o profissional mostrou num determinado período que ele pode assumir novas responsabilidades num projeto ou perante uma equipe, ele pode mudar de categoria (e seria justo enquadrar nos respectivos direitos e deveres). Para a seleção de um sênior, deve-se considerar a experiência em gestão de equipes e da área a que se pretende atuar.

    Curtir

    1. Obrigado por comentar, Peralta!
      Agregou bastante ao post!

      Realmente, está cada vez mais dificil encontrar um cara pra entrar já como sênior. Precisamos formar mais, pq tá dificil no mercado.

      []s

      Curtir

  2. Concordo contigo. Não considero possível alguém ser especialista (sênior) em qualquer coisa sem ter passado ao menos uns 10 anos batendo cabeça com aquilo. Não sei de onde tiram que 4 anos é suficiente para ser sênior. Devem estar querendo aumentar o número de “seniors” na empresa na base da maquiagem. E não bastar ter tempo de prática, tem que ter vivido diferentes experiências nesse período. Estou cansado de ver “sêniors” com 1 ano de experiência repetido quase que inalteradamente por 10, 15, 20 anos de vida, totalmente parados no tempo, desatualizados, e sendo tratados como gurus da tecnologia. E o resultado disso só pode ser um: soluções que já nascem obsoletas.

    Curtir

    1. Pois é, cara. Essa é uma das aberrações de se considerar apenas o tempo. Podemos ter um sênior totalmente estagnado no tempo.

      E maracutaia tem em todo lugar né. Nem citei no post pra não fugir do propósito. Nunca vi de perto mas não duvido que consultorias vendam a rodo sr/pl que, na prática, são apenas jr.

      []s

      Curtir

  3. É rapaz, esse assunto é polêmico. Sempre penso nisso, como proceder perante essas exigências sem embasamento do mercado. Sou contra achar que o cara precisar ser um ancião para ser um sênior, mas também sou contra cara que acabou de sair da faculdade ou terminou o 1º software e já acha que é o rei da cocada preta. Lembro uma vez que você estava selecionando uns curriculus, e estava com um malandro que tinha saído 2 anos da faculdade e já almejava ser gerente de projetos. Cara nem saiu das fraldas e já queria ser “J”erentes. O cara já começou errado em querer ser “J”erente ehehehehhehe. Isso além de ser uma guerra entre gerações, o mercado também bota pilha errada. Conheci pessoas “juniores” que manjam de construção tanto de hardware quanto de software, muito mais que caras que estão aí no mercado há anos.

    Curtir

  4. Gostei da sua visão sobre o assunto! Muito bem redigido o texto também, de passagem.
    No meu ponto de vista, esta “classificação” está totalmente voltada para a empresa e deve se basear no que o individuo vai oferecer a mesma.

    Realmente, um cara sênior em .Net em uma empresa “X”, pode não se dar “tão” bem na empresa “Y” a ponto de ser considerado Sênior.

    Veja: se uma empresa não possui nenhum cara sênior, e entra uma pessoa que até conhece bem a tecnologia, tem certa experiência, e conhece muito mais do que qualquer um que está na empresa, teoricamente, ele é sênior lá. Mas em outra empresa onde devs possuem um alto conhecimento, anos de experiência, etc etc etc, ele não seria sênior. certo?! depende, certo?!

    Abs

    Curtir

    1. Olá, Rafael. Obrigado pelos elogios.

      É por aí. O cara pode até ter uma ‘rodagem’, já ter desenvolvido vários projetos mas desconhece qualquer prática ágil (que o time já utiliza). Entra como pleno mesmo assim? Depende. Teria que testar o cara, conhecer melhor o trabalho dele.

      Costumamos fazer algumas entrevistas com o time e até trazer o cara pra trabalhar junto por umas horas/dias, dependendo do interesse/disponibilidade da pessoa.

      []s

      Curtir

  5. Eu acredito que o grande mal e o maior causador dessa bagunça de níveis são as consultorias do tipo BodyShop (outsourcing).

    Pois estas consultorias alocam recursos de nível Jr mas são repassados e cobrados ($) como sênior para o cliente.

    Nessa o desenvolvedor assume o nível que ele foi vendido e dali pra frente ele é sênior…

    Se perguntar sobre OOP, SOLID, TDD, qq coisa desse nível (básico) o sênior não conhece nada disso.

    É uma tristeza sem fim, eu quero contratar um pleno mas tenho que anunciar vaga de sênior, pq não existe mais plenos no mercado.

    Curtir

    1. Pois é, cara. Foi o que eu disse em comentário anterior. Nem entrei nessa questão das maracutaias.

      Mas se ele foi ‘vendido como’ senior e for pra outra empresa (mesmo achando que é senior) deve ser avaliado pela mesma, podendo não se enquadrar mais nesse nível.

      O problema maior é a vaidade (e falta de noção). O cara acaba não aceitando, ao seu ver, ser “rebaixado”.

      []s e valeu por comentar.

      Curtir

  6. Aquele lance de que o cara tem que ter 10 mil horas de práticas pra ser sênior está errado, foi mal entendido. São 10 mil horas de prática deliberada. E não são necessariamente 10 mil, na minha opinião. Varia de pessoa pra pessoa.
    Eu já escrevi sobre isso no passado, concordo com quase tudo que você disse. O sênior tem que ter vivido e resolvido problemas. Além de tocar de ouvido, ele, ao ver um problema, sabe como resolve, ou sabe como descobrir. E rápido.
    O que o Jr faz em uma semana o pleno pode fazer em um dia. O que o sênior faz em um dia, talvez o pleno não faça nunca (até chegar ao mesmo nível, ao menos). Há uma grande diferença entre um bom jogador de bairro e um jogador da primeira divisão.

    Curtir

  7. Muito bom post Robson Castilho! Concordo com seu ponto de vista e suas colocações. E para colocar um pouquinho mais de lenha na fogueira penso que essa classificação deveria ser proporcional ao retorno e comprometimento que o profissional oferece para a empresa, após um tempo acordado claro.

    Curtir

    1. Obrigado, Desirée 🙂
      Concordo. São pontos importantes e que fazem parte do processo de maturidade, como responsabilidade. Outro fator importante é o alinhamento do profissional com a cultura e valores da empresa. Se ele estiver desalinhado com seu time e com a empresa, é bem improvável que vá conseguir progredir na carreira. Pelo contrário, pode acabar tendo que trocar de empresa.

      Curtir

  8. Por que precisamos classificar as pessoas em Júnior, Pleno e Sênior?
    É mesmo necessário fazer essas discriminação?
    Se a classificação é tão subjetiva, a quem interessa que ela exista?

    Qual modelo de gestão de beneficia deste tipo de classificação?
    Quais são as consequências no comportamento das pessoas quanto utilizamos esses rótulos?

    Um profissional sênior de uma determinada empresa, que atende determinados clientes, que trabalha com determinadas tecnologias e numa determina equipe, também seria sênior em outro contexto?

    Por que o salário é determinado com base nessas classificações se elas não garantem resultados por si mesmas?
    Se o trabalho é mais coletivo do que individual nos dias de hoje, por que ainda temos classificações individuais e não coletivas?

    Curtir

    1. Olá, Matheus

      Pela (maldita, diga-se de passagem) CLT, não é permitido pessoas com salários diferentes no mesmo cargo. Mas não vejo esta como a principal justificativa e sim o fato que nós, seres humanos, naturalmente nos classificamos (e classificamos “coisas”). Como saber em qual nível se encontra uma pessoa sem dar um nome pra isso? Poderia ser quaisquer outros nomes, como “Padawan” e “Jedi”, ou quaisquer outros termos “cool” que vc queira usar. Acho uma forma de deixar explicita a evolução da pessoa, que ela conseguiu passar de “aprendiz” para “experiente” para “mestre”, etc.

      Como isso afeta o comportamento? Bem, deve servir como um norte para a pessoa buscar progredir e atingir níveis acima.

      Sobre o sênior…DEPENDE de todos os fatores que mencionei. A empresa contratante é que vai dizer.

      Se aplicados da forma “correta”, ou seja, levando em conta critérios que mencionei no post, elas garantem resultado sim. Um pleno, ou seja, alguém que desenvolve com mais facilidade o trabalho por completo, que está mais alinhado com a cultura e valores da empresa, por consequencia, acaba dando mais retorno à empresa. O “nível” é adquirido por MÉRITO (e o salário tbem).

      Acho justo um bônus que privilegie a equipe como um todo sim (mas não sei como isso funcionaria ao certo, pelo menos, não pra responder em 2 linhas…), mas acredito que o salário fixo deve permanecer individualizado. Ou você acha JUSTO, em um mesmo projeto, um cara com bastante experiência receber O MESMO que um júnior que está iniciando a carreira?

      IMHO.
      []s

      Curtir

  9. Por que é necessário saber em que nível uma pessoa está? De onde surgiu essa ideia de comparação entre as pessoas que trabalham na mesma empresa?

    Por que a pessoa precisa evoluir e subir de nível dentro de uma empresa? Por que dentro de uma empresa existe essa hierarquia no modelo gestão?

    Um sênior pode voltar a ser pleno ou até mesmo júnior? Na CLT não dá para fazer isso… Se o trabalho muda todos os dias, se o conhecimento necessário para fazê-lo é cada vez mais importante e evolui rapidamente, então podemos ter pessoas sendo rebaixadas nessa classificação?

    Se hoje o trabalho coletivo é a regra e o que gera melhores resultados na era do conhecimento, faz sentido falar em meritocracia? Se uma pessoa tem um desempenho de “sênior”, será que isso não está mais relacionado ao contexto em que ela se encontra e a equipe na qual ela trabalha do que com as suas próprias habilidades e competências?

    Será que salário é uma questão de mérito? Será que o salário está relacionado à méritos que tive no passado? Uma pessoa deveria receber pelo seu nível de “senioridade”? Uma pessoa deveria receber pela função ou cargo que ocupa? Ou uma pessoa deveria receber por quem ela é e pelo que ela representa para o negócio?

    A equipe não poderia ter autonomia para determinar o salário de seus membros? Afinal, ninguém melhor do que a própria equipe para fazer isso… A equipe também não poderia ter autonomia para contratar e demitir?

    E se… não existissem classificações com essas? Como seria? Que novos mecanismos de trabalho em equipe e de evolução substituiriam esse?

    Curtir

    1. Matheus,

      Compartilho de mtas das suas dúvidas. Muitas empresas gigantescas e pioneiras em modelos mais novos de gestão trabalham de forma mais flexível a respeito de cargos, mas aqui no Brasil algumas coisas são limitadas por lei.

      Só visitando uma dessas empresas para ter uma outra visão (como funciona na SEMCO, por ex?).
      ———————————————————–

      Sim, a pessoa deve receber pelo valor que ela agrega ao negócio e a classficiação Jr/Pl/Sr não exclui essa ideia (como já expliquei no texto anterior). A classificação é uma forma de ver o nível de experiência de cada um.

      Qto a um sênior ser ‘rebaixado’, isso não pode nem deve acontecer. Ele chegou ali (se pelos motivos corretos) por mérito. Por qual motivo seria rebaixado? Passou a fazer tudo errado? Desaprendeu? A mudança para um nível ‘inferior’ só pode ocorrer caso o profissional mude de empresa, pois como eu disse, essa classificação é relativa. E isso não é rebaixamento. É o entendimento/nivel de exigencia de cada empresa que é diferente.

      Qto à autonomia para determinar os próprios salários? Sim. É algo ideal. Muitas empresas estão indo por esse caminho. Estamos seguindo, mas não é algo que mude radicalmente do dia pra noite. É preciso mudança de cultura (o que não é tão simples) e, principalmente, maturidade das equipes para que as decisões sejam embasadas. “Empowerment” não acontece num simples passe de mágica.

      Aqui mesmo, vários profissionais tiveram aumento graças a um ‘toque’ de alguns profissionais mais experientes. Já é um começo. (E sim, a equipe já demitiu pessoas e hoje é ela que tem voz maior na contratação).

      Curtir

  10. Legal, Robson.

    É assim que podemos sair aos poucos da velha forma de pensar sobre o trabalho.

    Infelizmente, alguns conceitos sobre o trabalho já estão no inconsciente coletivo e dão suporte ao status quo do mercado e da empresa, como também às zonas de conforto (ou estagnação?) da maioria dos profissionais (méritos do passado garantem meus ganhos futuros… né?)

    No fim, é muito melhor ter uma receita de bolo ou um padrão para ser seguido ou respeitado (e uma escadinha de níveis para galgar, simplificando todas as nuances do ser humano, colocando todos em uma igualdade mediana e garantindo a perseguição por uma cenoura eterna). Viver com a incerteza sobre o trabalho é muito doloroso.

    Algumas empresas tentam adotar maneiras inovadoras de gestão e abandonar o pensamento tradicional sobre o trabalho. Em várias delas isso é útil para manter os funcionários distraídos e motivados. Mas elas ainda continuam presas na “Matrix”.

    Curtir

    1. Matheus, você coloca perguntas muito boas. Vou tentar responder algumas de forma não linear…
      Voltando na questão do que é sênior, vou parafrasear uma pergunta sua:

      Um cara que é sênior em um determinado contexto e muda de time, ou de tecnologia, ou de negócio, vai continuar a desempenhar igual?

      Provavelmente não.
      Quer dizer que ele não é mais sênior?
      Aí depende. Como assim, ele é “senior em um determinado contexto”? Senioridade não é assim tão simples. Se o cara só fez sites com Rails, só faz isso há dez anos, sempre muito parecidos, nunca estudou mais nada… como eu classifico esse cara? “Senior em rails”? E se ele escreve mal, cheio de erros de português, não sabe falar com o cliente, é grosso, ou não faz testes direito?
      Esse tipo de cara não me parece sênior.
      Por outro lado, se o “sênior em determinado contexto” significa um cara que está sempre buscando melhorar, que é capaz de se adaptar, que buscou melhorar também suas soft skills, que aprendeu a base da programação, e não só uma linguagem, que já buscou projetos diferentes, com gente diferente, em contextos diferentes, com problemas diferentes, em negócios diferentes (entre outras diversas características), esse cara provavelmente é sênior.
      Senioridade tem a ver com experiência, com conhecimento e com capacidade de produção potencial. Potencial, essa é a palavra. O cara é bom em Java, mas se eu coloco ele num projeto .NET ele se vira e em pouco tempo está produzindo. Esse é o cara sênior.

      Precisa chamar o cara de sênior?
      Precisa, a lei exige, como o Robson falou… É uma bosta, mas precisa, pelo menos na carteira. Dito isso, foda-se a carteira, chame ele de sênior lá, e em lugar nenhum mais.

      A atitude é o que mais importa. Se o cara está alinhado com a empresa, não faz tanta diferença em que nível abstrata surreal ele está. Ele pode produzir mais, mas a questão é se o time vai entregar, e se é capaz de ver os problemas e desafios, se tem visão. E isso é feito num contexto multidisciplinar, com todo tipo de gente.

      Por fim, sou sim a favor de remunerar esse conhecimento. Ele não vem de graça. E por mais abstrato que seja, as pessoas reconhecem conhecimento, elas sabem se devem dar x ou 2x pro cara de salário. Como o Robson disse, foda-se como se chama o título do cara, mas ele merece mais, ou menos, e todo mundo sabe.

      Curtir

      1. Por um tempo não gostava dos nomes “Jr/Pl/Sr” mas passei a aceitá-los e até a usá-los. São apenas nomes. Como disse antes, poderíamos usar quaisquer outros internamente como “novato”, “aprendiz”, “ninja”, “mestre”, “Jedi”. Enfim, apenas nomes.

        Fato é que precisamos deles pra chamar a pessoa e nós próprios “daquilo”. Ou faríamos como? Usando um parágrafo inteiro ou 5 minutos de conversa? É como dar nomes aos design patterns: usar um “adapter” ou usar “**aqui um texto maior e algum exemplo**” ? (importante: as pessoas QUEREM saber em que nível elas se encontram, se estão progredindo).

        “O cara é bom em Java, mas se eu coloco ele num projeto .NET ele se vira e em pouco tempo está produzindo. Esse é o cara sênior.”

        Concordo plenamente, e exemplifica o fato de eu ter dito que um sênior não é rebaixado (dentro da mesma empresa). Trocando de empresa, aí a situação é mais complicada. No mundo perfeito, considerando as soft e hard skills já mencionadas deveria, em tese, permanecer sênior, mas, como disse, isso é relativo. Não como padronizar todas as empresas.

        “Por fim, sou sim a favor de remunerar esse conhecimento. Ele não vem de graça. E por mais abstrato que seja, as pessoas reconhecem conhecimento, elas sabem se devem dar x ou 2x pro cara de salário.”

        Perfeito também. Obvio até. E sem a menor condição de todos terem salários iguais só porque “são todos desenvolvedores”.
        ———————————————————————-

        E Matheus,
        Esses níveis são de aprendizado/experiência da pessoa e não de hierarquia. Muito menos comando/controle. Um sênior não “manda” no pleno e no júnior e nem o pleno “manda” no júnior. São todos programadores no mesmo nível hierárquico, porém, que podem estar em níveis diferentes de experiência. Só isso. (Apenas reforçando, caso isso não tenha ficado claro nos comentários anteriores).

        []s e obrigado por comentarem! Estamos aí para conversar mais sobre o assunto!

        Curtir

  11. Giovanni e Robson!
    A discussão está excelente. Com certeza deveríamos fazer isso mais vezes e também pessoalmente. É fato que nenhum de nós sabe tudo ou sabe a melhor forma de fazer qualquer coisa, mas essas discussões nos fazem aprender bastante!
    Lendo as respostas de vocês, consigo ver vários pontos em que concordamos. Vou tentar listar alguns deles e fazer algumas considerações.
    1. CLT
    É verdade que a CLT é muito restritiva e nos obriga a estabelecer diferença entre cargos e salários. Entretanto, podemos tratar isso apenas como um burocracia e evitar que isso cause alguma influência dentro da empresa ou no modelo de gestão. Por exemplo, podemos usar na carteira de trabalho cargos como Programador, Analista de Sistemas e Engenheiro de Software e seus respectivos níveis (júnior, pleno e sênior) para encaixar dentro das restrições trabalhistas os diferentes salários existentes na empresa. Portanto, seria um “de-para” burocrático e uma maneira de não usarmos cargos / classificações dentro da empresa (é claro que isso tem risco trabalhista… mas creio que vale a pena mesmo assim).
    Entretanto, os salários poderia ser definidos de maneira mais dinâmica, sem seguir uma escala pré-determinada. E é claro que a equipe consegue ver o que é justo ou não pagar para um profissional.
    Como esse é uma problema complexo, não podemos simplificar sua solução para algo pré-determinado. Portanto, nada melhor que as próprias pessoas (também complexas) para resolver esse problema.
    2. Senior
    Concordo que podemos caracterizar como “sênior” o profissional que tem uma ótima capacidade de aprender e de resolver problemas. É claro que esta habilidade está relacionada aos conhecimentos e experiências passadas deste profissional.
    Também concordo que a equipe consegue identificar isso em um profissional “sênior”… e ela o faz observando seus comportamentos e atitudes.
    Não adianta um profissional ser “sênior” se ele está acomodado ou não está contribuindo para o time e para empresa. É preciso que ele coloque em prática suas competências enquanto “sênior”.
    Dentro do contexto de uma empresa, também podemos avaliar o trabalho de um profissional “sênior” a partir de diversas perspectivas: o resultado que ele traz para a empresa, o quanto ele colabora para o crescimento e desenvolvimento dos outros integrantes do time, as intenções por traz do seu trabalho na empresa (se ele realmente acredita nos valores e no propósito da empresa…) e os valores pessoais e boas práticas que regem sua conduta no trabalho.
    Por fim, se “sênior” é um profissional com grande capacidade de aprender e resolver problemas, então um cara que não desenvolve software mais é bom para resolver problemas de comunicação, de integração entre os membros do time, de negociação com o cliente e de capacitação de um integrante da equipe pode ser classificado assim.
    Aí, a pergunta que deixo é: esse profissional deveria ganhar mais, menos ou igual a um profissional sênior que desenvolve software na mesma empresa?

    Curtir

  12. Rapaz, parabéns pelo post!
    Só vou adicionar uma historia aqui para ver se complementa tudo o dito e que exemplifica a forma “empírica” em que esses “cargos” são manejados na prática dentro da empresa. Certeza que jr/pl/sr é por um lado só coisa de carteira de trabalho, na prática divide os níveis de XP dos caras. O Giovanni matou o assunto quanto ao sr, é o cara cujo XP lhe ajuda a sair de qualquer situação.
    Eu gosto muito de Historia, sempre li muito sobre isso. Um dia estava lendo sobre as táticas revolucionarias que levaram aos Alemães a conquistar a França em pouco mais de 40 dias durante a segunda guerra mundial. Basicamente e para resumir os caras precisavam de rapidez de toma de decisão e ação, e obviamente liberdade de ação, ou seja, o comando confiava nas decisões dos seus subalternos e não se metia a dar pitaco e atrapalhar o andamento das ops. Isto revolucionou as táticas e dito de passagem, mais ninguém no mundo adotou este tipo de liderança.
    Assim a Luftwaffe tinha um sistema interessante, ela usava os rangos, soldado, sargento, tenente, capitão, etc, no papel, porém quem liderava a missão de combate era quem tinha mais XP ou mais vitórias aéreas, então acontecia que um cara que era tenente liderar um voo onde tinha capitães e majores e mandava em tudo mundo. Tinha moleques de 20 anos de idade “mandando” (somente no ar) em capitão com 30 anos. Este método sadio ajuda também a controlar egos.
    Assim acontecia de um piloto recém chegado no fronte após algumas missões estar liderando companheiros pilotos com mais horas de voo por competência e ter demonstrado na prática resultado, comprometimento e liderança. Os caras também sempre colocavam um novato para voar em ala com um cara de XP (na nossa área ocorre isso, pouco, mais ocorre, espécie de relacionamento jedi-padawan, alias acho este “mentorismo” fundamental).
    Não sei se da para entender claramente o quero dizer, mas essa forma empírica e o “override” geral que faziam com os graus na prática foi o que levou ao sucesso fabuloso da Luftwaffe nos primeiros anos de guerra. Pelo menos foi assim ate que o resto do mundo cansado de levar pau aprendeu.
    Só sei que o sênior é o cara que tem um impacto maior onde quer que a força dele seja aplicada. Pode estar como pleno na carteira mas na prática o impacto dele em todas as áreas incluída a economia da empresa faz dele sênior.
    Alias, esse tema econômico é outro ponto que foi falado aqui. Os empresários não tem muito claro qual é o impacto de um bom profissional na economia da empresa. Muitas vezes deixam um cara ir por míseros 500 reais e não ponderam o quanto estão perdendo deixando ele ir embora. Olham somente os números frios e dizem “fiz negocio, troquei ele que vale 10 por um pl que faz o mesmo e vale 3 no final do ano ganhei 84!”, será que fez economia? Será que faz o mesmo?
    Um sênior tira um projeto problemático do buraco e o faz andar. Um pleno duvido, se consegue então não é pleno.
    Peço desculpa que o comentário virou quase post…
    Ref. sobre a Luftwaffe http://en.wikipedia.org/wiki/Luftwaffe#Organization_and_chain_of_command

    Curtir

    1. Interessante, apesar de ter a história da segunda guerra como um hobby não tinha lido nada a respeito.

      Vou procurar mais fontes sobre essa abordagem de comando na Luftwaffe é um case interessante talvez até semelhante ao Champion do sistema Toyota.

      Curtir

  13. Concordo em gênero, número e grau. Os comentários então mas que complementarão o artigo.

    Só posso lamentar ainda vivermos em um mercado de sênior e plenos que não passam de meros “esquentadores” de cadeira.

    Curtir

  14. Robson,
    Muitíssimo boas as suas colocações. Concordo em gênero, número e grau.
    Penso que as empresas, além dessa caracterização de jr/pl/sr devem adotar uma política de “segunda avaliação” feita por colegas profissionais daquela área específica.
    Já que sabemos que o RH tem dificuldade para avaliar o nível de conhecimento do pretendente à desenvolvedor de software (as vezes até nós mesmos,né? rsss).
    O tempo é muito relativo!
    Forte abraço.
    Parabéns.

    Curtir

    1. Opa, Paulo!
      Obrigado por comentar. Aqui nós fazemos assim. Os membros dos times participam do processo de contratação (alias, sao os principais envolvidos) e estamos sendo buscando melhorar esse processo.
      []s

      Curtir

  15. Vou entrar meio atrasado nessa discussão, mas gostaria de também dar meus 2 centavos. A visão que eu tenho do que é um senior é um pouco diferente dos demais. A meu ver, passar de pra pleno e depois pra senior vai além do conhecimento técnico e específico em uma determinada linguagem. É passar por tantas experiências que a maioria dos problemas se tornaram triviais e você sabe resolver sem precisar pensar no assunto ou buscar no google.
    Dessa forma, para um profissional se elevar de título acredito que precisam ocorrer duas coisas
    1 – Ele passa a ensinar muito mais do que fazer. Ou seja, ao invés de sempre por a mão na massa pra resolver os problemas arroz e feijão que já viu 300 mil vezes (e.g.: faça um CRUD), ele ensina os desenvolvedores juniores ou plenos a resolver e delega. Até porque, o desenvolvimento profissional deveria acompanhar a maturidade, de forma que um sênior tenha mais responsabilidades e ajude a gerir a equipe.
    2 – Quando ele de fato põe a mão na massa, é pra resolver algo complexo, ou melhorar os processos ou a qualidade. Neste caso, como fazer as coisas mais simples já não trazem nenhum desafio, e um sênior pode facilmente ensinar outro dev. a resolver e delegar, só faz sentido o sênior trabalhar com problemas complexos (como metaprogramação, escalabilidade, segurança, paralelismo, refatorações, etc.) que outros desenvolvedores com menos experiência teriam problemas em arquitetar.
    Agora, eu discordo um pouco dessa questão de que tempo de experiência é relativo. Eu acho que demora mais ou menos a mesma quantidade de tempo sim para todos os desenvolvedores. Porque não é saber uma linguagem ou tecnologia que torna um sênior sênior. É saber lidar com problemas diversos, sejam eles de código, equipe, cliente, prazos, máquina de café quebrada ou o que for. E lidar com todos estes imprevistos não é algo que se faz ativamente e que basta gastar X horas estudando loucamente uma linguagem para se auto proclamar sênior em 1 ano. É algo que se constrói dia a dia de forma imprevisível. E essa carga de experiência sim leva perto de uns 10 anos para acarretar, independente de ter 10 ou 50 mil horas na linguagem X framework Y.
    E nesse caso, não adianta avaliar só a qualidade técnica do profissional para “medir” o nível de destreza não. Já trabalhei com muito desenvolvedor tecnicamente bom, com ótima formação acadêmica e anos de experiência mas que ao invés de somar, subtraía a equipe. Não sabia lidar com outras pessoas, não tinha maturidade, e por aí vai. Eu prefiro trabalhar com um desenvolvedor junior que saiba coperar e disposto a aprender, do que um senior rockstar sem espirito de time ou cansado do que faz. Se o rockstar for refazer todo o código dos outros devs, ele acaba sendo menos produtivo que o junior, então qual a vantagem?
    Me considero “Sênior” não porque tenho 8 anos com Ruby on Rails e conheço bem uma porrada de outros frameworks. Mas sim porque nesse ínterim criei minha própria empresa e tive de lidar com todo tipo de cliente, equipes e profissionais de diversas qualidades e personalidades, projetos dos mais esquisitos e soluções completamente fora da caixa. E errei várias e várias e várias vezes. Aliás acho até que se hoje decidisse virar cozinheiro, provavelmente não começaria como júnior, ou subiria de cardo muito mais rapidamente. Posso não entender nada sobre como cozinhar, mas as lições que aprendi sobre como lidar a vida, os desafios e as pessoas servem pra qualquer área.

    Curtir

    1. Olá, Stefano

      Concordo com tudo que disse.
      Qto ao tempo de experiência, o profissional precisa amadurecer, ter passado por vários experiências (positivas e negativas) e isso leva tempo. 10 anos é um bom tempo sim. Pode variar um pouco mais ou um pouco menos. Desde, é claro, que tenha passado por desafios que tenham exigido dele. 10 anos fazendo CRUD numa salinha fechada não se encaixa nisso.

      Muito obrigado por ter enriquecido o post!

      []s!

      Curtir

  16. Parabéns pelo post!! Muito lúcido e claro. É certo que existem diferentes definições para estes níveis de experiência, mas você desenvolveu bem a questão. Creio que a definição depende muito em que empresa vc trabalha, se a empresa é de pequeno, médio ou grande porte, e também de cada profissional estar sempre se atualizando e valorizando o seu currículo. Registro em carteira profissional que comprove a sua experiência vale muito também. Sei por experiência própria. Trabalhei como analista de sistemas muitos anos no Grupo Hermes Macedo, depois saí e fiquei mais de 15 anos trabalhando como microempresário, aprendi muito com o mercado, com as exigências de diferentes tipos de usuários, definindo, analisando, desenvolvendo muitos sistemas aplicativos, fazendo cursos para complementar meus conhecimentos, estudando como autodidata, porem na hora que voltei a trabalhar registrado, essa experiência não valeu muito e fui registrado como Analista Junior. Me senti recomeçando aos 51 anos de idade. Trabalho numa ‘grande empresa’ desde janeiro de 2011, hoje como Analista Pleno e gosto muito do que faço, gosto muito do ambiente de trabalho, das pessoas, do modo como compartilhamos o conhecimento, de como crescemos junto com a empresa.

    Curtir

    1. Obrigado, João.

      E boa sorte!

      (Qto ao tempo de registro na carteira, não acredito que valha. As empresas boas não se importam com isso e sim com o que vc consegue fazer, geralmente por provas técnicas no processo de contratação. Ou seja, se você é bom/experiente, eles vão acabar comprovando na prática, com o código que vc é capaz de fazer (em se tratando de programador), independente de você ter trabalhado 2, 5 ou 10 anos, registrado ou não, se tem diploma ou não, se tem certificações ou não. Pelo menos, funciona assim em muitas empresas onde todos querem trabalhar. O importante é você estar praticando e atualizado.)

      []s

      Curtir

Participe! Vamos trocar uma ideia sobre desenvolvimento de software!

Blog no WordPress.com.

Acima ↑