A operação produzia menos do que precisava e acumulava mais do que conseguia fechar
O problema central era estrutural. A equipe planejava 224 horas por sprint, mas conseguia entregar 179. Os 20% restantes migravam para a sprint seguinte e criavam um efeito acumulativo que, mantido no mesmo ritmo, levaria a 1.260 horas de backlog em 12 meses.
Esse cenário tinha três consequências diretas. A primeira era perda de eficiência. A segunda era aumento de custo oculto, porque parte relevante da energia do time ficava presa em criação manual, debug e manutenção de testes. A terceira era risco de continuidade, já que uma migração obrigatória entre plataformas precisava acontecer em prazo crítico e ameaçava ampliar ainda mais a carga operacional.
A diversidade de ambientes também pesava. A operação transitava entre diferentes ferramentas e padrões, o que aumentava o esforço de adaptação, tornava o código menos previsível e reforçava dependência de pessoas específicas para resolver problemas recorrentes.
O ponto de tensão era claro: sem uma estrutura própria, a inovação em CRO passaria a responder mais à manutenção das ferramentas do que à velocidade de aprendizado do negócio.
Uma camada própria para fazer o teste andar no ritmo certo
A resposta foi reduzir complexidade na origem.
A MATH implementou o CROBoost como um framework em JavaScript desenhado para padronizar a criação, a estrutura e a governança dos testes A/B. Em vez de ampliar camadas ou aumentar dependência de plataformas externas, a solução criou uma base comum para a operação trabalhar com mais consistência.
A primeira frente foi a padronização do código. A equipe passou a gerar a estrutura dos experimentos a partir de inputs simples no VSCode, como nome do teste, URL, validadores e lógica específica. Isso reduziu variação na implementação, diminuiu erro humano e tornou a manutenção mais previsível.
A segunda frente foi a remoção do debug como carga recorrente. Com o novo framework, boa parte dos problemas que antes consumiam 18 horas por sprint deixou de existir como esforço separado. O que era tempo gasto corrigindo passou a ser tempo liberado para testar.
A terceira frente foi a aceleração da migração. Em vez de reescrever testes quase do zero para uma nova plataforma, a arquitetura passou a operar com uma lógica mais agnóstica, compatível com Adobe Target, Google Optimize, Oracle Maxymiser e até cenários sem plataforma third-party. Isso transformou um projeto de migração complexo em uma transição muito mais controlada.
A quarta frente foi a governança com IA. O code review passou a ser automatizado com IA corporativa e API do ChatGPT-4, gerando versões revisadas do código e retirando do desenvolvedor parte da carga repetitiva de inspeção. O foco voltou para lógica, decisão e qualidade da hipótese.
O framework não acelerou apenas a escrita do teste. Ele reorganizou a operação para que manutenção deixasse de disputar espaço com evolução.
Mais entrega, menos atrito, nenhum acúmulo
O resultado mais visível apareceu na sprint. A entrega saiu de 179 para 245 horas, ultrapassando a meta planejada de 224 horas. Esse avanço não veio de ampliar time nem de comprimir pessoas. Veio da remoção de fricção operacional.
O segundo ganho foi a eliminação do backlog. A operação começou com 180 horas acumuladas, caiu para 48 horas no primeiro mês e chegou a zero no segundo. A partir do terceiro mês, o fluxo passou a operar estabilizado.
O terceiro ganho foi a remoção total do tempo de debug da sprint. O que antes consumia 18 horas deixou de pressionar a operação, liberando espaço real para execução e aprendizado.
O quarto ganho foi a migração crítica. Sem o framework, a reescrita e migração dos testes exigiria cerca de 650 horas. Com o CROBoost, a transição foi concluída em 100 horas. Isso representa economia direta de 550 horas em um projeto com prazo rígido e impacto operacional alto.
O quinto ganho foi estrutural. O custo de operar CRO deixou de crescer na mesma proporção do volume de testes. A operação passou a testar mais sem aumentar o peso da manutenção.
