La historia del zapatero de Ikea y la perspectiva del proyecto
El siguiente artículo, del blog Andoni Arroyo de geeks.ms, representa muy bien, con un ejemplo cotidiano real, lo que suele ocurrirle al programador a la hora de construir una aplicación, especialmente si se saltan todos los procesos “que no sirven para nada”, pero bueno, esto es otra historia…
Os dejo el fragmento de texto:
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
- 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.
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….
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…
Ahora bien, no creo que Ikea invierta demasiado en las instrucciones, ya que yo también tengo un caso similar, aunque viendolo por otro lado, la mayoria de las empresas tampoco invierten en los procesos de diseño y documentación necesarios…
Fuente: Blog Andoni Arroyo – geeks.ms<
