Prototipação em Times Ágeis

  •  
  •  
  •  
  •  

No post da semana, vou relatar minha percepção com relação a prototipação de forma colaborativa.

Mas o que é prototipação? Para que isso serve? Bom, meu primeiro contato com essa ideia foi quando estava na faculdade estudando arquitetura da informação. Nessa matéria, é muito importante criarmos wireframes para analisarmos a relevância do conteúdo, da navegação (entre outros), em um projeto (seja um site, um sistema, etc).

Gosto de pensar que prototipação de um software, dentro do contexto ágil, é um esqueleto iterativo do que vai ser o resultado final.  Sim, é possível prototipar até serviços!! Para Alexandre Osterwald e Yves Pigneur, autores do livro Business Model Generation, através dela é possível trabalharmos com o pensamento visual, ou seja:

Ela [pensamento visual] torna tangíveis conceitos abstratos e facilita a exploração de novas ideias.

A partir de um protótipo, é possível experimentarmos e analisarmos diversos aspectos, como a interação com o usuário, a comunicação entre as telas e seus elementos, por exemplo. Quando tratamos sobre esse tema, temos que ter em mente que existem 2 tipos que são mais conhecidos, são eles: De baixa fidelidade e média/alta fidelidade.

Baixa fidelidade: como o nome já diz, são protótipos menos robustos e com um certo nível de informação. Tem como resultado algo não tão próximo da versão final.

Média/Alta fidelidade: são bem mais robustos, ou seja, já se aproximam mais do que será a versão final, com todas as suas interações e comportamentos em funcionamento. Atualmente existem vários softwares para trabalharmos. Particularmente, prefiro o axure.

E o que isso tem a haver com o mundo ágil?

Como já disse anteriormente aqui no blog, a colaboração é um dos pilares da cultura ágil. Esse aspecto traz grandes benefícios para um time, como o entrosamento entre seus integrantes.

Quando isso acontece, percebo que até a criatividade nas soluções propostas pelo time fluem muito mais fácil. Se tratando de criatividade colaborativa, Robert Hargrove, autor do livro Colaboração Criativa, é claro ao fazer a seguinte afirmação:

O processo, geralmente difícil, de procurar compreender, pela discussão, com que os diferentes campos de especialidade podem contribuir para um projeto, em última análise é compensador, pois aumente a qualidade, a velocidade e os resultados.

Ou seja, os diferentes contextos de cada membro do time (tanto sua experiência quanto a sua especialidade) são essenciais para atingir resultados incríveis. Tendo isso em mente, comecei a praticar essa criatividade colaborativa no momento da prototipação e, carinhosamente, chamei de prototipação colaborativa. Nossa… quanta criatividade!

E como isso funciona?

Durante o backlog grooming ou sprint planning, aproveito para reunir com o time para pensarmos, coletivamente, como a funcionalidade deve ser. Ficamos todos em frente ao quadro branco criando wireframes e pensando nos casos de uso que o projeto comporta (ex. E se o usuário fizer isso? E se ele fizer aquilo, como a funcionalidade vai se comportar? Quando o usuário cadastrar algo aqui, com qual módulo ele deve se comunicar?)

Sempre que possível, envolva o cliente e também o usuário para quem você está projetando. Isso vai criar um senso de responsabilidade em todos, aumentando assim o engajamento. Outra sugestão: Conheça sempre o seu usuário. Em breve irei explanar mais sobre personas.

Após esse processo, tenho como resultado um esboço de protótipo de baixa fidelidade desenhado no quadro branco. Então, a partir dele, crio um protótipo de média/alta fidelidade e procuro validar com o usuário, aplicando um “teste de usabilidade” (de baixíssimo custo) criando cenários e pedindo para o usuário realizar alguma ação referente a funcionalidade em si.

Caso seja necessário alguma mudança, alinho com o restante do time o que foi alterado. Geralmente, o impacto das alterações são pequenos, pois o período de validação ocorre quando o pessoal ainda ta escrevendo os testes (ou em alguma fase que não começou exatamente a parte de codificação). Simples assim! 🙂

Tenho realizado esse procedimento desde o final de 2014 em projetos de escopo aberto e fechado. E, o que pude perceber, é que essa atividade diminuiu a necessidade de uma documentação extensa, pois como todo o time participa do processo de criação, todos acabam entendendo a necessidade de alguns elementos estarem naquela tela, seja por questões de design, de desenvolvimento ou de negócio. Caso entre uma pessoa nova no time, todos serão capazes de explicar melhor as funcionalidades do projeto, fortalecendo assim o perfil multidisciplinar que um time deve ter.

Outro fator interessante que percebi, é que cada membro passa a conhecer melhor a especialidade existente em seu time, dando a oportunidade de sair da zona de conforto e ajudar também em outras áreas, fortalecendo ainda mais a real ideia de ter um time focado principalmente na experiência do usuário.

Por fim, reforço a importância de trabalhar-se com protótipos, principalmente de baixa fidelidade (feitos na mão e no papel), pois são ótimas formas para validar diversas informações sobre seu projeto, investindo pouco tempo e recurso, trazendo um grande valor para o resultado de seu projeto.

E como o seu time faz? 🙂

Grande abraço.

Leave a Comment