La historia del zapatero de Ikea y la perspectiva del proyecto

La historia que os voy a contar está basada en hechos reales. Aprovechando que tengo unos días libres antes de salir de viaje me he dispuesto a acabar con la fila india de zapatos que tengo por casa. Así que ni corto ni perezoso me fui al Ikea y me cogí un zapatero de esos tan apañado que te montas en casa.

Me puse manos a la obra y decidí seguir las instrucciones que tan amablemente incluyen los suecos a modo de ”paso a paso”. Tras una revisión previa combinada con mis nulos conocimientos en bricolaje y ebanistería, me decidí a seguir los pasos indicados al pie de la letra. El resultado, os lo podréis imaginar, un zapatero impresionante con una de las tablas del frontal colocada al revés, es decir, un precioso acabado en madera virgen…

Me ha dado por pensar los motivos de este pequeño desastre y la analogía de los mismos en los proyectos de desarrollo de Software. Podemos decir que yo he sido el programador currillo que he recibido una serie de pequeñas tareas bien definidas. Estas tareas fueron creadas por un gran analista sueco como resultado de un diseño basado en el análisis de la funcionalidad a cubrir.

Por supuesto, no tengo ninguna duda de que el señor analista sueco creó las tareas de manera correcta en su contexto y en su momento. Lamentablemente en el proceso de “codificación” de mi zapatero se han dado algunas circunstancias inesperadas.

  • Errores humanos
    Tras comprobar de nuevo las instrucciones observo que no se especifica explícitamente el lado que debe dar hacia el frontal y cual no. Obviamente mi decisión no fue la correcta.
  • Falta de comunicación
    La verdad es que el analista sueco no me pillaba lo suficientemente a mano para completar las dudas que me surgían sobre el manual mientras avanzaba el desarrollo del proyecto.
  • Falta de perspectiva e interiorización del alcance global del proyecto
  • He depositado mi confianza en el manual, sin llegar a interiorizar los componentes del proyecto. Si lo hubiese comprendido como un conjunto, me hubiera dado cuenta de que ese madero en el frontal dado la vuelta no encaja bien, pero para cuando  comprendí que eso era el frontal ya era demasiado tarde….

  • Falta de revisiones
    Una pequeña revisión al finalizar cada paso o conjunto de pasos podría haber evitado la desviación. Esto me habría limitado la cantidad de pasos a deshacer para recolocar el maldito madero y por lo tanto, el esfuerzo (dinero en proyectos reales) malgastado en problemas que yo mismo me he buscado.

En el mundo del Software tanto las especificaciones como los entregables son más abstractos. Si no comprendemos bien las necesidades del cliente, (las que nos transmite y las que ni él mismo ha identificado aún!) podemos llegar a las oficinas del cliente con un software que le produzca mas enfado que satisfacción. Dichas necesidades en la mayoría de ocasiones nos son totalmente ajenas y desconocidas puesto que no conocemos profundamente el sector del cliente (Al menos en los primeros proyectos tipo!).

Sin trabajar este proceso de interiorización apoyado en la empatía, podemos entregar el zapatero al cliente sin enterarnos de que tenemos el madero al revés aunque lo estemos mirando con todo detalle…

Así que dicho queda, me voy a por la caja de herramientas de nuevo…

8 comentarios en “La historia del zapatero de Ikea y la perspectiva del proyecto”

  1. Andoni, soberbia descripción y comentarios de un proceso tan cotidiano como normal y que todos hemos hecho o por donde todos los que nos dedicamos al desarrollo del Software hemos pasado.

    Está claro que el desarrollo Software no es una tarea fácil, aunque en muchas empresas se empeñen en verlo como algo muy sencillo.

    Muchas gracias por emplear las similitudes y estar atento a ellas. 🙂

    Un saludo,

    Jorge

  2. lamento no coincidir contigo.
    Tengo sobrada experiencia en montaje de muebles ikea, y tengo que decirte que sus manuales de montaje son los mejores, no sólo en su ambito, sino en cualquiera.
    Vuelve a mirar el manual, seguro que ves algun detalle que indica la posicion de la pieza.
    Si te fijas bien, son como dibujos de los diseños originales. La posición de los agujeros de los tornillos, lo que se ve y/o no se ve en esa perspectiva.
    Si pones tu pieza en la misma perspectiva del manual, verás algo, que al revés no verías.

    No es broma, los de ikea son increibles.

    P.D.: Lamento ponerme del lado del sueco, aunque en la moraleja estoy de acuerdo contigo.

  3. Que bueno, me gusta la extrapolación que has hecho al mundo del software…

    De todo modos ¿a qué al final has logrado montar el mueble?. A pesar de los problemas de especificación y de comunicación lo has logrado.

    ¿Cómo? Mediante visibilidad (miras el mueble y ves que el cajón no cierra), inspección (analízas el problema) y adaptación (modificas tu comportamiento para que el cajón siguiente se cierre bien). Esa es la clave, ese proceso iterativo es el que resuelve los problemas: Gestión empirica de procesos.

    Lo vimos en mi curso de Scrum al que acudiste… pero no se si te habías parado a pensarlo cuando has escrito el post ;).

    ¡Un saludo!

  4. No estoy de acuerdo del todo con lernar ni pirri.

    Me importa un bledo, que haya una una marquita en una esquina que indique que ese es el frontal. Si no ha llegado al “programador”, no tiene por que ser siempre su culpa. Además conozco tantas personas que dicen que montar un mueble de ikea es fácil como personas que dicen que es difícil. Depende de lo acostumbrados que estén a interpretar manuales de instrucciones, etc.

    En una comunicación, siempre hay un emisor un receptor y un canal. El canal pueden ser unas espcificaciones, el uso del castellano, un manual gráfico estilo ikea…

    Yo creo que es más justo repartir la culpa. Quiero decir que si Andoni no vio la marquita, puede que no fuera tan evidente…

  5. Karbunko, tu mismo dice en tu comentario una de las grandes verdades, por lo que lernar si tiene gran parte de razon, “Estar acostumbrado” un buen programador debe de estar acostumbrado a analizar correctamente una buena documentación igual que un buen montador de muebles de ikea tiene que estar preparado para analizar correctamente cada uno de los pasos, lo que ha ocurrido en el caso de andoni, es que mi padre ha cogido un manual de programación y ha intentado hacerse una base de datos en access, al final el informe no mostraba bien los datos. no podemos confundir los roles que hay en la historia de andoni, un programador novato de muebles es igual que un programador novato de aplicaciones, por eso andoni se equivoco al montarlo, aunque tenia una buena documentación error en sus conocimientos de montador.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *