Seu projeto de tecnologia pode fracassar antes do primeiro código

Helene Bellier
5 Min de leitura
Jean Pierre Lessa e Santos Ferreira

Especialista em tecnologia, software e inteligência artificial, Jean Pierre Lessa e Santos Ferreira avalia que os riscos que derrubam projetos raramente são técnicos na origem. O paradoxo é conhecido: equipes dominam a ferramenta e, ainda assim, entregam tarde, caro ou algo que ninguém usa.

A explicação está no lugar para onde se olha. Planos de risco costumam listar falhas de servidor, atrasos de fornecedor e erros de código. São ameaças reais, mas visíveis, e por isso recebem atenção. As que causam mais estrago ficam em áreas que ninguém considera responsabilidade da tecnologia.

Esses riscos silenciosos se repetem em empresas de portes e setores muito diferentes, do varejo ao sistema financeiro. Reconhecê-los cedo muda a conversa sobre prazo e orçamento, porque permite tratar como decisão aquilo que, mais tarde, aparece como surpresa.

Patrocínio frágil e objetivo difuso

O primeiro risco é o projeto sem dono no negócio. Quando o patrocinador delega tudo à área de tecnologia, cada dúvida de requisito vira reunião sem decisão, e o time passa a adivinhar prioridades. O cronograma escorrega sem que nenhum marco pareça ter falhado.

Um objetivo vago agrava o quadro. “Modernizar o atendimento” não diz o que precisa melhorar nem como medir. Já “reduzir pela metade o tempo de resposta ao cliente” orienta escolhas de arquitetura, define o que fica fora e mostra, ao final, se o investimento valeu.

Integrações e legado subestimados

Um novo aplicativo de pedidos parece simples até precisar conversar com estoque, faturamento, logística e cadastro de clientes, cada um com sua regra e sua janela de atualização. A integração, que ocupava uma linha no plano, consome boa parte do esforço real.

Jean Pierre Lessa e Santos Ferreira conduziu integrações tecnológicas de diversas aquisições e múltiplas viradas de ERP, cenário em que esse risco aparece com força. Sistemas antigos carregam regras não documentadas, e só quem já operou a rotina sabe por que determinado campo existe.

Jean Pierre Lessa e Santos Ferreira
Jean Pierre Lessa e Santos Ferreira

A mitigação passa por mapear dependências antes de estimar, testar integrações nas primeiras semanas e envolver quem conhece o legado desde o início. Descobrir uma incompatibilidade no primeiro mês custa ajustes; descobri-la na homologação custa o prazo.

Construir ou comprar sem critério claro

Jean Pierre Lessa e Santos Ferreira observa que a escolha entre construir e comprar é uma das decisões mais caras de um projeto, justamente por parecer apenas técnica. Desenvolver internamente o que o mercado já resolve bem consome times que poderiam criar diferencial competitivo.

O erro inverso também custa. Comprar uma solução pronta para um processo que é o coração do negócio prende a empresa ao ritmo do fornecedor. O critério útil separa o que diferencia a operação, que merece construção própria, do que é comum a todo o setor.

Dados ruins e conhecimento concentrado

Iniciativas de inteligência artificial e machine learning herdam um risco adicional: o modelo só é tão bom quanto os dados que o alimentam. Bases duplicadas, campos preenchidos de formas diferentes e históricos incompletos produzem previsões que parecem precisas em teste e falham em produção.

Outro risco silencioso é a dependência de poucas pessoas. Quando só um especialista entende a arquitetura, um período de férias ou um pedido de demissão paralisa decisões. Documentação viva, revisão de código em par e rodízio de responsabilidades distribuem o conhecimento antes que ele faça falta.

Quando o assunto é IA em escala, Jean Pierre Lessa e Santos Ferreira considera que qualidade de dados e formação das equipes pesam tanto quanto o algoritmo escolhido. A experiência à frente de times de dados e machine learning reforça essa leitura de que o risco mora na operação, não no modelo.

O risco que ninguém coloca na planilha

Existe um ponto comum a todos esses riscos: nenhum deles aparece como falha isolada. Eles se acumulam em pequenas concessões: uma reunião sem decisão aqui, uma integração adiada ali, até que o atraso pareça ter surgido do nada.

Por isso, gerir riscos em tecnologia é menos uma questão de prever catástrofes e mais de cultivar atenção ao que parece pequeno. Projetos que chegam ao fim no prazo não tiveram menos problemas, apenas os enxergaram antes de se tornarem inevitáveis.

Compartilhe esse artigo
Deixe um comentário

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *