Desenvolvimento

4 jul, 2013

Análise de maturidade em software “Frankenstein”

Publicidade

Nós já desenvolvemos software há muitos anos, e pudemos acompanhar grandes ciclos de evolução da tecnologia, deixando para o passado o famoso cartão perfurado. No entanto, algumas coisas ainda permanecem como antes, mesmo com inúmeras inovações e novos caminhos. Ainda hoje, diversos projetos são levados ao fracasso ou seguem caminhos dificultosos por falta de modernização, e não me refiro à simples troca de compilador, e sim a técnicas ultrapassadas e software construído sem a mínima preocupação com qualidade, que vem gerando um efeito que chamamos de software “Frankenstein”.

Para ter uma visão da forma com que produzimos software, eu lhe convido a comparar com uma fábrica de biscoitos. Quando se tem problema na produção e os biscoitos saem torrados, portanto, não passando pelo controle de qualidade, eles são descartados. Já o software é tratado de forma complementarmente diferente. Mesmo com problema na produção, ele é levado ao cliente que é obrigado a consumir um produto “avariado” e, após ciclos de reclamações indo e voltando, chega-se uma versão “remendada” do software ao cliente.

Esse modelo moveu a indústria de software por muitos anos, e não é difícil de encontrar algo parecido bem próximo  a você. Criou-se o princípio do erro consciente e o entendimento que machucar o cliente de leve não traz problema, provocando com isso um grande desgaste nos projetos que não são entregues nos prazos, nas pessoas que se desgastam e no próprio patrocinador do projeto, que devido a tantos ciclos recorrentes se desgasta e acaba desacreditado.

A falta de preocupação em produzir software funcionando impulsionou a indústria em um momento do mercado em que o cliente não tinha opções. Era um momento sem concorrência e nem meios de aprender e obter informações. Hoje, o consumidor tem experiência e aplicativos, estando cada vez mais exigente, conectado e influenciando a evolução do produto.

Baseado nas experiências em projetos nos últimos 15 anos, eu elaborei um pequeno questionário para que você possa fazer uma análise e levantar o nível do seu projeto.

Descritivo Pontos
Você tem módulos no projeto em que apenas uma pessoa dá manutenção? 5
Cada nova manutenção provoca medo em todos do time? 3
A cada mudança há um enorme retrabalho? 5
Alto índice de código duplicado e baixa reutilização? 3
Prazos nunca são cumpridos? 1
Longo tempo para liberar versões? 3
Backlog de trabalho nunca é finalizado ocasionando demora em atender cliente? 5
Ao corrigir um bug, aparecem outros problemas? 3
O cliente pede uma correção e recebe novas funcionalidades? 1
Turnover alto de pessoas? 1
Dificuldade de relacionamento Cliente X Equipe X Empresa que não confiam no software? 3
Quanto mais pessoas entram no projeto, mais problemas aparecem? 5
Todos se dedicam e trabalham intensamente não enxergando as entregas? 3
Várias versões do software duplicadas 1
A liberação de versão é manual na máquina do desenvolvedor? 1
Dificuldade em compartilhar serviços / API / SDK 3
Tecnologia utilizada está desatualizada 1
Dependência de componentes ultrapassados 3
Dificuldade em escalar desenvolvimento para outras pessoas 5
Regras de negócio em banco de dados 3
Código fonte atual é o mesmo de produção 1
Uso abundante de Stored Procedures 1
Problemas devido a banco de dados mal projetado, tabelas duplicadas, ausência de integridade. 3

Some todos os pontos conforme os itens que baterem no seu projeto e calcule o seu nível “Frankenstein”.

Pontuação Nível
Até 5 pontos Problemático
De 6 a 10 pontos Crítico
Mais de 10 pontos Caos

Agora que você já tem uma visão do nível de maturidade do seu software, será mais fácil encontrar respostas a questionamentos do tipo:  “Antigamente eu e mais outra pessoa construíamos o software e hoje nem com 30 pessoas conseguimos manter”. Frase muito comum dita no mercado de software.

Todas as empresas e produtos têm um ciclo de adoção da tecnologia, iniciando nos visionários que acreditam na sua ideia até o mercado que procura adotar o seu produto depois da comprovação de valor, comprovando que o produto  atravessou o abismo conforme Geoffrey Moore definiu em seu livro “Crossing the Chasm” o conceito “Technology Adoption Lifecyle”. Porém, chega um determinando momento em que o crescimento se limita e a concorrência se torna mais próxima, sendo necessário inovar.

É no momento da inovação que o efeito “Frankenstein” no software torna-se mais evidente e mais caro, uma vez que as empresas deixam de investir em inovação para gastar com sustentação de projetos em investimentos cíclicos e recorrentes, minando qualquer iniciativa de renovar. Em estudo do Forrester, foi comprovado que gasta-se cerca de 30x mais para manter o software por falta de qualidade. É o momento de repensar o nosso formato atual de desenvolvimento de software. Participe nos comentários.