Categorias de Desenvolvedor

Hoje em dia existe uma deficiência em entender as atividades de um programador e no que elas se distinguem das de um desenvolvedor, de um arquiteto ou de um analista. O mesmo é válido para cada uma destas em relação às outras.

A confusão aparece no universo java por dois motivos:

1) A Sun – que certifica os profissionais – estabelece 3 tipos principais de certificado: Programador, Desenvolvedor e Arquiteto. Para a Sun o papel de cada um é muito bem definido (existem objetivos concretos a serem alcançados) e, por isso, ela pode certificar que alguém chegou nesse patamar. Sob este ponto de vista, o processo é evolutivo sendo que apenas uma pessoa certificada como programador pode se habilitar a ser certificada em qualquer outra coisa. Os nomes explicitam o que a pessoa é potencialmente capaz de fazer, independentemente se tem ou não experiência.

2)Os Departamentos de Recursos Humanos, ou empresas terceirizáveis de Recursos Humanos – a que carinhosamente chamarei de RH – precisam ter parâmetros para avaliar tanto as competências necessárias mas principalmente as faixas de salário “de mercado”. Veja, o RH é avarento por natureza e não gastará um centavo a mais do que for necessário. Por outro lado, ele tem dificuldade em definir o que “precisa”, o  que leva a processos de seleção mais ou menos aleatórios.

Um profissional java também quer saber a faixa de salário em que se encaixa para saber como negociar com o RH e vice-versa. Contudo, é difícil ambos concordarem no que marca cada patamar da faixa salarial.

Os RH, de modo simplista, dividem as coisas em: júnior, pleno e sênior; chegando ao cúmulo destes três sufixos passarem a ser mais importantes que as atribuições do cargo em si.

Por exemplo, “Programador Sênior” singifica o quê ?
Em tese significa que a pessoa é um excelente programador. Nada mais que isso. Mas para os RH significa principalmente que: a) a pessoa tem mais de 5 anos na área; b) que já gerenciou equipes de programadores.
Ora, é óbvio a qualquer um que trabalhe com programação que : a) tempo não é equivalente à experiência nem a qualidade; b) gerenciar equipes não é trabalho de programador e sim de desenvolvedor, ou quiçá de arquiteto. Ou melhor dizendo, gerenciar equipes é uma qualidade completamente ortogonal à de programador.

Dois mundos separados que são “unidos” por expressões vazias como “Programador Sênior”, que  não têm um significado próprio pois significam coisas diferentes para cada um. Entenda que o erro do RH é entender o prefixo (junior/sênior) como equivalente a idade ao invés de a experiência. Uma pessoa com 15 anos no ramo de desenvolvimento pode ser programador sênior de uma linguagem que aparecem há 3 anos? Sim, porque o RH exige apenas 5 anos de experiência na área de programação e não na linguagem/tecnologia/plataforma em si. Isso leva ao absurdo do RH pedir por alguém mais experiente do que é matematicamente possível. Isso talvez não seja totalmente despropositado considerando o ponto de vista do RH que nada tem a ver com as qualidades técnicas da pessoa. Estamos frente a um paradoxo.

Bom, temos então duas áreas importantes para entender as atividades de um programador: a pessoal e a técnica. A pessoal é uma combinação de personalidade, histórico e esforço enquanto que a técnica é uma questão de experiência – experiência real, não apenas anos de trabalho na área. Por exemplo à pergunta:  “Qual a sua experiência com Java?” a resposta “Trabalho com java há 10 anos” diz muito pouco, mas “Já utilizei java em 5 projetos: um Desktop com SWT, três para Web e um embarcado em automóveis” diz muito mais. É que o cara pode passar 10 anos mexendo apenas com, digamos HTML+JSP e nem saber o que é um Servlet ou TagLib ou , pior, um List<T>. Tempo não é experiência é exposição.

Uma outra dimensão do problema é considerar a carreira como um todo. Muita gente pensa que a carreira é mais ou menos assim: Programador Júnior > Programador Pleno > Programador Sênior > Analista de Sistemas > Analista de Negócios. Quanto a mim, isso é bem longe da realidade. O trabalho do analista é levantar os requisitos necessários ao desenvolvimento do projeto. O analista (de negócios, requisitos, como se quiser chamar) tem que entender o pedido do cliente e dos desenvolvedores,  elaborar trade-offs inteligentes de forma a maximizar o valor do software para o cliente sem incorrer em riscos de desenvolvimento. O analista não precisa saber programar, ele precisa saber analisar. Isto é, ter espírito crítico, poder de comunicação e conciliação. Ele tem que ter noção daquilo que os pedidos do cliente implicam mas sempre deve contar com o apoio dos desenvolvedores. O pior  erro que uma analista pode cometer é não colaborar com o resto da equipe sob o falso pretexto que ele é o “chefe” ou o “líder”.

A carreira é uma escolha da pessoa entre as opções possíveis, mas o que interessa, eu acho, é a sua capacitação, isto é, o que a pessoa é capaz de fazer. Vejamos assim:

Programador J E
P S
Desenvolvedor J P S
Arquiteto J P
E
Analista J E

A capacitação de um programador júnior começa em uma área especifica da plataforma ( web,por exemplo) onde ele aprende a mexer com as classes básicas ( String, BigDecimal, File , InputStream, OutputStream, etc.). Ele não está preocupado com a estrutura abstrata do código, em seguir padrões, etc… apenas em escrever código que funcione. Repetindo este processo sempre no mesmo ambiente o programador vai conseguir executar tarefas de forma mais estruturada e tornar-se um especialista em uma certa área da paltaforma (web , desktop, por exemplo). Se ele muda de área, a bagagem do básico vai com ele; e ele começa a acumular conhecimento da plataforma como um todo. Pode até começar a enxergar e implementar um ou outro padrão de projeto. Aqui, ele está capacitado como programador pleno e desenvolvedor júnior, ou seja, ele pode assumir qualquer programação mas não a responsabilidade do design, para isso precisamos de um desenvolvedor pleno, que é normalmente um programador mais experiente que passou por diferentes projetos usando tecnologias diferentes e consegue enxergar o que há de comum entre elas. Por exemplo, entender que o JMS é na realidade uma super implementação do padrão Produtor-Consumidor ou que JMX é uma super implementação de Observer. A este ponto, a pessoa está capacitada a entender diagramas de arquitetura e até a dar algum palpite. Ele deve ser responsável pelo design e levar a equipe a seguir um design. Não pode, contudo,  ser responsabilizado por escolhas de arquitetura. O arquiteto é quem tem essa responsabilidade. Não é necessário que o arquiteto saiba programar na plataforma em causa, já que lhe bastam conceitos genéricos como Orientação a Objeto e Padrão de Projeto. Ele contará com o desenvolvedor para os detalhes, a ele cabem as idéias e as escolhas. Para o arquiteto é importante o conhecimento de tecnologias, plataformas, padrões e frameworks  tanto como para o desenvolvedor sênior é importante um pouco de feeling sobre as expectativas do cliente. O arquiteto pode ser especialista – trabalhar apenas com java, por exemplo – ou não, trabalhando com várias plataformas e/ou linguagens. Ou pode, ainda, se especializar em um tipo de arquitetura: web, desktop, etc. Um arquiteto verdadeiro tem um pouco de analista e, em uma equipe pequena, pode até acumular as duas capacidades, mas um bom arquiteto não necessariamente dá um bom analista e vice-versa. O arquiteto é uma pessoa versada em tecnologia enquanto um analista é uma pessoa versada em pessoas. Nem sempre estas duas vertentes são compatíveis. Normalmente não são. O analista pode também se especializar em uma área de negócio caso em que se transformará em um analista de negócios que pouca, ou nenhuma, relação tem com o mundo da informática. O trabalho do analista é levantar requisitos com o cliente e identificar padrões de requisitos para futuros projetos.

Embora pareça pela descrição, não acho que a pessoa precisa começar como programador para se transformar em analista de negócios, mas com certeza precisa se quiser virar arquiteto. Existem analistas de negócios que entendem a informática como uma ferramenta e tentam entrar nesse mundo como programadores (não como arquitetos) para suprir demandas na área de negócios que conhecem. Viram adeptos por necessidade (ver no fim). São dois mundos. Um pode levar ao outro, mas isso será obra das circunstâncias e não um plano de carreira.

O analista de negócios é um especialista em uma área de negócios. Ele pode simplificar as coisas para o analista não-especialista e/ou para o arquiteto. O analista de negócios tem uma participação esporádica e trabalha normalmente como consultor. O arquiteto, quando considerado que ele não programa e não analisa, também tem uma participação esporádica e trabalha também como consultor. Os outros, têm normalmente uma participação continua no projeto. Por isso ele representam a fatia maior do custo do projeto. Excluindo o analista não-especialista que consideramos trabalhar como consultor esporádico existem 5 categorizações possíveis: Programador Júnior , Programador (sem afixos) , Desenvovledor (sem afixos) , Arquiteto (sem afixos) e Analista (sem afixos).

Hoje me dia fala-se muito no Analista Desenvolvedor que teria capacidade equivalente a um analista junior, arquiteto junior e desenvolvedor senior e que no fundo representa a soobreposição ótima do quadro que apresentei antes. Isso nos deixa com três categorias: Desenvolvedor Junior , Desenvolvedor Programador e Desenvolvedor Analista. Essa nomenclatura faz mais sentido se pensarmos que Programadores, Desenvovledores e Arquitetos (nomenclatura Sun) são todos desenvolvedores (nomenclatura geral) .

As empresas – e portanto os RH – consideram ainda dois outras categorias: estagiário e trainee (treinando). A diferença é legal, um é protegido por ditames da lei diferentes. O treinando é alguém que a empresa assume que vai ensinar a teoria e a prática por seu próprio risco. Numa oficina seria o aprendiz. Ele tem N meses para mostrar que aprendeu. O estagiário é alguém se assume que já sabe alguma teoria e se espera que se encaixe numa certa prática (normalmente é alguém vindo direto da faculdade).

Onde se encaixam estas pessoas? Na categoria de júnior já que as suas capacitações são equivalentes. Na realidade a diferença é apenas administrativa relativa a como a lei enxerga a posição da pessoa na empresa e não relativa ao que ela sabe fazer. Existem estagiários com capacidade maior que junior, é verdade, mas o ambiente – infelizmente – não os deixa expressar as suas qualidades ( isso é assunto para outro post… ). Quando alguém consegue um certificado de programador pela Sun, isso significa, basicamente, que a pessoa é um programador júnior (Desenvolvedor Junior) certificado, já que o resto vem com a experiência.

Existe uma outra categoria que não posso deixar passar que é o Adepto. Este é o cara que começa com 10 anos a programar umas coisas em casa e até se vira bem, mas não tem nenhuma noção teórica do que está fazendo nem tem responsabilidade sobre os erros que comete. Alguns podem ser programadores em potencial, mas nem todos.

Ser programador não é apenas escrever código é responsabilizar-se pelo código que escreveu. Certificações podem ajudar a escrever um código melhor, mas os RH procuram pessoas responsáveis.

Anúncios

13 opiniões sobre “Categorias de Desenvolvedor”

  1. É Sérgio, essa coisa de cargos em Desenvolvimento de Software é algo muito complexo e polêmico, há uma discussão muito boa pra pensar sobre esse assunto no blog do Shoes . Abraço

  2. Olá Sergio!

    Como sempre post com mensagens acertadas sobre o mercado!

    Por isso acho necessário uma padronização do mercado, que pode vir através da Lei, mas não esse modelo proposto hoje.

    Obrigado

  3. Existem várias falhas no seu texto, e a maioria delas provém do seu, pelo visto, limitado entendimento do que é desenvolver software. A primeira delas é comparar experiência com FERRAMENTAS (linguagens, plataformas) ao invés do conhecimento do DOMÍNIO e das soluções utilizadas (que independem de ferramentas).

    Leia mais sobre SCRUM… pode ser que você perceba que sua visão sobre analistas também é furada.

    “Não é necessário que o arquiteto saiba programar na plataforma em causa, já que lhe bastam conceitos genéricos como Orientação a Objeto e Padrão de Projeto.” <- tenho medo dessa sua opinião…

    Cara, tu tem chão ainda pela frente 😉

  4. Bruno, não sei de onde tirou a ideia de que comparo experienca com ferramentas, aliás essa palavra aparece uma única vez no texto

    “Existem analistas de negócios que entendem a informática como uma ferramenta e tentam entrar nesse mundo como programadores ( não como arquitetos)”

    e se refere à visão que o analista de negócios – que defino como uma pessoa sem background em programação – pode enxergar a informática.
    Conhecimento de Domínio e das soluções utilizadas é exatamente coisa para analista, especialmente para analista de negócios. Tb não sei o que Scrum tem a ver com o caso já que não falei de gerência nem de liderança em lado nenhum.
    Sinceramente não compreendi o seu comentário…

  5. André, a minha postura e entendimento do conceito de analista é completamente diferente de alguem cujo único trabalho é fazer bonecos ( sejam UML ou outros). Para mim analista é uma pessoa responsável por entender o que o cliente quer, porquê ele quer isso, como a solução irá afetar o negócio do cliente ( para bem e para mal) e propor opções que o cliente não enxerga. Por exemplo, se o cliente pede o famoso “enter como se fosse tab” o analista tem que fazer um esforço para demonstrar que isso é conceito ultrapassado , que é contra as boas práticas de ergonomia e monstrar com casos reais que no fim, a pessoa usa o tab. Se o cliente insistir em coisas ultrapassadas ele merece ser cobrado a mais por isso. Normalmente o cliente entende melhor esse argumento. Isso é que é o papel do analista. Não tem nada a ver com modelagem ou programação. O artefato que o analista entrega pode ser uma simples lista de requisitos sem nenhum UML.
    O problema é que hoje em dia está função é menosprezada e se pensa que um desenvolvedor também pode ser analista. O ponto é que até pode, mas não de forma imparcial. Ele sempre está pensando no que isso vai dar de trabalho na hora de programar.
    Modelar com código como advogam a DDD e a TDD é ótimo mas se aplica a modelar não a analisar. Veja assim, analista é como um psicologo, desenvolvedor é como um farmacólogo. O farmacólogo tem sempre a pretenção que pode criar uma droga para resolver o problema mental do paciente, o psicologo sabe que muitas vezes a droga nem é necessária.

  6. “Não é necessário que o arquiteto saiba programar na plataforma em causa, já que lhe bastam conceitos genéricos como Orientação a Objeto e Padrão de Projeto.”

    Conhecimentos de “conceitos genéricos como Orientação a Objeto e Padrão de Projeto” são do domínio de qualquer estudante de bons cursos de graduação. Creio que um arquiteto precise de muito, mas muito mais.

    Quanto à divisão de papéis entre analista, desenvolvedor, programador, digitador e secretária, creio que os métodos ágeis já eliminaram o taylor-fordismo do desenolvimento de software faz algum tempo.

  7. Sergio,

    Concordo literalmente com o seu post, não só a carreira de um profissional que busca melhores adquações para se estruturar e entender suas funcionalidades, todavia o que ocorre é que aqui no Brasil, a divisão de tarefa esta centralizada na divisão de interesses, tambem de correntes consultores e que não querem concorrencia, e fazem deslealdades com outros que estão vindo, ao mercado.

    Vejo que colocar como Junior, Pleno ou Senior isso é de um erro gravissimo para na verdade configurar uma pessoa que trabalha com tecnologia da informação.

    Claro que anos de experiencia não diz que o cara é mais experimentados em outros projetos ricos em tecnologias, mas o que pega nisso é que anos de vivencia qualificam a pessoa a também saber ter postura técnica para se ater com o novo ou passar a qualidade de outras caracteristicas até então não vivida por aquela ou outra situação profissional.

    Somos todos colaboradores e precisamos saber nos indenficar com as novas funcionalidades dearcodo com aquilo que temos mais aptidão,visto que do mais o Mundo é relacionamento e trocas de boas informações e favores.

  8. Rodrigo,

    É claro que o arquiteto precisa de muito mais – aliás eu falo isso no texto – mas uma coisa que ele não necessariamente precisa é saber programar na linguagem da plataforma que ele escolheu como a mais adequada ao sistema em causa.
    Não sei de onde tirou que “digitador” e “secretária” são papeis em um ambiente de desenvolvimento, mas independentemente disso – infelizmente – o taylor-fordismo ainda não acabou. Os métodos ágeis podem trazer uma alternativa a alguns problemas, mas principalmente eles se focam em trabalhar o desenvolvimento. Alguns até em trabalhar a gerencia ( como o Scrum) mas nenhum em trabalhar a análise ou a arquitetura da mesma forma ágil. Por outro lado, nem todos os projetos podem ser abertos e muitos têm sua viabilidade tendo que ser definida à priori. Ou seja, métodos ágeis não se podem aplicar sempre.
    Enfim, mesmo que os métodos ageis tenham trazido uma forma de fugir ao taylor-fordismo, na prática, o mercado de desnevolvimento ainda não saiu desse modelo ( tal como as empresas ainda não sairam do modelo hierarquizado). Isso obriga o desenvolvedor a conviver com problemas decorrentes desses modelos no dia-a-dia. Um dos quais se traduz – como tentei mostrar – na visão que o RH tem dos desenvolvedores.

  9. Márcio,

    Sim, anos de exposição fazem a pessoa ter uma postura em realação ao que faz. No que discordo de ti é que essa exposição e essa postura sejam embutidas de “qualidade”. Ou seja, não me parece real que a pessoa que programou 10 anos com Clipper tenha o mesmo à vontade e postura inovadora de quem programa hoje com Java , Python ou Ruby. A pessoa que aprendeu a programar em um paradigma orientado a tabelas ( nem sequer orientado a banco de dados) tem sérias dificuldades em adotar e aceitar um paradigma orientado a objetos. É claro que a pessoa pode ter ganho capacidades comerciais e até de interação social ao longo do tempo, mas duvido que ela ganhe experiência prática util em outras situações. Para que isso aconteça a pessoa tem que quebrar laços com o paradigma de desenvolvimento que usa e isso é tanto mais difícil quanto mais tempo a pessoa passou exposta a outro paradigma.

  10. Primeiramente, deixo claro que acompanho teu blog sempre quando possível, já que encontro nele material simplificado e de fácil entendimento.
    Houve um equívoco no início da matéria.
    “o processo é evolutivo sendo que apenas uma pessoa certificada como programador pode se habilitar a ser certificada em qualquer outra coisa.”
    Para a certificação de Arquitecto (SCEA) não é necessário a (SCJP).

  11. Obrigado, Mateus pela correção.
    Na realidade isso reforça a idéia de que o Arquiteto não é um Programador.

  12. Sergio,

    Muito interessante esse post. Concordo com suas opiniões. Difícil é termos essas definições de papéis na prática como já conversamos no GUJ.

    Concordo que não podemos aceitar o que nos impõem e que devamos exigir melhores definições de papéis nas empresas em que trabalhamos. Eu mesmo tenho o título de Analista de Sistemas Sênior. Apesar de ser muito bonito esse título não me orgulho disso pois esse título é apenas um encaixe na faixa salarial. Na verdade, poucas vezes na minha vida tive um título que fosse compatível com minhas funções diárias na empresa.

    Abraço e parabéns pelo blog!

  13. Olá, achei muito legal o ponto de referência que você deixou no seu artigo. Eu estou tentando conseguir um emprego em programação (principalmente Java Web), mas não como procurar ainda.
    Obrigado por alguns esclarecimentos.

Deixe uma Resposta

Please log in using one of these methods to post your comment:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s