UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMTICA PS-GRADUAO EM CINCIA DA COMPUTAO

FELIPE SANTANA FURTADO SOARES

SISTEMAS DE RECOMPENSA COMO ESTRATGIA DE MELHORIA DE PRODUTIVIDADE EM ORGANIZAES DE SOFTWARE

RECIFE 2009

FELIPE SANTANA FURTADO SOARES

SISTEMAS DE RECOMPENSA COMO ESTRATGIA DE MELHORIA DE PRODUTIVIDADE EM ORGANIZAES DE SOFTWARE

Dissertao apresentada ao Programa de Ps-Graduao em Cincia da Computao, do Centro de Informtica, da Universidade Federal de Pernambuco UFPE/CIn, como requisito parcial para a obteno do ttulo de Mestre em Cincia da Computao.

Orientador: Prof. Dr. Slvio Romero de Lemos Meira

RECIFE 2009 ii

Dedico este trabalho a minha famlia.

iii

AGRADECIMENTOS

Este trabalho fruto de um incentivo pela busca de uma educao contnua sempre estimulada pelos meus pais, Paulo e Margarida. Agradeo, inicialmente, a eles pelo suporte incondicional. Envolvidos nessa mesma busca, agradeo o apoio dos meus irmos, Paulinho, Gabriel e Lucas. E a minha av, Anayd, sempre orando para dar tudo certo. A minha esposa, Ana Paula, pela inspirao provocada atravs da admirao que sinto por ela. E o nosso filho, Pedro, que nasceu na minha primeira semana de aula no Curso de Mestrado e que, agora, est iniciando seu primeiro ano de escola. Os meus agradecimentos so tambm para: Os professores Slvio Meira, pela confiana e pela oportunidade que me concedeu e Jones Albuquerque, pelas orientaes nas primeiras pesquisas. Gibeon Aquino, pelas orientaes, sugestes e incentivo ao longo de todo o trabalho de pesquisa. E a todos do grupo de pesquisa ProSE, Jeane Mendes, Joelza Vasconcelos, Manu Aleixo, Renata Alchorne, Romeu Guimares e Suzana Sampaio, pela oportunidade da troca de conhecimento. Os amigos do C.E.S.A.R, Teresa Maciel, Ana Sofia e Izabella Lyra, pelo incentivo, apoio e conversas ao longo dessa caminhada. Os amigos do CIN, Leila Mariz, Daniel Thiago, Petrus Bastos e Yguarat Cavalcanti, pela oportunidade de trabalhar na fbrica de software O3S. Graa Barbosa, pela ateno e disponibilidade para conversar sobre programas de recompensa. E para a equipe de Qualidade do C.E.S.A.R, Alessandra Mendes, Ana Carla, Andrea Pinto, Beth Morais, Bruno Freitas, Cibele Atade, Cuca Valadares, Mariana Xavier, Paula Ferreira e Valria Moura, pelo apoio dado durante os perodos de ausncia.

iv

The main problem for most incentive systems in use in real organizations is not noise in measures of performance but, rather, bias intentionally introduced by those being measured (AUSTIN, 1996).

Resumo comum nas empresas de desenvolvimento de software o interesse da alta direo em definir programas para medio da performance organizacional. Esse interesse est relacionado com a necessidade de acompanhar se os resultados das equipes esto alinhados com as metas estratgicas organizacionais e se esto alcanando os nveis de produtividade esperados, sejam financeiros, de satisfao do cliente, qualidade do produto, entre outros. Nesse contexto, as organizaes de desenvolvimento de software tm buscado diversas estratgias para aumento de sua produtividade, atravs do reuso de artefatos, implantao de ferramentas no processo de desenvolvimento de software etc. Porm, h evidncia emprica que sugere que programas de recompensas influenciam o comportamento e a performance dos membros das organizaes. Uma estratgia que vem ganhando destaque o uso dos indicadores presentes nos programas de medio como forma de definir um sistema de recompensa, tambm conhecido como sistema de incentivo, que estimule a motivao das equipes atravs de compensaes financeiras, promoes, prmios ou benefcios. Com o objetivo de explorar mais essa estratgia com dimenses menos voltadas para os aspectos tcnicos e com maior nfase nos aspectos culturais, sociais e psicolgicos, este trabalho fornece um conjunto de recomendaes, em forma de guidelines, com o objetivo de orientar os gestores a definirem e implantarem um programa de recompensa como parte da estratgia organizacional de aumento de produtividade das equipes nos projetos de desenvolvimento de software. Alm disso, tambm aborda os impactos negativos que tais programas podem causar na produtividade das equipes quando so mal aplicados, gerando o efeito da disfuno do sistema de medio.

Palavras-chave Produtividade. Sistemas de Recompensa. Sistemas de Incentivo. Sistemas de Medio. Disfuno.

vi

Abstract It is common in software development businesses for top management to be interested in setting up programs for measuring organizational performance. This interest is related to the need to monitor if the results from teams are aligned with organizational strategic goals and are achieving the expected levels of productivity, whether these be on: financial matters, client satisfaction, product quality, and so forth. In this context, software development organizations have tried various strategies to increase their productivity through the reuse of artifacts, the implementation of tools in the development of software etc. However, there is empirical evidence which suggests that reward programs affect the behavior and performance of the members of organizations. One strategy that has been gaining prominence is the use of indicators present in measurement programs as a way to define a reward system, also known as an incentive system, which stimulates the motivation of teams through financial compensation, promotions, awards or benefits. With the aim of exploring this strategy further by using dimensions less targeted on the technical aspects and placing more emphasis on cultural, social and psychological aspects, this study provides a set of recommendations, in the form of guidelines. They seek to guide managers in how to define and implement a reward program as part of the organizational strategy for increasing team productivity in software development projects. This study also addresses the negative impacts that such programs may cause on the productivity of teams when they are poorly implemented, and thus occasion a dysfunction effect in the measurement system.

Key-words Productivity. Dysfunction. Reward Systems. Incentive Systems. Measurement Systems.

vii

SUMRIO
1 INTRODUO....................................................................................................1 1.1 Motivao ........................................................................................................1 1.2 Problema .........................................................................................................2 1.2.1 Contexto .....................................................................................................3 1.3 Justificativa ......................................................................................................5 1.4 Contribuies...................................................................................................8 1.5 Estrutura da Dissertao .................................................................................8 2 SISTEMAS DE MEDIO................................................................................10 2.1 Medio, Medida, Mtrica e Indicador...........................................................10 2.2 Produtividade.................................................................................................13 2.3 Sistemas de Medio ....................................................................................13 2.3.1 As reais intenes de um Sistema de Medio ........................................15 2.3.2 Balanced Scorecard .................................................................................17 2.3.3 Goal Question Metric................................................................................19 2.3.4 Practical Software and Systems Measurement ........................................19 2.3.4.1 CMMI e ISO/IEC 15939.................................................................20 2.3.5 Disfuno em Sistemas de Medio ........................................................22 2.4 Consideraes Finais ....................................................................................24 3 SISTEMAS DE RECOMPENSA .......................................................................25 3.1 Recompensa .................................................................................................25 3.1.1 Remunerao ...........................................................................................30 3.2 Motivao ......................................................................................................33 3.2.1 Teoria da Hierarquia das Necessidades...................................................34 3.2.2 Teoria da Expectativa...............................................................................36 3.2.3 Motivao na Engenharia de Software.....................................................38 3.3 Sistemas de Recompensa Viso Geral ......................................................41 3.3.1 Sistemas de Recompensa e a Gesto do Conhecimento ........................48 3.3.2 Sistemas de Recompensa em Organizaes de Software.......................49 3.4 Consideraes Finais ....................................................................................56 4 RECOMENDAES PARA IMPLANTAO DE UM SISTEMA DE RECOMPENSA EM ORGANIZAES DE SOFTWARE ................................58 4.1 Entendimento dos Aspectos Motivacionais dos Indivduos ...........................63 4.1.1 Problema ..................................................................................................63 viii

4.1.2 Descrio .................................................................................................63 4.1.3 Benefcios da Adoo...............................................................................64 4.1.4 Requisitos Mnimos para Adoo .............................................................64 4.1.5 Forma de Adoo .....................................................................................64 4.1.6 Custos e Problemas .................................................................................65 4.1.7 Guidelines Relacionados..........................................................................65 4.2 Definio Clara do Plano de Remunerao Varivel.....................................65 4.2.1 Problema ..................................................................................................65 4.2.2 Descrio .................................................................................................65 4.2.3 Benefcios da Adoo...............................................................................66 4.2.4 Requisitos Mnimos para Adoo .............................................................66 4.2.5 Forma de Adoo .....................................................................................66 4.2.6 Custos e Problemas .................................................................................68 4.2.7 Guidelines Relacionados..........................................................................69 4.3 Definio de Baselines de Comparao para Mtricas de Produtividade .....69 4.3.1 Problema ..................................................................................................69 4.3.2 Descrio .................................................................................................69 4.3.3 Benefcios da Adoo...............................................................................70 4.3.4 Requisitos Mnimos para Adoo .............................................................71 4.3.5 Forma de Adoo .....................................................................................71 4.3.6 Custos e Problemas .................................................................................72 4.3.7 Guidelines Relacionados..........................................................................72 4.4 Identificao dos Participantes na Venda do Projeto ....................................72 4.4.1 Problema ..................................................................................................72 4.4.2 Descrio .................................................................................................73 4.4.3 Benefcios da Adoo...............................................................................73 4.4.4 Requisitos Mnimos para Adoo .............................................................73 4.4.5 Forma de Adoo .....................................................................................74 4.4.6 Custos e Problemas .................................................................................74 4.4.7 Guidelines Relacionados..........................................................................75 4.5 Definio do Sucesso do Projeto...................................................................75 4.5.1 Problema ..................................................................................................75 4.5.2 Descrio .................................................................................................75 4.5.3 Benefcios da Adoo...............................................................................76 ix

4.5.4 Requisitos Mnimos para Adoo .............................................................76 4.5.5 Forma de Adoo .....................................................................................76 4.5.6 Custos e Problemas .................................................................................79 4.5.7 Guidelines Relacionados..........................................................................79 4.6 Definio do Modelo de Gerenciamento da Equipe ......................................79 4.6.1 Problema ..................................................................................................79 4.6.2 Descrio .................................................................................................79 4.6.3 Benefcios da Adoo...............................................................................80 4.6.4 Requisitos Mnimos para Adoo .............................................................80 4.6.5 Forma de Adoo .....................................................................................80 4.6.6 Custos e Problemas .................................................................................81 4.6.7 Guidelines Relacionados..........................................................................82 4.7 Definio dos Indicadores de Performance...................................................83 4.7.1 Problema ..................................................................................................83 4.7.2 Descrio .................................................................................................83 4.7.3 Benefcios da Adoo...............................................................................83 4.7.4 Requisitos Mnimos para Adoo .............................................................84 4.7.5 Forma de Adoo .....................................................................................84 4.7.6 Custos e Problemas .................................................................................84 4.7.7 Guidelines Relacionados..........................................................................85 4.8 Implantao de um Comit Independente para Avaliao dos Resultados.....................................................................................................85 4.8.1 Problema ..................................................................................................85 4.8.2 Descrio .................................................................................................86 4.8.3 Benefcios da Adoo...............................................................................86 4.8.4 Requisitos Mnimos para Adoo .............................................................87 4.8.5 Forma de Adoo .....................................................................................87 4.8.6 Custos e Problemas .................................................................................87 4.8.7 Guidelines Relacionados..........................................................................88 4.9 Relacionamento entre os Guidelines.............................................................89 4.10 Consideraes Finais ....................................................................................91 5 VALIDAO DOS GUIDELINES .....................................................................93 5.1 Metodologia Utilizada ....................................................................................93 5.2 Anlise dos Dados.........................................................................................97 x

5.2.1 Anlise do Perfil das Empresas e dos Entrevistados ...............................97 5.2.2 Anlise da Pesquisa em Campo.............................................................100 5.3 Correlao entre as Questes e as Caractersticas das Empresas ............108 5.4 Limitaes da Pesquisa...............................................................................109 5.5 Consideraes Finais ..................................................................................109 6 CONCLUSES E TRABALHOS FUTUROS..................................................112 6.1 Trabalhos Futuros .......................................................................................114 REFERNCIAS.......................................................................................................116

xi

LISTA DE ILUSTRAES

Figura 1.1 Contexto da proposta...........................................................................................................5 Figura 1.2 Linha do tempo relacionada com algumas estratgias de melhoria de produtividade. .................................................................................................................7 Figura 2.1 Nveis do processo de medio (adaptada da ISO/IEC 15939 Software Measurement Process).................................................................................................11 Figura 2.2 Detalhamento dos nveis do processo de medio (adaptada da ISO/IEC 15939 Software Measurement Process). .............................................................................12 Figura 2.3 Pesquisa sobre a quantidade de sucesso e falha nos programas de medio (adaptada de DEKKERS, 2000). ..................................................................................15 Figura 2.4 As quatro perspectivas do Balanced Scorecard (extrada de NORTON E KAPLAN, 1996). ...........................................................................................................18 Figura 2.5 Modelo do Goal Question Metric (extrada de BASILI, CALDIERA E ROMBAC, 2001).............................................................................................................................19 Figura 2.6 Escopo do Practical Software and System Measurement (extrada de PSM, 2003).............................................................................................................................20 Figura 2.7 Relacionamento entre PSM, ISO/IEC 15939 e CMMI (extrada de PSM, 2003). .............21 Figura 2.8 O efeito da disfuno em sistemas de medio (extrada de AUSTIN, 1996). .................23 Figura 3.1 Principais modelos de remunerao varivel (adaptada de XAVIER, SILVA E NAKAHARA, 1999).......................................................................................................33 Figura 3.2 Pirmide de Maslow (extrada de FRANA et AL, 2002)..................................................35 Figura 3.3 Teoria da Expectativa (adaptada de ROBBINS, 1999). ....................................................37 Figura 3.4 Relao entre duas dimenses em um sistema de incentivo (extrada de AUSTIN, 1996). ............................................................................................................45 Figura 3.5 Pesquisa sobre poltica de incentivos em TI. As razes para justificar a parcela varivel no vencimento (extrada de ANETIE, 2004). ..................................................50 Figura 3.6 Modelo para mensurar sucesso em projetos open source (extrada de CROWSTON, 2003). ....................................................................................................54 Figura 4.1 Principais etapas da definio e validao dos guidelines................................................59 Figura 4.2 Escopo e fases dos guidelines, segundo os grupos de processo de gerenciamento de projetos do PMBOK (adaptada de PMBOK, 2004). .......................62 Figura 4.3 Exemplo de indicador de produtividade.............................................................................71 Figura 4.4 Dependncia do sucesso do projeto em funo do tempo de completude (extrada de SHENHAR E RENIER, 2002)...................................................................78 Figura 4.5 Notao utilizada para ilustrar o relacionamento entre os guidelines. ..............................89 Figura 4.6 Relacionamento entre os guidelines..................................................................................90 Figura 5.1 Perfil dos participantes pesquisados. ................................................................................97 Figura 5.2 Localizao das empresas por regio geogrfica. ............................................................98

xii

Figura 5.3 Tempo de mercado das empresas. ...................................................................................99 Figura 5.4 Tamanho das empresas. ...................................................................................................99 Figura 5.5 Consolidao da 5 questo da pesquisa de campo.......................................................101 Figura 5.6 Consolidao da 6 questo da pesquisa de campo.......................................................101 Figura 5.7 Consolidao da 7 questo da pesquisa de campo.......................................................102 Figura 5.8 Consolidao da 8 questo da pesquisa de campo.......................................................103 Figura 5.9 Consolidao da 2 questo da pesquisa de campo.......................................................104 Figura 5.10 Consolidao da 3 questo da pesquisa de campo.....................................................105 Figura 5.11 Consolidao da 4 questo da pesquisa de campo.....................................................106 Figura 5.12 Consolidao da 9 questo da pesquisa de campo.....................................................107 Figura 5.13 Consolidao da 10 questo da pesquisa de campo...................................................108 Figura 5.14 Consolidao em cinco nveis das oito questes da pesquisa de campo que possuem a mesma escala das opes de respostas.................................................110 Figura 5.15 Consolidao em trs nveis das oito questes da pesquisa de campo que possuem a mesma escala das opes de respostas.................................................110

xiii

LISTA DE TABELAS
Tabela 3.1 Fatores que motivam os engenheiros de software (extrada de SHARP et AL, 2008).............................................................................................................................40 Tabela 3.2 Consequncias da motivao dos engenheiros de software (extrada de SHARP et AL, 2008). .................................................................................................................40 Tabela 3.3 Relao de mtricas por categoria (extrada de WILLARD, 2006)......................................53 Tabela 3.4 Relao de indicadores de sucesso para projetos open source (extrada de CROWSTON, 2003). ....................................................................................................55 Tabela 3.5 Critrios para sistemas de recompensa em organizaes de software (extrada de CLINCY, 2003). .......................................................................................................55 Tabela 4.1 Tipos dos guidelines.............................................................................................................61 Tabela 4.2 Lista dos guidelines..............................................................................................................62 Tabela 4.3 Descrio dos papis. ..........................................................................................................63 Tabela 4.4 Critrios de sucesso do projeto (extrada de SHENHAR E RENIER, 2002). ......................77 Tabela 5.1 Relacionamento entre a pesquisa de campo e os guidelines. ............................................96

xiv

ABREVIATURAS
Sigla BSC CMMI GQM IEC IEEE IPD-CMM ISO LOC PF MA MPS-BR PMBOK PPR PSM RH ROI RV SECM SPI SW-CMM TI TIC UCP VIE Significado Balanced Scorecard Capability Maturity Model Integration Goal Question Metric International Electrotechnical Commission Institute of Electrical and Electronics Engineers Integrated Product Development Capability Maturity Model International Organization for Standardization Lines of Code Pontos de Funo Medio e Anlise Melhoria de Processo de Software - Brasileiro Project Management Body of Knowledge Participao nos Resultados Practical Software and Systems Measurement Recursos Humanos Return on Investment Remunerao Varivel Systems Engineering Capability Model Schedule Performance Index Capability Maturity Model for Software Tecnologia da Informao Tecnologia da Informao e Comunicao Use Case Points Valncia, Instrumentalidade e Expectativa

xv

INTRODUO
Este captulo descreve a motivao do presente trabalho, o problema que se

pretende resolver, ressaltando o contexto especfico, alm das justificativas para a proposta relacionada e suas principais contribuies. 1.1 Motivao Desde a conferncia conhecida por discutir a crise do software1 (NAUR e RANDELL, 1969), ocorrida no final da dcada de 60, apesar de as melhorias na produtividade serem difceis de se quantificar, pde-se acompanhar o avano na engenharia de software, atravs da evoluo dos processos, ferramentas e tecnologias. Ainda assim, os problemas relacionados com custo, prazo, escopo e qualidade se mantm em projetos de software (SOMMERVILLE, 2007). De acordo com o relatrio The Chaos Report (STANDISH GROUP, 2009) os resultados mostram uma diminuio nas taxas de sucesso dos projetos, com 32% dos projetos com sucesso que so entregues no prazo, dentro do oramento e com os requisitos requeridos; 44% foram projetos desafiados, ou seja, entregues atrasados, alm do oramento planejado e/ou com menos requisitos entregues; e, por fim, 24% falharam, ou seja, foram cancelados ou entregues e nunca utilizados. Nesse contexto, o mercado exige prazos e custos cada vez mais competitivos, demandando um ambiente de alta qualidade e produtividade. Para propiciar esse ambiente e obter ganhos significativos de produtividade, requerido um programa integrado de iniciativas entre diversas reas que incluem melhorias em

A crise do software foi um termo utilizado nos anos 70, quando a engenharia de software

era praticamente inexistente. O termo expressava as dificuldades do desenvolvimento de software frente ao rpido crescimento da demanda por software, da complexidade dos problemas a serem resolvidos e da inexistncia de tcnicas estabelecidas para o desenvolvimento de sistemas que funcionassem adequadamente ou pudessem ser validados (SOMMERVILLE, 2007).

ferramentas, metodologia, ambiente de trabalho, educao, gerenciamento, reuso e incentivos pessoais (BOEHM et AL, 1982). 1.2 Problema No sentido de melhorar os resultados dos projetos, a alta direo das empresas de desenvolvimento de software define programas para medio e melhoria da produtividade. Esse interesse est relacionado com a necessidade de acompanhar se os resultados das equipes esto alinhados com as metas estratgicas organizacionais e se esto alcanando os nveis de produtividade esperados, como, por exemplo, nveis financeiros, de satisfao do cliente, de qualidade do produto, entre outros (AUSTIN, 1996). Ridgway (1956) j relatou em seus estudos a existncia de uma forte tendncia para identificar o maior nmero possvel de variveis para definio de indicadores, baseado na idia de que se os objetivos da organizao podem ser medidos, os esforos e recursos envolvidos podem ser gerenciados de forma mais racional. Utilizar medidas quantitativas de performance , de fato, importante, mas o uso indiscriminado pode resultar na falta de conhecimentos suficientes e causar distores no sistema de medio. Quase 50 anos depois dos estudos realizados por Ridgway, Jackson (2005) afirma que um dos principais problemas com os indicadores para medio da performance continua sendo a escolha daqueles que so fceis de medir ao invs daqueles que, de fato, so representativos para a organizao. Nesse contexto, este trabalho busca responder seguinte perguntaproblema: No sentido de estimular o aumento da produtividade, sistemas de recompensa so eficazes como parte da estratgia organizacional de melhoria de produtividade de uma empresa de software2? E, ainda, quais so as boas prticas

Este trabalho considera as empresas de software como sendo as que desenvolvem

software para uso prprio ou desenvolvem software sob encomenda para atender os requisitos especficos de um cliente (http://www.mct.gov.br/index.php/content/view/2867.html).

que devem ser consideradas e as armadilhas que precisam ser evitadas na implantao de um sistema de recompensa? Para responder a essas perguntas, este trabalho fornece um conjunto de recomendaes, no formato de guidelines, que podem orientar os gestores a definirem e implantarem um programa de recompensa, numa organizao, como parte da estratgia organizacional de aumento de produtividade das equipes nos projetos de desenvolvimento de software. Alm disso, tambm aborda os impactos negativos que esses programas podem causar na produtividade das equipes, gerando o efeito da disfuno do sistema de medio, quando os indicadores so mal definidos ou mal utilizados. 1.2.1 Contexto Este trabalho foi desenvolvido em conjunto com o grupo de pesquisa ProSE3, cujo objetivo investigar e desenvolver o estado da arte e prticas relacionadas com produtividade em organizaes que desenvolvem software. O grupo atua em trs linhas de pesquisa: anlise de produtividade (mtricas de produtividade e fatores que afetam a produtividade); tcnicas, processos, ferramentas e ambientes para a melhoria de produtividade; e estimativa e medio de software. Com base nas pesquisas e estudos analisados pelo ProSE, a Figura 1.1 apresenta uma viso geral de como o problema da produtividade foi mapeado atravs de um framework que contm um conjunto de solues para que as organizaes desempenhem um programa efetivo de produtividade. Ele composto pelas seguintes partes: Infraestrutura para programas de medio de produtividade: definio de recursos (ferramentas, papis e responsabilidades, hardware etc.)

ProSE

Productivity

in

Software

Engineering

(http://prose.cesar.org.br

http://www.mct.gov.br/index.php/content/view/2867.html).

que d suporte implantao de um programa de mtricas de produtividade; Implantao de programa de mtricas de produtividade: definio de um modelo baseado em mtricas que possibilite a avaliao de produtividade em diferentes projetos; Mtricas de produtividade: definio de mtricas que avalie a produtividade dos projetos de desenvolvimento de software; Qualidade de cdigo e produtividade: anlise da influncia da qualidade do cdigo de software na produtividade do time, atravs de um exame das mtricas de cdigo que influenciam na qualidade da arquitetura e mtricas de cdigo que influenciam na produtividade; Fatores de produtividade: elaborao de um catlogo completo e consistente contendo informaes sobre os principais fatores que influenciam na produtividade. Espera-se que este catlogo possa servir como guia para as organizaes que desejam iniciar programas de melhoria de produtividade em projetos de desenvolvimento de software; Estratgias de melhoria de produtividade: propiciar uma viso sistmica sobre as prticas relacionadas produtividade no desenvolvimento de software, permitindo uma documentao da correlao entre as solues; Modelo de melhoria de produtividade: propor um modelo de melhoria contnua de produtividade seguindo os padres utilizados pelo CMMI (SEI, 2006) e MPS-BR (SOFTEX, 2006); Sistemas de Recompensa.

Figura 1.1 Contexto da proposta .

Baseado nesse contexto, os sistemas de recompensa so o foco deste estudo, com o objetivo de ser uma das estratgias de melhoria de produtividade em organizaes de software. A partir da correta definio e implantao de um sistema de recompensa, tambm conhecido como sistema de incentivo, a organizao procura medir alguns aspectos relacionados com a produtividade da equipe. Com base nessas medidas, as equipes so recompensadas, por exemplo, atravs de reconhecimento financeiro, promoes, prmios e benefcios. Espera-se, portanto, obter um ganho de produtividade e, conseqentemente, melhoria na qualidade e nos ndices de desempenho dos projetos (AUSTIN, 1996). 1.3 Justificativa H vrias estratgias de melhoria de produtividade que so pesquisadas na rea de desenvolvimento de software. A grande maioria est relacionada com alguns fatores j estudados, que afetam a produtividade das equipes. Por exemplo:

ProSE Productivity in Software Engineering (http://prose.cesar.org.br).

Qualidade do gerenciamento: a baixa produtividade das equipes est diretamente relacionada ao mau gerenciamento do projeto (SCACCHI, 1984); Tamanho dos times: pequenos times tendem a ser mais produtivos (BEHRENS, 1983); Durao e tamanho do projeto: aumento da durao do projeto ou do tamanho tendem a diminuir a produtividade (MAXWELL et AL, 1996); Uso de ferramentas: os impactos de aumento ou diminuio da produtividade relacionados com a implantao de ferramentas no processo de desenvolvimento do software (BRUCKHAUS et AL, 1996); Reuso de artefatos de software (BOEHM, 1999); Instabilidade dos requisitos (YU et AL, 1991) e da arquitetura do software (CAIN E MCCRINDLE, 2002). Porm, alm das reas relacionadas com ferramentas, metodologias, ambiente de trabalho, gerenciamento e reuso, a rea de incentivos pessoais, levantada em estudo de Boehm (BOEHM et AL ,1982), deve ser considerada como uma das iniciativas a ser integrada em um programa de melhoria significativa de produtividade. Alinhado com esse mesmo pensamento de Boehm, em suas pesquisas sobre produtividade de times, DeMarco relata que os principais problemas do nosso trabalho no so apenas de natureza tecnolgica. Muitos so de natureza sociolgica (DEMARCO, 1999). As teorias da motivao defendem que as pessoas que contribuem mais para uma empresa devem receber mais por isso (CAMPBELL, 1998). Essa expectativa tem uma influncia significativa na concepo de sistemas de incentivo e os programas de pagamento por mrito refletem essa influncia. No entanto, nem sempre atingem seus objetivos.

Clincy (2003) ressaltou algumas reas que podem aumentar a produtividade no desenvolvimento de software: processos de desenvolvimento de software, ferramentas de testes, definio da arquitetura e sistemas de recompensa. A Figura 1.2 ilustra os exemplos citados acima atravs de uma linha do tempo, entre 1982 e 2003.

Figura 1.2 Linha do tempo relacionada com algumas estratgias de melhoria de produtividade.

Com base nisso, a relevncia deste trabalho est relacionada ao fato de que as recomendaes propostas podem ser teis para a soluo de problemas do diaa-dia, que necessitam considerar a natureza dos sistemas de recompensa para se obter ganho de produtividade. Alm disso, esta pesquisa dar continuidade discusso de um tema que menos enfatizado na rea de software em referncia s demais estratgias de melhoria de produtividade, visto que atualmente est mais relacionada com os aspectos tecnolgicos. Ao mesmo tempo, esse tema bastante discutido e implementado nas disciplinas econmicas e sociais (HOLMSTROM E MILGORM, 1991; LAFFONT E MARTIMORT, 2002), onde vrios aspectos relacionados com incentivos j foram

aplicados e podem ser considerados como lies aprendidas para as organizaes de software. 1.4 Contribuies As seguintes contribuies foram geradas ao longo deste trabalho de pesquisa: Reviso da fundamentao terica relacionada com sistemas de incentivo, desde as teorias econmicas sobre incentivo nas empresas at o seu uso nas organizaes de software (FURTADO et AL, 2009a); Levantamento dos efeitos da disfuno dos sistemas de medio em organizaes de software (AQUINO et AL, 2009); Levantamento dos impactos da adoo de guidelines sobre sistemas de recompensa como uma das estratgias de melhoria de produtividade nas organizaes de software (FURTADO et AL, 2009b); Criao de guidelines e seus relacionamentos para orientar os gestores na definio e implantao de um programa de recompensa, em organizaes, sem causar disfuno do sistema de medio e, com isso, apoiar no aumento da produtividade das equipes em projetos de desenvolvimento de software. Para cada guideline foram sugeridas formas de adoo, alm de direcionar as principais fontes dos custos e os problemas envolvidos. 1.5 Estrutura da Dissertao Este trabalho est organizado da seguinte forma: O Captulo 2 descreve a fundamentao terica sobre os sistemas de medio e os principais conceitos relacionados com o tema, por exemplo: mtricas, indicadores, produtividade e disfuno;

O Captulo 3 apresenta uma reviso bibliogrfica sobre os sistemas de recompensa, iniciando pelas teorias econmicas e da administrao, at o uso deles em organizaes de software; O Captulo 4 apresenta a soluo proposta por este trabalho com uma srie de recomendaes, em formato de guidelines, que podem ser utilizados como estratgia para aumento de produtividade das organizaes de software; O Captulo 5 descreve como a proposta foi validada, a sua metodologia e a anlise dos resultados; O Captulo 6 descreve as concluses e os potenciais trabalhos futuros.

10

SISTEMAS DE MEDIO
Este captulo tem o objetivo de descrever, de forma geral, alguns conceitos

bsicos que sero mencionados ao longo deste trabalho, relacionados com produtividade, sistemas de medio e disfuno. Estes conceitos so teis para contextualizar as recomendaes propostas no Captulo 4. 2.1 Medio, Medida, Mtrica e Indicador A medio o ato ou o processo de medir as caractersticas de um projeto, um processo ou um produto. o processo no qual os nmeros ou smbolos so imputados aos atributos de entidades do mundo real, de forma a descrev-los de acordo com regras claramente definidas (FENTON, 1997). Medida um padro ou uma unidade de medio. um nmero ou smbolo conferido a uma entidade para caracterizar um atributo (FENTON, 1997). De acordo com o IEEE, so os valores quantitativos, reais ou estimados, que traduzem a extenso, o montante, a dimenso, a capacidade ou o tamanho de algum atributo de um processo, de um produto ou de um recurso (IEEE, 1990). Mtrica definida pelo IEEE como sendo a medida quantitativa do grau de um sistema, componente ou processo que possui determinado atributo (IEEE, 1990). Segundo Fenton (1997) so informaes sobre os atributos de entidades. A mtrica geralmente composta por duas ou mais medidas. Um exemplo de mtrica o nmero de defeitos encontrados aps a implantao, tambm conhecidos como defeitos escapados. As medidas que compem essa mtrica so o nmero de defeitos encontrados e o momento onde ele foi detectado. De acordo com o IEEE (1990), indicador algo que chama a ateno para uma situao particular. Ele, geralmente, est relacionado a uma mtrica e prov a interpretao daquela mtrica numa determinada situao ou contexto. Segundo Pressman (2006), as medies podem ser divididas em duas categorias: medidas diretas e medidas indiretas. No processo da engenharia de

11

software, as medidas diretas incluem, por exemplo, o esforo e o custo. Em relao ao produto, incluem-se as linhas de cdigo produzidas, velocidade de execuo, defeitos ao longo de um determinado tempo etc. No caso das medidas indiretas relacionadas ao produto podem ser citadas a qualidade, a confiabilidade, a eficincia, entre outras. Em geral, as medidas diretas so mais fceis de serem calculadas, desde que a organizao defina alguns procedimentos padres para isso. o caso do esforo, do custo, das linhas de cdigo, dos pontos de funo. Porm, no caso de qualidade e eficincia, essas so mais difceis de serem avaliadas e, por isso, so medidas indiretamente. A Figura 2.1 e Figura 2.2 ilustram o relacionamento entre esses conceitos dentro de um processo de medio, segundo a ISO/IEC 15939.

Figura 2.1 Nveis do processo de medio (adaptada da ISO/IEC 15939 Software Measurement Process).

12

Figura 2.2 Detalhamento dos nveis do processo de medio (adaptada da ISO/IEC 15939 Software Measurement Process).

Nos ltimos anos tem sido realizado um esforo para fornecer uma base terica relacionada a mtricas, para que seja possvel suportar o desenvolvimento e teste de uma mtrica, e garantir a sua eficincia (MENESES, 2001). A definio de uma teoria de mensurao identifica se uma mtrica especfica apropriada em uma determinada situao ou para um determinado propsito. A Teoria de Mensurao envolve descries matemticas de escalas, medidas, mtodos de medio, ordem, significados, de modo a fornecer subsdios tericos para validar qualquer conjunto de mtricas (ZUSE e BOLLMANN, 1989; BAKER et AL, 1990; FENTON e PFLEEGER, 1997).

13

2.2

Produtividade A produtividade em um sistema de manufatura pode ser medida pela

quantidade de unidades produzidas (output) dividida pelo nmero de horas utilizadas na produo (input), ou seja, Produtividade = Output/Input (SOMMERVILLE, 2007). Na engenharia de software, a medio da produtividade usualmente baseada na razo simples entre o tamanho do produto (output) e o esforo utilizado para produz-lo (input). Nessa definio, o tamanho do produto pode ser medido de vrias formas: medidas fsicas (quantidade de linhas de cdigo), medidas de design (quantidade de mdulos ou classes), medidas funcionais (quantidade de pontos de funo, pontos de casos de uso etc.), enquanto que o esforo realizado pode ser medido pela quantidade de pessoas-ms ao longo do projeto (KITCHENHAM e MENDES, 2004). Esta definio pode ser simples de operacionalizar se existir na organizao uma medida de tamanho padro; por exemplo: quantidade de linhas de cdigo, pontos de funo etc. Porm, normalmente, h vrias formas de definir o conceito de output durante a produo do software. Na viso moderna de produtividade, o valor produzido (output) pode ser analisado em mltiplas dimenses (AQUINO E MEIRA, 2009; KITCHENHAM E MENDES, 2004). Essas dimenses podem significar, por exemplo, resultado financeiro, satisfao do cliente, satisfao da equipe, grau de inovao do produto ou experincia adquirida, enquanto que o valor produzido (input) normalmente medido pelo esforo ou custo utilizado. Como no existe um modelo padro que agregue todas essas medidas, natural que as empresas utilizem a forma mais fcil de operacionalizao ou, ainda, que tentem definir a sua prpria forma de medio da produtividade. 2.3 Sistemas de Medio Segundo Deming (1986), sistemas de medio um conjunto de aes que devem ser realizadas em relao coleta, validao e anlise de dados utilizados para a tomada de deciso. o conjunto de todas as definies, mtodos e atividades usadas para medir um processo e seus produtos resultantes com o propsito de caracterizar e entender o processo.

14

Segundo DeMarco (1982), no se pode controlar aquilo que no se consegue medir. Essa necessidade das empresas de software em definir indicadores que quantifiquem a performance das organizaes faz com que os sistemas de medio sejam a principal ferramenta dos gestores para tomada de decises e criao de programas de recompensa (NORTON E KAPLAN, 1996). A busca por mtricas que representem determinadas dimenses do software, como tamanho ou custo, tem sido um dos grandes desafios das organizaes de desenvolvimento de software. Uma forma de implementar prticas para a obteno de indicadores que representem a situao de um projeto ou da organizao atravs dos sistemas de medio. Eles tm como objetivo estabelecer e sustentar a cultura de realizao de medies e anlises quantitativas nas organizaes. Assim, possvel perceber que a medio nos ajuda a entender o mundo e a tomar decises mais corretas (PFLEEGER E FENTON, 1997). No entanto, h vertentes que discordam da influncia da prtica da medio sobre as atividades executadas pelos indivduos dentro das organizaes. Em um trabalho mais recente, DeMarco (2009) faz uma autocrtica sobre a sua clebre frase Voc no pode controlar o que no pode medir publicada em seu livro Controlling Software Projects (DEMARCO, 1982). Vinte e sete anos depois ele diz que implcita nessa frase est a idia de que o controle seja, talvez, o mais importante aspecto de um projeto de software. Mas, no . Muitos projetos foram realizados quase sem controle e produziram timos produtos, como o Google Earth5 ou o Wikipedia6. E complementa:
Nos ltimos 40 anos ns nos torturamos com a nossa inabilidade de terminar um projeto no prazo e no oramento. Mas essa nunca deveria ter sido a meta suprema. A meta mais importante a transformao, criar softwares que mudam o mundo ou transformam a maneira como uma companhia realiza seu negcio. Desenvolvimento de software e sempre ser de alguma maneira experimental. Quanto mais voc foca em controle, maior a

http://earth.google.com/ http://www.wikipedia.org/

15

probabilidade de seu projeto estar entregando algo de valor baixo. Ento, como voc gerencia um projeto que no pode controlar? Bem, voc gerencia as pessoas e controla o tempo e o dinheiro. Estou sugerindo um approach de gesto muito prximo de mtodos geis. No mnimo deve ter um aspecto incremental (DEMARCO, 2009).

De acordo com Drucker (2001), para que a organizao esteja apta a controlar sua prpria performance, os gestores precisam saber muito mais do que apenas metas. Eles devem estar aptos a medir a sua performance e analis-las junto a esses objetivos. Essas medies no necessariamente precisam ser rgidas, mas, principalmente devem ser simples, claras, racionais e, muito importante, devem ser dados confiveis e, mesmo que haja margem de erros, esta deve ser conhecida. Por outro lado, a pesquisa publicada por Dekkers (2000) mostra a relao de sucesso e falha na implantao dos programas de medies entre os anos 1981 e 1998. A Figura 2.3 exibe a alta taxa de falha nesses programas, em torno de 80% nos ltimos 10 anos medidos.

Figura 2.3 Pesquisa sobre a quantidade de sucesso e falha nos programas de medio (adaptada de DEKKERS, 2000).

2.3.1 As reais intenes de um Sistema de Medio Na medida em que a engenharia de software amadurece, a medio passa a desempenhar um papel cada vez mais importante no entendimento e controle do desenvolvimento de software (FENTON, KITCHNEHAM E PEEGER, 1995). As organizaes procuram medir caractersticas do software para verificar se os

16

requisitos esto consistentes e completos, se o projeto tem boa qualidade ou se o cdigo est pronto para ser testado ou entregue para o seu cliente. Mas quais as reais intenes de um sistema de medio? Espera-se que as organizaes estejam em busca de compreender e melhorar o seu processo de desenvolvimento, facilitando, assim, as decises que so tomadas com o uso de informaes. Para entender as reais intenes das organizaes, preciso perceber que a medio inicia no nvel do projeto, onde desempenha uma grande ajuda ao gerente. Com as medies ele pode tomar decises com informaes objetivas nos seguintes pontos (JONES et AL, 2001): Comunicar-se mais efetivamente; Acompanhar objetivos especficos do projeto. As medies do projeto podem fornecer informaes mais precisas do status do projeto e do produto que est sendo gerado; Identificar e antecipar a correo dos problemas, favorecendo uma viso pr-ativa do gerente; Tomar decises-chaves. Todos os projetos de software so submetidos a restries. Custos, cronograma, capacidade da equipe e sua qualidade tcnica, e desempenho tm que ser negociados e priorizados em relao ao melhor custo e benefcio para garantir que os objetivos do projeto sejam atingidos. Austin (1996) explica as duas categorias das reais intenes de uso de um sistema de medio: a motivacional e a de informao. Ele no invalida completamente o benefcio das medidas, mas discute largamente a questo se a medida para gerar informao ou motivao. No primeiro caso, existem chances de sucesso. No segundo, o sistema tender a ser burlado e, por isso, alguns cuidados adicionais devem ser tomados.

17

A medio com inteno motivacional explicitamente destinada a afetar as pessoas que esto sendo medidas, para provocar uma maior demanda de esforos em relao s metas organizacionais. J a medio voltada para a informao tem o propsito de identificar alguma situao que ocorre no projeto e pode ser dividida em duas formas: medio para melhorar o processo de desenvolvimento do projeto e medio de coordenao, ou seja, para prover informao que permita alguma ao gerencial no progresso do projeto, como, por exemplo, adicionar novos recursos em um projeto atrasado. Essa medio, por sua vez, no tem a inteno de mudar o comportamento das pessoas. Ainda que as intenes dos sistemas de medio sejam conhecidas e perseguidas, assim como as ferramentas e metodologias, as medies por si s no podem garantir o sucesso de um projeto. No entanto, elas favorecem decises factuais, visibilidade e pr-atividade do gestor. Sendo assim, os projetos, alm de alcanar seus objetivos, aproximam a organizao no atendimento de sua meta. Nesse contexto, metodologias, modelos, padres ou ferramentas, como Balanced Scorecard (BSC), Goal-Question-Metric (GQM), Practical Software & Systems Measurement (PSM) e Capability Maturity Model Integration (CMMI) so muito utilizadas na identificao, definio e refinamento dos objetivos de negcio, iniciativas, mtricas e indicadores a serem implantados. 2.3.2 Balanced Scorecard O Balanced Scorecard (BSC) surgiu, em 1990, como um estudo intitulado Measuring Performance in the Organization of the Future. O trabalho foi realizado por David Norton, executivo principal do Instituto Nolan Norton, e pelo professor Robert Kaplan, da Harvard Business School7. um sistema de gesto estratgica cujo principal objetivo o alinhamento do planejamento estratgico com as aes operacionais da empresa. Segundo os criadores (NORTON E KAPLAN, 1996), o BSC traduz a misso e a estratgia das empresas em um conjunto abrangente de

Harvard Business School: http://www.hbs.edu/

18

medidas de desempenho, que serve de base para um sistema de medio e gesto estratgica. O BSC decompe a estratgia de uma maneira lgica, baseando-se em relaes de causa e efeito, vetores de desempenho e relao com fatores financeiros. decomposto em objetivos, indicadores, metas e iniciativas, nas quatro dimenses de negcio: Financeira, Clientes, Processos internos, Aprendizado e Crescimento, conforme ilustra a Figura 2.4 (NORTON E KAPLAN, 1996).

Figura 2.4 As quatro perspectivas do Balanced Scorecard (extrada de NORTON E KAPLAN, 1996).

Kaplan (2005), criador do Balanced Scorecard, apresenta um novo conceito denominado Prontido Estratgica, para medir o valor intangvel das organizaes de tecnologia da informao. Esse conceito est relacionado com o fato de que, mesmo no sendo possvel mensurar valor aos ativos intangveis, certamente possvel avaliar o seu alinhamento com as estratgias de alto valor, acrescentado para uma empresa. Ele diz que:

19

os aprimoramentos de pessoas, sistemas ou sistemas de recompensa da organizao do-se por meio de aperfeioamento de processos, que, por sua vez, criam mais valor para os clientes, resultando, por fim, em receita e margens mais altas. Atravs dessa cadeia indireta, possvel obter melhores desempenhos financeiros em tecnologia da informao (KAPLAN, 2005).

2.3.3 Goal Question Metric Goal Question Metric (GQM) um mtodo para medio de software, criado por Victor Basili em conjunto com o laboratrio de engenharia de software da NASA. O modelo de medio proposto apresenta trs nveis (BASILI, CALDIERA E ROMBAC, 2001), conforme ilustra a Figura 2.5. Nvel conceitual (Goal): so institudos objetivos para um objeto de medio, que podem ser estabelecidos em cima de produtos, processos ou recursos; Nvel operacional (Question): questes so elaboradas para caracterizar o objeto de medio, a fim de identificar os itens e critrios de qualidade desejados; Nvel quantitativo (Metric): um conjunto de dados associado a cada questo, a fim de respond-la quantitativamente.

Figura 2.5 Modelo do Goal Question Metric (extrada de BASILI, CALDIERA E ROMBAC, 2001).

2.3.4 Practical Software and Systems Measurement O Practical Software and Systems Measurement (PSM) um modelo que define a maneira de implementar um processo de medida efetivo. Ele foi criado, em 1994, pelo exrcito dos Estados Unidos. Em 2002, foi normalizado pela ISO/IEC

20

15939 Software Engineering Software Measurement Process Framework (PSM, 2003). O PSM procura resolver dois problemas: i) como especificar formalmente as medidas a serem usadas e ii) como conduzir o processo de medio. H dois modelos para alcanar esses objetivos: modelo de informao e modelo de processo (MCGARRY et AL, 2002). A Figura 2.6 ilustra o escopo do PSM composto de quatro atividades chaves: Estabelecer e Manter o Comprometimento; Planejar Medio; Executar Medio; e Avaliar Medio.

Figura 2.6 Escopo do Practical Software and System Measurement (extrada de PSM, 2003).

2.3.4.1 CMMI e ISO/IEC 15939 O CMMI (Capability Maturity Model Integration) um modelo de melhoria de processo para desenvolvimento de produtos e servios. O CMMI a evoluo e a unio de vrios modelos, dentre os quais: Capability Maturity Model for Software (SW-CMM), Systems Engineering Capability Model (SECM) e o Integrated Product Development Capability Maturity Model (IPD-CMM) (SEI, 2006). O CMMI composto por vrias reas de processo, dentre elas, a medio e anlise (MA). Essa rea tem como propsito desenvolver e manter a capacidade de medio usada para dar suporte s necessidades de informaes gerenciais. Envolve as atividades: (i) identificao dos objetivos de medies (alinhados aos objetivos e necessidades de informao gerenciais), (ii) especificao das medidas e

21

(iii) especificao dos procedimentos de coleta, armazenamento, anlise e divulgao dos dados e resultados (SEI, 2006). A ISO/IEC 15939 um padro internacional que define um processo de medio para o desenvolvimento de software e engenharia de sistemas. O padro descrito em termos de objetivos e resultados de um processo compatvel, com atividades e tarefas associadas. O padro tambm define o modelo de medio e a terminologia associada. A ISO/IEC 15939 abrange as atividades de medio, as informaes requeridas, a aplicao dos resultados da medio de anlise, e determina se os resultados das anlises so vlidos (PSM, 2003). O Practical Software Measurement (PSM) serve como documento base para o desenvolvimento da ISO/IEC 15939, fornece detalhes adicionais sobre as atividades e tarefas apresentadas na norma e passos detalhados para cumprir essas tarefas com sucesso. A Figura 2.7 ilustra a relao entre o PSM, a ISO/IEC 15939 e a rea de processo do CMMI (MA).

Figura 2.7 Relacionamento entre PSM, ISO/IEC 15939 e CMMI (extrada de PSM, 2003 ).

http://www.psmsc.com/ISO.asp

22

2.3.5 Disfuno em Sistemas de Medio Nas organizaes, apesar das boas intenes em criar sistemas de medies efetivos, existe um fenmeno, chamado disfuno, que prejudica a performance das empresas. Enquanto os gestores de um sistema de medio acreditam que esto dando visibilidade da performance da organizao atravs de seus indicadores, na verdade esto desviando a ateno e os esforos das equipes para nmeros que distorcem a realidade. No contexto organizacional, a disfuno pode ser definida como sendo as conseqncias da mudana de comportamento das pessoas que interferem os resultados pretendidos ou levam ao sentido oposto das reais intenes dos objetivos organizacionais definidos (AUSTIN, 1996). Segundo Austin (1996), a medio algo potencialmente perigoso. Quando se mede qualquer indicador de performance, incorre-se no risco de pior-la. O simples fato de medir faz com que a pessoa, cada vez mais, foque apenas na dimenso que est sendo medida. Isso no quer dizer que no se deva definir indicadores para acompanhamento e melhoria dos projetos e processo, mas, necessrio ter alguns cuidados ao definir as reais intenes daquilo que est sendo medido. Boehm (BOEHM et AL, 1982) afirma que obter ganhos significativos de produtividade requer iniciativas integradas em diversas reas; por exemplo: melhoria em ferramentas, metodologia, ambiente de trabalho, educao, gerenciamento, incentivos pessoais, reuso em software, dentre diversos outros fatores. Isso quer dizer que, para avaliar a produtividade, ou seja, o quanto os projetos produzem de valor agregado por unidade de valor consumido, necessrio entender quais so as vrias dimenses que precisam ser consideradas na anlise do desempenho organizacional. Porm, muitas vezes, essas dimenses no so facilmente identificadas e medidas. Isso pode ocorrer por vrias razes, como, por exemplo: desconhecimento do que precisa ser medido em relao aos objetivos estratgicos; desconhecimento ou

23

dificuldade de como coletar uma determinada dimenso; e barreiras culturais; entre outros. Muitas vezes, os indicadores so criados por serem fceis de coletar; por exemplo, a quantidade de linhas de cdigo produzidas por unidade de tempo. A partir do momento em que uma equipe avaliada por essa nica dimenso, a tendncia natural que as pessoas foquem seu trabalho em produzir, cada vez mais rpido, as linhas de cdigo, deixando de lado outras dimenses relacionadas com os atributos de qualidade do produto gerado, que no esto sendo observadas e so to ou mais importantes quanto a primeira (AQUINO et AL, 2009). Portanto, a disfuno ocorre quando a forma como a equipe trabalha, para alcanar uma meta controlada pela organizao, leva a uma queda da performance real, que no refletida nos indicadores medidos, conforme ilustrado na Figura 2.8. A disfuno, ento, aumenta quando qualquer dimenso crtica que despende esforo no medida. Jackson (2002), Meyer (2002) e Bruijn (2002) tambm tratam desse fenmeno, em estudos mais recentes. Alguns autores chamam-no de efeito perverso ou gaming.

Figura 2.8 O efeito da disfuno em sistemas de medio (extrada de AUSTIN, 1996).

24

Como vimos na Seo 2.3.1, uma medio pode ser usada para prover informao e, dessa forma, melhorar o processo utilizado ou dar subsdios para tomar decises gerenciais, baseadas em fatos, como, por exemplo, decidir aumentar os recursos humanos em um projeto. Por outro lado, a medio tambm pode ser utilizada para gerar motivao. Nesse caso, o sistema de medio torna-se vulnervel ao comportamento humano, visto que ele pode causar reaes s pessoas que esto sendo medidas; por exemplo, as medies utilizadas em programas de recompensas. Flamholtz (1979) afirma que, no contexto das organizaes, o papel da medio no meramente representado pelo aspecto tcnico; ele possui uma dimenso social e psicolgica. 2.4 Consideraes Finais Os sistemas de medio vm sendo utilizados por vrias organizaes com o intuito de mensurar indicadores que representem sua performance em diferentes perspectivas. Vrias metodologias, modelos, padres ou ferramentas so utilizadas, tais, como, BSC, GQM, PSM, CMMI, entre outras. Porm, nem sempre h sucesso em sua implantao. Uma das razes est relacionada inteno com que o sistema de medio implantado. A medio voltada para obter informao tem menos riscos de fracasso em relao medio voltada para a motivao. Essa ltima pode ser influenciada pelo efeito da disfuno que ocorre quando a m implantao, em um sistema de medio, ocasiona uma queda na performance organizacional, devido vulnerabilidade do comportamento das pessoas que so submetidas medio.

25

SISTEMAS DE RECOMPENSA
Este captulo descreve os conceitos bsicos que sero mencionados ao longo

deste trabalho, relacionados com sistemas de recompensa, alm de descrever o estado da arte sobre este tema. 3.1 Recompensa Recompensas podem ser classificadas como tangveis ou intangveis. No primeiro caso, so definidas como sendo prmios concedidos aos empregados em funo de tarefas realizadas, que vo ao encontro ou superam expectativas inicialmente estabelecidas. No segundo caso, so definidas como elogios concedidos em pblico, em virtude de realizaes amplamente aprovadas no contexto da cultura organizacional (STAJKOVIC E LUTHANS, 1997). Segundo Fischer (2001), os sistemas de recompensa se inserem na administrao de recursos humanos (RH) e, muitas vezes, so utilizados, dentro de uma viso instrumental, como um processo isolado, sem considerar o que significa, para as cincias administrativas e as relaes de trabalho, gerir pessoas nos ambientes organizacionais. Tradicionalmente, o sistema de administrao de RH, descreve a funo administrativa da seguinte forma: obteno e manuteno de uma fora de trabalho composta de pessoas diligentes, capazes, competentes, solidrias, coesas, motivadas e aperfeioadas entusiasticamente dedicada a contribuir com seus melhores esforos (RAMALHO, 1977). A partir de suas pesquisas no Brasil, e analisando esse enquadramento, Fischer considera que a funo de RH, prioritariamente, sempre foi entendida como um conjunto de artefatos para ajustar o indivduo a um esteretipo de eficincia estabelecido pela empresa, onde a pessoa recebe a ao de ajuste comportamental dessa organizao.

26

Conforme seus comentrios, os pressupostos desse posicionamento esto baseados, predominantemente, na busca de previsibilidade e controle, com foco em instrumentos. No diferencia o recurso humano dos demais recursos geridos pela organizao. Nesse sentido, a funo RH considerada uma mera extenso das demais funes administrativas para o mbito das relaes humanas e considera apenas um agente, no caso a organizao, como instncia consciente na dinmica complexa que se estabelece nas relaes entre as pessoas e o mundo do trabalho. Nessa viso tradicional da administrao de RH, o que no levado em considerao o que acontece entre o indivduo e a organizao um conjunto de relaes sociais entre pessoas, grupos e a prpria organizao. Para Fischer, essas relaes, essencialmente humanas, pressupem indivduos e grupos mais ou menos conscientes de seus interesses, atuando, interagindo e interferindo no seu comportamento e no comportamento dos demais agentes envolvidos. Esse mesmo autor afirma, tambm, que qualquer organizao depende de mecanismos de gesto institucionalizados para direcionar as relaes humanas no ambiente organizacional. Por isso, define estratgias e as transforma em instrumentos, processos e prticas de gesto mais ou menos formalizados, os quais indicam o comportamento humano desejado nesses ambientes. Ressalta, entretanto, que hoje, evolui-se para uma perspectiva de que o conceito de modelo de gesto de pessoas tenta superar as definies meramente instrumentais:
Tal conceito manifesta-se muito mais como uma sntese, como um vetor que resulta das estratgias colocadas em prtica por diferentes agentes organizacionais, quais sejam: empresrios, gerentes, especialistas da rea e os prprios funcionrios. Trata-se de algo menos objetivo e no to fcil de ser identificado do que os instrumentos de gesto adotados, mas muito mais representativo do que de fato ocorre com o comportamento humano no interior das organizaes (FISCHER, 2001).

Ele ainda analisa que o papel das polticas de RH tem a funo de gerar espao para que as relaes de trabalho se expressem de forma concreta, onde fatores, como a cultura organizacional, geram limites e possibilidade de atuao.

27

No mbito das relaes de poder, a funo dessas estratgias criar certa lgica de atuao, instrumentalizar as partes envolvidas, para que faam valer seus interesses, e ter mecanismos de regulamentao, a fim de manter o equilbrio e o funcionamento de um sistema complexo, repleto de contradies e que necessita de processos de cooperao. Nessa direo, Fischer, advoga que os elementos que compem o modelo de gesto de pessoas vo alm da estrutura, dos instrumentos e das prticas normatizadas de RH, incluindo o que, de forma significativa, influencia as relaes entre os dois agentes: pessoas e organizao. Desse modo, deve indicar os procedimentos que a organizao elege para envolver as pessoas: definies empresariais estratgicas, forma como estimula tipos de relao com os clientes, imagem institucional que quer passar, como quer atuar no mbito tecnolgico e outros temas organizacionais que indicam seus valores, bem como estrutura a maneira de pensar sobre determinada realidade, tornando-a de tal maneira familiar e conhecida que os agentes envolvidos podem trabalhar sobre ela. Nessa perspectiva, o modelo de gesto de pessoas deve ser compreendido como:
conjunto de polticas, prticas, padres atitudinais, aes e instrumentos empregados por uma empresa para interferir no comportamento humano e direcion-lo no ambiente de trabalho. Do ponto de vista empresarial, tais iniciativas so provenientes de diferentes instncias organizacionais e mesclam-se com as estratgias e prticas dos prprios empregados (FISCHER, 2001).

Nessa abordagem, inserem-se os programas de qualidade total, os processos de planejamento estratgico compartilhado, os sistemas de remunerao, de gesto de carreiras, avaliao de desempenho, de captao e demisso de pessoas. Esse novo posicionamento, reconhecido e usado pela administrao, revela que a empresa no tem como criar, unilateralmente, um sistema que oriente o comportamento humano na organizao, mas pode propor princpios, polticas, processos e procedimentos que estimulem, expressem as expectativas de como os comportamentos devem acontecer, desde que considere o fator humano sem levar

28

em considerao que so prticas menos estveis e localizadas, as quais incidem sobre as pessoas e no sobre os recursos. Essa abordagem, defendida por Fischer, evidencia o desafio e as contradies, com as quais, na atualidade, uma organizao se depara, ao tentar colocar em prtica sistemas de incentivos e recompensas. Nesses ambientes, muitas vezes, presencia-se pouco estmulo motivao, competio acirrada entre as pessoas, intenso ritmo de trabalho e uma relao imediatista entre desempenho e resultados. Dentro desse escopo, vale salientar que os sistemas de recompensa so criados com o objetivo de aumentar a produtividade organizacional, recompensando as pessoas que atinjam um nvel esperado de performance. A questo central como definir os indicadores adequados para assegurar a produtividade das equipes e estimular a motivao sem causar disfuno no sistema de medio e pouca efetividade na ao (AUSTIN, 1996). Dutra (2004) define os processos de gesto de pessoas categorizando-os, quanto natureza, da seguinte forma: movimentao, desenvolvimento e valorizao. No escopo deste trabalho ser abordada a natureza de valorizao, a qual se divide em: Remunerao; Premiao; Servios e facilidades. Essa natureza de valorizao medida pelas recompensas recebidas pelas pessoas como contrapartida de seu trabalho para a organizao. As recompensas podem ser entendidas como o atendimento s expectativas e necessidades das pessoas: econmicas, de crescimento pessoal, de segurana, de projeo social, reconhecimento, possibilidade de expressar-se atravs do trabalho, etc.

29

A recompensa pode ser concretizada de vrias maneiras: reconhecimento formal, atravs de um elogio, de uma carta ou de um prmio ou, at de um aumento salarial ou de uma promoo para posies organizacionais com desafios maiores. Segundo Zanelli (2004), o sistema de recompensa de uma organizao repercute na motivao do trabalho quando os trabalhadores so premiados de modo tangvel (bnus em dinheiro, aumento salarial) ou intangvel (elogio ou reconhecimento pblico) por terem praticados comportamentos considerados desejveis para a organizao. Thorndike (1913) definiu a Lei do Efeito, tendo como enunciado que o comportamento, quando seguido de conseqncias favorveis, tende a se repetir. Stajkovic e Luthans (1997) afirmam que as recompensas parecem ser elementos eficazes para a elevao da performance no trabalho. O principal desafio de um sistema de recompensa efetivo est relacionado com a definio de critrios sobre como a recompensa deve ser distribuda entre as pessoas. A utilizao de padres de diferenciao considerados pelas pessoas como justos e a consistncia desses padres com contexto da organizao so essenciais para uma relao de compromisso com a empresa e com o trabalho a ser executado. Dutra (2004) cita algumas caractersticas que o sistema de recompensa deve ter: Capaz de traduzir a contribuio de cada pessoa para a organizao; Aceito por todos como justo e adequado; Mensurvel pela organizao e pela prpria pessoa; Coerente e consistente no tempo, ou seja, tenha perenidade mesmo em ambiente turbulento e instvel; Simples e transparente para que todas as pessoas possam compreend-lo e a ele ter acesso.

30

A seo seguinte ir apresentar uma viso conceitual sobre remunerao, por ser um dos tipos de recompensa mais comuns. 3.1.1 Remunerao Remunerao ou compensao significa toda forma de pagamento monetrio para o qual o empregado elegvel ou o qual o empregado recebe. Salrio corresponde parcela fixa da remunerao, paga regularmente (CERIELLO E FREEMAN, 1991), porm, alguns autores incluem fatores no monetrios na definio de compensao (HIPLITO, 2006). O alinhamento entre remunerao e a estratgia da organizao um dos grandes desafios da administrao da compensao (LAWLER, 1990). importante que a forma de remunerao consiga estimular e reconhecer a performance de indivduos e grupos. Embora alguns autores (BELCHER, 1974) apontem para a possibilidade de reconhecer a performance por meio de alteraes no salrio, outros (MACLEAN, 1990; CAUDRON, 1993) sugerem que se reconhea a performance mediante remunerao varivel, pois se trata de um elemento que tende a ser voltil, isto , ela aumenta e diminui ao longo do tempo (HIPLITO, 2006). Quando se pensa amplamente em um sistema de recompensas, espera-se que ele seja capaz de reconhecer a contribuio dos indivduos aos resultados organizacionais, contemplando as dimenses de curto e longo prazo (HIPLITO, 2006). A proposta de remunerar a contribuio comum nas teorias de administrao salarial, sendo inerente lgica do sistema capitalista de produo (BELCHER, 1974). Alguns autores explicam a necessidade de manter a relao entre salrios e contribuio, visto que, em grande parte das organizaes, a folha de pagamento responsvel por uma parcela significativa de seu custo operacional, influenciando diretamente seu poder competitivo (MISHINA E INABA 1985; FLANERY, HOFRICHTEE E PLATTEN, 1996). A preocupao em manter a relao entre remunerao e contribuio para resultados j estava presente nos mtodos tradicionais de remunerao, refletindose nos nveis salariais praticados pelo mercado. Rucker (apud MISHINA, 1985), ao analisar o censo das empresas norte-americanas de manufatura, durante o perodo

31

de 1899 a 1929, provou estatisticamente haver uma relao proporcional entre a contribuio do profissional e o custo do trabalho, tambm detectada por Mishina (1985), vrios anos depois. O desafio, no entanto, est no estabelecimento de mecanismos capazes de manter essa relao, dificultada pela natureza complexa da contribuio e pela infinidade de tcnicas e instrumentos disponveis aos gestores de salrios (HIPLITO, 2006). A noo de contribuio no restrita a resultados financeiros de curto prazo. Um sistema de compensao efetivo deve:
especificar o que o empregador quer de seus empregados e o que ele deve ser motivado a oferecer, (...) reconhecendo a contribuio do profissional a partir da anlise de uma srie de dimenses e motivaes que o impede a esforar-se mentalmente e fisicamente e a alocar seus esforos de uma maneira que sirva aos interesses da organizao (MILGRON E ROBERTS, 1992).

Ao estabelecerem com clareza o que esto recompensando por meio de seus sistemas de pagamento, as organizaes podem orientar as decises salariais internas, estimulando comportamentos desejados de seus profissionais, bem como certificarem-se de no estarem privilegiando determinado tipo de resultado, por exemplo, apenas o resultado financeiro (BELCHER,1974). Remunerao varivel (RV) um sistema de remunerao do resultado cuja premissa bsica para reconhecimento e recompensa o alcance dos objetivos desejados (XAVIER, SILVA E NAKAHARA, 1999). De maneira geral, o papel da remunerao varivel pode ser destacado da seguinte forma: Alinhamento dos profissionais em relao aos objetivos

organizacionais; Vincular recompensa ao desempenho, promovendo a melhoria contnua; Incentivar esforo e recompensar a contribuio das pessoas para o sucesso do negcio (HIPLITO, 2006).

32

Participao nos resultados (PPR) um programa de remunerao varivel que, por intermdio monetrio, reconhece e recompensa os empregados que atingiram e/ou superaram as metas definidas, negociadas e contratadas (XAVIER, SILVA E NAKAHARA, 1999). Um programa de remunerao varivel pode ser visto como diferencial estratgico para os negcios da organizao. Segundo Xavier et al (1999), a remunerao varivel deve ser reflexo do core business da empresa. Deve estar ligada estratgia de negcios e alinhada aos vetores de resultados de seus negcios por meio de seus indicadores. Na prtica, Remunerao Varivel mais aplicada individualmente ou para um determinado grupo, enquanto no PPR, em geral, toda a organizao elegvel por meio de fatores coletivos, ainda que de forma diferenciada para grupos ou pessoas. Em ambas, RV e PPR, a compensao, quando dada sob a forma remuneratria, no incorporada ao salrio fixo. H vrios modelos de remunerao varivel. A maioria tem origem nos EUA. As diferenas de aplicao ocorrem em funo do objetivo a que se propem. Abaixo esto alguns exemplos mais comuns (XAVIER, SILVA E NAKAHARA, 1999): Bnus/Gratificaes: so valores pagos periodicamente em funo do resultado obtido pela organizao. Normalmente contempla apenas a direo da empresa; Comisso: so valores pagos (porcentagem ou valores de receita ou faturamento) rea comercial, focando no indivduo e estimulando a viso imediatista; Incentivos/Campanhas: so modelos de curta durao, utilizados principalmente para incrementar as vendas para o alcance de metas e objetivos preestabelecidos. O pagamento do prmio normalmente feito por meio de bens de consumo, servios ou viagens;

33

Participao Acionria: prev a distribuio ou venda facilitada de aes, ao longo dos anos, para parcela restrita de empregados, geralmente pessoas ligadas direo da empresa. Demais exemplos podem ser vistos na Figura 3.1. Quanto mais prximo da base da pirmide se encontra o modelo, maior a quantidade de pessoas que podem participar do programa.

Figura 3.1 Principais modelos de remunerao varivel (adaptada de XAVIER, SILVA E NAKAHARA, 1999).

A Seo 3.2 ir apresentar uma viso conceitual sobre motivao, visto ser um tema bastante mencionado pelos autores que estudam os sistemas de recompensa. 3.2 Motivao A palavra motivao tem origem na palavra latina motivus (aquilo que se movimenta, que faz andar). Segundo Maximiano (2004), as empresas necessitam de pessoas motivadas para que a relao produtividade X qualidade acontea. preciso entender o que movimenta as pessoas para comportamentos de alto desempenho, indiferena ou

34

improdutividade. Em princpio, todas as pessoas so motivadas. O que pode acontecer a motivao no estar direcionada para o fator produtividade empresarial. Segundo Robbins (1999), o elevado desempenho do funcionrio requer habilidade, apoio e motivao. O fator motivao estimulado como uma sada para melhorar o desempenho profissional no que diz respeito tanto produtividade quanto sade organizacional e satisfao dos trabalhadores (FRANA et AL, 2002). Para Vergara (2000), a motivao no um produto acabado, mas um processo que se configura a cada momento, ou seja, tem carter de continuidade. Uma caracterstica muito importante da motivao o fato de ela ser intrnseca. E, por ser intrnseca, no cabe dizer que podemos motivar algum. O que pode ser feito estimular, provocar e incentivar a motivao de algum. O carter de interioridade da motivao implica o fato de que ela experimentada por cada pessoa, no sendo, portanto, generalizvel. H vrias vertentes tericas sobe motivao: Maslow, Herzberg, McClelland, Expectativa, Equidade, Geertz, Bergamini (VERGARA, 2000). Mas, vale evidenciar, a partir das pesquisas de campo, que nenhuma teoria motivacional por si s capaz de explicar completamente a motivao humana. Nesse trabalho ser abordada a teoria de Maslow, pela sua importncia na teoria administrativa por identificar e formular em primeira instncia o que era significativo e influenciava a motivao humana de forma cientfica, e a teoria da expectativa, proposta por Victor Vroom, por ser uma teoria mais contempornea e possuir uma relao direta entre desempenho e recompensa. 3.2.1 Teoria da Hierarquia das Necessidades A teoria de Maslow, tambm conhecida por Hierarquia das Necessidades, foi proposta em 1943, por Abraham Maslow. Ele estabelece que as pessoas so motivadas essencialmente por necessidades, as quais esto organizadas hierarquicamente e a busca por satisfaz-las o que motiva as pessoas a tomarem

35

alguma direo (MASLOW, 1943). Essas necessidades so representadas na Figura 3.2.

Figura 3.2 Pirmide de Maslow (extrada de FRANA et AL, 2002).

Os dois nveis mais baixos desta hierarquia representam, fundamentalmente, as necessidades bsicas de alimentao, sono etc. e a necessidade de sentir-se seguro em um ambiente. O terceiro nvel est relacionado com a necessidade de sentir-se parte de um grupo social. A auto-estima inclui fatores internos (autonomia) e fatores externos (status, reconhecimento e considerao), enquanto que autorealizao so as necessidades relacionadas com o desenvolvimento pessoal. Na medida em que cada uma dessas necessidades satisfeita, a necessidade superior se torna dominante. Para Maslow, as pessoas tm a mesma estrutura de necessidades, porm podem se encontrar em nveis diferentes da hierarquia. Porm, hoje se tem poucas provas que sustentam este conceito de progresso hierrquica. Pesquisas enfatizam que os nveis da hierarquia efetivamente existem, embora a progresso de um estgio para outro no claramente sustentada pelos estudos. Acredita-se que pessoas diferentes estaro em pontos diferentes da hierarquia, e que a mesma pessoa pode estar em pontos diferentes em momentos diferentes. Alm disso, muitas pessoas podem querer satisfazer necessidades de nvel mais alto fora do trabalho. Portanto, no se pode estimular a motivao de todas as pessoas da mesma forma (FRANA et AL, 2002).

36

3.2.2 Teoria da Expectativa Outra teoria sobre motivao, chamada de Teoria da Expectativa, foi proposta por Vroom, na dcada de 60. Ele afirma que um funcionrio estar motivado a se esforar no trabalho quando acreditar que seu esforo produzir um desempenho que, reconhecido, ir lev-lo a ter recompensas que tenham valor para ele (VROOM e KENNETH, 1968). Essa teoria voltada especificamente para o ambiente de trabalho. considerada uma teoria de processo, e no simplesmente de contedo, pois identifica relaes entre variveis dinmicas, que explicam o comportamento das pessoas no trabalho (FRANA et AL, 2002). Vroom desenvolveu o modelo multiplicativo entre as trs variveis abaixo: VIE = Valncia x Instrumentalidade x Expectativa

Segundo ele, o que motiva uma pessoa a tomar uma deciso um produto dessas trs variveis: do quanto uma pessoa deseja uma recompensa (valncia); sua estimativa da probabilidade de que o esforo resultar num desempenho bemsucedido (expectativa); e a estimativa de que aquele desempenho ser um meio para se chegar recompensa (instrumentalidade). Para explicar melhor a sua teoria, Vroom apresenta trs conceitos: Expectativa: o grau em que a pessoa acredita, ou espera, que seus objetivos sejam atingidos. Diz respeito probabilidade que a pessoa enxerga na consecuo de seus alvos. definida como a crena de que determinado ato ser seguido de um resultado particular. Trata-se de uma associao entre ao e resultado da ao; Instrumentalidade: representa a crena do indivduo de que uma recompensa ser recebida em funo do desempenho. Espera-se que as pessoas faam um julgamento subjetivo a respeito da probabilidade de

37

que a organizao valorize o desempenho e fornea recompensas com base no desempenho; Valncia: a orientao afetiva em direo a resultados particulares. Pode-se traduz-la como a preferncia em direo, ou no, a determinados objetivos. Diz-se que algo tem valncia positiva se atrai o comportamento em sua direo. Um objetivo de valncia zero aquele ao qual uma pessoa indiferente. Um alvo com valncia negativa aquele que o indivduo prefere no buscar. A valncia de uma recompensa nica para cada indivduo, estando condicionada s suas expectativas e pode variar substancialmente durante um perodo de tempo, uma vez que quando necessidades antigas so satisfeitas, outras novas surgiro. Com base nessa teoria, a Figura 3.3 ilustra as seguintes relaes com base nos trs conceitos citados: Expectativa: Define a relao (1) entre esforo e desempenho: a crena de que o esforo produzir o desempenho esperado; Instrumentalidade: Define a relao (2) entre o desempenho e a recompensa. crena de que o desempenho ir resultar em recompensa; Valncia: Define a relao (3) entre a recompensa e as metas pessoais. a crena de que a recompensa dever ter preferncia para o indivduo.

Figura 3.3 Teoria da Expectativa (adaptada de ROBBINS, 1999).

38

Sendo assim, uma pessoa diminuir seus esforos se acreditar que no ir alcanar o desempenho necessrio, se acreditar que impossvel alcanar as recompensas ou se acreditar que a recompensa indesejada. Segundo Vroom, alcanar recompensas as quais se atribui um grande valor leva uma pessoa a realizar os esforos mais intensos. Segundo Frana (FRANA et AL, 2002), a teoria da expectativa v o indivduo como um ser pensante que tem desejos e crenas e atua com base na antecipao e no planejamento dos eventos de sua vida, colocando em suas aes esforo adequado e a direo apropriada, de modo a atingir seus objetivos. Dito de outra forma, a fora da inclinao para uma ao depende da fora da expectativa de que o ato ser seguido por um resultado de alta valncia. o reconhecimento da capacidade de planejamento do ser humano que diferencia essa teoria das demais, e ela tem excelente aplicao dentro do modelo de gesto compartilhada de carreiras. Umas das limitaes dessa teoria que as pessoas consideram a motivao apenas do ponto de vista racional. Pelo fato das interaes entre expectativas, instrumentos e valncias serem bastante complexas, algumas pesquisas sugerem que essa teoria no explica to completamente a variao de esforo aplicado no trabalho quanto seria de esperar (MAXIMIANO, 2004). 3.2.3 Motivao na Engenharia de Software De acordo com Sommerville (2007), para pessoas que trabalham em organizaes de desenvolvimento de software, os dois nveis mais baixos das necessidades propostas por Maslow so atendidos, considerando que essas pessoas no tm problemas com as necessidades fisiolgicas bsicas e de segurana. Do ponto de vista de gesto, o que mais significativo so as trs demais necessidades (social, auto-estima, auto-realizao). Ele diz, ainda, que essas pessoas no so apenas motivadas por recompensas materiais. Em geral, gostam de ir ao trabalho porque so motivadas pelas pessoas com quem trabalham e pelo trabalho que fazem. Em um estudo

39

psicolgico, Bass e Dunteman (apud SOMERVILLE, 2007) classificaram os profissionais em trs tipos: Task-oriented: so motivadas pelo trabalho que fazem. Na engenharia de software so os tcnicos que so motivados pelos desafios intelectuais do desenvolvimento de software; Self-oriented: so motivados principalmente pelo sucesso pessoal e reconhecimento. Eles tm interesse em desenvolvimento de software como forma de alcanar seus prprios objetivos; Interaction-oriented: so motivados pela presena ou aes dos parceiros de trabalho. Por exemplo, pessoas tcnicas que normalmente so task-oriented, quando percebem que no esto sendo recompensadas corretamente podem tornarem-se self-oriented e colocarem seus interesses pessoais antes das preocupaes tcnicas. Boehm (1981) reconhece que a motivao tem um impacto importante sobre a qualidade e a produtividade do software, mas como um fator intangvel e difcil de mensurar, normalmente deixada para trs. Tanner (2003) observa que recompensa e reconhecimento nem sempre funcionam com os engenheiros de software. Os estudos realizados por Tanner mostram que os engenheiros tm uma personalidade diferente e so motivados pela natureza do trabalho como, por exemplo, problemas tcnicos desafiadores , e pela interao entre os pares. A Tabela 3.1 apresenta o resultado da reviso sistemtica realizada por Sharp (SHARP et AL, 2008) sobre O que motiva os engenheiros de software a serem mais produtivos? Recompensas e incentivos aparecem em sexto lugar, no total de 23 aspectos, sendo relatadas em 14 estudos. O item reconhecimento aparece logo em seguida, sendo relatado em 12 estudos. Uma variedade de outros aspectos motivadores tambm citada por vrios estudos: bom gerenciamento, variedade de tarefas, autonomia, feedback, entre outros.

40

Tabela 3.1 Fatores que motivam os engenheiros de software (extrada de SHARP et AL, 2008). Motivao dos engenheiros de software Identificao com a atividade (metas claras, interesse pessoal, conhecer o objetivo da tarefa) Participao, envolvimento e trabalho em equipe Boa gesto (apoio da gerncia superior, montagem da equipe e boa comunicao) Carreira de trabalho (oportunidade de crescimento, perspectiva de promoo, planejamento de carreira) Variedade de trabalho Recompensa e incentivos (ex.: escopo para remunerao crescente e benefcios relacionados com performance) Reconhecimento (pela alta qualidade, bom trabalho realizado com base em critrios objetivos) Oportunidades de treinamento para ampliar as habilidades, oportunidades para se especializar Trabalho tcnico desafiador Segurana no trabalho, ambiente estvel Feedback Autonomia Confiana, respeito Recursos suficientes Quantidade de estudos reportados 20 16 16 15 14 14 12 11 11 10 10 9 4 2

Essa mesma reviso sistemtica procurou responder seguinte pergunta Quais so os resultados obtidos por engenheiros de software motivados? A Tabela 3.2 mostra que depois do aspecto relacionado reteno, o resultado mais significante a melhoria da produtividade.
Tabela 3.2 Consequncias da motivao dos engenheiros de software (extrada de SHARP et AL, 2008). Sinais externos de engenheiros de software motivados Retenso (diminuio do turn-over) Produtividade Entrega no prazo Oramento Sucesso do projeto Quantidade de estudos reportados 12 5 2 1 1

41

Esses estudos apontam para a direo que a recompensa , de fato, importante na engenharia de software, visto ser um dos aspectos que mais motiva os engenheiros e que, por sua vez, pode aumentar a produtividade. Outra pesquisa foi realizada por Sankar (SANKAR et AL, 1991) a respeito das percepes de oito empresas de tecnologia da informao sobre sistemas de recompensa. Eles estudaram a percepo de 91 pessoas, considerando o perfil tcnico e gerencial. Uma das questes levantadas por essa pesquisa foi em relao aos fatores que motivam as pessoas com perfil tcnico. O resultado da pesquisa mostrou que ambos os perfis concordam que recompensas em forma de reconhecimento e elogios so fatores mais importantes do que recompensas financeiras. Os autores atribuem essa percepo a uma justificativa semelhante a j citada anteriormente por Sommerville (2007) sobre o fato de as necessidades bsicas (de acordo com a teoria de Maslow) das pessoas com esse perfil j serem normalmente atendidas. Uma pesquisa realizada por Shlaes (1991), sobre o uso de sistemas de recompensa em organizaes de tecnologia, mostrou que as principais formas de recompensa percebidas pelos empregados esto relacionadas com visibilidade, atravs de reconhecimento e prmios. Reconhecimento financeiro aparece apenas em terceira posio de preferncia. Em estudos sobre estratgias para melhorar a performance e a satisfao dos empregados, demais autores tambm afirmam que, para muitas organizaes, a questo financeira nem sempre o principal fator que os estimulam (MARCHANT, 1999; DEEPROSE, 2006). 3.3 Sistemas de Recompensa Viso Geral Os economistas comearam a considerar a medio motivacional de forma mais profunda a partir dos trabalhos publicados por Ross (1973) e Holmstrom (1977). A teoria econmica, conhecida como agente-principal, est preocupada com o fato de como um indivduo, o principal (o empregador), pode estruturar um sistema de compensao (um contrato), o qual motive outro indivduo, seu agente (o

42

empregado), a agir no interesse do principal. O problema de agente-principal ocorre quando envolve algum esforo que no pode ser monitorado e medido pelo principal e, portanto, no pode ser diretamente recompensado. A soluo para esse tipo de problema est em estabelecer algum tipo de alinhamento de interesses de ambas as partes (principal e o agente) (HOLMSTROM E MILGROM, 1991; LAFFONT E MARTIMORT, 2002). Em 1990, foi realizada uma conferncia promovida pela Harvard Business School, estimulada pelo insatisfatrio conhecimento sobre como as organizaes mediam e avaliavam sua performance e como os sistemas de incentivo eram definidos e implantados. Dez artigos escritos por dezesseis professores de Universidades dos Estados Unidos e da Europa foram apresentados e discutidos por sessenta e seis executivos, consultores e acadmicos (BRUNS, 1992). Eles relataram que embora os economistas e psiclogos tenham escrito muito sobre como as organizaes deveriam definir esses sistemas, a literatura ainda era muito escassa sobre como resolver os problemas inerentes ao sistema. Em relao aos sistemas de incentivos, os autores evidenciaram, atravs de estudos em campo, que, na maioria das organizaes, esses sistemas tinham, de fato, o propsito de relacionar a motivao performance. Sendo que uma das principais dificuldades era encontrar formas de medir e avaliar sua performance sem, no entanto, produzir o efeito da disfuno. Relatam, ainda, que uma varivel que os modelos da poca no consideravam era o aspecto cultural das organizaes. E que muitos sistemas de incentivo falharam por no consider-lo. H muita evidncia emprica que sugere que sistemas de recompensas influenciam o comportamento e a performance dos membros das organizaes (MALTZ E KOHLI, 2002; FURTADO et AL, 2009a). Segundo Humphrey (1987) uma recompensa apropriada quando o empregado contribui de forma extraordinria para os lucros da organizao. Para qualificar uma recompensa, a meta deve ser clara, significativa e consistente com outras recompensas para metas similares. Para que um sistema de recompensa seja efetivo e possa estimular a motivao, ele precisa satisfazer alguma

43

necessidade individual de um empregado, em particular, alm de acompanhar as mudanas de suas necessidades. Caso contrrio, improvvel que ela atinja a performance desejada. Em estudos mais recentes, Kaplan (KAPLAN E HENDERSON, 2005) afirma a importncia de incentivos formais ou informais nas organizaes e o uso deles, em algumas empresas, como forma de estmulo ao aumento da performance dos empregados. Ressalta, porm, a seguinte preocupao em relao aos sistemas de medio aos quais so baseados:
Os sistemas de incentivos costumam se basear em mensuraes sujeitas interpretao. Embora a literatura econmica diga que tais parmetros so entendidos instantaneamente por todos na empresa, ainda que sejam subjetivos, nosso argumento o de que a construo de um entendimento comum do que seja a relao entre aes e resultados no uma coisa to fcil de conseguir (KAPLAN E HENDERSON, 2005).

Bowles (2009) sugere uma reflexo sobre o fato de definir sistemas de incentivos apenas baseado nas teorias econmicas. Ele diz que, ao mesmo tempo em que a promessa de um bnus impulsiona um desempenho elevado, tambm pode causar o efeito contrrio, coibindo o prprio comportamento que deveria incentivar. Ele exemplifica com um estudo que os economistas descobriram que oferecer dinheiro a mulheres pela doao de sangue reduz, para quase a metade, o nmero das que se dispem a doar, e que deixar que o pagamento seja canalizado para uma obra filantrpica reverte o efeito. Ele conclui que premiar o interesse prprio com incentivos econmicos pode atrapalhar quando o incentivo mina aquilo que Adam Smith chamou de sentimentos morais. O principal problema para a maioria dos sistemas de recompensa nas organizaes no est relacionado com a medio da performance, mas, sim, com as distores introduzidas por aqueles que esto sendo medidos (AUSTIN, 1996). Alinhado com esse mesmo pensamento, Baker (BAKER, GIBBONS E MURPHY, 1994) afirma que a razo para qualquer disfuno causada por mudana de comportamento no est relacionada com os sistemas de pagamento por

44

performance (pay-for-performance) em si, mas pelas medidas inapropriadas de performance em que esses sistemas se baseiam. Ele assume que medidas objetivas de performance so imperfeitas, portanto, contratos de compensao baseados apenas nessas medidas criam sistemas distorcidos. Por fim, complementa que a efetividade desses sistemas depende de vrios fatores sociais, psicolgicos e econmicos. Gibbs (GIBBS et AL, 2004) pesquisou sobre os efeitos da subjetividade nos sistemas de incentivo e encontrou uma boa relao quando existe uma grande confiana entre o subordinado e o supervisor. Como mencionado na Seo 2.3.5, um sistema de medio pode ser definido na categoria medio motivacional (AUSTIN, 1996). Esse sistema pode ser utilizado para pagamentos de incentivo, pagamento por mrito, pagamento por performance, entre outros. A utilizao de sistemas de incentivo pode ser vista em diversas reas. Uma pesquisa realizada na rea financeira (AUSTIN, 1996) revelou que 87% dos bancos, companhias de seguro e diversas firmas financeiras possuem planos de incentivo para seus executivos. Dentre os bancos, 98% esto inseridos nesse contexto. Tully (SHAWN, 1993) revelou que o nmero de empresas nos Estados Unidos que oferecem pagamento varivel para todos os empregados aumentou de 47% em 1988, para 68% em 1993. As empresas passaram a pagar mais em incentivos em relao a aumento de salrio. Ingersoll (1998) relata os efeitos de sistemas de incentivo na performance na indstria de metais. Ele descreve como esse sistema permitiu que a capacidade instalada da fbrica fosse estendida para aumentar a performance. Explica, ainda, que foi implantado um contrato de desempenho cujo propsito era concentrar os esforos nos principais projetos e aes associadas. Em seguida, as pessoas eram recompensadas por alcanarem os resultados planejados. Austin (1996) define o conceito de distoro do sistema de incentivo. A Figura 3.4 ilustra uma forma simplificada para explicar esse conceito. As coordenadas do grfico representam duas dimenses de um sistema de medio baseado em

45

motivao. Nesse sistema especfico, o valor agregado ao cliente representado por uma combinao das atividades medidas pelos indicadores dos eixos X e Y. Quanto mais direita e acima do grfico, mais valor agregado ser gerado ao cliente, exemplificados pelos nmeros em ordem crescente (2, 5, 9, 14, 20, 26, 32, 40). Sendo assim, um sistema de recompensa que observe apenas uma dessas duas dimenses far com que a equipe demande mais esforos direita do eixo X, por exemplo, e no demande muito esforo acima do eixo Y. Fica, assim, caracterizada uma distoro no sistema de recompensa.

Figura 3.4 Relao entre duas dimenses em um sistema de incentivo (extrada de AUSTIN, 1996).

Segundo Baker (BAKER et AL, 1994), uma forma de mitigar as distores em um sistema de incentivo causadas por medidas objetivas imperfeitas atravs da combinao dessas medidas com componentes subjetivos. Ele afirma que mesmo as medidas subjetivas no sejam perfeitas, elas podem complementar ou melhorar as medidas objetivas disponveis. Gibbs (GIBBS et AL, 2004) tambm defende que a subjetividade pode ser til na mitigao de vrios problemas relacionados com a atribuio de recompensas atravs de medidas quantitativas de performance. O uso da subjetividade permite que os avaliadores explorem qualquer informao adicional relevante, que surja durante o perodo da medio e que possa ser benfico tanto para o empregado quanto para a organizao.

46

Eccles (1991) relata que cada vez mais os gerentes esto mudando os sistemas de medio de performance, para aprimorar suas estratgias competitivas. Ele afirma que a dificuldade de alinhar os incentivos com a performance acentuada pelo fato de no ser efetivo definir frmulas objetivas que os unam. Se forem definidas frmulas simples colocar o foco em poucas variveis, inevitavelmente algumas medidas no sero consideradas. Por outro lado, se elas forem complexas e focarem em todas as variveis importantes, as pessoas sentir-se-o confusas com tantos nmeros. E, mais ainda, a importncia relativa das variveis certamente mudar com mais freqncia e velocidade em relao a todo o sistema de incentivo. O mesmo autor se diz favorvel em relacionar os incentivos s performances, mas, pelas razes apresentadas anteriormente, sugere que os gerentes sintam-se livres para determinarem as recompensas de seus subordinados, baseados em todas as informaes relevantes, qualitativas e quantitativas, sendo da responsabilidade do gerente explicar cuidadosamente aos seus subordinados as razes de suas respectivas recompensas. Larkey e Caulkins (1992) relatam que esse tipo de avaliao defendido por Eccles raramente so realizadas, visto que os gerentes de uma maneira geral preferem realizar as avaliaes de performance tomando como base os indicadores formais. Alinhada com essa discusso sobre utilizar aspectos qualitativos na avaliao da performance, Austin (1996) menciona a dificuldade em medir a dimenso relacionada com a qualidade do software desenvolvido. Segundo Ishikawa (apud AUSTIN, 1996), possvel alcanar a conformidade com o que foi especificado, mas, ainda assim, no atender a expectativa de qualidade do cliente. A dificuldade em verificar o atendimento da qualidade realada quando a atividade de produo largamente mental, muitas vezes no observvel e medida, como ocorre em desenvolvimentos de software. No modelo proposto por Austin (1996), h trs formas de gerenciamento da equipe: nenhuma superviso, superviso total e superviso parcial.

47

No primeiro caso (auto-gerenciamento), no possvel implantar um sistema de recompensa por desempenho, visto que nenhuma dimenso ser observada. Isso bastante comum em organizaes com atividades muito especializadas. No segundo caso (superviso total), a equipe tem seu esforo monitorado em todas as dimenses e o sistema de recompensa bem acompanhado. Se, pelo menos, uma das dimenses no for atendida, a recompensa ser prejudicada. Desse modo, a equipe procura distribuir os esforos de maneira que todas as dimenses sejam atendidas conforme planejado. Nem sempre essa forma adequada em funo do alto custo de implantar um sistema de incentivo com todas as dimenses possveis de serem observadas. DeMarco (1982) menciona que sempre existe alguma forma de medir alguma coisa, mas, isto depende de quanto voc precisa conhec-la comparada com quanto isso custa. E, por fim, a terceira forma no prev o monitoramento de todas as dimenses e possibilita a explicao de alguma disfuno. Por outro lado, o custo desse sistema de incentivo ser menor que o anterior. Para Marchant (1999), no h dvida de que os incentivos podem impulsionar o desempenho. No entanto, adverte que esses sistemas podem falhar por vrias razes, como, por exemplo: se o reconhecimento no estiver relacionado com o desempenho, se as metas so vistas de forma a serem burladas ou, ainda, se houver um baixo nvel de confiana entre os envolvidos. Ainda em relao ao aspecto da confiana, Bowles (2009) corrobora dizendo que os incentivos do errado quando indicam que a empresa no confia no empregado ou gananciosa. Apesar de vrios estudos apontarem as vantagens de relacionar os sistemas de incentivo com o ganho de performance, h alguns autores que os criticam em determinados contextos. DeMarco (1999) alerta sobre o risco dos incentivos individuais provocarem a concorrncia interna da equipe, atravs de concesso de salrios anuais, elogios apenas para alguns membros do time e prmios ou bnus relacionados com performance. Ele atribui, ao gerente da equipe, a responsabilidade de garantir que

48

esses aspectos no gerem o efeito contrrio, ou seja, que no diminuam a produtividade do time, devido a uma competio interna. Na mesma linha de DeMarco, Kohn (1993) alerta para o risco de o uso limitado de incentivos causar competio e impactar negativamente o trabalho em equipe e piorar a qualidade do que est sendo produzido. Kohn (1993) relata alguns estudos sobre o oferecimento de incentivos em questes relacionadas ao cotidiano das pessoas, como, por exemplo, perda de peso, parar de fumar ou usar cinto de segurana. Os estudos mostram que o oferecimento de incentivos nesses casos, alm de ser menos efetivo do que outras estratgias, em alguns casos pior do que no fazer nada. Em suas crticas, Kohn afirma que h estudos que comprovam que os incentivos no criam um comprometimento duradouro, apenas mudam temporariamente o comportamento das pessoas. Em relao produtividade, completa que quem espera receber uma recompensa para executar suas tarefas, simplesmente no as executam to bem quanto aqueles que no foram submetidos a nenhum incentivo. Segundo este mesmo autor, um dos problemas desses sistemas que eles podem tornar as pessoas menos propensas a assumirem riscos, visto que elas iro focar apenas em atingir os nmeros aos quais esto sendo medidas para alcanar as recompensas. Como conseqncia, pode desencorajar a criatividade e inovao das pessoas. 3.3.1 Sistemas de Recompensa e a Gesto do Conhecimento De acordo com Bose (2004), alguns dos muitos benefcios do uso da gesto do conhecimento esto relacionados com a reduo na perda do capital intelectual dos empregados, com a reduo do custo do desenvolvimento de novos produtos e com o aumento na produtividade pelo fcil acesso ao conhecimento para todos os funcionrios. Segundo Cyriney (2008), os desafios relacionados adoo das prticas e modelos associados Gesto do Conhecimento no so triviais. De maneira geral,

49

as empresas precisam ser apoiadas por mudanas nos sistemas de incentivo individual e coletivo. Nesse contexto, a adoo de sistemas de recompensa por mritos individuais pode incentivar a adoo da mentalidade individualista, ou seja, compartilhar conhecimentos adquiridos pode no ser prioridade para os membros da organizao (UNIMONTE, 2007). Para tentar minimizar esse tipo de problema, Zhuge (2008) props um modelo de incentivo com o objetivo de promover o compartilhamento do conhecimento na organizao e, com isso, obter ganhos de produtividade. O modelo prope que a contribuio individual (disseminao do conhecimento) pode ser medida, e a recompensa pode ser individualizada, baseada na contribuio. No entanto, quando a organizao no consegue medir a contribuio individual, sistemas de recompensa, baseados no desempenho do grupo, passam a ser uma alternativa prtica. 3.3.2 Sistemas de Recompensa em Organizaes de Software H alguns anos foi realizada uma pesquisa sobre o sistema de recompensa no setor nacional de Tecnologia da Informao, em um conjunto de 17 empresas (ANETIE, 2004). Apenas 18% das empresas pesquisadas afirmaram pagar vencimentos totalmente fixos. As demais possuem uma parcela fixa e outra varivel. Em geral, os critrios para estabelecer o montante varivel esto relacionados com o cumprimento de objetivos previamente determinados. Elas entendem que h uma necessidade de estimular a motivao dos empregados e de refletir no salrio dos trabalhadores o sucesso da organizao, conforme ilustra a Figura 3.5. Para a atribuio dos prmios, 47% das empresas utilizam critrios quantitativos, que dependem da avaliao dos supervisores; 29% dependem apenas de seus resultados; e 24% utilizam critrios qualitativos, que dependem da avaliao dos diretores e do departamento de recursos humanos. Um aspecto importante nesta pesquisa que o peso dos incentivos varia de acordo com as reas de trabalho. Por exemplo, o impacto da atribuio de incentivos

50

para os arquitetos e desenvolvedores de software 13% inferior s demais reas. A rea de gesto de projetos apresenta a segunda maior mdia de peso dos incentivos, com 23%. Esta pesquisa observa que essa prtica recente. Dentre as empresas que utilizam poltica de recompensa, 90% fazem-no h menos de 5 anos.

Figura 3.5 Pesquisa sobre poltica de incentivos em TI. As razes para justificar a parcela varivel no vencimento (extrada de ANETIE, 2004).

Em geral, os projetos de desenvolvimento de software so medidos atravs de indicadores financeiros. Nos casos em que uma nica dimenso utilizada para comparar todos os projetos do portflio, esse indicador tambm deveria considerar as decises tomadas pela rea comercial, no momento da venda do projeto, principalmente quando o preo diminudo por motivos estratgicos, como, por exemplo, para entrar no cliente pela primeira vez, executar um projeto importante dentro de um cliente existente, etc, e no por questes relacionadas com as estimativas realizadas originalmente pela rea tcnica (MCCONELLl, 2006). Em casos como esse, uma poltica de recompensa que apenas bonifique os gerentes, que executaram os projetos com alta margem de lucro, poderia levar a um caso de disfuno, visto que apenas uma varivel estaria sendo observada o preo quando, tambm, deveria ser considerada a estimativa original. Papo (2008) descreve como a qualidade de um produto de software pode ser afetada quando a performance dos projetos medida apenas pelas dimenses de custo e prazo. Ele comenta que:

51

como o gerente de projeto e os membros da equipe s sero medidos pela velocidade de entrega, ento tudo feito s pressas e usualmente sem a ateno devida a um bom design, a testes unitrios e funcionais e a refatoraes constantes. Sem esses cuidados, o sistema costuma ser entregue com um nmero de defeitos acima do desejado. Essa medio de performance tambm faz com que os nveis gerenciais demandem mais de 40 horas semanais dos profissionais (muitas vezes sem o devido pagamento de horas extras), o que ainda gera uma degradao de moral da equipe e um turn-over mais alto na empresa (PAPO, 2008).

Outro exemplo de sistema de recompensa pode ser utilizado quando se aplica a gesto por projetos para servios de tecnologia da informao, como sugerido por Finocchio (2005). O mtodo de gesto apresentado por ele prev a criao de um plano mestre, mensal ou trimestral, onde os gerentes de recursos da rea de TI, de uma organizao, selecionam as demandas que passaram por um processo de anlise de viabilidade tcnica e financeira. Cada uma dessas demandas estimada e atribuda a um responsvel pela sua execuo. Um dos indicadores de desempenho definido foi o SPI (Schedule Performance Index). O SPI um indicador de cronograma que deve ter sempre o valor 1 (um) durante o ciclo de vida do projeto. Se o valor do SPI foi menor que 1 (um), indica que o projeto est atrasado. Ao contrrio do percentual de execuo de todo o plano, que no fornece uma indicao direta de quanto deveria ter sido feito, o SPI indica a real situao de execuo. Por exemplo, o SPI de 0,90 indica que foi cumprido 90% do que deveria ter sido realizado at a presente data. Nesse caso, o sistema de recompensa pode ser estabelecido para os funcionrios que atingirem o SPI maior ou igual a 1 (um), ou seja, dentro do prazo e com a aceitao do cliente. O gerenciamento de projeto tradicional normalmente considera trs dimenses para definir o sucesso ou o fracasso de um projeto: tempo, oramento e escopo. Porm, nem sempre essas mtricas refletem a viso necessria do sucesso do projeto para todos os stakeholders. Sob a tica do modelo tradicional, os projetos so categorizados em trs grupos (STANDISH GROUP, 2009):

52

Bem-sucedido: o projeto foi completado dentro do prazo, oramento e escopo; Desafiado: o projeto foi completado, mas, fora do prazo, oramento e escopo; Fracassado: o projeto foi cancelado antes de sua concluso. De acordo com o relatrio do Standish Group de 2009 (STANDISH GROUP, 2009), 32% dos projetos so considerados bem sucedidos. Por que, ento, com uma taxa to baixa de sucesso, tantos projetos so iniciados? possvel que outros indicadores justifiquem esse cenrio. Baccarini (1999) afirma que essas mtricas tradicionais permitem apenas uma viso em relao ao sucesso do processo do gerenciamento do projeto. Segundo ele, elas so focadas no processo do projeto, e em particular, no cumprimento bemsucedido dos objetivos de custo, tempo e qualidade. Tambm considerada a maneira pela qual foi conduzido o processo de gerenciamento. Wideman (1996) tambm questiona esses indicadores quando afirma que oramento e conformidade com os requerimentos no so eles prprios, critrios satisfatrios de sucesso. Com base nesses questionamentos, Willard (2006) sugere que sejam identificadas mtricas adicionais para definir o sucesso do projeto. Segundo ele, as mtricas deveriam ser identificadas levando em conta como uma implementao beneficiar as principais diretivas do negcio da organizao. A Tabela 3.3 lista uma sria de mtricas agrupadas em trs categorias: gerenciamento de projeto, sucesso do projeto e sucesso do negcio (SHANG, 2002; BERNTHAL, 2005; DAVIES, 2004). Com essa nova viso de mtricas adicionais para mensurar a performance de um projeto, possvel estabelecer sistemas de recompensa com base nos indicadores que mais faam sentido ao projeto ou organizao em questo, ao invs de definir polticas de incentivo, apenas com base em prazo, oramento e escopo.

53

Tabela 3.3 Relao de mtricas por categoria (extrada de WILLARD, 2006). Categoria Gerenciamento de Projeto Mtrica Tempo do projeto Custo do projeto Preciso do projeto (especificaes tcnicas) Requerimentos de mudana Qualidade Segurana Sucesso do Projeto Benefcios para a organizao Satisfao do acionista/stakeholder Satisfao do usurio: nmero de problemas registrados desde a implantao Satisfao do usurio: facilidade de uso/quantidade de uso Satisfao do usurio: alegria/boa vontade dos usurios finais Problemas solucionados que o projeto pretendia solucionar Melhoras no-intencionais/complicaes para os processos/procedimentos Sucesso do Negcio Economia de custos/reduo de custos ROI (Retorno sobre Investimento) Retorno sobre as expectativas Vantagem competitiva Melhora nas eficincias operacionais Oportunidades no futuro Expanso ou melhora nas competncias centrais Aumento na produtividade Reduo na burocracia Reduo nos processos manuais Tempo real de processamento/tempo real de relatrios Aumento na exatido/melhorias em qualidade Melhoras no servio ao consumidor Melhoras no gerenciamento de recursos Crescimento no suporte do negcio Construo de relacionamento externo Flexibilidade aumentada Empowerment

54

Para projetos de desenvolvimento de software open source, j foram identificados indicadores especficos para definir o sucesso para projetos dessa natureza (CROWSTON, 2003). A Figura 3.6 mostra um modelo que sugere seis medidas de sucesso: qualidade do sistema, qualidade da informao, uso, satisfao do usurio, impacto individual e impacto organizacional.

Figura 3.6 Modelo para mensurar sucesso em projetos open source (extrada de CROWSTON, 2003).

Com base nesse modelo, o autor prope um conjunto de indicadores relacionados ao sucesso de projetos open source, conforme descrito na Tabela 3.4. Caso alguma organizao estabelea um sistema de recompensa para projetos dessa natureza, essa relao pode ser utilizada como ponto de partida. Clincy (2003) descreveu algumas recomendaes chaves de um sistema de recompensa que possa promover um aumento de produtividade em equipes de desenvolvimento de software. Esse estudo foi realizado com lderes de equipe de uma empresa listada na revista Fortune 1009. Para cada recomendao, os impactos e as necessidades so listados na Tabela 3.5.

Revista Fortune: http://money.cnn.com/magazines/fortune/

55

Tabela 3.4 Relao de indicadores de sucesso para projetos open source (extrada de CROWSTON, 2003). Medida Qualidade do Sistema e da Informao Indicador Qualidade do cdigo (ex.: entendimento, portabilidade, manutenibilidade, testabilidade, usabilidade, confiabilidade etc) Qualidade da documentao Satisfao do Usurio Uso Notas concedidas pelos usurios Surveys Nmero de usurios Downloads Reuso de cdigo Impactos Individuais e Organizacionais Resultados econmicos

Tabela 3.5 Critrios para sistemas de recompensa em organizaes de software (extrada de CLINCY, 2003). Recomendao Sistemas de recompensa precisam ser objetivos para fomentar a alta produtividade das equipes. Recompensas podem ser financeiras ou no financeiras. Recompensas no financeiras podem ser: dar ao time uma alta visibilidade ou a possibilidade de participar de projetos crticos. Recompensas financeiras individuais podem ser os tradicionais aumentos ou promoes. Na aplicao de fatores objetivos em um sistema de recompense, devem ser feitas consideraes em circunstncias que vo alm do controle das equipes do projeto. Recompensas tambm devem ser consideradas para pesquisas e aplicaes de novas tecnologias. Encorajar os comportamentos individuais e da equipe para aumentar o desempenho. Definir critrios para utilizar na medio dessas reas (pesquisa, novas tecnologias etc). Impacto Um sistema de recompensa objetivo deve encorajar os comportamentos individuais e da equipe para aumentar o desempenho. Necessidade Utilizao de vrias mtricas para medir o desempenho da equipe.

56

3.4

Consideraes Finais Os primeiros estudos realizados sobre formas de incentivo foram publicados

atravs de teorias econmicas. Com o passar dos anos, administradores e psiclogos passaram a contribuir mais com esse assunto e tentar obter formas de implantao nas mais diversas organizaes. H vrias teorias da motivao que procuram explicar o que os gestores podem fazer para estimular seus funcionrios, entre eles, Maslow, Herzberg, McClelland, Vroom, Geertz, Bergamini. Maslow defende que as pessoas so motivadas essencialmente por suas necessidades. Com base nisso, ele apresenta uma hierarquia das necessidades do ser humano, que inicia na dimenso fisiolgica at a auto-realizao do indivduo. Porm, outra teoria que vem sendo utilizada em ambientes organizacionais a teoria da expectativa, proposta por Vroom. Ele procura explicar as relaes entre o esforo do indivduo, o desempenho alcanado, a recompensa e as metas pessoais. Todas as teorias motivacionais propostas possuem alguma limitao e seu uso demanda alguns cuidados. Sistemas de recompensa podem ser utilizados como uma estratgia para estimular a motivao das pessoas e, com isso, obter ganhos de performance. H vrias formas de compensao: financeira, elogios, cartas, prmios, promoes, entre outras. Com base na importncia dos sistemas de medio para quantificar a performance das organizaes, um conjunto de indicadores pode ser utilizado para recompensar as equipes que atingem metas previamente estabelecidas. Espera-se, tambm, que a implantao desses sistemas intensifique o alinhamento dos funcionrios com a estratgia da organizao. De acordo com as pesquisas apresentadas neste captulo, nota-se que a recompensa possui uma posio relevante entre os fatores que motivam as pessoas que trabalham com TI. Apesar de que, nem sempre, a principal forma de recompensa est associada com remunerao financeira. Ainda hoje h dificuldades na implantao desses sistemas, no s pelo desafio de medir a real performance, mas, tambm com as distores introduzidas

57

por aqueles que esto sendo medidos, limitao da criatividade das pessoas em assumir riscos, competies internas nas equipes, entre outros. Mesmo diante dessas dificuldades, h organizaes de software que implantam sistemas de incentivo como forma de aumento de produtividade (FURTADO et AL, 2009b). Porm, mais esforos precisam ser realizados. O principal desafio entender os problemas enfrentados pelas demais reas e definir, dentre outros fatores, um sistema de medio que seja capaz de capturar, ao mximo, as dimenses corretas e os indicadores apropriados, considerando o custo da medio, o impacto cultural, o tamanho da organizao e, principalmente o aspecto comportamental daqueles que esto sendo submetidos ao sistema.

58

RECOMENDAES PARA IMPLANTAO DE UM SISTEMA DE RECOMPENSA EM ORGANIZAES DE SOFTWARE

Este captulo tem o propsito de apresentar algumas recomendaes com o

objetivo de apoiar os gestores das organizaes de software na implantao de um sistema de recompensa como estratgia para aumento de produtividade. A forma de descrio das recomendaes atravs de guidelines, cujo formato segue o padro listado abaixo, que foi baseado na forma como Sommerville os descreveu para engenharia de requisitos e melhoria de processo (SOMMERVILLE E SAWYER, 1997) e foi adaptado fundamentado em uma forma de notao utilizada para descrever padres de software (BRAGA, 2001): Ttulo: Frase curta que identifica o guideline; Problema: Estabelece o problema que o guideline se prope a resolver; Descrio: Breve descrio contextualizando o campo de aplicao do guideline; Benefcios: Alguns direcionamentos dos ganhos esperados pela

organizao com a adoo do guideline; Requisitos: Requisitos mnimos para adoo do guideline; Forma de adoo: Orientaes para adoo do guideline em uma organizao; Custos e problemas: Custos associados com a adoo do guideline e alguns problemas que podem ocorrer; Relacionamentos: Relacionamentos com outros guidelines, de acordo com a seguinte classificao:

59

o Relao de apoio: quando o uso de um guideline d suporte adoo de outro guideline; o Relao de influncia: quando a adoo de um guideline pode influenciar o comportamento de outro guideline; o Relao de uso: quando um guideline pode utilizar (se beneficiar) de outro guideline; o Relao de restrio: quando o uso de um guideline pode restringir a aplicao de outro guideline; o Relao de reavaliao: quando o uso de um guideline pode reavaliar o uso de outro guideline, alterando o seu comportamento. A metodologia utilizada para definir e validar os guidelines ilustrada na Figura 4.1. As etapas referentes validao dos guidelines ser abordada apenas no Captulo 5.

Figura 4.1 Principais etapas da definio e validao dos guidelines.

60

Como mostra a Figura 4.1, a definio dos guidelines foi realizada a partir de duas etapas: a primeira foi atravs da pesquisa bibliogrfica descrita no Captulo 3 e a segunda foi baseada no instrumento de pesquisa chamado observao ou estudo exploratrio (OLIVEIRA, 2008), realizado em uma organizao de desenvolvimento de software. A organizao observada um instituto privado, de inovao, que cria produtos, processos, servios e empresas, usando Tecnologia da Informao e Comunicao (TIC), sediada em Recife, com cerca de 500 funcionrios e, aproximadamente, 300 funcionrios envolvidos diretamente com a gesto e/ou desenvolvimento de software. Ela possui um programa de recompensa, implantado, com foco em aumento de produtividade e reteno de talentos. Os principais tipos de recompensa so: remunerao varivel, reconhecimento pblico, brindes, comisses e remunerao adicional para um grupo de especialistas. Nesse contexto, em abril de 2009 foram realizadas quinze entrevistas, com os seguintes papis: gerentes de projetos, gerentes de venda e engenheiros de software, que participaram do programa de recompensa sob duas perspectivas, ora como provedores da recompensa, ora como beneficirios da recompensa. Por exemplo: um determinado gerente de projeto foi o provedor da recompensa quando indicou um integrante de sua equipe para ser premiado por uma meta atingida. E, em outro momento, esse mesmo gerente de projeto foi beneficiado pelo programa de remunerao varivel por ter alcanado as metas de seu contrato de resultado. No primeiro momento, o objetivo foi entender o funcionamento do programa, os principais benefcios alcanados, dificuldades encontradas e pontos de melhoria. Foi com base nesse levantamento e na reviso bibliogrfica sobre o assunto que os guidelines foram propostos. Para melhor orientar as organizaes, os guidelines foram divididos em trs classificaes, descritas a seguir: tipo, escopo e fase. Possivelmente nem todos os guidelines podem ser aplicados a todas organizaes, visto que cada uma tem suas

61

prioridades e objetivos em relao s estratgias de melhoria de produtividade, alm de estruturas e culturas especficas. A Tabela 4.1 mostra a primeira forma de classificao quanto ao tipo. O principal critrio para classificar um guideline do tipo bsico, intermedirio ou avanado em relao a ordem de adoo.
Tabela 4.1 Tipos dos guidelines. Tipo do Guideline Bsico Descrio Guidelines com maior importncia para a implantao de um sistema de recompensa. Normalmente devem ser utilizados primeiro e minimizam o efeito da disfuno do sistema de medio. Guidelines com importncia secundria na implantao de um sistema de recompensa. So importantes para evitar o efeito da disfuno, mas numa escala menor de que os guidelines bsicos. Guidelines que podem ser adotados em funo da estratgia de recompensa da organizao.

Intermedirio

Avanado

A classificao do guideline quanto ao escopo utilizada para identificar se ele ser adotado na instncia organizacional ou na instncia do projeto. Por fim, a classificao quanto fase utilizada para identificar o momento do ciclo de vida do projeto mais apropriado para sua aplicao, no sendo, portanto, aplicveis para os guidelines com escopo organizacional. A Figura 4.2 ilustra as fases em funo dos grupos de processo de gerenciamento de projetos do PMBOK (2004), acrescido da fase de venda que antecede iniciao do projeto. A fronteira do projeto mostrada nessa mesma figura serve para diferenciar o escopo do guideline em relao ao projeto ou em relao a toda organizao.

62

Figura 4.2 Escopo e fases dos guidelines, segundo os grupos de processo de gerenciamento de projetos do PMBOK (adaptada de PMBOK, 2004).

A Tabela 4.2 mostra a lista dos guidelines propostos e suas respectivas classificaes, quanto ao tipo, escopo e fase.
Tabela 4.2 Lista dos guidelines. Guideline 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 Entendimento dos aspectos motivacionais dos indivduos Definio clara do plano de remunerao varivel Definio de baselines de comparao para mtricas de produtividade Identificao dos participantes na venda do projeto Definio do sucesso do projeto Definio do modelo de gerenciamento da equipe Definio dos indicadores de performance Implantao de um comit independente para avaliao dos resultados Tipo Bsico Avanado Bsico Intermedirio Intermedirio Intermedirio Bsico Intermedirio Escopo Organizacional Organizacional Organizacional Projeto Projeto Projeto Projeto Projeto Fase Venda Iniciao Planejamento Planejamento Monitoramento

A Tabela 4.3 descreve os papis que so mencionados ao longo da descrio dos guidelines. Esses papis podem variar de acordo com a estrutura funcional de cada empresa e sua descrio direciona apenas o nvel de responsabilidade que o profissional desempenha no contexto dos guidelines associados.

63

Tabela 4.3 Descrio dos papis. Papel Gerente de Projeto Descrio Profissional responsvel pelo planejamento e acompanhamento do projeto. Isto engloba, por exemplo, alocao da equipe tcnica apropriada, preparao da infraestrutura, realizao das estimativas e cronograma, gesto dos riscos, entre outros. Profissional responsvel pela gesto de todo o portflio de projetos da organizao. Profissional responsvel pela identificao de novas oportunidades de negcio para a empresa e pela conduo da venda de um projeto. Profissional responsvel pela rea de recursos humanos da empresa. Guidelines associados 4.4, 4.5, 4.6, 4.7, 4.8

Gerente Snior de Projeto Gerente de Negcio

4.7 4.4, 4.7

Gerente de Recursos Humanos

4.1, 4.2

As sees seguintes iro descrever os oito guidelines propostos neste trabalho. 4.1 Entendimento dos Aspectos Motivacionais dos Indivduos

4.1.1 Problema importante entender as necessidades que motivam as pessoas. Recompensas ou outros resultados para motivar as pessoas precisam ser desejados por elas. Os gestores precisam identificar resultados de valor e no simplesmente supor que sabem exatamente o que os funcionrios desejam, ou atribuir as suas prprias necessidades ou desejos a outras pessoas (ROBBINS, 1999). 4.1.2 Descrio esperado que uma distribuio apropriada de recompensas influencie positivamente tanto a satisfao quanto o desempenho. Ambos devem ser considerados dois resultados separados, mas interrelacionados. Portanto, as recompensas bem-administradas so consideradas as chaves para criar tanto a satisfao quanto um alto desempenho para o trabalho. Embora as pesquisas mostrem que as pessoas que recebem grandes recompensas tm maior probabilidade de relatar alta satisfao no trabalho, tambm concluem que as

64

recompensas precisam ser contingenciais em relao ao desempenho para influenci-lo. Isso significa que o tipo da recompensa varia de acordo com o nvel da realizao da pessoa (SCHERMERHORN et AL, 1999). 4.1.3 Benefcios da Adoo As recompensas podem resultar em um desempenho melhor se os trabalhadores tiverem a capacidade de aprimor-lo se, de fato, desejarem as recompensas que esto sendo oferecidas e se houver poucas restries fsicas e psicolgicas (SPECTOR, 2002). A teoria da expectativa diz que um empregado estar motivado a empregar um alto nvel de esforo quando acreditar que o esforo levar a uma boa avaliao de desempenho; que uma boa avaliao de desempenho levar a recompensas organizacionais, como um bnus, um aumento de salrio ou uma promoo; e que as recompensas satisfaro as metas pessoais do empregado (ROBBINS, 1999). 4.1.4 Requisitos Mnimos para Adoo Para a adoo desse guideline faz-se necessrio que os gestores de projetos sejam capacitados em gesto de pessoas com o objetivo de ter conhecimento nas teorias da motivao. A gerncia de recursos humanos da organizao deve apoiar os gestores nessa capacitao. 4.1.5 Forma de Adoo O primeiro passo para a adoo no achar que todos querem a mesma recompensa. A motivao varia de pessoa para pessoa e, ainda, para a mesma pessoa pode variar com o tempo. De acordo com a teoria de Maslow, se desejarmos estimular a motivao de algum, precisamos entender em qual nvel da hierarquia essa pessoa se encontra, no momento, e concentrar nossa ateno na satisfao das necessidades daquele nvel ou do nvel superior.

65

4.1.6 Custos e Problemas O custo de adoo desse guideline j deveria ser um fator inerente s atividades dos gestores. A gesto das pessoas j prev que os lderes devem conhecer seus subordinados e os pontos que podem ser mais estimulados para que tenham suas necessidades satisfeitas. Esse custo tende a aumentar quanto mais pessoas tiver nas equipes. Nesse caso, sugere-se que essa atividade possa ser delegada para lderes de times menores. 4.1.7 Guidelines Relacionados Esse guideline apia a adoo do guideline 4.2 (Definio clara do plano de remunerao varivel).

4.2

Definio Clara do Plano de Remunerao Varivel

4.2.1 Problema Quando um plano de remunerao varivel mal aplicado, pode estimular a desmotivao e prejudicar o desempenho das equipes. Isso ocorre, por exemplo, quando os critrios de remunerao no esto bem definidos, quando no h transparncia no processo ou, ainda, quando no se considera o aspecto cultural da organizao. 4.2.2 Descrio Uma das formas que as organizaes utilizam para recompensar seus funcionrios atravs de um programa de remunerao varivel, normalmente coordenado pela gerncia de recursos humanos. Esse programa permite que sejam estabelecidas algumas metas alinhadas aos objetivos estratgicos da organizao. Com base nessas metas, um conjunto de indicadores estabelecido e utilizado para definir o grau da recompensa.

66

Nesse contexto, caso a organizao opte por definir um plano de remunerao varivel, fundamental que ele seja claramente definido e divulgado por todos aqueles que sero influenciados por ele. 4.2.3 Benefcios da Adoo A recompensa pode ser vista como um diferencial competitivo, desde que implantada de forma adequada. Alguns dos benefcios que podem ser alcanados com um programa de remunerao varivel so: o alinhamento das atividades dos envolvidos aos objetivos esperados pela organizao; o estmulo melhoria contnua, atravs do vnculo entre recompensa e desempenho; o incentivo ao esforo das pessoas para atingirem o sucesso dos projetos (HIPLITO, 2006). 4.2.4 Requisitos Mnimos para Adoo O requisito mnimo necessrio para a adoo deste guideline o entendimento dos aspectos motivacionais das pessoas que sero impactadas pelo programa de remunerao varivel. 4.2.5 Forma de Adoo A visibilidade dos critrios e benefcios do plano fundamental para o seu sucesso. importante que sejam informados os dados de desempenho e todas as formas de medi-lo estejam disponveis para todos os envolvidos. Para que um sistema de recompensa seja eficaz, trs elementos devem estar presentes (SPECTOR, 2002): O trabalhador deve ter a possibilidade de expandir a sua capacidade. Se ele estiver trabalhando no limite de sua capacidade, a introduo de um sistema de recompensa, no maximizar o seu desempenho; As recompensas devem ir ao encontro das necessidades e das expectativas do trabalhador. Nem todo trabalhador deseja trabalhar unicamente em troca do dinheiro, ou seja, para que um sistema de

67

recompensa seja efetivo, deve convergir com que o trabalhador realmente deseja do seu trabalho; No deve haver limitaes fsicas ou psicolgicas para o desempenho do trabalhador. Nesse contexto, para que o plano de remunerao varivel alcance seus objetivos, alguns cuidados devem ser tomados durante sua implantao (KOHN, 1993): A utilizao de incentivos no deve substituir o papel da gerncia de fornecer aos seus subordinados as condies necessrias para realizarem seus trabalhos como treinamentos, ambiente de trabalho, disponibilizao de recursos, entre outros. No se pode apenas conceder algum tipo de bnus e aguardar que a equipe realize um bom trabalho; Os gestores devem dar uma ateno especial aos critrios definidos no plano de remunerao, visto ser comum que as pessoas concentrem seus esforos naquilo onde sero recompensadas. Com isso, o desempenho pode ser prejudicado caso no seja dado valor a outros aspectos importantes. Pesos proporcionais podem ser aplicados a cada um dos indicadores que iro compor a remunerao varivel, de acordo com seu grau de importncia para a organizao. Hiplito (2006) sugere trs etapas para definir um plano de remunerao varivel: Etapa 1: Estabelecer os critrios para a definio do montante que ser distribudo; Etapa 2: Estabelecer os critrios para a distribuio do montante; Etapa 3: Definir os indicadores para aferio e dos resultados individuais/equipes.

68

Essas etapas so importantes, pois fornecem transparncia e minimizam o desgaste entre os envolvidos, aps a obteno dos resultados. Alm disso, permitem o acompanhamento por parte da organizao e dos trabalhadores do que ser atribudo a ttulo de remunerao varivel. A definio dos critrios para distribuio do montante permite que seja acordado, logo no incio, qual o pblico alvo do programa, ou seja, quais as reas e quais as equipes podero ser contempladas com esse sistema de incentivo. Por fim, a ltima etapa permite definir quais as metas estratgicas devero ser consideradas na definio dos indicadores, de que forma ser feita a reviso peridica desses indicadores, fornecer transparncia e confiabilidade do sistema de apurao de resultados, considerar a estratgia e cultura organizacional e prtica de mercado para a concepo de poltica adequada e definir meios de comunicao dos objetivos do programa e de todos os critrios estabelecidos. 4.2.6 Custos e Problemas Os custos relacionados com um plano de remunerao varivel so em funo de muitos fatores, que dependero de cada organizao, por exemplo: A quantidade de pessoas que sero submetidas a esse plano; O valor de cada remunerao, que pode ser, por exemplo, um percentual em funo do salrio do empregado ou em funo da margem de lucro dos projetos; O esforo das pessoas envolvidas na definio e manuteno desse plano, por exemplo, rea de recursos humanos, rea comercial, rea financeira, execuo de projetos. Alguns problemas envolvidos com esse tipo de plano podem ser destacados: Nem sempre dinheiro o principal aspecto que ir estimular a motivao das pessoas no sentido de atingir um determinado desempenho. Ele pode ter apenas um efeito temporrio, ou seja,

69

importante que a empresa esteja atenta e possa considerar outras formas de incentivos, em seu programa de recompensa; As recompensas tambm podem ter um efeito punitivo quando elas no so ganhas. 4.2.7 Guidelines Relacionados Este guideline pode influenciar a adoo do guideline 4.4 (Identificao dos participantes da venda do projeto); apoiado pela adoo do guideline 4.2 (Entendimento dos aspectos motivacionais dos indivduos); e pode utilizar o guideline 4.7 (Definio dos indicadores de performance).

4.3

Definio de Baselines de Comparao para Mtricas de Produtividade

4.3.1 Problema A utilizao de sistemas de recompensa com base em metas de produtividade da equipe de desenvolvimento de software pode no ser adequada quando a medio da produtividade distorcida, por no considerar todos os fatores relevantes que a afetam. 4.3.2 Descrio Alguns sistemas de medio utilizam indicadores de tamanho fsico (LOC/h), ou funcionais (PF/h; UCP/h), para medir a produtividade da equipe de desenvolvimento de software. Qualquer que seja o indicador escolhido h vrios outros fatores que podem afetar a produtividade da equipe: linguagem de programao, uso de ferramentas case, experincia da equipe etc. Para afirmar que a meta da produtividade foi atingida ou para comparar produtividades entre projetos, faz-se necessrio definir para a organizao especfica quais sero os fatores que podem influenciar na performance das equipes e categorizar os projetos com base em diversos parmetros: tamanho, prazo, tecnologia, tipo de cliente etc.

70

H vrios estudos que relatam os fatores que afetam a produtividade, por exemplo, YU et AL (1991); BOEHM et AL (1982); BOEHM (1999); MAXWELL E FORSELIUS (2000). 4.3.3 Benefcios da Adoo Os seguintes benefcios podem ser alcanados com a adoo deste guideline: Definir um padro de caractersticas de projetos que permita estipular metas de produtividade, de acordo com os atributos do projeto especfico; Definir um padro de caractersticas de projetos que permita comparar a performance de diferentes equipes, apenas entre projetos com atributos semelhantes. Esse tipo de orientao permite que uma situao, como a descrita, a seguir, seja evitada. A Figura 4.3 ilustra um indicador que mede a produtividade da equipe de um projeto de desenvolvimento de software, em horas trabalhadas, divididas por pontos de casos de uso, ou seja, quantas horas so consumidas para produzir um ponto de caso de uso. A ordenada deste grfico representa o indicador de produtividade (h/UCP10) e a abscissa representa todos os projetos medidos em um determinado perodo. Nota-se que a produtividade varia de 5h/UCP at 55h/UCP, ou seja, uma variao de 1.000% entre o projeto de maior produtividade e o projeto de menor produtividade. Porm, nem todos os projetos possuem as mesmas caractersticas relacionadas com tecnologia, domnio de negcio, maturidade da

10

Apesar do conceito de produtividade ser definido por output dividido por input, ou seja, valor

produzido dividido por valor consumido, esse indicador especfico foi definido de forma invertida (input dividido por output). O problema com essa medida original que seria necessrio saber a quantidade de horas de trabalho correspondente a um ms, para que possam ser feitas comparaes. Algumas empresas definem o ms com 130 horas trabalhadas, outras com 160 horas, etc. No Brasil, em geral, os contratos de trabalho so feitos com base no preo de um ponto de funo ou de um ponto de caso de uso. Uma vez que esses valores so invertidos, facilita-se a precificao do contrato do trabalho (AGUIAR, 2003).

71

equipe etc. Isso quer dizer que em um cenrio como esse no possvel comparar qual projeto obteve uma melhor produtividade em relao aos demais, e, conseqentemente, utilizar esse indicador como base para o programa de recompensa.

Figura 4.3 Exemplo de indicador de produtividade.

Ao aplicar esse guideline sugerido, o indicador passaria a ser analisado por grupos de projetos com categorias similiares. 4.3.4 Requisitos Mnimos para Adoo No h requisitos mnimos necessrios para a adoo desse guideline, ou seja, a organizao pode iniciar sua adoo a qualquer momento. 4.3.5 Forma de Adoo A adoo desse guideline envolve fazer um levantamento dos projetos existentes na organizao e classific-los de acordo com parmetros que ajudem na identificao de projetos similares. Por exemplo: tecnologia, tipo de contrato, tamanho da equipe, entre outros. Com base nesse levantamento, uma infra-estrutura precisa ser implantada. Isso significa o uso de alguma ferramenta para armazenar os dados histricos dos projetos e que disponibilize consultas por projetos similares. Em seguida, os indicadores de produtividade devem ser definidos com base nas caractersticas dos projetos, anteriormente levantadas. Alm disso, as metas a

72

serem alcanadas pelas equipes sero estabelecidas a partir de uma baseline inicial, coletada nas informaes histricas. 4.3.6 Custos e Problemas Os principais custos relacionados adoo desse guideline envolve a alocao de profissionais para realizar o levantamento dos projetos e definio dos atributos de similaridade de projetos. Alm disso, dependendo da infra-estrutura utilizada, o custo pode variar desde o uso de planilhas eletrnicas at a aquisio ou desenvolvimento de uma ferramenta que possibilite o cadastramento e consulta dos dados histricos dos projetos. 4.3.7 Guidelines Relacionados Esse guideline pode ser utilizado pelos guidelines 4.5 (Definio do sucesso do projeto) e 4.7 (Definio dos indicadores de performance).

4.4

Identificao dos Participantes na Venda do Projeto

4.4.1 Problema Quando as estimativas de esforo, prazo ou custo so estabelecidas na proposta de venda de um projeto pelas mesmas pessoas que iro participar de sua execuo, podem ser geradas propostas super-estimadas, caso essas pessoas sejam posteriormente submetidas a um sistema de recompensa, por exemplo, um programa de remunerao varivel para gerentes de projeto baseado no cumprimento das estimativas.

73

4.4.2 Descrio As pessoas envolvidas na venda de um projeto, como, por exemplo, gerentes de projetos, no devem influenciar as estimativas em funo de um contrato de resultados11 em que sero submetidas ao longo da execuo do projeto. A partir do momento em que as pessoas que so envolvidas na venda do projeto no so as mesmas que iro participar da sua execuo, evita-se o risco de a estimativa ser super-dimensionada. Esse tipo de comportamento pode ocorrer caso o gerente do projeto seja submetido a um contrato de resultado que controle a variao do oramento ou prazo do projeto. Para evitar um mau desempenho em seu resultado final, as estimativas de esforo e custo podem ser elevadas em um percentual de risco que aumente o preo do projeto. Isto pode tornar a empresa menos competitiva no mercado e diminuir a quantidade de negcios contratados. 4.4.3 Benefcios da Adoo O principal benefcio desse guideline a imparcialidade dos responsveis pelas estimativas de prazo e custo, estabelecidas na proposta de venda do projeto. Na medida em que essas pessoas no so recompensadas por essas dimenses, a tendncia que as propostas no sejam influenciadas por interesses pessoais. 4.4.4 Requisitos Mnimos para Adoo Para que seja possvel a adoo desse guideline, faz-se necessrio existir na organizao uma rea responsvel pela alocao dos recursos que iro participar das estimativas durante o processo de venda. Alm disso, deve existir uma

11

Neste trabalho, o termo contrato de resultado um conjunto de metas estabelecidas

periodicamente entre uma pessoa, ou equipe, e a organizao em que o servio est sendo prestado ou o produto est sendo desenvolvido. Cada meta avaliada ao final de um perodo e uma nota fornecida. comum que o resultado desse contrato seja utilizado pelas organizaes como alguma forma de recompensa, seja relacionada a promoes, benefcios, re-enquadramentos etc., de acordo com a poltica de recompensa e remunerao de cada empresa.

74

quantidade grande de profissionais com habilidades semelhantes para possibilitar um rodzio nas alocaes. 4.4.5 Forma de Adoo A rea responsvel pela alocao dos recursos precisa entender o domnio de negcio e a tecnologia em que a venda est inserida para identificar os possveis profissionais capacitados para apoiarem no levantamento das necessidades do cliente e na realizao das estimativas de esforo e custo. Com base nessa relao de pessoas, a rea responsvel deve selecionar aqueles que tero pouca possibilidade de serem alocados para serem responsveis pela execuo do projeto, caso a venda seja concretizada. 4.4.6 Custos e Problemas O custo de adoo est relacionado a dois fatores: a criao e a manuteno de uma rea responsvel pela alocao dos recursos que devem ser envolvidos numa venda. Isso se torna crtico para as empresas em que existe uma nica pessoa responsvel por isso e o volume de propostas sendo elaboradas, ao mesmo tempo, alto. Caber a essa pessoa entender cada uma delas e alocar o gerente mais apropriado. O segundo fator est relacionado com a necessidade de ter uma quantidade disponvel de gerentes com habilidades semelhantes de domnio de negcio e tecnologia. No caso de empresas em que h uma grande diversidade de projetos, o custo de manter pessoas com o mesmo perfil torna-se alto. Como resultado dessas restries, o tempo de elaborao de uma proposta pode ser elevado, podendo levar a perda de um contrato. Para que isso seja evitado, faz-se necessrio avaliar a diversidade de tipos de projetos existentes na organizao e os perfis disponveis. Em funo dessa anlise, esse guideline pode no ser aplicvel em todas as propostas. Uma anlise de custo e benefcio deve ser realizada.

75

Um problema que pode ser causado com a adoo desse guideline que muitas organizaes preferem que o responsvel pela execuo do projeto tenha participado das suas estimativas iniciais. Com isto, espera-se obter um maior comprometimento dele. Nesse caso, importante que a organizao esteja atenta ao selecionar os indicadores que iro compor o sistema de recompensa dos envolvidos e que avalie o benefcio da imparcialidade versus o comprometimento com as estimativas. 4.4.7 Guidelines Relacionados Esse guideline pode ser influenciado pela adoo do guideline 4.2 (Definio clara do plano de remunerao varivel).

4.5

Definio do Sucesso do Projeto

4.5.1 Problema Os critrios que definem o sucesso ou o fracasso de um projeto nem sempre esto bem alinhados entre a alta direo da organizao e os responsveis pela execuo de um projeto. E quando esses critrios so utilizados como base para um sistema de recompensa, os resultados do projeto podem ser interpretados de maneiras distintas. 4.5.2 Descrio O sucesso de um projeto pode ser utilizado como critrio de avaliao no contrato de resultados do gerente ou da equipe que o executou. Porm, essa definio de sucesso pode variar em funo de muitos fatores. Por exemplo: o modelo de negcio, os objetivos estratgicos da organizao, entre outros. Sendo assim, importante que o conceito de sucesso esteja claro para cada projeto, antes do incio de sua execuo.

76

H pesquisas que confirmam que o sucesso de um projeto um conceito multi-dimensional (SHENHAR E RENIER, 2002). Os projetos no podem ser avaliados sempre com base nas mesmas dimenses. Um projeto pode fornecer uma soluo eficiente para as necessidades do cliente, mas, ainda assim, ser considerado um fracasso pelo retorno que trouxe organizao. Do mesmo modo, alguns projetos so considerados bem sucedidos em curto prazo, mas isso pode no ser verdade em longo prazo, e vice-versa. Em alguns casos, necessrio passar um tempo at as expectativas iniciais serem realmente cumpridas e o sucesso avaliado. 4.5.3 Benefcios da Adoo Baccarini (1999) afirma que as mtricas tradicionais permitem apenas uma viso em relao ao sucesso do processo do gerenciamento do projeto, visto que so focadas no processo do projeto, e, em particular, no cumprimento bem-sucedido dos objetivos de custo, tempo e qualidade. Willard (2006) sugere que sejam identificadas mtricas adicionais para definir o sucesso do projeto. Segundo ele, as mtricas deveriam ser identificadas levando em conta como uma implementao beneficiar as principais diretivas do negcio da organizao. Sendo assim, a definio correta de como o sucesso de um projeto ser medido far com que os envolvidos por sua execuo estejam cientes dos reais objetivos do projeto e os critrios que sero avaliados em seus contratos de resultados. 4.5.4 Requisitos Mnimos para Adoo No h requisitos mnimos necessrios para a adoo desse guideline, ou seja, a organizao pode iniciar sua adoo a qualquer momento. 4.5.5 Forma de Adoo Definir o sucesso de um projeto uma atividade que depender, principalmente, do alinhamento desse projeto com a estratgia da organizao e do tempo em que o projeto foi completado. Em geral, as organizaes de software relacionam o sucesso de um projeto com o atendimento aos prazos, oramento e

77

escopo definidos. Esse modelo faz sentido em grande parte dos projetos. Porm, h casos em que a estratgia da organizao est direcionada para obter um determinado cliente ou executar um projeto estratgico de algum outro cliente, entre outros casos. Nessas situaes, o sucesso do projeto pode no ser medido apenas pelos trs indicadores mencionados anteriormente (prazo, oramento e escopo). O projeto poder ter obtido sucesso mesmo com o oramento variado, mas, a estratgia com o cliente foi atendida e isso passou a ter um peso maior para um contexto especfico. H casos em que medir o projeto em relao ao atendimento ao prazo pode prejudicar a qualidade do produto que est sendo entregue. Faz-se necessrio, ento, definir quais os critrios de qualidade que devero ser mensurados, para evitar que o prazo seja atendido, mas o produto no esteja de acordo com o nvel de aceitao definido para o projeto. Uma abordagem que pode ser utilizada na implementao desse guideline atravs da relao entre a categoria do sucesso, definida pela organizao em funo de seus objetivos estratgicos, e a forma de med-lo, conforme mostra a tabela abaixo.
Tabela 4.4 Critrios de sucesso do projeto (extrada de SHENHAR E RENIER, 2002). Categoria do Sucesso Eficincia do projeto (Pr-finalizao) Benefcio ao cliente (Curto prazo) Medida do Critrio de Sucesso Atendimento ao cronograma Atendimento do oramento Atendimento a outras restries de recurso Ganho de performance Impacto favorvel ao cliente Satisfazer as necessidades do cliente Resoluo de um problema do cliente Cliente est utilizando o produto Cliente expressa satisfao Contribuio atual (Mdio prazo) Sucesso comercial ou de negcio Melhoria nos lucros Mercado ampliado

78

Categoria do Sucesso Oportunidade futura (Longo prazo)

Medida do Critrio de Sucesso Ser criada uma nova oportunidade no futuro O cliente ser posicionado de forma competitiva Ser criado um novo mercado Ir apoiar no desenvolvimento de uma nova tecnologia

Esses critrios possuem uma dependncia com o tempo, como mostra a Figura 4.4, ou seja, para um determinado projeto, a percepo de sucesso pode mudar ao longo do tempo. Isto depender do tempo decorrido desde a sua concluso. Por exemplo, um projeto pode ter o seu principal foco na criao de oportunidades futuras (quarta categoria). Portanto, pouco provvel que ele seja visto como bem sucedido at que essas oportunidades tenham efetivamente materializado. Uma vez que a organizao consegue ter essa real noo do que representa sucesso dentro de seu portflio de projetos, os contratos de resultados sero melhor aplicados.

Figura 4.4 Dependncia do sucesso do projeto em funo do tempo de completude (extrada de SHENHAR E RENIER, 2002).

79

4.5.6 Custos e Problemas O custo de definio desse guideline inicialmente baixo, desde que ele esteja relacionado, apenas, com o esforo de identificao dos critrios que definem o sucesso de cada projeto que ser iniciado. Porm, o custo poder ser elevado medida que seja complexa a coleta e anlise dos indicadores de sucesso do projeto. 4.5.7 Guidelines Relacionados Esse guideline pode utilizar os guidelines 4.3 (Definio de baselines de comparao para mtricas de produtividade) e 4.7 (Definio dos indicadores de performance). Alm disso, pode ser reavaliado pelo guideline 4.8 (Implantao de um comit independente para avaliao de resultados).

4.6

Definio do Modelo de Gerenciamento da Equipe

4.6.1 Problema Em geral, os sistemas de recompensa utilizam indicadores com base para as decises de incentivo das equipes. Se a definio desses indicadores no considerar o modelo de gesto da equipe, possvel que alguns deles no sejam viveis de mensurao e acompanhamento, inviabilizando as metas estabelecidas pelo sistema de recompensa. 4.6.2 Descrio A escolha do modelo de gerenciamento da equipe de desenvolvimento de software deve ser considerada ao tentar definir como um contrato de resultados ser aplicado em um programa de recompensa. De uma maneira geral, podemos considerar trs modelos de gerenciamento da equipe: nenhuma superviso, superviso parcial e superviso total. Essa categorizao est de acordo com o modelo proposto por Austin (1996).

80

4.6.3 Benefcios da Adoo O correto entendimento de qual modelo de gesto ser utilizado para planejar e acompanhar as atividades das equipes fundamental para definir quais dimenses podero ser utilizadas em um contrato de resultados. Isto possibilitar que no incio do projeto as expectativas sejam alinhadas em relao aos indicadores que podero ser coletados e quais deles sero utilizados para recompensar a equipe ao final do projeto. Assim, tanto ficar claro para os gestores o que poder ser cobrado das equipes, quanto para as equipes o que ser considerado no momento de serem recompensadas. 4.6.4 Requisitos Mnimos para Adoo No h requisitos mnimos necessrios para a adoo desse guideline, ou seja, a organizao pode iniciar sua adoo a qualquer momento. 4.6.5 Forma de Adoo No caso do modelo escolhido ser o auto-gerenciamento, ou seja, nenhuma superviso ser realizada equipe, no ser possvel quantificar claramente metas associadas a essa equipe. Dessa forma, o contrato de resultados no ter dados objetivos para recompensar as pessoas. No caso do modelo escolhido ser superviso parcial, ser necessrio identificar quais dimenses podero ser definidas, coletadas e analisadas, para s ento definir claramente como o contrato de resultados dever ser formulado. Nesse tipo de modelo, como a equipe no completamente gerenciada, nem todas as dimenses podem ser coletadas. Por exemplo: o gerente do projeto poder acompanhar apenas se os prazos so atendidos, mas, no acompanhar se o esforo realizado pela equipe est dentro de uma variao planejada. Em um caso como este, o contrato de resultados da equipe dever considerar apenas as metas relacionadas com o sucesso obtido por entregar os produtos dentro dos prazos acordados, mas, no ir considerar se foi necessrio realizar mais ou menos horas para cumpri-los.

81

Por fim, se o modelo de gesto escolhido for o de superviso total, qualquer dimenso poder ser avaliada no contrato de resultados da equipe. Por exemplo: entregas no prazo, cumprimento das estimativas de tamanho, esforo e custo, quantidade de linhas de cdigo, pontos de funo, pontos de casos de uso etc, produzidas por unidade de tempo, densidade de defeitos etc. A definio de qual modelo de gesto ser utilizado em um projeto especfico no deve ser apenas uma deciso unilateral do gerente do projeto. Outros aspectos tambm devero ser considerados, por exemplo: Maturidade e experincia da equipe. Equipes imaturas ou com baixo nvel de experincia no domnio ou tecnologia utilizados no so propcias a serem auto-gerenciadas; Custo da gesto do projeto. Definir um modelo do tipo superviso total implicar em um custo de gerenciamento maior, visto que ser necessrio definir vrios indicadores e pontos de controle para acompanhar o progresso do projeto; Importncia estratgica do projeto para a organizao. Dentro da gesto de portflio de uma empresa, alguns projetos possuem uma importncia maior que outros, em funo de um maior alinhamento com a estratgia da organizao. Para esses projetos, o modelo de gesto adotado pode ter um grau de superviso maior. Com base nessas caractersticas, a organizao dever definir qual o modelo de gesto ser mais apropriado para o projeto. Porm, caber a organizao considerar outras caractersticas para apoiar nesta definio. 4.6.6 Custos e Problemas O principal custo para adoo desse guideline est relacionado com o tipo de superviso gerencial que ser utilizado no projeto. Como dito na Seo anterior, quanto maior o nvel de superviso para gerenciar a equipe, maior pode ser a quantidade de dimenses que sero coletadas e analisadas. Por mais simples que

82

seja o processo de medio e anlise de uma organizao, algumas atividades mnimas so executadas em relao aos indicadores. Por exemplo: definio, coleta, anlise e divulgao (SEI, 2006). Alm disso, tambm est associado o custo da infra-estrutura para registrar e manter os dados coletados. Quanto maior essa complexidade do processo de medio e anlise, tambm poder ser necessria uma equipe responsvel pela organizao e evoluo do programa de medio da empresa. Um problema que precisa ser evitado com o uso desse guideline que mesmo que o tipo de superviso esteja adequado ao projeto, nem sempre o contrato de resultados poder captar todas as dimenses necessrias para recompensar as equipes, seja pelo alto custo de coleta de um indicador, seja pelo risco de provocar o efeito da disfuno no programa de medio existente. Sendo assim, faz-se necessria uma anlise crtica do custo e benefcio das dimenses que sero utilizadas em funo do modelo de gerenciamento escolhido. Nesses casos, pode ser considerada a utilizao de anlises qualitativas como parte do programa de recompensa, desde que esteja claro para todos os envolvidos. Segundo Baker (BAKER et AL, 1994), esse tipo de anlise pode ser utilizada como forma de mitigar as distores em um sistema de incentivo, causadas por medidas objetivas imperfeitas, combinando alguns componentes subjetivos. Mesmo que as medidas subjetivas no sejam perfeitas, elas podem complementar ou melhorar as medidas objetivas disponveis. 4.6.7 Guidelines Relacionados Esse guideline pode restringir o guideline 4.7 (Definio dos indicadores de performance).

83

4.7

Definio dos Indicadores de Performance

4.7.1 Problema Os contratos de resultados que so utilizados para medir o desempenho das equipes e recompens-las nem sempre so definidos de maneira adequada e esto alinhados aos objetivos estratgicos da organizao. 4.7.2 Descrio Os indicadores utilizados para medir a performance das equipes devem ser definidos previamente ao contrato de resultados. Esses indicadores podem variar em funo dos objetivos estratgicos da organizao e no devem seguir uma regra padro para todas as empresas. Para empresas onde o modelo de negcio est relacionado com uma fbrica de software, os indicadores podem estar relacionados, por exemplo, com entregas no prazo e densidade de defeitos. Por outro lado, modelos de negcio relacionados com inovao, os indicadores podem ser definidos com base em outras dimenses. Por exemplo, grau de impacto do produto lanado no mercado ou aprendizagem de uma determinada tecnologia. 4.7.3 Benefcios da Adoo Definir os indicadores com base nas dimenses corretas em funo do modelo de negcio da empresa faz com que os objetivos do projeto em execuo estejam alinhados com a estratgia da organizao. Desta maneira, o contrato de resultado aplicado equipe do projeto ser definido e medido de forma a minimizar que os interesses pessoais no interfiram nos interesses do projeto. De acordo com Austin (1996), o principal problema para a maioria dos sistemas de incentivo em uso pelas organizaes no a preocupao com as medidas de desempenho, mas, sim, com as distores intencionalmente introduzidas por aqueles que esto sendo medidos. Sendo assim, deixar claro para o gerente do projeto sob quais aspectos ele e sua equipe sero avaliados ao longo de todo o projeto ajudar a minimizar o efeito da disfuno na coleta e anlise dos

84

indicadores de satisfao do cliente, visto que o gerente tambm ser avaliado em funo de outros aspectos internos da organizao. 4.7.4 Requisitos Mnimos para Adoo O principal requisito para que esse indicador seja adotado a existncia clara de quais so os objetivos e metas organizacionais para que estas sejam alinhadas com as metas do projeto. 4.7.5 Forma de Adoo No incio do projeto, a gerncia snior de projetos e o gerente de negcios devero analisar junto com o gerente responsvel pela execuo do projeto quais so os objetivos estratgicos que devero ser alcanados e como eles esto alinhados aos objetivos do projeto. Esses objetivos devem fazer parte da contabilizao do indicador final de desempenho do projeto. Os indicadores utilizados para medir a performance de uma equipe devem ser definidos atravs de um sistema de medio. H vrias tcnicas e metodologias com esse propsito. Por exemplo: Balanced Scorecard, Goal Question Metric e Practical Software and Systems Measurement. Na implantao de um sistema de medio, importante que os indicadores possam ser baseados em mais de uma dimenso para evitar o efeito da disfuno do sistema. Uma vez que os indicadores so definidos, alguns critrios podem ser estabelecidos para atribuir pesos que ponderem a importncia de cada indicador em um projeto especfico. E, com isso, possam transmitir um maior senso de justia para aqueles que esto sendo recompensados. 4.7.6 Custos e Problemas Os custos de adoo desse guideline estaro diretamente relacionados com o custo de implantao do sistema de medio, na empresa, que poder variar em funo da metodologia escolhida, recursos envolvidos na implantao do sistema e, principalmente, na diversidade de modelos de negcio existentes na organizao.

85

Quanto maior essa diversidade, maior a quantidade de dimenses para medir a performance e maior o custo de coletar e analisar os indicadores. Nem sempre possvel identificar todas as dimenses para definio dos indicadores de performance. Alm disso, h casos em que as dimenses so conhecidas, mas o custo associado com a coleta dos dados pode ser alto e no justifique o seu uso. Nesses casos, o sistema de medio implantado pode no refletir a real performance alcanada por uma equipe em um determinado projeto e, conseqentemente, o contrato de resultados poder no surtir o efeito desejado. 4.7.7 Guidelines Relacionados Esse guideline pode utilizar o guideline 4.3 (Definio de baselines de comparao para mtricas de produtividade) e pode ser utilizado pelos guidelines 4.5 (Definio do sucesso do projeto) e 4.2 (Definio clara do plano de remunerao varivel). Alm disso, pode ser reavaliado pelo guideline 4.8 (Implantao de um comit independente para avaliao dos resultados) e pode ser restringido pelo guideline 4.6 (Definio do modelo de gerenciamento de equipe).

4.8

Implantao de um Comit Independente para Avaliao dos Resultados

4.8.1 Problema comum que mesmo estabelecendo medidas quantitativas da performance das equipes, o avaliado ou o avaliador possa manipular as medidas, e, portanto, elas no iro refletir exatamente o que esto predispostas a medir (GIBBS et AL, 2004). Alm disso, nem sempre as medidas quantitativas conseguem captar todas as informaes necessrias para a tomada de decises em sistemas de recompensas.

86

4.8.2 Descrio O processo de implantao de um programa de recompensas no completamente objetivo e fcil de ser seguido. Isso vai depender, dentre outros fatores, do nvel dos critrios definidos pela organizao, para recompensar as pessoas e das incertezas que podem existir em um programa de medio que utiliza seus indicadores como forma de incentivo s equipes. O uso da subjetividade permite aos avaliadores explorarem qualquer informao relevante, que surja durante o perodo da medio para beneficiar tanto a empresa quanto o empregado. Alm disso, sabe-se que, mesmo nos ambientes mais simples, haver fatores que estaro fora do controle dos gerentes e, portanto, inicialmente no faro parte dos sistemas de medio. Para esses fatores, o uso da subjetividade poder facilitar a atribuio das recompensas (GIBBS et AL, 2004). Vrias empresas mitigam o efeito causado pela distoro de medidas de performance objetivas com o uso de avaliaes subjetivas da performance (BAKER et AL, 1994). Sugere-se, ento, a implantao de um comit, que seja capaz de analisar eventuais distores, dados subjetivos e que tenha autonomia para ajustar os indicadores e metas, previamente estabelecidas. 4.8.3 Benefcios da Adoo O estabelecimento de um comit independente de avaliao dos resultados pode ser capaz de corrigir eventuais distores detectadas durante o processo de coleta e anlise dos indicadores, assim como durante o processo de atribuio das recompensas. As avaliaes dos resultados de um sistema de recompensa podem causar injustias em funo do grau de subjetividade que alguns indicadores podem apresentar, alm de ser muito difcil prever todos os critrios que iro ser utilizados no programa. Este um processo que exige tempo e maturidade da organizao.

87

Com a implantao do comit, ser criada a oportunidade de fazer a calibragem dos indicadores e dos critrios de recompensa. 4.8.4 Requisitos Mnimos para Adoo Para viabilizar a adoo desse guideline, necessrio que a empresa tenha disponibilidade de tempo de uma equipe imparcial e com poder de deciso na organizao. 4.8.5 Forma de Adoo A forma de adoo desse guideline pode variar em funo do tamanho da empresa e da maneira como ela funcionalmente organizada. A organizao dever selecionar um conjunto de pessoas que sejam imparciais ao programa de recompensa. ideal que no sejam os gestores imediatos das equipes que sero avaliadas. Esse comit deve se reunir periodicamente e precisa ser formado por uma equipe com representantes de reas diferentes e com poder de deciso na organizao. Por exemplo: superintendncia executiva, recursos humanos, diretoria executiva etc. Essa multidisciplinaridade do comit importante tambm para que determinados aspectos, que no estavam inicialmente definidos, possam ser levados em considerao. O contexto em que alguns projetos so executados e o seu alinhamento com as estratgias da organizao podem sofrer mudana com o passar do tempo. Mesmo que o programa de recompensa e os indicadores no tenham sido revistos em tempo, caber ao comit reavaliar cada caso especfico e considerar essas mudanas nas decises tomadas. 4.8.6 Custos e Problemas O custo envolvido com a adoo desse guideline est diretamente relacionado com o tempo de alocao das pessoas que iro participar do comit.

88

Portanto, ir variar em funo do cargo que essas pessoas ocupam e da periodicidade das reunies. O principal problema que deve ser observado nesta adoo com a discricionariedade que as decises podem ter. O comit deve ter sempre em mente que mesmo que a sua existncia seja para mitigar o risco da subjetividade, em alguns critrios de recompensa e na anlise de alguns indicadores, deve haver algumas regras para que as decises sejam tomadas. Por exemplo: a unanimidade das decises do comit pode ser um dos critrios para evitar esse tipo de problema. Caso contrrio, os avaliados podem ter a sensao que o sistema de recompensa no possui transparncia adequada a toda a empresa. Com isso, o sistema passa a ser desacreditado e no alcanar seus objetivos. Embora muitas vezes a subjetividade possa proporcionar benefcios, tambm pode adicionar outra forma de risco, causando injustias nas avaliaes de desempenho (PRENDERGAST, 1993). Se os subordinados no confiam nos seus avaliadores, o resultado pode o ser empregado frustrado, desmotivado e aumento do turnover. Alm disso, quando as avaliaes so subjetivas, os empregados podem tentar influenciar indevidamente os supervisores para receberem uma melhor avaliao. 4.8.7 Guidelines Relacionados Esse guideline pode ser utilizado para reavaliar periodicamente os guidelines 4.5 (Definio do sucesso do projeto) e 4.7 (Definio dos indicadores de performance).

89

4.9

Relacionamento entre os Guidelines Para facilitar a adoo dos guidelines e o entendimento de como eles esto

relacionados entre si, foi definida uma forma visual baseada na notao descrita na Figura 4.5.

Figura 4.5 Notao utilizada para ilustrar o relacionamento entre os guidelines.

90

A Figura 4.6 ilustra como os guidelines esto relacionados, de acordo com as categorias de relacionamento descritas no inicio deste Captulo, e os respectivos escopos e fase de atuao.

Figura 4.6 Relacionamento entre os guidelines.

91

4.10 Consideraes Finais Este captulo apresentou oito recomendaes, em forma de guidelines, com o objetivo de apoiar os gestores na implantao de um sistema de recompensa como uma estratgia de melhoria na produtividade das equipes. Contudo, a viabilidade da aplicao desses guidelines ir depender do porte da organizao, cultura, disponibilidade financeira, entre outros. Um aspecto importante que deve ser considerado no momento de definir indicadores em um sistema de recompensa est relacionado com o custo. DeMarco (2009) afirmou recentemente que nos dias atuais as pessoas j entendem que mtricas de software custam dinheiro e tempo e, por isso, devem ser utilizadas de forma moderada. Alm disso, desenvolvimento de software inerentemente diferente de uma cincia natural, como a fsica, com mtricas muito menos precisas. Uma boa estratgia iniciar com pequenas formas de recompensas que nem sempre esto associadas a alto custo. Por exemplo: reconhecimentos pblicos e pequenos prmios, e que possam mostrar resultados rpidos. A lista de guidelines apresentada neste captulo no exaustiva. Vrias outras diretrizes relacionadas com sistemas de recompensa podem ser aplicadas, muitas deles com baixo custo. A seguir, esto mais alguns exemplos citados por Deeprose (2006): Envolver os empregados na definio do sistema de recompensa; Determinar critrios de recompensa especficos e que possam contemplar todos os empregados; Garantir que as recompensas esto em sintonia com os valores da organizao; Reconhecer tanto comportamento, quanto as metas atingidas; Individualizar as recompensas, ou seja, dar s pessoas o que de fato as interessam;

92

Agradecer os empregados o tempo todo; Recompensar todo o time quando a meta atingida for conjunta. Este mesmo autor cita, em seu livro, 150 maneiras diferentes de conceder recompensas, independente do tipo de organizao.

93

VALIDAO DOS GUIDELINES

Este captulo tem o objetivo de descrever como os guidelines propostos no

Captulo 4 foram validados: metodologia utilizada, anlise dos dados, limitaes da pesquisa e principais concluses. 5.1 Metodologia Utilizada A metodologia utilizada para validao dos guidelines propostos foi baseada no instrumento de pesquisa chamado pesquisa de campo (OLIVEIRA, 2008), conforme ilustra a Figura 4.1. Esta pesquisa foi realizada atravs de um questionrio com questes fechadas, mas todas elas com a possibilidade do participante realizar comentrios sobre o assunto abordado. Foi considerado um pblico-alvo constitudo por empresas brasileiras que atuam no setor de desenvolvimento de software. O questionrio foi dividido em quatro partes, descritas a seguir. A primeira parte foi sobre as informaes da empresa do respondente (Questo 1): Confirmao se a empresa de desenvolvimento de software; Localizao geogrfica (Estado); Tempo de mercado (em anos); Tamanho da empresa: medido pela quantidade aproximada de profissionais envolvidos com a gesto e o desenvolvimento de software; Funo atual do respondente. A segunda parte foi composta por trs perguntas relacionadas com o uso de indicadores em projetos de desenvolvimento de software:

94

Questo 2: possvel definir os mesmos indicadores padres para todo tipo de projeto, com o objetivo de avaliar a produtividade de uma equipe de desenvolvimento de software? Questo 3: Normalmente, o sucesso de um projeto avaliado utilizando as dimenses tradicionais 'custo, escopo, prazo e qualidade'. Voc acha que possvel avaliar o sucesso do projeto com base em dimenses diferentes? Questo 4: Cada organizao que desenvolve software deve definir quais so os fatores que podem influenciar na produtividade de suas equipes e categorizar os projetos com base em diversos parmetros: tamanho, prazo, domnio de negcio, tecnologia, tipo de cliente, entre outros. Essa categorizao importante, pois possibilitar a comparao da produtividade de diferentes equipes, apenas entre projetos com caractersticas semelhantes. A terceira parte foi composta por quatro perguntas relacionadas com programas de recompensa, como uma estratgia para aumento da produtividade das equipes que desenvolvem software, contextualizando, antes, para o respondente o significado de um programa de recompensa: Questo 5: Programas de recompensa (ex.: remunerao varivel, prmios, reconhecimento pblico etc) so teis para melhorar a produtividade das pessoas que trabalham com projetos de desenvolvimento de software? Questo 6: H algum programa de recompensa (ex.: remunerao varivel, prmios, reconhecimento pblico etc) implantado na empresa onde voc trabalha? Questo 7: Caso exista algum programa de recompensa na sua empresa, voc acha que ele foi implantado de forma adequada?

95

Questo 8: importante existir uma lista de recomendaes/guias sobre como orientar os gestores a definirem e implantarem um programa de recompensa nas organizaes de software? Por fim, a quarta parte foi composta por duas perguntas relacionadas diretamente com o uso de indicadores como parte de um programa de recompensa em organizaes de software: Questo 9: Se as pessoas envolvidas durante a venda de um projeto de desenvolvimento de software forem as mesmas que iro participar da sua execuo, as estimativas de prazo e custo sero influenciadas, caso essas pessoas sejam submetidas a um programa de recompensa (ex.: contrato de resultados), ao longo da execuo do projeto? Questo 10: O uso de indicadores em projetos de desenvolvimento de software como parte do processo de avaliao das pessoas (ex.: contrato de resultados), alteram o comportamento delas para que esses indicadores sejam atingidos? Com exceo das questes 1 e 6, as demais possuam cinco opes de resposta: discordo plenamente, discordo, no concordo nem discordo, concordo, concordo plenamente. A questo 6 possua duas opes de respostas: sim e no. Cada pergunta foi formulada com a finalidade de validar alguns objetivos gerais, relacionados com o trabalho, e outros objetivos mais especficos, para validar alguns guidelines. A Tabela 5.1 descreve o relacionamento entre o objetivo que se desejava validar, a pergunta realizada na pesquisa de campo e o guideline relacionado.

96

Tabela 5.1 Relacionamento entre a pesquisa de campo e os guidelines. Objetivo da pesquisa Validar a relevncia geral do trabalho, ou seja, se existe alguma relao entre sistemas de recompensa e o aumento da produtividade, em organizaes que desenvolvem software. Validar se h relevncia em propor uma lista de recomendaes para orientar os gestores na definio e implantao de um sistema de recompensa, em organizaes que desenvolvem software. Avaliar o impacto do uso de indicadores em projetos de desenvolvimento de software para mensurar a produtividade das equipes e definir o sucesso de um projeto. Avaliar o impacto no comportamento das pessoas que so submetidas a um sistema de medio. Questo 5e6
12

Guideline -

13

7e8

2, 3 e 4

4.3, 4.5, 4.7 e 4.8 4.4

9 e 10

Com o objetivo de validar o entendimento do questionrio, uma primeira verso das perguntas foi enviada para dez pessoas, sendo duas consultoras de recursos humanos, especializadas em gesto de pessoas e planos de remunerao, e oito gerentes de projetos e lderes de equipe de uma empresa de desenvolvimento de software. Com base no entendimento do questionrio por essas pessoas, algumas sugestes de melhoria foram propostas para deixar o questionrio mais claro e objetivo. Apenas depois dessa validao inicial, a pesquisa de campo foi iniciada. O questionrio foi disponibilizado na web atravs da ferramenta Survey Monkey14 e foi divulgado atravs de listas de discusso que poderiam ter interesse pelo tema, alm de ferramentas de redes sociais e por demais grupos de pesquisas relacionados.

12

A questo nmero 1 (um) no est relacionada com nenhum objetivo, visto que era apenas

para identificar as caractersticas do participante e de sua empresa.

13

Os guidelines 4.1, 4.2 e 4.6 no foram validados diretamente pela pesquisa de campo. A

motivao para a definio deles foi a observao realizada numa organizao e o embasamento literrio, descrito no Captulo 3.
14

Ferramenta de pesquisa Survey Monkey: http://www.surveymonkey.com.

97

Durante 10 dias, em junho de 2009, 106 pessoas responderam o questionrio, porm, aps uma anlise dos dados, 15 respostas foram descartadas por estarem incompletas ou pelo fato de a empresa no fazer parte do pblico alvo desejado. Portanto, foram consideradas 91 respostas. A anlise do perfil das empresas e o resultado consolidado das questes esto descritas na Seo 5.2. 5.2 Anlise dos Dados

5.2.1 Anlise do Perfil das Empresas e dos Entrevistados As empresas brasileiras consideradas nesta pesquisa foram categorizadas pela localizao geogrfica, tempo de mercado e tamanho. Alm disso, tambm foi analisada a funo atual exercida pelo respondente. Apesar de o principal pblicoalvo ser gerentes de projetos de desenvolvimento de software, tambm foram consideradas algumas pessoas com perfil gerencial da rea de recursos humanos, vendas, engenheiros de software com perfil de liderana de equipe e liderana tcnica, analistas de negcios e engenheiros de qualidade. Para efeito de anlise, essas pessoas foram divididas em dois grupos: gerencial e tcnico. Todos aqueles que possuam alguma relao de liderana, foram considerados no primeiro grupo. Dentre as 91 pessoas, 74,7% possuam perfil gerencial, enquanto que 25,3% possuam perfil tcnico (Figura 5.1). Dentre os participantes que optaram por se identificar, pode-se afirmar que, no mnimo h 34 diferentes empresas, entre pblicas e privadas, avaliadas nessa amostra.

Figura 5.1 Perfil dos participantes pesquisados.

98

Conforme mostra a Figura 5.2, a maioria das empresas entrevistadas da regio Nordeste, seguida do Sudeste e Centro-Oeste. Na regio Nordeste, a maior quantidade foi do estado de Pernambuco (95,9%), seguido do Cear (2,7%) e Alagoas (1,4%). Na regio Sudeste, a maioria foi do estado do Rio de Janeiro (54,5%), seguido de So Paulo (36,4%) e Minas Gerais (9,1%). Por fim, na regio Centro-Oeste, a distribuio ficou da seguinte forma: Distrito Federal (66,7%), Mato Grosso (16,7%) e Tocantins (16,7%).

Figura 5.2 Localizao das empresas por regio geogrfica.

A Figura 5.3 mostra o tempo de mercado das empresas dos respondentes. A maioria possui um tempo mdio de mercado entre 11 e 30 anos (61,5%). Em seguida, aparecem as empresas com at 10 anos de mercado. Por ltimo, as empresas com mais de 30 anos de existncia.

99

Figura 5.3 Tempo de mercado das empresas.

Com relao ao tamanho da empresa, medido em funo da quantidade de profissionais envolvidos com a gesto e o desenvolvimento de software, a Figura 5.4 mostra que a maioria dos respondentes trabalha em empresas com tamanho mdio (50,5%), entre 101 e 500 pessoas. Em seguida, aparecem as empresas pequenas (37,4%), com at 100 pessoas, e, por fim, as empresas grandes (12,1%), com mais de 500 pessoas envolvidas diretamente com a gesto e o desenvolvimento de software.

Figura 5.4 Tamanho das empresas.

100

Com base nesta anlise, conclui-se que as caractersticas predominantes dos entrevistados so: Perfil dos entrevistados: gerencial; Regio geogrfica: Nordeste; Tempo de mercado: 11 a 30 anos; Quantidade de pessoas envolvidas com gesto ou desenvolvimento de software: 101 a 500 pessoas. 5.2.2 Anlise da Pesquisa em Campo Essa seo ir reportar a anlise realizada para cada objetivo descrito na Tabela 5.1. O primeiro objetivo foi definido para validar a relevncia geral do trabalho, ou seja, se existe alguma relao entre sistemas de recompensa e o aumento da produtividade em organizaes que desenvolvem software. Para valid-lo, foram formuladas as questes 5 e 6. A Figura 5.5 mostra que 83,6% dos pesquisados concordam ou concordam plenamente que os programas de recompensa so teis para melhorar a produtividade das pessoas que trabalham com projetos de desenvolvimento de software. Apenas 4,4% discordam ou discordam plenamente. Os demais (12,1%) no concordam nem discordam.

101

C oncordo plenamente

44,0%

C oncordo N concordo nem o discordo D iscordo 3,3% 12,1%

39,6%

D iscordo plenamente

1,1%

Figura 5.5 Consolidao da 5 questo da pesquisa de campo.

A Figura 5.6 mostra que 52,7% dos entrevistados trabalham em uma empresa de desenvolvimento de software que possui um programa de recompensa implantado, ou seja, a maioria conhece ou participa de um programa desse tipo. Para citar alguns exemplos de programas de recompensa relatados pelos participantes, temos: participao nos lucros e resultados, premiao por desempenho individual, elogios por escrito, reconhecimento pblico, promoo para cargos de confiana, remunerao varivel, viagem, jornal interno com a foto da equipe que participou do projeto etc.

Figura 5.6 Consolidao da 6 questo da pesquisa de campo.

Com base nesses resultados, h fortes indcios de que o primeiro objetivo vlido, pois a grande maioria (83,6%) concorda com a relao entre programas de

102

recompensa e aumento de produtividade e a maioria trabalha em uma empresa que possui um programa implantado. E mesmo aqueles que no trabalham em uma empresa que tenha o programa implantado, 88,4% tambm concordam com esta relao. Alm disso, dentre os 83,6% dos participantes que concordaram, houve alguns comentrios que corroboram esse resultado. Por exemplo: ... programas bem estruturados (de prmios e remunerao varivel) podem ser a mola impulsionadora da produtividade. Programas de reconhecimento, embora os fatos sejam pontuais, so de fundamental importncia na motivao e conseqente produtividade. O segundo objetivo foi validar se h relevncia em propor uma lista de recomendaes, para orientar os gestores na definio e implantao de um sistema de recompensa, em organizaes que desenvolvem software. Para valid-lo, foram formuladas as questes 7 e 8. A Figura 5.7 mostra, que, apenas 18,8% dos entrevistados concordam ou concordam plenamente que o programa de recompensa existente foi implantado de forma adequada, sendo que todos eles so pessoas com perfil gerencial. Quase 40% discordam ou discordam plenamente. E 41,7% no concordam nem discordam. Desse ltimo grupo, muitos registraram que no conhecem muito bem o programa para coment-lo, apenas sabem que existe.

C oncordo plenam ente

4,2%

C oncordo N concordo nem o discordo D iscordo

14,6% 41,7%

35,4%

D iscordo plenam ente

4,2%

Figura 5.7 Consolidao da 7 questo da pesquisa de campo.

103

A Figura 5.8 mostra que 86,9% dos entrevistados concordam ou concordam plenamente que importante existir uma lista de recomendaes sobre como orientar os gestores a definirem e implantarem um programa de recompensa nas organizaes de software. Apenas 4,4% discordam ou discordam plenamente. E 8,8% no concordam nem discordam.

C oncordo plenamente

47,3%

C oncordo N concordo nem o discordo D iscordo 2,2% 8,8%

39,6%

D iscordo plenamente

2,2%

Figura 5.8 Consolidao da 8 questo da pesquisa de campo.

Com base nesses resultados, h fortes indcios de que o segundo objetivo pode ser vlido, visto que a minoria dos entrevistados (18,8%) concorda que o programa de recompensa foi implantado de forma adequada e a maioria (86,9%) concorda que importante existir uma lista de recomendaes para apoiar os gestores na definio e implantao de um programa de recompensa. Alm disso, dentre os 86,9% dos participantes que concordaram, houve alguns comentrios que corroboram esse resultado. Por exemplo: ... independente da constituio da organizao, os gestores de qualquer instituio precisam de orientao. Na indstria de software o fator se agrava por conta da formao (predominantemente tcnica) dos profissionais que no contemplam tal informao. O terceiro objetivo foi definido para avaliar o impacto do uso de indicadores em projetos de desenvolvimento de software para mensurar a produtividade das

104

equipes e definir o sucesso de um projeto. Esse objetivo contempla a validao dos guidelines 4.3, 4.5, 4.7 e 4.8. Para isto foram definidas as questes 2, 3 e 4. A Figura 5.9 mostra que 66% dos entrevistados discordam ou discordam plenamente da possibilidade de definir os mesmos indicadores padres para todo tipo de projeto, com o objetivo de avaliar a produtividade de uma equipe. Apenas 26,4% concordam ou concordam plenamente e 7,7% no concordam nem discordam. Esse resultado um indicativo da validade do guideline 4.7 referente definio dos indicadores de performance. Alm disso, dentre os 66% que discordaram, houve alguns comentrios que corroboram esse resultado. Por exemplo: ... a produtividade de desenvolvimento pode depender do grau de inovao do projeto, que diferente da produtividade de um projeto tipicamente desenvolvido em uma fbrica de software... dependendo do projeto e metas a serem alcanadas, os indicadores precisam mudar. Os indicadores dependem muito da estratgia da empresa.

C oncordo plenam ente

5,5%

C oncordo N concordo nem o discordo D iscordo 7,7%

20,9%

49,5%

D iscordo plenam ente

16,5%

Figura 5.9 Consolidao da 2 questo da pesquisa de campo.

A Figura 5.10 mostra que 70,3% dos entrevistados concordam ou concordam plenamente que possvel avaliar o sucesso do projeto com base em dimenses diferentes das tradicionais: custo, escopo, prazo e qualidade. 19,8% discordam ou discordam plenamente. E apenas 9,9% no concordam nem discordam. Esse resultado mostra que h fortes indcios da validade do guideline 4.5, referente

105

definio do sucesso do projeto. Alm disso, dentre os 70,3% que concordaram, houve alguns comentrios que corroboram esse resultado. Por exemplo: ... ROI, benefcio social atingido, a renovao do contrato com o cliente, a rotatividade da equipe, valor agregado ao negcio... o sucesso de um projeto deveria estar associado ao cumprimento do objetivo do projeto, mesmo que ele seja ajustado com o tempo. Definir claramente esse objetivo o ponto mais importante para o alcance do sucesso.

C oncordo plenamente

16,5%

C oncordo N concordo nem o discordo D iscordo 9,9%

53,8%

18,7%

D iscordo plenamente

1,1%

Figura 5.10 Consolidao da 3 questo da pesquisa de campo.

A Figura 5.11 mostra que 86,8% concordam ou concordam plenamente que importante que cada organizao defina os fatores que podem influenciar na produtividade das equipes e categorizar os projetos para efeito de comparao. Apenas 5,5% discordam e 7,7% nem concordam nem discordam. Esse resultado um forte indcio da validade do guideline 4.3, referente definio de baselines de comparao para mtricas de produtividade.

106

C oncordo plenamente

27,5%

C oncordo N concordo nem o discordo D iscordo 7,7%

59,3%

5,5%

D iscordo plenamente 0,0%

Figura 5.11 Consolidao da 4 questo da pesquisa de campo.

Apesar de no existir uma pergunta especfica para validar o guideline 4.8, referente necessidade de um comit independente para avaliao dos resultados, os comentrios referentes s questes 2, 3 e 4 reforam essa necessidade, uma vez que todos so relacionados com o uso de indicadores para mensurar a produtividade das equipes ou definir o sucesso de um projeto. A seguir, alguns comentrios que corroboram esse guideline: ... o julgamento da comparao entre projetos sempre estar sujeito subjetividade... algumas vezes, gestores lem indicadores como verdades absolutas. Indicadores nunca devem substituir anlises subjetivas; ... deve haver tambm um mecanismo de verificao independente, que verifique se o programa est sendo aplicado corretamente. O quarto objetivo foi definido para avaliar o impacto no comportamento das pessoas que esto submetidas a um sistema de medio. Esse objetivo contempla a validao do guideline 4.4. Para valid-lo foram definidas as questes 9 e 10. A Figura 5.12 mostra que 72,6% dos entrevistados concordam ou concordam plenamente que as pessoas envolvidas durante a venda de um projeto podem influenciar as estimativas de prazo e custo, caso elas sejam submetidas a um programa de recompensa, ao longo da execuo do projeto. Apenas 13,2% discordam ou discordam plenamente e 14,3% no concordam nem discordam. Esse resultado mostra que h fortes indcios da validade do guideline 4.4, referente

107

identificao dos participantes da venda de um projeto. Alm disso, alguns comentrios tambm corroboram esse guideline, por exemplo: ... deve-se reforar a responsabilidade das estimativas e custos no processo de venda do projeto, para que os mesmos no sejam influenciados por fatores como programas de recompensa ou com limites oramentrios impostos pelo cliente. Quanto mais maduros os profissionais envolvidos no processo de estimativas, menor o risco de haver influncias negativas neste processo.

C oncordo plenam ente

23,1%

C oncordo N concordo nem o discordo Discordo 9,9% 14,3%

49,5%

D iscordo plenam ente

3,3%

Figura 5.12 Consolidao da 9 questo da pesquisa de campo.

A Figura 5.13 mostra que mais de 90% dos entrevistados concordam ou concordam plenamente que o uso de indicadores como parte do processo de avaliao das pessoas, altera o comportamento delas para que esses indicadores sejam atingidos. Apenas 2,2% discordam e 4,4% nem concordam nem discordam. Esse resultado um forte indcio de que as organizaes devem se preocupar com a implantao de seus sistemas de medio, principalmente no momento de atrello a um sistema de recompensa, com o principal objetivo de minimizar o efeito da disfuno. Alm disso, alguns comentrios tambm corroboram esse cenrio, por exemplo: ... tem um risco envolvido porque as pessoas vo orientar seu trabalho apenas para cumprir seu contrato, deixando, muitas vezes o bom senso de lado.

108

C oncordo plenamente

23,1%

C oncordo No concordo nem discordo D iscordo 4,4%

70,3%

2,2%

D iscordo plenamente 0,0%

Figura 5.13 Consolidao da 10 questo da pesquisa de campo.

5.3

Correlao entre as Questes e as Caractersticas das Empresas Em seguida, foi analisada se h alguma correlao entre as respostas

fornecidas e o perfil das empresas e dos entrevistados. Apenas a stima questo apresentou uma forte correlao entre o perfil do entrevistado com a quantidade de respostas que concordam ou concordam plenamente que o programa de recompensa existente foi implantado de forma adequada. Todos que concordam so pessoas do perfil gerencial. Isto pode ser um indicativo de que as pessoas com perfil tcnico podem no ter sido beneficiadas ou envolvidas com o programa de recompensa existente. Ainda sobre essa mesma questo, quase 42% nem concordam e nem discordam que o programa foi implantado de forma adequada, e muitos registraram que no conhecem muito bem o programa para coment-lo. Uma possvel concluso que a boa comunicao importante na implantao desse tipo de programa. Alm dessa questo, nenhuma outra apresentou uma forte correlao entre as respostas e as caractersticas das empresas e dos entrevistados, em relao ao tamanho da empresa, tempo de mercado e regio geogrfica.

109

5.4

Limitaes da Pesquisa Esta pesquisa apresenta algumas limitaes, as quais sero descritas, a

seguir: No foi possvel aplicar diretamente os guidelines propostos em uma organizao. Apesar de alguns guidelines serem fruto de observao em uma organizao, o ideal seria aplic-los em alguma outra organizao ou aplicar os novos na organizao observada. Porm, a aplicao desses guidelines requer uma iniciativa da alta direo e impacta no dia-a-dia da empresa. No foi possvel encontrar uma organizao que estivesse disponvel para aplic-los no tempo desejado, para a concluso do presente trabalho; Este trabalho no considerou a medio da produtividade, antes ou depois da aplicao do guideline, para afirmar qual o percentual de aumento de produtividade que a adoo do guideline possibilitaria. As concluses descritas foram todas baseadas na reviso literria, na observao de uma organizao e na pesquisa de campo em vrias empresas brasileiras; Em relao aos resultados da pesquisa de campo aqui apresentados, todos eles consideram a caracterstica da empresa na qual trabalha o funcionrio que respondeu a pesquisa. Isto quer dizer que os percentuais no so em relao quantidade de empresas, mas, sim, em relao quantidade de funcionrios das empresas. Sabe-se que, pelo menos, 34 empresas foram contempladas nessa amostra. 5.5 Consideraes Finais Este captulo apresentou a forma como os oito guidelines propostos foram validados. Os dois instrumentos utilizados foram a observao e a pesquisa de campo, atravs de um questionrio. A pesquisa foi realizada em vrios estados do Brasil, mas a predominncia foi a regio Nordeste, mais especificamente, o Estado de Pernambuco.

110

Todos guidelines puderam ser analisados e possuem fortes indcios de serem vlidos, considerando o escopo das empresas pesquisadas. A Figura 5.14 ilustra a consolidao das respostas.
100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Q2 Q3 Q4 Q5 Q7 Q8 Q9 Q10 Concordo plenamente Concordo N concordo nem discordo o Discordo Discordo plenamente

Figura 5.14 Consolidao em cinco nveis das oito questes da pesquisa de campo que possuem a mesma escala das opes de respostas .
15

A Figura 5.15 representa os mesmos dados da figura anterior, porm agrupando as respostas em apenas trs escalas: concordo e concordo plenamente; no concordo nem discordo; discordo e discordo plenamente.
100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Q 2 Q 3 Q 4 Q 5 Q 7 Q 8 Q 9 Q 10 C oncordo/C oncordo Plenamente N concordo nem discordo o D iscordo/D iscordo plenamente

Figura 5.15 Consolidao em trs nveis das oito questes da pesquisa de campo que possuem a mesma escala das opes de respostas.

15

As perguntas 1 e 6 no se aplicam neste grfico.

111

Para validar os objetivos listados na Tabela 5.1, esperava-se que a concentrao das concordncias fosse nas questes 3, 4, 5, 8, 9 e 10; e que a concentrao das discordncias fossem nas questes 2 e 7. Neste ultimo grfico possvel perceber esses agrupamentos. Diante dos resultados apresentados, pode-se afirmar que os quatro objetivos apresentados na Tabela 5.1 foram analisados e que h indcios de que a adoo dos oito guidelines podem ser efetivos para que uma organizao de desenvolvimento de software alcance maiores ndices de produtividade. Por fim, importante ressaltar que esta pesquisa no considerou a aplicao dos guidelines em conjunto com outras estratgias de melhoria de produtividade. Isso quer dizer que a sua adoo isolada pode no ser suficiente, sendo necessria a aplicao de outras estratgias j conhecidas, como, por exemplo, implantao de ferramentas para automatizar o processo de desenvolvimento de software, reuso de artefatos, melhoria da qualidade do gerenciamento dos times, entre outros.

112

CONCLUSES E TRABALHOS FUTUROS

O processo de medio da performance tem recebido uma grande ateno

devido preocupao das organizaes em aumentarem a produtividade das equipes. Vrias metodologias, modelos e ferramentas so utilizadas para criao de sistemas de medio: Balanced Scorecard, Goal-Question-Metric, Practical Software & Systems Measurement, Capability Maturity Model Integration, entre outros. Nesse contexto, vrias estratgias podem ser definidas para aumento de produtividade. Uma delas atravs do uso dos indicadores presentes em um programa de medio como forma de definir um sistema de recompensa que estimule a motivao das equipes atravs de compensaes. Os mecanismos de recompensas visam a fortalecer os comportamentos que devem ser repetidos. Ou seja, o alcance de metas de produtividade e de qualidade poder ser recompensado com bnus ou algum tipo de prmio extra, com a finalidade de mostrar para o indivduo, e aos demais participantes, quais so os comportamentos e metas esperadas. Em geral, esses sistemas tm a inteno de atrair, reter e motivar as pessoas. Porm, para que uma pessoa esteja motivada, ela precisa dar valor ao resultado, precisa acreditar que um esforo adicional a levar a um desempenho melhor e que o desempenho melhor, subseqentemente, resultar em recompensa ou resultados maiores. As recompensas financeiras so um componente importante do sistema de recompensa, mas existem outros fatores que estimulam a motivao dos empregados e influenciam seus desempenhos. Na verdade, vrios estudos relatam que as formas financeiras nem sempre so as mais indicadas. Para garantir um efetivo sistema de recompensa que leve ao comportamento desejado, essencial considerar cuidadosamente as vantagens e as estratgias utilizadas e garantir que as recompensas esto baseadas em desempenho.

113

Incentivar e compensar o desempenho devem ser uma atividade gerencial constante, e no apenas um ritual de remunerao anual. Os sistemas de recompensas, quando devidamente implantados, tm mostrado ser uma ferramenta importante para o alcance das metas organizacionais. Manter os planos simples de serem seguidos, medidos, compreendidos e administrados essencial para aumentar a performance desejada. Porm, nem sempre esses programas so definidos e implantados de forma efetiva. Um ponto relevante ressaltado nos sistemas de medio so os aspectos sociais e psicolgicos. Quando a inteno da medio voltada para motivar as pessoas, elas tendem a mudar o comportamento em funo daquilo que est sendo observado e medido. Isso faz com que o esforo das equipes sejam direcionadas apenas s dimenses mensuradas pela organizao. E, quando essas dimenses no so corretamente identificadas, leva ao problema da disfuno. Alm disso, precisa ser considerado o custo da medio. As atividades de identificao, coleta, anlise e divulgao dos indicadores podem representar um custo alto organizao para que os indicadores relevantes sejam, de fato, considerados no sistema de medio. H um grande desafio em analisar o trade-off entre: a relevncia do indicador coletado, o custo associado em todo o ciclo da medio, os benefcios que ele trar no processo de tomada de deciso organizacional e o aumento do desempenho das equipes. Com o objetivo de explorar mais essa estratgia de melhoria de performance organizacional, este trabalho forneceu um conjunto de recomendaes, em forma de guidelines, que podem orientar os gestores a definirem e implantarem um programa de recompensa numa organizao de desenvolvimento de software. Alm disso, tambm foram abordados os impactos negativos que esses programas podem causar na produtividade das equipes quando so mal aplicados. A definio dos guidelines considerou aspectos relacionados com o indivduo, como, por exemplo, questes ligadas s teorias motivacionais. Tambm foram sugeridas algumas recomendaes sobre como minimizar o impacto da medio com inteno motivacional, ou seja, quela utilizada para recompensar as pessoas e

114

em relao s mudanas de comportamento dos envolvidos em todo o processo da medio. Alm disso, as recomendaes englobaram os fatores relacionados com a correta definio dos contratos de resultados das equipes, os cuidados na comparao dos indicadores entre projetos de naturezas distintas, o significado do sucesso do projeto e o impacto da forma de gerenciamento das equipes para a identificao e acompanhamento dos indicadores relevantes. Em paralelo, acompanhando todas essas recomendaes, foi prevista a definio de um comit independente que possa atuar na reavaliao e calibrao em vrios pontos do programa de recompensa, visto que, em alguns momentos, anlises subjetivas podero ser necessrias, desde que alguns cuidados sejam observados. A adoo dos guidelines pode ser realizada em conjunto ou por partes. Essa deciso pode ser tomada, por exemplo, em funo do escopo da organizao que se pretende alcanar (processos organizacionais, processos de venda ou processos relacionados com a execuo de um projeto). Os relacionamentos entre os guidelines podem ser utilizados para apoiar esse tipo de deciso. Por fim, como todo conjunto de guidelines, apenas a adoo isolada das recomendaes aqui apresentadas, no garante o aumento de produtividade das organizaes, mas a pesquisa realizada em campo oferece indcios que isso possvel. Entretanto, necessrio que sejam consideradas outras estratgias de aumento de produtividade que possam ser combinadas com essa proposta. Alm disso, fundamental que esses guidelines sejam adaptados cultura da organizao e que seja possvel o apoio da alta administrao na sua adoo e utilizao efetiva. 6.1 Trabalhos Futuros Foram identificadas as seguintes possibilidades de trabalhos futuros: Definio do escopo de uma organizao em que seja possvel medir a produtividade das equipes antes e depois da aplicao dos guidelines propostos.

115

No fez parte do escopo deste trabalho realizar medies sobre a produtividade de uma equipe ou de parte da organizao. Isto importante para que o resultado da aplicao dos guidelines possa ser medida de forma objetiva. Uma proposta de trabalho futuro definir qual o escopo de uma organizao que poderia ter sua produtividade medida, realizar a medio antes da aplicao dos guidelines, realizar a medio aps a aplicao dos guidelines e, por fim, mensurar o ganho quantitativo desta proposta. Vrios desafios fazem parte deste trabalho, por exemplo, definir quais sero as mtricas de produtividade possveis de medir, com baixo custo e que represente valor para a organizao. Alm disso, isolar as variveis antes e depois da medio para poder avaliar se de fato foi a adoo dos guidelines responsveis pelo ganho na produtividade. Definio de um processo de implantao de sistemas de

recompensa em organizaes de software. No fez parte do escopo deste trabalho definir todos os ativos de um processo para apoiar as organizaes na adoo dos guidelines. Para isto, seria necessrio definir, por exemplo, fases, atividades, fluxo entre as atividades, papis e responsabilidade, artefatos e critrios de entrada e sada, entre outros. Definio de uma ferramenta que possa auxiliar a organizao na implantao e acompanhamento de um programa de recompensa. Para que a adoo das recomendaes de um sistema de recompensa seja feita de forma mais efetiva, sugere-se a definio de uma ferramenta que oriente organizao durante todo o processo de implantao. Por exemplo: definir o escopo dos guidelines que sero adotados, as reas da empresa que sero afetadas, os percentuais de completude de cada guideline, os relacionamentos entre eles, entre outros.

116

REFERNCIAS
AGUIAR, M. A Produtividade dos Projetos de Desenvolvimento, Developers Magazine, Fevereiro, 2003. p. 41. AQUINO, G, S., FURTADO, F., ALCHORNE, R., SAMPAIO, S., MEIRA, S. R. L. Disfuno dos Sistemas de Medio em Organizaes de Software. XII Conferncia de Engenharia de Requisitos e Ambientes de Software Medelln, Colmbia, 13-17/Abril 2009. IDEAS 2009. AQUINO, G, S., MEIRA, S. R. L. An Approach to Measure Value-Based Productivity in Software Projects. 9th International Conference on Quality Software Jeju, Korea, August 24-25, 2009b. QSIC 2009. ANETIE. Incentivos so prticas comuns em TI. Disponvel Acessado em: em:

http://www.semanainformatica.xl.pt/688/emp/100.shtml, 23/02/2009.

2004.

AUSTIN, R. D. Measuring and Managing Performance in Organizations. New York, USA: Dorset House Publishing, 1996. BACCARINI, D. The logical framework method for defining project success. Project Management Journal, 1999. pp. 25-32. BAKER, G., GIBBONS, R., MURPHY, K., J. Subjective Performance Measures in Optimal Incentive Contracts. The Quarterly Journal of Economics. February, 1994. BAKER, A. L., BIEMAN, J. M., FENTON, N., GUSTAFSON, D. A., MELTON, A., WHITTY, R., A. Philosophy for Software Measurement. J. Systems and Software, 12, p. 277 - 281, 1990. BASILI, V. R., CALDIERA, G., ROMBACJ, H. D. The Goal Question Metric Approach. 2nd ed., Wiley-Interscience, Encyclopedia of Software Engineering, 2001. p. 528-532.

117

BEHRENS,

C.

A.

Measuring

the

Productivity

of

Computer

Systems

Development Activities with Function Points. IEEE Trans. Softw. Eng. v. 9, n 6, nov. 1983. p. 648-652. BELCHER, D. W. Compensation administration. New Jersey: Prentice Hall, 1974. BERNTHAL, P. Measurement Gets Strategic, T+D Magazine, (53-56), May 2005. p. 54. BOEHM, B. W., ELWELL, J. F., PYSTER, A. B., STUCKLE, E. D., e WILLIAMS, R. D. The TRW Software Productivity System. In Proceedings of the 6th international Conference on Software Engineering (Tokyo, Japan, September 13 - 16, 1982). International Conference on Software Engineering. IEEE Computer Society Press, Los Alamitos, CA. p. 148-156. BOEHM, B. W. Managing Software Productivity and Reuse. Computer, v. 32, n 9, sep. 1999. p. 111-113. BOEHM, B. W. Software engineering economics, Advances in Computing Science and Technology Series, Prentice-Hall, Prentice-Hall, Englewood Cliffs, 1981. BOSE, R. Knowledge management metrics. Industrial Management & Data Systems, v. 104, n. 6, 2004. p. 457-468, 2004. BOWLES, S. Quando os incentivos econmicos atrapalham. Harvard Business Review, Maro, 2009. BRAGA, R. T. V., GERMANO, F. S. R., MASIERO, P. C., MALDONADO, J. C. Introduo aos Padres de Software. So Carlos: Universidade de So Paulo, 2001. BRUCKHAUS, T., MADHAVJI, N. H., JANSSEN, I., HENSHAW, J. The Impact of Tools on Software Productivity. IEEE Softw. v. 13, n 5, sep. 1996. p. 29-38. BRUIJN, H. Managing Performance in the Public Sector. London: Routledge, 2002.

118

BRUNS, W. J. Performance Measurement, Evaluation, and Incentives. Harvard Business School Press. 1992. CAIN, J. W., McCRINDLE, R. J. An Investigation into the Effects of Code Coupling on Team Dynamics and Productivity. In Proceedings of the 26th international Computer Software and Applications Conference on Prolonging Software Life: Development and Redevelopment COMPSAC. IEEE Computer Society, Washington, DC. 2002. p. 907-913. CAMPBELL, D. J., CAMPBELL, K. M., CHIA, H. Merit pay, performance appraisal, and individual motivation: An analysis and alternative. Department of Organizational Behavior, National University of Singapore, 1998. CAUDRON, S. Master the compesation maze. Personnal Journal, June 1993. p. 64b-64o. CERIELLO, V. R., FREEMAN, C. Human Resource management sytems: strategies, tactics and techniques. New York: Lexington Books, 1991. CLINCY, V. A. Software Development Productivity and Cycle Reduction. CCSC Eastern Conference - Consortium for Computing Sciences in Colleges. Dezembro, 2003. CROWSTON, K., ANNABI, H., HOWISON, J. Defining Open Source Software Project Success. NY, USA: School of Information Studies Syracuse University Syracuse, 2003. CYRINEY, J. C. T. Gesto do Conhecimento: o grande desafio empresarial. Disponvel em: http://www.terraforum.com.br, 2008. Acessado em 23/02/2009. DAVIES, T. Consistently doing the right projects and doing them right: What metrics do you need? Journal of the Australian Institute of Project Management, March 2004. p. 6-8. DEEPROSE, D. How to Recognize & Reward Employees: 150 Ways to Inspire Peak Performance. Second Edition, AMACOM, 2006.

119

DEKKERS, A., C. Unleash the power to improve. Software Quality Professional, 2000. p. 48-51. Disponvel em: http://www.asq.org/pub/sqp/past/vol3_issue1/. Acessado em: 23/02/2009. DEMARCO, T. Peopleware: productive projects and teams, 2nd Ed. Dorset House Publishing, 1999. DEMARCO, T. Controlling Software Projects - Management, Measurement & Estimates. Yourdon Press Series, 1982. DEMARCO, T. Software Engineering: An Idea Whose Time Has Come and Gone? IEEE Software Magazine, July/August 2009. DEMING, W. E. Out of the crisis. Cambridge, MA: MIT Center for Advanced Engineering Study, 1986. p. 88. DRUCKER, P. The Essential Drucker. Harper Business, 2001. DUTRA, J. S. Competncias, Conceitos e Instrumentos para a Gesto de Pessoas na Empresa Moderna. So Paulo: Atlas, 2004. ECCLES, R. G. The Performance Management Manifesto. Harvard Business Review, January, 1991. p. 131-137. FENTON, N., PFLEEGER, S, L. Software metrics: a rigorous & practical approach. PWS Publishing Company, Second Edition, 1997. 638 p. ISBN: 0-534954225-1. FENTON, S., KITCHENHAM, N., PEEGER, B.. Towards a framework for software measurement validation. In IEEE Transactions on Software Engineering. December 1995, v. 21 n 12, December, 1995, IEEE Press, 1995. p. 929-943. FINNOCCHIO, J. A gesto por projetos para servios de tecnologia da informao. Mundo Project Management, novembro, 2005. p. 78 a 81. FISCHER, A. L. O conceito de modelo de gesto de pessoas. In: S. J. Dutra (Org.). Gesto por Competncia. So Paulo: Gente, 2001.

120

FLAMHOLTZ, E. G. Toward a Psycho-Technical Systems Paradigm of Organizational Measurement. Decision Sciences, 1979. FLANERY, T. P., HOFRICHTEE, D., PLATTEN, P. E. Tecnologias de gesto: alinhando remunerao estratgia de mudanas e cultura das organizaes. ERA Light, v. 3, n 1, Jan/Mar 1996. p. 22-27. FRANA, A. C, L. et al. As Pessoas na Organizao. So Paulo: Gente, 2002. FURTADO, F. AQUINO, G., MEIRA, S. Incentive Systems in Software Organizations. In: ICSEA 2009 - The Fourth International Conference on Software Engineering Advances. Porto, Portugal. 20-25/Setembro, 2009a. FURTADO, F. AQUINO, G., MEIRA, S. Reward Systems as a Productivity Improvement Strategy in Information Technology Environments. In: SETP 2009 - International Conference on Software Engineering Theory and Practice. Orlando, FL, EUA. 13-16/Julho, 2009b. GIBBS, M., MERCHANT, K. A., STEDE, W. A., VARGUS, M. E. Determinants and Effects of Subjectivity in Incentives. University of Southern California, Marshall School of Business Research, 2004. HIPLITO, J. A. M. Administrao Salarial. A recompensa por Competncias como Diferencial Competitivo. So Paulo: Atlas, 2006. HOLMSTROM, B. On Incentives and Control in Organizations. Ph.D. Thesis, Stanford University, 1977. HOLMSTROM, B., MILGROM. Multitask Principal-Agent Analysis: Incentive Contracts, Asset Ownership, and Job Design. Journal of Law, Economics, and Organizations, Vol. 7, Spring 1991. p. 24-52. HUMPHREY, W. S. Managing for Innovation: Leading Technical People. Englewood Cliffs, NJ: Prenctice Hall, 1987. IEEE COMPUTER SOCIETY. IEEE Standard Glossary of Software Engineering Terminology: IEEE STD 610.12-1990.

121

INGERSOLL, T. The Effect of Performance Based Incentive Plans. IEEE Advanced Manufacturing Conference, 1998. ISO/IEC 15939, 2007. Information Technology - Software Engineering - Software Measurement Process. International Organization for Standardization - ISO, Geneva. JACKSON, A. Falling from a Great Height: Principles of Good Practice in Performance Measurement and the Perils of Top Down Determination of Performance Indicators. Local Government Studies, UK; Vol. 31, No. 1, p. 21-38, Spring 2005. JACKSON, A. A classification of gaming, in: A. Neely and A. Walters (Eds.) Performance Measurement and Management: Research and Action (Cranfield: Centre for Business Performance), 2002. JONES, C., LAYMAN, B., CLARK, E., DEAN, J., HALL, F., MCGARY, J., CARD, D. Software Measurement: Key Concepts and Practices. Addison-Wesley Professional, 2001. KAPLAN, 23/02/2009. KAPLAN, S., HENDERSON, R. Inertia and Incentives: Bridging Organizational Economics and Organizational Theory. Organization Science v. 16, n 5, SeptemberOctober 2005. p. 509521. KITCHENHAM, B., MENDES, E. Software Productivity Measurement Using Multiple Size Measures, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, December, 2004. v. 30, n. 12. KOHN, A. Why Incentives Plans Cannot Work. Harvard Business Review, Setembro-Outubro, 1993. R. O valor intangvel das TIs. Disponvel em:

http://www.computerworld.com.pt/site/content/view/463/48/, 2005. Acessado em:

122

LAFFONT, J. MARTIMORT, D. The theory of incentives: the principal-agent model. Princeton, EUA: Princeton University Press, 2002. LARKEY, P., D., CAULKINS, J. All Above Average and other Unintended Consequences of Performance Appraisal Systems. The Maxwell School, Syracuse University, September, 1992. LAWLER, E. Strategic pay: aligning organizational strategies and pay systems. So Francisco: Jossey-Bass, 1990. MACLEAN, B. P. Value-added pay beats traditional merit programs. Personnel Journal, Sept. 1990. p. 46-52. MALTZ, E., KOHLI, A. K. Reducing Marketing's Conflict with Other Functions: The Differential Effects of Integrating Mechanisms. Journal of the Academy of Marketing Science v. 28, n.4, 2002. p. 479-492. MARCHANT, T. Strategies for improving individual performance and job satisfaction. Journal of Management Practice, v. 2, n 3, 1999. p. 63-70. MASLOW, A., H. A Theory of Human Motivation. Psychological Review. 50(4) (1943):370-96. MAXIMIANO, ANTNIO C. Teoria geral da administrao: da revoluo urbana revoluo digital. 4. ed. So Paulo: Atlas, 2004. MAXWELL, K. D., FORSELIUS, P. Benchmarking Software-Development Productivity. IEEE Software. v. 17, n 1, jan. 2000. p. 80-88. DOI= http://dx.doi.org/10.1109/52.820015. MAXWELL, K. D., WASSENHOVE, V. L., DUTTA, S. Software Development Productivity of European Space, Military, and Industrial Applications. IEEE Trans. Softw. Eng. v. 22, n 10, oct. 1996. p. 706-718. MENESES, J. B. Inspector: Um Processo de Avaliao de Progresso para Projetos de Software. Dissertao Centro de Informtica, Universidade Federal de Pernambuco, Recife, 2001.

123

MCGARRY, Card, Jones, Layman, Clark, Dean e Hall. Practical Software Measurement: Objective Information for Decision Makers. Addisson Wesley, 2002. MCCONELL, S. Software Estimation: Demystifying the Black Art. Redmond, Wa. Microsoft Press, 2006. MEYER, M. W. Rethinking Performance Measurement: Beyond the Balanced Scorecard. Cambridge: Cambridge University Press, 2002. MILGROM, P., ROBERTS, J. Economics, organization & management. New Jersey: Prentice Hall, 1992. MISHINA, O., INABA, M. The integrated wage and salary system: a guide to Japanese wage and a salary systems at present and for the future. Tquio: The institute of Labor Administration, 1985. NAUR, P., RANDELL, B. Software Engineering: Report of a conference sponsored by the NATO Science Committee. Garmisch, Germany, 7-11 Oct. 1968, Brussels, Scientific Affairs Division, NATO, 1969. NORTON, D., KAPLAN, R. The Balanced Scorecard. McGraw-Hill Ryerson Agency, 1996. OLIVEIRA, M. M. Como fazer projetos, relatrios, monografias, dissertaes e teses. 4 edio. Rio de Janeiro: Elsevier, 2008. PAPO, J. Qualidade interna e externa de um produto de software. Disponvel em: http://www.erudio.com.br/engenharia-de-software/qualidade-interna-e-externa-deum-produto-de-software-3.html, 2008. Acessado em: 23/02/2009. PFLEEGER, S. L. FENTON, N. E. Software Metrics: A Rigorous and Practical Approach. PWS Publishing, 1997. PMBOK Guide. A Guide to the Project Management Body of Knowledge. Third Edition, Project Management Institute. Four Campus Boulevard, Newton Square, PA 19073-3299 USA, 2004.

124

PRENDERGAST, C., TOPEL, R. Discretion and bias in performance evaluation. European Economic Review, v. 37. April, 1993. PRESSMAN, R. S. Engenharia de software. 6.ed. So Paulo: McGraw-Hill, 2006. 720 p. PSM. Practical Software and Systems Measurements (PSM) PSM Guide 4.0b1. Disponvel em http://www.psmsc.com, 2003. Acessado em: 23/02/2009. RAMALHO, N. C. O Fator humano na empresa: aspectos tcnicos, profissionais e gerenciais. Braslia: Universidade de Braslia, 1977. RIDGWAY, V. F. Dysfunctional Consequences of Performance Measurements. Administrative Science Quarterly, v. 1, n 2. Published by: Johnson Graduate School of Management, Cornell University, 1956. p. 240-247. ROBBINS, S. P. Comportamento organizacional. 8 edio, Rio de Janeiro: LTC, 1999. ROSS, S. A. The Economic Theory of Agency: The Principal's Problem. The American Economic Review, v. 63, n 2, 1973. p. 134-39. SANKAR, C. S., LEDBETTER, W. N., SNYDER, C. A., ROBERTS, T. L., MCCREARY, J., BOYLES, W. R. Perceptions of Reward Systems by Technologists and Managers in Information Technology Companies. IEEE Transactions on Engineering Management, v. 38, n 4, November, 1991. SCACCHI, W. Managing Software Engineering Projects: A social Analysis. IEEE Trans. Soft. Engr.,SE-10(1), 1984, 49-59. SCHERMERHORN, J, R., HUNT, J. G., OSBORN, R. N. Fundamentos de Comportamento Organizacional, 2a edio, Porto Alegre: Bookman, 1999. SEI (2006). CMMI for Development, version 1.2, staged representation. CMU/SEI-2006-

http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf, TR-008.

125

SHANG, S., Peter B. Assessing and managing the benefits of enterprise systems: the business manager's perspective, Information Systems Journal, October 2002. p. 271-299. SHARP, H. et al. Models of motivation in software engineering, Inform. Softw. Technol. (2008), doi:10.1016/j.infsof.2008.05.009. SHAWN, T. Your Paycheck Gets Exciting. Fortune, november, 1993. p. 83-98. SHLAES, C. Rewarding and Stimulating Creativity and Innovation in

Technologies Companies. IEEE Technology Management : the New International Language, 1991. p. 609-612. SHENHAR, A. J., RENIER, J. J. Improving PM: Linking Success Criteria to Project Type. Southern Alberta Chapter, Project Management Institute, Symposium Creating Canadian Advantage through Project Management, Calgary, May 2002. SOFTEX (2006), MPS.BR Melhoria de Processo do Software Brasileiro, Guia Geral (v. 1.1). Disponvel em: http://www.softex.br/mpsbr. SOMMERVILLE, I., SAWYER, P. Requeriments engineering a good pratice guide. Chichester: John Wiley, c1997. 391 p. ISBN 0471974447. SOMMERVILLE, I. Engenharia de software. 8.ed. So Paulo: Pearson Addison Wesley 2007. 552 p. ISBN 9788588639287. SPECTOR, P. E. Psicologia nas Organizaes, So Paulo: Saraiva, 2002. STAJKOVIC, A. D., LUTHANS, F. A meta-analysis of the effects of organizational behavior modification on task performance. Academy of Management Journal, 1997. STANDISH GROUP. The Chaos Report Standish Group. 2009. Disponvel em : http://www.standishgroup.com. Acessado em: 27/05/2009.

126

TANNER, F. R. On motivating engineers, in: Engineering Management Conference, 2003, IEMC 03, Managing Technologically Driven Organisations: The Human Side of Innovation and Change, 2003. p. 214218. THORNDIKE, E. L. Educated Psychology: the psychology of learning, Nova York, 1913. UNIMONTE. Organizaes que Aprendem. Disponvel em:

http://www.unimonteonline.com/equipe.asp, 2007. Acessado em: 23/02/2009. VERGARA, S.C. Gesto de pessoas. So Paulo: Atlas, 2000. VROOM, V. H., KENNETH, R. M. Toward a Stochastic Model of Managerial Careers. Administrative Science Quarterly 13 (1): 26-46. Junho, 1968. XAVIER, P. R., SILVA, M. O, NAKAHARA, J. M. Remunerao Varivel. Quando os resultados falam mais alto. So Paulo: Makron Books, 1999. WIEDMAN, R. M. Improving PM: Linking Success Criteria to Project Type. Disponvel em: http://www.maxwideman.com/papers/improvingpm/improvingpm.pdf. 1996. Acessado em: 23/02/2009. WILLARD, B. O sucesso de um projeto sob uma nova tica de mensurao. Mundo Project Management, julho, 2006. p. 38-45. YU, W. SMITH, D. HUANG, S. Software productivity measurements. Proceedings of Computer Software and Applications Conference, 1991. ZANELLI, J. C., ANDRADE, J. E. B., BASTOS, A. V. B. Psicologia, Organizaes e Trabalho no Brasil. Porto Alegre: Artmed, 2004. ZHUGE, J. Reward systems for Implementing Knowledge sharing in Knowledge - Intensive Corporation. In: ISECS - International Colloquium on Computing, Communication, Control and Management, 2008.

127

ZUSE, H., BOLLMANN, P. Software Metrics: Using Measurement Theory to Describe the Properties and Scales of Static Software Complexity Metrics. ACM SIGPLAN Notices, 24(8), p. 167-171, 1989.