23/05/2007

Controle o seu escopo

Muitas vezes nos damos conta e comentamos, surpresos, sobre a nossa tendência a complicar determinadas atividades simples em nossa vida. Eu, particularmente, também me surpreendo com o contrário: como diversos passos simples que demandam quantidades relativamente pequenas de esforço podem descomplicar nossa vida e salvar nosso dia a dia profissional.

Quantos projetos você conhece (e talvez até já tenha participado) que falharam e cujo fracasso poderia ter sido evitado com um planejamento correto e controle adequado? Eu, particularmente, já vi esse filme várias vezes, e surpreendentemente, na maior parte das vezes isso ocorreu devido à falta da ferramenta mais básica de qualquer projeto: o controle de escopo.

Mas, afinal, o que é o escopo do seu projeto? De uma forma simples e direta, o escopo do seu projeto significa "até onde ele vai". Na definição do PMBoK (uma das "bíblias" do gerenciamento de projetos) o conceito do gerenciamento de escopo significa: "garantir que o projeto inclua todo o trabalho necessário e somente o trabalho necessário". Note como os dois termos são importantes. Tão importante quanto garantir, desde o início, que você está contemplando em seu planejamento (isto é, no seu orçamento, no seu cronograma, no seu estudo de recursos e em todo o resto) tudo que precisa ser feito, é certificar que esteja exposto de forma explícita para todos os interessados o que o projeto não vai abrangir.

O problema é que nem sempre isto fica claro, e quanto mais técnica for a área de atuação do projeto mais complicado ele se torna (a área de tecnologia é um perfeito exemplo dos segmentos que apresentam este problema).

É bastante comum ver softwares sendo completados que possuíam um propósito para a equipe de desenvolvimento e outro para o cliente. Quem da área de desenvolvimento nunca passou por isso? Imagine um diálogo típico (surreal, mas infelizmente realista):

Cliente: "Este relatório não está do jeito que eu pedi!"

Analista: "Está sim, foi o que você definiu para mim naquele e-mail. Eu retornei sua requisição explicando quais campos seriam os campos mestre, quais seriam os campos detalhe e como as totalizações seriam feitas."

Cliente: "Não adianta falar essa linguagem comigo, eu não sou Bill Gates. E quem vai fazer o cadastro dos 5000 itens do meu estoque?"

Analista: "O sistema foi entregue para você operacional. Vocês vão fazer o cadastro."

Cliente: "O quê? Você vai me entregar o sistema vazio? E quanto ao controle de férias dos funcionários que eu não achei onde estava no menu?"

Analista: "Mas pensei que ficou claro que isso não estaria nesta versão do sistema!"

...continua indefinidamente ou até o primeiro enfartar...

Este é um problema real de gerenciamento de escopo. Não ficou claro para os envolvidos o que está incluído no trabalho do executor e o que não está. É normal da parte de um cliente, leigo na área, incluir funcionalidades não previstas em um software porque este não é treinado para possuir a abstração tecnológica de um analista de sistemas. O problema é que estas funcionalidades a mais geram custo, e alguém tem que pagar. É aí que o conflito começa.

Então como administrar seu escopo? A solução deste problema inicia com o correto gerenciamento de stakeholders (aqueles indivíduos diretamente envolvidos no projeto ou diretamente impactados pelo seu resultado) e passa pela documentação, formalização e disseminação do escopo do projeto. Muitas vezes esses importantes passos são ignorados frente à tendência ainda existente de enxergar o planejamento como perda de tempo; na verdade, a tendência moderna do gerenciamento de projetos é passar cada vez mais tempo planejando em relação ao tempo de execução do projeto (em muitos projetos o tempo de planejamento é igual ou chega ser superior ao de execução). O tempo "gasto" planejando revela-se tempo "ganho" no futuro.

Um primeiro passo importante para a correta administração de escopo é identificar os seus stakeholders , ou seja, quem são. Os stakeholders incluem o gerente do projeto, a equipe, o cliente (aquele que utilizará diretamente o produto do projeto - este nós costumamos chamar de usuário) e outros indivíduos relevantes no seu contexto de trabalho. Muitas vezes nossa falha é justamente não saber quem são nossos stakeholders, ou não identificar suas necessidades e expectativas. Envolva-os no projeto! Estabeleça relações com eles, procure compreender suas motivações, interesses e objetivos, se possível até mesmo aqueles que não são explicitamente ditos a você. Quanto mais cedo você fizer isso mais estará protegido do diálogo infeliz citado acima. Acontece frequentemente (principalmente em grandes organizações) que alguns deles nem sequer sabem que serão afetados por um projeto seu, e um stakeholder desconhecido pode surgir no meio da execução de um projeto e mudar grande parte dos seus objetivos. Tente sempre que possível resolver os conflitos entre stakeholders a favor do cliente do projeto, e tente fazer isso o mais cedo possível (de preferência ainda na fase de planejamento), garantindo que o escopo esteja limpo e claro para todos os interessados.

Vale lembrar que outro grande fator para o sucesso de seu projeto é a comunicação com estes indivíduos: mantenha-os informados periodicamente da posição atual, performance e mudanças relevantes no projeto. Para isso um simples relatório de status semanal costuma ser suficiente (liste de forma resumida as atividades que ocorreram no projeto durante a semana e as mudanças de interesse). Um pequeno passo como esse dá uma sensação de visibilidade e de participação no projeto para os stakeholders que pode ser crucial no futuro.

Uma vez que a necessidade de seus stakeholders foi compreendida, formalize-a, ou seja, documente tudo. Acordos verbais não são interessantes num ambiente de projeto: as pessoas tendem a sofrer de memória seletiva quando as coisas dão errado. O PMBoK define três documentos ligado ao escopo do projeto: a carta de abertura ou project charter (que também atua como uma espécie de "certidão de nascimento" do projeto, ou seja, o documento que oficializa sua existência - pretendo falar mais sobre a iniciação de um projeto em artigos futuros), a declaração de escopo ou scope statement e a estrutura analítica do projeto (EAP), também conhecido como work breakdown structure (WBS). Estes documentos registram e tornam claro para todos qual é o trabalho do projeto, através de uma visão orientada a entregas .

Entregas são itens tangíveis e verificáveis que representam de alguma forma o progresso do projeto. Por exemplo: podemos considerar num projeto de geração de website o mapa do site como uma entrega da fase conceitual, e cada página como uma entrega da fase de execução. Cada uma dessas páginas pode ser formada por diversas entregas menores como figuras, textos e animações.

De uma forma bem geral (sem nos aprofundarmos nos detalhes destes documentos), registramos, na carta de abertura, os objetivos gerais e uma descrição textual do produto do projeto com o máximo de informações apuradas até o momento, bem como a sua justificativa, ou seja, quais necessidades este projeto foi criado para satisfazer. Com base no estudo técnico deste documento, geramos uma declaração de escopo indicando quais são as entregas principais do projeto e quais critérios mensuráveis aplicaremos a elas para considerar o projeto bem sucedido (ou seja, informações qualitativas acerca destas entregas).

Por fim, decompomos estas entregas principais em todas as sub-entregas que precisamos gerar para que estas existam. O documento que representa esta decomposição é a estrutura analítica do projeto (ou WBS). Segue um exemplo muito simplificado de um WBS de um website:



Mas até que nível nós devemos definir as entregas? Não existe uma regra, mas tenha como um padrão um nível em que é economicamente interessante controlar o andamento do projeto. Por exemplo, num projeto de realização de um livro, podemos colocar o livro no primeiro nível da EAP, os capítulos no segundo, os tópicos no terceiro e parar por aí. Poderíamos continuar a definir novos níveis na EAP (por exemplo, definir todos os parágrafos do livro), mas estaríamos criando um projeto muito custoso e difícil de controlar, sem contar que estaríamos restringindo demais a atuação da equipe planejando em excesso o produto antes da execução.

No momento em que seus documentos estiverem definidos, formalize a influência dos stakeholders, ou seja, permita que eles avaliem e validem estes documentos, de preferência com assinaturas. Após conseguir que o escopo se torne consenso entre todos os envolvidos, você estará pronto para executar este projeto e protegido por um escopo clarificado e aprovado. O que não quer dizer que ele não possa mudar, mas agora qualquer requisição de escopo que não consta nos documentos validados pode ser considerada oficialmente um pedido de mudança no projeto e administrada como tal. Veremos com profundidade do processo de gerenciamento de mudanças em um projeto numa oportunidade futura.

A correta compreensão e planejamento do escopo de um projeto são os primeiros passos para todos os outros planejamentos e muitas vezes os mais cruciais. Espero que este guia simplificado ajude a aumentar a percepção da sua importância, e, acima de tudo, o salve no futuro de ser o analista ou o cliente do diálogo acima.