Um dos maiores problemas em projetos de sistemas é o escopo de software. O que é para fazer, o que é para não fazer, de que jeito fazer etc.
Sempre tem o cliente que acha que pediu mais do que o fornecedor entendeu, e sempre tem o fornecedor que acha que o cliente pediu menos do que desejava pedir, dentre outras divergências.
A melhor forma de não deixar o combinado “nas entrelinhas” é escrevendo isso, e formalizando. Combinado não sai caro, mas quando o assunto é escopo de software, o combinado é o que está especificado.
Escopo de Software é o principal “contrato” do projeto
Quando falamos de Escopo de Software estamos falando do “contrato de fato” do projeto, ou pelo menos, do objeto deste contrato.
Num contrato se tem condições comerciais, premissas e restrições do ponto de vista legal, financeiro etc.
Mas quando o assunto é Escopo de Software, contratos pertinentes geralmente carregam apenas um visão “preliminar disso”, principalmente pelo problema do Cone da Incerteza.
Essa visão preliminar muitas das vezes é uma “verdade”, mas que vai mudar quando o projeto começar a acontecer.
Especificar e ter provas do que foi solicitado
O combinado não sai caro. Mas o que é o combinado?
Fechar um acordo de centenas de horas de trabalho com base em um telefonema é algo viável? Assumir que entendeu um e-mail com dez linhas e gastar dezenas de horas fazendo algo erro é plausível?
Veja neste vídeo um breve trecho de um Hangout com nossos alunos do nosso curso de Engenharia de Requisitos, onde abordamos brevemente essa problemática.