Qualidade de software não importa, o que vale é entregar

Durante anos acompanhando o mercado de software no Brasil venho me dedicando a conversar com os profissionais de tecnologia em todos os segmentos de empresas e o tema qualidade de software é sempre algo deixado em segundo plano na agenda dos gestores, sendo visto erroneamente como custo e mais trabalho para criar uma solução. Indo contra essa abordagem o Forrester fez um excelente estudo EM 2009 onde comprova que corrigir um bug em produção chega a custar 30 vezes mais, coisa que você já deve saber, porém poucos se dedicam a estudar mais a fundo a origem e como resolver.

Essa visão aplicada em fazer os projetos de qualquer jeito criando sistemas de produção “pseudo” produtivos tem prejudicado toda a indústria de software ao longo dos anos, contribuindo justamente para o contrário, resultando em software mal projetado, inseguro e nada produtivo, permeado por falhas frequentes e um retrabalho absurdo, consumindo os desenvolvedores, usuários e demais participantes do ciclo do projeto.

É comum receber o contato de clientes relatando que desenvolvedores querem testes, mas sempre chegam com aquele tom de deboche e uma dúvida no ar: “para quê?”, como uma grande interrogação na cabeça do gestor, uma vez que para ele está indo tudo bem, maravilhoso e que fazer software é assim mesmo, árduo, complexo, repetitivo, falho e, principalmente, essas dificuldades só existem devido à características do negócio dele e por isso eles sofrem e estão condenados a viver assim sempre planejando e vendendo sonhos que nunca são entregues conforme o previsto.

Eu imagino que você certamente se identificou com algo dito até este momento, afinal esses fatos refletem a mais pura essência de como se “conduz” e se pensa um projeto de software nas condições do vai fazendo e coloca em produção que eu assumo (“Go Horse”), pode confiar. Estamos no momento importante para você se permitir uma pausa (“Eu sei que você já escutou isso”) para refletir se esse processo de trabalho na raça, força bruta e retrabalho é realmente a única forma de se construir software e repensar onde foi parar toda a modernização tecnológica que foi criada nos últimos 15 anos e continua sendo ignorada.

Em todas as minhas pesquisas no mercado de software tenho percebido que ninguém se preocupa em contabilizar o prejuízo, retrabalho, insatisfação de todos que participam, inclusive você e os usuários do sistema, mas, principalmente, o custo para manter um software na UMB (Unidade multiplica bug, equivalente a UTI para seres humanos) durante toda a vida do mesmo, temendo qualquer mudança, atualização que se torna cada vez mais nociva a estabilização do projeto.

Se você tem um software hoje hospedado na UMB ((Unidade multiplica bug) sabe responder rapidamente o tamanho do backlog de mudanças que não consegue implementar por falta de tempo (“$”); sabe responder os seus sonhos não realizados que impedem de atender o cliente de forma mais moderna com um software simples e fácil de atualizar, pois está preso em um ciclo vicioso de manutenção recorrente que consome todo o seu tempo de repensar, inovar e progredir no produto.

Não existe produtividade ou evolução com segurança em software feito de qualquer jeito sem sustentação. É o mesmo que ter um edifício sem a devida fundação que sustente a carga de pessoas. Eu sei que as palavras carga e escalar são proibidas de falar em projetos de software, mas chega um momento que não aguentamos e temos que colocar o dedo na ferida e começar a dizer não. Quando eu digo não, é não mesmo. Chegou o momento de tomar uma atitude de mudança e parar de esperar resultados sem você fazer nada de diferente.

Para pensar em um ciclo moderno de software é importante entender e discutir os requisitos desde o início, tornando as pessoas parte do processo. É preciso pensar mais no problema a ser resolvido antes mesmo de iniciar a codificação. Com as tecnologias modernas é possível pensar e separar corretamente a inteligência da aplicação criando código simples e de fácil manutenção que quando integrado a testes unitários automatizados passam a compartilhar a qualidade para todos do projeto. Hoje podemos criar ciclos de qualidade indo desde funcionalidades até carga usando serviços de nuvem, o que aumenta a sua produtividade com a redução do retrabalho eliminando problemas recorrentes que nunca se resolvem numa abordagem tradicional.

Adotar práticas de qualidade é mais atitude do que qualquer outra ação e precisa estar na mente de todos que participam do ciclo de desenvolvimento de software. Você precisa conquistar o coração do seu cliente com um produto orientado aos seus desejos e que funcione corretamente. Qualquer pessoa que contribuir no projeto precisa ter em mente o quanto é importante aquela qualidade que ele está somando ao projeto.

Hoje não existe mais desculpa para viver no mundo de “Alice do software”, achando que jogar a sujeira debaixo do tapete e deixar o cliente pagar a conta da falta de qualidade é a solução. Um cliente insatisfeito custa muito caro para o negócio. Ele vai reclamar do produto e esse ciclo repetitivo de ir e voltar desestimula todo a equipe que perde a percepção de entrega do projeto. Por isso, hoje, pensar em qualidade é fundamental para ter produtividade e satisfação entre todos. Reduza os custos do seu projeto eliminando defeitos recorrentes e repetitivos ainda no início.

Para saber mais:
Aprofunde seus conhecimentos sobre este tema na comunidade ALM


Exibições: 430

Comentar

Você precisa ser um membro de DevBrasil para adicionar comentários!

Entrar em DevBrasil

Comentário de Marques Denis em 6 abril 2014 às 1:00

Na empresa que eu trabalho, estamos migrando todas a plataforma legadas  p/  .NET 

Os teste são realizados de maneira manual , e quase sempre quando há uma nova implementação que afeta vários pontos da aplicações , algo que funcionava antes não funciona mais.  

Apos ter implantado com muito custo( programadores antigos relutam muito, "sempre trabalhei assim , e nunca precisei disso!") , projeto testeUnit , os resultados foram incríveis.

Hoje consegui rastrear com extrema eficiência erros , decorrentes de novas implementações , bem como verificar o desempenho de pontos da aplicação.

Os programadores antigos reconhecem a eficiência , mas quando temos as reuniões semanais com o diretor e dono da empresa, eles dizem que isso não é necessário, mesmo que através do projeto de teste vários de seus bugs forma corrigidos rapidamente.

O projeto continua firme e forte ! e já disse que não abro mão deste recurso ! 

Comentário de Bruno Alves Siqueira em 4 dezembro 2013 às 16:10

É estranho ler essa matéria que abordam esse assunto dado a empresa que trabalho atualmente, ela realmente se preocupa com essa qualidade, o último projeto que participei teve tão poucos bugs após o Go Live que a garantia não teve muito trabalho.

Comentário de Edson Lourenço em 5 novembro 2013 às 18:40

Muito bom, concordo plenamente que 90% seguem o Go Horse. Se soubessem os benefícios de uma metodologia não deixariam o cavalo a solta, rs!

Comentário de Alex Sandro de Oliveira em 22 outubro 2013 às 20:07

Ótimo post. Uma pena 90% das empresas seguirem o Go Horse.

© 2017   Criado por Ramon Durães.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço