O que pode dar errado no primeiro projeto de um programador como freelancer

Confira a história do primeiro projeto de um desenvolvedor freelancer ainda na faculdade, tudo que poderia e que deu errado e quais as lições aprendidas.

Essa semana indo levar minha sogra no ponto de ônibus ela me perguntou se eu continuava fazendo “bico”, como o pessoal mais antigo chama. Trabalho em projetos extras desde a faculdade e particularmente gosto bastante desse contato direto com o cliente.

Essa pergunta dela me fez pensar sobre alguns trabalhos que já tinha feito, como consegui fechá-los, o que aprendi e onde quebrei a cara. Achei que daria um post legal a história do meu primeiro projeto. Tomara que dê mesmo! :)

Curso OpenAPI - Documentando APIs

Conhecer o curso

Senta que lá vem história

Inicialmente tinha pensado em fazer uma lista das coisas que aprendi, pontos positivos e negativos, algo bem clichê. Porém, pensando com mais calma, acho que contando um pouco da história do projeto é possível entender como cheguei às conclusões.

A primeira vez agente nunca esquece

Quando ainda estava na faculdade trabalhava em uma empresa pequena de suporte e manutenção de redes. Um amigo que trabalhava comigo vivia me dizendo que eu precisava ter um sistema para vender, ganhar dinheiro, como se fosse a coisa mais simples do mundo.

Um belo dia esse amigo chegou falando que um cliente dele estava abrindo uma empresa, precisava de um sistema. Na época não tinha muita experiência, tinha apenas feito alguns projetinhos na faculdade, mas de tanto ele falar acabei aceitando ir conversar com o cliente. Antes mesmo da primeira reunião já conversei com um colega da faculdade que trabalhava com Delphi bastante tempo se ele toparia fazer o projeto comigo. Fui na reunião com o cliente sozinho, entendi mais ou menos o que ele queria, falei para ele quanto era cobrado por hora e alguns outros detalhes.

Vendo que realmente existia a possibilidade de o projeto ser fechado, conversei com colega da faculdade e fizemos diversas reuniões com o cliente até definir mais ou menos o escopo e fechar o valor.

Como não sabia programar muito bem, o combinado com o meu colega de faculdade foi que eu levantaria os requisitos e faria as reuniões com o cliente e ele programaria. O cliente não tinha a menor ideia disso, na cabeça dele ambos tínhamos o mesmo conhecimento técnico e nós fizemos questão que ele acreditasse nisso.

No começo tudo foi muito bem, meu colega tinha grande conhecimento em Delphi. Usou uma arquitetura com DataSnap o que na época era algo bem legal, usava recursos e componentes avançados do Delphi, tudo extremamente profissional. Só que não. (tomara que ele não leia esse artigo :P).

Curso Usabilidade para interfaces Web

Conhecer o curso

As entregas que ele fazia geralmente apresentavam alguns problemas e o cliente queria que fossem corrigidas rapidamente. Porém, como ele também trabalhava, tinha vários freelas e a faculdade não dava tempo. Como eu conhecia bem pouco de programação também não conseguia corrigir, com isso o cliente ficava bem bravo, me ligava direto, além daquele meu amigo do começo da história ficar me cobrando toda hora por ter indicado o cliente.

Depois de um tempo a coisa começou a piorar. Como é comum em projetos onde valor fechado no início e o escopo do projeto é mal definido, toda hora o cliente queria uma coisa nova que falava que estava no escopo, além de estar sempre querendo mudar algo.

Com isso, meu colega programador acabou pegando raiva do cliente, então que a coisa não andava mesmo. Resolvi então eu mesmo programar ao menos as coisas que tínhamos ao meu ponto combinado com o cliente.

Lembro que uma das coisas que desenvolvi foi uma importação de XML de notas fiscais, para quem nunca teve a curiosidade de abrir um arquivo desse, geralmente eles possuem muitas informações. Criei uma tabela com uns 80 campos no banco de dados tudo varchar, só para ter uma ideia da qualidade do serviço. Por incrível que pareça, ainda acabou funcionando melhor para o usuário final do que algumas funções que meu colega tinha feito com a mais alta elegância que o Delphi oferecia.

Com o tempo, o próprio cliente foi percebendo que não era eu quem programava. Ele também percebeu que apesar não ter conhecimento técnico estava fazendo o máximo para tentar ajudá-lo. Isso fez com que ele entendesse também meu lado e acabei contando a situação real.

Aos trancos e barrancos o projeto acabou sendo concluído. Não ficou o projeto dos sonhos do cliente, até porque isso é bem difícil na maioria dos casos, mas ele conseguia usar e fazer os processos necessários que tínhamos combinado no início do projeto. O cliente só nunca mais conseguiu realizar nenhuma alteração no programa, nem mesmo pagando, pois meu colega demorava tanto para fazer que o cliente teve que acabar comprando o código fonte e passar para outro programador Delphi.

Ao ver essa história você deve ter concluído que o cliente nunca mais quis me ver nem pintado a ouro. Mas, na verdade, não. Inclusive, alguns anos depois fiz um serviço para ele, dessa vez tinha bastante conhecimento técnico e o projeto andou muito bem. Caso você tenha dúvidas sobre ser freelancer, temos um artigo com dicas de como ser um profissional freelancer.

Algumas coisas que aprendi nesse projeto

Abaixo compartilho algumas coisas que aprendi com esse projeto:

Se pegar um projeto que dependerá de outras pessoas para que ele seja concluído, é preciso tomar muito cuidado, pois, se algo der errado, a pessoa cobrada será você.
Nunca devemos esconder algo do cliente, pois quando o problema acontece fica bem mais complicado, se ele já souber desde o começo já contará com aquela possibilidade.
Sempre se coloque no lugar do cliente, conversar, tentar entender e resolver os problemas em relação ao projeto.
Não deixe o projeto totalmente na mão de outra pessoa ao ponto de que você não tenha como continuar caso algo aconteça.
Antes de pegar um trabalho é necessário o mínimo de conhecimento técnico das ferramentas utilizadas. Nem sempre conhecemos tudo que vamos usar em um projeto, porém, a maioria precisamos conhecer.
Gerar valor para o cliente é mais importante do que soluções técnicas avançadas e de última “geração”. Não que seja necessário fazer gambiarra, mas muitas vezes o cliente não quer saber qual a arquitetura ou as ferramentas que está utilizando, mas do sistema funcionando.
Definir bem o escopo do projeto no início, por mais que isso pareça impossível. Ou cobrar por hora e usar um processo de desenvolvimento ágil, para tentar garantir os requisitos e expectativas do cliente.