Grupo 6

En este documento vamos a encontrar el feedback recibido por el grupo 6 del proyecto CiaoLavoro La base de conocimientos individual del grupo 6 ciaolaboro la podeis encontrar en el siguiente enlace: Grupo 6 - CiaoLavoro

Semana 1: 6 de febrero

Respecto a la forma de presentar:

• Ir a una velocidad más lenta de exposición para que se entienda todo mejor.
• Segmentar las ideas para garantizar que el mensaje llegue mejor.
• Controlar los tiempos de exposición.
• Ser concisos a la hora de preguntar y responder. No usar preguntas abiertas nunca.
• Intentar hacer más presentaciones efectivas, intentando generar imagen de marca.
• Cuidado con las ideas que se transmiten: no podemos usar ideas ni expresiones negativas como “es muy feo”.
• Transmitir más seguridad respecto a nuestra confianza en el producto.

Respecto a la presentación:

• Usar un tamaño de letra adecuado: ni muy grande ni muy pequeño.
• Usar referencias visuales.
• No excederse en el texto de las diapositivas.
• Referenciar las diapositivas: poner números e indicadores.
• Faltaban elementos como el TCO, la identificación de roles o el presupuesto temporal.
• Trabajar en la parte de la presentación sobre cuál es el modelo de negocio.
• Añadir el clockify y la gestión del tiempo en la presentación, reflejando el consumo de tiempo.

Respecto al proyecto:

• El presupuesto temporal es importante. Serían unas 1650h (150h de trabajo x 11 miembros de equipo)
• Fundamental identificar los roles y las responsabilidades en los miembros del equipo. Un solo miembro puede tener varios roles o responsabilidades.
• Realizar el TCO (Coste total de operación) con seguridad y tener claro cual es.
• Trabajar en la parte de buscar los casos de usos de la aplicación y la del modelo de negocio.
• Investigar la posibilidad de relaciones 1 trabajo N personas en la aplicación.
• Todos debemos tener el rol de desarrollador.

Semana 2: 13 de febrero

Respecto a la forma de presentar:

• Ha hablado rápido al principio, luego mejor, y al final corriendo, pero ha mejorado con respecto a la última. Recomendable encontrar un término medio. Se aconseja usar el truco de “El bolígrafo” antes de la presentación, que consiste en ponerse un bolígrafo en la boca e intentar hablar, eso ayuda a hablar a un mejor ritmo después.
• Usar el mando para pasar las diapositivas durante la presentación.
• Llevar la bandolera da sensación de querer irse. La gracia ha estado bien para hacer un inicio efectivo pero debe quitarse nada más se empiece a presentar.
• Buen intento de killer opener, se ha transmitido mucha energía al inicio de la presentación. Buscar formas de innovar y mejorar en este aspecto.

Respecto a la presentación y las diapositivas:

• Aumentar el tamaño de los mockups para que se vean bien desde el fondo de la sala.
• Mejorar el orden de las diapositivas. Hacer que sea todo más fluido para que se entienda mejor, hay que evitar saltar de un tema a otro sin justificación.
• Mostrar el mockup de la aplicación al final de la presentación, si no, se siente como una interrupción.
• Dividir en varias diapositivas el Producto Mínimo Viable (MVP), y acompañarlo con apoyo visual para que la gente no se desconecte. No hablar demasiado en una única diapositiva, si se ve que una diapositiva consume mucho tiempo, dividirla en varias.
• Controlar el idioma del Mockup: o español, o inglés, pero no mezclar ambos.
• Añadir el análisis de competencia, de forma elaborada e indicando cómo se ha hecho y qué criterios/términos de búsqueda se han usado para buscarlos.
• En el apartado de riesgos, usar referencias visuales en lugar de “R3”.
• Comentar el commitment agreement, monitorizarlo e indicar si se ha modificado o si se está cumpliendo. No se trata de hablar sobre qué consiste sino en hablar sobre si se está cumpliendo por parte de los miembros del equipo.
• Comentar los aspectos legales de la aplicación (la seguridad para que no haya trabajos ilegales)
• Comentar el posible uso de la gamificación y elementos extra para evitar el problema del puente de usuarios.
• Indicar los perfiles de los usuarios piloto.
• Comentar cuando un compañero no está cumpliendo el agreement, sus horas o sus responsabilidades de trabajo. Hacer esto de forma anónima, no colocar “Pepito no ha cumplido” sino un “El miembro 7 no ha cumplido”.

Respecto a los mockups:

• Aumentar su tamaño
• Controlar el idioma: o en español, o inglés, pero ambos mezclados no.

Respecto al commitment agreement:

• No usar la palabra castigos: esa palabra debe desaparecer, es negativa. En su lugar, usar las palabras “recompensas” y “penalizaciones”. Ejemplos de penalizaciones sería trabajar más la semana siguiente para recuperar horas perdidas.
• Realizar análisis y monitorización del acuerdo para ver si se cumple. Básicamente revisar que se está cumpliendo.
• Ir evolucionando el acuerdo a lo largo del proyecto según se avanza. Es necesario tener archivadas las versiones anteriores del acuerdo.
• Actualizar el commitment agreement para que se indique que cada miembro es responsable de una tarea mínimo y que las tareas deben realizarse.

Respecto al proyecto en general:

• Cumplir al 100% lo que piden los profesores.
• El TCO se expresa por meses, no por años.
• Los precios y sueldos no se ponen por hora.
• Realizar un seguimiento de los riesgos y hablar de los que se han cubierto.
• Planificar y documentar soluciones a los posibles problemas por los aspectos legales de la aplicación (la seguridad para que no haya trabajos ilegales)
• Planificar y documentar soluciones al posible problema del “Puenteo”, por medio de medidas como la gamificación.
• Afinar más en cuál es el target de la aplicación: intentar ser más específico, buscar un target específico y ver las competencias que podemos implementar para ello.
• Usar usuarios pilotos reales y definir sus perfiles.
• Intentar ser originales a la hora de trabajar en el proyecto: si puede ser evitar al máximo el uso de la IA. Hacer las cosas de cero siempre que sea posible.
• Si algo funciona no cambiarlo: Debemos tener lo mismo pero ir añadiendo las cosas que se piden, manteniendo lo antiguo. Y arreglar lo que no estuviese bien.

Semana 3: 20 de febrero

FEEDBACK.

• Quitar índice o dejarlo pero no explicarlo. Ocupa mucho tiempo del que no disponemos.
• A veces los colores no los ponemos bien, es decir: fondo blanco y letras grises claras. Debemos revisar eso. Los colores no deben dificultar el visionado de los textos.
• Han mencionado algo sobre unas flechas que no están bien puestas en alguna diapositiva.
• Usamos demasiada iconografía sin texto. Aunque es bueno usar imágenes de apoyo, deberíamos ponerle algo de texto debajo para que sirva. Apoyar el apoyo visual con pequeños textos como en los logos en la parte de riesgos.
• Nos hemos quedado demasiado tiempo en alguna diapositiva (la del dafo o la del Índice).
• El presentador no debe decirle a un compañero que pase de diapositiva, es mejor que use el mando.
• Tenemos puesto que el dafo es un grafo y no es así.
• El DAFO no es eficiente, no tiene soporte visual. Nos ha vuelto a pasar lo mismo que el MVP. Quizás deberíamos haber dividido esto también o quizás que el presentador hable menos. Otra opción es darle un mando al presentador para que no espere a que un compañero pase la diapositiva. El grupo tiene la impresión de que esto hace que se quede mucho parado en la mismo diapositiva.
• La competencia (mejorar esa diapositiva, añadir soporte visual después de la tabla, otra diapositiva, etc)
• El análisis de riesgos y el ROI no son efectivos (color y demás). No se ven bien los costes por los colores escogidos en los cubos más oscuros. En concreto el cubo azul
• Pone autoevaulacion y es autoevaluación. Estar atento a posibles faltas de ortografía.
• Para el ROI podemos usar una gráfica que traslade esos datos y así se pueda ver mejor. Y así ver a partir de qué punto es rentable.
• Las letras a veces no se ven y no se entienden algunas diapositivas, la legibilidad es importante.
• Se ha echado en falta el usuario piloto: debíamos tener la planificación de cuando van a hacer las pruebas.
• No tenemos la visión del próximo sprint
• La profesora dice que no se le entiende mucho al hablar, puede ser porque el presentador va muy rápido y por el acento. Es recomendable que el presentador se relaje un poco.
• Tener cuidado con los textos pequeños y las imágenes que no sirven de apoyo visual, algunas solo entorpecen

FEEDBACK DE OTROS GRUPOS QUE NOS SIRVE

• En los usuarios potenciales debemos apuntar si estamos en contacto con ellos o no.
• Documentación como código. Debe estar versionado. Quieren ver una rama que se llame doc y se vea ramificado (por nombre, documento, etc).
• Que exista y cuando se suba el PTT que todos estemos cuando se practique la presentación y todos demos un feedback. Debemos revestirlo y que haya una pull request para que todo el mundo le de el OKEY.
• Básicamente que TODOS revisemos la presentación y le demos el visto bueno para subirlo.
• Idea de poner algún sitio para colocar las quejas y así podemos ver la retrospectiva semanal y solucionar problemas.

FEEDBACK FINAL

• Cuando se usa github actions hay que poner captura de la estimación.
• Poner una tabla para los agreement y con ello ver si se ha cumplido o no (rojo o verde)
• DOCUMENTACIÓN COMO CÓDIGO (versionado, ramificación y desarrollo) .
• Los usuarios potenciales: transparencia de ellos con su estado con ellos, si hemos contactado ya, estamos en espera, lo que sea, debe estar.
• Indicar si hemos ensayado esta diapositiva con todo el grupo o no.
• Transparencia simple de autodefensa: como hemos percibido nuestra presentación. Al final debemos decir que hemos cubierto el X% de lo que hemos cubierto respecto a lo que se ha pedido.
• Grabación y pasar transcripción a chat gpt
• Reducimos PRESENTACIÓN A 15 MINUTOS!!!
• Empezar a hacer los otros grupos de cuando tendrán el software para informar. Debemos tener el plan YA para ello. Cuando se prueba, cuánto tiempo tendremos y definir los pasos que deben realizar para probar la aplicación
• Debemos preparar un formulario para los usuarios pilotos y que nos genere un excel con los resultados. Pasarán Doc con info para enviar formularios a los usuarios pilotos Que esperan ver la próxima presentación:
• Será una presentación de avance del proyecto. Presentación más técnica aunque incluye una parte inicial que corresponde a la DP - DEADLINE
• Un 15-20% de resumen de lo que hemos hecho hasta ahora: modelo de negocio, killer opener, elevator pitch, análisis de competidor y en qué nos diferenciamos; costes, resumen del equipo, responsabilidades, estado del commitment agreement y cumplimiento.
• Un 15% del prototipo se desarrolló en ese momento. Es decir, la mitad del sprint uno. Queremos ver que llevamos ya desarrollado.
• Lo más importante 40-45% es:
  • la retrospectiva de esa primera semana
  • nuestra metodología
  • análisis de la calidad
  • rendimiento de todos los miembros del equipo en función al rol y cómo lo hacemos. Transparencia de todo el mundo comparado, no hace falta exponer nombres y con ello se pueden sacar cosas.
  • Problemas encontrados, que riesgos se han vuelto reales y hablar de qué solución hemos puesto. Medirlo y ver si es suficiente.
  • Lecciones aprendidas: hablar de cómo hemos ido solucionando los problemas.
  • reloj de avance del proyecto, gráfica de clocki, cuantas horas teníamos hechas respecto a las que esperábamos, etc.
  • Poner la gráfica circular de proyecto (tareas y tal) como de los usuarios (nosotros). Debemos añadir los link perdurables de lo que se ha trabajado. Hay que hacerlo todas las semanas. ES OBLIGATORIO.
• Un 15-20% planificación y replanificación por si hay margen de maniobra.
  • Definir claramente objetivos del siguiente sprint!! Cómo afecta eso a la planificación global
• Un 10% de gestion de usuarios piloto, como va la comunicación, formularios enviados?? hasta cuando pueden responder
• Report de IA.

Semana 4: 27 de febrero

Respecto a la forma de presentar:

• Buen ritmo al presentar, pero sigue siendo algo rápido
• No usar frecuentemente muletillas como “a grandes rasgos”
• Nunca hacer referencia a presentaciones anteriores.

Respecto a la presentación:

• En la sección de competencia faltan posibles competidores como Fiver o Freelancer
• Hay que usar el orden de presentación recomendado por los profesores.
• Se ha usado demasiado tiempo de presentación en el DAFO y la parte de planning del proyecto, haciendo que haya menos tiempo para exponer la parte del Sprint en desarrollo.
• Hay que mostrar el análisis de riesgos.
• El elevator Pitch debe estar en las diapositivas.
• Ser eficientes como equipo y colaborar todos en preparar la presentación.
• El Sprint es lo importante a hablar en la presentación.

Respecto al proyecto:

• Definir de forma clara qué tareas y partes de la aplicación hay que realizar en cada Sprint
• Definir las tareas CORE: lo más esencial, la oferta-demanda de trabajos, cosas como el Login son secundarias. Lo más importante es que el demandante pueda ver un listado de trabajadores y escoger.
• Los Riesgos hay que registrarlos como en la píldora teórica.
• Hace falta tener el elevator pitch.
• El ROI es excesivamente elevado, hay que revisarlo y ver donde se puede reducir costes.
• El Elevator Pitch consiste en intentar vender el producto en 40 segundos o 1 minuto.
• Hay que indicar en qué consiste cada tarea, no cosas “generales”. Ser mas detallados en el clockify.
• En el MVP hay que centrarse en el caso de uso core, el cual ha de priorizarse frente al resto.

Respecto al commitment agreement:

• El rendimiento del equipo debe estar desacoplado de la gestión de tiempo.
• El objetivo del Commitment Agreement es tratar de ver si se han realizado las tareas, no el tiempo invertido en el proyecto.
• Indicar los responsables de cada tarea.
• Indicar si alguien no aspira a una nota de 10.
• Reflejar la variación de rendimiento frente a la semana anterior.

Respecto a los costes:

• TCO: su objetivo es que una vez calculado el coste mensual por N usuarios, estimar y/o plantear la situación de cómo aumentaría con un aumento del número de usuarios.
• Analizar qué licencia de Github Actions es la que usamos en el proyecto.
• En el resumen del TCO se deben ver el gasto en licencias.
• También se debe reflejar cuánto dinero se lleva gastado.
• Hay que realizar estimaciones de gastos-ingresos a corto y medio plazo (pesimistas, optimistas y realistas)

Feedback de otros grupos que nos sirve:

NextONG:

• El análisis de competidores debe ser un resumen con lo más importante (pero debe estar en las diapositivas)
• Es responsabilidad de todo el grupo la presentación
• Lo interesante en el MVP es que se le ofrece al cliente para que prefiera nuestra aplicación frente a otras.

Ocial:

• En el análisis de competidores centrarse en las características “Killer”
• No está el github actions en las diapositivas: hay que ponerlo
• Hay que meter dramatización en los killer opener.

Cohabify:

• Buena estructura de Sprint
• Interesante poner las estadísticas de desarrollo
• Buena forma de explicar el rendimiento del equipo
• Priorizar tareas y comunicación fluida: no posponer tareas para el fin de semana.
• Indicar que tarea se planea hacer en cada Sprint
• Buena Landing Page.
• Hay que explicar todas las categorías de usuarios pilotos (no vale poner “otros”)
• Planificación de cómo se va a gestionar usuarios piloto.
• La gráfica Burndown está bien y un pseudodiagrama de gant para priorizar tareas también.
• Considerar las ventajas e inconvenientes de una demo grabada vs una demo en directo Ejemplo: https://www.youtube.com/watch?v=nkugQT7m0Qk

ITalent:

• Buena idea poner la metodología de trabajo en las diapositivas
• Poner un código QR que te lleva a la landing page en las diapositivas.
• Buena gráfica de análisis de rendimiento.

Musclemate:

• Calendario NikoNiko -> Si se hace debe de presentarse.
• El trabajo es de todo el grupo: quitar presión a los presentadores y disfrutar más de la presentación en sí.
• Hablar de reconocimiento: reconocer que se ha hecho bien e incluso podría ser buena idea hacer un “Podium” con los miembros que mejor han trabajado.
• Hay que proponer soluciones a los posibles problemas.

Feedback Semana 5 - 05 de marzo

Grupo 6 CiaoLavoro

Respecto a la forma de presentar:

• Nunca hacer referencia a presentaciones anteriores.
• Se ha mejorado el ritmo de presentación.
• Cuando se habla del Codacy, no se mencionan como ISSUES sino como errores del código.
• Killer opener muy original y memorable.

Respecto a la presentación:

• El modelo de competidores es bueno.
• No se ven bien los números de las gráficas, ni las gráficas (usar colores que se vean bien de lejos como Rojo o Negro, no azul clarito).
• En las gráficas hay que indicar qué representa cada color de la gráfica.
• No se pueden poner gráficas lineales: no son realistas.
• Las gráficas deben usar líneas más gruesas.
• No usar títulos en español o en inglés: ponerlos todos en un mismo idioma.
• Usar el Clockify y sus gráficas autogeneradas para el análisis de tiempo individual.
• Los usuarios piloto hay que indicar en qué estado están (contactados, pendientes de contestación, etc.).
• En los problemas hay que indicar los puntos a mejorar, políticas a seguir y el efecto de las mejoras aplicadas.
• El apoyo visual debe ser coherente con lo que se dice (en términos de porcentajes y números, el problema de la diapositiva del ROI fue este).
• El reporte de IA debe ir en las diapositivas al final, justo delante de la diapositiva que contiene la Landing Page.
• Hay que poner sí o sí en las diapositivas la estructura del equipo (qué hace cada miembro), haya cambiado o no.

Respecto al proyecto:

• El mal reparto de horas no es un problema, es el efecto de una mala planificación (el verdadero problema). efecto =! problema.
• Objetivos/Soluciones de mejora que se pretenden alcanzar, cómo las vamos a medir, hay que aplicarlo al proyecto.
• Hay que mejorar la visibilidad de la aplicación (mejorando los colores del fondo, por ejemplo) y de la presentación.

Respecto al commitment agreement:

• El rendimiento se debe medir más allá de las horas consumidas en el proyecto. Hay que tener en cuenta más elementos, como las tareas que realiza cada uno.

Respecto a los costes:

• TCO: Es el coste de operación y capital, entran todos los costes (incluido marketing). “Coste Total” no existe, es el TCO.
• Hay que mejorar el análisis de costes.

Respecto a la documentación:

• Hay que aprovechar más los repositorios.
• Usar documentación como código: meter la documentación en una carpeta llamada “docs” dentro del proyecto principal de GitHub, creando su propia rama desde donde editar los documentos en formato Markdown.
• Los documentos deben tener sus issues asociadas.

Respecto a GitHub:

• Editar el readme para que haga esas cosas que propuso el profesor (que salgan los perfiles de los colaboradores, etc).
• Es una carta de presentación. Hay que usar correctamente las issues, realizando la comunicación profesional entre compañeros a través del chat implementado en las issues.
• Hay que mirar en qué clase de licencia vamos a situar nuestra documentación.
• En los commits hay que poner algo identificativo para su posterior búsqueda (en resumen, que sigamos usando los patrones establecidos en el documento de gestión de la configuración).

Respecto a los entregables:

• A partir de ahora los entregables van a ser un enlace al repositorio (el cual debe de tener toda la documentación). Ya no se podrá añadir documentos al entregable, todo va en el repositorio.
• Se van a pedir hacer releases con etiquetas.

Respecto al Clockify:

• Las píldoras teóricas deben ser una tarea cronometrada en el Clockify con su propia categoría. (recordatorio, en Clockify la tenemos dentro de proyecto cómo “Theory Pills”, y en el documento gestión de la configuración se explica cómo gestionar el trabajo en Clockify)

Feedback de otros grupos que nos viene bien:

Musclemate

• Realizar una demo en video es una gran idea, deberíamos de hacerlo nosotros también.
• Cuestionario de retrospectiva anónimo para todos los miembros del equipo, para comprobar su grado de satisfacción.
• Hay que poner la estructura del equipo sí o sí, haya cambiado o no.
• En las Issues debe de haber una explicación completa.
• Las conversaciones para aclarar una Issue deben estar en GitHub, no en Discord u otros medios.
• Usar un calendario Niko-Niko es una buena idea que podemos replicar.

NextONG

• Una buena tabla de rendimiento.
• Hay que añadir según los profesores el GitHub Actions en las diapositivas e indicar para qué sirve.
• Las cifras deben ser aproximadas, no exactas.
• Tienen una buena fórmula de rendimiento.
• Hay que explicar a los miembros del grupo sus notas de rendimiento: el cómo se calculan o por qué tienen esa nota.
• Debemos mejorar nuestro análisis de calidad, implementando la matriz RACI de forma correcta (es para reflexionar sobre nuestro GitHub).

Ocial

• El número de las diapositivas de Ocial no se ve porque está situado justo debajo: debemos seguir como hasta ahora, situando los números de las diapositivas arriba.
• En el análisis de coste hay que incluir el coste de GitHub.
• Tienen buenas gráficas para la evaluación del rendimiento del equipo.
• IMPORTANTE: tienen un calendario de disponibilidad por semana, esto es muy buena idea porque permite ver la carga de trabajo y disponibilidad de cada miembro del proyecto.
• Su prototipo ha fallado en directo: por eso es mejor plantear la idea de grabar un vídeo donde se muestre el uso de la aplicación.
• Tienen muy bien planteada la gráfica del TCO (eso sí, las estimaciones deben de ser por mes, no por año).
• Sacar más partido a GitHub.

Cohabify

• No han hecho anónimo los análisis de rendimiento en la presentación: es muy mala práctica. Es mejor exponerlos de forma anónima y luego únicamente destacar y poner sin ser anónimos a los “mejores”.
• Deberíamos tener una tabla Niko-Niko.
• Establecer fechas límite para las tareas.
• Un calendario de disponibilidad de los miembros del equipo es una buena idea.
• Establecer y usar fórmulas para calcular el rendimiento individual y del equipo. Debería de incluir alguna variación respecto al rol del miembro del equipo.
• Estimación de los usuarios bien hecha en las diapositivas.
• Si se hace demo en video, precargar los formularios.
• Usar Pixel Cart para mejorar la calidad de las imágenes.
• El TCO lo tienen muy bien hecho, deberíamos aprender del suyo.
• Hacer un pseudogant para la planificación de los sprints, con sus colores y demás, es una buena idea.

ITalent

• De nuevo, los roles deben estar en las diapositivas sí o sí.
• Mejor mostrar la aplicación por medio de un vídeo: en directo puede fallar.
• Hacer zoom en el prototipo/cuando se muestra la aplicación es buena idea.
• Para las presentaciones, usan un proceso que nos vendría bien a nosotros: primero miran el feedback, luego preparan un guión y después hacen la presentación.
• Deberíamos añadir nosotros el uso de Codacy, SLint, y demás para el análisis de calidad del código.

FEEDBACK Semana 6 RETROSPECTIVA 12 / 03 / 2024

DIAPOSITIVAS

• El "Diagrama UML" no se debe de llamar así, un nombre más correcto es "Diagrama de diseño" o "Análisis de clases".
• La tabla de retrospectiva esta muy bien hecha.
• En el análisis de calidad, la línea no debe ser recta. Debe de incluir altibajos debido a que los fin de semana no se trabaja en teoría, igual que los días festivos (semana santa y feria)
• Decir mala estimación o problemas de recursos humanos.
• La presentación debe de comenzar a elaborarse desde el primer dia del proyecto, y se le va añadiendo el contenido a lo largo del avance del proyecto. Se debe de seguir una metodología agil. El primer dia de la semana de trabajo se elabora un esqueleto de la presentación y se añade contenido a lo largo de la semana.
• La desaparición de miembros debemos llamarlo falta de proactividad. Meterlo en la métrica de rendimiento para asignar los puntos.
• En las diapositivas, el esfuerzo en horas grupal NO debe de llamarse rendimiento grupal. Debe de llamarse esfuerzo en horas grupal.

PROYECTO

• Los fin de semana no son laborables. No se trabaja ni los fin de semana ni los festivos.

• Mal uso de las tipeline. Entre paréntesis se pone DOCREADME. No se pone el tipo entre paréntesis.

• Al tener tanto tiempo trabajado en el S1. Debemos reducir el alcance, valorar si vamos a llegar o no y replanificar, para ello es interesante verse la TEORY PILL de replanificaciones.

• Las tareas de ayuda deben estar en el rendimiento para que lo mejore.

• Incluir las cosas que veamos en los videos de las theory pills en la documentación como código.

• Tener en cuenta que el project manager debe tener una métrica diferente. Y tener en cuenta que todo el tiempo que esta pendiente de todo no lo tiene en código pero porque es su rol.

• Poner solo el prompt en el documento de IA Prompts, luego pasar el enlace correspondiente.

• Hay que hacer un Commitment Agreement para los pilot users. Siempre tiene un estado y una version. Si hay 4 usuarios pilot, hay 4 versiones.

• Usar versionado semántico.

• En github una issue puede tener varias issues asociadas.

• Recordar en el discussion guide el uso de ASPOSE.

UTIMO RETROSPECTIVE

• Perfil de github: commits, issues, hacer tarjeta de presentación de cada uno.

• Clockify con desglose TOTAL de cada uno.

• Tener en cuenta el numero de tareas que tiene cada uno para las métricas.

• Averiguar la huella de carbono que estamos usando.

FEEDBACK Semana 7 19 / 03 / 2024

DIAPOSITIVAS

• Mejorar la ortografía en diapositivas.
• Añadir antes del ROI y TCO los planes de precio (suscripciones y contratos).
• Hacer zoom a las gráficas para que se vean mejor (Análisis de Calidad, Diapositiva 31), señalar en un color más llamativo (rojo) las partes relevantes. El objetivo no es que se vea la leyenda, sino que se entienda la línea.
• Considerar reducir el número de diapositivas.
• Muy buen Storyboard, gracioso y llamativo, seguir así.
• El nombre de la diapositiva de Elevator Pitch debe ser Elevator Pitch (No se debe traducir).
• Mejorar nuestro elevator pitch de forma que incentive a invertir en nuestro producto.
• Se debe representar los costes de github actions y codacy. Hay que mencionarlos.
• Al hablar sobre el presupuesto , este se ejecuta, no se gasta (decir esto último es incorrecto). Lo que se gasta es el dinero.
• El markdown del análisis de calidad no se ve bien. Hay que poner un zoom en la parte más relevante de la gráfica.
• Hay que representar de forma clara las mejoras respecto a la semana anterior.
• El TCO se debe usar y representar a 2 años.
• Hacer el calendario Niko-Niko más visible.
• Ilustrar mejor la furgoneta de Competencias en la diapositiva 2.
• Hacer un segundo storyboard que represente un segundo caso de uso.
• El report de la IA debe ir al final de las diapositivas, y después de esa la diapositiva con la URL de la Landing Page.

PRESENTACIÓN

• Hay que dar coherencia a la presentación de la demo respecto a los Storyboards. Esto consiste en usar la demo para mostrar a los usuarios de la storyboard interactuando. En nuestro caso, sería ver la interacción entre Perico y Bufandasio.
• Mejorar la vocalización.
• Hacer Zoom en la demo.
• Somos un equipo, si algún miembro está cansado y no puede presentar, debemos tener miembros preparados para presentar también.

APLICACIÓN

• Poner datos realistas en la base de datos.
• Cambiar los títulos de las vistas (Mis Contratos).
• Valorar la posibilidad de filtrar por Idioma en los servicios.
• Mejorar la página de home, situando un listado de “trabajos destacados” en la página de inicio.

PROYECTO

• Comprobar si hay alguna forma de verificar que se cumpla la gestión de la configuración
• Asociar el Costumer Agreement al desarrollo del servicio. Contrato de uso o alquiler de servicios como los servicios en la nube.
• Tener en cuenta el impacto legal del proyecto (el usuario al registrarse debe aceptar los términos legales de uso y la política de protección de datos, las cuales debemos elaborar evitando políticas abusivas).
• Acuerdo de compromiso interno entre los miembros del equipo.
• Acuerdo de usuarios piloto.
• Implementar una API que valide que los correos usados para registrarse sean reales.

Feedback Semana 8 - 5 de abril

Sobre la presentación:

• Es mejor reducir el ritmo de presentación para que se entienda todo mejor
• Mejorar la visibilidad de la demo
• Encontrar un punto intermedio entre presentar de forma estática y la sobreactividad durante la presentación.
• Hay que evolucionar y enlazar el killer opener con la aplicación.
• Transmitir energía y seguridad

Sobre las diapositivas:

• La diapositiva de los beneficios en la sección de costes se puede unir en una única diapositiva, esto también es aplicable a la gráfica de horas del equipo.
• Mostrar los protocolos de codacy en capturas en vivo es muy buena idea, seguir con ello.
• Añadir más información en la diapositiva sobre el uso de la IA
• Muy buen Storyboard, seguir con los storyboards originales cuando se requieran
• Realizar menos transparencias de cada punto: intentar unificar diapositivas
• Para representar los problemas usar una tabla en lugar de imágenes

Sobre el proyecto:

• Se recomienda realizar una matriz de esfuerzo y horas del equipo para saber el rendimiento obtenido
• Una vez iniciada sesión en la aplicación, que no se vea la descripción de la aplicación sino los usuarios destacados.
• Hay que intentar ser menos optimista en la gráfica de la estimación optimista de beneficios.
• Analizar Webel, potencial nuevo competidor

Feedback Semana 9 - 9 de abril

Pensamientos del grupo

• Muy buen ritmo
• Deberiamos añadir más profesiones a la aplicación para mostrar que tenemos servicios polifacéticos
• El cartel de "Promoción" debe de ser mejorado

Sobre la forma de presentar

• Al presentar más relajado queda todo muchísimo mas claro.
• Evitar muletillas que pueden entenderse como algo negativo, como "no quita que". Buscar otra frase para hacer de nexo entre trasparencias.
• Eliminar el efecto de movimiento al pasar las diapositivas, puede causar mareos.

Sobre la presentación

• Buen uso de los memes en las diapositivas, ha quedado como un pequeño detalle gracioso en la presentación y bastante creativo.
• No usar IA para las fotos de los usuarios en la demo, usar datos más realistas.
• Antes de presentar la demo hay que contar que parte de la demo vamos a tratar.
• En la demo hacer una historia donde Perico la usa.
• Mejorar la diapositiva del apartado de pruebas, menos texto y más visual.
• La parte de problemas, usuarios piloto y plan se han quedado cortas y se ha destinado demasiado tiempo a la retrospectiva. Mejorar haciendo más corta la retrospectiva para dedicar más tiempo a los apartados que se han quedado cortos.
• La gráfica de la diapositiva 12 no se ve bien, son números demasiado largos. Escalarlos al estilo monopoly (usando K y M)
• La gráfica de la diapositiva 24 debe ser acumulativa, que se vea el To Do, In Progress, In review y Done.

Sobre el Killer Opener

• Está genial usar a Perico en el Killer Opener, pero la próxima vez en lugar de ponerlo tomándose unas vacaciones, es mejor ponerlo en algún trabajo nuevo (por ejemplo, si se acerca el verano, ponerlo de socorrista, o si se acerca la feria, ponerlo trabajando ahí)

Sobre el anuncio

• Abarcar más trabajos para mostrar que son servicios polifacéticos.

Sobre la publicidad

• Revisar los servicios más demandados y usarlos para la publicidad. También deben de ser añadidos a la aplicación.

Sobre la resolución de problemas

• Problema-Solución. ¿Cómo se mide? ¿Estamos llegando al objetivo?, debemos tener en cuenta esas preguntas a la hora de desarrollarlo.

Elementos a tener en la presentación para la próxima semana

• introducción, modelo de negocio
• killer opener
• elevator pitch
• resumen analisis competidores
• anuncio nuevo
• customer agreement (terminos servicios, claudette, explicar qué hacemos para arreglarlo)
• pricing customer agreement
• SLA
• tareas de marketing preliminar (nada muy desarrollado, qué acciones podemos hacer para ganar tracción, conseguir clientes, quizás segmentar el mercado, redes sociales, anuncios…) ROL DE COMMUNITY MANAGER
• resumen TCO (tener en cuenta una persona que sea el GDPR Officer y el Community Manager)
• refinar la distribución del equipo con lo anterior
• Commitment agreement (estado)
• Demo Sprint 3 completo siguiendo una historieta realista (poner a Perico, poner el usuario que esta usando la aplicacion)
• destacar mejoras en UX en la demo
• http y derecho al olvido (un formulario para que el usuario diga que quiera borrar sus datos)
• términos y condiciones
• retrospectiva
• gestión usuarios piloto
• planificacion PPL
• uso de IA
• diapositiva Final.

Feedback Semana 10 - 23 de abril

Pensamientos del grupo

• Buen Killer Opener.

Feedback de los compañeros

Positivo

• Nuestro Anuncio ha sido claro y corto
• Bien implementada la gamificación
• La presentación perfecta
• Issues (se ha hecho muy bien el tema de darles prioridad a las issues)
• Plantillas (las plantillas están muy bien, bastante completas)
• Está muy bien el caso de uso de la demo.

Recomendaciones

• Poner en la Demo algo para que ayude a seguir el hilo.

Feedback de los profesores

Riesgos y resolución de conflictos

• Tener métricas y umbrales para medir si solucionamos los problemas y tener fechas. ES IMPORTANTE. IMPLICA SUSPENSO.

Sobre la presentación

• Presentación clara y con buena dinámica.
• Visualmente clara
• Buena dinamica a la hora de presentar
• 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
• Faltó perico.

Costes

• ingreso y beneficio no es lo mismo. Ingreso es el dinero que se ingresa y beneficio cuando el dinero supera a los costes.
• Indicar el salario bruto por hora.

Problema de la clausula abusiva

• Reestructurar esa cláusula poniendo el caso de clicar sobre él y si no lo clicamos.

Lecciones aprendidas del feedback a otros grupos:

• Buenisima idea mostrar en la demo el feedback recibido por la responsable de manos abiertas con norte. Aporta valor a la aplicación y muestra que estan en contacto con el cliente. (NextONG)
• Interesante abordamiento el marketing mix de 1 producto 2 precio 3 distribución 4 comunicación (Musclemate)
• La tabla de problemas está muy bien porque incluye el cómo lo miden, cosa que aún no ha hecho ningún grupo que ha presentado hasta ahora. (Musclemate)
• El anuncio está muy bien, sobretodo porque han tenido el feedback en cuenta de los profesores y han hecho referencia a nosotros (Musclemate)
• Diapositivas muy limpias y fáciles de entender (OCIAL)
• No repasar la GPDR completa, solo indicar las acciones concretas que hayan tomado (ITalent)
• En los riesgos ha faltado acciones, umbrales y formas de medida para los problemas que se encuentran. (ITalent)
• Poner un término sancionador si el otro equipo no cumple el CA y no hace de usuario piloto. (ITalent)
• No subir a youtube los anuncios o demos, puede dar muchos problemas. (Cohabify)
• Mucho texto en las presentaciones. Recortar. La presentación es un apoyo visual a lo que se presenta. No son notas para prácticamente leer. (Cohabify)
• Tener métricas y umbrales para medir si solucionamos los problemas y tener fechas. ES IMPORTANTE. IMPLICA SUSPENSO.

Feedback semana 11 ‐ 30 de Abril de 2024

Pensamientos del grupo

• Buen Killer Opener.
• Muy buena demo, pero se oye regular.
• Es necesario llevar un altavoz para la proxima presentación

Feedback de los compañeros

Positivo

• La actuación de la demo les ha llamado la atención, les ha parecido más facil seguir la presentación.

Recomendaciones

• La broma de Bob Esponja una vez hace gracia, repetidamente se hace pesada.
• Poner subtítulos podría ser una buena idea para ayudar a seguir el hilo de la demo.
• Intentar que el audio se oiga mejor.

Feedback de los profesores

Sobre la presentación

• Se nota el esfuerzo en tener un ritmo distinto y una mejor vocalización.
• La presentación ha estado muy bien.
• Se notaba que el presentador se contenía al principio porque miraba el suelo: intentar no mirar el suelo.
• Al nivel visual estaba bien pero hay un cambio visual entre la tipografía del equipo y sus powerpoint con el resto de la presentación, y letras muy grandes. Intentar conseguir uniformidad si es posible. Por ejemplo con los colores, cambiamos continuamente de colores.
• Algunas partes de la presentación son super genéricas y evidentes. Intentar revisar la presentación para revisar y cambiar las partes genéricas por contenido más específico de nuestro proyecto, dando razones objetivas más allá de “somos muy buenos, los mejores”. Analizar cada frase para ver si es genérica o no, y si no lo es, introducir las razones del por qué. Esto afecta también a las diapositivas de costes, habría que indicar el criterio usado y especificar el momento y el por qué de cuando empieza a ser rentable.
• Prestar atención a las frases, cosas tipo “eso es lo que pretendemos hacer” no da seguridad al público, usar frases tipo “esto es lo que vamos a hacer”, cambiarlas para darles más seguridad al público. No decir intenciones si no Hechos. Dar seguridad de lo que hablamos.
• 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 más homogénea. No dedicar tantas diapositivas para el equipo: poner a todo el equipo, y dejar de mostrarlo como tres equipos.
• Hay que identificar y mostrar en la presentación dos personas, especificando motivaciones de usar la app, objetivos que quieren conseguir, etc. - Market segmentation-

Sobre la demo

• Está bien en el video demostración pero hay que hacerlo menos enfocado a hacer una película. Hay que intentar conseguir un equilibrio y debería durar 2 minutos como MAXIMO. Debe apuntar a las cosas claves de la aplicación. No se oía nada del video tampoco, recomendable llevar un altavoz.
• La demo debe de centrarse más en las funcionalidades.

Lecciones aprendidas del feedback a otros grupos:

• Anuncio para inversiores de 1 minuto máximo (NextONG)
• Como ingenieros de software, hay que tener cuidado de cómo nos autodefinimos. Frontend-Programmer NO es apto. Como mínimo poner frontend engineer (NextONG)

Feedback semana 12 ‐ 7 de Mayo de 2024

Pensamientos del grupo

• A veces se usan coletillas al hablar. Intentar reducir el uso de coletillas.

Feedback compañeros:

• Nos han aplaudido el anuncio de cliente
• Muy buenos videos, muy graciosos
• Está bien saber que clase de marketing nos resulta más efectivo

Feedback profesores

Sobre la presentación

• El inicio efectivo no ha funcionado. Hay que mejorarlo.
• El elevator pitch/matchmaking o cosas con vocabulario de ispp son términos difíciles de entender. Esta clase de conceptos no deberían de ponerse a nivel específico con el término.
• El elevator pitch no funciona, dice que no tiene potencial: es una frase que en 15 sg explica el potencial de la app, para venderlo.
• La Demo tenemos que reducir la parte de la valoración, quitarla. Hay saltos que no se entienden. Quizás añadir una escena en la que la persona realice el servicio, para separarlo y que se entienda mejor
• Mejorar el sonido. (Aunque es un problema del aula)
• El video de inversores lo pondría después del estudio de viabilidad. Y materializamos en el video las conclusiones del estudio. Invertimos demasiado tiempo en transparencias de costes Dejar la transparencia detallada de los costes al final de la presentación.
• No es necesario la trasparencia con los sueldos.
• Sobra el reconocimiento del trabajo del equipo, quitarlo.
• Ordenar mejor el hilo argumental, parece que estamos metiendo con calzador los videos, muy abrupto

Lecciones aprendidas de las presentaciones de otros grupos

OCIAL

• Está muy bien eso de que pongan antes de la demo las fotos de quienes van a ser los usuarios. Y que se va a hacer en la demo.
• La parte de gastos está bien explicada, queda bien que vayan poniendo los cuadrados con las información dentro, está esquematizado.
• Bien explicado el tema de los escenarios pesimista, optimista y realista, sacando los datos de usuarios de fuentes reales y contrastadas. (periódicos, medios deportivos, portales del gobierno…).
• Muy buen anuncio de inversores, poniendo un ejemplo real y además poniendo los % y lo que ganaran según inviertan

Musclemate

• La demo y el anuncio se centran en los aspectos principales de la aplicación, sin repetir funcionalidades en una y otra. Han hecho una demo rapida, centrandose en lo principal que los diferencia.

*ITalent

• Tienen un buen Elevator Pitch porque venden bien la app, dice lo que hacen en poco tiempo

Cohabify

• Ponen palabras que toda persona que no haya cursado ISPP va a entender.