Grupo B - Cerebrus

En esta página se encuentra el feedback recogido por el grupo B - Cerebrus durante el curso. Este feedback incluye comentarios, sugerencias y recomendaciones proporcionados por el profesor para mejorar el desempeño del grupo en futuras actividades y proyectos.

Última actualización: 27 de marzo

1. Definición de Producto

• Prioridad en Actividades: El núcleo diferenciador son las actividades y las estadísticas . El Sprint 1 debe terminar con una funcionalidad real en estas áreas para poder mostrar valor inmediato a los usuarios piloto.
• Justificación de Pago: No basta con decir qué hace la app; hay que detallar por qué un colegio o tienda pagaría por ella. Se deben aportar razones de peso y detalles minuciosos.
• Segmentación de Mercado: Es obligatorio definir si el enfoque es para centros públicos, privados o ambos. Se debe analizar la viabilidad económica real en centros públicos (riesgo de presupuesto).
• IA: Realizar un análisis riguroso: qué modelo se usará, plan de precios, riesgos y cómo se implementará técnicamente.

2. Análisis de Competidores y Riesgos

• Objetividad: Eliminar juicios subjetivos (ej. "no los conoce nadie"). La comparativa debe basarse en hechos y criterios técnicos/funcionales objetivos.
• Matriz de Comparación: Simplificar las tablas. Destacar los 3 o 4 criterios clave que demuestren nuestra ventaja competitiva.
• Riesgos Tecnológicos: Evaluar el despliegue considerando el tratamiento de datos de menores . Realizar despliegues pequeños de prueba de forma inmediata para mitigar problemas de curva de aprendizaje en el equipo.

3. Usuarios Piloto y Viabilidad

• Objetivo Cuantitativo: Alcanzar una lista de 10-12 usuarios piloto comprometidos (mínimo), idealmente más.
• Gestión de Pilotos: Se requiere un plan concreto: calendario de reuniones, registro de qué se les ha enseñado (mockups/demos) y feedback explícito sobre si estarían dispuestos a pagar.
• Diversidad de Perfiles: Al tener distintos roles (alumno, profesor, director), se deben buscar pilotos para cada categoría. El diseño para profesores/directores debe ser profesional y menos gamificado que el del alumno.
• Imporancia de la comunicación: Se requiere comunicación en vivo con ellos ya que la expresión corporal puede ayudarnos a recoger mejor feedback
• Importancia del proceso de recogida de feedback: Los usuarios piloto deben de tener muy claro cual es el proceso de recogida de feedback, y nosotros debemos de comunicarselo claramente.

4. Core Técnico y Estado del Desarrollo

Para la próxima presentación, estos puntos son de cumplimiento obligatorio :

• CI/CD Explicito: Detallar cómo se automatizará la integración y el despliegue en las 5 entregas.
• Stack y Despliegue: Claridad absoluta en las tecnologías y el entorno de hosting.
• Metodología: Explicar cómo se ha adaptado la metodología (ej. Scrum) a la realidad del grupo, sin entrar en definiciones teóricas.
• Planificación: Mostrar el estado del Sprint actual y si ha habido replanificaciones.

5. Presentación

• Formato de Diapositivas: Menos texto y más gráficos/metáforas visuales. Si hay párrafos, deben estar sincronizados con el discurso (leer textualmente para enfatizar).
• Killer Opener: La siguiente presentación debe iniciar con un gancho corto y potente que capte la atención desde el segundo uno. Debe de estar relacionado con el tema de exposición. Al presenta este debemos ser activos y alegres, transmitir emoción real.
• Dinámica: Mejorar la fluidez en los cambios de ponente y evitar ir demasiado rápido (gestión del tiempo).
• Imagen Corporativa: Mantener la estética, pero incluir eslogan y cuidar la visibilidad de los elementos clave.
• A nivel general seguir exponiendo como hasta ahora

6. Organización Interna y Compromiso

• Commitment Agreement: Mostrar de forma transparente las horas invertidas vs. estimadas por cada miembro. La desviación debe ser visible.
• Contribución al Código: Se reitera que todos los miembros (incluyendo responsables de marketing o documentación) deben realizar commits al repositorio.
• Cumplimiento del commitment agreement Es importante además de decir que contiene el acuerdo, cómo se está cumpliendo y cómo nos estamos asegurando de que se cumpla.

7. Notas de clase

Semana 1 (05/02)

Con respecto a la presentación:

• Tener cuidado con las letras pequeñas
• Añadir paginación
• Prepararse bien antes de realizar una presentación (problemas técnicos antes de la presentación)
• Orden de presentación de la información. Explicar mejor primero la idea y en que consiste y luego como mejorar al resto, o primero hablar del resto y luego lo nuestro. En nuestro caso hemos hablado de la idea, luego de competidores y luego otra vez de casos core.
• Antes de vender creernoslo, no se nos veía con mucha seguridad. Dominar los conceptos, ideas, casos core. Poder describirlo de forma breve.
• Positivo: Enfasis en imagen de marca y presentar al equipo del proyecto
• No se aprovechaba toda la pantalla para poder ver bien todo
• A medida que avanzaba la presentación surgían incognitas

Con respecto a la idea de la aplicación:

• Generar las actividades automáticamente con IA en vez de crearlas a mano el profesorado. Enlace con IA que nos puede mandar el profesor.
• Tener en cuenta la legislación por posibles problemas futuros al tener la posibilidad de ser una red social y poder comunicarse.
• Problema con la creación de las actividades: puede ser complicado crearlas.
• Definir un producto de forma muy afinada.
• Definir casos de uso core distintos claramente al resto. Próximo día presentar tabla de competidores muy exhausta y analizada en detalle, y diferenciarnos claramente del resto.
• Analizar todo lo que hay para que al empezar a trabajar en ello tener muchas posibilidades de que salga adelante.

Con respecto a los competidores:

• Análisis más profundo de los competidores
• Fundamental tomarse muy en serio el análisis de competidores.
• Hablar más en profundidad de las otras herramientas además de duolingo

Con respecto al público objetivo:

• ¿Quién paga? No se tiene muy claro el público objetivo (universidad? Primaria? Academias?) Dejar claro quien es el público objetivo para poder definir claramente los casos de uso core

Semana 2 (12/02)

A nivel general:

• Centrarnos en hacer demostraciones visuales que podamos enseñarle a un usuario piloto que convenza a este mismo a usarla y justifique nuestra diferenciación. Intentar buscar valor
• Mockups más concretos de los casos Core (obviar cosas como registro etc.)
• Profundizar en los que nos diferencian de la competencia, especificar muy bien esas funciones, lo que hay dentro. Centrarnos en las actividades.
• Cuidar imagen corporativa (meter eslogan)
• (1º sprint solo caso Core, por ejemplo, si registro no forma parte del Core no se hace, se les dan las contraseñas directamente, se lo dijo a otro grupo)
• (evitar vocabulario como plagio, mejor gestión del tiempo (Fernando ha ido muy rápido))
• Indicar estructura de grupo (como nos ordenamos internamente)

Con respecto a los competidores:

• Comparamos los competidores con cosas muy subjetivas deberíamos de ver desde puntos más objetivos y concretos. (No usar "no los conoce nadie" es subjetivo) Tenemos que poner hechos meramente objetivos. (en la tabla hemos puesto cosas medianamente)
• Valorar qué tipo de mecanismos tienen los competidores

Con respecto a las tecnologías:

• Identificar qué criterios seguir para decidir donde desplegar, porque es importante ver tratamiento de datos que hacen dichos entornos ya que almacenamos datos de menores.
• Profundizar en las tecnologías
• Elegir si vamos a usar login social o no (ya que es una barrera de entrada para los usuarios).
• Ver riesgos tecnológicos, hacer un despliegue chiquitito para ver que todo marcha bien. Porque en el sprint 1 debe de estar todo sí o sí. (Problemas de que alguno no sepa tecnología etc.)
• Análisis riguroso del uso de IA**, cual se va a implementar, como, plan de precios, riesgos de uso etc.
• Mencionar las herramientas de gestión de comunicación entre equipo y las herramientas de gestión de equipo (zenhub ...)

Con respecto a los usuarios piloto:

• Identificar más a fondo cual es nuestro nicho de mercado valorando si realmente es rentable desarrollar la aplicación para ese nicho. Para esto valorar el nº de colegios privados/concertados frene a públicos. Ver viabilidad
• Es importante que llevemos la idea a los colegios y que ellos nos de la aprobación en cuanto legalidad
• Hablar con los usuarios pilotos de nuestra idea y enseñándole nuestra idea de forma visual mostrando las cosas que nos diferencian frente a la competencia, y ver lo que les parece. Todo esto con el objetivo de ver si está dispuesto a pagar por nuestro producto o no. (para la siguiente presentación haber hablado ya con ellos de cosas concretas)
• Error pensar q director y alumno tiene la misma interfaz de usuario. Los profesores y el director tienen que verse menos gamificado, aprovechando mejor del espacio de la pantalla. El logo de la aplicación debe ser diferente para alumno y no alumno
• Estudiar nuestro tipo de cliente. ¿Existe manera de que los públicos puedan pagar esta suscripción?
• Tener una lista concreta con un plan concreto de usuarios piloto. (decenas de personas con compromiso a usar la app, min 10-12 preferible más) Definido calendarios de reuniones, de cómo y cuándo lo van a usar. (personas o empresas concretas a las que se les enseña los mockups)
• Como tenemos diferentes tipos de usuarios tenemos que buscar pilotos de todos los tipos

Semana 3 (19/02), evaluación

Obligatorio para la siguiente clase (26/02) :

• Foco diferente al actual, hay que enfocarse en cómo se está desarrollando el proyecto
• Stack tecnológico utilizando muy claro y explicitar como se van a desplegar las 5 entregas. TENER MUY CLARO EL CI/CD, DECIRLO EXPLÍCITAMENTE
• Que ALM estamos utilizando, (conjunto de pruebas).
• Análisis de los problemas que se han encontrado, lecciones aprendidas y plan de contingencia
• Listado de usuarios pilotos y plan para extenderlos y gestionarlos.
• Nuevo killer opener que capte la atención y corto.
• Mock-ups o demos de los casos de uso Core del final del sprint.
• Estado actual de la planificación del sprint y si ha habido que replanificar.
• Visión de muy alto nivel de la metodología de desarrollo que se está siguiendo. Diciendo explícitamente las adaptaciones de la metodología, por ejemplo, como adaptamos SCRUM o la que sea que usamos. No hace explicar que es SCRUM o que es la medotología agil

Con respecto a la presentación:

• Para que sirve el feedback: Para que te escuche el equipo y actúe en consecuencia. Para ello establecer una conexión con el equipo dando algo positivo y luego el equipo se puede mostrar más abierto a escuchar algo a mejorar.
• Les has gustado presentación. Estéticamente estaba bien (mantener)
• Matriz demasiado grande: simplificar a cuáles son los 3 o 4 criterios más importantes que han regulado nuestra comparativa
• No hablar tanto en una transparencia ni hacerlas con mucho texto el cual no apoyaba realmente lo expuesto. Mejor hacer más diapositivas con más imágenes y que sea una presentación más dinámica. (Por ejemplo, la diapositiva 5 es ejemplo de lo que no hay que hacer)
• Más gráficos y metáforas visuales (aunque hay que aumentar el número de imágenes, la imagen gráfica usada está bien en general)
• Si se redactan párrafos dentro de la presentación es para sincronizar el texto con lo que se dice. Es decir, decir algo así como: “... al igual que pone aquí ... (y leer el párrafo tal cual)”
• (no nos hemos adaptado al feedback en esta parte) Ha faltado mencionar si nos enfocamos en público y/o privado, y decir si nos parece factible o no para colegios públicos porque sea un riesgo. DEBE SER LA ULTIMA PRESENTACION DONDE ESTE TEMA NO ESTÉ
• Cuando ponemos los modelos de precio falta poner el intervalo de tiempo que se está pagando (por ejemplo 5€ al mes)
• Bien poner lo del commitment agrement, Pero para el futuro no poner cosas q sean difíciles de verificar, ya que, si no es difícil llevar seguimiento y encontrar pruebas de que se sigue.
• Profesor y alumno no aportan nada, hubiese estado mejor palabras clave del valor que aportan a uno y a otro.
• No hemos mostrado detalles de los casos diferenciales, debemos enseñarlo super en detalle.

Con respecto a los sprints:

• Preocupación sobre el foco del proyecto. Deberíamos de enfocarnos en el sprint 1 más en las actividades y las estadísticas (es decir, en el foco diferenciador). El objetivo es que cuando se acabe el sprint 1 podamos enseñarle al usuario algo con valor.
• Dar más detalle de los casos de uso core.
• Dar más detalle del uso de la IA y como se va a implementar.

Con respecto a los usuarios piloto:

• Análisis más robusto sobre si los usuarios están dispuestos a pagar o no.
• Pocos usuarios pilotos. Falta encontrar más y hacer un compromiso formal con ellos. Colocar esfuerzo en esto.
• Debemos de dar detalles concretos de aquello que nos diferencia del resto (por ejemplo, X hace esto, pero nosotros hacemos esto mejor)

Semana 4 (26/02)

Obligatorio para la siguiente clase (05/03) :

• Killer opener (fade/dissolve)
• Stack tecnológico
• Análisis de riesgos
• Proceso de despliegue
• Demo de casos de uso core
• Visión de alto nivel de la adaptación de Scrum realizada
• Visión de alto nivel del ALM (con CI/CD)
• Revisión del sprint 1: análisis de resultados frente a lo previsto, rendimiento del equipo y cómo se está midiendo dicho rendimiento
• Planificación del sprint 2: objetivo del sprint y si ha habido alguna replanificación
• Problemas encontrados y su estado (solucionado, en curso, etc.), medidas tomadas para resolverlos, plan de contingencia y métricas para verificar que las medidas están funcionando
• Listado de usuarios piloto, plan de expansión y mecanismo de recogida de feedback
• Análisis económico y ejecución presupuestaria
• Análisis competitivo: comparativa de alto nivel con competidores y diferenciadores clave
• Una o dos diapositivas sobre dedicación real frente a la estimada y grado de cumplimiento del commitment agreement.
• Presentación más atractiva y atrayente, había veces que costaba echar cuenta a la presentación

Con respecto a la presentación:

• Hablar más alto y controlar mejor el tiempo
• Killer opener más relacionado con el proyecto
• Se ve bien a nivel corporativo
• No poner tantas formas de señalar el avance. Quitar poorcentajes y secciones ya que sobrecarga mucho las diapositivas
• Mejorar la línea conductora de la presentación, empezar primero con idea princiàl y luego ir al detalle.
• Hilo conductor de las presentaciones demasiado mal hecho a nivel general. Debemos de pensar como tener varios bloques grandes temáticos y que cada uno responda a una pregunta, focalizando así los bloques. Ver, también, en que orden debería de aparecer esas preguntas para que otra persona lo entienda.
• Propuesta para hacer una actividad de team building

Con respecto al análisis económico

• En lo referente al coste de personal se debe de diferenciar entre: salario bruto, salario líquido y coste de contratación. Siendo coste de contratación lo que debemos de tener en cuenta a la hora de calcular el presupuesto.
• Hay que ver el coste de lo de construir y el coste de lo operación (son distintos).
• Ver diversos escenarios, ya que no es lo mismo dar soporte a 1000 usuarios q a 100000.
• Nuestra monetización es muy superficial. Ver a cuanto tiempo se prevee, poner horizonte temporal.
• Dar más detalle. Decir cuanto tiempo tengo, cuantos recursos y como se van a gestionar.
• Tener en cuneta CapEX y OpEX.

Con respecto al ALM

• Demasiadas diapositivas con muy poca profuncidad. Las imágenes no daban apoyo realmente de lo que se exponía.
• Debe de ser más concreto. No hace falta una sección expecífica si ya se cuenta implícito en otras partes de la presentación.
• Planificación: no debemos ver todo tan general, debemos ver el tiempo y los recursos que tenemos y desde ahí ver el orden en el que hacemos las cosas

Con respecto a los usuarios piloto

• Es muy interesante tener contacto en vivo con ellos aparte de la comunicación telemática. El lenguaje corporal es importante.
• Deben de tener claro cual es el proceso de recogida de feedback.
• Asegurarnos de que tienen un compromiso 100% real de testear la aplicación.
• Expecificar como nos vamos a comunicar con ellos.

Otras anotaciones

• Mockups demasiado superficiales. se debe de decir cuales son los elementos diferenciadores que nos aportan valor.
• Decir como ha afectado al proyecto que la gente no haya llegado al mínimo de horas requerido.
• Hacer estadísticas de profesor que nos diferencien más de los demás.
• Definición de características muy superficial. Decir porque nuestra propuesta presenta más variedad con respecto al resto.
• Detallas que nos da la IA como diferenciador.
• Se deben de mencionar las personas concretas del grupo y sus roles

Semana 5 (05/03), evalución

En general resaltar positivamente que estamos echando cuenta al feedback y que vamos en buena direcciones.

Obligatorio para la siguiente clase (12/03) :

• Documentación de todo lo que no sea pedido explícitamente en un formato concreto (pdf o excel) se debe de hacer en md.
• Presentación de un tercio del avance hasta el momento.
• Análisis de retrospectiva del sprint.
• Trabajo mejor del Open Killer.
• Stack tecnológico.
• Demo de los casos core hechos hasta el moemento.
• Visión de alto nivel de nuestra metodología y del ALM.
• Revisión plan de desarrollo del sprint.
• Análisis de rendimiento de los miembros y como medimos rendimiento.
• Plan de pruebas y como lo gestionamos.
• Listado explicito usuarios pilotos.
• Modelo gestion y recogida de feedback.
• Presentación equipo y estructura.
• Análisis económico.
• Comparativa competidores (una sola diapositiva).
• Commitment agreement en 1 - 2 diapo, ver decicacion temporal por miembro, desde comienzo proyecto y desde el sprint. Además 1 diapositiva más del team building.
• IMPORTANTE: visión de mejora continua siendo más concreta: análisis problemas encontrados, ver estado de estos problemas, ver las medidas, plan contingencia, lecciones aprendidas, decir como nos estamos asegurando que las medidas tomadas realmente están funcionando. (Ver problemas concretos y medidas concretas)

Con respecto al Killer Openner

• Buen killer oppener pero falta mas energía por parte de los presentadores.
• Intentar transmitir alegría para conseguir enganche en la presentación.

Con respecto al foco diferenciador

• Bien presentado (IA, estadísticas) aunque se necesita concretar más con respecto al avance, nos quedamos demasiado en la capa superficial.
• Ver si el problema a la hora de concretar nuestro foco diferenciador se cebe a un problema de concepto o de presentación.
• Ver foco diferenciador de las estadísticas
• Responder a: ¿Cuál es nuestro elemento diferenciador real?

Con respecto al ciclo de vida

• Da la sensación de que no se tiene en cuenta las iteraciones de los sprint. no se transmite como se va a ir construyendo.
• Es importante la temporalidad en los sprint ya que todos no van a durar lo mismo para saber a qué nos enfrentamos.
• Es importante decir como vamos construyendo ese producto poco a poco respecto a cada sprint (incrementalmente).
• No se ve el impacto temporal.

Con respecto al cumplimiento del Sprint

• Nos quedamos en la parte superficial ya que no concretamos como mitigar los errores.
• Hemos dicho lo que ha ido pasando y hemos dicho que lo hemos ido mitigando, pero tenemos que profundizar mas en que estamos haciendo para evitarlo.

Conjunto de razones de fallo en el sprint2

• Existencia de errores del tipo: crash y errores http no tratados.
• No debe de haber botones sin funcionalidad.
• No de deben de mandar datos desde formularios que no se hayan validado anteriormente.
• Todo debe de hacer lo que debe de hacer.
• No está permitido que por culpa de un error un usuario pueda hacer cosas en la aplicación que en teoría no debería de poder hacer por su rol.
• Debe de estar desplegado sí os sí.

Otras anotaciones

• Incentivar las entrevistas personales con los usuarios pilotos.
• Hilo conducto un poco conductor un poco caótico, reestruturar un poco. *
• Poner algo mas alla en el commitment agremment que el tema de las horas, poner mas cosas. *
• Poner costes de contratación se situan en copex y opex, en ambos sitios y también se debe de tener en cuenta costes de mantenimiento.
• Se debe de poner a nivel de miles de euros, 30K x ejemplo.
• Seguir poniendo el video con las cosas core, no capturas.
• Responder a la pregunta como sabemos que esta funcionando bien las medidas que estamos implemntando, no solo cuales son, si no, además, si están funcionando.

*Feedback no dirigido a nosotros en exclusiva.

Semana 6 (12/03)

Muy bien la forma de presentar al equipo y bien hecho lo de poner el dinero en miles. Seguimos mejorando. Presentación fluida.

Obligatorio para la siguiente clase (26/03) :

• Retrospectiva s2.
• Demo caso uso crítico.
• Killer Openner.
• Visión de producto
• Sistema CI/CD, explicitar framework de pruebas que usamos para el testing de unitarios, end2end e integración.
• Stack tecnológico. (Sin comparativa)
• Resumen de alto nivel de que ha pasado en el s2 (previsto vs lo que se ha realizado)
• Análisis de rendimiento de miembros del equipo, explícito por persona y decir, además, cómo medimos ese rendimiento (métricas concretas).
• (en caso de haber sido necesario) Reajustes del plan del sprint
• Plan concreto del s3.
• Análisis de problemas. Por cada problema: estado, medidas, lecciones aprencidas, contingencias y como sabemos que esta funcionando la solución. Ademas incluyendo métricas concretas, umbral al que queremos llegar, y periodo de tiempo en lo que lo queremos conseguir.
• Análisis de usuarios piloto. Resumen de alto nivel de los usuarios hasta el momento (no hace falta decir personas concretas): número de usuarios y de cada tipo cuantos tenemos. Además plan para aumentar ese numero y cómo se gestionan y el estado de recogida de feedback. Añadir reflexiones de que hemos analizado sobre ese feedback. Tiene que responder a la pregunta clave: ¿cuánto pagarías por esto? Deben responder los usuarios piloto sin que demos rango de precio, sin influenciarles nada.
• Presentación equipo + estructura
• Análisis económico. Estado actual económico y previsión a futuro, en concreto capex y opex. Importante: análisis de cada cifra tiene que estar contextualizada en un marco temporal y, si esa cifra depende del número de usuarios, poner para cuantos usuarios son esas cifras. (dar ese contexto) ( Suspenso si no tenemos análisis económico donde se vea: estado actual de cuanto llevamos gastado, previsión a futuro de capex opex con línea temporal y número de usuarios previsto).
• Ver, según las horas que llevamos totales de trabajo, cuanto llevaríamos gastado del presupuesto total.
• Análisis de competidores (1 diapo muy al pricipio).
• 1 diapo del team buildin, además de explicar cómo está funcionando (si no hay estamos suspendidos)
• 1 o 2 diapo de commitment Agremment, resumen de alto nivel explicitando dedicación temporal real vs estimada donde se vea para cada miembro desde inicio asignatura y desde inicio de sprint actual.

Con respecto a la demo:

• Demo se tiene que ver bien con zooms, ver orden lógico de cosas.
• Pensar en lo que ponemos en la demo.
• Demostración dejar mas claro cómo se pasa de alumno a profesor.

Con respecto a la vista de la aplicación:

• Interfaz con más usabilidad por parte del profesor.
• No llevar lo de gamificación a parte del profesor porque es menos usable la interfaz.
• (propuesta del profesorado) pensar actividades sobre cómo a los alumnos se les introducca el de pensamiento computacional, ética y uso de la ia.

Con respecto al killer oppener:

• Ver quien es nuestro publico objetivo al que vamos a presentar la aplicación, reflexionar sobre cual puede ser un buen killer opener que capte la atención.

Con respecto a la presentación

• Empezar con una frase explícita no está del todo bien, intentarlo cambiarlo, ya que es algo para decirlo textualmente y no aporta mucho, entonces mejor poner imágenes o algo aimilar.
• Poner contenido q de valor diferencial claro no estándar. Ciclo de revisión de pr y todo eso es muy estándar asi que no hace falta de poner a tanto detalle ya que no aporta demasiado. Quitarlo para darle más importancia a otras cosas.
• Cuántos minutos usamos de GitHub actions.
• Para aportar valor a nivel metodológico: indicar como estruturar clocki y que correspondencia tiene las issues con las tareas el clocki.
• Que se vea visualmente en la presentación como hacemos foco en las cosas.

Con respecto al análisis del rendimiento

• Que tareas se han complicado, que dificultad tenían, no mezclar en la misma diapositiva análisis y desviaciones de tiempo.

Otras anotaciones

• fallos muy comunes, suspensos directos:
  • 1 no enseñar las desviaciones en curso de todos los miembro por sprint y el total de la asignatura.
  • 2 no tener una forma sistemática de mejora. Para cada problema debemos de definir unas acciones concretas (problemas en curso) y más importante una metrica concreta que diga como se está solucionando además de un umbral objetivo (en esta métrica se quiere llegar a tanto) y un objetivo temporal de cuánto queremos tardar en llegar a ese umbral de esa métrica.

Semana 6 (26/03) (EVALUACIÓN)

• forma presentación problemas muy bien.
• crecimiento usuarios piloto muy bien.
• muy bien que haya despliegues separados para producción y para usuarios piloto.

Obligatorio para la siguiente clase (09/04) :

• Foco: idea clara del proyecto.
• Buen open killer.
• Stack tecnológico; de muy alto nivel de abstracción.
• Demo de casos de uso core. Esta debe de seguir un hilo conductor claro y realista. Se debe de hacer en base a un escenario imaginario realista de uso. (Puede ser buena idea unir ese hilo conductor con el open killer).
• Visión de alto nivel de la metodología; mostrar solo adaptacionnes concretas del proceso scrum, no todo.
• Visión de alto nivel del ALM y el CI/CD.
• Plan de pruebas detallado.
• Análisis de alto nivel del estaro del S3.
• Análisis del modelo de rendimiento explícito. Debe de ser para todo tipo de tareas, y se debe de mostrar en un gráfico visual donde se vea el rendimiento de cada miembro del equipo correlacionado con su trabajo. Es obligatorio que aparecca todas las siglas de todos los miembros.
• Revisión (de ser necesario) del plan de desarrollo.
• Análisis de problemas encontrado, indicando cuales son, sus estados, las medidas aplicadas, sus planes de contingencia, la prevención a futuro, sus métricas concretas, los umbrales objetivo y los periódos para alcanzar dichos objetivos.
• Resumen de alto nivel de los usuarios piloto diciendo cuantos son y los tipos.
• Estado de recogida del feedback, hay que explicitar las acciones que se han tomado para reaccionar a dicho feedback recibido.
• Presentación del equipo y su estructura,
• 1 diapositiva de los competidores,
• Análisis económico diferenciando entre Opex y Copex. Se debe de mostrar el estado actual del presupuesto. También, hacer un análisis de la evolución en un marco temporal. Tener en cuenta el coste de los servicios que usamos y como nos afecta.
• Pensar en story board de anuncio con una historia para los clientes.
• Resumen de alto nivel del cumplimiento del commitment agrement. Explicitar la desviación temporal real de cada miembro del proyecto en base al inicio del sprint y al inicio del proyecto.
• Team building y como afectó esto al proyecto.

Con respecto al análisis económico

• Separar opex del mantenimiento es un error porque también lo incluye.
• Cuidado con que el break even no tenga en cuenta el Capex, ya que se tiene que tener en cuenta lo que se ha invertido a lo largo del desarrollo del proyecto (su coste de desarrollo).

Con respecto a la demo

• No se veía muy bien, demasiado rápida, con cambios muy rápidos, si se viera por primera vez no se entendería las cosas.
• Foco en primaria -> cambiar demostración del producto para que sea algo mucho mas cercano con el uso real de los usuarios.
• Video descargardo mejor no de YouTube; se recomienda
• Falta que se vea lo que es el elemento clave que nos diferencia que explicamos al principio; no queda del todo claro a nivel visual.

Con respecto al análisis de rendimiento

• No hacer análisis rendimiento en horas; una cosa son las horas y otro el rendimiento. Son distintos, el rendimiento puede tener en cuenta las horas pero no se puede basar solo en eso.
• Definir métricas propias.

Con respecto a los usuarios piloto

• Falta hablar de que vamos a hacer con el feedback de los usuarios piloto, el resto bien.
• Se recomienda entrevistas personales

Con respecto al open killer

• No se debe de esperar a que todos se queden callados, parte de su efecto es que todos tomen atención en la presentación

Con respecto al hilo conductor

• Sigue avanzando en las buenas practicas de responder a diferentes preguntas, pero dar una vuelta y evolucionar a algo más lógico. 1º sprint y programación y luego usuarios piloto no del todo bien, mejor hacerlo del revés, presentar a los usuarios piloto primero y luego como su feedback nos afecta a nosotros.
• Darle una vuelta al hilo para facilitar captación y presentación.
• Evitar decir "esto lo comentamos más tarde", ya que deja ver una mala organización de la presentación.

Otras anotaciones

• La lista de dedicación no estará en la base de datos pública si no que se subirá a enseñanza virtual.
• Dentro de la documentación deberá de aparecer una sección de demos. En esta sección deben de estar las demos hechas hasta el momento subidas. Se debe de subir también una demo de no más de 10 min, la cual debe de estar también subida a youtube. Dicha demo, debe de mostrar todos los casos de uso core completados y se deben de añadir las marcas de tiempo en los comentarios del video de youtube de cada prueba de caso de uso core (para facilitar llegar a ver os diferentes casos de uso).
• Dentro del documento de Guidelines, se añadirá una nueva sección donde se explicitará la reacción que hemos tenido al feedback recogido de los usuarios piloto de los otros grupos de clase y del profesor revisor.
• Importante que las decisiones que se tomen sean desde la decisión y no solo porque nos lo han dicho.