Conhecer a Nextside →
PT-BREN
CTRL K
    PT-BREN

    Escopo de projeto: 5 furos por onde ele estoura

    Escopo de projeto não estoura porque o cliente pede demais. Estoura em 5 furos que ninguém fechou no briefing. Nenhum deles é sobre tecnologia.

    TL;DR

    Escopo de projeto quase nunca estoura porque o cliente é abusado. Estoura porque ninguém escreveu o que significa “pronto” de um jeito que dá pra conferir depois. Scope creep, o escopo que cresce sozinho durante o projeto, é sintoma. A doença é combinado vago. A pegadinha: escopo fechado demais também quebra, porque cliente muda de ideia por ter aprendido alguma coisa, não por má fé. O que funciona é entrega curta, critério de aceite escrito e uma porta aberta com preço.

    Por que o escopo estoura (e não é porque o cliente é chato)

    O escopo estoura quando o combinado descreve aparência e não comportamento. “Formulário de orçamento no site” é uma frase que todo mundo aprova na reunião e ninguém consegue conferir na entrega, porque tudo depende do que acontece depois que alguém aperta enviar. Sem essa parte escrita, cada lado imagina uma coisa diferente. A diferença só aparece na entrega.

    Acho que essa é a parte mais mal compreendida da relação entre agência e cliente. O cliente não está tentando levar vantagem quando pede “só mais uma coisinha”. Ele está descrevendo pela primeira vez uma coisa que sempre esteve na cabeça dele e que ninguém perguntou. Do lado dele, aquilo não é pedido novo. É esclarecimento do que ele achava óbvio.

    Pedido fora do escopo quase nunca chega em forma de pedido. Chega como pergunta (“mas não dá pra ver quem preencheu?”), como espanto (“ah, isso não vai pro e-mail do vendedor?”) ou como silêncio incômodo na reunião de entrega. Quando você percebe, já está negociando de graça.

    “Mas está no briefing.” Está o nome da coisa. O comportamento dela não está.

    Os 5 furos por onde o escopo escapa

    Quando um projeto de ferramenta estoura prazo e margem, eu aposto nestes cinco furos. Todos aparecem antes da primeira linha de código, todos são baratos de fechar no papel e nenhum deles tem relação com o time ser bom ou ruim. É trabalho de escrita, não de tecnologia.

    • “Pronto” nunca virou frase testável. O briefing diz “calculadora de frete funcionando”. Funcionando para quem, com quais faixas de CEP, mostrando o quê quando o CEP não existe? Enquanto “pronto” for um adjetivo, ele significa uma coisa pra você e outra pro cliente, e quem paga a diferença é a sua margem.
    • O briefing descreve tela, e o projeto é regra. Layout é a parte visível e a mais fácil de aprovar. O trabalho de verdade está no que acontece por baixo: quem recebe o lead, o que é campo obrigatório, o que o sistema faz com duplicado, quem consegue ver o histórico. Tela aprovada com regra em aberto é escopo em aberto.
    • Integração entrou como adjetivo. “Integrado com o CRM” é meia linha na proposta e pode ser semanas de trabalho, porque depende de qual CRM, de qual plano dele, se tem acesso liberado, o que fazer quando a conexão cai e quem descobre que caiu. Adjetivo não é item. Item tem nome, dono e teste.
    • Ninguém combinou quem aprova. Três aprovadores que discordam entre si transformam cada entrega em enquete. Cada rodada de opinião nova reabre decisão que já estava fechada, e reabrir decisão é o jeito mais caro de trabalhar que existe.
    • O “depois a gente vê” não tem lista. Toda conversa produz item adiado. Se o adiado não vai pra uma lista escrita, com nome e ordem, ele volta no fim do projeto fantasiado de “isso a gente combinou no começo”. E aí é a sua palavra contra a memória do cliente.

    Repare: NENHUM dos cinco é sobre tecnologia. Os cinco são sobre combinar por escrito o que as duas partes acham que já combinaram.

    O que escrever no lugar antes de assinar

    Fechar escopo não é escrever um contrato mais duro. É trocar adjetivo por frase que dá pra conferir. Cinco movimentos resolvem os cinco furos, e nenhum deles exige que você entenda de programação. Exige uma tarde de perguntas chatas antes de o projeto começar, e não durante.

    • Escreva “pronto” como um teste. Em vez de “formulário funcionando”, escreva “ao enviar o formulário, o lead aparece na planilha X e o vendedor Y recebe um e-mail em até um minuto”. Isso é critério de aceite: uma frase que qualquer pessoa consegue conferir sem opinião. Se ninguém consegue dizer sim ou não olhando a tela, a frase ainda está vaga.
    • Liste o que NÃO entra. A lista do que fica de fora vale mais que a lista do que entra, porque é ali que mora a expectativa não dita. “Não inclui login de cliente, não inclui relatório, não inclui integração com o sistema de emissão de nota.” Parece agressivo na hora de mandar. É bem menos agressivo do que a conversa que você teria sem ela.
    • Trate cada integração como um item com nome. Uma linha por sistema, com o nome do sistema, quem consegue o acesso e o que acontece quando ele estiver fora do ar. Integração é a única parte do projeto que depende de terceiro, e terceiro não responde ao seu cronograma.
    • Nomeie uma pessoa que aprova. Uma. As outras opinam, ela decide. Coloque o nome dela na proposta, junto com o prazo de resposta. Sem dono, aprovação vira rodada de comentário.
    • Abra a fase 2 no dia 1. Crie a lista do que fica pra depois antes de o primeiro item ser adiado. Quando um pedido novo aparecer, ele não é recusado nem aceito de graça: ele entra na lista, com esforço e preço próprios. Isso transforma uma discussão de relacionamento numa decisão comercial.

    O ponto dos cinco é o mesmo: pedido novo não deveria ser um problema, deveria ser um item. Na Nextside a gente faz isso virar mecanismo em vez de boa intenção, porque cada entrega tem critério de aceite escrito antes e você paga só a parte que aceitou funcionando.

    Onde isso quebra

    Agora o outro lado, porque escopo apertado demais tem um preço próprio. Combinado rígido entrega a coisa errada no prazo certo.

    O primeiro jeito de quebrar é congelar decisão cedo demais. Em projeto de ferramenta, muita coisa só fica clara quando existe algo pra clicar. Se o combinado proíbe qualquer mudança, você entrega exatamente o que foi escrito e assiste o cliente descobrir que não era aquilo que ele precisava. Entregar a coisa errada no prazo certo continua sendo entregar errado.

    O segundo é usar o escopo como arma. Responder “isso não estava no contrato” resolve a discussão de hoje e envenena a relação. O cliente aprende que falar com você custa caro, para de falar e leva o próximo projeto pra outro lugar. Ganhar a conversa e perder a conta é um péssimo negócio.

    O terceiro é confundir escopo fechado com projeto longo. Quanto maior o pedaço combinado de uma vez, maior a chance de ele estar errado quando ficar pronto. Fatia curta com critério de aceite claro erra pouco e corrige barato. Fatia grande com critério vago erra caro e corrige pior.

    “Eu não vou brigar com o cliente por um pedido pequeno.” Nem precisa. Pedido pequeno com preço combinado não vira briga, vira aditivo de uma linha.

    O que você vende quando fecha o escopo direito

    Escopo escrito não protege você do cliente. Protege os dois da conversa que ninguém teve. O cliente também odeia descobrir no fim que a ferramenta não faz o que ele imaginava, e ele odeia mais ainda quando percebe que teria bastado alguém perguntar antes.

    Agência que fecha escopo direito não vende só a ferramenta. Vende uma coisa mais chata e mais cara: a certeza de que o “pronto” dela e o “pronto” do cliente são a mesma frase. É por isso que ela tem argumento pra cobrar melhor, porque o cliente não está pagando por horas de alguém, está pagando pra não ter surpresa.

    Escopo aberto não é generosidade. É uma conta que chega depois, sempre no seu bolso.

    FAQ

    O que é scope creep em projeto de software?

    Scope creep é o crescimento do escopo durante o projeto, sem revisão de prazo, preço ou prioridade. Em geral não nasce de um pedido grande, e sim do acúmulo de ajustes pequenos que parecem óbvios para o cliente e nunca foram escritos. O sintoma clássico é a entrega que atrasa sem ninguém saber apontar quando começou a atrasar.

    Como saber se o escopo de um projeto está bem fechado?

    Pegue cada item combinado e pergunte se dá pra dizer sim ou não olhando a tela pronta, sem depender de opinião. Se a resposta exigir interpretação, o item ainda está aberto. Escopo bem fechado tem lista do que não entra, um nome por integração e uma pessoa responsável por aprovar cada entrega.

    O que fazer quando o cliente pede algo fora do escopo?

    Não recuse nem aceite de graça. Registre o pedido na lista de próxima fase com esforço e preço próprios e devolva a decisão pro cliente. Isso tira a conversa do campo pessoal e coloca no campo comercial, onde ela deveria estar desde o começo. Pedido com preço vira escolha, e não cobrança.

    Escopo fechado engessa o projeto?

    Engessa quando o pedaço combinado é grande demais e a mudança é proibida. Não engessa quando as entregas são curtas e existe um caminho combinado para pedidos novos entrarem. O objetivo não é impedir mudança, é fazer com que toda mudança tenha prazo e preço visíveis antes de virar trabalho.

    Quem deve escrever o escopo: a agência ou o cliente?

    A agência escreve, o cliente confirma por escrito. Cliente costuma descrever o que quer ver, e cabe a quem entrega traduzir isso em comportamento verificável e devolver pra validação. Quando o cliente escreve sozinho, o texto vem em forma de desejo. Quando a agência escreve sozinha e não valida, vem em forma de suposição.

    Leia também