6 Maneiras de Sabotar seu Projeto

Mas depois de cair em todas elas você começa a compreender como evitá-las (eu já caí 😃 ) e nesse artigo eu vou compartilhar algumas experiências e dicas de como “sabotar” seu projeto, então vamos lá:

Geralmente a maior parte dos desenvolvedores subestima a quantidade de tempo e trabalho que leva para realizar uma determinada tarefa (agora imagine um projeto gigante), principalmente porque se esquecem que não é todo dia que você vai sentar na cadeira e codar com 100% de energia.

Quando eu comecei a minha jornada como freelancer/remoto eu ficava impressionado como sempre eu errava o tempo que iria demorar para realizar um projeto (eu sempre achava que seria mais rápido do que realmente era) e isso as vezes gerava um grande estresse em mim e no cliente.

Com o tempo eu comecei a perceber os padrões que me levavam a estimar o preço/tempo de forma errada e o primeiro ponto é porque eu não sabia falar NÃO.

Como assim falar que não? Geralmente o cliente chega e diz o seguinte: “Veja bem eu tenho aqui um projeto para você mas é coisa simples e rápida, você pode me entregar em uma semana?” E eu respondia (inocentemente) que sim. Mas na hora que o cliente passava uma (semi) especificação eu percebia que o projeto não era assim tão simples e rápido, mas como já tinha fechado o acordo eu ficava com o prejuízo.

O segundo ponto era o seguinte, eu não tinha nenhum planejamento de execução do projeto, portanto era pegar o projeto e sair codando na “sorte” o que geralmente dava errado 😔 .

Quando você não possui uma especificação clara do que deve ser desenvolvido e um passo a passo de como desenvolver, você simplesmente não tem certeza do que deve ser feito, isso gera estresse, refatorações e erro.

Depois que eu ajustei esses dois pontos as coisas começaram a fluir corretamente para mim como desenvolvedor freelancer.

Você tem se sabotado por não saber dizer não ou por não tem um planejamento passo a passo?

Você está todo feliz desenvolvendo seu software em um belo dia de verão e sobe algumas novas funcionalidades X para o servidor de production, 5 minutos depois recebe uma ligação desesperada do seu cliente (ou dono(a) da sua empresa) dizendo que as funcionalidades Y não estão funcionando mais e que você deve arrumar isso para ontem.

Você fica um pouco desconcertado tentando entender o que aconteceu já que você trabalhou nas funcionalidades novas X e não nas funcionalidades antigas Y e depois de debugar por 1 hora percebe que X acabou influenciando em Y mas como você testou apenas X depois de ter subido para production não percebeu que Y tinha quebrado.

Parece familiar? Sim meu amigo isso acontece muito em softwares sem testes automatizados (e eu acredito que pelo menos metade dos softwares rodando atualmente não tem testes) então se você ainda não criou o hábito de gerar testes automatizados (que vão testar todo o seu software antes de subir para production) talvez você esteja querendo sabotar seu projeto!

Você é do tipo de pessoa que desiste assim que as primeiras coisas começam a dar errado? Do tipo que acha que quando algo dá errado é um sinal divino para você desistir e ir por outro caminho? Se esse for o seu caso certamente você vai sabotar compulsivamente seus projetos porque as coisas vão dar errado (antes de dar certo).

Eu não me recordo de nenhum projeto que depois de uma ou duas semanas de trabalho não começaram a surgir Bugs inesperados ou o cliente pediu modificações na especificação ou alguém importante teve que sair da equipe ou qualquer outro tipo de problema que fizesse qualquer desenvolvedor pensar em desistir e partir para outra e também posso dizer que os projetos que deram mais certos (tiveram mais visibilidade ou o cliente ficou mais satisfeito) foram os mesmos que deram mais problema.

“Saiu um novo framework ontem, preciso criar uma startup utilizando ele, certamente vai ser um sucesso!” 😃.

Falando assim fica bem obvio que não faz sentido criar uma nova startup apenas porque saiu um novo framework, mas isso é o que muitos desenvolvedores fazem, colocam a tecnologia à frente do problema que deve ser resolvido.

Um software em geral serve para resolver um problema do seus usuários, seja o aluguel de diárias em casas e apartamentos como é o caso do Airbnb, seja solicitar um carro do trajeto X ao Y como é o caso do Uber, então qual a tecnologia que o Airbnb e o Uber utilizam para prestar esse serviço é indiferente (o importante é que o serviço seja prestado de maneira intuitiva e com qualidade).

“Portanto não escolha a tecnologia e depois o problema que você quer resolver usando ela, escolha o problema que você quer resolver e depois as tecnologias que podem te ajudar a fazer isso de maneira fácil e com qualidade”

No e-Book “Workflow Super Full Stack” depois do planejamento técnico eu faço a definição do stack, que é a escolha das tecnologias que mais se adaptam às minhas habilidades e as necessidades do projeto, vale a pena dar uma olhada nos detalhes.

Mas de repente se depara com uma pergunta assustadora: “Como eu vou fazer para ganhar dinheiro com esse projeto?” E percebe que não tem uma resposta para isso porque a versão entregue em beta tem todas as features (o que inviabiliza um esquema de software “premium”) e o projeto por ser de nicho não vai ter tantas visitas (o que inviabiliza as propagandas).

Você recebeu uma nova solicitação de projeto de um cliente (seja como freelancer ou do seu superior na empresa), você avalia e diz que vai demorar 2 meses e a outra parte concorda e todo mundo é muito feliz por 2 meses enquanto o projeto está sendo desenvolvido.

De vez enquanto o cliente pergunta sobre o andamento do projeto e você todo animado(a) responde: “Estamos indo muito bem, tudo será entregue no prazo como combinado!”

E finalmente chega o tão esperado dia de demonstrar aquele trabalho magnifico que você fez (um software com qualidade, testes automatizados e aquela interface linda), você passa a URL para o cliente que estava aguardando ansiosamente o software e de repente você ouve um “Cara, não foi isso que eu te pedi!”.

Seu mundo cai, todas aquelas horas codando passando diante dos seus olhos e você fica parado tentando entender o que te atingiu.

O cliente continua: “O projeto tinha que ter a feature X e não deveria ter essa feature Y aqui, muda as cores, os textos, o estilo, a lógica……..etc…….etc……..etc”

E aí você percebe que vai levar mais 1 mês para ajustar tudo que foi pedido, lá se vai sua moral, seu ânimo e seu tempo pelo ralo. O que aconteceu? Um erro de alinhamento com juros

Como assim Léo, um erro de alinhamento com juros?

No começo do projeto você recebeu uma especificação feita pelo cliente (que não é um desenvolvedor) com a visão dele de como as coisas deveriam ser, mas na verdade existe uma grande diferença entre o que ele imaginou, o que ele escreveu e o que você entendeu. Somando essas pequenas diferenças em 2 meses de desenvolvimento sem contato entre as partes a diferença no final é expressiva.

Como evitar isto? Entregas parciais.

Desenvolver grandes projetos pode ser desafiador, mas se você evitar essas armadilhas (e mais algumas outras que estão no caminho) certamente vai conseguir entregar seu software com qualidade.

Eu falo sobre o meu método de Planejamento (que é feito para evitar essas armadilhas e melhorar a qualidade do projeto) no e-Book Workflow Super Full Stack que você pode baixar gratuitamente “Clicando Aqui”