Grupo D - AURA

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

Última actualización: 24 de febrero

1. Definición de Producto

• Enfoque de la idea principal: Hay que enfocarse en dejar clara idea principal, contextualizar las funcionalidades cores para su explicación.
• Publico objetivo y enfoque: Focalizar más en la palabra clave "herramienta" para nuestro público objetivo los guías, es lo que marcada la diferencia.
• Importancia de la IA: Al cambiar el público objetivo, la IA no es la protagonista de nuestra app, forma parte de la herramieta de trabajo que estamos creando para nuestro público objetivo.

2. Análisis de Competidores y Riesgos

• Objetividad: Realizar una comparativa real distinguiendo entre las diferentes categorias: audioguias, IA y herramientas de oficina.
• Matriz de Comparación: Simplificar el análisis a una sola diapositiva. Destacar los aspectos clave que demuestren nuestra ventaja competitiva.
• Riesgos Tecnológicos: Muy buen análisis técnologico, nos falta incluir herramientas de documentación, control de tiempo, gestor de versiones, etc.

3. Usuarios Piloto y Viabilidad

• Objetivo Cuantitativo: Alcanzar una lista de 10-12 usuarios piloto comprometidos (mínimo), idealmente más. Elaborar un plan de ampliación de usuarios pilotos.
• Gestión de Pilotos: Se requiere un plan de acción: que recoga la busqueda, la vía de comunicación, calendario de reuniones, registro de qué se les ha enseñado (mockups/demos) y feedback explícito sobre si estarían dispuestos a pagar.
• Diversidad de Perfiles: buscar pilotos por cada rol (guías freeland, empresas de tour y viajero)

4. Core Técnico y Estado del Desarrollo

Para la próxima presentación, estos puntos son de cumplimiento obligatorio :

• CI/CD Explicito: Detallar cómo se automatizará la integración y el despliegue en las 5 entregas.
• Stack y Despliegue: Claridad absoluta en las tecnologías y el entorno de hosting.
• Metodología: Explicar cómo se ha adaptado la metodología (ej. Scrum) a la realidad del grupo, sin entrar en definiciones teóricas.
• Planificación: Mostrar el estado del Sprint actual y si ha habido replanificaciones.

5. Presentación

• Imagen Corporativa: Cambiar la estética. Utilizar colores menos chillones, mejorar las transiciones en los mockups y reorganizar mejor las diapositivas para tener mejor flujo a la hora de presentar.
• Killer Opener: Crear una entrada distinta y que capte la atención del público.
• Dinámica: Mejorar el comiemzo de la presentación, incidir más en la idea y en los mockups. Seguir trabajando en la fluidez y en la gestión del tiempo.

6. Organización Interna y Compromiso

• Commitment Agreement: Mostrar de forma transparente las horas invertidas vs. estimadas por cada miembro. La desviación debe ser visible.
• Contribución al Código: Todos los miembros del equipo deben contribuir al código, se realizará de forma equilibrada si pertenece a otros grupos de trabajo.

7. Notas de clase

Semana 2 (12/02)

A nivel general:

• El proyecto tiene buena base visual y tecnológica (mockups claros y análisis de riesgos correcto).
• El principal problema es la falta de foco y la percepción de que AURA es similar a soluciones existentes.
• Se recomienda formalizar el pivot hacia un modelo B2B para guías turísticos como herramienta de productividad.
• Es necesario reducir el alcance (ciudad concreta o nicho funcional como rutas a pie) para garantizar viabilidad y diferenciación.
• La monetización actual ha sido invalidada y debe replantearse desde el valor profesional del producto.

Con respecto a la presentación:

• Falta un Killer Opener que capte la atención desde el inicio.
• Problemas de legibilidad visual (contraste en logos, tablas de competidores poco claras).
• Se debe reordenar las diapositivas: primero competidores → después mockups para contextualizar la solución.
• Falta coordinación y ensayo. La exposición debe fluir sin interrupciones.
• Integrar mejor los mockups dentro de la presentación en lugar de mostrarlos de forma aislada.

Con respecto a los competidores:

• Existe percepción de similitud con herramientas como Layla.
• Las funcionalidades actuales (navegación, tags, compartir rutas) no son suficientemente diferenciales.
• Es obligatorio justificar de forma clara por qué un usuario elegiría AURA.
• La estrategia recomendada es especializarse (nicho, ciudad o perfil profesional) para competir por foco y no por amplitud.

Con respecto a las herramientas:

• Central el foco en los riesgos que supone el uso de las herramientas.
• Herramientas: faltan añadir herramientas de documentación, gestor código, tiempo, etc. (OneDrive, Discord, Clockify...)

Con respecto a los sprints:

• El Sprint 1 debe centrarse únicamente en el core diferencial: algoritmo de generación de rutas.
• Eliminar desarrollo de elementos no críticos (login, extras, features secundarias).
• Crear un product backlog para enfocarse en el valor real del producto.
• La planificación técnica debe demostrar claramente cómo se construye la diferenciación.

Con respecto a los usuarios piloto:

• Situación crítica: no hay usuarios pilotos confirmados.
• Plan de acción: Conseguir una lista de 10–12 usuarios reales (guías), definir calendario de pruebas, establecer canales de feedback.
• La validación con usuarios es clave para demostrar viabilidad y orientar el pivot.

Semana 3 (19/02), evaluación

A nivel general:

• Lista de usuarios pilotos tiene que aparecer en la presentación.
• Todo el mundo tiene que contribuir al código.
• Análisis tecnológico: además añadir herramientas de documentos, tiempo, etc
• Integración continua: como vamos a hacer las pruebas automatizadas, etc
• Cumplir con la checkList
• Realizar una Base común de conocimiento consolidad
• Todas los miércoles disponible aulas de 14:30-15:30 prueba técnica

Con respecto a la presentación:

• Crear killer oppener diferente al de hoy, al principio de la presentación.
• Crear las diapositivas para la idea principal (mejorar el speech sobre la idea, venderla al máximo)
• Las diapositivas de mockups tienen que verse enteras al principio y crear una transición de zoom explicando el caso de uso core (Hacer algún mockup más, detallados y con personalidad)

Con respecto a los competidores:

• Competidores: reducir a solo 1 diapositiva, la tabla. Hacer hincapié en que nos diferenciamos con cada uno de los competidores.

Con respecto a las herramientas:

• Herramientas: faltan añadir herramientas de documentación, gestor código, tiempo, etc. (OneDrive, Discord, Clockify...)
• Visión muy alto nivel de la metodología ágil que vamos a usar (SCRUM), evitando definiciones. (COMO LA APLICAMOS NOSOTROS, SINO USAMOS METODOLOGIA TAMBIEN SE EXPLICA)
• ALM, Incluir CI/CD, como vamos a hacer las pruebas automatizadas, etc

Con respecto a los sprints:

• Plan de sprint: sprint 1: desglosar los casos de uso core en tareas, sprint 2 y sprint 3 de forma más general pero con el focus de la idea.
• Contar en el punto en el que estemos del sprint si vamos bien, si tenemos que dejar tareas para el otro sprint.
• Análisis de los problemas encontrados y el plan de contingencia.
• Crear la jerarquía del equipo con los roles y una imagen de cada uno enfocado sprint 1. Poner al final de la presentación.

Con respecto a los usuarios piloto:

• Listado de usuarios pilotos y plan para extenderlos.

Otro contenido:

• Análisis de alto nivel el presupuesto
• Cumplimiento del acuerdo grupal, asumimos que son 10 horas y cuanto ha hecho a la semana por persona (mirar en clockify)). Contemplar desviaciones.

Semana 4 (28/02),

A nivel general:

• La base de conomicimiento común tiene que estar dividida por categorías para su fácil uso.
• Funcionalidades sugeridas:
  • Incorporación datos útiles, curiosidad o datos adiciones a las paradas de las rutas enviadas por la IA.
  • Un chat efímero entre los turistas por si tiene que coordinar al grupo.
• Emplear un vocabulario más técnico.
• Incorporar además de pruebas unitarias, E2E y de integración.

Con respecto a la presentación:

• Presentación efectiva.
• Crear un flujo como si otra persona te estuviera preguntando.
• Cuidar la asimetrá (Colores, títulos, etc)
• Aprobechar toda el ancho de la diapositiva.
• No poner más de un titulo, innecesario poner demasiados titulos dando información que se dice hablando.
• Tablas de las lecciones aprendidas, sin título y no se ve.

Con respecto a los competidores:

• Los competidores en una sola tabla desplazable se ve bien.

Con respecto a las herramientas:

• No tenemos feedback sobre el stack tecnólogico.

Con respecto a los sprints:

• Metodología bien explicado con la infográfia utilizada, pero dar información de las PRs, nº de ramas, nº de líneas, nº de desarrolladores trabajamdo,etc.
• CI/CD muy bien. Si solo tenemos pruebas unitarias, explorar endtoend.

Con respecto a los usuarios piloto:

• En la recogida de feedback, es recomendable incluir como medios de contacto las llamadas telefónicas o reuniones, ya que generan mayor confianza. Además, a través del lenguaje no verbal y el tono de voz se obtiene información muy valiosa que no siempre se percibe en otros canales.

Con respecto a los CA:

• Commitment agreement no se visualiza correctamente, sería recomendable utilizar un diagrama de barras.
• En el diagrama de barra si no caben los nombres usar siglas.
• Se podría añadir una línea roja que indique el mínimo de horas a cumplir, así se verían claramente las desviaciones por encima y por debajo del objetivo.
• Es importante señalar si en este sprint se están cumpliendo las horas establecidas y también debe indicarse si hay desviaciones, aportar una justificación.
• Si algún miembro ha dedicado menos horas, conviene explicar en qué ha repercutido.
• Es tan importante cumplir con las horas previstas como no excederse, esto es un indica una mala estimación o un alcance mal definido.
• Crear diagramas de todo lo que llevamos trabajado hasta ahora, como el del sprint actual.

Con respecto a la Gestión de costes:

• Indicar claramente el intervalo temporal al que hace referencia el presupuesto, especificando si se trata de una estimación hasta el final del proyecto.
• Es importante diferenciar qué gastos ya son reales y cuáles son estimaciones futuras.
• El apartado de presupuesto debe estar claramente estructurado y por categorías (CAPEX Y OPEX).
• Para los costes de personal usar los costes de contratación.

Semana 5 (05/03), evaluación

Con respecto a la presentación:

• Cuidado con los accesorios que se pone en las diapositiva, están bien, pero pueden quitar el protagonismo del contenido.
• Trabajar en la energía del comienzo del inicio efectivo.

Con respecto a los sprints:

• Crear una demo en formato video, para comprobar la veracidad de lo que llevamos hecho.
• Incorporar la gestión de las pruebas.
• En la visión de la mejora continua, cuando se analizan los problemas, las lecciones aprendidas y el plan de contingencia, aportar las acciones que estamos tomando para cambiarlo y que métricas estamos usando para comprobar que se esta mejorando.

Con respecto a los usuarios piloto:

• En la recogida del feedback es importante estar abierto a cambiar el plan y el foco.
• Tener en cuenta que nos dice los usuarios pilotos, ya que podemos sacar funcionalidades nuevas que aporten valor a nuestro producto.
• Incorporar el feedback que hemos obtenido de los usuarios pilotos.

Con respecto a los CA:

• Hacer una checklist con las cosas del commitment agreetment de lo que se está cumplimento.
• Hacer una comparativa cuando se explica la evolución en hora que ha tenido un compañero por algún caso específico.
• No centrarnos solo en el cumplmiento del tiempo, sino poner otros datos como si se estan cumpliento las tareas, etc.

Con respecto a la Gestión de costes:

• Es conveniente poner grandes números no ir al céntimo.

Otros aspectos:

• Incorporar una diapositiva sobre el team building.

Semana 6 (12/03), Sprint 2

Métricas, seguimiento y lecciones aprendidas:

• Incluir porcentajes en las lecciones aprendidas para evidenciar si se están cumpliendo los objetivos.
• Definir siempre: Métrica, Umbral objetivo, Período de evaluación, Estado actual.
• Mostrar de forma sistemática si las acciones están mejorando los problemas.

Datos, gráficas y comprensión:

• Incluir gráficas de supuestos dentro del presupuesto.
• Asegurarse de que cada dato se entiende por sí solo o añadir contexto.
• No saturar con demasiada información sin tiempo para explicarla.
• Destacar y explicar claramente los puntos clave de las gráficas durante la presentación.

Presentación:

• Mejorar la gestión del tiempo.
• Eliminar el índice si no se va a utilizar.
• Trabajar los tonos de voz, especialmente en partes críticas.
• Mejorar vocalización y preparación previa.
• Diseñar un “killer opener” más llamativo.
• Apoyarse en referencias como la charla de “cómo hablar para que la gente te escuche”.

Demo:

• Cuidar las transiciones y la fluidez.
• Evitar cortar imágenes o elementos visuales.
• Centrarse en los casos de uso core.
• Eliminar el login si no aporta valor en la demo.
• Mostrar una historia clara (por ejemplo, interacción guía–turista).
• Asegurar que la demo se vea bien en todo momento.

Problemas y análisis:

• Explicar el impacto real de los problemas.
• Acompañarlos siempre de métricas.
• Analizar desviaciones de tiempo y rendimiento del equipo.
• Evaluar complejidad de tareas y grado de cumplimiento.

Presentación del sprint:

• Mejorar claridad en títulos y temporalidad.
• Mostrar: Qué se ha cumplido, Qué no, Rendimiento del equipo
• Incluir desviaciones por persona: En el sprint y En total

Análisis económico (CAPEX / OPEX):

• Profundizar más, evitando superficialidad.
• Diferenciar claramente:
• Costes de operación (OPEX)
• Costes de ejecución (CAPEX)
• Contextualizar cada cifra en el tiempo.
• Si depende de usuarios, representarlo con gráficas basadas en una fórmula definida.

Usuarios piloto:

• Enfatizar la recogida de feedback.
• Mostrar: Número de usuarios y tipo de usuarios (sin nombres)
• Definir plan de crecimiento de usuarios.
• Analizar si realmente se está llegando al público objetivo.
• Reflexionar sobre el feedback: Qué decisiones ha provocado (añadir/quitar funcionalidades)

Iteración y mejora continua:

• Implementar un sistema estructurado de mejora:
• Problema → Acción → Métrica → Umbral → Período → Estado
• Analizar si las acciones están funcionando realmente.
• Considerar el feedback como el elemento más valioso del proyecto.

Producto y casos de uso:

• Mostrar casos de uso habituales: Creación de rutas desde PC y Uso en móvil con vista personalizada
• Enfocarse en escenarios reales y relevantes.

Stack tecnológico:

• Explicarlo de forma directa y al grano.
• Evitar comparativas innecesarias.

Equipo:

• Usar fotos corporativas del equipo.
• Incluir una presentación clara del equipo.

Team building:

• Mostrar resultados del team building.

• Reflexionar si se van a aplicar cambios o no.

• Explicar el modelo y cómo está funcionando.

  Semana 7 (26/03), Evaluación

FOCO DE LA PRESENTACIÓN

• Definir una idea clara con killer opener

• Presentar el stack tecnológico a alto nivel

• Construir una demo con hilo conductor:

  • Escenario realista
  • Caso de uso concreto
  • Storytelling claro de principio a fin

• Explicar la metodología de negocio a alto nivel, resaltando solo lo diferencial

• Incluir visión de:

  • ALM
  • CI/CD
  • Más detalle en los planes de pruebas

• Mostrar resultado del sprint a alto nivel

• Realizar análisis de rendimiento del sistema

Métricas del equipo:

• Crear un análisis de rendimiento por tipo de tareas

• Incluir un grafo que correlacione rendimiento y métricas objetivas ejemplo commits

• Identificar claramente a los miembros y explicar sus siglas

• Revisar el plan de desarrollo

• Incluir problemas encontrados

• Incluir lecciones aprendidas

• Presentar usuarios piloto a alto nivel

• Explicar cómo escalar o extender el producto

• Mostrar el estado de recogida de feedback

• Explicar de forma explícita:

  • Cómo se recoge el feedback
  • Qué acciones se han tomado

NO ES FOCO PERO DEBE ESTAR

• Incluir análisis de competidores

• Incluir presupuesto CAPEX y OPEX:

  • Evolución de usuarios
  • Marco temporal
  • Coste de todos los servicios externos
  • Listado completo de servicios

• Crear storyboard de un anuncio

• Incluir CA

• Incluir team building:

  • Resultados
  • Reflexión sobre continuidad o mejora

FEEDBACK ESPECÍFICO

Estrategia y negocio

• Tener en cuenta la inversión realizada hasta ahora break-even

• Aclarar pivotaje sí o no y justificarlo

• Incluir estimación económica:

  • Coste hasta ahora
  • Coste en operación

• Explicar condiciones de estimación:

  • Hipótesis
  • Variables consideradas

Demo y entregable

• Añadir nuevo enlace a la release

• Preparar 2 vídeos:

  • Casos de uso con capítulos en YouTube
  • Vídeo narrado de ~10 minutos

• Preparar demo en directo con Zoom

• Incluir review guideline:

  • Qué feedback se recibió
  • Qué se ha implementado

Contenido y presentación

• Mantener el buen equilibrio entre imágenes y texto
• Mantener las preguntas en la presentación
• Marcar los fallos en rojo en la página 63

Presupuesto

• Incluir gastos consumidos de CAPEX y OPEX
• Revisar slide de OPEX variables:
  • Mostrar solo ejemplo o fórmula
  • O solo variables clave personas uso etc

Equipo

• Incluir evidencias de team building
• Evaluar necesidad de recursos ejemplo micrófonos en consejería

Otros ajustes

• El Excel vuelve a EV