¿Qué metodologías ágiles existen? ¿Qué es metodología ágil ejemplos? ¿Qué significa metodologías ágiles? ¿Cuáles son las metodologías más usadas?

Valorar más a los individuos y sus interacciones que a los procesos y las herramientas

Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero sin personas con conocimiento técnico y actitud adecuada, no producen resultados.

Valorar más el software funcionando que la documentación exhaustiva

El manifiesto no afirma que no hagan falta. Los documentos son soporte del software, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascendentales para aportar valor al producto.

Valorar más la colaboración con el cliente que la negociación contractual

Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle en el principio, o que si se definiera así tendrían al final menos valor que si se van enriqueciendo con retroinformación continua durante el desarrollo. También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio.

En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan.

Valorar más la respuesta ante el cambio que seguir un plan

Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente el cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre-establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.

El manifiesto ágil, tras los postulados de estos cuatro valores en los que se fundamenta, establece estos 12 principios:

1. Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
3. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los períodos breves.
4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
5. Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y recordándoles confianza para que realicen la tarea.
6. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
7. El software que funciona es la principal medida del progreso.
8. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica enaltece la agilidad.
10. La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se autoorganizan.
12. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

Roles

• Team member: todos los integrantes
• PRODUCT OWNER: el que conoce el negocio
• Scrum master: vigilante de que se cumplan las reglas del scrum. El que destraba, no es el leader del proyecto

Ceremonias

1. Reunión de planificación de product Backlog
2. Planificación del sprint
3. Sprint
4. Daily
5. Demostración del sprint
6. Retrospectiva

Artefactos

• Product backlog : user stories, planning poker
• Sprint backlog: Work items
• Tablero, burndown chart
• Software funcionando
• Tablero (otro)

Máximo 8 horas

Artefacto:

producto backlog : lista con requerimientos

User stories (hoja grande con requerimientos).

Tiene que tener descripción:

Como proveedor

Quiero poder entregar mis productos

Para poder

Tiene que tener estimación

Y prioridad: la pone el PO (varias UDS pueden tener la misma prioridad), los miembros del equipo pueden hacer sugerencias

Planning poker: son cartas que se utilizan para hacer la estimación

Los números son la serie de Fibonacci y vienen con un instructivo.

Son 13 cartas

Metodología: agarramos una US. Cada miembro tiene un mazo y elige una carta. Todos juntos destapan la carta a la vez. Si eligieron muy distinto se resuelve discutiendo y dando razones. Tienen que estar resuelto, y todos de acuerdo

Es muy importante tener un buen backlog, que las US estén bien hechas y bien estimadas

En la US muchas veces se ponen las validaciones (que vane en la demo)

• Una meta de Sprint.

• Una lista de miembros (y su nivel de dedicación, si no es del 100%)

• Una Pila de Sprint (lista de historias incluidas en el Sprint)

• Una fecha concreta para la Demo del Sprint.

• Un lugar y momento definidos para el Scrum Diario

• Máximo 4 horas
• Artefacto: Sprint backlog: tome algunas hojas del product backlog y los pongo en la pizarra
• Cada tarjeta grande (user story) se convierte en varios Work items (tarjetas chicas) y las ponemos en pendientes
• Cada WIKI tiene descripción, duración y la persona que se lo asigna
• Si una US es muy larga, la puedo partir
• Los WI deberían estar alineados con las US, podemos usar el mismo color
• El tablero tiene 3 columnas: pendiente, en proceso, finalizado
• La US que elegimos la ponemos en una 4ta columna a la izquierda (backlog)
• Creamos WI para pruebas, relevamiento, ets
• Se decide cuantas US hacemos en el sprint

El Dueño de Producto comienza la reunión resumiendo cuál es su meta para el Sprint y las historias más importantes. A continuación, el equipo las repasa y les asigna una estimación, comenzando con la más importante.

• Entre 2 o 4 semanas
• El tablero tiene 3 columnas: pendiente, en proceso, finalizado
• Voy resolviendo y muevo mi WI de pendiente, en curso, finalizado
• Cada sprint tiene un tablero
• La US que elegimos la ponemos en una 4ta columna a la izquierda (backlog)
• Además tengo el burndown chart, para medir el esfuerzo restante. Al final del sprint debería quedarme 0 WI. Puedo mirar WII u horas
• Se actualiza cada daily
• Este gráfico mide el rendimiento de mi proyecto, la velocidad
• Tengo un gráfico por cada sprint
• Este gráfico es muy importante

• Máximo 15 minutos
• Cada team member habla y mueve sus WI
• Se pueden unificar WI, se pueden agregar WI? NO
• En cada daily voy marcando el burndown chart

El indicador es el SW funcionado, tenemos que tener algo listo para cuando termina el sprint

Tengo un tablero con 3 secciones

Tres columnas:

• Bien: si hiciéramos el Sprint otra vez, volveríamos a hacer estas cosas igual.

• Mejorable: si hiciéramos otra vez el Sprint, haríamos estas cosas de forma diferente.

• Mejoras: ideas concretas sobre cómo podemos mejorar en el futuro.

Así que las columnas 1 y 2 son una mirada al pasado, mientras que la columna 3

mira al futuro.

Después de que el equipo genere todas estas ideas en post-its, utilizan “votación por puntos” para determinar en qué mejoras centrarse el próximo Sprint. Cada miembro del equipo tiene tres imanes y se les invita a votar sobre cualquier mejora en la que les gustaría trabajar en el próximo Sprint. Cada miembro del equipo distribuye los imanes como quiera, incluso colocando los tres en el mismo elemento.

Basándonos en esto, seleccionamos 5 mejoras de procesos en los que concentrarse, y los evaluamos en la siguiente retrospectiva

Características fundamentales:

• Programación por parejas: un mismo código se programa entre dos personas. Se potencian habilidades entre los dos. La idea es que trabajen coordinados y simultáneamente, no de turnos.
• Desarrollo guiado por prueba (TDD): primero se piensa cómo se va a probar, después cómo se desarrolla. Si se puede desarrollar un código de prueba automática, se puede desarrollar más ampliamente.
• Diseño incremental: se empieza simple y se va complejizando.
• Integración continua: los códigos que se van desarrollando simultáneamente deben estar constantemente integrándose. Esto se logra con una herramienta que lo hace automáticamente. La ventaja es detectar tempranamente errores o fallas de compilación.
• Propiedad colectiva del código. El producto que se va formando es propiedad de todos, y todos lo conocen. Se van rotando las parejas en las distintas funcionalidades, así se logra que todos estén al tanto y sean reemplazables mutuamente. Es de buen programador ir comentando el código a medida que lo va desarrollando.
• Espacio informativo: Espacios, pizarras, documentos, tablas donde se comparte la información.
• Estandarización del código: se toman convenciones en equipo de cómo se va a desarrollar, para que el código sea uniforme y se encuentren las mismas estructuras. Esto se logra fomentando espacios para que los equipos puedan compartir información.
• Ritmo sostenible/ trabajo enérgico: para trabajar enérgicamente, bien, y ser efectivo, las jornadas de trabajo deben ser limitadas. Se promueven actividades de ocio para fomentar la energía que se puede enfocar al trabajo. Pero, se pone el foco también en que el ritmo debe ser sostenible.

Como metodología, carece de ciertos aspectos en cuanto a planificación. Puede ser usado como buenas prácticas, para incorporarlas al desarrollo basado en otra metodología.

Se recomienda combinarlo con otras metodologías, ya que le falta manejo de proyectos

• Se puede combinar con SCRUM
• Es menos rígido
• ¿Cómo nace Kanban? En toyota
• Utiliza el concepto LEAN (just in time)
• Cero desperdicio
• Es aplicable a muchas disciplinas
• Vamos a usar otro tablero. Sí tiene TABLERO. En el tablero tengo que visualizar todo el flujo de trabajo. En el tablero tengo tantas columnas como actividades hay. Puede haber más o menos columnas, en general se usan post-it, para tareas de 1 día. Cada columna representa un estado del flujo de trabajo, o una cola (buffer) entre dos estados del flujo de trabajo. Empieza de forma sencilla y añade nuevas columnas cuando lo necesites.
• Tiene pocas reglas
• Limita el WIP(WORK IN PROCESS) (Work in Progress, trabajo en curso) - asigna límites concretos a cuántos elementos pueden estar en progreso en cada estado del flujo de trabajo. Los WI que están en una columna significa que están IP IN PROGRESS. ¿Cuántos WI puedo tener en cada columna? Depende de la capacidad de mi equipo. Se decide en el equipo: en la última columna puedo poner 100?
• Utiliza columnas con nombre para ilustrar dónde está cada elemento en el flujo de trabajo.
• El TODO (la columna 0) se va llenando todos los días
• Si hay más WI de los permitidos, ¿lo hablamos en el equipo? Si quiero cambiar el límite se puede. Se hace una convención del equipo y se vuelve a decidir. Ojo con el límite porque puedo quedar ocioso (ineficiente), queremos cero desperdicio
• Los cambios son conversados. ES MUY FLEXIBLE. EL MANIFIESTO ÁGIL se tiene que cumplir
• No tienen prioridad
• No hay ESTIMACIONES
• Se mide el LEAD TIME. Mide el lead time (tiempo medio para completar un elemento, a veces llamado "tiempo de ciclo"), optimiza el proceso para que el lead time sea tan pequeño y predecible como sea posible.
• Divide el trabajo en bloques, escribe cada elemento en una tarjeta y ponlo en el muro.
• No tiene ROLES predefinidos
• No tiene SPRINTS
• Mide el tiempo medio
• No tiene BURNDOWN chart
• Se pueden agregar DEMOs
• Se pueden combinar metodologías (scrum + kanban)

Kanban usa un mecanismo de control visual para hacer seguimiento del trabajo conforme este viaja a través del flujo de valor. Típicamente, se usa un panel o pizarra con notas adhesivas o un panel electrónico de tarjetas. Las mejores prácticas apuntan probablemente al uso de ambos. Kanban expone los cuellos de botella, colas, variabilidad y desperdicios. Kanban cambia el comportamiento y motiva a una mayor colaboración en el trabajo. Kanban propicia la evolución incremental de los procesos existentes, una evolución que generalmente está alineada con los valores del Agilismo y de Lean Kanban, por su naturaleza de Sistema Pull ("arrastre", "tirar"; la producción se realiza cuando el cliente retira un elemento terminado), también propicia diferir el compromiso tanto en la priorización del trabajo nuevo como en la entrega del trabajo existente. Un último comentario sobre Kanban es que el efecto de limitar el WIP proporciona predecibilidad sobre el tiempo de ciclo y hace que los entregables sean más fiables. La estrategia de "parar el proceso" ante impedimentos y bugs también parece promover altos niveles de calidad y un rápido descenso del re-trabajo.

• Visualiza el flujo de trabajo.

Los métodos ágiles se denominan a veces los métodos ligeros, en concreto, porque son menos restrictivos que los métodos tradicionales. De hecho, el primer principio del Manifiesto Ágil es "Individuos e interacciones sobre procesos y herramientas". Scrum y Kanban son muy adaptables, pero en términos relativos Scrum es más restrictivo que Kanban. Scrum te da más limitaciones, y así deja menos opciones abiertas. Por ejemplo Scrum prescribe el uso de iteraciones de duración fija, Kanban no.

Digamos que reducimos el límite de trabajo en curso, basándonos en la hipótesis de que esto va a mejorar nuestro proceso. Observamos cómo otros factores como la capacidad, el lead time, la calidad, y la predecibilidad evolucionan. Sacamos conclusiones de los resultados y ajustamos algunas cosas más, mejorando continuamente nuestro proceso.

Hay diferentes términos para referirse a este proceso. Kaizen (mejora continua en terminología Lean), Inspección y Adaptación (en terminología Scrum), control empírico de procesos o, por qué no, El Método Científico. El elemento más crítico de este proceso es el ciclo de retroalimentación, el feedback. Cambia algo => Observa cómo funciona => Aprende de ello => Cambia algo de nuevo. En general, lo que buscamos es obtener feedback en ciclos lo más cortos posibles, de manera que podamos adaptar nuestro proceso rápidamente.

Parecidos

• Ambos emplean sistemas de planificación "pull".

• Ambos establecen límites WIP.

• En ambos la visibilidad del proceso es la base de su mejora.

• Ambos tienen como objetivo la entrega temprana y frecuente de software.

• Ambos trabajan con equipos auto-organizados.

• Ambos necesitan la división del trabajo en partes.

• Ambos revisan y mejoran de forma continua el plan del producto en base a datos empíricos (velocidad / tiempo de entrega)

Diferencias

• Scrum dice que debemos tener equipos multidisciplinares.

Entonces, ¿Quién debe estar en cada equipo? No lo sé, experimenta.

• Scrum dice que el equipo selecciona cuánto trabajo incluir en

un sprint. Entonces, ¿Cuánto deben incluir? No lo sé, experimenta.

• Kanban dice que debemos limitar el trabajo en curso. Entonces, ¿Cuál debe ser ese límite? No lo sé, experimenta.

¿QUÉ ES LEAN?

OBJETIVOS

• Foco en valor añadido
• Eliminación de desperdicios
• Persigue la excelencia
• Pensar y actuar

EVOLUCIÓN

• Origen en la posguerra
• Taylor, Ford, Deming
• 1973 y el sistema JIT
• Globalización

Los 14 principios se agrupan en cuatro secciones:

1. Filosofía a largo plazo
2. El proceso correcto dará lugar a los resultados correctos
3. Añade valor a tu organización mediante el desarrollo de las personas
4. Aprendizaje, resolución de problemas y Mejora Continua.

• Principio 1: Base sus decisiones de gestión en una filosofía a largo plazo, a expensas de lo que suceda con los objetivos financieros a corto.
• Principio 2: Cree procesos en flujo continuo para hacer que los problemas salgan a la superficie.
• Principio 3: Utilice sistemas pull para evitar producir en exceso. Principio 4: Nivel la carga de trabajo (heijunka).
• Principio 5: Cree una cultura de parar, a fin de resolver los problemas, para lograr una buena calidad a la primera.
• Principio 6: Las tareas estandarizadas son el fundamento de la mejora continua y de la autonomía del empleado.
• Principio 7: Utilice el control visual de modo que no se oculten los problemas.
• Principio 8: Utilice sólo tecnología fiable y absolutamente probada que dé servicio a su personal y a sus procesos.
• Principio 9: Haga crecer a líderes que comprendan perfectamente el trabajo, vivan la filosofía y la enseñen a otros.
• Principio 10: Desarrolle personas y equipos excepcionales que sigan la filosofía de su empresa.
• Principio 11: Respete su red extendida de socios y proveedores, presentándose retos y ayudándolos a mejorar
• Principio 12: Vaya a verlo por sí mismo para comprender a fondo la situación (genchi genbutsu).
• Principio 13: Tome decisiones por consenso lentamente, considerando concienzudamente todas las opciones; implementarlas rápidamente (nemawashi).
• Principio 14: Convertirse en una organización que aprende mediante la reflexión constante (hansei) y la mejora continua (kaizen).

Los Siete Desperdicios

• Transporte. El movimiento innecesario de productos de un lugar a otro no agrega ningún valor, consume capital y espacio.
• Inventario..
• Movimiento. ...
• Tiempo muerto. ...
• Sobreproducción.
• Demasiados procesos. ...
• Defectos.

Los 5 porqués (5-Why) es una herramienta de análisis que trata de encontrar la causa raíz de un problema.

Ante la aparición de un problema debemos encontrar respuesta a dos preguntas:

¿Cuál es la causa raíz del problema? (base la para CORRECCIÓN)

¿Cuál es la causa por la que no nos hemos anticipado a él? (base para la PREVENCIÓN)

Partimos del síntoma del problema (paro espontáneo de una máquina, aparición de un defecto de fabricación, queja de un cliente…), y nos preguntamos ¿por qué? sucesivamente hasta que la causa raíz se vuelva evidente.

El número de preguntas no tiene porqué ser necesariamente cinco, pueden ser más o menos. Lo importante es no dejarse engañar por lo que en principio parece la solución al problema ni tampoco preguntarse indefinidamente el porqué hasta llegar a la “parálisis por el análisis”. Una solución al 60% hoy es mejor que una solución al 100% que nunca llega. Utilícese por tanto con sentido común.

Standard Work combination sheet

Es una herramienta del diseño para generar ideas innovadoras que centra su eficacia en entender y dar solución a las necesidades reales de los usuarios. Proviene de la forma en la que trabajan los diseñadores de producto. De ahí su nombre, que en español se traduce de forma literal como "Pensamiento de Diseño”.

Enlaza la creatividad y la innovación para transformar las ideas en propuestas prácticas y atractivas para los clientes o usuarios.

Es una de las herramientas más utilizadas por UX y pretende mejorar el estudio del concepto de la Persona a quien va dirigido nuestro producto o servicio.

El proceso de Design Thinking se compone de cinco etapas. No es lineal. En cualquier momento se puede ir hacia atrás o hacia delante si resulta oportuno, saltando incluso a etapas no consecutivas. Se comienza recolectando mucha información, generando una gran cantidad de contenido, que crecerá o disminuirá dependiendo de la fase en la que nos encontremos.

La empatía es la base del proceso de diseño que está centrado en las personas y los usuarios. Lo básico para ser empático es:

• Observar: Mirar a los usuarios y sus comportamientos en el contexto de sus vidas. Debemos siempre tratar de observar desde el exterior sin entrometerse.
• Involucrarse: Lo importante es siempre preguntarse “¿Por qué?” ya que eso descubre nuevos significados.
• Mirar y Escuchar: Pedir que nos expliquen cómo se hace algunas cosas y que vayan vocalizando lo que pasa por su mente cuando está en su trabajo.

Definir el problema

Estas ideas deben cumplir con ciertos criterios para que funcionen:

• Enmarcar un problema con un enfoque directo.
• Que sea inspirador para el equipo.
• Que genere criterios para evaluar ideas y contrarrestarlas.
• Que capture las mentes y corazones de las personas que has estudiado.
• Que ayude a resolver el problema.

Idear las posibles soluciones

Brainstorms, mind maps, prototipos y storyboards

Pero el utilizar todas no significa éxito, es necesario separar el área de generación de ideas del área de evaluación de ideas.

La creación de múltiples ideas permite atacar distintos focos:

• Pensar sobre soluciones que son obvias y por lo tanto aumenta el potencial de innovación del set de posibilidades
• Aprovechar de mejor manera las distintas visiones de cada equipo de trabajo y el trabajo colectivo
• Descubrir áreas inesperadas de exploración creando mayor volumen y mayores opciones para innovar.

Prototipar

Durante el proceso se desarrollan técnicas con un gran contenido visual y plástico. Esto hace que pongamos a trabajar tanto nuestra mente creativa como la analítica, dando como resultado soluciones innovadoras y a la vez factibles. Este proceso se va refinando mientras el proyecto avanza y los prototipos van mostrando más características funcionales, formales y de uso.

¿Por qué hacer prototipos?

• Para inventar, construir y pensar en resolver el problema
• Para comunicarse.
• Para empezar conversaciones. Las conversaciones con los usuarios son más eficientes cuando están concentradas sobre algo con que conversar como un objeto.
• Para cometer errores antes y poder visualizarlos para encontrarles solución.
• Para evaluar las alternativas. Ayuda a desarrollar distintas ideas sin tener que comprometerse con una demasiado temprano.
• Para controlar el proceso de la creación de soluciones. Ayuda a identificar distintas variables para poder descomponer grandes problemas que se puedan evaluar y arreglar de mejor forma.

¿Cómo hacer prototipos?

• Empieza construyendo:
• No le dediques demasiado tiempo a un prototipo:
• Identifica las variables: cada prototipo debe ir respondiendo preguntas cuando se esté evaluando.
• Trabaja los prototipos con un usuario en la mente:

Evaluar

Este paso consiste en solicitar feedback y opiniones sobre los prototipos que se han creado

de los mismos usuarios y colegas además de ser otra oportunidad para ganar empatía por las personas de las cuales estas diseñando de otra manera. Una buena regla es siempre hacer un prototipo creyendo que estamos en lo correcto, pero debemos evaluar pensando que estamos equivocados. Esta es la oportunidad para refinar las soluciones y poder mejorarlas. Idealmente se debe evaluar y testear en el contexto mismo del usuario.

¿Por qué Evaluar?

• Para refinar prototipos y soluciones.
• Para aprender más sobre el usuario. Es otra oportunidad para crear empatía a través de observaciones

¿Cómo evaluar?

• No lo digas, muéstralo: dale a los usuarios tus prototipos sin explicar nada. Deja que la persona interprete el objeto y observa tanto el uso como el mal uso de lo que le entregas y cómo interactúan con él, posteriormente escucha todo lo que tengan que decir al respecto y responde las preguntas que tengan.
• Crea Experiencias: no es suficiente solo entregarles el objeto, lo ideal es crear el ambiente y recrear la experiencia para tener una visión más acabada del contexto.
• Pídele al usuario que compare: entregarle distintos prototipos para probar dándole al usuario una base para poder comparar, esto revela necesidades potenciales.

Equipo

En el Design Thinking es imprescindible trabajar en equipo. Cuanto más diverso sea, mejor. Así podemos sumar puntos de vista, conocimientos y experiencia. Es imprescindible que haya al menos una persona con conocimientos sobre la metodología que sepa guiar el proceso. Y aunque debe tener un núcleo estable de personas que participen hasta el final, se podrán sumar otras dependiendo de la fase en la que nos encontremos. Por ejemplo, en la generación de ideas o en la prueba de prototipos.

Cada integrante del equipo debe ser colaborativo, humano, experimental, abierto, optimista, empático, creativo, en constante búsqueda y de pensamiento global.

Algunos roles son:

• Jefe de proyecto: tiene mucha experiencia aplicada con el pensamiento de diseño y el pensamiento integrador, entiende y sabe cómo usar una variedad de marcos y enfoques diferentes para diseñar soluciones a varios problemas, y no solo uno.
• Representante de clientes: puede ser la voz del cliente o usuario final.
• Expertos en diseño: personas con una gran experiencia en algún área de diseño que sea relevante para el proyecto.
• Otros profesionales: podría ser técnico, podría ser investigador, podría ser un antropólogo o un psicólogo, depende mucho de la naturaleza del proyecto. En general estos perfiles son útiles en la primera etapa del proyecto, cuando se busca empatizar con el usuario, conocerlos y recolectar información útil para el análisis de comportamientos.

Para un buen trabajo en equipo es importante que:

• Los miembros del equipo compartan (al menos algunas) aspiraciones
• Los patrones de comunicación se entiendan
• Los miembros del equipo sepan quién sabe qué
• Los miembros del equipo compartan un conjunto de casos de referencia a los que pueden referirse
• Tengan un vocabulario compartido

Una tendencia dentro del Design Thinking es pensar cada rol como un modelo de roles de diseñadores:

• Diseñador como co-creador
• Diseñador como investigador
• Diseñador como comunicador
• Diseñador empresario
• Diseñador como generador de capacidades
• Diseñador como facilitador
• Diseñador como estratega

Técnicas

Un proyecto de Design Thinking requiere del uso de numerosas técnicas que facilitan el desarrollo correcto del proceso. Conocer estas técnicas, aprenderlas e interiorizarse permite comprender y utilizar la metodología para obtener mejores resultados.

Existen muchísimas técnicas que se aplican a esta metodología, nombraremos solo algunas de ellas, a saber:

¿Qué? ¿Cómo? ¿Por qué?

“Qué Cómo y Por qué” son herramientas que pueden ayudar a llegar a niveles de observación más profundos.

Estas preguntas ayudan a moverse desde observaciones concretas de una situación en particular a emociones más abstractas y a otras motivaciones que están en juego en una situación.

• Empezar con Observaciones Concretas (Qué): ¿Qué está haciendo la persona observada en una situación particular o en una fotografía? Es importante darse cuenta y anotar los detalles, tratar de ser objetivo y no asumir nada en esta primera parte.
• Trata de entender (¿Cómo): ¿Cómo está haciendo el trabajo la persona que es observada? ¿Requiere de algún esfuerzo? ¿Parecen apurados? ¿Tienen dolor? ¿Pareciera que la actividad o situación está impactando su estado positiva o negativamente? Usa frases descriptivas llenas de adjetivos.
• Da el paso hacia el limbo de la interpretación (Porqué): ¿Por qué la persona que observamos está haciendo lo que hace y porqué lo hace de esa manera en particular?

Este paso usualmente requiere hacer adivinanzas o presunciones fundadas en algo en relación a la motivación y las emociones del usuario. Este paso revelará áreas y temas que deberemos testear con usuarios y normalmente arrojará conclusiones inesperadas sobre una situación en particular.

Entrevistas

Lo que queremos es entender los pensamientos, emociones y motivaciones de la persona para determinar cómo innovar para él o ella. Entendiendo las decisiones que esa persona toma y su comportamiento, podemos identificar sus necesidades y diseñar soluciones para satisfacerlas.

• Pregunta ¿por qué? Aun cuando creamos que sabemos las respuestas, tenemos que preguntarle a la gente por qué hace o dice algo. Las respuestas pueden sorprendernos. La conversación que parte de una pregunta debería continuar por el tiempo que sea necesario.
• Incentiva las historias. Sin importar si las historias que la gente cuenta son o no reales, nos revelan lo que la gente piensa del mundo. Tenemos que hacer preguntas que incentiven a la gente a contar historias.
• Pon atención al lenguaje no verbal. Debemos ser conscientes del lenguaje corporal, de los gestos y de las formas.
• No hagas preguntas binarias. Las preguntas binarias pueden ser respondidas con una sola palabra, es conveniente invitar una conversación basada en historias.
• Haz una pregunta por vez, una persona a la vez. Es importante resistir a la urgencia de emboscar al usuario.
• Asegúrate de estar preparado para documentar. Las entrevistas deben ser en pareja, debido a que es imposible involucrarse con el entrevistado y tomar notas apropiadamente al mismo tiempo.

Observación encubierta

Esta actividad consiste en observar a un usuario interactuando con un producto, servicio o prototipo, sin que sepa que está siendo evaluado. Se puede utilizar en la fase inicial de Empatía, para observar las reacciones sinceras de los usuarios, e igualmente en la fase de Testeo.

Mapa de empatía

Un buen diseño se basa en un profundo entendimiento por las personas de las cuales estamos diseñando. El mapa de empatía es una herramienta que nos ayuda a sintetizar las observaciones y descubrir ideas inesperadas.

Desempacar (Unpack): En un pliego, pizarra o muro, crear un cuadrado dividido en cuatro cuadrantes.

Después de revisar post-its, notas y material, se debe llenar el espacio con notas e información del usuario en relación a estos cuatro elementos:

• SAY (Lo que dice): Frases que el usuario haya dicho
• DO (Lo que hace): Acciones y comportamientos que notaste
• THINK (Lo que piensa): Lo que puede estar pensando ¿Que te dice de su comportamiento?
• FEEL (Lo que siente): ¿Qué emociones puede estar sintiendo?

Es preciso notar qué pensamientos/creencias y sentimientos/emociones no se pueden observar directamente.

Identificar necesidades: “Necesidades” son requerimientos humanos, físicos o emocionales; y cosas que el usuario quiere lograr. Las necesidades ayudan a definir los desafíos de diseño. Recuerde que las necesidades son verbos (actividades o deseos en que el usuario pueda necesitar ayuda), no son sustantivos (soluciones).

Identificar ideas: Una idea es descubrir algo inesperado o tener una para responder de mejor

manera un desafío de diseño. ¿Estas ideas generalmente nacen de dos contradicciones entre atributos del usuario (Dentro de un cuadrante o entre cuadrantes distintos) o al preguntarse “Por qué? Cuando notas un comportamiento particular. Escribe o anota potenciales ideas a un lado del mapa de empatía. Una manera de despertar la creatividad es capturando “tensiones” y “contradicciones” durante el trabajo.

Brainstorming

El objetivo principal del brainstorming es impulsar el pensamiento colectivo del grupo por medio de la conversación, escuchando y construyendo sobre otras ideas.

Se aplica mucha energía en cortos periodos de tiempo, como 15 o 30 minutos de alto compromiso y se utiliza una pizarra blanca siempre buscando la postura activa de estar parados y todos juntos para darle mayor efectividad al trabajo.

Existen al menos dos maneras de capturar ideas con el brainstorming:

• Describe: Informa de manera escrita y visual en la pizarra todas las ideas de cada miembro del equipo. Es muy importante captar cada una de las ideas sin importar la sensación personal sobre esa idea.
• Todos juntos: Cada persona debe escribir cada una de sus ideas mientras se les ocurren y en seguida compartirlas verbalmente con el grupo. Por eso se utilizan los post-it para poder escribir la idea y posteriormente ubicarla en el muro.

Storyboard o Guión gráfico

Sostener la conversación sobre la funcionalidad de una solución mediante herramientas visuales.

Esta técnica consiste en definir las distintas actividades que debe desarrollar un usuario en el uso de la solución, y plasmarlas de forma gráfica mediante viñetas que ayudarán a entender y a evaluar la experiencia.

Prototipos de empatía

El testear los prototipos con los usuarios durante la etapa de evaluación es una práctica común en el proceso de diseño. Sin embargo, el hacer y evaluar prototipos con los usuarios en etapas iniciales nos entrega información importante que no sucederá ni con entrevistas ni observaciones. Es importante estar consciente de que cuando se utiliza esta técnica se debe considerar dos cosas, lo que puedes aprender de la solución y lo que puedes aprender sobre el usuario. El aprendizaje a través de la empatía siempre será bienvenido.

Además, siempre puedes desarrollar prototipos o crear situaciones diseñadas específicamente para adquirir empatía sin ni siquiera tener una solución en mente o haber llegado a la etapa de evaluación. A esto algunas veces se le llama “empatía activa” porque ya no eres un simple observador si no que estas creando condiciones para recopilar información nueva. De la misma manera que un prototipo para una solución ayuda a entender el concepto, también un prototipo con empatía ayuda a adquirir conocimientos sobre el contexto, el espacio y el del usuario.

Como hacer prototipos con empatía

• Pídele al usuario que dibuje algo (por ejemplo, “dibuja lo que piensas sobre gastar dinero, o dibuja sobre cómo vas al trabajo”) para después conversar sobre el dibujo.
• Inventa un juego y hazlo más interactivo para explorar temas que te interesen (por ejemplo, se puede crear una simple cantidad de cartas con las soluciones dibujadas y hacer que el usuario elija entre las que encuentre más interesantes).
• Simula o actúa aspectos del usuario para poder comprenderlo de mejor manera (por ejemplo, si tu usuario es una dueña de casa que tiene que armar un mueble con un cuchillo, trata de armar un mueble con un cuchillo de tu cocina).

Prototipos en bruto

El prototipado en bruto implica acompañar la explicación de una idea, desarrollando prototipos rápidos con cualquier material que se encuentre alrededor. Ayuda a mejorar la interacción entre los miembros del equipo y a llegar a definiciones más concisas de las ideas a desarrollar.

Pruebas de usabilidad

Se le pedirá a una serie de usuarios que desarrollen tareas normales con los prototipos, para luego hacerles preguntas concretas sobre la usabilidad justo en el momento de haber terminado dichas tareas.

Evaluar con usuarios

Hacer evaluaciones con los usuarios es una parte fundamental del diseño centrado en el ser humano. Estas evaluaciones se hacen para refinar la solución y también para pulir el conocimiento que existe sobre el usuario para el cual se está diseñando. Por lo demás, cuando estás evaluando con el usuario deberíamos considerar dos cosas, las opiniones y feedback que tenga del usuario, y aprovechar la oportunidad para adquirir más empatía. Cuando estás interactuando con tu usuario final es como volver a la etapa de observación y empatía.

Procedimiento:

• Se debe estar atento a múltiples aspectos cuando se está usando este método. Uno es el prototipo, el segundo es el contexto y/o escenario donde se está practicando la evaluación y tercero es el cómo se observa y documenta la información y feedback recibidos. En relación a los dos primeros aspectos, es necesario testear y evaluar en un tipo de contexto que entregue las mayores facilidades para poder reunir un feedback significativo y reflexionar sobre cómo el prototipo y el contexto podrían interactuar. Si el prototipo fuera el contexto en sí, piensa cómo encontrar a la gente correcta (ej: los usuarios relacionados directamente con la situación) y crea un ambiente y sintonía para poder recolectar información lo más fidedigna posible.
• Crea roles de equipo para cada integrante del grupo durante esta etapa.
• Anfitrión: Debes ser capaz de trasladar al usuario desde la realidad hacia el contexto del prototipo para que pueda comprender el escenario. Como anfitrión también corresponde guiar las preguntas cuando sea necesario.
• Jugadores: Es necesario actuar ciertos roles con el equipo en el escenario para poder crear la experiencia del prototipo.
• Observadores: Es muy importante tener miembros del equipo que estén solamente mirando y observando la experiencia del usuario con el prototipo.
• Deja que el usuario experimente con el prototipo. Muéstralo, no lo digas. Dale al usuario el prototipo, y un mínimo de información solo para que lo puedan entender. No expliques lo que hace.
• Que el usuario vocalice mientras vive la experiencia.
• Observa activamente. Observa cómo manipula, usa (o mal usa) lo que le has entregado. No corras a corregir lo que la persona está haciendo, sólo observa.
• Sigue con las preguntas. Es lo más importante y valioso de esta etapa.