Não Existe Bala de Prata

Se você já fez uma análise de requisitos para desenvolvimento de software muito provavelmente já se sentiu assim também…

A minha dica para você que está tentando descobrir o que o seu cliente quer do seu novo software é a seguinte:

1. Em primeiro lugar nunca pergunte ao cliente o que ele quer que o novo sistema faça.
2. Compreenda como são feitos hoje os processos do cliente.
3. Pergunte ao cliente quais processos que ele sabe que funcionam bem no sistema atual. Faça o cliente explicar porque ele acha que funcionam bem.
4. Descubra quais são processos atuais que existem mas ninguém usa.
5. Baseado nessas informações desenvolva um protótipo do que você acredita que o cliente precisa. Quanto mais claramente esse protótipo puder ser compreendido pelo cliente melhor. Por exemplo, se for um cliente da área técnica você poderá lhe mostrar os casos de uso. Se for um cliente de negócio você vai precisar de algo mais visual…
6. Faça (essa parte às vezes é difícil) o cliente analisar o seu protótipo.
Sempre esteja cara-a-cara com ele enquanto estiver fazendo a análise.
7. Assinale os requisitos que o cliente concorda e aqueles que ele discorda. Baseado nessas informações descubra se ainda existem pontos do processo que você não entendeu corretamente.
8. Faça um novo protótipo. A partir daqui o processo se repete até que o cliente concorde com a maioria dos requisitos do sistema.

Tentar fazer com que todos os requisitos sejam validados e aprovados pelo cliente pode consumir muito tempo. Se o cliente já concordou com a maior parte então está na hora de colocar a mão na massa e começar o desenvolvimento. Quanto aos requisitos que não foram aprovados eles fazem parte dos requisitos que iriam mudar de qualquer jeito…

Desde quando o desenvolvimento de software se tornou uma atividade profissional milhares de pessoas têm tentado medir a produtividade dos seus programadores. E a primeira “métrica” que se imaginou, e talvez a mais famosa, é o loc ou lines of code.
A idéia é bem simples: basta contar quantas novas linhas de código o programador escreveu em cada dia, colocar tudo em uma planilha, e verificar se ele está rendendo mais ou menos.

Claro que hoje é fácil de perceber que não pode haver uma idéia mais absurda do que essa para se medir o trabalho de um programador. Acho que a estória que melhor ilustra essa incoerência foi o que aconteceu com um programador que participava do desenvolvimento do sistema operacional do Lisa, da Apple, em 1982.

Naquela época, os gerentes do projeto decidiram que cada desenvolvedor iria anotar semanalmente quantas linhas de código eles tinham produzido. Um desses desenvolvedores, Bill Atkinson, estava trabalhando na otimização de uma parte de código e acabou reescrevendo toda aquela seção de uma maneira mais genérica e que ainda por cima rodava seis vezes mais rápido. Como conseqüência, esse novo trecho acabou sendo bem mais conciso e acabou economizando 2000 linhas de código.
Quando teve que preencher o relatório de quantas linhas de código tinham sido produzidas, Bill anotou -2000 linhas. Isso mesmo, ele anotou um número negativo, o que deve ter criado uma grande inconsistência nos resultados de acompanhamento do projeto. Algumas semanas depois os gerentes pararam de cobrar a quantidade de linhas de código dos desenvolvedores.
Como desenvolvedor, acredito que qualquer tentativa de medir o progresso através de informações de baixo nível, como o código fonte, não mostra absolutamente nada de conclusivo. Mesmo existindo várias outras métricas mais aprimoradas que derivaram da loc mesmo assim são indicadores de quase nada. Mas o que fazer se, como disse Lord Kelvin, “o que não pode ser medido não existe”?

Eu só vejo uma solução: se você quer medir o progresso do desenvolvimento de um sistema então precisa medir funcionalidades macro. Por exemplo, medir quantos casos de uso foram implementados ou quantas funcionalidades de alto nível estão prontas para serem usadas. Tentar medir em níveis mais baixos que isso pode até gerar planilhas recheadas de números, mas que irão dizer absolutamente nada.

Já faz um tempo eu assisti na tv uma entrevista com o Maurício de Souza, aquele dos gibis da mônica. O que mais me chamou a atenção foi quando ele contou a maneira como ele contrata os seus desenhistas.

Segundo o próprio Maurício, todos os desenhos dos gibis são feitos à mão pela sua equipe, o que exige ter um time bastante entrosado, já que todos os personagens precisam ter um mesmo traço uniforme.

Para contratar um novo desenhista o próprio Maurício passa para o candidato uma "lição de casa", alguns desenhos, e pede para que ele volte alguns meses depois com o material que ele tenha conseguido produzir. Se o candidato volta meses depois e, além do que foi pedido, ele ainda fez outros desenhos, então é passada mais uma lição e, novamente, ele vai para casa treinar e desenhar para apresentar os resultados depois de outro tanto de tempo.

Esse processo se repete várias vezes e pode durar até um ano, mas garante ao estúdio do Maurício de Sousa conseguir encontrar aquele desenhista que realmente tem talento e vontade de fazer parte da equipe.

Para mim esse parece ser um processo bem razoável para encontrar bons desenvolvedores de software. Não quero dizer que ele precise durar um ano inteiro, mas seria bom sempre analisar o código que cada candidato é capaz de produzir. E não estou falando apenas de alguns pequenos trechos de código ou algoritmos de faculdade. Estou falando de escrever um sistema completo. Só assim você vai poder saber se o seu candidato consegue criar código de boa qualidade e que seja de fácil manutenção e alteração. Pedindo para o candidato ir modificando o seu sistema a cada nova entrevista e acompanhando quanto de bangunça ele coloca no próprio código é um bom indicador de como ele irá se comportar quando estiver mexendo nos sistemas da sua empresa.

Em um dos melhores artigos que Joel Spolsky escreveu sobre desenvolvimento de software está "O Teste do Joel: 12 Passos para um Código Melhor", onde um dos passos se refere a contratação dos desenvolvedores:

Você contrata um mágico sem pedir a ele para mostrar alguns truques? Claro que não.

Você contrata um bufê para seu casamento sem provar sua comida? Eu duvido. (A menos que seja sua tia Maria e ela iria odiá-lo para sempre se você não a deixasse fazer seu "famoso" bolo de fígado moído).

Apesar disso, todo dia, programadores são contratados com base num currículo bonito ou porque o entrevistador gostou de conversar com ele. Ou perguntam-se questões triviais ("Qual a diferença entre CreateDialog() e DialogBox()?"), que poderiam ser respondidas com uma olhada na documentação.

Você não deve se preocupar com as habilidades dos candidatos em memorizar milhares de trivialidades sobre programação, você deve se preocupar com suas habilidades em produzir código.Ou, pior ainda, perguntam-se questões "AHA!": o tipo de questões que parecem fáceis quando você sabe a resposta, mas se você não sabe, são impossíveis. Por favor, pare de fazer isto.

Faça o que quiser durante a entrevista, mas faça o candidato escrever algum código.

Eu realmente acredito que se pode conhecer um bom desenvolvedor pelo código que ele escreve. É mais fácil identificar um bom desenvolvedor pelo seu código do que pelo que ele diz em qualquer entrevista.

Bom, finalmente vou começar esse blog… Acho que enrolei demais para fazer isso, afinal de contas já estava com vontade de ter um blog há uns 3 ou 4 meses. Só não saiu antes devido ao meu problema de procrastinação.
É, eu tenho que adimitir, eu sempre acabo adiando as coisas, mesmo aquelas que eu sei eu preciso realmente fazer. Mas não vou falar sobre isso agora, senão eu mesmo me assusto. Afinal, ainda precisa ser feita muita coisa até esse blog ficar “habitável”.
Mas o primeiro passo está dado!