Descripción del Proyecto

Nombre: Sistema Web de Gestión de Horarios y Calificaciones Universitarias

Contexto: Como estudiante de Ingeniería en Sistemas y Computación, propongo desarrollar una aplicación web que permita a los estudiantes consultar horarios, ver calificaciones y recibir notificaciones sobre cambios académicos.

Objetivo: Crear una plataforma web funcional en 4 meses que mejore la comunicación entre estudiantes y administración académica.

Alcance:

1. Portal web responsive

2. Módulo de inicio de sesión

3. Visualización de horarios personalizados

4. Consulta de calificaciones por materia

5. Sistema de notificaciones por email

6. Panel administrativo básico

Equipo: 4 estudiantes (frontend, backend, base de datos, testing/documentación)

Tecnologías: React, Node.js, PostgreSQL, Git/GitHub

Fase de Planificación del Proyecto

1. Cronograma Inicial (16 semanas)

Mes 1 (Semanas 1-4): Análisis y Diseño

1. Semana 1-2: Levantamiento de requisitos, casos de uso

2. Semana 3-4: Diseño de BD, mockups UI/UX, arquitectura del sistema

Mes 2 (Semanas 5-8): Desarrollo Sprint 1

1. Backend: API REST, autenticación

2. Frontend: Login, dashboard básico

3. BD: Tablas principales

Mes 3 (Semanas 9-12): Desarrollo Sprint 2

1. Backend: Módulos de horarios y calificaciones

2. Frontend: Interfaces de consulta

3. Integración frontend-backend

Mes 4 (Semanas 13-16): Testing y Despliegue

1. Testing integral

2. Corrección de bugs

3. Documentación

4. Despliegue en servidor

Aplicación de los 4 Elementos en la Planificación

1. Manejo de Información

Información que necesito gestionar:

Información de entrada:

1. Requisitos funcionales de usuarios (estudiantes, admin)

2. Datos de ejemplo para poblar la BD

3. Documentación de tecnologías a usar

4. Feedback semanal del equipo

Información de progreso:

1. Commits diarios en GitHub

2. Reuniones semanales del equipo (daily standup adaptado)

3. Checklist de tareas en Trello/Notion

4. Métricas: % avance por módulo, bugs identificados

Información de salida:

1. Documentación técnica del sistema

2. Manual de usuario

3. Presentación final del proyecto

Plan de gestión de información:

Herramientas:

1. GitHub: Control de versiones, issues para bugs

2. Notion: Documentación, notas de reuniones

3. Trello: Seguimiento de tareas (To Do, In Progress, Done)

4. Discord/WhatsApp: Comunicación rápida del equipo

Reuniones:

1. Sincronización semanal (1 hora): revisión de avances y bloqueos

2. Revisión quincenal con el profesor/asesor: validar progreso

2. Gestión de Imprevistos

Imprevistos Supuestos (Riesgos identificados):

Riesgo Probabilidad Impacto Plan de Respuesta Un compañero abandona el equipo Media Alto Redistribuir tareas, simplificar alcance Problemas con hosting gratuito Alta Medio Tener 2 alternativas (Render, Railway) Retrasos en desarrollo de API Media Alto Priorizar endpoints críticos primero Cambio de requisitos por el profesor Baja Medio Diseño modular que permita ajustes Pérdida de código por error Baja Crítico Commits frecuentes, branches protegidos

Acciones preventivas:

1. Backup semanal del repositorio

2. Documentar APIs desde el inicio

3. Tener slack de 1 semana en el cronograma

4. Lista de recursos alternativos (tutoriales, librerías)

Ejemplo de Imprevisto Real y Respuesta:

Escenario: En la semana 7, el desarrollador de backend se enferma por 2 semanas.

Respuesta:

1. Evaluación inmediata: API de autenticación completa, pero módulo de horarios sin empezar

2. Plan de contingencia:

   1. Compañero de frontend asume backend básico (tiene conocimientos de Node.js)

   2. Se pospone sistema de notificaciones (feature no crítica) para la última semana

   3. Se usan 3 días del buffer de tiempo planificado

3. Comunicación: Informar al profesor, ajustar expectativas de la demo intermedia

4. Resultado: Recuperamos el ritmo en semana 9, entregamos con alcance levemente reducido

3. Flexibilidad en la Planificación

Cómo construyo flexibilidad:

A. Diseño Modular:

Arquitectura del sistema:
├── Autenticación (independiente)
├── Módulo Horarios (puede funcionar solo)
├── Módulo Calificaciones (puede funcionar solo)
└── Notificaciones (extra, no crítico)

Si algo falla, los módulos principales pueden funcionar de forma independiente.

B. Reservas de Tiempo:

1. Buffer por sprint: 2-3 días al final de cada mes para imprevistos

2. Semana de contingencia: Semana 15 dedicada a ajustes finales

3. Tareas opcionales: Sistema de notificaciones es "nice to have", no obligatorio

C. Tecnología Flexible:

1. Framework React permite cambiar componentes fácilmente

2. API REST es independiente del frontend

3. BD relacional permite agregar tablas sin romper lo existente

D. Roles Flexibles:

1. Cada miembro tiene una especialidad pero conoce lo básico de todo

2. Si alguien se atrasa, otro puede ayudar temporalmente

3. Pair programming para tareas complejas

Indicadores de flexibilidad:

1. Velocidad de respuesta a bugs: Meta <24 horas

2. Tiempo de integración de cambios: Nuevas features en <3 días

3. Capacidad de reasignación: Cada miembro puede cubrir 30% de tareas de otro

4. Cambio de Rumbo (Pivoting)

Escenarios que justificarían un pivot:

Escenario A: En semana 6 descubrimos que PostgreSQL es muy complejo para nuestro nivel

Decisión de Pivot:

1. Análisis: Hemos perdido 1 semana luchando con la BD

2. Alternativa: Cambiar a MongoDB (NoSQL más simple)

3. Evaluación: Perderíamos 2 días migrando lo que tenemos, pero ganaríamos velocidad

4. Decisión: PIVOT ✓ - Cambiar a MongoDB

5. Implementación:

   1. Fin de semana para migrar esquema

   2. Actualizar documentación

   3. Continuar desarrollo sin más retrasos

Escenario B: En semana 10 el profesor sugiere enfocarnos en mobile en vez de web

Decisión de NO Pivot:

1. Análisis: Ya tenemos 70% del frontend web hecho

2. Costo: Empezar desde cero en React Native

3. Beneficio: No justifica el esfuerzo a esta altura

4. Decisión: NO PIVOT ✗ - Continuar con web, agregar responsive design mejorado

5. Alternativa: Proponer mobile como Fase 2 del proyecto

Proceso de evaluación de cambio:

Criterios de decisión:

1. ¿Cuánto trabajo ya invertido se perdería? (>50% = no pivot)

2. ¿El cambio soluciona un problema real? (debe ser significativo)

3. ¿Tenemos las habilidades para la nueva dirección? (factor crítico)

4. ¿Hay tiempo suficiente para completar? (mínimo 30% del tiempo restante)

5. ¿El profesor/cliente aprueba? (necesario para validar)

Momentos clave para evaluar pivot:

1. Final de cada mes (reuniones de revisión)

2. Cuando aparece un bloqueador que dura >1 semana

3. Si la retroalimentación del asesor indica problemas fundamentales

Ejemplo de Aplicación Integrada

Situación Real (Semana 8)

Problema detectado: El servidor gratuito de Railway que planeábamos usar cambió sus políticas y ahora cobra después de 500 horas. Nuestro presupuesto es $0.

Aplicación de los 4 elementos:

1. Información

1. Detectado mediante monitoreo de noticias tech

2. Compartido inmediatamente en grupo de Discord

3. Documentado en Notion con alternativas

2. Gestión de Imprevisto (Real)

1. Clasificación: Riesgo alto-probabilidad que se materializó

2. Impacto: Bloqueador para despliegue final

3. Respuesta inmediata: Investigar 3 alternativas (Render, Vercel, Netlify)

3. Flexibilidad

1. Arquitectura preparada: Backend y frontend separados, fácil de migrar

2. Docker configurado: Facilita despliegue en cualquier plataforma

3. Tiempo disponible: Usamos 2 días del buffer de semana 8

4. Evaluación de Pivot

1. ¿Necesitamos cambiar la arquitectura? No, solo el hosting

2. ¿Cambiamos tecnología? No necesario

3. Decisión: Ajuste menor, no pivot completo

4. Acción: Migrar a Render (gratis para proyectos estudiantiles)

5. Resultado: Resuelto en 1 día, sin impacto al cronograma

Lecciones Aprendidas

Lo que funcionó:

1. El diseño modular nos salvó varias veces

2. Los buffers de tiempo fueron cruciales

3. Comunicación constante evitó sorpresas grandes

Lo que mejoraría:

1. Investigar herramientas gratuitas más profundamente desde el inicio

2. Hacer prototipos más rápidos para validar ideas

3. Documentar decisiones técnicas desde la semana 1

Conclusión: Aplicar estos principios en un proyecto universitario real me enseñó que la planificación no es rígida. Un buen plan incluye espacios para adaptarse, y saber cuándo cambiar de rumbo es tan importante como saber cuándo mantenerse firme en la dirección original.

Entregables Finales

1. Código fuente (GitHub)

2. Sistema funcionando (demo en vivo)

3. Documentación técnica (arquitectura, APIs)

4. Manual de usuario (cómo usar el sistema)

5. Presentación (15 min explicando el proyecto)

6. Este documento (reflexión sobre gestión del proyecto)