El problema con definir los requisitos de información

by Tim Bryce - 29 Abril 2009

Analista de sistemasComo muchos de ustedes sabrán, he sido miembro activo de la industria informática (TI) por mucho tiempo. Es un negocio extraño y, para ser sinceros, a veces deseo nunca haberme involucrado en ella. Hay muchos problemas asociados a TI, tales como performance de las computadoras, planificación de capacidad, seguridad, redes, recuperación de catástrofes, pero el problema mayor es probablemente la definición de requisitos. Es decir, definir con precisión las necesidades de información del usuario final. La industria informática es realmente buena en diseñar y escribir software, implementar bases de datos, y adquirir el hardware, pero a pesar de los años transcurridos todavía tiene problemas en comprender que es lo que el usuario necesita para hacer funcionar parte de su negocio. Por lo tanto, inevitable se entrega una solución incorrecta al usuario, causando una enormidad de tiempo y dinero perdido en el re-trabajo de una solución que satisfaga las necesidades del usuario.

Me acuerdo de la historia de un director de TI en una compañía de fabricación de zapatos que recibió una llamada de un encargado de ventas pidiendo ayuda con un problema acuciante. El director solicitó a uno de sus programadores que se reúna con el encargado de ventas para discutir el problema. Básicamente, el encargado deseaba un listado de todas las ventas de zapato clasificadas por modelo, cantidad, tipo, color, etc. El programador inmediatamente supo como tener acceso a los datos necesarios y los clasificó de tal modo que produjo un listado voluminoso (metro de alto) que diligentemente entregó al usuario.

El director pasó por la oficina del encargado de ventas unos días después para investigar si el programador había solucionado el problema del usuario. El encargado de ventas elogió la desempeño del programador y señaló orgulloso al imponente listado que se encontraba sobre su escritorio. El director entonces le preguntó cómo utilizaba el listado. El encargo le explicó que lo llevaba a su casa los fines de semana, filtraba lentamente los datos, y luego construía un informe sobre las tendencias de ventas.

“¿Le explicó al programador que usted iba a hacer esto?” le preguntó el director.

“¿Se da cuenta que le podríamos haber producido el informe que usted necesita y evitarle un montón de tiempo y esfuerzo?”

“No.”

Éste es un ejemplo clásico de un ciego guiando a otro ciego. El usuario no supo como describir adecuadamente su problema, y el programador hizo las preguntas incorrectas. Sin embargo, el encargado de ventas y el programador estaban encantados con los resultados. El director sacudió su cabeza en incredulidad.


Éste es un escenario típico que ocurre todos los días en el mundo corporativo. Ambos lados sienten la frustración, el usuario y la gente de sistemas. El usuario típicamente se pregunta: “¿Por qué no pueden darme lo que quiero?” Y la gente de sistemas afirma: “El usuario no sabe lo que quiere.” Considero que el usuario sabe lo que necesita desde el punto de vista del negocio, pero tiene problemas con la jerga técnica. Pero a su vez, el usuario no tiene porque aprender la jerga del mundo de sistemas. Esto sería análogo a forzar al usuario a aprender conceptos de arquitectura para diseñar un rascacielos, algo que toma a los arquitectos años de aprendizaje.

Por el contrario, la gente de sistemas tiene que escuchar al usuario (como lo hacen los arquitectos) e interpretar cuidadosamente lo que él necesita. Se debe realizar con el usuario una revisión de los requisitos de información, usando vocabulario que el usuario entienda, porque si los requisitos son incorrectos, todo lo que siga será incorrecto.

Para interpretar correctamente los requisitos, la gente de sistemas debe decir algo al efecto: “Asumiendo que le doy la información que usted desea, en la forma que usted la desea, ¿qué hará usted con ella? ¿Qué acciones y/o decisiones tomará con la misma?” Solamente cuando la gente de sistemas pueda de verdad ponerse en los zapatos del usuario, tendrá derecho a construir un sistema para el usuario.

Hace años, Monty Python hizo un sketch donde el papa discutía con Miguel Angel, el artista del renacimiento, su famosa obra “La última cena.” En el sketch, el artista malinterpreta los requisitos del papa y produce inicialmente una pintura que incluye una escena que muestra una gelatina, un canguro, una banda de Mariachis, 28 discípulos, y tres Cristos. El papa, por supuesto, no estaba satisfecho. Miguel Angel, a pesar de sus protestas, es forzado a cambiar la pintura. El papa cierra diciendo, “Puede que no sepa mucho de arte, pero si sé lo que quiero.

Esta misma expresión puede ser parafraseada por el usuario final para describir el problema de la definición de requisitos, “Puede que no sepa mucho sobre tecnologías de la información, pero sé lo que necesito para conducir mi negocio.”

Una solución elegante para el problema equivocado no soluciona nada.” – Ley de Bryce



Para obtener información adicional sobre esta temática, vea la metodología de ingeniería de sistemas de información “PRIDE” – (ISEM). Si desea discutir este tema conmigo en mayor profundidad, no dude en enviarme un e-mail.

Tim Bryce es un escritor y consultor en administración de empresas radicado en Palm Harbor, Florida . También es el Director General de M. Bryce y Asociados, una firma de consultoría gerencial situada en el área de Tampa Bay, Florida


timb001@phmainstreet.com
Copyright © 2008 Tim Bryce.

Todos los derechos reservados

Leave a Reply