Guión para la presentación de seguimiento del Sprint 3
| Guión preliminar por | Presentador | Tiempo |
|---|---|---|
| José María García | Álvaro Bernal | |
| Álvaro González | Nicolás Herrera |
Killer Opener + Elevator Pitch
La mitocondria
Pero bueno, sin más dilación, vamos a empezar con la presentación.
Figura 1. Portada de la presentación.
Somos Harmony y estamos revolucionando el día a día de las ONG. Nuestra aplicación no es solo una herramienta, es un salto hacia delante en la asistencia social. Nuestro objetivo es automatizar las tareas más repetitivas, reduciendo la carga administrativa y permitiendo a las ONG enfocarse en lo que realmente importa: ayudar a quienes más lo necesitan.
Y no hacemos esto a pasos de ciego, conocemos el problema. Hemos hablado con ONGs y hemos visto cómo se sienten frustradas por la dificultad de mantener todos sus datos con métodos anticuados como hojas de cálculo de Excel y registros en papel. Además, este desperdicio de tiempo les impide dedicarle más tiempo a sus seres queridos o a ellos mismos.
Figura 2. Contexto.
A día de hoy ya proporcionamos nuestros servicios a ACAT (asociación ciudadana de ayuda al toxicómano), que se dedica a ayudar a personas con adicciones, y a Cirio y Costal que reparte alimentos a familias en situación de vulnerabilidad. Ambas hacen de nuestra comunidad un lugar mejor, y queremos que más ONGs se unan a nosotros porque juntos podemos hacer mucho más, y hacedme caso cuando os digo que no conocéis las limitaciones de las formas de almacenar información de una ONG que se aferra a los métodos que antes usaban ACAT y Cirio y Costal hasta que tenéis un sistema en mano que hace cosas que ni siquiera sabíais que necesitábais.
Figura 3. Objetivos de harmony.
En Harmony estamos comprometidos a modernizar la gestión de las ONGs, simplificando procesos, fortaleciendo la comunicación interna y optimizando recursos para que estas organizaciones se enfoquen en lo más importante: brindar ayuda a quienes más lo necesitan.
- Transición con lo siguiente: "Y ¿por qué confiar en nosotros?" (pasamos a la siguiente diapositiva)
Análisis de Competidores
Figura 4. Análisis de competidores.
Para empezar, cada ONG es un mundo, cada una tiene sus necesidades particulares y por eso no creemos que haya una solución única.
Nosotros hemos identificado dos empresas que ofrecen gestión de alimentos e inventario para ONGs, la primera es Stockio, una empresa española que proporciona un software para la gestión de inventarios y almacenes, pero no para la gestión de beneficiarios, (silencio) cosa que sí hace Pantrysoft además de la gestión de inventario, pero al estar ubicada en los Estados Unidos, no les garantiza a las ONGs españolas el cumplimiento de las leyes de protección de datos europeas.
De igual forma, estas empresas no ofrecen una solución que se pueda adaptar a todas las necesidades de cada ONG.
Figura 5. Herramientas open source.
Y por otra parte, existen una serie de herramientas open source que consideramos que podrían ser de utilidad para la gestión de alimentos y beneficiarios de las ONGs, como Django-CRM o CiviCRM, pero tras algo más de análisis hemos visto que están más orientadas a la gestión de clientes empresariales y que no se adaptan a las necesidades de las ONGs.
Y ¿en qué nos diferenciamos nosotros? Pues en que ofrecemos una solución que se adapta a las necesidades de cada ONG, esto significa que trabajaremos conjuntamente con ellas para lograr cumplir todas sus necesidades y que además es una solución open source, lo que permite a las ONGs tener un mayor control sobre la aplicación y poder adaptarla a sus necesidades en cualquier momento.
Anuncio
Figura 6. Advertisement.
Y para dejarlo más claro, os vamos a mostrar un anuncio en el que se refleja nuestra misión.
Se reproduciría el anuncio de forma que esperamos a que acabe (duración aprox. 30 segundos)
Aspectos legales del proyecto
Figura 7. Aspectos legales del proyecto.
Tras este paseo con AL, vamos a entrar en temas más serios, en los aspectos legales de nuestro proyecto, y quiero comentar antes de empezar que nos hemos apoyado en la herramienta CLAUDETTE para redactarlo, tomando el feedback que considerábamos que aplicaba en nuestro caso.
Para esto, hemos hecho 2 divisiones de nuestro marco legal, el uso de nuestro servicio, y el uso únicamente de nuestro software.
Uso del servicio
Para esta en concreto se ha definido el Customer Agreement, el cual recoge todos los términos y condiciones a los que se somete un cliente al contratar un servicio de la empresa Harmony. Entre estos encontramos pagos y tarifas, acuerdos de nivel de servicio definidos en iTop, política de privacidad etc.
Al preguntarle a CLAUDETTE por las posibles cláusulas abusivas, nos dijo que como tal había cuatro cláusulas potencialmente abusivas:
OPCIONAL (posibilidad de recortar si véis que es mucha tela)
- Respecto a los cambios en la política de privacidad
- Limitación de la responsabilidad: Harmony no será responsable de ningún daño indirecto, incidental, especial, consecuente o punitivo que surja de su uso o imposibilidad de utilizar el Servicio.
- Terminación: Podremos dar por terminado o suspender su acceso al Servicio de forma inmediata, previo aviso y enviando copia de los datos de sus beneficiarios como consecuencia de un incumplimiento de este Acuerdo.
- Método de pago: si tu método de pago falla en repetidas ocasiones, nos reservamos el derecho a suspender o terminar tu acceso al servicio, aunque una copia de los datos almacenados será primero recogida y posteriormente enviada a usted.
De las cuatro, como grupo consideramos realmente abusivas dos, la 1 y la 2. Las otras no las consideramos abusivas, porque ya establecemos que se manda una copia de los datos para que no se queden sin ellos, consideramos que al ser el software open source pueden seguir usándolo o si quieren pagar el servicio de nuevo sería sencillo ponerlo de nuevo en marcha. Además, que un no-pago continuado es romper el acuerdo por parte del cliente; por eso no las consideramos abusivas
P.D.: De cara a la presentación no es necesario que se diga todo esto, basta con indicar que teníamos varias y que se han solucionado aquellas que eran más relevantes.
La razón por la cual no se consideran abusivas la 3) y la 4) es una extracción de una conversación que mantuvo José María con Antonio en el canal de general-pptx, para cualquier duda, contacta con alguno de los dos miembros (Antonio fue el que me dijo la razón de la última cláusula, pero en 15 minutos no daría tiempo de todo).
FIN OPCIONAL
Es importante destacar que tenemos un consentimiento informado con el cliente, es decir, gracias a la cláusula 1) corregimos unos aspectos de la política de privacidad, para que si cambiara en algún momento, se notificaría al cliente de este cambio y se actualizaría el acuerdo de cliente tras cinco días hábiles y se le volvería a notificar a los usuarios del cambio en la política.
Además hemos añadido una sección en la que se detallan las tarifas a abonar por parte de los clientes y en el soporte técnico hemos incluido un SLA que según el tipo de solicitud, se tiene un tiempo de respuesta y un límite de peticiones.
A su vez, también definimos un documento de Protección de Datos, en el que nos comprometemos a proteger la privacidad y los datos de los clientes y usuarios que contraten un servicio. Este reglamento se fundamenta principalmente en la LOPD,s LOPDGDD y el RGPD. (Acortaciones)
En caso de que alguien estuviera más interesado en este tema, podeis encontrar toda la información respecto a estos documentos en la sección “Legal” de nuestro docusaurus.
Without service
Por otro lado, si haces uso únicamente de nuestro software, te atienes a los términos en este caso no de nuestros términos y condiciones, sino de la licencia AGPL.
Análisis del TCO
Figura 8. Análisis del TCO.
Para nuestro servicio hemos calculado un coste total de propiedad de unos 90916,22€ (silencio). en un periodo de 2 año OUCH,
Pero bueno, vamos a analizarlo:
- El CapEx según nuestros cálculos compone un poco más de la mitad de este coste, 49521,42€. De aquí la mayoría del coste se va en el personal que contratamos, que son unos 39,000€, de los cuales 34,000€ durante el periodo de desarrollo, y el resto viene de los costes de material y licencias, que son unos 1,000€.
- El OpEx por otra parte son unos 42,000€, la mayoría se va en el personal que necesitamos para cumplir con las legislaciones de protección de datos como GPDR y el SLA de atención al cliente, que son unos 40,000€, y el resto viene de los costes de despliegue, que son rozan los 2,200€.
- Además hemos añadido un fondo del 15% para planes de contingencia. Porque esperamos que pueda haber desviaciones y es importante estar preparados para ello.
Quiero destacar que los costes OpEx están sujetos a cambios, ya que dependemos del precio que pongan servicios de terceros como, por ejemplo, pasa con el hosting del código y la integración continua, que aunque actualmente son gratuitas debido a la naturaleza Open Source de nuestro proyecto, si cambiara a tratarse como proyectos closed source, el TCO de estos dos primeros años aumentarían en 57€.
De igual forma estimamos que no necesitaremos durante este tiempo una licencia de sendgrid para más de 100 emails diarios por la naturaleza de nuestro servicio, pero si hiciese falta, el coste añadido sería de 480€.
ROI
Figura 9. Retorno de la inversión.
Y bien, 91.000€ no es poco dinero, nos hace falta estar seguros de que vamos a recuperar esta inversión. Por ello hemos hecho un análisis tratando de predecir el crecimiento de nuestra base de clientes y el retorno de la inversión en situaciones optimistas, pesimistas y más probables.
Como veis en la gráfica, los costes son un poco más grandes al principio, en el periodo de desarrollo, pero conforme entramos en producción bajan, a la vez que aumentan los ingresos. Según hemos calculado nuestro servicio generaría más de lo que cuesta a partir de los 30 meses aproximadamente tanto en el escenario optimista como en el más probable, y en el pesimista, que asume un crecimiento prácticamente nulo de clientes, no parece que vayamos a recuperar la inversión.
Seguimiento de costes + burndown
Y ya que vemos aquí en los primeros cuatro meses el costo del desarrollo, vamos a hacer un poquito de zoom ahi para ver cómo vamos:
Figura 10. Seguimiento de costes.
La línea azul son los costes de los que estamos hablando, aquí representados de forma acumulativa, como vemos en un principio nos encontrábamos por encima de los esperado, pero en esta última semana se ve un descenso ya que estamos empezando a compensar este exceso de costes y así volver a la línea esperada.
Pero bueno, tampoco es una preocupación porque como vemos con la gráfica rosa, hemos completado más puntos de historia de lo que esperábamos, lo que significa que estamos avanzo bien y tenemos margen de maniobra para corregir estas desviaciones.
Figura 11. Burndown.
El Burn Down se ha actualizado antes de mergear las últimas pull requests por lo que no se acerca tanto al ideal, sin embargo, podemos confirmar que la situación actual con respecto al desarrollo de las tareas no es ni mucho menos alarmante, sino todo lo contrario.
Equipo y estado del CA
Figura 12. Commitment Agreement Global.
Continuando con la temática del seguimiento veamos como va el equipo y el estado del CA.
OPCIONAL, SOLO SI HAY TIEMPO
Como recordatorio, nosotros medimos en este apartado 5 puntos principales: El cumplimiento mínimo de una dedicación de 10 horas semanales, compensables a través de un sistema de compensación de tiempo si una semana se echa más y otra menos tiempo, el respeto al horario de disponibilidad establecido, la realización de las tareas asignadas dentro de plazos o justificación de su retraso, y por ultimo la correcta aplicación del sistema de avisos.
FINALIZA OPCIONAL
Figura 12. Estado del CA.
Figura 13. Estado del CA.
A lo largo del proyecto este cumpolimiento ha sido excelente tanto a nivel general como individual, quitando alguna semana puntual en la que algún miembro hubiera recibido algún aviso por no cumplir con la cláusula relacionada con el cumplimiento de tareas o justificación de retrasos.
Especialmente este Sprint ha sido excepcional sin ninguna incidencia.
Changelog
Figura 13. Registro de cambios de ACAT en el sprint 3 primera parte
Aparte de gestionar problemas, me gustaría comentar algunos de las funcionalidades que hemos implementado, para ello hemos realizado en cada repositorio una release con su changelog autogenerado cómo es el caso de ACAT. Para recoger los cambios significativos en este repositorio le hemos pasado a GPT el changelog y nos ha generado un resumen de los cambios más importantes (Mencionar por encima los de la diapositiva si hay tiempo).
Demo
Figura 14. Demo.
Hoy os vamos a enseñar el sistema ACAT.
Dar al play
Hola, en esta demo os vamos a enseñar cuáles han sido los últimos cambios que tenemos implementados en la aplicación, el PWA, el botón de emergencia, la paginación y las validaciones.
Para el PWA, basta con dirigirse a esta pestaña donde pone "Instalar ACAT", instalamos la aplicación y ya podríamos hacer uso de la PWA.
El botón de emergencia funciona de tal manera que si le damos y necesitamos ayuda, se nos mostrará un mensaje en el que se nos indica que se le ha enviado un correo a los desarrolladores para que solucionen el problema lo más pronto posible.
Ahora para mostrar la paginación, iniciamos sesión y nos dirigimos por ejemplo a las intervenciones y aquí podemos ver que nuestro amigo Juan está yendo más de lo normal a la asociación, y la paginación funciona correctamente.
Por último, las validaciones se aplican de manera que si creamos una intervención, ponemos a amigo Juan como beneficiario y le ponemos una fecha de atención futura que no está permitida por el sistema y le damos a Registrar; primero tenemos que rellenar el campo técnico y segundo nos saltará que no podemos poner una fecha a futuro.
Y estos son todos los cambios que ha sufrido nuestra aplicación.
Aunque nos gustaría enseñar más cosas, ahora le toca a [NOMBRE] hacer un poco de retrospectiva de este Sprint.
Retrospectiva
[Enlace entre la demo y la retrospectiva: la demo que acabamos de observar es el resultado del rendimiento y esfuerzo del equipo. Así que pasemos a hablar de ello.]
Rendimiento
Aquí podemos ver una gráfica que representa rendimiento del equipo durante la primera semana del Sprint 3. Lo ideal es que la mayoría de burbujas se encuentren lo más a la derecha posible, pues esto implica una puntuación del rendimiento más elevada. De hecho, esto es lo que ocurre en este caso, por lo que podemos ver que el equipo ha tenido un buen rendimiento durante esta semana.
Programación de reuniones
Duarante el Sprint 2 decidimos que íbamos a comenzar a utilizar Calendly para mejorar la programación de las reuniones y en este Sprint 3 a hemos comenzado a utilizarlo. Aquí podéis ver un ejemplo de una reunión que hemos concertado con una de las ONGs para realizar el seguimiento del proyecto.
Calidad
En cuanto a la medición de la calidad, nosotros hemos empleado la herramienta Codacy para que puntue la calidad de nuestro código. Como vemos, durante este Sprint 3 hemos seguido manteniendo el nivel de calidad más alto posible en cada uno de nuestros repositorios, como veníamos haciendo durante los primeros dos sprints. [Opcional: Esto es en parte debido a que tenemos automatizado un análisis de calidad de código que se ejecuta cada vez que se realiza una pull request, lo que nos alerta de posibles problemas de calidad de código antes de que se fusionen en la rama de desarrollo].
Gestión de problemas
Sobre la gestión de problemas, tenemos buenas noticias en esta ocasión, ya que no hemos detectado nigún problema reseñable durante la primera semana del Sprint 3, así que, nuestro decimo-octavo integrante, AL, puede descansar tranquilamente (al menos por ahora).
Reloj del proyecto
En relación al tiempo invertido, durante la primera semana de este sprint hemos dedicado unas 140 horas al proyecto. Es cierto que es algo menos de lo esperado (170 horas), pero esto se entiende mejor si vemos el tiempo total invertido en el proeycto hasta ahora.
Como vemos, aún estamos algo más de 200 horas por encima de lo previsto para estas fechas. Esto se debe a que durante las primeras semanas invertimos más tiempo del previsto, por lo que en estos momentos estamos aligerando un poco el ritmo de trabajo.
Plan de pruebas
Otro aspecto importante en nuestro proyecto es la realización de pruebas. Por la parte del backend, nos hemos centrado en hacer tests unitarios y de integración. Además, tenemos previsto realizar tests de carga próximamente para comprobar cómo se comporta la aplicación con un número elevado de usuarios. Por la parte del frontend, hemos estado realizando tests unitarios, empleando mocks para simular el comportamiento funciones como las llamadas a la API. También hemos realizado tests para comporbar el correcto renderizado de los componentes de la aplicación. [Opcional: cabe mencionar que también tenemos definida una metodología para realizar las pruebas, de forma que todas las funcionalidades que se suben a la rama de desarrollo deben estar acompañadas de tests que las validen. Además, estos tests deben ser realizados por un miembro del equipo que no sea el desarrollador de la funcionalidad en cuestión. Consideramos que esto sirve para aumentar la calidad de nuestro código].
Usuarios piloto
Estado
Con respecto a los usuarios piloto, que en nuestro caso son tanto los compañeros del grupo 1 de ISPP como los miembros de las ONGs a las que estamos prestando servicio, ACAT y Cirio y Costal, están tanto contactados como informados como involucrados. Además, han firmado el acuerdo de compromiso conjunto que establece una serie de acuerdos relacionados con el recibimiento de feedback, como vamos a ver a continuación.
Acuerdo de compromiso
Hay dos cláusulas comunes en el Acuerdo de Compromiso de cada tipo de usuario piloto: cumplir las deadlines y tener una comunicación fluida. Para el caso concreto de los usuarios del grupo 1, también deben usar iTop, Clockify y en caso de que no nos guste el tipo de feedback que nos dan, se comprometen a cambiar de revisor.
Para el caso de las ONGs, lo que deben hacer es probar el prototipo de la aplicación que les corresponda.
Ranking de feedback
Durante estas semanas, hemos tenido varias reuniones con los usuarios piloto, en las que hemos comenzado a recibir su feedback. Como parte de nuestro mecanismo de gestión de feedback, hemos decidido priorizar los cambios que nos proponen los usuarios piloto para establecer el orden en el que ir realizando los cambios. Aquí podemos ver un ranking con los cambios a los que les vamos a dar más prioridad: creación de un usuario maestro que sea el único con permisos para crear otros usuarios en el sistema, implementación de un filtrado por fecha de las intervenciones y traducir de inglés a español los excels que vamos a usar para importar datos en la aplicación.
Calendario
Este es el calendario de usuarios piloto que hemos planificado para el mes de abril. Los días marcados en azul son los días en los que los usarios piloto van a probar la aplicación y los días marcados en amarillo son los días en los que vamos a analizar el feedback que nos han proporcionado.
También podemos ver el calendario de usuarios piloto para el mes de mayo. En este caso, solo hemos planificado una semana de pruebas de la aplicación, tras la cual esperamos recibir el feedback final de los usuarios pilotos para ir concretando la entrega final del proyecto en la fecha prevista.
Planificación
Planificación del Sprint 3
De cara al Sprint 3, estas son las tareas que hemos detectado como prioritatias: creación de un dashboard de estadísticas, uso offline de la aplicación con posterior sincronización, validación del correo electrónico e integración de una pasarela de pago.
Y otras tareas que también tenemos pensado realizar serían: implementación de skeleton loaders, la resolución de las peticiones de los usuarios piloto, el despliegue de la aplicación y el inicio del plan de marketing.
Como venimos haciendo desde el Sprint 2, seguimos gestionando nuestras tareas desde el tablero avanzado de GitHub Projects, que nos permite realizar estimaciones de tiempo y priorizar las tareas de forma sencilla.
Planificación de la fase PPL
También tenemos definida una planificación inicial de la fase PPL (Preparing Project Launch), que incluye la elaboración de una campaña publicitaria, la creación de manuales de usuario y preparación de un plan de lanzamiento de la aplicación.
Uso de la IA
Usos de esta semana
En cuanto al uso de la IA, hemos seguido utilizando GitHub Copilot y ChatGPT para ayudarnos con el código, ChatGPT para ayuda en tareas de documentación y RemoveBG para eliminar el fondo de algunas de las imágenes de esta presentación.
Huella de carbono
También hemos estado investigando acerca de la huella de carbono que generan las IAs que estamos utilizando. Hemos encontrado que cada query produce una emisión de CO2 de 4,32 gramos de CO2, por lo que hemos estimado que nuestro proyecto supone una emisión de algo más de 400 gramos de CO2 por semana (suponiendo que realizamos unas 100 queries semanales).
Debate sobre la IA
Por último tras haber estado usando la IA a lo largo de todo el proyecto, nos encontramos en un buen momento para realizarnos la siguiente pregunta: ¿cómo ha influido el uso de la IA en la eficiencia y productividad de nuestro proyecto? Como aspectos positivos, destacamos que el uso de la IA nos ha permitido automatizar tareas repetitivas y nos ha ayudado a mejorar la calidad de nuestro código y documentación. Sin embargo, también hemos encontrado algunos aspectos negativos, como la dependencia que hemos generado de estas herramientas y el tiempo que hemos tenido que invertir en aprender a utilizarlas. A pesar de esto, creemos que el balance es positivo y que el uso de la IA ha sido beneficioso para nuestro proyecto.
Cierre
Cumplimiento de objetivos
Para finalizar, vemos que hemos cumplido con los diferentes apartados que estaban previstos para la presentación. [Opcional: se pueden mencionar los diferentes apartados si se necesita alargar la presentación para llegar a los 15 minutos].
Fin de la presentación
Os dejamos nuestro correo electrónico por si tenéis alguna duda o sugerencia, y un código QR para que podáis acceder a nuestra landing page. ¡Muchas gracias por vuestra atención!