Descoberta dos domínios (DDD) do RD Station Marketing através do EventStorming
Em meados de 2020, quando a RD Station ainda se chamava Resultados Digitais, a área de engenharia e produto já possuía aproximadamente 40 times distintos, resultado de um crescimento acelerado.
O principal produto da empresa chamado RD Station Marketing, que é a ferramenta de Automação de Marketing líder na América Latina, na sua maior parte ainda era um monólito, ou seja, era um só projeto onde os times trabalhavam nele.
Muitos times começaram a sentir a necessidade de extrair serviços deste monólito, assim poderiam ter mais autonomia e independência no dia a dia. Então começou a surgir uma dúvida comum nestes casos: onde e como dividimos o monólito?
Organização dos times
Segundo a lei de Conway, a forma que os times se comunicam e interagem reflete diretamente na arquitetura do sistema, isso refletiu muito a nossa realidade, pois estávamos tentando dividir o produto exatamente como estava dividido os times.
Os times eram separados por funcionalidades (features), que fazia sentido quando a empresa era menor, mas é uma divisão bem diferente da divisão por domínios apresentada no Domain-driven design (DDD) por Eric Evans.
Por exemplo, vamos imaginar um sistema de marketing que possui um controle de leads, um controle de landing pages e um fluxo de automação. Essas são funcionalidades do sistema, por isso é natural que as pessoas pensem em uma divisão dos times como um time que cuida de leads, outro que cuida de landing pages e outro que cuida do fluxo de automação. Por mais intuitivo que pareça, quem conhece o negócio a fundo sabe que não é assim que se divide a jornada do usuário, então dividir por funcionalidade afasta o produto do negócio.
Ainda no mesmo exemplo, se olharmos do ponto de vista de negócio, essas funcionalidades são usadas em três fases da jornada: as landing pages, para atrair e converter os leads, o cadastro de leads, para organizar e segmentar a base de leads, e o fluxo de automação, para engajar os leads.
Essa sensibilidade de estar organizado conforme o negócio se organiza, se deve ao fato dos times se tornarem silos, isso acontece em qualquer empresa, e o contexto do time passa a ser uma visão limitada do todo.
Para então dividir o sistema, teríamos que dar um passo para trás, daí então olhar o elefante por inteiro e repensar como podemos nos organizar melhor.
EventStorming
Inicialmente começamos criando um canal no Slack para promover a discussão entre os times e centralizar o trabalho. Fluiu muito bem organicamente, as pessoas que já tinham iniciado algum trabalho relacionado dentro dos times fizeram apresentações nas reuniões semanais que tínhamos.
Depois, evoluímos para um time de 4 pessoas dedicadas em tempo integral para planejar e liderar as reuniões e dinâmicas, para no final apresentar os resultados.
Os livros Domain-Driven Design Distilled e Implementing Domain-driven Design, do Vaughn Vernon, ajudaram muito no processo de trazer o DDD para o contexto do nosso negócio e a planejar como faríamos esse trabalho na prática. Desse aprendizado vimos que o melhor caminho para descobrir os nossos domínios seria através do EventStorming.
O EventStorming é um formato de workshop que permite uma exploração colaborativa de domínios complexos, foi criado por Alberto Brandolini em meados de 2013 que por coincidência estava escrevendo seu novo livro Introducing EventStorming. O livro ficou à venda no formato digital mesmo em desenvolvimento, mas o conteúdo disponível já foi suficiente para servir como manual para realizarmos a dinâmica(além é claro de todo conteúdo aberto e palestras do próprio autor).
Com tanto conteúdo bom à disposição e um time super qualificado com quem eu aprendo todos os dias (quer fazer parte dessa equipe? Estamos com vagas abertas!), parecia uma tarefa bem simples de realizar. Porém, o desafio já começava pelo tamanho da área de produto e engenharia, além dos especialistas da área de negócio (domain experts) que precisam participar. Já seria impraticável colocar todo mundo junto em uma sala com uma dinâmica presencial, ainda mais em uma dinâmica online para respeitar uma quarentena (COVID-19) recém iniciada.
Planejando um EventStorming online
Brandolini já havia publicado um artigo chamado Remote EventStorming, entre outras declarações em palestras e redes sociais, desestimulando a realização remotamente, mas nesse caso era desistir ou nos adaptar. Conforme a quarentena foi se estendendo, até mesmo ele acabou aceitando a nova condição e escreveu outro artigo chamado EventStorming in COVID-19 times, mas estávamos na mesma situação de experimentar e aprender.
O primeiro desafio foi selecionar as pessoas que iriam compor a dinâmica. Era como fazer uma lista de convidados para um casamento, a vontade era de chamar o máximo de pessoas, mas os recursos nos faziam reduzir a lista ao máximo, sabendo que quem não participasse, ficaria ressentido por não participar.
Para facilitar, resolvemos dividir o trabalho em fases, assim cada uma delas poderia envolver pessoas diferentes em momentos diferentes. Como o primeiro passo era ter a visão do todo, resolvemos usar o Big Picture EventStorming, assim poderíamos construir uma narrativa clara de todo o negócio, de ponta a ponta.
Esta dinâmica geralmente envolve de 15 a 20 pessoas, entre pessoas técnicas e de negócio. Mas na empresa já temos uma área que faz exatamente essa ponte entre os dois, o que chamamos de Product Management, em que temos o papel do Product Manager (PM) que compõem cada time. Como o time é grande, algumas dessas pessoas já tinham trabalhado em funções técnicas e outras com atendimento ao cliente. Também convidamos algumas pessoas de User Experience (UX) para completar a área de conhecimento.
Fechando a lista com os nomes, vinha o próximo grande desafio: marcar uma data em que todas as pessoas pudessem comparecer. No presencial, poderia ser feito em dois dias completos, com paradas para o café e comidinhas irresistíveis. No remoto, além de não ter os aperitivos e esse momento de descompressão, poderia ser muito cansativo esse ritmo de dois dias inteiros seguidos.
Eram muitas hipóteses que tínhamos para arriscar fazer e não ter um resultado satisfatório. Precisávamos testar e reduzir o risco para fazer valer a pena o esforço e dedicação de tantas pessoas envolvidas, então resolvemos rodar uma prova de conceito antes.
Prova de conceito
Como éramos quatro pessoas dedicadas ao projeto, resolvemos simular como seria a dinâmica o mais próximo de como faríamos, assim teríamos pelo menos uma noção de provar cada hipótese levantada.
Para o resultado da dinâmica de teste não conflitar ou influenciar o resultado na dinâmica real, escolhemos uma área de negócio diferente, de uma empresa fictícia. Optamos por fazer um aplicativo de pedir lanches, pois já tínhamos conhecimento do negócio com diferentes aplicativos.
Separamos a parte da tarde para discutir sobre a dinâmica que aconteceria durante a manhã, isso nos permitiu otimizar nosso tempo entre discussões e prática.
A experiência da prova de conceito foi incrível e muito esclarecedora. Vimos que tinham conceitos básicos, como a definição de alguns termos, por exemplo, que não estavam tão alinhados entre nós quatro, assim como tivemos vários insights que só seria possível na prática.
No final, estávamos seguros e preparados para realizar a dinâmica real.
Em ação
Depois de muito alinhamento e várias reuniões depois, conseguimos reservar a parte da manhã de todos por uma semana, de segunda a sexta-feira. A parte da tarde ficaria livre para os participantes resolverem seus assuntos, e nós poderíamos aproveitar para fazer ajustes no rumo da dinâmica e nos prepararmos para o dia seguinte.
No primeiro dia começamos com uma apresentação sobre os conceitos iniciais do EventStorming, falamos sobre o objetivo e partimos para explicação da primeira parte da dinâmica.
A primeira parte é chamada de Exploração Caótica, onde todos ficaram sem se comunicar colocando todos os eventos em um quadro branco de forma independente. Como estávamos remoto, utilizamos o Miro como ferramenta para o quadro.
Já esperávamos muitos eventos, devido a magnitude do produto e a quantidade de pessoas, mas ainda sim nos surpreendemos pela quantidade. Se fosse presencial, faltaria parede para colocar tantos post-it. Como rendeu, acabamos deixando rolar esta parte pela manhã toda.
No segundo dia, começamos a reforçar a linha do tempo. Fizemos o caminho natural da esquerda para direita, removendo os eventos duplicados e ajustando os nomes.
Não foi um trabalho fácil, mas gerou muitas discussões boas. O que mais tivemos dificuldade, foi justamente ordenar os eventos na linha do tempo, como o usuário poderia fazer qualquer etapa a qualquer momento, os eventos acabaram indo mais na direção vertical do que horizontal, diferente do que vimos em outros EventStorming.
Na parte da tarde, refletimos sobre como poderíamos colocar a dinâmica nos trilhos. A solução veio do próprio livro do Brandolini, iríamos extrair os capítulos (chapters) do quadro e depois organizar os eventos por eles.
E foi assim que fizemos no terceiro dia, introduzimos o conceito de outcomes, que identificaria as entregas relevantes para o negócio entre todos os eventos que estavam no quadro. Depois pegamos todos os cartões verdes, que usamos para diferenciar os outcomes, e movemos para um espaço vazio. Agora iríamos focar só na entrega de valor para os nossos clientes, e passamos a ordenar esses outcomes em uma linha do tempo, dessa organização fomos extraindo os capítulos. No final, tínhamos todos os outcomes ordenados e agrupados por capítulos, isso nos deu uma visão muito mais clara sobre a narrativa do negócio.
No quarto dia, pegamos os capítulos e voltamos para o quadro onde estavam os eventos, o que tornou a organização dos eventos muito mais fácil, conseguimos construir uma linha do tempo muito mais clara e consistente.
No quinto e último dia começamos a fazer a quarta etapa, onde definimos as pessoas e sistemas, foi um trabalho bem rápido, e podemos ir para última etapa que era validar as narrativas da linha do tempo construída. Foi nesse dia que vimos o resultado do nosso trabalho, como uma história de um livro, com capítulos, eventos e personagens, a narrativa do nosso negócio foi construída de forma clara de ponta a ponta, sem faltar nenhum detalhe.
Resultado
No final do último dia, pedimos para todos os participantes fazerem um depoimento sobre o trabalho e o resultado. Todos ressaltaram que a discussão durante a construção foi a melhor parte, conseguimos nos aprofundar em todas as áreas e trouxemos entendimento de ponta a ponta do negócio.
Na imagem abaixo está como ficou o quadro. Os cartões amarelos são os capítulos, com seus outcomes em verde, os cartões laranjas são os eventos.
Para validar e reforçar o resultado, mostramos o trabalho para diferentes pessoas de diferentes times que têm contato direto com os clientes. Em todas as reuniões as pessoas tiveram muita facilidade de entender o que foi feito, mesmo não tendo conhecimento sobre o EventStorming, e reforçaram que a narrativa estava bem fiel à realidade do dia a dia dos clientes.
Quando começamos a construir os domínios baseados nesse quadro, estava óbvio a relação um para um dos domínios com os capítulos. Alguns ajustes precisaram ser feitos, mas o trabalho foi bem natural, conforme demonstrado na imagem abaixo.
Aprendizados
Nós empregamos um esforço considerável para chegar nessa separação de domínios, que nos levaram a diversos aprendizados, alguns deles:
- Você precisa se dedicar a essa tarefa, não é algo fácil mas é possível. O segredo é ser Lean e focar no que é importante.
- A diversidade do seu time na dinâmica é importante, tanto na questão da área (engenharia, produto, atendimento ao cliente) quanto em diferentes perspectivas, isso vai garantir que o resultado reflita a realidade do negócio.
- É um trabalho contínuo, você vai colocar bastante esforço no primeiro passo, mas precisa manter isso atualizado com a realidade do seu negócio.
Todo esse trabalho resultou em bons frutos, nós começamos o processo de modularização do nosso monólito, que vai nos permitir extrair serviços quando necessário, também organizamos os nossos times para refletir uma proximidade maior com o negócio, reduzindo a carga cognitiva e dando maior autonomia para todos nesse processo.
Assim, a empresa visivelmente está mais segura para continuar a expansão dos domínios, tendo em vista que entendemos os alicerces do negócio de forma bem mais clara.
