PROYECTO 01 / PRODUCTO DIGITAL
Organizar una pachanga parecía sencillo.
Hasta que dejó de serlo.
01 / EL ORIGEN DEL PROBLEMA
¿Quién juega esta semana?
Una necesidad real de organización fue evolucionando desde la coordinación manual desordenada hasta exigir lógica estructurada, memoria y una aplicación con comportamiento propio.DE PROCESO MANUAL A PRODUCTO PROPIO
Antes de escribir código hubo etapas intermedias que permitieron formalizar reglas, detectar fricciones y entender qué debía resolver realmente el producto.
Mensajes dispersos, confirmaciones cruzadas, listas copiadas y pegadas y tiempo dedicado a recordar quién había contestado primero.
Una fase esencial: permitió registrar asistencias, calcular puntos acumulados, gestionar rachas y ensayar los primeros criterios de equilibrado.
Cuando la hoja de cálculo alcanzó su límite operativo, la lógica se trasladó a una aplicación web con base de datos, API REST y control de estados.
02 / REGLAS DE NEGOCIO
Cuando intervienen personas, plazas limitadas y continuidad semanal, cada decisión sobre el partido necesita criterios objetivos y transparentes.
PLAZAS Y PRIORIDAD
Confirmar asistencia no es un «quién llega primero». El formato estándar reúne a 18 jugadores (9 contra 9), con soporte para 16 (8 contra 8).
CONTINUIDAD
Cada partido jugado suma exactamente +1 punto. La clasificación acumulada ordena a los participantes a lo largo del tiempo y sirve de base justa para dirimir la prioridad en convocatorias con alta demanda.
INCENTIVO
Para fomentar la regularidad semana a semana, el sistema aplica una regla de bonus por asistencia ininterrumpida:
03 / EQUILIBRADO DE EQUIPOS
Dos equipos descompensados arruinan la pachanga para 18 personas. El reparto se apoya en una escala de valoración manual y restricciones programadas deterministas. Lógica convencional bien diseñada: ni algoritmos opacos ni inteligencia artificial innecesaria.
ESCALA DE NIVELES MANUALES
Jugadores determinantes con mayor impacto en el ritmo.
Aportación regular y columna vertebral del juego.
Participación constante y rotación.
Rol específico y no intercambiable con jugadores de campo.
REPARTO DE REFERENCIA (FORMATO 9 vs 9)
Para cada partido de 18 jugadores, el equilibrador busca emparejar dos alineaciones que cumplan estrictamente la misma estructura:
Regla inquebrantable: exactamente un portero por equipo. El algoritmo busca minimizar la diferencia global entre conjuntos respetando las cuotas.
04 / CÓMO SE RESOLVIÓ
La solución se organizó en capas con funciones distintas. La tecnología aparece después de entender qué debía hacer el sistema.
05 / EVOLUCIÓN DE PRODUCTO
Una solución más sofisticada en teoría no es mejor si la realidad de uso la empeora. La evolución real incluye saber corregir decisiones.
Se introdujo una funcionalidad para que los propios jugadores puntuaran tras cada partido, con la idea de disponer de valoraciones dinámicas que alimentasen automáticamente el equilibrado.
En el uso real la participación fue insuficiente: muchos no votaban, las muestras quedaban incompletas y el equilibrado salía peor que con el criterio inicial, generando fricción innecesaria.
En lugar de forzar al usuario o añadir complejidad, se decidió retirar las valoraciones participativas y regresar a la valoración manual: datos 100% completos, cero fricción y mejores partidos.
06 / PRODUCTO REAL
TheGafferApp es un producto privado, operativo y utilizado semana tras semana por el grupo para el que fue construido. No es un SaaS público ni una demo comercial: sus altas se gestionan administrativamente y continúa evolucionando a partir de su uso práctico.
07 / QUÉ DEMUESTRA
SIGUIENTE / ÍNDICE
Otros problemas requieren otras decisiones.
Ver todos los proyectosHABLEMOS / SIN JERGA
No hace falta que sepas qué tecnología necesitas.
Esa parte podemos resolverla nosotros.