PÓS-GRADUAÇÃO LATO SENSU EM ANÁLISE, PROJETO E

PÓS-GRADUAÇÃO LATO SENSU EM ANÁLISE, PROJETO E GERÊNCIA DE SISTEMAS DE INFORMAÇÃO
LEONARDO BARROSO DA SILVA
RAFAEL LEITE DE FREITAS
UMA FERRAMENTA PARA INTEGRAÇÃO DA DOCUMENTAÇÃO DE
PROJETOS AO MODELO CANVAS
Campos dos Goytacazes/RJ
2015
LEONARDO BARROSO DA SILVA
RAFAEL LEITE DE FREITAS
UMA FERRAMENTA PARA INTEGRAÇÃO DA DOCUMENTAÇÃO DE
PROJETOS AO MODELO CANVAS
Monografia apresentada ao Instituto
Federal de Educação, Ciência e Tecnologia Fluminense como requisito
parcial para conclusão da Pós-Graduação em Análise, Projeto e Gerência de Sistemas de Informação.
Orientadora: Simone Vasconcelos
Silva, D.Sc.
Campos dos Goytacazes/RJ
2015
LEONARDO BARROSO DA SILVA
RAFAEL LEITE DE FREITAS
UMA FERRAMENTA PARA INTEGRAÇÃO DA DOCUMENTAÇÃO DE
PROJETOS AO MODELO CANVAS
Monografia apresentada ao Instituto
Federal de Educação, Ciência e Tecnologia Fluminense como requisito
parcial para conclusão da Pós-Graduação em Análise, Projeto e Gerência de Sistemas de Informação.
Aprovada em 27 de fevereiro de 2015
Banca avaliadora:
……………………………………………………………………………………
Profª Simone Vasconcelos Silva, D.Sc. (orientadora)
Doutora em Computação/UFF
Instituto Federal de Educação, Ciência e Tecnologia Fluminense
……………………………………………………………………………………
Profª Ana Silvia Ribeiro Escocard Santiago, M.Sc.
Mestre em Pesquisa Operacional e Inteligência Computacional/UCAM
Instituto Federal de Educação, Ciência e Tecnologia Fluminense
……………………………………………………………………………………
Prof. Eduardo Francisco Freire da Silva, M.Sc.
Mestre em Economia Empresarial/UCAM
Instituto Federal de Educação, Ciência e Tecnologia Fluminense
Dedicatória
“Dedico este trabalho a todos os meus amigos
e familiares que conviveram comigo nos
últimos anos e que participaram, direta ou
indiretamente, na formação deste trabalho.”
Leonardo
“Dedico este trabalho à minha esposa
Bárbara, por estar sempre presente nos
melhores e piores momentos da minha vida”
Rafael
Agradecimentos
“Agradeço a oportunidade dada por Aline
Pires Vieira de Vasconcelos para participar de
projetos na instituição e a Simone Vasconcelos
Silva e equipe do grupo Quali/Gestão/NES
que ajudaram a construir um período de
amadurecimento profissional e pessoal em
minha vida; E aos meus familiares e amigos
que realmente vibram em cada felicidade e
conquista compartilhada.”
Leonardo
“Agradeço primeiramente aos meus pais por
terem sempre priorizado todos os esforços na
minha educação e por todo o carinho.
Agradeço também aos meus irmãos pelo
exemplo que sempre me deram. Por último
deixo um agradecimento a todos os
educadores que deram sua contribuição
durante minha vida acadêmica.”
Rafael
Resumo
Nos últimos anos, administrar projetos das organizações têm sido um desafio e tanto para gestores, principalmente devido ao mercado cada vez mais globalizado e competitivo. O presente
trabalho consiste no desenvolvimento e apresentação de uma ferramenta que se destina a apoiar o Gerenciamento de Projetos, permitindo que os dados gerados na concepção do plano de
projeto através da metodologia Project Model Canvas sejam aproveitados de forma a alimentar documentos baseados nos templates do PMBOK, tais como: Termo de Abertura do Projeto, Documento de Requisitos, Estrutura Analítica do Projeto, Orçamento e o Plano de Riscos.
A referida ferramenta foi desenvolvida através da evolução do protótipo do plug-in Canvas-gi,
integrado à Ferramenta Gestão Integrada, desenvolvida por projeto de pesquisa vinculado ao
Núcleo de Engenharia de Software do Instituto Federal Fluminense. Ao longo do trabalho, outras ferramentas de apoio ao Gerenciamento de Projetos foram pesquisadas, mas percebeu-se
que nenhuma delas possibilitava a integração dos dados e exportação do canvas para os documentos previstos pelo PMBOK.
Palavras-chave: Gerência de Projetos, PMBOK, Project Model Canvas, Gestão Integrada.
Abstract
In recent years, managing organization projects have been a challenge for managers, mainly
due to an increasingly globalized and competitive market. The present work is the development
and presentation of a tool that is intended to support the Project Management, allowing data
generated in the project plan by Project Model Canvas methodology of being recovered in order to feed documents based on PMBOK templates, such as: Project Charter, Requirements
Document, the Work Breakdown Structure, Budget, and the Risk Plan. The tool was developed through the evolution of a plug-in prototype named Canvas-gi wich is integrated to the Integrated Management tool, linked to the Software Engineering Center, at Instituto Federal Fluminense. Throughout the work, other tools wich support project management were surveyed,
but it was realized that none of them made possible the integration of data and export to other
documents provided by the PMBOK.
Keywords: Project Management, PMBOK, Project Model Canvas, Integrated Management.
Lista de Figuras
Figura 1: Representação gráfica das áreas do conhecimento do PMBOK. Fonte: PMI (2014).
...................................................................................................................................................15
Figura 2: Canvas dividido por cores. Fonte: FINOCCHIO (2013)...........................................24
Figura 3: Diagrama de classes do protótipo canvas-gi. Fonte: SALES (2013).........................40
Figura 4: Interface da versão anterior do plug-in Canvas-gi. Fonte: SALES (2013)................41
Figura 5: Diagrama de classes atualizado do plug-in Canvas-gi................................................43
Figura 6: Mensagem informativa e links da tela inicial do plug-in Canvas-gi............................43
Figura 7: Nova interface do Canvas-gi......................................................................................44
Figura 8: Formulário para preenchimento de um post-it da caixa Riscos..................................44
Figura 9: Tela de seleção de artefatos para geração dos templates no Canvas-gi.....................45
Figura 10: Tela de pré-visualização dos dados dos artefatos no Canvas-gi...............................45
Figura 11: Tela de Termo de Abertura preenchida com dados oriundos do Canvas-gi..............46
Figura 12: Tela do Canvas-gi após o preenchimento do canvas "TCC IFF".............................47
Figura 13: Tela do formulário do Termo de Abertura do projeto na ferramenta Gestão Integrada após a exportação dos dados do canvas-gi...........................................................................48
Figura 14: Tela que gerencia os perfis cadastrados na Gestão Integrada..................................48
Figura 15: Tela do formulário da EAP do projeto na ferramenta Gestão Integrada após a exportação dos dados do canvas-gi..............................................................................................49
Figura 16: Tela de visualização do Gantt por pacotes da EAP do projeto na ferramenta Gestão
Integrada após a exportação de dados do Canvas-gi................................................................49
Figura 17: Tela do formulário de Requisições do projeto na ferramenta Gestão Integrada após
a exportação dos dados do canvas-gi........................................................................................50
Figura 18: Tela do formulário de Plano de Riscos na ferramenta Gestão Integrada após a exportação dos dados do canvas-gi..............................................................................................50
Figura 19: Tela do formulário de Orçamento anual do projeto na ferramenta Gestão Integrada
após a exportação dos dados do canvas-gi................................................................................51
Lista de tabelas
Tabela 1: Funcionalidades Gestão Integrada x Adaptações x Áreas Atendidas. Fonte: (SILVA et
al., 2011)....................................................................................................................................33
Tabela 2: Comparativo entre as ferramentas de Gerência de Projetos......................................38
Tabela 3: Lista de Requisitos - Prótotipo Canvas-gi. Fonte: SALES (2013)............................40
Tabela 4: Áreas do canvas x Templates Disponíveis na Gestão Integrada. Fonte: SILVA (2014)
...................................................................................................................................................42
Tabela 5: Lista de Novas Funcionalidades e melhorias do plug-in Canvas-gi...........................42
Sumário
1 INTRODUÇÃO..........................................................................................................11
1.1 Objetivo........................................................................................................................... 11
1.2 Justificativa..................................................................................................................... 12
1.3 Metodologia.................................................................................................................... 12
1.4 Organização do trabalho................................................................................................13
2 GERENCIAMENTO DE PROJETOS.......................................................................14
2.1 Conceitos....................................................................................................................... 14
2.2 PMBOK.......................................................................................................................... 14
2.2.1 Fases do Projeto.......................................................................................................................... 14
2.2.2 Áreas do Conhecimento.............................................................................................................. 15
2.3 PROJECT MODEL CANVAS..........................................................................................23
2.3.1 Introdução.................................................................................................................................... 23
2.3.2 Conceber o Plano........................................................................................................................ 24
2.4 Considerações...............................................................................................................31
3 FERRAMENTA GESTÃO INTEGRADA..................................................................33
3.1 Descrição........................................................................................................................ 33
3.2 Funcionalidades............................................................................................................. 33
3.2.1 API REST.................................................................................................................................... 36
3.3 Considerações...............................................................................................................37
4 COMPARAÇÃO DAS FERRAMENTAS DE GERÊNCIA DE PROJETOS..............38
5 PLUG-IN PARA INTEGRAÇÃO PMBOK E PMCANVAS........................................40
5.1 Evolução do Plug-in Canvas-gi......................................................................................41
5.2 Estado Atual da Ferramenta...........................................................................................43
5.2.1 API REST.................................................................................................................................... 46
5.3 Exemplo Prático............................................................................................................. 46
5.4 Considerações...............................................................................................................51
6 CONSIDERAÇÕES FINAIS.....................................................................................52
ANEXO I - API RESTful para o Canvas-gi...............................................................56
Código das Boxes................................................................................................................ 56
Observações........................................................................................................................ 57
11
1 INTRODUÇÃO
Nos últimos anos, administrar projetos das organizações têm sido um desafio e tanto para
gestores, principalmente devido ao mercado cada vez mais globalizado e competitivo.
Segundo Rabechini Jr. e Carvalho (2003), as empresas têm passado por um processo de
transformação, organizando-se para poder dar respostas eficazes e rápidas aos problemas envolvendo competição e posicionamento de mercado. Estas respostas são um conjunto de ações
ou atividades que refletem a competência da empresa em aproveitar oportunidades, incluindo,
portanto, sua capacidade de agir rapidamente, respeitando as limitações de tempo, custo e especificações.
Diante da necessidade de obter excelência no ramo, as empresas utilizam com frequência
ferramentas, ou seja, softwares de gestão de projetos e se apoiam em metodologias.
Uma metodologia de gerência de projetos é uma abordagem estruturada utilizada para
guiar a equipe de projeto durante o desenvolvimento do plano do projeto. Pode ser tão simples
quanto formulários padrão e modelos (em papel ou eletrônico, formal ou informal) ou tão
complexa quanto uma série de simulações requeridas (PONTOGP, 2015).
Segundo Monteiro & Falsarella (2006) as informações coletadas ao longo do projeto precisam ser armazenadas, de forma que possam ser recuperadas, especialmente para uso em projetos futuros. Apesar de cada projeto ter a característica de ser único, é possível fazer benchmarking, utilizando os conhecimentos adquiridos em projetos bem sucedidos.
Dando prosseguimento a essa perspectiva, no que diz respeito às ferramentas de gerência
de projetos e portfólio, Silva et al. (2011) defende a prática de reunir todas as informações e
documentos de cada projeto da organização com os argumentos de que tal prática favorece os
projetos desenvolvidos de forma colaborativa, eliminando a redundância de documentos e ferramentas diversas, reduzindo o acúmulo de papéis e o desperdício causado pela alocação ineficiente de recursos, além da redução da duplicação de esforços em projetos.
1.1 Objetivo
O objetivo deste trabalho é analisar e evoluir o protótipo responsável pela concepção e gerência de projetos sob a metodologia canvas, chamado Canvas-gi, para que seja possível aproveitar os dados cadastrados através da funcionalidade do Project Model Canvas para o preenchimento inicial, de forma automatizada, de alguns dos templates (baseados no PMBOK) da
Ferramenta Gestão Integrada, tais como: Termo de Abertura do Projeto, Documento de Requisitos, Estrutura Analítica do Projeto, Orçamento e o Plano de Riscos. Por conseguinte, almeja-
12
se disponibilizar as funcionalidades oriundas do desenvolvimento para uso por ferramentas externas através de uma API.
1.2 Justificativa
Segundo Finnochio (2013), o modelo de padrão de projetos não está adaptado ao trabalho
na maioria das organizações, criando barreiras que impossibilitam que gerentes de projeto passem a realmente planejar os projetos dentro de suas organizações. Assim, dentro deste contexto, a aplicação das metodologias mais tradicionais têm demonstrado baixa eficiência em seu
uso.
De acordo com Rodello e De Pádua (2013), os Sistemas Integrados eram historicamente
desenvolvidos como sistemas isolados, ou seja, cada departamento ou setor (gestão de pessoas, contabilidade e produção, entre outros) desenvolvia o seu, com pouca ou nenhuma preocupação com a comunicação ou integração entre eles. Com o tempo, percebeu-se que a integração seria inevitável. As empresas adquirem diversos benefícios quando integram seus documentos em sistemas integrados, tais como disponibilização de informações táticas e estratégicas, redução de prazos de execução, eliminação de redundância e rastreamento dos erros e
controle sobre as operações.
A motivação para o desenvolvimento de um conjunto de funcionalidades voltadas para o
Project Model Canvas na ferramenta Gestão Integrada deu-se justamente por ser uma metodologia nova e promissora. Além disso, no início do desenvolvimento do protótipo constatou-se
que a metodologia era desprovida de uma ferramenta própria e de cunho específico (SILVA et
al., 2014). A partir desta funcionalidade foi observado que a mesma seria ainda mais útil se os
dados cadastrados através dela pudessem ser reaproveitados para o preenchimento automático
de todos os templates da ferramenta que fizessem uso desses dados, facilitando dessa forma a
integração das informações contidas no Project Model Canvas com os templates do PMBOK,
eliminando o desperdício de tempo com digitação de dados repetidos e aumentando a produtividade no projeto.
1.3 Metodologia
A adoção de metodologias de pesquisa ocasionou na divisão das atividades nas seguintes
etapas:
●
Revisão Bibliográfica sobre Gerência de Projetos e PMBOK;
●
Análise e descrição da Ferramenta Gestão Integrada;
●
Análise da metodologia Project Model Canvas;
13
●
Pesquisa de outras ferramentas e análise comparativa de funcionalidades com a Gestão Integrada;
●
Análise da versão atual do plug-in Canvas-gi;
●
Descrição dos novos requisitos e processo de implementação para o plug-in Canvas-gi;
●
Descrição de um exemplo prático documentando o resultado da integração dos canvas
com os templates da Ferramenta Gestão Integrada.
A metodologia aplicada neste trabalho segue, inicialmente, o tipo de pesquisa exploratória,
com o intuito de proporcionar uma visão de conhecimento mais ampla dos objetos selecionados para estudo.
Nesta abordagem metodológica, a característica predominante é a de uma pesquisa quantitativa (LAKATOS E MARCONI, 2010) pois contempla em sua pesquisa bibliográfica a pesquisa de ferramentas para classificação e análise, visando a comparação de suas funcionalidades, sob o método comparativo.
Visando o cumprimento dos objetivos do trabalho, o resultado da pesquisa deve ser documentado utilizando o método explicativo, principalmente por permitir que os pesquisadores
realizem um detalhamento maior da ferramenta resultante da pesquisa aplicada.
1.4 Organização do trabalho
Os capítulos iniciais tratarão da revisão bibliográfica dos conceitos abordados para este
trabalho, tais como:
O Capítulo 2 descreve todo o referencial teórico pesquisado sobre os conceitos de Gerência de Projetos, focando nas práticas do PMBOK, e também trata da metodologia Project Model Canvas e sua contribuição para a concepção de projetos.
O Capítulo 3 apresenta a Ferramenta Gestão Integrada, descrevendo suas características,
mapeando e comparando suas funcionalidades com as áreas do PMBOK.
No Capítulo 4 é feita uma comparação com funcionalidades de outras ferramentas disponíveis no mercado.
No Capítulo 5 é descrita a ferramenta resultante deste trabalho, com representação gráfica
da modelagem e descrição do seu funcionamento, utilizando um exemplo prático.
O Capítulo 6 apresenta as conclusões e os resultados obtidos com a realização do trabalho, e ainda sugere trabalhos futuros.
O Anexo I apresenta o manual de uso da API REST resultante do desenvolvimento da ferramenta.
14
2 GERENCIAMENTO DE PROJETOS
2.1 Conceitos
Segundo PMI (2014) o gerenciamento de projetos é “a aplicação do conhecimento, habilidades, ferramentas e técnicas às atividades do projeto para atender aos seus requisitos.”. De
acordo com a SOFTEX (2012), “o propósito do processo Gerência de Projetos é estabelecer e
manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como
prover informações sobre o andamento do projeto que permitam a realização de correções
quando houver desvios significativos no desempenho do projeto”. Já segundo a ISO 1006
(1997), o gerenciamento de projetos “inclui o planejamento, organização, supervisão e controle de todos os aspectos do projeto, em um processo contínuo, para alcançar seus objetivos”.
O ciclo de desenvolvimento de softwares é composto de diversas fases, entre elas uma das
mais importantes é a de Gerenciamento de Projetos, que visa a realizar com antecedência uma
estimativa de quais recursos serão necessários durante o ciclo de vida do projeto, bem como a
previsão de quanto tempo será necessário para realização do mesmo. Além disso, através do
Gerenciamento de Projetos é possível que ocorra um acompanhamento do progresso do projeto, com o objetivo de verificar se os prazos e o orçamento estão sendo ou não cumpridos
(PFLEEGER, 2004).
2.2 PMBOK
O Guia PMBOK (Project Management Body of Knowledge) é um padrão de gerenciamento de projetos que contém normas, métodos, processos e práticas. De acordo com PMI
(2014), o PMBOK expõe, na forma de um framework, os processos de gerenciamento de projetos e suas melhores práticas. O guia não propõe uma metodologia para a aplicação destas
práticas, deixando que o gerente de projeto e sua equipe definam a melhor forma de agir de
acordo com as peculiaridades da organização.
2.2.1 Fases do Projeto
Segundo o Guia PMBOK, um projeto (ou suas etapas) podem ser divididas em cinco fases:
a) Iniciação: nesta fase são realizados processos que definem e autorizam uma nova etapa ou
projeto;
15
b) Planejamento: onde são realizadas tarefas como definição de escopo do produto e do projeto, refinamento e detalhamento dos requisitos e objetivos e desenvolvimento de um plano de ação;
c) Execução: onde o trabalho é realizado de acordo com as decisões das fases iniciais;
d) Monitoramento e Controle: verificação do trabalho realizado na execução, de forma a verificar a adequação aos requisitos do projeto, bem como as possíveis correções;
e) Encerramento: realização dos trâmites formais para finalização da etapa ou do projeto.
2.2.2 Áreas do Conhecimento
O Guia PMBOK categoriza os 47 processos de gerenciamento de projetos em dez áreas
do conhecimento (ilustradas na Figura 1), conforme destaca PMI (2014, p. 60):
“Uma área do conhecimento representa um conjunto completo de conceitos, termos
e atividades que compõem um campo profissional, campos de gerenciamento de
projetos, ou uma área de especialização. Essas dez áreas do conhecimento são usadas na maior parte dos projetos, na maioria das vezes.”
Figura 1: Representação gráfica das áreas do conhecimento do PMBOK. Fonte: PMI (2014).
2.2.2.1 Integração
Segundo o PMI (2014), esta área do conhecimento reúne processos que identificam, definem, combinam, unificam e coordenam os demais grupos de processos. A integração define
como será a alocação de recursos e prioridades, assim como o controle do relacionamento entre outras áreas de conhecimento e processos.
16
Os seguintes processos compõem a área de integração:
●
Desenvolver o termo de abertura: processo onde desenvolve-se o documento responsável
pela autorização formal para a existência do projeto, além da nomeação do gerente responsável pelo mesmo. Neste processo é gerado o termo de abertura do projeto, onde são
relatadas as necessidades do negócio, premissas, restrições, o entendimento das necessidades e requisitos de alto nível do cliente e o resultado previsto.
●
Desenvolver o plano de gerenciamento do projeto: processo onde integram-se todos os
planos auxiliares em um único plano de gerenciamento de projeto. Segundo PMI (2014), o
plano de gerenciamento de projeto define a forma de execução, monitoramento e controle
do projeto, integrando todos os planos de gerenciamento auxiliares e linhas de base do
projeto. Além disso, o plano de gerenciamento de projeto inclui outros documentos como:
o ciclo de vida do projeto e listagem de processos aplicados em cada fase, detalhamento
das decisões relativas às adequações especificadas pela equipe do projeto, descrição de
como o trabalho será realizado, plano de gerenciamento de mudanças, plano de gerenciamento de configuração, descrição de como será a manutenção da linha de base do projeto
e requisitos e técnicas de comunicação. Este plano pode ser produzido de maneira detalhada ou reduzida, de acordo com as necessidades de cada projeto. Para que sejam realizadas
alterações no plano de projeto após sua aprovação é necessário que seja realizada primeiramente uma solicitação de mudanças formal.
●
Orientar e gerenciar o trabalho do projeto: processo onde se realiza e coordena a realização do trabalho do projeto, visando o atingimento dos objetivos do mesmo.
●
Monitorar e controlar o trabalho do projeto: processo responsável por acompanhar o progresso do projeto, de forma a atingir os objetivos de desempenho definidos no plano de
gerenciamento do projeto.
●
Realizar o controle integrado de mudanças: processo responsável pelo gerenciamento das
mudanças realizadas nos artefatos do projeto, bem como o controle de aprovação das solicitações.
●
Encerrar o projeto ou fase: processo responsável pela finalização das atividades, de forma
a possibilitar o encerramento formal das fases ou do projeto.
2.2.2.2 Escopo
Segundo o PMI (2014), a área do conhecimento do Escopo objetiva delimitar qual o trabalho necessário para a conclusão do processo, assegurando que trabalhos desnecessários não
sejam realizados. O PMI entende que não se deve entregar mais do que o cliente solicitou, pois
isso pode trazer riscos ao projeto, como, por exemplo, a insatisfação do cliente com o resulta-
17
do apresentado. A área de Escopo trata de processos referentes ao escopo do produto e também do projeto:
●
Escopo do produto: características referentes ao produto, serviço ou resultado final;
●
Escopo do projeto: descrição do trabalho que deve ser realizado para entregar o produto,
serviço ou resultado especificado pelo cliente.
Os processos abaixo pertencem a área de Escopo:
●
Planejar gerenciamento de escopo: processo responsável por definir quais serão as ferramentas, técnicas e procedimentos utilizados no gerenciamento do escopo, que por sua vez
determina como os demais processos de gerenciamento de escopo serão realizados. Neste
processo, por exemplo, são definidas as responsabilidades e um processo formal de controle e registro de mudanças. Ao final deste processo são gerados um plano de gerenciamento de escopo e um plano de gerenciamento dos requisitos;
●
Coletar requisitos: processo onde são definidos os requisitos do resultado do projeto. Segundo PMI (2014), requisitos são necessidades quantificadas, documentadas e priorizadas
das partes interessadas. Este processo influencia diretamente no resultado final do projeto,
pois uma identificação incompleta ou incorreta das expectativas das partes interessadas
pode ocasionar em um grande número de mudanças durante o ciclo de vida do mesmo.
Como resultado deste processo, é gerada a documentação de requisitos e a matriz de rastreabilidade dos requisitos:
●
Documentação dos requisitos: descreve os requisitos do projeto e como os mes-
mos atendem às necessidades de negocio do projeto. Pode ser uma lista simples ou
um documento mais elaborado com resumo e anexos. O documento deve incluir: necessidades do negócio, objetivos do projeto, requisitos funcionais, não funcionais e de
qualidade, critérios de aceitação, impactos em outras áreas e negócios, requisitos de
suporte e treinamento e premissas e restrições dos requisitos. Além disso, é importante fazer uma matriz de rastreabilidade dos requisitos, que ajuda a assegurar a entrega
do valor agregado prometido do projeto.
●
Definir escopo: processo responsável pela descrição detalhada do projeto e do produto,
baseando-se nos requisitos, nas premissas e nas restrições do projeto. Como resultado
deste processo é gerada a declaração de escopo do projeto, que descreve quais serão as
entregas e o trabalho necessário para criá-las. Este documento deve ser aprovado pelas
partes interessadas no projeto e sempre ser atualizado.
●
Criar Estrutura Analítica do Projeto (EAP): segundo PMI (2014), neste processo é realizada a subdivisão das entregas e do trabalho do projeto em partes menores, objetivando
facilitar o gerenciamento do trabalho. Essa subdivisão é denominada Estrutura Analítica
18
do Projeto e a somatória dos níveis inferiores, conhecidos como pacotes de trabalho, devem compor o resultado total do projeto. Na EAP todos os produtos e trabalhos gerados
pelo projeto devem ser representados, inclusive os de gerenciamento.
●
Verificar Escopo: neste processo são formalizadas as aceitações das entregas concluídas
no projeto, envolvendo a revisão das entregas pelo cliente ou patrocinador. Desta forma, é
assegurado que o projeto atende às expectativas e identifica-se a necessidade de solicitações de mudanças.
●
Controlar Escopo: processo onde se verifica o andamento da execução do escopo do projeto e do produto. Inclui o gerenciamento das mudanças, assegurando que as mesmas sejam processadas e que as ações corretivas e preventivas sejam realizadas. Além disso são
realizadas medições de desempenho do trabalho realizado no projeto e atualizações de documentos do projeto, quando necessário.
2.2.2.3 Tempo
De acordo com PMI (2014), a área de conhecimento do Tempo objetiva estimar a duração
do projeto e suas atividades, criando um cronograma e monitorando o mesmo. Esta área engloba os seguintes processos:
●
Planejar gerência do tempo: processo que identifica a metodologia utilizada para o gerenciamento e controle do cronograma. Ou seja, define como serão realizados os demais processos de gerenciamento de tempo. Ao final do mesmo, será gerado um plano de gerenciamento do tempo.
●
Definir atividades: neste processo, os pacotes de trabalhos previstos na Estrutura Analítica
do Projeto são decompostos em tarefas que serão realizadas para a execução do projeto.
A lista de tarefas deve identificar o escopo do trabalho de cada atividade, de maneira detalhada ao ponto em que os membros da equipe consigam identificar qual o trabalho necessita ser executado. É importante relacionar as tarefas aos níveis da EAP e aos requisitos,
para proporcionar a rastreabilidade das mesmas. Neste processo também devem ser identificados os marcos do projeto.
●
Sequenciar atividades: segundo PMI (2014), neste processo as atividades do projeto são
relacionadas e colocadas em sequência. Neste processo também são definidas as dependências entre as atividades. Ao final deste processo são criados diagramas de rede do cronograma do projeto, que demonstram as relações lógicas entre as atividades.
●
Estimar os recursos das atividades: objetiva estimar quais recursos humanos, materiais e
financeiros serão necessários para realizar cada uma das atividades do projeto. É impor-
19
tante que o gerente de projeto faça essa estimativa da maneira mais correta possível, pois
eles são essenciais para um bom planejamento.
●
Estimar a duração das atividades: processo responsável por estimar quanto tempo será necessário para realizar as atividades do projeto, utilizando os recursos definidos no processo anterior.
●
Desenvolver o cronograma: neste processo é criado o cronograma do projeto, baseandose nas informações coletadas nos processos anteriores. O cronograma gerado pode ser de
vários tipos, como um gráfico de marcos, um gráfico de barras ou diagramas de rede. Na
prática, o cronograma deve ser um dos últimos documentos a ser concluído durante o planejamento. Além disso, o patrocinador do projeto deve concordar formalmente com o cronograma quando ele estiver finalizado.
●
Controlar o cronograma: processo responsável por monitorar o andamento do projeto e
manter o cronograma em caso de mudanças.
2.2.2.4 Custo
Conforme PMI (2014), a área de conhecimento do Custo define processos que estimam os
custos orçamentários do projeto e suas atividades, criando um orçamento estimado e monitorando os gastos durante o ciclo de vida. Esta área engloba os seguintes processos:
●
Planejar gerenciamento do custo: processo que identifica como será realizado o gerenciamento e controle dos custos do projeto. Este processo terá como saída um plano de gerenciamento do custo.
●
Estimar custos: tem como objetivo estimar quais recursos monetários serão necessários
para realizar cada uma das atividades do projeto. Este processo deve identificar alternativas de custos e possíveis riscos. Também é importante que se busque a melhor eficiência
dos custos.
●
Determinar o orçamento: processo responsável por agregar os custos das atividades, de
forma a estabelecer a linha de base dos custos. Ao final deste processo é gerado o orça mento do projeto, onde também deve-se levar em conta as reservas de contingência e gerenciais.
●
Controlar os custos: processo responsável por monitorar o orçamento do projeto durante
o ciclo de vida, de forma a verificar se o orçamento está sendo seguido e atualizar o mesmo quando necessário.
20
2.2.2.5 Qualidade
Segundo PMI (2014), os processos da área de conhecimento da Qualidade visam determinar as políticas de qualidade do projeto, para que o mesmo possa satisfazer as necessidades levantadas no planejamento inicial. Esta área engloba os seguintes processos:
●
Planejar o gerenciamento da qualidade: processo responsável pelo levantamento dos requisitos e padrões de qualidade do projeto e por documentar o método de demostração da
conformidade do projeto. Além disso, define como os outros processos de qualidade serão
executados.
●
Realizar a garantia da qualidade: este processo realiza as auditorias dos processos, de forma a garantir que estão sendo realizados de acordo com os requisitos de qualidade. Este
processo pode gerar, inclusive, solicitações de mudanças visando a melhoria da qualidade.
●
Controlar a qualidade: neste processo é realizado o monitoramento e o registro das medições da qualidade do projeto, durante todo o ciclo de vida do mesmo. Enquanto o processo anterior é executado durante a execução das atividades, este é realizado após as entregas, de forma a garantir que os requisitos estão sendo cumpridos.
2.2.2.6 Recursos humanos
De acordo com PMI (2014), os processos da área de conhecimento de Recursos Humanos
objetivam gerenciar os recursos humanos do projeto, assegurando que serão utilizados da melhor maneira possível. Esta área é dividida em quatro processos:
●
Planejar o gerenciamento dos recursos humanos: processo responsável pela identificação e
documentação dos papéis, responsabilidades, hierarquia e habilidades necessárias do projeto. Neste processo também são identificadas as possíveis necessidades de treinamento do
pessoal e contratação de profissionais. Entre os resultados deste processo está o organograma do projeto, além dos planos de gerenciamento de recursos humanos e gerenciamento de pessoal.
●
Mobilizar a equipe do projeto: este processo verifica a disponibilidade de pessoal e define
a equipe designada para o projeto.
●
Desenvolver a equipe do projeto: neste processo é realizada a melhoria das competências,
da integração e do ambiente da equipe, de forma a manter a equipe motivada e ciente das
necessidades e objetivos do projeto.
●
Gerenciar a equipe do projeto: processo responsável pelo acompanhamento da equipe do
projeto, de forma a garantir a execução do trabalho, resolver conflitos, esclarecer atribuições e responsabilidade e gerenciar mudanças.
21
2.2.2.7 Comunicações
Segundo PMI (2014), os processos de comunicação garantem que todo o conhecimento
gerado no projeto seja coletado, possibilitando sua posterior utilização, comunicando aos envolvidos quando necessário. Esta área engloba os seguintes processos:
●
Planejar gerenciamento das comunicações: processo que define como serão atendidas as
necessidades de informação dos envolvidos no projeto, definindo ações e atividades de comunicação.
●
Gerenciar comunicações: este processo é responsável por disponibilizar as informações
coletadas às partes interessadas no projeto, colocando em prática as ações definidas no
processo acima.
●
Controlar comunicações: garante que as necessidades de comunicação estão sendo supridas, de acordo com as ações estabelecidas no plano de gerenciamento das comunicações.
2.2.2.8 Riscos
Conforme PMI (2014), os processos da área de conhecimento de Riscos se referem à
identificação, análise, controle e planejamento de reações aos possíveis riscos do projeto. Eles
tem como objetivo diminuir os efeitos negativos e, ao mesmo tempo, potencializar os impactos
positivos dos possíveis riscos do projeto. Esta área engloba os seguintes processos:
●
Planejar gerenciamento dos riscos: processo que define como serão conduzidas as atividades de gerenciamento de riscos do projeto. Como resultado deste processo, será gerado o
Plano de Gerenciamento de Riscos, contendo as seguintes informações: metodologia, papéis e responsabilidades, orçamento, prazos, categorias de riscos, definições de probabilidade e impacto dos riscos, matriz de probabilidade e impacto, tolerâncias, formatos dos
relatórios e método de acompanhamento.
●
Identificar riscos: este processo é responsável por identificar e documentar os riscos que
podem ocorrer no projeto, registrando características e impactos. Toda a equipe deve ser
estimulada a participar deste processo, de forma a melhorar a eficácia do mesmo.
●
Realizar análise qualitativa dos riscos: neste processo, os riscos levantados no processo
anterior são analisados para definição de prioridades, levanto em conta a probabilidade de
ocorrência e possíveis impactos dos mesmos. Este processo deve ser revisto durante todo
o ciclo de vida do projeto.
●
Realizar análise quantitativa dos riscos: processo que analisa numericamente os efeitos dos
riscos priorizados no processo anterior. Esta análise é utilizada para atribuir uma classificação numérica individual aos riscos ou um valor agregado do projeto como um todo.
22
●
Planejar resposta a riscos: processo responsável por identificar quais serão as atitudes tomadas na ocorrência dos riscos previstos, identificando também quem serão os responsáveis pelas mesmas. Também são realizadas as previsões orçamentárias e de cronograma relacionados às respostas aos riscos.
●
Monitorar e controlar riscos: processo que implementa as respostas aos riscos, acompanha
os riscos, identifica novos riscos e avalia a eficácia do planejamento. Esse processo pode
incluir a definição de estratégias alternativas a adoção de ações corretivas e atualizações
no Plano de Gerenciamento do Projeto.
2.2.2.9 Aquisições
Segundo PMI (2014), os processos da área de conhecimento de aquisições são aqueles referentes a compras de bens e serviços para o projeto. Os processos de contratação de consultores também são considerados como da área de aquisições. O gerenciamento de contratos
também faz parte dessa área. Esta área engloba os seguintes processos:
●
Planejar gerenciamento de aquisições: processo de registro das decisões de compras do
projeto, onde se define como será a abordagem e buscando fornecedores em potencial.
Também são identificadas as necessidades do projeto que devem ser melhor atendidas com
aquisição de serviços ou produtos externos, levando em conta os custos e o cronograma
do projeto.
●
Realizar aquisições: processo onde as aquisições detectadas no processo acima são efetivamente realizadas, por meio de licitação ou recebimento de propostas.
●
Controlar aquisições: processo de acompanhamento das aquisições realizadas, objetivando
identificar se os contratos estão sendo cumpridos e se os objetivos estão sendo atendidos.
2.2.2.10 Partes interessadas
De acordo com PMI (2014), esta área de conhecimento é responsável pela identificação
dos stakeholders do projeto, com o objetivo de gerenciá-los para que se comprometam com o
projeto. Esta área possui os seguintes processos:
●
Identificar partes interessadas: processo que identifica todas as pessoas ou organizações
envolvidas ou afetadas pelo projeto, documentando seus interesses, envolvimento e impacto no projeto.
●
Planejar o gerenciamento das partes interessadas: processo responsável por analisar de
maneira mais detalhada os interessados no projeto e definir estratégias para esses relacionamentos.
23
●
Gerenciar o engajamento das partes interessadas: processo em que se realiza a interação
com as partes interessadas, objetivando atender às suas necessidades, aumentar a aceitação do projeto, abordar preocupações ainda não atendidas e esclarecer as mesmas.
●
Controlar o engajamento das partes interessadas: processo de acompanhamento do relacionamento com as partes interessadas, objetivando melhorar o engajamento das mesmas,
podendo inclusive realizar ajustes e inclusão de novos stakeholders.
2.3 PROJECT MODEL CANVAS
2.3.1 Introdução
Project Model Canvas (PMC) é uma nova metodologia de gerenciamento de projetos, que
objetiva uma maior agilidade e menos burocracia que os métodos tradicionais. A metodologia
foi criada pelo professor José Finocchio Júnior, especialista em gerenciamento de projetos. Segundo Finocchio (2013), a metodologia foi criada com o intuito de possibilitar que os gerentes
de projeto passem a realmente planejar os projetos dentro de suas organizações, tendo em vista
que as metodologias mais tradicionais tem demonstrado baixa eficiência.
O PMC tem como base a ideia de modelos mentais do projeto, formados por conceitos
(como recursos, stakeholders, equipe, requisitos) e as relações entre esses conceitos. Quando
estudamos um determinado projeto, geralmente armazenamos um modelo mental de como funcionaria o mesmo, já que não conseguimos armazenar todas as informações. Esses modelos
tendem a ser imprecisos, por isso devemos aprimorá-los por meio de prática, tempo ou de debates. Para isso foi criado o Project Model Canvas, que pode ser utilizado tanto como única
representação do projeto quanto como uma base para a posterior confecção de um plano de
projeto tradicional (FINOCCHIO, 2013).
De acordo com Finocchio (2013), uma das grandes vantagens do Project Model Canvas é
que a confecção do plano pode ser feita de maneira muito prática, necessitando somente de
uma folha A1 e post-its. Essa folha A1 é utilizada como tela de fundo, também conhecida como
canvas, para a confecção do plano de projeto. Esse canvas é preenchido pelos post-its com o
auxílio dos envolvidos do projeto em reuniões e buscando ser o mais sucinto possível nas descrições.
A construção do canvas é feita em 4 etapas:
a) Conceber: etapa em que são respondidas as 6 perguntas fundamentais: Por que? O que?
Quem? Como? Quando? e Quanto?;
b) Integrar: etapa em que se verifica se os blocos estão coesos entre si;
24
c) Resolver: etapa em que são resolvidas as possíveis inconsistências encontradas na etapa
anterior e as informações faltantes;
d) Comunicar/Compartilhar: etapa em que o canvas passa a ser base para a confecção de outros documentos do projeto.
Para a construção do canvas recomenda-se uma equipe com pelo menos 3 ou 4 pessoas e
que mescle pessoas mais experientes e novatos (FINOCCHIO, 2013).
2.3.2 Conceber o Plano
De acordo com Finocchio (2013), o canvas é dividido em 5 perguntas e 13 componentes
que devem ser preenchidos na ordem em que estão dispostos, de forma subsequente:
a) Por que? : Justificativa, Objetivos e Benefícios;
b) O que? : Produto e Requisitos;
c) Quem? : Stakeholders externos e Equipe;
d) Como? : Premissas, Grupos de entrega e Restrições;
a) Quando e Quanto? : Riscos, Linha do tempo e Custos;
As perguntas são representadas no canvas com cores diferentes de forma a facilitar a visualização das mesmas, conforme pode ser visualizado na Figura 2. Essa ordem das perguntas foi
prevista de forma a facilitar a resposta da pergunta posterior, agilizando o processo de concepção.
Figura 2: Canvas dividido por cores. Fonte: FINOCCHIO (2013)
25
2.3.2.1 Por que fazer o projeto?
Para Finocchio (2013), esta seção objetiva descobrir quais motivos levaram a organização
a verificar a necessidade de realização do projeto em questão. Esta fase é muito importante,
pois falhas nesta concepção podem levar aos seguintes problemas:
●
Projeto pode não atender à demanda: um levantamento inadequado dos problemas que
justificam o projeto pode fazer com que o objetivo seja estabelecido de maneira inadequada. Essa inadequação pode fazer com que o projeto não gere os benefícios desejados pela
organização.
●
Problemas de qualidade do projeto: uma falta de definição da qualidade necessária do produto gerado pelo projeto resulta na baixa qualidade do mesmo, gerando novos investimentos para futuras adequações.
●
Inutilidade do projeto: os gastos realizados pela organização com o projeto não são recompensados com ganhos reais para a mesma.
●
Projeto não altera a situação da organização: o projeto não trará benefícios para a organização, não melhorará os indicadores de desempenho da mesma.
●
Projeto gera problemas a organização: ao invés de trazer benefícios para a organização, o
projeto deixará a mesma numa situação inferior a que se encontrava anteriormente, devido
a uma má concepção ou problemas de gestão.
●
Projeto superavaliado: utilização de soluções exageradas, gerando custos desnecessários
para a organização. Os mesmos objetivos poderiam ser alcançados com menos esforços da
organização.
●
Projeto inacabado: devido a erros na previsão dos custos e riscos do projeto, a organização não possui recursos financeiros ou humanos para a finalização do mesmo.
●
Projeto impossível: a definição de objetivos foi feita de maneira pouco realista, sendo inviável a realização dos mesmos.
2.3.2.1.1 Justificativa
Conforme Finocchio (2013), nesta seção do canvas, devem ser descritos os motivos para
a organização iniciar o projeto, de forma sucinta e objetiva. São exemplos de motivos: problemas que devem ser solucionados, oportunidades de ganhos para a organização, necessidades
de negócio e obrigações legais ou normativas. Se for o caso de um projeto vendido a outra or ganização, devem ser descritas também as justificativas da organização adquirente. É importante que, após finalizar o preenchimento da seção, os post-its sejam organizados em ordem de
importância, de forma a definir quais são mais relevantes.
26
2.3.2.1.2 Objetivo
Nesta seção, deve ser descrita a finalidade do projeto, de maneira clara e objetiva em um
ou dois post-its, seguindo um critério conhecido como S.M.A.R.T. (Specific Measurable Attainable Relevant Timely), que define que um objetivo deve seguir as seguintes diretrizes:
●
Específico: o objetivo deve utilizar adjetivos e qualificadores suficientes para elucidar o
projeto;
●
Mensurável: devem haver critérios objetivos para verificar se o objetivo foi atingido;
●
Alcançável: a organização possui os meios necessários para realizar o objetivo;
●
Realista: é possível alcançar o objetivo com o tempo e recursos disponíveis;
●
Delimitado no tempo: definição de um prazo para conclusão do projeto;
2.3.2.1.3 Benefícios
Nesta seção Finocchio (2013) propõe que devem ser descritos quais benefícios a organização deseja atingir com a realização do projeto com critérios quantificáveis para uma posterior
validação do atingimento destes benefícios pelo projeto. Além disso, é importante que os benefícios dialoguem com as justificativas e o objetivo. Assim como na seção de justificativas, é importante que os benefícios mais importantes sejam colocados primeiramente no canvas.
2.3.2.2 O que produz o projeto?
De acordo com as explanações de Finocchio (2013), qualquer projeto tem o objetivo de
gerar algum tipo de produto, seja para a organização responsável pelo projeto, seja para o cliente que o adquiriu. Este projeto deve atender a determinados requisitos para atender corretamente aos objetivos da organização, originando assim a qualidade deste produto. Nem sempre
o cliente consegue definir de modo claro quais são estes requisitos, por isso a importância da
participação dos mesmos neste processo.
2.3.2.2.1 Produto
Como ressalta Finocchio (2013), no Project Model Canvas, o canvas de produto deve
descrever o que vai ser entregue ao cliente no final do projeto, seja um produto, um serviço ou
um resultado. Uma boa forma de entender o conceito é levar em conta o seguinte exemplo:
●
Uma empresa de tecnologia da informação desenvolve um sistema de controle financeiro
de uma instituição de ensino, entregando um produto, o software pronto.
●
A mesma empresa cria um projeto para fazer a migração de dados de outro software do
mercado de clientes interessados, gerando um serviço;
●
Se esta empresa decide obter uma certificação de qualidade de software do MPS.Br, vai
gerar um resultado.
27
2.3.2.2.2 Requisitos
Finocchio (2013) salienta que os requisitos são as definições das características do produto gerado pelo projeto, de forma a atender às necessidades do cliente. No Project Model Canvas é importante que os requisitos sejam detalhados da forma mais simples possível para que,
posteriormente, os envolvidos no projeto estudem os mesmos de maneira mais precisa.
No canvas, deve-se preencher primeiramente com requisitos de comportamento e de características do produto final, seguidos por requisitos de qualidade, desempenho e confiabilidade.
Durante o processo de preenchimento do canvas é importante que a equipe envolvida saiba que este é somente um processo inicial de levantamento dos requisitos, para que não detalhe muito e para que o cliente saiba que estes requisitos podem, e devem, ser evoluídos posteriormente.
No final do preenchimento, é importante ordenar os requisitos de acordo com o grau de
prioridade, diferenciando os essenciais dos desejáveis.
2.3.2.3 Quem trabalha no projeto?
Como esclarece Finocchio (2013), esta pergunta é muito importante, por possibilitar um
entendimento amplo dos limites do problema a resolver, além de permitir um maior controle
sobre as informações do projeto. Deve-se fazer uma análise de quem vai executar cada fase do
projeto e das pessoas / organizações envolvidas no mesmo.
2.3.2.3.1 Stakeholders Externos
Nesta seção, deve-se listar todos os envolvidos no projeto, sejam pessoas ou organizações, que não estejam diretamente envolvidos na execução do mesmo. A importância desse
mapeamento reside no fato da motivação destes envolvidos pode ter papel crucial na continuidade ou não do projeto (FINOCCHIO, 2013).
Para que não se perca tempo monitorando stakeholders desnecessários, deve-se listar somente os que requerem atenção extra, como o patrocinador ou o cliente do projeto.
●
Patrocinador: pessoa ou organização que disponibilizará os recursos para realização do
projeto ou que possui autoridade para fazê-lo.
●
Cliente: pessoa ou organização que se beneficiará diretamente dos produtos do projeto,
que deve participar ativamente do levantamento de requisitos.
Em alguns casos, pode ocorrer de uma mesma pessoa ou organização acumular a função
de cliente com a de patrocinador, quando isso ocorrer é importante registrar no canvas as duas
funções separadamente.
28
Além destas funções, fornecedores de matéria-prima, órgãos regulatórios, órgãos de governos e departamentos organizações, além de outros, podem ser considerados como stakeholders externos.
2.3.2.3.2 Fatores Externos
Conforme explicita Finocchio (2013), com o objetivo de obter-se um melhor planejamento, é importante observar os fatores externos que podem afetar de alguma forma o projeto, durante seu ciclo de vida. Entre esses fatores podemos destacar os seguintes: desenvolvimento
econômico, clima, avanços tecnológicos, produtividade, disponibilidade de recursos, normas
regulatórias e questões culturais do local de implementação.
2.3.2.3.3 Equipe do Projeto
O preenchimento desta seção deve ser feito de forma a identificar os papéis executados
pela equipe do projeto, tendo em vista que, provavelmente, na fase inicial do mesmo não seja
possível saber quais serão as pessoas envolvidas diretamente no mesmo. É importante que todos os envolvidos sejam listados, mesmo que tenham um papel secundário ou temporário, de
forma a mapear corretamente estas informações (FINOCCHIO, 2013).
2.3.2.4 Como vamos entregar o projeto?
Segundo Finocchio (2013), quando se planeja um projeto se baseando em atividades, criase um problema de impossibilidade de planejar da maneira mais apropriada, deixando brechas
para uma previsão inadequada, além de gerar insatisfação na equipe envolvida, devido a uma
sensação de que as tarefas são intermináveis.
Por isso, alguns gerentes de projeto optam por planejar projetos baseando-se em entregas
no lugar de tarefas. Desta forma, a equipe se sente mais motivada e estável, possibilitando que
se organizem com mais eficiência. Esta seção do projeto trata justamente da definição de como
serão feitas essas entregas.
2.3.2.4.1 Premissas
Durante o ciclo de vida de um projeto, vários fatores externos à influencia e ao controle
do gerente de projeto podem afetar o cumprimento das entregas previstas dentro do prazo
programado. Como forma de se resguardar caso esses problemas venham a ocorrer, nesta caixa serão feitas suposições sobre como esses fatores devem se comportar para que os prazos
sejam cumpridos (FINOCCHIO, 2013).
Desta forma, o gerente de projeto deixa claro quais são as condições para que as promessas de tempo e custo valerão. Caso alguma dessas premissas sejam consideradas falsas, será
necessário que as entregas relativas a elas sejam renegociadas.
29
Estas premissas devem ser preenchidas de maneira afirmativa, demonstrando que a realização destas viabilizam o projeto da forma como foi planejado.
2.3.2.4.2 Entregas
De acordo com Finocchio (2013), de forma a planejar melhor o projeto, é importante dividir o mesmo em vários componentes ou partes que serão entregues em várias fases do ciclo de
vida e que juntos assegurarão a conclusão do projeto. Esses componentes são denominados
como entregas e devem ser facilmente identificáveis pelo cliente.
Todo trabalho realizado no projeto deve ser empreendido com o objetivo de contribuir diretamente para efetuação destas entregas. Para que algumas entregas sejam identificadas é importante que alguns membros da equipe técnica do projeto participem da criação do canvas do
projeto, tendo em vista que essas pessoas possuem um conhecimento mais aprofundado do trabalho a ser realizado. (Finocchio, 2013)
É importante que, no preenchimento, mantenha-se o foco nas entregas mais importantes,
para que o entendimento do projeto se torne mais fácil e que fique claro como as mesmas se
complementam. Caso exista um grande número de entregas previstas, deve-se fazer um esforço para simplificá-las ou agrupá-las em uma quantidade menor.
2.3.2.4.3 Restrições
Conforme afirma Finocchio (2013), todo projeto possui determinadas restrições que limitam a atuação do mesmo, por isso é importante que a equipe avalie anteriormente a existência
das mesmas, para poder atuar da melhor forma quando ocorrerem. Além disso, uma avaliação
incompleta das restrições pode resultar numa previsão errada de custos e prazos.
Dentre as restrições, podemos exemplificar:
●
Limitações de período de realização do trabalho
●
Pouca disponibilidade de recursos humanos e de equipamentos
●
Restrições de logística
●
Dificuldades no descarte de resíduos
●
Adequação a contratos já firmados
●
Dependência entre entregas do projeto
●
Observância de seguimento de padrões tecnológicos
Para um correto preenchimento das restrições é importante indicar quem é afetado e quem
impõe cada uma delas, além de descrevê-las de maneira específica e quantificável.
30
2.3.2.5 Quando o projeto será concluído e quanto custará?
Geralmente o planejamento de um projeto começa com uma previsão de custos e de prazos, porém, na metodologia do Project Model Canvas, estas previsões são, propositalmente,
deixadas para o final do planejamento. Isso ocorre porque qualquer previsão desta natureza
sem os dados obtidos nas outras seções do canvas tende a ser inexata. Um entendimento claro
do que o projeto propõe é essencial para um correto planejamento neste sentido (FINOCCHIO, 2013).
O Project Model Canvas faz uma abordagem simplificada do cronograma e do orçamento
do projeto, de forma a possibilitar a validação e integração dos artefatos do plano de projeto.
O canvas serve apenas como referência para uma posterior análise minuciosa do cronograma e
da planilha de custos do projeto.
2.3.2.5.1 Riscos
Conforme previu Finocchio (2013), nesta seção do canvas, devemos descrever quais são
as incertezas que podem, de alguma forma, interferir na realização dos objetivos do projeto.
Os riscos devem ser levantados para que possam ser gerenciados de maneira a não causar problemas. O processo de gerenciamento de riscos foi tratado no Capítulo 2.2.2.8 deste trabalho.
Por ter um impacto muito grande no ciclo de vida do projeto, é importante que a equipe
disponibilize um bom tempo para identificar os riscos. Para que esse trabalho seja mais efetivo,
recomenda-se que os outros componentes do canvas sejam estudados em busca de possíveis
riscos relacionados a eles.
Cada risco deve ocupar um post-it de tamanho grande, com as seguintes informações:
●
Causa: condição responsável pela existência do risco;
●
Risco: acontecimento possível de ocorrer que pode se tornar um problema ou oportunidade pertinente ao projeto
●
Efeito: consequências ao projeto
Além de identificar os riscos, é importante que sejam definidos graus de probabilidade de-
les ocorrerem, além de uma escala de impacto dos mesmos.
2.3.2.5.2 Linha do tempo
Como analisa Finocchio (2013), os prazos do projeto são estabelecidos de acordo com a
experiência das pessoas que elaboram o canvas e com as informações coletadas nas outras seções. A principal função da elaboração da linha do tempo é diminuir a incerteza relacionada aos
prazos, de forma a viabilizar a tomada de decisões. Infelizmente, não é possível eliminar estas
incertezas completamente.
31
A linha do tempo do canvas trata de compromissos, ou seja, de data definidas para que sejam realizadas as entregas previstas. Desta forma, o gerente de projeto terá dados suficientes
para uma posterior construção de um cronograma mais completo.
Nesta seção do canvas, o ciclo de vida do projeto é dividido em 4 partes e são utilizados
post-its para marcar em qual intervalo de tempo as entregas serão realizadas, ao lado dos referidos post-its de entregas.
2.3.2.5.3 Custos
Para Finocchio (2013), no Project Model Canvas, a previsão de custos deve ser feita de
forma bem resumida, dividindo o mesmo por grupos de entregas ou por tipos de custos. O ideal é que estes custos sejam expressos em intervalos de valores para uma posterior avaliação
mais precisa. É importante que os riscos sejam avaliados, para uma possível inclusão de reserva para gastos extras.
2.4 Considerações
Este capítulo abordou os conceitos básicos de Gerenciamento de Projetos e descreveu o
PMBOK, um framework que definie normas, métodos e boas práticas para gerência de projetos. Ele é dividido em cinco fases e contempla dez áreas de conhecimento (Integração, Escopo, Tempo, Custo, Qualidade, Recursos Humanos, Comunicações, Riscos, Aquisições e Partes
Interessadas). A partir destas áreas, é possível conceber, acompanhar e controlar as diversas fases de um projeto, além de estimar custos e mobilizar recursos humanos. Sua aplicação, no entanto, é livre, cabendo à instituição que irá utilizar o framework a escolha de um formato próprio para aplicação que seja compatível com o seu perfil.
Este Capítulo também definiu a metodologia Project Model Canvas como uma metodologia que abandona métodos antigos e burocráticos que não fazem mais sentido para organizações, que buscam cada vez mais em metodologias e ferramentas características como a facilidade de coletar informações de forma colaborativa e enxuta.
Com base em modelos mentais, a proposta de Finnochio possibilita uma organização de
ideias utilizando perguntas simples (Por que, O que, Quem, Como, Quando e Quanto) para
concepção do plano de projeto que permite averiguar sua necessidade e viabilidade, descrevendo as características do projeto e os produtos desejados, resultantes da execução do projeto.
Por conseguinte, permite descrever os envolvidos no projeto, a divisão das atividades na execução do projeto, a estimativa de tempo das atividades, além das restrições, riscos e custos do
projeto.
32
Sabe-se que no início do projeto as informações são imprecisas e nem sempre o que se
discute em sua abertura é seguido a risca durante a execução do mesmo. Por conta disso, Finnochio acelerou os passos para concepção do projeto, focando nos pontos definidos por ele
como os mais importantes para que o projeto entre em execução após diminuir as dúvidas e
após gerar mais clareza de ideias entre os seus participantes.
33
3 FERRAMENTA GESTÃO INTEGRADA
3.1 Descrição
Gestão Integrada é uma ferramenta que fornece meios para planejar, executar e controlar
os processos e os projetos das organizações de forma integrada e com qualidade (SILVA et al.,
2014). A ferramenta fornece funcionalidades de gestão de projetos e possui como base de seu
código-fonte a plataforma Redmine, que foi desenvolvida através da linguagem de programação Ruby e seu framework Rails, e possui como características principais o código aberto, facilidade de extensão e configurações personalizadas (SILVA, BARROSO, PAULINO, 2013).
A Ferramenta Gestão Integrada ganhou o prêmio de melhor projeto do ano de 2013 na categoria Inovação pela revista Mundo Project Management (SILVA et al., 2014).
A ferramenta Gestão Integrada foi desenvolvida, inicialmente, pelo projeto GESTÃO no
Núcleo de Engenharia de Software (NES) do Instituto Federal Fluminense (IFFluminense) e já
foi utilizada em projetos de software mantidos pelo Ministério da Educação (MEC), através da
RENAPI (Rede Nacional de Pesquisa e Inovação em Tecnologias Digitais) – SETEC (Secretaria de Educação Profissional e Tecnológica) e pelo Ministério das Comunicações (MC), através do projeto Formação GESAC (SILVA, et al., 2011). E a ferramenta continua em constante
evolução através de projetos de pesquisa vinculados ao NES.
O usuário pode usufruir de funcionalidades da aplicação baseadas em guias e métodos,
não somente para o ambiente empresarial como também no ambiente acadêmico, agindo como
um facilitador para o aprendizado prático das disciplinas de gerência de projetos e gerência de
processos (SILVA, et al., 2014).
3.2 Funcionalidades
A Tabela 1 (SILVA et al., 2011) relaciona as funcionalidades da ferramenta Gestão Integrada, apontando para cada uma delas a(s) área(s) atendida(as) do PMBOK, identificando as
adaptações executadas no Redmine nativo.
Tabela 1: Funcionalidades Gestão Integrada x Adaptações x Áreas Atendidas. Fonte: (SILVA et
al., 2011)
Funcionalidades Gestão Integrada
Adaptações
Áreas de
Conhecimento
Cadastro de projetos, subprojetos, perfis e permissões disponíveis
Redmine Nativo
Integração, Escopo
e RH
Cadastro de recursos humanos relacionado ao perfil e ao projeto
Redmine Nativo
RH
34
Funcionalidades Gestão Integrada
Adaptações
Áreas de
Conhecimento
Formulário eletrônico
Novo Plug-in
Integração, Escopo
Novo Plug-in
Escopo
Lançamento, controle e consulta das tarefas vinculadas aos pacotes da EAP,
podendo visualizar de forma clara as tarefas em atraso
Redmine Nativo
Configurações
Tempo
Cálculo das estimativas de tamanho e complexidade dos produtos de software
através da Análise de Pontos por função e Caso de Uso
Novo Plug-in
Tempo, Custo e
Aquisição
Formulário Eletrônico
Novo Plug-in
Custo, RH e
Aquisição
Sequenciamento e relacionamento entre as tarefas
Novo Plug-in
Tempo
Cálculo do caminho crítico
Novo Plug-in
Tempo
Redmine Nativo
Configurações
Tempo
Formulário Eletrônico
Novo Plug-in
Risco
Novo Plug-in
RH
Formulário Eletrônico
Novo Plug-in
RH
Redmine Nativo
Integração,
Comunicação e
Qualidade
Formulário Eletrônico
Comunicação
Termo de Abertura do Projeto (TAP) – poderá ser aprovado ou reprovado pelo
cliente. Após aprovação, as fases definidas no ciclo de vida geram os marcos e
pacotes de trabalho da EAP
Estrutura Analítica do Projeto (EAP) – permite o lançamento dos marcos do
projeto, seus pacotes de trabalho e suas subdivisões
Orçamento, contendo o lançamento dos custos de recursos humanos e materiais
envolvidos em cada projeto
Cronograma e visualização de um diagrama de Gantt de acordo com diversos
níveis da EAP, mostrando o status de cada tarefa e identificando as que estão no
prazo e as que estão em atraso
Planejamento e controle dos riscos do projeto (identificação, impacto,
probabilidade, prioridade e plano de mitigação)
Geração da matriz de responsabilidade por nível do EAP
Solicitação de capacitação, o qual será avaliado pelo gerente, gerando uma lista
de capacitações e stakeholders envolvidos
Documentação através de repositórios, documentos e arquivos
Plano de comunicação, identificando o armazenamento e a distribuição das
informações
Plano de projeto desenvolvido na wiki, contendo links para todos os documentos
do projeto e para um tutorial de usuário
Novo Plug-in
Redmine Nativo
Configurações
Integração e
qualidade
Formulário Eletrônico
Novo Plug-in
Qualidade, Riscos
Redmine Nativo
Comunicação
Atas de reuniões, onde a partir do lançamento das deliberações ocorre a geração
automática de tarefas que serão alocadas ao EAP
Formulário Eletrônico
Novo Plug-in
Integração, Escopo,
Tempo e
Comunicação
Plano de ações e metas, onde são lançadas as ações, objetivos e metas de cada
projeto. Cada ação poderá ser aprovada ou reprovada. Após aprovação de uma
ação esta gera um marco na EAP, e seus objetivos e metas geram pacotes de
trabalho
Formulário Eletrônico
Novo Plug-in
Integração, Escopo,
Redmine Nativo
Comunicação
Solicitação e Controle de Eventos, selecionando stakeholders de diversos
projetos. Após a solicitação esta deverá aguardar a aprovação do gerente, quando
aprovada gera solicitações de passagens e diárias quando necessário
Formulário Eletrônico
Novo Plug-in
Comunicação e
Custos
Lançamento e acompanhamento dos requisitos. Após o lançamento de um
requisito, este poderá ser aceito ou rejeitado pelo gerente do projeto para o qual o
requisito foi direcionado. Quando o requisito é aceito, o mesmo gera uma ou mais
tarefas que serão alocadas aos stakeholders do projeto. Estas tarefas estarão
vinculadas aos pacotes da EAP e ao lançar a conclusão das tarefas, o status do
Formulário Eletrônico
Novo Plug-in
(desenvolvido na
ferramenta Fermine do
Escopo e Qualidade
Registro de problemas identificados, registro das ações para corrigir desvios e
para prevenir a repetição dos problemas identificados
Envio de avisos por e-mail
Reuniões virtuais entre os stakeholders através dos fóruns
Tempo, RH e Custo
35
Funcionalidades Gestão Integrada
requisito (que as originou) passará de “em desenvolvimento” para “atendido”
Relatórios Gerenciais: EAP por projeto/subprojeto contendo os pacotes e tarefas;
tarefas em atraso; nº de horas por: stakeholders, tipos de tarefa,
projeto/subprojeto; custo detalhado por projeto, etc.
Adaptações
Áreas de
Conhecimento
Ambiente Integrado)
Novo Plug-in
Abrange todas as
áreas.
Além das funcionalidades da Tabela 1, a Ferramenta Gestão Integrada continua evoluindo
e novas funcionalidades foram incorporadas na ferramenta, como o kanban, o mapa de processos e a automatização da avaliação (SILVA, BARROSO, PAULINO, 2013), o Project Model
Canvas no modo computador e também para quadro inteligente (SILVA et al., 2014).
A ideia do Kanban se mistura com a metodologia Lean, em que é priorizado a redução de
falhas (POPPENDIECK e POPPENDIECK, 2003 apud SILVA, BARROSO, PAULINO,
2013). Na Gerência de Projetos pode-se aplicar o Kanban em nível de controle e acompanhamento do fluxo de trabalho de cada membro da equipe.
Mesmo havendo variações dos campos a serem preenchidos em cada cartão, as informações que este irá prover são de grande relevância para a gerência, pois é possível realizar avaliações quanto a esforço/tempo, dificuldade, atrasos do tempo previsto e critérios de aceitação
de cada tarefa. Na funcionalidade Kanban da ferramenta Gestão Integrada, cada uma das tarefas (com sua descrição, tempo previsto e outros dados já estabelecidos no cartão) será alocada
para os desenvolvedores. Ao ser encerrada, o desenvolvedor completará os dados restantes do
cartão, como tempo gasto e observações, e o moverá para a coluna Finalizado. Com o fluxo de
tarefas do Kanban, pode-se identificar o progresso de cada atividade, a participação de cada
membro da equipe e o desenvolvimento do projeto como um todo;
Dentro do contexto do Mapa de Processos, Oliveira e Neto (2011) apud Silva, Barroso,
Paulino (2013), define o objetivo da modelagem como facilitador do entendimento, do aprendizado, da documentação e da melhoria contínua dos processos, criando o ciclo do processo
de mapeamento. Para isto, a modelagem deve seguir uma metodologia, pois esta direciona os
esforços a partir do levantamento do atual estado do processo, de como deveria ser executado,
até o modo adequado de execução. A funcionalidade de Mapa de Processos possibilita a modelagem do negócio das partes de um projeto ou de todo o projeto através da própria ferramenta
de Gestão. Desta forma o gerente poderá modelar o negócio ao qual o projeto está relacionado
e cada atividade da modelagem estará relacionada a documentos da gerência de projetos (EAP,
TAP, plano de comunicação, matriz de risco e outros) existentes na ferramenta. A modelagem
dos processos segue a notação BPMN (Business Process Modelling Notation), para Pereira et
al. (2009) apud Silva, Barroso, Paulino (2013) esta notação foi desenvolvida com o intuito de
36
ser orientada para negócios de fácil entendimento entre os atores envolvidos. A notação
BPMN unifica os processos de negócios com outras notações e assim elabora as melhores práticas da modelagem de processos;
A funcionalidade Automatização da Avaliação consiste em verificar a existência de formulários eletrônicos preenchidos para os artefatos necessários. Caso exista é alocado o estado
“Atende Parcialmente” como default para o artefato, este estado pode ser alterado pelo usuário (atende completamente, atende parcialmente e não atende) de acordo com as informações
contidas no artefato. O estado pode ser alterado pelos usuários de acordo com as informações
contidas em cada artefato. A ferramenta possibilita a inserção de evidências que complementem
os artefatos detectados automaticamente ou a inserção de novos artefatos com suas evidências.
No trabalho iniciado por Sales (2013), apresentou-se um protótipo para a manipulação e
execução de projetos seguindo os preceitos descritos na metodologia Project Model Canvas.
A partir de então foi possível adicionar à Ferramenta Gestão Integrada a funcionalidade Project Model Canvas no modo computador. Mais adiante, no trabalho desenvolvido por Fernandes (2015) sobre o Project Model Canvas no formato quadro inteligente, os componentes
(canvas, post-its e stakeholders) passaram a ser manipulados através de movimentos e toques
na superfície do quadro inteligente. Este modo facilita a elaboração do plano do projeto de forma interativa e colaborativa através da participação das partes interessadas.s
3.2.1 API REST
REST (Representational State Transfer) é um dos estilos arquiteturais que define atributos
de qualidade da World Wide Web. Seu uso tem sido amplamente adotado por desenvolvedores
web por permitir de forma simples a criação de uma interface de serviços de fácil manutenção.
(PAUTASSO et al., 2013).
O sistema hipermídia é caracterizado por ser aberto, fracamente acoplado, distribuído e
descentralizado. Mas a principal característica de um sistema REST é a aplicação do conceito
de interface uniforme, que permite que recursos na Web sejam compartilhados através de identificadores ou endereços únicos padronizados (URIs, por exemplo) independentes da tecnologia sob a qual foram criados.
O funcionamento de uma API REST funciona sob a forma de representações e estados dos
recursos. Neste contexto, aplicações clientes podem enviar requisições (mensagens) para aplicações com interface REST com o objetivo de alterar o estado do recurso ou simplesmente
para recuperar dados daquela representação. Mensagens contém metadados que indicam o formato de processamento da requisição. No protocolo HTTP, por exemplo, um conjunto de mé-
37
todos possuem significados e objetivos que definem bem o que podem fazer com o estado de
um recurso, por exemplo: GET, POST, PUT, DELETE, HEAD, etc.
A Ferramenta Gestão Integrada possui uma API REST herdada do Redmine (REDMINE
REST API, 2015). Com ela é possível acessar alguns recursos do framework e obter dados
como lista de tarefas e membros de projetos cadastrados. O formato de saída do recurso pode
ser renderizado em javascript, ou em html.
3.3 Considerações
A Ferramenta Gestão Integrada é descrita no presente Capítulo como uma ferramenta vencedora de prêmio de destaque na categoria Inovação por uma revista do ramo. Capaz de gerir
processos e projetos das organizações, suas funcionalidades foram mapeadas e relacionadas às
áreas de conhecimento do PMBOK. Uma Tabela foi utilizada para informar se característica
implementada era nativa do Redmine ou se tratava de uma modificação feita através de um
novo plug-in da ferramenta. Verificou-se que a Ferramenta Gestão Integrada atende a várias
áreas do PMBOK, seja através de configurações, seja através de plug-ins ou funcionalidades
nativas do Redmine.
Além das funcionalidades mapeadas na Tabela, a Gestão Integrada possui uma API REST
capaz de disponibilizar informações cadastradas na ferramenta no formato JavaScript, um formato diferente do usual (HTML), fazendo com que uma ou mais funcionalidades possam ser
modificadas ou adicionadas através de plug-ins configuráveis.
38
4 COMPARAÇÃO DAS FERRAMENTAS DE GERÊNCIA DE PROJETOS
No mercado, existem várias ferramentas de Gerência de Projetos com várias funcionalidades. Entre as mais conhecidas está o MSProject, software pago desenvolvido pela Microsoft e
presente há algum tempo no mercado.
Outra opção muito difundida é a ferramenta dotProject, software livre desenvolvido na linguagem PHP e disponível para download gratuito. A sua última versão estável é a 2.1.8, lançada em julho de 2013.
Disponível no portal do Software Público, GPWeb é um software desenvolvido com base
no software dotProject pela empresa gpWeb. Já o TraceGP é um software nacional, desenvolvido por uma empresa de mesmo nome, somente disponível para compra, sem versão de testes.
Todas as ferramentas citadas anteriormente foram selecionadas - juntamente com a Ferramenta Gestão Integrada, descrita no Capítulo 3 deste trabalho - para uma breve comparação
de funcionalidades. Tendo em vista a vasta quantidade de ferramentas no mercado, o objetivo
desta comparação é realizar um levantamento para reunir informações do que há disponível
atualmente no mercado, mais precisamente no gerenciamento de projetos.
Conforme pode ser visto a seguir, na Tabela 2, as funcionalidades selecionadas são as mais
comuns encontradas em ferramentas de propósito específico de gerenciamento de projetos. Na
primeira linha estão as ferramentas descritas neste Capítulo e ao longo da Tabela é possível verificar com a marcação de um 'X' se a ferramenta possui a funcionalidade descrita.
Tabela 2: Comparativo entre as ferramentas de Gerência de Projetos
MsProject
DotProject
GPWeb
Cadastro de projetos e
subprojetos, perfis e permissões.
X
X
X
Cadastro de recursos humanos,
relacionando a um perfil e a um
projeto
X
X
X
TraceGP
Gestão
Integrada
X
X
X
Termo de Abertura do Projeto
(TAP).
X
X
Estrutura Analítica do Projeto
(EAP)
X
X
Cálculo das estimativas de prazos
e custos
X
Orçamento
X
Sequenciamento e relacionamento
entre as tarefas
X
X
X
X
X
X
X
X
X
X
X
39
MsProject
TraceGP
Gestão
Integrada
X
X
X
X
X
X
X
X
X
X
X
Plano de comunicação
X
X
X
Fóruns
X
X
X
X
X
X
X
X
X
X
Cálculo do caminho crítico
X
Cronograma e visualização de um
diagrama de Gantt
X
Planejamento e controle dos riscos
do projeto
X
Documentação do projeto através
do uso de repositórios,
documentos e arquivos
X
X
Gerenciamento dos requisitos.
Relatórios Gerenciais
DotProject
X
X
Project Model Canvas
GPWeb
Project Model Canvas Quadro
Inteligente
Exportação do Canvas em um
projeto
X
X
X
Disponibilização de API para
utilização do Canvas por outras
ferramentas
X
Criação colaborativa do Canvas
com PMBOK
X
Desenvolvida por um projeto do NES, a funcionalidade PMCanvas Quadro Inteligente
permite a criação de Canvas através de um quadro interativo de maneira colaborativa (SILVA
et al., 2014), utilizando a API desenvolvida neste trabalho.
Além das ferramentas listadas na tabela acima, existe também um aplicativo para celulares
com sistema operacional Android ou iOS desenvolvido por Finocchio em conjunto com a empresa Project Builder. O referido aplicativo possibilita que os seus usuários criem o canvas de
um projeto de maneira colaborativa, inclusive com a visualização do mesmo em um navegador
para computadores em tempo real. Cabe ressaltar que este aplicativo não importa nem exporta
os dados gerados de nenhuma forma, por isso não está listado na tabela acima.
Como resultado das análises e comparações das ferramentas, concluiu-se que elas não
possuem algumas das características da Gestão Integrada, como integração de documentos,
templates com base no PMBOK, exportação e reaproveitamento de dados e geração de relatórios mais complexos, além de não fornecer funcionalidades de plano de projeto e integração
usando a metodologia do canvas.
40
5 PLUG-IN PARA INTEGRAÇÃO PMBOK E PMCANVAS
A Ferramenta Gestão Integrada teve o seu acervo de plug-ins incrementado com a adição
do protótipo para criação de canvas (plug-in Canvas-gi). Descrito e implementado por Sales
(2013), o protótipo possuía um conjunto de funcionalidades que permitia a criação de canvas
para elaboração de planejamento de projetos e utilizava os conceitos de boxes e post-its de forma colaborativa, participativa, simplificada e significativa para os interessados (Tabela 3). Em
conjunção a isso, seu diagrama de classes também indicava esse minimalismo (Figura 3).
Tabela 3: Lista de Requisitos - Prótotipo Canvas-gi. Fonte: SALES (2013)
Lista de Requisitos - Protótipo Canvas-gi
I.
O sistema deve fornecer 13 “caixas” visuais: Justificativa, Objetivos SMART, Benefícios, Produto, Requisitos, Stakeholders
Externos, Equipe (stakeholders internos), Restrições, Premissas, Grupo de Entregas, Riscos, Linha do tempo e Custos;
II.
O sistema deve permitir a criação de post-its para cada caixa;
III.
O sistema deve permitir a edição de post-its;
IV.
O sistema deve permitir a deleção de post-its;
V.
O sistema deve enumerar os post-its de cada caixa para melhor organização;
VI.
O sistema deve permitir a reorganização de post-its dentro da mesma caixa e/ou em outras caixas;
VII. O sistema deve reorganizar os post-its após deleção;
VIII. O sistema deve prover um mecanismo para salvar o projeto canvas e reabrir futuramente.
Figura 3: Diagrama de classes do protótipo canvas-gi. Fonte: SALES (2013).
Além disso, o plug-in contava com uma interface de estilo visual demasiadamente simples
para gerenciamento, conforme pode ser visto na Figura 4.
41
Figura 4: Interface da versão anterior do plug-in Canvas-gi. Fonte: SALES (2013)
5.1 Evolução do Plug-in Canvas-gi
Como ponto de partida para o desenvolvimento de novas funcionalidades, verificou-se que
as únicas funcionalidades pós-cadastro que a ferramenta disponibilizava eram a de edição e visualização do canvas, e dados como o pitch e o nome do gerente não estavam disponíveis na
tela de visualização (Figura 4). Além disso, o visual da ferramenta deixava a desejar em casos
em que a mesma fosse utilizada em uma projeção ou tela muito grande.
Baseando-se na necessidade dos usuários de se trabalhar com os dados registrados para
dar prosseguimento às demais fases de um projeto recém-cadastrado com o método canvas, a
ferramenta carecia de funcionalidades que permitissem a transformação dos dados em artefatos
para uso direcionado no sistema, gerando um retrabalho ao redigitar as mesmas informações
em formulários (templates) preexistentes. Deseja-se, portanto, a disponibilização dessas funções.
O estudo do aproveitamento dos dados resultou em um mapeamento dos formulários presentes na Ferramenta Gestão Integrada e relações com as caixas (boxes) do canvas. Assim sendo, este formato definia que para cada conjunto de post-its de uma ou mais caixas (Justificativas, Benefícios, etc.), há um ou mais formulários disponíveis na ferramenta que podem servir
como destino de uma possível exportação e consequente aproveitamento de dados dos artefatos. Esses formulários atendem aos templates do PMBOK e estão listados na Tabela 4.
42
Tabela 4: Áreas do canvas x Templates Disponíveis na Gestão Integrada. Fonte: SILVA (2014)
Áreas do Canvas
Templates disponíveis
Justificativas, Objetivos Smart, Benefícios
Termo de Abertura do Projeto
Produto, Requisitos
Criação do Projeto, Termo de Abertura de Projeto, Cadastro de
Requisitos
Stakeholders externos, equipes
Termo de Abertura do Projeto, Cadastro de usuários com papeis e
responsabilidades
Grupo de Entregas
Estrutura Analítica do Projeto
Restrições, Premissas
Termo de Abertura do Projeto
Riscos
Plano de Riscos
Linha do Tempo
Estrutura Analítica do Projeto, Cronograma e Diagrama de Gantt
Custos
Cadastro do Orçamento
Com o objetivo de aproveitar os dados inseridos no canvas em outras áreas da Gestão Integrada, uma lista de melhorias e novas funcionalidades foi criada para o plug-in (Tabela 5).
Tabela 5: Lista de Novas Funcionalidades e melhorias do plug-in Canvas-gi
Canvas-gi - Melhorias e Novas Funcionalidades
I.
Refatorar tela de apresentação do canvas;
II.
Limitar a criação de canvas para apenas um por projeto da Gestão Integrada;
III.
Aproveitar o canvas existente em um projeto para outros projetos da Gestão Integrada;
IV.
Exportar artefatos do canvas para o Termo de Abertura;
V.
Exportar artefatos do canvas para o Plano de Comunicação;
VI.
Exportar artefatos do canvas para o Grupo de Usuários;
VII. Exportar artefatos do canvas para o Planejamento (EAP/Tarefas);
VIII. Exportar artefatos do canvas para o Plano de Risco;
IX.
Exportar artefatos do canvas para Requisitos;
X.
Exportar artefatos do canvas para o Orçamento.
XI.
Disponibilizar uma API para alimentar o canvas através de programas de terceiros (ANEXO I)
O diagrama de classes atualizado (Figura 5) fornece uma representação resultante das mudanças que foram feitas no código. Após o desenvolvimento das funcionalidades, o diagrama
representa o estado estático atual do plug-in. Dentre elas, destaque para o pacote de libs criado para dar suporte à comunicação do plug-in canvas com a Gestão Integrada, que permitiu
por exemplo a transformação dos artefatos do canvas e o aproveitamento de canvas entre pro-
43
jetos da ferramenta. Adicionalmente, a especialização dos post-its (CanvasTickets) permitiu a
inserção de alguns dados específicos nos post-its de algumas caixas e, posteriormente, uma exportação de artefatos mais rica e coerente.
Figura 5: Diagrama de classes atualizado do plug-in Canvas-gi.
5.2 Estado Atual da Ferramenta
A atualização do plug-in com as novas funcionalidades adicionou novas possibilidades ao
fluxo de uso da ferramenta. Inicialmente, ao acessar a tela inicial do plug-in Canvas-gi, é possível criar um novo Projeto Canvas. O sistema emite uma mensagem informando ao usuário o
limite de um canvas por projeto do sistema (Figura 6). Opcionalmente, é possível copiar o
canvas existente em outro projeto do sistema.
Figura 6: Mensagem informativa e links da tela inicial do plug-in Canvas-gi.
Ao acessar o projeto pelo link “Mostrar”, uma tela com as caixas e os post-its é carregada
(Figura 7). Essa tela teve sua interface alterada visando um melhor conforto na visualização e
no uso de suas funcionalidades. O Usuário pode clicar no ícone “+” de cada caixa para carregar o formulário de cadastro do post-it. Dependendo da caixa, os campos a serem preenchidos
irão mudar, bem como a validação para salvar os dados corretamente.
44
Figura 7: Nova interface do Canvas-gi.
Como pode ser observado na Figura 8, o preenchimento do post-it da caixa “Riscos” necessita de 3 informações básicas: um texto que defina sucintamente o risco a ser registrado, seguido de uma causa e um efeito previstos. Cadastrar um risco facilita a leitura de possíveis desvios no andamento do projeto e registrar suas causas e efeitos ajuda na previsibilidade e evita
os chamados “sustos” na equipe.
Figura 8: Formulário para preenchimento de um post-it da caixa Riscos.
Outros post-its foram especializados de acordo com as suas necessidades de guardar a informação. No entanto, houve uma preocupação para não burocratizar o processo de cadastro.
A qualquer momento o usuário pode concluir o cadastro e acessar a opção “Exportação
dos Artefatos”. Essa nova opção é a mais importante desta versão do plug-in, pois inicia a fase
de aproveitamento dos dados cadastrados, justificando todas as modificações implementadas
45
até agora. Ao acessar esta nova tela (Figura 9), o usuário pode selecionar um ou mais formulários que ele pretende gerar.
O plug-in proporciona a vantagem de pré-visualizar os dados a serem exportados antes da
confirmação definitiva, conforme pode ser visto na Figura 10.
Figura 9: Tela de seleção de artefatos para geração dos templates no Canvas-gi.
Figura 10: Tela de pré-visualização dos dados dos artefatos no Canvas-gi.
Ao clicar no botão “Gerar artefatos”, o plug-in canvas-gi irá alocar, para cada templatealvo selecionado, os dados oriundos do cadastro realizado anteriormente no canvas. Os dados
das caixas Justificativas, Objetivos Smart e Benefícios formam, por exemplo, o Termo de Abertura do Projeto (Figura 11). As demais caixas auxiliam no aproveitamento de dados de outros
formulários, conforme descritos na Tabela 4, Capítulo 5.1 deste documento.
46
Figura 11: Tela de Termo de Abertura preenchida com dados oriundos do Canvas-gi.
5.2.1 API REST
Uma outra funcionalidade presente no Canvas-gi aproveita a arquitetura REST presente
no Redmine (Capítulo 3.2.1) e provê acesso a operações do tipo CRUD (Criar, Recuperar,
Atualizar e Deletar) para os recursos do plug-in. Para compatibilizar o formato de saída com
os padrões de comunicação mais utilizados atualmente no desenvolvimento de aplicações, os
recursos disponíveis passaram a contar com o formato de renderização JSON (2015). O procedimento, já adotado na ferramenta anteriormente, funciona da seguinte maneira: com um usuário previamente cadastrado, o sistema utiliza uma chave de acesso a API e assim permite que
as requisições sejam realizadas com dados no formato solicitado. A interface REST do plug-in
Canvas-gi está descrita no Anexo I deste documento.
5.3 Exemplo Prático
Esta seção descreve um exemplo prático proposto em sala de aula pela Professora Simone
Vasconcelos Silva na disciplina de Gerência de Projetos do curso de Pós-Graduação Lato Sensu de Análise e Gestão de Sistemas da Informação no período letivo de 2014.
47
O trabalho consistia em conceber um projeto de desenvolvimento de um TCC utilizando a
metodologia Project Model Canvas. A turma foi dividida em grupos para trabalhar cada um em
seu projeto. Em um segundo momento, as informações cadastradas pelos grupos foram divulgadas e ficaram sob análise e discussão dos demais grupos. A Figura 12 mostra o Canvas preenchido após as discussões.
Após o preenchimento dos dados, o usuário do sistema clicou no link “Exportação de artefatos” e escolheu todos os tipos de exportação, já descritos na Figura 9.
Figura 12: Tela do Canvas-gi após o preenchimento do canvas "TCC IFF".
Após a confirmação da exportação pela ferramenta, os formulários que antes se encontravam vazios foram acessados para que os alunos pudessem conferir o resultado. Inicialmente, o
Termo de Abertura (Figura 13) foi gerado aproveitando diretamente os post-its do grupo de
caixas do Canvas chamada “Como”. Os outros dados foram extraídos da 1ª coluna – chamada
“Por que”.
Os Grupos de Usuários (Figura 14) são gerados através dos post-its da caixa Grupo de
Entregas e caracterizam um perfil na ferramenta Gestão Integrada. Desse modo, os perfis são
utilizados como base para configurar permissões de acesso dos usuários à funcionalidades diversas do sistema, além de facilitar o rastreamento de tarefas atribuídas aos membros da equipe.
48
Figura 13: Tela do formulário do Termo de Abertura do projeto na ferramenta Gestão
Integrada após a exportação dos dados do canvas-gi.
Figura 14: Tela que gerencia os perfis cadastrados na Gestão Integrada.
As caixas “Grupos de Entrega” e “Linha do Tempo” do Canvas possuem informações
como nome da fase ou pacote a ser entregue e a data de início e fim estimados. Estes dados foram suficientes para compor o formulário de planejamento do projeto. A Figura 15 lista os pacotes da EAP – Estrutura Analítica do Projeto e a partir desta tela é possível prosseguir com o
preenchimento, configurando responsáveis dos pacotes e criando tarefas.
49
Figura 15: Tela do formulário da EAP do projeto na ferramenta Gestão Integrada após a
exportação dos dados do canvas-gi.
Como resultado da organização das entregas do projeto em pacotes da EAP, a ferramenta
permite que seja gerado, através do link “Visualizar Gantt do Planejamento” (Figura 15) um
relatório de tarefas baseando-se nos pacotes do planejamento daquele ano. Ao acessar o link,
na tela seguinte (Figura 16), é possível adicionar filtros para refinar as pesquisas das tarefas. O
usuário poderá, finalmente, clicar no link “Gantt” para verificar o resultado.
Figura 16: Tela de visualização do Gantt por pacotes da EAP do projeto na ferramenta Gestão Integrada após a exportação de dados
do Canvas-gi.
50
É possível verificar o resultado da exportação dos dados da caixa “Requisitos” para o formulário, homônimo, na ferramenta. Os requisitos de projeto podem ser apreciados no Documento eletrônico de Requisitos (Figura 17). A partir de sua aceitação, pode-se gerar uma ou
mais tarefas para participantes, ou ainda, o requisito pode ser cancelado.
Figura 17: Tela do formulário de Requisições do projeto na ferramenta Gestão
Integrada após a exportação dos dados do canvas-gi.
Já as Figuras 18 e 19 mostram os formulários de Riscos e de Orçamento, aproveitando as
caixas “Riscos” e “Custos” do canvas, respectivamente. O formulário de Riscos pode ser utilizado como orientação futura nas possíveis mudanças bruscas do projeto e pode ser atualizado
ao final de cada fase com o feedback da equipe, visando aprendizado. Já o orçamento anual
pode ser levado em conta para estimar custos de execução do projeto na fase de concepção e
pode ser atualizado periodicamente.
Figura 18: Tela do formulário de Plano de Riscos na ferramenta Gestão Integrada após a exportação dos dados do canvas-gi.
51
Figura 19: Tela do formulário de Orçamento anual do projeto na ferramenta Gestão Integrada após a exportação dos dados do
canvas-gi.
5.4 Considerações
Neste Capítulo foram apresentadas as novas funcionalidades do plug-in Canvas-gi, principalmente a operação de exportar os artefatos para os formulários baseados no PMBOK disponíveis na Ferramenta Gestão Integrada. Como resultados, observou-se que a geração automatizada de artefatos poupa o trabalho da equipe em redigitar os dados, pois isola o processo de
concepção do projeto das ações posteriores ao do cadastro dos dados. Esse formato permite
manter o foco da reunião em levantar dados acerca do projeto e diminui a carga de complexidade que um cadastro comum normalmente geraria. Em adição a isso, o plug-in também coloca os dados em um outro 'momento' do sistema, apropriado para a fase de execução.
52
6 CONSIDERAÇÕES FINAIS
O presente trabalho apresentou a evolução do plug-in canvas-gi, funcionalidade do Project Model Canvas da Ferramenta Gestão Integrada. O plug-in, que seguia os preceitos descritos na metodologia Project Model Canvas, descrita por Finnochio, permitia a criação de canvas para elaboração de planejamento de projetos, utilizando-se dos conceitos de caixas e postits de forma simplificada entre os interessados.
Uma série de ferramentas foram estudadas para fins de comparação de funcionalidades.
Uma delas, criada por Finnochio, permite a concepção de projetos com a metodologia canvas
utilizando um aplicativo em smartphones que sincroniza os cadastros em tempo real em um navegador. Cabe ressaltar que na versão atual, a referida ferramenta não possui qualquer função
para trabalhar com os dados na ferramenta na fase posterior ao registro, tão pouco funcionalidades para acessar e/ou exportar os dados para outras plataformas.
Diante da necessidade de utilizar os dados na execução do projeto e levando em consideração que nenhuma das ferramentas do comparativo descrito no Capítulo 4 possuía funções de
processamento dos dados no pós-cadastro, o plug-in Canvas-gi passou por um processo de
amadurecimento e obteve melhorias em sua interface e adição de novas funcionalidades, como
por exemplo a exportação de artefatos para os templates existentes na ferramenta Gestão Integrada e a definição e abertura da API do plug-in. Com isso, a inserção e recuperação de dados
do canvas, tanto via interface da Gestão Integrada quanto via API REST acessada por programas de terceiros pode ser feita.
O plug-in adiciona à Ferramenta Gestão Integrada a possibilidade de trabalhar com os dados dentro da metodologia do canvas. A funcionalidade de exportação permite a pré-visualização dos dados para produzir os documentos necessários para facilitar a gerência de tais informações em um ambiente único e de fácil manutenção.
Há a necessidade de executar, posteriormente, estudos de avaliação de caso baseados em
planos de projeto reais, visando análise de usabilidade e fatores de qualidade, relatando grau de
satisfação e de eficiência da ferramenta. Ou seja, deseja-se pesquisar sobre a qualidade adicionada pelo plug-in à Ferramenta Gestão Integrada após a evolução do mesmo.
Futuramente, o plug-in pode sofrer evoluções e adaptações de acordo com as mudanças
dos templates baseados no PMBOK. Melhorias podem ser implementadas em sua interface,
seja com refinamento dos recursos de arrastar e soltar dos post-its, seja nos formulários de cadastros, pois atualmente estes são atualmente estáticos e dependem de uma tela a parte para
cadastro. Já os recursos da API deverão ser revistos a cada versão, pois os programas de ter-
53
ceiros precisarão sofrer também para manter a interoperabilidade entre as aplicações. Outras
alterações podem ser analisadas mediante feedback dos usuários do plug-in.
REFERÊNCIAS BIBLIOGRÁFICAS
DOTPROJECT.
DotProject:
Project
Management
<http://www.dotproject.net/>. Acesso em: 02 jan. 2015.
Software.
disponível
em
FERNANDES, F. A. (2015). Project Model Canvas Modo Quadro Interativo: Uma Melhoria da Interatividade na Ferramenta Gestão Integrada. Instituto Federal Fluminense. Campos
dos Goytacazes/RJ.
FINOCCHIO JÚNIOR, José. Project Model Canvas: Gerenciamento de projetos sem burocracia. 1 ed. Rio de Janeiroo: Elsevier, 2013.
GPWEB. Sistema GP WEB. disponível em <http://www.sistemagpweb.com/>. Acesso em: 02
jan. 2015.
JSON. Introdução ao JSON. Disponível em: <http://json.org/json-pt.html>. Acesso em: 23
fev 2015.
MARCONI, Marina de Andrade; LAKATOS, Eva Maria. Fundamentos de metodologia científica. In: Fundamentos de metodologia científica. Atlas, 2010.
MICROSOFT. Project Management Software. disponível em <http://products.office.com/ptBR/project/project-and-portfolio-management-software>. Acesso em: 02 jan. 2015.
MONTEIRO, N. A.; FALSARELLA, O. M. Gestão Da Informação Em Projetos Empresariais. Gesta, v. 2, n. 1, jan.-mar./2006, p. 78-104. ISSN 1809-0079. Disponível em:
<http://www.unisantos.br/mestrado/gestao/egesta/artigos/56.pdf>. Acesso em: 18 fev. 2015.
MONTEIRO, N. A.; FALSARELLA, O. M., (2007). Um Modelo de Gestão da Informação
para Aprendizagem Organzacional em Projetos Empresariais. Perspectivas em Ciência da
Informação, v. 12 n. 2, p.81-97, maio/ago. 2007. Disponível em:
<http://www.scielo.br/pdf/pci/v12n2/v12n2a06>. Acesso em: 18 fev. 2015.
PAUTASSO, Cesare; WILDE, Erik; ALARCON, Rosa. REST: Advanced Research Topics
and
Practical
Applications.
Springer,
2013.
Disponível
em:
<http://www.springer.com/br/book/9781461492986>. Acesso em: 22 fev. 2015.
PFLEEGER, Shari Lawrence. Engenharia de Software: teoria e prática. 2 ed. São Paulo: Pearson Prentice Hall, 2004.
PMI. Um Guia do Conhecimento em Gerenciamento de Projetos: Guia PMBOK – Quinta
Edição. 5 ed. São Paulo: Saraiva, 2014.
RABECHINI JR., R.; CARVALHO, M. M. Perfil das competências em equipes de projetos.
RAE-eletrônica.
São
Paulo,
v.2,
n.1,
jan-jun.
2003.
Disponível
em:
<http://www.scielo.br/pdf/raeel/v2n1/v2n1a12>. Acesso em: 17 fev. 2015.
REDMINE.
Redmine
REST
API.
Disponível
<http://www.redmine.org/projects/redmine/wiki/Rest_api/28>. Acesso em: 02 fev 2015.
em:
55
RODELLO, I. A.; DE PÁDUA, S. I. D., (2013). Um Estudo Empírico sobre os Benefícios
Percebidos pela Implantação de Sistemas Integrados de Gestão com Organizações do Interior de São Paulo. Race - Revista de Administração, Contabilidade e Economia da FUNDACE. Ribeirão Preto. SP. Dez. 2013. Disponível em: <http://fundace.org.br/artigos_racef/artigo_02_12_2013.pdf>. Acesso em: 19 fev. 2015.
SALES, M. S., (2013). Um Protótipo para Gestão de Projetos Utilizando o Método Canvas. Instituto Federal Fluminense. Campos dos Goytacazes/RJ.
SILVA, S., BARROSO, L., PAULINO, E., (2013). Melhorias Aplicadas à Ferramenta Gestão Integrada – Uma Abordagem no Processo de Gerência de Projetos . (WPGS 2013).
SBQS 2013. Salvador, 2013.
SILVA, S., LISBOA, J., VASCONCELOS, A., BARBOSA, C., REIS, M., LEITE, R., BARROSO, L., (2011) Gestão Integrada – Uma Ferramenta para Atender aos Processos de Gerência de Projetos e Portfólio do MPS.Br. IV Workshop de Gerenciamento de Projetos de
Software (WPGS 2011). SBQS 2011. Curitiba, 2011.
SILVA, S. V. ; BARROSO, L. ; SALLES, M. ; ARANTES, F. . Ferramenta Gestão Integrada. In: QUATIC, 2014, Braga - Portugal. Quatic 2014, 2014.
TRACEGP. Funcionalidades do Trace GP | Versão 9. disponível em
<http://tracegp.com.br/site/folders/FuncionalidadesTraceGPV9.0.pdf>. Acesso em: 02 jan.
2015.
TRENTIM, Mário Henrique. Gerenciamento de projetos: guia para certificações CAPM e
PMP. 2 ed. São Paulo: ATLAS, 2014.
56
ANEXO I - API RESTful para o Canvas-gi
Requisição do Cliente
GET
Descrição
-
Array de hashes com os
campos: name, id e parent_id
GET
Retorna o canvas de um
/projects/:project_id/canvas_pr projeto
ojects/show.json
-
Hash com campos do post-it
POST
/projects/:project_id/canvas_pr
ojects(.:format)
Cria um canvas
project_id;
Array canvas_project com
campos gp, name e pitch
Hash com os campos do
canvas ou array de erros de
validação.
PUT
/projects/:project_id/canvas_pr
ojects/:id(.:format)
Edita um canvas
project_id;
Array canvas_project com
campos gp, name e pitch
Hash com os campos do
canvas ou array de erros de
validação.
DELETE
/projects/:project_id/canvas_pr
ojects/:id(.:format)
Exclui um canvas
-
Uma confirmação da exclusão
ou array com erros de
validação.
GET
/projects/:project_id/canvas_pr
ojects/:canvas_project_id/canv
as_tickets/:id(.:format)
Retorna um post-it
-
Hash com campos do post-it.
GET
/projects/:project_id/canvas_pr
ojects/:canvas_project_id/canv
as_tickets(.:format)
Retorna todos os post-its de
um canvas_project
-
Lista de hashes com campos
dos post-its.
POST
/projects/:project_id/canvas_pr
ojects/:canvas_project_id/canv
as_tickets(.:format)
Cria um post-it
Hash canvas_ticket com os
Hash com campos do post-it
campos: data_inicio, data_fim, ou mensagem de erro de
canvas_box_id, efeito, causa, validação.
text, canvas_project_id, text e
canvas_ticket_id (para associar
com post-it de Grupo de
Entrega)
PUT
/projects/:project_id/canvas_pr
ojects/:canvas_project_id/canv
as_tickets/:id(.:format)
Editar um post-it
Hash canvas_ticket com os
Hash com campos do post-it
campos: data_inicio, data_fim, ou mensagem de erro de
canvas_box_id, efeito, causa, validação.
text, canvas_project_id, text e
canvas_ticket_id (para associar
com post-it de Grupo de
Entrega)
DELETE
/projects/:project_id/canvas_pr
ojects/:canvas_project_id/canv
as_tickets/:id(.:format)
Excluir um post-it
-
/projects(.:format)
Lista os projetos cadastrados
na Gestão Integrada
Parâmetros adicionais Resposta do Servidor
para envio
(JSON)
(erro 403 se o projeto não
estiver com canvas habilitado
ou null se não houver canvas
pra o projeto)
Uma confirmação da exclusão
ou array com erros de
validação.
Código das Boxes
•
"justificativas" => 1, "objectivesmart" => 2, "beneficios" => 3, "produto" => 4,
"requisitos" => 5, "stakeholders" => 6, "premissas" => 7, "equipe" => 8, "grupoentregas" => 9, "restricoes" => 10, "riscos" => 11, "linhadotempo" => 12,
"custos" => 13
57
Observações
●
Todas
as requisições devem incluir o
parâmetro
“key” na url. Exemplo:
“http://nome_do_servidor:porta/recurso/a/ser/consumido.json?
key=chave_do_usuario_da_gestao_integrada”, onde o valor da key deve ser adquirido na
seção “minha conta” do usuário, na Gestão Integrada.
●
O cabeçalho da requisição deve conter o conteúdo "Content-Type:application/json"