Skip to main content

Feedback clase 19 Marzo

Texto_Ocial

ISPP 2024

Feedback clase 19 de Marzo​

19-03-2024​

Repositorio: https://github.com/ispp-2324-ocial​

Web: https://ocial.es​

Grupo 2​

Miembros​

  • Adrián Romero Flores.
  • Ramón José Guerrero Romero.
  • Aitor Rodríguez Dueñas.
  • Fernando Jesús Fernández.
  • Francisco Manuel Villalobos Páez.
  • Horacio García Lergo.
  • Juan José Gómez Borrallo.
  • Iñigo Ruíz Marchueta
  • Jesús Zambrana Guerra.
  • Eduardo Pizarro López.
  • Paula Peña Fernández
  • José Carlos Ortiz Gutiérrez.
  • Carlos Varela Soult.
  • Raúl Montalbán Martín.

Índice

Historial de versiones

Nombre de la versiónCambios
v1.0Redacción feedback
v1.1Añadida plantilla del proyecto

Introducción

Se crea documento para almacenar el feedback recibido por los profesores de todos los grupos para mejorar el proyecto a fecha Lunes 19/03/2024. La duración de la clase fue de 10.30h a 14.30h en el aula H1.10.

Agenda​

  1. Grupo 4

  2. Grupo 6

  3. Grupo 5

  4. Grupo 3

  5. Grupo 1

  6. Grupo 2

  7. Comentarios generales

  8. Tareas

  9. Otras anotaciones

Grupo 4​

  • Buena organización para no trabajar el fin de semana.
  • Tener en cuenta que si los usuarios pilotos dan su feedback tarde, no van a poder corregir los errores a tiempo.
  • Costumer agremment en vez de commitment agreement.
  • Aspectos de uso legal.
  • En la demo, que sean datos reales.
  • Dejar claro que diferencia al grupo de la competencia.
  • Problemas encontrados. Decir en que estado están y como se estan solucionando, y si está siendo efectiva la solución
  • Zoom en la demo bueno.
  • Porque se ha reducido el alcance del proyecto.
  • Elevator Pitch no comenta.
  • Incluir servicio pago S2.

Grupo 6​

  • Ha vuelto a hablar mas rapido.
  • Algunas graficas se ve todo muy pequeño.
  • Buen StoryBoard
  • Elevator Pitch
  • Impacto legal, separar las cosas externas e internas.
  • Zoom en las zonas de la demo para que se vea bien.
  • Cambiar página principal del prototipo
  • Costes de github y github actions.
  • Los presupuestos no se gastan, se ejecutan.

Grupo 5​

  • Quitar lineas rojas de la diapositiva 22 (retrospectiva)
  • Que solo aparezcan las cosas que aporten valor.
  • El costumer agreement se han mezclado conceptos. Custommer agreement: Contrato clásico/contrato desarrollo.
  • Grafica de los costes.
  • Aádir todos los avances
  • Se ha puesto en capex licencias.
  • Muy rapido hablando de los analisis de competidores.
  • Mock del backend.
  • A que se refiere con conocimientos tecnicos dentro de los competidores.
  • Hablar de errores y tiempo ahorra debido al uso de la IA.

Grupo 3​

  • Demo más explicativa. Decir que vamos a ver.
  • Analisis de competencia más directo.
  • Story Board poner algo más claro.
  • Hacer las graficas como vienen en las pildoras teoricas de Carlos.
  • Test que sean funcionales. Medir cuantos bugs encuentran.
  • Leer la pregunta y poner menos texto.
  • ¿Está bien medida la fórmula del rendimiento.
  • Medir los problemas.
  • No es un contrato es un acuerdo.

Grupo 1​

  • Buena Demo, pero hay una vista que esta en negro con fondo negro.
  • De cara a la presentación aunque en la web se ve bien, evitar naranja sobre negro.
  • Presupuesto no centrarse en la parte del desarrollo solo.
  • Análisis a 24 meses
  • Rendimiento del equipo (profundizar) / Esfuerzo. Volver a mirar la fórmula de la evaluacióm.
  • Usuarios pilotos.
  • Comprobar que la direccion valida es valida.
  • Elevator Pitch debería ser más efectivo
  • StoryBoard más detallado.
  • Destacar porqué es bueno iTalent.

Grupo 2​

  • Hacer un StoryBoard tanto para cliente como para usuario.
  • Diapositiva 22, citar fuentes.
  • Demo realistas (tema fotos en los eventos).
  • Con el nuevo competidor, sacar un nuevo riesgo.
  • Muy bien el Opex y Capex.

Comentarios generales​

  • Análisis a 24 meses
  • Aplicaciones donde se pide un gmail o algo si estamos validando que es una direccion valida. (usar API)
  • Nueva condiciones en algunos documentos.
  • Justificar en los documentos como y porque hemos cortado el alcance.
  • Reporte de la IA, decir porblemas encontrados y tiempo que os ha quitado. También decir cantidad de prompts usadas.
  • No se ha dejado en algunos casos las mejoras respecto las semanas anteriores.
  • TCO a 2 años.
  • Usar API para validez del correo electronico.
  • Calendario compartido.
  • 1 encargado revisar presentación.
  • 1 Encargado de revisar failure condition.

Tareas​

  • Introduccion con killer opener bueno.
  • Elevator Pitch.
  • Resumen de analisis de competidores. (centrarnos principalmente en lo que nos diferencia)
  • StoryBoard para todos los roles.
  • Impacto legal del proyecto.
  • Customer Agreement (píldora).
  • Analisis del TCO (Capex-Opex). Añadir costes de la API para comprobar el correo.
  • Costes de github, github-actions.
  • Situación actual respecto a lo esperado.
  • Estimaciones a corto y largo plazo.
  • Justificar costes e ingresos.
  • Refinamiento del equipo.
  • Estado del Commitment Agreement.
  • DMO Sprint2. (Completo y con datos reales)
  • Retrospectiva del Sprint2.
  • Problemas encontrados, solucion, y medir si obtenemos esas soluciones.
  • Reloj avance del proyecto.
  • Plan de usuarios pilotos.
  • Calidad del código.
  • Tareas de priorización de los feedback de los usuarios pilotos.
  • Decir cual es el plan de los usuarios pilotos del Sprint 3.
  • Commitment Agreement de los usuario pilotos.
  • Planificación del Sprint 3.
  • Objetivos del SPrint 3.
  • Report de las IAs con lo dicho arriba.

Otras anotaciones​

Ninguna.

Firma: Juan José Gómez Borrallo y Ramón José Guerrero Romero, secretarios del grupo 2 (Ocial).