O “escopo do projeto” é o trabalho que deve ser realizado para se obter um produto ou serviço com determinadas características e recursos. Comece por definir o que deve ser feito e o que não deve. Esse processo nos permite entender os contornos do projeto e traçar uma linha divisória entre o que deve ser feito e o que não deve ser, pelo menos neste momento. Muitos novatos se perdem em discussões intermináveis sobre recursos do produto final que o tornariam “perfeito”.
Sempre me lembro de um amigo muito experiente que, ante a minha ânsia em acertar todos os detalhes logo de cara, me dizia que “o ótimo é inimigo do bom”, ou seja: enquanto perseguimos o “ótimo” nos distanciamos de algo que está bem mais próximo, o “bom”, é que temos mais chance de conseguir atingir. Com o tempo achei uma forma elegante de contornar as exigências de projeto sem decepcionar os clientes: não é que não faremos o que está sendo pedido, mas devemos ver que este recurso cabe na versão 2, 3, etc… mas não cabe na versão 1, que é o que estamos tentando desenvolver neste momento ! Afaste o fantasma da perfeição.
Um dos grandes segredos do gerenciamento de projetos é proteger o seu escopo. Projetos que ficam mudando o escopo durante sua execução têm sérias dificuldades em cumprir o cronograma e estouram o orçamento. O risco mais comum é o que se chama de “scope creep”, quando o escopo vai crescendo a medida que o cliente vai entendendo suas necessidades e reformulando seus objetivos. Há quem chame este problema de “Jacques”. Seria uma homenagem a um francês ilustre ? Não, trata-se apenas da forma como o cliente costuma abordar o assunto: “já que o sistema faz isso, ele pode então fazer aquilo. Agora eu quero aquilo também incorporado ao projeto.”
O gestor do projeto deve ter calma e analisar com cuidado cada demanda: ao rejeitar um pedido, ele pode se indispor com o cliente, mas se aceitar ele pode estar dando um tiro no próprio pé, já que o prazo e orçamento não serão tão “elásticos” quanto as exigências. Devemos sempre contar com uma certa “margem de manobra”, mas nos tempos atuais, em que eficiência é a palavra que está na ordem do dia, não há muita “gordura para queimar” e os compromissos assumidos pelo gerente podem se transformar num sacrifício, muitas vezes desnecessário, para toda a equipe.
Em projetos de software, o inchaço do escopo ou scope creep é uma situação tão comum que não dá para começá-los sem tomar algumas precauções. O primeiro cuidado é negociar a forma de remuneração: fixa ou variável. Se for fixa, o risco das mudanças está toda com o gerente do projeto, se for variável, o cliente assume os custos extras. Mesmo neste caso, o gerente do projeto deve cuidar para que o cliente seja informado a priori dos novos custos. Por precaução, eu sempre redijo um adendo ao escopo colocando o que será feito, em quanto tempo e a que custo. Colho a assinatura do cliente e só depois autorizo a execução da tarefa. Gerentes financeiros não participam destas reuniões e podem alegar que não há previsão de recursos para os extras, então mantenha-os informados das novas condições para evitar dissabores na hora do recebimento.
O segundo cuidado é documentar meticulosamente o escopo do projeto. Este documento resume o que será feito, com que características e com que recursos. Ele é um “quase-contrato” mas não traz as cláusulas de rescisão e as penalidades. Neste momento, tudo está bem e todos concordam. Só que, na cabeça de cada um, há uma imagem diferente do que será o produto final. Á medida que este produto vai tomando forma e sendo entregue, o cliente vai vendo que o que ele imaginou “não é bem aquilo” e podem começar as decepções.
A satisfação do cliente depende em muito do que será dito e prometido no que se chama de “pré-venda”. É neste momento que o gerente de projetos deve entrar em cena para meticulosa, cuidadosa e disciplinadamente escrever tudo o que o sistema deve ter e fazer. Este processo é o “planejamento de escopo” e num software dele abrange das telas até os relatórios. Esta tarefa pode ser delegada para um analista, mas a responsabilidade não sai nunca das mãos do gerente. Eu costumo especificar toda a interface dos usuários com o sistema: telas e relatórios. Depois de “colocar tudo no papel”, o gerente deve obter do cliente um “de acordo”, de preferência assinado no final do documento em que todas as páginas serão rubricadas com um “visto” para que ele tome ciência do que será feito. Não há palavras para expressar a importância deste planejamento em que as expectativas serão levantadas e moldadas, de forma que, diante do produto final, o cliente não possa se dizer decepcionado.
O terceiro cuidado é definir prioridades. O gerente deve ter a sensibilidade para identificar quais são os requisitos obrigatórios e quais os desejáveis, marcando cada um segundo com a sua prioridade. Isso evita que alguém arbitre o que é importante no lugar do cliente. Há gerentes de projeto que vão mais longe e pedem ao cliente para definir o que ele considera “sucesso” do projeto. Por exemplo, num sistema em que havia desperdício de 30% da matéria-prima, foi considerado sucesso reduzir esta taxa para 15%. Mas este número ainda é alto, diria você. Sim, mas o cliente considerou que uma redução de 50% dos desperdícios já representaria benefícios suficientes que compensariam os investimentos no projeto. Além do mais, lembre-se de que: “o ótimo é inimigo do bom”.
Em suma: definir o escopo, no fundo, é saber o que deve ser feito para atender a necessidade do cliente.
