Gestão de Projetos: o Escopo, este menosprezado

“Faça para mim”, eu te peço. E a primeira coisa que você, que tem bem mais de dois neurônios certamente  vai perguntar é: “Mas o que você quer que eu faça?”

Parece lógico, não? Então, eu pergunto, por que é tão complicado definir um escopo? A maior parte dos atrasos ocorridos em projetos acontece porque não se tem definição de aonde se quer chegar.  Já imaginaram se a construção de uma casa se desse da mesma maneira que certos GPs conduzem um projeto? Teríamos casas cujas bases são os telhados, as janelas sustentam as paredes e as portas são colocadas na horizontal acima do chão.

A missão de um GP em um projeto é, acima de tudo, manter todos os envolvidos focados no objetivo que se quer alcançar. Ele tem que ter em mente que muitas vezes o cliente sabe o que quer, mas não sabe explicar. Para o cliente, a imagem é muito clara da necessidade que ele quer suprir, mas não é tarefa dele saber COMO traduzir isso para um software. Se fosse, estaríamos desempregados. Por outro lado, os analistas designados para atendimento têm percepções diferentes, vivências diferentes e modos de pensar diferentes do cliente e entre si mesmos. Não somos feitos em formas de bolo, e é justamente aí que residem tanto a maior benesse quanto o maior perigo na condução de um projeto: somos diferentes.

A qualidade principal de um bom Gerente de Projetos é a capacidade de equalizar as diferentes percepções de cada um dos participantes do projeto, e para isso ele tem que ter sempre em mente um escopo muito bem definido de aonde se quer chegar. Metodologias de condução de projetos, como PMI, SCRUM e tantas outras sopas de letrinhas ajudam MUITO no gerenciamento do escopo, mas NADA ainda vai superar o bom e velho BOM-SENSO.
Não é porque o cânone sagrado do PMI fala que você tem que produzir determinado documento que ele será necessário para o sucesso de seu projeto. Se houver consenso e clareza nos papéis, tarefas e objetivos de cada um, você pode dispensar o documento, e você não vai pra cadeia por isso. O que é inadmissível é produzir toneladas de papel sem necessidade prática.

Entenda, JAMAIS dispense a documentação, existe um mínimo necessário para que o projeto transcorra sem (tanta) dificuldade, mas acima de tudo a documentação serve para que o seu sucessor (ou você mesmo) no futuro lembre-se para que serve e como foi criado aquele software. Também não recomendo deixar para fazer a documentação no final, isso normalmente acontece quando todos estão cansados e desgastados demais para se lembrarem de tudo, e com certeza o trabalho será feito somente para cumprir um protocolo, não servindo para nenhuma utilidade prática.

A porcentagem ideal de tempo gasto em desenvolvimento de software, que apurei conversando com GPs amigos, segue o seguinte padrão:

Note que a fase de PENSAMENTO (definição de escopo) deve ocupar mais da metade do tempo de vida de um projeto. Isso reduz o tempo de correção de erros no futuro, porque logicamente uma parede bem projetada não irá cair porque falta uma fileira de tijolos ou a argamassa suficiente.

O GP deve ser um profissional hábil em mediar discussões, em interpretar as diferentes visões do cliente e seus analistas, e conduzir a todos para um objetivo comum, negociado e consensual. Saiba ouvir seu cliente, para que ele e você tenham a idéia clara da necessidade, e saiba comunicar isso para seus analistas para que eles tornem isso realidade. Como se diz por aí, “combinado não é caro”. A falta de definição de objetivos é a principal causa dos atrasos na entrega de projetos, e se o GP tem isso claro e sabe conduzir as necessidades e desejos do cliente e dos analistas, o sucesso é garantido.