Hackathon: Ideas para desarrollar

Lucía Serigos
Trocafone
Published in
9 min readJan 3, 2019

Cuando se trata de compartir, de innovar y de proponer en Trocafone todos se involucran, y no hay momento de mayor creatividad, ingenio y espíritu de equipo que una Hackathon. Cuatro veces al año dedicamos un día entero para que las mejores ideas puedan cobrar vida.

Durante la Hackathon se experimentan nuevas tecnologías, se crean y mejoran herramientas que servirán para nuestro trabajo diario y se busca perfeccionar el funcionamiento de nuestro producto. Cada detalle durante este día puede hacer la diferencia, porque de eso se trata, de aplicar toda la creatividad para generar ideas útiles a futuro, y, sin dudas, pasar un gran momento junto al equipo.

Tiempo de crear

Cada tres meses realizamos nuestra tan esperada Hackathon, un espacio que disfrutamos y aprovechamos para poner nuestras mejores ideas sobre la mesa y empezar a crear.

Para que todo esto pase, unas semanas antes, los miembros del equipo proponen ideas. En formato de pitch se comenta el objetivo y los recursos que van a ser necesarios. Lo interesante es que de esta manera se da lugar a la interacción de los distintos integrantes de los equipos, cada uno aportando y compartiendo sus conocimientos.

Son muchos los proyectos que, con mucho esfuerzo y dedicación, nacieron en una Hackathon. Seleccionamos algunas de nuestras experiencias para que sus protagonistas pudieran relatar sus historias y compartirlas con todos. En las siguientes líneas, van a poder disfrutar las palabras de los integrantes de cada trabajo.

Troca Clickers

Primera Versión

Durante la primera Hackathon de Trocafone, allá por mayo de 2017, nació la versión 1.0 de este proyecto. La idea surgió por el interés de algunos por el desarrollo de videojuegos (o mejor dicho, su adicción a los mismos).

Originalmente se pensó hacer un idle game con el modelo de negocio de Trocafone, con gran cantidad de mejoras e intrincadas reglas. No solo buscaba reflejar el proceso core de la empresa (compra, reacondicionamiento y venta de celulares), sino también la influencia de cada sector que compone la compañía.

Para esta primera versión, el equipo estuvo conformado por una desarrolladora frontend, un desarrollador backend y un analista de marketing.

El desarrollo se encaminó por la parte de venta, dejando de lado la generación de stock o la reparación de celulares, y pensando en incrustarse como un módulo en una versión más abarcativa. Buscamos en los perfiles de Facebook de los chicos de marketing las fotos más vergonzosas. A partir de ahí se crearon mejoras referidas a sus preferencias o alguna situación graciosa. Además se agregó un slider de frases graciosas relacionadas al juego o -anécdotas de la oficina, como por ejemplo:

-“Siempre que juego al Troca Clicker ligo el ancho de espadas” - Gonzálo Higuaín
-“¡Mamá cortaste toda la LOOOZ! Estaba jugando al Troca Clickers”

A medida que avanzaba el día nos dimos cuenta que iba a ser imposible crear los tres flujos (compra, reparación y venta). Entonces nos focalizamos en balancear el juego y mejorar el material. Agregamos un comportamiento donde cada determinado tiempo te pedían pagar sueldos y si no estabas atento renunciaba alguien.

Al finalizar el día tuvimos la primera versión, con el foco puesto en el funcionamiento de la venta y con un montón de referencias graciosas del día a día. Esa Hackathon se dieron premios al desarrollo más votado y el ganador fue Troca Clickers. Creemos que la principal razón fue la empatía que generó el trabajo, además de su desarrollo (buscando fotos, frases anecdóticas y demás), funcionalidad y usabilidad del juego.

Segunda versión

La segunda versión contó con cuatro desarrolladores: dos se dedicaron al frontend y otros dos a evolucionar las reglas y el comportamiento.

El objetivo ahora era hacer un contenido más sobrio, sin dejar de lado el humor, pero no tan específico de nuestra gente. La idea era hacer un producto que se pudiera mostrar en el stand que armamos de Trocafone para conferencias, donde los asistentes se pudiera acercar y jugar. Buscábamos que tuviera las tres partes fundamentales de nuestro negocio: compra, reacondicionamiento y venta.

La primera hora y media del día se dedicó a definir Gameplay y UI. Pudimos usar la imaginación y tirar ideas para un juego. Luego nos pusimos a desarrollar los dos equipos.

En el backend llevamos un estado del juego que iba atravesando en cada gameloop una parte del flujo. Quisimos agregar un cuarto paso financiero, donde se paguen los sueldos cada cierta cantidad de iteraciones.

Desde el lado del backend (lógica del juego) queremos mencionar una estrategia que utilizamos.

Primero enfatizamos el contexto:

Teníamos muchas ideas para aplicar a la mecánica del juego. Algunas indispensables y otras nice to have.

Contábamos con un tiempo muy limitado: 4 o 5 horas.

Éramos dos personas trabajando en un desarrollo pequeño.

Entonces necesitábamos poder:

Paralelizar al máximo las tareas.

Agregar de forma fácil features.

Dar por finalizado el desarrollo en cualquier momento, sin importar cuáles de las tareas quedaban sin realizarse.

Lo logramos diseñando la solución como un pipe-and-filters. En cada iteración o “turno” del juego, se pasaba de forma secuencial por cada filter o flow del juego (reparación, compra, venta, contratación, upgrade y pago de sueldos). Además manejamos un contexto compartido por todos los filters del que leían y escribían los atributos que necesitaban. De esta manera logramos agregar flows al juego de forma incremental y casi transparente.

A las 3pm era nuestro deadline para modificaciones. A partir de ahí nos dedicamos a integrar con el frontend y corregir algún bug.

Finalmente lo jugamos para poder balancearlo y obtener un juego divertido y funcional. Para eso tocamos los precios de venta, los costos de compra y reparación. Según lo que configuramos a veces era imposible ganar, otras lo era perder. Pudimos llegar a una versión perfectible, pero bastante buena.

Trocabot

Por más compleja o simple que pueda ser una aplicación, existen ciertos conceptos que no pueden escapar de su órbita: integración continua y deployment, dos claros ejemplos de ello. Es verdad que un simple “¡Hola mundo!” no requiere que estemos pensando en esto, pero, ¿qué pasaría ahora si quisiéramos complejizar nuestra aplicación, distribuir entre varios desarrolladores y automatizar nuestros deployments? Este planteo nos lleva a pensar en soluciones orientadas a lo que en la jerga se pueden abreviar como “CI/CD”.

Suponiendo que ya se tenga una solución operativa, ¿qué puntos de mejora se pueden atacar?

Este fue el desafío que nos enfrentamos en la última Hackathon.

Con la necesidad de implementar mejoras para el actual “Trocabot” (bot de slack para automatización de tareas, implementado originalmente en otra Hackaton), nos dispusimos a diseñar una PoC, para el pipeline completo del proyecto.

La PoC contó con 3 pilares, que esperábamos al final del día pudieran conectarse.

1. Trocabot: se trabajó para la implementación de las mejoras en el manejo de deployments y ambientes.

2. CI/CD: se trabajó con la implementación de una nueva versión de Jenkins + Pipelines + Blueocean, para poder definir pipelines de deployments.

3. Infraestructura: se trabajó con todo lo que sucedía en los puntos anteriores e iba a ejecutarse, ni más ni menos que un cluster de K8s.

Llegado al final de la hackaton, si bien no se pudo contar con un pipeline completamente automatizado, logramos objetivos claros que nos allanaron bastante el camino para el futuro.

Utilización de Grafos

En su ciclo de vida, un celular en Trocafone atraviesa un flujo bastante complejo, desde su compra y logística inversa; su revisión y reparación; hasta su venta por alguno de los canales, logística directa y la posibilidad de que se termine devolviendo. Ese flujo es una simplificación. Cada uno de los puntos que mencioné tiene varios pasos internos, y su avance no es lineal. De la mayoría de los estados, un celular puede ir a más de un lugar, por ejemplo: después de su reparación un celular puede ir a stock, descartarse o volver a ser reparado.

Entender ese flujo en papel no es fácil. Nuestra idea era armar una herramienta gráfica que permita visualizar los diferentes estados de Trocafone, y los posibles caminos entre ellos. La representación que nos pareció ideal es un grafo dirigido, donde los nodos son los diferentes estados posibles, y las aristas son los posibles movimientos.

Encontramos una biblioteca de Javascript para visualización de grafos, y con su ayuda armamos una aplicación web, que dada una definición de flujo lo grafica, permite agrupar estados (y luego ocultar las agrupaciones) y resalta los posibles caminos entre ellos. Extendimos un poco el alcance inicial del proyecto y le agregamos la posibilidad de visualizar la cantidad de teléfonos en cada estado (con el tamaño de los nodos), y de resaltar el flujo de un celular particular.

Trocamozaic

La motivación nació ya que sabíamos que habían muchos teléfonos que, por tener alguna falla (ej: GPS), no eran aptos para la venta y quedaban en un stock de descarte. Entonces, se nos ocurrió que un mosaico de teléfonos, como el de televisores en los noticieros, podría quedar simpático y llamar la atención para la recepción de Trocafone.

En una primera Hackathon se hizo una prueba de concepto con cuatro teléfonos y una aplicación en Android. Lamentablemente, al final del día descubrimos que con el approach planteado presentaba problemas para escalar a más dispositivos.

A raíz de eso, decidimos tomar un approach diferente en una siguiente Hackathon e implementamos una solución superadora sobre 30 dispositivos. Ésta se basa en un servidor de control, desarrollado en Node.js, al que todos los dispositivos se conectan mediante una app Android. Para evitar configurar en cada dispositivo la dirección IP del servidor, se implementó una solución basada en multicast. Al mismo tiempo, se le fueron agregando distintas funcionalidades: slideshow de imágenes y la generación automática de un template con las posiciones de cada celular a partir de una foto sacada a la configuración física de los dispositivos en el mosaico. Además del reto de construir el software, tuvimos que lidiar con problemáticas del hardware como mantener los dispositivos conectados a la red eléctrica sin que se vean los cables. El primer uso que se le dio al mosaico fue para el stand de Trocafone en la NodeConf 2018.

A futuro queremos implementar la capacidad de mostrar un video y realizar una integración con el TrocaSnake de tal forma que en cada dispositivo pueda mostrar una partida en vivo.

Trocasnake

El Snake del Nokia 1100 fue un gran juego que marcó toda una generación, a la cual pertenecemos. Como nuestro negocio se basa en la venta de celulares reacondicionados, entre otros tipos productos, tuvimos ganas de hacer nuestra versión.

La idea nació con el objetivo de dar una solución que pudiera resolver la necesidad del equipo de tecnología y recruiting de cara a la NodeConf 2018: conseguir nuevos perfiles y seguir sumando talento al equipo.

Aprovechamos el contexto de la Hackathon para resolver un problema claro, y la mejor manera que encontramos para hacerlo fue de una forma lúdica. El proyecto nos parecía sumamente atractivo, nos rememora a nuestra infancia y lo más interesante era que podríamos relacionarlo directamente con el negocio.

¿Cómo logramos conseguir los leads? Desde el login de LinkedIn tuvimos acceso a datos valiosos de los posibles candidatos. Además armamos un ranking para resaltar los mejores resultados e identificar al mejor de cada jornada, para luego hacer un sorteo entre los primeros y darle un premio.

En cuanto a las tecnologías utilizamos un stack isomórfico utilizando librerías com React, Redux, PixiJS, Node, Express. Usando Typescript como sintaxis y PostgreSQL para persistir los datos.

</ para ir cerrando >

Terminamos 2018 con enormes proyectos, algunos mencionados en este artículo; grandes ideas; importantes objetivos; y muchas ganas de seguir creciendo y aprendiendo.

Esperamos seguir por este camino y construir mucho más a partir de nuestras queridas Hackathones.

--

--