Skip to main content

Feedback 07-03-2025

Logo FisioFind

FISIO FIND - FEEDBACK 07-03-2025

ÍNDICE

Ficha del documento

  • Nombre del Proyecto: FISIO FIND

  • Número de Grupo: Grupo 6

  • Entregable: #SPRINT 1

  • Miembros del grupo: Alberto Carmona Sicre, Antonio Macías Ferrera, Benjamín Ignacio Maureira Flores, Francisco Capote García, Daniel Alors Romero, Daniel Fernández Caballero, Daniel Ruiz López, Daniel Tortorici Bartús, Daniel Vela Camacho, Delfín Santana Rubio, Guadalupe Ridruejo Pineda, Julen Redondo Pacheco, Miguel Encina Martínez, Francisco Mateos Villarejo, Pablo Fernández Pérez, Ramón Gavira Sánchez, Rafael Pulido Cifuentes.

  • Contribuidores: Alberto Carmona Sicre (revisor), Delfín Santana Rubio (autor), Daniel Vela Camacho (autor)

  • Fecha de Creación: 11/03/2025

  • Versión: v1.2

Histórico de Modificaciones

FechaVersiónRealizada porDescripción de los cambios
11/03/2025v1.0Alberto Carmona SicrePrimera versión del documento
11/03/2025v1.1Alberto Carmona SicreCorreción de pequeños detalles
13/03/2025v1.2Alberto Carmona SicreAñadido aclaraciones de profesores que faltaban

1. RESUMEN DEL FEEDBACK POR GRUPO

Primer grupo (Holos):​

Feedback alumnos

  • No se entiende la parte de que se limite para siempre sobre el plan de negocio.
    • Al final parece que sí se había explicado.

Feedback recibido (resumen de los comentarios de los profesores)

  • La demo no se ve bien.

  • En la diapositiva 8, para ver mejor los costes, se deberían desglosar más tanto el CapEx como el OpEx.

  • Son necesarios los gastos e ingresos para poder ver cuándo la app es rentable.

  • Se debe mejorar y entender que se necesita tiempo para hacer un buen vídeo de la demo.

  • Empezar por las lecciones aprendidas es como empezar por el final, quizás sería más apropiado comentar el desarrollo del sprint.

  • Ya no hace falta hablar de riesgos, sino de problemas.

  • Habría que poner un punto más específico sobre el uso de la IA (prompts).

  • Habría que poner el cumplimiento del Acuerdo de compromiso.

  • Hay que hacer ejercicios de vocalización.

  • Quizás se podría integrar una IA generativa para que ayude en el proceso creativo, pero hay que preguntar a los usuarios pilotos.

  • La rentabilidad debería ser mencionada mediante análisis exhaustivo del volumen de mercado.

  • El chat no parece que sea una funcionalidad core.

  • El burn-up parece que está mal por cómo aparece.

  • El Product Backlog debería estar casi completo desde el comienzo.

Puntos positivos destacados

  • La presentación ha ido mejorando semana a semana.

  • Tienen una diapositiva específica sobre lecciones aprendidas.

  • Muy bien el niko niko.

Áreas de mejora sugeridas

  • Dedicar más tiempo a la demo.

  • Realizar ejercicios de vocalización.

  • Posible integración de IA regenerativa.

Segundo grupo (Gastrostock):​

  • Han mejorado en los usuarios piloto respecto a la última presentación.

  • Quizás en la tabla de competidores los iconos no se entienden.

  • Los mockups y explicar el MVP quizás sobra.

  • Los precios no están con Ks o Ms.

  • No han inlcuido información sobre demos.

Feedback alumnos:

  • Pregunta sobre proveedores en los mockups.

  • Lo del TPV.

    • Según los usuarios piloto, no parece útil una aplicación que no esté en un TPV.

Feedback recibido (resumen de los comentarios de los profesores)

  • No ha habido por falta de tiempo.

Puntos positivos destacados

  • Intencionalmente en blanco.

Áreas de mejora sugeridas

  • Intencionalmente en blanco.

Tercer grupo (Eventbride):​

Feedback alumnos

  • Felicitar el vídeo inicial.

Feedback recibido (resumen de los comentarios de los profesores)

  • El inicio efectivo es bueno y malo: es actual, llama la atencion y es fácil de relacionar con la app, pero se termina de forma poco profesional. Hay que intentar aproximar la formalidad con la coloquialidad.

  • Se han abordado todos los puntos. Sin embargo, han hablado muy rápido.

  • Muy bueno que han dicho si se ha cumplido el Acuerdo de Compromiso. HAY QUE DECIRLO AUNQUE ESTÉ ANONIMIZADO (PCTR, etc).

  • La demo hay que revisarla (zoom).

  • No incluyen información sobre el seguimiento de los problemas.

  • En algunas diapositivas, no se ve bien la letra (quizás es un problema de fuente).

  • La diapositiva con los calendarios, en vez de poner varios calendarios quizás poner solo la fecha porque no se ven bien los calendarios.

  • Hay que tener en cuenta los aspectos legales de la aplicación.

  • Los usuarios piloto deberían ser potenciales compradores.

  • La presentación debería potenciar el discurso, no ser notas para el presentador. Se debe poner menos texto.

  • Si se usa la IA, debe trabajar más en otras cosas.

  • En caso de haber un cambio en una pull request y esté por añadirse, es importante que se comente que ya se ha creado una pull request.

  • Reforzar el uso de las metáforas visuales.

Puntos positivos destacados

  • Han dicho cuándo alguien ha sido clave para una entrega.

  • Comentar el cumplimiento del CA.

Áreas de mejora sugeridas

  • Quizás algunas diapositivas tienen demasiado código.

  • Tener en cuenta los aspectos legales.

  • Mencionar pull requests.

Cuarto grupo (BORROO):​

Feedback alumnos

  • Muy buen inicio efectivo.

  • Hay veces que han ido muy acelerados.

  • Se debería haber hecho zoom a la demo.

Feedback recibido (resumen de los comentarios de los profesores)

  • Han hablado muy rápido.

  • Inicio efectivo muy bueno pero un poco largo. Con las mascotas puede haber problemas de copyright.

  • Cuidado con las preguntas al público (por el tema de la mascota de Doraemon).

  • En los competidores, hay algunos que no parecen competidores directos. No están bien puestas las diferencias. No se ve claramente lo que se diferencia.

  • En los costes deberían meter un plan de contigencia.

  • En los costes no se deben poner todas las cifras (en vez de 1000, 1k o 1M).

  • Cuando hay un errorcillo, se debe explicar lo que ha pasado.

  • Modelo de evaluación, la diapositiva se debería mejorar el cómo se muestra.

  • No está puesto quién evalua.

  • No se sabe si se miden code smells y demás.

  • Se debería poner cómo evaluan a quienes organizan.

  • Hay diapositivas sin número de página.

  • Se debería poner la gestión de los problemas (cómo va, si está solucionado...).

  • Se deberían poner medidas para reducir lo que tardan las reuniones. La medida debería de verse "Se quiere reducir el tiempo de las reuniones en 10%".

  • Deberían de haber dedicado más tiempo a la retrospectiva y haberlo explicado mejor.

  • Poner PCTR de cuando la IA alucina.

Puntos positivos destacados

  • Inicio efectivo muy bueno, conociendo al público. Relacionado con el feedback de la presentación anterior podría haber dicho lo que les diferencia en el inicio efectivo.

  • Explican cómo se hace la evaluación interna correctamente.

  • Los problemas que han tenido se han presentado bien.

Áreas de mejora sugeridas

  • Plan de contingencia para costes.

  • Poner cómo evaluan a quienes organizan.

  • Dedicar más tiempo a la retrospectiva y explicarla mejor.

Quinto grupo (CAMYO):​

Feedback alumnos:

  • A un alumno le ha gustado el inicio efectivo intentando vender un bolígrafo.

  • Buen cambio de presentadores.

  • Han puesto muestras de la aplicación que no parecen core(login).

  • Riesgos con los que han hecho trazabilidad: dependencia backend y frontend, hay gente que no ha sido activa, adelanto en el planning, cuellos de botella.

Feedback recibido (resumen de los comentarios de los profesores)

  • No han dicho sus nombres al inicio de la presentación.

  • Lo que les diferencia de los competidores en la tabla de competidores parece haber cambiado.

  • La tabla de competidores parece no resaltar claramente en qué se diferencian de los competidores.

  • Muy buen inicio efectivo, pero se debe buscar un inicio efectivo relacionado con el tema del producto y que esté relacionado con lo que les diferencia de los competidores.

  • Usuarios piloto: han puesto el procedimiento pero necesitan las fechas (o relativo).

  • La diapositiva del equipo puede resumirse.

  • En la demo no es relevante lo que han mostrado porque han mostrado un registro y cosas por el estilo que son genéricas.

  • La tipografía no se ve desde atrás. No se ve la demo.

  • Si hay pull request de mejora se debe decir en la presentación.

  • Retrospectiva, muy bien el cómo se han mostrado las horas.

  • Se debe cambiar la forma en la que se mide la calidad. Por ejemplo, cómo miden los commits: se pueden hacer muchos commits para parecer que se trabaja mucho.

  • La gestión de la calidad puede hacerse por puntos.

  • En la retrospectiva no se mustra cómo de solucionados están los casos/problemas.

  • Hay leyendas que no se ven.

  • Diapositiva 25 (mostrar planificación): muy bien el cómo se ha mostrado.

  • Diapositiva 22 (retrospectiva): no hay suficiente apoyo visual.

  • No se ve la replanificación en la diapositiva de los sprints.

Puntos positivos destacados

  • Buen inicio efectivo interactuando con el grupo para intentar captar la atención, lo une con el elevator spitch.

  • Han tomado la anterior presentación para mejorar en las cosas que les comentaron. Por ejemplo, la diapositiva de gestión de usuarios piloto, ahora es muy buena y clara.

  • Las gráficas de productividad son muy buenas(commits, horas,etc.).

  • Diapositiva 25 (mostrar planificación): muy bien el cómo se ha mostrado.

Áreas de mejora sugeridas

  • La diapositiva del equipo puede resumirse.

  • La tipografía no se ve desde atrás.

  • La gestión de la calidad puede hacerse por puntos.

  • Si hay pull request de mejora se debe decir en la presentación.

Sexto grupo (FISIO FIND):​

Feedback alumnos

  • Demasiadas diapositivas.

  • Aumentar tamaño de algunas cosas.

  • Reducir el killer opener.

  • Felicidades por las videollamadas.

  • Pregunta si las horas son solo una persona.

  • Muy bueno el foro.

Feedback recibido (resumen de los comentarios de los profesores)

  • Inicio efectivo muy largo y no está relacionado con lo que vamos a ofrecer.

  • Los tres presentan muy bien. Antonio debería mirar a todo el mundo.

  • Se debería comentar en qué nos diferenciamos de otros. Los competidores podrian ser marcados que es DyCare/Trak de manera visual para referenciar cuando hay muchos elementos en la presentacioón.

  • Presentación autocontenida. Animaciones y elementos visuales muy buenos. Revisar el tema del color cálido de la pantalla.

  • Los costes están bien, pero deberían resumirse más y especificar la moneda (no usar 'K' si no está todo en inglés).

  • Ensayar más los costes para que queden más claro.

  • Las fotos del equipo más pequeñas. Además, menos diapositivas de los equipos porque ya se pasan de manera rápida. Aglutinar más la información.

  • Buen uso del burn up. Estamos realizando de manera correcta el análisis de rendimiento.

  • La demo debe de ser más grande.

  • Existe un problema con la falta de respuesta de la gente; no se sabe si está solucionado o no.

  • Hay que diferenciar entre problemas y riesgos. PROBABILIDAD X IMPACTO: hemos de mencionar que los problemas encontrados provienen de un determinado riesgo o no. Mejorar la manera de presentar los riesgos para que sea más cómodo.

  • No hay una trasparencia de IA en específico que contenga cómo se ha usado, entre otras cosas.

  • No parece algo positivo que se tengan solo usuarios pilotos jóvenes, con poca experiencia.

Puntos positivos destacados

  • Muy bueno el foro.

  • Muy bien los presentadores.

  • Presentación extremadamente buena.

  • Bien los costes.

  • Buen uso del burn up. Buen análisis de rendimiento.

Áreas de mejora sugeridas

  • Comentar en qué nos diferenciamos de otros.

  • Resumir costes y usar €.

  • Ensayar más los costes.

  • Información del equipomás resumida.

  • Diferenciar entre problemas y riesgos.

  • Tener en cuenta la falta de usuarios pilotos más experimentados.

2. ANÁLISIS DEL FEEDBACK

2.1. TENDENCIAS GENERALES​

Factores comunes en los comentarios de los profesores

  • Muchas presentaciones tienen problemas con el inicio efectivo, ya sea porque es demasiado largo, no está bien relacionado con el producto o no genera suficiente impacto.

  • La visualización de la demo es un problema recurrente (tamaño, zoom, claridad).

  • Hay comentarios sobre la falta de diferenciación con los competidores en varias presentaciones. Se recomienda marcar bien las diferencias.

  • La explicación de costes debe ser más clara y resumida, asegurándose de que se use la moneda correctamente.

  • En muchos casos, los usuarios piloto podrían no ser los adecuados para validar realmente el producto.

Puntos de fortaleza general en los equipos

  • En general, las presentaciones han ido mejorando semana a semana con base en el feedback recibido.

  • Algunos grupos han hecho un buen uso de herramientas como el burn-up y gráficos de productividad.

  • El uso de la IA se está considerando en varias presentaciones, aunque aún se debe mejorar su implementación y justificación.

  • Algunos grupos han logrado destacar con un inicio efectivo bien ejecutado.

Áreas de mejora recurrentes

  • Zoom en la demo para que se vea mejor lo que se está mostrando.

  • Reducir el texto en diapositivas y hacerlas más visuales.

  • Diferenciar mejor los problemas de los riesgos, aplicando probabilidad x impacto.

  • Mejorar la vocalización y el ritmo de la presentación para que sea más clara y efectiva.

  • Elegir bien los usuarios piloto para que la validación del producto sea más representativa.

2.2. COMPARACIÓN DEL FEEDBACK DE NUESTRO GRUPO VS LOS OTROS​

¿Qué estamos haciendo bien en comparación con otros?

  • Presentación visualmente atractiva y bien estructurada, con buenas animaciones y gráficos claros.

  • Muy buenos presentadores, con un desempeño sólido en la exposición.

  • Análisis de rendimiento y burn-up bien utilizados, lo que indica una buena gestión del progreso.

  • El foro ha sido una funcionalidad destacada, recibiendo felicitaciones específicas.

  • Costes bien estructurados, aunque se pueden resumir más.

¿Qué aspectos debemos mejorar respecto a los demás?

  • Reducir el killer opener para que sea más directo y relevante al producto.

  • Diferenciarnos mejor de la competencia de manera visual y clara.

  • Resumir la información del equipo y los costes, para evitar diapositivas innecesarias.

  • Mejorar la presentación de los riesgos vs. problemas, aplicando probabilidad x impacto.

  • Ampliar la variedad de usuarios piloto, incluyendo personas con más experiencia en el sector.

Discusión para la siguiente clase (evaluación).​

  • Todos los documentos deben de estar en markdown(ya estamos haciendo esto)

  • En el knowledge base report debe de aparecer todo el contenido que se contribuye.

  • La base de conocimiento debe de tener buscador.

  • No puede haber demasiada disparidad en las horas que dedica cada miembro del equipo.

  • 15 minutos de presentación.

  • Asistencia obligatoria.

  • Habrá test (con nueva píldora teorica).

Lo que se espera ver (no va a cambiar mucho):

  • Killer oppener (1 min).

  • Elevator pitch(30-45s).

  • Resumen de análisis de competidores (ir al grano).

  • Resumen de costes: TCO, CapEx y OpEx (como nosotros).

  • Retrospectiva:

    • Gastos respecto gastos esperados.

    • Estimación corto (4-6 meses) y medio plazo (1-2 año) de gastos e ingresosn (gráficos) desde ya.

    • Ingresos: justificar de dónde van a venir esos ingresos.

    • Estimaciones de tres escenarios: pesimista, optimista y esperado.

    • Análisis del rendimiento (horas trabajadas y productividad).

    • Resultados de la evaluación de calidad del software.

    • Problemas encontrados, estado, lecciones aprendidas (o global) y medición para ver si sirve el mecanismo para reducir el problema.

    • Reloj del avance del proyeco (tiempo invertido respecto del total).

  • Equipo (máximo 2 min).

  • Demo (15%): se tiene que ver con los casos de uso core.

  • Gestión usuarios piloto:

    • No hace falta decir cómo se han captado (se puede seguir captando pero no decir cómo).

    • El número y roles.

    • Importa la gestion con ellos, tiempo de respuesta, gestión de su feedback, etc.

    • Gestión de usuarios piloto respecto al sprint 2.

  • Planificacion y replanificacion para el sprint 2 y como afecta al sptrint 3.

  • Uso de IA: alucinaciones tambión, por ejemplo.

  • Última diapositiva landing page.

En cuando a documentación, guia de revisión del software. Se aumentarán las condiciones de fallo.

3. CONCLUSIONES Y OBSERVACIONES

  • Nuestra presentación es muy sólida en términos visuales y estructurales, lo que nos ha permitido transmitir la información de manera clara y atractiva. Sin embargo, debemos reducir la cantidad de diapositivas y resumir mejor ciertos apartados, como el equipo y los costes.

  • El inicio efectivo necesita ser más conciso y estar mejor alineado con el producto para generar un impacto más directo y relevante. Otros grupos han logrado este equilibrio de manera más efectiva.

  • La diferenciación con los competidores debe ser más clara y visual. Aunque se menciona en la presentación, es importante que sea evidente y fácil de identificar para el público.

  • Nuestra demo ha sido valorada positivamente, pero se sugiere hacerla más grande para facilitar la visualización. Este es un problema común en casi todos los grupos, por lo que debemos asegurarnos de corregirlo.

  • El análisis de rendimiento con el burn-up ha sido bien recibido, lo que indica que estamos haciendo un buen seguimiento del progreso y la productividad del equipo.

  • El problema con la falta de respuesta de los usuarios debe ser tratado de manera más clara. Podríamos implementar métricas o mecanismos para evaluar el grado de satisfacción y compromiso de los usuarios piloto.

  • Se sugiere ampliar la diversidad de usuarios piloto, ya que actualmente contamos con un perfil mayormente joven y con poca experiencia. Incluir perfiles más experimentados podría aportar una validación más realista del producto.

Aprobado por:
Scrum Master: Antonio Macías Ferrera
Secretario: Alberto Carmona Sicre