Es de esas temporadas, que como otras tantas veces te he contado, que no sé por qué será que se repiten las mismas situaciones en diferentes sitios y cuando pasa eso… hay que convertirlo en post.
Además, en este caso, el tema de hoy pedía a gritos ser una continuación de «Cazadores de Desperdicios» (te dejo el post previo sobre desperdicios y estimaciones).
Vamos primero con lo obvio. Los desperdicios de hacer la cosas corriendo y mal están claros, ya hemos hablado mucho de ello y por ello no me quiero parar aquí. Ya hablamos en su día, y te dejo enlaces, del trabajo superfluo (la imagen de abajo de instagram y aquí va post), hablamos sobre deuda técnica, etc.
Dicho lo obvio… ahora viene lo difícil. Se puede hacer algo (una Historia de Usuario, por poner un ejemplo) muy mal (y rápido) o se puede hacer algo rozando la perfección (echándole, obviamente, muchas horas)… ¿Qué deberíamos hacer? ¿Qué opción es mejor? ¿Qué tiene más desperdicio?
Cualquiera de los extremos no parece la mejor idea, un punto intermedio parece mejor opción… ¿cuál es ese punto? No hay una solución algorítmica, ni un workflows, ni una checklist que de la mejor solución a este problema. A lo que debería llevar este tema de hoy es a… Reflexionar antes de ponerse a añadir calidad hasta el infinito (el problema de añadir calidad cero ya está comentado).
Normalmente, a la gente de negocio, managers, gente no técnica, etc., les suele gustar que las cosas se hagan rápido y no suelen ser conscientes de que eso implica que se hagan mal y que luego, tiempo después, vuelvan a aparecer los errores de haber hecho las cosas rápido. Trabajo superfluo. Desperdicio.
En un modelo Ágil, en el que las estimaciones y decisiones de cómo resolver un problema son potestad del equipo técnico, muchos equipos, quizá por el sufrimiento de años pre-ágiles, se pasan al otro extremo… exceso de horas para dejar las cosas perfectas. Desperdicio.
Hay que decir que, simplificando, que el número de «cosas» para hacer algo perfecto tiende a infinito. Pongamos el ejemplo del Testing, ¿cuántas pruebas hay que hacer para asegurarnos 100% de que algo no va a fallar? Típicamente… infinito (es imposible asegurar que una aplicación software no va a fallar).
Si nos pasamos de perfección bajará en exceso la velocidad, si nos pasamos de rapidez aumenta el desperdicio por el trabajo superfluo y bajará la velocidad.
Hacer algo tendiendo a la perfección no es siempre la mejor opción, incluso creo que puede ser, en muchos casos, la opción fácil. Incluso tiene pinta de modelo predictivo no-ágil, de aquellos tiempos en que se hacían un montón de cosas «por si acaso» (y luego nunca llegó su utilidad).
Cuestión de probabilidades y de mover las neuronas, añadir un elemento de aumente la calidad y que tendrá aplicación con una probabilidad del 5%… tiene pinta de que podríamos pasar de ello.
Cómo el calculo de esa probabilidad es imposible… toca mover las neuronas.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Truco (con IA o sin ella) para espiar (legalmente) a tu competencia - 6 marzo, 2025
- Lo que NO te aconsejo hacer si quieres que SI se valore tu conocimiento - 27 febrero, 2025
- Como una PIZZA te puede dar una clase magistral de IA - 20 febrero, 2025