Atualmente estou vivendo a construção de um novo produto, do zero. Tem sido uma experiência muito rica e vou aproveitar este espaço para compartilhar alguns aprendizados, sendo o primeiro deles o tema deste artigo.
Começando pelo começo
Sim! Redundante! Um produto sempre tem muitos "começos", desde as primeiras ideias que nascem e morrem, até os primeiros benchmarks, Layouts, fluxogramas, POCs, entre muitos outros.
É difícil determinar onde, realmente, é o começo, mas gosto de pensar o seguinte:
A partir do momento onde você perde o sono por algo, você já começou!
Desde as primeiras ideias até perdermos o sono foram mais de 2 anos. Transformar ideias em um produto é uma tarefa complicada. Vender Software como um serviço, mais ainda!
Depois do início
Poderia escrever um artigo inteiro somente com as pautas das reuniões que aconteceram nos últimos meses, mas você certamente não gostaria de ler sobre isso! Portanto, vou focar nos principais pontos de aprendizagem que tivemos até então. Boa leitura!
Visão de produto
Como as pessoas-chave que vão construir o produto o enxergam? Esse ponto é crucial, pois:
Para quem não sabe para onde vai, qualquer caminho serve…
Alice no País das Maravilhas, Lewis Carrol
No entanto, como expor uma visão de algo extremamente complexo? Como fazer as pessoas enxergagem um produto da mesma forma que você? Como compartilhar ideias e pensamentos que amadureceram durante anos na sua mente?
Este é o maior desafio na concepção de um produto!
Mas é claro que diversas outras pessoas e empresas já passaram por isso antes, então vamos analisar com pouco o passado!
Histórico da modelagem de software
Me lembro até hoje do meu pai, analista de sistemas desde a década de 1980, me contando sobre um sistema que fez para um escritório de contabilidade.
"Rogerinho, tive que pegar vários papeis que estavam no Arquivo da empresa para entender como que eles guardavam os documentos, depois fiz uma série de entrevistas. Passei muito tempo nisso, depois fiz um sistema em COBOL que tinha que rodar só com 16KB de ram. No final o cliente adorou. Passei lá depois de 10 anos e eles ainda estavam usando o sistema!"
Analista de sistemas, como era conhecido esse trabalho. Primeiro uma grande análise, depois sistematizar.
Conforme o mundo avançou e evoluiu, podíamos fazer sistemas que usassem muito mais do que 16Kb de memória RAM, bem como podíamos agregar complexidade no negócio das empresas. Sistematizar já tinha ficado no passado.
Jeff Sutherland, em 2001, criou o manifesto ágil, um documento com alguns princípios para que o desenvolvimento de software se tornasse algo antifrágil. A parte de análise antes de se desenvolver um software estava sendo feita com muita energia, meses e meses de planejamento, mas o resultado era um software que já não atendia os requisitos de negócio.
Assim como o Universo se expande de maneira acelerada, o nosso mundo está mudando de forma cada vez mais rápida.
Um pouco depois da crise de 2008, quando o mundo passou a viver um momento muito próspero cujo custo do dinheiro (juro) estava batendo recordes negativos, surgiu um livro que se popularizou rapidamente: Lean Startup, de Eric Ries.
Foi um livro muito importante, pois introduziu e popularizou alguns conceitos vitais no desenvolvimento de software atualmente, tais como:
- MVP (Produto minimamente viável)
- Continuous Deployment
- Testes A/B
- Pivô
- Entre outros..
Esse novo mindset levou o mundo a fazer o extremo oposto do que meu Pai fazia nas décadas de 80 e 90. Pouquíssima análise, muito sistema! Dinheiro farto em startups, unicórnios com aportes bilionários, contratações em massa. Entre 2008 e 2021 o mundo passou por uma grande abundância de investimento e dinheiro barato. O custo o erro era barato demais.
Erre rápido, aprenda rápido. Lean Startup, Eric Ries
Mundo atual: cenário pós pandemia
A economia vive em ciclos, se há abundância, logo haverá escassez. As grandes economias injetaram muito dinheiro para bancar o cenário caótico pandêmico. A oferta de capital no mercado cresceu muito, em outras palavras, inflação.
Esse fenômeno financeiro coloca o desenvolvimento de software moderno em uma situação nunca antes enfrentada:
O erro, hoje, é caro. Devemos continuar buscando velocidade e errando muito para aprender muito? Se antes uma startup suportava 100 erros, hoje, quantos erros ela suportaria? Se fossemos olhar para o atual preço do dinheiro (juro) o valor seria algo em torno de 5~~10 erros.
Papel da modelagem na redução dos erros
Visto que estamos em um cenário muito diferente do que há apenas 2 anos, devemos nos preocupar com a quantidade de erros que somos capazes de suportar. É aí que entra a importância modelagem.
Diferente do que era feito pelo meu pai há mais de 20 anos, hoje existem técnicas modernas de modelagem de negócio e de software, as quais ajudam a construir uma visão de produto e que contribuem para a maior assertividade. A seguir destacarei uma delas.
Domain Driven Design
Com o objetivo de atacar a complexidade de software onde realmente importa, o DDD tem se popularizado cada vez mais e já é referência para diversos notáveis desse ramo, entre eles: Eric Evans, Martin Fowler, Elemar Jr. Grandes empresas também: Airbnb, Uber, Netflix, Microsoft, Amazon, SoundCloud, The Guardian, Zendesk, entre outros.
Em Domain Driven Design, existem 3 tipos de complexidade que compõem um software:
- Domínio — Inerente ao problema de negócio que estamos tentando resolver
- Solução Técnica — Com relação as técnicas e tecnologias (frameworks, ambientes operacionais, etc) que optamos por adotar
- Legado — Soluções que precisamos continuar suportando, alheio a nossa vontade.
A única que queremos "pagar" é pelo domínio, pois é nela que as empresas ganham dinheiro e constroem diferenciais no mercado.
Modelando um produto usando Domain Driven Design
A primeira grande pergunta que temos que fazer é:
Pergunta 1: Qual é o ponto mais importante do meu produto?
É uma pergunta extremamente difícil de responder. Caso você tenha pensado "tudo" tenho uma má notícia para te dar: você não conhece seu negócio.
Para fins didáticos, vamos pensar em um ecommerce simples.
O que compõem um ecommerce simples?
Podemos listar:
- Produtos
- Vendas
- Pagamento
- Logística
- Clientes
- Atendimento
- Administração
- Estoque
Existem outros pontos, mas para simplificar vamos restringir aos citados anteriormente.
Caso você faça novamente a pergunta 1 talvez seja um pouco mais fácil, mas ainda dá para levantar dúvidas. Seria o Cliente (Ex: Gucci)? Os Produtos (Ex: Shopee)? A Logística (Ex: Amazon)? As Vendas (Ex: Walmart)?
Para facilitar, o DDD nos dá uma ferramenta chamada Mapa de Contexto.
Nela iremos dispor os contextos que compõem o produto e vamos criar relacionamentos.
Dentro do exemplo passaremos a ter algo assim:
Agora, vamos classificar em 3 tipos diferentes:
- Verde: Core Domain
- Amarelo: Contextos de suporte, que ajudam o Core Domain
- Cinza: Contextos Genéricos, geralmente são serviços terceirizados
Reparem que, para outras empresas (negócios) essa classificação poderia ser completamente diferente. É realmente uma decisão de negócio!
Para você, como faria essa classificação?
A pergunta acima é equivalente a Pergunta 1. Viu como ficou mais fácil?
O DDD permite expandir muito a profundidade do olhar de negócio, mas de uma forma estruturada e enxuta. De uma forma em que seja fácil todas as pessoas-chave do projeto entenderem onde devem concentar seus esforços!
Conclusão
O grande aprendizado que tenho construído é que, para que uma visão fique clara o suficiente ela precisa ser modelada. Ao mesmo tempo vivemos um período economicamente desafiador, no qual o preço do erro está 20x mais caro do que há apenas 2 anos. Trabalhar a modelagem do produto passou a ser um "seguro de vida" do produto, o qual devemos investir para garantir seu crescimento. Certamente é um desafio equilibrar a velocidade de entrega com o planejamento, mas em um cenário de risco devemos investir na preparação do produto bem mais do que num passado recente.
Se eu tivesse apenas uma hora para cortar uma árvore, eu usaria os primeiros quarenta e cinco minutos afiando meu machado. Abraham Lincoln
Referencias e fontes: