Planejamanto de projetos de softwares:Obejto e Restriçoes

FASES DOS PROJETOS

Todo projeto é divido em fases e possui uma estrutura de ciclo de vida semelhante. Por menor que seja, um projeto possui uma fase de início, uma fase intermediária e uma fase de término. O número de fases depende da complexidade do projeto e de sua área de aplicação. O conjunto de todas as fases do projeto constitui seu ciclo de vida.
Ao final de cada fase o Gerente de Projetos, o patrocinador (spansor) e os outros envolvidos têm a oportunidade de determinar se o projeto deve prosseguir para a próxima fase e detectar e corrigir os erros a um custo aceitável.
Cada fase gera um deliverable. Um deliverable é qualquer item ou resultado tangível e mensurável que deve ser produzido para se alcançar o objetivo do projeto ou de parte do projeto.
De forma geral e simplória, o Gerente de Projetos deve ter em mente as fases: PLANEJAMENTO, EXECUÇÃO e FINALIZAÇÃO.
Este artigo se propõe a esclarecer o “COMO” da fase de PLANEJAMENTO.

OBJETIVOS DO PLANEJAMENTO DE PROJETOS

O planejamento do projeto é responsável pela quantificação do tempo e orçamento que um projeto custará, reduzindo, assim, as incertezas relativas aos riscos e custos. Nesta etapa o planejamento das atividades é detalhado, os produtos a serem gerados são especificados, os índices de controles são definidos e o cronograma detalhado juntamente da WBS. São estabelecidos os marcos principais do projeto, conforme critérios gerais (entrega de produtos finais) ou específicos (encerramento de uma fase ou um marco financeiro, por exemplo, data de faturamento).
A finalidade do planejamento do projeto é criar um Plano do Projeto que possa ser utilizado para guiar tanto a Execução quanto o Controle do Projeto.

A seguir tentarei descrever um CASE EXEMPLO dos processos para a fase de PLANEJAMENTO.

PROCESSO DO PLANEJAMENTO DE PROJETOS (empresa fictícia)

1) TOMAR CIÊNCIA DAS INFORMAÇÕES GERAIS DO PROJETO:

PASSO-A-PASSO:
1.1) O Gerente do Projeto deve convocar* reunião, via e-mail, com o representante da Equipe de Negócios responsável pela relação comercial do projeto, para receber as seguintes informações que deverão ser formalizadas em Ata de Reunião.

•   Visão do cliente quanto ao objetivo, necessidades e expectativas sobre o escopo do projeto;
•   Recursos mínimos previstos para o projeto (rh, infra-estrutura, hardware e software);
•   Questões políticas, problemas, objetivos implícitos sobre o cliente e produto proposto;
•   Cópias das documentações dadas como aceitas pelo cliente (versão final), bem como cópia do edital de licitação e termo de sigilo caso tenham sido emitidos.

* Poderão ser convocadas também para a reunião outras pessoas de acordo com a complexidade do mesmo e as novidades técnicas inerentes ao trabalho, que justifiquem, a critério do Gerente do Projeto, estas participações.

2) DEFINIR O ESCOPO DO PROJETO:

PASSO-A-PASSO:
2.1) O Gerente do Projeto deve registrar as informações que confirmem as necessidades do projeto e desenvolver um entendimento comum do escopo entre as partes envolvidas e interessadas:

• Descrição do escopo do produto: Incluem características do produto, serviço ou resultado para cuja criação o projeto foi idealizado. Essas características terão normalmente menos detalhes nas fases iniciais e mais detalhes nas fases posteriores, conforme as características do produto forem progressivamente elaboradas.
• Limites do projeto: Declara de forma explícita, o que está excluído do projeto, para evitar que uma parte interessada possa supor que um produto, serviço ou resultado específico é um componente do projeto.
• Objetivos do projeto: Incluem os critérios mensuráveis do sucesso do projeto, podendo ser objetivos técnicos, de negócios, custo, cronograma e qualidade. Podem incluir metas de custo, cronograma e qualidade.
• Lista de fatores essenciais para o sucesso da implementação: Descreve os fatores críticos de sucesso do projeto.
• Premissas do projeto: Lista e descreve as premissas específicas do projeto e o impacto potencial dessas premissas, se não forem confirmadas. Frequentemente, as equipes de projetos identificam, documentam e validam as premissas como parte do seu processo de planejamento. As premissas listadas na declaração do escopo detalhada do projeto são normalmente consideradas possíveis riscos ao projeto.
• Restrições do projeto: Lista e descreve as restrições específicas do projeto que limitam as opções da equipe. Por exemplo, um orçamento predefinido ou datas impostas (marcos do cronograma) divulgadas pelo cliente ou pela organização executora. Quando um projeto for realizado sob contrato, em geral as cláusulas contratuais se constituirão em restrições.
• Entregas do projeto (Subprodutos): Incluem o produto ou serviço do projeto, como resultados auxiliares, como documentação e relatórios de gerenciamento de projetos.

2.2) Uma vez definido e documentado o escopo, o Gerente de Projetos está apto a iniciar o ciclo de aprovações do escopo, conforme os seguintes procedimentos:
2.1.1) Definir Aprovadores de Escopo: Responsável (eis) pelas aprovações de escopo, podendo ser o responsável funcional pelo projeto e/ou o Patrocinador.
2.1.2) Solicitar Aprovação: Requerer a formalização da aprovação do escopo definido.
2.1.3) Fechar Escopo: Formalizar o que deve ser realizado no projeto, servindo de base para futuras decisões no projeto.

3) DEFINIR A ESTRUTURA ANALÍTICA DE TRABALHO DO PROJETO:

PASSO-A-PASSO:
3.1) O Gerente do Projeto deve reunir com a equipe do projeto, para dar início à elaboração da WBS.

• A WBS pode ser criada totalmente nova ou reutilizar partes de outra WBS ou de modelos (templates) da organização.
• Nesta hora os participantes devem consultar os documentos de alto nível que guiaram o escopo do projeto assim como entrevistas do cliente, de forma a identificar os subprodutos de cada fase.

3.2) O grupo deve iniciar colocando no primeiro nível (nível 0) da WBS o nome do projeto.
* Como exemplo, utilizaremos uma WBS de projeto de software.

3.3) Em seguida, colocar no segundo nível (nível 1, também chamado de primeiro nível de decomposição) as fases que estabelecem o ciclo de vida do projeto. Por exemplo:

Listar as atividades e tarefas dentro de cada componente principal, subdividindo cada componente até ter um nível de detalhe suficiente para suportar o plano.

O que é considerado um nível de detalhe suficiente? Tome em consideração estes fatores:
i. Para cada subproduto (deliverable), verificar se as estimativas de custo e tempo, assim como a identificação de riscos, podem ser desenvolvidos neste nível de detalhe e se é possível atribuir a responsabilidade para a execução do mesmo. Se a resposta for negativa, decompor o elemento da WBS em componentes menores até que possa responder essas questões, visando o melhor desenvolvimento dos processos de Gerenciamento de Projeto (Planejar, Executar, Controlar e Encerrar).
ii. Uma boa heurística a seguir é a regra do 8-80: exige-se que um pacote de trabalho ocupe entre 8 e 80 horas de duração, a variação é de acordo com o ciclo de acompanhamento, de modo que seja possível identificar: Um código de identificação único; um subproduto específico e verificável; um único responsável pela sua entrega.
iii. Se você não tem informações suficientes para criar uma WBS para todas as fases do projeto, você pode usar a técnica de Planejamento em ondas sucessivas ou Elaboração progressiva, ou do inglês, Rolling Wave Planning (RWP). Neste caso, você terá que construir uma WBS bem definida da primeira fase do projeto e quando esta fase estiver quase completa, você terá informações suficientes para construí uma WBS mais completa para a fase seguinte. Então você continuara este processo até o final do projeto.

Comentário:O planejamento do projeto é responsável pela quantificação do tempo e orçamento que um projeto custará, reduzindo, assim, as incertezas relativas aos riscos e custos.Uma boa heurística a seguir é a regra do 8-80: exige-se que um pacote de trabalho ocupe entre 8 e 80 horas de duração, a variação é de acordo com o ciclo de acompanhamento, de modo que seja possível identificar