Saltar al contenido principal

Grupo 11

En este documento vamos a encontrar el feedback recibido por el grupo 1

Semana 1​

Feedback general​

  • La importancia de resaltar la idea principal de lo que se quiere transmitir. Cuál era el propósito de la aplicación, etc. El objetivo de esta semana era conocer la idea, analizar qué es lo que nos interesa y cómo lo vamos a llevar a cabo.
  • El feedback de los compañeros es importante, indica que se enteran de la presentación.

Presentación​

  • Respecto a la parte visual, las diapositivas están muy bien pero faltan los números de página.
  • Utilizar nuestros propios conceptos, no los de la asignatura.
  • Presentaciones más visuales para que sean más dinámico.
  • Evitar usar imágenes que “creamos que no se ven bien”.
  • Plantear mejor cómo presentar el cuadrante de crecimiento de competidores. Mejor una imagen creada por nosotros que un captura.
  • Eficiencia de la comunicación: intentar buscar lo que resulta valioso. Pensar en la cantidad de información que se proporciona (los árboles te impiden ver el bosque).
  • A veces se ha hablado muy rápido y cuesta seguir el ritmo.
  • Preparar mejor el speech de las presentaciones.
  • Presentar un reloj de horas totales. Cada semana se actualiza el tiempo consumido.

Base de conocimiento​

  • ¿almacenamiento organizado de la información? Tenemos que pensar qué consultas vamos a hacerle a la base de conocimiento para aclarar qué herramienta utilizar.
  • Guardar todos los enlaces de los diálogos con la IA.

Semana 2​

Feedback general​

  • Antonio estaría dispuesto a pagar por nuestra aplicación. Quiere un asistente que le diga cuántos aparcamientos hay en su cercanía y le guíe. Que se pueda hablar con un asistente, para que no haya que manipular.
  • Muller propone: ceder el aparcamiento. Que se cedan las plazas. Hacer que se espere la persona que libera el aparcamiento a que llegue el que la solicitó.
  • Descartar la idea de los parkings privados. Eso lo tiene google mejor.

Presentación​

  • A la hora de exponer, mirar a todos, exponer de forma en la que captamos la atención, hacer comentarios graciosos y sarcásticos para que no sea monótona la presentación. Contar un ejemplo y/o una historia breve.
  • Killer opener: una historia para enlazarla con la presentación.
  • Para datos estadísticos mejor citar fuente.
  • Hay que dejar los datos de contacto y el qr de feedback en las prox presentaciones, duante todo el momento de preguntas y feedback.

Herramientas​

  • Usar copilot y ahorrar tiempo. Ya que hay herramientas hay que usarlas.
  • “Torpes sois si no usais chatgpt para programar” - Antonio.

Riesgos​

  • Los riesgos con más probabilidad hay que pensar en los planes de contingencia bien.

Semana 3​

Presentación​

  • Poner los planes de precio de la aplicación.
  • Más zoom en los mockups, hay que buscar manera que el móvil se vea bien.

Presentadores​

  • Usar un lenguaje más formal, dejar atrás tantas coletillas.
  • Micro más lejos si se habla fuerte.
  • Usar los términos ingenieriles, profesionalizar el vocabulario.

Análisis de costes​

  • Barajar ingresos por anuncio, al principio es baja.

Competidores​

  • Actualizar los competidores, echar un ojo constantemente.
  • Adaptar las nuevas características de Apparkya a las funcionalidades de nuestra página.

Usuarios pilotos​

  • Gestión de usuarios pilotos, hay que contactar con ello, empezar a hablar con los del grupo 5 y buscar gente externa dispuesta a usar la aplicación.
  • Crear un plan de gestión de las comunicaciones.

Semana 4​

Desarrollo​

  • Hay que mejorar la forma de hacer tests, que el testeo lo haga otra persona diferente a quien haga la funcionalidad. Hay que seguir las buenas practicas.
  • Añadir comentarios en tareas para github, no le estamos sacando partido al potencial que eso tiene. En la propia issue se declara el caso de uso que la implementación debe superar. Mirar el número de comentarios por issue como forma de media; a semana que viene nos preguntaran por esto.

Commitment agreement​

  • Añadir estado del commitment agreement para la siguiente presentación.

Spring Backlog​

  • Indicar hacia donde se quiere llegar en los 3 srings.

Riesgos​

  • Indicar si se han solventado los riesgos que están ocurriendo y como se han solventado.
  • Tenemos que saber identificar cuales son los puntos de bloqueo, hay que identificar las razones por las que el proyecto se puede quedar bloqueado.

Costes​

  • Tener en cuenta el marco temporral y la "capacidad nominada" del opex ¿Si se duplica el número de de usuarios, se dobla el coste? ¿Se triplica?

Presentación​

  • No tenemos que demostrar que hemos hecho las cosas mal, hay que mirar las soluciones.
  • No hacer referencias a otras presentaciones que hemos hecho.
  • Ha faltado: elevator speech, mvp, casos de uso y explicar de donde viene las formulas.

Semana 5​

Aplicación​

  • Para el tamaño del parking poner algún tipo de medida. Por ejemplo algún coche como medida.

Costes​

  • Ir actualizando los costes con las horas que llevamos.
  • Calcular los beneficios y gastos optimistas, pesimistas y esperados.
  • No juntar TCO y Mantenimiento.

Presentación​

  • Presentar la situcación altual de los costes, cuanto llevamos gastado.
  • Dejar muy claro en la presentación el rendimiento del equipo y el estado del comitmment agreement. Deben estar separados.
  • Presentar el objetivo de los 3 sprint.
  • Presentar tablas más claras que indique que es cada columna/fila.

Riesgos​

  • Muy buena manera de presentar los riesgos.

Herramientas​

  • Descargarse el pluging de Clockify, muy util para contavilizar el tiemo en el github.

Semana 7​

Presentación​

  • Importante mostra el customer agreement.
  • La situcacióm actual frente al total debe ir con los costes.
  • Hay que poner un video en la demo, se está vendienfo humo.

Costes/Beneficios​

  • Indicar en la presentacion el número de clientes estimado y de donde han salio.

Burn down​

  • El burn down se debe hacer por sprint, no por semana.
  • Debe representar el estado en que se encuentra el sprint en el momento de la presentación.

Project management​

  • Se han hecho previsiones poco realistas de acuerdo con el ritmo que llevamos.

Semana 8​

Presentación​

Presentación​

  • Relacionar el inicio efectivo con la demo.
  • Mucho tiempo dedicado a la parte inicial. Se tiene que dedicar el mayor tiempo a la parte técnica y planificación del proyecto que a vender el producto.
  • Explicar en la presentación como se va a gestionar el feedback de los usuarios pilotos.

Demo​

  • Usar una lupa en la demo para hacer zoom en las partes claves.

Documentación​

  • Poner las condiciones de fallo en la parte del Sprint 2, no en Planificación del proyecto.

Desarrollo​

  • Se valora positivamente implementar un social login (google, facebook, ...)

Demo​

  • Usar una lupa en la demo para hacer zoom en las partes claves.

Documentación​

  • Poner las condiciones de fallo en la parte del Sprint 2, no en Planificacion del proyecto.

Desarrollo​

  • Se valora positivamente implementar un social loging (google, facebook, ...)

Semana 9​

Demo​

  • Enlazar la demo con el anuncio, usar simbolos para indicar que tipo de usuario usa la funcionalidad.
  • Hacer la demo con la aplicación en claro (blanco).
  • Eliminar las partes que no forman parte del core de la aplicacion, como el login.

Presentación​

  • La parte del planning de la siguiente semana va después de la demo.
  • Poner menos datos en las diapositivas porque no da tiempo a digerir la información.
  • Ajustar el tamaño de las diapositivas a la pantalla donde se proyecta.
  • Cuidar la presentación y unificar los estilos. Hay que ser profesionales y consistentes.
  • La parte del costumer agreement se puede reducir a una diapositiva.
  • Elaborar un elevator pitch que hable sobre nuestra funcionalidad de forma resumida.

Presentadores​

  • Vocalizar más en el inicio.
  • Explicar mejor de que va nuestra aplicación para que sea clara para los oyentes.

Semana 10​

Presentación​

  • Hacer la gráfica de Proyect state más grande para que se aprecia mejor los datos.
  • Añadir apoyo visual para el killer opener
  • Explicar antes de mostrar la demo que se va a mostrar.
  • Mejorar la performance-time matrix.

Riesgos​

  • Si un riesgo ocurre, es un problema --> PROBLEM MONITORING
  • Especificar mejor las soluciones que se toman para solucionar los riesgos.
  • Establecer un umbral para comprobar la eficacia de la solución al problema.

Semana 11​

Anuncio​

  • Acortar el anuncio.
  • No usar terminos de ingenieros en la presentación, por ejemplo C2C.
  • Usar datos para convencer a los inversores, datos que llamen la atención.
  • No comentar cosas irreales, aunque sea para un chiste.
  • Centrarse en la funcionalidad de ceder aparcamiento.

Demo​

  • No incluir la introducción de datos en los formulacios (registrarse, inicio de sesión, etc.)
  • Centrarse en la cesión de aparcamiento.

Presentación​

  • Mejorar la narrativa con la que se cuenta los competidores. Llamar más la atención a los oyentes para vender que lo nuestro es mejor.
  • No destacar el paso pesimista en los costes y beneficios, a no ser que sea para realzar lo bueno.
  • No poner el título de Elevator pitch.
  • Hacer un Elevator pitch más impovisado, que no quede muy enconsetado y planeado.
  • La parte de key aspect no es nada específica, vende humo.

Marketing​

  • Goals del plan de marketing muy genérico.
  • Presentar el calendario de marketing y un ejemplo de flyer.

Segmentación​

  • Segmentación muy genérica. No vale decir que todos valen.
  • Crear una persona para mostrar cual es el público objetivo.

Semana 12​

Presentación​

  • No hace falta un índice que vaya siguiendo, simplemente la presentación debe seguir un hilo argumental bueno.
  • Presentarse al inicio de la presentación.
  • Hacer el inicio efectivo más visual, usar varias fotos que sigan la historia.
  • Recortar la tabla de competidores, dejar los más relvantes o marcarlos para que destaquen.
  • No usar terminos de la asignatura (CapEX, OpEX, TCO).
  • Redondear los números.

Anuncio Inversores​

  • Añadir lo de los tipos de inversión en el anuncio de inversores y quitarlos de la presenatción.
  • Dar datos reales que inciten a los usuario a invertir en la aplicación.

Demo​

  • Que la demo sea más como una historia, más fluido todo. Que siga el contexto del anuncio.

Presentadores​

  • Dar toda la energía posible para la presentación.
  • Hacer una conexión fluida de los apartados.

Segmentación del mercado​

  • Abarcar a un rango de edad diferente o justificarlo mejor.
  • Enfocar la publicidad segun al sector al que nos queremos centrar. Anucios televisión, baners, ... .