EdG: Speed Challenge

0

El vídeo de la escena de gestión de hoy viene directamente sacado de un post de el laboratorio de las TI, de Julián Gómez. En el post Julian muestra dos vídeos en los que se intenta dibujar algo en 10 minutos, en 1 minuto y en 10 segundos. En el primer video queda clara la calidad del resultado por el tiempo invertido.

En el segundo vídeo, y que os traigo de la escena de gestión, parece todo lo contrario. El resultado no se degrada tanto por el tiempo, con lo que a priori se podría pensar que realmente esa tarea requiere menos tiempo, y dedicarle más es sufrir de overengineering o de principio de Parkinson. Pero yo saco una lección muy diferente, y eso me ha motivado al artículo.

Si nos fijamos cuando hace el primer dibujo, el pintor no sabe muy bien a dónde llegar. Así que tantea distintas opciones. El árbol central pasa por varios prototipos, que hace y rehace hasta llegar al definitivo. Incluso prueba a pintar pájaros, que luego retira pintando un árbol encima. Sinceramente, se parece mucho a un equipo agile iterando, y corrigiendo el resultado en cada entrega.

En el siguiente dibujo, ya sabe claro lo que tiene que hacer, así que va al grano. No se va por las ramas, y pinta justamente lo que quedará en el resultado. Pero parece que la experiencia de pintar en poco tiempo no la tiene dominada y tiene importantes desperdicios. Si os fijáis invierte 10 segundos en “cargar” el pincel antes de empezar. Cuando el pincel llega el cronómetro ya marca 00:50, indicando que ha desperdiciado 10 segundos.

En el último dibujo se aúnan dos ventajas: sabe lo que quiere, y sabe obtenerlo en poco tiempo. Ha identificado los desperdicios, y va al grano.

Así que saco dos lecciones importantes:

  • Al realizar un ciclo y evaluarlo, aprendemos. Mejoramos. Nos hacemos más productivos. Tenemos menos desperdicios.
  • El valor del producto que se obtiene no es sólo el producto en sí mismo, sino el conocimiento de lo que se necesita.

Cuando nos planteamos rehacer aplicaciones de cero, porque el legacy nos ahoga, o porque estamos inmersos en una transformación digital, muchos consideran que estan tirando a la basura toda la inversión en ese producto. Y no es cierto. Sólo se tira una pequeña parte, el código. Lo que más valor aporta en una aplicación que lleva una década de evolutivo, es el conocimiento de negocio adquirido. Es saber perfectamente qué necesitamos y cómo lo necesitamos. Es saber dónde estarán los retos. Es saber en qué partes del código tendremos que fijarnos en el rendimiento y en cuales no. Es saber qué partes habrá que monitorizar. Eso vale muchísimo más que el código. Y siguiendo el símil del vídeo, podemos hacer en menos de una décima parte del tiempo un producto decente, ya que el 90% del tiempo lo tendremos ahorrado gracias al conocimiento invertido.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

Sin comentarios