Skip to main content

Grupo A - Rooma

En esta página se encuentra el feedback recogido por el grupo A - Rooma durante el curso. Este feedback incluye comentarios, sugerencias y recomendaciones proporcionados por el profesor y compañeros para mejorar el desempeño del grupo en futuras actividades y proyectos.

Última actualización: 29 de marzo de 2026​

1. Feedback principal (18/02), evaluación​

  • Narrativa y orden: La secuencia debe seguir un hilo natural; primero el contexto y los competidores, después el valor añadido y finalmente los detalles. Evitar “saltos” entre bloques.
  • Explicación del producto primero: Explicar Rooma antes que el equipo/desarrolladores, y no hablar del match antes de explicar qué es y cómo funciona.
  • Diapositivas autoexplicativas: Todas las diapositivas deben tener título.
  • Consistencia visual: Unificar tipografía, tamaños y formato de tablas (mismo estilo en toda la presentación).

2. Casos de uso core y mockups​

  • Punto fuerte: La presentación de los casos de uso con mockups ha sido excelente.
  • Renumeración clara: Cambiar la numeración de core a 1, 2, 3, 4 (o eliminar números si no aportan).
  • Detalle del match: Explicar criterios del match y evitar ambigüedades (ej.: no presentar el match antes de definirlo).
  • Facturas y pagos (detalle técnico): Añadir una descripción explícita de cómo se hará el reparto de facturas a nivel tecnológico.
  • Base de datos común: Se ha indicado que la base de datos común “va mal”; priorizar estabilización y plan de corrección.

3. Usuarios piloto y validación​

  • Lista obligatoria en presentación: Incluir una lista explícita de usuarios piloto y su tipo de usuario.
  • Madurez del piloto: La lista debe estar ya lista y completa; se considera que vamos tarde.
  • Objetivo mínimo: Mantener como objetivo al menos 10–12 usuarios piloto comprometidos.

4. Planificación y sprints​

  • Sprint planning con fechas: Añadir fechas a la planificación (no solo orden de tareas).
  • Enfoque en lo core: El sprint debe reflejar claramente foco en los casos core y entregables demostrables.

5. Riesgos, despliegue y CI/CD​

  • Mitigación accionable: Sustituir mitigaciones genéricas por acciones concretas (ej.: “X personas se van a formar en Y”).
  • Riesgos de despliegue: Explicar riesgos de despliegue y cómo se van a congelar/asegurar los despliegues.
  • CI/CD (crítico): Definir claramente el modelo (ramas, PRs, tests, despliegue automático), porque es clave para coordinar el trabajo del equipo.

6. Organización interna y contribución​

  • Todos desarrollan: Todo el grupo debe aportar al código; evitar comunicar que algunos miembros “solo gestionan”.

7. Propuestas de mejora (19/02)​

  • Búsqueda de piso en grupo: Posibilidad de unir varios usuarios en un “pack”/lista conjunta para una solicitud.
  • Gestión de referencias: Cartas de recomendación, nómina y contactos de otros caseros como información privada para el casero.
  • Comunicación entre caseros: Permitir que caseros contacten entre sí para pedir referencias sobre inquilinos con los que hayan tenido interacción.

8. Notas de clase​

Semana 1 (05/02)​

  • Las diapositivas deben servir de apoyo a lo que se comunica: mucho texto distrae; poco texto no es lo mismo que nada.
  • Explicar terminología que el público puede no conocer (ej.: “swipe”).

Semana 2 (12/02)​

  • Mantener coherencia visual (colores, estilos, formatos) durante toda la presentación.
  • Imágenes del equipo suficientemente grandes y explicar la organización interna del grupo.
  • En el stack tecnológico, incluir también herramientas de gestión (comunicación con pilotos, incidencias, etc.).
  • Tabla de competidores grande y legible; no juntar competidores en una misma columna (una columna por competidor).
  • Practicar la presentación para clavar tiempos.

Semana 3 (19/02), evaluación​

  • Explicar Rooma antes que los desarrolladores; todas las diapositivas con título.
  • Unificar tipografía, tamaños y formato de tablas.
  • Renumerar casos core a 1–4 (o eliminar números).
  • No hablar del match antes de explicarlo.
  • Añadir fechas al sprint planning.
  • Mitigación de riesgos con acciones concretas.

Semana 4 (26/02)​

  • Muy buena homogeneidad en la presentación con la marca corporativa.
  • Hilo conductor de la presentación confuso ya que se van dando saltos todo el rato.
  • Dar más detalle del caso de uso de los pagos.
  • En el análisis de coste distinguir bien entre CAPEX y OPEX.
  • Análisis de coste según el volumen de usuarios (usar tabla comparativa).

Semana 5 (05/03)​

  • Hilo conductor sigue sin ser coherente del todo, no atrae.
  • No presentarnos como estudiantes, somos ingenieros.
  • Diferenciar entre riesgos y problemas.
  • Justificar cómo estamos intentando solucionar los problemas y si eso está funcionando.

Semana 6 (12/03)​

  • Mejorar el killer opener para captar la atención.
  • Reducir el tiempo y el nivel de detalle en el análisis de competidores.
  • Demo directa con datos reales: eliminar inicios de sesión, mostrar solo lo clave.
  • Desglosar y detallar mucho más los gastos, incluyendo un análisis de costes con fórmulas.
  • Añadir el coste de GitHub a los gastos.

Semana 7 (26/03)​

Específico:​

  • Análisis de problemas (Crítico): Mejorar profundamente el análisis. Dar más detalles de los estados de los problemas y aportar métricas. Debe aparecer en las diapositivas y ser reforzado oralmente.
  • Gráfica de rentabilidad: Está mal calculada. No se han tenido en cuenta los gastos iniciales ni cómo evolucionan los gastos con el tiempo. Es preferible hablar de "momento en que se cubren gastos iniciales" en lugar de "ser rentables" prematuramente.
  • OPEX: En la gráfica de coste y beneficio acumulado, se deben sumar también los costes de desarrollo.

General y Próximos Pasos (S2):​

  • Software Review Guidelines:
    • Añadir sección sobre cambios realizados basados en el feedback de usuarios piloto (grupos) y el profesor revisor.
    • Incluir un segundo vídeo de 10 min con revisión exhaustiva de casos de uso (añadir marcas de tiempo en el documento).
  • Entregables: El Excel de dedicación se incluye en la entrega oficial (y opcionalmente en el repo público).
  • Stack Tecnológico: Presentación de alto nivel.
  • Casos de Uso: Deben seguir un hilo realista (ej: login -> búsqueda -> swipe -> notificación landlord -> aceptación). Prohibido usar datos de prueba tipo "Doraemon"; usar pisos y usuarios realistas.
  • ALM y Calidad: Visión de alto nivel, pero entrar en detalle en los planes de prueba.
  • Análisis de Rendimiento:
    • Para todas las tareas (desarrollo y doc).
    • Gráficos de tipo cuadrante relacionando miembros (siglas) con métricas objetivas (commits, adiciones doc, tests creados).
  • Análisis Económico: Debe incluir el avance de usuarios en el tiempo y el coste explícito de todos los servicios externos (GitHub, APIs) en un listado mensual.
  • Team Building: Incluir el modelo utilizado y los resultados obtenidos (pendiente de implementar).
  • Marketing: Ir pensando en un storyboard para un anuncio orientado a clientes.