O Que E Escopo Do Projeto

O problema que ninguém anuncia

Você já viu um projeto sair dos trilhos porque o cliente decidiu que "era óbvio" que aquela funcionalidade extras estava inclusa? Isso acontece todos os dias. O escopo do projeto existe exatamente para evitar essa situação, mas a maioria das pessoas trata como um documento burocrático em vez de uma ferramenta de proteção. Escopo é simplesmente a descrição detalhada do que será entregue e, mais importante, do que não será entregue. Sem isso, você tem um projeto que nunca termina porque nunca há consenso sobre o que significa "terminado".

o que e escopo do projeto na prática

O escopo se divide em duas partes principais: o escopo do produto, que descreve as características e funcionalidades do entregável final, e o escopo do projeto, que abrange todo o trabalho necessário para produzir esse entregável. Uma coisa não depende automaticamente da outra. Você pode ter um produto simples com um projeto extremamente complexo por trás. No meu caso, fiz uma consultoria para uma empresa que queria um sistema de relatórios automatizado. O escopo do produto parecia simples: dashboard com cinco gráficos e exportação em PDF. O escopo do projeto, porém, envolvia integração com três sistemas legados que ninguém documentava, migração de dados de uma base que tinha campos obsoletos e um período de testes de quatro semanas. O cliente achava que seriam seis semanas no total. Levou dezoito. O problema não era a complexidade técnica, era que ninguém havia definido explicitamente o que estava fora do escopo no início. A regra básica é: escreva o escopo com nível de detalhe suficiente para que duas pessoas diferentes chegarem ao mesmo entendimento do que está incluído e do que está excluído. Se um membro da equipe precisar perguntar "isso tá dentro ou fora?", o escopo está mal escrito.

Como construir um escopo que funciona

O processo mais direto começa com a identificação dos entregáveis. Liste tudo que precisa existir no final do projeto. Depois, para cada entregável, especifique os critérios de aceitação: condições mensuráveis que precisam ser satisfeitas para que o cliente aceite formalmente. Isso elimina a subjetividade. A seguir, defina as exclusões. Esta é a parte que a maioria das pessoas pula. Escreva explicitamente o que o projeto NÃO inclui. "Não inclui treinamento dos usuários finais." "Não inclui customização para outros idiomas." "Não inclui manutenção pós-entrega." Essas afirmações valem mais do que qualquer descrição positiva. Depois vem a estrutura analítica do projeto, ou WBS. Ela decompõe cada entregável em pacotes de trabalho menores até chegar em atividades que podem ser estimadas com razoável precisão. A decomposição deve continuar até que cada elemento seja grande o suficiente para ser gerenciado e pequeno o suficiente para ser estimado. Na prática, isso costuma significar pacotes entre 40 e 80 horas de trabalho. Menos que isso gera microgerenciamento. Mais que isso esconde riscos.

Por fim, valide o escopo com todas as partes interessadas antes de começar qualquer execução. Reúna clientes, equipe técnica, gestores e qualquer outro stakeholder. Faça cada um revisar o documento e assinar. Isso não é formalidade, é prevenção de conflito. Um documento assinado custa minutos e economiza semanas de discussão depois.

Onde a maioria erra

O erro mais comum é tratar o escopo como algo fixo e intocável. Em metodologias ágeis, o escopo é naturalmente mais flexível porque os requisitos evoluem durante o projeto. O que não muda é a necessidade de ter clareza sobre o que está sendo feito em cada iteração. Scrum lida com isso através do product backlog priorizado e do scope definido em cada sprint. Kanban funciona com limitadores de trabalho em progresso. O princípio é o mesmo: decisões sobre escopo devem ser explícitas e documentadas, não assumidas. Outro erro frequente é confundir escopo com cronograma. Escopo responde "o quê". Prazo responde "quando". Orçamento responde "com quanto". São variáveis diferentes que se influenciam mutuamente, mas são coisas distintas. Quando alguém pede para "entregar mais rápido" sem ajustar o escopo, você não está lidando com uma questão de tempo, está lidando com uma mudança de escopo disfarçada. Trate como tal. O problema do escopo mal definido é cumulativo. Um detalhe omitido no início gera retrabalho na execução, que gera atraso, que gera pressão por atalhos, que gera qualidade comprometida. Em projetos de TI, estimei que cerca de sessenta por cento dos problemas de entrega estão raiz em escopo mal definidio. Os outros quarenta por cento são problemas técnicos reais.

Uma solução alternativa quando o escopo não cabe na caixa

Se você está em um ambiente onde os requisitos são genuinamente incertos desde o início e não há como definir um escopo detalhado antes de começar, considere frameworks como o Lean Startup ou modelos contratuais baseados em valor entregue em vez de escopo pré-definido. Projetos de pesquisa e desenvolvimento frequentemente funcionam melhor assim, pois o objetivo é descobrir algo que ainda não se sabe se existe. Nesses casos, tentar forçar um escopo tradicional é inútil e contra-producente. Também existe o caso em que o cliente insiste em um escopo fechado mas se recusa a assinar. Nessa situação, o melhor caminho é documentar por escrito todas as incertezas e assumidos, enviar para confirmação e criar um registro de que o escopo apresentado foi o melhor entendimento disponível na data. Se o cliente não contestar, você tem uma base. Se contestar depois, você tem evidência de que a divergência aconteceu em determinado momento. A ferramenta para escrever o escopo não importa tanto quanto o conteúdo. Planilha, documento de texto, ferramenta de gestão de projetos, quadros visuais. O que importa é que o documento exista, seja acessível e seja referenciado durante todo o projeto. Uma versão desatualizada do escopo é pior que nenhum escopo, porque cria uma falsa sensação de controle.