Apasionado
de la Agilidad o Agilismo

Agile Coach,
Consultor

& Facilitador

"Estoy convencido de que la Agilidad o Agilismo es un camino y no un fin. Me encanta ayudar a los equipos a cocrear las mejores condiciones para abrazar la Agilidad Organizacional."

Próximos
Cursos


Ver más cursos
incompany

Cursos
In-company


Cualquiera de los cursos ofertados en el calendario, o bien, cursos específicos a la medida de tus necesidades. Podemos cocrear juntos una experiencia sublime de capacitación en un grupo privado, formado por personas de tu empresa.

Hey!, Más información sobre esto

Consultoría


La Agilidad o Agilismo es un camino y no un fin. Te acompaño en este viaje para cocrear las mejores condiciones en tu organización para abrazar la Agilidad Organizacional.

  • Facilitación
    Facilitación

    Facilitar es “hacerlo fácil”.
    Facilito sesiones para guiar a personas y equipos hacia un resultado predeterminado ¿Cómo?, a través prácticas, dinámicas y herramientas diversas de gamificación que fomenten las conversaciones poderosas y liberen el potencial de las personas.

  • Mentoría & Coaching
    Mentoría & Coaching

    Enfocada en cuestiones directas sobre temas específicos. Es una opción adecuada si tienen alguna consulta puntual y se encuentran en la exploración de alternativas.
    Una manera de ayudar a desarrollar nuevos conocimientos y habilidades específicos ¿Cómo?, a través de compartir experiencia y guía, a la vez que se pone en práctica lo aprendido.

  • Consultoría
    Consultoría

    Les acompaño en el viaje de evolución ágil de tu organización: Partir de un estado inicial, co-crear las mejores condiciones de manera iterativa que potencialicen su capacidad de adaptarse al cambio y abrazar la Agilidad.

Hey!, Más información sobre esto

Testimonios


Algunos testimonios de personas con quienes he tenido el gran gusto de colaborar profesionalmente a lo largo de este mágico camino de la Agilidad:

  • Leonel consiguió resultados de cambio sorprendentes en la empresa con la mentoría de SCRUM. Es un profesional muy enfocado para trabajar en el aprendizaje de cada colaborador de nuestra organización. Tiene excelentes conocimientos en el marco de SCRUM, y gracias a él hemos podido llevar a cabo la implementación de varios proyectos de forma exitosa.


    **Miguel Ángel Pedraza González**
Dirección de Transformación Digital e Innovación en (Fintech-Retail)
**(México)**

    Miguel Ángel Pedraza González
    Dirección de Transformación Digital e Innovación en (Fintech-Retail)
    (México)

  • Destaco la facilitación de nuestro trainer Leonel Zapien López, impecable.
    Me llevo la forma de explicar los conceptos y las dinámicas utilizadas que ayudan a entender los conceptos puestos en práctica.


    **Cristian Rodríguez**
Enterprise Agile Coach | SAFe Agilist | CSM | Transformación digital
**(España)**

    Cristian Rodríguez
    Enterprise Agile Coach | SAFe Agilist | CSM | Transformación digital
    (España)

  • Gran dominio del tema, excelentes visualizaciones, los ejercicios prácticos fueron de mucho aprendizaje, en conclusión Leonel Zapien Lopez felicidades por tu enorme capacidad de transmitir conocimientos.


    **Katheryn Hodgson**
Gestión Administrativa-Financiera en Organizaciones sin Fines de Lucro
**(Nicaragua)**

    Katheryn Hodgson
    Gestión Administrativa-Financiera en Organizaciones sin Fines de Lucro
    (Nicaragua)

  • Superó mis expectativas!! Me encantó y 100 de calificación a Leo.


    **Guillermina Marín Covarrubias**
Program Manager
**(México)**

    Guillermina Marín Covarrubias
    Program Manager
    (México)

  • Leonel comparte muchísimo más Valor del que esperé desde el momento que supe de su curso. Me parece que tiene un estilo bastante amigable, amable y atento para impartir el conocimiento.
    Busca siempre resolver cualquier duda posible y da tiempo suficiente y adicional para responder cada pregunta. Estaría dispuesto a tomar más cursos con él, sin duda, y lo recomiendo 100%


    **Leopoldo García**
Program Manager
**(México)**

    Leopoldo García
    Program Manager
    (México)

  • Como siempre Leonel Zapien Lopez dándonos una cátedra. Sencillamente magistral, muchísimas gracias por compartir con nosotros tus conocimientos y experiencias. Un abrazo gigante desde Venezuela hasta México.


    **Ileana Ramos Pereira**
PMP, PMI-ACP, Scrum Master, Product Owner. Consultoría de Negocios
**(Venezuela)**

    Ileana Ramos Pereira
    PMP, PMI-ACP, Scrum Master, Product Owner. Consultoría de Negocios
    (Venezuela)

  • Taller 100% recomendable, Leonel Zapien Lopez con clases muy entretenidas, imposible no mantenerse atento!


    **Leonardo Soto Cartes**
Director de Ciberseguridad
**(Chile)**

    Leonardo Soto Cartes
    Director de Ciberseguridad
    (Chile)

  • Me encantó el curso, mucha información entregada de una manera muy amena, dinámica y entretenida. Felicidades por estos skills educativos.


    **Fabiola Fajardo**
Clinical Neuro- Scientist | Life Science Consultant & Project Manager
**(México)**

    Fabiola Fajardo
    Clinical Neuro- Scientist | Life Science Consultant & Project Manager
    (México)

  • Una gran experiencia con el facilitador, con un alto grado de innovación y cocreacion, siempre nos mantuvo demasiado enfocados en los temas que se nos pasaban las sesiones rapidísimo por su gran manera de abordar los temas. Sabe liderar de manera excelente el curso, muy flexible al momento de dar respuesta a dudas, siempre con una gran amabilidad y establece de una manera muy entendible el contexto de los temas a fin de que todos podamos entenderlos.


    **Miguel Ángel López**
Gerente de Operaciones
**(México)**

    Miguel Ángel López
    Gerente de Operaciones
    (México)

  • Quiero expresar mi agradecimiento a Leonel Zapien Lopez, talentoso facilitador, por su experiencia y dedicación en la enseñanza de este poderoso enfoque ágil.


    **Noemí Zalazar**
Desarrollo Full Stack con enfoque en Frontend | Metodologías Ágiles | PM
**(Argentina)**

    Noemí Zalazar
    Desarrollo Full Stack con enfoque en Frontend | Metodologías Ágiles | PM
    (Argentina)

  • “Algo que cabe destacar entre todo lo positivo, es su método y el expertise con el cual se maneja en conjunto con la pasión y dinamismo que emplea al explicar los temas, por ende, puedo confirmar y reafirmar que ha sido una de las mejores experiencias de aprendizaje profesional que he tenido.”


    **Sascha Alexander Pedersbeck Franco**
Scrum Master | PM
**(México)**

    Sascha Alexander Pedersbeck Franco
    Scrum Master | PM
    (México)

  • ¡Sos un crack Leonel!
    Como dice la frase “Ser un Facilitador es como ser un artista, tienes los flujos de procesos de diferentes colores combinados en una obra de arte” ~ Greg Cimmarrusti


    **Sheila Santos**
Scrum Master| Coach Ontológico| Project Manager
**(Argentina)**

    Sheila Santos
    Scrum Master| Coach Ontológico| Project Manager
    (Argentina)

Visita mi
Blog


Innovación & MVP - Diseñar y probar hipótesis de negocio
MVP, Product Management, Innovación
Innovación & MVP - Diseñar y probar hipótesis de negocio

“No cometas el error de ejecutar ideas de negocio sin evidencia: Prueba tus ideas, sin importar qué tan bien luzcan en teoría” – David J. Bland & Alex Osterwalder. # Hipótesis de negocio ¿Tienes una idea de un nuevo producto o servicio?, ¿Una nueva funcionalidad que piensan agregar para tu usuario o cliente?, para pasar de una idea de negocio a un elemento validado, se debe de probar de manera rápida y lo más barato posible (en el artículo pasado hablamos sobre el **Producto Mínimo Viable o MVP**, Minimum Viable Product en inglés, puedes leer el artículo completo (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí)). Pues bien, está chévere esta idea de que un MVP nos invita a validar ideas de negocio con experimentos antes de ir a mayor escala. Pero ¿Por dónde empezar si quiero hacer un experimento para probar una idea?, ¿Por dónde inicio? Lo primero que necesitamos asentar es que una **idea de negocio** es en realidad una **hipótesis** (ya sé que esto suena muy del ámbito científico, pero en realidad así es). Hasta que se valide obteniendo un resultado (se cumple y por lo tanto es correcta, o no se cumple), solo entonces dejará de ser una hipótesis. “El objetivo de un MVP es probar las hipótesis fundamentales del negocio, es sólo un primer paso en un proceso de aprendizaje.” – Eric Ries (The Lean Startup) # Probar ideas de negocio: Un proceso iterativo El ciclo Diseño-Prueba es un proceso iterativo, creado por David Bland & Alex Osterwalder, tiene dos grandes áreas: Diseño & Prueba, veamos cada una a detalle: (image: design-test-innovacion-strategyzer-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) **Diseño:** Es la actividad de llevar ideas vagas o dispersas, a proposiciones de valor, que después puedan concretarse como modelos de negocio. **Prueba:** Necesitamos descomponer una idea de negocio en hipótesis pequeñas y fáciles de validar mediante experimentos que proporcionen evidencia que ayuden a decidir los siguientes pasos. # Diseño En este primer paso el objetivo es generar la mayor cantidad de opciones como sea posible (debemos evitar enamorarnos de nuestra primera idea, no es personal, solo son negocios), basándose en la intuición, observación o en lo que se conozca sobre los clientes. (image: design-test-innovacion-strategyzer-01-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) Las ideas locas, irreverentes, aquellas que retan el Status Quo, son más que bienvenidas (de hecho, eso es lo que buscamos). En este punto, no es el momento de empezar a desmenuzar el modelo de negocio y cuestionar la validez o potencial éxito en el mercado de una idea. No aún. **Queremos que el equipo diseñe como si tuviera razón**, ¿Tenemos sobre la mesa alguna idea de negocio innovadora? **Pregunta para llevar: ** ¿El equipo está “empujando” los límites?, o ¿Están jugando a lo seguro y manteniéndose cerca de lo que la empresa hace actualmente? # Prueba Una vez estemos satisfechos con lo realizado en la etapa de diseño, es hora de pasar a las pruebas. (image: design-test-innovacion-strategyzer-02-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) El primer paso en el ciclo de prueba es definir y priorizar las hipótesis de negocio. Si la hipótesis es muy grande, la dividimos pequeñas partes comprobables. Aquí lo esencial es la palabra “comprobable”, para esto debemos cocrear (de verdad, es increíble el poder de la crear de manera colaborativa), seleccionar y ejecutar experimentos adecuados que nos proporcionen información que respalde y nos ayuden a validar (o desechar) nuestras hipótesis. En pocas palabras, necesitamos **evidencia**. # Tarjeta de Prueba o Test Card Aquí te comparto una herramienta muy útil, desarrollada por Strategyzer, que nos ayuda a definir un experimento para probar una idea: (link: https://www.strategyzer.com/library/validate-your-ideas-with-the-test-card text: La Tarjeta de Prueba (Test Card)). Aquí veremos brevemente cómo llenar esta tarjeta: (image: test-card-strategyzer-leonel-zapien-lopez-ideas-agilidad-business-hypholesis-s.webp) 1. **Hipótesis:** Define la idea de negocio que se cree que es verdadera. **Ejemplo: **“Creemos que las personas están interesadas en un curso en línea sobre bordar manteles navideños con punto de cruz.” 2. **Prueba:** ¿Qué experimento (o experimentos) ejecutarás para determinar obtener información que permita validar si hipótesis es verdadera o falsa? **Ejemplo: **“Para verificar esto, nosotros agregaremos un breve video sobre el curso y un botón de en nuestro sitio web.” 3. **Métrica:** ¿Qué vamos a medir para validar la hipótesis?, la idea es que sea una medida específica, objetiva, no ambigua, binaria (cumple o no cumple) y reproducible. **Ejemplo:** “Y lo mediremos por el número de personas que ingresan a nuestro sitio web y hacen clic en el botón de .” 4. **Criterio: **Definir el resultado esperado respondiendo a la pregunta ¿Cómo es el escenario ideal que en nuestro contexto nos dice que la hipótesis ha sido exitosa? **Ejemplo: **“Y sabremos que tenemos éxito si se registran al menos 1,000 ‘compradores de pre-venta’ en la primera semana.” Este último punto es crítico ya que ayuda a responder la pregunta: ¿Qué necesita ser cierto para que esta idea de trabajo funcione? En este ejemplo, la definición de éxito que esta empresa de cursos en línea espera (de acuerdo con su contexto especifico, como costos fijos, retorno de inversión esperado, cobertura de mercado actual, etcétera), son 1,000 “compradores” registrados, pero ¿En cuánto tiempo?, para ellos ese bloque de tiempo es en la primera semana de correr el experimento. ¿Lo más importante?, el producto en este ejemplo, el curso en línea no ha sido creado aún, por lo que probar esta hipótesis es relativamente muy barato (y rápido). # Aprender El último paso es aprender de los experimentos que realizamos. ¿La evidencia recabada apoya o refuta nuestras suposiciones?, Eso que acabamos de obtener es aprendizaje, de hecho, es lo que Eric Ries (el creador del **Método Lean Startup**, puedes leer el artículo que hice sobre este tema (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí)) llamó **Aprendizaje Validado**, pues se basa en evidencia. ¿Este aprendizaje validado nos indica que debemos de continuar por este mismo rumbo, o pivotar y explorar un nuevo camino? Para validar el aprendizaje, aquí comparto, al igual que en el punto anterior, una herramienta propuesta por Strategyzer: (link: https://www.strategyzer.com/library/capture-customer-insights-and-actions-with-the-learning-card text: La tarjeta de Aprendizaje o Learning Card). Hemos realizado un experimento para tratar de validar una hipótesis de negocio, debemos de rescatar e identificar el aprendizaje obtenido y aplicarlo lo más pronto posible, pues el aprendizaje tiene una “fecha de caducidad”. ¿A qué nos referimos con aplicar el aprendizaje obtenido?, a aplicarlo en la toma de decisiones informada, identificar los siguientes pasos: ¿La hipótesis de negocio era correcta, y debemos continuar por este camino?, o ¿Debemos de cambiar el rumbo, partiendo de una nueva hipótesis? (esto último, se conoce como hacer un “**pivote**”). Retomando el ejemplo que revisamos en la Tarjeta de Prueba (Test Card), continuamos con el ejemplo para llenar ahora la Tarjeta de Aprendizaje: (image: learning-card-leonel-zapien-lopez-ideas-agilidad-business-hypholesis-s.webp) 1. **Hipótesis: **Define la idea de negocio que se creía verdadera. **Ejemplo: **“Creíamos que las personas están interesadas en un curso en línea sobre bordar manteles navideños con punto de cruz.” 2. **Observación: **¿Qué pudimos observar después de realizar el experimento? **Ejemplo: **“Observamos que solo un 1.2% de los clientes potenciales esperados hicieron clic en nuestro botón de en nuestro sitio web.” 3. **Aprendizajes e ideas clave:** El aprendizaje validado que se ha obtenido de la observación. **Ejemplo:** “Dado que esperábamos 1,000 clics de compra en pre-venta durante la 1ra semana y solo obtuvimos 12 clics (1.2%), este curso en línea no genera el interés esperado.” 4. **Decisiones y acciones:** Ahora que se ha visto si la hipótesis de negocio era válida o no, determinar los siguientes pasos que se realizarán a partir de este punto. **Ejemplo:** “No dedicaremos más recursos a esta hipótesis. Replantearemos nuestra idea de negocio y haremos un pivote a una nueva hipótesis que está por definirse.” En este caso de ejemplo, la hipótesis de negocio no era válida, ¿Lo más importante?, el producto en este ejemplo, el curso en línea sobre bordar manteles navideños con punto de cruz, nunca fue creado: No se dedicaron semanas o meses de trabajo a un producto que se creía que se vendería como pan caliente, pero que el experimento demostró que no había interés. Probar esta hipótesis fue relativamente muy barato y rápido. ¿Y cómo procedemos una vez se confirma el resultado de una hipótesis?, se pueden hacer varias 3 cosas: 1.** Perseverar: **Quiere decir que vamos por buen camino, y debemos de continuar por este rumbo. No es el caso en este supuesto, solo sucedería si la hipótesis resultara válida. 2. **Pivotar: **Hacer un cambio de rumbo, lo que Eric Ries en su libro “The Lean Startup” llama un “Pivote”, comenzar a explorar otros caminos y formular nuevas hipótesis. 3. **Descartar: **Tal vez, después de explorar varias hipótesis, negocio decide no continuar explorando este camino (y probablemente ningún otro similar o alineado con este camino). Continuando con este ejemplo, ¿Qué tal si a la gente no le interesa aprender a bordar manteles navideños, pero se acerca el Día de Star Wars, y bordar manteles temáticos de Star Wars es algo que las personas están buscando con singular alegría?, uno nunca sabe. ¿Cómo lo sabremos?, formulando una nueva hipótesis. (image: hipotesis-de-negocio-star-wars-copy.webp) # ¿Qué sigue después? En el centro del ciclo Diseño-Prueba se encuentra “Decidir”, se debe de decidir sobre este modelo de negocio que el equipo está probando. El objetivo final es comprobar **si el modelo de negocio es viable**, los equipos de innovación deben evaluar en este punto y reflexionar sobre su progreso hacia la búsqueda de un modelo de negocio rentable que funcione. Al evaluar la solidez de la evidencia que respalda cada componente básico del modelo de negocio, los equipos pueden identificar si aún hay incertidumbre y existen componentes que aún deben probarse, ¿Deben realizarse nuevos experimentos? Cuando se aprenden nuevas lecciones, se puede actualizar el modelo de negocio, identificar nuevas hipótesis y ejecutar el siguiente conjunto de experimentos. Esta es la razón por la que los equipos que pueden recorrer rápidamente el ciclo descubren más rápido si su idea de negocio es viable. Hasta aquí, ya tenemos información de la hipótesis de negocio mediante los experimentos realizados, ahora, muy recientemente en este último par de párrafos hemos comenzado a hablar de un “Modelo de negocio”. Para esto, el equipo de Strategyzer han creado también el (link: https://www.strategyzer.com/library/the-business-model-canvas text: Business Model Canvas, o Lienzo de Modelo de negocio), el cuál es el siguiente paso para ayudar al equipo de innovación a determinar la validez de su modelo. Aquí te presento el Lienzo de Modelo de Negocio, pero creo que este artículo ya es algo extenso, así que en un próximo artículo conversaremos específicamente sobre este Canvas. Por lo pronto, hemos visto cómo probar y validar ideas de negocio. (image: business-model-canvas-modelo-de-negocio-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) # Conclusiones La **apertura para experimentar** es esencial para desarrollar una **cultura de innovación** en cualquier organización. Las herramientas que hemos visto el día de hoy no son solo un par de tarjetas para prueba y aprendizaje, o un canvas con un modelo de negocio, son en realidad recordatorios de conversaciones enriquecedoras y poderosas que deben de suceder. Una tarjeta o un canvas como tal no resolverán ningún problema ni nos llevará al valle dorado de la innovación. Debemos fomentar los espacios para los individuos y sus interacciones, como dice el **Manifiesto Ágil** (puedes leer el artículo que escribí sobre el Manifiesto Ágil (link: https://leonelzapien.com/blog/23-aniversario-n-manifiesto-agil text: aquí)). Así mismo, la experimentación y la innovación son unos músculos que deben de ejercitarse, es posible que a tu equipo le tome algunos ciclos el comenzar a entrar en calor, a agarrar ritmo, y a perder el miedo a experimentar (y para esto último se requiere un adecuado **liderazgo** y sólidos cimientos de **Seguridad Psicológica** en tu organización y equipo). Lo importante de la experimentación es obtener aprendizaje validado, con esto, el ciclo Diseño-Prueba se ha completado, de manera rápida y lo más barata posible. En este ejemplo, no fue viable continuar con el producto, así que el ciclo vuelve a iniciar, esta vez, con una nueva hipótesis de negocio. ¡Nunca dejemos de experimentar y aprender! **¿Cómo validas tus ideas de negocio?** ## Nota final #01 Las herramientas sobre las cuales hemos conversado hoy, Tarjeta de Prueba, Tarjeta de Aprendizaje y el Canvas de Modelo de Negocio, los puedes descargar en su versión original del sitio de (link: https://www.strategyzer.com/ text: Strategyzer), o en su defecto, los puedes descargar en una versión traducida a español, aquí en mi sitio web en la sección de (link: https://leonelzapien.com/recursos text: Recursos para descargar). ## Nota final #02 Existen varios canvas o lienzos que apoyan para crear modelos de negocio, hace unos meses hablé sobre el **Tablero de la Visión del Producto o Product Vision Board,** creado por Roman Pichler, escritor y todo un master Jedi en Agile & Product Management. Este canvas es muy útil para cocrear una visión compartida del producto (lo que se conoce como “envisioning”), y puede de igual manera apoyar como siguiente paso, ya que es similar al Business Canvas Model en algunos aspectos. Si quieres leer sobre el Tablero de la Visión del Producto, puedes leer el artículo que escribí sobre el tema (link: https://leonelzapien.com/blog/como-iniciamos-el-tablero-de-vision-del-producto text: aquí). ## Nota final #03 De verdad que existe el “**Día de Star Wars**”, millones de fans a lo largo y ancho de toda la galaxia lo celebramos el día 4 de mayo. ¿Por qué el 4 de mayo?, por el juego de palabras de la frase: “Que La Fuerza te acompañe”. En inglés se dice “May the Force be with you”, lo cual es un juego de palabas y cuando se dice en voz alta casi-casi como “May the Fourth be with you”… o sea “Que el 4 de mayo te acompañe”, y de ahí derivó que cada 4 de mayo se celebre el Día de Star Wars (Sí, debo de reconocer que nos buscamos cualquier pretexto para ese tener un día para usar sables láser y ponernos el casco de Darth Vader). **Referencias:** • Testing Business Ideas. David J. Bland & Alex Osterwalder. • Business Model Generation. Alex Osterwalder & Yves Pigneur. • El método Lean Startup: Cómo crear empresas de éxito utilizando la innovación continua. Eric Ries.

2 de junio de 2024
El Método Lean Startup & Producto Mínimo Viable (MVP)
Product Management, MVP, Innovación
El Método Lean Startup & Producto Mínimo Viable (MVP)

“Si estamos creando algo que nadie quiere, no importa si lo hacemos en tiempo y dentro del presupuesto” – Eric Ries El creador del método Lean Startup, Eric Ries, menciona que “demasiados planes de negocio parecen diseñados para planificar cómo lanzar un cohete: Prescriben los pasos que hay que dar y los resultados esperables con un gran nivel de detalle en cada paso, lo establecen todo como si cada minúsculo error en las asunciones o suposiciones pudiera llevar a un resultado catastrófico.” Eric Ries lo deja muy en claro: No podemos prever todos los posibles pasos (por más análisis de Fortalezas y Debilidades, de riesgos, estimaciones, simulaciones, y una larga lista de etcéteras), no podemos preparar cada detalle, nunca podremos concebir todos los posibles escenarios. Es por esto que Eric Ries, propone: **El Método Lean Startup**, que se basa en una premisa simple pero fundamental: En lugar de hacer planes complejos basados en muchas suposiciones, se pueden hacer ajustes constantes mediante un ciclo de retroalimentación llamado **Crear-Medir-Aprender**. (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-01.webp) En el artículo de hoy, hablaremos sobre Lean Startup, el ciclo Crear-Medir-Aprender, y sobre el poderoso enfoque del **Producto Mínimo Viable** (**MVP**, por sus siglas en inglés, Minimum Viable Product). # El caso de IMVU: Un error garrafal que llevó a la gran epifanía de Eric Ries IMVU, una gran empresa dedicada al desarrollo de software, decidió entrar en el mercado de mensajería instantánea. Era el año 2004, y este mercado en aquel tiempo tenía centenares de millones de usuarios a nivel mundial. Empresas como AOL (America On Line), Microsoft y Yahoo! dominaban el mercado. (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-02.webp) IMVU llega con una nueva idea: Mundos y juegos virtuales a través de avatares 3D personalizables, que pueden agregarse a las aplicaciones de mensajería instantánea ya existentes. Si el mercado de mensajería instantánea tenía cientos de millones de usuarios, entrar con esta propuesta que complementaba a las aplicaciones de mensajería, sonaba como un gran éxito. El equipo de IMVU, liderados en aquel tiempo por Eric Ries, estuvo más de 6 meses trabajando intensamente para desarrollar este producto, haciendo pruebas, discutiendo qué elementos o funcionalidades agregar y cuáles remover, poniendo muchísimo esfuerzo en la calidad, trabajando durante meses, jornadas hasta altas horas de la noche y fines de semana. Finalmente llegó el gran día del lanzamiento. Eric Ries menciona al respecto lo siguiente: **“Y entonces, ¡no pasó nada! Resultó que nadie probó nuestro producto”** **“Nuestra propuesta de valor estaba tan desencaminada de lo que los clientes querían, que ni siquiera lo probaban**, y, por lo tanto, no llegaban a descubrir lo malas que habían sido nuestras elecciones sobre el diseño. Los consumidores no descargaban nuestro producto.” El equipo de IMVU optó por hacer mejoras al producto, introducir nuevos cambios, uno que otro cliente llegaba a descargar su producto (Eric Ries reconoce que al inicio eran principalmente amigos y familiares de ellos mismos), y a pesar de tantas mejoras y retrabajo, pronto se quedaron sin amigos que quisieran probar su producto, y con unos ingresos mensuales de poco más de $300 dólares al mes. **“Estábamos mejorando el producto día a día, pero el comportamiento de los consumidores no cambiaba: todavía no querían probarlo.”** # Momento de hacer las cosas de manera diferente Para que el equipo de IMVU intentara hacer las cosas de manera distinta a partir de este punto, influyeron fuertemente dos factores: Un poco tuvo que ver la frustración de estar trabajando en un producto que nadie compraba, y un poco más tuvo que ver que se estuvieran quedando sin dinero para continuar operaciones. Hay un dicho: “La desesperación es la madre de la inventiva”, así que en este punto Eric Ries y todos en IMVU estaba bastante desesperados. ¿Qué hicieron ahora? **Comenzaron a hablar con los clientes** (verdaderas conversaciones, de esas que son cara a cara). Llevaban a clientes a sus oficinas, los entrevistaban, les mostraban pruebas de su producto, hacían ajustes en base a sus comentarios, y después volvían a mostrarles más pruebas. El equipo de IMVU tenía una idea en mente de su producto: Un avatar 3D que se puede personalizar, que se agrega como complemento a la aplicación de mensajería instantánea de preferencia del usuario, se enamora del producto, después invita a todos sus amigos a usarlo, y se vuelve viral. No suena nada mal. La cuestión es que después de docenas de entrevistas y pruebas con clientes reales, directo en sus oficinas, se dieron cuenta que su concepto de “mensajería instantánea complementaria” estaba destinado al fracaso desde un inicio, a nadie le interesaba eso. # Ok, y entonces ¿ahora qué? Era momento de reconocer que el trabajo de más de 8 meses no le interesaba a nadie. Trabajo tirado a la basura. ¿Cuál fue la razón de que el equipo de IMVU durara tanto para construir su producto?, habían estado trabajando en hacer un producto de alta calidad, que fuera compatible para todas las redes sociales o aplicaciones de mensajería de aquella época… y cuando hicieron todo esto, se dieron cuenta que a nadie le interesaba. # Es hora de hacer redirigir el rumbo: Pivotar (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-03.webp) Eric Ries menciona que Pivotar es detenerse, hacer una pausa y evaluar si merece la pena seguir por este camino. En este caso de IMVU, al reconocer finalmente que la respuesta de los clientes no era positiva, la decisión fue abandonar la estrategia inicial, **tomar un nuevo camino** lanzando un nuevo producto (hacer un pivote), y validar lo más pronto posible su nueva propuesta, directamente con los clientes. El objetivo de estas conversaciones directas y (ahora más frecuentes) que querían tener con los clientes era ayudarles a **identificar conforme iban construyendo su producto**, qué funcionalidades les gustaban a los clientes (aportan valor), y cuáles no (lo cual se considera como un desperdicio o despilfarro). La idea es obtener esta retroalimentación lo más pronto posible y no ya que el producto está totalmente terminado, 8 meses después, y descubrir que fueron 8 meses de trabajo tirado a la basura. No se trataba de adivinar lo que los clientes querían, ni de decirles lo que deberían de querer, sino de entenderlos, ver cómo utilizaban la propuesta de producto, y en base a la retroalimentación obtenida directamente de su experiencia con el producto, lo que Eric Ries llamó **Aprendizaje Validado**, ahora sí, mejorar el producto. “Cuando pivotamos a partir de la estrategia inicial (después de escuchar a los clientes), todo empezó a cambiar […] no porque estuviéramos trabajando más duro, sino porque lo hacíamos de una forma más inteligente, **a partir de escuchar las necesidades reales de nuestros clientes.**” # Ciclo Crear-Medir-Aprender Lo que el equipo de IMVU comenzó a hacer a partir de su experiencia anterior, fue plantearse una **hipótesis de negocio:** (sí, ya sé que esto de "hipótesis" suena muy del ámbito científico, pero en realidad así es, ya que es algo que creemos pero hasta que no lo validemos, no sabremos si es cierto o no). La hipótesis en este ejemplo era: Creemos que los jóvenes están interesados en un avatar 3D para sus aplicaciones de mensajería instantánea. Basados en esta hipótesis, en vez de construir durante 8 meses un producto que fuera compatible para todas las aplicaciones de mensajería, y que tuviera todas las funcionalidades, determinaron **construir un experimento que les permitiera validar su hipótesis lo más pronto posible.** (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-04.webp) **Crear **un producto que no fuera malo en cuestiones de calidad, pero no algo muy robusto ni sofisticado, solo las funcionalidades básicas y que pudiera utilizarse, por ejemplo, en vez de que fuera compatible con todas las aplicaciones de mensajería, elegir una sola, la de mayor uso (de esta manera, se requeriría relativamente muy poco tiempo en construirlo). Esta primera versión del producto es lo que se conoce como **Producto Mínimo Viable** (**MVP** por sus siglas en inglés, Minimum Viable Product), un producto con las mínimas funcionalidades que requerimos, solo las necesarias para probar si a la gente le aporta valor o no. Obtener información es el siguiente paso, a fin de poder **medir**… ¿Cómo medimos?, cara a cara con el cliente: Observándolo con nuestro producto o servicio, ¿Qué funcionalidades o características utiliza y cuáles no?, ¿Es fácil e intuitivo que lo utilice o tenemos que explicarle cómo hacerlo?, ¿Cuáles son sus comentarios después de utilizar nuestro producto?, ¿Le gusta?, ¿Realmente resuelve su necesidad o le hace la vida más fácil?, ¿Descargan nuestra versión del producto?, ¿La recomiendan? La idea es obtener información relevante, **métricas accionables** que nos ayuden a determinar cómo vamos. **Aprender **es el último paso de este ciclo. En base a la información recabada, ¿Cómo vamos?, ¿Cuál es el aprendizaje validado después de correr este pequeño experimento?, aquí la cuestión fundamental es: La hipótesis de negocio que habíamos considerado de manera inicial, ¿se cumple?, si la respuesta es positiva, podemos continuar por este rumbo con un producto o servicio que sabemos que tiene aceptación de parte de los clientes, tal vez agregando o removiendo algunas funcionalidades o características, haciendo algunos ajustes. Por otro lado, tal vez la respuesta es negativa y a nadie le interesa este producto o servicio, si es el caso, se debe de evaluar si es necesario hacer un **pivote** y ajustar el rumbo: **Plantear una nueva hipótesis de negocio y volver a correr el ciclo Crear-Medir-Aprender.** # El Método Lean Startup Así nace el método Lean Startup, creado por Eric Ries. Pero a todo esto, **¿Qué es el Método Lean Startup? La aplicación del pensamiento Lean (reducir el desperdicio o despilfarro) al proceso de Innovación.** (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-05.webp) En el método Lean Startup, un experimento es más que una simple investigación teórica; también es un primer producto. Un **Producto Mínimo Viable o MVP**, que ayude a empezar con el proceso de aprendizaje lo más pronto posible. El MVP no es necesariamente el producto más pequeño que se pueda imaginar; es la forma más rápida de entrar en el ciclo de retroalimentación **Crear-Medir-Aprender** con el mínimo esfuerzo (y lo más barato posible). El objetivo de un MVP es probar las hipótesis fundamentales del negocio, es sólo un primer paso en un proceso de aprendizaje. A lo largo de este proceso, tras muchas iteraciones, se puede descubrir que algún elemento del producto o estrategia es erróneo y decidir que ha llegado el momento de cambiar, un pivote, a un método diferente para alcanzar la visión. # ¿Y es factible construir ese MVP? Ok, esa idea de MVP suena bien... pero ¿Ya existe la tecnología de Star Trek para teletransportar a una persona, o hacer maleable el adamantium?, aquí la palabra clave es si este MVP es **factible **de construirse. De acuerdo con **Paulo Caroli**, famoso escritor y desarrollador de **Lean Inception **(sí, lo sé. Parece que todos se han puesto de acuerdo para agregar la palabra “Lean” como prefijo a todo lo nuevo), el error más común en la creación de un MVP es el pensamiento unilateral: Pensar solo en el desafío tecnológico, o solo en lo que le encantaría al usuario, o simplemente en lo que valida el negocio. (image: leonel-zapien-lopez-ideas-agilidad-paulo-caroli-lean-inception-mvp-producto-minimo-viable-guadalajara-mexico-06.webp) Un MVP adecuado, de acuerdo con Paulo Caroli, se encuentra justo en la intersección de: 1. Lo que es valioso para el usuario. 2. Es utilizable. 3. Es técnica y económicamente factible construirlo. (image: leonel-zapien-lopez-ideas-agilidad-paulo-caroli-lean-inception-mvp-producto-minimo-viable-guadalajara-mexico-05.webp) # Conclusiones Es imposible predecir cómo responderá un cliente a un producto o servicio que se lance al mercado. La mejor manera de entonces de actuar es escucharlo directamente, cómo responde y cuáles son sus necesidades reales. Para esto, la mejor aproximación es partir de experimentos, un producto mínimamente viable que nos ayude a validar una hipótesis de negocio de manera rápida y barata, antes de proceder a construir un producto o servicio a mayor escala y detalle. Para esto nos podemos apoyar en el ciclo Crear-Medir-Aprender, y cada vez que completemos una vuelta a este ciclo, determinar la forma en que habremos de actuar en base al **aprendizaje validado** que hemos obtenido. Eric Ries menciona que “la cantidad de tiempo que una empresa puede mantenerse como líder del mercado para explotar sus primeras innovaciones se está reduciendo y esto crea un imperativo. Incluso para las empresas más afianzadas: invertir en innovación”, y ¿Cómo podemos hacer esto?, creando algo “barato”, midiendo con los clientes o usuarios finales, aprendiendo, determinar si es necesario ajustar, y volver a iniciar. Añadiría un elemento más a lo anterior: Aprender divirtiéndonos durante el proceso, disfrutar el viaje por el ciclo Crear-Medir-Aprender, si hacemos lo que hacemos con pasión, la experiencia (además de enriquecedora), será totalmente memorable. **¿Habías escuchado hablar antes del Método Lean Startup?, ¿Cómo te ha ido experimentando con MVPs y obteniendo aprendizaje validado de tus productos o servicios?** ## Referencia: • El método Lean Startup: Cómo crear empresas de éxito utilizando la innovación continua. Eric Ries. • Lean inception: Creando conversaciones hacia un producto exitoso. Paulo Caroli.

6 de mayo de 2024
Objetivos y Resultados Clave (OKRs) para crear enfoque y alineación
OKRs
Objetivos y Resultados Clave (OKRs) para crear enfoque y alineación

OKR es un acrónimo en inglés que significa Objetivos y Resultados Clave (Objectives and Key Results), y se trata de un marco de trabajo de pensamiento crítico para el establecimiento de objetivos a través de resultados específicos y medibles. Hay una definición de OKRs que personalmente me gusta mucho, de los autores Paul R. Niven & Ben Lamorte: “Los OKR son un marco de pensamiento crítico y una disciplina continua que busca asegurar que los empleados trabajen juntos, centrando sus esfuerzos en hacer contribuciones mensurables que impulsen a la empresa hacia adelante.” # Introducción y (solo realmente) un poco de Historia Los OKR son ampliamente utilizados en el mundo ya que ayudan a las organizaciones a alinear objetivos y garantizar que todos estén trabajando colaborativamente en aquellos objetivos que realmente importan. De ahí parte todo: “Medir lo que importa”, es decir, métricas accionables, alineadas con los objetivos estratégicos de la compañía, y que nos indiquen paso a paso cómo vamos. Sin que esto sea una clase de historia, pero sí de forma general y a manera de contexto, te platico que los OKR fueron creados por Andy Grove cuando era CEO de Intel a finales de la década de 1980 y durante la de 1990. Esta forma de trabajar y alinear a Intel fue tan revolucionaria, que se extendió rápidamente por todo Silicon Valley, a empresas como Google y Netflix, y continúa creciendo al resto del mundo. Uno de los principales discípulos de Andy Grove, John Doerr, presentó los OKR en 1999 a los creadores de Google y ayudó a introducirlos en su compañía, publicó en 2017 el libro “**Mide lo que importa**” (Measure what matters), y a partir de ahí, la adopción de este marco ha crecido exponencialmente. (image: leonel-zapien-lopez-ideas-agilidad-andy-grove-john-doerr-okrs-mesure-what-matters.webp) ¡Ya!, es toda la historia que voy a contar, lo prometo. Pasemos mejor directo a tema sobre qué son los OKRs y por qué son tan poderosos. # Objetivos y Resultados Clave, vamos parte por parte ### Objetivo (O): Un objetivo es una declaración concisa que describe una meta cualitativa, diseñada para impulsar a la organización hacia la dirección deseada. Responde a la pregunta: "¿Qué queremos hacer?" Un objetivo bien redactado tiene un plazo determinado (factible en un trimestre) y debe inspirar y capturar la imaginación compartida de tu equipo. ### Resultados Clave (KR): Un resultado clave es un elemento cuantitativo que mide el alcance de un objetivo determinado. Si el objetivo responde a la pregunta “¿Qué queremos hacer?”, un resultado clave responde a la pregunta: “¿Cómo sabremos si hemos alcanzado nuestros objetivos?”. “El reto (y el valor real) de un resultado clave es el ayudarnos a definir maneras cuantificables para asentar, o para remover la ambigüedad e intangible de un objetivo. Por medio de los resultados clave, no es subjetivo o ambiguo si hemos alcanzado un objetivo o no, se vuelve algo medible y, por lo tanto, binario: Se cumplió o no se cumplió. (image: leonel-zapien-lopez-ideas-agilidad-okrs-consultor-cursos-agilismo-guadalajara-mexico.webp) # Vamos con un ejemplo: A manera de definir un primer ejemplo para asentar las características de los Objetivos y los Resultados Clave, imaginemos que queremos lanzar un nuevo y flamante sitio web para nuestra compañía. Bajo este contexto, uno de nuestros **objetivos** para este trimestre puede ser: “Diseñar un sitio web atractivo que llame a la gente a visitarnos como clientes potenciales”. El objetivo es conciso (sólo quince palabras), y su alcance es totalmente cualitativo (un sitio web atractivo, que llama a la gente). El objetivo no contiene números, eso corresponde a los resultados clave. Al definir un límite de tiempo (durante este trimestre) estamos confiamos en que podemos crear un diseño inspirador y que involucre nuestra creatividad en la producción de un sitio que la gente encuentre útil y estéticamente atractivo). Pero ahora, ¿Cómo sabremos si avanzamos en la dirección correcta para el logro de este objetivo que tiene adjetivos como “atractivo”, u oraciones como “que llame a la gente a visitarnos” ?, aquí es donde entran los resultados clave, y donde podemos encontrarnos con algunos problemas, ya que no hay una manera de traducir “un sitio web atractivo” a números, por lo cual se debe de “traducir” o definir en base al contexto específico de la organización. Basado en lo anterior, algunos posibles **resultados clave** para este ejemplo podrían ser: 1. Incrementar en 40% el número de visitas a nuestro sitio web de la compañía. 2. 20% de visitantes a nuestro sitio web que regresen a visitarnos nuevamente, dentro de una semana. 3. 10% de visitantes que dejen un mensaje o pregunta sobre nuestros productos. **Aquí algunos puntos importantes:** • El cumplimiento (o no) de los resultados clave, determinará el grado de cumplimiento del objetivo. • Y el otro punto importante: **Caja de tiempo o Timebox**. Estos resultados clave y objetivo son para un periodo de tiempo corto, en este ejemplo, para un trimestre. De esta manera tenemos el resultado cuantificable esperado durante un periodo de tiempo esperado. Esto es totalmente específico, medible e innegable. # Y… ¿Eso es todo?, parece realmente algo muy simple La verdad es que sí, los OKRs son una aproximación simple en esencia, pero no por eso menospreciemos los resultados que apoyan a lograr (digo, por algo Google y Netflix los utilizan hoy en día). Algunos de los elementos principales que lo hacen un marco tan poderoso son: ### Despliegue a todos los niveles de la organización La idea de los OKRs es que los objetivos y resultados clave que más aporten a la organización a nivel estratégico estén claramente definidos, y cada división, departamento, equipo (e inclusive puede implementarse a nivel persona) tengan claro cómo sus OKRs individuales aportan, día a día, paso a paso, a los OKRs de toda la compañía. Ya que los OKRs a nivel organización, los OKRs a nivel división, los OKRs a nivel departamento y los OKRs a nivel equipo, son transparentes y visibles para todos, la alineación que se puede lograr es extraordinaria (esto se conoce como **alineación vertical**). De la misma manera, ya que en nuestro día a día dependemos (en muchas circunstancias) de otros equipos o departamentos. Un punto de dolor común es diversas compañías, es que cada equipo o cada división tiene sus propias métricas para evaluar cómo están realizando su trabajo. Hasta aquí todo parece ir bien, ¿correcto?, pero ¿Qué sucede cuando las métricas o indicadores “individuales” de un equipo o departamento se contraponen con los indicadores de otro equipo o departamento? (image: leonel-zapien-ideas-agilidad-okrs-alineacion.webp) **Te voy a contar una historia (Me gusta mucho contar historias)** 😉 Claro que no puedo compartir nombres, pero una compañía con la que colaboré realizaba un producto X, y la verdad es que era todo un éxito. En el proceso de elaboración de este producto, había dos áreas importantísimas, una era desarrollo y la otra era calidad. Desarrollo elaboraba el producto y lo enviaba al área de calidad para que hiciera las validaciones correspondientes. Hasta ahorita todo parece aún ir bien, ¿aún correcto? El detalle, es que a desarrollo lo medían por la cantidad de trabajo que enviaban a calidad (más, en este sentido, es mejor. Al menos para desarrollo). A calidad lo medían por la cantidad de defectos que detectaban (aquí también, más defectos detectados es mejor, desde el punto de vista de los indicadores de calidad). Pues bien, desarrollo se enfocaba en enviar y enviar la mayor cantidad de trabajo que pudiera a calidad, a destajo, podían llegar a ser cantidades descomunales de trabajo. Calidad es un muestreo (claro que hay temas como automatizaciones que nos pueden ayudar para no hacerlo manual), pero ningún proceso puede asegurar un porcentaje de errores de 0.0000000%... en ese sentido, a calidad se le podían ir algunos defectos (en especial cuando tenían un alto volumen de trabajo por revisar), y cuando se “escapan” estos defectos y llegaban al cliente. ¿De quién era la culpa? El argumento de Desarrollo era: “Calidad no lo revisó bien”, se podía caer en el objetivo de enviar trabajo por enviar, desarrollo cumplía su indicador (cantidad de trabajo “terminado”), y si calidad no detectaba algún error o defecto y llegaba hasta el cliente, cuando volvía era un indicador de calidad. Lo sé, mal, mal, mal, en este escenario pintaba todo mal (y en realidad al final todos perdían). Pues bien, los OKRs se utilizan también para crear **alineación horizontal**, entre divisiones, departamentos, equipos. Deben de cocrearse objetivos y resultados clave que corresponsabilicen a ambas partes, que promueva la colaboración y que asienten la base para un verdadero ganar-ganar, tanto entre los equipos implicados, como a nivel organización. # Si me enfoco en todo, no me estoy enfocando en nada (poco es mejor) Los OKRs por definición deben de ser pocos, de tal manera que se tenga un enfoque real. Dependiendo la fuente que revises, puedes encontrar un poco de variación en cuando a las cantidades (pero es algo realmente menor, no es como que un autor diga 4 y otro diga 44). Respecto al número de Objetivos y Resultados Clave, las fuentes bibliográficas que he leído, por ejemplo, los autores Paul R. Nivel y Ben Lamorte, así como lo que he comprobado que funciona bien en la práctica, son los siguientes: **Número de Objetivos (O):** De 2 a 5 (como máximo, pero de verdad menos es mejor). **Número de Resultados Clave (KR):** De 2 a 4 para cada objetivo. # Cadencia Otro de los elementos poderosísimos de los OKRs es que es un modelo cíclico, que funciona en base a iteraciones o cadencias. (image: cadencia.webp) Retomemos el mismo ejemplo que conversábamos más arriba en este artículo: “Diseñar un sitio web atractivo que llame a la gente a visitarnos como clientes potenciales”. Los resultados clave asociados a este objetivo, lo que nos hará saber de una manera medible cómo vamos con respecto a este objetivo, son los siguientes: 1. Incrementar en 40% el número de visitas a nuestro sitio web de la compañía. 2. 20% de visitantes a nuestro sitio web que regresen a visitarnos nuevamente, dentro de una semana. 3. 10% de visitantes que dejen un mensaje o pregunta sobre nuestros productos Mencionábamos que este equipo hipotético tenía este objetivo para un trimestre. Pues bien, si llegamos al final del trimestre para evaluar y darnos cuenta en ese mismísimo momento que no se logró el objetivo, tal vez (solo tal vez), ya sea un poco tarde para intentar hacer algunos ajustes durante el camino. Por esto, hay todo un ciclo de OKRs que ayuda a dar cadencia a este marco, y tenemos transparencia constante para inspeccionar y adaptar. Pues bien, este ciclo de OKRs establece que se pueden definir Objetivos y Resultados Clave de la manera siguiente: **1. De manera anual (para la estrategia d etoda la organización).** Es definir los OKRs a nivel estratégico para toda la organización. En este sentido, hay muchos autores que “anti-rrecomiendan”, y yo soy solo autor de este blog, pero coincido en que es un periodo de tiempo muy largo para la vorágine del mundo VUCA-BANI en el cual vivimos (por cierto, si quieres saber un poco más sobre los acrónimos VUCA y BANI, (link: https://www.youtube.com/watch?v=2uPBLpm5Qno text: te comparto aquí este link a un video de un webinar que di al respecto)). **2. Cuatro veces al año, o lo que es cada tres meses (Quarterly).** Definir los OKRs para el periodo de tres meses que está por comenzar (o alinearlos con los OKRs anuales que pudieran haberse definido a nivel organización). **3. Revisiones a mitad del cuarto (Mid-quarter).** El objetivo de estas revisiones es, habiendo llegado a la mitad del periodo, ver el avance que se tiene hasta el momento, conocer la probabilidad de alcanzar los resultados clave, y ajustar. La verdad es que aún en este punto, a mitad del trimestre, es incierto determinar si los OKRs se lograrán, pero maximiza por mucho el enfoque de los equipos y todos comparten la misma base de información. Es un trabajo colaborativo. **4. Revisiones semanales.** El objetivo de estas revisiones que se recomiendan cada semana es compartir información, evaluar el progreso, identificar riesgos potenciales antes de que se conviertan en verdaderos problemas, y, uno de los puntos de mayor valor: Mantener el enfoque, asegurar consistencia y **ayudar a que la forma de trabajar con OKRs se establezca y eche raíces en la cultura de la organización**. # Beneficios de los OKRs Después de su despliegue e implementación de los OKRs en muchísimas compañías a lo largo y ancho del mundo, entre los principales los beneficios que reportan haber obtenido las compañías que los han implementado, podemos encontrar: **1. Enfoque:** Con OKRs se asegura que todos tienen claro qué es lo que más importa, y enfocarse en ello. **2. Transparencia:** El tener metas medibles y visibles a todos los niveles, promueve la toma de decisiones informadas y el puntual paso a la acción. **3. Alineación:** La transparencia promueve la alineación multifuncional, entre personas, equipos, departamentos, divisiones. **4. Comunicación:** Al ser un sistema de fácil comprensión, se incrementa su uso y aceptación, fomentando la comunicación alineada entre las personas, equipos, departamentos, divisiones. **5. Agilidad:** Al trabajar en ciclos cortos y frecuentes de retroalimentación, se fomenta la agilidad y se está mejor preparado para los cambios. **6. Compromiso:** La mayoría de los OKRs se originan de “abajo hacia arriba” en la estructura organizacional (bottom-up), de tal manera que las personas y equipos son dueños y responsables de sus metas. **7. Pensamiento visionario:** Los OKRs ayudan a “estirar” nuestro pensamiento acerca de lo que es posible, para alcanzar metas más retadoras. # Conclusiones Hasta aquí, de manera general he compartido la esencia de este marco de trabajo conocido como OKRs. La verdad es que es muy sencillo de comprender, considero que el verdadero reto reside por un lado en la elaboración y definición de Objetivos y Resultados Clave efectivos y retadores, que no indiquen métricas de vanidad o que no aporten a la estrategia organizacional, así como que no sean realmente retadores y solo lleven a los equipos a continuar trabajando igual, a hacer lo que se conoce como** BAU (Business as Usual)**, es decir, trabajar de la misma manera que se ha venido trabajando siempre. Por otro lado, el segundo punto de importancia en la adopción de OKRs, y uno muy importante para que de verdad se den resultados sorprendentes, es algo que había mencionado un poco más arriba en el artículo: Los OKRs deben de enraizarse en la cultura de la organización. Es decir, debe de haber una seguridad para que los equipos puedan experimentar y proponer, para intentar lograr sus objetivos, alineación vertical y horizontal que fomente la colaboración y enfoque, patrocinio de los niveles directivos en el programa de OKRs, compartir y conversar en espacios que realmente detonen maneras creativas de alcanzar y superar los OKRs. Hay una cita respecto al cambio, que siempre me ha encantado: **“Un cambio es cultural, o no lo es”**. Así de simple y así de poderoso. Fomentemos los OKRs con un enfoque experimental, de aprendizaje. Siempre con la mentalidad o mindset de la Agilidad o Agilismo en el foco, siempre recordando que todo parte de los Individuos y sus interacciones, sobre los procesos y las herramientas. **¿Habías escuchado hablar antes de los OKRs?, ¿Cómo te ha ido experimentando con ellos en tus equipos?** ### Referencia: **Objectives and Key Results: Driving focus, alignment, and engagement with OKRs.** Paul R. Nive and Ben Lamorte.

4 de marzo de 2024
Ver más artículos súper chéveres

Yo soy
Leonel :)

leonel-zapien-lopez-ideas-agilidad-consultor-agile-scrum-management-3.0-kanban-guadalajara-mexico

¡Hey!, ¿Qué tal?

Soy un espíritu libre y creativo: Amo viajar y las actividades al aire libre como trekking y acampar.
Soy fan de los comics, de Star Wars y me encanta la salsa cubana.

Mi pasión en la vida (además de la Agilidad) es la fotografía y la literatura.... todo esto es parte de mi ikigai.

Aquí te platico sobre mí y mi experiencia profesional