Pensando fuera de la caja !

Las herramientas y metodologías para pasar de las ideas a proyectos concretos de pequeña y mediana envergadura están produciendo un cambio radical en las organizaciones y estructuras diseñadas para solucionar problemas de manera innovativa.

Pensar fuera de la caja es un concepto que suena bien pero que necesita para cristalizar que sea desarrollado dentro de mecanismos flexibles, poco estructurados, rápidos y enfocados en el conocimiento y desglose previo del problema, de modo tal de meternos dentro de estados emocionales donde el amor por la dificultad a resolver sea más grande que el cariño por la solución.

El entrenamiento como coach me ha servido bastante en lo personal, sobre todo en un aspecto sustancial, el cual muchas veces y por diversas razones me resultaba esquivo: mantener un alto nivel de capacidad aprendiente. Declararse un aprendiz a tiempo completo es el punto de partida para abrir nuestra mente, participando de procesos de los cuales hubiéramos huido sin más, anclados a nuestros más arraigados prejuicios.

Esta semana tuve la fortuna de participar, junto a otros compañeros de trabajo, de un programa de hackathon vinculado a la innovación en el área de la biotecnología. Aquí, sin lugar a dudas, me ayudó bastante el aprendiz que aprendí (valga la redundancia) a llevar casi siempre conmigo. Si bien había leído sobre este proceso, y participado de manera parcial en algún evento vinculado, nunca lo había hecho de manera formal, dentro de un proceso muy bien organizado. Traigo a colación para aquellos que no están tan familiarizados con esta terminología que es muy común en las áreas tecnológicas, a que se refiere específicamente el concepto.

El término ‘’Hackathon’’ es, sin duda, una palabra compuesta; una fusión entre ‘hacking’ y ‘marathon’. Este término puede llevar a error a aquellas personas que asocien la palabra ‘hacking’ con delitos informáticos y ciberdelincuentes. Sin embargo, esta práctica delictiva tiene muy poca relación con un hackathon. ‘Hacking’, en este contexto, hace referencia a la resolución de problemas técnicos a través de una manera innovadora y muy poco convencional. El enfoque de los hackathones es, por tanto, muy constructivo, ya que los desarrolladores asisten a estos eventos para trabajar con el enfoque de crear un producto o una idea novedosa y útil. Los hackathones, por lo general, se enfocan en una temática tecnológica determinada que, a su vez, influye en los participantes del evento.

Lo particular y novedoso de estas jornadas de las cuales fuimos parte, pueden resumirse en lo siguiente:

1. La biotecnología pudo sortear esa faceta de disciplina dura, a la cual acceden sólo los especialistas en la materia, para poder compartir la oportunidad de mejora o problema planteado con jóvenes, graduados o no, de distintas y diversas disciplinas.

2. La actividad integrada en torno a un facilitador especialista en design sprint, con la presencia de decisores y expertos (en este caso los que postulábamos el tema a tratar), agrupaba a estos jóvenes y muy entusiastas del pensamiento para accionar, dentro de equipos donde lo principal era fortalecer la sensación y la vivencia de que lo imposible no existe.

3. Los resultados conseguidos fueron muy buenos, pero el nivel superlativo se consiguió dentro del proceso mismo. El camino que fue de un accionar constante, vertiginoso, enriquecedor superó con creces las expectativas de muchos. Las horas que se vivieron se pueden resumir con estos dos versos de Antonio Machado extraídos del poema Caminante no hay camino:

«Caminante no hay camino, se hace camino el andar. «

o

«Caminante no hay camino, sino estelas en la mar».

A continuación, les dejó una breve reseña sobre la metodología design sprint, de modo tal que les sirva de referencia, generando quizás el interés por profundizar y aprender más sobre esta práctica, que aún con su corta edad, ha prendido bastante fuerte en el mundo de la innovación. Todos los que vivieron el proceso se adaptaron muy bien a esta sencila y fácil herramienta diseñada para obtener resultados en un muy corto plazo.

Design Sprint

Se trata de una metodología ideada por Jake Knapp en 2010 (actualizada en 2018), cuando trabajaba en Google Ventures. En ella mezcla las metodologías ágiles con el design thinking para obtener un proceso de 4 días en el que validar ideas.

En el Design Sprint original se necesitaban 5 días para poder realizar los 5 pasos del sprint, aunque en una actualización posterior en 2018 decidieron reducirlo a 4, adquiriendo la denominación de Design Sprint 2.0.

No se elimina ningún paso, pero sí se optimiza el tiempo y también se permite liberar al equipo antes, algo que es bastante importante en cualquier empresa (nadie quiere estar ‘encallado’ realizando la misma tarea durante mucho tiempo).

Fase 0: Consideraciones previas

Para que un Design Sprint funcione, antes de empezar deben realizarse determinadas tareas:

Montar el equipo. Cuanto más multidisciplinar sea, mejor, porque se aportarán puntos de vista distintos. Lo recomendable es que sea de entre 5 y 7 personas.

Bloquear 2 días enteros (de los 4) en el calendario de todo el equipo y encuentra el espacio adecuado.

Recopilar datos existentes. La investigación forma parte de la Fase 1, pero siempre es mejor tener la información ya existente a mano.

Redactar un pequeño documento en el que se explique brevemente el reto del Design Sprint. Es la forma de evitar llegar al día uno y tener que hablarlo todo.

Fase 1: Investigar y definir

La mañana del primer día está orientada a poner todo el equipo en la misma página. Se explica el reto y, entre todos, se decide qué parte se atacará.

Lo importante en esta fase es que cada miembro pueda hablar durante algunos minutos sobre su enfoque y punto de vista. De este modo, todos tendremos el mismo conocimiento.

La fase de investigación incluye procesar todos los datos ya existentes y, en la medida de lo posible, añadir más puntos de información mediante investigaciones complementarias:

Mapas de empatía

Entrevistas

Encuestas

FODA

Esta primera fase debe terminar con un documento en el que se definan sobre qué se actuará y cuáles son los principales insights (perspectivas) obtenidos.

Fase 2: Boceto de las propuestas

Cada miembro del equipo dedicará el resto del primer día a bocetar su propia solución al problema. Se trata de que cada uno trabaje de forma individual, ya que de esta forma se llegará a más soluciones y no habrá ninguna opinión que modifique las del resto.

Se trata de bocetos rápidos para transmitir una idea (que es lo que debe quedar más claro), por lo que no son necesarios conocimientos de diseño. Simplemente se trata de coger un papel y unos cuantos bolígrafos y ponerse manos a la obra.

Fase 3: Toma de decisiones

La mañana del segundo día se dedica a debatir y escoger qué es lo que se va a prototipar en la siguiente fase.

Para conseguirlo, se realizará una votación de cada boceto, decidiendo la opción que tenga más posibilidades de alcanzar el resto.

Una forma de votar es colgar todas las páginas y asignar “puntos” a cada solución. La que al final tenga más puntitos, será la escogida.

De esta tercera fase hay que salir con un storyboard (guión o guía gráfica) consensuado por todos, que tenga definidas claramente las pantallas a prototipar.

Fase 4: Prototipar el storyboard

El tercer día se dedica a prototipar el storyboard que se definió en la fase anterior. Es aquí cuando ya no hace falta que esté la mayoría del equipo, ya que será el equipo de diseño el encargado de prototipar.

El resultado final no debe ser un prototipo de alta fidelidad, sino un prototipo interactivo que sirva para explicar las funcionalidades básicas y en el que quede claro lo más esencial de la solución.

Por último, es importante finalizar el día teniendo claro qué es lo que se va a preguntar a los usuarios durante el test y qué se quiere validar.

Fase 5: Test con usuarios

La última fase del Design Sprint es la más crucial. En ella se pone a prueba todo el trabajo anterior y debe quedar todo bien registrado y documentado.

Se trata de realizar tests con usuarios reales para poder ver cómo interactúan con el producto, dónde hacen clic, en qué parte se encallan, qué dudas les surge por el camino, etc.

Lo ideal es poder grabar el test, ya que así podrán ver los resultados otros miembros del equipo que no puedan estar disponibles durante el día que se realiza.

Una buena metodología es el test de guerrilla, en el que se busca en un sitio concurrido posibles usuarios de la aplicación y se les pregunta si quieren realizar el test. Obviamente antes hay que pedir permiso para grabar y registrar sus acciones.

Si se trata de un producto con un público objetivo más específico, será necesario que ese día estén en la oficina presencialmente (la convocatoria se lanza días antes de empezar el Design Sprint).

Cómo registrar los resultados del test

Además de la grabación, es recomendable realizar un resumen del test. Esto puede realizarse fácilmente con un documento de Excel:

Crea una hoja nueva y reserva cinco columnas (o las que sean necesarias) para los nombres de los usuarios que realizarán el test

Formatea las celdas de modo que únicamente puedan ser contestadas con “Sí” o “No”.

En la columna de más a la izquierda, añade qué hipótesis quieres validar. No se trata de que el facilitador del test las pregunte directamente, sino que oriente el test para que el usuario las conteste de forma autónoma.

Finalmente, debajo de todo ello hay que reservar un espacio para anotar las frases o reflexiones más relevantes que haga el usuario mientras se le está realizando el test.

Al finalizar el test se podrá compartir el documento con el grupo para ver rápidamente cómo ha ido el test y qué es lo más importante que ha sucedido.

Entregables de un Design Sprint

Otro aspecto positivo de los Design Sprints es que permite finalizar el periodo de tiempo con bastantes entregables con los que se podrá ir trabajando durante los próximos días o semanas.

Conclusiones del Design Sprint: notas, los documentos obtenidos durante la fase de investigación, story board, etc.

Prototipo funcional

Un resumen del test con usuarios y qué se ha aprendido

Una hoja de ruta para continuar

Validación (o no) de las hipótesis iniciales

Desde mi perspectiva estos procesos de manos a la obra, donde lo más importante es empezar, son una ayuda sustancial a la hora de animarnos a pensar fuera de la caja, innovando de manera más efectiva.

Celebro que estos eventos reúnan a distintas vertientes de pensamiento y disciplinas que a priori parecen no encajar. Desde mi visión de ingeniero educado en una disciplina dura, estos son complementos muy necesarios a la hora de empatizar con las nuevas y bastante más desestructuradas corrientes de pensamiento.

Resultó impactante como los estudiantes que participaron adoptan estas ágiles metodologías de investigación y desarrollo de proyectos, ideando cosas desde la perspectiva que casi nada puede parecer insensato, excluyente o digno de una negación total.

Para finalizar les regalo completo el hermoso poema de Antonio Machado titulado “Caminante no hay camino”

Caminante, son tus huellas

el camino y nada más;

Caminante, no hay camino,

se hace camino al andar.

Al andar se hace el camino,

y al volver la vista atrás

se ve la senda que nunca

se ha de volver a pisar.

Caminante no hay camino

sino estelas en la mar.

Deja un comentario