Se você já passou pela experiência de fechar um contrato com uma consultoria de dados, ver o projeto andar por alguns meses e chegar ao final com a sensação de que o que foi entregue não era bem o que você tinha em mente, saiba que esse sentimento tem um nome técnico: desalinhamento de escopo.
O resultado aparece lá na frente, quando o projeto entrega algo que é tecnicamente correto mas operacionalmente inútil. Ou quando o prazo estoura porque ninguém havia mapeado que aquele dado dependia de uma integração que levaria três meses para ser feita. Ou quando a discussão sobre o que significa “dashboard entregue” começa só depois que o fornecedor emitiu a nota fiscal.
Este artigo resolve isso antes do contrato. Se você está prestes a iniciar um projeto, use o que segue como um checklist de sobrevivência.
Por que 60% dos projetos de dados falham
Existe uma percepção comum de que projetos de dados falham por problemas tecnológicos. A ferramenta escolhida era a errada. O banco de dados não suportava o volume. A integração era mais complexa do que parecia.
Esses problemas existem, mas raramente são a causa raiz do fracasso. O que os estudos do setor mostram, e o que qualquer profissional com algum histórico de projetos vai confirmar, é que a maioria dos fracassos começa muito antes do primeiro sprint de desenvolvimento. Começa na reunião de kick-off, quando o escopo ainda é vago o suficiente para que cada lado da mesa entenda uma coisa diferente.
Objetivo de projeto sem critério de sucesso definido. Entregável descrito em termos de atividades em vez de resultados. Prazo definido sem levar em conta as dependências de dados que a empresa precisaria fornecer. Esses são os padrões que se repetem, independente da tecnologia, do fornecedor ou do setor.
Entregáveis versus atividades: a diferença que muda tudo no contrato
Leia qualquer proposta de consultoria de dados e você vai encontrar uma lista de atividades. Levantamento de requisitos. Modelagem do banco de dados. Desenvolvimento dos dashboards. Treinamento da equipe. Homologação.
A diferença parece sutil até que o projeto termina e você percebe que todas as atividades foram executadas mas o resultado não é o que você precisava. O fornecedor pode, com razão, dizer que fez tudo o que estava no contrato. Você pode, com razão igual, dizer que não recebeu o que esperava. Ambos estão certos. E o problema é o contrato.
Um entregável bem definido tem três características: é específico, é verificável e tem um responsável. Em vez de “desenvolvimento dos dashboards”, o contrato deveria dizer “três dashboards operacionais para as áreas de vendas, financeiro e logística, com as métricas listadas no anexo A, atualização diária, acessíveis via navegador sem instalação de software adicional, validados e aprovados pelos gestores de cada área”. Isso é um entregável. O restante é uma atividade.
Os 5 elementos de um bom escopo de dados
Um escopo bem estruturado não precisa ter cinquenta páginas. Precisa ter cinco elementos. Se algum deles estiver faltando, o projeto tem uma lacuna que vai se manifestar em algum momento da execução, geralmente no pior momento possível.
Objetivo de negócio. Não o objetivo técnico, mas o problema de negócio que o projeto está resolvendo.
Entregáveis específicos. Listados com o nível de detalhe descrito acima.
Prazo com dependências mapeadas. O prazo não pode ser definido sem antes mapear o que o projeto precisa receber de outras áreas.
Dependências internas e externas. Separadas do prazo porque merecem um olhar específico. Dependências internas incluem disponibilidade do time de TI, acesso a sistemas, e tempo dos gestores para validação.
Critérios de aceite. O elemento mais negligenciado e o mais importante.
Como definir critérios de aceite técnicos
“Dashboard entregue” não é um critério de aceite. É uma frase.
Um critério de aceite técnico responde a perguntas concretas. O dashboard está acessível a todos os usuários listados no contrato? Os dados estão atualizando com a frequência definida? As métricas foram validadas pelos gestores responsáveis e batem com as fontes de origem? O tempo de carregamento é inferior a X segundos? Existe documentação suficiente para que a equipe interna consiga fazer ajustes simples sem depender da consultoria?
Cada um desses pontos precisa estar no contrato, com resposta binária. Sim ou não. Atende ou não atende. Isso não é desconfiança do fornecedor. É o mecanismo que protege os dois lados de uma discussão que ninguém quer ter depois que o dinheiro mudou de mão.
Um critério de aceite bem escrito também define quem valida e em quanto tempo. Se o gestor tem sete dias para testar e aprovar cada entregável, isso precisa estar no contrato. Caso contrário, o projeto pode ficar travado na fase de homologação indefinidamente, sem que nenhuma das partes tenha clareza sobre o próximo passo.
Marcos e checkpoints para projetos de 3 a 6 meses
Projetos de dados raramente são lineares. O que parecia urgente para o negócio muda de prioridade no terceiro mês. Sem marcos intermediários, o projeto vai acumulando desvios silenciosos até que a entrega final revela tudo de uma vez.
Para projetos de três meses, o recomendado são três marcos formais além do kick-off e da entrega final. Um ao final do primeiro mês para validar o diagnóstico de dados e os requisitos levantados. Um ao final do segundo mês para revisar os primeiros entregáveis em versão preliminar. E um na semana anterior à entrega final para o aceite formal.
Para projetos de seis meses, adicione um marco de revisão estratégica no meio do projeto, em torno do terceiro mês, onde o objetivo de negócio é revalidado. Não para mudar o contrato, mas para garantir que o que está sendo construído ainda faz sentido para o momento da empresa. Projetos longos são particularmente vulneráveis à perda de relevância porque o negócio continua evoluindo enquanto o projeto avança no seu próprio ritmo.
Em cada marco, duas coisas precisam acontecer: uma revisão formal dos entregáveis até aquele ponto, e uma avaliação explícita dos riscos para os próximos meses. Esse é o tipo de disciplina que separa projetos que entregam dos que surpreendem negativamente.
Red flags em escopos de fornecedores
Você recebeu a proposta. Agora leia com atenção e procure o que não está lá.
Objetivo descrito em linguagem técnica sem conexão com negócio. Se a proposta fala em “construir um data lake escalável com camadas bronze, silver e gold” mas não explica qual problema de negócio isso resolve, é um sinal de que o fornecedor está propondo uma solução antes de entender o problema.
Lista de atividades no lugar de entregáveis. Já discutimos isso. Se o escopo descreve o que eles vão fazer mas não o que você vai receber, peça que reescrevam.
Prazo sem dependências mapeadas. Um cronograma que não menciona o que depende do cliente é um cronograma incompleto. Quando as dependências aparecerem durante o projeto, e vão aparecer, o fornecedor vai ter argumentos legítimos para renegociar prazo e custo.
Ausência de critérios de aceite. Se a proposta não descreve como cada entregável será validado, pergunte. Se a resposta for vaga, peça que seja incluída formalmente.
Suporte pós-entrega não especificado. O que acontece depois que o projeto é encerrado? Existe um período de suporte incluído? Bugs de implementação têm custo adicional? Sem essa clareza, você pode acabar pagando para corrigir problemas que deveriam ter sido previstos.
Para aprofundar os critérios de avaliação de propostas, vale ler o guia completo de como escolher uma consultoria de dados que a beAnalytic publicou com um framework de oito critérios ponderados.
Template de escopo básico
Segundo o Project Management Institute, em seu Pulse of the Profession, projetos com escopo bem definido desde o início têm 2,5 vezes mais chance de serem entregues dentro do prazo e do orçamento. O dado não é específico para dados, mas a lógica se aplica diretamente: clareza no início poupa retrabalho, renegociação e frustração no final.
Antes de assinar, valide o escopo
A pressão para começar logo é real. O fornecedor quer fechar. Você quer entregar. O board está esperando resultado. Mas o tempo investido em validar o escopo antes da assinatura é o melhor investimento que você pode fazer no projeto.
Não estamos falando de semanas. Uma sessão de trabalho bem conduzida de três a quatro horas com o fornecedor e os stakeholders internos é suficiente para revisar os cinco elementos, alinhar os critérios de aceite e identificar as dependências que estavam escondidas.
Projetos de dados são complexos por natureza. Mas a complexidade gerenciada com um escopo claro é muito diferente da complexidade que emerge de um contrato vago assinado com pressa.
A diferença entre os dois costuma ser algumas horas de trabalho chato no início. E meses de tranquilidade depois.
Gabriela Melo é estrategista de conteúdo na beAnalytic, especializada em SEO e GEO. Com foco na criação de conteúdos otimizados para posicionar temas de Business Intelligence e Engenharia de Dados.
- Gabriela Melo
- Gabriela Melo
- Gabriela Melo
- Gabriela Melo
