Lidero la evolución técnica desde la arquitectura hasta el código. Convierto las necesidades funcionales en decisiones ejecutables, ordeno el trabajo y reviso el desarrollo, las integraciones, los despliegues y la operación con un criterio técnico común. Creo las condiciones para que el equipo entregue y mantenga la plataforma por su cuenta.
Criterio profesional
Cuatro diferencias que he encontrado tanto en equipos internos como en equipos de proveedores.
Una revisión que solo comprueba que la funcionalidad responde deja fuera lo esencial: qué interfaces del núcleo utiliza, cómo se comporta bajo carga, si sobrevive a una actualización y qué ocurre al restaurar una copia.
Cuando nadie del lado de la organización puede juzgar si lo entregado encaja en la plataforma completa, la arquitectura acaba siendo la suma de decisiones locales que nadie tomó a propósito.
Cuando incidencias, deuda técnica, mejora funcional y cambio estructural comparten una misma lista, lo estructural queda siempre pospuesto frente a lo urgente.
Si la plataforma funciona porque una sola persona conoce su funcionamiento, falta liderazgo técnico. El trabajo consiste en repartir ese criterio mediante revisiones explicadas, automatización y decisiones documentadas.
Dónde se concentra la complejidad
No suele nombrarse así. Se presenta como despliegues que dan miedo, actualizaciones bloqueadas o una propuesta de proveedor que el equipo no puede valorar.
Cada uno resuelve su tarea de forma razonable y aparecen patrones distintos, dependencias duplicadas y decisiones incompatibles entre sí.
No hay una definición de terminado, ni pruebas suficientes, ni trazabilidad entre cambios, ni forma de volver atrás, ni nada que observar después.
El desarrollo diario no se gobernó pensando en las interfaces públicas ni en la evolución de versión, y ahora la actualización es una reconstrucción parcial.
Se corrige la consecuencia inmediata sin análisis de causa, sin acción preventiva y sin cambiar el criterio de desarrollo que lo permitió.
Llega una estimación, una arquitectura o un desarrollo terminado y hace falta alguien capaz de revisarlo con criterio técnico y traducir el riesgo a coste y plazo.
Funciona mientras esa persona esté disponible. Nadie más conoce las decisiones, los atajos ni los sitios donde no hay que tocar.
Responsabilidades
Ocho responsabilidades. Ninguna consiste en programarlo todo yo, y ninguna consiste en repartir tareas y esperar.
Con producto, formación y operación, separar qué se configura, qué necesita desarrollo, qué corresponde a una integración, qué debe resolverse fuera de Moodle y qué no merece construirse. Descartar con argumentos lo que no merece construirse suele evitar una parte importante del coste y del mantenimiento futuros.
Que lo que se construye respete las interfaces públicas del núcleo, el modelo de extensiones, los contratos de integración, los límites entre sistemas, el modelo de datos y la compatibilidad con las actualizaciones. Una arquitectura se mantiene si alguien la aplica en cada revisión.
Revisión de código, análisis estático, estándares de la plataforma, pruebas unitarias y funcionales, pruebas de integración, seguridad, rendimiento, accesibilidad y comportamiento ante copia y restauración. Los criterios de calidad se acuerdan antes de escribir el código.
Trabajo técnico pendiente, dependencias, riesgos, definición de preparado y de terminado, versionado, estrategia de ramas, integración continua, entornos, despliegue, vuelta atrás y estabilización. El objetivo es que desplegar deje de ser un acontecimiento excepcional.
Contratos versionados, quién responde de cada dato, gestión de errores, reintentos, idempotencia, reconciliación, auditoría y observabilidad. Es el origen de buena parte de los incidentes y la capa que menos se revisa hasta que aparece uno.
Revisiones explicadas en vez de correcciones secas, programar juntos cuando hace falta, decisiones escritas, mentoría y reparto del conocimiento. Mido el resultado por lo que el equipo puede resolver de forma autónoma.
Traducir riesgo técnico a coste, plazo y consecuencia operativa. Validar estimaciones, revisar propuestas, fijar criterios de aceptación y escalar lo que está bloqueado antes de que sea tarde.
Incidencias, deuda acumulada, mejora funcional y cambio estructural compiten en la misma lista, y lo urgente desplaza siempre a lo estructural. Separarlos, ponerles consecuencia y defender un hueco fijo para lo estructural es lo que evita que dentro de tres años la plataforma vuelva a estar bloqueada.
Responsabilidades concretas
De que exista un criterio común y aplicado, de que lo entregado se pueda mantener y de que el conocimiento deje de vivir en una sola cabeza. No de escribir yo todo el código.
Un criterio común, conocido y aplicado, en lugar de tantas arquitecturas implícitas como personas haya en el equipo.
Reviso pensando en quien mantendrá el código dentro de dos años y en la actualización de versión que llegará, no solo en que la demostración funcione.
Pruebas, trazabilidad, vuelta atrás y observación posterior. La desconfianza ante un despliegue señala una carencia concreta que se puede corregir.
Causa, acción preventiva y cambio en el criterio de desarrollo. Cuando el mismo incidente se repite, reviso si el análisis identificó la causa correcta, si las acciones se ejecutaron y si los controles resultaron eficaces.
Documento las decisiones y explico las revisiones para que el conocimiento no dependa de mi disponibilidad.
Casos de uso
Lo que encontré revisando extensiones propias y de terceros, y qué cambió al gobernarlas como un conjunto.
En una plataforma con alrededor de 40 extensiones propias mantenidas por equipos y proveedores distintos, cada entrega podía introducir regresiones y cada actualización de Moodle abría un ciclo largo de revisión. El inventario interno mostraba ciclos de regresión prolongados, incidencias atribuibles a las extensiones y componentes sin un responsable claro. Parecía un problema de calidad de determinados desarrolladores, y lo descarté porque los fallos reaparecían en los mismos puntos de integración con independencia del equipo. La causa era la ausencia de estándares de extensión, propiedad definida, matriz de compatibilidad, pruebas comunes y presupuestos de rendimiento. Implanté un ciclo de vida para las extensiones, componentes compartidos, integración continua con pruebas de compatibilidad, análisis de rendimiento y criterios de retirada. Tras implantar el ciclo común se redujeron tanto el tiempo de regresión como las incidencias atribuibles a las extensiones; no publico aquí la serie, el volumen de entregas y el criterio de clasificación necesarios para cuantificar esa comparación.
En una plataforma corporativa, las sincronizaciones nocturnas con el ERP fallaban por agotamiento de memoria alrededor del 40 % del catálogo procesado. Medí el pico de memoria, el comportamiento del recolector de basura de PHP y la asignación de objetos durante la ejecución. Parecía que el límite de memoria del entorno de línea de comandos era demasiado bajo, y lo descarté porque el consumo crecía de forma lineal con cada registro y la memoria de los bloques terminados nunca se liberaba. La causa era una fuga en plugins de sincronización de terceros: el código mantenía referencias circulares a objetos globales de Moodle dentro del bucle masivo. Perfilé la ejecución hasta localizar la función responsable, reescribí el proceso para trabajar en lotes pequeños y liberé explícitamente los objetos entre ellos. También sustituí la carga completa de resultados por un cursor, que los recorría fila a fila. La tarea pasó de fallar con más de 4 GB a ejecutarse de forma estable por debajo de 128 MB y en la mitad de tiempo.
Cómo trabajo
Entiendo el punto de partida antes de proponer reglas, porque el equipo solo puede aplicar criterios ajustados a su capacidad y a sus restricciones.
Qué tiene que conseguir la organización, con qué equipo, en qué plazo y con qué no se puede contar.
Reviso la arquitectura, el código, las integraciones y la operación para ajustar las reglas a la capacidad y las restricciones reales del equipo.
Lo que solo conocían tres personas queda documentado, con la alternativa descartada y su motivo.
Una regla que no se puede verificar en una revisión o en la integración continua se queda en recomendación, y las recomendaciones acaban ignorándose.
Automatizo las comprobaciones repetibles para reservar la revisión humana a los fallos, las excepciones y las decisiones que exigen criterio. El equipo mantiene las reglas y sus umbrales, y observa lo desplegado en lugar de darlo por bueno.
El trabajo termina cuando el equipo toma por su cuenta las decisiones que al principio tomaba yo.
Marcos propios
Ayudan a que la conversación con producto y con proveedores se apoye en criterios escritos y no en la impresión de quien revisa ese día.
Ver la colección completaLista de evaluación de Alberto Lara para integraciones EdTech: responsabilidad, identidad, estándares, datos, seguridad, fiabilidad y operación.
Consultar el marco de integraciones EdTech ↗Marco de Alberto Lara para dirigir y ejecutar la automatización de procesos: resultado, proceso, datos, autonomía, operación, evidencia y responsables.
Consultar el marco de automatización de procesos ↗Trabajo propio relacionado
Documentan qué se comprueba, en qué orden y por qué. El trabajo hecho para otras organizaciones no aparece por confidencialidad.
Las reglas con las que reviso un desarrollo antes de aceptarlo.
Ver la ficha de Calidad automatizada de extensiones ↗Ingeniería y calidadCódigo, seguridad, interfaces, pruebas y entorno en una sola revisión trazable.
Ver la ficha de Auditoría técnica coordinada ↗Ingeniería y calidadInstrumentos propios para saber qué ocurre dentro de una instalación.
Ver la ficha de Herramientas de diagnóstico ↗Blog
Análisis sobre calidad de extensiones, pruebas, despliegue, revisión de proveedores y evolución de plataformas, con las fuentes y los límites de cada afirmación.
Ir a blog.albertolarah.comHablamos
A veces basta con que alguien de fuera mire lo que ya habéis decidido y diga dónde ve el riesgo. Si os sirve, escríbeme.