Son bien ricos los tamales, pero esos tamales de la calle, del tianguis. Incluso esos oaxaqueños don
de ¡el carrito va a tu casa!
Ya es clásico escuchar el grito de “HAY TAMALES OAXAQUEÑOS” y que mejor servicio que solo salir a la calle, pedir un tamal, pagar y listo.
Pero, el otro día fui a un restaurante y pedí “tamales gourmet”. Según el slogan eran “hechos a tu medida y gusto”. Y pues, mi medida y gusto me indicaban que quería unos verdes con pollo (a lo mejor ese fue mi error, pedí el tamal clásico).
Pero este proceso, fue tortuoso.
Primero, el esperar a que me dieran mesa, hacer el pedido, (que aqui hubo un problema ya que el mesero confundió las ordenes) esp
erar a que lo prepararan, lo cual llevo alrededor de 25 a 30 minutos, llego a mi mesa y aquí viene lo peor.
¡EL SABOR DEJABA MUCHO QUE DESEAR!
El tamal del carrito de la calle era mucho más rico y lo entregaban en menos tiempo.
Y no hablemos del costo, ya que el del carrito era la mitad.
Si lo vemos de cierto punto de vista, en el carrito pagamos por el producto tal cual, no tenemos que esperar lugar, a que nos lleven el tamal, simplemente lo pedimos, lo entregan y pagamos.
Menos gasto, menos costo.
A diferencia que uno de restaurante, donde tenemos que pagar el lugar, el mesero, el transporte del producto y el servicio, ah sí, también el tamal.
Es por esto que se llama esta entrada “tamales esbeltos” por su relación con las prácticas y principios de “Lean” donde nos enfocamos en reducir el tema del desperdicio.
Y así como hay mucho desperdicio en temas de transportar alimentos, pedir órdenes y pagar entornos que no ayudan al producto, estas situaciones también afectan el desarrollo de software, siendo los siguientes 7 los principales
Desperdicio #1 – Trabajo hecho a medias
Dejar cosas en “desarrollo” por mucho tiempo trae problemas ya que es código que hay que compilar mientras desarrollamos otras cosas y seguramente fallara si cambia alguna interfaz.
Desperdicio #2 – Funcionalidad extra
Cualquier cosa que no se haya solicitado, es un desperdicio, ya que probablemente no aporte ningún valor o solo aporte poco valor. La funcionalidad extra añade complejidad, es un nuevo punto de fallo, implica mayor mantenimiento. Sin mencionar la funcionalidad extra que decide incorporar el desarrollador simplemente porque le gusta o le motiva.
Desperdicio #3 – Reaprendizaje
Nuestra memoria está limitada y tendemos a ir olvidando lo que no usamos normalmente, y si tenemos que volver a usar algo tenemos que aprender de nuevo cómo usarlo. Cualquier proceso de reaprendizaje es un desperdicio y debe evitarse siempre que se pueda.
Tomar requerimientos demasiado temprano o encontrar bugs más tarde de llevarse a cabo el desarrollo, es un desperdicio ya que habrá que releer los requerimientos y entenderlos de nuevo, o revisar los bugs y modificar desarrollos posteriores si ha pasado mucho tiempo.
Desperdicio #4 – Transferencias de conocimiento
Este ocurre muy frecuentemente, es como el teléfono descompuesto. El product manager toma los requerimientos del cliente, éste se lo pasa al analista, y este se los pasa al arquitecto técnico, éste al programador, después al tester, ¿Les suena conocido?
Desperdicio #5 – Retrasos
Las depend
encias con gente de fuera del equipo. Los vistos buenos de esos “dioses del olimpo”, revisiones, validaciones de gente que no tiene el contexto.
Esto normalmente conlleva al cambio de contexto, ya que en esos momentos de espera, es común que se asigne otra actividad o se hagan trabajos parciales.
Desperdicio #6 – Cambios de contexto
Cuando tenemos varias cosas que se deben hacer de forma inmediata, tendemos a intentar hacer varias cosas a la vez. Como nuestra mente no es multitasking, lo que hacemos es cambiar de contexto y por tanto no avanzamos.
Aunque aquí podemos aplicar Kanban, es necesario tener definidas las prioridades y mantener el foco (Ver Kanban)
Desperdicio #7 – Defectos
Si, nadie es perfecto, pero si somos capaces de detector el mayor número de bugs en desarrollo, estos se corregirán inmediatamente, ya que mientras más tiempo vivamos con ellos, su resolución será más complic
ada. Por lo cual, siempre deben estar incluidas las pruebas como parte del trabajo diario.
Hacer pruebas unitarias, de integración y validar criterios de aceptación son buenas prácticas, pero deben apoyarse de más actividades que nos ayuden a revisar nuestro código (Test automatizados, funcionales, exploratorios, etc.)
De esta forma, haremos que nuestro desarrollo evite muchos temas de desperdicio y sea tan delicioso como esos tamales de carrito.