Saltar al contenido principal

Presentacion

En este documento vamos a encontrar feedback respecto a las propias presentaciones (diapositivas).

Semana 1​

  • Segmentación de ideas: para una mayor aclaración de ideas y una transmisión más clara del mensaje.
  • Referenciar las diapositivas: colocar números e identificadores en las diapositivas
  • Estar atentos al exceso, tamaño y fuente de las letras en el powerpoint: es mejor tener imágenes que ayuden a explicar las diapositivas.
  • Debe estar presente el control de tiempo con aplicaciones como Clockify como parte de la presentación.
  • Las tablas comparativas en la presentación deben ser más concisas.
  • Usar palabras claves en las diapositivas en lugar de meter mucho texto.
  • El diagrama UML no se presenta: debe estar en la documentación
  • Cuando se presenten cantidades monetarias, hacerlo redondeando y sin colocar céntimos. Ejemplo: si tenemos de presupuesto 67.839,45, en las diapositivas escribirlo como 68K.
  • Debe haber soporte visual que acompañe al discurso y a la presentación.
  • Al insertar el diagrama DAFO en las diapositivas es importante el orden para que sea facil de entender.
  • En cada presentación hay que reflejar el avance de las horas consumidas durante el proyecto.
  • Tratar de homogeneizar las fotos de los participantes, que no tengan fondos muy diferentes.

Semana 2​

  • Evitar sobrecargar las diapositivas.
  • No mezclar idiomas.
  • Marcar las diapositivas que sean respuesta de seguir feedback anterior.
  • Dejar los mockups para el final de la presentación.

Semana 3​

  • Para practicar las presentaciones es recomendable la tecnica de hacerlo previamente con miembros del grupo, para que estos puedan aportar feedback sobre las diapositivas o la propia presentación.
  • Es recomendable que las diapositivas pasen el visto bueno de todos los miembros del grupo.
  • Al exponer en las diapositivas los usuarios piloto, hay que indicar si se está en contacto con ellos.
  • Cuando se usa github actions hay que poner captura de la estimación en las diapositivas.
  • Seguir mejorando la forma de expresar mas en menos.
  • No hablar tan rapido, el público puede llegar a colapsarse y quitarle atención para descansar.
  • Indices innecesarios.
  • Mal uso de los espacios en las trasparencias.
  • Valorar el uso del microfono.
  • No usar tantos colores en la presentación y menos en pricing y ese tipo de información que SI hay qu emirar la diapositiva.
  • Importante uniformidad en las fotos.
  • Números en las diapostivas y la marca del feedback bien visible.
  • Mirar al público, no mirar el suelo.

Semana 4​

  • Las demos de los prototipos se deben ver bien, hacer zoom si es necesario.
  • Evitar letras blancas sobre colores claros.
  • Si hay datos en el tiempo (días) poner como apoyo visual un calendario.
  • Se debe ser coherente lo que se refleja en la diapositiva con lo que pone en el título.
  • Evitar sobrecarga en las presentaciones, buscar la simplicidad y la correlación entre diapositivas.
  • Marcar más el reconocimiento que se dice que se tiene sobre el Commitment Agreement. Poner un pódium con los nombres.
  • Usar recursos en la presentación como líneas o subrayados para corresponder con lo que se dice.
  • El DAFO ya no merece la pena incluirlo en la presentación.
  • Pensar en si es mejor una DEMO grabada o en directo.
  • Indicar con triángulos hacia arriba o abajo cuando haya habido rendimiento positivo o negativo en la retrospectiva.
  • Siempre debe haber una transparencia con la productividad por miembro del equipo (horas).
  • Si se dicen las tareas que ha hecho cada subgrupo deben ir acompañadas de un diagrama de gantt simplificado o similar en el que se vean para cuando estaba planificada cada una.
  • No meter una imagen de un QR si no es funcional o al menos aclarar que no lo es.
  • No basta con mostrar los problemas que ha habido durante la semana de trabajo, se debe mostrar siempre el análisis de riesgos inicial.
  • No mezclar la retrospectiva con la autoevaluación.
  • Debe quedar reflejado en la presentación que cuando no se llega el trabajo planificado se ha incumplido alguna cláusula del Commitment Agreement.
  • Deben quedar claro los responsables de una tarea.
  • En la presentación deben quedar claros los análisis del rendimiento y los límites operativos de github (github actions) para justificar el plan que necesitamos. Por ejemplo, cuánto tarda en evaluar a X usuarios para formar un grupo.
  • En la autoevaluación debe haber un análisis con métricas y números claros.
  • Siempre que se muestren problemas en el trabajo en equipo en la presentación, se mostrarán las medidas que se tomarán para solventarlos con las métricas con las que se medirá la eficacia de las respuestas.
  • A cada sprint siempre se debe mostrar la planificación o re-planificación de los próximos sprints.
  • Se busca una mejora de la síntesis cada semana, no se deben eliminar conceptos de una a otra.
  • Mantener siempre una diapositiva con la Landing Page con QR aunque sea en la última diapositiva.
  • Siempre incluir los estados de la comunicación en la gestión de usuarios pilotos.

Semana 5​

  • Para la semana del 12/03/2024 se tiene que presentar (15 minutos) una retrospectiva genérica que incluya el tiempo invertido, tareas hechas, rendimiento del equipo, problemas, commitment agreement, etc...
  • También se debe hablar del procedimiento de evaluación de los miembros del grupo.
  • Para la semana del 19/03 tiene que tener una estrutura similar a la semana 4: killer opener, elevator, modelo de negocio, resumen de analisis de competidores, empezar a pensar en un story board (anuncio orientado a alguno de nuestros clientes), impacto legal del proyecto (licencia y otros aspectos legales), customer agreement.
  • Resumen analisis TCO (añadir actions), situación actual respecto al total, estimaciones realistas, optimistas, DEMO de la mitad del sprint2 (comparar demo sprint1 con la del 2), datos realistas (en la demo), retrospectiva de la mitad del sprint2.
  • ALM (todo lo que está en la píldora), hablar de como ha evolucionado la calidad del código.
  • Gestión de riesgos que se han convertido en problemas y problemas que no vengan de riesgos. Como vamos a reaccionar y como hemos reaccionado.
  • Reloj de avance del proyecto. (semanal y global)
  • Gestión de usuarios pilotos (como estamos gestionando ese feedback)
  • Planificación, reestimación del sprint2 y sprint3. Meter algo de pago para el sprint2.
  • Report de IAs, y qr de la landing al final de la presentación.

Semana 6​

  • Los diagramas UML no deben llamarse de esa forma, un nombre mas correcto sería "Diagrama de diseño" o "Análisis de clases"
  • En los análisis de calidad, las líneas no deben ser rectas, debe existir altibajos dado que lo fin de semana no se trabaja.
  • La presentación debe de empezar a trabajarse desde el primer día. Es metodología agil.
  • Los miembros que no contribuyen al proyecto debe de referirse a ellos como "miembros con falta de proactividad", y esto debe estar incluido en la métrica de rendimiento.

Semana 7​

  • En la demo se deben poner tanto datos como imagenes reales
  • Ver como otras empresas enfocan el elevator pitch para aplicarlo en el nuestro.
  • Hacer zoom en la demo para que se aprecie mejor.
  • Resaltar información y cosas que aporten valor, no lo estético.
  • Resaltar en el storyboard lo que nos diferencia de los competidores.
  • Citar las fuentes usadas.
  • Mostrar el impacto legal del proyecto (GDPR, licencias, aspectos legales, customer agreement).
  • Realizar Storyboard para un rol distinto.
  • El report de IA debe situarse en la penúltima diapositiva, siendo la ultima la diapositiva con la URL de la Landing Page.
  • La presentación de la demo debe ser coherente con lo que se represente en los Storyboards.
  • Hay que realizar zoom en las demos en los momentos donde veamos que se ve pequeño.

Semana 8

  • En la presentación hay que mostrar el incremento de la aplicación en la demo
  • Puede ser buena idea el jugar a hacer cosas curiosas con la demo, como el ejemplo del muñeco que hablaba expuesto por los profesores.
  • Realizar una matriz gráfica 2D de rendimiento del esfuerzo en horas y rendimiento. Siendo una columna rendimiento y la otra horas.
  • A partir de esta semana se debe de tener un anuncio en la presentación

Semana 9

  • Pequeños detalles creativos y graciosos en la presentación pueden quedar muy bien y hacer más amena la misma. Además permite tener a todos los espectadores más atentos.
  • Antes de presentar la demo, se debe indicar que parte de la aplicación vamos a tratar.
  • Si los números en las diapositivas son demasiado largos, escalarlos con el método Monopoly (usar K para cifras de 1000 o más, y M para cifras de 1 millón o más)
  • Las diapositivas de los powerpoint si evitamos usar efectos de movimiento al pasarlas mejor: esos efectos pueden causar mareos.

Semana 10

  • La DEMO debería tener algo parecido a una historia, no debe verse como una lista de funcionalidades. Es buen práctica que el anuncio se vea reflejado en la DEMO.
  • Las presentaciones deben servir de apoyo a la audiencia, no deben parecer apuntes para el orador. Se deben buscar más iconografías e imágenes.
  • No confundir los términos "beneficios" e "ingresos", sobre todo al reflejarlos en la presentación.
  • No usar canciones demasiado conocidas para los anuncios. Plantearse usar herramientas de IA con el nombre de nuestra aplicación para estos.
  • En los anuncios evitar anuncios de dinámica “¿Conoces la app ...?” Es mejor llegar de una manera más orgánica, en la que uno presente las necesidades que puede satisfacer la aplicación y entonces se le ocurra usar la nuestra.
  • Recomendación: Hacer ejercicios de vocalización antes de presentar. Charla de Treasure “Cómo hablar para que la gente te quiera escuchar”. Ayuda para mejorar la vocalización https://www.ted.com/talks/julian_treasure_how_to_speak_so_that_people_want_to_listen
  • Buenisima idea mostrar en la demo el feedback recibido por los usuarios piloto. Aporta valor a la aplicación y muestra que estan en contacto con el cliente.
  • No repasar la GPDR completa, solo indicar las acciones concretas que hayan tomado
  • No subir a youtube los anuncios o demos, puede dar muchos problemas.

Semana 11

  • Hay que intentar conseguir uniformidad en la tipografía y los powerpoint siempre que sea posible. Evitar cambiar mucho los colores y evitar el uso de letrar demasiado grandes.
  • Revisar las partes de la presentación para cambiar las partes más genéricas por contenido más específico del proyecto. Hay que dar razones más allá de "nuestro proyecto es muy bueno", hay que introducir el por qué de las cosas. Esto tambien se aplica a la diapositiva de costes, hay que indicar los criterios usados y especificar el por qué de cuando empieza a ser rentable.
  • Evitar decir frases como "es lo que pretendemos hacer". Hay que decir frases que aporten e indiquen seguridad, como "esto es lo que vamos a hacer". No decir intenciones, si decir hechos.
  • Lo que nosotros vendemos es una aplicacion: NO SE PUEDE DECIR ESO. Hay que maquillarlo. Por ejemplo, "nosotros vendemos una solución social que permite a particulares contactar con particulares para ofrecer servicios"
  • Mostrar fotos y nombres del equipo de desarrollo, intentarlo presentar de forma homogénea.
  • La dema no debe ser demasiado larga y debe haber un balance entre tener una historia y mostrar las funcionalidades. Inventarse 2 o 3 personajes.
  • **Importante:**Hay que identificar y mostrar en la presentación dos personas, especificando motivaciones de usar la app, objetivos que quieren conseguir, etc. -Market segmentation-

Semana 12

  • Vocabulario proveniente de ISPP como Elevator Pitch o matchmaking son terminos dificiles de entender. Hay que usar un vocabulario en el que cualquier persona pueda entenderlo.
  • El elevator pitch debe ser una frase que en 15 segundos venda el potencial del producto.
  • Hay que mejorar el sonido a la hora de poner videos.
  • Hay que tener un hilo argumental en la presentación. Que no sea abrupto.