Ps-Graduao em Cincia da Computao

Problemas em Iniciativas de Melhoria de Processos de

Software sob a tica de uma Teoria de Interveno

Por

Andr Felipe Lemos Santana

Dissertao de Mestrado






Universidade Federal de Pernambuco
posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao


Recife, Maro/2007
Universidade Federal de Pernambuco
Centro de Informtica
Programa de Ps Graduao em Cincia da Computao








Andr Felipe Lemos Santana








Problemas em Iniciativas de Melhoria de Processos de
Software sob a tica de uma Teoria de Interveno





Dissertao apresentada como requisito parcial
obteno do grau de Mestre em Cincia da
Computao, rea de concentrao em Enge-
nharia de Software, do Programa de Ps Gra-
duao em Cincia da Computao do Centro
de Informtica da Universidade Federal de
Pernambuco.

Orientador: Hermano Perrelli de Moura, PhD.








Recife, Maro/2007































i
Ao meu pai, Raul Santana Sobrinho (em memria)
e minha me, Zilda lemos Santana
ii
AGRADECIMENTOS


A Hermano Perrelli de Moura, meu orientador, pela oportunidade, confiana e
apoio neste trabalho.
A Antnio Carlos Valena a quem, alm da honra de compor a minha banca de
avaliao, atravs do visionrio Programa de Formao de Consultores Organizacio-
nais de Valena & Associados Aprendizagem Organizacional, devo grande parte de
meu conhecimento em cincia da ao, que usei como vis interpretativo desta pes-
quisa.
s minhas queridas esposa Ins e irm Poliana, pelas preciosas revises e opi-
nies em alguns captulos deste texto.
s pessoas queridas que deram apoio fundamental em transcries de entrevis-
tas da pesquisa: Ins Gama, Priscila Santana, Natlia Oliveira, Masa Alves, Daniele
Amaral e Ediane Souza.
Aos amigos que em algumas conversas me possibilitaram algumas reflexes
importantes para o encaminhamento da pesquisa: Guilherme Moura, Ana Clara Vi-
nhas, Antnio Carlos Valena, Joo Gratuliano e os professores do DCA/UFPE Pedro
Lincoln e Gilson Ludmer.
Aos professores e amigos de mestrado e do CIn-UFPE cuja excelncia e ami-
zade me estimularam na busca de concluir este trabalho, em especial s equipes do
Maracatu Rob Futebol Clube, da fbrica Engenho de Software e do Projeto
SmartSim.
Agradecimento muito especial aos profissionais entrevistados nesta pesquisa
(que por um compromisso de pesquisa no posso nomear) pela colaborao, abertura e
generosidade.
A Deus e ao Universo pelo aqui e agora de poder realizar este trabalho.

iii
RESUMO

Iniciativas de melhoria de processos de software (MPS) tm tido uma impor-
tncia cada vez maior na indstria de software como fator de evoluo da qualidade de
seus produtos e de combate alta taxa de insucesso em projetos desta indstria. Pes-
quisas mostram que as iniciativas de MPS, por sua vez, tambm tm uma alta taxa de
insucesso. Mostram tambm, que vrios dos principais fatores crticos em MPS no
so questes tcnicas de engenharia de software e sim questes humanas, sociais e
organizacionais, relativas conduo das iniciativas de melhoria, e interao entre
seus participantes.
Esta dissertao mostra que iniciativas de MPS podem ser vistas como uma in-
terveno na organizao que produz software. A teoria de interveno e conceitos
complementares de teorias de ao e de aprendizagem organizacional do cientista
social Chris Argyris e seus colaboradores so usados nesta dissertao para reinterpre-
tar e compreender mais profundamente os problemas scio-tcnicos de iniciativas de
MPS. So particularmente apontados como problemas que permeiam iniciativas de
MPS: a incongruncia das normas internalizadas da organizao com os objetivos da
interveno de MPS; a dificuldade dos atores em lidar produtivamente com situaes
conflitivas; a incongruncia da teoria em uso dos atores para com as atividades pri-
mrias de interveno preconizadas por Argyris; e finalmente, as limitaes da abor-
dagem predominantemente tcnica na conduo da interveno de MPS. A mesma
abordagem terica utilizada como base para prescrio de estratgias de ao de co-
mo tratar os problemas levantados.
A interpretao dos problemas tomou por base uma pesquisa de campo sobre
fatores crticos (facilitadores e barreiras) em iniciativas de MPS. A pesquisa foi reali-
zada com entrevistas a profissionais desempenhando vrios papis (engenheiros da
qualidade, consultores externos, diretor, gerentes de projetos e engenheiros de softwa-
re) e que estiveram envolvidos em iniciativas de MPS em suas empresas. Esta disser-
tao contribui, assim, para preencher uma lacuna comumente encontrada na conduo
de iniciativas MPS, que usam modelos normativos tais como CMMI e MPS.Br, quanto
ao entendimento e tratamento dos fenmenos humanos e sociais inerentes a este tipo
de iniciativa.

iv
Palavras-chave: melhoria de processos de software (MPS), fatores crticos em MPS,
teoria de interveno, teorias de ao, aprendizagem organizacional.
v
ABSTRACT

Software process improvement initiatives (SPI) are gaining great importance in
the software industry as a factor of evolution of the quality of its products and as a
response to the high rate of failure in software projects. Research shows that MPS ini-
tiatives have also a high rate of failure. They show also that many of the main critical
factors in SPI are not technical issues of software engineering, but human, social and
organizational issues in the conduction of improvement initiatives, and interactions
among its participants.
This dissertation shows that SPI initiatives can be viewed as an intervention in
the organization that produces software. The intervention theory and complementary
concepts of theories of action and organizational learning from the organizational
researcher Chris Argyris and its collaborators are used in this dissertation to reinterpret
and to understand more profoundly the socio-technical problems of SPI initiatives. As
problems that occur besides SPI initiatives it is emphasized: incongruence of norms
internalized in the organization with the objectives of SPI intervention; the actors
difficulties in leading productively with conflictive situations; incongruence of actors
theory in use with primary activities of intervention recommended by Argyris; and
finely, the limitations of technicist approach that predominates in conducting SPI in-
terventions. That same theoretical approach is used as a basis to prescribe actions
strategies of how to deal with the referred problems.
The interpretation of the problems was based in a field research about critical
factors (facilitators and barriers) in SPI initiatives. The research was performed by
interviewing professionals in different roles (quality engineers, external consultants,
director, project managers and software engineers) and which were involved in SPI
initiatives in their organizations. In this way, this dissertation contributes to fill gaps
commonly encountered in conducting SPI initiatives that use normative models like
CMMI and MPS.Br, in understanding and dealing with human and social phenomena
in this kind of initiative.

Key-words: software process improvement (SPI), critical factors in SPI, intervention
theory, action theories, organizational learning.

vi
LISTA DE FIGURAS

Figura 2.1: Ciclo de vida e disciplinas do Rational Unified Process

.................................................. 8
Figura 2.2: Elementos conceituais bsicos do RUP. ............................................................................ 9
Figura 2.3: Frameworks voltados para, ou que influenciam MPS...................................................... 12
Figura 2.4: Componentes de um modelo CMMI. ............................................................................... 17
Figura 2.5: Fases e atividades do modelo IDEAL. ............................................................................. 23
Figura 2.6: Infra-estrutura organizacional para MPS. ........................................................................ 26
Figura 3.1: Diagrama causal entre Fatores Crticos em MPS a partir de relato de entrevista. ............ 46
Figura 3.2: Arqutipo do Limite ao Sucesso em MPS na pesquisa em Recife parte 1 .................... 48
Figura 3.3: Arqutipo do limite ao sucesso em MPS na pesquisa em Recife parte 2 ...................... 48
Figura 3.4: Arqutipo do Limite ao Sucesso em MPS na pesquisa em Recife completo ................ 49
Figura 3.5: Arqutipo da transferncia do fardo em MPS na pesquisa em Recife parte 1. ............. 50
Figura 3.6: Arqutipo da transferncia do fardo em MPS na pesquisa em Recife parte 2. ............. 51
Figura 3.7: Arqutipo da transferncia do fardo em MPS na pesquisa em Recife parte III. ........... 52
Figura 3.8: Arqutipo da transferncia do fardo em MPS na pesquisa em Recife completo. .......... 53
Figura 3.9: Arqutipo dos adversrios acidentais em MPS na pesquisa em Recife parte 1............ 54
Figura 3.10: Arqutipo dos adversrios acidentais em MPS na pesquisa em Recife parte 2. ......... 55
Figura 3.11: Arqutipo dos adversrios acidentais em MPS na pesquisa em Recife (completo). ..... 56
Figura 4.1: Esquema geral expandido da Teoria de Ao. ................................................................. 64
Figura 4.3: Dimenses da teoria de Ao........................................................................................... 65
Figura 4.4: Ciclo de relaes causais entre as tarefas primrias. ........................................................ 67
Figura 4.5: Componentes do Comprometimento................................................................................ 71
Figura 4.6: Aprendizagem de ciclo nico e ciclo duplo no esquema da teoria de ao. ..................... 78
Figura 4.7: Ciclo de reforo vicioso pelo encadeamento de Erros de 1
a
e 2
a
Ordens.......................... 81
Figura 6.1: Modelo Cclico de Interveno com base em Pesquisa-Ao........................................ 129
Figura C.1: Estrutura genrica do arqutipo da limitao ao crescimento. ...................................... 174
Figura C.2: Estrutura genrica do arqutipo da transferncia do fardo. ........................................... 175
Figura C.3: Estrutura genrica do arqutipo dos adversrios acidentais. ........................................ 176

vii
LISTA DE QUADROS

Quadro 2.1: CMMI em estgios - nveis de maturidade e reas de processos associadas. ................ 15
Quadro 2.2: CMMI contnuo - nveis de capacidade para uma rea de processo............................... 16
Quadro 2.3: Estatstica de pases com avaliaes oficiais nos modelos CMMI e CMM.................... 19
Quadro 2.4: Correspondncia entre o CMMI e MR-MPS (MPS.Br) ................................................. 20
Quadro 2.5: Tipos de evidncias objetivas consideradas no SCAMPI............................................... 22
Quadro 2.6(a): Descrio resumida das atividades do modelo IDEAL.............................................. 24
Quadro 2.6(b): Descrio resumida das atividades do modelo IDEAL. ............................................ 25
Quadro 2.7: Tempo mdio para passagem de nveis de maturidade no modelo SW-CMM. .............. 29
Quadro 2.8: Resultados de Performance de Retorno do CMMI em casos reais. ................................ 29
Quadro 3.1: Caractersticas dos entrevistados.................................................................................... 35
Quadro 3.2: Caractersticas das empresas dos entrevistados. ............................................................. 36
Quadro 3.3: Sntese temtica de fatores crticos em MPS. ................................................................. 37
Quadro 3.4: Facilitadores em MPS comparao com outras pesquisas........................................... 39
Quadro 3.5: Barreiras em MPS comparao com outras pesquisas................................................. 40
Quadro 3.6: Natureza dos fatores crticos identificados na pesquisa. ................................................ 45
Quadro 4.1: Esquema geral de uma Teoria de Ao. ......................................................................... 63
Quadro 5.1(a): Fatores crticos em MPS relacionados s Tarefas Primrias de Interveno. ............ 94
Quadro 5.1(b): Fatores crticos em MPS relacionados s Tarefas Primrias de Interveno. ............ 95
viii
SUMRIO

1 INTRODUO............................................................................................................................................ 1
1.1 MOTIVAO E CONTEXTO DA PESQUISA .............................................................................................. 1
1.2 OBJETIVOS DA PESQUISA....................................................................................................................... 3
1.3 ESTRUTURA DA DISSERTAO .............................................................................................................. 3
2 MELHORIA DE PROCESSOS DE SOFTWARE ................................................................................... 6
2.1 PROCESSOS DE SOFTWARE .................................................................................................................... 7
2.1.1 Ilustrando os Componentes de um Processo de Software atravs do RUP.................................. 8
2.2 MODELOS DE REFERNCIA PARA MELHORIA DE PROCESSOS DE SOFTWARE........................................ 10
2.2.1 Um Exemplo de Modelo de Maturidade para MPS: Capability Maturity Model
Integration (CMMI) ......................................................................................................................................... 13
2.2.2 Um Exemplo de Modelo para Avaliao de Processos: Standard CMMI Appraisal
Method for Process Improvement (SCAMPI) .................................................................................................. 20
2.2.3 Um Exemplo de Guia de Implantao de Melhorias: Initiating Diagnosing Estabilishing
Acting and Learning (IDEAL
SM
) ...................................................................................................................... 22
2.3 INFRA-ESTRUTURA ORGANIZACIONAL PARA MPS.............................................................................. 26
2.4 ESTIMATIVAS DE ESFORO, RETORNO E FALHA EM INICIATIVAS DE MPS............................................ 28
2.5 CONSIDERAES FINAIS AO CAPTULO................................................................................................ 30
3 FATORES CRTICOS EM MPS: UMA PESQUISA QUALITATIVA............................................... 32
3.1 METODOLOGIA E CONTEXTO DA PESQUISA.......................................................................................... 32
3.2 QUADRO SINTTICO DE FATORES CRTICOS EM MPS........................................................................... 37
3.2.1 Comparao com Outras Pesquisas Encontradas na Literatura de MPS..................................... 38
3.2.2 Diferenas mais Marcantes para com os Resultados de Outras Pesquisas .................................. 42
3.3 ANLISE DOS RESULTADOS DA PESQUISA ........................................................................................... 44
3.3.1 Natureza dos Fatores Crticos Identificados ................................................................................. 44
3.3.2 Inter-Relaes entre os Fatores: Padres Sistmicos Identificados a Partir da Pesquisa............ 45
3.3.2.1 Arqutipo 1 - Limite ao Sucesso do Programa de MPS: a Necessidade de Sobrevivncia da
Empresa 47
3.3.2.2 Arqutipo 2- Transferncia do Fardo em MPS: Priorizao da Certificao em Detrimento da
Melhoria em Si 50
3.3.2.3 Arqutipo 3- Adversrios Acidentais em MPS: Equipe da Qualidade versus Equipe de
Desenvolvimento de Software ............................................................................................................................................53
3.4 DIFICULDADES E LIMITAES DA PESQUISA....................................................................................... 56
3.5 COMENTRIOS FINAIS AO CAPTULO ................................................................................................... 58
4 TEORIA DE INTERVENO NAS ORGANIZAES...................................................................... 60
4.1 CONCEITOS BSICOS........................................................................................................................... 60
4.2 INTERVENO ENQUANTO UMA TEORIA DE AO ............................................................................... 63
4.3 ATIVIDADES PRIMRIAS DE INTERVENO......................................................................................... 66
4.3.1 Gerao de Informao Vlida e til, e Monitoramento da Implementao das Decises
da Interveno ................................................................................................................................................. 68
4.3.2 Escolha Livre e Informada ............................................................................................................ 69
4.3.3 Comprometimento Interno............................................................................................................. 71
4.4 RISCOS DA NO OBSERVNCIA DAS ATIVIDADES PRIMRIAS DE INTERVENO.................................. 73
4.5 MODELOS DE INTERVENO................................................................................................................ 75
4.6 APRENDIZAGEM ORGANIZACIONAL COMO RESULTADO DESEJVEL DE UMA INTERVENO............... 76
4.7 LIMITES APRENDIZAGEM E AO SUCESSO DAS INTERVENES........................................................... 80
4.7.1 Baixa Capacidade de Lidar com Situaes Problemticas ........................................................... 80
4.7.2 Normas e Sistema de Recompensas Incongruentes com a Interveno......................................... 82
4.7.3 Teoria-em-uso dos Agentes Incongruente com as Atividades Primrias de Interveno.............. 84
4.7.4 Abordagem Predominantemente Tcnica...................................................................................... 86
4.8 O PAPEL DOS INTERVENIENTES........................................................................................................... 89
4.9 CONSIDERAES FINAIS AO CAPTULO............................................................................................... 91
5 PROBLEMAS DE INICIATIVAS DE MPS LUZ DA TEORIA DE ARGYRIS E SCHN .......... 93
ix
5.1 RELACIONANDO OS FATORES CRTICOS EM MPS S ATIVIDADES PRIMRIAS DE INTERVENO........... 94
5.2 APROFUNDANDO A COMPREENSO DOS PROBLEMAS DE MPS............................................................ 96
5.2.1 Normas do Sistema Organizacional Incongruentes com a Interveno de MPS .......................... 97
5.2.2 Baixa Capacidade de Lidar com Situaes Problemticas em MPS........................................... 100
5.2.3 Teoria-em-uso dos Agentes Incongruente com as Atividades Primrias de Interveno............ 104
5.2.4 Abordagem Predominantemente Tcnica.................................................................................... 109
5.2.4.1 Abordagem Predominantemente Tcnica na Conduo das Intervenes de MPS...............................109
5.2.4.2 Abordagem Predominantemente Tcnica na Educao dos Profissionais ............................................113
5.3 ALGUMAS REFLEXES ADICIONAIS COM BASE EM OUTROS AUTORES ............................................... 115
5.4 COMENTRIOS FINAIS AO CAPTULO ................................................................................................. 119
6 PRESCRIES....................................................................................................................................... 121
6.1 REDUZINDO A INCONSISTNCIA DAS NORMAS DO SISTEMA ORGANIZACIONAL COM OS
OBJETIVOS DA INTERVENO DE MPS............................................................................................................ 121
6.2 MELHORANDO A COMPETNCIA DOS PROFISSIONAIS DE MPS EM CONDUZIR AS ATIVIDADES
PRIMRIAS DE INTERVENO ......................................................................................................................... 125
6.2.1 Um Programa de Desenvolvimento de Competncias de Interveno para Profissionais
de MPS 126
6.2.1.1 Etapas do Programa de Desenvolvimento de Competncias de Interveno ........................................128
6.2.1.2 Estimativa de Recursos Humanos e Logsticos Necessrios ao Programa............................................131
6.2.1.3 Outras Consideraes sobre a Proposta de Desenvolvimento de Competncias...................................132
6.3 OUTRAS PRESCRIES DE CARTER REESTRUTURADOR DO PROCESSO DE MPS ................................. 133
6.3.1 Reviso dos Papis dos Intervenientes e Desenvolvedores de Software: Afinal MPS um
Problema de Quem? ...................................................................................................................................... 133
6.3.1.1 Detalhamento da Viso Desejada: o Papel dos Profissionais de MPS ..................................................135
6.3.1.2 Detalhamento da Viso Desejada: O Papel dos Desenvolvedores ........................................................136
6.3.2 Tornando o Processo de MPS mais Integrado Execuo dos Processos de Software ............. 137
6.4 COMENTRIOS FINAIS AO CAPTULO ................................................................................................. 138
7 CONCLUSO E TRABALHOS FUTUROS ........................................................................................ 139
7.1 PRINCIPAIS CONTRIBUIES DA DISSERTAO ................................................................................. 141
7.2 PRINCIPAIS DIFICULDADES E LIMITAES ENCONTRADAS................................................................. 142
7.3 OPORTUNIDADES PARA TRABALHOS FUTUROS .................................................................................. 143
8 REFERNCIAS BIBLIOGRFICAS................................................................................................... 145
APNDICE A ROTEIROS DE ENTREVISTAS DA PESQUISA............................................................ 151
APNDICE B DETALHAMENTO DOS FATORES CRTICOS EM MPS ENCONTRADOS
NA PESQUISA.................................................................................................................................................. 153
APNDICE C ARQUTIPOS SISTMICOS ............................................................................................ 173

1
1 INTRODUO
Este captulo introdutrio tem por objetivo apresentar a motivao de pesquisa pa-
ra a realizao desta dissertao, definir os objetivos do trabalho e o que se pode esperar da
leitura deste texto. Busca tambm situar o contexto geral que gerou a motivao de pesquisa e
apresenta a estrutura da dissertao.
1.1 MOTIVAO E CONTEXTO DA PESQUISA
Software um bem cada vez mais importante e mais presente na vida das pessoas,
seja atravs de seu uso direto em computadores, seja embutido num nmero cada vez maior
de produtos que elas utilizam. Estes produtos so usados em diferentes fins como: trabalho,
lazer, comunicao, sade, educao e uso militar. Entre eles encontram-se os de uso corri-
queiro, como aparelhos de telefone celular, at aqueles mais especializados e crticos para
vidas humanas como sistemas integrados de controle de trfego areo. Utilizados em aplica-
es cada vez mais complexas, os componentes de software, por sua vez, tendem a absorver
esta complexidade em sua construo. Ahern, Clouse e Turner (2003), por exemplo, citam
estimativa do Departamento de Defesa Norte-Americano de que, em breve, aquela organiza-
o estar usando sistemas com cerca de 40 milhes de linhas de cdigo.
Se por um lado software um bem cada vez mais utilizado, por outro lado, as es-
tatsticas de falha em projetos de desenvolvimento de software continuam muito altas apesar
dos avanos da engenharia de software. O conhecido relatrio Chaos Report do Standish
Group (2001) sobre a resoluo de projetos de software da indstria norte-americana, apontou
que, no ano 2000, apenas 28% deles obtiveram o sucesso esperado; 49% foram concludos
com estouro de prazo, oramento e com menos funcionalidades que o previsto; e 23% falha-
ram completamente, pois sequer foram concludos. Tudo isto implica em enorme prejuzo
econmico alm da possibilidade de produtos de software de baixa qualidade.
Estas questes tm motivado, nos ltimos 20 anos, vrios projetos em nvel mun-
dial dedicados criao de modelos normativos de qualidade e mtodos para melhoria de
2
processos de software (MPS
1
), visando obter mais controle sobre os processos e mais compe-
titividade para as organizaes que os utilizam. Estes modelos e mtodos sugerem uma srie
de etapas a serem atingidas de forma a melhorar a qualidade de um processo de software. Ba-
sicamente, eles indicam como realizar o processo de melhorar um processo (Fuggetta,
2000). Alguns dos modelos mais conhecidos so: CMM (Capability Maturity Model) (Paulk e
outros, 1993), CMMI (Capability Maturity Model Integration) (CMU/SEI, 2002), SPICE
(Software Process Improvement and Capability dEtermination) (SPICE, 2005) e, mais recen-
temente, o MPS.Br (Melhoria do Processo de software Brasileiro) (Weber e outros, 2005).
Com base em modelos normativos como estes cada vez mais empresas tm em-
preendido esforos significativos de melhoria de seus processos de software, que podem durar
vrios anos e consomem muitos recursos e energia das equipes envolvidas. Relatrio do SEI
(Software Engineering Institute
2
) (CMU/SEI, 2005) relata que iniciativas deste tipo, quando
bem sucedidas, tm um retorno mdio bastante significativo da ordem de 4,7 unidades mone-
trias para cada unidade investida. Por outro lado, conforme se ver em mais detalhe mais
adiante nesta dissertao, estudos mostram que a grande maioria destas iniciativas (cerca de
dois teros) tambm falha ou no evolui como esperado (Debou e Kuntzmann, 2000) (SEI,
citado por Iversen, 2004). Isto causa srios prejuzos financeiros para as empresas e desest-
mulo para as equipes envolvidas.
Embora o campo da engenharia de software seja visto como sendo de natureza
eminentemente tcnica, diversas pesquisas mostram que a maior parte das falhas dos progra-
mas de MPS de natureza no tcnica e sim humana e social. Fundamentalmente, pode-se
observar que muitos problemas so ligados s estratgias de conduo da iniciativa de melho-
ria no nvel dos indivduos, dos grupos e da organizao como um todo. Entretanto, a com-
preenso de problemas desta natureza por parte de pesquisadores e profissionais de MPS mui-
tas vezes insuficiente e superficial principalmente em virtude de lacunas na formao destes
profissionais e pesquisadores em termos de cincias humanas e sociais. Por este motivo, os
modelos normativos e as iniciativas de MPS costumam enfatizar os aspectos tcnicos, proce-
dimentais e instrumentais do processo, relegando a segundo plano os aspectos humanos e so-
ciais. A compreenso e tratamento destes ltimos fenmenos citados, em iniciativas de MPS,
configuram o problema de pesquisa abordado nesta dissertao.

1
A sigla MPS ser usada daqui em diante nesta dissertao em substituio expresso melhoria de processos
de software. Ela equivalente em portugus sigla em ingls: SPI (software process improvement), comu-
mente encontrada na literatura mundial.
3
Iniciativas de MPS podem ser vistas como uma interveno na organizao. Pes-
quisas oriundas das cincias sociais aplicadas tm uma importante contribuio a dar neste
sentido, particularmente para a compreenso dos fenmenos relativos s mudanas inerentes a
estas intervenes. Esta dissertao usa esta abordagem, particularmente com o apoio das
teorias dos cientistas organizacionais Chris Argyris e Donald Schn, buscando mostrar que os
trabalhos destes autores nas reas de teoria de interveno, teorias de ao e aprendizagem
organizacional, contribuem de forma relevante para a compreenso e tratamento dos fenme-
nos socio-tcnicos de intervees de MPS.
1.2 OBJETIVOS DA PESQUISA
Esta dissertao tem como objetivo abordar os problemas de MPS sob a tica da
teoria de interveno do cientista social Chris Argyris, e tambm dos conceitos relativos
teorias-de-ao e aprendizagem organizacional deste mesmo autor e seu principal colabora-
dor Donald Schn, com vistas a:
Aprofundar a compreenso destes problemas;
Identificar estratgias de ao que possam ajudar no tratamento destes pro-
blemas.
Para tanto, como um objetivo especfico da pesquisa, buscou-se levantar proble-
mas de MPS na viso de profissionais envolvidos neste tipo de iniciativa, em empresas da
cidade de Recife, Brasil. Com isto, busca-se tambm contribuir com uma viso particularizada
sobre fatores crticos em iniciativas de MPS nesta cidade, que atualmente reconhecida como
um dos maiores plos de desenvolvimento de software do Brasil.
1.3 ESTRUTURA DA DISSERTAO
A organizao dos demais captulos desta dissertao descrita a seguir.
Captulo 2 (Melhoria de Processos de Software): traz uma viso geral sobre
MPS, em termos de quais so os componentes e como este tipo de iniciativa
geralmente conduzida atualmente nas organizaes. Introduz modelos norma-

2
O Software Engineering Institute da Universidade Carnegie Mellon (EUA) um dos centros de pesquisas em
engenharia de software mundialmente mais influentes.
4
tivos comumente utilizados em MPS; apresenta algumas estatsticas sobre re-
torno financeiro esperado, de custo e de tempo necessrios, bem como taxa de
falhas de projetos de MPS, segundo artigos e publicaes encontradas nesta
rea.
Captulo 3 (Fatores Crticos em MPS: uma Pesquisa Qualitativa): descreve
uma pesquisa qualitativa realizada com 19 profissionais envolvidos com MPS
em diferentes papis, para levantamento de fatores crticos em termos de as-
pectos facilitadores e barreiras em MPS. apresentada uma anlise temtica
dos fatores crticos por ordem de incidncia, uma anlise de inter-relao entre
eles e uma comparao com pesquisas semelhantes encontradas na literatura
mundial de MPS.
Captulo 4 (Teoria de Interveno nas Organizaes): traz uma viso geral so-
bre teoria de interveno de Chris Argyris: que se entende por interveno?
Quais as atividades primrias de uma interveno? Qual o papel de um inter-
veniente? O que se deve esperar de uma interveno? Quais so os problemas
que costumam limitar o sucesso das intervenes? Os conceitos de interven-
o so enriquecidos com os conceitos de teorias de ao e aprendizagem or-
ganizacional de Chris Argyris e Donald Schn.
Captulo 5 (Problemas de Iniciativas de MPS Luz da Teoria de Argyris e
Schn): busca mostrar que os fatores crticos em MPS esto relacionados s
atividades primrias de interveno propostas por Argyris. Com base nos
conceitos de Argyris e Schn, busca-se mostrar que parte relevante das barrei-
ras em MPS tm origem em problemas fundamentais relativos a deficincias
nas teorias de interveno que so usadas em MPS, nas deficincias das teori-
as-em-uso dos profissionais envolvidos, e nas incongruncias das normas in-
ternalizadas do sistema-organizacional com os objetivos da interveno de
MPS. As proposies interpretativas dos problemas so ilustradas com trechos
significativos de relatos dos entrevistados na pesquisa descrita no Captulo 3.
Captulo 6 (Prescries): com base nos problemas apontados no Captulo 5
so sugeridas estratgias de ao para tratamento dos problemas. As prescri-
es levam em conta contribuies de autores alinhados com as teorias de
Argyris e Schn.
5
Captulo 7 (Concluso e Trabalhos Futuros): traz um resumo da interpretao
apresentada na dissertao; comenta as principais contribuies, bem como as
dificuldades e limitaes da pesquisa. Apresentam-se oportunidades para ex-
tenso em trabalhos acadmicos futuros.
Apndices: apresenta apndices relativos pesquisa qualitativa documentada
no Captulo 3. Dentre estes, destaca-se uma anlise detalhada e ilustrada com
trechos de relatos de entrevistas, sobre cada um dos fatores crticos em MPS
identificados na pesquisa.
6
2 MELHORIA DE PROCESSOS DE SOFTWARE
A motivao bsica para a melhoria de processos de software (MPS) assenta-se na
idia de que, conforme Humphrey (1989), a qualidade de um sistema de software governa-
da pela qualidade do processo usado para desenvolv-lo.
A crescente dependncia dos diversos segmentos da sociedade por produtos e
componentes de software, por um lado, e as altas taxas de insucesso dos projetos software,
por outro lado, tm tornado esta questo um ponto crucial.
Conforme argumenta Fuggeta (2000) desenvolvimento de software um processo
complexo que no envolve apenas o uso efetivo de linguagens de programao e ferramentas,
mas tambm um grande esforo coletivo e criativo para se obter os produtos desejados. Isto
inclui todo um ciclo de interaes entre diferentes atores (clientes e fornecedores) de diferen-
tes domnios, desde o levantamento de requisitos at a implantao efetiva das solues pro-
postas. Assim, a qualidade de um produto de software depende fortemente das pessoas, orga-
nizaes e procedimentos que so usados para cri-lo e implant-lo. Como qualquer outro
esforo centrado nas pessoas, processos de software podem exibir desempenho e resultados
inesperados e indesejados. Algumas dificuldades tpicas enfrentadas por engenheiros de soft-
ware podem ser (Fuggetta, 2000):
Produtos entregues que no exibem a qualidade desejada em termos de confia-
bilidade, funcionalidade ou performance;
Retardo e trabalho desnecessrios em funo de uma seqncia especfica de
operaes de processos inadequada, que podem ser eliminados ou pelo menos
reduzidos pela redistribuio de responsabilidades e atribuies de tarefas;
Dificuldade de localizar e seguir mudanas e variaes de produtos de software
gerados por diferentes membros do time de desenvolvimento;
Grande parte do esforo empregado na produo de software pode ser consu-
mido no prprio esforo para fazer os mtodos de desenvolvimento funciona-
rem (Button e Sharrock, 1994).
Por motivos como estes, MPS se tornou um dos focos de ateno mais importan-
tes para muitas iniciativas da indstria e de pesquisas em engenharia de software. MPS pode
ser compreendida como um processo que consiste em definir e adaptar caractersticas de pro-
cessos de software s necessidades e condies da organizao (infra-estrutura, equipe), pro-
7
piciando que eles possam gerar produtos cada vez mais: bem especificados (que atendem s
necessidades dos clientes); bem implementados (que atendem s especificaes, sem erros); e
num prazo e custo controlvel (previsibilidade).
Neste captulo so abordados alguns dos principais tpicos que compreendem as
iniciativas de MPS conforme elas so comumente conduzidas na indstria de software:
O conceito de processo de software e os elementos que o compem;
Modelos de referncia para MPS:
Modelos de maturidade ou capacidade de processo;
Modelos de avaliao de processos de software;
Guias de implantao;
Infra-estrutura necessria para MPS.
So apresentados tambm alguns dados sobre expectativas de retorno, custo e fa-
lha em iniciativas tpicas de MPS.
2.1 PROCESSOS DE SOFTWARE
Algumas das definies para processo de software so:
Um conjunto de ferramentas, mtodos e prticas usadas para produzir um produto
de software (Humphrey, 1989).
Um conjunto de atividades, mtodos, prticas e transformaes que as pessoas u-
sam para desenvolver e manter software e seus produtos associados (por exemplo,
planos de projetos, documentos de design, cdigo, casos de teste e manuais de usu-
rios) (Paulk e outros, 1993).
Um conjunto coerente de procedimentos, tecnologias, artefatos e estruturas organi-
zacionais necessrias a conceber, desenvolver, implantar e manter um produto de
software (Fuggetta, 2000).
Um conceito precursor noo de processo de software a idia de ciclo de vida
do desenvolvimento de software. O ciclo de vida define diferentes estgios de evoluo de um
produto de software. Tipicamente, estes estgios por ordem em que so desempenhados, so
geralmente os seguintes: especificao, design, desenvolvimento, validao, implantao,
operao, manuteno e, eventualmente, a desativao (retirada de funcionamento) (Fugget-
ta, 2000). O ciclo de vida de um software define os princpios e guias de acordo com os quais
estes diferentes estgios devem ser realizados. Por exemplo, o modelo cascata sugere que um
estgio especfico s deveria ser iniciado quando os produtos do estgio anterior tenham sido
8
completados. J o modelo espiral considera o desenvolvimento de software como iteraes
sistemticas que realizam o desenvolvimento do software de forma incremental.
Em geral um ciclo de vida de software define um esqueleto e uma filosofia pelos
quais o processo de software realizado. Todavia ele no prescreve um curso preciso de a-
es, uma organizao que lhes d suporte, ferramentas e procedimentos operacionais, polti-
cas e restries que tornem o projeto e implementao de software algo controlvel (Fuggeta,
2000). Estes so elementos que compem tipicamente um processo e que podem ser mais
bem ilustrados tomando como base um exemplo real de modelo de processo.
2.1.1 Ilustrando os Componentes de um Processo de Software atravs do RUP
O Rational Unified Process (RUP) (Kruchten, 2003) atualmente uma das mai-
ores referncias da indstria de software em termos de modelo de processo. A Figura 2.1 a-
presenta o conhecido grfico das baleias do RUP que ilustra a distribuio de esforo entre
as disciplinas que compem as atividades previstas no modelo, ao longo de seu ciclo de vida
(fases e iteraes).

Figura 2.1: Ciclo de vida e disciplinas do Rational Unified Process
3
.
Alm da idia de fases e disciplinas, alguns conceitos fundamentais presentes no
RUP e na maioria dos modelos de processos de software so (Rational, 2003):

3
Rational (2003).
9
Papel: diz respeito a quem faz o que em termos de atividades. No RUP so
previstos 33 tipos de papis distintos, distribudos entre os seguintes grupos:
analistas (subdivididos em mais 8 categorias), desenvolvedores (subdivididos
em mais 10 categorias), testadores, gerentes (subdivididos em mais 7 categori-
as) e outros papis (subdivididos em mais 7 categorias).
Atividade: tipo de tarefa, que pode ser realizada por pessoas investidas em um
papel. So previstas vrias dezenas de tipos de atividades distintas no RUP.
Artefato: produto que deve ser gerado, por pessoas investidas em um papel,
executando uma ou um conjunto de atividades. So tambm previstos dezenas
de artefatos distintos no RUP.
Fluxo de Trabalho seqncia em que atividades devem ser executadas com
a conseqente produo de artefatos. So tambm previstos dezenas de fluxos
de trabalhos distintos no RUP.
A Figura 2.2 ilustra estes e outros conceitos fundamentais do RUP, muitos de-
les tambm presentes em outros modelos de processos de software.

Figura 2.2: Elementos conceituais bsicos do RUP
4
.

4
Adaptado com base em Rational (2003).
10
Por ser largamente usado e bastante completo em termos de conceitos associados
a um processo de software o RUP bastante til enquanto representao de modelo de pro-
cesso para este tipo de atividade. Embora possua grande quantidade de adeptos, h tambm
muitos crticos. Estes costumam consider-lo um processo pesado, de difcil implantao e
adaptao na prtica e excessivamente burocrtico em virtude de ser centrado em grande
quantidade de artefatos documentais.
Parte destes crticos deu origem aos chamados mtodos geis (Beck e outros,
2001) Estes mtodos valorizam mais um processo cclico de produo rpida de programas
seguidos de testes e readaptao dos programas (refactoring) com uma carga menor de docu-
mentao. Caracterizam-se tambm por grande interao entre os elementos da equipe de de-
senvolvimento, que por sua vez possuem papis pouco rgidos (pressupostos que os tornam
bastante distintos do RUP). O exemplo provavelmente mais conhecido desta escola de pro-
cessos de software o eXtremme Programing (XP) (Beck, 1999). Os ditos mtodos geis
so tambm criticados por muitos, que lhes atribuem entre outros defeitos, pouca controlabili-
dade do processo e documentao pobre.
Todavia, longe de intencionar aprofundar estas questes, esta breve ilustrao dos
conceitos bsicos associados a processos de software, tem apenas o intuito de contextualizar o
objeto bsico de ateno das iniciativas de MPS, ou seja, o prprio processo de software, res-
saltando que:
Processos de software so compostos por uma quantidade razovel de elemen-
tos conceituais interconectados que torna o seu domnio algo complexo;
No h consenso entre praticantes e pesquisadores sobre quais devam ser esses
elementos que compem um processo e qual a melhor forma de estrutur-los.
Isto serve para prenunciar a complexidade do esforo envolvido em iniciativas de
MPS. A seo seguinte aprofundar esta questo ao abordar modelos de referncia para MPS.
2.2 MODELOS DE REFERNCIA PARA MELHORIA DE PROCESSOS DE
SOFTWARE
At recentemente, a maior parte das empresas produtoras de software no possua
processos de software bem definidos. Os processos eram (e ainda so para uma parcela signi-
ficativa das empresas) realizados de forma um tanto artesanal, eram no definidos ou semi-
definidos e sujeitos a grande variabilidade. Isto ocorria devido complexidade inerente ati-
11
vidade e ao desenvolvimento incipiente da engenharia de software, e tambm do prprio mer-
cado consumidor dos produtos desta rea.
A partir do incio dos anos 1990, esta realidade vem se transformando pouco a
pouco de forma crescente, medida que o mercado, atravs de critrios normativos, exige
cada vez mais qualidade dos produtos de software. Como a qualidade destes produtos de-
pende diretamente da controlabilidade dos processos que os produzem, estas exigncias nor-
mativas tm, conseqentemente, recado diretamente sobre estes processos. Influenciada por
esta exigncia crescente e naturalmente tambm pelas pesquisas na rea, a engenharia de soft-
ware tem evoludo com a produo de ferramentas de apoio ao prprio desenvolvimento de
software. Todos estes fatores tm se tornado uma realidade cada vez maior para as empresas
produtoras de software em nvel mundial. Com o advento da globalizao isto se tornou
tambm uma realidade para as empresas nacionais.
Na prtica, isto significa para as empresas a necessidade de definir, implantar e
melhorar seus processos de produo de software. Contudo, conforme se pde observar com
base nos elementos conceituais ilustrados na seo anterior, processos de software podem
adquirir um nvel de complexidade bastante grande, em virtude da multiplicidade de fatores
como: disciplinas, atividades, papis, artefatos e fluxos de trabalho. Implantar estes modelos
, portanto uma atividade bastante complexa. Conforme argumentam Ahern, Clouse e Turner
(2003), em termos de implantao, praticamente impossvel controlar ao mesmo tempo to-
dos os aspectos de um processo de software completo. preciso quebrar esta tarefa em pe-
daos em que se possam fazer ajustes controlveis.
Alm disso, em geral pesquisadores e praticantes deram-se conta que uma vez de-
finidos processos no podem ser congelados para sempre. Processos precisam constante-
mente sofrer mudanas e refinamentos para melhorar sua capacidade de lidar com requisitos,
expectativas de mercado, de clientes e profissionais envolvidos, e mudanas no contexto da
organizao. Portanto, processos de software precisam ser continuamente adaptados e melho-
rados (Fuggetta, 2000).
Diante disto, percebeu-se tambm que no bastam apenas modelos de processos
de software, mas tambm h necessidade de mtodos de como implant-los e melhor-los
quebrando a tarefa em partes controlveis. Estas questes tm motivado uma srie de projetos
dedicados criao de modelos de qualidade e mtodos para melhoria de processos de soft-
ware. Estes modelos sugerem mtodos de avaliao, etapas a serem seguidas e estratgias
com vistas melhoria de qualidade dos processos de software. Eles so processos de como
melhorar processos (Fuggetta, 2000).
12
Pressionados em grande parte por questes mercadolgicas, profissionais e em-
presas de software descobriram que sua habilidade para ganhar e desempenhar contratos est
sujeita a investigao dos seus processos bem como da qualidade, custo e eficcia de seus
produtos (Sheard, 1997). Os frameworks que servem de guias para implantao, melhoria e
auditoria de processos multiplicaram-se desde o incio da dcada de 1990. A Figura 2.3 ilustra
grande parte dos modelos surgidos com este intuito.


Figura 2.3: Frameworks voltados para, ou que influenciam MPS
5
.

Longe de pretender detalhar todos estes modelos, a insero da Figura 2.3 nesta
seo objetiva demonstrar o quanto tem sido dada ateno a esta questo na indstria de soft-
ware. Grande parte destes modelos so padres estabelecidos por entidades normativas ofici-
almente reconhecidas em muitos pases como ISO
6
, e ANSI
7
. Outros so modelos de maturi-

5
Ilustrao de Sheard (2001).
6
ISO International Organization. For Standardization.
7
ANSI American National StandardsInstitute.
Legendas:
Em CINZA - padres considerados j obsoletos.
Modelos integrados.
Indica que o modelo apontado substitui o outro.
Indica que o modelo apontado baseado no outro.
Indica que o modelo apontado usa/referencia o outro.
Caixa em
alto relevo
No lanados.
Baseado em CBA, IPI, SAM e outros.
Verso 2 tambm baseada em outros
modelos.

13
dade e capacidade de processos livremente criados, mas que pela sua aceitao na indstria
terminam por adquirir a fora de um padro a ser seguido. Um exemplo disto o conhecido
modelo CMMI (Capability Maturity Model Integration) criado pelo Software Engeneering
Institute SEI (CMU/SEI, 2002). Geralmente estes modelos estabelecem boas prticas para
implantao, avaliao e melhoria de processos, priorizando a definio do que deve ser feito,
mas no como fazer.
Nem todos os modelos referidos na Figura 2.3 tm largo uso na indstria e no
inteno deste captulo realizar comparaes entre os modelos e sim ilustrar uma iniciativa de
MPS tpica. Tambm no h necessariamente um consenso de como deve ser estruturado um
esforo de MPS. As iniciativas de implantao e melhoria de processos, conforme ocorrem
atualmente na indstria, na maioria dos casos, poderiam ser vistas em termos do uso dos se-
guintes ingredientes metodolgicos:
Guias para melhoria de processos, normalmente instanciados como modelos de
maturidade/capacidade organizacional e de processos, que normalmente indi-
cam patamares incrementais de implantao e melhoria de processos. Um e-
xemplo o j referido modelo CMMI (Capability Maturity Model Integrati-
on) que ser mais bem detalhado na prxima seo deste captulo.
Modelos de avaliao de processos, que normalmente so utilizados conjunta-
mente com os primeiros acima, estando relacionados aos critrios estabelecidos
por eles. Um exemplo o mtodo de avaliao SCAMPI
SM
(CMU-SEI, 2001
a
)
utilizado em conjunto ao CMMI.
Guias de implantao que definem um modelo de ciclo de vida para melhorias.
Um exemplo o IDEAL
SM
(Gremba e Myers, 1997).
Como forma de ilustrar uma iniciativa de MPS tpica, sero abordados resumida-
mente, a seguir, os modelos referidos nos itens acima.
2.2.1 Um Exemplo de Modelo de Maturidade para MPS: Capability Maturity Model
Integration (CMMI)
O CMMI um guia composto por um conjunto de modelos de referncia, produ-
zido pelo Software Engineering Institute SEI (CMU/SEI, 2002) que prov orientao para
melhorar processos organizacionais e a habilidade para gerenciar o desenvolvimento, aquisi-
o e manuteno de produtos ou servios. Ele prov abordagens estruturadas de forma a aju-
14
dar uma organizao a avaliar sua maturidade organizacional, capacidade de reas de proces-
so, estabelecer as prioridades de melhoria e implementar as melhorias.
O CMMI uma evoluo direta do CMM (Capability Maturity Model) tambm
criado pelo SEI, que incorporou elementos de outros modelos como o padro ISO 15504
(CMU/SEI, 2002). O CMM um modelo de maturidade, publicado no incio da dcada de
noventa para ser um guia de MPS. Sua origem remonta segunda metade da dcada de oiten-
ta a partir dos trabalhos liderados por Humphrey (1989) e posteriormente evoludo por Paulk
e outros (1993). O objetivo inicial era criar padres de processos para fornecedores do Depar-
tamento de Defesa norte-americano. O conceito chave da proposta de Humphrey foi a idia de
estabelecer nveis de maturidade, que determinam metas incrementais de melhoria. Este con-
ceito foi, por sua vez, inspirado nos trabalhos de Phillip Crosby (Crosby, 1979 citado por
Humphrey, 1989) um conhecido autor da rea de qualidade de processos para a indstria em
geral. Embora possa sofrer crticas, a aceitao deste modelo na indstria de software foi tal
que Rico (2002) sustenta que embora o SW-CMM possa ser avaliado como sendo menos que
a abordagem ideal em MPS, este modelo se tornou o padro internacional de fato em MPS.
A princpio o CMM foi voltado para processos de engenharia de software, tendo
este modelo inicial sido batizado como SW-CMM. Porm a linha cada vez mais tnue na in-
dstria do emprego de componentes de software e hardware integrados num mesmo produto
motivou a posterior criao de modelos derivados como o SE-CMM e IPD-CMM. Estes so
voltados, respectivamente, para engenharia de sistemas (que prev sistemas compostos por
componentes de hardware e software) e desenvolvimento de produtos integrados (pode incluir
a integrao de produtos, alm de componentes de hardware e software). A proliferao de
modelos CMM motivou pesquisas de como mant-los compatveis e integrados.
O objetivo bsico da criao do CMMI no incio dos anos 2000 foi integrar os
modelos CMM criados para diferentes aplicaes. Atualmente o CMMI prope a integrao
de quatro modelos envolvendo diferentes reas de aplicao: engenharia de software; enge-
nharia de sistemas; desenvolvimento integrado de processo e produto e seleo de fornecedo-
res. Todavia estes modelos podem ser utilizados distintamente de acordo com a necessidade
da organizao.
Os modelos que compem o CMMI so um conjunto de requisitos e guias que a-
judam a organizao a estruturar seus processos. Eles priorizam a definio de o que deve ser
feito, mas no de como deve ser feito. So disponibilizados para uso sob duas representaes
que implicam na escolha de estratgias distintas para a iniciativa de melhoria:
15
Representao em Estgios: estruturada em nveis pr-definidos de maturida-
de organizacional conforme o Quadro 2.1. Cada nvel de maturidade define um
conjunto de reas de processos com determinadas metas que devem ser atendi-
das. Um determinado nvel de maturidade pressupe o acmulo dos requisitos
dos nveis inferiores. Iniciativas de melhoria com base nesse modelo pressu-
pem a evoluo global da capacidade dos processos da organizao conforme
a ordem pr-definida no modelo.
Quadro 2.1: CMMI em estgios - nveis de maturidade e reas de processos associadas.
NVEL DE
MATURIDADE
FOCO REAS DE PROCESSO / CATEGORIAS
8

1
(Inicial)
No h foco especfico. Nenhuma especfica
(Representa o processo em estgio inicial de organizao,
caracterizado muitas vezes por ser catico: no-definido
ou pobremente definido)
2
(Gerenciado)
Gerenciamento bsico de
Projetos.
Gerencia de requisitos (Eng)
Planejamento de projeto (Prj)
Monitoramento e controle de projeto (Prj)
Gerenciamento de acordo com fornecedor (Prj)
Medio e anlise (Sup)
Garantia da qualidade de produto e processo (Sup)
Gerencia de configurao (Sup)
3
(Definido)
Padronizao de processos. Desenvolvimento de requisitos (Eng)
Soluo tcnica (Eng)
Integrao de produtos (Eng)
Verificao (Eng)
Validao (Eng)
Foco no processo organizacional (Prc)
Definio de processo organizacional (Prc)
Treinamento organizacional (Prc)
Gerncia integrada de projetos (Prj)
Gerncia de riscos (Prj)
Anlise de decises e resoluo (Sup)
4
(Gerenciado
Quantitativamente)
Gerenciamento quantitativo. Desempenho do processo organizacional (Prc)
Gerncia quantitativa de projeto (Prj)
5
(Otimizado)
Melhoria contnua. Inovao organizacional e implantao (Prc)
Anlise causal e resoluo (Sup)

Representao Contnua: estruturada em nveis pr-definidos de capacidade
conforme o Quadro 2.2, para cada rea de processo distinta. Iniciativas de me-
lhoria com base nesse modelo pressupem flexibilidade para que a evoluo

8
Como se pode observar no Quadro 1 as reas de processos so agrupadas em quatro categorias: gerncia de
processo (Prc), gerncia de projeto (Prj), engenharia (Eng) e suporte (Sup).
16
possa ser feita em certas reas de processo apenas, sem ordem pr-estabelecida,
conforme priorizado pela organizao.
A proposta de representao contnua possivelmente a maior diferena do CM-
MI em relao ao seu antecessor, o CMM, que previa apenas a representao em estgios.
Ambas as representaes tm basicamente o mesmo contedo, pois as reas de processos so
as mesmas e permitem um mapeamento de uma em relao outra (CMU/SEI, 2002). As
definies dos nveis de maturidade so idnticas entre os modelos CMMI e CMM.
Quadro 2.2: CMMI contnuo - nveis de capacidade para uma rea de processo.
Nvel de Capacidade Significado
0 Incompleto Indica que um determinado processo no realizado ou realizado
parcialmente.
1 Realizado Indica que um determinado processo completamente realizado.
3 Gerenciado Indica que um processo planejado e realizado com base no plano.
4 Definido Indica que um processo planejado e executado por todas as reas da
organizao sob as mesmas especificaes de processo.
5 Quantitativamente gerenciado Indica que um processo definido e monitorado estatisticamente ou
por outros mtodos quantitativos.
6 Otimizado Indica que um processo definido e monitorado estatisticamente con-
tinuamente adaptado visando atingir objetivos relevantes do negcio.

Embora o modelo contnuo seja mais flexvel para adequao s necessidades es-
pecficas de cada organizao, o modelo em estgios amplamente mais utilizado. Isto ocorre
por dois motivos principais: primeiro porque esta forma de estruturao foi herdada pelo
CMMI quase sem alteraes significativas do modelo CMM, que j estava amplamente testa-
do na indstria de software e por isso, foi visto como uma estratgia segura a ser seguida. O
segundo motivo, que o modelo em estgios permite uma avaliao oficial reconhecida pelo
SEI que estabelece o nvel de maturidade do processo global da organizao. Esta avaliao
oficial foi desde o incio um dos objetivos do CMM, para ser um fator de qualificao de for-
necedores de produtos e servios de software, inicialmente pelo Departamento de Defesa nor-
te Americano (Humphrey, 1989). Posteriormente, este modelo tornou-se cada vez mais difun-
dido para este mesmo fim, na indstria e no mercado mundial de software em geral e, por isto,
o maior interesse pelo CMMI em estgios j que este o sucessor natural do CMM em sua
forma original.
Os conceitos do CMMI constantes no Quadro 2.1 esto estruturados de forma
mais completa conforme a Figura 2.4.
17

Figura 2.4: Componentes de um modelo CMMI
9
.

A seguir uma breve descrio sobre os componentes ilustrados na Figura 2.4:
Nvel de maturidade, no topo da figura, define um plat evolutivo de melhoria
de processo. Prov uma forma de predizer o desempenho de uma organizao
em uma dada disciplina ou conjunto de disciplinas. O Quadro 2.1 ilustra os n-
veis previstos no modelo.
rea de processo um conjunto de prticas relacionadas em uma dada rea
que, quando desempenhadas coletivamente, satisfazem um conjunto de metas
consideradas importantes para uma melhoria significativa nesta rea. Na prti-
ca as reas de processo so formas de organizar disciplinas e atividades fun-
damentais para o desenvolvimento de software. O Quadro 2.1 ilustra as reas
de processos do CMMI classificadas por nvel de maturidade.
Metas especficas dizem respeito s caractersticas que descrevem o que deve
ser implementado para satisfazer uma dada rea de processo e por isso so usa-
das nas avaliaes da respectiva rea de processos. Por exemplo: gerenciar re-
quisitos uma meta especfica da rea de processo de gerncia de requisitos.

9
CMU/SEI (2002, Pg. 10).
Verificao da
Implementao
Caractersticas Comuns
Nveis de Maturidade
rea de Processo 1 rea de Processo 2 rea de Processo N
Metas
Especficas
Metas
Genricas

Prticas
Especficas

Compromentimento
para Realizar
Habilidade
para Realizar
Direcionamento da
Implementao
Prticas
Genricas
18
Prtica especfica uma atividade considerada importante para o atingimento
de uma meta especfica de uma dada rea de processo. Por exemplo: obter um
entendimento dos requisitos uma prtica especfica da meta gerenciar requi-
sitos. Identificar inconsistncias entre resultados de trabalho e requisitos um
outro exemplo de prtica especfica para a mesma meta gerenciar requisitos.
Caractersticas comuns organizam as prticas genricas de cada rea de pro-
cesso. So componentes do modelo que no so medidos de alguma maneira
especfica. So quatro: comprometimento no realizar, habilidade de realizar,
direcionamento de implementao e verificao de implementao.
Metas genricas so assim chamadas porque aparecem em mltiplas reas de
processos. O atingimento de uma meta genrica numa rea de processo signifi-
ca que seu controle foi melhorado em planejar e implementar processos associ-
ados quela rea. Indica se um processo parece ser eficaz, repetvel e duradou-
ro. Por exemplo: institucionalizar um processo gerenciado uma meta genri-
ca para a rea de processo gerncia de requisitos e tambm para a rea de ge-
rncia de projeto.
Finalmente, prticas genricas provem institucionalizao a fim de certificar
que os processos associados a uma rea de processo sero efetivos, repetveis e
duradouros. Por exemplo: estabelecer uma poltica organizacional e prover
recursos so prticas genricas associadas meta genrica institucionalizar
um processo gerenciado, que por sua vez est ligada rea de processo de ge-
rncia de requisitos.
Embora no seja um padro criado por uma instituio normativa oficial como
ISO, ANSI (ou ABNT, no caso do Brasil), a aceitao do CMMI (juntamente com seu ante-
cessor CMM) na indstria de software to relevante que ele vem a ser o principal modelo de
referncia para maioria das iniciativas de MPS, tanto em nvel mundial como na indstria
brasileira.
O Quadro 2.3 apresenta uma contagem de avaliaes em nvel mundial publicada
pelo SEI. Considerando a comparao entre os dois modelos, observa-se que o CMM ainda
possui maior quantidade de avaliaes oficiais, naturalmente por ser cerca de dez anos mais
antigo que o CMMI. Todavia, o CMMI apresenta uma maior tendncia de uso, alm de que,
conforme anunciado pelo SEI, novas avaliaes oficiais do CMM j foram descontinuadas.
Por estes motivos o CMMI foi escolhido neste trabalho para ilustrar o uso de modelos de refe-
rncia em iniciativas de MPS conforme ocorrem atualmente na indstria.
19


Quadro 2.3: Estatstica de pases com avaliaes oficiais nos modelos CMMI e CMM.
CMMI
10
CMM
11

Pas N de avaliaes
oficiais
Nvel mximo de
Maturidade alcanado
N de avaliaes
oficiais
Nvel mximo de
Maturidade alcanado
Estados Unidos 500 5 2035 5
ndia 140 5 422 5
Japo 131 5 177 5
China 117 5 354 5
Coria 50 5 78 5
Frana 42 5 151 5
Reino Unido 35 5 144 3
Taiwan 26 5 10 ou menos Info. no disponvel
Brasil 22 5 32 5
Alemanha 22 5 76 4
Austrlia 21 5 36 5
Espanha 18 5 28 5
Canad 15 5 85 5
Argentina 12 4 12 5
Itlia 10 ou menos Info. no disponvel 40 5
Mxico 10 ou menos Info. no disponvel 34 5
Israel 10 ou menos Info. no disponvel 32 3
Chile 10 ou menos Info. no disponvel 29 5
Holanda 10 ou menos Info. no disponvel 25 5
Tailndia 10 ou menos Info. no disponvel 23 3
Singapura 10 ou menos Info. no disponvel 23 5
Filipinas 10 ou menos Info. no disponvel 13 5
Hong Kong 10 ou menos Info. no disponvel 12 4
Irlanda 10 ou menos Info. no disponvel 11 3
TOTAL 1.251 3.882

O uso de um modelo como CMMI em estgios geralmente significa um esforo
de melhoria em larga escala da organizao que produz software, o que pode requerer um
esforo de tempo e custo considerveis para muitas empresas. Todavia, vale ressaltar que ou-
tras formas de melhoria em menor escala so tambm possveis. Um exemplo disto poderia
ser a melhoria de apenas algumas reas de processo especficas (atravs do CMMI contnuo,
por exemplo). Ou ainda o emprego de modelos menos abrangentes como o Personal Software
Process-PSP (CMU/SEI, 2006c) e Team Process Software-TSP (CMU/SEI, 2006d), que res-

10
(CMU/SEI, 2006a)
11
(CMU/SEI, 2006b)
20
tringem-se mais propriamente ao disciplinamento e melhoria da atividade de implementao
de software propriamente dita, individualmente ou em equipe, respectivamente.
Um outro modelo alternativo ao CMMI digno de referncia o padro MPS.Br
(Melhoria do Processo de Software Brasileiro) criado pela Softex
12
. Este padro foi criado
propositalmente para ser conceitualmente compatvel com o modelo CMMI e assim manter-se
de acordo com padres da indstria mundial, porm pensando numa maior adequao reali-
dade econmica da indstria de software brasileira. Desta forma, o custo de certificao por
este modelo foi projetado para ser significativamente mais adequado aos padres da economia
nacional do que uma avaliao oficial para o CMMI. Conceitualmente, a diferena bsica do
MR-MPS (Modelo de Referncia para Melhoria do Processo de Software) que compe o
MPS.Br, que ele prope o fracionamento de dois dos nveis do CMMI em nveis intermedi-
rios com o objetivo de tornar ainda mais incremental a implementao de melhorias, confor-
me o Quadro 2.4.
Quadro 2.4: Correspondncia entre o CMMI e MR-MPS (MPS.Br)
Nveis de Maturidade do CMMI
/ Significado
Nveis de Maturidade do MR-MPS
/ Significado
1 Inicial (no h correspondente)
G - Parcialmente Gerenciado 2 Gerenciado
F - Gerenciado
E - Parcialmente Definido
D - Largamente Definido
3 Definido
C - Definido
4 Gerenciado Quantitativamente B - Gerenciamento quantitativo
5 Em Otimizao A - Melhoria contnua.

2.2.2 Um Exemplo de Modelo para Avaliao de Processos: Standard CMMI Appraisal
Method for Process Improvement
13
(SCAMPI)
Um componente importante de melhorias de processos de software so os mto-
dos de avaliao que permitem a medio da evoluo da organizao com base em algum
modelo de referncia para MPS. Muitos mtodos padronizados de avaliao esto disponveis
na indstria de software de forma a permitir benchmarks entre organizaes, entre processos,

12
A Sociedade Softex uma organizao no-governamental criada em 1996, que teve origem a partir de projeto
do Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico (CNPq), com o intuito de capacitar de
empresas de softwares brasileiras para exportao de Software.
13
Mtodo Padro CMMI para Avaliao de Melhoria de Processo.
21
ou mesmo para permitir critrios estveis que permitam o monitoramento numa mesma base
dos processos de uma organizao, ao longo do tempo.
Assim como criou o CMM e posteriormente o CMMI, o Software Engineering
Institute (SEI) definiu num documento denominado Apphraisal Requeriments for CMMI
14

(ARC) (CMU/SEI, 2001) um conjunto de requisitos para o desenvolvimento de mtodos de
avaliao que sejam compatveis com o CMMI. Com base nestes requisitos o prprio SEI
instanciou tambm um mtodo de avaliao para uso conjunto com o CMMI, denominado
SCAMPI (CMU-SEI, 2001
a
), conforme o ttulo desta seo.
O mtodo SCAMPI consiste de um conjunto de requisitos, atividades e prticas
usadas para identificar foras, fraquezas e comparaes dos processos de uma determinada
organizao em relao a um modelo CMMI, com vistas a determinar seu nvel de maturidade
ou nvel de capacidade de seus processos. O SEI sugere que o SCAMPI seja usado pelas or-
ganizaes como um mtodo de avaliao no apoio a programas de melhoria interna de pro-
cessos que usem o CMMI. Aplicaes do mtodo incluem mensurao do progresso de me-
lhorias, conduo de auditorias de processos, focando em domnios especficos ou linhas de
produtos, avaliao de projetos especficos e preparao para avaliao por fornecedores ex-
ternos.
Em termos prticos o uso de um mtodo como o SCAMPI significa verificar a exis-
tncia de forma mais objetiva possvel de quais requisitos do modelo CMMI foram efetiva-
mente implantados nos processos de manufatura de software da organizao. Para tanto, so
definidos indicadores de implementao prtica com base nas definies do CMMI.
O mtodo pressupe o estabelecimento de uma equipe de avaliadores que ir rea-
lizar esta verificao com base em um plano objetivo de avaliao que define, entre outros
itens, quais requisitos sero avaliados. A existncia de uma equipe de avaliadores importan-
te, pois apesar de buscar definir critrios da forma mais objetiva possvel, h casos em que a
interpretao das evidncias pode variar sendo necessria a discusso das interpretaes. O
Quadro 2.5 ilustra os tipos de indicadores e evidncias consideradas no mtodo.
O SCAMPI pode ser utilizado tanto para avaliao interna dos processos, como
para avaliao oficial reconhecida pelo SEI. Alm disso, possui outras aplicaes relaciona-
das verificao de qualidade de servios de fornecedores externos, como por exemplo, a
prpria seleo de fornecedores e, em contratos de longo prazo, a monitorao (auditorias)

14
Requisitos de Avaliao para o CMMI.
22
dos processos de fornecedores durante a prestao dos servios e desenvolvimento de produ-
tos de software.
Quadro 2.5: Tipos de evidncias objetivas consideradas no SCAMPI.
Evidncias objetivas Descrio geral
Artefatos diretos Resultados de trabalho que so explicitamente e intencionalmente produzidos
como conseqncia da implementao de uma prtica prevista no modelo.
Exemplo (relacionado ao processo de gerncia de requisitos): um documen-
to de requisitos de um sistema.
Artefatos indiretos Artefatos incidentais que so indicativos da implementao de uma prtica
prevista no modelo.
Exemplo (relacionado ao processo de gerncia de requisitos): uma mensagem
entre clientes fazendo referncia a itens do documento de requisitos, em
relao ao processo de gerncia de requisitos.
Demonstraes / apresentaes Demonstrao da capacidade ou apresentao de uma ferramenta ou outro
mecanismo relacionado implementao de uma prtica prevista no modelo.
Exemplo (relacionado ao processo de gerncia de requisitos): demonstrao
e/ou apresentao de uma ferramenta usada para gerenciar requisitos.
Afirmaes Sentenas orais ou escritas de pessoas que realizam atividades relevantes que
so indicativas da implementao de uma prtica prevista no modelo e que
possam ser demonstrveis.
Exemplo (relacionado ao processo de gerncia de requisitos): numa auditoria
de processo, um analista de sistemas demonstra oralmente que conhece os
requisitos e ferramentas usadas no processo.
2.2.3 Um Exemplo de Guia de Implantao de Melhorias: Initiating Diagnosing Estabi-
lishing Acting and Learning (IDEAL
SM
)
Devido complexidade envolvida na adoo de modelos de processos de software
e de modelos de maturidade/capacidade destes processos os profissionais e organizaes esto
crescentemente reconhecendo a necessidade de um guia para estabelecimento de um ciclo de
vida na implantao destas iniciativas. O modelo IDEAL foi concebido tambm pelo SEI ini-
cialmente para guiar iniciativas de MPS baseadas no CMM (Gremba e Myers, 1997). Posteri-
ormente foi revisado para ser genrico o suficiente de forma a poder ser usado em outros tipos
de iniciativas de melhoria. A Figura 2.5 ilustra as fases e atividades deste modelo.
O propsito de cada fase do modelo , resumidamente, o seguinte:
Iniciao (Initiating): Articular claramente as razes da iniciativa de melhoria
e relacion-las estratgia de negcio da empresa. Estabelecer o apoio da alta
gerncia e alocar recursos, incluindo uma infra-estrutura que suporte o esforo
de melhoria.
Diagnstico (Diagnosing): desenvolver um entendimento mais completo da i-
niciativa de melhoria, avaliando o estado atual e estabelecendo um estado dese-
23
jado. Com base nisto se estabelecem recomendaes que nortearo as fases
posteriores.
Estabelecimento (Estabilishing): desenvolver uma abordagem (estratgia) pa-
ra o ciclo de melhoria em curso e um plano detalhado de ao, levando em
conta prioridades estabelecidas com base no diagnstico.
Ao (Acting): pr em prtica o plano de ao estabelecido para construir, tes-
tar, refinar e finalmente implantar as solues necessrias ao ciclo de melhoria.
Aprendizagem (Learning): coletar e analisar dados do ciclo de melhoria como
um todo, documentar lies aprendidas e recomendaes para novos ciclos a
serem iniciados. Um outro objetivo mais geral desta fase desenvolver e me-
lhorar continuamente a habilidade da organizao para implementar mudana.

Figura 2.5: Fases e atividades do modelo IDEAL
15
.
O Quadro 2.6 descreve resumidamente as atividades de cada fase. Conforme se
pode observar neste quadro, o IDEAL um modelo iterativo para implementao de melhori-
as. A idia central deste tipo de abordagem permitir a implementao incremental de mu-

15
Gremba e Myers (1997).
Identificar
o Contexto
Estabelecer
Patrocinadores
Estabelecer
Infra-estrutura
Caracterizar
os Estados
Atual e Desejado
Desenvolver
Recomendaes
Estabelecer
Prioridades
Desenvolver
Abordagem
Planejar
Aes
Criar a
Soluo
Teste Piloto
da Soluo
Refinar a
Soluo
Implantar
A Soluo
Analisar
e Validar
Propor
Alteraes
Futuras
Iniciao
Estmulo
para a
Mudana
24
danas que possam ser ao mesmo tempo desafiadoras, mas realistas para cada organizao em
cada passo da melhoria.
Quadro 2.6(a): Descrio resumida das atividades do modelo IDEAL.
FASE ATIVIDADE DESCRIO RESUMIDA
Estmulo para a
mudana
Identifica as razes de vrias naturezas que leva a organizao querer
realizar a iniciativa de melhoria. Quanto mais claras estas razes maior
a chance de visibilidade para a iniciativa de melhoria.
Identificar o
Contexto
Identifica onde o esforo de melhoria se encaixa no negcio e estratgia
da organizao. Quanto maior o impacto da melhoria no atingimento
dos objetivos estratgicos de negcio, maior as chances de comprome-
timento com o esforo de melhoria.
Estabelecer
Patrocinadores
Estabelece o patrocnio da alta gerncia necessrio s aes de melhori-
a. Identifica os membros da alta administrao que estaro mais direta-
mente empenhados neste patrocnio. Este apoio fundamental, sobretu-
do no incio do esforo e em momentos de incerteza e de decises crti-
cas.
Iniciao (Initi-
ating)
Estabelecer
Infra-estrutura
Estabelece a infra-estrutura que estar disponvel ao esforo de melho-
ria, o que pode incluir pessoas, equipamentos, ferramentas, servios de
terceiros e instalaes. Depende da complexidade do esforo e das pos-
sibilidades da organizao.
Caracterizar o
estado atual e o
desejado
Identifica o estado atual e o estado desejado da melhoria. A caracteriza-
o destes estados pode ser realizada tendo como base um modelo como
o CMMI. Para o estabelecimento do estado desejado se deve levar em
conta que so previstas vrios ciclos de melhoria.
Diagnstico
(Diagnosing)
Desenvolver
recomendaes
Estabelece recomendaes de aes para as atividades subseqentes da
melhoria. Estas recomendaes requerem a participao de um time
experiente nas atividades em questo. Requer tambm a validao dos
patrocinadores da melhoria.
Estabelecer
prioridades
Estabelece prioridades com base no diagnstico, levando em conta
restries do contexto como limitao de recursos, dependncias entre
as recomendaes, fatores externos e prioridades globais da organiza-
o.
Desenvolver
abordagem
Desenvolve uma estratgia para realizao do trabalho combinando
dados do diagnstico com as prioridades estabelecidas. Leva em conta
aspectos tcnicos como a necessidade de aquisio de tecnologias, e
aspectos culturais da organizao como focos de resistncia e papel dos
patrocinadores em aes especficas.
Estabelecimento
(Estabilishing)
Planejar Aes Produz um plano detalhado de ao, estabelecendo elementos caracte-
rsticos de projetos como: tarefas, cronograma, marcos, recursos, res-
ponsabilidades, riscos e estratgias de mitigao, mecanismos de acom-
panhamento.

25
Quadro 2.6(b): Descrio resumida das atividades do modelo IDEAL.
FASE ATIVIDADE DESCRIO RESUMIDA
Criar a soluo Combina efetivamente todos elementos previstos no plano de ao para
criar uma proposta de soluo para a melhoria pretendida. Por exemplo,
se um objetivo estabelecido for implantar um processo de Gerncia de
Requisitos, criar a soluo implica em definir o processo a ser implan-
tado detalhadamente em todos os seus elementos.
Pilotar/ testar a
soluo
Pe em prtica a soluo criada normalmente atravs de um teste piloto.
No significa a implantao definitiva. Requer a seleo cuidadosa de
situaes reais da organizao que se prestem a um teste piloto que
proporcione informaes vlidas sobre o desempenho da soluo pre-
vista sem riscos excessivos para a organizao. Em relao ao exemplo
anterior, significa por em prtica o processo criado de gerncia de re-
quisitos em um projeto piloto, por exemplo.
Refinar a solu-
o
Tira lies aprendidas do teste piloto, corrige e refina a soluo inicial-
mente criada. Pode requerer vrias iteraes de teste seguido de refina-
mento. No significa a criao de uma soluo necessariamente perfei-
ta.
Ao
(Acting)
Implantar a
soluo
Implanta efetivamente a soluo na organizao. Leva em conta a abor-
dagem definida na fase de estabelecimento (top-down ou bottom-up, por
exemplo). No exemplo mencionado, significa a implantao do proces-
so de gerncia de requisitos nos diversos projetos de desenvolvimento
ou manuteno de software da organizao.
Analisar e vali-
dar
Analisa em que medida o esforo atendeu aos objetivos estabelecidos
incluindo as necessidades de negcio identificadas na fase inicial. Veri-
fica o que funcionou bem e o que poderia ser feito melhor. Lies so
coletadas, analisadas, sumarizadas e documentadas.
Aprendizagem
(Learning)
Propor aes
futuras
Desenvolve e documenta recomendaes com base nas anlises e vali-
daes realizadas. As recomendaes podem ser endereadas a diferen-
tes nveis da organizao.

O IDEAL claramente influenciado pelo conhecido ciclo PDCA (plan-do-check-
act) muito utilizado em abordagens tradicionais de implantao do gerenciamento da qualida-
de total (Campos, 1992). Todavia uma diferena significativa o fato do IDEAL incorporar
explicitamente na fase learning a idia de aprendizagem a partir das aes realizadas. A
importncia deste aspecto ser retomada em captulo posterior desta dissertao.
Como j citado, o IDEAL um guia genrico para implementao de melhorias e
a quantidade de iteraes a serem realizadas e o tempo de cada uma pode variar de acordo
com o contexto e a estratgia adotada em cada esforo de melhoria. A ttulo de exemplo, uma
forma possvel de utilizao deste guia em MPS conjuntamente com o modelo CMMI em
estgios, seria o estabelecimento uma iterao para cada nvel de maturidade a ser atingido.
Uma outra possibilidade poderia ser granularizar mais as etapas, propondo uma iterao do
IDEAL mais curta para cada rea de processo prevista em cada nvel de maturidade do CM-
MI. Estas decises so fortemente influenciadas pela infra-estrutura que a organizao capaz
de disponibilizar para o esforo de melhoria.
26
2.3 INFRA-ESTRUTURA ORGANIZACIONAL PARA MPS
Conforme mencionado na seo anterior a infra-estrutura disponibilizada para o
esforo de melhoria um fator muito importante. Esta infra-estrutura crtica para o estabe-
lecimento de papis e responsabilidades para aqueles que iro conduzir o esforo de melhoria,
realizando atividades como planejamento, definio de processos, avaliaes, auditorias, do-
cumentao e treinamento para os usurios dos processos, e para a prpria equipe de melhori-
a. A Figura 2.6 ilustra uma estrutura organizacional tipicamente recomendada e utilizada.

Figura 2.6: Infra-estrutura organizacional para MPS
16
.
Os elementos da Figura 2.6 podem ser melhor descritos conforme a seguir:
Comit Diretivo de MPS: composto em sua maior parte por membros da alta
administrao tem por funo estabelecer diretrizes de alto nvel para o esforo
de melhoria, acompanhar e cobrar o cumprimento de metas e, fundamental-
mente, proporcionar o suporte poltico e de infra-estrutura necessrios aos tra-
balhos dos demais grupos. Os membros deste comit so dedicados em tempo
parcial.
Grupo de Processo de Engenharia de Software (SEPG
17
): prioriza e planeja
os processos a serem definidos ou melhorados; valida as melhorias propostas
pelos Times de melhorias de Processos. Os membros deste comit so os cha-
mados engenheiros de processos. Parte dos membros pode ser alocada nesta

16
Ilustrao baseada em Ahern, Clouse e Turner (2003, Captulo 2, Seo 2.2).
17
SEPG, do ingls: software engineering process group. A sigla em ingls comumente encontrada mesmo na
literatura brasileira de MPS.
Projects
Comit de Diretivo
de MPS
Grupo de Processo
de Eng. de Software
(SEPG)
Grupo de Garantia da
Qualidade de Software
(SQA)
Projects
Projetos de Desenv. de
Software
Times de Melhoria
de Processos
Consultores
Externos

27
funo em tempo parcial, mas convm que haja outros alocados em tempo in-
tegral. importante que neste grupo haja representatividade das diversas reas
e grupos de desenvolvimento de software da organizao.
Grupo de Garantia da Qualidade de Software (SQA
18
): responsvel pela
avaliao e auditoria interna que verifica nos diversos projetos de desenvolvi-
mento de software se os processos de software estabelecidos esto em uso de
fato, conforme os requisitos especificados. Parte dos membros pode ser aloca-
dos nesta funo em tempo parcial, mas convm que haja outros alocados em
tempo integral.
Times de Melhoria de Processos: so times de natureza mais temporria cria-
dos para desenvolver uma rea de processo especfica. Normalmente formados
por especialistas na rea (por exemplo: se a rea de processos em questo for a
de Gerncia de Projetos, o grupo ser composto por gerentes de projetos e ou-
tros profissionais que agreguem conhecimento rea) com o apoio de enge-
nheiros de processos.
Projetos de Desenvolvimento de Software: so os diversos projetos de soft-
ware que esto em curso na organizao, cujas equipes devem utilizar os pro-
cessos j estabelecidos. Estas equipes so os usurios mais diretos dos proces-
sos de software estabelecidos.
Consultores Externos: especialistas em MPS e outros aspectos como condu-
o de mudanas, externos organizao, que so eventualmente contratados
para apoiar o esforo.
Vale ressaltar que esta uma estrutura genrica que pode ocorrer com muitas va-
riaes. Um dos aspectos que costuma ser determinante para a disponibilizao da infra-
estrutura o porte da organizao. Quanto maior a organizao, normalmente, maiores as
condies para o estabelecimento dos grupos previstos na Figura 2.6 e alocao de profissio-
nais neles. Em organizaes pequenas os grupos o SEPG e SQA costumam ser fundidos em
um s, e no raro, no h necessariamente um grupo, mas um nico profissional que acumula
estes papis. Assim como muitas vezes pode no haver um comit diretivo e sim um nico
membro da alta administrao que faz o papel de patrocinador do esforo de MPS. Uma outra

18
SQA, do ingls: Software Quality Assurance. A sigla em ingls comumente utilisada mesmo na literatura
brasileira de MPS. Frequentemente, conforme constatado na pesquisa de campo desta dissertao, ela tam-
bm usada coloquialmente para designar os prprios profissionais da qualidade de software.

28
caracterstica que os participantes podem estar inseridos em mais de um grupo ao mesmo
tempo.
Em todo caso, conforme constatado na pesquisa descrita no Captulo 3 desta dis-
sertao, a experincia mostra que o sucesso da iniciativa costuma exigir ao menos um profis-
sional dedicado inteiramente ao esforo de melhoria. Da mesma forma como exige o apoio da
alta administrao e dos desenvolvedores, conforme constatado na mesma pesquisa.
Um outro aspecto importante de infra-estrutura, que pesquisadores e praticantes
da rea de MPS tm dado crescente ateno, diz respeito criao de ambientes de sistema de
informao voltados especificamente para apoiar a definio e evoluo de processos de soft-
ware. Estes sistemas de informao tendem a ter uma importncia crescente no campo de
MPS na medida em que as ferramentas propostas se integrem aos prprios projetos de desen-
volvimento de software. Trabalhos de Rocha e outros (2005), e Oliveira, Vasconcelos e
Rouiller (2005) exploram esta tendncia.
2.4 ESTIMATIVAS DE ESFORO, RETORNO E FALHA EM INICIATIVAS DE
MPS
Para complementar uma viso geral de iniciativas de MPS, convm dedicar um
olhar sobre o esforo de custo e tempo, bem como o retorno esperado. Neste sentido, esta se-
o no tem a pretenso de fornecer uma viso necessariamente detalhada desta questo, que
certamente poderia exigir uma pesquisa especificamente voltada para este objetivo. O intuito
aqui to somente ilustrar alguns dados de outros estudos que forneam uma ordem de gran-
deza para estes fatores. Para tanto, so exibidos dados especificamente relacionados aborda-
gem de MPS que vem sido ilustrada no captulo. No menos importante, tambm mencio-
nada uma estatstica de falhas em projetos de implantao de MPS. Estes dados sugerem uma
idia da complexidade deste tipo de iniciativa
Conforme se poderia supor a partir de uma viso crtica dos conceitos, modelos e
processos de melhoria referidos neste captulo, uma iniciativa de MPS pode requerer um es-
foro considervel a depender do escopo de melhoria. Corroborando esta afirmao, o Quadro
2.7 mostra resultados consolidados pelo prprio SEI, a partir de avaliaes oficiais desta insti-
tuio, em relao ao tempo mdio requerido pelas empresas para galgar os nveis de maturi-
dade do CMM.
29
Quadro 2.7: Tempo mdio para passagem de nveis de maturidade no modelo SW-CMM
19
.
Passagem de Nvel de Maturidade Mdia de meses necessrios
1 2 19
2 3 19
3 4 24
4 5 13
Total necessrio: 1 5 75

Pelo exposto no Quadro 2.7, se v que chega a mais de seis anos o tempo mdio
necessrio para se atingir o nvel cinco de maturidade, quando de acordo com o CMM, uma
organizao atinge propriamente o nvel de melhoria contnua.
O custo de projetos de implantao de MPS, certamente tambm pode variar con-
sideravelmente de acordo com o escopo de melhoria estabelecido. Provavelmente por ques-
tes de sigilo do negcio, tanto por parte das organizaes que prestam servios de MPS, co-
mo por parte das organizaes-clientes, infelizmente no se dispe facilmente de estatsticas
publicadas a respeito. Rico (2002) estima um custo total de US$ 850.500,00 para aplicao do
SW-CMM, em uma organizao que possua quatro projetos de sistemas em desenvolvimento,
envolvendo custos de treinamento e implantao para desenvolvimento de todos os requisitos
dos nveis dois e trs do SW-CMM e mais o custo de avaliao. Segundo o mesmo autor, um
contexto semelhante de aplicao do CMMI-SE
20
pode chegar a US$ 2.315.565,00. Pelo ex-
posto, considerando a realidade brasileira, onde grande parte das empresas de software de
pequeno porte, se verifica que um investimento desta ordem de grandeza algo bastante dif-
cil, seno impraticvel em muitos casos.
Quadro 2.8: Resultados de Performance de Retorno do CMMI em casos reais
21
.
Melhoria de desempenho
Categoria Mdia Pior Resultado Melhor Resultado
Tamanho
da Amostra
Custo 20% 3% 87% 21
Cronograma 37% 2% 90% 19
Produtividade 62% 9% 255% 17
Qualidade 50% 7% 132% 20
Satisfao do Cliente 14% -4% 55% 6
Retorno do Investimento 4.7 : 1 2 : 1 27.7 : 1 16


19
SW-CMM Maturity Profile March 2006 (CMU/SEI, 2006).
20
CMMI-SE voltado para Engenharia de Sistemas, que pode incluir integrao de componentes de software e
hardware.
21
CMMI Performance Results (CMU/SEI, 2006).
30
Quanto expectativa de retorno, o Quadro 2.8 apresenta dados publicados pelo
SEI que demonstram que o retorno de iniciativas bem sucedidas de MPS com base no CMMI
pode ser bastante compensador.
Todavia, a performance relatada acima no inclui as situaes de falha. No decor-
rer deste trabalho no foram encontrados muitas referncias sobre estatsticas de insucesso em
programas de MPS semelhana do conhecido Chaos Report (Standish Group Internatio-
nal, Inc., 2001) que voltado para projetos de desenvolvimento e implantao de sistemas.
Porm as indicaes disponveis so de que o nmero de iniciativas mal-sucedidas significa-
tivamente maior do que as bem-sucedidas. Iversen (2004) cita relatrio do SEI que relata que
de um total de 1.638 empresas que sofreram avaliao inicial, somente 34% voltaram a fazer
nova avaliao para tentar melhorar seu nvel de maturidade no CMM. Destas, 13% no obti-
veram sucesso em melhorar seu nvel de maturidade e 3,1% chegaram a descer seu nvel. De-
bou e Kuntzmann (2000) relatam que apenas um tero dos projetos de MPS pesquisados obti-
veram sucesso em melhorar a performance da organizao de forma significativa. A pesquisa
realizada em Recife, Brasil, para esta dissertao (a ser detalhada no Captulo 3) sugere que
no mercado local, o percentual de sucesso deste tipo de iniciativa pode ser ainda menor do
que as referncias acima.
2.5 CONSIDERAES FINAIS AO CAPTULO
Este captulo buscou mostrar uma viso global do que vm a ser iniciativas de
MPS na forma atualmente mais usada na indstria. Resumidamente, de acordo com o exposto,
realizar MPS envolve, entre outras coisas:
Adotar um modelo de referncia para implementao de requisitos de melho-
ria a exemplo de um modelo de maturidade como o CMMI, ilustrado neste ca-
ptulo;
Tendo como base modelos de processos de software a exemplo do RUP ilus-
trado neste captulo;
Adotar um mtodo para avaliao peridica da evoluo do esforo de melho-
ria, a exemplo do SCAMPI (a depender do modelo de referncia utilizado para
melhoria), tambm aqui ilustrado;
Adotar uma estratgia de implementao incremental das melhorias semelhan-
te ao IDEAL, tambm aqui ilustrado.
31
Conforme se pde observar neste captulo, um aspecto que adiciona complexidade
considervel a prpria proliferao de modelos, mtodos e guias sobre processos e melhoria
de processos de software disponveis na indstria (ver Figura 2.3). Devido a esta grande mul-
tiplicidade, Ahern, Clouse e Turner (2003) chegam a comparar a rea de melhoria de proces-
sos estria bblica da Torre de Babel, pelo risco do desentendimento gerado por tantos
modelos no necessariamente compatveis. Este fenmeno revela que esta rea de conheci-
mento deu origem, dentro da indstria de software, a uma indstria de melhoria de proces-
sos, cujos clientes primrios so organizaes que produzem software e cujo mercado pode
chegar a bilhes de dlares em escala global. Desta forma, torna-se importante desenvolver
um senso crtico de que estes diferentes modelos no deveriam ser vistos puramente como
resultados de pesquisas supostamente isentas, mas tambm, como produtos concorrentes
que buscam se impor como padres numa indstria lucrativa. Isto gera risco de m escolha
pelos praticantes de MPS simplesmente porque podem tender a seguir um padro de mercado
que pode ser inadequado ao contexto especfico de suas organizaes.
Ainda outra caracterstica verificvel desta proliferao de modelos que eles
tendem a priorizar questes tcnicas, procedimentais ou instrumentais do esforo de melhoria,
mesmo quando muitos deles faam tambm referncias a aspectos humanos e sociais conside-
rados determinantes para o sucesso das mudanas pretendidas. A anlise deste aspecto em
captulo posterior um dos objetivos desta dissertao.
Pelo exposto neste captulo, de se esperar que iniciativas de MPS sejam desafios
complexos sujeitos a muitos percalos de natureza tcnica, humana, econmica e organiza-
cional. Apesar do comprovado retorno de iniciativas de MPS bem sucedidas, h indicaes
relevantes de que a maioria significativa das iniciativas so mal-sucedidas. No Captulo 3
desta dissertao so abordados fatores considerados crticos para o sucesso ou fracasso de
programas de MPS com base em pesquisa em Recife, Brasil, e em relatos na literatura mundi-
al em MPS.

32
3 FATORES CRTICOS EM MPS: UMA PESQUISA QUALITATIVA
Nos comentrios finais ao Captulo 2, argumentou-se que a implementao de ini-
ciativas de melhoria de processos de software representa um desafio geralmente bastante
complexo, tendo em vista a multiplicidade de fatores de diversas naturezas que influem no
processo. O presente captulo procura justamente debruar-se mais detidamente sobre os fato-
res que concorrem para o sucesso ou fracasso deste tipo de esforo, com base na prpria opi-
nio de participantes de iniciativas de MPS.
Para tanto, foi realizada uma pesquisa qualitativa, documentada neste captulo,
com 19 profissionais, em sua grande maioria, integrantes de empresas da cidade de Recife,
Brasil, que estiveram participando em programas de MPS em suas organizaes. Os entrevis-
tados estiveram exercendo diferentes papis envolvidos no esforo de MPS: consultores, audi-
tores e engenheiros da qualidade, diretor tcnico, gerentes de projeto de software e desenvol-
vedores (analistas de sistemas, lderes tcnicos e outros profissionais de engenharia de softwa-
re). O objetivo maior desta pesquisa foi o de gerar informao sobre programas de MPS que
pudessem ser utilizadas para analisar este tipo de iniciativa enquanto interveno na organi-
zao, anlise esta, que feita em captulos subseqentes desta dissertao.
Esta pesquisa subsidiou a identificao de uma lista de 24 fatores crticos entre fa-
cilitadores e barreiras que so individualmente detalhados e analisados no Apndice B da
dissertao. Busca-se analisar a natureza dos fatores crticos apontados na pesquisa e tambm
como estes fatores podem ser relacionados numa perspectiva sistmica.
Os resultados da pesquisa so tambm comparados ao de outras pesquisas seme-
lhantes encontrados na literatura de MPS. Foi possvel ento, a identificao de semelhanas e
particularidades que podem ser informaes teis para a conduo de projetos MPS na regio
das empresas pesquisadas.
3.1 METODOLOGIA E CONTEXTO DA PESQUISA
Foi realizada uma pesquisa qualitativa com foco principal na anlise temtica
(Franco, 2005, Pg. 39) de aspectos considerados facilitadores ou barreiras em programas de
MPS. Para tanto, foram entrevistados diversos profissionais envolvidos com iniciativas de
33
MPS de larga escala em suas empresas. Por iniciativas de MPS de larga escala entendemos
aqui, aquelas que implicam na definio, implantao e melhoria de um processo de software
a ser usado em toda a organizao, que demanda um esforo e infra-estrutura (pessoas, recur-
sos) da empresa alocada especificamente para este intento, por vrios anos ou mesmo perma-
nentemente.
A pesquisa obedeceu s seguintes etapas:
1. Pesquisa exploratria (pesquisa bibliogrfica em livros, peridicos, sites espe-
cializados e artigos para identificao preliminar do problema de pesquisa)
22
;
2. Planejamento (definio de objetivos, da amostra, das tcnicas a serem utili-
zadas e estimativa de prazos);
3. Coleta de dados atravs de entrevistas gravadas com base em questes semi-
estruturadas e abertas;
4. Transcrio de dados (transcrio do contedo gravado das entrevistas);
5. Classificao temtica identificando fatores crticos em melhoria de processos
de software (identificao de pensamentos chave e construtos presentes nos
discursos dos entrevistados; categorizao temtica dos pensamentos chave e
construtos; identificao dos pensamentos chave em termos de facilitadores
ou barreiras em programas de MPS). Este passo geralmente requer vrias ite-
raes para a obteno de classes relevantes, homogneas e excludentes.
6. Anlise dos dados (contagem das incidncias, por categorias; classificao das
categorias de acordo com suas incidncias; seleo das principais categorias;
contextualizao das categorias encontradas);
7. Sntese das categorias em uma lista fatores crticos em MPS (ordenao das
categorias identificando nmero de incidncias de facilitadores e barreiras em
MPS; criao de um dicionrio com o significado detalhado de cada categoria
a partir dos contedos coletados; seleo de trechos de relatos representativos
de cada categoria);
8. Interpretao dos dados (anlise cada fator crtico no contexto das entrevistas;
comparao com resultados de pesquisas semelhantes; relacionamento de cada
fator crtico aos elementos da teoria de interveno que ser vista no Captulo
4; identificao de padres sistmicos entre os fatores crticos identificados);

22
Esta pesquisa resultou na publicao e apresentao de um artigo conceitual no IV Simpsio Brasileiro de
Qualidade de Software (Santana e Moura, 2005).

34
9. Relato dos resultados.
O mtodo de entrevista com questes semi-estruturadas e abertas (Richardson,
1999, Captulo 13, Pg 208) foi escolhido por possibilitar uma maior possibilidade de investi-
gao em profundidade do contexto dos entrevistados de forma a melhor relacion-lo teoria
de interveno que ser vista no Captulo 4.
O mtodo de anlise do contedo utilizado sobre os relatos de entrevistas foi es-
colhido com base no argumento de Freitas e Janissek (2000, Pg. 37) de que um dos propsi-
tos deste mtodo observar motivos de satisfao, insatisfao ou opinies subentendidas e
natureza dos problemas relatados pelos pesquisados. De acordo com estes mesmos autores, o
mtodo pressupe que uma parte importante do comportamento, opinies ou idias de pessoas
se exprime sob a forma verbal. De acordo com Perrien, Chrron e Zins citados por Freitas e
Janissek (2000, Pg. 37), a anlise de contedo torna possvel analisar as entrelinhas das
opinies das pessoas, no se restringindo unicamente s palavras expressas diretamente, mas
tambm quelas subentendidas no discurso. A unidade bsica utilizada para anlise dos rela-
tos foi o tema, aqui compreendido como uma assero sobre um determinado assunto, poden-
do ser uma simples sentena (sujeito e predicado), um conjunto delas ou um pargrafo, con-
forme definido por Franco (2005, Pg. 39).
Quanto ao desenvolvimento das entrevistas em si, aps algumas perguntas para
entendimento do contexto do entrevistado, o assunto central da entrevista girava em torno das
questes:
a) Quais os aspectos que voc considera como sendo facilitadores, impulsiona-
dores, pontos fortes da experincia de MPS na empresa em que trabalha?
b) Quais os aspectos que voc considera como sendo barreiras, dificultadores,
pontos fracos da experincia de MPS na empresa em que trabalha?
Estas questes podiam derivar outras perguntas complementares que variavam
conforme o relato dos prprios participantes buscando explorar temas relevantes associados a
questes como:
Como os problemas eram tratados?
Como as informaes eram compartilhadas?
As questes complementares variaram tambm em funo do papel do entrevista-
do. Os roteiros completos das entrevistas encontram-se no Apndice A desta dissertao.
Anteriormente s entrevistas, os participantes foram contatados por email com um
convite para participar da pesquisa que seria realizada com uma entrevista gravada, e conten-
do um roteiro bsico das questes, prevendo um tempo de cerca de 40 minutos para os profis-
35
sionais de MPS e 30 minutos para os demais. Os participantes foram estimulados a falar o
mais livremente possvel sobre as questes com o compromisso de no serem identificados
como indivduos, nem suas empresas, e caso desejassem, poderiam solicitar a interrupo da
gravao.
A amostra das entrevistas foi intencional e buscou envolver diferentes tipos de
profissionais envolvidos na experincia de MPS, seja na conduo direta da iniciativa (aqui
identificados como profissionais de MPS), ou porque tinham seu trabalho diretamente afe-
tado por ela (aqui identificados como desenvolvedores de software e diretor tcnico). Desta
forma, foram entrevistados profissionais de acordo com o Quadro 3.1.
Quadro 3.1: Caractersticas dos entrevistados.
Tipo de Profissional Descrio N de Entrevistados
Profissionais de MPS Consultores em MPS, Engenheiros da
Qualidade, SQAs e Gerentes da Qualidade.
7
Desenvolvedores de
Software
Gerentes de Projeto e Desenvolvedores em
geral nos papis de: Analista de Sistemas,
Arquiteto de Software e Lder Tcnico.
11
Diretor tcnico Diretor tcnico de empresa que atua na
rea de desenvolvimento de software.
1
Total de Entrevistados 19

Durante as entrevistas, os profissionais referiram-se ao que julgaram mais relevan-
te em termos de suas experincias com MPS. Em um total foram relatadas experincias em 10
empresas distintas de acordo com o Quadro 3.2. Das empresas referidas no Quadro 3.2 apenas
uma no tinha software como rea de interesse finalstico. Nove eram da iniciativa privada
uma era pblica e a outra era mista. Todas possuiam unidades em Recife, sendo que algumas
tambm em outras cidades (trs delas tm sua sede em outras cidades). Oito destas empresas
estiveram interessadas na obteno de certificao ou avaliao oficial de seus processos de
software atravs de modelos normativos
23
como CMMI, MPS.Br ou ISO. Destas, trs j havi-
am obtido avaliao oficial CMM nvel 2 e estavam em busca do CMMI nvel 3, outras duas
j haviam obtido ISO 9000:2000 e estavam em busca de obteno de CMMI-2 e MPS.Br n-
vel G respectivamente. Uma delas buscava obter o MPS.Br nvel G e tambm o CMMI-2. As
demais ainda no possuam certificao e buscavam obter o CMMI-2.


23
Ver Seo 2.2 desta dissertao, sobre modelos normativos em melhoria de processos de software.
36
Quadro 3.2: Caractersticas das empresas dos entrevistados.
Empresa N de
Funcs.
Ramo de Negcio Certificaes
Obtidas
Objetivo do Pro-
grama de MPS
Referncias em
entrevistas
24

A 100 500 Privado desenvolvimento
de sistemas (que incluem
hardware e software).
CMM-2 Certificao CMMI 1
B 50 100 Privado - desenvolvimento de
produtos e projetos de soft-
ware, desenvolvimento de
sistemas (que incluem hard-
ware e software).
ISO 9001 Certificao CMMI 8
C > 500 Privado - desenvolvimento de
projetos de software e siste-
mas.
CMM-2 Certificao CMMI 5
D 100 500 Privado - desenvolvimento de
projetos de software e siste-
mas.
- Certificao CMMI 2
E < 50 Privado - desenvolvimento de
produtos e projetos de Soft-
ware.
MPS.Br Certificao CMMI 3
F 100 500 Privado - desenvolvimento de
produto de software.
ISO 9001 Certificao
MPS.Br
1
G > 500 Pblico - desenvolvimento de
produtos de software e pres-
tao de servios para o Go-
verno Federal.
CMM-2 Certificao CMMI 1
H > 500 Pblico servios bancrios. - Melhoria sem visar
certificao espec-
fica.
1
I < 50 Parceria Pblico/Privada
servios de fomento inds-
tria de software
No se aplica No se aplica 1
J < 50 Privada consultoria proces-
sos de desenvolvimento de
software
No se aplica No se aplica 1






24
Quantidade de entrevistas em que a empresa foi referida.
37
3.2 QUADRO SINTTICO DE FATORES CRTICOS EM MPS
Seguindo as etapas previstas na seo anterior, obteve-se a sntese demonstrada no
Quadro 3.3.
Quadro 3.3: Sntese temtica de fatores crticos em MPS.
Fatores Crticos em MPS Facilitadores Barreiras
freq % freq %
Freq
Total
1. Tempo e Recursos para MPS 10 52,6% 16 84,2% 26
2. Apoio e comprometimento da equipe de desenvolvimento 5 26,3% 14 73,7% 19
3. Apoio/Comprometimento da Alta Administrao 9 47,4% 9 47,4% 18
4. Envolvimento da equipe de desenvolvimento 12 63,2% 5 26,3% 17
5. Conscientizao/ entendimento dos benefcios e exigncias de MPS 11 57,9% 6 31,6% 17
6. Postura da equipe de qualidade 7 36,8% 9 47,4% 16
7. Fatores motivacionais para MPS 6 31,6% 10 52,6% 16
8. MPS como obstculo ao "trabalho real" 0 0,0% 16 84,2% 16
9. Treinamento e mentoria 12 63,2% 3 15,8% 15
10. Experincia e qualificao 6 31,6% 8 42,1% 14
11. Processo e infra-estrutura para compartilhar conhecimento 7 36,8% 6 31,6% 13
12. Atitude dos Clientes 5 26,3% 6 31,6% 11
13. Metodologia formal 5 26,3% 4 21,1% 9
14. Gerenciamento do projeto de MPS e da mudana 7 36,8% 2 10,5% 9
15. Comunicao e feedback sobre andamento da MPS 5 26,3% 3 15,8% 8
16. Objetivos claros, relevantes e alinhados 3 15,8% 4 21,1% 7
17. Adaptao de processos realidade dos projetos 5 26,3% 2 10,5% 7
18. Delegao de responsabilidade / criao de times de ao 5 26,3% 1 5,3% 6
19. Conflitos Organizacionais 0 0,0% 6 31,6% 6
20. Rotatividade da equipe 0 0,0% 6 31,6% 6
21. Escopo de processos e projetos 0 0,0% 5 26,3% 5
22. Revises / Inspees / Auditorias 2 10,5% 2 10,5% 4
23. Esquemas de recompensa 3 15,8% 1 5,3% 4
24. Viabilizao de iniciativas em MPS 3 15,8% 0 0,0% 3

No Quadro 3.3 pode-se observar que no conjunto das entrevistas, a maioria dos
temas foi pontuado ao mesmo tempo como facilitador e como barreira. Buscou-se, nestes
casos, listar no quadro a descrio positiva do tema que deve ser entendida na sua forma
direta enquanto facilitador. J a manifestao do tema enquanto barreira deve ser entendida
na maioria das situaes enquanto ausncia, insuficincia ou ineficcia da descrio positi-
38
va do tema. Por exemplo, o tema descrito como Apoio/Comprometimento da Alta Adminis-
trao quando considerado enquanto fator facilitador indica que os entrevistados relataram a
ocorrncia deste fator na sua experincia prtica como algo que pode ser entendido com cono-
tao favorvel ao sucesso da iniciativa. O mesmo tema quando considerado enquanto barrei-
ra indica que os entrevistados relataram ausncia, insuficincia ou ineficcia deste fator na
sua experincia com MPS.
Quanto contagem de freqncia de cada tema, considerou-se a contagem de uma
unidade por entrevista completa. Isto , apesar de haver casos em que um mesmo entrevistado
refere-se a um mesmo fator mais de uma vez durante a entrevista, a contagem da freqncia
relativa ao tema acrescida de apenas uma unidade por entrevista. Conforme se pode tambm
observar no quadro, a soma das freqncias enquanto facilitador ou barreira de um tema es-
pecfico pode ser maior que o nmero total de entrevistas (o que faz com que a soma dos per-
centuais entre facilitador e barreira possa ser superior 100%). Isto se explica porque um
mesmo tema pode ter sido contextualizado numa mesma entrevista hora como facilitador,
hora como barreira.
Para um entendimento mais aprofundado dos itens do Quadro 3.3 convm ler o
Apndice B desta dissertao que contm um detalhamento de cada fator listado, no qual
consta:
O significado de cada fator do Quadro 3.3, conforme interpretado pelo autor
desta dissertao na etapa de classificao temtica de idias-chave obtidas
nas entrevistas;
Um comentrio analtico resumido sobre cada tema;
Exemplos de trechos de relatos de entrevista que demonstram cada fator en-
quanto facilitador e/ou barreira para a iniciativa de MPS;
Uma anlise resumida sobre a relao de cada fator com as atividades prim-
rias de interveno que sero referidas no Captulo 4, Seo 4.3 desta disser-
tao.
3.2.1 Comparao com Outras Pesquisas Encontradas na Literatura de MPS
Algumas pesquisas podem ser encontradas na literatura voltada para MPS sobre
fatores crticos em MPS enquanto facilitadores e barreiras. Niazi, Wilson e Zowghi (2003)
apresentam uma pesquisa, metodologicamente prxima realizada neste trabalho, feita em
empresas australianas. Neste mesmo trabalho estes autores realizaram uma pesquisa na litera-
39
tura mundial de MPS, sobre facilitadores e barreiras em MPS a fim de comparar com sua pr-
pria pesquisa. Os Quadros 3.4 e 3.5 apresentam uma comparao entre a pesquisa realizada
nesta dissertao e os dados obtidos em Niazi e outros.
Quadro 3.4: Facilitadores em MPS comparao com outras pesquisas.
Pesquisa no Porto Digital Pesquisa de Niazi e outros (2003)
Facilitadores S % L % N % Facilitadores
Tempo e Recursos para MPS 53 38 44 Tempo da equipe e recursos
51 44 Envolvimento da equipe Apoio e comprometimento da equipe de
desenvolvimento
26
23 - Pertena do processo
Apoio/Comprometimento da Alta Adminis-
trao
47 66 65 Comprometimento da gerencia snior
Envolvimento da equipe de desenvolvimento 63 51 44 Envolvimento da equipe
- 52 Conscincia sobre MPS Conscientizao/ entendimento dos benef-
cios e exigncias da MPS
58
15 - Prover entendimento aprofundado
Postura da equipe de qualidade 37 - 26 Facilitao
Fatores motivacionais para MPS 32 - -
Treinamento e mentoria 63 49 65 Treinamento e mentoria
Experincia e qualificao 32 28 35 Equipe experiente / Conhecimento
Processo e infra-estrutura para compartilhar
conhecimento
37 - -
Atitude dos Clientes 26 - -
Metodologia formal 26 - 35 Metodologia Formal
Gerenciamento do projeto de MPS e da
mudana
37 15 13 Gerenciamento do projeto de MPS
Comunicao e feedback sobre andamento
da MPS
26 21 22
Encorajamento da comunicao e cola-
borao
Objetivos claros, relevantes e alinhados 16 26 - Metas de MPS Claras e relevantes
Adaptao de processos realidade dos
projetos
26 - -
31 9 Criao de times de ao de processos Delegao de responsabilidade / criao de
times de ao
26
26 - Atribuio de Responsabilidade em SPI
Revises / Inspees / Auditorias 11 28 9 Revises
Esquemas de recompensa 16 15 - Esquemas de Recompensas
Viabilizao de iniciativas em MPS 16 15 9 Viabilizao de iniciativas de MPS
Legendas: S - Pesquisa realizada nesta dissertao.
L - Pesquisa na literatura de MPS realizada por Niazi e outros (2003).
N - Pesquisa de Niazi e outros (2003) em empresas australianas.

Em ambos os Quadros 3.4 e 3.5 as categorias encontradas foram justapostas por
semelhana. Pode-se observar que as categorias encontradas nas pesquisas de Niazi e outros
so em sua grande maioria bastante semelhantes com as encontradas no presente trabalho,
particularmente entre os fatores facilitadores. Todavia, entre as barreiras h algumas catego-
rias distintas importantes que podem sugerir caractersticas distintas entre as experincias com
MPS relatadas na pesquisa desta dissertao e aquelas da pesquisa de Niazi, Wilson e Zowghi
40
(2003). Entretanto, uma anlise mais profunda destas dissimilaridades pode no ser vivel,
pois no h como comparar o quo semelhantes foram os critrios das entrevistas e de classi-
ficao temtica entre as pesquisas.
Quadro 3.5: Barreiras em MPS comparao com outras pesquisas.
Pesquisa no Porto Digital Pesquisa de Niazi e outros (2003)
Barreiras S % L % N % Barreiras
50 35 Falta de recursos
Tempo e Recursos para MPS 84
36 17 Presso de Tempo
29 - MPS enquanto obstculo ao trabalho real
MPS como obstculo ao "trabalho real". 84
7 26
Documentao requerida/ procedimentos
formais
Apoio e comprometimento da equipe de de-
senvolvimento
74 14 -
Mudana do modelo mental da gerncia e
da equipe tcnica
Fatores motivacionais para MPS 53 - -
- 26 Falta de patrocnio Apoio/Comprometimento da Alta Administra-
o
47
21 48 Falta de apoio
Postura da equipe de qualidade 47 - -
Experincia e qualificao 42 36 17 Equipe experiente / Conhecimento
Conscientizao/ entendimento dos benefcios
e exigncias da MPS
32 - 43 Conscincia sobre MPS
Processo e infra-estrutura para compartilhar
conhecimento
32 - -
Atitude dos Clientes 32 - -
Conflitos Organizacionais 32 29 52 Politicagem na organizao
Rotatividade da equipe 32 29 - Rotatividade da equipe
Envolvimento da equipe de desenvolvimento 26 - -
Escopo de processos e projetos 26 - -
Treinamento e mentoria 16 - -
Metodologia formal 21 - 52 Metodologia Formal
Comunicao e feedback sobre andamento da
MPS
16 - -
Objetivos claros, relevantes e alinhados 21 - -
Gerenciamento do projeto de MPS e da mu-
dana
11 - -
Adaptao de processos realidade dos proje-
tos
11 - -
Delegao de responsabilidade / criao de
times de ao
5 - -
Revises / Inspees / Auditorias 11 - -
Experincias de fracasso 5 7 9 Experincias negativas
Esquemas de recompensa 5 - -
Legendas: S - Pesquisa realizada nesta dissertao.
L - Pesquisa na literatura de MPS realizada por Niazi e outros (2003).
N - Pesquisa de Niazi e outros (2003) em empresas australianas.

Nos Quadros 3.4 e 3.5, uma dificuldade encontrada para a comparao dos dados
desta pesquisa com o trabalho de Niazi, Wilson e Zowghi (2003) o fato da publicao destes
41
autores no conter um dicionrio de cdigos que detalhe o significado de cada categoria con-
forme feito no Apndice B desta dissertao. Assim, em alguns casos, torna-se difcil a
comparao de categorias entre as pesquisas. Um exemplo a categoria Facilitao encon-
trada em Niazi e outros, cujo significado no necessariamente evidente. Um outro exemplo
a categoria Falta de apoio, cuja descrio no identifica um grupo de atores especfico
(isto : falta de apoio de quem?). Em todo caso, as similaridades temticas sugerem que
grande parte dos problemas enfrentados nas iniciativas MPS referidas nos relatos desta pes-
quisa so semelhantes queles de iniciativas semelhantes que ocorrem em outras partes do
mundo.
Isto pode ser constatado em outros trabalhos relevantes que foram tambm pes-
quisados, particularmente, Baddoo e Hall (2003, 2002), que apresentam pesquisa sobre fatores
desmotivadores e motivadores em MPS, em 13 empresas do Reino Unido, com base em pes-
quisa qualitativa com grupos focais de discusso. Dyba (2005 e 2002) Apresenta pesquisas
sobre a importncia de questes organizacionais como fatores chaves para sucesso em MPS.
Tambm foram pesquisados os trabalhos de Rainer e Hall (2000), El Emam e outros (1998),
Stelzer e Mellis (1998), e Goldenson e Herbsleb (1995), sendo todos estes voltados para a
identificao de fatores crticos de sucesso em MPS, sem distino entre facilitadores e bar-
reiras. Vale ressaltar que estes ltimos foram concebidos metodologicamente de forma dife-
rente j que privilegiaram o levantamento dos dados atravs de questionrios escritos com
questes menos abertas.
No contexto de pesquisas brasileiras nesta rea, durante a elaborao desta disser-
tao quase no foram encontrados outros trabalhos voltados especificamente para identifica-
o de fatores de sucesso ou fracasso em MPS envolvendo um universo amplo de empresas.
Uma exceo encontrada, ainda que no apresente o detalhamento metodolgico das pesqui-
sas anteriormente citadas, o relatrio apresentado por Rocha (2005), que destaca:
A partir de uma anlise comparativa entre os fatores de sucesso e dificuldades na
implantao de processos de software utilizando o MR-MPS e o CMMI apresenta-
dos nas sees anteriores, pode-se perceber que existem alguns casos de espelha-
mento entre os fatores de sucesso e dificuldades. O comprometimento da empresa,
grau de acompanhamento dos processos implantados, disponibilidade de recur-
sos, motivao da empresa, apoio ferramental e treinamento demonstraram ser
fatores que influenciaram positivamente quando estavam fortemente presentes, e
quando eram fracos ou ausentes influenciaram negativamente na implementao de
processos de software utilizando o MR-MPS e o CMMI (Rocha, 2005. Grifos
meus).
42
3.2.2 Diferenas mais Marcantes para com os Resultados de Outras Pesquisas
Como diferenas mais marcantes encontradas entre os resultados desta pesquisa e
Niazi e outros (2003) referidos na Seo 3.2, chamam a ateno:
Tempo e Recursos para MPS: embora este tema esteja fortemente presente
em outras pesquisas vale ressaltar que foi pontuado negativamente de forma
bem mais alta na pesquisa desta dissertao. Isto pode indicar que as empresas
pesquisadas em Recife, Brasil, por motivos econmicos, tm bem mais difi-
culdade de levar adiante iniciativas de qualidade de software que suas corres-
pondentes internacionais pesquisadas nos outros trabalhos referidos.
Fatores motivacionais para MPS: Este tema no encontrado nas outras
pesquisas referidas. A inteno de certificao (ISO 9000 ou MPS.Br) ou ava-
liao oficial (CMM ou CMMI) mostrou-se como o argumento mais freqen-
temente referido nas entrevistas como fator motivacional do programa de
MPS. Normalmente esta inteno estava associada a motivaes mercadolgi-
cas da organizao tais como: maior possibilidade exportar produtos de soft-
ware e participao em licitaes. No nvel individual, foi relatada a inteno
de participar do processo de certificao como algo que traz experincia e me-
lhoria ao currculo profissional. Em apenas uma entrevista uma pessoa fez
questo de mencionar que a busca da qualidade em si era um fator mais rele-
vante do que a obteno de certificaes. Vale ressaltar que muitos relatos su-
gerem a constatao de que a nfase excessiva na busca por certificao s ve-
zes pode funcionar como uma barreira para a melhoria dos processos em si
(ver Apndice B, Seo B.7).
Processo e infra-estrutura para compartilhar conhecimento: Este tema no
encontrado nas outras pesquisas referidas. Um nmero significativo de en-
trevistados referiu-se falta de compartilhamento ou discusses de lies a-
prendidas, bem como falta de documentao ou repositrio estruturados de
conhecimentos adquiridos. De forma significativa houve tambm relatos da
presena deste fator em algum nvel, como uma referncia positiva no pro-
grama de MPS. Tende a ser muito influenciado tambm pelo fator comunica-
o e feedback sobre o andamento do programa de MPS destacado no Qua-
dro 3.3.
43
Atitude dos Clientes: Este tema no encontrado nas outras pesquisas referi-
das. De acordo com relato significativo de alguns entrevistados a definio e
formalizao de processos desenvolvimento de software era uma exigncia de
suas empresas-clientes e nesses casos isto foi um fator de grande relevncia
para facilitao do programa de MPS. Em outro caso, seno a exigncia, mas a
aceitao e colaborao do cliente foram igualmente relatadas como um facili-
tador. Por outro lado, de forma bastante surpreendente, cerca de um tero dos
entrevistados apontaram a existncia de desconfiana e resistncia ao progra-
ma de MPS por parte de empresas-clientes. Nessas situaes, a viso dos en-
trevistados foi de que os clientes tenderam a ver no programa de MPS um ris-
co indesejvel de aumento de custos dos servios. Nesses casos, estes fatores
agiram como sendo uma grande barreira ao programa, gerando, por exemplo,
conflitos entre a equipe de desenvolvimento (que se via pressionada pelos cli-
entes) e a rea de qualidade (que exigia o cumprimento dos processos estabe-
lecidos), e contribuindo para que MPS fosse vista como obstculo ao trabalho
real de atender o cliente. A desconfiana por parte dos clientes pode ser um
indicador de que as empresas nacionais consumidoras de software no esto
suficientemetente informadas sobre, ou no valorizam a qualidade de software
ou os modelos normativos empregados nesta rea, da mesma forma que valo-
rizam custo e prazo de entrega dos projetos.
Postura da equipe de qualidade: Este tema no encontrado nas outras pes-
quisas referidas. Atitudes da equipe de qualidade vistas como negativas como:
rigidez, rigor excessivo nas auditorias de processos, distanciamento e falta de
entrosamento, foram relatadas como barreiras MPS, uma vez que provoca-
vam maior resistncia das equipes de desenvolvimento. Em casos assim, os
auditores da qualidade foram vistos como inflexveis, distantes e, s ve-
zes, rotulados at como carrascos das equipes de desenvolvimento nas situa-
es de auditoria de processos (ver detalhamento deste tema no Apndice B,
Seo B.12). Este aspecto particularmente importante do ponto de vista da
abordagem terica desta dissertao e voltar a ser referido no Captulo 5.

44
3.3 ANLISE DOS RESULTADOS DA PESQUISA
Para alm do exposto na seo anterior e da anlise individual feita no Apndice
B sobre cada fator identificado no Quadro 3.3, torna-se til tambm um olhar global sobre
outros aspectos deste conjunto de fatores. Neste sentido, esta seo prope uma reflexo so-
bre:
A natureza dos fatores crticos apontados;
Inter-relaes entre os fatores: padres sistmicos identificados a partir da pes-
quisa.
3.3.1 Natureza dos Fatores Crticos Identificados
O Quadro 3.6 a seguir, agrupa os fatores crticos listados no Quadro 3.3 em macro
categorias gerais que ajudam a identificar a natureza dos problemas envolvidos em MPS.
Observando-se o Quadro 3.6 pode-se constatar que a maioria dos fatores realados
como barreiras ou facilitadores pelos entrevistados diz menos respeito a fatores puramente
tcnicos de engenharia de software ou mesmo modelos de qualidade para MPS, e muito mais
a fatores econmicos e organizacionais, a estratgias de conduo da iniciativa, e a fatores
humanos e sociais. Esta uma constatao relevante, considerando que MPS se trata de uma
interveno direta na atividade de desenvolvimento de software, que largamente vista como
tcnica. Esta constatao pode ser encontrada tambm nos resultados de outras pesquisas refe-
ridas na Seo 3.2.
A importncia dos aspectos da estratgia de conduo da iniciativa de MPS e ou-
tros aspectos que dizem respeito a fatores humanos e sociais, que podem ser observados no
Quadro 3.6, foi justamente a maior motivao para a escolha da abordagem terica que ser
usada nos captulos subseqentes desta dissertao para compreenso dos problemas de MPS.

45
Quadro 3.6: Natureza dos fatores crticos identificados na pesquisa.
Macro Categorias Fatores Crticos em MPS
a) Fatores econmicos (Recursos
disponibilizados para MPS)

Tempo e Recursos para MPS
Treinamento e mentoria (em parte, mentoria pode ser classificada
tambm na macro categoria (c) )
Experincia e qualificao
25

Viabilizao de iniciativas em MPS
b) Posicionamento e estratgias de
ao dos indivduos diante da inici-
ativa de MPS
Apoio e comprometimento da equipe
Apoio/Comprometimento da Alta Administrao
Postura da equipe de qualidade (em parte est tambm vinculada
macro categoria (c) )
Atitude dos Clientes
c) Estratgias de conduo da ini-
ciativa de MPS
Envolvimento da equipe
Conscientizao/ entendimento dos benefcios e exigncias de MPS
Processo e infra-estrutura para compartilhar conhecimento
Metodologia formal
Gerenciamento do projeto de MPS e da mudana
Comunicao e feedback sobre andamento da MPS
Objetivos claros, relevantes e alinhados
Adaptao de processos realidade dos projetos
Delegao de responsabilidade / criao de times de ao
Escopo de processos e projetos
Revises / Inspees / Auditorias
Esquemas de recompensa (em parte poderia ser classificado tambm
na macro categoria (a) )
d) Pressupostos e percepes dos
interessados
MPS como obstculo ao "trabalho real" (crena de que iniciativas de
MPS podem burocratizar a atividade de desenvolvimento de soft-
ware)
Fatores motivacionais para MPS (certificao da empresa, cresci-
mento profissional dos envolvidos, ou, melhoria dos processos pro-
priamente, conforme constatado na pesquisa).
e) Outros fatores do contexto da
organizao
Conflitos Organizacionais
Rotatividade da equipe

3.3.2 Inter-Relaes entre os Fatores: Padres Sistmicos Identificados a Partir da Pes-
quisa
Pode-se observar que muitos fatores relatados na Seo 3.2 esto relacionados en-
tre si atravs de relao causa-efeito. Estas relaes causais podem ser diretamente encontra-
das no discurso dos entrevistados como no exemplo a seguir, onde um deles relata:
46
Como tinha um turnover muito grande e a empresa estava passando por uma dificul-
dade financeira, a soluo adotada sempre aquela mais barata, que era trazer gente
que pedisse menos. E a essas pessoas eram menos qualificadas, geralmente estagi-
rios. E a realmente voc no podia atribuir, nem cobrar responsabilidade muito alta
de um estagirio. Ele estava ali para aprender. Ento, realmente isso complicava, as
pessoas que eram formadas tinham um gap conceitual muito grande. (Bartolomeu
26
,
Engenheiro da Qualidade).
A identificao de inter-relaes causais pode ser usada como uma estratgia de
gerao de informao sobre estruturas sistmicas de influncia mtua entre os fatores crticos
de MPS. A ttulo de exemplo, com base relato acima, podemos identificar um conjunto de
relaes causais que podem ser sintetizados de acordo com o diagrama da Figura 3.1.
Tempo e Recursos
para MPS
Experincia e
qualificao
Delegao de
responsabilidade /
criao de times de ao
Envolvimento /
participao da
equipe
+
+
+
Contratao de
estagirios
-
-
R

Figura 3.1: Diagrama causal entre Fatores Crticos em MPS a partir de relato de entrevista.

No diagrama acima as setas indicam relao de causa entre os fatores. Aquelas i-
dentificadas com o sinal - indicam relao de causa inversamente proporcional, enquanto as
identificadas com + indicam relao de causa diretamente proporcional. Assim de acordo
com o relato, pode-se interpretar o diagrama da seguinte forma: a diminuio de recursos na
empresa gerava uma maior contratao de estagirios que por sua vez levava a uma menor
experincia e qualificao da equipe. Esta levava a uma menor delegao de responsabilida-
de, que por inferncia, levava a um menor envolvimento da equipe de desenvolvimento em
aes de MPS, que findava reforando a baixa experincia e qualificao da equipe, constitu-
indo-se assim, um ciclo de reforo vicioso.

25
Este fator est classificado como fator econmico porque constatou-se na pesquisa em grande parte este
tema esteve relacionado capacidade da empresa de contratar e manter profissionais qualificados.
26
Nome fictcio.
47
Estruturas como a ilustrada na Figura 3.1 podem originar a padres de comporta-
mento do sistema ao longo do tempo que podem ser associados a arqutipos sistmicos. Ar-
qutipos sistmicos so estruturas sistmicas genricas compostas por relaes de causa-efeito
cclicas que se repetem em diferentes contextos (Senge, 2001, Captulo 6), geralmente, sem
que as pessoas tenham conscincia de seus efeitos na situao em questo. Por terem um
comportamento previsvel, a revelao destas estruturas pode inspirar estratgias de ao efi-
cazes para as situaes problemticas que elas representam. Tendo em mente o que sugere
Mathiassen, Nielsen e Pries-Heje (2002) quando argumentam que em MPS a resoluo de
problemas a essncia da melhoria, a identificao de arqutipos sistmicos pode ser um
mtodo particularmente til no uso de abordagens orientadas a problemas em MPS.
As sees seguintes exploram esta ferramenta de anlise qualitativa, atravs de
trs situaes problemticas identificadas com base nos relatos de entrevistas. As variveis
presentes nas ilustraes de arqutipos destas sees so desdobramentos dos fatores crticos
em MPS citados no Quadro 3.3 deste captulo, que esto presentes explcita ou implicitamente
nos relatos dos entrevistados. Como apoio ao entendimento destes arqutipos, o apndice C
desta dissertao traz um resumo da estrutura causal padro dos arqutipos sistmicos identi-
ficados.
3.3.2.1 Arqutipo 1 - Limite ao Sucesso do Programa de MPS: a Necessidade de So-
brevivncia da Empresa
Vrios relatos dos entrevistados do conta de que os resultados concretos de pro-
gramas de MPS esto bastante relacionados capacidade de sustentao do esforo de melho-
ria no longo-prazo. Esta capacidade de sustentao particularmente no universo pesquisado
depende da condio financeira da empresa em sustentar tempo e recursos destinados para
MPS. O padro sistmico gerado sugere o enquadramento no arqutipo de limite ao sucesso
tambm conhecido como limite ao crescimento (ver estrutura genrica deste arqutipo no
Apndice C, Seo C.2).
De acordo com diversos relatos nas entrevistas, o programa de MPS geralmente
surgiu nas empresas como uma iniciativa que passou se concretizar com o apoio e comprome-
timento da alta administrao quando esta tomou a deciso de investir tempo e recursos da
equipe para MPS (ver Figura 3.2 a seguir). Com isso as equipes passavam a desenvolver a-
es de MPS visando certificao (CMMI, MPS.Br, entre outros). Num curto prazo, isto ge-
rava o apoio e comprometimento da equipe de desenvolvimento (que de acordo com os rela-
48
tos, mostrava-se interessada em conhecer e seguir padres normativos de MPS valorizados no
mercado) que por sua vez reforava o apoio e comprometimento da alta administrao, fe-
chando um ciclo de reforo virtuoso (R1, na Figura 3.2). Esta estrutura pode ser vista como o
impulso inicial da maior parte das iniciativas de MPS relatadas.
Aes de MPS
visando certificao
Apoio e
comprometimento
da equipe
Apoio e
comprometimento da
alta administrao
+
+
Tempo da Equipe
dedicado MPS
+
+
R1

Legendas: R1 - Ciclo virtuoso inicial que d origem iniciativa.
Figura 3.2: Arqutipo do Limite ao Sucesso em MPS na pesquisa em Recife parte 1
No longo prazo, este ciclo de reforo virtuoso tende a ganhar sustentao quando
o tempo e recursos em MPS so dedicados adaptao dos processos s necessidades dos
projetos. Isto com o tempo tende a melhorar a maturidade dos processos que passam a efeti-
vamente gerar resultados concretos (ver Figura 3.3 a seguir). Os resultados concretos levam
percepo dos benefcios de MPS que por sua vez reforam e sustentam o apoio da equipe e
da alta administrao, fechando os ciclos de reforo virtuoso R2 e R3 na Figura 3.3.
Aes de MPS
visando certificao
Apoio e
comprometimento
da equipe
Apoio e
comprometimento da
alta administrao
+
+
Tempo da Equipe
dedicado MPS
+
+
Adaptao dos
processos necessidade
dos projetos
+
Resultados
concretos
acuracidade
de prazos
qualidade da especificao
de requisitos
Adequao
aos requisitos
Manutenibilidade
dos produtos
Percepo dos
benefcios de MPS
+
+
+
+
+
+
Maturidade
dos Processos
+
+
+
Obteno de niveis de certificao
oficial (CMMI, MPS.Br,...)
+
R1
R2
R3

Legendas: R1 - Ciclo virtuoso inicial que d origem iniciativa.
R2 e R3 Ciclos virtuosos que do sustentao iniciativa de MPS.
Figura 3.3: Arqutipo do limite ao sucesso em MPS na pesquisa em Recife parte 2
49
Todavia, os efeitos dos ciclos R2 e R3 tendem a demorar a acontecer (para exem-
plificar, conforme citado no Captulo 2, o tempo mdio estimado para uma empresa alcanar
o CMMI-2 de 19 meses). Paralelamente, medida que so empregados tempo e recursos da
equipe dedicados a MPS, tende a haver uma diminuio do tempo e recursos dedicados a
desenvolvimento de software o que afeta diretamente a produo finalstica da organizao ou
equipe de software (ver Figura 3.4). Assim, diante de eventuais dificuldades de sobrevivncia
da empresa (que foram comuns nos relatos de entrevistas da pesquisa), passa a haver uma
maior percepo do custo de MPS (sem a necessria contrapartida de benefcios), o que com
o tempo tende a diminuir o apoio e comprometimento da alta administrao e consequente-
mente a diminuio do tempo e recursos da equipe dedicado a MPS, fechando o ciclo de
balanceamento B1 (lado direito da Figura 3.4). Neste tipo de arqutipo, um ciclo como B1
tende a limitar o crescimento provocado inicialmente pelo ciclo R1 e impedir a concretizao
dos ciclos R2 e R3, comprometendo, assim, o sucesso da iniciativa como um todo.
Aes de MPS
visando certificao
Apoio e
comprometimento
da equipe
Apoio e
comprometimento da
alta administrao
+
+
Tempo da Equipe
dedicado MPS
+
+
Custo de MPS
Adaptao dos
processos necessidade
dos projetos
+
Resultados
concretos
acuracidade
de prazos
qualidade da especificao
de requisitos
Adequao
aos requisitos
Manutenibilidade
dos produtos
Percepo dos
benefcios de MPS
+
+
-
+
+
+
+
Maturidade
dos Processos
+
+
+
Tempo da Equipe
dedicado
Desenvolvimento
-
-
Obteno de niveis de certificao
oficial (CMMI, MPS.Br,...)
+
Dificuldade de
"sobrevivncia" da empresa
+
R1 B1
R2
R3

Legendas: R1 - Ciclo virtuoso inicial que d origem iniciativa.
R2 e R3 - Ciclos virtuosos que do sustentao iniciativa de MPS.
B2 Ciclo de balanceamento que limita R1 e impede R2 e R3.
Figura 3.4: Arqutipo do Limite ao Sucesso em MPS na pesquisa em Recife completo
50
3.3.2.2 Arqutipo 2- Transferncia do Fardo em MPS: Priorizao da Certificao em
Detrimento da Melhoria em Si
Um arqutipo de transferncia do fardo
27
tambm conhecido como transfern-
cia de responsabilidade, consiste principalmente em deslocar o foco das aes corretivas de
um problema para uma soluo sintomtica que parece mais fcil ou atrativa, em vez de
uma soluo mais fundamental que tende a ser mais difcil, demorada ou simplesmente no
identificada (ver Apndice C, Seo C.3, para conhecer a estrutura genrica deste arqutipo).
De acordo com vrios relatos de entrevistas, um problema relevante que foi identi-
ficado subjacente motivao para a iniciativa de MPS aquele que pode ser caracterizado
como necessidade de melhorar a qualificao da empresa no mercado a fim ganhar competi-
tividade e oportunidades de negcio (exportao de software, participao em licitaes). De
acordo com o constatado, muitos gestores enxergam o investimento em MPS como oportuni-
dade de obter esta qualificao atravs da certificao ou avaliao oficial de seus processos,
atravs de padres normativos valorizados no mercado (a exemplo do CMMI, MPS.Br, ou
ISO). Todavia muitos deles parecem no equilibrar este objetivo com o necessrio comprome-
timento para com as aes de melhoria em si, cujo resultado tende a demorar. Desta forma,
conforme a Figura 3.5 a seguir, promovem investimento em certificao com objetivo de ga-
nhar mercado, cuja implementao tende a ser conduzida atravs do estabelecimento de re-
quisitos de processos prioritariamente dirigidos para modelos normativos que leva ao esta-
belecimento de processos de acordo com padres valorizados no mercado. Isto a curto prazo
pode parecer melhorar a qualificao da empresa no mercado, que era o objetivo inicial de-
sejado, fechando o ciclo de balanceamento B1 que neste tipo de arqutipo fica caracterizado
como o ciclo da soluo sintomtica.
Necessidade de
qualificao da empresa
no mercado
Requisitos de Processos
prioritariamente dirigidos
para modelos normativos
Investimento em
certificao com objetivo
de ganhar mercado
Estabelecimento de Processos
de acordo com padres
valorizados no mercado
+
+
+
B1
-

Legenda: B1 Ciclo de balanceamento que caracteriza a soluo sintomtica.
Figura 3.5: Arqutipo da transferncia do fardo em MPS na pesquisa em Recife parte 1.

27
Traduo do original em ingls: shift the burden.
51
Todavia, conforme a Figura 3.6, idealmente, a preocupao com a necessidade de
qualificao da empresa no mercado atravs padres normativos deveria vir acompanhada
do investimento em processos adaptados s necessidades e recursos da empresa que com o
tempo e esforo disciplinado levaria a uma maior maturidade dos processos e, por sua vez, ao
cumprimento de prazos com qualidade nas entregas aos clientes. Isto, por sua vez, diminuiria
a necessidade de qualificao da empresa no mercado (que era o problema original), fe-
chando o ciclo de balanceamento B2 que neste tipo de arqutipo fica caracterizado como ciclo
da soluo fundamental.
Necessidade de
qualificao da empresa
no mercado
Requisitos de Processos
prioritariamente dirigidos para
modelos normativos
Investimento em processos
adaptados s necessidades e
recursos da empresa
Cumprimento de
prazos com qualidade
Investimento em
certificao com objetivo
de ganhar mercado
Estabelecimento de Processos
de acordo com padres
valorizados no mercado
+
+ +
B1
B2
-
-
+
Maturidade dos
processos
+
+

Legendas: B1 Ciclo de balanceamento que caracteriza a soluo sintomtica.
B2 Ciclo de balanceamento da soluo fundamental.
Figura 3.6: Arqutipo da transferncia do fardo em MPS na pesquisa em Recife parte 2.
Porm, a caracterstica deste tipo de arqutipo justamente o fato do ciclo da so-
luo fundamental tender a ser mais demorado (ou sequer ativado) em relao ao ciclo da
soluo sintomtica. Isto ocorre ou porque o ciclo da soluo fundamental mais difcil e
custoso, ou ainda, pelo fato do modelo mental dos atores envolvidos no levar conscincia
de sua necessidade.
Por outro lado, solues sintomticas podem dar origem a efeitos colaterais
(conseqncias no intencionadas), que com o tempo, tendem a tornar o ciclo da soluo fun-
damental ainda mais difcil. No caso em questo, o estabelecimento de requisitos de proces-
sos prioritariamente dirigidos para modelos normativos favorece uma seqncia de efeitos
colaterais (ver lado direito da Figura 3.7) como: a definio de processos pouco adaptados
realidade dos projetos que, que com o tempo, contribui para MPS vista como obstculo ao
52
"trabalho real"/ Burocracia
28
. Isto, por sua vez tende a diminuir o apoio e comprometimen-
to da equipe de desenvolvimento com o programa de MPS, que reduz a participao da
equipe pela equipe de desenvolvimento, que tende a dificultar o investimento em processos
adaptados s necessidades e recursos da empresa . Isto por sua vez, tende a manter um baixo
nvel de maturidade dos processos que influi em um baixo nvel de cumprimento de prazos
com qualidade. Isto por sua vez, finda mantendo o problema inicial da necessidade de quali-
ficao da empresa no mercado que tender a ser tratado reforando o investimento em certi-
ficao com objetivo de ganhar mercado com estabelecimento de requisitos de processos
prioritariamente dirigidos para modelos normativos. Fecha-se assim o ciclo R1, de reforo
vicioso, que contribui para o ressurgimento do problema original, e que pode dificultar o ciclo
B2 da soluo fundamental atravs do desgaste do apoio e comprometimento da equipe.
Necessidade de
qualificao da empresa
no mercado
Requisitos de Processos
prioritariamente dirigidos para
modelos normativos
Processos pouco
adaptados realidade
dos projetos
MPS vista como
burocracia / obstculo ao
"trabalho real"
Apoio e
comprometimento da
equipe
Investimento em processos
adaptados s necessidades e
recursos da empresa
Cumprimento de
prazos com qualidade
Investimento em
certificao com objetivo
de ganhar mercado
Estabelecimento de Processos
de acordo com padres
valorizados no mercado
+
+ +
+
+
Participao da
equipe
-
+
+
B1
B2
-
-
R1
+
Maturidade dos
processos
+
+

Legendas: B1 Ciclo de balanceamento que caracteriza a soluo sintomtica.
B2 Ciclo de balanceamento da soluo fundamental.
R1 Ciclo de efeitos colaterais da soluo sintomtica
Figura 3.7: Arqutipo da transferncia do fardo em MPS na pesquisa em Recife parte III.
Uma outra conseqncia ainda mais drstica para o sucesso do programa de MPS
aquela em que MPS vista como obstculo ao "trabalho real"/ Burocracia leva a uma per-
cepo de baixa relao favorvel de benefcio/custo de MPS (ver Figura 3.8) que, com o
tempo, pode levar desistncia do programa de MPS. Quebra-se assim outra vez a possibili-
dade do ciclo da soluo fundamental, contribuindo para a imagem de baixa qualificao da

28
O termo burocracia aqui empregado conforme o sentido atribudo pelos entrevistados, isto , algo que leva a
excesso de documentos e passos por eles tidos como desnecessrios.
53
empresa no mercado, fechando outro ciclo de reforo vicioso (R2). Pior ainda, a desistncia
do programa de MPS pode gerar a descrena em MPS (ver parte inferior direita da Figura
3.8) que desestimula o surgimento de novas iniciativas de melhorias (ciclo de reforo vicioso
R3).
Necessidade de
qualificao da empresa
no mercado
Requisitos de Processos
prioritariamente dirigidos para
modelos normativos
Processos pouco
adaptados realidade
dos projetos
MPS vista como
burocracia / obstculo ao
"trabalho real"
Apoio e
comprometimento da
equipe
Investimento em processos
adaptados s necessidades e
recursos da empresa
Cumprimento de
prazos com qualidade
Investimento em
certificao com objetivo
de ganhar mercado
Estabelecimento de Processos
de acordo com padres
valorizados no mercado
+
+ +
+
+
Participao da
equipe
-
+
+
B1
B2
R2
-
-
Relao favorvel do
benefcio/custo de MPS
Desistncia do
programa de MPS
-
+
R1
Descrena em MPS
+
+
+
R3
+
Maturidade dos
processos
+
+

Legendas: B1 Ciclo de balanceamento que caracteriza a soluo sintomtica.
B2 Ciclo de balanceamento da soluo fundamental.
R1, R2 e R3 Ciclos de efeitos colaterais da soluo sintomtica.
Figura 3.8: Arqutipo da transferncia do fardo em MPS na pesquisa em Recife completo.
3.3.2.3 Arqutipo 3- Adversrios Acidentais em MPS: Equipe da Qualidade versus E-
quipe de Desenvolvimento de Software
Relatos nas entrevistas da pesquisa do conta de situaes de conflito entre a e-
quipe da rea de qualidade e equipes de desenvolvimento de projetos de software que pare-
cem se enquadrar no arqutipo de adversrios acidentais (ver Anexo C, Seo C.4). Este
tipo de arqutipo ocorre quando atores ou grupos de atores que deveriam ser parceiros, aca-
bam por prejudicarem-se uns aos outros em vez de concorrerem para o sucesso mtuo, quan-
do tendem a adotar aes individualistas.
Na Figura 3.9, a seguir, pode-se observar um ciclo de reforo virtuoso (R1) que
contribui para o sucesso mtuo das equipes de qualidade e de desenvolvimento de software.
Pode-se percorr-lo, por exemplo, iniciando pelas aes com foco em melhoria gerando pro-
cessos adaptados realidade dos projetos que contribui para o sucesso da equipe de desen-
54
volvimento. Isto tende a gerar o apoio e comprometimento da equipe de desenvolvimento
com o programa de MPS contribuindo assim para o sucesso da equipe da qualidade. Isto re-
fora ainda mais as aes com foco em melhoria, fechando o ciclo.
Sucesso da Equipe
de Qualidade
Aes com foco
em melhoria
Sucesso da Equipe
de Desenvimento
Apoio /
comprometimento da
Equipe de Desenv.
+
+
+
R1
Processos adaptados
realidade dos projetos
+
+

Legenda: R1 Ciclo virtuoso do sucesso mtuo entre os parceiros.
Figura 3.9: Arqutipo dos adversrios acidentais em MPS na pesquisa em Recife parte 1.
Todavia, do lado da equipe de desenvolvimento presses mercadolgicas (neces-
sidade de sobrevivncia da empresa) terminam por gerar o estabelecimento de projetos com
prazos inexeqveis (ver Figura 3.10) que frequentemente causam o abandono das normas
de processos. Num primeiro momento, isto tende a reduzir o tempo de entrega dos produtos
reforando o sucesso da equipe de desenvolvimento (ciclo de reforo R3). Todavia o aban-
dono das normas de processos representa a diminuio do apoio e comprometimento da e-
quipe de desenvolvimento e tende a aumentar a quantidade de no-conformidades reduzindo
assim o sucesso do programa de MPS e conseqentemente tambm o sucesso da equipe da
qualidade (configura o ciclo de balanceamento B1).
Do lado da equipe da qualidade, por sua vez, as mesmas presses mercadolgicas
(necessidade de sobrevivncia da empresa) geram presses para a obteno de certificao
(ver Figura 3.11) que podem fazer com que haja priorizao de aes com foco em certifica-
o, em vez da melhoria em si. Isto num primeiro momento pode reforar o sentimento de
sucesso da equipe de qualidade (ciclo de reforo R3). Todavia, tende a aumentar a exigncia/
rigidez dos SQAs podendo fazer com que haja menos processos adaptados realidade dos
projetos contribuindo assim para a reduo do sucesso da equipe de desenvolvimento (confi-
gura o ciclo de balanceamento B2).
55

Sucesso da Equipe
de Qualidade
Aes com foco
em melhoria
Sucesso da Equipe
de Desenvimento
Apoio /
comprometimento da
Equipe de Desenv.
+
+
+
Abandono das
Normas de processos
+
Estabelecimento de
projetos com prazos
inexequveis
+
No-Conformidades
+
-
R1
R2
B1
Processos adaptados
realidade dos projetos
+
+
-
Tempo de Entrega
de produtos
-
-
Presses Mercadolgicas
(necessidade de
sobrevivncia da empresa)
+

Legendas: R1 Ciclo virtuoso do sucesso mtuo entre os parceiros.
R2 Ciclo de reforo da ao individualista da equipe de desenvolvimento.
B2 Ciclos de balanceamento que so efeitos colaterais de R2.
Figura 3.10: Arqutipo dos adversrios acidentais em MPS na pesquisa em Recife parte 2.

Sucesso da Equipe
de Qualidade
Aes com foco
em melhoria
Sucesso da Equipe
de Desenvimento
Apoio /
comprometimento da
Equipe de Desenv.
+
+
+
Exigncia/Rigidez
dos SQAs
Abandono das
Normas de processos
+
Estabelecimento de
projetos com prazos
inexequveis
Presso para
Certificao
+
No-Conformidades
+
-
R1
R3
R2
Aes com foco
prioritrio em
Certificao +
+
+
+
B2
B1
Processos adaptados
realidade dos projetos
+
+
-
-
Tempo de Entrega
de produtos
-
-
Presses Mercadolgicas
(necessidade de
sobrevivncia da empresa)
+
+

Legendas: R1 Ciclo virtuoso do sucesso mtuo entre os parceiros.
R2 Ciclo de reforo da ao individualista da equipe de desenvolvimento.
B1 Ciclos de balanceamento que so efeitos colaterais de R2.
R3 Ciclo de reforo da ao individualista da equipe da qualidade.
B2 - Ciclo de balanceamento que efeito colateral de R3.
56
Figura 3.11: Arqutipo dos adversrios acidentais em MPS na pesquisa em Recife (completo).
Desta forma, aes individualistas dos dois grupos representadas pelos ciclos R2 e
R3 podem concorrer para a reduo do desempenho do conjunto que a conseqncia central
do arqutipo dos adversrios acidentais.
3.4 DIFICULDADES E LIMITAES DA PESQUISA
O objeto central desta pesquisa qualitativa foi o relato dos entrevistados. De uma
maneira geral observou-se bastante disponibilidade dos participantes em abordar as diversas
questes. Todavia, conforme j esperado, com alguma freqncia pde-se observar algum
nvel de receio dos participantes ao abordar temas que consideravam delicados. Apesar dis-
so, em apenas um caso, um participante solicitou a interrupo da gravao em certo trecho da
entrevista.
Sobre os relatos, deve ser ressaltado que apesar deles terem sido obtidos de pesso-
as que se envolveram diretamente com o tema da pesquisa, eles requerem uma srie de cuida-
dos para que sejam utilizados como representao geral da realidade. Eles representam a viso
que os protagonistas tm de seus prprios problemas. Esta viso composta dos pressupostos
individuais e fazem parte do que Argyris e Schon (1974) chamam de teoria proclamada
29
dos
agentes. Desta forma possvel que boa parte dos entrevistados tenda a:
No se perceber como parte dos elementos causais dos problemas que eles
mesmos relatam e, neste sentido, quando se referindo aos problemas, tendem a
transferir responsabilidades para outras pessoas ou grupos;
Minimizar a expresso de percepes negativas sobre a realidade de suas em-
presas, encobrindo aspectos que consideram mais delicados dos problemas.
Esta ltima tendncia fica demonstrada nas entrelinhas de alguns relatos, pelo
cuidado dos participantes em escolher as palavras ao relatarem suas opinies. Para exempli-
ficar considerem-se os seguintes trechos:
... era um pouco meio traumtica. Era um pouco meio traumtica. (Jlio, Gerente
de Desenvolvimento, referindo-se ao seu relacionamento com a rea de qualidade da
empresa, durante a implantao de um programa de MPS. Grifos meus).

29
Este conceito ser abordado no Captulo 4, Seo 4.2.
57
Quando esse processo foi jogado pra gente... Jogado s uma maneira de di-
zer... (Luana, Arquiteta de Software, referindo-se fase inicial de implantao de
um processo de software. Grifos meus).
No primeiro relato acima, o entrevistado enfatiza sua dificuldade de
relacionamento com a rea de qualidade da empresa repetindo a mesma frase duas vezes e
usando o termo traumtica, porm ao mesmo tempo amenizando-o atravs da expresso
um pouco meio.... Na ocasio o entrevistado evitou descrever propriamente o que lhe foi
traumtico. O segundo relato mostra a entrevistada amenizando uma expresso que havia dito
de forma bastante espontnea, parecendo querer minimizar o sentido negativo que ela pode
adquirir. Ambos os relatos sugerem como os entrevistados parecem tender a ser contidos nos
relatos dos problemas exibindo apenas parte de suas reais opinies.
Do ponto de vista de uso da pesquisa como um retrato das iniciativas de MPS
das empresas locais regio pesquisada, o trabalho tem tambm como limitaes principais o
fato de no estar baseado em amostra aleatria e balanceada dos entrevistados e empresas.
Todavia, vale ressaltar que apresentar este retrato no foi necessariamente o objetivo desta
pesquisa e sim buscar elementos que ilustrem os problemas de conduo do processo de in-
terveno que sero abordados nos captulos subsequentes da dissertao.
Em termos de dificuldades, o processo de classificao dos dados mostrou-se bas-
tante complexo por motivos como: contedo muitas vezes ambguo dos relatos, multiplicida-
de de contextos entre os pesquisados, granularidade e superposio dos temas identificados,
subjetividade dos relatos dos pesquisados e finalmente a subjetividade de interpretao do
prprio pesquisador. Entretanto, dificuldades com estas so esperadas em pesquisas com este
tipo de mtodo, causando a necessidade de realizao de vrios ciclos de reclassificao tem-
tica para uniformizao dos critrios de classificao e obteno de classes numericamente
representativas. Idealmente, o processo de classificao temtica em pesquisas qualitativas
deve ser feito por mais de um pesquisador para que haja um acordo intersubjetivo que promo-
va uma maior validao das interpretaes. Isto no foi possvel nesta pesquisa, porm, o re-
sultado prximo a pesquisas semelhantes citadas na Seo 3.2 leva a crer que a classificao
aqui apresentada vlida.
Deve ser ressaltado que o ordenamento dos fatores crticos do Quadro 3.3 pela
freqncia de ocorrncias identificadas representam uma informao relevante sobre o que
pode ser visto como sendo as preocupaes mais comuns dos entrevistados. Todavia, con-
siderando as crenas que fundamentam este trabalho, a ordem de freqncia dos temas no
58
representa necessariamente a ordem de importncia dos fatores crticos encontrados. Alguns
motivos para esta argumentao so:
os relatos esto imbudos das teorias de ao (ver Captulo 4, Seo 4.2) ou
modelos mentais dos entrevistados, que podem conter dilemas e inconsis-
tncias;
os fatores crticos possuem inter-relaes causais que podem constituir pa-
dres de comportamento sistmico entre eles, de forma que alguns fatores po-
dem ser mais causadores do que outros e, portanto mais impactantes siste-
micamente. Portanto, a simples freqncia dos temas no representa esta im-
portante caracterstica.
3.5 COMENTRIOS FINAIS AO CAPTULO
Conforme referido na Seo 2.4 desta dissertao, estima-se que cerca de dois ter-
os das iniciativas de MPS falham em algum nvel na obteno da melhoria de performance
desejada. Experincias pesquisadas no mbito desta dissertao parecem autorizar a afirmao
de que na regio pesquisada (Recife, Brasil) a frao de sucesso pode ser ainda menor.
Para ilustrar este argumento, relevante citar que a maior parcela dos entrevista-
dos nesta pesquisa tomou parte em uma iniciativa de MPS que comeou envolvendo dez em-
presas do Porto Digital em Recife (Dirio de Pernambuco, 21/08/2003) com objetivo cen-
tral de, num prazo de dois anos, obter o nvel 2 do CMM (posteriormente o objetivo voltou-se
para o CMMI). Para tanto, foi estabelecido um projeto com custo parcialmente subsidiado por
um rgo de fomento ao desenvolvimento empresarial, que incluiu a contratao de consulto-
res que acompanhavam de forma coordenada este grupo de empresas. De acordo com infor-
maes levantadas durante a pesquisa, somente trs das dez empresas iniciais mantiveram-se
na iniciativa at o trmino do projeto conjunto. Mesmo entre estas, nenhuma atingiu o objeti-
vo inicial de obteno do CMMI nvel 2, sendo que uma delas obteve sucesso parcial ao obter
a certificao MPS.Br nvel G (que corresponde a parte dos requisitos do CMMI nvel 2).
Conforme levantado em relatos sobre este caso, o maior obstculo dentre os mui-
tos referenciados neste captulo parece ter sido a dificuldade de dar sustentao econmica
iniciativa no molde do arqutipo de limite ao sucesso referenciado na Seo 3.3.3.1 deste
captulo. O aspecto econmico e mercadolgico envolvido neste caso suscita a reflexo sobre
a dificuldade potencialmente maior que empresas tpicas da regio pesquisada podem ter em
59
implantar MPS com base em modelos normativos exigentes como o CMMI, em relao a ou-
tras empresas que estejam inseridas em economias mais desenvolvidas. Uma pesquisa mais
especfica sobre este aspecto envolvendo os riscos econmicos e a relao custo versus bene-
fcio deste tipo de iniciativa seria potencialmente til para a conduo de novos projetos MPS
em Recife, Brasil.
Entretanto, deve ser ressaltado que foram observados, de forma muito significati-
va, outros aspectos de natureza socio-tcnica que tendem a dificultar iniciativas de MPS, a
exemplo daqueles evidenciados no Quadro 3.6. A investigao destes fatores sob a tica de
uma teoria de interveno na organizao o objetivo central desta dissertao e isto ser
feito nos captulos subseqentes.
60
4 TEORIA DE INTERVENO NAS ORGANIZAES
Conforme Santana e Moura (2005), iniciativas de melhoria de processos de soft-
ware (MPS) podem ser vistas luz de uma teoria de interveno na organizao. Faz-se ento
necessrio primeiramente explorar os conceitos bsicos para em seguida explorar sua utilida-
de no campo de MPS. Nesse sentido, Chris Argyris e seu principal colaborador Donald
Schn, so pesquisadores sociais que ao longo de mais de trs dcadas desenvolveram impor-
tantes contribuies para compreenso e tratamento dos fenmenos associados a este tipo de
atividade nas organizaes.
Nas sees seguintes deste captulo so explorados resumidamente alguns concei-
tos associados interveno nas organizaes com base nos trabalhos dos autores menciona-
dos. So abordados, principalmente, os temas relacionados a:
atividades centrais de uma interveno, sobretudo aquelas intervenes que
envolvem gerao de conhecimento e requerem o engajamento de muitos par-
ticipantes;
modelos de interveno;
papel dos intervenientes em sua relao com os clientes;
fatores que costumam limitar o sucesso das intervenes.
Para enriquecer a compreenso de fenmenos relativos a intervenes nas organi-
zaes so tambm apresentados, com base nos mesmos autores, conceitos de teorias de ao
e de aprendizagem organizacional. Esta ltima enfatizada como um dos resultados desej-
vel de uma interveno.
Sempre que possvel, busca-se ilustrar alguns conceitos com exemplos do prprio
campo de MPS e engenharia de software.
4.1 CONCEITOS BSICOS
Com base em Argyris e Schn (1974, Captulo 1, pg. 6) podemos entender interveno na
organizao como toda iniciativa que busca ajudar a organizao a compreender e melhorar
os fatores de sua eficcia, eficincia e competncia. Sobre a ao de intervir Argyris (1970,
Captulo 1, pg 15) afirma que intervir entrar num sistema de relaes em andamento, e
61
estar em meio s pessoas, grupos, ou objetos
30
com o propsito de ajud-los. No mundo das
organizaes, a atividade de interveno pode ento ser facilmente associada s atividades de
consultoria e outras que envolvam melhoria nas organizaes. Aqueles que conduzem a inter-
veno, ditos intervenientes, podem ser associados por sua vez ao papel de consultores (exter-
nos ou internos) que ajudam seus clientes a realizar as melhorias desejadas.
Seguindo estas definies bsicas, intervenes nas organizaes podem possuir
natureza e objetivos bastante diversos. Apenas para ilustrar, alguns exemplos podem ser cita-
dos:
A implantao de um programa de qualidade total;
O desenvolvimento e implantao de um planejamento estratgico;
Um programa de melhoria das relaes inter-pessoais na alta-administrao;
Uma iniciativa de melhoria de processos de software numa empresa de de-
senvolvimento de software, caso que particularmente interessa mais nesta dis-
sertao.
Para melhor aprofundar as questes relacionadas s intervenes nas organiza-
es, convm citar algumas premissas sobre critrios que definem eficcia, eficincia e com-
petncia de um sistema organizacional (a organizao como um todo ou parte dela). Segundo
Argyris (1970, Captulo 2, pg. 36), as atividades bsicas de qualquer sistema so:
Alcanar seus objetivos;
Preservar seu ambiente interno;
Adaptar-se ao ambiente externo relevante e manter o controle sobre ele.
Na viso deste mesmo autor, o grau de adequao em que o sistema alcana estas
atividades bsicas acima, em quaisquer circunstncias, indica a sua eficcia. Complementan-
do este conceito, pode-se entender por eficincia o nvel de esforo (custo) que um sistema
emprega para ser eficaz. O grau de adequao em que um sistema alcana essas atividades
bsicas, ao longo do tempo e sob diferentes circunstncias, indica a sua competncia.
Do ponto de vista do ciclo de vida da organizao, o conceito de competncia po-
de ser visto como o mais abrangente e importante. Estas noes so de extrema relevncia,
pois de acordo com o mesmo autor citado, o objetivo de uma interveno deve ser:
Resolver no s um conjunto especfico de problemas priorizados na interven-
o, mas tambm...

30
Objetos aparece aqui como a traduo direta de objects, que numa interpretao baseada no conjunto da
obra deste autor, poderia ser entendido tambm como intentos dos atores envolvidos.
62
Favorecer o aumento ou, pelo menos, a manuteno do nvel atual de compe-
tncia e eficcia do sistema.
Neste caso, do ponto de vista do interveniente, uma questo chave passa a ser:
como ajudar o sistema-cliente, atravs do sistema de interveno, a aumentar sua eficcia e
sua competncia, nos termos acima definidos?
Para responder a esta questo, Argyris coloca a premissa fundamental segundo a
qual um sistema melhor na medida em que controla o seu prprio comportamento e o seu
prprio destino. Isto significa que o sistema capaz de resolver os seus problemas e executar
as suas decises de uma maneira tal que continua com o controle, ou seja, mantm a sua auto-
nomia. Os critrios para a competncia do sistema esto, portanto, relacionados sua capaci-
dade de resolver problemas, de tomar decises, e de implement-las.
Esta premissa impe uma restrio bsica aos intervenientes: eles no devem con-
ceber nem se comprometer com estratgias de mudanas, que embora possam atingir objeti-
vos especficos da interveno, possam tambm reduzir a capacidade do cliente em tomar
decises e implement-las com vistas a resolver autonomamente seus problemas. Tais estrat-
gias tendem a aumentar a dependncia do cliente em relao aos intervenientes e, portanto
reduzem a probabilidade do sistema-cliente tornar-se auto-regulvel, reduzindo assim a sua
competncia.
Argyris (1970, Captulo 2, pg. 37) prope ento cinco critrios que podem ser
usados para avaliar a eficcia e competncia dos intervenientes, do processo de interveno, e
eventualmente, do prprio sistema-cliente:
i. A informao necessria compreenso dos fatores relevantes (problemas,
oportunidades, ameaas) est disponvel e compreensvel pelas partes re-
levantes. Somente quando a informao compreensvel, alcana as condi-
es iniciais para ser usada eficazmente.
ii. A informao est no somente disponvel e compreensvel, mas tambm
til ao sistema ou manipulvel por ele. No se deve esperar um comporta-
mento eficaz, se as variveis necessrias resoluo de um problema, e
tomada e implementao de uma deciso estiverem alm da habilidade do
sistema para a sua utilizao.
iii. Os custos (em termo de tempo, pessoas, e recursos materiais) de obteno,
compreenso, e uso da informao no esto alm da capacidade do siste-
ma.
63
iv. O problema resolvido e a deciso tomada e implementada de maneira tal,
que o problema no reincida (este critrio relevante somente para os pro-
blemas sob o controle ou influncia do sistema).
v. Os quatros critrios acima indicados so alcanados sem deteriorar, e sim,
preferencialmente, aumentando a eficcia de: resoluo de problemas, de
tomada de decises e implementao destas.
4.2 INTERVENO ENQUANTO UMA TEORIA DE AO
As pesquisas de Chris Argyris tm como base fundamental a ao humana inten-
cional e deliberada. Sob esse ponto de vista pode-se considerar uma interveno como sendo
uma ao deliberada com o objetivo de melhoria da organizao. Para abordar a ao humana
deliberada e intencional o autor utiliza o conceito de teoria de ao. Teorias de ao podem
ser entendidas como teorias
31
(geralmente no explcitas) que guiam a forma como as pessoas
planejam, implementam e revem suas aes (Argyris e Schn,1974, Captulo 1). O esquema
geral de uma teoria de ao mostrado no Quadro 4.1.
Quadro 4.1: Esquema geral de uma Teoria de Ao.
32


Um agente que quer alcanar uma conseqncia (objetivo da ao) C,
numa situao (contexto da ao) S,
de acordo com um conjunto de pressupostos (motivos, crenas operativas) P
1
... P
n
,
realizar a ao (ou um conjunto de aes) A.

O conjunto de pressupostos referidos no Quadro 4.1 inclui no s aqueles acerca

do contexto presente da ao do agente, mas tambm outras crenas mais profundas constru-
das ao longo da histria de vida do agente. A ao em si tambm precedida pela construo
de uma estratgia de ao. Desta forma o esquema pode ser expandido de acordo com a Figu-
ra 4.1.

31
Argyris (2004, Captulo 1, pginas 7 e 8) refere-se tambm a teorias de ao como sendo master designs nor-
mativos que guiam a ao de forma a obter eficcia de seus objetivos.
32
Com base em Argyris e Schn (1974, Captulo 1, pgina 6).
64

Figura 4.1: Esquema geral expandido da Teoria de Ao
33
.

De acordo com o diagrama mostrado na Figura 4.1 a ao humana intencional
baseada em estratgias de ao adotadas sobre o contexto da ao (pressupostos sobre o con-
texto, inteno no contexto e teorias causais). Estas estratgias de ao, por sua vez, so esta-
belecidas sob a influncia de variveis governantes da ao. As variveis governantes podem
ser vistas como macro intenes que esto constantemente presentes na ao e que em nvel
do indivduo obedece a uma hierarquia de fatores como: crenas sobre mundo, valores, moti-
vaes profundas e traos. No que diz respeito organizao estas variveis governantes po-
dem ser vistas como crenas e valores que norteiam a ao coletiva.
No campo da prtica profissional e das intervenes o conceito de teoria de ao
pode ser til para a compreenso de outros conceitos importantes. Argyris e Schn (1974,
Captulo 1, pgina 6) definem uma prtica como sendo uma seqncia de aes realizadas por
uma pessoa (um profissional) para servir outras (os clientes). Nesse sentido a engenharia de
software, por exemplo, pode ser vista sob como uma prtica profissional.
Uma teoria de prtica (Argyris e Schn ,1974, Captulo 1, pgina 6) um conjun-
to de teorias de ao inter-relacionadas, que sob pressupostos relevantes, num dado contexto,
vai permitir conseqncias desejadas de um servio a ser prestado. Para exemplificar, no
campo da engenharia de software podemos considerar o RUP (Rational Unified Process)
(Kruchten, 2003) como uma teoria de prtica.
Uma teoria de interveno (Argyris e Schn ,1974, Captulo 1, pgina 6) pode ser
vista como uma teoria de ao que possui foco em buscar a eficcia de uma teoria de prtica.
Para exemplificar, podemos considerar guias de melhoria de processos de software como o

33
Adaptado com base em Valena (1997, Cap4, pg. 67)
A ao prpriamente dita
traz ...

O contexto da histria do
agente/grupo/organizao
influencia as ...

O contexto da
realidade presente
influencia as ...

Variveis
Governantes
Estratgias
de Ao
Consequncias:
Intencionadas;
No-intencionadas.
Motivaes profundas,
Traos
Valores
Crenas
Pressopostos
sobre o Contexto
Intenes
sobre o Contexto
Teorias
Causais
65
CMMI (CMU/SEI, 2002) e o MPS.Br (Weber e outros, 2005) como sendo teorias de interven-
o (que visam o aperfeioamento de teorias de prtica de engenharia de software) cujos
componentes comportam os mesmos conceitos de variveis governantes, estratgias de ao,
e conseqncias que constituem uma teoria de ao.
A Figura 4.2 ilustra a interseo entre estes conceitos.
Figura 4.2: Interseo dos conceitos de Teoria de Ao, de prtica, e de interveno34.

Argyris e Schn (1974, Captulo 2, pg. 6) destacam duas dimenses da teoria de
ao que as pessoas utilizam em seu cotidiano: a teoria proclamada, aquela atravs da qual o
agente explica (proclama) seu comportamento para os outros e para si mesmo; e a teoria-em-
uso, aquela que agente efetivamente usa em sua ao e que nem sempre congruente com a
teoria proclamada. De acordo com Argyris (2004, Captulo 1, pg. 8) a teoria-em-uso funcio-
na como um programa mestre com o qual lidamos com a realidade. A teoria em uso de-
senvolvida ao longo de toda a histria do agente a partir do conhecimento tcito que ele acu-
mula em sua experincia. Por causa desta natureza tcita, poucas pessoas tm conscincia da
teoria que elas realmente usam.

Figura 4.3: Dimenses da teoria de Ao.
No contexto da organizao o conceito de teoria proclamada, pode ser visto como
a origem de normas e regulamentos explcitos, bem com objetivos proclamados, mas no ne-
Teoria Proclamada
rea de incongruncia
da Teoaria de Ao
(diz, mas no faz)
rea de congruncia
da Teoria de Ao
(faz o que diz)
Teoria em Uso
Dimenso tcita da Teoria de Ao
(faz mais do que capaz de dizer)
Teoria de Ao: domnio da ao humana intencio-
nal (deliberada).

Teoria de Prtica: domnio da ao relativa a uma
prtica profissional. Ex: o RUP (dentro da prtica da
engenharia de software).

Teoria de Interveno: domnio da ao relativa a
uma prtica de melhoria de uma prtica profissional.
Ex: CMMI, MPS.Br (dentro da prtica da engenha-
ria de software)

66
cessariamente realizados. Diversos artefatos importantes da organizao podem ser vistos
como teorias proclamadas: misso, viso, valores proclamados, procedimentos documentados
(incluindo processos de software). A teoria em uso, por sua vez, d origem a normas implci-
tas (tcitas), ao e comportamentos de fato realizados (mas no necessariamente proclama-
dos!).
A conscincia destas diferentes dimenses da teoria de ao importante, pois
significa reconhecer as possveis incongruncias entre discurso versus prtica, ou ainda: em
que medida uma organizao ou equipe est conseguindo seguir de fato as normas que ela
mesma estabeleceu? Como aspecto positivo, esta reflexo pode ser um fator motivador para
atingir o estado desejado. Todavia, infelizmente as organizaes tendem a encobrir estas
incongruncias. As incongruncias so associadas ao insucesso, culpa e receio de punies.
Isto traz graves conseqncias para a capacidade da organizao ou equipe de aprenderem
com seus erros de forma produtiva, conforme ser melhor abordado ainda neste captulo.
4.3 ATIVIDADES PRIMRIAS DE INTERVENO
Embora possam ser vrios a natureza, os motivos e objetivos especficos de uma
interveno Argyris (1970, Captulo 1, pginas 17 a 20) sustenta que devem ser trs as ativi-
dades primrias envolvidas no processo, a fim de atender aos cinco critrios de competncia
do sistema organizacional e dos intervenientes citados na Seo 4.2:
i. Gerar informao vlida
35
e til
36
sobre o objeto da interveno (objetivos,
contexto, andamento da interveno);
ii. Gerar escolha livre
37
e informada
38
sobre os destinos da interveno;
iii. Gerar comprometimento interno
39
com as decises da interveno;
Argyris (2004, Captulo 1, pgina 10) cita, ainda, o que pode ser considerada uma
quarta atividade primria de interveno:

34
Adaptao com base em Valena (1997, Captulo 2, pg 26).
35
Que pode ser testada e validada publicamente.
36
Que tem potencial de ser utilizada na interveno.
37
Os participantes tomam decises relativas interveno de forma livre e sem coero ou manipulao das
escolhas pelo interveniente.

38
As escolhas so feitas pela explorao de opes fundamentadas em informaes vlidas.

39
Interno, no sentido de que o estmulo principal para comprometimento vem de uma motivao interna da pes-
soa, e no por uma presso ou necessidade externa.
67
iv. Monitorar a implementao das decises da interveno referentes (ii) a-
cima para avaliar seu grau de eficia. Esta atividade pode ser considerada
um caso especial de (i) acima.
A relao entre estas tarefas primrias pode ser compreendida como uma seqn-
cia de causalidade cclica de acordo com o diagrama mostrado na Figura 4.4.
Gerao de
Informao
Vlida e til
Gerao de
Escolha Livre e
Informada
Gerao de
Comprometimento
Interno
Monitoramento da
Implementao das
Decises
+
+
+
+
R

Figura 4.4: Ciclo de relaes causais entre as tarefas primrias.
Por este diagrama, observamos que a gerao de informao vlida e til sobre o
objeto da interveno favorece a gerao de escolha livre e informada sobre os destinos da
interveno, que por sua vez tende a gerar nos participantes o comprometimento interno com
as escolhas feitas por eles prprios. O comprometimento interno por sua vez, realimenta o
ciclo de reforo virtuoso, estimulando mais gerao de informao vlida e til. Ao mes-
mo tempo a gerao de escolha livre e informada dever requerer o monitoramento da im-
plementao das decises, que por sua vez ir gerar mais informao vlida e til, contribuin-
do tambm para o ciclo de reforo virtuoso.
Por outro lado, este mesmo diagrama pode tambm explicar o efeito negativo so-
bre o sistema de interveno, que ocorre quando uma (ou mais) das tarefas primrias relega-
da a segundo plano: suponhamos, por exemplo, que a interveno no esteja enfatizando de-
vidamente a gerao de informao vlida e til sobre o processo em curso, ento, isto tende-
r a gerar menos capacidade de escolha livre e informada que por sua vez dificultar o com-
prometimento interno dos participantes. Finalmente, isto far com que eles tenham menos
estmulo gerao de informao vlida e til, fechando assim o que seria um ciclo de refor-
o vicioso que prejudica o sucesso da interveno.
importante observar que estas tarefas primrias, no so um conjunto de aes
especficas bem definidas, que ocorrem como etapas necessariamente seqenciais de uma
68
interveno. Antes, elas so diretrizes (princpios-guia) para a ao dos intervenientes e dos
clientes que podem ocorrer paralelamente entre si e devem ser levadas em conta ao longo do
curso de toda a interveno.
Elas podem inclusive, ser usadas como critrios por parte de um interveniente pa-
ra decidir sobre, se ir ou no, tomar parte numa interveno e ajudar um cliente (Argyris,
1970, Captulo 1, pg 24). Ele poder fazer isso realizando um pr-diagnstico para analisar a
capacidade do cliente de se adequar s tarefas primrias. Da mesma forma, uma organizao-
cliente suficientemente consciente, poderia utilizar este mesmo critrio para selecionar um
interveniente, nesse caso, observando se seu mtodo de trabalho enfatiza estas atividades pri-
mrias.
Desta forma, as atividades primrias so teis tambm como critrios normativos
na relao cliente-interveniente (Argyris, 1970, Captulo 1, pgs. 24 a 27):
i. Seleo de clientes pelos intervenientes dependendo da capacidade dos
clientes de aderir s atividades primrias;
ii. Seleo dos intervenientes pela organizao-cliente dependendo dos m-
todos dos intervenientes estarem congruentes com as atividades primrias;
iii. Minimizao das probabilidades de manipulao indevida dos objetivos da
interveno, tanto por parte do cliente como por parte do Interveniente;
iv. Critrio para os intervenientes deixarem a organizao-cliente retirando-se
da interveno caso os clientes revelem-se incapazes em alto grau de ade-
rir s atividades primrias.
v. Critrio para a organizao-cliente desligar os intervenientes caso estes
revelem-se incongruentes em alto grau para com as atividades primrias.
Considerando a nfase Argyris nestas atividades primrias, faz-se til algum apro-
fundamento em cada uma delas, conforme a seguir.
4.3.1 Gerao de Informao Vlida e til, e Monitoramento da Implementao das
Decises da Interveno
Vale destacar que a atividade primria de gerao de informao vlida e til,
dentre as atividades primrias citadas provavelmente aquela que o interveniente tem mais
influncia e controle atravs de seus mtodos de interveno. Ela tambm pode ser associada
mais concretamente atividade de pesquisa diagnstica sobre a situao em interveno. Uma
pesquisa diagnstica geralmente uma das primeiras etapas de um processo de interveno
69
que ir subsidiar a ao nas demais etapas. Em se tratando de MPS, naturalmente nas etapas
iniciais do programa, aconselhvel a realizao de um diagnstico sobre, por exemplo, a
situao atual dos processos de software utilizados, entre outros fatores.
Todavia, para Argyris, a atividade primria de gerao de informao vlida e til
tambm uma diretriz de ao crucial a ser seguida em toda e qualquer etapa, para alm da
etapa formal de diagnstico, pois ela subsidia com dados o processo de monitoramento da
interveno. Este caso especfico do monitoramento da implementao das decises da in-
terveno.
Como mtodo de realizao desta diretriz, este autor faz vrias consideraes so-
bre sua preferncia pelo que chama de pesquisa orgnica (Argyris, 1970, Captulo 5) de
cunho mais qualitativo, baseada nos princpios da pesquisa-ao, cuja aplicao mais co-
mum entre os pesquisadores das cincias sociais
40
. Na pesquisa orgnica, os passos e catego-
rias de informao so estabelecidos conjuntamente por pesquisadores e clientes participantes
da pesquisa.
Entretanto, para efeito das reflexes mais amplas deste texto, consideram-se vli-
dos outros mtodos que atendam aos objetivos desta diretriz, ou seja: gerar informao sobre
o contexto da interveno, que seja vlida e til para a ao. Um exemplo disto em MPS so
os diversos mtodos de diagnstico e avaliao de processos de software como o SCAMPI,
citado no captulo anterior. Muito embora, vale ressaltar que estes mtodos diagnsticos tradi-
cionalmente usados em MPS, so exemplos do que Argyris (1970, Captulo 4) chama de m-
todos mecnicos, isto , so pr-concebidos em termos de passos a serem seguidos e cate-
gorias de informao a serem pesquisadas. Segundo este autor os mtodos diagnsticos me-
cnicos tendem a reduzir a escolha livre dos participantes da pesquisa quanto aos passos e
categorias de informao que sejam de seu interesse, e desta forma, tendem tambm a reduzir
o comprometimento interno dos participantes com a pesquisa diagnstica.
4.3.2 Escolha Livre e Informada
Sobre a escolha livre e informada, Argyris sustenta que h apenas duas condies
em que ela pode ser sub-enfatizada (juntamente com a gerao de informao vlida e til)
em funo de uma estratgia mais diretiva e unilateral por parte do interveniente, na qual ele

40
Vale, porm ressaltar que metodologias baseadas em pesquisa-ao tm sido empregadas na rea de sistemas
de informao e mesmo melhoria de processos de software (Brjesson, 2006), (Iversen, Mathiassen e Niel-
sen, 2004), (Mathiassen, 2002), (Baskerville, 1999).
70
fornece as informaes e induz mais diretamente as escolhas do cliente (Argyris, 1970 - Cap-
tulo 1, pg 17 a 27):
i) Quando a situao no envolve o sentimento de competncia do cliente (por
exemplo, em questes tcnicas que o cliente tenha pouco, ou nenhum dom-
nio).
ii) Quando o sistema-cliente estiver em extremo perigo e sentir-se incapacitado
para a ao autnoma (mesmo assim, o interveniente deve utilizar a estratgia
diretiva como uma estratgia temporria, reconhecendo que o comprometi-
mento do cliente ser extrnseco).
Vale ressaltar que a situao (i) acima, raramente ser o caso em melhoria de pro-
cessos de software (MPS), tendo em vista que uma equipe de desenvolvimento de software
geralmente possui algum grau de domnio ou capacidade de avaliao crtica, em relao a
mtodos de trabalho em sua rea. Eventualmente, considerando o objetivo de atender a mode-
los normativos de MPS, podero acontecer casos em que os clientes, por falta de experincia
na situao especfica, sintam dificuldade de escolher entre novos modelos de processos de
software ou modelos de qualidade e queiram transferir esta escolha para o interveniente. To-
davia, o interveniente dever ter conscincia que atender a estes anseios uma estratgia ar-
riscada, tendo em vista que o comprometimento do cliente com a escolha tender a ser extrn-
seco. Caso o interveniente venha a ceder, mais tarde os clientes podero vir a transferir a res-
ponsabilidade por eventuais dificuldades para o interveniente. Em vez disso, seria aconselh-
vel o interveniente proporcionar a gerao de mais informao vlida e til para o cliente so-
bre as opes de escolha disponveis. Caso haja possibilidade, uma alternativa interessante
seria, por exemplo, o interveniente conduzir pequenas experincias com o cliente utilizando
as prprias opes de modelos de MPS indicados. Desta forma, o cliente poderia desenvolver
um melhor referencial de escolha em relao s opes, e com a ajuda do interveniente propor
inclusive uma adaptao destas opes sua realidade. Outra alternativa, possivelmente me-
nos demorada nesses casos, seria conduzir estudos de caso referentes a organizaes em con-
dies semelhantes a do cliente.
Em relao situao (ii) anteriormente citada, certamente este seria um caso ain-
da mais raro em MPS, visto que um sistema-cliente que esteja seriamente ameaado (geral-
mente por questes financeiras, ou crises de sucesso de comando) necessitaria de outro tipo
de interveno em primeira instncia.
Pelos argumentos anteriores pode-se ento considerar que a gerao de escolha li-
vre e informada uma diretriz relevante e plenamente aplicvel a intervenes de MPS.
71
4.3.3 Comprometimento Interno
Para melhor situar a questo do comprometimento interno, convm explorar, ain-
da que resumidamente, o conceito de comprometimento de uma forma mais ampla do que a
que o prprio Argyris geralmente refere em sua obra.
Uma definio comumente encontrada para comprometimento a encontrada no
guia do CMM (Olson e outros, 1994): Comprometimento - um pacto que livremente assu-
mido, visvel, e que espera-se que seja mantido por todas as partes..
Entretanto, embora importante, este tipo de pacto explcito apenas um lado do
conceito de comprometimento. Abrahamsson (2000) argumenta que um mal-entendido co-
mum tratar comprometimento como um construto singular. Com base em Salancelick (cita-
do por Abrahamsson, 2000), ele aborda comprometimento de uma forma mais ampla, como
um estado psicolgico de vnculo que define o relacionamento entre uma pessoa e uma enti-
dade. Este relacionamento pode ser visto em termos de vrios componentes conforme a Fi-
gura 4.5.

Figura 4.5: Componentes do Comprometimento
41

A Figura 4.5 ressalta os seguintes elementos:

41
Adaptado de Abrahamsson (2002).
Uma PESSOA uma ENTIDADE (alvo ou foco do interesse)
com
COMPROMETIMENTO
Define o relacionamento entre...
O foco pode ser:

- Pessoa
- Grupo
- Projeto
- Organizao
- Meta
- Um processo!

(Outros Elementos)
Foco (comprometido
com que?).
Profundidade (com
que fora?).
Termos (o que precisa
ser feito?).
Durabilidade (por
quanto tempo?)
(Forma)
Afetivo (eu quero).
Continuidade (eu preciso).
Normativo (eu devo).

72
i. Foco: define o objeto ao qual um indivduo estabelece o vnculo. Pode ser,
por exemplo: a organizao, um projeto especfico, um esforo de MPS ou
a carreira profissional.
ii. Profundidade: define o quanto o indivduo est vinculado ao foco do com-
prometimento. Varia em funo do significado pessoal associado ao foco
do comprometimento.
iii. Termos: define o que o indivduo precisa fazer ou cumprir para com o foco
do comprometimento. um pacto implcito ou explcito (um contrato, por
exemplo).
iv. Durabilidade: diz respeito durao do vnculo do indivduo com o foco do
comprometimento. Pode ser temporrio (um projeto, por exemplo), ou du-
radouro (a carreira profissional, por exemplo).
v. Nvel: pode envolver o vnculo de um indivduo, grupo ou organizao co-
mo um todo, com o objeto do comprometimento.
vi. Forma: em relao natureza do vnculo com o foco, o comprometimento
pode ser:
a. Afetivo: refere-se ao vnculo, envolvimento e identificao intrnseca
com a entidade em foco (o indivduo est vinculado ao foco porque
gosta dele).
b. Normativo: reflete o sentimento de obrigao para com a entidade em
questo. influenciado pelo sistema normativo no qual ele est inseri-
do (o indivduo percebe o foco como uma obrigao normativa).
c. De Continuidade: refere-se conscincia sobre os custos associados a
abandonar a entidade em questo. influenciado pelo sistema de re-
compensa da organizao (o indivduo percebe o foco como uma ne-
cessidade, um meio para sustentao de outros objetivos).
possvel que, em relao a um determinado foco, um mesmo indivduo desen-
volva as trs formas de comprometimento, porm destas, a mais desejvel a afetiva (Abra-
hamsson, 2000), por no depender de fatores extrnsecos relao indivduo-entidade. Numa
dada situao, se a principal forma a normativa, o comprometimento pode ser perdido
medida que haja menos presso normativa sobre o indivduo, ou mesmo excesso de presso
normativa (caso em que a pessoa, por no suportar a presso, prefere romper com o sistema).
Esta forma de comprometimento pode gerar um alto custo psicolgico para o indivduo e o
grupo.
73
Se a principal forma a de continuidade (por exemplo, em funo de premiao
atravs de um sistema de recompensas), o comprometimento pode diminuir se sua base moti-
vacional for modificada.
Pode-se observar que a forma afetiva citada por (Abrahamson, 2000) aproxima-se
do que Argyris denomina como comprometimento interno, e refora que esta a forma mais
desejvel no contexto de uma interveno.
Estes conceitos relatados por Abrahamsson (2000 e 2002) tm uma complementa-
ridade importante para a abordagem de Argyris que mais focada na questo do comprome-
timento interno. Por exemplo: Abrahamsson faz um importante alerta de que pode ser errada a
premissa de que um alto nvel de comprometimento sempre til. De fato, pode-se constatar
que dependendo do foco, o comprometimento pode tornar-se um problema. Tome-se o se-
guinte exemplo na prpria rea de MPS: um engenheiro de software, por ter participado ati-
vamente da definio de um dado processo normativo de software, pode estar altamente com-
prometido com ele. Todavia se este mesmo processo estiver trazendo problemas ao restante
da equipe, possvel que, mesmo assim, este profissional tenda a resistir a modificaes no
processo porque ele comprometido esta definio de processo atual. Desta forma, pode-se
propor a seguinte concluso: os intervenientes e participantes de um esforo de melhoria de-
veriam desenvolver a conscincia de que o foco prioritrio de comprometimento deve ser a
prpria atividade primria de gerao de informao vlida e til, j que ela pode subsidiar a
conscincia crtica e percepo objetiva da necessidade de mudanas no contexto da interven-
o.
Abrahamsson relata que a prtica e a literatura em MPS, raramente tm concorda-
do to consistentemente sobre a importncia de um conceito especfico, como no caso de
comprometimento. Pesquisas do conta de que, considerando um programa de MPS bem pla-
nejado, comprometimento em todos os nveis da organizao, tem sido apontado um dos fato-
res mais importantes para determinar se uma iniciativa deste tipo ir ou no, ser bem sucedi-
da.
4.4 RISCOS DA NO OBSERVNCIA DAS ATIVIDADES PRIMRIAS DE IN-
TERVENO
Conforme alerta Argyris (1970, Captulo 1), na nsia de verem seus problemas re-
solvidos, os clientes tendero a pressionar os intervenientes para que estes tragam solues
74
rpidas e prontas para seus problemas. Os intervenientes podero vir a sucumbir a estas pres-
ses.
A no observncia da prioridade das tarefas primrias faz com que os intervenien-
tes tendam a prestar ajuda a seus clientes de forma diretiva, com base em sua experincia a-
cumulada e sua viso dos problemas, fazendo as escolhas pelos clientes ou induzindo suas
escolhas. Esta estratgia pode trazer graves conseqncias para a interveno pelo desfavore-
cimento do comprometimento interno e autonomia do cliente:
i) Reduo do estmulo dos clientes para implementao das aes previstas pelo
risco da no identificao intrnseca deles com as propostas dos intervenientes.
Em MPS, por exemplo, assumindo-se o intevenientes como sendo os enge-
nheiros de processos, se este profissional estabelece os processos de software
sem a participao dos desenvolvedores de software, possvel que estes ve-
nham a resistir a seguir estes processos
42
.
ii) Diante de eventuais dificuldades na implementao das aes, os clientes po-
dero tender a transferir para os intervenientes a responsabilidade por estas di-
ficuldades e por um possvel fracasso. Considerando-se o exemplo anterior,
em caso de dificuldade, os desenvolvedores de software tendero a transferir a
responsabilidade para os engenheiros de processos
43
.
iii) O sistema-cliente como um todo poder vir a tornar-se dependente do interve-
niente, reduzindo sua capacidade de deciso e resoluo autnoma de proble-
mas. Nesse caso, pelo exposto anteriormente, o sistema-cliente ter sua com-
petncia diminuda. Em longo prazo isto poder vir a ser um ponto de conflito
entre clientes e intervenientes. Caso isto tenha sido uma estratgia deliberada,
porm encoberta pelos intervenientes, este conflito pode vir a ser irrecuper-
vel;
iv) Os intervenientes podem ser vtimas de manipulao pelo cliente (por exem-
plo, para que assumam a responsabilidade pela implementao de medidas
impopulares). Em MPS, por exemplo, a alta-administrao poder querer,
perante as equipes de desenvolvimento, transferir a responsabilidade pela im-
posio de processos de software para os consultores externos e engenheiros
de processos.

42
No Captulo 5 desta dissertao este problema ser evidenciado na prtica.
43
Idem nota anterior.
75
v) O sistema-cliente pode ser vtima da manipulao dos intervenientes para a
adoo de medidas favorveis a estes, mas no necessariamente as mais vanta-
josas para o sistema-cliente. Em MPS, consultores externos e engenheiros de
processos podem induzir a adoo de mtodos e modelos normativos que so
do domnio destes, mas que no so necessariamente as melhores opes para
os problemas dos clientes.
4.5 MODELOS DE INTERVENO
Argyris (1970, Captulo 1, pg. 31) utiliza os critrios de grau de inovao e flexi-
bilidade no processo de interveno para estabelecer trs tipos referenciais de interveno:
i) Aquelas que utilizam modelos j existentes, baseados em um conjunto de co-
nhecimentos e experincias em mtodos para lidar com problemas j conheci-
dos, e comuns a diferentes tipos de cliente. No campo da melhoria de proces-
sos de software, um exemplo disto pode ser a implantao do modelo CMMI
em estgios no qual os macro-objetivos das melhorias j esto pr-definidos
em cada nvel de maturidade proposto no modelo. O MPS.Br outro que pos-
sui esta mesma caracterstica.
ii) Aquelas que utilizam modelos j existentes de uma forma mais flexvel bus-
cando um arranjo criativo do conhecimento existente, eventualmente introdu-
zindo algumas inovaes. No campo de Melhoria de Processos de Software,
um modelo como o CMMI contnuo, ou o SPICE, parece ser mais adequado
a este tipo de abordagem, uma vez que flexibilizam a definio de quais pro-
cessos e em que ordem, devem ser atacados durante a interveno.
iii) No terceiro tipo, que mais raro, os recursos do sistema-cliente e os do inter-
veniente so colocados juntos para conduzir uma interveno que ajude o cli-
ente a compreender a natureza dos seus problemas e contribua para a teoria
bsica da atividade de interveno. O objetivo ajudar o sistema-cliente e si-
multaneamente desenvolver novos modelos conceituais, que ajudem a explicar
tanto aquele caso em particular como outros que possam ser identificados no
futuro. Este modelo se enquadra na classe da metodologia de pesquisa conhe-
cida como pesquisa-ao (Baskerville, 1999). Em MPS, equivaleria concep-
o de um modelo gerado a partir do diagnstico sobre o sistema-cliente em
76
questo, sem recorrer necessariamente a outros modelos. Este ltimo tipo
certamente mais comumente originado no ambiente acadmico.
Argyris argumenta que o primeiro tipo de interveno , provavelmente, o tipo
mais utilizado pelos intervenientes, por isso tem como vantagem envolver mtodos mais tes-
tados e, portanto, um resultado mais previsvel. Ele especialmente til quando h pouco
tempo e recursos para adaptaes. Todavia, h a desvantagem de que este tipo tende a influ-
enciar o interveniente a ver, sem se dar conta, todos os problemas dos clientes em termos do
repertrio de solues pr-concebidas do modelo que utilizado
44
.
O segundo tipo tem como vantagem a possibilidade de uma melhor adaptao a
certas necessidades do cliente e experimentao de alguma inovao til ao modelo. Ele
tende a ser possvel quando o sistema-cliente tem disponveis um tempo e recursos adequa-
dos, um estado de sade j existente que permita a experimentao, e um interveniente capaz
de perceber apropriadamente o potencial do sistema. A principal desvantagem um maior
nvel de risco em relao ao primeiro tipo.
O terceiro tipo tem como vantagens mais evidentes uma possvel melhor adequa-
o s necessidades dos clientes e uma maior possibilidade de gerao de inovaes para o
prprio campo da interveno. As maiores desvantagens so um maior risco e maior nvel de
exigncia sobre a competncia do interveniente na conduo diagnstica e na interveno
como um todo. Argyris alerta ainda que h o risco de reduzir o cliente a ser um sujeito de ex-
perimentao, e de que o interveniente demore na oferta da ajuda (porque ele est tentando
contribuir para o conhecimento bsico). Alguns pesquisadores da rea de sistemas de infor-
mao e tambm de MPS tm demonstrado interesse na aplicao desta modalidade de pes-
quisa em suas reas, tendo em vista seu potencial para resolver problemas e gerar conheci-
mento (Brjesson, 2006), (Iversen, Mathiassen e Nielsen, 2004), (Mathiassen, 2002), (Bas-
kerville, 1999).
4.6 APRENDIZAGEM ORGANIZACIONAL COMO RESULTADO DESEJVEL
DE UMA INTERVENO
A perspectiva de que a atividade eficaz de interveno deve ajudar o cliente a re-
solver no s um conjunto especfico de problemas, mas tambm aumentar a sua competncia

44
Um provrbio popular atribudo ao psiclogo Abraham Maslow e que se aproxima deste argumento diz: "Para
quem s sabe usar martelo, todo problema um prego (Frases Famosas,
www.frasesfamosas.mundoperdido.com.br/autor/967/ ).
77
pressupe que, idealmente, os membros da organizao sejam tambm favorecidos em duas
dimenses:
i) Aprender questes concretas para resolver os problemas relacionados aos ob-
jetivos especficos da interveno e dos problemas nela abordados.
ii) Melhorar sua capacidade de aprender (aprender a aprender). Ou seja: a inter-
veno deve proporcionar aos clientes a possibilidade de refletir no s como
podem executar melhor o seu trabalho, mas tambm sobre o processo de como
eles aprendem, e como poderiam faz-lo melhor. Argyris e Schn, com base
em Bateson, chamam este fenmeno de deutero-aprendizagem (Bateson, cita-
do por Argyris e Schn, 1996, Captulo 1, pg. 38)
Argyris e Schn (1996, Captulo 1, pg. 16) chamam de aprendizagem organiza-
cional o processo pelo qual membros da organizao, buscando aperfeio-la diante de situa-
es problemticas, aprendem em nome dela, e esta aprendizagem passa a se refletir sobre
artefatos, processos organizacionais, e tambm na forma como estes membros agem e com-
preendem a organizao. Segundo estes autores a aprendizagem organizacional ocorre princi-
palmente quando h um descompasso (situao problemtica, inesperada ou surpreendente)
entre os resultados esperados de uma ao (ou conjunto de aes) e os resultados alcanados,
e este descompasso respondido com:
i) um processo de investigao do problema que permite modificar a compreen-
so da organizao e seus fenmenos,
ii) bem como reestruturao das suas atividades em busca dos resultados deseja-
dos e, portanto,
iii) a modificao da(s) teoria(s) em uso na organizao.
Para distinguir aprendizagem organizacional, do caso mais geral que poderamos
chamar meramente de aprendizagem na
45
organizao, convm que o contexto da primeira
tenha as seguintes caractersticas:
i. Os indivduos envolvidos devem estar investigando os problemas em nome da
organizao. Portanto, eles precisam estar legitimados por papis e normas
(no necessariamente formais) da organizao.
ii. A aprendizagem resultante desta investigao deve passar a integrar as ima-
gens mentais que os membros tm da organizao e os artefatos (mapas, me-
mrias e procedimentos) presentes no ambiente organizacional.

45
Aprendizagem que ocorre no local da organizao, porm sem os requisitos aqui referidos.
78
Aprofundando um pouco mais esta compreenso, a capacidade de aprender orga-
nizacionalmente est tambm associada capacidade de reflexo dos agentes sobre as cren-
as, motivaes e valores que fundamentam suas aes na organizao. Esta questo bem
ilustrada por Argyris e Schn (1996, Captulo 1, pg. 20) com os conceitos de aprendizagem
de ciclo nico e de ciclo duplo ilustrados na Figura 4.6 a partir do esquema da teoria de ao
anteriormente citado.
Conforme sugere a Figura 4.6, as pessoas possuem variveis governantes que num
dado contexto da realidade do origem a estratgias de ao, que por sua vez do suporte a
ao propriamente dita. O resultado da ao comparado com as intenes dos agentes esta-
belecidas nas estratgias de ao e que buscam atender s variveis governantes. A aprendi-
zagem de ciclo nico envolve a readaptao apenas das estratgias de ao dos agentes (refle-
te-se sobre os meios). J a aprendizagem de ciclo duplo envolve a readaptao no s das es-
tratgias de ao, mas tambm das chamadas variveis governantes da ao (reflete-se sobre
os propsitos). Estes conceitos servem tanto para ilustrar o fenmeno da aprendizagem em
nvel do indivduo, como tambm para os nveis de grupo, inter-grupo e organizao. Sendo
que nos trs ltimos, referem-se a variveis governantes da ao e estratgias de ao coleti-
vas que so parte da cultura da organizao.

Figura 4.6: Aprendizagem de ciclo nico e ciclo duplo no esquema da teoria de ao
46
.
A aprendizagem de ciclo nico (Argyris e Schn , 1996, Captulo 1, pg. 20)
mais comum e fcil de acontecer uma vez que est baseada na mudana pontual de pressupos-

46
Adaptado com base em Valena (1997, Cap4, pg. 67)
A ao prpriamente dita
traz ...

O contexto da histria do
agente/grupo/organizao
influencia predominante-
mente as ...

O contexto da
realidade presente
influencia predomi-
nantemente as ...

Variveis
Governantes
Estratgias
de Ao
Consequncias:
Intencionadas;
No-intencionadas.
Motivaes profundas,
Traos
Valores
Crenas
Pressopostos
sobre o Contexto
Intenes
sobre o Contexto
Teorias
Causais
Aprendizagem de Ciclo nico
Aprendizagem de Ciclo Duplo
79
tos, intenes e estratgias propriamente ditas sobre um contexto objetivo da ao. Argyris e
Schn ressaltam que este tipo de aprendizagem possui uma natureza frequentemente instru-
mental. No contexto organizacional, este tipo de aprendizagem pode ser facilmente associado
a mudanas procedimentais. Adaptaes e melhorias em processos de software na grande
maioria das vezes diz respeito a este tipo de aprendizagem.
A aprendizagem de ciclo duplo (Argyris e Schn , 1996, Captulo 1, pg. 21)
mais rara tendo em vista que a readaptao das variveis governantes (crenas profundas,
valores e motivos) mais difcil para os agentes. Isto ocorre porque estas variveis aproxi-
mam-se de fatores que compem a prpria identidade dos agentes e lhes fornecem o que Arg-
yris e Schn (1974, Captulo 1, pgs. 15 e 16) chamam de campos de constncia da ao,
com os quais eles lidam com as vrias situaes da realidade. Por exemplo: o comportamento
competitivo dos membros de uma equipe pode ser resultante de uma varivel governante co-
mo, por exemplo, a expressada na crena estou aqui para ganhar. A modificao de vari-
veis governantes potencialmente mais impactante para a competncia dos agentes e das or-
ganizaes.
No contexto da pesquisa realizada para esta dissertao (descrita no Captulo 3)
foi possvel identificar exemplos reais de mudanas mais paradigmticas em alguns casos, que
se aproximam do conceito de aprendizagem de ciclo duplo. Veja-se o caso de um diretor que
realizou em sua empresa um investimento considervel em um programa de MPS amplamente
focado no objetivo de certificao que terminou por ser descontinuado. Quando indagado so-
bre o que faria de diferente se fosse iniciar nova iniciativa semelhante, respondeu que diferen-
temente de sua experincia passada, mudaria completamente o foco do programa para melho-
ria de processos puramente, e s mais tarde pensaria em certificao. Esta mudana parece
denotar que ele est abdicando de alguns valores relativos ao ganho de imagem de sua empre-
sa no mercado (que seria alavancada atravs da certificao) por outros valores mais voltados
para a busca da eficcia interna dos processos em si. Num outro exemplo, um analista de sis-
temas que inicialmente mostrava-se resistente ao programa de MPS posteriormente parece ter
modificado completamente suas crenas. Relatou ele:
Algumas pessoas compram, vestem a camisa e assumem (referindo-se adeso ao
programa de MPS na empresa). Mas a maioria, tem uma certa repulsa. Esse neg-
cio vem para me dar mais trabalho! (risos). Eu mesmo pensei assim no primeiro
momento. ... Hoje eu vejo que aquilo ali realmente a garantia da qualidade
do tipo trabalho que a gente faz, da atividade da gente. Se no fizer... Eu hoje
no enxergo uma empresa sem CMMI. Falando srio. Aquilo realmente, preto no
branco. (Mrio, analista de sistemas. Grifos meus).
80
4.7 LIMITES APRENDIZAGEM E AO SUCESSO DAS INTERVENES
Muitas podem ser as barreiras aprendizagem e gerao de conhecimento na or-
ganizao:
iii. Limites capacidade de processar informao e fazer sentido da experincia
uma barreira natural (March e Simon, 1958, citado por Lyytinen e Robey,
1999);
iv. O prprio excesso de informaes torna difcil aprender algo quando h tanto a
conhecer e tanta informao a processar (Lyytinen e Robey, 1999);
v. Limitaes econmicas e na infra-estrutura organizacional so tambm exem-
plos claros de fatores que prejudicam o sucesso das intervenes nas organiza-
es.
Todavia, Argyris e Schn privilegiam a anlise de fatores que so internos pr-
pria ao humana no contexto das organizaes. Alguns deles so resumidos nas sees se-
guintes.
4.7.1 Baixa Capacidade de Lidar com Situaes Problemticas
A perspectiva defendida por Argyris e Schn de que a aprendizagem ocorre prin-
cipalmente em resposta s situaes problemticas, ressalta que a aprendizagem fortemente
dependente da capacidade de reconhecimento e investigao pelos membros da organizao
dos erros e falhas ocorridos nas situaes em questo. Todavia, aqui reside a maior dificulda-
de deste processo, j que na maioria das organizaes os erros e falhas tendem a ser tratados
como situaes embaraosas e, portanto, tendem a ser minimizados ou completamente enco-
bertos dependendo do grau de ameaa que representam. Desta forma, bloqueada a reflexo e
aprendizagem coletivas. Pior ainda: o encobrimento ou minimizao tambm em si mesmo
uma ameaa e, portanto tambm encoberto, tornando estas situaes, assuntos indiscutveis.
Argyris e Schn (1996, Captulo 8) (Valena, 1987, pg. 267) referem-se s falhas
e conseqncias no intencionadas da ao como sendo erros de primeira ordem. Os erros de
primeira ordem ocorrem em geral por falta de informao vlida suficiente para deciso e
escolha de cursos de ao apropriados. preciso ressaltar que muitas vezes estas informaes
simplesmente no existem e precisam ser geradas por tentativa e erro, por exemplo.
Os mesmos autores chamam as aes de encobrimento dos erros e encobrimento
do encobrimento, de erros de segunda ordem (Argyris e Schn, 1996, Captulo 8) (Valena,
81
1987, pg. 267). Diferentemente dos erros de primeira ordem, os de segunda ordem so fruto
da ao intencional. Eles so gerados quando ao defrontar-se com seus erros de primeira or-
dem que podem causar embarao, os agentes sentem-se ameaados e minimizam ou escon-
dem os erros. Este encobrimento dos erros costuma caracterizar-se na prtica por maquia-
gem ou negao de dados comprometedores, diagnsticos situacionais baseados em informa-
es no verificveis, busca de culpados e transferncia de responsabilidades para terceiros ou
para o sistema. Com base em Argyris e Schn (1996) pode-se explicar esta tendncia pelos
seguintes motivos:
i. As normas (explcitas ou implcitas) do sistema tendem a coagir os agentes
a atingirem os objetivos estabelecidos e a punir (diretamente ou indireta-
mente) os erros e desvios, mesmo os no intencionais;
ii. Os agentes individualmente, em geral, tm como valor bsico obter o m-
ximo de ganhos e o mnimo de perdas
47
. Em virtude de (i) acima, quando
em meio a uma situao de erros eles percebem-se com suas oportunidades
de ganhos ameaadas.
Os erros de segunda ordem fazem com que o sistema de aprendizagem torne-se
auto-oclusivo ao prejudicar diretamente a gerao de informao vlida e til, gerando um
ciclo de reforo vicioso conforme a Figura 4.7.
Figura 4.7: Ciclo de reforo vicioso pelo encadeamento de Erros de 1
a
e 2
a
Ordens.

47
Ver o Modelo I de teoria-em-uso na Seo 3.7.3 deste mesmo Captulo.
Falta de Clareza ou
Insuficincia de Informao
Vlida e til para decises
Incerteza em Decises e
Cursos de Ao adotados
Desvios de planejamento
e falhas no intencionadas
Minimizao ou
encobrimento intencional
dos desvios e falhas
ameaa e presso
sobre os agentes
+
+
+
+
+
Normas de coao ao
atingimento de objetivos
e punio de erros
+
Valores pessoais de
obteno do mximo de
ganhos e mnimo de perdas
+
R
"Encobrimento do
encobrimento"
Normas implcitas de
Indiscutibilidade das situaes
ameaadoras e embaraosas
+
+
+
(Erros de 1 Ordem)
(Erros de 2 Ordem)
(Condies de Erro)
82
De acordo com a Figura 4.7, os erros de primeira ordem tendem a produzir amea-
a para os agentes (em funo de normas de coao para atingimento de objetivos e punio
de erros, e em funo de valores pessoais de maximizao de ganhos). Isto por sua vez, leva
minimizao ou encobrimento dos erros que gera falta de clareza ou insuficincia de infor-
mao vlida e til para decises. Este fator chamado por Argyris e Schn de condio de
erro (Argyris e Schn, 1996, Captulo 5). A falta de clareza ou insuficincia de informao
vlida e til para decises favorece a incerteza em decises e cursos de ao adotados que
por sua vez gera maior probabilidade de novas falhas e desvios de planejamento, fechando o
crculo de reforo vicioso. Complementando e piorando ainda mais esta dinmica, a minimi-
zao ou encobrimento intencional dos desvios e falhas representa em si mesma uma ameaa
para os agentes na medida em que revela uma situao de incongruncia deles. Desta forma
isso d origem ao encobrimento do encobrimento e este por sua vez gera normas implcitas
(tcitas) de indiscutibilidade das situaes ameaadoras e embaraosas. Mais uma vez isto
refora a probabilidade de que haja falta de clareza ou insuficincia de informao vlida e
til para decises.
As conseqncias deste fenmeno alm de extremamente danosas para o sistema
de aprendizagem da organizao o so tambm para o sistema de interveno na medida em
que afetam diretamente as atividades primrias de gerao de informao vlida e til, esco-
lha livre e informada, e comprometimento interno dos agentes. Desta forma, quanto mais este
fenmeno esteja ocorrendo maior a probabilidade de uma interveno vir a fracassar.
4.7.2 Normas e Sistema de Recompensas Incongruentes com a Interveno
De acordo com Argyris (1970, Captulo 2, pg. 47), o sistema pode ser operacio-
nalmente identificado pelas normas, polticas e prticas da organizao. Entre as caractersti-
cas que influenciam de forma impactante a ao dos agentes no sistema esto as normas e as
polticas de recompensa do sistema.
importante ressaltar que por normas da organizao entende-se no s aquelas
formais e explicitas, mas tambm aquelas que so informais e muitas vezes tcitas. Quanto s
polticas de recompensa estas tambm ultrapassam o sistema de recompensa formal como
salrio ou prmios de reconhecimento, e incluem tambm as recompensas tcitas: aquilo que
valorizado pelos gerentes e mesmo os colegas como sendo o bom desempenho. As puni-
es (recompensas negativas) tambm devem ser consideradas como parte das mesmas polti-
cas.
83
Em se tratando de uma interveno que provoca mudanas e que exija dos agentes
a adoo de novos comportamentos fundamental que as normas (formais e informais) e pol-
ticas da organizao recompensem os agentes na direo da mudana. Embora na teoria isso
seja uma necessidade evidente, na prtica as organizaes podem conviver com dilemas que
deixam os agentes em situaes conflituosas que Argyris e Schn (1996) chamam de duplo-
vnculo. Estas so situaes em que os agentes se vem sob a demanda de atender a mais de
uma norma ou objetivo que so inconsistentes e excludentes. Nesses casos o duplo vnculo
aos objetivos excludentes far com que os agentes estejam em situao de erro seja qual rumo
tomarem.
Um exemplo tpico em intervenes de melhoria de processos de software a si-
tuao em que as equipes de desenvolvimento devem seguir as normas estabelecidas pelos
processos, produzindo os diversos artefatos documentais necessrios e ao mesmo tempo se
vem obrigados a cumprir prazos de entrega muitas vezes irrealistas estabelecidos com clien-
tes. Nesses casos a postura dos agentes que detm o poder legitimado na organizao ir de-
terminar a norma tcita a ser seguida. Em muitos casos documentados na literatura de MPS,
inclusive na pesquisa desta dissertao, a norma tcita nessas situaes muitas vezes : es-
quea o processo, preocupe-se em aprontar a entrega do cliente!. Mais adiante na prxima
auditoria de processos os mesmos desenvolvedores podero vir a ser mal pontuados pelas
no-conformidades.
Uma engenheira da qualidade participante da pesquisa desta dissertao (descrita
no Captulo 3) ilustra na prtica o efeito de normas tcitas inconsistentes com os objetivos da
interveno em MPS. Relata ela:
J teve vezes de fazer auditoria e o pessoal dizer: Ah, to engraado, vocs che-
gam aqui, dizem que tudo est errado e vo embora, no ? E a gente quem tem
que fazer. ... J aconteceu milhes de vezes... e eu no acho nem que o pior. O
pior : se o chefe do chefe s cobra prazo e custo, no faz sentido o cara que j es-
t trabalhando at 10 da noite parar para ajeitar um requisito que est desatualizado.
No faz o menor sentido e eu entendo. Eu nunca tive problema pessoal. Eu sempre
me dei bem com todo mundo, e s vezes entendia, conversava: ... se a cobrana
essa, o que voc vai fazer, no ? ... A minha teoria essa: tudo depende do que o
chefe do chefe vai cobrar. (Lorena, Consultora e SQA. Grifos meus).
de se esperar que a organizao conviva com dilemas semelhantes a este princi-
palmente no decorrer de um processo de mudana. Todavia o que ir afetar de forma relevan-
te a eficcia da interveno ser a forma como esses dilemas forem tratados. A incapacidade
de lidar com situaes de erro conforme referido na seo anterior tender a fazer com que
estes dilemas permaneam sem soluo produtiva. A base para tratamento eficaz destas ques-
84
tes est mais uma vez relacionada s atividades primrias de interveno: gerar informao
vlida e til sobre o contexto, promover opes de escolha livre e informada, promover aes
que possibilitem o comprometimento interno dos envolvidos, e finalmente gerar mais uma vez
informao sobre a implementao das decises (monitorar as decises).
Torna-se ento fundamental ressaltar que, para alm dos objetivos imediatos de
uma interveno, a fim de que o sistema possa aumentar sua competncia geral em resolver
problemas, tomar decises e aprender, fundamental que as normas do sistema recompensem
estratgias de ao que sejam baseadas nas atividades primrias de interveno. Todavia a
prtica na maioria das organizao est distante desta diretriz conforme se ver na prxima
seo.
4.7.3 Teoria-em-uso dos Agentes Incongruente com as Atividades Primrias de Inter-
veno
Ao longo de mais de trs dcadas de pesquisas em organizaes, documentadas
em dezenas de publicaes, Argyris, Schn e outros colaboradores perceberam que a maior
parte das organizaes e das pessoas que as integram agem com base em um padro de teoria-
em-uso que traz graves consequncias para a capacidade de aprender organizacionalmente de
forma produtiva. Com base em Argyris e Schn (1974, Captulo 4; 1996, pgs. 92 a 94) se
pode resumir este padro, que chamado de teoria-em-uso de Modelo I, de acordo com o
seguinte:
i) Variveis governantes (premissas e macro-intenes):
Busque o controle unilateral sobre os outros;
Lute para vencer e minimizar a perdas;
Suprima as percepes negativas, seja racional.
ii) Estratgias de ao (para atingir as macro-intenes e atender s premissas):
Advogue sua posio de forma a vencer, o que significa: trate com cla-
reza apenas as informaes que lhe so favorveis, suprima dados desfavo-
rveis, use mensagens ambguas;
Estabelea julgamento/atribuies sobre suas aes e intenes e sobre as
aes e intenes dos outros (porm de uma forma no explcita);
Seja diplomtico, evite teste pblico de dados ameaadores, prefira con-
versas privadas;
85
Implemente as estratgias acima de forma a desencorajar a investigao e
teste destas estratgias.
iii) Algumas conseqncias previstas:
Ganhos unilaterais, competitividade destrutiva, ambiente de alto custo psi-
colgico;
Pouca gerao de informao vlida e, por conseqncia, reduo da esco-
lha livre e informada e do comprometimento interno, o que por sua vez re-
sulta em baixa capacidade de aprendizagem e de mudana produtiva
(sobretudo para aprendizagem de ciclo duplo que implica em mudanas
paradigmticas);
Raciocnios defensivos, normas tcitas de encobrimento de informaes
embaraosas, sistema auto-oclusivo, baixa possibilidade de aprendizagem
de ciclo-duplo (que implica em mudana dos valores)
Na prtica, o padro de teoria-em-uso de Modelo I est na base dos fatores limi-
tantes citados nas sees anteriores que afetam a aprendizagem produtiva e que oferecem ris-
co ao sucesso das intervenes. Quanto mais a natureza da interveno for dependente da ne-
cessidade de gerao de conhecimento e do comprometimento das pessoas maior risco que
este padro de teoria-em-uso oferece interveno.
Como alternativa ao padro de teoria em uso de Modelo I Argyris e Schn (1974,
Captulo 5), sugerem o que eles chamaram de Modelo II. As variveis governantes do modelo
II so justamente o que Argyris (1970) chamou de atividades primrias de interveno. Com
base em Argyris (1974, Captulo 5; 1996, pgs. 117 a 119) se pode resumir a teoria-em-uso
de Modelo II, de acordo com o seguinte:
i) Variveis governantes (premissas e macro-intenes):
Produza informao vlida;
Produza escolha livre e informada;
Gere comprometimento interno, monitore o comprometimento com as de-
cises.
ii) Estratgias de ao (para atingir as macro-intenes e atender s premissas):
Comunique-se, tanto quanto possvel, com base em dados diretamente ob-
servveis (fatos, evidncias);
Na ausncia de dados diretamente observveis, explicite o raciocnio por
traz do julgamento/atribuies que venha a fazer sobre o contexto, sobre si
e os outros;
86
Submeta seus posicionamentos (pressupostos, teses) investigao dos
outros possibilitando que possam desconfirmados se houver evidncias que
justifiquem isto.
Estabelea os objetivos e tarefas de forma conjunta, tanto quanto possvel.
iii) Algumas Conseqncias previstas:
Relaes minimamente defensivas, ambiente de sucesso psicolgico;
Alto grau de liberdade de escolha;
Ambiente propcio reflexo sobre a ao.
Maior possibilidade de aprendizagem de ciclo-duplo.
Argyris (2004, Captulo 1, pg. 9) afirma que a teoria-em-uso de Modelo I en-
contrvel em maior ou menor grau em qualquer tipo de organizao e cultura indistintamente
da idade, sexo, raa ou nvel de educao das pessoas. Embora a mudana do Modelo I para o
Modelo II seja difcil e lenta ele afirma que ela realizvel e pode-se dizer que o conjunto de
sua obra dedicado, em grande parte, a este intento. Ele sustenta que toda interveno, para
alm de seus objetivos mais diretos, deve favorecer a mudana do padro de Modelo I para o
Modelo II, a fim de que torne possvel a melhoria crescente da competncia da organizao.
Infelizmente, na realidade nem sempre isso acontece, sendo que muitas vezes ocorre at
mesmo o inverso, conforme argumenta Martin, Archer e Brill (2002) em Why do People and
Organizations Produce the Opposite of What they Intend?.
Argyris e Schn (1996, Captulo 6, pg 96) reconhecem que o Modelo II idealis-
ta, algo que se pode aspirar, mas raramente alcanar. Todavia ele um referencial de mudan-
a essencial para um comportamento mais competente. um modelo para ajudar as pessoas a
definir metas de aprendizagem gerais, intermedirias e de curto-prazo. Embora na prtica ele
possa ser inalcanvel em um grau puro, a evoluo em sua direo tender a trazer um
resultado impactante na competncia das pessoas e da organizao tanto em situaes espec-
ficas de interveno quanto para a sobrevivncia e evoluo da organizao em longo prazo.
4.7.4 Abordagem Predominantemente Tcnica
O mundo das organizaes permeado pelos papis profissionais que l so exer-
cidos e que so a base para a distribuio de tarefas e organizao do trabalho. Esta organiza-
o do trabalho em termos destes papis profissionais de certa maneira molda no s os servi-
os que a organizao presta a seus clientes (internos e externos), mas tambm a viso que as
pessoas tm do seu trabalho e dos problemas da organizao. Moldando a viso que as pesso-
87
as tm dos problemas da organizao influi tambm na forma como as pessoas aprendem com
estes problemas e como elas buscam intervir na organizao para resolv-los.
Argyris e Schn (1974, Captulo 8) argumentam que historicamente, a partir da
revoluo industrial, pouco a pouco o que chamaram de paradigma da tcnica tornou-se um
modelo de referncia que influenciou as demais profisses. Numa argumentao semelhante,
Morgan (1996, Captulo 2) sustenta que as organizaes, por sua vez, passaram a utilizar a
metfora da mquina em sua estrutura de funcionamento, criando um ambiente caracteriza-
do pela especializao e departamentalizao das funes, padronizao das tarefas e outros
componentes de controle dos aspectos mensurveis do trabalho, com vistas a ter um resultado
tambm padronizado. No paradigma dominante de uma organizao bem administrada,
durante o sculo vinte (e ainda amplamente em vigor), os gerentes tentam dirigir as tarefas
como eles as vem, exercendo o controle unilateral sobre seus subordinados (Argyris e Schn,
1974, cap 8, pgina 152). Fazem isso, tornando o trabalho to simples nos nveis inferiores da
organizao, que qualquer pessoa possa faz-lo e, portanto, qualquer um pode ser controlado;
criam uma estrutura de poder e de informao que d s pessoas dos nveis inferiores pouca
informao e uma perspectiva de curto prazo, enquanto as dos nveis superiores recebem mais
informao, mais poder de controle, e perspectivas de prazo mais longo. Ressalte-se que estas
so caractersticas do Modelo I (que voltado para o controle unilateral) de teoria-em-uso
referidas na seo anterior.
Argyris e Schn (1974, Captulos 9 e 10) argumentam que os papis profissionais
so exercidos com base em:
i. Teorias tcnicas: dizem respeito ao conhecimento do agente sobre procedi-
mentos tcnicos especficos aplicveis nas situaes do exerccio profissional
e suas decises de como us-lo.
ii. Teorias inter-pessoais: dizem respeito s normas que definem a interao do
profissional com outras pessoas (clientes e outros profissionais) de forma que
as teorias tcnicas possam ser aplicadas.
Em todos os papis profissionais estas teorias interpenetram-se em maior ou me-
nor grau nas diversas fases da interao profissional (diagnstico, teste e implementao, por
exemplo). Porm, a nfase no paradigma da racionalidade tcnica tende a maximizar a impor-
tncia das teorias tcnicas e a moldar as teorias inter-pessoais de tal maneira que as relaes
profissionais-clientes sejam controladas de forma ativa pelos profissionais que so os detento-
res da tcnica. Os clientes tendem a exercer um papel passivo.
88
De acordo com Argyris e Schn (1974, Captulo 8, pg. 148), sob a influncia
desta racionalidade tcnica, os profissionais passaram a ser vistos, por eles mesmos e pelos
outros, primariamente como tcnicos que aplicam o seu conhecimento profissional especiali-
zado, que base de sua autoridade. Nesta perspectiva a prpria noo de competncia profis-
sional est associada com problemas instrumentais, que consistem na aplicao de teorias e
tcnicas derivadas da pesquisa sistemtica, preferencialmente cientfica, como soluo aos
problemas apresentados. Como conseqncia desta viso a prpria formao profissional em
muitas reas tende a enfatizar as teorias tcnicas e sub-enfatizar as teorias inter-pessoais (este
certamente o caso da maioria dos cursos superiores ou de extenso em engenharia de soft-
ware).
Ressalte-se ainda que esta viso afeta tambm a maneira como so conduzidas as
intervenes nas organizaes e, antes mesmo, a forma e os objetivos para os quais elas so
contratadas. Isto , sob a influncia do paradigma da racionalidade tcnica, as organizaes
tendero a priorizar a natureza instrumental dos problemas e a buscar ajuda para resolver este
tipo de problema. Os modelos de interveno, por sua vez, tendem a valorizar este mesmo
aspecto. Este certamente o caso dos modelos normativos em MPS como o CMMI, SPICE,
MPS.Br e tantos outros.
Os mesmos autores (Argyris e Schn, 1974, Captulo 9, Pg. 170) argumentam
que o paradigma da racionalidade tcnica perfeitamente aplicvel s situaes familiares nas
quais o profissional pode aplicar as regras e procedimentos derivados de sua bagagem tcnica
do conhecimento profissional. Todavia, em muitas situaes profissionais, os eventos no se
apresentam como problemas bem delineados. Ao contrrio aparecem na forma de estruturas
caticas e indeterminadas, nas quais os critrios para seleo e aplicao das tcnicas conhe-
cidas so falhos, justamente porque eles exigem problemas bem delineados para serem apli-
cveis. Isso tende a ocorrer, sobretudo, nas situaes advindas do mundo comportamental
criado no decorrer das relaes inter-pessoais dos profissionais entre si e entre estes e seus
clientes, em que a problemtica gira em torno de conflito de valores, interesses e atitudes.
Para Schn (2000, Captulo 1, Pg. 21) estas situaes so o que chama de zonas indetermi-
nadas da prtica, onde a incerteza, a singularidade, e os conflitos de valores escapam lente
de anlise da racionalidade tcnica. Isto parece ser precisamente o caso de algumas situaes
problemticas em MPS que sero abordadas nos relatos citados nos Captulos 5 desta disser-
tao.
Schn argumenta que tais zonas indeterminadas da prtica devem ser vistas como
um aspecto central da prtica profissional. Idealmente, a competncia do profissional conside-
89
rada para alm das teorias tcnicas depende de sua habilidade em lidar com estas zonas inde-
terminadas da prtica para as quais no h receitas precisas de como proceder. Para aquele
autor esta habilidade estar baseada na capacidade de realizar reflexo em ao e sobre a a-
o. Esta habilidade favorece de forma fundamental as atividades primrias de interveno.
Os autores ressaltam (Argyris e Schn, 1974) que o problema do paradigma da ra-
cionalidade tcnica no advm do uso das teorias tcnicas em si, mas sim da forma como elas
so usadas sob a influncia direta de teorias-em-uso de Modelo I
48
que so voltadas para o
controle unilateral das tarefas, do ambiente, e pouco propcias gerao de informao vlida
e til. Argyris (2004) ressalta ainda que as estratgias de Modelo I subjacentes racionalidade
tcnica so teis para situaes rotineiras e bem definidas. Todavia, afirma que atividades que
requeiram inovao e gerao de conhecimento a partir das pessoas tero maior chance de
sucesso se apoiadas em estratgias que tenham base em gerao de informao vlida, escolha
livre e informada e comprometimento interno (que so base do Modelo II de teoria-em-uso e
das atividades primrias de interveno).
Gerao de conhecimento a partir da prtica dos profissionais o centro da pro-
blemtica em MPS, conforme argumenta Aaen (2002 e 2003). Portanto, esta uma atividade
que seria muito beneficiada se conduzida com base em mtodos de reflexo em ao (Schn,
2000) e nas atividades primrias de interveno. Entretanto, MPS bem como a rea de enge-
nharia de software em geral amplamente dominada pelo paradigma da racionalidade tcnica,
conforme ser melhor abordado no captulo 5 desta dissertao.
4.8 O PAPEL DOS INTERVENIENTES
Argyris (1970) afirma que intervir entrar num sistema de relaes em
andamento, e estar em meio s pessoas, grupos, ou objetos com o propsito de ajud-los. Ao
longo de toda sua obra ele enfatiza que esta ajuda dos intervenientes deve ser baseada nas
atividades primrias de interveno, que so tambm as variveis governantes do Modelo II
que ele preconiza.
Desta forma, o papel principal de um interveniente ao longo de uma interveno
zelar por estas tarefas primrias, levando em conta, evidentemente, o contexto objetivo da
interveno. Argyris (1970 - Captulo 1, pg 21) argumenta que este aspecto do papel do in-
terveniente de tal forma prioritrio que a prpria gerao de mudana no deve ser conside-
90
rada um objetivo primrio do interveniente, e sim conseqncia das atividades primrias j
citadas e da deciso do cliente para mudar. Ele alega que se o interveniente assume a priori
que os problemas do cliente esto relacionados necessidade de mudanas, ele j estar to-
mando a deciso pelo cliente. Argumenta que, na maioria das vezes, algum nvel de mudana
necessria, mas o papel do interveniente ajudar o cliente a como obter informao vlida e
alternativas que ajudem a deciso e comprometimento do cliente. A deciso de mudar deve
ser assumida pelo cliente como sendo uma responsabilidade inteiramente dele, embora ele
possa estar apoiado na ajuda do interveniente.
Em relao aprendizagem e gerao de conhecimento fruto da interveno, na
viso convencional, o relacionamento entre intervenientes e clientes costuma ser baseado na
seguinte troca: os praticantes fornecem seus problemas; os pesquisadores fornecem seus co-
nhecimentos de especialistas cuja aplicao aos problemas permitem aos praticantes a soluo
deles de uma forma distintamente profissional. Schn, citado por Argyris e Schn (1996, Ca-
ptulo 2, pg. 34) argumenta que o modelo convencional de interao entre experts e pratican-
tes ignora a pesquisa dos praticantes, suas prprias teorias, formas de raciocnio e teste de
idias. Como ento se pode esperar que a capacidade de aprendizagem dos praticantes possa
ser melhorada com a interao com um expert segundo este modelo? Eles argumentam que
quando os pesquisadores ou intervenientes vem a si mesmos principalmente como fontes de
conhecimento baseado em pesquisa, a conseqncia de suas interaes com os praticantes
tender a resultar em dependncia ou rejeio para com os pesquisadores/intervenientes. Os
autores defendem que no contexto da aprendizagem organizacional, ambos praticantes (clien-
tes) e intervenientes ou pesquisadores acadmicos sejam investigadores, preocupados com a
deteco e correo de erros, e com a obteno de sentido de situaes problemticas, confu-
sas e conflitantes.
Durante este processo de interao, considerando o objetivo de ajudar os clientes a
serem mais competentes em tomar decises e resolver problemas, idealmente o interveniente
deve buscar ser para eles um modelo de comportamento competente que se aproxime do Mo-
delo II de teoria-em-uso. Em muitos momentos a interao dos clientes (que tendero a com-
portar-se de acordo com o Modelo I) poder gerar um conflito de valores com o interveniente
(que dever estar mais prximo ao Modelo II). Este choque poder levar a reaes ambiva-
lentes e defensivas dos clientes para com o interveniente (Argyris, 1970, Captulo 6). Todavia
a habilidade do interveniente em gerar informao vlida sobre este mesmo conflito e em

48
Ver a Seo 3.7.3 deste mesmo captulo.
91
comportar-se consistentemente na direo do Modelo II ser a chave da mudana dos clientes
para uma maior capacidade de aprendizagem produtiva sobre seus problemas.
Claro est que, para isso, o interveniente deve possuir habilidades para muito alm
das de natureza tcnica. No contexto de melhoria de processos de software ele ser certamente
mais eficaz se possuir ambas as habilidades tcnicas e as sociais e humanas aqui citadas.
4.9 CONSIDERAES FINAIS AO CAPTULO
De acordo com a argumentao deste captulo, as condies para o sucesso de uma in-
terveno so fortemente influenciadas por fatores humanos e sociais que envolvem o sistema
cliente em si e relacionamento entre os intervenientes e o sistema cliente. As pesquisas de
Argyris, Schn e seus colaboradores oferecem uma contribuio importante para a compreen-
so destes problemas e estabelecimento de diretrizes de conduo eficaz em intervenes de
vrias naturezas.
Vale ressaltar que a evoluo natural da obra destes autores resultou em contribuies
para as cincias sociais aplicadas que esto para alm de teoria de interveno nas organiza-
es. Pode-se constatar que este tema foi um interesse preliminar de Argyris (1970) e nunca
deixou de s-lo ao longo de sua profcua obra. Entretanto, notvel que suas pesquisas abra-
gem tambm a ao humana deliberada de uma forma geral (Argyris e Schn, 1974), at o
ponto de propor uma cincia da ao (Argyris, Putnam e Smith, 1985). Schn (1983 e 2000),
por sua vez, desenvolveu relevantes contribuies para questes de educao profissional e da
reflexo em ao que influenciou inclusive autores da rea de desenvolvimento de sistemas
(ver, por exemplo, Mathiassen, 1998) e melhoria de processos de software (Brjesson, 2006).
A prpria noo de aprendizagem organizacional desenvolvida por Argyris e Schn (1978 e
1996) possui alcance mais abrangente que situaes de interveno pura e simplesmente. En-
tretanto, esta dissertao busca ressaltar o aspecto de teoria de interveno presente na obra
destes autores a fim de ressaltar seu potencial de uso em intervenes de MPS.
Em se tratando de intervenes de MPS, fatores humanos e sociais so em geral abor-
dados de forma superficial pelos modelos normativos que tm sido a base para o desenvolvi-
mento de programas de MPS na indstria de software. A abordagem da teoria de interveno
de Argyris e Schn relacionada a programas de MPS busca ser uma contribuio especfica
desta dissertao. Esta contribuio aprofundada no prximo captulo, onde os fatores crti-
92
cos em MPS so relacionados com elementos da referida teoria, e onde se busca compreender
os fatores sobre-determinantes dos problemas de MPS com base nesta mesma teoria.
93
5 PROBLEMAS DE INICIATIVAS DE MPS LUZ DA TEORIA DE ARGYRIS E
SCHN
Conforme visto no Captulo 3, iniciativas de MPS esto sujeitas a muitas barrei-
ras. Dentre elas, destacam-se aquelas relacionados mudana na organizao em que so re-
queridos fatores como: conscincia das dificuldades e benefcios deste tipo de iniciativa,
comprometimento, conhecimento e habilidades para conduo da mudana nos vrios nveis
organizacionais. Estes fatores ocorrem em uma escala de complexidade que traz risco consi-
dervel de falha para as iniciativas de MPS.
Este captulo mostra como os fatores crticos em MPS podem ser relacionados s
atividades primrias de interveno
49
propostas por Argyris, conforme que se encontram na
Seo 4.3. Um dos objetivos deste captulo ilustrar este relacionamento com base na pesqui-
sa qualitativa documentada no Captulo 3.
Um ponto de partida para reflexo importante a ser considerado que os fatores
crticos em MPS listados na pesquisa foram extrados dos relatos dos prprios profissionais
envolvidos em MPS e, portanto, possvel supor que estes profissionais tenham razovel
conscincia de boa parte daqueles problemas. Pode-se ento questionar: se eles tm conscin-
cia de ao menos parte dos problemas, por que no conseguem lidar com eles eficazmente? A
resposta a esta questo pode ser complexa, sujeita a explicaes de vrias naturezas e nunca
completa. Entretanto, parte importante desta explicao pode ser dada tomando como base o
Captulo 4, particularmente a Seo 4.7 (Limites aprendizagem e ao sucesso das interven-
es). O presente captulo busca fundamentalmente analisar, do ponto de vista da teoria de
Argyris e Schn: por que estes problemas ocorrem?
So utilizados trechos significativos de relatos de entrevistas realizadas na pesqui-
sa desta dissertao para apoiar a interpretao dos problemas. Todos os relatos selecionados
para este captulo dizem respeito a pessoas de diferentes papis que tomaram parte numa
mesma iniciativa de MPS de uma empresa que buscava obter avaliao oficial para o CMMI
nvel 2.
A argumentao do captulo mostra que a teoria de Argyris e Schn possui grande
potencial para compreenso e tratamento dos problemas de intervenes de MPS.

49
Ver Captulo 4, Seo 4.3.
94
5.1 RELACIONANDO OS FATORES CRTICOS EM MPS S ATIVIDADES PRI-
MRIAS DE INTERVENO
Conforme argumentado por Santana e Moura (2005), fatores crticos em MPS po-
dem ser relacionados s atividades primrias de interveno
50
propostas por Argyris (1970).
Os Quadros 5.1(a) e (b) apresentam uma seleo de fatores identificados na pesquisa docu-
mentada no Captulo 3
51
em que isto ocorre de forma mais relevante.
Quadro 5.1(a): Fatores crticos em MPS relacionados s Tarefas Primrias de Interveno.
Fator Crtico em MPS Relao com as Atividades Primrias de Interveno
Apoio e comprometimento da
equipe
Este fator est diretamente relacionado com gerar comprometimento inter-
no.
Apoio/Comprometimento da
Alta Administrao
Idem ao anterior. Este fator depende tambm de: informao vlida e til sobre
os benefcios potenciais da iniciativa de MPS para com os objetivos e estratgias
do negcio.
Envolvimento / Participao da
equipe
A oportunidade de participar um forte gerador de comprometimento das pes-
soas; Escolha livre informada necessria frente s oportunidades de partici-
pao e contribuio;
Conscientizao/ entendimento
dos benefcios e exigncias da
MPS
Este fator depende fundamentalmente de gerao de informao vlida e til
sobre a iniciativa de MPS: objetivos, papel de cada envolvido, benefcios e tam-
bm exigncias do programa de MPS para a empresa e para as pessoas. Este
um fator altamente potente para gerao de comprometimento interno.
Postura da equipe de qualidade
O conhecimento e uso efetivo da teoria de interveno apresentada resumida-
mente no Captulo 4 desta dissertao, especialmente quanto ao papel do inter-
veniente, de grande relevncia para o posicionamento eficaz dos profissionais
de MPS.
Capacidade de promover a gerao de Informao Vlida e til a habilidade
mais bsica de um interveniente. Mtodos de interveno em MPS que propor-
cionem escolha livre e informada e comprometimento interno tendem a pro-
mover uma maior probabilidade de sucesso da interveno. Idem para a capaci-
dade diagnstica no monitoramento da interveno.
Fatores motivacionais para
MPS
As motivaes para MPS podem estar baseadas em intenes nem sempre com-
patveis entre si e cujo conflito pode no estar realmente claro para os agentes: -
por exemplo, eles muitas vezes proclamam o interesse na melhoria dos proces-
sos mas sua teoria-em-uso revela um maior interesse pelo selo da certificao
em si, pelo que isso representa para a imagem da empresa (no nvel organizacio-
nal) e para a imagem pessoal (no nvel do currculo individual dos profissionais).
A atividade de gerao de informao vlida e til exercida de forma produti-
va deve ser capaz de revelar problemas deste tipo e proporcionar o redireciona-
mento (escolha livre e informada) dos rumos do programa.
Processo e infra-estrutura para
compartilhar conhecimento
Est fortemente relacionado gerao de informao vlida e til. Ele tender
acontecer se houver um ambiente colaborativo e tender a ser restrito se houver
um ambiente competitivo e desagregador (ver os modelos I e II referenciados no
Captulo 4, Seo 4.7.3.


50
Ver Captulo 4, Seo 4.3.
51
Ver Quadro 3.3 no Captulo 3.
95
Quadro 5.1(b): Fatores crticos em MPS relacionados s Tarefas Primrias de Interveno.
Fator Crtico em MPS Comentrio relativo s Atividades Primrias de Interveno
Gerenciamento do projeto de
MPS e da mudana
A fase de planejamento do processo de gerenciamento de projetos pode ser dire-
tamente associada s atividades de gerao de informao vlida (sobre o
contexto da interveno) e de escolha informada (sobre os rumos da interven-
o). A fase de execuo fortemente dependente do comprometimento com o
plano. O processo de controle, por sua vez, diretamente relacionado atividade
de monitoramento da implementao das decises da interveno.
Comunicao e feedback sobre
andamento da MPS
Este fator uma estratgia diretamente associada ao monitoramento da imple-
mentao das decises da interveno e a gerao de informao vlida e
til. Ele fundamentalmente dependente de: (a) Nvel de abertura da organiza-
o para o tratamento produtivo de problemas, falhas e desvios, (ver modelos I e
II no Captulo 4, Seo 4.7.3); e (b) Habilidade das pessoas em se comunicarem
com base em dados diretamente observveis (evidncias) e atravs de raciocnios
explcitos (ver Modelo II no Captulo 4, Seo 4.7.3).
Objetivos claros, relevantes e
alinhados
Este fator depende basicamente da gerao de informao vlida e til sobre: -
quais so as intenes e objetivos dos atores-chave em questo? Quo explcitos
e compreendidos esses objetivos esto, em termos dos desdobramentos necess-
rios? Os objetivos possuem algum nvel de incongruncia entre si? Caso sim,
como tratar isso explicitamente e tomar decises a respeito? (requer mais infor-
mao vlida, escolha livre e informada).
Adaptao de processos rea-
lidade dos projetos
Requer a gerao de informao vlida e til sobre em que nvel os processos
atendem aos requisitos da realidade dos projetos em desenvolvimento e a deciso
sobre quais adaptaes (requer escolha livre e informada) a serem feitas.
Delegao de responsabilidade
/ criao de times de ao
Esta tende a ser uma estratgia eficaz para gerao de comprometimento inter-
no dos participantes dos times de ao. tambm certamente muito influenciada
pelo grau de escolha livre e informada dos participantes.
Conflitos Organizacionais
Grande parte dos conflitos organizacionais em MPS ocorrem em funo de obje-
tivos incompatveis, nem sempre tratados de forma clara para as partes. Gerar
informao vlida e til sobre este contexto pode reduzir estes conflitos. Os
conflitos tendem a ser mais difceis de resolver quanto mais os valores da orga-
nizao forem prximos ao Modelo I (ver Captulo 4, Seo 4.7.3), no qual os
conflitos tendem a ser escamoteados e a permanecerem latentes gerando resis-
tncia passiva, baixo comprometimento e alto custo psicolgico. Sero menos
difceis quanto mais os valores da organizao forem prximos ao Modelo II.
Revises / Inspees / Audito-
rias
Revises, inspees e auditorias so estratgias diretas de gerao de informa-
o vlida e til. Elas tendero a ser to mais aceitas e produtivas quanto sua
implementao for voltada para a gerao de aprendizagem e conhecimento e
menos para punies e busca de culpados pelos problemas.
Esquemas de recompensa
Recompensas materiais em geral tendem a gerar comprometimento externo nos
participantes que uma forma menos potente e mais fugaz de comprometimento.
Recomenda-se compreender o sistema de recompensas de forma abrangente
conforme sugerido no Captulo 3, item 3.6.2, de maneira a abranger tambm
aquilo que valorizado (no necessariamente de forma explcita, formal) pela
organizao em termos de aes e resultados. Para desenvolver sua competncia
ao longo do tempo a organizao deve buscar recompensar (valorizar) estrat-
gias alinhada com as atividades primrias de interveno.

Os Quadros 5.1(a) e (b) destacam alguns fatores crticos que tm sua natureza in-
trinsecamente relacionada s atividades primrias de interveno de uma forma mais direta.
Porm, deve ser ressaltado que todos os fatores em MPS identificados na pesquisa podem
sofrer influncia destas atividades. Isto ocorre na medida em que qualquer fator crtico rela-
96
cionado tem mais chance de ser trabalhado eficazmente se houver informao vlida e til a
respeito, alternativas para escolha livre e informada, comprometimento interno para resolv-
lo e monitoramento das aes para resolver o problema.
5.2 APROFUNDANDO A COMPREENSO DOS PROBLEMAS DE MPS
Embora a comparao dos fatores crticos em MPS com as tarefas primrias de in-
terveno feita nos Quadro 5.1(a) e (b) possa ser uma fonte de reflexes relevantes sobre a
conduo de iniciativas de MPS, faz-se necessria o aprofundamento de outros aspectos im-
portantes das teorias de Argyris e Schn vistos no Captulo 4, que no so abordadas nestes
quadros. Com base nelas possvel identificar de forma mais profunda alguns problemas que
permeiam e do origem a vrios fatores crticos em MPS relatados na pesquisa. Em resumo, a
argumentao aqui defendida busca ilustrar que boa parte dos problemas tm origem em:
Normas do sistema organizacional incongruentes com a interveno de MPS;
Baixa capacidade de lidar com situaes problemticas em MPS;
Teoria-em-uso dos agentes incongruente com as atividades primrias de inter-
veno; e
Abordagem da interveno predominantemente tcnica.
As sees seguintes ilustram esta interpretao com o apoio de trechos significati-
vos de relatos de entrevistas realizadas nesta pesquisa que so representativos para os concei-
tos vistos na Seo 4.7 do captulo anterior.
Buscando oferecer uma maior homogeneidade de contexto, todos os relatos sele-
cionados para este captulo dizem respeito ao caso de uma empresa em que pessoas exercendo
diferentes papis, tomaram parte numa mesma iniciativa de MPS. Esta iniciativa dizia respei-
to a uma organizao produtora de software, que na poca possua cerca de 50 colaboradores
e que, tendo obtido certificao ISO 9000, buscava obter avaliao oficial para o CMMI nvel
2. A iniciativa durou cerca de um ano e meio e veio a ser mal sucedida quanto a este objetivo
especfico, tendo o seu programa de qualidade sido descontinuado, posteriormente. A maioria
dos participantes entrevistados alegou que este insucesso ocorreu, principalmente, devido a
dificuldades financeiras da empresa. Todavia, para alm desta dificuldade, pde-se constatar
nos relatos que havia vrios outros problemas srios de natureza scio-tcnica no contexto da
interveno que certamente contriburam significativamente para este insucesso, conforme se
poder observar neste captulo.
97
Deve ser ressaltado que, embora os relatos selecionados neste captulo digam res-
peito a um caso de iniciativa de MPS especfico, vrios elementos ressaltados nesta experin-
cia so tambm encontrveis nos demais relatos de entrevistados de outras empresas pesqui-
sadas.
5.2.1 Normas do Sistema Organizacional Incongruentes com a Interveno de MPS
As iniciativas de MPS geralmente se baseiam na modificao do processo de
software vigente atravs de propostas de melhoria que tomam a forma de um conjunto de de-
finies procedimentais, de estruturas organizativas e de artefatos de processos a serem segui-
dos para construir software. Este entendimento vlido mesmo para os casos em que o pro-
cesso de software ainda no est formalmente definido de forma explcita, pois se pode consi-
derar que ele existe sob a forma de rotinas tcitas dos desenvolvedores, correspondendo pro-
vavelmente ao nvel 1 do CMMI (s vezes chamado de processo catico).
Estas propostas de melhoria uma vez legitimadas na organizao passam a se tor-
nar normas explcitas a serem seguidas pelas equipes de desenvolvimento de software. Porm,
muitas vezes estas melhorias so idealizadas com base em preocupaes que no esto sufici-
entemente presentes na teoria-em-uso
52
dos desenvolvedores, sobretudo de seus lderes (ge-
rentes de projeto e a prpria alta administrao). Desta forma estas propostas de melhoria
muitas vezes entram em choque com as verdadeiras preocupaes vigentes destes atores.
Como estas preocupaes vigentes so a base das normas tcitas do sistema organizacional
que alimentam a teoria-em-uso, as novas normas explcitas oriundas das melhorias tm difi-
culdade de serem assimiladas, internalizadas e acionadas pelos atores.
Estas incongruncias podem ser relacionadas a deficincias na fase inicial do es-
foro de MPS, principalmente em relao aos seguintes fatores crticos em MPS relatados na
pesquisa documentada no Captulo 3:
Conscientizao/entendimento dos benefcios e exigncias da MPS: na medida
em que as pessoas podem no ter a conscincia clara sobre como sua forma
atual de trabalho ser afetada.
Objetivos claros, relevantes e alinhados: na medida em que muitas vezes os
objetivos da MPS no esto claros, nem alinhados, nem as pessoas estabelece-

52
O conceito de teoria-em-uso definido no Captulo 4, seo 4.2.
98
ram de fato seu nvel de relevncia em relao a outros objetivos da organiza-
o.
Fatores motivacionais para MPS: na medida em que o que est motivando a
iniciativa de MPS pode no ser coerente com as exigncias de implementao
da iniciativa. Por exemplo: frequentemente a motivao principal obter certi-
ficao do processo, todavia, este objetivo exige um nvel de esforo e possui
conseqncias que as pessoas podem no ter conscincia quando do incio do
programa.
Do ponto de vista dos entusiastas das propostas de melhoria, mesmo que as nor-
mas explcitas dem suporte s propostas de mudana, as normas tcitas podero fazer com
que as tentativas de aplicao efetiva das melhorias no sejam suficientemente recompensa-
das
53
.
Conforme j exemplificado anteriormente no Captulo 4, o caso mais frequente-
mente constatado na pesquisa desta dissertao a situao em que as equipes de desenvol-
vimento devem seguir as normas estabelecidas explicitamente pelos processos, produzindo os
diversos artefatos documentais necessrios e, ao mesmo tempo, se vem obrigadas a cumprir
prazos de entrega, muitas vezes, irrealistas, estabelecidos com clientes. As normas explcitas
do processo preocupam-se, s vezes, de forma idealizada com a qualidade (reduo de erros,
documentao de especificaes e outros aspectos que influem no funcionamento e manuteni-
bilidade do software). Porm, porque exigem carga de trabalho adicional dos desenvolvedo-
res, frequentemente estas normas ameaam as preocupaes mais agudas dos gerentes de
desenvolvimento: prazo de entrega e custo. Por causa disto, os processos de software podem
passar a ser vistos como algo burocratizante
54
. Estas preocupaes dos gerentes foram for-
temente identificadas na pesquisa qualitativa documentada no Captulo 3 (ver Apndice B,
Seo B.8).
Nesses casos a postura dos agentes que detm o poder legitimado na organizao
(os gerentes) tende a determinar a norma tcita a ser seguida, independentemente das normas
explcitas j aprovadas. Em geral a norma implcita constatada nessas situaes referidas nos
relatos foi algo semelhante a: esquea o processo, cuide em aprontar a entrega do cliente!.

53
Por recompensa nesse caso, entenda-se no somente algum tipo de premiao material, mas sobretudo a valo-
rizao e reconhecimento do mrito da ao.
54
O termo empregado aqui conforme entendimento atribudo pelos entrevistados para burocracia com sendo
algo que gera excesso de artefatos e passos formais desnecessrios.
99
Uma engenheira da qualidade participante da pesquisa desta dissertao ilustra na prtica o
efeito de normas tcitas inconsistentes com os objetivos da interveno em MPS. Relata ela:
J teve vezes de fazer auditoria e o pessoal dizer: Ah, to engraado, vocs che-
gam aqui, dizem que tudo est errado e vo embora, no ? E a gente quem tem
que fazer.... J aconteceu milhes de vezes... e eu no acho nem que o pior. O
pior : se o chefe do chefe s cobra prazo e custo, no faz sentido o cara que j
est trabalhando at 10 da noite parar para ajeitar um requisito que est desa-
tualizado. No faz o menor sentido e eu entendo. Eu nunca tive problema pessoal.
Eu sempre me dei bem com todo mundo, e s vezes entendia, conversava: ... se a
cobrana essa, o que voc vai fazer, no ?... A minha teoria essa: tudo de-
pende do que o chefe do chefe vai cobrar. (Lorena
55
, Consultora e Engenheira da
Qualidade. Grifos meus).
Em outro exemplo, podemos observar uma situao em que normas implcitas da
organizao de certa forma impediram ou no mnimo foram falhas em recompensar a iniciati-
va de um grupo de profissionais que buscava testar e seguir uma rea do processo de software
que havia sido recentemente estabelecido. Relatou um dos entrevistados:
... Com relao a rodar o procedimento, no houve o apoio para que a gente pudesse
rodar. Ento a gente dizia (para o gerente do projeto): olha a gente vai executar o
procedimento de planejamento de projeto. A o nosso gerente dizia: "no d pra e-
xecutar porque isso vai comprometer o tempo do projeto"... Ele no queria compro-
meter essa entrega com uma srie de atividades que podiam prejudicar a entrega.
Ento ele j dizia: infelizmente voc no pode carregar isso a no. E a gente:
Mas eu quero assumir, nem que trabalhe at, por exemplo, seis e meia, sete
horas em determinada atividade. No, eu no quero que vocs faam isso
(disse o gerente). (Lima, Analista de Sistemas, membro de SEPG, Grifos meus).
Sobre a mesma situao um outro membro da equipe relatou:
... a gente assume a responsabilidade, vamos colocar o negcio pra moer em
alguns projetos e o pessoal (referindo-se ao gerente): no, no quero colocar, no
quero arriscar esse projeto que vai iniciar, por conta do tempo, no sei o que.... E a
Diretoria nesse ponto ela podia ter intervido e dito: no, eu quero comprar... a gente
vai colocar os processos aqui nesse projeto pra ver como que faz. E tinha tudo pra
voc colocar, tinham pessoas que participavam do SEPG, que estavam na equipe do
projeto, que facilitaria o feedback n? E ficou a ver navios... Ento isso ficou como
ponto negativo n? (Venncio, Analista e membro de SEPG. Grifos meus)

Os relatos acima ilustram a situao em que os desenvolvedores, por um lado,
sentem que deveriam seguir a norma do processo estabelecido e, por outro lado, so desauto-
rizados a faz-lo. Eles so exemplos de situao em que o agente se v em duplo-vnculo
com objetivos excludentes (ver Captulo 4, Seo 4.7.2). A conseqncia de situaes assim

55
So fictcios todos os nomes de entrevistados apresentados na dissertao.
100
que seja qual a for a escolha do agente ele se ver em situao de erro, pois como estas incon-
gruncias muitas vezes no so tratadas abertamente, ele poder ser cobrado por ambos os
objetivos. No caso acima, na prtica, os desenvolvedores tendem a ser cobrados por cumpri-
mento de prazo de entrega de software (pelos gerentes) e podero tambm vir a serem cobra-
dos para seguir as especificaes do processo de software (pelos auditores da qualidade). Co-
mo conseqncia real do caso acima os entrevistados relataram sua posterior desmotivao,
bem como de outros membros do SEPG para com a iniciativa de MPS.
A incongruncia entre os objetivos da interveno e as normas implcitas do sis-
tema organizacional pode ser vista sob a tica da teoria de Argyris e Schn como uma incon-
gruncia entre a teoria proclamada e a teoria-em-uso:
A teoria proclamada, nesse caso, est representada pelos objetivos da inter-
veno e pelas normas e processos de software explicitamente estabelecidos
(mas ainda no efetivamente usados);
A teoria-em-uso, nesse caso, est representada pelas normas tcitas sanciona-
das pelos decisores.
Na situao abordada no relato anterior, pode-se constatar que os analistas em
questo relataram que se sentiram desautorizados a experimentar o processo estabelecido
mesmo que para isso usassem tempo fora do expediente normal.
Incongruncias como estas podem originar ou reforar dinmicas disfuncionais
como aquela ilustrada no arqutipo dos adversrios acidentais entre equipe de qualidade e
desenvolvedores visto no Captulo 3, na Seo 3.3.3.3. Mais que isto, estas incongruncias
dificultam ou mesmo impedem a implantao das mudanas previstas no esforo de MPS. A
menos que elas sejam tratadas de maneira eficaz com base em gerao de informao vlida
e til, escolha livre e comprometimento interno a tendncia que elas dem origem a rotinas
defensivas (Argyris , 1992, Captulo 3) (Valena, 1997, Captulo 10) no sistema organizacio-
nal que pouco a pouco minem o esforo de melhoria. Entretanto, na maioria das vezes o tra-
tamento de forma aberta destas incongruncias algo improvvel de acontecer em muitas
organizaes conforme se ver na seo seguinte.
5.2.2 Baixa Capacidade de Lidar com Situaes Problemticas em MPS
Em processos de mudana, tendo em vista a incerteza e a multiplicidade de vari-
veis que influem no contexto, a ocorrncia de incongruncias como as citadas na seo anteri-
101
or pode ser um fenmeno esperado, em maior ou menor grau. Argyris e Schn argumentam
que mesmo no nvel do indivduo as variveis governantes de sua teoria-em-uso podem apre-
sentar dilemas (Argyris e Schn, 1974. Captulo 2, pg. 30), isto , o agente muitas vezes po-
de querer atingir objetivos incompatveis. No nvel do grupo e da organizao pode-se esperar
que este fenmeno se repita num grau ainda mais complexo, j que engloba a soma dos
dilemas indivduais.
Porm, embora estas incongruncias sejam barreiras importantes, no nvel da or-
ganizao, o que as torna ainda mais graves o fato dos agentes lidarem com elas embutindo
o que Argyris (1992, Captulo 3) (Valena, 1997, Captulo 10) chama de rotinas defensivas.
Entre outras possibilidades, as rotinas defensivas apresentam-se sob a forma de mensagens
dbias, negao, minimizao ou encobrimento das incongruncias, erros e desvios; e transfe-
rncia de responsabilidade pelos problemas para terceiros ou para o sistema. Estas rotinas
surgem inicialmente no nvel da teoria-em-uso individual dos agentes configurando o que
Argyris e Schn (1996, Captulo 5) chamam de laos inibidores primrios da aprendizagem.
Posteriormente, por fora da influncia destes no sistema, vm a se transformar em normas
tcitas que legitimam as rotinas defensivas no nvel dos grupos e da organizao, configuran-
do o que os mesmos autores chamam de laos inibidores secundrios da aprendizagem. Desta
forma, as rotinas defensivas impedem a gerao de informao vlida e, portanto, o tratamen-
to eficaz dos problemas e, tambm, a aprendizagem produtiva sobre eles.
Em conformidade com a argumentao acima, as situaes de incongruncia entre
objetivos da interveno de MPS e a prtica das equipes de desenvolvimento so tratadas co-
mo situaes embaraosas e do origem a conflitos na organizao. Conflitos organizacio-
nais em MPS foi um dos temas bastante pontuados na pesquisa qualitativa feita nesta disser-
tao referida no Captulo 3, Seo 3.2
56
. Estes conflitos podem ser bastante desgastantes para
as equipes com reflexo na iniciativa de MPS. Veja-se o seguinte relato de um dos entrevista-
dos da mesma organizao do caso abordado na seo anterior:
Houve um conflito em relao a essas duas pessoas (refere-se ao gerente da qualida-
de e um dos gerentes de projeto de software, em virtude da discordncia entre eles
quanto s aes de MPS). Isso foi bastante desgastante, bastante mesmo! Ento
isso um ponto fraco, extremamente fraco. ... Tanto que a gente participou de
momentos, de treinamentos, que houve uma discusso (refere-se a uma situao de
discusso conflituosa) de meia hora entre gerentes! (Lima, Analista de Sistemas,
membro de SEPG, Grifos meus).

56
Para mais detalhes, ver Apndice B, Seo B.19.

102
Por falta de estratgias adequadas para tratamento destes problemas e influncia
de teorias-em-uso voltadas para o controle unilateral (ver Seo 4.7.3), os conflitos, quando
explicitados, tendem a ser tratados de forma disfuncional conforme sugere o relato acima. Por
outro lado, por fora do mesmo padro de teoria-em-uso dos agentes, provvel que na maio-
ria das vezes os conflitos tendam a ser mantidos de forma latente, gerando atribuies mtuas
(que so tambm uma forma de rotina defensiva) sobre a responsabilidade pelos problemas.
Vejam-se os relatos a seguir de atores desta mesma organizao referida no relato anterior:
Gerente de Desenvolvimento, sobre os SQAs
57
: O SQA gosta muito de botar
muita coisa para, desculpe, mas para justificar o trabalho dele e complicar o da
gente! (Jlio, Gerente de Desenvolvimento).
SQA, sobre o Gerente de Desenvolvimento: ... eram os que tinham maior nume-
ro de projetos (referindo-se equipe do gerente), os projetos tinham ciclo de vida
pequenos, ento dava pra gente rodar os processos vrias vezes. E o pessoal era mui-
to bom, em relao aos outros (refere-se s outras equipes) era muito bom, mas o
gerente no apoiava, ele era totalmente contra processo! Ento, no funcionava.
(Bartolomeu, Engenheiro da Qualidade. Grifos meus)
Analista, sobre o Gerente de Desenvolvimento: Como que voc pode ir contra
ao teu Gerente? (refere-se discordncia do coorenador em testar o processo esta-
belecido) Porque na sua rea, assim, que voc trabalha com ele, pode dificultar o re-
lacionamento, pode dificultar o teu emprego. Ento foi um ponto fraco! (Lima, Ana-
lista e membro de SEPG)
Analista, sobre o Diretor e o Gerente da Qualidade: na experincia da empresa
foi muito mal. A experincia foi muito ruim. Por dois motivos: no houve com-
prometimento da alta direo e segundo motivo: a gerncia da qualidade, no
fez um procedimento.... (no estou julgando aqui a pessoa, estou dando minha opi-
nio aqui na parte tcnica) ela no procurou este entrosamento entre as equipes,
est entendendo? (Mrio, Analista e membro de SEPG. Grifos meus)
Diretor, sobre equipes de desenvolvimento e da qualidade: A gente teve pro-
blema de relacionamento da rea de qualidade com determinados projetos, resistn-
cia de determinadas reas a seguir os procedimentos (Manoel, Diretor)
Na tica de Argyris, as situaes conflitivas deveriam ser aproveitadas pelos in-
tervenientes para gerar mais informaes vlidas e relevantes sobre o contexto da interveno.
Neste sentido, possivelmente as estratgias dos condutores do programa de MPS do caso aci-
103
ma no eram suficientemente eficazes para conseguir este objetivo, ou ainda, eles podiam no
ter este tipo de percepo de como tratar o problema. Como indcios de que isto tenha ocorri-
do podemos observar os seguintes relatos de pessoas da mesma organizao:
... eu acho que o pessoal da qualidade, pelo menos l com a experincia que eu tive...
eu acho que eles no to muito preparados para tratar os conflitos quando eles
existem. (Venncio, Analista e membro de SEPG. Grifos meus)
Eu percebi que havia uma postura equivocada, realmente, da rea de qualidade. E
no por incompetncia. Ao contrrio, as pessoas eram super competentes tecnica-
mente e tal, as auditorias eram bem executadas, mas na questo de relacionamen-
to pecavam. (Manoel, Diretor. Grifos meus)
Como conseqncia, tende a haver reaes de resistncia para com as aes de
MPS por alguns e frustrao e desmotivao pelos entusiastas da iniciativa, conforme se pode
verificar nos relatos anteriores. A falta de estratgias adequadas para lidar com os conflitos
somada s posturas unilaterais dos envolvidos geralmente deixa como alternativas:
Escalada de conflitos abertos em que as partes apenas reforam seus pressu-
postos buscando vencer os oponentes. Uma grande possibilidade nesses casos
que haja rompimento do vnculo de parte dos envolvidos com a empresa,
causando readaptaes no sistema. Em geral, isto tem como conseqncia um
alto custo psicolgico para os envolvidos e o reforo do que visto como a
lei do mais forte: manda quem pode obedece quem tem juzo. Outra sria
conseqncia a perda de conhecimento com aqueles que deixam a empresa.
Conflitos latentes em que as partes criam normas implcitas de indiscutibilida-
de dos problemas, que permitem uma convivncia supostamente civilizada,
mas bloqueiam a gerao de informao vlida e til. As conseqncias espe-
radas so: cinismo na organizao, estratgias de manipulao entre as partes,
pouca escolha livre e informada e baixo comprometimento (Argyris e Schn,
1996, Captulo 5) (Valena, 1997, Captulo 10).
Em ambos os casos, como conseqncia esperada das estratgias de controle uni-
lateral dos agentes, o sistema organizacional tende a permanecer fechado aprendizagem,
sobretudo a aprendizagem de novos valores (aprendizagem de ciclo-duplo, ver Captulo 4).

57
O termo SQA (Software Quality Assurance) originalmente identifica a rea de Garantia da Qualidade de
Software. Todavia os profissionais de engenharia de software costumam utilizar este mesmo termo corri-
queiramente para designar os profissionais da qualidade de software em geral.
104
5.2.3 Teoria-em-uso dos Agentes Incongruente com as Atividades Primrias de Inter-
veno
Conforme argumentado no Captulo 4, Seo 4.7.3, a maior parte das pessoas nas
organizaes tende a desenvolver estratgias de controle unilateral em algum grau sobre seus
objetivos, tarefas e ambiente. Elas fazem isso de acordo com as estratgias que lhe parecem
mais adequadas conforme o papel que exercem no contexto. Se o agente possui poder legiti-
mado ele poder tender a impor seus posicionamentos mesmo que o faa de forma diplomti-
ca. Em outros casos, o agente tender a buscar outras alternativas como manipulao das in-
formaes (por exemplo, evidenciando as que lhes so favorveis e minimizando as desfavo-
rveis), ou aliar-se a outros agentes que possuam poder legitimado persuadindo-os.
De acordo com os relatos de entrevistas, pode-se supor que este fenmeno reflete-
se em iniciativas de MPS na ao dos diversos atores em questo, da seguinte forma:
A equipe de qualidade: tem como prioridade definir, implantar e melhorar os
processos de software a serem usados pelas equipes de desenvolvimento, e ga-
rantir que as equipes de desenvolvimento estejam seguindo estes processos.
Os gerentes de projetos: costumam ter como prioridade cumprir prazos e re-
quisitos dos clientes sem extrapolar os custos.
A alta administrao: quer obter certificao de qualidade, mas prioriza a so-
brevivncia da empresa. Eles tendero a desenvolver posies ambguas.
De acordo com o que foi visto na Seo 4.7.3, na maioria das organizaes, a ten-
dncia que os atores acima desenvolvam estratgias unilaterais que garantam e protejam
suas prprias prioridades. Mais que isso eles tendero a faz-lo de maneira a desestimular o
questionamento de suas posies pelos demais
58
.
Para ilustrar a tendncia ao controle unilateral, veja-se, por exemplo, o relato de
entrevista de um profissional de MPS que alegou falta de apoio da alta administrao para
implantao de processos de software, e quando perguntado sobre que tipo de apoio ele espe-
rava relatou:
... ela (refere-se alta administrao) precisa no momento que eu reportar as
minhas dificuldades, ela ir l e chamar o cara e dizer: Olhe, isso aqui, voc vai
ter que fazer dessa forma porque a gente est querendo esse objetivo. E junto comi-
go, ela fazer com que o resto das pessoas da parte operacional entendesse a impor-
tncia daquele negcio! E quando o cara no quisesse participar, simplesmente
dizer: Bicho, ou voc participa ou voc cai fora, cara!. (Bartolomeu, Engenhei-
ro da Qualidade. Grifos meus)

58
Ver a descrio da teoria-em-uso de modelo I, na Seo 3.6.3.
105
Na interpretao de outras partes envolvidas da mesma organizao do relato aci-
ma, o problema era visto de outra forma. A reao esperada dos desenvolvedores pode ser
conforme os depoimentos seguintes:
... a rea de qualidade queria porque queria que a gente trabalhasse do jeito que ela
queria e no do jeito que o cliente exigia. ... Um colega nosso dizia que os proces-
sos, eles foram empurrados de goela abaixo na gente e isso gerava um tremendo
desconforto! (Jlio, Gerente de Desenvolvimento. Grifos meus).
Na empresa existia um conflito. Por qu? Porque a rea de qualidade no partici-
pava junto com a equipe de desenvolvimento. ...Na hora que voc determinou
uma norma, voc primeiro tem que testar uma norma para saber se ela factvel ou
no. Ento no houve isso: os caras (a equipe da qualidade) criaram as normas e no
testaram.... Simplesmente assim, de imposio... Comearam a estabelecer os
processos de cima para baixo. Evidentemente que cumprindo o que os manuais do
CMMI falavam... E de novo houve problema de adaptao, ou seja, voc estabelecer
um processo e depois no conseguir cumprir. (Mrio, Analista de Sistemas. Grifos
meus)
Estratgias de controle unilateral podem ser teis e legtimas, porm elas tm co-
mo efeito colateral a reduo da escolha livre e do comprometimento interno dos agentes.
Por sua vez, conforme ilustrado no Captulo 4, Figura 4.4, o baixo comprometimento interno
desestimula a gerao de informao vlida e, por sua vez, reduz o feedback pelos desenvol-
vedores sobre o andamento do programa de MPS, reforando o ciclo e limitando sua evolu-
o. Alm disso, as estratgias de controle unilateral frequentemente geram, em resposta, ou-
tras reaes tambm baseadas estratgias de controle unilateral pelas partes afetadas. A resis-
tncia passiva (corpo-mole, ateno seletiva, distanciamento psicolgico, entre outras), por
exemplo, uma estratgia de controle unilateral disfarada que frequentemente acionada
quando os agentes no se vem em condio de questionar abertamente as decises das quais
discordam. Este tipo de reao alimenta ainda a mais a necessidade de controle unilateral ati-
vo por parte dos gerentes, gerando ainda mais resistncia, fechando assim mais um ciclo de
reforo vicioso.
Os prprios modelos normativos de MPS, podem tambm favorecer em algum
grau a adoo de estratgias unilaterais por parte dos profissionais de MPS. Isto tender a
ocorrer quanto mais rgidos forem os modelos em prescrever unilateralmente as estruturas
organizativas dos processos de software, dos artefatos necessrios e dos passos de sua implan-
tao. Os modelos favorecem as estratgias unilaterais dos profissionais de MPS na medida
em que estes, diante das dificuldades junto aos desenvolvedores, podem alegar necessidade de
atender s exigncias do modelo.
106
Argyris (1970) afirma justamente que os intervenientes, quando em conflito com
seus clientes, tendem a adotar dois tipos de estratgias, ambas prejudiciais interveno por
no favorecerem as atividades primrias de interveno:
i. Recorrer aos aspectos formais da interveno, distanciando-se psicologica-
mente dos problemas dos clientes e da ajuda genuna a eles. Em MPS isso o-
correr com o apego dos engenheiros da qualidade aos aspectos formais dos
modelos normativos de MPS.
ii. Super identificar-se com os problemas dos clientes assumindo os seus valores
e abandonando os objetivos da interveno e as atividades primrias de inter-
veno.
O caso (i) acima (apego aos aspectos formais da interveno pelos intervenientes)
parece ter ocorrido nas situaes relatadas a seguir:
Comecei a adaptar o template (refere-se a um modelo de documento previsto no
processo de software), mas a rea de qualidade no aceitava! Tinha que ser daquele
jeito deles! O SQA parecia uma mquina! Eu tinha um objetivo (melhoria do pro-
cesso) e ele tinha outro (certificao). Ele dizia: voc no consegue o selo se no
fizer todos os processos de nvel 2, conforme previsto!. Eu podia at fazer uma
CR (Change Request) do processo, mas enquanto a mudana no era implantada ti-
nha que funcionar como previsto! Assim, todos os itens eram sempre no confor-
mes! (Diane, Gerente de Projeto. Grifos meus).
Algumas pessoas da rea de qualidade, s vezes tornam o processo uma coisa muito
chata de se fazer. Por exemplo: a gente tem um cdigo de 500 linhas, 600, e tem
uma virgulazinha l que est errada. Um ponto e vrgula que foi colocada no cabe-
alho. Voc precisa fazer uma inspeo para isso?! Convidar uma pessoa para
vir fazer um negcio formal, de botar no histrico que aquilo foi alterado?! Isso
to mnimo! No vai fazer diferena! Mas tem gente na rea de qualidade que
diz: Ah, porque no processo diz que qualquer mudana, por menor que seja,
vai afetar.... Vai ter que demandar esse tempo! (Luana
59
, Arquiteta de Software,
Membro de SEPG. Grifos meus).
O caso (ii) referido anteriormente (super-identificao com os problemas dos cli-
entes) pode ter ocorrido no primeiro relato j citado na Seo 5.2.1, pgina 105, deste mesmo
captulo, quando a entrevistada, diante do problema argumentado pelos desenvolvedores, con-
temporiza a questo e aparentemente abandona seu objetivo enquanto auditora da qualidade,
dizendo: ... se a cobrana essa, o que voc vai fazer, no ?.

59
Este relato, como exceo aos demais apresentados no captulo, no pertence ao conjunto de atores da organi-
zao referida na Seo 5.2.

107
Devido rigidez e apego de alguns profissionais de MPS aos aspectos formais dos
processos, e o impacto que isto pode causar no trabalho das equipes de desenvolvimento, mais
de um entrevistado chegou a rotular estes profissionais como sendo carrascos conforme o
exemplo a seguir:
... Era uma falha do pessoal de qualidade... As pessoas eram vistas, na minha vi-
so, quando a gente ia ter uma auditoria, como carrascos! No se tinha uma vi-
so de ajuda, mas a gente tinha uma viso de prejuzo, de preocupao. A gente
no tinha uma viso: No, ele vem para c para ajudar". A viso era: "Ele vem pa-
ra c para prejudicar. (Jlio, Gerente de Desenvolvimento. Grifos meus).
O relato acima mostra o nvel de antagonismo a que pode chegar a relao entre
desenvolvedores de software e profissionais de MPS. D tambm uma idia de o quo distan-
te a imagem de alguns destes profissionais de MPS pode estar da viso preconizada por Argy-
ris de que o interveniente deve ser um profissional de ajuda conforme visto na Seo 4.8.
Este tipo de antagonismo (no necessariamente no nvel mostrado no relato anterior) apareceu
com freqncia significativa nas entrevistas (ver o fator postura dos profissionais da qualida-
de no Quadro 3.3 e no Apndice B, Seo B.6). Todavia no necessariamente o caso geral,
conforme sugerem os seguintes relatos:
Voc (enquanto engenheiro da qualidade) deve ter jogo de cintura. Se chegar l
pra falar com o pessoal e a o cara diz: No, eu estou sem tempo agora... estou aqui
no sufoco e tal... (refere-se ao cumprimento de metas estabelecidas por aes da
Qualidade). Ah, ? T beleza. Vamos fazer um acordo? No faz at esse dia no,
mas faz pra dois dias depois. Pra pessoa ver que voc tem interesse em ajudar, o
seu interesse no ficar lascando a pessoa ali, dizer que ela vai ter que fazer
aquele negcio e vai ter que virar a noite aqui fazendo tudinho. (Daniel, En-
genheiro da Qualidade. Grifos meus)
60

O SQA tem um papel de educador, no ? Eu acho. Ele no chega l, faz auditoria
e vai embora. Ele vai ajudar as pessoas a resolverem os problemas, a arranjar
uma soluo mais vivel. ... No somente cobrar por cobrar. Voc tem que ter
um entendimento do contexto tambm e ver a melhor forma que d para corrigir na-
quele ambiente. Ter esse senso crtico, porque fcil numa equipe que est bem, su-
per organizada e pedir inspeo de 100% de cdigo. Numa equipe que est atrasada
voc pedir inspeo de 100%, talvez no seja. (Lorena
61
, Consultora e Engenheira da
Qualidade)

60
Este relato, como exceo aos demais apresentados no captulo, no pertence ao conjunto de atores da organi-
zao referida na Seo 5.2.
61
Lorena (nome fictcio) atuou na organizao referida na Seo 5.2 como consultora externa e no no quadro
normal de funcionrios da empresa.
108
O apego pelos intervenientes aos aspectos formais dos modelos normativos de
MPS traz tambm outra nuance mostrada na pesquisa, que muitas vezes sugere o interesse
prioritrio na certificao dos processos em detrimento da ajuda genuna aos desenvolvedo-
res. Este um aspecto grave porque muitas vezes demonstra uma incongruncia entre teoria
proclamada (de melhorar os processos) e a teoria-em-uso (que se apega prioritariamente aos
requisitos formais de certificao) que pode desmoralizar a interveno perante parte dos
interessados (no caso, os desenvolvedores). Em um outro depoimento relevante, um analista
de sistemas recm-contratado na empresa relatou:
Quando eu cheguei aqui, eles estavam muito perto de tirar certificado ISO. E a o
que aconteceu? O pessoal ficou meio assustado, porque eu estava chegando agora e
o auditor podia justamente me pegar naquela hora e eu danar. Eu no tinha prepa-
rao nenhuma. Ento, eles disseram: Olha, o seguinte, tu ficas em casa nesses
dias de auditoria. Deixa o pessoal vir (os auditores da certificao) e depois tu
vens. E foi justamente o que aconteceu. Eu fiquei fora. Me deram a viso bem ge-
ral. Pe geral nisso! Os auditores vieram e tal. Eles ganharam o certificado, a de-
pois eu voltei. A como j tinham renovado (a certificao), houve uma certa, diga-
mos... Ah, renovou, ento vamos.... No passaram (os processos) logo para
mim. Ento, assim, passaram para mim: olha, tem aqui, d uma lida aqui...
Aquela coisa... (refere-se ao fato de que o grupo da qualidade uma vez que conse-
guiu o certificado, no se preocupou mais em trein-lo nos processos estabeleci-
dos). (Gilmar, Analista de Sistemas. Grifos meus)
A incongruncia das teorias proclamadas dos agentes com suas teorias-em-uso e
com as tarefas primrias de interveno certamente um aspecto de grande influncia negati-
va nos fatores crticos relatados relatados por (Santana, 2007) relacionados ao comprometi-
mento dos grupos (alta gerncia, desenvolvedores e a prpria equipe de qualidade) com a ini-
ciativa de MPS. Este entendimento fundamental por dois motivos bsicos citados por Abra-
hamsson (2000 e 2002):
i. Comprometimento tem sido sempre visto como um dos fatores crticos mais
relatados para MPS;
ii. Comprometimento (sobretudo o comprometimento interno dos agentes)
algo que no diretamente controlvel, mas apenas influencivel.
Sobre este aspecto a teoria-em-uso dos participantes na interveno certamente
uma das grandes influncias para o comprometimento do grupo. Ela tender a favorecer este
comprometimento quanto mais baseada estiver nas tarefas primrias de interveno.
109
5.2.4 Abordagem Predominantemente Tcnica
Apesar da maioria dos fatores crticos em MPS constatados na pesquisa desta dis-
sertao e em outros trabalhos (ver Captulo 4) serem de natureza no-tcnica, verifica-se que
a prtica profissional em MPS e em engenharia de software em geral amplamente dominada
pelo paradigma tcnico. Tende assim, a minimizar outros aspectos humanos e sociais funda-
mentais ao desempenho eficaz da interveno. Esta lacuna pode ser a fonte de muitos mal-
entendidos em intervenes de MPS. Tomando por base o que foi argumentado na Seo
4.7.4 desta dissertao que alertou sobre os problemas do paradigma da racionalidade tcnica
para as intervenes, pode-se constatar a influncia predominante deste paradigma em MPS
em dois aspectos bsicos que so abordados nas sees seguintes e que esto intimamente
relacionados entre si:
A abordagem predominantemente tcnica na conduo das intervenes de
MPS;
Abordagem predominantemente tcnica na educao profissional de engenhei-
ros da qualidade e profissionais de engenharia de software em geral.
5.2.4.1 Abordagem Predominantemente Tcnica na Conduo das Intervenes de
MPS
Pde-se constatar nas entrevistas realizadas, que o foco das intervenes em MPS
costuma basear-se na preocupao instrumental com a definio e implantao de processos
de software com base em requisitos de modelos normativos como o CMMI e MPS.Br. O ape-
go aos aspectos formais destes modelos normativos e dos processos de software estabelecidos,
conforme comentado na seo anterior, um forte indicador disto.
Embora em muitos casos as atividades desenvolvidas comportem em algum grau
as atividades primrias de interveno (gerao de informao vlida, escolha livre e infor-
mada, comprometimento interno e monitoramento da interveno), constatou-se que raramen-
te as intervenes privilegiaram atividades de reflexo coletiva sobre a experincia de MPS e
os problemas encontrados. Menos ainda se o foco da reflexo for a teoria-em-uso dos diversos
atores envolvidos, que lhes permitissem desenvolver um senso de causalidade pessoal sobre
os problemas que esto ocorrendo durante a interveno.
A crena no paradigma tcnico nos termos definidos no Captulo 4, Seo 4.7.4,
parece ser a base da ao dos profissionais de MPS (que em sua grande maioria so engenhei-
110
ros de software que transformaram-se em engenheiros de processos). Esta crena no s mol-
da o ngulo a partir do qual os problemas so analisados, mas delimitam tambm o papel que
eles acreditam que devem exercer. Seno, veja-se o relato de um dos entrevistados na pesqui-
sa desta dissertao:
... o SQA no RH. A gente escuta tudo, mas eu acho que a gente tem que sepa-
rar o que RH e o que no . Ento, quando chegar no gerente (refere-se aqui s
eventuais queixas que os desenvolvedores fazem de seus gerentes durante as audito-
rias), voc deve dizer: Jia! Mas faa o seguinte, converse com o pessoal do RH.
Eu acho que ele pode lhe ajudar. Mas no o SQA, porque a voc comea a criar
aquele cdigo secreto de confiana, que fulaninho diz para voc, que para fulaninha
e depois aquilo ali chega para o gerente e a voc fica como se estivesse num telefo-
ne sem fio injusto. Ento, eu acho que o SQA tem que ser objetivo, olhar proces-
so, produto e qualidade. isso o que ele olha. Ele no olha comportamento.
(Lorena, Consultora e Engenheira da Qualidade. Grifos meus).
Do ponto de vista da teoria de Argyris e Schn, o problema encontrado no relato
acima que ao assumir este tipo de postura os profissionais de MPS estaro eliminando de
seu raio de preocupao grande parte dos problemas no-tcnicos, que so informao valida
e til chave para o sucesso de intervenes de MPS. No entanto, de uma forma ou de outra
eles estaro lidando com estes mesmos problemas advindos das zonas indeterminadas da pr-
tica, conforme referido no Captulo 4, Seo 4.7.4. Transferir preocupaes com conflitos
entre pessoas ou grupos para outros profissionais (o pessoal do RH, por exemplo, conforme
o relato anterior) mais uma conseqncia da viso tcnica dos problemas, que busca espe-
cializar o tratamento destas questes como se isso fosse eficaz em qualquer situao.
Os problemas no-tcnicos so, muitas vezes, inseparveis dos objetivos das a-
es de MPS o que requer uma viso holstica destas questes. Na perspectiva defendida por
Argyris e Schn, conflitos como os mencionados no relato anterior deveriam ser explorados
como informao vlida e til sobre os problemas da interveno. Deve ser ressaltado que,
embora os profissionais de MPS possam recorrer a outros profissionais que venham a ajudar
na conduo deste tipo de problema, por outro lado, eles esto num papel central enquanto
intervenientes. Sendo assim, para obterem maior eficcia, devero estar preparados para exer-
cer as atividades primrias de interveno, sobretudo em situaes de conflito. Eles deveriam
ser capazes, por exemplo, de favorecer a criao de um ambiente de discusso minimamente
produtivo, onde estes problemas pudessem ser tratados em meio aos problemas tcnicos en-
contrados, pois estes problemas provavelmente se retroalimentam entre si.
Outras caractersticas relevantes que ocorrem na conduo de iniciativas MPS que
pode ser vistas como influncia do paradigma tcnico so:
111
i) O tratamento do conhecimento gerado em MPS como algo estocvel em ar-
tefatos documentais.
ii) A tendncia separao no tempo e espao entre a ao dos profissionais de
MPS (no papel de especialistas, engenheiros de processos) e dos praticantes,
que so os desenvolvedores de software (no papel de usurios dos processos).
Aaen (2002, 2003) argumenta que MPS diz respeito mudana e construo de
conhecimento no nvel do indivduo, do grupo e da organizao e, portanto diz respeito ges-
to deste conhecimento. Ele diz que um problema particularmente importante em MPS pos-
sibilitar um entendimento comum do processo de software entre aqueles que devem segui-lo.
Com base em Fahey e Prusak (1998), Aaen (2002, 2003) argumenta sobre alguns equvocos
cometidos em MPS na perspectiva da gesto deste conhecimento. Entre eles est a crena no
conhecimento como algo que pode ser separado e estocado fora da cabea das pessoas. Ele
argumenta que em termos de MPS se as organizaes seguirem esta viso, elas tendero a
desenvolver e manter estruturas de informaes com mais e mais descries complexas dos
processos na crena de que o conhecimento estar ali.
Como conseqncia, o mesmo autor alerta para o fato de que as iniciativas de
MPS podem se tornar algo que predominantemente conduzido como uma atividade de re-
taguarda separada dos praticantes, isto , os desenvolvedores de software, que deveriam ser a
fonte e o prprio objeto do conhecimento. Em outras palavras, desta forma, o foco de MPS
torna-se principalmente a externalizao de descries de atividades, papis, fluxos e artefatos
por um grupo especfico de profissionais (geralmente o SEPG
62
ou times de engenheiros de
processos), separadamente do conjunto seus praticantes (os desenvolvedores). Embora em
muitos casos se tenha constatado na pesquisa que os desevolvedores participam de SEPGs e
grupos de definio de processos, verifica-se que em geral esta participao restrita. Assim,
assume-se que o conhecimento construdo e armazenado sob a forma de descries de pro-
cessos por um grupo de especialistas para posteriormente ser usado pelos praticantes. Isto traz
como conseqncias negativas:
Pouco dilogo reflexivo entre os praticantes dos processos (os desenvolvedo-
res de sotware) e os engenheiros de processos e, portanto, pouca gerao de
informao vlida e til;

62
SEPG: Software Engineering Process Group (grupo de processo de engenharia de software).
112
Tendncia rejeio do conhecimento explcito associado s descries dos
processos quando estes se distanciam do conhecimento tcito dos praticantes
(desenvolvedores).
Esta a maneira tradicional pela qual MPS desenvolvida na maioria das organi-
zaes, conforme constatado nesta dissertao. Em geral, um grupo de engenheiro de proces-
sos faz a proposta dos processos e busca test-los junto equipe de desenvolvimento. Esta
abordagem mesmo quando comporta a anlise e sugestes de desenvolvedores, por ter esta
participao geralmente limitada aos integrantes dos SEPGs, pode ser ineficaz do ponto de
vista do dilogo entre as equipes e do nvel de gerao de conhecimento a partir deste dilogo.
O relato a seguir de um engenheiro de processos participante da pesquisa realizada nesta dis-
sertao parece denotar esta dificuldade de dilogo:
Tive problema com essa pessoa que eu estou te falando (refere-se a um lder de de-
senvolvimento). Ela no aceitava, ela dizia que a gente estava tentando empurrar os
processos goela abaixo, mas eu tentava mostrar pra ela que isso no era verdade,
que os processos estavam l, que eles estavam num primeiro momento, que as
pessoas tinham que contribuir dando sugestes, tentando aplicar na prtica pra ver
quais eram as deficincias, mas que simplesmente como as pessoas no tiveram o-
portunidade de participar na definio de processos, por motivos n... (d a enten-
der que as pessoas tinham dificuldade em testar o procedimentos que no foram
criados por eles). (Bartolomeu, Engenheiro da Qualidade. Grifos meus)
Aaen (2002) argumenta que a abordagem tradicional para MPS baseada nesta se-
parao entre concepo e uso do processo, reflete uma perspectiva arquitetural, onde o foco
voltado para a estrutura do processo de software e para os objetos (artefatos) que compem
esta estrutura (que so justamente os aspectos tcnicos de MPS). Citando um influente artigo
nos anos 1990 (Osterweil,1987: Software processes are software too) Aaen relata a idia de
que este enfoque tradicional de MPS semelhante ao desenvolvimento de software tradicio-
nal no qual a equipe de desenvolvimento implementa o software e o usurio final o utiliza.
Neste sentido, Aaen argumenta que os profissionais de MPS atuam como programadores de
processos, tendo os desenvolvedores de software como usurios.
Numa outra concepo, conforme argumentam Fahey e Prusak (1998) citados por
Aaen (2002), importante abordar o processo de conhecimento enquanto algo que envolve e
conecta indivduos, e que inseparvel daqueles que o usam e o desenvolvem. Desta forma o
processo de gerao do conhecimento deve ser inseparvel de sua prtica e de reflexo sobre
esta prtica. Aaen argumenta que esta abordagem coerente com as idias de aprendizagem
organizacional e reflexo em ao de Chris Argyris e Donald Schn (1996).
113
Este tipo de posicionamento requer dos profissionais de MPS habilidades para li-
dar com as zonas indeterminadas da prtica. Sobre estas habilidades, conforme j visto no
Captulo 4, Seo 4.8, Argyris e Schn sustentam que se os intervenientes pretendem aumen-
tar a competncia das organizaes em resolver seus prprios problemas, eles devero ser
para seus clientes um referencial de competncia na realizao das tarefas primrias de inter-
veno. Eles sero to mais exemplares para seus clientes (os desenvolvedores) quanto conse-
guirem isso, mesmo em situaes problemticas e sob tenso. Nesse caso, os profissionais de
MPS deveriam estar bem mais preocupados com este aspecto de sua competncia enquanto
intervenientes do que parecem demonstrar nos diversos relatos colhidos na pesquisa desta
dissertao. Entretanto, eles podem no ter um conscincia clara destes aspectos em virtude
da base de sua formao profissional conforme exposto na seo seguinte.
5.2.4.2 Abordagem Predominantemente Tcnica na Educao dos Profissionais
A viso instrumental sobre os problemas de MPS e da engenharia de software em
geral, fundamentalmente criada e reforada pelo tipo de formao profissional que as pesso-
as recebem em cursos universitrios e de extenso nesta rea. De forma semelhante a Lyyti-
nen e Robey (1999) pde-se constatar na pesquisa desta dissertao que a grande maioria dos
profissionais que conduzem iniciativas de MPS, incluindo todos os participantes das entrevis-
tas so oriundos da atividade de engenharia de software com pouca ou nenhuma bagagem
educacional nas cincias sociais. Lyytinen e Robey (1999) argumentam que, sob a influncia
da racionalidade tcnica, as pessoas recrutadas nas empresas para papis relacionados rea
de engenharia de software, incluindo MPS, tendem a assumir que seu desafio em termos de
educao profissional adquirir mais e mais conhecimento tcnico.
Especificamente em termos de MPS pode-se argumentar que pelas situaes pro-
blemticas referidas nas sees anteriores esta uma viso limitada e insuficiente porque,
como j argumentado, em muitos casos as questes humanas e organizacionais so insepar-
veis das questes tcnicas em MPS. Provavelmente no haver treinamento em engenharia de
software ou modelos de qualidade que possam substituir habilidades necessrias eficcia em
problemas relacionados ao coletiva como o caso de MPS. Competncia nas atividades
primrias de interveno; habilidades de reflexo e aprendizagem sobre ao; noo pelos
agentes de como sua teoria-em-uso impacta o grupo e a organizao; habilidades relacionais
como: empatia, capacidade de negociao, facilitao de grupos e comunicao clara, s para
citar algumas, no sero desenvolvidas em cursos de natureza tcnica. Por outro lado estas
114
competncias so adquirveis e aprimorveis em ambientes adequados que explorem ativida-
des laboratoriais com base na reflexo em ao e sobre a ao.
Com base em Argyris e Schn (1974, Captulo 10), pode-se argumentar que uma
ao eficaz para mudar a viso tradicional da educao profissional em engenharia de softwa-
re e consequentemente MPS, seria a reforma do currculo dos cursos que formam os profis-
sionais destas reas. Esta modificao deveria incluir a insero de disciplinas das cincias
sociais que abordassem problemas como os mencionados anteriormente ligados, por exemplo,
a aspectos da aprendizagem organizacional na atividade de engenharia de software.
Schn (2000, Captulo 1) argumenta que a educao profissional deveria caminhar
em direo ao desenvolvimento do talento artstico profissional
63
. Para ele, este aprendizado
depende, pelo menos em parte, de condies semelhantes quelas criadas nos atelis e conser-
vatrios de arte e design: liberdade para aprender atravs do fazer, em um ambiente de risco
relativamente baixo, com instrutores que iniciam os estudantes nas "tradies da vocao", e
os ajudam a ver por si prprios e sua prpria maneira, aquilo que eles mais precisam conhe-
cer. Tais ambientes deveriam ser capazes de educar o profissional para a reflexo-em-ao
64
e
para a aprendizagem pblica coletiva, fundamentada na reflexo retrospectiva. Essa viso
requer um novo paradigma de concepo do mundo profissional e suas escolas de formao.
Todavia, com base em Argyris e Schn (1974, Captulo 10) pode-se prever que
uma mudana paradigmtica desta natureza que requer a mudana de valores difcil e mes-
mo improvvel. assim porque uma das caractersticas do Modelo I
65
, que subjacente ao
paradigma da racionalidade tcnica, tornar o sistema auto-oclusivo a reflexes profundas e
pouco permevel mudana de valores.
Diante do exposto, provvel que os profissionais de MPS sigam aprendendo so-
bre estas questes apanhando com os problemas na prtica. Porm, sem um referencial te-
rico e estratgias eficazes de investigao e reflexo sobre a ao, este aprendizado tende
tambm a ser limitado pelos mesmos valores de Modelo I que dificultam a aprendizagem de
novos valores (aprendizagem de ciclo-duplo).

63
Artstico aqui tem a ver com o conhecimento tcito que geralmente necessrio em toda prtica profissio-
nal, inclusive para a boa aplicao da tcnica. interessante observar que em Engenharia de Software muitos
referem-se arte de conceber e programar solues elegantes em termos de algoritmos e implementao.
64
Habilidade de refletir sobre a ao enquanto age..
65
Ver Captulo 3, sees 3.6.3 e 3.6.4.
115
5.3 ALGUMAS REFLEXES ADICIONAIS COM BASE EM OUTROS AUTORES
Pelo exposto neste Captulo, iniciativas de MPS certamente se enquadram na ca-
tegoria tpica de intervenes em que Argyris (1970 e 2004) preconiza como sendo funda-
mentais as tarefas primrias de gerao de informao vlida, escolha livre e informada, com-
prometimento interno e monitoramento das implementaes das decises. De acordo com
Fugetta (2000), iniciativas de MPS deveriam levar mais em conta o que outras disciplinas e
pesquisadores j descobriram sobre qualidade e melhoria de processos, pois os mtodos rela-
cionados tecnologia e processos de software ignoram ou apenas consideram superficialmen-
te as contribuies de cientistas organizacionais. Portanto, correm os riscos de ignorar ques-
tes importantes que podem ocupar um papel crtico em iniciativas de melhorias. Por exem-
plo, muitas das indicaes sugeridas pelo CMM / CMMI tm foco apenas em aspectos de
engenharia. Todavia, a implementao bem sucedida desses fatores requer, geralmente, uma
reconsiderao mais profunda sobre a organizao que est realizando estas atividades. Este
tipo de implicao tratada inadequadamente pela maioria dos modelos de MPS. Baddoo e
Hall (2003) sustentam a hiptese de que MPS pode no estar atendendo aos benefcios prome-
tidos pela ateno insuficiente que tem sido dada aos aspectos humanos da implementao de
deste tipo de iniciativa.
Porque h uma ampla predominncia de uma viso tcnica, frequentemente, a a-
bordagem para tratamento dos problemas de processos de software considerar que a dificul-
dade est na inadequao dos mtodos (Woolgar, 1994). O remdio usual buscar melhor-
los com mais mtodos e torn-los mais sofisticados. Porm, se a dificuldade residir na inter-
pretao do problema estas iniciativas podem at pior-los (adicionando mais complexidade
aos processos, por exemplo). Lyytinen e Robey (1999) alertam tambm para este problema e
argumentam que h uma barreira educacional e na prtica profissional na rea de desenvolvi-
mento de sistemas, onde o interesse basicamente direcionado para questes tecnolgicas.
Alm destes ltimos autores citados, Woolgar (1994) argumenta para a importncia de novo
enquadramento dos problemas privilegiando aspectos sociais, organizacionais e do negcio. O
paradigma da racionalidade tcnica e as limitaes derivadas dele afetam no s iniciativas de
MPS, mas a rea de engenharia de software como um todo. Goguen e Linde (1993), por e-
xemplo, argumentam que a maioria dos sistemas computacionais so desenvolvidos sem
qualquer ajuda das cincias sociais. Para eles, isto significa que as necessidades dos usurios
(indivduos e organizaes) no so tratadas de forma sistemtica.
116
Uma outra fonte de problemas que merece reflexo para os profissionais de
MPS o fato de que nenhum mtodo genuinamente prova de falhas (Button e Sharrock,
1994). H sempre um limite para a extenso do que pode ser feito pelos engenheiros de pro-
cessos em termos de design de procedimentos de trabalho, sem que isso envolva a dependn-
cia do bom senso daqueles que tero efetivamente que seguir o procedimento em seu traba-
lho dirio. Isto assim porque, por mais bem definido que seja um mtodo ou procedimento,
ele reflete um conjunto de recomendaes que precisam ser reinterpretadas e adaptadas pelos
profissionais que os esto aplicando em seu trabalho. Sobre este particular, a atividade de de-
senvolvimento de software mesmo quando utiliza processos padronizados raramente uma
simples seqncia mecnica de passos que ocorrem sempre da mesma forma independente da
realidade em questo. Em geral, cada novo projeto de desenvolvimento de software envolve
diferenas de contexto em relao a projetos anteriores quanto ao domnio da aplicao, pro-
blemas a serem resolvidos na organizao-cliente, ou mesmo quanto a mudanas na equipe de
desenvolvimento. Por isto, este passo interpretativo e adaptativo dos profissionais para utili-
zao prtica de uma metodologia ou procedimento uma necessidade constante nesta ativi-
dade. Ou seja, parte do esforo em desenvolvimento de software que usa mtodos definidos
consiste em fazer os prprios mtodos funcionarem na prtica (Button e Sharrock, 1994).
Neste sentido, o prprio Humprhey (2002), que o idealizador dos modelos CMM e outros
mtodos como PSP (CMU/SEI, 2006
c
) e TSP (CMU/SEI, 2006
d
), afirma que poucas pessoas
conseguem consistentemente realizar este tipo de esforo de forma disciplinada.
Alm disso, como a execuo dos processos de software envolve situaes de
interao entre os desenvolvedores entre si, com os gerentes e tambm com os clientes, estas
questes abrem a possibilidade para a ocorrncia do que Schn (2000) chama de zonas inde-
terminadas da prtica (ver seo 4.7.4).
Exemplificando como as teorias em uso sobre MPS podem tratar superficialmente
aspectos no tcnicos, podemos citar algumas concepes que, segundo Abrahamson (2000),
so limitadas e carecem de base cientfica, mas que esto geralmente implcitas em modelos
como o CMM (Paulk, Curtis e Weber, 1993) e na ao dos profissionais da rea, em relao
ao conceito de comprometimento:
i. A noo de comprometimento como um construto singular (contrapondo
esta compreenso, na Seo 4.3 foram apresentados vrios componentes
importantes para entendimento dos fenmenos relativos ao conceito de
comprometimento).
117
ii. A crena de que o comprometimento cresce de forma linear em relao aos
estmulos para seu desenvolvimento (Abrahamson argumenta que no h
evidncia cientfica disto).
iii. A crena na controlabilidade do processo de comprometimento (verifica-se
que este um processo, no mximo, influencivel, mas no controlvel).
iv. A premissa de que um alto nvel de comprometimento sempre til (verifi-
ca-se que isso no necessariamente sempre verdade: o foco do compro-
metimento pode tornar-se um problema).
Em um outro exemplo prtico do risco da superficialidade, podemos verificar co-
mo o modelo CMMI (CMU/SEI, 2001) trata a questo da participao, mesmo quando alega
que uma questo crtica para o sucesso de certas atividades preconizadas no modelo. Este
documento tem trechos como:
The identification of promising incremental and innovative improvements should
involve the participation of an empowered workforce aligned with the business
values and objectives of the organization. (pg. 52. Grifos meus)
Posteriormente o documento preconiza:
1. Promote an environment (created as part of project management) that encourages
employee participation in identifying and reporting quality issues
[PA145.IG101.SP101.SubP101]" (pg. 178. Grifos meus)
Successful implementation of improvements requires participation in the process
definition and improvement activities by process owners, those performing the proc-
ess, and support organizations. [PA152.IG102.N101] (pgina 318. Grifos meus)
Podemos ento verificar nesse caso que, embora o documento faa de fato alega-
es importantes sobre a necessidade da participao, criao de ambiente apropriado para
participao, e deciso coletiva, no ser encontrada em suas 707 pginas, qualquer aprofun-
damento sobre quais so as caractersticas de tal ambiente, nem de como ele pode ser criado.
Nem tampouco h referncia fonte externa para aprofundamento do assunto. Pode-se con-
cluir ento, sobre estas alegaes do referido documento, que:
i. Elas parecem estar baseadas em conhecimento de senso comum, porm
sem base cientfica testada, ou enquadramento terico que as apiem;
118
ii. As pessoas que as utilizam, com base apenas no modelo em questo, po-
dem no estar suficientemente conscientes sobre com o que esto lidando, e
consequentemente,
iii. Elas podem estar lidando para com este assunto muito mais como um ele-
mento de discurso, do que algo que realmente so capazes de realizar na
prtica, j que por desconhecimento, podem no dispor de estratgias ade-
quadas.
Evidentemente, em muitas situaes de interveno de MPS pode ocorrer que haja
intervenientes suficientemente habilidosos e experientes, que baseados em seu conhecimento
tcito, somado a uma organizao-cliente igualmente madura e com alto grau de prontido
para mudana, venham a desenvolver intervenes bem sucedidas nestes aspectos. Mas cer-
tamente, haver um outro nmero igual ou maior de situaes em que estas questes podem
trazer muitos mal-entendidos entre os participantes.
Como reflexo sobre estas lacunas nos modelos normativos de MPS, deve-se con-
siderar que, ainda que modelos como o CMMI ou MPS.Br possam ser alvo de investigao de
inmeros pesquisadores, eles so tambm produtos de mercado. Como tal, eles podem sofrer
de problemas como: desatualizao, presso para lanamento de novas verses em funo de
metas de conquista de mercados, e falta de testes suficientes. Consequentemente, so sujeitos
inconsistncias e bugs como qualquer produto da indstria de software. Portanto, interve-
nientes e clientes de programas de MPS devem ter conscincia crtica sobre estes aspectos.
Para tanto, devem gerar informao vlida e til sobre sua aplicabilidade e eventuais lacunas
em situaes especficas, e no tratar o conhecimento preconizado por estes modelos, como
verdades incontestveis.
Apesar da prtica amplamente tecnicista em MPS, alguns autores tm demonstra-
do a preocupao com esta lacuna. Abrahamsson (2000, 2002) aborda especificamente o tema
do comprometimento em MPS e embora de uma forma passageira, este autor cita as ativida-
des primrias de interveno preconizadas por Argyris como forma de desenvolver compro-
metimento em MPS. Lyytinen e Robey (1999) apresentam uma viso que se aproxima da
argumentao desta dissertao sobre as dificuldades de aprendizagem coletiva, gerao de
conhecimento e eficcia em equipes de desenvolvimento de sistemas, todavia no aprofunda
sobre atividades primrias de interveo. Mathiassen, Nielsen e Pries-Heje (2002) argumen-
tam que organizaes de software que estejam implementando MPS devem ser orientadas
soluo de problemas e que esta abordagem deve estar em acordo com a proposta de aprendi-
zagem organizacional de Argyris e Schn (1996). Embora no se refiram textualmente ne-
119
cessidade da atividade primria de gerao de informao vlida, eles reforam esta idia
quando argumentam que os profissionais envolvidos devem desenvolver habilidades diagns-
ticas. Afirmam ainda que MPS adquire uma imagem negativa entre profissionais de desenvol-
vimento de software quando o grupo de MPS oferece pouca informao ou informao ina-
propriada, quando no demonstram resultados teis ou falham em interagir com os profissio-
nais de desenvolvimento.
5.4 COMENTRIOS FINAIS AO CAPTULO
Este captulo buscou mostrar como problemas de MPS relatados na pesquisa qua-
litativa documentada no captulo 4 podem ser explicados em termos principalmente de:
Deficincias na teoria-de-interveno utilizada pelos profissionais de MPS,
que predominantemente de natureza tcnica e instrumental, e no enfatizam
suficientemente as atividades primrias de interveno, nem a reflexo e a-
prendizagem coletivas;
Deficincias nas teorias-em-uso dos atores como um todo (profissionais de
MPS, desenvolvedores, gerentes e alta administrao de empresas de softwa-
re), que so influenciadas por estratgias voltadas para o controle unilateral
dos objetivos, do ambiente e das tarefas;
Deficincias no sistema de aprendizagem da organizao para com mudanas
pretendidas (normas tcitas vigentes incongruentes com as propostas de me-
lhorias).
Estas deficincias podem ser vistas como fatores sobre-determinantes para o sur-
gimento de muitas das barreiras em MPS relatadas no Captulo 3, ou que no mnimo, contri-
buem para que aqueles problemas permaneam sem soluo produtiva. Um exemplo disto
pode ser a dinmica disfuncional retratada nos arqutipos apresentados no final daquele cap-
tulo que tende a permanecer sem soluo produtiva em virtude dos fatores determinantes a-
bordados no presente captulo.
Vale esclarecer, quanto relatos dos entrevistados empregados neste captulo para
ilustrar os problemas que, por limitaes de escopo da pesquisa, o autor desta dissertao em
alguns casos empregou inferncias que no foram possveis testar com os agentes entrevista-
dos sobre certos aspectos da teoria-em-uso (intenes, pressupostos) deles no contexto relata-
do. Um processo mais rigoroso com base na cincia da ao (Argyris, Putnam e Smith, 1985)
120
exigiria um diagnstico mais profundo da teoria-em-uso dos agentes nos termos, por exem-
plo, apresentados por Argyris (2004, Captulo 6). Todavia, isto j se caracterizaria em si como
uma interveno que exigiria uma disponibilidade e abertura dos entrevistados e de suas orga-
nizaes para muito alm do escopo do trabalho pretendido nesta dissertao.
Finalmente, ressalte-se que referncias s teorias de Argyris e Schn embora raras
no so novidade na literatura de MPS. Alguns pesquisadores em MPS, particularmente auto-
res escandinavos citados ao longo desta dissertao como: Lyytinen, Mathiassen, Aaen,
Brjesson, Abrahanssom, Iversen e Nielsen, trazem referncias aos trabalhos daqueles auto-
res. Estas referncias se do principalmente no tocante a conceitos de aprendizagem organi-
zacional, como aprendizagem de ciclo-nico e de ciclo-duplo, sendo esta ltima vista como
um conceito fundamental para compreenso de inovaes paradigmticas nas organizaes.
Todavia, de uma maneira geral as referncias existentes no aprofundam suficientemente os
conceitos de teoria de interveno de Argyris e menos ainda de teoria de ao de Argyris e
Schn. Entretanto deve ser ressaltado que estes ltimos conceitos citados so sustentculos
fundamentais das teorias de aprendizagem organizacional no s de Argyris e Schn mas de
outros autores renomados influenciados por eles, a exemplo de Peter Senge (2001). A ilustra-
o dos problemas de MPS em termos destes conceitos uma contribuio especifica desta
dissertao.
A crena fundamental do autor desta dissertao de que estes conceitos ajudam a
uma compreenso mais profunda dos problemas de MPS para alm de opinies de senso co-
mum sobre os fatores humanos e sociais vigentes nesta atividade. Desta forma, este conheci-
mento pode vir a inspirar uma prtica mais eficaz de MPS.
121
6 PRESCRIES
O captulo anterior buscou aprofundar a compreenso de parte dos problemas de
MPS identificados no Captulo 3, do ponto de vista das teorias de Argyris e Schn que foram
apresentadas no Captulo 4. Diante desta compreenso, torna-se ento importante identificar
prescries de como encaminhar o tratamento destes problemas. Levando-se em conta os pro-
blemas conforme colocados ao longo do Captulo 5, entre outras possibilidades, pode-se con-
siderar que as preocupaes fundamentais sobre como trat-los giram em torno das seguintes
questes:
i. Como reduzir o nvel de inconsistncia das normas do sistema organizacio-
nal com os objetivos da interveno de MPS?
ii. Como melhorar a competncia de profissionais de MPS e desenvolvedores
de software em lidar de forma produtiva com situaes problemticas em
MPS?
iii. Como tornar a teoria-em-uso e de interveno dos profissionais de MPS
mais consistentes com as atividades primrias de interveno?
iv. Como incrementar a conduo de intervenes de MPS com aspectos para
alm do paradigma da racionalidade puramente tcnica?
As sees seguintes prescrevem algumas alternativas de ao (que certamente no
so as nicas possveis) visando responder especificamente
66
a estes questionamentos.
6.1 REDUZINDO A INCONSISTNCIA DAS NORMAS DO SISTEMA ORGANI-
ZACIONAL COM OS OBJETIVOS DA INTERVENO DE MPS
O tratamento deste tipo de problema certamente requer a conscientizao e ali-
nhamento de viso dos atores envolvidos na cadeia de produo de software e de melhoria de
processos, sobretudo dos lderes da organizao, comeando na alta administrao e incluindo
gerentes de projetos e lderes tcnicos.

66
No sero tratados aqui, outros problemas relevantes apontados na pesquisa, como por exemplo, aqueles de
natureza econmica que giram em torna da dificuldade de sobrevivncia das empresas, ausncia de recursos
suficientes e presses de mercado.
122
Esta estratgia de ao est fortemente relacionada a promover aes na direo
de pelo menos dois fatores crticos em MPS revelados no Captulo 3:
Conscientizao/entendimento dos benefcios e exigncias da MPS (enfati-
zando aqui o aspecto das exigncias)
Objetivos claros, relevantes e alinhados.
Estas estratgias requerem a compreenso do nvel de incongruncia das normas
67

do sistema organizacional com os objetivos da interveno e implicam na identificao de
diferenas entre a teoria proclamada e teoria-em-uso na organizao (ver conceitos apresen-
tados no Captulo 4, Seo 4.2). Tomando como base o mtodo de pesquisa-ao (Baskerville,
1999), este objetivo poderia, por exemplo, ser tratado com uma seqncia de aes, como:
i) Realizao de uma pesquisa diagnstica qualitativa que poderia ser feita
nos moldes metodolgicos da pesquisa descrita no Captulo 3, com o objetivo
de fazer emergir estas incongruncias. Esta pesquisa, tanto quanto possvel,
deve envolver todos os atores relevantes da cadeia de produo de software.
Ela deve privilegiar mtodos que possibilitem o aprofundamento das crenas e
atitudes adotadas pelos diversos atores. Poderia envolver uma combinao dos
seguintes mtodos:
a. Entrevistas presenciais gravadas com base em questes abertas semi-
estruturadas. Tm como vantagem a possibilidade de aprofundamento de
certas questes conforme o contexto do relato. Tem como desvantagem
consumir tempo e recursos de um entrevistador e posterior necessidade de
transcrio da entrevista; s vezes os entrevistados podem no ficar von-
tade com a gravao ou com o entrevistador.
b. Questionrios, com base em questes abertas semi-estruturadas. Tm co-
mo algumas vantagens: baixo custo de operacionalizao; obteno de da-
dos j transcritos para posterior anlise. Suas desvantagens so: menor
possibilidade de explorao e aprofundamento do contexto das respostas;
nem sempre os respondentes tm o necessrio comprometimento de apro-
fundar suas respostas; as respostas podem no ser suficientemente descri-
tivas (baseadas em evidncias) e os pesquisadores no estaro l para es-
clarec-las.

67
Por normas, como j citado anteriormente, entenda-se no apenas as explcitas, mas tambm as tcitas que
permeiam a cultura organizacional.
123
c. Grupos focais de discusso, onde pequenos grupos de atores discutem os
problemas com base em um roteiro semi-estruturado. A discusso grava-
da e posteriormente transcrita para anlise. Tem como vantagem: a intera-
o entre atores pode enriquecer as opinies individuais e criar um ambi-
ente de discusso coletiva. Tem como desvantagens: tendem a ter uma o-
peracionalizao nem sempre simples em compatibilizar agendas; a trans-
crio das discusses tende a ser mais complexa; algumas discusses po-
dem no ser produtivas quando alguns atores tolhem as falas e opinies a-
lheias, ou, quando alguns atores no se sentem vontade para aprofundar
certas questes na presena dos demais.
Um roteiro de como os dados gerados podem ser processados, pode ser encon-
trado na Seo 3.1 desta dissertao.
ii) Seminrios para devoluo de resultados da pesquisa envolvendo todos os
atores relevantes. Avaliao destes resultados em subgrupos e coleta de suges-
tes para estabelecimento de plano de ao.
iii) Seminrios ou grupo de trabalho para estabelecimento de planos de aes
de melhoria para reduo das incongruncias, envolvendo todos os atores re-
levantes.
a. Os planos de ao devero levar em conta restries de contexto como
tempo e recursos. Devero resultar de um acordo entre os atores que se
perceba realista para este contexto.
b. Os planos devem idealmente ser desenvolvidos levando em conta o
contexto dos projetos especficos em curso na organizao.
c. Se for o caso, eles podem incluir questes relativas a reas de proces-
sos de modelos normativos de qualidade software.
d. Devero ser estabelecidos indicadores qualitativos de comprometimen-
to que reflitam a realizao das aes e um grupo de monitoramento
das aes.
A seqncia de aes descrita acima pode parecer relativamente simples em ter-
mos do entendimento de como ela se processa. Todavia, vale ressaltar que um diagnstico que
envolva o tratamento de incongruncias entre a teoria-em-uso e a teoria proclamada dos ato-
res lderes da organizao pode ser extremamente difcil de ser conduzido, uma vez que este
tipo de problema o centro das rotinas defensivas, que costumam gerar questes indiscutveis
que tomam a forma de agendas ocultas (Argyris e Schn, 1996; Argyris, 2004) entre os
124
atores. Para exemplificar, em termos de situaes de MPS constatadas na pesquisa desta dis-
sertao, podero surgir situaes paradoxais como:
Membros da alta administrao que proclamam que querem implantar proces-
sos de software (geralmente porque esto visando certificao da empresa),
mas paralelamente, porque no aceitam perder oportunidades de negcio, sa-
botam (inconscientemente ou no) as aes de MPS retirando recursos hu-
manos da equipe de qualidade ao menor sinal de novos projetos com os clien-
tes, causando descontinuidade e desestmulo com aes de MPS.
Gerentes de projeto que proclamam que querem implantar e melhorar proces-
sos, mas paralelamente, porque tm que atender a prazos irrealistas, induzem
suas equipes a abandonar os processos.
Equipes de desenvolvimento que proclamam que seguem os processos estabe-
lecidos, mas produzem muitos dos artefatos requeridos por engenharia rever-
sa s vsperas das auditorias de processos (ou seja: os processos muitas vezes
so puros faz-de-conta).
Profissionais de MPS que priorizam aspectos formais de certificao dos pro-
cessos em vez da ajuda genuna melhoria de processos das equipes de de-
senvolvimento.
Situaes como estas tendero a ser tratadas como questes embaraosas que por
influncia do Modelo I de teoria-em-uso (ver Seo 4.7.3) na maioria das vezes sero enco-
bertas ou minimizadas. Este tipo de problema ir requerer o que, com base em Argyris e
Schn (1996), se pode denominar de interveno no sistema de aprendizagem que visa identi-
ficar e remover barreiras investigao e reflexo coletivas dos problemas aumentando a
chance da ocorrncia de aprendizagem de ciclo-duplo. Argyris (2004, Captulos 6 e 7) descre-
ve intervenes que aprofundam este conceito. Este tipo de interveno costuma ser extre-
mamente exigente em termos de:
Competncia dos intervenientes nas atividades primrias de interveno, so-
bretudo nas situaes de tenso que podem emergir.
Abertura e comprometimento dos participantes em aderir s atividades prim-
rias; e confiana destes nos intervenientes.
Se por um lado intervenes no sistema de aprendizagem so desafiadoras, por
outro lado, o no tratamento das incongruncias citadas anteriormente tender a levar a inicia-
tiva de MPS ao insucesso uma vez que encontre barreiras na forma de normas implcitas j
125
solidificadas no sistema organizacional. Estas normas implcitas tendero a impedir as mu-
danas recomendadas pelas aes de MPS, conforme visto em relatos apresentados no captu-
lo anterior.
A realizao de pesquisa diagnstica de natureza mais orgnica (Argyris, 1970,
Captulo 5) conforme sugerido nesta seo pode ser um importante complemento a avaliaes
de processos que possuem carter mais mecnico e so mais comuns em MPS.
6.2 MELHORANDO A COMPETNCIA DOS PROFISSIONAIS DE MPS EM
CONDUZIR AS ATIVIDADES PRIMRIAS DE INTERVENO
Os questionamentos (ii), (iii) e (iv) realizados na introduo deste captulo so for-
temente interconectados entre si. Conforme j referido anteriormente, constata-se que a for-
mao dos profissionais de MPS predominantemente de natureza tcnica. Embora os pro-
blemas relativos aos questionamentos referidos no digam exclusivamente aos profissionais
de melhoria de processos, deve ser ressaltado que, no contexto de MPS, eles desempenham
mais que ningum o papel de intervenientes. Como tal, suas aes tende a ter ampla irradiao
sistmica para as equipes de desenvolvimento e mesmo para a alta administrao. Desta for-
ma, o tratamento dos questionamentos acima citados, ser amplamente beneficiado se estes
profissionais tiverem a oportunidade de estender a sua formao com um programa de capaci-
tao voltado para melhorar seu repertrio de habilidades enquanto intervenientes, nos moldes
dos requisitos preconizados na Seo 4.8 (O Papel dos Intervenientes) desta dissertao.
Iniciativas deste tipo em MPS, embora raras, no so necessariamente novidade.
Brjesson (2006) descreve um programa conduzido na Ericsson com base em pesquisa-ao
com o objetivo de capacitar profissionais de MPS enquanto agentes de mudana. Esta inter-
veno fundamentou-se principalmente em mtodos de aprendizagem ao
68
(Revans, 1998 e
Marquardt, 1999, citados por Brjesson, 2006) e reflexo em ao (Schn, 1983, citado por
Brjesson, 2006) aplicadas em situaes de MPS. A experincia consistiu de seminrios, ati-
vidades individuais de estudo e realizao de diagnsticos ao longo de um ano com um grupo
de profissionais de MPS. Os seminrios eram constitudos principalmente por discusso de
artigos selecionados, apresentaes tericas, estabelecimento de planos de ao, avaliaes do
programa de MPS em andamento e dos diagnsticos realizados. Os temas de estudo nos semi-
nrios e leituras individuais envolviam: pesquisa-ao, gesto de conhecimento, aprendiza-

68
Action Learning, termo original em ingls.
126
gem organizacional e gesto de mudana intercalados a questes de MPS vivenciadas pelo
grupo. Os resultados relatados na pesquisa revelaram-se muito animadores conforme pode ser
constatado naquela publicao, que tem o sugestivo ttulo: improve by improving software
improvers (Brjesson, 2006).
Valena e Associados (1995 e 1997) descrevem detalhadamente a implementao
de um programa de formao de consultores organizacionais e de uma comunidade de prtica
em aprendizagem organizacional com base na cincia da ao proposta por Argyris e seus
colaboradores (Argyris, Putam e Smith, 1985). Diferentemente de Brjesson (2006), a experi-
ncia relatada por Valena e Associados no focada em MPS, mas em situaes de consul-
toria em geral, muitas das quais envolvendo mudanas na organizao. Alm disso, aquela
iniciativa envolveu atividades com potencial de mudana da teoria-em-uso dos participantes
ainda mais profundas do que a referida por Brjesson e, por outro lado, tambm um esforo
de tempo de programa muitas vezes maior. De forma semelhante a Brjesson (2006), a expe-
rincia de Valena e Associados envolveu atividades de seminrios, estudos individuais e em
grupo, alm de diagnsticos. Os seminrios, alm de atividades relativamente semelhantes s
relatadas por Brjesson, incluam estudos de caso individuais (referidos por Valena e Asso-
ciados como clnicas de habilidades) sobre situaes de interveno e sobre a teoria-em-uso
dos participantes. Havia tambm encontros especficos de imerso de longa durao voltados
para a sensibilizao dos participantes em temas relativos aos objetivos do programa. O autor
desta dissertao teve oportunidade em tomar parte desta iniciativa ao longo de seis anos, e
pde constatar sua eficcia em melhorar a capacidade dos participantes em termos de: de rea-
lizar as atividades primrias de interveno; de refletir sobre sua teoria-em-uso; e de facilitar
a aprendizagem organizacional em diversos contextos. A crena fundamental que move a
pesquisa desta dissertao est em que muitos aspectos desta experincia so aplicveis ao
contexto dos profissionais de MPS.
A proposta de desenvolvimento de competncias de interveno para profissionais
de MPS apresentada a seguir toma por base elementos previstos nas experincias referidas
acima.
6.2.1 Um Programa de Desenvolvimento de Competncias de Interveno para Profis-
sionais de MPS
A proposta de um programa de desenvolvimento de competncias de interveno
para profissionais de MPS tem como objetivo melhorar as habilidades destes profissionais em
127
conduzir eficazmente as atividades primrias de interveno: gerao de informao vlida e
til, de escolha livre e informada, de comprometimento interno, e monitoramento da interven-
o. Isto se traduz num aumento da capacidade diagnstica ampla dos fenmenos relativos a
iniciativas de MPS que inclua aspectos scio-tcnicos, e tambm o aumento da capacidade de
lidar com esses fenmenos.
Um programa deste tipo pode ter como pblico-alvo:
Profissionais de MPS;
Outros atores que tomem parte regularmente em aes de MPS;
Em situaes especficas, com vistas a desenvolver a compreenso e apoio ao
programa: membros da alta gerncia, lderes de projetos, lderes tcnicos ou
mesmo todo o time de desenvolvimento.
Este programa tem como premissas principais
O programa se desenvolve preferencialmente enquanto os participantes esto
inseridos em iniciativas de MPS em curso;
O programa no visa diretamente a melhoria de processos de software, mas se
utiliza das situaes de MPS para melhorar as habilidades de interveno dos
participantes e, portanto, espera-se que seus resultados se reflitam no prprio
processo de MPS.
Como contedo terico a ser abordado sugere-se os seguintes temas principais,
tomando como base as teorias de Argyris e Schn vistas em captulos anteriores:
teoria de interveno: porque a base da argumentao desta dissertao para
compreenso e tratamento dos problemas de MPS.
pesquisa-ao: porque um mtodo de pesquisa diagnstica e de interveno
alinhado com a abordagem terica desta dissertao.
teorias de ao: porque estende e aprofunda a compreenso dos fenmenos
tratados em teoria de interveno;
aprendizagem organizacional: porque estende e aprofunda a compreenso dos
fenmenos tratados em teoria de interveno e pode inspirar aes de desen-
volvimento organizacional;
Estes contedos podem ser complementados com conhecimentos subsidirios -
teis em reas como: reflexo em ao (Schn, 1983 e 2000), pensamento sistmico (Senge,
2001) e gesto de conhecimento (Nonaka e Takeuchi, 1995, citados por Brjesson, 2006).
128
Este contedo terico deve ser conduzido, to prximo quanto possvel de refle-
xes sobre situaes concretas de iniciativas de MPS. Para tanto, uma abordagem metodol-
gica interessante e alinhada com a argumentao anteriormente usada nesta dissertao pode
ser a pesquisa-ao (Baskerville, 1999) com fins de educao profissional, onde os partici-
pantes devem buscar:
Conhecer o contedo terico proposto;
Diagnosticar e resolver problemas reais da sua teoria de interveno em MPS
nas suas organizaes.
Contribuir com gerao de conhecimento em intervenes de MPS.
6.2.1.1 Etapas do Programa de Desenvolvimento de Competncias de Interveno
Como etapas do programa sugerem-se:
i. Iniciao: um ou dois seminrios de sensibilizao dos participantes, pr-
diagnstico e definio do contexto do programa.
ii. Mdulos temticos: uma hiptese poderia ser a diviso em 04 mdulos te-
mticos, com durao em torno de quatro a seis meses cada, envolvendo a
seguinte seqncia de temas principais anteriormente propostos: (1) teoria
de interveno; (2) pesquisa-ao em MPS; (3) teorias de ao em MPS; e
(4) aprendizagem organizacional e gesto de conhecimento em MPS.
iii. Fechamento: um seminrio para avaliao geral do programa e planeja-
mento da manuteno e difuso do conhecimento adquirido.
Sugere-se que os mdulos temticos sejam conduzidos como ciclos iterativos de
Diagnstico-Planejamento-Ao-Avaliao, conforme a Figura 6.1.

129

Figura 6.1: Modelo Cclico de Interveno com base em Pesquisa-Ao
O modelo cclico da Figura 6.1 inspirado nas fases do mtodo de pesquisa-ao
ilustrado por Baskerville (1999) e no modelo IDEAL (Gremba e Myers, 1997) visto na Seo
2.2.3 desta dissertao. Todavia, em relao a este ltimo possui algumas diferenas funda-
mentais:
O modelo no pressupe transies precisas entre as fases, que poderiam ser
irrealistas numa aplicao de pesquisa-ao deste tipo.
O modelo no define aprendizagem como uma fase, mas como a conseqncia
de um esforo permanente que, por sua vez, resultado do emprego mtodos
voltados para a reflexo-em-ao (Schn, 1983 e 2000) ao longo de todas as
fases do programa.
O modelo pressupe nveis de controle distintos pelos condutores da iniciati-
va: a aprendizagem vista como um processo influencivel, porm pouco
controlvel, uma vez que um processo interno s pessoas; o esforo de refle-
xo-em-ao pode ter algum nvel de controle pelo tipo de atividade que e-
xercido; e apenas as atividades relativas ao diagnstico-planejamento-ao-
avaliao podem ter um nvel de controle relativamente alto.
Mdulo de Teoria de
Interveno em MPS
Iniciao
Fechamento
Alto
Mdio
Baixo
Controle sobre o Processo:
Mdulo de Pesqui-
sa-ao em MPS
Mdulo de
Teorias de ao
Aprendizagem e Gesto de
Conhecimento em MPS
Mdulos temticos do programa
Aprendi-
zagem
130
As fases que compem o modelo cclico da Figura 6.1 podem ser descritas da se-
guinte forma:
i. Diagnstico: envolve a gerao de informao vlida e til sobre aspectos
reais da organizao e das aes dos profissionais de MPS, que podero
subsidiar os temas focados em cada mdulo do programa.
ii. Planejamento: planejamento dos elementos que comporo a etapa ao:
seleo de artigos e textos para o mdulo; definio e preparao de semi-
nrios; definio de outras aes como, por exemplo, pesquisas diagnsti-
cas a serem conduzidas pelos participantes.
iii. Ao: pode ser composta de atividades como:
Leituras dirigidas (Artigos, Captulos de Livros e Vdeos) individuais
ou de estudo em grupo.
Seminrios peridicos, constitudos de:
Exposies tericas (dos facilitadores, dos participantes, ou de pa-
lestrantes convidados);
Quando aplicvel, vdeos e filmes que ilustrem temas estudados;
Discusses em grupo de textos e vdeos com contextualizao em
MPS e na organizao;
Estudos de caso em situaes de interveno em MPS;
Avaliaes da aprendizagem dos seminrios e aes do programa.
Pesquisas diagnsticas a serem conduzidas pelos participantes sobre o
programa de MPS em curso na organizao.
Orientao individual e coletiva nas atividades primrias de interven-
o, feitas por facilitadores experimentados em teoria de intervenven-
o, com base em:
Relatos de situaes de MPS;
Observao participante com base em protocolos de observao, de
situaes de MPS, tais como: diagnsticos, revises de processos,
auditorias, concepo de planos de melhorias em processos, discus-
ses tcnicas.
iv. Avaliao
131
Envolve a sistematizao da aprendizagem gerada segundo os participan-
tes, e avaliao de pontos fortes, dificuldades e sugestes prticas de me-
lhorias ao programa.
6.2.1.2 Estimativa de Recursos Humanos e Logsticos Necessrios ao Programa
Um programa como o aqui proposto requer a observao de alguns requisitos fun-
damentais. Dentre estes podemos destacar como principais:
i. Apoio de facilitadores para conduo do programa, com conhecimento e
experincia nos temas:
teorias de ao e de interveno (Argyris, 1970; Argyris e Schn 1974),
Cincia da Ao (Argyis e outros, 1985), aprendizagem organizacional
(Argyris e Schn, 1996), e reflexo-em-ao (Schn, 1983 e 1987). Este
um requisito fundamental;
outras teorias complementares como: pensamento sistmico (Senge,
2001), aprendizagem ao (Revans, 1998, citado por Brjesson, 2006),
gesto de conhecimento (Nonaka e Takeuchi, 1995, citados por
Brjesson, 2006). Este um requisito desejvel;
fundamentos de MPS e engenharia de software. Este um requisito til;
ii. Sistema de informao de apoio interveno e gesto de conhecimento,
com recursos como: lista de discusses, elaborao de pesquisas, repositrio
de arquivos. Existem diversas ferramentas j disponveis no mercado que
podem se prestar a este papel. Em termos especficos de MPS, Rocha e ou-
tros (2005) descrevem, por exemplo, uma aplicao de software voltada pa-
ra apoio a intervenes de MPS que poderia ser utilizada numa experincia
deste tipo.
iii. Ambiente fsico adequado para realizao de seminrios e discusses coleti-
vas.
iv. Disponibilidade de tempo especfico para atividades do programa pelos par-
ticipantes - mnimo de: 16 horas mensais para realizaes de seminrios;
cerca de quatro horas semanais de estudo individual, ao longo de cerca de
24 meses de programa. Deve-se ressaltar que esta durao sugerida uma
estimativa. Tendo em vista que um programa deste tipo deveria ir alm da
132
aprendizagem puramente cognitiva, dependendo de seus objetivos dos parti-
cipantes e do quo longe eles quiserem ir em aprofundar a compreenso e
melhoria de sua teoria-em-uso, com base em Argyris (1970, Captulo 6),
pode-se afirmar que este tempo pode ser bastante insuficiente.
6.2.1.3 Outras Consideraes sobre a Proposta de Desenvolvimento de Competncias
Com a execuo de um programa de desenvolvimento de competncias como o
aqui proposto, espera-se os seguintes benefcios adicionais:
Melhoria da capacidade de reflexo em ao dos profissionais, gerando maior
conscincia dos agentes de sua causalidade pessoal no ambiente e nas aes
do programa de MPS.
Aes de MPS mais eficazes em mdio e longo-prazo, em virtude de:
o Melhoria da competncia em interveno dos profissionais de MPS.
o Maior produtividade e eficcia na relao entre profissionais de MPS e de-
senvolvedores de software.
o Melhoria da interao entre os prprios desenvolvedores por influncia dos
facilitadores da aprendizagem.
Embora no se possam mensurar precisamente os ganhos de habilidades dos in-
tervenientes, podem ser estabelecidos indicadores qualitativos que reflitam a influncia do
programa nas aes de MPS conduzidas pelos participantes da interveno, nos moldes apre-
sentados por Brjesson (2006).
Vale ressaltar que, quanto experimentao desta proposta em um caso real, h
duas dificuldades bsicas que a tornam pouco vivel para aplicao no escopo desta disserta-
o:
i. Requer um grupo de profissionais de MPS que compreenda esta proposta e
se disponha a participar do estudo de caso, o que poderia ser demorado para
obter.
ii. Devido natureza da proposta (que gira em torno da compreenso e modi-
ficao da teoria de interveno dos participantes por eles prprios), o tem-
po requerido para realizao do experimento e coleta de dados tende a ser
longo em relao ao escopo de tempo disponvel para a dissertao.
133
6.3 OUTRAS PRESCRIES DE CARTER REESTRUTURADOR DO PROCES-
SO DE MPS
Na Seo 5.4 desta dissertao, ao abordar questes relativas influncia do para-
digma da racionalidade tcnica em MPS, foi argumentado que este paradigma, influenciado
pelo padro de teoria-em-uso de Modelo I (que voltada para o controle unilateral), pode
induzir dois fenmenos:
A separao de papis em termos de especialistas (exercido pelos interve-
nientes) que tendem a assumir um papel ativo e praticantes que tendem a
assumir um papel passivo. Em MPS o papel de especialista tende a ser as-
sumido por engenheiros de processos que de certa forma programam os
processos a ser usados pelos praticantes (os desenvolvedores de software).
A separao em termos de tempo e espao entre o design dos processos e
seu uso efetivo. O design dos processos tende a ser uma atividade de reta-
guarda distante do uso efetivo destes.
Argumentou-se que, em ambos os casos, a aprendizagem e gerao de conheci-
mento so desfavorecidas. As prescries apresentadas nas sees a seguir envolvem o trata-
mento destas questes buscando reduzir estes problemas. Por sua vez estas prescries favo-
recem o tratamento dos questionamentos feitos no incio deste captulo na medida em que
ajudam a estruturar um processo de MPS com maior probabilidade de gerao de informao
vlida e til sobre os problemas.
6.3.1 Reviso dos Papis dos Intervenientes e Desenvolvedores de Software: Afinal
MPS um Problema de Quem?
Com base nas informaes geradas na pesquisa desta dissertao sobre os proble-
mas encontrados no processo de melhorar processos de software, uma fonte de dificuldades
pode estar no enquadramento do papis exercidos pelos profissionais de MPS e pelos desen-
volvedores de software. De acordo com o identificado nos relatos e com pesquisas de outros
autores observou-se a tradicionalmente este papel exercido de forma que os profissionais de
MPS (engenheiros da qualidade, engenheiros de processos, SQAs) em maior ou menor grau,
tendem a atuar como programadores de processos, alm de auditores destes mesmos pro-
cessos. Por sua vez, os desenvolvedores tendem a atuar como usurios dos processos e tm
seu trabalho periodicamente auditado pelos engenheiros da qualidade.
134
Por esta concepo, melhorar processos de software tende a ser vista como uma
funo dos profissionais de MPS. Por outro lado, a melhoria de processos uma atividade que
afeta diretamente o trabalho dos desenvolvedores. Nesta situao, conforme argumentado
anteriormente no Captulo 4, na Seo 4.2.2:
i. Dificilmente os desenvolvedores deixaro de ter seu sentimento de compe-
tncia em relao ao seu trabalho, afetado pelas aes de melhoria;
ii. Eles podero ver seu nvel de escolha livre reduzido em relao a como e-
xecutar o seu trabalho;
iii. Eles tendero a rejeitar os processos formalmente estabelecidos quando es-
tes se distanciarem do seu conhecimento tcito enquanto desenvolvedores
(ver Seo 5.2.4.1).
Ainda que em muitos casos constatados na pesquisa desta dissertao, os grupos
de ao de melhorias (SEPGs) contem com a participao de desenvolvedores, esta participa-
o costuma ser limitada, restando maior parte dos desenvolvedores o papel de usurios dos
processos. Alm disso, permanece a concepo bsica de que a responsabilidade pelas inicia-
tivas de melhoria de processos pertence rea de qualidade. Como conseqncia, previsvel
que o comprometimento dos desenvolvedores com as aes de melhoria possa ser afetado
negativamente e sua relao com os profissionais de MPS possa ser conflituosa em algum
nvel.
Uma premissa bsica para modificao deste cenrio a de que os profissionais
de MPS assumam a funo de intervenientes nos moldes do que est descrito no Captulo 4,
seo 4.8 (O Papel dos Intervenientes) desta dissertao. Isto , sua ao deveria estar vol-
tada prioritariamente para as atividades primrias de interveno (gerao de informao vli-
da e til, escolha livre e informada, comprometimento interno, e monitoramento da
implementao das decises). Os desenvolvedores, por sua vez, deveriam assumir maior
responsabilidade pelas iniciativas de melhorias em si. Nesse caso, uma estratgia de ao
fundamental deveria ser a de aumentar a competncia dos atuais profissionais de MPS na
conduo de atividades primrias de interveno conforme previsto na seo 6.2 deste
captulo. A Figura 6.2 a seguir, cuja concepo fortemente influenciada pela proposta de
Aaen (2002 e 2003) resume a transformao necessria.
135

Figura 6.2: Revisando o enquadramento dos papis em MPS
6.3.1.1 Detalhamento da Viso Desejada: o Papel dos Profissionais de MPS
De acordo com a proposta da Figura 6.2, os engenheiros da qualidade deveriam
atuar muito mais como mentores e facilitadores da aprendizagem organizacional em MPS sob
a demanda dos desenvolvedores do que propriamente como os responsveis pelas iniciativas
de melhoria. Como facilitadores da aprendizagem seus requisitos bsicos devem ser a compe-
tncia nas atividades primrias de interveno: gerar informao vlida e til; gerar escolha
livre e informada; gerar comprometimento interno; e monitorar a implementao das decises
de MPS. Devem ser capazes de acionar estas atividades primrias para, em relao ao esforo
de MPS, conduzir atividades junto aos desenvolvedores no sentido de:
Diagnosticar os problemas dos processos e das equipes de desenvolvimento;
Fazer emergir alternativas de aes de melhoria a partir dos prprios desen-
volvedores;
Estabelecer conjuntamente com os desenvolvedores meios de monitorar as a-
es de melhoria.
No desempenho das atividades acima, os profissionais de MPS, idealmente, de-
vem ser capazes de se comportar na direo do Modelo II de teoria-em-uso, conforme referido
no Captulo 4, Seo 4.7.3, de forma que possam ser uma referncia de eficcia para o restan-
te do grupo na construo de ambiente de aprendizagem organizacional produtiva.
Tomam as iniciati-
vas pelas melhorias.
So fornecedores
de conhecimento.
So auditores de
processos.
So usurios de
processos.
Ocasionalmente
participam de
SEPGs.
Responsabilidade na
conduo de MPS
Fraca
Forte

Agem sob demanda
como mentores.
So facilitadores da
aprendizagem.
So gestores de
conhecimento.
So donos dos
processos.
Tomam as iniciati-
vas pelas melhorias.

Intervenientes
(SQEs)
Desenvolvedores
de Software
PAPIS VISO TRADICIONAL VISO DESEJADA
136
Como mentores em melhoria de processos eles devero ser tambm manter-se
tecnicamente competentes em engenharia de software e MPS a fim de que possam melhor
dialogar e ajudar os desenvolvedores em questes instrumentais objetivas do processo de
software. Porm este conhecimento tcnico deve ser prioritariamente acionado para dar supor-
te s atividades primrias de interveno e no necessariamente para tomar a iniciativa pelas
melhorias em si. Como gestores de conhecimento em MPS os engenheiros da qualidade deve-
riam manter um sistema de informaes de processos para conter histrico de itens como:
documentos de descrio de processos usados nos diversos projetos, registro de lies apren-
didas, registro de avaliao e diagnstico dos processos, dificuldades e pontos fortes encon-
trados pelos diversos atores envolvidos no esforo de MPS. Este sistema de informaes deve
servir de apoio s aes de melhoria por parte dos desenvolvedores e profissionais de MPS.
Os profissionais de MPS devem tambm atuar como facilitadores para que este conhecimento
flua na organizao.
6.3.1.2 Detalhamento da Viso Desejada: O Papel dos Desenvolvedores

Os desenvolvedores em seus diversos papis (gerentes de projeto, analistas de sis-
temas, engenheiros de software entre outros) devem ser vistos como os donos do processo
de software considerando as reas especficas do processo definido (gerncia de projeto, ge-
rncia de requisitos, de configurao, entre outras). Os problemas de desempenho dos proces-
sos devem ser vistos como problemas dos desenvolvedores, cuja resoluo depende destes
com a ajuda dos profissionais de MPS. Os lderes de desenvolvimento e suas equipes devem
tomar as iniciativas de MPS, contando para isso com a facilitao e mentoria dos profissionais
de MPS. As aes de MPS devem ser conduzidas de forma tal que todos os desenvolvedores
participem tanto quanto possvel. Provavelmente, isto poder ser melhor realizado se estas
aes forem exercidas em nvel de projetos, ou de equipes de desenvolvimento especficas.
Isto , o estabelecimento e melhoria dos possessos ter mais chance de ser participativo e con-
sequentemente contar com maior comprometimento dos profissionais se for realizado numa
abordagem bottom-up a partir das equipes. A generalizao, documentao e difuso do co-
nhecimento gerado entre as equipes deveria ficar a cargo dos profissionais de MPS.
137
6.3.2 Tornando o Processo de MPS mais Integrado Execuo dos Processos de Soft-
ware
Com base em Aaen (2002 e 2003) sugere-se que: (1) o desenvolvimento e uso do
processo de software seja integrado e seja tambm da responsabilidade dos usurios dos pro-
cessos; e (2) que o processo de software seja reconhecido como conhecimento e competncia
detidos principalmente por seus praticantes em vez de armazenados simplesmente em arte-
fatos descritivos. Influenciado pelas idias de Weick (1993, citado por Aaen, 2002 e 2003),
Aaen prope o que denominou de MPS pelo usurio final na qual: (a) MPS seja visto como
atividades em curso (em vez de especificaes complexas de natureza estrutural); (b) que a
responsabilidade pela concepo do processo seja dispersa entre desenvolvedores e designers
de processos, e (c) processos de software deveriam ser simples e abertos interpretao como
uma receita de alto nvel em vez de manuais detalhados. De acordo esta abordagem, mtodos
de MPS deveriam conter as seguintes caractersticas:
Utilizar abordagens que busquem o estabelecimento do processo de soft-
ware no nvel do grupo. Nesse sentido Aaen cita como exemplo o Team
Software Process (CMU/SEI, 2006
d
) e a eXtremme Programming (Beck,
1999) como abordagens em que os desenvolvedores exercem um papel
chave no estabelecimento do processo e nos quais os processos so estabi-
lizados e modificados atravs de interaes no grupo.
Usar especialistas como mentores e conselheiros. A responsabilidade pri-
mria pelo desenvolvimento dos processos de seus usurios, porm os
profissionais de MPS tm o papel fundamental de mentores e de difuso
das idias pela organizao.
Ver os processos como uma receita aberta improvisao. Os processos
devem ser emergentes ao contexto em que sero usados desde que respei-
tados requisitos de alto nvel estabelecidos em nvel de grupo e da organi-
zao.
Melhorar primeiro, modelar o resultado depois. Significa documentar o
que os usurios fazem enquanto fazem. Documentar o que foi feito e no o
que dever ser feito no futuro.
Menos estrutura vai mais longe. Definir apenas os elementos essenciais
de processo em vez do processo completo. Considerar o uso de processos
simples e flexveis por pessoas competentes e motivadas.
138
Usar processos de avaliao contnuos e encaixados no nvel dos projetos.
Feedback sobre pontos fortes e fracos dos processos so essenciais.
A abordagem de Aaen (2002 e 2003), aqui apresentada resumidamente, revela-se
interessante e em consonncia com a linha de interveno proposta nesta dissertao. Todavia
deve ser ressaltado que as prescries feitas por aquele autor nos referidos artigos permanece-
ram num nvel conceitual no tendo sido testadas por ocasio daquelas publicaes. Durante a
composio desta dissertao no foram encontrados trabalhos deste autor relatando experi-
mentos nesta direo.
6.4 COMENTRIOS FINAIS AO CAPTULO
Este captulo buscou identificar algumas recomendaes de estratgias de ao di-
recionadas ao tratamento dos problemas de MPS apresentados no captulo anterior sob a tica
das teorias de Argyris e Schn. Ressalte-se que estes problemas devido sua natureza e com-
plexidade no so necessariamente resolvveis em sua plenitude, mas podem ser amplamente
reduzidos. As prescries se direcionam para que o tratamento destes problemas seja um pro-
cesso gerador de aprendizagem e competncia para as equipes que promovem MPS e que
praticam os processos estabelecidos. A prescrio de um programa de desenvolvimento de
competncias de interveno para profissionais de MPS leva em conta o papel central dos
profissionais de MPS como intervenientes e como potenciais irradiadores de uma postura efi-
caz frente aos problemas ressaltados no Captulo 5.
A realizao prtica destas prescries, particularmente a proposta de desenvol-
vimento de competncias de interveno para profissionais de MPS, feita na Seo 6.2, tende
a ser uma experincia de longa durao. Numa viso que busque solues em curto-prazo isto
pode ser visto como um aspecto negativo. Todavia, deve ser ressaltado que, neste critrio de
tempo, elas so compatveis com a aplicao de modelos normativos de MPS como o CMMI,
MPS.Br e outros, cuja implantao tende a durar vrios anos e requerem manuteno perma-
nente mesmo depois de finda a interveno. A crena do autor desta dissertao de que a
realizao concomitante destas prescries com a implantao de modelos normativos de
MPS pode no s ajudar na conduo deste tipo de iniciativa como tambm ser um processo
de ampla aprendizagem e gerao de conhecimento para o prprio campo de MPS. Ressalte-
se que estas prescries podem vir a ser teis mesmo em intervenes de MPS j em anda-
mento.
139

7 CONCLUSO E TRABALHOS FUTUROS
Partindo de depoimentos colhidos atravs de pesquisa qualitativa com profissio-
nais que estiveram envolvidos com iniciativas de MPS em empresas de Recife, Brasil, com o
apoio das teorias de interveno do cientista social Chris Argyris e seu principal colaborador
Donald Schn, esta dissertao buscou mostrar que:
i. A maior parte dos problemas de MPS relatados pelos profissionais pouco
vinculada a questes tcnicas de engenharia de software. Esta viso est em
consonncia com pesquisas de outros autores da rea de MPS citados nesta
dissertao.
ii. As iniciativas de MPS so uma forma de interveno nas organizaes, e os
modelos normativos utilizados em MPS podem ser vistos so teorias de inter-
veno, de acordo com o conceito proposto por Argyris.
iii. Fatores crticos em MPS frequentemente relatados como: falta de comprome-
timento dos envolvidos, falta de conscincia e entendimento dos benefcios
e exigncias de MPS, falta de objetivos claros e alinhados, conflitos orga-
nizacionais e muitos outros podem ter raiz em fatores sobredeterminantes
como:
(a) Incongruncia das normas do sistema organizacional (sobretudo as normas
tcitas) com os objetivos de mudana propostos pela interveno de MPS;
(b) Baixa capacidade dos atores em lidar de forma produtiva com situaes
conflitivas de iniciativas de MPS. Nisto, tm papel fundamental as defici-
ncias da teoria de interveno dos profissionais de MPS que conduzem a
iniciativa, quando no enfatizam suficientemente as atividades primrias de
interveno junto aos demais participantes da interveno. Estas atividades
primrias so:
1. gerao de informao vlida e til,
2. gerao de escolha livre e informada,
3. gerao de comprometimento interno dos participantes, e
4. monitoramento da implementao das decises.
140
(c) Teorias-em-uso tanto de profissionais de MPS como de desenvolvedores de
software, que tendem ao controle unilateral das tarefas e do ambiente. Des-
ta forma, dificultam o enfrentamento produtivo das situaes problemti-
cas, dificultando assim a aprendizagem coletiva e a melhoria da competn-
cia da organizao para resolver seus problemas.
(d) Abordagens que enfatizam exclusivamente aspectos tcnicos e instrumen-
tais de MPS e engenharia de software. Estas abordagens por serem condu-
zidas sob a influncia de estratgias de ao de controle unilateral da inter-
veno desfavorecem um dilogo mais amplo e mais prximo entre enge-
nheiros de processos e desenvolvedores e favorecem os conflitos entre eles.
Estas abordagens so influenciadas pela formao destes profissionais que
tende a ser exclusivamente tcnica.
Aps aprofundar a compreenso dos problemas de MPS nestes termos, a disserta-
o buscou tambm prescrever diretrizes de ao coerentes com esta compreenso de forma a
tratar estes problemas. As prescries foram:
i. Conduzir pesquisa-ao com os principais interessados no processo de
MPS (profissionais de MPS, desenvolvedores de software e alta-
administrao) com o objetivo de:
o Aumentar o nvel de conscincia destes atores sobre: os problemas,
benefcios e exigncias de programas de MPS.
o Desenvolver uma viso sistmica de como estes problemas podem es-
tar interconectados no contexto da organizao.
o Promover a clareza e alinhamento entre objetivos da organizao e ob-
jetivos da iniciativa de MPS, possibilitando aes corretivas conscien-
tes sobre rumo da iniciativa de MPS, quando necessrio.
ii. Implementar um programa de desenvolvimento de habilidades de interven-
o para profissionais de MPS, a ser conduzido num formato combinado de
treinamento e pesquisa-ao.
iii. Realizar mudanas na forma tradicional do processo de MPS, quanto a:
o Papis dos profissionais de MPS e desenvolvedores: buscando enfati-
zar os primeiros como intervenientes facilitadores da aprendizagem,
mentores e disseminadores de conhecimento, e estes ltimos como ge-
radores de conhecimento e melhoradores de seus prprios processos.
141
o Buscar aproximar tanto quanto possvel atividade de melhoria da apli-
cao propriamente dita dos processos, enfatizando estes processos en-
quanto definies em nvel macro a serem adaptadas por equipes de
desenvolvimento, em vez de descries detalhadas. Esta abordagem
pressupe equipes de desenvolvimento competentes e conscientes de
seu papel quanto MPS.
7.1 PRINCIPAIS CONTRIBUIES DA DISSERTAO
As principais contribuies desta dissertao so:
i. A utilizao, de certa forma indita, da teoria de interveno e conceitos re-
lacionados dos cientistas sociais Chris Argyris e Donald Schn para inter-
pretao dos problemas scio-tcnicos de intervenes de MPS e prescri-
o de aes para tratamento destes problemas
69
.
ii. A realizao de uma pesquisa qualitativa com anlise temtica e de conte-
do dos relatos de entrevistados, sobre os problemas de MPS em empresas
da cidade do Recife, Brasil
70
.
Na crena do autor desta dissertao o primeiro item acima o mais importante
pelo potencial que esta teoria tem de aplicao no campo de MPS. Pelo volume crescente da
indstria de software na economia mundial e as atuais altas taxas de falha tanto de projetos de
software como tambm de programas de MPS, a ajuda desta teoria parece ser relevante para
uma conduo mais eficaz deste tipo de iniciativa. Neste aspecto, uma reflexo a ser conside-
rada diz respeito a que os problemas scio-tcnicos abordados nesta dissertao certamente
no fazem parte das preocupaes clssicas dos pesquisadores e praticantes da engenharia
de software. Todavia, levando-se em conta que: projetar, desenvolver e implantar sistemas
envolve muitos aspectos sociais, sobretudo em projetos complexos e com equipes grandes,
estes problemas tero sempre importncia fundamental se estes profissionais pretendem reali-
zar estas atividades de maneira eficaz nas organizaes.

69
At a finalizao desta dissertao, apesar de encontrar algumas referncias a Argyris e Schn na literatura
mundial de MPS, o autor desta no encontrou nenhuma que abordasse temas de teorias de interveno e teo-
rias de ao conforme aqui apresentado.
70
At a finalizao desta dissertao, seu autor no encontrou publicaes sobre pesquisa metodologicamente
semelhante neste tema nem em Recife nem no Brasil, nas propores aqui apresentadas.
142
Quanto segunda contribuio anteriormente citada, ela ganha importncia pelo
fato do Recife ser atualmente um dos maiores plos de desenvolvimento de software do Brasil
e tambm de iniciativas de MPS. Esta pesquisa, portanto, traz luz aos problemas de MPS en-
contrados nesta regio. Ainda sobre esta pesquisa qualitativa, o emprego de arqutipos sist-
micos para fazer sentido da dinmica de inter-relaes dos problemas encontrados parece ser
tambm indito na literatura de MPS.
Em certo sentido, a aproximao de conhecimentos vindos da rea de engenharia
de software com outros vindos das cincias sociais aplicadas contribui como um estmulo
gerao de mais pesquisas semelhantes com potencial de trazer resultados relevantes. A inter-
disciplinaridade das pesquisas pode ser um fator importante de gerao de conhecimento em
MPS.
7.2 PRINCIPAIS DIFICULDADES E LIMITAES ENCONTRADAS
A aplicao das teorias de Argyris e Schn, que tradicionalmente usada no cam-
po de desenvolvimento organizacional e aprendizagem organizacional abrangente, para o
campo de MPS, revelou-se bastante desafiadora por dois motivos:
H pouca disponibilidade de trabalhos semelhantes em MPS, consequente-
mente,
Ausncia de outros pesquisadores acadmicos em MPS com objetivos seme-
lhantes, com os quais dialogar.
Por conta disto, e tendo em vista a vasta produo acadmica daqueles autores
(sobretudo Argyris) foi particularmente desafiador para o autor desta dissertao, a determi-
nao do nvel de abrangncia e profundidade da abordagem terica em relao ao escopo de
recursos, tempo disponvel e objetivos da dissertao.
Outro aspecto dificultador diz respeito a limitaes para aplicao experimental
da abordagem terica ao escopo de uma dissertao de mestrado, tendo em vista que, pela
prpria natureza dos problemas tratados, seria necessrio longo tempo para desenvolvimento
de experimentos. Alm disso, estes experimentos necessitariam de casos reais de organizaes
e profissionais dispostos e comprometidos em embarcar em uma interveno real, cuja natu-
reza certamente fora dos padres de intervenes de MPS atualmente contratadas pelas or-
ganizaes. Isto requereria um trabalho extra de convencimento por parte dos pesquisadores a
fim de obter as oportunidades de estudos de caso.
143
7.3 OPORTUNIDADES PARA TRABALHOS FUTUROS
A aplicao das prescries previstas no Captulo 6 desta dissertao, desde que
com tempo e oportunidades reais disponveis, provavelmente seria uma enorme fonte de gera-
o de conhecimento sobre intervenes de MPS, com grandes possibilidades para pesquisa
acadmica, e resultados teis para a prpria indstria de software.
Todavia, vale ressaltar que, entre outras possibilidades, as teorias de Argyris e
Schn so tambm potencialmente teis em Engenharia de Software em pelo menos trs as-
pectos:
i. Aplicao em pesquisa e interveno sobre problemas scio-tcnicos de
engenharia de requisitos e implantao de sistemas.
ii. Anlise da teoria de prtica que est subjacente aos ditos mtodos geis
de desenvolvimento, em comparao com mtodos pesados.
iii. Aplicao em pesquisas sobre educao profissional em Engenharia de
Software.
iv. Aspectos humanos e sociais da gerncia de projetos de software.
Particularmente sobre o primeiro tpico acima, Kotonya e Sommerville (1997)
afirmam que processos de Engenharia de Requisitos so dominados por fatores humanos,
sociais e organizacionais, pois sempre envolvem interao de pessoas oriundas de diferentes
domnios profissionais e com metas pessoais e organizacionais distintas. De maneira seme-
lhante, Jirotka e Goguen (1994) afirmam que o aspecto social possui uma importncia bvia
em design e desenvolvimento de sistemas, j que o processo de requisitos acontece numa or-
ganizao, sistemas computacionais so usados em organizaes, e o processo de requisitos
em si social pela necessria interao entre diferentes grupos de pessoas. Portanto, a enge-
nharia de requisitos precisa ser sensvel a como as pessoas percebem e entendem o mundo que
as cerca, como elas interagem, e como isto afeta suas aes. Nuseibeh e Easterbrook (2000)
endossam esta viso ao afirmarem que as cincias cognitivas e sociais tm contribuies rele-
vantes para o embasamento da prtica em engenharia de requisitos. Em termos das teorias
vistas nesta dissertao, assim como MPS, o processo de engenharia de requisitos tambm
poderia ser visto como uma interveno na qual as atividades primrias de gerao de infor-
mao vlida e til, escolha livre e informada, e gerao de comprometimento interno podem
ser muito relevantes para os problemas enfrentados nesta rea.
Sobre a comparao da teoria de prtica dos mtodos geis versus mtodos
pesados, sabe-se que os primeiros proclamam fortemente a dependncia do elemento huma-
144
no da realizao dos processos, sem rigidez de papis. J os ltimos so mais centrados em
aspectos documentais e de artefatos do processo, determinando tambm papeis muito distin-
tos. Utilizar a teoria de Argyris e Schn para avaliar comparativamente como estas caracters-
ticas afetam de fato a possibilidade de gerao de informao vlida, escolha livre e compro-
metimento interno na equipe, pode ser uma fonte de gerao de conhecimento e de aperfeio-
amento dos mtodos.
Sobre questes de educao profissional em engenharia de software as teorias de
Argyris e Schn, e mais particularmente deste ltimo, poderiam tambm trazer amplas e rele-
vantes contribuies (vide Schn, 1983 e 2000). Esta mesma dissertao abordou, ainda que
introdutoriamente, problemas neste campo, cuja anlise poderia ser estendida em pesquisas
mais profundas.
Sobre gerncia de projetos, o tratamento de muitos aspectos da gerncia de equi-
pes pode ser beneficiado com as noes de teoria de interveno, teorias de ao e aprendiza-
gem organizacional. Em muitos casos, projetos, de uma maneira geral, podem se enquadrar no
conceito de interveno na organizao, pelo fato de que, de acordo com seu prprio conceito
(PMI, 2000), buscarem o atingimento de objetivos especficos e nicos em prazos determina-
dos, geralmente para melhorar aspectos da organizao.
At onde o autor desta dissertao pde identificar em pesquisas bibliogrficas
exploratrias a aplicao das teorias de Argyris e Schn nestas reas poderia redundar em
muitas contribuies acadmicas inditas.
145
8 REFERNCIAS BIBLIOGRFICAS
Aaen, I. Challenging Software Process by Design. Proceedings of ECIS 2002 The Xth Euro-
pean Conference on Information Systems, 2002.
Aaen, I. Software Process Improvement: Blueprints versus Recipes. IEEE Computer Soci-
ety, 2003.
Abrahamsson, P. Commitment Development in Software Process Improvement: Critical
Misconceptions. IEEE Proceedings of the 23rd International Conference on Software
Engineering, 2000.
Abrahamsson, P. e Iivari, N. Commitment in Software Process Improvement In Search of
the Process. IEEE - Proceedings of the 35th Annual Hawaii International Conference
on System Sciences, 2002.
Ahern, D. M., Clouse, A. Turner, R. CMMI

Distilled: A Practical Introduction to Inte-

grated Process Improvement. Addison Wesley, segunda edio, Setembro de 2003.
Argyris, C. Intervention Theory. A Behavorial Science View. Addison-Wesley, 1970.
Argyris, C. Enfrentando Defesas Empresariais. Facilitando o Aprendizado Organizacional.
Editora Campus, 1992.
Argyris, C. Reasons and Rationalizations. The Limits to Organizacional Knowledge. Oxford
University Press, 2004.
Argyris, C. e Schn, D. A. Theory in Practice. Increasing Professional Effectiveness.
Jossey-Bass Publishers, 1974.
Argyris, C. e Schn, D. A. Organizational Learning. A Theory of Action Perspective. Addi-
son Wesley, 1978.
Argyris, C. e Schn, D. A. Organizational Learning II. Theory, Method, and Practice. Ad-
dison Wesley, 1996.
Argyris, C.; Putnam, R. e Smith, Diana M. Action science - Concepts, Methods, and Skills
for Research and Intervention. Jossey-Bass Inc. Publishers, 1985
Baddoo, N.; Hall, T. De-motivators for software process improvement: an analysis of prac-
tioners views. The Journal of Systems and Software, 66/23-33, 2003.
Baddoo, N.; Hall, T. Software Process Improvement Motivators: An Analysis using Multi-
dimensional Scaling. Empirical Software Engineering - Springer, 2002.
Baskerville, R. L. Investigating Information Systems with Action Research. Communica-
tions of the Association for Information Systems (AIS), Volume 2, Artigo 19, 1999.
146
Beck, K. e outros. The Agille Manifesto. 2001. Disponvel em: http://agilemanifesto.org/ (l-
timo acesso em: 13/07/2006).
Beck, K. Extreme Programming Explained. Addison-Wesley, 1999.
Brjesson, A. Improve by improving software process improvers. International Journal in
Business Information Systems, Vol. 1, N 3, 2006.
Button, G. e Sharrock, W. Occasioned practices in the work of software engineers. Em Ji-
rotka, M. e Goguen, J. Requirements Engineering Social and Technical Issues. A-
cademic Press, 1994.
Campos, V. F. TQC: Controle da Qualidade Total (no estilo japons). Fundao Cristiano
Ottoni, 6 Edio, 1992.
CMU/SEI(a). Process Maturity Profile CMMI v1.1 / SCAMPI
SM
v1.1 Class A Appraisal
Results 2005 End-Year Update. Maro de 2006. Carnegie Mellon University
Software Engineering Institute. Disponvel em http://www.sei.cmu.edu/appraisal-
program/profile/pdf/CMMI/2006marCMMI.pdf (ltimo acesso: 11/06/2006).
CMU/SEI(b). Process Maturity Profile Software CMM - 2005 End-Year Update. Maro de
2006. Disponvel em http://www.sei.cmu.edu/appraisal-program/profile/pdf/SW-
CMM/2006marSwCMM.pdf (ltimo acesso: 11/06/2006).
CMU/SEI(c). Personal Software Process (PSP). Carnegie Mellon University Software En-
gineering Institute. Disponvel em: http://www.sei.cmu.edu/tsp/psp.html (ltimo a-
cesso em 13/07/2006).
CMU/SEI(d). Team Software Process (TSP). Carnegie Mellon University Software Engi-
neering Institute. Disponvel em: http://www.sei.cmu.edu/tsp/tsp.html (ltimo acesso
em 13/07/2006).
CMU/SEI. Appraisal Requirements for CMMI
SM
, Version 1.1 (ARC, V1.1). Relatrio Tcni-
co. Carnegie Mellon University Software Engineering Institute, Dezembro de
2001. Disponvel em:
http://www.sei.cmu.edu/publications/documents/01.reports/01tr034.html (ltimo a-
cesso em 13/07/2006).
CMU/SEI. Capability Maturity Model Integration (CMMI
SM
),Version 1.1. CMMI
SM
for
Software Engineering - Staged Representation. Carnegie Mellon University
Software Engineering Institute, agosto de 2002.
CMU/SEI. CMMI Performance Results (reported as of December 15, 2005). Carnegie
Mellon University Software Engineering Institute. Disponvel em
http://www.sei.cmu.edu/cmmi/results.html (ltimo acesso: 11/06/2006).
CMU/SEI. Standard CMMI
SM
Appraisal Method for Process Improvement (SCAMPI
SM
),
Version 1.1: Method Definition Document. Carnegie Mellon University Software
Engineering Institute, Dezembro de 2001.
147
CMU/SEI. SW-CMM Maturity Profile March 2006. Carnegie Mellon University Software
Engineering Institute. Disponvel em http://www.sei.cmu.edu/appraisal-
program/profile/pdf/SW-CMM/2006marSwCMM.pdf (ltimo acesso: 11/06/2006).
Debou, C. e Kuntzmann-Combelles, A. Linking software process improvement to business
strategies: experiences from industry. Em, Software Process: Improvement and
Practice Volume 5, Issue 1. John Wiley & Sons, Ltd, 2000.
Dirio de Pernambuco. Negcios em busca de mais qualidade. Jornal Dirio de Pernambuco,
Edio de Quinta-Feira, 21 de Agosto de 2003. Disponvel em:
http://www.pernambuco.com/diario/2003/08/21/especialportodigital13_0.html (lti-
ma consulta em Dez, 2006).
Dyba, T. An Empirical Investigation of the Key Factors for Success in Software Process
Improvement. IEEE Transactions on Software Engeneering, Vol. 31, n 5, Maio de
2005.
Dyba, T. Enabling Software Process Improvement: An Investigation of The Importance of
Organizational Issues. Empirical Software Engineering, Vol. 7, pags. 387 a 390,
2002.
El Emam, K. Goldenson, D. McCurley e J. Herbsleb, J. Success or Failure? Modeling the
Likelihood of Software Process Improvement. International Software Engineering
Research Network, 1998.
Fahey, L. e Prusak, L. The Eleven Deadliest Sins of Knowledge Management. California
Management Review; Vol. 40, n 3; Spring, 1998.
Franco, M. L. P. B. Anlise do Contedo. Braslia, Lber Livro, 2 Edio, 2005.
Freitas, H.; Janissek, R. Anlise Lxica e Anlise de Contedo. Porto Alegre, Sphinx: Edito-
ra Sagra Luzzatto, 2000.
Fuggetta, A. Software Process: A Roadmap. The Future of Software Engineering, 2000.
Goguen, J. e Linde, C. Techniques for Requirements Elicitation. In Proceedings, Require-
ments Engineering '93, edited by Stephen Fickas and Anthony Finkelstein, IEEE
Computer Society, 1993.
Goldenson, D. e Herbsleb, J. After the Appraisal: A Systematic Survey of Process Improve-
ment, its Benefits, and Factors that Influence Success. Technical Report CMU/SEI-
95-TR-009, 1995.
Gremba, J. e Myers, C. The IDEAL
SM
Model: A Practical Guide for Improvement. Carnegie
Mellon University Software Engineering Institute, 1997. Disponvel em:
http://www.sei.cmu.edu/ideal/ideal.bridge.html#overview#overview (ltimo acesso
em 20/10/2006).
Humphrey, W. S. Managing the Software Process. Addison-Wesley Publishing Company,
Inc. 1989.
148
Humphrey, W. S. Three Process Perspectives: Organizations, Teams, and People. Annals of
Software Engineering 14, 3972, 2002. Kluwer Academic Publishers, 2002.
Iversen, J. H.; Mathiassen, L.; Nielsen, P. A. Managing Risk in Software Process Improve-
ment: an Action Research Approach. MIS Quarterly Vol. 28 No. 3, pags 395-433,
Setembro de 2004.
Jirotka, M. e Goguen, J. Requirements Engineering Social and Technical Issues. Academic
Press, 1994.
Kotonya, G. e Sommerville, I. Requirements Engineering Processes and Techniques. John
Wiley & Sons, 1997.
Kruchten, P. The Rational Unified Process: An Introduction. Addison Wesley Terceira
edio. Dezembro de 2003.
Lyytinen, K. e Robey, D. Learning failure in information systems development. Information
Systems Journal n 9, pags. 85-101, 1999.
Martin, R. L.; Archer, M. A. e Brill, L. Why do People and Organizations Produce the Op-
posite of What they Intend? Comissioned Paper for The Walkerton Inquiry, 2002.
Disponvel em: http://www.rotman.utoronto.ca/rogermartin/Walkerton.pdf (ltimo
acesso: 06/11/2006).
Mathiassen, L. Collaborative Practice Research. Scandinavian Journal of Information Sys-
tems, 14: 57-73, 2002.
Mathiassen, L. Reflective Systems Development. Scandinavian Journal of Information Sys-
tems, 10(1&2): 67-118, 1998.
Mathiassen, L.; Nielsen, P. A. Pries-Heje, J. Learning SPI in Practice. Em: Mathiassen, Lars;
Pries-Heje, Jan e Ngwenyama, O. Improving Software Organizations - From Princi-
ples to Practice. Addison-Wesley, 2002.
Morgan, G. Imagens da Organizao. So Paulo, Editora Atlas, 1996.
Niazi, M.; Wilson, D.; Zowghi, D. A maturity model for the implementation of software pro-
cess improvement: an empirical study. The Journal of Systems and Software xxx
(2003) xxxxxx, 2003.
Nuseibeh, B. e Easterbrook, S. Requirements Engineering: A Roadmap. The Future of Soft-
ware Engineering, 2000.

Oliveira , S. R. B.; Vasconcelos, A. M. L. de; Rouller, A. C. Uma Proposta de um Ambiente
de Implementao de Processo de Software. Infocomp Journal of Computer Sci-
ence, VOL.4, N.1, March, 2005.
Olson, T. Neal, R. Over, J. A Software Process Framework for the SEI Capability Maturity
Model. CMU/SEI-94-HB-01, 1994.
Paulk, M. C. Curtis, B. Chrissis, M. B. Weber, C. V. Capability Maturity Model
SM
for Soft-
ware, Version 1.1. Relatrio Tcnico, CMU/SEI-93-TR-024, Fevereiro de 1993.
149
Disponvel em:
http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.024.html (ltimo
acesso: 21/06/2006).
PMI. A Guide to the Project Management Base of Knowledge (PMBOK

Guide). Project
Management Institute (PMI), 2000.
Rainer, A. e Hall, T. Key success factors for implementing software process improvement: a
maturity-based analysis. Journal of Systems and Software, 2002.
Rational. Rational Unified Process Version 2003.06.12.01. Rational Software Corporation,
2003.
Richardson, R. J. Pesquisa Social Mtodos e Tcnicas. 3 Edio, So Paulo: Editora A-
tlas,1999.
Rico, D. F. Software process improvement: Modeling return on investment (ROI). Software
Engineering Institute (SEI) Software Engineering Process Group Conference (SEPG
2002), Phoenix, Arizona, 2002.
Rocha, A. R.; Montoni, M.; Santos, G.; Mafra, S.; Figueiredo, S.; Bessa, A. e Mian, P. Esta-
o TABA: Uma Infra-estrutura para Implantao do Modelo de Referncia para
Melhoria do Processo de Software. Anais do IV Simpsio Brasileiro de Qualidade
de Software (IV SBQS), Porto Alegre, 2005.
Santana, A. F. L. e Moura, H. P. de. Programas de Melhoria de Processos de Software: Re-
flexes sob a tica de uma Teoria de Interveno. Anais do IV Simpsio Brasileiro
de Qualidade de Software (IV SBQS), Porto Alegre, 2005.
Schn, D. A. Educando o Profissional Reflexivo. Um novo design para o ensino e a apren-
dizagem. Artes Mdicas Sul, 2000.
Schn, D. A. The Reflective Practioner. How Professionals Think in Action. Basic Books,
New York, 1983.
Senge, P. M. A quinta disciplina.A arte e prtica da organizao que aprende. So Paulo:
Best Seller, 2001.
Senge, P. M.; Kleiner, A.; Roberts, C.; Ross, R. e Smith, B.A quinta disciplina caderno de
campo: estratgias e ferramentas para construir uma organizao que aprende.
Rio de Janeiro: Qualitymark Ed., 1997.
Sheard, S. A. The Frameworks Quagmire, a Brief Look. Software Productivity Consortium,
1997. Disponvel em
http://www.software.org/quagmire/frampapr/FRAMPAPR.HTML (ltimo acesso:
15/06/2006).
Sheard, S.A. Evolution of the frameworks quagmire. IEEE Computer Volume 34, Issue 7,
Page(s):96 - 98, Jul 2001.
SPICE. Software Process Improvement and Capability dEtermination. Software Quality
Institute. http://www.sqi.gu.edu.au/spice/ (ltimo acesso em 17/03/2005).
150
Standish Group International Inc, The. Extreme Chaos. The Standish Group International,
Inc. 2001.
Stelzer, D.; Mellis, W. Success Factors of Organizational Change in Software Process Im-
provement. Software Process Improvement and Practice - doi.wiley.com., 1998.
Valena, A. C. Eficcia Profissional. Rio de Janeiro: Qualitymark, 1997.
Valena e Associados. Consultores em Ao. Uma Pesquisa sobre Aprendizagem Organiza-
cional. Valena e Associados / Edies Bagao, 1995.
Valena e Associados. Programa de Consultores Organizacionais na Perspectiva de uma
Comunidade de Prtica. Valena e Associados / Edies Bagao, 1997.
Valena e Associados. Pensamento Sistmico. 25 Aplicaes Prticas. Valena e Associados
/ Edies Bagao, 1999.
Weber, K. C.; Arajo, E.; Machado, C. A. F.; Scalet, D.; Salviano, C. F.; Rocha, A. R. C. da.
Modelo de Referncia e Mtodo de Avaliao para Melhoria de Processo de Soft-
ware verso 1.0 (MR-MPS e MA-MPS). IV Simpsio Brasileiro de Qualidade de
Software (SBQS). Porto Alegre, junho de 2005.
Woolgar, S. Rethinking requirement analysis: Some implications of recent research into
producer-consumer relationships in IT development. Em Jirotka, M. e Goguen, J.
Requirements Engineering Social and Technical Issues. Academic Press, 1994.

151
APNDICE A ROTEIROS DE ENTREVISTAS DA PESQUISA
Roteiro para Engenheiros da Qualidade

Pergunta Perguntas subsidirias
1. Uma breve descrio do programa e sua
participao (objetivos gerais / etapas /
marcos previstos)?
Durao do programa?
Tempo interno de dedicao?
2. De que forma se dava(d) a melhoria de
processos em si?
Quem tomava parte? Em que papis?
Quantas pessoas?
Como v a participao desses diversos
atores?
3. Como o processo de planejamento/ exe-
cuo/monitoramento do programa?
Quem participa das decises?
Existe algum processo formal tipo PM-
BOK?
Como a difuso de informaes do
programa?
H (havia) um processo peridico para
avaliao e documentao de lies a-
prendidas? Quem gera as L.As.? Quem
tem acesso?
4. Quais os pontos fortes e dificuldades mais
relevantes da experincia?
o Suas expectativas mudaram ao longo do
programa? (sim?) Em que termos? O que
o fez mudar?
o Que mudanas efetivas nos clientes in-
ternos, ocorreram ao longo do progra-
ma?
o E sobre o modelo CMMI em si?
5. Como voc percebe os fatores humanos
envolvidos no processo?
o Como voc se percebe lidando com estes
fatores?
o Voc participou de algum curso / forma-
o que voc acredita que lhe ajuda nes-
tas questes? Qual curso? Em que aspec-
tos ajuda?
o Pode dar um exemplo?
6. Se fosse recomear a experincia faria algo
de diferente? O que ?




7. O que ser um SQE / SQA na prtica? Qual o seu papel?
O que no seu papel?




152
Roteiro para os Consultores Externos em MPS

Pergunta Perguntas subsidirias
1. Como surgiu a idia de implantar do
CMM10/PSI-CMMI? Qual a motivao i-
nicial?
o Quem participou efetivamente da deci-
so? Quais os seus papis ?
o Por que o modelo CMM/CMMI? Foram
analisadas outras alternativas? Algum
usa o CMMI contnuo?
2. Como o planejamento e gerenciamento
global do programa?
o Foi adotado algum modelo de gerencia-
mento?
o Quem participa do gerenciamento glo-
bal?
3. Como sua participao?
4. Quais os pontos Fortes / Fracos da sua ex-
perincia no programa?
o Quais so as maiores dificuldades?
o E sobre o modelo CMMI em si?
5. Como v a influncia de fatores humanos
na experincia?

6. Qual sua viso sobre a desistncia de algu-
mas empresas? Que fatores tm sido mais
influentes?

7. H algum processo global de gerao/ do-
cumentao/ avaliao de Lies Aprendi-
das? H cooperao entre as empresas?
o Como so armazenadas as lies apren-
didas?
o Quem tem acesso?


Roteiro para Desenvolvedores / Analistas / Gerentes de Projeto:

Pergunta Perguntas subsidirias
1. Descreva sua experincia de Melhoria de
Processos de Software?
Em que momentos se dava a sua parti-
cipao?
Quem participa da definio dos proces-
sos?
Quem avalia?
2. Quais os pontos Fortes / Fracos da sua ex-
perincia no programa?
o Quais so as maiores dificuldades?
o E sobre os modelo CMMI (ou ISO) em
si?
3. Como v a influncia de fatores humanos
na experincia?
Como v o relacionamento entre as pes-
soas de diferentes papis, envolvidos no
programa?
Qual era seu nvel de motivao e de
seus colegas de equipe / empresa para
com esta experincia?
4. H algum processo global de gerao/ do-
cumentao/ avaliao de Lies Aprendi-
das? H trocas de idias entre as equipes?
o Como so armazenadas as lies apren-
didas?
o Quem tem acesso?
o Como so tratadas as dificuldades?
5. Se voc fosse um SQE conduzindo esse
processo, o que voc sugeriria como modi-
ficao?

Qual o papel de um SQE em sua opini-
o?
153
APNDICE B DETALHAMENTO DOS FATORES CRTICOS EM MPS ENCON-
TRADOS NA PESQUISA
B.1) Tempo e Recursos para MPS

Significado:
Tempo e recursos em termos financeiros, humanos, ferramentas, e Consultoria externa destinados MPS. Inclui
o apoio de programas governamentais de incentivo e fomento MPS que envolvendo financiamento de iniciati-
vas consorciadas de MPS. Insuficincia ou falta destes fatores.
Comentrio analtico:
Insuficincia de tempo e recursos para MPS foi o fator mais referido diretamente nas entrevistas enquanto bar-
reira ao programa de MPS. Quase todos os relatos incluram referncias presso de tempo sofrida pelas equi-
pes de desenvolvimento em relao a prazos de entrega para os clientes como sendo um obstculo para que
estas equipes possam cumprir os processos de software ou realizar aes de melhoria neles. Tambm bastante
referenciada a carncia de pessoas dedicadas ao trabalho nos SEPGs ou equipes de qualidade. Em geral alega-
se que a necessidade de sobrevivncia das empresas faz com que poucos recursos possam ser destinados para
MPS. Enquanto aspecto facilitador observou-se tambm a presena deste fator como sendo um dos mais signi-
ficativos que os relatos de sucesso mencionam. Nesse sentido o apoio de consultoria externa foi um recurso
significativamente bem pontuado nos relatos. Foi constatado o importante apoio de programas governamentais
de incentivo e fomento MPS que envolveram o financiamento de iniciativas consorciadas de MPS. Pelas en-
trevistas, tempo e recursos para MPS um fator mostrou-se particularmente muito dependente da capacidade
financeira da empresa manter o investimento em MPS ao longo do tempo.
Exemplo como facilitador:
A gente tem 2 pessoas (referindo-se equipe da qua-
lidade): um gerente de projeto interno, que o projeto
do MPS.br, junto com ele, a gente tem outra pessoa.
Sao 2 analistas experientes, porque o sucesso realmen-
te voc botar as pessoas mais experientes pra atuar
nesses projetos de Qualidade, n?
(Flvia, Gerente de Desenvolvimento de Sistema)
Exemplo como barreira (insuficincia ou falta de):
... pela situao (difcil) da empresa, houve uma ade-
quao. O setor de qualidade foi se enxugando, se
enxugando at a no existir. Ento, quer dizer, no
houve mais um acompanhamento. Ento, eu acho que
no por conta da qualidade em si, mas por causa da
situao da empresa, que no vinha boa. Ento, eles
comearam a deixar de lado. O CMMI tambm foi
abandonado. No conseguiram mais seguir em frente
com o processo CMMI.
(Gilmar, Desenvolvedor)
Relao com as Atividades Primrias de Interveno:
Este fator fundamentalmente influenciado pela capacidade financeira da empresa. Para alm disso, pode ser
muito influenciado pelas tarefas primrias em termos de:
Informao vlida e escolha informada sobre alternativas de investimento recurso do programa de MPS favo-
recendo a deciso e comprometimento da alta administrao.
Comprometimento da alta direo com a deciso de investir em MPS


154
B.2) Apoio/Comprometimento da Alta Administrao

Significado:
Apoio, comprometimento da alta administrao com o patrocnio de aes, decises e acompanhamento do pro-
grama de MPS.
Comentrio analtico:
Este fator foi o segundo mais freqentemente referido nas entrevistas, com igual peso tanto como um facilitador
como tambm barreira (pela ausncia deste fator) ao programa de MPS. Nos relatos enquanto facilitador este
fator se mostrou bastante associado ao efetiva da alta administrao para motivao das pessoas, acompa-
nhamento do programa e sobretudo ao apoio poltico s aes de MPS quando estas podiam de alguma forma
sofrer presses de demandas dos clientes. Em relatos enquanto barreira ficou patente a cobrana por decises
firmes da alta gerncia em situaes de conflito envolvendo o programa de MPS, bem como referncia a situa-
es de omisso, falta de acompanhamento e cobrana por parte da alta gerncia com relao ao programa.
Exemplo como facilitador:
Eu acho que o que facilita mesmo a coisa da Direo.
Eu chego aqui pro Inaldo, pra Wilma (diretores) e
digo: , est tendo esse problema aqui, a eles resol-
vem mesmo, puxam a orelha da galera e tal: Olha
pessoal, tem que fazer, tem que fazer e tal... A gente
tem uma reunio de quinze em quinze dias que rene a
empresa todinha, a de vez em quando o Inaldo est
falando: , pessoal, temos aqui o objetivo. Quando
ia ter a avaliao para certificao, a gente sentia muito
disso, porque ele sempre estava fazendo um discurso
motivando a galera: , est chegando, est chegan-
do!. Ento esse apoio eu acho que fundamental,
porque seno voc comea a definir as coisas, a vai l
institucionalizar, e se o pessoal no sentir que tem o
apoio da Direo: Ah, t beleza, tem isso aqui pra
fazer do processo e tal, mas eu no vou fazer no por-
que eu tenho essa outra coisa pra entregar pro clien-
te.... Ento, o apoio da Diretoria importante porque o
pessoal v: Isso a importante pra empresa. Ento, se
eu fizer, no vou ser prejudicado por causa disso, no
vo me cobrar porque fiz isso e no fiz outra coisa.
Ento, eu acho que o principal.
Exemplo como barreira (insuficincia ou falta de):
ele no tava direcionando o esforo dele no sentido de
cobrar que as pessoas seguissem os processos, de parti-
cipar das coisas com a gente... era aquele apoio ver-
bal: eu quero... vamos l... mas faam ai.... a alta
gerncia da gente no dava respaldo. No momento
crucial, que foi o momento que a gente comeou a
institucionalizar os processos, as pessoas-chaves que
deveriam estar puxando o negcio, que era a alta ge-
rncia e os gerentes de projetos, simplesmente se
omitiam. Ento, isso causou a desmotivao de todos.
(Bartolomeu, Engenheiro da Qualidade. Grifos meus)
... Principalmente na resoluo dos conflitos (referin-
do-se expectativa de ao pela alta direo). Porque
existe conflito entre a rea de qualidade e rea de pro-
duo. Ento, o que acontecia? Ficava aquele conflito
e tem uma hora que a alta direo quem decide. E na
empresa no existiu. A diretoria era muito ausente.
(Mrio, Analista de Sistemas. Grifo meu)
Relao com as Atividades Primrias de Interveno:
Este fator depende de: informao vlida e til sobre os benefcios potenciais da iniciativa de MPS para com
os objetivos e estratgias do negcio; escolha livre informada tendo em vista as oportunidades de participao
e contribuio no papel de patrocinador; monitoramento da interveno com foco nos resultados prticos para
o desempenho do negcio; comprometimento interno tendo em vista os fatores anteriores.


155
B.3) Apoio e comprometimento da equipe

Significado:
Abertura, apoio e comprometimento da equipe de desenvolvimento de software (incluindo gerentes de projeto)
para a implantao de processos formais de desenvolvimento e para com as aes em geral do programa de
MPS. Sentimento de pertena do processo pela equipe de desenvolvimento. Ausncia ou insuficincia destes
fatores. Resistncia mudana.
Comentrio analtico:
O principal produto de uma iniciativa de MPS a prpria implantao do processo de software ou melhorias no
processo j existente. Na prtica, como as mudanas propostas afetam diretamente o trabalho das equipes de
desenvolvimento o sucesso do programa depende fundamentalmente do comprometimento com a utilizao
efetiva do processo por estas equipes.
Ausncia ou insuficincia de apoio/comprometimento da equipe de desenvolvimento foi o segundo fator mais
freqentemente referenciado como barreira ao programa de MPS. Freqentemente esta barreira era explicada
nos relatos como resistncia mudana por falta de visualizao dos benefcios da MPS ou fruto da falta de
participao e sentimento de pertena da equipe em relao s definies dos processos. J a presena deste
fator foi tambm referenciada como um importante facilitador de MPS, porm numa freqncia significativa-
mente menor em relao sua pontuao enquanto barreira.
Exemplo como facilitador:
Essa era uma rea em que as pessoas eram supermoti-
vadas (referindo-se uma certa equipe de desenvol-
vimento). E o CMM veio para motivar mais ainda.
Ento, era uma coisa muito interessante. Eu como
SQA, a gente perguntava, sempre naquela auditoria:
voc tem algum ponto forte ou algum ponto fraco para
colocar? E a as pessoas diziam: _Ah, aqui bom
porque tem processo, a gente sabe o que vai fazer.
Ento, eram as prprias pessoas e voc via que j
tinha uma motivao boa e aquilo ali fomentou, no ?
(Lorena, Consultora e Engenheira da Qualidade)
Voc depois se tiver oportunidade, eu posso chamar
outras pessoas, voc vai ver como forte essa questo
da qualidade, as pessoas querem ir em busca (referin-
do-se especificamente uma equipe). cultural. A
gente j muito acostumado a trabalhar com proces-
sos, mesmo quando a gente no tinha uma forma es-
truturada ainda, um CMM ou algum padro j conhe-
cido, a gente j procurava fazer os nossos processos,
as nossas melhorias. ... A gente tem pessoas que che-
gam de outras empresas e dizem: Puxa vida, vocs
aqui so organizados, tem processos... Acho que
cultural, e no foi assim de uma hora pra outra, n? O
projeto j vai fazer 12 anos.
(Flvia, Gerente de Desenvolvimento de Software)
Exemplo como barreira (insuficincia ou falta de):
... a gente tinha auditorias internas peridicas, mas
tinha uma resistncia muito grande, em um alguns
pontos da empresa em realmente seguir as normas que
os processos tinham determinado. ...Com o tempo
melhorou (referindo-se resistncia), mas acho que
no era ideal, ao contrrio.... Tinha que melhorar mui-
to pra ser o ideal (Risos). Quando dizia: tem que
esticar o final de semana pra trabalhar uma no-
conformidade identificada nos processos, atualizar os
identificadores..., ento voc via que era um negcio
meio que... no rolava n?
(Venncio, Analista de Sistemas, Membro de SEPG)
... A maioria tem uma certa repulsa (referindo-se a
atitude da equipe de desenvolvimento para com os
processos). Esse negcio vem para me dar mais tra-
balho (risos). Eu mesmo pensei assim no primeiro
momento.
(Mrio, Analista de Sistemas)

156
Relao com as Atividades Primrias de Interveno:
Este fator depende de:
Informao vlida e til sobre a iniciativa de MPS, objetivos, benefcios do programa para a empresa e para as
pessoas e papel de cada envolvido. A resistncia das equipes de desenvolvimento deve ser tratada como uma
informao vlida sobre o processo de implantao de MPS. Em vez da equipe de qualidade atribuir a resistn-
cia como sendo uma caracterstica inevitvel da equipe de desenvolvimento ela deveria promover uma investi-
gao sobre como a ao da equipe de qualidade pode estar contribuindo para esta resistncia.
Escolha livre informada tendo em vista as oportunidades de participao e contribuio.
Comprometimento interno tendo em vista a motivao e interesse em participar.
Monitoramento da interveno com foco nos resultados prticos para o desempenho dos projetos e avaliao
da participao efetiva das pessoas.



B.4) Envolvimento da equipe de desenvolvimento

Significado:
Participao da equipe de desenvolvimento na definio, validao do processo de software e aes do progra-
ma de MPS. Ausncia ou insuficincia deste fator (imposio dos processos).
Comentrio analtico:
Este fator aparece como um dos mais freqentes nos relatos de aspectos facilitadores do programa. Uma parcela
significativa de entrevistas citou a ausncia deste fator como uma barreira ao programa. Esta barreira geralmen-
te foi caracterizada como imposio dos processos aos desenvolvedores sem que eles pudessem opinar suficien-
temente a respeito. Esta barreira geralmente traz como conseqncia a falta de apoio e comprometimento da
equipe com as aes do programa.
Exemplo como facilitador:
... Os gerentes de projeto se envolviam, os gerentes de
projeto e os coordenadores de software (referindo-se
etapa j vivida de obteno do nvel 2 do CMM).
Nesse nvel agora (referindo-se busca atual do nvel
3 do CMMI) ta se envolvendo o desenvolvedor mes-
mo, ou o projetista de hardware, entendeu? Chegou
num nvel de engenharia agora.
(Aline, Gerente de Qualidade)
Exemplo como barreira (insuficincia ou falta de):
... Tinham pessoas que diziam: como que eu posso
fazer um processo, executar um processo, e esse pro-
cesso eu nem participei, pelo menos no dei minha
opinio em relao.. Porque a idia do modelo era a
gente fazer um processo que atendesse s normas. Que
de fato fosse executado pelas pessoas. Era escrever o
que elas de fato faziam.
(Lima, Analista de Sistemas, Membro de SEPG)
... um colega dizia que os procedimentos, quando
foram mudados pelo CMM, foram empurrados de
goela abaixo na gente e isso gerava um tremendo
desconforto. Tanto dos tcnicos como das pessoas que
iriam fazer auditoria. ...alguns tcnicos nossos eram
auditores tambm. Ento, eles sentiam na pele tudo
aquilo que foi colocado no processo e que no era
usado. Ento, se tinha muita no-conformidade.
(Jlio, Gerente de Desenvolvimento)
Relao com as Atividades Primrias de Interveno:
Este fator depende de: Informao vlida e til sobre o conhecimento da iniciativa de MPS e das oportunida-
des de participao; Escolha livre informada tendo em vista as oportunidades de participao e contribuio;
Comprometimento interno: a oportunidade de participar um forte gerador de comprometimento das pessoas;
Monitoramento da interveno com foco no nvel de participao das pessoas.

157
B.5) Conscientizao/ entendimento dos benefcios e exigncias da MPS

Significado:
Percepo e conscincia da equipe como um todo, dos benefcios e exigncias das aes de MPS. Percepo
dos problemas gerados pela falta de processos de software. Aes para conscientizao. Ausncia ou insufici-
ncia deste fator.
Comentrio analtico:
Tema bastante frequentemente destacado nas entrevistas. Conforme se pode observar nos prprios relatos dos
entrevistados possui grande influncia no fator apoio e comprometimento da equipe. Aes na direo da
conscientizao / entendimento dos benefcios de exigncias da MPS so um requisito bsico desde o incio do
programa de MPS e ao longo de toda sua evoluo. este fator que gera nas pessoas uma percepo da relao
benefcios versus custos do esforo de MPS.
Exemplo como facilitador:
A motivao importantssima, mas a pessoa s se
motiva se ela souber o que aquilo. Se ela vir que
aquilo traz benefcio pra ela, ela faz. A motivao vem
do entendimento, vem da importncia daquilo, da
pessoa saber que aquilo importante pra carreira dela,
entendeu? Se a pessoa no v aquilo como importante,
ela pensa que mais importante fazer o cdigo.
(Romero, Gerente de Projetos)
Eu acho que ajuda voc deixar bem claro pra pessoa
porque que ela est fazendo aquele negcio. Ento,
quando voc faz avaliao de Qualidade e v que
aquilo tem no-conformidade, no s chegar pra
pessoa e dizer: , isso aqui est errado. Faz desse
jeito. Ento, at no prprio relatrio l da gente, tem
um canto l que diz qual o impacto daquela no-
conformidade: , se voc no fizer isso ou se conti-
nuar fazendo desse jeito que voc est fazendo, no
fizer do jeito que est l no modelo, o problema
esse, pra dizer o que que acontece. Porque no pode
dizer s: No, voc tem que preencher aqui essa ata
porque o processo diz que assim, n? Porque seno,
o pessoal: P! Eu estou fazendo s porque o processo
diz que assim. No tem sentido nenhum!.
(Daniel, Engenheiro da Qualidade)
Exemplo como barreira (insuficincia ou falta de):
Acho que houve falha na implantao do programa, a
conscientizao das pessoas foi mal feita. Por exem-
plo: marcaram uma apresentao do CMMI para a
equipe e sem que esta soubesse de nada disseram:
vamos comear semana que vem!. At pra mim foi
surpresa! Disse a eles: - vocs deviam ter me avisado
antes que eu teria falado com o pessoal. como se
no tivessem usado o lado humano mesmo. Chegaram
e disseram: vai ser assim.... No entanto, preciso
perder tempo explicando s pessoas, mostrando os
benefcios, pra conquistar as pessoas.
(Diane, Gerente de Projeto)
... o projeto ISO um projeto que abrange toda a em-
presa. Ento, quanto mais gente envolvida, quanto
mais processos envolvidos, mais difcil fica a coisa de
andar. Ento, por mais que a gente tivesse um desejo
particular da Diretoria, a gente teve um problema de
comunicao no incio, de que todas as pessoas enten-
dessem: o que que a gente ta fazendo? O que que a
gente quer com esse projeto? O que que a empresa
deseja, por que que a gente ta trabalhando com isso?
(Flvia, Gerente de Projeto)
Relao com as Atividades Primrias de Interveno:
Este fator depende fundamentalmente de gerao de informao vlida e til sobre a iniciativa de MPS, obje-
tivos, benefcios do programa para a empresa e para as pessoas e papel de cada envolvido. Este um fator alta-
mente potente para gerao de comprometimento.


158
B.6) Postura da equipe de qualidade.

Significado:
Postura da equipe de profissionais da qualidade em relao s equipes de desenvolvimento de software. Carac-
tersticas relatadas como positivas: ajuda, flexibilidade, mentoria, proximidade e entrosamento. Caractersticas
relatadas como negativas: rigidez, rigor excessivo nas auditorias de processos, distanciamento e falta de entro-
samento.
Comentrio analtico:
Este tema pode ser considerado um dos destaques desta pesquisa uma vez que ele pouco relatado em pesqui-
sas semelhantes na literatura de MPS. As atitudes positivas dos profissionais da qualidade referidas acima fo-
ram relatadas como facilitadoras do programa de MPS, sobretudo porque provocavam um melhor entrosamento
com as equipes de desenvolvimento e consequentemente uma melhor aceitao do programa. Ao contrrio, as
atitudes negativas referidas acima, foram relatadas como barreiras MPS, uma vez que provocavam maior
resistncia das equipes de desenvolvimento. Nos casos negativos os auditores da qualidade foram vistos como
inflexveis, distantes e, s vezes, rotulados at como carrascos. Verificou-se na pesquisa que a formao
profissional dos engenheiros da qualidade de software, em geral, no inclui programas para desenvolvimento de
habilidades relacionais.
Exemplo como facilitador:
Voc (enquanto engenheiro da qualidade) deve ter
jogo de cintura. Se chegar l pra falar com o pessoal
e a o cara diz: No, eu estou sem tempo agora...
estou aqui no sufoco e tal... (refere-se ao cumprimen-
to de metas estabelecidas por aes da Qualidade).
Ah, ? T beleza. Vamos fazer um acordo? No faz
at esse dia no, mas faz pra dois dias depois. Pra
pessoa ver que voc tem interesse em ajudar, o seu
interesse no ficar lascando a pessoa ali, dizer que
ela vai ter que fazer aquele negcio e vai ter que virar
a noite aqui fazendo tudinho...
(Daniel, Engenheiro da Qualidade)
Porque o SQA tem um papel de educador, no ? Eu
acho. Ele no chega l, faz auditoria e vai embora. Ele
vai ajudar as pessoas a resolverem os problemas, a
arranjar uma soluo mais vivel. ... No somente
cobrar por cobrar. Voc tem que ter um entendimento
do contexto tambm e ver a melhor forma que d para
corrigir naquele ambiente. Ter esse senso crtico,
porque fcil numa equipe que est bem, super orga-
nizada e pedir inspeo de 100% de cdigo. Numa
equipe que est atrasada voc pedir inspeo de 100%,
talvez no seja. Agora, se aquilo for um critrio do
projeto, do cliente, a tem que ser. Ento, assim, o
tempo todo voc fica lidando com essas coisas e traba-
lhando com a equipe para ter a melhor soluo, para
no prejudicar a qualidade.
(Lorena, Consultora e Engenheira da Qualidade)
Exemplo como barreira (insuficincia ou falta de):
Algumas pessoas da rea de qualidade, s vezes tor-
nam o processo uma coisa muito chata de se fazer. Por
exemplo: a gente tem um cdigo de 500 linhas, 600, e
tem uma virgulazinha l que est errada. Um ponto e
vrgula que foi colocada no cabealho. Voc precisa
fazer uma inspeo para isso? Convidar uma pessoa
para vir fazer um negcio formal, de botar no histrico
que aquilo foi alterado? Isso to mnimo! No vai
fazer diferena! Mas tem gente na rea de qualidade
que diz: Ah, porque no processo diz que qualquer
mudana, por menor que seja, vai afetar.... Vai ter
que demandar esse tempo!
(Luana, Arquiteta de Software, Membro de SEPG)
... era uma falha do pessoal de qualidade... as pessoas
eram vistas, na minha viso, quando a gente ia ter uma
auditoria, como carrascos! No se tinha uma viso de
ajuda, mas a gente tinha uma viso de prejuzo, de
preocupao. A gente no tinha uma viso: No, ele
vem para c para ajudar". A viso era: "Ele vem para
c para prejudicar.
(Jlio, Gerente de Desenvolvimento)
Comecei a adaptar o template (refere-se a um template
previsto no processo de software), mas a rea de qua-
lidade no aceitava! Tinha que ser daquele jeito deles!
O SQA parecia uma mquina! Eu tinha um objetivo
(melhoria do processo) e ele tinha outro (certifica-
o). Ele dizia: voc no consegue o selo se no fizer
todos os processos de nvel 2, conforme previsto!. Eu
podia at fazer uma CR (Change Request) do proces-
so, mas enquanto a mudana no era implantada tinha
que funcionar como previsto! Assim, todos os itens
eram sempre no conformes!
(Diane, Gerente de Projeto. Grifos meus)
159
Relao com as Atividades Primrias de Interveno:
O conhecimento e experimentao da teoria de interveno de proposta por Argyris e apresentada resumida-
mente no captulo 4 desta dissertao, especialmente quanto ao papel do interveniente, poderia ser de grande
relevncia para a conduo de aspectos scio-tcnicos de programas de MPS.
Capacidade de promover a gerao de Informao Vlida e til a habilidade mais bsica de um intervenien-
te. Mtodos de interveno em MPS que proporcionem escolha livre e informada e comprometimento inter-
no tendem a promover uma maior probabilidade de sucesso da interveno. Idem para a capacidade diagnstica
no monitoramento da interveno.
Estas habilidades devem estar apoiadas por outras de natureza humana/relacional como: empatia, capacidade de
negociao e facilitao de grupos. Habilidades de viso sistmica e orientao para metas e ao so tambm
importantes.


B.7) Fatores motivacionais para MPS

Significado:
Fatores que motivaram a implantao do programa de MPS: certificao, aumento de oportunidades de merca-
do, obteno de qualidade (em nvel da organizao); melhoria do currculo (em nvel individual por parte dos
profissionais). Priorizao do objetivo de certificao em detrimento da melhoria em si
Comentrio analtico:
A inteno de certificao (casos da ISO ou MPS.Br) ou avaliao oficial (caso do CMM ou CMMI) mostrou-
se como o argumento mais freqentemente referido nas entrevistas como fator motivacional do programa de
MPS. Normalmente esta inteno estava associada a motivaes mercadolgicas da organizao. No nvel indi-
vidual foi referida inteno de participar do processo de certificao como algo que traz experincia e melhoria
ao currculo profissional. Em apenas uma entrevista uma pessoa fez questo de mencionar que a busca da quali-
dade em si era um fator mais relevante do que a obteno de certificaes. Em muitos relatos foi possvel cons-
tatar que priorizao da busca de certificao pode funcionar uma barreira para a melhoria dos processos em si,
conforme pode ser visto nos exemplos a seguir.
Considera-se esta caracterstica como um dos destaques desta pesquisa, tendo em vista que este problema
pouco relatado em pesquisas semelhantes encontradas na literatura. Uma exceo um artigo de (2002) que
argumenta que a priorizao do objetivo de certificao uma tendncia que traz riscos a que modelos como o
CMM possam vir a perder sua utilidade enquanto guias de melhorias de processos.
Exemplo como facilitador:
... como eu lhe digo: a empresa como empresa j
tem o certificado. Ento, se fosse pelo certificado, ela
no tinha interesse nenhum em passar pra outras uni-
dades, mas o nosso interesse qualidade. Ento, inde-
pendente de certificado, a empresa no vai ganhar
nada em termos de visibilidade no mercado de ter uma
outra unidade certificada, porque como eu lhe falei a
empresa (como um todo) ISO, mas... a comeou por
aqui e est indo pras outras. O mesmo processo pra
MPSbr, pro CMM e pro que vier, a gente no sabe o
que vem pela frente.
(Flvia, Gerente de Desenvolvimento de Sistema)
... para mim era interessantssimo, at por uma questo
de currculo. Ter conhecimento em CMMI melhor
do que ISO. Embora eu nem conhea tanto o CMMI,
s pelo nome. Por uma questo tambm de nomen-
clatura de mercado, a gente pensa isso a.
(Gilmar, Desenvolvedor)
Exemplo como barreira:
... os patrocinadores das empresas, muitos deles entra-
ram no projeto (referindo-se ao projeto de MPS) mais
por questes de mercado do que propriamente vontade
de melhorar os processos. O cara tinha o querer de
coisas do tipo: ah! eu vou entrar porque eu perdi uma
licitao ou porque eu vejo como uma oportunidade
da minha empresa ganhar mais mercado. Mas do
ponto de vista de vamos melhorar os processos, va-
mos melhorar a qualidade de trabalho das pessoas
dentro da organizao, esse tipo de coisa no era
muito enxergado, n? ... Como ele tava querendo
mercado, o que que acontecia? s vezes quando
aparecia um contrato grande, ele (o diretor da empre-
sa) pegava aquele cara l (a pessoa dedicada MPS),
tirava do projeto de melhoria e botava no projeto de
desenvolvimento de um produto e a a empresa perdia
o passo n?!
(Lauro, Consultor de MPS)
... Quis continuar a melhoria mesmo assim, mas a rea
160
de qualidade perdeu a motivao. Eles se desinteressa-
ram j que no havia mais a possibilidade de certifica-
o (refere-se ao fato de que a direo havia tomado
a deciso de excluir este projeto do escopo da avalia-
o). Eles estavam interessados na experincia de
certificar a empresa. ...Eu que ligava, marcava reu-
nio e eles no vinham.
(Diane, Gerente de Projeto de Software)
as auditorias internas sempre pegavam isso. Identifi-
cavam as no conformidades e as aes corretivas
eram, deveriam ser tratadas n? Era sempre aceito,
mas sempre acontecia novamente. ... e no final pres-
tes a ter uma nova auditoria pra re-certificar, en-
to tinha aquele mutiro pra adequar as coisas j
na afobao! Ento assim, isso muito ruim pra
empresa, que, pxa a empresa certificada e tal, mas
realmente os processos no seguiram como deveriam
realmente seguir, ento isso um ponto que eu achei
muito negativo n?!
(Venncio, Analista de Sistemas, membro de SEPG)
Relao com as Atividades Primrias de Interveno:
Este fator traz a tona intenes nem sempre compatveis entre si e cujo conflito pode no estar realmente claro
para os agentes: - eles muitas vezes proclamam o interesse na melhoria dos processos mas sua teoria-em-uso
revela um maior interesse pelo selo da certificao em si pelo que isso representa para a imagem da empresa
(no nvel organizacional) e para a imagem pessoal (no nvel do currculo individual dos profissionais).
A atividade de gerao de informao vlida e til exercida de forma produtiva deve ser capaz de revelar
problemas deste tipo e proporcionar o redirecionamento (escolha livre e informada) dos rumos do programa.


B.8) Burocracia / MPS como obstculo ao "trabalho real"

Significado:
Excesso de documentos previstos no processo de software. MPS vista como causadora de burocracia e algo
que rouba tempo que deveria estar dedicado atividade finalstica da empresa.
Comentrio analtico:
Este fator foi basicamente referenciado como uma barreira aceitao da implantao de processos formais,
principalmente por parte dos profissionais de desenvolvimento, em virtude do que eles atribuam como rigidez
do processo e excesso de documentos a serem produzidos. Os entrevistados referiram-se a termos como: pro-
cesso engessado ou pesado. Pelos relatos, esta caracterstica tendeu a diminuir ao longo do tempo seja por-
que os processos sofreram simplificaes, seja porque as pessoas tambm adquiriam uma melhor compreenso
de seus benefcios.
Exemplo como barreira:
Muitas vezes tinha a impresso de que o tempo gasto apenas para documentar os requisitos e especificaes
(refere-se a passos previstos no processo de software) era maior do que o tempo necessrio a resolver o pro-
blema do cliente, se fosse apenas sentar em frente mquina e realizar as alteraes. Havia a sensao de que
estava realizando aquilo para atender aos processos e no para atender ao cliente.
(Paulo, Gerente de Projeto de Software)
Relao com as Atividades Primrias de Interveno:
Problemas como este podem representar uma ameaa para os profissionais da qualidade fazendo com que eles
venham a minimiz-lo ou fazer de conta que ele no existe, ou ainda, transferir a responsabilidade para a
161
resistncia da equipe de desenvolvimento.
A atividade de gerao de informao vlida e til exercida de forma produtiva deve ser capaz de revelar
problemas deste tipo e proporcionar estratgias para soluo conjunta dos problemas (escolha livre e informa-
da e comprometimento com a soluo).


B.9) Treinamento e mentoring

Significado:
Treinamento e orientao adequados aos envolvidos no esforo de MPS. Insuficincia ou ineficcia destes fato-
res.
Comentrio analticos:
Este fator est no topo da lista dos mais referidos nas entrevistas com uma conotao positiva em termos ser um
facilitador em programas de MPS. Todavia, estas referncias nem sempre foram feitas como resposta direta
pergunta de quais so os fatores facilitadores? e sim muitas vezes estavam diludas em meio a outros temas.
Algumas vezes foi citado como uma barreira na medida em que foi considerado insuficiente ou ineficaz.
Exemplo como facilitador:
... Todos eram bem capacitados, todos foram bem
treinados e preparados pela consultoria. A consultoria
fez um papel muito importante, que era um papel de
mentoring durante o processo.
(Mrio, Analista de Sistemas)
Exemplo como barreira:
A forma de treinar da gente ainda no est certa. No
adianta o cara chegar na empresa e ser treinado duran-
te uma semana e sair direto pra trabalhar. Ou a gente
tem que fazer um treinamento inicial menor, coloca o
cara pra trabalhar e fazer uma reviso depois de um
ms, no sei... tem que ser escolhida alguma forma
diferente de fazer esse treinamento. Do jeito que a
gente faz hoje em dia no eficiente... No verifica-
do se o treinamento foi realmente efetivo, nada disso.
Nem verificado! ... Voc chega l e fala: ah, eu vi o
check-list no site do Processo com todos os documen-
tos e todos os procedimentos. Voc no sabe se
trabalhou. O cara s vai ler e no tem que fazer,
entende? Ento a forma, o mecanismo de treinamento
da gente no est muito bem arrumado pra isso da.
(Amaral, Lder Tcnico)
Relao com as Atividades Primrias de Interveno:
As atividades de treinamento e mentoria so fortemente baseadas em conhecimento acumulado. Todavia, em
MPS as situaes de treinamento/mentoria podem ser utilizadas para investigao (gerao de informao
vlida e til) sobre o contexto dos envolvidos. Isto poder contribuir para o comprometimento dos treinandos
e tambm vir a gerar mais conhecimento a partir da experincia deles.


B.10) Experincia e qualificao da equipe

Significado:
Experincia, qualificao, domnio de conhecimentos e formao profissional adequados em Engenharia e
Software e MPS, da equipe envolvida no esforo de MPS. Insuficincia ou falta destes fatores.
162
Comentrio analtico:
A insuficincia de experincia e qualificao da equipe, tanto do pessoal de desenvolvimento (na maioria das
vezes) como da prpria equipe de qualidade, foi citada em quase metade das entrevistas como uma barreira
evoluo do programa de MPS. Em um tero das entrevistas, a presena desse fator foi considerada relevante
como facilitador do processo. A experincia ou qualificao referida em conceitos bsicos de Engenharia de
Software (no caso da equipes de desenvolvimento e tambm profissionais da qualidade) ou experincia em
conduzir MPS (no caso de profissionais da qualidade).
Exemplo como facilitador:
Quando voc pega um cara que tem uma experincia
como a pessoa que lhe falei (refere-se a um engenhei-
ro que considera experiente) uma tranqilidade
trabalhar com elenno projeto, entendeu? Eu e ele cate-
quizamos o resto... Tem um grupo da Federal que eles
j tm uma disciplina de trabalho. excelente traba-
lhar com eles! Fazem requisitos, fazem isso, fazem
aquilo, a qualidade do que eles fazem muito boa,
entendeu? Eles j tm isso de cor! Eu acho que a
maturidade das pessoas, a experincia no tempo
apenas, tempo versus intensidade. Pode ter cara com
dois, trs anos de experincia, mas com uma intensi-
dade de experincia muito grande, que no final ele
consegue ver o que a gente faz como um processo,
quem faz, como que a qualidade contribui pra isso, o
que a qualidade, entendeu?
(Romero, Gerente de Projetos)
Exemplo como barreira:
.... a empresa estava passando por uma dificuldade
financeira, a soluo adotada sempre aquela mais
barata, que era trazer gente que pedisse menos. E a
essas pessoas eram menos qualificadas, geralmente
estagirios. E a realmente voc no podia atribuir,
nem cobrar responsabilidade muito alta de um estagi-
rio. Ele estava ali para aprender. Ento, realmente isso
complicava, as pessoas que eram formadas tinham um
gap conceitual muito grande. Coisas bsicas elas no
sabiam fazer, como o que um requisito, o que um
caso de uso, ento a gente tinha uma dificuldade gran-
de de ter que treinar estas pessoas na base, que elas j
deveriam ter, para que elas pudessem entender os
processos.
(Bartolomeu, Engenheiro da Qualidade)
Relao com as Atividades Primrias de Interveno:
A experincia e qualificao das equipes de desenvolvimento e de qualidade depende diretamente do conheci-
mento acumulado em MPS e em engenharia de software em geral. Isto favorecido por processos que privile-
giem a gerao coletiva de informao vlida e til (por exemplo: reunies de lies aprendidas, auto-
diagnsticos, resoluo conjunta de problemas). Isto, por sua vez, depende da participao dos envolvidos que
por sua vez influenciada por escolha livre e informada e comprometimento interno.


B.11) Processo e compartilhamento de conhecimento em MPS

Significado:
Prtica, processo e infra-estrutura para compartilhar conhecimento vindo da experincia de aplicao dos pro-
cessos e de MPS. Insuficincia ou falta destes fatores
Comentrio analtico:
Um nmero significativo de entrevistados referiu-se falta de compartilhamento ou discusses de lies apren-
didas, bem como falta de documentao ou repositrio estruturados de conhecimentos adquiridos. De forma
significativa houve tambm relatos da presena deste fator em algum nvel, como uma referncia positiva no
programa de MPS. Tende a ser muito influenciado tambm pelo fator comunicao e feedback sobre o anda-
mento do programa de MPS.
Exemplo como facilitador:
Todo ano a gente tem o exemplo do Encontro Nacio-
nal de Desenvolvedores de Software da empresa, que
foca em apresentar problemas das equipes, solues, a
gente mostrar melhorias...
(Silvana, Gerente da Qualidade)
Exemplo como barreira:
Aqui na empresa a gente s tem processos por projeto,
melhorias de um projeto no passam pros projetos
seguintes. Isso um problema! Ento, voc faz uma
srie de prticas interessantes naquele projeto espec-
fico: de templates diferentes, de um processo de teste
um pouco diferente do que o normal, talvez um acom-
panhamento um pouco diferente do que estava sendo
163
A gente trabalhava num ambiente que no era to
grande, ento a gente comentava muito entre ns. A
gente tinha muito isso de dizer: O que tu achas disso,
de botar isso no relatrio? Leve isso que eu estou
muito insegura. Ento, tinha muito essas coisas que
um aprendia com outro. Mas teve um momento que a
gente formalizou. A gente tinha reunies peridicas,
onde cada um dizia o que achou, o que pegou...
(Lorena, Consultora e Engenheira da Qualidade)
feito normalmente, um planejamento um pouco dife-
rente, mas isso no passa pros projetos seguintes.
Porque algumas vezes, o post mortem que a gente faz,
quando a gente faz, isso a no colocado, no existe
uma base de planejamento de voc poder passar isso
a no! Ento esse conhecimento no passa pra frente,
ele fica localizado naquele projeto.
(Amaral, Lder Tcnico)
Relao com as Atividades Primrias de Interveno:
O compartihamento de conhecimento em MPS e engenharia de software uma estratgia direta de gerao de
informao vlida e til. Ele tender acontecer se houver um ambiente colaborativo e tender a ser restrito se
houver um ambiente competitivo e desagregador (ver os modelos I e II referenciados no captulo 3). Isto ser
favorecido com processos e infraestrutura que propiciem esta ao. Depende diretamente da escolha livre e
informada e do comprometimento interno com o processo.

164
B.12) Atitude dos Clientes

Significado:
Atitude positiva ou negativa dos clientes frente aos requisitos da iniciativa de MPS. Exigncia dos clientes por
MPS ou colaborao com a iniciativa. Indiferena, desconfiana ou rejeio dos clientes para com a iniciativa
de MPS.
Comentrio analticos:
De acordo com o relato significativo de entrevistados o uso de processos formais de desenvolvimento de soft-
ware era uma exigncia de suas empresas-clientes e nesses casos isto foi um fator de grande relevncia para
facilitao do programa de MPS. Em outro caso, seno a exigncia, mas a aceitao e colaborao do cliente
foram igualmente um facilitador. Por outro lado, de forma bastante surpreendente, cerca de um tero dos entre-
vistados apontaram a existncia de desconfiana e resistncia ao programa de MPS por parte de empresas-
clientes. Nessas situaes, a viso dos entrevistados foi de que os clientes tenderam a ver no programa de MPS
um risco indesejvel de aumento de custos dos servios. Nesses casos, estes fatores agiram como sendo uma
grande barreira ao programa, gerando por exemplo, conflitos entre equipes de desenvolvimento (que se viam
pressionadas pelos clientes) e a rea de qualidade (que exigiam o cumprimento dos processos estabelecidos), e
contribuindo para que MPS fosse vista como obstculo ao trabalho real.
Exemplo como facilitador:
... era uma exigncia do cliente que a gente tivesse
definio de um processo pra ser seguido, tudo isso.
Ento, a gente encarou essa definio meio como uma
atividade que faz parte de um projeto como um todo,
n? Definir o processo, saber como que a gente vai
trabalhar com esse processo, como vai melhorar esse
processo continuamente e tudo mais. Pra gente foi
tranqilo...
(Amaral, Lder Tcnico)
Melhorou tambm a relao com o cliente na medida
em que ele tambm faz parte do processo preenchendo
requisies de melhoria e priorizando as requisies.
Os clientes aceitaram facilmente o novo processo e
passaram a valorizar a nova forma de trabalho.
(Paulo, Gerente de Projeto de Software)
Exemplo como barreira:
O cliente acaba achando assim, que muitas vezes ter
qualidade significa ter mais custo pra o projeto. Ento,
alguns clientes chegam a pedir: eu queria pedir esse
projeto, sem qualidade. (risos) Como se fosse poss-
vel tirar a qualidade do projeto entendeu? (risos) ...
Voc tem at que entrar at nesse mrito... De mudar a
cultura do cliente... Alguns clientes voc tem que
trabalhar: olha eu sou aqui da rea de qualidade, a
gente ta implantando um processo de melhoria, a
gente queria ouvir vocs, ver onde que a gente podia
mexer nos nossos processos pra melhor atender voc
.... Ah! Mas isso no vai encarecer o projeto?! a
primeira pergunta que eles fazem: Quanto que isso
vai custar pra mim?. A assim: voc mudar essa cul-
tura difcil, um trabalho que... voc tem que fazer
no dia-a-dia mesmo.
(Aline, Gerente de Qualidade)
A gente tinha uma dificuldade com um cliente que ele
no enxergava o valor de voc ter um planejamento...
O cliente exigia o prazo: quero que o sistema esteja
pronto em 2 meses. Pxa, em 2 meses eu no vou
ter um sistema, eu vou te entregar um produto com um
monte de erro. Ele preferia, porque tinha que estar
operacional em 2 meses por situaes l dele...
(Manoel, Diretor)
Relao com as Atividades Primrias de Interveno:
A atitude favorvel dos clientes fortemente influenciada pelo fator conscientizao/entendimento dos benef-
cios de MPS. Este por sua vez diretamente dependente da informao vlida e til sobre a iniciativa de
MPS, objetivos, custos e benefcios do programa para o cliente.


165
B.13) Metodologia formal

Significado:
Uso de metodologia e modelos para implantao de MPS e para estabelecimento dos processos de software.
Ineficcia ou falta deste fator.
Comentrio analtico:
Os relatos de entrevistas e outras pesquisas semelhantes indicam que o uso de metodologias bem definidas e
testadas trazem maior senso de orientao seja para a definio dos processos de software seja para a prpria
conduo do programa sendo portanto um facilitador. A ausncia deste fator considerada uma barreira na
medida em que os condutores do programa podem sentir-se desorientados em estabelecer os processos de soft-
ware e os passos da mudana. O uso de uma metodologia tambm pode vir a ser uma barreira se esta metodo-
logia implicar numa rigidez que no comporte adaptaes ao contexto especfico da iniciativa de MPS em cur-
so.
Exemplo como facilitador:
eu acho que uma das coisas importantes tambm que
de se utilizar o processo de implantao n!? Ele no
deveria ser um negcio que voc chaveia da noite por
dia n?! O cara pega e desenvolve o processo: a par-
tir de amanh todo mundo trabalha dessa forma!...
Isso um processo gradual, incremental atravs do
uso de piloto transferncia de tecnologia, por isso que
um negcio demorado n!?
(Lauro, Consultor em MPS)
Exemplo como barreira:
.... optou-se por Java, adquiriram ferramenta da Ratio-
nal, o que foi um erro porque a gente criou a ferra-
menta sem ter um processo. Ento, contratou-se
ferramenta, contratou-se curso, contratou mentoring e
no deu certo porque as pessoas se perderam, no ?
(Silvana, Gerente da Qualidade. Grifos meus)
Relao com as Atividades Primrias de Interveno:
Pesquisas demonstram que a principal dificuldade no uso de metodologias pr-definidas obter o comprome-
timento das equipes em seguir as definies. Humphrey (2002) afirma que poucas pessoas conseguem consis-
tentemente realizar trabalho de forma disciplinada. A principal prescrio no caso a adaptao da metodologia
realidade em questo e a participao das pessoas nessa adaptao. Isto exige tanto a gerao de informao
vlida e til como escolha livre e informada.


B.14) Gerenciamento do projeto de MPS e da mudana

Significado:
Uso de boas prticas de gerencia de projetos na conduo do programa de MPS. Ineficcia ou falta deste aspec-
to.
Comentrio analtico:
Uma iniciativa de MPS pode ser vista como um projeto ou um programa (conjunto de projetos que concorrem
para para mesmo macro-objetivo). Os achados desta e de outras pesquisas semelhantes sugerem que a adoo
de tcnicas de gerenciamento de projetos so fatores importantes para o sucesso deste tipo de iniciativa. A sua
ausncia ou ineficcia relatada como uma barreira.
Exemplo como facilitador:
... igual a um projeto como outro qualquer (referin-
do-se ao projeto de MPS): tem a fase de concepo,
marcos, estudo da viabilidade do projeto... verifica se
vai precisar ou no de consultorias, estima o nmero
de horas de consultoria... Passa a lista pra presidncia,
a presidncia revisa, aprova... tem todo um processo
de um projeto comum; ento, a gente passou j pela
fase de concepo, foi estudado, viabilizado o projeto
CMM na empresa ... A gente t na fase de planeja-
Exemplo como barreira:
A partir do momento que ele saiu da empresa (refere-
se a um gerente da qualidade que saiu da empresa),
nenhum outro gerente, apesar de j terem feito treina-
mento do PMBOK, nenhum gerente de projeto seguia
(as prticas do PMBOK)... Ento eles no tinham
responsabilidade com plano de projeto, elaborao de
cronogramas, preocupao em reportar os problemas
para a gerncia snior, fazer relatrios peridicos...
166
CMM na empresa ... A gente t na fase de planeja-
mento...
(Aline, Gerente de Qualidade)
(Bartolomeu, Engenheiro da Qualidade)
Relao com as Atividades Primrias de Interveno:
A fase de planejamento do processo de gerenciamento de projetos pode ser diretamente associada s atividades
de gerao de informao vlida (sobre o contexto da interveno) e de escolha informada (sobre os rumos
da interveno). A fase de execuo fortemente dependente do comprometimento com o plano. O processo
de controle fortemente associado atividade de monitoramento da implementao das decises da inter-
veno.


B.15) Objetivos claros, relevantes e coerentes

Significado:
Percepo clara de objetivos e prioridades entre eles. Coerncia e compatibilidade entre objetivos num mesmo
grau de prioridade.
Comentrio analtico:
Relatos nas entrevistas mostram que muitas vezes a iniciativa de MPS encontra barreiras em objetivos confli-
tantes, pouco claros ou incoerentes estabelecidos principalmente pela alta gerncia. Estes redundam em exign-
cias incompatveis cujas prioridades, se no forem claramente administradas tendem a gerar conflitos organiza-
cionais e falta de comprometimento para com parte dos objetivos. Por exemplo: estabelecer projetos de desen-
volvimento com prazos exguos visando conquistar clientes incompatvel com implantar um novo processo de
software (que normalmente tende a baixar o desempenho da equipe num primeiro momento). Por outro lado, a
existncia e divulgao de objetivos claros, relevantes e coerentes relatado como um facilitador do processo
de MPS.
Exemplo como facilitador:
... o gerente de Produto junto com a gerente de Quali-
dade fizeram um exemplo com toda a empresa, dando
palestras, explicando quais eram os objetivos, o que
que a empresa desejava, qual era o papel de cada um,
que todos tm que estar envolvidos, e isso foi um
ponto importante pra que a gente conseguisse isso.
Depois, desse workshop que a gente teve, interessan-
te como a coisa fluiu. A percepo das pessoas do que
a empresa quer, onde que a gente vai chegar, qual
papel de cada um (em relao implantao da qua-
lidade)... Isso parece pouco relevante, mas quando a
gente trabalha com pessoas fundamental! ... Todo
mundo tem que entender muito bem onde que a
empresa quer chegar, qual seu papel, o que que
precisa ser feito.
(Flvia, Gerente de Desenvolvimento de Software)
Exemplo como barreira:
... falta de planejamento interno. Preciso investir
quanto? E isso mesmo o que eu quero? Ou eu quero
s a certificao pra poder exportar? Porque pode ser
que eu passe um ano sem precisar usar aquela certifi-
cao... Ento, faltou um pouco, assim, de maturida-
de, mesmo (referindo-se falta de clareza de objeti-
vos dos diretores em uma iniciativa de MPS mal-
sucedida).
(Helena, Engenheira da Qualidade e Consultora)
Relao com as Atividades Primrias de Interveno:
Este fator depende basicamente da gerao de informao vlida e til sobre quais so as motivaes e obje-
tivos em questo? O quo compreendidos eles esto? Quais os conflitos entre eles? Quais as decises a tomar
(requer escolha livre e informada)?.


167
B.16) Adaptao de processos realidade dos projetos

Significado:
Adaptao dos processos de software propostos realidade vivida nos diferentes projetos de software da empre-
sa. Insuficincia ou falta deste fator.
Comentrio analtico:
Num esforo de MP, o processo de software inicialmente proposto freqentemente contem excesso de defini-
es e requisitos que precisam ser readequados. Alm disso, um processo de software padro define atividades,
papis, artefatos generalistas que podem no estar completamente adaptados s necessidades dos projetos espe-
cficos. Nesses casos fundamental um mtodo de adaptao do processo padro, sem o que o desempenho das
equipes de desenvolvimento poder ser prejudicado, por excesso de burocracia ou deficincia de documentao
especfica, por exemplo. Este esforo de adaptao requer uma ao integrada da equipe de qualidade junto s
equipes de projetos. A presena deste fator foi relatada de forma significativa como um facilitador de MPS nas
entrevistas. A ausncia ou insuficincia desse esforo de adaptao foi relatada como uma barreira e, nesses
casos, geralmente est associada a viso dos processos como sendo rgidos e burocrticos.
Exemplo como facilitador:
... tudo foi trabalho que a gente teve, pensando como
que fazia: Ah, no deu muito certo no!, ajusta aqui
um pouquinho e tal... Acho que foi o maior acerto da
gente de ter caprichado mesmo na definio e estar
sempre melhorando, em vez de tentar forar a pessoa a
fazer um negcio que no funcionava... Pensar em
coisas que fossem mais fceis de fazer.
(Daniel, Engenheiro da Qualidade)
Exemplo como barreira:
A gente percebeu com a anlise que a gente fez atra-
vs de algumas auditorias internas, que o primeiro
processo que foi criado tava muito cheio, muito en-
gessado, muito complicado... E atravs da auditoria a
gente viu que a gente tinha muitas no-conformidades.
(Lima, Analista de Sistemas e Membro de SEPG)
Relao com as Atividades Primrias de Interveno:
A adaptao de processos realidade dos projetos requer a gerao de informao vlida e til os requisitos
da realidade em questo e a deciso sobre quais adaptaes (requer escolha livre e informada) a serem feitas.


B.17) Delegao de responsabilidade / criao de times de ao

Significado:
Delegao e atribuio de responsabilidade a diferentes atores e grupos de atores na iniciativa de MPS. Insufici-
ncia ou falta deste fator.
Comentrio analtico:
O sucesso de um programa de MPS requer o comprometimento em esforo conjunto de reas como Alta Admi-
nistrao, Qualidade e principalmente da Equipe de desenvolvimento. Para tanto, uma estratgia relatada como
positiva nas entrevistas o estabelecimento de times de ao que assumem a responsabilidade por parte do
esforo. Um exemplo o estabelecimento de times para definio e melhoria de reas do processo como: ge-
rncia de requisitos, gerncia de configurao entre outras. Um aspecto importante tambm relatado nesses
casos sentimento de autonomia destes times para realizao das tarefas e tomadas de deciso necessrias. A
ausncia destes fatores foi relatada como barreira a MPS.
Exemplo como facilitador:
Nossa gerncia snior tem muito essa viso, de quali-
dade, sempre colocando pra equipe e a equipe absor-
vendo isso de uma maneira que no precisa cair numa
cobrana, porque eu acho que no funciona, acho que
quando vem de cima pra baixo, as coisas no funcio-
nam. importante o papel da liderana de tentar mos-
trar as diretrizes, mostrar o caminho, mostrar onde a
Exemplo como barreira:
Numa organizao que a gente viu, o cara (referindo-
se ao diretor) apoiava, mas na realidade ele meio que
tava l botando o dedo na coisa, interferindo, dando
pitaco. E a eu acho que isso tolheu de certa forma as
pessoas, porque o cara (da rea de qualidade) se sen-
tia meio que subordinado sempre. A no tinha deci-
ses prprias, o desembarao de tocar a coisa. Sempre
168
gente quer chegar, mas a a equipe anda s, est en-
tendendo? Eu acho que isso importante pra gente
conquistar o que a gente vem conquistando.
(Flvia, Gerente de Desenvolvimento de Software)
ficava esperando algum l de cima pra vir dar o apoi-
o.
(Lauro, consultor de MPS)
Relao com as Atividades Primrias de Interveno:
Este fator est fortemente associado escolha livre e informada e comprometimento dos participantes dos
times de ao.


B.18) Comunicao e feedback sobre o andamento do esforo de MPS.

Significado:
Esforo e qualidade da comunicao e feedback de informaes sobre os diversos aspectos do processo de
MPS. Clareza e fundamentao da informao/ feedback. Insuficincia ou ineficcia deste fator.
Comentrio analtico:
A comunicao informal e o feedback voluntrio a forma mais bsica de colher informao sobre o andamen-
to de um esforo de melhoria e relatado como um fator facilitador. A qualidade da comunicao est associa-
da sua clareza e relao com evidncias. A ausncia destes fatores foi relatada como barreira.
Exemplo como facilitador:
... como a gente buscava a melhoria, a gente tentava:
olha isso aqui realmente no foi feito, no existe um
registro disso, no existe uma evidncia de um ndice
que era auditado a gente repassava, e a gente tentava
colocar que a gente ta buscando melhoria. Ento:
busquem criticas, busquem sugestes, no apenas
responder auditoria interna.... Mas, buscar melhorar
a qualidade da coisa.
(Venncio, Analista de Sistemas, membro de SEPG)
H uma reunio quinzenal com toda a empresa, onde
se conversa os temas gerais da empresa. Nelas, muitas
vezes entra na pauta o tratamento de problemas com
os processos, e troca de experincia entre as equipes
de projetos em relao aos problemas relatados.
(Paulo, Gerente de Projeto de Software)
Exemplo como barreira:
O cara s vezes no te d feedback. ...por mais que a
gente monte mecanismos de melhorias de processos,
os engenheiros no do feedback pra fazer essa me-
lhoria, entende?
(Amaral, Lder Tcnico)
Eu sempre fazia entrevista e algum dizia assim:
_Olha, o meu gerente muito chato. Ele manda a
gente vir no final de semana e ele no vem. Ele
muito irresponsvel. E a a pessoa coloca no relat-
rio: o gerente no tem sintonia com a equipe. Eu
acho que isso a voc perdeu a objetividade, perdeu o
factual. Uma pessoa acha que o cara chato, mas voc
no pode dizer que o cara chato porque uma pessoa
acha que ele chato.
(Lorena, Consultora e Engenheira da Qualidade)

Relao com as Atividades Primrias de Interveno:
Este fator uma estratgia diretamente associada ao monitoramento da implementao das decises da in-
terveno e a gerao de informao vlida e til. Ele fundamentalmente dependente de:
Nvel de abertura da organizao para o tratamento produtivo de problemas, falhas e desvios, (ver mo-
delos I e II no captulo 3).
Habilidade das pessoas em se comunicarem com base em dados diretamente observveis (evidncias) e
atravs de raciocnios explcitos (ver Modelo II no captulo 3).


169
B.19) Conflitos Organizacionais

Significado:
Conflitos entre lderes e entre equipes na organizao, influindo nas decises de MPS.
Comentrio analtico:
Por sua importncia e abrangncia, um programa de MPS tende a trazer a tona conflitos de objetivos e priorida-
des entre os diversos interessados do programa. Estes conflitos podem representar uma sria ameaa ao anda-
mento do programa caso no sejam adequadamente tratados. Geralmente este fator est associado ao fator Ob-
jetivos claros, relevantes e coerentes. Conflitos potenciais entre reas funcionais podem se dar, por exemplo,
entre:
rea Comercial, porque para conquistar clientes pode subestimar prazos de desenvolvimento e priori-
zar o objetivo da certificao em detrimento da melhoria em si dos processos;
rea de Desenvolvimento, porque pressionados por prazos exguos tendem a relaxar o cumprimento de
artefatos documentais do processo de software;
rea de Qualidade, porque tende a ser rigorosa na cobrana do cumprimento do processo de software.
Exemplo como barreira:
... Um ponto fraco, que ela (refere-se diretoria da empresa) no soube gerenciar, em relao a... inimizade,
por assim dizer, entre o gerente da qualidade e um gerente de equipe. Houve um conflito em relao a essas
duas pessoas. Isso foi bastante desgastante, bastante mesmo! Ento isso um ponto fraco, extremamente fraco.
... Tanto que a gente participou de momentos... de treinamentos, que houve uma discusso de meia hora entre
gerentes...
(Lima, Analista de Sistemas, membro de SEPG)
... O projeto (refere-se a certo projeto de desenvolvimento de software) era dividido com outra empresa daqui
de Pernambuco. As duas partes tinham que tomar a deciso sobre se este projeto entraria no escopo da avaliao
(para avaliao CMMI) ou no, e como esse negcio iria beneficiar a empresa, mas em contrapartida ia preju-
dicar o projeto de certa forma, os caras (refere-se a dirigentes da outra empresa) colocavam terra. Acabava no
rolando.
(Bartolomeu, Engenheiro da Qualidade)
Relao com as Atividades Primrias de Interveno:
Grande parte dos conflitos organizacionais em MPS ocorrem em funo de objetivos incompatveis, nem sem-
pre tratados de forma clara para as partes. Gerar informao vlida e til sobre este contexto pode reduzir
estes conflitos. Os conflitos tendem a ser mais difceis de resolver quanto mais os valores da organizao forem
prximos ao Modelo I (ver captulo 3), no qual os conflitos tendem a ser escamoteados e a permanecerem laten-
tes gerando resistncia passiva, baixo comprometimento e alto custo psicolgico. Sero menos difceis quanto
mais os valores da organizao forem prximos ao Modelo II.


B.20) Rotatividade de pessoas da equipe

Significado:
Rotatividade de integrantes das equipes de desenvolvimento de software e da qualidade. Inclui tambm cresci-
mento rpido da equipe.
Comentrio analtico:
A ocorrncia deste fator foi relatada como barreira ao programa de MPS na medida em que com a sada das
pessoas o conhecimento/expertise dos processos tende a ser perdido e precisam ser recriados com os novos
integrantes.
Exemplo como barreira:
170
... num perodo curto, num perodo de um ano que eu trabalhei na empresa, eu trabalhei com 3 gerentes (refere-
se a gerentes da qualidade) diferentes! ... A gente tinha uma alta rotatividade de pessoas o que impedia a gente
de conseguir institucionalizar os processos, porque a gente tentava fazer uma institucionalizao, treinava as
pessoas e as pessoas saiam com um ms e entravam novas pessoas, ficava difcil pra gente. As pessoas no
sabiam como era o processo, no tinham conhecimento prvio de ter trabalhado com processo antes, ento era
difcil.
(Bartolomeu, Engenheiro da Qualidade)
Relao com as Atividades Primrias de Interveno:
De acordo com os relatos, este fator ocorreu principalmente em funo de conjuntura financeira e do mercado
profissional. Nem sempre este fator tem relao direta com as tarefas primrias de Interveno. Todavia, um
ambiente organizacional pouco favorvel gerao de comprometimento interno pode favorecer a sada volun-
tria das pessoas da equipes e empresas.


B.21) Escopo de processos e projetos

Significado:
Escopo de projetos e reas de processo e equipes da organizao, escolhidos para MPS. Projeto Piloto escolhido
para implantao de MPS. Adequao ou inadequao deste escopo.
Comentrio analtico:
As mudanas propostas pelas aes de MPS normalmente requerem a sua execuo em um projeto de desen-
volvimento piloto. O teste piloto tambm pode incluir mais ou menos reas do processo de software e mais ou
menos equipes ao mesmo tempo. A escolha de escopos muito ousados para implantao inicial foi relatada
como barreira ao programa de MPS.
Exemplo como barreira:
Se voc escolher um projeto piloto voc tem duas coisas dois fatores n!? Escolher pessoas que acreditam, e o
projeto que vivel. Voc bota um projeto que vivel com um pessoal que acha que baboseira ou o inverso,
o pessoal acha que legal, mas o projeto invivel porque um projeto de alta presso, um cronograma muito
curto n!? Presses de custo muito grande e programa de tempo e muito mais o que vai acontecer!? Esse pesso-
al no vai conseguir focar n!? Porque ao mesmo tempo ele um projeto piloto, mas tem muito mais uma viso
de ser um projeto mais pra aprender do que ser um projeto pra realmente entregar no custo no prazo neh!? Eh
uma viso mais didtica. Se voc pega um projeto que piloto, mas ele critico pra organizao termina o
pessoal deixando o processo pra l pra poder atender o cliente porque critico n?! Ento acho que isso uma
coisa que a gente tambm tem batido muito nas coisas, nos projetos piloto. Olhar e dizer: isso d pra ser piloto,
isso no d pra ser piloto, o pessoal que d pra ser equipe piloto e no d pra ser equipe piloto, acho que por
a.
(Lauro, consultor de MPS)
Relao com as Atividades Primrias de Interveno:
Depende basicamente da gerao de informao vlida sobre o nvel de adequao do escopo de projetos e
processos envolvidos no programa de MPS, em termos de:
Riscos que aes de MPS podem trazer a projetos crticos;
Capacidade de apoio (orientao, mentoria) que a equipe da qualidade pode prestar s equipes de pro-
jetos envolvidas.

171
B.22) Revises / Inspees / Auditorias

Significado:
Revises, inspees, auditorias da execuo de processos de software e normas estabelecidas. Inspees de
cdigo. Ganho de qualidade e aprendizagem em funo destes fatores. Tenso e conflitos em funo destes
fatores.
Comentrio analtico:
Revises, inspees e auditorias so estratgias consagradas para gerar informao sobre como est o desempe-
nho das equipes em relao aos processos. Com base nela os processos podem ser melhorados e o conhecimen-
to de MPS incrementado. Todavia relatos das entrevistas mostram que a execuo destes procedimentos pode
trazer tenso e conflitos em funo da forma como so executados e as conseqncias de seus resultados: as
pessoas podem achar que esto tendo o seu desempenho julgado e podem achar que se est buscando culpa-
dos pelos problemas (e isso de fato pode vir a ocorrer). Estes procedimentos obtero to mais sucesso quanto
mais as pessoas percebam que os objetivos forem a gerao de informao visando a aprendizagem e melhoria.
Exemplo como facilitador:
h um ganho de produtividade, com certeza. Voc tem
uma diminuio de produtividade quando voc come-
a com inspeo... como teoria clssica de qualidade
na indstria, entendeu? Voc perde um pouco, mas
com o tempo, voc tende a ganhar, voc tende ter uma
maior previsibilidade no processo como um todo.
(Romero, Gerente de Projetos)
Exemplo como barreira:
Auditoria era um processo que a gente no estava
acostumado. Quando vinha um auditor, tinha gente
que ficava at nervoso. Auditor interno, seu colega de
trabalho de uma outra rea que vai l lhe auditar. Eu
acredito que isso tambm foi uma barreira: voc ter
um processo de auditoria... Como se fosse uma prova,
n?! Hoje em dia no! J est natural. Antes era um
estresse! Isso atrapalhou um pouco, at era uma preo-
cupao para a certificao.
(Flvia, Gerente de Desenvolvimento de Software)
Relao com as Atividades Primrias de Interveno:
Revises, inspees e auditorias so estratgias diretas de gerao de informao vlida e til. Elas tendero a
ser to mais aceitas e produtivas quanto sua implementao for voltada para a gerao de aprendizagem e co-
nhecimento e menos para punies e busca de culpados pelos problemas.


B.23) Viabilizao de iniciativas da equipe

Significado:
Viabilizao, apoio e abertura para iniciativas de MPS vindas da prpria equipe de desenvolvimento de softwa-
re. Insuficincia ou falta deste fator.
Exemplo como facilitador:
Em alguns casos, os desenvolvedores propem (refe-
re-se a melhorias). Por exemplo, a ferramenta pra
gerencia de configurao: a gente comeou a usar o
CVS pra algumas coisas especficas. Eles propuseram
o SubVersion e eles comearam a liderar isso e a
gente s foi trabalhando junto, ento, foi um trabalho
junto de avaliao do piloto pra substituio. Ento
assim, pode vir proposta deles, a gente s respons-
vel por encaminhar o processo, validar e implementar
mesmo.
(Silvana, Gerente da Qualidade)
Exemplo como barreira:
... com relao a rodar o procedimento, no houve o
apoio para que a gente pudesse roda. Ento a gente
dizia (para o gerente do projeto): olha a gente vai
executar o procedimento de planejamento de projeto.
Ai o nosso gerente: "no d pra executar porque isso
vai comprometer o tempo o projeto"... Ele no queria
comprometer essa entrega com uma srie de ativida-
des podiam prejudicar a entrega. Ento ele j dizia:
infelizmente voc no pode carregar isso a no. E a
gente: No! Mas eu quero assumir, nem que trabalhe
at, por exemplo, 6 e meia, 7 horas em determinada
atividade. No, eu no quero que vocs faam isso
(disse o gerente). (Lima, Analista de Sistemas, mem-
bro de SEPG).
172
(Lima, Analista de Sistemas, membro de SEPG)
Relao com as Atividades Primrias de Interveno:
Este fator depende da gerao de informao vlida e til sobre os objetivos e potenciais benefcios das inici-
ativas em questo para estas venham a obter a deciso (escolha informada) e comprometimento em viabilizar
a iniciativa.


B.24) Esquemas de recompensa

Significado:
Esquemas que vinculam recompensas a pessoas ou equipes ao seu desempenho no esforo de MPS.
Exemplo como facilitador:
... A empresa tinha uma rea de Qualidade Organizacional que pressionava as demais e fazia com que as pesso-
as... Esses departamentos locais precisassem se certificar pra que, por exemplo, as pessoas tivessem direito
participao nos lucros da empresa. Ou seja, eles tentavam puxar pelo bolso, n? Simplesmente se voc... eles
alegavam o seguinte: se voc... se algo... tinha l... vamos definir assim: no ano de 2006, tais e tais e tais setores
da empresa, de tais regionais tm que ser avaliados positivamente e se no forem, toda a empresa vai ser preju-
dicada, ningum vai receber participao nos lucros das empresas.
(Bartolomeu, Engenheiro da Qualidade)
Relao com as Atividades Primrias de Interveno:
Recompensas materiais em geral tendem a gerar comprometimento externo nos participantes que uma forma
menos potente e mais fugaz de comprometimento. Recomenda-se compreender o sistema de recompensas de
forma abrangente de forma a incluir aquilo que recompensado (no necessariamente de forma explcita, for-
mal) pela organizao em termos de aes e resultados. Para desenvolver sua competncia ao longo do tempo a
organizao deve buscar recompensar (valorizar) estratgias de gerao de informao vlida e til, escolha
livre e informada e comprometimento interno. O sistema normativo explcito e tcito da organizao deve ser
investigado gerando informao vlida e til sobre conflitos entre os objetivos de MPS e da organizao como
um todo.

173
APNDICE C ARQUTIPOS SISTMICOS
Este apndice traz uma breve descrio da estrutura genrica dos arqutipos sis-
tmicos apresentados no Captulo 3. Para tanto, introduz tambm os elementos conceituais
que compem os diagramas dos arqutipos. Arqutipos sistmicos so estruturas sistmicas
genricas compostas por relaes de causa-efeito cclicas que se repetem em diferentes con-
textos (Senge, 2001, Captulo 6). Eles podem ser teis para dar sentido a situaes complexas
das organizaes, que esto sob influncia de mltiplos fatores interligados ao longo do tem-
po.
C.1) Elementos Componentes da Linguagem dos Diagramas Sistmicos
Os elementos que compem a linguagem dos diagramas sistmicos so os seguin-
tes (Senge, 2001, Captulo 5) (Valena e Associados, 1999, Captulo 1, Pg 31):
o Variveis: so fatores relevantes dos sistemas, subjacentes realidade em
anlise. So indicadores (quantitativos ou qualitativos) que representam nveis
variveis da ocorrncia de um determinado fenmeno ao longo do tempo. A-
presentam-se como sentenas sintticas do fenmeno representado. Exs:
Tempo e Recursos para MPS, Apoio e comprometimento da equipe de de-
senvolvimento.
o Relaes Causais: so relaes de causa-efeito entre as variveis. So repre-
sentadas por setas entre as variveis. Estas relaes podem ser causa-efeito di-
retamente proporcional, representadas pelo sinal + no final da seta, ou in-
versamente proporcional, representadas pelo sinal -.
o Tempos de Retardo: indicam que a relao de causa-efeito no se faz perce-
ber imediatamente e requer certo tempo para isto acontecer. So representados
por traos cortando as setas que representam as relaes causais, e/ou a ilus-
trao de um relgio junto seta.
o Ciclos ou Loops Causais: ocorrem quando uma seqncia relaes de causa-
efeito forma um circuito. So os elementos centrais que causam o comporta-
mento dos arqutipos sistmicos ao longo do tempo. Estes circuitos podem ser
de dois tipos:
174
o Reforo (R) que implicam na ampliao (crescente ou decrescente) ou
reforo mtuo das variveis do sistema. Tm o efeito de causar o cres-
cimento ou decrescimento exponencial das variveis do sistema. So
responsveis pelos ciclos de mudana dos sistemas. Podem representar
ciclos virtuosos, quando causam mudanas boas para o sistema, ou,
viciosos que causam mudanas indesejveis ao sistema.
o Balanceamento (B), tambm conhecido como ciclos de equilbrio.
Normalmente, tm o efeito de levar os sistemas para uma situao de
equilbrio. Por este motivo, tendem a limitar a ao dos ciclos de refor-
o.
C.2) Arqutipo do Limite ao Sucesso
Tambm conhecido como limite ao crescimento, este arqutipo sistmico possui o
seguinte padro de estrutura (Senge, 2001, Apndice 2, pg. 408) (Valena e Associados,
1999, Captulo 2, pg. 40):
Efeito do
crescimento
(sucesso)
Ao
promovedora
do crescimento
Consequncias
no-intencionadas
+
B
R
+
+
-
Fatores
limitantes

Figura C.1: Estrutura genrica do arqutipo da limitao ao crescimento.
Este arqutipo representa situaes em que o sucesso ou crescimento inicial de
certa iniciativa vem a encontrar barreiras (normalmente imprevistas) que limitam este sucesso
ou crescimento. A estrutura deste arqutipo possui dois componentes principais: um ciclo de
reforo (lado esquerdo do diagrama acima) que produz o sucesso ou crescimento inicial, e um
ciclo de balanceamento (lado direito do diagrama), que, aps certo tempo, freia ou limita o
sucesso inicial. Normalmente este ciclo de balanceamento est sob a influncia de fatores
limitantes externos sobre os quais os agentes do sistema tm pouco controle.

175
C.3) Arqutipo da Transferncia do Fardo
Tambm conhecido como transferncia de responsabilidade este arqutipo sist-
mico possui o seguinte padro de estrutura (Senge, 2001, Apndice 2, pg. 409) (Valena e
Associados, 1999, Captulo 2, pg. 47):
Sintoma do
problema
Soluo
sintomtica
Soluo
fundamental
Conseqncias
no-intencionadas
+
-
+
-
+
-
B
B
R

Figura C.2: Estrutura genrica do arqutipo da transferncia do fardo.
Este arqutipo representa situaes em que aes corretivas em resposta a um pro-
blema so tomadas visando uma soluo sintomtica que parece mais fcil ou atrativa, em
vez de uma soluo mais fundamental que tende a ser mais difcil, demorada ou simplesmente
no identificada. A recorrncia soluo sintomtica que inicialmente parece resolver o pro-
blema, costuma causar efeitos colaterais (conseqncias no intencionadas) que depois de
um tempo voltam a causar o problema e em longo prazo dificultam a soluo fundamental. O
arqutipo pode ser visto simplificadamente em termos da composio das seguintes estrutu-
ras: (1) o sintoma do problema: uma ou um conjunto variveis normalmente colocados na
parte central do diagrama; (2) um ciclo de balanceamento da soluo sintomtica (parte supe-
rior do diagrama); (3) um ciclo de balanceamento da soluo fundamental (parte inferior do
diagrama); e (4) um ciclo de reforo vicioso das conseqncias no intencionadas (que envol-
ve todo o diagrama).


176
C.4) Arqutipo dos Adversrios Acidentais
Este arqutipo sistmico possui o seguinte padro de estrutura (Senge e outros,
1997, pg. 145), (Valena e Associados, 1999, Captulo 2, pg. 59):
Sucesso
de A
Ao de A que
favorece B
Sucesso
de B
Ao de B que
favorece A
+
+
+
Consequncias
no intencionadas
da ao de A
Ao
individualista
de B
+
+
R1
R2
R3
Ao
individualista
de A
+
+
+
B1
B2
+
Consequncias
no intencionadas
da ao de B
-
-

Figura C.3: Estrutura genrica do arqutipo dos adversrios acidentais.
Este tipo de arqutipo ocorre quando atores ou grupos de atores que deveriam ser
parceiros, acabam por prejudicar-se um ao outro em vez de concorrerem para o sucesso m-
tuo, quando tendem a adotar aes individualistas. Como resultado disto, ambas as partes e o
sistema como um todo obtm um nvel global de desempenho menor do que o esperado. Sua
estrutura pode ser vista assim: (1) um ciclo de reforo virtuoso que favorvel a ambas as
partes (R1, o ciclo mais externo no diagrama acima); (2) ciclos de reforo das aes individu-
alistas das partes (R2 e R3 no diagrama) que favorecem cada parte individualmente mas atra-
palham a outra; e (3) ciclos de balanceamento que so conseqncias das aes individualistas
das partes e fazem com que o desempenho global seja prejudicado.