O case do marceneiro

Marcio Endo

, 19/06/2011 18:22

Produzir software pode eventualmente ser fácil. Já produzir software de qualidade é extramamente difícil. Muitos [1] já disseram o mesmo então eu não extenderei o assunto.

Apesar dos mais de 50 anos de evolução da área, de nada adiantam as novas ferramentas de desenvolvimento, os avanços na Engenharia de Software, o surgimento das metodologias ágeis ou as novas linguagens de programação se você não tiver as pessoas certas no barco [2].

No final das contas, pode-se resumir a questão inteira a isto: ter os melhores profissionais é condição necessária para que software de qualidade seja produzido.

A objectos é ainda uma empresa muito pequena. Não uso isso como justificativa para eventuais falhas que ocorram, tenham ocorrido ou venham a ocorrer. Mas é fato que, se no Brasil de hoje, mesmo empresas médias e grandes já têm dificuldades para contratar e manter corpo técnico de qualidade, para uma empresa pequena o desafio é ainda maior.

E em dificuldades, imaginação e criatividade ajudam. Em geral e no entanto, e a experiência ajuda-me a comprovar, basta manter-se fiel aos conceitos básicos. Isto é, se é verdade que criatividade e imaginação ajudam quando se têm dificuldades, também é que as soluções mais elegantes (e eventualmente as duradouras) tendem a ser as mais simples.


Desde o início das atividades da objectos, deu-se ênfase ao processo seletivo. No início do ano de 2011, ele foi bastante remodelado. Costumo dizer a praticamente todos os candidatos que entrevisto o seguinte: "em entrevistas o candidato já sabe o que o entrevistador irá perguntar e o entrevistador já sabe o que o candidato irá responder". Cabe, assim, ao entrevistador saber "ler as entrelinhas".

É neste contexto que entrava o case do marceneiro. Meu intuito era avaliar o entendimento (ou não) do candidato sobre profissionalismo em geral e, mais especificamente, qual o entendimento que ele possuía sobre profissionalismo no desenvolvimento de software.

O case era o seguinte:

Suponhamos que você seja um marceneiro. Eu, como cliente, chego a você e peço que me faça um armário. Digo que abri recentemente uma pequena empresa. Por conta disso tenho várias pastas, envelopes e material de escritório espalhados pelas mesas. Preciso, assim, de um armário para guardá-los apropriadamente. Peço que o armário tenha a altura aproximada de uma mesa, largura de uns 80cm e profundidade de uns 30cm. Gostaria que ele tivesse portas e que o espaço interno fosse dividido por uma prateleira.

Uma, duas ou três semanas depois, você me entrega o armário exatamente como foi pedido. Além disso, você escolheu um acabamento muito bonito e de bom gosto, o que me deixa bastante feliz. Satisfeito com seu trabalho, encomendo mais dois armários.

Uma semana, um mês, seis meses ou um ano depois, o tempo exato não é importante, ao abrir o armário para nele guardar os arquivos de novos funcionários, a porta simplesmente não abre. Ao aplicar uma leve força na mesma, ela sai inteira em minhas mãos. Em uma análise mais atenta, percebo que a dobradiça utilizada era de baixa qualidade. Além disso, estava posicionada de maneira errada. Mais que isso, e o que agravou consideravelmente a situação, os parafusos aparentavam ter sido colocados por alguém com bastante pressa.

Ligo para você e devolvo os armários. Nem peço pelo meu dinheiro de volta. Digo apenas: “considerava-o um ótimo marceneiro, percebo agora que estava errado. Qualquer outro armário que precisar, chamarei outro profissional e arrependo-me de tê-lo indicado a amigos.”

Exposta a situação, pedia para que o candidato transpusesse o exemplo para a programação.

Uma grande parte focava na especificação, que o marceneiro não cumprira com o que havia sido pedido e que um programador deve sempre cumprir a especificação.

A verdade é que, do que havia sido especificado, tudo fora cumprido. Além disso, um programador profissional não é aquele que cumpre cegamente o que lhe é especificado. Ele pensa, pondera e oferece a melhor solução ou alternativa o que, por vezes, pode divergir da especificação. Mas esta é outra questão.

Costumava tentar ajudar os candidatos: “pense que, se como marceneiro, sua atividade envolve serrar, furar, pregrar; como programador sua atividade envolve, em última análise, escrever textos”.

Mesmo com a ajuda, não chegavam ao ponto principal: um profissional precisa ter atenção total e irrestrita a todos os detalhes do seu trabalho. Por vezes, assim como demonstrado no caso, detalhes diferenciam a percepção entre um bom trabalho e um mau trabalho.

Reputações inteiras podem, de um momento para outro, ser perdidas.

No caso do armário, a falta de profissionalismo pode ser vista de maneira material: um parafuso. Mas e na programação? Como se vê na prática tais desvios de conduta?

Tento explicar isto a todos que trabalham comigo que, "por sorte" (notem as aspas), clientes em geral preferem distância do código. Afinal, é exatamente para isto que estaremos sendo contratados. Por outro lado e em hipótese alguma, isto pode ser visto como desculpa para descuidar de todos os detalhes do código.

O código é o seu trabalho. Assim, deve-se ter apreço, deve-se ter zelo pelos códigos que são escritos. E isto só é possível se você possui paixão pelo que faz.

Além disso, pode-se adicionar a questão do “fazer o que lhe é pedido”. De fato, no case, não havia pedido especificamente que a porta funcionasse todas as vezes. Por outro lado, também não especifiquei que a porta funcionasse apenas por três ou seis meses e que, depois disso, seria aceitável se ela deixasse de funcionar.

De maneira análoga, não espero ter que pedir todos os dias a um programador que ele faça seu trabalho. E faça-o sempre muito bem dentro da sua capacidade. Não contrato pessoas para que elas façam um mau trabalho e para que, eventualmente, elas façam um bom trabalho.

Da mesma forma, nossos clientes não estarão nos contratando para que os aplicativos funcionem às vezes ou que funcionem “na minha máquina”.

Eles esperarão não menos que um valor agregado maior que o valor investido inicialmente.

blog comments powered by Disqus