//
Documentos de saída do fluxo 1

Ao seguir o fluxo de processo 1, vários documentos serão gerados pelos processos, sendo muitas vezes o resultado concreto da execução correta de um processo. Nesta área do PMO Virtual eu vou mostrar que documentos são estes, e sugerir uma forma de gerá-los.

___________________________________________________________________________
Documentos de Saída do Fluxo 1

Cada um dos processos descritos no fluxo de processos 1 gera um ou mais documentos. Alguns são obrigatórios e outros opcionais, além de que alguns também são utilizados como entradas de outros processos.

saidas
Figura 2 – clique para amplicar

Nesta área publicarei quais são os documentos originados em cada processo, o resumo sobre o que cada um deve conter, o formato sugerido, o software indicado para a construção e um modelo para download. Lembrando que os modelos disponíveis são os que eu utilizo em meus projetos, não sendo estes os únicos e muito menos os melhores. Eles representam apenas uma forma de fazer.

Lembrete: Todos os documentos são necessários para um melhor gerenciamento do projeto, porém alguns são opcionais e de acordo com o projeto em questão podem ser descartados. No entanto, os obrigatórios tem um propósito importante no fluxo então devem ser gerados.

Dica: Se você, como eu, gosta de ter contato visual e uma forma rápida e fácil de lembrar o que precisa fazer, imprima o fluxo de processo da figura 1, juntamente com a lista de documentos de saída que está abaixo na figura 2, e cole na sua mesa, na sua parede, no corredor da sua empresa, ou em qualquer outro lugar que esteja ao alcance dos seus olhos.

Baixe aqui a versão 1.6 dos Documentos de Saída do Fluxo de processo 1 em PDF: PMO Virtual – Documentos de Saída do Fluxo 1 (pdf).

obs: É preciso ter o Adobe Reader para abrir e ler o fluxo na versão PDF. Caso não tenha clique aqui e realize o download gratuíto através do próprio site da Adobe.

Como foi descrito nos elementos do fluxo, cada processo possui saídas, e estas saídas podem gerar documentos que são mostrados no fluxo com números, semelhantes a imagem ao lado. Para entender quando e como cada um dos documentos é gerado ao longo da execução dos processos, acompanhe no fluxo cada documento através de seu número, e relacione-os com os números abaixo. Assim ficará bem simples de saber quando usar um documento específico, e quando e como gerar um outro.

___________________________________________________________________________
a. Definições

1. Project Charter – Termo de abertura do projeto: Documento obrigatório, que tem o objetivo de oficializar o início do projeto, determinando seus objetivos, requisitos de alto nível, cronograma macro, responsáveis e equipe envolvida.

Dica: Documento em formato textual, utilizando ferramenta Microsoft Word ou similar.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

2. Registro das partes interessadas – Stakeholders: Documento obrigatório, que visa listar as partes
interessadas que devem ser consideradas durante o projeto, identificando também seus respectivos interesses, tais como: expectativas, influência, relacionamento e finalidade no projeto.

Lembrando que as partes interessadas podem gerar influências positivas e ajudar o projeto, como também influenciar negativamente e prejudicar o projeto. É importante identificar qual é o tipo de influência de cada Stakeholder, e se necessário qual a estratégia para gerenciá-lo.

Dica: Documento em formato textual, utilizando ferramenta Microsoft Word ou similar.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

3. Plano de gerenciamento do projeto: Documento obrigatório, que tem como finalidade guiar a execução do projeto e servir como base para o controle de todo o projeto, incluindo as etapas de planejamento e gerenciamento. É um forte aliado na melhoria da comunicação e da clareza com os stakeholders.

Este documento pode ser dividido em pequenos planos menores de acordo com o tamanho do projeto e o detalhe desejado em cada área de gerenciamento.

Sugere-se que contenha no mínimo as seguintes sessões:

  • Objetivo do projeto;
  • Ciclo de vida do projeto;
  • Processos aplicáveis ao projeto;
  • Ferramentas a serem utilizadas na gestão;
  • Plano de gerenciamento de mudanças;
  • Plano de gerenciamento de configuração;
  • Plano de gerenciamento de requisitos; e,
  • Plano de comunicação do projeto.

Dica: Documento em formato textual, utilizando ferramenta Microsoft Word ou similar.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

4. Documento de detalhamento de requisitos de alto nível: Documento obrigatório, que visa elicitar e detalhar de forma resumida todos os requisitos identificados para serem atendidos pelo projeto, e que compõem o produto objeto final do projeto. O foco do detalhe deve ser sempre o negócio do cliente.

Este documento deve ser dividido em duas partes distintas: (1) Elicitação e (2) Detalhamento.

Dica: Documentos em formato textual, utilizando ferramenta Microsoft Word ou similar.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

5. Matriz de rastreabilidade de requisitos: Documento obrigatório, que visa ser uma tabela de ligação entre os produtos a serem realizados pelo projeto, e os seus requisitos de origem, mantendo um rastreamento durante todo o ciclo de vida do projeto. Tendo como principal objetivo ajudar a garantir que cada requisito seja atendido e resulte em um valor adicionado ao projeto.

Dica: Documento em formato tabular, utilizando ferramenta Microsoft Excel ou similar. Sendo que uma das características desta matriz é a ligação entre o requisito identificado como necessidade, com as funcionalidades ou realizações (e.g. telas, relatórios, integrações, apresentações, testes, manuais, treinamentos) que serão completadas para atender a cada requisito. Com isso é fácil acompanhar os requisitos atendidos e não atendidos. Este é um documento que não pode ser perdido de vista nunca.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

6. Protótipos de telas e relatórios: Documento obrigatório, que tem como objetivo mostrar de uma forma clara e direta como as telas e relatórios do sistema ficarão visualmente, e como será o comportamento de cada um após a implementação (desenvolvimento) do sistema.

Não é necessário que seja um protótipo navegável, mas deve representar características e arquiteturas visuais, bem como as regras envolvidas com o funcionamento da tela ou relatório.

Este documento pode ser dividido em dois ou mais documentos.

Dica: Uma sugestão para criar os protótipos, é o Microsoft Visio, porém o envio ao cliente pode ser no
corpo de um documento textual em Microsoft Word, permitindo inclusive a complementação de textos explicativos com o objetivo de descrever os funcionamentos mais importantes, ou atípicos do protótipo.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

7. Modelo de dados relacional e Dicionário de dados: Documentos obrigatórios. O modelo de dados relacional, também conhecido como MER, deverá ser um desenho do modelo de dados, explicitando todas as tabelas, seus campos e características que o banco conterá, além de suas integridades referenciais (relacionamentos).

O dicionário de dados deverá ser um complemento do MER, contendo um descritivo de todas as características das tabelas e campos.

Dica: Normalmente ferramentas como Erwin e Microsoft Visio permitem o desenho do MER e o complemento do dicionário. No entanto, utilize a ferramenta de sua preferência, existem várias no mercado.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

8. Declaração do escopo / Especificação detalhada: Documento opcional (*), que tem o objetivo de ser um descritivo detalhado do funcionamento das telas do sistema, relatórios, integrações e eventuais rotinas ou processos implícitos, contendo descrições o mais detalhadas possíveis, principalmente, e no mínimo de regras de negócio, comportamentos, validações e resultados esperados.

Este é o momento de detalhar e registrar os critérios de aceitação, riscos e premissas identificadas, além do que está contido nas entregas, e principalmente o que será excluído do projeto. Muitas vezes este
último ponto não é registrado como deveria, gerando problemas em aceitações formais de entregas do projeto.

Geralmente estes documentos são suficientes para detalhar todo o trabalho que deve ser feito no
projeto, mas caso seja necessário podem ser adicionados outros como complementação (*), e sendo considerados como exceção, geralmente não como regra.

Lembrete: A documentação em excesso é tão ruim e prejudicial quanto à falta dela. Porém, as regras de negócio sempre devem ser descritas e registradas.

Dica: Documento em formato textual, utilizando ferramenta Microsoft Word ou similar.

(*) De acordo com a complexidade do sistema, o detalhamento pode estar contido nos protótipos, ou serem descritos em documentos separados. Podendo ainda ser complementado por Casos de Uso e/ou
diagramas de sequência, porém, estes geralmente não são realizados para todas as funcionalidades, apenas para as mais críticas ou complexas.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

9. EAP: Documento obrigatório. A estrutura analítica do projeto é uma representação gráfica e visual de todo o escopo do projeto, definido a partir da declaração do escopo. Deve representar graficamente todo o trabalho do projeto.

Esta é a principal ferramenta de controle do trabalho do projeto, principalmente como fronteira do que está ou não contido no trabalho, que deverá ser realizado durante a etapa de implementação do sistema.

A técnica utilizada para montar a EAP, apoiada no Guia PMBOK®, é a transcrição da definição do escopo, decomposta em pacotes de trabalho que serão representados graficamente na EAP. Estes pacotes normalmente são decompostos em unidades menores que ficam entre 8 e 80 horas. Como
sugestão, não devem ser definidos pacotes menores que 8 horas, ou maiores que 80 horas. Ou se for de preferência, pode-se utilizar as referências de 4 ou 40 horas, respectivamente.

A EAP tem outra importância, que é a primeira estimativa mais concreta do esforço total do projeto. Pois, ao definir todos os pacotes de trabalho, considerando a regra do 8/80, se obtêm o tamanho de todos
os pacotes de trabalho, e ao agregá-los debaixo para cima na estrutura da EAP, se consegue a primeira previsão de esforço de todo o trabalho do projeto.

Dica: Duas boas ferramentas para se construir a EAP é a WBS Chart Pro ou a Freemind.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

10. Dicionário da EAP e Linha de base do escopo: Documentos obrigatórios. O dicionário da EAP deve ser um descritivo resumido dos pacotes de trabalho e suas características, principalmente a diferenciação dos pacotes por um número de identificação, que poderá ser usado futuramente em cronogramas, status reports e outros relatórios de acompanhamento.

A linha de base do escopo, nada mais é do que uma marcação de todo o escopo definido até o momento. A sua maior importância é determinar o fechamento de uma parte, ou de todo, o escopo do projeto. Feita esta marca, esta linha de base será utilizada para o controle das mudanças de escopo no projeto, podendo servir de base para negociações de prazo, custo e qualidade, além do próprio controle integrado de mudanças.

Dica: Ambos os documento podem ter o formato textual, utilizando ferramenta Microsoft Word ou similar. Sendo que a linha de base do escopo pode ser um documento em forma de termo de aceite, com solicitação de assinatura do cliente, confirmando a validade, entendimento e aceitação do escopo detalhada por todos os processos até o momento de sua assinatura.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

11. Lista de atividades e Diagrama de rede: Documentos opcionais, principalmente porque podem estar contidos e realizados no mesmo momento do cronograma do projeto.

A lista de atividades deve ser uma decomposição dos pacotes de trabalho da EAP em tarefas menores, que definam de forma objetiva os trabalhos que precisam ser realizados para completar os pacotes de trabalho da EAP do projeto. Este documento pode ser em formato textual utilizando ferramenta Microsoft Word, ou tabular utilizando o Microsoft Excel, ou diretamente no Microsoft Project contendo uma lista simples, enumerada e ligada aos pacotes de trabalho para rastreabilidade e acompanhamento.

Dica: O diagrama de rede tem a função de determinar o seqüenciamento das atividades, bem como o relacionamento e a dependência entre as atividades. O ideal para este documento é que ele seja gráfico, utilizando ferramentas como Microsoft Visio. Outra boa opção é o Microsoft Project, onde o diagrama de rede é montado automaticamente ao se listar as atividades, e definir as dependências e seqüenciamentos entre elas. É uma ferramenta interessante pela sua praticidade de uso e pela possibilidade de extração do Gráfico de Gantt que expressa graficamente o diagrama de rede.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

12. Estimativa de duração das atividades: Documento obrigatório. Uma forma de estimar corretamente, se dá ao decompor os pacotes de trabalhos da EAP em atividades menores, determinando para cada atividade sua estimativa de duração.

Uma das maneiras mais seguras de se estimar a duração das atividades é a opinião especializada, ou seja, reunir a equipe que irá realizar a atividade, explicar todos os detalhes conhecidos sobre a tarefa, sanar todas as dúvidas que podem influenciar no tempo e no esforço, e por fim deixar a própria equipe dizer qual é o tempo estimado para a realização da atividade exposta. Com isso a estimativa se torna mais assertiva, por ser definida em uma granularidade menor e por ser determinada por quem é especialista no trabalho envolvido.

Esta decomposição ainda permite a aplicação da estimativa bottom-up para se estimar a duração total do projeto. A bottom-up define que a soma de todas as estimativas das atividades menores, determinam a duração total dos pacotes de trabalho, e ao somar os pacotes de trabalho, se obtêm a duração total do projeto.

Dica: Este documento apesar de obrigatório pode ser realizado em conjunto, e estar contido no cronograma do projeto. Se realizado em separado pode ter o formato textual, utilizando ferramentas como Microsoft Word e Microsoft Excel.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

13. Requisitos de recursos e EAR: Documentos opcionais. No entanto, como parte do processo se torna obrigatória a identificação dos recursos necessários para realizar os trabalhos do projeto, principalmente as pessoas. Após a lista de atividades, e conseqüente estimativa de duração das mesmas, pode-se montar uma lista objetiva dos recursos necessários para se completar as tarefas do projeto.

Lembrando que esta lista de requisitos de recursos deve conter todos os recursos necessários, tais como pessoas, máquinas, equipamentos, software, entre outros.

Dica: A lista de requisitos de recurso pode ser um documento em formato textual, utilizando ferramenta Microsoft Word, ou tabular utilizando o Microsoft Excel ou similar. O mais importante é conter o nome ou descrição do recurso, o tempo que ele será necessário, e em vários casos o custo do recurso.

A Estrutura Analítica de Recursos (EAR) complementa a lista de requisitos de recurso, representando
graficamente como os recursos se relacionam e estão organizados, principalmente organizacional e hierarquicamente.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

14. Cronograma do projeto: Documento obrigatório. Com a lista de atividades, o diagrama de rede, as estimativas e os recursos, o cronograma do projeto pode ser montado.

Para este processo, o cronograma pode ser detalhado na mesma granularidade da lista de atividades, ou em um nível superior e mais macro, o de pacotes de trabalho. Porém no mais macro, as atividades devem ser controladas fora do cronograma, esta estratégia diminui a complexidade de manutenção do cronograma, e tira o controle do projeto deste artefato, que deve apenas permitir o acompanhamento das datas mais importantes do projeto, evitando um controle orientado a cronograma, que geralmente não é saudável aos projetos.

Lembrando que o controle em separado das atividades deve permitir que a equipe do projeto saiba
exatamente quais atividades precisam ser completadas para que o pacote de trabalho definido no cronograma esteja concluído. Sendo que a duração da estimativa do pacote de trabalho destacado como item do cronograma deve ser a soma de todas as atividades contidas no mesmo pacote de trabalho.

Dica: A ferramenta mais indicada para se construir e acompanhar um cronograma é o Microsoft Project. Ele fornece todas os recursos tecnológicos necessários, além de uma praticidade reconhecida de uso para controlar prazos, datas de marcos, antecipação, espera, alocação e até custos.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

15. Dados do Cronograma: Documento opcional, que tem a finalidade de apoiar o cronograma realizado, melhorando o entendimento de informações que influenciaram na determinação de prazos, marcos, paralelismos, antecipações, esperas e outros detalhes contidos no cronograma.

Este documento deve conter no mínimo os atributos das atividades, detalhes sobre as premissas e restrições que influenciaram no cronograma, além de requisitos de recursos por período de tempo, e principalmente cronogramas alternativos, tais como melhor ou pior caso, prevendo a ocorrências
de riscos já identificados.

Comumente não são realizados cronogramas alternativos, dificultando o acerto na previsão de
conclusão dos marcos importantes do cronograma. Primeiro porque uma estimativa é somente, e simplesmente, uma previsão, segundo porque uma estimativa não deve ser considerada, a grosso modo, um compromisso de conclusão das atividades. Este compromisso geralmente não é cumprido, principalmente pelos fatores influenciadores de um projeto que podem ser vários. Neste caso os cronogramas alternativos podem ser uma opção, pois ajudam a equipe do projeto a prever, estudar e avaliar vários destes fatores influenciadores, mitigando os riscos de erro de estimativa, e conseguindo obter e divulgar previsões de conclusão mais reais e assertivas.

Dica: Documento em formato textual, utilizando ferramenta Microsoft Word ou similar.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

16. Planejamento de comunicação do projeto: Documento obrigatório, que tem como objetivo identificar quais são as necessidades de comunicação do projeto, visando determinar quais as necessidades de informação de cada parte interessada, definindo qual será o meio, a abordagem e a freqüência das comunicações do projeto. Sugere-se também como complemento, descrever como será o funcionamento das reuniões de comitê e de acompanhamento, bem como o conteúdo e o propósito
dos relatórios de Status Report.

Dica: Documento em formato textual, utilizando ferramenta Microsoft Word ou similar.

De acordo com o tamanho do projeto, este documento pode estar contido como uma sessão no plano de gerenciamento do projeto.

___________________________________________________________________________
 b. Modelos para download

Em breve.

___________________________________________________________________________
Introdução | Fluxo de processos 1 – Iniciação e planejamento | Documentos de saída do fluxo 1

Discussão

Nenhum comentário ainda.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

fabio cruz no twitter

Categorias

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Junte-se a 10 outros seguidores

%d blogueiros gostam disto: