Plataforma de gestión educativa

Problema

La plataforma reunía registro de instituciones, trámites regulatorios, seguimiento jurídico, notificaciones, tableros y procesos académicos. El reto del backend era coordinar esas responsabilidades sin convertir cada cambio de un proceso en una modificación transversal difícil de seguir.

Responsabilidad

Trabajé como desarrollador Backend entre mayo de 2022 y diciembre de 2024. Participé en el diseño de microservicios, automatización de procesos académicos, normalización de código, documentación de rutas y flujos, y despliegues de prueba y producción.

El caso se limita a esas responsabilidades. No publica la organización, las instituciones usuarias, datos, código, infraestructura detallada ni resultados que no pueda respaldar.

Restricciones

• Los procesos administrativos, jurídicos y académicos tenían responsabilidades distintas, pero compartían el recorrido de un trámite.
• Notificaciones y tableros dependían de cambios producidos en otros módulos.
• Los entregables debían poder verificarse en ambientes separados de prueba y producción.
• La explicación pública debía excluir reglas regulatorias y datos de las instituciones.

Decisiones relevantes

Separar por responsabilidad del proceso

El seguimiento jurídico, las notificaciones y los tableros se organizaron como servicios con responsabilidades identificables. La separación buscaba que el cambio de un proceso no obligara a interpretar nuevamente el backend completo.

Normalizar código y contratos

Se adoptaron prácticas compartidas y normalización de código para reducir diferencias accidentales entre módulos. El CV registra una contribución aproximada del 15 % al aumento de la capacidad de entrega del equipo durante este periodo, según la comparación de puntos completados por sprint.

La cifra se presenta como una estimación declarada y colectiva. No se conserva el detalle de la línea base ni de la ventana de medición, por lo que no equivale a una auditoría independiente ni a una medición de rendimiento individual.

Documentar rutas y recorridos

Las rutas de API se documentaron junto con los flujos principales del producto. El objetivo era explicar no solo qué endpoint existía, sino en qué parte del proceso intervenía.

Integrar despliegue y desarrollo

Los entregables se desplegaron en entornos Ubuntu sobre AWS para pruebas y producción. El detalle público se limita a esa superficie y no describe topología, accesos ni configuración interna.

Resultado verificable

El trabajo produjo backend para registro y trámites regulatorios, servicios de seguimiento, notificaciones y tableros, y automatización de registros académicos e inscripciones. También dejó rutas y flujos documentados y un recorrido de despliegue para prueba y producción. Dentro de ese periodo, contribuí al aumento aproximado del 15 % descrito en el CV, con puntos completados por sprint como referencia de comparación y los límites de interpretación indicados en este caso.

Aprendizaje

En una plataforma de procesos, el límite útil de un servicio sigue una responsabilidad que el equipo puede explicar. La documentación gana valor cuando conecta el contrato técnico con el recorrido operativo, y el despliegue deja de ser una tarea posterior cuando forma parte de cada entrega.