domingo, 31 de agosto de 2008

Prototipado rápido de sistemas

El paper prototyping es una técnica para crear prototipos de software sin programar nada, sólo usas lápiz, papel, una persona que juega el rol de computadora y el usuario, quien utiliza las interfaces dibujadas en el papel como si fueran de verdad.

Mediante esta técnica se pueden crear prototipos de interfaces de una manera muy rápida, garantizando que el software construido al final tendrá una mayor coherencia interna y surgirán menos contratiempos durante la fase de codificación.

Aquí les dejo unos videos para que vean como funciona.



Miren cómo aquí hicieron un demo de un software para PDA sin haber programado nada.



Tal vez muchos estén ahora pensando que es (como dicen los españoles) una chorrada. ¿Cómo eso me va a permitir construir mejores sistemas?. En realidad tiene sentido.

Piénsenlo, ¿los sistemas para quien los hacemos? la mayor parte de las veces es para usuarios. A los usuarios lo que les importa es que puedan hacer con el sistema aquello para lo que fue creado. Eso es todo. A ellos no les interesa cómo y con qué esta hecho.

Ahora piensen, ¿los usuarios cómo interactúan con el sistema? mediante interfaces. Las interfaces son la parte del sistema que el usuario ve. Más aún, para el usuario la interfaz ES el sistema.

Para los desarrolladores podría ser el código, la base de datos, las clases, los patrones, las funciones, los métodos, los frameworks y la relación entre todos esos componentes para generar cierta información o realizar algunas acciones determinadas. Pero para el usuario no.

Siguiendo con esto, analicemos, cuando se nos solicita mostrar un prototipo dentro de X tiempo ¿qué es lo que normalmente se hace? codificar "algo" para tener "qué mostrar" e "irlo corrigiendo" según las especificaciones del usuario. Muchas veces ese "algo" termina convirtiéndose en el sistema final ¿cómo? con parches. Uno sobre otro, uno sobre otro, hasta que "funciona" como el usuario quiere.

Muy mal. Desde ahí está mal. Así no es como debe ser. Cuando un arquitecto construye una casa no hace una construcción inicial parecida a lo que cree que su cliente pide y luego va derribando muros y construyendo y volando habitaciones o pisos enteros hasta que queda como su cliente realmente la quiere. Sería una locura y al final quedaría un adefesio, como mi amigo el adriel me confirmo.

Pues entre quienes hacemos software eso es una práctica muy común, claro, aplicado a nuestra área. Pienso que si pudieramos hacer las cosas bien desde el principio se evitarían muchos problemas cuando llegue el momento de darle mantenimiento a nuestro software.

¿Los arquitectos que hacen en lugar de eso?. Ellos al principio de sus proyectos no construyen NADA. Muestran bocetos, maquetas, croquis poco detallados, ideas generales. ¿Entonces porqué nosotros tenemos esa manía de codificar desde el principio? ¿no nos han enseñado que la codificación es una de las últimas fases del proceso de desarrollo? ¿no es una de las enseñanzas de Vertti-sensei? pero en la práctica no se siguen las fases como debe ser, se mezclan aspectos de una y de otra.

¿Porqué no aplicar algo así nosotros también? ¿el usuario quiere ver cómo funcionará la interfaz no? pues vamos a darle precisamente eso. Ya que esté contento entonces Y SÓLO ENTONCES codificamos el sistema.

Sí, ya me imagino las objeciones. ¿Para qué perder el tiempo haciendo dibujitos si lo puedo programar de una vez y así ahorro tiempo?. Los usuarios son criaturas caprichosas e impredecibles. Un sólo cambio en la interfaz te puede tirar gran parte de la lógica interna del sistema, provocando tener que reescribir incluso módulos enteros. El estar reescribiendo tu código realmente no es mucho ahorro de tiempo que digamos.

Cuando se trata de programas simples podría no ser necesario, hasta es trabajo de más, pero en sistemas de tamaño medio, un pequeño cambio a una parte del código le pega a varios módulos o clases que dependen o están relacionados con ella.

Estar aplicando cambios en muchos lugares diferentes no es divertido, por esa razón al final queda todo parchado, para no cambiar el comportamiento del código original terminamos agregando algunos hacks sucios por aquí y por allá "sólo en esta parte" para que el código nuevo "jale". Después vienen los problemas.

Propongo que empecemos a cambiar la forma de realizar sistemas en nuestras organizaciones, estas son cosas que ya se vienen haciendo desde hace rato en otros países, pero por alguna razón no ha tenido difusión por acá. Tal vez existe temor de cómo será visto el ingeniero o el programador que no programa sino que "hace dibujitos" o que el usuario se sienta tonto picando botones en una hora de papel, pero por nuestro bien deberíamos superar eso.

Esta no es la única forma de hacer prototipos, debe haber varias y tampoco es aplicable para todos los casos, como cuando tu usuario es remoto y sólo te comunicas con él por teléfono. Para esos casos debe haber otras herramientas que nos sirvan, es cuestión de investigar. Por lo pronto el php forms del buen rafa-kun se ve bastante interesante, pero no se anima a liberarlo. Creo que eso es top secret y no debería estar hablando de ello aquí.

4 comentarios:

HevuZ dijo...

que te han plagiado la frase!!!!

http://www.microsiervos.com/archivo/frases-citas/sistemas-usuario.html

que viene de aca

http://makememinimal.com/2008/frase-semanal-del-guru-la-interfaz-es-el-sistema/

makz dijo...

Me agrada el preplagio, es una indicación de que no estoy tan perdido en mis ideas.

AVL dijo...

Exelente ese makz, me agrado el tema y se ve realmente util, en el proximo desarrollo seguro lo utilizare, independientemente de que el usuario final lo vea (que seria lo mas optimo) o no yo creo que seria aplicable y de gran ayuda en team works como complemento al uso de alguna metodologia de desarrollo rapido como scrum o xp ya que nos permite repartir facil y logicamente las tareas de las que cada cual se encargara, sale ese makz ahi estamos ;)

Jose Abanto dijo...

Dame una mirada en mi BLOG, donde acabo de balbucear algunas palabras sobre el desarrollo de sistemas y no he tenido mejor idea que “robarte” una frase para justificarme.

Gracias.