Home > Idéias, Mercado, Work > Projetos web e os tradicionais erros

Projetos web e os tradicionais erros

Depois de trabalhar com tantas agências e consequentemente com processos distintos, pude observar uma série de erros comuns em seus projetos. Sim, observei isso no Rio de Janeiro, mas tenho certeza de que se repete em outros lugares.

Com um pouco de cuidado e mais atenção, tenho certeza de que a qualidade dos projetos poderia melhorar muito, com este post não tenho nenhuma intenção de mudar algo, como sempre, o objetivo é mostrar o resultado de minhas observações.

A metodologia

A grande maioria das agências cariocas não possuem nenhum tipo de metodologia para o desenvolvimento de seus projetos, normalmente as necessidades, restrições, premissas, riscos e tudo mais é descoberto ao decorrer da execução. O fluxo de trabalho também é confuso e na maior parte dos casos não se respeita a dependência de tarefas, como resultado temos um enorme retrabalho, atraso e qualidade abaixo do esperado.

O planejamento

Muito pouco tempo é dedicado a esta etapa o que gera no fim das contas muitas idas e vindas, não é medido corretamente a quantidade de recursos (pessoal, tempo e dinheiro) necessário para a execução e como consequência o projeto acaba ficando manco.

Mas por que isso acontece?

Existem diversas formas de responder esta pergunta, uma delas é, uma agência precisa pagar suas contas e não pode cobrar muito, existem muitas agências por aqui – com pouquíssimo diferencial – e o que define, na maior parte dos casos, quem vai executar o projeto é o valor dado. Para resolver isso ela precisa de um certo volume de jobs em execução, assim, os prazos são curtos inclusive para o planejamento do que será feito.

Outra questão é a “ignorância”, não no sentido ruim, mas veja, uma pessoa que nunca programou na vida, pode desenhar uma forma extremamente complexa e achar que via código aquilo é feito tão rápido quanto no Photoshop ou algo do tipo (o mesmo se aplica para um programador que acha que uma tela pode ser produzida em segundos).

Ainda acredito que é melhor planejar por 1 ano e executar em 1 dia que planejar em 1 dia e passar 1 ano fazendo remendos.

A execução

Muitos jobs, pouco tempo e o pior, ninguém sabe o que está fazendo e como isso se liga ao trabalhos dos outros. Uma clara definição de “o que é responsabilidade de quem” resolve metade dos problemas e uma reunião antes do começo do projeto para que todos entendam o que está sendo feito, por que razão e qual o objetivo daquilo, resolve outra boa parte.

Se você está trabalhando com freelancers, pegar o mais barato nem sempre é uma boa idéia e oferecer menos ao que você confia é pior. Quanto menos um freelancer ganha, maior a desconfiança dele e pior o comprometimento.

Se você está produzindo isso em casa, talvez seja uma boa idéia eventualmente fazer um agrado para sua equipe, porque não? O comprometimento aumenta e você vai ver o resultado.

Uma questão muito importante é o respeito pelo conhecimento do outro, lembre-se se você é uma pessoa sem background de design, provavelmente não vai ter muitas condições de criticar (o que não quer dizer que você não possa contribuir) o layout de alguém. Confie e respeite seu colega/funcionário/freelancer.

Nem sempre o que foi desenhado pode ser implementado, a usabilidade por ficar ruim, ser tecnicamente inviável ou simplesmente na hora do layout nem tudo foi levado em conta. É preciso entender e achar uma saída intermediária que resolva o problema e fique bom, não adianta se manter 100% fiel ao layout e ninguém conseguir usar.

O controle

Controlar não é ser chato! Os melhores atendimentos que conheci – não sei porque ainda os chamo de atendimento, eles eram/são Gerentes de projeto – estavam sempre ali do lado, de bom humor, dispostos a achar uma saída em conjunto, confiando, dando uma dura quando necessário e nunca, nunca abandonavam a equipe. 5 da manhã, todo mundo cansado e eles ali do lado participando, tentando ajudar a resolver.

Claro, você precisa de feedback, saber como estão as coisas, onde estão e quando vão terminar. É importante saber onde está para poder avaliar o status e a qualidade do que foi desenvolvido até então.

Não basta estar dentro do escopo e prazo, a qualidade tem que ser boa.

A conclusão

Depois de todo projeto (ou etapa do projeto, depende do tamanho dele) acho essencial uma reunião para que se possa verificar o que foi bem feito, o que pode melhorar e resolver prováveis problemas entre as pessoas da equipe. Numa situação de estresse, um email que não foi lido direito pode se tornar uma crise entre dois ou mais membros da equipe, essa é a (provavelmente ultima) chance de resolver de maneira amigável.

Avaliar seus fornecedores, a equipe e claro, premiar – nem que seja com um tapinha nas costas – aqueles que se destacaram é uma ótima maneira de mantê-los dedicados.

Outros problemas

Alguns problemas comuns eu já havia comentado em outro post, mas vou listar frases que deveriam ser banidas das agências.

  • Vai fazendo que depois a gente vê como fica;
  • Faz o código que depois eu te mando o material (layout, fla, html, etc);
  • Faz o layout que na semana que vem a gente vê se são essas seções mesmo;
  • Isso é simples de fazer, você demora o que, 4 horinhas? (Se fosse simples você mesmo faria, não?)
  • A gente faz esse job com esse valor, depois a gente compensa.
  • Mas é só mudar o texto/cor/imagem/forma, é copy/paste!
  • Eu conheço o cliente, ele não aprovaria isso! (Talvez você devesse perguntar, ele pode estar só esperando você oferecer algo novo e não o de sempre)
  • Muda isso aqui, depois, se precisar, a gente volta.
  • Faz na linguagem x que depois a gente dá um jeito.
  • faz um prototipozinho, mas com tudo q vai ter no final
  • Faz um prototipozinho, só com tudo q vai ter no final.

Entre outras.

Categories: Idéias, Mercado, Work Tags: