Tras asentar las bases del trabajo en equipo entre UX y desarrollo en el anterior post «Se puede integrar UX en equipos ágiles de desarrollo y ser felices», aquí van los trucos o prácticas más terrenales que estamos aplicando en Biko para que esa felicidad se palpe día a día (podéis completarlas también con las de gente de renombre como Jeff Patton, en algunas de las cuales coincidimos).
Prácticas de Lean UX implantadas en Biko con buenos resultados
1. I love my team. Por eso me arrimo a ellos
Ya lo adelantaba en el otro post. Práctica simple donde las haya pero que provoca grandes resistencias. Quizá por ser de los primeros pasos necesarios para este cambio.
Lo dicho: UX, múdate a la mesa del equipo de desarrollo. Y no vale de espíritu, tiene que ser cuerpo. Llévate tu ordenador, tus papeles, tus muñequitos… y arrastra de paso al diseñador gráfico, al maquetador y a quien sea que vaya a aportar en vuestros proyectos como nuevo equipo multidisciplinar.
He hablado con bastante gente que tiene dificultades ineludibles con este primer paso (kilómetros de distancia entre unos miembros y otros, y todas las variantes posibles del problema) y la vía de solución es siempre acercarse al menos virtualmente. No problemo siempre que el espíritu sea el mismo: mantener un contacto continuo en forma de conversaciones y discusiones (continuo es varias al día, no usar el skype para el daily scrum).
2. Pila rica rica. El equipo al completo (comercial incluído) aporta perejil a la pila
Tres cabezas aportan más que dos, cuatro mejor que tres, cinco mejor que cuatro… Especialmente si cada una de esas cabezas está amueblada de una forma diferente.
Por eso, nosotros damos mucho peso a la participación de todos los miembros del equipo (y el comercial que aun está por unirse completamente) en la elaboración de la pila. Será más sencillo no olvidarse de nada si hay perfiles diferentes identificando las piezas clave del producto a construir o vender (podemos estar aun en fase de propuesta).
El UX percibirá detalles de servicio al usuario que van más allá de funcionalidad técnica propiamente dicha, o podrá dar luz sobre cuál de esas funcionalidades podría ser el core del producto y cuál no. El comercial, como iniciador de la relación con el cliente o el posible cliente, aclarará dudas sobre el modelo de negocio, la idiosincrasia del cliente… además de enriquecerse al escuchar (o incluso participar) en las estimaciones.
Lo mismo para los desarrolladores, los diseñadores, los maquetadores… Es incuestionable que cada experto va a aportar su granito de arena durante el proyecto. Por tanto, si después vamos a necesitar que sea parte de él, que lo sea desde el inicio.
3. Iteración Zero. Inception, sketching, design thinking y el pino-puente para empezar
Dependiendo de lo exhaustiva que haya sido la fase comercial a la hora de materializar el proyecto, la iteración Zero será más o menos intensa.
El objetivo es que todo el equipo (+ el cliente) obtenga la visión compartida de lo que se va a construir. Esta visión se hará tangible a través de la pila, por supuesto, pero mejor si la completamos con unos wireframes de baja fidelidad del core del proyecto, con un inception que cuestione los requerimientos del proyecto y explore, mediante dinámicas creativas, otras alternativas, con una identificación de los personajes a los que vamos a querer servir con nuestro proyecto… o bien con todo ello.
Eso sí, ojito, la iteración Zero no puede ser una consultoría tradicional por varias razones:
- No puede durar tres meses. Se trata de una iteración. Dos a lo sumo si nos encontramos con que el producto está en mantillas o ni siquiera hay producto.
- No es una fase para que el equipo de UX trabaje a la vieja usanza, osease, solo. Es una iteración en condiciones, de trabajo mano a mano con el cliente y con todo el equipo o al menos con gran parte de él. Aviso: la incertidumbre en esta fase temprana del proyecto puede ser un poco difícil de llevar para según qué perfiles si el proyecto no es proyecto aun y hay que aplicar técnicas de design thinking en lugar de poder empezar a construir de inmediato. En el AOS de Zaragoza le llamamos Inception Plus. Pero como esto da para otro post entero, lo dejo aquí 😉
- La iteración Zero no acaba con un entregable a cliente. Acaba porque empezamos a diseñar, a construir, a montar el gestor… lo que sea. No es una consultoría y por tanto el fin no es el entregable. Ay, vaya, eso ya lo he dicho 😉 pero por si no quedaba claro!
4. Sketching colaborativo. Pinta cuando haya dudas y cuando no las haya
A veces somos capaces de creer que nos estamos entendiendo con alguien al conversar y resulta que es mentira. No es a mala fe, ¡desde luego!, y eso es lo peligroso, que de verdad creemos habernos entendido. Pero resulta complicado entenderse a la perfección cuando sólo la palabra es la vía para ese entendimiento. No te digo si encima quienes intentan entenderse viven en mundos distintos (con jergas distintas y cabezas amuebladas de forma diferente). Y es que si yo digo… «consultoría», por ejemplo, y tú dices «consultoría» y él dice «consultoría»… cada uno entendemos una cosa diferente, aunque creamos estar en sintonía.
La otra vía es intentar dibujar lo que quieres decir. En sucio y sin avergonzarte de no ser un Leonardo Da Vinci. Descubrirás que quien hasta ahora asentía a todo lo que decías tuerce el gesto. Oh, vaya, ¿resulta que no estabais tan de acuerdo?
El dibujo es mágico. Nosotros apostamos por dibujar casi cada día. Cuando defines la pila. Cuando piensas el core del producto. Cuando abordas una nueva historia. Cuando el cliente pide una funcionalidad nueva. Cuando un compañero tiene dudas sobre una pieza. Cuando estás discutiendo. Cuando no discutes porque resulta que os estáis entendiendo (o eso parece).
Apuntaba en el post anterior que NADA supera la palabra. Ja!, pues mentía. ¡El dibujo la supera! (por eso soy fan de Paper) Ah! Como consejo final, deja siempre copias de los dibujos colaborativos en las mesas de tus compañeros. La memoria es corta.
5. Backlog grooming. Pasitos por delante (de guisante, de gigante o de cangrejo)
Una de las mayores dificultades (y frustraciones) en todo este cambio es la ausencia de la visión completa y detallada (vía wireframes, por ejemplo) de todo el producto a construir.
Al obviar una fase previa de consultoría larga, el equipo arranca sin el detalle de todo lo que terminará montando. Y esto pone tan nerviosos a los UX como a desarrollo. A los primeros porque les hace sentir que no tienen el control total y que pueden surgir inconsistencias durante el montaje. Y a los segundos porque les provoca mucha incertidumbre (por si surge una funcionalidad compleja allí donde no se esperaba, porque a veces abordan una historia que no está todo lo detallada que se precisa…)
Ante este problema, gurús como Jeff Patton, a quien mencionábamos al inicio del post, recomiendan trabajar en Pistas paralelas. A mi personalmente no me resulta muy cómodo ese planteamiento. me provoca la sensación de volver a trabajar en cascada, de dar un pasito hacia atrás.
En Biko somos más fans de otras alternativas como:
- Decidir el detalle de la funcionalidad historia a historia, entre UX y desarrollo, de forma diaria. Para ello, empezamos reservándonos un tiempo de trabajo en equipo (o en parejas, o en tríos…) tras el scrum. Con el fin de cumplirlo, lo llegamos a calendarizar. A día de hoy ya no necesitamos bloquear ese tiempo porque ya todos sentimos necesidad de esa conversación, de ese dibujo en sucio que nos permite alcanzar un acuerdo, por encima de cualquier detalle de historia en jira.
- Adelantar el análisis de las historias complejas que ejecutaremos en la siguiente iteración. Pero todo el equipo, o quien sea necesario, no sólo el UX (al contrario de lo que plantea el modelo de Pistas paralelas). Esto lo explica mucho mejor que yo Jose Manuel Beas.
6. Viva el lejano oeste. Sombreros y sesiones de foco
Ya en plena iteración hay momentos en los que necesitamos estar dando lo mejor de nosotros, concentrados al máximo, exprimiendo neuronas. Cuando el equipo es multidisciplinar y los ritmos de trabajo de cada uno son variados, el respeto a los tiempos de foco de los compañeros se hace imprescindible. Para evidenciarlos en mi equipo usamos sombreros de paja, a lo vaquero. Si sois demasiado vergonzosos para imbuiros en el lejano oeste, pueden ser pelotas de colores sobre los ordenadores, banderitas… Yo sigo apostando por los sombreros, al menos consiguen hacer sonreir a los compañeros.
Esto para respetar los tiempos individuales, pero ¿qué hay de los tiempos colectivos? A veces olvidamos que en sesiones grupales (inceptions, retros, demos, planificaciones…) el foco es igual de importante o más, puesto que la apatía, la desidia, el malhumor o simplemente el cansancio de cualquiera de los miembros puede poner en peligro el objetivo de la reunión (identificar riesgos, acciones de mejora continua, idear soluciones creativas…).
Como remedio, mi consejo es introducir comida (a poder ser chocolate) y café en algunas sesiones (despierta nuestro cerebro y lo prepara para que las ideas calen mejor en él), apoyarse en juegos para extraer la información oculta y, de vez en cuando, como remate, hacer algunas terapias de grupo que ayuden a aumentar la empatía entre los miembros del equipo.
Lo que estamos empezando a hacer pero aun estamos recorriendo el camino
7. Terminado elevado a X
Cuando el equipo se compone de diferentes perfiles, suele ser necesario la colaboración de todos ellos (o la mayoría de ellos) para poder dar por terminada una funcionalidad. Igual que todos aportaron en la creación de la pila, todos serán capaces de evaluar el producto terminado desde diferentes perspectivas. Y es que una historia puede cumplir con los requerimientos establecidos pero no estar suficientemente redonda a nivel gráfico, de usabilidad…
Para solventarlo, de momento estamos realizando una demo continua interna que nos permite a todos los miembros del equipo durante la iteración revisar el avance de las historias implementadas antes de la demo oficial de fin de iteración y así identificar detalles de mejora sobre la marcha. Además, antes de dar cualquier historia por terminada, nos solicitamos entre nosotros segundas opiniones.
Con todo, creo que nos falta un un proceso más estandarizado. Cualquier idea es bienvenida.
8. Test vs/+ MVP
Los UX, sobre todo en modelos de construcción ágil, hemos pasado de organizar focus, test de usuarios, etc. a testar en modo guerrilla con amigos, conocidos… En parte porque creíamos que no compensaba el valor obtenido con este tipo de prácticas respecto al coste para el cliente y, en parte, porque hemos priorizado el planteamiento Lean Startup: construye tu MVP (quizá es un mero formulario) y téstalo en real.
Aun así, no sé si con razón o por herencia pasada, a veces echamos en falta algo más de testeo con usuario final en frases tempranas. ¿Cuál es la barrera? Curiosamente suele serlo el cliente: no lo ve necesario, no nos facilita el acceso a esos usuarios, no está dispuesto a pagar por algo que él considera ya tener clarísimo…
Aun así hemos optado por ampliar el testeo de guerrilla todo lo posible (envío de encuestas rápidas, inmersión en el contexto del usuario objetivo -ej. probar diferentes coches eléctricos existentes si nuestro proyecto implica el diseño de un nuevo sistema de control táctil, etc.) sin que esto detenga el ritmo del proyecto y controlando que el esfuerzo empleado vs la información obtenida nos compense. En ello estamos.
9. Conocimiento compartido
Cuando una organización se atomiza en varios equipos se precisa que el conocimiento fluya entre ellos. También incluso entre los miembros del propio equipo: cómo no querer entender y profundizar en aquellos nichos de conocimiento que tus compañeros de al lado manejan con maestría cada día frente a ti y que tanto te pueden enriquecer.
Lo que no encontrábamos hasta ahora era el medio más adecuado para conseguirlo. En el Open Space que montamos en Biko el viernes pasado, una de las sesiones se centró en este tema y ya hay ideas para resolverlo de formas no-tradicionales (que era como hasta ahora no nos funcionaba). Conceptos como Desk Surfing entre equipos, Open Spaces mensuales para compartir experiencias y conocimiento o tiempos blindados en cada iteración empiezan a sonar como alternativas. Os iremos contando.
Y como consecuencia… un objetivo más elevado
10. Be happy, make everybody feel happy
En el primer post la palabra «feliz» era incluso parte del título, porque en realidad esto va de conseguir la felicidad. En todos los aspectos y a todos los niveles:
- A nivel personal, con relaciones más humanas cada día.
- A nivel profesional, con la construcción de productos más redondos que nos permiten realizarnos.
- A nivel de equipo, porque generamos un ecosistema que favorece nuestro crecimiento individual y colectivo y nos permite ser dueños del proyecto, el cliente, el producto… Dueños de nuestro destino! 😉
- A nivel de cliente, porque su implicación en el producto va más allá de la priorización de la pila y porque trabajará con un equipo que ha convertido en un reto común el objetivo de negocio, eliminando las fronteras entre cliente y proveedor.
- A nivel de empresa, porque la empresa crecerá al mismo ritmo sus equipos y clientes, cada vez más maduros y cercanos al negocio, perdiendo sentido el command&control.
Por eso esto va de conseguir la felicidad. De ser felices y hacer felices a otros. Aunque sea por el puro egoísmo de sentirte bien por ello 😉
En fin, estas son nuestras prácticas para trabajar UX y tekis en armonía y ser felices con con ello. ¿Cuáles son las tuyas?
