Qualidade de TI – Qual a abrangência

Para começar a falar sobre qualidade em TI, é preciso conceituar: O que é Qualidade?

Defendo que Qualidade é a satisfação das necessidades, que só existe se medida e percebida pelo cliente, ou usuário final.

Esta conceituação deve ainda ir um pouco além. As expectativas de clientes e usuários compreendem necessidades explícitas, declaradas nas suas requisições, mas não tão somente isso, necessidades implícitas, não declaradas, também devem ser atendidas.

E ainda tem mais, a qualidade considera o prazo no qual as necessidades devem ser atendidas.

Atualmente a realidade dos negócios está em constante mutação e as necessidades se alteram com muita rapidez. Os prazos de entrega necessitam ser reduzidos e as soluções precisam ser flexíveis para aceitarem manutenções constantes.

E não termina aí, afinal, há que se considerar também o custo, assim, o produto ou serviço deve ser entregue ao custo combinado.

A Qualidade então é percebida pelo cliente, ou usuário final, como um produto ou serviço, que faz o que deve ser feito, explícita e implicitamente, e é entregue no prazo e ao custo combinado.

E qual a abrangência da Qualidade em TI?

Há que se pensar em qualidade muito antes de começar a escrever um software e muito além do software. Precisamos começar a verificar e medir a qualidade quando se começa a pensar em desenvolver um produto ou serviço. Lá no início, quando se define: O Que Se Quer?

E isso inclui todos os requisitos envolvidos, desde as funcionalidades, passando por eficácia e eficiência, pela segurança requerida, por infrestrutura necessária para atingir a performance esperada e outros tantos.

Poderíamos ficar aqui descrevendo uma série interminável, citando ítens que normas e modelos já elencaram. Mas o que acho necessário aqui, é o entendimento de que Qualidade de TI começa muito antes da TI e termina muito depois da TI.

O que quero propor é atingir a Qualidade de TI através de ações aplicadas durante o todo o ciclo do produto ou serviço.

Ações dirigidas para a qualidade, para a redução de erros, para a eliminação de defeitos, para a prevenção de falhas.

Sim, pessoas cometem erros. Não por vontade, aí estamos falando em sabotagem, mas por falta de treinamento, falta de orientação adequada, ou mesmo comunicação indevida.

E ai, o que acontece?

Defeitos são introduzidos no produto ou serviço.

Estes defeitos muitas vezes não são detectados e removidos durante os testes e ficam dormentes por longo tempo. Até que aquela condição específica, aquele dado diferente, que até então não havia transitado, aparece e acorda o defeito, provocando as falhas no resultado esperado. Nesse momento, todos são surpreendidos e ouvimos coisas como:

• “Justamente esse teste não foi feito…”
• “A versão nova ainda não estabilizou!”
• “Nos testes estava tudo bem, mas implantaram a versão errada!“
• “O aplicativo falhou mesmo testado exaustivamente”
• “O aplicativo falhou onde não podia – lei de Murphy”

Ressaltamos que:

• Testes consomem 30% do esforço do desenvolvimento;
• Quase 60% dos defeitos são gerados antes da 1ª linha de código ser escrita;
• Sistemas são cada vez mais integrados, mais genéricos, processam em múltiplas plataformas, com múltiplas interações de diferentes usuários, acessados por múltiplos canais de comunicação;
• Interagem com os mais diversos aplicativos;
• Testes tornam-se mais complexos, mais trabalhosos…

O resultado é a menor visibilidade da qualidade do produto ou serviço de TI e a menor previsibilidade de prazos e dos custos envolvidos.

Tenho percebido que muito se fala sobre gestão de requisitos, gestão de testes, gestão de mudanças e gestão da conversão. Ações focadas no durante, mas pouco no antes e no depois. O depois, em geral são ações do tipo: força tarefa para recuperação e estabilização, típicas ações de bombeiros.

A abrangência das ações a serem aplicadas antes, durante e depois do desenvolvimento do produto ou serviço é que irá garantir o foco na Qualidade em TI.

Nos próximos textos vamos avançar nas ações que fazem a real diferença para a qualidade do produto ou serviço, aplicáveis em momentos diferentes do ciclo de desenvolvimento.

[Crédito da Imagem: Qualidade – ShutterStock]