Análisis Causal de Defectos

Propósito

El propósito del análisis causal de defectos (DCA) es identificar las causas raíz de los defectos (además de otros problemas) y tomar las acciones correctivas necesarias para prevenir que estos no vuelvan a ocurrir.

Contexto

El DCA no es una tarea sencilla para las organizaciones pero es fundamental puesto que su aplicación mejora la calidad y la productividad a partir de la prevención de la introducción de defectos en un producto.

Normalmente confiar en la detección de defectos luego de que ya han sido introducidos no es rentable. Se ha visto que es más efectivo prevenir la introducción de defectos a partir del desarrollo de actividades de análisis causal en cada etapa del proyecto. Puesto que la calidad del producto es inherente a la calidad del proceso que lo produce.

Las actividades de DCA también son un buen instrumento para la comunicación entre proyectos; puesto que soluciones a defectos del proyecto actual pueden haber sido encontradas en otros proyectos (de similares características) o incluso en etapas tempranas del propio proyecto.

El DCA no tiene por qué estar únicamente relacionado a defectos en el software; sino que puede ser utilizado en otro tipo de problemas no relacionados con los defectos tal vez relacionados con la efectividad en el uso de los costos (CPI) o en el uso del calendario (SPI). Lo único que hace falta es un proceso bien definido.

Seguramente haga falta establecer algún sistema de medición que nos permitan analizar el efecto de las causas; sino también la efectividad de las etapas del proceso en términos de indicadores que nos sean de interés.

Etapas del proceso

1. Determinar las causas de los defectos
1. Elegir la información para analizar
2. Analizar las causas
2. Erradicar las causas de los defectos
1. Implementar las acciones correctivas
2. Evaluar el efecto de los cambios
3. Colectar información

Determinar la causa de los defectos

La idea de esta etapa es asegurarse que sistemáticamente se analizan y se determinan las causas de los defectos (u otros problemas). Lo importante es identificar la causa Raíz, que es esa causa que si es erradicada los defectos relacionados disminuyen o bien desaparecen.

Elegir la información para analizar

En esta parte del proceso lo que debemos hacer es colectar toda la información de los defectos (o problemas) que nos sean de interés. Esta información puede prevenir desde diferentes fuentes como por ejemplo:

• Fuentes de defectos: reportes del cliente, reportes de usuarios, reportes de testing (mantis), reportes de revisión por pares.
• Fuentes de problemas: problemas de la gestión, problemas del proceso, indicadores de performance (CPI, SPI, EV), tiempos de respuesta, uso de los recursos

(Las listas no son completas, solo a modo de ejemplo)

Luego deberemos elegir cuales de todos los defectos (o problemas) vamos a tratar en detalle. Esto es fundamental para el proceso puesto que cualquier pequeño estimulo que hagamos por mejorar puede tener un gran impacto pero lo cierto es que abarcar mucho puede hacernos perder efectividad, entonces es mejor ir priorizando y atacando los defectos agrupados por: el impacto que tengan, la frecuencia de ocurrencia, índice de costos, índice de tiempos, entre otras similitudes.

Hay varias herramientas que se pueden usar para visualizar mejor esta agrupación y poder ponderar la selección, pero (según los estudios) la más utilizada es el análisis de Pareto (coloquialmente proporción 80/20).

Cuando se aplica a productos de software y en particular a defectos esta “regla” de proporciones se interpreta de la siguiente forma: “El 20% de los tipos de defectos son la causa del 80% de los defectos” con lo cual esta interpretación nos da una heurística para la ponderación de las causas de defectos (problemas) a analizar.

Ejemplo de gráfico para análisis de Pareto

Con lo que finalmente la salida de esta etapa del proceso es una lista ponderada, priorizada de defectos (o problemas) e incluso grupos de defectos (agrupadas por alguna dimensión de particular interés) que nos servirá de entrada para realizar el análisis de causa raíz.

Analizar las causas

El objetivo de esta etapa del proceso es realizar el análisis de causa raíz para los defectos/problemas seleccionados y proponer las acciones correctivas para erradicarlos.

El DCA es llevado a cabo normalmente en reuniones en con aquellos interesados que conocen o entienden mejor los defectos que hemos seleccionados para analizar. Estas reuniones se pueden realizar en cualquier momento; lo importante es que se realicen de forma sistemática.

Durante esta reunión lo que se hace es analizar detalladamente los defectos (problemas/tipos/grupos) que hayamos identificado en la etapa anterior del proceso para hallar la causa raíz.

Como para visualizar y profundizar el análisis de los defectos hay varias herramientas (puedo proveer un artículo que he publicado con una revisión sistemática sobre este tema si es necesario profundizar) pero las más utilizadas por las organizaciones son: el diagrama de Ishikawa (fishbone) y la técnica de los “5 ¿por qué?”.

El diagrama de Ishikawa (o de espina de pez) nos permitirá enfocarnos en un defecto a la vez y graficar de forma visual las posibles causas; mientras que la técnica de los “5 ¿por qué?” nos obligará a ir más profundamente sobre las causas acercándonos con mayor certeza a la posible causa raíz del defecto que estemos analizando.

Tras haber finalizado el análisis de cada uno de los defectos en cuestión, nos resta listar todas las causas identificadas (puesto que puede haber más de una causa en común), proponer y documentar acciones correctivas que nos ayuden a prevenir que vuelvan a ocurrir.

Ejemplo de diagrama de Ishikawa (fishbone)

Algunos ejemplos, las acciones correctivas pueden tener impacto en: el proceso, nuevos entrenamientos, cambios en herramientas, desarrollo de nuevas herramientas o métodos, mejoras en las comunicaciones o productos de trabajo.

Habitualmente de las acciones correctivas se documenta: Evento que la origina, descripción del problema, descripción del defecto, autor, etapa del proceso en la que se da el evento, etapa en la que fue identificado, descripción detallada de la acción propuesta (en pasos si fuera necesario).

Con lo cual el típico producto de trabajo de esta etapa es una lista de todas las acciones correctivas identificadas.

Erradicar las causas de los defectos

Básicamente el objetivo de esta etapa del proceso es realizar las acciones para institucionalizar las propuestas de mejora que faciliten que las causas de los defectos analizados sean erradicadas y así estos no vuelvan a ocurrir.

Implementar las acciones correctivas

Seguramente de la etapa previa hayan surgido varias y diferentes acciones correctivas y tal vez no todas (al menos a priori) puedan ser implementables o sea dudoso sí efectivamente su implementación agregará valor, por lo que primero habrá que analizarlas y priorizar su implementación.

Cuando se haya seleccionado una acción correctiva hay que generar los instrumentos para liderar su institucionalización, esto se hace a través de los action ítems (quién, cuándo, dónde y cómo) y así constituir una propuesta de mejora para la organización.

¡Ejecutar! Y finalmente identificar cuáles de las propuestas de mejora deben ser debidamente documentadas y en todo caso elevadas para ser incluidas en el conjunto de procesos estándar de la organización.

Por lo tanto los productos típicos de trabajo de esta fase son: la lista de acciones correctivas seleccionadas para su implementación y las correspondientes propuestas de mejora.

Evaluar el efecto de los cambios

Aquí la idea es poder medir, tomando medidas y calculando métricas el impacto de los cambios en el proceso/proyecto que ha sido modificado tras la puesta en práctica de las propuestas de mejora.

Esto necesitará de la definición de métricas (y las medidas adecuadas a estas) que nos permitan conocer si ha sido o no una mejora exitosa.

Hay alguna métricas comunes para defectos específicamente que se pueden utilizar; pero la mejor opción suele ser el utilizar un modelo de guía para la definición de métricas como Goal – Question – Metric (GQM) de V. Basili que es el mecanismo que más se ha industrializado y así definir las métricas especialmente necesarias de acuerdo a las necesidades de información.

Con las métricas y medidas definidas establecer una línea base de medición sobre la cual contrastar tras haber aplicado la mejora al proceso. Lo que necesitará también de la institucionalización de un proceso de medición.

Por lo que el producto típico de trabajo de esta actividad son las medidas de rendimiento previas y posteriores a la instrumentación de la mejora; además del análisis correspondiente.

Colectar información

La información recolectada, procesada y analizada durante el proceso de DCA debe ser administrada para que pueda ser compartida con el resto de la organización a los efectos de institucionalizar la mejora como conocimiento organizacional. Uno de los instrumentos que se puede utilizar como medio de comunicación de dicha información son las lecciones aprendidas.

Los registros, correspondan o no a las lecciones aprendidas, son los principales productos de trabajo de esta actividad.