(Publicado na Developers' Magazine em Agosto de 1997)

A pesquisa publicada neste número da Developers’ sobre a utilização de Orientação a Objetos tem alguns resultados interessantes que vale a pena comentar. Algumas coisas eram esperadas, outras nem tanto. Vamos a elas.

O uso de variantes de metodologias OO (Booch, UML, OMT etc.) ficou sem resposta por quase metade dos respondentes, indicando talvez que se esteja tentando usar OO sem metodologia nenhuma. Geralmente isto é o reflexo da idéia (errada) de que desenvolver sistemas é codificar. Quem acha que está fazendo OO simplesmente porquê está usando Delphi deve botar as barbas de molho. Se estiver usando VB então (que não é OO)… A tese se confirma quando se verifica que está havendo mais treinamento para programação do que para análise e projeto OO.

A metodologia indicada como a mais usada (pelos que estão usando alguma) é Coad/Yourdon, a mais antiga e ultrapassada, abandonada até mesmo pelos seus autores. Pode indicar três coisas: (1) estas empresas estão usando OO há muito tempo, desde quando Coad/Yourdon era novidade (pouco provável); (2) estas empresas tiveram pouco acesso à história da evolução das metodologias OO, ignorando que novas metodologias, inclusive dos mesmos autores, superam as deficiências de Coad/Yourdon (um pouco menos improvável); (3) os profissionais brasileiros de informática, ao contrário do que se acredita, continuam tendo grandes dificuldades com a língua inglesa (o mais provável, especialmente considerando-se que o segundo lugar é de Rumbaugh: Coad/Yourdon e OMT são as únicas metodologias OO traduzidas para o português).

Como era de se esperar, as linguagens mais usadas são Delphi e VB. Cuidado! Delphi é OO, mas também é estruturada (híbrida); pode-se perfeitamente programar em Delphi sem se estar fazendo OO. O VB, por sua vez, não é totalmente OO, limitando as possibilidades do desenvolvedor. Surpreendeu-me, entretanto, o uso de C++ (15%): não esperava tanto!

Os bancos de dados OO continuam sendo ilustres desconhecidos no Brasil. Presume-se que os respondentes estão usando relacionais ou nada.

O brasileiro confirma sua vocação para autodidata: 60% das empresas estão migrando para OO sem nenhum apoio externo (consultoria)!

A maioria das empresas espera aumentos de qualidade e produtividade da OO. Correto, mas cuidado! O retorno da OO em termos de produtividade é no longo prazo (três anos ou mais). Quem estiver esperando aumentos fantásticos de produtividade para amanhã vai se decepcionar. Além disso, o principal ganho de produtividade com a OO não se dá no desenvolvimento, mas na manutenção, que fica muito simplificada nos sistemas OO bem construídos (e apenas nestes). Além disso, quem não estruturar uma área de Administração de Objetos não vai conseguir obter a tão sonhada reutilização e, portanto, não vai ter aumentos de produtividade.

O número de projetos piloto pareceu-me bastante baixo. Pode ser que as empresas que já estão desenvolvendo já os tenham realizado (será?). De qualquer modo, o tema dos pilotos é tão importante que dedico o resto deste artigo a ele.

Projetos Piloto

Os projetos piloto são a melhor forma de transferir tecnologia nova para dentro de uma empresa. Talvez seja mesmo a única forma eficaz de fazê-lo. Projetos piloto trazem diversas vantagens ao processo de assimilação de uma nova tecnologia na empresa. Vejamos algumas delas.

Projetos piloto permitem o aprendizado prático pelos membros da equipe. Ao final do piloto, os participantes poderão dizer que realmente conhecem a tecnologia, ao contrário de quem sai de um curso. Tiveram a oportunidade de experimentá-la, verificar suas vantagens e limitações, sua aplicabilidade e -porquê não- puderam errar bastante (e aprender com isto).

Testar a tecnologia. Uma tecnologia alardeada pela mídia nem sempre é tão boa quanto seus profetas apregoam. Mesmo que seja, pode não ser adequada para a empresa em questão.

Projetos piloto permitem errar em ambiente controlado, reduzindo riscos e custos. Funcionam como um seguro. É muito mais barato descobrir que uma tecnologia não funciona ou não é adequada em um piloto pequeno e curto do que após um ano de aplicação em massa em um projeto crítico.

Adaptar os processos do uso da nova tecnologia à cultura da empresa. Cada empresa utilizará uma tecnologia de forma diferente, de acordo com sua cultura, capacidade tecnológica, background, tamanho, área de atuação etc. Imaginar que uma tecnologia pode ser aplicada sem adaptações em qualquer empresa é ingenuidade.

No entanto, projetos piloto devem ser bem conduzidos para darem resultado. Infelizmente, muitas empresas não encaram estes projetos com seriedade. Algumas simplesmente não os realizam. Introduzem novas tecnologias sem se preocupar em testá-las ou treinar as pessoas que as utilizarão, implantando-as em processos críticos. Não é de se admirar que boa parte, se não a maioria, destes projetos com uso de tecnologia nova sem teste e assimilação dêem com os burros n’água. Mas existe outra forma de não levar a sério os pilotos. Erros no estabelecimento e condução destes projetos podem ser fatais.

Vejamos, portanto, alguns fatores críticos para o sucesso de projetos piloto.

Objetivos claros. Todo mundo deve estar ciente dos objetivos do piloto. O primeiro é o treinamento. A entrega do produto final é secundária, quase um subproduto do piloto. Além disso,  não se deve colocar como objetivo o aprendizado de muitas coisas ao mesmo tempo, pois as curvas de aprendizado se multiplicam.

Foco no Treinamento. Não é demais repetir. O objetivo primordial do piloto é o treinamento da equipe, o teste e a adaptação da tecnologia à realidade da empresa. Não é o objetivo do piloto implantar o sistema X com prazo e custo determinados, com funcionalidade e qualidade conforme o especificado etc. Prazos, custos e escopo devem ser flexíveis, para dar oportunidade de experimentação à equipe e para possibilitar alternativas caso as coisas não saiam exatamente como esperado (algo mais que freqüente nestes casos).

Equipe de Projeto. Não é qualquer pessoa que deve fazer parte da equipe do projeto piloto. A equipe deve ser composta dos melhores profissionais disponíveis. Aqui se encontra um dos maiores problemas, já que os melhores profissionais invariavelmente estão já sobrecarregados de trabalho. O que acaba acontecendo é que a equipe piloto acaba sendo composta dos “largados”, pessoas que, por sua própria falta de iniciativa ou reduzida competência, têm tempo de sobra e não estão fazendo nada de importante. Ora, embora isto pareça evidente, é muito freqüente vermos equipes de projetos piloto compostas quase que exclusivamente de profissionais que estavam disponíveis justamente porque ninguém os queria. Na medida em que um piloto envolve aprendizado de tecnologias ou metodologias desconhecidas na empresa, são necessários aqueles profissionais que têm fome de aprender, criatividade, capacidade de encontrar soluções, grande dose de iniciativa e disposição para correr riscos. Ao mesmo tempo, como serão estas pessoas que terão depois a incumbência de disseminar internamente o que aprenderam, devem ser profissionais respeitados por seus pares e com grande capacidade de comunicação e didática. Vivência também é importante, para que a equipe do piloto saiba reconhecer armadilhas e estabelecer relações com as tecnologias em uso na empresa, além de poder valorar com maior objetividade as vantagens e riscos envolvidos na nova tecnologia. Dentro da curva de adoção de tecnologia da figura 1, o ideal é que os membros do piloto façam parte da categoria de “adotantes imediatos”. Os “pioneiros”, por outro lado, são melhores em tarefas de prospecção e experimentação prévia, antes mesmo do estabelecimento do piloto, uma vez que pessoas com estas características tendem freqüentemente a não enfatizar o lado prático do uso da tecnologia, o que é uma necessidade no piloto.

 

Gerente do Projeto. Todo o que foi dito em relação à equipe vale duplamente para o Gerente do Projeto. Além disso, o Gerente ideal para projetos piloto é aquele que têm um estilo participativo de liderança. Um capataz com cronômetro em uma mão e um chicote na outra não vai ajudar muito num caso destes. O Gerente do piloto deve ser mais um líder motivador do que um cobrador de resultados. Também deve ser bom na solução criativa de problemas inesperados, já que os percalços em um piloto podem ser muitos e variados.

Prazo. Deve ser curto. Pilotos que levem anos serão provavelmente cancelados antes do fim, além de perder a atenção da empresa. O tempo ideal para um projeto piloto é de quatro a seis meses. Isto normalmente é suficiente para o cumprimento dos objetivos que um piloto deve ter. Assim, é fundamental que o tamanho e escopo do projeto escolhido não seja muito grande.

Uso da tecnologia. O piloto deve ser escolhido de modo a permitir a experimentação em amplitude e profundidade da tecnologia que se está transferindo. De nada adianta escolher um projeto que, por suas características, explore apenas 10% da capacidade da tecnologia em teste.

Risco Baixo e Alta Visibilidade. É evidente que o projeto piloto deve ser escolhido dentre aqueles que, dando certo, podem trazer muito benefício, mas, dando errado, não levem a empresa à falência. Sistemas de Suporte à Decisão normalmente têm estas características, consistindo em excelentes candidatos a piloto. No extremo oposto, não adianta escolher também um projeto que têm risco baixíssimo exatamente porque trata de um assunto que não interessa a ninguém. Caso dê certo, ninguém vai prestar atenção, fazendo com que se perca um dos principais benefícios dos projetos piloto, que é justamente servir como vitrine para a tecnologia nova, atraindo o apoio de desenvolvedores e usuários.

Dedicação exclusiva. Quando uma pessoa têm que administrar simultaneamente rotina e inovação, invariavelmente a rotina esmaga a inovação. Esta é uma das razões pelas quais você ainda não encontrou tempo para começar a praticar aquele esporte que você se promete a anos. Uma equipe que trabalhe no piloto de tarde e dê manutenção em sistemas antigos de manhã dificilmente conseguirá terminar o piloto. A cada “pepino” que surgir no sistema atual, este receberá obviamente toda a atenção e o piloto será relegado a um segundo (ou terceiro) plano. A única garantia de dedicação efetiva ao piloto é a existência de uma equipe que tenha sido liberada de qualquer atividade rotineira.

Recursos. É claro que o piloto não poderá dar bons resultados se não houver recursos suficientes. É preciso alocar todas as facilidades necessárias, incluindo hardware, software de apoio, acesso à literatura, treinamento em conceitos, técnicas e ferramentas (nesta ordem e no timing correto), contratação de especialistas para consultoria e mentoring etc. Um gerenciamento pão-duro de um piloto não pode dar muito resultado.

Suporte Gerencial. Sendo o item mais importante, fica por último na lista, de forma a ser mais difícil de esquecer. Sem o apoio da alta administração, qualquer projeto tem poucas chances de sucesso, o quê é duplamente verdadeiro com um projeto piloto. Uma gerência comprometida garante a existência dos demais fatores acima. Inversamente, uma gerência pouco convencida não irá se esforçar por alocar o melhor gerente, a melhor equipe, garantir recursos e a dedicação exclusiva etc. Com um patrocinador forte, todos os problemas se resolvem. O ideal é um patrocinador de fora da área de tecnologia, de preferência o “usuário principal”, isto é, o Diretor da área a ser atendida pelo piloto. O cuidado, porém, que se deve tomar nestes casos, é o de garantir que este patrocinador entenda muito bem os objetivos de treinamento e assimilação do piloto, de forma a ser tolerante com os inevitáveis tropeços no caminho. Uma boa abordagem é fazer do piloto a primeira fase da implantação de um sistema maior, atraindo a “proteção” do patrocinador, que, embora não espere muito do piloto, confia que as fases seguintes produzam resultados importantes, com base no conhecimento adquirido na primeira.

Vale lembrar que tudo quanto se disse sobre pilotos vale para projetos de assimilação de qualquer forma de novos conhecimentos pela empresa. Projetos piloto podem e devem ser utilizados na introdução de novas tecnologias (como Orientação a Objetos), ferramentas (como uma nova linguagem de programação) e metodologias (como novos processos de Gerência de Projetos). Quando a mudança for muito grande, pode ser necessário mais de um piloto. No entanto, nenhuma empresa deveria adotar novas tecnologias sem ao menos um piloto, por simples e curto que seja. É um risco que simplesmente não vale a pena.

Artigo publicado na revista Developer's Magazine em Agosto de 1997.

Copyright © 1997-2006 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.