Essa coisa de junior e de sênior sempre me pareceu completamente ridícula desde o dia em que comecei a mexer com software e tive que enfrentar essas classificações que as empresas e os RH fazem. Bom, para ser justo, não são apenas os RH é todos o mundo de forma geral que tem alguma coisa que ver com administração de empresas relacionadas a software.
Esta nunca me pareceu forma de dividir ou distinguir as habilidades das pessoas. Aliás sempre achei o nome “programador” ofensivo para quem é mais que isso, embora reconheça que sim existem programadores. O ponto é que quem desenvolve software não é apenas um “programador” ele tem outras habilidades. Eu já fiz várias entrevistas e sempre procurava determinar o quantidade de aptidões e o nível dessas aptidões nas pessoas. Existem pessoas que simplesmente têm talento para testar e nenhum para desenvolver. E outros é ao contrário. Poucos têm as duas coisas em equilibrio. Portanto, não se pode esperar tudo de todos. Mas a pergunta que ficava sempre na minha cabeça era : “afinal o que estou procurando nesta pessoa”. E não estou falando de empenho e vontade de aprender. Estou falando de vertentes, de perfis. Afinal quantos e quais perfis existem ?
A resposta é simples. Existem quatro : Especialistas, Generalistas, Generalistas com especialidades e fanfarrões.
“Programar” é uma coisas que o desenvolvedor faz , de entre as muitas possíveis. É uma especialidade. Quem apenas sabe programar e o faz bem e apenas faz isso, então é um Programador no verdadeiro sentido da palavra. É um especialista em programação. Um especialista em programação não apenas programa, ele programa seguindo diretivas, boas práticas, padrões e convenções de forma que outras pessoas também programadores saibam ler o codigo que escreveu e o saibam interpretar ( reconhecer as razões que levaram a pessoas a escrever o codigo daquela forma). Mas um software não se faz só de código. Se faz de levantamento de requisitos, analise, design, arquitetura, modelagem, teste, grafismo, ergonomia, etc… Cada uma dessas coisas em si mesma pode ser umas especialidade. Afinal todos ouvimos falar nos DBA e AD que comandam – apenas – banco de dados, de pessoas que ficam fazendo diagramas UML ou escrevendo casos de uso, os “testers” que são – em tese- pessoas especializadas em teste, etc…
No mundo do software tradicional é muito comum dividir o trabalho pelas especialidades e esperar que cada um faça sua parte para no fim juntar tudo. O problema é que se esquecem de que “juntar tudo” também é uma tarefa em que se pode ser especializado (designer) e é por isso que os projetos tradicionais falham.
Todos sabemos o que é um “Especialista de Dominio” (domain specialist). É uma pessoa especializada no dominio. Esta especialização é bem útil durante a construção de um software dirigido a um domínio especifico, e quanto mais complexo o domínio, mais necessárias são estas pessoas. Elas não necessariamente produzem software no sentido de por a mão na massa do código, mas ajudam a todos a entender o porquês e por que nãos das coisas que o software deve fazer.
Por outro lado, um generalista é uma pessoa que sabe fazer de tudo um pouco. Não se trata aqui de que o especialista faz com mais qualidade que o generalista. Não é esse o ponto. O ponto é que o generalista sabe fazer mais coisas que o especialista. O quão bem as sabe fazer advém da experiencia , esforço e talento de cada um. Um generalista não tem que saber tudo. Não é necessário desempenhar todos os papeis para ser um generalista mas mais do que dois ou três.
O iniciantes começar no mundo do software preocupados em saber programar, usar as bibliotecas etc… sem nunca dar atenção a coisas como modelagem ou levantamento de requisitos. Muitos passam sua vida sendo apenas programadores deixando com outros especialistas as outras atividades. Isto é comum em “fábricas de software”.
Como disse antes quem trabalha no modelo de fábrica com um bando de especialistas encadeados em uma linha de produção se esquece que alguém tem que conhecer todas as partes do processo, do produto e do resultado de forma a avaliar como a linha de produção se portou. Senão ficam todos a olhar uns para os outros peguntando a cada um como a parte dele deveria funcionar. Isto causa imenso ruido na informação relevante, perda de informação e até inclusão de erros.
No modelo ágil se pede que as equipes sejam multidisciplinares. Muitos interpretam isto como “muitos tipos diferentes de especialidades”, mas significa de fato “pessoas com várias aptidões” ou seja, generalistas. Um generalista pode fazer muito mais num período de tempo que vários especialistas. A pessoa pode conduzir o ciclo inteiro. Levantar um requisito, implementá-lo, testá-lo reportar ao cliente e começar de novo. Implementar pode significa escrever java, html, javascript, usar a biblioteca A ou B, mexer com banco de dados, SQL, configurações, produzir documentos, uml, etc… Agora imagine dois, três , quatro , generalistas e compare com equipes de dez, quinze, vinte , cinquenta especialistas.
Quando imagino especilistas imagino o cara sentado numa mesa com aqueles oculos especias com muitas lentes procurando os detalhes. Eles são excelentes nos detalhes. Eles enxergam a “small picture”. Os generalistas enxergam a imagem maior (“big picture”). De longe, como uma águia que procura o problema e desce rapidamente na terra para matar o problema.
Uma equipe para ser produtiva tem que ter uma mistura saudável de especialistas e generalistas, sendo que é melhor ter generalistas com especialidades.
Mas cuidado, não se confunda “generalista” com fanfarrão, ou com o cara que diz que faz tudo mas não é bom em nada. Para ser um generalista legitimo, ha que fazer direito várias coisas. Os famosos bombeiros ( o cara que fica apagando fogo de um lado para o outro) não necessariamente é um generalista. Especialmente se ele que começa os incêndios.
Não ha nada de mal em ser um bom especialista, seja de domínio, de tecnologia , de modelagem , etc… nem ha nada de errado em ser um generalista. Contudo imagine que tem mais chances de sobreviver num ecosistema em constante mudança ? Por exemplo, à 40 anos atrás DBA era o cara. Os sistemas existiam em stores procedures. Hoje que o banco de dados é commodity e temos o NoSQL ( Not Only SQL) esta profissão – como especialidade única – coloca a pessoa em risco de não trabalhar mais. Não ha como negar que especialidade é sinônimo de limitação. Por outro lado, um generalista está limitado pela sua capacidade de saber os detalhes. Porque ele não sabe ou procura os detalhes pode fazer as coisas mais levianamente que um especialista faria.
Ser especialista ou generalista é inerente ao profissional , mas da mesma forma que uma pessoa apenas boa no serrote ou na glosa não pode se considerar um carpinteiro, da mesma forma uma pessoa que só sabe programar ou só sabe trabalhar com bando de dados, ou só sabe modelar, não se pode chamar de desenvolvedor. Ao entrar no mundo do trabalho voce pode entrar como especialista ou como generalista, é você que escolhe. É comum ver as pessoas entrarem como iniciantes e nem saberem sequer programar, quanto mais levantar requisitos e fazer testes, mas se nunca tentar a pessoa não sabe se é boa ou não nessas tarefas. Por outro lado, ninguém é sênior sabendo apenas programar. Maior nivel de aptidão (skill) significa também mais aptidões.
É isto que diferencia os desenvolvedores. É isto que tem que procurar durante as entrevistas. É nisto que tem que pensar ao formar uma equipe. Você quer muitos especialistas, muitos generalistas, ou é melhor ter apenas alguns generalistas com especialidades ? Por outro lado, como membro de uma equipe, como você pode ser mais útil ?
A meu ver o mundo da especialização e das fábricas está mudando para o mundo generalista com especialidades e modelo de oficina. Em uma oficina de carpintaria qualquer um sabe serra e usar uma glosa. Senão, o produto sairia muito caro. Isto não significa que de vez em quanto uma peça especifica não tenha que ser feita fora, por alguém que percebe mais : um especialista… mas não é comum.