Dirección tecnológica
Defino el rumbo, ordeno las prioridades y decido qué capacidades necesita la organización sin perder contacto con la realidad técnica.
Alberto Lara Hernández
Desde 2004 en tecnología educativa, del software a la dirección tecnológica.
Mi experiencia reúne desarrollo, arquitectura de software, liderazgo técnico, producto y dirección tecnológica en plataformas y ecosistemas de aprendizaje. Sigo entrando en el detalle —diseños, código, integraciones, despliegues e incidencias— porque una decisión de dirección solo es útil si el equipo puede construirla y la organización puede operarla.
Moodle es la plataforma con la que más he trabajado, dentro de una especialidad más amplia: tecnología educativa, plataformas de aprendizaje e inteligencia artificial aplicada.
Perfil profesional
Conecto el rumbo del producto con la arquitectura, la entrega y la operación.
He trabajado en ingeniería, arquitectura, liderazgo técnico, producto y dirección. Sigo revisando código y diseños, probando integraciones e investigando incidencias porque necesito conocer lo que el sistema permite antes de comprometer una hoja de ruta.
Qué hago
Seis responsabilidades que reúno según el alcance de cada encargo.
El título y el alcance del encargo cambian: dirección tecnológica, responsabilidad de plataforma, arquitectura o responsabilidad técnica. En todos mantengo un mismo hilo: relacionar las decisiones técnicas con las necesidades del negocio y del producto, dentro de la autoridad que corresponda en cada caso.
Liderazgo técnico
Trabajo con el equipo para aplicar las decisiones de arquitectura, mantener la calidad y mejorar la forma en que entregamos los cambios.
Arquitectura de software y nube
Defino los límites del sistema, cómo se modelan los datos y por dónde debe evolucionar la plataforma, con requisitos y comprobaciones explícitas de seguridad y observabilidad.
Dirección de proyectos tecnológicos
Ordeno el alcance, los riesgos y las dependencias, y coordino a proveedores y equipos con evidencias claras de avance.
Estrategia y producto EdTech
Defino una hoja de ruta que responda a las necesidades del producto y que el equipo pueda ejecutar y mantener.
IA aplicada al aprendizaje
En iniciativas de IA aplicada al aprendizaje, defino qué se evalúa, con qué datos y umbrales, quién autoriza las acciones y cuándo el sistema debe abstenerse o escalar.
Responsabilidades acumuladas
Cómo se ha ampliado el alcance de mi trabajo
Este esquema resume cómo, desde 2004, el trabajo se ha ampliado del código a la dirección sin abandonar la responsabilidad técnica de las etapas anteriores. Los puestos y periodos del historial profesional público están enlazados al final de la sección.
- 01Desde 2004
Construir software y resolver incidencias en producción
Empecé desarrollando funcionalidades, integraciones y procesos, y aprendiendo cómo se comporta el software cuando llegan datos incompletos, carga real e incidencias.
- 02Arquitectura
Diseñar arquitectura e integraciones
Amplié la responsabilidad hacia los límites entre sistemas, el modelo de datos, la identidad, la infraestructura y la evolución compatible de la plataforma.
- 03Liderazgo técnico
Liderar equipos y convertir criterio en calidad
Pasé de resolver mi parte a hacer explícitas las decisiones, revisar entregas, coordinar dependencias y crear prácticas que otros pudieran aplicar y comprobar.
- 04Producto y operación
Conectar producto, aprendizaje y operación
Incorporé el recorrido académico y comercial, la experiencia del usuario, la hoja de ruta y las necesidades de quienes administran y mantienen el servicio.
- 05Dirección tecnológica
Dirigir la evolución tecnológica
Hoy reúno prioridades, arquitectura, equipos, proveedores, datos, IA, infraestructura y operación para que la plataforma pueda crecer sin perder control ni capacidad de cambio.
A lo largo de esta trayectoria he alternado puestos dentro de organizaciones con encargos profesionales por cuenta propia. Lo relevante en cada etapa es la responsabilidad que asumí y el trabajo entregado, no la forma del contrato.
Consultar puestos y periodos en LinkedIn
Pruebas públicas
Registros externos que permiten comprobar mi trayectoria con Moodle.
En conjunto, documentan contribuciones al núcleo de Moodle, una presentación técnica y actividad en el foro de desarrollo asociadas a mi nombre. Cada enlace permite revisar el alcance exacto del registro.
Contribuciones al código del núcleo
El listado oficial de desarrolladores incluye mi nombre entre quienes han contribuido directamente al código de Moodle.
Comprobar en Moodle.orgMoodle como base de soluciones avanzadas
El archivo oficial conserva las diapositivas de la presentación en la que expliqué cómo usar Moodle como marco para construir soluciones avanzadas de aprendizaje digital.
Abrir la presentaciónIntervenciones en el foro de desarrollo
El archivo del foro general de desarrolladores conserva consultas técnicas publicadas bajo mi nombre sobre plantillas, restauración y desarrollo de extensiones para Moodle.
Consultar el archivoResponsabilidades en contexto
Tres síntesis de responsabilidad.
No incluyo nombres, fechas ni magnitudes que permitan identificar a las organizaciones. Por eso estas síntesis explican el tipo de responsabilidad y de entregable, pero no las presento como casos de éxito verificables ni como prueba de un resultado cuantitativo.
Producto, tecnología e infraestructura con un criterio común
- Contexto
- La hoja de ruta dependía de decisiones repartidas entre software, infraestructura, integraciones y operación.
- Mi responsabilidad
- Debía ordenar las prioridades sin comprometer la arquitectura, sobrecargar a los equipos ni poner en riesgo la continuidad del servicio.
- Decisiones
- Identifiqué las dependencias y sus responsables, revisé la hoja de ruta según la capacidad disponible y el riesgo, e incorporé las necesidades de operación a las decisiones de producto.
- Entregable
- La organización contó con un criterio documentado para priorizar el trabajo según la capacidad disponible, el riesgo y la continuidad del servicio.
Convertir problemas de negocio distintos en soluciones implementables
- Contexto
- Cada organización partía de restricciones, sistemas existentes y capacidades de equipo diferentes.
- Mi responsabilidad
- Debía diseñar una arquitectura que la organización pudiera entender y que sus equipos fueran capaces de construir.
- Decisiones
- Delimité las responsabilidades de cada sistema, definí las integraciones y los datos necesarios, y propuse un orden viable para implantar la solución.
- Entregable
- Los equipos dispusieron de un mapa de dependencias y de un plan de implantación que podían explicar y revisar.
Evolucionar el LMS como parte de un ecosistema
- Contexto
- Moodle debía convivir con identidad, contenidos, sistemas corporativos, datos, infraestructura y procesos de negocio.
- Mi responsabilidad
- Debía evitar que cada nueva necesidad terminara dentro del LMS, combinando arquitectura, coordinación de equipos y conocimiento de la plataforma.
- Decisiones
- Separé responsabilidades, definí contratos de integración y planifiqué la evolución de manera compatible con la operación diaria.
- Entregable
- El diseño delimitó qué responsabilidades permanecían en Moodle y cuáles correspondían a los sistemas externos, y definió las integraciones mediante contratos compatibles con la operación diaria.
Lo que aporta la experiencia
Una dependencia sin responsable, el crecimiento por acumulación y una IA sin criterios de evaluación son riesgos que conviene hacer visibles pronto.
A lo largo de mi trayectoria he participado en proyectos e intervenciones sobre plataformas de aprendizaje para empresas, universidades y administraciones públicas. He intervenido en trabajos que van desde la resolución de incidencias y las integraciones hasta proyectos completos de evolución de plataformas. Aunque los contextos cambian, muchos problemas se repiten.
Convierto esas señales en preguntas verificables: quién responde de la integración, qué coste deja cada excepción, cómo se medirá una iniciativa de IA y qué evidencia permitirá revisar la decisión.
Criterio por escrito
Escribo para explicar las decisiones que suelen quedar ocultas detrás de la tecnología.
El blog es independiente de esta web. Allí desarrollo análisis sobre dirección tecnológica, liderazgo, arquitectura, Moodle, interoperabilidad, producto, inteligencia artificial y operación de plataformas de aprendizaje.
Escribo para que un responsable tecnológico pueda formular mejor un problema, reconocer un riesgo o tomar una decisión con más contexto que el que ofrece la novedad de la semana.
Ir a blog.albertolarah.comContacto profesional
Si necesitas definir o reconducir la tecnología de un producto EdTech, podemos empezar por el contexto.
Trabajo con plataformas de aprendizaje, productos EdTech, decisiones de arquitectura y equipos que necesitan aclarar su rumbo técnico.
Escríbeme