No cenário atual de desenvolvimento de sistemas, especialmente em ambientes de alta demanda, a realidade se impõe: nem sempre é possível atender a todas as solicitações do negócio sem alterar a base técnica. Em diversas situações, é necessário que o arquiteto exerça a maturidade de saber quando dizer “NÃO” para o negócio – mesmo diante de uma cultura fortemente inclinada ao “cliente tem sempre a razão”.
Hoje discutimos os desafios de equilibrar anseios contraditórios, a tensão entre requisitos funcionais e não funcionais, e como essa decisão pode ser determinante para a sustentabilidade e o desempenho dos sistemas.
Os anseios de negócio: contradições e desafios
As empresas, por natureza, buscam crescimento, expansão e resultados imediatos. Muitas vezes, a demanda é por soluções que operem de maneira “tradicional”, sem que seja necessário repensar processos ou alterar estruturas consolidadas. Essa visão, que preza por manter o status quo, entra em conflito com a realidade técnica de que atender a volumes massivos sem promover mudanças é, simplesmente, inviável.
Em muitas organizações, há uma pressão intensa para que cada nova demanda seja rapidamente absorvida, mantendo a expectativa de que o sistema seja capaz de suportar volumes crescentes sem que se precise alterar o fluxo ou os mecanismos internos. Esse ideal, contudo, entra em colisão com os limites técnicos, que exigem a aplicação de estratégias de gerenciamento de carga, otimização de processos e, em alguns casos, a adoção de mecanismos que podem modificar o comportamento tradicional do sistema.
Imagine uma empresa de seguros que deseja implementar, de forma imediata, um novo módulo para análise de riscos em tempo real. O negócio acredita que, se essa funcionalidade estiver disponível, os clientes terão uma experiência mais dinâmica e a conversão de vendas aumentará. No entanto, a equipe técnica, ao analisar os requisitos, percebe que o sistema atual não foi projetado para processar em tempo real esse volume de dados complexos, o que pode resultar em lentidão ou até falhas no processamento. Nesse caso, apesar da demanda do negócio, os arquitetos recomendam uma abordagem gradual – implementando primeiro uma versão assíncrona e monitorada – antes de migrar para o processamento em tempo real.
A Cultura do “cliente tem sempre a razão” no Brasil
No Brasil existe um hábito quase arraigado de dizer “sim” a todas as solicitações, independentemente da complexidade ou dos desafios envolvidos. Essa postura, muitas vezes, decorre de uma cultura de otimismo exagerado ou da necessidade de agradar o cliente. Entretanto, essa atitude pode levar a promessas que, na prática, não se concretizam de forma executável.
Os mecanismos de cobrança e as pressões internas contribuem para que essa cultura se perpetue, mesmo quando as condições técnicas apontam para a impossibilidade de uma implementação sem alterações significativas. Essa realidade cria um ambiente onde o diálogo entre os diferentes setores da empresa – especialmente entre os times de negócios e de tecnologia – torna-se fundamental para estabelecer expectativas realistas e construir soluções robustas.
Em uma startup de tecnologia, a liderança frequentemente solicita novas funcionalidades sem uma análise profunda da infraestrutura atual. Por exemplo, o time de negócios decidiu adicionar uma funcionalidade de chat em tempo real para suporte ao cliente durante picos de vendas, sem considerar os impactos no servidor. Os desenvolvedores, pressionados, implementaram o recurso rapidamente. Após alguns dias de uso, o sistema começa a apresentar lentidão e instabilidades, justamente porque a arquitetura não previa um volume tão alto de conexões simultâneas. Esse cenário força a equipe técnica a interromper a funcionalidade para realizar ajustes na infraestrutura, evidenciando que um “sim” precipitado pode comprometer a qualidade do serviço. Afinal, qual a experiência dos clientes durante a instabilidade?
A divergência entre requisitos funcionais e não funcionais
Uma das principais fontes de tensão em times técnicos é causada pela forma como os profissionais são cobrados:
De um lado, o desenvolvedor é avaliado com base na entrega dos requisitos funcionais – ou seja, a capacidade de implementar as funcionalidades solicitadas.
De outro, o arquiteto é responsável pelos requisitos não funcionais, como desempenho, escalabilidade, segurança e confiabilidade do sistema.
Essa divisão gera, muitas vezes, um cenário de conflito. O time de desenvolvimento foca na criação de funcionalidades que atendam às demandas do negócio, enquanto os arquitetos precisam garantir que essas soluções possam suportar um volume crescente de acessos e transações, sem comprometer a qualidade do sistema. Dizer “NÃO” para o negócio, neste contexto, significa recusar demandas que coloquem em risco a integridade dos requisitos não funcionais, mesmo que, em um primeiro momento, pareça uma recusa ao que é pedido.
Conciliar essas duas perspectivas exige um diálogo constante e transparente entre todas as áreas. A maturidade para decidir quando ceder e quando resistir a novas demandas não é apenas uma questão técnica, mas também de gestão e comunicação. É preciso construir pontes que possibilitem que ambos os lados compreendam os limites e as necessidades do outro, estabelecendo prioridades que garantam a sustentabilidade do sistema a longo prazo.
Considere um sistema de pagamentos onde o time de desenvolvimento implementou rapidamente um novo método de checkout para aumentar as conversões – atendendo ao requisito funcional de maneira exemplar. Entretanto, os arquitetos perceberam que o novo fluxo não estava preparado para suportar o volume de transações esperado durante eventos promocionais, afetando a latência e a segurança das operações. Assim, mesmo tendo uma solução funcional, é preciso “dizer NÃO” para a implementação imediata, optando por uma revisão arquitetural que incluísse, por exemplo, balanceamento de carga e mecanismos de cache, para que o sistema se tornasse sustentável sob alta demanda.
A maturidade na decisão: Quando dizer sim e quando dizer não
Decidir entre dizer “sim” ou “não” para o negócio não é uma questão de teimosia ou de negativismo; é uma prática que exige visão de longo prazo e uma compreensão profunda dos limites técnicos. A maturidade, nesse contexto, é fundamental para que a equipe técnica possa fazer análises criteriosas e oferecer alternativas que, embora possam diferir da solicitação inicial, atendam aos objetivos estratégicos sem comprometer a qualidade ou a escalabilidade do sistema.
Essa maturidade se manifesta na capacidade de apresentar dados, projeções e análises que demonstram claramente os riscos associados à implementação de uma demanda sem os ajustes necessários. Em muitos casos, a recusa ou a proposta de uma solução alternativa não é uma rejeição ao negócio, mas um passo estratégico para evitar problemas imediatos ou futuros – como falhas em momentos críticos, aumento de custos com retrabalho ou até mesmo a perda de credibilidade no mercado.
Em um projeto de modernização de um sistema legado, o time de negócios pressiona para que todas as funcionalidades antigas sejam migradas de uma só vez para uma nova plataforma, a fim de reduzir custos e acelerar o tempo de lançamento. O time de arquitetura, porém, identifica que uma migração em massa pode causar indisponibilidade e inconsistências críticas nos dados. Após realizar testes de carga e simulações, a equipe técnica propôem uma migração gradual, utilizando feature flags para ativar novas funcionalidades de forma controlada. Essa decisão, baseada em dados e análise, permitiu validar a estabilidade do sistema e, posteriormente, atender às demandas do negócio de maneira sustentável.
Exemplo Prático: O Cenário do E-commerce
Considere o caso de um e-commerce que enfrenta um volume crescente de acessos e transações. A equipe de negócios pode insistir em manter o fluxo tradicional de finalização de compra, no qual o pedido é convertido imediatamente em uma compra. Entretanto, a equipe técnica, responsável por garantir que o sistema suporte picos de acesso sem travamentos ou perdas de dados, como na Black Friday, pode identificar que esse modelo não é sustentável sem ajustes.
Nesse cenário, a abordagem técnica pode sugerir que, ao invés de converter o pedido em uma compra imediata, o sistema trate o clique do cliente como uma solicitação de compra – uma mudança que, embora contrarie a expectativa tradicional, permite o uso de mecanismos como processamento assíncrono e filas para gerenciar o volume sem sobrecarregar a infraestrutura. Aqui, dizer “NÃO” ao modelo tradicional não é um obstáculo, mas sim uma decisão necessária para assegurar que o sistema continue performando de forma confiável, mesmo em momentos de alta demanda.
Conclusão
Dizer “NÃO”, em certos momentos, é uma escolha estratégica que visa a longevidade e a robustez do sistema. A tensão entre os anseios imediatos do negócio e as necessidades estruturais da tecnologia é real e exige maturidade para que as decisões sejam tomadas com base em análises técnicas sólidas e em um diálogo transparente entre todos os envolvidos.
No Brasil, onde a cultura do “cliente tem sempre a razão” pode facilmente obscurecer os limites técnicos, é imprescindível que as equipes de arquitetura e desenvolvimento se unam para construir pontes de entendimento. Somente assim será possível conciliar os requisitos funcionais – que atendem às demandas do negócio – com os não funcionais – que garantem a sustentabilidade do sistema –, criando soluções que não apenas respondam ao presente, mas que também estejam preparadas para a longevidade.
Estamos cansados de construir, quebrar, reconstruir e falhar novamente pelos mesmos erros que já cometemos no passado.
0 comentários