Por que a obra entrega e o software não: uma pergunta de 123 mil visualizações

A obra também atrasa. O que muda são três dispositivos: projeto pago antes da execução, aditivo com medição e assinatura, e responsável técnico com nome.

Antes de a primeira peça subir, a estrutura já passou por projeto aprovado e assinatura

A obra também atrasa. Atrasa feio, e quem já respondeu tecnicamente por montagem de estrutura metálica conhece o tamanho do desvio entre o cronograma que foi vendido e o dia em que a inspeção libera o trecho. O que faz a pergunta parecer justa é o papel. Quando a obra derrapa, existe um documento assinado dizendo o que mudou, quem pediu a mudança e quanto ela custa a mais. Em software, a mesma derrapada chega na reunião com o nome de imprevisto.

Uma pergunta de 2012 no Software Engineering Stack Exchange já foi vista 123.583 vezes, tem score 543 e juntou 31 respostas: por que a indústria de TI não entrega projetos grandes e sem falha rápido, como as outras indústrias. A maioria das respostas fala de estimativa, de complexidade essencial e de requisito que muda. Tudo verdade, e nada disso é o que separa as duas indústrias. O que separa são três dispositivos de contrato, nenhum deles técnico: o projeto executivo aprovado e pago antes de a execução começar, o aditivo com medição e assinatura toda vez que o escopo muda, e um responsável técnico com nome de gente respondendo pela estrutura.

O canteiro derrapa igual, e o desvio aparece na medição do mês

Mudança de escopo em obra tem orçamento, prazo novo e alguém assinando embaixo

Montagem de fábrica de cimento. Um trecho de estrutura que estava previsto para nove dias levou perto de três semanas porque a peça chegou com a furação fora de posição e o guindaste ficou parado esperando. Chuva, fornecedor, retrabalho de solda. Nada disso é exclusividade de software.

A diferença é que aquele desvio virou linha no boletim de medição daquele mês. O cliente viu a quantidade montada, viu o que não subiu e viu o motivo, antes de o cronograma inteiro estourar. Quando chegou o fim do contrato, ninguém precisou explicar o atraso: a explicação tinha sido construída em pedaços, com assinatura em cada um.

No seu projeto de software acontece o contrário. O status fica verde até o mês da data prometida, o gráfico de atividade sobe, e a conversa difícil acontece uma vez só, tarde, quando já não sobra decisão para tomar. É por isso que a obra que atrasou uns 20% passa por normal e o software que atrasou os mesmos 20% passa por fracasso. Um foi medido no caminho, o outro apareceu pronto no fim. Vale conferir se o seu acompanhamento mede trecho montado ou só cronograma bonito com card se mexendo.

Na obra, o projeto sai antes e custa dinheiro

Antes de a primeira máquina entrar no terreno, existe projeto executivo aprovado, disciplinas compatibilizadas entre si e licença emitida. A prancha diz o perfil de cada peça, a furação, o tipo de solda. O montador não decide no lugar do projetista, ele executa o que já foi decidido e conferido.

Esse projeto é uma linha do orçamento, não um brinde. Ninguém no canteiro chama isso de burocracia.

Em software, a fase equivalente é a descoberta somada ao desenho de arquitetura e ao que o time precisa abrir por dentro antes de estimar. Quase todo cliente quer essa fase embutida na proposta, sem preço, resolvida numa call de uma hora. A frase que sustenta o arranjo é sempre a mesma: a gente descobre no caminho. Descobrir no caminho, no canteiro, tem outro nome, e ele envolve demolir parede pronta.

Quando eu tinha uma startup de locação de equipamentos, eu era o cliente dessa história. Contratei dev sem conseguir julgar prazo e sem entender com profundidade o que me diziam. A sprint terminava sem a entrega esperada e eu colocava a culpa no time. Faltava planta, e eu não sabia o suficiente para sentir falta dela. Algumas perguntas antes de assinar teriam me poupado uns meses.

Mudança de escopo com medição, número e assinatura

Em software, a mesma mudança entra na sprint como ajuste e some do contrato

Na obra, o cliente muda de ideia o tempo todo. Ele troca o layout do galpão depois da fundação, pede mais uma ponte rolante, resolve subir o pé direito. Existe um caminho para isso, e ele é chato de propósito: pedido de alteração, orçamento, novo prazo, assinatura. Só depois a equipe encosta na peça.

O aditivo protege os dois lados. Protege o cliente porque o preço da mudança aparece antes, e protege o fornecedor porque a data se move junto com o escopo.

Já peguei o outro extremo. Um cliente contratou uma plataforma de cursos e, com o projeto andando, passou a exigir experiência de streaming, com o faturamento parado como alavanca de negociação. Cada reunião trazia uma tela nova, sempre apresentada como ajuste. Terminou em rescisão, com parte do que já tinha sido entregue sem pagamento. Meses depois ele voltou, ouviu o valor justo, achou absurdo e foi para outro fornecedor. O projeto morreu por lá. Conto isso pelo aprendizado: o defeito estava no contrato que a gente assinou, não nas pessoas da sala.

Em software, o aditivo cabe em duas linhas de e-mail. Toda mudança aprovada vira uma ordem de serviço com faixa de esforço, impacto no prazo e um aceite escrito antes de entrar na sprint. Sem isso, mudança de escopo vira favor, e favor não tem data.

"Mas requisito de software muda o tempo todo, é diferente"

É a objeção honesta, e ela erra no alvo. A obra também muda. O que a obra não faz é fingir que a mudança não vai acontecer: o mecanismo de alteração já nasce dentro do contrato, com fórmula de reajuste e critério de medição.

O contrato de software faz o oposto. Ele congela um escopo que ninguém consegue congelar, e depois trata cada alteração como conversa de reunião. Aí a mudança acontece do mesmo jeito, só que sem preço e sem prazo novo.

A alteração vai chegar de qualquer forma. A pergunta é se ela passa por número e data antes de entrar na sprint, ou se entra de lado, apresentada como ajuste. E o produto não para de mudar no dia do aceite: ele continua vivo depois da entrega, e o contrato precisa dizer quem paga por isso no mês seguinte.

Quem assina embaixo da estrutura tem nome de gente

Respondi tecnicamente pelas estruturas metálicas do Autódromo de Interlagos. Não era título, era responsabilidade pessoal registrada em papel: se a estrutura falhar, existe um nome, e o nome é meu. Isso muda o que você aprova, o que você recusa e a hora em que você para a montagem.

No seu contrato de software, quem assina é um CNPJ. O engenheiro que desenhou a solução no kickoff pode não estar no seu repositório no quarto mês, e o contrato permite. Ninguém está agindo de má fé, só não existe nome amarrado à estrutura.

Dá para corrigir sem inventar conselho profissional: escreva no contrato quem responde pela arquitetura, quem revisa o que entra em produção e o que acontece quando essa pessoa sai do projeto. Se o fornecedor travar nessa cláusula, você aprendeu bastante em quinze minutos. Uma checagem curta no fornecedor costuma revelar o resto.

O vilão é o preço fechado com escopo elástico

Juntando as três coisas, sobra um culpado, e ele é o modelo de contratação. Preço fechado paga o fornecedor por terminar. Escopo elástico dá ao cliente o direito de empurrar ideia nova para dentro sem mexer no número. Os dois na mesma folha criam um incentivo perfeito para entregar casca podre: teste que roda sem nenhum expect, endpoint de health devolvendo 200 com painel colorido em cima de dado vazio. Por fora, completo. Sob a estrutura, nada.

O fornecedor tira o que o contratante não sabe avaliar. Isso no melhor dos casos, quando não há má intenção nenhuma.

Três cláusulas que mudam esse jogo na próxima proposta:

• Pague a fase de projeto separada da execução, com entregável escrito, para que a estimativa da obra nasça de algo que alguém abriu por dentro.
• Combine que toda mudança de escopo gera uma ordem de serviço com faixa de esforço e novo prazo, aceita por escrito antes de entrar na sprint.
• Coloque nome de pessoa na responsabilidade técnica e defina o que acontece com o projeto quando essa pessoa sai.

Repare que nenhuma delas fala de tecnologia, e nenhuma delas depende do valor da hora. A hora é a única linha que as duas propostas escrevem do mesmo jeito, e por isso ela vira o critério errado de decisão. Se quiser conferir a faixa de mercado antes de comparar, ela está na nossa tabela de valores.

Onde essa comparação quebra

A obra tem norma técnica, código de obras, fiscalização e um conselho profissional que cassa registro. Software não tem nada disso, e não vai ter tão cedo. Quem promete disciplina de canteiro para um produto digital está vendendo mais do que consegue entregar.

Tem outro limite, e ele é honesto: em produto novo, ainda procurando cliente, escopo fechado é péssimo mesmo. Ali o caminho é ciclo curto com medição frequente, não papel grosso. Não sei se essas cláusulas valem para um time de três pessoas antes da primeira receita, porque o custo do processo pode passar o custo do retrabalho que ele evita.

Para o resto, faça a conta hoje. Pegue o último projeto que estourou o prazo, conte quantas vezes o escopo mudou e conte quantos documentos alguém assinou por causa dessas mudanças. Se o segundo número for zero, o atraso não foi imprevisto. Ele foi o combinado.