“Sólo la variación puede absorber la variación” (1)ashby
El software es intangible. El Software funcionando es el resultado de un proceso de producción basado en conocimiento, y por tal, muy propenso a variar. En esta publicación, variación significa cualquier cosa que cambie la naturaleza del trabajo.
Hace unas semanas mi auto se rompió y se negó a arrancar. En uno de esos misterios de la vida, cuando llegó la asistencia, el auto decidió arrancar. Como no me sentí muy seguro con esta incertidumbre, llamé a mi servicio prepago y reservé un horario con un mes de anticipación para que lo revisaran. Una semana después del primer evento, el auto no volvió a arrancar. Esta vez, fue en un semáforo. Con las lecciones aprendidas del primer incidente, esperé un rato y conseguí volver a encenderlo. Así que lo llevé al mecánico, quien, para mi sorpresa, me informó que respetarían mi reserva inicial porque estaban trabajando ”a capacidad”, y no tiene tiempo de ver qué le pasa a mi automóvil hasta el momento de mi reserva original.
Las palabras clave de la historia son “A CAPACIDAD”, es decir, “el número máximo de cosas que su sistema de producción puede aceptar”. Implica en esas palabras que no pueden hacer frente a imprevistos como:
- Un coche que se rompa como el mío.
- Una reparación que lleva más tiempo del asignado.
- Una repuesto fuera de stock, que tiene que solicitar y esperar el envio.
Todos estos acontecimientos y otros, introducen “variación”, y su sistema no parece preparado para absorberla. Los síntomas de no poder afrontar la situación, es que pequeñas interrupciones causan grandes perturbaciones.
Ahora, centrémonos en el desarrollo de software. Desarrollo de software es un dominio más intangible que la reparación de automóviles. Como desarrolladores de software, estamos más expuestos a fuentes de variaciones:
- Un coma mal colocada en un string.
- Un requisito cambiante
- Un “‘” abierto en una cadena de conexión
- Un mensaje de error oculto de una API subcontratada.
Como tal, para que el proceso siga fluyendo es imperativo que nos adaptemos a las variaciones. Nuestras iteraciones|sprints no se pueden gestionar “al máximo de tu capacidad”. De lo contrario, no podemos aceptar variaciones/cambios.
- ¿Son tus tarjetas el comienzo de conversaciones?
- ¿Planeas la capacidad de tu equipo al comienzo de cada sprint?
Contame: ¿cuáles son tus fuentes de variación y cómo las manejas en tus interacciones|sprints?
Déjame un comentario.
Yo creo en lugar de variación, Ashby usó la palabra variedad. Prefiero la palabra variación, que me suena más moderna 🙂
