17 de março de 2011

Qual é a melhor forma de avaliar um desenvolvedor?

Os desenvolvedores de software enfrentam uma questão importante: seu valor no mercado. É certo que existe uma média salarial, mas como diferenciar-se da multidão? O que você tem, que seus colegas de sala podem não ter?

Essa mesma dúvida seu chefe provavelmente também tem a seu respeito: “A quem eu devo promover?”. Muitas vezes seu diferencial é tão particular que ninguém vê. Nem você mesmo!

Para evitarmos a mesmice, procuramos nos diversificar. Até aí corremos o risco de cair na mesmice, afinal sempre encaramos as coisas com o olhar tecnológico. Afinal, quanto mais sabemos, mais temos a oportunidade de contribuir, certo? Só se você diversificar dentro do leque de opções que interesse seu cliente ou seu empregador, caso você queira continuar trabalhando com eles.

Muitos procuram as tecnologias que estão na crista da onda. Esses nunca serão realmente especialistas em nada. São generalistas e há espaço para eles.

Outros, procuram entregar tudo no prazo, cumprir horário, seguir o script como manda o figurino, mas não ligam o computador em casa. Eles realmente não gostam da profissão e nunca vão se destacar, nunca deixarão um legado. Também há espaço para esses.

Talvez se soubéssemos como somos avaliados, poderíamos focar nossos esforços para “ficarmos bem na foto”.

Já fui avaliado por linhas de código produzidas. Isso mesmo! “Fulano fez só Y linhas de código. Esse é enrolado!”

Já vi avaliação por Pontos de Função entregues! Gente, os Pontos de Função são uma métrica de tamanho de sistema (apesar das controvérsias), não de produtividade. Até hoje muitas empresas insistem em estabelecer uma produtividade média em Pontos de Função, conforme a linguagem. [Não sei se é melhor do que as tais linhas de código.]

Também conheço desenvolvedores que eram premiados ou punidos porque entregaram certo volume de programas por semana ou por mês. Bem viajado, isso, né? E se os 15 programas fossem pequenos e simples, contra 1 grandão e complexo? [E as linhas de código ainda ficam na lembrança.]

Eu já tive que avaliar membros da minha equipe, para promovê-los (!!!), com base na pontualidade. E sem eles saberem disso! :-o (Hoje vejo que não tínhamos relógio de ponto, mas eu era o porteiro que fazia “cara x crachá”). [Agora to achando que as linhas de código já fazem algum sentido.]

Existem também os “desenvolvedores” que são avaliados pela quantidade de especificações feitas. É... como se o cliente pudesse executar uma especificação. E, pior, aonde vi isso em prática, normalmente os desenvolvedores seniores eram os escolhidos para escreverem as tais especificações. Pergunta se a turma gostava de trocar o editor de programas, pelo Word! [Que saudade da avaliação por linhas de código!]

Sem falar naquele método de avaliação chamado “gente-boísmo”. Esse eu tenho certeza que você também já viu. Sabe aquele cara gente boa, que todo mundo gosta? É o promovido. O resto, que não tem muito tempo pra fazer “as honras da casa”, continua ralando sem promoção. [Pô, as linhas de código até parecem justas agora. Pelo menos o cara trabalhava.]

E o codificador programador que leva uma baita ensaboada porque seguiu a tal especificação do tal sênior que ganhou a promoção? Ele fez o que o papel mandava, mas pagou o preço porque o programa não funcionou. [Salve as linhas de código!]

Olha, essas situações acima não são folclore. Eu já presenciei todas essas formas de avaliação.

Mas, nunca vi um desenvolvedor ser avaliado pelo retorno financeiro que ele deu ao negócio. Já vir se dispensado, mas nunca promovido. Outro dia eu conversava com um amigo que ajudou a empresa a reduzir os gastos com telefone celular, de R$ 34.000 (trinta e quatro mil) por mês, para R$ 2.500 (dois mil e quinhentos). Não sei exatamente como, mas fez.

Já pensou se a empresa estendesse por mais um mês o gasto antigo, e bonificasse meu amigo em R$ 31.500 uma única vez? Acho que ele não ficaria chateado, nem pensaria em sair dessa empresa.

Quando as empresas resolverem premiar seus desenvolvedores pelo retorno que eles dão ao negócio, teremos mais criatividade posta em prática, sistemas mais simples e enxutos, e desenvolvidos em tempo menor.

Então, saberíamos que a melhor forma de melhorar na vida seria preocupar-nos com o negócio da empresa, ao invés de encarar a tecnologia como um fim em si mesmo.

Para quem se interessa por Agile, esse seria o mundo perfeito. Mas, fico pensando, para quem gosta de se esconder atrás de especificações, qual seria a alternativa?

Na sua opinião, qual é a melhor forma de avaliar um desenvolvedor?

8 de março de 2011

Rails for Zombies

Anota aí: http://railsforzombies.org É... Rails para Zumbis!

A princípio pode parecer brincadeira, mas não é. O curso é bem prático, com exercícios interativos e muito objetivo.

Aliás, fico impressionado como os rubystas têm a capacidade de inovar e fazer coisas sérias com um aspecto bem legal.

Esse curso gratuito e introdutório de Ruby on Rails é muito gostoso de fazer. Em apenas 5 lições tem-se uma visão ampla de como o Rails funciona, abordando Models, Views, Controllers e Routes de uma forma muito natural.

Recomendadíssimo!

Obs.: peguei essa dica no blog do Leo Hackin http://www.leohackin.com.br/2011/03/ruby-on-rails-referencias-de-leitura