Cuando trabajas en un proyecto personal, nadie te dice qué toca hacer a continuación. No hay un jefe de producto priorizando un backlog, ni un cliente pidiendo una función concreta con fecha límite. Eso suena a libertad total, y lo es, pero también es la razón por la que muchos proyectos personales avanzan a saltos desordenados: hoy se retoca la interfaz, mañana se ataca una función nueva a medias, pasado se abandona ambas cosas por una tercera idea que parecía más interesante en el momento.

Con el tiempo he ido construyendo un criterio propio para decidir el siguiente paso, no perfecto, pero lo bastante consistente como para evitar ese vaivén.

Por qué "lo que más apetece" no es buen criterio

Lo que más apetece programar en un momento dado suele ser lo más nuevo o lo más vistoso, no necesariamente lo más importante. Es humano: una función nueva ofrece la ilusión de progreso visible, mientras que corregir una limitación conocida o reforzar algo que ya funciona a medias no genera esa misma sensación inmediata. Si dejo que el apetito decida siempre, el proyecto acumula funciones a medio terminar mientras las bases se quedan frágiles.

Esto no significa ignorar el interés personal por completo —un proyecto sin ninguna motivación termina abandonado igual—, sino no dejarlo como único criterio.

Los tres criterios que sí uso

Primero, impacto real sobre quien vaya a usar el proyecto, no impacto percibido por mí como desarrollador. Una mejora interna de arquitectura puede parecer importante desde dentro y ser invisible desde fuera; a veces merece la pena igual, pero lo pienso con esa distinción clara en mente.

Segundo, riesgo pendiente: si hay una limitación conocida relacionada con datos sensibles o con algo que podría fallar de forma grave, esa limitación sube en la lista aunque no sea la tarea más atractiva. Prefiero cerrar un riesgo conocido antes que sumar una función nueva sobre una base todavía frágil.

Tercero, coste de esperar. Algunas tareas se vuelven más caras de resolver cuanto más se posponen —por ejemplo, cambios de modelo de datos que afectan a más código cuanto más tiempo pasa sin abordarlos—, mientras que otras no empeoran especialmente por esperar unas semanas más. Las primeras ganan prioridad, no por urgencia aparente, sino por el coste creciente de dejarlas para después.

Ejemplo práctico

En un momento del desarrollo de mi app de mapa de pesca tenía dos frentes abiertos a la vez: mejorar la pantalla de perfil, que ya funcionaba pero se veía poco pulida, y revisar cómo se calculaba la representación pública de los puntos guardados, que tenía una limitación conocida de privacidad. Lo que más apetecía en ese momento era el perfil, porque el resultado se ve enseguida y es agradecido. Aplicando los tres criterios, la revisión de privacidad ganó: tenía más riesgo pendiente, más coste de esperar —cuantos más puntos se guardaran con el modelo antiguo, más trabajo de migración habría después— y un impacto real mayor, aunque menos vistoso, para quien fuera a confiar sus puntos a la app.

Terminé la revisión de privacidad primero, y el pulido del perfil llegó después, sin que eso supusiera ningún drama: solo un orden distinto al que habría elegido siguiendo solo el interés del momento.

Qué hago cuando dos tareas empatan en los tres criterios

No siempre hay un ganador claro. Cuando dos tareas puntúan de forma parecida en impacto, riesgo y coste de esperar, dejo que decida un cuarto factor, más pragmático: cuál de las dos puedo completar por entero en el tiempo que tengo disponible esta semana, en lugar de dejar ambas a medias. Prefiero cerrar una cosa entera que abrir dos y no terminar ninguna.

Cómo evito quedarme parado dándole vueltas a la decisión

Aplicar tres o cuatro criterios puede convertirse en su propio problema si la decisión sobre qué hacer a continuación empieza a llevar más tiempo que la propia tarea. Para evitarlo, me pongo un límite explícito: si no tengo una respuesta razonablemente clara después de pensarlo unos minutos, elijo la opción con más riesgo pendiente sin seguir dándole vueltas, porque en caso de duda prefiero equivocarme por el lado de reducir riesgo antes que por el lado de sumar una función más.

Ese límite de tiempo para decidir es tan importante como los criterios en sí. Un buen criterio de priorización que tarda una hora en aplicarse para una tarea de veinte minutos no ha ahorrado nada, solo ha cambiado de sitio el tiempo perdido.

Límites de este método

Este criterio funciona bien para decidir entre tareas ya identificadas, pero no resuelve el problema previo de detectar qué tareas deberían estar en la lista. Para eso sigo dependiendo de revisar con regularidad la documentación de limitaciones del proyecto y de prestar atención a lo que surge al usar la propia app en condiciones reales, no solo en pruebas controladas.

Conclusión

Cada pocas semanas repaso las decisiones de priorización que tomé y me pregunto si, con lo que sé ahora, habría elegido lo mismo. No para arrepentirme sin sentido de decisiones ya cerradas, sino para afinar el criterio de cara a la siguiente vez. Alguna vez he detectado que sobreestimé el riesgo pendiente de una tarea y le di prioridad de más; otras veces al revés. Ese ajuste continuo es, probablemente, más valioso que cualquiera de los criterios concretos por sí solo.

Decidir el siguiente paso de un proyecto personal sin roadmap externo no tiene por qué ser caótico si existe un criterio explícito, aunque sea sencillo. Impacto real, riesgo pendiente y coste de esperar me han funcionado mejor que dejarme llevar por lo que más apetece programar ese día, que es exactamente el criterio que menos fiable me ha resultado con el tiempo.