A Importância do Detalhamento do Escopo

A definição do que deve ser feito no projeto, ou seja, a definição do escopo é crucial. Essa definição está ligada ao objetivo do projeto e seu detalhamento tem impactos na duração e no custo do projeto.

 

De modo geral, no método waterfall (queda dágua ou cachoeira), o projeto é feito em etapas sucessivas, e não passamos para a etapa seguinte sem que a etapa anterior seja completada. A definição do escopo é feita na etapa inicial. Na etapa de planejamento – que vem depois – o escopo é detalhado e decomposto em entregas. Ainda no planejamento é estabelecida a ordem que as entregas serão executadas, sendo isso registrado em um cronograma. Em seguida, o escopo é executado, entrega após entrega, na ordem definida no cronograma. Cada passo do projeto é devidamente monitorado e controlado, da primeira até a última entrega, até que todas as entregas - que representam o escopo do projeto - sejam feitas. A imagem da queda dágua (waterfall), não exatamente de água, mas de etapas “caindo”, ou melhor, se sucedendo, representa uma forma de como fazer as coisas e trabalhar, que se traduz no método mais tradicional de se gerenciar um projeto.

Todos dizem que as mudanças em um projeto são inevitáveis, não importando a metodologia de gestão que adotem. Se uma organização adota o waterfall, o escopo do projeto é, de certa forma, protegido das tentativas de mudança. As mudanças de escopo, antes de serem implementadas, precisam ser formalmente aprovadas. Geralmente, essa aprovação passa pelo “sponsor” do projeto. Em projetos de maior porte, é usual consultar um grupo de pessoas com autoridade para tomar decisões sobre o projeto e preparadas para analisar as solicitações de mudanças, chamado de comitê de controle de mudanças. O comitê de controle de mudanças analisa uma solicitação de mudança e investiga se é possível fazer a mudança, os benefícios da mudança, quais são os riscos, quanto tempo vai demorar, quanto vai custar e o que justifica a aprovação. Com base nisso, a solicitação de mudança pode ser aprovada ou rejeitada.

Vejamos abaixo alguns exemplos que mostram a necessidade de analisar uma mudança no escopo do projeto, antes de sua implementação de fato.  

·         O projeto de desenvolvimento de um novo carro, com 15 meses de duração, feito pela montadora XYZ Motors, cujo escopo especifica o uso de um motor de 1.600 cilindradas de potência. Suponha que alguém da equipe técnica, depois de 8 meses do início do projeto, e já próximo a fase de testes do primeiro protótipo, descobre que seria melhor ter usado um motor diferente, de 2.000 cilindradas de potencia. O projeto já está muito adiantado e a mudança do motor resultaria em atraso e significativo aumento de custos. Sendo assim essa mudança não é aprovada.

·         A obra da construtora XYZ, que está erguendo um edifício de 8 andares, com 26 meses de duração. Suponha que alguém do departamento comercial, após 5 meses do inicio da obra, está solicitando uma mudança no escopo do projeto que alteraria a quantidade de andares de 8 para 12, além de outras implicações como, por exemplo, alterações na área destinada as vagas de garagem. A empolgação do pessoal do departamento comercial se deve a confirmação da venda de 90% das unidades em tão pouco tempo. O projeto está progredindo conforme indicado no cronograma original, e as fundações do edifício já foram concluídos. Essas fundações não suportariam mais 4 pavimentos, isso sem contar com o atraso no cronograma e no aumento de custos que uma mudança dessa natureza representaria. Essa seria uma mudança inviável e, por isso, não aprovada.

·         O projeto de criação de uma nova linha de produção da empresa XYZ Injeção de Plásticos, com duração de 6 meses. O escopo original do projeto especificava uma máquina injetora com capacidade para injetar volumes entre 326 e 622 centímetros cúbicos. Passada a primeira metade do cronograma, um colaborador do departamento de engenharia industrial notou que a pressa em iniciar logo o projeto gerou equívocos na análise de requisitos e teve como consequência a especificação incorreta da máquina injetora. Esse funcionário propôs uma mudança de escopo do projeto e apresentou evidências que indicavam que a nova máquina injetora deveria ter capacidade para injetar volumes maiores, entre 432 e 896 centímetros cúbicos. Nessa altura do projeto, o fornecedor da máquina injetora já tinha sido escolhido e a compra concluída. Assim sendo, como o equívoco (na especificação da máquina injetora) foi descoberto somente depois da compra (da máquina originalmente especificada), essa mudança não foi aprovada.

·         Um projeto de abertura de uma nova filial da rede de lojas XYZ, com duração de 8 meses, incluindo várias entregas como, por exemplo, autorização do município, obtenção de financiamento, compra de um prédio antigo, reforma desse prédio, instalação de móveis, contratação de pessoal, treinamento de pessoal, dentre outras entregas. O prédio antigo foi escolhido em função de seu tamanho e localização, sendo considerado apropriado pela área de marketing e capaz de receber todos os departamentos da loja, gerando o volume de vendas previsto. Depois de alguns meses de iniciado o projeto, com base em uma novíssima pesquisa de mercado, a área de marketing decidiu solicitar uma mudança no escopo do projeto que tinha como principal implicação a necessidade de um prédio bem maior do que o originalmente adquirido. Acontece que o prédio antigo já tinha sido comprado e a reforma iniciada. Por isso, a mudança solicitada foi rejeitada.

·         Um projeto de desenvolvimento de software para gerenciamento de bancos de dados, com duração de 3 meses. Estando o projeto no seu terço final, um dos programadores sugeriu o uso de novos “plug-ins XYZ”, pois isso tornaria o trabalho de programar mais ágil.  Um “plug-in” de software é um programa usado para adicionar funções a outros programas maiores. Todavia, seria obrigatório verificar como resolver algumas incompatibilidades presentes nesses “plug-ins” (gerando a necessidade de tempo extra e custos adicionais). Além disso, mais da metade das funcionalidades já tinha sido desenvolvida naquele momento. Por conta disso, a solicitação de mudança não foi aprovada.

Os projetos não são compostos por atividades totalmente independentes. Ao contrário disso, na maioria das vezes, vemos que existe algum tipo de dependência entre as atividades do projeto. Então, o timing é crucial em muitos tipos de projetos, em que vencidas certas etapas torna-se muito difícil voltar atrás com as escolhas e decisões já tomadas e refazer o que já está feito. Por isso, a definição do escopo do projeto é vital e, consequentemente, é recomendada a adoção de um processo que trate do controle integrado de mudanças.

 

As mudanças de escopo no método SCRUM são tratadas, digamos, de uma forma um pouco diferente.  As mudanças são consideradas como inevitáveis (isso não é diferente) e a equipe do projeto deverá estar preparada para lidar com elas de forma adequada (saber como lidar com as mudanças, aceitando-as na maior parte das vezes, é que faz toda a diferença). Mas, será que é mesmo assim? Bem, o SCRUM é um método ágil de gerenciamento de projetos, no qual o projeto é feito em “rodadas” mais curtas, que são chamados de sprints. Os sprints duram de 2 a 4 semanas! Uma atividade importante no SCRUM é o planejamento desses sprints, no qual são definidas as tarefas que deverão ser executadas naquele período de 2 ou 4 semanas. No SCRUM o produto a ser criado pelo projeto é representado no product backlog. Na terminologia do SCRUM, o product backlog é uma lista detalhada de tudo o que precisa ser realizado para transformar a visão do produto em realidade. O product backlog (tudo que precisa ser feito) é subdividido em pedaços que são executados nos sprints. Portanto, nesses sprints serão executadas partes do produto que o projeto está criando. Desse modo, sprint após sprint, do primeiro ao último, cada parte do produto vai sendo executada, até que todo o produto tenha sido criado. Se, após um determinado sprint, alguém decide que não ficou bom, o trabalho poderá ser refeito. Serão apenas 2 ou 4 semanas, certo? Sim, desde que isso não se repita com frequência. Afinal, se isso começar a ocorrer com frequência, teremos muito trabalho desperdiçado, e ninguém quer que isso aconteça!

Alguns autores acreditam que os métodos ágeis de gerenciamento de projetos, como o SCRUM, são mais apropriados em projetos urgentes e complexos, como o desenvolvimento de software. Outros entendem, e defendem, que o SCRUM pode ser usado em qualquer tipo de projeto. Já vi em alguns dos sites de empresas que vendem programas de software de gerenciamento de projetos baseados em SCRUM que esse método está sendo aplicado em diferentes tipos de indústrias, embora não seja dito claramente que tipos de projetos foram desenvolvidos nessas indústrias. Me parece óbvio que se uma montadora de automóveis, um laboratório farmacêutico, uma indústria de alimentos ou qualquer outra indústria manufatureira usa o SCRUM para desenvolver ou implantar um software, esse é um projeto de software. Ponto!

Eu tenho procurado projetos diferentes daqueles relacionados ao desenvolvimento de software feitos com o SCRUM, mas ainda não encontrei. Se você leitor desse blog identificar algum projeto feito com SCRUM que seja diferente do desenvolvimento de software, por favor, compartilhe conosco, enviando um comentário. Não faço isso por ser contra ou a favor dos métodos ágeis de gerenciamento de projetos, mas porque entendo que o SCRUM é um método interessante e que deve ser estudado e aprofundado. O gerente de projetos não deve ter um comportamento de torcedor de time de futebol (a favor do Waterfall e contra o SCRUM, ou vice-versa). Deve buscar o conhecimento para usá-lo da melhor forma possível, em favor do projeto e da organização que implementa e patrocina o projeto.    

A minha conclusão é que se estamos trabalhando com partes ou blocos independentes de um projeto ou, em outras palavras, quando a mudança em um bloco não afeta outros blocos, será possível refazer tarefas ou modificá-las com mais facilidade. Mesmo assim, as mudanças custam dinheiro e precisam ser gerenciadas. Por outro lado, em projetos com blocos dependentes, se um pedido de mudança é feito agora, que pode afetar algo feito antes, isso tem impacto no trabalho como um todo e, por conta disso, será muito mais difícil implementar tal mudança.