Saltar al contenido principal

Grupo 5

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

Semana 1​

  1. Decisiones tecnológicas no sustentadas:

    • Las decisiones tecnológicas se tomaron sin fundamentar detenidamente las opciones.
    • Las ONGs pueden tener creado software usable.

  2. Disonancia entre lo que se dice y el contenido de la presentación:

    • En cuanto a los competidores no corresponde lo que está escrito con lo que se dice.

  3. Incongruencias con el mvp y los objetivos:

    • El mvp y los objetivos no se corresponden.

  4. Sobre los costes:

    • Es necesario incluir el coste del posible mantenimiento y despliegue en la nube.

  5. Sobre las comunicaciones:

    • Se debe formalizar la comunicación de forma más detallada para evitar que información importante no se transmita correctamente.

  6. Consideración sobre el software final:

    • Debemos tomar todas las decisiones para que al final del desarrollo se haya creado un software usable por las ONGs a largo plazo.

Semana 2​

  1. Sobre la presentación:

    • Hay que apoyarse más en las diapositivas, poniendo elementos más visuales y evitando usar la misma diapositiva durante demasiado tiempo.
    • Marcar las diaposiutivas de alguna forma si son respuesta de feedback anterior.
    • Killer opener debería estar relacionado con el proyecto.

  2. Falta el análisis de competencias:

    • No se ha incluido el análisis de competencias en la presentación.

  3. Contingencia:

    • Expresar bien el valor del porcentaje de la contingencia.

  4. Sobre los riesgos:

    • Se tiene que ser cuidadoso en los riesgos y no se deben de asumir como un hecho.
    • Matizar los riesgos y no ponerlos de forma general.

  5. Posible funcionalidad:

    • Considerar un login social para la aplicación.

Semana 3​

  • No se ha podido ver bien la señalización de los feedbacks.
  • Mockups mal distribuidos, no se veían desde el fondo bien.
  • Usar docsaurus para la documentación del proyecto.
  • Seguir revisando el agreement., cuanto más esclarecedor, objetivo y asertivo mejor.
  • Calcular precio con estimaciones y con personas de Github actions.
  • Actualizar el agreement con términos verdes, rojos, strikes, etc.
  • Considerar documentación como código.
  • Indicar en diapositiva cuánto cubre la presentación sobre lo que piden.
  • Preparar la gestión de usuarios pilotos.

Semana 4​

  • No se ha visto transparencia con las horas por miembro.
  • No se ha especificado los usuarios pilotos.
  • Poner landing page.
  • Poner toda la planificación del proyecto en vez de la del sprint.
  • Priorizar el core en el MPV.
  • TCO: Calcularlo por numero de usuarios
  • Minutos de las github actions: Calculo de de licencia, sin ser universidad.
  • Commitment: Si alguien no aspira al 10 debe de aparecer
  • Debe aparecer el responsable de cada tarea en la sección de commitment

Semana 5​

  • Aclarar qué GitHub Actions usamos, qué objetivos tienen y si tienen un impacto positivo.
  • Toda cifra que se ponga debe ser aproximada.
  • En el análisis positivo, pesimista y realista de ingresos deben aparecer porcentajes en vez de cifras exactas.
  • La matriz RACI debe considerar más roles.
  • Razonar el razonamiento detrás del individual performance.

Semana 6​

  • Cuando pongamos solución a un problema debemos añadir una tarea de seguimiento para dicha solución.
  • No evaluar todos a todos, solo a las personas con las que se trabaja.
  • Las evaluaciones entre nosotros no deberían ser anónimas.
  • Empezar a poner la versión del Commitment Agreement en las presentaciones.
  • Mejorar el tema deadlines. Se podría hacer un seguimiento de tareas durante la semana.

Semana 7​

  • La demo ha sido demasiado rápida. Estudiar la posibilidad de añadir subtítulos.
  • Los números de página son difíciles de ver.
  • Quitar lineas rojas de las tablas.
  • Customer agreement debe ser un contrato entre el cliente y los desarrolladores sobre la aplicación desplegada, no sobre el desarrollo.
  • Distinguir entre contrato de desarrollo y el customer agreement real.
  • Propiedad intelectual tiene sentido en los documentos, pero hay cosas que no.
  • Añadir gastos e ingresos a corto y medio plazo.
  • Añadir la licencia de Office en OPEX, o explicarlo bien y dejarlo en CAPEX.
  • Enseñar avances. Como mínimo mencionar los avances en una diapositiva.
  • cambiar el nombre lessons a lectures en las horas asistidas a clase.
  • Sugerencia: poner si la IA usada ha fallado o no.

Semana 8​

  • Evaluación: Indicar en el rendimiento global la fórmula usada. Además, no se ve que la fórmula actual sea efectiva.
  • Problemas: Poner el seguimiento de las soluciones. Considerar unificar problemas con retrospectiva.
  • ALM: Leyenda de Codacy no se ve bien.
  • Revisiones: Aclarar las acciones tomadas para mejorar las revisiones.
  • Tener la demo en local y ordenador de repuesto.
  • Presentación: Falta diapositiva de las horas de cada persona.
  • Mencionar como solucionar los problemas con los usuarios pilotos

Semana 9​

  • Resolucion de los problemas: ¿Cómo medimos la efectividad de una solución a un problema? Dar mas informacion de las que no estan en verde
  • Falta información de los usuarios pilotos: Poner el feedback recibido. Hablar de qué se va a abordar y qué no.
  • Cómo prepararnos para el PPL: Hacer que la ong promocione nuestra pagina en sus redes.
  • Segundo anuncio: usar otro rol como la gente que necesita la herramienta.
  • No hace falta la matriz RACI.
  • Más preparación para la demo: Establecer primero unos problemas, y partir de eso, se enseñan los usos.
  • Hablar de tipos de test que vamos a hacer.

Semana 10​

  • Considerar recortar el alcance para evitar consumir las horas de contingencia. En su alternativa reconocer las horas extra como voluntariado.
  • Probar el despliegue del grupo 11 durante el PPL.
  • Introducir la aplicación en el segundo anuncio de alguna manera.
  • Hacer fotos más formales.
  • Crear mapa de calor en el rendimiento individual para ver el progreso durante los sprints.
  • Explicar con mayor transparencia la función usada para las notas individuales.
  • Sobre los riesgos: crear métricas, umbrales y plazos sobre las acciones a tomar en respuesta a problemas o mejoras a hacer. Es decir, formalizar las acciones concretas a tomar (escribir correo, hablar con alguien), crear una medida que permita observar si funciona y un umbral objectivo que represente cuándo pretendemos tener soluciones.

Semana 11​

  • Poner las tomas falsas al final de la presentación.
  • La dema debe ser más corta y debe haber un balance entre tener una historia y mostrar las funcionalidades. Inventarse 2 o 3 personajes.
  • Poner en contexto sobre Manos Abiertas con Norte antes de poner la demo.
  • Explicar de donde vienen las graficas del plan de marketing.
  • Meter costes de marketing en la segunda presentación.
  • Business Plan: ¿Como voy a ganar dinero?
  • La tabla del TCO desentona. Al hablar de miles/millones, poner K/M.
  • El anuncio parece que es para donantes, no para inversores.

Semana 12​

  • Fluidez de la presentación es mejorable
  • Estaría bien decir en los anuncios algo como "NexONG surge a partir de la ONG Manos Abiertas" porque a veces ponemos la imagen de manos abiertas pero no la mencionamos.
  • La demo no sigue una historia. Se para en cosas no relevantes.
  • Anuncio de inversores: justificar a los inversores mediante gráficas mostrando información de los beneficios que obtendrían
  • Poner la portada de la demo en blanco.
  • Dejar de poner conceptos Capex y Opex explícitamente.
  • Poner cuantas horas a la semana se supone que trabajan los Community Manager.