|
A
ineficiência da indústria de software.
O ser
humano como primeira opção usa a força bruta para resolver seus problemas. Se
não consegue fazer algo com certos recursos humanos, acaba insistindo mais ainda
por fazê-lo e, só depois, quando fracassa, pensa em mudar métodos e paradigmas.
Isso é o que tem feito tradicionalmente e, basicamente o faz, a indústria de
desenvolvimento de sistemas no mundo.
Existe uma
enorme ineficiência da programação manual em todo o mundo e a ineficiência
relativa é cada vez maior. Se pode pensar que com as novas linguagens -por
exemplo, por usar Java ou C#, em
vez de usar Cobol- existe um aumento de produtividade da ordem de 50 a 100%
sobre os estándares de 1990. Mas as aplicações atuais são muito mais complexas
que as de 1990 (provavelmente 1000% mais complexas. Então, se estávamos mal,
estamos pior.
A síndrome
do ano 2000, empurrou ainda mais para o uso indiscriminado de recursos da força
bruta.
Como se tem
respondido -> ineficiência do desenvolvimento manual
Contratação
de pacotes: contrato a solução feita, sabendo que não vai satisfazer mais
que uma porcentagem de meus requerimentos, sabendo que vou perder
individualidade e, ->s vezes, minhas vantagens diferenciadoras. Sacrifico isso e
me incluo numa solução geral. Essa tem sido uma grande tendência. Os grandes
líderes dos pacotes tem conseguido, estranhamente, converter sua debilidade em
fortaleza preconizando com êxito que se quero ser uma empresa de classe mundial
devo utilizar seu software (e, é claro, adaptar-me a ele).
Importação de recursos
humanos. Isto é bastante claro, por exemplo, na Alemanha.
Contratação
de programação e, se é possível desenvolvimento e ainda outsourcing, em
países onde os salários são muito baixos e a capacidade técnica razoável. Este é
o fenômeno da Índia hoje emulado por muitos países de baixos salários e que
afeta de forma importante a indústria de software dos países
desenvolvidos.
Temos várias
experiências a respeito e temos empreendido uma ação por uma oportunidade ligada
-> solução deste problema no Japão. Mas, o problema não se refere unicamente ao
Japão: no último Cebit de Hanôver tive a oportunidade de conversar com vários
empresários de software e serviços associados da Alemanha, Inglaterra e Holanda,
fundamentalmente, e todos estão sentindo o mesmo problema. Em particular todos
eles contratam serviços na Índia e está claro para eles que só resolvem o
problema transitóriamente: todos eles vêem claramente que, a médio prazo, se
tudo continua assim, seus clientes contratarão diretamente na Índia.
Dito de outra maneira: com os atuais
paradigmas de desenvolvimento manual é inviável a indústria de software e
serviços associados nos países desenvolvidos que pagam altos
salários.
E isso é
fatalmente assim?
A síndrome do
know-how
Estamos
numa cultura presidida pela ?síndrome do Know-how?.
Permanentemente
lidamos com uma enorme quantidade de dados, pouca informação e quase nenhum
conhecimento. Por isso não vemos os problemas em sua verdadeira perspectiva, por
isso não os resolvemos.
Para
reverter a ineficiência: desenvolvimento baseado em
conhecimento
Como
revertimos isto? Os requerimentos têm que especificar-se estritamente em nível
de ?o quê?, e para isso necessito que o analista -nenhuma máquina o fará-
entenda o ?porquê? e o ?para quê?. Então a pessoa, um analista de negócios, vai
descrever o quê, e em seguida veremos como o fazemos: o ?como? sempre pode
automatizar-se.
Se o fazemos a mão, o ?quê? é insuficiente, também temos que
saber o ?como?, do contrário não há uma idéia de quanto vai custar, mas se o
fazemos com ferramentas baseadas no conhecimento o ?quê? é
suficiente: descrevemos em vez de programar. Então, é muito
importante que possamos ir a um paradigma de desenvolvimento baseado em
conhecimento, um paradigma onde eu descrevo o problema, e não tenho que analisar
todo o problema e deduzir dele os complexos algarítmos que o resolvam.
O
conhecimento é permanente, não perde o valor com o tempo nem com as mudanças
tecnológicas, o conhecimento é absolutamente independente da tecnologia
(sistemas operativos, sistema de gerência de base de dados, linguagem,
arquiteturas). No desenvolvimento baseado no conhecimento: o que acontece com as
mudanças? Alguém pode me dizer que não há mudanças, mas é mentira, só numa
empresa que está morta não há mudanças. Há mudanças, só que as mudanças se
propagam automaticamente, os programas se desenham e geram automáticamente, os
requerimentos se descrevem em nivel do quê.
A importância do
desenvolvimento baseado em conhecimento para as empresas
A
influência da divisão do mercado entre duas plataformas de execução (Java e
Microsoft.NET) é muito importante e afeta o resto do problema. Se sou um cliente
final, se há duas plataformas vou escolher uma e, derrepente, dentro de três
anos me dou conta que errei e remediar o erro é muito caro, porque geralmente
temos que fazer tudo de novo para outra plataforma. Mas se eu fosse uma loja de
software, por exemplo se eu fosse Mariano de Larrobla, a situação seria muito
diferente, não posso escolher, porque escolher significa automaticamente
renunciar -> metade do mercado.
Então para
uma grande corporação é muito importante manter o desenvolvimento baseado em
conhecimento porque se sua escolha tecnológica de hoje não é a adequada, amanhã
poderá trocá-la a um custo muito baixo. Para uma loja de software o
desenvolvimento baseado em conhecimento é essencial.
A tecnologia faz a diferença:
GeneXus
Agora pensemos na indústria de serviços que vende serviços ->
medida. O que vendo? Vendo horas de trabalho? No Uruguai por exemplo, se é isto
o que vendo é melhor que vá me dedicando a outra coisa, porque nunca vou poder
ter salários adequados, para poder competir com os países de baixos salários.
Devo me organizar para vender outra coisa, vendo trabalho medido com algum tipo
de unidade objetiva que conheçam ambas partes, vendo trabalho medido, por
exemplo, em pontos funcionais.
O que acontece se produzimos um desenvolvimento baseado em
conhecimento, se o fazemos em GeneXus?
Pois uma
empresa americana, com salários de USA, trabalhando em GeneXus pode fazer a
mesma aplicação a um menor preço que fazendo essa mesma aplicação em algum país
de baixos salários programando a baixo nível.
Claro,
os salários no Uruguai são um pouco mais baixos -esperemos que subam- e a diferença é muito
maior. A tecnologia compensa a diferença.
O que queremos é que gente de
primeira, trabalhando em seus países e ganhando bons salários, possam ser
eficientes: mais que aqueles que ganham baixos salários, mas trabalham sem
tecnologia.
Essa é a
diferença, a tecnologia faz a diferença.
Material da conferência:
http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,938
|