Los errores nos hablan… ¿estamos dispuestos a escucharlos?

Los errores nos hablan… ¿estamos dispuestos a escucharlos?

18 febrero, 2021 Giuseppe Satriani Calvi

Compártelo:

Cuantas veces hemos escuchado frases del tipo: “¡hay que aprender de los errores!”; “equivocarse es parte del aprendizaje”; “¡no hay mejor manera de aprender que equivocarse!” Estas verdades, que suelen acompañarnos a lo largo de nuestras vidas, desde nuestra infancia son realmente difíciles de aplicar porque nuestra sociedad y nuestra cultura exalta el éxito, pero nunca el necesario y complicado proceso para conseguirlo.

Esto se puede trasladar a cuando hablamos de empresas que desarrollan software. Los errores se asumen como parte inevitable del ciclo de vida de desarrollo, se asumen como herencia en un mantenimiento de sistemas, se actúa como bomberos profesionales cuando desatan un incendio, pero muy pocas empresas se paran a escuchar lo que los errores les susurran, y todavía menos aplican una sistemática para mejorar en función de las indicaciones que dichos errores nos proporcionan.

Errores y márgenes operativos, una amarga relación

Alguien se ha planteado alguna vez ¿cuánto cuesta corregir estos errores? ¿qué porcentual del margen se ve mermado por el mero hecho de detectar los errores muy tarde y hacer poco para que no vuelvan a ocurrir? ¿Cuál es el impacto en la capacidad de producción? ¿Cuánto afectan los costes de desarrollo en el caso del ciclo de vida seguro? ¿Qué tamaño tiene la deuda técnica que estamos condenados a asumir?

En las empresas en las cuales de desarrolla software, y todavía más en el caso de ciclo de vida seguro, el “retrabajo” causado por la corrección de errores es una de las principales causas de perdida de márgenes. Esto es debido a dos factores:

  • a la cantidad de errores que se introducen en las diferentes actividades del ciclo de vida (errores inyectados)
  • al hecho de que el coste de corrección de un error se dispara de acuerdo a una curva exponencial; cuanto más lejos se detecta el error respeto a cuando se ha inyectado.

Metodología EMC

Desde la plataforma SLI del área de ICT en TECNALIA hemos definido una metodología de cinco pasos para permitir poner la gestión de los errores al centro de la mejora del rendimiento de una organización. Esta metodología la hemos llamado EMC (Error Management Compass), es pragmática y la estamos aplicando con éxito en diferentes empresas tanto españolas como internacionales de diferentes tipos. Por ejemplo, las hemos aplicada tanto en empresas que ofrecen servicios IT con una estructura organizacional distribuida geográficamente, como también en empresas industriales que desarrollan software embebido.

A continuación, intento explicar brevemente en que consiste esta metodología y estaré encantado de proporcionar más detalles a aquellas personas que quisieran profundizar en el tema.

Para poder llegar a usar los errores como el motor de la mejora del rendimiento de nuestra organización/equipo de proyecto/equipo de trabajo, hay que entrar en sintonía con ellos; los errores nos hablan, pero hay que poner las bases para poderlos entender. Esto se obtiene a través de un sistemático registro de estos errores.

¿Para qué tengo que registrar los errores si luego los corrijo?

Esta pregunta es algo que se repite hasta la saciedad en las empresas de desarrollo software. Además, en muchas de ellas hay una fuerte resistencia en hacerlo por el miedo a que se descubra quién es bueno y quién es malo (el maldito enfoque a encontrar siempre el culpable en lugar de la solución…). Otro tipo de resistencia es la que dice: “me cuesta más el registro del error que su corrección”; este comentario nos tiene que hacer reflexionar y pensar en soluciones ágiles y eficientes para el registro de los errores, pero no quita que quien se resiste aduciendo este tipo de excusa, está usando un enfoque muy “egoísta” y parece no haber entendido una de las mayores enseñanzas que nos ha ofrecido este nefasto 2020. La verdadera fuerza no está en el individuo sino en el grupo y, para eso, cada individuo tiene que saber renunciar a algo de su propia comodidad en favor del bien común.

El registro de los errores debería siempre incluir: la actividad de detección que lo ha encontrado; la actividad en el cual se ha inyectado; cuánto ha costado corregirlo y posiblemente cuales han sido los elementos afectados por el error. Con estos datos, es posible hacer ya un análisis que permite tomar decisiones sobre cómo mejorar algunas actividades, sobre qué fase del ciclo de vida enfocar nuestra atención o sobre qué componentes.

Tablas de inyección de errores y modelos

A partir de allí y una vez que la recogida de datos de los errores sea sistemática, el siguiente paso es desarrollar una tabla de inyección de errores. Una tabla de este tipo se construye en base a los datos históricos disponibles de los errores. Cada columna de la tabla es una alternancia de actividades que introducen errores en el producto que se está construyendo (actividades de inyección) y de actividades que los detectan (que podemos visualizar como filtros de errores).

En el desarrollo software y considerando un ciclo de vida sencillo, las actividades que inyectan errores son aquellas actividades como: desarrollo de requisitos, diseño, codificación, etc..; las actividades de detección son “los filtros” que se ponen para que los errores no llegan al cliente: revisiones, pruebas funcionales, integradas, peer-reviews, etc.

Una tabla de inyección de errores nos permite definir el rendimiento de cada una de las actividades de detección de errores que tenemos en nuestro ciclo de vida (que porcentaje de los errores que se deberían detectar, realmente se detectan) y además nos permite tener un primer “olfateo” del coste de corrección de errores en función de cuando se han detectado.

  • Disponiendo de esta tabla de inyección de errores, estamos listos para dar un paso más allá, definiendo un modelo de costes que nos proporcionará la dimensión económica de la gestión de errores, ofreciendo una valiosa información que nos permite tomar decisiones del tipo: “¿merece la pena económicamente mejorar esta fase de detección para que detecte más errores? o “¿cuál es el coste que presumiblemente tendré que asumir si decido no ejecutar alguna de las actividades de detección que tengo definidas en mi ciclo de vida o si la ejecuto solo parcialmente”?
  • Finalmente, el último estado de nuestra metodología EMC, prevé el desarrollo de un modelo predictivo que nos permitiría de antemano, cuando se está por ejemplo planificando un proyecto o después de haber finalizado una de las actividades de detección incluidas en el ciclo de vida, definir la combinación óptima de actividades de detección de errores que minimicen el coste del retrabajo o encontrar el balance óptimo de actividades de detección para maximizar el rendimiento de los “filtros”, sin pasarnos en cuanto a costes necesarios para minimizar el retrabajo.

Cuando se alcanza este nivel en el control de los errores, la organización será además capaz de valorar cuantitativamente y de antemano la conveniencia económica de introducir una nueva actividad de detección, o de modificar una ya existente, o de proporcionar una alternativa de una existente en función de los beneficios económicos que dicha actividad proporcionaría al rendimiento global de nuestro proceso.

Algún dato y conclusiones

Para aportar una visión cuantitativa de los beneficios en aplicar la metodología EMC, se aportan los datos que nos ha proporcionado uno de nuestros mayores clientes, que desde hace cinco años utiliza EMC. everis Centers es una organización descentralizada en nueve países geográficamente distribuidos con una plantilla de alrededor 20.000 personas. Lo que ha alcanzado aplicando la metodología EMC es:

  • aumentar su capacidad productiva en 360.000 horas de desarrollo en cinco años que previamente se dedicaban a corregir errores detectados tarde
  • ahorrar 3.500.000€ en cinco años en costes de desarrollo
  • obtener en el último año unos márgenes extra de 612.000€ por ser más eficientes

Este artículo tenía el objetivo de concienciar sobre la importancia que tiene en nuestras vidas y en la vida de las empresas TI el aprendizaje a partir de los errores que se comenten. Además, quería informar que tenemos las herramientas necesarias para que los errores nos hablen y nos permitan optimizar nuestras actuaciones.

Así que no queda otra que hacer caso a lo que nos decían nuestros padres cuando tenían que consolarnos por la frustración derivada de algún error cometido; y ponernos “manos a la obra” y hacer que de un error podamos aprender y hacer las cosas mejor.

Sobre Giuseppe Satriani Calvi

Kanban Management Professional por la Kanban University, SCRUM Máster y experto en diferentes normas y modelos de mejora de procesos cuales: ISO33000, EFQM, CMMI, Six Sigma. Giuseppe lleva más de 20 años proporcionando su experiencia en apoyar a empresas TI e industriales de todo el mundo en la optimización de los procesos de desarrollo software, vinculando dicha actividad al uso de indicadores cuantitativos y relacionados con la consecución de objetivos de negocio.

Forma parte del equipo de Software and Systems Lifecycle Innovation en el área de ICT de TECNALIA; su actividad principal se centra en el estudio y desarrollo de modelos, métodos y herramientas relacionados con la mejora de procesos y calidad en ámbito de la ingeniería del software. Anteriormente trabajó en Olivetti desarrollando diferentes roles tanto técnicos como de gestión.