• Nenhum resultado encontrado

XPM consiste em uma abordagem ágil de gerenciamento de projetos cuja característica principal está na sua relação à mudança: diferentemente da abordagem tradicional, na qual o planejamento é direcionado aos resultados, ao contrário da ágil, onde os resultados direcionam o planejamento, sendo necessário facilitar a mudança, e não desencorajá-la por meio de processos complexos, que restringem e diminuem a criatividade.

O XPM visa melhorar o gerenciamento de projetos, em especial aos projetos de software para os quais o tempo e o custo para tornar o produto disponível no mercado são críticos, não sendo possível elaborar um cronograma detalhado e uma especificação de requisitos em um estágio preliminar do processo, e mostra-se necessária uma avaliação diária do projeto para adequá-lo à situação de mercado. A meta é a entrega do resultado desejado, e não necessariamente o resultado inicialmente planejado. Ela é definida por um conjunto de 11 regras e cinco ferramentas, descritas a seguir, que possuem como missão dar suporte à mudança, planejando critérios de sucesso para stakeholders, citando cenários e eventos principais, definindo benefícios esperados e como atingi-los e estabelecendo acordos com parceiros e em relação à qualidade exigida.

4.1 Regras

4.1.1 XPM Regra 1: A gerência de pessoas e processos criativos demanda processos criativos.

Não existe uma forma única e ideal para gerenciar projetos na dinâmica atual do mercado. Tanto gerente quanto equipe precisam ser criativos no desenvolvimento de um produto inovador, com alto valor para o negócio e maior qualidade. É necessário considerar não só as expectativas e os requisitos dos clientes, mas também o contexto e as estratégias da própria organização, em busca de um planejamento, monitoramento e controle mais tangível do projeto.

4.1.2 XPM Regra 2: Quanto menos o gerente souber sobre questões técnicas do projeto, melhor.

O gerente de projeto vai ter que se responsabilizar em analisar o número de variáveis complexas para poder desenvolver um plano realístico que não somente identifique as expectativas dos clientes, requerimentos funcionais especificados, riscos e custos, mas também devem focar-se e entender o contexto organizacional dentro a qual o projeto está sendo desenvolvido.

Para entender e gerenciar um projeto, o gerente deve fazer distinção entre os aspectos gerenciais e técnicos.

O gerenciamento tradicional freqüentemente confunde o gerenciamento de projeto com o gerenciamento técnico. O processo de gerenciamento técnico requer um entendimento detalhado do processo de desenvolvimento de sistema: análise, design, programação e teste e consiste em assistência ao time técnico. O gerente técnico é um “guru”, pessoa que detém profundas habilidades técnicas.

O gerente de projeto tem um foco diferente e é direcionado por um conjunto diferente de informações que não são técnicas, elas trazem em seu contexto, informações gerenciais sobre o projeto. Os aspectos técnicos e gerenciais são integrados através do escopo, objetivos, estratégias e requerimentos de qualidade do cliente.

Com a freqüente mudança da tecnologia e a complexidade envolvendo as mais variadas técnicas de desenvolvimento, torna-se difícil, se não impossível para o gerente de projeto ter todas as habilidades técnicas necessárias para torná-lo responsável pelo gerenciamento técnico do projeto.

O escopo, objetivos, estratégia e qualidade são um elo de ligação entre o gerenciamento técnico e o de projeto. O gerente de projeto deve definir e concordar com o escopo e objetivos do projeto como requerido pelo cliente. O analista de sistema deve então se focar neste escopo e objetivos acordados para realizar sua análise e

4.1.3 XPM Regra 3: O que ocorre depois do projeto é mais importante do que ocorre durante o projeto

No gerenciamento tradicional de projeto, após o desenvolvimento, poucas empresas rastreiam seus custos ou os benefícios realizados. A ausência destas informações no ciclo de produção deixam o alto escalão sem evidências do valor agregado através dos novos produtos ou sistemas de informação, o que tem também contribuído para o se ter uma visão errada da Tecnologia de Informação como um centro de custo.

4.1.4 XPM Regra 4: O planejamento de projeto desenvolvido sem a participação completa dos stakeholders não é mais que a fantasia de uma única pessoa

Para ser um sucesso, o planejamento dos e-projects em um contexto organizacional contemporâneo o gerente de projeto deve identificar os stakeholdes1 chaves relacionados ao projeto e com os

membros do time de projeto realizar um processo de planejamento de maneira aberta e colaborativa.

Este conceito de gerenciamento de projeto aberto garante que todos os provedores de serviço para o gerente de projeto e todos os gerentes de projetos nos projetos relacionados estejam preparados para suportar sua tabela de horários previamente estabelecida.

As complexidades internas e externas dos e-projects podem simplesmente sobrecarregar uma única pessoa. Um time tem uma capacidade maior para garantir que tudo que foi planejado seja completado e preciso.

Deve ser enfatizado que a abordagem do planejamento aberto é baseada em consenso, o gerente de projeto é ainda a pessoa responsável. Freqüentemente o time envolvido não vai chegar a um consenso e nestes casos, cabe ao gerente de projeto

1

Stakeholders são indivíduos ou as organizações que estão ativamente envolvidos em um projeto cujos interesses podem afetar positivamente ou negativamente o resultado da execução do projeto

juntamente com o dono ou patrocinador do projeto resolver o impasse.

O conceito de um encontro de um grande grupo de pessoas para planejar o projeto pode ser visto como risco e custo, mas experiências mostram que o processo aberto é mais rápido, tem menos custo e mais preciso. A XPM usa o Planejamento Rápido (RAP) para produzir planos de projeto – um conceito semelhante ao Desenvolvimento Rápido de Aplicação (RAD)

Quadro 03 : Etapas do Planejamento Rápido (RAP)

Etapa Descrição

Definir Sucesso Estabelecer as expectativas que cada participante tem para o sucesso. Definir escopo, objetivos, stakeholders e

projetos relacionados

Analisar o escopo e objetivos do projeto

Analisar os benefícios do projeto Analisar os benefícios gerados ao negócio com o produto, sistema ou serviço sendo desenvolvido

Analisar a qualidade do projeto Analisar a qualidade do produto que está sendo gerado

Analisar cenários / estratégias do projeto Definir as estratégias que devem ser tomadas ao longo do projeto

Analisar risco do projeto e desenvolver um plano de gerenciamento de risco

Estabelecer os riscos para o projeto, a probabilidade e impacto dos mesmos e um plano de respostas a estes riscos. Desenvolver a lista de tarefas do projeto Estabelecer a lista de tarefas do projeto Estimar as tarefas do projeto Estimar o tempo de conclusão para cada

uma das tarefas.

Desenvolver cronograma do projeto Elaborar o cronograma das tarefas do projeto.

Fonte : Abrahamsson, Salo, Ronkaisen e Warsta (2002)

4.1.5 XPM Regra 5: Quanto mais tempo o gerente de projetos permanecer com os stakeholders melhor

A XPM está envolvida com o contexto do projeto (ambiente organizacional, social, político e financeiro no qual o projeto está sendo desenvolvido), logo a gerência do contexto trata do gerenciamento das expectativas de um conjunto complexo e variado de stakeholders. O gerenciamento do contexto preocupa-se com o time de projeto e processos internos envolvendo o desenvolvimento do produto.

4.1.6 XPM Regra 6: Se o sucesso do projeto não for definido no começo, ele nunca será alcançado no final

Para muitos gerentes de projetos e analistas de sistemas, expectativas são simplesmente aqueles elementos requeridos que não foram especificados pelos clientes. Para outros, expectativas são a diferença entre o que o cliente quer e o que eles realmente precisam. Em uma batalha dura para o gerente de projeto, as expectativas são uma lista de desejo que inicia uma serie de negociações difíceis para reduzir estas expectativas. As expectativas ansiadas pelos clientes são relativas a satisfação dos

stakeholders, atendimento dos objetivos / requerimentos funcionais,

a permanência dentro do orçamento, a manutenção dos prazos, agregar valor ao negócio, assegurar uma boa qualidade ao produto e deixar os membros da equipe satisfeitos. A ferramenta sugerida para o acompanhamento é composta por sliders de sucesso, um indicador que representa o grau de atendimento aos critérios de sucesso.

4.1.7 XPM Regra 7: Mostre-lhes o lucro: nada mais importa

Mais do que facilitadora de processos, a força atual da TI reside em tornar o negócio mais lucrativo e competitivo. Uma análise cuidadosa do negócio permitirá identificar o valor agregado pelo produto e priorizar funcionalidades a serem desenvolvidas, visando empregar menos esforço na obtenção de mais benefícios. As ferramentas utilizadas são:

a) O modelo O3 (Objective, Output, Outcome), que cria uma cadeia de valores para o projeto, permitindo modelar e perceber os benefícios associados aos objetivos. Ele parte do princípio de que a organização só será capaz de alcançar seus resultados se o projeto tiver sucesso na produção de resultados relevantes. Ele está baseado no modelo IRACIS (Increase Revenue, Avoid Costs and

Improve Services), Thomsett (2002), que possibilita identificar se os

b) Um Acordo de Qualidade que, a partir dos objetivos do produto, estabelece os critérios para definir sua qualidade e os processos presentes no desenvolvimento que irão assegurá-la, uma vez que a melhoria de um atributo de qualidade pode causar impacto negativo em outro.

4.1.8 XPM Regra 8: Os Stakeholders do projeto podem ser seus melhores aliados ou seus piores inimigos

Depois do principal papel do projeto, o patrocinador, a segunda causa mais comum de falha de projeto é o papel de

stakeholders do projeto e projetos relacionados. Em muitos e- projects há um conjunto complexo de interdependências entre o

projeto e seu contexto organizacional.

Existe risco de um stakeholder (como um fornecedor de recursos) ser deslocado para outro projeto, o que geralmente causa impacto negativo. Na tentativa de evitar tais situações, o XPM sugere ao gerente a utilização de Acordos de Parceria, uma ferramenta que documenta os serviços requeridos, o tempo e o custo estimado para sua realização e a identificação de pessoas em condições de fornecer um retorno sobre os serviços para o stakeholder. Manter os stakeholders informados sobre os resultados ajuda a manter uma boa relação no projeto.

4.1.9 XPM Regra 9: Se você não pode prever o futuro, não planeje em detalhe

O XPM abrange planejamento e re-planejamento diários, como parte do processo da equipe e dos stakeholders. Todas as alterações relativas a contexto, externas e internas. Riscos, escopo, objetivos, valor agregado, etc. . são identificadas e avaliadas diariamente, o que se ajusta extremamente bem aos conceitos de XP. Na sessão de RAP os principais eventos e cenários relacionados à entrega do produto são identificados, e somente tarefas que visem atingir um evento específico são detalhadas e incluídas no cronograma. A ferramenta de planejamento em tempo real de eventos e cenário é uma extensão simples das práticas de desenvolvimento utilizadas em XP.

4.1.10 XPM Regra 10: Se o seu projeto não mudou, fique apreensivo, muito apreensivo.

A abordagem mais comum de medição do progresso do projeto é o encontro da equipe com o gerente de projeto no inicio do dia. O foco deste encontro é o contexto e não o conteúdo, do projeto. Em outras palavras, é avaliado se a equipe está fazendo o que é esperado ao projeto.

Estes encontros matinais tentam responder as seguintes questões: a) Se as expectativas de sucesso mudaram.

b) Se houve alguma mudança no escopo.

c) Se houve alguma mudança relacionada com os stakeholders. d) Se as premissas de benefícios e custos ainda são relevantes. e) Se os benefícios adquiridos até então ainda são relevantes. f) Se a qualidade mudou.

g) Se houve mudança para os riscos do projeto e gerenciamento de risco.

Assim, se houver qualquer mudança nos objetivos do projeto um re- planejamento deve ocorrer imediatamente, até mesmo antes que se inicie qualquer trabalho técnico.

4.1.11 XPM Regra 11: Em e-projects, um dia é um tempo muito longo O gerenciamento efetivo de e-projects demanda uma abordagem nova e radical para o gerenciamento de projetos. O XPM tem provado em muitas organizações ser efetivo e poderoso em gerenciamento de e- projects.

Documentos relacionados