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.