Las metodologías ágiles como problema de Diseño

Cuando nos planteamos integrar Experiencia de Usuario y Metodologías Ágiles, el encuadre nos condiciona a pensar que una vez que identifiquemos el punto de encuentro, tendremos todas las respuestas que necesitamos.

Esto sería acertado y suficiente, si no hubiéramos tenido desencuentros antesde la aparición de las metodologías ágiles. Aplicaría si hubiéramos venido trabajando fenómeno hasta que en el año 2001 fuera publicado el Manifiesto Ágil; la realidad es un poco más compleja.

Las metodologías ágiles suelen ser propuestas o impuestas por el área de Ingeniería, y allí es cuando podemos ver que el universo “metodologías ágiles” está compuesto por dos dimensiones: Ingeniería y Gestión. La relación entre Diseño e Ingeniería viene siendo el marco del problema ya no antes del 2001, sino desde tiempos inmemoriales: arquitectos e ingenieros llevan siglos hablando mal unos de los otros.

El primer paso para lograr una convivencia sana, es resolver la relación entre Diseño e Ingeniería. Para eso, me gusta mucho esta definición que conocí por Bret Victor: “La tecnología satisface necesidades humanas, amplificando capacidades humanas”.

Esta definición resulta reveladora en varios aspectos. Primero que nada: Sin persona, no hay tecnología. En segundo lugar, permite entender que la Ingeniería se ocupa de los aspectos funcionales, los que se ajustan al problema… y el Diseño se ocupa de que lo que se proyecta, se adapte a la persona, habiendo entendido sus necesidades y capacidades. La tecnología no se limita a lo mecánico; no es algo que inventan los ingenieros y que los diseñadores coloreamos. Sin Diseño no hay tecnología: hay meras curiosidades técnicas.

Para incorporar Diseño al proceso, encuentro muy útiles las tres preguntas críticas: ¿Qué problema queremos resolverle…? ¿…a quién(es)? y ¿Cómo sabremos si lo logramos? Estas preguntas permiten integrar en una sola conversación a las tres áreas del problema: Ingeniería, Diseño y Gestión.

Cuando hablamos de Gestión, es bueno entender qué es una Metodología: un marco para organizar un proceso que involucra personas. Lo importante de esta definición es que nos revela lo que una Metodología no abarca.

Una metodología no reemplaza a las personas (involucradas en el proceso),las conversaciones (herramienta para compartir visión de futuro y coordinar acciones), ni a la toma de decisiones. Elegir una metodología es, de por sí, una decisión.

Una metodología no puede prescribir decisiones, de la misma manera en que las reglas de tránsito (ej. “circular por la derecha”) no pueden dictarnos a dónde ir: sólo nos pueden ofrecer la organización necesaria para llegar a destino reduciendo el riesgo de accidentes.

La toma de decisiones es una parte fundamental del Diseño, y el mayor valor que aporta al proceso. Es frecuente que quienes nos contratan, consideren al Diseño sólo en cuanto a la ejecución de Diseño, esto es, hacer “bonitas” las decisiones de diseño tomadas previamente por Ingeniería y Negocio (sin siquiera ser conscientes de qué es una decisión de diseño).

Nos corresponde a los diseñadores marcar las distinciones correctas, proponiendo y cumpliendo la promesa de ayudar a Ingeniería y Negocio a tomar mejores decisiones, al punto que las decisiones de Diseño pueden alimentar a las decisiones de Negocio en las cuales deben basarse.

Cuando se considera al diseño como la mera ejecución, pareciera ser que un proyecto puede considerarse más o menos complejo por la “cantidad de pantallas” a producir — o cualquier otro entregable que pueda ser cuantificado.

Lo que encontramos en Kambrica trabajando sobre este problema, es que la complejidad del Diseño se puede entender de manera más apropiada como producto de la complejidad de la ejecución por la complejidad de las decisiones. Este modelo nos permite mostrar más claramente el rol necesario de UX en facilitar los procesos de toma de decisiones de los stakeholders, y brindar información para que resulten basados en evidencia.

Otra distinción importante hace al uso vulgar del término Ágil. Particularmente de parte del Negocio, se expresa interés en adoptar metodologías ágiles por la idea de lograr rapidez.

La realidad es que la rapidez no forma parte de los postulados del manifiesto ágil: lo que proponen es respuesta ante el cambio en lugar de aferrarse a un plan. En otras palabras, ágil es el esquiador que esquiva los obstáculos y llega a la meta; apurado, es el que llega al hospital.

El esquiador apurado se arroja a la meta ciegamente, en un acto de fe impelido por la ansiedad. El esquiador ágil mantiene sus sentidos abiertos para un constante proceso de toma de decisiones basado en evidencia: un ciclo de observación, orientación, decisión y acción.

En un proyecto, la investigación UX es lo que permite información para toma de decisiones basada en evidencia. Sin embargo, suele ser desestimada con el pretexto de que “es lenta”, que es otra forma de decir “no hay tiempo”. Ahora bien: el tiempo no es algo que se almacena en cajón. El tiempo es algo que se dispone. ¿Qué significa realmente “no hay tiempo”?

Supongamos que alguien va a un centro de esquí, pide unos esquíes y cuando el dependiente le pregunta cuánto calza, el cliente dice “no tengo tiempo de ponerme las botas, sólo quiero los esquíes”. Lo que quiere decir, es que no entiende las botas como condición necesaria para usar los esquíes.

Los profesionales de UX tenemos que aprender a escuchar “no tengo tiempo” no como una negativa inflexible, sino como una invitación a señalar la condición necesaria entre nuestra propuesta y lo que nuestro cliente necesita.

En el proceso de decisión de nuestro cliente, hay una balanza con dos bandejas: una, lo que no quiere, problemas presentes o futuros, sus miedos; y otra, lo que quiere, el futuro del cual quiere ser parte, su deseo.

Atender a las preocupaciones es crítico para lograr atención: todo lo que propongamos antes de haber satisfecho ese punto, será ignorado o malinterpretado, al punto que en lugar de ser entendido como parte de la solución, puede ser considerado como problemas adicionales recargando la bandeja del miedo.

Este enfoque permite resolver el habitual pedido de técnicas cuantitativas, aún cuando encontremos que aporten poco y nada al entendimiento y resolución del problema. La razón de este pedido es que los clientes que lo enuncian, necesitan algo para presentar a sus superiores: se los mide. La mayor preocupación de estos interlocutores no está alineada a la calidad del diseño: está enfocada en su supervivencia en la organización.

En estos casos, la investigación cuantitativa debe ser presentada como condición necesaria para lograr una cuantificación que a nuestros clientes les resulte positiva. Esto es, reconocer las métricas que puedan mostrar con medidas crecientes a lo largo del proyecto.

Distingo en la investigación cuantitativa tres niveles:

• Validación (comprobar lo que “sabemos que sabemos”) es el proceso cualitativo más simple, menos riesgoso, y sobre el cual es más factible establecer métricas cuantitativas.
• Investigación (ir a buscar lo que “sabemos que no sabemos”) representa mayor incertidumbre y sólo es viable una vez que nuestro cliente ha podido entender el valor de UX en reducir riesgos, típicamente luego de la validación de supuestos que se presentaban originalmente como verdades.
• Exploración (ir a buscar lo que no sabemos que no sabemos) es el proceso cualitativo más alejado de la preocupación del cliente por su supervivencia en la organización; sólo es viable cuando nuestro cliente dispone de recursos, capital político, experiencia y compromiso.

Recién con herramientas sólidas para las conversaciones y la toma de decisiones, podemos abocarnos a diseñar una metodología.

Lo más importante que toda metodología busca lograr, es lograr en la escala del proyecto una relación sana cliente-proveedor. Sin metodología alguna, a medida que se suma gente de ambos lados, se producen conversaciones cruzadas, confusiones y problemas que llevan a la formación de dos bandos: “esos cretinos” y “esa manga de inútiles”.

Por eso, toda metodología plantea un solo interlocutor de cada lado,contando con autoridad, competencia técnica, entendimiento de Negocio y competencias de gestión.

Una base muy importante para las metodologías ágiles es la distinción de Valor vs. Desperdicio propia de la filosofía “Lean”. Valor es lo que el Cliente valora; desperdicio, es todo lo demás… aún cosas que consideramos condiciones necesarias para lograr Valor.

Identificar el desperdicio obliga a cuestionarse todas las actividades que se realizan. En el caso de la construcción de una vivienda, las paredes –que permiten proteger a los habitantes de la intemperie y preservar su privacidad– son claramente un Valor. Ahora bien, los andamios, por más que se consideren necesarios para la construcción de esas paredes, son en realidad desperdicio constructivo: los habitantes no convivirán con los andamios una vez inaugurado el edificio. Si los andamios fueran de oro, el presupuesto crecería en varios millones de dólares, sin que los clientes finales encuentren Valor en ello. Por eso, los andamios son modulares, reutilizables, y en muchos casos, se alquilan.

Otros tipos de desperdicio pueden ser más claros de identificar. Si en lugar de descargar los materiales en el punto donde se los necesita, se los descarga a 10 cuadras de distancia, será necesario tiempo y esfuerzo adicionales para desplazarlos a donde deberían haber sido descargados en primer lugar.

Identificar el desperdicio en software resulta mucho más difícil. Lean Software Development es una herramienta muy valiosa para identificar, reducir y eliminar en nuestros proyectos:

Desperdicios en el producto:

Son los más claros… y también los más tardíos en poder ser identificados. Resultan evidentes una vez que el proyecto ha salido a producción… y por ello, cuando ya no hay recursos para resolverlos. El proceso de investigación UX busca, en un entorno controlado, identificar estos desperdicios de manera económica, cuando todavía hay tiempo y recursos para mitigarlos:

• Defectos: bugs, cosas que no funcionan de acuerdo a la expectativa del usuario final, problemas de usabilidad.
• Funcionalidad no usada: típicamente, producto de falta de entendimiento de las necesidades y capacidades reales de los usuarios.

Desperdicios en el proceso:

Pueden ser identificados y resueltos durante el proceso mismo. Atenderlos reduce la posibilidad de manifestación de desperdicios en el producto. Requieren de competencias de gestión, responsabilidad del equipo, y manejo de expectativas del Cliente.

• Pase de manos: cuando una tarea pasa de una persona a otra, hay o bien una conversación necesaria entre esas personas, o información que se pierde en el proceso.
• Multitarea: el ser humano puede realizar una sola tarea de forma consciente; la “multitarea” resulta en realidad, intercalar fragmentos de dos o más tareas. Pasar de la tarea A a la tarea B, requiere de un esfuerzo mayor a cero para entender el contexto de la segunda tarea; esa penalización de aplica nuevamente al retomar la tarea A.
• Reaprendizaje: retomar una tarea o práctica al cabo de mucho tiempo, requiere de un esfuerzo para recuperar el contexto y capacidad operativa, que se puede evitar manteniendo continuidad.
• Esperas: ocurren cuando una persona no puede avanzar con sus tareas asignadas por no contar con decisiones o insumos de los que depende. Una forma de evitar estas situaciones es manejando un cronograma de “sprints” que impone cadencia al proyecto, y que debe involucrar al Cliente.
• Trabajo incompleto: todas las decisiones y ejecuciones no finalizadas, aumentan la deuda técnica al punto en que el día de mañana, el costo para saldarla puede resultar inviable. Suele ser producto de apuro y presión sobre el proyecto, falta de planificación y visión.
• Talento no utilizado: uno de los casos usuales es cuando el Cliente considera al Diseño como mera ejecución, desatendiendo la capacidad del equipo de ayudar al Negocio a tomar mejores decisiones. Requiere de gestión, autoridad, manejo de expectativas y compromisos. Impacta al proyecto de maneras no cuantificables (nadie puede medir contra lo que “podría haber sido”), y al equipo en quiebres de motivación.

Desde Kambrica desarrollamos, iteramos y proponemos un modelo que en primer lugar, reconoce el valor de los procesos de Facilitación e Investigación para reducir la complejidad de la toma de decisiones. Y revela que la ejecución de diseño, lejos de “resolver” (como suele ser la percepción del cliente), en realidad siempre abren nuevas preguntas que requieren de procesos adecuados para su resolución.

Nuestro modelo mínimo de sprint considera ciclos semanales, con un track de Gestión adelantado una semana al track de ejecución. En el momento de Planificación, se empalman los dos tracks, considerando además una instancia de seguimiento con Negocio a mediados de la semana de ejecución para reducir riesgos y desvíos.

Aplicando este modelo logramos coordinar todos los proyectos, sin importar su complejidad.

En resumen, integrar Experiencia de Usuario y metodologías ágiles requiere trabajar sobre varias dimensiones, de general a particular: desde el entendimiento de Diseño, Ingeniería y Gestión, hasta el diseño y aplicación de una metodología particular para encaminar los proyectos identificando y reduciendo los desperdicios, estableciendo y cumpliendo compromisos de manera responsable.

Créditos de la Presentación

• Framing hammer — Luigi Zanasi (CC BY-SA 2.0 ca)
• Iceberg in the Arctic with its underside exposed — AWeith (CC BY-SA 4.0)

Todas las demás imágenes y videos bajo Licencia CC0 (Libres para todo uso sin atribución requerida), de dominio público o producción propia.