//
Fluxo de processos 1 – Iniciação e planejamento

É preciso fazer e realizar atividades, mas mesmo antes de começar, é preciso saber por onde começar, e saber o que fazer em cada uma das etapas. Esta é a função dos fluxos de processos da área PMO Virtual que serão mostrados aqui.

___________________________________________________________________________
Quando e Como?

O objetivo desta área é mostrar quando, e como executar algumas das etapas de planejamento de um projeto de desenvolvimento de sistemas,
 demonstrando de uma forma simples e objetiva uma sequencia de processos que busca definir um fluxo seqüencial e lógico, abrangendo a iniciação e o planejamento inicial, abordando principalmente os documentos de entrada e saída que envolvem especialmente as etapas de levantamento de requisitos, análise de negócios, análise de sistemas, modelagem de dados, estimativas de atividades, recursos e prazos que irão, por fim, compor o cronograma de trabalho do projeto.

Dica: É mais interessante, e com certeza será mais proveitoso, se você conhecer o conteúdo dos grupos e seus processos antes de estudar o fluxo descrito abaixo. Para isso visite as sessões Iniciando e Planejando na áera PMBOK®.

___________________________________________________________________________
Iniciando

Muito se fala atualmente sobre a necessidade de melhorar a forma de gerenciar os projetos da área de tecnologia da informação, principalmente os relacionados a desenvolvimento de sistemas. Existem diferentes metodologias, frameworks e boas práticas, mas um dos problemas ainda existentes é que mesmo que se defina qual prática usar, é difícil no início saber como e quando usar.

Sendo assim, vou sugerir aqui uma forma de aplicação do Guia PMBOK®, elucidando como aplicar os processos contidos no guia e, como gerar valor a partir desta aplicação.

Um projeto de desenvolvimento de sistemas abrange várias áreas, e geralmente passa por inúmeras etapas até a sua conclusão. No entanto, um fator muito observado ao longo de vários projetos fracassados, demonstra que os principais motivos que levam ao insucesso são a ausência de planejamento inicial, o mau entendimento dos trabalhos que precisam ser realizados, e as falsas estimativas apresentadas como resultado dos péssimos trabalhos anteriores.

Por isso este artigo visa demonstrar um modelo funcional que aplica os processos de iniciação e planejamento contidos no Guia PMBOK®, objetivando principalmente ter a equipe certa, para entender da melhor maneira possível o trabalho necessário para o projeto, e planejar como os trabalhos serão realizados. Por isso ao longo do fluxo serão gerados artefatos que naturalmente estimularão a comunicação clara, objetiva e direta, entre a equipe do projeto, o cliente e todos os envolvidos e interessados com o projeto, aumentando e criando muitas condições e oportunidades para se atingir o sucesso esperado pelo projeto.

___________________________________________________________________________
Rompendo barreiras

O primeiro fator de influência negativa, é que inúmeros profissionais da área de sistemas da informação ainda não estão convencidos de que as boas práticas do Guia PMBOK® funcionam em projetos de desenvolvimento de sistemas. Este conceito se dá, principalmente pela velocidade em que as aplicações precisam ser concluídas, e a rapidez com que o mercado sofre mutações, não dando tempo para que os projetos sejam concluídos, e muito menos a aplicação de práticas extensas, complexas e fora da realidade dos projetos em questão.

Outro fator prejudicial, é que mesmo não havendo a barreira citada acima e a equipe de gerenciamento saber o que precisa ser feito para gerenciar o projeto, muitas vezes não se sabe COMO fazer esta gestão, dificultando na decisão de quando aplicar uma determinada prática, ou em qual é o momento correto para executar uma ação específica, ou até mesmo faltando a experiência e o conhecimento de quando deve-se produzir ou recorrer a um documento de entrada ou saída.

Assim eu irei demonstrar um fluxo eficiente que permitirá em uma sequencia lógica e realista, executar os processos e utilizar seus documentos de entrada e saída de forma eficaz para atingir o objetivo do projeto, quebrando os maus conceitos apresentados anteriormente, e estimulando o uso mais adequado de uma metodologia, que permite a reutilização de práticas reconhecidas pelo mercado mundial de gerenciamento de projetos.

Dica: Este fluxo foi criado por mim e já aplicado em situações reais de projeto. No entanto mostra apenas uma forma de fazer, a forma com que eu faço, não se propondo ser a melhor e nem a única, permitindo inclusive que este modelo seja adaptado para atender melhor o(s) seu(s) projeto(s).

___________________________________________________________________________
a. Fluxo

A partir das minhas próprias experiências em projetos de desenvolvimento de sistemas, sem dúvida, os dois grupos de processos mais importantes dentre os demais são os de iniciação e planejamento. Simplesmente porque são os primeiros a ocorrerem nos projetos de qualquer natureza, e são os responsáveis por definir e ditar o ritmo, realizar os entendimentos, identificar as tarefas e a forma com que as atividades e as comunicações vão fluir ao longo de toda a execução do projeto. Além de que, serão estes dois processos que vão definir “COMO”, e o “O QUE” será entregue ao final do projeto, acompanhados inclusive dos critérios de aceitação final do produto do projeto.

Por isso, se as etapas descritas no fluxo não forem realizadas, possivelmente ocorrerão problemas sérios no projeto em questão, principalmente os ligados as entregas, estimativas e entendimentos das necessidades do cliente, influenciando diretamente na futura aceitação final do projeto.

Se você já se perguntou ou ouviu a pergunta: “Porque tivemos tantos erros na execução do projeto?”, ou “Porque estamos demorando tanto para homologar esta entrega?”, ou até “Porque o nosso cliente está tão descontente com o que entregamos?”. Provavelmente foi porque os processos contidos na iniciação e planejamento do projeto foram negligenciados, ou pior, simplesmente não realizados.

Lembre-se: Executar é relativamente fácil, hoje em dia é possível construir quase tudo, mas o mais importante de tudo é construir a “coisa” corretamente, da maneira desejada e necessária para quem vai utilizar, e para isso é preciso se entender exatamente o que se precisa, e o que será feito.

Então, não saia correndo executando um projeto “meio” entendido, tenha calma e execute apenas uma vez, o retrabalho é muito mais caro do que a execução. Por isso o propósito deste fluxo é demonstrar uma eficiente maneira de colocar em prática os processos iniciais de um planejamento de um projeto de desenvolvimento de sistemas, e mostrar que seguir as boas práticas sugeridas pelo Guia PMBOK® é possível e menos complicado e “engessado” do que se imagina.

A figura 1 apresenta o fluxo dos processos de iniciação e planejamento, a execução deste fluxo deve ser a primeira realização do projeto, visando abranger desde a primeira reunião do projeto, aquela conhecida como kickoff, até a parte que atinge o cronograma detalhado de todas as atividades do projeto, incluindo estimativas, esforços e recursos envolvidos. Além é claro, de permitir a obtenção de todo o escopo definido e devidamente documentado ao final do fluxo.

Dica: Apesar de todos os processos estarem dentro dos grupos de iniciação e planejamento, os processos 2.2. e 2.3. descritos abaixo, também fazem parte da execução do projeto, pois irão gerar insumos que devem ser tratados como entregas do projeto, necessitando de validação e aprovação do cliente como se fosse um incremento pronto do sistema. São os contidos no quadro roxo em destaque.

Figura 1 - Fluxo de Processo de Iniciação e Planejamento - versão 1.6

Figura 1 - Clique para ampliar a imagem

Baixe aqui a versão 1.6 do Fluxo de processo 1 em PDF: PMO Virtual – Fluxo de Processos de Iniciação e Planejamento (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.

___________________________________________________________________________
b. Os Elementos do Fluxo

O fluxo possui os seis elementos a seguir, que permitem a quem o utiliza rapidamente identificar qual o caminho a seguir, e quais os artefatos utilizados e produzidos pelos processos.

b.1. Entradas: As entradas são todos os documentos, internos ou externos ao projeto, necessários para se realizar o processo. As entradas são representadas no fluxo conforme a figura ao lado. No exemplo, estão destacadas as entradas do processo 1.1. Project Charter, onde são sugeridos os documentos de declaração de trabalho, contrato e business case.

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

b.2. Processos: São os processos determinados para receber as entradas sugeridas, e serem executados durante o fluxo. Contendo atividades, ferramentas ou técnicas específicas para atingir o objetivo de cada processo. Cada processo foi extraído do Guia PMBOK® e pode ser corretamente entendido lendo o guia na íntegra ou acessando a área PMBOK® deste blog.

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

b.3. Saídas: As saídas são os documentos produzidos pelas atividades realizadas durante o processo, e podem ser consideradas o resultado da execução do processo. As saídas são mostradas no fluxo conforme imagem ao lado.

Os itens contidos na descrição da saída podem representar tópicos de um documento, ou o próprio documento. Neste exemplo estão ilustradas as saídas do processo 1.1. Project Charter. Este processo gera apenas um documento, denominado Termo de abertura do projeto, que deve possuir pelo menos os tópicos citados na referência da saída.

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

b.4. Documentos (Saídas): Ligados diretamente as saídas, os documentos servem de orientação para a composição do resultado esperado ao realizar o processo. As saídas podem ser representadas por um ou mais documentos, e estes podem ser obrigatórios ou opcionais, sendo que estas definições são dadas por este elemento, e podem ser apresentados no fluxo conforme figura ao lado.

Neste exemplo, os números 4 e 5 representam que a saída deverá ser composta por pelo menos dois documentos distintos e obrigatórios. Já o número 3 significa que a saída terá um documento que poderá ou não ser subdividido em vários outros documentos, seja para melhorar a comunicação ou para estruturar a divisão por áreas por exemplo. Por fim, os números de 13 e 14, definem que a saída deverá ser através de um documento obrigatório (o 13, de cor amarela) e um opcional (de cor rosa) que por sua vez pode ser subdividido em vários outros. Lembrando que estes tipos podem estar sozinhos ou combinados.

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

b.5. Sequência e sentido: As setas com traço contínuo representam a sequencia que deve ser seguida pelo fluxo, sendo que o sentido deve ser da ponta sem a seta para a ponta com a seta. A figura ao lado mostra um sentido indo da esquerda para a direita, de baixo para cima.

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

b.6. Atualizações: As setas com tracejado vermelho representam que um documento de outro processo está sendo atualizado, devido a uma atividade do processo em execução. Este é um elemento de fundamental importância para manter os documentos do projeto em constante evolução e atualizados ao longo do tempo acompanhando os produtos do projeto. Na figura ao lado é dado um exemplo de um processo sugerindo a atualização do plano do projeto.

___________________________________________________________________________
c. Processos do Fluxo

O fluxo abrange dez processos, sendo dois contidos no grupo de iniciação, e oito contidos no grupo de planejamento. A separação dos grupos e processos pode ser facilmente observada no fluxo da figura 1, pelas divisões “1. Iniciação” que está na cor rosa, e “2. Planejamento” que está na cor azul.

Vamos entender a proposta de cada processo contido neste fluxo,e  caso você tenha dúvidas sobre as atividades contidas nos processos, clique no link sobre o nome de cada um e veja seus detalhes na área PMBOK®.

1.1. Project Charter: É o processo responsável por Desenvolver o termo de abertura do projeto, e contempla o processo de mesmo nome contido no Guia PMBOK® 4ª ed.. Deve ser realizado logo no início do projeto, de preferência antes da reunião de Kickoff.

Dica: O ideal é que este processo seja realizado pelos patrocinadores, e/ou pelo gerente de projetos.

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

1.2. Stakeholders: É o processo responsável por Identificar as partes interessadas, e contempla o processo de mesmo nome contido no Guia PMBOK® 4ª ed.. Pode ser iniciado já na reunião de Kickoff, e intensificado após a mesma terminar. Nesta primeira etapa, é o processo mais importante, pois os Stakeholders serão os influenciadores do projeto. Lembrando que esta influência pode ser positiva ou negativa, e o quanto antes elas forem identificadas, melhor para a saúde do projeto.

Dica: O ideal é que este processo seja realizado pela equipe de gerenciamento, e se possível com o apoio da equipe de análise de negócios.

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

2.1. Plano de gerenciamento do projeto: É o processo responsável por Desenvolver o plano de gerenciamento do projeto, e contempla o processo de mesmo nome contido no Guia PMBOK® 4ª ed.. Deve ser realizado como primeiro processo do planejamento do projeto, e antes de qualquer trabalho de execução, inclusive antes dos trabalhos de análises de negócio e sistemas, pois o(s) documento(s) de planejamento gerado(s) neste processo guiarão todos os trabalhos do projeto daqui para frente, e vão alinhar os objetivos e clarificar os caminhos a seguir para toda a equipe.

Dica: O ideal é que este processo seja realizado pela equipe de gerenciamento, e se possível, incluir as equipes de análise e desenvolvimento, para auxílio nas definições de execução e controle que serão descritas no plano.

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

2.2. Documentos de requisitos: É o processo responsável por produzir os primeiros documentos relacionados com os requisitos do projeto, tais como matriz de rastreabilidade de requisitos e elicitação de requisitos. Contempla o processo Coletar Requisitos contido no Guia PMBOK® 4ª ed., e deve ser realizado sempre após a identificação dos Stakeholders, pois as partes interessadas é que alimentarão este processo com os requisitos mais importantes e fundamentais para o objetivo do projeto. Também podendo ser realizado em conjunto com o processo 2.3..

Importante: Este processo já é considerado parte da execução do projeto, devendo ser bem planejado e comunicado, além de acompanhando e controlado. No fluxo de execução e controle haverá mais detalhes sobre estas atividades.

Dica: É o primeiro trabalho de análise de negócios, é aqui que o analista de negócio começa a conhecer o sistema que irá desenvolver em detalhes. Os analistas de sistemas e desenvolvedores podem ser envolvidas já nesta etapa para apoio ao entendimento e as definições de arquitetura e sistemas.

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

2.3. Declaração do escopo: É o processo responsável por produzir os documentos detalhados e técnicos do projeto, tais como especificações, protótipos e modelos de dados. Contempla o processo Definir o escopo contido no Guia PMBOK® 4ª ed., e deve ser realizado sempre após a elicitação dos requisitos.

É um dos processos mais longos e importantes da etapa de análise de negócios e sistemas, pois envolve um grande contato com os Stakeholders, com o objetivo de determinar em detalhes todo o trabalho a ser executado para terminar o projeto, definindo inclusive a etapa de desenvolvimento.

Importante: Este processo já é considerado parte da execução do projeto, devendo ser bem planejado e comunicado, além de acompanhando e controlado. No fluxo de execução e controle haverá mais detalhes sobre estas atividades.

Dica: Este processo pode ser realizado em conjunto com o processo 2.2, e é onde os analistas de negócio devem participar detalhando as regras de negócio, os analistas de sistemas especificando todos os componentes técnicos do sistema, incluindo também regras, arquitetura, padrões de interface, entre outras. Como apoio nas definições e especificações os designers, desenvolvedores, analistas de testes e administradores de banco de dados podem ser envolvidos neste processo.

Lembre-se: Refazer é sempre mais caro que fazer, então não é perda de tempo detalhar os requisitos e especificar as regras de negócio e a arquitetura de seu sistema, perda tempo e dinheiro será iniciar uma construção mal definida e entendida, que precisará ser refeita no futuro. 

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

2.4. EAP / WBS: É o processo responsável por Criar a EAP do projeto, e contempla o processo de mesmo nome contido no Guia PMBOK® 4ª ed.. Deve ser iniciado quando se tem materiais produzidos de requisitos e escopo, e deve ser mantido ao longo de todos os trabalhos de análise do projeto.

Este é um dos principais documentos de controle e acompanhamento do projeto, pois mostra de forma gráfica e clara todos os pacotes de trabalho que precisarão ser desenvolvidos ao longo do projeto.

Dica: A EAP (estrutura analítica do projeto), geralmente é produzida pelo gerente do projeto e pelos analistas que participaram do processo 2.3. e 2.2. Pode ser iniciada já durante o processo 2.2., e ser detalhada juntamente com o processo 2.3.

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

2.5. Atividades: É o processo responsável por identificar, listar e sequenciar as atividades do projeto. Contempla os processos Definir as atividades e Sequenciar as atividades contidos no Guia PMBOK® 4ª ed..

O momento mais indicado para realizar este processo é após os trabalhos de análises estarem concluídos, ou seja, após a realização dos processos 2.2, 2.3 e 2.4. No entanto, quando o projeto é muito grande ou complexo e possui muitos requisitos para serem analisados e detalhados, os processos desde o 2.2 até o 2.7 podem ser realizados por ciclos de ondas sucessivas, ou seja, por ciclos menores que permitam o entendimento completo de pequenas partes do projeto, até completarem todo o trabalho contratado.

Este trabalho não precisa ser complexo, basta ter em mente que após se saber O QUE precisa ser feito, por exemplo: Uma tela de cadastro de usuário, é preciso definir as atividades que vão permitir O COMO realizar a tela, por exemplo: “Criar o layout da tela“, “Programar os componentes internos da página“, “Criar as tabelas envolvidas no banco de dados“, “Construir os planos de testes“, “Realizar testes unitários“, “Publicar a página no servidor de testes“, entre outras atividades que podem ser consideradas pela equipe como necessárias para se ter o requisito pronto e atendido.

Dica: Este processo pode ser realizado em conjunto com os processos 2.6 e 2.7, e o ideal é que toda a equipe participe destes trabalhos, pois é o momento onde se inicia o entendimento de como as tarefas serão realizadas. Caso não for possível, pelo menos os analistas e os desenvolvedores devem ser envolvidos nesta etapa.

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

2.6. Estimativas: É o processo responsável por estimar os recursos e as durações das atividades. Contempla os processos Estimar os recursos das atividadesEstimar as durações das atividades contidos no Guia PMBOK® 4ª ed.. O momento mais indicado para realizar este processo é após o processo 2.5., ou juntamente com o 2.5. e o 2.7..

Este é o momento que se entende completamente as tarefas que serão realizadas, e quais os esforços necessários para completá-las.

Dica: Tabmém é o ideal que neste processo toda a equipe do projeto participe dos trabalhos de estimativa, principalmente o time que será envolvido nas realizações de execução. Uma das melhores formas de prever e estimar o esforço necessário, é perguntar para o especialista que vai realizar a atividade.

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

2.7. Cronograma: É o processo responsável por Desenvolver o cronograma do projeto e contempla o processo de mesmo nome contido no Guia PMBOK® 4ª ed.. O momento mais indicado para realizar este processo é após os processos 2.5. e 2.6., ou juntamente com eles.

Dica: Geralmente o cronograma do projeto é montado pela equipe de gerenciamento durante os processos 2.5 e 2.6.

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

2.8. Plano de comunicação do projeto: É o processo responsável por Planejar as comunicações do projeto e contempla o processo de mesmo nome contido no Guia PMBOK® 4ª ed.. É geralmente iniciado a partir dos trabalhos do processo 2.1, e pode ser finalizado a qualquer momento dentro do fluxo, sendo importante e fundamental que esteja concluído e distribuído antes dos trabalhos de execução iniciarem.

Importante: Os trabalhos de análise contidos nos processos 2.2. e 2.3., realizados em conjunto com o cliente, já são considerados parte da execução do projeto e devem ser realizados após uma primeira versão do plano de comunicação já ter sido divulgado.

Dica: Este processo deve ser realizado pelo gerente do projeto.

___________________________________________________________________________
d. Documentos de Saída

Cada um dos processos descritos no fluxo 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.

Continue lendo, e veja na página Documentos de saída do fluxo 1, os documentos originados em cada processo, um resumo sobre o que cada um deve conter, o formato sugerido, o software indicado para a construção e, principalmente um modelo para download.

Continue sua visita ao PMO Virtual de FabioCruz.com.

___________________________________________________________________________
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: