Skip to main content

Informes de Feedback

Imagen 1Imagen 2

Ingeniería del Software y Práctica Profesional - Universidad de Sevilla
#

BERMEJO SORIA, CARLOS

CASAL FERRERO, RUBÉN

DOMÍNGUEZ RUIZ. ANDRÉS

DOMÍNGUEZ-ADAME RUIZ. ALBERTO

FERNÁNDEZ CASTILLO, JAVIER

GALLARDO MARTOS, DANIEL

HERRERA RAMIREZ, ISMAEL

IZQUIERDO LAVADO, MARIO

MATEOS GÓMEZ, FERNANDO JOSÉ

MERINO PALMA, ALEJANDRO JOSÉ

MONTERO MARTÍNEZ, FRANCISCO JESÚS

LÓPEZ MOYANO, ROCÍO

OTERO BARBASÁN, MANUEL

VILAPLANA DE TRÍAS, FRANCISCO DAVID

ZARZUELA REINA, CARLOS

Sevilla, Mayo 2024

Entregable: WPL#

Grupo 01 (Mañana) - IT Talent#

Control de Versiones

VersiónFechaAutorCambios
v1.08/02/24PacoDocumento inicial
v1.113/02/24PacoAdición de contenido de la 2a semana
v1.220/02/24PacoAdición de contenido de la 3a semana
v1.327/02/24PacoAdición de contenido de la 4a semana
v1.405/03/24PacoAdición de contenido de la 5a semana
v1.513/03/24PacoAdición de contenido de la 6a semana
v1.621/03/24PacoAdición de contenido de la 7a semana
v1.703/04/24PacoAdición de contenido de la 8a semana
v1.810/04/24PacoAdición de contenido de la 9a semana
v1.924/04/24PacoAdición de contenido de la 10a semana
v1.1001/05/24PacoAdición de contenido de la 11a semana
v1.1107/05/24PacoAdición de contenido de la 12a semana

Resumen del documento#

En este documento se recoge todo el feedback semanal recibido por parte de profesores y alumnos el día de la presentación a cada uno de los grupos, el feedback para nuestro equipo y las tareas que no pueden faltar de una semana a otra# Índice

1. Semana 1 (06/02) 3

Cosas a tener en cuenta 3

Consideraciones para IT TALENT 5

Tareas 6

2. Semana 2 (13/02) 7

Cosas a tener en cuenta 7

Consideraciones para IT TALENT 9

Tareas - ¿Qué no puede faltar? 10

3. Semana 3 (20/02) 11

Cosas a tener en cuenta 11

Consideraciones para IT TALENT 12

Tareas - ¿Qué no puede faltar? 13

4. Semana 4 (13/02) 15

Cosas a tener en cuenta 15

Consideraciones para IT TALENT 17

Tareas - ¿Qué no puede faltar? 18

5. Semana 7 (19/03)

Cosas a tener en cuenta

Consideraciones para IT TALENT

Tareas - ¿Qué no puede faltar?

6. Semana 8 (02/04)

Cosas a tener en cuenta

Consideraciones para IT TALENT

Tareas - ¿Qué no puede faltar?

7. Semana 9 (09/04)

Cosas a tener en cuenta

Consideraciones para IT TALENT

Tareas - ¿Qué no puede faltar?

8. Semana 10 (23/04)

Cosas a tener en cuenta

Consideraciones para IT TALENT

Tareas - ¿Qué no puede faltar?

9. Semana 11 (30/04)

Cosas a tener en cuenta

Consideraciones para IT TALENT

Tareas - ¿Qué no puede faltar?

10. Semana 12 (07/05)

Cosas a tener en cuenta

Consideraciones para IT TALENT

Tareas - ¿Qué no puede faltar?

  1. Semana 1 (06/02)

Cosas a tener en cuenta#

  1. Presentaciones siempre preparadas para una duración de 18 minutos.
  2. Durante las presentaciones, en el último minuto del feedback del grupo exponiendo el encargado del siguiente debe ir preparando su presentación en el ordenador del aula.
  3. Tener algún tipo de moderación para estafas si procede para asegurar la fiabilidad.
  4. Se debe buscar una exposición de conceptos lenta para poder madurar lo que se va diciendo.
  5. “Segmentar las ideas” de tal manera que queden claros los mensajes clave.
  6. Usar y plasmar las palabras más claves (p.e: debilidades de la competencia) durante la presentación.
  7. Es fundamental tener establecido el TCO, TC puesta en marcha y el TC de mantenimiento en el plan de manera clara y concisa.
  8. Los casos de uso de la aplicación, deben estar claramente definidos.
  9. Cuidar presentación: Numeración, letras legibles (cuidar fondos y tamaños), textos cortos y usar imágenes e iconografías.
  10. Se debe intentar que el presentador en el momento de la exposición tenga el menor número de preocupaciones ajenas a esta.
  11. Cada vez que haya un cambio de rumbo, explicar claramente las fuerzas que han llevado a cabo tomar esta decisión.
  12. Pocos objetivos pero claros y en estrecha relación con el MVP.
  13. Tener en cuenta de las horas totales que han planificado para el MVP y cada vez que se alcancen hitos en horas (i.e: 100 horas de las 2400 horas totales) se deben plasmar qué se ha usado el tiempo para asegurar el tiempo útil.
  14. Tener claro cómo se invierte el tiempo. Debe quedar plasmado en las presentaciones cuánto y en qué se va consumiendo el tiempo a cada hito/iteración/semanalmente (añadiendo captura de clockify) o el que falta para el resto de semanas .
  15. Conocer bien las capacidades financieras de los clientes.
  16. Ser coherente con lo que expones en la presentación y con lo que explicas
  17. Dar énfasis a ciertos puntos críticos de la presentación para mantener la atención del público, cambiando la entonación para que no sea demasiado monótona.
  18. Los roles no son permanentes
  19. Tener en cuenta la existencia de bots asegurando seguridad y fiabilidad.
  20. Pedir feedback de empresas grandes e incluso tener como usuarios pilotos si son parte del negocio.
  21. Organizar el tiempo para cada apartado de la presentación.
  22. Evitar permanecer demasiado tiempo en una diapositiva o dejar explicación sin soporte visual, hace complicado seguir la presentación.
  23. Nunca ponerse a la defensiva cuando se proponen ideas o dudas por parte del público. Empezar con frases como “Primero gracias por tu feedback, …”.
  24. Empezar siempre con una presentación de los ponentes y el número de grupo de forma alta y clara.
  25. Durante la presentación se debe ser “cercano y formal”, siempre cuidando los términos que se usan.
  26. Especificar a la hora de evaluar a la competencia, en caso de que nuestra alternativa lo haga mejor, QUÉ y CÓMO hace mejor que ellos.
  27. Siempre tener en cuenta el coste y planificación de trabajos “secundarios” (p.e: colocar QRs en máquinas)
  28. Exponer siempre claramente la organización y los integrantes del grupo.
  29. Tratar de homogeneizar las fotos de los participantes, que no tengan fondos muy diferentes.
  30. Dejar claro que todos los integrantes conocen la tecnología con la que van a trabajar (si no, especificar tutorial/curso que se va a proporcionar)
  31. Tener claro y exponer el número de suscripciones mínimo para que sea rentable y estable en el tiempo.
  32. Procurar eficiencia al dar información; se tiene que decir poco y bueno.
  33. El acompañante debe estar completamente atento a lo que presenta el compañero sino puede parecer que no tiene importancia lo que se expone.
  34. Hablar alto y claro, proporcionar un micrófono si fuera necesario.
  35. En vez de situar competidores o elementos en lista (de ventajas y desventajas), realizar un mapa y agruparlos por similaridad para evaluarlos de esta manera.
  36. No confundir análisis de costes con el resto de conceptos (i.e: TCO).
  37. Es esencial tener firmado el acuerdo de compromiso.
  38. En el commitment agreement, que no sea el propio afectado que ha hecho menos del 50% el que deba dejar el grupo.
  39. La política de gestión de prompts para las IAs debe ser accesible y estar organizada.
  40. Todos los miembros deben tocar algo de desarrollo.
  41. Evitar demasiados clientes distintos.
  42. Las diferencias con el resto de competidores deben quedar suficientemente claras.
  43. Tener en cuenta los costes de la plataforma (p.e: operaciones), añadir planes sobre qué hacer en caso del aumento o disminución de usuarios.
  44. Se deben identificar las responsabilidades de cada grupo de trabajo. Evaluar cómo evolucionan cada semana las responsabilidades.
  45. Explicar cuál ha sido el proceso y criterio de búsqueda con los competidores.
  46. Relacionar entre sí la matriz DAFO (p.e: Amenazas vs Fortalezas) concretamente: 1ºA, 2ºF, 3º D, 4º O
  47. Hay que hablar la base de conocimientos común.
  48. En los costes no poner los céntimos en la presentación, no es necesario ese nivel de detalle, en vez de 61.120,60€ poner 60k.
  49. NO HACER PREGUNTAS AL PÚBLICO.

Consideraciones para IT TALENT#

Las diferencias con el resto de competidores deben quedar suficientemente claras.

¿Qué pasa si el usuario tiene su perfil o repositorios privados? – Es el propio usuario, una vez envía su cv, acepta las políticas de usos de sus datos deberá también introducir su key si quiere que se use su información privada. ← Explicar en presentación.

Trataremos de tener acceso a todos los repositorios posibles en los que esa persona ha participado (teniendo en cuenta si el repositorio en el que ha participado no es suyo).

Para solucionar los problemas de privacidad cambiar el objetivo parcialmente: Que busque un talento grupal, un grupo de personas que se encarguen de una necesidad ofertada por una empresa (problema grande, real y actual), que nuestra aplicación busque al grupo completo. Sería una innovación que se busca mucho en empresas actualmente. Subir la búsqueda desde las empresas 1-1 a 1-n.

Sacar información de Stackoverflow.

Tareas#

  • Mejorar el “business statement”.
  • Menos texto y más metáforas visuales.
  • Tipo de negocio: ¿Cliente = usuario?, ¿matchmaking?
  • Mejorar análisis de coste preliminar, mirar píldoras teóricas sobre ello.
  • ¿Qué análisis se ha hecho para los competidores? Que estén como mínimo los primeros que aparecen al buscar en Google negocios similares.
  • Usuarios pilotos potenciales reales. Tener una lista a parte de los alumnos del grupo de tarde.
  • Definición del MVP con estudio de casos de uso core.
  • Mockups iniciales -> interactivos y que te diferencien de la competencia.
  • Discusión sobre la tecnología o innovación necesaria para desarrollar el proyecto
  • Refinar temas de equipo como los roles.
  • Más información sobre commitment agreement, en profundidad, darle otra vuelta.
  • Report de uso de IA – Gestión de uso de prompts (que todo el mundo los tenga prompts para poder hacer cuestiones de un mismo tema en diferentes ordenadores)
  • Análisis de riesgos preliminares. Se pondrá una píldora teórica sobre ello.

  1. Semana 2 (13/02)

Cosas a tener en cuenta#

  1. Hay que comenzar las presentaciones de manera clara con un “Impacto” inicial. Importancia de los “Killer openers”. (Hay una píldora que lo trata)
  2. Dar gran protagonismo a los casos de uso core, la idea de negocio y los mockups.
  3. Si se comparan competidores o herramientas similares se debe hacer hincapié en el elemento diferenciador.
  4. Si existen alternativas gratuitas al comparar competidores se debe justificar qué provocaría el cambio/paso a nuestra herramienta.
  5. Si es un elemento el que nos diferencia de la competencia, el pricing debería ir enfocado a este.
  6. Las promesas no deben ir al final, si no al inicio para usarlas como enganche para el público. Los mockups al final
  7. Cuando se dicen riesgos debe estar claramente identificado de qué manera podría pasar y cómo se solucionaría con detalle. (Por ejemplo, si uno es falta de conocimiento y se propone una formación, especificar la duración de la misma).
  8. Al comentar el commitment agreement, se deben exponer posibles problemas de equipo que ejemplifiquen. (Por ejemplo, si alguién no tiene una tarea tiempo, ¿Qué va a pasar?)
  9. Promover y mostrar la evolución del commitment agreement además de medir cómo se cumple. El TCO debe estar expresado de manera mensual no anual.
  10. Al exponer un riesgo es importante describirlo como un evento que puede ocurrir y describir los daños o pérdidas que causaría.
  11. Si se expone un riesgo, se presenta la solución por delante.
  12. Los análisis de costes son más inteligibles en forma de tabla.
  13. Los costes de herramientas y/o licencias de pago (por ejemplo github) deben ser tenidos en cuenta. Si es un servicio gratuito se debe exponer la existencia de un plan si este deja de serlo.
  14. Dejar claro que TODOS los integrantes han firmado el commitment agreement.
  15. No sentarse en la mesa para exponer.
  16. Un fondo negro dificulta la lectura.
  17. Uso de fuentes anchas y grandes.
  18. Al proponer precios debe quedar claro los beneficios que se están sacando (TCO).
  19. Siempre tener en cuenta el feedback de semanas anteriores al exponer. Marcar con una “F” las diapositivas que hacen referencia a este feedback.
  20. Se puede presentar un trabajo con carencias con su debida justificación pero las excusas no son efectivas en la evaluación.
  21. Tener un orden con sentido y coherencia en la presentación (No empezar exponiendo a los integrantes), comenzar exponiendo el producto.
  22. Dejar los mockups para el final.
  23. Comenzar a exponer con confianza. Uno debe creerse lo que está diciendo al presentar.
  24. Es importante tener un uso del tiempo (clockify) justificado y coherente.
  25. Hacer pública la base de conocimientos del equipo.
  26. El commitment agreement debe servir también como monitorización del riesgo. Se debe incluir en la presentación semanal y usarlo como autoevaluación.
  27. Añadir una transparencia de autoevaluación.
  28. Relacionar la tabla de riesgos y el commitment agreement.
  29. No usar la palabra “castigos” en el commitment agreement (mejor usar penalización). Es más eficiente y se funciona mejor mediante recompensas o “Service credits”.
  30. Hacer hincapié en una diapositiva si hay información relevante.
  31. Al exponer se debe buscar un término medio entre energía y rapidez.
  32. Para asegurar un uso de la aplicación en el tiempo pensar en herramientas como la gamificación.
  33. Para empatizar y sensibilizar al público dar alguna experiencia personal que enlace o sea coherente con el proyecto.
  34. La iconografía debe ser entendible o, en su defecto se debe apoyar de texto.
  35. Desarrollar los costes de contingencia.
  36. No confundir riesgos que pueden darse o no con hechos (por ejemplo, falta de conocimientos), causas (por ejemplo, la falta de conocimientos acaba retrasando un milestone) o debilidades.
  37. Incluir matriz RACI.
  38. Priorizar la originalidad, usar ChatGPT sin pasarse.
  39. Seguir un discurso lógico y una “historia” durante la exposición.
  40. Cada vez se necesita más eficiencia a medida que se añade contenido.
  41. Mockups más claros que hagan uso de toda la pantalla.
  42. Responder a lo que se espera en ese día e ir cotejándolo.
  43. Commitment agreement actualizado para que refleje que todas las tareas tienen un miembro asignado y un responsable. Debe poder usarse a la hora de cotejar que todo esté al día.
  44. Asegurar el cumplimiento del commitment agreement semanalmente, poner ejemplos con anécdotas anónimas.
  45. Seguimiento del plan de riesgos y un informe del cumplimiento.
  46. Si te pasas de horas debe haber una re-evaluación del alcance ó reducir las de otras semanas.
  47. No poner precios por hora para cada rol. Se debe poner la hora básica de servicio y realizar multiplicadores (por ejemplo, un jefe de proyecto suele cobrar un x2.5 sobre la básica).
  48. Fotos homogéneas.

Consideraciones para IT TALENT#

Uso de iconografías sin descripción en la comparación con otras empresas.

Dejar claro que el uso de RRSS para el registro es opcional, nunca se pretende ser intrusivo en la vida personal del candidato, lo último que buscamos es perturbarlo con estos análisis.

Dar mayor protagonismo a los mockups, casos de uso core y la idea de negocio.

Hay que asumir los costes de github y tenerlos en cuenta. Si asumimos que es gratuita la licencia, ¿Qué pasaría si no? ¿Cuántas github action usaremos al mes?

Se debe dejar claro de dónde sale el cálculo de precios y cuál es el beneficio que se saca de estos.

Tareas - ¿Qué no puede faltar?#

  • Presentación de 16 minutos.
  • Hablar y dejar clara la idea clave del negocio.
  • Hacer inicio efectivo de la presentación, contar en muy poco de qué va el proyecto para que inviertan en él y tratar de realizar el “elevator pitch”.
  • Hablar del tipo de negocio.
  • Dejar clara la diferencia entre usuario y cliente, ¿Quién paga?
  • Re-evaluar el análisis de competidores con el nuevo feedback.
  • Re-evaluar el análisis de costes; indirectos, oficinas, herramientas, licencias…
  • Gestión de usuarios pilotos (píldora teórica).
  • Mockups, casos de uso core e idea de negocio claros.
  • Discusión sobre la innovación que pudiera ser necesaria y stack tecnológico.
  • Elaborar análisis de riesgos (píldora teórica).
  • Fotos homogéneas.
  • Tratar el commitment agreement con el feedback que se ha dado.
  • Evaluar la manera en la que se ha hecho uso de IAs.
  • Comenzar a hablar algo del desarrollo e ir comenzando, por ejemplo:
    • Aseguramiento de la Calidad
    • Posibilidades de mejora
    • Cómo medir el rendimiento de cada miembro durante el desarrollo
    • Herramientas obligatorias para el desarrollo; github,:project, actions…,
    • Herramientas de análisis de código…
    • Evaluar el control del tiempo usado y por usar.
    • Evaluar y planear la gestión del código.
    • Evaluar y planear los despliegues múltiples.
    • Planificar qué se va a hacer en el sprint 1 y grosso modo los siguientes sprints.
  • Elaborar una página donde se hable del proyecto. Que haya enlaces y formas de contacto con responsables.

  1. Semana 3 (20/02)

Cosas a tener en cuenta#

  1. Si se realiza un Killer Opener, este debe ser corto sin demorarlo demasiado sino deja de ser efectivo.
  2. Situar la marca de feedback en la parte superior de la presentación.
  3. Al presentar los mockups debe ser en pantalla completa y realizando zoom cuando se haga referencia a partes concretas que no sean legibles al fondo de la clase.
  4. Es importante “afilar” los argumentos, sintetizar de manera que quede solo lo esencial.
  5. Al comparar con los competidores hacer énfasis en los puntos que mejora nuestra aplicación.
  6. Dejar claro el estado de la comunicación con los usuarios pilotos.
  7. Dejar claro el versionado que se usará en la gestión del código.
  8. Tener una gestión de la documentación similar a la del código con github. Por ejemplo, la presentación debería subirse como una pull request con todo el grupo como revisor.
  9. Tener un workflow para la gestión de la documentación.
  10. Se debe dejar claro que la presentación ha sido revisada y escuchada por todos los miembros del equipo y que estos han aportado su feedback.
  11. Si se han aplicado medidas para solucionar un problema hay que plasmar, evaluar y medir cómo de buenas han sido estas.
  12. Tener claros y plasmar las metas y objetivos del sprint sobre el que se trabaja y los siguientes..
  13. No quejarse NUNCA en medio de la presentación.
  14. Plasmar la refactorización de equipos en la presentación.
  15. Los costes deben aparecer junto al TCO destacando claramente este último.
  16. A la hora de enseñar datos económicos, separar claramente los costes de los beneficios.
  17. Evitar exponer un riesgo que implique el fracaso de la aplicación en la presentación.
  18. Estructurar la información de manera que sea entendible y visualmente atractiva.
  19. Valorar y revisar que cosas son mejor realizar con github pages o con docusaurus.
  20. Presentar la “landing page” con un QR visible para llamar la atención de los espectadores.
  21. Cuando un profesor da feedback sobre algo se debe aceptar y escuchar el comentario completo y más tarde clarificar si este estaba en un error.
  22. Evaluar si un índice es realmente necesario en la presentación.
  23. Ser eficientes con la información retratada en las diapositivas. (por ejemplo, evitar tablas en las comparaciones)
  24. Evitar uso de colores en las tablas.
  25. Evitar fuentes más finas sobre fondo blanco.
  26. Mencionar siempre dónde trabajan todos los miembros del equipo.
  27. Dejar claro y desglosar los costes de las licencias pertinentes.
  28. Presentar datos y estadísticas de pull request e issues.
  29. Presentar datos como de efectivo está siendo el uso de las IA y prompts.
  30. Buscar usuarios piloto que puedan elegir los roles que se ajustan a su perfil.
  31. Si hay diferentes categorías de suscripción, decirlas incrementalmente marcando con negrita las mejoras de una con respecto a la siguiente.
  32. Uso de imágenes realistas y profesionales de ejemplo en los mockups.
  33. Mirar a todo el público al exponer.
  34. Realizar plan de monitorización del feedback de usuarios piloto.
  35. Moverse y no estar de brazos cruzados cuando se expone.
  36. No incluir datos teóricos o del temario en la presentación.
  37. No usar polémicas como Killer Opener.
  38. Cotejar la autoevaluación con el grado de cumplimiento de cláusulas del commitment agreement.
  39. Expresar con gráficos y medir adecuadamente el grado de rendimiento de los miembros del grupo.
  40. Tener clara y exponer la gestión de usuarios piloto.
  41. Si hay recompensas para los usuarios piloto, debe estar recogido en el TCO.
  42. No usar fondos degradados, es complicado controlar un formato o fuente legible.

Consideraciones para IT TALENT#

  • Acortar el Killer Opener.
  • Tenemos demasiadas horas para las tres semanas de trabajo usadas.
  • Mover la marca de feedback en la parte superior.
  • Hacer zoom en los mockups.
  • No decir “BOFF ANDA QUE NO CANSA NÁ”.
  • Es importante “afilar” los argumentos, quitar la paja y dejar lo esencial.
  • Quitar la palabra “plan” del pricing.
  • Los competidores tienen una disonancia visual, destacar en los 3 puntos que vamos a trabajar como mejora del resto.
  • Dejar claro el estado de la comunicación con los usuarios pilotos.
  • Dejar clara la gestión del código, el versionado de la aplicación…
  • Tener una gestión de la documentación similar a la del código con github. Por ejemplo, la presentación debería subirse como una pull request con todo el grupo como revisor.
  • Se debe dejar claro que la presentación ha sido revisada y escuchada por todos los miembros del equipo y que estos han aportado su feedback.
  • Cambiar nombre a ITalent.
  • Uso “Opening” con 2 n’s en la presentación.
  • Medir cómo de buenas son las medidas que decidamos usar para reducir tiempo de reuniones.
  • Reflejar las metas por sprint en la presentación.
  • Hablar sobre la retrospectiva semanal de forms en la presentación.
  • Revisar arquitecturas de microservicios para ver si tienen cabida en nuestro proyecto.

Tareas - ¿Qué no puede faltar?#

  • Enseñar capturas de github; número de contributors, calculadora con los precios, actions...
  • Plasmar todas las cláusulas del commitment agreement de manera breve y marcar cada una como verde/rojo si se ha cumplido o no.
  • Plantear la documentación como código. Describir poco y bien.
  • Transparencia en la que queden claro los usuarios piloto y potenciales y el estado de las comunicaciones (contactado/pendiente de respuesta) con ellos.
  • Dejar claro si la presentación ha sido ensayada con todo el grupo y recibido feedbacks de estos en la presentación.
  • Transparencia de autodefensa ¿Cuánto cubre la presentación del total pedido para esa semana?
  • Probar a grabar la presentación, conseguir transcripción y pedir a ChatGPT como hacerla en menos tiempo o más sintetizada.
  • Presentación de 15 minutos.
  • Informar a los usuarios pilotos de cuándo vamos a tener una aplicación usable, para cuando necesitamos que la prueben y qué vamos a requerir de ellos.
  • Se proporcionará información sobre que debe estar reflejado en la presentación del feedback de los usuarios pilotos a parte de información adicional que creamos pertinente.
  • Ahora que se va a presentar desarrollo, la presentación debe ser más técnica, pero debe seguir quedando claro en ella el modelo de negocio.
  • En torno a un 15/20% se debe desarrollar el modelo de negocio:
    • Seguir elaborando Killer Opener.
    • Seguir trabajando un Elevator pitch.
    • Resumen de análisis de competidores y que nos diferencia.
    • Resumen de análisis de costes.
    • Resumen de estructura del equipo en base a roles, jerarquía…
    • Estado de cumplimiento del commitment con métricas.
  • Otro 15% el prototipo con lo desarrollado en la primera semana del sprint 1:
    • Todo lo visual.
    • El backend: Lo que se pueda mostrar de manera pertinente (ver como poner algoritmos/código)
  • 40/45% la retrospectiva de esa primera semana:
    • Metodología empleada.
    • Análisis de la calidad.
    • Transparencia con el rendimiento de miembros (anónimo) comparado: en función del rol de cada uno.
    • Exponer problemas que se han dado y eran riesgos (p.e: reuniones muy largas, efectividad programando…) con las medidas tomadas para su solución: medirlas y cuantificarlas, ¿Ha sido suficiente? ¿Debe ser mejorada la medida?
    • También decir sí hemos encontrado problemas que no eran riesgos.
    • Lecciones aprendidas.
    • Reloj de avance del proyecto (clockify): horas invertidas, diferenciar horas de clase y de trabajo en casa… E incluir links donde se ve lo que se va trabajando con las horas que ha dedicado cada uno.
  • Otro 15% la planificación o re-planificación que se haya podido dar: (interesante dejar el sprint 3 más vacío como contingencia)
    • Hablar de los objetivos del sprint 2 y como afecta a la planificación global.
  • 10% la gestión de usuarios piloto.
  • Report de gestión de IAs toma mayor importancia (copilot): cómo han ayudado o cómo NO han sido útiles, todo.

  1. Semana 4 (27/02)

Cosas a tener en cuenta#

  1. Resumen de análisis de competidores siempre debe estar presente en las presentaciones.
  2. Siempre debe haber una transparencia con la productividad por miembro del equipo (horas).
  3. Mantener siempre una diapositiva con la Landing Page con QR aunque sea en la última diapositiva.
  4. A cada sprint siempre se debe mostrar la planificación o re-planificación de los próximos sprints.
  5. En caso de tener problema valorar la posibilidad de mover tareas de un sprint a otro.
  6. Se busca una mejora de la síntesis cada semana, no se deben eliminar conceptos de una a otra.
  7. El rendimiento se debe medir individualmente y no en grupo.
  8. En la autoevaluación debe haber un análisis con métricas y números claros.
  9. Siempre que se muestren problemas en el trabajo en equipo, se deben presentar medidas que se tomarán para solventarlos con las métricas con las que se medirá la eficacia de las respuestas.
  10. El análisis de competidores debe estar más sintetizado, parándose en los 3 más similares a nuestra plataforma, focalizando en la característica más “killer”.
  11. El elevator pitch debe estar siempre claramente presente.
  12. No confundir coste de mantenimiento con coste de operación, el mantenimiento puede ser por ejemplo el correctivo (para posibles fallos) o aumentativo (hay suficiente dinero como para hacer añadidos).
  13. Cuidar y evitar las muletillas.
  14. Siempre cuidar y tener claro el hilo de la presentación. Debe de haber coherencia entre los puntos y no dejar conceptos sueltos.
  15. Se debe dejar claro la planificación de cada sprint, sobre todo si ha habido problemas de rendimiento en una semana, ¿Cómo afectan estas carencias a los próximos sprints?
  16. No basta con mostrar los problemas que ha habido durante la semana de trabajo, se debe mostrar siempre el análisis de riesgos inicial.
  17. Durante el desarrollo dar preferencia a las funcionalidades core o del MVP, por ejemplo, si el login es secundario no debería estar siendo desarrollado en el primer sprint cuando el objetivo es acabar el MVP.
  18. Cuanto mayores son los números en cuanto a ROI mayor debe ser el Elevator Pitch, orientado a estos números. Si son poco realistas deben ser repensados.
  19. Debe quedar reflejado en la presentación que cuando no se llega el trabajo planificado se ha incumplido alguna cláusula del Commitment Agreement.
  20. El rendimiento no es la inversión del tiempo si no el uso efectivo del mismo.
  21. En el Commitment Agreement se debe plasmar si se ha logrado los objetivos, sin tener que ver con el número de horas, si no con el rendimiento de estas y si han aportado al desarrollo final.
  22. No olvidar que es el moderador quien lleva el conteo del tiempo (fuera de evaluación) de las presentaciones.
  23. Siempre incluir los estados de la comunicación y gestión de usuarios pilotos.
  24. Hablar de porcentajes del número de usuarios que tienen que usar nuestra aplicación (TCO) con respecto al número de usuarios potenciales.
  25. Si no se llega al 100% del trabajo que se pedía, se debe justificar con un motivo de peso o penalizaciones sobre el Commitment Agreement o la evaluación grupal de la persona implicada.
  26. Reflejar en el Commitment Agreement cuando personas tiene penalizaciones o “ya no van a por el 10”
  27. Si se dicen las tareas que ha hecho cada subgrupo deben ir acompañadas de un diagrama de gantt simplificado o similar en el que se vean para cuando estaba planificada cada una.
  28. No mezclar la retrospectiva con la autoevaluación.
  29. Si hay una propuesta de mejora se debe decir cómo se va a medir de antemano, antes de tomar la medida.
  30. Indicar con triángulos hacia arriba o abajo cuando haya habido rendimiento positivo o negativo en la retrospectiva.
  31. Pensar en si es mejor una DEMO grabada o en directo.
  32. El testing no puede estar presente solamente en el sprint 3, deben ser FAST, se deben hacer a lo largo de todos los sprints.
  33. El TCO debe ser mensual, no global (anual).
  34. Deben quedar claro los responsables de una tarea.
  35. No suspirar a lo largo de la presentación, da sensación de agotamiento de lo que se está contando.
  36. Aclarar y enlazar el Killer Opener con el inicio y el resto de la presentación.
  37. Falta claridad en el TCO. Se necesita definir un marco de tiempo (time frame) y una capacidad de demanda nominal para comprender mejor cómo se comportará el sistema en diferentes condiciones de uso, en resumen, cómo escalará. No solo se trata de cuántos usuarios pueden usarlo al mismo tiempo, sino también de cuándo y con qué nivel de demanda.
  38. En la presentación deben quedar claros los análisis del rendimiento y los límites operativos de github (github actions) para justificar el plan que necesitamos. Por ejemplo, cuánto tarda en evaluar a X usuarios para formar un grupo.
  39. Las métricas del rendimiento debe ser capaz de comparar cada miembro del equipo y los datos obtenidos deben ser cotejados para evaluar al final de cada sprint. Para los que programan es sencillo; nº de commits… Pero ¿Cómo se está midiendo el rendimiento de la persona que coordina?
  40. El DAFO ya no merece la pena incluirlo en la presentación.
  41. El número de usuarios que necesitamos para mantener la aplicación debe tener porcentajes con respecto al número de personas en el sector en Sevilla por ejemplo.
  42. No meter una imagen de un QR si no es funcional o al menos aclarar que no lo es.
  43. Usar recursos en la presentación como líneas o subrayados para corresponder con lo que se dice.
  44. Recordar que como presentador no recae en uno las responsabilidades del grupo al completo, disfrutar de la presentación.
  45. Evitar sobrecarga en las presentaciones, buscar la simplicidad y la correlación entre diapositivas.
  46. Se debe ser coherente lo que se refleja en la diapositiva con lo que pone en el título.
  47. Aunque se realice un Killer Opener, los presentadores deben decir sus nombres.
  48. Marcar más el reconocimiento que se dice que se tiene sobre el Commitment Agreement. Poner un pódium con los nombres.
  49. Evitar letras blancas sobre colores claros.
  50. Las DEMOS de los prototipos se deben ver bien, hacer zoom.
  51. Si hay datos en el tiempo (días) poner como apoyo visual un calendario.

Consideraciones para IT TALENT#

  • No suspirar a lo largo de la presentación, da sensación de agotamiento de lo que se está contando.
  • Aclarar y enlazar el Killer Opener con el inicio y el resto de la presentación.
  • Falta claridad en el TCO. Se necesita definir un marco de tiempo (time frame) y una capacidad de demanda nominal para comprender mejor cómo se comportará el sistema en diferentes condiciones de uso, en resumen, cómo escalará. No solo se trata de cuántos usuarios pueden usarlo al mismo tiempo, sino también de cuándo y con qué nivel de demanda.
  • Hablar en profundidad de nuestra gestión de la documentación, mostrar el versionado de documentos que se lleva internamente.
  • En la presentación deben quedar claros los análisis del rendimiento y los límites operativos de github (github actions) para justificar el plan que necesitamos. Por ejemplo, cuánto tarda en evaluar a X usuarios para formar un grupo.
  • La tabla de TEAM PERFORMANCE está bien, no cambiarla demasiado, pero le ha faltado la performance individual.
  • Faltan gráficas y métricas del rendimiento por cada integrante del equipo (anónimo).
  • Las métricas del rendimiento debe ser capaz de comparar cada miembro del equipo y los datos obtenidos deben ser cotejados para evaluar al final de cada sprint. Para los que programan es sencillo; nº de commits… Pero ¿Cómo se está midiendo el rendimiento de la persona que coordina?
  • El DAFO ya no merece la pena incluirlo en la presentación.
  • Diferencias entre gitflow y goldenflow y decir cual nos merece la pena usar.
  • El número de usuarios que necesitamos para mantener la aplicación debe tener porcentajes con respecto al número de personas en el sector en Sevilla por ejemplo.
  • Pensar en si es mejor una DEMO grabada o en directo.
  • Marcar más el reconocimiento que se dice que se tiene sobre el CA. Poner un pódium con los nombres.

#

Tareas - ¿Qué no puede faltar?#

  • Falta claridad en el TCO. Se necesita definir un marco de tiempo (time frame) y una capacidad de demanda nominal para comprender mejor cómo se comportará el sistema en diferentes condiciones de uso, en resumen, cómo escalará. No solo se trata de cuántos usuarios pueden usarlo al mismo tiempo, sino también de cuándo y con qué nivel de demanda.

estaría bien decir el

sistema de memoria planteado para minimizar el número de llamadas

  • En la presentación deben quedar claros los análisis del rendimiento y los límites operativos de github (github actions) para justificar el plan que necesitamos. Por ejemplo, cuánto tarda en evaluar a X usuarios para formar un grupo.
  • La tabla de TEAM PERFORMANCE está bien, no cambiarla demasiado, pero le ha faltado la performance individual.
  • Faltan gráficas y métricas del rendimiento por cada integrante del equipo (anónimo).
  • Las métricas del rendimiento debe ser capaz de comparar cada miembro del equipo y los datos obtenidos deben ser cotejados para evaluar al final de cada sprint. Para los que programan es sencillo; nº de commits… Pero ¿Cómo se está midiendo el rendimiento de la persona que coordina?
  • Diferencias entre gitflow y goldenflow y decir cual nos merece la pena usar.
  • El número de usuarios que necesitamos para mantener la aplicación debe tener porcentajes con respecto al número de personas en el sector en Sevilla por ejemplo.
  • Pensar en si es mejor una DEMO grabada o en directo.
  • Una vez que calculas el coste al mes por X usuarios se debe analizar cómo cambia el coste necesario si se duplican, triplican, bajan… el número de usuarios. Plantearlo para finiquitar el TCO para el resto de sprints.
  • Si algún miembro ya no aspira al 10 con respecto al CA se debe indicar en la presentación.
  • Poner los responsables de las tareas en la presentación y confirmar que está reflejado en el CA.
  • El orden de la presentación debe ser similar entre grupos, concretamente:
  1. 15% INTRODUCCIÓN proyecto:
    1. Killer Opener
    2. Elevator Pitch
    3. Resumen Análisis de competidores
    4. Resumen de TCO:
      1. Capex: coste desarrollo, licencias, personal de la empresa, portátil, amortización por varios projects…
      2. Opex: gastos hosting e infraestructura, customs, mantenimiento, ventas-marketing-anuncios, maquinaVM en la nube, mejoras, support, ventas para el cliente, copilot
      3. PORCENTAJE DE CAPEX VS OPEX EN GRANDE.
    5. Situación actual del presupuesto gastado vs TOTAL esperado.
    6. Estimaciones corto (4 /6 meses) y largo (12/24 meses) plazo de ingresos y medir el número de usuarios e ingresos divididas en pesimistas, optimistas y realistas.
    7. Refinar los roles de equipo, composición y jerarquía.
    8. Estado de cumplimiento del CA.
  2. 15% DEMO FINAL del sprint 1 con casos de uso core terminados.
  3. 40 % RETROSPECTIVA del sprint 1:
    1. Rendimiento del equipo (mejora/empeora, fórmulas) . POR MIEMBRO.
    2. Codacy, Sonar, algo de la Gestión de la Calidad del código.
    3. Gestión de riesgos.
    4. Control del rendimiento de las medidas tomadas. Si se ha encontrado un nuevo problema, proponer la solución y decir cómo se medirá el rendimiento cuando se emplee en el próximo sprint.
    5. Lecciones aprendidas.
    6. Reloj de avance del proyecto / Clockify.
  4. USUARIOS PILOTO:
    1. Gestión de usuarios; feedback… a nivel mensual.
    2. Cuando vamos a entregar el MVP y cuando necesitamos el feedback + planificar el segundo sprint en este asunto
  5. PLANIFICACIÓN:
    1. De esta semana y el sprint 2. ¿Hará falta re-planificación?
    2. Planificación del 3. ¿Hará falta re-planificación?
  6. REPORT DE USO DE IA
  7. Última diapositiva: QR Landingpage. Con nuestros datos de contacto.

Semana 5 (5/03)

Cosas a tener en cuenta#

  1. Evitar capturas de documentos, no son legibles al fondo de la clase.
  2. Tener demos grabadas, sobre todo para las jornadas de evaluación.
  3. Las estimaciones a futuro NO pueden ser lineales, datos como el número de usuarios deben hacer fluctuar los datos.
  4. Evitar colores claros sobre blanco en los gráficos y poner etiquetas en cada eje.
  5. Poner la estimación de gastos e ingresos con una gráfica, evitar tablas con muchos datos numéricos o simplificarlas (pesimista, optimista...)
  6. La estructura del equipo, jerarquía… Debe estar siempre presente.
  7. No mezclar conceptos como el grado de cumplimiento y el análisis de rendimiento.
  8. Decir los milestones en la presentación** para próximas semanas/sprints.
  9. Evitar diapositivas con mucho texto y usar iconografías.
  10. Añadir gráfico con los gajos de horas individuales de clockify.
  11. Para en la demo empezar por lo más importante, no el login.
  12. Evitar hacer uso innecesario de plataformas de comunicación ajenas a GitHub, cambiarlo por el uso de comentarios de github o portales.
  13. No poner títulos en inglés y español en las diapositivas
  14. No confundir “Coste Total” con TCO.
  15. Hacer usos de herramientas que proporcionan aplicaciones como clockify para los gráficos, no realizar esfuerzo extra.
  16. Un problema no es hacer uso de más horas para una tarea, sino mala asignación de tareas.
  17. Respetar el orden que se dijo en las clases para la presentación.
  18. Estimaciones de usuarios (optimistas, pesimistas, realistas) con análisis PERT.
  19. No poner el rellenado de los registros en la DEMO de la aplicación
  20. Realizar un pseudo gantt en la retrospectiva del sprint con las tareas que se han realizado en este.
  21. La matriz RACI no se debe mostrar, desarrollar su contenido cuando se habla de la gestión del código en GitHub.
  22. El uso de las github actions debe estar desarrollado, en qué se están usando.
  23. Cada integrante debe saber la justificación de su nota en el sprint. Sobre todo si la nota es baja; se debe hablar con el integrante lo haya pedido este o no.
  24. Desarrollar en la presentación cuál es el “rational” de las diferencias en el cálculo del rendimiento de coordinadores e integrantes.

Consideraciones para IT TALENT#

  • Eliminar la captura del formulario, no es legible.
  • Falta un Elevator pitch claro.
  • Cambiar MPV por MVP.
  • Tener una demo grabada.
  • Para en la demo empezar por lo más importante, no el login.
  • Demasiados datos en el TCO, hacen complejo entender y seguir la presentación.
  • Las estimaciones a futuro (BUDGET) NO pueden ser lineales, datos como el número de usuarios deben hacer fluctuar los datos.
  • Evitar colores claros sobre blanco en los gráficos y poner etiquetas en cada eje.
  • Hacer poner la clave de github (API) al cliente es arriesgado si la empresa es la que tiene que hacer los análisis. Sobre todo si el cliente ya usa su api para otras cosas, el requisito de uso es demasiado alto, no es profesional.
  • Estimar el número de peticiones que se deberían hacer en total y decir cuánto nos costaría con la responsabilidad de usar la API nosotros.
  • Deberíamos haber hecho el análisis de la capacidad de peticiones, para estimar el nº de peticiones óptimo para los clientes en los diferentes planes de subscripción.
  • Tendríamos que hacer el análisis económico de las peticiones que harán los clientes.
  • Estimaciones de usuarios (optimistas, pesimistas, realistas) más simple, realizar análisis PERT.
  • Realizar un pseudo gantt en la retrospectiva del sprint con las tareas que se han realizado en este.
  • Incluir documentación en el repositorio o en un docusaurus.
  • Añadir los contributing.md al repositorio.
  • Tiempo de visualización de los videos de las píldoras en el clockify.

Tareas - ¿Qué no puede faltar?#

  • Toda la documentación en una carpeta docs en el repositorio de github o en un docusaurus, usar IAs para pasar a Markdown o para hacer uso de la documentación de manera más ágil (poner comentarios…). Pensar si hacer un despliegue de esta en app engine. Incluir la documentación de los entregables en el docusaurio.
  • Hacer uso de conventional commits con metainformación en los mensajes (tipo, milestones…).
  • Para la semana que viene Presentación de retrospectiva de unos 15 minutos con:
  1. Tablas con horas.
  2. Tareas que hemos hecho.
  3. Rendimiento del equipo.
  4. Mecánicas de trabajo.
  5. Commitment agreement, ¿Se cumple? ¿Modificaciones?
  6. …
  • Para dentro de 2 semanas:
  1. INTRODUCCIÓN:
    1. Killer opener
    2. Elevator pitch
    3. Análisis de competidores
  2. Storyboard (píldora teórica) de un anuncio para uno de los clientes. (Representantes o Candidatos)
  3. Impacto Legal del proyecto – Incluir Customer Agreement. (Licencias, aspectos legales que nos afectan…)
  4. COSTES:
    1. TCO
    2. Capex vs Opex
    3. Costes GActions
    4. Cuanto llevamos gastado con respecto al Total
    5. Estimaciones pesimistas, optimistas… Con respecto al número de usuarios
  5. Refinar estructura de equipo
  6. DEMO dinámica sprint 2 - Resaltar que estaba en el S1 y que hemos hecho nuevo**
  7. RETROSPECTIVA:
    1. Rendimiento del equipo, desarrollando las fórmulas
    2. ALM: Automatización del código (ALM pill)
    3. Evolución de la calidad del código, Sonar, Codacy… ver incremento y decremento de métricas.
    4. Gestión de riesgos, riesgos que se han dado, problemas que no eran riesgos: Medidas, métricas, planes…
    5. Lecciones Aprendidas
    6. Reloj de avance de proyecto, clockify semanal y global
  8. Gestión de Usuarios Piloto. – Gestión del feedback (demostrar que el usuario ha sido escuchado)
  9. Re-estimación del sprint 2 (tema documentos si quitan tiempo) y global del 3:
    1. Objetivos del 2: Incluir algo de Pagos / pasarelas de pago
    2. ¿Qué queda para el 3er sprint?
  10. Uso de IA
  11. QR landing page

Semana 7 (19/03)

Cosas a tener en cuenta#

  1. Validar los correos electrónicos mediante alguna API y añadir los costes de esta al Opex.
  2. Storyboards en blanco y negro poniendo en color lo que queramos destacar.
  3. Si se trabaja en horario no lectivo con otros grupos debe ser por previo acuerdo entre ambas partes.
  4. No confundir los acuerdos con los usuarios pilotos con el Customer Agreement, no son lo mismo.
  5. A partir de ahora siempre deben aparecer los términos legales y políticas de usuario.
  6. En las demostraciones no pueden aparecer nombres de ejemplo como “Usuario1” o “admin”.
  7. Si se recorta el alcance se debe justificar, no solo por un “paso de horas” sino por qué se ha dado.
  8. No usar líneas rojas en tablas en la presentación.
  9. Se deben buscar siempre representaciones gráficas para los costes, evitar el uso de tablas en la medida de lo posible.
  10. Los costes de las GActions no pueden faltar nunca en la presentación pero el desglose puede no estar presente.
  11. Se debe saber desarrollar/justificar todas las columnas que aparecen en la tabla del análisis de competidores.
  12. En la universidad se imparten “Lectures” no “Lessons”.
  13. Realizar el desarrollo a partir de mocks para que el frontend pueda trabajar independientemente del backend.
  14. Si es una demo auto explicativa se debe introducir adecuadamente para poner atención desde un principio.
  15. En el storyboard se debe centrar en lo que diferencia del resto de la competencia.
  16. En la presentación debe aparecer una gráfica de puntos de historia vs tiempo consumido.
  17. Para medir la eficiencia de los tests, contar en base a los fallos que saltan con estos. También es buena practica poner los fallos a posta para que estos salten.
  18. No confundir los términos Contrato y Acuerdo, los contratos tienen términos y componentes legales.

Consideraciones para IT TALENT#

  • Evitar uso de fuentes oscuras sobre fondos oscuros.
  • En la DEMO hay letras muy pequeñas, por lo que es necesario hacer uso de zoom en el video.
  • Pensar en usar colores más claros para la DEMO únicamente, manteniendo los colores en la aplicación original.
  • Storyboards en blanco y negro poniendo en color lo que queramos destacar.
  • Los presupuestos expuestos están demasiado centrados en el desarrollo.
  • La grafica del Budget sobra con la otra grafica de costes y beneficios.
  • Revisitar el tema de las métricas que se está usando para medir el rendimiento. Separar el número de horas en el rendimiento, no confundir con el esfuerzo.
  • Revisar los usuarios pilotos que no responden y acotar los que sean menos probables.
  • El elevator pitch debe estar más presente. No solamente como una frase introductoria. (como musclemate, qué ofrecemos nosotros que otros no)
  • En el storyboard del empresario buscar destacar la característica que nos diferencia (le hagan falta 5 personas para YA con unas especificaciones CONCRETAS).
  • Dar coherencia a la presentación de manera que si mostramos a unos actores en el storyboard, usarlo como recurso a lo largo de la presentación, en por ejemplo en la demo…
  • Validar los correos electrónicos mediante alguna API y añadir los costes de esta al Opex (No estoy seguro de que correos se refería, si a los de las empresas o a los usuarios de la aplicación en general).
  • Hacer gráfica de puntos de historia vs tiempo consumido.
  • Para medir la eficiencia de los tests, contar en base a los fallos que saltan con estos. También es buena practica poner los fallos a posta para que estos salten.
  • Capex, costes de desarrollo, mostrar multiplicador por cada rol (sobre la hora de servicio mínima) (Para este parto sobre los comentarios de Müller de Ocial, destacó especialmente esta diapositiva).

Tareas - ¿Qué no puede faltar?#

  • Hablar del commitment agreement de los usuarios pilotos.
  • Justificar recortes de alcance.
  • Es obligatorio meter en las issues a los encargados de revisión.
  • Hacer números sobre el uso de la IA, si se esta usando: ¿Cuánto tiempo nos está ahorrando? (número de horas), si se dan errores en las consultas ¿Cuántos refinamientos han hecho falta?, ¿El uso repetido te esta formando para ingeniería prompt?...
  • Las mejoras y adiciones sobre el sprint anterior deben estar claras.
    • Hacer análisis de los conventional commits para evaluar las mejoras: contar número de fixs…
  • De deben ver ya las pasarelas de pago y que aparezcan los acuerdos.
  • La evolución del opex debe ser no lineal
  • Tener y mostrar un calendario compartido para ver las horas libres para las reuniones.
  1. INTRODUCCIÓN:
    1. Killer opener
    2. Elevator pitch, con un par de frases predefinidas. Recordar que se busca convencer a los inversores.
    3. Análisis de competidores, centrarnos en las features killer y pasar poco por el resto.
  2. Storyboards
  3. Impacto Legal del proyecto – Customer agreement, GDPR, licencias, aspectos legales...
  4. COSTES:
    1. TCO
    2. Capex vs Opex
    3. Costes GActions
    4. Cuanto llevamos gastado con respecto al Total
    5. Estimaciones pesimistas, optimistas… Con respecto al número de usuarios
  5. Refinar estructura de equipo
    1. Estado del Commitment Agreement
  6. DEMO dinámica sprint 2 - Resaltar que estaba en el S1 y que hemos hecho nuevo** con el resto feedback; casos de uso corse, historias de usuario, imágenes reales…
  7. RETROSPECTIVA:
    1. Rendimiento del equipo, desarrollando las fórmulas
    2. ALM (ALM pill)
    3. Evolución de la calidad del código, Sonar, Codacy… ver incremento y decremento de métricas.
    4. Gestión de riesgos, riesgos que se han dado, problemas que no eran riesgos: Medidas, métricas, planes…
    5. Lecciones Aprendidas
    6. Reloj de avance de proyecto, clockify semanal y global
  8. Gestión de Usuarios Piloto.
    1. Gestión del feedback (demostrar que el usuario está siendo escuchado)
    2. Resumen del feedback proporcionado
    3. Acciones de consolidación que se han tomado a partir de ese feedback
    4. Planes con los usuarios piloto para el S3
    5. Commitment Agreement con los usuarios piotos
  9. Re-estimación del sprint 3:
    1. Justificar si hemos tenido que reducir el alcance
    2. Objetivos del 2: Sandbox de pago / pasarelas de pago
    3. ¿Qué queda para el 3er sprint?
  10. Uso de IA
  11. QR landing page

Semana 8 (02/04)

Cosas a tener en cuenta#

  1. En diapositivas que contenga gráficas se debe parar un mínimo para explicarlas.
  2. Uso de datos y descripciones realistas en las demos.
  3. Cuidar formatos en las diapositivas que hagan las letras más pequeñas, pueden hacerlas ilegibles.
  4. Siempre hacer algún comentario o explicar brevemente los análisis del ALN.
  5. Si se da un problema siempre se debe especificar el estado del mismo.
  6. Evitar empezar la retrospectiva de un sprint con los problemas que ha habido durante este.
  7. Si falla algo en un sprint, al final del siguiente hacer especial interés en que se ha tenido en cuenta y se ha realizado alguna medida con métricas.
  8. Añadir el numero de refinamientos en las IAs.
  9. No usar encabezados de “BIENVENIDO A…” con una descripción de los servicios en la aplicación, eso sería contenido de la Landing Page.
  10. Evitar moverse demasiado a la hora de realizar la presentación, hay que buscar un punto medio entre energía y serenidad, también en ritmos de presentación.
  11. Mostrar los análisis del código en vivo es una buena práctica.
  12. A mayor número de clientes los costes de mantenimiento deben subir.
  13. Añadir una matriz con el esfuerzo en horas y el rendimiento con nuestra fórmulas y los integrantes en ella.
  14. Se debe tener cuidado de no fomentar trabajar menos con la gamificación en el desarrollo.
  15. Las funciones listadas con botones queda poco profesional se debe buscar meter gráficas y otras disposiciones.
  16. Siempre se deben exponer los problemas que ha habido y se han solucionado, los que están por solucionar y las soluciones propuestas.
  17. Si se muestran gráficas se debe como mínimo hacer alguna conclusión de esta.
  18. La recepción del feedback de los usuarios pilotos debe ser lo antes posible para poder ejercer los cambios necesarios antes del entregable.

Consideraciones para IT TALENT#

  • Usar como Killer Opener ISPP y crear grupos de trabajo para el desarrollo y en la DEMO; “Javi, como coordinador quiere crear un grupo de trabajo con X necesidades y para ello…”.
  • Introducir los objetivos de la demo al comienzo del video y poner un icono representando al usuario/representante (yo diría de poner un texto que se vea todo el rato mientras se hable de Candidatos o Representatives)
  • El storyboard es poco creíble, un programador de Cobol no debería tener problemas de falta de trabajo.
  • Usar más gráficas, “modo resumen” y más visuales, en las estadísticas de GitHub de los candidatos.
  • Dejar más claro el estado de los problemas que ha habido, meter iconografías si estos están solucionados o en proceso de serlo. Con mayor focus en las métricas.
  • La planificación del Sprint 3 queda muy escueta.
  • Realizar cambios sobre el workflow del feedback de los usuarios pilotos, se debe de ver más claro.
  • Añadir el numero de refinamientos necesarios en el report de las IAs.

Tareas - ¿Qué no puede faltar?#

  • Nueva versión del Failure Conditions
  • Hay enlaces para los dashboard de BlueJ (no influye en la nota) pero se puede usar para meterlo en la presentación.
  1. INTRODUCCIÓN:
    1. Killer opener
    2. Elevator pitch, con un par de frases predefinidas. Recordar que se busca convencer a los inversores.
    3. Análisis de competidores, centrarnos en las features killer y pasar poco por el resto.
  2. Storyboards + ANUNCIO en vivo de uno de ellos
  3. Impacto Legal del proyecto
  4. Customer agreement
    1. Desarrollar Términos de servicios
    2. Uso de Claudette: ¿Qué cláusulas se han eliminado? ¿Cuáles no?
    3. Pricing
    4. SLA: Implicaciones de estas en la implementacion (Cambios en el TCO por personal de soporte adicional por una subida de usuarios)
  5. COSTES:
    1. TCO a 2 años
    2. Capex vs Opex
    3. Costes GActions
    4. Cuanto llevamos gastado con respecto al Total
    5. Estimaciones pesimistas, optimistas… Con respecto al número de usuarios
  6. Refinar estructura de equipo:
    1. Estado del Commitment Agreement + Historial de este, ¿Cuándo y por qué no se ha cumplido?
  7. DEMO dinámica** sprint 3:
    1. Resaltar que estaba en el S1 y S2 y que hemos hecho nuevo con el resto feedback.
    2. Mejoras de UX (píldora teórica).
    3. Registro con términos y condiciones + Cosas de GDPR implementadas.
    4. Implementación de aspectos legales (P.E: ¿cookies?...)
  8. RETROSPECTIVA:
    1. Evolución de la calidad del código, Sonar, Codacy… ver incremento y decremento de métricas.
    2. Rendimiento del equipo, desarrollando las fórmulas.
      1. Matriz de HORAS vs RENDIMIENTO con todos los integrantes.
    3. Gráfica de productividad y evolución.
    4. Mejoras de agendamiento y calendario compartido: ¿Cómo y cuánto nos han ayudado?
    5. Plan de pruebas, píldora de testing, planes de aquí al Proyect Launch.
    6. Gestión de riesgos: Riesgos que se han dado + problemas que no eran riesgos: Medidas, métricas, planes…
    7. Lecciones Aprendidas
    8. (Reloj de avance de proyecto, clockify semanal y global) ¿breve? - no tengo apuntado que lo dijera, pero igual se le pasó
    9. Changelog (evaluar meterlo en la demo) - Qué se ha incrementado con respecto a la semana anterior.
  9. Gestión de Usuarios Piloto.
    1. Gestión del feedback (demostrar que el usuario está siendo escuchado)
    2. Resumen del feedback proporcionado
    3. ¿Qué prioridad se le ha dado a cada cambio necesario y por qué?
    4. Acciones de consolidación que se han tomado a partir de ese feedback
    5. Desarrollar Commitment Agreement con los usuarios piotos
  10. PLANIFICACIÓN:
    1. Issues previstas para este sprint + las que ya serán para futuras mejoras (quedan fuera del desarrollo actual)
    2. Objetivos para la demo final.
    3. Objetivos del 3: Registro, Pagos...
    4. Hacer planificación preliminar de la siguiente fase
  11. Uso de IA
  12. QR landing page

Semana 9 (09/04)

Cosas a tener en cuenta#

  1. Cuidar la velocidad con la que se cuenta la información, sobre todo para personas que no conocen la aplicación o nunca han visto la presentación antes. Evaluar si reducir el nivel de detalle/contenido por apartado.
  2. Cuidar el formato de la presentación para que se adecúe al aula en la que se va a exponer, si no da la sensación de mala calidez o cutrez.
  3. Es crucial añadir indicadores a los problemas que se presenten (si hay colisiones en el frontend, indicar el número).
  4. NO añadir información redundante en la DEMO (p.ej: edición de campos o registro).
  5. Mencionar primero la fórmula del rendimiento y luego el rendimiento del equipo.
  6. Añadir el número total de pruebas que se van a realizar a cada característica.
  7. No es necesario comentar los problemas que van bien, sobre todo si hay falta de tiempo o varios que mencionar.
  8. Evitar añadir demasiada información que den contexto del proyecto, sobre todo si al mismo tiempo se está exponiendo lo mismo.
  9. Hacer un seguimiento de las funcionalidades que los usuarios pilotos consideran más interesantes/importantes. Realizar un orden de estas.
  10. Si se añade texto en los anuncios debe haber tiempo suficiente para leerlo o debe ser un texto lo suficientemente breve.
  11. No hacer uso de imágenes poco realistas para fotos en la demo, si se usan IAs hacer uso de alguna fotorrealista.
  12. Cuidar la escala de gráficas y añadir prefijos como K o M.

Consideraciones para IT TALENT#

  • Cuidar la iluminación del anuncio así como la vocalización y velocidad del diálogo.
  • ¿SON LOS CORRECTOS USUARIOS POTENCIALES? Hay que cambiar el enfoque, la búsqueda de trabajo es constante
  • Añadir diapositivas de apoyo para el Customer Agreement (Diapositiva: SLA + TOS).
  • Especificar los datos de la diapositiva Capex vs Opex. Y añadir datos de usuarios empleados que se registrarían en la aplicación.
  • Pararse brevemente a explicar qué es cada cláusulas del Commitment Agreement.
  • En la DEMO pararse en las funcionalidades core y no mencionar la edición/eliminación de perfiles.
  • Al subir el ritmo del diálogo se deja de seguir el ritmo de la presentación y se pierden conceptos.
  • Para cada gráfico (a partir de la 37) o dato que se enseñe, prepararse una frase que resuma el gráfico (p.ej: ha habido un aumento del rendimiento del 4%) o plasmarlo en la misma diapositiva.
  • La gráfica de rendimiento individual no refleja bien la diferencia con respecto de una semana a otra, si se quiere plasmar eso habría que cambiar la forma de enseñarlo.
  • La DEMO debe estar más orientada al anuncio, que Javi salga en el anuncio como jefe y luego salga igual en la foto de perfil de la DEMO.
  • Se debe plasmar si los tests están siendo efectivos o no (inventarse fallos o realizar test que se sabe que van a fallar).
  • Añadir el numero de refinamientos necesarios en el report de las IAs.
  • Meter acciones de consolidación en la Base de Conocimientos
  • Tener un apartado de la DEMO en el Docusaurio (link a Youtube…).
  • Añadir apoyo para los SLA y ToS (Customer Agreement)
  • Incluir los ToS en el registro.
  • Añadir el feedback específico nos han dado los Usuarios Pilotos. A cada feedback que se mencione que han aportado los usuarios piloto añadir la prioridad que se le ha asignado.
  • A Muller le gustó que: Para cada problema: OPEN, NOT SOLVED, IN PROGRESS, SOLVED
  • Muller mencionó que es buena practica realizar pruebas de carga que muestren cuantás peticiones son necesarias para agotar los créditos de Google.
  • A Muller le gustó: Segmentación de mercado de cara al proyect launch (píldora teórica).

Tareas - ¿Qué no puede faltar?#

  • Nueva versión del Failure Conditions
  1. INTRODUCCIÓN:
    1. Killer opener
    2. Elevator pitch, con un par de frases predefinidas. Recordar que se busca convencer a los inversores.
    3. Análisis de competidores, centrarnos en las features killer y pasar poco por el resto.
  2. Storyboards + ANUNCIO en vivo de uno de ellos (Volver a incluirla especificando si se ha modificado algo, también se puede ir añadiendo el siguiente).
  3. Impacto Legal del proyecto
  4. Customer agreement
    1. Uso de Claudette: ¿Qué cláusulas se han tenido que modificar? ¿Cómo?
    2. Pricing
    3. ToS
    4. SLA: Implicaciones de estas en la implementacion (Cambios en el TCO por personal de soporte adicional por una subida de usuarios)
  5. Estrategias de marketing preliminares puntuales:
    1. ¿Qué hacer para ganar tracción en el mercado?: segmentación
    2. ¿A quién nos vamos a enfocar? ¿Cómo vamos a hacer para que se enfoque a ese perfil?
    3. Añadir rol de Community Manager.
  6. COSTES:
    1. TCO a 2 años
    2. Capex vs Opex
    3. Costes GActions
    4. Cuanto llevamos gastado con respecto al Total
    5. Estimaciones pesimistas, optimistas… Con respecto al número de usuarios
    6. Modificaciones de nuevos roles: GDPR Data Protección Officer y Community Manager
  7. Refinar estructura de equipo:
    1. Estado del Commitment Agreement + Historial de este, ¿Cuándo y por qué no se ha cumplido?
    2. Modificaciones de nuevos roles: GDPR Data Protección Officer y Community Manager
  8. DEMO dinámica sprint 3: Descripción previa** al video
    1. Si en lo que se muestra hay algo nuevo, marcarlo (no quiere decir que haya que mostrar todo lo nuevo)
    2. Destacar mejoras de UX (píldora teórica).
    3. Implementación de aspectos legales (P.E: ¿cookies?...)
    4. Registro con términos y condiciones
    5. GDPR Compliance: httpS, derecho de olvido...
  9. RETROSPECTIVA:
    1. Evolución de la calidad del código, Sonar, Codacy… ver incremento y decremento de métricas.
    2. Rendimiento del equipo, desarrollando las fórmulas.
      1. Matriz de HORAS vs RENDIMIENTO con todos los integrantes.
    3. Gráfica de productividad y evolución.
    4. Plan de pruebas, píldora de testing, planes de aquí al Proyect Launch.
    5. Gestión de riesgos: Riesgos que se han dado + problemas que no eran riesgos: Medidas, métricas, planes…
    6. Lecciones Aprendidas
    7. Reloj de avance de proyecto, clockify semanal y global
    8. Changelog - Qué se ha incrementado con respecto a la semana anterior.
  10. Gestión de Usuarios Piloto.
    1. Gestión del feedback (demostrar que el usuario está siendo escuchado)
    2. Resumen del feedback proporcionado: feedback específico
    3. ¿Qué prioridad se le ha dado a cada cambio necesario y por qué?
    4. Acciones de consolidación que se han tomado a partir de ese feedback
    5. (Desarrollar Commitment Agreement con los usuarios pilotos) creo que poca gente lo ha mencionado y no han dicho nada pero luego en la evaluación nunca se sabe.
  11. PLANIFICACIÓN: De este apartado solo dijo "Planificación", no se qué habrá que mencionar, entiendo que algo de las futuras fases, cambio en los equipos...
    1. Issues previstas para este sprint + las que ya serán para futuras mejoras (quedan fuera del desarrollo actual)
    2. Objetivos para la demo final.
    3. Objetivos del 3: Registro, Pagos...
  12. Uso de IA
  13. QR landing page

Semana 10 (23/04)

Cosas a tener en cuenta#

  1. Evitar hablar de cosas como el GDPR que son generales e iguales para todos y entrar en conceptos de grupo.
  2. Justificar siempre por qué se darían datos optimistas o pesimistas.
  3. La DEMO debería tener algo parecido a una historia, no debe verse como una lista de funcionalidades. Es buen práctica que el anuncio se vea reflejado en la DEMO.
  4. Incluir cómo se van a medir y qué horizontes se van a poner a las métricas para resolver los problemas.
  5. Especificar los bugs que se han detectado y de qué manera se han solucionado.
  6. Si durante esa semana ha habido algún problema con los usuarios pilotos, se deben desarrollar las acciones que se han tomado con respecto al Acuerdo de los Usuarios Piloto.
  7. Por cada riesgo o problema que se presente, debe haber acciones de consolidación, pero lo más importante es que además deben haber métricas y se deben exponer en la presentación. “Vamos a reunirnos cada 2 días” “Vamos a …” Debe haber una métrica para medir el grado de satisfacción de la medida y un umbral que mida cuando se ha solucionado.
  8. Cuando se hable de los problemas que han aparecido, reflejar de alguna manera (una tabla es lo más sencillo para que lo vean claro los profesores) que se vea: Problema – Medida – Métrica - Estado
  9. Las presentaciones deben servir de apoyo a la audiencia, no deben parecer apuntes para el orador. Se deben buscar más iconografías e imágenes.
  10. Los números realistas deben ser lo suficientemente optimistas como para que sea rentable como para que un equipo pueda mantenerla. Luego estos números se podrán justificar en la campaña de lanzamiento durante los próximos sprints.
  11. Si como presentador tenemos problemas de hablar rápido es buena práctica realizar ejercicios de vocalización previos a la presentación.
  12. No confundir los términos "beneficios" e "ingresos", sobre todo al reflejarlos en la presentación.
  13. Se debe cuidar el uso de conectores durante la presentación sobre todo si no tiene sentido coherente entre ambas frases.
  14. Hay que saber medir cuando, aún habiendo mucho esfuerzo en una tarea, si se da una corrección o una recomendación, aceptar estas y realizar algo de retrospectiva en lugar de tratar de defenderla a cualquier costo.
  15. No usar canciones demasiado conocidas para los anuncios. Plantearse usar herramientas de IA con el nombre de nuestra aplicación para estos.
  16. Se debería de prever con anterioridad a padecer el problema el pasarse de las horas estipuladas en la asignatura. Si ya ha pasado no se ha tratado de manera correcta.
  17. Si no se pueden realizar los test de carga sobre el AppEngine es conveniente buscar alternativas, aunque sea probarlo el local y extrapolar al despliegue real.
  18. Si alguien disminuye su rendimiento de manera constante es necesario tomar algún tipo de medida, hablarlo con él y llegar a algún tipo de solución para que la tendencia no siga.
  19. En los anuncios evitar anuncios de dinámica “¿Conoces la app ...?” Es mejor llegar de una manera más orgánica, en la que uno presente las necesidades que puede satisfacer la aplicación y entonces se le ocurra usar la nuestra.
  20. Al recoger el feedback de los usuarios piloto sobre los precios, nos da más información preguntar primero cuánto estaría dispuesto a pagar antes de mostrarle cuánto cuesta.

Consideraciones para IT TALENT#

  • Evitar hablar de cosas como el GDPR que son generales e iguales para todos y entrar en conceptos de grupo.
  • Justificar mejor por qué se darían datos optimistas o pesimistas.
  • La DEMO debería tener algo parecido a una historia, no debe verse como una lista de funcionalidades. Es buen práctica que el anuncio se vea reflejado en la DEMO.
  • Quitar decimales de los años de experiencia (son pequeños detalles pero no pueden llegar a la presentación siendo 15 miembros de equipo).
  • Incluir cómo se van a medir y qué horizontes se van a poner a las métricas para resolver los problemas.
  • Un fondo oscuro es poco práctico, debe como mínimo existir la opción de poner un modo claro. Es difícil leer cosas como la leyenda de los gráficos.
  • Dejar claro que la búsqueda de nuevos usuarios pilotos sigue activa.
  • Al ser una herramienta que se usaría de forma puntual y de manera no extendida no tiene sentido el fondo oscuro.
  • Especificar los bugs que se han detectado y de qué manera se han solucionado.
  • Si durante esa semana ha habido algún problema con los usuarios pilotos, se deben desarrollar las acciones que se han tomado con respecto al Acuerdo de los Usuarios Piloto.
  • Por cada riesgo o problema que se presente, debe haber acciones de consolidación, pero lo más importante es que además deben haber métricas y se deben exponer en la presentación. “Vamos a reunirnos cada 2 días” “Vamos a …” Debe haber una métrica para medir el grado de satisfacción de la medida y un umbral que mida cuando se ha solucionado.
  • Cuando se hable de los problemas que han aparecido, reflejar de alguna manera (una tabla es lo más sencillo para que lo vean claro los profesores) que se vea: Problema – Medida – Métrica - Estado

Tareas - ¿Qué no puede faltar?#

  • WPL:
    • En el salón de actos 21 de mayo. Desde las 12:30 a 14:30
    • Se podrá ensayar el Lunes de 13:30 a 16:30. Preparar temas como el cañón, audio…

HABRÁ 2 PRESENTACIONES distintas:

  • Una de 10 minutos para ensayar el WPL:
  1. ¿De qué va el proyecto?
    1. Killer opener
    2. Elevator pitch
    3. Video usuario/cliente
  2. ¿Cómo funciona? - DEMO
  3. ¿Hay competencia?
    1. Análisis de competidores
    2. ¿Qué nos diferencia?
  4. ¿Quién hay detrás? - Equipo
  5. ¿Es rentable?
    1. Planes de precio
    2. Resumen de plan de negocio, costes...
    3. Oportunidades de inversión, ROI
    4. Anuncio de inversores:
      1. ¿Qué podemos ofrecer?
      2. ¿De qué va el proyecto?
      3. Opciones de inversión – “Si invertes X en tanto tiempo conseguirás Y”
  6. Landing page, contacto…
  • Otra de 5 minutos sobre la campaña de lanzamiento:
  1. Segmentación del mercado - ¿A quién va dirigido? (modelo de segmentación) (2 perfiles como mínimo)
  2. Algún tipo de optimización SEO – Buscadores, palabras claves…
  3. Campaña de lanzamiento previo al WPL – Promociones, acciones de impulso para tracción inicial (orientado al cliente más que al usuario)
  4. Acciones de marketing
  5. Community Management:
    1. Objetivos (Píldora teórica)
    2. Planning (Publicaciones en las RRSS)
    3. Responsables (De las RRSS)
    4. Número de impresiones que tenemos como objetivo
  6. Coste de marketing – Desglosado
  7. Si hay algún anuncio que queramos poner que no saliera en la primera se pone para comentarlo
  8. Uso de las IAs

Semana 11 (30/04)

Cosas a tener en cuenta#

  1. Incluir subtítulos en las demos es una buena práctica sobre todo si el audio está distorsionado.
  2. Buscar uniformidad en las diapositivas no cambiar demasiado el tamaño de letra, aunque se trate de una gráfica.
  3. Evitar “Frases Genéricas” que no aportan nada en apartados como “¿Por qué nosotros?” se debe tratar de ser original y ser lo más objetivos y específicos posibles, todas las razones que demos se deben sustentar en algo.
  4. Es importante remarcar en qué momento empezaría a ser rentable nuestra aplicación.
  5. Evitar frases obvias como “Venimos a vender una aplicación”.
  6. No dedicar tanto como 4 o 5 slides a la estructura de equipo, también se debe tratar de que sea homogénea y todos tengan el mismo protagonismo.
  7. Cuando se habla del TCO se debe ir al caso realista, no al optimista.
  8. Cada vez que se vean datos a futuro se debe tratar de convencer un poco diciendo de dónde salen esos números.
  9. La música del anuncio no debe se estruendosa, no debe distraer del mensaje del mismo.
  10. Business Plan debe responder a “¿Cómo voy a ganar dinero con la aplicación? ¿Por qué y cómo vamos a ser rentables?”.
  11. No olvidar cuales son las prioridades del inversor (ROI) a la hora de realizar el anuncio.
  12. El nivel de información que se mete en una diapositiva o serie de diapositiva debe ser asimilable, por ejemplo, en la composición de equipos, no se pueden tener demasiadas diapositivas ni pararse demasiado en cada tema del que hay que hablar, se trata de sintetizar no de ser más rápido.
  13. Si se cambia el orden del momento en el que hablar de los competidores, debe estar justificado, que encaje con el elevator pitch.
  14. En el Killer Opener se debe dejar claro de que va nuestra aplicación, no caer en la dinámica de hablar a gente que ya la conoce.
  15. Evitar líneas o columnas en el análisis de competidores que reflejen que nadie tiene una característica que nosotros sí, se pierde el concepto de “Competición”.
  16. No decir que la aplicación puede fallar de manera irrecuperable en la presentación.
  17. Evitar mostrar las trabas por el camino (de índole “Casi dejamos el proyecto) en la presentación WPL.
  18. Evitar frases como “Como siempre…” “Como todas las semanas…” en el WPL.
  19. Si no llegamos a poder explicar todo lo que queremos del TCO, es conveniente ponerlo en el anuncio de inversores.
  20. No hablar a la vez en la DEMO o el Anuncio (en la presentación en vivo) si hay música en el mismo. Si hay algo que decir incluirlo en el audio del video.

Consideraciones para IT TALENT#

  • Business Plan debe responder a “¿Cómo voy a ganar dinero con la aplicación? ¿Por qué y cómo vamos a ser rentables?”.
  • Realizar el Anuncio de Inversores. Se deben incluir números, datos, ROI… Orientado al mercado y apoyado de estudios que hayamos realizado.No olvidar cuales son las prioridades del inversor. Ser claro con ¿Cuánto tengo que invertir? ¿Cuándo Tengo que invertir? y ¿Cuánto voy a ganar? CON NÚMEROS apoyados por estudios de marketing, anuncios, estudios de mercado…
  • Dar opciones de inversión sin nunca superar el 50% (de adquisición de la aplicación) y mostrando el ROI.
  • EN la DEMO no incluir la presentación de la historia que cuenta Javi a la misma vez que se están realizando acciones sobre la aplicación, aunque sea el registro.
  • Intentar realizar un anuncio a la vez que DEMO de esta manera podría quedar menos repetitivo. Es decir, en nuestro caso podría funcionar mejor un anuncio en el que se vean claramente las funciones de nuestra aplicación.
  • Eliminar el Commitment Agreement de la presentación, no pega en las últimas presentaciones.
  • Añadir la leyenda de la gráfica de la página 6.
  • Mostrar algún story o publicación en la presentación de Marketing.
  • Se debe mostrar la agenda de marketing en la presentación.
  • Se ve que hay un coste inicial en el Marketing (que nos hacen empezar en negativo), se debe hablar de estos costes (desglose) además de otros datos como el número de usuarios que estimamos que aporte la campaña de marketing.
  • Usar “Equipos” para el SEO no es una keyword efectiva, aparecerían otros resultados antes (deportes).
  • Fernando debe alzar la voz en el Killer Opener de los CV.
  • El audio debe ser mejorado en el anuncio (arreglar eco), aclararlo lo mas posible (o volver a grabarlo encajarlo en el video).
  • Evitar usar términos como Capex, Opex, Matchmaking… en el WPL, ya que no son de dominio general (en la presentación habrá personas que no dominan estos términos) por lo que es mejor usar Coste Capital y Coste Operacional.

Tareas - ¿Qué no puede faltar?#

  • A iniciativa del grupo de tarde, se han puesto en contacto de la escuela para publicitar su aplicación. Se usarán las pantallas para publicitar las apps en la que podremos poner una pantalla en la que pongamos de que va el proyecto. Pasaran una plantilla por EV para modificarla.

  • Definir el "perfil" bien: ¿Dónde están segmentados nuestro perfiles del público al que va dirigido?

  • WPL:

    • En el salón de actos 21 de mayo. Desde las 12:30 a 14:30
    • Se podrá ensayar el Lunes de 13:30 a 16:30. Preparar temas como el cañón, audio…
  • 10 minutos para el WPL:
  1. ¿De qué va el proyecto?
    1. Killer opener
    2. Elevator pitch
    3. Video usuario/cliente
  2. ¿Cómo funciona? - DEMO
  3. ¿Hay competencia?
    1. Análisis de competidores
    2. ¿Qué nos diferencia?
  4. ¿Quién hay detrás? - Equipo
  5. ¿Es rentable?
    1. Planes de precio
    2. Resumen de plan de negocio, costes...
    3. Oportunidades de inversión, ROI
    4. Anuncio de inversores:
      1. ¿Qué podemos ofrecer?
      2. ¿De qué va el proyecto?
      3. Opciones de inversión – “Si invertes X en tanto tiempo conseguirás Y”
  6. Landing page, contacto…
  • 5 minutos para la campaña de lanzamiento:
  1. Segmentación del mercado - ¿A quién va dirigido? (modelo de segmentación) (2 perfiles como mínimo)
  2. Algún tipo de optimización SEO – Buscadores, palabras claves…
  3. Campaña de lanzamiento previo al WPL – Promociones, acciones de impulso para tracción inicial (orientado al cliente más que al usuario)
  4. Acciones de marketing
  5. Community Management:
    1. Objetivos (Píldora teórica)
    2. Planning (Publicaciones en las RRSS)
    3. Responsables (De las RRSS)
    4. Número de impresiones que tenemos como objetivo
  6. Coste de marketing – Desglosado
  7. Si hay algún anuncio que queramos poner que no saliera en la primera se pone para comentarlo
  8. Uso de las IAs

Semana 12 (07/05)

Cosas a tener en cuenta#

  1. No incluir competidores que no supongan competición en el análisis.
  2. El número de usuarios concurrentes debe ir justificado con la campaña de marketing o con datos del mercado.
  3. Las transiciones deben quedar naturales, respondiendo a las preguntas que nos han dado los profesores ¿De qué va el proyecto? ¿Quién hay detrás? ¿Quién más hay en el mercado? E ir pasando por los diferentes puntos de esta manera.
  4. No entrar a detalle en la estructura del equipo, solo enseñarla.
  5. Siempre tiene que haber algo de Marketing en la presentación del WPL.
  6. Debería verse el número de horas con la que se está contando que trabajará el equipo de desarrollo.
  7. Evitar transiciones entre diapositivas como “ahora vamos a ver el anuncio de, ahora vamos a ver la grafica de” debe ser más natural y fluido. Cambiarlo por frases como “¿Cómo sacaremos dinero de todo esto?”
  8. Eliminar funciones tipo CRUD de la DEMO como funciones de Editar o Eliminar.
  9. Nombrar los roles de GDPR, GM… en el WPL sobra, con diferenciar al CEO es suficiente. Solo es necesario dejar claro que somos un grupo “SÓLIDO”.
  10. Evitar demasiado detalle en los costes o en los planes de precios, no pasarse con el desglose.
  11. No se debería invertir demasiado tiempo en diapositivas de costes o demasiado complejas, con demasiadas cifras, que no se puedan digerir. Incluir QRs con “más detalle en este link”.
  12. El anuncio de inversores debe estar desasociado del resto de anuncios. Hablar de las ventajas competitivas con el resto de aplicaciones, ROI, Cuánto pedimos Y cuanto van a conseguir a cambio. El resto sobra.
  13. Eliminar cualquier vocabulario técnico de la presentación, diapositiva o verbal. Sólo debería incluirse un vocabulario que entienda un alumno de inicio de carrera.
  14. Tratar de no cerrar abruptamente las presentaciones, se debe llegar de manera más sosegada.

Consideraciones para IT TALENT#

  • Buen inicio efectivo.

  • Somo un buen ejemplo de cómo se pasa de un tema a otro, enlazando el hilo argumental con un buen ritmo.

  • Para el killer opener, El tono de voz de Fernando tiene que ser más elevado. Imprimir varios currículos y preguntar quién tiene uno de IT.

  • El anuncio no se puede considerar como tal, es demasiado largo:

    • El tema oscuro con música triste no casan nada bien. Transmite algo contradictorio, da una sensación de desolación con el negro + música triste mientras se usa la aplicación hace que parezca que ITTALENT da desidia. La música triste debe ser al principio, una vez se usa la aplicación se debe cambiar a un motivo alegre, de esperanza.
    • Cuidar que Javi dice Plan Pro y se clica en el Advance.
    • La historia parece dirigida a una sola persona que busca trabajo o no queda lo suficientemente claro que existen ambas.

  • A lo largo del resto de la aplicación se debe seguir reforzando la formación de equipos y las ventajas que esto da con respecto a otras aplicaciones disponibles en el mercado. Si no se enseñan las ventajas o lo rompedor que es de forma natural, incluir una diapositiva que indique las razones por la que lo es.

  • Revisar los términos ISPP ONLY como “TCO”, cambiar términos aunque se desglosen las siglas.

  • El anuncio de inversores está en muy buena dirección. Eliminar la parte en la que se habla de “Los beneficios a X meses”. El audio dice que se ganan 15K y en el video pone que se ganan 43K (sin hacer la resta) es algo contradictorio.

  • Eliminar la keyword “Team Building”, es otra cosa, no tiene que ver con nuestra aplicación.

  • Los datos de impresiones deben estar en el WPL actualizados, quedan muy bien.

Tareas - ¿Qué no puede faltar?#

  • La semana que viene es de retrospectiva: Presentación rápida destacando contribuciones de cada miembro poniendo los commits a GitHub, las horas de clockify... debe ser ágil para que de tiempo a todos. 15 mins.
  • WPL:
    • En el salón de actos Martes 21 de mayo de las 12:30 a 14:30
    • Se podrá ensayar el Lunes 20 de mayo de 13:30 a 16:30. Preparar temas como el cañón, audio…
  • La rúbrica para la evalución del WPL se compartirá por EV, y contendrá algo como:

CALIDA AUDIOVISUAL: Calidad de audio, sonido, video...

DELIVERY: Cómo se hace la presentación, dirección, energía, ritmo, queda claro los mensajes que se han querido destacar sobre el resto de la información...

PROBLEMA: queda claro como arreglamos el problema con nuestro proyecto

TARGET: queda claro el publico objetivo...

MODELO DE NEGOCIO: queda clara la ventaja con la competición...

Luego a parte se evaluará el Software desarrollado.

  • 10 minutos para el WPL:
  1. ¿De qué va el proyecto?
    1. Killer opener
    2. Elevator pitch
    3. Video usuario/cliente
  2. ¿Cómo funciona? - DEMO
  3. ¿Hay competencia?
    1. Análisis de competidores
    2. ¿Qué nos diferencia?
  4. ¿Quién hay detrás? - Equipo
  5. ¿Es rentable?
    1. Planes de precio
    2. Resumen de plan de negocio, costes...
    3. Oportunidades de inversión, ROI
    4. Anuncio de inversores:
      1. ¿Qué podemos ofrecer?
      2. ¿De qué va el proyecto?
      3. Opciones de inversión – “Si invertes X en tanto tiempo conseguirás Y”
  6. Landing page, contacto…
  • 5 minutos para la campaña de lanzamiento:
  1. Segmentación del mercado - ¿A quién va dirigido? (modelo de segmentación) (2 perfiles como mínimo)
  2. Algún tipo de optimización SEO – Buscadores, palabras claves…
  3. Campaña de lanzamiento previo al WPL – Promociones, acciones de impulso para tracción inicial (orientado al cliente más que al usuario)
  4. Acciones de marketing
  5. Community Management:
    1. Objetivos (Píldora teórica)
    2. Planning (Publicaciones en las RRSS)
    3. Responsables (De las RRSS)
    4. Número de impresiones que tenemos como objetivo
  6. Coste de marketing – Desglosado
  7. Si hay algún anuncio que queramos poner que no saliera en la primera se pone para comentarlo
  8. Uso de las IAs
  • Ingeniería del Software y Práctica Profesional - Universidad de Sevilla
  • Resumen del documento
  • Cosas a tener en cuenta
  • Consideraciones para IT TALENT
  • Tareas
  • Cosas a tener en cuenta
  • Consideraciones para IT TALENT
  • Tareas - ¿Qué no puede faltar?
  • Cosas a tener en cuenta
  • Consideraciones para IT TALENT
  • Tareas - ¿Qué no puede faltar?
  • Cosas a tener en cuenta
  • Consideraciones para IT TALENT
  • Tareas - ¿Qué no puede faltar?
  • Cosas a tener en cuenta
  • Consideraciones para IT TALENT
  • Tareas - ¿Qué no puede faltar?
  • Cosas a tener en cuenta
  • Consideraciones para IT TALENT
  • Tareas - ¿Qué no puede faltar?
  • Cosas a tener en cuenta
  • Consideraciones para IT TALENT
  • Tareas - ¿Qué no puede faltar?
  • Cosas a tener en cuenta
  • Consideraciones para IT TALENT
  • Tareas - ¿Qué no puede faltar?
  • Cosas a tener en cuenta
  • Consideraciones para IT TALENT
  • Tareas - ¿Qué no puede faltar?
  • Cosas a tener en cuenta
  • Consideraciones para IT TALENT
  • Tareas - ¿Qué no puede faltar?
  • Cosas a tener en cuenta
  • Consideraciones para IT TALENT
  • Tareas - ¿Qué no puede faltar?