1. O Contexto: Alto Valor com Risco Oculto
O cenário era, na superfície, de simples execução, mas de Alto Valor de Negócio. A necessidade era clara: incluir uma coluna que exibisse a situação atual de um registro em diversas telas do nosso sistema.
O benefício era facilmente quantificável: estávamos recebendo de três a cinco demandas semanais dos usuários solicitando exatamente a verificação desse status. Resolver isso diretamente na interface prometia reduzir drasticamente a recorrência dessas solicitações, liberando tempo da equipe de suporte e melhorando a eficiência do usuário.
O ponto de partida parecia um “gol de placa”: a informação necessária era extraída de uma única consulta no banco de dados.
2. O Dilema: A Armadilha da Simplicidade da Demanda
A análise inicial revelou o sinal de risco. O problema não estava em obter os dados, mas em garantir a consistência da apresentação.
Apesar de todas as telas recorrerem à mesma consulta, o resultado era tratado de maneiras diferentes em diversos locais do código antes de ser exibido. O que parecia uma mudança em um único ponto se revelou rapidamente uma alteração distribuída.
A armadilha comum que se apresentava era o erro típico de iniciantes: acreditar na simplicidade da demanda. Essa crença poderia nos levar a dois caminhos com riscos distintos:
- Caminho A (Épico Único): Entregar um único card épico, consultando o dado isolado e englobando todas as telas. Isso resultaria em desordem, dificultando testes, ajustes finos e correção de erros.
- Caminho B (Entregáveis Menores): Quebrar a demanda em entregáveis menores, forçando o desenvolvedor a lidar com diversas tarefas correlatas ao mesmo tempo.
A pergunta-chave que guiou a decisão foi estratégica: A equipe gastaria mais esforço executando a mudança em si ou se organizando para garantir que a execução fosse coesa?.
3. Decisão e o Framework: Classificando a Complexidade pelo Risco
A metodologia de análise se fundamentou no modelo Valor vs. Complexidade. Este framework é crucial para padronizar os parâmetros de tomada de decisão, permitindo a alocação de recursos finitos de desenvolvimento baseada em raciocínio estratégico e quantificável.
Enquanto o Valor de Negócio era Alto, a necessidade de tratar o resultado da consulta em múltiplos locais do código, garantindo a apresentação idêntica, elevava drasticamente o fator Complexidade/Esforço. O risco de divergência de dados era o fator que transformava a iniciativa em algo que se aproximava do quadrante de Alto Valor, Alta Complexidade.
A Complexidade total, nesse contexto, precisava englobar não apenas o tempo de desenvolvimento, mas também o risco de falha na apresentação ou de introdução de inconsistências.
A Escolha Estratégica
A decisão foi pela quebra da demanda (Caminho B). Ao quebrar o épico em cards bem pequenos e separados, conseguimos gerenciar a complexidade em pedaços menores, transformando um esforço monumental em uma série de pequenas vitórias que, juntas, atingiriam o objetivo.
O critério prático de priorização para a ordem de execução foi tático: começar pela tela onde o usuário tinha o costume de procurar aquela informação primeiro, priorizando o valor entregue em detrimento de validar pela complexidade intrínseca.
4. Execução Detalhada e Contenção de Risco
A fase de execução foi estruturada com base na decisão estratégica de quebrar a demanda em entregáveis menores (Caminho B). Embora essa abordagem tenha sido escolhida para gerenciar a complexidade em partes controláveis, o risco principal aceito conscientemente foi uma demora maior na entrega do épico completo.
O Risco Crítico a Ser Evitado
O fator determinante para o planejamento de execução foi a necessidade de evitar o pior cenário possível: entregar o sistema com dados divergentes. Dada a natureza da alteração (apresentar o status de um registro em múltiplas telas, mas tratando o resultado de maneira diferente em vários pontos do código), havia um risco elevado de que o status fosse exibido como “X” em uma tela e “Y” em outra.
Se a equipe entregasse dados inconsistentes ou divergentes, isso não só anularia o benefício da iniciativa (que era reduzir as solicitações de verificação de status), mas também geraria novas demandas de suporte por parte dos usuários e aumentaria o retrabalho para a equipe de desenvolvimento.
O Plano de Contenção de Divergência
Para mitigar este risco inerente à alteração distribuída, onde muitas partes do código eram afetadas, foi adotado um plano rigoroso de contenção. Este plano visava essencialmente incorporar os benefícios de coesão do Caminho A (entrega única e consolidada) à execução quebrada do Caminho B.
O plano se baseou em duas estratégias centrais:
- Consolidação Total no Ambiente de Homologação: A equipe decidiu que não seriam realizadas entregas parciais diretamente para o usuário final. Em vez disso, todo o trabalho dos cards quebrados foi segurado integralmente no ambiente de homologação. Essa abordagem garantiu que a funcionalidade só seria disponibilizada quando estivesse completa e coesa.
- Teste Integrado Recorrente (Validação Cruzada): A estratégia central de mitigação foi a implementação de uma validação cruzada contínua. O objetivo tático era buscar ativamente as divergências entre as telas. O protocolo era claro: após o Card A ser validado, quando o Card B chegasse em homologação, a instrução era retornar e retestar o Card A em conjunto com o Card B. Isso garantia que a nova alteração não introduzisse uma inconsistências em relação às telas já modificadas.
Resultado do Processo Rigoroso
A aplicação desse processo rigoroso assegurou que o custo de corrigir qualquer inconsistência ou divergência fosse mantido internamente, dentro do ciclo de desenvolvimento. Ao proteger o usuário final e evitar a entrega incorreta, a equipe impediu que o trabalho gerasse novas demandas de suporte ou retrabalho.
Em essência, a estratégia de execução adotada foi quebrar para desenvolver, mas consolidar para entregar. Isso permitiu o controle eficiente do risco de divergência, que era o pior cenário possível, além de garantir que o Alto Valor da iniciativa fosse entregue de forma completa e confiável ao sistema. Essa abordagem se alinha ao princípio fundamental de que iniciativas de alto valor devem ser executadas de forma estruturada, priorizando a consistência sobre a velocidade aparente.
5. Conclusão com o Aprendizado Estratégico
A Análise da Complexidade é Economia
A lição fundamental dessa situação é que organizar a demanda no momento da análise, utilizando a lente da complexidade real versus o valor percebido, não deve ser encarada como um luxo ou um atraso, mas sim como uma economia crucial.
Um requisito bem desenhado e refinado reduz o retrabalho lá na frente. Se a equipe de desenvolvimento não tem tempo hoje, a falta de tratamento dos requisitos fará com que o tempo se torne ainda mais escasso no futuro, elevando o custo da mão de obra.
O framework Valor vs. Complexidade força a equipe a construir uma representação visual da verdade por trás de cada iniciativa proposta, permitindo que as iniciativas de alto valor sejam executadas de forma estruturada, priorizando a consistência sobre a velocidade aparente.
O Padrão na Gestão de Entregáveis
O padrão que se repete em casos de alterações distribuídas é a necessidade de procurar sempre quebrar entregáveis menores. Contudo, a lição crucial nesse case vai além da quebra: é preciso calcular se essas entregáveis menores devem ser entregues separadamente ou em conjunto.
Neste cenário de risco de divergência, a estratégia de quebrar para desenvolver e consolidar para entregar foi o equilíbrio ideal. Isso permitiu controlar o risco de divergência (o pior cenário possível) e garantiu que o Alto Valor da iniciativa fosse entregue de forma completa e confiável.
Analogia para Aplicação:
A aplicação do Modelo Valor vs. Complexidade neste caso é semelhante a um arquiteto lidando com a reforma de uma casa antiga com instalações elétricas complexas e interligadas. O Valor é modernizar a iluminação. A Complexidade é a fiação antiga distribuída. Tentar fazer tudo de uma vez (Caminho A) resultaria em um curto-circuito (divergência de dados). Ao quebrar o trabalho por cômodo e testar cada circuito em conjunto antes de ligar o disjuntor principal (Homologação), você garante que o sistema moderno funcione de forma integrada, transformando a complexidade em um resultado coeso e seguro.