Skip to main content

Reporte Base de Conocimiento

Logo FisioFind

FISIO FIND - REPORTE BASE DE CONOCIMIENTO

Í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.

  • Autores: Alberto Carmona Sicre (autor), Antonio Macías Ferrera (revisor), Delfín Santana Rubio (revisor)

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

  • Versión: v1.4

Histórico de Modificaciones

FechaVersiónRealizada porDescripción de los cambios
11/03/2025v1.0Alberto Carmona SicreCreación del informe de base de conocimiento.
12/03/2025v1.1Alberto Carmona SicreEstructuración de los puntos 3 y 4
12/03/2025v1.2Alberto Carmona SicreEstructuración de los puntos 4 y 5
12/03/2025v1.3Alberto Carmona SicreAñadir volcado de feedback
13/03/2025v1.3Antonio Macías FerreraAdecuación para la entrega
13/03/2025v1.4Delfín Santana RubioÚltimos cambios para entrega

1. INTRODUCCIÓN

La base de conocimiento ha sido desarrollada siguiendo las directrices establecidas en nuestro Acuerdo de Base de Conocimiento. Cada acción realizada ha sido regulada conforme a sus disposiciones. Añadir aqui algo de que este es el informe del sprint 1 y a lo mejor algo de las fechas en las que se ha llevado a cabo.

2. ACCESO A LA BASE DE CONOCIMIENTO

El acceso a la base de conocimiento está disponible en el siguiente enlace: FisioFind.

Para consultar la documentación, visita Documentación FisioFind. En esta sección, encontrarás un panel lateral izquierdo que muestra todos los documentos subidos.

Por otro lado, la base de conocimiento de toda la clase se encuentra en el siguiente enlace: https://bcc-three.vercel.app/

3. USO Y GESTIÓN DE LA BASE DE CONOCIMIENTO

3.2. USO Y GESTIÓN GRUPAL​

Para gestionar de manera eficiente la base de conocimiento, se ha implementado el siguiente esquema de trabajo, con una separación de responsabilidades que optimiza la eficacia del equipo al momento de elaborar y actualizar documentos de forma recurrente.

A continuación, se muestra la información correspondiente a cada punto del esquema:

3.2.1. Organización​

  • En la carpeta Organización se almacenan todos los documentos redactados relacionados con acuerdos o compromisos. Los encargados de la elaboración de estos se asignaban durante reuniones y se desarrollaban de manera conjunta, sin haber unos responsables específicos encargados de realizar todos los documentos de este tipo.

3.2.2. Planificación​

  • En la carpeta Planificación se guardan todos los documentos relacionados con la planificación del proyecto (planes, registros y costes). En este caso, la distribución sigue el mismo procedimiento: el equipo se reunía, se distribuían los documentos y se realizaban de manera colaborativa.

3.2.3. Informes​

Para mejorar la eficiencia en la documentación de informes, se estableció un grupo específico encargado de cada tipo de reporte:

  • Carpeta Informes de Tiempo: en esta sección se acumulan todos los informes de horas que el equipo dedica al trabajo de manera semanal. Para la elaboración de dichos documentos se asignaron a los compañeros Rafael Pulido y Alberto Carmona.

  • Carpeta Informes de IA: en esta sección se almacenan todos los informes dedicados a evaluar el uso de la inteligencia artificial por parte de los miembros del equipo durante cada semana de trabajo. Para la elaboración de dichos documentos se asignaron a los compañeros Daniel Ruiz y Daniel Fernández.

3.2.4. Seguimiento​

En esta sección encontramos dos subapartados: Reuniones y Sprint 1.

  • En la sección de Reuniones se guardan cada una de las actas de las reuniones realizadas. La redacción de las actas de reuniones es responsabilidad del Scrum Master, Antonío Macías, o de los Secretarios, Alberto Carmona, Delfín Santan y Daniel Vela.

  • En el otro apartado, Sprint 1, se almacenan los informes relacionados con el sprint en sí (planificación, retrospectiva, etc.). Documentos como la retrospectiva se encargaron al equipo de QA, mientras que la planificación fue responsabilidad del Scrum Master.

3.2.5. Recursos​

  • La gestión de la carpeta Recursos siguió la siguiente dinámica: los Secretarios y el Scrum Master fueron los encargados de añadir los informes de feedback, las notas sobre las píldoras teóricas y otros documentos relevantes, como el Informe de Base de Conocimiento.

3.2.6. Ideando un proyecto​

  • En la carpeta Ideando un proyecto simplemente se pueden encontrar juntos todos los documentos generados durante esta fase inicial del proyecto.

Los documentos e informes no se incluyen directamente en la base de conocimiento, sino que se van subiendo al apartado docs del repositorio oficial de código de Fisio Find, que cuenta con una estructura ampliamente parecida a la base de conocimiento, para así mantener un orden de los documentos que se van finalizando a lo largo del desarrollo. Una vez los documentos son finalizados, dos responsables, Rafael Pulido y Daniel Ruiz, se encargan de lo siguiente:

  • Se aseguran de que los documentos añadidos en el repositorio oficial de código de Fisio Find estén correctamente reflejados en la base de conocimiento.

  • También supervisan la correcta visualización de la página web asociada.

De nuevo, este esquema ha permitido optimizar la documentación, asignar responsabilidades de manera eficiente y garantizar un acceso ordenado a la información a lo largo del desarrollo del proyecto.

3.2 USO Y GESTIÓN GENERAL​

En la base de conocimiento general de la asignatura, dentro de la sección correspondiente a nuestro grupo (Grupo 6), se ha ido incorporando semanalmente el feedback recibido tanto de nuestros docentes como de nuestros compañeros. Este feedback abarca tanto la evaluación de nuestro propio grupo como la de los otros cinco grupos.

Se ha elegido al secretario Alberto Carmona como responsable de actualizar la base de conocimiento general de la asignatura.

4. CONTRIBUCIONES DEL EQUIPO

4.1. CONTRIBUCIONES A LA BASE DE CONOCIMIENTO GRUPAL​

A continuación, se muestran las contribuciones del equipo a la base de conocimiento grupal durante la elaboración del Sprint 1, dividido en las secciones: Organización, Planificación, Informes, Seguimiento y Recursos.

4.1.1. Organización​

No se han añadido nuevos documentos.

4.1.2. Planificación​

No se han añadido nuevos documentos.

4.1.3. Informes​

  • Informe de tiempo de la semana 4 (21/02/2025 - 27/02/2025).

  • Informe de tiempo de la semana 5 (28/02/2025 - 06/03/2025).

  • Informe de IA de las semanas 4 (21/02/2025 - 27/02/2025) y 5 (28/02/2025 - 06/03/2025).

4.1.4. Seguimiento​

  • Acta de reunión del día 22 de febrero de 2025.

  • Acta de reunión del día 24 de febrero de 2025.

  • Acta de reunión del día 25 de febrero de 2025.

  • Planificación del Sprint 1.

  • Retrospectiva del Sprint del grupo 1.

  • Retrospectiva del Sprint del grupo 2.

  • Retrospectiva del Sprint del grupo 3.

  • Retrospectiva del Sprint global.

4.1.5. Recursos​

  • Feedback de la clase del día 21 de febrero de 2025. En el anexo, se muestra tanto el feedback grupal como las anotaciones generales.

4.1.6. Píldoras teóricas​

No se han añadido nuevos documentos.

La información detallada de estos documentos se pueden encontrar en el segundo enlace proporcionado en la sección 2. USO Y GESTIÓN DE LA BASE DE CONOCIMIENTO.

4.2 CONTRIBUCIONES A LA BASE DE CONOCIMIENTO GENERAL​

A continuación se muestran las contribuciones a la base de conocimiento general. Cabe destacar que, para los demás grupos, el feedback es igual que el que se añade en el feedback de la base de conocimiento grupal, por lo que solo se va a añadir el feedback del grupo 6.

Semana 3​

Feedback relacionado con la presentación​

  • Los compañeros nos felicitaron por los siguientes aspectos:

    • El uso de los mockups para presentar la aplicación.

    • La herramienta interna que tenemos para calcular los costes.

    • La presentación en general.

    • El inicio afectivo.

  • En la tabla de competidores, los iconos no se entendían.

  • No se debe hacer referencia a la semana pasada.

  • En los riesgos, explicar cómo se van a mitigar (en vez de poner mitigar o evitar).

  • Poner las asignaciones de tareas y responsabilidades a los miembros del equipo.

  • Los costes no se expusieron correctamente.

  • El inicio efectivo debe ser más innovador.

La organización de la presentación no es la que indicaron los profesores.

  • Añadir la landing page al final de la presentación.

Feedback relacionado con el desarrollo del proyecto​

  • Aumentar el número de usuarios piloto.

Tareas a realizar para la siguiente semana​

  • A partir de ahora las presentaciones durarán 15 minutos.

  • Todo lo relacionado con la evaluación del rendimiento debe ser cuantitativo.

  • Los despliegues suelen dar problemas. Se debería de hacer despliegue continuo.

  • Las presentaciones a partir de ahora (los porcentajes pueden no sumar 100%):

    • Deben empezar con un 15% de introducción:

      • Killer opener.

      • Elevator pitch corto.

      • Resumen análisis de competidores.

      • Con tabla diciendo lo que nos diferencia.

      • Análisis de costes.

      • Equipo.

        • Si alguien no ha cumplido con sus tareas diciendo el porcentaje.

        • Puede ser anónimo.

        • Estructura de responsabilidades.

    • 15% de prototipo:

      • Mostrar lo que se tenga mediante capturas y vídeos.

      • Deben de ser concisas e ir al grano, mostrando lo importante.

    • 50% de retrospectiva:

      • Análisis de la calidad y productividad:

        • Análisis del rendimiento, plan de la calidad (se puede anonimizar), etc.

        • Puede ser más de una trasparencia.

      • Problemas encontrados.

      • Trazabilidad de los riesgos:

        • No se deben de repetir riesgos.

        • Lecciones aprendidas del riesgo.

      • Reloj de avance del proyecto:

        • Tiempo dedicado según lo esperado.

        • Diferencia entre tiempo dedicado y esperado.

        • Ratio de horas respecto al total.

      • Reestimación del sprint 1:

        • Objetivos finales para el sprint 1.

      • Reestimación de siguientes sprints.

    • 10% de gestión de usuarios pilotos:

      • Agenda para trabajar con ellos (días y cuándo).

      • La responsabilidad del feedback es del equipo.

      • La gestión de los usuarios pilotos es crítica.

    • Planificación para el siguiente sprint.

    • Cómo hemos usado la IA.

    • Lo que no se menciona no se pide (se puede poner pero tiene que tener una razón).

Semana 5​

Feedback relacionado con la presentación​

  • Demasiadas diapositivas.

  • 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 presentación.

  • Aumentar tamaño de algunas cosas.

  • 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.

  • 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.

  • La demo debe de ser más grande.

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

  • 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.

Feedback relacionado con el desarrollo del proyecto​

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

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

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

Tareas a realizar para la siguiente semana​

  • Reducir la cantidad de diapositivas.

  • Mejorar el inicio efectivo.

  • Mejorar el contenido de la presentación de la IA.

  • Diferenciar entre problemas y riesgos.

  • Mejorar la visualización de la demo.

5. ACCIONES TOMADAS A PARTIR DEL FEEDBACK

En esta sección se muestra un resumen de las acciones que se han tomado a partir del feedback dado. Se muestra un resumen ya que se entiende que existe un proceso de interiorización del feedback que hace que se tomen acciones de forma inconsciente. Es decir, si por ejemplo se valora mucho una presentación en concreto, lógicamente se va a intentar mejorar dicha presentación en los puntos en los que se haya dado feedback positivo. Se puede obtener un análisis mucho más detallado del feedback y de las presentaciones en los documentos de feedback de nuestra base de conocimiento.

5.1. Resumen de mejoras tras el feedback del 21/02/2025​

Tras el feedback recibido en la sesión del 21/02/2025, se tomaron medidas para mejorar aquellos aspectos de la presentación que presentaban fallos, al mismo tiempo que se reforzaron los puntos que fueron elogiados.

5.1.1. Aumento de usuarios piloto​

  • Ante la clara falta de usuarios piloto, se destinó cierto tiempo a una búsqueda más exhaustiva que permitiese tener una base mucho mayor de feedback por parte de posibles usuarios de la aplicación. Esto tuvo como resultado un aumento de fisioterapeutas de 5 a 16 con distinta experiencia, así como un aumento en pacientes de 3 a 18.

5.1.2. Tabla de competidores​

  • En el feedback del 21/02 se indicó que la tabla de competidores principales no llegaba a entenderse puesto que era demasiado abstracta. Por ello, para la siguiente presentación se actualizó la tabla para que fuese más sencillo diferenciar lo que hacíamos distinto a los demás.

5.1.3. Asignaciones de tareas y responsabilidades​

  • Aunque se expusieron los equipos y diapositivas con las distintas responsabilidades existentes, no se dejó claro quién hacía qué mediante representaciones visuales, por lo que se corrigió para la siguiente presentación con diapositivas que juntasen a los miembros con sus responsabilidades.

5.1.4. Costos​

Se nos indicó la necesidad de mejorar en la presentación de los costos. Entre las mejoras realizadas se encuentran:

  • Desglose del CapEx.
  • Desglose del OpEx.
  • Gráfica con Ingresos Acumulados, Costes Acumulados y ROI.

5.1.5. Inicio efectivo​

  • Se destacó la necesidad de innovar en el inicio efectivo, por lo que los presentadores dedicaron un tiempo mayor a idear un inicio mucho más potente.

5.1.6. Organización de la presentación​

  • Los docentes indicaron que la organización de la presentación no era la acordada, por lo que se anotaron bien los puntos para tener bien en cuenta la distribución en la siguiente presentación.

5.2. Resumen de mejoras tras el feedback del 07/03/2025​

Tras el feedback recibido en la sesión del 07/03/2025, se tomaron medidas para mejorar aquellos aspectos de la presentación que presentaban fallos, al mismo tiempo que se reforzaron los puntos que fueron elogiados.

5.2.1. Inicio efectivo​

  • se comentó que el inicio efectivo fue demasiado largo y no estaba relacionado con lo que vamos a ofrecer, por lo que se ha destinado todavía más tiempo a preparar esta parte de la presentación.

5.2.2. Diapositivas​

  • El número de diapositivas era superior a lo esperado, por lo que se tuvo en cuenta a la hora de realizar la siguiente presentación.

  • Como feedback positivo, se felicitó la presentación autocontenida, los elementos visuales y las animaciones, por lo que se seguirán utilizando en presentaciones futuras.

5.2.3. Costos​

  • Aunque los costos estaban bien expuestos, se necesitaban resumir un poco más, por lo que se tuvo en cuenta para futuras presentaciones.

5.2.4. Equipo​

  • La presentación del equipo era demasiado extensa, por lo que se tuvo en cuenta para futuras presentaciones, aglutinando la información relevante.

5.2.5. Demo​

  • La mala visualización de la demo fue una constante en todos los grupos, por lo que se realizaron zooms en la demo para que se vea mejor lo que se estaba mostrando.

5.2.6. Transparencia de IA​

  • Faltó una diapositiva dedicada a la IA, por lo que se incluyó en la siguiente presentación para comentar la manera en la que se usaba.

5.2.7. Riesgos y problemas​

  • Mejorar en la sección de riesgos y problemas según lo dicho en el feedback(diferenciar entre riesgo y problema, mejorar la trazabilidad, solo poner riesgos que han surgido, etc.).

5.2.8. Usuarios piloto​

  • A partir del feedback recibido hemos terminado el Plan de Gestión de Usuarios Piloto, en el que entre otras cosas se determinan las encuestas que se van a pasar a cada tipo de usuario. Los comentarios de los profesores nos han hecho mejorar en gestión de usuarios piloto y en cómo lo presentamos.

6. ANEXO - RESUMEN DEL FEEDBACK POR GRUPO

6.1. Clase del día 21/02/2025​

Primer grupo (Holos):​

Los compañeros felicitaron (solo dio tiempo al feedback de una persona):

  • La actitud en la presentación.

El equipo de FISIO FIND destaca también el hilo de la presentación y la forma en la que han captado la atención del público.

Feedback recibido (resumen de los comentarios de los profesores)

  • Se recomendó centrarse en las comisiones en vez de en las suscripciones y dar la opción a que los primeros envios sean gratuitos.

  • Mejorar la claridad en el apartado de los usuarios pilotos.

Puntos positivos destacados

  • Intencionalmente en blanco.

Áreas de mejora sugeridas

  • Modelo de negocio
  • Usuarios piloto

Segundo grupo (Gastrostock):​

Los compañeros han felicitado:

  • Las transiciones en la presentación.

  • La fuerza de la exposición.

  • Los colores utilizados.

  • El elevator pitch.

  • Los datos públicos de la gestión de bares.

Un aspecto positivo que no se nombró pero que el equipo de FISIO FIND quiere anotar, fue el zoom que se utilizó en las diapositivas de los mockups.

Feedback recibido (resumen de los comentarios de los profesores)

  • Se debería haber controlado mejor el tiempo de la presentación. Esto se puede conseguir con más práctica.

  • No se menciona la gestión de usuarios pilotos.

  • Las fotos estaban distorsionadas, lo que puede hacer que la presentación pierda seriedad.

  • Falta el número de página.

  • Se comentó que hubo un cambio en la organización del equipo. Se recomendó controlar cuando se hacen este tipo de cambios en la estructura ya que si se hace antes de una evaluación puede causar problemas.

  • No apareció la landing page en las diapositivas y no estaba desplegada.

  • Se deberían haber mostrado los competidores mediante una tabla.

  • Tienen muchas casos de uso core, lo que puede causar problemas.

Puntos positivos destacados

  • Intencionalmente en blanco.

Áreas de mejora sugeridas

  • Mejora en la presentación (específicamente en el tiempo de presentación, fotos de grupo y en cómo se muestran los competidores).

  • Usabilidad de la aplicación para los bares.

  • Landing page.

Tercer grupo (Eventbride):​

Los compañeros de clase felicitamos:

  • El formato y los colores de la presentación son acorde a la temática de la aplicación.

  • El apartado de costes está completo.

  • La mejora de las diapositivas respecto a los días anteriores.

  • La gestión de usuarios piloto por recompensa.

  • La gestión del uso de la IA.

  • Análisis de riesgo acertado.

Por otro lado, un aspecto que no se nombró en el feedback de los compañeros es lo bien detallado que están tanto su commitment agreement como el análisis cuantitativo de la calidad.

Feedback recibido (resumen de los comentarios de los profesores)

  • Se debería de haber practicado más la presentación.

  • Mejorar el elevator pitch.

  • Mejora en la gestión del tiempo en la presentación. Además, algunas diapositivas se han saltado demasiado rápido.

  • No han puesto la planificación de los sprints.

  • Se recomienda no poner los mockups al final y no explicar los casos de uso en una diapositiva específica si ya se hace con los mockups.

Puntos positivos destacados

  • Buen commitment agreement.

Áreas de mejora sugeridas

  • Mejora en la gestión del tiempo en la presentación.

  • Mejora en la organización de las diapositivas.

  • Mejorar el elevator pitch.

  • Dedicar más tiempo a prácticar la presentación.

Cuarto grupo (Borroo):​

Los compañeros de clase felicitamos:

  • Las animaciones en la presentación.

  • La tabla de competidores.

  • La gama de colores y el formato de la presentación.

  • Los ejemplos visuales.

  • La interacción con el público.

El equipo de FISIO FIND, además de lo anterior, ha encontrado muy interesante el cómo utilizan los términos de cancelación.

Feedback recibido (resumen de los comentarios de los profesores)

  • Mejorar en el inicio efectivo.

  • Poner la landing page al final de la presentación.

  • La organización de los sprints puede mejorarse. No está claro si aparecen los casos de uso core y si se planea implementar la funcionalidad que les diferencia de sus competidores en el último sprint, puede existe el riesgo de que al final no se implemente por problemas.

  • Hubo un pequeño error en el precio de los mockups.

  • Indicar si los costes son mensuales o anuales.

  • Indicar ratio de respuesta en encuestas de usuarios piloto.

  • Las políticas de cancelación podrían mostrarse de manera más clara.

Puntos positivos destacados

  • Intencionalmente en blanco.

Áreas de mejora sugeridas

  • Mejorar en el inicio efectivo.

  • Mejorar en la organización de los sprints.

  • Mejorar en cómo se muestran los costes.

  • Mejorar los mockups.

  • Poner la landing page al final de la presentación.

Quinto grupo (CAMYO):​

Los compañeros de clase felicitamos al equipo por la claridad de la exposición y su inicio efectivo. El equipo de FISIO FIND piensa que su gestión de usuarios piloto y su exposición de la rentabilidad es algo de lo que podrían aprender.

Feedback recibido (resumen de los comentarios de los profesores)

  • Mejorar en la gestión del tiempo de la presentación.

  • Practicar más la presentación para mejorar en la dicción y otros aspectos generales.

  • Se debe de mostrar cómo los usuarios piloto son solo para feedback. Es decir, no se pueden aprovechar para nada más.

  • Reducir el tiempo dedicado al elevator pitch.

  • En cuanto a los riesgos, mostrar el plan de contingencia como las medidas que se están tomando para que no suceda (el qué hacer si suceden se dará más adelante).

  • Planificar que en el primer sprint van a hacer todo el MVP puede ser peligroso.

  • En vez de poner los números con todas las cifras, ponerlo con Ks.

Puntos positivos destacados

  • Intencionalmente en blanco.

Áreas de mejora sugeridas

  • Mejorar en la gestión del tiempo de la presentación.

  • Mejorar el elevator pitch.

  • Mejorar la gestión de usuarios pilotos.

  • Planificar el reparto de funcionalidades en los sprints.

  • Mejorar el registro de riesgos.

  • En vez de poner los números con todas las cifras, ponerlo con Ks.

Sexto grupo (FISIO FIND):​

En general muy buena presentación. Los compañeros nos felicitaron:

  • El uso de los mockups para presentar la aplicación.

  • La herramienta interna que tenemos para calcular los costes.

  • La presentación en general.

  • El inicio efectivo.

Feedback recibido (resumen de los comentarios de los profesores)

  • Aumentar el número de usuarios piloto.

  • En la tabla de competidores los iconos pueden no entenderse.

  • No se debe hacer referencia a la semana pasada.

  • En los riesgos explicar claramente cómo se van a mitigar (en vez de poner evitar o mitigar).

  • Poner las asignaciones de tareas y responsabilidades a los miembros del equipo.

  • No se han expuesto los costes correctamente.

  • Se debe de innovar en el inicio efectivo.

  • La organización de la presentación no es la que indicaron los profesores.

Puntos positivos destacados

  • Se han destacado los mockups.

Áreas de mejora sugeridas

  • Aumentar el número de usuarios piloto.

  • Mejorar la tabla de competidores.

  • Mejorar las diapositivas de riesgos.

  • Mejorar las diapositivas de competidores.

  • Mejorar el inicio efectivo.

  • Seguir la organización de la presentación indicada por los profesores.

  • Indicar las responsabilidades por persona. Se pueden poner las responsabilidades de las tareas por sprint.

  • No hacer referencia a la semana pasada.

Análisis del feedback​

Factores comunes en los comentarios de los profesores

  • Mejorar en el inicio efectivo.

  • Mejorar en la gestión del tiempo de las presentaciones.

Puntos de fortaleza general en los equipos

  • Toda la presentación es visible.

  • La tabla de competidores.

Áreas de mejora recurrentes

  • Mejorar en el inicio efectivo.

  • Mejorar en la gestión del tiempo de las presentaciones.

  • Gestión de usuarios piloto.

  • Mejorar el cómo se presenta.

  • Registro de riesgos.

Comparación de nuestro feedback VS los de otros grupos​

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

  • Nuestros mockups son más visuales.

  • Hemos sabido hacer una gestión del tiempo mejor en comparación con el resto.

  • Nuestro análisis de costes.

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

  • Añadir la landing page al final de la presentación.

  • Presentar mejor los riesgos.

  • Indicar las responsabilidades de los miembros del equipo.

  • Conseguir más usuarios piloto.

Conclusiones​

  • Nuestra presentación parece estar a la altura de la fecha del curso. Faltaría esperar a la nota de los profesores para verificar esto.

  • Debemos mejorar en algunos aspectos de la presentación.

Trabajo para la siguiente semana​

  • A partir de ahora las presentaciones durarán 15 minutos.

  • Todo lo relacionado con la evaluación del rendimiento debe ser cuantitativo.

  • Los despliegues suelen dar problemas. Se debería de hacer despliegue continuo.

  • Las presentaciones a partir de ahora (los porcentajes pueden no sumar 100%):

    • Deben empezar con un 15% de introducción:

      • Killer opener.

      • Elevator pitch corto.

      • Resumen análisis de competidores.

      • Con tabla diciendo lo que nos diferencia.

      • Análisis de costes.

      • Equipo.

        • Si alguien no ha cumplido con sus tareas diciendo el porcentaje.

        • Puede ser anónimo.

        • Estructura de responsabilidades.

    • 15% de prototipo:

      • Mostrar lo que se tenga mediante capturas y vídeos.

      • Deben de ser concisas e ir al grano, mostrando lo importante.

    • 50% de retrospectiva:

      • Análisis de la calidad y productividad:

        • Análisis del rendimiento, plan de la calidad (se puede anonimizar), etc.

        • Puede ser más de una trasparencia.

      • Problemas encontrados.

      • Trazabilidad de los riesgos:

        • No se deben de repetir riesgos.

        • Lecciones aprendidas del riesgo.

      • Reloj de avance del proyecto:

        • Tiempo dedicado según lo esperado.

        • Diferencia entre tiempo dedicado y esperado.

        • Ratio de horas respecto al total.

      • Reestimación del sprint 1:

        • Objetivos finales para el sprint 1.

      • Reestimación de siguientes sprints.

    • 10% de gestión de usuarios pilotos:

      • Agenda para trabajar con ellos (días y cuándo).

      • La responsabilidad del feedback es del equipo.

      • La gestión de los usuarios pilotos es crítica.

    • Planificación para el siguiente sprint.

    • Cómo hemos usado la IA.

    • Lo que no se menciona no se pide (se puede poner pero tiene que tener una razón).

6.2. Clase del día 7 /03/2025.​

A continuación, se muestra tanto el feedback grupal como las anotaciones generales:

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.

Análisis del feedback​

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.

Comparación de nuestro feedback VS los de otros grupos​

¿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.

Trabajo para la siguiente semana (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 pueden 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.

Conclusiones​

  • 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.