Get best of the week

5 reglas para integrar UX en Agile y Scrum

Se preparó una traducción del artículo antes del lanzamiento del curso Agile Project Manager en TI .



Cuando recién comenzaba mi carrera, el software vino en cajas. Si esto le parece extraño, sepa que cuando era niño, mi padre trajo a casa tarjetas perforadas en las que se grabaron programas en la década de 1970. Tal software tenía un estado final. Después de 20 años a partir de ese momento, ya parecía ridículo. Hoy estamos creando sistemas que se pueden mejorar infinitamente. Esto plantea la pregunta: "¿Cuándo termina el trabajo?" - Y esta pregunta es difícil de responder. Estamos buscando la respuesta a esta pregunta, porque nos ayudará a responder otras preguntas aún más importantes. ¿El equipo recibirá su premio o lo reportarán? ¿El equipo hará algo nuevo? ¿Se beneficiará la parte interesada?

Los equipos de desarrollo que usan Scrum (o cualquier otra variación de la metodología Agile) tienen una idea clara de cuándo termina el desarrollo. A menudo, esto significa "un conjunto de criterios mínimos que un producto / servicio debe tener para satisfacer las necesidades del negocio". Como resultado, se reduce a una lista de funciones, que es aprobada por la parte interesada (o el propietario del producto) y al momento de la finalización del proyecto debe implementarse completamente. Los desarrolladores lo llaman "funciona según lo previsto".

Pero "trabajar según lo previsto" significa solo que el software hace lo que quiere de él. Desafortunadamente, a veces esto no es suficiente. De hecho, esto es solo el comienzo de una conversación que tenemos continuamente con nuestros usuarios y clientes. Es la mejora continua de nuestros sistemas para proporcionar una mejor experiencia lo que les da un valor real.

Entonces, ¿cómo podemos definir "cierre" para un equipo? ¿Cuándo comienza un equipo un nuevo proyecto? La falta de ROI es un buen lugar para comenzar, pero ¿cómo sabemos que no hay recuperación de la inversión? La respuesta nos la darán los clientes. Nos fijamos en su comportamiento. Escuchamos sus necesidades, evaluamos si nuestros sistemas satisfacen estas necesidades y pensamos qué podemos hacer para satisfacer estas necesidades siempre cambiantes. Llamamos a estas métricas los resultados.

Y estos resultados no pueden predecirse, así como es imposible predecir el comportamiento humano. Los buenos resultados requieren que los miembros del equipo se involucren activamente con los clientes para detectar cambios en su comportamiento, los motivos de su ocurrencia y las oportunidades para satisfacer mejor las necesidades de los clientes en el futuro. La buena noticia es que su empresa probablemente ya emplea personas que son especialmente buenas en estos aspectos: diseñadores. A pesar del hecho de que hoy en día los diseñadores están presentes en casi todas las empresas, la mayoría de ellos no ocupan puestos lo suficientemente altos como para influir en la adopción de grandes decisiones. De hecho, muchos de ellos quedan fuera del camino para los procesos de desarrollo ágil, diseñados para programadores y gerentes de producto.

La integración de diseñadores en el proceso de desarrollo ágil es un problema constante para muchas organizaciones. Gracias a casi 20 años de experiencia en el diseño, gestión y consultoría de equipos de productos, he identificado las siguientes 5 reglas que un equipo debe seguir si quiere asegurarse de que la experiencia del usuario (UX) se integre con éxito en su proceso ágil:

1. Un diseñador separado para cada equipos

No puede haber compromiso. Sin el diseñador "propio" en el equipo Scrum, simplemente tiene un equipo de desarrollo, que sin un diseñador no puede proporcionar el nivel adecuado de calidad de la experiencia del usuario.

2. Horas de trabajo en equipo con clientes.

Esta regla la aprendí de Jared Spoolquienes realizaron un estudio demostrando que los equipos que pasan al menos 2 horas-hombre cada 6 semanas se comunican con los clientes (por ejemplo, reciben llamadas de soporte, hablan con los usuarios, observan a las personas, etc.) están teniendo más éxito productos

3. El trabajo del diseñador es el primer punto de la

cartera de pedidos. Brevemente: mantenga una sola cartera de pedidos. Desarrollo, control de calidad, diseño, trabajo de investigación: todo esto debe estar en un trabajo atrasado, priorizado por todo el equipo que realiza este trabajo. Tan pronto como el trabajo se divida en dos atrasos, el equipo elegirá uno de ellos y decidirá tratarlo como el "principal", y el segundo simplemente lo colocará en la caja posterior.

4. Resultados de priorización como Filtros para Cartera

me escribió un montón sobre los resultados (y Josh Seyden escribió un libro completo al respecto ), pero lo único que quiero señalar en el contexto del tema de hoy es que cada elemento de la cartera de pedidos debe pasar por el filtro de objetivos finales del equipo. Pregúntese: "¿Este trabajo ayudará a lograr el objetivo?" Si la respuesta es no, suelte este elemento.

5. Entrenamiento multifuncional

La experiencia y el diseño del usuario conllevan muchas cosas interesantes que vale la pena explorar. Dichos eventos pueden ser realizados por diseñadores (o analistas), pero deben ser practicados y atendidos por todo el equipo. Cuanto más un equipo puede aprender juntos, menos tiempo lleva compartir el conocimiento adquirido y más para decidir dónde aplicarlo (que es un tema de conversación más productivo para el equipo).

La naturaleza retrospectiva iterativa de Scrum es muy adecuada para UX y actividades de diseño. La integración de los conocimientos del cliente en el proceso de trabajo proviene directamente del Manifiesto Ágil (trabajo con clientes, etc.). UX y diseño nos acercan al objetivo ágil de enfoque en el cliente y mejor satisfacción del cliente. Siga estas 5 reglas para combinar diseño y desarrollo ágil.


.

More articles:


All Articles