Saltar al contenido principal

Grupo 12

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

Semana 1​

  • Podríamos probar a desplegar el proyecto de mantenimiento para que las ONG puedan acceder pues tenemos el backend

  • No debemos plantear decisiones tan importantes a la clase ya que la decisión de que proyecto debemos hacer es nuestra

  • Centrarse además en una cuestión de estrategia, no tan técnica. Convertir debilidades en oportunidades. Analizar el por qué ha ocurrido lo que ha sucedido con el proyecto Aiding. Por qué la aplicación ha terminado así y por qué no la está usando ninguna de las ONGs que colaboraron. Ser capaces de tomar decisiones importantes. Revisitar las opciones que tenemos.

  • Hablar con las ONGs para comentar el porqué del fracaso de la aplicación anterior e incitarles a colaborar para mejorar la aplicación y que así les resulte realmente útil.

  • Preguntar a ChatGPT por el DAFO porque nos puede ayudar dándonos información muy interesante. Además, en el DAFO tenemos que hacer un análisis más profundo, combatiendo las debilidades con fortalezas y las amenazas con oportunidades.

  • Los compañeros han propuesto un posible competidor llamado Etsy, lo tenemos que estudiar.

  • Es importante tener un backlog con cosas para hacer con independencia el cliente o del tipo de proyecto que tengamos. De esta forma, en situaciones de incertidumbre, nadie se queda sin trabajo por hacer por la falta de asignación de tareas.

  • Pensar en un tipo de cliente que tenga mucha necesidad de impresión 3D, para ir hacia ese mercado. Segmentar el mercado para encontrar el cliente principal del producto. Analizar los clientes de más a menos afines.

Semana 2​

  • No decir más o menos. Dar una información más precisa y profesional. No se ha incorporado el coste de GitHub, hay que añadirlo. Cuando hay una idea de todo el coste, ya los números no son más o menos, tendremos números exactos. Poner fórmula mediante la cual se han obtenido los cálculos en la presentación, así la gente se entera bien.

  • Análisis de competidores: disonancia entre lo dicho y lo que aparece en pantalla. Mayor coherencia y mayor apoyo a lo que se dice en las presentaciones. Decir magnitudes y dimensiones de lo que se compara.

  • Riesgos: Confusión entre hechos y riesgos. Un riesgo es un evento que puede o no ocurrir sobre el que existe una cierta incertidumbre. Que parte del equipo no sepa de React, es un hecho, por lo que no hay incertidumbre. Hay que contemplar un plan de formación para los que no sepan.

  • No se han hecho killer openers. Pensar diferentes cosas por si una no sale.

  • La entonación y el ritmo no han sido los adecuados. Hay que usar la entonación para dar importancia a ciertas cosas. Usar pausas y tener claro lo que se tiene que decir para cautivar a los espectadores. Decir mucho de manera sintética, es decir, hablar poco y ser eficiente con lo que se cuenta.

  • Tratar tema de GitHub Actions, si se va a usar o no. Si se usa habrá que pagar también por Git Hub Actions.

  • Indicar número de usuarios y ser precisos. Intentar desterrar la palabra mantenimiento. Tener claro el mantenimiento y el TCO. Lo que se tiene es la operación del servicio. El TCO ayuda a estimar el coste de tener en propiedad el servicio. No se puede meter solo el coste de personal, eso no es mantenimiento. Se puede incluir un mantenimiento correctivo. Contemplar el coste unitario de las cosas.

  • Saber cuál es nuestra audiencia y así poder tratar mejor la presentación y el habla.

  • En varias partes se ponen tablas, que no se identifican exactamente de qué van los datos. Probar con gráficos para mostrar mejor los resultados.

  • En cuanto a competidores, no ha quedado claro. Centrándonos en la impresora 3D, no se ve visualmente cuál es el impacto de esos competidores en nuestro proyecto. Hacer tabla comparativa de nuestro producto frente al de los competidores, para así exponer el valor que aportamos.

  • En cuanto a los riesgos, hacer tabla clasificatoria de riesgos, con su probabilidad de ocurrencia, impacto y plan de contingencia. Si pasa esto, se hace esto otro. Nada de decir "probablemente" se haga esto.

  • Commitment agreement es un documento vivo, lo que significa que cada semana hay que revisarlo y ver si se ha cumplido o no. Se puede tener un apartado donde haya una cláusula (modificar commitment agreement), que diga que todos se comprometen a realizar las tareas claves de cada semana, indicando el grado de participación de cada uno en cada tarea. Incluir cláusulas de cancelación, es decir, plantear service credits. Si alguien no llega a una determinada cantidad de trabajo, entonces que esa persona realice más trabajo la próxima semana. Tener un anexo para indicar el cumplimiento del commitment agreement. Incluir en las presentaciones una tabla con el grado de cumplimiento de cada uno de los miembros del equipo en el commitment agreement. Mantener informado al profesorado sobre esto continuamente.

Semana 3​

  • El primer punto de la diapositiva se ha pasado muy rápido.

  • De dónde salen los números del coste de licencia de GitHub. Mirar número de minutos para GitHub Actions e indicarlo. Estimar minutos de GitHub Actions para cada sprint.

  • En usuarios piloto no ha quedado claro si están contactados o no. Para la próxima semana, incluir un cuadro de mando con todos los usuarios pilotos y su estado (contactado o no contactado).

  • El análisis de competidores, muy rápido. Se puede sintetizar de manera general pero sin ir rápido. Además, es difícil conocer cuál es el aporte. Concentrar y resumir las diapositivas y resaltar nuestras características frente a los competidores.

  • Faltan incluir detalles de la planificación. Poner una diapositiva de apoyo antes de los mockups.

  • Revisar a conciencia todos los puntos a presentar en clase para que no falte nada.

  • En cuanto a las medidas de rendimiento, falta detallar exactamente los procesos a seguir y las métricas a contabilizar.

Semana 4​

  • No se ha hablado del core de nuestro sistema y de la planificación para el próximo sprint.

  • Comentar cuál es el objetivo principal de la aplicación para este primer sprint.

  • Indicar el formato de subida de imagen. Estudiar el nivel de dificultad del uso de este formato y el posible uso de plugins que cambie de formato.

  • Ha faltado incluir el planning y mencionar las IAs usadas.

  • Ha faltado el elevator pitch. Hay que vender la aplicación. Preparar un buen discurso con este objetivo.

  • Estudiar adaptar el modelo de puntuación a la nota que quiera conseguir cada uno. Por ejemplo, tenemos 100 horas y cada hora es un punto, cómo organizar la asignación de tareas.

  • Diferenciar entre CapEx y OpEx.

  • Identificar roles de una forma más concreta.

Semana 5​

  • Buena presentación.

  • No se ha seguido el orden que se mencionó en el discussion guide.

  • No ha quedado el análisis de los costes. Los salarios de los desarrolladores no es

  • OpEx. CapEx es gastos en capital y OpEx gastos en operación. Los sueldos es el

  • capital humano de la empresa. Habría que hablar de subcontratación en nuestro caso y no hablar de la organización. Nosotros no subcontratamos a nadie, el equipo de proyecto pertenece a la organización. Los gastos de capital de la propia empresa es CapEx. Si subcontratamos, estamos contratando un servicio, eso sería OpEx. El trabajador de la empresa puede trabajar en cualquier parte de la empresa, es un gasto de esta. En la actualidad, casi todos los gastos empiezan a ser de operación (OpEx), pues se subcontratan muchos servicios.

  • Poner gráfica de los costes, comparando la predicción pesimista, optimista y objetiva.

  • El estado de los riesgos no ha quedado claro, tampoco cómo se van a tratar los mismos.

  • Identificar conceptos y separarlos en las diapositivas. De esta forma, en una diapositiva, un concepto, y en otra, otro.

  • El elevator pitch ha sido muy largo.

  • Trabajar mejor el análisis de coste y hacer una predicción realista del número de suscriptores por plan. No poner el mismo número de suscriptores en todos los planes.

  • Contabilizar el número de issues comentadas. Tenemos que comunicarnos a través de GitHub. Hacer comentarios en las issues para aclarar las tareas y las soluciones que se quieran desarrollar.

  • Usar convenciones semánticas para saber si las tareas son sobre documentación, código, etc.

Semana 7​

  • Evaluar opción de reportar para combatir contra el plagio de diseños. Analizar consecuencias legales de problemas de copyright.
  • No utilizar el storyboard como killer opener. Deben coexistir las dos cosas, no pisarse entre ambas.
  • Ya que tenemos un storyboard que presenta una historia, se puede realizar un hilo conductor a lo largo de la presentación.
  • Analizar el hecho de que un diseño se difunda por un comprador, de forma que sea inútil comprar el diseño nuevamente. Debemos evitar esta casuística y fomentar la compraventa en la aplicación.
  • Seguir el orden definido en el discussion guide.
  • Dar libertad a los usuarios pilotos, en algunos casos, para que se enfrenten ellos, sin guía alguna, a la funcionalidad. Esto lo podemos hacer con ciertas funcionalidades, de forma que obtengamos un feedback más realista por parte de ellos.

Semana 8​

  • Mostrar la próxima semana el feedback más importante y una priorización de dichas tareas.
  • Mostrar los iconos constantemente en la demo para saber concretamente quién usa la aplicación.
  • Se podría enlazar el killer opener con lo que se muestra luego en la demo.
  • Monitorizar consumo de créditos del despliegue.

Semana 9​

  • Se podría implementar una IA que detecte palabras de spam.
  • En la tabla de análisis de coste, buscar alguna forma para diferenciar claramente los costes durante el desarrollo y durante la operación.
  • Buscar desarrollar una historia a la hora de mostrar la demo.
  • Uniformidad en las gráficas que se usan en la presentación.
  • Reescalar la presentación al tamaño de la pantalla.
  • Hilar el killer opener con el anuncio y con la demo. Debe ser todo muy claro.
  • Evaluar alternativas para que el audio se escuche correctamente.

Semana 10​

  • En la demo se ha intentado unir con el inicio, pero no ha resultado efectivo. Se podría haber hilado mejor con la historia del anuncio.
  • Se podría haber profundizado más en el marketing que se va a realizar.
  • Mejorar el audio de cara a próximas presentaciones.
  • El killer opener ha sido mejor que los anteriores, pero se puede seguir mejorando.
  • Los usuarios impresores son los fundamentales para hacer que funcione la aplicación. El marketing debe estar enfocado en una primera instancia a los impresores.
  • Para las pruebas de interfaz, incluir el id en los elementos que se van a probar luego. Así no se van a producir fallos en los tests al modificar la interfaz.

Semana 11​

  • Establecer el número de usuarios que significa cada estimación en la gráfica de costes frente a beneficios.
  • En el killer opener, aprovechar más la imagen del influencer, no solo mencionarlo. Los killer opener deberían tener un apoyo visual preferiblemente.
  • SHAR3D o SHAR3D, unificar la forma de decirlo.
  • A la demo le ha faltado zoom al inicio.
  • Buen discurso en la presentación de los 10 minutos.
  • La gráfica del estado del proyecto no debe estar en la presentación del World Project Launch. Debería estar en la presentación de 5 minutos.
  • En el vídeo de inversores faltan datos y opciones de inversión. Si se invierte tanto… se ganará tanto…
  • Utilizar más titulares de noticias para dar fuerza al mensaje. El actual que hay en el vídeo parece un subtítulo.
  • ¿Se podrán solapar los roles de diseñador e impresor? Introducir en los anuncios elementos para empezar a persuadir a los diseñadores.
  • Ya que se menciona que se ha hecho un sorteo en X, ver el post en las diapositivas.
  • Profundizar en el contenido que se va a subir a las redes sociales. Lo interesante es ver ejemplos en la presentación, no solo mencionarlos.
  • No poner elevator pitch como título de una diapositiva.

Semana 12​

  • En el elevator pitch no hablar de los planes antes de enseñar la demo. Primero hablar de la funcionalidad y luego mencionar los planes.
  • La demo está al límite. Hacer evidente la existencia de una necesidad para usar la aplicación. Se pide una historia en la que se siga un hilo argumental. Hay que partir de una necesidad, con esto, ver como el personaje con la necesidad descubre la aplicación, y, en la demo, ver como este personaje usa la aplicación en un caso de uso real. Todo debe ser coherente y estar dentro del mismo contexto. ¿Qué motivación tiene el personaje que compra en la demo? Mejorar la narrativa en este apartado. Hay que explicar el porqué quiere solicitar una impresión el personaje. A qué se debe esa necesidad.
  • No ir a la defensiva al recibir feedback. Analizar los comentarios que se dan y luego debatir de forma constructiva. En el caso de que no se quiera seguir el feedback, justificar los motivos detalladamente, explicando por qué otras opciones son mejores.
  • No poner términos relacionados con la asignatura en las diapositivas. Nada de CapEx, OpEx y términos similares.
  • Todos los costes relativos a una marca de tiempo, indicarlo explícitamente. Por ejemplo: 27K€/mes.
  • Se recomienda todas las cantidades reducirlas a K euros. Si la cantidad es menor, generalizar esos costes de otra forma.
  • Muy buen anuncio de inversores, aunque se hace algo largo.
  • Muy bien comentada la parte de beneficios frente a gastos.
  • Sacar la funcionalidad de la aplicación del anuncio de inversores, así como los sonidos de dinero o similares que le restan formalidad al anuncio.