abbado
Un coordinador con IA para equipos universitarios. Ayuda con la parte del trabajo en grupo que nadie ve: todo lo que pasa entre recibir el enunciado y entregar.
En corto. Abbado es un coordinador con IA para trabajos en grupo universitarios, construido de punta a punta como mi TFM. Un onboarding de 4 preguntas asigna a cada estudiante un rol Belbin, el enunciado se convierte en un plan de tareas con dueños, y un facilitador con IA acompaña al equipo mientras el profesor ve salud, nunca individuos. El motor de emparejamiento está validado en una simulación de 1.000 equipos y la app lleva 656 tests automatizados detrás. Siguiente paso: un piloto en un aula real.
el problema
Los trabajos en grupo se rompen casi siempre igual. Una persona acaba cargando con todo. A los callados se les pisa y los conflictos pequeños crecen en silencio hasta que la entrega revienta.
Casi todo pasa en el tramo entre el enunciado y la entrega, cuando nadie está mirando.
research
Entrevisté a 11 estudiantes y profesores. Unos cuantos patrones se repetían:
- Silencio. La gente se calla para evitar fricción.
- Mérito robado. Las voces fuertes ganan; el trabajo silencioso desaparece.
- Trabajo invisible. Quien organiza hace más, por la misma nota.
- Un desfase de tiempo. Los conflictos empiezan pronto, pero los profesores se enteran tarde.
Los conflictos empezaban en las semanas 2 a 4, pero los profesores no se enteraban hasta las semanas 7 a 8. Ese desfase es la razón por la que abbado existe.
Tres personas resumían lo que encontré, y guiaron cada decisión que viene después:
- Montse, la organizadora. Acaba cargando con el equipo y con el trabajo invisible, y se quema por la misma nota que el resto.
- Agatha, la silenciosa. Su trabajo es sólido, pero las voces altas lo pisan. A mitad de proyecto ya ha dejado de proponer.
- Felix, el profesor. Quiere que los equipos aprendan, no vigilarlos. Se entera en la semana 8 de lo que se rompió en la semana 3.
decisiones de diseño
Visibilidad sin vigilancia. Un profesor necesita ver cómo va un equipo, pero en cuanto los estudiantes se sienten vigilados dejan de ser honestos. Así que el profesor ve la salud del equipo y nunca a la persona que hay detrás. No hay roles ni nombres propios.
- 4 preguntas, no 30. Un test corto y adaptativo te asigna un rol de equipo, en vez de un test de personalidad larguísimo.
- Salud por fechas. Mira lo que toca entregar, así un equipo que va tarde en lo que importa no puede esconderse tras un montón de logros pequeños.
- La lógica de roles es determinista. El emparejamiento funciona con reglas fijas, no con el modelo. Mismas respuestas, mismo rol, siempre, y puedes comprobar por qué.
- Un chat que conoce tu contexto. Funciona con Mistral y ya sabe tu rol y tus tareas. Facilita y se mantiene al margen del trabajo en sí, y nunca te elige el equipo.
El emparejamiento, por dentro. Las cuatro respuestas puntúan a cada estudiante en los nueve roles de equipo de Belbin, y unas reglas fijas eligen un reparto equilibrado. El motor evita además los pares que mi investigación marcó como propensos a fricción, dos de riesgo alto (un Shaper con un Completer Finisher, un Plant con un Implementer) y cinco medios. Y un límite que nunca cruza: no elige tu equipo. Tú eliges a tu gente; Abbado ayuda a que el equipo que elegiste funcione.
qué construí
Una app real y desplegada, no un mockup de Figma, con 656 tests automatizados detrás.
- 11 entrevistas detrás del diseño.
- 4 preguntas de onboarding, nueve roles Belbin.
- 1.000 equipos en la simulación de validación.
- 656 tests automatizados detrás de la app.
- Onboarding de 4 preguntas y un rol Belbin para cada estudiante.
- El enunciado partido en tareas, repartidas por perfil.
- Un dashboard en vivo con salud del equipo, avisos y el chat.
- Un informe de proceso compartido al final.
Honesta con el testing: validé la lógica de emparejamiento con una simulación de 1.000 equipos, que daba alrededor de un 60 a 70% menos de fricción. Eso es simulación, todavía no usuarios reales. Lo siguiente es un piloto en un aula real, además de Canvas y Moodle.
qué probaría a continuación
El emparejamiento está validado en simulación, pero abbado todavía no se ha usado con un equipo real de estudiantes. Ese es el límite honesto de la evidencia, así que este es el piloto de aula que haría para cerrarlo.
- 5 equipos, un proyecto cada uno. ¿Abbado mata el momento de "¿de quién es la sección 3?"? Mediría cuánto tarda cada miembro en asumir un rol y si el reparto de tareas está claro al tercer día, no una métrica de vanidad.
- La hipótesis de las semanas 2 a 4. La fricción empieza pronto pero se ve tarde. Mediría si los avisos de abbado hacen visible un problema más cerca de cuando arranca de verdad.
- La promesa de privacidad, de frente. ¿Se sintieron vistos los estudiantes sin sentirse vigilados, y tuvo el profesor señal suficiente sin monitorizar? Si los estudiantes se sienten vigilados, la apuesta central falló.
- Qué me haría cambiar de idea. Si los equipos ignoran el rol asignado, o rechazan el que les dan las cuatro preguntas, el emparejamiento necesita revisión antes que nada.
qué aprendí
La decisión de la que estoy más orgullosa fue lo que dejé fuera. La mayor parte del trabajo de diseño se me fue en decidir qué es lo que el profesor nunca llegaría a ver. La privacidad no acabó siendo una funcionalidad más. Era la respuesta al problema.
Hacerlo sola, la investigación, el diseño, la IA y el desarrollo, significa que no hay nadie a quien pasarle una decisión: cada trade-off tuvo que sobrevivir a mi propio interrogatorio. Agotador, y probablemente el mejor entrenamiento que podía pedir.
Qué cambiaría: llevaría abbado a un aula real antes, en lugar de seguir afinando la simulación. La evidencia que me falta vive con estudiantes reales, no en mis datos.