Armadilha: evitando o programador picareta

Texto escrito em 2014

Está precisando contratar um programador? Este post talvez lhe economize uma fortuna. Vou expor a seguir algumas dicas para lhe ajudar a negociar com bons programadores e, ainda mais importante: te ajudar a detectar "profissionais" ruins. Estas diretivas devem ser aplicadas principalmente no seu primeiro contato com o provedor de serviços.

Verifique o currículo

Muitas vezes o profissional se apresenta como "o cara". É o sujeito capaz de resolver todos os seus problemas, um gênio do desenvolvimento e irá lhe cobrar um valor significativo seja sob a forma de valor hora, escopo fechado, demanda ou qualquer outro tipo de medição.

(Lembre-se do conceito real de caro. Algo só é caro se o valor que você paga não te dá um retorno que justifique o investimento.
Um profissional com valor hora alto que resolve seu problema rápido na realidade é barato)

Ok: se o seu valor hora é de, digamos R$ 1000,00, algo deve justificar este preço, certo? O que justifica é o seu currículo. Sempre peça o seu currículo. Se for uma empresa, pergunte pela carteira de clientes. Quem não deve não teme, então nada há de errado com este pedido.

Analise este currículo. Formação acadêmica não é fundamental, mas prática sim. Observe os trabalhos que esta pessoa desenvolveu e, se possível, caso não tenha qualquer conhecimento a respeito do sujeito, ligue para estes clientes e pergunte a seu respeito. Você está simplesmente checando referências. Me assusta o fato das pessoas não fazerem este tipo de coisa.

(aqui em BH, por exemplo, há um caso famoso de um "ex funcionário do Google" que passeia pelas empresas mas que ninguém do Google nunca ouviu falar a respeito)

É uma empresa? Melhor ainda, você pode ligar para os cases que ela te citou e pegar feedback a respeito também. Não se envergonhe a respeito.

Há certificações no currículo? Peça para que sejam expostos os certificados. Pode parecer chato em um primeiro momento, mas dado que você está diante de um desconhecido o que há de errado nisto? Internet também é sua amiga, use-a para saber mais a respeito do profissional. Sites como Linkedin (http://www.linkedin.com) por exemplo são muito úteis para validar estes dados. Se houver menções a projetos open source, verifique as listas de discussão de desenvolvedores. Será que ele aparece realmente por lá? Será que é bem visto?

Talvez o sujeito seja novato e não tenha um currículo formado. Talvez você seja seu primeiro cliente. Neste caso, tenha consigo alguém que te ajude a analisar este programador/empresa. Leve em consideração que qualquer absurdo que este sujeito está dizendo pode ser mera falta de experiência. Use isto para negociar o preço, pois você está na realidade aceitando um risco. Lembre também que no caso do novato pode ser uma aposta que dê muito certo, e que gere um relacionamento extremamente frutífero para ambos os lados.

Entenda o sujeito e dialogue

Sempre digo isto: se você conhece algo, então é capaz de descrever seu conhecimento em palavras. Isto é fundamental no momento em que você for passar a primeira tarefa a este profissional. Aliás, considero este um dos principais testes que poderão ser feitos.

Diga-lhe exatamente o que quer: esforce-se ao máximo em conseguir descrever bem o que precisa ser feito. Uma resposta você terá de receber após sua descrição. Recebeu apenas um "ok, vou fazer", tá errado. Peça ao profissional que lhe explique exatamente o que irá fazer em seu sistema. Talvez não dê pra te dar uma resposta na hora: aguarde por um e-mail, é justo.

Entendeu o que o profissional disse? Perfeito, passou no teste. Não entendeu? Peça para que ele lhe explique melhor. Se após diversas tentativas mesmo assim não conseguir entender, siga um dos caminhos a seguir:

• Se auto critique: será que não é você que não explicou direito a situação? Será que não deveria deixar de lado momentaneamente esta demanda para estuda-la melhor e com isto elaborar uma melhor descrição?
• O sujeito não sabe do que está falando. Simples assim. (leve como exceção o caso do novato)

Se não há entendimento entre ambas as partes e você estiver lidando com um programador picareta, tenha certeza de que você será ludibriado.

Dica importantíssima: tenha tudo por escrito após o comum acordo e você ter sentido segurança de que ambas as partes entenderam bem o problema.

Entenda e questione o preço

Você expôs a sua demanda e percebeu que foi bem compreendida pelo programador. Chega o momento do preço. Este pode ser apresentado sob diversas maneiras: horas, escopo fechado, valor mensal, etc.

Se o valor é dado por quem oferece o serviço, procure entende-lo. Se for por valor hora, leve o histórico do profissional/empresa assim como seu currículo em consideração. Pode ser uma excelente justificativa.

Um modo bastante comum de se dar preço é por hora. Exemplo: para a demanda X vou precisar de W horas, e o valor da minha hora é Y.

Não tenha medo de questionar o porquê destas horas. Dica importante: peça para que o profissional descreva sua estimativa de horas. Vou lhe dar um exemplo de estimativa ruim.

"Oi Fulano, para integrar seu site com o PagSeguro vou levar 32 horas"
"Ah Ciclano, perfeito. Quais as atividades que estarão envolvidas e que levarão este tanto de tempo?"
"Uma única atividade: integrar seu site com o PagSeguro. Levará 32 horas"

ERRADO! Por padrão não aceito uma tarefa que ocupe mais de oito horas, que corresponde a um dia de trabalho. Não aceite este tipo de estimativa. Para mais de oito horas (ou o valor que você padronizar para si), EXIJA que seja exposta uma decomposição. Veja como passa a fazer mais sentido agora:

"Oi Fulano, para integrar seu site com o PagSeguro vou levar 24 horas."
"Ah Ciclano, perfeito. Quais as atividades envolvidas e que levarão a este tanto."
"Bom, como nunca trabalhei com PagSeguro, peço umas 4 horas para estudar a API.
Tenho de alterar o modo como é feito o pagamento hoje, está bem escrito, levará 4 horas.
Logo em seguida terá um período de homologação de 8 horas.
E pra finalizar, terá também os ajustes de layout, muitas páginas terão de mudar (páginas x, y, z) o que dará umas duas horas para cada uma. Duas horas coloquei por contingência"

Agora há espaço para negociação. Talvez você não tenha dinheiro para pagar 24 horas. Mas pode pagar pela análise do seu sistema se achar correto.

Dica: extraia valor de tudo. Se for pagar para alguém estudar o seu sistema, peça que lhe seja enviado um parecer técnico. É uma API nova, peça que seja fornecido um pequeno tutorial sobre como esta funciona. Isto te dá mobilidade de fornecedor pois você está na realidade documentando seu sistema. Lembre-se: você não é um programador.

É outra unidade de valor que não seja hora? Questione e só aceite após entende-la, e bem.

Sempre saiba o valor do trabalho ANTES que este seja executado

Ponto fundamental: em hipótese alguma permita que o trabalho seja executado antes de saber quanto irá custar. Exija uma estimativa para evitar prejuízos gigantescos (tal como mencionei no início deste post).

Antes do profissional por a mão no seu código exija uma estimativa e questione-a como expus acima. É a sua chance de inclusive barganhar. Ao quebrar a tarefa talvez você identifique itens que saiba serem desnecessários (ao menos acredita que sejam, o diálogo pode provar o contrário).

Se você passa a tarefa para o sujeito sem pedir uma estimativa, o sujeito pode te cobrar quantas horas quiser. E juridicamente não há muito o que possa ser feito. Será sua palavra contra a dele.

Pode ser que a estimativa esteja errada (é por isto que se chama estimativa), neste caso, o profissional deverá entrar em contato com você para que seja feita uma renegociação. Não há nada de errado com isto, pelo contrário: mostra maturidade.

Teste o resultado do trabalho

Não aceite que o resultado do trabalho desenvolvido vá para o seu ambiente de produção imediatamente. Sempre teste o que lhe for fornecido para garantir que a tarefa foi bem implementada.

Tenha sempre no mínimo dois ambientes de execução. Um que é o seu de produção (o que é usado de verdade) e um de testes. No de testes você irá verificar se o que foi pedido foi feito. É a sua chance de evitar problemas sérios com os usuários do seu sistema e também avaliar a qualidade do trabalho que lhe foi fornecido.

Trabalho feito é aquele em uso no ambiente de produção e funcionando. Se não saiu do ambiente de testes, é por que não está pronto. Leve isto em consideração na hora de pagar pelo trabalho freelancer.

Concluindo

Sei que estas dicas parecem bobas mas vejo repetidas vezes péssimos "profissionais" se aproveitarem destes pontos e com isto lesar clientes e sujar a imagem de desenvolvedores honestos e competentes. São pontos simples, eu sei: mas muitas vezes o cliente por timidez ou falta de experiência acaba se esquecendo ou mesmo ignora completamente sua existência.

Espero com isto ter lhe ajudado a contratar e encontrar melhores profissionais de desenvolvimento. O bom programador não quer um relacionamento rápido com seu cliente: quer algo que dure. E pra isto age certo. Lembre-se disto.