Sem muito papo e muita enrolação, seguindo os moldes do meu último “post happy-list”, vamos à lista da felicidade para não precisar passar na farmácia por causa de um projeto, especialmente um sistema, web.
1 - Pegar sistema “pela metade” pra completar, nem pensar!
Eu juro pra vocês que estou neste momento terminando um sistema que se encaixa neste item. Mas estou porque é para alguém conhecido, apenas como uma ajuda, porque isto dá uma dor de cabeça dos infernos! Analise comigo: o tiozinho liga para você, ele tem um “sisteminha”que o sobrinho dele começou a fazer mas não conseguiu terminar, e pergunta se você pode terminar o sistema. O que você responde? “Sim, é claro”… NÃO! Repita comigo: Não! Não pegue sistema pela metade pra completar, isto é suicídio. Imagina pegar um sistema com modelo de dados mal-projetados, que não seguem nenhum tipo de padrão ou convenção, telas todas geradas com tabelas por um WYSIWYG qualquer, controllers sem identação e com nomes de variáveis tipo $incredibleCrazyHugeNameVariable, e por aí vai… segue aqui para o divertimento de vocês uma pequena demonstração da estrutura de um banco de dados que eu vi em um sistema escrito por um maluco estripador programador:
Trata-se de uma tabela com cidades. Começamos com o campo de id, que em vez de simplesmente id, é chamado de id_Cid. Então vemos o campo nome, que em vez de nome se chama nom_cidade, e finalmente o pa_ID que é, certamente, o ID do país… não! É o ID do estado! Está aí um belo exemplo de tabela mal-projetada. Seria correto fazer id,nome,estado_id, ou então id_Cid,nome_Cid e estado_id_Cid, mas não esta mistura sem nexo nenhum.
2 - “E se isso”, “e se aquilo”…
“E se o usuário clicar aqui primeiro e não alí?”, “E se o site estiver fora do ar?”, “E se eu desistir do sistema e quiser todo o meu dinheiro de volta?”… existem pessoas e clientes que gostam de ficar imaginando situações-exceção em vez de imaginar as situações que ocorrem todos os dias no uso de um sistema. Cuidado com os “e se(s)”, eles podem lhe render horas a mais de programação para uma funcionalidade/exceção que nem 0,1% dos seus usuários vão notar, e ao mesmo tempo tirar uma funcionalidade/recurso que 99,9% dos seus usuários sentirão falta.
3 - “Okay, daqui á 6 meses te mostro o sistema funcionando”
Aí está mais uma prática suicida. Depois destes 6 meses você mostra o sistema e ele não era nada do que o cliente imaginava. Por favor, divida o desenvolvimento de um sistema ou site grande em partes menores para que você não passe por isso. Não trabalhe mais que duas semanas sem perguntar para o cliente se está okay até o momento. Pense comigo: se tiver algum problema ou algo que não estiver de acordo com a expectativa do cliente, o que é melhor: refazer 6 meses ou refazer 2 semanas de trabalho?
4 - “Quero um efeito igual ao do Exterminador do Futuro 2″
Esta é clássica: o cliente chega e exige um monte de efeitos e firulas inúteis que só vão te dar mais trabalho e não vão acrescentar em nada (além de kbytes) no site/sistema dele. Minha dica: tente convencê-lo de que isto não vale a pena, se não tiver jeito e você realmente precisar fazer, cobre (e caro) por isso, afinal na maioria das vezes quando somos obrigados a fazer algo do tipo, o site não fica bom o suficiente para o portfólio.
Aí estão algumas das minhas dicas para poder dispensar a aspirina? Quais são as suas? Podem recomendar algum outro remédio, caso a aspirina não esteja adiantando 
