Fragmental

Este tópico está na minha fila de posts há meses, hora de sair algo. Eu vou me basear num e-mail que recebi de uma pessoa do GUJ (cujo nome não será mencionado pois não pedi autorização para tal):

Sobre o “polêmico” manjado tópico de que o java pode acabar.

Você postou o seguinte (na primeira página):

Software é programar. Se você que gerenciar uma equipe de desenvolvimento você tem que estudar matérias relacionadas à gestão de pessoas. Isso não é uma evolução do programador, um desenvolvedor de software é sempre um desenvolvedor de software.

Será que alguém que se forma em Ciência da Computação (como eu, se Deus quiser) não consegue o cargo de gerência de equipe? Eu vejo isso pelo meu tio… ele é formado em Engenharia Química e hoje é gerente de um empesa aqui, mas porquê? Porque ele conhece como as coisas funcionam… todo gerente que conheço ou que já ouvi falar aconteceu o mesmo… gerentes de supermercado geralmente sabem tudo o que se passa dentro do maldito mercado! Concorda? Logo, começa-se como programador, pra depois passar pra cima. Ou não? Você já foi programador? Estou em dúvida porque parece que o salário de um programdor (caso eu seja programdor pra vida inteira, que é algo que eu não quero) é baixo e não dê pra sustentar uma família, entende? Da maneira que eu digo faz parecer que eu não quero ser programador JAMAIS, mas eu quero… putz, amo programar, tenho um tesão gigantesco por programação… mas o problema é se vai me sustentar bem e minha família pro resto da vida, entende? Acredito que se um dia eu chegar a um cargo que não envolva programação eu ainda assim vou programar, pra me divertir mesmo.

E aí, o que você acha?

Este é um problema bem grande. Vamos começar sobre algo que não está explícito no e-mail acima mas que existe: aquilo que alguns chamam de analista de sistemas.

Quando eu estava na faculdade pela primeira vez (ou seja: antes de abandoná-la pela primeira vez) lembro de ter aula com um daqueles professores com anos de COBOL nas costas. Ele se lamentava sobre como o mercado confundia analistas e programadores e como estava surgindo a bizarrice do ‘progranalista’- alguém que combinava os dois papéis. Na comunidade em geral você vê este pensamento, eu tenho muitos conhecidos que querem ser ‘analistas’, e isto para eles significa desenhar UML ou fluxogramas que são passados para os programadores.

Creio que já tenha escrito sobre este assunto neste blog mas, resumindo, não há justificativa para este papel existir no desenvolvimento de sistemas nos últimos dez anos. O papel do analista seria, teoricamente, converter um modelo abstrato (de negócios) em um modelo lógico, geralmente expresso de forma gráfica. O modelo lógico então passa a um modelo físico, que é a implementação.

Agora vamos analisar o caso de uma plataforma moderna de desenvolvimento como Java, .Net ou Ruby - ‘moderna’ aqui significando algo como “inventada nos últimos dez anos”. Um modelo abstrato é composto por conceitos de negócio. Geralmente estes conceitos não possuem uma estrutura que um computador entenda, logo o analista vai traduzir este conceito em lógica, provavelmente usando UML. Ora, UML é apenas uma notação gráfica para classes e objetos, e sua linguagem favorita já trabalha com classes e objetos! A tradução entre um modelo lógico e o modelo físico é desnecessária: o modelo lógico já é o modelo físico. A diferença é que UML não executa, por mais que os evangelistas de MDA cismem do contrário.

A solução? Modele em código. Caso seja necessário gerar diagramas basta utilizar uma das dezenas de ferramentas de engenharia reversa. Modelando em código você tem algo executável, testável e que pode dar feedback ao seu usuário.

“Analista de sistemas” é algo que não existe. Pode ter existido um dia, não sei, mas não faz mais sentido há muitos anos. O modelo lógico é expresso em linguagens de alto nível que modelam muito bem o negócio: Java, Ruby, C#… Quem converte o lógico em físico é o compilador, que traduz as abstrações em código de máquina.

Alguém colocar na sua assinatura de e-mail ou ter a carteira assinada (como eu já tive!) como “Analista Java” está se enganando e colaborando para a criação de papéis que só existem na burocracia das empresas e das pessoas.

Ok, sem diagramas de objetos então, mas e a parte do papel do analista de resolver problemas de negócio? Sinto informar mas se você fazia isso como parte das suas tarefas de “analista de sistemas” você estava ou se enganando ou enganando seu cliente. É certo que muitos clientes precisam entender seus próprios negócios antes de criar um sistema, mas isso não é papel de analista de sistemas, é papel de analista de negócios.

Um analista deste tipo possui capacitação em campos bem diferentes, é completamente possível que um analista de negócios seja um desenvolvedor (vamos abolir o “analista de sistemas” a partir daqui) mas neste caso ele está assumindo duas especialidades. Um analista de negócios possui um perfil não-técnico e provavelmente mais especializado em um domínio como bancos, marketing, telecomunicações e etc.

Mas e o gerente? Uma das piores coisas que podem fazer em uma empresa é promover um bom técnico à gerente (coordenador, o que for) apens porque ele está há muito tempo na casa. Querem estimular a pessoa? Transormem em um líder técnico, aumentem seu salário e o deixem em paz.

Gerência não é brincadeira. Não é porque alguém programa muito bem que vai ser um bom gerente. Se você é desenvolvedor mas sonha em dizer para a paquera no barzinho que é gerente de algo (nem que seja do McDonald’s) invista nisso. Aprenda sobre liderança, sobre mercado, plano de negócios, luxo de caixa, lean e todas as dezenas de disciplinas envolvidas. Vai levar algum tempo.

Só não encare isto como uma evolução. Você não está evoluindo, está mudando de carreira -da área técnica para a gerencial. Considerando que conseguir bons salários como técnico é complicado, pode ser uma boa escolha. Mas não necessariamente é a melhor escolha, se você é um bom técnico e não quer deixar isso de lado existem opções…

Há mais de dois anos que entrevistar candidatos faz parte do meu dia-a-dia. Neste período eu aprendi bastante sobre como entrevistar e ser entrevistado, acho que é um bom momento para compartilhar… não estou dizendo que o texto abaixo é ótimo, é aplicável ao seu caso, ou sequer que você deva usar. É apenas uma descrição sobre o que eu tenho de experiência nesta área.

Lição 1: Seja Claro no que Procura

Não são só arquiteturas que sofrem com padronização desnecessária, entrevistas também devem ser desenhadas de acordo a situação, especialmente com o que se espera encontrar.

É preciso saber o que se procura. Geralmente alguém decide que a equipe precisa de mais um ou mais membros para ter melhor performance mas a primeira coisa a fazer -como sempre- é fugir do senso comum e se perguntar: é isso mesmo? Será que estamos fazendo as coisas certas? Será que não podemos melhorar nosso desempenho simplesmente mudando a forma de trabalho? Empresas de três letras ensinaram ao mercado que quando um projeto vai mal devemos enfiar pessoas nele (e cobrar por homem/hora, não se esqueça) mas isso é simplesmente contra tudo que sabemos sobre projetos de software. Enfiar mais pessoas em um projeto só o faz atrasar mais (leia Fred Brooks).

Se a resposta for realmente mais pessoas, então que tipo de profissional precisamos contratar? Seja lá o que for deixe bem claro no anúncio, você não vai evitar que panfletadores de curriculum encham sua caixa de email (aliás, crie uma caixa só para isso e desative-a quando não existirem mais vagas) mas vai melhorar as chances que alguém realmente interessante e interessado responda. Também não coloque em qualquer lugar seu anúncio, divulgue em listas especializadas e em grupos de pessoas que confie. Aliás, grupos de pessoas são ótimos porque você pode verificar o histórico da pessoa que enviar o curriculum.

Lição 2: Capriche na Triagem

Se você for bem específico como sugeri na lição acima dificilmente vai ter uma chuva de curriculums, mas caso tenha uma técnica de triagem se faz necessária. Se você tem tempo faça a primeira entrevista por telefone. Se você não tem muito tempo sequer para entrevistas presenciais faça o seguinte: crie uma lista com alguns problemas e peça para o cara resolver e te mandar a resposta.

Os problemas precisam ser diferentes, crie um problema sobre concorrência, um sobre otimização, um sobre modelagem, eles precisam ter o mesmo nível de dificuldade também. O problema que a pessoa escolher (só deve escolher um) te diz sobre o perfil dela. Depois faça uma revisão via telefone do código com a pessoa, é mais para evitar fraude mas ainda assim é uma ótima oportunidade para perguntar alguns aspectos técnicos, porque tomou a decisão X e não fez Y, como refatorar a solução para que fique mais XYZ, etc.

Lição 3: Nada de Perguntas McDonald’s

Para entrar numa grande empresa fui entrevistado pelo meu futuro gerente. Ele tinha na mão uma lista com umas 10 páginas de perguntas variadas sobre Java e SQL, basicamente. Após a segunda página nós já havíamos abolido a folha e partido para um fluxo mais aberto de conhecimento mútuo. Dessa experiência eu tirei um fluxo de entrevista um pouco diferente do que costumo ver.

Quando seleciono um curriculum eu geralmente monto um estereótipo para aquela pessoa: “Arquiteto”, “junior”, “pleno”, “especialista em XXX”, “enrolão”, etc. Deste estereótipo eu penso em algumas primeiras perguntas.

Quando a pessoa chega eu geralmente peço a ela que se apresente, conte um pouco da sua história. Desta o estereótipo inicial pode ser alterado ou não, geralmente após isso eu já tenho uma boa noção do perfil profissional da pessoa. Aí começam as perguntas reais.

Se eu penso que o cara é junior eu começo com algumas perguntas pedindo para ele descrever conceitos. Eu dificilmente pergunto pelo conceito diretamente mas sim algo que indiretamente vai requisitar dele que o faça, como comparações. Continuando com conceitos eu vejo se possui boas bases ou é apenas apertador de parafusos. Eu continuo perguntando, seguindo os perfis de pleno, arquiteto e especialista até ver que o cara não sabe mais. Muitas vezes encontrei juniores que sabiam mais que arquitetos.

Para “desenvolvedor pleno” a coisa começa relativamente ao contrário. Eu peço para ele descrever alguma coisa em que tenha trabalhado e depois para ele dissecar a arquitetura. No meio do caminho surgem diversos pontos interessantes para explorar como Domain Models, BO/VO, programação concorrente, técnicas de performance, etc. Sempre que possível eu faço perguntas baseadas em um cenário real que eu já tenha vivido, até para a pessoa sentir o tamanho do desafio (é difícil fazer alguns entenderem o tamanho da encrenca). Muita gente morre aqui simplesmente porque não entende nada do que trabalha. O cara está há anos desenvolvendo aplicações e não tem idéia do porque usa um padrão ou outro. Todo mundo sabe responder “um design pattern é uma solução para um problema comum blablabla” mas ninguém sabe dizer que problema o tal do BO/VO soluciona.

Tenho que admitir que para arquitetos o buraco é way over mais embaixo. A coisa começa com descrições sobre arquiteturas que ele já tenha trabalhado e, principalmente, desenhado. Geralmente nestas descrições vai haver uma menção um pouco mais interessante que o usual, como conectores JCA, filas, caches ou clusters. Aí é que está o pulo do gato: um arquiteto tem que saber como isso funciona num projeto. Não importa se na época ele não se entitulava arquiteto, não é admissível alguém que nunca parou para saber como aquilo funcionava! Algumas perguntas sobre arquitetura da JVM são sempre boas também. Você consegue descrever como o Garbage Collector funciona com muita e com pouca memória disponível? Identificar erros mais simples de parametrização da JVM?

Interessante notar que não é preciso responder certo as perguntas. Aliás, eu nem espero que sejam respondidas. As respostas ideais, da melhor para a pior:

1. Resposta certa
2. Caminho certo (não chegou na resposta mas elaborou bem)
3. Resposta errada por uma bobeira qualquer
4. Dizer que não sabe

Nessa lista não está a resposta errada. Se um candidato não assume que não conhece a resposta (e algumas perguntas não supõem que você conheça a resposta!) e chuta ele perde muitos pontos numa entrevista dessa. Mentir sobre projetos e empresas é sempre engraçado, no Rio de Janeiro eu conheço muita gente em muitas empresas e sempre consigo lembrar de alguém que teoricamente teria trabalhado com o candidato no tal projeto.

Eu sempre insisto para a pessoa tentar chegar na resposta ao menos. Na sala sempre vai haver papel e caneta ou um quadro-branco, o ato de seguir por um caminho lógico para tentar chegar à resposta é muito importante. Uma das coisas que consigo verificar assim é escalabilidade, dificilmente aparece alguém que sabe como criar um site que suporte um fluxo muito grande de acessos mas geralmente as pessoas têm pelo menos uma idéia sobre conceitos que podem usar enste caso.

Tem gente que fica muito nervosa neste ponto então é melhor criar o ambiente mais descontraído possível. Aqui isso não é problema, geralmente eu converso com a pessoa com meu jeans e camiseta usual, muitas vezes com o pé na cadeira. Não é para impressionar, é assim que as coisas são e é bom a pessoa saber disso. Eu não quero saber se a pessoa é boa ou ruim, quero apenas saber se ela é quem eu estou procurando neste momento ou não.

Lição 4: Explique o Cenário

Após a entrevista em si eu explico o cenário. Descrevo como as coisas funcionam na equipe, a hierarquia, os tipos de projeto, tecnologias e o que espero da vaga. No final respondo dúvidas.

Por que não antes? Porque pode influenciar a pessoa. Ao ouvir que nós plantamos bananas ele vai se vender como o melhor bananeiro desde Jorge Ben Jor.

Lição 5: Racionalize o Candidato

As vezes você procura um semi-deus e aparecem apenas juniores, as vezes você procura juniores e o próprio Zahl aparece. Hoje em dia um gestor tem que saber flexibilizar seu quadro de pessoal.

Se você tem vaga de senior e arrumou um junior muito interessante que tal dividir a grana do senior em dois? Ou que tal pagar o salário do junior e com o resto do orçamento investir na equipe para que todo mundo suba de nível técnico?

O tipo de entrevista acima não dispensa ninguém. Se na segunda pergunta você já viu que o cara não serve para a vaga continue, descubra quem o cara é. Num mercado como esse no mínimo você pode indicá-lo a outro gestor precisando de pessoas ou guardar na manga para outra oportunidade. Claro que se o cara for ruim ele é ruim e pronto.

Eu sei bem que não é o ideal, mas este modelo de entrevista já me fez boas contratações e, sinceramente, nenhuma ruim. Um dos efeitos ruins é que as vagas demoram bons meses para serem preenchidas mas atualmente isso é “menos pior” do que ficar meses com um desenvolvedor não-qualificado.