Ao invés de redesign, uma abordagem estilo Agile

Temos conversado muito aqui na Latitude14 sobre a aplicação dos conceitos de desenvolvimento ágil (ou Agile) no processo de design com foco na experiência do usuário. Tentamos herdar idéias como:

  • começar desenvolvendo somente a essência, a menor unidade de um sistema (sem perder a visão do todo, claro);
  • colocar o produto nas mãos do usuário para se ter feedback o mais cedo possível (iterar cedo para iterar mais); e
  • reduzir a burocracia e a documentação (documentos e relatórios mais “digeríveis”).

Falei um pouco disso num post anterior. A Karine também escreveu um post bem esclarecedor sobre o assunto no blog dela. Vemos que maioria dos projetos pode se beneficiar dessa abordagem, até mesmo produtos que já estão prontos.

Onde quero chegar com isso: existe uma cultura fortíssima de redesign no mercado. Pelo menos é o que constatamos, de forma muito evidente, aqui em Belo Horizonte, principalmente quando se fala em websites.

Não sei dizer se é uma estratégia das produtoras e agências para obter mais lucro, se ainda não pensaram em trabalhar de outra forma, ou se os clientes demandam redesigns sempre e elas não têm argumentos para justificar uma abordagem incremental. Talvez as três coisas.

Quando se faz um redesign completo, não há tempo de aprender o suficiente e acaba-se focando somente nos problemas principais do produto anterior. Fatalmente, numa nova versão, também surgem novos problemas, que serão cobertos muito depois, num novo redesign, já que a verba se foi toda no primeiro.

Como gostam de dizer os gringos, “joga-se fora o bebê junto com a água da banheira”. E aí ficamos nesse ciclo vicioso, no qual nunca se chega a um produto totalmente maduro. Melhoram-se alguns aspectos enquanto surgem novos, os projetos duram vários meses e, quando vão ao ar, já têm problemas congênitos.

Quando foi a última vez que você viu um redesign completo da Amazon ou da Netflix, por exemplo? O mesmo vale para o Google e o Yahoo!, que fazem melhoras constantes e seus produtos, ao invés de jogar tudo no chão e reconstruir do zero. São empresas que têm essa mentalidade, não porquê são grandes, mas porque precisam construir produtos sólidos, com o mínimo de risco possível.

Se é feito inicialmente um estudo mais criteiroso dos problemas que existem na versão atual de um produto, de forma a ordená-los em ordem de criticidade, é possível quebrar o grande redesign em pequenos projetos.

Refazer ou melhorar somente uma pequena parte ou aspecto de uma aplicação ou website faz com que aquele seja um produto melhor num prazo muito mais curto. Além disso, aprende-se sobre o contexto, os usuários e outros stakeholders no processo. E esse aprendizado é reaproveitado nos “mini-projetos” seguintes.

Publicado em 24/09/2008

Comentários

Inclusive, vale ressaltar que redesign não é apenas alterar o visual, muito conhecido aqui no Brasil como “design do site”. A Amazon, por exemplo, já reformulou o visual, sem mexer na estrutura. O Yahoo!, ídem. O que considero redesign problemático, é quando se joga tudo no chão e começa do zero, ou, quando se começa a reformular algo, sem conhecimento do processo anterior. Nos dois casos, todo o conhecimento gerado é desperdiçado, possibilitando que se repita os mesmos erros de versões anteriores, pelo simples desconhecimento de tais erros.

Acho que o exemplo da Globo.com aqui no Brasil vale bastante. Desde a reformulação até esse redesign feito no começo desse ano eles conseguiram acertar. Talvez seja o melhor exemplo dentre os portais brazucas.

E qto ao processo Agile a projetos menores e rápidos como advergames, hotsites?

Concordo com a sua opinião, mas acho que uma melhora contínua depende de um projeto original bom, que tenha sido planejado para o crescimento, pois se a estrutura é falha, como fazer para não jogar tudo no chão e começar do zero?

Falando em Agile, vi um gráfico interessante esses dias: http://www.svpg.com/resources/Agile/Process.html

Eduardo, acho que a estrutura é justamente um dos aspectos que se pode melhorar individualmente (ou até parcialmente). Claro que cada caso é diferente, mas acredito que em quase todos é possível definir uma visão inicial de onde se deve chegar e dividir o trajeto em blocos menores. Dessa forma, você aprende no processo, torna o site melhor em menos tempo e, com as lições aprendidas, pode ir ajustando a visão durante o caminho.

Quanto à pergunta do Vinícius, acredito que mesmo um projeto pequeno pode se apropriar de alguns princípios ágeis sem problema, usando técnicas como prototipação em papel, avaliações informais e iterações curtas.

Na empresa onde trabalho, usamos em alguns projetos metodologia Agile, onde está sendo muito bem visto.
Temos também algumas pessoas já certificadas em Scrum Master.
Posso dizer, esse é o futuro!

Obrigatório, mas não será exibido no comentário
Opcional
Somente marcação Textile