Problemas nos caminhos da transformação digital, por Gefferson de Medeiros

Empresas globais de tecnologia de altíssima reputação não costumam recorrer ao marketing enganoso para vender os seus produtos estratégicos.

Problemas nos caminhos da transformação digital

por Gefferson de Medeiros 

Em plena onda de difusão digital, quando muito se fala na Quarta Revolução Industrial, nota-se a crescente iniciativa de se buscar investir no desenvolvimento de sistemas inovadores voltados para suportar a transformação digital. Em muitos casos são utilizadas startups que adotam o mantra “fail fast” (falhe rapidamente). O fato é que as startups falham e a imprensa norte-americana tem apontado uma série de problemas para além do modismo que busca apenas glorificá-las.

Mas por que mesmo as startups falham? Pode-se dizer, basicamente, que essas firmas cometem equívocos no desenvolvimento de sistemas, ao desconsiderar inclusive as singularidades especificas dos seus clientes. Erros de interface, ambiguidades de requisitos, modelagem de apenas parte do sistema alvo, recursos limitados do projeto de software e ausência de suporte foram alguns dos muitos problemas encontrados. Tais problemas foram descobertos pelos clientes durante o uso dos produtos.

Empresas globais de tecnologia de altíssima reputação não costumam recorrer ao marketing enganoso para vender os seus produtos estratégicos. Na primeira metade da década de 1980, por exemplo, a IBM lançou o revolucionário database relacional, o SQL/DS (o primeiro nome do DB2), que na realidade era um protótipo prematuramente promovido a um software de produção. Claro que ocorreram erros descobertos em produção, gerando custos de reconstrução para o cliente ao ter que migrar para outro sistema operacional e descartar o componente transacional de visualização de dados. A Oracle havia lançado primeiro que a IBM o seu database relacional, sendo que a otimização do RDMS era baseada em regras. Tal fato deu origem a uma “indústria de sintonia de desempenho”. Aproximadamente 14 anos depois foi lançado um otimizador baseado em custos no Oracle 7, que é o componente crítico de qualquer database relacional que se preze.

Leia também:  A campanha “Lula Livre” e o impasse das forças progressistas contra esse governo, por Álvaro Miranda

O “hype” corrente na automação de desenvolvimento de sistemas concentra-se nos provedores de software chamados de “low-code” e “no-code”. As lições rapidamente aprendidas ajudam as empresas escolher o produto, que tem capacidades e recursos para automatizar o desenvolvimento de sistemas. Tais lições estão sintetizadas na questão: o seu produto foi usado para automatizar o desenvolvimento de todos os componentes dele próprio? Qualquer resposta diferente de SIM desmonta o marketing enganoso do provedor do software de automação do desenvolvimento de sistemas.

Pergunte aos desenvolvedores experientes de sistemas complexos em qualquer empresa que buscam aprimorar significativamente a maneira de desenvolver sistemas qual é a maior pressão que vocês enfrentam em cada “sprint” de desenvolvimento dos MVPs dos backlogs de quaisquer sistemas. A resposta consiste em uma lista de itens:

  1. Definições rigorosas incompletas tardiamente descobertas.
  2. Descobertas de quaisquer tipos de erros são retardadas e chegam ao limite de gerar descréditos junto aos usuários de negócios, com alto custo de correção.
  3. Pressão de tempo para entregar o sistema.
  4. Melhores práticas de desenvolvimento de sistemas são, quase todas elas, tradicionais e ultrapassadas.
  5. O paradigma de desenvolvimento somente permite que os erros sejam descobertos na derradeira etapa de desenvolvimento, ou seja, nas atividades de testes do sistema.
  6. O foco na integração é sempre retardado e isso torna a mesma muito complexa, quando é de alguma forma possível, pois os sistemas não são desenvolvidos para serem integrados (a imensidade de silos de dados construídos, por exemplo).
  7. O reuso de componentes das aplicações não é primordialmente relevante.
  8. Os sistemas não são construídos para serem modificados ao longo de seu ciclo de vida, ou seja, na prática é inviável fazer uma engenharia reversa a fim de aprimorar o sistema em algum ponto no tempo no futuro, usando a mesma abordagem de desenvolvimento.
Leia também:  O que Paulo Freire pode nos ensinar sobre jornalismo?, por Juliana Freire Bezerra

Ao longo das últimas cinco décadas, tentativas de projetistas de construir sistemas inovadores críticos rapidamente e corretos usaram práticas tais como cascata, espiral, user experience, técnicas de desenvolvimentos ágeis tipo extreme programming e outras mais. Claramente, tais ferramentas e práticas tradicionais de desenvolvimento de sistemas não têm resolvido os problemas acima listados. Portanto, é preciso repensar a metodologia de desenvolvimento de sistemas.

 

Você pode fazer o Jornal GGN ser cada vez melhor

Assine e faça parte desta caminhada para que ele se torne um veículo cada vez mais respeitado e forte.

Assine agora

Deixe uma mensagem

Por favor digite seu comentário
Por favor digite seu nome