La historia del diseñador victima de su diseño.
¡Hola! El día de hoy he publicado en "El Camino de Java, Volumen 2", la nueva sección "Patrones de diseño", donde te hablaré de técnicas para resolver problemas comunes en el desarrollo de software.
El curso se acerca a su fin, y como lo había mencionado, todos aquellos que se inscriban antes de que se publique la última lección, como un agradecimiento a su confianza recibirán un regalo especial.
Y ya que estamos hablando de diseño, me acordé de una historia que en la vida pensé que me sucedería, y difícilmente creo que a alguien le sucederá. Resulta que en la empresa donde en aquel momento estaba trabajando, decidieron implementar un nuevo sistema que iba a cubrir muchas de las necesidades administrativas, las cuales se realizaban con muchos sistemas pequeños, uno de ellos el mío, pero la agencia que había sido contratada para hacer este trabajo era costosa, y por lo tanto querían reducir tiempos cubriendo toda la funcionalidad que se pudiera con el menor número de interfaces. Así que un buen día se me acercó una persona encargada de analizar el funcionamiento de los sistemas actuales para con esta información diseñar el nuevo sistema, le mostré toda la funcionalidad y se fue satisfecho.
A los pocos días, regresó a hacerme una propuesta, cosa extraña porque yo no estaba encargado del nuevo desarrollo, pero de lo que me quería convencer era de implementar la funcionalidad en el nuevo sistema, pero repitiendo algunos tramites. Para no entrar en detalles, imagina que existe un proceso donde tienes que registrar datos en una forma de captura larga, anexas documentos digitalizados, el sistema se encarga de procesar la petición y listo. Bueno pues lo que esta persona quería era hacer una forma de captura larga, obtener un acuse de recibo con datos de la transacción, conectarse a otro sistema, llenar otra forma de captura similar, anexar la información del acuse de recibo anterior, enviar los datos y después ingresar a otro sistema para registrar los documentos digitalizados. Casi me voy de espaldas: ¿Para qué vamos a hacer que los usuarios se metan a 3 sistemas para hacer lo mismo? ¡Eso es absurdo! Cuál es la mejora. Pero me insistía mucho, una y otra vez, como si yo fuera el desarrollador, y después me di cuenta que la razón de su insistencia es que a él le habían encargado que validara los nuevos procesos con alguien que conociera del negocio, y esa iba a ser la justificación para desembolsar los altos costos de desarrollo y de ahí su interés en obtener mi aprobación. No sabes todas las sesiones que tuvimos de acaloradas discusiones, pero para todo tenía una respuesta:
Y muchas mas alarmas, pero con esto te puedes dar una idea. Total que al final se salió con la suya y yo tuve que aceptar casi casi con ellos torciéndome el brazo por detrás.
Pasó el tiempo, el nuevo sistema se implementó, pero no me lo vas a creer porque por azares del destino, esta persona cambió de posición y se convirtió en un usuario del sistema que diseñó. Me enteré porque me di cuenta que seguido pasaba al área de sistemas a pedir soporte, y siempre llegaba con una cara de pocos amigos, hasta que un día me acerqué para saludarlo:
Es que ayer me desvelé capturando información en el sistema y resulta que tiene errores y ahora necesito que me los corrijan. No sabes la risa que me dio en ese momento, y claro le comencé a preguntar del nuevo sistema y solo me respondía maldiciones de lo mal hecho que estaba y todos los problemas que le traía: Terminó trabajando horas extra, haciendo trabajo burocrático y cometiendo errores que le traían más trabajo. ¿No que la gente nunca se iba a equivocar?, ¿No que no iba a implicar más trabajo para el empleado?, no me respondía a nada, seguramente le cayó bastante mal que se lo preguntara, pero lo siento, no pude resistirme jajaja.
Así que la moraleja de la historia es: Cuando diseñes un sistema, no lo hagas pensando en tus necesidades, ¡Piensa en las necesidades del usuario!.
Hasta la próxima
Raúl Cosío