Projeto novo !! E agora PO, como ter uma visão do todo?

Essa é uma pergunta que talvez se passe na mente do Product Owner(PO) quando sai de um UX e precisa transformar todos aqueles protótipos em realidade, em um backlog que permita construir este lindo produto!!

Também é uma pergunta que na sequência o Product Manager (PM) vai fazer: E aí PO, qual o tamanho do projeto, quando teremos um MVP pra levar no evento. Ou quando teremos um MVP para pilotar no cliente?

E também no Dev Team, tá PO, o protótipo está aqui prontinho, mas por onde começamos?

Enfim, gostaria de compartilhar a experiência que tive com o Event Storming e o quanto ele ajudou a resolver esta e várias outras perguntas e questões.

Aplicamos a técnica no início do desenvolvimento do App do MLA, um aplicativo móvel que seria construído do zero no time para um módulo bem conhecido no produto Datasul, no módulo de aprovações.

Reunimos Dev Team, PO e TechLead e começamos o desenho do nosso Event Storming, discutindo cada evento de usuário e quais os comandos necessários para se chegar a cada um desses eventos.

Focamos em definir juntos:

Olhando para cada tela prototipada pensávamos juntos, no modelo brainstorming mesmo, todos contribuindo, com chuva de ideias. Quais comandos temos nesta tela? Dica, pensando sempre o comando como uma ação então verbo no infinitivo.

• Efetuar login no app
• Buscar permissões/configurações do aprovador
• Buscar dialeto do usuário
• Traduzir informações da tela conforme dialeto

Estes são só alguns exemplos de comandos encontrados. Vejam no caso de uma tela aparentemente simples. Quando começamos a conversar com todos os níveis de conhecimento (técnico, negócio, testers), reparem quantos insights um protótipo não consegue nos trazer?

Legal, comandos mapeados e agora? Para cada ação, desdobramos então em qual evento resultaria. Por exemplo, a ação de efetuar login no app, resultaria no usuário logado. Atenção, o evento agora é passado, então verbo no passado, “Usuário logado”, “Preferências do usuário carregadas”.

Na medida em que os comandos e eventos iam avançando, íamos também encaixando as telas que eram envolvidas naquela ação. Ficando claro assim pra todos qual o link destas ações com os protótipos.

E ao final, tínhamos o mapeamento a seguir.

Surgiram no meio do caminho também as indefinições. Sim, nem tudo são flores. Situações que não estavam claras naquele momento sobre o que iríamos precisar, necessitavam de um estudo adicional ou uma POC para clarear, primeiramente. Seriam as indefinições(post-it vermelhos):

Exemplo de indefinição:

Este exemplo envolvia uma indefinição técnica que talvez até inviabilizaria este comando de trocar empresa. Mas neste momento a ideia seria deixar esta situação mapeada para estudo futuro.

Apesar destas indefinições ao final da aplicação, que durou cerca de uma manhã, tínhamos um esquema que dava uma visão inicial, a todos os envolvidos, de tudo que permearia o desenvolvimento da primeira jornada que seria do Aplicativo em si.

Dali daquela aplicação chegamos à conclusão, também, que seria necessária uma nova jornada, que seria da configuração visual dos campos, ou seja uma interface que não tínhamos prototipado mas que seria essencial para maior adaptabilidade do Aplicativo nos clientes.

Mas, o foco neste dia foi a jornada do Aplicativo de aprovação. E o que o Event Storming entregou ao final?

A visão apresentada acima nos deu visibilidade:

Enquanto time de desenvolvimento: de tudo que seria necessário para cada uma das telas do protótipo parar de pé, o que envolvia ação em cada uma delas.

Enquanto PO: De todos os Épicos que seriam necessários abrir para as entregas, os quais se desdobraram em múltiplas histórias. Exemplo: DMANSUPCEX-16055 virou um Épico, e cada um dos quadradinhos viraram Épicos… Tínhamos um backlog inicial para trabalho

E para as perguntas do PM? “E aí PO, qual o tamanho do projeto? Quando teremos um MVP para levar no evento?”

Como o PO ja tem o mapeamento inicial de todos os Épicos que compõem o desenvolvimento, ele tem uma noção macro do tamanho do mesmo. E com a evolução do primeiro, segundo, terceiro Épico, ele já sabe qual a velocidade de entrega daquele Coreteam do projeto. E com isso consegue projetar o tempo de entrega de um Épico e assim também a projeção de entrega final.

Caso real, a projeção final de entrega do projeto não cabia no marco de entrega de produto, precisávamos apresentar o Aplicativo no Evento Comercial que ocorreria no início do ano. Então o Evento Storming entrou de novo na decisão. Juntos novamente PO e time de desenvolvimento paramos para olhar o esquema gerado e pensar em um MLP (Mínimo Produto Amável) que pararia de pé e entregaria valor ao cliente. Um apresentável para o evento e na sequência caminharíamos com os demais MLPs.

E chegamos em um entregável inicial: Épicos 1 a 5 e Épicos 7 e 8. Deixamos para um segundo entregável o detalhamento de pendências, algo que não impedia o uso inicial do App, seria um plus. A troca de empresas, e assim por diante.

Resumindo então no que ele nos ajudou?

- Envolvendo toda a Squad levou com que todos tivessem uma visão do projeto como um todo.

- Ajudou o PO e PM na divisão dos Épicos e ter uma noção mais clara do tamanho do projeto e com isso projetar prazo de entrega com mais clareza.

- Definir MLPs do projeto.

- Melhor acompanhamento do projeto como um todo.

E se quiserem aplicar em algum projeto e quiserem uma ajuda só avisar… Manda uma mensagem que tentarei ajudar no que for possível!

Abraços!