Consultor EdTech en estrategia, aprendizaje y tecnología
Durante más de 22 años he trabajado en proyectos EdTech desde tres perspectivas complementarias: la técnica, la educativa y la organizativa. He participado en decisiones sobre la financiación de proyectos y en la operación de las plataformas resultantes. Ayudo a delimitar decisiones sobre plataformas de aprendizaje, integraciones, datos, evaluación e inteligencia artificial; comparo alternativas, hago visible el coste de cada una y dejo escrito cómo se comprobará el resultado.
Dónde se concentra la complejidad
Estas decisiones no tienen por qué empezar con una herramienta. Aparecen porque dos sistemas dicen cosas distintas del mismo alumno, porque nadie recuerda por qué se configuró algo así, o porque se ha pedido inteligencia artificial sin decir sobre qué material.
Detrás de muchos síntomas hay algo más que una configuración: una decisión sobre la arquitectura, los datos o la gobernanza. El trabajo consiste en comprobar en qué nivel está el problema antes de tocar nada.
Comparo las necesidades que tendrá la organización dentro de tres años con la capacidad real de su plataforma actual. Miro el uso —qué se utiliza, cuánto y cuándo—, no solo la tabla de funcionalidades, porque ahí se ve si el problema está en la plataforma o en cómo se usa.
LTI, SCORM, xAPI o QTI aparecen en el pliego sin haber definido antes qué flujo resuelven, qué datos se intercambian y de qué proveedor se acepta depender. Reviso esas tres cosas primero: el estándar viene después, y a veces resulta que sobra.
Concreto de dónde sale lo que el sistema puede leer, qué permisos hereda de quien pregunta, cuándo tiene que abstenerse y quién revisa lo que responde. A veces el resultado es que todavía no toca, y también lo escribo.
Esos días concentran los mayores picos de concurrencia y algunas de las transacciones más críticas del trimestre. Antes de ampliar capacidad, mido la aplicación, la base de datos, las colas, el almacenamiento y las dependencias. Si el límite es la saturación de recursos, escalar puede resolverlo; si está en bloqueos o servicios externos, solo desplaza el problema.
Me encuentro con plataformas heredadas de responsables anteriores, integraciones que nunca se documentaron y permisos ampliados por una urgencia de hace años. Reconstruyo qué hay, qué depende de qué y qué se puede tocar sin que caiga otra cosa.
Un requisito sin evidencia ni criterio de aceptación se cumple sobre el papel y falla en la entrega. Escribo qué hay que exigir y cómo se comprueba, para que las ofertas se puedan poner una al lado de otra.
Mapa de especialización
Relaciono la estrategia, el aprendizaje y la operación al analizar una plataforma. Estas áreas permiten localizar qué decisión está pendiente, de qué depende y quién debe participar.
Qué papel ocupa el LMS dentro de la organización y qué se le está pidiendo que no le corresponde. Muchas peticiones de funcionalidad son en realidad una decisión de alcance que nadie ha tomado.
Estructura de categorías y cursos, roles, permisos y recorridos. Es donde más barato sale acertar y más caro sale rectificar: un modelo de permisos mal planteado se paga en cada matrícula posterior.
Diseño de cursos, actividades, itinerarios, calificación y acreditación. Es la parte que da sentido educativo a la plataforma y que más se olvida cuando la conversación se centra solo en los sistemas.
Desde una instalación única hasta varias organizaciones sobre una misma plataforma. Delimito responsabilidades, modelo los picos de carga y acuerdo con los responsables qué debe degradarse primero y qué puede apagarse sin interrumpir el servicio.
Cambios de versión y cambios de plataforma. La dificultad suele concentrarse en las extensiones de terceros sin mantenedor, las integraciones y los datos de los que depende un departamento entero.
Documento el flujo, la fuente de autoridad de cada dato, los casos de error, la responsabilidad operativa y la dependencia aceptada antes de elegir entre LTI, xAPI, API o eventos.
Extensiones, temas y automatizaciones. Cada modificación del núcleo aumenta el coste y el riesgo de actualizar: habrá que revisarla, probarla y, según la versión, adaptarla o retirarla. Por eso una parte del trabajo consiste en decidir qué no se construye.
Modelo la capacidad y preparo pruebas para los picos de matrícula y evaluación. Además, defino los objetivos de servicio, implanto o especifico la observabilidad acordada y ensayo el procedimiento de recuperación: no basta con que las copias existan, hay que haberlas restaurado.
Trato los accesos, la protección de datos, la auditoría y las responsabilidades desde el diseño. Las obligaciones concretas dependen de la jurisdicción, los datos y la finalidad, y se documentan en cada proyecto.
Delimito el material autorizado, el modelo de permisos, los criterios de abstención, la revisión humana, la evaluación y la condición de retirada. A veces la conclusión es que todavía no toca.
Una plataforma bien montada que nadie sabe usar no resuelve nada. Trabajo con los equipos técnicos, con quien da clase y con quien responde del proyecto para concretar necesidades, responsabilidades y criterios compartidos.
Proceso
Primero el enunciado, después lo que ya está montado, y solo entonces las alternativas. El orden importa: una propuesta puede estar bien ejecutada y aun así fallar si resuelve un problema que nadie había terminado de formular.
Tras la primera conversación aún no hay una recomendación: queda por escrito qué hay que decidir, quién decide y qué ocurre si nadie decide.
Reviso la configuración, las integraciones, los datos y el uso real. Ahí suelen aparecer respuestas importantes y la explicación de por qué algo que se decidió bien hace años ya no vale.
Cuando existen varias alternativas viables, comparo las necesarias y explico qué resuelve y qué deja fuera cada una. Si la elección depende de prioridades organizativas, explico los criterios y las consecuencias para que la organización decida.
Dejo una ficha por decisión: enunciado, responsable, alternativas, dependencias, evidencia disponible, criterio de aceptación, señal de revisión y plan de reversión cuando corresponde. Lo que no se puede comprobar no lo doy por resuelto.
Criterios de decisión
No los uso para puntuar herramientas, sino para que la conversación no dependa de quién habla más fuerte.
Ver la colección completaLo utilizo para asignar responsabilidades y comprobar cómo una decisión educativa afecta a plataformas, integraciones, datos, seguridad y operación.
Consultar la arquitectura del ecosistema de aprendizaje ↗Obliga a documentar el significado de los datos, los casos de error, la dependencia aceptada y la prueba con la que se dará por válida una integración.
Consultar el marco de integraciones EdTech ↗Blog
Publico el criterio con el que comparo alternativas y las decisiones que se repiten en plataformas de aprendizaje, integraciones e inteligencia artificial.
Contacto
Plataformas de aprendizaje, integraciones, datos, evaluación e inteligencia artificial se entienden mejor cuando se revisan dentro del mismo ecosistema.