Aplicando design thinking para gerar soluções assertivas

Publicado por Daniel Mai no dia agile, design

Temos uma fase de estudo de solução para novas funcionalidades em nosso kanban de projetos. Recentemente, adaptamos esta fase de estudo a um projeto de web app interno para gestão de contas. Desenvolvido por um time de seis pessoas. Devido à mudanças de expectativa e ao pouco conhecimento inicial do time e dos stakeholders sobre os problemas do negócio, o projeto teve um alinhamento mínimo em seu início.

Dada a escassez de tempo e recursos, optamos por priorizar uma entrega rápida e de baixo custo, de acordo com nossa cultura de desenvolvimento ágil. A metodologia do estudo precisaria ser mais enxuta e flexível mas ainda assim orientada ao design thinking.

Dentro deste cenário, os estudos de solução seguem as seguintes etapas:

  1. investigar um problema junto aos usuários e validá-lo junto ao Product Owner e ao time de desenvolvimento;

  2. propor uma solução e validá-la junto ao P.O. e ao time de desenvolvimento;

  3. escrever as histórias de desenvolvimento que serão estimadas pelo time, avaliadas pelo P.O. e vão alimentar o backlog do projeto.

Estes estudos geralmente são alocados em uma sprint de uma semana. Se em quaisquer destas etapas não houver aceitação na validação, o estudo volta para o início da etapa ou, dependendo da situação, ainda para a etapa anterior.

Fases do estudo de solução

Análise e validação do problema

Esta etapa trata de conhecer o problema. Toda solução deve resolver um problema conhecido. Esse conhecimento pode vir através de solicitações em tickets de suporte - onde são identificadas e analisadas as dificuldades dos usuários - ou de entrevistas internas onde nesse caso os usuários são os próprios funcionários da empresa.

Através das entrevistas, buscamos descobrir informações específicas e detalhadas sobre problemas previamente identificados e que precisam ser resolvidos através da feature em desenvolvimento.

O objetivo das entrevistas é coletar informações e aprofundar o problema, compreendendo suas origens, relações e consequências. Nesse momento, também identificam-se as regras que são inerentes ao processo mas estão subentendidas apenas na cabeça dos usuários e dos stakeholders.

Analisando o problema

Para levantar as dúvidas que serão trabalhadas nas entrevistas, busca-se antes estabelecer cenários com casos, condições, personas e tarefas. A definição desses cenários pode ser feita através das seguintes questões básicas:

O que? (tarefa/feature)

É a tarefa, processo ou feature ao qual o problema está atrelado. Pode ser uma tarefa ou processo que vão originar features no software ou features já existentes que precisam ser modificadas.

Quem? (personas que realizam/utilizam)

São as personas (tipos de usuários) que realizam, utilizam, solicitam, participam, são impactadas, enfim, têm alguma forma de relação relevante com a tarefa, processo ou feature em questão.

Por quê? (problema)

Este é o problema de fato. O motivo que define o valor gerado pela tarefa ou feature.

Quando? (momento de uso/ocorrência)

São os momentos de uso ou ocorrência que definem os casos e condições do cenário.

Quanto? (frequência de uso/ocorrência)

O levantamento da frequência de uso ou ocorrência do problema possibilita quantificar o valor gerado e determinar sua importância e prioridade de solução e desenvolvimento.

Onde? (posição de espaço/tela)

Levantamento de pontos espaciais nas telas do software que tenham relação com a feature ou tarefa em questão, auxiliando na visualização concreta do cenário e do problema.

Como é? (método/cenário atual)

Define em detalhes o processo e métodos utilizados na execução da tarefa ou na utilização da feature dentro do cenário atual, além das dores e dificuldades encontradas.

Como deveria ser? (método/cenário ideal)

Busca levantar em detalhes um possível caminho de solução já identificado, definindo um método ou cenário ideal na perspectiva do usuário. Contribui para o levantamento dos fatores e condições de sucesso que irão balizar a validação da solução. Estas questões se desdobram em outras mais pontuais e detalhadas - e é exatamente este o objetivo.

Depois de entrevistar alguns usuários e conversar com o P.O., estas questões e as respostas obtidas são trazidas ao time de desenvolvimento - a fim de validar o problema e limitar seu escopo. Neste momento, podem surgir novas dúvidas por parte do time. Estas são registradas para uma nova coleta de informações. Muitas vezes alguns caminhos de solução já são apontados e serão seguidos na próxima etapa.

Desenho da solução

Inicialmente, são levantadas hipóteses de solução lógica para o problema em escopo. É facultativa a opção de fazer um benchmarking de outras ferramentas para avaliar como o mesmo problema é tratado. Muitas vezes, o problema não ocorre da mesma forma em outras circunstâncias. Em outras, o problema pode não envolver software, mas sim processos e métodos, dificultando ainda mais esta atividade.

Desenhando a solução

Após refinamento das hipóteses, partimos para um esboço da solução, constituído por um conjunto de conceitos, definições e regras que sustentam um cenário próximo do ideal.

Este cenário será simplificado e dividido a fim de encontrar uma ou mais versões mínimas viáveis (MVPs) que entreguem um valor mínimo de forma incremental. Quando necessário, são desenhados wireframes que auxiliam na visualização da solução. Também podem ser construídos protótipos, possibilitando testes de usabilidade e validação de interfaces gráficas complexas, além de auxiliar muito no refinamento do design e no desenvolvimento front-end.

Por fim, o desenho da solução é validado pelo time de desenvolvimento e pelo P.O.. Após considerações e ajustes, a solução é aprovada por todos e pode então gerar backlog.

Geração de backlog de desenvolvimento

Aqui, o desenho da solução aprovado é quebrado em histórias de desenvolvimento que vão alimentar o backlog do projeto. Para garantir detalhes e coerências técnicas, as histórias são escritas junto a um desenvolvedor do time. Nesse momento, ainda tentamos quebrar as histórias em outras menores, buscando sempre MVPs que entreguem valor de forma incremental ao usuário e que cadenciem o desenvolvimento.

Quebrando histórias de backlog

Também buscamos encontrar e descrever caminhos de execução rápida e com o menor custo possível. Ao final desse momento, as histórias recebem pré-estimativas simplificadas para seu custo de produção e valor entregue ao usuário. Algumas histórias não envolvem necessariamente desenvolvimento de software. Alguns exemplos são planos de ação ou comunicação.

Na sequência, as histórias finalizadas são estimadas pelos desenvolvedores. As estimativas são avaliadas pelo P.O., que pode aprovar ou negociar com o time novas estimativas. Nesse ponto, o estudo é considerado como entregue.

Conclusão

A introdução dos estudos de solução em nosso processo de desenvolvimento tem se mostrado muito positiva e vem contribuindo para a manutenção de nossa cultura ágil. Temos percebido uma quantidade menor de surpresas desagradáveis durante a execução do projeto, como escopo descoberto muito tardiamente e outras incertezas relacionadas ao cenário e seus desdobramentos como um todo. Estes impedimentos acabavam atrasando as entregas e contribuindo para introdução de bugs. Ficamos contentes com os primeiros resultados pois conseguimos antecipar muitos problemas, ter mais tempo para pensar na solução com antecedência e, consequentemente, entregar com mais qualidade.

Daniel Mai

Daniel Mai

Designer

Comentários