Artigos

Nesta página estão publicados artigos meus, tanto aqueles antigos, publicados na Byte Brasil e na Developers' Magazine, quanto outros mais recentes.

Artigos da série Arquiteto Corporativo: Profissional do Futuro

Introdução

Cinco Razões para se tornar um Arquiteto Corporativo

Por onde Começar?

Frameworks de Arquitetura - Zachman

Frameworks de Arquitetura - TOGAF 9

 

Artigos recentes

Arquitetura Corporativa é mais do que TI - Novembro de 2011

Arquitetura Corporativa e Gestão de Portfolio de Projetos - Julho de 2009

Os 3 mal-estares do Planejamento Estratégico - Setembro de 2008

Gestão do Conhecimento e Cultura Organizacional: Uma Lição da II Guerra - Setembro de 2007

Analistas de Processos de Negócios: 5 Competências Fundamentais - Abril de 2007

PMBOK não basta: Entendendo como a Cultura e o Poder afetam os projetos - Fevereiro de 2007

 

Artigos publicados na Byte Brasil

Metodologia: Capricho ou Necessidade - Byte Brasil - Dezembro de 1995

Como não perder o rumo na migração para OO - Byte Brasil - Fevereiro de 1996

 

Artigos publicados na Developers' Magazine

Migração Tecnológica é um Processo Cultural - Developers' Magazine - Janeiro de 1997

Orientação a Objetos e Projetos Piloto - Developers' Magazine - Agosto de 1997

Tecnologia: O profissional do Futuro e o Futuro do Profissional - Developers' Magazine - Dezembro de 2001

 

 

Os 3 mal-estares do Planejamento Estratégico

Os 3 mal-estares do planejamento estratégico

Por Atila Belloquim

 

No segundo semestre da cada ano, muitas empresas realizam seu ritual periódico de planejamento estratégico. Os executivos reúnem-se para revisar o planejamento em curso e estabelecer objetivos e metas para o próximo período.

Cada executivo, naturalmente, conhece relativamente bem os detalhes da operação de sua área, mas, devido às pressões do dia-a-dia e às inevitáveis dificuldades de comunicação, seu conhecimento a respeito das demais áreas é quase sempre bastante fragmentário. Mesmo no que se refere a sua própria área, às vezes o executivo dispõe apenas de alguns indicadores mais ou menos confiáveis. Sobre a empresa como um todo, pode acontecer de ele ter que se dirigir à reunião com pouco mais do que os últimos balancetes. Assim, não é incomum que esses executivos vão para as reuniões de planejamento estratégico com a desconfortável sensação de que serão chamados a tomar decisões estratégicas com base em informações em quantidade insuficiente e de qualidade duvidosa.

O processo de planejamento utiliza diversas ferramentas para ordenar e guiar o pensamento e as discussões. Análises SWOT, modelos de referência como a Cadeia de Valor de Michael Porter e o Balanced Scorecard estão entre as ferramentas mais populares. Às vezes, estão disponíveis dados de produção ou de mercado em ferramentas de Business Intelligence. Aqui ocorre o segundo mal-estar. Muitas dessas técnicas e ferramentas produzem resultados tão bons quanto os dados de entrada disponíveis. Ou seja, se a informação de entrada é incompleta ou inadequada, o resultado da aplicação das técnicas pode deixar a desejar.

Tomemos, por exemplo, a análise SWOT. O “S” e o “W” dizem respeito forças e fraquezas internas da organização. Pode haver pouca informação confiável a este respeito. Durante as reuniões de planejamento estratégico, idéias são colocadas na mesa, hipóteses são levantadas e opções são discutidas. Infelizmente, a discussão sobre as opções muitas vezes é feita com base em hipóteses e pressupostos não verificáveis no momento das reuniões, sendo que, o que é pior, trata-se de informação disponível na empresa, mas não se sabe onde nem com quem!

É costume referir-se à Estratégia como “olhar a floresta em vez de olhar as árvores”. O problema é que, no mundo real, não dá para entender a floresta sem conhecer bem as árvores também. Grandes decisões estratégicas podem ser técnica ou economicamente inviáveis quando sua implementação é desdobrada em detalhes.

Ao final do processo de planejamento estratégico, o executivo sai com um conjunto de metas que precisa alcançar em sua área. Neste momento, ocorre o terceiro mal-estar, pois é freqüente que o executivo não saiba por onde começar. Afinal, é sabido que comunicar a estratégia e transforma-la em operação no dia-a-dia é um dos maiores desafios das organizações. Na falta de melhores instrumentos, o executivo acaba se restringindo a cobrar “mais empenho”. Mas a implementação da estratégia tem que ser mais do que “vamos trabalhar mais duro”.

Um exemplo concreto
Suponhamos que a empresa esteja enfrentando um ambiente competitivo que se acirrou no último período. Novos entrantes muito ágeis surgiram, e os concorrentes tradicionais responderam de forma agressiva, levando a uma guerra de preços que reduziu a rentabilidade de todas as empresas no setor. Além disso, nossa empresa-exemplo, por não ter respondido a tempo, acabou por perder participação de mercado.

Vamos supor que, no momento do planejamento estratégico, a nossa empresa disponha de informações razoáveis sobre o mercado. Ela precisa decidir o que fazer. Ao longo das discussões, surgem três opções estratégicas preferidas:
1.    Reduzir preços também, para recuperar o market-share perdido, reduzindo custos ao mesmo tempo para preservar a rentabilidade;
2.    Investir na diferenciação da oferta da empresa, sem alterar significativamente os preços, com foco em fidelização dos clientes atuais e expansão da base;
3.    Entrar em novos segmentos de mercado, pouco explorados pelos concorrentes.

Como decidir entre estas opções? Na falta de informação completa e confiável sobre as forças e fraquezas internas da organização, é muito difícil.

Seria necessário responder a perguntas como:
•    Temos espaço para reduções significativas de custos? Quanto custam nossos processos de negócio? Eles podem ser racionalizados de modo a gerar reduções significativas de custo? Quanto vai custar para reduzirmos os custos de nossos processos? Isso pode ser feito em um horizonte de tempo viável?
•    Se optarmos pela estratégia de diferenciação, quais os nossos atuais processos de negócio que precisam ser revistos? Os processos, como são hoje, dão conta de sustentar esta estratégia? Se tivermos que mudar esses processos, quais os impactos? Que processos relacionados precisariam ser revistos? Nossos Sistemas de Informação atuais dão conta dos novos processos necessários? Vamos precisar de novos sistemas? Podemos alterar os atuais? Quanto tempo vai levar e quanto vai custar? Nosso time de colaboradores possui as competências necessárias para sustentar esta nova estratégia? Podem ser capacitados? Quanto tempo vai levar e quanto vai custar?
•    Da mesma forma, se optarmos por atacar novos segmentos de mercado, de que novos processos, sistemas e competências precisaremos?

Esses são apenas alguns exemplos de perguntas cujas respostas são essenciais para a tomada de decisão informada em um processo de planejamento estratégico. Mas essas respostas, muitas vezes, estão escondidas em lugares que os executivos planejadores não sabem nem mesmo por onde começar a procurar.

Arquitetura Corporativa
A Arquitetura Corporativa procura dar respostas a essas perguntas. Na verdade, não se trata de um conceito especialmente complexo. Ao contrário, conceitualmente é bastante simples.

O dono de uma casa precisa ter as plantas da Arquitetura de sua casa disponíveis e atualizadas para poder fazer reformas sem “furar canos”, “tomar choques” ou, o que é pior, atingir um pilar estrutural ao derrubar uma parede.

Os executivos de uma empresa, da mesma forma, precisam de um conjunto de “plantas” que descreva a empresa para que possam empreender “reformas” sabendo antecipadamente o que deve ser feito e os custos e riscos envolvidos.

Infelizmente, essas “plantas” da organização normalmente não estão disponíveis. Pior ainda, “reformar” a empresa é uma necessidade muito mais freqüente do que reformar uma casa, e a empresa típica está sempre com algum tipo de “reforma” em curso, seja para atender mudanças na estratégia, na legislação ou mesmo de necessidades puramente operacionais. Essas “reformas” incluem mudanças em metas, nos processos de negócio, nas estruturas organizacionais, em sistemas de informação e na infra-estrutura física da empresa (reformas stricto sensu).

A Arquitetura Corporativa se propõe desenhar e manter disponíveis e atualizadas essas plantas, de modo que o time executivo possa tomar decisões baseadas em informação consistente, sendo capaz de avaliar custos, prazos, riscos e outros tipos de impactos ao empreender mudanças na estratégia, por exemplo.

A Arquitetura Corporativa nada mais é, portanto, do que um conjunto de modelos descritivos da organização (“plantas”) armazenados em um repositório centralizado, acompanhado de estruturas organizacionais e processos que garantam que esta informação se mantém sempre atualizada e relevante.

Nos próximos artigos, detalharemos diversos aspectos relacionados com a Arquitetura Corporativa, como as diferentes formas em que a informação pode ser armazenada, como iniciar um projeto para implantação de Arquitetura Corporativa, sua relação com a Governança Corporativa e a Governança de TI, entre outros assuntos.

02-09-2008

Referência:
ZACHMAN, John, A framework for information systems architecture, IBM Systems Journal, Vol. 26 No. 3, 1987.

Gestão do Conhecimento e Cultura Organizacional: Uma Lição da II Guerra

Gestão do Conhecimento e Cultura Organizacional: Uma Lição da II Guerra


Por Atila Belloquim


A História da Segunda Guerra Mundial nos dá um exemplo da diferença que pode fazer a aplicação de alguns conceitos, hoje bem conhecidos, da Gestão de Conhecimentos, e a atenção aos aspectos culturais da organização.

Quem se interessa por esse período histórico e, especialmente, pela Guerra Aérea e Aeronaval, tanto na Europa quanto no Pacífico, espanta-se, a principio, ao ver o desempenho relativo dos pilotos de caça norte-americanos, comparados aos japoneses e alemães. Esses últimos parecem ter tido desempenho muito melhor, apesar de terem perdido a guerra.

Um “Ás” era definido, por cada Força Aérea, como um piloto de caça que tivesse obtido um número de “vitórias” superior a um nível pré-determinado. Uma “vitória” é a derrubada confirmada de um avião inimigo de qualquer tipo (um bombardeiro, um transporte, outro caça ou qualquer outra aeronave militar).

Quando se lê a respeito dos ases alemães e japoneses, é freqüente vermos referências a números de vitórias superiores a 200 ou 300. Já um piloto americano era considerado um “ás” com 10 vitórias. Olhando assim, parece ser um ás meio “fajuto”, não é?

O fato é que os americanos adotaram uma política muito inteligente, que era a de condecorar o piloto como ás quando ele obtivesse sua décima vitória, e enviá-lo de volta aos Estados Unidos para ser instrutor de combate aéreo. Promoção, medalha, fanfarra, festa, tapinhas nas costas e “go back home”. Os pilotos nem sempre gostavam disso, pois, para muitos, isso era como uma “aposentadoria compulsória”, afastando-os das glórias do combate no front.

Essa política, porém, mostrou-se extremamente acertada, a ponto de Matsuo Fuchida - o comandante das forças japonesas que atacaram Pearl Harbor e da força aérea embarcada nos porta-aviões japoneses até a batalha de Midway - dizer que esta foi uma das razões para a derrota do Japão na Guerra. O livro de Fuchida serviu de base para o roteiro do clássico de Hollywood “Midway”, com Charlton Heston. O próprio Fuchida aparece como personagem no filme.

O Japão havia adotado o que Fuchida chamou de “Política dos Ases”, em que os pilotos mais experientes e habilidosos eram mantidos nos porta-aviões, combatendo até a morte. Como resultado, não havia instrutores experientes no Japão para treinar novos pilotos. No fim da Guerra, havia pouquíssimos pilotos japoneses experientes. Os pilotos Kamikase, aliás, tinham um treinamento de vôo de duas semanas, e eram os piores entre os alunos-piloto (os que apresentavam alguma habilidade eram destacados para missões “normais” de combate).

Assim, os EUA deram um exemplo de “transformação do conhecimento tácito em tácito”, para usar o modelo de Nonaka e Takeuchi (1997). Segundo Polany (1966) o conhecimento pode ser tácito ou explícito. O conhecimento tácito é pessoal, específico ao contexto e difícil de ser formulado e comunicado. Uma ótima cozinheira pode não ser capaz de explicar formalmente o que é que faz com que seus quitutes sejam tão bons. O conhecimento explícito, por sua vez, é codificado, transmissível em linguagem formal e sistemática. Pode, por exemplo, ser adquirido em livros. Para Nonaka e Takeuchi, os dois tipos de conhecimento podem ser “convertidos”, ou transmitidos, um para outro, de modos distintos. A conversão de tácito para tácito é chamada pelos autores de “socialização”, que é um processo de compartilhamento de experiências. É exatamente o caso aqui, o ensino prático de pilotagem de aviões.

A instrução de vôo é um exemplo límpido deste tipo de transmissão de conhecimentos. Por mais que o aluno-piloto leia manuais, aprende a voar voando. E o instrutor é essencial nesse processo, quando a demonstração e a imitação são os fatores mais importantes.

Nada substitui um instrutor experiente em combate numa situação dessas. O fato de os novos caçadores americanos terem sido ensinados por pilotos de caça excepcionais pode ter feito uma enorme diferença na Guerra.

Não deixa de ser irônico que tenham sido dois autores japoneses a destacar o bom gerenciamento do conhecimento tácito como a causa principal da superioridade de algumas empresas japonesas sobre americanas, em termos de inovação, uma vez que o episódio que estamos considerando trata justamente da superioridade americana nessa empreitada sobre os japoneses, na Guerra, através exatamente do conhecimento tácito.

Cultura

Não seria exagerado afirmar que as Culturas Organizacionais das diferentes forças aéreas tiveram influência decisiva na política para com os ases e, portanto, nos seus resultados durante a guerra.

A Cultura, entre outras coisas, diz respeito às crenças e valores compartilhados pelos membros da organização. Na carreira militar, o “caçador”, ou seja, o piloto de caça, é normalmente visto como um herói solitário e, de fato, é comum que esses pilotos sejam frequentemente individualistas, de forma um pouco paradoxal, já que as Forças Armadas são, essencialmente, um empreendimento baseado do trabalho em equipe.

A Cultura das forças aéreas japonesa e alemã era de forte individualismo, e o “estrelismo” dos ases era incentivado pelos altos escalões. Os ases eram propostos como heróis nacionais e tratados como celebridades, como exemplo para os concidadãos. Havia, inclusive, um incentivo insano à competição interna, em que os pilotos procuravam em primeiro lugar obter mais vitórias do que os demais pilotos do esquadrão, às vezes levando-os a colocar isso acima dos objetivos ou mesmo da segurança da missão.

Na força americana, sem matar totalmente essa característica, havia muito maior atenção aos valores de trabalho em equipe e transmissão de conhecimento e experiência. É claro que existia aí também a competição, mas sua importância era muito menor, e tudo era feito em um clima de camaradagem.

Lições

Este exemplo serve para ilustrar como a Cultura Organizacional pode influenciar esforços de Gestão de Conhecimento nas organizações. É praticamente impossível fazer dar certo um esforço desse tipo se a cultura for, por exemplo, de incentivo ao individualismo e à competição interna. Se minha empresa me incentiva a ver meu colega de trabalho como um concorrente, porque eu pararia o que eu estou fazendo para gastar meu precioso tempo para, ainda por cima, passar para meu concorrente (o colega!) o meu conhecimento?

Quando falo de Gestão do Conhecimento, não me refiro somente a esforços “explícitos” nesse sentido, como, por exemplo, um “Projeto de Portal Corporativa com Ferramentas de Colaboração” (Wiki, por exemplo).  Quase todos os grandes projetos que as empresas estão desenvolvendo hoje, como implantação de CMMI, COBIT, ITIL, PMO e que tais, possuem um imenso componente de Gestão do Conhecimento. Você não pode esperar por um “Projeto de Gestão de Conhecimento” para colocar essas práticas em ação se você estiver implantando, por exemplo, melhoria de processos segundo o CMMI. A definição de um processo puro e simples, por exemplo, não garante seu entendimento e utilização. Novos colaboradores aprendem fazendo e, principalmente, através do exemplo dos colegas mais antigos. Ou seja, socialização do conhecimento. E, sem isso, evidentemente, não teremos ainstitucionalização, requerida pelo modelo.

A Cultura se manifesta em artefatos visíveis. Não basta um belo discurso de incentivo ao compartilhamento do conhecimento. As práticas de Gestão de Pessoas, por exemplo, tem que estar alinhadas com esses valores. Se, por exemplo, os critérios para avaliação de desempenho, promoção e remuneração variável estiverem focados no desempenho individual do colaborador, ele receberá da organização a mensagem de que o discurso é “só pra inglês ver”. Portanto, esforços de Gestão do Conhecimento só dão certo com uma Cultura adequada, que se manifeste em políticas e práticas de Gestão de Pessoas consistentes com ela. Ao escolher alguém para promoção, a empresa tem que levar em conta o quanto ele se dedica a compartilhar seus conhecimentos com os colegas. Na hora de conceder bônus, o tempo e o esforço dedicados a ensinar os colegas têm que ser levados em conta.

Ases solitários e instrutores

Outra lição importante aqui deveria ser absorvida pelas empresas. Quando o conhecimento tácito está envolvido, é muito mais produtivo que os trabalhadores mais experientes gastem seu tempo instruindo os mais novos do que apenas executando suas tarefas. Um Desenvolvedor experiente, por exemplo, pode aumentar a qualidade do desenvolvimento de software em todas as equipes de uma empresa, caso seja destacado para o “peer review” do trabalho de todos. O resultado final será o aumento da qualidade no trabalho das diversas equipes. Caso esteexpert seja mantido a cuidar apenas do “seu sistema”, este poderá alcançar enorme qualidade, mas apenas ele. Poderemos ter um software fantástico junto a todos os outros de qualidade medíocre. Caso o expert seja destacado para revisar o trabalho dos outros, poderemos ter todas as equipes produzindo software de boa qualidade, mesmo que nenhum deles seja excepcional. Na média, o resultado é sempre melhor. Mas é difícil encontrar empresas dispostas a abrir mão do trabalho especializado de um expert, transformando-o em formador das novas gerações de trabalhadores. A “Política dos Ases” japonesa, como se vê, fez escola.

1-11-2002

Revisado e ampliado em 18-9-2007

 

Referências:

NONAKA, I. e Takeuchi, H. Criação de Conhecimento na Empresa. São Paulo, Campus,1997.

POLANY, M. Personal Knowledge. Chicago, University of Chicago Press, 1958.

FUCHIDA, M. e Okumiya, M. Midway. São Paulo, Flamboyant, 1967

Analistas de Processos de Negócio: 5 Competências Fundamentais

Analistas de Processos de Negócio: 5 Competências Fundamentais


Por Atila Belloquim


A comunicação e o alinhamento entre as áreas de negócios e de TI sempre foram problemáticos. Hoje, porém, a questão se tornou crítica como nunca, tanto por conta da necessidade crescente de agilidade no uso dos recursos de TI quanto pela forte tendência de terceirização das atividades de desenvolvimento e manutenção de sistemas.

Quando uma empresa terceiriza seu desenvolvimento, em que pesem as vantagens que o outsourcing possa trazer, cria-se uma necessidade crítica de que o trabalho a ser feito esteja perfeitamente entendido e documentado. Caso contrário, na medida em que o desenvolvedor não conhece a fundo nem a cultura nem o negócio da empresa, e, além disso, freqüentemente está afastado inclusive fisicamente dos usuários do sistema, erros de entendimento tendem a demorar mais para serem descobertos e, portanto, a custarem mais para serem corrigidos, tanto em termos financeiros quanto de tempo.

Essa é uma das circunstâncias que faz com que o papel de Analista ou Gerente de Processos de Negócio se torne tão importante. Embora o papel possa ter nomes diferentes em cada empresa, estamos tratando daquela pessoa cuja função é fazer a “ponte” entre os usuários de TI, ou seja, o pessoal de negócios, e a TI propriamente dita, no papel de provedora de soluções tecnológicas e de sistemas, independentemente de o desenvolvimento ser feito “em casa” ou por terceiros.

Infelizmente, temos observado que é muito freqüente que os gerentes de processos (ou analistas de negócios) apresentem lacunas significativas em sua formação e, muitas vezes, nas habilidades necessárias para esse papel importantíssimo. Por essa razão, vamos listar aqui cinco competências fundamentais para as pessoas que desempenham este papel, em ordem decrescente (em nossa opinião) de importância.

Profundo conhecimento do negócio. Este é o ponto mais importante. O analista de processos de negócio é o receptor das demandas dos profissionais de negócio da empresa, os quais frequentemente possuem pouco conhecimento de tecnologia e, quase sempre, dispõem de pouco tempo para explicar o que precisam. Ao conhecer em profundidade o negócio, o analista de processos é capaz de identificar rapidamente a necessidade do usuário, mesmo quanto ela não é claramente articulada. Além disso, ele é capaz de propor soluções que podem não ter ocorrido ao usuário, bem como avaliar imediatamente os impactos daquilo que está sendo pedido em outros processos de negócio da organização.

Formação ampla. Muitas vezes o analista de processos de negócio é oriundo da área de desenvolvimento de sistemas e, com freqüência, essa é a única formação específica e experiência de que dispõe. Para ser capaz de se entender com seus usuários, porém, isso não basta. Ele precisa ter um entendimento claro do funcionamento geral de uma empresa, com conhecimentos de marketing, finanças, assuntos regulatórios e de governança. Precisa também ter noções de microeconomia, para ser capaz de entender o contexto econômico em que opera a empresa. Por fim, precisa ter noções de sociologia e ciência política, para ser capaz de entender a cultura organizacional da empresa e a forma como se dão nela as relações de poder. Sem este conhecimento, o profissional corre o risco de propor soluções que, embora tecnicamente perfeitas, causem grandes problemas e resistências por serem, eventualmente, incompatíveis com a cultura da empresa ou por não darem conta de relações de poder que podem inviabilizar o projeto.

Habilidades interpessoais e pensamento sistêmico. O analista de processos de negócio precisa ser capaz de se relacionar bem com pessoas de diferentes formações, estilos e mentalidade, especialmente na medida em que é sua função “fazer a ponte” entre as diversas áreas de negócio e as áreas de tecnologia. Ou seja, precisa lidar com pessoas de estilos muito diferentes. Precisa saber ouvir, ser capaz de compreender a comunicação não-verbal, distinguir necessidades de desejos, negociar e assumir compromissos. Além disso, precisa ter pensamento sistêmico, de modo a prever as interações entre o que está sendo pedido e as demais necessidades da empresa.

Domínio de técnicas. Além de todas as competências já citadas, é claro que este profissional precisa ainda dominar as diversas técnicas necessárias para entender, modelar, analisar e documentar processos de negócio e requisitos de sistemas. Precisa ser fluente nos métodos, linguagens e notações usados na empresa, sejam eles padrões de mercado – como o BPMN, IDEF ou a UML – sejam específicos da organização.

Visão pragmática da tecnologia. Por fim, é fundamental que o gerente de processos tenha uma ampla compreensão das possibilidades oferecidas pela tecnologia disponível, seja internamente, seja no mercado. Sem precisar ser um expert tecnológico, ele deve entender o que existe dentro e fora da empresa e como essas tecnologias podem ser empregadas para resolver os problemas de seus clientes internos. Deve estar “antenado” com as novidades tecnológicas de modo a ser capaz de sugerir a adoção de novas tecnologias, sem perder de vista a forma como tais novidades podem ser integradas ao ambiente tecnológico atual da organização. Deve também ser inovador no uso de tecnologias já bem estabelecidas na organização, criando novas soluções para os problemas que surgem sem necessariamente ter que recorrer a tecnologias de ponta.

Ainda é muito freqüente vermos pessoas dedicadas serem “jogadas aos leões” ao assumirem esse papel, sem estarem totalmente preparadas para tanto. Isto é especialmente verdadeiro quando essas pessoas vêm da área de TI, têm formação tecnológica e passaram a vida trabalhando como desenvolvedores. Embora este seja o caso mais comum, as empresas precisam ter claro que não basta mudar a descrição de cargo do colaborador. É fundamental que ele receba a formação necessária, cobrindo as lacunas que possa ter. De outro modo, o risco de problemas de comunicação, atritos e mesmo desmotivação por parte deles é imenso, o que fará da empresa a primeira e mais prejudicada.

 

Copyright © 2007 Atila Belloquim

Este artigo pode ser reproduzido no todo ou em parte, desde que citada a fonte e acompanhado do endereço eletrônico www.atilabelloquim.com.br.

 

PMBOK ® não basta: Entendendo como a Cultura e o Poder afetam os projetos.

PMBOK ® não basta: Entendendo como a Cultura e o Poder afetam os projetos.


Por Átila Belloquim


O fracasso de um projeto raramente se deve a problemas técnicos. A popularização de modelos e referências como o Guia PMBOK®, o CMMI® e o RUP® foram fundamentais para disseminar as melhores práticas de gestão de projetos, minimizando as ocorrências de erros grosseiros na sua condução.

Entretanto, referências como o Guia PMBOK® concentram-se fortemente nos aspectos técnicos dos projetos. Os aspectos humanos, sociais e comportamentais do projeto não recebem ênfase proporcional à criticidade que têm para o sucesso do projeto. Esses aspectos são muitas vezes chamados de aspectos “soft”, o que não deixa de ser irônico, já que são quase sempre os mais difíceis de lidar. Podemos imaginar, porém, que o “soft” refere-se ao fato de que esses aspectos são mais ambíguos, sem contornos muito bem definidos, em contraste aos aspectos “hard” que, sendo mais técnicos, possuem fronteiras bem delimitadas e, com freqüência apresentam “resposta certa”.

Os dois aspectos “soft” mais importantes em qualquer projeto são: Poder e Cultura.

Embora existam inúmeras definições para esses termos, podemos dizer que Poder, neste contexto, diz respeito à capacidade que alguém possui de fazer com que outras pessoas atuem da forma como ele, o detentor do Poder, deseja (essa é, essencialmente, a definição de Max Weber). Cultura, por outro lado, pode ser definida como o conjunto de crenças e valores compartilhados pelos membros de um grupo (por exemplo, os colaboradores da organização) que orientam o pensamento e a ação dos mesmos.

A Cultura Organizacional tem profunda relação com os projetos conduzidos na organização. Por um lado, a cultura impõe limites aos projetos. Alguns projetos podem ter seu escopo severamente restringido pela cultura e, no limite, serem pura e simplesmente inviáveis. Projetos de Gestão de Conhecimento, por exemplo, em que o compartilhamento do conhecimento é fundamental, tem baixíssima probabilidade de vingar em ambientes com cultura altamente competitiva e estrutura autoritária. As pessoas simplesmente não vêem por que deveriam compartilhar o conhecimento que lhes dá vantagens competitivas diante dos colegas ou poder de negociação diante da chefia.

Por outro lado, todo projeto, a não ser os mais triviais, causa impacto na cultura. Isso porque os projetos tipicamente levam a mudanças na forma de trabalho das pessoas, o que basta para modificar aspectos da cultura. Em certos casos, o objetivo do projeto é justamente provocar a mudança cultural, como é o caso na maioria dos projetos de Gestão de Pessoas. Nestes casos, o que se procura é que a mudança cultural leve a mudanças no comportamento das pessoas da organização.

Além da Cultura, é evidente que a questão do Poder também está muito presente. A maioria dos projetos envolve mudanças em processos de trabalho e no acesso à informação. Assim, cada projeto tem potencialmente dentro de si interesses conflitantes. A informação que se torna disponível para um grupo maior de pessoas transfere poder do grupo que originalmente a detinha, por exemplo.

De modo geral, se tomarmos como referência o Guia PMBOK®, veremos que esses assuntos são tratados muito superficialmente, sendo que as maiores referências concentram-se quando se fala em análise de stakeholders na área de conhecimento de Gestão de Riscos, com algumas referências adicionais nas áreas de Comunicação e Gestão de Pessoas. Essas poucas referências podem, erradamente, dar a impressão de que são assuntos pouco importantes. No mundo real, há situações políticas que tornam um projeto sem nenhuma possibilidade de sucesso, havendo mesmo casos em que projetos são criados com o objetivo específico (ainda que velado) de dar errado (como exercício, o leitor pode imaginar situações em que isso pode acontecer). Numa situação dessas, não há PMP  que salve o projeto, por mais competente que seja na aplicação das técnicas de gestão de projetos que aprendeu.

É claro que todo gerente de projetos experiente e bem sucedido sabe de tudo isso. O problema é que raramente essas questões são tratadas de forma sistemática. As metodologias de gestão de projetos tipicamente não vão além de uma análise de stakeholders superficial no momento do planejamento.  Assim, o sucesso dos projetos acaba dependendo mais das habilidades políticas e sociais do gerente do projeto do que da aplicação das “melhores práticas” técnicas. Além disso, gerentes de projetos jovens e com pouca experiência podem levar anos “tomando na cabeça” até aprenderem (isso se não forem antes expelidos da profissão…)

É, portanto, necessária uma abordagem explícita e sistemática para essas questões. As metodologias de gestão de projetos (e os modelos e guias) precisam ser aprimorados nesse sentido. Mas, mais importante ainda, é fundamental que os novos (e também os não tão novos…) gerentes de projeto sejam capacitados a lidar com esses assuntos. Um gerente de projetos em cuja formação não estejam presentes os aspectos de Sociologia e Ciência Política relevantes à situação possui uma grave deficiência em sua capacitação que poderá ser, inclusive, o diferencial entre os gerentes de sucesso e os demais. Até porque o domínio de técnicas envolve conhecimentos e habilidades que, muito em breve, serão commodities.

 

Copyright © 2007 Atila Belloquim.

Este artigo pode ser reproduzido no todo ou em parte, desde que citada a fonte eacompanhado do endereço eletrônico www.atilabelloquim.com.br.