Escopo aberto e o porque nós não negociamos qualidade

Você com certeza já passou por aquela frustração de receber um projeto com nenhuma qualidade, entregas atrasadas ou até mesmo gastar horas e horas corrigindo bugs de funcionalidades que foram lançadas.  

E se eu te falar que todas essas frustrações tem um motivo? E o motivo se chama ESCOPO FECHADO. Sim, ele mesmo, o escopo fechado tem sido o vilão principal na grande parte dos projetos digitais da última década, saiba como contornar esses problemas utilizando o escopo aberto.

Pilares de um projeto de software

Todo software possui 4 pilares: escopo, qualidade, prazo e custo. Qualquer negociação envolvendo um projeto sempre é embasada nesses 4 pilares, mesmo que de maneira implícita, por exemplo:

• O projeto 1 será entregue em uma data X, pelo preço Y contento o escopo Z, nesse ponto, estamos esquecendo de um pilar muito importante, a qualidade.

• O projeto 2 vai ser entregue em uma data X, pelo preço Y, com a qualidade Z, deixando o escopo aberto, para que possamos entregar o que mais gerar valor para o cliente no tempo estipulado.

No primeiro caso estamos fixando o valor, o preço e o escopo do projeto, deixando a qualidade implícita, a critério de quem está desenvolvendo.

Nem preciso falar que a manutenção desse projeto vai ficar cada vez mais complicada né? Aumentando exponencialmente o preço e o prazo para ser entregue.

Estimativas nem sempre são assertivas

O ser humano tem o vício de supor coisas e imaginar que tudo sairá bem. Bom, tenho uma péssima notícia para te dar, elas não sairão.

Historicamente, todo projeto atrasa, pois as suposições iniciais não condizem com a realidade em tempo de projeto.

Precisamos começar a tratar estimativas como o próprio nome sugere, são uma hipótese, do que irá acontecer, se acertarmos, ótimo, se não, resolvemos. E não tem nada demais nisso, precisamos parar de tentar prever tudo o que irá acontecer no projeto e nos preparar para resolver os problemas em tempo hábil.

Nós não sabemos o que o usuário quer (E você também não)

Quantas vezes você já viu projetos gigantes e milionários sendo feitos e quando vão a público não agradam. Pois bem, as pessoas também tem o péssimo hábito de acreditar que sabem tudo o que o usuário precisa/quer.

A literatura prova que precisamos iterar sob essas suposições e corrigir o curso do projeto enquanto o mesmo avança. O famoso conceito de MVP.

Do que adianta um projeto dentro do custo e prazo se ninguém usa?

Os custos implícitos no escopo fechado

O risco é muito grande para o fornecedor do projeto no escopo aberto, dessa maneira, sempre que um projeto é orçado o time coloca uma margem para garantir que a estimativa seja assertiva. Dessa maneira, projetos super interessantes que poderiam ter sido colocados em prática são inviabilizados.

Além de que a maioria das funcionalidades concebidas no início do projeto não são utilizadas, então imagine a quantidade de horas que você poderia economizar testando funcionalidades em lançamentos quinzenais. Muita coisa, né?

Diferença entre um projeto de escopo fechado e um projeto de escopo aberto

Para um projeto de escopo aberto funcionar é preciso muita parceria e transparência. Reuniões semanais e conversas diárias tem de ser rotineiras para que esse tipo de projeto funcione. Dessa maneira, o time consegue se adequar às mudanças que surgem durante o projeto, contribuindo para o sucesso do produto.

Uma metáfora muito utilizada pelo pessoal de agilidade – e que particularmente eu gosto muito – é a do táxi, vou exemplificar.

Imagine que você tem que entregar um documento importante para seu chefe, que está do outro lado da cidade de São Paulo, aguardando – ansiosamente – pela chegada desses documentos. E o pior, em horário de pico.

Pois bem, você contrata um taxista para levar esses documentos até o seu chefe, o homem te diz que levará 1 hora para levar os documentos até o seu chefe, e o custo será de R$ 200,00. Você dá os documentos para o taxista e relaxa, esperando que os documentos sejam entregues.

2 horas depois – lembra, não somos bom em estimar coisas – o seu chefe te liga desesperado perguntando dos documentos. Já irritado com a situação você liga para o taxista e ele te diz que está parado no trânsito, que o pneu dele furou, brigou com um motoqueiro e que por conta de tudo isso a corrida ficará R$ 400,00.

Como bom brasileiro você já desconta toda sua raiva no homem e presume que o mesmo está te roubando.

Nesse caso você tem duas opções, pagar os R$ 400,00 e arcar com o prejuízo, ou cancelar a corrida, perder os documentos e deixar seu chefe ainda mais desesperado e com raiva. Ou seja, não tem solução boa né?

E é aí que entra a grande questão, se você estivesse no táxi, junto com o motorista? Além de comprovar todos os problemas que o taxista enfrentou, você poderia ter sugerido outros caminhos que conhecia ou mesmo encerrar a viagem de táxi no meio do caminho e sair andando com os documentos para entregar ao seu chefe. E se mesmo assim não desse tempo, você teria a certeza de que apesar de ter gasto mais tempo e custado muito mais, foi feito o possível para cumprir o combinado.

Essa é a grande diferença entre um projeto de escopo fechado e um projeto de escopo aberto, transparência e confiança são necessárias para tirar grandes produtos digitais do papel.

Nós não negociamos qualidade

Se você ainda não se convenceu sobre como um projeto de escopo aberto tem as melhores chances de conceber um produto digital, ai que vai o argumento final.

Qualidade, alguns tópicos acima falamos sobre os 4 pilares de um projeto e como esquecemos da qualidade quando fechamos o escopo.

Dado todas os argumentos anteriores, fica claro que o ser humano não é capaz de estimar um projeto de software com clareza, então, quando tiver perto do prazo final, quem você acha que é atacada, para que as coisas saiam na data combinada?

Se você chutou qualidade, acertou. Gambiarras, código sem testes, código fora do padrão e muitas outras coisa são liberadas quando um projeto está próximo de sua data limite.

Você já parou para contabilizar o quanto isso afeta na manutenção futura? E se o projeto continuar no escopo fechado é pior ainda, pois é maior a margem de segurança (gordura) que o desenvolvedor coloca nas próximas estimativas, inflando ainda mais o custo.