Quando é a hora da manutenção evolutiva?
16 de dezembro de 2008, 21:45Portais de empresas sempre precisam de alterações. Como saber a hora de deixar de lado os pequenos ajustes e lançar uma nova versão? Uma pergunta difícil de responder.
Por
Quem está envolvido no dia-a-dia com o desenvolvimento ou administração de portais, sabe. Os projetos já nascem velhos. Isso porque, ao longo das diversas fases, da concepção ao lançamento, vão surgindo novas idéias, novas sugestões e também novos problemas e ajustes emergenciais. E, uma hora, é preciso fazer um corte e decidir: a partir daqui entra na versão 1.0 e o resto fica para as próximas etapas.
E então, com o tempo, vão surgindo mil ajustes, centenas de alterações emergenciais inadiáveis que impedem a famosa manutenção evolutiva do site. Como saber, então, a hora de deixar de lado os pequenos ajustes e lançar uma nova versão? Essa é uma pergunta difícil de responder.
Definitivamente, não é logo após o seu lançamento. O site precisa antes ser avaliado e utilizado pelo usuário. E o gestor necessita ter ao menos alguns meses de relatórios de visitação para entender os principais gargalos, caminhos utilizados, páginas de saída, palavras-chave utilizadas nos buscadores e seções mais e menos visitadas. Mas, também não pode ser tarde demais, a ponto das pessoas já terem desistido de utilizar o canal.
Com aproximadamente um ano de estatísticas avaliadas, é possível ter métricas confiáveis para estudar o comportamento do visitante. Nesse momento, é interessante fazer a leitura analítica da visitação e planejar um teste de usabilidade, especialmente em pontos críticos apontados pelo relatório, com amostras do público-alvo da página. Este tipo de trabalho, muito eficiente para captar dificuldades de entendimento da própria arquitetura da informação, pode ser muito útil para orientar os próximos passos.
Outro ponto interessante é fazer (ou refazer, se tiver sido feito no planejamento do site) o card sorting - técnica onde o arquiteto da informação escreve em papéis os vários rótulos utilizados nos menus e submenus do site e pede que o usuário ordene hierarquicamente. Acompanhando essa dinâmica, é possível perceber onde estão as dificuldades de entendimento por parte do internauta.
Uma prática utilíssima é pedir que diferentes designers e profissionais de web façam uma avaliação heurística do site, detectando, a partir de sua experiência, dificuldades óbvias na navegação e usabilidade como um todo. Nesse trabalho, é bem possível que surjam novas oportunidades de conteúdo.
É o momento de avaliar também a interatividade do canal. Se, conjuntamente, for realizado um estudo analítico da concorrência, com possibilidade de benchmarking de suas qualidades e aprendizado com o erro dos outros, podem surgir idéias e soluções criativas e eficazes para reformular e criar novas ações que nunca haviam sido planejadas.
Com base nesse material, é possível planejar uma versão 2.0 do site, resolvendo os problemas mais críticos para o usuário e modernizando o canal como um todo. O importante é nunca tirar da cabeça que um projeto de site perene nunca fica pronto. Ele é lançado e entra em um ciclo permanente de avaliação e evolução, até o dia em que sai do ar. [Webinsider]
.
1° Emerson Tadeu Data: 17/12/2008 às 7:29 am
Atividade:
Cidade:
Artigo fraco, conseguiu ter exatamente a postura que todo usuário odeia.
Genérica demais, coloca um monte de parâmetros, sendo muitos deles inatingíveis para a maioria dos casos.
Para o desenvolvedor existe apenas 1 argumento que justifica uma nova versão.
Quando o chefe manda ou o cliente resolve que vai pagar por ela.
Na informática existem 3 níveis para a urgência de implementação de soluções:
1: Erro crítico que causa prejuízo de tempo e/ou de $$$.
2: Erro intermediário que também podem causar prejuízos, mas todos o conhecem e sabem como proceder para que não ocorra.
3: Erro de desing ou melhorias para utilização do software.
Os problemas do nível 1 não podem jamais esperar nova versão.
Os problemas do nivel 2/3 podem esperar o quanto for necessário pela vontade do chefe.
Portanto …
Caso vc seja desenvolvedor apenas ouça seu chefe, mas se vc é chefe ouça seus clientes e divida as solicitações nestes 3 grupos que apresentei.
Quando vc tiver recursos humanos e financeiros para avançar então o faça baseado no que vc percebeu que seus clientes esperam de vc !
Neste ponto o artigo é útil, pois ele subentende que vc tenha mecanismos para juntar as informações relevantes para sua tomada de decisão.
É simples para caramba.