6 Maneiras de Sabotar seu Projeto

Introdução

Desenvolver um software (seja ele um site, API, APP, Chatbot e etc) em geral é uma longa jornada que pode conter algumas armadilhas só esperando para te impedir de prosseguir (quanto sangue de inocentes já foi derrubado nessa estrada… 😃 ).

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á:

 

6 Maneiras de sabotar seu Projeto

1 – Não possuindo um cronograma de entregas realista

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?

Eu compilei o meu processo de Planejamento atual em um e-Book, caso você queira saber mais baixe o “Workflow Super Full Stack” 🙂


2 – Não criando testes automatizados

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!

Desenvolver testes vai te ajudar a desenvolver um código com mais qualidade, mais alinhado com a especificação técnica e vai te ajudar a fazer aquele deploy monstro na Sexta-Feira as 17h59 sem muita culpa.

3 – Largando o projeto assim que algo dá errado

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.

Então se você está em uma fase ruim no seu projeto não desista tão facilmente, grandes projetos como o Google, Facebook e etc passaram por grandes desafios antes de se tornarem o que são, então “coloca a faca nos dentes e bora fazer acontecer”.

4 – Focando mais nas tecnologias utilizadas do que no problema a ser resolvido

“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.


5 – Não tendo um plano claro de como o software será rentabilizado

Você, assim como eu, tem o desejo de empreender e criar coisas novas para tornar a vida das pessoas mais fáceis, então você decide criar uma startup que resolve o problema X do seu público.
Depois de lançar a versão beta você recebe muitos bons feedbacks elogiando o projeto e aí decide partir para a versão estável e finalmente ser recompensado financeiramente por todo o dinheiro e tempo que você se dedicou àquele projeto.

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).

Para evitar isso é necessário ter uma ideia clara de como será a rentabilização do projeto desde o planejamento inicial (inclusive imaginando vários cenários de rentabilização).
Você já sabe como vai rentabilizar seu projeto?


6 – Não homologando parte a parte com o cliente

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.

Ao invés de entregar o software no final do prazo entregue partes funcionais a cada semana (ou duas semanas) dessa forma o cliente vai perceber as diferenças do que ele esperava e você vai poder ajustar antes que os juros aumentem.


Conclusão

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

Se puder, me dê um feedback sobre o que achou do e-Book aqui nos comentários e compartilhe com a gente outras armadilhas que você teve que desviar na hora de entregar um novo projeto.

 

Bons Códigos \o/
Leonardo Scorza

 


Você é novo por aqui?

Primeira vez no OneBitCode? Curtiu esse conteúdo?
O OneBitCode tem muito mais para você!

O OneBitCode trás conteúdos de qualidade e em português sobre programação com foco em Ruby on Rails e outras tecnologias como Angular, Ionic, React, desenvolvimento de Chatbots e etc.

Se você deseja aprender mais, de uma forma natural e dentro de uma comunidade ativa, visite nosso Facebook e nosso Twitter, veja os screencasts e talks no Youtube, alguns acontecimentos no Instagram, ouça os Podcasts e faça parte de nossa Newsletter.

Além disso, também estamos com alguns e-Books muito interessantes para quem deseja se aprimorar como programador e também como freelancer (os e-Books são gratuitos!):

Espero que curta nossos conteúdos e sempre que precisar de ajuda com os tutoriais, fala com a gente!
Seja por
Facebook ou e-mail, estamos aqui para você 🙂

Bem-vindo à família OneBitCode \o/

novembro 3, 2017

6 responses on "6 Maneiras de Sabotar seu Projeto"

  1. Parabéns pelo artigo, prático e incrível. Já tenho o e-book e lerei em breve.

  2. Muito bom, Leonardo, algumas dessas coisas ainda acontecem até hoje, a gente sabendo onde pode errar é mais fácil de evitar.

  3. Essa de entregar feature por feature pro cliente ir acompanho é sensacional!

Deixe uma resposta

Feito com s2 por OneBitCode
%d blogueiros gostam disto: