Grupo E - Vecinus

En esta página se encuentra el feedback recogido por el grupo E - Vecinus 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

📢 Presentación y Narrativa

Hilo Conductor: La presentación no puede ser un listado de puntos; debe tener una narrativa que conecte todo.

Killer Opener: Debe ser profesional y neutro. Prohibido el uso de memes, temas políticos o controvertidos ante un público formal.

Demo Mejorada: Hacerla más realista con zoom, eliminando pasos innecesarios como el login o el cambio constante entre comunidades.

📊 Negocio y Presupuesto

Coste Real: Eliminar el concepto de "coste cero". En el presupuesto se deben reflejar los planes de pago, aunque se use la capa gratuita actualmente.

Modelo de Ingresos: Evaluar el cambio de un coste fijo por comunidad a un coste por uso o por número de pisos (límites de uso).

Claridad Financiera: Definir mejor el OPEX y ajustar la transparencia de competidores (quitar lo que no se explique).

🛠️ Gestión de Equipo y Calidad

Team Building: Añadir diapositivas que muestren los resultados y la evaluación del desempeño del equipo.

Análisis de Rendimiento: Incluir métricas definidas y su evaluación correspondiente.

Definiciones Técnicas: Especificar qué se pide exactamente en el commit funcional.

• Aclarar la periodicidad de revisión de las PR (diaria, semanal, etc.).
• Detallar en qué consiste la penalización en la diapositiva de problemas.

6. Notas de clase

Semana 1 (05/02)

Con respecto a la presentación:

• Mejorar formato visual de presentaciones.
• Reducir texto: Eliminar repetidos y priorizar lo esencial
• Definir idea de comienzo potente (hook).
• Controlar tiempos y lenguaje corporal
• Adaptar mensaje al público objetivo de cada presentación
• Preparar estructura fija: Introducción, Problema, Solución, Diferenciación, Tecnología, Plan

Con respecto a la documentación:

• Formalizar metodología de recogida de feedback: Documento común y Responsable de apuntar feedback
• Recoger feedback de: Profesores y Otros grupos
• Analizar feedback y decidir qué incorporar
• Registrar: Reparto de responsabilidades, Horas, Evidencias de trabajo
• Mantener commits claros
• Usar Clockify: Descripciones detalladas y representativas

Con respecto a la organización del equipo:

• Mostrar claramente: Miembros del proyecto y Componentes/roles
• Redactar y firmar el commitment agreement
• Registrar evidencias de responsabilidades
• Permitir movilidad de roles si es necesario

Con respecto a la preparación del próximo día / entrega:

• Incorporar todo el feedback recibido
• Tener clara la estructura final del proyecto
• Presentar:
  • Casos de uso core
  • Mejorar el análisis de competidores + diferenciación en una tabla comparativa. Dejar claro dónde estamos nosotros (la diferencia con el resto)
  • Mockups con evidencia diferencial
  • Stack tecnológico
  • Análisis de riesgos
  • Sistemas de despliegue (pros/contras, pago/gratis). Tener en cuenta que son 4 despliegues que deben persistir
  • Pensar también en la base de datos, en caso de existir, deberá haber hasta 4 (una por despliegue)
  • Plan para organizar el Sprint 1
  • Plan para localizar los usuarios piloto
• Profundizar más en nuestras fortalezas frente al resto de apps (diferenciación)
• Decidir quién es nuestro cliente objetivo (grandes comunidades, pequeñas, etc.)
• Focalizar muy bien en cómo llegar hasta el cliente objetivo -> Buscar o destacar las funcionalidades que más les llame la atención, aunque tengamos otras
• Argumentar bien el tema de las votaciones -> Es una buena funcionalidad pero debemos estudiar el marco legal

Aspectos a tener en cuenta

• Habrá un despliegue independiente por cada entregable. Al final del cuatrimestre debemos tener un total de 4 despliegues
• Si la app tiene base de datos, habrá también 4 independientes
• Cuándo se despliega no se puede volver a tocar el código. Los bugs se corrigen para la siguiente entrega
• Cuando se da un dato (ej. "Comentarios malos") debemos decir de dónde hemos sacado ese dato
• Debatir si conviene más funcionalidad general para mucha gente (cualquier público) o funcionalidad más específica para un público más centrado
• No presentar aspectos negativos de otras aplicaciones que la nuestra tampoco va a tener

Semana 2 (12/02)

Comentarios positivos:

• Buen análisis de los aspectos de despliegue y todo lo que hemos abordado del coste de la hibernación.

Con respecto a la presentación:

• Es algo muy negativo tener tantísimo texto
• El tamaño de los mockups es muy pequeño, no se ve. Debemos aprovechar mejor la pantalla
• Las imágenes más de lo mismo
• El QR es mala idea, pierde tiempo y la gente deja de prestarte atención
• Análisis tecnológico: mala presentación. Mostramos mucha información en la presentación que no da tiempo a analizar. RECORDAR, si hay demasiado texto nos dejan de atender. Hay que quitarlo.
• Los casos de uso core están bien pero los mockups no los defienden, deben centrarse más en estos y menos en el resto de funcionalidades.
• En todas las tablas que pongamos debemos resaltar nuestra opción y quitar texto, mucho texto, que no requiera concentración para entenderla.
• En la planificación del Sprint falta la planificación temporal, aunque luego no se cumpla hay que añadirla

Con respecto al feedback:

• Mejorar la presentación
• Profundizar más en la información que damos con respecto a la IA. Por ejemplo, la IA que usemos, si tiene pricing plan, como se lo cobramos al cliente, etc etc.
• Defender más la IA, es decir, si es nuestro hecho diferenciable al resto tenemos que destacarlo aún más. Algo que atraiga a los clientes, que hagan que paguen por el producto

Con respecto a la organización del equipo:

• Debemos añadir a la presentación los miembros del equipo
• Debemos añadir también cómo estamos organizando al equipo (Backend, Frontend, ...)

Con respecto a la preparación del próximo día / entrega:

• Mejorar las presentaciones
• Incluir los aspectos del feedback recogido
• De cara a la siguiente presentación debemos realizar una killer opener, es decir, comenzar la presentación de una forma que atraiga al público

Aspectos a tener en cuenta

• Cuando mostramos demasiado información lo mejor es quitar casi todo el texto y tener en un documento formalizada esa información, para asi poder defenderla en el caso que nos pregunten. (Por ejemplo para el análisis tecnológico).

Semana 3 (19/02), evaluación

Comentarios positivos:

• El análisis del valor
• La diferenciación con los competidores
• El análisis tecnológico
• Correcta planificación del Sprint 1

Con respecto a la presentación:

• Entrar más en detalle sobre como vamos a implementar la firma digital
• Entrar más en detalle sobre como vamos a implementar la transcripción de actas en cuanto a la tecnología que vamos a usar
• En algunas diapositivas hemos intentado meter mucho contenido en muy poco espacio y están un poco sobrecargadas
• Debemos cambiar el orden de las diapositivas de las funcionalidades porque estamos presentando antes las funcionalidades genéricas que los casos de uso CORE, que deben ir antes
• En las tablas de características estamos poniendo colores pero no especificando lo que es o significa cada uno

Con respecto al feedback:

• Mala planificación del Sprint 2. Hemos indicado que aquí vamos a añadir los usuarios piloto (login y registro), pero estos deben estar en la BD desde el primer día
• Falta una lista con los usuario piloto
• Falta la dedicación de tiempo
• Quizás conviene más centrarse en un tipo de usuario (administrador o propietario). Esto no significa eliminar al otro, sino encaminar la presentación y el proyecto al usuario que nos de más juego
• Debemos tener mucho cuidado con el tema de la seguridad y privacidad de los datos, y las firmas digitales. Debemos estudiar más en profundidad esto

Aspectos comentados de forma general

• Los usuarios piloto deben estar, es muy importante tener una lista detallada de los mismos y un compromiso formal con ellos
• Hay grupos con análisis tecnológicos muy superficiales. También tenemos que explicar cómo vamos a llevar a cabo los despligues, hacer pruebas previamente, explicar cómo vamos a congelar los despliegues. Además, se da poco detalle sobre el CI/CD que se va a implementar
• Debemos analizar bien el calendario para los sprint, hay que tener en cuenta que las semanas de feria o semana santa no se trabaja
• Cuidado con los contenidos frágiles (datos de usuarios, firmas digitales, etc)
• En cuanto a la presentación del stack tecnológico tenemos libertad
• En cuanto a la base de datos de conocimiento (la que recoge el feedback), está muy mal gestionada. Debemos usar Docusaurus. Si no se arregla supondrá nota negativa global
• Ya debemos empezar a desarrollar. Tenemos que elicitar muy bien como vamos a hacer los 5 despliegues
• Cuando explicamos la metodología de desarrollo que usamos hay que analizarla muy bien, con una visión de detalle de alto nivel
• En las próximas presentaciones debemos incluir el estado actual del sprint en el que nos encontramos (ej. un burndown)
• En las próximas presentaciones hay que ir recogiendo los problemas encontrados, las lecciones aprendidas y el plan de contingencia para solventarlos
• Presentar el equipo, la estructura que tenemos y usamos, y un análisis económico (a nivel de presupuesto, ...)
• En la siguiente presentación, 1 sola diapositiva para el cumplimiento del commitment agreement y el informe de rendimiento individual (clockify)
• En la siguiente presentación, 1 sola diapositiva para el análisis de competidores (interesa ponerla por el principio)

Semana 4 (26/02), Sprint 1

Aspector positivos:

• CI/CD implementado es correcto y bueno

Con respecto a la forma de presentar:

• Se recomiendo presentar con más calma, ir más lento
• Se recomienda llevar una vestimenta adecuada
• Decir más en menos frases -> usar palabras clave.
• Enfocar la presentación al desarrollo.

Con respecto a la presentación:

• En las tablas, especificar lo que significa cada color. Usar rojo en lugar de amarillo en tablas.
• Sobra la primera diapositiva de commitment agreement, hay que quitarla
• Dividir metodología y miembros de equipo para que se entienda mejor -> poner fotografías del equipo.
• La diapositiva de la estructura del equipo es compleja y no se entiende. Desglosarla y ponerla, por ejemplo, como la tiene el otro grupo con las fotos de la orla
• Debe haber mayor homogeneidad y consistencia en la presentación y la imagen corporativa. Hay colores llamativos en tablas que sobran por ejemplo.
• Diferencia en estilos entre diapositivas -> estilo y paleta debe ser uniforme, están como si se hubiesen hecho con prisa.
• La diapositiva del clockify debe mostrar las horas de cada uno individualmente frente a la desviación de tiempo estimada.
• Que decida el humano -> instrumentar prompts para que el mensaje sea ese, que no sea la IA -> cuidar lenguaje.
• No se ve ni los riesgos, ni el presupuesto, ni la parte de infraestructura.
• Añadir análisis de coste de GitHub -> gastos de operación y desarrollo. CapEX -> personal, OpEX -> desarrollo.
• Realizar un análisis real, no educativo. Tanto en tiempo, como en costes, etc.
• Análisis de herramientas -> usar modelos freemium es lo más rentable normalmente.
• Debemos ir incluyendo como va el desarrollo de la app en lugar de mockups siempre que sea posible
• Desbalanceado entre mockups y los análisis de trabajo y Sprint. Hay muchas presentaciones de mockups
• Análisis de costes teniendo en cuenta GASTOS REALES (licencias, planes, sin tener en cuenta que somos estudiantes, sino como empresa)

Semana 5 (05/03), Evaluación Sprint 1

Con respecto a la presentación:

• Debemos cuadrar el tiempo de la presentación
• Las transiciones están un poco desorganizadas
• Demo es una demo(usar un vídeo o algo similar). Además, no quedaba claro qué estaba terminado y qué no
• Debemos tener y seguir un hilo argumental. Que haya una transición entre los bloques fluidos

¿Qué debemos de corregir?

• Debemos dejar más claro la firma digital
• Para la firma hacer lo de los bancos, quizás sea lo más sencillo
• No es profesional dar la app gratis (a los usuarios piloto en el futuro). Pensar en la rentabilidad.
• Dar una solución a modo de producción, y si es limitada gratis. (Explicar bien que todo el despliegue y demás es gratis)
• Para las pruebas usar el modelado (por ejemplo, los test hacer con mocks y no gastar llamadas a la API) y para los usuarios piloto el real
• Los gastos son confusos
• Los gastos operativos no son personas
• Commitment agreement, debemos decir si se está cumpliendo o si se ha inflingido
• Para la gestión de incidencias igual ya existe algo hecho, investigar si podemos usarlo a modo de api por ejemplo
• En las lecciones aprendidas, no usar tapices, sino poner la frase real y completa
• En cuanto al riesgo y sus magnitudes debemos evaluarlo (alto, medio, bajo) y cúanto podría costar (30% incluido en el coste por ejemplo)

Aspectos generales comentados en clase:

• Hilo conductor en presentaciones. No suele quedar claro cuando empieza o cuando acaba un bloque. Debemos intentar guiar la presentación como si fuesemos respondiendo preguntas que le puedan ir surgiendo al público.
• Hay que darle más valor al feedback de los pilotos y entrevistas personales.
• El commitment va más allá de las horas y es un aspecto positivo decir si cambia y el por qué.
• Costes de contratación. Capex (los del inicio del proyecto) & Opex (mantenimiento, soporte, evolución, ...)
• Poner los costes como 30K por ejemplo mejor que 30.256€.
• Las demos no son capturas de pantalla, lo ideal es poner la app funcionando (en vivo o en vídeo)
• El Sprint 2 es más estricto: todos los docs que no nos pidan en EV debemos tenerlos en formato markdown en el repositorio
• Se actualizan las razones de suspenso. Ahora incluyen más motivos.

Aspectos generales comentados para el próximo:

• Será un día de revisión igual que siempre
• Análisis de retrospectiva del sprint con los siguientes puntos (Killer Opener, Stack tecnológico, Demo, Metodología de desarrollo, ALM(CI/CD), Plan de desarrollo de los Sprints, Análisis de rendimiento de miembros, Plan de pruebas)
• MUY IMPORTANTE PARA EL PRÓXIMO DÍA: Análisis de problemas encontrados con su estado (abierto, cerrado, en curso) y medidas de contingencia. Analizar cómo estamos analizando la solución (acciones a tomar y métricas para ver si ese problema está siendo bien gestionado)
• Más cosas que debemos tener en la presentación:
  • Listado de usuarios piloto
  • Modelo de recogida de feedback
  • Equipo y estructura
  • Análisis Copex/Opex
  • Competidores
  • Commitment: ver la dedicación en horas desde el comienzo del proyecto y desde el sprint
  • Transparencia al team building

Semana 6 (12/03), Sprint 2

Aspectos positivos:

• Hemos mejorado la forma de exponer
• Hemos mejorado en la velocidad de exposición, vamos más calmados

Aspectos que no pueden faltar el próximo día (motivo de suspenso):

• Divergencia de horas, en el total y en el sprint 2. Debemos añadir dos gráficas
• Lecciones aprendidas
• Para cada problema, debemos tener una métrica para ver si se está solucionando

En cuanto a las diapositivas:

• La transparencia de los competidores está abandonada. Debemos ajustarla al peso que le damos pues muchas cosas no se explican, quitarlas.
• La demo no está mal pero hay que mejorarla. Debemos adaptarla haciendo zoom, que sea más realista, no mostrar cosas innecesarias como el login
• Tenemos que añadir una diapositiva al menos del team building.

Otros aspectos:

• El killer opener no es del todo correcto para un público formal donde haya usuarios potenciales. Básicamente, que si el publico es mas serio, que no utilicemos memes para abrir la presentacion
• Como sabemos que número es el optimos de usuarios piloto. Debemos reflexionar por qué 8 es correcto y no 14.
• No vale decir que la app es de coste cero, en el mundo real vamos a pagar. Así que para el presupuesto evitamos el coste cero, aunque usemos el plan gratuito debemos poner el plan de pago en el presupuesto.

Aspectos generales comentados en clase:

• Con respecto a la demo, no es una landing. Debemos hacerle zoom a lo que mostramos, y pensar en lo que enseñamos (nada de login ni registro)
• Con respecto a los pilotos, debemos plantear un plan de crecimiento
• A partir de ahora, en el stack tecnológico, solo hay que explicar nuestra elección, nada de alternativas descartadas.
• Las cifras económicas ponerlas como 30K.
• Intentar que las fotos de equipo sean uniformes, todas iguales.
• Las desviación de tiempo (horas) y el análisis de rendimiento (tareas completadas, sin completar) son dos cosas totalmente diferentes. No podemos ponerlas como lo mismo
• Team building: obligatorio poner el resultado del mismo
• El feedback de los pilotos debemos tratarlo como oro. Es importante hacerles esta pregunta: ¿Cuánto pagarían por la aplicación?
• Fallos comunes que son suspenso directo:
  • No enseñar la desviación de tiempo por persona en este Sprint en curso y en el total (desde el inicio)
  • No tener una forma sistemática de mejora. Para cada problema, una métrica de cómo medir si se está solucionando o no el problema, y un umbral como sistema de medida de esa métrica.

Aspectos comentados para la defensa del Sprint 2:

Debemos hacer una presencación de retrospectiva con foco en:

• Killer opener
• Demo CORE (en teoría para esta presentación ya tiene que estar todo acabado)
• CI/CD. Explicar el framework de pruebas para cada tipo (unitarias, integración, end to end)
• Stack tecnológico, sin comparativas. Al grano con nuestra elección.
• Resumen de alto nivel de si hemos cumplido lo previsto
• Análisis de rendimiento por persona y decir cómo lo estamos midiendo
• Plan de trabajo planteado para el Sprint 3. Comentar si hemos tenido que hacer algún reajuste.
• Análisis detallado de los problemas que hemos encontrado. Para cada problema: estado, medida tomada, contingencia, métricas para ver si se soluciona, umbral y periodo para ver si se alcanza.
• Pilotos, resumen de alto nivel. Quitar las personas y añadir el número y tipo de cada uno. Plan para aumentar la cantidad y cómo gestionarlos.
• Feedback recogido de los pilotos y reflexión sobre el mismo

Además, debe aparecer también en las diapositivas lo siguiente:

• El equipo
• El presupuesto
• El estado actual (lo que ya hemos gastado del presupuesto) y la previsión futura a nivel económico
• Precios contextualizados en un marco temporal (ej, precio/mes) y si depende o no de la cantidad de pilotos
• Capex y Opex, en que tiempo y cómo varía segun el número de pilotos
• Resumen de alto nivel de competidores. Contextualizar el foco principal y el valor diferencial
• Team building y cómo está funcionando
• Resumen alto nivel del commitment. Dedicación real sobre estimada para cada miembro desde el comienzo del proyecto y en el sprint actual.

Semana 7 (26/03), Evaluación Sprint 2

Aspectos positivos

• La presentación ha mejorado mucho visualmente

Aspectos que debemos corregir

• Falta un hilo conductor, está todo como un listado
• En la demo nos sugiere no cambiar de comunidad en comunidad (es algo innecesario)
• El Opex no queda claro
• Tienen que verse los resultados del team building
• Duda del profesor que debemos evaluar: ¿Tiene sentido un coste fijo por comunidad? ¿No nos interesa más un coste por uso?
• Debemos especificar más que imponemos límites de uso. Podemos usar coste por número de pisos.
• En el killer opener no debemos entrar en temas controvertidos ni políticos
• Algunas diapositivas (entre ellas la 42), son poco específicas o están poco definidas
• En el análisis de rendimiento del equipo debemos añadir también las métricas definidas, la evaluación del mismo, ...
• En la diapositiva de problemas encontrados: Sobre la penalización debemos especificar más sobre ella
• En la diapositiva que se habla sobre el commit funcional, debemos dar más info de que es lo que estamos pidiendo con este
• En la diapositiva que se habla sobre las PR, pone todo el tiempo pero debemos especificar si lo revisamos diariamente, semanalmente, ...

Aspectos comentados de forma general

• Para la gráfica de ingresos esperados también tenemos que tener en cuenta los capex (todo lo invertido)
• Sobre el análisis de los usuarios piloto. Tenemos que dar más detalle sobre lo que nos dicen y lo que hacemos al respecto

Qué esperan el próximo día (Presentación similar con pocos cambios)

• En el stack tecnológico debemos subir el nivel de abstracción (muy alto nivel, dar muy poco detalle)
• La DEMO CORE debe seguir un hilo conductor, no debe mostrar cosas como una lista sin más
• Reducir al máximo la metodología de desarrollo, el ALM y el CI/CD
• Entrar más en detalle del entorno de pruebas
• Análisis del estado actual del sprint
• Modelo de análisis de rendimiento junto a una gráfica y métricas. Analizar para todo tipo de tareas y tienen que aparecer todos los miembros. Ej: para desarrollo número de commits o PR, para docs número de commits al repo común, ...
• Problemas encontrados, métricas, ... --> Cómo sabemos que está funcionando la solución
• Es fundamental explicitar las acciones tomadas respecto al feedback
• Análisis económico: Evolución del número de usuarios, marco temporal, listado concreto de todos los servicios que se usan y costes de cada uno
• Debemos pensar en un anuncio para clientes
• Team building y resultados