Armadilha: evitando o programador picareta

picareta_moderna Recentemente vi um amigo ter um prejuízo significativo ao contratar um “programador” freelancer que não era nada do que dizia. Não foi a primeira nem será a última vez que presenciei algo assim. Como sei o estrago que isto causa à imagem da minha profissão resolvi escrever este post com o objetivo de ajudar a detectar este tipo de pilantra: o programador picareta.

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.

13 thoughts on “Armadilha: evitando o programador picareta

  1. Ótimas dicas, quase sempre ngm leva isso em consideração.
    Como dica, vale tbm agora criar um post a respeito do outro lado, ser ludibriado pelo emprego dos sonhos, até acho mais difícil sermos “dobrados” nessas questão, mas aos novatos valerá a leitura.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Excelente ideia. Vou fazer.

    Responda

    Pedro Henrique Reply:

    Quando eu ouço, “A nossa empresa está crescendo e você crescerá junto (até arrepio) rs”, brincadeiras a parte, é isso aí Fábio, parabéns Kiko pelo excelente blog (mais uma vez).

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Opa, valeu Pedro Henrique! :)

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Já cai nesta. :)

    Eu vou escrever alguma coisa aqui a respeito em breve.
    Depois que fiz o meu TCC sobre assédio moral em fábricas de software (http://www.itexto.net/devkico/?p=1385) percebi uma série de monstruosidades que são cometidas por aí sem que ninguém se dê conta.

    Responda

  2. As dicas são muito boas!
    Atualmente, para avaliar uma conratação estamos levando em consideração os códigos existentes no github.
    Nada melhor de ver os códigos que o profissional produz.
    Muitos dizem: “eu não tenho conta no github”. Para mim é ponto negativo, pois hoje além de gerenciador de fontes ele atua como um portifolio do profissional.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Leandro,

    sim, é interessante olhar o GitHub. Mas tem de ficar muito atento com charlatões. Por issto que no post digo que é uma boa observar as listas de e-mails de projetos open source.

    Digo isto porque já vi e ouvi falar de casos de contas do GitHub com código que não era do autor. Yeap: tem picareta pra tudo. :)

    Responda

  3. Cresce também vertiginosamente o número de clientes picaretas, pessoas que já sabem da complexidade que é conceber a ideia de um software e dão requisitos funcionais superficiais, e são conhecedores do jargão da TI (do programadorês), mas quando você entrega, começam a remendar a colcha, e se o programador não tiver muito jogo de cintura pode arrumar um grande problema, ainda mais se você se esforçar para manter o bom relacionamento atendendo várias demandas, não se engane eles se aproveitam de qualquer falha no seu código para embutir novas coisas, aí quando ele acha um bug é a festa.

    Vide o artigo sobre os exploradores do kiko rs.

    Parabéns, aqui é um lugar onde eu me identifico e aprendo com as coisas que encontro.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Oi Pedro Henrique, bom ouvir isto, obrigado. :)

    Responda

  4. Parabéns Kico. Artigo muito bom, seu blog possui excelente conteúdo.

    Está aí! Uma boa experiência que, infelizmente, estamos longe de absorver (mesmo que seja o mínimo) quando estamos na faculdade.

    Responda

    Kico (Henrique Lobo Weissmann) Reply:

    Que bom que gostou Denis, obrigado!

    Responda

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>