ads:
FUNDAÇÃO EDSON QUEIROZ
UNIVERSIDADE DE FORTALEZA - UNIFOR
MESTRADO EM INFORMÁTICA APLICADA
Abordagem para Análise e Resolução de Causas de
Problemas Aplicando Multicritério
Francisca Márcia Gomes Sampaio Gonçalves
Fortaleza – CE
Dezembro de 2008
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
ii
FUNDAÇÃO EDSON QUEIROZ
UNIVERSIDADE DE FORTALEZA - UNIFOR
MESTRADO EM INFORMÁTICA APLICADA
Abordagem para Análise e Resolução de Causas de
Problemas Aplicando Multicritério
Francisca Márcia Gomes Sampaio Gonçalves
DISSERTAÇÃO APRESENTADA AO CURSO DE MESTRADO EM
INFORMÁTICA APLICADA DA UNIVERSIDADE DE
FORTALEZA COMO PARTE DOS REQUISITOS NECESSÁRIOS
PARA A OBTENÇÃO DO TÍTULO DE MESTRE EM
INFORMÁTICA.
Orientador: Plácido Rogério Pinheiro
Co-orientador: Adriano Bessa Albuquerque
Fortaleza – CE
Dezembro de 2008
ads:
iii
Francisca Márcia Gomes Sampaio Gonçalves
Abordagem para Análise e Resolução de Causas de
Problemas Aplicando Multicritério
Data de Aprovação: ____/____/______
Banca Examinadora:
________________________________________________________
Prof. Plácido Rogério Pinheiro, D. Sc.
(Prof. Orientador – UNIFOR)
________________________________________________________
Prof. Adriano Bessa Albuquerque, D. Sc.
(Prof. Co-orientador – UNIFOR)
________________________________________________________
Profª. Carla Alessandra Lima Reis, D. Sc.
(Membro da Banca Examinadora – UFPA)
________________________________________________________
Prof. Antônio Clécio Fontelles Thomaz, D. Sc.
(Membro da Banca Examinadora – UECE)
iv
Aos meus pais Eudes e Estefânia, ao meu esposo
João Bosco, à minha filha Stephanie e à minha
irmã Patrícia que são o que tenho de mais precioso
na vida.
v
AGRADECIMENTOS
Gratitude takes three forms: a feeling in the heart,
an expression in words, and a giving in return.
JOHN WANAMAKER
A Deus, em primeiro lugar, por me abençoar, dando-me saúde, paz e energia,
elementos fundamentais para que eu conseguisse concluir esta dissertação.
À minha filha, Stephanie, que desde dentro de mim, foi a maior motivação e
inspiração para a conclusão deste trabalho.
Ao meu marido, João Bosco, pelo amor e companheirismo que tem me dedicado, e
por todas as alegrias que tem me proporcionado.
Aos meus pais, Estefânia e Eudes, que sempre acreditaram em mim e incentivaram
meus estudos, oferecendo-me a oportunidade que não tiveram e, à minha irmã Patrícia, pelo
carinho que sempre me dá.
Aos professores Plácido Rogério Pinheiro e Adriano Bessa Albuquerque pelas
inúmeras contribuições para a elaboração deste trabalho. À professora Ana Regina Rocha
pelo apoio e colaboração no momento em que fiquei sem um orientador. E, aos professores
Carla Alessandra Lima Reis e Antônio Clécio Fontelles Thomaz, pela valiosa contribuição
na análise e julgamento desta dissertação.
Aos meus amigos do mestrado Solange, Karol, David, Josy e Ana Lisse, pelos
muitos momentos compartilhados, pela amizade que semeamos e que hoje dá belos frutos.
Aos amigos do Instituto Atlântico e do Serpro pelas inúmeras contribuições e
incentivo: Carlo Giovano, Gabriela Telles, Carla Ilane, Daniele Farias e Carlos Augusto
Neiva.
À FUNCAP, pelo apoio financeiro durante boa parte do meu mestrado.
Ao professor Dr. Arnaldo Dias Belchior (in memorian), meu profundo
agradecimento e sincera homenagem por tudo que fez por mim e pelo que sou
profissionalmente. Você foi responsável por me mostrar e fazer com que eu me apaixonasse
vi
pela área de qualidade de software num momento em que eu estava desmotivada com o
curso que fazia. Foi um grande amigo, me aconselhando sempre que era preciso. Obrigada
mestre!
vii
Resumo da Dissertação apresentada ao Corpo Docente do Curso de Mestrado em
Informática Aplicada da Universidade de Fortaleza como parte dos requisitos necessários
para a obtenção do título de Mestre em Informática (M.Sc.)
Abordagem para Análise e Resolução de Causas de Problemas Aplicando
Multicritério
Francisca Márcia Gomes Sampaio Gonçalves
Dezembro / 2008
Orientador: Plácido Rogério Pinheiro
Co-orientador: Adriano Bessa Albuquerque
As metodologias de análise e resolução de problemas atualmente utilizadas variam
amplamente de acordo com a situação considerada. Por serem genéricas, a implementação
das abordagens existentes torna-se difícil quando se faz necessário adaptá-las a um
contexto específico, como em organizações de software. Quando se trata de problemas
complexos esse processo se torna ainda mais crítico. Desta forma, o uso de metodologias
multicritério de apoio à decisão como instrumento de apoio para o processo de análise das
causas de tais problemas se torna extremamente útil. Diante deste contexto, este trabalho
propõe uma abordagem que aplica a metodologia multicritério de apoio à decisão com o
intuito de auxiliar na análise das causas dos problemas no âmbito de organizações de
software, de forma a entender a relação entre as causas e os resultados, encontrar quais as
causas do problema que são mais relevantes, eliminar as causas relevantes do problema e,
conseqüentemente, melhorar os resultados.
Palavras-chave: Análise de Causas, Tomada de Decisão, Problemas Complexos,
Multicritério, PDCA, MCDA, MACBETH.
viii
Abstract of the dissertation presented to the board of faculties of the Master Program in
Applied Informatics at the University of Fortaleza, as partial fulfillment of the requirements
for the degree of Master of Computer Science (M.Sc.)
Approach for Analysis and Resolution of Problem Causes Applying
Multicriteria
Francisca Márcia Gomes Sampaio Gonçalves
December / 2008
Advisor:
Plácido Rogério Pinheiro
Co-advisor: Adriano Bessa Albuquerque
The methodologies used in analysis and resolution of problems vary widely according to
the considered situations. Due to the fact they are generic, the implementation of the
existent approaches is difficult when is necessary adapt it to a specific context, for
example, in software organizations. Besides, when the problems are complex, this process
becomes more critical. So, the use of multiple criteria approaches to support decision-
making, specially, the causal analysis process is extremely useful. In face of this context,
this work proposes an approach based on multiple criteria to support the analysis and
resolution of causes of problems, in software organizations. The purpose is to understand
the relations between the causes and the results, to find out which causes are more relevant
and, consequently, improve the results.
Keywords: Causal Analysis, Decision Making, Complex Problems, Multicriteria, PDCA,
MCDA, MACBETH.
ix
SUMÁRIO
LISTA DE FIGURAS................................................................................ xiii
LISTA DE TABELAS................................................................................ xiv
LISTA DE ABREVIATURAS E SIGLAS............................................... xv
CAPÍTULO 1 – INTRODUÇÃO.............................................................. 01
1.1 CARACTERIZAÇÃO E JUSTIFICATIVA.................................................... 01
1.2 OBJETIVOS..................................................................................................... 04
1.3 METODOLOGIA DE PESQUISA.................................................................. 05
1.4 ORGANIZAÇÃO DA DISSERTAÇÃO.......................................................... 06
CAPÍTULO 2 – ANÁLISE E RESOLUÇÃO DE CAUSAS DE
PROBLEMAS..................................................................................... 07
2.1 INTRODUÇÃO................................................................................................ 07
2.2 O QUE É PROBLEMA?.................................................................................. 07
2.3 A COMPLEXIDADE DOS PROBLEMAS..................................................... 08
2.4 ANÁLISE E RESOLUÇÃO DE CAUSAS DE PROBLEMAS...................... 09
2.5 CICLO PDCA................................................................................................... 13
2.6 ANÁLISE E RESOLUÇÃO DE CAUSAS DE PROBLEMAS EM
NORMAS E MODELOS............................................................................
14
2.6.1 ISO/IEC 12207 – Processos de Ciclo de Vida de Software................................ 14
2.6.1.1 ISO/IEC12207 – Processo de Resolução de Problema.......................... 17
2.6.2 MPS.BR - Melhoria de Processo do Software Brasileiro .................................. 19
2.6.2.1 Análise de Causas de Problemas e Resolução no MR-MPS.................. 20
2.6.3 CMMI - Capability Maturity Model Integration.......……………………….....
...
22
2.6.3.1 Análise e Resolução de Causas no CMMI............................................. 23
2.7 CONCLUSÃO.................................................................................................. 25
CAPÍTULO 3 – ABORDAGEM MULTICRITÉRIO DE APOIO À
DECISÃO...........................................................................................
26
3.1 INTRODUÇÃO................................................................................................ 26
3.2 TOMADA DE DECISÃO................................................................................ 26
3.3 ABORDAGEM MULTICRITÉRIO................................................................. 27
3.4 METODOLOGIAS MULTICRITÉRIO........................................................... 30
x
3.4.1 A Metodologia MCDA........................................................................................ 30
3.4.1.1 Fases do MCDA........................................................................................ 31
3.4.1.1.1 Fase de Estruturação..................................................................... 32
3.4.1.1.2 Fase de Avaliação......................................................................... 33
3.4.1.1.3 Fase de Recomendação................................................................. 34
3.5 MACBETH....................................................................................................... 34
3.5.1 Caracterização do Contexto da Decisão............................................................ 36
3.5.2 Definição de Critérios e Ações........................................................................... 36
3.5.3 Construção do Descritor de Impacto de cada Critério...................................... 37
3.5.4 Definição dos Pesos para “Bom” e para “Neutro”........................................... 39
3.5.5 Avaliação de cada Critério................................................................................. 40
3.5.6 Cálculo do Valor do Critério.............................................................................. 40
3.5.7 Análise de Sensibilidade nos Resultados............................................................ 40
3.5.8 Resultado Final................................................................................................... 41
3.6 HIVIEW............................................................................................................ 41
3.6.1 Por que utilizar o Hiview?.................................................................................. 42
3.7 CONCLUSÃO.................................................................................................. 43
CAPÍTULO 4 – TRABALHOS CORRELATOS.................................... 44
4.1 INTRODUÇÃO................................................................................................ 44
4.2 METODOLOGIA PARA ANÁLISE E SOLUÇÃO DE PROBLEMAS –
MASP.......................................................................................................... 44
4.3 MÉTODO DAS 8 DISCIPLINAS - 8D.......................................................... 46
4.4 QUALITY CONTROL STORY – QC STORY............................................... 48
4.5 CONSIDERAÇÕES SOBRE AS METODOLOGIAS APRESENTADAS.... 49
4.6 CONCLUSÃO.................................................................................................. 50
CAPÍTULO 5 – ABORDAGEM PARA ANÁLISE E RESOLUÇÃO
DE CAUSAS DE PROBLEMAS APLICANDO
MULTICRITÉRIO............................................................................ 51
5.1 INTRODUÇÃO................................................................................................ 51
5.2 DESCRIÇÃO DA ABORDAGEM.................................................................. 51
5.3 FASES DA ABORDAGEM............................................................................. 53
5.3.1 Planejar (Plan)................................................................................................... 54
5.3.1.1 PASSO P1: Descrever o Problema........................................................ 54
5.3.1.2 PASSO P2: Formar a Equipe................................................................. 56
xi
5.3.1.3 PASSO P3: Definir Objetivos e Metas.................................................. 58
5.3.2 Executar (Do)...................................................................................................... 59
5.3.2.1 PASSO D1: Determinar as Causas do Problema................................... 60
5.3.2.1.1 SUBPASSO D1.1: Investigar as Causas Potenciais do
Problema........................................................................
60
5.3.2.1.2 SUBPASSO D1.2: Consolidar os Resultados........................ 63
5.3.2.1.3 SUBPASSO D1.3: Identificar as Causas Elementares.......... 64
5.3.2.1.4 SUBPASSO D1.4: Construir os Descritores e Identificar os
Níveis “Bom” e “Neutro”.............................................. 64
5.3.2.1.5 SUBPASSO D1.5: Avaliar as Causas.................................... 65
5.3.2.1.6 SUBPASSO D1.6: Analisar os Resultados............................ 66
5.3.2.2 PASSO D2: Analisar as Possíveis Soluções…...................................... 67
5.3.2.3 PASSO D3: Elaborar e Executar o Plano de Ação.................................... 68
5.3.3 Controlar (Check)............................................................................................... 69
5.3.3.1 PASSO C1: Acompanhar e Avaliar os Resultados................................ 69
5.3.4 Agir (Act)............................................................................................................ 70
5.3.4.1 PASSO A1: Divulgar os Resultados...................................................... 70
5.3.4.2 PASSO A2: Incorporar as Lições Aprendidas....................................... 71
5.4 COMPARAÇÃO DA ABORDAGEM COM OUTRAS METODOLOGIAS 72
5.5 CONCLUSÃO.................................................................................................. 73
CAPÍTULO 6 – EXPERIÊNCIA DE USO.............................................. 74
6.1 INTRODUÇÃO................................................................................................ 74
6.2 CARACTERIZAÇÃO DA ORGANIZAÇÃO................................................. 74
6.3 PROCESSOS DO SERPRO............................................................................. 75
6.4 APLICAÇÃO DA ABORDAGEM PROPOSTA............................................. 76
6.4.1 Planejar .............................................................................................................. 76
6.4.1.1 PASSO P1: Descrever o Problema........................................................ 76
6.4.1.2 PASSO P2: Formar a Equipe................................................................. 80
6.4.1.3 PASSO P3: Definir Objetivos e Metas.................................................. 84
6.4.2 Executar ............................................................................................................. 85
6.4.2.1 PASSO D1: Determinar as Causas do Problema................................... 85
6.4.2.1.1 SUBPASSO D1.1: Investigar as Causas Potenciais do
Problema........................................................................ 85
6.4.2.1.2 SUBPASSO D1.2: Consolidar os Resultados....................... 89
6.4.2.1.3 SUBPASSO D1.3: Identificar as Causas Elementares.......... 93
xii
6.4.2.1.4 SUBPASSO D1.4: Construir os Descritores e Identificar os
Níveis “Bom” e “Neutro”...............................................
95
6.4.2.1.5 SUBPASSO D1.5: Avaliar as Causas.................................... 95
6.4.2.1.6 SUBPASSO D1.6: Analisar os Resultados............................ 100
6.4.2.2 PASSO D2: Analisar as Possíveis Soluções.......................................... 102
6.4.2.3 PASSO D3: Elaborar e Executar o Plano de Ação................................ 107
6.4.3 Controlar e Agir.................................................................................................. 108
6.5 ANÁLISE DA EXPERIÊNCIA DE USO DA ABORDAGEM...................... 108
6.6 CONCLUSÃO.................................................................................................. 111
CAPÍTULO 7 – CONCLUSÃO................................................................ 112
7.1 CONSIDERAÇÕES FINAIS........................................................................... 112
7.2 LIMITAÇÕES.................................................................................................. 114
7.3 TRABALHOS FUTUROS............................................................................... 114
REFERÊNCIAS BIBLIOGRÁFICAS.................................................... 116
APÊNDICE A – TABELAS RESUMO DOS PASSOS DA
ABORDAGEM...................................................................................
125
APÊNDICE B – MODELOS DE DOCUMENTOS GERADOS
PARA A ABORDAGEM................................................................... 135
xiii
LISTA DE FIGURAS
Figura 2.1 - Fluxo de Análise de Problema [KEPNER e TREGOE, 1981]................... 12
Figura 2.2 - Processo de Ciclo de Vida de Software [ISO/IEC 12207, 2004]............... 15
Figura 2.3 - Estrutura do MR-MPS [SOFTEX, 2007a]................................................. 20
Figura 2.4 - Componentes do CMMI [CMMI-DEV, 2006]........................................... 23
Figura 2.5 - Diagrama de Contexto da Análise e Resolução de Causas [AHERN,
2003] .......................................................................................................... 24
Figura 3.1 - Fases do MCDA [BANA e COSTA et al., 1999]....................................... 32
Figura 3.2 - Tipos de Descritores [THOMAZ, 2005].................................................... 37
Figura 3.3 - Classificação e exemplos de descritores..................................................... 38
Figura 3.4 - Identificação dos Níveis de um Descritor Genérico................................... 39
Figura 6.1 - Indicador da Evolução do % de Inoperância da Equipe 1.......................... 79
Figura 6.2 - Causas Consolidadas Relacionadas a Pessoas............................................ 90
Figura 6.3 - Causas Consolidadas Relacionadas a Processo.......................................... 91
Figura 6.4 - Causas Consolidadas Relacionadas à Organização.................................... 92
Figura 6.5 - Causas Consolidadas Relacionadas à Tecnologia...................................... 92
Figura 6.6 - Diagrama de Causa e Efeito das Causas Consolidadas.............................. 94
Figura 6.7- Matriz de Juízos de Valor para o PVF Pessoas.......................................... 96
Figura 6.8 - Matriz de Juízos de Valor para o PVF Processo........................................ 96
Figura 6.9 - Matriz de Juízos de Valor para o PVF Organização.................................. 97
Figura 6.10 - Matriz de Juízos de Valor para o PVF Tecnologia..................................... 97
Figura 6.11 - Termômetro dos Pontos de Vista Fundamentais........................................ 98
Figura 6.12 - Matriz de Juízos de Valor para Atribuição de Pesos aos PVFs.................. 99
Figura 6.13 - Resultado dos Escores Obtidos em cada Opção......................................... 99
Figura 6.14 - Análise de Sensibilidade para o Critério Pessoas....................................... 101
xiv
LISTA DE TABELAS
Tabela 2.1 - Processo de Resolução de Problema na ISO 12207...................................
18
Tabela 2.2 - Resumo do Processo de Análise de Causas de Problemas e Resolução no
MR-MPS ....................................................................................................
21
Tabela 2.3 - Resumo da Área de Processo de Análise e Resolução de Causas no
CMMI.........................................................................................................
25
Tabela 4.1 - Etapas do MASP.........................................................................................
46
Tabela 4.2 - Etapas do 8D...............................................................................................
47
Tabela 4.3 - Etapas do QC Story....................................................................................
48
Tabela 5.1 - Passos da Abordagem.................................................................................
53
Tabela 5.2 - Causas Comuns de Problemas em Organizações de Software por
Categoria.....................................................................................................
62
Tabela 6.1 - Mapeamento entre Objetivos de Negócio e Necessidades de Informação
com os Objetivos de Medição....................................................................
77
Tabela 6.2 - Papéis dos Envolvidos e Passos onde Possuem Participação.....................
83
Tabela 6.3 - Detalhamento da Meta................................................................................
84
Tabela 6.4 - Causas Identificadas Relacionadas a Pessoas.............................................
86
Tabela 6.5 - Causas Identificadas Relacionadas a Processo...........................................
87
Tabela 6.6 - Causas Identificadas Relacionadas à Organização.....................................
87
Tabela 6.7 - Causas Identificadas Relacionadas à Tecnologia.......................................
88
Tabela 6.8 - Sugestões de Ações para Tratamento dos Problemas.................................
103
Tabela 6.9 - Plano de Ação.............................................................................................
107
xv
LISTA DE ABREVIATURAS E SIGLAS
ACD Análise Crítica de Desempenho
ACP Análise de Causas de Problemas e Resolução
AME Analisador de Medidas
CAR Causal Analysis And Resolution
CMA Coordenador do Grupo de Medição e Análise
CMMI Capability Maturity Model Integration
GG Objetivos Genéricos (Generic Goals)
GP Práticas Genéricas (Generic Practices)
GPES Grupo de Processo de Engenharia de Software
GQS Garantia de Qualidade de Software
GS Gerente Sênior
GT-MA Grupo de Trabalho de Medição e Análise
ISO/IEC
International Standard Organization/International Electrotechnical
Commission
MACBETH Measuring Attractiveness by a Category Based Evaluation Technique
MA-MPS Método de Avaliação para Melhoria do Processo de Software
MASP Metodologia para Análise e Solução de Problemas
MCDA Multiple Criteria Decision Aid
MCDM Multiple Criteria Decision Making
MN-MPS Modelo de Negócios para Melhoria de Processo de Software
MPS.BR Melhoria de Processo do Software Brasileiro
MR-MPS Modelo de Referência para Melhoria de Processo de Software
PA Área de Processo (Process Area)
PDCA Plan, Do, Check, Act
PMS Método de Estruturação de Problemas
PSDS Processo Serpro de Desenvolvimento de Soluções
PVE Ponto de Vista Elementar
PVF Ponto de Vista Fundamental
xvi
RCA Root Cause Analysis
REMA Relatório de Medição e Análise
RUP Rational Unified Process
SERPRO Serviço Federal de Processamento de Dados
SG Objetivos Específicos (Specific Goals)
SGI Sistema de Gestão de Informações
SM Solicitação de Mudança
SMART Specific, Measurable, Aligned, Realistic/Relevant and Time-bound
SP Práticas Específicas (Specific Practices)
TI Tecnologia da Informação
Capítulo
1
Introdução
“... Apenas responder de forma rápida um estímulo não atende mais a todas
as necessidades dos mercados; é preciso ser proativo. Estamos na era da
proatividade, onde levam vantagens àqueles que conseguem se antecipar às
mudanças.”
EDUARDO NEWTON O. VIEIRA
Este capítulo aborda a contextualização e justificativa deste trabalho, os
objetivos, a contribuição para a ciência, a metodologia de pesquisa
utilizada e a forma de organização de cada capítulo.
1.1 CARACTERIZAÇÃO E JUSTIFICATIVA
A qualidade dos produtos e serviços oferecidos pelas organizações de tecnologia da
informação é o determinante de sucesso em um ambiente cada vez mais competitivo. Face
às transformações ocorridas nas últimas décadas, em virtude da globalização e das
incessantes inovações, a competitividade tornou-se mais acirrada e a previsibilidade das
ações e repetição dos problemas que ocorriam já não é mais possível.
A complexidade técnica oriunda dos serviços de tais organizações requer, além de
pessoas especializadas, técnicas e processos para a análise e resolução das causas dos
problemas. A solução de problemas utilizando-se unicamente a experiência é inviável.
Problemas mais complexos exigem uma análise aprofundada através do uso de
metodologias e técnicas para que se obtenha um bom resultado.
De modo a desempenhar suas atividades, os responsáveis pelas tomadas de decisão
se vêem constantemente diante de situações conflitantes, que envolvem questões de médio
e grande risco, cujas decisões, caso mal tomadas, podem ter sérias conseqüências. No
entanto, na maioria das vezes o responsável pela tomada de decisão acaba incorporando
2
seus valores intrínsecos, utilizando, de forma muitas vezes inconsciente, todos os recursos
pessoais para a busca da solução. Esta utilização se dará, provavelmente, de forma vaga e
imprecisa, muitas vezes excluindo variáveis relevantes para a decisão.
Além disso, agindo desta forma, o responsável pela tomada de decisão, se
questionado sobre os fatores que influenciaram a sua decisão, estará impossibilitado de dar
uma resposta consciente e satisfatória. Esta ausência de conscientização é percebida, de
forma mais séria, na maneira como muitos tomadores de decisão tentam resolver seus
problemas: partem para a chamada resolução antes mesmo de refletir sobre a natureza real
de seu problema, caracterizando assim um ponto comum na área de tecnologia da
informação, na qual a resolução de problemas, na maioria das vezes, é realizada por
“tentativa e erro” [THOMAZ, 2005].
Desta forma, o responsável pela tomada de decisão pode perder o foco do seu
problema real, correndo o risco de solucionar o problema errado, exatamente pela falta de
entendimento do problema e de todo o contexto onde este está inserido. A falta de
planejamento leva à dispersão de esforços e à falha na coleta de informações para a
investigação das causas do problema. Esse processo de tentativa e erro para a solução do
problema pode acrescentar um longo tempo no processo. Em alguns casos, o problema é
resolvido, porém a causa não é identificada tornando a infra-estrutura vulnerável ao longo
do tempo.
Assim, é comum as organizações se depararem com algumas armadilhas durante a
análise e resolução das causas dos problemas, tais como [GRIMALD e MANCUSO, 1994]:
• Não consultar dados históricos: não levar em consideração problemas
similares já ocorridos no passado, que são uma fonte de informação.
• Concluir por intuição: ir direto à solução do problema sem analisar os
ângulos da questão ou explorar outras alternativas
• Decidir pelo mais fácil: desprezar dados e fatos fundamentais, por pressa ou
dificuldade em obtê-los.
3
• Dimensionar mal o problema: às vezes, a solução está em esfera superior
de decisão, não sendo de competência do grupo.
• Contentar-se com uma solução: insistir na solução encontrada,
desprezando objeções e dificuldades.
• Isolar-se com o problema: não consultar pessoas-chave, nem as que serão
responsáveis pela ação e nem as que serão afetadas pela solução.
• Desprezar os detalhes: encontrar solução sem aprofundar a sua viabilização
• Utilizar técnicas inadequadas: escolher a técnica mais fácil, porém, menos
adequada para o tipo de problema.
• Não acompanhar os resultados obtidos: após a realização das ações, não é
realizado um acompanhamento efetivo para analisar os efeitos gerados.
Para tratar algumas destas dificuldades, algumas metodologias de análise e solução
de problemas são utilizadas. No entanto, elas variam amplamente de acordo com a situação
considerada. Por serem bastante genéricas, a implementação das abordagens já existentes
no mercado para análise e resolução de causas de problemas torna-se difícil quando se faz
necessário adaptá-las a um contexto específico, como é o caso de organizações de TI, que
tratam de projetos que possuem recursos e prazos geralmente limitados, num mercado cada
vez mais competitivo. Assim, nem sempre estas adaptações são bem sucedidas, podendo
gerar alguns problemas, tais como:
• Desperdício de esforço e recursos em resolver problemas similares.
• Análises inadequadas de problemas de baixo impacto.
• Desmotivação da equipe ao tentar buscar as causas do problema.
• Inviabilidade de aplicação da metodologia devido a altos custos e
morosidade, entre outros.
Em se tratando de problemas complexos, que envolvem várias pessoas com
diferentes pontos de vista e valores, esse processo de análise e resolução de causas se torna
4
ainda mais crítico, necessitando assim de uma abordagem mais robusta. É necessário,
portanto, um método de análise e resolução de problemas que rompa com os modelos
mentais existentes e que amplie a capacidade do indivíduo ver o mundo e agir [GAV,
1998].
Desta forma, o uso de metodologias multicritério de apoio à decisão como
instrumento de apoio para o processo de análise das causas de tais problemas se torna
extremamente útil, uma vez que esta metodologia proporciona uma melhor adaptação aos
contextos decisórios encontrados na prática, permitindo que um grande número de dados,
interações e objetivos sejam avaliados de forma integrada e mais criteriosa.
Além disso, as metodologias multicritério vêm sendo cada vez mais utilizadas para
apoiar a análise de decisões, devido às necessidades crescentes de analisar de forma
sistemática e formalizada os contextos decisórios complexos que atualmente se apresentam.
Análises deste tipo são valiosas ao considerar a natureza multidisciplinar dos problemas e
as conseqüências das alternativas das ações segundo vários pontos de vista, permitindo aos
envolvidos um melhor entendimento do contexto decisório e um conseqüente aprendizado,
inclusive no que se refere aos seus valores e preferências.
Diante deste contexto, este trabalho tem como objetivo propor uma abordagem para
auxiliar na análise e resolução das causas dos problemas no âmbito de organizações de
software aplicando a metodologia multicritério de apoio à decisão, com o intuito de
entender a relação entre as causas e os resultados, encontrar quais as causas do problema
que são mais relevantes, eliminar as causas relevantes do problema e, conseqüentemente,
melhorar os resultados.
1.2 OBJETIVOS
Este trabalho tem como objetivo principal definir uma abordagem para análise e
resolução de causas de problemas complexos no âmbito de organizações de software
fazendo uso da metodologia multicritério de apoio à decisão. A partir da definição desta
abordagem, seu uso será exemplificado através da aplicação em uma organização.
5
Os objetivos específicos deste trabalho são:
• Realizar uma fundamentação teórica sobre os conceitos relacionados à
Análise e Resolução de Causas de Problemas e sobre o apoio Multicritério à
Tomada de Decisão com o intuito de dar subsídios à abordagem proposta.
• Propor uma abordagem para análise e resolução de causas para organizações
de software aplicando multicritério, apresentando suas fases e passos tendo
em vista a resolução de problemas complexos.
• Aplicar a abordagem proposta em uma organização de software para avaliar
o seu uso e apresentar os resultados obtidos.
1.3 METODOLOGIA DE PESQUISA
Para atingir seus objetivos propostos, o desenvolvimento deste trabalho foi dividido
em quatro etapas:
• A primeira etapa consistiu na realização de uma revisão da literatura no que
diz respeito à Análise e Resolução de Causas de Problemas, à Metodologia
Multicritério de Apoio à Decisão e ao estudo de metodologias para análise e
resolução de causas de problemas já existentes.
• A segunda etapa consistiu no desenvolvimento da abordagem proposta, a
partir da revisão bibliográfica.
• A terceira etapa envolveu uma experiência de uso da abordagem proposta
para avaliação e melhoria da mesma.
• A quarta etapa consistiu na avaliação da abordagem proposta a partir dos
resultados obtidos na experiência de uso, ressaltando as principais
dificuldades em sua utilização, bem como seus pontos fortes e pontos fracos.
6
1.4 ORGANIZAÇÃO DA DISSERTAÇÃO
A dissertação está estruturada em seis capítulos e dois apêndices, conforme segue:
O capítulo em questão, Introdução, apresenta a caracterização e justificativa deste
trabalho, e descreve os objetivos, a contribuição para a ciência, a metodologia de pesquisa
utilizada, bem como a presente estrutura.
O Capítulo 2, Análise e Resolução de Causas de Problemas, aborda o referencial
teórico referente a tal assunto, destacando modelos e normas que tratam do mesmo.
O Capítulo 3, Abordagem Multicritério de Apoio à Decisão, discorre sobre os
conceitos básicos que norteiam este trabalho com relação a multicritério.
O Capítulo 4, Trabalhos Correlatos, apresenta as principais metodologias
relacionadas à análise e resolução de causas de problemas.
O Capítulo 5, Análise e Resolução de Causas de Problemas Aplicando
Multicritério, apresenta a proposta desta dissertação detalhando as suas fases, passos e
subpassos.
O Capítulo 6, Experiência de Uso, mostra os resultados obtidos com a execução da
abordagem proposta em uma organização de software.
O Capítulo 7, Conclusão, exibe as principais conclusões e as contribuições deste
trabalho, bem como as limitações e os trabalhos futuros.
O Apêndice A contém tabelas resumo dos passos da abordagem e, o Apêndice B,
contém modelos de documentos que podem ser utilizados como forma de facilitar a
execução da abordagem proposta.
Capítulo
2
Análise e Resolução de Causas de Problemas
“Os problemas significativos que enfrentamos não podem ser
resolvidos no mesmo nível de pensamento em que estávamos
quando os criamos.”
ALBERT EINSTEIN
2.1 INTRODUÇÃO
Este capítulo apresenta os principais conceitos, normas e modelos relacionados à
Análise e Resolução de Causas de Problemas. Desta forma, discorre sobre o que vem a ser
um problema e sua complexidade, apresenta o ciclo PDCA como um método gerencial de
tomada de decisões e apresenta a ISO/IEC 12207, o MPS.BR e o CMMI tendo como foco o
tema em questão.
2.2 O QUE É PROBLEMA?
Segundo Juran (1992) problema é um desvio da característica de qualidade de seu
nível ou estado pretendido que ocorre com gravidade suficiente para fazer com que um
produto associado não satisfaça às exigências de uso, normal ou razoavelmente previsível,
ou, conforme Hosotani, (1992) um problema é a diferença entre a situação atual e a
situação ideal ou a situação atual e o objetivo.
Sob uma perspectiva pragmática, um problema é um resultado indesejável de um
processo. Em outras palavras, é um item de controle que não atinge o nível desejado
[WERKEMA, 1995]. Outra definição pragmática pode ser obtida em Campos (1992), que
diz que um problema é um resultado indesejável de um processo.
8
Do ponto de vista do processo, pode-se dizer que problema é a falta de
conformidade em relação aos padrões definidos. Buscando-se em uma definição mais
gerencial, um problema pode ser tradicionalmente definido como um gap entre o estado
atual e o estado desejado, ou seja, uma situação que necessita ser melhorada [SMITH,
1998]. McGregor (1961) afirma que gerenciar é essencialmente resolver problemas.
Sendo assim, podemos afirmar que problemas são resultados indesejáveis, efeitos
percebidos de causas que precisam ser identificadas, analisadas e eliminadas. Temos um
problema quando percebemos uma defasagem entre a meta estabelecida e o resultado
alcançado. Ou seja, é a diferença entre o resultado obtido e o que se esperava alcançar. Eles
estão sempre relacionados aos fins, aos resultados, nunca aos meios. No entanto, se
cuidarmos dos meios, o fim cuidará de si próprio.
2.3 A COMPLEXIDADE DOS PROBLEMAS
A primeira questão que se pode levantar é: O que são, afinal, problemas complexos?
Problemas complexos são problemas que obrigam a um grande esforço de estruturação,
sendo aqueles que, na maioria dos casos, são encontrados pelo facilitador quando atua na
prática do apoio à decisão [THOMAZ, 2005].
Segundo Churchill (1990), problemas complexos são definidos como sendo aqueles
que necessitam de grande esforço de estruturação, ou seja, aqueles em que estão presentes
vários decisores e muitas características subjetivas com vários fatores envolvidos. De
acordo com o autor, são chamados de problemas complexos porque:
• São caracterizados pela intratabilidade das análises por causa de informações
incompletas; falta de definição, concordância, parâmetros quantitativos;
múltiplos objetivos conflitantes; e participantes em conflitos.
• São caracterizados por uma grande quantidade de informações qualitativas.
• Podem ser descritos como confusos e com falta de clareza sobre a definição
do problema.
• Envolvem vários membros de uma equipe, visões e objetivos divergentes
com respeito à situação.
9
• Refletem importantes interações entre diferentes jogadores de fora
(colaboradores) do grupo de decisão.
• Resolvê-los envolverá cumplicidade entre os membros da equipe conforme
eles negociam maneiras através da dinâmica de alcançar o consenso (na
verdade, uma situação de compromisso).
• O processo de resolução de problemas é influenciado por membros com
diferentes poderes dentro de uma equipe, e a administração deste processo é
particularmente importante.
• Resolvê-los requer criatividade para a descoberta de um rol de opções (ações
potenciais).
Tomar decisões complexas é, de modo geral, uma das mais difíceis tarefas
enfrentadas individualmente ou por grupos de indivíduos, pois quase sempre tais decisões
devem atender a múltiplos objetivos, e freqüentemente seus impactos não podem ser
corretamente identificados.
Conclui-se, então, que um problema complexo envolve diversos atores, com
diferentes relações de poder, cada um deles com diferentes valores, percepções e objetivos.
Esses fatores fazem com que uma das questões cruciais do facilitador, na prática do apoio à
decisão, seja a de procurar definir qual a compreensão e a interpretação de cada um dos
atores sobre o problema.
2.4 ANÁLISE E RESOLUÇÃO DE CAUSAS DE PROBLEMAS
De acordo com a Softex (2007b), a análise e resolução de causas de problemas é um
processo sistemático para identificar e analisar causas associadas à ocorrência de
determinados tipos de problema, permitindo identificar oportunidades de melhoria para os
processos da organização visando prevenir a ocorrência daquele tipo de problema em
projetos futuros. CARD [2005] descreve o processo de análise e resolução de causas de
problemas de forma resumida, como contendo os seis seguintes passos:
• Selecionar uma amostra do problema. Normalmente a análise de causas
de problemas é disparada por uma instabilidade detectada em um gráfico de
10
controle [FLORAC e CARLETON, 1999]. Os dados associados à
instabilidade se tornam então o foco da análise de causas e, uma amostra
destes dados deve ser selecionada para a reunião de análise das causas.
• Classificar os problemas selecionados. Entre as informações básicas a
serem armazenadas a respeito dos problemas, temos o tipo de problema, o
momento de inserção, o momento de detecção e o esforço de retrabalho para
corrigir o problema. O uso de tabelas de índices cruzados, histogramas,
gráficos de Pareto e técnicas como attribute focusing [BHANDARI et al.,
1993] podem ajudar a encontrar agrupamentos de problemas com base em
sua classificação. Erros sistemáticos possuem probabilidade maior de serem
encontrados nos tipos de problemas mais comuns.
• Identificar erros sistemáticos. Um erro sistemático resulta em problemas
similares se repetindo em diferentes ocasiões [CARD, 2005]. Normalmente
erros sistemáticos estão associados com uma atividade ou parte do produto
específica. Encontrar erros sistemáticos indica a existência de oportunidades
de melhoria para o processo.
• Identificar as principais causas. Muitos fatores podem contribuir para um
erro sistemático e tratar todos eles muitas vezes não é economicamente
viável. Assim, deve haver um esforço no sentido de encontrar as causas
principais. Neste passo é que a compreensão de sistemas causais,
relacionando causas, problemas e sintomas, se torna uma habilidade útil.
Entre as técnicas utilizadas para encontrar as causas principais temos o uso
dos diagramas de causa e efeito (ou diagramas de Ishikawa) [ISHIKAWA,
1976].
• Desenvolver itens de ação. Uma vez que a causa principal de um defeito
sistemático foi encontrada, itens de ação devem ser desenvolvidos para
promover a prevenção (ou detecção mais cedo, em casos que a prevenção
não é possível) dos erros sistemáticos. Normalmente o número de ações é
pequeno. As ações devem ser tão pontuais e específicas quanto possível,
facilitando o acompanhamento objetivo do estado de sua implantação.
11
• Documentar os resultados da reunião de análise causal. Registros dos
resultados da reunião de análise causal precisam ser mantidos para assegurar
que as ações serão implementadas. De acordo com CARD [2005], para o
sucesso de um programa de análise causal é essencial que uma equipe de
ação seja formada. Os resultados da reunião de análise causal devem ser
fornecidos para esta equipe, que tem entre suas responsabilidades encontros
regulares a respeito das ações propostas. A aplicação de atividades de análise
de causas de problemas e resolução também fornece um mecanismo
eficiente para disseminação de conhecimento na organização [AL-SHEHAB
et al., 2005]. Por exemplo, lições aprendidas coletadas ao longo dos projetos
descrevem problemas, soluções aplicadas e os efeitos obtidos com a
aplicação dessas soluções para tratamento dos problemas. Essas lições
constituem um ativo de conhecimento importante de ser gerenciado para
evitar que os mesmos problemas ocorram em projetos futuros e para auxiliar
no tratamento dos problemas caso venham a ocorrer.
Segundo Kepner e Tregoe (1981), a análise do problema é um processo lógico de
relacionar um corpo de informação durante a busca por uma solução. A cada estágio, a
informação vai surgindo, à medida que o processo se movimenta para o que está errado,
passando para o problema a ser tratado e a seguir para as possíveis causas que fizeram o
problema surgir, e finalmente para a causa mais provável com uma ação corretiva
específica em relação ao problema, conforme mostra a Figura 2.1.
12
Figura 2.1: Fluxo de Análise de Problema [KEPNER e TREGOE, 1981]
Para cada tipo de problema, existe uma série de metodologias que podem ser
utilizadas. O MASP (Metodologia para Análise e Solução de Problemas) [GRIFO, 1997], o
QC-Story (Quality Control Story) [CAMPOS, 1992] e as Oito Disciplinas (8-D) [FORD,
1999], por exemplo, são metodologias abertas que tratam dos problemas do dia a dia da
indústria. Geralmente são empregadas no tratamento de não conformidades apresentadas
pelos processos.
No entanto, muitas vezes as empresas não conseguem atingir suas metas de
qualidade com a utilização das metodologias apresentadas anteriormente. Alguns autores
discutem a aplicabilidade de metodologias que utilizem técnicas específicas como as
ferramentas japonesas. Outros, ainda, questionam a respeito da adaptação de técnicas
importadas neste processo de análise de problemas.
13
A resolução de problemas é possível através das análises das relações entre
características e causas de um problema, executando ações corretivas apropriadas.
Entretanto, esse processo de estratégica de soluções de problema pode ser abordado sob
diversos ângulos. Conseqüentemente, quando se usa uma metodologia mal aplicada, não se
chega em ações de melhoria adequadas [GONÇALVES et al., 2008]. Sendo assim, é
importante entender as relações entre as causas e as características do problema ou efeito.
2.5 CICLO PDCA
Várias abordagens para melhoria de processo de software têm como referência o
ciclo PDCA (PLAN - Planejar, DO - Fazer, CHECK - Avaliar e ACT - Agir), desenvolvido
por Shewhart na década de 1930 e popularizado por Deming na década de 1980.
Werkema (1995) define o ciclo PDCA como um método gerencial de tomada de
decisões para garantir o alcance de metas necessárias à sobrevivência de uma organização.
Considerando a definição de que um problema é um resultado indesejável de um processo,
o PDCA pode ser visto como um método de tomada de decisões para a resolução de
problemas organizacionais. Assim, o PDCA indica o caminho a ser seguido para que as
metas estipuladas possam ser alcançadas.
De acordo com Campos (1992), a fase P consiste nas etapas de identificação do
problema, observação (reconhecimento das características do problema) e análise do
processo (descoberta das causas principais que impedem o alcance das metas). A fase D é a
de ação (contramedidas sobre as causas principais), ou atuação de acordo com o plano de
ação para bloquear as causas fundamentais. Na fase C, é feita a verificação, ou seja, a
confirmação da efetividade do plano de ação para ver se o bloqueio foi efetivo. Já na fase A
existem duas etapas, a de padronização e a de conclusão. Na etapa de padronização, caso o
bloqueio tenha sido efetivo, é feita a eliminação definitiva das causas para que o problema
não reapareça. Na etapa de conclusão ocorre a revisão das atividades e planejamento para
trabalhos futuros. Caso na fase C, o bloqueio não tenha sido efetivo, deve-se voltar para a
fase P.
No entanto, é necessário ter um processo claro de análise e resolução de problemas
de acordo com o contexto da organização, bem como o emprego correto de técnicas e
14
ferramentas para a obtenção, processamento e disposição das informações necessárias à
condução das etapas do PDCA.
Desta forma, existem várias iniciativas de normas e modelos que guiam as
organizações no processo de análise e resolução de problemas no âmbito de organizações
de TI. Dentre elas, merecem destaque a ISO/IEC 12207 [ISO/IEC 12207, 2004], o MPS.BR
[SOFTEX, 2007a] e o CMMI [CMMI-DEV, 2006], que são apresentados nas próximas
seções. Vale destacar que não é foco desta dissertação atender a tais normas e modelos.
2.6 ANÁLISE E RESOLUÇÃO DE CAUSAS DE PROBLEMAS EM NORMAS E
MODELOS
Existem, atualmente, normas e modelos que tratam da análise e resolução de causas
de problemas, onde merecem destaque: a ISO/IEC 12207, o MPS.BR e o CMMI, que serão
descritos nas seções a seguir.
2.6.1 ISO/IEC 12207 – PROCESSOS DE CICLO DE VIDA DE SOFTWARE
O padrão internacional ou modelo de referência ISO/IEC 12207 - Processos do
Ciclo de Vida do Software [ISO/IEC 12207, 2004] foi estabelecido pela International
Standard Organization (ISO) em 1995 e tem como principal objetivo fornecer uma
estrutura única para que o adquirente, fornecedor, desenvolvedor, mantenedor, operador,
gerentes e técnicos envolvidos com o desenvolvimento de software utilizem uma
linguagem comum que é estabelecida na forma de processos bem definidos.
Por meio de processos bem definidos, a Norma 12207 auxilia os envolvidos na
produção de software a definir seus papéis e, conseqüentemente, proporciona às
organizações que a utilizam, um melhor entendimento das atividades que envolvem de
alguma forma o software [ROCHA et al., 2001].
Segundo Singh (1999), todos os processos distribuem suas atividades tendo
inspiração no ciclo PDCA, os macro-processos e todos seus processos se integram de
maneira que os processos de desenvolvimento têm suporte dos processos de apoio e são
influenciados pelos processos organizacionais.
15
Os processos são agrupados, por uma questão de organização, de acordo com a sua
natureza, ou seja, o seu objetivo principal no ciclo de vida de software, conforme podemos
ver na Figura 2.2.
Figura 2.2: Processo de Ciclo de Vida de Software [ISO/IEC 12207, 2004]
16
Esse agrupamento resultou em três diferentes classes de processos, que são:
• Fundamental: atendem ao contrato entre fornecedor e adquirente e à
execução do desenvolvimento, da operação ou da manutenção de produtos
de software durante o seu ciclo de desenvolvimento. Esta classe é formada
pelos processos de Aquisição, Fornecimento, Desenvolvimento, Operação e
Manutenção.
• De Apoio: auxiliam e contribuem para o sucesso e a qualidade do projeto de
software. Esta classe é formada pelos processos de Documentação, Gerência
de Configuração, Garantia de Qualidade, Verificação, Validação, Revisão
Conjunta, Auditoria e Resolução de Problema.
• Organizacional: são empregados por uma organização para estabelecer e
implementar uma estrutura constituída pelos processos do ciclo de vida e
pelo pessoal envolvido no seu desenvolvimento. Esta classe é formada pelos
processos de Gerência, Infraestrutura, Melhoria e Treinamento.
Há, ainda, o processo de adaptação, que define as atividades básicas necessárias
para executar as adaptações.
Cada um desses processos é divido em um conjunto de atividades, e cada atividade
em um conjunto de tarefas. Os processos de apoio e organizacionais devem existir
independentemente da organização e do projeto que está sendo executado. Os processos
fundamentais são instanciados de acordo com a situação. Estes processos, atividades e
tarefas podem ser adaptados de acordo com as características de um projeto de software.
No entanto, vale ressaltar que a ISO/IEC 12207 descreve a arquitetura de um
processo de forma geral, mas não especifica em detalhes como implementar ou
desempenhar estas atividades, nem descreve o formato ou conteúdo da documentação a ser
gerada. Estes aspectos devem ser definidos pela organização que pretende utilizá-la de
acordo com suas necessidades e as características particulares de cada projeto.
Nas próximas seções, será detalhado o processo de resolução de problema,
relacionado ao tema desta dissertação.
17
2.6.1.1 ISO/IEC 12207 – PROCESSO DE RESOLUÇÃO DE PROBLEMA
O processo de Resolução de Problema é um processo para analisar e resolver os
problemas (incluindo não-conformidades), de qualquer natureza ou fonte, que são
descobertos durante a execução do desenvolvimento, operação, manutenção ou outros
processos. O objetivo é prover os meios em tempo adequado e de forma responsável e
documentada para garantir que todos os problemas encontrados sejam analisados e
resolvidos e tendências sejam identificadas [ISO/IEC 12207, 2004].
Os resultados esperados deste processo são:
• Uma estratégia de gerência de problemas desenvolvida.
• Os problemas registrados, identificados e classificados.
• Os problemas analisados e avaliados para identificar as soluções aceitáveis.
• A resolução de problema implementada.
• Os problemas acompanhados até sua conclusão.
• A situação de todos os problemas relatados sendo conhecida.
Para atingir estes resultados, o processo de resolução de problema é composto
por duas atividades com suas respectivas tarefas e requisitos, conforme podemos ver na
Tabela 2.1.
18
Tabela 2.1 – Processo de Resolução de Problema na ISO 12207
Atividade Tarefa Requisitos
O processo deve ser de ciclo fechado (closed-loop),
garantindo que: todos os problemas detectados sejam
prontamente relatados e incluídos no Processo de
Resolução de Problema; a ação seja iniciada nos
problemas detectados; as partes relevantes sejam
alertadas da existência do problema, quando apropriado;
as causas sejam identificadas, analisadas, e, quando
possível, eliminadas; a resolução e sua aplicação sejam
alcançadas; a situação seja rastreada e relatada; e os
registros dos problemas sejam mantidos, conforme
estipulado no contrato.
O processo deveria conter um esquema para categorizar
e priorizar os problemas. Cada problema deveria ser
classificado por categoria e prioridade para facilitar a
análise de tendência e resolução de problema.
A análise deve ser executada para detectar tendências
nos problemas relatados.
Implemen
tação do
Processo
Estabelecimento de um
processo de resolução de
problema para tratar todos os
problemas (incluindo não-
conformidades) detectados nos
produtos de software e
atividades.
As resoluções de problemas e suas aplicações devem ser
avaliadas para: verificar se os problemas foram
resolvidos, se as tendências adversas foram revertidas e
se as alterações foram implementadas corretamente nos
produtos de software e atividades apropriados; e
determinar se problemas adicionais foram introduzidos.
Resolução
do
Problema
Quando problemas (incluindo
não-conformidades) forem
detectados em um produto de
software ou em uma atividade,
um relatório de problema deve
ser preparado para descrever
cada problema detectado. O
relatório de problema deve ser
usado como parte do processo
de ciclo fechado (closed-loop)
descrito acima: a partir da
detecção do problema, ao
longo da investigação, análise
e resolução do problema e sua
causa, e para detectar
tendências.
19
2.6.2 MPS.BR - MELHORIA DE PROCESSO DO SOFTWARE BRASILEIRO
Em dezembro de 2003 a associação para a promoção da excelência do software
brasileiro – SOFTEX criou o modelo de Melhoria do Processo de Software Brasileiro
MPS.BR com o intuito de aumentar a qualidade dos processos de desenvolvimento de
software em organizações que não possuem tantos recursos para investimento em
qualidade. Este modelo não define novos conceitos, mas, adequa as estratégias de
implementação à realidade brasileira [WEBER et al 2004].
A base técnica para a construção do modelo MPS.BR foram as normas ISO/IEC
12207 [ISO/IEC 12207, 2004] e a ISO/IEC 15504 [ISO/IEC 15504, 2003] com as quais
está em conformidade. Complementarmente, o modelo cobre o conteúdo de outros modelos
de referências, como o CMMI [CHRISSIS, 2006] com o qual é compatível. O modelo
também define regras para sua implementação e avaliação, de modo a dar sustentação e
garantia de que está sendo empregado de forma coerente com suas definições.
O modelo MPS.BR é composto por três componentes: O Modelo de Referência para
Melhoria de Processo de Software (MR-MPS), o Método de Avaliação para Melhoria do
Processo de Software (MA-MPS) e Modelo de Negócios para Melhoria de Processo de
Software (MN-MPS). Cada componente do modelo foi descrito através de documentos
específicos tais como os respectivos guias.
O MR-MPS é o modelo de referência do MPS.BR, ou seja, é a partir dele que as
organizações devem definir seus processos de software. Nele estão contidas as definições
dos níveis de maturidade, que são organizadas em duas dimensões: a dimensão de
capacidade (capability dimension) e a dimensão de processo (process dimension), conforme
pode ser visto na Figura 2.3. A dimensão de capacidade é um conjunto de atributos de um
processo que estabelece o grau de refinamento e institucionalização com que o processo é
executado na organização. À medida que evolui nos níveis, um maior ganho de capacidade
para desempenhar o processo é atingido pela organização.
20
Figura 2.3 – Estrutura do MR-MPS [SOFTEX, 2007a]
O Modelo de Referência MR-MPS define sete níveis de maturidade. Os níveis,
seqüenciais e cumulativos de maturidade do MR-MPS são: 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 de
maturidade inicial.
No nível mais alto do MR-MPS (nível A), está o processo de Análise de Causas de
Problemas e Resolução (ACP), que será apresentado a seguir.
2.6.2.1 ANÁLISE DE CAUSAS DE PROBLEMAS E RESOLUÇÃO NO MR-MPS
O processo Análise de Causas de Problemas e Resolução (ACP) tem o propósito de
identificar causas de defeitos e de outros problemas e tomar ações para prevenir suas
ocorrências no futuro.
Este processo é incluído no nível mais alto do MR-MPS exatamente para fornecer
um melhor apoio aos novos resultados de processo e atributos de processo.
Os resultados esperados desse processo bem como uma breve descrição dos mesmos
estão descritos na Tabela 2.2. Não serão detalhados os atributos do processo por não serem o
foco deste trabalho.
21
Tabela 2.2 – Resumo do Processo de Análise de Causas de Problemas e Resolução no MR-
MPS
MR-MPS - ACP Descrição
ACP1 - Defeitos e
outros problemas são
registrados,
identificados,
classificados e
selecionados para
análise
A organização deve manter registros dos problemas
encontrados a partir da realização das diferentes atividades
dos demais processos. Tais registros devem fazer uso de
esquemas de classificação definidos para a organização,
contendo um identificador para o problema e as informações
a serem armazenadas para permitir a análise causal e
resolução. Por fim, amostras dos problemas devem ser
selecionadas para análise.
ACP2 - Defeitos e
outros problemas são
analisados para
identificar sua causa
raiz e soluções
aceitáveis para evitar
sua ocorrência futura
A organização deve ser capaz de identificar erros sistemáticos
e suas causas principais. A partir da identificação dos erros
sistemáticos, suas causas principais podem ser identificadas.
Por fim, a organização deve ser capaz de desenvolver e
registrar itens de ação. As ações para resolução do problema
devem ser implementadas organizacionalmente por meio de
alterações em ativos de processo organizacional e, quando
pertinente, nos projetos em andamento para prevenir a
ocorrência de defeitos similares.
ACP3 - Ações para
resolução do problema
são selecionadas e
implementadas
Os itens de ação desenvolvidos e registrados no cumprimento
do resultado ACP2 devem ser priorizados e selecionados para
implementação.
ACP4 - As ações
implementadas para
resolução de
problemas são
acompanhadas com
medições, para
verificar se as
mudanças no processo
corrigiram o problema
e melhoraram o seu
desempenho
Uma vez que o processo modificado pela implementação dos
itens de ação é implantado no projeto, o efeito das mudanças
deve ser verificado para obter evidência de que a mudança no
processo corrigiu o problema e melhorou o seu desempenho.
A organização deve medir a mudança no desempenho de seu
processo definido, em relação aos problemas analisados. A
organização deve também medir a capacidade do processo
definido, em relação aos problemas analisados.
ACP5 - Dados das
ações para análise de
causas de problemas e
resolução são
armazenados para uso
em situações similares
A organização deve manter dados da análise de causas de
problemas e dos itens de ação, de modo que outros projetos e
unidades organizacionais possam realizar mudanças
apropriadas em seus processos e atingir resultados similares.
22
2.6.3 CMMI - CAPABILITY MATURITY MODEL INTEGRATION
O Capability Maturity Model Integration (CMMI) [CHRISSIS, 2006] é um modelo
de maturidade de desenvolvimento de produtos desenvolvido pelo Software Engineering
Institute (SEI), que está cada vez mais sendo adotado nas empresas, uma vez que esse
modelo busca orientar as organizações na implementação de melhorias contínuas em seu
processo de desenvolvimento.
Em 1997, o SEI verificou a necessidade de integração dos modelos CMM (SW-
CMM; SE-CMM-EIA/IS; IPD-CMM) para que fosse implementado um processo único de
melhoria para toda a organização, tendo também o intuito de conciliar esses modelos com
outras metodologias e padrões, tais como a ISO 9001, ISO/IEC 15504, entre outros.
Sua estrutura inclui elementos comuns e melhores práticas dos modelos acima
citados, bem como os requisitos e métodos específicos do CMMI, provendo para a
organização a possibilidade de selecionar elementos que melhor se apliquem à sua
estratégia de negócios. O âmbito do CMMI não é somente software, mas desenvolvimento
multidisciplinar, embora apresente forte fundamentação em software.
Segundo Chrissis (2006), o propósito do CMMI é estabelecer um guia para
melhorar o processo da organização e sua capacidade para gerenciar o desenvolvimento,
aquisição e manutenção de produtos e serviços. Por ser um guia de referência, necessita ser
interpretado e adaptado para a realidade de cada organização.
Há duas diferentes representações no CMMI: a representação contínua e a
representação por estágios.
A representação contínua utiliza níveis de capacidade para medir a melhoria do
processo da organização. Essa representação contém seis níveis de capacidade: incompleto,
executado, gerenciado, definido, gerenciado quantitativamente, e em otimização. Suas áreas
de processo são independentes dos níveis de maturidade, ficando relacionadas apenas com
a capacidade do processo, ou seja, uma determinada área de processo em particular poderá
ter sua capacidade avaliada independente das outras áreas de processo, de acordo com o
objetivo estratégico da organização.
23
Na representação por estágios, as áreas de processo comuns são agrupadas em
diferentes níveis de maturidade. São cinco os níveis de maturidade: 1 (Inicial), 2
(Gerenciado), 3 (Definido), 4 (Gerenciado Quantitativamente) e 5 (Em Otimização). O fato
de uma organização, por exemplo, estar no nível dois de maturidade, significa que todas as
áreas de processo obrigatórias para aquele nível foram satisfeitas igualmente.
Conforme pode ser visto na Figura 2.4, cada nível é constituído por um conjunto de
áreas de processos (PA), que são compostas por objetivos genéricos (GG) e objetivos
específicos (SG). Cada objetivo genérico é composto por um conjunto de práticas
genéricas (GP), e os objetivos específicos pelas práticas específicas (SP).
Figura 2.4 - Componentes do CMMI
[CMMI-DEV, 2006]
No nível mais alto de maturidade do CMMI (nível 5), está a área de processo de
Análise e Resolução de Causas (Causal Analysis and Resolution – CAR), que será
apresentada a seguir.
2.6.3.1 ANÁLISE E RESOLUÇÃO DE CAUSAS NO CMMI
A área de processo de Análise e Resolução de Causas tem o propósito de identificar
as causas de defeitos e de outros problemas e tomar ações para prevenir que ocorram no
futuro, proporcionando uma melhoria da qualidade e da produtividade de um produto ou
serviço. A Figura 2.5 mostra o diagrama de contexto desta área de processo.
24
Figura 2.5 - Diagrama de Contexto da Análise e Resolução de Causas [AHERN, 2003]
De acordo com Kasse (2004), confiar em atividades, tais como revisões e testes para
detectar e eliminar os defeitos depois que foram introduzidos no sistema não é muito
efetivo. É mais efetivo prevenir os defeitos através da integração das atividades de análise
e resolução de defeitos em cada fase do projeto. Como os defeitos e os problemas podem
ter sido previamente encontrados em outros projetos ou fases anteriores ou em tarefas do
projeto corrente, as atividades de análise e resolução de causas são mecanismos para
comunicar as lições aprendidas entre os projetos [CHRISSIS, 2006].
Baseado no entendimento do processo definido para uso e em como ele é
implementado, as causas raiz dos defeitos e as futuras implicações dos defeitos podem ser
determinadas. A PA de análise e resolução de causas também fornece um mecanismo para
os projetos avaliarem seus processos e observar as melhorias que podem ser feitas. Se as
melhorias dos projetos mostrarem-se efetivas, elas se tornam candidatas para as melhorias
nos processos a nível organizacional [KASSE, 2004].
Os objetivos específicos (SG) dessa área de processo, bem como suas práticas específicas
com uma breve descrição estão descritos na Tabela 2.3. Não serão detalhados os objetivos e
práticas genéricas por não serem o foco deste trabalho.
25
Tabela 2.3 – Resumo da Área de Processo de Análise e Resolução de Causas no CMMI
SG 1
Determinar as Causas dos Defeitos
SP 1.1
Selecionar dados para análise dos defeitos: consiste em obter os
defeitos relevantes e determinar que outros defeitos e problemas sejam
analisados.
SP 1.2
Analisar causas: consiste em conduzir a análise com as pessoas que são
responsáveis pelas atividades; analisar os defeitos selecionados e outros
problemas para determinar suas causas raiz; agrupar os defeitos
selecionados e outros problemas baseados na causa raiz, e propor e
documentar ações que precisam ser executas para prevenir ocorrências
futuras de defeitos similares e outros problemas.
SG 2 Tratar Causas dos Defeitos
SP 2.1
Implementar ações propostas: consiste em analisar as ações propostas e
determinar suas prioridades; selecionar as ações propostas que serão
implementadas; criar itens de ações para implementação das ações
propostas; identificar e remover defeitos similares que podem existir em
outros processos e produtos de trabalho, e identificar e documentar as
propostas de melhorias para o conjunto de processos padrão da
organização.
SP 2.2
Avaliar os efeitos das mudanças: consiste em medir, quando apropriado,
as alterações no desempenho dos processos definidos para os projetos, e
medir, quando apropriado, a capacidade do processo definido para o
projeto.
SP 2.3
Registrar dados: consiste em registrar os dados da análise e resolução de
causas de problemas para uso através do projeto e da organização.
2.7 CONCLUSÃO
Este capítulo apresentou o referencial teórico referente à Análise e Resolução de
Causas de Problemas, apresentando seu contexto na ISO/IEC 12207, no MPS.BR e no
CMMI. O capítulo seguinte apresenta a abordagem multicritério de apoio à decisão.
Capítulo
3
Abordagem Multicritério de Apoio à Decisão
"Nada é mais difícil, e por isso mais precioso, do que ser capaz de
decidir.”
NAPOLEÃO BONAPARTE
3.1 INTRODUÇÃO
Neste capítulo serão apresentados os conceitos fundamentais relacionados à
Abordagem Multicritério de Apoio à Decisão. Desta forma, discorre sobre tomadas de
decisão, sobre as metodologias multicritério destacando a metodologia MCDA com suas
respectivas fases, apresenta o MACBETH em detalhes e, a ferramenta Hiview, utilizada
nesta dissertação.
3.2 TOMADA DE DECISÃO
Na vida das organizações, inúmeros são os problemas complexos de decisão
enfrentados por seu corpo gerencial, uma vez que a maioria das situações reais é
caracterizada pela existência de vários objetivos ou “desejos” a serem atingidos.
Conforme Laxxus (2005), a decisão está intrinsecamente relacionada a múltiplos
pontos de vista, os quais podem ser definidos como critérios. Quando a escolha de
determinada alternativa depende da análise de diferentes pontos de vista ou “desejos”, o
problema de decisão é considerado um problema multicritério.
Assim, assumindo que tomar decisões é uma tarefa difícil tanto para grupos quanto
para indivíduos isolados; que normalmente a decisão deverá atender a objetivos e a critérios
conflitantes; que as conseqüências das decisões nem sempre são facilmente identificáveis; e
27
que algumas alternativas e/ou objetivos estão interligados, a não aceitação da subjetividade
pode tornar-se uma dificuldade para a solução do problema.
Bana e Costa (1992) considera que, se é verdade que a procura da objetividade é
uma preocupação importante, é crucial não esquecer que a tomada de decisão é antes de
tudo uma atividade humana, sustentada pela noção de valor e que, portanto, a subjetividade
está onipresente e é o motor da decisão.
Dessa forma, as abordagens multicritérios funcionam como uma base para
discussão, principalmente nos casos onde há conflitos entre os decisores, ou ainda, quando
a percepção do problema pelos vários atores envolvidos ainda não está totalmente
consolidada [BOUYSSOU, 1990].
Diante deste contexto, o que o multicritério busca é diminuir a subjetividade na
decisão a ser tomada diante de múltiplos critérios a partir do uso de cálculos. Contudo, a
subjetividade sempre irá existir, visto que os itens a serem avaliados matematicamente são
resultantes de opiniões humanas. Seu objetivo, portanto, é ajudar o “decisor” a analisar as
informações e buscar a melhor estratégia de gestão.
3.3 ABORDAGEM MULTICRITÉRIO
Atualmente, há uma forte tendência de esclarecer a opinião dos tomadores de
decisão em todos os níveis do processo de planejamento nas organizações, quanto à
importância da utilização de múltiplos critérios na análise de problemas complexos. O
objetivo da tomada de decisão multicriterial é identificar e selecionar o melhor curso de
ação, quando se depara com um problema de decisão complexo que envolve múltiplos
objetivos e, até certo ponto, conflitantes.
Esta nova forma de encarar o processo de tomada de decisão permite a consideração
de diversos fatores relevantes que possibilitam uma análise mais detalhada das vantagens e
desvantagens dos cursos alternativos de ação de um sistema. Dentre estes fatores, pode-se
destacar os grupos envolvidos na tomada de decisão, bem como os interesses e critérios que
movem cada um deles [GONÇALVES et al., 2006].
28
A escolha de um determinado curso de ação afeta os grupos envolvidos no processo
decisório, de forma e intensidade diferentes para cada um deles. Destaca-se, portanto, a
necessidade inerente de se considerar no processo todos os grupos de interesse, tanto os
envolvidos direta ou indiretamente na tomada de decisão, quanto os grupos afetados pelo
processo.
O crescimento da abordagem multicritério de apoio à decisão se deve ao fato de dar
ao grupo envolvido no processo de tomada de decisão, subsídios necessários para se obter
uma solução que melhor se ajuste às necessidades do grupo [BANA E COSTA, 1990].
A abordagem multicritério, de acordo com Bouyssou (1990), caracteriza-se pela
construção de vários critérios através da utilização de vários pontos de vista. Cada critério é
uma função matemática que mede performance das ações potenciais com relação a um
determinado aspecto. Os pontos de vista, por sua vez, representam os eixos através dos
quais os diversos atores de um processo de decisão justificam, transformam e questionam
as suas preferências, realizando comparações com base na avaliação das alternativas de
acordo com estes pontos de vista e estabelecendo, então, as preferências parciais.
Desta forma, as abordagens multicritério se constituem em formas de modelar os
processos de decisão, onde entram em jogo: uma decisão a ser tomada, os eventos
desconhecidos que podem afetar os resultados, os possíveis cursos de ação e os próprios
resultados. Estas abordagens refletem, de maneira suficientemente estável, o juízo de
valores dos decisores.
Estas abordagens foram desenvolvidas para problemas que incluem aspectos
qualitativos e/ou quantitativos, tendo como base o princípio de que a experiência e o
conhecimento das pessoas é pelo menos tão valioso quanto os dados utilizados para a
tomada de decisão [SCHMIDT, 1995].
Nota-se, por conseguinte, que a análise multicritérios leva em conta a subjetividade
dos atores [ROY e VANDERPOOTEN, 1996]. Por isso, a convicção da interconexão e
inseparabilidade dos elementos objetivos e subjetivos do contexto decisório, e a convicção
da aprendizagem e do construtivismo são consideradas por Bana e Costa (1992) como
características mais importantes das abordagens multicritério de apoio à decisão.
29
Através dos modelos multicritérios, o “decisor” poderá analisar as possíveis
implicações de cada curso de ação, de modo a obter uma melhor compreensão das
vinculações entre suas ações e seus objetivos [FLAMENT, 1999]. O desafio é identificar,
entre critérios conhecidos ou implícitos, quais são relevantes para o problema de decisão
[HENING e BUCHANAN, 2004].
Logo, sempre haverá a coexistência de aspectos subjetivos com aspectos objetivos,
uma categoria complementando a outra. Caso se considere a existência de apenas um dos
grupos citados, estar-se-á pressupondo que um deles possui relevância absoluta sobre o
outro. Não se pode afirmar, porém, a priori, qual desses dois grupos é mais fundamental
dentro do contexto analisado [BANA E COSTA, 1992].
Pode-se considerar que as partes subjetivas do modelo são as diversas opiniões
humanas que serão os critérios e que a parte objetiva são os cálculos realizados a partir de
um modelo de multicritério. As variáveis de decisão são as ações detalhadas, que devem ser
escolhidas e comunicadas.
A decisão do grupo será a combinação das preferências individuais, resultando,
portanto, em um intercâmbio de decisões entre seus membros, através da negociação das
propostas aceitáveis. Logo, se o acordo é obtido, elas são automaticamente pactuadas
[GOMES e MOREIRA, 1998].
Os resultados obtidos pela análise multicritério dependem do conjunto de ações
consideradas, da qualidade dos dados, da escolha e estruturação dos critérios, dos valores
de ponderação atribuídos aos critérios, do método de agregação utilizado e da participação
dos diferentes atores [SOARES, 2003].
É possível notar, portanto, o esforço em representar o mais fielmente possível as
preferências do “decisor” ou do grupo de “decisores”, mesmo que essas preferências não
sejam totalmente consistentes. Estes métodos, contudo, não visam apresentar uma solução
ao problema, elegendo uma única verdade representada pela ação selecionada. Na
realidade, eles buscam apoiar o processo decisório através da recomendação de ações ou
cursos de ações a quem vai tomar decisão.
Sendo assim, as metodologias multicritérios consideram mais de um aspecto e,
portanto, avaliam ações segundo um conjunto de critérios.
30
3.4 METODOLOGIAS MULTICRITÉRIO
Existe atualmente uma série de metodologias multicritérios. Todos, segundo Ensslin
(1998), com dois objetivos básicos. Por um lado visam auxiliar no processo de escolher,
ordenar ou classificar as ações potenciais. Por outro, buscam incorporar múltiplos aspectos
nesse processo, ao invés dos métodos monocritérios da pesquisa operacional tradicional.
Com o intuito de promover o melhor entendimento a respeito da abordagem
multicritérios, são apresentadas a seguir suas principais vertentes, a Multiple Criteria
Decision Making – MCDM e a Multiple Criteria Decision Aid – MCDA.
A Escola Americana, denominada Multiple Criteria Decision Making (MCDM)
caracteriza-se por fazer prescrições com referência a um ideal, procurando assim aproximar
o máximo possível deste. Tal ideal é baseado em um grupo de axiomas, os quais, se
examinados separadamente, podem ser aceitos naturalmente como normas ou hipóteses de
trabalho. Portanto, esta escola segue o caminho prescritivista, onde o facilitador faz uma
descrição do problema e compõe prescrições baseadas em hipóteses normativas, as quais
são validadas pela realidade descrita.
A Escola Européia, conhecida como Multiple Criteria Decision Aid (MCDA) busca
desenvolver recomendações nas quais o ideal de aproximação como uma entidade pré-
existente não presta um papel significante. Esta escola trabalha sob a abordagem
construtivista, onde se procura no decorrer do processo junto com os atores construir um
modelo mais ou menos formalizado que permitirá a evolução do processo de apoio à
decisão em concordância com os objetivos e o sistema de valores dos atores.
Dessa forma, a metodologia MCDA surgiu com o intuito de priorizar o fator
humano na análise de problemas complexos. Esta metodologia será utilizada para a
realização deste trabalho, e, desta forma, será detalhada a seguir.
3.4.1 A METODOLOGIA MCDA
A metodologia MCDA se caracteriza pela flexibilidade de permitir forte iteração do
modelo a ser construído com os tomadores de decisão e suas percepções da problemática
em estudo. A participação de todos os tomadores de decisão no processo de construção do
31
modelo é de fundamental importância para o aprofundamento das discussões, gerando
melhor compreensão do contexto decisório.
O MCDA pode lidar com qualquer tipo de problema complexo. A metodologia é
proposta a qualquer momento em que os decisores estejam incertos quanto ao caminho a
seguir ou a qualquer momento em que eles, os decisores, tenham interesses conflitantes.
Ele é capaz de organizar a complexidade, é capaz de incluir considerações
subjetivas e é capaz de sintetizar informações e julgamentos e uniformizar conhecimentos.
O método fornece uma abordagem estruturada para decisões complexas, considerando
dados quantitativos e julgamentos subjetivos e permite ao decisor obter um retrato gráfico
do problema na forma de uma hierarquia.
Para Vincke (1992), em situações complexas por natureza, o MCDA emerge como
uma evolução da Pesquisa Operacional, sendo informada por um novo espírito: o
reconhecimento dos limites da objetividade.
Diante de tal reconhecimento, esta metodologia enfatiza a idéia básica de atitude:
enquanto as abordagens tradicionais tentam dar solução ao problema, o MCDA enfatiza a
idéia da construção do problema, ou seja, enfoca a modelagem do contexto decisório,
através da consideração das convicções e valores dos atores envolvidos no processo
decisório. Esta modelagem permitirá a construção de um modelo de avaliação, com base no
qual se acredita que as decisões tomadas sejam as mais adequadas para o contexto em
questão [ROY e VANDERPOOTEN, 1996].
3.4.1.1 FASES DO MCDA
O processo desta atividade de ajuda à decisão consiste de três fases básicas,
diferenciadas, mas intrinsecamente correlacionadas: (1) a estruturação e definição do
problema; (2) a avaliação das ações potenciais; e, (3) a elaboração de recomendações,
conforme podemos ver na Figura 3.1.
32
Figura 3.1: Fases do MCDA [BANA e COSTA et al., 1999]
As fases (2) e (3) são conseqüência direta da fase (1), onde se dá a estruturação do
problema. Estas três fases serão detalhadas a seguir.
3.4.1.1.1 FASE DE ESTRUTURAÇÃO
A fase de estruturação consiste em uma fase de análise do sistema em estudo, que
conduz à identificação, caracterização e hierarquização dos principais atores intervenientes
e à explicitação das alternativas de decisão potenciais, alternativas estas que são
comparadas em termos de seus méritos e desvantagens relativas, dado um conjunto de
critérios de avaliação.
A estruturação é a fase mais importante da metodologia de apoio à decisão. As
contribuições que esta fase propicia como aprendizado, clareza, representatividade, entre
outros aspectos, através da definição e construção de um modelo que sirva como uma base
comum, onde os valores dos atores intervenientes possam ser validados, são sem dúvida
fundamentais para o auxílio a um processo decisório.
Essa fase visa a construção de um modelo formalizado, capaz de ser aceito pelos
atores como uma estrutura de representação e organização de todo um conjunto de critérios
para avaliação.
33
Dessa forma, uma primeira preocupação com que o decisor se confronta é entender
bem “o que o problema é”, sob a perspectiva dos atores envolvidos em uma determinada
situação [ENSSLIN et al., 1997].
A literatura sobre o assunto, [ROY, 1985], [ROSENHEAD, 1989] e [BANA E
COSTA et al., 1999], permite a verificação de diversas definições e formas de conduzir a
atividade de estruturação. Uma das principais e mais utilizada é a estruturação por Pontos
de Vista (PV).
Para Bana e Costa (1992), considera-se como Ponto de Vista os aspectos que
reúnem características e/ou objetivos, percebidos como importantes pelo decisor, para a
construção de um modelo de avaliação de ações existentes ou construídas. Esses aspectos
são conseqüência do sistema de valores do decisor ou mesmo de sua estratégia de
intervenção no processo decisório e agrupa elementos primários de avaliação, que
interferem de forma ativa na formação de suas preferências.
A estruturação corresponde a identificar progressivamente, de forma interativa, os
pontos de vista onde se ligam e se agrupam estes elementos inicialmente dispersos e, então,
definir-se quais são os Pontos de Vista Fundamentais (PVF).
Souza (1999) afirma que, para chegar à definição dos pontos de vista a serem
considerados para a estruturação de um problema, é necessário que os aspectos a serem
considerados e o próprio problema estejam, de alguma forma, expressos de acordo com a
percepção do decisor.
Existem outras técnicas de definição e estruturação de problemas, como os trabalhos
de Checkland (1985), os Métodos de Estruturação de Problemas – PMS, com cinco
desencadeamentos, ou ainda o método do Mapeamento Cognitivo [ÉDEN et al., 1983]. O
desenvolvimento detalhado das mesmas, no entanto, não é objeto do presente trabalho.
3.4.1.1.2 FASE DE AVALIAÇÃO
A fase de avaliação consiste em esclarecer a escolha, recorrendo à aplicação de
métodos multicritérios para apoiar a modelagem das preferências dos atores e a sua
34
agregação, ou seja, dar condições ao decisor para fazer uma escolha entre ações que tenham
conseqüências mensuráveis, segundo diversos pontos de vista.
As conseqüências de uma ação são expressas segundo uma lista de níveis de
impacto sobre os descritores correspondentes aos diversos pontos de vista. Esta fase está
dividida em: avaliação parcial das ações, segundo cada ponto de vista (avaliação local) e
agregação das várias avaliações parciais, denominada avaliação global.
Desta forma, são construídas as matrizes de juízos e obtidas as escalas de valor
cardinal para cada um dos critérios já definidos. Posteriormente são calculadas as taxas de
substituição, responsáveis por determinar o grau de importância dado a cada ponto de vista
para a obtenção das preferências globais. A partir destes resultados, é possível se realizar
uma análise das ações potenciais, permitindo que sejam feitos, quando necessários, ajustes
que traduzam os julgamentos de valor dos decisores.
A tarefa de construção das escalas será implementada através da metodologia
MACBETH, desenvolvida por Bana e Costa e Vansnick em 1994 [BANA E COSTA e
VANSNICK, 1994].
3.4.1.1.3 FASE DE RECOMENDAÇÃO
A fase de recomendação procura fornecer subsídios aos decisores, para que estes
tenham condições de aperfeiçoar cada alternativa e de analisar qual o conjunto de
alternativas que mais contribui para a organização como um todo.
Nesta fase são feitas análises de sensibilidade e robustez para verificar se mudanças
nos parâmetros do modelo de avaliação interferem no resultado final. É uma fase
fundamental que contribui para gerar conhecimento sobre o problema e, assim, aumentar a
confiança do decisor nos resultados obtidos [DIAS et al., 1997].
3.5 MACBETH
O MACBETH é uma metodologia de apoio à tomada de decisão que permite avaliar
opções levando em consideração múltiplos critérios. Foi desenvolvido por Carlos Bana e
Costa e Jean Claude Vansnick na década de 90. Permite representar numericamente os
35
julgamentos dos decisores sobre a atratividade global das ações, unindo a representação
numérica da informação, com os critérios.
O MACBETH é abordado através de uma ferramenta que possui parâmetros claros,
de fácil interpretação, além de ser humanista, interativo e construtivista [BANA E COSTA
e VANSNICK, 1994]. Assim sendo, decidiu-se em aplicá-lo neste trabalho.
A distinção fundamental entre o MACBETH e outros métodos de análise de decisão
com múltiplos critérios é que o MACBETH requer apenas julgamentos qualitativos sobre
as diferenças de atratividade entre elementos, para gerar pontuações para as opções em cada
critério e para ponderar os critérios. Sete categorias semânticas de diferença de atratividade
são introduzidas no MACBETH: diferença de atratividade nula, muito fraca, fraca,
moderada, forte, muito forte e extrema. Daí a origem do nome da abordagem MACBETH:
“Measuring Attractiveness by a Category Based Evaluation Technique” (Medir a
Atratividade por uma Técnica de Avaliação Baseada em Categorias) [M-MACBETH,
2005].
À medida que os julgamentos qualitativos são expressos pelo avaliador e
introduzidos no MACBETH, o software verifica automaticamente a sua consistência e
oferece sugestões para resolver eventuais inconsistências. Depois, o processo MACBETH
de apoio à decisão evolui para a construção de um modelo quantitativo de avaliação. A
partir de julgamentos do avaliador e utilizando as funcionalidades do software, escalas de
pontuações em cada critério e pesos relativos para os critérios são gradualmente sugeridos e
discutidos. Em seguida, uma pontuação global é calculada para cada opção, fazendo a soma
ponderada das suas pontuações nos múltiplos critérios. Essa pontuação global reflete a
atratividade da opção respectiva no conjunto de todos os critérios.
Diversas análises de sensibilidade e de robustez dos resultados do modelo, assim
construído, permitirão compreender o problema em profundidade, ajustar o modelo e
formar convicções sobre as prioridades a estabelecer ou as ações a selecionar, em contextos
de tomada de decisão individual ou em grupo. O MACBETH oferece numerosas
representações gráficas que facilitam a elaboração de um relatório justificando
recomendações elaboradas [M-MACBETH, 2005].
36
Conforme o MACBETH (BANA E COSTA e VANSNICK, 1995; M-
MACBETH, 2005), a avaliação do MCDA deve ser vista como um pacote das seguintes
atividades a serem realizadas:
• Caracterização do contexto da decisão.
• Definição de critérios e ações.
• Construção do descritor de impacto de cada critério.
• Definição dos pesos para “bom” e para “neutro”.
• Avaliação de cada critério.
• Cálculo do valor do critério.
• Análise de sensibilidade nos resultados.
• Resultado final.
Estas atividades serão detalhadas a seguir.
3.5.1 CARACTERIZAÇÃO DO CONTEXTO DA DECISÃO
Essa caracterização consiste na identificação dos atores relacionados ao contexto de
decisão e na contextualização de todo o problema.
3.5.2 DEFINIÇÃO DE CRITÉRIOS E AÇÕES
É necessária a identificação e a estruturação de critérios do problema (BANA E
COSTA, 1992). Cada critério consiste em um Ponto de Vista Fundamental (PVF) dentro de
um grupo de opções de decisão que deve ser inserido em uma estrutura denominada árvore
de valores e ações. Na estruturação dos critérios, é importante identificar também os
subcritérios relacionados (Ponto de Vista Elementar - PVE), para um melhor detalhamento
e entendimento dos critérios analisados.
Já a definição das ações consiste na elicitação dos aspectos-chave para a escolha das
decisões, os quais devem ser comuns a todos os critérios.
37
3.5.3 CONSTRUÇÃO DO DESCRITOR DE IMPACTO DE CADA CRITÉRIO
Souza (1999) apresenta os descritores como sendo um conjunto de níveis de
impacto que sirvam como base para descrever impactos plausíveis das ações potenciais em
termos de cada PVF. Cada nível de impacto corresponde a um certo “grau de urgência” da
necessidade da decisão. Este grau de urgência é, posteriormente, traduzido em uma escala
de pontuação.
Um critério (ou subcritério) está associado a um descritor de impacto. Assim, faz-se
necessário identificar os fatores de impacto relacionados àquele critério. Além disso, é
necessário que cada descritor não seja ambíguo, ou seja, tenha em cada nível seu
significado claro e que também seja distinto dos descritores dos demais Pontos de Vista
Fundamentais.
Um descritor, segundo Ensslin et al. (2001), pode ser direto, indireto e construído,
além de qualitativo ou quantitativo, discreto ou contínuo, conforme ilustrado na Figura 3.2.
Figura 3.2: Tipos de Descritores [THOMAZ, 2005]
38
O descritor que expressa uma medida numérica própria, clara e objetiva é conhecido
como descritor direto. Quando o descritor relaciona-se ao PV através de uma propriedade
ou de um evento dependente, ele é chamado de indireto. Já, um descritor é dito construído
quando um determinado ponto de vista não pode ser representado por um descritor direto
único. Por outro lado, os descritores quantitativos descrevem numericamente, direta ou
indiretamente, os níveis de impacto de uma ação, enquanto que os qualitativos não
apresentam uma forma numérica para essa descrição. Finalmente, deve ser destacado que
os descritores diretos quantitativos podem, ainda, ser contínuos ou discretos, quando
apresentam ou não, respectivamente, níveis de valores intermediários aos apresentados
diretamente pelo descritor.
Como forma de esclarecer os tipos de descritores, a Figura 3.3 mostra alguns
exemplos de descritores.
Figura 3.3: Classificação e exemplos de descritores [VASCONCELLOS, 2001]
39
Em resumo, o processo de escolha do tipo de descritores, e posteriormente, da sua
construção, é extremamente útil para a estruturação do problema. A escolha de um descritor
vai fazer com que apareçam novos valores, aumentando o grau de conhecimento do
problema. Assim, se em um primeiro grau de exigência, poderia parecer suficiente um
determinado tipo de descritor, à medida que o processo de estruturação vai avançando, é
provável que seja necessário uma maior formalização na construção dos níveis de impacto
de um descritor, de forma a tornar operacional o ponto de vista envolvido, possibilitando a
quantificação do modelo de valor dos atores e uma posterior avaliação das suas ações
potenciais.
3.5.4 DEFINIÇÃO DOS PESOS PARA “BOM” E PARA “NEUTRO”
Tendo sido construídos os descritores, é necessário, agora, definir em cada um deles
dois níveis de impacto de referência, o nível “BOM” (o melhor viável) e o nível
“NEUTRO” (o pior admissível) [ENSSLIN et al., 2001], conforme exemplificado na Figura
3.4.
Figura 3.4: Identificação dos Níveis de um Descritor Genérico
A definição desses pesos é importante, pois a experiência tem revelado que o
esforço requerido para identificar níveis bons e níveis neutros contribui significativamente
para a inteligibilidade do critério. Além disso, uma declaração explícita com respeito a
40
níveis bons e neutros de referência torna possível objetivar a noção de atratividade
intrínseca de cada proposta.
3.5.5 AVALIAÇÃO DE CADA CRITÉRIO
Depois de definida a escala de valores para cada critério, deve-se: (i) informar a
ordem de prioridade das ações para cada critério, (ii) comparar a “não-atratividade” dessas
ações duas-a-duas; e (iii) atribuir valores (0: nula, 1: muito fraca 2: fraca, 3: moderada, 4:
forte, 5: muito forte, e 6: extrema) a cada par.
O M-MACBETH permite a verificação visual da consistência, uma vez que na
matriz de julgamentos os valores de “diferença de atratividade” devem aumentar da
esquerda para a direita e de baixo para cima, devido a uma necessária ordenação antes dos
julgamentos. Desta forma, a cada valor atribuído, é verificada pelo M-MACBETH a
consistência da matriz e são sugeridas modificações, caso seja detectada alguma
inconsistência.
3.5.6 CÁLCULO DO VALOR DO CRITÉRIO
Após o completo preenchimento da matriz de cada critério, o M-MACBETH cria
uma escala numérica. Essa escala é então discutida, e, quando necessário, o facilitador
poderá alterar o valor de uma ação dentro do seu intervalo, de modo a garantir uma
adequada representação das ações para o critério avaliado.
Assim, esse processo deve ser repetido para todos os critérios existentes na árvore
de valores. À medida que este passo for concluído, o M-MACBETH gerará um histograma
com os valores de cada ação para o critério trabalhado.
3.5.7 ANÁLISE DE SENSIBILIDADE NOS RESULTADOS
A análise de sensibilidade é uma atividade que permite ao decisor analisar os efeitos
da variação dos seus julgamentos sobre o resultado da avaliação, identificando as ações
mais adequadas aos novos julgamentos. Isto faz com que o decisor tenha mais uma vez uma
visão mais ampla sobre o problema em questão tornando a sua decisão final cada vez mais
41
segura, à medida que é resultado de um profundo conhecimento do problema e das
alternativas das ações.
Além do histograma, o M-MACBETH fornece um gráfico onde se poderá fazer a
análise de sensibilidade das ações naquele critério, comparando as ações aos pares, a fim de
garantir o processo decisório.
Ele possibilita realizar, facilmente, uma análise de sensibilidade, que permite
verificar se a variação das importâncias tem impacto sobre a decisão recomendada,
alterando-a. Assim, é avaliada a estabilidade da decisão recomendada, com relação a
mudanças nas entradas do modelo (alteração dos pesos propostos para os critérios ou das
preferências pelas alternativas), o que é particularmente útil em situações de decisão em
grupo, em que se deseja obter consenso, mas também permite que o decisor individual
perceba a robustez de sua decisão.
3.5.8 RESULTADO FINAL
Finalmente, deve-se comparar os critérios na matriz de julgamento de critério e
solicitar à ferramenta a geração dos dados finais contendo o ranking final das ações.
A seção a seguir apresenta o Hiview, software utilizado para implementar as
atividades do MACBETH.
3.6 HIVIEW
O Hiview [BARCLAY, 1984] é um software que facilita bastante as análises sobre
problemas complexos. Ele permite que os decisores definam, analisem, avaliem e
justifiquem suas preferências com relação às alternativas existentes com base nos atributos
das alternativas. Auxilia a estruturação de um problema de uma forma simples,
especificando-se os critérios a serem utilizados na escolha entre as alternativas e atribuindo-
se a eles níveis de importância (pesos). As alternativas são avaliadas comparativamente
para cada critério e um valor de preferência é atribuído a cada uma delas, para cada critério.
Além disso, permite alterar julgamentos e comparar graficamente as respostas obtidas,
possibilitando ao decisor repensar e, se necessário, ratificar a decisão recomendada.
42
Outra finalidade da aplicação do Hiview [HIVIEW, 2008] consiste em realizar uma
análise da robustez do modelo. Esta análise consiste em verificar o comportamento do
desempenho das empresas à medida que se faz variar as taxas de substituição. Para um
modelo ser considerado robusto, deve-se atestar que para pequenas variações nas taxas de
substituição não devem existir grandes variações na avaliação final das ações.
Desta forma, o Hiview quando aplicado num processo de apoio à decisão, permite
avaliação de modelos obtidos através de metodologias multicritério que usam uma função
de agregação aditiva, como é o caso da metodologia MACBETH.
3.6.1 POR QUE UTILIZAR O HIVIEW?
A escolha de um método multicritério dentre os disponíveis, aplicado a um
determinado contexto, deverá se adequar às características da problemática em questão. Um
ponto importante é a avaliação da problemática, dos objetos de decisão e das informações
disponíveis. Segundo Bouyssou et al. (2000), a escolha do método deve ser resultado de
uma avaliação dos parâmetros escolhidos, do tipo e da precisão dos dados, da forma de
pensar do decisor, e do seu conhecimento sobre o problema. Ressalta-se ainda que a direta
conseqüência da possibilidade de escolha entre diversos métodos é que os resultados podem
ser discordantes e até mesmo contraditórios.
Ainda conforme Bouyssou et al. (2000), não se deve complicar a avaliação, uma
vez que as diferenças observadas estão muito mais relacionadas à diversidade de resultados
do que a contradições e que existem alguns critérios que permitem validar o método
escolhido. Na presente dissertação, a aplicação do método MACBETH enalteceu-se da
necessidade de avaliar a aceitação dos dados e o apoio do resultado no processo de decisão.
Questões secundárias como a existência de ferramentas como o
M-MACBETH e o HIVIEW também foram observadas, pois permitiram uma maior
integração com a problemática abordada. Desta forma, concordando com o que Ozernoy
(1992) salientou, a metodologia de apoio multicritério à decisão possui diversos métodos
que podem ser aplicados nos mais diversos problemas. Portanto, a própria escolha de um
método de apoio multicritério à decisão por si só já é um problema multicritério.
43
3.7 CONCLUSÃO
Este capítulo apresentou os conceitos fundamentais relacionados à Abordagem
Multicritério de Apoio à Decisão. O próximo capítulo apresenta algumas metodologias
existentes para Análise e Resolução de Causas.
Capítulo
4
Trabalhos Correlatos
“Aprendi na vida que a maioria dos problemas complexos tem
soluções simples."
ALCIDES TÁPIAS
4.1 INTRODUÇÃO
Este capítulo mostra algumas metodologias existentes para Análise e Resolução de
Causas. Desta forma, será apresentada a Metodologia para Análise e Solução de Problemas
- MASP, o Método das 8 Disciplinas – 8D e o Quality Control Story – QC Story.
4.2 METODOLOGIA PARA ANÁLISE E SOLUÇÃO DE PROBLEMAS - MASP
O MASP, Metodologia para Análise e Solução de Problemas, consiste em uma
seqüência de etapas que levam a um planejamento participativo para a melhoria da
qualidade de um produto ou serviço de determinado setor em uma organização. O MASP se
baseia na obtenção de dados que justifiquem ou comprovem fatos previamente levantados e
que comprovadamente causem problemas.
O método parte de uma situação detectada, cuja descrição identifica um problema,
primeiramente avaliado do ponto de vista de representar um desvio de desempenho ou uma
oportunidade de melhoria. Tratando-se de uma situação insatisfatória, a análise a ser feita é
essencialmente voltada para as descobertas das causas do desvio, ou seja, voltada para o
passado, para o levantamento de um histórico do processo e para o diagnóstico dos fatores
que afetaram eventos já ocorridos, ainda que os seus efeitos perdurem no presente. Ao se
analisar uma oportunidade de melhoria, a avaliação volta-se para o futuro.
45
O objetivo da análise de um desvio será a sua correção, enquanto o da análise de
uma oportunidade será a obtenção da melhoria pretendida. Portanto, em princípio, o
primeiro tipo de trabalho busca recuperar uma situação anterior ao desvio, conhecida e
controlada, ao passo que o segundo tipo busca explorar estratégias que conduzam a uma
situação melhor do que a presente, desconhecida e sujeita a riscos de avaliação. Dessa
forma, a decisão do primeiro caso ocorre sob condições de certeza e a do segundo é tomada
sob condições de risco e incerteza.
De acordo com Ando (1994), a idéia básica do MASP é:
• Pensar logicamente e usar evidências (dados) que apóiem a lógica.
• Entender a relação entre as causas e os resultados.
• Encontrar quais as causas que no processo são relevantes.
• Eliminar as causas relevantes no processo.
• Melhorar o resultado.
O MASP é dividido em várias etapas, conforme pode ser visto na Tabela 4.1.
Para auxiliar na execução das etapas, o MASP faz uso de diversas ferramentas, tais
como: brainstorming, multivotação, histogramas, cartas de controle, entre outras. No
entanto, não é obrigatório o uso de tais ferramentas, apenas são dadas sugestões de quais
podem ser utilizadas na execução de cada fase.
46
Tabela 4.1 – Etapas do MASP
4.3 MÉTODO DAS 8 DISCIPLINAS - 8D
O método das 8 disciplinas (8D) foi idealizado pela empresa Ford Motors para a
resolução de problemas quando a causa é desconhecida. Como processo para a solução de
problemas é uma seqüência de ações que devem ser seguidas desde o momento que se
identifica a existência de um problema [FORD, 1999].
O processo de resolução de problemas consiste em uma seqüência de fases, que
deverão ser seguidas a partir do momento em que o problema se torne evidente. Essas fases
(quando executadas corretamente) permitem que o problema seja resolvido no mais curto
47
espaço de tempo. Esta metodologia, baseada em fatos, permite que todo o processo de
planejamento, de decisão e de resolução do problema seja feito de forma sustentada,
garantindo desta maneira que o problema seja efetivamente resolvido.
O método, na sua totalidade deverá ser usado quando:
• A causa do problema é desconhecida.
• A resolução do problema está além das capacidades duma só pessoa.
• A gravidade do problema exige que haja uma equipe envolvida.
As oito etapas do método estão descritas na Tabela 4.2.
Tabela 4.2 – Etapas do 8D
48
4.4 QUALITY CONTROL STORY – QC STORY
O Quality Control Strory - QC Story, tem origem nas atividades dos círculos de
controle da qualidade (CCQs), em meados da década de 60, no Japão e atualmente existem
diferentes apresentações para o QC Story. Conforme a estrutura descrita por Campos
(1992), o QC Story apresenta as seguintes etapas, como pode ser visto na Tabela 4.3.
Tabela 4.3 – Etapas do QC Story
49
4.5 CONSIDERAÇÕES SOBRE AS METODOLOGIAS APRESENTADAS
Para cada tipo de problema, existe uma série de metodologias que podem ser
utilizadas.
De acordo com Paris (2003), O MASP, o QC-Story e as Oito Disciplinas (8D) são
metodologias abertas que tratam dos problemas do dia a dia da indústria. Geralmente são
empregadas no tratamento de não conformidades apresentadas pelos processos. Ao citar
uma metodologia de solução de problemas como estas, fica implícita a questão do Controle
de Qualidade que visa essencialmente planejar a qualidade para o estabelecimento de
padrões para a satisfação do cliente, manter a qualidade através da manutenção dos padrões
e de melhorar a qualidade dos produtos e serviços.
Este aprimoramento está ligado à redução da variabilidade do processo. Controlar o
processo significa manter as variações provocadas por causas comuns inerentes ao processo
em estudo. No entanto, muitas vezes as empresas não conseguem atingir suas metas de
qualidade com a utilização das metodologias apresentadas anteriormente. Segundo Paris
(2203), alguns autores discutem a aplicabilidade de metodologias que utilizem técnicas
específicas como as ferramentas japonesas. Outros, ainda, questionam a respeito da
adaptação de técnicas importadas neste processo de análise de problemas. Quando se trata
de problemas complexos, nem sempre é simples se chegar a uma única causa. Isto pode ser
agravado pelo tamanho da empresa e número de variáveis associados ao problema
dificultando ao time a identificação das causas.
A abordagem proposta nesta dissertação é focada para organizações de Tecnologia
da Informação, tomando como base categorias de problemas (pessoas, processos,
tecnologia e organização) características de organizações de TI. Além disso, suas etapas
mostram exatamente quais ferramentas e técnicas utilizar, agregando também modelos de
documentos a serem usados. Adicionalmente, faz uso da metodologia multicritério de apoio
à decisão, tornando a tomada de decisão mais objetiva.
Esses são alguns fatores que tornam a proposta desta dissertação um diferencial com
relação às metodologias citadas anteriormente.
50
4.6 CONCLUSÃO
Este capítulo apresentou a Metodologia para Análise e Solução de Problemas -
MASP, o Método das 8 Disciplinas – 8D e o Quality Control Story – QC Story . O próximo
capítulo apresenta a proposta desta dissertação, que consiste numa abordagem para análise
e resolução de causas de problemas em organizações de software aplicando multicritério.
Capítulo
5
Abordagem para Análise e Resolução de Causas de
Problemas Aplicando Multicritério
"O problema não é que existem problemas. O problema é esperar
que seja de outra forma e pensar que ter problemas é um
problema.”
THEODORE RUBIN
5.1 INTRODUÇÃO
Este capítulo aborda, em detalhes, uma abordagem para análise e resolução de
causas de problemas em organizações de software aplicando multicritério, objeto desta
dissertação. Desta forma, apresenta a descrição da abordagem e suas fases com os
respectivos passos e subpassos.
5.2 DESCRIÇÃO DA ABORDAGEM
Ao contrário de outras metodologias para resolução de problemas como Triz
[ALTSHULLER, 1999] e RCA (Root Cause Analysis) [AMMERMAN, 1998] que focam
apenas na eliminação do problema em si, a abordagem proposta concentra-se desde a
definição do problema até o controle dos resultados obtidos no decorrer do tempo. Seu foco
consiste em problemas complexos, que exigem uma análise mais criteriosa devido às suas
características [GONÇALVES et al., 2008].
Desta forma, foi estruturada de maneira a auxiliar os gestores a solucionar
problemas complexos, ao mesmo tempo em que cria uma rotina padronizada na solução de
problemas no contexto organizações de software tratando o tema através de um processo
adequado de análise, e fornecendo aos mesmos meios para:
52
• Planejar a análise das causas e solução do problema.
• Descobrir as causas mais prováveis dos problemas.
• Definir as possíveis soluções.
• Implementar as soluções propostas.
• Verificar a eficácia das soluções implementadas.
• Eliminar a reincidência de um determinado problema.
• Compartilhar os resultados obtidos.
• Proporcionar aprendizagem organizacional.
Como conseqüência da execução desta abordagem espera-se ter: melhoria na gestão
dos projetos, melhoria na comunicação e elevação das habilidades pessoais para resolução
de problemas, eficácia no tratamento de problemas complexos, dentre outras.
De maneira a auxiliar as equipes a solucionar os problemas colocando este assunto
dentro de uma metodologia reconhecida mundialmente por promover a melhoria contínua,
a estrutura da abordagem utiliza o ciclo PDCA definido por Deming.
Cada fase do ciclo PDCA está estruturada através de passos e subpassos que
descrevem o que deve ser feito, conforme podemos ver na Tabela 5.1.
53
Tabela 5.1 – Passos da Abordagem
PDCA Passos
Passo P1 - Descrever o Problema
Passo P2 - Formar a Equipe
Plan
Passo P3 - Definir Objetivos e Metas
Passo D1 - Determinar as Causas do Problema
- Subpasso D1.1: Investigar as Causas Potenciais do Problema
- Subpasso D1.2: Consolidar os Resultados
- Subpasso D1.3: Identificar as Causas Elementares
- Subpasso D1.4: Construir os Descritores e Identificar os Níveis
“Bom” e “Neutro”
- Subpasso D1.5: Avaliar as Causas
- Subpasso D1.6: Analisar os Resultados
Passo D2 - Analisar as Possíveis Soluções
Do
Passo D3 - Elaborar e Executar o Plano de Ação
Check
Passo C1 - Acompanhar e Avaliar os Resultados
Passo A1 - Divulgar os Resultados
Act
Passo A2 - Incorporar as Lições Aprendidas
As fases da abordagem proposta que requerem um maior esforço são as de
Planejamento (P) e Execução (D), por serem as fases mais críticas e que possuem um maior
grau de complexidade.
5.3 FASES DA ABORDAGEM
Nesta seção serão detalhadas as fases da abordagem proposta com seus respectivos
passos e subpassos.
Tabelas resumo dos passos da abordagem e modelos de documentos para auxiliarem
a sua execução encontram-se no Apêndice A e Apêndice B, respectivamente.
54
5.3.1 PLANEJAR (PLAN)
O objetivo desta fase é realizar o planejamento para o problema em questão. O
problema e suas características são descritos, a equipe é formada e, os objetivos e as metas
a serem alcançados são definidos.
A seguir, são descritos os passos que implementam esta fase.
5.3.1.1 PASSO P1: DESCREVER O PROBLEMA
O primeiro passo desta abordagem consiste na definição do problema que será
tratado, com um breve histórico mencionando quando o mesmo começou a acontecer,
freqüência de ocorrência, o que ele afeta (características da qualidade, custos, prazos, etc.),
entre outras informações relevantes, para que esteja claro o quanto a resolução deste
problema é importante para a organização [GONÇALVES et al., 2007].
A clara definição do problema é um dos pontos mais importantes e, freqüentemente,
um dos mais negligenciados. Segundo Albuquerque (2008), um dos erros mais comuns que
se comete ao se defrontar com problemas é saltar rapidamente para as ações. Problemas
mal definidos podem sugerir soluções que não são as adequadas ou que não agregam valor
à organização.
Escrever o problema com o maior detalhe possível evita diferentes interpretações.
Além disso, deve-se ter em mente que a definição cuidadosa do problema proporcionará a
matéria prima para a identificação bem sucedida das suas causas.
De acordo com Arioli (1998), deve-se destacar na descrição do problema os dados,
os fatos que mostrem falhas no projeto, os sintomas de desempenho insatisfatório e outros
fatores que possam ser considerados essenciais para a compreensão das causas ou,
alternativamente, para avaliação do custo-benefício.
Antes de serem executados os passos seguintes, é importante que seja feita uma
consulta na base histórica organizacional, com o intuito de verificar se problemas similares
já foram tratados em outros projetos. Desta forma, caso seja identificado algum problema
semelhante, ele servirá de apoio para as fases seguintes. Esta tarefa pode agregar muito no
tratamento do problema em termos de conhecimento e agilidade.
55
Da mesma forma, também é importante descrever qual o impacto ou conseqüências
do problema caso o mesmo não venha a ser corrigido. Esta descrição deve estar focando
somente nos sintomas e não em causas ou soluções. Também devem ser descritas as
restrições para tratamento do problema, tais como tempo, recursos, custos, entre outros.
A fonte do problema deve ser identificada, podendo ser mais que uma. Exemplos de
fontes de problemas em organizações de software são:
• Resultados de pesquisas de satisfação com o cliente.
• Reclamações do cliente.
• Indicadores.
• Resultados de estudos de benchmarking.
• Resultados de avaliações da qualidade.
A organização pode pré-definir as principais fontes dos problemas com o intuito de
facilitar, padronizar e agilizar a sua classificação.
Geralmente, ao analisar problemas, as pessoas relacionam imediatamente o
problema a uma categoria. No entanto, no âmbito de problemas complexos que possuem
várias causas associadas, o problema pode pertencer a várias categorias, e as mesmas
devem ser investigadas em detalhes.
Na literatura encontramos diversos tipos de categorias de causas de problemas,
[CARD, 2005], [ENDRES, 1975], [HAYES, 2006], no entanto, a grande maioria é
adequada para o contexto de indústrias, diferente do contexto das organizações de software.
No que se refere às causas dos problemas relacionados a organizações de software,
existe uma categorização proposta por Jalote e Agrawal (2005), que classifica as causas dos
problemas da seguinte forma: processos, pessoas e tecnologia. Eles mencionam que estes
são os fatores com o maior impacto na qualidade e produtividade.
De forma a complementar esta categorização em organizações de software, Jacobs
et al. (2004) acrescenta a categoria “organização”. Esta categoria está relacionada a causas
de problemas organizacionais e não especificamente aos seus processos.
56
Sendo assim, a abordagem proposta fará uso das seguintes categorias de causas de
problemas:
• Pessoa: quando as causas do problema estão relacionadas diretamente com
as pessoas. Exemplos: falta de interesse, perfil inadequado, etc.
• Processo: quando as causas do problema estão relacionadas com o
processo/forma como a organização trabalha. Exemplos: falta de processo,
métodos e técnicas inadequados, etc.
• Organização: quando as causas do problema estão relacionadas com a
organização como um todo. Exemplos: políticas, cultura, infra-estrutura, etc.
• Tecnologia: quando as causas do problema estão relacionadas com os
recursos tecnológicos utilizados pela organização. Exemplos: falta de
ferramentas, apoio automatizado inadequado, etc.
Vale ressaltar que a organização pode incluir ou excluir outras categorias, caso
julgue necessário.
Nesta abordagem proposta, a categoria do problema será considerada como o Ponto
de Vista Fundamental (PVF) utilizado na metodologia multicritério.
É fundamental a participação das pessoas – conhecer o problema já é um grande
passo para a sua solução. Pessoas que sofrem impacto direto do problema podem fornecer
informações importantes sobre o mesmo, à medida que o visualizam sob ângulo diferente.
Desta forma, pode ser interessante ouvir a opinião de clientes, por exemplo.
Um modelo de documento para auxiliar a execução deste passo está disponibilizado
no Apêndice B - Modelo de Planejamento para o Problema.
5.3.1.2 PASSO P2: FORMAR A EQUIPE
Inicialmente, deve-se formar a equipe responsável pela análise e resolução do
problema, sendo representada pelo facilitador e decisores que atuarão em grande parte das
atividades. O owner deve ser identificado e deve fornecer os recursos e apoio necessário
para a equipe. Os envolvidos estarão presentes em alguns passos da abordagem podendo ser
57
selecionados no momento da execução dos mesmos. No Apêndice A (Tabelas Resumo dos
Passos da Abordagem) são identificados os responsáveis e envolvidos em cada passo da
abordagem.
A seguir, segue a descrição de cada papel participante nesse processo.
• Owner: é o “dono” do problema, o principal interessado na resolução do
mesmo, podendo ser representado por mais de uma pessoa. Seu papel é de
fundamental importância para o sucesso da abordagem, pois fornece os
recursos necessários e apóia sua execução.
• Facilitador: é o responsável pela condução de todo o ciclo de análise e
resolução das causas do problema. Deve deter grande conhecimento sobre a
abordagem, saber trabalhar em equipe, ter bom relacionamento interpessoal
e habilidades de raciocínio lógico. É, portanto, um ator do processo de
decisão, uma vez que ele nunca será neutro, apesar de esforçar-se para tal
[MONTIBELLER NETO, 1996].
• Decisor: é uma pessoa que possui grande conhecimento sobre o problema e
que está diretamente envolvida nas atividades relacionadas ao mesmo.
Participa geralmente dos passos que requerem tomadas de decisões. A
quantidade de decisores pode variar de uma a três pessoas, não sendo
aconselhável um número maior, pois dificulta o consenso e onera o processo.
• Envolvido: é qualquer pessoa que pode estar contribuindo de alguma forma
com informações sobre o problema. Geralmente possui participação
temporária, podendo ser convocado no decorrer dos trabalhos para atender a
situações pontuais.
Outros papéis podem ser definidos, de acordo com a estrutura da organização. É
fundamental o apoio do Owner neste passo uma vez que será necessário recursos
(geralmente tempo) para a execução das atividades bem como motivação e
comprometimento da equipe.
Selecionar o pessoal certo para integrar a equipe de análise e resolução de
problemas é considerado um fator de êxito para a execução da abordagem. As pessoas
58
devem ser informadas do porquê de terem sido incluídas (Ex: sua especialidade técnica,
conhecimento sobre o problema em questão ou experiência).
Ao formar a equipe, alguns fatores devem ser levados em consideração, tais como:
• Quem é afetado pelo problema.
• Quem dispõe de informações sobre o problema.
• Quem pode sugerir soluções.
• Quem dispõe de conhecimento técnico.
• Quem possui experiência sobre o assunto.
É importante que os indivíduos estejam motivados e entusiasmados por estarem
envolvidos. Além disso, todas as perspectivas sobre o problema devem ser consideradas
durante a formação da equipe, de modo que ações acordadas entre os mesmos não sejam
susceptíveis de serem interrompidas sob o argumento de que um determinado fator não foi
considerado na avaliação [GONÇALVES et al., 2007].
As percepções das pessoas são particulares e individuais, ou seja, a rigor, em um
mesmo problema, cada pessoa traz consigo diferentes pontos de vista, diferentes anseios e
desejos, de forma que a completa compreensão do problema emergirá do inter-
relacionamento destas visões divergentes.
Um modelo de documento para auxiliar a execução deste passo está disponibilizado
no Apêndice B - Modelo de Planejamento para o Problema.
5.3.1.3 PASSO P3: DEFINIR OBJETIVOS E METAS
Nesta etapa são definidos os objetivos e as metas a serem atingidos com a execução
da abordagem proposta para tratamento do problema em questão. Cada objetivo deve ser
fragmentado em metas. Uma meta,
geralmente, é o retorno às condições ideais anteriores à
ocorrência do problema.
Quando a fonte do problema é oriunda de um indicador já existente, as metas
geralmente já são definidas no mesmo. Caso não exista uma meta pré-definida, ou seja,
59
necessário adequá-la, pode ser realizado um Benchmarking para estudo e comparação da
prática de outras organizações.
Como um auxílio na validação da meta, pode-se usar a técnica SMART, fazendo-se
os seguintes questionamentos:
• “S” - A meta é específica? Metas genéricas não são “absorvidas” como
algo pelo qual valha a pena realmente se esforçar.
• “M” - A meta é mensurável? A meta precisa ser mensurada, para que
seja possível saber se realmente foi alcançada ou não. Do contrário,
como será possível saber se a mesma foi atingida?
• “A” - A meta é atingível? Deve-se ter o cuidado para não estabelecer
metas impossíveis de serem alcançadas no tempo determinado.
• “R” - A meta é relevante? Deve estar claro quais são os benefícios em
se atingir a meta. A relevância da meta é fundamental para gerar
entusiasmo, motivação para realizar a meta, para persistir diante das
dificuldades e para o comprometimento dos envolvidos.
• “T” - A meta é temporal? Significa que uma meta precisa ter tempo
definido de quando será realizada, para que você possa elaborar um
cronograma de ações que te ajudarão a realizar a meta no tempo
definido.
Caso a meta leve muito tempo para ser atingida, podem ser estabelecidas submetas
para facilitar e motivar no alcance da meta geral.
Um modelo de documento para auxiliar a execução deste passo está disponibilizado
no Apêndice B - Modelo de Planejamento para o Problema.
5.3.2 EXECUTAR (DO)
Nesta fase são conduzidas as atividades de acordo com o que foi planejado na fase
anterior. As causas potenciais do problema são investigadas, os resultados são
consolidados, as causas elementares são identificadas, são construídos os descritores para
60
os critérios e seus níveis “bom” e “neutro” são identificados, as causas são avaliadas e os
resultados analisados, as possíveis soluções para tratamento das causas são elicitadas e, o
plano de ação é elaborado e executado. A metodologia multicritério é abordada nesta fase
(Subpasso D1.3 ao Subpasso D1.6).
A seguir, são descritos os passos que implementam esta fase.
5.3.2.1 PASSO D1: DETERMINAR AS CAUSAS DO PROBLEMA
Este é um dos passos mais importantes da abordagem proposta, uma vez que seu
propósito é encontrar as causas fundamentais do problema. Caso esta atividade não seja
feita corretamente, o resultado pode ser comprometido, pois todas as atividades seguintes
terão como base o resultado deste passo [GONÇALVES et al., 2008].
Sendo assim, devem participar desta etapa pessoas que possuam conhecimento a
respeito do problema e que estejam diretamente envolvidas em atividades relacionadas ao
mesmo, de forma a contribuir com informações sobre suas causas.
À medida que as pessoas realizam as análises com mais detalhes, ou seja, quanto
mais precisa for a análise, maior a probabilidade de determinar quais são as causas
fundamentais do problema. No entanto, quanto mais acuradas as análises, mais onerosas
serão. Portanto, torna-se importante que seja identificado o nível de precisão adequado, isto
é, até que ponto a consideração de novas informações pode adicionar valor à decisão.
Esta atividade é composta pelos subpassos descritos a seguir.
5.3.2.1.1 SUBPASSO D1.1: Investigar as Causas Potenciais do Problema
Quando se tem um problema complexo, muitas podem ser as causas do mesmo. A
compreensão das causas é um passo fundamental para solucionar o problema.
Sendo assim, deve-se inicialmente fazer uma ampla exploração sobre as causas que
influenciam o problema, com a participação dos principais envolvidos no mesmo e a
utilização de técnicas apropriadas. Uma vez que problemas complexos envolvem várias
pessoas, com diferentes níveis hierárquicos e que possuem pontos de vista e expectativas
distintas, as técnicas mais apropriadas neste momento são aquelas em que as pessoas se
61
sintam à vontade para se expressarem, sem medo de repressão. Sendo assim, neste passo é
utilizada a técnica de brainstorming individual.
De fato, muitos indivíduos podem encontrar mais criatividade sozinhos do que
fazendo parte de um tradicional grupo de brainstorming. Além disso, a liberdade de estar
sempre disponível para um brainstorming individual é mais fácil de se atingir
[DAYCHOUM, 2007].
Segundo Parnes (1963), a técnica de brainstorming é mais eficaz se utilizada
individualmente do que em grupo. Isso sugere que há uma contribuição importante de cada
integrante do grupo, se cada um fizer seu processo individual de análise das causas do
problema em questão.
A escolha dos envolvidos no brainstorming deve abranger os diferentes papéis, de
forma a contemplar opiniões divergentes. Caso o número de pessoas diretamente
relacionadas ao problema seja muito grande, deve-se definir uma amostragem. Vale
destacar que, quanto mais idéias (causas identificadas), maior a chance de se encontrar a
solução do problema e maior será também o número de conexões e associações a novas
idéias e soluções [BRASSARD, 1994].
Neste momento, também podem ser solicitadas sugestões de soluções para as causas
identificadas aos envolvidos, principalmente quando a quantidade de pessoas incluídas na
amostragem for considerável, ficando difícil e custoso realizar um novo brainstorming.
Estas sugestões servirão de insumo para a execução do Passo D2 - Analisar as Possíveis
Soluções.
O brainstorming individual, utilizado nesta abordagem, deve fazer uso de diagramas
de causa e efeito, elencando os problemas de acordo com as categorias pré-definidas. Este
tipo de diagrama é bem simples e possui um efeito visual de fácil assimilação, e que, sem
dúvida, ajuda a sistematizar e separar adequadamente as causas dos efeitos [BRASSARD,
1994].
O papel do facilitador nesta atividade é de suma importância uma vez que o mesmo
será o responsável por contextualizar os envolvidos, bem como dirimir as eventuais
dúvidas. É fundamental que o facilitador não esteja em um nível hierárquico superior aos
envolvidos, de forma a não gerar qualquer tipo de intimidação.
62
Exemplos de causas comuns de problemas na área de software são citados por
diversos autores, tais como [HALL, 1995], [LESZAC et al., 2000], [FARIAS, 2002] e
ANDRADE [2005]. A Tabela 5.2 contém uma relação de causas citadas por tais autores,
agrupadas pelas categorias utilizadas nesta dissertação. Esta relação de causas pode servir
de base para dar início a este passo, podendo ser incrementada quando outras causas forem
identificadas, de forma a alimentar a base de conhecimento da organização.
Tabela 5.2 – Causas Comuns de Problemas em Organizações de Software por Categoria
Pessoas Processo Organização Tecnologia
Falta de treinamento Falta de processo
Falta de
políticas/diretrizes
Ferramentas
inadequadas
Falta de
habilidade/perfil Processo dúbio Falta de recursos
Inexistência de
ferramentas
Desmotivação Falta de planejamento
Falta de apoio da alta
direção
Indisponibilidade das
ferramentas
Falta de disciplina Processo burocrático
Alta rotatividade dos
funcionários
Apoio automatizado
inadequado
Falta de comunicação
Granularidade do
processo inadequada
Mudança dos
objetivos da
organização
Inexistência de
documentação de
ajuda
Volume de trabalho
excessivo
Métodos e técnicas
inadequados
Inexistência de
políticas de incentivo
ao uso do processo
Má gestão dos recursosResistência ao processo Dispersão geográfica
Falta de
comprometimento da
gerência/equipe
Responsabilidades mal
definidas
Responsabilidades
mal definidas
Falta de coordenação e
liderança nas
atividades
Estimativas de
custo/prazo irreais Cultura
Falta de um bom
relacionamento entre
os desenvolvedores e o
gerente
Não institucionalização
do processo
Falta de
sensibilização quanto
à importância
Equipes mal
dimensionadas
Ambiente físico
inadequado
Falta de infra-
estrutura
Modelos de documentos para auxiliarem a execução deste passo estão
disponibilizados no Apêndice B - Modelo de Diagrama de Causa e Efeito e Modelo de
Lista de Causas Potenciais.
63
5.3.2.1.2 SUBPASSO D1.2: Consolidar os Resultados
De acordo com Schmidt (1995), o método natural de funcionamento da mente
humana, quando se defronta com um grande número de elementos, controláveis ou não, que
abrangem uma situação complexa, é agregá-lo a grupos, segundo propriedades comuns, isto
é, quando o ser humano identifica alguma coisa, decompõe a complexidade encontrada,
quando descobre relações, sintetiza.
Desta forma, após ter sido realizado o brainstorming individual, o facilitador deverá
gerar uma lista das causas potenciais identificadas por categoria, e, em conjunto com os
decisores, deverá agrupar as causas repetidas (ou similares), quantificando o número de
vezes que a mesma foi identificada de forma a gerar, posteriormente, gráficos de Pareto.
O uso de gráfico de Pareto neste subpasso tem como objetivo determinar a
freqüência de ocorrência das causas identificadas, dando subsídios para que o próximo
passo utilize esta informação para determinação das causas elementares.
De acordo com a lei de Pareto, 80% dos problemas são causados apenas por 20%
das causas, ou seja, um grande número de problemas é resultado de um número
relativamente pequeno de causas [JURAN, 1974]. Vale ressaltar que o uso do gráfico de
Pareto é mais útil quando existem no mínimo 25 amostras de dados, o que geralmente é
obtido no caso de problemas complexos.
Dentre as causas citadas inicialmente, deve-se excluir as causas menos prováveis
tomando como base as informações levantadas. Caso necessário devem ser coletados dados
adicionais.
Um modelo de documento para auxiliar a execução deste passo está disponibilizado
no Apêndice B - Modelo de Gráfico de Pareto.
Os subpassos seguintes recorrem à aplicação de multicritério para apoiar na
modelagem das preferências dos envolvidos de forma a esclarecer as escolhas.
64
5.3.2.1.3 SUBPASSO D1.3: Identificar as Causas Elementares
Conforme mencionado no Passo P1- Descrever o Problema, as categorias do
problema são consideradas como os Pontos de Vista Fundamentais na abordagem proposta.
Desta forma, com os PVF definidos, com as causas identificadas, consolidadas e com os
gráficos de Pareto construídos, a equipe deve iniciar uma análise para identificação das
causas elementares do problema, ou seja, aquelas que mais contribuem para o mesmo
[GONÇALVES et al., 2008].
Como forma de auxiliar esta tarefa, deve ser construído um diagrama de causa e
efeito decorrente das causas consolidadas. O facilitador e os decisores devem destacar as
causas consideradas como elementares, de acordo com a experiência de cada um, para que
estas sejam utilizadas nas matrizes de juízo de valor. Recomenda-se que o número de
causas elementares selecionadas não seja maior que oito, de forma que as análises sejam
viáveis e não onerosas.
Neste subpasso deve-se ter o cuidado para não focar apenas nos resultados dos
gráficos de Pareto, uma vez que, uma causa pode ter sido identificada por apenas uma
pessoa, mas possui um alto impacto no problema.
Assim, tendo sido destacadas as causas elementares em cada categoria, deve ser
construída a árvore de pontos de vista onde devem ser identificados os Pontos de Vista
Fundamentais (PVFs) e os Pontos de Vista Elementares (PVEs), através do software
Hiview, de acordo com a metodologia multicritério.
5.3.2.1.4 SUBPASSO D1.4: Construir os Descritores e Identificar os Níveis “Bom” e
“Neutro”
Com os PVEs identificados, devem ser construídos os descritores de impacto. Os
descritores forneceram um melhor entendimento daquilo que representa a preocupação dos
decisores ao mensurar uma dimensão do contexto decisório. Esta etapa melhora a
comunicação entre as pessoas envolvidas no processo de tomada de decisão, cria melhores
alternativas e, torna possível a quantificação do modelo proposto.
65
Uma vez que os descritores tenham sido construídos, para cada um deles devem ser
definidos os níveis de impacto “bom” e “neutro”. A identificação destes níveis permite uma
maior inteligibilidade do descritor, e, conseqüentemente do ponto de vista que está sendo
avaliado. Com eles fica mais fácil, no processo decisório, identificar quais causas são
atrativas (aquelas que têm performance acima do nível neutro) e quais não são (com
desempenho abaixo deste mesmo nível). Já o nível bom demarca as ações que tem uma
performance acima das expectativas dos decisores [ENSSLIN et al., 2002].
Bana e Costa (1992) afirma que se não existe um descritor direto (ou natural), para
um ponto de vista, nada garante que um descritor indireto ou um construído vai ser único
ou que este seja minimamente suficiente ou “o mais” adequado para tornar este ponto de
vista operacional. Desta forma, caso a construção dos descritores não seja trivial para o
problema em questão, pela dificuldade em quantificar o PVE devido à subjetividade
inerente ao mesmo, este passo pode ser omitido.
5.3.2.1.5 SUBPASSO D1.5: Avaliar as Causas
O objetivo deste subpasso é comparar as várias causas dos problemas, a fim de
permitir a escolha mais consciente e mais adequada das causas que serão tratadas.
Desta forma, para cada critério (categoria) o facilitador e os decisores devem
construir as matrizes de juízo de valor, informar a ordem de prioridade das causas e fazer a
atribuição de valores (0: nula, 1: muito fraca, 2: fraca, 3: moderada, 4: forte, 5: muito forte,
e 6: extrema) para cada par, conforme a metodologia multicritério. Para obtenção dos pesos
dos critérios, também deve ser construída uma matriz de juízo de valor entre os mesmos.
Durante o preenchimento das matrizes, o facilitador e os decisores devem verificar a
sua consistência semântica, ou seja, supondo, por exemplo, que a diferença de atratividade
entre um nível A e um nível B seja “fraca” e que a diferença de atratividade entre os níveis
B e C seja “moderada”, a diferença de atratividade entre A e C não poderá ser “muito
fraca”. Tal consistência é verificada pelo software Hiview (que aplica o MACBETH na
etapa de avaliação do modelo), o qual analisa se as categorias dos juízos não decrescem da
esquerda para a direita em cada linha, nem crescem de cima para baixo em cada coluna.
66
Caso haja inconsistência nos julgamentos, o Hiview auxilia na identificação de
fontes de inconsistência e sugere modificações nos julgamentos iniciais. Estas modificações
deverão ser discutidas, de tal modo que mudanças nas categorias sejam feitas somente com
a concordância entre o facilitador e os decisores.
Garantida a consistência semântica, o software verifica se há consistência cardinal,
ou seja, se existe uma função critério cardinal capaz de representar os juízos expressos pelo
avaliador. Caso positivo, uma escala de atratividade cardinal é proposta. Caso contrário,
uma revisão dos juízos de valor deve ser realizada.
5.3.2.1.6 SUBPASSO D1.6: Analisar os Resultados
Neste subpasso várias análises podem ser realizadas para apoiar na avaliação dos
resultados, dentre elas, destacam-se:
•
Análise de Sensibilidade: nesta análise tanto são identificadas as variações
no valor total atribuído às ações quanto as conseqüências destas variações
podem ser analisadas. Isto porque, em alguns casos, pequenas variações nas
taxas de substituição, inicialmente calculadas, podem vir a apontar uma nova
ação como a mais adequada.
Cabe ao facilitador assegurar que o decisor tenha
conhecimento da influência da variação destes julgamentos no resultado da
avaliação, fazendo com que a decisão que este venha a tomar seja resultado de
um conhecimento mais profundo do problema e das alternativas de ação.
• Mapas Comparativos: neste tipo de análise as causas potenciais são
alocadas e os resultados das causas dominantes e dominadas são
intrinsecamente relacionados às taxas de substituição definidas pelo
avaliador. Assim, as ações localizadas na fronteira do gráfico são as que
teoricamente são as mais adequadas. Isto porque não se pode descartar
nenhuma delas, pois as posições destas causas serão reflexo da importância
relativa atribuída aos vários pontos de vista.
•
Análise de Robustez: a
robustez é um conceito que se refere à sensibilidade
de uma decisão em relação às incertezas que fogem ao controle dos decisores.
Dessa forma, uma decisão robusta não é facilmente afetada por mudanças em
67
fatores externos [THOMAZ, 2000]. A análise de robustez caracteriza-se, assim,
por analisar todos coeficientes de ponderação dos pontos de vista ao mesmo
tempo, contrariamente à análise de sensibilidade que, por sua vez, faz variar o
coeficiente de ponderação de um ponto de vista mantendo os restantes
constantes.
Por fim, deve-se analisar o resultado final a partir dos dados gerados pela
ferramenta, observando o ranking das categorias utilizadas, com o intuito de saber qual
merece mais atenção.
Vale destacar que compete aos decisores a escolha final das causas a serem tratadas.
O facilitador se preocupa tão somente em assegurar o perfeito entendimento do problema
por parte dos decisores e a repercussão dos possíveis cursos de ação.
5.3.2.2 PASSO D2: ANALISAR AS POSSÍVEIS SOLUÇÕES
Uma vez definidas as principais causas, é necessário analisar as possíveis soluções
com o intuito de tratar o problema. Algumas sugestões de soluções já foram feitas durante o
Passo D1.1 e servirão de insumo para este passo. Desta forma, estas sugestões devem ser
analisadas e mapeadas às causas priorizadas como forma de facilitar a análise.
Podem ser realizadas pesquisas na literatura, benchmarking e entrevistas com
pessoas chave de forma a auxiliar os decisores, uma vez que estes devem fazer um
brainstorming de idéias para que sejam levantadas as possíveis soluções que venham tratar
o problema em questão.
Em situações onde são identificadas muitas soluções e onde os pontos de vista dos
decisores são divergentes, podemos estar diante de outro problema complexo (escolha da
solução). Desta forma, pode ser necessário que o Passo D1 – Determinar as Causas do
Problema seja realizado novamente, só que desta vez não mais com o objetivo de
“Determinar as causas do problema”, mas sim, de “Determinar as soluções a serem
implementadas”.
Ao realizar a análise das soluções, alguns critérios devem ser levados em
consideração, tais como:
68
• Viabilidade de execução da ação: é possível que a solução seja
implementada?
• Aceitação dos decisores: os decisores estão de acordo com a
implementação da solução?
• Impacto: qual o impacto e conseqüências que a implementação da solução
irá causar?
• Custo: o custo para implementação da solução é viável para a organização?
• Tempo para execução: quanto tempo levará a implementação da solução?
• Riscos: quais são os riscos que a implementação desta solução pode causar?
Vale ressaltar que as soluções selecionadas devem eliminar as causas do problema
ou minimizar sua influência sob o efeito indesejado.
Um modelo de documento para auxiliar a execução deste passo está disponibilizado
no Apêndice B - Modelo de Lista de Sugestões de Solução
5.3.2.3 PASSO D3: ELABORAR E EXECUTAR O PLANO DE AÇÃO
Após terem sido definidas as soluções a serem executadas, um plano de ação para
execução das mesmas deve ser elaborado pelo facilitador com apoio dos decisores e
conseqüente aprovação do(s) owner(s).
O plano de ação consiste num conjunto de ações que visam tratar as causas do
problema. Para isto, deve-se verificar se tais ações são para sanar as causas fundamentais e
não seus efeitos, e se as ações não trazem nenhum efeito.
Através da utilização de um plano de ação é possível identificar as ações e as
responsabilidades pela sua execução, entre outros aspectos. De acordo com Oliveira (1996)
todo plano de ação deve estar estruturado para permitir a rápida identificação dos elementos
necessários à implementação do projeto.
Estes elementos básicos podem ser descritos pelo que se convencionou chamar
5W1H. Um plano de ação 5W1H permite considerar todas as tarefas a serem executadas ou
selecionadas de forma cuidadosa e objetiva, assegurando sua implementação de forma
69
organizada. Cada ação deve ser especificada levando-se em consideração os seguintes itens
[OLIVEIRA, 1996]:
• Why – Por que deve ser executada a tarefa (justificativa).
•
What
– O que será feito (etapas).
•
Where
– Onde cada tarefa será executada (local).
•
When
– Quando as tarefas serão realizadas (datas).
•
Who
– Quem realizará as tarefas (responsabilidade).
•
How
– Como deverá ser realizada cada tarefa (método).
Desta forma, esta abordagem faz uso da estrutura acima citada como forma de
apoiar na elaboração e execução do plano de ação.
Um modelo de documento para auxiliar a execução deste passo está disponibilizado
no Apêndice B - Modelo de Plano de Ação.
5.3.3 CONTROLAR (CHECK)
Nesta fase é realizado o acompanhamento do plano de ação e, a avaliação dos
resultados obtidos de forma a verificar se os objetivos e metas estabelecidos foram
atingidos.
A seguir, é descrito o passo que implementa esta fase.
5.3.3.1 PASSO C1: ACOMPANHAR E AVALIAR OS RESULTADOS
Neste passo devem ser monitorados os resultados obtidos com a execução das ações
para que se tenha uma visibilidade do avanço do processo de resolução do problema e, ao
término da execução do plano de ação, deve-se avaliar se os objetivos e metas foram
atingidos. Para isto, deve-se comparar os dados coletados antes e após a execução do plano
de ação e analisar os resultados obtidos, bem como se ocorreram efeitos secundários. O
resultado das análises deve ficar documentado em um relatório, se possível, fazendo uso de
indicadores.
70
Se a ação não tiver surtido o efeito esperado, deve-se retornar para o Passo D3 –
Elaborar e Executar o Plano de Ação (quando não eliminou as causas) ou para o Subpasso
D1.3 – Identificar as Causas Elementares (quando eliminou a provável causa, mas os
efeitos ainda permanecem).
Na avaliação dos resultados obtidos deve ser feita uma análise se a meta
estabelecida na fase “Planejar” foi atingida, bem como uma análise do custo-benefício do
tratamento do problema utilizando a abordagem proposta.
Deve-se acompanhar os resultados ao longo de algum tempo para verificar se a
solução atuou sobre o problema, impedindo a recorrência do mesmo ou se melhorou os
índices de desempenho conforme definido na meta. Os dados do problema obtidos antes e
depois da execução das ações devem ser comparados em um mesmo formato (tabelas,
gráficos, diagramas, etc).
É importante que sejam feitas reflexões sobre todo o processo e que sejam
levantadas questões que auxiliarão no aperfeiçoamento contínuo da abordagem.
Um modelo de documento para auxiliar a execução deste passo está disponibilizado
no Apêndice B - Modelo de Relatório de Acompanhamento e Avaliação.
5.3.4 AGIR (ACT)
Nesta fase os resultados obtidos são divulgados e as lições aprendidas são
disseminadas e incorporadas aos ativos organizacionais.
A seguir, são descritos os passos que implementam esta fase.
5.3.4.1 PASSO A1: DIVULGAR OS RESULTADOS
É de suma importância que ao final da execução da abordagem proposta, sejam
divulgados os resultados obtidos bem como as lições aprendidas com toda a organização.
O compartilhamento destas informações pode servir de insumo para o tratamento de
problemas similares em outros projetos, de forma a agir proativamente. Devem ser
divulgados até mesmo os problemas não solucionados e as metas não atingidas com as
devidas análises.
71
Um modelo de documento para auxiliar a execução deste passo está disponibilizado
no Apêndice B - Modelo de Relatório de Resultados.
5.3.4.2 PASSO A2: INCORPORAR AS LIÇÕES APRENDIDAS
Com os resultados da execução da abordagem deve-se fazer uma análise das lições
aprendidas identificadas e, avaliar a necessidade de alterações nos processos da
organização, nas diretrizes e nas políticas, de forma que os ganhos obtidos não fiquem
restritos e que sejam disseminados por toda a organização.
De acordo com Albuquerque (2008), entre as ações necessárias para a
institucionalização das melhorias, tem-se: realizar treinamentos para que os colaboradores
possam executar de forma adequada o novo processo e promover o envolvimento dos
colaboradores.
Se os resultados das ações executadas forem somente temporários, eles não são
melhorias verdadeiras. É a duração dos resultados que garante a eficácia. Sendo assim, a
padronização, através de documentos, é necessária. A padronização é definida como
medidas que previnem reincidências e avaliam a performance das atividades de melhoria,
como também a verificação dos resultados. Sem padrões, as ações tomadas para resolver
um problema irão gradativamente retroceder às rotinas antigas, propiciando a repetição do
problema. E é provável que o problema volte a ocorrer quando novas pessoas passarem a
envolver-se com o trabalho em questão.
É importante que as lições aprendidas sejam registradas em uma base de
conhecimentos. Caso a organização ainda não possua uma base de conhecimentos, pode ser
feita uma lista das lições aprendidas, para que as informações possam ser reutilizadas em
situações similares.
Um modelo de documento para auxiliar a execução deste passo está disponibilizado
no Apêndice B - Modelo de Lista de Lições Aprendidas.
72
5.4 COMPARAÇÃO DA ABORDAGEM COM OUTRAS METODOLOGIAS
Esta seção tem o intuito de realizar uma análise comparativa da abordagem proposta
nesta dissertação com as metodologias para análise e solução de problemas apresentadas no
capítulo 4. Desta forma, buscaremos apresentar as principais vantagens da abordagem
proposta.
1. Específica para organizações de TI: Embora possa ser utilizada em
contextos diferentes de organizações de TI, a abordagem foi elaborada tendo
como foco este tipo de organização, tendo assim algumas peculiaridades,
como por exemplo, a forma de classificação das categorias de problemas
(pessoas, processo, organização e tecnologia). O MASP, a 8D e o QC-Story
foram desenvolvidos tendo como foco a indústria.
2. Estabelece as ferramentas e técnicas a serem utilizadas: Para cada etapa
são definidas quais ferramentas e técnicas devem ser utilizadas,
diferentemente das outras metodologias que citam uma grande quantidade
de ferramenta, mas não dá um direcionamento de quais devem ser utilizadas.
3. Define modelos de documentos a serem utilizados: Para uma etapa que
necessite de uso de documentos, são definidos modelos de forma a facilitar o
uso da abordagem. Nenhuma das metodologias citadas no capítulo 4 define
modelos a serem utilizados.
4. Maior objetividade através do uso da metodologia multicritério: Esse é
um grande diferencial da abordagem, uma vez que faz uso de uma
metodologia multicritério de apoio à decisão, que torna a tomada de decisão
o mais objetiva possível. Até o presente momento, não temos conhecimento
de nenhuma metodologia para análise de causa de problemas que faça uso da
metodologia multicritério de apoio à decisão.
5. Baseada em dados quantitativos: A abordagem visa definir metas
quantitativas, acompanhadas através de indicadores. As outras metodologias
verificam se o problema foi resolvido, independente de terem dados
quantitativos ou não.
73
5.5 CONCLUSÃO
Este capítulo apresentou a proposta desta dissertação, que consiste numa abordagem
para análise e resolução de causas de problemas em organizações de software aplicando
multicritério, detalhando-a através de suas fases com os respectivos passos e subpassos.
Além disso, apresentou as principais vantagens da abordagem, fazendo uma análise
comparativa com outras metodologias para análise e resolução de causas de problemas. O
capítulo seguinte apresenta uma experiência de uso desta abordagem.
Capítulo
6
Experiência de Uso
"O comportamento organizacional é um jogo de poder no qual
vários jogadores, chamados de influenciadores, tentam controlar
as decisões e ações da organização”.
HENRY MINTZBERG
6.1 INTRODUÇÃO
Este capítulo apresenta a experiência de uso da abordagem proposta nesta dissertação
para análise e resolução de causas de problemas em organizações de software aplicando
multicritério, mediante o uso em uma organização pública do setor de TI, cujos resultados
serão apresentados nas próximas seções.
6.2 CARACTERIZAÇÃO DA ORGANIZAÇÃO
A abordagem proposta foi aplicada no Serviço Federal de Processamento de Dados -
Serpro, que é uma empresa pública, vinculada ao Ministério da Fazenda. Foi criado no dia 1º
de dezembro de 1964, pela Lei nº 4.516, com o objetivo de modernizar e dar agilidade a
setores estratégicos da administração pública brasileira. A empresa, cujo negócio é a
prestação de serviços em tecnologia da informação e comunicações para o setor público, é
considerada uma das maiores organizações do setor, na América Latina [SERPRO, 2008].
O Serpro desenvolve programas e serviços que permitem maior controle e
transparência sobre a receita e os gastos públicos, além de facilitar a relação dos cidadãos
com o governo. Dentre as várias soluções desenvolvidas com essas características destacam-
se a declaração do Imposto de Renda via Internet (ReceitaNet), a nova Carteira Nacional de
Habilitação, o novo Passaporte Brasileiro e os sistemas que controlam e facilitam o comércio
exterior brasileiro (Siscomex). O Serpro também desenvolve projetos e programas que
75
contemplem as questões sociais de acessibilidade e inclusão digital, e apóia as políticas do
governo federal.
O mercado de atuação da empresa é o de finanças públicas, composto pelo Ministério
da Fazenda com suas secretarias e demais órgãos, correspondendo a 85,2% do volume de
negócios da empresa. Outro segmento igualmente importante é o de ações estruturadoras e
integradoras da Administração Pública Federal cuja gestão e articulação compete ao
Ministério do Planejamento, Orçamento e Gestão.
Ao longo de seus 44 anos, o Serpro consolidou-se como uma referência, aprimorando
e desenvolvendo tecnologias utilizadas por órgãos do setor público brasileiro, as quais foram
incorporadas à vida dos cidadãos.
O Serpro tem sede em Brasília e está presente em dez capitais com regionais
distribuídas de acordo com as regiões fiscais do país: Belém, Fortaleza, Recife, Salvador,
Brasília, Belo Horizonte, Rio de Janeiro, São Paulo, Curitiba e Porto Alegre. Nos demais
estados, a empresa mantém escritórios de serviço.
A experiência de uso do presente trabalho foi realizada na regional de Fortaleza, em
uma de suas superintendências, que possui atualmente cerca de 130 funcionários.
6.3 PROCESSOS DO SERPRO
O Serpro vê como fundamental manter um padrão de qualidade em relação aos
produtos desenvolvidos pelas suas unidades. Sendo assim, é preciso proporcionar condições
para que estas unidades estejam em um mesmo estado de maturidade, no que se refere ao
desenvolvimento de soluções.
Desta forma, foi desenvolvido o Processo Serpro de Desenvolvimento de Soluções
(PSDS) que tem como objetivo ser uma referência que oriente a empresa como um todo a
adotar uma metodologia integrada quando o assunto é construção de soluções de TI. Com
isso, além de ganhar em qualidade nos seus produtos, o Serpro garante mais controle sobre
seus processos e racionaliza o uso de mão-de-obra e infra-estrutura [TEMA, 2006].
76
O PSDS foi construído a partir de algumas referências, onde se destaca o RUP
(Rational Unified Process) e também se fundamenta na maturidade de processos,
alavancados pelo CMMI.
Sua estrutura é baseada em macroatividades, possuindo uma específica para auxiliar
as tomadas de decisão, chamada de “Análise de Decisão e Resolução”. No entanto, esta
macroatividade foi idealizada de forma a contemplar qualquer tipo de decisão, não estando
relacionada especificamente a problemas e não tratando de forma diferenciada a
complexidade das decisões.
6.4 APLICAÇÃO DA ABORDAGEM PROPOSTA
No setor público, é comum a ocorrência de problemas complexos uma vez que
geralmente envolvem interesses conflitantes, concentração de poder, aspectos motivacionais,
centralização de decisões, políticas de incentivo e benefícios aos servidores. Nesta
conjuntura, tomar uma decisão é uma tarefa que requer conhecimento, segurança e coerência.
Desta forma, torna-se necessário o uso de uma abordagem que auxilie os gestores no
processo de análise das causas dos problemas de maior complexidade, de forma que a tomada
de decisão se realize de forma mais coerente e realista.
Assim, nas seções seguintes serão apresentados os resultados da aplicação da
abordagem proposta nesta dissertação.
6.4.1 PLANEJAR
A fase de planejamento da experiência de uso está detalhada através dos passos
apresentados a seguir.
6.4.1.1 PASSO P1: DESCREVER O PROBLEMA
Como forma de controlar o esforço produtivo de seus funcionários, o Serpro mantém
um registro das horas trabalhadas através de um sistema, denominado SGI (Sistema de
Gestão de Informações). Neste sistema, cada funcionário deve registrar as horas efetivamente
77
trabalhadas segundo regras estabelecidas em um documento denominado “Sistemática de
Apropriação
1
”.
De forma a acompanhar os resultados, foi criado um indicador denominado "% de
Apropriação em Projetos", que vem sendo coletado mensalmente em âmbito nacional, desde
janeiro de 2007. Este indicador é coletado no pólo de Fortaleza por equipe, tendo como
objetivo medir a evolução da dedicação das equipes ao processo produtivo de
desenvolvimento de software baseado em projetos. Conforme pode ser visto na Tabela 6.1,
este indicador está associado aos objetivos de medição MED4, MED5 e MED6.
Tabela 6.1 – Mapeamento entre Objetivos de Negócio e Necessidades de Informação com os
Objetivos de Medição
Público-
Alvo:
Superintendente, Coordenação de Gestão de Demandas e de Projetos, Gerentes
de Pólo
Objetivos de Negócio e
Necessidades de Informação
ID* Objetivos de Medição
MED1
Analisar o processo, com o propósito de avaliar a
eficácia, do ponto de vista do Superintendente e
Gerentes de Pólo, Pólos de Desenvolvimento, e
equipes.
Conhecer a efetividade do
processo, monitorando o
atendimento a projetos e
serviços.
MED2
Analisar o processo, com o propósito de monitorar a
evolução da alocação de recursos no processo
produtivo, referente à eficiência, do ponto de vista do
Superintendente, Gerentes de Pólo e clientes (URC),
Pólos de Desenvolvimento, e equipes.
Melhorar a satisfação do
cliente, assegurando a entrega
de serviços com a qualidade
contratada, obedecendo os
modelos de qualidade
adotados pelo Serpro.
MED3
Analisar o desempenho dos Pólos de
Desenvolvimento e equipes, com o propósito de
controlá-los e melhorá-los, referente à eficiência, do
ponto de vista do Superintendente e Gerentes de
Pólo.
MED4
Analisar a qualidade dos registros de apropriação,
com o propósito de garantir informação consistente
para tomadas de decisão em conjuntura tempestiva.
MED5 Analisar efetividade da gestão de projetos e serviços.
Melhorar a qualidade da
informação de
acompanhamento de projetos
e serviços para apoiar à
tomada de decisão na
distribuição de demandas
entre os Pólos de
Desenvolvimento
MED6
Analisar distribuição de projetos e serviços no âmbito
dos Pólos de Desenvolvimento e Superintendência.
1
Sistemática de Apropriação é um documento que contém todas as regras referentes ao cadastro das horas
trabalhadas (apropriação), como por exemplo: em quais atividades apropriar, quais serviços, tipo de atividade,
insumo etc.
78
De forma a auxiliar ainda mais no controle da apropriação, surgiu a necessidade de
saber quanto do esforço apropriado estava relacionado a serviços
2
e quanto não era
apropriado (inoperância
3
). Desta forma, outros dois indicadores foram criados: “% de
Apropriação em Serviços por Equipe” e “% de Inoperância por Equipe”.
Estes indicadores são coletados e analisados mensalmente. As análises são realizadas
em três momentos distintos:
• Análise Prévia: após ter sido realizada a coleta do indicador, o Analisador de
Medidas (AME) faz uma análise prévia, em um relatório denominado
Relatório de Medição e Análise (REMA) que é composto por outros sete
indicadores além dos três mencionados acima. Esta análise é feita de forma
totalmente objetiva, tomando como base apenas os dados quantitativos
obtidos.
• Reunião de Medição e Análise: esta reunião tem como participantes os
membros do Grupo de Trabalho de Medição e Análise (GT-MA), atualmente
composto por sete pessoas incluindo o Analisador de Medidas (AME) e a
Coordenadora do Grupo de Medição e Análise (CMA). Também participam
desta reunião a Gerência Sênior (GS) e o responsável pela Garantia de
Qualidade de Software do Pólo (GQSP). O REMA é discutido nesta reunião, e
os resultados que se apresentam fora dos limites de controle estabelecidos são
investigados pelos membros do GT-MA, de forma a complementar o REMA.
• Reunião de Análise Crítica de Desempenho (ACD): após o REMA ter sido
complementado, é realizada a Reunião de ACD. Esta reunião tem como
participantes o GS, o CMA, o AME, o GQSP, Chefes de Divisão (três
pessoas) e Líderes de Projeto (dez pessoas). Nesta reunião o REMA é
discutido e ações corretivas e/ou preventivas são geradas.
Logo após a Reunião de ACD, o REMA é complementado com as alterações
sugeridas na reunião e, cadastrado na ferramenta SGI onde os resultados serão analisados e
consolidados com os resultados dos demais pólos do Serpro e analisados a nível nacional.
2
Consistem nos trabalhos de manutenção e desenvolvimento de sistemas realizados pelas equipes de projetos.
3
Consiste nas horas não trabalhadas.
79
Através das análises, são geradas ações corretivas com o intuito de sanar os
problemas identificados. No entanto, para os indicadores de apropriação (projetos, serviço e
inoperância) tais ações nem sempre se mostram efetivas e o problema se repete nos meses
seguintes para algumas equipes. Desta forma, a eficácia de tais ações é constantemente
questionada.
Diante deste contexto, a aplicação da abordagem proposta se mostra de extrema
relevância para tratar os resultados obtidos nos indicadores. Assim, a mesma será utilizada
como forma de tratar o seguinte problema: “Grande percentual de inoperância na
Equipe 1”.
Este problema vem sendo identificado há sete meses através do indicador de
“Evolução do % de inoperância por equipe”, sendo que a Equipe 1 esteve dentro dos limites
de controle em apenas um mês dos últimos sete. Como pode ser visto na Figura 6.1, a
inoperância desta equipe só vem aumentando, apresentando uma tendência de crescimento.
Figura 6.1: Indicador da Evolução do % de Inoperância da Equipe 1
80
Como pode ser visto na Figura 6.1, os valores de referência estabelecidos para este
indicador são:
• Limite inferior de controle: 10%
• Média: 15%
• Limite superior de controle: 20%
Os resultados referentes a este indicador nas demais equipes são variáveis, no entanto,
a grande maioria apresenta os resultados dentro dos limites de controle.
Vale ressaltar que este indicador é de suma importância, uma vez que ele dá subsídios
para a tomada de várias decisões, sejam elas no âmbito do projeto, do pólo, da regional e até
mesmo em nível nacional. Alguns exemplos da relevância das informações deste indicador
são:
• Distribuição de atividades no projeto.
• Alocação das pessoas entre projetos.
• Aquisição de novos projetos.
• Medição da produtividade.
• Aquisição de novos concursados.
Desta forma, a análise dos problemas relacionados a este indicador não pode ser
negligenciada. Assim, será realizada a abordagem multicritério para análise e resolução de
causas de problemas de forma a investigar as causas do alto % de Inoperância da Equipe 1.
As categorias para classificação do problema serão as definidas nesta abordagem, ou
seja: pessoas, processo, organização e tecnologia.
6.4.1.2 PASSO P2: FORMAR A EQUIPE
Para formar a equipe, o facilitador analisou quais os papéis que atuam direta ou
indiretamente nos resultados, ou que podem contribuir com os mesmos, através de
informações, sugestões, conhecimento e experiência, sendo considerados desta maneira como
atores do processo.
81
Assim, foram selecionados os seguintes papéis na organização, para auxiliar na
análise e resolução das causas do problema:
• Gerência Sênior: Tem a responsabilidade de fornecer direcionamento
técnico/administrativo e distribuir novas atividades entre as divisões.
• Chefe de Divisão: Responsável pela administração dos recursos, designação
do líder para os projetos e gestão das demandas
4
(negociação de prazos,
definição de prioridades etc). Em alguns momentos exerce o papel de
Gerência Sênior.
• GPES Local: Responsável pela definição, manutenção e melhoria contínua
do PSDS. O Grupo de Processo de Engenharia de Software (GPES) tem
como atribuições gerais: internalizar o PSDS; monitorar seu uso; propor e
implementar melhorias em seu conteúdo e estrutura; fornecer suporte aos
seus usuários; e gerenciar a aplicação de mudanças ao processo.
• CMA do Pólo: Responsável pelo planejamento e acompanhamento das
atividades relacionadas à medição e análise no seu âmbito de atuação. O
Coordenador de Medição e Análise (CMA) elabora o Plano de Medição e
Análise (PMA) e as Especificações de Medição (EM) necessárias à sua
execução, bem como o Relatório de Avaliação de Medição e Análise
(RAMA).
• AME do Pólo: Responsável pela análise e apresentação dos resultados das
medições. O Analisador de Medidas - AME elabora o REMA e divulga-o às
partes interessadas de acordo com o PMA.
• GQS do Pólo: Tem como principais responsabilidades planejar e
acompanhar as atividades de Garantia da Qualidade de Software do Pólo
(GQSP); alocar consultores de GQS aos projetos; divulgar mensalmente as
atividades e resultados de GQS do Pólo; promover palestras sobre objetivos,
4
Demanda consiste em uma solicitação de serviço direcionada para o pólo. Um projeto pode atender uma ou
mais demandas.
82
valores, benefícios, atividades, papéis e responsabilidades da macroatividade
de GQS, entre outras.
• Coordenador do Escritório de Projetos: Responsável por coordenar as
atividades relacionadas ao escritório de projetos. Exemplos de atividades:
delegar atividades na equipe, negociar compromissos, divulgar informações
gerais para o pólo, subsidiar necessidades de informações das lideranças,
entre outras.
• Líder de Projeto: É o responsável por todas as atividades relacionadas ao
Software a ser desenvolvido. Exemplos de atividades: desenvolver e
acompanhar os planos de trabalho; negociar compromissos; manter
informados todos os envolvidos no projeto, entre outras.
• Desenvolvedores: São todos os profissionais envolvidos diretamente no
desenvolvimento de Software, tais como Analista de Sistemas, Projetistas,
Implementadores, Testadores etc. O PSDS refere-se a Desenvolvedor de uma
maneira geral, quando não foi criado papel específico para a execução da
atividade.
A Tabela 6.2 apresenta em maiores detalhes a equipe descrevendo o papel na
organização, papel na abordagem e em quais passos os participantes estão envolvidos.
83
Tabela 6.2 –Papéis dos Envolvidos e Passos onde Possuem Participação
Papel na
Organização
Papel na
Abordagem
Passos Envolvidos
Gerência Sênior Owner 1 Passo P2, Passo P3, Passo D1 (Subpasso D.1.1), Passo
D3 e Passo A1
Chefe de Divisão Owner 2 Passo P3, Passo D1 (Subpasso D.1.1), Passo D3 e
Passo A1
Líder de Projeto Owner 3 Passo P3, Passo D1 (Subpasso D.1.1), Passo D3 e
Passo A1
GPES Local,
CMA do Pólo e
Coordenador do
Escritório de
Projetos
Decisor 1 Passo P3, Passo D1 (Subpasso D1.2, D1.3, D1.4, D1.5
e D1.6), Passo D2, Passo D3 e Passo C1.
GQS do Pólo Decisor 2 Passo P3, Passo D1 (Subpasso D1.3, D1.4, D1.5 e
D1.6), Passo D2, Passo D3 e Passo C1.
AME do Pólo Facilitador Todos os passos
Desenvolvedor Envolvido 1 Passo D1 (Subpasso D1.1, D1.2), Passo D2 e Passo D3
Desenvolvedor Envolvido 2 Passo D1 (Subpasso D1.1, D1.2), Passo D2 e Passo D3
Desenvolvedor Envolvido 3 Passo D1 (Subpasso D1.1, D1.2), Passo D2 e Passo D3
Desenvolvedor Envolvido 4 Passo D1 (Subpasso D1.1, D1.2), Passo D2 e Passo D3
Desenvolvedor Envolvido 5 Passo D1 (Subpasso D1.1, D1.2), Passo D2 e Passo D3
Desenvolvedor Envolvido 6 Passo D1 (Subpasso D1.1, D1.2), Passo D2 e Passo D3
Desenvolvedor Envolvido 7 Passo D1 (Subpasso D1.1, D1.2), Passo D2 e Passo D3
Desenvolvedor Envolvido 8 Passo D1 (Subpasso D1.1, D1.2), Passo D2 e Passo D3
Desenvolvedor Envolvido 9 Passo D1 (Subpasso D1.1, D1.2), Passo D2 e Passo D3
Vale ressaltar que o facilitador contou com o auxílio dos decisores na seleção dos
participantes. Além disso, a participação das pessoas acima mencionadas foi autorizada pela
Gerência Sênior e não foi necessária a realização de uma amostragem para seleção de
membros da equipe, uma vez que não é um número muito grande de membros e a
participação de cada um é de suma importância, pois o resultado de apenas uma pessoa pode
contribuir significativamente para o resultado do indicador que está sendo tratado. Assim,
assumiu-se que os benefícios serão maiores que os custos incorridos.
84
6.4.1.3 PASSO P3: DEFINIR OBJETIVOS E METAS
O objetivo de executar a abordagem proposta nesta dissertação no problema
detalhado no Passo P1 é fazer uma análise mais criteriosa das causas do alto % de
inoperância na Equipe
1
de forma a executar ações que façam com que os resultados do
indicador fiquem dentro dos limites de controle. Este objetivo está associado com a meta do
indicador e, já era de comum acordo entre os owners.
Desta forma, o facilitador apoiou os decisores na definição das metas, de forma a
alcançar o objetivo. Os detalhes das metas e submetas definidas estão apresentados na
Tabela 6.3.
Tabela 6.3 – Detalhamento da Meta
Meta Submeta Prazo
SM1 - Diminuir em 10 pontos percentuais a inoperância,
ou seja, o resultado do indicador referente ao mês 8 deve
ser de, no máximo, 33%.
jan/09
SM2 - Diminuir em 8 pontos percentuais a inoperância, ou
seja, o resultado do indicador referente ao mês 9 deve ser
de, no máximo, 25%.
Obs.: este percentual pode ser ajustado, de acordo com o
resultado obtido no mês de 8.
fev/09
M1 - % de inoperância
da Equipe 1 dentro dos
limites de controle (10%
a 20%).
SM3 - Diminuir em 5 pontos percentuais a inoperância, de
forma que o resultado do indicador referente ao mês 10
esteja dentro dos limites de controle (no máximo 20%).
Obs.: este percentual pode ser ajustado, de acordo com o
resultado obtido no mês de 9.
mar/09
Depois de definidas as metas e submetas, os owners as aprovaram. Esta aprovação se
torna fundamental como forma de obter o comprometimento de todos os envolvidos no
alcance das metas.
85
6.4.2 EXECUTAR
A fase de execução da experiência de uso está detalhada através dos passos
apresentados a seguir.
6.4.2.1 PASSO D1: DETERMINAR AS CAUSAS DO PROBLEMA
O passo de determinação das causas do problema está detalhado através dos
subpassos apresentados a seguir.
6.4.2.1.1 SUBPASSO D1.1: Investigar as Causas Potenciais do Problema
Como forma de investigar as causas do problema, o facilitador realizou um
brainstorming individual com os envolvidos diretamente no problema, totalizando quinze
pessoas (ver Tabela 6.2). Essa investigação foi realizada utilizando um diagrama de causa e
efeito dividido nas quatro categorias definidas no Passo P1.
O facilitador, ao entregar o modelo de diagrama de causa e efeito para cada membro
da equipe selecionada, explicou o objetivo do brainstorming e falou sobre como as pessoas
deveriam preencher o diagrama. Algumas pessoas já conheciam o diagrama, outras não, mas,
como o mesmo é de fácil utilização, não houve problemas para seu uso.
Neste subpasso, o facilitador notou que a principal dificuldade da equipe foi para
classificar algumas causas, o que já era previsto, uma vez que as mesmas poderiam estar
associadas a mais de uma categoria. Desta forma, foi orientado que, ao classificar, fosse
analisada qual a categoria mais fortemente relacionada à causa. Este relacionamento entre as
categorias das causas é analisado no Subpasso D1.5 – Avaliar as Causas, onde será realizada
uma análise mais detalhada através do Hiview.
Logo após os participantes terem identificado as causas do problema, foi feita uma
listagem contendo todas as causas elencadas nos diagramas. Assim, foram identificadas 34
causas relacionadas a pessoas, 15 relacionadas a processos, 6 relacionadas à organização e 22
relacionadas à tecnologia, conforme podemos ver nas Tabelas 6.4, 6.5, 6.6 e 6.7
respectivamente. Vale mencionar que para algumas causas (as destacadas de cinza) foi
86
necessário obter maiores informações com os participantes a fim de categorizá-las
adequadamente, conforme podemos ver na seção a seguir.
Tabela 6.4 – Causas Identificadas Relacionadas a Pessoas
No. Causas Identificadas na Categoria “Pessoas” Grupo
1 Se sentem controladas G1
2 Tarefas de curta duração desestimulam a apropriação G2
3 Falta de percepção da necessidade/importância da apropriação para o processo G3
4 Foco nas atividades de Análise, Projeto e Implementação de Software. G3
5 Falta cobrança das lideranças
G5
6 Conscientização G3
7 Sobrecarga de Recursos G4
8 Falta de Acompanhamento G5
9 Resistência ao controle G1
10 Falta de clareza do sentimento das pessoas (quais são as dificuldades?). G6
11 Dificuldade de comunicação G7
12 Empregado tem a visão do escritório de projetos como “inspetor” G8
13 Empregado tem a visão que o escritório de projetos tem mais poder que o GS. G8
14 Falta de disciplina na apropriação: apropriação realizada apenas no fim do mês G9
15
Realização de muitas atividades ao mesmo tempo confunde o empregado na
hora de apropriar
G9
16 Demora ao apropriar (esquecimento) G9
17 Falta de conhecimento da maneira correta de apropriar G7
18 Orientações erradas G7
19 Baixa motivação para apropriação G2
20 Pouco entendimento sobre a política de apropriação G3
21 Dificuldade de saber em que e como apropriar G7
22 Deixar para apropriar no final do mês G9
23 Não apropriam diariamente G9
24
Falta de hábito de apropriar diariamente. Normalmente as pessoas deixam pra
depois e esquecem quantas horas trabalharam nos projetos.
G9
25
Ainda há pouca gente capacitada para a distribuição de serviços, tendo assim
uma sobrecarga de demandas.
G4
26 Atraso nas apropriações diárias G9
27 Falta de clareza na utilidade da informação G3
28
As pessoas não sabem qual o benefício/impacto de apropriações incorretas. O
processo não indica os padrões de normalidade
G3
29 Falta de acompanhamento dos LP G5
30 Falta de discussão nas equipes sobre apropriação. G7
31 Projetos de curtíssima duração impossibilitando uma apropriação correta G2
32 Competitividade G10
33 Falta de espírito de equipe G10
34 Medo de punição G11
87
Tabela 6.5 – Causas Identificadas Relacionadas a Processo
No. Causas Identificadas na Categoria “Processo” Grupo
1
O Indicador não deve incluir no cálculo as pessoas que não estão envolvidas
diretamente nos projetos.
G1
2 Muito oneroso G2
3 Falta de acompanhamento do GQS G3
4 Dificuldade de verificação da integridade dos dados G1
5 Tempestividade do escritório de projetos para subsidiar a tomada de ações G4
6 Indicador inadequado (Ex.: Limites de controle) G1
7 Sistemática complexa G5
8 O processo não indica claramente onde cada atividade deve ser apropriada. G5
9
Gestão da “acomodação”: Apesar do problema da baixa apropriação em
projetos, não são tomadas ações efetivas para correção de rumo.
G6
10 Falta de avaliação mais “robusta” do CGQS G3
11
Não é claro. Existem muitas subdivisões que confundem as pessoas com
relação a como apropriar uma determinada atividade.
G5
12 Muitas vezes recebemos demandas sem SM e não sabemos onde apropriar G7
13 Tarefas sem SM G7
14
Processo extremamente burocrático, sem prever de forma eficiente
tratamento para grande porte, uma vez que quem define ou tem a visão de
plataforma baixa ou nunca trabalhou para valer e com isso acaba não tendo
noção da realidade do dia-a-dia.
G2
15 Muitas demandas atendidas sem SM. G7
Tabela 6.6 – Causas Identificadas Relacionadas à Organização
No. Causas Identificadas na Categoria “Organização” Grupo
1 Política de gratificação não relacionada à apropriação G1
2
Algumas equipes ficam sem projetos em determinados períodos, porém,
nem sempre são realocadas às equipes que têm projetos e que estão
precisando de recursos.
G2
3 Demora na correção dos problemas identificados na ferramenta ou processo G3
4
A empresa não deixa explícita a sua política de apropriação e nem vincula
esta com a produtividade das equipes e com a FCT distribuída fazendo com
que isto diminua a motivação para apropriação
G1
5
Contato direto do cliente com o desenvolvimento. A área de negócio não faz
sua parte.
G2
6
Postura errada da empresa ao aceitar tudo que o cliente impõe com a
desculpa de prazos políticos.
G2
88
Tabela 6.7 – Causas Identificadas Relacionadas à Tecnologia
No. Causas Identificadas na Categoria “Tecnologia” Grupo
1 Ferramenta não automatizada o suficiente. G1
2 Ferramentas de difícil orientação G2
3 Falta de automação em algumas atividades relacionadas à apropriação G1
4 Lentidão nas ferramentas G3
5
Dificuldades da ferramenta (lentidão, problemas na exportação,
contabilização errada de jornadas de 6 horas).
G3
6 Falta de automatização G1
7 Erros processo manual G1
8
O ato de apropriar não está integrado à execução da atividade. Para realizar
a apropriação o empregado tem que parar o que está fazendo e acessar a
ferramenta para registrar.
G4
9 A ferramenta não critica alguns tipos de apropriações incorretas G3
10 Ferramenta não amigável G2
11 Falta de automação G1
12 Não contabilização de abonos de meio período/horas G3
13 A ferramenta de apropriação não é eficiente. G3
14
A ferramenta não está vinculada com o cartão de ponto, fazendo com que as
horas apropriadas não justifiquem as horas extras.
G4
15
Não há um tempo mínimo de apropriação, criando-se para isso muitos
registros de apropriação com menos de uma hora.
Descartado
16 Não há integração com o solicita G4
17 Falta de integração com o solicita G4
18
Com a interface atual, o usuário demora um tempão para encontrar o seu
projeto. É preciso melhorar a seleção na lista de projetos.
G3
19
Algumas pessoas preferem manter a página do SGI aberta para irem
apropriando ao longo do dia, porém, a sessão expira em 30 minutos e você
tem que relogar.
G3
20 Falta de integração G4
21 A ferramenta não presta. Descartado
22 A organização dos projetos prejudica a localização G3
Vale destacar que duas das causas identificadas foram descartadas. Uma delas
(número 15 da categoria tecnologia) por não estar diretamente associada ao problema e, a
outra causa (número 21 da categoria tecnologia), por estar genérica, não agregando ao
estudo realizado.
89
6.4.2.1.2 SUBPASSO D1.2: Consolidar os Resultados
Depois de listadas todas as causas identificadas, o facilitador agrupou as causas
repetidas ou similares, como pode ser visto na coluna “Grupo” das Tabelas 6.4, 6.5, 6.6 e 6.7,
de forma a consolidar os resultados. Estes grupos foram numerados, de forma a não perder a
rastreabilidade, bem como identificar o número de vezes que a causa foi identificada. Em
seguida, o agrupamento foi revisado pelo Decisor 1. O Decisor 2 não participou deste
subpasso por indisponibilidade durante o período.
Vale frisar que algumas causas citadas não puderam ser classificadas inicialmente,
pois o facilitador e o decisor necessitaram de maiores informações, como foi o caso das
causas 19 e 25 da categoria pessoas, 14 da categoria processos e, 13 da categoria tecnologia
(destacadas de cinza). Desta forma, foi necessário que o facilitador buscasse maiores
esclarecimentos com os participantes para, a partir daí, realizar a classificação da maneira
correta.
Após todas as causas terem sido classificadas e agrupadas, os resultados foram
consolidados e os respectivos gráficos de Pareto foram construídos, conforme pode ser visto
nas Figuras 6.2, 6.3, 6.4 e 6.5.
Como pode ser visto na Figura 6.2, as causas “Falta de Disciplina”, “Falta de
Entendimento/Conscientização da Importância e Impacto”, “Problemas de
Comunicação/Orientação” e “Desestímulo – Tarefas de Curta Duração” foram as causas
identificadas mais vezes, representando 61,8% do total de causas identificadas na categoria
“Pessoas”.
90
Causas Relacionadas a Pessoas
0
1
2
3
4
5
6
7
8
Figura 6.2 – Causas Consolidadas Relacionadas a Pessoas
A Figura 6.3 mostra que as causas “Problemas no Indicador”, “Falta de Clareza no
Processo/Sistemática
5
” e “Tarefas sem SM
6
” foram as causas identificadas mais vezes,
representando 60% do total de causas identificadas na categoria “Processo”.
5
Sistemática consiste em um documento que rege as regras sobre apropriação.
6
Uma Solicitação de Mudança (SM) consiste na forma de atribuição de atividades para os membros das
equipes através da ferramenta SGI.
91
Causas Relacionadas a Processo
0
1
2
3
4
5
6
7
8
G1 - Problemas no
indicador
G5 - Falta de
clareza no processo
/ sistemática
G7 - Tarefas sem
Sm
G2 - Processo
oneroso/burocrático
G3 - Falta de
acompanhamento
dos CGQS
G4 - Falta de
tempestividade no
acompanhamento
do Escritório de
Projetos
G6 - Falta de ações
efetivas para tratar
o problema
Figura 6.3 – Causas Consolidadas Relacionadas a Processo
As causas “Problemas de Gestão” e “Falta de Política de Gratificação” foram as
causas identificadas mais vezes, como pode ser visto na Figura 6.4, representando 83% do
total de causas identificadas na categoria “Organização”. Vale ressaltar que, nesta categoria,
apenas 6 causas foram citadas, resultando em apenas 3 grupos.
92
Causas Relacionadas à Organização
0
1
2
3
4
5
6
7
8
G2 - Gestão para alocação dos
recursos deficiente
G1 - Falta de política de gratificação G3 - Demora na correção dos
problemas identificados na
ferramenta e/ou processo
Figura 6.4 – Causas Consolidadas Relacionadas à Organização
Na Figura 6.5 pode ser visto que as causas “Problemas/Melhorias na ferramenta” e
“Falta de Automação” foram as causas identificadas mais vezes, representando 65% do total
de causas identificadas na categoria “Tecnologia”.
Causas Relacionadas à Tecnologia
0
1
2
3
4
5
6
7
8
G3 - Problemas/melhorias
na ferramenta
G1 - Falta de automação G4 - Falta de integração G2 - Ferramenta pouco
intuitiva
Figura 6.5 – Causas Consolidadas Relacionadas à Tecnologia
93
Depois de gerados os gráficos, as causas elementares foram identificadas, conforme
veremos na seção a seguir.
6.4.2.1.3
SUBPASSO D1.3: Identificar as Causas Elementares
De forma a auxiliar na seleção das causas elementares e permitir uma melhor
visualização das causas consolidadas, foi construído um diagrama de causa e efeito, onde
foram destacadas as causas consideradas como de maior impacto no problema, como pode
ser visto na Figura 6.6.
94
Figura 6.6 – Diagrama de Causa e Efeito das Causas Consolidadas
Depois de construído o diagrama de causa e efeito, foram destacadas no mesmo oito
causas consideradas como pontos de vista elementares e, a partir daí, foi construída a árvore
de valor no Hiview.
6.4.2.1.4
SUBPASSO D1.4: Construir os Descritores e Identificar os Níveis “Bom” e
“Neutro”
Para o problema em estudo, os decisores e o facilitador analisaram os PVEs e
decidiram pela não construção dos descritores de impacto, uma vez que a sua quantificação
não seria algo trivial, devendo ser aplicadas pesquisas ou outras formas para geração dos
mesmos, o que seria inviável devido ao pouco tempo disponível para o alcance das metas.
6.4.2.1.5
SUBPASSO D1.5: Avaliar as Causas
Para a avaliação das causas do problema, foi realizada uma reunião entre o facilitador
e decisores, para construção das matrizes de juízos de valor e obtenção das escalas de
preferência local para cada um dos pontos de vista fundamentais (categorias), seguindo a
metodologia MACBETH e os procedimentos de questionamento apresentados em Bana e
Costa e Vansnick (1995) e em Bana e Costa e Chagas (2002).
Durante o processo de construção dessas matrizes ocorreram alguns casos de
inconsistência cardinal, resolvidos através de discussões, com a conseqüente modificação
de alguns julgamentos. As matrizes de juízos de valor resultantes das análises podem ser
vistas nas Figuras 6.7 (PVF Pessoas), 6.8 (PVF Processo), 6.9 (PVF Organização) e 6.10
(PVF Tecnologia).
Como pode ser visto na Figura 6.7, as causas relacionadas à categoria Pessoas
tiveram uma distribuição de valores uniforme, apresentando uma maior variação entre as
causas “Problemas de Comunicação/Orientação”, “Demora na Correção dos Problemas” e
“Falta de Clareza no Processo/Sistemática”.
96
Figura 6.7 – Matriz de Juízos de Valor para o PVF Pessoas
Na Figura 6.8, relacionada à categoria Processos, as causas “Tarefas sem SM” e
“Problemas de Comunicação/Orientação” apresentaram variação igual às causas “Falta de
Acompanhamento das Lideranças” e “Demora na Correção dos Problemas”.
Figura 6.8 – Matriz de Juízos de Valor para o PVF Processo
Assim como a categoria relacionada a Pessoas, que apresentou escores uniformes,
podemos observar na Figura 6.9 que a categoria Organização também teve resultados
distribuídos com valores aproximados, apresentando uma maior variação entre as causas
“Falta de Acompanhamento das Lideranças” e “Falta de Clareza no Processo/Sistemática”.
97
Figura 6.9 – Matriz de Juízos de Valor para o PVF Organização
E, na categoria Tecnologia, observamos uma grande diferença de atratividade entre
a causa “Tarefas sem SM” e “Falta de Acompanhamento das Lideranças”. Destaca-se
também a proximidade entre as causas “Problemas na Ferramenta”, “Demora na Correção
dos Problemas” e “Tarefas sem SM”. As demais causas apresentaram taxas de variação
uniformes.
Figura 6.10 – Matriz de Juízos de Valor para o PVF Tecnologia
Para uma melhor visualização dos resultados, a Figura 6.11 apresenta o termômetro
de cada ponto de vista, com as respectivas pontuações para cada opção.
98
Figura 6.11 – Termômetro dos Pontos de Vista Fundamentais
Logo após terem sido construídas as matrizes de juízo de valor para cada PVF, foi
realizada a construção da matriz de juízos de valor para o problema (inoperância),
conforme podemos ver na Figura 6.12. Esta matriz tem como objetivo identificar a
relevância de cada critério, tendo como resultado uma escala de pesos (coluna Current
Scale).
A aplicação do MACBETH para a determinação dos pesos facilita o processo de
tomada de decisão, uma vez que, com o mesmo tipo de procedimento utilizado para a
determinação das escalas de valor cardinal locais, é possível obter as constantes de escala
necessárias à agregação das avaliações locais das ações potenciais.
99
Figura 6.12 – Matriz de Juízos de Valor para Atribuição de Pesos aos PVFs
Por fim, o resultado final pode ser visto na Figura 6.13, onde os escores obtidos por
cada causa são apresentados.
Figura 6.13 – Resultado dos Escores Obtidos em cada Opção
Desta forma, ordenando as causas em ordem decrescente de classificação, temos o
seguinte resultado:
1. Falta de Entendimento/Conscientização da Importância e Impacto; Falta de
Acompanhamento das Lideranças.
100
2. Problemas de Comunicação/Orientação
3. Falta de Disciplina.
4. Demora na Correção dos Problemas.
5. Falta de Clareza no Processo/Sistemática.
6. Tarefas sem SM
7. Problemas na Ferramenta.
Diante dos resultados, os decisores e o facilitador fizeram uma análise, como pode
ser visto no subpasso a seguir.
6.4.2.1.6
SUBPASSO D1.6: Analisar os Resultados
Conhecidos os resultados, os decisores analisaram-nos com o intuito de avaliar a
necessidade de alteração dos valores obtidos. Foi senso comum que a ordem apresentada
pela ferramenta foi sensata e que devem ser tratadas de acordo com esta prioridade.
No entanto, o empate entre as causas “Falta de Entendimento/Conscientização da
Importância e Impacto” e “Falta de Acompanhamento das Lideranças” fez com que o
facilitador e decisores realizassem uma análise de sensibilidade com o intuito de avaliar os
valores obtidos para estas duas causas.
Para isto, foi aplicada a análise de sensibilidade do Hiview, gerando-se um gráfico
para a categoria Pessoas, conforme pode ser visto na Figura 6.14, uma vez que as duas
causas que obtiveram o mesmo escore pertencem a esta categoria.
101
Figura 6.14 – Análise de Sensibilidade para o Critério “Pessoas”
A análise de sensibilidade permite analisar variações no valor total atribuído às
ações e as conseqüências destas variações podem ser analisadas. Isto porque, em alguns
casos, pequenas variações nas taxas de substituição, inicialmente calculadas, podem vir a
apontar uma nova opção como a mais adequada.
Conforme podemos ver na Figura 6.14, o eixo das abscissas X representa o índice
de relevância do critério. A linha vertical paralela ao eixo Y e com valor 54,1 no eixo X
indica o grau de relevância desse critério para a organização. O eixo das ordenadas Y
representa o índice de relevância das ações.
Os números de 1 a 8 apresentados na Figura 6.14 indicam a ordem de importância
da causa para o critério Pessoas, ou seja, a causa 1 é a mais relevante e, a causa 8, a menos
relevante. No entanto, esta análise de sensibilidade foi realizada com o intuito de investigar
as causas 2 e 3.
102
Desta forma, podemos observar que para o critério Pessoas, a causa 2 tem maior
prioridade que a causa 3. Isto também pode ser observado na Figura 6.11, onde os
termômetros indicam que a “Falta de Entendimento/Conscientização da Importância e
Impacto” tem maior prioridade que a “Falta de Acompanhamento das Lideranças” nos
critérios Pessoas, Processo e Organização.
Além destas informações, a análise de sensibilidade realizada para o critério Pessoas
mostrou que:
• Se o peso do critério pessoas for menor que 48,2, a causa 3 passa a ter maior
prioridade que a causa 2.
• Se o peso do critério pessoas estiver no intervalo entre 48,2 e 53 (parte
hachurada de verde na Figura 6.14), a ordem de prioridade entre as causas 2
e 3 permanece a mesma no resultado final, ou seja, ficam empatadas (ver
Figura 6.13).
• Se o peso do critério pessoas for maior que 53, a causa 2 passa a ter maior
prioridade que a causa 3.
Diante destas informações, o facilitador e decisores, cientes de que o critério
pessoas é o de maior relevância no contexto deste problema, priorizaram a solução da
causa 2.
6.4.2.2
PASSO D2: ANALISAR AS POSSÍVEIS SOLUÇÕES
Após a análise dos resultados, o facilitador e os decisores realizaram um
brainstorming elencando as possíveis soluções para tratamento do problema.
Neste momento, foi analisada a lista de sugestões propostas pelos participantes
quando os mesmos haviam realizado o brainstorming individual (Subpasso D1.1: Investigar
as Causas Potenciais do Problema), o que totalizou 68 sugestões de melhoria. Para cada
sugestão foi feito um mapeamento com as causas associadas à mesma, como pode ser visto
na Tabela 6.8.
103
Tabela 6.8 – Sugestões de Ações para Tratamento dos Problemas
Descrição da Sugestão Causa Associada
Realizar Reuniões com as equipes para expor os objetivos de MA,
PMA e REMA para sensibilizá-los sobre a importância das
apropriações.
Falta de Entendimento/Conscientização
da Importância e Impacto
Problemas de Comunicação/Orientação
Rever sistemática de apropriação anexando orientação Problemas de Comunicação/Orientação
Falta de Clareza no Processo/Sistemática
Orientar colaboradores sobre como apropriar imediatamente após
eventos
Problemas de Comunicação/Orientação
Definir procedimento juntos aos LP (ou coordenadores de MA das
equipes) para verificar apropriação dos colaboradores por amostragem
Falta de Acompanhamento das
Lideranças
Fazer novo levantamento junto às equipes sobre quem fez atividades
de serviços e realizar novo plano de ação para repasse às URC e/ou
cliente.
-
Rever fórmula do indicador para incluir somente pessoas envolvidas
diretamente nos projetos.
-
Discutir o motivo da apropriação em determinadas macros estar baixa -
Incentivar a apropriação em projetos com reconhecimento e
valorização da correta apropriação
-
Acompanhar a apropriação em serviço e a não apropriação para
identificar se elas não poderiam ser revertidas para apropriação em
projetos.
Falta de Acompanhamento das
Lideranças
Compartilhar pessoas “ociosas” com equipes que tenham projetos
com necessidade de recursos.
Falta de Acompanhamento das
Lideranças
Conscientizar as lideranças sobre o processo, importância e objetivos
de Medição e Análise.
Falta de Entendimento/Conscientização
da Importância e Impacto
Comunicar os resultados de maneira mais simples para os
colaboradores
Problemas de Comunicação/Orientação
Cuidado ao relacionar resultados com premiação -
Trabalhar as resistências (especialmente LP). O que temem? O que
incômoda?
Falta de Entendimento/Conscientização
da Importância e Impacto
Trabalhar espírito de equipe Falta de Entendimento/Conscientização
da Importância e Impacto
Tratar as solicitações de mudanças constantes do indicador -
Fazer avaliações da apropriação por amostragem Falta de Acompanhamento das
Lideranças
Trabalhar a imagem do escritório de projetos como aliado Problemas de Comunicação/Orientação
Envolver desenvolvedores nas análises e tomadas de ações Falta de Entendimento/Conscientização
da Importância e Impacto
Fornecer dados a tempo de tomar ações que impactem no resultado do
mês
Falta de Acompanhamento das
Lideranças
Trabalhar bastante focado nas melhores maneiras para orientar quanto
à apropriação
Problemas de Comunicação/Orientação
Mostrar melhores práticas (depoimentos) Falta de Disciplina
Falta de Entendimento/Conscientização
da Importância e Impacto
Uniformizar a forma de apropriação (apenas horas efetivamente
trabalhadas)
Problemas de Comunicação/Orientação
Intervir junto ao corporativo para ajustar erros na ferramenta Problemas na Ferramenta
GQS cobrar efetivamente as apropriações -
104
Tabela 6.8 – Sugestões de Ações para Tratamento dos Problemas (Continuação)
Descrição da Sugestão Causa Associada
Automatizar a ferramenta para torná-la mais prática (não ser sempre
que logar para cadastrar atividades – uma maneira de importar)
Problemas na Ferramenta
Incentivar as pessoas a apropriar tempestivamente Falta de Disciplina
Falta de Entendimento/Conscientização
da Importância e Impacto
Promover uma mudança no processo e no sistema para tornar a
apropriação mais simples e com menos possibilidade de erro.
Falta de Clareza no Processo/Sistemática
Problemas na Ferramenta
Estabelecer um padrão único para apropriação Falta de Clareza no Processo/Sistemática
Treinamento para os novos funcionários Problemas de Comunicação/Orientação
Acompanhamento mensal e por equipe Falta de Acompanhamento das
Lideranças
Melhorar a ferramenta de apropriação Problemas na Ferramenta
Divulgar melhor a sistemática de apropriação Problemas de Comunicação/Orientação
Sempre reforçar a importância das apropriações para as estimativas de
projetos futuros serem mais próximas à realidade
Falta de Entendimento/Conscientização
da Importância e Impacto
Ao invés de contabilizar as horas, ver a produtividade. -
O sistema deve ser descentralizado. Ao invés de um servidor central,
ser um por regional.
Problemas na Ferramenta
Apresentação da empresa de uma política que vincule apropriação
com FCT, citando claramente os impactos da baixa apropriação.
-
Melhoria na parte tecnológica - no sistema de apropriação poderia ser
acrescida a coleta automática de apropriação, uma vez que os
funcionários trabalham com solicitações.
Problemas na Ferramenta
Relacionar o cartão de ponto com a ferramenta de apropriação
(Muitas vezes o funcionário faz horas extras sem a correlação na
apropriação)
Problemas na Ferramenta
Fazer o fechamento do sistema por semana para forçar as pessoas a
registrarem suas tarefas pelo menos uma vez por semana, já que as
mesmas costumam deixar para o último dia.
Falta de Disciplina
Problemas na Ferramenta
Vincular a apropriação com as SM's, por exemplo, quando entrar no
SGI para apropriar, perguntar se a apropriação será em projeto ou não.
Se for em projeto, abrir somente os projetos das SM's que estiverem
em aberto para aquele funcionário, dessa forma, a lista de projetos
ficaria restrita aos projetos dos funcionários.
Tarefas sem SM
Problemas na Ferramenta
Apropriação diária Falta de Disciplina
O sistema deveria disponibilizar apenas os projetos que tem aquela
pessoa como recurso. Isto também evitaria que se apropriasse
incorretamente em um projeto que não se está como recurso.
Problemas na Ferramenta
Maior automação da ferramenta. Por exemplo: Trazer tipo de insumo
quando selecionar o projeto.
Problemas na Ferramenta
Automatizar a apropriação a partir das SMs. Tarefas sem SM
Problemas na Ferramenta
105
Tabela 6.8 – Sugestões de Ações para Tratamento dos Problemas (Continuação)
Descrição da Sugestão Causa Associada
Uma sugestão para melhoria da apropriação seria a automatização
desta atividade da seguinte forma: o analista ao iniciar uma atividade,
independente de ter recebido SM ou não, iniciaria em um sistema uma
espécie de cronômetro que permitisse pausar no momento em que a
atividade fosse interrompida por qualquer que seja o motivo (sair para
ir o banheiro, beber água ou até mesmo se chegar alguém para
conversar), desta forma o sistema marcaria exatamente o tempo que
este analista passou em cada atividade, a qual já seria sincronizada
com a ferramenta que contabiliza as apropriações, restando apenas ao
analista, no final do mês, submeter seus horário contabilizados. A
falta de credibilidade na apropriação não se dá pelo fato da ferramenta
não gerar indicadores significativos, mas sim pelo fato das pessoas
não apropriarem com sinceridade e responsabilidade.
Tarefas sem SM
Problemas na Ferramenta
Sensibilizar funcionários sobre importância e impacto da apropriação
na gestão
Falta de Entendimento/Conscientização
da Importância e Impacto
Informar na SM a macroatividade, o tipo de insumo e projeto no qual
o funcionário deve apropriar.
Tarefas sem SM
Problemas na Ferramenta
Criar uma consulta para o funcionário informando o total de horas
apropriadas em cada dia trabalhado
Problemas de Comunicação/Orientação
Integração das transações do SGI Problemas na Ferramenta
Maior integração do SGI com o Siscop Problemas na Ferramenta
Convencer a equipe da importância da apropriação correta. A maioria
apropria só porque é obrigatório.
Falta de Entendimento/Conscientização
da Importância e Impacto
Divulgar melhor a sistemática de apropriação através de workshop
para mostrar a sua importância.
Problemas de Comunicação/Orientação
Divulgar melhor a sistemática Problemas de Comunicação/Orientação
Permitir a apropriação diretamente no solicita (O SGI seria mantido
para a apropriação de outras atividades fora do projeto).
Problemas na Ferramenta
Verificação de até que ponto a baixa apropriação não é fruto de uma
produtividade alta e se a "necessidade de apropriação" não faz o
colaborador reduzir sua própria produtividade.
-
O indivíduo segue o grupo: o envio da consulta "horas apropriadas
por subordinado" para a equipe via e-mail poderia ser uma forma de
cada um comparar sua apropriação à dos outros (ou, para evitar
constrangimentos, poderia ser a média por equipe apenas).
Falta de Acompanhamento das
Lideranças
Divulgar os efeitos negativos da baixa apropriação e como isso afeta
cada colaborador.
Falta de Entendimento/Conscientização
da Importância e Impacto
A cada evento deveria ser divulgada imediatamente a forma de
apropriação
Problemas de Comunicação/Orientação
Criação de políticas de gratificação com foco na apropriação efetiva e
de qualidade
-
Melhor acompanhamento da evolução individual da apropriação Falta de Acompanhamento das
Lideranças
Realizar pesquisa para levantamento de dificuldades para apropriar -
Tratar sobrecarga de recurso através da redistribuição de tarefas Falta de Acompanhamento das
Lideranças
106
Tabela 6.8 – Sugestões de Ações para Tratamento dos Problemas (Continuação)
Descrição da Sugestão Causa Associada
Automatizar apropriação de algumas atividades Problemas na Ferramenta
Construir ferramentas de apropriação mais amigáveis, de fácil
utilização.
Problemas na Ferramenta
Permitir um período maior para finalizar a apropriação para efetuar
correções após o final do mês.
-
Lideranças orientarem a apropriação sempre que possível, por
exemplo, ao concluir uma reunião ou evento informar onde apropriar.
Falta de Acompanhamento das
Lideranças
Problemas de Comunicação/Orientação
Criar indicador de atraso de apropriação que faça parte também do
desempenho individual ou premiação para aqueles que apropriam
tempestivamente como estímulo.
-
Estas sugestões foram consideradas de grande valia para o grupo, servindo como
insumo para o brainstorming realizado entre o facilitador e os decisores, onde foram
elencadas as soluções prioritárias para tratamento do problema, conforme segue:
• Realizar reunião de conscientização: tem o propósito de mostrar para a
equipe a importância da apropriação de cada um e os impactos em cada nível
organizacional. Nesta reunião, também deve haver uma orientação sobre a
forma correta de apropriar, bem como estimular a disciplina de realizar as
apropriações diariamente.
• Realizar acompanhamento semanal: tem o propósito de sistematizar o
acompanhamento das apropriações numa periodicidade semanal pelos líderes
de projeto. Como forma de apoiar este acompanhamento, o Escritório de
Projetos deverá verificar as apropriações das equipes, de forma a elencar as
pessoas que estão com alto percentual de inoperância e informar para as
lideranças.
• Realizar informe semanal: tem o propósito de, semanalmente, comunicar a
todos, via e-mail, como deve ser feita a apropriação dos principais eventos
realizados durante a semana. Este mesmo informe deve conter pequenas dicas
e informações constantes na sistemática para que sejam conhecidas e
apropriações comuns organizadas por papéis.
107
• Orientar a forma de apropriar após realização de eventos: consiste em
enviar orientação via e-mail sobre a forma de apropriar sempre que um evento
(reunião, palestra, treinamento etc) ocorrer.
6.4.2.3
PASSO D3: ELABORAR E EXECUTAR O PLANO DE AÇÃO
Com as soluções definidas, o Plano de Ação foi elaborado pelo facilitador e decisores
de acordo com a técnica 5W1H, conforme podemos ver na Tabela 6.9.
Tabela 6.9 – Plano de Ação
Causa
O que fazer? Por quê? Quem? Onde? Como? Quando?
- Falta de
Entendimento/Consc
ientização da
Importância e
Impacto
- Problemas de
Comunicação/Orient
ação
Realizar
reunião de
conscientização
As pessoas não sabem qual
a utilidade do indicador
Gerente
Sênior
Sala de
Reunião
1
Através de
reunião com
todos os
funcionários
Janeiro
- Falta de
Acompanhamento
das Lideranças
- Falta de Disciplina
- Problemas de
Comunicação/Orient
ação
Realizar
acompanhamen
to semanal
Não há atualmente um
acompanhamento rigoroso
das apropriações.
Geralmente, esta atividade é
feita mensalmente, não
permitindo tomar ações
efetivas no prazo.
Líderes
Local de
Trabalho
de cada
Funcioná
rio
Através de
avaliação
individual e
conversa com
as pessoas que
não estão
apresentando
os resultados
desejáveis.
Constante
(Logo após
reunião de
conscientiz
ação)
- Problemas de
Comunicação/Orient
ação
- Falta de
Entendimento/Consc
ientização da
Importância e
Impacto
- Falta de Disciplina
Realizar
informe
semanal
As pessoas têm dúvidas
sobre em quais atividades
devem apropriar. Além
disso, poucos conhecem a
sistemática de apropriação.
Escritório
de
Projetos
-
Através de E-
mail
Constante
(Logo após
reunião de
conscientiz
ação)
- Problemas de
Comunicação/Orient
ação
- Falta de
Acompanhamento
das Lideranças
Orientar a
forma de
apropriar após
realização de
eventos
Por não saberem onde
apropriar após a realização
de um evento (palestras,
reuniões, etc), as pessoas
deixam para apropriar
posteriormente e, acabam
não apropriando, ou,
apropriam indevidamente.
Líderes
Escritório
de
Projetos
-
Através de E-
mail
Constante
(Logo após
reunião de
conscientiz
ação)
108
Vale destacar a importância de iniciar o plano de ação com a reunião de
conscientização, onde a Gerência Sênior discorrerá sobre a relevância do indicador,
alinhamento da forma de realização das apropriações bem como para dirimir as eventuais
dúvidas dos funcionários. Isso ratifica a importância da análise de sensibilidade para
avaliação das prioridades diante das variações de pesos para os critérios.
A execução das ações deve ser realizada conforme o plano de ação e, devido à
indisponibilidade de tempo, não será coberta nesta dissertação.
6.4.3
CONTROLAR E AGIR
Os passos “Acompanhar e Avaliar os Resultados”, “Divulgar os Resultados” e
“Incorporar as Lições Aprendidas” serão realizados à medida que as ações forem
executadas e os resultados forem obtidos. Não é objetivo deste trabalho acompanhar o
andamento da execução destes passos uma vez que isso requer um tempo adicional, não
disponível para a realização desta dissertação.
No entanto, acreditamos que isto não trará prejuízos ao trabalho, uma vez que estes
passos são simples de executar, e, em alguns casos, estas atividades já são inerentes ao
processo da organização, como é o caso do Serpro.
6.5
ANÁLISE DA EXPERIÊNCIA DE USO DA ABORDAGEM
Nesta seção, apresentamos uma análise crítica da experiência de uso da abordagem
proposta em uma superintendência do Serpro na regional de Fortaleza.
A abordagem se mostrou adequada no que se refere à execução das fases Planejar e
Executar. As fases Controlar e Agir não foram executadas por restrição de tempo para a
entrega desta dissertação, no entanto, estas fases serão executadas na organização no
momento devido. Consideramos, no entanto, que para efeito de uma avaliação inicial da
viabilidade e utilidade da abordagem, foram executados os principais passos e subpassos.
As principais dificuldades e percepções identificadas durante a execução da
abordagem serão descritas a seguir:
109
• Subpasso D1.1 - Investigar as Causas Potenciais do Problema: neste
passo, o facilitador teve dificuldades na realização do brainstorming
individual devido à indisponibilidade de alguns participantes. No entanto,
acreditamos que esta tenha sido a melhor técnica, uma vez que a realização
de uma reunião para realização de brainstorming seria ainda difícil. Além
disso, algumas opiniões e informações foram dadas ao facilitador no
momento em que o mesmo realizava as instruções de preenchimento do
diagrama de causa e efeito. Tais informações se mostraram úteis para maior
entendimento das percepções e dificuldades de cada participante.
• Subpasso D1.2 - Consolidar os Resultados: durante a consolidação dos
resultados, o facilitador encontrou dificuldades no agrupamento de algumas
causas, por estarem relacionadas a mais de um grupo. Assim, buscou-se
incluir a causa no grupo que tivesse o relacionamento mais forte com a
mesma. Em alguns casos, a junção de grupos de causas se mostrou a melhor
solução. A consolidação foi realizada primeiramente pelo facilitador e
revisada pelos decisores, que realizaram algumas modificações. Vimos
como uma vantagem o fato do facilitador fazer este trabalho inicial, uma vez
que requer tempo para a realização, desta forma, o envolvimento dos
decisores aconteceu de forma mais ágil.
• Subpasso D1.5 - Avaliar as Causas: na avaliação das causas, a maior
dificuldade foi no momento do julgamento para preenchimento das matrizes
de juízo de valor, uma vez que as causas muitas vezes estavam relacionadas
a várias categorias e, o facilitador e os decisores tinham que ter muita
atenção para que o julgamento fosse feito de acordo com a categoria da
matriz em questão. O fato de realizar esta atividade com a participação de
três pessoas foi muito relevante, uma vez que os julgamentos eram
discutidos, e, no caso de inconsistências, as melhores opções eram debatidas.
• Subpasso D1.6: Analisar os Resultados: a principal dificuldade encontrada
durante este passo foi relacionada à falta de experiência dos decisores com
relação aos tipos de gráfico uma vez que não houve nenhum tipo de
110
treinamento na ferramenta, e sim, algumas orientações anteriores e durante a
análise.
Os passos/subpassos não citados acima foram executados sem maiores dificuldades.
Todo esse processo foi facilitado devido a um bom planejamento realizado na fase inicial
da abordagem.
Além do exposto, algumas considerações sobre a experiência de uso da abordagem
merecem ser citadas. Antes da sua execução, as pessoas enxergavam as causas do problema
de uma forma diferente, geralmente de acordo com o conhecimento e o papel exercido na
organização. Assim, algumas ações já haviam sido executadas anteriormente, no entanto, os
resultados desejados raramente eram obtidos.
Com a execução da abordagem, foi possível uniformizar o conhecimento e avaliar
as causas reais do problema, considerando os diferentes pontos de vista de cada pessoa. Os
brainstormings realizados foram de grande valia, uma vez que possibilitaram para as
pessoas envolvidas no problema a oportunidade de exporem suas dificuldades e fazerem
sugestões, bem como permitiu a troca de conhecimento.
O resultado da priorização das causas a serem tratadas serviu para conscientizar as
pessoas de que antes de serem executadas várias ações, deve-se primeiramente mostrar qual
a utilidade e impacto da informação. Desta forma, as pessoas passam a saber os reais
motivos da obrigatoriedade de execução da atividade (apropriação).
Vale ressaltar a importância da Gerência Sênior estar realizando esta
conscientização como forma de obter o comprometimento de todos. Algumas orientações já
haviam acontecido anteriormente, no entanto, não tiveram o retorno esperado, uma vez que
houve uma divisão por chefia e as orientações não foram uniformes, sujeitas a várias
interpretações.
Também merece destaque a determinação de um comportamento imparcial por
parte do facilitador que foi fundamental para o emprego desta abordagem, uma vez que os
participantes sentiram-se à vontade para expor suas opiniões e, desta forma, algumas
informações que não eram de conhecimento dos decisores foram obtidas. Assim, o
facilitador se torna um grande conhecedor sobre o assunto.
111
O apoio dos owners para a execução da abordagem foi imprescindível tanto com
relação à disponibilidade de recursos, quanto para aumentar o comprometimento por parte
dos envolvidos.
No que se refere ao apoio ferramental, o Hiview se mostrou adequado,
proporcionando maior facilidade, eliminando cálculos matemáticos e economizando tempo,
o que permitiu uma análise mais rica com a rápida construção de gráficos e figuras que
auxiliam a compreensão do problema.
6.6
CONCLUSÃO
Neste capítulo, foi apresentada uma experiência de execução da Abordagem para
Análise e Resolução de Causas de Problemas em uma organização de software aplicando
multicritério. Foram também apresentadas as principais dificuldades e percepções obtidas
após esta experiência de uso. No próximo capítulo apresentamos as conclusões da
dissertação, suas contribuições e possíveis trabalhos futuros.
Capítulo
7
Conclusão
“Bom mesmo é ter problema na cabeça, sorriso na boca e paz no
coração!”
ARNALDO JABOR
_________________________________________________________________________
Neste capítulo são apresentadas as principais conclusões, limitações e
perspectivas futuras deste trabalho.
7.1 CONSIDERAÇÕES FINAIS
Atualmente as análises e resolução de causas de problemas complexos são um grande
desafio para as organizações de software. As análises, quando realizadas, em geral não focam
suficientemente o problema e suas possíveis causas. Conseqüentemente, são tomadas decisões
erradas, que acabam por não resolver o problema e, em alguns casos, até mesmo agravando-o
ainda mais, pois isto gera retrabalho, insatisfações, aumentando o custo ocasionado pela falta de
qualidade.
Assim, a construção de modelos multicritérios de apoio à decisão, tem sido cada vez
mais utilizada, devido à crescente necessidade de análise dos contextos decisórios
complexos de forma sistemática e formalizada, considerando a natureza multidisciplinar
dos problemas e as conseqüências das alternativas de ações segundo vários pontos de vista.
Desta forma, foi proposta nesta dissertação uma abordagem que auxilia a análise e
resolução de causas de problemas de grande complexidade e incerteza, com resultados que
garantem uma solução razoável e fundamentada. Esta abordagem faz uso da metodologia
multicritério de apoio à decisão, o que permite aos decisores tomar uma decisão com maior
clareza, transparência e segurança, chegando a uma melhor e mais aceitável solução.
113
A abordagem proposta apresentou um conjunto de passos e subpassos que levam a
um aumento de conhecimento por parte do facilitador e dos decisores em relação ao
problema a ser tratado. O problema, por sua vez, é tratado desde o planejamento até a
disseminação por toda a organização, evitando assim a sua recorrência. Além disso, são
propostos modelos de artefatos que visam auxiliar a execução da abordagem.
Vale destacar que, num processo de análise e resolução de problemas, a tarefa do
facilitador é, no mínimo, desafiadora. O facilitador atua de forma imparcial, procurando
fazer com que os decisores cheguem a uma solução comum, além de canalizar as
informações de todos os envolvidos no problema em análise. Sob outro aspecto, ela é
gratificante, pois a equipe, ao final do trabalho, fica entusiasmada com os resultados
apresentados, colocados de forma tão clara no papel, e que resultam, naturalmente, em uma
solução simples.
Os resultados obtidos com a experiência de uso demonstram que o conhecimento
adquirido durante a utilização da abordagem é um ganho de valor inquestionável, tornando
possível o tratamento das reais causas do problema. Além disso, há um aumento do
comprometimento das pessoas que participam do processo por saberem que de alguma
forma estão contribuindo para a melhoria do mesmo.
Através do uso do software Hiview foi possível realizar várias análises, facilitando
assim na identificação coerente das causas do problema. O software proporcionou maior
facilidade, eliminando cálculos matemáticos e economizando tempo, permitindo uma
análise mais rica com a rápida construção de gráficos e figuras que facilitam a compreensão
do problema. Além disso, os gráficos gerados pela ferramenta auxiliam aos gestores a
melhor visualizar as causas do problema e dá respaldo para os mesmos irem em busca de
soluções em níveis hierárquicos superiores.
Conforme vimos, fica claro que os métodos multicritério para apoio à tomada de
decisão agregam um valor substancial à informação, pois, não só permitem a abordagem de
problemas considerados complexos e, por isto mesmo, não tratáveis pelos procedimentos
intuitivo-empíricos usuais, mas também dão ao processo de tomada de decisão clareza e
transparência não disponíveis quando outros métodos de natureza monocritério são
empregados.
114
Ficou evidenciado neste trabalho, o entendimento de que as análises de problemas
devem ser encaradas como oportunidades de aprendizado para seus envolvidos. E, também,
que a aprendizagem deve ser tratada como elemento essencial na correta identificação e
apreciação dos problemas, deixando os decisores mais preparados para enfrentar problemas
complexos nas organizações, o que é um considerável fator competitivo.
Por fim, não podemos deixar de citar a contribuição que esta dissertação faz para a
pesquisa, uma vez que une duas áreas de conhecimento: a engenharia de software com o
multicritério. A experiência de uso realizada mostrou que esta junção é viável e apresenta
ganho, não só na comunidade acadêmica, mas também no dia-a-dia das organizações.
7.2 LIMITAÇÕES
Como limitação desta dissertação, aponta-se o não acompanhamento dos passos
referentes às fases controlar e agir no estudo de caso: acompanhamento e avaliação dos
resultados, divulgação dos resultados e incorporação das lições aprendidas. Estes passos
demandam um tempo maior que o disponibilizado para a conclusão deste trabalho.
Uma outra limitação diz respeito ao fato do modelo ter sido elaborado de maneira
subjetiva através dos julgamentos dos participantes baseado em suas experiências. No
entanto, de acordo com Montibeller Neto (1996), é importante levar em conta a
subjetividade dos envolvidos no processo decisório devido à impossibilidade de se
encontrar a solução ótima (verdadeira) em problemas complexos.
7.3 TRABALHOS FUTUROS
Durante o desenvolvimento e a aplicação da abordagem proposta, algumas
possibilidades de trabalhos futuros foram identificadas:
• Executar os passos de acompanhamento e avaliação dos resultados,
divulgação dos resultados e incorporação das lições aprendidas no problema
estudado no capítulo 5 bem como aplicar a abordagem em outros problemas.
• Criação de uma base de conhecimento genérica para apoiar as tomadas de
decisão.
115
• Avaliar o uso de outras abordagens multicritério de apoio à decisão para a
abordagem.
• Definir um processo de adaptação da abordagem de acordo com as
características do problema.
• Acrescentar a técnica de raciocínio baseado em casos à abordagem proposta.
116
REFERÊNCIAS BIBLIOGRÁFICAS
[AHERN, 2003] AHERN, Dennis M.; CLOUSE, Aaron; TURNER, Richard.
CMMI Distilled
:
A Practical Introduction to Integrated
Process Improvement. 2
nd
ed. Addison Wesley, 2003.
[ALBUQUERQUE, 2008] ALBUQUERQUE, Adriano B.
Avaliação e Melhoria de
Ativos de Processos Organizacionais em Ambientes de
Desenvolvimento de Software
. Tese de Doutorado,
COPPE/UFRJ, Rio de Janeiro, 2008.
[AL-SHEHAB et al., 2005] AL-SHEHAB, A. J.; HUGHES, R. T.; WINSTANLEY, G.
Facilitating Organisational Learning through Causal
Mapping Techniques in IS/IT Project Risk Management
.
Lecture Notes in Computer Science, 3782 NAI, 2005.
[ALTSHULLER, 1999] ALTSHULLER, Genrich.
Innovation Algorithm
: TRIZ,
systematic innovation and technical creativity. Technical
Innovation Ctr, 1999.
[AMMERMAN, 1998] AMMERMAN, Max.
The Root Cause Analysis Handbook
:
A Simplified Approach to Identifying, Correcting, and
Reporting Workplace Errors. Productivity Press, 1998.
[ANDO, 1994] ANDO, Y.
How to Improve Your Process Using "The QC
Story" Procedure.Tokyo: Juse Press, LTD. 1994.
[ANDRADE, 2005] ANDRADE, J. M. S.
Avaliação de Processos de Software
em
ADSOrg
. Dissertação de Mestrado, COPPE/UFRJ, Rio de
Janeiro, 2005.
[ARIOLI, 1998] ARIOLI, Edir Edemir.
Análise e Solução de Problemas
: O
Método da Qualidade Total com dinâmica de grupo. Rio de
Janeiro: Qualitymark, 1998.
[BANA E COSTA, 1990] BANA E COSTA, C. A.
Readings in Multiple Criteria
Decision Aid. Springer-Verlag, Berlim, 1990.
[BANA E COSTA, 1992] BANA E COSTA, C. A.
Structuration, construction et
exploitation dún modèle multicritère d’aide à la décision
.
Tese (Doutorado em Eng. de Sistemas) – Instituto Técnico
Superior, Universidade Técnica de Lisboa, Lisboa, 1992.
117
[BANA E COSTA e
VANSNICK, 1994]
BANA E COSTA, C. A.; VANSNICK, J. C.
MACBETH
: a
theoretical framework for measuring attractiveness by a
categorical based evaluation technique. XIth International
Conference on MCDA. Ago, 1994.
[BANA E COSTA e
VANSNICK, 1995]
BANA E COSTA, C. A.; VANSNICK, J. C.
Uma nova
abordagem ao problema de construção de uma função de
valor cardinal
: MACBETH
.
Investigação Operacional, v. 15.
Jun, 1995.
[BANA E COSTA et al.,
1999]
BANA E COSTA, C. A; ENSSLIN, L.; CORREA, E. C.;
VANSNICK, J. C.
Decision support systems in action
:
integrates application in a multicriteria decision aid process.
European Journal of Operational Research, v. 133, p. 315-335,
1999.
[BANA E COSTA e
CHAGAS, 2002]
BANA E COSTA, C. A.; CHAGAS, M. P.
A career choice
problem
: an example of how to use MACBETH to build a
quantitative value model based on qualitative value
judgments. Accepted for publication in EJOR, 2002.
[BARCLAY, 1984] BARCLAY, S.
HIVIEW software package
. London:
London School of Business, 1984.
[BHANDARI et al., 1993] BHANDARI, I.; HALLIDAY, M.; TARVER, E.; BROWN,
D.; CHAAR, J.; CHILLAREGE, R.
A Case Study of
Software Process Improvement During Development
.
IEEE Transactions on Software Engineering, 19 (12), 1993.
[BOUYSSOU, 1990] BOUYSSOU, D.
Building Criteria
: A prerequisite for
MCDA, in: Bana e Costa, C. A. (Ed.), Readings in Multiple
Criteria Decision Aid, Springer-Verlag, Berlim, 1990.
[BOUYSSOU, 2000] BOUYSSOU, D.; MARCHANT, T.; PIRLOT, M.; PERNI,
P.; TSOUKIÁS, A.; VINCKE, P.
Evaluation and Decision
Models
: A Critical Perspective. Boston: Kluwer Academic,
2000.
[BRASSARD, 1994] BRASSARD, Michael.
Qualidade
: Ferramentas para uma
melhoria contínua. Rio de Janeiro: Qualitymark, 1994.
[CAMPOS, 1992] CAMPOS, V.F.
TQC
: Controle da Qualidade Total no Estilo
Japonês. 2ª. ed. Belo Horizonte: Fundação Christiano Ottoni,
1992.
[CARD, 2005] CARD, D. N.
Defect Analysis
: Basic Techniques for
Management and Learning. Advances in Computers 65, 2005.
118
[CHECKLAND, 1985] CHECKLAND, P. B.
From optimizing to learning
: a
development of systems thinking for the 1990s. Journal of
Operational Research Society, v. 36, Issue 9, 1985.
[CHRISSIS, 2006] CHRISSIS, Mary B.; KONRAD, Mike; SHRUM, Sandy.
CMMI
: Guidelines for Process Integration and Product
Improvement. 2
nd
ed. Boston: Addison Wesley, 2006.
[CHURCHILL, 1990] CHURCHILL, J. Complexity and Strategic Decision-
Making. London: Sage Publications, 1990.
[CMMI-DEV, 2006] CMMI-DEV,
CMMI for Development
, V1.2 model,
CMU/SEI-2006-TR-008. Software Engineering Institute,
2006.
[DAYCHOUM, 2007] DAYCHOUM, Merhi.
40 ferramentas e técnicas de
gerenciamento. Brasport, 2007.
[DIAS et al., 1997] DIAS, L.C.; COSTA, J.P.; CLÍMACO, J.N.
Conflicting
criteria, cooperating processors
– Some experiments on
implementing decision support method on a parallel
computer. Computers & Operations Research, 1997.
[ÉDEN et al., 1983] EDEN, C.; JONES, S.; SIMS, D.
Messing About in
Problems
- An Informal Structured Approach to their
Identification and Management. Pergamon Press, Oxford,
1983
[ENDRES, 1975] ENDRES, A.
An Analysis Of Errors and Their Causes in
System Programs
. ACM Sigplan Notices, Volume 10, Issue
6, 1975.
[ENSSLIN et al., 1997]. ENSSLIN, L.; BANA E COSTA, C.A.; VANSNICK, J.C.;
CORREA, E.C.
Structuring a Real Problem Using a
Multiple Criteria Model
. Proceedings of 13th International
conference on MCDM, Cape Town, South Africa, January,
1997.
[ENSSLIN et al., 1998]. ENSSLIN, L.; DUTRA, A.; ENSSLIN, S. R.
MCDA
: A
constructivist approach to the management of HR at SEA. The
Third International Conference on Multi-Objective
Programming and Goal Programming: Theory and
Applications (MOPGP’98) – Quebec City, Canada, May/June,
1998.
[ENSSLIN et al., 2001] ENSSLIN, L.; MONTIBELLER, G. N.; NORONHA, S. M.
Apoio à decisão
: Metodologia para Estruturação de
Problemas e Avaliação Multicritério de Alternativas.
119
Florianópolis: Insular, 2001.
[ENSSLIN, 2002] ENSSLIN, S.R. A incorporação da perspectiva sistêmico-
sinérgica na metodologia MCDA construtivista
: uma
ilustração de implementação. Tese (Doutorado em Eng. de
Produção) – Universidade Federal de Santa Catarina,
Florianópolis, 2002.
[FARIAS, 2002] FARIAS, L.
Planejamento de Riscos em Ambientes de
Desenvolvimento de Software Orientados à Organização.
Dissertação de Mestrado, COPPE/UFRJ, Rio de Janeiro,
2002.
[FLAMENT, 1999] FLAMENT, M.
Glossário multicritério
. Red Iberoamericana
de Evaluación y Decisión Multicritério, Espanha, 1999.
Disponível em: <www.unesco.org.uy/redm/glosariom.htm>.
Acesso em: 04 jul 2008.
[FLORAC e CARLETON,
1999]
FLORAC, W.A.; CARLETON, A.D.
Measuring the
Software Process
– Statistical Process Control for Software
Process Improvement. Addison-Wesley, 1999.
[FORD, 1999] FORD Motor Company.
Training-manual for the G-8D
Process. Germany, 1999.
[GAV, 1998] GAV.
Manual de metodologia de Superação de Barreiras
–
BIM. Florianópolis: UFSC, 1998.
[GONÇALVES et al., 2006] GONÇALVES, F. Márcia G. S. et al
.
Multicriteria Model
for Selection of Automated System Tests
. Proceedings of
the International Conference on Research and Practical Issues
of Enterprise Information Systems (CONFENIS), Viena -
Áustria, 2006.
[GONÇALVES et al., 2007] GONÇALVES, F. Márcia G. S.; PIRES, Carlo G. S.;
BEZERRA, Carla Ilane M.; COELHO, Ciro C.
MiniDMAIC:
An Approach for Causal Analysis and Resolution in
Software Development Projects
. Proceedings of the
Australian Conference on Software Engineering
(ASWEC),
2007.
[GONÇALVES et al., 2008] GONÇALVES, F. Márcia G. S.; ALBUQUERQUE, Adriano;
B; FARIAS, Daniele O.; ROGÉRIO, Plácido P.
Causes of
Problems on Software Organizations: a Multiple Criteria
Approach to Analysis and Resolution
. Proceedings of the
International Joint Conferences on Computer, Information,
and Systems Sciences, and Engineering (CISSE), 2008.
120
[GOMES e MOREIRA,
1998]
GOMES, L. F. M.; MOREIRA, A. M. M.
Da informação à
tomada de decisão: agregando valor através dos métodos
multicritério
. RECITEC, Recife, v. 2, n. 2, 1998. Disponível
em: <www.fundaj.gov.br/rtec/res/res-001.html>. Acesso em:
05 jul. 2008.
[GRIFO, 1997] GRIFO, Equipe.
A metodologia de análise e solução de
problemas. 2ª. ed. São Paulo: Editora Pioneira, 1997.
[GRIMALD e MANCUSO,
1994]
GRIMALDI, R.; MANCUSO, J.H.
Qualidade Total
. Folha
de SP e Sebrae, 6º e 7º fascículos, 1994.
[HALL, 1995] HALL, E. M.
Proactive risk management methods for
software engineering excellence
. PhD thesis, Florida
Institute of Technology, Melbourne, FL, USA, 1995.
[HAYES, 2006] HAYES, J. R.
The Complete Problem Solver
. 2
nd
ed.
Lawrence Erlbaum, 1989.
[HENING e BUCHANAN,
2004]
HENING, M.; BUCHANAN, J.
Decision making by
multiple criteria
: a concept of solution, 2004. Disponível em:
<http://www.mngt.waikato.ac.nz/depts/mnss/john/procon.htm
>. Acesso em: 01 jul. 2008.
[HIVIEW, 2008] HIVIEW. Disponível em
<http://www.catalyze.co.uk/?id=230>. Acesso em: 05 jul.
2008.
[HOSOTANI, 1992] HOSOTANI, K.
The QC Problem Solving Approach
Solving Worplace Problems the Japanese Way
. 3A
Corporation, Tokyo, Japan, 1992.
[ISHIKAWA, 1976] [ISHIKAWA, 1976] ISHIKAWA, K.,
Guide to Quality
Control. Asian Productivity Organization. Tokyo, 1976.
[ISO/IEC 12207, 2004]
ISO/IEC 12207
:1995/Amd 2:2004, Information Technology -
Software Life Cycle Process, Amendment 2. Genebra: ISO,
2004.
[ISO/IEC 15504, 2003] ISO/IEC 15504.
Technology Information
– Process
Assessment. Part 1 to Part 5. International Organization for
Standardization, 2003-2005.
[JACOBS et al., 2004] JACOBS, J.C., VAN MOLL, J.H., KRAUSE, P.J.,
KUSTERS, R.J., TRIENEKENS, J.J.M.
Effects of Virtual
Development on Product Quality
: Exploring Defect Causes.
Proceedings of the 11th Annual International Workshop on
Software Technology and Engineering Practice (STEP’04),
121
2004.
[JALOTE e AGRAWAL,
2005]
JALOTE, P.; AGRAWAL, N.
Using Defect Analysis
Feedback for Improving Quality and Productivity in
Iterative Software Development
. Invited paper, 3rd
International Conference on Information and Communication
Technology, ICICT, Cairo, 2005.
[JURAN, 1974] JURAN, J. M. Controle de Qualidade –
Métodos Estatísticos
Clássicos Aplicados à Qualidade. Volume VI, McGraw-
Hill, 1974.
[JURAN, 1992] JURAN, J. M.
Controle da qualidade Handbook
. vol. VI.
São Paulo: Makron Books, 1992.
[KASSE, 2004] KASSE, Tim.
Practical Insight into CMMI
. Cambridge,
Massachusetts: Artech House Publishers, 2004.
[KEPNER e TREGOE,
1981]
KEPNER, C. H.; TREGOE, B. B.
O administrador racional
- uma abordagem sistemática à solução de problemas e
tomada de decisões. São Paulo: Atlas, 1981.
[LAXXUS, 2005] LAXXUSS,
Multiple Criteria Decision
Analysis - State Of
The Art Surveys, Boston: Springer, 2005.
[LESZAC et al., 2000] LESZAK, M., PERRY, D. E., STOLL, D.
A Case Study in
Root Cause Defect Analysis
. Proceedings of the International
Conference on Software Engineering (ICSE 2000), Limerick,
2000.
[MCGREGOR, 1961] MCGREGOR, D.
The Human Side of Enterprise.
McGrawHill, 1961.
[M-MACBETH, 2005]
M-MACBETH
– Guia do Utilizador, 2005. Disponível em
<http://www.m-macbeth.com/index.html>. Acesso em: 05 jul.
2008.
[MONTIBELLER NETO,
1996]
MONTIBELLER NETO, G.
Mapas Cognitivos: uma
Ferramenta de Apoio à Estruturação de Problemas.
Dissertação de Mestrado. Programa de Pós-Graduação em
Engenharia de Produção. Florianópolis: UFSC, 1996.
[OLIVEIRA, 1996] OLIVEIRA, S. T.
Ferramentas para o aprimoramento da
Qualidade. São Paulo: Ed. Pioneira, 1996.
[OZERNOY, 1992] OZERNOY, Vlademir M.
Choosing the “Best” multiple
criteria decision making method. INFOR, v. 30, n.2, 1992.
122
[PARIS, 2003] PARIS, Wanderson Stael.
Proposta de uma metodologia
para identificação de causa raiz e solução de problemas
complexos em processos industriais
: um estudo de caso.
Dissertação (Mestrado). Curitiba: UFPA, 2003. Disponível
em: <
http://www.pgmec.ufpr.br/dissertacoes/dissertacao_019.pdf >.
Acesso em: 04 jul. 2008.
[PARNES, 1963] PARNES, Sidney J.
The deferment of judgement principle
:
a clarification literature. Psychological Report, Southern
University Press, n.12, Apr, 1963.
[ROCHA et al, 2001] ROCHA, A. R. et al.
Qualidade de
Software - Teoria e
Prática. Prentice Hall, 2001.
[ROSENHEAD, 1989] Rosenhead, J.
Rational Analysis for a Problematic
World -
Problem Structuring Methods for Complexity, Uncertainty
and Conflict. John Wiley & Sons, 1989.
[ROY e VANDERPOOTEN,
1996]
ROY, B.; VANDERPOOTEN, D.
The European School of
MCDA
: Emergence, Basic Features and Current Works.
Journal of Multi-Criteria Decision Analysis, 1996.
[ROY, 1985] ROY, B.
Méthodologie multicritère d'aide à la décision
.
Paris: Economica, 1985.
[SCHMIDT, 1995] SCHMIDT, Â. M. A.
Processo de apoio à tomada de
decisão
– Abordagens: AHP e MACBETH. Dissertação
(Mestrado). Florianópolis: UFSC, 1995. Disponível em:
<www.eps.ufsc.br/disserta/engait95.html>. Acesso em: 04 jul.
2008.
[SERPRO, 2008] Página do SERPRO.
Quem somos
. Disponível em:
<http://www.serpro.gov.br/>. Acesso em: 06 ago. 2008.
[SINGH, 1999] SINGH, Raghu.
International Standard ISO/IEC 12207
Software Life Cycle Processes
. Federal Aviation
Administration, 1999. Disponível em:
<http://www.abelia.com/pubsmain.htm>. Acesso em: 15 jul.
2008.
[SMITH, 1998] SMITH, G.F.
Quality Problem Solving
. Milwaukee: ASQ
Quality Press, 1998.
[SOARES, 2003] SOARES, S. R.
Análise multicritério com instrumento de
gestão ambiental
. Dissertação (Mestrado). Florianópolis:
UFSC, 2003. Disponível em: <www.ens.ufsc.br/~soares>.
123
Acesso em: 05 jul. 2008.
[SOFTEX, 2007a] SOFTEXa.
Melhoria de Processo de Software
Brasileiro -
Guia Geral. Versão 1.2, 2007.
D
isponível em:
<http://www.softex.br/mpsbr>. Acesso em: 26 abr. 2008.
[SOFTEX, 2007b] SOFTEXb.
Guia de
Implementação – Parte 7: Nível A, 2007.
Disponível em: http://www.softex.br/mpsbr. Acesso em: 26
abr. 2008.
[SOUZA, 1999] SOUZA, F. C. B. (1999).
Sistema de apoio à decisão em
ambiente espacial aplicado em um estudo de caso de
avaliação de áreas destinadas para disposição de resíduos
sólidos na região metropolitana de Porto Alegre.
Dissertação (Mestrado). Florianópolis: UFSC, 1999.
Disponível em: <www.eps.ufsc.br/teses99/teses99.htm>.
Acesso em: 30 jun. 2008.
[TEMA, 2006]
Um modelo para as soluções
. Brasília, ed. 184, mar-abril, 2006.
Disponível em:
<http://www.serpro.gov.br/imprensa/publicacoes/Tema/tema_18
4/materias/um-modelo-para-as-solucoes>. Acesso em: 06 ago.
2008.
[THOMAZ, 2000] THOMAZ, João Pedro da Cruz Fernandes.
Concepção de um
modelo multicritério de apoio à decisão para a
determinação da localização, a nível nacional, de centros
de informação e recrutamento de voluntários para as
forças armadas.
Dissertação de Mestrado, Universidade
Lusíada, Lisboa, Portugal, 2000.
[THOMAZ, 2005] THOMAZ, João Pedro da Cruz Fernandes.
O Apoio à
Tomada de Decisão na Avaliação do Desempenho de
Pessoas:
Contributos para o Processo de Decisão Militar em
Tempo de Paz. Tese de Doutorado, Instituto Superior Técnico,
Universidade Técnica de Lisboa, 2005.
[VASCONCELOS, 2001] VASCONCELLOS, L.
Construção do modelo de avaliação
do desempenho de uma indústria de conservas utilizando a
metodologia MCDA para gerar alternativas
. Dissertação de
Mestrado. Pós-graduação em Engenharia de Produção –
Universidade Federal de Santa Catarina. Florianópolis, 2001.
[VINCKE, 1992] VINCKE, P.
Multicriteria Decision-aid
. New York: Jhon
Wiley & Sons, 1992.
124
[WEBER et al. 2004] WEBER, K. C., et al.
Modelo de Referência para Melhoria
de Processo de Software
: uma abordagem brasileira. In:
Anais da XXXI Conferência Latino-Americana de Informática
(CLEI 2004), Arequipa - Peru, September/October, 2004.
[WERKEMA, 1995] WERKEMA, M.C.C.
As Ferramentas da Qualidade no
Gerenciamento de Processos
. Belo Horizonte: Fundação
Christiano Ottoni, 1995.
125
Apêndice A
Tabelas Resumo dos Passos da Abordagem
Este apêndice contém tabelas com um resumo dos passos da abordagem proposta,
tendo como propósito ser um guia rápido para auxiliar a sua execução. A estruturação das
tabelas é uma adaptação do padrão estabelecido na norma ISO/IEC 12207.
Passo: P1 - Descrever o Problema
Subpasso:
--
Descrição: Consiste em coletar as informações úteis e necessárias sobre o
problema para dar subsídios às próximas atividades, tais como:
• Histórico do problema
• Quando o problema foi identificado
• Freqüência de ocorrência do problema
• Impacto do problema
• Restrições do problema
• Fontes do problema
• Categorias do problema
Pré-passo: --
Critério de Entrada: Identificação de um problema complexo
Critério de Saída: Problema descrito
Responsáveis: Facilitador
Participantes: Decisor (se necessário)
Produtos Requeridos: Todo e qualquer documento relacionado ao problema
Modelo de Planejamento para o Problema
Produtos Gerados: Planejamento para o Problema
Ferramentas e Técnicas: Processador de Texto
Pesquisa (documentos, pessoas)
Pós-passo: P2 – Formar a Equipe
126
Passo P2 - Formar a Equipe
Subpasso:
--
Descrição:
Consiste em selecionar os membros da equipe de análise e
resolução das causas do problema, identificando os seguintes
papéis:
• Owner
• Facilitador
• Decisor
• Envolvido
Pré-passo: P1 - Descrever o problema
Critério de Entrada: Problema descrito
Critério de Saída: Equipe formada
Responsáveis: Facilitador
Participantes: Owner
Decisor
Produtos Requeridos: Modelo de Planejamento para o Problema
Produtos Gerados: Planejamento para o Problema
Ferramentas e Técnicas: Processador de Texto
Pós-passo: P3 – Definir Objetivos e Metas
Passo: P3 - Definir Objetivos e Metas
Subpasso:
--
Descrição:
Consiste em descrever os objetivos e definir as metas a serem
atingidas com a resolução do problema.
Pré-passo: P2 - Formar a equipe
Critério de Entrada: Equipe Formada
Critério de Saída: Objetivos e metas definidos
Responsáveis: Owner
Participantes: Decisor
Facilitador
Produtos Requeridos: Indicadores (caso possua)
Modelo de Planejamento para o Problema
127
Produtos Gerados: Planejamento para o Problema
Ferramentas e Técnicas: Benchmarking
SMART
Processador de Texto
Pós-passo: D1 - Determinar as Causas do Problema
D1.1 - Investigar as Causas Potenciais do Problema
Passo: D1 - Determinar as Causas do Problema
Subpasso: D1.1 - Investigar as Causas Potenciais do Problema
Descrição:
Consiste na investigação de quais são as causas potenciais do
problema através de brainstorming
individual com os todos os
participantes, fazendo uso de diagramas de causa e efeito.
Pré-passo: P3 - Definir Objetivos e Metas
Critério de Entrada: Objetivos e metas definidos
Critério de Saída: Causas potenciais identificadas
Responsáveis: Facilitador
Participantes: Todos
Produtos Requeridos: Modelo de Diagrama de Causa e Efeito
Produtos Gerados: Diagramas de Causa e Efeito
Ferramentas e Técnicas: Brainstorming Individual
Diagrama de Causa e Efeito
Pós-passo: D1 - Determinar as Causas do Problema
D1.2 - Consolidar os Resultados
Passo: D1 - Determinar as Causas do Problema
Subpasso D2: D1.2 - Consolidar os Resultados
Descrição:
Consiste em listar todas as causas potenciais identificadas e, em
seguida, agrupar os resultados obtidos, descartando as causas
menos prováveis (não relacionadas diretamente ao problema) e
esclarecendo eventuais dúvidas com os participantes. Gráficos
de Pareto também devem ser construídos de forma possibilitar
uma melhor visualização do resultado da consolidação das
causas.
128
Pré-passo: D1 - Determinar as Causas do Problema
D1.1 - Investigar as Causas Potenciais do Problema
Critério de Entrada: Causas potenciais identificadas
Critério de Saída: Causas potenciais consolidadas
Gráficos de Pareto construídos
Responsáveis: Facilitador
Participantes: Decisor
Produtos Requeridos: Diagramas de Causa e Efeito
Produtos Gerados: Lista de Causas Potenciais por Categoria
Lista de Sugestões de Solução
Gráficos de Pareto
Ferramentas e Técnicas: Processador de Texto
Diagrama de Pareto
Reuniões (Discussão com a equipe)
Pós-passo: D1 - Determinar as Causas do Problema
D1.3 - Identificar as Causas Elementares
Passo: D1 - Determinar as Causas do Problema
Subpasso: D1.3 - Identificar as Causas Elementares
Descrição:
Consiste em uma análise para identificação das causas
elementares do problema, ou seja, aquelas que mais contribuem
para o mesmo. Assim, deve ser construído um diagrama de
causa e efeito contendo as causas elementares e destacando as
mais prováveis. Em seguida, deve ser elaborada a árvore de
pontos de vista.
Pré-passo: D1 - Determinar as Causas do Problema
D1.2 - Consolidar os Resultados
Critério de Entrada: Causas potenciais consolidadas
Diagramas de Pareto construídos
Critério de Saída: Diagrama de causa e efeito das causas elementares construído
Árvore de pontos de vista construída
Responsáveis: Facilitador
Participantes: Decisor
129
Produtos Requeridos: Gráficos de Pareto
Produtos Gerados: Diagrama de Causa e Efeito
Árvore de Pontos de Vista
Ferramentas e Técnicas: Hiview
Planilha Eletrônica
Reuniões (Discussão com a equipe)
Pós-passo: D1 - Determinar as Causas do Problema
D1.4 - Construir os Descritores e Identificar os Níveis “Bom” e
“Neutro”
Passo: D1 - Determinar as Causas do Problema
Subpasso:
D1.4 - Construir os Descritores e Identificar os Níveis
“Bom” e “Neutro”
Pré-passo: D1 - Determinar as Causas do Problema
D1.3 - Identificar as Causas Elementares
Descrição:
Consiste na definição de descritores para os critérios (causas)
identificados. Este subpasso pode ser omitido caso seja haja
descritores diretos (ou naturais) para os pontos de vista.
Critério de Entrada: Diagrama de causa e efeito das causas elementares construído
Árvore de pontos de vista construída
Critério de Saída: Descritores construídos e níveis bom e neutro definidos
Responsáveis: Facilitador
Participantes: Decisor
Produtos Requeridos: Árvore de Pontos de Vista
Produtos Gerados: Tabela de Descritores com Nível Bom e Neutro
Ferramentas e Técnicas: Processador de Texto
Hiview
Reuniões (Discussão com a equipe)
Pós-passo: D1 - Determinar as Causas do Problema
D1.5 - Avaliar as Causas
130
Passo: D1 - Determinar as Causas do Problema
Subpasso: D1.5 - Avaliar as Causas
Descrição:
Consiste na comparação das várias causas do problema, a fim de
permitir a escolha mais consciente e mais adequada. Desta
forma, devem ser preenchidas as matrizes de juízo de valor para
cada critério (categoria). Uma matriz contendo a avaliação dos
critérios também deve ser construída para obtenção dos pesos
dos mesmos.
Pré-passo: D1 - Determinar as Causas do Problema
D1.4 - Construir os Descritores e Identificar os Níveis “Bom” e
“Neutro”
Critério de Entrada: Diagrama de causa e efeito das causas elementares construído
Árvore de pontos de vista construída
Descritores construídos e níveis bom e neutro definidos (caso
tenham sido utilizados)
Critério de Saída: Julgamento de valores realizado
Responsáveis: Facilitador
Participantes: Decisor
Produtos Requeridos: Diagrama de Causa e Efeito
Árvore de Pontos de Vista
Tabela de Descritores com Nível Bom e Neutro (se gerados)
Produtos Gerados: Matrizes de juízo de valor
Ferramentas e Técnicas: Hiview
Reuniões (Discussão com a equipe)
Pós-passo: D1 - Determinar as Causas do Problema
D1.6 - Analisar os Resultados
Passo: D1 - Determinar as Causas do Problema
Subpasso: D1.6 - Analisar os Resultados
Descrição:
Consiste em realizar análises com o intuito de apoiar a avaliação
dos resultados. Assim, podem ser feitas análises de
sensibilidade, mapas comparativos entre outras análises de
gráficos disponíveis pela ferramenta, de acordo com a
necessidade.
131
Pré-passo: D1 - Determinar as Causas do Problema
D1.5 - Avaliar as Causas
Critério de Entrada: Julgamento de valores realizado
Critério de Saída: Análises realizadas
Responsáveis: Facilitador
Participantes: Decisor
Produtos Requeridos: Matrizes de Juízo de Valor
Produtos Gerados:
Gráficos de Análise de Sensibilidade, Mapas Comparativos
entre outros gráficos.
Ferramentas e Técnicas: Hiview
Reuniões (Discussão com a equipe)
Pós-passo: D2 – Analisar as Possíveis Soluções
Passo: D2 – Analisar as Possíveis Soluções
Subpasso:
--
Descrição:
Consiste em analisar as sugestões de soluções já realizadas no
Passo D1 e realizar um brainstorming
para elicitar outras
soluções que tratem as causas do problema.
Pré-passo: D1 - Determinar as Causas do Problema
D1.6 - Analisar os Resultados
Critério de Entrada: Análises realizadas
Critério de Saída: Soluções elicitadas
Responsáveis: Facilitador
Participantes: Decisor
Produtos Requeridos:
Gráficos de Análise de Sensibilidade, Mapas Comparativos
entre outros gráficos.
Modelo de Lista de Sugestões de Solução
Produtos Gerados: Lista de Sugestões de Solução (Identificadas no Subpasso D1.1)
Ferramentas e Técnicas: Processador de Texto
Brainstorming
Benchmarking
Entrevistas
Reuniões (Discussão com a equipe)
Pós-passo: D3 – Elaborar e Executar o Plano de Ação
132
Passo: D3 – Elaborar e Executar o Plano de Ação
Subpasso: -
Descrição:
Consiste na elaboração e execução de um plano com as ações
para tratamento do problema.
Pré-passo: D2 – Analisar as Possíveis Soluções
Critério de Entrada: Soluções elicitadas
Critério de Saída: Plano de ação elaborado e executado
Responsáveis: Facilitador
Participantes: Decisor
Envolvido
Produtos Requeridos: Lista de Soluções
Modelo de Plano de Ação
Produtos Gerados: Plano de Ação
Ferramentas e Técnicas: Processador de Texto
Brainstorming
5W1H
Pós-passo: C1 – Acompanhar e Avaliar os Resultados
Passo: C1 – Acompanhar e Avaliar os Resultados
Subpasso:
--
Descrição:
Consiste na monitoração dos resultados obtidos com o intuito de
avaliar se as ações estão tendo o efeito desejado e, após
execução das mesmas, analisar se o problema foi resolvido e se
a meta foi atingida. É realizado um acompanhamento dos
resultados ao longo de um tempo para observar se há
recorrência do problema.
Pré-passo: D3 – Elaborar e Executar o Plano de Ação
Critério de Entrada: Plano de ação elaborado e executado
Critério de Saída: Acompanhamento dos Resultados Realizado
Responsáveis: Facilitador
Participantes: Decisor
Produtos Requeridos: Plano de Ação
Indicadores (caso existam)
133
Modelo de Relatório de Acompanhamento e Avaliação
Produtos Gerados: Relatório de Acompanhamento e Avaliação
Indicadores
Ferramentas e Técnicas: Processador de Texto
Pós-passo: A1– Divulgar os Resultados
Passo: A1– Divulgar os Resultados
Subpasso:
--
Descrição: Consiste em divulgar os resultados obtidos e lições aprendidas.
Pré-passo: C1 – Acompanhar e Avaliar os Resultados
Critério de Entrada: Acompanhamento dos Resultados Realizado
Critério de Saída: Resultados divulgados
Responsáveis: Owner
Participantes: Facilitador
Decisor
Envolvido
Produtos Requeridos: Todos os artefatos gerados
Modelo de Relatório de Resultados
Produtos Gerados: Relatório de Resultados
Ferramentas e Técnicas: Processador de Texto
E-mail
Informe
Reuniões
Treinamentos
Pós-passo: A2 – Incorporar as Lições Aprendidas
134
Passo: A2 – Incorporar as Lições Aprendidas
Subpasso:
--
Descrição:
Diante dos resultados, deve-se fazer uma análise das lições
aprendidas identificadas e, avaliar a necessidade de alterações
nos processos da organização, nas diretrizes e nas políticas, de
forma que os ganhos obtidos não fiquem restritos e sejam
disseminados por toda a organização.
Pré-passo: A1– Divulgar os Resultados
Critério de Entrada: Resultados divulgados
Critério de Saída: Lições Aprendidas documentadas
Responsáveis: Facilitador
Participantes:
Determinado pela organização (em geral esta atividade é
realizada por grupos de processo)
Produtos Requeridos: Todos os artefatos gerados
Modelo de Lista de Lições Aprendidas
Produtos Gerados: Documentos alterados
Lista de Lições Aprendidas
Ferramentas e Técnicas: Processador de Texto
Base de Conhecimentos
Pós-passo: --
135
Apêndice B
Modelos de Documentos Gerados para a Abordagem
Este apêndice contém um conjunto de modelos gerados para auxiliar na execução da
abordagem proposta nesta dissertação.
A.1 – ARTEFATO PARA A FASE “PLANEJAR”
O Modelo de Planejamento para o Problema, apresentado a seguir, contém os
campos necessários para preenchimento das informações requeridas na fase de
planejamento, contemplando assim os passos P1 - Descrever o Problema, P2 - Formar a
Equipe e P3 - Definir Objetivos e Metas.
Registro do Problema - Plan
1. Identificação
Empresa:
Data:
2. Descrição
<Relacionar informações úteis e necessárias sobre o problema, tais como o histórico,
quando foi identificado, freqüência de ocorrência, impacto, restrições, fonte, categorias, etc>
3. Metas
<Definir as metas/submetas a serem alcançadas, atribuindo prazos às mesmas e analisando
136
se são SMART>
Meta Submeta Prazo
4. Equipe
< Informar quais são os membros da equipe de análise e resolução das causas do
problema>
Nome Papel na Organização
Papel na
Abordagem Passos Envolvidos
A.2 – ARTEFATOS PARA A FASE “EXECUTAR”
Os artefatos a seguir auxiliam na execução da fase de execução da abordagem.
A.2.1 – MODELO DE DIAGRAMA DE CAUSA E EFEITO
O Modelo de Diagrama de Causa e Efeito, apresentado a seguir, visa auxiliar a
execução do Subpasso D1.1: Investigar as Causas Potenciais do Problema.
137
Registro do Problema – Do
1. Identificação
Empresa:
Data:
2. Diagrama de Causa e Efeito
<Aplicar diagrama de causa e efeito em cada envolvido com o intuito de identificar as potenciais causas do problema>
138
3. Sugestões de Ações:
139
A.2.2 – MODELO DE LISTA DAS CAUSAS IDENTIFICADAS POR CATEGORIA
O Modelo de Lista de Causas Potenciais, apresentado a seguir, visa auxiliar a
execução do Subpasso D1.1: Investigar as Causas Potenciais do Problema.
Registro do Problema – Do
1. Identificação
Empresa:
Data:
2. Lista de Causas Potenciais por Categoria
<Listar todas as causas identificadas com a
aplicação do diagrama de causa e efeito agrupadas por categoria>
No. Causas Identificadas na Categoria “Pessoas” Grupo
1
2
3
4
No. Causas Identificadas na Categoria “Processo” Grupo
1
2
3
4
No. Causas Identificadas na Categoria “Organização” Grupo
1
2
3
4
No. Causas Identificadas na Categoria “Tecnologia” Grupo
1
2
3
4
140
A.2.3 – MODELO DE GRÁFICOS DE PARETO
O Modelo de Gráfico de Pareto, apresentado a seguir, visa auxiliar a execução do
Subpasso D1.2: Consolidar os Resultados.
Registro do Problema – Do
1. Identificação
Empresa:
Data:
2. Agrupamento das Causas Potenciais por Categoria
<Agrupar as causas potenciais, excluindo
as menos prováveis. Contabilizar a quantidade vezes que a causa foi identificada. Incluir nas tabelas em ordem
decrescente e gerar gráfico de Pareto>
Causas relacionadas
a Pessoas
Nº vezes que foi
identificada
%
<Causa 1>
10
<Causa 2>
5
<Causa 3>
3
Causas relacionadas
à Processo
Nº vezes que foi
identificada
%
<Causa 1>
10
<Causa 2>
5
<Causa 3>
3
141
Causas relacionadas
à Organização
Nº vezes que foi
identificada
%
<Causa 1>
10
<Causa 2>
5
<Causa 3>
3
Causas relacionadas
à Tecnologia
Nº vezes que foi
identificada
%
<Causa 1>
10
<Causa 2>
5
<Causa 3>
3
142
A.2.4 – MODELO DE LISTA DE SUGESTÕES DE SOLUÇÃO
O Modelo de Lista de Sugestões de Solução, apresentado a seguir, visa auxiliar a
execução do Passo D2: Analisar as Possíveis Soluções.
Registro do Problema – Do
1. Identificação
Empresa:
Data:
2. Lista de Sugestões de Solução
<Listar todas as soluções decorrentes da aplicação do
diagrama de causa e efeito (brainstorming individual) informando à qual causa elementar a sugestão
está associada>
Descrição da Sugestão Causa Associada
143
A.2.5 – MODELO DE PLANO DE AÇÃO
O Modelo de Plano de Ação, apresentado a seguir, visa auxiliar a execução do
Passo D3: Elaborar e Executar o Plano de Ação.
Registro do Problema – Do
1. Identificação
Empresa:
Data:
2. Plano de Ação
<Informar as ações que serão executadas para tratar as causas selecionadas de
acordo com os questionamentos realizados na tabela a seguir (5W1H)>
Causa O que fazer? Por quê? Quem? Onde? Como? Quando?
A.3 – ARTEFATOS PARA A FASE “CONTROLAR”
O artefato a seguir auxilia na execução da fase de controle da abordagem.
144
A.3.1 – MODELO DE RELATÓRIO DE ACOMPANHAMENTO E AVALIAÇÃO
O Modelo de Relatório de Acompanhamento e Avaliação, apresentado a seguir, visa
auxiliar a execução do Passo C1 - Acompanhar e Avaliar os Resultados.
Registro do Problema – Check
1. Identificação
Empresa:
Data:
2. Acompanhamento
<Informar os resultados obtidos durante o acompanhamento>
Data Informações sobre o Acompanhamento
3. Avaliação dos resultados
<Avaliar se os objetivos e as metas foram atingidos>
Meta Submeta Avaliação
<Obs.: Caso existam, incluir informações oriundas de indicadores de forma a comparar os
resultados>
145
A.4 – ARTEFATOS PARA A FASE “AGIR”
Os artefatos a seguir auxiliam na execução da fase de ação da abordagem.
A.4.1 – MODELO DE RELATÓRIO DE RESULTADOS
O Modelo de Relatório de Resultados, apresentado a seguir, visa auxiliar a execução
do Passo A1 - Divulgar os Resultados.
Registro do Problema – Act
1. Identificação
Empresa:
Data:
2. Relatório de Resultados
<Fazer um resumo sobre o problema ressaltando os
resultados alcançados. Procurar utilizar gráficos ou imagens.>
146
A.4.2 – MODELO DE LISTA DE LIÇÕES APRENDIDAS
O Modelo de Lista de Lições Aprendidas, apresentado a seguir, visa auxiliar a
execução do Passo A2 - Incorporar as Lições Aprendidas.
Registro do Problema – Act
1. Identificação
Empresa:
Data:
2. Lista de Lições Aprendidas
<Listar todas as lições aprendidas obtidas durante a
execução da abordagem.>
Lição Aprendida Passo
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
