Soluciones simples y veloces: el valor del prototipado

¿Qué hacemos en operaciones?

Operaciones es muchas cosas y una de esas es poder apagar un incendio en tiempo record. Un incendio no necesariamente es que pasa algo con un cliente, o que un producto no está funcionando bien. Un incendio muchas veces es: se atrasó un proceso clave, hay un caso borde que no vimos antes que complejiza mucho una solución y cosas del estilo.

Muchas veces con el equipo de Ops hemos hablado de cómo se puede cuantificar el éxito de operaciones. Una forma que me gusta es:

Nuestro éxito se mide en base al tiempo que le ahorramos a los otros equipos en sus procesos.

En este contexto, al equipo de operaciones le toca hacer muchos prototipos. En Fintoc, interpretamos el prototipado como probar soluciones de manera manual y hacer automatizaciones de partes aisladas de un proceso con algunos objetivos:

• Sacar métricas: saber qué tan probable es que pase un hecho, saber cuánto demora un proceso, entender la magnitud y desafío de escalar algún producto o funcionalidad, entre otros.
• Definir riesgos y cómo mitigarlos: Podemos entender qué partes del proceso es indispensable que sean automáticas y de acceso limitado.
• Encontrar casos borde: operando un proceso semi-manualmente, podemos darnos cuenta de cosas que no se nos ocurren a primera vista.

Ahora veamos un ejemplo real para entender mejor cómo usamos el prototipado en Fintoc: cómo usamos Retool para elevar la calidad de nuestro proyecto de modernización de la facturación.

Modernizando la facturación

En Fintoc a medida que crecemos, hemos estado trabajando en cómo hacer el proceso de facturación más ágil y que signifique una mejor experiencia para nuestros clientes. Por eso, este mes partimos emitiendo facturas a clientes de Iniciación de Pagos en que Fintoc recauda los fondos y cobramos comisiones, por lo que no tenían saldo pendiente por pagar.

Estas facturas, como todas las de Fintoc, vienen acompañadas de un documento que detalla el uso que se tuvo de nuestros productos en el mes. Teníamos una emergencia: los archivos para los clientes que tenían esta nueva forma de facturar, estaban mandándose en mails separados. Esto no suena tan grave a primera vista, pero en Fintoc tenemos la filosofía de tener un producto simple y limpio, por lo que no estamos dispuestos a “spamear”.

Mandar 1 correo por cada producto, y además un correo por cada factura a fin de mes, serían demasiados correos en un mismo día y no cumplirían su objetivo de informar sobre la facturación mensual: alguno se perdería, alguno sería reenviado sin los demás, algunos no serían leídos, etc...

Resultó ser que más que nunca, en esa fecha el equipo de desarrollo estaba a full capacidad, y armar el sistema de correos de nuevo (y rápido) hubiera atrasado mucho otros proyectos.

Back to basics

En ese momento me acordé de tiempos más antiguos en Fintoc, en que mandábamos mails con los pagos dispersados diariamente usando Retool. Esta es una herramienta de desarrollo de aplicaciones web que diría que es medium to low-code.

Principalmente usa JavaScript pero también soporta Python, y tiene componentes pre-armados y soporta muchísimas integraciones. En Fintoc las que más usamos son BigQuery, Slack y SendGrid.

El problema es que lo que hacíamos con Retool en “los viejos tiempos” era para muy poquitos clientes, y se ejecutaba para cada uno uno por uno. Hoy en día, los procesos deben correr automáticamente, para más de 300 clientes en un instante. Esta es una falencia de Retool: no es reactivo ni tiene “memoria”. Al final cada vez que recargas la página se corren todas las queries y procesos desde 0 y luego se deja de procesar a menos que hagas alguna acción (apretar un botón, modificar un filtro, etc.).

Cómo lo resolví

Hace no mucho tiempo Retool sacó un nuevo feature para suplir este “hoyo”, y en Ops aún no lo habíamos explorado al 100%. Los workflows permiten correr múltiples queries y scripts en serie y en paralelo en base a un trigger. Este puede ser un tiempo o fecha específico o incluso un webhook (mensaje que envía una app a otra para avisar de un evento o cambio).

Partí por hacer un workflow para modelar el proceso para un cliente, en base a un parámetro de “test” que lo identificaría.

Paso a paso

1. Recibir información para identificar al cliente a quién se enviará el mail.
2. Ir a buscar las transacciones del cliente a la base de datos.
3. Ir a buscar la información del cliente (había el desafío de manejar clientes con una dirección de correo y múltiples direcciones).
4. Armar la estructura del archivo procesando los datos con JavaScript.
5. Des-parsearlo para poder enviarlo como CSV.
6. Formatear los datos personalizados por cliente que irían en el mail con JavaScript.
7. Armar la query para enviar usando la integración de Rerool con la API SendGrid.

Luego, armé otro workflow para poder iterar sobre los clientes que debían recibir el archivo y mandarle un webhook (decirle que inicie, y mandarle un identificador del cliente de esa iteración) al workflow individual que mostré antes.

Nunca había explorado en profundidad estas features de Retool, así que aprendí sobre la marcha y puedo decir que fue una excelente experiencia.

Antes de apretar el gatillo

Como el fondo de todo este desarrollo era dar una experiencia al usuario en el proceso de facturación, esto no podía salir mal. Había que, antes de enviar los mails en masa, probar que todo estuviera funcionando bien. Para probarlo:

1. Test interno: Primero probé el flujo para 1 cliente, pero reemplazando el paso de extraer el correo de la organización por uno de alguien de Fintoc, siguiendo el mismo formato de output.
2. Test interno con condición borde: Luego, hice lo mismo, pero asumiendo que la organización tenía más de 1 correo (un arreglo de correos) y verificar que funcionara de la misma manera y ambos correos recibieran el archivo.
3. Test interno con loop: Lo siguiente fue probar la llamada del workflow con el loop al workflow para pocos clientes (3), con direcciones de correo internas.
4. Test externo: Después, mandamos el mail real a través del loop, pero a un solo cliente, para verificar el flujo con los outputs reales de las funciones.
5. Test externo con loop pequeño: Luego soltamos 3 mails (con el loop) para clientes reales (excluyendo el cliente del paso 4).
6. Con todo: Con todas las pruebas anteriores exitosas, soltamos los cientos de mails de una.

Resultado

¿Cómo salió? Bastante bien. Los correos se mandaron exitosamente, cada uno con el archivo y naming correspondiente para su organización en particular, y en pocos segundos. De todos los mails enviados, 4 tuvieron que reintentarse porque la API de SendGrid falló por rate-limit (demasiadas llamadas consecutivas a la API).

Dentro de todo, un éxito, ya que después de los reintentos, todos recibieron los mails, y el equipo de success se vio desbloqueado para seguir avanzando en el mes.

Entonces: ¿para qué prototipar?

• Diseñar antes de programar resulta en código más eficiente: Fui aprendiendo a usar esta faceta de la herramienta sobre la marcha, por lo que no diseñé al 100% la solución antes de ponerme a programar. En vez de ir a buscar a Big Query cada organización por ID, hubiera sido mejor traerlas todas de una en el workflow del loop y mandar un webhook con la información necesaria por cliente. Ahora funcionó bien pero quizás para el triple de mails no hubiera funcionado perfecto.
• Anticiparse a los errores: Es normal que no todo salga perfecto. Por esto, podría haberme anticipado a posibles errores que podrían ocurrir haciendo mejores logs de los procesos de las organizaciones a medida que iban corriendo (imprimiendo el nombre del cliente por ejemplo en caso de error). Como no lo hice 😫, fue un poco latero el proceso de encontrar cuáles eran las 4 que habían fallado.
• A veces velocidad es mejor que elegancia: Este es el mantra del prototipado. Si bien la solución no fue código perfecto, elegante y 100% testeado, permitió destrabar a los devs, sacar algo bueno, funcional y rápido, darme cuenta de casos borde y resolver una situación inesperada de manera ágil, destrabando también los procesos de cierre de mes del equipo de facturación. Además, prototipando rápido pude aprender mucho de cómo diseñar la solución mejor, para luego traspasar el diseño y requerimientos al equipo de desarrollo y poder, ahora sí, priorizar armar un producto elegante y de calidad.