119/365 · La regla del 80/20 (o: por qué el último 20% te va a costar el 80% de tu cordura)
Descubre la regla del 80/20 en desarrollo: por qué el último 20% del trabajo consume el 80% de tu esfuerzo y cómo evitar la frustración.
Escribía ayer sobre cuándo parar y publicar, y mientras lo hacía me daba cuenta de que había algo que me estaba dejando en el tintero — algo que está justo debajo de esa pregunta del "cuándo publico" y que es, probablemente, una de las cosas que más me han ayudado a no volverme loco con el desarrollo: entender que el último 20% del trabajo te va a costar el 80% del esfuerzo. Y que, muchas veces, ese último 20% ni siquiera es necesario.
Esto en el mundo del desarrollo se conoce como la regla del 80/20 (o principio de Pareto, si queremos ponernos técnicos), y básicamente dice que el 80% de los resultados vienen del 20% del esfuerzo. O dicho de otra forma: puedes conseguir que algo funcione y sea útil con relativamente poco trabajo — pero pulirlo hasta que brille te va a consumir una cantidad desproporcionada de tiempo y energía.
Y yo lo he vivido. Vaya si lo he vivido.
El momento en que descubres que estás puliendo aire
Cuando empecé con el EDUmind Quiz, la versión inicial me llevó... no sé, ¿dos semanas? Puede que tres, trabajando ratos sueltos. Era básica: crear preguntas, que el alumnado respondiera, ver resultados. Funcionaba. Mi alumnado de tercero la usó, les sirvió, punto. Eso era el 80% del valor con el 20% del esfuerzo.
Luego vino la fase de "vamos a mejorar esto". Y ahí empecé a meterme en ajustes: que si personalizar los colores de las tarjetas, que si añadir animaciones cuando aciertas, que si opciones avanzadas de configuración para tipos de pregunta muy específicos. Y de repente, cada pequeña mejora me llevaba HORAS. Días, incluso. Estaba en esa fase donde cambiar el comportamiento de un botón en un caso muy concreto me consumía una tarde entera de pruebas.
¿Y sabes qué? Cuando lo publiqué con esos ajustes, nadie — literalmente, nadie — me comentó nada sobre esas mejoras. Porque desde el punto de vista del usuario (mi alumnado, mis compañeros), el valor ya estaba en la versión básica. El resto era ruido. Ruido que a mí me había costado un montón de esfuerzo.
Por qué pasa esto (y por qué nos enganchamos igual)
Hay algo en la psicología del perfeccionismo que John Sweller explica bastante bien con su teoría de la carga cognitiva. Sweller habla de cómo nuestro cerebro tiene una capacidad limitada para procesar información, y cuando sobrecargamos esa capacidad con cosas innecesarias (carga cognitiva extrínseca), el aprendizaje se resiente. Bueno, pues con el desarrollo pasa algo parecido: cuando te enganchas en los detalles del último 20%, estás sobrecargando TU capacidad cognitiva con cosas que, objetivamente, aportan poco valor.
Pero seguimos haciéndolo. ¿Por qué? Porque psicológicamente es MÁS FÁCIL pulir detalles que enfrentarte a la incertidumbre de publicar. Es más cómodo ajustar el tamaño de una fuente que preguntarte si tu herramienta realmente resuelve el problema para el que la creaste. Es procrastinación disfrazada de productividad — y es una trampa en la que caemos todos (yo el primero).
Investigaciones sobre procrastinación productiva muestran que muchas personas se enfocan en tareas menores para evitar las más importantes y desafiantes. Y eso es exactamente lo que pasa cuando te quedas atascado en ese último 20%: estás evitando el momento de soltar el proyecto, de exponerlo al mundo real, de recibir feedback que igual no te gusta.
Cómo aplicar el 80/20 sin que se te caiga el invento
Vale, entonces la teoría está clara: céntrate en el 20% del trabajo que te da el 80% del valor. Pero en la práctica, ¿cómo narices sabes qué es ese 20%? Porque no viene con una etiqueta que diga "esto sí importa" y "esto es perder el tiempo".
Lo que a mí me ha funcionado (con más aciertos que fallos, aunque fallos también he tenido) es hacerme estas preguntas ANTES de empezar a trabajar en algo:
Si solo pudiera implementar UNA cosa, ¿cuál sería? Esto te obliga a priorizar de verdad. En el caso del Quiz, era poder crear preguntas y que el alumnado las respondiera. Todo lo demás era secundario.
¿Esto lo necesita mi alumnado o lo necesito yo? Porque muchas veces añadimos cosas que a nosotros nos parecen importantes pero que, en el día a día del aula, son irrelevantes. Un compañero una vez me dijo: "Luis, tu alumnado tiene ocho años, les da igual el degradado del botón". Y tenía razón.
¿Cuánto tiempo voy a invertir vs. cuánta gente se va a beneficiar? Si vas a pasar cinco horas en algo que va a usar el 2% de tus usuarios en una situación muy específica... probablemente no es prioridad.
Y aquí viene la parte difícil (para mí, al menos): aceptar que vas a dejar cosas sin hacer. Que tu herramienta NO va a tener todas las funciones que te gustaría. Que va a haber casos de uso que no vas a cubrir. Y que está BIEN. Porque como decía ayer, siempre puede estar mejor — pero "mejor" no siempre significa "más útil".
El lado pedagógico de la cosa (que siempre hay uno)
Y esto, claro, tiene una lectura pedagógica enorme. Porque si nosotros como docentes nos obsesionamos con el último 20% de nuestras herramientas, ¿qué mensaje estamos transmitiendo a nuestro alumnado sobre el proceso de creación?
Dylan Wiliam, que ha investigado un montón sobre evaluación formativa y feedback, insiste en que uno de los errores más comunes en educación es invertir demasiado tiempo en aspectos superficiales (presentación, formato, estética) y poco en los aspectos profundos (comprensión, aplicación, transferencia). Y con las herramientas pasa lo mismo: podemos pasarnos semanas ajustando la interfaz y descuidar si realmente la herramienta facilita el aprendizaje.
Carol Dweck lo tiene claro también: la mentalidad de crecimiento implica valorar el esfuerzo y el progreso, no la perfección. Si le transmites a tu alumnado que solo se muestra lo perfecto, estás fomentando una mentalidad fija — esa que dice "o lo hago perfecto o no lo muestro". Y eso es justo lo contrario de lo que queremos enseñar.
Así que cuando lanzas una herramienta que funciona pero que no es perfecta, estás modelando algo muy valioso: que el progreso es mejor que la perfección. Que iterar es parte del proceso. Que lo importante es que resuelva un problema real, no que tenga todos los adornos posibles.
Dónde estoy yo ahora con esto
Ahora mismo, con todo el ecosistema EDUmind (el Motor, la App, Motion...), sigo aplicando esto — aunque reconozco que a veces me cuesta. Hay días que me pica el gusanillo de "voy a añadir esto que sería útil" y tengo que frenarme y preguntarme: ¿es útil de verdad o es el 20% que me va a costar el 80% del esfuerzo?
Porque la tentación siempre está ahí. Siempre hay "una cosa más" que podría mejorar. Pero he aprendido (a base de pasarme tardes enteras ajustando cosas que luego nadie usaba) que el tiempo es limitado. Y que si me lo gasto puliendo el último 20%, no me queda para crear cosas nuevas, para probar ideas distintas, para experimentar con mi alumnado.
Y al final, ¿qué es más valioso? ¿Tener una herramienta perfecta que tardó seis meses en salir, o tener cinco herramientas funcionales que mi alumnado ya está usando? Para mí, la respuesta es bastante clara. Y por eso, cuando me veo entrando en modo "voy a pulir esto hasta que brille", intento recordarme: el brillo no enseña. La utilidad, sí.
Si estás desarrollando algo (o si estás pensando en hacerlo), pregúntate dónde está TU 80/20. Qué es lo esencial, lo que de verdad necesita tu alumnado, lo que resuelve el problema. Y si te descubres ajustando detalles que solo importan a ti... igual es hora de publicar.
Nos vemos mañana — con algo que, seguramente, podría estar más pulido pero que va a funcionar igual.