miércoles, 18 de marzo de 2015


Juan Manuel González Porter.
FactoríaUx de Steelmood.

Hace apenas dos semanas inicié un debate en el Foro del International Institute for Business Analysis, grupo incluido en la red profesional Linkedin. El tema elegido para dicho debate fue: “Prototyping tools as means to capture requeriments” (Herramientas de prototipado como un medio de captura de requerimientos).

El tema lo elegí motivado por una conversación entre Steelmood y un cliente que versaba precisamente sobre la captura de requerimientos. En las dos semanas transcurridas desde que abrí el debate en la red, el tema capturó la atención de más de quince profesionales que leen este foro, con más de treinta y cinco opiniones, lo cual me catapultó a “Top Contributor”, pero lo más importante son los resultados del debate.

Para empezar, ¿por qué seleccioné este tema? Al usar herramientas de prototipado existe un riesgo de que se tomen decisiones que corresponden a la implementación durante la fase de captura de requerimientos. La fase de captura de requerimientos debe definir lo que el negocio necesita, pero sin restringir la implementación (excepto cuando la restricción es un requerimiento en si). Mi intención fue desde un principio pulsar la opinión y la experiencia de otros profesionales en el mundo del análisis de negocio respecto a este tema.

Las reacción fue casi unánime: el uso de herramientas de prototipado es aceptado por los analistas de negocio. Muchos de ellos usan herramientas comerciales como axure, balsamiq, iRise o invision durante la elicitación (hay una buena comparación de éstas herramientas aquí:  http://www.cooper.com/prototyping-tools)

La opinión general es que los prototipos ayudan a clarificar los elementos gráficos y de uso. Además está generalizado igualmente la opinión de que reducen significativamente los malentendidos en este área de especificación, siempre difícil de manejar, pues sin prototipos es fácil cometer errores de interpretación en este área abstracta.

Se tienen que tomar en cuenta los siguientes puntos:

  1. Involucrar lo mínimo posible en esta fase a los diseñadores que se encargarán de implementar la solución final, para asegurar que los prototipos cumplan con su propósito de especificación, y evitar que se mezclen con implementación.
  2. Los prototipos deben ser lo suficientemente detallados para definir lo que se tiene que implementar, pero no demasiado detallados que limiten las opciones.
  3. Los prototipos deben ser documentos "desechables" que cumplan con los lineamientos de "lean": todo trabajo hecho que no llega al producto final es un desperdicio. 
  4. En contextos ágiles, la situación cambia radicalmente: el prototipo se puede incluir en las activamente en el refinamiento del prototipo. De esta manera el prototipo no es un documento "desechable" pero se convierte en un elemento vivo del proyecto.


0 comentarios:

Publicar un comentario