Skip to main content

Contribuciones a la Base Común de Conocimiento

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.018/02/24Paco, Fernando, IsmaelDocumento inicial
v2.026/02/24PacoCambio en el formato y adición del contenido de la 3a semana
v2.103/03/24PacoAdición de contenido de la 4a semana
v2.622/04/24PacoAdición de contenido de la 8a y 9a semana

Resumen del documento#

En este documento se especifican las contribuciones a la base de conocimientos de la asignatura disponible en este enlace. También se recogen las acciones que se han tomado teniendo en cuenta el feedback proporcionado de una semana a otra.

Índice

1. Contribuciones 4

Feedback del grupo 1 4

Feedback general 7

2. Acciones de consolidación 12

Semana 1

Semana 2

Semana 3

Semana 4

Semana 5

Semana 6

Semana 7

Semana 8

Semana 9

Semana 10

Semana 11

Semana 12

1. Contribuciones

Para las contribuciones se llega a un acuerdo de que cada semana será un grupo el encargado de recoger todo el feedback general de esa sesión y desplegarlo en la página https://bgcc.vercel.app/. Pero cada grupo tendrá como encargo semanalmente subir el feedback de su propio grupo, además de revisar el general en busca de posibles carencias en este.

Feedback del grupo 1#

  • Semana 1
  1. Las diferencias con el resto de competidores deben quedar suficientemente claras. Distinguir la “puesta en marcha” del resto de costes, ¿Cuál es el TCO?.
  2. 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.
  3. Se deben identificar las responsabilidades (están bien hechos los grupos) para cada grupo.
  4. Explicar cuál ha sido el proceso y criterio de búsqueda con los competidores.
  5. Evitar que sobre demasiado tiempo sobre todo si se puede profundizar en otros temas como la búsqueda de competidores.
  6. Evitar permanecer demasiado tiempo en una diapositiva o dejar explicación sin soporte visual, hace complicado seguir la presentación.
  7. Relacionar entre sí las matrices DAFO p.e: Amenazas vs Fortalezas… concretamente: 1ºA, 2ºF, 3º D, 4º O
  8. No son preferibles las estructuras jerárquicas con jefes y planificaciones. Son preferibles roles claros.
  9. Hay que hablar la base de conocimientos común.
  10. Tratar de homogeneizar las fotos de los participantes, que no tengan fondos muy diferentes.
  11. 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.
  12. Tratar de mantener un volumen de voz alto.
  13. No hacer preguntas al público.
  • Semana 2
  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.
  10. El TCO debe estar expresado de manera mensual no anual.
  11. Al exponer un riesgo es importante describirlo como un evento que puede ocurrir y describir los daños o pérdidas que causaría.
  12. Si se expone un riesgo, se presenta la solución por delante.
  13. Los análisis de costes son más inteligibles en forma de tabla.
  14. 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.
  15. Dejar claro que TODOS los integrantes han firmado el commitment agreement.
  16. No sentarse en la mesa para exponer.
  17. Un fondo negro dificulta la lectura.
  18. Uso de fuentes anchas y grandes.
  19. Al proponer precios debe quedar claro los beneficios que se están sacando (TCO).
  20. Siempre tener en cuenta el feedback de semanas anteriores al exponer. Marcar con una “F” las diapositivas que hacen referencia a este feedback.
  21. Evitar el uso de iconografías sin descripción en la comparación con otras empresas.
  22. 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.
  23. Dar mayor protagonismo a los mockups, casos de uso core y la idea de negocio.
  24. 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?
  25. Se debe dejar claro de dónde sale el cálculo de precios y cuál es el beneficio que se saca de estos.
  • Semana 3
  1. Si se realiza un Killer Opener, este debe ser corto. Si se demora demasiado deja de ser efectivo.
  2. Situar la marca de feedback en la parte superior de la presentación.
  3. Al presentar los mockups realizar 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. 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.
  10. Si se han aplicado medidas para solucionar un problema hay que plasmar, evaluar y medir cómo de buenas han sido estas.
  11. Tener claros y plasmar las metas y objetivos de cada sprint.
  12. No quejarse NUNCA en medio de la presentación.
  • Semana 4
  1. 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.
  2. 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.
  3. Hablar en profundidad de nuestra gestión de la documentación, mostrar el versionado de documentos que se lleva internamente.
  4. 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.
  5. La tabla de TEAM PERFORMANCE está bien, no cambiarla demasiado, pero le ha faltado la performance individual.
  6. Faltan gráficas y métricas del rendimiento por cada integrante del equipo (anónimo).
  7. 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?
  8. El DAFO ya no merece la pena incluirlo en la presentación.
  9. Diferencias entre gitflow y goldenflow y decir cual nos merece la pena usar.
  10. 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.
  11. Pensar en si es mejor una DEMO grabada o en directo.
  12. Marcar más el reconocimiento que se dice que se tiene sobre el CA. Poner un pódium con los nombres.
  • Semana 5
  1. Eliminar la captura del formulario, no es legible.
  2. Falta un Elevator pitch claro.
  3. Cambiar MPV por MVP.
  4. Tener una demo grabada.
  5. Para en la demo empezar por lo más importante, no el login.
  6. Demasiados datos en el TCO, hacen complejo entender y seguir la presentación.
  7. Las estimaciones a futuro (BUDGET) NO pueden ser lineales, datos como el número de usuarios deben hacer fluctuar los datos.
  8. Evitar colores claros sobre blanco en los gráficos y poner etiquetas en cada eje.
  9. 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.
  10. 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.
  11. 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.
  12. Tendríamos que hacer el análisis económico de las peticiones que harán los clientes.
  13. Estimaciones de usuarios (optimistas, pesimistas, realistas) más simple, realizar análisis PERT.
  14. Realizar un pseudo gantt en la retrospectiva del sprint con las tareas que se han realizado en este.
  15. Incluir documentación en el repositorio o en un docusaurus.
  • Semana 7
  1. Evitar uso de fuentes oscuras sobre fondos oscuros.
  2. En la DEMO hay letras muy pequeñas, por lo que es necesario hacer uso de zoom en el video.
  3. Pensar en usar colores más claros para la DEMO únicamente, manteniendo los colores en la aplicación original.
  4. Storyboards en blanco y negro poniendo en color lo que queramos destacar.
  5. Los presupuestos expuestos están demasiado centrados en el desarrollo.
  6. La grafica del Budget sobra con la otra grafica de costes y beneficios.
  7. 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.
  8. Revisar los usuarios pilotos que no responden y acotar los que sean menos probables.
  9. El elevator pitch debe estar más presente. No solamente como una frase introductoria. (como musclemate, qué ofrecemos nosotros que otros no)
  10. En el storyboard del empresario buscar destacar la característica que nos diferencia (le hagan falta 5 personas para YA con unas especificaciones CONCRETAS).
  11. 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…
  12. 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).
  13. Hacer gráfica de puntos de historia vs tiempo consumido.
  14. 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.
  15. 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).
  • Semana 8
  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.
  • Semana 9
  1. Cuidar la iluminación del anuncio así como la vocalización y velocidad del diálogo.
  2. ¿SON LOS CORRECTOS USUARIOS POTENCIALES? Hay que cambiar el enfoque, la búsqueda de trabajo es constante
  3. Añadir diapositivas de apoyo para el Customer Agreement (Diapositiva: SLA + TOS).
  4. Especificar los datos de la diapositiva Capex vs Opex. Y añadir datos de usuarios empleados que se registrarían en la aplicación.
  5. Pararse brevemente a explicar qué es cada cláusulas del Commitment Agreement.
  6. En la DEMO pararse en las funcionalidades core y no mencionar la edición/eliminación de perfiles.
  7. Al subir el ritmo del diálogo se deja de seguir el ritmo de la presentación y se pierden conceptos.
  8. 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.
  9. 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.
  10. 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.
  11. Se debe plasmar si los tests están siendo efectivos o no (inventarse fallos o realizar test que se sabe que van a fallar).
  12. Añadir el numero de refinamientos necesarios en el report de las IAs.
  13. Meter acciones de consolidación en la Base de Conocimientos
  14. Tener un apartado de la DEMO en el Docusaurio (link a Youtube…).
  15. Añadir apoyo para los SLA y ToS (Customer Agreement)
  16. Incluir los ToS en el registro.
  17. 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.
  18. A Muller le gustó que: Para cada problema: OPEN, NOT SOLVED, IN PROGRESS, SOLVED
  19. Muller mencionó que es buena practica realizar pruebas de carga que muestren cuantás peticiones son necesarias para agotar los créditos de Google.
  20. A Muller le gustó: Segmentación de mercado de cara al proyect launch (píldora teórica).
  • Semana 10
  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.
  • Semana 11
  1. Business Plan debe responder a “¿Cómo voy a ganar dinero con la aplicación? ¿Por qué y cómo vamos a ser rentables?”.
  2. 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…
  3. Dar opciones de inversión sin nunca superar el 50% (de adquisición de la aplicación) y mostrando el ROI.
  4. 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.
  5. 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.
  6. Eliminar el Commitment Agreement de la presentación, no pega en las últimas presentaciones.
  7. Añadir la leyenda de la gráfica de la página 6.
  8. Mostrar algún story o publicación en la presentación de Marketing.
  9. Se debe mostrar la agenda de marketing en la presentación.
  10. 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.
  11. Usar “Equipos” para el SEO no es una keyword efectiva, aparecerían otros resultados antes (deportes).
  12. Fernando debe alzar la voz en el Killer Opener de los CV.
  13. El audio debe ser mejorado en el anuncio (arreglar eco), aclararlo lo mas posible (o volver a grabarlo encajarlo en el video).
  14. 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.
  • Semana 12

  1. Buen inicio efectivo.

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

  3. 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.

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

    1. 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.
    2. Cuidar que Javi dice Plan Pro y se clica en el Advance.
    3. La historia parece dirigida a una sola persona que busca trabajo o no queda lo suficientemente claro que existen ambas.

  5. 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.

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

  7. 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.

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

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

FEEDBACK GENERAL#

Presentadores

“Segmentar las ideas” de tal manera que queden claros los mensajes clave.

Evitar permanecer demasiado tiempo en una diapositiva o dejar explicación sin soporte visual.

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.

Aunque se realice un Killer Opener, los presentadores deben recordar decir sus nombres.

Recordar que como presentador no recae en uno las responsabilidades del grupo al completo, disfrutar de la presentación.

Aclarar y enlazar el Killer Opener con el inicio y el resto de la presentación.

No olvidar que es el moderador (no nuestro grupo) quien lleva el conteo del tiempo (fuera de evaluación) de las presentaciones.

Cuidar y evitar las muletillas.

No suspirar a lo largo de la presentación, da sensación de agotamiento de lo que se está contando.

Siempre cuidar y tener claro el hilo de la presentación. Debe de haber coherencia entre los puntos y no dejar conceptos sueltos.

Si como presentador tenemos problemas de hablar rápido es buena práctica realizar ejercicios de vocalización previos a la presentación.

Se debe cuidar el uso de conectores durante la presentación sobre todo si no tiene sentido coherente entre ambas frases.

Presentación

Tratar de homogeneizar las fotos de los participantes, que no tengan fondos muy diferentes.

Las demos de los prototipos se deben ver bien, hacer zoom si es necesario.

Evitar letras blancas sobre colores claros.

Si hay datos en el tiempo (días) poner como apoyo visual un calendario.

Se debe ser coherente lo que se refleja en la diapositiva con lo que pone en el título.

Evitar sobrecarga en las presentaciones, buscar la simplicidad y la correlación entre diapositivas.

Marcar más el reconocimiento que se dice que se tiene sobre el Commitment Agreement. Poner un pódium con los nombres.

Usar recursos en la presentación como líneas o subrayados para corresponder con lo que se dice.

El DAFO ya no merece la pena incluirlo en la presentación.

Pensar en si es mejor una DEMO grabada o en directo.

Indicar con triángulos hacia arriba o abajo cuando haya habido rendimiento positivo o negativo en la retrospectiva.

Siempre debe haber una transparencia con la productividad por miembro del equipo (horas).

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.

No meter una imagen de un QR si no es funcional o al menos aclarar que no lo es.

No basta con mostrar los problemas que ha habido durante la semana de trabajo, se debe mostrar siempre el análisis de riesgos inicial.

No mezclar la retrospectiva con la autoevaluación.

Debe quedar reflejado en la presentación que cuando no se llega el trabajo planificado se ha incumplido alguna cláusula del Commitment Agreement.

Deben quedar claro los responsables de una tarea.

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.

En la autoevaluación debe haber un análisis con métricas y números claros.

Siempre que se muestren problemas en el trabajo en equipo en la presentación, se mostrarán las medidas que se tomarán para solventarlos con las métricas con las que se medirá la eficacia de las respuestas.

A cada sprint siempre se debe mostrar la planificación o re-planificación de los próximos sprints.

Se busca una mejora de la síntesis cada semana, no se deben eliminar conceptos de una a otra.

Mantener siempre una diapositiva con la Landing Page con QR aunque sea en la última diapositiva.

Siempre incluir los estados de la comunicación en la gestión de usuarios pilotos.

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.

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.

No confundir los términos "beneficios" e "ingresos", sobre todo al reflejarlos en la presentación.

No usar canciones demasiado conocidas para los anuncios. Plantearse usar herramientas de IA con el nombre de nuestra aplicación para estos.

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.

Análisis de competidores

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.

Pese a estar en la fase de desarrollo el análisis de competidores siempre debe estar presente en las presentaciones.

Para un análisis de competidores más sintetizado es suficiente con pararse en los tres más similares a nuestra plataforma focalizando en la característica más “killer”.

Análisis de costes

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.

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).

Para el TCO es pertinente 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 de porcentajes del número de usuarios que tienen que usar nuestra aplicación (TCO) con respecto al número de usuarios potenciales.

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.

Justificar siempre por qué se darían datos optimistas o pesimistas.

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.

Documentación

Reflejar en el Commitment Agreement cuando personas tiene penalizaciones o “ya no van a por el 10”.

Análisis de Riesgos

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.

Incluir cómo se van a medir y qué horizontes se van a poner a las métricas para resolver los problemas.

Especificar los bugs que se han detectado y de qué manera se han 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

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.

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.

Usuarios Piloto

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.

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.

Proyecto en general

Se debe dejar claro la planificación de cada sprint, sobre todo si ha habido problemas de rendimiento en una semana, ¿Cómo afectan las carencias en este sprint a los próximos sprints?

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.

El rendimiento no es la inversión del tiempo si no el uso efectivo del mismo.

El rendimiento se debe medir individualmente y no en grupo.

Si hay una propuesta de mejora se debe decir cómo se va a medir de antemano, antes de tomar la medida.

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?

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.

El testing no puede estar presente solamente en el sprint 3, deben ser FAST, se deben hacer a lo largo de todos los sprints.

En caso de tener problemas en el desarrollo, siempre valorar la posibilidad de mover tareas de un sprint a otro.

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.

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.

2. Acciones de consolidación

Tras recoger el feedback semanal han de ser evaluados y realizar los cambios pertinentes sobre el proyecto, aquí se recogen estos cambios.

Semana 1#

Costes

Se realizó el análisis de costes orientado a distinguir los costes de puesta en marcha, costes de desarrollo, costes de mantenimiento y coste total de propiedad. Además, se han añadido planes de acción en cuanto a la variación del volumen de usuarios. Se ha explicado el proceso que se ha seguido(teniendo en cuenta las píldoras teóricas) para identificar a los competidores.

Commitment Agreement

Se deja claro en el commitment agreement en quién recae la responsabilidad de una tarea en el grupo. Es el coordinador el que la piensa y asigna, pero la responsabilidad de la no realización de la misma recae sobre el asignado, a no ser que se avisara con tiempo suficiente como para poder encargársela a otro en día laboral.

Presentación

Se redujo la carga de las diapositivas, aumentando su cantidad y usando un mayor número de referencias simbólicas. Se tuvo en cuenta y se explica ahora la matriz DAFO empezando por Debilidades y Fortalezas, y luego Amenazas y Oportunidades. Nos hicimos fotos con el mismo fondo y pose. Pusimos los costos con un número sin decimales. Se dejó de lanzar preguntas al público sin que estuviera acordado entre ellos.

Semana 2#

Presentador

Se ha preparado un Killer opener más impactante unido a un Elevator Pitch, además de evitar sentarse durante la exposición.

Presentación

Se le dedica más tiempo en la exposición a desarrollar la idea de negocio y el core. No se usaba fondo negro, pero se aumenta el tamaño de la letra y fuente.

Se ha incluido promesas en la parte de la idea de negocio, y de definición del producto. Los mockups se han movido al final. Se ha cambiado la expresión del TCO a meses, y se expresa con más detalles los gastos y costes. Se indica con una “F” las partes donde se ha tenido en cuenta el feedback. Se ha aclarado que el uso de RRSS es opcional y siempre por parte del candidato. Se usan iconos con breve descripción, no sólo símbolos sueltos.

Comparaciones

Hemos analizado y remarcado cuales son nuestras diferencias más importantes del resto de competidores. No existen competidores que ofrezcan el servicio de forma gratuita. Además, el pricing ha sido actualizado para orientarlo a nuestro producto y hacerlo más llamativo(palabras claves y letras más grandes).

Commitment agreement

Se han realizado cambios en el commitment agreement sobre en quién recae la responsabilidad de una tarea y las recompensas del trabajo semanal individual, dando a un total de 15 cláusulas que volvieron a firmar los integrantes del equipo.

Riesgos

Se indica de manera explícita como solventar los riesgos y se ha aumentado el número de estos. Se describe el riesgo como evento, no como “problema”.

Costes

Se han añadido las licencias necesarias(Github) al análisis de costes. Además se ha calculado cuáles serán las ganancias.

Semana 3#

Presentador

Se trabaja sobre el Killer Opener y se elabora una historia como introducción más corta y directa. Para lidiar con problemas durante la exposición el presentador del grupo se ha grabado realizándola y la ha mandado a todo el grupo dándole este último apuntes y consejos sobre que puede ser obviado o qué no puede faltar, de esta manera es capaz de practicar la presentación y además afilar más los argumentos quitando lo innecesario.

Presentación

Para la presentación se toman en cuenta los comentarios que realizó el público y; se cambia la posición de la marca del feedback a la parte superior de las transparencias y se procura que en todo momento las letras estén lo suficientemente grandes o destacadas.

También se remarcan aún más nuestras diferencias con los competidores en la transparencia correspondiente.

Comunicación

Se mantiene el contacto con nuestros usuarios pilotos y dejamos claro que iremos avisando de cuando tengamos demos que puedan testear. Por su parte nos dan ya una fecha, el 28 de febrero, en la que tendríamos su demo.

Con respecto a las empresas contactadas, el estado de comunicación con estos es el mismo, una ha confirmado y el resto pendientes de respuesta.

Retrospectiva

Se han tomado medidas para nuestro uso del tiempo y las respuestas a estas han sido notables esta semana, por ello de momento las metas para el resto del proyecto se mantienen iguales.

Documentació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.

Seguimos con la misma metodología de gestión que habíamos tomado desde el inicio, con Drive, pero con tableros de github para controlarlos como un repositorio en el que un responsable se encarga de revisar cada documento y cada encargado de realizarlo es notificado mediante issues y si hubiera algún problema es notificado mediante comentarios en estos.

Semana 4#

Costes

Para el TCO se nos pedía y hemos realizado nuevos análisis en lo referente al número de usuarios que podría llegar a almacenar nuestra aplicación, si éste subiera aumentaría el coste de operación ya que sería necesario ampliar servicios de github, servidores…

También volvemos a calcular los usuarios por rol estimados para que la aplicación sea rentable en tres tipos: optimista, realista y pesimista.

Por último se cambia la manera de desplegar el TCO en capex y opex.

Consideraciones de la aplicación

Para solucionar la velocidad de chequeos el cliente el que tiene que añadir un token a a la aplicación y realizar las llamadas a la API, recae en este el riesgo y por tanto si un cliente tiene un token inválido o a excedido el límite de llamadas a la api tendrá que crearse uno nuevo o esperarse. Aún así es complicado que se llegue a dar este límite.

Para el análisis del rendimiento, el análisis de un usuarios tarda como mucho 5 segundos, dependiendo de la cantidad de datos del usuario, pero por ejemplo, para saber cuánto tarda en evaluar a X usuarios para formar un grupo lo sabremos la semana que viene cuando esto sea implementado.

Hemos realizado un exhaustivo análisis sobre gitflow y goldenflow y nos hemos decantado por una versión de gitflow que se adecúa a nuestras necesidades.

Rendimiento de equipo

Hemos dado una vuelta a la manera de evaluar al equipo en cuanto a rendimiento, se mantienen las tablas que teníamos por subgrupo (debido al feedback positivo del mismo) y añadimos también el análisis individual de cada miembro (anónimo). Para realizar este análisis hemos elaborado unas fórmulas en una tabla de excel que unifican la evaluación del grupo completo, cambiando según el rol.

De momento ningún miembro no ha dejado de optar al 10.

Riesgos

Hemos encontrado nuevos problemas que no suponían riesgos; con los usuarios pilotos del equipo 7 para el que estableceremos un calendario bidireccional y un problema de gestión de equipos que ha sido dividida en backend y frontend como principal subdivisión pese a seguir habiendo roles del apartado. Las medidas tomadas serán evaluadas para el próximo sprint viendo cuál ha sido el rendimiento.

Presentación

Dejamos reflejado a los responsables de distintas tareas de nuestro proyecto para ejemplificar la metodología de encargo de tareas del equipo.

Semana 5#

Código

Se ha realizado un trabajo más superficial del código reformateo y limpiado en su mayoría.

Presentación

Durante esta semana se ha preparado la presentación el coordinador del grupo al no poder nuestro presentador habitual ir a la sesión de retrospectiva. Se habla de las mecánicas, CA, tablas con horas…

Semana 6#

Presentación

Se trabaja sobre las diapositivas con el feedback que se dió en la última semana y se eliminan unas con capturas ilegibles al fondo de la clase además de algunas faltas ortográficas.

Costes

Se eliminan datos que se catalogaron como redundantes, y se buscan estimaciones de costes menos lineares. Se reajustan los costes teniendo en cuenta que seríamos nosotros los encargados de realizar las peticiones a la API.

Documentación

Se pasa toda la documentación a Markdown y se despliega un Docusaurus con esta en https://it-talent-wiki.vercel.app/ . Se redacta también el Contribute.md y los aspectos legales de nuestra aplicación.

Gestión del Tiempo

Durante el transcurso de las últimas dos semanas se toma en cuenta el tiempo de visualización de las píldoras teóricas como “Formación”.

Semana 7#

Presentación

Se repasa la presentación para evitar la poca claridad de la fuente con los fondos seleccionados. Se hace uso de zoom para la DEMO ya que la fuente era demasiado pequeña en algunas vistas y hacía que fueran ilegibles. También se pasan los storyboard a blanco y negro siguiendo lo recomendado en la píldora teórica. Se añade una diapositiva de puntos de historia VS tiempo consumido.

Empresas Piloto

Se revisan los usuarios piloto (empresas) que se creen menos probable que vayan a contestar y se eliminan de la presentación (estaban como "Pendiente de respuesta").

Presentador

Se prepara un Elevator Pitch más claro cohesionandolo con el Killer Opener ya existente. También se hará uso de los actores del killer opener y storyboard para el resto de la presentación con el objetivo de dar una "storyline".

Aplicación

Se añade una API al desarrollo para validar los correos electrónicos usados y se añade el coste de esta al Opex.

Semana 8#

Presentación

Se cuida que no haya ninguna diapositiva cuyo formato de imagen no permita reconocer los textos en esta. Se atiende a lo dicho en clas y se incluye una matriz con el esfuerzo en horas y el rendimiento estipulado por nuestro grupo con todos los integrantes.

Demo

Se usan datos realistas para la DEMO para los apartados de Candidatos y Representantes. Se aportan más gráficas para mostrar los datos para que quede más profesional.

Presentador

Cuida el movimiento por el espacio designado a presentar para no marear a la audiencia y procura, al mostrar alguna gráfica, desarrollar, mencionar o explicar algo de esta y no pasar sin comentarla.

Costes

A mayor número de clientes los costes varían; El personal de soporte aumentará si lo requiere la plataforma.

Usuarios Pilotos

Se habla con los usuarios piloto y tratamos de dejar claro cuál es la fecha límite para recibir su feedback, para tener tiempo a tomar acciones de consolidación en función a este.

Semana 9#

Presentación

Creamos un nuevo anuncio con el feedback aportado en la anterior clase sobre el existente. Se realiza una diapositiva que refleje mejor la mejora del rendimiento de un integrante con respecto a la semana anterior.

Usuarios Potenciales

Se repiensan los usuarios potenciales de nuestra aplicación al no tener datos realistas o suficientemente justificados de personas que USEN o puedan llegar a usarla en algún momento.

Demo

Nos cercioramos de que en el video de la demo se vaya directamente a las funcionalidades core sin pasar por otras como la edición de perfiles. Se incluyen los ToS en el registro.

Presentador

El presentador practica un ritmo constante de presentación para no subirlo y que se pierdan conceptos por ello.

Semana 10#

Presentación

Se evita hablar de cosas que son generales o iguales para todos los grupos y al dar los datos pesistas u optimistas se acompaña de una explicación de cómo se podrían dar. Procura que pese a tener confirmados algunas empresas, la búsqueda de más empresas piloto sigue activa.

DEMO

Se procura que exista una correlación con el anuncio y la DEMO para que haya cierta linearidad o hilo en esta y no sea una ristra de funcionalidades.

Aplicación

Se trabaja en planear la adición de un modo claro en la aplicación. Se trabaja una serie de bugs reportados por los usuarios pilotos.

Semana 11#

Marketing

Se realiza un business plan claro, se valora la aplicación y se redactan las oportunidades de inversion apoyado por investigaciones y estudios de mercado. Se retira la Keyword "Equipos" del SEO.

Presentación

Se elimina el apartado del Commitment Agreement ya que a estas alturas no es necesario incluirlo.

Aplicación

Se arreglan una serie de bugs reportados por los usuarios pilotos.

Presentador

Fernando se encargará de tener un micrófono para él en la presentación o de alzar la voz en caso de no ser posible un segundo micrófono. También se trabaja evitar términos más técnicos durante la presentación como Capex, Opex, Matchmaking... En su lugar se usaran otros como por ejemplo "Coste Operacional".

Semana 12#

Presentación

Se van a imprimir varios reportes con las estadistícas de los github de cuentas de la universidad. Fernando se preocupará de mantener un volumen alto durante el killer opener (no tiene micro de momento). Por último se eliminan términos de la presentación que no entienda algún espectador ajeno a la asignatura de ISPP y se añaden las impresiones de las RRSS para el WPL.

DEMO

Se han aplicado cambios sobre la DEMO tras recibir el feedback de la semana pasada (música triste...)

Anuncio de inversores

Se eliminan incoherencias de la imagen y el diálogo que se vieron en el PPL.

Marketing

Se elimina la keyword "Team Building".