Una vieja historia conocida, nuevos actores
Un equipo Scrum con el cual colaboré hace un par de años, estaba pasando por una situación: Habían terminado un nuevo producto (en este caso era un software para uno de sus clientes), habían construido todas las funcionalidades y características solicitadas “al pie de la letra, con puntos y comas” por este cliente, les daba retroalimentación, y en base a eso terminaron un producto… cuando llegó el usuario final, resulta que para la forma “real” en que él trabajaba y sus necesidades, este software no le ayudaba. No aportaba un beneficio mayor, un valor real, finalmente no utilizaba el nuevo, flamante (y costoso) programa. ¿Te suena conocida esta historia?
Se entregaron las nuevas características tal como las solicitó el cliente, así como en el tiempo y costo definido en el contrato. En este caso un punto importante es que el cliente y el usuario no eran la misma persona, quien pagó por el producto (el cliente) no era quien realzaba las operaciones del día a día, quien daba la cara al cliente, no era quien iba a usar el producto (usuario). El equipo puso todo el enfoque y empeño en entregar, esto es lo que se conoce como enfoque en “salidas” (outputs), es decir, cumplo al entregar en las condiciones estipuladas: tiempo, costo, las funcionalidades tal cual se solicitaron.
Una vieja historia conocida de terror contemporáneo, es La-Pesadilla de las pesadillas, es algo que tristemente aún continúa cobrando a los equipos horas y horas de trabajo / miles líneas de código / documentos infinitamente extensos… trabajo que, desde el punto de vista Lean, termina siendo un desperdicio.
El epitafio de este producto diría algo: “Aquí yace un producto construido impecablemente, que nadie compra” ☹
¿Hay algo más en qué debo de poner el enfoque?
¡Claro!, lo que buscamos es un impacto positivo, resolver el problema del usuario, hacerle la vida más fácil. Para poder llegar a generar un impacto, primeramente, debemos de enfocarnos en algo que se puede traducir como “resultados” (outcomes). Hay una definición de outcomes que en lo personal me gusta mucho, propuesta por su Joshua Seiden en su libro “Outcomes over Outputs: Why customer behavior is the key metric for business success” (Resultados sobre Salidas: Por qué el comportamiento de los usuarios es la métrica clave para el éxito del negocio), nos dice que:
“Un outcome (resultado) es un cambio en un comportamiento humano que conduce a un resultado de negocio.”
Esta definición me parece muy poderosa, porque nos transmite que un outcome no tiene que ver con solo “construir o entregar algo”, sino en un cambio en una conducta o comportamiento del usuario/cliente que conduce a un valor positivo para el negocio.
En el caso de este equipo Scrum que mencionaba al inicio de este artículo, ellos hicieron entrega de un producto, funcionaba perfectamente (no tenía errores), inclusivo era visualmente muy mono (se veía re-bonito, hasta tenía unas animaciones muy chéveres), y “lo más importante” es que lo entregaron en el tiempo y presupuesto acordado… suena como un producto perfecto, ¿no?... pero aún así, no producía ningún cambio en la forma en que el usuario final realizaba sus actividades porque sencillamente no le ayudaba en la realidad de su día a día, no facilitaba sus tareas, sus operaciones, no le hacía la vida más fácil.
Para asentar un poco el enfoque en outcomes (y finalmente en el impacto en la vida del usuario final), al leer el libro de Seiden me encontré con este modelo que me encantó y estaba muy emocionado por escribir sobre él, o como decimos acá en México: Se me quemaban las habas por compartirlo.
Este modelo y ejemplo que Seiden plantea en su libro, este se llama: Program Logic Model o Modelo lógico de programa (creado por W.K. Kellogg Foundation). Este modelo es muy simple:
El enfoque en los outcomes en vez de outputs no es nada nuevo, de hecho, es muy conocido. Sin embargo, el agregarle ese enfoque final en el impacto me pareció poderoso y creo que aporta muchísimo valor. Claro que en la realidad, en el día a día, en nuestros equipos y organizaciones buscamos ese impacto final con la entrega de un nuevo producto o servicio, pero al menos personalmente nunca lo había definido con una palabra concreta, impacto, por lo cual este modelo me pareció muy alineado con lo buscamos con puntos como “La meta del Producto” o Product Goal que define La Guía Scrum, o con el famosísimo “Porqué” (sí, así pegado y con acento) que menciona Simon Sinek en su libro “Comienza con el Porqué”, esa razón de ser que nos guía.
Así que, ya sin tanto rollo, el ejemplo para explicar este modelo es el siguiente:
Una fundación tiene como propósito ayudar a mejorar la calidad de vida de una pequeña comunidad que vive en una zona alejada y sin servicios básicos. La gente de esta comunidad dedica buena parte de su día en caminar hasta un río para acarrear agua.
En base a la observación, una hipótesis de la fundación es que, si la comunidad contara con un pozo de agua en el centro de su villa, no dedicarían tanto tiempo en acarrear agua desde el río, y este tiempo que se “ahorren” podrán dedicarlo a realizar otras actividades que les permitan mejorar su calidad de vida (tal vez aprender nuevos oficios, mejorar sus viviendas, cultivar más, o cosas como de ese estilo).
En este caso, construir un pozo para la comunidad es el entregable que la fundación pretende entregar, la salida (output). El resultado (outcome) que esta salida genera es que las personas toman agua de aquí y ya no van hasta el río todos los días. Esto cumple con la definición que nos comparte Seiden, porque hay un cambio positivo en el comportamiento de las personas que usan el pozo. El impacto que se busca, que las personas dediquen más tiempo a realizar otras actividades que mejoren en la calidad de vida de la comunidad, debe de observarse para determinar si se logra.
¿Cómo garantizar que se obtenga el impacto deseado?
Este es un tema que da para mucho, de esas charlas largas y apasionantes acompañadas de un buen café o mate (en lo personal prefiero un té verde).
Siempre le he batallado con esto: ¿Cómo garantizas que se obtenga el impacto deseado?, ya que en la universidad no cursé la materia o asignatura llamada “Ver el futuro en una bola de cristal” :D
Ya hablando en serio, hablar del impacto es hablar de complejidad, de cuestiones que no se pueden predecir (en la realidad existen infinitas variables que pueden influir en el impacto, y no siempre es posible identificar una correlación lineal o directa entre estas variables).
¿Cómo garantizar entonces el impacto? La verdad es que no es posible, ¿Entonces?
Aquí lo importante es abordarlo con un enfoque de experimentación y plantear este impacto como una hipótesis. Para ver si esta hipótesis es correcta, se pueden correr experimentos pequeños, controlados, baratos, que nos den retroalimentación sobre la factibilidad de los outputs y outcomes para el impacto buscado. En este caso de ejemplo, supongamos que es factible llevar camiones o pipas de agua que abastezcan a la comunidad durante un periodo de tiempo que se considerará como un muestreo, y durante este tiempo se puede observar los cambios en las conductas o comportamiento de las personas y una “muestra” del impacto, a fin de validar si la hipótesis es correcta, antes de avanzar más… pero este solo punto, como mencionaba, es tema charlas mucho más profundas, o al menos de otro artículo particular (de hecho lo voy a abordar en un video que está en proceso de edición, próximamente lo compartiré por aquí: Pinky promise).
El modelo de este ejemplo quedaría algo como:
¿Cómo te parece el modelo de este ejemplo?
Conclusión
Para cerrar, me gustaría mencionar nuevamente la definición de outcomes que nos propone Seiden: “Un outcome (resultado) es un cambio en un comportamiento humano que conduce a un resultado de negocio.”
El definir primeramente impacto que se espera en función a outcomes, es decir, en función del comportamiento de los clientes/usuarios, sirve como guía para ayudar a fomentar una cultura centrada en ellos, los clientes y usuarios, lo cual puede ayudar a que la organización obtenga también el impacto esperado: Valor de negocio.
P.D.
No olvidemos también a nuestro equipo, a las personas: Que construyan el producto o servicio en un ambiente de bienestar es, como se dice: un MUST, o sea que es imprescindible.
¿En qué se enfocan en tu equipo u organización actualmente? ¿Aún en outputs? ¿En outcomes, pero solo en esto? ¿O ya están centrados en los Impactos?
Leonel Zapien
Apasionado de la Agilidad: Consultor & Facilitador.
