Escopo Fechado: Receita De Fracasso

2017/09/12

Quando questionado por clientes se haveria uma forma de fechar o escopo de um projeto maior que 20 horas, dessa forma limitando a interação em uma entrega única já com os requisitos definidos por ele, geralmente nossa resposta é: “isso nunca vai funcionar; ou se funcionar, vai sair bem caro”.

Sinto muito, mas não trabalhamos dessa forma. Já tivemos várias experiências ruins no passado em que o cliente jurava de pé junto que o escopo estava fechado e detalhado no máximo, mas na hora de desenvolver a história foi muito diferente. Isso não é falha de projeto, é como desenvolvimento de software funciona.

Agora, se você, como cliente, preferir trabalhar em um modelo mais tradicional, é possível sim levantar todos os requisitos. Mas imagine o drawback: já seriam cobradas as horas do levantamento como horas de trabalho (sem nada entregue), sairia mais caro pois demoraria o dobro do tempo e eu te asseguro que cobraríamos o triplo de horas, para nossa segurança (já que o cliente também quer ter a segurança do lado dele).

O que funciona melhor, de acordo com nossa experiência, acaba sendo uma combinação de elementos da metodologia ágil: estimamos o backlog de vocês e com isso as entregas semanais (ou uma frequência desejada, mas com tempo curto). Haverá uma interação mínima entre o gerente de projeto de nosso lado e um ponto focal do lado de vocês para verificar o progresso e modificar o backlog se necessário.

O risco que os clientes geralmente imaginam do escopo aberto será diluído conforme o desenvolvimento avança, permitindo tomar decisões muito rapidamente antes que a entrega vá por água abaixo. Um escopo fechado é um risco para ambos os lados e que não compensa para nenhum deles. Essa foi a nossa conclusão depois de muitos projetos fracassados. Portanto, se você pretende fracassar com seu projeto, segue a dica: use escopo fechado.

Facebook | Twitter | Linkedin | Google