Aportaciones a la BCC - Sprint 2

Universidad de Sevilla

Escuela Técnica Superior de Ingeniería Informática

Grado en Ingeniería Informática – Ingeniería del Software

Curso: 2024 – 2025
Fecha: 09/04/2025
Versión: v1.3

Grupo de prácticas: G1
Nombre del grupo de prácticas: ISPP - Grupo 1 - Holos

María del Mar Ávila Maqueda
Joaquín González Ganfornina
Nerea Jiménez Adorna
Juan del Junco Obregón
Miguel Ángel Gómez Vela
Juan Antonio Moreno Moguel
María del Carmen Barrera Garrancho
Daniel Guedes Preciados
Julia Virginia Ángeles Burgos
Javier Muñoz Romero
Juan Núñez Sánchez
Nicolás Pérez Gómez
Francisco Pérez Lázaro
Celia Aguilera Camino
Gabriel María Vacaro Goytía
Ignacio Warleta Murcia
José María Portela Huerta

Responsables:

Miembro	Responsabilidad
Gabriel Vacaro	Redactor
María del Mar Ávila	Revisora

Repositorio: GitHub - Holos-INC

Base de conocimiento Comun Base de conocimiento común

Control de Versiones

Fecha	Versión	Descripción	Autor
13/03/2025	v1.0	Creación de documento	Gabriel Vacaro Goytia
13/03/2025	v1.1	Modificación Portada	María del Mar Ávila
25/03/2025	v1.2	Aportaciones del Sprint 2	Gabriel Vacaro Goytia
09/04/2025	v1.3	Añadido texto exacto de cada aportación	Gabriel Vacaro Goytia

Índice de Contenidos

Introducción
Aportaciones realizadas a la BCC
2.1 Sprint 1
2.2 Sprint 2

1. Introducción

En este documento se detallarán las contribuciones realizadas a la base de conocimiento común de la asignatura ISPP 2024-2025: Base de conocimiento común.

2. Aportaciones realizadas a la BCC

Sprint 1

En este primer sprint, se han compartido con el resto de grupos de la asignatura todo el feedback recogido tanto por los propios miembros del grupo durante las presentaciones, como las aportaciones de los compañeros ajenos a este y de los profesores durante el tiempo de feedback. Esta aportación es completa, pues se recogen de forma separada tanto los aspectos positivos como los negativos desde el punto de vista de los estudiantes que conforman el Grupo 1. Esta aportación puede verse: aqui

Aportación exacta:

Semana 1

Convivio

App para gestión de convivencia en pisos.

Feedback de estudiantes

No ha quedado claro que problema estamos intentando solucionar, es decir, nuestro factor diferenciador.

Feedback de profesores

No tenemos claro el alcance de la aplicación, pregunta si alguien perteneciente a una finca podría usar también la app. Portela responde que esta más orientado a pisos.

La profesora entiende que es mas individual. Además se aclara que habrá trabajadores acreditados que participen y que puedan ser elegidos para arreglar incidencias. La profesora no tiene mucha fe en la idea, piensa que ya existen, no ve una necesidad en aunar dos aplicaciones distintas ya existentes como el chat con el casero y el solver de incidencias.

Le ha gustado a la profesora el tema de los incentivos pero dice que no podemos asegurar mucho como desarrolladores en el tema de las reseñas.

Semana 2

Holos

App para venta de obras de artistas.

Feedback de estudiantes

Desde su perspectiva si la "IA" vuelve a fallar sería grave

Tenemos planteado competir o cooperar con la IA? tenemos pensado competir, con flitros anti IA y cosas varias

No se veía la tabla de competidores, mala elección de dimensiones.

En el commitment agreement es bastante probable que se compinchen personas para blindar a alguien y que no lo echen. Podemos usar el logo como marca de agua para que no ocupe espacio.

Feedback de profesor

Hay un competidor que solo tiene una cosa, respondemos que esta puesto para dar a entender que nosotros aunamos esa característica

El orden de la presentación es raro, los competidores no deberían estar tan al final.

Le gusta que le hayamos puesto corazon, pero ve mal enfocada la presentación, no ve cuales el propósito general de la aplicación y el quiere saber cual es el caso de uso core, además no hemos hecho caso al feedback, nos dijo que no tiene sentido las dimensiones usadas en las diapositivas (no puede ser que no se vean cosas en la presentación).

El valor diferencial no queda claro, deberíamos aclarar como trabajan actualmente los artistas y que aportaríamos, que es lo que no pueden hacer y por que funcionalidad concreta estarían dispuestos a pagar los artistas.

A nivel de delivery, no es aceptable que no se vea la presentación ni destacar los casos de uso core.

Hay cosas como perder tiempo en el índice, en una estructura del equipo, el nivel de detalle cree que no ha sido el correcto, todo es valido mientras no ignoremos el feedback.

La frase de cuando ha salido la presentación del mock up de "sabemos que no se puede ver bien", es fatal.

Semana 3

Holos

App para venta de obras de artistas.

Feedback de estudiantes positivo

Inicio impactante que capta la atención de inmediato.
Uso acertado de un comentario ligero/chascarrillo para conectar con la audiencia.
Explicación clara del problema y la propuesta de valor: qué somos y qué necesidad resolvemos.
Presentación estructurada con ejemplos que facilitan la comprensión.
Diferenciación frente a la competencia bien señalizada.
Priorización correcta del inicio potente antes de la presentación formal.
Interacción natural con el público, fomentando la participación.
Diseño visual atractivo y bien organizado.
Casos de uso core expuestos de manera concreta.
Frases con gancho que refuerzan el mensaje, como “Con Holos lo tienes todo centralizado”.
Mockups claros e interactivos.
Inclusión de ejemplos llamativos para captar la atención.
Planes de negocio bien detallados, con costes y rentabilidad visibles.
Estrategia acertada al introducir ejemplos erróneos para estimular la participación.
Explicación precisa de las funcionalidades y el papel de la IA.

Feedback de estudiantes negativo

Hubieron problemas para empezar la presentación que tardaron bastante en resolverse, lo cual nos restó mucho tiempo de feedback de los profesores, si bien puede no haber sido nuestra culpa, hay que tratar este asunto con el grupo anterior para que no se repita.
La conexión entre el presentador y el pasador de diapositivas podría ser más fluida.
Algunas muletillas (ej. “eee”, “estilo”); se pueden corregir con pausas más conscientes.
Pequeño tropiezo en la explicación de las gráficas de entrevistas; convendría mayor familiarización con esos datos.
Evitar frases como “en las diapos no está reflejado”, ya que pueden generar dudas sobre la preparación.
No es recomendable restar valor a la propuesta diciendo que “no somos excesivamente buenos”.
El nivel de detalle en el versionado podría no ser relevante para el cliente; reconsiderar su inclusión en la presentación.

Feedback de profesor (Pablo)

La principal área de mejora es la gestión del modelo de negocio. Es mejor centrarnos en las comisiones y que los encargos sean gratuitos; no optaría por precios fijos en los planes, ya que pueden convertirse en una barrera. No le ve mucho sentido.

Feedback de profesor (Cristina)

La presentación ha mejorado mucho; la idea se entiende mejor.
Al principio, el presentador estaba nervioso, pero la exposición ha mejorado a medida que avanzaba la presentación.

Semana 4

Holos

App para venta de obras de artistas.

Feedback positivo de estudiante

Aunque ha habido problemas, todo el mundo ha cantado el inicio efectivo.
Presentación muy clara y visible.
Al decir “somos tan buenos” damos confianza al cliente.
Letras muy claras, se ve todo.
Muy bien realizadas las diapositivas de presentación del equipo, muy visuales.
Explica bien la necesidad del tablero kanban y los problemas de organización, así como los plazos de las tareas y qué soluciones hemos tomado para abarcar estos problemas.
Explica las métricas y la necesidad de un tablero Niko-Niko, cosa que solo este grupo posee.
Ha mejorado mucho en el no uso de muletillas.
Hacia la mitad de la exposición se ha calmado en gran medida y ha mejorado la exposición.

Feedback negativo de estudiante

Inicio efectivo fallido, con problemas de sonido y coordinación.
Se le nota muy acelerado y nervioso.
Mala coordinación al pasar las presentaciones. Poco ensayado.
No se ve el prototipo.
La gente puede no conocer el término “ladybug egipcia en Jerez”.
No se ven las horas del Clockify, pasó lo mismo la última sesión.
El plan de negocio parece raro con solo 2 slots y 7 imágenes.

Feedback de profesores (Cristina)

La apariencia ha mejorado muchísimo. Se veía muy bien, quitando la demo.
En la diapositiva 8, el tema de los costes se debería desglosar un poco más, porque solo hay un resumen muy grande.
La demo debe verse, aunque sea complicado, hacer zooms.
Contarlo de manera dinámica como una historia, explicar los roles que intervienen e intentar hacerlo más entretenido.
En la retrospectiva, empezar por lecciones aprendidas es comenzar por el final.
No se ha hablado de problemas en una única diapositiva. La retrospectiva es muy importante: primero los problemas y luego las lecciones aprendidas.
Ya no se habla de riesgos, sino de problemas. Un problema no es una lección aprendida.
No se ha comentado nada sobre el uso de la IA.
Nada sobre el commitment agreement. Es importante mencionar su cumplimiento.

Feedback de profesores (Pablo)

En el inicio efectivo, capta la atención, lo cual es muy bueno, pero debe estar relacionado con el factor diferencial de la aplicación.
Tiene el potencial de ser un gran comunicador, pero debe hacer ejercicios de vocalización.
Necesita ensayos para mejorar las pausas. Si sigue ese camino, se convertirá en un comunicador impresionante.
Explorar la IA como catalizador de la creatividad para expandir ideas del artista: qué colores se usaban en el antiguo Egipto, qué símbolos, etc. Dar ideas textuales para estimular la creatividad del artista.
Se comete el error de afirmar rentabilidad sin hablar del volumen de mercado, qué porcentaje del mercado pensamos obtener y qué porcentaje es necesario para ser rentable. IMPORTANTE.
No ve necesario el chat, no lo considera crítico. Se deben priorizar funcionalidades diferenciadoras más específicas.
En cuanto al burnup: problema grave de gestión. Deberíamos tener todas las tareas listas desde el principio.
Felicita el uso de Canvas.
Le encanta la presentación.

Grupo 2 - GastroStock

Semana 1

GEZSTOCK

Ayuda a la gestión de inventarios y mejora de logística mediante IA, publico objetivo: PYMES

Feedback de estudiantes

Le ha encantado la idea pero hay dos cosas que no le gustan:

¿el software se ejecuta desde un servidor externo o hay que tener una maquian? ¿Cómo se integraría en cada local? No han sabido responder muy bien

¿Se han planteado usar las APIs de chatGPT y deepSeek? si

De nuevo se pregunta por si será fácil la integración por parte del cliente para usar la app, responden que tendrán un trabajador de mantenimiento. Los costes iniciales son elevadísimos para los usuarios piloto.

Como harían de forma técnica la implementación de la IA. quizás usen API o quizás entrenen un modelo simple con las características mas básicas.

Feedback de profesores

Entiende el objetivo, hay muchos retos, no sabe hasta que punto van a implementar los chats (responden chatbot), dice que debe de haber un análisis de competidores mucho más extenso, quiere una tabla comparativa entre análisis de competidores y el grupo, con lo bueno y lo malo de la comparativa.

Le ha gustado el orden de presentación (no presentar el equipo justo después del nombre porque la gente desconecta),No le gusta la forma de presentar (han leído mucho el DAFO). Mucho texto en la presentación, debe ser mucho mas agiles, metáforas visuales, no tanto texto. Falta paginación. Le ha gustado mucho que hayan hecho un sondeo de los usuarios piloto, piensa que son demasiado ambiciosos al decir que funcionará en todos los sectores.

Se debe especificar mejor los salarios, mayor transparencia, más detalles, les falto el coste de mantenimiento.

Semana 2

GastroStock

Ayuda a la gestión de inventarios de bares y mejora de logística mediante IA.

Feedback de estudiantes

Enfoque correcto, pero le sigue chinando como se va a usar la IA, al no usar internet la ia deberá ir integrada y quizás la app pese mucho. Como lo ejecutaran los móviles in tarjeta grafica integrada?

Feedback de profesores

buen speach inicial buena soltura.

-mucha ambición.

-logo bastante malo.

-buen estudio de viabilidad y rentabilidad

-legibilidad baja, letra pequeña, mucho texto.

en el DAFO no han puesto los enlaces a la normativa, responde que NO existe, pues es suya propia.
le gustaría ver el equipo y las responsabilidades.
redondear costes.
como ponente le ha llamado la atención a la gente, tiene talento el chaval.
Fluia mal la conexión con el que pasaba la presentación.
Decir cosas muy informales choca un poco.
reconocer las carencias en las preguntas de los compañeros
como haya una sola palabra en una presentación que no se vea es un suspenso directo

Semana 3

GastroStock

Ayuda a la gestión de inventarios de bares y mejora de logística mediante IA.

Feedback de estudiantes positivo

Inicio potente que capta la atención de inmediato, transmitiendo mucha energía.
Desde el primer momento, se deja claro en qué se diferencia la app y a quién va dirigida.
Presentaciones muy claras, con una cantidad adecuada de texto para evitar sobrecargar.
Uso de storytelling (ejemplo: chicharrones) que involucra al público y mantiene el interés.
Gran contraste entre fondo y texto, garantizando una excelente visibilidad.
Tamaño de letra bien ajustado para facilitar la lectura.
Justificación sólida del modelo de negocio con datos sobre los gastos en bares.
Uso acertado de diapositivas con estilo de periódico/noticia, muy claras y efectivas.
Inclusión de datos relevantes que captaron la atención del público.
Implementación de una recompensa para los usuarios piloto.
Clasificación de competidores amena y visualmente clara, resaltando el factor diferenciador.
Integración de un plan Freemium como estrategia de acceso.
MVP bien definido y explicado.
Se nota una preparación sólida de la presentación, sin dudas ni titubeos.
Acertada combinación de mockups con el desarrollo de los sprints.
Roles bien definidos dentro del equipo.

Feedback de estudiantes negativo

En algunas palabras, la pronunciación varía ligeramente, aunque no afecta la claridad del mensaje.
El cambio de presentador ha reducido la energía de la presentación, haciéndola parecer más plana en comparación con la fuerza inicial. La proyección de la voz podría mejorarse para mantener el ímpetu.
La sucesión de demasiados mockups seguidos puede resultar desorientadora para la audiencia.
El comentario sobre que los costes "no le importan a nadie" no es adecuado; podría reformularse para agilizar la exposición sin restar importancia al tema.
La falta de tiempo ha generado bloqueos, lo que ha afectado el ritmo de la presentación.

Feedback de profesor (Pablo)

Es necesario realizar más ensayos para optimizar el tiempo y evitar bloqueos.
Se ha señalado que la clave del éxito radica en la facilidad para añadir productos, pero esto no se percibe claramente en los mockups presentados, que parecen los mismos de siempre. No se ha mencionado nada sobre la gestión de los usuarios piloto.
Falta información sobre la cantidad exacta de usuarios piloto; se menciona que hay 15 bares y restaurantes, pero no se ha especificado cuántos usuarios hay dentro de ellos.
Algunas imágenes aparecen distorsionadas, lo que puede dar una impresión de falta de atención al detalle y afectar la percepción de confianza en el equipo y su producto.

Feedback de profesor (Cristina)

La ausencia de números de página dificulta la navegación por la presentación.
Es necesario incluir una tabla comparativa de competidores para destacar mejor las diferencias clave.
Se recomienda analizar en qué situaciones es más o menos conveniente asumir riesgos.
Falta la inclusión de una landing page, un elemento clave para la captación de usuarios.
Se han definido demasiados usos core para el S1, lo que podría afectar la focalización y ejecución.

Semana 4

GastroStock

Ayuda a la gestión de inventarios de bares y mejora de logística mediante IA.

Feedback positivo de estudiante

Inicio efectivo bueno.
Han mejorado el logo.
Muy buena presentación. Empiezan en orden, hablando brevemente en que consiste la aplicación.
Muy buenas diapositivas. Tienen el texto justo y muchas metáforas visuales.
Muy buena tabla de análisis de competidores pero no se entienden algunos iconos.
Se ve muy bien todo. Tamaño de fuente muy bueno.
Han ido cara a cara a reclutar cada usuario piloto, cercanía con el cliente.
Buen desglose de trabajo para cada uno de los sprints

Feedback negativo de estudiante

Parece que no tienen prototipo, muestran mockups.
Solo tienen hasta ahora 13 usuarios piloto, lo cual quizás sea indicativo de algo.
Notificación durante la presentación.
No hay QR a landing page

Feedback de profesores (Cristina)

No dio tiempo. Feedback de profesores (Pablo)
No dio tiempo.

Grupo 3 - EVENTBRIDE

Semana 1

EVENTBRIDE

Aplicación para gestionar eventos cristianos; bodas, bautizos y comuniones

Feedback de estudiantes

Portela preguna sobre los beneficios por comisiones, dice de usar el chat para buscar proveedores, y luego contactar fuera con los proveedores fuera de la app. Como respuesta le dicen que como van a hablar con muchos proveedores, no sería nada cómodo hacer eso de manera continua, y que el beneficio de la comodidad merece la pena.

Algunos compañeros no saben que ofrecen realmente, no lo ven realista ( la clase murmura con excepticismo)

Dicen que Bodas.net es un competidor demasiado potente en el mercado, cuando un compañero ha preguntado por esta página, en el grupo se han reido todos, como respuesta dicen que sus costes van a ser más baratos y que ofrecen ventajas como mensajes esporádicos, el objetivo de la aplicación es para las personas que quieren hacer eventos "con prisa".

¿Se puede hacer para bodas que no sean cristianas? por supuesto

Feedback de profesor

La profesora entiende las dudas de los alumnos, piensa que algunas cosas pueden ser útiles, como en el caso de conocer de antemano las empresas proveedoras, poder ser contratadas "con un click" lo que favorece la velocidad.

Ampliar análisis de competidores, solo tienen 5.Como positivo dice que la imagen corporativa le gusta, pero que la presentación tiene una mala elección de colores, no se puede leer, faltan los números de pagina y los mockups no se alineaban nada con la aplicación. Mala elección de las dimensiones de los cuadros de texto, el titulo ocupaba 1/3 de las diapos. Ha habido diapositivas que no se han presentado (esas deben omitirse)

Le ha gustado el sondeo con las empresas (no han sido empresas realmente, sino usuarios finales).

Los perfiles de usuario se piden más tarde, se ha sorprendido con que lo hayan realizado tan temprano.

Todos tenemos que ahondar mas en los casos de uso y en la tabla comparativa con los competidores.

Semana 2

EVENTBRIDE

Aplicación para gestionar eventos cristianos; bodas, bautizos y comuniones

Feedback de estudiantes

Le ha parecido curioso la "rapidez con la que se elegirían los candidatos", pues quizás quieran debatir el precio. Responden que de todas las opciones elegirán la que mas se adecue.

¿Piensan ampliar a otros eventos? Dicen que por el momento van a conformarse con lo que tienen.

Feedback de profesores

No se han presentado.

El comienzo ha sido muy soso, deja mucho que desear.

El índice se puede saltar, lo primordial es atraer la atención de la gente.

No han dicho el nombre de la empresa.

Han dicho puntos negativos al inicio.

Han mostrado 14 competidores solo. Dicen que tienen muchos mas.

No se ve bien la letra, usar blanco sin un fondo negro no es legible.

Deberían adaptar las luces del aula

¿Cómo han encontrado competidores? Hay que usar la pagina proporcionada de la asignatura para encontrar competidores y hacerlo cada cierto tiempo para que no nos sorprendan.

Se ha perdido en una trasparencia de funcionalidades, no estaba lo suficientemente claro (se han equivocado en una grafica con un titulo distinto).

No han introducido el análisis de riesgo preliminar, y no han comentado el commitment agreement.

No han quedado los casos de uso core en los mock ups

Falta innovación, hay que convencerse a uno mismo antes de venderle la moto a otro

No han tenido en cuenta la infraestructura en el desarrollo en los costes

Semana 3

EVENTBRIDE

Aplicación para gestionar eventos cristianos; bodas, bautizos y comuniones

Feedback de estudiantes positivo

Desde el principio, el presentador explica claramente a qué se dedican, lo que ayuda a contextualizar.
La diapositiva 6, que trata sobre la identificación de proveedores, es muy visual y efectiva.
Los casos de uso core están muy bien definidos y se presentan de forma clara.
El cambio en el diseño de la presentación respecto a semanas anteriores ha sido positivo; ahora se ve más profesional y limpio.
Los resultados de las encuestas a los usuarios pilotos, presentados en la diapositiva 9, son muy claros y fáciles de interpretar.
La separación de competidores por categorías (organizadores, buscadores y navegadores) en la diapositiva 11 facilita la comparación.
Los costes están presentados de manera clara y accesible.
El logo es limpio y elegante, transmitiendo profesionalismo.
Se ha hecho una buena diferenciación de los posibles casos en los análisis de costes.
Los roles dentro del equipo están claramente definidos, lo que mejora la organización.
El reporte sobre el uso de IA, presentado en la diapositiva 27, está muy completo y bien estructurado.
El análisis preliminar de riesgos (diapositiva 29) está bien realizado, con una tabla clara y un buen uso de los colores.
La gama de colores elegida para los mockups aporta profesionalismo y cohesión visual.
El tiempo de presentación se ha gestionado de manera excelente, cuadrando perfectamente con lo previsto.

Feedback de estudiantes negativo

La presentación no transmite mucha emoción ni ilusión; parece carecer de energía o entusiasmo.
El presentador se mostró bastante nervioso, titubeando durante la exposición. Esto puede deberse a falta de preparación o ansiedad.
La cantidad de texto en las diapositivas es excesiva, lo que dificulta la comprensión rápida.
Uso puntual de la muletilla "eee", lo que indica que hay falta de preparación en cuanto a fluidez.
El presentador no realiza barridos de mirada al público, lo que puede hacer que la audiencia se sienta desconectada.
La diapositiva 10 resulta confusa y recargada, lo que dificulta la comprensión del mensaje.
En lugar de una presentación visual, la diapositiva parece más un documento de texto, lo que reduce su impacto.
La tabla comparativa de competidores está demasiado cargada de información, sin aprovechar adecuadamente el espacio disponible.
En general, las diapositivas están excesivamente recargadas, lo que puede distraer a la audiencia.
El "Commitment Agreement" no es visible, y la presentación en general no sigue bien el feedback previamente proporcionado.
Falta incluir el código QR para acceder a la landing page.

Feedback de profesor (Pablo)

Intencionalmente en blanco.

Feedback de profesor (Cristina)

Se ha notado la falta de ensayo, lo que ha generado titubeos y momentos de inseguridad durante la presentación. Es importante practicar más para ganar fluidez.
En algunas partes de la presentación se percibe una falta de confianza, por lo que se recomienda dedicar más tiempo a la preparación.
La diapositiva 4 contiene información redundante, especialmente sobre marketing, que no es relevante en el elevator pitch. Debe centrarse en la idea de negocio.
El orden de la presentación no es el más adecuado, lo que afecta la fluidez de la exposición.
Se observa la falta de una planificación clara de los sprints, lo cual es fundamental para la presentación.
La diapositiva 7, que presenta los casos de uso core, no aporta valor relevante. Es recomendable revisar su contenido o eliminarla.
Faltó incluir el ratio de respuesta de los usuarios piloto, una métrica importante para evaluar la efectividad.
En la diapositiva 27 sobre el uso de IA, sería más efectivo mostrar las conclusiones y resultados alcanzados, en lugar de solo detallar las acciones realizadas.
Se echó de menos una foto corporativa del equipo, lo que ayudaría a humanizar y dar más cercanía a la presentación.
No es recomendable dejar los mockups para el final; deberían presentarse antes para captar la atención del público desde el principio.
El commitment agreement ha sido resumido de manera adecuada en una diapositiva, lo que mejora su comprensión.

Semana 4

EVENTBRIDE

Aplicación para gestionar eventos cristianos; bodas, bautizos y comuniones

Feedback positivo de estudiante

Inicio efectivo muy bueno
Usan la IA en el killer opener para recrear a un tal “ILLOJUAN”.
Explica con un buen nivel de detalle los competidores.
El análisis del coste es bastante exhaustivo
Explican bien los problemas con las horas por persona y el reparto no equitativo de tareas
Buena explicación del problema de subestimar las tareas y replanificación del sprint
Buen Eslogan final.

Feedback negativo de estudiante

No se han presentado
Podrían haber introducido el video en la presentación.
Lleva un papel durante la presentación. Sensación de inseguridad, de no haberse preparado bien.
Mejor poner k para los miles en lugar de m, para evitar confusiones con millones.
No se ve el prototipo.
Han incluido el inicio de sesión o el registro, aunque, aprendiendo del feedback anterior, lo han obviado.
El presentador va muy rápido.
Meten el commitment agreement pero es innecesario.
Dicen muchas veces, que para este problema ya hemos tomado medidas, pero nunca se comentan qué medidas se han tomado.
Mientras ella expone, el otro presentador repasa con el papel.
Se mueve mucho, está muy nervioso. Genera estrés.
Hay diapositivas con mucho texto que no es legible desde largas distancias

Feedback de profesores (Cristina)

Inicio efectivo tiene técnicas buenas: actual, llama la atención y relaciona el problema, pero acaba diciendo “hijos y toda la paranoia” que queda mal.
Han abordado todos los puntos, pero iban muy rápido, muy acelerados.
En el commitment agreement han puesto que todos los miembros han cumplido y esto es necesario ponerlo.
No le convence mezclar la descripción del equipo con el rendimiento.
La demo tiene problemas, no se puede leer. La letra está muy pequeña.
La diapositiva 12, términos y condiciones, no hace falta ponerlo. No aporta nada.
Retrospectiva: Quieren ver más información del rendimiento. Pregunta por los problemas resueltos.
Las medidas tomadas, ¿son de prevención o soluciones para salir del paso?
La traspa 23 no se lee. La fuente no le gusta porque junta mucho las letras. Poner menos información.
Retrospectiva como análisis de cómo ha ido la semana e hilar con lecciones aprendidas.
Poner fecha y plan de acción de usuarios piloto de manera clara.

Feedback de profesores (Pablo)

De acuerdo con el punto 1.0 de Cristina, muy bueno para la asignatura, pero muy malo en un lanzamiento de producto.
En el video, queda patente que los desarrolladores tienen talento creativo, pero lo criticado es el foco, hay que pensar en que se debe hacer un lanzamiento del producto.
Traspa que tenga un tamaño de letra que no se vea: FAIL.
Dicen que tienen particulares, de las 4X personas, si no son personas que van a hacer eventos, ¿qué hacen con la aplicación?
Recomienda hacer una tipología de usuarios piloto. Dividir en este caso los usuarios pilotos por interesados en X evento.
Le preocupa que diga que el texto es un apoyo, las transparencias NO son un apoyo, es un complemento que refuerza tu mensaje. No son unas notas del orador, es un reforzador, hay que ir todos a una.
Metáforas visuales, muy necesarias para reforzar lo que se dice.
No poner cifras exactas de euros, poner K.
El tema de “la cosa es que ChatGPT no nos haga la aplicación” no es un problema y sería válido que lo hiciera, pero tienen que echar 50 horas. Si lo hacen todo en 1h, el resto hay que echarlo en otras cosas.
Es interesante saber si se van a tomar medidas con las pull request a la hora de integrar.
Es más importante la fase InReview que la fase Done.

Grupo 4 - BORROO

Semana 1

Aplicación para generalizar el alquiler de objetos, es de matchmaking-improved market

Feedback de estudiantes

Portela dice: todo muy claro, muy distintivo.

¿Qué pasa si alquilo un objeto y me lo roban? respuesta: se añade una fianza que en función del precio y del producto se calculara y crearán un proceso que administre la incidencia.

Feedback de profesor

Todo lo que dice el profesor se entiende como un feedback para otorgarnos autonomía y busca la mayor profesionalidad posible, desde un punto de vista general, el tema de moderación esta siendo pobre, quiere que el moderador dirija la clase.

Desde el punto de vista de el tiempo, le parece necesario un timer compartido, para que todo el mundo tenga acceso al timer.

Desde le punto de vista de la clase, ver y escuchar el feedback es importante.

Si se interviene, hay que proyectar de forma correcta la voz, respetar el turno.

Para aprovechar el tiempo, el profesor se centra en cosas de mejora, va a ser duro con los grupos.

Feedback propio del grupo: A nivel de delivery y por ser el primer grupo que critica este profesor va a ser más duro:

-El aprovechamiento de la capacidad es horrible. -No se ven las letras. -El uso del texto es muy problemático -Intentar optimizar al máximo la conversación entre el exponente y la presentación (mensajes en sincronia) -Evitar ver las presentaciones como guion -Intentar mirar mas a la audiencia, hacer barridos visuales -Hay que intentar evitar el uso de vocabulario especifico (tecnicismos) ej: matchmaking, springBoot… -Paginado

En relación al mercado:

9 competidores es un DESASTRE ABSOLUTO, inaceptable, 16 personas han trabajado 96 horas, de esas solo 4h han sido dedicadas a buscar competidores No dar respuestas defensivas, si algo salió mal no protestar. En 10 segundos ha encontrado 2 competidores que hacen exactamente lo mismo que su app que el grupo no ha logrado encontrar Quedan muchas mas cosas en el tintero, se le acaba el tiempo.

Semana 2

Aplicación para generalizar el alquiler de objetos, es de matchmaking-improved market

Feedback de estudiantes

Le gusta mucho las imágenes, y en ciertas transparencias la letra es demasiado pequeña.

Feedback de los profesores

aunque han tenido problemas técnicos han sabido retomar el tema

Inicio muy estándar, aburrido.

Uso de metáforas visuales junto con texto ( a veces hay solo imágenes las cuales no se saben interpretar por si solas)

Dice que sus datos de competidores, rentuki hace lo mismo que ellos, y la única diferencia que han puesto es que ellos "no han hecho un mal marketing", responden que tienen otra funcionalidad única.

El DAFO ha parecido un documento de mitigación de riesgos mas que un DAFO propiamente dicho.

Han dicho 10 casos de uso core, la profesora piensa que no todos lo son. que especifiquen bien cuales son los cores.

El coste de marketing le ha parecido muy bajo.

No ha aparecido el equipo.

Tienen 185 competidores, quizás no tengan que poner los que no se centren específicamente.

Semana 3

BORROO

Aplicación para generalizar el alquiler de objetos, es de matchmaking-improved market

Feedback de estudiantes positivo

Desde el principio, queda claro lo que los diferencia: la solicitud de alquileres y pequeños comercios. Esto está bien definido.
El formato de la presentación es claro, y la tabla de competidores está muy bien diseñada y visualmente atractiva.
Se ha dejado un buen espacio para que el público escanee el QR, lo cual es una buena práctica.
Los contenidos de los sprints están bien definidos y se entiende claramente qué se trabajará en cada uno.
Se utilizan pequeños chistes y preguntas al público, lo cual es una buena estrategia para mantener la atención.
Los mockups son claros, aunque la letra podría ser un poco más grande para facilitar su lectura.
Los costes están presentados de forma clara y comprensible.
Los roles de cada miembro del equipo están bien definidos.
Se hace referencia a asignaturas anteriores, lo que añade contexto y familiaridad.
Se han mencionado nuevas adiciones al commitment agreement, lo que muestra flexibilidad y mejora continua.

Feedback de estudiantes negativo

Al inicio hubo un pequeño problema con el puntero, aunque lo solucionaron rápidamente.
Se han utilizado muchas animaciones de transición, lo que puede resultar un poco sobrecargado visualmente.
El presentador se muestra motivado y con ganas, pero en algunas ocasiones no vocaliza lo suficientemente claro. Quizás se podría trabajar en reducir la velocidad y dar más pausa para mejorar la comprensión.
Se han cometido algunos errores gramaticales, como el dequeísmo, lo cual es importante corregir para dar una mejor imagen.
Hay demasiado texto en algunas diapositivas, y el tamaño de la letra es pequeño, lo que dificulta la lectura. Se recomienda usar una fuente más grande (al menos 30 puntos) para hacer las diapositivas más vistosas y legibles.
En cuanto a las imágenes, se plantea la duda sobre cómo se verifica que una imagen es verídica. Sería importante abordar este punto.
Los mockups no son visualmente atractivos, y surge una preocupación sobre qué pasaría si se sube una foto incorrecta (por ejemplo, de un dron mal fotografiado), lo que no se ha tratado adecuadamente.
Falta incluir el QR al final de la presentación, lo cual es importante para que los asistentes tengan acceso fácil a la información complementaria.
La presentación no estaba completamente medida, lo que resultó en que acabara un minuto antes de lo previsto. Para compensar, se rellenó el tiempo con una despedida demasiado larga, lo que podría haberse evitado con una planificación más precisa.

Feedback de profesor (Pablo)

Intencionalmente en blanco.

Feedback de profesor (Cristina)

Al inicio de la presentación hubo un pequeño fallo técnico, lo que afectó la fluidez.
El inicio de la presentación no fue tan impactante ni divertido como se esperaba; se percibió algo más soso. Sería recomendable mejorar el "killer opener" para la próxima vez, para captar la atención desde el principio.
Sería ideal terminar con la landing page para cerrar la presentación de manera efectiva y dejar un buen impacto visual.
En relación al Sprint 1, sería necesario revisar si se han incluido todos los casos de uso core, ya que algunos que se consideran clave parecen estar en el Sprint 2 en lugar de en el 1.
El listado de objetos no parece ser un caso core, por lo que es importante revisarlo y asegurarse de que lo que se presenta es esencial para el MVP.
Hubo confusión sobre el concepto de "anuncio de alquiler", ya que no estaba claro si se refería a la posibilidad de publicar un alquiler o a otro tipo de funcionalidad. Esto debe aclararse para evitar malentendidos.
A la profesora le preocupa que no se estén implementando primero las funcionalidades diferenciales del producto. Es esencial priorizar estas características para que el producto destaque frente a la competencia.
Es necesario revisar las estimaciones de tiempo y esfuerzo para que sean más realistas y alcanzables.
Sería útil añadir métricas como el ratio de respuestas de los usuarios pilotos para medir la efectividad y el alcance de las interacciones.
Los usuarios pilotos no fueron mencionados en la presentación, lo cual es un aspecto clave que debe ser abordado.
Se recomienda poner unidades en los costes para hacer más claros los valores presentados y evitar confusión.

Semana 4

BORROO

Aplicación para generalizar el alquiler de objetos, es de matchmaking-improved market

Feedback positivo de estudiante

Muy buen Killer opener, el mejor hasta la fecha.
Muy buenos chascarrillos, además lo enlaza con la aplicación.
De nuevo recuerda qué proporciona su aplicación con respecto a la competencia de forma visual.
Estimaciones del coste muy claras, explica por qué dedica cada cantidad de dinero a cada ámbito del proyecto.
Vídeo sobre la aplicación, muy buena idea.
Pone ejemplos para explicar las métricas de trabajo, muy buena idea.
Tiene talento para la exposición.
Buena idea poner un gráfico burndown.
Admite errores propios y es consciente de que tienen que cambiar algunas cosas.
Muy visual las horas invertidas y el progreso alcanzado.

Feedback negativo de estudiante

En el video de uso de la aplicación, no se ve todo, sería buena idea agrandar la página.
Error en el video, más se ha acabado convirtiendo en un chascarrillo.
Habla quizá demasiado rápido. Faltan pausas. Es una metralleta de información que puede saturar.
Quizás sería mejor idea reducir la cantidad de información que quieres transmitir al público.
Muchos ejemplos y casos concretos. No está mal meter unos pocos, pero tantos llegan a saturar.
Lo importante, usuarios piloto, lo aborda de forma rápida.
Repite mucho “de acuerdo?” y “de alguna forma”.

Feedback de profesores (Cristina)

Presentación muy bien excepto por alguna transparencia mejorable.
Inicio muy bueno pero un poco largo se le ha hecho.
Algunos que según se ven en las tablas no parecen competidores.
No se transmite la idea
No es lo mismo la calidad del código que la calidad que se considere.
No hay numero de pagina en alguna diapositiva
Gestionar que es importante en la diapositiva. Imágenes muy grandes e irrelevantes.
Dedicar mucho más tiempo a retrospectiva (40 / 50% del tiempo)

Feedback de profesores (Carlos Müller)

Muy de acuerdo con Gabriel, tiene un gran dominio, pero habla rápido, aunque la dicción sea correcta y comprensible, peca de hablar demasiado rápido. Da la sensación de estrés, podría ser buena idea reducir el contenido de la presentación y resumir lo que es verdaderamente importante.
Sugiere el lápiz en la boca para mejorar la dicción.
Poner al principio, antes de la demo, decir que se presenta.
Ve un problema con el copyright de Doraemon.
Quizás Doraemon no sea la mejor opción, pues los más mayores no lo conocen y dan por hecho que sí. Si la presentación le llega a un camionero de avanzada edad, no entenderá el chiste.
Cuidado con las preguntas al público asumiendo cosas.
Costes: Falta plan de contingencia. Habría que poner K o M.
Prototipo: Muy corto y se veía muy poco.
Cuando ha fallado el video, deberían haber explicado cuál ha sido el error y no pasar rápido y corriendo a la siguiente diapositiva, da la sensación de no estar preparado.
Dejar en claro las métricas que deben de seguir los QA para valorar la calidad.
No invertir demasiado tiempo en reuniones.
No han hecho enlace con los riesgos. ¿Se está aplicando los planes de contingencia?

Grupo 5 - Camyo

Semana 1

App para juntar camioneros con empresas

Feedback de estudiantes

Le ha gustado mucho el cambio de idea que han hecho y le gusta mucho la paleta de colores, la fuente le parece pequeña.

Feedback de profesores

Lo que comento anteriormente a nivel de presentación se aplica aquí también. Le he gustado el teatrillo inicial Uso de vocabulario simple. Han realizado 11 horas en el análisis de competidores, es un desastre inaudito, es tirar a la basura 1400 horas. Pablo dice que en su lugar hubiera usado como MINIMO 55 horas en este apartado (en 10 segundos ha encontrado otro competidor) Es mejor centrarse en decir que hacemos que el resto no, en qué nos diferenciamos El éxito es el análisis certero sobre algo que alguien estaría dispuesto a pagar. Uber se come el mercado, que lo único que lo diferencie sea un chat es una vergüenza Se buscan DECENAS de competidores como mínimo. Se necesitan DECENAS de personas dispuestas a pagar como sondeo. Intentar que en las presentaciones las diapositivas NO sean genéricas (Quitar la mayor cantidad de morralla posible). Poner datos en crudo que ni se ven es mala idea, decidir que nivel de información se puede ver, contar, leer y asimilar (ver que sobra de la presentación)

Semana 2

App para juntar camioneros con empresas

Feedback de estudiantes

Le ha gustado mucho el teatrillo del inicio y el análisis de competidores, pregunta si tienen pensado hacer verificado de conductores para que las empresas tengan una idea de a quien contratar. Dicen que si lo han pensado.

En los costes les sale mas caro el mantenimiento que el desarrollo de la aplicación. Dicen que se han equivocado poniéndolo.

Feedback de profesores

Le ha gustado el teatrillo para atraer la atención.

No encuentra muy novedosa el factor diferenial de la aplicación. Le parece muy alto el riesgo que la única diferencia sea algo tan pequeño

Letras mas grandes en la diapositiva

Que pasa si un competidor de EEUU pasa a España? dicen que no va a pasar porq están en perdidas.

La mitad de los usuatios piloto dijeron que no les interesaba.

Se necesitan 15-20 usuarios piloto, poner el QR fue buena idea

No han especificado bien los casos de usuario core.

No sabe a que se refiere con IVA o sin IVA, no lo saben ni ellos.

Demasiadas diapositivas, tienen 40.

Clasificar los riesgos según prioridad/importancia.

A nivel de quipo, necesitan responsabilidades concretas, quien es el manager?, para los roles es necesario hacer secretario, manager, gestor de conflictos, gestor de calidad...

Semana 3

Camyo

App para juntar camioneros con empresas

Feedback de estudiantes positivo

Comienzan con un enfoque entretenido usando la historia del teatrillo, lo que capta la atención desde el principio.
El uso del QR al inicio es excelente para reclutar usuarios piloto, una estrategia eficaz y bien ejecutada.
El cambio en el formato del teatrillo para cada presentación mantiene el interés y demuestra flexibilidad.
El QR se mantiene durante todo el teatro, lo cual es una buena idea para mantener la interactividad.
Desde el principio, queda claro qué es Camyo y en qué se diferencia de otras opciones, lo que es fundamental para establecer el valor diferencial.
La tabla de competidores en la diapositiva 3 está muy clara y facilita la comprensión.
La presentación es muy limpia y ordenada, sin sobrecargar de información, pero se mencionan los puntos clave de forma concisa.
La gestión de usuarios pilotos en la diapositiva 4 está muy bien estructurada y clara, facilitando su comprensión.
Se aclara de manera efectiva que la app aporta un beneficio directo a los usuarios pilotos, incentivando su uso.
Es un buen punto contar con empresas de renombre, lo que refuerza la confianza en el proyecto.
El MVP está bien definido y se va desglosando de manera detallada a lo largo de la presentación.
El formato elegido para las diapositivas es muy adecuado y consistente, proporcionando una estructura clara y profesional.
El análisis de riesgos es muy completo, con medidas claras para cada posible escenario, lo cual demuestra un enfoque proactivo.
El desglose de costes está bien presentado y es fácil de entender.
El estudio de mercado incluye varios escenarios de rentabilidad (mejor, más probable y peor caso), lo que proporciona una visión equilibrada.
La planificación de los sprints está muy bien detallada y clara.
La diapositiva 19 es especialmente clara y esquemática, facilitando la comprensión de la información.
Los roles están definidos claramente, lo cual es importante para entender la estructura del equipo.
En el commitment agreement se han abordado bien los modelos de rendimiento y los diferentes casos posibles.
Han hecho un excelente trabajo al elegir la cantidad adecuada de texto para las diapositivas, manteniendo el equilibrio entre claridad y concisión.
Dejan el QR de la landing page al final, lo que es un buen cierre para la presentación.
La landing page es intuitiva y fácil de navegar, lo cual facilita la interacción con los usuarios.

Feedback de estudiantes negativo

No parece faltar preparación en la presentación, sin embargo, la presentadora ha mostrado nerviosismo, lo que ha afectado su fluidez.
Se ha trabado en un par de ocasiones, lo que generó una sensación de inseguridad que perduró durante el resto de la presentación.
Se notaron algunos momentos de risita nerviosa, quebramiento de la voz y quedarse en blanco, lo cual es común cuando alguien se siente nervioso.
Las muletillas también fueron un indicativo de nerviosismo, lo que puede ser gestionado con más práctica.
Se recomienda realizar más ensayos en un entorno relajado para ganar confianza. Técnicas de control de los nervios, como la respiración profunda, también podrían ayudar a mejorar la fluidez y reducir la ansiedad.

Feedback de profesor (Pablo)

Tiempo de presentación: Es importante que los tiempos se gestionen adecuadamente. Ha sido un poco ajustado al final, lo cual no debe repetirse. Aprovechar cada minuto de la presentación para maximizar su impacto es crucial.
Mejora en la presentación: La calidad de la presentación puede mejorar. Se sugiere que se enfoque en mejorar la vocalización. Un recurso útil podría ser el libro How to Speak So That People Want to Listen, que ofrece excelentes técnicas para comunicar de manera efectiva. También sería útil grabarse durante los ensayos para poder analizar los errores y ajustar los tiempos. Practicar juntos como equipo también ayudará a mejorar la fluidez y cohesión.
Explicación de usuarios pilotos: La forma en que se explicó la gestión de usuarios pilotos no fue completamente clara. Es importante enfocarse en cómo se gestionará el feedback de estos usuarios, cómo se comunicará con ellos, y cómo se organizará la recepción del feedback de manera estructurada.
Usuarios pilotos: La cantidad de usuarios pilotos parece ser limitada. Sería útil aumentar la base de usuarios pilotos para obtener un feedback más diverso y amplio.
Mockups: Los mockups son bastante básicos. Se debe ser más selectivo con lo que se comenta y evitar entrar en detalles innecesarios. Además, es importante recordar que los mockups no deben ser el foco principal, sino la experiencia que representan.
Enfoque en el MVP y casos de uso core: La presentación mostró el MVP demasiado pronto. El MVP debería ser el último entregable, mientras que ahora el foco debe estar en implementar los casos de uso core. Estos deben priorizarse para poder obtener feedback más rápido y efectivo de los usuarios pilotos.
Uso de abreviaturas: Se recomienda usar "K" en lugar de escribir miles para simplificar la presentación de números. Esto hace que la información sea más fácil de leer y entender.

Feedback de profesor (Cristina)

Elevator Pitch: El elevator pitch debe ser más breve y conciso. Un pitch demasiado largo puede resultar tedioso y perder la atención del público. Es importante captar rápidamente el interés con una explicación clara y directa.
Competidores: La sección sobre competidores fue demasiado corta y no proporcionó información relevante. Se le debe dedicar más tiempo para explicar cómo se posiciona el producto frente a la competencia y destacar claramente los diferenciadores.
Riesgos: La aproximación a los riesgos fue incorrecta. En lugar de centrarse en cómo resolver los riesgos una vez ocurran, se debe enfocarse en cómo minimizar o evitar que esos riesgos se materialicen en primer lugar. Es importante recordar que un riesgo no es un problema ya resuelto, sino algo que podría suceder y que debe ser mitigado desde el principio con acciones preventivas claras.

Semana 4

Camyo

App para juntar camioneros con empresas

Feedback positivo de estudiantes

Buen killer opener, involucra al público.
Utiliza chascarrillos que captan la atención.
Muy visual la presentación, la letra cumple los requisitos de tamaño mínimo.
Se nota que está muy preparado, no se ha dejado nada al azar.
Muy visual la aplicación, se ha ilustrado en la presentación de manera que cada paso se vea en grande mientras se explicaba.
Habla de previsión de riesgos y cómo han sufrido uno, comentan cómo lo solucionarán, buena práctica. (comunicación escasa entre backend y frontend, mal estimación del tiempo de tarea)
Tiene un final con gancho.

Feedback negativo de estudiante

Quizá un poco pesado los mockups definiendo cosas básicas como un registro o inicio de sesión. Trivial y pasable (Ajustar nivel de detalle).
No me queda muy claro si lo que han enseñado es el caso de uso core u otra funcionalidad.

Feedback de profesores (Cristina)

No se ha presentado los presentadores.
No le queda claro si dan soporte a autónomos o no (responden que sí, y viene reflejado en la tabla de la presentación).
Los usuarios piloto NO tienen fechas, quieren una agenda, ya sea con fechas absolutas o relativas, decir cómo reciben el feedback, cuáles son los tiempos de respuesta, cómo tratamos el feedback.
No es necesario mostrar formularios como el registro. (mala elección de nivel de detalle). Centrarse más en los casos core.
Retrospectiva: Se ha explicado bien en qué se ha dedicado el tiempo.
Se queda corto la productividad del equipo solo con clockify y commits.
Considerar otros criterios.
Problemas y riesgos: Medición de cómo evolucionan los problemas. ¿Están abiertos, solucionados? Medición desde que se detecta hasta que se soluciona. Cómo medimos el problema hasta que se soluciona. Cualitativo o cuantitativo.

Feedback de profesores (Carlos Müller)

Problema: No le queda claro qué es lo que les diferencia.
No le ha quedado claro qué es la búsqueda de contratos. (Deberían haberlo explicado mejor, dado que da lugar a confusión).
El inicio efectivo ha sido bueno, pero deben de buscar algo más relacionado con el tema, y a ser posible que esté estrechamente relacionado con su punto diferenciador; vender un boli está bien, pero no tiene nada que ver con los camiones.
Se puede resumir la presentación del equipo. Invertir menos tiempo.
Hay algún detalle como la barra de búsqueda que no se ve.
Una demo grabada da menos sensación de mockup (responden que no tienen los botones todavía).
Efecto cobra: recompensa por cada cobra muerta -> crearon granjas de cobras y acabaron pervirtiendo las métricas. Esto es un paralelismo a las métricas de análisis de horas.
Buscas cualitativo antes que cuantitativo a la hora de valorar la productividad del equipo (alguien que haga pocos commits y luego ayude a la gente no será bien valorado).
No se ven las leyendas de las imágenes.
Le encanta la transparencia 25. Mezcla muy bien texto con iconos.
Mucho tiempo sin apoyo visual en alguna transparencia.
No han puesto de forma visual la replanificación y sería una buena idea.

Grupo 6 - FisioFind

Semana 1

Gallery Guide App

Mapas virtuales de cada museo y rutas guiadas según preferencias, no como Google maps, sino como un plano

Feedback de estudiantes

No hay

Feedback de profesores

Tienen muy pocos competidores (el profesor ha encontrado 2 competidores que hacen lo mismo que ellos) Tienen muchos problemas, no lo ve confuturo, si los museos grandes ya tienen sus propias aplicaciones, no tiene sentido que se descargaran la suya. Observa que sería mejor sino fuera sobre museos sino sobre rutas turísticas en la calle. Cosas de presentaciones igual que el resto.

Semana 2

FisioFind

App para consultas de fisioterapia

Feedback de estudiantes

Le ha gustado mucho, el tema de la videollamada debería tener una previa visita física? No, puede hacerlo a remoto.

los videos son para rehabilitación? si

no han puesto la diferencia entre ambos planes de pago

Feedback de profesores

han tenido en cuenta el feedback

han invertido tiempo en cosas superfluas, hay que intentar focalizar el proyecto

el tema DAFO,cosas triviales como no tener internet no hay que añadirlo, son cosas especificas del proyecto

-ve bien el delivery, hace énfasis en llevar un ritmo de velocidad constante, una recomendación es JulianTreasure: How to speak for people to want to listen.

El foco esta muy bien, pero han dejado sin definir las herramientas especializadas, (al parecer las tenían en las encuestas pero no la pusieron en la presentación). Hubiera sido mejor invertir tiempo en cosas especificas como el mapa de dolor y el mercado.

-Tema las verificaciones, aclarar si son automáticos o no

tema de los costes: en ningún caso se habla de estimación de usuario en función del mercado.ej: seremos rentables en este mercado si conseguimos un x% del mismo y mostrar los costes de infraestructura.

la diferencia entre un mock up "wildframe" y capturas que parecen reales, este prefiere los mockups que muestren las funcoinalidades

le parece bien que al buscar competidores y ver que no hay mercado salir (esto es un elogio a nosotros también), lo valiente es cambiar el trabajo de una semana.

Buena calidad visual, todo se podía ver.

le gustan que tengan ya datos como cuantos usuarios serian necesario para rentabilizar la app.

Semana 3

FisioFind

App para consultas de fisioterapia

Feedback de estudiantes positivo

Creación de personaje (Manuel): La creación de un personaje (Manuel) fue una buena técnica para involucrar al público y hacer más accesible la presentación. Desarrollar este personaje a lo largo de la presentación ayuda a mostrar el uso práctico de la app.
Mockups: Los mockups fueron muy claros, lo que facilita la comprensión de cómo funcionará la app en la práctica.
Plan de acción para tecnologías: Es positivo que se haya mencionado un plan de acción para superar la falta de conocimiento en ciertas tecnologías. Esto demuestra proactividad y disposición para mejorar.
Vestimenta: Guadalupe y Antonio van vestidos con los colores de la paleta de la app. Si bien esto puede ser un detalle visual interesante, sería importante confirmar si fue una casualidad o si se trató de una estrategia premeditada para reforzar la identidad de la marca.
Visión holística del proyecto: Se abordó el tema desde una visión global, lo cual es positivo, ya que ayuda a entender el contexto y la importancia de la app en el mercado.
Feedback de clases anteriores: Es muy positivo que se haya mencionado el feedback recibido en clases anteriores y las mejoras realizadas en base a eso. Esta actitud abierta a la crítica y a la mejora continua es muy valiosa.
Página para calcular coste: La página para calcular el coste es una característica excelente y bien recibida. Proporciona valor al usuario y muestra un nivel de detalle y funcionalidad que se destaca.

Feedback de estudiantes negativo

Casos de uso core: El nivel de detalle en los casos de uso core fue algo limitado. Sería ideal proporcionar más información y ejemplos prácticos para dar una visión más completa de cómo la app resolverá problemas clave.
Dimensiones de la presentación: Las dimensiones de la presentación no coinciden con el formato recomendado, lo que provoca que aparezcan bordes negros en algunas diapositivas. Este es un detalle técnico importante que debe corregirse para evitar problemas de formato.
Killer Opener: El inicio de la presentación con la referencia a la vida amorosa fue una elección curiosa, pero no es la manera más profesional de captar la atención del público. Sería más efectivo iniciar con algo más directamente relacionado con el producto o la problemática que resuelve.
Muletillas: Guadalupe utiliza la muletilla "eee" en ocasiones puntuales, mientras que Antonio usa "vale?". Estas muletillas pueden restar profesionalismo a la presentación. Practicar y tener más control sobre el discurso podría ayudar a evitar estos deslices.
Tiempo de exposición: El tiempo de exposición de Guadalupe fue de 4 minutos 40 segundos, mientras que el de Antonio fue de 10 minutos 20 segundos. Es importante equilibrar los tiempos de exposición entre los miembros del equipo para asegurar una presentación fluida y equitativa.
Código QR: No se dio suficiente tiempo para escanear el código QR, ya que lo mostraron y rápidamente lo quitaron. Se recomienda poner el código QR al final de la presentación para asegurarse de que todos tengan el tiempo necesario para escanearlo.
Tamaño de la letra: En una diapositiva, el tamaño de la letra era visible pero no cumplía con el tamaño recomendado en la asignatura. Es importante asegurarse de que la letra sea suficientemente grande para que todos en la audiencia puedan leerla con claridad.

Feedback de profesor (Pablo)

Intencionalmente en blanco.

Feedback de profesor (Cristina)

Clientes y usuarios pilotos: El número de clientes (cinco) y usuarios pilotos (tres) es bastante limitado. Es importante trabajar en la captación de más usuarios pilotos para obtener un feedback más representativo y poder validar el producto de manera más eficaz.
Tabla de competidores: La interpretación de los iconos en la tabla de competidores no fue clara. Es fundamental que los iconos sean fácilmente comprensibles para la audiencia. Se recomienda usar leyendas o explicaciones más detalladas para mejorar la claridad.
Referencia a semanas anteriores: Evitar hacer demasiadas referencias a presentaciones anteriores, ya que esto puede distraer del contenido actual y no aporta valor inmediato. Enfócate en lo que has logrado y lo que estás presentando en el momento.
Riesgos: Evitar un riesgo completamente es muy complicado. Es más efectivo priorizar los riesgos según su probabilidad y el impacto que puedan tener, y establecer acciones de mitigación claras. No quedó del todo claro cómo se gestionan los riesgos en este caso. Asegúrate de presentar un enfoque más estructurado para la mitigación de riesgos.
Equipo y roles: La asignación de roles dentro del equipo no quedó lo suficientemente clara y, en algunos casos, hizo que la presentación fuera algo pesada. Intenta simplificar y clarificar la distribución de roles para que la audiencia entienda mejor quién hace qué en el proyecto.
Costes: No se presentaron los costes de manera clara. Es importante que la diapositiva con los costes sea simple y comprensible, de modo que la audiencia pueda ver rápidamente los datos clave. Asegúrate de hacer un desglose claro de los costes asociados al proyecto.
Mockups: El hecho de comenzar con los mockups sorprendió, pero en un sentido positivo. Aún así, el orden de la presentación no resultó ser del todo intuitivo y terminó mareando un poco. Sería ideal comenzar con una breve introducción, seguida por los competidores y luego los mockups. Esto ayudará a construir una narrativa más lógica y fluida.
Innovación en el inicio: Se sugiere ser un poco más innovadores con la introducción de la presentación. Hacerla más atractiva y original puede captar mejor la atención del público desde el principio.

Semana 4

FisioFind

App para consultas de fisioterapia

Feedback positivo de estudiante

Introducen con un buen killer opener, videos e imágenes que llaman mucho la atención. (bebés).
Muy buena diapositiva del trabajo realizado. Muy visual.
Ha bajado del estrado para exponer en otro nivel y así innovar con respecto a sus propios compañeros y el resto de grupos.
Gráficas para mostrar el avance del proyecto y además las explica muy bien.
Buen chascarrillo para retomar la atención.
Es buena idea un grupo de FAQ.
Han pivotado de Taiga a Github Projects (han sabido rectificar).

Feedback negativo de estudiante

Es raro empezar por los costes.
Números de página MUY PEQUEÑOS.
El presentador utiliza monótono, después de un presentador muy capaz, se queda en poco llamativo en el mejor de los casos.
Serios problemas con el pase de diapositivas, el puntero no funciona y tienen que recurrir a miradas entre el pasador y el exponente.
Quizás echo en falta que comience por la prueba funcional de la aplicación, estoy viendo usuarios piloto pero no me acuerdo ni de lo que hace la app.
El nivel de detalle no es correcto, se habla del equipo demasiado en detalle, llevamos la mitad de la presentación y no hemos visto nada de la app.
Utilizar el baremo de cantidad de commits u horas como parámetros es falsable y no mide realmente la calidad del trabajo.
Si pasa tan rápido las diapositivas del equipo, ¿para qué ponerlas?
Demasiadas diapositivas.
Los gráficos tienen las líneas muy finas, la diapositiva está prácticamente en blanco.
Muestran el MVP un poco tarde.
Decir que está feo es echarse piedras. Mejor un comentario como “está en proceso”.
No se ve nada de la aplicación. ENANO.
Presentación muy larga. Se ha pasado de tiempo y no avanza más rápido a pesar de saberlo.

Feedback de profesores (Cristina)

El killer opener máximo 1 minuto.
El elevator pitch máximo 30 seg.
El equipo muchas traspas y las han pasado muy rápido.
Tienen problemas con el ratio de respuestas, podrían hacer una media de la satisfacción. (Dicen que se ha solventado a nivel de prioridad).
Muchas transparencias.
No se distinguían los problemas de los riesgos.

Feedback de profesores (Carlos Müller)

Killer opener muy largo. Relacionarlo con el problema que resolvemos.
Presentan los tres muy bien, pero Antonio debería mirar a todo el mundo, no solo a los profesores. Técnica de las 4 esquinas.
Competidores: Ayuda mucho señalar de lo que se habla (destacarlo en la presentación).
Se especializan en el mercado español, pero se llaman FisioFind. El profesor recomienda llamarlo FisioYa o TuFisio.
Muy bien el tener en cuenta la estimación de suscriptores.
La demo no se veía.
Han personalizado bien el análisis de rendimiento.
Uso de prompts.

FIN DE LA APORTACION

Aportaciones de consolidación

Por otra parte se ha añadido una función de búsqueda de documentos en el repositorio de la base de conocimiento común para facilitar a los compañeros de la asignatura la búsqueda de artefactos específicos, pues esta será una funcionalidad que pensamos necesaria en una base de conocimiento que sin lugar a dudas va a expandirse mucho. Esta aportación puede verse: aqui

Fichero ajustado: docusaurus.config.js

 plugins: [
     [
       require.resolve("docusaurus-plugin-search-local"),
       {
         indexDocs: true,
         indexBlog: true,
         indexPages: true,
         highlightSearchTermsOnTargetPage: true,
         searchResultLimits: 10,
         hashed: true, 
         translations: {
           search_placeholder: "Buscar...",
           no_results: "No se encontraron resultados.",
         },
       },
     ],
   ],  

Sprint 2

En este segundo sprint, al igual que en el anterior, se han compartido con el resto de grupos de la asignatura todo el feedback recogido tanto por los propios miembros del grupo durante las presentaciones, como las aportaciones de los compañeros ajenos a este y de los profesores durante el tiempo de feedback. Esta aportación es completa, pues se recogen de forma separada tanto los aspectos positivos como los negativos desde el punto de vista de los estudiantes que conforman el Grupo 1. Esta aportación puede verse: aqui

Aportacion exacta:

Semana 5

Holos

Feedback positivo de estudiante

Killer opener sencillo pero efectivo, toda la clase con la mano levantada.
Ha mejorado la tranquilidad que transmite.
Muestra claramente la responsabilidad de cada miembro del grupo.
Buenas diapositivas para los costes
Sinceridad con los problemas
Se pone solución a los problemas surgidos y se explica qué se hará.
Uso de tablero niko niko el cual es una métrica adicional útil. muy bien el final de la presentación en cuestión de tiempo.

Feedback negativo de estudiante

No llega a relacionar bien el problema con la solución.
Tardamos en explicar a qué nos dedicamos, quizá sería buena idea ajustar el nivel de detalle.
No hemos hecho caso al feedback. Pablo nos sugirió eliminar el plan premium y sacar únicamente dinero por comisiones.
En algunos datos se usa el k para referirse a los miles y en otros no.
Gráfica no muy intuitiva del análisis de coste. Quizás el diagrama de barras no es la mejor idea.
La explicación de los porcentajes no ha quedado claro.
El ritmo de la demo es muy lento, No se ha preparado bien el video de la demo.
No se ve muy bien el video de la demo. Faltan zooms o tamaños de letra más grandes.
Mucho tiempo explicando el equipo, quizá sería adecuado ajustar el nivel de detalle.
Foto con marca de agua. Sensación de que no es provisional.
Anque va mejorando, el presentador repite todavia la muletilla “estilo” con cierta regularidad.
En la presentación se hace mención "tareas de CI/CD", quizás un usuario promedio que escuche la charla no sepa lo que es.
No hicimos caso al feedback: Nos comentaron que basar las métricas de rendimiento según el número de commits no es recomendable. Es muy falseable.
Las fechas de la gráfica del Niko-Niko están mal (21/02, 03/02, 21/02).
Da la sensación de una presentación poco preparada. Se ha dado mucha prisa al final. Demasiadas diapositivas (tenemos 40).

Feedback de profesores (Carlos)

Le ha gustado la idea de que haga que levantemos la mano, pero opina que tiene sus desventajas, como en el caso de que nadie la levante.
Le gusta la idea del proyecto.
El tema de trackear el uso de IA, pregunta como lo haremos. Él no lo ve sencillo. Pero Portela se ha defendido muy bien (grande mi presi).
Estimar también el número de transacciones
Piensa que tenemos liado el Capex y el Opex.
En el tema de estimaciones lo ha hecho solo en base al número de artistas, pero si esos artistas no llevan transacciones pueden dejar de ser clientes. nos sugiere estimar también el número de transacciones
Le ha gustado “el plan B” de la demo, ir moviendo la barra del video manualmente. Muy bien reaccionado.
No se ve el texto en la demo.
El número de commits es una métrica que se puede pervertir.
Necesita otras metricas que sirvan para medir el avance.
Ojo con el despliegue. Lo avisa con tiempo. Si no se tiene cuidado nos podemos quedar sin creditos o sin espacio etc.

Semana 6

Holos

App para venta de obras de artistas.

Feedback positivo de estudiante

Killer opener paseándose por la clase, algo nuevo.
El storyBoard está muy bien hecho y a mano además, somos consecuentes con el no uso de la ira en el arte..
Hila bien las transparencias y la temática. Usa lenguaje coloquial chocante: “Se jode”, por otra parte esto puede ser peligroso.
Los gráficos del coste son muy ilustrativos.
Hace hincapié en las licencias, lo cuál no ha sido mencionado por ningún otro grupo.
Le da la importancia a la GDPR que debe tener, algo imprescindible.
Pone métricas a todos los problemas que hemos tenido y también a las soluciones
Calendario niko-niko único.

Feedback negativo de estudiante

Hay bordes negros, no se aprovecha al máximo las dimensiones.
La demo ha sido quizás demasiado lenta, distorsionando demasiado el audio.

Feedback de profesores (Pablo)

El tema del inicio efectivo, pablo plantearía algo mas enfocado a un hecho o una historia, que permita introducir más rapido el tema, por ej: picasso tuvo 4 intentos de suicidio cuando no fue capaz de tener los encargos a tiempo. (que se entienda el dolor y la necesidad del proyecto, que hay un problema que solucionar)
Le preocupa el tema de la IA, que es como un report, ya lo dijo que le parece un error, pues es imposible detectar si algo está hecho por IA o no, replantearnos el esfuerzo en ese aspecto, y que justifiquemos si de verdad es clave e interesante y diferenciador. No entiende nuestro valor diferenciador.
En la transparencia 11, no entiende las variaciones en los gastos y costes estimados. Dice que no está bien hecho porque hay que tener en cuenta las amortizaciones a lo largo del proyecto, la gráfica tiene muchísimos problemas.

Feedback de profesores (Cristina)

Inicio efectivo ha usado el storyboard, es ocurrente, pero no le ha quedado claro quien es el cliente. Asume que todos somos artistas.
En las siguientes transparencias, dice “le interesa mucho a la clientela”, pero a Cristina no le queda nada claro quién es nuestra clientela.
En la diapositiva 11 (gráfica), no se ha entendido bien el eje x, porque no es nada intuitivo. Quizás sería mejor poner fechas.
“Tema licencia, Tema noseque…,” hay que intentar transicionar de forma más profesional.
La demo es genial, le ha encantado.
Vamos atrasados en cuenta a la implementación.
Algunas transparencias le han gustado mucho, pero en la traspa 25, más que soluciones son propuestas.
Medidas más cuantitativas para, medir mejor la evolución de los problemas, la intención solo no es suficiente.
En la traspa 30,31 hay que revisarlo un poco, hay una persona que ha hecho un 0% de tareas a tiempo.

Semana 5

GastroStock

Ayuda a la gestión de inventarios de bares y mejora de logística mediante IA.

Feedback positivo de estudiante

Empieza con energía.
Empieza desarrollando una historia con la que nos podemos identificar (estudiantes sin dinero).
Inicio muy efectivo.
Deja claro su objetivo de negocio.
Diapositivas muy visuales, no están recargadas de texto. Tienen el texto justo.*
Aún con los problemas puntuales ha sabido actuar y los ha solucionado rápidamente sin perder el hilo.
Gráficas muy visuales.
Buena explicación de los costes donde se comentan los gastos ya cubiertos
Perfiles del equipo muy bien definidos.
Muy sinceros con sus problemas.*
Decisión muy valiente hacerlo en un TPV. Mucha curiosidad por ver cómo sale.*

Feedback negativo de estudiante

Inicio no apto para todas las edades, ya que se centra en el caso de los estudiantes.
Se han pasado del minuto que debe durar el inicio efectivo.
Problema en la presentación.
Mala coordinación presentando.
Ha faltado mucha preparación.
No han puesto K en los costes.
No ponen la landing page.
Han comenzado un modelo de negocio que depende de que los clientes trabajen el doble, y encima le piden que les den sus datos gratuitamente.

Feedback de profesores (Carlos)

Más tiempo dedicado a la retrospectiva, era interesante ir directamente a los problemas y no a que no funciona la app.
¿Coste de TPV? ¿De hardware?
Promocionar un TPV no tiene mucho sentido.
Analizar el porqué se ha llegado a esa situación.
Han cambiado a un grupo más grande de WhatsApp en vez de subdividirlo, lo cual no sabe si es buena idea, ya que otros grupos partieron de un grupo grande y acabaron en subdivisiones.
Hay que tomar cartas en el asunto, porque no lo ve claro, la cantidad de horas trabajadas es escasa.
Cuidado con el lenguaje sexista, expresión: “estos tíos”, usar "camareros, camareras".
Ha faltado preparación en la presentación. Se queja de las animaciones. Hace falta un plan B si hay algún problema con la presentación.
Alaba su honestidad.
¿Esto es feedback o una ejecución pública?

Semana 6

GastroStock

Ayuda a la gestión de inventarios de bares y mejora de logística mediante IA.

Feedback positivo de estudiante

Killer opener que relaciona el problema con una solución
Expone muy calmado, quizás demasiado. Falta emoción.
Da información precisa sobre el costo de una TPV, lo cual no es de conocimiento común y aporta al contexto.
Crea un personaje “tio gilito” que retoma un poco la atención.
Los tiempos de la demo están más o menos bien cuadrados.
El chascarrillo sobre el nuevo integrante del grupo ha sentado bien.
Usa un lenguaje con impacto “las cabras del equipo”. En este entorno funciona.
Robo de de portátil a un compañero se toma como riesgo y se evalua.
Buena idea usar el ratón como pasante.

Feedback negativo de estudiante

Killer opener muy largo, comparado con otros grupos no tiene el mismo impacto.
Es un poco monótono en el discurso, lo que provoca una pérdida de interés en el público.
Pasan muy rápido los competidores, dice que lo hace porque ya los conocemos, entonces por qué poner 3 diapositivas dedicadas a ellos.
El video de la demo no está muy preparado.

Feedback de profesores (Pablo)

No se aporta información cuantitativa de nada. No se apoya en nada.
A partir de ahora lo normal es que un público común no entienda la parte más técnica de la presentación. Al no existir elementos cuantitativos, ha generado suspicacia, informalidad e inseguridad. Se piden datos como porcentajes de mejora, rendimiento….
Cuando se introduzca un dato cuantitativo, se debe introducir un contexto, si un inversor llega a ver si hay potencial y retorno de inversión, en la presentación dice que “obtendrán un x% del mercado”, el inversor no va a sacar una calculadora y a ponerse a hacer cálculos, se le deben entregar los números que permitan al oyente analizar si tus argumentos son o no creibles. (no un %, sino miles de euros por ejemplo, o no un % del mercado sino introducción en 500 locales)
La penetración de mercado se puede hacer como un estimado, si nos equivocamos pues bueno, pero está bien que se estime. (una estimación en dinero es mucho mas dificil que una en clientes, pues este primero es una consecuencia lógica del segundo)

Feedback de profesores (Cristina)

Inicio efectivo bueno, pero muy largo. Dice detalles menos relevantes. Debe acortarse. Está bien alineado con la presentación.
Muy monótono. He empezado con energía, pero he bajado el nivel.
En los costes, la elección de colores debe ser intuitiva, lo bueno debe ir en verde y lo malo en rojo por ejemplo.
Demo muy mejorable, mucho “también puede ver”, hay que amenizar. Faltan personajes y guión, contar una historia.
Los anuncios no se ven bien. Replantearía muchas partes de la presentación.
Faltan problemas, riesgos, storyboard…

Semana 5

EVENTBRIDE

Aplicación para gestionar eventos cristianos; bodas, bautizos y comuniones

Feedback positivo de estudiante

El mejor inicio en años. Incluso los fallos en la presentación han “casado” genial con el tono cómico.
Muy acertados los chascarrillos.
Han hecho caso al feedback (poner presupuestos con K).*+
Gráfica de la rentabilidad muy clara.
Muy claros los roles de cada integrante del grupo.
Demo guiada con un narrador. Decisión muy acertada.
Se nota que han practicado la presentación, en todo momento sabían lo que venía a continuación.
Sinceros con los problemas.
Reestimación de tareas para solucionar problemas.
Diapositivas muy visuales, con el texto justo. En ninguna le sobra texto.
Planificación de sprint clara y sencilla donde se entiende perfectamente las tareas destinadas a cada uno.
Muy clara la gestión de usuarios pilotos en una sola diapositiva (intereses de los usuarios, etc.).
30 diapositivas, cantidad justa para contar todo.

Feedback negativo de estudiante

Mucha información quizá en los costes.
En ocasiones acelera mucho su dicción.
Uso de IA un poco recargado.

Feedback de profesores (Carlos)

La botella es un gran recurso para cuando no te acuerdas de algo.
Estimación de rentabilidad: deben poner los datos en los que se basan para esa estimación.
Las demos deben tener datos reales o al menos realistas.
Audios de los vídeos más homogéneos.
Le parece muy trabajada la fórmula de rendimiento. Poner los datos.
El procedimiento para solucionar problemas está contado de manera demasiado genérica.
Elasticidad a la hora de presentar: tener en cuenta qué cosas puedes contar extra si te queda mucho tiempo.

Semana 6

EVENTBRIDE

Aplicación para gestionar eventos cristianos; bodas, bautizos y comuniones

Feedback positivo de estudiante

Muy buen killer opener que hila con la historia de la semana pasada y con el propósito de la app.
Miguel es un icono de la efusividad, lo cual hace que el killer opener sea más cómico.
Mucho entusiasmo y energía en la presentación.
Hablan sobre el seguimiento de un código de conducta, lo cual es muy interesante.
Muy interesante las menciones especiales.. Han hecho caso al feedback.
Tienen desarrolladas cuentas de instagram y tik tok.
Muy buen storyboard.
Han definido un público objetivo para el storyBoard.
Muy buena demo. Se escucha muy bien, hay zooms y tiene muy buen guión.
Buena autocrítica.
Muy buena presentación en el rendimiento.
Son sinceros con los problemas.
Buena velocidad mental para responder a las preguntas de los alumnos.

Feedback negativo de estudiante

Sigue hablando muy rápido.
La fórmula se ve muy mal, podrían introducirla en latex.

Feedback de profesores (Carlos)

Cree urgente que obtengan un pasante (para no tener que ir mirando al que pasa las diapositivas).
Muy bien enlazado el killer opener con el problema que solucionan.
El storyboard lo ve MUY BIEN. Le ha gustado el detalle de dibujarlo a mano.
En el anuncio, centrarse en bodas no es buena idea, porque das a entender que es lo único que haces.
Falta la viñeta final de pricing.
Diagrama de barras para ver la diferencia entre costes y ganancias.
Hay que destacar más la línea de costes. Se queda perdida.
Muy buenas las fórmulas, dan bastante detalle, pero falta algo más, quizás una pequeña gráfica para el rendimiento entre sprints (si va en aumento o decremento).
Marvilla de demo, le ha encantado. Imposible no estar atento a la demo. Lo único es cuando la octogenaria dice que es muy complicado y después que es una maravilla.
Falta gráfica para ver cómo evoluciona la calidad del código.
Lo bueno se copia
Hay que ser capaces de medir las soluciones.

Feedback de profesores (Cristina)

No hacer referencias a las semanas anteriores.
Cuesta seguir los números muchas veces, pues la única referencia que se da es: “Como se puede ver aquí”
En la trasparencia 8, la línea de corte ha de estar más destacada
En cuanto al equipo, le queda la duda si tienen un GDPR manager.
Diapositiva 27, se habla de problemas y luego de problemas encontrados, preferiría todos los problemas en la misma transparencia.

Semana 5

BORROO

Aplicación para generalizar el alquiler de objetos, es de matchmaking-improved market

Feedback positivo de estudiante

Inicio efectivo divertido (Don Ramón).
Se visualizan muy bien los costes Capex y Opex, se puede observar perfectamente en qué va destinado cada parte gracias a esa división.
Buena tabla comparativa.
Deja claro en qué se centra su app y en qué se diferencia desde el principio.
Utilizan "mil" en lugar de "K", pero han hecho caso al feedback.
Gráfica del coste clara.
Clara explicación de las responsabilidades de cada miembro del grupo.
Demo muy clara y muy bien explicada por el presentador.
Modelo de evaluación detallado para saber los aspectos que se tienen en cuenta y cómo se calcula.
Diapositivas muy claras, con la cantidad de texto justa y necesaria. Muy visuales.
Me ha parecido interesante cómo miden la calidad del código realizado.
Sinceridad con respecto a los problemas que han tenido.
En cuanto a las diapositivas de los problemas, me han gustado las transiciones de la explicación y su solución y cómo iban pasando a "Solucionados".
Muy clara la planificación de los distintos Sprints.
Buen detalle dejar el QR de la landing page al final de la presentación.
Presentación muy bien preparada.

Feedback negativo de estudiante

Problemas con la demo

Feedback de profesores (Carlos)

Respecto al killer opener: es muy buena idea cambiarle los colores a Doraemon y el nombre a Don Ramón.
Muy buena idea hacer referencia a la época en la que estamos, como la Semana Santa o la Feria.
Es normal que los costes sean altos al principio y después se reduzcan, ya que serán costes de mantenimiento. Cambiará la pendiente.
El formato de los problemas le ha encantado.
Ha faltado comentar cómo se ha medido si las soluciones a los problemas son buenas.
Muy bien temporizada la demo.

Semana 6

BORROO

Aplicación para generalizar el alquiler de objetos, es de matchmaking-improved market

Feedback positivo de estudiante

Killer opener bueno, hila muy bien con su app
Vuelve a hilar la presentación con el killer opener.
El segundo storyboard que muestra es mejor que el primero. - Simple, pero muestra la funcionalidad.
Don Ramón nos acompaña durante la presentación.
No hay parte de la pantalla que se desperdicie, utilizan la completitud del espacio que tienen, dando una sencilla visión al público.
Incluyen métodos cuantitativos para evaluar el rendimiento.
Hace referencia a riesgos que se encontraron y sucedieron, y como la solución a estos ha resultado en una clara mejora en este sprint.
Han mejorado mucho la forma de presentar, ha sido más calmado.

Feedback negativo de estudiante

Es el mismo killer opener que en la última presentación, si bien funciona, quizás seria buena idea innovar.
Mucho tiempo analizando competidores, no es necesario.
Storyboard muy escueto, solo dos imágenes y sin mucho sentido. El segundo anuncio mejora.
El video demo no está mal, pero no tiene voz ni guion ni personajes.
Las imágenes en usuarios piloto no tienen ningún tipo de relación con lo que se está hablando.
Presentación muy larga.

Feedback de profesores (Pablo)

No usa K, usan mil y recomienda poner K.
Insiste en que en la gráfica de revisiones de estimaciones (10), se debería entender la diapositiva en términos de qué significa, lo de k € viene recogido en la RAE y debe ser lo utilizado en su opinión. Si lo que hay que analizar en la gráfica es si es realista, hay que entender de donde salen los números, y para entenderlo bien hay que entender la atracción estimada (volumen de transacciones, clientes atraídos), para yo estimar cómo de realista es, deberíamos estimar cuántas transacciones se realizarán.
Desde el sprint 1 debe haber feedback de los usuarios piloto y que la usen, por ahora no han podido usarla los usuarios pilotos, a día de hoy si no se ha podido usar todavía, vamos fatal. Estamos en peligro.
Las transparencias genéricas no son buena idea, si en una transparencia no hay algo específico del proyecto, hay que repensar si es necesario ponerlo, pues si es algo común a todos los proyectos, nohace falta ponerlo.
Lo de la solicitud de alquiler le ha sorprendido, pues era su valor diferencial y lo han dejado para el Sprint 2, todos los esfuerzos han de ir dirigidos al valor diferencial en contra de la competencia.

Feedback de profesores (Cristina)

En la transparencia número 4, el storyBoard le ha parecido poco ocurrente y bastante simple, con la imagen no se describe la historia que proclaman sigue.
No intenta convencer a ningún inversor, tienen que decir, cuánto tienen que abonar y cuánto ganarán.
En la traspa 23 (rendimiento del equipo), cuando dicen que todos han sacado un 10, ¿han cumplido todos con todo?
En la 38 (IA), la diapo es muy genérica, se habla mucho pero hay poco, se podria decir que herramientas IA se han usado, como, debe ser más completa la traspa.
Trampas sin título han sido corregidas, aquí han seguido el feedback

Semana 5

Camyo

App para juntar camioneros con empresas

Feedback positivo de estudiantes

Inicio efectivo que continúa la historia de anteriores presentaciones.
Diferenciación muy clara en la tabla de competidores.
Han hecho caso al feedback en costes al poner la K.
Costes muy claros.
Gráficas muy claras, muy limpio el diseño. Además, han puesto las suposiciones que han hecho para sacar las gráficas.
Diapositivas visuales, con el texto justo.
Hila muy bien de una diapositiva a otra (transiciones), se nota que se ha practicado.
Expone a un ritmo perfecto, no va apurado ni despacio. Conoce de sobra el contenido de la presentación.
Gestión de los usuarios pilotos indicándose las funciones a probar, para obtener el feedback de estas.
Muy claros los puestos de cada miembro del equipo.
Video demo genial, con un narrador y un guión muy original.
Vídeo demo mostrando la app desde los dos perfiles que tienen como objetivo. Muy bien pensado.
Muy sinceros con los problemas.
Resolución muy clara de los problemas.
Métricas muy buenas para medir las alucinaciones de la IA.
Muy clara y bien explicada la planificación de los Sprints.
Buen detalle dejar el QR de la landing page al final.

Feedback negativo de estudiante

No procede.

Feedback de profesores (Carlos)

El icono de la demo indicando el rol que usa la aplicación es muy bueno.
Le ha gustado mucho las métricas (de IA).
Podrían meterse ellos mismos en los iconos. Ayuda para enlazar el killer opener con la demo y que quede todo muy hilado.
Deben revisar Capex y Opex, deben desglosarlo.
Son el primer grupo que plantea bien el problema y la solución.
Le gusta la gráfica que se cruza con costes y presupuestos.
En cuanto a los usuarios piloto, asumen que todo el feedback son errores; ellos dicen que no.

Semana 6

Camyo

App para juntar camioneros con empresas

Feedback positivo de estudiantes

Buen killer opener
Presentación muy visual
Muy buena la traspa de los costes.
Muy buena cantidad de diapositivas.
Muy buenos datos de usuarios piloto.
Comenta peticiones de los UP, muy interesante
Demo completa, se muestra la funcionalidad completa.
Han resuelto bien sus problemas de carga de trabajo de backend y frontend.
Han tomado medidas para la planificación del proyecto creando todas las issues en el primer día.
Han hecho caso al feedback y han añadido los empleados de la semana.
Termina con el QR de la landing page.

Feedback negativo de estudiante

Presentador nervioso. Da paseillos.
La demo no se ve bien y tampoco se escucha muy bien.
Es importante vocalizar en la demo, no se entiende.
Muy larga la demo.

Feedback de profesores (Carlos)

He empezado más nervioso de la cuenta por el problema técnico, hay que empezar como si nada hubiera pasado.
El storyBoard necesita un usuario target definido, sino no funciona, si quieres centrarte en un público objetivo tienes que dedicarle a ellos el storyBoard.
El killer opener le ha gustado, aprovechar elementos del momento siempre está muy bien, pero le sigue faltando una mejor conexión con la demo.
Capex y opex bien interpretados
Tienen separado costes y ganancias y no le permite unirlo todo. Una gráfica de corte puede quedar bien (Gastos/Ingresos).
Ha dicho muchas cosas sin apoyo visual, esto puede hacer que los oyentes desconecten.
La demo se escucha y se ve poco.
El audio lo ha grabado una sola persona y deberían ser dos.
En la traspa 19 (reloj de avance del proyecto) hay demasiada incertidumbre.

Feedback de profesores (Cristina)

Inicia muy bien la presentación.
Un poco rápido, la primera parte se la han perdido, tras los competidores, lo que hace la app en el storyboard no se ha entendido
¿A quién va dirigido el storyBoard? Quizás haya que hacer un storyBoard por cada usuario target.
Le gusta el enfoque del ámbito legal, las conclusiones y decisiones le gustan.
Cuidado con la expresión. «Bueno, ¿Cuánto costamos?», hay que intentar matizar bien los términos que se usan. También usa «Competición» en lugar de competidores. Hay que corregirlo.
No le ha quedado claro si han clasificado o no el feedback de los UP, es importante clasificarlos por importancia para el sprint 3.
La demo no se ve bien, no se escucha bien, y se hace monótona.
Le falta el email de contacto en la última transparencia.
No han tenido ningún problema en la retrospectiva, esto le resulta raro.

Semana 5

FisioFind

App para consultas de fisioterapia

Feedback positivo de estudiante

Killer opener espectacular. Han hecho caso al feedback: relacionan el problema que pretenden resolver.
Todos los rangos de edades pueden sentirse identificados con el killer opener.
Tabla de competidores muy visual.
Van a un ritmo que hace que se mantenga la atención.
Han seguido el feedback y los costes son redondeados (uso de K).
No han dejado solo al manager para la asignación de tareas.
Son sinceros con respecto a las horas trabajadas y toman medidas para subsanar el problema.
Las transparencias de los costes se ven muy bien, todo muy claro.
Tamaño de letra muy bueno.
Equipos explicados de manera muy clara, con un nivel de detalle adecuado.
Demo muy visual, va explicando todo a medida que sucede. Va al grano.
Han logrado implementar el caso de uso core que tenían, su factor diferencial.
Han hecho caso al feedback y han puesto al final las lecciones aprendidas.
Se nota que han practicado la presentación.
Han bajado el número de diapositivas, han hecho caso al feedback.

Feedback negativo de estudiante

No han hecho caso al feedback de la semana pasada con respecto a decir qué van a enseñar en el video de la demo antes de ponerlo.
Se ve un poco pequeña la demo, pero mejor que la semana pasada.
Quizás vaya demasiado rápida la demo, apenas da tiempo a observar bien todo.

Feedback de profesores (Carlos)

Han empezado un poco rápido.
No entiende muy bien la parte del video donde dice que “pierde todo el día”. Propone que se vea más claro, como por ejemplo en la consulta de un fisioterapeuta esperando.
Felicita la presentación en general (usa el adjetivo espectacular).
Le han gustado mucho las gráficas pesimista, optimista y esperada.
Dice que en la pesimista se es muy pesimista, debe ser algo menos pesimista.
Más énfasis en los porcentajes de las estimaciones.
Muy bien hilado.
No se veía muy bien la descripción de cada párrafo de la demo.
Bien resumido el análisis de rendimiento de compañeros.
Le parece extraño el mecanismo de quitar puntos.
Bien planteado el tema de los riesgos. Pregunta si ha habido problemas con los riesgos identificados, dice que falta en la presentación.
Deben medir si el foro está funcionando. Hacer una métrica de dudas planteadas y dudas respondidas para comprobar si está funcionando.
¿Cuánto feedback de usuarios pilotos han añadido a historias de usuarios?

Semana 6

FisioFind

App para consultas de fisioterapia

Feedback positivo de estudiante

Killer opener muy bueno. Una historia que une con el problema.
Ataca a la sanidad pública.
Buena idea cambiar los presentadores en una semana intermedia.
El presentador se nota preparado.
Hace referencia a las Theory Pills, para marcar su seguimiento.
Buen cambio en el CA, al cambiar la penalización por un sistema de recompensas.
Introduce los 3 mejores miembros del equipo en la semana.
Utilizan lo que funciona en otros grupos y lo toman como suyo.
La presentación se ve muy bien. Mantiene un diseño homogéneo muy bueno. Muy visual.
Son conscientes de que una solución dada a un problema del sprint anterior se ha convertido en un problema (Foro de FAQ).
Muy buena idea el meme de la semana.
Costes claros.
Hace buenos chascarrillos durante la presentación para retomar la atención de la audiencia.
Termina con toda la información y del QR.

Feedback negativo de estudiante

Tiene una dicción demasiado rápida a veces. Pero no parece nervioso.
Se para mucho en los competidores.
Añaden una métrica y luego le restan valor diciendo que no es representativa del estado actual del proyecto.
Demo muy rápida, sin zooms y sin voz ni, evidentemente guion. Muy por detrás del resto de la clase. Es importante copiar lo bueno.
La demo no da tiempo a ver bien, va muy rápido, hay pantallas donde la letra es muy pequeña.
La demo va tan rápida que se ha perdido con la presentación. Storyboard muy breve. Y en un estado precario.

Feedback de profesores (Carlos)

A Dani le ha faltado un poco de energía al presentar.
Lo que le faltaba al supermega anuncio de Guadalupe era lo que hoy ha comentado Miguel.
La mezcla sería estupendisima y divina de la muerte
Hay que pensar formas más efectivas de hacer graficas. Como gráficas acumulativas para ver todas las tasks que están en to do, in progres…
Los carteles que explican la funcionalidad pasan muy rápido. Podrían ponerme más tiempo o ponerlo a un lado.
Ya están contemplando el tema de aspectos legales, esto le gusta mucho.
Deberían copiar algunas métricas que funcionan en otros grupos o dar un mayor nivel de detalle en las suyas propias.
El sistema de recompensas debería ser gratuito. (Dejar que él elija primero la issue que quiera hacer)
En las transparencias 19 y 20. Falta evolución de los problemas encontrados. Falta ver si la solución es eficiente,
Cambiar los colores de abierto y cerrado. Sale abierto en verde y cerrado en rojo.
Medir cuán alcanzable es el objetivo hasta la fecha.

Feedback de profesores (Cristina)

Buen inicio efectivo, deja bien claro lo que no existe para que en el elevator pitch se destaque lo positivo. Bien ensayado el discurso.
Ha mejorado mucho la apariencia visual. Le gusta mucho, es muy profesional.
Han dedicado mucho tiempo en los competidores.
Buen guiño a la píldora teórica.
Mucho implementado
La demo no se ve bien, es muy pequeña.
Los jueves el aula está reservada, se lo recuerda al grupo por algo.
Pregunta cómo se mide el rendimiento del equipo.
Esperan ver todas las semanas el rendimiento.
La métrica a veces es un objetivo y otra cosa es la evolución para llegar al objetivo, ponerlo en una misma columna de métrica no es adecuado.

Feedback de final de clase

Semana 1

Commitment agremment firmado
Sistema gestión del tiempo (clockify)
Presupuesto temporal
Velocidad presentación bien 2do turno, eficiencia de las presentaciones
Identificación de los roles, ajustado a los tiempos que tenemos
Indicar el TCO
Centrarnos en lo que nos piden, con todo el detalle que comentemos
Analizar el DAFO vs Describir el DAFO
Mejor analizar en como neutralizar debilidades y amenazas
Claro modelo de negocio, planes de precio
Casos de uso core
Qué funcionalidad está dispuesto el usuario piloto a pagar, que no ofrezcan otros
Refinar la idea clave de negocio. Business Statement (frase, intro interesante, etc.)
Análisis de competidores Profundizar, analizar, y si es necesario, pivotar. Tiene que quedar claro
Lista exhaustiva, y no evidente
En la presentación lo que se pueda asimilar, no todo. Ya luego se puede preguntar Usuarios pilotos
Más de 12 usuarios pilotos, mínimo. Normal de 20 a 30, de cada tipo
Si hay problemas encontrándolos, no está claro el objetivo o no hay mercado
Segmentar para ver quién llamar si falla
Ver cómo interactuar con ellos
Yo creo que reuniones de 1 hora, en general mejor. Por subgrupos. Cada reunión de unos 10 a 15 min, a poder ser

MVP, casos uso core
Mockup entendido como algo centrado en la funcionalidad
Grado Innovación, lo que hay por detrás
Composición, soft skills
Comentar el commitment agreement
El estado, si firmado, lo que queramos resaltar IA
Empezar a pensar en un análisis de riesgos inicial
¿Qué puede hacer que sea un fracaso el proyecto? Planes de contingencia y demás

Semana 2

Anexos: Commitment Agremment, con responsabilidades y demás, reflejado aquí
- Si no se cumple con algo, hay un responsable
- Todo plasmado
Presentación: También si no se ha cumplido algún punto, por qué (anónimo o con responsable)
- Versionados para el CA también
En lugar de echar del grupo, penalizaciones. Hemos sido muy estrictos quizás
- Lo comentan sobre todo por nosotros
- Reencaminar la situación
Puntuaciones entre nosotros:
- Hay que hacerlo en cada entregable
- Va a tener impacto en la nota al final
Nos subirán Failure conditions, para saber qué no falla seguro, porque si no suspenso:
- Un riesgo es un evento que puede causar pérdidas económicas en
  - Los más importantes en la presentación
  - Priorizarlos
  - Acciones para mitigarlos
- TCO general, por meses, facturación mensual no por año
  - Sin iva, porque es el total y el iva va por otro lado
  - Los costes de la empresa es distinto del salario bruto del neto
  - Tener en cuenta el problema del coste para la empresa
  - Añadir coste de GitHub para desarrollo
- Termino para los servicios
  - COSTES DE PSG2, por los servicios
  - Añadir en las transparencias los valores entre general y específico, con la prueba del algodón (que se vea)
  - 16 min de presentación
    - 40 o 50 diapositivas no es viable
    - Son estrictos hasta la médula. Ni un segundo de más, pero acabar en el último minuto
    - Asistencia obligatoria
    - Se pedirá feedbacks voluntarios, o lo piden
    - Atender sí o sí, propuestas o cosas positivas
    - Test corto de teoría, traer portátil
- Qué esperan ver:
  - Elevator speech, describiendo muy bien la temática, que capte la atención del público
  - Tipo de negocio
  - Análisis de competidores
  - Analisis preliminar de TCO
    - Personal
    - Proyecto
    - Apoyo, (Github, office, etc)
    - Licencias
    - Costes indirectos
    - Mantenimiento
  - Gestión usuarios pilotos
    - Píldoras teóricas
  - Mockups más específicos, con finalidad para el Sprint 1
    - La idea es que en el S1 estén todos estos casos de uso
  - Innovación
  - Stack tecnológico
  - Plan de gestión de riesgos
  - Equipo
    - Buena imagen, ver los miembros
    - Imagen corporativa
      - No papá noel
      - Uniforme, Skills
  - Desarrollo
    - Plan gestión calidad
      - Ante fallos, cómo medir y solucionar
    - Modelo rendimiento del equipo
      - Cómo van cada semana
      - Cuantitativo
    - Stack tecnológico
      - GitHub
      - Actions
      - Projects (es bueno por aquí, porque se monitorizará finalmente)
      - Controlemos CD/CI
    - Gestión del código
      - De cara a los S1/2/3
        
        Cómo etiquetar, versionado del código
    - En los entregables hay varios despliegues, estáticos, para que queden fijos, y así pueden mirarlos siempre
      - Importante en dónde lo desplegaremos, que ahí estarán los 5 despliegues
      - Todas las elecciones hay que verificarlas si se pueden llevar en esos despliegues
      - Análisis para ver que siempre se pueda acceder al final ahí
    - Landing page, privada con acceso a los profes
      - Con email, resumen equipo, etc
      - Última diapositiva, con QR para poder acceder
- Planificación
  - División de casos de uso en cada Sprint, más concreto para el Sprint 1. Cuánto podemos tener implementado para el siguiente sprint
Reporte uso IA
Presentar con el nivel de detalle importante. Si nos piden más detalle, otras diapositivas
Landing page:
- “Despliegue”. Google Sites por ejemplo

Semana 3

Para facilitar la obtención de más feedback, las presentaciones se limitan a 15 minutos. Es necesario recalcular el tiempo disponible para el feedback.
En relación a los usuarios pilotos, el plazo para apuntarse finaliza hoy a las 20:00.
Todo lo relacionado con la evaluación debe ser cuantitativo y objetivo, utilizando métricas claras como tareas completadas, horas registradas en Clockify y el ratio de respuesta.

Introducción (15-20% del tiempo)

Killer opener: Comienza con algo impactante que capte la atención.
Elevator pitch: Breve y claro resumen de la propuesta de valor.
Resumen de análisis de competidores: Incluir una tabla comparativa con los diferenciadores clave, realizando un análisis rápido.
Resumen de análisis de costes: Explicar brevemente los aspectos clave de costes.
Equipo (10%): Presentar al equipo y sus roles, destacando el compromiso y cualquier situación relevante en el "commitment agreement".

Prototipo (15%)

Capturas de pantalla de código: Mostrar ejemplos relevantes del código para evidenciar el trabajo realizado.
Videos concisos: Incluir videos que vayan al grano y aporten valor real, demostrando funcionalidades clave.
Tecnología aplicada: Explicar cualquier tecnología utilizada para mejorar el desarrollo.
Análisis del rendimiento del equipo: Describir cómo cada miembro contribuye y las tareas que realiza.
Productividad de cada miembro: Incluir métricas de productividad de los miembros del equipo.
Trazabilidad y gestión de riesgos: Mostrar cómo se identificaron los riesgos, el estado actual de los mismos y cómo se están gestionando.
Lecciones aprendidas: Presentar los aprendizajes obtenidos de cualquier problema enfrentado.
Reloj de avance del proyecto: Incluir una visualización clara de cuánto tiempo se ha invertido y cuánto queda por completar.

Planning (15-20%)

Reestimación del sprint 1: Ajustar los objetivos finales del primer sprint con base en el progreso actual.
Estimación de los sprints 2 y 3: Presentar estimaciones de tiempo y objetivos para los siguientes sprints.

Gestión de usuarios pilotos (10%)

Usuarios pilotos: Detallar cuántos usuarios piloto se tienen, su tipo y una agenda para trabajar con ellos.
Proceso de contacto: Explicar cuándo y cómo se contacta a los usuarios pilotos, el tiempo que se les da para responder, cuándo se les entregará el software y cómo se recibirá su feedback.
Planificación temporal: Asegurarse de que la planificación del trabajo con los usuarios pilotos sea clara y concisa.
Responsabilidad del feedback: Es importante recordar que la responsabilidad del feedback es del equipo, no solo de los usuarios. Facilitarles la tarea puede ser clave, por ejemplo, proporcionando plantillas para facilitar la recopilación de feedback.

Uso de IA

Resumen del uso de IA: Explicar cómo se ha utilizado la inteligencia artificial durante el sprint 1 y sus beneficios.

Presentaciones más técnicas

Analizar problemas reales: Analizar casos reales y problemas concretos que se hayan enfrentado durante el desarrollo del producto.
Recomendación para el próximo despliegue: Sugerir realizar el despliegue para la siguiente sesión, basándose en los avances actuales.

Semana 4

Siguiente clase evaluación.
15 minutos para presentar.
Asistencia obligatoria, test.
Nueva píldora teórica.
El contenido de la presentación no cambia.
Se espera ver:
- Killer opener 1 minuto.
- Elevator pitch 30/45 seg.
- Resumen del análisis de competidores.
- Resumen de análisis de costes (concepto TCO, diferenciar capex y opex?).
- Estimación a corto 4,6 meses (desde ya) y a medio 1,2 años de los gastos y los ingresos. Gráficas. Tres curvas: la pesimista, optimista y esperada. (ESTO NO SE PIDIO ANTES).
- Situación actual respecto al total esperado (Seguimiento).
- Ingresos, justificar de donde vienen y justificar a donde van.
- En gastos: 3 curvas: Pesimista, optimista, esperada.
- Equipo max 2 minutos.
- La demo que se vea.
- Pensar en formas más amenas de presentar la demo. Editar el vídeo, por ejemplo.
- Demo con casos de uso core (15%?).
- Retrospectiva:
  - Análisis de rendimiento de equipo 1 traspa con productividad y análisis del equipo.
  - Resultados automatización y análisis del código.
  - Problemas con su estado abierto, solucionado…
  - Lecciones aprendidas.
  - Medición: forma de saber si está funcionando el mecanismo de solución del problema.
- Reloj del avance del proyecto (inversión respecto a esperado).
- Medir la calidad del software.
- Gestión de usuarios piloto:
  - No hace falta comentar cómo hemos captado los up.
  - Ya no nos centramos en la captación de usuarios pilotos, los que tenemos son los que son, estamos en el periodo de gestión. Cómo los gestionamos.
  - Cuántos tenemos.
  - Los roles que tienen.
  - Cómo nos comunicamos con ellos, cómo gestionamos su feedback, fechas…
  - Cómo se gestionan de cara al S2.
- Necesitamos ya feedback de los up.
- Planificación para el sprint 2.
- Si afecta, planificación para el sprint 3.
- Reporte del uso de la IA. Analicemos la salida.
- Última diapositiva landing page.
- Más la documentación de la failure conditions: Utilizar markdown no pdfs.

Semana 5

Usar enlaces en Markdown.
Usar contributors del README de Docusaurus.
Incluir licencias que estemos usando (informarnos de estas).
BCC: ¿Hay protocolo para controlarlo? Muy pobres los informes de aportaciones a la BCC.
Evidenciar el trabajo en los Markdown, a nivel de implementación, de Clockify, etc.
Automatizar métricas y otras cosas.
Informes de tiempo invertido individuales.
Incluir "empleado de la semana". Un ranking. Póngase el top 3. Destacar en positivo los que más han trabajado.
15 mins presentación.
Killer opener de 1 min.
Elevator pitch que enlace con el killer opener. Si se enlaza bien, queda en una frase.
Análisis de competidores.
Storyboard de un anuncio:
- Anuncio usuarios.
- Anuncio inversores (totalmente distinto a los otros: datos, cifras, etc.).
- Anuncio clientes.
Implicaciones legales (GDPR obligatorio).
¿En qué afecta el GDPR en la implementación? Recomienda asignar a alguien encargado de esta parte.
Haced términos y condiciones.
CapEx es gasto capitalizado.
Estimaciones a corto, medio y largo plazo.
Demo con datos reales o realistas a partir de ahora.
Gestión de UP para el S2.

Semana 6

Proximo dia evaluación, ver las píldoras teóricas.
Sugiere no hablar mucho de las reuniones en las presentaciones. Sugiere también un calendario compartido para llevar a cabo las reuniones.
Recomienda tener un changelog para tener un seguimiento.
fix, docs, feats, son etiquetas que nos recomienda usar para mejorar el historial
Pilot User Commitment Agreement con los estudiantes.
Tener cuidado a la hora de salir y entrar.
Introducción killer opener max 1 min
Elevator pitch 30 seg
Análisis de competidores al grano
Storyboard de otro target (usuario, cliente, inversor)
Customer agreement (clausular no abusivas a ser posible)
Princing
Acuerdo de nivel de servicios
Implicaciones con apis a nivel de terceros que quiza debamos añadir, si tienen repercusión.
SLAs
Implicación en la implementación
TCO igual que hasta ahora
Resumen del equipo y roles.
Commitment Agreement Status.
Demo mejorar.
retrospectiva sprint 2
Añadir un gráfico (matriz de rendimiento y esfuerzo con 4 cuadrantes, arriba derecha alto rendimiento y esfuerzo, alto rend y poco esfuerzo, poco rend poco esf…)
Resultado de análisis de software
Problemas encontrados: Además del estado, decir explícitamente acciones concretas de cómo se ha abordado o se está abordando el problema y tenemos que evaluar de alguna forma estas soluciones. (ha servido la solución o no) y lecciones aprendidas
Reloj del avance del proyecto con rendimineto y esfuerzo
Gestión de usuario piloto, feedback recibido, comunicación con ellos…
Planificación y replanificación (de cara al sprint 3)
(S3) Aspectos de seguridad: Validar cuentas de correos, que las tarjetas de crédito tengan el numero de digitos… - Validez de datos, validez en los formularios.
¿Las api de comprobación tienen reflejos en el opex?
Se puede hacer lo de enviar un correo y que se pulse un botón como verificación.
Evitar cosas genéricas. No triviales.

FIN DE LA APORTACION

Aportaciones de consolidación

Por otra parte se ha añadido al conocimiento común feedback concreto para cada apartado (presentaciones, Killer opener, usuarios piloto, desarrollo del producto, análisis y garantía de la calidad, idea de negocio, análisis de costes y TCO, organización del equipo, Commitment Agreement, uso de la IA, Sprint retrospective y demo del producto). Estas aportaciones pueden verse aqui.

Presentaciones.md:

Semana 17/03

Claridad y estructura: Explicar bien la propuesta de valor y priorizar información relevante. Si la diapositiva es genérica, es decir, común a todos los proyectos, no tiene cabida en la presentación, es importante centrarse en las particularidades.
Acompañamiento visual: Es importante que el presentador no hable en exceso de un tema sin apoyo visual de la presentación, esto provoca desconexión en la audiencia.
Expresión oral: Ensayos previos para mejorar la fluidez, pausas y vocalización. Es importante decidir con antelación qué elementos son prescindibles, por si se da el caso de que el presentador vaya con el tiempo justo para terminar, ser capaz de, con soltura, poder decidir que elementos desechar y cuáles aportan valor diferencial.
Convencer a los inversores: Especificar rentabilidad, mercado objetivo y diferenciación, los inversores no deben realizar cálculos con los porcentajes entregados en la presentación, es mejor darles los datos en la forma más sencilla (ej. no decir que tenemos un 1% del mercado, sino comentar que estamos instalados en 1000 locales)
Utilizar la notación K € para referirse a miles.
Colores intuitivos: Hacer uso de la psicología de colores (ej: usar el verde para lo positivo y rojo para lo negativo).

Killer opener.md

Semana 17/03

El killer opener debe estar estrechamente relacionado con el tema a tratar y servir como una introducción breve. Además, esta conexión debe ser evidente y comprensible de inmediato para facilitar una transición rápida hacia la introducción (no nos interesa extendernos demasiado).
Tener cuidado con el copyright, es importante atenerse a la legislación vigente.
Utilizar un tema impactante, que demuestre que existe una necesidad acuciante que nuestro factor diferencial consigue suplir.

Usuarios piloto.md

Semana 17/03

Si los usuarios piloto aún no han tenido la oportunidad de probar la aplicación, nos encontramos en una situación crítica. Es fundamental recibir su feedback sobre las funcionalidades clave. Si estas aún no están implementadas, esto indica un retraso significativo en el desarrollo que hay que paliar con la mayor presteza posible.

Desarrollo del producto.md

Semana 17/03

Un storyboard bien desarrollado ayuda a visualizar el flujo del producto. Sin embargo, en algunos casos es demasiado simple o poco efectivo, lo que dificulta entender el valor de la solución, es fundamental que se comprenda de forma rápida a quién va dirigido el storyboard, cuál es el público objetivo, además, se valorará de forma positiva su realización a mano, con el objetivo de aportar originalidad y distinción de la competencia.
Reevaluar si realmente se está priorizando lo importante del producto, priorizar el factor diferencial y apartar lo secundario hasta que tengamos la seguridad de que la implementación sea robusta y contiene la validación adecuada.

Analisis y garantia de la calidad.md:

Semana 17/03

Falta de métricas cuantitativas: En varios casos, no se han proporcionado datos numéricos que respalden el rendimiento del producto o su impacto. Sin estos, la presentación puede generar dudas sobre su viabilidad. Se recomienda incluir porcentajes de mejora, estimaciones de rendimiento o datos financieros claros.
Entrega tardía de la app a usuarios piloto: el retraso en el recibimiento de feedback de los usuarios piloto nos deja menos margen de tiempo de respuesta para corregir errores, por lo que es crucial comenzar con este proceso para ir realizando análisis de aceptación a lo largo del tiempo, y comprobar de esta manera si la opinión con respecto a la aplicación mejora o no.

Idea de negocio.md:

Semana 17/03

Realizamos estimaciones de la rentabilidad en términos monetarios, pero estas se basan en la penetración de mercado (cantidad de usuarios absorbidos). Por lo tanto, es fundamental considerar ambas métricas de manera coherente.
Uso de datos cuantitativos, a los inversores no les basta con decir "Seremos muy rentables", es necesario indicarles cuánto sera necesario que aporten, en cuánto tiempo recuperarán la inversión y qué ganancias procederán desde entonces. Todo con datos específicos.

Análisis de costes y TCO:

Semana 17/03

Estimación realista de los costes: no es correcto añadir un valor arbitrario a los equipos, estos se deben tratar como amortizaciones.
Es importante justificar los cálculos de costes y no dejar cifras al aire sin explicar de dónde provienen, hay que justificar la rentabilidad monetaria con la penetración de mercado, pues esta primera deriva de la segunda.
Se deben proporcionar cifras claras sobre el retorno de inversión (ROI) y los costos operativos (OPEX) para que inversores y audiencias puedan evaluar la sostenibilidad del proyecto.
Inclusión de más datos cuantitativos para respaldar la viabilidad del negocio.

Organizacion del equipo.md:

Semana 17/03

No incluir un sistema de recompensas basado en dinero, es preferible otro tipo de incentivo (ej: Dejar a elección la primera tarea que se quiera realizar)
Copia de buenas prácticas de otros equipos (team bonding, empleados del sprint, meme de la semana...) en pos de reforzar la conexión entre los miembros y generar sensación de unidad y sentimiento de pertenencia.

Commitment Agreement.md:

Semana 17/03

Comentar explícitamente si ha habido algún miembro que no ha cumplido con las expectativas, compromisos no cumplidos del CA, qué medidas se han tomado y si estas han servido para solventar el problema.

Uso de la IA.md:

Semana 17/03

No realizar comentarios genéricos sobre el uso de la IA, como lo pueden ser: "La IA nos ha ayudado mucho" o "Hemos ahorrado tiempo", es preferible dar datos cuantitativos, comentar qué problema en específico ha resuelto y cuánto tiempo se cree ha ahorrado con ello.

Sprint retrospective.md:

Semana 17/03

Destacar los problemas encontrados, no es aceptable comunicar que "no ha habido problemas", pues estos siempre están al acecho, y es necesario evaluarlos minuciosamente con la mayor prontitud y proponer soluciones factibles, además debemos comentar si estas soluciones han surtido efecto, y en este caso, si son definitivas, o simples parches temporales.
Es una buena práctica generar gráficas para las métricas de rendimiento, para ser capaces de evaluar la eficiencia de los miembros (tiempo/tarea realizada) y su evolución durante los sprints.

Demo del producto:

Semana 17/03

Centrarse en los casos de uso core, demostrar la operatividad del factor diferencial de la aplicación.
Es inaceptable que haya elementos clave no visibles, una opción es la inclusión de zooms para que se pueda observar con total claridad que se pretende realizar en cada momento.
Es de vital importancia que la demo sea atractiva al público, para ello podemos utilizar un registro informal de carácter cómico que pretenda relatar una historia, mas hay que cuidar el registro y ser conscientes de nuestro público objetivo.

FIN DE LA APORTACION DE CONSOLIDACION

Grado en Ingeniería Informática – Ingeniería del Software​

Control de Versiones​

Índice de Contenidos​

1. Introducción​

2. Aportaciones realizadas a la BCC​

Sprint 1​

Aportación exacta:​

Semana 1​

Semana 2​

Semana 3​

Semana 4​

Grupo 2 - GastroStock​

Semana 1​

Semana 2​

Semana 3​

Semana 4​

Grupo 3 - EVENTBRIDE​

Semana 1​

Semana 2​

Semana 3​

Semana 4​

Grupo 4 - BORROO​

Semana 1​

Semana 2​

Semana 3​

Semana 4​

Grupo 5 - Camyo​

Semana 1​

Semana 2​

Semana 3​

Semana 4​

Grupo 6 - FisioFind​

Semana 1​

Semana 2​

Semana 3​

Semana 4​

Aportaciones de consolidación​

Sprint 2​

Aportacion exacta:​

Semana 5​

Semana 6​

Semana 5​

Semana 6​

Semana 5​

Semana 6​

Semana 5​

Semana 6​

Semana 5​

Semana 6​

Semana 5​

Semana 6​

Feedback de final de clase​

Semana 1​

Semana 2​

Semana 3​

Semana 4​

Semana 5​

Semana 6​

Aportaciones de consolidación​

Presentaciones.md:​

Semana 17/03​

Killer opener.md​

Semana 17/03​

Usuarios piloto.md​

Semana 17/03​

Desarrollo del producto.md​

Semana 17/03​

Analisis y garantia de la calidad.md:​

Semana 17/03​

Idea de negocio.md:​

Semana 17/03​

Análisis de costes y TCO:​

Semana 17/03​

Organizacion del equipo.md:​

Semana 17/03​

Commitment Agreement.md:​

Semana 17/03​

Uso de la IA.md:​

Semana 17/03​

Sprint retrospective.md:​

Grado en Ingeniería Informática – Ingeniería del Software

Control de Versiones

Índice de Contenidos

1. Introducción

2. Aportaciones realizadas a la BCC

Sprint 1

Aportación exacta:

Semana 1

Semana 2

Semana 3

Semana 4

Grupo 2 - GastroStock

Semana 1

Semana 2

Semana 3

Semana 4

Grupo 3 - EVENTBRIDE

Semana 1

Semana 2

Semana 3

Semana 4

Grupo 4 - BORROO

Semana 1

Semana 2

Semana 3

Semana 4

Grupo 5 - Camyo

Semana 1

Semana 2

Semana 3

Semana 4

Grupo 6 - FisioFind

Semana 1

Semana 2

Semana 3

Semana 4

Aportaciones de consolidación

Sprint 2

Aportacion exacta:

Semana 5

Semana 6

Semana 5

Semana 6

Semana 5

Semana 6

Semana 5

Semana 6

Semana 5

Semana 6

Semana 5

Semana 6

Feedback de final de clase

Semana 1

Semana 2

Semana 3

Semana 4

Semana 5

Semana 6

Aportaciones de consolidación

Presentaciones.md:

Semana 17/03

Killer opener.md

Semana 17/03

Usuarios piloto.md

Semana 17/03

Desarrollo del producto.md

Semana 17/03

Analisis y garantia de la calidad.md:

Semana 17/03

Idea de negocio.md:

Semana 17/03

Análisis de costes y TCO:

Semana 17/03

Organizacion del equipo.md:

Semana 17/03

Commitment Agreement.md:

Semana 17/03

Uso de la IA.md:

Semana 17/03

Sprint retrospective.md: