Artículos - Introducción


Aquí encontrará artículos de miembros del Instituto Lean Management, así como de autores de la Lean Global Network que puede encontrar en versión original en:

 

   

 

 

Usando kaizen, un equipo de Theodo pudo reducir el tiempo necesario para instalar un proyecto en el ordenador de un nuevo desarrollador desde tres semanas a doce minutos.

Cuando los desarrolladores se unen a un proyecto, la incorporación comienza instalando el proyecto en su ordenador para que puedan comenzar a trabajar. Esto es muy similar al cambio de troqueles que vemos en una planta de producción.

Hace unos meses, me uní a un proyecto en curso aquí en Theodo y me sorprendió ver que me llevó dos días instalarlo. Para mí, esto no era aceptable, especialmente teniendo en cuenta que en nuestra empresa instalamos proyectos con mucha frecuencia (160 veces en 2018). En mi opinión, esta tarea no debería tomar más de 30 minutos, así que elegí este período de tiempo, media hora, como estándar y decidí comenzar un kaizen.

Aprovechamiento de la automatización para eliminar errores humanos

Comencé mapeando todos los pasos del proceso de instalación para incorporar a un nuevo desarrollador, cada uno de ellos tomando de 1 a 4 acciones humanas, como se describe en este gráfico:

Luego, clasifiqué los pasos y eliminé los que consideraba innecesarios. Por ejemplo, descubrí que la "Configuración de credenciales en la máquina virtual" era innecesaria, porque la creación de la máquina virtual genera automáticamente credenciales. Esto significaba que no teníamos que configurar otros nuevos, un buen ejemplo de 5S digital.

Entonces decidí automatizar el proceso, porque estaba cometiendo muchos errores al seguirlo. Por lo tanto, escribí un script para ejecutar todos los pasos restantes y logré obtener el tiempo de instalación por debajo del umbral de 30 minutos. (El primer paso, "Instalar dependencias globales" fue el único que dependía del ordenador que usa el desarrollador. Esto hizo que la automatización fuera más complicada, así que lo dejé como estaba).

Poka-yoke al rescate

Poco después, cambié los proyectos nuevamente y, una vez más, me encontré con un proceso de instalación muy complejo. Implicaba unas 40 páginas de instrucciones, y me llevó tres semanas instalar el proyecto localmente.

Como respuesta, apliqué el estándar que he diseñado para simplificar el proceso de instalación. Cuando el próximo desarrollador se unió al equipo, le llevó menos de 15 minutos instalarlo.

Sin embargo, cuando un par de meses después un nuevo desarrollador se unió al proyecto, le tomó 50 minutos. Se quedó atascado cinco veces porque cometió errores durante la instalación de dependencias globales.

Esta historia me impulsó a agregar un nuevo estándar: debe haber una verificación automática de que cada dependencia global esté instalada y sea funcional. Por lo tanto, añadí un script que verificaría la instalación de todas las herramientas necesarias para el proyecto. Lo hice mostrar en una sola línea en la dependencia faltante o rota cuando falló.

Después de esas mejoras, eliminé un par de cientos de acciones manuales. Las siguientes instalaciones les tomaron a los nuevos desarrolladores un máximo de 12 minutos.

Las secuelas

Con el tiempo, seguí haciendo kaizen en docenas de proyectos. Hasta la fecha, he creado los siguientes estándares:

  • Se enumeran todas las dependencias externas y el desarrollador tiene una manera de saber cómo resolverlas.
  • Para garantizar que las dependencias globales estén instaladas correctamente, hay una comprobación automática. Hay al menos un conjunto conocido de dependencias globales que se sabe que funcionan.
  • La instalación es automática (una vez que se instalan las dependencias globales).
  • La instalación siempre funciona en el primer intento. Lo que significa, por ejemplo, que no puede haber una sección de solución de problemas en la documentación.

Ahora estoy empezando a darme cuenta de que mi objetivo inicial de instalar en menos de 30 minutos no debería ser la primera preocupación del desarrollador, ya que deberían centrarse en hacer que funcione bien la primera vez.

Si reflexiono sobre mi experiencia desde una perspectiva Lean, veo que mi viaje es muy similar a la metodología SMED.

La esencia del SMED es comenzar por mapear el proceso e identificar qué pasos requieren que la producción se detenga, los que se llaman internos. Luego conviertir tantos pasos internos como pueda en pasos externos, lo que significa que ya no requieren que la producción se detenga. Y, finalmente, garantizar que todos los pasos externos sean fiables.

Al igual que en una planta de producción cuando una máquina pasa por un cambio, el desarrollador necesitaba detener la producción de características y centrarse en la instalación. Los pasos de instalación ya estaban definidos, pero requerían toda la atención del desarrollador: eran internos.

Al automatizar la instalación, simplifiqué un proceso de docenas de tareas internas y lo reemplacé con varias tareas externas, ya que el desarrollador ya no tiene que manejar la secuencia de comandos por sí mismo.

El último paso es simplificar los pasos que aún requerían la atención del desarrollador: manejo de errores y dependencias globales.

 
Clément Hannicq
Architect Developer en Theodo
 

Extraído de: Planet Lean


Más leídos