TL;DR
Para começarmos um Event Storming é importante os envolvidos entenderem a terminologia proposta, tanto como participante, tanto como facilitador.
Esse post é reservado para falar o que é cada post-it, cor, posição, modo de escrita e o que significa.
Terminologia: Cores dos Post-its
Isso mesmo, a dinâmica toda gira em torno das cores dos post-its onde cada cor representa coisas diferentes e cada um possui uma maneira de ser escrito, vamos começar pelos básicos que constituem a espinha dorsal da dinâmica, que são:
Eventos ( Laranja ) ■
Comandos ( Azul )
Atores ( Amarelo )
Agregadores ( Amarelo claro )
Todos os outros além desses podem ser opcionais para o cenário e você pode escolher produzir eles ou não, que podem ser:
Hotpoints ( Vermelho )
Sistemas externos ( Rosa claro )
Interfaces ( Verde claro )
Políticas e Regras. ( Lilás )
É importante saber que temos a liberdade de criar cartões escolhendo uma cor diferente dos outros e definindo um propósito, por exemplo: já facilitei workshops que mapearam “custom” post-its como: Riscos (post-it Rosa) e Valor de Negócio (post-it Verde Limão).
Então vamos lá, seguindo a ordem mencionada.
1. Eventos - Events ■
É um evento qualquer coisa relevante que aconteceu no "passado"e tende a ser de simples compreensão para pessoas técnicas e não técnicas, isso é, qualquer pessoa.
Um evento pode ser qualquer coisa e não está limitado somente ao contexto tecnológico.
Eles geralmente são resultado de algum dos seguintes fatores:
Eles são resultados da interação entre usuários.
Eles são resultados de um gatilho ou sistema externo.
Eles são resultados de um gatilho de agendamento.
Eles são resultados do encadeamento de outros eventos.
Cor: Post-its Amarelos em tom Escuro ou Laranja
Posição: Sem dependências, no lugar que melhor o representa na linha tempo. (quando ele acontece)
Como escrever: Substantivo + Verbo no Passado
Exemplos:
Compra efetuada
Pagamento efetuado
Carro conduzido até a garagem
Cadastro do cliente finalizado
Consulta de preço realizada
Check-in realizado no balcão
Cliente recepcionado
Visão do board - Linha do tempo:
É importante identificar eventos cujo o não acontecimento também é relevante, por exemplo:
Compra declinada
Carrinho abandonado
Reserva não realizada
Cliente não compareceu
Visão do board - Linha do tempo:
2. Comandos - Commands ■
Os comandos são ações que geram eventos e normalmente antecedem os eventos. Geralmente são possíveis de serem associados à atores responsavéis por disparar o comando.
É comum o comando estar associado com uma decisão ou interação de algum ator ou usuário.
Cor: Post-its Azuis ■
Posição: Se posiciona a esquerda dos eventos que ele está associado de alguma maneira.
■■
Como escrever: Verbo Imperativo + Objeto (Opcional)
Exemplos:
Pesquisar Reserva
Pesquisar Produto
Realizar cadastro
Preencher formulário inicial
Solicitar ajuda
Realizar Logout
Realizar Login
Pagar com Cartão de Crédito
Pagar com PIX
Visão do board - Linha do tempo:
Comandos podem gerar diferentes e vários eventos e não estão restritos um para um, por exemplo:
Visão do board - Linha do tempo:
3. Pessoas - Actors ■
É um ator toda entidade responsável por disparar um comando, podem ser pessoas, automações, robôs, sensores etc.
É comum os atores serem personas e muitas vezes é descoberto novas personas e atores durante o Workshop.
Cor: Post-its Amarelos Pequenos (Metade de um post-it) ■
Posição: Se posiciona a esquerda dos comandos que ele está associado de alguma maneira.
■■■
Como escrever: Substantivos no plural ou singular
Exemplos:
Cliente
Usuário do Site
Usuário do Aplicativo
Entregador
Motorista
Pessoa
Atendente do Balcão
Fiscal
Recepcionista
Sensor de velocidade
Sensor de presença
Robô de armazém
Sistema de URA
Chatbot
Quanto mais especifico for melhor será o entendimento, como por exemplo, ao invés de cliente de maneira genérica, poderíamos detalhar melhor as características do ator se isso for relevante.
Visão do board - Linha do tempo:
No futuro você pode utilizar o Event Storming para encontrar esses atores e coletar percepções e alguns atores podem participar do Workshop possível.
4. Agregadores - Aggretates ■
Para explicar agregadores é preciso dar um exemplo sobre o conceito de agregados originados no Domain Driven Design e utilizados no Event Storming.
Em poucas palavras: Agregado é um conjunto de entidades e dados que juntos constituem o estado válido de um contexto sistêmico maior, que sozinhas não possuem sentido e garantem sua consistência juntas.
Logo, o Agregado é responsável por garantir a integridade do conjunto e por isso usamos esse post-it para associar eventos e comandos que estão ligados de alguma maneira à um contexto transacional.
Por exemplo, os seguintes eventos fazem parte do mesmo agregado, podendo ter ele qualquer nome:
Produto Adicionado ao Carrinho
Checkout Realizado
Pagamento Processado
Eles possuem o mesmo agregado pois a soma das suas informações constituem algo muito maior que precisa ser consistente e sozinhos não fazem sentido, por exemplo: Pagamento Processado → De que carrinho?
Algumas pessoas gostam de pensar no agregado como o Evento Macro que liga os Eventos de alguma maneira ou por algum motivo.
Cor: Post-its Amarelos Claro
Posição: Se posiciona acima dos comandos e eventos que ele está associado.
Como escrever: É comum serem substantivos ou nomes de processos de negócio, mas esse cartão não possuí regra de escrita e seu nome não é importante, desde que ele agrupe os eventos que fazem sentido.
Exemplos:
Vendas Diretas
Coleta Leads
Atendimento
Suporte ao cliente
Venda online
Garantia
Auditoria
Finalização de Contrato
Pós Vendas
Pesquisa
Checkout
Visão do board - Linha do tempo:
Eles são capazes de associar os grupos de post-its em contextos comuns de transação.
Visão do board - Linha do tempo:
É comum nunca ter sido pensado nesse agrupamento antes, então o nome não é tão relevante desde que agrupe os eventos corretamente.
Já vi pessoas que gostam de chamar o agregado de contexto ou domínio que na minha opinião fazem sentido mas só pelo fato que são termos generalistas demais, eu gosto de ver os agregados como um aglomerado de entidades que combinam seus dados e responsabilidades para atender algum valor ou serviço sem perder sua integridade.
5. Pontos de Dor - Pain Points ■
Pontos de Dor são post-its vermelhos contendo uma breve explicação sobre alguma dificuldade ou problemas que o post-it que está marcado apresenta. Geralmente está conectado com problemas de performance, retrabalho, delays, gastos excessivos, perdas, má impressão, vulnerabilidades de segurança, má gestão etc.
Cor: Post-its Vermelhos
Posição: Preferencialmente tocando os outros post-its que participam desse ponto de dor de alguma maneira.
Como escrever: A escrita é livre e deve trazer um contexto do problema de forma nítida e se possível mensurar os impactos.
Exemplos:
Todo início de mês o servidor fica fora do ar devido alto volume de requisições e causa perda conversão.
Durante os finais de semana o suporte ao cliente demora muito para dar tratativa pois os sistemas que o atendente usa ficam lentos ou apresentam downtimes.
O tempo de esperar para processar o pagamento faz com que os clientes procurem a concorrência.
Não criptografamos os arquivos nesse ponto e eles contêm dados sensíveis de clientes.
Temos muitos bugs e atrasos nessa etapa pois a qualidade dos sistemas envolvidos é muito baixa.
Existem muitas rotinas nesse evento que foram criadas por pessoas que já saíram da empresa e não conseguimos evoluir.
Ninguém na empresa sabe como funciona isso.
Quem criou isso não está mais na empresa e muitas manutenções foram feitas por diferentes fornecedores.
O processo de atualização de estoque tem muitos problemas, viramos madrugadas corrigindo estoque manualmente.
Temos muitas reclamações dos clientes nessa etapa.
Visão do board - Linha do tempo:
Os pontos de dores são muito ricos pois acabam trazendo a tona de maneira muito rápida problemas que talvez nem todos sabiam que existiam, nunca foram compartilhados ou discutidos. Geralmente podem ser estudados pós Workshop de maneira exploratória para endereçar melhorias de fluxo e resultados.
6. Sistemas Externos - External Systems ■
É fato que eventos não são gerados do nada, eles geralmente são resultado do processamento de algum comando e quem realiza esse processamento na maioria das vezes é um sistema.
É comum na maioria dos casos que o sistema seja aquele que recebe o comando e de alguma maneira gera eventos como consequência do seu processamento as vezes chamando outros sistemas.
Alberto Brandolini brinca explicando que External System seria:
“An External System is whatever we can put the blame on”
Traduzindo:
“Um Sistema Externo é tudo em que podemos colocar a culpa” 🤣🤣
Um sistema externo pode ser qualquer coisa fora do nosso controle, que nos faz cair em algumas possibilidades:
É um sistema externo de fato, desenvolvido e ou mantido por uma empresa externa.
É um sistema interno desenvolvido e ou mantido pela própria organização.
É uma organização externa não necessariamente um sistema tecnológico.
É um parceiro que completa ou suporta nosso core business de alguma maneira.
É uma integração com alguma coisa.
É um legado caixa preta que ninguém mais sabe o que é, mas sabe que é ele que faz.
Cor: Post-its grande Lilás claro ou Rosa Salmão
Posição: Preferencialmente em contato com os comandos e eventos que ele está relacionado.
Como escrever: Nomes, siglas e ou nomes próprios que identificam o sistema.
Exemplos:
Módulo Fiscal
E-commerce
Gerador de PDF
Processador de Pedidos
Microserviços de Payment
Gateway de Pagamento
ERP
Controle de Estoque
Mensageria de Notificação para Cliente
Sistema Backend/Backoffice
Salesforce
Visão do board - Linha do tempo:
É comum surgirem sistemas com nomes próprios conhecidos pela organização e na maioria dos casos são identificados por siglas, por exemplo: ERP, STA, SCT, FI.
As siglas são fáceis de lembrar e escrever mas nem todas as pessoas podem saber o que é, então a sugestão é escrever o nome do sistema por extenso se possível como por exemplo: FI - Módulo Fiscal do SAP.
7. Interfaces de Dados - Read Models
As Interfaces de Dados ou Read Models são post-its que representam um conjunto de informações que o ator/pessoa precisa ter acesso para tomar uma decisão, isto é, gerar um comando.
Ao descrever esses post-its é capaz de se perceber o ambiente que o ator está inserido e como essa informação é encontrada e apresentada.
Eles podem trazer discussões sobre pontos de dor e de falhas de processo, no que tange a sequência ideal de passos ou até mesmo a usabilidade de interfaces que o ator tem contato.
Cor: Post-its Verde ou Verde Limão
Posição: Preferencialmente em contato com os atores e pessoas que tomam decisão.
Como escrever: Escrita livre da descrição das informações que ator tem contato.
Importante lembrar que os post-its do event storming são fatos no passado, quer dizer essas informações precisam ser as que atualmente existem e temos certeza que o ator tem disponível, não informações que suponhamos que ele tem ou que precisaria ter.
Exemplos:
Lista de cores de um produto e também a disponibilidade de entrega.
O valor do frete caso ele adicione mais produtos.
O preço dos itens da sacola com descontos aplicados.
As categorias de eletrônicos cyber-monday.
As opções de investimentos a médio prazo com calculo de rentabilidade.
As opções de entrega ou retirada.
Exemplos mais curtos:
Preço
Lista de tamanhos
Valor, tempo de preparo, distância
Tempo, estações próximas
Lista de amigos, agenda dos eventos
Visão do board - Linha do tempo:
É comum utilizarmos uma sequência de passos para descrever as informações, como por exemplo “entro na página inicial, clico em produtos e em seguida clico em adicionar carrinho". O post-it não precisa ter essa sequência pois muitas vezes é uma combinação de passos possível e podem existir inúmeras outras combinações. É preciso focar na qualidade dos dados e das interfaces que ator tem contato.
8. Políticas de Eventos ou Políticas - Policies
Eu prefiro ensinar nos meus times que as Policies do Event Storming são “políticas de eventos”, simplesmente pelo fato que são regras que precisamos cumprir na maioria das vezes obrigatoriamente, toda vez que um comando e um evento acontecem.
Cor: Lilás
Posição: Obrigatoriamente em contato com os comandos e eventos que ele está relacionado.
Como escrever: Escrita livre e geralmente com duas naturezas de informação: O nome e a implementação. O nome é como aquela política é identificada, e a implementação é como ela é executada.
Exemplos: Nome - Implementação
1. Política de Novo Usuário - Política de Boas-vindas quando um usuário se cadastro que executa um Tour pela ferramenta.
2. Política de Onboarding - Enviar o pacote de mimos quando um usuário se registra.
3. Política de Confirmação de Pedido - Enviar e-mail com a confirmação da compra.
4. Política de Devolução de Carro - Levar o carro para limpeza e abastecimento toda vez que ele for devolvido do aluguel.
Visão do board - Linha do tempo
As políticas podem ser executadas por pessoas e softwares e podem gerar outros comandos e eventos. No event storming não temos regras restritas sobre quais post-its são obrigatórios, podemos ter combinações diferentes sem termos problemas, como no exemplo abaixo:
Visão do board - Linha do tempo
9 - Bônus: Riscos - Risks
Antes de mais nada, vale ressaltar que esse post-it Risks, não está presente no livro de Event Storming, explicação abaixo: Em alguns workshops que facilitei nos últimos anos que envolviam a exploração de uma cadeia de valor que tinha como back-end uma composição de sistemas legados e em processo de modernização utilizamos um post-it emprestado de outra dinâmica chamada Risk Storming, link.
O post-it emprestado foi o dos riscos, simplesmente para criar insumos para os times técnicos como por exemplos: system teams, dados, desenvolvedores etc.
Também utilizamos para apoiar estimativas e refinamentos sobre novas features nesse ambiente legado e criar quick wins.
Cor: Rosa ou Vermelho em qualquer tom ainda não utilizado.
Posição: Em contato com qualquer outro post-it que ele está relacionado, na maioria das vezes é com External System e Comandos.
Exemplos:
Formato de dados do sistema XPTO muda o tempo todo.
É comum esse legado ficar indisponível no período de fechamento.
Os componentes desse sistema são lentos.
Não tem estrutura distribuída e escala na vertical.
Existem muitos logs de erro nesse processo.
Se esse sistema cair para tudo.
Existe muitos dados corrompidos, que justifica o setor do empurra barramento.
Temos muitos problemas de infraestrutura.
Perdemos dados frequentemente.
Ainda não está compliance com LGPD.
Tecnologia muito antiga.
Tem muitos bugs abertos ainda não resolvidos.
Não temos pessoas qualificadas para alterar algo nesse sistema.
Fizemos lock-in com uma ferramenta do tipo arrasta e solta e agora não temos mais devs que querem mexer nesse sistema. (dificuldade contratação)
Etc.
Visão do board - Linha do tempo
Existe uma diferença com os pontos de dores, os riscos são informações que temos sobre coisas que não estão funcionando como deveria ou não estão configuradas como deveriam e na maioria das vezes não existem dores relatadas sobre isso.
Por exemplo: Dados não estão sendo criptografados em repouso, existem muitos logs de erros, mas não existe alguém relatando uma dor diretamente sobre isso. Na maioria das vezes estão relacionados e alguns deles no futuro podem gerar pontos de dor.
E talvez se não forem tratados podem custar muito para a organização (riscos).
Capítulos desse post em construção, disponíveis nos próximos dias:
1 | Eventos - Events | ✅ 26-01-2022 |
2 | Comandos - Commands | ✅ 27-01-2022 |
3 | Agregadores - Aggregators | ✅ 27-01-2022 |
4 | Atores - Actors | ✅ 27-01-2022 |
5 | Questões - Pain Points | ✅ 28-01-2022 |
6 | Sistemas Externos - External Systems | ✅ 28-01-2022 |
7 | Interfaces - Read Models | ✅ 02-02-2022 |
8 | Regras e Políticas - Policies | ✅ 02-02-2022 |
9 | (Bônus) - Riscos - Risk | ✅ 02-02-2022 |
10 | Início do Blog Post - Event Storming III - Organizando e Facilitando o Workshop | 🏆 Part III - em construção. |
Esperando ansiosamente os capítulos 7,8,9 e 10