Compartilhando os resultados de testes com o time

http://uswireframes.com

Sempre trabalhei em agência. Lá, os testes “eram diferentes” de uma startup. Quando algo era testado, precisávamos gerar um relatório grande para entregar para o cliente. Isto acontecia porque precisávamos mostrar valor para o trabalho que foi realizado, e, principalmente porque nem sempre era a própria agência que executava as melhorias que estavam sendo propostas. Assim, tudo era bem detalhado e o relatório ficava enorme.

Quando entrei no ContaAzul, de imediato nos primeiros testes senti uma necessidade de compartilhar o resultado com todo o time. É imensamente importante que — principalmente — os desenvolvedores tenham conhecimento das iniciativas e sugestões de melhorias a partir de testes de usabilidade.

Entretanto, gerar um relatório “colossal” não faria eles lerem e muito menos trazer insights para correção dos problemas encontrados. O meu time dentro do ContaAzul possui um conhecimento excepcional sobre notas fiscais (área em que trabalho) e com certeza seria besteira não ter a opinião deles.

Como fazemos

Quando realizamos testes, levantamos problemas e hipóteses para corrigir. Todas as hipóteses precisam ser repassados para o time mensurar antes de "codar".

Desta forma, criamos uma planilha para compartilhar os aprendizados, criar pequenas tarefas e quantificar o esforço para desenvolver. A planilha é dividida em dez passos, sendo cinco preenchidos pelo designer e cinco pelo time como um todo.

  1. Problema Encontrado: descrevemos o problema visto no teste;
  2. Área: em qual parte do sistema está o problema;
  3. Ocorrência: quantas vezes este problema apareceu nos testes (por número de usuários);
  4. O que fazer: qual a hipótese para corrigir o problema;
  5. Heurísticas: qual heurística foi quebrada;

Estes campos são preenchidos pelo designer. Entretanto, compartilhando os resultados, o time inteiro pode fazer sugestão para melhorar os problemas.

O que o time preenche:

  1. Impacto (PM coloca o impacto que a iniciativa trará para o negócio)
  2. Esforço (desenvolvedores mensuram e anotam o esforço para resolver o problema)
  3. Confiança. O quanto o time está confiante que a sugestão de fato corrigirá o problema.
  4. Status. É important saber o que será feito e o que ficará em stand by
  5. RICE. RICE é a sigla em inglês para Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço). Os três primeiros itens da matriz são pontuados e, ao final, divididos pelo último. Esta matriz de priorização é gerada automaticamente com base no que foi preenchido. Leia sobre o RICE no blog do ContaAzul.

Nossos ganhos

  • Todo o resultado fica compilado em um único arquivo, compartilhado com todo o time e dentro da pasta padrão do projeto (fácil consulta caso precise no futuro).
  • Os desenvolvedores são “obrigados” a ler, pois, só assim para mensurar o que poderá ser feito.
  • Todo o time fica sabendo das iniciativas e testes que estão sendo feitos. Isto facilita na tomada de decisão e ajuda a priorizar os próximos passos.
  • O designer consegue ter uma visão clara de quais as heuristicas que estão sendo quebradas e onde o trabalho ainda precisa de atenção.

Próximos passos

Esta planilha está em evolução. Estou compartilhando como estamos fazendo hoje para criar uma discussão sobre este assunto e trazer insights para melhorar ela :)

Quem quiser trocar uma ideia sobre os processos de compartilhamento com o time é só me escrever: victor.zanini@contaazul.com

Achou legal e quer usar esta planilha? Vem trabalhar com a gente :)