Gnosis

Por Atila Belloquim

Publicado em Janeiro de 1997 na Developers’ Magazine.
Este artigo está apresentado aqui tal como foi enviado ao editor, podendo, devido ao processo de revisão da revista, estar ligeiramente diferente de sua versão publicada.

Cultura. Cultura de Informática. Esta é a palavra de ordem que deve guiar os executivos de desenvolvimento de sistemas das empresas. Isto ocorre porque é fácil verificar que o investimento em tecnologia, quando entendido como compra de hardware e software, não tem produzido os resultados esperados em aumento de qualidade, produtividade e satisfação das necessidades dos usuários que se prometia. Ao contrário, a complexidade inerente às novas tecnologias tem deixado perdidos e sem mapa os desenvolvedores e gerentes de desenvolvimento. Como dominar, integrar e produzir algo de útil para os usuários e clientes da empresa com coisas como Cliente-Servidor, Orientação a Objetos, Multimídia, Internet, Sistemas Especialistas etc.? Como utilizar estas tecnologias para agregar valor aos produtos fornecidos pela organização, alcançando uma vantagem competitiva?

A verdade é que as novas tecnologias têm-se mostrado muito mais complexas do que foi alardeado em seu surgimento. Além disso, a maioria dos desenvolvedores, após longos anos trabalhando em aplicações monolíticas, centralizadas e desenvolvidas com base em técnicas de Análise Estruturada, tem grandes dificuldades (quando não resistência explícita) de passar de uma hora para outra para um ambiente com dados e processos distribuídos, objetos, interfaces gráficas, groupware, ferramentas CASE, e-mail e middleware. Além disso muitas tecnologias “da moda” não estão ainda maduras para o desenvolvimento de aplicações de missão crítica. Como saber por onde ir? Quando começar? Pelo quê?

Existe uma verdade óbvia que é freqüentemente esquecida. Independentemente da tecnologia subjacente, sistemas são desenvolvidos por seres humanos. Uma Ferrari F-40 não sairá do lugar se a pessoa que se sentar ao volante não souber dirigir (ou irá parar no primeiro poste). Um volume com as Obras Completas de Shakespeare não acrescenta nada a quem não sabe ler. Da mesma forma, sem uma profunda preparação, um desenvolvedor não saberá como tirar proveito de novidades tecnológicas, sendo provável até que perca seu tempo desenvolvendo aplicativos que não poderão ser utilizados ou, pior, que poderão causar problemas e prejuízos à empresa.

É, portanto, fundamental que os executivos de informática tomem consciência de que a migração para uma nova tecnologia, como Cliente-Servidor ou Orientação a Objetos, é muito mais uma questão de mudança cultural que uma mudança meramente tecnológica.

Quais as conseqüências imediatas disto? Em primeiro lugar, é necessário parar de comprar hardware e software antes de se saber para onde se vai. É inacreditável a quantidade de empresas que compram servidores e linguagens de programação orientadas a objetos (”Pelo menos foi o que o vendedor garantiu!!!”) sem sequer informar-se dos conceitos mais básicos referentes a estas tecnologias. São tomadas decisões quanto ao servidor de banco de dados, sistemas operacionais e ambientes de programação que logo se mostram inadequados às necessidades da empresa.

Assim, os executivos que decidem sobre mudanças tecnológicas deveriam informar-se muito bem antes de tomar decisões. Além disso, deveriam incluir neste processo de “aculturação” seus técnicos mais brilhantes e experientes, pois estes têm os recursos necessários para identificar riscos técnicos e fazer as perguntas que o vendedor não gostaria que fossem feitas.

Nenhum processo de migração tecnológica deveria ser feito sem um ou mais projetos piloto. Embora isto pareça óbvio, muitas vezes é ignorado. Também é necessário observar que há pilotos e pilotos. O conceito que muitos gerentes têm sobre projetos piloto resume-se a jogar nas mãos de uma equipe algum hardware e software de desenvolvimento dizendo “vejam o que vocês conseguem fazer com isso”. Embora uma análise exploratória inicial seja importante, nada substitui um projeto piloto formal como instrumento de validação de tecnologia e treinamento prático da equipe.

A equipe do piloto deve receber treinamento antes do início do projeto. É freqüente encontrarmos em salas de treinamento pessoas que participaram de pilotos, e mesmo de projetos posteriores, aprendendo os conceitos básicos daquilo que já utilizaram. Nestas situações, a frase mais ouvida pelo instrutor é “Ah, se eu soubesse disto há um ano, quando começamos o projeto!” Estas pessoas verificam então quanto tempo e dinheiro foi perdido em becos sem saída que poderiam ter sido evitados com um simples treinamento dado no momento certo.

Suponhamos uma empresa que tenha decidido adotar uma nova tecnologia. Que passos deveriam ser seguidos pelo gerente encarregado desta empreitada?
•    Em primeiro lugar, o gerente deveria escolher um ou dois técnicos experientes e com facilidade para absorver novas idéias, formando um grupo de estudo.
•    Este grupo deveria imediatamente familiarizar-se com a nova tecnologia. Isto incluiria a participação em cursos conceituais sobre o assunto (não cursos de produtos específicos!), leitura de livros e revistas especializadas nacionais e estrangeiras, e visitas a empresas que já possuem a tecnologia. Antes de qualquer decisão, é necessário familiarizar-se com a terminologia, os conceitos, o estado de maturidade da tecnologia e os principais padrões e produtos disponíveis no mercado para esta.
•    Como em todo processo de transferência de tecnologia, é necessário então escolher uma empresa de consultoria com experiência no assunto para facilitar a transição. Uma boa consultoria acelera o processo de transição e baixa os custos, pois faz com que se evitem as armadilhas inerentes à adoção da nova tecnologia (e são muitas!!!)
•    A empresa de consultoria ajudaria o gerente a escolher um projeto piloto adequado, para o qual deveria ser escolhida uma equipe com pessoas competentes, criativas e curiosas, dispostas a aprender. Se possível, o gerente deveria escolher seus melhores profissionais para o piloto (em vez de escolher os que não estão fazendo nada de importante por não serem tão bons assim, o que ocorre com freqüência). Também devem ser escolhidas ferramentas de desenvolvimento a serem utilizadas no piloto.
•    Esta equipe passaria então por um processo maciço de treinamento, incluindo os conceitos básicos da tecnologia, as metodologias de desenvolvimento utilizadas para aquela tecnologia e as ferramentas de desenvolvimento que serão utilizadas.
•    O projeto piloto seria então desenvolvido, com o apoio da consultoria. Um consultor pode fazer o papel de “tutor” da equipe, solucionando suas dúvidas práticas e fazendo do piloto uma espécie de treinamento contínuo e prático.
•    Ao final do piloto, erros e acertos devem ser documentados e divulgados. As demais equipes devem ser igualmente treinadas antes que novos projetos sejam desenvolvidos.

O projeto piloto deve servir também como teste e treinamento da metodologia de desenvolvimento, e não apenas da tecnologia adotada.

Como se pode observar, se os profissionais não sofrerem uma “imersão total” nas novas tecnologias e metodologias, não saberão o que fazer, e tenderão a utilizar a nova tecnologia com os conhecimentos que têm, fazendo, portanto, uma utilização errônea ou, no mínimo, uma sub-utilização dos recursos disponíveis. Quem só conhece bicicleta vai querer pedalar uma Mobilette (e vai achar pesada!).

Acreditamos que o enfoque de transferência de tecnologia como um processo de educação de pessoas é o único que pode garantir o sucesso de uma transição tecnológica. A compra de hardware e software de última geração não garante em absoluto a melhoria dos sistemas. Desenvolvedores capazes, bem preparados e bem suportados por ferramentas adequadas são a única garantia de sucesso no desenvolvimento.