MDP: o playbook para projetar releases semanais que entregam valor real em B2B

A cadência semanal funciona quando o tamanho da mudança é compatível com a capacidade de teste e operação. Uma equipe que tenta entregar uma grande integração, uma alteração de modelo de dados e uma nova experiência de usuário na mesma semana não está praticando MDP. Está apenas comprimindo um projeto tradicional em um calendário menor.

Use uma definição de pronto que inclua produto e operação. Além dos critérios funcionais, verifique logs estruturados, alertas relevantes, permissões, comportamento em caso de falha, documentação mínima e plano de reversão. Em sistemas B2B integrados a SAP, ERPs ou Power BI, valide também idempotência, limites de tempo e tratamento de indisponibilidade do sistema externo.

Feature flags são úteis porque separam publicação técnica de exposição ao cliente. Uma flag simples pode controlar o acesso por organização, perfil de usuário ou percentual de tráfego. Ela deve ter proprietário, data de revisão, comportamento padrão seguro e uma condição explícita para ser removida, para não virar dívida permanente.

A estratégia de deploy precisa acompanhar o risco. Uma alteração pequena pode usar publicação gradual; uma migração sensível pode exigir execução em paralelo, validação de dados e reversão planejada. O guia sobre feature flags, canary, blue-green e dark launches ajuda a escolher o mecanismo de exposição adequado sem tratar todas as releases como iguais.

O time também precisa de limites de trabalho em progresso. Uma regra prática é não iniciar uma nova fatia enquanto a anterior não tiver hipótese registrada, critério de aceitação e telemetria mínima. Menos itens abertos reduzem troca de contexto e aumentam a chance de uma entrega realmente chegar ao usuário.

Para acompanhar a saúde do fluxo, use métricas de entrega reconhecidas, como frequência de deploy, tempo entre alteração e produção, taxa de falha de mudança e tempo de recuperação. O relatório State of DevOps do Google Cloud apresenta pesquisas e práticas sobre desempenho de entrega, mas essas métricas devem orientar melhoria do sistema, nunca servir para comparar indivíduos ou estimular publicação artificial.

O primeiro erro é confundir release semanal com sprint semanal. Uma sprint pode terminar com código pronto, mas um MDP termina com uma mudança observável em produção. Se a equipe entrega apenas em homologação, ainda não fechou o ciclo de aprendizado.

Outro problema é fatiar por camada técnica. Entregar primeiro banco, depois serviço e depois interface produz componentes, não valor. Prefira fatias verticais, como registrar e acompanhar um chamado, mesmo que a primeira versão tenha escopo limitado e pouca automação.

Também é arriscado medir sucesso por login ou page view. Um decisor B2B pode acessar o sistema uma vez por mês, enquanto o indicador relevante é o tempo de resolução, a redução de retrabalho ou a conclusão de uma etapa regulatória. A métrica precisa representar o trabalho que o cliente deseja melhorar.

A pressa para agradar um cliente pode gerar personalizações que inviabilizam o produto. Antes de aceitar uma demanda, classifique-a como problema recorrente, requisito contratual, adaptação específica ou pedido de conveniência. Uma flag por organização pode ser apropriada para testar uma variação, mas não deve esconder um produto fragmentado indefinidamente.

Há ainda o erro de ignorar o buying center. Usuário, gestor, comprador, segurança e área jurídica podem avaliar a mesma release por critérios diferentes. Para mapear essas expectativas, use um roteiro de discovery para buying centers B2B antes de transformar feedback em prioridade.

Por fim, algumas equipes tentam resolver qualquer dificuldade de entrega migrando imediatamente para microsserviços. A cadência semanal depende mais de modularidade, testes, automação e limites claros de responsabilidade do que de uma arquitetura distribuída. A decomposição deve responder a gargalos comprovados, como escala independente, isolamento de falhas ou autonomia de domínios, e não a preferência tecnológica.

O MDP não é uma arquitetura permanente nem uma justificativa para ignorar engenharia. Ele é um modo de reduzir risco enquanto o produto ainda está aprendendo. Quando as hipóteses principais são confirmadas e o uso cresce, o foco muda de descobrir valor para sustentar volume, confiabilidade, segurança e previsibilidade.

Sinais de transição incluem aumento recorrente de incidentes, deploys que exigem coordenação entre muitas áreas, consultas lentas em jornadas críticas, filas de suporte causadas por limitações estruturais e equipes que não conseguem alterar um domínio sem testar o sistema inteiro. Outro sinal é a necessidade de escalar partes diferentes do produto de forma independente.

A sequência mais prudente costuma começar por um monolito modular bem delimitado. Separe domínios, contratos, dados e responsabilidades antes de extrair serviços. Só faça a extração quando houver uma razão operacional clara, como isolamento de falhas, escala desigual ou necessidade de autonomia de implantação.

Em um produto que passou de centenas para dezenas de milhares de usuários, a decisão pode envolver cache, índices, filas, processamento assíncrono, particionamento de dados e melhoria de consultas antes de microsserviços. O critério é o gargalo medido. Sinais de que um produto precisa migrar para arquitetura orientada a eventos ajudam a diferenciar necessidade real de entusiasmo arquitetural.

A OrbeSoft aplica essa lógica em projetos de software sob medida: entendimento de mercado, prototipação, entrega funcional e evolução técnica são tratados como partes do mesmo sistema de decisão. A experiência em mais de 300 projetos na América Latina, nos Estados Unidos e na Europa reforça uma convicção prática: release rápida só é vantagem quando produto e operação conseguem absorver o aprendizado.

Em uma governança de oito semanas, uma squad sênior dedicada pode organizar esse ciclo com arquiteto, engenharia, UX e produto, sem funcionar como uma fábrica que apenas recebe pedidos. O objetivo é entregar incrementos reais, questionar escopo quando necessário e deixar artefatos que permitam ao cliente continuar evoluindo o produto com autonomia.