Como utilizamos Domain-Driven Design e Jobs to be done para uma melhor comunicação de produto
A Gestão de Produto (Product Management) está diretamente relacionada à comunicação que acontece entre as pessoas que se envolvem com o Produto. Através de conceitos e técnicas de Jobs to be done é possível que o cliente informe as suas maiores dores, tarefas ou jornadas a serem resolvidas. Desta forma podemos ter uma visão de fora para dentro, ou seja, do Cliente para o Produto. Por outro lado, Domain-Driven Design nos trás uma metodologia para estabelecer uma comunicação simples. Essa troca de informação ocorre entre pessoas que trabalham no produto como: Product Managers, Designers, Engineers, Marketing e Stakeholders. Estabelecendo assim uma visão de dentro para fora.
Afirmar que a comunicação entre as pessoas que se envolvem com o produto é uma das principais responsabilidades da Gestão de Produto parece básico. Mas, “o óbvio precisa ser dito”. Confesso que “Googlei” o autor desta citação para o texto ficar mais “intelectual” e não encontrei. Porém acabei me deparando com outras duas citações que vão de encontro ao que estou querendo dizer. “O óbvio é aquilo que ninguém enxerga, até que alguém o expresse com simplicidade.“ Khalil Gibran e “O óbvio é a verdade mais difícil de se enxergar.” Clarice Lispector. De fato, o básico precisa ser dito, a fim de que interlocutor e receptor se expressem até garantir que todos estejam entendendo. O “objeto” que está sendo comunicado precisa estar sendo interpretado da mesma forma. Este processo deve ser contínuo e consistente.
As necessidades dos nossos clientes e a complexidade dos nossos produtos se expandem exponencialmente. Considerando que “Tudo quebra na escala”, citando agora Bruno Ghisi (Co-Founder e CTO da RD). Na busca por um processo fluído de entendimento do produto temos grandes desafios destacados abaixo:
- Como garantir que este processo de comunicação se mantenha simples para que seja entendido por todos envolvidos?
- Como o produto pode ser mais claro e simples para resolver diretamente as tarefas do cliente?
- Como Product Managers, Engenheiros, Designer, Product Marketing e Stakeholder enxergam o produto atual e a visão de longo prazo?
Conceitos e técnicas de ”Jobs to be done” e “Domain-Driven Design” tem nos ajudado a resolver estas perguntas no nosso dia a dia em Produto na Resultados Digitais.
Domain-Driven Design (DDD)
Uma das características que impedem uma comunicação fluida e clara entre as pessoas é a Polissemia. A polissemia é um dos principais problemas que o DDD se propõe a resolver. Porém, antes de aprofundarmos em conceitos do DDD é importante destacarmos um pouco mais sobre o que seria esta Polissemia.
Polissemia
Polissemia é quando algo tem vários significados. Para exemplificar pergunto para vocês: O que significa a palavra “banco”? Provavelmente você pensou em dois ou mais de um significados. Porém, se uma pessoa te manda a mensagem “Estou na fila do banco” é bem mais simples determinar o significado da palavra “banco”. Fica claro que “banco” se refere a uma agência bancária. Desta forma, podemos dizer que para quebrar a Polissemia é necessário um Contexto.
Bounded Context
Contexto é essencial para que simplificar o processo de comunicação. O DDD define como Bounded Context contextos que permitirão identificar de forma mais direta responsabilidades de negócio, entidades e objetos contidos neste contexto. Estes Bounded Contexts devem garantir que as responsabilidades definidas para cada contexto não irão se expandir a ponto de ficar complexa e com ambiguidades. O Bounded Context deve ser capaz de responder todas as necessidades referente às suas regras de negócio de forma independente.
Continuando nosso exemplo da palavra “banco”, vamos a uma outra situação. Você está indo encontrar com um amigo e ele te manda uma mensagem “Estou te esperando em frente ao banco da praça”. Chegando na praça, você vai até o banco de assentar e ele não está lá, posteriormente ele te confirma que está em frente ao Banco do Brasil que tem naquela praça. Veja que aqui o contexto “praça” não foi suficiente para quebrar a Polissemia. O DDD define que além dos Bounded Context temos ter uma linguagem ubíqua para garantir uma comunicação simples e efetiva.
Ubiquitous Language
A Linguagem Ubíqua ou Linguagem Universal é uma forma única pela qual podemos definir algum objeto. Contextos, Entidades, Telas, Campos, ou seja tudo no seu Modelo deve ter uma nomenclatura única para transmitir uma linguagem universal de entendimento daquela “coisa”. Eliminando assim complexidade, ambiguidade e confusão no processo de comunicação.
Voltando ao nosso exemplo, se substituirmos a palavra “banco” por “Agência Bancária” ou “Banco de Assentar” simplificamos o processo de comunicação através de uma linguagem universal.
O Product Manager é um agente responsável por evangelizar conceitos do produto de forma contínua para garantir que todos estejam na mesma página. Promovendo assim alinhamento com todos os envolvidos através de uma linguagem universal.
Jobs to be done
Jobs to be done, por sua vez, consiste em resolver tarefas/trabalhos que o cliente precisa executar. Podemos entender também que o Produto se propõe a resolver essas várias jornadas ou problemas do cliente.
Com necessidades complexas que se desdobram em várias possibilidades, de diferentes personas, é essencial isolar cada necessidade e persona com objetivo de simplificar o entendimento do processo e trazer foco para experiência do Cliente. Pesquisas com usuário, experimentos via produto e outra técnicas de Discovery nos levarão a um aprendizado para maior entendimento deste fluxo. Dando uma visão global de como o Produto resolverá o problema do cliente.
Contudo, como vincular estas várias jornadas aos vários Bounded Contexts do Produto?
DDD + JTBD
Se temos uma visão global ao definir a Jornada e experiência do usuário, em contrapartida, temos uma visão local em cada Bounded Context do Modelo. Unir os conceitos de DDD e JTBD nos permitirá conectar:
- Como o Cliente enxerga o produto (Visão Global)
- Como Engenharia, máquina entende os Contextos (Visão Local)
Cada Jornada do cliente irá transitar entre os Contextos, garantindo assim uma comunicação mais simples e controlada. Direcionando os envolvidos a alcançar um objetivo (Outcome) de forma clara e direta.
Na prática
Na Resultado Digitais sou o PM responsável pelo nosso produto de Subscription Management and Billing. Sistema este responsável por gerenciar todas as assinaturas da RD, desde a oferta de planos até o processo de bilhetagem e cobrança.
Tínhamos um Modelo muito complexo e com várias entidades assumindo muitas responsabilidades o que dificultava muito alguns processo como:
- Identificação de problema junto aos clientes
- Abordagem de hipóteses de solução com Designers e Engenheiros
- Priorização com Stakeholder.
Mesmo com produto evoluindo e avançando em complexidade estamos hoje conseguindo quebrar toda esta visão em abordagens mais simples através dos conceitos de DDD.
Tínhamos um único Modelo com foco em pagamentos que foi ao longo do tempo se tornando super complexo. Hoje temos Bounded Contexts que quebram e simplificam este Modelo, isolando o funcionalidades de Pagamentos em um Contexto, conforme imagens 3 e 4 abaixo.
As necessidades do clientes transitam pelos Contextos trazendo clareza e uma comunicação simples entre todos as pessoas envolvidas com o produto.
No vídeo do Webinar vocês podem conferir maiores detalhes sobre como quebramos o Modelo e uma entidade com polissemia. Bem como, alguns resultados que estamos encontrando ao utilizar estes frameworks de comunicação.
Conclusão
O foco está na melhoria da comunicação para que as pessoas envolvidas estejam na mesma página. Se a comunicação está confusa, o diálogo está complexo e ambíguo, sem dúvida você não quebrou ou desdobrou o suficiente o “objeto”, seja a Jornada do cliente, a Entidade, o Contexto.
Entender o cliente e o problema dele é fundamental para direcionar o seu produto. Ter uma linguagem comum com os Engenheiros é base para construir o produto. Alinhar com os stakeholder e garantir que eles estão entendendo sua visão é essencial para unir o tático com o estratégico.
