Grupo 9 - Caronte

En esta página se encuentra el feedback recogido por el equipo del grupo 9 durante las sesiones de clase. Con secciones para cada semana, se detallan los comentarios y sugerencias del profesor y los compañeros, así como las tareas a realizar para la siguiente semana. Además, se incluye una sección para cada grupo con el feedback proporcionado por el grupo 9.

Feedback del día 14/02

Feedback relacionado con la presentación

• Orden de las diapositivas. Comenzar con la idea de negocio, seguida de la descripción en 50 palabras, logo y concepto antes de introducir al equipo de trabajo.
• Eliminar excesivos índices dentro de la presentación, hacerla más directa.
• Tener una presentación más concisa. Reducir texto y enfocarse en los puntos clave.
• Evitar cambios de enfoque repentinos que puedan confundir a la audiencia.
• Tabla comparativa. Asegurar que muestre diferencias claras con los competidores.
• Evitar referencias difíciles de entender sin contexto, como términos específicos de videojuegos (“pase de batalla”).
• Hacer que la presentación sea más dinámica y atractiva sin perder claridad.
• Incluir un elemento educativo en el slogan o branding para reforzar la identidad del proyecto.

Feedback relacionado con el desarrollo del proyecto

• Corrección de Key Partnerships. Enfocar esta sección en relaciones externas con otras entidades (influencers, empresas, organizaciones) y no incluir a estudiantes ni profesores.
• Diferenciar Key Partnerships de Value Propositions para que no se confundan con el público objetivo.
• Customer Segments. Los estudiantes y profesores deben estar aquí, ya que representan a los usuarios objetivo.
• Revisión general del BMC. Ajustar y conectar mejor sus secciones para que tenga coherencia con el proyecto.
• Definir un MVP claro y realista, sin sobrecargar con demasiadas funcionalidades.
• No mencionar pagos o funciones premium en la descripción inicial de 50 palabras.
• Ser más conciso en la descripción de 50 palabras, pero asegurando que transmita bien el valor del proyecto.
• No limitar el público objetivo por edad, ya que el aprendizaje es un proceso continuo.
• Reformular el slogan para que refleje mejor la propuesta educativa de la aplicación.
• El logo debe indicar claramente de qué trata la app.
• Ser más claro y directo con las sanciones o medidas en el proyecto.
• No tener miedo a aplicar castigos si es necesario dentro del proyecto.
• Destacar lo generado por IA si se ha utilizado en el desarrollo.

Feedback del día 21/02

Feedback relacionado con la presentación

• Orden de la presentación. Es importante hablar primero del proyecto y luego de la competencia. La introducción debe centrarse en explicar quiénes somos antes de compararnos con otros.
• Presentación individual. Se recomienda que solo una persona exponga, salvo que haya una división clara de roles (por ejemplo, técnico vs. financiero).
• Casos de uso y UML. Los diagramas de UML no aportan mucho en este contexto, se debe buscar una forma más visual y atractiva para explicar los casos de uso.
• Visibilidad del contenido. Asegurar que todas las secciones sean legibles y comprensibles, evitando elementos visuales confusos.
• Menos comparación con competidores. No destacar tanto las diferencias con la competencia, sino enfocarse en lo que aporta el producto.
• Priorizar los mockups. Mostrar visualmente cómo funciona la aplicación en lugar de enfocarse en diagramas de casos de uso.

Feedback relacionado con el desarrollo del proyecto

• Definir un modelo de pago claro. Actualmente, la monetización no está bien explicada. Se sugiere explorar opciones como una cuota mensual o anual en lugar de un pago único al fallecer.
• Sostenibilidad económica. Es necesario justificar mejor cómo se mantendrán los ingresos a lo largo del tiempo.
• Diferenciarse con servicios adicionales. No centrar todo el modelo de negocio en las esquelas, sino diversificar los servicios para maximizar el valor ofrecido.
• Esquelas personalizadas premortem. Permitir que los usuarios creen sus propias esquelas en vida con mensajes personalizados.
• Transformar las esquelas digitales. En lugar de ser anuncios pasivos, pueden ser elementos más dinámicos y personalizables.
• Explorar un enfoque más atrevido. Una aproximación políticamente incorrecta podría ser una oportunidad para diferenciarse en el mercado.
• Certificación de defunción: Se debe asegurar que las esquelas solo se creen tras la validación de un parte de defunción.
• Integración con servicios existentes: Considerar que los tanatorios ya cuentan con ciertos servicios, lo que puede afectar la propuesta de valor de la aplicación.

Feedback del día 28/02

Feedback relacionado con la presentación

• Mejorar la gestión del tiempo y las transiciones durante la presentación.
• Realizar una presentación que sea lineal.
• Mejorar la presentación del Business Model Canvas utilizando una mayor diferenciación y conexión entre sus diferentes secciones (los Key Partnerships van “propagándose” poco a poco sobre el resto de secciones).
• Mejorar la presentación del análisis de competidores (evitar la nube de competidores, mostrar una frase completa que defina a cada competidor y explicar por qué descartas a los competidores menos destacados).
• Unificar las fotos de los miembros del equipo de trabajo.
• Cambiar el enfoque de las protopersonas (no dan feedback) y combinarlo con los usuarios objetivo.
• Hacer un stack tecnológico llamativo y útil.

Feedback relacionado con el desarrollo del proyecto

• No limitar la aplicación a una aplicación web y escoger las tecnologías que permiten el desarrollo de una aplicación web y móvil.

Feedback del día 07/03

Feedback relacionado con la presentación

• Hablar del valor del producto de nuestra aplicación antes que la propia competencia.
• Incluir una gráfica de costes, ingresos y gastos.
• Crear un clima en el que se normalice la muerte sin abusar de lo políticamente incorrecto.
• Mejorar el Killer Opener de la presentación.
• Presentación muy correcta con un tono formal y atractivo. Seguimiento lineal de todas las secciones.
• Mejorar la sección del prototipo funcional para hacerlo más dinámico, visual e interactivo.
• Mejorar la visualización de las gráficas de rendimiento y desempeño individual.
• Buena gestión del programa de usuarios piloto (gran número de participantes, calendario detallado, etc.).
• Mejorar el estado del progreso de las diferentes secciones de la presentación.

Feedback relacionado con el desarrollo del proyecto

• En la sección de análisis de costes y TCO, considerar las diferentes fases del proyecto diferenciando entre las fases de desarrollo y lanzamiento. Establecer un análisis de beneficios progresivo durante la fase de lanzamiento, incluyendo el factor tiempo. Determinar un alcance realista de usuarios de la aplicación.
• Determinar qué pasará en el caso de que la empresa desaparezca.

Feedback del día 14/03

Feedback relacionado con la presentación

• Mejorar la representación del porcentaje de cada sección para que tenga un refuerzo gráfico detrás.
• Mejorar la diapositiva relativa a la organización del equipo de trabajo para que represente de una manera más visual la capacidad de cada rol designado en el equipo.
• Mejorar la representación gráfica de rendimiento del equipo de trabajo (añadir límite de horas necesario, media de horas de trabajo, no incluir el total de horas, etc.).
• Buen trabajo por el cuidado de la presentación. A veces, las cosas más simples son las mejores.

Feedback relacionado con el desarrollo del proyecto

• Se ha incluido información en la presentación acerca del uso de IA durante el desarrollo del proyecto, uno de los pocos grupos que lo ha hecho (era un punto obligatorio a tratar).
• En la sección de análisis de costes y TCO, incluir una curva acumulativa de beneficios para visualizar de una manera más clara el punto de retorno de la inversión.
• Comenzar a utilizar alguna herramienta de análisis y monitoreo de código y la deuda técnica adquirida.
• Dar una prioridad más alta a aquellas tareas que se estiman como críticas por su complejidad o duración.
• Gestionar de una manera adecuada todo el feedback recibido, ya sea por parte del profesor, los compañeros o el resto de usuarios piloto.
• Se ha valorado positivamente el uso de gráficas Burnup para el seguimiento y control de las tareas asignadas en el Sprint correspondiente, así como del Product Backlog de manera global.

Feedback del día 21/03

Feedback relacionado con la presentación

• Mejorar el Killer opener, incluyendo un apoyo visual. Buen uso de las pausas para llamar la atención a la audiencia.
• Mejorar la presentación del Storyboard, incluyendo uno para cada uno de los usuarios de la aplicación (clientes, empresas e inversores).
• Incluir los factores establecidos para la evaluación del rendimiento de los miembros del equipo.
• Evitar realizar la demostración funcional de la aplicación en directo, empleando el vídeo previa edición con el incremento funcional de esta semana.
• Buen uso de la gestión y evolución de la calidad del código utilizando la herramienta de seguimiento Codacy, incluyendo los aspectos positivos y a mejorar de cara a próximas semanas de desarrollo, análisis de code smells y duplicidad de código, entre otros.
• La gráfica de análisis de costes y TCO y la gráfica de análisis de rendimiento del equipo reúne toda la información necesaria.

Feedback relacionado con el desarrollo del proyecto

• En la sección de análisis de costes y TCO, cambiar el término Pérdidas por Gastos.
• En la sección de análisis de rendimiento del equipo, incluir factores cuantitativos y cualitativos, del mismo modo, es necesario la presencia de una gráfica que indique el rendimiento individual de cada miembro del equipo de manera conjunta.
• Definir correctamente los riesgos, realizar una diferenciación clara respecto a los problemas e introducir una sección de análisis de las medidas llevadas a cabo y su seguimiento.
• Incluir en la aplicación un mecanismo de denuncia que permita a los usuarios contactar con nosotros cuando tengan algún problema.

Feedback del día 28/03

Feedback relacionado con la presentación

• En la sección del Killer opener, se podría mejorar el inicio efectivo incorporando las ideas de los storyboards. De esta forma, se haría un muy buen nexo.
• El orden de presentación le ha chirriado, después del elevator pitch deberían ir los storyboards, posteriormente los competidores y finalmente la demo.
• Mejorar el Benchmarking para señalar mejor las diferencias entre los competidores.
• Mejorar la sección de Customer Agreement para indicar más información como las cláusulas abusivas y decir que se ha utilizado Claudette.
• En la comparación del cambio de métricas en Codacy, representar las dos gráficas en la misma transparencia para ver bien la diferencia.
• En la sección de usuarios piloto, explicar cómo se prioriza el feedback recibido y se categoriza en función de su importancia.

Feedback relacionado con el desarrollo del proyecto

• En la sección de análisis de costes y TCO, considerar el exceso en los costes de trabajadores en el caso de que excedan el límite de 170 horas.
• Utilizar GitHub Copilot para la revisión de pull requests.
• En la sección de los usuarios piloto, hacer que estos se sientan escuchados enviándoles información a raíz del feedback proporcionado.
• En la sección de la demostración funcional, hacer zoom sobre las partes más importantes y que no puedan verse por la audiencia.

Feedback del día 04/04

Feedback relacionado con la presentación

• El anuncio de los clientes es un poco extenso, se puede quitar algunos fondos negros de transición.
• En la sección de los Storyboards de los inversores, modificar la sección incluyendo opciones de inversión con su rentabilidad, el beneficio y recuperación de la inversión en el tiempo.
• En la sección de análisis de costes y TCO, utilizar los colores corporativos para la representación de las diferentes gráficas.
• En la sección de análisis de rendimiento del equipo de trabajo, añadir la media del resto de semanas a la gráfica del Sprint.
• En la sección de usuarios piloto, añadir a la pirámide de feedback categorizado de los usuarios piloto un cuarto nivel en el que se encuentran todos los aspectos a ignorar por diversos motivos.

Feedback relacionado con el desarrollo del proyecto

• Característica nueva: poder relacionar los “receivers” de las esquelas y mensajes con los contactos del móvil o amigos de redes sociales.
• En la sección de marketing, elaborar un plan de marketing (establecer un plan de tracción del mercado, reparto de responsabilidades del equipo, etc.).

Feedback del día 11/04

Feedback relacionado con la presentación

• La presentación es clara y contiene todos los elementos necesarios y guarda un estilo acorde a lo largo de todas las diapositivas. Por otro lado, el orador ha mantenido un ritmo correcto y ha realizado una buena presentación en todos los aspectos.

Feedback relacionado con el desarrollo del proyecto

• En la sección de la demostración funcional, mejorar el contenido que se presenta incluyendo únicamente aquellas nuevas funcionalidades que pertenezcan a los casos de uso core de la aplicación, así como cuidar la velocidad de las diferentes transiciones y zooms utilizadas a lo largo del vídeo. Es esencial evitar los casos de registro y todos los formularios donde se necesite rellenar información.
• En la sección de análisis del rendimiento del equipo, mejorar la visualización de las horas de trabajo individual de cada miembro del equipo para una mejor comprensión por parte de la audiencia.
• En la sección de los anuncios, mejorar la calidad de los vídeos para empresas e inversores.
• En la sección de análisis de código, no incluir los test para el análisis de código en Codacy para evitar la redundancia y duplicidad de código.

Feedback del día 25/04

Feedback relacionado con la presentación

• Cambiar el orden del comienzo de la presentación, la transparencia del mensaje inicial tiene demasiadas imágenes heterogéneas. Se podría utilizar el anuncio de usuarios como killer opener.
• Se podría combinar la demostración funcional con la explicación de las diferentes características que ofrecemos.
• En la monetización falta apoyo visual para comprender cuales son las situaciones pesimistas y optimistas.
• Fallo en la diapositiva de protopersonas, en el estado civil ponía la ocupación de la persona.
• No se entienden bien los números que están junto a las redes sociales, a primera vista parece los seguidores y no el número de publicaciones.
• No hay que hablar sobre retrospectiva, moral o nada relacionado con el equipo en esta presentación.
• Lo que importa al inversor no es el precio, si no que porcentaje y que está comprando por ese dinero.

Feedback relacionado con el desarrollo del proyecto

• Posible futura implementación de una IA para la validación de esquelas.
• El vídeo de la demostración funcional va muy rápido y la música está altísima.

Feedback del día 02/05

Feedback relacionado con la presentación

• Durante la presentación de la demostración funcional, el volumen del vídeo demo era excesivamente alto, lo cual dificultó la comprensión del presentador.

Feedback relacionado con el desarrollo del proyecto

• En la sección de análisis de competidores, se incluyó a Life Will, una startup que ya ha desaparecido del mercado.
• El tono paródico del anuncio dirigido a inversores no resulta adecuado para este contexto. Se sugiere evitar el formato de diálogo, adoptando un enfoque más narrativo. Además, el vídeo no deja claro a quién se está dirigiendo la solicitud de inversión.

Grupo 7 - Map Your World

Feedback del día 14/02

Feedback relacionado con la presentación

• Mantener una estética homogénea en todas las diapositivas (fuentes, colores, estructura, márgenes).
• Incluir el logo del proyecto o un elemento identificador en cada diapositiva.
• Cuidar el tamaño de la letra para que sea legible desde cualquier punto.
• Evitar elementos distractivos como cambios de plantilla o estilos diferentes.
• Respetar los espacios en blanco y la combinación de colores para mejorar la legibilidad.
• Incorporar referencias visuales de la identidad corporativa (IC) en cada diapositiva.
• Evitar bloques de texto extensos, optar por mensajes compactos y directos.
• Resaltar palabras clave en negrita para facilitar la comprensión.
• Explicar funcionalidades con mockups o metáforas visuales.
• Incluir una tabla comparativa para análisis de competencia.
• Iniciar la presentación con una introducción del equipo y después explicar la asignación de roles.
• La presentación debe ser un apoyo visual, no la protagonista.
• Evitar leer en exceso las diapositivas; hablar de forma natural y estructurada.
• No utilizar papel o guiones para evitar distracciones.
• Hablar de manera pausada para que la audiencia tenga tiempo de procesar la información.
• Utilizar el botón de pantalla negra para evitar distracciones en ciertos momentos.

Feedback relacionado con el desarrollo del proyecto

• Definir claramente el producto mínimo viable (MVP) y representarlo visualmente.
• Aclarar mejor el público objetivo y diferenciarlo si hay distintos segmentos.
• Distinguir claramente entre roles y equipos de trabajo.
• Asegurar que la sección de inteligencia artificial (IA) sea transversal y mencionar explícitamente dónde se ha usado.
• Definir un manual de identidad corporativa para mantener coherencia en futuras presentaciones.
• Asegurar que el resumen de 50 palabras sea representativo y efectivo.
• Definir cómo se va a trabajar con IA y explicar claramente su aplicación en el proyecto.
• Mejorar la documentación de reuniones y orden del día.
• Evaluar el sistema de penalizaciones para hacerlo más justo.

Feedback del día 21/02

Feedback relacionado con la presentación

• Autocontención. No hacer referencias a presentaciones anteriores, cada una debe ser comprensible por sí sola.
• Legibilidad. No incluir contenido que no se pueda leer claramente.
• Orden de los apartados. Ajustar el orden de las secciones para que la estructura tenga sentido. No hablar de costes antes de explicar el producto.
• Claridad visual. Evitar márgenes inconsistentes, tipografías difíciles de leer y tablas desorganizadas.
• Evitar iconos poco visibles. No usar elementos gráficos difíciles de interpretar.
• Enfocar la presentación a inversores. Resaltar el valor del producto sin enfocarse en los riesgos de manera alarmista.
• Evitar depender de la presentación para leer contenido. Los ponentes deben transmitir las ideas sin necesidad de leer diapositivas textuales.
• Solo los presentadores deben hablar con el profesor. Evitar interrupciones de otros miembros del equipo.

Feedback relacionado con el desarrollo del proyecto

• Justificación. Explicar por qué se han elegido esos competidores y cómo se han identificado.
• Comparación clara. Asegurar que haya un análisis comparativo detallado con métricas bien definidas.
• Cobertura completa. No deben faltar competidores relevantes, evitando que el análisis sea insuficiente.
• Diferenciación. Destacar qué hace único el producto frente a la competencia.
• Claridad en las características de pago. Definir qué funcionalidades son gratuitas y cuáles requieren pago.
• Viabilidad del modelo premium. Justificar por qué alguien pagaría por ciertas funciones y si realmente merece la pena.
• Momento adecuado para tratar la monetización. Presentar el modelo de ingresos después de explicar qué hace la aplicación.
• Privacidad y regulaciones. Abordar cómo la aplicación gestionará los datos de los usuarios para generar confianza.
• Corrección en el uso de términos. Usar "ludificación" en lugar de "gamificación".
• Optimización del Business Model Canvas. Diferenciar correctamente los segmentos de clientes y eliminar solapamientos en los perfiles.

Feedback del día 28/02

Feedback relacionado con la presentación

• Utilizar un lenguaje más visual y sencillo (uso de una simbología más clara).
• Mejorar el orden de la presentación. Algunas secciones deberían ir con antelación de otras, es muy importante seguir una línea temporal a lo largo de la presentación.
• PMBOK es un marco de referencia y no una tecnología en sí misma, por lo que puede complementarse con metodologías ágiles como SCRUM.
• De todos los elementos incluidos en la tabla de PMBOK, es necesario evaluar cuáles se implementarán y cuáles no, en función de la necesidad y viabilidad del proyecto.
• En cuanto a la gestión del conocimiento, se dedicó mucho tiempo a discutir una diapositiva con estructura de índice. Sin embargo, sería recomendable desarrollar con mayor profundidad aspectos clave como la metodología, la toma de decisiones y otros puntos relevantes para mejorar el feedback y la comprensión del proyecto.
• Evitar el uso de las diapositivas “transición”. No es necesario utilizar diapositivas completas para indicar la sección que se va a tratar a continuación, la idea y todo el contenido tiene que ser más directo.

Feedback relacionado con el desarrollo del proyecto

• Analizar si la tecnología de Websocket es la mejor para el desarrollo e implementación de la idea del proyecto.
• El MVP debería ser más claro y dedicarle más tiempo y una mayor prioridad que otras como el benchmarking.
• Justificar la elección de las tecnologías de desarrollo del equipo.
• La landing page tiene una correcta presentación y contenido. Bastante completa y visualmente atractiva.
• Un modelo publicitario implica costos asociados a la aparición de publicidad, por lo que es fundamental considerar y planificar estos gastos.

Feedback del día 07/03

Feedback relacionado con la presentación

• Utilizar términos técnicos relacionados con el marco de referencia de PMBOK.
• Ser consistentes con el idioma a lo largo de la presentación.
• Las diapositivas contienen demasiado texto y carecen de metáforas visuales. Reducir el contenido de información por diapositiva para mejorar su comprensión.
• El número de diapositivas no es visible.
• Durante la sección de seguimiento de tareas y planificación, es necesario mostrar las tareas en curso junto con un porcentaje que refleje su nivel de progreso.
• No presentar secciones que no están contempladas en el guión de la presentación (ej. Business Model Canvas).
• Diferenciación clara entre riesgos y problemas detectados.
• El presentador ha hablado demasiado rápido debido al exceso de información y temas a tratar de la presentación.
• Mantener un orden correcto en la presentación, hablando antes sobre la innovación de la idea antes que hablar de la competencia.

Feedback relacionado con el desarrollo del proyecto

• Mejorar la gestión del programa de usuarios piloto.
• Mejorar el contenido, añadiendo más información al respecto, en la fuente de ingresos.

Feedback del día 14/03

Feedback relacionado con la presentación

• Mejorar el Killer opener para que sea más atractivo y se enfoque en dar una solución a un problema.
• Incluir los enlaces a demostraciones y a la aplicación web en la diapositiva final.
• Cuidar la terminología empleada durante la presentación.
• Evitar el uso de diagramas de colores y simplificar el contenido mostrado en dichas gráficas para mejorar la visualización de los datos.
• Pronunciar correctamente el nombre del grupo, el presentador ha hablado demasiado rápido porque tiene mucho contenido que contar.
• Cambiar la presentación del resultado del análisis de rendimiento y/o Sprint Retrospective. Utilizar un orden de: cosas que han ido mal, cosas que mejorar y cosas que se han hecho bien y, si es posible, utilizar una diapositiva para sección.
• Se ha hablado antes de los competidores que de la propia propuesta de la aplicación, error que se cometió la semana pasada por otro grupo.
• Ser consistentes con el idioma empleado a lo largo de toda la presentación.
• Falta de apoyo durante la demostración del vídeo (muchos silencios incómodos).
• Mejorar la consistencia en los estilos de las diapositivas, respetar los márgenes y espacios para los títulos.
• Mejorar la presentación de información a través de tablas para mejorar su apariencia y comprensión por parte de la audiencia.
• Falta de homogeneidad en las imágenes del equipo de trabajo, error que se cometió anteriormente por otro grupo.
• Las personas que quieran contribuir en la presentación deberían presentarse (aunque sea durante la fase de feedback).
• Mejorar el reparto de tiempo para las diferentes secciones de la presentación.

Feedback relacionado con el desarrollo del proyecto

• Actualizar los riesgos, acciones tomadas y análisis de las medidas que vayan surgiendo a lo largo del desarrollo de la aplicación.
• Considerar la pérdida de transmisión de datos en tiempo real por parte de dispositivos móviles en algunos casos específicos (ej. modo de ahorro de energía).
• Estudiar la viabilidad de implementar la actividad por pulseras inteligentes de actividad (Google Fit) o Smartwatches.
• Incluir la repercusión de las penalizaciones tomadas en la nota final de los miembros del equipo de trabajo.
• Incluir el Project Launch en la planificación completa de la asignatura, después del Sprint 3 no va el World Project Launch.
• Se ha incluido información en la presentación acerca del uso de IA durante el desarrollo del proyecto, uno de los pocos grupos que lo ha hecho (era un punto obligatorio a tratar).
• En la sección de análisis de costes y TCO, considerar que los costes de mantenimiento, soporte, etc. no son constantes a lo largo del tiempo.

Feedback del día 21/03

Feedback relacionado con la presentación

• Centrar la demostración al core de la aplicación (evitar la muestra de gestión de usuarios) y hacerla más atractiva para la audiencia (muchos silencios incómodos).
• Mejorar el Killer opener para que sea más atractivo y llame la atención a la audiencia. Definir un perfil de usuario para que el inicio efectivo sea atrayente a la mayor cantidad de personas.
• Centralizar los Storyboard acordes con el nicho de la aplicación, enfocar la demostración visual a los distintos usuarios de la aplicación. Incluir datos y cifras reales para el Storyboard de los inversores.
• Presentar con antelación la presentación para llevar una estimación de la duración de cada una de las diferentes secciones expuestas, de esta forma se evitaría tener que hablar rápido y agilizar el contenido para acabar en el tiempo establecido.
• Las diapositivas contienen demasiado texto y carecen de metáforas visuales. Reducir el contenido de información por diapositiva para mejorar su comprensión.

Feedback relacionado con el desarrollo del proyecto

• Definir correctamente los riesgos, realizar una diferenciación clara respecto a los problemas e introducir una sección de análisis de las medidas llevadas a cabo y su seguimiento.
• Incluir factores cuantitativos y cualitativos en la sección de análisis de rendimiento del equipo, del mismo modo, es necesario la presencia de una gráfica que indique el rendimiento individual de cada miembro del equipo de manera conjunta.
• Mejorar la fluidez del vídeo de la demostración funcional para que sea más dinámica, evitando el uso de transiciones lentas.

Feedback del día 28/03

Feedback relacionado con la presentación

• En la sección del Killer opener, se puede mejorar el inicio efectivo simulando una historia más realista y que se entienda mejor por parte de la audiencia.
• En la sección de los Storyboards, deben ser más independientes ya que se explican juntos y no tienen un buen nexo entre ellos, el espectador puede confundirse con la persona a la que va dirigida. Además en los Storyboards de inversores se tiene que incluir los números, ofrecer planes en acciones/recuperación e implicación del dinero.
• Una red social necesita gente al principio, por lo que se podría buscar alguna forma para conseguir gente.
• En la sección de análisis de costes, reducir la complejidad de las gráficas mostrando toda la información en una única tabla unificada.
• Muchas transparencias pierden el número.
• Cuando se nombra el equipo de trabajo, evitar enumerar uno a uno.
• Explicar con más detalle todas las gráficas y sus respectivas métricas empleadas.
• No se ve el logo de la aplicación con los estilos actuales de la presentación.
• No puede haber tantas secciones en la presentación.
• Algunas transparencias pueden ser más simples y claras.
• Lo importante no son las horas, sino el retraso que se lleva. Enseñar las gráficas de cuanto falta del proyecto.

Feedback relacionado con el desarrollo del proyecto

• Buen producto, mal negocio, el pago de los negocios es excesivamente caro para el servicio que se ofrece. Las cifras de precios para las empresas no están bien planteadas con respecto a los inversores esperados.
• En la demostración funcional, el precio de los diferentes planes no está definido.

Feedback del día 04/04

Feedback relacionado con la presentación

• La gráfica de proyección financiera no se entiende bien a simple vista, los ejes están desplazados.
• Para mejorar el anuncio quizás ir cambiando el fondo, además se debe indicar las funcionalidades extras que posee.
• Cambiar la gráfica de las métricas del equipo porque son difíciles de comprender.
• Falta de consistencia en los estilos y títulos de la presentación, faltas de ortografía a lo largo de las diapositivas.

Feedback relacionado con el desarrollo del proyecto

• En la sección del anuncio, mencionar las ventajas del plan premium.
• En la sección de los Storyboards, incluir los paquetes de inversión correctamente y limitar el porcentaje dedicado a los inversores.
• En la demo poner que usuario la está usando en ese momento.
• Nunca un paquete de inversiones puede superar el 49% de la empresa.

Feedback del día 11/04

Feedback relacionado con la presentación

• Pronunciar correctamente el nombre del grupo, el presentador ha hablado demasiado rápido porque tiene mucho contenido que contar, aún así se ha llevado una buena entonación a lo largo de la presentación.
• Establecer qué información se va a contar en cada momento, si se incluye la sección de análisis de costes y TCO en el anuncio de inversores, no dedicar otra sección en la presentación sobre el mismo tema.
• Buen inicio efectivo, el Killer opener refleja claramente el propósito de la aplicación y se ha empleado un toque humorístico bastante bueno.
• El vídeo de la demostración funcional está bastante completo y recoge todos los puntos necesarios.
• Falta de consistencia en los estilos y títulos de la presentación, así como faltas de ortografía a lo largo de las diapositivas.
• Unificar los precios de los planes a lo largo de toda la presentación para mostrar consistencia.

Feedback relacionado con el desarrollo del proyecto

• En la sección de los anuncios, evitar grabar escenas a contraluz y apoyarse en mayor medida en datos y cifras reales, por ejemplo, incluyendo estadísticas del nivel de sedentarismo en España. Por otro lado, se ha aplicado correctamente el feedback de la semana pasada incluyendo más dinamismo a las escenas.
• En la sección de Lecciones aprendidas, incluir ejemplos concretos de los errores que han sido encontrados gracias al testing de la aplicación.

Feedback del día 25/04

Feedback relacionado con la presentación

• La gráfica proyección de beneficios no es representativa, los gastos varían en función de la cantidad de trabajo, normalmente los costes deberían ser estables.
• Ausencia del Killer opener efectivo.
• Demasiado eco en los audios de los vídeos.
• Incluir un resumen de las características de la aplicación previa al anuncio de clientes o la demostración funcional.
• Destacar en el análisis de competidores lo que verdaderamente los diferencia de cada uno de ellos, con los rasgos relevantes respecto a la competencia.

Feedback relacionado con el desarrollo del proyecto

• La demo es demasiado acelerada y la música de fondo despistaba más que ayudaba.
• En la sección de inversores, considerar la propuesta de establecer paquetes de inversión a un precio muy bajo y asequible con la finalidad de tener muchas acciones a muy poco precio, porque los actuales son demasiado pretenciosos.
• En la campaña de lanzamiento falta ser más concreto en el apartado de la planificación de las publicaciones (definir fechas exactas para cada actividad). Además, establecer los objetivos (número de publicaciones, repercusión, etc.).
• Para el branding las sombras son malas, con un borde difuso da sensación de no estar bien diseñado.

Feedback del día 02/05

Feedback relacionado con la presentación

• Es recomendable replantear el killer opener para que se adapte mejor al contexto específico del WPL, teniendo en cuenta que se expondrá en el salón de actos de la universidad.
• Para lograr una presentación completamente coherente, es fundamental establecer un hilo conductor que conecte de forma lógica todas las secciones.
• El contenido debe ser totalmente autocontenido. No se debe asumir que el público ha visto presentaciones anteriores ni incluir referencias que puedan generar confusión.
• En la presentación de paquetes de aparición, se debería inferir sutilmente que están dirigidos a empresas y desarrollar la explicación de forma más pausada y clara.
• Se debe omitir la parte teórica sobre SEO. En el WPL, es más apropiado centrarse en diapositivas de carácter no técnico. Además, es importante contextualizar las cifras de búsqueda y enfocarse en palabras clave que realmente utilice el público objetivo.
• Antes de mostrar la gráfica de proyección de beneficios, es esencial mencionar todos los datos clave y explicar el contexto para mantener una linealidad narrativa.
• El término beneficio debería sustituirse por resultado. Además, no queda claro cuáles son las fuentes de ingreso que justifican dichos resultados; esto debe aclararse previamente.
• Se sugiere mejorar la explicación en el análisis de competidores, destacando de forma más efectiva las diferencias clave y aportando un análisis más estratégico.

Feedback relacionado con el desarrollo del proyecto

• La última parte del anuncio de clientes presenta problemas de calidad de audio (eco y saturación).
• Es necesario especificar el valor de cada acción y el porcentaje de la empresa que representa dicha inversión.

Grupo 8 - Infantem

Feedback del día 14/02

Feedback relacionado con la presentación

• Mantener coherencia estética en todas las diapositivas (fuentes, colores, márgenes, estructura).
• Incluir el logo y el nombre de la aplicación en todas las diapositivas, no solo en la primera.
• Definir una Imagen Corporativa (IC) clara y atractiva.
• Usar transiciones y animaciones bien diseñadas, pero sin que sean intrusivas o distraigan.
• Mantener una única fuente de iconos para coherencia visual.
• Considerar el uso de GIFs siempre que sean sutiles y no distraigan.
• Evitar sobrecargar la presentación con demasiadas funcionalidades, centrarse en las esenciales.
• Presentar primero el análisis de competencia antes de las debilidades del DAFO para mejorar la narrativa.
• Utilizar una tabla comparativa para evaluar la competencia de forma visual.
• Asegurar un diseño unificado con número de diapositivas bien integradas.
• Presentar primero a los competidores y después el DAFO para mejorar la lógica de la exposición.
• Hacer descripciones más compactas y concisas, evitando textos extensos.
• Tener cuidado con los errores ortográficos y tiempos verbales.
• Incluir un slogan o frase compacta que resuma la propuesta de valor de la aplicación.
• La presentación debe ser un apoyo visual, no el foco principal.
• Hablar de manera pausada para que la audiencia pueda procesar la información.
• No depender de papeles o guiones, confiar en el discurso.
• Dominar el tema y mostrar confianza en la exposición.
• Interactuar con el público mediante preguntas abiertas o llamadas de atención.
• Usar técnicas de storytelling o metáforas visuales para explicar mejor el concepto.
• Evitar depender de terceros o afiliaciones externas como principal fuente de ingresos.
• Asegurar que el nombre de la empresa esté en todas las diapositivas.
• Incluir un documento claro con tareas y roles semanales.

Feedback relacionado con el desarrollo del proyecto

• Definir claramente el Producto Mínimo Viable (MVP) y evitar módulos innecesarios.
• Explicar bien las características diferenciadoras del proyecto.
• Usar protopersonas para definir claramente el usuario potencial de la aplicación.
• No bombardear con ideas, solo presentar los puntos principales del MVP.
• Evaluar si la plataforma propuesta es demasiado ambiciosa y si debe reducirse el alcance.
• Definir mejor la viabilidad del negocio y las limitaciones de implementación.
• Revisar el Business Model Canvas para mejorar el enfoque estratégico.

Feedback del día 21/02

Feedback relacionado con la presentación

• Orden de los temas. La sección de competidores apareció demasiado tarde en la presentación, debe reorganizarse para mayor claridad.
• Tipografía y legibilidad. Aumentar el tamaño de la tipografía y corregir faltas de ortografía.
• Mejorar transiciones. Las transiciones entre diapositivas y secciones deben ser más fluidas.
• Márgenes. La presentación no tiene márgenes definidos, lo que afecta la estética y la organización del contenido.
• Evitar Lorem Ipsum. No utilizar texto de relleno en los mockups, sino contenido real para una mejor representación de la aplicación.
• Casos reales en mockups. Es necesario incluir ejemplos reales en lugar de texto ficticio para mejorar la comprensión del producto.
• Buen inicio de presentación. Interacción con la audiencia y conexión con la actualidad (ejemplo del Día de San Valentín).

Feedback relacionado con el desarrollo del proyecto

• Falta de modelo de ingresos. No se ha explicado cómo se generarán ingresos, solo se han mencionado los gastos.
• Justificación de costes. Es necesario presentar datos realistas sobre los costes, incluyendo sueldos y tecnologías utilizadas.
• Sostenibilidad económica. Se debe revisar el modelo de negocio para asegurar que sea viable y que los números cuadren.
• Incluir costes sociales. El análisis financiero debe considerar no solo beneficios y gastos operativos, sino también los costes sociales.
• Caso Manfred. Se recomienda utilizar herramientas como Manfred para obtener referencias sobre salarios y costes laborales.
• Maduración de la propuesta. Se requiere una revisión más profunda de la idea para asegurar su viabilidad y relevancia.
• Compromiso con la diferenciación. Definir mejor qué hace única la aplicación frente a la competencia.
• Análisis de competidores. No solo identificarlos, sino justificar por qué han sido seleccionados y hacer una comparación clara.
• Uso de IA y Commitment Agreement. Faltó mencionar estos aspectos dentro de la presentación.
• Casos reales y ejemplos concretos. Se debe dar mayor énfasis a la implementación práctica del producto.
• Idea innovadora. Tiene un enfoque interesante y dirigido a un público amplio.

Feedback del día 28/02

Feedback relacionado con la presentación

• Presentación muy visual y dinámica con un buen opening para enganchar a la audiencia.
• Falta la definición del producto (Idea en 50 palabras), DAFO, Commitment Agreement y uso de la IA.
• La landing page no se ha presentado.
• Mejorar el orden y la linealidad de las secciones de la presentación para favorecer una presentación más dinámica y fluida.
• La sección de análisis de costes ha sido el eje principal de la presentación. Demasiada importancia a las cifras y mucha información que ha sido complicada comprender por parte de la audiencia. Todas las cifras y datos mostrados, deben ser justificados por alguna fuente fiable y deben tener definido un periodo (€/mes, €/año, etc.).
• No hablar del mercado potencial en la misma sección que el PMBOK.
• Revisar la checklist de contenido a comentar en la presentación para que no falte ninguna sección.
• No usar siglas sin ofrecer su correspondiente explicación acerca de significado
• Utilizar una tipografía con mejor legibilidad.
• En la sección de costes, no incluir los iconos de las tecnologías implicadas porque no aportan nada relevante.
• Algunos textos no son muy visibles y contienen demasiada información.
• Corregir la falta de tildes en títulos y textos de la presentación. Establecer un estilo fijo a lo largo de toda la presentación (título completo en mayúscula, sólo la primera letra, etc.).
• Dar una mayor prioridad a la sección de riesgos en la presentación.
• Enfocar la presentación con un carácter más técnico.
• Realizar una presentación autocontenida.

Feedback relacionado con el desarrollo del proyecto

• Realizar un análisis detallado de cada uno de los competidores, incluyendo una tabla comparativa para cada competidor mostrando fortalezas del competidor e Infantem.
• Diferenciar correctamente el término beneficios (diferencia entre los ingresos y los costes) en la sección de análisis de costes.
• Los presupuestos y cálculos en la sección de análisis de costes se deben realizar sin considerar el IVA.
• Comentar y justificar la elección de las tecnologías de desarrollo del equipo.
• Detallar los diferentes planes que ofrece la aplicación.
• Detallar los precios, características y condiciones del plan premium.

Feedback del día 07/03

Feedback relacionado con la presentación

• No presentar secciones que no están contempladas en el guión de la presentación.
• Las diapositivas contienen demasiado texto y carecen de metáforas visuales. Reducir el contenido de información por diapositiva para mejorar su comprensión.
• Mejorar visualmente la sección de planificación y seguimiento del proyecto.
• Falta de apoyo visual en el Killer Opener (demasiado extenso).
• Las diapositivas contienen demasiada información y contienen errores ortográficos. Explicar cada una de las siglas que se introducen y mejorar los elementos de apoyo (uso de porcentajes ‘%’).
• Mejorar la sección de análisis de costes para hacerla más dinámica e interesante.
• Establecer un estilo homogéneo a lo largo de todas las diapositivas de la presentación que sea visualmente atractivo y legible.
• Sintetizar el contenido de la presentación y mostrar los resultados en lugar del proceso previo de análisis (seguimiento de riesgos, lecciones aprendidas, etc.).
• Mejorar la visualización del diagrama de Gantt.

Feedback relacionado con el desarrollo del proyecto

• Mejorar la sección de costes, facilitando su comprensión y visualización. Todo el contenido debe ser consistente y realista.
• Tratar el MVP con ese nombre, no como PMV.
• Incluir la gestión del programa de usuarios piloto, un usuario no puede ser un integrante del propio equipo desarrollador.
• En la sección de seguimiento de tareas, indicar de una manera cuantitativa el estado de las tareas que están en progreso.

Feedback del día 14/03

Feedback relacionado con la presentación

• Mejorar el Killer opener para que sea más atractivo y directo.
• Se ha destinado mucho tiempo para explicar el MVP.
• Sintetizar la información necesaria para la presentación, centrándose en las secciones y contenido solicitado.
• Las diapositivas contienen demasiado texto y carecen de metáforas visuales. Reducir el contenido de información por diapositiva para mejorar su comprensión.
• Falta de consistencia en los estilos y títulos de la presentación, faltas de ortografía a lo largo de las diapositivas.
• Utilizar datos realistas durante la demostración del producto.
• Centrar la demostración al core de la aplicación (evitar la muestra de gestión de usuarios) y hacerla más atractiva para la audiencia.
• La sección de feedback de usuarios piloto ha sido muy clara y visualmente atractiva gracias al buen uso de las metáforas visuales.
• No se dice Usuarios Pilotos sino Usuarios Piloto.
• Evitar el uso de diagramas de colores.

Feedback relacionado con el desarrollo del proyecto

• En la sección de organización del equipo de trabajo, reducir el número de personas que se encuentran en puestos de dirección/organización al tratarse de un grupo reducido de 15 personas (5 personas en puestos de dirección equivalen a +30% del equipo).
• Comenzar a utilizar alguna herramienta de análisis y monitoreo de código y la deuda técnica adquirida.
• Incluir la sección de análisis del uso de la IA, sección obligatoria que no se ha tenido en cuenta en la presentación.
• En la sección de análisis de costes y TCO, las gráficas han sido claras y concisas
• Actualizar los riesgos, acciones tomadas y análisis de las medidas que vayan surgiendo a lo largo del desarrollo de la aplicación.

Feedback del día 21/03

Feedback relacionado con la presentación

• Mejorar el Killer opener para que sea más atractivo y llame la atención a la audiencia.
• Falta de homogeneidad en las imágenes del equipo de trabajo, error que se cometió anteriormente por otro grupo.
• Falta de consistencia en los estilos y títulos de la presentación, faltas de ortografía a lo largo de las diapositivas.
• En la sección de análisis de costes y TCO, unificar toda la información en una única diapositiva para mejorar la visualización de los datos y tener una visión global de los datos proporcionados.
• En la sección de rendimiento del equipo de trabajo, mejorar la gráfica para que no contenga tantos colores, no muestre las horas totales empleadas, ni se muestre de manera porcentual el esfuerzo realizado por cada uno de los integrantes del equipo. Además, debe incluir un límite de las horas necesarias y la media de horas de trabajo.
• No utilizar la presentación para leer el contenido expuesto, sino como apoyo visual.
• Se ha hablado antes de los competidores que de la propia propuesta de la aplicación, error que se cometió en semanas pasadas por otro grupo.
• Las diapositivas contienen demasiado texto y carecen de metáforas visuales. Reducir el contenido de información por diapositiva para mejorar su comprensión. No se dice Usuarios Pilotos sino Usuarios Piloto, error que también se cometió la semana pasada.

Feedback relacionado con el desarrollo del proyecto

• En la sección de los Storyboard, no emplear el uso de la tercera persona para referirse al grupo de los inversores, sino tratarlos de una manera más directa. Suprimir el “meta anuncio” para introducir cómo llega la aplicación a los usuarios, ser más directos.
• Definir a qué edad la aplicación dejará de ser útil para un usuario.
• En la sección de análisis de costes y TCO, unificar toda la información en una única diapositiva para mejorar la visualización de los datos y tener una visión global de los datos proporcionados.
• Mejorar la cobertura de código.
• Incluir factores cuantitativos y cualitativos en la sección de análisis de rendimiento del equipo, del mismo modo, es necesario la presencia de una gráfica que indique el rendimiento individual de cada miembro del equipo de manera conjunta.

Feedback del día 28/03

Feedback relacionado con la presentación

• Incorporar en la demo de la aplicación la historia del killer opener, esto añadirá un muy buen nexo para toda la presentación.
• Aproximar las numeraciones, no representarlas con tanta información. Por ejemplo, representar “90.030, 40” como “90K”.
• Cuando haya una enumeración de cualquier punto, no ponerlo en texto si no con metáforas visuales, y no enumerar todo tal cuál, sino centrarse en algo concreto y lo demás dejarlo como un simple etcétera.
• En el storyboard de inversores hay que centrarse más en las cifras, poniendo los precios y todo lo relacionado con números.
• Utilizar más metáforas visuales, hay demasiado texto.
• No leer tanto las transparencias porque si la audiencia detecta que estás leyendo las transparencias, esta deja de escuchar.
• Intentar cambiar la entonación durante la presentación para hacerla más amena, por ejemplo, haciendo énfasis en lo más importante.
• Se entienden cosas antes de presentarlas verdaderamente, haciendo referencia a que el elevator pitch está tan bien que la posterior presentación del MVP pierde valor.

Feedback relacionado con el desarrollo del proyecto

• En el análisis del código, insertar más información acerca del estado del código, para justificar los márgenes de mejora y futuras progresiones. Puede ser buena idea usar las gráficas de Sonar para hablar de esto.

Feedback del día 04/04

Feedback relacionado con la presentación

• Mejora de presentación respecto a la semana anterior, pero el presentador debe jugar un poco más con las pausas.
• Killer opener efectivo, pero hay que hilar más con tema principal de la aplicación. Ya que se centra en la comida, pero ha parecido que la aplicación se relaciona con enfermedades.
• Falta de consistencia en los estilos y títulos de la presentación, faltas de ortografía a lo largo de las diapositivas.
• En la sección de análisis de costes y TCO, utilizar unos colores más diferenciales para poder distinguir correctamente cada información en la gráfica de costes compleja.
• En la gráfica de rendimiento del equipo se debe poner en los ejes lo que representa.
• La mayoría de problemas que se han presentado son de implementación, habría que añadir más problemas de comunicación y otros campos.
• Hay que explicar la nota de E del análisis de código, ya que ha dicho que todo está perfecto pero no ha justificado la nota.
• No ha dado tiempo a presentar bien el informe de IA, hay que recortar de otro punto de la presentación. En el MVP se ha dedicado demasiado tiempo.

Feedback relacionado con el desarrollo del proyecto

• Se debe desarrollar el matching de la aplicación.
• En la demo, introducir imágenes reales de la aplicación en lugar de imágenes generadas por IA.
• En la demos se debe destacar los aspectos se han mejorado gracias al feedback de los usuarios pilotos.
• En la sección de seguimiento y planificación del trabajo, es necesario incluir gráficas sobre el seguimiento de los diferentes estados de las tareas a lo largo del Sprint.
• Ha faltado la presencia de un anuncio en la aplicación, no utilizar el Storyboard para apoyarse en esa idea.
• En la sección de análisis de costes y TCO, ser más realistas en cuanto a los planes de inversión e introducir el factor tiempo en todo el cálculo de beneficios.
• Aclarar el tema de los referidos de los productos.

Feedback del día 11/04

Feedback relacionado con la presentación

• El Killer opener está muy conseguido, se ha usado el feedback de la semana pasada para incluir en él un problema específico en el bebé (problema con los alérgenos), que se ha usado posteriormente en la sección de los anuncios manteniendo un buen hilo argumental.
• Falta de consistencia en los estilos y títulos de la presentación, así como faltas de ortografía a lo largo de las diapositivas.
• Mejorar la forma de presentar, el orador habla demasiado rápido y no hace las pausas necesarias entre las diferentes secciones o puntos de la presentación.
• Las diapositivas contienen demasiado texto y carecen de metáforas visuales. Reducir el contenido de información por diapositiva para mejorar su comprensión.
• Mencionar en todo momento la fuente de todos los datos y cifras estadísticas que se utilizan en la presentación.
• Utilizar una notación de K, M, etc. para la representación de las cifras numéricas de una manera más simple y clara.
• Mantener una linealidad a lo largo de toda la presentación, cuidar la presentación inicial de la mascota para que esta no aparezca sin ser presentada.

Feedback relacionado con el desarrollo del proyecto

• En la sección de los anuncios, unificar el anuncio de usuarios. No grabar un vídeo para usuarios freemium y otro para usuarios con un plan premium.
• En la sección de la Idea de negocio, aumentar el rango del público objetivo debido a la concepción de niños cada vez más tardía.
• En la sección de análisis del rendimiento del equipo, utilizar una nueva métrica que se adapte mejor y permita una correcta evaluación de cada uno de los miembros del equipo.
• En la sección de Sprint Retrospective, evitar realizar un análisis de rendimiento, realizando una retrospectiva de todos aquellos aspectos que han ido bien o se pueden mejorar, así como de las debilidades afrontadas por el equipo a lo largo del Sprint.
• En la sección de Usuarios piloto, buena priorización y categorización del feedback, incluyendo ejemplos reales.

Feedback del día 25/04

Feedback relacionado con la presentación

• En la presentación falta hilo argumental, podrían hacer el killer opener las personas que hacen el anuncio.
• No poner cifras enteras, acortar con letras que hagan referencia al valor de la cifra.
• Al poner a Spoony no se entiende bien en la planificación que se va a hacer, especificar en qué redes sociales que se va a subir en qué red social y cuando.
• Falta de soporte visual en algunas secciones.

Feedback relacionado con el desarrollo del proyecto

• En el anuncio no aparecen problemas relacionados con la comida, que es lo principal de esta aplicación.
• La demostración funcional de la aplicación es muy breve y no recoge los casos de uso core de la aplicación
• Vídeo de inversores corto, se debería ampliar con paquetes de inversión.

Feedback del día 02/05

Feedback relacionado con la presentación

• La parte dedicada a costes, ingresos y beneficios ocupa demasiado tiempo dentro de la presentación.
• Las representaciones actuales de los usuarios tipo (protopersonas) requieren mayor profundidad, especialmente en cuanto a los bebés.
• Para representar la información de manera más visual y comprensible sobre las estadísticas de redes sociales, se recomienda sustituir los datos estáticos por una gráfica de evolución que muestre la progresión o impacto a lo largo del tiempo.

Feedback relacionado con el desarrollo del proyecto

• En el modelo de ingresos es importante precisar que no se trata de un modelo freemium, sino de una proporción de usuarios freemium. - Además, la estimación del 13 % de ingresos iniciales provenientes de estos usuarios parece excesiva y podría resultar poco realista en fases tempranas del proyecto.
• La propuesta de colaboración con influencers necesita incluir un presupuesto estimado.
• Se sugiere incluir de forma explícita al segmento de personas con bebés dentro de la segmentación de mercado, forman parte del público potencial de la solución.
• Se recomienda enriquecer la demo incorporando una pista de audio narrado. En particular, sería interesante que el personaje Spoony tuviera voz.

Grupo 10 - Go4Surprise

Feedback del día 14/02

Feedback relacionado con la presentación

• Reducir la cantidad de secciones para hacerlo más claro y conciso.
• Si se incluye un índice, debe ser numerado y con un orden lógico, sin exceso de divisiones.
• Pasar el índice sin detenerse a explicarlo, enfocándose directamente en el contenido relevante.
• Evitar explicar conceptos que la audiencia ya conoce (por ejemplo, no explicar SCRUM a expertos).
• No incluir diagramas innecesarios como UML, DAFO o casos de uso, a menos que sean estrictamente relevantes.
• Conocer bien a la audiencia para adaptar la información al nivel adecuado y evitar explicaciones redundantes.
• Hacer que la parte de preguntas y respuestas (Q&A) sea más natural, no estructurarse como un examen.
• No incluir preguntas artificiales en diapositivas para intentar explicar conceptos; mejor integrarlas de forma orgánica en la conversación.
• Remarcar claramente los puntos clave si se hace un “zoom” sobre un tema específico para evitar confusión.
• Evitar una presentación plana y básica, incorporar elementos visuales atractivos para captar la atención.
• Incluir Imagen Corporativa (IC) en las diapositivas para reforzar la identidad del proyecto.
• No intentar vender datos sin entender bien los aspectos legales, ya que es un tema complejo y puede ser problemático.

Feedback relacionado con el desarrollo del proyecto

• Ser más realistas con la idea del proyecto, evitando planteamientos demasiado optimistas o poco prácticos.
• Ajustar la propuesta de valor para que tenga sentido en el contexto en el que se va a aplicar.

Feedback del día 21/02

Feedback relacionado con la presentación

• Reducir la sobrecarga de información. Actualmente, la cantidad de datos es abrumadora. Se debe priorizar la información clave y estructurarla de manera más digerible.
• Controlar el flujo de información. Saber cuándo sorprender al público y cuándo centrarse en el valor recibido.
• Barra de progreso en la presentación. Indicar cuántas diapositivas hay en total (ejemplo: "15 de 20") para gestionar la expectativa del público.
• El título debe estar siempre visible. Preferiblemente en la parte superior izquierda de cada diapositiva.
• Cuidar la legibilidad. Asegurarse de que la letra sea lo suficientemente grande para facilitar la lectura.
• Diferenciar tecnologías de metodologías. No mezclar herramientas técnicas con enfoques metodológicos en la misma sección.
• Cuidar los recortes de imágenes. Si se eliminan fondos, asegurarse de que el fondo resultante sea uniforme para evitar inconsistencias visuales.
• Usar iconos sin fondo blanco. Para mantener una estética más limpia y homogénea.

Feedback relacionado con el desarrollo del proyecto

• Contar una historia con los mockups. No deben simplemente mostrar elementos visuales, sino guiar al espectador a través de un recorrido narrativo.
• Evitar sobrecargar los mockups. Demasiada información en una sola imagen dificulta la comprensión del mensaje.
• Definir bien la arquitectura de la aplicación. En lugar de solo listar tecnologías, se debe mostrar cómo se relacionan entre sí con un diagrama claro.
• Estructurar mejor la presentación de tecnologías. No basta con poner los logos, se debe explicar su función dentro del proyecto.
• Separar herramientas según su función. Diferenciar entre herramientas de almacenamiento (Google Drive) y frameworks de desarrollo (Django).
• El hardware es amortizable. Considerar esto en los cálculos financieros.
• Cuidado con las decisiones estresantes. Algunas personas no disfrutan las sorpresas, por lo que es clave gestionar bien la forma en que se presentan elementos inesperados.

Feedback del día 28/02

Feedback relacionado con la presentación

• Mejorar el orden y la linealidad de las secciones de la presentación para favorecer una presentación más dinámica y fluida. El MVP, junto con la Idea de negocio, deben presentarse en las primeras secciones de la presentación.
• En la sección de análisis de costes, indicar si los datos han sido calculados en neto o en bruto y tener en cuenta los costes sociales, así como mostrar una relación precio/período temporal (€/semana, €/mes, €/año, etc.).
• Evitar el uso de las diapositivas “transición”. No es necesario utilizar diapositivas completas para indicar la sección que se va a tratar a continuación, la idea y todo el contenido tiene que ser más directo.
• Falta de una imagen de marca en cada diapositiva, no basta únicamente con incluir el nombre de la aplicación.
• Algunas diapositivas contienen mucho contenido (texto compacto e iconos) y puede sobrecargar a la audiencia.
• Corregir la falta de tildes en títulos y textos de la presentación. Establecer un estilo fijo a lo largo de toda la presentación (título completo en mayúscula, sólo la primera letra, etc.). Evitar que cada palabra de los títulos comience por mayúscula (generado por IA), en caso de usarse, es necesario una consistencia clara (todos los títulos o ninguno).
• Mejorar la visibilidad de los número de diapositivas y dar un nuevo enfoque a la barra de progreso (enfoque progresivo por secciones frente a un progreso general de toda la presentación).

Feedback relacionado con el desarrollo del proyecto

• Evaluar la idea principal de la aplicación y sus aspectos más importantes, si la aplicación da lugar a un gran número de riesgos de un carácter elevado hay que considerar cambiar el enfoque para mejorar en enfoque de la aplicación.
• Mejorar el plan de contingencia, todos los riesgos deben tener su plan de contingencia asociado. Las cancelaciones pueden llegar a suponer pérdidas y bajar la reputación y el número de usuarios. No basarse en el resto y buscar soluciones efectivas para mejorar estos riesgos/problemas.
• Explicar en detalle el alcance geográfico de la aplicación y su escalabilidad/expansión en un futuro si procede.

Feedback del día 07/03

Feedback relacionado con la presentación

• No presentar secciones que no están contempladas en el guión de la presentación y mantener una linealidad efectiva entre las diferentes secciones.
• Falta de un Killer Opener atractivo y el Elevator Pitch.
• No dedicar tanto espacio en la presentación para la sección de análisis de costes y TCO.
• Sintetizar el contenido de la presentación y mostrar los resultados en lugar del proceso previo de análisis (programa de usuarios piloto, análisis de riesgo, etc.).
• Ampliar el grupo de usuarios del programa de usuarios piloto.
• Mejorar la presentación de la demo para mejorar el aspecto visual.
• Incluir una sección para hablar del equipo de trabajo.
• Incluir el análisis de competidores en la presentación.
• Incluir un estado de progreso a lo largo de las diferentes secciones de la presentación.
• No utilizar anglicismos (la palabra gamificación lo es).

Feedback relacionado con el desarrollo del proyecto

• Falta de un Killer Opener atractivo.
• Detallar información acerca del programa de usuarios piloto.
• Ampliar el grupo de usuarios del programa de usuarios piloto.
• En la sección de análisis de costes y TCO, realizar un análisis de miedos en inversores y diferenciar correctamente entre los ingresos y gastos de la aplicación.
• Mejorar la sección de costes, facilitando su comprensión y visualización. Todo el contenido debe ser consistente y realista.
• Mejorar el análisis de riesgos (considerar la gestión de tareas como posibles causas de retrasos en los tiempos establecidos).
• Cuidar el formato y estilos de la landing page para una mejor visualización.
• Correcta definición de los casos de uso core (gestión de usuarios excluida).
• Incluir en la demostración de la aplicación vistas con contenido y datos reales (no usar pantallas estáticas).
• Seguimiento riguroso del Commitment Agreement.

Feedback del día 14/03

Feedback relacionado con la presentación

• Mejorar el Killer opener para que esté orientado a todo el público y evitar el uso de preguntas abiertas en las que se conoce la respuesta.
• Hablar sobre el alcohol es un tema delicado, en España el 13% de la población es abstemia y existen algunos países donde socialmente no se acepta el consumo de alcohol.
• Las diapositivas contienen demasiado texto y carecen de metáforas visuales. Reducir el contenido de información por diapositiva para mejorar su comprensión.
• Centrar la demostración al core de la aplicación (evitar la muestra de gestión de usuarios) y hacerla más atractiva para la audiencia.
• En la sección de riesgos acontecidos o lecciones aprendidas, exponer en primer lugar los problemas y, posteriormente, la solución implantada así como su análisis y seguimiento.
• Mejorar la sección de Sprint Retrospective de modo que se muestren las debilidades, puntos a mejorar y fortalezas de manera individualizada.
• Mejorar la consistencia en los estilos de las diapositivas, respetar los márgenes y espacios para los títulos.
• Falta de homogeneidad en las imágenes del equipo de trabajo, error que se cometió anteriormente por otro grupo.
• Sintetizar la información necesaria para la presentación, centrándose en las secciones y contenido solicitado. No presentar secciones que no están contempladas en el guión de la presentación (Sprint 3 Backlog) y mantener una linealidad efectiva entre las diferentes secciones

Feedback relacionado con el desarrollo del proyecto

• En la sección de organización del equipo de trabajo, mejorar la distribución o reparto de roles de trabajo (no merece la pena distinguir entre los roles de frontend, backend y full-stack.
• Asumir la aparición de nuevos cambios que conllevarán en la realización de una nueva planificación de tareas.
• En la sección de análisis de costes y TCO, las gráficas han sido claras y concisas. Considerar que el caso realista no tiene que representar la media entre los casos optimista y pesimista.
• En la sección de feedback de usuarios piloto ha faltado centrarse en el propio feedback para su posterior análisis e implementación de posibles cambios/mejoras de la aplicación.

Feedback del día 21/03

Feedback relacionado con la presentación

• Killer opener bastante atractivo y que llame la atención. Intentar no utilizar el recurso de las preguntas abiertas para no seccionar a la audiencia.
• Se ha hablado antes de los competidores que de la propia propuesta de la aplicación, error que se cometió la semana pasada por otro grupo.
• Mantener una linealidad efectiva entre las diferentes secciones de la presentación, respetar los márgenes y espacios para los títulos.
• No se dice Usuarios Pilotos sino Usuarios Piloto.
• Ser consistentes con el idioma empleado a lo largo de toda la presentación.
• Mejorar la presentación de información a través de tablas para mejorar su apariencia y comprensión por parte de la audiencia.
• Las diapositivas contienen demasiado texto y carecen de metáforas visuales. Reducir el contenido de información por diapositiva para mejorar su comprensión.
• Centrar la demostración al core de la aplicación (evitar la muestra de gestión de usuarios) y hacerla más atractiva para la audiencia.
• Hacer más énfasis en el factor diferencial de la aplicación y no definirse como algo que no son.
• Diferenciar claramente las cosas que han ido bien y qué ha ido mal, dividiendo cada información en diapositivas diferentes para una correcta separación del análisis del Sprint Retrospective.
• La gráfica del rendimiento de los miembros del equipo de trabajo ha quedado muy representativa al indicarse la diferencia de trabajo respecto a la semana anterior. De esta forma, se puede llevar un correcto seguimiento sobre los miembros del equipo y su rendimiento por semana.

Feedback relacionado con el desarrollo del proyecto

• En la sección de análisis de costes y TCO, considerar el tiempo del equipo de trabajo como una inversión y no como un coste. Al mismo tiempo, incluir en las gráficas los beneficios acumulados para una correcta visualización del retorno de la inversión. No mostrar las fórmulas empleadas para la elaboración de las gráficas.
• Mejorar el planteamiento de la Storyboard, eliminando el factor “magia” (de repente aparece la aplicación).
• Incluir factores cuantitativos y cualitativos en la sección de análisis de rendimiento del equipo, del mismo modo, es necesario la presencia de una gráfica que indique el rendimiento individual de cada miembro del equipo de manera conjunta.
• Definir correctamente los riesgos, realizar una diferenciación clara respecto a los problemas e introducir una sección de análisis de las medidas llevadas a cabo y su seguimiento.

Feedback del día 28/03

Feedback relacionado con la presentación

• Relacionar el Killer opener con la demostración funcional.
• Cuidado con el lenguaje coloquial, hay límites.
• Mejorar la gráfica de rendimiento del equipo.
• Intentar mirar a toda la audiencia mientras se presenta, no sólo al profesor.
• Minimizar lo que ha ido mal durante el Sprint justificando como se ha solventado.

Feedback relacionado con el desarrollo del proyecto

• Buscar un slogan para la aplicación.
• En la sección del Customer Agreement, incluir el SLA de la aplicación.
• Replantear la idea de que la aplicación solo se pueda usar si eres mayor de 18 años.

Feedback del día 04/04

Feedback relacionado con la presentación

• El anuncio es demasiado extenso. Además hay que implantar un team building.
• En la sección de análisis de costes y TCO, se tiene que añadir el número de usuarios esperado que usará la aplicación.
• Incluir la pantalla del móvil en el anuncio para que se vea mejor.
• Hacer una trazabilidad entre los problemas y las soluciones, indicándose de forma sistemática no de golpe.

Feedback relacionado con el desarrollo del proyecto

• Enfocarse en la demo en las nuevas funcionalidades, no en aquella que no aporten valor.

Feedback del día 11/04

Feedback relacionado con la presentación

• Controlar el tiempo de la presentación, se añadieron 30 segundos a la presentación de manera injustificada. La presentación tiene que durar al menos 14 minutos y nunca llegar a extenderse más del minuto 15.
• Mejorar el Killer opener para incluir de una mejor manera el factor sorpresa que ofrece la aplicación.
• Mejorar el orden y la linealidad de las secciones de la presentación para favorecer una presentación más dinámica y fluida.
• Ser consistentes con el idioma a lo largo de la presentación.
• No usar siglas sin ofrecer su correspondiente explicación acerca de su significado.
• El orador de la presentación no debería de estar mascando chicle durante esta.
• Mantener una estética homogénea en todas las diapositivas (fuentes, colores, estructura, márgenes).
• No se dice Usuarios Pilotos sino Usuarios Piloto.
• En la sección de análisis de competidores y Benchmarking, mejorar la presentación para detallar en mejor medida qué aporta la aplicación frente a los competidores existentes.
• Mejorar la diapositiva de roles de equipo, se podría mostrar al equipo de una manera más generalizada y es necesario incluir la presencia del nuevo departamento de marketing, requisito que se pedía para esta semana y no se ha presentado.
• Utilizar metáforas visuales para apoyar el contenido expuesto a lo largo de la presentación.

Feedback relacionado con el desarrollo del proyecto

• En la sección de análisis de rendimiento del equipo, mejorar la representación del trabajo individual para que sea entendible de una manera más visual. La información aparece muy condensada y el uso de tantos círculos y líneas puede resultar muy confuso.
• En la sección de anuncios, corregir y diferenciar de manera clara qué es un anuncio para inversores o para empresas. En el caso de que fuera un anuncio para empresas, era necesario incluir una explicación más detallada de qué es la aplicación y qué es lo que ofrece.
• Reducir la duración de los anuncios para que se adapten en mayor medida a las actuales y futuras presentaciones.
• En la sección de la demostración funcional, mejorar la visualización a lo largo de todo el vídeo, incluyendo zooms e interactuando con la mascota Sorpresín.
• En la sección de Lecciones aprendidas, detallar en mayor medida los problemas surgidos y no quedarse en la superficie. Para ello, es necesario abordar el problema, comentar las soluciones propuestas y la realizada, así como la evolución del problema tras la aplicación de una solución.

Feedback del día 25/04

Feedback relacionado con la presentación

• No hay que hablar sobre retrospectiva ni nada relacionado con el equipo en esta presentación.
• Falta de información en cuanto al modelo de negocio, de donde sale el dinero, los ingresos, etc.

Feedback relacionado con el desarrollo del proyecto

• En el anuncio de inversores no se ve la pantalla de fondo que se supone que es importante. Además de la falta de opciones de inversiones.
• Incluir la funcionalidad del tema de notificaciones que quedan x días en la demostración funcional.

Feedback del día 02/05

Feedback relacionado con la presentación

• Se sugiere fortalecer el killer opener incorporando de forma más clara el factor innovador del proyecto. Además, para darle mayor realismo y captar la atención desde el inicio, podría emplearse alguna herramienta de inteligencia artificial (por ejemplo, simular la caída del PM mediante IA).
• El segundo anuncio, que ha generado gran popularidad de forma inesperada, debe integrarse en la sección de marketing. Se recomienda mencionarlo como un fenómeno de alcance orgánico, mostrando métricas concretas y utilizándolo como argumento de validación del producto o de su atractivo en redes sociales.
• Corregir los errores ortográficos y la cohesión y coherencia del mensaje en las presentaciones y en el contenido subido a GitHub.

Feedback relacionado con el desarrollo del proyecto

• Algunos anuncios presentan deficiencias en audio e iluminación. Es fundamental preparar correctamente el entorno de grabación para asegurar una calidad audiovisual profesional.
• En la demostración funcional del producto, sería conveniente remarcar la funcionalidad donde, si el usuario descarta más categorías de lo habitual, se le indique que deberá pagar un coste adicional.
• Si se establece como objetivo la obtención de una gran cantidad de opiniones de usuarios, es necesario plantear mecanismos de incentivo. En caso de incorporar recompensas, estos costes deben estar presentes en el TCO.
• Las keywords actuales son demasiado genéricas. Se sugiere probar con términos más específicos y relacionados con situaciones reales del usuario, por ejemplo: “estoy aburrido”.

Grupo 11 - Pawtel

Feedback del día 14/02

Feedback relacionado con la presentación

• La presentación es demasiado plana y simple, sin una identidad visual fuerte.
• Falta Imagen Corporativa (IC) en las diapositivas, lo que haría que el proyecto se vea más profesional y estructurado.
• El discurso necesita más enfoque y claridad, ya que la idea no está bien aterrizada y la presentación va “de aquí para allá” sin un hilo conductor claro.

Feedback relacionado con el desarrollo del proyecto

• El público objetivo no está claramente definido, lo que dificulta orientar la presentación y el desarrollo del proyecto.
• El público al que va dirigido puede no estar interesado, por lo que es necesario replantear su enfoque.
• Necesita un análisis más profundo de la audiencia para asegurarse de que el producto tenga demanda real.
• El concepto de “dating” presenta desafíos complejos que requieren una revisión más profunda.
• Es una idea ya muy explotada, similar a muchas redes sociales existentes, por lo que necesita un factor diferenciador claro.
• No se percibe como innovador, por lo que habría que enfocarse en qué la hace distinta a otras soluciones en el mercado.
• Es necesario definir mejor el valor diferencial del proyecto para justificar su propuesta.

Feedback del día 21/02

Feedback relacionado con la presentación

• Uso de varios estilos y tipografías, lo que genera inconsistencia visual.
• Letra demasiado pequeña y compacta, dificultando la lectura.
• Falta organización en las secciones de la presentación, especialmente en la parte de la idea de negocio.
• Se ha detectado ruido durante la presentación, lo que ha dificultado la claridad del mensaje.
• No se han incluido números de pie de página.
• La imagen corporativa de la aplicación no aparece en todas las diapositivas.
• Falta de claridad en las tablas comparativas del benchmarking y análisis de riesgos.
• Referencias a páginas web conocidas como Booking o Trivago sin suficiente justificación.
• El índice de la presentación no se lee.
• Presentación amena y llamativa en general, pero con margen de mejora en estructura y claridad.
• Falta de ortografía detectada en la presentación.
• El tiempo de la presentación debe estar mejor controlado para optimizar la transmisión de información relevante.
• Se ha invertido poco tiempo en los mockups, quitándoles importancia.
• La sección de preferencias del equipo podría estar mejor estructurada.
• Durante la presentación, sólo las personas que estén exponiendo deberían hablar con el profesor.
• No se han explicado bien ciertos conceptos clave como "strike", "amarilla" y "roja", ni su impacto.

Feedback relacionado con el desarrollo del proyecto

• Se ha dedicado demasiado tiempo a explicar lo que no es en lugar de centrarse en definir claramente lo que sí es.
• Es necesario definir un concepto inequívoco y eliminar cualquier ambigüedad. En este caso, se debe usar "residencia para mascotas" en lugar de "hoteles para mascotas".
• Se debe eliminar el ruido en torno al MVP y ser más directos.
• La idea de negocio es buena, pero necesita más detalles.
• Se han mencionado términos incorrectos o ambiguos.
• No se ha realizado un análisis adecuado de las soft skills del equipo.
• El esquema de soft skills no se entiende bien y debe explicarse mejor.
• Muchas decisiones presentadas carecen de justificación basada en datos.
• El impacto del bajo rendimiento no está explicado.
• Las decisiones deben estar respaldadas por datos y no ser gratuitas.
• No se ha dejado clara la forma de monetización.
• No se ha incluido la función de pago como un caso de uso core, lo cual es un error.
• El volumen de ventas parece aleatorio y debe justificarse con datos concretos (por ejemplo, basado en un porcentaje del mercado español o global).
• En lugar de darle la razón al público sobre sus intereses, se debe estudiar la viabilidad y diferentes opciones de monetización y control de ingresos y costes.
• Exceso de personas en roles de liderazgo (+30% de la plantilla en funciones directivas es demasiado).
• Los mockups actuales se asemejan demasiado a Booking.
• Falta detalle en los mockups, lo que puede hacer que la aplicación parezca poco diferenciada frente a la competencia.

Feedback del día 28/02

Feedback relacionado con la presentación

• Presentación con un buen opening para enganchar a la audiencia, pero no preguntar por mascotas y acto seguido centrarse en el campo de aplicación para perros.
• Corregir la falta de tildes en títulos y textos de la presentación. Establecer un estilo fijo a lo largo de toda la presentación (título completo en mayúscula, sólo la primera letra, etc.). Evitar que cada palabra de los títulos comience por mayúscula (generado por IA), en caso de usarse, es necesario una consistencia clara (todos los títulos o ninguno).
• No hay número en las diapositivas.
• No hay márgenes en las diapositivas.
• Demasiado texto en algunas secciones e ilegible.
• Utilizar un mismo estilo, tipografías e imagen corporativa durante la presentación.
• Las imágenes del grupo de trabajo además de no ser homogéneas no tienen el mismo tamaño ni disposición.
• No es necesario dedicar tiempo a la lectura del índice.
• Manera interactiva y dinámica para mostrar los casos de uso core de la aplicación.
• Establecer una persona temporal durante la presentación (corregir el uso de la 1º persona del singular y plural).
• Mejorar la presentación del Stack tecnológico (difícil comprensión, si es necesario, incluir el nombre de las tecnologías menos conocidas. Las stats “modo FIFA” no tienen ningún sentido en cuanto a reparto de habilidades. La gráfica no puede “estar volcada a la derecha”, que significa “resolución de problemas” y que la propia gráfica cuente con una habilidad “liderazgo” en la parte izquierda y que sea la más baja de todas las habilidades del equipo.
• Mejorar la transición de presentadores.
• La sección de agradecimientos y “Hall Of Shame” se ha presentado como algo “offtopic” para llegar al tiempo indicado para la presentación.
• Los presentadores de la presentación (únicas personas que se han presentado al comienzo) deberían ser las únicas personas que se encarguen de resolver cualquier cuestión o aspecto pedido por los alumnos o el profesor.

Feedback relacionado con el desarrollo del proyecto

• Mejorar el análisis de competidores (hay que destacarse de los competidores, ofrecer soluciones con menos funcionalidades/prestaciones que ellos puede resultar en algo incongruente).
• Detallar la reserva de contingencia durante el análisis de riesgos y el plan de contingencia (si se dice que es un 10%, que se indique sobre qué).
• Establecer un análisis de costes con un mejor enfoque. Un promedio de precio entre 10-25€ (la diferencia supera al precio más bajo estimado) es demasiado amplio. Todos los datos deben ser realistas y estar respaldados con páginas fiables (no utilizar los datos de la Junta de Andalucía).
• Cambiar el enfoque y abrir la solución tecnológica a más mascotas. Actualmente, tiene muchas similitudes con Petclinic.

Feedback del día 07/03

Feedback relacionado con la presentación

• El número de diapositivas no es visible.
• Sintetizar el contenido de la presentación y mostrar los resultados en lugar del proceso previo de análisis (seguimiento de riesgos, lecciones aprendidas, etc.).
• No utilizar anglicismos.
• Las diapositivas contienen demasiado texto y carecen de metáforas visuales. Reducir el contenido de información por diapositiva para mejorar su comprensión.
• Las diapositivas contienen errores ortográficos.
• En un contexto académico no es necesario explicar el diagrama UML.
• Mejorar el estado del progreso de las diferentes secciones de la presentación.
• Incluir el uso de la IA en la presentación.

Feedback relacionado con el desarrollo del proyecto

• Incluir en la demostración de la aplicación vistas con contenido y datos reales (no usar pantallas estáticas). Contar una historia.
• En la sección del Sprint 1 Retrospective.
• En la sección de organización del equipo establecer más roles además de los relacionados con la programación en backend y frontend.
• En la sección de planificación y seguimiento de tareas se ha realizado un trabajo exhaustivo y muy completo.

Feedback del día 14/03

Feedback relacionado con la presentación

• Mejorar el Killer opener para que sea más atractivo y directo.
• No mezclar dimensiones en las gráficas (nº de usuarios, dinero, búsqueda, etc.).
• Evitar el uso de gráficas muy actuales. En el caso de aparecer el año actual, tratarlo como una estimación con la información actual proporcionada.
• Evitar el uso de diagramas de colores y simplificar el contenido mostrado en dichas gráficas para mejorar la visualización de los datos.
• Falta de homogeneidad en las imágenes del equipo de trabajo, error que se cometió anteriormente por otro grupo.
• No utilizar anglicismos en las diapositivas y evitar emplear términos que no son correctos (utilización de sobresaltado en lugar de sobresalido).

Feedback relacionado con el desarrollo del proyecto

• En la sección de análisis de costes y TCO, los costes asociados no pueden mantenerse constantes a lo largo del tiempo.
• En la sección de riesgos acontecidos o lecciones aprendidas, exponer en primer lugar los problemas y, posteriormente, la solución implantada así como su análisis y seguimiento.

Feedback del día 21/03

Feedback relacionado con la presentación

• Buen Killer opener, quizás un poco extenso porque se ha tardado mucho tiempo en introducir la aplicación, pero es necesario vincularlo con el resto de la presentación (incluido el Storyboard) para que se cuente una historia completa y que enlace con las diferentes secciones de la presentación en todo momento.
• Falta de homogeneidad en las imágenes del equipo de trabajo, error que se cometió anteriormente por otro grupo.
• Mencionar los casos de uso que vamos a ver y no en la demostración.
• Mejorar la última diapositiva para que contenga más información de la aplicación.
• Centrar la demostración al core de la aplicación (evitar la muestra de gestión de usuarios).
• Tomarse de una manera más seria la sección de feedback del profesor como críticas constructivas sobre mejoras a incluir tanto en la presentación y el proyecto.
• La presentación debe ser autocontenida y no se puede mencionar en ningún momento aspectos expuestos en semanas anteriores.
• Mantener una linealidad efectiva entre las diferentes secciones de la presentación, respetar los márgenes y espacios para los títulos.

Feedback relacionado con el desarrollo del proyecto

• En la sección de análisis de costes y TCO, diferenciar claramente entre los términos CAPEX y OPEX (los gastos operativos no pueden ser tratados como CAPEX).

Feedback del día 28/03

Feedback relacionado con la presentación

• Killer opener bastante completo pero algo extenso (apróximadamente 2 min.)
• La presentación va demasiado rápida, no da tiempo a procesar la información. Debería haber de 20 a 60 seg. por transparencia.
• El presentador enumera sin cerrar, siempre termina con un etcétera, aspecto que confunde a la audiencia.
• Unificar los estilos de los Storyboards (algunas partes están hechas con IA y otras se ve que no lo están y tienen un estilo diferente). Además contar los Storyboards de manera independiente.
• Se debería hilar con la demo el killer opener, y utilizar la mascota presente en la presentación también, para tener una mayor consistencia.
• En el análisis de competidores, se debería minar más la principal funcionalidad de la aplicación, son un comparador.
• Dar dígitos a los inversores, y ser más precisos en los números. Mejorar el tema de cuadrantes en el rendimiento del Sprint, es confuso poner directamente el cuadrante sin enseñar una vista general previamente.
• En el análisis de código con Codacy hay que poner la evolución y tal respecto otras semanas. Además, no es tan importante los números tal cuál en los errores de la calidad del código.
• En la demo normalizar los precios, si son por días o la reserva en general.
• El tema de rangos en la aplicación solo utilizarlos cuando sea necesario, ha utilizado rangos “min:20” y “max:20”.
• Intercalar problema-solución, y no hacer primero todos los problemas y todas las soluciones.
• Buena idea la del mediador, falta explicar cómo se ha efectuado y cómo de efectivo ha sido.
• Dar más información del bajo rendimiento de la mitad del grupo.

Feedback del día 04/04

Feedback relacionado con la presentación

• Buen Killer opener que va directo al grano, pero conviene elegir el vocabulario adecuado a la audiencia y no utilizar palabras técnicas en otro idioma.
• No se debe explicar una idea después de dar por sentado que la idea está comprendida por el público.
• Representar los números de manera 1K en vez del número en crudo.
• En la parte de protección de datos, no debe decirse qué no debe hacerse ya que es anticlimático.
• En la diapositiva del vídeo de la demostración funcional, eliminar el enlace local y utilizar un hipervínculo oculto o un icono llamativo.
• Mejorar la representación y visualización de los ejes en todas las tablas de información.
• Se debe explotar más las palabras claves: comparador y mascota.

Feedback relacionado con el desarrollo del proyecto

• Cómo calculan el rendimiento no está muy bien, ya que alguien con 20 horas tenga el mismo rendimiento que alguien con 6 horas parece de broma.
• El cálculo del rendimiento no está muy bien definido, ya que a pesar de la gran diferencia de horas entre algunos miembros tienen un rendimiento similar.

Feedback del día 11/04

Feedback relacionado con la presentación

• Se ha llevado un buen hilo argumental al comienzo de la presentación, conectando correctamente el Killer opener, los anuncios y los Storyboards.
• Mejorar el orden y la linealidad de las secciones de la presentación para favorecer una presentación más dinámica y fluida.
• La sección de Team building y el Hall Of Fame está muy conseguida, aunque es necesario evitar usar esta última como medida para alargar la presentación por falta de contenido y mala organización.
• La presentación tiene que durar al menos 14 minutos y nunca llegar a extenderse más del minuto 15.
• En la sección de análisis de costes y TCO, mejorar la representación de los valores de los ejes para que sea más visual y entendible para la audiencia. Al mismo tiempo, hablar de Gastos y no de Pérdidas.

Feedback relacionado con el desarrollo del proyecto

• En la sección de anuncios, mejorar el uso de la IA en estos para unificar el idioma empleado a lo largo de los vídeos. Aún así, está muy bien introducir subtítulos para que el mensaje del anuncio llegue a toda la audiencia.

Feedback del día 25/04

Feedback relacionado con la presentación

• La historia inicial no es realista, no tiene que ver con el producto. Necesita un enfoque más visual y utilizar apoyo en las diapositivas de la propia presentación.
• Problemas técnicos con la presentación.
• Disonancia entre audio y video.

Feedback relacionado con el desarrollo del proyecto

• Si solo monetizan de la comisión de reserva, pueden perder dinero si hay otro medio de comunicación entre dueño y propietario de hotel.
• Dar importancia a la estacionalidad del negocio ya que es un punto importante en este proyecto en concreto.

Feedback del día 02/05

Feedback relacionado con la presentación

• Probar previamente todo el material técnico antes de la presentación para evitar fallos en directo. Tener planes de sobra por si algo falla.
• No es necesario detallar tanto la composición del equipo (backend, frontend); en el WPL basta con explicar los roles de forma general.
• Evitar el uso de acrónimos como CAPEX y OPEX en la presentación, ya que pueden no ser comprendidos por toda la audiencia.
• Aclarar que los datos de registrados en la plataforma son potenciales, no reales.
• Reestructurar la sección de posicionamiento digital para mejorar su claridad y coherencia dentro de la presentación.

Feedback relacionado con el desarrollo del proyecto

• En el análisis de costes y TCO, incluir el gasto asociado a los Pawpoints.
• Eliminar el número de página visible en el anuncio mostrado durante la presentación.