Tiempo de lectura aproximado: 10 min (depende de cuanto consiga hacerte pensar)

En el mundo de las empresas y de la productividad, cada cierto tiempo nace una nueva metodología o aparece un nuevo concepto que se pone de moda. En cierto modo es algo lógico. Si la forma actual de hacer las cosas no funciona, tiene sentido que busquemos mejores formas de proceder. Con los tecnicismos también sucede algo parecido: cuando una palabra, frase o concepto deja de tener impacto, aparece otra que la sustituye.

Recuerdo cuando empecé a hacer SCRUM, allá por el 2005, que se utilizaba mucho la metáfora de cerdos y gallinas para identificar qué personas estaban comprometidas con el proyecto, y que personas solo estaban involucradas en el proyecto (y las consecuencias de todo esto). Os dejo una viñeta que os resultará familiar a los conocedores de esta metodología, que ilustra muy bien el concepto.

Después de unos años bastante desconectado de la comunidad, ahora que he vuelto a cotillear un poco por aquí para ver qué cosas han cambiado, me encuentro con frecuencia con un término que nunca había escuchado: “skin in the game”. Aunque el significado era bastante evidente, me puse a investigar un poco y vi que tenía su origen en un libro de Nassim Nicholas Taleb: “Skin in the Game: Hidden Asymmetries in Daily Life”. Todavía no he leído el libro, y aunque es bastante probable que lo acabe leyendo porque he visto que lo ha recomendado bastante gente que considero que tienen buen criterio, así a primera vista me parece una reformulación de los cerdos y las gallinas.

Otro ejemplo sería el cambio de los KPIs a los OKRs. Yo me quedé en la época de los KPIs, y nunca me gustaron mucho más allá de la teoría. Por poner un poco de contexto os dejo aquí las diferencias según perplexity

La principal diferencia entre KPI (Key Performance Indicators) y OKR (Objectives and Key Results) es:

  • Los KPI se enfocan en medir el rendimiento y el progreso hacia objetivos específicos, mientras que los OKR se enfocan en definir objetivos ambiciosos y medir los resultados clave para alcanzarlos.

  • Los KPI son métricas cuantitativas que permiten evaluar la eficiencia, efectividad y rentabilidad de una empresa en áreas específicas. Por ejemplo, número de leads generados, tasa de conversión del sitio web, etc.

  • Los OKR se componen de un objetivo cualitativo y resultados clave (KRs) cuantitativos que miden el progreso hacia ese objetivo. Los OKR tienden a ser más ambiciosos y se actualizan con más frecuencia que los KPI.

  • Mientras que los KPI buscan un resultado positivo, los OKR pueden tener resultados mixtos, ya que un OKR muy fácil de alcanzar no sería lo suficientemente ambicioso.

  • Los KPI suelen permanecer estables a lo largo del tiempo, mientras que los OKR se modifican con mayor frecuencia para adaptarse a los cambios.

En resumen, los KPI miden el rendimiento actual, mientras que los OKR definen objetivos ambiciosos y miden los resultados clave para alcanzarlos. Ambos enfoques son complementarios y pueden usarse juntos para una gestión efectiva del desempeño organizacional.

No digo que sean lo mismo ni que antes se utilizaran unos más que otros. Es mi percepción, pero no soy ningún experto en la materia (aunque investigando un poco si veo que los KPIs son anteriores a los OKRs, y últimamente escucho más hablar de los segundos que de los primeros). El problema es que, para mí, ambos son iguales. Iguales no en cuento a significado, si no que ambos tienen los mismos fallos y funcionaran mejor o peor en base a la mayor o menor ocurrencia de estos. Ambos son definiciones que dependen, y mucho, de la interpretación que se haga de los mismos. Por intentar aterrizarlo en un lenguaje sencillo; al final depende de lo que decidas medir, y de cómo lo midas, que tenga o no sentido y sea o no útil. Y es esto último, esa subjetividad, la que me lleva de vuelta al tema de las metodologías.

Antes de las metodologías ágiles se utilizaban principalmente metodologías en cascada (waterfall). Resumiendo mucho, las metodologías en cascada intentaban planificar los proyectos de principio a fin, mientras que las metodologías ágiles hacían esa planificación de forma iterativa rompiendo el proyecto en piezas más pequeñas, permitiendo así una mejor adaptación al cambio y una mayor flexibilidad.

Si bien es cierto que personalmente las metodologías ágiles me parecen una evolución natural y necesaria, una vez más veo que el problema está en la subjetividad. Su éxito o su fracaso dependen en gran medida de cómo entiende y aplica cada uno estas metodologías, y no de la metodología en sí misma. Si decides utilizar una metodología ágil pero luego no permites que se realicen cambios, ¿qué sentido tiene?

Mi opinión es que al final todo esto no son más que formas de comunicarnos y de planificar y organizar nuestra forma de trabajar. Herramientas, al fin y al cabo. Y como herramientas que son, habrá quién las utilice mejor y quién las utilice peor. Y es ahí dónde está “la clave del éxito” y no en las herramientas en sí mismas. En las personas que utilizan dichas herramientas, y en su forma de utilizarlas. Seguro que os suena la frase de “es el indio, no la flecha” o “es el mago, no la varita”. Y por eso todas las metodologías y todos los tecnicismos están, en mi opinión, condenados al fracaso cuando se popularizan lo suficiente. Entendiendo fracaso como quedarse por debajo de las expectativas. Otro día hablaremos de la gestión de expectativas…

Veamos un ejemplo en abstracto. Algo que dice todo el mundo o una forma de trabajar que utiliza la mayoría empieza a no funcionar. Algunos, muy pocos en sus inicios, empiezan a utilizar nuevos términos y nuevas formas de hacer las cosas, y parece que les funciona. Con el tiempo y el éxito asociado empiezan a popularizarse, pero como son cosas subjetivas, al popularizarse se pervierten. Ya sea por falta de comprensión, aptitud, conocimiento, exceso de simplificación o lo que sea, al llegar a la gran masa parece que ese éxito inicial se diluye. Y entonces empezamos a criticar a esa nueva metodología o ese nuevo concepto. No funciona.

Mi opinión sobre todo esto, probablemente bastante impopular, es que cada vez es más difícil hacer cualquier cosa y que las cosas difíciles no tienen fórmulas mágicas para ser ejecutadas o implementadas con éxito. Por pura definición, no existen cosas difíciles que puedan resolverse de manera sencilla. Y esa dificultad creciente, en mi opinión debido a un aumento en la complejidad, imposibilita que una metodología (o lo que sea), por muy buena que parezca en sus inicios, mantenga ese nivel de acierto o de éxito si llega a popularizarse. Porque nacen de la necesidad de resolver problemas cada vez más complejos y eso es algo que, por pura distribución estadística, nunca podrá estar al alcance de la mayoría.

Si existe una forma de hacer las cosas que le funciona bien a la mayoría tengo bastante claro que esa forma de hacer las cosas no sirve para resolver un problema complejo.

No estoy diciendo con esto que las metodologías no sean útiles y tampoco tengo nada en contra de los tecnicismos. Es más, suelo utilizarlos con relativa frecuencia si creo que la persona con la que estoy hablando puede entenderlos de manera similar a como lo hago yo. Y he sido (y soy, aunque ahora las utilice menos por mi contexto personal) un fiel defensor de las metodologías ágiles. Pero no son recetas que cualquiera pueda utilizar o repetir. Ni por identificar un problema con un tecnicismo vas a resolverlo.

Quizá la mayor dificultad para utilizar con éxito una metodología sea saber cuándo y cómo nos va a aportar valor y, sobre todo, saber detectar y poder asumir cuándo no es conveniente utilizarla. Por mucho que nos guste y por mucho que en el pasado la hayamos utilizado con éxito. Porque muy a nuestro pesar, al menos en mi opinión, son excesivamente dependientes del equipo y del contexto de cada proyecto.

Y tampoco es todo blanco o negro. A veces si las puedes utilizar, pero tendrás que hacer ciertas adaptaciones, saltarte algunas reglas o inventarte reglas nuevas. Y eso está bien. Es más, creo que cuando tienes cierta experiencia es cuando más adaptaciones tienes que hacer, y mayor partido conseguirás sacarles. Aunque creo que antes de empezar a saltarte las reglas tienes que haberlas cumplido en diferentes ocasiones y haber entendido sus bondades y sus defectos. Como en todo, hay una fase de aprendizaje necesaria que no nos deberíamos saltar nunca.

Creo que ha llegado el momento de ir terminando con esto, al menos de momento. Y por el mismo motivo que no creo que existan recetas mágicas para los problemas complejos, tampoco existen consejos útiles para la mayoría. Aun así, me voy a permitir el lujo de dejar uno por aquí, cuya utilidad dependerá más de la interpretación que haga cada uno que del consejo en sí mismo.

Cuando estés aprendiendo una nueva metodología o escuches un término que está de moda y mole mucho, no te quedes en la definición. Intenta profundizar, entender cómo funciona, por qué funciona, cuándo funciona, y quizá también dónde y a quién, y solo entonces mira a ver qué beneficios puede ofrecerte a ti, o a tu equipo. Intenta ponerlo en práctica y no intentes correr. Con el tiempo, si lo has entendido de verdad, es posible que puedas empezar a cambiar algunas cosas para que se adapte mejor a tu contexto, de utilizar solo una parte y de hacerlo a tu manera, y obtengas beneficios por hacerlo. Tampoco esperes el mismo resultado siempre que las utilices. Como comenté hace unas líneas, esto depende mucho del contexto. Todo lo difícil, lo complejo, depende siempre del contexto.