EventStorming Big Picture: como funciona?
No artigo anterior fiz uma breve introdução sobre EventStorming e suas aplicações, a seguir farei uma breve introdução a um dos formatos que mais utilizo:
o EventStorming Big Picture.
O que é EventStorming Big Picture
O Workshop de EventStorming se originou como uma prática presencial, mas como muitas outras ferramentas se fizeram adaptações para realizar de maneira remota. Neste exemplo irei focar no modelo remoto, onde em todos os casos utilizo o Miro, ou outro parecido que permita a colaboração em tempo real.
Acredito que o EventStorming Big Picture seja um dos mais importantes na minha caixinha de ferramentas. Pois, ele abrange quase todos os elementos que se usam em outros formatos do workshop e vai te colocar rapidamente no caminho para explorar e modelar o domínio com quem entende o que é essencial para o negócio e com quem sabe o que é possível de construir para resolver o problema de nossos usuários.
Lembre-se, esta é a minha interpretação de como fazer EventStorming Big Picture baseado na minha experiência e conhecimento.
Na minha opinião, o objetivo principal do EventStorming Big Picture é obter uma visão sistêmica de alto nível de como funciona o domínio, jornadas do usuário ou fluxos de trabalho.
EventStorming Big Picture de um Domínio de portal de notícias
Podendo assim envolver pessoas não técnicas que conhecem como opera o negócio ou uma parte e visualizar processos que são dependentes da cadeia principal de valor. Recomendado para mapear o estado atual (as-is) e assim visualizar potenciais pontos de evolução.
Como fazer EventStorming Big Picture
Para construir o Big Picture precisamos de no mínimo 3 horas para dar tempo para divergir, explorar e convergir.
Começamos instigando os participantes para descreverem o que acontece em um domínio específico ou jornada de um usuário criando os eventos que são importantes desde sua perspectiva que acontece no domínio sendo explorado.
E para isso é muito importante deixar claro qual é o domínio que se está explorando, pode ser uma jornada de usuário ou tudo o que acontece dentro de um processo específico de negócio.
Nesta etapa muitas pessoas vão se perguntar “o que é um evento”? Então crie um evento de exemplo utilizando o post-it laranja e recomende escrever a expressão em passado, pois um evento é algo que já aconteceu, mas não procure corrigir as pessoas muito cedo!!
Estar correto nesta etapa é menos importante do que criar opções e oportunidades de conversação para poder avançar.
Por exemplo, vamos explorar o domínio ao se realizar uma compra em um simples E-Commerce:
Eventos criados de maneira caótica pelos participantes
Com cada participante criando eventos sem ordem e talvez repetidos gera um estado caótico, o que faz parte do processo de exploração para criar opções. Depois para poder validar estes eventos precisaremos que sejam ordenados em uma linha do tempo de esquerda para direita.
Perguntando algo como: faz sentido que o evento “envio iniciado” esteja depois de “envio concluído”?
Esta simples pergunta facilita a conversa necessária para chegar num consenso sobre como realmente funciona o processo de compra e entrega em nosso exemplo de E-Commerce.
Eventos ordenados de maneira colaborativa
Ao ordenar os eventos começam a surgir as primeiras perguntas, pois o que pode ser muito óbvio para alguns, para outros não está claro. Por exemplo: o envio pode iniciar antes do pagamento ser realizado?
Todos estes eventos fazem parte de qualquer E-Commerce, porém à medida que formos explorando o pessoal de UX ou Devs farão perguntas aos especialistas do domínio como um Stakeholder (e vice-versa) trazendo clareza para dúvidas que estavam escondidas.
Os participantes engajam em uma conversa para definir a modelagem do domínio de maneira visual e colaborativa. Juntos criam uma linguagem Ubíqua deixando claro os conceitos utilizados na modelagem de maneira contextualizada. Aqui aproveite e crie um glossário para descrever o significado de cada conceito como:
- Carrinho de Compra: Lugar onde se encontram os itens que o comprador vai escolhendo antes de concluir a compra e realizar o pagamento.
E se ninguém souber responder? Ou detectarmos um ponto de risco para ser analisado com outras pessoas? Não pare o workshop! Sinalize estes pontos em aberto para endereçar em outro momento usando o post-it chamado Hotspot. Isto também ajuda a manter o foco no que é realmente essencial para avançar.
Hotspot para conversar depois com a pessoa certa sobre
Após a ordenação dos eventos na linha do tempo que construímos colaborativamente, uma pessoa precisa ler em voz alta cada um dos eventos começando da esquerda, gerando narrativas que contam uma história chegando em um consenso de como descrevemos e entendemos o domínio. É normal apagar ou criar novos eventos à medida que formos chegando em consenso.
Agora vamos identificar quais são os eventos “pivô” que são os eventos mais importantes e marcantes da história que está sendo contada, por exemplo, onde tem passagem de bastão ou uma transição na história que mudam o estado do processo criando um novo contexto. Um evento pivô no processo de compra poderia ser “pagamento realizado”, já que esse evento encerra a compra e inicia um novo processo de entrega.
Eventos pivô podem ser sinalizados aumentando o tamanho do post-it
Estes eventos são importantes para identificar mais tarde a delimitação de contextos.
Para avançar precisamos entender quem ou o que causam estes eventos, ou seja, quais são os atores (ou pessoas com papéis) e de que maneira interagem com estes sistemas. Você poderia imaginar que cada evento é o produto de um comportamento que pode ser sinalizado com o post-it azul chamado de “comando” ou “ação” e os atores com post-it amarelo escrevendo o papel que o ator tem no processo, e o sistema com post-it roxo.
Semântica a seguir para emergir estrutura que seja legível o suficiente para formar uma narrativa
Identificando os sistemas, os atores e os comandos podemos visualizar a dependência entre sistemas internos ou externos, e principalmente contar a história da jornada para se concluir um objetivo, por exemplo: “um possível comprador deseja comprar um produto adicionando o item no carrinho de compras”
Jornada do usuário completa, com os atores, comandos executados em sistemas e os eventos resultantes do comportamento
Fazendo um zoom na parte do carrinho de compras e o pagamento:
Repare que à diferença do evento, um comando é escrito no estilo imperativo, por exemplo: “adicionar item” ou “pagar”.
Uma vez que conseguimos visualizar quem, como e quando o usuário interage com o sistema para resolver seu problema, podemos agora partir para emergir estrutura que será muito importante no momento em que precisamos entender como modularizar nosso sistema de maneira que reflita o negócio. Separar por contextos é necessário para evitar conceitos ambiguos ou universais onde toda a organização precisa definir uma única palavra para dar significado a algum conceito utilizado nos processos do negócio. A falta desta delimitação geralmente causa sistemas altamente acoplados repletos de ambiguidades.
Por exemplo: “Conta do Usuário” no contexto de Banco significa algo diferente no contexto de Marketing ou Identificação e Autenticação do Usuário. Cada conceito ou modelo, contém responsabilidades e características (propriedades) diferentes que se não delimitar o contexto dará origem a um grande modelo que sofrerá impactos sempre que algum dos contextos precisar evoluir.
Narrativas delimitadas por contexto ou sub-domínio
Não se apegue a contextos já definidos no mercado, o importante que faça sentido para seu negócio e as pessoas que atuam nele, por exemplo:
Os contextos podem se comunicar despachando eventos, por exemplo: sempre que um checkout é realizado, o estoque precisa dar de baixa no item comprado.
As regras do jogo
Perceba que cada elemento tem uma cor e uma ordem, estas são as regras do jogo para poder entender e ler o resultado de um EventStorming.
Perceba que os atores interagem com o sistema executando comandos, e o evento é o resultado deste comportamento que pode ser utilizado para dar continuidade ou início a outra etapa de um processo, ou jornada do usuário.
Com estes simples elementos e mantendo esta ordem – ator > comando > sistema > evento – podemos modelar e explorar domínios sem precisar de inserir termos técnicos pouco acessíveis para os especialistas de domínio / negócio e deixando para decidir qual será a solução técnica no momento certo com as pessoas certas.
Visualize os potenciais pontos de evolução
Os participantes do workshop, após terem modelado todo o processo e ter tudo sendo apresentado de maneira simples sem “tecniquês” ou abstrações ambíguas, irão enxergar de forma mais fácil os potenciais pontos de evolução onde existem problemas ou oportunidades de melhoria fazendo sugestões.
Para tornar este processo colaborativo começaremos com dois elementos, um balão (ou post-it) verde para as oportunidades e um balão (ou post-it) magenta para indicar problemas ou coisas que impactam de maneira negativa.
Em caso de se ter pouco tempo restante para discutir cada uma das oportunidades e problemas, você pode trazer mais um elemento, uma seta preta para que os participantes indiquem e votem quais são os lugares que desejam depositar maior atenção. Você pode limitar a duas setas por participante para votar, porém, não é uma regra, no final o que importa é que seja visível onde estão os pontos de maior prioridade.
Conclusão
Falamos anteriormente no post introdutório sobre EventStorming, mas acho importante ressaltar aqui que o EventStorming Big Picture e Process Modeling podem ser utilizados para mais do que desenvolver sistemas, por exemplo:
- Otimizar fluxos de trabalho onde todos os envolvidos terão a oportunidade de participar e apontar padrões ocultos ou propor soluções para otimizar após enxergar como cada etapa impacta no trabalho das pessoas que participam do fluxo.
- Mudança organizacional utilizando a emergência dos contextos e sub-domínios para delimitar as responsabilidades de cada time e alinhar com como o domínio do seu negócio funciona. Segundo a Lei de Conway “Organizações que desenvolvem sistemas de software tendem a produzir sistemas que são cópias das estruturas de comunicação dessas organizações”, então se a maneira como sua organização se organiza e comunica é complexa, com ruído e cheio de ambiguidades ou pontos cegos, tudo isso será refletido no sistema ou solução desenvolvida.
Quer explorar e criar soluções de maneira colaborativa com seus times com o EventStorming?
Clique aqui e saiba como nós podemos te ajudar a derrubar as barreiras entre o pessoal técnico e o de negócio focando no que é essencial para o sucesso do seu produto!
