Toma de requisitos - Paso 4: Presentar el prototipo

Hola, hoy vamos a ver el paso siguiente (Paso nº 4 en nuestra secuencia) en la definición de los requisitos, y para ello, tendremos que presentar a los usuarios, el prototipo que con tanto mimo hemos creado.

Esta entrada forma parte de una serie cuyo índice es el siguiente:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

En primer lugar, hay que hacer notar que la primera versión de un prototipo difícilmente va a gustar a los usuarios. Es algo normal, sus expectativas no van a cubrirse en esta primera versión.

Lo que hay que buscar en realidad es el feedback de dichos usuarios clave: sus comentarios son oro. Y lo son, porque tan sólo cuando esos usuarios ven el prototipo, la maqueta de nuestra aplicación, es cuando van a darse cuenta de detalles que habían pasado por alto, de información que difícilmente podría ser obtenida de otra manera.

Por supuesto, a los usuarios hay que dejarles claro que es un prototipo: ni hemos tenido un avance del 40% del proyecto en dos días, ni los problemas que vayan a surgir en la revisión han de ser tenidos en cuenta. Hay que tranquilizar a los usuarios en este sentido: aún estamos muy lejos de cerrar el prototipo, y por tanto, aún más lejos de tener avanzado el desarrollo del producto.

Es en esta fase cuando tendremos que hacer un auténtico ejercicio de usabilidad: conseguir no sólo que los requisitos se satisfacen, que han sido correctamente identificados. Además de esto, el producto debe ser sencillo, lógico, fácil de usar.

Es importante notar que en esta fase, hay que estar volcado al 100%, y hay que tener experiencia en el área que estamos prototipando. Si no es así, ni va a ser sencillo de usar, ni tampoco va a satisfacer las necesidades de los usuarios.

El objetivo final de esta fase es conseguir el apoyo, la excitación de los usuarios al lograr consciencia de que efectivamente, hemos entendido sus necesidades, y además, el producto va a facilitarles el día a día. No se trata de "satisfacer requisitos", sino más bien de satisfacer a los usuarios finales.

En esta fase, puede pensarse que se está perdiendo un tiempo precioso en algo que va a tirarse a la basura. Después de todo, ese es el final de todo prototipo. Nada más lejos de la realidad. Al contrario, todo el esfuerzo invertido facilitará y acelerará el desarrollo posterior, evitando problemas, revisiones, y cambios de última hora.

Como ya he comentado, es fundamental aclarar a los usuarios que el producto es un prototipo, un mero "esbozo" de la realidad que aún está por construir. Por eso, al final, vuelve a servir lo que comentaba en el artículo anterior, en el paso 3: las herramientas de prototipado simples como el Paint o PowerPoint, o un dibujo en un papel, son mucho más efectivas. Esto es así porque el usuario las percibe como algo realmente temporal, no aprovechable. Si nos liamos a hacer mucho código, HTML, css, JavaScript, menús desplegables, etc, etc el usuario pensará que lo que está probando es ya un producto real. Después de todo, se instala, se usa, y da resultados como un producto real. Si caemos en la trampa de dar un prototipo demasiado realista, el cliente pasará a meternos presión, ya que pensará que le estamos engañando, y que en realidad, tenemos ya avanzado buena parte del desarrollo.

Es importante dar también una fecha límite a la fase de revisión del prototipo: 2 o como máximo 3 revisiones de prototipo, deberían ser suficientes. Si nos alargamos en su revisión, sí que podremos poner en peligro el plan general del proyecto.

Si quieres volver al índice haz clic en: Índice.
También puedes ir al paso anterior de la toma de requisitos haciendo clic aquí: Paso anterior.

Toma de requisitos - Paso 3: Cómo hacer un prototipo

Para que tu prototipo sea a prueba de idiotas...busca uno

Hacer un prototipo no es tan fácil como parece. Conviene seguir unas reglas, para que a la hora de continuar el desarrollo, no nos encontremos con problemas. Veamos un poco de qué hablo.


Esta entrada forma parte de una serie cuyo índice es el siguiente:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Simple.

El prototipo ha de ser simple. Se trata de ofrecer al usuario alternativas, de que pueda explorar cómo va a ser el sistema. Es por tanto el momento de explorar, de ofrecer opciones en cuanto a usabilidad, estilos, etc.

Alcance.

Se trata de ahorrar esfuerzos. No hace falta explorar todas las posibilidades, de abordar todos los casos de uso. De ofrecer todos los mensajes de error. De lo que se trata es de que el usuario reciba suficiente feedback de cómo se va a comportar el sistema. Para ello, hay que definir un alcance limitado, para que los esfuerzos de desarrollo también lo sean.

Por ejemplo, nos limitaremos a realizar los principales casos de uso. Es más interesante que cubramos una operación completa de varias pantallas, que por ejemplo cubrir una acción en cada pantalla.

El usuario no va a ser consciente de que funciona todo o parte en cada pantalla. Lo importante es que hemos cubierto una parte mayor de la aplicación. Por ejemplo, en un ERP haremos un alta en almacén, un alta de cliente, un alta pedido de ese cliente, y facturaremos ese producto para finalmente, contabilizarlo. Un caso de uso simple de cada pantalla, de forma que se cubra una gran parte del sistema.

Es más importante obtener la visión del look&feel, de qué se hace y cómo.

Herramientas.

¿Qué herramientas utilizar?Las más simples. Podría utilizarse HTML puro y duro en lugar de Java o código .Net. Pero tampoco es descabellado prototipar con herramientas más cercanas al diseño como Visio, Powerpoint o el mismísimo Paint que viene de serie en Windows.

¿Porqué no usar algo más elaborado como una herramienta profesional de prototipado? Pues porque precisamente en esta etapa, y los seguidores de las metodologías ágiles lo sabrán muy bien, no sirven mucho. Y no sirven, no porque sean malas, sino porque en esta etapa los requisitos aún son muy volátiles. Estas herramientas de prototipado pretenden ahorrar esfuerzo posterior, creando un sistema aprovechable. Sin embargo, el sistema no se va a aprovechar. El gran número de cambios lo echaría atrás. Claro, esto no ocurre cuando los requisitos tengan poca volatilidad. En ese caso, el sistema sí que puede prototiparse con herramientas que nos permitan en el futuro aprovechar los flujos, la estructura, o incluso el código.

Una recomendación: por simple que sea nuestro prototipo, si tiene código, siempre puede tener un error. después de todo es un prototipo. ¿Vamos a poner código de gestión de errores? ¿De logging? ¿Y qué más? ¡Si no hace falta! Queremos mostrar qué se va a hacer, nada más. Una pantalla Powerpoint, una imagen hecha con una herramienta de dibujo rápido, sería suficiente. Que la herramienta haga el trabajo por nosotros: para pasar de una pantalla a otra, usemos las acciones de Excel, de Powerpoint por ejemplo.

Otra ventaja de los prototipos hechos como "documento", es que difícilmente tienen errores. No dependen del PC en que se van a ejecutar. Se pueden mandar al cliente, ejecutar directamente desde un correo, sin instalación. Ni siquiera hace falta que se copie una carpeta con código HTML en el escritorio. Con que esté instalada la aplicación (Word, Excel, Powerpoint...es suficiente). Con algunos productos, es posible convertirlos en "ejecutable", de forma que en cualquier PC con Windows funcionen.

 

Detalles.

Los detalles, hay que cuidarlos pero con mínimo esfuerzo. ¿Que hay que sacar un informe al pulsar el botón "Imprimir"? Pues se muestra un documento de texto simulando el informe, o se muestra una imagen que muestre un informe típico.

Si queremos ahorrar esfuerzo mostrando datos encolumnados, nada más simple que usar una Excel, pegar ahí los datos a mostrar, y al ocultar la cuadrícula de fondo...¡premio! Tenemos un report simulado. También podemos simular la paginación, poniendo imágenes en celdas de forma que parezcan el botón "siguiente", y que dicho botón sirva de hipervínculo a la página siguiente del informe (también simulada, por supuesto).

Esfuerzo

Con todo lo dicho, hay que conseguir máximo en diseño, estilo y apariencia...pero con el mínimo esfuerzo. Si los datos son fijos, o se muestran en una imagen, no importa. Pero el esfuerzo por pantalla o acción debe ser el menor posible.

Es muy importante repartir adecuadamente el esfuerzo durante el prototipado. Si contamos con equipo que conozca el diseño gráfico, utilicémoslo. Si alguien conoce Powerpoint y su facilidad para crear vínculos y botones que nos lleven de una slide a otra...adelante. Es mejor que el equipo se sienta a gusto y explote una herramienta, que nos perdamos intentando usar la última "mega-herramienta-de-prototipado" del mercado.

La profundidad funcional ha de ser muy liviana. Si dedicamos por ejemplo más de 1h por pantalla, ya es demasiado. Mejor centrarse en pintar el aspecto y que "de el pego", que dedicar la hora a cargar datos XML y aplicar una hoja de estilos.

Como veo que el artículo me está saliendo muy largo, si no os importa, dejaré para una segunda parte todo lo que tengo en mente seguir contando sobre los prototipos.

Para ver el índice de artículos sobre Toma de Requisitos, haz clic aquí.
Para ir al paso anterior (nº2: Entrevistas), haz clic aquí.

Consigue Windows 8 a precio de saldo

Pues sí, es posible encontrar Windows 8  a precio de saldo. Lo puedes obtener por unos: 60, 30 y 15 euros (aproximadamente), o incluso menos.

• El precio normal, de unos 60 euros, ya lo tendréis en la mayoría de tiendas y centros comerciales.
• Para conseguirlo por sólo 29,99 euros, basta con que te apuntes a la oferta online que Microsoft está estos días ofreciendo. Esta promoción es sólo para descargas por Internet desde Microsoft y finaliza el 31 de enero de 2013.
• Aún es posible exprimir más todavía el tema, y conseguir por unos 15 euros la última versión de Windows 8. En teoría basta con que hayas comprado recientemente un PC, y dicho equipo admita la actualización.
• Finalmente, está el tema de licencias por volumen. Al parecer, hay quien compra a Microsoft este tipo de licencias (normalmente orientadas a empresas), y luego revende por internet dichas licencias a unos 10 euros o menos. Ojo, habrá que ver si esto es realmente legal o no, o de si luego puedes tener problemas con la licencia.

Por lo demás, y a pesar de los comentarios que recibo, Windows 8 va muy bien. Es agradable de usar, sencillo y potente. Eso sí, el término sencillo va acompañado de su curva de aprendizaje. Hay cosas que cambian, y aunque es posible hacer todo sin la interfaz metro, los cambios están ahí.

¿Compatible? Pues tampoco encuentro mucha diferencia respecto por ejemplo a Windows 7, que rompió compatibilidad con muchos programas y juegos que dejaron de funcionar. De momento todo me funciona y bien.

Hay quien dice que Microsoft tendrá que echarse atrás y traer de nuevo el botón de inicio (que es uno de los cambios más traumáticos), entre otras cosas. Tiempo al tiempo. Decían lo mismo del Ribbon (la barra de iconos de las aplicaciones Office), y la verdad es que no ha sido así. Más bien al revés, lo encuentro cómodo al tener los iconos agrupados, y mostrando las opciones más habituales.

Un cambio acertado es el "Market" de Microsoft. Tienes miles de aplicaciones disponibles, y buscarlas es tan fácil como usar la misma "lupa" que usas para buscar cualquier otra cosa en tu PC. De hecho, se hace exactamente igual. Es entretenido el disponer de tantas aplicaciones gratuitas para casi todo.