Día 1 — Arranque del Sprint de Diseño
Originalmente, teníamos apartado en nuestras un sprint para un cliente que nos canceló. Como ya habíamos agendado un cuarto, conseguido los materiales y coordinado nuestras agendas; Decidimos hacer un sprint de todos modos.
Nuestro plan sería lanzar un Producto Mínimo Viable en 3 semanas. Esta semana trabajaremos en Sprint de diseño. Después haremos una planeación de trabajo que permitiría -en teoría- lanzar la solución en dos semanas.
Primero lo primero, ¿Qué es un Sprint de Diseño?
Un Sprint de diseño es un proceso de diseño en que transformar una idea en un prototipo y lo validas con clientes en 5 días. La razón por la que los Sprints se volvieron populares es que Google Ventures, (Ahora GV) los hace.
Durante los design sprints, tienes una temática por día. Por ejemplo, los lunes se usan para entender el problema. Los martes para divagar y pensar en la mayor cantidad de soluciones. Los miércoles eliges la idea ganadora. Los viernes pruebas tus hipótesis con clientes potenciales.
Los Sprints de Diseño son parecidos al método de Bruno Munari. La diferencia principal radica en que con los Sprints de Diseño tienes límites de tiempo.
Nuestro proceso de Sprint de Diseño, fue inspirado por Google Ventures, Thoughtbot y otras agencias de primer nivel. Tomamos las prácticas que más nos gustaban de ellos, e incluimos unas que según nosotros necesitaban.
Para entender, usamos Mapas de Empatía y Diseño de Personas. Esto nos ayuda a identificar quiénes serían las personas ideales para entrevistar el día viernes. Queremos entender sus motivaciones y problemas. Entender al usuarios nos ayuda a escribir mejor copy para la página web.
Para generación de ideas usamos Relaciones Forzadas como punto de partida. Las relaciones forzadas nos permiten traer conceptos de otras industrias o conceptos extraños.
Nuestra Idea:
Ayudar a desarrolladores en ciudades pequeñas a ser mejores en su trabajo y conseguir reconocimiento como si estuvieran en Sillicon Valley.
Nuestro Objetivo:
Lanzar una Solución Minima Viable que desarrolle una comunidad en un Design Sprint & un sprint de desarrollo con Phoenix y React.
Día 1: Entender al Cliente
En el primer día, nos enfocamos exclusivamente en el cliente. Casi todos en nuestro equipo son desarrolladores (Yo soy la excepción). Siendo honestos, todos nos hemos sentido frustrados por no saber si estamos haciendo las cosas de la manera correcta.
Por ejemplo, hasta donde sabemos, somos la única agencia en la ciudad que está desarrollando con Phoenix-Elixir. La comunidad de Phoenix es genial, pero no tenemos a alguien que nos pueda ayudar en nuestra ciudad.
Queremos encontrar la forma de hacer programas con: Mejor código y Mejores Prácticas.
El plan de Actividades:
Presentaciones:
En este caso, las presentaciones fueron cortas. Todos nos conocemos de trabajar como un equipo por los últimos 9 meses. Elegimos a Polo como “Product Owner” y responsable de tomar decisiones. Nos vendió la idea según lo que habíamos platicado en semanas pasadas.
Presentar el Tablero de Back-Burn:
Una disculpa. Escribir acerca del proceso de un Sprint de Diseño va cargado de mucho “Pochismo”. El back-burn es un lugar en el que anotamos todas las ideas que se nos han ido ocurriendo. Solamente porque una idea llegó antes o después de tiempo no significa que sea eliminada.
Presentar el Tablero de Suposiciones:
Anotamos todo lo que suponemos que va a pasar. En nuestro caso, creemos que las personas prefieren una gran cantidad de reseñar de personas con todos los niveles en vez del de un solo experto. Escribimos más de 30 cosas que asumimos y cómo pensamos validarlas.
¿Hacia dónde vamos?
Tener una visión clara del producto es la mitad del problema. Para entender la visión usamos dos ejercicios. El primer ejercicio se llama “Primera Plana”. Durante el ejercicio de primera plana redactas una historia de un periódico acerca de tu visión para el producto. Cada uno de los participantes lee la nota y se identifican los elementos en común. Con esta información podemos redactar nuestra “Declaración del Problema” e identificar las cosas que pueden arruinar nuestro proyecto.
Mapas de Empatía y Diseño de Personas:
Incluimos estas técnicas en nuestro proceso de diseño. Idealmente queremos que todas las personas en el sprint logremos “Entendimiento Común”. Trabajando con mapas de empatía y diseño de personas dejamos de diseñar para un usuario anónimo. Nuestra persona para este sprint es Francisco, un recién graduado de ingeniería en software que quiere aprender una habilidad nueva.
Diagramas de Carril de Nado:
Los diagramas de Carril de Nado son un esquema simplificado de “Service Blueprint”. Los usamos para entender cómo interactúan los usuarios entre ellos y con el sistema. El carril de nado nos sirve de base para los “Blueprints” y el Mapeo de historias.
Lunch:
Nos dio hambre y ya no podíamos pensar. Comimos Subway, aunque no es lo recomendable por que da sueño. Afortunadamente no nos dio mal del puerco.
¿Cómo podríamos …?
Después de comer entrevistamos a algunos amigos que querían aprender una nueva tecnología. Entendimos el proceso en el que un desarrollador joven y relativamente inexperto aprende algo nuevo.
Nos dimos cuenta que el aprendizaje se da por prueba y error. Pero una vez que funciona, quieren entender por qué funciona y cómo pueden hacerlo mejor.
Card Sorting:
organizamos todos nuestros “¿Cómo podríamos?” y los agrupamos en temas en común. Al poco tiempo nos dimos cuenta de la tendencia. La mayoría de las personas aprenden de guías como esta y sesiones organizadas con amigos o profesores.
El equipo empezó a divagar con formas en las que podríamos descubrir más cosas. Afortunadamente, nuestro Product Owner, se apegó a la visión original e hizo las preguntas difíciles.
Las Preguntas Críticas.
¿Le gustaría a los desarrolladores jugar un juego en el que dan consejos en tiempo-real? ¿Los desarrolladores prefieren el consejo de un experto, o el conocimiento de la masa? ¿Cómo podemos mantener múltiples usuarios conectados al mismo tiempo? ¿Cómo podemos identificar “Calidad” y “Expertise” más allá de estrellas y likes?
¿Qué salió bien?
El equipo se comprometió con la idea. Estamos desarrollando este producto por nuestra propia cuenta. Vivimos en una ciudad mediana. Sí hay muchos profesionales en T.I. pero no en las tecnologías que usamos.
Creamos una buena cantidad de conocimiento y entendimiento. Logramos alcanzar entendimiento general y un consenso con respecto a nuestro cliente ideal.
En general, mejoramos los tiempos de ejecución desde el último sprint que facilitamos. En esta ocasión incluimos hojas de trabajo impresas. Nos dimos cuenta que aunque llevar cosas impresas reduce “Los jugos creativos”, ayuda a explicar conceptos complicados.
¿Qué salió mal?
Sobre-estimamos el tiempo en la actividad de Card Sorting, y sub-estimamos el tiempo para desarrollar empatía. Vamos a considerar estos aspectos para los siguientes sprints.
¿Ustedes qué piensan?¿Se nos olvidó algo? Díganoslo en los comentarios.
What do you guys Think? Did we miss something? Let us know in the comments. P.S. We are about to launch our new website. We will share it once it’s ready.
