gerenciamento de projetos de software
TRANSCRIPT
SENAI - SERVIÇO NACIONAL DE APRENDIZAGEM INDUSTRIAL
JEFERSON ANDRÉ FARIAS
GERENCIAMENTO DE PROJETOS DE SOFTWARE
UM ESTUDO DE CASO
Florianópolis – SC
2008
JEFERSON ANDRÉ FARIAS
GERENCIAMENTO DE PROJETOS DE SOFTWARE
UM ESTUDO DE CASO
Trabalho de Conclusão de Curso de Pós-Graduação Lato Sensu em Gerenciamento de Projetos apresentado como requisito parcial para obtenção do grau de Especialista em Gerenciamento de Projetos da Faculdade de Tecnologia SENAI Florianópolis em parceria com EUAX – Gestão de Projetos.
Orientador: Prof. Antonio Joaquim da Silva
Florianópolis – SC
2008
JEFERSON ANDRÉ FARIAS
GERENCIAMENTO DE PROJETOS DE SOFTWARE
UM ESTUDO DE CASO
Trabalho de Conclusão de Curso apresentado à Banca Examinadora do Curso de Pós Graduação Lato Sensu em Gerenciamento de Projetos da Faculdade de Tecnologia SENAI Florianópolis em cumprimento a requisito parcial para obtenção do título de especialista em Gerenciamento de Projetos.
APROVADO PELA BANCA EXAMINADORA
EM FLORIANÓPOLIS, 15 DE SETEMBRO DE 2008.
____________________________________________________ Prof. Antonio Joaquim da Silva, Esp. SENAI / Florianópolis
Coordenador do Curso
BANCA EXAMINADORA
__________________________________________________ Prof. Antonio Joaquim da Silva, Esp. SENAI Florianópolis
Orientador
__________________________________________________ Profª. Francisca Rasche, Me. SENAI - Florianópolis
Examinadora
Florianópolis – SC
2008
Dedico este trabalho aos meus falecidos pais,
pelo Amor que nos envolve em laços de
afinidade eterna. Pelos exemplos de que a vida
é um processo constante de busca e
aperfeiçoamento, mesmo que por vezes,
estejamos dispersos a este propósito.
AGRADECIMENTOS
Agradeço inicialmente a DEUS, por mais esta oportunidade, pela inspiração, pela
força sempre presente.
A minha esposa, Priscila Sobierajski Barreto, pelas palavras de incentivo, pelos
gestos de carinho, pela paciência, sem esquecer é claro, do AMOR que nos une.
Ao meu orientador, Antonio Joaquim da Silva, pelo auxílio sempre presente, pela
extrema paciência, pelos exemplos de profissionalismo.
A professora Francisca Rasche, pelo auxílio na organização metodológica.
Ao professor Carlos Fernando Martins, pelas orientações e pelo bom humor.
Aos demais professores pelos ensinamentos.
Aos meus colegas de trabalho, pelo aprendizado diário e pela oportunidade de
colocar em prática todo o conhecimento adquirido durante o curso.
Aos integrantes da turma, pessoas com quem a oportunidade de trocar
experiências, ampliar contatos, aprender, e principalmente fazer grandes amizades.
I
RESUMO
Com os crescentes avanços tecnológicos e econômicos, o gerenciamento de projetos tornou-se uma ferramenta poderosa para o desenvolvimento das empresas, nos seus mais diversos segmentos. Buscar uma forma organizada e padronizada de gerenciar projetos denota forma eficiente de competitividade. Com o intuito de buscar uma forma de adaptação a estes constantes avanços, este trabalho pesquisa e apresenta uma metodologia de gerenciamento de projetos para ser inserido em ambiente específico. A metodologia aplicada neste trabalho baseou-se no levantamento bibliográfico em livros especializados, pesquisas na Internet, trabalhos acadêmicos, além de padrões criados por órgãos nacionais e internacionais, propiciando embasamento mínimo necessário sobre metodologias de gerenciamento de projetos, visando a busca de práticas a serem inseridas no ambiente de pesquisa. Objetiva-se neste trabalho uma análise, por intermédio de um estudo de caso frente a um referencial bibliográfico, a indicação e adaptação de práticas de gerenciamento de projetos que possam auxiliar a condução de projetos na empresa alvo de estudo, levando-se em consideração seu momento atual e seu planejamento estratégico. Os resultados obtidos neste trabalho atingiram os objetivos propostos, uma vez que foram identificadas práticas de gerenciamento de projetos mais viáveis, podendo as mesmas ser inseridas no ambiente de estudo de maneira gradativa.
Palavras chave: Gerenciamento de Projetos, Desenvolvimento de Software.
II
ABSTRACT
Project Management has shown to be a powerful tool helping companies on their growth when adding constant technological and economical improvements to the equation. A company who is looking for organized and standardized ways of managing a project keeps competitive efficiency on their side. Willing to adapt to these constant improvements, project management methodologies were researched and are shown here to be used in a specific environment. Specialized books, Internet, academic papers, or even more, national and international standardization organizations, were basic bibliographic sources of information about project management methodologies applied to a research environment. The target of this study is to use the bibliographic study compared to a real case scenario to analyze what project management practices can be indicated and adapted to the company who is presented on this study. Nonetheless, this analyze, has been based considering the present moment and this company strategic planning. The results of this study has matched its objective, since more interesting project management practice were identified and may be implanted on the studied company in a gradual way.
Keywords: Project Management, Software Development.
III
LISTA DE FIGURAS
Figura 1 – Exemplo de réguas de sucesso ................................................................................12
Figura 2 – O Ciclo do Scrum....................................................................................................21
Figura 3 – Interação entre grupos de processos em um projeto................................................24
Figura 4 – Visão geral das áreas de conhecimento em gerenciamento de projetos e os
processos de gerenciamento de projetos ...................................................................................26
Figura 5 – Componentes do MPS.BR.......................................................................................28
Figura 6 – Estrutura organizacional da empresa alvo de estudo...............................................39
Figura 7 – Estrutura organizacional do setor de desenvolvimento da empresa alvo de estudo 40
Figura 8 – Novo processo de desenvolvimento proposto. ........................................................52
LISTA DE TABELAS
Tabela 1 - Níveis de maturidade do MR-MPS..........................................................................31
IV
LISTA DE SIGLAS
ACATE Associação Catarinense de Tecnologia
ANSI American National Standarts Institute
ANVISA Agência Nacional de Vigilância Sanitária
APM Agile Project Management
BID Banco Interamericano de Desenvolvimento
CNPq Conselho Nacional de Desenvolvimento Científico e Tecnológico
DSDM Dynamic System Development Method
FINEP Financiadora de Estudos e Projetos
MCT Ministério da Ciência e Tecnologia
MA-MPS Método de Avaliação para Melhoria de Processo de Software.
MN-MPS Modelo de Negócio para Melhoria de Processo de Software.
MR-MPS Modelo de Referência para Melhoria de Processo de Software.
MPS.BR Melhoria do Processo de Software Brasileiro
PACS Picture Archiving and Communication Systems
PMBOK Project Management Body of Knowledge
PMI Project Management Institute
RAP Rapid Plainning
RC Release Candidate
SOFTEX Associação para Promoção da Excelência do Software Brasileiro
XP Extreme Programming
XPM Extreme Project Management
SUMÁRIO
1. INTRODUÇÃO .................................................................................................................1
1.1. Tema da pesquisa........................................................................................................2 1.2. Questões de pesquisa ..................................................................................................2 1.3. Objetivos.....................................................................................................................3
1.3.1. Objetivo Geral...........................................................................................................3 1.3.2. Objetivos Específicos................................................................................................3
1.4. Justificativa .................................................................................................................4 1.5. Estrutura do Trabalho .................................................................................................4
2. REVISÃO BIBLIOGRÁFICA ........................................................................................6
2.1. Gerenciamento de Projetos .........................................................................................6 2.2. Gerenciamento de Projetos Ágil .................................................................................7
2.2.1. XPM (Extreme Project Management) ......................................................................9 2.2.1.1. Valores ............................................................................................................9 2.2.1.2. Regras ...........................................................................................................10 2.2.1.3. Técnicas e Ferramentas.................................................................................12
2.2.2. APM (Agile Project Management) .........................................................................13 2.2.2.1. Princípios ......................................................................................................14 2.2.2.2. Práticas..........................................................................................................14
2.2.3. Scrum ......................................................................................................................17 2.2.3.1. Papéis e responsabilidades............................................................................18 2.2.3.2. Fundamentos .................................................................................................19 2.2.3.3. O ciclo do Scrum ..........................................................................................20
2.3. PMBOK - Project Management Body of Knowledge ..............................................21 2.3.1. O ciclo de vida do projeto:......................................................................................22 2.3.2. Grupos de Processos ...............................................................................................22 2.3.3. Áreas de Conhecimento ..........................................................................................24
2.4. MPS/BR....................................................................................................................27 2.4.1. Guias .......................................................................................................................28 2.4.2. Níveis de Maturidade..............................................................................................29 2.4.3. Processo ..................................................................................................................30 2.4.4. Capacidade de Processo..........................................................................................30
3. METODOLOGIA ...............................................................................................................32
3.1. Classificação da Pesquisa .........................................................................................32 3.2. Procedimentos Técnicos ...........................................................................................32
4. ESTUDO DE CASO............................................................................................................35
4.1. Apresentação da Empresa.........................................................................................35 4.2. Planejamento estratégico da empresa .......................................................................36
4.2.1. Negócio ...................................................................................................................37 4.2.2. Missão.....................................................................................................................37 4.2.3. Visão .......................................................................................................................37 4.2.4. Objetivo...................................................................................................................37 4.2.5. Iniciativas................................................................................................................38
4.3. Estrutura organizacional ...........................................................................................38 4.4. Diagnóstico do ambiente interno ..............................................................................41
4.4.1. Contextualização dos projetos da empresa .............................................................41
4.4.2. Contextualização das estruturas da empresa e seus papéis.....................................41 4.4.3. Processo de desenvolvimento de software..............................................................41 4.4.4. Levantamento de requisitos ....................................................................................42
4.4.4.1. Identificação de erros e não-conformidades.................................................42 4.4.4.2. Análise de requisitos, erros e não-conformidades ........................................42 4.4.4.3. Definição de versões .....................................................................................43 4.4.4.4. Implementação..............................................................................................43 4.4.4.5. Controle de Qualidade ..................................................................................44 4.4.4.6. Liberação de versões.....................................................................................44 4.4.4.7. Pesquisa e Desenvolvimento.........................................................................44 4.4.4.8. Práticas de Gerenciamento de Projetos.........................................................44
4.4.5. Dificuldades encontradas ........................................................................................45
5. PROPOSTA DE METOLOGIA ........................................................................................47
5.1. Novo processo de desenvolvimento de software ......................................................47 5.1.1. Primeira Etapa.........................................................................................................48
5.1.1.1. Iniciação de Novo Ciclo de Desenvolvimento..............................................48 5.1.1.2. Testes Finais do Ciclo de Desenvolvimento anterior ...................................50
5.1.2. Segunda Etapa.........................................................................................................50 5.1.3. Terceira Etapa .........................................................................................................51
5.2. Apresentação do novo processo de desenvolvimento...............................................52 5.3. Alinhamento de Processos ........................................................................................54 5.4. Formalização de Processos .......................................................................................54 5.5. Práticas de Sugeridas ................................................................................................55
6. CONCLUSÕES...................................................................................................................57
6.1. Sugestões para trabalhos futuros...............................................................................58
REFERÊNCIAS ......................................................................................................................59
1
1. INTRODUÇÃO
É comum verificarmos atualmente, empresas de desenvolvimento de software de
pequeno porte que utilizam um reduzido conjunto de padrões ou boas práticas no
gerenciamento de seus projetos.
Segundo Castor (2007), esta pouca afinidade entre pequenas empresas e técnicas
de gerenciamento de projetos ocorre devido ao fato de pequenas empresas serem associadas à
uma alta dose de improvisação, enquanto que o gerenciamento de projetos exige uma elevada
dose de previsibilidade e rigor.
Os fatores que motivaram a concepção de projetos de desenvolvimento de software
com a utilização reduzida de padrões ou boas práticas em seus gerenciamentos, geralmente
vem de encontro com o histórico da empresa.
Na maioria dos casos, tratam-se de pequenas empresas, criadas para suprir
demandas de desenvolvimento de softwares específicos, para desenvolverem soluções mais
simples ou mais acessíveis financeiramente em comparação a soluções já existentes, tornando-
as viáveis a um mercado consumidor de menor poder aquisitivo.
Inicialmente estas pequenas empresas possuem um número reduzido de recursos.
No caso de recursos humanos, estes são, em alguns casos, os próprios sócios da empresa. Elas
têm como um de seus atributos indissociáveis a concentração em um, ou pouquíssimos
administradores, das decisões relativas a produtos, mercados, tecnologia, finanças e
administração, onde as responsabilidades se sobrepõem de maneira informal (CASTOR,
2007).
Com gradativo crescimento destas empresas, surgem novas oportunidades de
negócio gerando demanda de aquisição e contratação de novos recursos.
Na medida em que novos recursos são adquiridos e contratados, ocorrem melhoras
no processo de desenvolvimento de software, em decorrência da soma intelectual e
2
tecnológica das novas aquisições e contratações. Mesmo com este fator positivo, os novos
projetos oriundos das novas oportunidades de negócio ainda não possuem um padrão definido
de gerenciamento em suas etapas: iniciação, controle, execução e finalização.
A não existência de um gerenciamento específico dos projetos de desenvolvimento
de software, aliado crescimento destas empresas, gera dificuldades durante todo o ciclo destes
projetos, na definição de escopo, na análise de riscos, na manutenção de softwares e no
gerenciamento dos recursos envolvidos nos projetos, gerando custos excessivos, esforços
extras, além da possibilidade de não cumprimento de prazos.
Tendo como base o contexto apresentado, este trabalho visa desenvolvimento e
apresentação de uma metodologia de gerenciamento de projetos de software, baseado em
padrões e boas práticas de gerenciamento de projetos para que possa ser incorporado
gradativamente no cotidiano de projetos uma empresa com o perfil citado acima, de modo a
possibilitar um controle mais efetivo sobre os mesmos, tornando-os mais produtivos e por
conseqüência com melhores resultados.
A empresa selecionada para a efetuação deste estudo de caso será descrita
posteriormente neste trabalho, no capítulo 4.
1.1. Tema da pesquisa
Gerenciamento de Projetos de Software.
1.2. Questões de pesquisa
Quais são as práticas de gerenciamento de projetos de software que a empresa
selecionada utiliza atualmente?
3
Que boas práticas de gerenciamento de projetos podem ser incorporadas na
empresa de forma a melhorar seu desempenho atual e auxiliar na obtenção de seus resultados
conforme seu planejamento estratégico?
1.3. Objetivos
Frente ao tema proposto, apresentam-se o objetivo geral e os específicos deste
trabalho.
1.3.1. Objetivo Geral
Desenvolver e apresentar uma metodologia de gerenciamento de projetos de
software alinhado a necessidades atuais e ao planejamento estratégico de uma pequena
empresa.
1.3.2. Objetivos Específicos
Os objetivos específicos deste trabalho compreendem as seguintes atividades:
a) Identificar quais são as práticas de gerenciamento de projetos de software que a empresa
selecionada utiliza atualmente.
b) Analisar, indicar e adaptar práticas de gerenciamento de projetos que podem ser úteis à
empresa selecionada, levando em consideração o momento atual da empresa e seu
planejamento estratégico (visão).
c) Criar uma metodologia de gerenciamento de projetos de software com as práticas mais
viáveis à empresa alvo do estudo de caso, adequando-as gradativamente ao seu contexto.
4
1.4. Justificativa
Partindo do princípio de que existe a possibilidade do aumento da quantidade de
projetos e o reconhecimento da importância dos mesmos para a empresa. A apresentação de
uma metodologia de gerenciamento de projetos para a empresa visa auxiliá-la na busca de
uma forma padronizada de conduzi-los e monitorá-los, para com isso possibilitar a
compilação de uma visão centralizada e precisa sobre o andamento e situação de cada um dos
projetos da empresa.
Como justificativa, convém citar um desafio ainda maior: Como inserir a forma
padronizada de maneira prática, gradativa, estando ela alinhada aos objetivos estratégicos da
empresa, sem causar prejuízo ao conjunto das atividades em andamento, levando-se em
consideração a situação atual da mesma e os recursos disponíveis para propiciar tal mudança?
1.5. Estrutura do Trabalho
O presente trabalho está estruturado em seis capítulos.
No primeiro capítulo, denominado Introdução são apresentados o tema e a questão
de pesquisa, o objetivo geral e os objetivos específicos, sendo finalizado com a justificativa da
pesquisa.
O segundo capítulo, diz respeito à Revisão Bibliográfica, onde serão apresentados
conceitos e definições referentes aos temas relevantes ao estudo, baseados em literaturas com
respaldo científico. Os temas abordados serão: metodologias, guias, processos e boas práticas
de gerenciamento de projetos de software, sempre levando em consideração o contexto da
empresa alvo de estudo.
O terceiro capítulo é composto pela Metodologia utilizada na pesquisa.
5
O quarto capítulo é denominado Estudo de Caso, onde será efetuada a descrição do
ambiente alvo de estudo, além de diagnóstico das práticas de gerenciamento de software hoje
efetuadas no mesmo.
O quinto capítulo, denominado de Proposta de Metodologia, tem como base o
segundo e quarto capítulos, e trata-se da descrição de boas práticas de gerenciamento de
projetos de software a serem propostas a empresa alvo de estudo, além da forma com que tais
práticas podem ser inseridas em seu contexto.
No sexto capítulo, será apresentada a Conclusão deste trabalho, além das
perspectivas de continuidade do mesmo, na forma de melhorias na metodologia proposta.
Por fim, são apresentadas as referências utilizadas na confecção deste trabalho.
6
2. REVISÃO BIBLIOGRÁFICA
2.1. Gerenciamento de Projetos
Conforme o PMBOK (2004), gerenciamento de projetos trata-se da aplicação de
conhecimentos, habilidades, ferramentas e técnicas as atividades do projeto a fim de atender
aos seus requisitos. Sua realização se dá por intermédio da aplicação e integração de processos
de iniciação, planejamento, execução, monitoramento e controle, e por fim o encerramento.
A gerência de projetos surgiu pela demanda de novos métodos de gerenciamento,
sendo consideradas três forças básicas que impulsionam sua aplicação que são: o crescimento
exponencial do conhecimento humano, a demanda crescente por produtos e serviços mais
complexos e padronizados, e a evolução da competição global pela produção de produtos e
serviços (ZANONI, 2001).
O termo gerência de projetos é também utilizado para descrever uma abordagem
organizacional para gerenciamento de processos operacionais contínuos. Esta abordagem,
mais conhecida como gerência por projetos, trata aspectos de serviços continuados como
projetos, objetivando aplicar a eles também os conceitos de gerência de projetos.
Gerenciar projetos, segundo o PMBOK (2004) inclui:
a) Identificação de necessidades.
b) Estabelecimento de objetivos claros e alcançáveis.
c) Balanceamento de demandas conflitantes de qualidade, escopo, tempo e custo.
d) Adaptação de especificações, dos planos e da abordagem às diferentes preocupações e
expectativas das diversas partes interessadas.
O principal objetivo gerenciamento de projetos consiste na obtenção de um
equilíbrio entre custos, prazos e qualidade, buscando atingir metas previamente estabelecidas.
7
2.2. Gerenciamento de Projetos Ágil
Em um contexto onde avanços tecnológicos acontecem de maneira cada vez mais
rápida, é importante que as empresas estejam atentas às inovações a fim de ampliarem sua
capacidade e agilidade produtiva. Este também é um desafio para a área de desenvolvimento
de software, que constantemente visa a melhoria em seu processo produtivo.
Mesmo com a constante evolução de métodos, técnicas e ferramentas nesta área, a
entrega de software em prazos e custos estabelecidos nem sempre é atingida. Uma das causas
deste problema é o excesso de formalidade nos modelos de processo propostos nos últimos
anos (FILHO, 2005).
Conforme Yoshima (2007), o desenvolvimento de software é uma atividade
completamente diferente de tudo o que a indústria construiu desde os tempos de revolução
industrial. Cita ainda que reconhecer que o desenvolvimento de software requer práticas
especiais de gerenciamento de projetos, por terem uma natureza que denomina como
“diferente”, é o primeiro passo de uma importante caminhada que irá definir o sucesso ou o
fracasso de projetos de desenvolvimento de software.
Uma nova abordagem para o desenvolvimento de software tem despertado grande
interesse entre as organizações de todo mundo. Trata-se de uma tendência para o
desenvolvimento ágil de aplicações, motivado pelo ritmo acelerado de mudanças na
tecnologia da informação, pressões por constantes inovações, concorrência acirrada e grande
dinamismo no ambiente de negócios (PEREIRA, 2007).
Com o objetivo de oferecer ao mundo uma alternativa às metodologias pesadas,
que exigem um planejamento rigoroso e detalhado de todo o processo de desenvolvimento de
software, tornando-o lento e burocrático, um grupo de 17 autores e representantes das mais
variadas técnicas e metodologias ágeis reuniu-se para identificar boas práticas de
desenvolvimento de projetos dentre as metodologias e técnicas existentes, padronizando-a.
8
Este grupo autodenominou-se de aliança ágil (agille alliance) e defende valores e
práticas de métodos ágeis, apresentando valores e princípios que definem critérios para o
desenvolvimento ágil (MÜLLER, 2004). O resultado deste encontro foi a criação do
Manifesto para Desenvolvimento Ágil de Software (Agile Manifesto, 2001), cujos valores são
descritos a seguir:
a) Indivíduos e interações são mais importantes que processos e ferramentas.
b) Software funcionando é mais importante do que documentação detalhada.
c) O relacionamento com o cliente é mais importante do que a negociação de contratos.
d) Adaptação às mudanças é mais importante do que seguir um planejamento.
Compreender os valores do Agile Manifesto traz novas sugestões para a melhoria
de métodos, processos e técnicas de desenvolvimento e gestão de projetos (PEREIRA, 2007).
Conforme Müller (2004), os métodos de desenvolvimento ágeis adaptam-se às diversas
situações e necessidades de software, como mudanças constantes nos requisitos, diferente dos
processos tradicionais, que buscam prever todos os requisitos e necessidades do sistema.
Outro valor significativo é o incentivo ao trabalho em equipe, sendo
constantemente reforçada a idéia de time, pois as pessoas são o plano principal no
desenvolvimento ágil, não o processo. Este fator facilita o gerenciamento do projeto, uma vez
que propicia uma maior integração e comprometimento da equipe do projeto, que
consequentemente se sente mais motivada (PEREIRA, 2007).
O reforço do planejamento do projeto, minimizando riscos, considerando que o
planejamento é mais importante do que o plano (uma vez que o mesmo não é cessado até que
se tenha atingido a satisfação do cliente na entrega do produto final) é outra característica
positiva a ser destacada.
Existem várias opções para começar a praticar a agilidade em projetos de software,
das quais podem ser destacadas o XP (Extreme Programming), Scrum (PEREIRA, 2007),
9
além de XPM (Extreme Project Management) e APM (Agile Project Management)
(MAGALHÃES, 2005).
Uma vez que XP (Extreme Programming) tem seu enfoque voltado para práticas
de desenvolvimento de software (e não gerenciamento), não serão citadas suas características
no decorrer desta revisão bibliográfica.
2.2.1. XPM (Extreme Project Management)
O XPM caracteriza-se pela facilitação de mudanças no decorrer do projeto, sendo
recomendado para projetos de software para os quais o tempo e o custo para tornar o produto
disponível no mercado é crítico.
Segundo o paradigma ágil, o XPM visa a melhoria no gerenciamento de projetos,
cuja abordagem de desenvolvimento é baseada em XP (Extreme Programing).
Sua principal característica frente às abordagens tradicionais está na sua atitude em
relação às mudanças, no qual os resultados direcionam o planejamento e não o contrário.
Segundo Magalhães (2005), a meta é entregar o resultado desejado e não necessariamente o
resultado planejado.
2.2.1.1. Valores
Segundo PONS (2004), são considerados valores do XPM:
a) Participação: O gerenciamento de projetos é baseado na participação de stakeholders 1do
projeto.
b) Pró-Atividade: Trata-se de um processo criativo e pró-ativo de solução de problemas.
c) Transparência: Todas as informações do projeto são compartilhadas com stakeholders.
1 Stakeholders são as partes envolvidas no projeto, englobando clientes, a organização executora do projeto, os membros da equipe, o gerente ou equipe de gerenciamento de projetos, os patrocinadores e os influenciadores do projeto.
10
d) Foco externo: O foco do Gerente de Projetos está relacionado ao foco dos stakeholders.
e) Confiança: A equipe do projeto é tratada como um conjunto de profissionais em que se
pode confiar.
2.2.1.2. Regras
Magalhães (2005) cita 11 regras que compõe o XPM, descritas a seguir:
a) A gerência de pessoas e processos criativos demanda processos de gerenciamento
criativos: Não existe uma maneira específica e certa para se gerenciar projetos na
dinâmica atual do mercado. Todos os envolvidos no projeto precisam de criatividade para
agregar valor e qualidade ao produto final.
b) Quanto menos o gerente souber sobre questões técnicas do projeto, melhor: Faz-se
necessário distinguir informação técnica da informação gerencial em um projeto, com o
intuito de viabilizar uma maior compreensão do mesmo. Uma vez que um abrange o
domínio de tecnologias, o outro abrange o controle processos e a integração das partes
envolvidas visando à agregação de valor ao produto. Experiências específicas devem ser
usadas em áreas específicas (MAGALHÃES, 2005).
c) O que ocorre depois do projeto é mais importante do que o que ocorre durante o projeto: O
acompanhamento de um projeto após sua implantação, possibilita uma análise de
cumprimento de metas de sucesso do projeto (por parte da equipe de desenvolvimento),
viabilizando a ampliação da visão do cliente do valor agregado pelo produto em seu
negócio.
d) Um planejamento de projeto desenvolvido sem a participação completa dos stakeholders
não é mais que a fantasia de um planejamento efetuado por uma só pessoa: Nesta regra é
destacada a importância do envolvimento dos stakeholders durante o processo de
11
planejamento, tornando-o aberto e colaborativo, o que facilita a busca de consenso na
resolução de pontos de discórdia entre eles.
e) Quanto mais tempo o gerente de projeto permanecer com os stakeholders, melhor: Sugere
que o gerente de projetos deve investir uma parte considerável de seu tempo na
compreensão das pessoas que fazem parte da equipe do projeto, já que a abordagem do
XPM é relacionada à informação gerencial (diferente do XP, cuja abordagem, conforme
citado anteriormente, é mais voltada para o desenvolvimento de software).
f) Se o sucesso de projeto não foi definido no começo, ele possivelmente não será alcançado
no final: Sugere que os critérios que determinam o sucesso de um projeto devem ser
definidos no início do projeto e acompanhados no seu decorrer, por intermédio de “réguas
de sucesso”, que serão descritas no decorrer deste tópico.
g) A importância da apresentação do lucro: Visa a análise do negócio, a fim de identificar o
valor agregado que o produto trará. Esta regra torna possível ainda à priorização de
funcionalidades a serem desenvolvidas de modo a maximizar benefícios.
h) Os stakeholders do projeto podem ser seus melhores aliados ou seus piores inimigos: A
fim de evitar a perda de recursos estratégicos, o XPM sugere a utilização de uma
ferramenta cujo objetivo é manter os stakeholders informados sobre a possibilidade de
utilização de um recurso (próprio, ou de outro stakeholder). A ferramenta utilizada para
este fim, também será descrita no decorrer deste tópico.
i) Se você não pode prever o futuro, não planeje detalhes: Trata-se de extensão de boas
práticas de desenvolvimento utilizadas em XP, onde planejamento e re-planejamento são
efetuados diariamente, envolvendo toda a equipe do projeto (inclusive stakeholders).
j) Se o seu projeto não mudou, fique preocupado: Trata-se de uma avaliação diária do
andamento do projeto, a fim de identificar quaisquer situações que possam prejudicar o
andamento do mesmo.
12
2.2.1.3. Técnicas e Ferramentas
São técnicas e ferramentas do XPM:
a) RAP (Rapid Plainning) (Utilizada na regra 4): Segundo Magalhães (2005), o XPM utiliza
Planejamento Rápido (RAP), para criar planos de projeto, visando assegurar a
fundamentação do mesmo, com a participação intensiva dos stakeholders. Conforme Pon
(2004), sem a realização de reuniões de planejamento intensivo, é comum a morosidade
no desenvolvimento de um plano de projeto, ao custo de o mesmo sofrer muitas revisões e
alterações. O mesmo autor cita ainda, como vantagem desta técnica que a duração do
projeto é diminuída, aumentando o alinhamento das expectativas de todos os envolvidos e
fortalecendo a comunicação.
b) “Réguas de Sucesso” (utilizada na regra 6): Trata-se do alinhamento de expectativas do
cliente, patrocinador e outros stakeholders (PON, 2004), ou seja, é a representação do grau
de atendimento dos critérios de sucesso do projeto definido pelos mesmos. A figura 1
ilustra um exemplo de réguas de sucesso.
Figura 1 – Exemplo de réguas de sucesso Fonte: Pon (2004)
13
c) Modelo O3 (Objective, Output, Outcome) (Utilizado na regra 7): Modelo que cria uma
cadeia de valores para o projeto, permitindo vislumbrar os benefícios atrelados aos
objetivos, tendo como princípio que a empresa só atingirá seus resultados se houverem
sucessos na produção de saídas relevantes ao projeto.
d) Acordo de Qualidade (Utilizado na regra 7): Trata-se do estabelecimento de critérios e
processos de qualidade do produto a partir de seus objetivos.
e) Acordos de Parceria (Utilizado na regra 8): Trata-se de ferramenta que documenta
serviços, identifica recursos capacitados, tempo estimado e custo estimado para as
necessidades de stakeholders.
2.2.2. APM (Agile Project Management)
O APM é um conjunto de práticas e princípios cuja finalidade é guiar o
gerenciamento de projetos, auxiliando as equipes de projetos a entregarem produtos ou
serviços de valor agregado em ambientes complexos, desafiadores e instáveis (DIAS, 2006).
Segundo MAGALHÃES (2005), O APM tem seu enfoque direcionado para
habilidades de liderança, destacando a combinação de características atreladas a esta
habilidade como visão de negócio, comunicação, flexibilidade, compreensão de requisitos
técnicos, juntamente com habilidade de planejamento, coordenação e execução.
No APM, é o cliente quem define e prioriza as funcionalidades essenciais ao seu
negócio, levando em consideração o valor agregado que estas funcionalidades trarão ao
mesmo. As equipes de desenvolvimento são responsáveis pela criação e monitoramento do
seu próprio planejamento, incluindo interações junto com o cliente para alinhamento de
expectativas. Em um cenário como este, o gerente de projetos tem pouca necessidade de atuar
de forma tradicional, passando a ser mais um facilitador e orientador.
14
Os valores e os princípios do APM descrevem a motivação de sua criação, já suas
práticas descrevem como pode ser aplicado. Ambos serão apresentados a seguir.
O APM é considerado uma das referências básicas para metodologias ágeis. Fora
concebido pelo grupo denominado aliança ágil (agille alliance), descrito anteriormente, e seus
valores são os mesmos descritos no manifesto ágil (Agile Manifesto, 2001), ou seja:
a) Indivíduos e interações são mais importantes que processos e ferramentas.
b) Software funcionando é mais importante do que documentação detalhada.
c) O relacionamento com o cliente é mais importante do que a negociação de contratos.
d) Adaptação às mudanças é mais importante do que seguir um planejamento.
2.2.2.1. Princípios
São considerados princípios do APM:
a) Entregar valor ao cliente.
b) Gerar entregas iterativas e baseadas em funcionalidades.
c) Buscar a excelência técnica.
d) Encorajar a exploração.
e) Construir times adaptativos, auto-organizados e auto-disciplinados.
f) Simplificação nas atividades.
2.2.2.2. Práticas
Segundo Magalhães (2005), são práticas do APM:
a) Visão Direcionada: Trata-se do estabelecimento de uma visão direcionada para o projeto,
reforçando-a continuamente por meio de atitudes, influenciando assim os membros da
equipe do projeto. Munido da visão do cliente no que diz respeito ao atendimento de suas
15
expectativas, o gerente de projetos deve prover uma propriedade coletiva desta visão,
facilitando a obtenção de senso comum sobre a mesma, por intermédio de debates.
Estando a visão do projeto clara a todos os membros da equipe, fica mais fácil a equipe em
manter o foco do projeto.
b) Trabalho e Colaboração em Equipe: Trata-se da facilitação da colaboração ativa da
equipe, estabelecendo-se condições para se manterem bons relacionamentos. Sessões de
planejamento são situações propícias para auxiliarem neste processo, Elas auxiliam no
desenvolvimento de uma compreensão e respeito comum entre os desenvolvedores e o
cliente. Com uma liderança adequada, na medida em que o projeto progride, sessões de
planejamento podem tornar-se altamente colaborativas e criativas, resultando em melhoria
do clima da equipe. Uma definição de papéis na equipe, o conhecimento da característica
de cada indivíduo (como habilidades complementares e interesses), aliadas a um
relacionamento próximo, cordial e respeitoso entre todos proporcionam interações ricas e
também aprimoram o trabalho colaborativo. Cabe ao gerente, o monitoramento da
dinâmica da equipe e decidir alguma intervenção (como resolução de conflitos, caso
necessário), não esquecendo de celebrar sucessos e marcos conquistados. Valorizar a
autonomia da equipe é fundamental para todas as outras práticas.
c) Regras Simples: Objetiva o fornecimento de suporte a equipe do projeto para um
comportamento complexo, permitindo que a mesma trabalhe em uma estrutura flexível.
Estas regras devem fornecer limites claros, mas não a ponto de restringir a autonomia e
criatividade da equipe. Devem ser declaradas explicitamente, compreendidas e acordadas
por todos os membros da equipe logo no início do projeto, cabendo ao gerente de projetos
a avaliação, junto dos mesmos, se estas regras estão sendo seguidas, procurando ajustá-las
continuamente.
16
d) Informação Aberta: Objetiva o fornecimento claro e aberto à informação, para que a
equipe possa adaptar-se continuamente, não estando alheios a situações que, em
abordagens tradicionais somente o gerente teria conhecimento. Algumas técnicas eficazes
para serem utilizadas na disseminação de informações: Uma proximidade do gerente de
projetos com a equipe, uso de quadros, reuniões diárias ou com freqüência definida
(incluindo a participação de stakeholders), uso de wiki2.
e) Toque leve: Trata-se da aplicação de um "controle inteligente" na equipe do projeto.
Levando em consideração que na gerência tradicional há um enfoque específico em
controle, seja de mudanças, de riscos, de pessoal, diversas metodologias, ferramentas e
práticas evoluíram com o intuito de administrar "um mundo fora de controle", acreditando
que controle resultaria em mais ordem. Algumas delas porém, não manipulam processos
cíclicos com facilidade, assim como situações variáveis presente em um mundo real e
incerto. O gerente de projetos que utiliza uma metodologia ágil, reconhece que é
impossível prever tudo antecipadamente, renunciando parte do controle, controlando
somente o que for suficiente para manter a ordem. Sob o ponto de vista da gerência
tradicional, esta ordem pode parecer com desordem ou caos. Mas se o gerente estiver
disposto a renunciar parte deste controle, as recompensas desta prática englobam uma
equipe dinâmica e comprometida, soluções inovadoras e adaptação contínua.
f) Vigilância Ágil: Conduzir uma equipe, levando em consideração as 5 primeiras regras
descritas anteriormente requer do gerente ágil uma vigilância contínua. Isto significa
confiar na equipe do projeto e no processo que elas auxiliaram a desenvolver, ser
observador, avaliar continuamente a equipe e os processos, monitorar sucessos e fracassos,
adaptando-se conforme a necessidade. A vigilância ágil consiste em algumas atitudes,
como: encorajar o desenvolvimento colaborativo e o trabalho em equipe, percebendo
2 Wiki é uma coleção de muitas páginas interligadas e cada uma delas pode ser visitada e editada por qualquer pessoa.
17
sinais de tensão e intervindo quando necessário, encorajar a auto-organização, estar
atualizado frente a tecnologia, estando situado na linguagem da equipe, motivar e
recompensar iniciativas, administrando expectativas, refletir sobre o que está de acordo e o
que precisa de melhoria.
2.2.3. Scrum
O Scrum é um método ágil para o gerenciamento de projetos de desenvolvimento
de software, cujo objetivo é a maximização da produtividade de um grupo de trabalho.
Segundo Filho (2005), o Scrum foi desenvolvido para gerenciar o processo de
desenvolvimento de software em ambientes em que os requisitos estão em constante mudança.
A metodologia Scrum pode ser vista como um processo incremental e iterativo,
mais orientado para o gerenciamento dos projetos de software (MAGALHÃES, 2005), mas
também pode ser usado para projetos sem relação com software, pois seus princípios são
aplicados a qualquer projeto (MÜLLER, 2004).
A idéia principal do Scrum é que o desenvolvimento de software envolve muitas
variáveis técnicas e de ambiente (como requisitos, recursos e tecnologia) que podem sofrer
mudanças durante o processo, tornando-o complexo e imprevisível, requerendo flexibilidade
para o acompanhamento de tais mudanças.
O Scrum é baseado em processos empíricos, ou seja, processos que não são pré-
definidos, por isso menos tempo é despendido tentando planejar e definir tarefas
antecipadamente, bem como para ler e criar documentação. Estes processos (empíricos)
divergem dos processos tradicionais (definidos), como o cascata e o espiral, quanto ao
tratamento da análise e desenvolvimento (MÜLLER, 2004).
18
Por se tratar de um framework3, o Scrum poderá ser útil como guia de boas práticas
para atingir objetivos (PEREIRA, 2007). Entretanto, as decisões de quando e como utilizá-lo,
quais táticas e estratégias seguir para obtenção de maior produtividade fica a cargo de quem as
estiver aplicando. Um dos aspectos positivos do Scrum é a sua adaptabilidade, pois o
conhecimento das suas práticas permite sua aplicação de variadas formas.
A seguir serão apresentadas algumas dos conceitos e práticas do Scrum.
2.2.3.1. Papéis e responsabilidades
São consideradas práticas do Srum:
a) Product Owner - Trata-se do encarregado pela definição de requisitos do produto, sendo
responsável por decidir a data de liberação da versão e o que deve conter a mesma. É
responsável também pelo retorno financeiro (ROI) do produto. Ele é quem pode mudar
requisitos e prioridades de cada Sprint, além ainda de poder aceitar ou rejeitar o resultado
de cada Sprint (PEREIRA, 2007).
b) Scrum Master – O Scrum Master é o responsável pela garantia dos utilização dos valores
do Scrum, respeitando e fazendo respeitar as práticas e regras do mesmo. Cabe a ele o
relacionamento com o cliente e com os membros da equipe, representando-os.
c) Scrum Team - Trata-se da equipe que desenvolverá o produto. Ela é responsável por
selecionar entre os itens priorizados, os que irão ser executados durante a Sprint, tendo
liberdade de realizar o que quiser dentro da Sprint para cumprir o objetivo da iteração.
Cabe aos membros da equipe uma auto-organização de forma participativa.
3 Framework é uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido.
19
2.2.3.2. Fundamentos
São considerados fundamentos do Scrum:
a) Product Backlog - Trata-se da lista das funcionalidades que estarão contempladas na
versão do software (organizadas em ordem de prioridade). É nela onde serão especificados
novos requisitos, tarefas e tecnologias.
b) Sprint – Sprint é o ciclo de desenvolvimento do Scrum. Não possui especificamente um
período de tempo pré-definido, mas sugere-se que seja curto (geralmente com duração
máxima de trinta dias). Durante sua execução são realizadas tarefas e atividades para
garantir a meta de entregar um software que contemple o disposto no product backlog.
c) Sprint Backlog – Trata-se do backlog que será executado durante o ciclo do Sprint, ou
seja, é uma lista com funcionalidades, atividades e tarefas a serem executadas e
desenvolvidas durante o Sprint.
d) Daily Meeting – Reunião realizada diariamente, com duração máxima de 15 minutos, onde
a equipe discute aspectos pertinentes ao trabalho. Nesta reunião é efetuada a análise do
que fora produzido desde a última reunião e o que se pretende fazer até a próxima. A
brevidade da reunião fica à cargo do Scrum Master.
e) Sprint Planning Meeting – Trata-se de reunião realizada antes do Sprint, onde são
definidos os itens que irão compor a lista de backlog do Sprint e sua ordem de prioridade
entre os itens. Por intermédio de estimativas efetuadas pela equipe de desenvolvimento,
será definida a lista de backlog do próximo Sprint. Nesta reunião os requisitos podem ser
alterados, sendo que após o início do Sprint só os desenvolvedores podem realizar
mudanças. (MÜLLER, 2005).
20
2.2.3.3. O ciclo do Scrum
O ciclo do Scrum, conforme ilustrado na Figura 2, inicia-se com o product
backlog, através de uma reunião de planejamento, onde o usuário vai definir e classificar as
funcionalidades desejadas para o software por nível de prioridade. A cada novo ciclo poderão
ser alterados os itens deste backlog, podendo-se inserir, mudar ou excluir requisitos antes
especificados. A mudança de requisitos é aceita, não prejudicando o andamento do projeto.
Backlog do Sprint - Esta etapa é efetuada após a definição do backlog de produto.
É nela onde são definidas (a partir do backlog do produto), quais atividades serão realizadas
no Sprint.
Sprint - Sprint é a fase de desenvolvimento do que fora definido no backlog do
Sprint. Uma vez iniciada só os desenvolvedores envolvidos poderão fazer mudanças nas
atividades especificadas. Estas mudanças tratam-se de alterações e expansões nas tarefas
definidas no backlog de Sprint e visam a melhor adaptação ao trabalho a ser realizado.
O objetivo do Sprint é completar as tarefas definidas para ele e entregar uma
pequena parte funcional do software, também conhecida como incremento. Para tanto a
equipe é livre para desenvolver, desde que os objetivos sejam alcançados (MÜLLER, 2005).
Qualquer problema ou necessidade da equipe ou com um membro em particular,
reporta-se ao Scrum Master, que deverá orientar a equipe para evitar problemas e atingir sua
meta.
Diariamente, durante o Sprint, realizam-se as reuniões de Scrum (os Daily
Meetings), onde a equipe se reúne e discute sobre o andamento do projeto. Nela, os membros
da equipe falam brevemente de como vai o seu trabalho, explicitando problemas encontrados
e qual será sua próxima atividade.
Por fim, é efetuada uma apresentação ao cliente o produto da iteração, ou seja, o
pedaço executável de software ou incremento, para ser analisado pelo usuário final (Product
21
Owner). Este incremento deverá estar testado e com as funcionalidades especificadas para ele.
Nesta fase também é analisado o progresso do projeto, onde são gerados gráficos de
monitoramento (MÜLLER, 2005).
Figura 2 – O Ciclo do Scrum Fonte: Magalhães (2005)
2.3. PMBOK - Project Management Body of Knowledge
O guia PMBOK (2004) é uma publicação que descreve conhecimentos e práticas
para gerência de projetos, publicado pelo PMI (Project Management Institute), sendo
mundialmente aceito e reconhecido como padrão neste segmento pelo ANSI (American
National Standarts Institute).
Nele são tratados aspectos como ciclo de vida do projeto, processos e grupos de
processos de gerenciamento, sendo abordadas áreas de conhecimento da gerência de projetos
e suas interações. Conforme Magalhães (2005) o PMBOK (2004) também pode ser utilizado
para orientar a definição de um processo padrão para o gerenciamento de projetos de software.
O conjunto de conhecimentos em gerenciamento de projetos descreve o
conhecimento exclusivo da área de gerenciamento de projetos e que se sobrepõe às outras
disciplinas de gerenciamento PMBOK (2004). Este conjunto de conhecimentos consiste na
22
definição do ciclo de vida do projeto, em cinco grupos de processos de gerenciamento de
projetos e em nove áreas de conhecimento, que serão apresentados a seguir.
2.3.1. O ciclo de vida do projeto:
Em se tratando de gerenciamento de projetos deve haver uma distinção do ciclo de
vida de projeto e do ciclo de vida do gerenciamento de projeto.
Com relação ao ciclo de vida de um projeto o PMBOK (2004) descreve-o como o
conjunto de fases nas quais um projeto é dividido, visando a determinação de seu início e fim.
São assim divididos visando facilitar sua elaboração progressiva, seu gerenciamento e seu
controle. Ainda segundo o PMBOK (2004), são as características específicas de cada projeto
que determinam seu ciclo de vida.
Com relação ao ciclo de vida do gerenciamento do projeto, o PMBOK (2004)
descreve que o gerenciamento de projetos ocorre por intermédio de processos (que é um
conjunto de ações que geram um resultado). Cita ainda que os processos de gerenciamento
estão distribuídos em 5 fases do ciclo de vida do gerenciamento do projeto: Iniciação,
Planejamento, Execução, Controle e Encerramento.
2.3.2. Grupos de Processos
Conforme o guia PMBOK (2004), o gerenciamento de projetos é um
empreendimento integrador, e esta integração exige que cada processo do projeto e do produto
seja adequadamente associado e conectado a outros processos, visando facilitar a sua
coordenação. Esta integração ocorre por intermédio da descrição da natureza dos processos de
gerenciamento de projetos, em termos da integração entre eles, das interações dentro deles e
dos objetivos a que atendem.
23
Esses processos são agregados em cinco grupos, definidos como os grupos de
processos de gerenciamento de projetos, que são:
a) Grupo de processos de iniciação: Visam à definição e autorização de um projeto ou uma
fase de um projeto.
b) Grupo de processos de planejamento: Visa à definição e o refinamento dos objetivos do
projeto (escopo), sendo posteriormente planejada a ação necessária para alcançar os
objetivos definidos.
c) Grupo de processos de execução: Visa à mobilização e integração de recursos a fim de
realizar o plano de gerenciamento do projeto.
d) Grupo de processos de monitoramento e controle: Visam o monitoramento e medição do
progresso no desenvolvimento do projeto, para que possam ser identificadas variações em
relação ao plano de gerenciamento do projeto, tornando possível a tomada de ações
corretivas e preventivas quando necessário.
e) Grupo de processos de encerramento: Visam à formalização da aceitação do produto,
serviço ou resultado, conduzindo o projeto a um final ordenado.
A figura 3 ilustra a interação entre os grupos de processos:
24
Figura 3 – Interação entre grupos de processos em um projeto Fonte: PMBOK (2004)
2.3.3. Áreas de Conhecimento
Com relação às áreas de conhecimento, o PMBOK (2004) identifica nove áreas de
concentração do conhecimento do gerenciamento de projetos, cujos objetivos são descritos a
seguir:
25
a) Gerenciamento da integração: Objetiva assegurar a coordenação dos elementos do projeto,
como negociações de conflitos visando atingir as necessidades de todas as partes
interessadas no mesmo. Envolve as atividades de desenvolvimento e execução do plano do
projeto, além do controle de mudanças.
b) Gerenciamento de escopo: Objetiva a definição e controle dos trabalhos solicitados no
projeto. Nele estão inseridas as atividades de iniciação, planejamento, definição,
verificação e controle de mudanças do escopo.
c) Gerenciamento do tempo: Objetiva a conclusão do projeto no prazo previsto. Nele estão
inseridos os processos de definição, ordenação, estimativa de duração das atividades, além
da elaboração e controle de cronogramas.
d) Gerenciamento de custos: Objetiva a garantia da conclusão da execução do projeto dentro
do orçamento previsto. Fazem parte desta área as atividades de planejamento de recursos,
estimativas, orçamentos e controle de custos.
e) Gerenciamento da qualidade: Objetiva a certificação de que o projeto satisfará as
conformidades solicitadas pelo cliente nas atividades de planejamento, garantia e controle
de qualidade.
f) Gerenciamento de recursos humanos: Objetiva a otimização da utilização de recursos
humanos envolvidos no projeto. As atividades pertinentes a este gerenciamento são: o
planejamento organizacional, alocação de recursos humanos e o desenvolvimento da
equipe do projeto.
g) Gerenciamento da comunicação: Objetiva a obtenção e disseminação adequada das
informações do projeto. Ou seja, as informações são filtradas de acordo com os papeis dos
envolvidos no projeto. Consiste das atividades de planejamento da comunicação,
distribuição da informação, relatórios de acompanhamento (reports) e encerramento
administrativo do projeto.
26
h) Gerenciamento de riscos: Objetiva a identificação e análise de riscos ao projeto, de modo
a maximizar resultados e minimizar conseqüências. Fazem parte desta área as atividades
de identificação, quantificação, tratamento e controle de tratamento de riscos.
i) Gerenciamento das aquisições: Objetiva a obtenção de recursos, bens e serviços externos a
capacidade produtiva da equipe do projeto. Neste gerenciamento são necessárias as
atividades de planejamento de aquisição, planejamento de solicitação, solicitação de
propostas, seleção de fornecedores, e administração e encerramento de contratos.
A figura 4 ilustra as áreas de conhecimento e os processos de gerenciamento de
projetos
Figura 4 – Visão geral das áreas de conhecimento em gerenciamento de projetos e os processos de gerenciamento de projetos
Fonte: PMBOK (2004)
27
2.4. MPS/BR
O MPS.BR (Softex, 2007) é um programa para a Melhoria de Processo do
Software Brasileiro. Trata-se de um projeto coordenado pela SOFTEX (Associação para
Promoção da Excelência do Software Brasileiro), com apoio do MCT (Ministério da Ciência
e Tecnologia), da FINEP (Financiadora de Estudos e Projetos) e do BID (Banco
Interamericano de Desenvolvimento).
Este programa busca estar adequado a empresas com diferentes tamanhos e
características, sendo elas públicas ou privadas, concentrando sua atenção nas micro,
pequenas e médias empresas, estando alinhado a padrões de qualidade já aceitos no contexto
de projetos mundial, aproveitando toda a competência já existente nos padrões e modelos de
melhoria de processo já disponíveis (Softex, 2007).
O MPS.BR é baseado em conceitos de maturidade e capacidade de processo para a
avaliação e melhoria da qualidade e produtividade de produtos de software e serviços
correlatos, cujo embasamento é orientado por três componentes, conforme ilustrado na figura
5:
a) Modelo de Referência (MR-MPS): O Modelo de Referência MR-MPS contém os
requisitos que os processos das unidades organizacionais devem atender para estar em
conformidade com o mesmo. Nele estão contidas as definições dos níveis de maturidade,
processos e atributos do processo, descritos no decorrer deste tópico. Este modelo está em
conformidade com os requisitos de modelos de referência de processo da norma ISO/IEC
15504-2 (ISO/IEC 15504-2, 2003).
b) Método de Avaliação (MA-MPS): O método de avaliação descreve o processo de
avaliação, os requisitos para os avaliadores e os requisitos para atender o Modelo de
Referência (MR-MPS), em conformidade com a norma ISO/IEC 15504, sendo descrito no
guia de avaliação.
28
c) Modelo de Negócio (MN-MPS): O Modelo de Negócio MN-MPS descreve regras de
negócio tanto para a implementação do Modelo de Referência (MR-MPS), seja pelas
instituições que desejam implementá-la, como para as instituições que almejem avaliá-la,
como para a organização de grupos de empresas para implementação do MR-MPS e
avaliação MA-MPS para tornarem-se consultores e certificadores de aquisição e
programas anuais de treinamento por meio de cursos, provas e workshops MPS.BR.
Figura 5 – Componentes do MPS.BR Fonte: SOFTEX (2007)
2.4.1. Guias
A descrição do MPS.BR (Softex, 2007) foi efetuada por meio de documentos em
formatos de guias, descritos a seguir:
a) Guia Geral: Guia que contém a descrição geral, detalhando o Modelo de Referência (MR-
MPS), seus componentes e as definições necessárias para seu entendimento e aplicação.
b) Guia de Aquisição: Guia que descreve um processo de aquisição de software e serviços
para este fim. Visa o apoio às instituições que desejam adquirir produtos de software e
serviços apoiando-se também no Modelo de referência (MR-MPS).
29
c) Guia de Avaliação: Guia que descreve o processo e o método de avaliação do Guia de
Aquisição, os requisitos para avaliadores líderes, avaliadores adjuntos e Instituições
Avaliadoras (IA).
d) Guia de Implementação: Guia que descreve como implementar um determinado nível do
Modelo de Referência (MR-MPS), sub-dividido em 7 partes.
2.4.2. Níveis de Maturidade
Segundo a Softex(2007), os níveis de maturidade estabelecem patamares de
evolução de processos, caracterizando estágios de melhoria da implementação de processos na
organização. O nível de maturidade em que se encontra uma organização permite prever o seu
desempenho futuro ao executar um ou mais processos.
São sete os níveis de maturidade do MPS.BR: A (Em Otimização), B (Gerenciado
Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F
(Gerenciado) e G (Parcialmente Gerenciado).
O nível G é o nível inicial, indicando que o processo é mais imaturo que os demais
níveis, e o nível A indica que o processo é mais maduro.
Perfis de processo são atribuídos a cada um dos níveis descritos. Eles indicam
pontos de melhoria nos processos. O atendimento de propósitos, a obtenção de resultados
esperados dos processos e dos atributos de processo estabelecidos são indicadores de alcance
de níveis de maturidade.
Segundo Weber (2006) os sete níveis do MR-MPS possibilitam uma
implementação e reconhecimento mais gradual da melhoria de processo de software,
facilitando sua adequação às pequenas e médias empresas, com visibilidade dos resultados em
prazos mais curtos.
30
2.4.3. Processo
Os processos no MR-MPS são descritos na forma de propósitos e resultados.
Propósitos descrevem o objetivo a ser atingido durante a execução de um processo.
Resultados estabelecem os resultados a serem obtidos com a efetiva implementação do
processo.
Os resultados obtidos podem ser evidenciados por intermédio de um artefato
produzido ou por intermédio de uma mudança significativa de estado ao ser executado o
processo.
2.4.4. Capacidade de Processo
Conforme Softex (2007), a capacidade do processo é representada por um conjunto
de atributos de processo descrito em termos de resultados esperados.
Ela expressa o grau de refinamento e institucionalização com que o processo é
executado. No MPS.BR, à medida que a organização evolui nos níveis de maturidade, um
maior nível de capacidade para desempenhar o processo deve ser atingido pela organização.
A capacidade do processo no MPS.BR possui nove (9) atributos de processos (AP)
que são: AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP 4.2, AP 5.1 e AP 5.2.
Cada AP está detalhado em termos de resultados esperados do atributo de processo
(RAP) para alcance completo do atributo de processo. A tabela 1 apresenta os níveis de
maturidade do MR-MPS, os processos e os atributos de processo correspondentes a cada
nível.
31
Tabela 1 - Níveis de maturidade do MR-MPS
Fonte SOFTEX(2007)
32
3. METODOLOGIA
A metodologia da pesquisa norteia o caminho a ser seguido, orienta o pesquisador
como realizar o trabalho, quais procedimentos seguir para que a pesquisa seja confiável e
tenha respaldo científico.
Para formular a metodologia utilizada nesta pesquisa, foi empregada a
classificação conforme Gil (2002). Segundo o autor, “toda e qualquer classificação se faz
mediante algum critério”, pode-se classificar a pesquisa com base em seus objetivos gerais, e
conforme os procedimentos técnicos utilizados.
3.1. Classificação da Pesquisa
Com base nos objetivos da pesquisa, o presente estudo é classificado como
exploratório e descritivo.
A pesquisa exploratória visa proporcionar maior familiaridade com o problema,
tornando-o explícito. Envolve levantamento bibliográfico, entrevistas com envolvidos em
experiências práticas com o problema pesquisado, assumindo, em geral, as formas de
pesquisas bibliográficas e estudos de caso (GIL, 2002).
Já a pesquisa descritiva visa descrever características de determinada população,
fenômeno ou ambiente. Envolve o uso de técnicas padronizadas de coleta de dados como
questionários e observação sistemática, assumindo em geral a forma de levantamento (GIL,
2002).
3.2. Procedimentos Técnicos
A classificação conforme os procedimentos técnicos utilizados têm como objetivo
traçar um modelo conceitual e operativo da pesquisa. A forma como os dados foram
33
coletados compreende os seguintes procedimentos técnicos: pesquisa bibliográfica,
documental, levantamento e estudo de caso.
Conforme Gil (2002) “A pesquisa bibliográfica é desenvolvida com base em
material já elaborado (...)”. A pesquisa bibliográfica dá sustentação teórica a qualquer tipo de
pesquisa.
A pesquisa é classificada como documental, pois fora elaborada a partir de
materiais que não receberam tratamento analítico (GIL, 2002). Foram utilizados documentos
internos da empresa alvo do estudo de caso, como instruções de trabalho, intranet4,
informativos.
Para obtenção de maiores informações referentes às práticas atuais de
gerenciamento de projetos de software será efetuado um levantamento. Levantamento é um
procedimento de interrogação direta de pessoas cuja atividade e comportamento deseja-se
conhecer (GIL, 2002). Nesta pesquisa, o levantamento de dados foi realizado a partir da
observação direta na empresa alvo de estudo, conforme será detalhado no estudo de caso.
O estudo de caso consiste em uma pesquisa profunda de uma ou poucas unidades,
tem como objetivo dar um caráter de profundidade e detalhamento. (VERGARA, 2004). A
presente pesquisa pode ser classificada como um estudo de caso, de uma realidade específica,
pois se trata de um estudo sobre as ações de gerenciamento de projetos de software utilizadas
atualmente pela empresa alvo de estudo.
Portanto, com base na classificação apresentada e com o objetivo de criar uma
metodologia com as práticas de gerenciamento de projetos de software mais viáveis à empresa
alvo de estudo, foram realizadas as seguintes etapas metodológicas:
a) Levantamento bibliográfico: Levantamento bibliográfico baseado em livros
especializados, pesquisas na Internet, artigos de revistas especializadas, trabalhos
4 Uma Intranet é uma plataforma de rede independente, conectando os membros de uma organização, utilizando protocolos padrões de internet.
34
acadêmicos, apresentando metodologias, modelos de maturidade, guias, processos e boas
práticas de gerenciamento de projetos de software. O foco deste tópico é a apresentação de
conceitos básicos, para propiciar embasamento mínimo necessário para a criação de uma
metodologia, viabilizando o entendimento de onde e como a metodologia proposta poderá
ser inserida.
b) Levantamento do atual contexto de gerenciamento de projetos de software: Para viabilizar
a criação de uma metodologia de gerenciamento de projetos de software, faz-se necessária
a contextualização das atuais práticas adotadas pela empresa alvo de estudo, para que sirva
como base na elaboração da nova metodologia. Esse levantamento foi realizado por meio
da observação direta, bem como a pesquisa documental.
c) Proposta de metodologia: A partir do conhecimento prévio sustentado pelo levantamento
bibliográfico e pelo levantamento do contexto atual, será elaborada e apresentada uma
metodologia de gerenciamento de projetos de software para a empresa alvo de estudo de
forma descritiva, com definições acerca do que a metodologia propõe.
35
4. ESTUDO DE CASO
Neste capítulo será realizada a apresentação da empresa estudada, sendo
apresentado seu nicho de mercado e as soluções que oferece ao mesmo, seguido da
contextualização de dados de crescimento. Em seguida, serão citadas informações de sua
estrutura organizacional e seu planejamento estratégico, com o intuito de prover uma maior
visão de sua estrutura.
Por fim, serão apresentados o diagnóstico do ambiente interno, ou seja, os
processos de trabalho (com foco no desenvolvimento de software), as práticas de
gerenciamento de projetos utilizadas, além dos problemas que a empresa enfrentada
atualmente na concepção de seus projetos.
As informações obtidas neste estudo de caso, servirão como base para a criação de
uma metodologia mais adequada para a empresa alvo de estudo, que é apresentada no capítulo
5.
4.1. Apresentação da Empresa
A empresa alvo de estudo fui fundada em maio de 2002, em Florianópolis (SC) e é
especializada em desenvolvimento e comércio de sistemas para o setor de radiologia e de
diagnóstico por imagem.
Especializada em soluções PACS (Picture Archiving and Communication
Systems), um avançado conjunto de softwares que permitem realizar captura, armazenamento,
impressão, distribuição, visualização e manipulação de exames de diagnóstico por imagem,
fornecendo soluções personalizadas e adaptadas ao mercado nacional, com investimentos
viáveis e adequados à realidade do sistema de saúde brasileiro.
36
Seus produtos destinam-se a médicos radiologistas, clínicas especializadas de
diagnóstico por imagem e hospitais, sejam eles públicos ou privados. Suas soluções estão
presentes em vinte e oito bases espalhados por dez estados Brasileiros.
Com relação a seu crescimento, comparando o exercício do ano de 2006 para
2007, a empresa triplicou seu faturamento (de R$ 593.000,00 para R$ 1.600.000,00) Maia
(2007). Neste exercício, o número de hospitais e clínicas especializadas aumentou de 15 para
27, e para suprir esta nova demanda, o número de funcionários passou de 17 para 23.
Atualmente a empresa alvo de estudo tem como meta aumentar seu faturamento
para R$ 2.500.000,00, consta atualmente com 35 clientes um quadro de 33 funcionários.
Conforme citado anteriormente, seu negócio está voltado ao fornecimento de um
conjunto de softwares para a manipulação de imagens médicas, que por conseqüência gera
serviços (de vendas, implantação, treinamento e suporte), indicando que sua receita esta
diretamente ligada à venda dos softwares produzidos e os serviços que gera, denotando a
importância do gerenciamento de projetos de software para a empresa.
4.2. Planejamento estratégico da empresa
O planejamento estratégico trata-se de um plano onde é formalizado o caminho
que a empresa optou com o objetivo de torná-la competitiva, garantindo sua continuidade.
Neste plano, estão definidas atividades e competências relacionadas entre si visando à entrega
de valor de maneira diferenciada aos interessados.
O planejamento estratégico da empresa alvo de estudo, será descrito a seguir:
37
4.2.1. Negócio
A empresa é especializada no desenvolvimento de soluções voltadas para a gestão
de imagens médicas em hospitais e clínicas de imagem. O produto desenvolvido é o sistema
de PACS (Picture Archiving and Communication Systems), um avançado conjunto de
softwares que permitem realizar aquisição, armazenamento, distribuição, visualização e
manipulação de exames de diagnóstico por imagem.
4.2.2. Missão
A missão da empresa é o desenvolvimento de tecnologia e a prestação de serviços
para clínicas e hospitais da área de diagnóstico por imagens médicas na América do Sul,
visando otimizar os recursos dos clientes por meio de uma solução integrada de software,
tendo como benefício social a melhoria do atendimento a comunidade.
4.2.3. Visão
Tornar-se referência na área de desenvolvimento de softwares para diagnóstico por
imagem nos países em desenvolvimento.
4.2.4. Objetivo
O objetivo principal da empresa é o desenvolvimento de tecnologias inovadoras e
diferenciadas, com alto valor agregado e facilidade de uso, a fim de disponibilizar soluções
capazes de garantir maior agilidade no fluxo de trabalho dos médicos e maior precisão
diagnóstica.
38
4.2.5. Iniciativas
A empresa está em fase de registro e certificação de marcas e produtos na
ANVISA (Agência Nacional de vigilância Sanitária), órgão que rege o setor brasileiro de
saúde.
Com o intuito de aumentar diretrizes e reconhecimento da qualidade dos seus
produtos e processos, ela está em busca da constante melhoria de seus processos produtivos
(além da busca por certificações), baseando-se em padrões e boas práticas recomendadas pelo
PMBOK, MPS.BR (Melhoria do Processo do Software Brasileiro) e Agille Aliance.
4.3. Estrutura organizacional
Encontram-se na literatura três denominações básicas para os tipos de estruturas
organizacionais: Funcional, Matricial e Projetizada.
Segundo Vargas (2003) estruturas funcionais são caracterizadas pela utilização de
uma mesma linha de controle para operações regulares e projetos. O mesmo autor cita ainda
que neste tipo de estrutura os projetos tem importância reduzida frente as atividades
consideradas na organização.
Conforme Valeriano (2001), estruturas projetizadas são caracterizadas por formar
equipes temporárias de trabalho chefiadas por um Gerente de Projetos, exclusivamente
dedicadas à execução de um projeto. Vargas (2003) cita que em organizações estruturadas
desta forma os gerentes têm autonomia total assumindo também o controle funcional dos
envolvidos.
A estrutura matricial, segundo Valeriano (2001) é caracterizada pela combinação
de benefícios das estruturas funcional e projetizada. O mesmo autor cita ainda que nesta
estrutura existe a sobreposição de uma estrutura de projetos à uma estrutura funcional.
39
Vargas (2003) subdivide as organizações matriciais em fracas, equilibradas ou
moderadas e fortes.
Em uma organização matricial fraca, cita que existe a alocação de recursos para
condução de projetos com pouco reconhecimento de autoridade formal sobre as atividades e
os recursos, destacando que nestas organizações a importância dada aos projetos ainda é
limitada.
Em estruturas organizacionais consideradas moderadas, há uma dedicação integral
do Gerente de Projetos aos projetos, possuindo ainda uma autonomia comparável a de um
gerente funcional.
Em estruturas matriciais consideradas fortes, a autonomia do Gerente de Projetos é
maior que a de gerentes funcionais, pois os projetos tendem a ser estratégicos para a empresa.
A figura 6 ilustra o organograma da empresa alvo de estudo. Nela pode-se
constatar a ligação direta das diferentes áreas da empresa com a diretoria, onde a
descentralização de autoridade está dividida entre Gerências, Coordenadorias e Lideranças de
equipe, não existindo a figura do Gerente de Projetos.
Figura 6 – Estrutura organizacional da empresa alvo de estudo
40
Com exceção do setor de desenvolvimento de software, os demais setores da
empresa são considerados como funcionais, uma vez que são agrupadas na mesma unidade e
realizam atividades dentro de uma mesma área técnica.
O desenvolvimento é caracterizado por uma estrutura por projetos, como ilustra a
figura 7, onde os recursos estão agrupados de acordo com o(s) projeto(s) com o(s) qual(is)
estão envolvidos. Neste caso, o projeto funciona como um departamento temporário, cujas
lideranças de equipe e desenvolvedores podem trabalhar em mais de um projeto
simultaneamente.
Figura 7 – Estrutura organizacional do setor de desenvolvimento da empresa alvo de estudo
As duas formas de departamentalização da empresa caracterizam-na como uma
estrutura tipicamente matricial, haja vista que existe uma combinação de dois tipos de
departamentalização, uma funcional e outra por projetos.
A empresa pode ser considerada uma estrutura matricial fraca, pois não existe hoje
a figura do Gerente de Projetos, sendo os projetos conduzidos pelo Diretor de Tecnologia,
Gerências, Coordenadorias e Lideranças de Equipe.
41
4.4. Diagnóstico do ambiente interno
4.4.1. Contextualização dos projetos da empresa
A empresa alvo de estudo possui um conjunto de softwares desenvolvidos em 2
linguagens de programação (Java e C++) para viabilizar sua solução PACS. No Setor de
Desenvolvimento, cada software é considerado como um projeto.
Atualmente são 13 os projetos ativos na empresa, que juntos ou separadamente
compõe 8 produtos. Existe uma forte dependência entre os projetos, mesmo nos casos que os
projetos envolvidos em um produto específico sejam concebidos em linguagens diferentes.
4.4.2. Contextualização das estruturas da empresa e seus papéis
Conforme citado anteriormente a empresa alvo de estudo tem seu foco no
desenvolvimento de softwares para diagnóstico de imagens médicas. Estes softwares por sua
vez geram produtos e serviços que são os insumos que o setor Comercial, Marketing,
Qualidade, Implantação e Suporte utilizam para o desenvolvimento de suas atividades. Estes
setores serão ora denominados de stakeholders do setor de desenvolvimento de software.
4.4.3. Processo de desenvolvimento de software
O processo e desenvolvimento de software da empresa alvo de estudo consiste das
seguintes etapas:
42
4.4.4. Levantamento de requisitos
Esta atividade é efetuada pelos diversos setores da empresa como a Gerência de
Produto, o Setor Comercial, o Setor de Implantação e o Setor de Suporte.
A Gerência de Produto efetua pesquisa de mercado para avaliar diferencial entre
ferramentas para o mesmo fim, solicitando funcionalidades de equiparação com produtos de
empresas concorrentes.
O Setor Comercial efetua consultas e solicitações para o atendimento de exigências
contratuais de novos clientes. O Setor de Implantação após efetuar suas atividades
(implantação e treinamento), encaminha as solicitações de melhorias (efetuadas pelos clientes
durante suas atividades).
O Setor de Suporte solicita melhorias na medida em que as mesmas são reportadas
ao setor. Estes requisitos são reportados ao Setor de Desenvolvimento, onde são cadastrados
(por projeto) em um software específico para o cadastramento de requisitos, denominado
JIRA (ATLASIAN, 2008).
4.4.4.1. Identificação de erros e não-conformidades
Esta atividade é executada pelos mesmos envolvidos no levantamento de
requisitos, com a participação adicional do Setor de Controle de Qualidade. Suas ocorrências
também são cadastradas no software JIRA (ATLASIAN, 2008).
4.4.4.2. Análise de requisitos, erros e não-conformidades
Uma vez registradas as ocorrências de requisitos, erros e não-conformidades é
efetuado o processo de análise de características da ocorrência, análise de impactos e análise
de riscos que envolvem a mesma.
43
Ocorrências podem ser desmembradas em mais de um outro projeto, uma vez que
pode englobar uma funcionalidade específica de um projeto.
Esta análise geralmente ocorre em breves reuniões, entre o Diretor de Tecnologia e
o(s) envolvido(s) no projeto que é afetado pela ocorrência. Nesta análise também é efetuada
definição prévia de qual versão do projeto a mesma será implementada ou solucionada.
4.4.4.3. Definição de versões
A definição de datas e de que quais itens (seja a implementação requisitos ou a
resolução de erros) farão parte da próxima versão de cada software fica a cargo do Diretor de
Tecnologia e do Líder da Equipe do projeto envolvida.
A empresa atualmente adota a postura de desenvolvimento de releases curtos (de
aproximadamente 30 dias), sob a justificativa de manter os clientes constantemente
atualizados.
Durante a pesquisa observou-se que dependendo da criticidade da solicitação, a
geração de uma versão pode ocorrer no mesmo dia da solicitação.
4.4.4.4. Implementação
Os desenvolvedores são encarregados de consultar diariamente o software JIRA
(ATLASIAN, 2008), para verificação e implementação das pendências que estão sob sua
responsabilidade.
44
4.4.4.5. Controle de Qualidade
Na medida em que são efetuadas implementações, o Setor de Qualidade efetua
testes incrementais nas versões "parciais" de cada projeto.
4.4.4.6. Liberação de versões
Finalizada a etapa de implementações e de controle de qualidade, é efetuada a
gerência de configuração das versões produzidas.
Esta atividade consiste de um conjunto de atividades de apoio ao desenvolvimento
no controle de mudanças efetuadas nos softwares. É nela onde são gerados documentos de
atualização que serão encaminhados aos setores de Suporte e Implantação para atualização e
implantação de novas versões de softwares em clientes.
4.4.4.7. Pesquisa e Desenvolvimento
Em virtude da necessidade de estar constantemente inovando seus produtos, a
empresa alvo de estudo tem investido em pesquisa e desenvolvimento, buscando fomento
junto a instituições como o FINEP (Financiadora de Estudos e Projetos) e o CNPq (Conselho
Nacional de Desenvolvimento Científico e Tecnológico). Existe a perspectiva criação de
novos projetos na empresa, caso estes fomentos sejam concretizados.
4.4.4.8. Práticas de Gerenciamento de Projetos
Durante o estudo de caso, pode-se observar que a empresa alvo de estudo não
aplica práticas específicas de Gerenciamento de Projetos em seu cotidiano. A própria
inexistência do papel de Gerente de Projetos denota este fato. Existem atividades
45
organizacionais que merecem destaque, mas que não possuem vínculos ou referências
específicas com práticas de Gerenciamento de Projetos, que são:
a) Definição de processos da ANVISA (Para todos os setores da organização).
b) Gerência de Configuração.
c) Análise de Riscos simplificada (Sem formalização, nem plano de ações corretivas).
4.4.5. Dificuldades encontradas
Em decorrência do crescimento da empresa (apresentado em item anterior neste
capítulo), ocorreram mudanças com relação ao número e ao perfil de clientes. Some-se a este
fato ocorrências como: Necessidade de criação de inovações como diferencial competitivo,
necessidade de atualizações tecnológicas, necessidade de estabilização de versões dos 3
principais produtos da empresa e treinamento de novos recursos.
Mesmo com o aumento do quadro de funcionários (nos diferentes setores) o
processo de desenvolvimento de software existente não está adaptado a esta nova realidade, o
que ocasionou uma queda gradativa na capacidade de produção do setor de desenvolvimento.
Mesmo efetuando esforços extras como tentativa de suprir a nova demanda, constatou-se uma
queda na qualidade dos produtos e serviços gerados.
Em levantamento efetuado com os demais setores da empresa, foram constatados
os seguintes problemas em relação ao processo de desenvolvimento de software atual:
1) Geração de novas versões em períodos curtos (menores do que 30 dias):
a) Dificulta a atualização de clientes por parte do Setor de Suporte (apenas parte dos
clientes recebem atualização devido à sua quantidade).
b) Dificulta a atualização e divulgação de manuais por parte do Setor de Implantação.
c) Dificulta a especificação de prazos aos clientes por parte dos setores Comercial,
Implantação e Suporte.
46
d) Dificulta a divulgação direcionada (a médicos radiologistas e gerentes de TI dos
clientes) de novas implementações e ajustes.
e) Dificulta o controle de qualidade, devido ao número de projetos a serem testados
(sendo testadas apenas os incrementos / alterações efetuadas e não todo o aplicativo
novamente).
2) Geração de versões por projeto e não do PACS como um produto:
a) Dificulta o entendimento das dependências entre projetos por parte dos Setores de
Implantação e Suporte.
Durante o levantamento de informações, ficaram evidenciadas falhas de
comunicação entre os setores no alinhamento de suas expectativas.
47
5. PROPOSTA DE METOLOGIA
Uma vez efetuada a revisão bibliográfica, na qual foram apresentados conceitos de
metodologias de Gerenciamento de Projetos e efetuado o estudo de caso das atuais práticas
que a empresa alvo de estudo utiliza, torna-se possível identificar e propor uma maneira
prática de inserir práticas de Gerência de Projetos à empresa alvo de estudo.
A proposta é composta das seguintes fases:
a) Criação de um novo processo de desenvolvimento de software.
b) Apresentação do novo processo de desenvolvimento de software.
c) Alinhamento de processos internos dos stakeholders com o novo processo de
desenvolvimento.
d) Formalização de processos.
e) Sugestão de práticas de gerenciamento de projetos.
5.1. Novo processo de desenvolvimento de software
Conforme observado no estudo de caso, o processo atual de desenvolvimento de
software da empresa alvo de estudo não suporta a nova demanda ocasionada pelo crescimento
da empresa.
É essencial que o mesmo seja re-adequado para não apenas suportar a nova
demanda, mas estar alinhado com os demais setores, que utilizam o produto dos projetos do
setor de desenvolvimento como insumos para suas atividades.
Mesmo não sendo este o foco deste estudo de caso (a re-adequação do processo de
desenvolvimento de software), é importante apresentá-lo, pois é a partir do mesmo que será
sugerida a inclusão gradativa de práticas de Gerenciamento de Projetos na empresa alvo de
estudo, servindo como meio.
48
O novo processo de software sugerido trata de uma mudança conceitual, pois como
os projetos que compõe o PACS estão fortemente interligados e cada vez mais com relações
de dependências entre os mesmos, sugere-se que não mais sejam efetuadas liberações de
versões de softwares, mas sim, versões do PACS. Ao conjunto destas versões dos projetos
sugere-se a definição de um nome específico, seguido de um controle de versões numérico
(Ex. PACS 1.0).
O novo processo sugerido é dividido em 3 etapas, descritas a seguir:
5.1.1. Primeira Etapa
Sugere-se que esta etapa tenha a duração de trinta dias e seja composta de dois
processos, que são: o Processo de Iniciação de Novo Ciclo de Desenvolvimento e o Processo
de Testes Finais do Ciclo de Desenvolvimento Anterior.
Sugere-se também que estes processos ocorram de forma paralela.
5.1.1.1. Iniciação de Novo Ciclo de Desenvolvimento
Neste processo, objetiva-se que o setor de desenvolvimento de software reúna-se
com todos os seus stakeholders para a definição de quais funcionalidades irão compor cada
software que compõe o PACS.
Sugerem-se duas reuniões durante este processo.
Sobre a primeira reunião de cada projeto, sugere-se que ocorra nos dez primeiros
dias desta etapa. É nela onde deverão ser apresentadas as necessidades de cada stakeholder,
como descrito a seguir:
a) Equipe de desenvolvimento do projeto: Equipe que será responsável pela análise e
implementação das solicitações.
49
b) Líderes de Equipe de projetos dependentes: Caso o projeto cujas funcionalidades a serem
incorporadas no ciclo de desenvolvimento dependam de um outro projeto, sugere-se a
participação das lideranças de equipe dos mesmos para alinhamento de expectativas.
c) Gerente de Produto: Para solicitações de diferenciais de produto, efetuados por intermédio
de pesquisa mercadológica.
d) Coordenadoria de Implantação: Para solicitações de clientes cuja implantação e
treinamento já ocorreram.
e) Gerente de Suporte: Para as solicitações de correções de erros, reportadas por clientes.
f) Gerente Comercial: Para incorporar solicitações contratuais de clientes novos.
g) Gerente Financeiro: Caso haja a necessidade de ser efetuada alguma aquisição para o
processo de desenvolvimento, a presença deste gerente se faz necessária para que possa
efetuar previsão orçamentária.
h) Coordenadoria de Qualidade: Para que possa mapear todas as necessidades, solucionar
dúvidas sobre os objetivos das mesmas e assim traçar plano global de testes.
i) Gerente de Marketing: Para verificar as necessidades de insumos por parte do setor de
Desenvolvimento, como por exemplo a produção de ícones.
Uma vez apresentadas as necessidades, serão efetuadas em conjunto análises de
viabilidade, análise de riscos, impacto sobre outros projetos, dentre outras considerações
importantes.
Objetiva-se que ao final desta reunião, tanto desenvolvedores como os
stakeholders já tenham definido o escopo prévio do que irá compor a versão do projeto em
análise (com todos os requisitos, devidamente cadastrados no software JIRA (ATLASSIAN,
2008)), alinhando assim expectativas entre as partes interessadas.
50
Sobre a segunda reunião de cada projeto, sugere-se que seja efetuada nos últimos
dez dias desta etapa. É nela onde a equipe técnica de desenvolvimento irá efetuar definições
de arquitetura, modelagem de objetos, modelagem de dados, definições de tarefas por recurso.
5.1.1.2. Testes Finais do Ciclo de Desenvolvimento anterior
Conforme citado anteriormente, trata-se de processo paralelo ao de iniciação de
ciclo de desenvolvimento.
Uma vez que a equipe de desenvolvimento não estará em continuamente reunida
para a definição de versões, sugere-se que em paralelo a estas atividades, sejam efetuados
ajustes nas versões do ciclo de desenvolvimento anterior, ou seja, a que a equipe de
desenvolvimento esteja focada na estabilização dos aplicativos que compõe a versão anterior
do PACS.
Para viabilizar a estabilização de versões de software que compõe o PACS, sugere-
se que sejam liberadas versões RC (Release Candidate5) em ambiente de produção de um
número reduzido de clientes.
Para os clientes dispostos a testarem as novidades do PACS, podem ser concedidas
algumas vantagens contratuais, como atualizações gratuitas, por exemplo.
5.1.2. Segunda Etapa
Trata-se da etapa a ser considerada como o Desenvolvimento do Ciclo, onde serão
implementadas as funcionalidades definidas nos escopos dos projetos durante a 1ª etapa.
Sugere-se que esta etapa tenha a duração de quarenta e cinco dias e que nela sejam
definidos marcos dentro dos projetos, para que na medida em que forem alcançados, sejam
5 Refere-se à liberação de uma versão com potencial para se tornar o produto final. Nesta fase, o produto apresenta todas as funcionalidades
concebidas sem a presença de erros impeditivos;
51
geradas versões parciais a serem encaminhadas ao Setor de Qualidade para a efetivação de
testes. Sugere-se também que o Setor de Marketing produza e disponibilize os insumos
solicitados pelo Setor de Desenvolvimento, como por exemplo, a criação de ícones.
Cabe nesta etapa ainda, como sugestão, a atualização de clientes com versões
fechadas de aplicativos de ciclo anterior, além de seus manuais e materiais de divulgação, pelo
Setor de Suporte.
5.1.3. Terceira Etapa
Trata-se da etapa a ser considerada como Testes Iniciais do Ciclo. Sugere-se que
esta etapa tenha a duração de 15 dias.
Nesta etapa as versões implementadas são liberadas para testes completos para o
Setor de Controle de Qualidade. Nela o Setor de Desenvolvimento deve estar focado no ajuste
de erros e não conformidades encontradas durante os testes.
Sugere-se também que na medida em que forem finalizados os ajustes citados
acima, sejam efetuadas as seguintes atividades pelo Setor de Desenvolvimento, para que os
demais setores possam dar seqüência à suas atividades:
a) Encaminhamento de informação ao setor de implantação para atualização de manuais.
b) Encaminhamento de informações ao setor de marketing para a divulgação de material de
divulgação.
c) Efetuar de treinamentos de novas funcionalidades com os Setores de Suporte, Implantação
e Comercial.
52
5.2. Apresentação do novo processo de desenvolvimento
A apresentação do novo processo de desenvolvimento aos demais setores da
empresa (stakeholders) tem o intuito de diminuir o impacto causado, por se tratar de uma
mudança conceitual na concepção de projetos e geração de produtos e serviços.
A figura 8 ilustra o novo processo de desenvolvimento proposto.
Figura 8 – Novo processo de desenvolvimento proposto.
Objetiva-se também nesta fase obter desde o princípio a participação de todos os
envolvidos, seja avaliando o processo, questionando motivações, sugerindo mudanças,
enriquecendo-o, dando início à um processo de desenvolvimento colaborativo entre setor de
desenvolvimento e seus stakeholders, fazendo com que todos sintam-se parte integrante do
processo.
53
Como toda mudança tende a gerar certa resistência inicial, cabe apresentar aos
envolvidos as vantagens do novo processo, no que diz respeito à produtividade. Basicamente
elas estão relacionadas ao ganho de tempo na execução de atividades, descritas por setor a
seguir:
1) Setor de Controle de Qualidade:
a) Intervalo de tempo maior para efetuação de testes na empresa.
b) Possibilidade de execução de testes em ambiente de produção na 1ª Etapa.
2) Setor de Suporte:
a) Intervalo de 90 dias para a atualização de clientes.
b) Intervalo de tempo maior para treinamento interno de novas funcionalidades.
c) Informar melhorias e correções aos clientes com base em prazos mais seguros.
3) Setor de Marketing:
a) Intervalo de tempo maior para a geração e divulgação de material de apresentação de
melhorias e novas funcionalidades (o popular “o que há de novo?”).
4) Setor de Implantação:
a) Intervalo de tempo maior para incremento e atualização de manuais.
b) Intervalo de tempo maior para preparação de treinamentos.
c) Intervalo de tempo maior para agendar implantações em novos clientes.
d) Informar melhorias e correções aos clientes com base em prazos mais seguros.
5) Setor Comercial:
a) Possibilidade de prospecção antecipada (e com prazo de entrega seguro) de novas
funcionalidades.
b) Informar melhorias e correções aos clientes com base em prazos mais plausíveis.
6) Setor de Desenvolvimento:
a) Maior controle em seu processo produtivo.
54
b) Alinhamento de expectativas com os demais setores da empresa.
5.3. Alinhamento de Processos
Uma vez apresentado, debatido, melhorado e aceito o novo processo de
desenvolvimento de software, sugere-se que seja efetuado um alinhamento do mesmo com os
processos internos dos stakeholders.
Este alinhamento auxiliará na obtenção de respostas a perguntas como:
a) Em que etapa o desenvolvimento de software poderá solicitar insumos ao setor de
Marketing (por exemplo, a confecção de ícones)?
b) Caso hajam ocorrências emergenciais de suporte durante a 2ª etapa, como inseri-las no
ciclo em andamento?
c) Cabe na segunda reunião da 1ª etapa, alguma nova solicitação de algum stakeholder que
tenha surgido desde a primeira reunião?
A identificação de informações úteis entre os processos, como necessidades,
exceções, dados de entradas e saídas, viabiliza não somente a integração entre ambos, mas a
possibilidade de serem monitorados e melhorados continuamente.
5.4. Formalização de Processos
Com os processos (o de desenvolvimento de software e os dos stakeholders)
alinhados, sugere-se a formalização dos mesmos.
Como a empresa alvo de estudo já está em processo de registro com a ANVISA, é
importante que os novos processos sejam formalizados perante o órgão conforme suas
diretrizes.
55
Convém citar que a formalização de processos auxilia a divulgação e o
conhecimento de todos para toda a organização.
5.5. Práticas de Sugeridas
Visando a criação da cultura de Gerenciamento de Projetos na empresa alvo de
estudo, levando-se em consideração sua situação atual e seu planejamento estratégico,
sugerem-se as seguintes práticas a serem inseridas de forma gradativa em seu contexto:
a) Criação do papel de Gerente de Projetos: Conforme pode ser observado na estrutura
organizacional da empresa estudada, não existe o papel do Gerente de Projetos. Sugere-se
a criação deste papel, para que possa desempenhar atividades necessárias, com foco inicial
na concepção, análise e melhoria de processos, servindo de elo entre o Setor de
Desenvolvimento e os stakeholders, agindo como facilitador.
b) Passar mais tempo com os stakeholders: Citado como regra do XPM, tende a viabilizar
uma visão direcionada (APM), sobre as reais expectativas e necessidades dos mesmos.
c) Participação ativa de stakeholders na concepção de projetos e produtos: Citado na revisão
bibliográfica como prática do XPM, esta sugestão visa tornar o processo de
desenvolvimento de software aberto e colaborativo, propiciando transparência, alinhando
a produção de software aos seus objetivos reais.
d) Encerramento de ciclos: Sugere-se que ao final de cada ciclo de desenvolvimento de
software (apresentado no capítulo Proposta de Metodologia) sejam efetuadas reuniões do
Setor de Desenvolvimento com seus stakeholders para que possa ser efetuado o
encerramento do ciclo de desenvolvimento, onde sugere-se que sejam expostos e
formalizados os erros e acertos do mesmo (popular “lições aprendidas” conforme
PMBOK).
56
e) Melhoria contínua nos processos: Citada em praticamente todas as referências da revisão
bibliográfica, a criação de práticas para inspeção e adaptação de processos, propiciando
uma reflexão regular sobre seus sucessos e falhas auxilia na obtenção da maturidade
organizacional.
f) Desenvolver e implantar o Gerenciamento da Comunicação: Conforme observado no
estudo de caso, existem falhas de comunicação entre o Setor de Desenvolvimento e seus
stakeholders. Visando sanar este problema, sugere-se a definição de processos que
viabilizem a disseminação adequada das informações entre ambos, assegurando a geração,
coleta, distribuição, armazenamento e apresentação das informações às partes interessadas.
g) Desenvolver e implantar o Gerenciamento da Qualidade: Uma vez que o novo processo de
desenvolvimento sugerido tem duas de suas etapas voltadas para testes, sejam eles
executados na própria empresa, ou em ambiente de produção de um número reduzido de
clientes, sugere-se a criação de processos para a certificação de que os softwares estarão
sendo disponibilizados em conformidade com as expectativas iniciais dos clientes finais.
h) Criação de metodologia de medição do novo processo de desenvolvimento de software:
Visa à obtenção de informações acerca da capacidade produtiva do Setor de
Desenvolvimento, com o intuito de disponibilizar informações para a tomada de decisões
da diretoria quanto à incorporação de novos projetos ao portifólio da empresa.
i) Criar processos de gestão de Conhecimento e Inovação: Com o intuito de formalizar o
conhecimento tácito adquirido pelos recursos da empresa, visando facilitar a disseminação
de conhecimento entre as diferentes áreas da empresa além da rápida adaptação de novos
recursos.
57
6. CONCLUSÕES
No decorrer deste estudo foram sugeridas boas práticas de gerenciamento de
projetos com o intuito de introduzir de maneira gradativa o gerenciamento de projetos na
empresa alvo de estudo.
A revisão bibliográfica propiciou o embasamento das metodologias de
gerenciamento de projetos mais difundidas, de forma sucinta, uma vez que não era seu
objetivo o aprofundamento nas mesmas, para que a partir deste embasamento fosse possível a
seleção ou adaptação das práticas que compõe a metodologia proposta.
A partir das práticas inseridas na metodologia, desde que seguidas, tem-se
condições gradativamente conduzir projetos de uma maneira mais padronizada e organizada e
ainda de efetuar um processo de melhoria contínua, sempre alinhado à realidade e ao
planejamento estratégico da empresa, viabilizando uma fácil adequação à metodologias mais
robustas, caso haja necessidade e interesse.
Como resultado a metodologia proposta cumpre seus objetivos específicos, ou seja,
efetua um estudo da empresa alvo, tomando conhecimento de sua estrutura, seus objetivos,
seus processos e suas dificuldades. Com base nestas informações, efetua a análise no intuito
de indicar e adaptar práticas baseadas na revisão bibliográfica, levando em consideração o
momento atual da empresa, como seu planejamento estratégico.
Por fim, espera-se que este trabalho possa agregar valor à empresa alvo de estudo,
servindo como base na inclusão da cultura de gerenciamento de projetos na mesma,
melhorando o índice de sucesso em seus projetos, aumentando a satisfação dos stakeholders
internos e clientes por meio da melhora na qualidade dos serviços entregues, além de servir
como base a outros trabalhos acadêmicos.
58
6.1. Sugestões para trabalhos futuros
Por se tratar de um estudo de caso, que propõe uma metodologia, este trabalho
apresenta uma sugestão para trabalhos futuros, descrito a seguir:
a) Aumento da maturidade de Gerenciamento de Projetos: Uma vez adotada e sendo seguida
a metodologia de gerenciamento de projetos proposta neste trabalho, sugere-se que seja
aumentado o nível de maturidade do mesmo, sendo adicionados novos processos,
tornando-a mais robusta, e que estejam coerentes com os objetivos e planejamento
estratégico da empresa.
59
REFERÊNCIAS
ATLASSIAN [On-line]. JIRA – Bug and Issue Tracker. Disponível em <http://www.atlassian.com/software/jira/ >. Acessado em: 07/2008. CASTOR, Belmiro Valverde Jobin. Gestão de Projetos nas pequenas Empresas: A busca da compatibilidade. Revista Mundo PM, n. 18, p. 07, 2007. DIAS, Marisa V. B. et al. Titulo do artigo. AGILE PROJECT MANAGEMENT: Um Novo Enfoque para o Gerenciamento de Projetos de Desenvolvimento de Sistemas de Tecnologia de Informação. São Paulo: Universidade de São Paulo – USP. 6f, 2006. FILHO, Edes G. C. et al. Padrões e Métodos Ágeis: Agilidade no processo de desenvolvimento de software. São Carlos: Universidade Federal de São Carlos – Departamento de Computação, 2005. GIL, Antonio Carlos. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2002.
MAGALHÃES, Ana L. et al. Titulo do artigo. Revista ProQualiti: Qualidade na Produção de Software.Núcleo de Estudos Avançados em Engenharia e Qualidade de Software. Lavras: Universidade Federal de Lavras - UFLA. n. 1, p. 34, 2005. MAIA, Viviane. Crânios e ossos via internet. Revista Pequenas Empresas e Grandes Negócios, n. 227, p.50, 2007. SOFTEX. Associação para Promoção da Excelência do Software Brasileiro. MPS.BR: Guia de Aquisição, versão 1.2,jun. 2007. Disponível em: <www.softex.br>. Acesso em: 06/2008 MÜLLER, Elias. Métodos Ágeis: Uma Aplicação do Scrum no Simuplan. Passo Fundo, 2004, 92 f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) Universidade de Passo Fundo, Passo Fundo, 2004. NASCIMENTO, Gustavo V. et al. ProAgil: Um modelo para a implantação de processo de desenvolvimento ágil. São Paulo: Universidade de São Paulo (USP) - Departamento de Ciências da Computação, 2007. PEREIRA, Paulo. et al. Entendendo Scrum para Gerenciar Projetos de Forma Ágil. Revista mundo PM, Curitiba, n. 14, p. 60, 2007. PMBOK - A guide to the project management body of knowledge. Project Management Istitute, 2004. PONS, Roberto H. N. et al. Gerenciamento de Múltiplos Projetos. Rio de Janeiro, 2004, 91 f. Trabalho de Conclusão de Curso (MBA em Gerência de Projetos) Fundação Getúlio Vargas, Rio de Janeiro, 2004. VERGARA, Sylvia Constant. Projetos e relatórios de pesquisa em administração. 5. ed. São Paulo: Atlas, 2004.
60
VALERIANO, Dalton L. Gerenciamento Estratégico e Administração por Projetos. São Paulo: Makron Books, 2001. VARGAS, Ricardo V. Gerenciamento de Projetos: Estabelecendo diferenciais competitivos. 5ª ed. Rio de Janeiro: Brasport, 2003. YOSHIMA, Rodrigo. Entregue Software Funcionando: Gerenciamento de Projetos Ágil. Revista Mundo Java, Curitiba, n. 26, p. 10, 2007. ZANONI, Roberto. Proposta de um Modelo de Gerência de Projeto de Software. Porto Alegre, 2001, 47 p. Trabalho Individual - Programa de Pós-Graduação em Ciência da Computação Curso de Mestrado, Pontifícia Universidade Católica do Rio Grande do Sul. Faculdade de Informática. WEBER, Kival. et al. Titulo do artigo. Melhoria de Processo do Software Brasileiro (MPS.BR): Um Programa Mobilizador. SOFTEX – Associação para Promoção da Excelência do Software Brasileiro. 10f, 2006