Existe uma frase que a Visie já disse e que resume nosso pensamento sobre o assunto: um agente de IA eficiente é 10% prompt e 90% engenharia.

Ela incomoda porque contraria a promessa que o mercado vem vendendo. A ideia de que basta escrever uma boa instrução e a mágica acontece. Não acontece. E os números de 2026 mostram exatamente onde a mágica quebra.

O que o Gartner viu

O Gartner prevê que 40% dos projetos com agentes de IA sejam encerrados até 2027. O motivo principal não é o modelo ser ruim. É falta de experiência e foco em experimentação em vez de solução comprovada. As empresas montam piloto atrás de piloto e nenhum sai do laboratório.

O dado que sustenta isso é ainda mais duro: 85% dos projetos de IA falham por dados inadequados. Não por falta de inteligência do modelo. Por falta de qualidade e governança nos dados que alimentam o modelo.

Onde o agente encontra a realidade

Na demonstração, tudo funciona. O agente responde, resolve, encanta. O problema aparece quando ele encontra o mundo real da empresa.

Sistemas legados sem documentação. Dados espalhados em silos que não se falam. Permissões conflitantes, em que ninguém sabe ao certo quem pode acessar o quê. Custos invisíveis, provas de conceito que consomem muito antes de gerar retorno.

O agente é tão bom quanto o terreno em que ele pisa. E o terreno, na maioria das empresas, é acidentado.

Por que dados decidem tudo

Vale um dado que muda a conversa de orçamento. Segundo o Connectivity Benchmark Report da MuleSoft, que ouviu 1.050 CIOs, organizações que investem em governança de dados implantam IA quatro vezes mais rápido e geram três vezes mais valor.

Do outro lado, pesquisa da BigID com mais de 200 líderes mostra que 69% dos executivos reconhecem que a infraestrutura precária de dados trava o avanço da IA. E a Forrester aponta que só 22% das empresas têm capacidade madura de operacionalizar modelos.

Junte tudo e o retrato fica claro: o gargalo da IA não é o modelo, é a fundação.

O modelo que está vencendo

Há um padrão entre quem consegue tirar IA do piloto e colocar em produção. É híbrido. O time interno cuida de governança, produto e conhecimento do negócio. Um parceiro externo especializado cuida de execução técnica, integração e escala.

Faz sentido. Governança e contexto de negócio não se terceiriza, é a alma da empresa. Já engenharia de integração e operação de IA em escala é exatamente o tipo de trabalho em que experiência acumulada evita meses de erro caro.

O que perguntar antes de aprovar um projeto de IA

Se você é o decisor que vai assinar o investimento, as perguntas certas não são sobre o modelo. São sobre a fundação. Os dados que vão alimentar o agente estão organizados e acessíveis? Os sistemas que ele precisa acessar têm API? Existe governança de quem acessa o quê? Há um plano para sair do piloto e chegar em produção, ou é mais um experimento?

Se as respostas forem vagas, o projeto já nasce no grupo dos 40%.

Onde a Visie entra

A Visie não vende IA como mágica. Constrói a engenharia que faz a IA funcionar. 

Se a sua empresa está pensando em agentes de IA, o melhor investimento antes do modelo é olhar a fundação. É aí que a gente começa. Vamos conversar?

The post 40% dos projetos de agentes de IA vão fracassar até 2027: o que separa quem acerta appeared first on Visie.

Por cinco anos, a LGPD conviveu com uma percepção perigosa no mercado: a de que “não estava pegando”.

 Poucas multas, fiscalização reativa, um órgão sem estrutura para dar conta. Muita empresa leu isso como permissão para deixar a conformidade para depois.

Esse cálculo mudou, e mudou de forma estrutural.

O que aconteceu com a ANPD

Em outubro de 2025, o Congresso converteu em lei a MP 1.317/25 e a ANPD deixou de ser autarquia para virar oficialmente uma agência reguladora. Isso não é detalhe burocrático. Passou a ter autonomia funcional, técnica, decisória, administrativa e financeira, carreira própria com dezenas de especialistas em regulação e fiscalização, e estrutura equivalente às demais agências do país.

Traduzindo: o órgão que antes não tinha braço para fiscalizar passou a ter. E órgão com estrutura fiscaliza.

A fiscalização deixou de ser sorte

A mudança mais relevante para o dia a dia é como a ANPD passou a agir. Antes, o padrão era reativo, agir depois de uma denúncia ou de um vazamento que viralizasse. Agora é temática e setorial.

Em dezembro de 2025, a ANPD publicou o Mapa de Temas Prioritários para 2026 e 2027, com quatro eixos: direitos dos titulares, com foco em dados biométricos, de saúde e financeiros; proteção de crianças e adolescentes no ambiente digital; poder público; e inteligência artificial. Em novembro de 2025, lançou um Painel da Fiscalização com transparência pública dos processos em curso.

Ou seja, dá para saber quais setores estão na mira. E se o seu está na lista, contar com a sorte deixou de ser estratégia.

O tamanho da conta

As multas da LGPD podem chegar a 2% do faturamento da empresa no último exercício, com teto de R$ 50 milhões por infração. Para violação continuada, há multa diária com o mesmo teto. Quem ignora uma notificação da ANPD vê o valor acumular por dia.

E as infrações mais autuadas não são exóticas. São o básico mal feito: ausência de base legal para tratar dados, vazamento, falta de transparência com o titular, não atender aos direitos de quem pede acesso ou exclusão, e segurança da informação precária.

Por que isso é problema de arquitetura, não só de jurídico

Aqui está o ponto que o CIO precisa levar para a mesa. Conformidade com LGPD não se resolve só com política no papel e termo de consentimento no rodapé do site. Ela se resolve na arquitetura.

Saber onde cada dado pessoal está, quem acessa, por quanto tempo fica guardado, como é apagado quando o titular pede. Isso é engenharia de dados e desenho de sistema. Uma empresa com sistemas em silo, sem integração, sem controle de acesso claro, está exposta por construção, por mais bem escrito que seja o contrato.

É por isso que a pauta migrou do jurídico para a tecnologia. O risco mora no sistema.

Conformidade que vira vantagem

Tem um outro lado, e ele é estratégico. Num mercado onde a maioria adiou o dever de casa, estar em conformidade de verdade virou diferencial comercial. Cliente grande audita fornecedor. Contrato B2B pede garantia de tratamento de dados. Estar pronto abre porta, além de fechar risco.

Onde a Visie entra

Segurança e conformidade não são camada que se adiciona no fim. São decisão de arquitetura, tomada no começo. A Visie trabalha há vinte anos construindo sistemas em setores sensíveis, como de seguros e financeiro, onde tratar dado errado não é opção. Alper Seguros é um exemplo de aplicação em ambiente regulado e exigente.

Se a sua empresa está num setor prioritário da ANPD, ou se a conformidade hoje depende mais de sorte do que de arquitetura, vale olhar isso antes que a fiscalização olhe. Vamos conversar?

The post A ANPD virou agência reguladora: o que muda na fiscalização de dados em 2026 appeared first on Visie.

Todo diretor de TI conhece a cena. Uma informação que existe em três sistemas e não bate em nenhum. Um pedido que precisa ser digitado de novo porque o ERP não fala com o e-commerce. Um relatório que leva uma semana para ficar pronto porque alguém precisa cruzar planilha na mão.

O custo disso raramente aparece numa linha do orçamento, mas está em toda parte. Retrabalho, erro, decisão tomada com dado velho, time sênior gastando hora em tarefa de integração que deveria ser automática.

O que é arquitetura composable, sem jargão

A ideia central é simples. Em vez de um sistema gigante que faz tudo e no qual mexer numa parte arrisca quebrar outra, você monta o negócio a partir de peças independentes. Cada peça faz uma coisa bem, expõe uma API, e conversa com as outras por ali. Precisou trocar uma peça, troca sem derrubar o resto.

A sigla que virou referência é MACH: Microservices, API-first, Cloud-native, Headless. Microserviços para modularidade. API-first para que tudo seja acessível e reutilizável. Nuvem para escala. Headless para separar a experiência do usuário da lógica por trás.

Deixou de ser tendência e virou base

Vale marcar o momento. Composable não é mais aposta de early adopter. Pesquisa da MACH Alliance com 561 empresas prevê que 61% da stack de tecnologia empresarial será baseada em MACH em 2026, e 8 em cada 10 organizações têm visão positiva sobre o modelo.

A conversa mudou de “devemos adotar?” para “estamos de fato colhendo o resultado que a arquitetura promete?”. Isso importa porque muita empresa migrou a tecnologia sem migrar a organização, e ficou no meio do caminho.

O motivo que empurrou tudo: a IA precisa de sistemas que conversam

Tem um fator novo acelerando a adoção: a possibilidade de construção de agentes de IA. Agente de IA só funciona se os sistemas por baixo forem acessíveis. Um modelo pode gerar conteúdo, personalizar experiência e rodar experimento em escala, mas só se conseguir ler e escrever nos sistemas certos por API. Arquitetura monolítica costuma tornar isso bem mas difícil.

Ou seja, quem está pensando em aplicar IA de verdade nos próximos dois anos esbarra antes na questão de integração. A arquitetura composable destrava. É por isso que a pauta ganhou urgência mesmo em empresas que não estavam pensando em modernizar a stack.

Onde os projetos travam

Não é a tecnologia que costuma falhar. São as barreiras de organização. As mais comuns: alinhamento interno ruim entre áreas, falta de governança de conteúdo e de dados, complexidade de privacidade, e o que o mercado apelidou de “MACH-washing”, fornecedor que vende como composable o que é monolito com uma API na frente.

Traduzindo para o dia a dia do CIO: dá para comprar as peças certas e ainda assim não colher o resultado, se a governança e a orquestração não vierem junto. A arquitetura é meio caminho. O outro meio é como as áreas passam a trabalhar.

Orquestração é a palavra de 2026

Se a adoção já é dada, o diferencial passou a ser orquestração. Fazer as peças conversarem com regra clara, dado consistente, segurança e observabilidade. É trabalho de engenharia madura, não de conectar duas APIs e torcer.

Aqui a experiência conta muito. Saber quais sistemas legados vão resistir, onde os dados estão em silo, quais permissões conflitam. Isso não se aprende no primeiro projeto.

Onde a Visie entra

Orquestração de sistemas é o centro do que a Visie faz. A Vero é um exemplo concreto: um ecossistema digital integrado que atende 1,3 milhão de usuários, com sistemas que precisam conversar sem falha. Não é slide de arquitetura, é operação de pé, em escala.

Se a sua empresa está sentindo o custo de sistemas que não se falam, ou pensando em compor a stack para destravar automação e IA, esse é exatamente o problema que a gente resolve há vinte anos. Vamos conversar?

The post Quando os sistemas não conversam, o negócio paga a conta: por que 61% das empresas vão para arquitetura composable em 2026 appeared first on Visie.

Tem uma conta que quase nenhum diretor de marketing faz, e que muda a prioridade da semana quando aparece na tela.

Um site que fatura 100 mil por ano e demora um segundo a mais para carregar do que poderia está deixando cerca de 7 mil na mesa. Não em teoria. É a média medida em estudos de performance de e-commerce: cada segundo adicional de carregamento derruba a conversão em torno de 7%.

Agora coloque isso na escala de uma operação grande. O número deixa de ser detalhe técnico e vira linha de receita.

O que o Google realmente mede

Core Web Vitals são três métricas, e vale entender o que cada uma pega, porque elas falham por motivos diferentes.

LCP, Largest Contentful Paint. Mede quanto tempo o maior elemento visível leva para aparecer. A meta é abaixo de 2,5 segundos. Análises de milhares de sites de e-commerce apontam que a conversão ótima aparece com LCP abaixo de 1,8 segundo, ou seja, a meta oficial é o mínimo, não o ideal.

INP, Interaction to Next Paint. Mede a resposta do site à interação do usuário. É a métrica mais nova e a que mais pega gente de surpresa. Ela substituiu o antigo FID em março de 2024. A diferença importa: o FID media só a primeira interação da sessão. O INP observa todas e reporta a pior. Um site que parecia rápido no teste antigo pode falhar no novo, porque agora conta aquele clique que travou meio segundo no meio da jornada. A meta é abaixo de 200 milissegundos.

CLS, Cumulative Layout Shift. Mede estabilidade visual. É aquela experiência irritante de ir clicar num botão e a página pular porque uma imagem carregou atrasada. A meta é abaixo de 0,1.

O tamanho real do problema

Segundo o Chrome UX Report, 87% dos sites falham em pelo menos uma das três métricas essenciais. Não é um problema de nicho. É a regra, não a exceção.

E o mais comum é a empresa não saber em qual das três está falhando, porque o site “parece rápido” para quem o construiu, testando de um computador bom, numa rede boa, com o cache quente. O usuário real está no celular, numa rede instável, na primeira visita. É a experiência dele que o Google mede.

Por que isso é problema de marketing, não só de TI

Aqui está o nó. Performance de site cai numa terra de ninguém. O marketing acha que é assunto de tecnologia. A tecnologia trata como dívida técnica que entra na fila. E ninguém dono do número de conversão está olhando LCP toda semana.

Só que a conta de receita é do marketing. Quando a lentidão derruba a conversão, quem responde pela meta é o CMO, não o time de infraestrutura. Por isso Core Web Vitals precisa virar pauta compartilhada, com alguém do lado do negócio acompanhando, não só um gráfico esquecido no painel do desenvolvedor.

Por onde a correção costuma passar

Não existe bala de prata, mas os culpados se repetem. Imagens pesadas sem compressão nem formato moderno. JavaScript demais bloqueando a renderização. Fontes que travam o texto. Servidor lento na primeira resposta. Elementos sem dimensão reservada, que empurram o layout ao carregar.

Cada um desses tem correção conhecida. O que falta, quase sempre, é alguém tratar performance como projeto contínuo, com medição no ambiente real do usuário, e não como faxina pontual antes de uma campanha.

Onde a Visie entra

A Visie construiu o e-commerce da Aramis na VTEX com foco em performance justamente porque, no varejo, velocidade é conversão e conversão é receita. Não é sobre passar num teste do Google. É sobre a pessoa terminar a compra antes de desistir.

Se você suspeita que o seu site está deixando receita na mesa por lentidão, dá para medir isso com precisão, no ambiente real, e priorizar o que move o ponteiro. Vamos conversar?

The post Cada segundo a mais no seu site custa 7% de conversão: o guia de Core Web Vitals para 2026 appeared first on Visie.

Existe uma pergunta que muito diretor de marketing ainda não fez à própria equipe: quando um cliente em potencial digita a dúvida dele no ChatGPT, a nossa empresa aparece na resposta?

Para a maioria das marcas B2B, a resposta é não. E o problema não é falta de conteúdo. É que o conteúdo foi escrito para uma lógica que está deixando de ser a única que importa.

Durante vinte anos, ser encontrado significou uma coisa: aparecer na primeira página do Google. Todo o esforço de SEO girava em torno disso. Palavra-chave, backlink, autoridade de domínio. Esse jogo continua de pé, mas ele ganhou um segundo tabuleiro. As pessoas passaram a perguntar para a IA e a aceitar a resposta que ela dá, muitas vezes sem clicar em link nenhum.

O que muda quando a IA responde no seu lugar

No modelo antigo, o Google te mostrava dez links e você escolhia. No modelo generativo, a IA lê dezenas de fontes, sintetiza e devolve um parágrafo. Sua marca ou está dentro desse parágrafo ou não existe naquela conversa.

E aqui está o dado que deveria acender um alerta em qualquer área de marketing: uma pesquisa da Brandlight indica que a sobreposição entre os links que rankeiam no topo do Google e as fontes citadas pela IA caiu de 70% para menos de 20%. Em outras palavras, estar bem no Google já não garante estar bem na resposta da IA. São dois jogos, e boa parte das empresas só treinou para um.

GEO não substitui o SEO, ele se soma

Vale afastar um mal-entendido comum. GEO não é o fim do SEO. A base técnica continua valendo, e em boa medida se sobrepõe. A diferença está no destino do conteúdo. O SEO otimiza para o algoritmo de busca ranquear sua página. O GEO otimiza para o modelo de linguagem entender, confiar e citar o que você publicou.

Quem já tem um bom trabalho de SEO parte na frente. Falta ajustar a forma.

O que a IA procura antes de citar você

Modelos de linguagem têm preferências claras, e elas são bem observáveis:

1. Conteúdo estruturado. FAQs, listas de definição, guias passo a passo e estudos de caso são recuperados com mais facilidade do que um texto corrido sem hierarquia.
2. Respostas diretas e curtas. Blocos de 40 a 60 palavras que respondem a uma pergunta específica logo no começo da seção, antes de contextualizar. A IA extrai esses blocos quase prontos.
3. Frescor. Há um padrão de decaimento de citação observado: conteúdo sem sinais de atualização perde prioridade depois de cerca de duas semanas. Revisar e datar o material passou a ser trabalho recorrente, não uma tarefa de uma vez só.
4. Sinais de confiança externos. Uma marca que só fala de si mesma tem dificuldade de ser citada. Uma marca mencionada em fontes de terceiros, comparativos, comunidades, podcasts e cases ganha validação que o modelo reconhece.
5. Conteúdo original. Pesquisa própria, dado proprietário, um framework construído a partir da sua experiência. Se você publica algo que ninguém mais tem, a IA passa a ter motivo para escolher você em vez de uma dúzia de páginas iguais.

O lado técnico decide tudo

Boa parte da invisibilidade em IA acontece por barreiras invisíveis, vacilos técnicos que atrapalham que os crawlers encontrem e entendam seu conteúdo. O robots.txt bloqueando o crawler do modelo. O conteúdo importante renderizado só via JavaScript, que a IA não lê. A informação presa atrás de login. Um arquivo llms.txt inexistente, quando ele ajudaria o modelo a entender a estrutura do site.

São correções de engenharia, não de redação. E é exatamente aí que muita empresa trava, porque a agência de conteúdo não mexe no código e o time de tecnologia não sabe que isso virou pauta de marketing. O GEO vive nessa fronteira entre as duas áreas.

Como medir se está funcionando

Três indicadores dão o retrato:

1. Taxa de menção: percentual de respostas de IA que citam o nome da sua marca. 
2. Taxa de citação: percentual de respostas que trazem um link clicável para o seu domínio. 
3. Posição: quando citada, sua marca aparece na primeira menção ou perdida no fim.

Curtida não entra nessa conta. O que importa é aparecer na resposta que o decisor lê antes de escolher com quem falar.

Onde a Visie entra

GEO é um trabalho de fronteira, e é nessa fronteira que a Visie opera há duas décadas. Estrutura de conteúdo que a IA entende, renderização server-side que o crawler consegue ler, schema markup, arquitetura de site pensada para ser recuperável. É engenharia aplicada a um objetivo de marketing.

Se a sua marca sumiu das respostas de IA, o problema quase sempre está na estrutura, não no texto. Vamos olhar isso juntos?

The post Seu cliente perguntou ao ChatGPT e sua marca não apareceu: o que é GEO e por que o SEO tradicional já não basta appeared first on Visie.

A moda empurra para microsserviços. A conta nem sempre fecha.

Há alguns anos, dizer que a arquitetura da empresa é um monólito virou quase uma confissão. Microsserviços viraram sinônimo de moderno, escalável, preparado para o futuro. E, com isso, muita empresa partiu para fragmentar o sistema em dezenas de serviços independentes antes de ter o problema que os microsserviços resolvem.

O resultado costuma ser o oposto do prometido. Em vez de mais velocidade, mais complexidade. Em vez de times autônomos, times travados esperando uns aos outros. Em vez de economia, uma conta de infraestrutura e de operação que ninguém tinha colocado na ponta do lápis.

Marcio, o diretor de TI, vive essa pressão dos dois lados. De um lado, o time técnico querendo adotar a arquitetura que aparece em toda palestra. Do outro, a diretoria perguntando por que o sistema continua difícil de mudar depois de tanto investimento. A pergunta que resolve os dois lados não é qual arquitetura é mais avançada. É qual arquitetura a empresa consegue sustentar sem quebrar a operação nem estourar o custo.

O que cada arquitetura realmente é, sem jargão

Um monólito é um sistema construído e publicado como uma peça única. Todas as funções vivem no mesmo aplicativo, compartilham o mesmo banco e sobem juntas a cada nova versão. Isso não significa desorganização. Um bom monólito é modular por dentro, com fronteiras claras entre as partes. Ele só não separa essas partes em processos que rodam de forma independente.

Microsserviços quebram esse aplicativo único em vários serviços menores, cada um responsável por um pedaço do negócio, cada um com seu próprio ciclo de vida. O serviço de pagamento pode ser atualizado sem tocar no serviço de catálogo. Cada equipe cuida do seu serviço, publica quando quiser e escala só a parte que precisa de mais capacidade.

A diferença central está nesse ponto: no monólito, tudo evolui junto. Nos microsserviços, cada parte evolui por conta própria. Essa autonomia é a grande vantagem e, ao mesmo tempo, a origem de toda a complexidade que vem junto.

Onde o monólito ainda ganha

Para a maioria das empresas médias, o monólito continua sendo a escolha mais inteligente, e não por falta de ambição.

Ele é mais simples de desenvolver, porque tudo está num lugar só. É mais barato de operar, porque exige menos infraestrutura e menos ferramentas de coordenação. É mais fácil de depurar, porque quando algo quebra, o problema está dentro de um sistema, não espalhado por uma rede de serviços que se chamam entre si. E é mais rápido de entregar no início, o que importa muito quando o produto ainda está encontrando seu formato.

Enquanto o time cabe numa ou duas equipes que conseguem se coordenar sem atrito, o monólito bem estruturado entrega quase todos os benefícios que se atribuem aos microsserviços, sem a conta de complexidade que vem com eles.

Quando microsserviços passam a valer a pena

Existe um momento em que o monólito começa a doer, e é um momento concreto, não teórico.

Ele chega quando o produto cresceu tanto que times diferentes precisam mexer em partes diferentes ao mesmo tempo, e passam a se atrapalhar. Quando cada nova versão fica arriscada porque uma mudança pequena num canto pode derrubar algo do outro lado. Quando uma parte do sistema precisa de muito mais capacidade que o resto, mas você é obrigado a escalar tudo junto para dar conta só dela.

Nesse ponto, separar o sistema em serviços independentes deixa de ser moda e vira solução real. Mas há um pré-requisito que quase ninguém menciona: microsserviços exigem maturidade de operação. Sem monitoramento sério, automação de deploy e um time que sabe lidar com um sistema distribuído, a empresa troca um sistema difícil de mudar por uma rede de sistemas difícil de operar.

O custo escondido de escolher errado

Cada erro de escolha tem um preço, e ele aparece em lugares diferentes.

Escolher microsserviços cedo demais faz o custo aparecer na operação. Mais infraestrutura, mais ferramentas, mais tempo gasto entendendo por que uma tarefa que passa por cinco serviços falhou em algum ponto que ninguém consegue localizar de imediato. O time que deveria estar construindo funcionalidade passa a gastar energia mantendo a máquina de pé.

Segurar o monólito tempo demais faz o custo aparecer na velocidade. As partes vão se enroscando umas nas outras até que qualquer mudança vira um projeto, cada entrega assusta e o sistema, que um dia foi rápido de evoluir, passa a andar devagar. Nenhum dos dois custos aparece numa linha de orçamento com nome claro. Os dois aparecem no ritmo do time e na conta do mês.

Como decidir na sua empresa

A decisão fica mais simples quando parte de perguntas concretas sobre a própria operação, não de uma preferência de arquitetura.

Quantos times mexem no sistema hoje, e eles se atrapalham entre si? Com que frequência a empresa precisa publicar mudanças, e cada publicação dá medo? As fronteiras do negócio estão claras o bastante para dizer onde um serviço termina e outro começa? A empresa já tem monitoramento, automação de deploy e gente com prática em operar um sistema distribuído?

Quanto mais respostas apontam para times numerosos, entregas frequentes, fronteiras nítidas e operação madura, mais os microsserviços fazem sentido. Quanto mais apontam para um time enxuto, entregas ocasionais e operação ainda em construção, mais o monólito bem feito é a escolha certa. E existe um meio-termo que resolve muita empresa: um monólito modular, organizado por dentro de forma que, no dia em que uma parte precisar virar serviço próprio, ela saia com pouco atrito.

Onde a Visie entra

A Visie constrói software sob medida há quase 20 anos, e isso significa ter construído os dois caminhos. Monólitos que sustentam operações inteiras com estabilidade, e arquiteturas distribuídas onde a escala e a quantidade de times realmente pediam essa separação.

No ecossistema digital da Vero, com 1,3 milhão de usuários, a decisão de arquitetura acompanhou o tamanho real da operação, e não uma preferência de moda. É essa leitura que muda o jogo: entender em que estágio o produto está antes de escolher como ele deve ser construído.

Se a sua empresa está nessa dúvida, ou desconfia que escolheu o caminho errado lá atrás, o diagnóstico começa por olhar a operação como ela é hoje, e não pelo nome da arquitetura.

Vamos conversar?

The post Monólito ou microsserviços: como escolher a arquitetura certa (e quando cada uma custa mais) appeared first on Visie.

O orçamento que o CFO aprova é só metade da conta

Todo projeto de integração de sistemas chega para aprovação com um número visível: o valor do investimento. É esse número que o CFO olha primeiro, e é natural que olhe com desconfiança. Faz parte do trabalho dele questionar gasto.

O que raramente chega junto é o outro lado da conta: quanto custa não fazer o projeto. Esse custo existe, opera todos os dias, e não aparece em nenhuma linha do orçamento porque está disperso no tempo das pessoas, não num contrato.

Marcio, o diretor de TI, sente esse custo antes de conseguir nomeá-lo. Ele sabe que o time do financeiro fecha o mês exportando planilha de um sistema para conferir com outro. Sabe que o atendimento perde minutos preciosos abrindo três telas para responder uma pergunta que deveria estar numa tela só. O que falta é transformar essa sensação em número, porque é número que convence quem aprova orçamento.

A fórmula que transforma retrabalho invisível em custo visível

O cálculo não precisa ser sofisticado para ser convincente. Ele parte de três variáveis:

Horas perdidas por semana num processo manual de conciliação, exportação ou redigitação entre sistemas. Salário-hora médio de quem realiza esse trabalho, considerando salário e encargos. Frequência com que esse processo se repete no mês.

Um exemplo: um analista pleno com salário entre R$ 6.000 e R$ 9.000 por mês custa, com encargos, algo entre R$ 45 e R$ 65 por hora de trabalho. Se esse analista dedica entre 8 e 12 horas por semana a reconciliar dados entre dois ou três sistemas que não conversam, o custo direto desse retrabalho fica entre R$ 1.500 e R$ 3.000 por mês, só para uma pessoa. Em times onde duas ou três pessoas fazem esse tipo de tarefa, e é comum que façam, o número sobe para uma faixa entre R$ 4.000 e R$ 9.000 mensais, algo entre R$ 48 mil e R$ 108 mil por ano, apenas em horas de trabalho gasto movendo dado de um lugar para outro.

Esse valor ainda não inclui o custo do erro. Um dado digitado errado numa conciliação manual não avisa que está errado. Ele só aparece quando o relatório não bate, quando o cliente reclama de uma cobrança inconsistente, ou quando uma decisão é tomada em cima de um número que já estava desatualizado no momento em que alguém olhou para ele. Esse custo é mais difícil de precificar, mas costuma pesar mais do que o custo de tempo.

Por que o instinto do CFO faz sentido, e por que a conta muda a resposta

Faz sentido o CFO olhar para um squad dedicado de integração, num investimento que costuma girar entre R$ 60 mil e R$ 120 mil por mês, e comparar com o orçamento de TI que já existe. É um número concreto, com contrato e prazo.

O que muda a decisão é colocar os dois lados da mesma régua. Um projeto de integração que resolve o retrabalho de um time de três pessoas, no exemplo acima, se paga no próprio custo evitado de retrabalho em um intervalo que costuma variar entre seis meses e um ano, dependendo do escopo. A partir daí, o que era despesa de projeto passa a ser eliminação de um custo recorrente que a empresa já pagava, só que sem contrato e sem visibilidade.

A pergunta certa para levar ao CFO não é “quanto custa integrar”. É “quanto estamos pagando, todo mês, para não integrar”.

Como montar essa conta para a sua empresa

O exercício funciona em qualquer operação, com os números da própria casa.

Primeiro, mapear os processos onde dado atravessa sistemas na mão de alguém. Planilha exportada, número redigitado, conferência manual de fechamento.

Depois, medir o tempo real gasto nesses processos, em horas por semana, com quem faz o trabalho no dia a dia. A estimativa costuma ser mais alta do que a percepção inicial, porque esse tempo se acumula em pequenos blocos ao longo do mês.

Em seguida, aplicar o salário-hora de quem executa a tarefa, e multiplicar pela frequência mensal. O resultado é o custo direto do retrabalho.

Por fim, somar uma estimativa conservadora do custo de erro: quantas vezes por trimestre um número errado gerou retrabalho adicional, atraso de decisão ou desconfiança num relatório.

O total, comparado ao investimento do projeto de integração amortizado pelo tempo de uso esperado, costuma revelar uma conta bem diferente da que aparece só no orçamento de TI.

Onde a Visie entra

A Visie conhece os dois lados dessa conta porque constrói os dois lados. Sabe o custo de desenvolver a integração e sabe, pelo diagnóstico que faz com clientes, o custo de operar sem ela.

No Visie Flow, com a Whirlpool, parte do valor entregue foi eliminar exatamente esse tipo de retrabalho manual entre sistemas de atendimento técnico. No ecossistema da Vero, com 1,3 milhão de usuários, a integração entre sistemas evita que times inteiros dependam de conciliação manual para saber se os dados batem.

Esse diagnóstico, de mapear onde o retrabalho vive e quanto ele custa hoje, é algo que a Visie faz antes de propor qualquer projeto. Se a sua empresa nunca fez essa conta, vale começar por aí.

Vamos conversar?

The post ROI de integração de sistemas: como calcular o custo de manter tudo desconectado appeared first on Visie.

Você não tem um problema de sistema. Tem cinco sistemas que não se falam.

A cena se repete em quase toda média e grande empresa. O time comercial registra o pedido no CRM. O faturamento roda no ERP. O e-commerce vive numa plataforma à parte. O atendimento usa outra ferramenta. E, em algum lugar, há um sistema próprio que alguém construiu há oito anos para resolver uma dor específica e que ninguém tem coragem de desligar.

Cada um desses sistemas resolveu bem um problema no seu tempo. O incômodo de hoje não nasce de nenhum deles isoladamente. Nasce do espaço entre eles, do dado que precisa sair de um e chegar a outro e que, na falta de uma ponte, atravessa esse caminho na mão de alguém. Uma exportação de planilha aqui, uma digitação repetida ali, uma conferência manual no fim do mês para descobrir por que dois relatórios não batem.

Marcio, o diretor de TI, conhece essa rotina de cor. Ele sabe que o time perde horas movendo informação de um lugar para outro. Sabe que cada transferência manual é uma chance de erro. E sabe que, quando o board pede um número consolidado, a resposta demora porque ninguém tem certeza de qual sistema diz a verdade.

O custo invisível de operar em silos

O problema dos sistemas desconectados raramente aparece numa linha de orçamento. Ele se esconde no tempo das pessoas e na qualidade dos dados.

Um exemplo concreto que vemos com frequência: um provedor de telecom com cerca de 200 mil assinantes pode operar com sete sistemas diferentes que não conversam entre si. Cadastro do cliente num lugar, cobrança em outro, rede e provisionamento em um terceiro, atendimento num quarto. Quando um cliente liga para resolver uma cobrança, o atendente precisa abrir três telas para entender o que aconteceu, porque nenhuma delas tem a história completa. Multiplique isso por milhares de chamados por mês e o custo aparece, ainda que ninguém o tenha colocado numa planilha.

Esse é o tipo de dor que cresce em silêncio. Cada sistema novo que entra parece resolver um ponto, mas adiciona mais uma ilha ao arquipélago. Em 2026, o freio de produtividade nas empresas médias raramente é a falta de software. É o excesso de software que não troca dado.

A solução que parece óbvia, e por que ela costuma ser a errada

Diante de tudo isso, a primeira reação de muitos times é radical: vamos trocar tudo por um sistema único que faça tudo. É uma ideia compreensível, e quase sempre uma armadilha.

Substituir todos os sistemas de uma vez significa parar a operação durante a migração, treinar o time inteiro de novo, reescrever integrações que já funcionavam e apostar que o novo sistema único vai realmente cobrir todas as necessidades que cinco sistemas especializados cobriam. O projeto incha, o prazo escorrega e o risco se concentra num único ponto de falha. Muitas empresas que tentaram esse caminho descobriram, no meio da migração, que o problema nunca tinha sido a qualidade dos sistemas. Era a ausência de comunicação entre eles.

Vale trocar a pergunta. Em vez de “qual sistema novo eu compro”, a que move o problema é “como faço os sistemas que já tenho conversarem de forma confiável”.

Como integrar sem refazer do zero

A alternativa madura é tratar a integração como uma camada própria, construída sobre o que já existe. Em vez de demolir, você cria as pontes que faltavam. Esse trabalho costuma seguir alguns passos.

Primeiro, mapear o fluxo do dado. Onde cada informação nasce, quem a consome e por quais caminhos ela passa hoje. Esse mapa quase sempre revela transferências manuais que ninguém tinha registrado como processo, mas que sustentam a operação no improviso.

Depois, expor os sistemas legados. Sistemas antigos nem sempre nasceram pensando em troca de dados, mas a maioria pode ser exposta por APIs, conectores ou rotinas de integração que dão a eles uma porta de entrada e saída padronizada, sem mexer no núcleo que já funciona.

Em seguida, orquestrar a troca num ponto central. Em vez de cada sistema falar diretamente com todos os outros, num emaranhado que ninguém consegue manter, a comunicação passa por uma camada de orquestração que controla o que vai para onde, em que formato e com qual frequência. É o que transforma um arquipélago em algo que se comporta como um sistema só.

Por fim, garantir confiabilidade. Integração de verdade não é exportar arquivo de madrugada e torcer. Envolve tratamento de erro, reprocessamento, registro do que passou e visibilidade para saber quando algo falhou antes que o cliente perceba.

Nada disso exige desligar o que funciona. Exige a engenharia que conecta as peças.

Onde a Visie entra

Fazer sistemas diferentes concordarem sobre o mesmo dado, ao mesmo tempo, sem intervenção manual, é o centro do que a Visie constrói há quase 20 anos.

No Visie Flow, com a Whirlpool, o desafio foi orquestrar atendimento técnico em escala, fazendo sistemas distintos operarem como um só fluxo. Na Vero, foi sustentar um ecossistema digital com 1,3 milhão de usuários, onde dezenas de pontos precisavam servir a mesma informação de forma consistente. Em ambos, a parte difícil nunca foi um sistema específico. Foi a integração entre eles.

A Visie não chega propondo trocar o que você já tem. Chega entendendo o ambiente atual, mapeando onde os dados se perdem e construindo as pontes que faltam, no ritmo que a operação suporta.

Esse é um diagnóstico que a gente faz com frequência, e ele costuma começar pela mesma frase: “nossos sistemas simplesmente não conversam”. Se essa frase soa familiar, vale uma conversa.

Vamos conversar?

The post Integração de sistemas legados: como fazer seus sistemas conversarem sem refazer tudo do zero appeared first on Visie.

Existe uma mudança brutal acontecendo no desenvolvimento de software.

Enquanto algumas empresas ainda seguem o mesmo modelo de sempre, com prazos longos, alto custo e entregas demoradas, outras já estão operando em uma lógica completamente diferente: mais rápidas, mais eficientes e, principalmente, mais inteligentes.

Obviamente isso está acontecendo por conta do uso da Inteligência Artificial, mas não da forma superficial que você vê por aí.

O problema é a pecinha de trás…

Se você é líder de negócio ou está envolvido em transformação digital, talvez já tenha passado por situações como:

• Projetos que demoram meses para sair do papel
• Custos que aumentam ao longo do desenvolvimento
• Dificuldade de adaptar o software conforme o negócio evolui
• Dependência de times grandes para entregar coisas relativamente simples

Esses problemas não surgiram agora. Eles sempre fizeram parte do desenvolvimento de software, porém eles não precisam mais existir nesse nível.

A IA reduziu drasticamente o custo de produzir código, o que normalmente era a parte mais demorada do processo. Hoje, gerar código deixou de ser o gargalo, e isso muda completamente o jogo!

O que a IA realmente mudou?

Existe muito ruído no mercado. De um lado, promessas de que qualquer pessoa pode criar um software milionário em poucos dias. Do outro, o medo de que programadores deixarão de existir.

Nenhum dos dois extremos representa a realidade!

A IA não substituiu o desenvolvimento de software, ela transformou o papel de quem desenvolve. Agora, o valor está em entender o problema, tomar decisões corretas e garantir que a solução funcione no mundo real.

E aqui está o ponto mais importante para você, como decisor:

A qualidade do resultado continua dependendo de quem está por trás da ferramenta.

O surgimento do “Super Dev”

Quando a IA é utilizada da forma correta, desenvolvedores experientes deixam de ser limitados pela execução e passam a operar em um nível muito mais estratégico.

Eles se tornam o que chamamos de “Super Devs”.

Na prática, isso significa:

• Entregas MUITO mais rápidas
• Maior capacidade de testar e validar ideias
• Flexibilidade para mudanças de escopo
• Redução significativa de retrabalho

Não estamos falando de pequenas melhorias. Em muitos casos, a produtividade pode aumentar de 10 a 20 vezes, ou mais, dependendo do tipo de projeto.

Parece até promessa política, mas é a dura realidade, e se você não abraçar essa realidade ela vai acabar te engolindo!

Para o seu negócio, isso significa algo simples:

Mais velocidade para inovar e menor tempo para gerar resultado.

Mas tem um detalhe que os gurus da IA não estão te contando

A IA não transforma qualquer fornecedor em um time de Super Devs.

Ela não resolve problemas de arquitetura, não garante segurança e não toma boas decisões sozinha.

Na verdade, quando mal utilizada, ela pode amplificar erros.

Já existem casos REAIS de:

• Sistemas que quebraram em produção por falta de validação
• Problemas de segurança causados por código mal gerado
• Aplicações que não escalam quando começam a crescer
• Perda de dados por uso inadequado das ferramentas

Ou seja: a IA acelera. Mas ela não corrige a falta de experiência!

E eu aposto que você não quer ver isso acontecendo na sua operação…

“Mas eles me disseram que usam IA”

Com a popularização da IA, surge um novo desafio para as empresas: Como saber se um fornecedor realmente sabe usar essa tecnologia?

Hoje, você encontra dois perfis comuns no mercado:

De um lado, empresas com pouca experiência em projetos corporativos, que utilizam IA de forma superficial e entregam soluções frágeis.

Do outro, empresas com experiência técnica sólida, mas que ainda não incorporaram IA de forma profunda e continuam operando com baixa eficiência.

Nenhum dos dois cenários é ideal.

O fornecedor que realmente gera valor hoje é aquele que consegue equilibrar os dois pontos: experiência em software de missão crítica + domínio prático do uso de IA.

O que muda na prática para o seu negócio

Quando esse equilíbrio existe, o impacto é direto e você passa a ter:

• Ciclos de desenvolvimento mais curtos
• Maior previsibilidade de entrega
• Capacidade de testar ideias rapidamente
• Software preparado para escalar
• Menor dependência de grandes equipes

E o mais importante:

• mais agilidade para responder às mudanças do mercado.

Porque no final, o problema nunca foi só tecnologia. Sempre foi tempo.

A premissa é simples

IA, por si só, não resolve nada.

Mas nas mãos certas, com método, experiência e estrutura, ela transforma completamente a forma como software é construído.

Ela não elimina a necessidade de bons profissionais, ela potencializa eles!

E é exatamente isso que cria uma vantagem competitiva real.

Como a Visie enxerga esse cenário

Na Visie, nós não tratamos IA como uma tendência.

Tratamos como uma camada fundamental do processo de desenvolvimento.

Isso significa que não usamos IA apenas para acelerar tarefas isoladas, nós estruturamos todo o fluxo de trabalho para aproveitar o máximo da tecnologia sem abrir mão de qualidade.

Na prática, isso envolve:

• Padrões sólidos de arquitetura
• Uso estratégico de IA como parceiro de desenvolvimento
• Validação rigorosa de código
• Estrutura preparada para evolução e escala

O objetivo é simples: transformar nossos desenvolvedores em Super Devs, e entregar isso como valor para o cliente.

Se você quer mais eficiência, precisa olhar para isso agora

A diferença entre empresas que vão evoluir mais rápido e as que vão ficar para trás não está apenas na decisão de usar IA, está em como essa IA é utilizada.

E, principalmente, em quem está utilizando.

Se você está avaliando fornecedores ou buscando acelerar suas iniciativas digitais, esse é um ponto que não pode ser ignorado.

Próximo passo

Se quiser entender melhor como aplicamos isso na prática e como isso pode impactar diretamente seus projetos, vale a pena conhecer mais sobre a Visie.

Acesse: https://visie.com.br

E se quiser ver essa discussão acontecendo de forma mais aprofundada, com exemplos reais e sem filtro, assista ao episódio completo do podcast que deu origem a esse conteúdo: Como a IA está redefinindo o desenvolvimento de software

Não estou aqui para dizer que a inteligência artificial é inútil ou que é hype. Ela é, de fato, uma das tecnologias mais transformadoras que já apareceram. Mas tem muita gente usando ela errado, esperando coisas que ela não é capaz de entregar, e pagando um preço caro por isso.

Às vezes literalmente com a vida.

A IA é uma máquina de sortear palavras

Antes de falar sobre limitações, precisamos entender o que é uma LLM, o modelo de linguagem que está por trás do ChatGPT, Gemini, Claude e todos os outros que você usa.

Ela não pensa. Ela sorteia.

Quando você faz uma pergunta, o modelo sorteia a próxima palavra. Depois a próxima. Depois a próxima. Ele usa um mecanismo estatístico sofisticado para decidir qual palavra tem maior probabilidade de ser a “certa” dado tudo que já foi escrito antes. O que ele tem de especial é uma forma muito eficiente de classificar quão bom ficou o texto resultado, comparando com os bilhões de textos usados no treinamento.

O que isso significa na prática? A IA é boa em produzir texto que parece uma boa resposta, não necessariamente texto que é uma boa resposta.

Na maior parte dos casos, a diferença é pequena. Uma resposta que parece boa geralmente é boa. Mas em situações onde não existe uma resposta consolidada nos dados de treinamento, ela vai sortear palavras que parecem certas, e falar com a mesma convicção de sempre.

Ela não sabe que está errando. Ela nunca sabe.

O estagiário que nunca duvida de si mesmo

Gosto de pensar na IA como um estagiário bem-intencionado que erra bastante.

Isso é útil porque um estagiário te ajuda a filtrar links, fazer resumos, rascunhar textos, organizar informação. Você usa, mas você revisa. Você sabe que ele pode errar.

O problema é que a IA é um estagiário convincente. Ela não gagueja quando está incerta. Ela não diz “olha, não tenho certeza sobre isso”. Ela apresenta a resposta errada com a mesma fluência e segurança da resposta certa.

E aí as pessoas param de revisar.

Já vi isso acontecer em reuniões, em apresentações, em briefings que chegam até nós. O material foi feito pela IA. A pessoa entregou. Você faz a segunda pergunta e ela não sabe responder, porque ela nunca leu o que entregou.

Isso não é usar a IA como ferramenta. Isso é delegar a responsabilidade para uma ferramenta que não tem responsabilidade nenhuma.

Para avaliar uma resposta da IA, você precisa saber a resposta

Aqui está um paradoxo que pouca gente percebe: para saber se a IA errou, você precisa ter conhecimento suficiente para identificar o erro.

Se você não entende o assunto, qualquer resposta parece aceitável.

Isso significa que a IA é mais útil exatamente para quem já sabe do que está fazendo. Para quem não sabe, ela pode ser perigosa, não porque vai dar uma resposta obviamente errada, mas porque vai dar uma resposta que parece completamente razoável.

Para informações factuais simples e bem documentadas, ela vai bem. “Em que ano foi proclamada a República no Brasil?” Isso está em tantos textos que ela vai acertar. Mas quando você quer construir conhecimento novo, fazer um raciocínio original, ou tomar uma decisão que depende de contexto que ela não tem, aí você está por conta própria.

Ela pode te ajudar a encontrar os fatos. Mas ela não vai fazer o trabalho de pensar por você.

Casos reais em que confiar na IA custou caro

Não estou falando de inconveniências.

Nas últimas temporadas, as autoridades dos Alpes italianos registraram aumento no número de mortes de turistas. A causa: pessoas que consultaram a IA sobre rotas e equipamentos necessários para trilhas de montanha, e confiaram nas respostas sem verificar com fontes especializadas.

Houve também o caso de uma mulher que mostrou uma planta para a câmera do celular, perguntou para a IA se era venenosa, acreditou na resposta e morreu.

Num evento aqui em São Paulo, assisti ao vivo a demonstração de um assistente de viagem baseado em IA. Enquanto o pessoal apresentava o produto, abri no celular e perguntei sobre um passeio de casal em Monte Verde, lugar que conheço bem. A IA me recomendou a “Praça do Pôr do Sol” para ver o pôr do sol. Essa praça fica na Vila Madalena. Não existe em Monte Verde. Os restaurantes que ela recomendou também não existiam.

Mas ela recomendou com total segurança, com descrições detalhadas e convincentes.

Quem paga a conta quando a IA mente?

Essa é uma pergunta importante para quem está pensando em usar IA no atendimento ao cliente.

A OpenAI, empresa que criou o ChatGPT, a vanguarda de tudo isso, coloca um aviso no rodapé da interface deles: “ChatGPT pode cometer erros. Considere verificar informações importantes.”

Pensa nisso um segundo.

Os melhores do mundo nessa tecnologia, com todo o investimento e conhecimento que têm, precisam avisar que o produto deles pode errar. Se eles não conseguem entregar uma IA em que você possa confiar cegamente, que mágica você imagina que vai acontecer na sua empresa?

E tem um problema jurídico que pouca gente considera: um consumidor mal-intencionado pode ficar ali, conversando com o seu chatbot, coletando sistematicamente as respostas erradas para usar como evidência em processo judicial.

Isso não é paranoia. É uma possibilidade real que precisa estar no seu modelo de risco.

A IA está mascarando falta de processo

Tem chegado até nós um tipo de cliente que me preocupa: o que quer uma IA para resolver um problema de negócios, mas que ao primeiro questionamento não sabe explicar qual é o processo que a IA deveria executar.

O briefing chegou feito pela IA. O processo que a IA deveria automatizar não está documentado. As regras de negócio não foram pensadas.

A esperança, às vezes implícita, é que a própria IA descubra qual é o processo ideal.

Ela não vai.

A IA pode sortear palavras que parecem descrever um bom processo. Mas ela não conhece o seu negócio, não conhece as exceções que sua equipe sabe de cor, não tem o contexto de anos de operação. Ela vai te dar algo que soa razoável. E você vai ter que aprender da forma difícil que razoável não é suficiente.

Em muitos casos, o problema que o cliente quer resolver com IA seria mais bem resolvido, mais barato, mais rápido, mais confiável, com um processo bem documentado e automação convencional. Sem nenhuma LLM no meio.

Como colocar IA em produção com responsabilidade

Isso não significa que você não deve usar IA. Significa que você precisa usá-la com cuidado.

Quando desenho a arquitetura de um projeto com IA, costumo pintar de vermelho as partes que envolvem o modelo. Depois olho para cada uma e pergunto: se a IA errar de forma drástica aqui, o que acontece? A saída vai direto para o cliente? Tem um sistema no meio do caminho? Qual é o impacto?

Esse risco precisa ser conhecido. E depois de conhecido, precisa ser mitigado.

Algumas práticas que fazem diferença:

Defina os limites antes de ligar. A IA precisa ter clareza sobre o que pode responder, de onde busca informação, e quando deve dizer “não sei” ou encaminhar para um humano. Sem esses limites, ela vai inventar respostas que parecem razoáveis.

Guarde logs de tudo. Em produção, você precisa conseguir auditar o que a IA está dizendo. Isso tanto para corrigir problemas quanto para ter evidência do que aconteceu em caso de disputa.

Teste muito mais do que você testaria software convencional. Software convencional é determinístico: mesma entrada, mesma saída, sempre. IA é probabilística: mesma entrada pode gerar saídas diferentes. O volume de testes necessários é massivamente maior.

A meta não é zero erros. É errar menos, ou de forma menos cara, do que o time humano erraria fazendo a mesma coisa.

Onde a IA realmente brilha

Tendo dito tudo isso, deixa eu ser justo sobre o que ela faz bem.

Tarefas repetitivas em escala. Se você tem um processo que se repete com pequenas variações, a IA pode automatizá-lo de forma eficiente.

Processamento de dados não estruturados. Você tem anos de e-mails, PDFs, registros em texto livre? A IA pode ler tudo isso e transformar em dados estruturados que um sistema convencional consegue processar. Isso é algo que antes simplesmente não dava para automatizar.

Auxiliar no raciocínio. Aqui está um dos usos que mais gosto: usar a IA para me questionar. Quando estou preparando um material, peço para ela me dizer o que estou deixando de considerar, o que poderia ser melhorado, quais pontos estão confusos. Eu não aceito as respostas como verdade, leio, avalio, e uso o que faz sentido. Mas ela quase sempre traz algo que eu não tinha considerado.

Auditoria de texto em larga escala. Você tem milhares de interações de atendimento e quer identificar onde o atendente foi mal-educado, ou onde o cliente saiu insatisfeito? A IA pode ler esse volume todo e sinalizar o que merece revisão humana.

Interface mais humana para software complexo. Em 2001, Michael Dertouzos, diretor do MIT, já previa que a interface com computadores se tornaria conversacional. Isso está acontecendo agora. Você não precisará mais ser treinado para usar um ERP se puder simplesmente dizer o que precisa. Isso vai democratizar o acesso ao software de forma que ainda não imaginamos completamente.

O que a IA não vai substituir tão cedo

A IA não vai substituir o ser humano em sua melhor entrega.

Existe uma quantidade enorme de bom senso em desenvolvimento de software. Gerar uma arquitetura que seja ao mesmo tempo segura, barata de operar e fácil de usar exige pesar fatores que a IA não sabe ponderar. Dizer “não” para o cliente quando o fluxo que ele pediu é um problema de segurança exige julgamento humano. Se quiser aprofundar nesse ponto, escrevemos mais sobre como a IA e o desenvolvedor se complementam.

Agora, a IA vai substituir quem faz trabalho de robô. Quem acorda todo dia, pega ônibus por uma hora, senta na frente de um computador e por oito horas executa tarefas mecânicas que não exigem senso crítico. Essas pessoas serão substituídas, e isso levanta questões econômicas sérias que merecem um artigo próprio.

IA é um recurso técnico, não uma religião

Tem um tipo de conversa sobre IA que me preocupa: quando o assunto da conversa é a IA em si, não o problema de negócio que ela deveria resolver.

Quando um fornecedor chega falando que vai colocar IA em tudo, em cada etapa, em cada módulo, em cada processo, desconfie. Isso é paixão pela tecnologia, não pelo seu problema.

Banco de dados relacional é um recurso técnico poderoso. Banco não-relacional também. Sistema de busca semântica também. Ninguém chega para vender software e passa meia hora falando sobre bancos de dados. Você escolhe o banco que faz sentido para o problema, e pronto.

IA deveria ser tratada da mesma forma. É mais um recurso técnico, poderosíssimo, capaz de resolver coisas que antes eram impossíveis de automatizar, mas é só mais um recurso. Ele entra na arquitetura onde faz sentido, não em todo lugar só porque é empolgante. É o que chamamos de agentes de IA especializados: IA com poderes definidos, integrada a código convencional, dentro de limites que fazem sentido para o negócio.

Software convencional ainda é a resposta mais barata, mais segura e mais previsível na maioria dos casos. E ele se integra com IA exatamente onde faz sentido. E quando o software não tem qualidade, seja gerado por IA ou não, os custos aparecem mais tarde, geralmente mais caros do que o original.

A conversa madura não é “o que a IA pode fazer”. É “qual é o seu problema, e qual é a melhor forma de resolvê-lo”. Se a resposta envolver IA, ótimo. Se não envolver, melhor ainda.

Estamos fazendo brinquedos de chumbo

No começo da Revolução Industrial, brinquedos eram feitos de chumbo. É um metal barato, fácil de trabalhar, fácil de moldar. Ninguém questionou. Só depois de muita doença e muita morte a humanidade aprendeu que não era uma boa ideia.

Estamos no mesmo momento com a IA.

Ela vai continuar existindo e vai continuar mudando o mundo. Mas estamos dando a ela acesso a nossas casas, nossos e-mails, nossas informações pessoais, nossas decisões de negócio, sem entender direito o que estamos fazendo.

Vamos aprender. Mas o custo do aprendizado pode ser alto.

Por isso a conversa que precisamos ter não é “a IA vai mudar tudo”. Ela já está mudando. A conversa que precisamos ter é: o que ela realmente é, onde ela funciona de verdade, e onde ela vai te deixar na mão.

Espero ter ajudado com isso aqui.

Este artigo é baseado numa conversa que tivemos no podcast da Visie, Thabata Camarotti, Igor Iglesias, Wellinton Ribeiro e eu, Elcio Ferreira, discutimos esse tema com profundidade. Se quiser, pode ouvir o episódio completo.

The post Super Devs: como a IA está redefinindo o desenvolvimento de software appeared first on Visie.

Não estou aqui para dizer que a inteligência artificial é inútil ou que é hype. Ela é, de fato, uma das tecnologias mais transformadoras que já apareceram. Mas tem muita gente usando ela errado, esperando coisas que ela não é capaz de entregar, e pagando um preço caro por isso.

Às vezes literalmente com a vida.

A IA é uma máquina de sortear palavras

Antes de falar sobre limitações, precisamos entender o que é uma LLM, o modelo de linguagem que está por trás do ChatGPT, Gemini, Claude e todos os outros que você usa.

Ela não pensa. Ela sorteia.

Quando você faz uma pergunta, o modelo sorteia a próxima palavra. Depois a próxima. Depois a próxima. Ele usa um mecanismo estatístico sofisticado para decidir qual palavra tem maior probabilidade de ser a “certa” dado tudo que já foi escrito antes. O que ele tem de especial é uma forma muito eficiente de classificar quão bom ficou o texto resultado, comparando com os bilhões de textos usados no treinamento.

O que isso significa na prática? A IA é boa em produzir texto que parece uma boa resposta, não necessariamente texto que é uma boa resposta.

Na maior parte dos casos, a diferença é pequena. Uma resposta que parece boa geralmente é boa. Mas em situações onde não existe uma resposta consolidada nos dados de treinamento, ela vai sortear palavras que parecem certas, e falar com a mesma convicção de sempre.

Ela não sabe que está errando. Ela nunca sabe.

O estagiário que nunca duvida de si mesmo

Gosto de pensar na IA como um estagiário bem-intencionado que erra bastante.

Isso é útil porque um estagiário te ajuda a filtrar links, fazer resumos, rascunhar textos, organizar informação. Você usa, mas você revisa. Você sabe que ele pode errar.

O problema é que a IA é um estagiário convincente. Ela não gagueja quando está incerta. Ela não diz “olha, não tenho certeza sobre isso”. Ela apresenta a resposta errada com a mesma fluência e segurança da resposta certa.

E aí as pessoas param de revisar.

Já vi isso acontecer em reuniões, em apresentações, em briefings que chegam até nós. O material foi feito pela IA. A pessoa entregou. Você faz a segunda pergunta e ela não sabe responder, porque ela nunca leu o que entregou.

Isso não é usar a IA como ferramenta. Isso é delegar a responsabilidade para uma ferramenta que não tem responsabilidade nenhuma.

Para avaliar uma resposta da IA, você precisa saber a resposta

Aqui está um paradoxo que pouca gente percebe: para saber se a IA errou, você precisa ter conhecimento suficiente para identificar o erro.

Se você não entende o assunto, qualquer resposta parece aceitável.

Isso significa que a IA é mais útil exatamente para quem já sabe do que está fazendo. Para quem não sabe, ela pode ser perigosa, não porque vai dar uma resposta obviamente errada, mas porque vai dar uma resposta que parece completamente razoável.

Para informações factuais simples e bem documentadas, ela vai bem. “Em que ano foi proclamada a República no Brasil?” Isso está em tantos textos que ela vai acertar. Mas quando você quer construir conhecimento novo, fazer um raciocínio original, ou tomar uma decisão que depende de contexto que ela não tem, aí você está por conta própria.

Ela pode te ajudar a encontrar os fatos. Mas ela não vai fazer o trabalho de pensar por você.

Casos reais em que confiar na IA custou caro

Não estou falando de inconveniências.

Nas últimas temporadas, as autoridades dos Alpes italianos registraram aumento no número de mortes de turistas. A causa: pessoas que consultaram a IA sobre rotas e equipamentos necessários para trilhas de montanha, e confiaram nas respostas sem verificar com fontes especializadas.

Houve também o caso de uma mulher que mostrou uma planta para a câmera do celular, perguntou para a IA se era venenosa, acreditou na resposta e morreu.

Num evento aqui em São Paulo, assisti ao vivo a demonstração de um assistente de viagem baseado em IA. Enquanto o pessoal apresentava o produto, abri no celular e perguntei sobre um passeio de casal em Monte Verde, lugar que conheço bem. A IA me recomendou a “Praça do Pôr do Sol” para ver o pôr do sol. Essa praça fica na Vila Madalena. Não existe em Monte Verde. Os restaurantes que ela recomendou também não existiam.

Mas ela recomendou com total segurança, com descrições detalhadas e convincentes.

Quem paga a conta quando a IA mente?

Essa é uma pergunta importante para quem está pensando em usar IA no atendimento ao cliente.

A OpenAI, empresa que criou o ChatGPT, a vanguarda de tudo isso, coloca um aviso no rodapé da interface deles: “ChatGPT pode cometer erros. Considere verificar informações importantes.”

Pensa nisso um segundo.

Os melhores do mundo nessa tecnologia, com todo o investimento e conhecimento que têm, precisam avisar que o produto deles pode errar. Se eles não conseguem entregar uma IA em que você possa confiar cegamente, que mágica você imagina que vai acontecer na sua empresa?

E tem um problema jurídico que pouca gente considera: um consumidor mal-intencionado pode ficar ali, conversando com o seu chatbot, coletando sistematicamente as respostas erradas para usar como evidência em processo judicial.

Isso não é paranoia. É uma possibilidade real que precisa estar no seu modelo de risco.

A IA está mascarando falta de processo

Tem chegado até nós um tipo de cliente que me preocupa: o que quer uma IA para resolver um problema de negócios, mas que ao primeiro questionamento não sabe explicar qual é o processo que a IA deveria executar.

O briefing chegou feito pela IA. O processo que a IA deveria automatizar não está documentado. As regras de negócio não foram pensadas.

A esperança, às vezes implícita, é que a própria IA descubra qual é o processo ideal.

Ela não vai.

A IA pode sortear palavras que parecem descrever um bom processo. Mas ela não conhece o seu negócio, não conhece as exceções que sua equipe sabe de cor, não tem o contexto de anos de operação. Ela vai te dar algo que soa razoável. E você vai ter que aprender da forma difícil que razoável não é suficiente.

Em muitos casos, o problema que o cliente quer resolver com IA seria mais bem resolvido, mais barato, mais rápido, mais confiável, com um processo bem documentado e automação convencional. Sem nenhuma LLM no meio.

Como colocar IA em produção com responsabilidade

Isso não significa que você não deve usar IA. Significa que você precisa usá-la com cuidado.

Quando desenho a arquitetura de um projeto com IA, costumo pintar de vermelho as partes que envolvem o modelo. Depois olho para cada uma e pergunto: se a IA errar de forma drástica aqui, o que acontece? A saída vai direto para o cliente? Tem um sistema no meio do caminho? Qual é o impacto?

Esse risco precisa ser conhecido. E depois de conhecido, precisa ser mitigado.

Algumas práticas que fazem diferença:

Defina os limites antes de ligar. A IA precisa ter clareza sobre o que pode responder, de onde busca informação, e quando deve dizer “não sei” ou encaminhar para um humano. Sem esses limites, ela vai inventar respostas que parecem razoáveis.

Guarde logs de tudo. Em produção, você precisa conseguir auditar o que a IA está dizendo. Isso tanto para corrigir problemas quanto para ter evidência do que aconteceu em caso de disputa.

Teste muito mais do que você testaria software convencional. Software convencional é determinístico: mesma entrada, mesma saída, sempre. IA é probabilística: mesma entrada pode gerar saídas diferentes. O volume de testes necessários é massivamente maior.

A meta não é zero erros. É errar menos, ou de forma menos cara, do que o time humano erraria fazendo a mesma coisa.

Onde a IA realmente brilha

Tendo dito tudo isso, deixa eu ser justo sobre o que ela faz bem.

Tarefas repetitivas em escala. Se você tem um processo que se repete com pequenas variações, a IA pode automatizá-lo de forma eficiente.

Processamento de dados não estruturados. Você tem anos de e-mails, PDFs, registros em texto livre? A IA pode ler tudo isso e transformar em dados estruturados que um sistema convencional consegue processar. Isso é algo que antes simplesmente não dava para automatizar.

Auxiliar no raciocínio. Aqui está um dos usos que mais gosto: usar a IA para me questionar. Quando estou preparando um material, peço para ela me dizer o que estou deixando de considerar, o que poderia ser melhorado, quais pontos estão confusos. Eu não aceito as respostas como verdade, leio, avalio, e uso o que faz sentido. Mas ela quase sempre traz algo que eu não tinha considerado.

Auditoria de texto em larga escala. Você tem milhares de interações de atendimento e quer identificar onde o atendente foi mal-educado, ou onde o cliente saiu insatisfeito? A IA pode ler esse volume todo e sinalizar o que merece revisão humana.

Interface mais humana para software complexo. Em 2001, Michael Dertouzos, diretor do MIT, já previa que a interface com computadores se tornaria conversacional. Isso está acontecendo agora. Você não precisará mais ser treinado para usar um ERP se puder simplesmente dizer o que precisa. Isso vai democratizar o acesso ao software de forma que ainda não imaginamos completamente.

O que a IA não vai substituir tão cedo

A IA não vai substituir o ser humano em sua melhor entrega.

Existe uma quantidade enorme de bom senso em desenvolvimento de software. Gerar uma arquitetura que seja ao mesmo tempo segura, barata de operar e fácil de usar exige pesar fatores que a IA não sabe ponderar. Dizer “não” para o cliente quando o fluxo que ele pediu é um problema de segurança exige julgamento humano. Se quiser aprofundar nesse ponto, escrevemos mais sobre como a IA e o desenvolvedor se complementam.

Agora, a IA vai substituir quem faz trabalho de robô. Quem acorda todo dia, pega ônibus por uma hora, senta na frente de um computador e por oito horas executa tarefas mecânicas que não exigem senso crítico. Essas pessoas serão substituídas, e isso levanta questões econômicas sérias que merecem um artigo próprio.

IA é um recurso técnico, não uma religião

Tem um tipo de conversa sobre IA que me preocupa: quando o assunto da conversa é a IA em si, não o problema de negócio que ela deveria resolver.

Quando um fornecedor chega falando que vai colocar IA em tudo, em cada etapa, em cada módulo, em cada processo, desconfie. Isso é paixão pela tecnologia, não pelo seu problema.

Banco de dados relacional é um recurso técnico poderoso. Banco não-relacional também. Sistema de busca semântica também. Ninguém chega para vender software e passa meia hora falando sobre bancos de dados. Você escolhe o banco que faz sentido para o problema, e pronto.

IA deveria ser tratada da mesma forma. É mais um recurso técnico, poderosíssimo, capaz de resolver coisas que antes eram impossíveis de automatizar, mas é só mais um recurso. Ele entra na arquitetura onde faz sentido, não em todo lugar só porque é empolgante. É o que chamamos de agentes de IA especializados: IA com poderes definidos, integrada a código convencional, dentro de limites que fazem sentido para o negócio.

Software convencional ainda é a resposta mais barata, mais segura e mais previsível na maioria dos casos. E ele se integra com IA exatamente onde faz sentido. E quando o software não tem qualidade, seja gerado por IA ou não, os custos aparecem mais tarde, geralmente mais caros do que o original.

A conversa madura não é “o que a IA pode fazer”. É “qual é o seu problema, e qual é a melhor forma de resolvê-lo”. Se a resposta envolver IA, ótimo. Se não envolver, melhor ainda.

Estamos fazendo brinquedos de chumbo

No começo da Revolução Industrial, brinquedos eram feitos de chumbo. É um metal barato, fácil de trabalhar, fácil de moldar. Ninguém questionou. Só depois de muita doença e muita morte a humanidade aprendeu que não era uma boa ideia.

Estamos no mesmo momento com a IA.

Ela vai continuar existindo e vai continuar mudando o mundo. Mas estamos dando a ela acesso a nossas casas, nossos e-mails, nossas informações pessoais, nossas decisões de negócio, sem entender direito o que estamos fazendo.

Vamos aprender. Mas o custo do aprendizado pode ser alto.

Por isso a conversa que precisamos ter não é “a IA vai mudar tudo”. Ela já está mudando. A conversa que precisamos ter é: o que ela realmente é, onde ela funciona de verdade, e onde ela vai te deixar na mão.

Espero ter ajudado com isso aqui.

Este artigo é baseado numa conversa que tivemos no podcast da Visie, Thabata Camarotti, Igor Iglesias, Wellinton Ribeiro e eu, Elcio Ferreira, discutimos esse tema com profundidade. Se quiser, pode ouvir o episódio completo.

The post O que a inteligência artificial não pode fazer appeared first on Visie.

A intenção é boa: reduzir riscos.  O problema é que, em muitos casos, o custo de evitar o erro se tornou maior do que o custo do próprio erro.

Em tecnologia, especialmente no desenvolvimento de software, essa lógica costuma gerar um efeito colateral perigoso: a lentidão. Quando um time leva seis meses para desenhar a “arquitetura perfeita”, o mercado não espera. O cliente muda, o concorrente se antecipa e a hipótese inicial perde validade.

Agora compare isso com um cenário diferente: em duas semanas, o time improvisa um MVP funcional, coloca algo real nas mãos do usuário e recebe feedback concreto. Esse feedback não é opinião, nem achismo, mas dado. E dado real é o ativo mais valioso que uma empresa pode ter.

Prepare-se, neste artigo vou defender uma ideia que soa quase herética em ambientes corporativos: o improviso, quando bem usado, é uma das ferramentas mais poderosas para reduzir o time-to-market e aumentar a capacidade de inovação.

Aqui, com “improviso” não quero dizer ausência de técnica. Entenda improviso como a  capacidade de agir rápido, sem paralisia burocrática.

O Improviso como Motor de Agilidade

O primeiro benefício do improviso é simples: velocidade de resposta. Projetos reais raramente seguem o plano original. Eu, pelo menos, nunca vi acontecer. Se você tem uma certeza ao começar um projeto de software é que as coisas vão mudar.

Se você coloca algo funcional nas mãos do usuário cedo, você ganha o dado mais valioso de todos: o feedback real do usuário. O improviso permite respostas rápidas. Se um bug crítico surge ou uma ideia genial brota no meio de um sprint, esperar pela próxima reunião de planejamento é decretar a morte da oportunidade. 

Em ambientes excessivamente rígidos, qualquer desvio exige passar pela via-crúcis: reunião, aprovação, replanejamento e documentação. O tempo passa e o problema continua ali. Em times que sabem improvisar, a resposta é imediata. Ajusta-se o plano, resolve-se o problema e aprende-se com isso depois.

O improviso também cria uma cultura de experimentação. Empresas como Google e Spotify ficaram conhecidas por incentivar espaços de liberdade controlada — hackathons, projetos paralelos, tempo dedicado a explorar ideias fora do backlog tradicional. Produtos como o Gmail nasceram exatamente desse espaço de improviso consciente.

Existe ainda um impacto humano importante, frequentemente ignorado: motivação. Quando as pessoas têm liberdade para decidir como resolver um problema, elas deixam de ser só executoras de tarefas e passam a se sentir donas do trabalho. Isso tem o potencial de reduzir burnout, aumentar o engajamento e melhorar a retenção de talentos. Pessoas gostam de resolver problemas de verdade — não apenas seguir processos.

Mitigando Riscos sem Matar a Velocidade

O principal argumento contra o improviso costuma ser o medo. Medo de dívida técnica, falhas de segurança ou soluções frágeis. Esses riscos existem, negar isso seria ingenuidade. O erro está em achar que a única forma de mitigá-los é com burocracia pesada. Há alternativas muito mais leves e eficazes. Um improviso não precisa ser definitivo. É claro que o improviso sem rede de proteção é perigoso. Mas a solução não é mais burocracia; são proteções técnicas.

Em vez de impedir o improviso, sugiro usar ferramentas que permitam que ele aconteça com segurança:

• Code Reviews e Testes Automatizados: O improviso acontece na solução, mas todo mundo tem certeza de que a validação vai acontecer. Testes automatizados são a garantia que uma alteração não vai quebrar o que já funcionava. Esse é o único jeito de ser ágil de verdade em desenvolvimento de software.
• CI/CD Pipelines: Se você pode deployar rápido e fazer rollback mais rápido ainda, o medo de improvisar diminui.
• Aprendizado com o Erro: O modelo de blameless post-mortems (análises de erros sem culpados), pilar do SRE do Google, foca em entender a falha sistêmica em vez de punir a iniciativa individual.

É aqui que a diferença entre Ágil e Waterfall fica evidente. O improviso não cabe em modelos rígidos e sequenciais. Mas ele se encaixa perfeitamente em ambientes ágeis que possuem proteções: pipelines de CI/CD, testes automatizados, observabilidade e rollback rápido. Ou seja, o improviso não elimina risco, mas muda onde ele é tratado: sai do papel e vai para o código e para as ferramentas técnicas.

A história está cheia de exemplos: a Nokia, com sua rigidez e processos pesados, foi atropelada, entre outros fatores, pela fluidez (e pelos improvisos iniciais) do ecossistema do iPhone. No software moderno, o “Ágil” de verdade muitas vezes se parece mais com um jazz do que com uma marcha militar.

A Analogia do Jazz: Maestria como Pré-requisito

A analogia do Jazz é perfeita: no Jazz, só improvisa bem quem domina muito o instrumento. O improviso só funciona porque os músicos dominam profundamente a técnica e a teoria. No software, acontece o mesmo. O improviso legítimo nasce de quem conhece tão bem os fundamentos que consegue “compor em tempo real”.

O improviso que elogiamos não é o da negligência (“vou fazer de qualquer jeito porque não sei fazer o certo”), mas o da maestria. Um desenvolvedor sênior improvisa porque conhece os fundamentos tão bem que consegue “compor em tempo real” para validar uma hipótese.

O que eu chamo de Improviso por Maestria é quando um desenvolvedor pensa: “Conheço a regra, mas vou quebrá-la agora para entregar valor imediato.”

Já o Improviso por Negligência é: “Não conheço a regra, então estou apenas tentando a sorte.”

Para que o improviso funcione, a empresa precisa investir em mentoria e treinamento. Times juniores precisam de mais estrutura; times seniores precisam de mais liberdade.

Onde Pisar no Freio?

Seria irresponsável dizer que o improviso cabe em todo lugar. Em setores altamente regulados, como saúde ou finanças (HIPAA, GDPR, LGPD), o improviso deve focar na experiência do usuário e na lógica de negócio, mas o compliance e a segurança de dados precisam ser inegociáveis e embutidos desde o início. Mesmo em contextos regulados, improvisar não desaparece, mas há limites: improvisa-se na solução, não na conformidade.

Além disso, é preciso gerenciar a Dívida Técnica. Muitas vezes uma solução improvisada é simplesmente melhor do que aquelas que um processo de planejamento detalhado é capaz de entregar. Mas, às vezes, o improviso pode ser um empréstimo de agilidade. Como qualquer empréstimo, ele tem juros. O segredo é ter métricas claras: quanto tempo estamos gastando em novas features versus quanto tempo estamos gastando pagando “juros” (refatorando improvisos passados).

O Exercício da Confiança

Promover o improviso é, essencialmente, um exercício de confiança. Quando uma empresa pune um desenvolvedor que saiu do script para resolver a dor de um cliente, ela está ensinando seu time a parar de pensar. O desenvolvedor vira apenas um executor de tickets. O improviso devolve ao desenvolvedor o papel de artesão e resolvedor de problemas. E empresas que permitem isso colhem algo raro: times que se importam genuinamente com o resultado.

O equilíbrio ideal entre controle e liberdade não é uma linha estática; é um ciclo de experimentação. Mas uma coisa é certa: burocracia demais costuma ser pior do que burocracia de menos. Nossa recomendação? Comece o mais leve possível. Dê aos seus times a liberdade de serem resolvedores de problemas. Acrescente controles apenas onde algum problema real aparecer, e não onde o medo imaginário mandar.

Afinal, em um mercado que muda na velocidade da luz, a maior gambiarra de todas é tentar controlar o futuro com excesso de papelada.

Gostou deste artigo? Na Visie, acreditamos que o desenvolvimento de software é um equilíbrio entre engenharia rigorosa e a agilidade criativa. Se você quer saber como podemos ajudar seu time a encontrar esse ponto de equilíbrio, que tal conversarmos sobre seu próximo projeto?

The post Elogio ao Improviso: Por que a Burocracia está Matando a Inovação appeared first on Visie.

Ao longo de duas décadas, uma ideia ficou cada vez mais clara pra nós: tecnologia é ferramenta, não fim. Desde o começo, o nosso trabalho sempre foi ajudar pessoas e empresas a usar tecnologia para simplificar a vida — com menos fricção, menos ruído, menos “processo pelo processo”. Em outras palavras: fazer software para seres humanos e, sempre que possível, parar de semear burocracia.

Diante disso, se tem uma forma gostosa de comemorar 20 anos, é olhando para trás e lembrando das transformações que mudaram a nossa profissão — e a vida de todo mundo.

1) Smartphones (iPhone e Android)

Smartphone é o computador que você carrega no bolso: câmera, sensores, GPS, internet, pagamentos, trabalho, lazer — tudo ali. O marco que “virou a chave” foi o iPhone, que chegou ao público em 29 de junho de 2007 e redefiniu como a gente interage com tecnologia. Pouco depois, o Android começou sua trajetória comercial em 2008 e fez isso ganhar escala global. Com isso, o impacto foi tão grande que mudou até como projetos nascem: a web passou a ser mobile-first não por moda, mas porque as pessoas passaram a viver no celular.

2) Carros autônomos (como Tesla Autopilot)

Carros autônomos — e, por enquanto, principalmente os sistemas avançados de assistência — são a aplicação direta de sensores + software + IA no mundo físico, em tempo real. O Tesla Autopilot virou um símbolo dessa era a partir de 2014, e desde então, o carro deixou de ser só “máquina” e virou “plataforma que atualiza”. O impacto está em andamento: ainda há debates enormes sobre segurança e responsabilidade, mas a direção já virou um problema computacional — e isso é um divisor de águas.

3) Netflix e Spotify (acesso em vez de propriedade)

Streaming é a ideia de que você não “compra” mídia; você acessa. A Netflix fez a virada quando começou o streaming em 2007, e o Spotify nasceu em 2008 empurrando a música para o mesmo caminho. O impacto foi cultural e econômico: assinatura virou padrão, recomendação algorítmica virou parte do produto, e “ter uma coleção” foi substituído por “ter acesso”.

4) Airbnb e Uber (uso sob demanda)

Airbnb e Uber são dois ícones do modelo “sob demanda”: plataformas que conectam oferta e demanda do mundo físico com software, logística e reputação digital. O Airbnb nasceu em 2008, o Uber em 2009, e de repente hospedagem e mobilidade passaram a funcionar como aplicativo. O impacto foi imediato: nasceu a gig economy, regulações foram chacoalhadas, e ficou claro o poder de escalar serviços físicos com tecnologia.

5) HTML5 e CSS3

HTML5 e CSS3 são, na prática, o momento em que a web deixou de ser “página” e virou “plataforma”. O HTML5 se consolidou como recomendação do W3C em 2014, e o CSS3 trouxe (ao longo dos anos) responsividade, animações e recursos que antes exigiam gambiarras ou plugins. O impacto foi libertador: vídeo, áudio, gráficos, layout moderno — tudo no padrão aberto, com performance e consistência.

6) Angular, React e Vue.js

Quando AngularJS apareceu em 2010, e depois React em 2013 e Vue em 2014, a interface ganhou um novo status. A partir daí, virou software complexo, organizado em componentes, estado e reatividade. Consequentemente, o impacto foi enorme na produtividade e na capacidade de construir UIs ricas — e também na responsabilidade: front-end deixou de ser “camada visual” e virou “produto dentro do produto”.

7) LLMs

LLMs são modelos de linguagem capazes de ler, escrever, resumir, explicar e programar em linguagem natural — uma tecnologia que parecia “muito futurista” até poucos anos atrás. A explosão pública aconteceu com o lançamento do ChatGPT em 30 de novembro de 2022, trazendo IA generativa para o dia a dia de equipes e pessoas comuns. O impacto é comparável a um novo “computador pessoal”: muda fluxo de trabalho, muda produto, muda educação — e cria discussões sérias sobre segurança, privacidade e governança.

8) Containers (Docker e Kubernetes)

Containers são a forma moderna de empacotar e executar software com previsibilidade: “funciona aqui” passa a significar “funciona em qualquer lugar”. O Docker virou o símbolo disso ao ser lançado como open source em março de 2013, e o Kubernetes apareceu em junho de 2014 como a resposta para orquestrar isso em escala. O impacto é gigantesco: deploy ficou repetível, infra virou parte do código, e “rodar em produção” virou disciplina.

9) Node.js

Node.js levou JavaScript para o servidor em 2009, e isso fez muita coisa “clicar”: a mesma linguagem no front e no back, alta performance em I/O, ecossistema vibrante de bibliotecas e ferramentas. O impacto foi redefinir o jeito de construir APIs e serviços — e, para muita equipe, reduzir atrito e aumentar velocidade de entrega.

10) Cloud Computing

Cloud computing é o modelo em que infraestrutura vira serviço: você provisiona, escala e paga pelo uso. A AWS puxou essa virada em 2006 com serviços como o S3 (lançado em março de 2006) e, a partir dali, “ter datacenter” deixou de ser pré-requisito para crescer. O impacto foi democratizar escala: startups ganharam superpoderes e empresas grandes ganharam velocidade de experimentação.

11) Let’s Encrypt

Let’s Encrypt tornou HTTPS fácil e gratuito a partir de 2015, automatizando algo que antes era burocrático, caro e cheio de barreiras. O impacto foi civilizatório para a web: criptografia deixou de ser diferencial e virou o padrão mínimo aceitável.

12) YouTube e redes sociais

YouTube (2005) e redes sociais consolidaram uma internet onde o conteúdo é fluxo, comunidade e conversa — e não só “site”. O impacto foi mudar marketing, educação, entretenimento, política e comportamento. E, do ponto de vista de produto digital, mudou o jogo: distribuição e atenção viraram parte central da estratégia.

13) Google Chrome

Quando o Chrome foi lançado em 2 de setembro de 2008, ele acelerou a web: performance, atualização constante, pressão por padrões e uma nova corrida entre navegadores. O impacto foi direto para quem desenvolve: mais recursos, mais consistência e um empurrão enorme para experiências cada vez mais “app-like” no browser.

14) Blockchain

Blockchain é um registro distribuído e imutável, popularizado pelo Bitcoin em 2008. O impacto foi abrir uma nova discussão sobre confiança digital, descentralização e novos modelos econômicos — com tudo que veio junto: inovação real, hype pesado e a necessidade de separar promessa de produto.

15) App Store

A App Store (2008) institucionalizou a economia de aplicativos: distribuição, pagamento, descoberta, atualização. O impacto foi um novo mercado inteiro: apps viraram canal principal, empresas nasceram “app-first” e o celular virou uma plataforma de negócios.

16) Pix

O Pix colocou pagamentos instantâneos no cotidiano brasileiro desde 16 de novembro de 2020. O impacto desta tecnologia foi imediato: menos fricção, mais inclusão, QR Code em todo lugar e uma mudança radical de hábito — para pessoas e empresas.

17) Waze (e Google Maps)

Waze e Google Maps transformaram deslocamento em software: rotas em tempo real, trânsito como dado, cidade como API. O Waze ganhou força como produto na virada para 2008, e isso mudou como a gente se move e como negócios pensam logística. Consequentemente, o impacto é tão grande que, hoje, mobilidade urbana não se entende sem mapa digital.

18) Git

Git nasceu em 2005 e desde então virou a espinha dorsal do desenvolvimento moderno: versionamento distribuído, colaboração, histórico confiável, workflows maduros. O impacto foi permitir que times e comunidades crescessem sem virar caos — e viabilizar, assim, a escala do open source e das práticas modernas de engenharia.

19) CDNs (Cloudflare)

CDNs colocam conteúdo “perto” do usuário e protegem aplicações na borda. A Cloudflare surgiu em 2009 e ajudou a popularizar performance e segurança como algo acessível. O impacto é invisível (quando funciona), mas enorme: páginas mais rápidas, menos latência, mais proteção, mais estabilidade.

20) HTTP/2 e HTTP/3

HTTP/2 e HTTP/3 são mudanças “por baixo do capô” que fazem a web ficar mais rápida e eficiente. O HTTP/2 virou padrão em 2015 (RFC 7540), e o HTTP/3 veio depois, publicado como RFC 9114 em 2022, levando HTTP para cima do QUIC. O impacto é silencioso, mas decisivo: melhor performance em redes instáveis, conexões mais eficientes e uma web mais preparada para escala.

O que a gente aprendeu no caminho

Quando você olha essa lista, dá vontade de pensar que tudo mudou. E mudou mesmo. Mas tem algo curioso: os princípios certos envelhecem muito bem.

No fim das contas, a tecnologia mais valiosa é a que reduz atrito, melhora a experiência e dá autonomia — e é por isso que, mesmo com novas ondas chegando o tempo todo, a Visie continua perseguindo a mesma direção: menos burocracia, mais clareza, mais fluidez, mais gente feliz usando software.

Se você estivesse escrevendo essa lista, quais transformações entrariam no seu Top 20?

The post 20 anos de Visie: 20 transformações e tecnologias que vimos nascer appeared first on Visie.

Essa questão, que parece um simples detalhe, no entanto, revela muito sobre o que o profissional busca: liberdade geográfica, preferência por uma liderança flexível, alinhamento com a cultura da empresa e, acima de tudo, a importância da confiança nas relações de trabalho.

O Fim do “Olho do Dono”

É só dar uma olhada nas redes sociais para ver as inúmeras discussões sobre o home office. Há quem defenda com unhas e dentes e quem simplesmente não suporte. Com frequência, nos deparamos com falas como a de Jamie Dimon, CEO do JPMorgan Chase, criticando o trabalho remoto, alegando que ele atrapalha a gestão, a inovação e o aprendizado:

“O trabalho remoto não funciona para os jovens, para a gestão ou para a inovação. Aplaudo o direito de não querer ir ao escritório todos os dias, mas você não vai dizer à JPMorgan o que fazer.”

No entanto, sejamos sinceros: se sua empresa ainda acredita que um funcionário só produz sob sua vigilância, então é provável que o problema não seja o funcionário, certo? A liberdade do home office vai muito além de onde a pessoa está. É sobre maturidade, autonomia e responsabilidade compartilhada. Quando uma equipe atua remotamente, a liderança mostra que confia na capacidade do time de entregar resultados sem precisar controlar cada minuto. É fundamental, portanto, entender que o profissional tem uma vida fora da empresa e que pode ser super produtivo sem estar fisicamente presente no escritório.

Enquanto algumas empresas insistem no controle de ponto e na ideia de que só se trabalha entre quatro paredes no escritório, com todo o estresse do trânsito, outras estão colhendo os bons resultados de uma abordagem baseada na confiança, e não no microgerenciamento.

O home office está com os dias contados?

Recentemente, a volta ao trabalho presencial ganhou força. Gigantes como a Amazon anunciaram o retorno 100% ao escritório. E esse movimento não é só lá fora; no Brasil, o cenário pós-pandemia já mostra essa mudança.

De acordo com o estudo “Planeta Firma – Anuário de Benefícios 2025”, o home office está em queda no país:

• 33,8% das empresas já operam 100% presencialmente.
• 32,1% adotam modelos híbridos, porém com mais dias no escritório.
• O Auxílio Home Office despencou de 45% (em 2021) para apenas 27% (em 2024).

Em contrapartida, o vale-combustível cresceu 203% e o auxílio-mobilidade aumentou 76%.

Essa mudança toda reacende uma discussão importante: o regime de trabalho ideal não é só uma questão de logística. Ele revela a cultura da empresa e impacta diretamente como atraímos e mantemos talentos. Como resultado, para muitos, o home office é um benefício e tanto, e não ter essa opção pode ser o motivo para um profissional recusar uma vaga.

A transição da Visie para o home office: nossos aprendizados e benefícios

Aqui na Visie, vivemos a transição do presencial para o home office de forma intensa.

Atualmente, já acumulamos sete anos de experiência contínua com o home office, sendo mais de cinco anos trabalhando totalmente de casa. Além da liberdade geográfica, esse modelo nos trouxe vários benefícios: mais qualidade de vida, uma queda significativa nas faltas e, ainda que em menor escala, uma boa redução nos custos de escritório. Todavia, o foco de hoje é outro: vamos voltar a falar da agilidade no trabalho remoto.

Olhando assim, pode até parecer que o home office deu certo para a Visie desde o começo, mas isso não aconteceu sem esforço. Acredite, enfrentamos muitos desafios e precisamos mudar bastante coisa. Dessa forma, uma das áreas que mais se transformou foi a forma como desenvolvemos software. Deixamos para trás metodologias antigas e complicadas, como o Processo Unificado, e vimos na rotina remota uma chance de melhorar ainda mais nossa agilidade.

Para a Visie, a agilidade não é só um conjunto de regras, como o Scrum. É, acima de tudo, saber se adaptar. E isso vale tanto para como os processos funcionam quanto para como a equipe colabora, aprende e entrega valor.

Desafios e adaptações no home office

Nossa experiência também mostrou que nem todo mundo se adapta bem ao home office. Trabalhar de casa exige mais autogestão e disciplina para organizar o próprio tempo. O mundo digital está cheio de distrações, e para algumas pessoas, estar perto dos colegas no escritório, com a pressão social, é a única forma de se concentrar.

A comunicação também é um ponto importante. Trabalhar a distância pede um tipo diferente de habilidade. Por exemplo, é preciso saber usar as ferramentas online e de colaboração. Se você tem um problema técnico em casa, na maioria das vezes vai ter que se virar, já que a tecnologia é seu único meio de pedir ajuda. Ademais, para muitos, é difícil se comunicar de forma clara sem estar na mesma sala, olhando nos olhos ou fazendo um desenho rápido.

Por fim, percebemos que nem toda empresa funciona bem no modelo remoto por questões de cultura e gestão. O trabalho a distância exige um cuidado especial para construir uma cultura forte. Para certas culturas empresariais, o remoto simplesmente não se encaixa.

Vale lembrar que a experiência da Visie é bem particular, e o remoto funciona mais fácil pra gente do que para a maioria das empresas por aí.

Scrum, papéis e nossa estrutura mais enxuta

O ambiente remoto também nos fez perceber que menos é mais. Times maduros, com desenvolvedores experientes, não precisam de um monte de camadas no meio do caminho para as coisas acontecerem.

Na prática, nossos coordenadores de projeto são programadores que trabalham junto com o time. Eles ajudam nas cerimônias do projeto, mantêm o ritmo e garantem a qualidade do que é entregue. Isso pode parecer meio louco para muitas empresas, já que eliminar um papel como o de Scrum Master, por exemplo, é algo impensável para o bom andamento dos projetos. No entanto, aqui na Visie, é o contrário. Essa estrutura horizontal nos ajuda a evitar ruídos de comunicação e a aproximar a equipe do cliente. É comum que os próprios desenvolvedores recebam feedback direto, seja bom ou ruim, e isso faz com que eles se sintam mais responsáveis e donos do produto final que a gente entrega.

Métricas: o que a gente mede na agilidade?

Para nós, a única coisa que realmente importa é o software funcionando. É isso que mostra o progresso, o valor entregue e a qualidade técnica. A gente foca em entregas pequenas, constantes e que podem ser testadas, seguindo o espírito ágil de aprender e ajustar rápido. A autonomia da equipe é prioridade. Em outras palavras, ao invés de controlar horários ou exigir relatórios diários, nossa empresa foca em resultados que dão pra ver.

E isso não quer dizer que a gente não acompanha: a prática de pair programming no ambiente remoto, aliás, ajuda muito no aprendizado entre os desenvolvedores e fortalece nossa cultura de melhoria contínua.

Transparência e liderança técnica

Na Visie, a liderança é técnica e prática. Não temos gerentes que só observam, nossos líderes programam, participam das decisões técnicas e conhecem as dificuldades reais do dia a dia. Essa proximidade com a equipe e com o cliente garante que o trabalho flua e que a gente entregue sempre com a mesma qualidade.

Nossa comunicação é direta: sem “tradutores de requisito”, sem intermediários entre cliente e equipe. Isso exige maturidade, porém, traz clareza, agilidade e um senso de dono. Além disso, o feedback constante garante a melhoria contínua.

O futuro do mercado seria híbrido?

Muito se fala sobre o “modelo híbrido” como a solução ideal. Contudo, o verdadeiro híbrido vai além de só misturar dias em casa e no escritório. É uma forma de pensar o trabalho de um jeito flexível, adaptável e focado nas entregas, em vez de horários fixos ou presença física.

Acreditamos que o futuro do trabalho é, por sua natureza, remoto, especialmente para funções como o desenvolvimento de software. As vantagens são claras: flexibilidade, acesso a talentos de todo o mundo, aumento da produtividade e um equilíbrio melhor entre vida pessoal e profissional.

Agilidade é mais humana do que técnica

A discussão sobre o modelo de trabalho ideal mostra algo ainda maior: a fragilidade de empresas que não confiam em suas equipes e a força daquelas que valorizam a autonomia, responsabilidade e um propósito claro.

A agilidade não é só uma regra. É uma forma de pensar. E ela funciona e melhora mesmo em ambientes remotos, desde que exista confiança, uma liderança com os pés no chão e uma cultura que valoriza a entrega de verdade, e não só a encenação da produtividade.

E na sua empresa?

• Vocês estão prontos para confiar mais e controlar menos?
• Seus processos valorizam o software funcionando ou a formalidade dos rituais?
• Sua equipe colabora porque é obrigada ou porque realmente se importa?

🎧 Quer saber mais sobre a verdadeira agilidade no home office? Ouça o nosso bate-papo completo no podcast “Simplificando o Digital”.

The post Agilidade no home office e o futuro do trabalho remoto appeared first on Visie.

No desenvolvimento de software, vemos ferramentas que escrevem trechos de código, automatizam testes, sugerem correções e até detectam vulnerabilidades de segurança. Diante disso, é natural que surja uma pergunta inquietante: a IA vai substituir os desenvolvedores humanos?

Apesar de parecer contraintuitiva para alguns, a resposta é clara: não.

Inteligência artificial não substitui consciência humana

A IA realmente mudou o jogo. Mas não veio para tirar os humanos da jogada. Pelo contrário: ela evidencia ainda mais o valor insubstituível da inteligência emocional, do julgamento ético, da criatividade e da empatia — competências humanas essenciais no desenvolvimento de software.

Sim, algoritmos podem analisar padrões. Mas apenas pessoas conseguem compreender o impacto de uma decisão sobre a vida de outras pessoas. Desenvolver software não é apenas escrever código funcional; é resolver problemas humanos por meio de soluções digitais.

Desenvolver software é entender de gente, não só de código

Embora envolva lógica, frameworks e linguagens, desenvolver software é uma atividade profundamente humana. É projetar experiências, eliminar frustrações, melhorar fluxos, facilitar jornadas.

Ao criar um sistema ou uma aplicação, o desenvolvedor precisa considerar muito mais do que performance e design técnico. Ele pensa em quem vai usar, em como aquela funcionalidade será compreendida, em como minimizar erros e aumentar a confiança do usuário.

Esse olhar exige mais do que conhecimento técnico: requer sensibilidade, empatia, visão de negócio e consciência ética. E tudo isso ainda está fora do alcance das máquinas.

Inteligência Artificial é eficiente, mas ainda carece de consciência

A IA generativa já demonstra capacidades impressionantes. Ela reconhece padrões, aprende com grandes volumes de dados e executa tarefas com agilidade. Mas existe algo fundamental que ela não faz — e talvez nunca fará: sentir.

Ela não sente medo ao decidir. Não se emociona com uma entrega bem feita. Não entende o impacto emocional de uma escolha de design, de um fluxo confuso ou de um bug crítico.

E mais: ela não assume responsabilidades. Se uma IA tomar uma decisão que prejudica milhares de usuários, quem responde? Onde está a ética? A accountability?

Esse é um ponto central. Sem consciência, não há julgamento. Sem julgamento, não há decisões críticas confiáveis.

Decisões críticas exigem julgamento humano

Durante o ciclo de desenvolvimento, muitas decisões não estão explícitas em briefings, documentos técnicos ou históricos de dados. Elas surgem de situações inesperadas, mudanças de escopo, restrições de prazo, novas informações e interações humanas.

São escolhas que dependem de repertório, contexto e bom senso. E são essas decisões que fazem a diferença entre um software burocrático e uma solução intuitiva, eficiente e acolhedora.

Discernimento não se programa. Se adquire com vivência.

O papel da Inteligência Artificial no desenvolvimento de software é gigantesco (e positivo)

Nada disso diminui a importância da IA. Muito pelo contrário. Seu papel no desenvolvimento é cada vez mais essencial — como aliada, não como substituta.

A IA aumenta a produtividade dos times: automatiza tarefas repetitivas, sugere melhorias, localiza falhas com precisão. Ela ajuda os desenvolvedores a ganharem tempo, foco e energia para o que realmente importa: criar soluções mais humanas, estratégicas e inovadoras.

Ela também abre novas possibilidades: pair programming com IA, refatoração mais ágil, análises preditivas, testes contínuos mais robustos, segurança reforçada. Isso não elimina o humano — eleva o humano a um novo patamar de atuação.

A Inteligência Artificial transforma funções, mas não elimina o humano

A história da tecnologia mostra que a substituição total do ser humano é um mito recorrente. O que acontece, de fato, é transformação.

Funções desaparecem, sim. Mas novas surgem. E outras se tornam mais estratégicas, exigindo novos conhecimentos e novas formas de atuação.

No contexto do desenvolvimento de software, isso significa que o papel do desenvolvedor vai mudar — mas não vai desaparecer. Vai se tornar mais analítico, mais criativo, mais colaborativo.

O futuro é colaborativo: Inteligência Artificial e humanos trabalhando juntos

A narrativa da IA como substituta do ser humano é simplista. O futuro mais promissor é aquele em que pessoas e máquinas trabalham juntas, cada uma com seu papel claro.

A IA cuida da repetição, da escala, da velocidade. O ser humano cuida da direção, do propósito, do impacto. Um complementa o outro. E essa sinergia é o que vai permitir que a tecnologia evolua de forma ética, sustentável e verdadeiramente inovadora.

Olhando para frente: e daqui a 30 anos?

É impossível prever com exatidão como a IA se desenvolverá nas próximas décadas. Pode ser que a computação quântica amplie suas capacidades. Pode ser que surjam formas mais sofisticadas de simular consciência.

Mas mesmo nesse cenário, a capacidade humana de criar com empatia, de interpretar o mundo com sensibilidade e de tomar decisões com ética continuará sendo indispensável.

Tecnologia evolui. Mas nossa humanidade evolui junto.

Conclusão: o desenvolvimento de software é, e continuará sendo, humano

A Inteligência Artificial veio para transformar o desenvolvimento — e isso é ótimo. Mas a essência do bom software continua sendo a mesma: resolver problemas humanos com responsabilidade, empatia e inteligência contextual.

Enquanto houver pessoas com necessidades reais, haverá espaço para soluções criadas por outras pessoas — com sensibilidade, ética e propósito.

No fim das contas, a tecnologia é um meio. O fim continua sendo o ser humano.

E você?

Como enxerga o impacto da inteligência artificial no desenvolvimento de software?

🎧 Ouça o bate-papo no nosso canal e deixe sua opinião nos comentários — vamos adorar saber o que você pensa!

The post IA e desenvolvimento de software: colaboração, não substituição appeared first on Visie.

Claramente, não é o que você espera, ao contratar seu fornecedor, por isso gravamos um vídeo com algumas orientações importantes para ajudá-lo a se prevenir. Confira!

O que leva um projeto inacabado ao abandono?

Primeiro, ressaltamos que ninguém começa um projeto com a intenção de não finalizá-lo! Você, cliente, busca um fornecedor que lhe entregue um software finalizado e funcionando adequadamente; e o próprio fornecedor também se propõe a desenvolvê-lo por completo. 

Existem exceções, é verdade, mas, considerando a boa fé dos envolvidos, as pessoas não planejam um projeto inacabado! Então por que existem tantos relatos dessa espécie? Simples: porque a maioria dos fornecedores desenvolve o software com uma única entrega real, deixando os testes de funcionalidades para o final do projeto.

Dessa forma, o cliente (e o próprio fornecedor) só vê o software em funcionamento depois de meses de trabalho, quando já está quase todo estruturado. Então, se surgem bugs (porque é na hora de utilizar a ferramenta que eles aparecem), o projeto já está avançado demais para sofrer mudanças. Assim, a equipe começa a buscar soluções paliativas, que acabam gerando outros problemas e formando um círculo vicioso de projeto inacabado!

Logo, os desenvolvedores percebem a impossibilidade de corrigir as falhas sem reconstruir o software, começam a se esquivar das cobranças do cliente e… somem! Abandonam o projeto! Terrível, não?

Como garantir que o fornecedor entregará o prometido?

Quanto maior o projeto, maiores as chances de surgirem problemas, devido aos níveis de complexidade e de acoplamento do sistema. 

Entende-se por complexidade, o grau de dificuldade de programar neste software em virtude da quantidade de código que precisa ser escrito para alcançar seu objetivo. Já o acoplamento, é a ligação entre certas partes do software, que provoca alterações em áreas que não foram mexidas, quando o programador faz algum ajuste em determinada parte a elas atreladas.

O ideal é reduzir ao máximo a complexidade e o acoplamento do software, no entanto, nem sempre isso é possível. Por este motivo, recomendamos dividir o projeto em pequenas partes inteiras para diminuir riscos e problemas ao fazer ajustes.

Portanto, em vez de aprovar layouts e protótipos estáticos por meses, antes de ver o sistema funcionando, sugerimos desmembrar o software em várias partes inteiras. Assim, as entregas intermediárias do projeto passarão a ser da “coisa real”, do software programado de verdade em áreas específicas de seu sistema. Consequentemente, os bugs que eventualmente surgirem, serão percebidos já nas pequenas entregas e poderão ser corrigidos com mais facilidade e agilidade.

Além disso, a comunicação entre cliente e equipe de desenvolvimento precisa ser fluida e contínua, durante todo o projeto. Até porque, é natural surgirem dúvidas e insights de ambas as partes, que interferem nas decisões relacionadas à construção do software. Por isso, é fundamental o contato direto entre programadores e cliente, para esclarecimento dessas dúvidas e alinhamento de expectativas enquanto há tempo para mudanças estruturais!

É possível salvar um projeto inacabado?

Depende! Um projeto inacabado e abandonado pelos desenvolvedores, certamente alcançou um estágio de problemas insustentável até para seus criadores. Ou seja, tem tantos bugs que, quando mexidos, geram outros bugs, que às vezes nem vale a pena tentar consertar. 

Por outro lado, pode haver partes do software que não estão acopladas àquelas que estão apresentando falhas e que, portanto, não precisam ser alteradas/corrigidas. Neste caso, convém avaliar o custo-benefício de corrigir as partes com problemas para não perder o investimento já feito ou começar tudo de novo.

Então, quando você for contratar um novo fornecedor, tenha bastante cuidado para não terminar novamente com o projeto inacabado! Prefira sempre fornecedores que tenham experiência comprovada, que priorizem a qualidade do código e testes automatizados e que dividam o projeto em pequenas entregas! 

Se precisar de ajuda, entre em contato com a nossa equipe!

Por Joana Kerr

The post Tenho um projeto inacabado que ninguém quer terminar: e agora? appeared first on Visie.

Mas você já parou para pensar no impacto disso? Os números são realmente impressionantes e continuam crescendo em um ritmo acelerado. Todos os dias, bilhões de transações acontecem ao redor do mundo, movimentando cifras que quebram recordes ano após ano.

• No Brasil, atualmente cerca de 85% das pessoas fazem pelo menos uma compra online por mês;

• 62% realizam de duas a cinco compras no mesmo período;

• E a expectativa para 2025 é de um crescimento de 10%, com faturamento estimado em impressionantes R$ 224,7 bilhões. 

Um dado ainda mais impressionante é que 87,5% dos e-commerces brasileiros são pequenos negócios com faturamento de até R$ 5 milhões anuais. Apenas 2,7% pertencem a grandes empresas, o que mostra que os pequenos são a verdadeira força desse mercado.

O desafio das plataformas de e-commerce

Apesar disso, pequenos e médios negócios enfrentam um grande obstáculo: encontrar uma plataforma de e-commerce que atenda às suas necessidades sem pesar no orçamento, que não seja limitada ou complexa demais. Se você já gerencia um e-commerce, provavelmente conhece esse problema. Geralmente, as plataformas mais conhecidas oferecem dois extremos:

1. Planos acessíveis, mas com funcionalidades limitadas e pouquíssima personalização.
2. Soluções robustas e personalizáveis, porém caras e extremamente complexas.

No final, sua loja virtual acaba tendo que se adaptar à plataforma de e-commerce, quando deveria ser o contrário. Você já passou por isso?

A solução: Visie Store

Ao longo dos nossos 19 anos de experiência desenvolvendo e-commerces para grandes marcas como Brastemp e Aramis, entendemos que a realidade de pequenos e médios negócios, como você, é bem diferente. Por isso, decidimos criar a Visie Store: uma plataforma de e-commerce descomplicada, acessível e eficiente, feita para oferecer exatamente o que pequenos e médios negócios precisam para crescer, com a cara da sua marca.

Se você tem desafio parecido, te convidamos a conhecer um pouco mais sobre a Visie Store.

Como funciona a plataforma de e-commerce Visie Store?

A plataforma de e-commerce Visie Store nasceu com o intuito de atender as reais necessidades de pequenos e médios e-commerces, independente do setor de atuação. Seja no ramo de vestuário, jóias, calçados, alimentos, decoração ou qualquer outro mercado, a plataforma foi desenvolvida para oferecer as ferramentas que você precisa para destacar sua loja no ambiente digital.

Se o seu objetivo é crescer e se destacar sem precisar se adaptar às limitações de plataformas tradicionais, então conheça a Visie Store e tire suas próprias conclusões. Com a Visie Store você foca nas vendas e nós cuidamos da tecnologia!

1. Faça uma gestão simplificada

Na Visie Store, tecnologia não será uma dor de cabeça. Criamos uma plataforma que facilita a vida de quem compra e, principalmente, a sua que irá administrar. O painel de controle é intuitivo e repleto de funcionalidades:

• Adicione e edite produtos, categorias e promoções de forma intuitiva;
• Gerencie frete, cupons de desconto e estoque de forma simplificada;
• Além disso, extraia relatórios detalhados para embasar e potencializar suas estratégias de venda.

2. Reduza de barreiras para compra

A experiência de compra do seu cliente é prioridade. Portanto, na Visie Store, o processo é direto e sem complicações:

• Os consumidores podem finalizar suas compras sem a necessidade de criar login ou senha;
• O cadastro é realizado automaticamente no momento em que ele insere os dados de pagamento, eliminando etapas desnecessárias e aumentando as chances de conversão.

3. Apresente resultados inteligentes com a busca fonética

Na Visie Store, os erros de digitação não atrapalham a experiência de compra. A busca fonética identifica o que o cliente deseja, e mesmo que ele digite errado, o resultado de busca apresenta os produtos corretos de forma ágil e inteligente.

4. Que carrega muito rápido 

Sabemos que o desempenho do e-commerce é crucial para o sucesso das vendas. Por isso, a Visie Store garante:

• Carregamento rápido e leve, proporcionando uma experiência fluida e eficiente para os seus clientes, evitando abandonos de carrinho.

Agende uma demonstração gratuita

Que tal agendar uma demonstração para você descobrir mais sobre como a Visie Store pode te ajudar?

📅 Clique no link abaixo para marcar sua demonstração com nossos especialistas:

👉Agendar demonstração

Quer entender melhor? Assista ao vídeo explicativo sobre nossa plataforma.

The post A sua plataforma de e-commerce é limitada ou complexa demais? appeared first on Visie.

No vídeo abaixo, apresentamos algumas alternativas valiosas para ajudá-lo a reduzir consideravelmente o tempo de execução do seu projeto sem comprometer a qualidade da entrega. Confira!

O que fazer quando há um prazo curto demais?

2024 termina e o diretor da empresa percebe que aquele software planejado para gerar mais vendas em 2025 nem chegou a sair do papel! O problema é que os resultados que o gestor pretende mostrar a seu chefe no primeiro semestre do novo ano dependem do funcionamento desse novo sistema!

Diante de tal urgência, o gerente de projetos muda suas prioridades e aposta todos os seus recursos para desenvolver esse software apesar do prazo curto. Assim, organiza a equipe de desenvolvedores para fazer horas extras e a pressiona a produzir na metade do tempo necessário. 

Como consequência, o seu pessoal fica exausto, começa a cometer erros por falta de atenção e, após algum tempo, surgem bugs que geram mais trabalho. Então parte da equipe deixa o que estava fazendo para resolver os novos problemas e atrasa ainda mais a entrega do software. 

E, se tentam reduzir o prazo, evitando corrigir os erros, acabam por entregar um software com problemas de funcionamento, sujeitando a operação a paralisações. Dessa forma, a empresa perde aquelas oportunidades de vendas, comprometendo os resultados que o gestor deveria apresentar ao chefe no final do semestre. 

Percebe como não funciona “espremer” o processo de desenvolvimento de software para cumprir um prazo curto que é insuficiente para o trabalho a ser executado? Mas, como falamos no vídeo acima, é possível reduzir o prazo de entrega respeitando o tempo necessário para o desenvolvimento de cada etapa do projeto! 

Reduza o escopo do projeto conforme o prazo curto de entrega

Se falta tempo para o desenvolvimento do projeto completo, melhor se ater à produção do que é realmente essencial para o funcionamento do software. Esse não é o momento de se demorar em detalhes que não interferem nas funcionalidades do sistema, muito menos de testar novos processos!

Utilize recursos de terceiros para se ajustar ao prazo curto

Nem todas as integrações do sistema precisam ser feitas neste primeiro momento! Há casos em que é possível utilizar recursos externos para atender ao sistema enquanto suas configurações internas ainda não estiverem prontas. Você pode, por exemplo, usar um intermediador de pagamento, enquanto faz sua própria integração aos gateways!

Otimize o tempo com equipes trabalhando simultaneamente

Se você dividir o projeto de software em três e delegar cada parte dessas a uma equipe diferente, o desenvolvimento acontecerá três vezes mais rápido! Para isso, você pode contratar fornecedores que disponibilizam várias equipes, ou até contratar fornecedores diferentes. No entanto, a comunicação precisa ser fluida entre as equipes, visto que isso também impacta nos resultados e cumprimento dos prazos acordados.

Por que é fundamental contar com uma equipe comprometida?

Vale lembrar que, na entrega do sistema, haverá etapas a serem concluídas com o software já em funcionamento, no ambiente de produção! Isso significa que sua equipe contratada precisará continuar trabalhando até a conclusão de todas as pendências.

Ou seja: o prazo curto de que falamos refere-se ao tempo para deixar o software minimamente pronto para entrar em operação. Todavia, os programadores ainda precisarão de tempo e dedicação para concluir o desenvolvimento das partes que puderam ser deixadas para depois. Portanto, sua equipe deve estar comprometida até a finalização de tudo. Caso contrário, todo o cuidado para cumprir prazos mantendo a qualidade da entrega cairá por terra!

Esse processo pode ser trabalhoso e custar mais caro no início, mas resolve o problema de ter um prazo curto, sem comprometer a qualidade. Por isso, se você estiver diante de algum projeto da empresa “para ontem”, considere usar essas estratégias que recomendamos acima! Além disso, se precisar de ajuda para esse processo de desenvolvimento de software da sua empresa, conte com a Visie!

Por Joana Kerr

The post Prazo curto: tenho um projeto para ontem, e agora? appeared first on Visie.

Na prática, quanto maior o investimento na qualidade do desenvolvimento do software, menores são os gastos posteriores. Porém, a maioria das pessoas ignora o TCO durante a fase inicial desse tipo de projeto e acaba perdendo dinheiro na expectativa de economizar!

É sobre isso que falamos neste último vídeo da série: “Riscos financeiros em projetos de software”. Confira!

TCO em projetos de software

TCO (do inglês: Total Cost of Ownership), representa todo tipo de gasto ao adquirir um produto ou serviço. Em projetos de software, entram nessa conta os custos de desenvolvimento, licenças, implantação, hospedagem, manutenção, suporte, treinamento, evolução, funcionamento da operação e quaisquer imprevistos futuros.

Desenvolvimento de software – Os custos do desenvolvimento são, aparentemente, os mais fáceis de estimar, visto que estão contidos no valor orçado pelo prestador do serviço. No entanto, pensar no preço do desenvolvimento isoladamente é uma armadilha, visto que a forma de desenvolver determina as necessidades do projeto a longo prazo.

Licenças de uso – Dependendo do tipo de tecnologia usada no desenvolvimento do seu software, você precisará arcar com taxas de licenciamento e depender do fornecedor para mantê-lo ativo. Consequentemente, além dos gastos diretos com as licenças, sua empresa ficará vulnerável a gastos indiretos com seu fornecedor, como aumento de preço, entre outras variáveis.

Implantação do sistema – O processo de implantação do software pode envolver mudanças operacionais, atualizações em computadores da rede e/ou instalação de nova infraestrutura. Tudo isso precisa ser contabilizado, antes do desenvolvimento, para se certificar da viabilidade de tais investimentos, ponderando o custo-benefício, e se preparar para imprevistos.

Hospedagem escalável – A equipe responsável por um desenvolvimento de software de alta performance deve garantir a capacidade do sistema suportar o uso simultâneo de muitos usuários. Contudo, ela precisa orientá-lo quanto à contratação de uma hospedagem escalável, que molda a disponibilidade dos servidores à demanda de usuários, para evitar gastos desnecessários.

Manutenção e suporte – Um software com código bem escrito, pensado para a manutenção, facilita a execução de eventuais correções e a implementação de novas funcionalidades mais tarde. Além disso, contar com uma equipe comprometida e disponível para esclarecer dúvidas e resolver problemas é fundamental para aumentar resultados, reduzindo tempo e gastos financeiros.

Decisões baseadas no TCO

Em suma, negligenciar a qualidade do desenvolvimento em prol de preços mais baixos, e desconsiderar detalhes do projeto a longo prazo, pode sair muito caro. Porque você pode receber um software com tecnologia pouco conhecida, arquitetura complexa, código mal escrito e com erros, que exigirá mais recursos e mão-de-obra para realizar correções e mantê-lo funcionando.

Então, quando você for construir um software para o seu negócio, analise o todo antes de contratar os fornecedores do seu desenvolvimento! Lembre-se de que um projeto de qualidade requer um investimento maior, mas reduz significativamente os gastos a médio e longo prazos. 

Portanto, durante o planejamento, coloque na ponta do lápis todas essas condições e busque profissionais capacitados para entregar software com alta performance, escalabilidade e com facilidade de manutenção. Afinal, somente investindo na qualidade do software, é possível reduzir o custo operacional do seu projeto (TCO) e, por consequência, aumentar os resultados da sua operação!

Por Joana Kerr

The post Riscos financeiros em projetos de software: ignorar o TCO appeared first on Visie.

Funcionalidade de software comprometida

Um dos primeiros problemas que surgem quando há falhas de qualidade de software, está na capacidade do sistema cumprir a função ao qual foi designado. Isso pode acontecer antes mesmo do projeto ser concluído, se não tiver sido construído adequadamente! Podem surgir bugs na fase de testes e gerar novos gastos com correções.

Isso sem contar os casos em que os problemas de funcionalidade aparecem já durante a operação do cliente, em resultados errados, perda de dados etc! Os riscos financeiros, neste contexto, vão depender do grau de comprometimento da operação em virtude do mal funcionamento do software. Porque já não se trata dos gastos com o sistema, mas com os seus “efeitos colaterais”! 

UX ruim por baixa qualidade de software

Quando falamos em experiência do usuário, estamos lidando com as emoções das pessoas e com a disposição delas para realmente utilizar o software. Se for um aplicativo para uso de clientes, por exemplo, o desconforto ou dificuldade do usuário pode levá-lo a preferir opções da concorrência. Assim, a baixa qualidade de software resultará em perda de dinheiro para o negócio.

Se for um sistema interno de empresa, para uso exclusivo dos seus colaboradores, a experiência de navegação ruim contribui para uma possível queda de desempenho. Até porque, um software criado para simplificar processos internos, que proporciona uma experiência de uso complicada, certamente impacta nos resultados da operação da empresa!

Qualidade de software e o impacto na segurança

A preocupação com qualidade de software também é importante para garantir a segurança, posteriormente, durante seu funcionamento. Isso porque acessos indevidos, vazamento de dados e vulnerabilidades podem causar processos, paralisação de operações internas e perda de clientes. Além disso, com a Lei Geral de Proteção de Dados (LGPD) no radar dos internautas, falhas de segurança em softwares podem acabar com a reputação da empresa!

É claro que a segurança do software também está atrelada a fatores como a hospedagem e configurações de rede e firewalls, porém muitos dos quesitos de segurança dependem de algoritmos expressos em código. Então, se o sistema não for programado, desde o início, para ser seguro, depois ficará muito mais difícil (e caro) corrigir quaisquer falhas de segurança.

No próximo post daremos continuidade ao tema da qualidade de software, considerando os riscos financeiros em casos de má qualidade do código escrito por desenvolvedores. 

Por Joana Kerr

The post Riscos financeiros em projetos de software: qualidade appeared first on Visie.

Essa é uma das grandes dificuldades encontradas na definição de escopo, visto que as soluções costumam ser encontradas/construídas ao longo do projeto de software. Por isso, é habitual trabalhar com um escopo aberto, mas também é comum enfrentar problemas com prazos e gastos imprevistos neste tipo de projeto.

Para ajudá-lo a evitar esse tipo de risco financeiro em projetos de software, preparamos uma série de três artigos e vídeos sobre o tema. Nesta semana, começamos com este, sobre os riscos financeiros na definição de escopo. Depois falaremos dos riscos relacionados à qualidade do software e, posteriormente, traremos informações importantes a respeito do custo total de propriedade.

Planejamento e modelagem de software em detalhes é caro e incerto

Diante das incertezas da definição de escopo no início do projeto, as últimas duas gerações de desenvolvedores se dedicaram a criar métodos extremamente detalhados para planejar o processo de desenvolvimento de software. A exemplo desses, estão a Análise Estruturada e o Processo Unificado. 

Ambos criados para viabilizar a construção de softwares de qualidade, baseados no escopo inicial, prevendo situações e evitando surpresas durante o desenvolvimento. A proposta é criar modelos que orientem o processo de desenvolvimento em todas as fases do projeto, considerando seus requisitos, as necessidades do usuário, as questões técnicas do projeto, os testes e a implantação.

São metodologias muito boas em termos de detalhamento e qualidade de esboço, mas incapazes de prever todas as variáveis do desenvolvimento. Então, quando algo sai do planejado ou dos problemas já previstos (o que quase sempre acontece em algum momento), todo o projeto é comprometido. Consequentemente, todo o trabalho inicial de levantamento de requisitos, planejamento e modelagem de software em detalhes, torna-se disfuncional!

Projetos grandes geram mais imprecisões na definição de escopo

Quanto maior o projeto, maiores os riscos de ter que refazer tudo se não houver aprovação ou se surgirem falhas nas etapas finais do processo. Mesmo que todos os detalhes e variáveis do projeto sejam milimetricamente calculados nas fases iniciais, a chance de ter gastos não previstos, posteriormente, é enorme! 

Por este motivo, entendemos que o mais seguro é dividir qualquer grande projeto em diversos projetos pequenos individuais. Em vez de dividir o projeto em fases que envolvem o todo e apresentar as fases ao cliente, a ideia é trabalhar o todo em cada pequeno projeto de partes diferentes do software, de modo a entregar em prazos menores o sistema pronto. Não todo o sistema de uma vez, mas uma parte específica por vez, sendo entregue de forma real: já desenvolvido, testado e funcionando.

Basear a definição de escopo na “quebra” do projeto reduz riscos

Imagine o valor total de um grande projeto sendo também dividido em partes menores, a serem pagas a cada pequena entrega de software realmente funcionando! Se o projeto for estimado para ficar pronto em 5 meses e for dividido em 10 partes, por exemplo, depois de duas semanas você já recebe algo pronto, tendo desembolsado apenas um décimo do valor total. 

Nesse momento, você provavelmente vai avaliar o que foi entregue e pode ser que queira fazer mudanças. Por ser uma parte pequena do projeto, será mais fácil e barato implementar essas mudanças e, dependendo do caso, sua equipe já saberá dessa sua preferência nos próximos pequenos projetos a desenvolver. O resultado será, a cada entrega, receber um software com mais qualidade e alinhado às suas expectativas.

Bem diferente dos casos em que o cliente passa meses acompanhando o projeto na teoria e, no final do prazo de desenvolvimento, quando recebe o software funcionando, verifica que não era bem isso que estava imaginando! O custo e o tempo necessários para tais ajustes são incomparáveis aos da situação anterior, de “quebra” do projeto em partes menores.

Portanto, na hora da contratação de uma equipe e da definição de escopo para o desenvolvimento do software da sua empresa, negocie considerando pequenas entregas reais! Ainda surgirão imprevistos, mas com certeza você economizará tempo e dinheiro, e ainda terá um software com muito mais qualidade, ao final do projeto!

Por Joana Kerr

The post Riscos financeiros em projetos de software: definição de escopo appeared first on Visie.