118/365 · Cuándo parar y publicar (o: cómo aprendí a soltar el gatillo sin que me temblara el dedo)

Llevo dos días escribiendo sobre el stack mínimo, sobre empezar, sobre dar los primeros pasos — y de repente me doy cuenta de que me he dejado fuera una de las preguntas que más vueltas me han dado (y que más me siguen dando, aunque ahora de otra forma): ¿cuándo paras? ¿Cuándo dejas de ajustar, de pulir, de añadir "una cosita más" y públicas de una vez?

Porque esa es la realidad del vibe coding, ¿no? Que la tentación de seguir iterando, de seguir retocando, de seguir añadiendo "mejoras" está ahí — permanente, insistente, como esa vocecilla que te dice "esto podría estar mejor, ¿verdad?". Y lo peor es que la vocecilla tiene razón: SÍ que podría estar mejor. Siempre puede estar mejor. El problema es que si le haces caso y no paras nunca... bueno, pues no publicas nunca. Y si no publicas, tu herramienta no existe para nadie más que para ti.

El mito del producto perfecto (que no existe, por cierto)

En el mundo del desarrollo hay un concepto que me parece especialmente útil para nosotros los docentes: el MVP (Minimum Viable Product, o Producto Mínimo Viable). La idea es lanzar la versión más básica de un producto que incluye solo las características esenciales necesarias para satisfacer a los primeros usuarios y validar una idea en el mercado. No se trata de lanzar algo roto o a medias — se trata de lanzar algo que FUNCIONA, aunque no tenga todos los adornos que te gustaría ponerle.

Yo empecé con EDUmind así, aunque en ese momento no sabía que tenía un nombre técnico para lo que estaba haciendo. La primera versión del EDUmind Quiz era básica — podías crear preguntas, el alumnado podía responderlas, y ya. No había estadísticas avanzadas, ni personalización de colores, ni integraciones con otras herramientas. Pero funcionaba. Y cuando mi alumnado de tercero lo probó, funcionó LO SUFICIENTE como para que yo pudiera ver si la idea tenía sentido o no.

Y aquí está la clave (Eric Ries, el que popularizó el concepto del MVP, lo tiene clarísimo): el producto mínimo viable es aquella versión de un producto nuevo que permite a un equipo recoger la máxima cantidad de aprendizaje validado sobre los usuarios con el mínimo esfuerzo. No es sobre crear productos mínimos porque sí — es sobre APRENDER lo más rápido posible si lo que estás construyendo tiene sentido para la gente que va a usarlo.

El perfeccionismo como bloqueador (mi enemigo personal)

Yo he sido — sigo siendo, de hecho — bastante perfeccionista. Y el perfeccionismo en el trabajo de diseño conduce a retrasos y rediseños interminables. Lo he vivido en mis propias carnes: hay recursos que he tenido semanas guardados en local, ajustando detalles, porque "no estaban listos". ¿Y sabes qué pasaba? Que mientras yo ajustaba el color de un botón o reescribía por tercera vez un texto de ayuda, mi alumnado seguía sin poder usar la herramienta. Estaba optimizando algo que todavía no había sido validado por sus usuarios reales.

John Hattie (sí, otra vez él — es que el tío tiene razón en demasiadas cosas) insiste mucho en la importancia del feedback temprano. Su investigación sobre el efecto tamaño nos dice que el feedback tiene uno de los impactos más altos en el aprendizaje. Pero para recibir feedback, tienes que tener algo que mostrar. Y si estás bloqueado puliendo detalles en lugar de publicar, no hay feedback posible. Es como si preparas una clase perfecta pero nunca la das porque siempre le falta "un ajuste más" — absurdo, ¿no?

Esta carga de trabajo extra es completamente prevenible si los perfeccionistas pueden aprender a compartir borradores imperfectos de forma temprana. Y esto me ha costado aprenderlo — de verdad que sí. Porque va contra todo lo que te enseñan: que tienes que presentar cosas acabadas, pulidas, impecables. Pero en el desarrollo (y en la enseñanza, también), eso es una trampa.

La regla que me funciona (casi siempre)

Después de darle vueltas durante meses (y de lanzar cosas demasiado tarde y de lanzar cosas demasiado pronto — sí, también he cometido ese error), he llegado a una regla que más o menos me funciona: cuando el tiempo y coste de hacer un cambio supera el beneficio de hacerlo, tus iteraciones están completas.

Suena muy técnico, pero es bastante práctico. Básicamente: si estás pasando dos horas ajustando un detalle que va a impactar al 3% de tus usuarios en una situación muy específica... probablemente no es el momento. Publica, recoge feedback real, y ya verás si ese detalle importa o no. Puede que descubras que nadie lo necesitaba. O puede que descubras que hay otros diez detalles más importantes que ni siquiera habías considerado.

Actualmente estoy en una fase más llana con EDUmind — todo fluye, las apps funcionan, tengo menos preocupación constante por el desarrollo porque las bases están encajadas. Pero llegar aquí no fue por esperar a tener todo perfecto antes de lanzar. Fue por lanzar rápido, iterar según lo que veía en clase, y aceptar que algunas versiones iban a ser... bueno, cutres. Y lo fueron. Pero funcionaron LO SUFICIENTE como para aprender qué necesitaba mejorar de verdad.

Publicar como acto pedagógico (no solo técnico)

Y hay algo más — algo que creo que no se habla suficiente cuando hablamos de crear herramientas educativas. Publicar, aunque sea algo imperfecto, es en sí mismo un acto pedagógico. Le estás diciendo a tu alumnado (y a ti mismo) que está bien lanzar cosas que no son perfectas. Que el proceso importa. Que iterar es parte del aprendizaje.

Carol Dweck lleva años investigando sobre la mentalidad de crecimiento (growth mindset), y una de las claves es precisamente esa: ver el error, la imperfección, la versión inicial como parte del proceso, no como un fracaso. Si tú como docente te pasas meses escondiendo tu trabajo porque "todavía no está listo", ¿qué mensaje estás transmitiendo? Que solo se muestra lo perfecto. Que el proceso se oculta. Y eso, pedagógicamente, es un desastre.

El diseño iterativo en educación es un proceso dinámico que implica desarrollar, probar y refinar experiencias de aprendizaje, y al recoger feedback de los estudiantes durante cada fase, los educadores pueden identificar fortalezas y debilidades en sus materiales, asegurando que el producto final sea efectivo, atractivo y alineado con los objetivos de aprendizaje. No es solo para el desarrollo de software — es para TODO lo que hacemos en educación.

Entonces, ¿cuándo publico?

Mi checklist mental (nada científico, pero me funciona) es más o menos así:

¿Resuelve el problema principal para el que lo creaste? Si la respuesta es sí — aunque sea de forma básica — puedes publicar. Si tu herramienta iba a ayudar al alumnado a practicar las tablas y lo hace (aunque no tenga gráficos bonitos), funciona.

¿Está roto o solo es mejorable? Hay una diferencia enorme. Si algo no funciona — se cuelga, pierde datos, genera errores — no publiques. Pero si funciona y solo le faltan "extras", adelante. Los extras pueden venir después.

¿Has probado con usuarios reales? Aunque sea con tres alumnos en un recreo. Aunque sea con un compañero. Si nadie más que tú lo ha visto, todavía no sabes si funciona de verdad.

¿Te da vergüenza publicarlo? Buena señal. En serio. Si te da un poco de vergüenza porque "podría estar mejor", probablemente es el momento perfecto para lanzarlo. Si estás súper orgulloso porque es perfecto, igual te has pasado de pulir.

Ahora mismo, con el ecosistema EDUmind rodando (el EDUmind Motor, la EDUmind App, EDUmind Motion...), sigo iterando — pero desde otra posición. Ya no estoy en modo "construir desde cero", sino en modo "ajustar según uso real". Y eso solo fue posible porque en su momento publiqué versiones que no eran perfectas. Versiones que, si soy honesto, me daba un poco de corte mostrar. Pero que funcionaron.

Así que si estás en esa fase donde llevas semanas (o meses) dándole vueltas a algo que has creado, pregúntate: ¿estoy mejorándolo de verdad o solo estoy retrasando el momento de soltarlo? Porque a veces, soltar es la mejor forma de mejorar.

Mañana seguimos. Con algo que probablemente no esté perfecto cuando lo publique. Como debe ser.