Lo ideamos para encontrar una solución en poco tiempo y llevarla a cabo. Así hicimos nuestro Google Design Sprint de tres días, y éstos son los logros y aprendizajes que tuvimos.
La necesidad
Todo empezó al darnos cuenta que había una necesidad que nos llevaba a refinamientos repetitivos. No había forma de encontrar una solución por mucho que nos esforzábamos en colaborar equipo técnico y stakeholders.
Estuvimos dándole vueltas a qué causas podían provocar esta «no solución», y una de las más importantes era la diversidad de casos que cubría la necesidad en el cliente final, que realmente significaba cubrir lo mismo para distintos tipos de clientes. Cuando cubríamos a unos, complicábamos la existencia a los demás. Cambiábamos, y descuidábamos las primeras…¡se estaba haciendo infinito y no tenía ningún sentido! El equipo entero se estaba desmotivando en los refinamientos, y empezaba a sonar la palabra «déjà vu».
Entonces un miembro del equipo y yo encontramos un meetup al que acudir, sobre Google Desing Sprint (No tengo el link a tal meetup, pero os dejo este para que podáis saber sobre qué va: https://designsprintkit.withgoogle.com/ ) Vimos la luz 🙂
Decidimos hacer un Google Design Sprint de 3 días con representantes de todos los roles del equipo y stakeholders. Es decir, como si nos juntáramos para un refinamiento ordinario, pero con mucho más tiempo, actividades dirigidas y cómo no…aperitivos y mucho café 😛
La puesta a punto
Durante unos días estuvimos pensando cómo proponer algo así en nuestra organización. No era fácil explicar que queríamos probar un experimento que necesitaba de la presencia de varias personas con perfiles técnicos y de negocio durante 5 días. Esto era una semana de trabajo, y a veces, sinceramente, cuesta darse cuenta que dedicarse ese tiempo a encontrar una solución es más rápido que todos los refinamientos del equipo durante 2 meses.
Teníamos la certeza de que presentando el Google Design Sprint de los 5 días tendríamos un NO rotundo, por eso creo que fuimos más listos en presentarlo para hacerlo en 3 días. Aún así tuvimos ciertas reticencias, pero lo logramos 😛
La experiencia
Me atrevería a decir que, más allá del resultado, de lo que más aprendimos fue de la preparación. Siguiendo las recomendaciones del link que os he pasado anteriormente, y estudiando muy bien qué actividades realizar, estábamos entendiendo qué buscábamos.
En este post no se pretende explicar al detalle las actividades, sino qué estrategia seguimos para aprovechar el tiempo y cómo nos resultó la experiencia, pero os dejaré en cada actividad el link para que las podáis ver en profundidad.
En el siguiente documento podrás ver el detalle de todas las actividades que se pueden hacer en cada fase del taller:
Agenda
El primer día lo dedicamos a las fases de entendimiento, sketch y definición, para conocer bien el problema, identificar posibles soluciones y saber PARA QUÉ. Lo importante es que todos tuviéramos la misma visión y el mismo objetivo.
Las actividades:
Fase de entendimiento
Una primera fase para abrir ideas, concentrarlas en similares y votar las más relevantes
- Lighting talk: en este caso liderado por el equipo de ExD, explicando los resultados obtenidos de distintas entrevistas con clientes finales.
- How Might We: todos juntos mientras se daba el Lighting Talk
- HMW Sharing and Affinity Map + HMW Voting: todos juntos.
Fase de sketch
Una segunda fase de apertura y concentración de ideas para el punto más relevante de la fase anterior.
- Crazy 4: variante del Crazy 8 para dejar correr la imaginación. Nos dividimos en tres grupos.
- Round Robin: para volver a converger las ideas. Entre los tres equipos. Nosotros usamos el paso de ideas para buscar riesgos y mejoras de cada futuro prototipo.
Fase de definición
- User sentence: Buscamos una frase entre todos como título a la necesidad.
- Succes & Metrics: para pensar cómo íbamos a medir que nuestra solución funcionara. Por equipos.
El segundo día nos dedicamos a prototipar soluciones teniendo en cuenta todos los puntos que habíamos hablado el día anterior. El objetivo final no era sólo tener un diseño, sino preparar el test que nos ayudaría a solucionar nuestra necesidad. Todas las actividades se hicieron con los tres grupos creados el día anterior.
Las actividades:
Fase de prototipo
Fase para entrar al detalle de lo que significa la solución de la necesidad. En este punto todos estábamos alineados en qué necesitábamos. Nos dedicamos a crear un prototipo en papel tal cual lo haríamos en un programa digital, con el fin que al día siguiente, las personas que hicieran el test tuvieran una experiencia lo más realista posible.
- Story Guide: antes de empezar con el detalle del prototipo, cada equipo pensó en la historia de la solución, lo que sería el «journey».
- Design: El prototipado en sí. Nosotros no usamos ningún programa, lo hicimos a mano, y nos dimos cuenta del potencial de las personas del equipo para preparar diseños movibles realmente espectaculares.
- Test preparation: no basta con hacer una lista de preguntas para realizar un test, el orden debe tener sentido y sobre todo estar muy atento a las reacciones del testeado y adaptarse.
El último día fue el más intenso, aunque no lo pareciera, la concentración tenía que ser máxima, pues cualquier idea, comentario, gesto…nos daría pistas de qué cosas iban a funcionar y qué cosas no.
Fase de test
Dividimos las horas de la mañana en diferentes test en los que acudieron personas afines al proyecto, desde managers a desarrolladores y stakeholders que no hubieran participado en el taller. En este caso no podíamos disponer de usuarios finales, así que nos reinventamos 😉
Los tres equipos, con sus respectivos prototipos y soluciones hicieron un gran trabajo en recoger y después recopilar todos los pros, contras y nuevas ideas que iban surgiendo.
Al final cada uno de los equipos recopiló la información más relevante y la mostró a los demás.
En ese momento nos dimos cuenta que el hecho de cambiar el objetivo del taller, para tener tres soluciones en lugar de una había sido un error. Lo hicimos con la intención de tener los mismos resultados corroborados por tres, pero nos encontramos con demasiado trabajo.
Para solucionarlo, dedicamos la tarde a votar qué cosas habían tenido más y menos éxito de cada prototipo, de esta manera salimos del taller con pocas ideas claras, que algunos sprints más tarde quedarían implantadas en nuestro producto.
Aprendizajes y Mejoras
El Lighting Talk debería haberlo hecho el Product Owner (-)
Echando la vista para atrás, pensamos que la explicación de la necesidad (LightingTalk) debería haberla hecho el Product Owner, tal cual en un refinamiento. Llegamos al taller intentando obviar las soluciones que sin querer se te pasan por la cabeza cuando reconoces un problema en el producto. Imagino que nos pasó porque ya lo habíamos hablado muchas veces antes. Al hacerlo una persona de ExD con los resultados de unos test, creo que nos condicionó todavía más.
El Crazy 4 en lugar del Crazy 8 (+)
Como he comentado anteriormente, hicimos tres equipos de trabajo para algunas actividades. En cada equipo había una persona de ExD, dos stakeholders y dos desarrolladores (BE y FE). Con esta distribución, nos pareció que hacer el Crazy 8 sería un reto muy grande para las personas que no eran de ExD, y el objetivo no era tener un diseño espectacular, sino una solución espectacular, sin dejar atrás el diseño y que de alguna forma todos pudieran sentirse creadores.
Pedir feedback (+)
¡Nos ayudó muchísimo! Desde saber qué actividades habían gustado más y menos, hasta modificar horarios de las agendas para que los participantes estuvieran más cómodos.
Tres equipos con tres soluciones diferentes (-)
Pienso que nos perdió el buscar la mejor solución entre varias, en lugar de poner foco en una sola, probarla y mejorarla. El hecho de dividir el trabajo en tres equipos y acabar teniendo tres prototipos distintos y pruebas distintas nos abrió demasiado las propuestas. Lo bueno es que nos dimos cuenta al final, y creo que lo pudimos salvar cuando unificamos los resultados y cada uno de nosotros dio sus pros y sus contras a los puntos que más éxito habían tenido en las pruebas, fuera cual fuera el prototipo.
Implicación de los distintos roles (+)
Implicar al equipo y a los stakeholders en un trabajo común durante tres días unió los lazos más que nunca hasta ese momento. De hecho, pese a las reticencias iniciales para hacer el workshop, luego se nos pidió repetirlo para otras necesidades.
Seguir las normas a «rajatabla» (-)
En algún momento a los organizadores (una servidora y mi ayudante) se nos olvidó que era más importante la participación que el hecho de cumplir las reglas de las actividades. Por ejemplo, hay actividades en las que no se puede hablar, pero al final, da igual si alguien habla, no somos policías, pretendemos la colaboración máxima.
Si quieres dar feedback (opinar sobre qué otras cosas podríamos haber mejorado o qué te ha gustado), o si quieres tener más detalle de alguna actividad, no dudes en dejar un comentario y lo atenderé encantada.