Comments for Prototipos de papel para análisis de requisitos y usabilidad ágiles at http://www.navegapolis.net , comment 1 to 7 out of 7 comments http://www.navegapolis.net Thu, 28 Aug 2008 16:37:25 +0100 FeedCreator 1.7.2 http://www.navegapolis.net/content/view/721/58/#comment-1215 Porqué le llaman prototipo a algo que no funciona. ¿Te imaginas el prototipo de un auto y que no ande? Mientras que de la maqueta, si me lo imagino. ¡Usemos los términos propiadamente! - Lin Fan Fri, 22 Feb 2008 18:14:34 +0100 http://www.navegapolis.net/content/view/721/58/#comment-1142 El primer enfoque puede resultar demasiado 'abstracto' para requisitos, algún cliente me ha dicho despues de una reunión de prototipado en pizarra que 'como el trabajo lo han hecho ellos, no me pagan esas horas' (!) Personalmente creo (a diferencia del comentario de JRubira), que el prototipo cuesta muy poco (mucho menos que las pantallas, no importa el lenguaje), y que con la herramienta adecuada, sirve para varios propósitos: - Efectivamente, cierra los requisitos del cliente (y sirve al cliente para descubrir lo que 'no quiere' porque se pueden hacer demos muy facilmente) - Sirve de referencia para el desarrollo. - Anticipa problemas de usabilidad (e incluso funcionales) Pero es muy importante que el usuario no crea que el prototipo es un entregable final por varios motivos: - Pensará que el desarrollo está más avanzado de lo que está. No importa cuánto insistas, si ve una ventana con todos los colorines, pensará que 'ya está casi' aunque no haya ni una linea de código para soportarla. - Lleva mucho tiempo completar un prototipo, aunque sea sólo estéticamente. No lo intentes, quédate en un wireframe. - Puedes atraparte en una estética que resulte en problemas funcionales más tarde, y te obligará a renegociar. Hice una pequeña recopilación de herramientas hace unos meses, yo uso el stencil Visio de guuui.com, pero podéis verla aquí: [url]http://blog.omelas.net/2006/07/web-prototyping.html[/url] - Jorge Uriarte Wed, 09 Jan 2008 11:26:06 +0100 http://www.navegapolis.net/content/view/721/58/#comment-1140 Les tiro algunas ventajas que tiene el prototipo en papel sobre el realizado en la computadora: - Es mas rápido y economico de realizar - Se puede modificar adelante del cliente - Cualquier persona que sepa escribir sabe realizar un prototipo, sin necesidad de conocer una determinada herramienta. - Evita falsas espectativas al cliente cuando ve las pantallas en la computadora, pensando que ya tenemos el sistema listo. - Muchas veces el cliente cuando ve un prototipo en la computadora piensa que ya está listo y no opina sobre las modificaciones que abria que hacerle... cosa que en papel fomenta la participación del cliente. - Diego Mon, 07 Jan 2008 11:49:19 +0100 http://www.navegapolis.net/content/view/721/58/#comment-1139 Uff. No sé. No sé. Para desarrollo agil ... con el tiempo que tardo en escribirlo en papel, se hace lo mismo diseñandolo directamente en la aplicación (aunque solo sean las ventanas sin funcionar), y así no trabajas dos veces. Por otra parte, el mayor problema no está en que campos llevará la aplicación, (añadir y quitar campos puede ser relativamente facil si la arquitectura es simple) sino en como se aplican las formulas que hay por debajo (dtos, comisiones, lo que lleva iva y lo que no, o lo que sea) Si es una arquitectura compleja donde intervienen muchas personas en el desarrollo es mejor hacer un analisis donde si pueden llevan las ventanas pero de una manera más legible. :-\ Bueno, para gustos los colores. - JRubira Sun, 06 Jan 2008 20:28:19 +0100 http://www.navegapolis.net/content/view/721/58/#comment-1138 Algunas veces la herramienta más sencilla es la más adecuada, y sin embargo por dar empaque se crean complicaciones innecesarias, llegando a ser el peso del entorno y las herramientas más una zancadilla que una ayuda. Para trabajar en equipo (que no tanto en grupo de trabajo) de forma ágil y en un número reducido puede ser más recomendable una pizarra con post-it's y comunicación verbal directa, que una intranet de comunicación colaborativa. Ahora tienes toda la razón, para trabajar en equipo puede estar bien, pero para enseñar a clientes en salas de reuniones, quizá un pelín cutre la modalidad de líneas torcidas con rotulador. Un saludo. - Juan Sun, 06 Jan 2008 12:38:47 +0100 http://www.navegapolis.net/content/view/721/58/#comment-1137 La técnica sin duda es excelente para reducir o acotar al máximo las confusiones que puedan existir en las especificaciones funcionales. Pero estamos en el 2008, creo que ya existen varias herramientas como para evitar mostrar papelitos al cliente. :P Salu2 - Carlos Astudillo Sun, 06 Jan 2008 03:20:12 +0100 http://www.navegapolis.net/content/view/721/58/#comment-1136 Gracias por hacer conocer la existencia de esta idea!! ... por más simple que es .. seguro que nos ahorra tiempo en hacer líneas de codigo antes de saber la reacción del usuario frente al software ... ;D .. felicitaciones por el blog ... ;) - Rommel Anatoli Quintanilla Cruz Sat, 05 Jan 2008 17:34:29 +0100