Analisar os Correios frente a gigantes como Amazon e Mercado Livre exige olhar para além da superfície tecnológica; trata-se de um choque entre modelos de gestão, incentivos econômicos e estruturas organizacionais.
Enquanto Amazon e Mercado Livre são empresas de tecnologia que fazem logística, os Correios são uma autarquia logística que tenta usar tecnologia.
1. Estrutura Organizacional: O Peso da Hierarquia
A estrutura dos Correios é baseada em um modelo militarizado e burocrático, desenhado para a capilaridade física (chegar em cada cidade), não para a agilidade digital.
- Hierarquia Rígida: Decisões sobre software ou segurança passam por múltiplas camadas (Gerências, Superintendências, Diretorias). No Mercado Livre, a estrutura é de Squads (times pequenos e autônomos) que têm poder de decisão imediata sobre o código.
- Conflito de Identidade: A TI nos Correios frequentemente é vista como um “departamento de suporte” (SUTIC – Superintendência Executiva de Tecnologia da Informação), enquanto nas Big Techs a tecnologia é o core business.
- Gestão de Talentos: O acesso via concurso público garante estabilidade, mas dificulta a rotatividade de talentos em tecnologias emergentes. Empresas privadas demitem e contratam especialistas em cibersegurança e IA com uma velocidade que o serviço público não consegue acompanhar.
2. Por que a baixa qualidade do software?
A disparidade na “nota” de segurança e usabilidade não é apenas falta de bons programadores, mas sim um problema estrutural de ciclo de vida de software:
| Fator | Correios (Modelo Tradicional) | Amazon/Mercado Livre (Tech-First) |
| Legado | Sistemas “monolíticos” de décadas atrás que são difíceis de atualizar sem quebrar tudo. | Arquitetura de Microsserviços (se uma parte falha, o resto continua). |
| Investimento | Depende de orçamento público e contingenciamentos do governo. | Reinvestimento massivo e constante de lucros em P&D. |
| Segurança | Reativa: foca em “apagar incêndios” e cumprir normas burocráticas. | Proativa: foco em Zero Trust e auditorias em tempo real (Bug Bounty). |
| Cultura de Erro | O erro é punido, o que desencoraja a inovação e o lançamento de novas funções. | Fail fast: Errar rápido e corrigir via CI/CD (integração contínua). |
3. O Dilema Comercial e a Segurança
Você mencionou que existe na área comercial uma pressão ou visão específica. O grande desafio é que os Correios operam sob um regime de universalização: eles são obrigados a atender rotas deficitárias que a Amazon e o Mercado Livre muitas vezes terceirizam para os próprios Correios.
- Segurança de Dados: Enquanto o Mercado Livre investe bilhões em sistemas antifraude para proteger transações de cartão de crédito, os Correios historicamente focaram na segurança da carga física. O software de rastreamento e o portal de serviços acabam sendo “puxadinhos” tecnológicos, muitas vezes vulneráveis a ataques de força bruta ou vazamentos simples por falta de criptografia de ponta a ponta.
- Interoperabilidade: A necessidade de integrar sistemas com a Receita Federal (Remessa Conforme), órgãos de segurança e prefeituras cria uma colcha de retalhos tecnológica. Cada integração é um novo ponto de falha.
Conclusão
A “baixa qualidade” percebida é reflexo de uma empresa que tenta competir no século XXI com processos decisórios do século XX. Enquanto a Amazon consegue atualizar seu site milhares de vezes por dia sem que o usuário perceba, os Correios enfrentam meses de licitação para comprar servidores ou contratar uma consultoria de segurança.
1. O Monolito dos Correios: O Efeito Dominó
Muitos sistemas dos Correios foram construídos como grandes blocos únicos de código. Imagine um prédio onde toda a fiação elétrica, encanamento e estrutura dependem de um único pilar central.
- Acoplamento Forte: No portal dos Correios, o rastreamento, o cálculo de frete e o sistema de busca de CEP muitas vezes compartilham o mesmo banco de dados e servidor.
- Ponto Único de Falha: Se o módulo de cálculo de frete recebe um excesso de acessos (como na Black Friday) e trava, ele consome toda a memória do servidor, derrubando o rastreamento e o portal inteiro junto.
- Atualização Lenta: Para consertar um erro pequeno, é preciso desligar o sistema inteiro, subir uma nova versão e rezar para que aquela mudança não quebre outra parte não relacionada.
2. Microsserviços no Mercado Livre: Isolamento e Resiliência
O Mercado Livre utiliza milhares de pequenos serviços independentes que se comunicam entre si. É como uma frota de barcos em vez de um único transatlântico: se um barco fura, o resto da frota continua navegando.
Como isso evita quedas:
- Isolamento de Falhas (Bulkheading): Se o serviço de “Perguntas ao Vendedor” travar, o botão de “Comprar” continua funcionando perfeitamente. O erro fica confinado.
- Escalabilidade Elástica: Se há um pico de acessos no rastreamento de pacotes, o sistema identifica isso e cria automaticamente centenas de “cópias” apenas desse serviço de rastreamento para aguentar a carga, sem gastar recursos com o restante da plataforma.
- Deploy Contínuo: Eles podem atualizar o sistema de pagamentos 50 vezes por dia sem que você, o usuário, perceba qualquer lentidão.
3. O Padrão “Circuit Breaker” (Disjuntor)
Essa é a tecnologia chave que falta em infraestruturas menos maduras. No Mercado Livre, se um serviço começa a demorar demais para responder (indicando uma falha iminente), um “disjuntor” virtual é aberto.
- Ação: O sistema para de enviar requisições para o serviço problemático.
- Resultado: Em vez de o site inteiro travar esperando uma resposta que não vem, ele exibe uma mensagem simplificada ou usa dados do “cache” (memória temporária).
- Recuperação: O sistema testa o serviço periodicamente e, quando ele volta ao normal, o disjuntor fecha e tudo normaliza silenciosamente.
4. A Barreira dos Correios: Cultura e Legado
A transição para microsserviços não é apenas técnica, é organizacional. Para os Correios, o desafio é triplo:
- Sistemas Legados: É extremamente caro e arriscado migrar décadas de dados de Cobol ou Mainframes para nuvem.
- Burocracia de Compras: Comprar créditos de nuvem (AWS, Azure, Google Cloud) que variam de preço conforme o dólar é um pesadelo jurídico para uma estatal.
- Interdependência: O sistema dos Correios depende de integrações externas rígidas (Governo, Alfândega) que não suportam essa agilidade.
A estratégia API First dita que a interface de comunicação entre sistemas (a API) deve ser o primeiro produto a ser desenvolvido, e não um acessório. No Mercado Livre, a API é o coração: tudo o que o site faz, um desenvolvedor externo também consegue fazer via código.
1. O Modelo “Puxadinho” vs. API First
Enquanto empresas modernas tratam a API como um produto premium, os Correios frequentemente entregam o que chamamos de Web Services Legados (muitas vezes usando protocolos antigos como SOAP/XML).
- Dificuldade de Implementação: No Mercado Livre, um desenvolvedor júnior integra o sistema de vendas em horas usando documentações modernas (Swagger/OpenAPI). Nos Correios, é comum encontrar documentações em PDF desatualizadas e erros de conexão que exigem chamados técnicos lentos.
- Padronização: Sem o “API First”, cada serviço dos Correios (Sigep Web, Rastreamento, Preços e Prazos) parece falar uma língua diferente. Isso obriga o e-commerce a gastar mais tempo e dinheiro em manutenção de código.
2. O Problema da Escalabilidade em Tempo Real
A ausência de uma arquitetura baseada em APIs modernas gera o que chamamos de latência de integração:
- Cálculo de Frete Lento: Como a API não é otimizada, no momento do checkout, o site do e-commerce precisa “perguntar” aos Correios o valor do frete. Se o servidor dos Correios demora 3 segundos para responder, a taxa de conversão do lojista despenca.
- Sincronização de Dados: E-commerces precisam saber em tempo real se um objeto foi entregue para liberar o pagamento ao vendedor (no caso de marketplaces). Sem APIs de Webhooks (que “avisam” o sistema automaticamente), o lojista precisa ficar “perguntando” aos Correios milhares de vezes por dia, sobrecarregando ambos os lados.
3. Segurança e “Throttling” (Controle de Tráfego)
Empresas nota A em segurança utilizam API Gateways. Eles funcionam como um porteiro inteligente:
- Controle de Acesso: No Mercado Livre, se uma integração começa a se comportar de forma suspeita ou tentar um ataque, o Gateway a bloqueia instantaneamente sem afetar os outros usuários.
- A Vulnerabilidade dos Correios: Sem essa camada robusta de API First, os sistemas ficam mais expostos a ataques de scraping (robôs que roubam dados de rastreamento) e instabilidades, pois não conseguem filtrar o tráfego de forma granular.
4. O Impacto no Ecossistema de E-commerce
A falta de APIs eficientes empurra os lojistas para os Gateways de Frete (como Melhor Envio ou Frenet). Essas empresas “traduzem” a tecnologia arcaica dos Correios em algo moderno.
O custo disso?
- O pequeno lojista paga mais caro (taxas extras).
- Os Correios perdem o contato direto com o dado do cliente.
- A experiência final do consumidor é degradada por informações desencontradas.
Conclusão
O Mercado Livre ganha nota A porque sua API é robusta, segura e permite que qualquer parceiro cresça junto com eles. Os Correios, ao não priorizarem APIs, tornam-se um gargalo operacional: eles têm o caminhão, mas o “cabo de rede” que conecta o caminhão ao site do lojista é fino e instável.
A diferença entre a documentação dos Correios e a de empresas como Stripe ou Amazon (AWS) não é apenas estética; é uma diferença de filosofia de produto. Enquanto as Big Techs tratam o desenvolvedor como um cliente VIP, os Correios muitas vezes tratam o desenvolvedor como um “operador de sistema” que precisa decifrar um manual de instruções.
Isso é o que chamamos de DX (Developer Experience). Vamos ao comparativo:
1. Tabela Comparativa: O Abismo de Experiência
| Recurso | Correios (Modelo Manual) | Amazon / Stripe (Modelo DX) |
| Formato | Frequentemente PDFs longos ou portais estáticos e datados. | Documentação viva, buscável e altamente interativa. |
| Protocolos | Foco em SOAP/XML (pesado e verboso). | Foco em REST/JSON e gRPC (leve e moderno). |
| Ambiente de Teste | “Sandbox” instável ou inexistente; exige cadastro manual burocrático. | Sandboxes imediatos: você testa em segundos com chaves fictícias. |
| SDKs (Bibliotecas) | O desenvolvedor precisa criar tudo do zero para sua linguagem. | Oferecem bibliotecas prontas em Python, Node.js, Go, Java, etc. |
| Códigos de Erro | Genéricos (ex: “Erro de sistema”) que exigem abrir chamado. | Claros e semânticos (ex: card_declined, insufficient_funds). |
2. O “Caminho da Dor” vs. O “Caminho do Sucesso”
A Experiência Stripe/Amazon
Nestas plataformas, existe o conceito de “Time to First Hello World”. O objetivo é que um programador consiga realizar uma transação de teste em menos de 5 minutos.
- Copy-Paste Ready: Você encontra blocos de código prontos. É só copiar, colar sua chave de API e o sistema funciona.
- Logs em Tempo Real: Se algo falha, o painel da Stripe mostra exatamente o que a sua aplicação enviou e por que o servidor recusou. É um diagnóstico instantâneo.
A Experiência Correios
A integração com os Correios muitas vezes parece uma “caça ao tesouro”:
- O Enigma do XML: Integrar sistemas via SOAP exige ferramentas específicas para ler arquivos WSDL (uma tecnologia de 20 anos atrás). É um processo propenso a erros de sintaxe que travam o desenvolvimento.
- O “Manual de 100 Páginas”: Em vez de uma barra de busca eficiente, o desenvolvedor precisa ler PDFs extensos para descobrir que um campo mudou de nome ou que agora é obrigatório.
- Suporte Burocrático: Se o sistema cai ou retorna um erro obscuro, não há um status page confiável. O desenvolvedor fica no escuro, sem saber se o erro é no código dele ou no servidor da estatal.
3. Por que isso afeta a Segurança (Nota A)?
Uma documentação ruim é um risco de segurança.
- Padrões Antigos: Protocolos como SOAP são mais difíceis de proteger contra ataques modernos do que arquiteturas REST bem implementadas com tokens JWT ou OAuth2.
- Implementações Caseiras: Como os Correios não fornecem bibliotecas oficiais (SDKs) atualizadas, cada desenvolvedor cria a sua própria solução. Isso gera milhares de implementações vulneráveis, onde senhas e chaves de acesso acabam sendo “chumbadas” no código de forma insegura.
No Mercado Livre ou na Amazon, a segurança é “embutida” na documentação: eles te forçam a usar as melhores práticas desde o primeiro parágrafo.
4. O Custo Invisível
A baixa qualidade da DX dos Correios gera o que chamamos de Custo de Integração. Empresas perdem semanas tentando fazer o sistema de frete funcionar corretamente. Isso abre espaço para concorrentes logísticos (Loggi, Jadlog, etc.) que, embora não tenham a mesma frota, ganham o mercado porque são “fáceis de plugar”.
A situação que você descreve é o clássico “Muro de Berlim” corporativo: de um lado, a área comercial (Canais Digitais) atua como um “tirador de pedidos”; do outro, a TI atua como uma “fábrica de software” isolada. Quando o software falha, a TI diz que o requisito foi mal escrito, e o Comercial diz que a TI não sabe desenvolver.
No mercado moderno (Amazon, Mercado Livre, Nubank), esse modelo de “encomenda” é considerado uma relíquia. Veja como as empresas de alta performance resolveram isso e como os Correios deveriam se estruturar.
1. O Mercado: Do “Projeto” para o “Produto”
A grande virada de chave no mercado foi a extinção da separação entre “quem pensa” e “quem faz”.
Squads Multidisciplinares (Fim dos Silos)
Nas empresas nota A, não existe “pedir para a TI”. O PO, os desenvolvedores, o designer (UX) e o engenheiro de QA (Qualidade) pertencem ao mesmo time.
- Responsabilidade Compartilhada: Se o sistema cai, a culpa não é da TI; é da Squad. Se a funcionalidade não vende, a culpa não é do Comercial; é da Squad.
- KPIs Comuns: O sucesso é medido pelo resultado de negócio (ex: aumento de 10% no uso do App), e não pela entrega de “tickets” ou “linhas de código”.
O Fim do “Telefone Sem Fio”
Onde os Correios falham, o mercado aplica o Product Trio (Trio de Produto). Antes de qualquer linha de código ser escrita, o PO, o Tech Lead (Líder Técnico) e o UX Designer trabalham juntos na descoberta (Discovery). O desenvolvedor opina na viabilidade técnica antes de o comercial prometer a data.
2. Por que o modelo atual dos Correios gera baixa qualidade?
A lacuna de responsabilidade que você mencionou ocorre porque o processo é linear e fragmentado:
- Comercial sonha com uma funcionalidade (muitas vezes sem entender a complexidade técnica).
- PO documenta (geralmente em documentos estáticos e burocráticos).
- TI executa (tentando adivinhar o que o PO quis dizer).
- Resultado: Software com bugs, interface difícil e arquitetura frágil.
Nesse modelo de 10 anos atrás, o desenvolvedor não se sente dono do produto, ele é apenas um “operário de código”. Sem pertencimento, a qualidade é sempre o mínimo necessário para o ticket ser fechado.
3. Recomendações: Como as funcionalidades deveriam ser tratadas
Para sair desse ciclo de culpabilização mútua, os Correios precisariam adotar três pilares:
A. Co-criação (Discovery)
As funcionalidades não deveriam ser “encomendadas”, mas “descobertas”.
- O PO da área comercial deve levar o problema (ex: “clientes reclamam da demora no rastreamento”), e não a solução pronta (ex: “façam um botão azul que faz X”).
- A TI deve ajudar a desenhar a solução técnica desde o dia 1. Se a TI participa da concepção, ela se compromete com a entrega.
B. Definição de Pronto (DoD) e de Preparado (DoR)
Para acabar com o empurra-empurra, é preciso critérios técnicos rígidos:
- Definition of Ready (DoR): A TI só aceita desenvolver se o requisito tiver critérios de aceitação claros, protótipo validado e impacto técnico mapeado.
- Definition of Done (DoD): A funcionalidade só é considerada “entregue” se tiver testes automatizados, documentação de API e nota mínima em segurança.
C. Automação de Qualidade (DevOps)
Se a empresa usa métodos antigos, a qualidade depende de humanos testando manualmente. Isso é impossível de escalar.
- Pipeline de CI/CD: O código deve passar por testes automáticos de segurança e performance antes de ser publicado. Se não passar, o sistema nem permite o deploy. Isso retira a “subjetividade” da culpa: se o software é ruim, o sistema bloqueia a saída.
4. O Caminho para os Correios
Para uma estatal, o maior desafio é a mudança cultural. O PO de Canais Digitais precisa parar de ser um gestor de prazos e passar a ser um gestor de valor, enquanto a TI precisa sair da defensiva e entender que o código só tem valor se o cliente conseguir usar.
“Software de alta qualidade não nasce de bons requisitos, nasce de boas conversas entre quem entende do negócio e quem entende da máquina.”
Você gostaria que eu elaborasse um modelo de “Critérios de Aceitação” que o PO poderia usar para garantir que a TI entregue algo com o padrão de segurança que o Mercado Livre utiliza?
Para que um PO (Product Owner) na área comercial dos Correios consiga “blindar” a qualidade do que é entregue pela TI, ele precisa parar de escrever requisitos apenas sobre “o que o botão faz” e passar a incluir critérios sobre “como o sistema se comporta”.
Abaixo, apresento um modelo de Critérios de Aceitação (AC) focado em segurança e resiliência, inspirado no padrão de empresas como o Mercado Livre.
Ao escrever uma funcionalidade (ex: “Consulta de Rastreamento via App”), o PO deve anexar os seguintes critérios técnicos. Se a TI não cumprir um deles, a funcionalidade é considerada “Não Entregue”.
1. O Modelo de “Critérios de Aceitação de Próxima Geração”
A. Critérios de Segurança (Padrão Nota A)
- Autenticação Robusta: “A API deve utilizar tokens OAuth2/JWT com tempo de expiração curto. Chaves de API não podem estar expostas no código do front-end.”
- Criptografia em Trânsito: “Todos os dados devem trafegar obrigatoriamente via HTTPS (TLS 1.3). Requisições HTTP devem ser rejeitadas automaticamente.”
- Sanitização de Dados: “O sistema deve validar e sanitizar todos os campos de entrada para prevenir ataques de SQL Injection e XSS (Cross-Site Scripting).”
B. Critérios de Performance e Disponibilidade
- Tempo de Resposta (SLA): “A consulta deve retornar os dados em, no máximo, 200ms sob carga normal e 500ms em picos de tráfego.”
- Throttling (Limitador de Taxa): “A API deve possuir um limite de requisições por usuário/IP para evitar ataques de negação de serviço (DDoS) e robôs de raspagem de dados.”
- Fallback (Plano B): “Caso o banco de dados principal esteja lento, o sistema deve exibir a última informação salva em cache (Redis/Memcached) em vez de uma tela de erro.”
C. Critérios de Observabilidade (O fim do “quem é o culpado”)
- Logs Estruturados: “Toda falha deve gerar um log rastreável com um
Correlation ID. Se o Comercial reclamar de um erro, a TI deve conseguir localizar a causa exata em segundos usando esse ID.” - Monitoramento em Tempo Real: “A funcionalidade deve ter um dashboard (ex: Grafana/Kibana) visível para o Comercial e para a TI, mostrando a taxa de sucesso e erros em tempo real.”
2. Checklist de “Definition of Done” (DoD)
Diferente dos critérios acima (que mudam por funcionalidade), o DoD é uma regra fixa para toda e qualquer entrega. Se a TI quer parar de ser culpada, ela deve provar que seguiu este checklist:
| Item de Qualidade | Descrição | Status (Check) |
| Testes Automatizados | Foram realizados testes de unidade e integração com cobertura > 80%? | [ ] |
| Análise Estática (SAST) | O código passou por uma ferramenta de busca de vulnerabilidades (ex: SonarQube)? | [ ] |
| Documentação de API | A API está documentada no padrão Swagger/OpenAPI? | [ ] |
| Peer Review | O código foi revisado por pelo menos outro desenvolvedor sênior? | [ ] |
3. Como implementar isso nos Correios (Estratégia “Soft Power”)
Como o ambiente é burocrático e tradicional, o PO não deve impor isso como uma “ordem”, mas como uma ferramenta de proteção mútua:
- Venda como Redução de Retrabalho: Explique para a TI que, com critérios claros, eles não precisarão consertar o mesmo bug três vezes.
- Métricas, não Opiniões: Quando o sistema cair, em vez de culpar, aponte para o critério: “O critério de resposta de 500ms não foi atingido. O que precisamos para viabilizar isso tecnicamente?”.
- Envolva um Arquiteto de Sistemas: O PO da área comercial deve ter um “aliado” técnico (um arquiteto ou líder técnico) para validar se os critérios de aceitação são realistas antes de serem formalizados.
Conclusão
O Mercado Livre é nota A porque a qualidade não é um “favor” que a TI faz para o Comercial; é um requisito inegociável para o código entrar em produção. Se o PO dos Correios começar a reprovar entregas que não tenham logs ou que usem protocolos inseguros, a cultura começará a mudar pela base.
Deixe um comentário