Você sabe o que são as licenças Creative Commons?

No post anterior, é possível que você tenha reparado neste ícone:

by-nc-sa-20

Dependendo da curiosidade, você pode também ter percebido que o ícone está associado a este link:

http://creativecommons.org/licenses/by-nc-sa/2.5/br/

De que se trata?

Trata-se de algo muito interessante.

Suponha que você tenha criado alguma coisa: um livro, um artigo, uma pintura, fotografia, música, vídeo, qualquer coisa. Suponha também que você quer dar a maior visibilidade possível à sua obra e não pretende explorá-la comercialmente. Ao criar a obra, você adquiriu automaticamente o copyright sobre ela. Qualquer pessoa que quiser usar sua obra tem que obter sua autorização expressa.

Ora, muita gente acha, nesses tempos de open source, que o copyright é restritivo demais. Vou dar um exemplo concreto e pessoal. Tenho vários de meus artigos publicados aqui no site. Ao final de cada artigo, eu sempre inclui uma frase tal como “Todos os direitos reservados. Este artigo pode ser reproduzido desde que citada a fonte (…)” etc. Muita gente faz isso há um bom tempo. Meus artigos estão reproduzidos em alguns sites sem que eu tenha sido consultado. Ótimo! Não quero ter que aprovar por escrito toda vez que alguém citar um artigo meu.

O Creative Commons nasceu para dar validade jurídica a este tipo de compartilhamento. Em vez de “Todos os direitos reservados”, temos “Alguns direitos reservados”, de acordo com a legislação de Direitos Autorais dos países para os quais a licença já foi adaptada. Isso facilicclogolargeta muito a divulgação do trabalho de qualquer um de nós que não seja mundialmente famoso.

Mais um exemplo concreto, agora sobre alguém que não usa licenças Creative Commons.

Eu quis adicionar ao post anterior uma imagem de Escher. Fui ao site e descobri que não há modo legal de eu ilustrar um post usando uma imagem dele, pois tenho que contar toda a história de minha vida para talvez conseguir obter uma licença por escrito:

Copyright

International Copyright laws protect all of the work of M.C. Escher. Any reproduction of his work, including downloading, is prohibited without the express written permission of the copyright holder. Requests for reproduction should be directed to Cordon Art’s copyright department.

If you want to use any of the work of M.C. Escher as illustration in a book, magazine, an advertisement campaign, brochure, or on the Internet,

you may fill in this form

or send your request to our copyright department at copyright@mcescher.com with as much background information as possible. (…)

Resultado? Muito menos gente conhecendo o fantástico trabalho de Escher. Ou, ao contrário, a republicação sem licença em milhares do locais na internet (veja no Google images).

Para que proibir, se não é possível controlar? Quem é que vai atrás de cada blog ou site que já publicou umas dessas fotos?

Seria muito mais inteligente se os detentores dos direitos sobre a obra de Escher liberassem, para fins específicos, um conjunto de fotos de trabalhos de Escher, usando para isso uma licença Creative Commons.

Saiba mais sobre o assunto no site do Creative Commons e na página em português.

Os 3 mal-estares do Planejamento Estratégico

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 transformá-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.

Uma Lição de Gestão do Conhecimento da Segunda Guerra Mundial

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 a institucionalizaçã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 este expert 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.

Publicado originalmente em 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

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

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

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. 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 se concentram 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.

Entrevista com Watts Humphrey

O modelo CMM de qualidade de software, apresentado na edição de Março da DevMag, tem um pai. Líder da equipe que criou e divulgou o modelo, Watts Humphrey é hoje um dos mais respeitados pregadores da qualidade de software. Sua enorme experiência no gerenciamento de projetos de Engenharia de Hardware e Software, especialmente na IBM, deu consistência e foco prático ao modelo. Hoje estudando a aplicação dos conceitos do CMM ao desenvolvedor individual e às pequenas equipes de desenvolvimento, Humphrey mostra seu espírito de pesquisador e inovador. Presente ao Software Engineering Process Group Conference ´97, um evento de qualidade do processo de software organizado pelo SEI, nosso colaborador Átila Belloquim teve a oportunidade de entrevistar com exclusividade Watts Humphrey, trazendo ao desenvolvedor brasileiro suas idéias mais recentes.

Como lhe ocorreu, pessoalmente e como grupo no SEI, a necessidade de um modelo estruturado (o CMM) para a melhoria do processo de software?

Veio de minha própria experiência. Trabalhei na IBM por muitos anos e, num determinado momento, fiquei responsável por todo o software da IBM. Eu tinha 4000 engenheiros desenvolvendo os grandes sistemas operacionais /360. Era óbvio na ocasião que havia sérios problemas gerenciais. Eu já tinha trabalhado por muitos anos como engenheiro construindo hardware, e minha experiência era que era necessário ter cronogramas, ter um bom sistema gerencial para conduzir projetos, ou você nunca entregaria as coisas em tempo. Assim, quando assumi a área de software da IBM, tratei de por em prática estes mesmos princípios. Eu descobri que nenhum dos 15 laboratórios sob minha responsabilidade fazia cronogramas. Eles simplesmente tentavam produzir código o mais rápido possível. Era muito improdutivo. É como tentar produzir algum produto sem nenhuma estrutura de planejamento, sem ninguém para adquirir matéria-prima etc. Um caos total. Os engenheiros concordavam que eles deveriam ter cronogramas e planos, mas eles diziam que não o faziam porque não tinham tempo. Eu concluí que era um problema que não era culpa deles, mas minha e de meu predecessor. Nós permitíamos que eles prosseguissem desenvolvendo programas sem nenhuma estrutura de planejamento. Então eu decidi -depois de obter a concordância do topo da Companhia- parar todo trabalho que não tivesse planos. Nós não anunciaríamos produtos, não entregaríamos produtos, não entraríamos em projetos a menos que tivessem planos. E ponto final. Assim, eu fiz disto algo essencial: não havia modo de alguém produzir código se não tivesse um plano! Isto limpou a situação em poucos meses. Foi impressionante! Paramos tudo e fizemos os engenheiros-chefes sentarem-se e fazerem planos. Os planos foram feitos e cumpridos por alguns meses. A partir daí, anunciamos os prazos de entrega e não estouramos nenhum prazo por dois anos e meio. Nem um!

Ficou claro para mim que o requisito básico do gerenciamento sólido são bons planos. Também ficou claro que nada mais poderia ser feito pelo processo de software antes que isto estivesse feito. A partir daí, continuamos aprendendo sobre os outros problemas e modos de resolvê-los. E acabou ficando claro para mim, depois de muito trabalho duro, que precisa haver um critério básico sobre o que constitui um trabalho de qualidade.

Quando me aposentei na IBM, eu tinha que decidir o que eu faria pelo resto da minha vida. Eu não queria simplesmente sentar na praia. Então eu decidi que eu iria me comprometer a tentar mudar o modo como se faz software. Por isso, fui trabalhar no SEI, e é o que eu faço até hoje.

Uma das primeiras coisas que a Força Aérea nos perguntava no SEI era: como decidir se um fornecedor de software é melhor do que o outro, em uma concorrência? Fui colocado em uma equipe que tinha por objetivo avaliar não os produtos, mas o processo. As avaliações antes eram feitas analisando-se as propostas. Eu disse então: Não! queremos olhar o processo. Se você quer comprar chips, você não olha os chips, olha a fábrica. Tínhamos que fazer o mesmo com software. Mas olhar o quê? Não foi surpresa descobrir que a primeira coisa a olhar era a existência de um sistema básico de planejamento. Assim, fomos considerando o que deveria ser olhado em seguida, e assim por diante. Foi assim que acabamos por estruturar isto tudo em níveis, pois percebemos que as organizações não podem melhorar tudo ao mesmo tempo. Este é um dos problemas de muitos dos programas de qualidade: eles são “planos”, você tem que fazer tudo ao mesmo tempo. Mas as empresas não funcionam assim. Uma empresa tem um problema que, se não for resolvido, não há como ir para a frente. São como barreiras em uma estrada. Se você está parado em uma barreira, você não se preocupa com o que há mais para a frente. Você tem que superar esta barreira primeiro, para depois se preocupar com a próxima. Portanto, a questão era: em que ordem as barreiras aparecem, qual é a ordem certa para a remoção de barreiras? Quais os problemas que você enfrentará que lhe causarão mais dor de cabeça no início? É basicamente o planejamento, o comprometimento, este tipo de coisa fundamental. Se isto não estiver resolvido, todas as outras coisas não farão a menor diferença. Você pode tentar usar ferramentas avançadas, inspeções etc., mas se o sistema básico de planejamento não estiver lá, nada mais vai funcionar direito.

É uma espécie de Caminho Crítico…

Exato. São passos seqüenciais. É como aprender Matemática. Se você não aprender Aritmética, não adianta brigar com a Álgebra. Até que você domine a Álgebra, não perca seu tempo com Cálculo. Se você não pode lidar com o Cálculo, esqueça a Mecânica Quântica. Assim fomos organizando os níveis. O mais radical foi definir os níveis 4 e 5, pois não tínhamos visto estes níveis! Mas nosso julgamento parece ter sido confirmado pelas empresas que chegaram a estes níveis. Havia uma lógica por trás disto.

O CMM está se tornando um modelo bastante popular para a melhoria do processo de software e está chegando agora à sua segunda versão. O Sr. acredita que esta estrutura continuará sendo a mesma ao longo do tempo, ou existe a possibilidade de grandes mudanças?

É difícil dizer. No momento, não vejo nada que possa precisar de grandes mudanças, mas a tecnologia pode surpreender. Quando todo mundo estiver nos níveis 3, 4 ou 5, podemos descobrir que existem outras estruturas para pensar. Eu não ficaria surpreso. Mas ao menos por enquanto a estrutura parece ser sólida e funcionar muito bem. Mas é importante mantermo-nos flexíveis. Em 10, 15 ou 20 anos podemos descobrir necessidades completamente diferentes. É difícil prever, mas ao menos para o futuro visível não vejo nenhuma mudança fundamental.

O Sr. não acha que o CMM é muito pesado para aplicações cada vez mais construídas a partir de componentes em vez de a partir do nada?

Não. Acredito que o CMM é baseado numa estrutura gerencial, praticamente independente da tecnologia. A necessidade de controle, de planejamento, de qualidade, de gerenciamento de contratos são as peças do CMM. Você pode juntar partes e ter um problema de qualidade, mesmo que as partes em si sejam de alta qualidade. A estrutura gerencial faz sentido mesmo se você não escrever nenhum código. Na verdade, as pessoas têm percebido que simplesmente trocando a palavra “software” por outra, elas podem usar a estrutura do CMM para hardware ou qualquer outra coisa. Os princípios são amplamente aplicáveis, quase não importa do se trata.

Existem vários novos modelos alternativos ao CMM para avaliar a maturidade do processo de software de uma organização, como o SPICE. O que o Sr. acredita que acontecerá: estes modelos irão competir, ser integrados, ou o quê?

Bem, eu acredito que existam algumas diferenças fundamentais entre o CMM e o Spice e estes outros métodos. Sempre fiquei frustrado pela quantidade destes outros métodos, porque me parecem um reflexo deste tipo de “doença” dos programadores. Quando a comunidade de software é confrontada com um problema, ela corre e inventa algo novo. É por isso que temos literalmente milhares de linguagens de programação. Todo mundo tem que ter a sua própria nova linguagem! A idéia de construir sobre o trabalho de outras pessoas e avançar a partir daí, parece que as pessoas simplesmente não querem fazê-lo  quando estão na comunidade de software, por alguma razão. Eles querem construir coisas novas, começar tudo de novo e fazer do modo deles. E isto infelizmente é uma grande dose de esforço desperdiçado, reproduzindo tudo o que já foi feito anteriormente. Levamos anos para chegar onde estamos, e parece que as pessoas não querem aproveitar isso. Criam cada vez novos métodos que têm como principal conseqüência confundir as pessoas, que acabam perdendo de vista o fato de que o propósito desta coisa toda não é ter um modo cada vez mais belo de descrever software. O propósito disto tudo é focar em como melhorar o modo como o software é desenvolvido. E uma parte muito substancial disto é justamente encontrar um modo melhor de realizar a comunicação entre gerentes e engenheiros de software, isto é, como os gerentes podem entender o que os engenheiros estão fazendo, como os engenheiros podem entender melhor o que o gerente quer, como pôr juntas todas estas coisas e fazê-las funcionar. Quando eu vejo descrições de 30 páginas sobre por que isso é assim, quais são as distinções entre isso e aquilo, etc, fico frustrado. O público destes métodos, os gerentes e engenheiros não entendem as diferenças, não vêem porquê  se discute a respeito disto, e eu também não! É uma perda de tempo. As pessoas não aprenderam com o que fizemos. Pegam parte do nosso material e mudam, querem obter descrições muito mais precisas do processo e vêm perdendo anos tentando reproduzir aquilo que nós já fizemos! Começamos a trabalhar no modelo de maturidade há 15 anos, fizemos a primeira avaliação na IBM em 1983. São anos e anos de experiência e as pessoas querem vir com suas próprias novidades sem ao menos sentar e conversar conosco! Vão inventando suas coisas com base em algo que leram e acabam fazendo a coisa errada. Sei que se pode imaginar coisas inteligentes, e que há pessoas brilhantes e que às vezes aparecem coisas boas. Mas fundamentalmente é uma perda de tempo, um desperdício de esforços. A multiplicidade de métodos confunde as pessoas, que não sabem se devem usa o CMM ou o Spice ou isto ou aquilo. Infelizmente, é o que estão fazendo, mas não vou combatê-los.

O problema é que a maioria destes métodos é baseado em medições, procuram obter uma medida precisa, o que a empresa é exatamente. Acontece que, na verdade, isto não importa! O CMM não é baseado em medição, é baseado em mudança, em como você consegue fazer a organização realmente mudar! O foco de nosso esforço não está em obter uma medida precisa da organização. É claro que ajuda ter uma medida aproximada, mas a questão é que você está procurando fazer com que a empresa entenda o que acontece. O CMM é uma ferramenta para ajudar a entender as organizações e motivá-las a melhorar. Não é uma medida precisa, não tem toda esta objetividade. O problema com o Spice e outros grupos é que estão focados em como obter melhores medidas.

E não mostram os caminhos para mudar e melhorar…

Bem, eles dão. Você pode usá-los, e eles ajudam. Não estou dizendo que eles sejam ruins, de modo algum! Eles têm algumas coisas boas e podem ajudar, mas o que eles tentam fazer é obter um modo muito mais preciso de descrever as organizações, o que você acaba descobrindo que, na verdade, não importa! Está-se indo às organizações para medi-las com precisão, quando o problema é motivar as pessoas a melhorar. Se você esperar três semanas, sua organização estará diferente do que você mediu. Organizações são muito dinâmicas. Não adianta tomas medidas até à terceira casa decimal. Se você for por um caminho um pouco diferente, se você fala com as pessoas num dia diferente da semana ou se você entrevista algumas pessoas diferentes, você obtém uma medida totalmente diferente. Organizações são muito complicadas. Todas estas medidas são aproximações muito cruas do que realmente está acontecendo. Nós descobrimos que em cada avaliação nós não estamos atrás de números e medidas. Nós as obtemos porque as pessoas gostariam de ter uma idéia, mas o que estamos realmente atrás é de compreender a ética, a cultura, o que motiva as pessoas, como elas se comunicam, qual é a sua linguagem, este tipo de coisa. O CMM o ajuda a entender isto. Mas se você não conseguir compreender estas coisas, as medidas que colher não servirão para nada. Assim é. Outras pessoas continuarão criando seus próprios métodos. Ter 3 ou 4 métodos competindo é como ter 3 ou 4 linguagens diferentes ao mesmo tempo. Você terá que ter ferramentas suportando cada uma, diferentes pessoas para dar suporte a cada uma etc. O problema real que nós temos não é como obter uma medida mais precisa, mas como chamar a atenção da gerência para mudar, para melhorar. Cada vez que surge um novo método, fica mais difícil chamar a atenção da gerência, pois ela fica confusa. Isto apenas dá desculpas para que as pessoas não faças o que precisa ser feito. É triste.

O Sr. desviou sua atenção do CMM para o PSP (Personal Software Process) nos últimos anos. Por quê o Sr. decidiu seguir este novo caminho?

O CMM estava em seu caminho, estava indo bem. Na verdade, era importante que eu saísse do caminho. Um dos problemas que havia no trabalho do CMM era que, se eu estivesse em uma reunião e estivesse havendo alguma discussão, no momento em que eu falasse algo a discussão acabava. “Está gravado em pedra, o Grande Homem falou…”, você sabe (risos). Portanto, eu estava barrando o progresso. Eu precisava sair do caminho para que as pessoas pudessem pensar, mover-se, fazer progresso por conta própria, e eles o fizeram muito bem. Uma segunda razão, muito importante, era que muitas organizações pequenas não viam como o CMM pudesse aplicar-se a elas. Como o CMM se aplica a empresas de 18 pessoas, ou a times de 4 pessoas etc. Um grande número de pequenas organizações produzem muito software. Nós tentamos convencê-los de que o CMM se aplicava a eles, mas não conseguimos. Durante anos eu me interessei pela idéia de aplicar processos ao trabalho pessoal. Assim, quando sai do projeto do CMM pude mudar-me para Florida e começar a pesquisar sobre o Processo Pessoal, usando-o eu mesmo. Escrevi um monte de programas, umas 25.000 linhas de código em C++. Assim, eu não estava abandonando o CMM, mas eu tinha que sair do caminho.

Em que o Sr. está trabalhando no momento?

Estou trabalhando no que chamo de TSP – Team Software Process. Como você pega engenheiros que foram treinados no PSP e faz com que trabalhem juntos para produzir projetos. O que geralmente acontece hoje em dia é que você pega um grupo de engenheiros e lhes diz: “o.k., quero que vocês construam esta coisa”. O problema é que os engenheiros não entendem realmente o que a gerência quer, não entendem a estrutura de pensamento da gerência. Não entendem os objetivos do negócio e como isto está relacionado com eles. Não sabem que processos usar, não sabem que vai fazer o quê, não têm planos. Mas nós esperamos que eles vão e façam o que pedimos. Não é surpresa que eles tenham problemas, briguem e percam um monte de tempo. O TSP parte do princípio que os engenheiros foram treinados no PSP. Pegamos aqueles conhecimentos e então o TSP mostra a eles como usá-los para tocar um projeto em conjunto. O CMM visa construir capacitação organizacional. O PSP está focado em construir a capacitação e as habilidades dos engenheiros. E o TSP está focado em usar isto para construir produtos. Existe 16 grupos usando o TSP no momento, estamos numa fase experimental.

O CMM, o PSP e outros modelos do SEI estão muito relacionados a questões culturais dentro da organização. Com base em sua experiência internacional, o Sr. acredita que este modelo podem ser usados como são em países com culturas diferentes da Norte Americana, ou deveriam eles ser alterados para a cultura específica de cada país?

É claro que existem diferenças culturais. Mas o que me surpreendeu é que eu pude observar culturas tão diversas quanto a Japonesa, Indiana, Européia e Sul-Americana, incluindo variações dentro do mesmo país, e não encontrei diferenças fundamentais. As pessoas no Japão ou na Índia entendem o que eu digo imediatamente. Os desenvolvedores de software encontram problemas quase idênticos em todas as partes do mundo. Existem, é claro, diferenças na estrutura gerencial, na formalidade, etc. Mas os princípios do CMM parecem aplicar-se de forma bastante geral. Afinal, eles são bem básicos. Demming e Juran já tinha demonstrado que os princípio de qualidade funcionavam bastante bem em todas as partes do mundo, e no nosso caso parece que o mesmo se aplica. Ainda é muito cedo para se ter certeza, mas parece que funciona.

 

Artigo publicado na revista Developers’ Magazine em 1997.