01-woses-2009

V Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES

1

A Abordagem Sistmica na Gesto de Projetos de Software

Guilherme Carvalho1, Daniel Penaforte1, Hector Oliveira1, Daniel Julio1, Csar Delmas1, Hermano Perrelli1, Antnio Pereira1

1Centro de Informtica Universidade Federal de Pernambuco (UFPE) Caixa Postal: 7851, CEP: 50732-970, Recife PE Brasil

{ggc, dap4, hplo, dvsj, cadcn, hermano}@cin.ufpe.br, [email protected]

Abstract. By understanding how the various parties involved in the project are related and integrated, professionals anticipates consequences and evaluates problems and solutions more effectively. So, the application of systems thinking in projects environments promotes a holistic approach for greater understanding of the majority influences. Thus, the quality management must be related to all parties in a project and the manager is responsible for evaluating individuals, projects and organizational goals together as a whole. This article explains with practical examples how systems thinking impacts the decision-making before, during and after a project by allowing implicit assumptions identification, human factors incorporation, dynamic view of work processes, project behavior representations and other project main characteristics, improving the quality of the processes and results. Resumo. Ao compreender o funcionamento das diversas partes envolvidas no projeto, o gerente antecipa conseqncias e avalia situaes problemticas de forma mais efetiva. Assim, a aplicao do pensamento sistmico no ambiente de projetos promove uma viso holstica e o entendimento das influncias majoritrias. A gesto da qualidade, ainda, deve estar relacionada a todas as partes do projeto e responsabilidade do gerente avaliar os objetivos individuais, do projeto e da organizao como um todo integrado. Este artigo explica a partir de exemplos prticos como o pensamento sistmico impacta o processo de tomada de deciso antes, durante e depois do projeto ao permitir identificao de premissas gerenciais implcitas, incorporao de fatores humanos, viso dinmica dos processos de trabalho, representao explcita do comportamento do projeto e outras caractersticas relevantes para o projeto, favorecendo a qualidade dos processos e resultados.

1. Introduo Inmeras atividades apresentam caractersticas dinmicas semelhantes [Senge 2003]. O desenvolvimento de um software, a preparao de uma apresentao, ou a construo de uma usina nuclear so exemplos de projetos. Todas estas atividades possuem os mesmos processos genricos em maior ou menor grau de detalhes: objetivos, prazos, cronograma de atividades, recursos materiais, sistemas de controle, e a necessidade de mo-de-obra para executar estas atividades [Santos 2006]. A qualidade do produto final diretamente associada ao bom desempenho destas atividades.


2

A modelagem de sistemas dinmicos pode ser vista (1) como um processo de mapeamento que utiliza grficos, diagramas, palavras e lgebra simples e amigvel para ativar e capturar conhecimentos de grupos de pessoas que atuam como equipe, ou (2) como um conjunto de conhecimentos sistematizados e desenvolvidos para organizar, filtrar e estruturar o vasto conhecimento que uma equipe de indivduos compartilha [Figueiredo 2001]. Desta forma, favorecem os ambientes de aprendizagem a partir do momento em que as pessoas so capazes de entender, testar, desafiar e redefinir suas formas de raciocinar. A evoluo destes ambientes de aprendizagem contribui para produo de resultados com qualidade cada vez maior [Argyris e Schn 1978].

A Dinmica de Sistemas, por sua vez, se mostra como o mtodo mais apropriado para modelagem de ambientes dinmicos [Sterman 1992] como, por exemplo, o ambiente de projetos de software. Dentre os diversos benefcios da aplicao do pensamento sistmico no ambiente de projetos, destacam-se a viso das influncias prioritrias no projeto, identificao de premissas implcitas e fatores conflitivos, entendimento do impacto de polticas de qualidade, compreenso sistmica dos processos e suas conseqncias positivas e negativas [Rodrigues 2000].

Para compreender uma situao de forma simples, direta e sistmica, indicado o uso de arqutipos de sistema, pois permitem que os envolvidos aprendam como estruturar detalhes relevantes em uma estrutura coerente capaz de demonstrar as foras envolvidas no sistema e suas conseqncias [Senge 2003]. Assim, este artigo faz uma anlise sistmica das partes envolvidas nos projetos de softwares e como estas afetam a qualidade do produto final e do ambiente como um todo, procurando mostrar atravs de arqutipos sistmicos as estruturas dinmicas que envolvem os projetos de software.

2. A Mente dos Envolvidos e seu Impacto na Qualidade Os gerentes tm em seu cotidiano o planejamento e acompanhamento de projetos uma vez que a maior parte admite planejar (85%) e controlar (82%) seus projetos na maioria das vezes ou sempre [PMI 2008]. Entender como funciona este cotidiano e como as decises so tomadas com diagramas causais e reflexes das aes passadas e atuais permitir que os gerentes se tornem mais consistentes em suas decises [Senge 2003].

Na verdade, os gerentes de projeto esto sempre desenvolvendo a capacidade de resolver problemas imediatos, definindo metas, estabelecendo cronogramas, alocando atividades, entre outros [PMBOK 2004]. O ser humano determina com rapidez a causa para qualquer evento que seja considerado um problema e costuma concluir que a causa um outro evento [Senge 2003]. Na prtica, a maneira como o gerente percebe (modelo mental e viso de mundo) e como processa a tomada de decises crucial e afeta diretamente no sucesso da compreenso, do planejamento e da execuo de seus objetivos [Valena 2007]. Desta forma, uma viso sistmica da estrutura complexa que envolve as decises de projeto se torna um grande diferencial para a qualidade das decises tomadas antes, durante e ao final do projeto.

Os gerentes precisam, na verdade, aprender a refletir sobre seus modelos mentais atuais e expor os mesmos para se tornarem mais flexveis mudana [Senge 2003]. Sem esta reflexo, eles no sero capazes de desafiar suas vises de mundo, ficando limitados na experimentao de novas formas de pensamento. Esta incapacidade, por sua vez, dever refletir na equipe que se tornar fechada e limitada enquanto equipe cooperativa. A flexibilizao produz novas perspectivas, permitindo que solues


3

criativas sejam pensadas [Andrade 2006]. Ou seja, os gerentes precisam refletir suas estruturas de raciocnio para no se tornarem prisioneiros destas.

O sistema que envolve a qualidade e o gerenciamento de projetos , na verdade, um conglomerado complexo de variveis interdependentes [Abdel-Hamid 1989]. Ao refletir sobre algumas variveis (e.g. motivao e comunicao), possvel perceber que um gerenciamento eficaz precisa considerar a complexidade do sistema. Ou seja, a qualidade de um componente, por menor que este seja, influencia a qualidade do produto como um todo. Um engenheiro de software desmotivado, por exemplo, pode levar ao fracasso de toda uma equipe. Assim, para manter a qualidade dos processos e do produto, a viso sistmica de toda equipe, especialmente do gerente do projeto, torna-se uma condio bsica, haja vista a crescente complexidade que envolve os projetos de software (equipes crescentes, funcionrios temporrios, tecnologias diferentes a cada instante, etc.).

Sabe-se, por exemplo, que, quanto mais participativo o estilo de gerenciamento, maior a probabilidade de aumentar o envolvimento e comprometimento da equipe com o projeto, aumentando dessa forma a possibilidade de sucesso do projeto [Argyris & Schn 1978]. No entanto, muitas posturas e idias novas de como estimular essa participao no so colocadas em prtica por entrarem em conflito com poderosos modelos mentais implcitos [Senge 2003]. Esto presos, portanto, ao paradigma de que, enquanto estiver funcionando, no precisa ser melhorado. Este o pensamento conformado que est associado a ambientes que favorecem dinmicas do tipo ganha-perde ou perde-perde, no resolvendo o problema de forma que ele no ocorra mais. Na verdade, este apenas um dos laos inibidores do modelo tpico da maioria das organizaes, onde so criadas condies de indiscutibilidade, profecias auto-realizantes, processos auto-oclusivos e erros em escalada, enquanto as prprias organizaes e seus gestores permanecem inconscientes da criao destas condies [Valena 2007]. Este modelo favorece o controle unilateral e a competitividade. Presos a estas condies de erro, as pessoas buscam camuflar seus erros e, como conseqncias inevitveis, a eficcia prejudicada, a confiana abalada, o distanciamento cresce e a injustia se torna comum. A qualidade do projeto , ento, afetada por estes aspectos comportamentais. Por fim, neste ambiente, dificilmente as pessoas e as equipes podem se abrir para uma verdadeira mudana paradigmtica de suas aes e da prpria cultura organizacional [Valena 2007]. Na verdade, o gerente e os demais envolvidos no projeto so diretamente influenciados pelo ambiente e o influenciam reciprocamente.

As aes do gerente, portanto, visam eficcia de acordo com o seu prprio modelo mental internalizado e a percepo que ele possui do ambiente em que est inserido e das pessoas que nele tambm esto.

3. Viso Sistmica do Projeto O pensamento sistmico est interessado nas caractersticas essenciais do todo integrado e dinmico, que no esto em absoluto nas partes, mas nos relacionamentos dinmicos entre elas, entre elas e o todo, e entre o todo e outros todos [Valena 2007]. Desta forma, a viso sistmica estimula que os envolvidos no projeto tenham seu entendimento modificado das partes para o todo. Ou seja, ao invs de observar cada rea do projeto isoladamente, o gerente deve orientar-se para o projeto como um todo, suas variveis e como estas se relacionam e influenciam umas as outras e o projeto.


4

Desta forma, as pessoas envolvidas demonstram maior facilidade em perceber rapidamente o impacto que aes locais tm na organizao como um todo [Solinger 2004]. Enquanto pensam sistemicamente e refletem sobre suas aes, as equipes aprendem enquanto trabalham e este aprendizado influencia positivamente a produtividade e qualidade [Valena 2007]. Isto forma um ciclo de reforo virtuoso demonstrado na figura 1 a seguir, onde a varivel Trabalho aumenta a varivel Aprendizado, que, por sua vez, torna a aumentar a capacidade de trabalho e reflexo. As setas com o + indicam que a ampliao de uma varivel aumenta a outra. Pensar sistemicamente o projeto, , portanto, perceber ciclos como estes, observando como determinadas variveis-chave se influenciam direta ou indiretamente.

Trabalho Aprendizado+

+

R

Figura 1. Ciclo de reforo do trabalho e aprendizado Por outro lado, enquanto o software desenvolvido, muitos fatores levam a

reduo da produtividade [PMBOK 2004]. Estas perdas de processo (tempo gasto para preparao de ambiente, retrabalho, burocracias, entre outros) so causadas, por exemplo, pela presso de calendrio e revises tardias para deteco de erros [Abdel-Hamid 1989]. bastante comum, por exemplo, em projetos de software um aumento da carga de trabalho semanal buscando aumentar a execuo de atividades do projeto e diminuir o atraso no curto prazo. Este conjunto forma um exemplo do chamado ciclo de balanceamento ilustrado na figura 2, onde o Atraso no calendrio leva a aumentar a Carga extra de trabalho semanal que diminui, por sua vez, o atraso no calendrio. A seta com o -, portanto, indica que a ampliao de uma varivel diminui a outra.

Atraso nocalendrio

Carga extra detrabalho semanal

+

-

B

Figura 2. Ciclo de balanceamento do atraso e carga extra

Ao analisar sistemicamente o ambiente de um projeto, possvel perceber como as partes esto inter-relacionadas. Na verdade, os projetos apresentam relaes no-lineares [Sterman 1992]. Assim, no exemplo do atraso solucionado pela carga extra de trabalho, avalia-se que esta carga extra de trabalho semanal leva a uma diminuio na produtividade da equipe ao longo do tempo, uma vez que, com o tempo, os membros sentem-se cansados pela carga extra, provocando mais erros, e gerando mais retrabalho. Este retrabalho, por sua vez, atrasa os resultados e o calendrio do projeto [Abdel-Hamid 1989]. A Figura 3 ilustra como estas variveis interagem entre si, demonstrando um exemplo prtico de um arqutipo de sistema, o arqutipo da Soluo Quebra-Galho, onde a contratao de horas extras vista como a soluo temporria e sintomtica para o atraso no projeto, uma vez que no ataca a causa real do problema e, como conseqncia indesejada, com o tempo (indicado na notao grfica por dois traos na seta), ele pode tornar a acontecer.

Resolver problemas com solues rpidas e no profundas podem dar ensejo gerao de um arqutipo de Soluo Quebra-Galho, onde a soluo rpida gera conseqncias no intencionadas, que com o passar do tempo fazem ressurgir o


5

problema [Valena 2007]. Assim, gerentes de projetos devem resistir tentao de consertos rpidos com foco em curto prazo. A soluo deve ser fundamental de modo a provocar uma mudana verdadeira na equipe envolvida no projeto, ou seja, no gerar conseqncias indesejadas no futuro.

R

Atraso nocalendrio

Carga extra detrabalho semanal

+

-

B

Cansao

Taxa de erros

Retrabalho

+

Figura 3. Horas extras como soluo quebra-galho No caso anterior, entendvel na viso de curto prazo a preferncia pela soluo

rpida de contratao de horas extras j que uma soluo fundamental difcil e no traria resultados instantneos. Na verdade, nestes casos, so feitas avaliaes da fora de trabalho disponvel com o objetivo de aument-la de alguma forma. No entanto, esse nvel de fora para realizar um determinado trabalho no projeto deve considerar diversas variveis como nvel de experincia da equipe, treinamento de membros novatos, tempo para assimilao do treinamento, e perdas em comunicao interna dada a quantidade de membros na equipe [Santos 2006]. Assim, a contratao de novos membros exige um tempo para que a soluo tenha impacto no projeto. Na verdade, a deciso gerencial de contratao de mais empregados com o intuito de acelerar a concluso de um projeto seguramente aumenta a produtividade da organizao no longo prazo, porm, no curto prazo esta produtividade pode ser at diminuda j que trabalhadores experientes tero que se dividir entre suas respectivas tarefas e o treinamento dos novatos [Santos 2006].

Por outro lado, a contratao de horas extras leva a perdas de processo, resultando em trabalho mais desordenado. Na verdade, mesmo desordenado, o trabalho da equipe aproxima o projeto do seu fim. A qualidade do resultado, todavia, estar comprometida. Na medida em que se chega mais prximo do final do projeto, a resistncia entrada de novas pessoas cresce [Abdel-Hamid 1989]. Enfim, esta proximidade com o final do projeto diminui as chances de se contratar e treinar novos membros. Na Figura 4 ilustrado um arqutipo que explica como funciona esta transferncia de responsabilidade em relao ao problema do atraso no calendrio.

Essa estrutura refere-se a um dos arqutipos mais propcios para a literatura da psicologia ou suas reas combinadas, Transferncia de Responsabilidade [Valena 2007]. Isto se deve ao fato de que, na medida em que o sintoma do problema aparece, a busca pela soluo mais fcil rpida e alivia o problema, fazendo com que o responsvel pela resoluo do problema deixe de pensar no problema e sua causalidade. Todavia, a soluo rpida gera efeitos colaterais que, com o tempo, diminuem a possibilidade de realizar a soluo fundamental seja pela insistncia em adotar a soluo mais simples repetidamente ou pela crescente dificuldade que o tempo causa para aplicao da soluo complexa, como o caso ilustrado no exemplo anterior. A melhor estratgia para esta estrutura aplicar imediatamente a soluo rpida com o objetivo de solucionar o problema, mas, em paralelo, executar aes que levem soluo fundamental para garantir que o problema no torne a ocorrer [Valena 2007].


6

Contratao dehoras-extras

Atraso nocalendrio

Contratao etreinamento dos

novatos

Trabalhodesordenado

Proximidade com o fimdo projeto (sem

qualidade)

-

+

+

-

-

+

+

B

B

R

Figura 0. Transferncia de responsabilidade no atraso do calendrio

Outro fator crtico em projetos dedicao do gerente. Na prtica, a dedicao do gerente atividade de gerncia, em muitas empresas varivel [PMI 2008]. Esta variao, na verdade, tem como limitante a presso exercida pela alta administrao que exige dedicao exclusiva ao projeto somente em momentos de tenso, risco, atrasos e perdas. A dedicao do gerente ao projeto, por sua vez, afeta outras variveis da estrutura, como a produtividade da equipe. A figura 5 mostra outro arqutipo, Limite ao Crescimento, que mostra as conseqncias destas variaes de dedicao do gerente sobre variveis crticas ao sucesso do projeto. No arqutipo, possvel entender como o aprendizado, o envolvimento e o comprometimento da equipe, bem como os resultados e a produtividade do projeto so limitados pela dedicao do gerente. Ao analis-lo, fica claro que uma srie de variveis favorveis ao projeto forma ciclos de reforo junto com a produtividade da equipe. Ou seja, quanto maior a produtividade, mais resultados, envolvimento e aprendizado. Por outro lado, no ciclo de balanceamento, quanto maior a produtividade, menos fatores de presso interna como riscos e atrasos e, conseqentemente, menos exigncia para dedicao do gerente ao projeto. No caso, a organizao precisa entender que diminuir a dedicao do gerente ao projeto, diminui a produtividade e gera complicaes no futuro.

ProdutividadeResultados

Envolvimentoda equipe

Aprendizado

+

+

+

+++

Presso interna(calendrio, alta

administrao, etc)

Riscos do projeto

Atraso nocalendrio

Dedicao doGerente ao projeto

-

-

-

+

+

+

+

R

B

Figura 5. Conseqncias da dedicao do gerente ao projeto Em muitos arqutipos citados possvel perceber a ao do tempo. O principal

problema em lidar com estruturas de tempo o de combinar duas habilidades: a de conhecer como funciona a estrutura e a de exercitar a pacincia [Valena 2007]. Um projeto exibe diversos atrasos em sua conduo, seja no tempo para descoberta de erros e o tempo para corrigi-los, no tempo para contratar membros e o tempo para trein-los at t-los efetivos na funo, ou no tempo para responder a quaisquer mudanas no ambiente do projeto [Sterman 1992]. Por exemplo, no caso de um crescimento repentino no tamanho do projeto, ajustes na equipe envolvida ou no calendrio no so instantneos, pois precisam de um tempo para tal [Abdel-Hamid 1989].


7

Um arqutipo, por exemplo, onde o tempo considerado extremamente relevante refere-se ao de Crescimento e Subinvestimento. Isto se deve ao fato de que, neste arqutipo, bsico para o responsvel pelo projeto prever como seus investimentos sero afetados com a crescente demanda por desempenhos e capacidades. Na figura 6, ilustrado um exemplo deste arqutipo onde o crescimento da empresa atravs da contratao de pessoas e aceitao de novos projetos forma um ciclo de crescimento na quantidade tanto de projetos em que a organizao est envolvida quanto no seu quadro de pessoal. Para quase todas as organizaes este cenrio timo j que a existncia de novos projetos e funcionrios indica o crescimento da organizao. O gerente deve, no entanto, estar atento s diversas limitaes que este crescimento vir a encontrar. No caso, ilustrado o problema da comunicao que muitas vezes menosprezado pela gerncia.

Contratao depessoas

Quantidade deprojetos na empresa

Eficincia doscanais de

comunicao

Produtividade

Integrao daequipe

Investimento emintegrao

Perdas deprocesso

+

+

-

+ +

-

++

+

R B1

B2

Figura 6. Crescimento da organizao e subinvestimento na comunicao Atravs do entendimento do arqutipo, possvel perceber que o crescimento da

quantidade de projetos dificulta os processos de comunicao, especialmente se tratando de organizaes com estes processos razoavelmente indefinidos. A eficincia dos canais de comunicao, por sua vez, afeta diretamente a produtividade nos projetos j que, se comunicando melhor, a equipe mantm consistente o projeto e evita retrabalhos [PMBOK 2004]. Da mesma forma, na medida em que uma equipe se torna mais produtiva, a quantidade de projetos na empresa tende a crescer. Forma-se, ento, um ciclo de balanceamento (chamado de B1 na figura 6) onde a quantidade de projetos diminui a eficincia da comunicao que diminui a produtividade, diminuindo a quantidade de projetos na empresa. Continuando a leitura, se percebe que a diminuio da quantidade de projetos aumenta a eficincia da comunicao que aumenta a produtividade e a quantidade de projetos. Desta maneira, este ciclo de balanceamento limita o crescimento da quantidade de projetos e pessoas na empresa.

A interpretao deste arqutipo leva a concluir que o investimento em comunicao tanto de tempo do gerente quanto de recursos da organizao bsico para suportar o crescimento organizacional. Os canais de comunicao funcionam, portanto, como limitantes ao crescimento. Por este ser um fator interno e, assim, passvel de investimento, a partir do momento em que o gerente no investe na melhoria da comunicao de sua equipe e entre as equipes, este cenrio se constitui atravs do crescimento contnuo com ausncia de investimento. O outro ciclo de balanceamento, ilustrado na figura 6 (B2), mostra justamente como esta eficincia dos canais de comunicao afeta a organizao. possvel perceber que o investimento em integrao favorece a continuidade do crescimento. Atravs deste arqutipo, ento, possvel


8

enxergar de forma sistmica problemas da comunicao e entender, inclusive, os fatores que levam o gerente a no investir em comunicao por um perodo de tempo. Assim, existe um perodo de tempo em que o gerente e a equipe acreditam que a comunicao est eficiente at que percebam perdas de processo. Na maioria das empresas, somente quando estas perdas se tornam perceptveis, feito o investimento para solucion-la. Isto normalmente leva tempo, o que pode tornar invivel a soluo fundamental quando o problema for percebido.

Outro aspecto extremamente relevante no entendimento das partes do projeto refere-se deteco de erros. O trabalho desordenado aumenta a quantidade de erros encontrados durante o projeto. Erros ocultos existem e, obviamente, quando encontrados, tenta-se minimiz-los, levando a melhorar a organizao do trabalho. Desta forma, a descoberta de erros tende a melhorar a organizao do trabalho. A existncia de erros ocultos, por sua vez, aumenta, com o tempo, o atraso no calendrio aumentando a reflexo sobre as aes para entendimento dos problemas. A reflexo das aes, por sua vez, com o tempo, diminui a ocorrncia de erros ocultos. A soluo de problemas atravs da reflexo da ao considerada fundamental j que visa resoluo de maneira duradoura [Valena 2007]. Ao analisar estes reforos sistemicamente, so percebidos os efeitos da busca pela soluo rpida de dar continuidade ao trabalho desordenado na tentativa de alcanar resultados mais rpidos: necessidade de controle e ocupao do gerente.

A figura 7 ilustra um arqutipo de Transferncia de Responsabilidade que se baseia neste exemplo. possvel enxergar que o problema da existncia de erros ocultos tem como soluo rpida a continuidade do trabalho desordenado ignorando a raiz do problema. Desta forma, a tendncia surgirem os efeitos colaterais que, por sua vez, dificultam a reflexo das aes j que ocupa o gerente e a equipe, no permitindo que se dediquem a refletir e aprender com suas aes e erros.

TrabalhodesordenadoErrosdescobertos

Erros ocultos

Atraso nocalendrio

Reflexo sobreas aes

Necessidade decontrole dasatividades

Ocupao dogerente

+

-

+

-

+

+

+

+

-

B

B

R

Figura 7. Solues para o problema da existncia dos erros ocultos Com este arqutipo, possvel entender um dos grandes benefcios da reflexo

sobre as aes. Na verdade, para o entendimento das partes e suas relaes com o todo extremamente importante a prtica da reflexo das aes [Valena 2007]. Todavia, no cotidiano da gesto de projetos, comum encontrar prticas que inibem o estmulo a tal prtica. O controle excessivo das atividades, por exemplo, pode no ser imediatamente visto como um inibidor, mas, ao analisar sistemicamente a estrutura, possvel enxergar uma disputa entre o estmulo ao aprendizado contra o controle e monitoramento da equipe. Para entender como isto acontece, deve-se perceber que a diminuio na dedicao do gerente ao projeto ocasiona perdas de processo, aumentando a carga de trabalho da equipe e a necessidade de controle. Por outro lado, esta diminuio na dedicao ocasiona perdas na comunicao, afetando o aprendizado e impedindo o


9

crescimento do nvel de experincia da equipe. Esta estrutura conhecida como o arqutipo de Escalada, onde dois balanceamentos so conectados por uma varivel que tende a favorecer os resultados somente de uma das partes, prejudicando a outra. O resultado este comportamento que impede o crescimento simultneo dos dois ciclos. Ou seja, no exemplo, que ilustrado atravs da figura 8, o aumento no controle das atividades implica na reduo do aprendizado e vice-versa.

Dedicao dogerente ao projeto

Carga de trabalhoda equipe

Controle dasatividades

Perdas deprocesso

-

+

+

+

B1

Eficincia doscanais de

comunicao

Aprendizado

Nvel deexperincia da

equipe-

+

+

+

B2

Figura 8. Controle e monitoramento inibem o aprendizado e reflexo

Nos arqutipos de Escalada, a soluo tambm a busca pela separao dos ciclos de forma a evitar a competio entre as duas atividades. O ideal favorecer a auto-competio, onde cada um preocupa-se apenas com seu prprio desempenho. Outra sugesto de ao estimular que ambos cooperem para alcanar em conjunto o objetivo [Valena 2007]. No exemplo, ento, a reflexo deve estimular a descoberta de uma forma diferente de controle de modo a evitar a desorganizao, mas permitir que a equipe continue a refletir sobre seus erros e sucessos.

Por fim, um dos arqutipos mais complexos trata dos Adversrios Acidentais. Este arqutipo demonstra como funcionam certas parcerias e estimula a reflexo sobre o real comprometimento com o objetivo comum dos parceiros envolvidos. Muitas vezes, as pessoas pensam estar agindo de forma colaborativa e, no entanto, provoca-se uma competio entre estas [Valena 2007]. Como exemplo, pode-se considerar a parceria entre equipes de vendas e de planejamento em empresas de projetos (figura 9). De um lado, os clientes exigem prazos cada vez mais curtos e a equipe de vendas acaba por aceitar a reduo para vender mais. Por outro lado, a eficincia do gerente de projetos o torna eficaz nos planejamentos e, com isso, aumenta a garantia de trmino do projeto dentro do prazo. A princpio, estes dois ciclos se reforam individualmente. possvel perceber, ainda, a grande parceria que estas equipes formam j que, enquanto vende-se mais projetos, a equipe gerencial se torna mais eficiente seja atravs do aprendizado de prtica [Argyris e Schn 1978] ou da contratao de novos gerentes. A eficincia da equipe gerencial, por sua vez, favorece a qualidade dos projetos e, com isso, mais argumentos para a equipe de vendas aumentarem suas vendas.

No entanto, para alcanar realmente aumento de vendas, a equipe de vendas se submete a prazos mais curtos, aumentando a presso da alta administrao para diminuio dos prazos estabelecidos pela gerncia. Isto prejudica a eficincia da equipe gerencial e, conseqentemente, a garantia dos projetos terminarem nos prazos. Por outro lado, a eficincia da equipe gerencial exige planejamentos bem feitos que impliquem projetos com prazos confortveis de modo a evitar atrasos. Estes prazos confortveis aumentam o tempo exigido para os projetos que, por sua vez, vai diminuir as vendas de projetos. Os dois parceiros precisam definir se realmente pretendem ser parceiros e criar um futuro conjuntamente, ou ser concorrentes [Valena 2007]. Logo, a equipe de vendas e a equipe gerencial devem estar mais prximas de modo a favorecer o sucesso


10

mtuo. Assim, a equipe de vendas ser capaz de entender a capacidade de produo da empresa, e a equipe gerencial entender as necessidades dos clientes.

VendasDemanda de

projetos com prazoscurtos

R2+

+

Garantia detrmino no prazo

Eficincia dogerente de projetosR3

+

+

Projetos+

+

Presso da altaadministrao para

diminuio dos prazos

+

-

Tamanho do prazoexigido para o projeto

Qualidade dosprojetos da empresa

+

-

+

+

R4

R1

B1

B2

Figura 9. Equipe de vendas e gerencial em parceria acidental

Da mesma forma, muitas estruturas podem ser encontradas por todos os processos do gerenciamento de projetos e da qualidade. Cada arqutipo indica estruturas de ao e prope uma nova perspectiva para enxerg-las. Os arqutipos, na verdade, favorecem bastante o esclarecimento da viso do todo. Ao analisar as partes isoladamente, as pessoas so incapazes de identificar estas estruturas complexas com rapidez. Atravs do pensamento sistmico possvel, portanto, visualizar as partes e o comportamento destas enquanto variveis da estrutura como um todo.

4. A Viso Sistmica no Processo de Tomada de Deciso Os gerentes precisam de meios de distinguir o que importante, identificando as variveis nas quais devem focar e quais so menos relevantes. O processo de tomada de deciso gerencial claramente favorecido pela aplicao do pensamento sistmico neste processo [Senge 2003]. Na verdade, a arte do pensamento sistmico est em enxergar atravs da complexidade de modo a perceber as estruturas subjacentes que geram a mudana [Valena 2007]. Desta forma, o gerente capaz de tomar decises e solucionar problemas de maneira duradoura.

Na realidade, o pensamento sistmico vincula o uso dos arqutipos a fim de perceber as estruturas complexas subjacentes. Atravs da visualizao destas estruturas, o gerente capaz de perceber os efeitos que cada alternativa no processo decisrio ocasionar no sistema. Cada ao reflete em diversas variveis do sistema e, atravs dos arqutipos de sistema, o gerente entende quais destas devem ser manipuladas de forma a conseguir a mudana desejada. Assim, a tomada de deciso tem maior consistncia com a realidade da situao, o que evita o surgimento de conseqncias no-intencionadas no futuro [Senge 2003]. Os arqutipos sistmicos, portanto, oferecem ao gerente uma viso estruturada da real problemtica encontrada no gerenciamento de projetos.

Os modelos sistmicos proporcionam muitos benefcios, mas o objetivo principal destes ajudar o processo mental dos tomadores de deciso a lidar com o comportamento de sistemas complexos ao longo do tempo, representando os modelos mentais em formulaes explcitas por meio de diagramas causais. Estes modelos


11

devem ser utilizados como instrumentos de apoio para que os prprios administradores aprendam as conseqncias de seu modo de enxergar a realidade, em vez de serem utilizados apenas para fazer previses sobre o futuro [Andrade 2006].

As decises gerenciais so tomadas com base no comportamento do sistema e resultam em aes que tm como objetivo alterar o estado em que o sistema se encontra. Quando os resultados das aes afetam as condies do estado do sistema, o gerente pode analisar de que forma ele foi alterado, ou seja, analisar a eficcia da ao gerencial tomada [Santos 2006]. Cada alterao no sistema gera informaes que podem desencadear novas aes gerenciais, que provocaro outras alteraes no estado do sistema. Essa busca pelo estado ideal do sistema processada por meio de realimentaes em um conjunto de relaes causais entre as variveis do sistema, onde o gerente responsvel por decidir quais aes devem ser mais eficazes para cada estado do sistema considerando os possveis efeitos esperados e inesperados. Com base nestes diagramas e no entendimento da complexidade do todo, antes de decidir por um curso de ao, deve-se procurar identificar quais as conseqncias das aes e quais as conseqncias das conseqncias, na perspectiva das aes interdependentes [Valena 2007]. Algumas vezes, no entanto, conseqncias imprevistas s aparecem aps vrias simulaes ou planejamento de cenrios. Aprendendo a ver as estruturas dentro das quais operamos, iniciamos um processo de libertao das foras antes no identificadas e acabamos dominando a habilidade de trabalhar com elas e de mud-las [Senge 2003]. O principal resultado prtico do pensamento sistmico que afeta o decisor a capacidade de identificao de como as aes e mudanas nas estruturas podem levar a melhorias significativas e duradouras. Ao permitir uma visualizao sistmica da estrutura, os arqutipos ajudam os gerentes a enxergar o funcionamento destas e, ento, encontrar os melhores pontos para atuao, especialmente em situaes onde grande a presso sobre as decises.

5. Concluses Um gerenciamento eficaz e eficiente traz diferenciais significativos na aplicao dos recursos disponveis. Diversas dificuldades, no entanto, so encontradas pelos gerentes que so extremamente exigidos devido grande complexidade de atividades que compem suas responsabilidades. O gerente deve ter competncias multidisciplinares para ser capaz de enxergar o projeto como um todo e entend-lo.

A aplicao do pensamento sistmico ao gerenciamento de projetos permite ao gerente a capacidade de enxergar esse sistema complexo que envolve sua gesto e os fatores crticos que ameaam e favorecem a mesma. Ou seja, possvel entender como diversas variveis se relacionam para formar a estrutura que envolve todos os processos e prticas gerenciais. Para tal, sugerido o uso de arqutipos, pois favorecem visualizar de forma clara e concisa os processos mentais envolvidos nestas estruturas capazes de perdurar por um longo perodo de tempo. Os arqutipos mostram comportamentos que, de certa forma, se sabe suas conseqncias imediatas. O que no se v com facilidade so os processos de feedback que reforam ou balanceiam as aes.

Na realidade, problemas nem sempre so fceis de descobrir e, muitas vezes, tornam-se recorrentes em sua generalidade. Ou seja, muitos dos problemas encontrados so, na verdade, recorrncia de problemas comuns em situaes do dia-a-dia da gerncia de projetos, seja no prprio projeto, na organizao ou em outras organizaes. Em


12

muitos casos ainda, as solues lineares e convencionais, usadas para muitos problemas, no so adequadas para muitas situaes complexas, como demonstrado nas situaes tratadas neste trabalho

Cabe ao gerente analisar quais variveis so mais relevantes para a situao de sua equipe, organizao, projeto, cliente e seu ambiente como um todo. Desenvolver essa viso holstica tende a minimizar drasticamente os erros nos processos decisrios atualmente predominantes. Assim, atravs do entendimento da estrutura como um todo que afetado pela complexidade dos relacionamentos entre as variveis, o gerente se torna capaz de antecipar conseqncias desejadas e indesejadas que cada deciso ocasionar. Desta forma, o gerente passa a planejar para curto prazo com objetivos concretos e mensurveis orientando o conjunto para objetivos maiores e de longo prazo.

Referncias Abdel-Hamid, T. K. Madnick, S. E. Lessons Learned from Modeling the Dynamics of

Software Development. Communications of the ACM. Dezembro, 1989. Argyris, C. Schn, D. Organizational Learning: A theory of action perspective. Mass:

Addison Wesley, 1978. Andrade, A. et al Pensamento Sistmico: Caderno de Campo. Porto Alegre: Bookman,

2006. Figueiredo, R. Zambom, A. Saito, J. A introduo da simulao como ferramenta de

ensino e aprendizagem. XXI Encontro Nacional de Engenharia de Produo. Salvador, 2001

Rodrigues, A. The Application of System Dynamics to Project Management: An Integrated Methodology (SDPIM). PhD Dissertation Thesis. Department of Management Science, University of Strathclyde, 2000.

PMI (Project Management Institute). PMBOK, Um Guia do Conjunto de Conhecimentos em Gerencia de Projetos - Terceira Edio. Project Management Institute, 2004.

PMI (Project Management Institute) Brasil. Estudo de Benchmarking em GP 2008 (Relatrio). Project Management Institute Chapters Brasileiros, 2008. Disponvel em . Acessado em 15/03/2009.

Santos, A. M. A Aplicao de um Modelo de Simulao para o Gerenciamento de Projetos: um estudo de caso utilizando a dinmica de sistemas. Dissertao de Mestrado, Escola Politcnica da Universidade de So Paulo, Departamento de Engenharia Naval e Ocenica. 2006.

Senge, P. M. A Quinta Disciplina: Arte e Prtica da Organizao de Aprendizagem. 15. ed. So Paulo: Editora Nova Cultural, 2003.

Solinger, T. The Whole Works. PM Network Setembro, 2004. Sterman, J.D. System dynamics modeling for project management. System Dynamics

Group, Sloan School of Management, MIT, 1992. Valena, A. C. Mediao: Mtodo de Investigao Apreciativa da Ao-na-Ao:

Teoria e Prtica de Consultoria Reflexiva. Recife: Bagao, 2007.

01-woses-2009

Documents