Ir al contenido
  1. Blog/

Goxo: La aventura pandémica, una historia de transformación tecnológica

·1724 palabras·9 mins· loading · loading · ·
Product Management Desarrollo Tecnológico Transformación Digital Leadership Escalabilidad
Ángel J. Ramos
Autor
Ángel J. Ramos
Staff Cloud Architect @ DoiT
Goxo: La aventura pandémica - Este artículo es parte de una serie.
Parte 1: Este artículo
Goxo pasó de ser una red social para foodies a una plataforma digital para restaurantes, impulsada por la pandemia de COVID-19. Esta entrada detalla cómo escalamos nuestra infraestructura tecnológica, abordamos desafíos técnicos y construimos un equipo ágil para aprovechar la oportunidad. Descubre las lecciones aprendidas en la toma de decisiones y la adaptación en un entorno tecnológico en constante cambio.

Antes de comenzar, un pequeño disclaimer: la siguiente serie de entradas se basa en hechos reales de mi trayectoria profesional, ambientada hace cuatro años en un panorama tecnológico muy, muy lejano. Prepárate para una mirada sin censura al proceso de toma de decisiones técnicas, donde el pasado se encuentra con el presente y donde aguardan muchas lecciones aprendidas. ¡Abróchate el cinturón para un viaje inolvidable!

Todo comenzó en una cena de Navidad en noviembre de 2019, donde el equipo de colaboradores de la por aquel entonces red social Goxo se reunía para despedir un año lleno de retos y aprendizajes. Esos aprendizajes llevaban a la conclusión de que teníamos que pasar de ser una red social para “foodies” a ser una plataforma de marca blanca para la digitalización de los restaurantes, o como nos gustaba resumirlo, el Shopify de los restaurantes.

Pero faltaba una pieza importante. El primer paso para conseguir esa propuesta de valor pasaba por tener un módulo de entrega a domicilio vía un proveedor logístico, con lo cual, las navidades de 2019 me las pasé desarrollando una pequeña pieza de software que precisamente hacía esto, un conjunto de métodos que invocados en un determinado orden conseguían llevar el pedido de un restaurante a la casa de un cliente.

Con el tiempo, la nueva propuesta de valor de Goxo llegó a tener cuatro pilares principales para ayudar a los restaurantes a crecer sus negocios online:

  1. Digitalización de los canales directos de los restaurantes personalizados con su propia imagen de marca, es decir, una web y una app móvil con su look and feel adaptados.
  2. Un servicio completo de entrega a domicilio.
  3. Una plataforma donde entender los datos de tu negocio por los canales digitales, con una serie de dashboards y herramientas que permitían a los restaurantes: retener a sus clientes, mejorar sus ventas (e.g., upsell) y personalizar el servicio para sus usuarios.
  4. Un conjunto de marketplaces de nicho donde se agregaban varios restaurantes que compartían características comunes, por ejemplo, que estuvieran alojados en un mismo centro comercial.

Con el nuevo módulo en producción, empezamos a conseguir nuestros primeros clientes y veíamos luz al final del túnel. Después de mucho esfuerzo, conseguimos monetizar nuestro proyecto. Sin embargo, llegó marzo de 2020 y con esta fecha la crisis del COVID-19 que obligó a todos los restaurantes a cerrar sus localizaciones físicas y, por tanto, sus principales fuentes de beneficios. Pero, ¡oh sorpresa!, aquellos que tenían su canal digital disponible podrían seguir atendiendo a sus clientes. El canal digital se había convertido en la única manera que su negocio podría sobrevivir ante tal incertidumbre.

Debido a este evento, nuestras ventas se dispararon masivamente. En mis clases de producto muchas veces hablamos del product market fit y a mí me gusta resumirlo con esta captura, esa gráfica en forma de palo de hockey en la que pasas de 0 a 100 en horas.

Gráfica de Goxo Product Market Fit
Gráfico del Product Market Fit de Goxo

Este éxito masivo nos obligó a escalar de forma acorde también desde el punto de vista de tecnología. Recordemos que desde el punto de vista técnico en la propuesta de valor de Goxo, por cliente teníamos que:

  1. Generar una web con la imagen de marca del cliente en menos de 24h.
  2. Hacer lo mismo pero en forma de aplicación móvil para Android y para iOS.
  3. Añadir una infraestructura flexible dedicada con su propio dominio para este cliente.

El punto de partida tecnológico que había heredado por razones históricas de otros colaboradores era un poco desalentador:

  1. Infraestructura: 2 máquinas virtuales alojadas en GCP, una de ellas con la base de datos (MongoDB) y la otra con unos 15 microservicios MERN. Ni siquiera había un entorno de preproducción, no había tests y los procesos de integración continua y delivery eran inexistentes. Además, existía una única aplicación móvil proveniente de la red social Goxo que había que refactorizar.
  2. Equipo: un consultor experto en desarrollo de aplicaciones móviles y yo mismo, que por aquel entonces mi ocupación principal era trabajar en el departamento de estrategia de Orange, pero esa historia la contaré otro día.

Ante esta situación, aquí va mi primera lección que os quiero dejar.

En tecnología hay que prepararse para sentirse totalmente incompetente pero aún así ser funcional.

Teníamos ante nosotros una serie de retos tecnológicos difíciles de atacar: ¿cómo íbamos a poder…?

  1. Escalar la base de datos y los microservicios.
  2. Escalar nuestra capacidad y nuestros skills.
  3. Productivizar las aplicaciones móviles.
  4. Crear las aplicaciones web lo más parecidas a las móviles.
  5. Escalar los procesos de administración y facturación.
  6. Explotar los datos.

En esta entrada no voy a contar cómo resolvimos todos los retos, pero voy a dar unas breves pinceladas sobre cómo afrontamos algunos. En siguientes entradas de la serie seguiré comentando los que me parecen más relevantes. No obstante, si tenéis curiosidad o queréis comentar alguno de los retos, no dudéis en escribirme.

Empecemos por cómo atacamos el primero de los retos, el de escalar la base de datos y los microservicios. Como todo buen problema, este tenía una base multicausal, que afrontamos desde varios frentes.

Primero, incrementar el ancho de banda del equipo. Como no teníamos mucho dinero, decidimos buscar una persona de DevOps part-time que nos ayudara unas 10 horas por semana. Esto fue un acierto porque aprendí muchísimo de esta persona y nos permitió retener el conocimiento dentro de la organización, además de sentar las bases de unas buenas prácticas de DevOps.

Establecimos conjuntamente un plan de modernización de la plataforma y, como parte de ese plan, decidimos contanerizar las cargas de trabajo para poder correrlas en un servicio gestionado de Kubernetes (GKE) que nos daría la flexibilidad y granularidad necesaria para centrarnos en la entrega de valor de la plataforma. Por la propia tecnología, nos permitía tener unas plantillas a la hora de desplegar los distintos servicios, utilizando componentes como Helm charts, el artefacto kustomize, etc. Pero, sobre todo, lo que hizo la diferencia fue una buena organización de las distintas piezas en la estructura de ficheros. Estoy omitiendo algunos detalles técnicos por simplificar el texto, pero si tenéis interés, por favor escribidme.

Toda esta migración a GKE la hicimos relativamente rápido, en algo menos de dos meses teníamos al menos lo básico funcionando. Sin embargo, no estuvimos exentos de problemas por el camino. Un gran error que cometimos fue no atacar la escalabilidad de la base de datos mucho antes en el proceso de modernización porque pensábamos que aguantaría la escalada del servicio (o al menos eso nos decían nuestras herramientas de monitorización). Básicamente, lo que pasó es que la máquina de la base de datos murió. Me acuerdo perfectamente que fue en el día de la madre, en medio del servicio de cenas, y pasamos varias horas lanzando nuevamente el sistema, lo cual tuvo un impacto en nuestros clientes y, por extensión, en nuestra cuenta de resultados, concretamente 10.000 euros de impacto.

Otra aprendizaje que me llevo de esta aventura es que una decisión no es buena o mala por el resultado de la misma, sino por el proceso de toma de la propia decisión. Sigo convencido de que la decisión de hacer la migración de la manera que la hicimos fue la correcta. Ahora, a posteriori, quizás hubiera prestado más atención a la base de datos, pero creo que hacerla de la manera que la hicimos nos permitió tener un entendimiento del resto de piezas que luego nos permitiría recrear la base de datos en poco tiempo.

El siguiente reto que me gustaría comentar es el de escalar nuestras capacidades y conocimientos. En este aspecto, utilizamos una pequeña ronda de financiación (FFF) para contratar un pequeño equipo de desarrollo:

  • Un desarrollador móvil de React Native.
  • Dos senior full stack.
  • Dos junior front enders.
  • Un diseñador UX/UI.
  • Incrementar las horas de DevOps.

Además, fuimos a universidades y bootcamps para contratar algunos becarios.

Lo importante de este reto no es la composición del equipo en sí, que obviamente tiene que reflejar las necesidades y estrategia de la compañía, sino cómo, con un presupuesto limitado, contratar talento y hacer un onboarding súper rápido porque cada minuto contaba.

Para ello fue fundamental establecer una propuesta de valor para el empleado atractiva. En nuestro caso, nos apalancamos bastante en el teletrabajo para poder contratar trabajadores alrededor de España con capacidades muy competitivas a precios competitivos.

La velocidad en el onboarding la conseguimos haciendo una combinación entre una buena base de datos de conocimiento, en forma de wiki que hicimos con Notion, y pasar parte de mi tiempo ayudando a hacer más suave el onboarding durante las primeras semanas.

La lección que aprendí en este aspecto es que tienes que darle al equipo autonomía, favorecer su forma de trabajar dándoles herramientas que mejoren su conocimiento del problema y les permitan aprender, y darles un propósito a conseguir dentro de la organización.

En resumen, en este viaje a través de la transformación de Goxo, desde una red social para foodies hasta una plataforma integral para la digitalización de restaurantes, he contado algunos de los retos y las lecciones aprendidas en la toma de decisiones técnicas y estratégicas sobre el devenir de la compañía. La pandemia de COVID jugó un papel esencial al forzar a los restaurantes a depender de canales digitales, lo que impulsó el crecimiento de Goxo. La escalabilidad tecnológica y la construcción de un equipo ágil y bien preparado fueron fundamentales para aprovechar esta oportunidad. Es importante entender que también en tecnología, el proceso de toma de decisiones y la capacidad de adaptación son tan importantes como el resultado final.

En la siguiente entrada me centraré en como atacamos el reto de escalabilidad de las aplicaciones móviles, especialmente su integración y despliegue continuo, también veremos un framework de pensamiento para analizar retos y hacer un planteamiento de soluciones, lo veremos con el ejemplo de cómo desarrollamos la aplicación web clonando la experiencia de usuario de la aplicación móvil.

Espero que os haya gustado esta entrada. Nos vemos en la siguiente, ¡hasta la semana que viene!

Goxo: La aventura pandémica - Este artículo es parte de una serie.
Parte 1: Este artículo

Relacionados

Cuidate a tí mismo: La importancia del bienestar mental y la transformación cultural
·1078 palabras·6 mins· loading · loading
Product Management Cultura Liderazgo Coaching Salud Mental
De la teoría a la práctica: cómo crear y expandir una cultura de producto
·1445 palabras·7 mins· loading · loading
Product Management Cultura Liderazgo Coaching Onboarding Gestión De Equipos
Comunicación y observabilidad en la gestión de producto: estrategias y herramientas clave
·1515 palabras·8 mins· loading · loading
Product Management Communications Observability Estrategia