La plataforma ha crecido a base de añadir piezas
Se han incorporado aplicaciones, proveedores e integraciones sin revisar el conjunto. Ahora cualquier cambio obliga a entender una cadena de dependencias que nadie controla del todo.
Dirección y liderazgo
Dirección tecnológicaTech Lead y liderazgo técnicoTrayectoria y perfil profesionalArquitectura y producto
Arquitectura de plataformasEstrategia y producto EdTechIntegraciones e interoperabilidadAutomatización y productividadMarcos y herramientas de decisiónProductos y proyectos propiosEspecialidad EdTech
Ecosistemas EdTechSectores y modelos B2B, B2C y B2GArquitectura de MoodleSistemas inteligentes de aprendizajeMapa de capacidades EdTechBlog técnico
Los artículos, guías y análisis viven en un sitio independiente. Esta web está dedicada a mi perfil, mi experiencia y mi trabajo.
Ir al blogAsumo la responsabilidad técnica de principio a fin: defino qué debe construirse, en qué orden y con qué medios, y respondo de que el resultado llegue a producción, se mantenga y pueda evolucionar.

Cuándo asumo la responsabilidad
Este problema aparece con frecuencia cuando crece la organización: cada proyecto resuelve su necesidad inmediata, pero nadie revisa las consecuencias para el conjunto de la plataforma. El resultado son prioridades enfrentadas, dependencias difíciles de mantener y costes que solo se descubren cuando ya resulta complicado reducirlos.
Se han incorporado aplicaciones, proveedores e integraciones sin revisar el conjunto. Ahora cualquier cambio obliga a entender una cadena de dependencias que nadie controla del todo.
La hoja de ruta sigue creciendo, pero el rendimiento, la seguridad, la calidad o la capacidad del equipo empiezan a frenar las entregas.
Hay presupuesto y actividad, pero no existe una visión conjunta de las capacidades necesarias, el orden de las iniciativas y el coste de mantenerlas.
Producto, ingeniería, datos, infraestructura y seguridad trabajan con prioridades diferentes y resuelven los mismos conflictos una y otra vez.
Se prueban modelos y proveedores, pero nadie ha acordado qué datos pueden utilizarse, cómo se evaluarán los resultados ni quién responderá cuando el sistema falle.
Las incidencias, la deuda técnica y las tareas manuales ocupan al equipo hasta el punto de que cada mejora compite con la estabilidad del servicio.
Responsabilidades concretas
Primero aclaro qué decisiones me corresponden y quién debe participar en cada una. Después ordeno las prioridades y compruebo que la arquitectura, la capacidad de los equipos y el riesgo operativo permiten llevarlas a la práctica.
Decido qué capacidades necesita la organización, qué inversiones tienen sentido y qué principios deben respetar los proyectos.
Ordeno las iniciativas por su utilidad, sus dependencias y sus riesgos. Cuando cambian las condiciones, reviso las prioridades y explico las consecuencias.
Establezco los límites, los estándares y el reparto de responsabilidades que permiten evolucionar la plataforma sin perder el control.
Contrasto el valor esperado con el esfuerzo técnico, el coste de operación y la deuda existente antes de comprometer una fecha o una solución.
Defino qué decisiones corresponden a cada equipo y conservo dentro de la organización el conocimiento imprescindible para gobernar la plataforma, también cuando intervienen proveedores.
Incluyo desde el diseño los requisitos de fiabilidad, observabilidad, seguridad, cumplimiento, coste y recuperación ante fallos.
Cómo trabajo
Mi trabajo consiste en dejar claro qué se hará ahora, qué se aplaza y qué riesgos se aceptan. Si los resultados no respaldan una decisión, la reviso antes de que el coste de cambiarla sea mayor.
Reviso cómo funciona hoy el negocio, qué producto se ofrece, cómo está construida la plataforma, quién toma cada decisión y qué problemas aparecen en la operación.
Concreto las prioridades, asigno responsables y dejo claro qué se hará ahora, qué se aplaza y qué riesgos se aceptan.
Compruebo que la hoja de ruta, la arquitectura y la capacidad de los equipos sean compatibles antes de comprometer el trabajo.
Compruebo en producción cómo se comporta cada cambio y corrijo el rumbo cuando los datos contradicen una decisión anterior.
Primeros cien días
Empezaría por conocer la plataforma y la forma de trabajar que existen de verdad, no solo las que describen los documentos. A partir de ahí, acordaría las prioridades y pondría en marcha un plan que los equipos pudieran cumplir.
Revisaría los objetivos, el producto, la arquitectura, los equipos, los contratos, los proveedores, las incidencias, la seguridad y los costes. El resultado sería un mapa comprensible de las capacidades existentes, las dependencias y los riesgos.
Reuniría a los responsables de producto, tecnología, seguridad y operación para acordar las prioridades, los criterios de inversión, los principios de arquitectura y la persona responsable de cada decisión.
Ordenaría las iniciativas en una hoja de ruta viable, resolvería las decisiones técnicas que bloquean al equipo y establecería indicadores de entrega, fiabilidad y coste para comprobar si el plan funciona.
Al cabo de esos cien días, la organización debería saber qué va a construir, por qué ha elegido ese orden, qué riesgos acepta y quién responde de cada decisión.
Experiencia y trabajo propio
Marcos propios
Estos modelos permiten que negocio, producto, tecnología y operación comparen alternativas con los mismos criterios y entiendan las consecuencias de cada decisión.
Ver la colección completaAyuda a distinguir qué iniciativas de IA están preparadas para recibir inversión y cuáles necesitan mejorar antes sus datos, su evaluación o su gobierno.
Consultar el modelo de madurez de IA aplicada a EdTech ↗Lo utilizo para ordenar la cartera y distinguir qué debe controlar la organización de aquello que puede delegar.
Consultar el mapa de capacidades EdTech ↗Proyectos propios relacionados
En estas iniciativas explico las decisiones, las alternativas descartadas y los límites encontrados. No incluyo proyectos de otras organizaciones porque están sujetos a confidencialidad.
Gobierno y operación coordinada de varias plataformas Moodle.
Ver la ficha de Gobierno de ecosistemas multi-LMS ↗Diseño documentadoCoordinación de la captación, la admisión, las convocatorias, la inscripción y la operación de los programas formativos.
Ver la ficha de Gestión integral de programas formativos ↗Blog
Allí desarrollo con más detalle cuestiones de estrategia, arquitectura, liderazgo de equipos y gobierno tecnológico.
Ir a blog.albertolarah.comContacto
Para asumir esa responsabilidad, necesito conocer qué quiere conseguir la organización, qué decisiones siguen abiertas y en qué punto se perdió el rumbo común.
Escribirme