Hackathon contra la crisis COVID-19

Participar en una hackathon no es para nada fácil y pone a prueba tus habilidades, tanto de trabajo en equipo como en tu especialidad dentro del equipo.

Escribo este artículo para contar mi experiencia como Dart Developer & Cloud Engineer en un equipo en una hackathon. Además, mostrar y explicar la arquitectura implementada para el proyecto en menos de 48 horas.

Nombre de la Hackathon: Creamos Juntos
Fechas: 05–07 de Marzo del 2021
Reto: ¿Cómo utilizamos la información alrededor de la crisis sanitaria para darle soporte al gobierno y a la población en la estrategia de vacunación?
URL: https://www.creamosjuntos.com.pe/

Equipo:

- Juan José León Camilo — Project Manager & Flutter Developer
- Jhunior Chavez Cruz — UX Designer
- Gabriela Rojas Castro — UI Designer
- Wilmer Huillca Ayma — Brand Manager

A continuación un pequeño spoiler de la arquitectura implementada. Si te interesa cómo llegué a esto, sigue leyendo este artículo.

Día 0

Todo comienza con una idea. Pensarla, discutirla y moldearla, antes incluso de inscribir al equipo. La idea que se nos ocurrió este día para el reto fue crear una aplicación Web y Móvil en donde cualquier persona pueda inscribir a adultos mayores, con la finalidad de tener una base de datos actualizada con la ubicación de las personas de riego en el Perú. Con esta data podríamos haber generado un mapa para saber, a nivel de distrito, en qué lugares existe más concentración de personas de riegos, lo que se traduce en una herramienta logística que ayude a saber a dónde enviar más vacunas.

Además, estábamos conscientes del contexto social. La mayor parte de la población de adultos mayores no sabe utilizar la tecnología, a lo mucho puede realizar una llamada. Nuestra propuesta es crear un movimiento de voluntarios digitales que puedan ayudar a la causa utilizando las aplicación para registrar a las personas mayores. Pero también ellos mismos podrían ofrecerse para actuar como agentes de un call center que nosotros implementaríamos. En otras palabras, las personas mayores podrían llamar a un número y pasaríamos esa llamada a uno de nuestros voluntarios registrados; y de esta manera llegar a más población vulnerable.

Luego de tener la idea, necesitábamos el equipo. Y además de lo técnico (Backend/Frontend), para esta idea necesitábamos armar una marca para el movimiento que íbamos a crear; se debería convencer a los jóvenes para que se registren como voluntarios. Así que buscamos a un Brand Manager. Y adicionalmente, dentro del proceso de desarrollo de aplicaciones se necesita un Diseñador UX y un Diseñador UI.

Con idea y equipo, recién nos decidimos a inscribimos.

Día 1

La hackathon empezaba a las 8 de la noche de este día. Para mí, todo el día fue momento perfecto para pensar cómo implementar la idea que nos habíamos propuesto. Pensar desde la estructura de la base de datos hasta cómo se iba a implementar el call center.

Luego de la inauguración virtual, con el equipo nos pusimos a hablar de la idea. Pusimos en una pizarra el posible flujo que tendría la aplicación. Además hablamos de cómo íbamos a dividir las tareas en el tiempo: ¿Qué tareas eran dependientes de otras? ¿Qué tareas se tenían que hacer primero? Y de acuerdo a eso ir armando los horarios: ¿Quiénes podían irse a dormir y deberían despertar mañana temprano? ¿Quiénes deberían quedarse a terminar sus tareas y podían despertarse mañana tarde?

Lo bueno de desarrollar el backend y la arquitectura de las aplicaciones es que casi nunca tienes tareas dependientes con otras personas. Podía avanzar a mis anchas, así que era uno de los que debía quedarse hasta tarde. En esa noche hice las configuraciones iniciales del proyecto, empecé a crear la base de datos y a armar la primera parte de la arquitectura:

Usaría Cloud Firestore como base de datos y el SDK de Firebase para conectarme con la base de datos. Desarrollar con Firebase es fácil y rápido, y nos da funcionalidades extra sin hacer mayor esfuerzo en el desarrollo, como el manejo de la cache o el guardado de datos en modo offline.

Para registrar la ubicación de la persona teníamos dos opciones: Con la posición exacta mediante coordenadas o una posición a nivel de distrito preguntando departamento/provincia/distrito.
Optamos por la segunda por cuestión de seguridad y versatilidad. Es más complicado comunicar a otra persona una posición exacta mediante coordenadas, además la dirección exacta puede considerarse como un dato sensible que no se debería dar una persona cualquiera. Otra razón es qué tanto le iba a servir esa data al estado. Sólo con el dato departamento/provincia/distrito, el estado podría armar un plan logístico interesante.

Esa noche también armé una lógica simple de Ubigeo (departamento/provincia/distrito) para que se pueda usar tanto en el backend como en el frontend. Usé esta base de datos para armar esa lógica:

Con eso terminé el día, aún pensando cómo iba a hacer el call center.

Día 2

Como fue de esperarse me levanté tarde. Ya se estaba empezando a crear la marca para el movimiento de voluntarios digitales. Además el prototipo ya estaba avanzado en un 65%.
Hasta este punto ya teníamos asignado un mentor y ya estaba en el chat de nuestro equipo. Nos dio una idea interesante: realizar una encuesta para validar nuestra idea y ver qué tan dispuestos están los jóvenes para convertirse en voluntarios. Así, parte del equipo se puso manos a la obra con esa encuesta.

Comencé a buscar servicios que me pudieran ayudar a implementar nuestro call center. Filtré los servicios según la disponibilidad en Perú, el precio, la funcionalidad para direccionar las llamadas y según la facilidad de implementación. Estos fueron los mejores candidatos:

Twilio - Communication APIs for SMS, Voice, Video and AuthenticationCaters to customers' tastes at scalewith email from Twilio SendGrid Latifah Lake, Product Marketing Manager Marcie…www.twilio.comMessageBird | Zero friction, omnichannel communicationAPIs, tools, customer support software, and a global connectivity network to elevate business to customer…www.messagebird.comCommunication Platform for SMS APIs, Voice APIs, and SIP Trunking.New Introducing the Number Lookup API Enterprise grade communications stack for your business Explore our solutions…www.plivo.com

Todos estos cumplían con los anteriores filtros, pero Twilio era el más fácil de implementar. El mismo servicio ofrecía pequeños tutoriales que me dieron mejor panorama de cómo desarrollar el call center de forma rápida en poco tiempo (justo lo que necesitaba).

En la arquitectura, Twilio recibe las llamadas mediante un número proporcionado por ellos. Cada vez que entra una llamada, el servicio envía una petición a un servidor configurado por nosotros, y ese servidor tiene que retornar como respuesta los pasos a seguir: Puedes hacer que un bot responda, reproducir un archivo de sonido, dirigir esa llamada a otro celular, etc. Con esta lógica es como armé la siguiente parte de la arquitectura:

El “servidor” que recibe la petición de Twilio es una Cloud function (Función serverless), que ejecuta una instancia de una función cada vez que se recibe una petición. Esto último hace que esta parte de la arquitectura sea escalable, ya que no importa el número de llamadas que se haga, ¡Nunca se va a caer el “servidor”!

Esta función lo que hace es obtener de la base de datos los voluntarios registrados y aplica un algoritmo de selección que prioriza los nuevos voluntarios sin ninguna llamada respondida. Luego esa función retorna a Twilio la orden de dirigir esa llamada al teléfono del voluntario seleccionado.

Y con esto ya tenía configurado un call center escalable, eficiente y con integración a nuestra base de datos en menos de 6 horas.

Para este punto ya se había creado una marca y un nombre para el movimiento que queríamos armar: #MeSumo

Además el prototipo ya estaba terminado y la aplicación ya se estaba desarrollando.

No fui parte de ninguno de estos procesos, pero viendo los resultados puedo decir que el trabajo ha sido arduo y ha sido completado satisfactoriamente en el poco tiempo que tenían. Todo el equipo, aunque separados, estábamos trabajando a toda máquina y bien.

Casi finalizando el día ya había acabado de implementar todo el backend de la aplicación y de probar el call center. Ya no tenía mucho que hacer, para el día siguiente estaba pensando en resolver los bugs que surgieran o ayudar preparando el material para la entrega final. Nunca me esperé seguir trabajando en la arquitectura.

Día 3

Desperté tarde, otra vez. No me dieron tiempo de hacer nada. Me comunicaron el resultado de la encuesta que realizamos, y la mayor conclusión que se sacó es que se necesita habilitar Whatsapp como otro canal para inscribir a las personas. No lo pensé más y me puse a investigar cómo hacer un bot para Whatsapp.

Cuando inicié esta tarea sí sentí que tenía poco tiempo, así que utilicé el primer servicio que vi que podría implementar rápido, Chat-API: https://chat-api.com/en/

Dentro del servicio podía conectar cualquier número de celular mediante Whatsapp Web. Luego, obtenía los mensajes que llegaban a ese número y los enviaba a un servidor configurado por nosotros para que hagamos lo que sea ahí. Con esta lógica, y de forma casi poética, construí la siguiente parte de la arquitectura:

Cada vez que llega un mensaje del celular de una persona, Chat-api lo recoge y lo manda a una Cloud function en donde se procesa el mensaje, se guarda el estado en la base de datos y se envía la respuesta de regreso al servicio para que se envíe al chat de la persona.

Para el almuerzo yo ya había terminado de programar el bot y toda la arquitectura ya estaba implementada:

La conexión con RENIEC se utilizaba para obtener y validar los datos de las personas que se registraban mediante la aplicación. Esta parte fue simulada ya que se necesita realizar un trámite para poder tener acceso a la API.

Mientras se estaba terminando el desarrollo de la app, yo me puse a terminar los entregables finales. Esto último fue lo más estresante, no por lo trabajoso ni complicado, sino por el hecho de trabajarlo tan cerca del tiempo de entrega. A una hora del final, ya se tenían casi todos los entregables, sólo faltaba un video que muestre lo que habíamos hecho. Juan José, nuestro Project Manager y Frontend developer, se encargó de tan pesada tarea.

Al final, faltando 5 minutos, enviamos el video, y con eso, habíamos terminado con la hackatón, o al menos por ahora. Fue momento de celebración para el equipo, habíamos logrado hacer varias cosas impresionantes en tan poco tiempo. Abrimos una botella de vino y, luego de un pequeño brindis, nos pusimos a jugar un juego de cartas (con el que estamos enviciados actualmente)

Al día siguiente nos dieron la noticia de que no pasamos a la final y ahí terminó definitivamente nuestra participación. Mi reflexión sobre esta experiencia, y el porqué también escribo este artículo, es que tenemos un equipo con miembros especializados en diferentes áreas, un equipo capaz de implementar grandes cosas en poco tiempo. Pero a pesar de todo, siempre se necesitan nuevos miembros que sumen más especialidades al equipo.

Acerca de nuestra idea, no creo que haya sido mala (los ganadores tuvieron una idea similar), sino que nos faltó vender mejor la idea y mostrar de una mejor manera todo lo que hicimos y lo que somos capaces de hacer. Una bonita experiencia muy importante para nuestras próximas hackathones.