Lucas Miranda de Oliveira Moreira
Proposta de um processo para a escolha
da ferramenta de gerência de projetos.
Feira de Santana – BA Março / 2009
Lucas Miranda de Oliveira Moreira
Proposta de um processo para a escolha
da ferramenta de gerência de projetos.
Trabalho de Conclusão de Curso apresentado como requisito parcial para a obtenção do grau de Bacharel em Engenharia de Computação pela Universidade Estadual de Feira de Santana.
Orientador:
Prof. Hugo Saba Pereira Cardoso
Departamento de Ciências Exatas / Departamento de Tecnologia Universidade Estadual de Feira de Santana – UEFS
Feira de Santana – BA Março / 2009
Monografia de conclusão de curso sob o título “Proposta de um processo para a escolha da ferramenta de gerência de projetos”, defendida por Lucas Miranda de Oliveira Moreira em 19 de março de 2009, em Feira de Santana – BA.
___________________________________________________ Lucas Miranda de Oliveira Moreira
Engenharia de Computação
Universidade Estadual de Feira de Santana – UEFS Aluno
___________________________________________________ Prof. Dr. Hernane Borges de Barros Pereira
Departamento de Ciências Exatas – UEFS Examinador
___________________________________________________ Prof. MSc. Eduardo Manuel de Freitas Jorge
Universidade do Estado da Bahia – UNEB Examinador
___________________________________________________ Prof. MSc. Hugo Saba Pereira Cardoso
Departamento de Ciências Exatas – UEFS Orientador
Dedico esta dissertação à minha mãe, que de forma tão peculiar me ensinou a jamais desistir dos meus sonhos, e o valor das coisas simples. A minha querida poetisa e trovadora avó, Dorothy Miranda, pelo exemplo de vida e enriquecedoras conversas. A querida tia Marcinha e tio Herald, pelos valiosos conselhos e ensinamentos. Aos primos Caio, Otávio e Thiago, que tantas vezes me desviaram dos livros. Aos tios Túlio, Herald, Peixinho, Anselmo, Astor e todos que compõem essa família maravilhosa, pelos muitos fins de semana de “enriquecimento cultural paralelo”.
Àquela cujo afago sempre me acalma, pelo constante apoio e dedicação... A Manuella.
Agradecimentos
Ao Deus todo poderoso.
Ao professor Prof. Hugo Saba Pereira Cardoso, pela orientação e incentivo na realização deste trabalho, pelos conselhos que vão além desta orientação, e pelas caronas para salvador!
Ao professor Prof. Dr Hernane Borges de Barros Pereira, pelas críticas construtivas e singular contribuição à minha formação.
Ao Prof. João Batista Rocha Junior, pelo direcionamento e valiosos ensinamentos ao longo deste curso.
A Abraão Maia (chefia), gerente da ASSINF-UEFS, pela compreensão e conselhos geniais.
A toda equipe da ASSINF-UEFS, pela amizade e conhecimento compartilhado durante tanto tempo.
Resumo
Este trabalho propõe a definição de um processo capaz de auxiliar na escolha da ferramenta de gerência de projetos mais adequada a um dado projeto. Para tanto, é necessário elaborar formulários específicos que qualifiquem ferramentas de gerência de projetos e projetos segundo os aspectos aqui definidos para avaliação. O processo proposto é capaz de confrontar os dados das qualificações e definir percentuais de compatibilidade de acordo com cada um dos aspectos levantados no estudo teórico.
Abstract
This work proposes a process capable to help to choice the appropriate project management tool for a specific project. However will be necessary specifics forms to qualify tools and projects according the defined aspects. The proposed process is capable to confront the qualification data and define the percentage of compatibility according each evaluated aspect.
Sumário
Lista de tabelas ... 10
Lista de figuras ... 11
Lista de siglas ... 12
1. Introdução ... 13
1.1. Visão geral do documento ... 15
2. Gerência de projetos ... 16
2.2. Escopo do Projeto ... 19
2.3. Estrutura analítica do projeto ... 20
2.4. Gestão de tempo ... 23
2.5. Gestão de Tarefas ... 26
2.5.1. Análise de Caminho Crítico ... 26
2.6. Gestão de Recursos ... 28
2.7. Gestão de Custo ... 29
2.8. Gestão de Pessoas ... 31
2.9. Gestão de Documentação ... 33
3. Ferramentas de gerência de projetos ... 35
3.1. Funcionalidades em Ferramentas de Gerência de Projetos ... 36
3.2. Características de Ferramentas de Gerência de Projetos ... 38
3.3. Instrumentos para avaliação de Ferramentas de Gerência de Projetos e Projetos .. 40
3.3.1. Escalas de Likert ... 40
3.3.2. Ferramentas de Survey ... 42
4. Desenvolvimento do projeto ... 43
4.1. Avaliação de funcionalidades em ferramentas de gerência ... 44
4.2. Questionário para avaliação geral ... 46
4.2.1. Montagem do questionário geral ... 47
4.2.2. Aplicação do questionário geral ... 49
4.2.3. Análise dos resultados do questionário geral ... 49
4.2.4. Resultados sobre ferramentas ... 50
4.2.5. Resultados sobre funcionalidades das ferramentas ... 51
4.2.6. Resultados sobre características das ferramentas ... 52
5. Processo de escolha proposto ... 53
5.2. Modelo para avaliação de projetos ... 57
5.3. Exemplo da aplicação do processo ... 59
6. Considerações ... 61
Referências ... 62
Apêndice A. Questionário Geral ... 65
Apêndice B. Questionário Específico 1: Avaliação de ferramentas ... 76
Apêndice C. Questionário Específico 2: Avaliação de projetos ... 82
Lista de tabelas
Tabela 1. Ferramentas de gerência e suas funcionalidades ... 45 Tabela 3. Avaliação parcial de um projeto ... 59 Tabela 4. Compatibilidade do OpenProj para a funcionalidade Recurso ... 60
Lista de figuras
Figura 1. Estrutura geral do projeto ... 15
Figura 2. Elaboração de uma EAP... 21
Figura 3. Cronograma baseado em Gantt. Fonte: http://openproj.org/ ... 25
Figura 4. Diagrama de uma rede PERT ... 27
Figura 5. Questão baseada na Escalas de Likert. Fonte: articulate.com. ... 41
Figura 6. Escala de experiência do respondente ... 47
Figura 7. Excerto da Parte I do questionário geral... 48
Figura 8. Parte III do questionário geral, características de ferramentas ... 49
Figura 9. Resultados da parte I do questionário geral. ... 50
Figura 10. Importância das funcionalidades de Ferramentas de Gerência ... 51
Figura 11. Esquematização da qualificação das ferramentas ... 53
Figura 12. Esquematização da qualificação dos projetos ... 54
Figura 13. Detalhe do questionário específico 1 ... 55
Figura 14. Detalhe do questionário específico 2 ... 57
Lista de siglas
GP ... Gerência de Projetos EAP ... Estrutura Analítica do Projeto UT ... Unidade de Trabalho FGP ... Ferramenta de Gerência de projetos
1. Introdução
Existem diversas ferramentas computacionais que auxiliam gerentes e equipes no decorrer de projetos. Ferramentas de controle de recursos, controle de equipe, criação e emissão de relatórios, testes, entre outras. Essas ferramentas, conhecidas como Ferramentas de Gerência de Projetos (FGP), buscam automatizar as atividades inerentes à Gerência de Projetos (GP) e os processos envolvidos em cada fase de um projeto. Porém, a complexidade da GP faz com que tais ferramentas priorizem alguns aspectos em detrimento de outros, elas não implementam todos os conceitos teóricos que envolvem GP (Heldman, 2006). Dessa forma, o uso de uma FGP específica pode afetar a percepção do gerente em relação ao projeto e afetar seu desempenho como gerente, portanto o grau de sucesso do projeto.
Assim como uma FGP dá suporte a aspectos específicos da atividade de GP, cada projeto possui detalhes específicos. E tais particularidades delineiam certa compatibilidade entre FGPs e projetos.
É possível identificar, em uma FGP, funcionalidades que representem teorias e conceitos encontrados na bibliografia. Algumas práticas como a construção da Estrutura Analítica do Projeto e a Análise de Caminhos Críticos podem ser desenvolvidas de forma automática, a partir dessas funcionalidades.
No entanto, nem todos os conceitos e teorias são implementados em uma FGP. Práticas mais específicas como a previsão da data de conclusão do projeto a partir do atraso médio das tarefas também fazem parte do leque de funcionalidades inerentes a uma FGP. São essas particularidades que tornam uma FGP mais adequada que outras a um determinado projeto. Quando um projeto necessita de funções tão específicas o uso de uma ferramenta adequada facilita o trabalho da equipe, permitindo, por exemplo, tomar decisões a partir de uma análise mais criteriosa do projeto.
Por outro lado, não foram encontrados, na bibliografia estudada, materiais direcionados especificamente à orientação quanto à adequação de uma FGP. Muitos gerentes afirmam que essa dúvida surge a cada novo projeto e que é comum utilizar a mesma ferramenta utilizada em projetos anteriores. Essa escolha acontece, pois é
levado em conta principalmente o conhecimento na ferramenta por parte do gerente.
Sendo assim, observou-se que é possível caracterizar projetos e ferramentas a fim de identificar aspectos que explicitem uma possível compatibilidade entre ambos. Detalhes sobre a equipe, métodos e processos utilizados em um projeto justificam ou exigem a utilização de determinadas práticas. Essas práticas, automatizadas em uma FGP como funcionalidades, apontam o grau de adequação da ferramenta a um projeto específico.
Esse trabalho sugere como objetivo principal, que a partir de informações sobre características de FGPs e de projetos, seja possível realizar uma análise detalhada e definir um processo para definir a FGP mais adequada a um dado projeto. Essa adequabilidade depende, dentre outros fatores, do das funcionalidades e características apresentadas por cada ferramenta, além da descrição minuciosa do projeto que se quer avaliar. Para caracterizar as ferramentas e projeto foram elaborados questionários específicos através dos quais é possível descrever as ferramentas e os projetos de forma detalhada e objetiva.
O modelo de avaliação aqui proposto leva em consideração apenas as funcionalidades e características das ferramentas. A complexidade da construção de formulários específicos capazes de avaliar os outros aspectos citados justifica a restrição da análise apenas a esses dois aspectos.
1.1.
Visão geral do documento
A Figura 1 apresenta a estrutura geral de organização desse documento. No Capítulo 2 serão apresentados conceitos sobre GP importantes para o desenvolvimento desse trabalho.
No Capítulo 3 serão apresentadas as funcionalidades e características de uma FGP que são consideradas nesse trabalho, além dos métodos que serão utilizados para avaliação de FGPs e projetos.
A problemática abordada, os objetivos definidos para o trabalho e a metodologia utilizada serão apresentados no Capítulo 4. O Capítulo 5 trata do objetivo principal do trabalho, o processo de escolha proposto. O Capítulo 6 trás as considerações do trabalho.
2. Gerência de projetos
Os conceitos e teorias de GP, estudados na bibliografia utilizada, são organizados sob óticas diferentes. Essa inconstância depende, sobretudo, da ênfase abordada no material. Os tópicos discutidos a seguir foram estruturados levando-se em conta os objetivos desse trabalho. Portanto, foi dado ênfase aos conceitos, práticas e teorias passíveis de implementação, aqueles que, convertidos diretamente em funcionalidades, podem ser encontrados em softwares destinados a atividade de Gerência de Projetos.
Segundo o (PMBOK, 2003), um projeto é um esforço empreendido, durante certo tempo, para criar um produto, um serviço ou alcançar um resultado exclusivo. Um projeto não possui, obrigatoriamente, as datas de início e fim definidas podendo, inclusive, durar anos ou ser encerrado antes mesmo de alcançar seu objetivo.
Projetos não são esforços contínuos e são exclusivos. Os resultados que um projeto produz são sempre singulares, até mesmo projetos que compartilham algum propósito produzem resultados diferentes. A presença de elementos semelhantes não muda a singularidade fundamental do trabalho do projeto (PMBOK, 2003).
A GP é uma atividade desenvolvida desde os primórdios da humanidade. Grandes projetos desenvolvidos durante toda história foram concebidos a partir do planejamento, execução e monitoramento de um grupo bem elaborado de tarefas. Um bom exemplo são projetos arquitetônicos tais como a construção das Pirâmides do Egito, a construção da Basílica de São Pedro, em Roma e históricos projetos militares como a expansão romana. Esses e outros grandes projetos foram observados por estudiosos na tentativa de formular teorias e definir conceitos sobre essa atividade.
A partir do século XX a GP passou a ser reconhecida como ciência e Taylor foi um dos grandes estudiosos que contribuíram para a ascensão dessa atividade. De forma similar, muitos dos seus contemporâneos seguiram a linha de pensamento que associa diretamente a gerência de projetos à gerência de pessoas. Para os seguidores dessa linha grandes tarefas exigem esforço conjunto de um
grupo de pessoas e a eficiência de tal esforço depende principalmente da figura de um coordenador (Taylor, 2004).
Os métodos de monitoramento e controle utilizados por coordenadores daquela época serviram de base para a criação de técnicas mais apuradas, desenvolvidas posteriormente por outros estudiosos. Os Gráficos de Gantt, técnica desenvolvida por Henry Laurence Gantt (Valeriano, 2005) e, mais recentemente, a técnica de avaliação PERT (do inglês, Program Evaluation and Review Technique) são exemplos da evolução dessa ciência.
Atualmente esses métodos foram automatizados e inúmeras ferramentas computacionais de auxílio a gerentes foram criadas. Tais ferramentas computacionais possuem funcionalidades que buscam representar os conceitos elaborados no passado e processam uma série de informações relativas a um projeto. Porém, antes de utilizar tais ferramentas um gerente de projetos deve compreender os conceitos que dão origem a essas ferramentas. Essas são, verdadeiramente, as chaves do sucesso de um projeto (Kerzner, 2006).
O gerenciamento de projetos é dividido em cinco fases iniciação, planejamento, execução, controle e finalização (PMBOK, 2003). Essas são as fases pelas quais todo projeto deve passar. E para que esse ciclo de vida exista os gerentes devem dominar os conceitos e teorias que conduzem a gerência de projetos.
Na fase de iniciação o gerente define a data de início do projeto baseando-se na análise das condições da equipe, recursos e outros fatores que se fizerem necessário. É importante que a data de início seja cumprida, pois seguir a rigor as programações feitas para o projeto demonstra seriedade e traz confiança à equipe.
A fase planejamento é criada a partir do conceito de que um projeto é um grupo de atividades que se relacionam. É preciso organizar esse grupo de acordo com as interdependências existentes e então definir a duração e a ordem de execução dessas atividades. Esse planejamento interfere diretamente no grau de sucesso do projeto.
Durante a fase de execução é posto em prática o cronograma definido na fase de planejamento. Tarefas são distribuídas e devem ser cumpridas no prazo esperado para que o projeto siga como planejado. A partir do momento em que as tarefas passam a ser executadas o projeto entra na fase de controle. Ciclos de verificação mais curtos são definidos para que sejam feitas checagens, e devidas correções nas atividades. É preciso verificar se as metas estão sendo alcançados e se os resultados condizem com o que foi definido.
Com o ciclo de execução das tarefas terminado o projeto entra na fase de finalização. Nessa etapa são feitos os ajustes finais, apresentação do produto e o encerramento formal do projeto.
A GP abrange inúmeras gestões, áreas de estudo específicas a um aspecto dessa atividade, além de possuir elementos que devem ser estudados cuidadosamente. Nos próximos capítulos são apresentados essas gestões e os elementos que as compõem um projeto.
2.2.
Escopo do Projeto
Antes de montar um projeto propriamente dito é preciso pensar no produto que se espera obter com sua conclusão, definir o escopo do projeto, elaborar cuidadosamente os objetivos que devem ser alcançados ao fim do projeto.
Segundo (Taylor, 2004) alguns objetivos podem ser mais facilmente alcançados se analisados como um conjunto de tarefas distintas que possam ser executadas separadamente, ou até mesmo em paralelo, e por pessoas diferentes. Esse é o conceito de projeto segundo Taylor.
O escopo do projeto é a documentação que descreve seus objetivos, ou seja, o resultado que deve ser alcançado e descreve ainda como chegar a esse resultado, as ações envolvidas nesse processo (Valeriano, 2005). O escopo do projeto pode ser divido em duas grandes partes: a parte que aborda o produto a ser entregue, portanto a delimitação das funções e características do produto ou serviço a ser gerado pelo projeto. E a parte que define os processos e os meios para obtê-lo, que delimita e quantifica o trabalho necessário à obtenção do produto assim como definido.
A definição do escopo é de fundamental importância para o sucesso do projeto, uma vez este que deve traduzir as necessidades e os requisitos que motivaram a criação do projeto, bem como o conhecimento, as habilidades, e os recursos necessários para desenvolver o projeto.
2.3.
Estrutura analítica do projeto
Todo projeto tem por objetivo produzir um resultado, seja ele um produto tangível ou um serviço. No entanto para alcançar esse objetivo é preciso, muitas vezes, decompor o projeto em etapas. As etapas de um projeto possuem ligações e relações de dependência e, por esse motivo, não podem ser executadas aleatoriamente, devem seguir uma estrutura lógica.
Ao elaborar um projeto é preciso definir detalhadamente seus requisitos para que seja possível apresentá-lo de forma compreensível aos integrantes da equipe que irá desenvolvê-lo. Afinal, a compreensão integral do projeto por cada um dos membros da equipe desenvolvedora é fundamental para que o projeto seja bem sucedido (Valeriano, 2005).
Sendo assim, é preciso representar o projeto e suas etapas em um modelo que organize, defina e mostre graficamente tanto o produto a ser gerado como o trabalho a ser realizado para obtê-lo. Esse modelo é conhecido como Estrutura de Decomposição do Trabalho (EDT), Estrutura Analítica de Projetos (EAP) ou WBS (do inglês, Work Breakdown Structure).
A EAP de um projeto possibilita a representação das atividades necessárias à conclusão do projeto em um nível de abstração mais baixo do que as definições e descrições elaboradas durante a definição do escopo do projeto.A EAP consiste em um cronograma e um roteiro para cada fase do projeto.
Para um gerente a EAP é uma ferramenta bastante útil, pois dá a possibilidade de dividir o projeto em partes menores a fim de analisá-las minuciosamente. O detalhamento do projeto deve existir pra que seja possível analisar sua complexidade e sua viabilidade, porém levar o projeto a um nível muito alto de detalhes pode ser considerado perda de tempo.
Na Figura 2 é possível observar como deve ser elaborada uma EAP seguindo o seu nível gradual de detalhamento. A construção da EAP deverá alcançar pelo menos o terceiro nível, Unidades de Trabalho, não necessitando alcançar o nível Tarefas quando o mesmo for instável, pois a documentação das mudanças nesses nívis pode ser custosa a equipe.
Vejamos como exemplo um sistema simples de busca. Uma loja de sapatos quer montar uma unidade virtual de vendas através da qual o cliente pode listar os sapatos a partir de suas características. Sendo assim um sistema deve ser desenvolvido para suprir tal necessidade. As fases do projeto provavelmente seriam criação do banco de dados, criação da aplicação de controle, criação da interface Web e resolução de problemas de implementação.
Figura 2. Elaboração de uma EAP
Neste exemplo a fase desenvolvimento do banco é constituída por algumas unidades de trabalho como: levantamento dos requisitos, informações que devem ser persistidas, modelagem da relação entre as tabelas. Detalhando essa última unidade de trabalho (UT) encontramos tarefas como criar tabelas de cores, modelos, tamanho, criar scripts de busca, etc. Neste caso essas tarefas não precisam ser descritas em uma EAP, pois sofrem alterações constantemente e podem até deixar de existir devido a uma mudança no projeto.
O grau de detalhe ideal que o gerente deve alcançar varia em cada projeto. E até em um mesmo projeto cada fase possui sua complexidade e por esse motivo deve ser analisada separadamente e detalhada devidamente. Além da análise das atividades, o gerente precisa conhecer o potencial de sua equipe, a ponto de saber qual o nível de complexidade das tarefas a serem delegadas a cada membro. Deve saber ainda em qual grau de detalhamento é possível delegar responsabilidades sobre as decisões.
Outro parâmetro pelo qual o gerente pode se basear é o tempo estimado para a execução da UT. Uma UT com tempo de duração de 8 dias, por exemplo, pode causar grandes transtornos se um eventual atraso não for observado e contornado em tempo hábil. É mais seguro fracioná-la em 4 tarefas de 2 dias, dessa forma surgem 4 novos pontos de checagem obrigatórios e a mesma tarefa passa a ter um melhor monitoramento (PMBOK, 2003).
Além de informar o objetivo geral das tarefas e ordená-las cronologicamente uma EAP pode agregar informações detalhadas sobre as tarefas. Essas informações são úteis tanto para o gerente, no acompanhamento do andamento do projeto, quanto para os outros membros da equipe, para que cada um tenha melhor noção do seu papel no projeto. Algumas dessas informações são: a relação de dependência com outras tarefas e os recursos necessários ao cumprimento da tarefa (Valeriano, 2005). Escopo do Projeto 1º Nível Fases do Projeto 2º Nível Unidades de Trabalho 3º Nível 4º Nível Tarefa
Com o projeto disposto em uma EAP é possível perceber o grau de paralelismo entre as fases, unidades de trabalho e tarefas (Phillips, 2002). Esse paralelismo é importante para o projeto, pois tarefas executadas ao mesmo tempo encurtam o tempo total do projeto, criando folgas e reduzindo o surgimento de caminhos críticos. Caminhos críticos serão discutiremos de forma mais abrangente na Seção 2.5.1.
Existem dois métodos de evolução amplamente utilizados no processo de criação de uma EAP bottom-up e top-down. O método bottom-up é ideal para obter solução para um determinado problema. Ele exige soluções muito específicas sem se aprofundar nos detalhes de cada uma delas, porém ao fim da definição dos detalhes é possível definir a solução a ser utilizada. Na escolha de um carro, por exemplo, esse método definiria detalhes como cor, acessórios, condições de compra, e então, a partir do que foi determinado, tem-se o modelo a ser escolhido (Heldman, 2006).
O método top-down é mais comumente utilizado e requer mais lógica e estrutura. Uma EAP que utiliza esse método identifica, primeiramente, a solução geral do problema, a partir daí o problema passa por um processo de divisão bem elaborado. O produto de tal processo são etapas e tarefas bem descritas necessárias à implementação. Esse processo continua até que essas partes alcancem um tamanho ideal para execução (Heldman, 2006).
O processo de criação de uma EAP não deve ser uma atividade isolada, é importante envolver o gerente e a equipe de projeto. Em alguns casos os supervisores da gerência participam, porém, é comum que nesse ponto a equipe já possua autonomia sobre o projeto.
Uma boa maneira de iniciar a EAP é a partir das etapas definidas no orçamento, caso este não tenha sido feito a equipe deve identificar fases e posteriormente unidades de trabalho e tarefas. Esse processo de identificação de fases não é simples, mas torna-se intuitivo a partir da utilização de métodos de evolução como o método top-down (Heldman, 2006).
A partir da identificação das fases do projeto é possível iniciar a etapa de análise dessas fases. As análises feitas devem, inicialmente, levar em conta toda EAP e não é necessário gastar tempo com detalhes. A princípio apenas unidades de trabalho devem ser identificadas, dessa forma um número cada vez maior de passos menos complexos são definidos para alcançar o resultado esperado. Com o aumento no número de passos as análises passam a se restringir a fases e posteriormente a unidades de trabalho, porém levam em conta cada vez mais detalhes.
2.4.
Gestão de tempo
Um dos principais pilares da gerência de projetos e a gestão de tempo, pois todo projeto deve obedecer a um cronograma e possuir uma data determinada para ser finalizado (Valeriano, 2005). A gestão de tempo consiste na elaboração precisa de um cronograma e no controle criterioso do mesmo (Valeriano, 2005). O cronograma, por sua vez, consiste basicamente na ilustração de tarefas, marcos, eventos-chave e outros elementos relevantes ao projeto dispostos segundo suas datas de início e final. Tais elementos compreendem os produtos resultantes do planejamento do projeto, portanto da definição dos requisitos do produto, e da criação prévia da EAP (Kerzner, 2006).
A maior preocupação da gestão de tempo são as tarefas, afinal são elas que demandam tempo (Kerzner, 2006). Por essa razão é importante que as tarefas sejam idealmente complexas, permitindo uma estimativa consciente do tempo necessário para sua execução. A estimativa da duração da tarefa requer bastante atenção do gerente, pois é preciso fazer uma avaliação criteriosa das atividades envolvidas, além de levar em conta os processos decorridos anteriormente e a disponibilidade de recursos necessários (Valeriano, 2005).
A duração das atividades é comumente expressa em dias e possui uma indicação da margem de tolerância (Exemplo: 8dias ± 2). Porém não é raro encontrarmos a indicação da margem de tolerância expressa de forma percentual (Exemplo: 8dias ± 25%), segundo (Valeriano, 2005) a segunda forma é mais intuitiva para quem calcula a tolerância, porém menos intuitiva para quem a lê.
Após a definição da duração de cada tarefa é preciso elaborar o seqüenciamento delas, portanto dispor as atividades em uma seqüência cronológica que leve em conta as precedências e restrições existentes. Há atividades que podem ser executadas de forma independente, já outras exigem que sejam levadas em consideração as dependências temporais, restrições e ligações lógicas que proporcionem sintonia entre os produtos de uma tarefa com a tarefa sucessora (PMBOK, 2003). O resultado desse seqüenciamento será o diagrama de rede do projeto que é a forma gráfica de mostrar as ligações lógicas e as interdependências entre tarefas.
Restrições em uma tarefa existem quando, por algum motivo, esta possui data determinada pra iniciar ou terminar, portanto toda tarefa é passível de restrição (Valeriano, 2005). Comumente projetos são vinculados ao lançamento de um novo produto ou determinam mudanças na forma de trabalho de empresa, como por exemplo, a informatização de um setor. Essa ligação com fatos
importantes da vida de uma empresa pode ser fator determinante na definição de uma data de início ou término de uma tarefa ou etapa de um projeto.
Segundo (Valeriano, 2005) as dependências entre tarefas são identificadas quando uma tarefa possui uma relação de início ou fim com outra tarefa. Essa relação pode pertencer a um dos quatro tipos a seguir:
a) Término para início: Exige que outras tarefas sejam finalizadas primeiro.
b) Início para início: São tarefas intimamente relacionadas e devem iniciar ao mesmo tempo, porém não precisam necessariamente terminar ao mesmo tempo.
c) Término para término: Essas tarefas devem terminar ao mesmo tempo, pois seus produtos devem ser apresentados em conjunto ou são exigidos para o início de uma nova etapa ou tarefa.
d) Início para Término: Esse relacionamento é raro e exige que a tarefa antecessora não inicie até que a sucessora termine.
A partir da estimativa da duração de cada tarefa e da definição de suas dependências é possível calcular a duração total do projeto e então marcar sua data de início, alocá-lo no tempo. A definição da data de início do projeto deve levar em conta alguns fatores, pois após a definição desta data, cada tarefa também será alocada no tempo e a alocação das tarefas deve estar de acordo com a disponibilidade dos recursos necessários. Alguns desses fatores são: as condições de trabalho locais, ou seja, feriados, trabalho noturno, férias, legislações e regulamentos específicos dos funcionários da empresa e ciclos econômicos da empresa, como por exemplo, contratação de consultores e especialistas, contratação de outras empresas e ciclo de compras de materiais.
Nesse ponto da elaboração do projeto têm-se os três elementos base para a criação do cronograma. Esses elementos são o diagrama de rede com sua seqüência lógica de tarefas, a duração estimada dessas tarefas e o calendário com os marcos e eventos relevantes ao projeto (Valeriano, 2005).
A forma mais comum para ilustrar um cronograma é através do gráfico de barras de Gantt (Valeriano, 2005). Segundo Heldman (2006), o gráfico de Gantt foi elaborado pelo engenheiro e cientista social Henty Gantt em 1917 para exibe todas as tarefas de um projeto e as dependências entre elas, dispondo-as segundo as particularidades de um determinado calendário.
Ferramentas computacionais comumente implementam os conceitos elaborados por Gantt. Essas ferramentas incorporaram algumas funcionalidades ao
gráfico de barras facilitando o acesso a algumas informações do projeto. Em muitas dessas ferramentas é possível visualizar a completude da tarefa a partir de marcas de percentagem nas barras.
É comum, também, encontrar nas ferramentas que possibilitam a criação do diagrama de Gantt uma linha de tempo vertical que mostra o estado esperado do projeto. Analisando essa linha de tempo é possível calcular o atraso de cada tarefa, o atraso médio do projeto e estimar a data de conclusão do projeto considerando esses dados.
Outro ponto a ser observado nessas ferramentas é a conservação da dependência entre as tarefas e suas durações, o calendário com seus eventos e o cronograma do projeto. Qualquer modificação em um desses elementos implica na atualização dos outros. Como atualizações de cronograma são bastante freqüentes em projetos, essa característica é imprescindível para garantir economia de tempo e consistência de informações (Ainscough et al., 2003).
Dependências, marcos e eventos-chave são outros aspectos que podem ser visualizados juntamente com o gráfico de barras de Gantt na função cronograma das ferramentas de gerência projetos (FGP). A Figura 3 possibilita a visualização, através da ferramenta OpenProj, de um cronograma contendo alguns dos elementos citados.
2.5.
Gestão de Tarefas
Em gerência de projetos uma tarefa é um trabalho específico que para ser realizado requer a aplicação de recursos e produz um resultado. Além de possuir um tempo determinado para ser executada, uma tarefa pode manter uma relação de dependência com outras (Borrego et al., 2003).
Uma tarefa é sempre delegada a um responsável apto a executá-la. Tal responsável deve iniciar a execução da tarefa na data determinada e seguir os passos necessários para finalizá-la em tempo hábil. A execução desses passos define o percentual de completude da tarefa e a finalização da execução de todos esses passos coincide com o fim da tarefa. Uma tarefa pode e deve ser analisada por um supervisor capacitado para que sua qualidade seja garantida.
A fase de desenvolvimento de um projeto é composta basicamente pela execução sucessiva de tarefas. Para que essa fase seja bem sucedida é preciso manter o controle do cronograma, portanto garantir o cumprimento de cada atividade, sua qualidade e prazo.
2.5.1. Análise de Caminho Crítico
O gerenciamento de um projeto se baseia no controle das tarefas que o compõem, assim como a realização de cada tarefa requer cuidados em relação às dependências dos resultados produzidos por outras tarefas (PMBOK, 2003). Porém, segundo Heldman (2006) o controle de tarefas pode ser feito a partir da utilização de algumas técnicas como o Método do Caminho Crítico – MCC ou CPM (do inglês, Critical Path Method) e a Técnica de Avaliação e Análise de Programas – TAAP ou PERT (do inglês, Program Evaluation and Review Technique). No entanto o uso dessas técnicas depende da criação prévia do cronograma do projeto.
O Método do Caminho Crítico (CPM) é uma técnica de análise da rede de tarefas, que calcula o tempo total do projeto a partir das datas de início e fim mais cedo e das datas de início e fim mais tarde. Ela se baseia em redes seqüenciais de tarefas elaboradas juntamente com o cronograma, como foi visto na Seção 2.4. Essa técnica busca identificar os caminhos críticos do projeto. O caminho crítico é o caminho, da rede de tarefas, composto pelas tarefas com o maior tempo de duração e deve abranger tanto a primeira como a última tarefa da rede.
As tarefas que compõem o caminho crítico requerem o maior grau de atenção, pois qualquer atraso irá afetar diretamente a duração total do projeto. No entanto a identificação desse caminho de ser feita levando em conta a duração das
tarefas com folga zero, portanto os tempos definidos pra cada tarefa sem qualquer acréscimo.
As folgas atribuídas em uma tarefa podem ser classificadas de duas formas. A folga total ou float é aquela na qual é possível atrasar o início da tarefa sem afetar o tempo total do projeto, possível apenas em tarefas que não fazem parte do caminho crítico. O outro tipo é a folga livre, ou slack, que corresponde ao tempo durante o qual é possível atrasar o início da tarefa sem que esse atraso afete o início da tarefa subseqüente (Heldman, 2006).
O método PERT foi desenvolvido na década de 50 pela marinha americana para o controle de um projeto histórico, o Programa de Mísseis Polaris. Esse método tem por objetivo fazer projeções de cronograma com alto grau de confiabilidade. PERT é bastante semelhante ao método CPM. A diferença é que enquanto este utiliza a duração mais provável para calcular o tempo total do projeto, PERT faz uso do valor esperado, ou média ponderada. O valor esperado é encontrado a partir da média ponderada entre três valores estimados de duração de uma tarefa. Heldman (2006) afirma que em 99,73% das vezes o trabalho termina dentro de mais ou menos três desvios-padrão.
A Figura 4 mostra um diagrama PERT simples. Os valores dentro dos círculos são identificadores dos marcos e, neste caso, estão incrementados de 10 para que outros nós possam ser incluídos sem provocar mudança nos identificadores já inseridos, um sistema simples de numeração. Cada aresta desse diagrama representa uma atividade, as letras são os identificadores das tarefas e o tempo indicado nas arestas é a duração estimada dessa tarefa. Nesse exemplo, o caminho crítico identificado é a seqüência de atividades representadas pelas arestas A, C e F do grafo da Figura 4, pois esse caminho possui o maior tempo de execução, sete semanas. Qualquer atraso em uma dessas tarefas provoca um acréscimo direto no tempo total do projeto.
2.6.
Gestão de Recursos
Esta gerência compreende os procedimentos que envolvem a estimativa, o planejamento e o controle de todos os recursos necessários à concretização dos requisitos de um projeto, portanto abrange os elementos necessários ao cumprimento de cada tarefa do projeto (Valeriano, 2005). Estes recursos podem ser pessoas, equipamentos, peças, matérias-prima, documentos, softwares, etc.
A existência de um conjunto organizado de recursos é essencial a uma boa gerência de recursos, pois permite controlar a alocação dos mesmos às tarefas, além de documentar a relação existente entre cada requisito do projeto, suas respectivas tarefas e recursos necessários à sua execução. Este pool de recursos, como é chamado, deve armazenar dados técnicos e descrições sobre cada recurso nele armazenado, de forma que os interessados em um desses recursos possam verificar sua utilidade segundo seus atributos (Vieira, 2008).
A estimativa dos recursos necessários ao desenvolvimento do projeto pode ser feita com base nas tarefas definidas na EAP, nos atributos dos responsáveis pela tarefa e nos requisitos técnicos de cada um desses recursos. É importante levar em conta a natureza desses recursos e sua disponibilidade, já que essas informações, juntamente com a opinião de especialistas e informações de projetos anteriores, permitem determinar quais recursos podem ser obtidos na própria organização, quais serão adquiridos e a forma de aquisição (e.g. contratação, aluguel, compras, etc.).
Durante o processo de definição dos recursos é comum que apareçam várias soluções, ou sugestões, para um determinado problema. Isso se deve à possibilidade de utilização de meios diversos para alcançar um mesmo objetivo. Esse fato é bastante evidente em projetos da área de tecnologia de informação, na qual as tecnologias utilizadas e o grau de conhecimento do profissional interferem amplamente no resultado da atividade.
Juntamente com o pool de recursos, uma boa gerência de recursos deve dispor de medidas corretivas e preventivas para que não haja divergência entre o processo de utilização dos recursos e o planejamento definido anteriormente. Possíveis incompatibilidades entre o recurso e a atividade, ou problemas encontrados durante a utilização deste recurso devem ser documentados para que permaneça como base de pesquisa para planejamentos futuros.
2.7.
Gestão de Custo
Determinar a viabilidade de um projeto não depende apenas da capacidade da equipe ou dos recursos disponíveis. É extremamente importante a análise detalhada do custo do projeto e como o recurso financeiro será aplicado ao projeto. É função do gerente do projeto ajustar seu cronograma e planejar a alocação dos recursos de acordo a verba disponível naquele momento (Vieira, 2008).
O controle de custo de um projeto é função do gerente. O gerente deve utilizar orçamento e cronograma do projeto como ferramentas para análise e acompanhamento do custo. Não existe uma regra para a criação do orçamento, no entanto o resultado desse trabalho deve ser uma análise consciente das despesas esperadas em cada etapa do projeto dispostas em um documento. Esse documento deve trazer informações detalhadas dos custos e ser de fácil análise para os interessados.
Uma forma bastante comum de criar um orçamento é basear-se na EAP do projeto e calcular o valor de todos os produtos apresentados nela. O cálculo do valor de cada produto deve ser minuciosamente executado e deve levar em conta alguns aspectos do projeto. Alguns dos valores calculados tais como o valor pago a cada membro da equipe, o custo do material utilizado durante o desenvolvimento, a depreciação dos equipamentos, entre outros, são tidos como gastos fixos do projeto, valores passíveis de cálculo sem grande variação.
Porém, custos oriundos de cálculos menos precisos como a adaptação da equipe a uma nova tecnologia, a oscilação do preço de alguns recursos que não podem ou não devem ser estocados, e a contratação de serviços especializados, são ditos gastos variáveis e não podem ser definidos precisamente. Esse é um dos pontos no qual a experiência do gerente faz a diferença.
Com o decorrer do projeto o valor calculado deve levar em conta outras variáveis. A qualidade profissional dos evolvidos e a produtividade media da equipe no decorrer do projeto podem interferir no custo total do projeto, em caso de adiamento do fim do projeto, por exemplo. Nesses casos é comum que as empresas contratem profissionais temporários ou terceirizem alguns serviços na tentativa de evitar que ocorra um acréscimo de tempo no projeto.
Projetos que incorrem nesse erro sofrem um grande acréscimo de custo. Além do custo de manter uma equipe inteira durante mais tempo é preciso levar em conta o gasto com outros fatores relativos ao atraso como o custo de equipamentos alugados. A impossibilidade de alocar equipamentos e recursos a projeto por estarem indisponíveis como equipamentos alugados, por exemplo, pode causar um grande prejuízo. Outro fator agravante é a perda de prestígio devido ao atraso, pois
produtos ou serviços podem ser vistos como meras imitações ou obsoletos por terem sido lançados tardiamente devido a um maior tempo de elaboração.
2.8.
Gestão de Pessoas
O grupo de pessoas envolvidas no projeto apesar de ser visto erroneamente com um recurso, o dito recurso humano, deve ser tratado de forma exclusiva. Tal grupo não se restringe apenas aos que trabalham no projeto, mas sim aos integrantes de todas as partes interessadas. Cada indivíduo deve ser avaliado e observado isoladamente, sob seu aspecto humano e capacidade profissional. Da mesma forma, a equipe deve ser considerada como um grupo dedicado ao trabalho cooperativo que, apesar de ser formado por indivíduos distintos, age e será avaliado como uma única unidade de trabalho. Essa visão deve levar em conta tanto o resultado final do projeto quanto os produtos provenientes da conclusão de cada tarefa ou etapa (Valeriano, 2005).
A definição dos integrantes do grupo de trabalho do projeto pode ser feito durante a construção da EAP ou ser elaborado durante a execução do projeto, antes do início de cada fase. A escolha dos profissionais que irão compor a equipe deve levar em conta a formação, as habilidades, as características pessoais, fatores normalmente definidos na descrição do trabalho. É comum também que essa descrição seja adicionada à EAP do projeto para mostrar a alocação de cada membro da equipe no projeto e suas responsabilidades.
Mesmo que o projeto seja bem formulado se a equipe não tem a mesma visão do produto final, as chances de sucesso do projeto ficam ameaçadas. É importante que o gerente tenha exata noção dos integrantes da equipe de suas atribuições e que cada membro da equipe conheça e cumpra com suas responsabilidades. Pois nesse ponto um projeto já possui um objetivo, definido antes mesmo do projeto e uma estrutura, a EAP, resta agora definir as regras de funcionamento que é o papel de cada um em cada atividade a ser desempenhada.
A comunicação entre os membros deve ser eficiente e monitorada pelo gerente. Pois a gerência de pessoas abrange além da formação equipes a motivação e a administração de conflitos. Dessa forma é possível manter todos os envolvidos a par de suas tarefas e principalmente mantê-los cientes da importância de suas atividades para a finalização bem sucedida do projeto. É função do gerente alertá-los da dependência entre as tarefas futuras e o resultado das suas atividades atuais.
Para que a equipe permaneça coesa e motivada é comum que exista um programa de premiação ou reconhecimento pelo bom cumprimento das obrigações. Boas condições de trabalho, como instalações adequadas e programas de treinamento, também são fundamentais para o crescimento profissional da equipe.
No entanto, toda equipe sofre com conflitos pessoais e até acontecimentos como este devem ser bem administrados para que, quando solucionados, sirvam como exemplo e incentivo ao grupo.
2.9.
Gestão de Documentação
Durante todo o clico de vida de um projeto existe a necessidade de documentar fatos ocorridos, decisões tomadas, detalhes sobre etapas e diversos outros eventos e informações importantes. Para que isso seja possível, e seja feito de forma eficiente, é preciso que as informações necessárias sejam extraídas e armazenadas sempre que um evento relevante ocorrer pra que, posteriormente, sejam agrupadas e formalizadas em documentos específicos (Kerzner, 2006).
O acompanhamento do projeto pode e deve ser mantido por todas as partes interessadas. No entanto é possível distinguir dois grupos de interessados. O grupo de trabalho do projeto, que é responsável pela execução das tarefas e, portanto analisa e contribui com a documentação mais dinâmica do projeto como relatórios de execução, descrição de tarefas e descrição de recursos. Os outros interessados são a alta administração, os clientes e possíveis colaboradores que acompanham o andamento do projeto a partir da leitura e análise de relatórios de progresso, relatórios de análises de riscos e custos, estudos de mercado e outros documentos mais abrangentes (kerzner, 2006).
É possível que a mesma informação seja posta em mais de um documento, isso porque a forma e o nível de detalhamento da informação apresentada dependem do perfil das pessoas que irão ter acesso ao documento. Tomando como exemplo as tarefas de uma determinada etapa do projeto observa-se que para o gerente é indispensável ter acesso aos problemas com um grau de detalhamento suficiente para a identificação das causas e possíveis soluções. Por outro lado, para clientes e colaboradores são suficientes o percentual de conclusão e o atraso médio da etapa.
Quando armazenadas de forma adequada, essas informações podem ser utilizadas para a elaboração automática desses documentos de acompanhamento. Relatórios, gráficos, redes e esquemas podem ser gerados dinamicamente a partir desses dados. É comum, também, a existência de um site específico do projeto. Este também pode ser atualizado de maneira independente, sem intervenção humana. O uso dessas ferramentas permite que documentos assim sejam criados a qualquer momento e sempre com informações atuais.
No entanto é importante que exista um profissional dedicado exclusivamente à atividade de documentação do projeto, pois mesmo diante das facilidades provenientes do uso da tecnologia, como frameworks específicos para essa atividade, é preciso monitorar a elaboração de cada documento, pois existem algumas normas específicas para padronizar a documentação de um projeto.
O CMM (do inglês, Capability Maturity Model) é um modelo de referência que contem práticas necessárias para que uma organização atinja a maturidade em áreas específicas do conhecimento (e.g. Engenharia de Software, GP, etc.). Algumas dessas práticas são relacionadas diretamente com o processo de documentação. Os documentos exigidos são elaborados para documentar a estrutura e os processos da organização, bem como os projetos desenvolvidos pela organização (SOWEK, 1999).
Todos os conceitos apresentados nesse capítulo são passíveis de implementação. Ao serem convertidos em funcionalidades, esses conceitos passam a compor ferramentas computacionais destinadas a auxiliar gerentes de projetos.
3. Ferramentas de gerência de projetos
Nesse capítulo serão estudados aspectos de softwares com propósitos específicos
Uma ferramenta de gerência de projetos é um software que se propõe a implementar os conceitos e teorias sobre gerência de projetos de forma a automatiza os processos relativos a essa atividade (Vieira, 2008). No entanto, essas ferramentas devem levar em conta as particularidades de cada conceito teórico ao implementar tais funções. Porém nem todos os conceitos estão presentes, em forma de recursos, em uma determinada ferramenta.
As ferramentas normalmente são tendenciosas, ou seja, priorizam algumas teorias, e acabam por dar ênfase às funcionalidades ligadas a essas teorias. Essa escolha pode ser influenciada pela temática da ferramenta, como ferramentas destinadas a processos ágeis, por uma análise incompleta dos requisitos da ferramenta ou por qualquer outro motivo.
Algumas ferramentas trazem recursos que buscam automatizar um determinado conceito teórico, porém não o fazem de forma correta. Esse deslize torna a ferramenta incompleta, além de possibilitar uma utilização equivocada desses recursos. Muitas dessas ferramentas são citadas em livros, sites e blogs especializados em GP. Algumas dessas ferramentas e recursos são apresentados na Seção 3.1.
3.1.
Funcionalidades em Ferramentas de Gerência de
Projetos
Uma ferramenta de gerenciamento deve, primeiramente, ter uma interface amigável e disponibilizar, de forma intuitiva, o acesso aos recursos que automatizam os conceitos teóricos que norteiam a atividade de gerência de projetos (Strauss, 1997).
Nas seções anteriores foram identificados os principais conceitos, abordados na bibliografia proposta, sobre a atividade de gerência de projetos e os processos relativos às atividades da área. Os conceitos, métodos e processos de gerência são bastante consultados por grupos de desenvolvedores e empresas para modelar as funcionalidades que irão compor ferramentas de auxílio à gerência de projetos.
A partir da bibliografia aqui proposta e da análise de alguns sites e blogs especializados, foram elencadas funcionalidades de FGP ditas de grande valor para um software dessa categoria. Algumas das fontes acessadas foram: Revista Mundo PM, Blog do PG, UniversoGP.com e PontoGP, entre outros. A lista completa de fontes pode ser encontrada no Apêndice A.
De acordo com essas fontes e levando em consideração a fundamentação apresentada na Seção 2, foram identificadas oito funcionalidades principais. Aqui usaremos rótulos para melhor identificar cada uma dessas funcionalidades.
Cronograma é o identificador definido para referenciar recursos em uma ferramenta que tratem da organização de elementos como a seqüência lógica de tarefas, as datas de início e fim de cada tarefa, o calendário com os marcos e eventos relevantes ao projeto, entre outros. Essa funcionalidade está bastante ligada aos conceitos do diagrama de Gantt vistos na Seção 2.4.
Porém, como algumas ferramentas implementam um cronograma sem levar em consideração os conceitos elaborados por Henry Gantt, decidiu-se pela utilização do identificador Gantt para especificar que o cronograma apresentado pela ferramenta utiliza o diagrama de Gantt. Alguns recursos dessa funcionalidade são a visualização da completude da tarefa, uma linha de tempo vertical para mostrar o estado esperado de completude do projeto e as dependências entre as tarefas.
Para referenciar recursos que permitam a criação de uma tarefa com toda informação necessária como datas de início e fim, responsável, recursos necessários, notas de esclarecimento, entre outros, foi definido o indicador Tarefas.
A possibilidade de atualizar o percentual de completude, acrescentar notas sobre acontecimentos e indicar sua conclusão também são referentes a esse indicador.
Para que seja possível executar o controle de recursos é preciso que a ferramenta possa cadastrar um recurso, sua natureza, quantidade e custo agregado, além da possibilidade de rastrear esse recurso e monitorar seu uso e alocação nas tarefas. Para essas e outras funcionalidades relativas aos recursos do projeto foi definido o indicador Recursos.
A definição de tarefas e alocação de recursos implica em uma rede de dependências que cria uma relação entre todas as tarefas. Esse acontecimento é esperado em um projeto, porém a elaboração inadequada dessa rede pode culminar em um caminho crítico. Esse caminho é a seqüência ininterrupta de tarefas que não podem sofrer atraso, caso contrário o tempo total do projeto será afetado. O identificador Pert será utilizado para definir funcionalidades que tratem da análise e controle de caminhos críticos na ferramenta.
A análise dos custos relativos ao projeto envolve uma série de cálculos como a definição do valor estimado de depreciação de um equipamento, o valor total a ser pago a um trabalhador pelas suas horas de trabalho, o valor total gasto com um recurso a partir do seu valor unitário, entre outros. Todo esse cálculo deve ser feito automaticamente pela ferramenta a partir de outras informações previamente cadastradas. Os recursos da ferramenta destinados a essa atividade serão aqui identificados como Custo.
O controle do pessoal envolvido no projeto torna-se mais complexo quanto maior for a equipe e como vimos anteriormente manter toda equipe informada sobre decisões e acontecimentos do projeto é de crucial importância para o sucesso do mesmo. As funcionalidades em uma ferramenta que permitem essa comunicação e difusão de informações entre os membros, controle de acesso a dados restritos, troca de mensagens, entre outras, são aqui definidas pelo identificador Equipe.
A última funcionalidade definida levou o título de Relatórios e é referente a recursos que possibilitem a criação automática de documentos com dados do projeto. Esses documentos são normalmente relatórios de custo, de atividades, de rendimento, etc., e tem por finalidade resumir, para fácil observação, dados armazenados desde o início do projeto até a data em que são gerados.
3.2.
Características de Ferramentas de Gerência de Projetos
Segundo a avaliação das fontes de pesquisa sobre funcionalidades e características das ferramentas de gerência foi possível identificar características possivelmente encontradas nessas ferramentas, porém desprovidas de resguardo teórico. Tais características são medidas que visam melhorar a usabilidade da ferramenta, tornando sua utilização mais agradável ao usuário. Algumas dessas características visam, também, a melhoria de funcionalidades como a notificação do usuário, via e-mail, sobre detalhes de tarefas. Os parágrafos a seguir tratam das características elencadas a partir do estudo das fontes.A Personalização do Ambiente de Trabalho foi uma das características encontradas. Ela se refere à possibilidade do usuário modificar elementos visuais da ferramenta, como cores, posição de menus, modos de exibição de informações, etc. A utilização dessa característica visa, principalmente, a praticidade no uso das funções mais freqüentemente acessadas.
Notificação Via e-mail permite maior comodidade aos usuários da ferramenta, uma vez que informações podem ser enviadas aos interessados, tornando imediata a publicação das novidades do projeto. Grandes modificações e detalhes sobre o projeto devem permanecer como conteúdo de relatórios e documentos específicos, porém eventos simples como a conclusão de uma tarefa, a aquisição de um novo recurso ou a disponibilização de um novo documento podem ser notificados dessa forma.
Ferramentas que permitem Comunicação Remota entre os integrantes da equipe são ideais para monitorar projetos que envolvem pessoas ou grupos geograficamente dispersos. A possibilidade de atualização remota de informações permite maior flexibilidade, porém exige maior independência e disciplina por parte dos participantes do projeto já que não existe a figura presencial do líder. É comum que ferramentas que possuem tal característica sejam Baseadas em Plataforma Web sendo acessíveis a partir de qualquer terminal conectado à internet.
Manter um Histórico de Lições Aprendidas não é apenas função natural dos envolvidos no projeto, algumas ferramentas dão suporte a esse tipo de documentação buscando tornar mais fácil a resolução de problemas semelhantes no futuro. A base de conhecimento tem a função de registrar, além do planejado, os imprevistos ocorridos durante o projeto e como eles foram resolvidos. É comum que essas e outras informações sejam disponibilizadas a partir de um Web Site Próprio.
Outro tipo de controle que pode ser encontrado em algumas ferramentas é o Controle de Versão de Documentos. Com ele, relatórios ou documentos que são
elaborados durante o projeto podem ser armazenados e centralizados na ferramenta, criando assim uma fonte única para fornecimento dessas informações, além de evitar equívocos decorrentes da utilização de material desatualizado.
Outra característica encontrada nas FGP avaliadas foi o Modelo de Persistência Desvinculado. Essa característica permite da à ferramenta maior possibilidade de integração com outros sistemas computacionais, já que existe a possibilidade de acessar os dados do projeto a partir de outros softwares. É possível, por exemplo, alimentar um portal com dados do projeto sem a necessidade de intervenção humana, ou fazer uso dessa base de dados em ferramentas para criação dinâmica de relatórios.
3.3.
Instrumentos para avaliação de Ferramentas de
Gerência de Projetos e Projetos
Um dos pontos centrais em pesquisas empíricas, como as que investigam o nível de usabilidade em softwares, é a elaboração de um instrumento de medição eficiente para a coleta de informações subjetivas (Gould e Lewis, 1985). Segundo Padilha (2004) o uso de questionários ou entrevistas é bastante útil para avaliar e mensurar características não exatas de um determinado objeto. Porém as entrevistas podem ser diferenciadas dos questionários, afinal são duas técnicas distintas de avaliação.
A principal característica de uma entrevista é ser um instrumento de avaliação e conhecimento interpessoal. O que facilita a apreensão de uma série de elementos de identificação e de construção do todo do entrevistado (Guzzo e Pasquali, 2001). Diferentemente das entrevistas, as questões presentes em um questionário são respondidas sem a presença de um entrevistador, de modo que alguns fatores devem ser levados em conta. Por exemplo, é preciso que o indivíduo que responde ao questionário saiba ler e escrever, assim como é preciso também dosar a quantidade e tamanho das questões para que o seu preenchimento não seja cansativo (Silva et. al. 2006).
Segundo (Guzzo e Pasquali, 2001), um teste é um procedimento sistemático utilizado para observar um determinado comportamento e descrevê-lo com a ajuda de escalas numéricas ou categorias fixas. Percebe-se, portanto que os questionários podem ser instrumentos de medição utilizados em testes, principalmente os que são elaborados segundo a utilização de escalas.
3.3.1. Escalas de Likert
Em 1932, Rensis Likert, elaborou uma maneira de medir níveis de aceitação e ponderar respostas a uma pergunta utilizando escalas. As Escalas de Likert, ou Escalas Somadas, requerem dos respondentes a indicação do grau de concordância ou discordância com declarações relativas a um determinado objeto avaliado e suas características ou critérios de avaliação. Questionários compostos por escalas são adequados à coleta de informações subjetivas para posterior análise quantitativa, uma vez que as pessoas respondem a esses questionários segundo experiências e influências sociais às quais são submetidos e as escalas oferecidas ao respondente podem ser quantificadas (Brandalise, 2005).
Escalas de Likert são amplamente adotadas na construção de questões devido a um conjunto de características positivas, dentre as quais se destacam a facilidade de construção de questões (Santos, 2007), a popularidade da escala (Alexandre, 2003) e a precisão e simplicidade de sua aplicação devido ao maior número de alternativas de resposta (Brandalise, 2005).
O comprimento da escala de Likert adotado pode variar em até nove níveis que separam dois qualificadores utilizados para avaliar uma afirmação. Alguns exemplos de qualificadores são: concordo e discordo, satisfeito e insatisfeito, eficiente e ineficiente, e agradável e desagradável. O critério de avaliação adotado deve ser definido para que as questões possam ser criadas. Cada questão deve ser elaborada de forma clara e objetiva, de forma a levar em conta um critério de avaliação e evitar uma interpretação dúbia. Na Figura 5 é mostrado um exemplo de questão baseada em Escalas de Likert, essa questão foi retirada do site do fabricante do da ferramenta de survey Quizmaker. Maiores detalhes sobre essa ferramenta podem ser encontrados em http://www.articulate.com/.
Figura 5. Questão baseada na Escalas de Likert. Fonte: articulate.com.
Quanto ao comprimento da escala existe uma contradição em relação ao número de níveis. É importante manter um número impar de níveis para dar aos respondentes a possibilidade de uma escolha integralmente medial. Do contrário, como em uma escala de seis níveis, eles são obrigados a escolher um nível não central, indicando que estão sempre inclinados a um dos extremos, o que nem sempre se confirma. Por outro lado, o uso de escalas de comprimento impar, pode
provocar uma atitude tendenciosa, o respondente pode marcar o nível médio por não saber ou não ter experiência no assunto abordado (Alexandre, 2003).
A opção N/A (Não se Aplica) também pode ser oferecida como opção de resposta em uma questão. Esta opção deve existir sempre que haja uma possibilidade de interpretação na qual os qualificadores não se adéqüem ao objeto avaliado. Outra utilidade é evitar respostas conduzidas pelas escolhas tendenciosas ilustradas anteriormente. Sendo assim, ao marcar a opção N/A o respondente se exime da responsabilidade de responder a questão devido a não compreensão da questão ou conhecimento insuficiente sobre o assunto abordado.
Para cada nível de resposta da escala será definido um valor. Este valor será atribuído aos itens da escala de acordo com a adequação do qualificador para com o objeto avaliado. Ao final da aplicação dos questionários, é feita a coleta das informações que servem de base para a realização de cálculos e análises estatísticas. Através das respostas e seus respectivos pesos é possível mensurar e apresentar numericamente as características subjetivas de um determinado objeto avaliado segundo os critérios de avaliação abordados nas questões.
3.3.2. Ferramentas de Survey
Alguns softwares são desenvolvidos especificamente para criar questionários e aplicá-los a um grupo de pessoas. A partir de ferramentas como SurveyMonkey, Quizmaker, Wufoo e o Google Survey Tool é possível elaborar questionários com questões diversas, além de poder submetê-los aos respondentes através de diversos meios. Através dessas ferramentas é possível aplicar questionários a partir de formulário acessados via e-mail, formulários acessados via web ou através do próprio software utilizado para criá-lo.
Através dessas ferramentas é possível organizar as respostas dadas de maneira que estejam dispostas para análises estatísticas posteriores. Algumas permitem, ainda, exportar o conjunto de respostas em formatos compatíveis com softwares diversos.
4. Desenvolvimento do projeto
Para alcançar o objetivo principal desse trabalho, um método computacional para definir a compatibilidade entre ferramentas e projetos, alguns observações e estudos foram necessários. Primeiramente, foi observado que existem diversas ferramentas computacionais voltadas à GP. Dentre as ferramentas utilizadas no estudo, notou-se que nem todas implementam, por completo, as funcionalidades consideradas nesse trabalho. Algumas ferramentas não apresentam certas funcionalidades e/ou implementam um determinado conceito de maneira particular.
4.1.
Avaliação de funcionalidades em ferramentas de
gerência
Para essa primeira análise foi feita uma avaliação em 24 ferramentas (Tabela 1). A verificação da existência de uma funcionalidade em cada ferramenta foi feita a partir das informações disponibilizadas nos sites dos fabricantes e a partir do uso de cada ferramenta. As ferramentas avaliadas foram selecionadas a partir de indicações existentes em sites e blogs especializados em GP, tais como Revista Mundo PM e Universo GP. A lista completa com o nome e os endereços eletrônicos das fontes encontra-se no Apêndice D.
Para melhor delinear as ferramentas foram definidos 3 níveis de categorização. Os níveis definidos são referentes aos conceitos teóricos vistos no Capítulo 2 e classificam as ferramentas segundo a existência das funcionalidades apresentadas no Capítulo 3. O nível de categorização SIM, observado na Tabela 1 como a letra S, indica que a ferramenta implementa a funcionalidade de acordo com o que a teoria apresenta, seguindo suas particularidades, além de produzir resultados semelhantes aos resultados produzidos pelos processos teóricos.
O nível PARCIAL, representado pela letra P, é aqui utilizado para indicar que determinada funcionalidade apesar de encontrada na ferramenta, apresenta certa discrepância em relação aos conceitos teóricos anteriormente descritos. Outros recursos que não são encontrados nas ferramentas, nível de categorização NÃO, são marcados na Tabela 1 pela letra N. Nesses casos a ferramenta não traz nenhuma indicação referente ao recurso, ou funções que o valham.
As funcionalidades inerentes a uma FGP dão ao gerente a capacidade de monitorar um grande número de informações sobre o projeto e executar atividades como monitorar tarefas, monitorar recursos ou tomar algumas decisões. Tais atividades criam uma dependência entre o gerente e a ferramenta utilizada, pois as funcionalidades encontradas na ferramenta propiciam o monitoramento completo do projeto. Essas funcionalidades permitem a visualização inteligível e a alteração eficiente dessas informações.
Observa-se, portanto, que a inexistência de determinadas funcionalidades pode causar um monitoramento incompleto das informações do projeto, portanto afetar a percepção do gerente sobre tais informações. Sendo assim, nota-se uma possível dependência entre a ferramenta utilizada e a atuação do gerente. Pois, existem inúmeras ferramentas de gerência e cada uma prioriza determinados
