Arquitetura orientada a procrastinação

Imagem: reprodução internet

“Eu escolho uma pessoa preguiçosa para um trabalho difícil, pois uma pessoa preguiçosa encontrará uma maneira fácil de resolver o problema”(1).

Já vi inúmeras vezes esta frase, mas aqui não falaremos de preguiça e sim de tomar decisões no momento certo, com as informações corretas e de como trabalhar em projetos com grau de incerteza elevado.

O processo de desenvolvimento é um aprendizado contínuo: vamos conhecendo os domínios do problema e os clientes, e isso nos permite escrever um código mais adequado, legível e eficiente. Assim como quando falamos da área de Produto, na qual existem diversas técnicas para descoberta, com a criação de hipóteses para validação e com erros sendo absorvidos como aprendizado, também no processo de desenvolvimento deve ser assim e não devemos ter medo de refatorar código. Por um outro lado, algumas decisões cobram mais caro que outras, por exemplo, fazer uma migração de um banco de dados para uma tecnologia diferente não é um processo simples.

O Mínimo Viável

MVP, do inglês Minimum Viable Product (produto mínimo viável) é uma prática famosa entre startups, onde os ciclos precisam ser rápidos para permitir uma evolução na mesma velocidade. A intenção é termos uma primeira versão do produto o mais rápido possível para que nosso usuário possa testar e opinar e assim tiramos “achismos” do design do produto. Nesse processo, desejamos que o sistema tenha funcionalidade e entregue valor desde sua primeira versão.

O tipo de banco de dados ou a infraestrutura utilizada entregam algum valor para seu cliente? Geralmente o usuário não se importa (e nem deveria) se seus dados são persistidos em um banco relacional ou não relacional, se a arquitetura é monolítica ou em microsserviços, para ele o sistema deve ser responsível e confiável. Na primeira versão do sistema é possível que ninguém conheça bem o suficiente o domínio do problema para fazer esse tipo de escolha.

O time onde atuo hoje teve a oportunidade de vivenciar esse tipo de situação na prática. Em um projeto de inovação com diretrizes muito bem definidas, mas com um alto grau de incerteza, nosso dia a dia foi baseado em provas de conceito e nosso MVP não possuía um frontend web nem um banco de dados.

Encontramos nos Jupyter Notebooks(2) uma forma de expor funcionalidade para nossos usuários chave sem a necessidade de investir meses de desenvolvimento em um framework web e simples arquivos em disco foram o suficiente para nossas necessidades de persistência.

Evolução contínua

Eventualmente se torna inviável seguir um projeto sem algumas estruturas. Decisões tomadas em estágios iniciais, baseadas em provas de conceito, passam a atrapalhar uma evolução mais rápida do produto e é nesse momento que devemos parar de procrastinar uma decisão e, com todo conhecimento adquirido específico do domínio trabalhado, podemos escolher com maior acurácia e precisão.

No nosso caso, percebemos que não faria sentido ter apenas um banco de dados, os tipos de informações a serem persistidas possuem características muito divergentes e assim conseguimos definir uma estratégia para cada tipo de dado. Esse processo também nos permitiu enxergar com maior clareza os domínios do nosso problema, o que trouxe um desenho de arquitetura de código que está nos auxiliando a entregar com maior velocidade as novas features.

Durante todo esse processo é muito importante ter clareza e alinhamento entre os times de Produto e Engenharia. É preciso que esteja claro onde uma decisão está sendo postergada para que um débito técnico seja priorizado sem surpresas, quando o momento for propício. É importante também que o time de Engenharia seja envolvido cedo na ideação de um produto, assim todo o conhecimento de negócio vai se sedimentando e é possível chegar mais rapidamente a um design de código que atenda as demandas.

Postergue decisões: com mais tempo criamos um entendimento melhor do problema, e assim conseguimos propor soluções sob medida.

Alinhe expectativas: é importante que todo o time, técnico e não técnico, esteja na mesma página para essa estratégia funcionar sem acumular débitos.

Simplicidade e Assertividade

Mantendo o projeto simples (keep it simple!(3)), alinhando expectativas e aguardando o momento certo para tomar decisões chaves, estamos conseguindo aos poucos tornar concreto um projeto de inovação com altíssimas demandas, mesmo em frente a diversas incertezas e desafios.

E com base nessa experiência, eu faço um convite: vamos procrastinar mais nossas decisões de arquitetura?

Referências

1: “I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.” — Frase geralmente atribuída a Bill Gates, mas sem referência certa.

2: Jupyter Notebooks são arquivos que, em conjunto com o Jupyter Server, permitem a execução de código de maneira iterativa e em formato de caderno.

3: “Keep It Simple, Stupid (KISS)” é um princípio comumente utilizado no desenvolvimento de software.