Cada vez mais nos deparamos com atrasos em projetos de software, ou projetos entregues com má qualidade ou ainda aqueles que são interrompidos no meio do caminho porque o dinheiro gasto já não será mais recuperado. As empresas em alguns casos atuam como aquele time de futebol, quando tudo vai ruim, culpa-se o treinador, no meio empresarial o Gerente de Projetos é o alvo das organizações que por melhores metodologias que apliquem, seja ágil ou tradicional, não percebem que aquilo que vão construir, testar e entregar deve ser extremamente pensado e delimitado criando assim algo de valor, algo que agregue para seus clientes.
Em muitos contextos, temos as questões relativas ao ambiente organizacional da empresa. Qual ambiente a empresa está inserida, qual o contexto de negócio? Nestes cenários a entropia permite o não entendimento daquilo que deve conter e aquilo que deve ficar de fora de um projeto. Como então em ambientes onde há falta de preparo por parte dos gestores, a má aplicação de metodologias e ferramentas e um ambiente organizacional caótico, pode-se construir um produto que atenda as expectativas dos clientes.
Um dos pilares do Gerenciamento de Projetos, o Gerenciamento de Escopo, que já fez parte de uma chamada restrição tripla, que hoje em dia podemos sem sombra de dúvidas chamá-la de restrição sêxtupla, pois fazem parte (Escopo, Custo, Tempo, Qualidade, Recursos e Riscos) é o conceito que deve ser aplicado e, portanto tornar-se uma prática constante nas empresas que buscam desenvolver produtos de software melhores.
Segundo o Guia PMBOK® Quinta Edição, a definição de escopo é “a soma de produtos, serviços e resultados a serem fornecidos na forma de projeto.” E também temos outras duas definições importantes, Escopo do Produto, que é definido como “características e funções que descrevem um produto, serviço ou resultado” e Escopo do Projeto, definido como “O trabalho que deve ser realizado para entregar um produto, serviço ou resultado com as características e funções especificadas.” Grosso modo, se perguntarmos se estamos construindo o produto certo estamos falando do escopo do produto, caso contrário se a pergunta for, estamos construindo certo o produto estamos nos referindo ao escopo do projeto.
Mas o que gerenciamos nos projetos, esta distinção está clara? O que é mais importante o escopo do projeto ou o escopo do produto? É evidente que para entregar o produto temos que definir como será o trabalho do projeto, mas sem saber qual o produto ou trabalho a realizar como definir a forma de realizá-lo? É justamente em meio a estas questões cruciais ou até mesmo na falta de fazê-las é que empresas desenvolvem projetos com escopo mal definidos ou desenvolvem de maneira inadequada. Algumas ferramentas são propostas a serem utilizadas, por exemplo, criar uma EAP (estrutura analítica do projeto) ou criar um Backlog do produto, levantar os requisitos junto aos usuários através de técnicas de observação ou entrevistas, criar canais de colaboração, como o papel do Product Owner nos métodos ágeis. O objetivo aqui não é discutir cada uma individualmente, mas apontar que existem possibilidades através das ferramentas e técnicas dos diversos métodos que podem apoiar o gerente de projetos e sua equipe de planejamento a definir qual o escopo do produto e para construir o produto. Além disso, é importante que os próprios gestores estejam preparados para atuarem em ambientes em constante transformação, saibam lidar com as seis restrições que serão impostas aos projetos, pois estas medem forças entre si quando há um desequilíbrio importante, de aumento ou mesmo de diminuição de escopo.
O maior desafio, para os projetos de software hoje é delimitar o suficiente aquilo que será construído e entregue dentro de um cenário muitas vezes desfavorável, e o mais importante é saber que há dois contextos, o do projeto e do produto e que ambos se completam e não podem ser gerenciados de forma isolada.
[Crédito da Imagem: Escopo – ShutterStock]
You must be logged in to post a comment.
