Feedback clase 20 febrero

Hora inicio: 10:30h

Hora finalización: 14:30h

Lugar: Aula H1.10

Grupo 3

Poner número de las diapositivas.
Transmiten cocneptos erróneos. Decir: "este es el TCO asumiento tal..."
Se ha dejado muy clara la idea de negocio.
Mostrar si se van a usar las IAs y cómo va a ser su uso.
Se ha ignorado el feedback de la semana pasada (respecto al coste).
Es fundamentar dar una visión general y luego en detalle (es decir, tiene un TCO de tanto, debido a estas condiciones...). Los costes meterlo bajo estimación del TCO. Poner el desarroollo
Se están mezclando conceptos en las diapositivas de pricing.
Cuando hablan de riesgo, tienen que dejar claro que conseguirán hablar con los gimnasios, no dejarlo de forma hipotética.
Ajustar al tiempo (se han pasado y no han mostrado los mockups).
No han nombrado ni hablado de la landing page.
Tienen que conseguir un gimnasio sí o sí.
No reaccionar en modo defensa al feedback.

Muy buena idea usar un formulario de google para evaluar a los compañeros.
Colocar las f, que indiquen diapositiva modificada por el feedback de la semana pasada, que sea esta más grande y siempre colocada en el mismo sitio.
No han comentado si han tenido algún problema con algún miembro del grupo.
Muy buena presentación.
En los mockups no han hecho buen uso de todo el espacio de la pantalla.
Buen commitment agremment.
Buena rúbrica.
Buena gestión de código (que tengan en mente la gestión de la documentación).
La documentación para la ONG puede estar mejor en el docusarius en lugar de en una KB.
Hay que trabajar más el inicio efectivo.
Poner enlace o QR para la landing page.
Objetividad a la hora de dar strikes.

Buen inicio efectivo.
Poner en conjunto los colores de todas las letras de las diapositivas y el tamaño de flechas.
Mucho tiempo en una misma diapositiva.
Ha hablado más lento que la semana pasada, pero aún puede ser un poco más.
Reflexionar sobre el índice
Diapositiva grafo DAFO. Poner o grafo o DAFO.
No se ha corregido el DAFO respecto la semana pasada.
Buen uso de la gamificación.
Planificación (visión global y lo que se espera para el siguiente Sprint). Hablar de fechas.
Quitar cosas redundantes (índice y diapositivas en las que se lleva mucho tiempo).
Texto muy pequeños.
En los roles, pensar en una gráfica que traslade los elementos.
Regular un poco más la rapidez

Diapositivas con fondo blanco y letras no claras.
Hablar más del equipo de desarrollo, no solo de ellos 2.
Poner más competidores.
Añadir algunas palabras en las imágenes
Buena presentación.
Buen arranque, pero mejorable.
Bien señalado el feedback.
Ver el uso de la IA.
Marina debería usar el micrófono, ya que no se le escuchaba bien al final.
En la diapositiva del pricing, primero hablar de los 3 planes y luego ir desarrollando cada uno de los planes.
Poner estadísticas (de las pull request, ia, horas...).
Landing page.
Bien uso de ROI.
No obligar a los usuarios pilotos a tener un rol específico. Buscar a personas ya con ese rol.
En pricing contarlo de forma incremental (ir diciendo lo que cambia de un plan a otro). Sería de forma más rápida.
En lo mockups, buscar imágenes y usuarios realistas.

Recomendaciones de planes mediante puja (aplicar la ley de la oferta y la demanda).
Para el futuro analizar costes marketing
Opener bueno pero arriesgado, pensar en algo más seguro.
Diapositiva del ROI. Especificar de donde salen esos 2 decimales.
Quitar las trasparencias en las que aparecen cosa de la asignatura (en la de client != user)
Estructura en grupos. En el backend mirar la arquitectura de microservicios (es la que se suele usar).
Gestión de la documentación.
En los riesgos, resumirlo quedandonos con los más importantes.
Indicar el número de horas que pensamos que vamos a usar (github actions).
Explicar el agreement, decir el estado. Analizar el rendimiento de cada miembro del grupo e indicarlo con gráficos.
Diapositiva 12. Decir que es lo que tenemos ya.
Muy buena gestión de usuarios pilotos.
Bien que en el Sprint 3 tengamos pocas tareas.
Poner fotos uniformes.
Cuando se suba la PPT, que nos lo hayan presentado a todo el grupo y den su visto bueno.
Añadir un slide con el grado de acuerdo. Anañizar el rendimiento de cada usuario.

Opening no muy llamativo.
Demasiadas horas para tan poco tiempo de ejecución del proyecto.
La marca del feedback, ponerla arriba para que sea más visual desde atrás.
No decir "uff que cansado". Beber agua mejor.
Muy bien los competidores. Disonancia con lo puesto y lo dicho.
Transparencia 16, quitar lo del plan 1, plan 2...
Usuario potenciales, decir en que estado está la relación con ellos.
Trabajar con la documentación con código. Con estrategia de versionado.
Cuando se suba la PTT, que nos lo hayan presentado a todo el grupo y den su visto bueno.
Documentación como código.
Muy buenas empresas como usuarios pilotos.
Falta la planificación por Sprint.
Buenas prácticas a la hora de presentar mockups.
Medir como de buenas son las medidas optadas para mejorar algún problema.

Poner fotos de github y github actions, con los precios (hay calculadoras que lo hacen).
Poner la documentación como código.
Cuando hablemos de los usuarios potenciales, decir en qué estado nos encontramos con ellos.
Indicar si se ha ensayado la presentación delante de todo el grupo.
Poner una transparencia de autodefensa (como estamos trabajando respecto a lo que se espera que se haya trabajado, porcentaje de lo que cubre la presentación en base al total).
Para la presentación, grabarse y subirlo a chatgpt y ver como lo diría él.
Añadir tablas con las clausulas de los agreements.

Próximas presentaciones de 15 min.
Empezar a trabajar como usuario pilotos de los otros grupos.
Documento con la información mínima que se les pedirá a los usuarios pilotos.
Presentación: killer opener; 10% de todo lo visto hasta ahora; 15% prototipo desarrollado, retrospectiva de esta primera semana, resumen modelo neg, elevator pitch, análisis de competidores, costes, equipo, esto del commitment...; 45% metodología, análisis de calidad, rendimiento de los miembros del equipo, gráfica comparando el rendimiento de todo el equipo, problemas encontrado (riesgos encontrado o algo nuevo que haya pasado), lecciones aprendidas, reloj del avance del proyecto (añadir los enlaces); 20% planificación y replanificación, indicar objetivos del sprint 2; 10% gestión de usuarios pilotos (tiempo que van a tener...). Reporte de las IAs.