Mantener una metodología Lean durante el crecimiento de una Startup y no morir en el intento

8º evento de IxDA Madrid

No podíamos irnos de vacaciones de Semana Santa sin hablar un poco de diseño, o en este caso de metodologías. Casi 90 personas nos juntamos en las oficinas de OnTruck para escuchar a dos de sus compañeras: Claudia Cuevas e Isabel Gárate, Product Designer y Product Manager.

En una charla muy amena llena de ejemplos y anécdotas hicimos un recorrido por la metodología de trabajo que utilizan en OnTruck tanto en sus proyectos como en la propia organización de la empresa y equipos.

Debido a su crecimiento (de 5 a casi 100 empleados en poco más de dos años) iteran continuamente sus procesos, tratando de ver los puntos más flojos y como solventar posibles bloqueos. Las fases que siguen desde el principio son prácticamente las mismas, pero han ido midiendo e iterando las cosas que no funcionan dentro de cada una de ellas sin dejar de ser Lean.

No queremos desperdicios, no queremos perder el tiempo y queremos que lo que hacemos sea lo más eficaz posible.

Antes de entrar en detalle en la metodología, Isa nos hizo una introducción muy rápida a la empresa, producto y stakeholders involucrados en el proceso, sin antes recalcar algo que a ningún diseñador se nos debería olvidar jamás:

Trabajamos con problemas y no con soluciones

Es decir, lo primero es entender la necesidad real del usuario, ¿cual es el problema al que se enfrenta? ¿que dificultades tiene? Para esto es necesario que las figuras de PM y PD trabajen de la mano:

• Product Manager: Trabajan con los stakeholders, tanto internos como externos para identificar problemas y priorizarlos. A veces es necesario validar que un problema existe realmente, por lo que se mide (tiempos, número de pasos necesarios…) para detectar puntos de mejora.
• Product Designer: Se encarga de liderar las fases del proceso en el que se da una solución al problema identificado.

Claudia comenzó a hablarnos de procesos contándonos como Toyota se esforzaba mucho por detectar dónde estaban los problemas en su cadena de montaje, mejorando mucho la calidad de fabricación de sus coches gracias a ello.

Esto inspiró y animó a OnTruck a invertir tiempo y esfuerzo en su metodología de trabajo, basada en Design Thinking. Estas son sus fases:

Discover

Es la primera fase: en la que se descubren y priorizan los problemas. Para que un problema sea considerado como tal, tiene que ir “avalado” por más de un equipo, es decir, más de un equipo tiene que estar de acuerdo con que ese problema existe.

Understand

Una vez identificado el problema a resolver, en esta fase se trata de entender el problema desde los puntos de vista de todos los stakeholders implicados.

Es fundamental comprobar tanto cualitativamente como cuantitativamente que hemos identificado bien el problema principal y todos los que hay alrededor, así como contrastar que los resultados de ambos análisis (cuantitativo y cualitativo) son coherentes.

Para entender cuales son los problemas de los usuarios con los que trabajamos es fundamental ir a donde están nuestros usuarios y ver de primera mano como usan nuestro producto, que medios tienen, si están en un sitio tranquilo o no… Todo esto nos ayuda a comprender mucho mejor a nuestros usuarios y sus problemas.

Diverge

Intentamos pasar siempre por esta fase, no importa lo grande o pequeño que sea el proyecto, porque si no muchas veces vamos a la solución obvia.

Mediante diferentes técnicas, como el crazy eight, se exploran diferentes soluciones al problema. A veces se escoge la obvia, pero esto no hace que la fase sea tiempo perdido, ya que se aprende a considerar diferentes opciones y argumentar sobre cada una de ellas. Además, es una fase en la que todos los compañeros pueden tener voz, por lo que se puede abordar el problema desde muchos puntos de vista.

Otra de las ventajas de esta fase es que se puede encontrar más de una solución válida y guardar algunas para el futuro. Descartar soluciones en un momento no significa que no se puedan retomar más adelante si se quiere iterar sobre una funcionalidad, por ejemplo.

Decide

Para esta fase se parte de una o más soluciones. Se juntan los equipos de producto, diseño y tecnología y trabajan juntos para valorar esfuerzo e impacto de cada una de las soluciones, para decidir cual de ellas se desarrollará.

En algunos proyectos se decide salir con un MVP, medir, y si los datos son positivos iterar sobre esa solución. Esto ayuda a no crear soluciones muy complejas desde un principio corriendo el riesgo de que no se usen.

Faseando la solución es más fácil detectar dónde nos estamos equivocando e ir corrigiendo los problemas con los que nos encontremos a lo largo del resto del proceso.

Design

Se diseña la solución elegida en la fase anterior teniendo en cuenta todos los casos que queremos abordar.

La solución no siempre es una pantalla. Puede ser un mail, un proceso…

Es fundamental empezar diseñando en papel y validar con los stakeholders antes de seguir avanzando en el proceso. Es mejor equivocarnos pronto y barato.

User testing

Durante esta fase se valida que la solución diseñada da respuesta a las necesidades del usuario.

Para esto, al igual que en la fase “Understand”, es importante ir al entorno del usuario y observar como usa la solución. Para interacciones sencillas o validar ideas también se puede hacer de forma remota: hoy en día existen muchas herramientas que nos permiten hablar por videollamada y testar prototipos online, por lo que no siempre es necesario desplazarse.

Build

En esta fase el equipo de tecnología desarrolla la solución. No existe la figura única de QA, si no que todo el equipo se encarga de asegurar que lo que se hace funciona, mantiene la calidad y no se va a perjudicar a otras partes del producto.

Se trabaja con historias, en las que se detalla la solución que se va a implementar para medir tiempo y esfuerzo. En estas historias también se definen los criterios de aceptación, y hasta que todo el equipo no ha dado su aprobación no se empieza a desarrollar.

Launch & Measure

Se despliega la solución. Aquí no acaba el proceso, ya que es especialmente importante seguir las métricas de lo implementado y validar que lo que se ha desarrollado a lo largo del proceso funciona.

A partir de lo que se observa gracias a las métricas se pueden detectar nuevos problemas y pequeñas mejoras en la solución. Es el punto de partida para iterar.

A modo de cierre, Claudia e Isa compartieron con nosotros un resumen del proceso, así como los dos puntos en lo que más se enfocan ahora mismo en OnTruck:

1. Obsesiónate con el cliente, sus problemas y necesidades
2. Debes poder ejecutar cambios en dos semanas.

Tras una ronda de preguntas de lo más interesante tuvimos el ya habitual networking, acompañado de unas cervezas cortesía de nuestro patrocinador KSchool, que además nos ha regalado un descuento de un 5% en sus cursos para los miembros de IxDA Madrid. ¡Muchísimas gracias por vuestro apoyo!

Muchas gracias a OnTruck por acogernos en vuestra casa para este evento, y especialmente a Isa y Claudia por lo maravillosamente bien que nos contasteis vuestro día a día de una forma sencilla pero llena de aprendizajes y reflexiones sobre nuestros procesos y nuestra profesión.

Mil gracias a Kschool por ayudarnos con las cervezas y el picoteo que tanto nos ayudan a quedarnos un ratito más intercambiando impresiones y haciendo crecer poco a poco esta comunidad que estamos creando entre todos.

Y por supuesto, gracias a todas las personas que vinisteis, nada de esto sería posible sin vuestro apoyo y vuestras ganas de seguir compartiendo mes a mes este espacio de aprendizaje. ¡Nos vemos en Abril!