Ultima revisión 02/02/2023

Desarrollo ágil centrado en el usuario

Últimamente se habla mucho de cómo mejorar el diseño sin perjudicar ni a los usuarios, ni al cliente.

Yo creo que esto es posible si aplicamos un planteamiento más objetivo, uniforme y global que podríamos denominar desarrollo ágil centrado en el usuario (DACU o UCAD en inglés). Pero, qué es eso de DACU? Pues no es ni más ni menos que diseño centrado en el usuario mezclado con desarrollo ágil. Esto es:

Por un lado tenemos el desarrollo ágil, que puede definirse como una disciplina que define y juega con ciclos de trabajo cortos con el fin de aumentar la eficiencia del proceso de entrega de un proyecto.

Por otro lado tenemos el diseño centrado en el usuario, que es una disciplina que se caracteriza por situar al usuario como eje principal de todo desarrollo del producto, aplicativo o sistema.

Dado que tanto el diseño centrado en el usuario, como el desarrollo ágil son metodologías, disciplinas o planteamientos filosóficos que se basan en la iteración de pequeños pasos que proporcionan validaciones de forma permanente y continua en todos y cada uno de ellos, podríamos afinar un poco en algunos aspectos y proponer algunas directrices que fuesen beneficiosas y estableciesen un equilibrio.

Sin embargo, como muchos sabrán, el problema estriba en que muchas veces lo que desea el cliente difiere de lo que desea el usuario final. Entonces, cómo podemos establecer ese equilibrio? Pues, para empezar, podríamos cambiar un poco el cliclo de vida estableciéndolo de la siguiente forma:

Y a este modo de trabajar podríamos añadir lo siguiente:

Satisfacer al cliente. Esto lo podemos conseguir informándolo periódicamente, aceptando los cambios y nuevos requisitos como algo positivo y beneficioso, realizando feedbacks efectivos y eficientes entre el cliente y todos los equipos de desarrollo, diseño, etcétera, y garantizando que el desarrollo es continuo y sostenible.
Formar equipos multidisplinares y multiorganizados de máximo 8 miembros, pero que estén enfocados a un único ambito o área. Esto es, un equipo podría estar formado por profesionales que dominan más o menos todas las áreas de desarrollo, pero estar localizados en una. Por poner un ejemplo, podríamos reunir un equipo que tuviese una persona encargada del Front-End, otra del Back-End, otra para los servicios y microservicios, otra de UX, otra de calidad y otra que ejerciese como manager, pero con capacidad de programar si hiciese falta.
Pensar en tareas en función de los escenarios, no al revés. No se debe aportar funcionalidad a un sistema sin más, o con el motivo de por si acaso. Lo que hay que hacer es crear la funcionalidad que se necesite en función del escenario que se está manejando en un momento dado. Si luego cambia el escenario, será entoces cuando se deberá analizar si la funcionalidad debe cambiar o no, y no antes.
Exponer a todos los miembros del proyecto las posibles tareas, aunque no tengan conocimientos avanzados o sean de otro departamento, para tratar de conseguir una mejor objetividad y requisitos necesarios. Esto es porque las tareas son creadas por los miembros del equipo de desarrollo, pero pueden ser propuestas por otras personas o usuarios que poseen otra visión menos estructurada o automatizada.
Definir bien el alcance de las tareas y su duración, no siendo superiores a 5 días. De nada sirve tener buenas ideas y soluciones si son inmanejables en el tiempo. Pensemos que una tarea larga tiene más probabilidades de sufrir un retraso que una corta, aunque sólo sea por la causalidad de imprevistos, excesivo tiempo de investigación o por aleatorios problemas de ejecución y/o depuración.
Priorizar aquellas tareas en donde confluyan el cliente y el usuario. Si realizamos un análisis previo de los requerimientos de negocio en contraste con los requerimientos del usuario y priorizamos aquellas tareas que van a satisfacer antes tanto al cliente como a los usuarios, es posible que ambos obtengan una mejor experiencia.
Diseñar y desarrollar pensando en lo más probable, no en lo posible. Esto es importante porque muchas veces se crean diseños y funcionalidades que se ponen por si acaso y no, porque, si bien un usuario puede que utilice la cámara para comprobar si el producto se ajusta a su complexión, no es probable que muchos lo hagan.
Desarrollar pensando en utilizar para reutilizar. Es decir, desarrollar primero aquellas funcionalidades básicas que puedan llegar a ser repetitivas o que puedan formar parte de una funcionalidad mayor. Esto es porque, es posible que una funcionalidad como la de buscar en un sitio web necesite de otros métodos internos que también estén en una búsqueda predictiva.
No aportar más funcionalidad de la que se necesita. Parece evidente que si un sistema solo necesita de sumas y restas, añadirle las posibilidad de multiplicar y dividir no es necesario. Sin embargo, lo que muchos no saben, o no parecen saber, es que la mera definición de esas funcionalidades, hará que disminuya el rendimiento, en nivel de productividad, los beneficios de desarrollo y puede que hasta la usabilidad y la experiencia de usuario.
Realizar reuniones diarias para reorganizar y replanificar las tareas, además de poner al día al equipo y al manager. En estas reuniones, cada miembro, no debe acaparar más de 5 o 10 minutos. Si durante el transcurso de la sesión uno de los miembros tiene un problema que no sabe o no puede solucionar, se le deberá asignar un recurso que sí que pueda y le proporcione la solución.

Si tenéis alguna pregunta o duda, no dudéis en decírmelo.

Hasta más vernos.