Qualidade em TI – Aprendendo com as falhas

Em nosso último texto falamos do processo de Prevenção de Falhas, de seus compromissos, dos envolvidos e dos passos a serem seguidos.

Agora vamos falar sobre a implantação deste processo e, para começar, precisamos de uma base. Por exemplo, de uma lista de falhas que possam ser priorizadas e assim atacadas.

Nunca podemos esquecer da definição de Qualidade em TI:  Qualidade em TI só é 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.

Significa que precisamos medir se o produto ou serviço faz o que deve ser feito e se é entregue ao custo e prazo combinado.

De saída temos aí alguns indicadores:

• Fazer o que deve ser feito significa não apresentar falhas – é indicador de eficácia;
• Entregue no prazo significa que foram combinados anteriormente datas e horas, ou mesmo tempos de resposta para a entrega do produto ou serviço – é outro indicador de eficácia; e,
• Entregue no custo significa que há uma expectativa de gasto para a obtenção do produto ou serviço – é indicador de eficiência.

Medir antes de aplicar qualquer ação e assim obter a base de comparação em relação aos resultados destas.

Caso a organização já possua um processo de atendimento a ocorrências, do tipo Help Desk, ao qual os usuários ou clientes recorrem quando têm algum problema. Este processo faz o registo de ocorrências, formando uma base de dados de incidentes e problemas, que serão analisados e solucionados pelo suporte e/ou desenvolvimento.

Este registro com a lista de falhas, ou incidentes, é a base ao processo de Prevenção de Falhas.

A lista deve ser analisada de forma pragmática, classificando as falhas por tipo, origem, geografia, impacto em negócio ou serviço, urgência, etc. As informações devem ser consolidadas e a análise, em conjunto com as áreas de engenharia de software, devem indicar as ações de melhorias e controles a serem aplicados.

Para garantir que, uma vez identificadas e endereçadas, as falhas em software não voltem a ocorrer, as ações aplicadas e o conhecimento adquirido neste processo devem ser traduzidos em lições aprendidas.

Como fazer isso?

Transformamos as causas que provocaram incidentes e problemas em itens de verificação aos demais processos do ciclo de vida de software:

• para a Elicitação de Requisitos – implica em um checklist mais completo quando da validação dos levantamentos de requisitos de usuários;
• para os Requisitos Funcionais e Não Funcionais – implica em melhoria nas especificações funcionais e técnicas do software em definição e desenvolvimento;
• para as Condições de Testes – implica em incremento dos testes com condições que anteriormente não eram verificadas;
• para o processo de Homologação – implica em maior garantia de qualidade antes da decisão de implementação do software em produção;
• para o processo de verificação da Conversão – implica em ampliação das condições de distribuição de software;
• e, também em argumentos de pesquisa ao Código Legado – implica em permitir a varredura do código legado em busca destes defeitos e, assim, prevenir falhas provenientes deste tipo de causa.

Desta forma, condições que antes não eram previstas, passam a enriquecer todo o processo de desenvolvimento, manutenção e implantação de software. Incrementar a garantia através de itens que anteriormente não eram verificados.

Esta tradução deve ser cuidadosa, por exemplo, incluir a análise de tendências, que permita a um passo além, uma visão de futuro. É a fase preditiva do processo de Prevenção de Falhas, sem a qual, a organização não aprende com seus próprios erros.

Seguindo com a orientação que definimos para as ações, começando de trás para frente, no próximo texto vamos falar de: Qualidade em TI – As falhas na implantação.

[Crédito da Imagem: Falhas – ShutterStock]