Lograr una buena comunicación es sin duda, uno de los grandes desafíos que tienen no solo los equipos, sino también las organizaciones como un todo. Ya que esta al ser un sistema adaptativo complejo, necesita crear, buenos canales de comunicación para transmitir la información tanto internamente como desde y hacia sus clientes de manera constante y continua. Con el fin de que estos (los clientes), no solo reciban buenas soluciones que logren satisfacer sus necesidades, sino que también, puedan comprender realmente lo que se les esta entregando. Y al interior de la organización, exista claridad hacia donde se va y porque ese es el camino, las metas que se esperan alcanzar y como se espera que se alcancen. Es decir, que la comunicación ha de ser la base para lograr la conexión organizacional que se requiere para realmente desarrollar la agilidad.
Adicionalmente a esto, el poder comunicar al interior de la organización, no solo correctamente la información, sino también la información correcta, permitirá tomar las mejores decisiones de cara al camino a seguir y al hecho de tener que adaptar su comportamiento y estructura, según los resultados generados y/o el contexto en el que se encuentre la organización. Esto es lo que conocemos como Homeostasis organizacional, la cual requiere entre otros factores, de buena conexión y comunicación al interior de la organización, para lograr su fin. De ahí, que una de los cosas que más se fomente en un viaje de habilitación de la agilidad, es el desarrollo de la capacidad de poder comunicarse de la mejor manera entre las personas y/o los distintos equipos y áreas que componen la organización.
En cada proyecto en el que he participado en estos años, al igual que en cada acompañamiento y/o consultoría que he realizado, siempre he tenido muchas lecciones aprendidas en torno a la importancia de una buena comunicación. Dada la impresionante cantidad de interacciones y tareas que dependen de la comunicación, pero es aún más impresionante la cantidad de malentendidos y problemas que se generan, cuando esta, no se hace de la manera y forma adecuada.
Ahora, en muchos casos por estar tan centrados en nuestras metas, necesidades y suposiciones sobre los demás, terminamos no comprendiendo realmente, no solo lo que nos quieren decir, sino que tampoco la verdadera necesidad a satisfacer o las metas a alcanzar. Al hablar de una buena comunicación, debemos hablar entonces de una buena comprensión o como lo llaman algunos autores el “arte de comprender”.
Y es que, siendo precisamente la naturaleza del ser humano el hecho de estar suponiendo lo que el/los otros le quieren decir, es lo que termina generándole muchos problemas y/o malentendidos. De ahí, que el comprender y no suponer, es un campo que todos deberíamos aprender.
Pero, ¿Qué hay de malo en las suposiciones?
Daniel Kahneman en su libro Thinking, Fast and Slow. Llama a los supuestos, “El inconsciente adaptativo”, lo cual desde su punto de vista, es básicamente, la parte del cerebro responsable de los juicios rápidos. La cual, en muchos casos, demuestra ser muy eficaz para ayudarnos a tomar decisiones rápidas e incluso puede salvarnos la vida. Sin embargo, los seres humanos, somos dados a confiar demasiado en esta capacidad, por lo que le permitimos inconscientemente realizar demasiadas tareas de decisión. Las cuales, simplemente no puede gestionar.
Los seres humanos, usamos el llamado pensamiento rápido para crear opiniones sobre las personas y dar sentido a lo que dicen y cómo se comportan. Como resultado, la gran mayoría de nuestras interacciones con los demás terminan guiándose por suposiciones.
Reflexionando un poco en esto, te invito mi querido amigo lector a pensar en la última vez que discutiste con alguien. ¿Cuánto tiempo pasó hasta que tuviste una reacción emocional? ¿Tuviste tiempo para escuchar la opinión de la otra persona? ¿sus argumentos? ¿Estás seguro de que realmente entendiste lo que la otra persona estaba tratando de decir y, lo más importante, por qué lo hizo? Personalmente tengo varias, por no decir muchas experiencias en ese sentido, tanto con mi esposa como con mis hijos y que decir de familiares, amigos, colegas, compañeros de trabajo e incluso clientes. En general, es una muestra que nuestro inconsciente adaptativo, influye esta presente en nuestro día a día.
A menudo hacemos suposiciones sobre lo que piensan otras personas y por qué hacen lo que hacen. Como resultado, tratamos a las personas que nos rodean como si supiéramos lo que están haciendo, incluso si no lo sabemos. Veronika Kortba y Ralph Miarka, En su libro: Agile Teams, enseñan el arte de la comprensión y demuestran cómo se puede aplicar para facilitar la comunicación en equipos. De este libro mi querido lector te puedo contar que desafortunadamente actualmente, solo está disponible en alemán. Sin embargo, hay varios apuntes interesantes en inglés, que puedes encontrar en la web, como por ejemplo el fragmento que uso para tomar como referencia al escribir parte de este post.
En uno de esos apuntes del libro que encontré, los autores plantean el modelo de coco (una explicación grafica que muestra lo que nos sucede a los seres humanos en ciertas situaciones). En la imagen, plantean la idea detrás hay una niña que vive en una isla que tienen múltiples arboles de coco. Y un joven que vive en una isla contigua, con árboles que no son de coco. Un día, la niña decide que es frustrante que el hombre nunca haya visto un coco, así que decide arrojarle uno. Sin embargo, el pobre está totalmente confundido y se pregunta: ¿por qué ese coco de repente vuela hacia mí? ¿Alguien me está atacando?
Ilustración del modelo de coco (del libro ‘Agile Teams’ de Veronika Kortba y Ralph Miarka)
Desafortunadamente, esto es lo que sucede a menudo en nuestras interacciones con los demás. Les “arrojamos cocos” (ofrecemos soluciones que creemos que son buenas para los problemas que creemos que tienen). Hacemos suposiciones sobre los demás, lo que, en la mayoría de los casos, da como resultado una serie de juicios erróneos y malentendidos.
Analiza un poco mas esto y piensa por ejemplo, ¿cuántos cocos entregan los equipos, por no comprender realmente las necesidades que plantean los Product Owner?, o ¿Cuántos cocos entregan los equipos, porque el Product Owner no se dio a entender? O peor aún ¿Cuántos cocos entregan los equipos, por no interactuar nunca con los clientes?
Y es que hay que tener presente que entender y comprender son cosas distintas, ya que Entender es percibir el significado de algo, aunque no se comprenda. Comprender es hacer propio lo que se entiende y actuar congruentemente con ello. De ahí la importancia que los equipos comprendan realmente las necesidades mas que solo entenderlas, al igual que los lideres de la organización, quienes necesitan mas que entender un marco de trabajo, necesitan comprender lo que es la agilidad y los cambios que se requieren para que esta sea habilitada. Esta demostrado que cuando esto no sucede, se termina colocando foco por ejemplo en la implementación de un marco de trabajo por encima de realmente habilitar la agilidad.
Es por esto, que propuestas como el User Story Conversation Canvas que plantea lucho Salazar, se convierten en una herramienta sensacional, a la hora de lograr una buena conversación que desencadene en una verdadera comprensión del problema a resolver. O que las distintas alternativas de definición de historias de usuario que nos proponen lucho y Jorge abad en su libro historias de usuario – una visión pragmática, sean una gran herramienta a la hora de lograr una excelente comprensión de las necesidades de los clientes. O que técnicas como el Deep-Dive o el Design Thinking, que sumergen a los equipos al conocimiento real del cliente y sus necesidades, terminan siendo de gran provecho a la hora de generar soluciones de valor.
De ahi que la guia de scrum por ejemplo plantee que es responsabilidad del Product Owner, «Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel necesario». Es decir garantizar que verdaderamente los comprenda (en la guía en ingles aparece la palabra Understand, que al español se podría traducir como entender/comprender, sin embargo al indicar que es al nivel necesario nos lleva al contexto real de comprensión por encima de solo entendimiento). Ahora, este es un punto que sin duda va en doble vía, ya que debe ser una responsabilidad del equipo, comprender las necesidades planteadas por el Product Owner. Por lo que estos (los integrantes del equipo), deben hacer las preguntas necesarias para lograr este objetivo. De igual forma, el Scrum máster tiene como responsabilidad «Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista de Producto claros y concisos» y «Entender la planificación del producto en un entorno empírico» (en ambos casos aplica lo del punto anterior con la palabra Understand de la guía original en ingles).
Ahora, dominar el arte de la comunicación comienza con hacer las preguntas correctas, en el momento correcto. Y es que, las preguntas pueden actuar como un puente entre las dos islas y hacernos saber más sobre las otras personas, sus necesidades y motivaciones. Por otra parte, las respuestas que obtengamos actuarían como base para una mayor comunicación y nos ayudarían a desarrollar una comprensión de lo que nos quiere transmitir la otra persona.
Desde mi perspectiva, la mayoría de las percepciones se descubren cuando hacemos preguntas sobre los sentimientos y emociones de las personas. ¿Por qué? Porque de esta manera, podemos ayudar a comprender algo sobre la persona que tal vez ni siquiera ellas misma se había dado cuenta. En este sentido, los podemos ayudar a tomar conciencia de una situación o problemática específica. Algo que en procesos de gestión del cambio, termina siendo crucial.
Por eso, mi querido amigo lector, la invitación final va en el sentido de que evitemos a toda costa que los equipos supongan las cosas y busquemos siempre la manera de que realmente comprendan las cosas. Lo cual servirá, para tener mayor claridad sobre las necesidades a resolver y así poder plantear y desarrollar soluciones que verdaderamente generen valor.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Y si los equipos utilizaran técnicas como esta… Tendrían un enfoque de productos y cuanto valor generarían.
Una de las cosas que tienen las organizaciones que han empezado el viaje de habilitación de la agilidad son estructuras virtuales, denominadas equipos, células, salas, squads, tribus, trenes, etc. Las cuales de una u otra forma utilizan Frameworks en busca de no solo agilizar su proceso de generación de valor, sino también habilitar la agilidad como tal, tanto en el interior de dichas estructuras como en la organización a la que pertenecen.
Sin embargo, una de las cosas que llama mucho la atención, es lo limitantes al marco de trabajo que se vuelven dichos equipos. Ya que, aunque existe un sinnúmero de metodologías, técnicas y/o herramientas que permiten complementar y/o apoyar su ideal de existencia (la generación de valor), estos parecen no querer utilizarlos.
Es por eso mi querido amigo lector, que en esta ocasión, quiero compartir contigo una sencilla pero poderosa técnica de ideación y generación de productos denominada Deep-Dive. La cual se utiliza para sumergir rápidamente a un equipo en una situación específica, para la resolución de problemas o la creación de ideas que desencadenen en productos o soluciones de gran valor para los clientes.
La técnica Deep-Dive, Originalmente fue desarrollada por el grupo IDEO (una empresa de diseño de aprendizaje) para el desarrollo rápido de productos. Dicho método, fue documentado por Andy Boynton y Bill Fischer (de la escuela de negocios del International Institute of Management Development (IMD)), quienes posteriormente mejoraron aún más el proceso y vendieron los derechos a Deloitte Consulting en 2006.
La técnica, se centra en cuatro áreas distintas: proceso, organización, cultura y liderazgo.
Proceso. Fracasar a rápido, para tener éxito antes. El ensayo y el error ilustrados suelen presentar grandes resultados. La creación de prototipos facilita el aprendizaje sobre el producto, servicio o proceso. Ahora, el prototipo de múltiples ideas a pequeña escala para demostrar, construye a que se pueda experimentar sobre algo que se pueda ver y sentir.
Organización. Permitiendo tener una estructura plana enfocada al aprendizaje.
Cultura. La confianza en los miembros del equipo es vital y fundamental para esta metodología. Ya que se da por hecho que las personas puede aportar todo su potencial creativo.
Liderazgo. El líder del equipo solo facilita, no es el experto. Su función es únicamente la de orientar el proceso, pero no participar en las ideas. Esto permite la libertad. Este proceso es consistente
la clave para una (s) sesión (es) de Deep-Dive exitosa (según se creador), es que los participantes lleguen con información sobre las necesidades de sus clientes. Y lo más importante, una mente abierta de lo que pueden ofrecer y cómo pueden satisfacer las necesidades y expectativas de los clientes.
En cuanto a la ejecución de una sesión de Deep Dive, tenemos que decir que esta se ejecuta bajo un proceso de cinco pasos que son:
Comprender el mercado / cliente / tecnología y las limitaciones (análisis DAFO interno y externo, análisis PESTLE y análisis PRIMO-F)
Observar a personas reales en situaciones reales.
Visualizar conceptos nuevos y clientes finales
Evaluar y perfeccionar prototipos
Implementar nuevo concepto de Entrega y/o Comercialización.
Y ya propiamente en la ejecución de la sesión:
Se crean los Hot Teams para trabajar en las oportunidades / problemas (estos equipos trabajan el proceso de punta a punta)
Se realiza una lluvia de ideas y opciones en el contexto de las necesidades del cliente
Se realiza un prototipado rápido de posibles soluciones
Se observa y se escucha a los clientes (internos y externos)
Y se piensa en un enfoque de productos
Un punto para tener en cuenta con esta técnica, es que una vez que se completan las fases de generación y captura de ideas, una serie de ideas se deben convertir en ‘prototipos’ para ver cómo pueden funcionar o no. Ahora, una idea no debe progresar hasta su implementación hasta que no se haya creado un prototipo y se haya probado junto con otras ideas. La prueba consiste en involucrar a los participantes que interactuaron con los clientes, proveedores y otras partes para probar o explorar los méritos de la propuesta.
El centro de este enfoque, es la creación de prototipos que resultaron de una lluvia de ideas visual e interactiva. Este enfoque hace que las ideas sean más tangibles, acercándolas a su objetivo, al mismo tiempo que resalta los problemas que no eran obvios cuando solo era una buena idea en una pizarra.
Sin duda mi querido amigo lector, la técnica del Deep-Dive, es una gran herramienta para los equipos que quieren no solo generar soluciones exitosas que generar gran valor para los clientes y la organización, sino te también permite que los equipos tengan realmente un enfoque en productos y no en proyectos lo que brinda la posibilidad de poder enfocarse en Outcomes y no en outputs.
Aquí te dejo un video mi querido amigo lector, para que veas un poco la tecnica en ejecucion.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Una Mirada a: «la simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.» desde los ojos de un Product Owner.
Encontrar la solución adecuada para el problema que queremos resolver es vital para lograr el éxito. De ahí, que los grandes equipos se esfuerzan por desarrollar soluciones precisas, ya que entienden que al construir una solución más compleja de lo necesario, se generaran residuos, se ralentizará el tiempo de comercialización y para colmo, se generará inevitablemente más deuda técnica.
En este sentido, toma mucha relevancia para un equipo entender claramente el principio del manifiesto ágil que dice: “la simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.», que se expone en el manifiesto ágil. Es por eso mi querido amigo lector, que en esta ocasión, estaré proponiéndote una mirada de este principio que debería tener un Product Owner.
Y es que todo Product Owner, debería alegrarse cuando los desarrolladores le desafían sobre los temas que trae al refinamiento de los ítems del Product Backlog. Ya que esto demuestra que están interesados en resolver problemas reales. Sin embargo, muchos desarrolladores no aceptan que los Product Owner desafíen la solución técnica. Ya que, en muchos casos piensan que estos se están entrometiendo en su definición del cómo, tal vez algunos lo hagan con esa intención (cosa que no debería suceder), pero en realidad hay que entender que los equipos de alto desempeño, logran resultados asombrosos porque no les temen a las diferencias de opinión que puedan llegar a tener entre ellos. Por el contrario, potencializan esas diferencias para diseñar y desarrollar soluciones que generen alto valor.
Patrick Lencioni, en su libro: “The Five Dysfunctions of a Team: A Leadership Fable” (Las cinco disfunciones de un equipo: una fábula de liderazgo), plantea lo siguiente: “Es tan simple como esto. Cuando las personas no descargan sus opiniones y sienten que han sido escuchadas, realmente no se unirán”. Y nada más cierto que esto, ya que de parte la premisa que debemos hacer partícipes a las personas de las definiciones, para que logren empoderarse de lo que hacen. De ahí la importancia, que dicha comunicación y desafío sea en doble vía.
En Scrum, por ejemplo, los Product Owner son dueños del por qué. Entonces, como responsables de la maximización del valor a generar, deben decidir por qué el equipo debe trabajar en algo. Ahora, dado que el equipo de desarrollo es dueño del cómo, ellos deciden cómo resolver los problemas. Sin embargo, no debemos olvidar que la responsabilidad final de todo lo que se elabora es de todo el Scrum Team. Por lo que, el grado de colaboración entre los miembros del equipo determinará su éxito.
Los Product Owner entonces, deben “desafiar” al equipo de desarrollo en la solución técnica. La intención de hacerlo es asegurarse de que no se generen residuos, se reduzca el time to market y se produzca la mínima cantidad de deuda técnica, entre otros factores importantes para el éxito de la solución. Otro punto importante con esto, es que un Product Owner, debe garantizar que no se estén diseñando soluciones demasiado complejas, de tal modo que dicho desafío, también buscara que el equipo traiga más opciones planteadas a la mesa.
Hay que tener claro entonces, que no se trata de cuestionar las habilidades técnicas del equipo de desarrollo. Por el contrario, se trata de ayudarles a pensar qué solución técnica se adapta perfectamente al problema que queremos resolver.
En este sentido, algunas preguntas planteadas por el Product Owner al equipo que podrían ayudar a identificar soluciones precisas, podrían ser:
¿Es esta la solución más simple que podemos construir?
¿Por qué es esta la mejor solución para este problema?
¿Qué creen que podríamos estar omitiendo?
¿Cuáles son las otras opciones que podríamos considerar?
¿Qué suposiciones tenemos con esta solución?
Según mi experiencia, si los desarrolladores no desafían al Product Owner, tendemos a crear soluciones que son demasiado simples. Y si los Product Owner no desafían a los desarrolladores, tendemos a desarrollar soluciones que son demasiado complejas para el problema que queremos resolver. Por lo que, mi querido amigo lector, el equilibrio adecuado en estos desafíos, es vital para construir soluciones de alto valor y que estemos alineados con el cumplimiento del principio ágil que se planteó en este post.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Estrategia e Innovación en amalgama, un gran motor de grandes resultados
Según el «Informe del HBR Insight Center – The Gap Between Strategy and Execution Collection», el cual tiene una recopilación de 25 artículos de la «Harvard Business Review» del 18 de marzo. En el contexto empresarial, solo una de cada 10 empresas alcanza todos los objetivos programados y los nueve negocios que fracasan, tienen pérdidas del 20% del presupuesto anual debido a la desconexión entre la estrategia diseñada y la estrategia efectivamente implementada. Un panorama preocupante, que deja en evidencia el problema de desconexión organizacional que viven las organizaciones a nivel mundial y que según el mismo estudio, aun cuando algunas de estas organizaciones presentan avances en temas de agilidad, siguen sin lograr conectar efectivamente la estrategia con la táctica y más preocupante aún, la estrategia con la innovación.
Motivo por el cual, en esta ocasión mi querido amigo lector, pretendo mostrarte un poco como la estrategia y la innovación, no solo deben de conectarse, para lograr que las organizaciones alcancen verdaderos resultados de negocio y valor para sus clientes. Sino también, como lograr esa conexión o amalgama.
Phil Crosby plantea: «Una empresa ‘con problemas’ es aquella en la que la administración y los empleados no se encuentran en el mismo bando. La empresa ‘libre de problemas’ es aquella en que todos los empleados están unidos y no existen bandos.» Si bien es cierto que todas las organizaciones de una u otra forma enfrentaran a lo largo de sus existencia grandes desafíos, la cultura de estas, reflejará la forma en que los afrontarán, de ahí la importancia que toma el hecho de mantener una cultura que permita que toda la organización este conectada bajo un mismo propósito, el cual debe empoderar y encaminarlos a todos a conseguir resultados conjuntos y no individuales ni por áreas, ya que cuando esto sucede los silos se hacen mas evidentes y termina la organización teniendo dos tipos de cultura, la que se vive y la que esta escrita en el papel.
La forma en que la cultura de una organización evolucione, sin duda marcará la pauta del grado de desarrollo de la agilidad que esta consiga. Y, como una de las promesas de la habilitación de la agilidad es la generación de valor, dicha generación de valor, no solo debe estar conectada a las necesidades de los clientes, sino que también debe estar conectada con la estrategia organizacional, para que no se presente lo que particularmente denomino “Desconexión Organizacional”, ese estado en el cual, lo importante es hacer o entregar, sin entrar a analizar por qué se deben hacer las cosas y cuál debe ser la prioridad de estas, no se gestionan correctamente las posibles dependencias, como tampoco se analizan en conjunto los riesgos y el impacto generado, dando como consecuencia el sobre esfuerzo, el financiamiento descontrolado y los silos.
En organizaciones en donde la agilidad comienza a tomar vuelo, es donde dicha desconexión comienza a hacerse más evidente, dada la naturaleza en sí de la agilidad, la cual a medida que comienza a emerger; también comienza a sacar a flote cada vez más los problemas que presenta la organización, en pro de que se comiencen las conversaciones, los análisis y la toma de acciones que den solución a los problemas.
Fuente: Redarquia.net
Por eso cuando hablamos de habilitar la agilidad organizacional, lo que buscamos es crear conexión organizacional, es decir, una conexión orgánica entre todas las partes de una organización, que permita que se dé, de manera permanente, esa capacidad de respuesta, de generación de valor, de inspección, de adaptación, de mejora continua y de gestión del cambio, como una cualidad propia de la cultura organizacional, que permita afrontar con éxito el entorno VUCA.
En este sentido, una organización que logra comenzar a desarrollar orgánicamente la agilidad, es aquella que ha creado conexión organizacional y es aquí en donde la estrategia y la innovación logran el amalgama perfecto para generar los resultados esperados.
Ahora, hay algunos puntos básicos para tener en cuenta al momento de lograr consolidar este amalgama sino también para mantenerlo solido a lo largo del tiempo en la organización y estos son:
Tener principios y valores claros y sobre todo realmente vivirlos
Este punto lo podemos dividir en dos partes:
La «Planificación estratégica», la cual si bien directamente no es innovación, esta representa el acto de toma de decisiones por parte de un grupo de interés sobre «dónde jugar» y «cómo jugar» para “Ganar”.
La “Ejecución”, la cual es el acto de brindar autonomía a los responsables de estas elecciones, asegurando que las personas elijan la mejor forma de ejecutarlas.
Este equilibrio se puede lograr mediante la existencia de principios y valores sólidos, arraigados a la cultura organizacional y a prácticas, técnicas herramientas, las cuales pueden cambiar o variar con el paso del tiempo, pero los principios y valores permanecen. Es precisamente estos (los valores y principios), los que son considerados la esencia real de todo lo que acontece en la organización.
De ahí la importancia que la comunión o amalgama entre la estrategia y la táctica, este soportada en principios y valores, ya que los planes son solo intenciones, a menos que generen movimiento y trabajo que genere valor tanto para clientes como para la organización.
Tener un equilibrio entre el Diseño de la estrategia y la Ejecución de la estrategia.
Es fundamental dar igual importancia a la elaboración de la estrategia y la ejecución de la estrategia. Y sobre todo, que la construcción y desarrollo de ambas, sea un proceso de co-creación colaborativa. Un punto para tener en cuenta, es que existen desafíos durante la definición y el desarrollo de la estrategia, tales como la interpretación del contexto (el mercado, las áreas, los clientes, etc.), la definición de metas intermedias, la desagregación de objetivos, y la creación de mecanismos de aprendizaje. Y en este sentido, la innovación representa el medio para poder equilibrar todo esto, generando resultados de valor tangibles para los clientes y la organización. Para esto los procesos de innovación, presentan herramientas que centran al cliente en el foco de lo que se quiere lograr, de tal modo que una alineación entre la estrategia definida y dicho procesos, permitirá entregar al cliente soluciones no solo acordes a sus necesidades sino también, soluciones alineadas a la estrategia organizacional.
Promover la inteligencia y la seguridad en el uso de datos.
Durante la elaboración del diseño de la estrategia, es necesario utilizar información sobre las partes involucradas en su contexto, mapeando oportunidades y amenazas, incertidumbres y dependencias, incorporando ideas para la propia elaboración. Usar tendencias tecnológicas como la automatización, el uso de realidad virtual o aumentada, el uso de Internet de las cosas para predecir el comportamiento orgánico del consumidor, el uso de una mayor seguridad de la información para garantizar que las personas elijan compartir sus datos sin necesariamente sentirse invadido puede mejorar estas prácticas.
Tener a las personas adecuadas, empoderadas y en los lugares adecuados
Para que la estrategia y la ejecución estén equilibradas, es necesario asignar los objetivos adecuados a las personas. De tal forma, que podamos evitar redundancias de tareas, segregando lo que es operación de lo que es la lista de nuevos proyectos, categorizando los desafíos por conocimientos y habilidades específicas, dando autonomía en función de un propósito a los equipos y recordando reconocer a los ejecutores. Una persona motivada en el lugar correcto, puede obtener resultados increíbles, gracias a que puede hacer lo que realmente lo motiva y además si tiene claro el propósito de lo que está haciendo explotara su capacidad creativa al máximo y con ello podrá aportar más en el desarrollo de dicha solución. Al fin y al cabo, las personas son el combustible infinito de la innovación.
Supervisar los resultados y actualizar los planes
Cuando la estrategia está en marcha, es necesario tener el compromiso de que se le dará seguimiento al avance en la consecución de los resultados claves esperados. De tal modo que se puedan tomar decisiones a tiempo en torno si vamos o no en el camino adecuado a la consecución de los objetivos trazados en la estrategia.
Priorizar y ser simple
El mundo ha alcanzado un nivel de hiperconectividad y complejidad. Por eso, ser sencillo y saber priorizar sigue siendo fundamental. Este es el mayor problema encontrado en el proceso de desarrollo de la estrategia. Para ello, es necesaria una cultura donde exista poca burocracia, y que sea posible tomar decisiones rápidas sobre oportunidades y amenazas, donde se puedan tomar riesgos, pero con foco en el objetivo final de la estrategia.
Mantener el foco, arriesgar y celebrar
Si así como suena, ya que uno de los objetivos por el cual se define una estrategia, es para ayudar a los equipos a mantenerse enfocados, tener un punto guía contra que priorizar el trabajo a realizar. En este sentido, es esencial obtener una alineación genuina entre las distintas capas de la organización, asi como entre los distintos equipos y/o estructuras virtuales que la componen. Promover una cultura transparente que fomente la cooperación empresarial para mantener motivada a su gente, será clave en la titánica tarea de empoderar a las personas, pero más allá de ello, en poder alinearlos a todos hacia el mismo objetivo.
Ahora bien, arriesgarse a tomar decisiones rápidamente y eliminar los obstáculos para que la organización avance hacia los objetivos trazados más rápidamente, incluso en tiempos de incertidumbre. Permitirá tener una ventaja competitiva con respecto a la competencia, en caso de que las decisiones hayan sido acertadas, en caso contrario, aprender a usar el fracaso de modo consciente, como un enfoque de aprendizaje para el contexto de crecimiento e innovación de la organización. Permitirá que las decisiones futuras generen mayor impacto en la consecución de la estrategia.
Ahora, si todo sale bien, el reconocimiento a los aportes de las personas y los equipos, genera confianza y motivación. Como también permite crear una cultura laboral positiva.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Todos los seres humanos de una u otra forma, tenemos en nuestros pensamientos algún tipo de clásico que nos hace recordar gratos momentos. Dentro de los clásicos mas comunes tenemos por ejemplo los modelos de autos antiguos que aunque poco se ven en las calles de las principales ciudades, siempre nos transportan a una época (que aunque muchos no vivieron) nos hace pensar/recordar como fue. Del mismo modo, existe un clásico que todo Product Owner debe conocer ya que este es una herramienta que no pierde vigencia. Dado que permite adentrarnos de una manera simple, al mundo de la priorización en el desarrollo de productos incrementales. Pero al mismo tiempo, es una herramienta muy útil para identificar y clasificar los distintos atributos de los productos para luego relacionarlos con el grado de satisfacción que brindan al cliente.
Motivo por el cual, mi querido amigo lector, quiero recordar (para aquellos que ya lo conocen) y/o compartir (para aquellos que no lo conocen) este clásico propuesto por Noriaki Kano, mundialmente conocido simplemente como el Modelo de Kano.
Como mencione en el párrafo anterior, el Modelo de Kano ha sido utilizado desde su creación, para priorizar lo que se debe ir añadiendo a los incrementos del producto. Así como también, para identificar y clasificar los distintos atributos o funcionalidades de los productos. Para luego, relacionarlos con el grado de satisfacción que brindan al cliente. Esta multiforma de uso, ha permitido que el Modelo de Kano sea una herramienta clásica, que no puede faltar en la caja de herramientas de un Product Owner.
El modelo de Kano, tiene como objetivo último, el que se pueda identificar claramente cuáles son los atributos valorados por los clientes y ofrecer así, un producto acorde a dicha valoración. Así, por ejemplo, el modelo Kano nos ayuda a identificar los siguientes cuatro elementos, claves para la definición de lo que será la estrategia de liberación:
Cuáles son las falencias de un producto o solución
Que atributos deberían estar presentes y por diversas circunstancias no lo están (o por lo menos no en el grado que genere realmente valor a los clientes)
Si es conveniente o no invertir en agregar o no un determinado atributo. Es decir, nos permite si el cliente, estará o no dispuesto a pagar por este atributo adicional.
Determinar cuáles atributos pueden llevarnos a superar a nuestros competidores.
Pero, ¿Cómo funciona el modelo Kano?
El modelo de Kano clasifica los atributos en cinco grandes categorías, de acuerdo a cómo afectan la satisfacción del cliente:
Calidad básica o esperada: Son los atributos o funcionalidades mínimas con las que debe contar un producto o servicio. En otras palabras, es lo mínimo que el cliente espera encontrar y si no se encuentran estos atributos existirá una gran insatisfacción.
Los atributos o funcionalidades básicas no sirven para aumentar la satisfacción del cliente. Probablemente el no agradecerá si las encuentra ya que es lo mínimo que espera.
Calidad deseada o de performance: También llamados atributos o funcionalidades de rendimiento. Se trata de atributos o funcionalidades que son solicitadas por el cliente y que pueden marcar la diferencia con los competidores. Estas, son atributos o funcionalidades que el cliente valora, agradece, y que al mismo tiempo las utilizará para hacer comparaciones.
Los atributos o funcionalidades deseadas influyen significativamente en la satisfacción del cliente. A mayor cantidad de atributos funcionalidades de este tipo encuentre, más satisfecho quedará. Es decir, sentirá que está recibiendo más valor.
Calidad motivadora o emocionante: Son atributos o funcionalidades que sorprenden al cliente ya que los valora, pero no esperaba encontrarlos. Es decir, son detalles con los que se es capaz de sobrepasar las expectativas del cliente.
La calidad motivadora produce gran satisfacción al cliente aunque su ausencia no le generará insatisfacción.
Calidad indiferente: son atributos o funcionalidades que no influyen en nada en la satisfacción del cliente.
Calidad de rechazo: Son atributos o funcionalidades, que el cliente percibe como negativos y le causa rechazo.
Algo a favor de este modelo mi querido amigo lector, es que el modelo se puede representar gráficamente de una manera sencilla:
En el eje horizontal ubicamos los atributos o función del producto, que va desde ausente hasta completamente implementado. En el eje vertical, en tanto, ubicamos el grado de satisfacción del cliente que va desde descontento (insatisfecho) hasta encantado.
Como podemos ver, los atributos básicos apenas y cubren las expectativas del cliente mientras que los atributos de performance afectan su grado de satisfacción de manera creciente. No obstante, los atributos de emoción son los únicos que pueden llevar al cliente a un grado de satisfacción máximo.
Otro Punto interesante de este modelo mi querido amigo lector, son las diferentes variantes de la clasificación que se presentan en el Modelo de Kano. Ya que la clasificación de los atributos que resulte de la aplicación del modelo, termina no siendo estática, sino que puede variar por al menos dos factores:
El paso del tiempo y el avance de la tecnología. Con los avances tecnológicos, atributos o funcionalidades que antes pertenecían a la categoría de performance pasan a ser requisitos básicos sin los cuales es imposible competir.
Las preferencias de los consumidores. No todos los consumidores son iguales, los atributos o funcionalidades que son relevantes para algunos pueden pasar desapercibidos para otros.
Adicionalmente a todo esto, Kano en su artículo de presentación del modelo, dejó un cuestionario para facilitar la clasificación. El cuestionario se basa en una matriz, en donde las filas representan el cómo me sentiría el cliente, si estuviera esa característica o atributo y las columnas representan, el cómo sentiría si no las tuviese. Ahora, para el registro de dicha matriz, se pueden responder las siguientes preguntas: ¿me gusta?, ¿lo espero?, ¿me da igual?, ¿puedo tolerarlo? y ¿me desagrada?
Un ejemplo sencillo de la aplicación del Modelo de Kano, es cuando entramos a analizar los atributos o funcionalidades de un teléfono móvil moderno. Aplicando el Modelo, los atributos o funcionalidades de calidad serían:
Atributos o funcionalidades básicas: Hacer y recibir llamadas, mensajería, etc.
Atributos o funcionalidadesdeseadas: Cámara fotográfica, sincronización con correo, navegar por Internet, etc.
Atributos o funcionalidadesmotivadoras: Videoconferencia, carga solar, sensibilidad al tacto.
Atributos o funcionalidadesindiferentes: Color del teclado, forma de las letras o números, etc.
Atributos o funcionalidadesde rechazo: Mala conexión, interrupciones, pérdida de llamadas, etc.
Como vez mi querido amigo lector, el modelo de kano tanto como un verdadero clásico, es una muy buena herramienta que todo Product Owner debe conocer para maximizar el valor generado tanto para clientes como para la organización.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
Enfoque de Proyectos vs Enfoque de Productos, veamos ¿cual es mejor?, ¿porqué? y como implementar el mejor enfoque.
En la actualidad las organizaciones que logran tener clara la diferencia entre un proyecto y un producto y su respectiva gestión, logran marcar una diferencia importante entre éxito y fracaso de la estrategia organizacional y la generación de valor a los clientes. Motivo por el cual, en esta ocasión quiero compartir contigo mi querido amigo lector, una comparación de lo que es el enfoque de proyectos y el enfoque de productos, los beneficios que tiene no solo para los equipos sino para la organización el tener un enfoque de productos y sobre todo como orientarnos hacia este enfoque.
Dado que en las organizaciones, uno de los mayores desafíos que enfrentará un Product Owner, un Product Manager e incluso una organización misma, es tratar de cambiar los paradigmas de las personas, los equipos y de la misma organización, al tener latente la necesidad de cambiar de un enfoque de gestión de proyectos a un enfoque de gestión de productos, con el fin no solo de maximizar el valor generado a los clientes, sino también el valor generado para la misma organización. Y digo que este desafío lo tienen los Product Owner, los Product Manager (sin dejar de lado el papel importante que juegan en esto los Scrum Master, agile coach y todos aquellos agentes de cambio con que cuente la organización), dada la función estratégica de maximización de valor que estos tienen de cara a los clientes y a la organización. Y su comunicación permanente con las capaz estratégicas de esta.
Para comenzar, analicemos lo que es el enfoque de proyectos:
De este, podemos decir que es el enfoque tradicional, por lo que se encuentra bastante generalizado. De hecho, las grandes organizaciones a menudo tienen departamentos de PMO, centrados exclusivamente en la gestión de proyectos, las cuales aún en un ámbito o ambiente en donde la organización está embarcada en el viaje de habilitación de la agilidad, su gestión y enfoque sigue siendo tradicional, en donde predomina la gestión de proyectos. Motivo por el cual, es muy común encontrar grandes organizaciones, en donde las métricas de los equipos agiles siguen siendo las mismas métricas de los proyectos tradicionales, los comités siguen teniendo el mismo enfoque tradicional de seguimiento sobre el avance y no sobre el valor generado e incluso la forma de gestión del portafolio de iniciativas sigue siendo tradicional. Al punto, que la forma en que la organización invierte el dinero se mantiene con un enfoque anual y cerrado, dejando de lado la asignación dinámica y participativa del presupuesto organizacional, según el alineamiento de las iniciativas a la estrategia y a las verdaderas necesidades de los clientes. Lo que hace que no se asignen presupuestos por ciclos cortos, los cuales permiten un rápido ajuste a la estrategia en caso de que los resultados no sean los esperados.
Ahora, el enfoque de gestión de proyectos se basa en lo que se conoce como Proyect Thinking o pensamiento de proyecto. Dicho Mindset o pensamiento de proyecto, es sustentando con el foco en la entrega, es decir en los outputs. Esto, podría ser la entrega de funciones específicas o soluciones completas. Incluso, la entrega podría ser cualquier cosa, de ahí que veamos equipos preocupados por la entrega de Historias de Usuario y no en la generación de resultados, ya que en la organización el foco esta puesto es en cuantas Historias entregan por Sprint. Lo que se ve reflejado en que su principal métrica de análisis sea la Velocidad del equipo y que la preocupación más grande sea que dicha medida no presente picos de curva descendente, ya que podría comprometer los cronogramas establecidos. Lo que es una muestra de que la percepción y finalidad de generación de valor no existe en estos contextos.
En este punto podríamos decir, que la gestión del proyecto se centra específicamente en la entrega y se mide por la precisión con la que pudimos estimar la línea de tiempo de antemano y luego realizar la entrega de manera precisa con el cronograma. De ahí la imperiosa necesidad de constantemente estar analizando el famoso porcentaje de avance del proyecto. En este contexto, el éxito se define en gran medida en la forma en cómo se capturan los requisitos/necesidades del cliente de antemano.
Ahora cuando hablamos del enfoque de productos:
Vemos como este adopta un enfoque totalmente diferente. En lugar de centrarse en la entrega, es decir en el output, el enfoque de productos se centra en el resultado, es decir en el outcome. Este es un cambio significativo de la mentalidad. Ya que en lugar de centrarnos en los plazos y las fechas, nos centramos en el ó los objetivos que queremos lograr y el trabajo que debemos realizar para alcanzar dichos objetivos. De ahí que metodologías como la de Okr, funcionen muy bien para apalancar dicho enfoque.
Ahora, debido a que estamos enfocados en el resultado en lugar de la entrega, es mucho más difícil poner restricciones de tiempo alrededor de la entrega, al menos por adelantado. Principalmente, porque por adelantado, no necesariamente sabemos cómo vamos a lograr el o los objetivos trazados.
Este tipo de enfoque requiere un cambio de paradigmas que significa un gran cambio, especialmente para las personas que han pasado mucho tiempo trabajando con el enfoque tradicional de gestión de proyectos. Ya que es normal, que se sientan incómodas con la incertidumbre de no tener cronogramas estructurados que puedan monitorear regularmente.
Ahora, los beneficios que encontramos de tener un enfoque de productos en lugar de proyectos, son variados. En primer lugar nos aseguramos de llegar al resultado de manera más eficiente, ya que con una mentalidad de proyecto, asumimos al principio que ya sabemos cómo lograr el resultado deseado. Por lo que, partiendo de esa suposición, creamos un plan de proyecto y un cronograma completo de los requisitos e hitos, y luego comenzamos la ejecución de ese plan. Pero, ¿y si nos equivocamos inicialmente? ¿Qué pasa si la solución que identificamos no va a lograr el resultado que esperábamos?
Ahí es donde el enfoque de proyectos nos mete en todo tipo de problemas. Ya que, una vez que ponemos en marcha el plan, puede ser muy difícil, especialmente en organizaciones más grandes, pivotar y cambiar. Entendiendo que, una vez que se han establecido las fechas y todos han acordado un plan, eso suele ser lo que queda en la mente de todos, a pesar de nuestros mejores esfuerzos para aprender y adaptarnos.
Pero con el enfoque de productos, podemos aprender y adaptarnos a medida que avanzamos. No estamos limitados de manera estricta en fechas e hitos. Sino, que estamos enfocados en aprender y lograr el resultado. Si algo no funciona o sencillamente los resultados no son los esperados, podemos ajustar la estrategia y adaptarnos. Por lo que, podríamos seguir trabajando hacia el resultado que pretendíamos, sin hacer estallar ningún plan. Como si sucederá en el enfoque de proyectos. Porque, cuando surgen problemas en el enfoque de proyectos, en la mayoría de las veces, nos veremos atrapados en reuniones interminables tratando de determinar por qué nuestras conjeturas iniciales estaban equivocadas y cómo ajustamos los cronogramas para cumplir con las entregas pactadas.
De este último punto, quiero resaltar que además de lo planteado, esto lleva a sacrificios en la calidad, el equilibrio entre el trabajo y la vida personal, y sobre todo el resultado esperado, ya que debemos mantenernos enfocados en cumplir con la entrega que acordamos inicialmente, independientemente de si eso sigue siendo lo correcto.
La pregunta en este punto, ahora es mi querido lector ¿cómo logramos implementar y mantener el enfoque de productos?
Lo primero que tenemos que decir, es que todos los productos y la gestión de productos, implican cierto nivel de gestión de proyectos. Dado que, es poco realista suponer que podemos trabajar en un entorno en el que nuestros Stakeholders no esperaren algunas fechas o compromisos.
La clave es hacer compromisos y planes solo en un momento en que podamos hacerlo con un alto grado de confianza. Entonces, en lugar de comprometernos con un roadmap específico de antemano, nos comprometemos una vez que hayamos validado lo que estamos haciendo y hayamos tenido la oportunidad de comprender realmente lo que se necesitará. Este es el punto de partida que nos invita a tener claro cómo será nuestra estrategia de liberación. Y técnicas como Product Discovery, Design Thinking, entre otras, apalancan fuertemente esta parte del proceso. Marty Cagan, en su libro “How to Create Tech Products People”, llama a este tipo de compromiso un «compromiso de alta integridad». Ya que brindamos tiempo a los equipos para realizar un descubrimiento y una investigación adecuada antes de asumir compromisos.
Otro punto importante, es que necesitamos ayudar a otros a comprender el beneficio del enfoque de productos. Por lo que sesiones de workshop en donde se explique mediante una simulación del contexto de lean startup seria de muy buena ayuda. Ahora, recordemos también, que hay una razón por la que mucha gente pide fechas y plazos. Parte de esto se debe a los viejos hábitos (es decir a sus paradigmas).
Además, hay que entender que hay momentos en que esta información es necesaria para establecer la estrategia del negocio y los presupuestos. Por lo tanto, debemos comprender cuál es el objetivo de establecer una línea de tiempo en esos casos. Si se trata de ayudar a vender el producto, deberíamos centrarnos en las características específicas que generaran el mayor valor posible y tendrán el mayor impacto positivo en los cliente y en la organización. Ahora, si se trata de gestionar el riesgo, tal vez necesitemos ayudar a los Stakeholders a comprender que al riesgo, no le falta una fecha para ser determinado. Sino que por el contrario, se está perdiendo el enfoque por completo del valor que estamos tratando de ofrecer.
Al final, si bien el propósito del enfoque de productos es entregar valor a los clientes y a la organización. Debemos comprender, que la mayoría de las veces no sabemos exactamente qué tipo de valor se va a ofrecer. Por lo que, pensar que podemos encontrar las soluciones correctas por adelantado, a veces con un año de anticipación, realizando la planificación y presupuestación anual, es bastante poco realista.
De ahí mi querido amigo lector, la importancia de implementar este enfoque en los equipos y en general en la organización, ya que como logramos ver, el enfoque de productos, mantiene el enfoque en el resultado correcto, es decir en el valor que espera recibir los clientes y la organización.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
10 cosas que debes tener en cuenta para lograr implementar correctamente un sistema de OKR
En la actualidad las organizaciones que están en el viaje de habilitar la agilidad de una manera orgánica, han encontrado en los OKR (objetivos y resultados clave) más que una metodología para la gestión de objetivos con un enfoque ágil, una poderosa herramienta que puede ayudar a los equipos y a las organizaciones a tener un enfoque de trabajo orientado a resultados.
En un mundo ideal, todos los empleados de una organización, tendrían una idea clara de cómo su trabajo contribuye al propósito de la organización. Cada empleado debería saber cómo lo que hace lleva a la organización a crecer, mejorar o tener éxito en su misión. Especialmente en las grandes organizaciones, es fácil para las personas sentirse alejadas del resultado final, sin importar cuán productivas sean. Una forma de cerrar esa brecha es crear objetivos claros y descubrir formas de medir si los equipos están logrando verdaderamente no solo alcanzar los objetivos sino también conocer realmente, como cada acción que realizan contribuye o impacta verdaderamente a esto.
Es aquí donde los Okr entran en acción y dan un apoyo gigante en este propósito, al permitir que los equipos contribuyan en la definición de los objetivos, los obliga a pensar no solo en cómo avanzar para alcanzarlos, sino también en como alinear estos, a los objetivos de la organización.
Los OKR están diseñados para cambiar el modo de gestión de comando y control a uno de equipos empoderados. Si lo que se quiere es controlar lo que todos están haciendo, entonces los OKR no son la solución. Si lo que se quiere es tener micro gestión a todos, los Okr, tampoco son la respuesta. Cuando se usan correctamente, los OKR aprovechan la brillantez de un equipo y los apuntan en la dirección correcta. Es decir, le dan un enfoque de trabajo orientado a resultados.
Pero comenzar a trabajar bajo este sistema de gestión de objetivos e incluso dominarlos, puede ser más complicado de lo que se percibe al conocer un poco de la teoría que los explica. Es por eso, que quiero compartir contigo mi querido amigo lector, estos 10 consejos para dominar la metodología de Okr.
Tener presente los requisitos previos para la implementación. Antes de que una organización pueda establecer objetivos y resultados clave, debe cumplir con algunos requisitos previos:
Contar con patrocinio y compromiso de alto nivel. Alguien o un grupo de alto nivel en la organización necesita creer en el valor de los OKR.
Tener un propósito claro del porque se necesita implementar la metodología de los Okr, ya que así como hay que tener claro porque se debe habilitar la agilidad en la organización, hay que tener claro el porque se requiere implementar la metodología, ya que este propósito dará la luz en el camino de las decisiones que se deban tomar en cada contexto de la organización.
La organización en su conjunto necesita tener una visión clara y objetivos bien definidos.
Ya que los resultados clave dependen de los datos, «hay que instrumentar las métricas». Es decir, hay que pensar en las métricas que son críticas, tanto para el negocio como para el producto/solución en sí, sin dejar de lado el equipo. Por lo que tener clara una línea base de métricas criticas será un buen punto de partida.
Escribir siempre los KR cualitativos y los cuantitativos. Uno de los errores más comunes que la gente comete al escribir OKR, es no entender la diferencia entre los objetivos y los resultados clave. Los objetivos están diseñados para ser la hoja de ruta, por lo que deben ser de naturaleza inspiradora e idealmente aspiracional, y no deben ser cuantitativos. Mientras que los resultados clave son las métricas que permiten saber que se ha logrado ese objetivo. A menudo, los KR ayudan a definir qué significa realmente el objetivo
Tener un plan para fallar al principio. Cuando una organización o un equipo, comienza a trabajar con OKR por primera vez, es normal que por un tiempo no solo no logre dominar la metodología, sino que no logre alcanzar idóneamente los objetivos trazados o los Kr establecidos. Por lo que contemplar fallar las primeras veces, no en términos de cumplir con los objetivos establecidos, sino en términos de proponer objetivos importantes y los resultados clave correctos para cuantificarlos.
Comenzar ejecutando un piloto no una implementación Big Bang. Un piloto significa que un equipo o departamento trabajará con OKR sin transferirlo a otras partes de la organización. Si se ejecuta un piloto, se puede aprender y fracasar controladamente. Además, que iniciar con grupo o equipo permitirá que con dichas lecciones aprendidas, se prepare el camino de los siguientes grupos que lo adopten. El piloto también lo ayuda a descubrir cómo se ajustan y miden los OKR con la cultura de la empresa.
Tener claro desde el principio que No todo el mundo en la organización, necesita OKR. El objetivo de un piloto es probar los OKR con un equipo y luego tal vez implementar el programa en otros. Con eso en mente, no todos los equipos o personas necesitan OKR. Algunos solo pueden hacerlo una vez que el concepto esté firmemente establecido en la organización. Algunos tal vez nunca lo hagan.
Ciertos tipos de equipos, tienen más dificultades que otros para encontrar objetivos y resultados clave. Por ejemplo, un departamento financiero o legal. Para ellos, el éxito podría definirse como hacer negocios como siempre. Es posible que no necesariamente tengan un papel en el crecimiento o la ampliación de las ambiciones de la empresa. Si estos departamentos tienen áreas que desean mejorar, esa es otra historia, y entonces los OKR podrían tener sentido.
No implementar OKR solo por moda. Si no todos los equipos necesitan OKR, entonces ciertamente no tiene sentido obligar a todos a unirse a ellos. No es necesario extenderlos a todos los equipos para lograr uniformidad. Si cubrimos una organización y decimos ‘cada persona debe tener OKR’ o ‘cada equipo debe tener OKR’, puede que no se cumpla el propósito del porque se necesita implementar la metodología.
NO implementar OKR personales. Una de las grandes preguntas que por lo general me realizan al hablar de Okr en una organización, es que si debemos implementarlos a nivel persona. Este es un punto importante para tener en cuenta, ya que a menudo, los Okr, se confunden como una forma de controlar a las personas.
Los OKR están diseñados para cambiar el modo de gestión de comando y control a uno de equipos empoderados. Si lo que se quiere es controlar lo que todos están haciendo, entonces los OKR no son la solución. Si lo que se quiere es tener micro gestión a todos, los Okr, tampoco son la respuesta. Cuando se usan correctamente, los OKR aprovechan la brillantez de un equipo y los apuntan en la dirección correcta. Es decir, le dan un enfoque de trabajo orientado a resultados.
Los OKR no se atan a las evaluaciones de desempeño. Ya que al hacerlo, las personas establecen objetivos y resultados que saben que pueden alcanzar, en lugar de pensar en objetivos aspiracionales. Los OKR simplemente no están diseñados para estar vinculados a las evaluaciones de rendimiento. Ya que las evaluaciones de desempeño deberían basarse en lo que las personas hicieron, no en lo que no lograron. Si no lograron sus OKR, pero hicieron algunas cosas increíbles, entonces deberían ser compensados.
El progreso de los KR, debe ser monitoreado regularmente. Un gran error que comenten muchos equipos y muchas organizaciones es establecer Okr y olvidarse del seguimiento regular del avance de los KR. Hay que entender que los OKR son dinámicos, por lo que requieren revisión y monitoreo regulares para determinar el progreso y tomar las decisiones a tiempo y sobre todo basadas en datos. Otro gran error que se comete a menudo, es que cuando se aprende a escribir los OKR se suele evaluar solo si se alcanzó el éxito al final del ciclo de trabajo.
Lo más importante, tener bien claro que en el equipo ni en la organización son Google. En la actualidad, muchas personas conocen los OKR porque se implementaron en Google y se ha escrito mucho al respecto. Y piensan que porque allá funciono al hacer esto o aquello, va a ser igual en su organización. La forma en que escribe y se realiza seguimiento de los OKR en la organización, debe ser exclusiva de la organización, ya que esta tiene su propia cultura.
Hay que tener presente que no todas las empresas funcionan a la misma velocidad o tienen el mismo desarrollo de esa capacidad llamada agilidad, por lo que definir el periodo correcto para la ejecución de los Okr es propio de cada organización. Por lo que es clave entender que conseguir el ritmo adecuado para cada equipo y/o organización requiere tiempo y madurez.
Como conclusión, mi querido amigo lector, podríamos decir que los OKR pueden ayudar a los equipos y a la organización como un todo a ser más efectivos, permiten empoderan a los equipos para establecer objetivos que sean alcanzables pero ambiciosos. Y que cuando son transparentes, también pueden ayudar a todos los equipos de la organización a alinear mejor sus esfuerzos hacia los objetivos de esta. E incluso, lleva a las personas a tener más claro cómo están contribuyendo al propósito de la organización. Sin embargo, también hay que tener presente que dominarlos, no es una tarea fácil y que se requiere tener varios aspectos claros antes de empezar a implementarlos y los aquí expuestos mi querido amigo son algunos de ellos. Los cuales, espero te sirvan de base para lograr una buena implementación.
Mi querido amigo lector una vez más, gracias por tu tiempo.
Ah y porque no todo es lectura, quiero compartir contigo también, mi canal de YouTube, el cual podrás visitar y suscribirte al canal aquí. Canal en el que también estoy publicando constantemente contenido.
Saludos,
Hernán Hurtado
🚀 Executive Advisor | AI Strategy and Governance | Digital Transformation Strategy and Business Agility | AI-driven Agility | LPM, Lean Operating Models and VMO Expert
Contenido Relacionado
– SUSCRÍBETE A MI BLOG –
Y cada vez que realice una nueva publicación, recíbela al instante.
