Testar conceitos e identificar requisitos

Para verificar os conceitos gerados, é importante verificar se eles realmente geram os benefícios e impactos esperados. No entanto, desenvolver uma solução até o fim para verificar sua validade representa um alto risco e um grande investimento. Por isso, é importante verificar os conceitos desde o início do desenvolvimento.

Também deve-se iniciar a identificação dos requisitos que a solução deverá atender, pois tais requisitos poderão auxiliar em definições do modelo de negócio e na análise da viabilidade econômico-financeira.

O protótipo de baixa-fidelidade tem como objetivo representar funcionalidades, características ou qualquer outra hipótese que o time gostaria de verificar. Ele não precisa representar a solução completa, podendo ser elaborado com materiais simples, como papel e blocos, ou ser simplesmente uma representação por roleplaying.

ENTREGAS

Protótipos

Implementar uma solução funcional para verificação ainda não é viável no início do desenvolvimento. Portanto, neste momento, verificamos os conceitos testando-os com stakeholders por meio dos chamados protótipos de baixa fidelidade.

O primeiro passo para desenvolver um protótipo de baixa fidelidade é identificar quais hipóteses e premissas do conceito precisam ser verificadas. Por exemplo, pode ser que o time tenha identificado que os clientes desejam uma solução mais fácil de usar. Suponha que seu time tenha criado uma solução considerada mais fácil de usar por vocês. No entanto, isso precisa ser testado com os clientes para validar se realmente seu uso é mais fácil.

Após identificar as hipóteses e premissas, crie protótipos que permitam sua validação. Idealmente, crie um protótipo por hipótese ou premissa. Garanta que o protótipo seja focado em validar a hipótese ou premissa específica para garantir que os stakeholders que testarão o protótipo foquem na hipótese ou premissa testada.

Adicionalmente, crie de uma visão global da solução para que os stakeholders possam opinar sobre a solução como um todo. Novamente, essa visão global não precisa ser uma versão funcional da solução. Ela pode ser uma representação como uma história em quadrinhos, um vídeo ou animação, um esquemático, ou a representação que seu time julgar mais adequada.

Um protótipo de papel muito comum é a representação de aplicativos. Você pode criar as diversas telas do aplicativo e, à medida que o usuário indica onde ele clicaria, seu time pode colocar em sua frente a “tela” que apareceria.

Em geral, os protótipos podem assumir diversos formatos. Alguns deles são os seguintes:

  • Protótipos em papel;
  • Protótipos em formato de jogos;
  • Opções de protótipos para identificar preferências;
  • Protótipos criados pelos clientes;
  • Simulações “por trás das cortinas” feitas pelo seu time;
  • Simulações digitais;
  • Aplicativos simplificados;
  • Roleplaying;
  • Roleplay do serviço com o produto real (em casos de servitização de um produto existente);
  •  

Um protótipo de papel muito comum é a representação de aplicativos. Você pode criar as diversas telas do aplicativo e, à medida que o usuário indica onde ele clicaria, seu time pode colocar em sua frente a “tela” que apareceria.

Após a criação dos protótipos, teste-os com seu time antes de buscar feedback dos stakeholders. Podem surgir insights e melhorias antes mesmo dos testes iniciais.

Feedback dos Stakeholders

Os protótipos devem ser testados com os stakeholders para obter o feedback.

Preferencialmente, o stakeholder deve interagir com o protótipo sem a influência do seu time e sem qualquer tipo de guia que o ensine a interagir. Apenas forneça um contexto mínimo para que o stakeholder entenda por si só o que fazer. Deixe que ele cometa erros e tome notas, pois os erros podem gerar insights e melhorias para o conceito.

Durante a interação com o protótipo, faça perguntas sobre como ele se sente, questione as razões pelas quais ele toma determinadas decisões, estimule que o stakeholder fale e descreva o que ele está fazendo e por quê ele o está fazendo. Caso o usuário do protótipo faça perguntas, responda com uma pergunta. Por exemplo, se ele perguntar o que um determinado botão faz, você pode perguntar de volta o que ele acha que aquele botão faz.

Tome notas de tudo que puder contribuir para a evolução do conceito. Anote pontos positivos e negativos do protótipo. Ideias fornecidas pelo stakeholder também devem ser anotadas, assim com as dúvidas que ele teve. Tente refinar possíveis requisitos que ele tenha explicitado, como “Eu adoraria comprar essa solução desde que não fosse muito cara” ou então “Só pagaria por esse serviço se fosse muito rápido” – questione o que é caro ou rápido para o stakeholder e transforme esses requisitos em parâmetros mensuráveis.

A cada teste do protótipo, retorne com a sua equipe, melhore e refine o seu conceito, e crie novos protótipos para as premissas e hipóteses restantes. Se o seu time permanecer em dúvida em relação a algum aspecto da solução pois os stakeholders ofereceram feedbacks positivos para mais de uma possibilidade, leve todas as possiblidades promissoras em frente. Pode ser que algum aspecto do modelo de negócio ou da viabilidade econômica ajude o seu time a tomar uma decisão.

As User Stories são declarações sucintas de unidades de funcionalidades, descrevendo o que o sistema deve ser capaz de realizar para seus usuários. Uma User Story costuma ser estruturada por frases no seguinte estilo:

“Como um <categoria de stakeholder>, eu posso <atividade> de forma que <valor>”

Lista de requisitos iniciais

Os requisitos são a base para garantir que todo o time de desenvolvimento esteja alinhado, desenvolvendo soluções que

atendam às necessidades e desejos dos clientes, resolvam os problemas dos stakeholders e estejam condizentes com as restrições de modelo de negócio e da capacidade de investimento do provedor.

Dependendo da abordagem que estruturará o restante do desenvolvimento da solução, você pode escrever os requisitos em formatos diferentes.

Se o detalhamento da solução for seguir abordagens típicas da engenharia de sistemas, os requisitos podem ser descritos no formato tradicional, trabalhando-se com base em gestão de requisitos.

Caso o restante do desenvolvimento siga abordagens ágeis, os requisitos podem ser especificados como User Stories.

A primeira identificação dos requisitos iniciais deriva de análise das necessidades, problemas e oportunidades. Por exemplo, se um time desenvolver uma solução servitizada para substituir a venda de um produto, sabemos que o custo-benefício da nova solução para o cliente deve ser suficiente para desestimular a compra da solução antiga.

Você pode refinar os requisitos parcialmente durante os testes da solução. Inclusive, alguns requisitos podem ser considerados como hipóteses ou premissas para basear protótipos. Por exemplo, você pode desejar saber qual a faixa de preço que um cliente pagaria pela solução. Assim, o time pode derivar o custo da solução do valor atingido.

MÉTODOS

Existem diversos métodos para criar protótipos de baixa fidelidade. Você pode prototipar algo com diferentes finalidades, como testar hipóteses e premissas, tomar decisões ou gerar empatia.

Quando prototipamos uma característica física da solução, podemos usar métodos como:

  • Protótipos rápidos[i] para simular características físicas ou funções da solução de forma rápida;
  • Protótipo feito pelos stakeholders[ii] para refinar conceitos e gerar mais ideias;
  • Protótipo “por trás das cortinas” [iii] para simular funcionalidades automáticas;
  • Protótipo roleplay[iv] para simular interações, processos ou serviços;
  • Storyboards[v] para representar fluxos de atividades, acontecimentos relacionados à solução ou a jornada esperada pela solução.

Para testar os protótipos, é interessante seguir algumas boas práticas descritas no método “Testing with users” proposto pelo Bootcamp Bootleg (ver nota de fim 29).

O feedback dos stakeholders pode ser documentado no template MAP03.06 proposto neste guia. O método “Feedback grid” proposto pelo Bootcamp Bootleg (ver nota de fim 29) pode ser utilizado como guia para preencher o template.

MATERIAL DE APOIO

MAP03.06. Template para feedback dos stakeholders: O template é adaptado do método “Feedback grid” proposto pelo Bootcamp Bootleg (ver nota de fim 29), o qual pode ser utilizado como guia para preencher o template. Note que o template proposto neste guia possui um espaço à direita para descrever requisitos. Liste nesse espaço todos os requisitos que surgirem nos testes dos protótipos.

Recomendamos que os requisitos sejam quantificáveis sempre que possível e que eles sigam o formato mais adequado com a abordagem de desenvolvimento que seu time irá utilizar posteriormente.

DICAS

  • Sempre foque cada protótipo em uma hipótese ou premissa;
  • Crie protótipos que dependam o mínimo possível de explicações;
  • Crie protótipos que permitam que o usuário interaja sem intervenções;
  • Deixe que o usuário do protótipo interaja livremente com o protótipo;
  • Responda perguntas com perguntas;
  • Não se apegue demais ao conceito. Pode ser que os stakeholders rejeitem um conceito. Pense nisso como uma redução de riscos. Jogue fora este conceito e prossiga para o próximo.
  • Erre cedo, com frequência e não tenha medo de errar.

[i] Protótipos rápidos são protótipos feitos com recursos que se tem à mão. Pode ser algo feito de papel, massinha, blocos de montar, ou qualquer outro recurso que ajude a criar uma representação da solução. Saiba mais sobre esta técnica no método “Rapid Prototyping” proposto pelo guia “human-centered design” (veja nota de fim 25).

[ii] Quando seus stakeholders realizam o processo de prototipagem, eles indicam como gostariam que a solução fosse a partir de um conceito inicial. Esse tipo de protótipo é muito útil para refinar soluções e gerar mais ideias. Recomendamos buscar mais informações e boas-práticas no método “User-driven prototype” proposto pelo Bootcamp Bootleg (veja nota de fim 29).

[iii] Quando uma solução possui funcionalidades automáticas que se deseja testar, pode-se realizar a prototipagem “por trás das cortinas” para testar a funcionalidade sem implementá-la. Por exemplo, no caso de um software, podemos criar “telas” em papel. Quando o usuário interagir com as “telas”, o usuário indica onde estaria apertando e alguém troca a tela de papel, como teria acontecido em um software. Mais diretrizes de como realizar a prototipagem “por trás das cortinas” podem ser vistas no método “Wizard of Oz prototype” proposto pelo Bootcamp Bootleg (veja nota de fim 29).

[iv] Roleplaying quer dizer atuar. Em protótipos do tipo roleplay, o time representa papéis e atua para simular parte de uma interação, de um serviço ou de um processo. Mais informações sobre esse tipo de protótipo podem ser vistas no método “Role Playing” proposto pelo guia “human-centered design” (veja nota de fim 25).

[v] Storyboards são histórias em quadrinhos que podem representar pedaços de solução, processos, serviços, acontecimentos, interações, jornadas ou qualquer coisa que seu time julgue útil representar neste formado. Para ver mais sobre storyboards, veja o método “Storyboard” proposto pelo guia “human-centered design” (veja nota de fim 25).