Riesgos y penurias de diseñar una solución antes de implementarla

Es un placer escuchar en un ambiente de diseño a personas que vienen de otras disciplinas con puntos de vista diferente a los nuestros.

Esto fue lo que ocurrió el pasado 31 de Mayo en la ponencia de Juan Delgado, desarrollador de ustwo en las oficinas de Chazz.

Actualmente la gran mayoría de empresas están apostando por el trabajo con metodologías ágiles para evitar trabajos en cascada, en los que los diferentes equipos (diseño, desarrollo, Q&A…) realizan el trabajo de forma interna y no pasa al siguiente equipo hasta que no finalizan su parte.

Con la metodología ágil dividimos los equipos por disciplinas y separamos nuestras capacidades de resolver el problema en conjunto. Por lo tanto, ¿es realmente ágil dividir al equipo por disciplinas y anteponer el diseño un sprint por delante del desarrollo?

Al anteponer el diseño al desarrollo lo que está ocurriendo es que las dudas surgen en cascada. No surgen en el mismo momento en el que estamos planteando. El equipo no está 100% conectado para poder resolver juntos estas dudas por lo que se pierde el punto de vista de otras disciplinas o en algunos casos llegan tarde. Todo esto puede hacer que una gran parte del trabajo “se tire a la basura”.

Y sabiendo esto, ¿por qué diseño va antes que desarrollo en los sprint?

Tenemos la percepción de que haciendo pequeñas aprobaciones del producto en papel, o en prototipos rápidos tendremos feedback rápido para poder iterar y mejorarlo rápidamente para aprovechar el tiempo.

“Prototipos en papel, feedback en papel”

Pero ¿y si pensamos como equipo a la vez, creando el producto juntas y realizando estas aprobaciones en producción con los usuarios reales para poder iterar?

Esto es lo que Juan nos propone y tiene un nombre: Mob Programming, un grupo de personas concentradas y trabajando en un mismo ordenador, en un mismo ítem.

Igual la solución es trabajar en equipo, plantear las soluciones con todas las personas de los diferentes equipos involucradas en el proceso entero del diseño del producto.

Trabajar 4 horas del día como equipo centrándonos en un único problema bajo un mismo ordenador y otras 4 horas de manera individual con el fin de hacer mejore productos pensando en los usuarios en menos tiempo. Esta es la metodología de trabajo que Juan nos proponía.

Suena bien ¿no?. Sin embargo, hay varios retos por delante, ¿cómo asegurarse de que todo el mundo participa?, ¿cómo se podría realizar esta metodología en grandes equipos?. Al ser una metodología para desarrollo, ¿cómo podríamos adaptarla para diseño? ¿en otras disciplinas podría funcionar igual?…

Como bien dice Juan, una metodología no está para seguirla al 100%, cada equipo, cada proyecto, cada empresa es diferente y debemos adaptarnos a cada una. Sin embargo, poder crear debate, abrir nuevos frentes, hacernos pensar si nuestra forma de trabajo es la más adecuada o descubriendo nuevos puntos de vista es la forma para seguir mejorando en las metodologías con las que actualmente trabajamos.

Gracias Juan por abrir este debate. Os animamos a que opinéis, que nos deis vuestro punto de vista sobre este tema aportando ideas o nuevos retos.

Pero esto no fue todo. El estudio de diseño Chazz nos abrió las puertas a su casa y tenemos el honor de decir que fuimos el primer evento de diseño que se celebró en esta casa. ¡¡Gracias por confiar en nosotras!!