Hay etapas profesionales que no se miden solamente por el tiempo que duran, sino por la cantidad de problemas reales que te obligan a entender, la cantidad de personas con las que construyes y la forma en que sales de ellas: con más criterio, más perspectiva y más respeto por el trabajo bien hecho.
Hoy estoy cerrando mi ciclo en Yummy, una compañía que fue para mí mucho más que un lugar de trabajo. Fue un espacio de crecimiento técnico, humano y profesional. Un lugar donde tuve la oportunidad de construir soluciones con impacto real, participar en decisiones complejas, liderar iniciativas estratégicas y aprender, muchas veces, en escenarios donde no había respuestas simples.
Me voy con gratitud, con orgullo por lo construido y con una visión mucho más clara de lo que significa hacer tecnología dentro de una operación viva, exigente y en constante movimiento.
Construir tecnología donde ocurre el negocio
Durante mi paso por Yummy trabajé principalmente en retos asociados al equipo tecnológico de finanzas, un equipo donde la tecnología no vive aislada: cada decisión técnica tiene relación directa con procesos financieros, conciliaciones, facturación, dispersión, reportería, integraciones internas, operación diaria y cumplimiento.
Eso cambia la forma en que uno entiende el software. La velocidad y la forma en la que comienzas a ver el mundo, sobre todo en un país como Venezuela.
Sé parte de los que apoyan con su suscripción más contenido especializado como este.
No se trata solo de crear servicios, endpoints o dashboards. Se trata de construir sistemas que soporten decisiones, que reduzcan fricción operativa, que den trazabilidad, que permitan auditar, que conecten equipos y que ayuden a que el negocio funcione con mayor claridad.
Tuve la oportunidad de participar en iniciativas alrededor de:
Modernización de procesos financieros: procesos que actualmente no tienen nada que envidiarle a cualquier corporación internacional existente a día de hoy.
Integraciones con sistemas internos y externos: con lo último en tecnología, pero sin dejar de ser estable, escalable y altamente operativo.
Automatización de flujos operativos: generando asistentes y operaciones automatizadas completamente, que antes requerían muchas horas hombre.
Implementación y evolución de ERP: gestionando toda la cadena operativa y administrativa, con tecnología de vanguardia. Cuando se habla de Yummy, no son 100 o 200 operaciones aisladas al mes, son millones.
Reporting financiero y herramientas de análisis: integrales, que operan a un nivel de seguridad muy alto, con capacidad y disponibilidad 24/7.
Conciliación y dispersión de fondos: lo que puede parecer fácil, y que realmente es una de las cosas más complejas de hacer, por el volumen de la operación.
Observabilidad y trazabilidad de procesos críticos: nos pusimos la meta de poder detectar fallos de forma proactiva, documentarlo todo y generar luego de eso, incluso, sistemas de predicción. Y sí, se cumplió.
Revisión de arquitectura, seguridad y calidad: modernizando todos y cada uno de los servicios, ejecutando procesos modernos con arquitectura moderna y elastica.
Gobernanza de datos y criterios de autoridad sobre la información: Trabajando de la mano con otros equipos especializados en el tema, nos convertimos en referencia de cómo se pueden hacer las cosas cumpliendo estos criterios.
Uso práctico de inteligencia artificial: haciéndola realmente útil, no simplemente diciéndole a la IA “construyeme un front bonito y seguro para ver el proceso de conciliación“, sino integrándola al desarrollo de un equipo altamente profesional y dedicado a su trabajo, no solo como asistente, sino como parte de las soluciones.
Cada una de estas áreas dejó una enseñanza distinta. Algunas fueron profundamente técnicas; otras, más organizacionales. Muchas fueron ambas al mismo tiempo.
De resolver tickets a diseñar sistemas
Uno de los aprendizajes más importantes que me llevo es que un equipo técnico madura cuando deja de pensar únicamente en entregables aislados y empieza a pensar en sistemas como soluciones.
Un ticket puede cerrar una necesidad puntual. Un sistema bien diseñado cambia la forma en que el equipo opera.
En Yummy pude trabajar en esa transición: liderando a mi equipo para pasar de resolver problemas caso por caso a crear mecanismos más repetibles, trazables y sostenibles; a soluciones sistematizadas y altamente operativas sin perder seguridad o confiabilidad.
Eso implicó fortalecer metodologías de planificación, análisis de impacto, documentación técnica, criterios de aceptación, revisión de arquitectura y validación antes de ejecutar.
Sé parte de los que apoyan con su suscripción más contenido especializado como este.
Un error al sumar 1+1 en cualquier equipo puede ser un simple bug, o como mucho implicar una pérdida de estabilidad en el sistema, incluso una caída total; que, aun siendo muy grave, ese mismo error en finanzas puede hacer que no se puedan ejecutar operaciones financieras en toda una compañía; incluso puede ser motivo de sanción administrativa por el regulador.
Un ejemplo claro fue la evolución hacia una forma más estructurada de planificar iniciativas técnicas: antes de escribir código, entender el dominio, mapear dependencias, identificar riesgos, revisar impacto entre repositorios, definir escenarios de prueba y separar lo urgente de lo importante.
Ese tipo de disciplina no hace más lento al equipo. Bien aplicada, lo hace más confiable. Y claro que no es solo eso, sino dale la confianza necesaria, y aprender a delegar, entender que no todo lo importante es urgente, y que no todo lo urgente es importante; lo urgente e importante se ejecuta al momento; lo urgente se planifica y lo importante se comunica.
Porque cuando un cambio toca pagos, finanzas, facturación o conciliación, el costo de “probar en producción” sin suficiente claridad no es solo técnico. Puede convertirse en ruido operativo, reprocesos, inconsistencias de datos o pérdida de confianza entre áreas o, como les reitero, sanciones muy fuertes por parte del regulador.
Metodologías que realmente aportan
Una parte importante de mi paso por Yummy estuvo relacionada con impulsar mejores formas de trabajo. No metodologías como ritual vacío, sino como herramientas prácticas para reducir incertidumbre.
Sé parte de los que apoyan con su suscripción más contenido especializado como este.
Entre las prácticas que más valor aportaron estuvieron:
Planificación técnica estructurada, para convertir necesidades ambiguas en rutas de ejecución claras.
Spec-Driven Development, usando especificaciones antes de implementar.
Criterios de aceptación en Gherkin, para que negocio, QA y tecnología hablaran con mayor precisión.
Definition of Ready y Definition of Done, evitando iniciar trabajo incompleto o cerrar trabajo que aún no estaba realmente operativo.
Revisión de arquitectura, especialmente cuando una decisión podía afectar varios servicios.
Análisis de impacto multi-repositorio, necesario en ecosistemas donde un cambio pequeño puede tener consecuencias en varios flujos.
KPIs de ingeniería, no como herramienta de presión, sino como forma de entender tendencias, capacidad, foco y trade-offs.
Retrospectivas basadas en hechos, para aprender de lo ocurrido sin convertir los problemas en culpa.
Observabilidad como parte del diseño, no como algo que se agrega al final.
Automatización de reportes y seguimiento, para liberar tiempo de coordinación y mejorar visibilidad.
Una metodología solo sirve si ayuda a tomar mejores decisiones. Si solo agrega reuniones o documentos sin impacto, no sirve. Esa diferencia fue algo que aprendí hace años y reforcé con mucha claridad.
Inteligencia artificial como capacidad adicional del equipo de desarrollo e ingeniería
Otro eje importante fue el uso de herramientas de IA en el trabajo técnico. No como reemplazo del criterio humano, sino como acelerador para tareas donde el contexto, la revisión y la estructura importan: análisis de repositorios, generación de planes, revisión de riesgos, documentación, validación de criterios, preparación de reportes, análisis de impacto y soporte a procesos de Tech Lead.
Uno de los trabajos que más orgullo me deja fue contribuir al desarrollo y uso de herramientas internas para AI. Brindandole seguridad, confiabilidad, contexto y sobre todo limites claros de su uso e implementación.
Sé parte de los que apoyan con su suscripción más contenido especializado como este.
Logrando una forma de organizar contexto, memoria, reglas, agentes, revisiones y documentación para que distintas herramientas de IA pudieran apoyar el trabajo técnico sin depender de improvisación. Esto me confirmó algo importante: la IA en ingeniería no se trata de pedirle “hazme esto” a una herramienta.
Se trata de diseñar un sistema de trabajo donde la IA tenga contexto, límites, criterios de calidad y validación humana. Y en estos dos años con el impulso de la AI reforcé algo que observava desde los salones de mi antigua alma mater: la diferencia entre usar IA como juguete y usarla como capacidad real está en la disciplina con la que se integra al proceso.
Porque la AI puede parecer muy moderna, pero su desarrollo comenzo casi desde los inicios de la computación moderna, si mal no recuerdo los años 60’s. Solo que hace 15 años, eran “algoritmos avanzados“ los que se encargaban de ejecutar esas tareas.
Aprender a pensar en trazabilidad
En compañías con operación financiera, la velocidad importa, pero la trazabilidad importa igual o más. Liderando un equipo técnico en Yummy, desarrollando soluciones de alto nivel para el mercado venezolano, es donde más se nota.
Hay procesos donde no basta con que algo “funcione”. También hay que poder explicar qué ocurrió, cuándo ocurrió, por qué ocurrió, qué sistema lo produjo y cómo se puede verificar.
Sé parte de los que apoyan con su suscripción más contenido especializado como este.
Esa forma de pensar estuvo presente en muchos retos: conciliaciones, reportes, integraciones, dispersión de fondos, dashboards, logs, validaciones y procesos de auditoría.
Un ejemplo práctico: cuando un flujo financiero atraviesa varios sistemas, no alcanza con saber que el resultado final llegó. Es necesario poder seguir la historia completa: desde el evento inicial, pasando por las transformaciones, validaciones, decisiones, estados intermedios y resultado final.
Esa trazabilidad reduce fricción entre equipos. Permite que soporte, finanzas, producto, data e ingeniería hablen sobre hechos y no sobre suposiciones.
Gobernanza de datos: una de las discusiones más valiosas
Uno de los aprendizajes más profundos estuvo alrededor de la gobernanza de datos: acalorado, pero gratificante cuando vez una implementación correcta, certificada y funcional en plena operación.
Sé parte de los que apoyan con su suscripción más contenido especializado como este.
En tecnología es común escuchar frases como “una sola fuente de verdad”. Suena correcto, pero en dominios financieros la realidad suele ser más compleja.
A veces el problema no es tener un solo número. El problema es entender qué representa cada número, quién lo produce, bajo qué regla, en qué momento, con qué responsabilidad y para qué decisión se usa.
No todo dato tiene el mismo peso. No es lo mismo un dato analítico que un dato contable. No es lo mismo una métrica de observación que un registro que puede tener consecuencias fiscales, operativas o regulatorias.
Ese tipo de discusiones me ayudó a reforzar una idea que me parece fundamental:
Lo reversible se puede centralizar con mayor facilidad.
Lo irreversible debe quedarse cerca de quien lo firma, lo controla y responde por sus consecuencias.
Esa frase resume mucho de lo que aprendí sobre arquitectura, responsabilidad y operación.
También hubo momentos difíciles
No quiero romantizar el proceso. No todo fue simple, ni perfecto, ni siempre cómodo. Todos los procesos son complejos, aún más si sin procesos humanos.
Sé parte de los que apoyan con su suscripción más contenido especializado como este.
Hubo momentos de presión alta, prioridades cambiantes, deuda técnica, ambigüedad, diferencias de criterio, urgencias operativas y decisiones tecnicas difíciles. También hubo conversaciones donde era necesario defender una postura técnica, ó reconocer errores, ajustar el enfoque o aceptar que una solución inicial no era suficiente, incluso enfrentar tus argumentos con los de la mismisima directiva.
Pero esos momentos también fueron parte esencial del aprendizaje. Yummy no es una empresa más, aquí te consigues al director de finanzas un viernes en la oficina y te invita un cafe, o vas a una reunión despues del trabajo y puedes conversar tranquilamente con el CEO. Pero, a mayor confianza, el mayor respeto posible; accesibilidad no siempre representa saltarte pasos necesarios para cumplir tus metas, sino saber aprovechar esa accesibilidad para comunicar lo que sea necesario, en el momento necesario y de la forma correcta.
Liderar técnicamente no es tener siempre la razón. Es crear claridad cuando hay ruido. Es saber cuándo empujar, cuándo escuchar, cuándo documentar, cuándo escalar y cuándo cambiar de opinión. Por eso es importante tener en cuenta que:
Una buena discusión técnica no debería tratarse de ganar un argumento, sino de encontrar una solución que reduzca riesgo y haga sentido para el negocio.
La comunicación efectiva, es tan importante como la arquitectura. Una solución técnicamente correcta puede fallar si no está bien explicada, si no considera a las personas que la operan o si no reconoce las restricciones reales del entorno.
La respuesta ante momentos inesperados
También me tocó ver y participar en momentos donde la tecnología tuvo un rol distinto al habitual, bueno, donde la empresa tuvo un movimiento que nunca habia visto en otra empresa, con mis 13 años en el sector TI.
Ver como durante un terremoto, toda la directiva de la empresa, llamo personalmente a cada uno de los empleados, de todos los niveles, personalmente para ver si estaban bien. Y no una, sino dos veces. ¡ES IMPRESIONANTE!
Durante situaciones de contingencia nacional, quedó claro que (según mi criterio) la empresa de tecnología más innovadora de Venezuela, y una de las tecnologicas más importantes del país, colocaba su equipo, infrestructura y tecnología completa; a disposición de los ciudadanos.
Sé parte de los que apoyan con su suscripción más contenido especializado como este.
Cuando todos preguntamos si podiamos desconectarnos ese día para ir a ayudar, nos dijeron que podiamos ayudar desde Yummy. Y para alguien a +1.000 km del desastre, es algo que realmente fue útil. Noches sin dormir, dias de preocupación y aun con traumas desarrollamos soluciones altamente operativas en horas.
Contruyendo respuesta, coordinación, visibilidad y soporte cuando el contexto lo exige. Ese tipo de experiencias recuerdan que detrás de cada sistema hay personas. Y que la tecnología, cuando está bien orientada, puede ser una herramienta concreta para ayudar, ordenar información y responder mejor.
Me llevo ese aprendizaje con especial respeto.
Lo que me llevo de Yummy
Me llevo muchas cosas, no voy a negar que buenas y no tan buenas, pero esas ultimas son tan pocas que realmente sé que no afectarán en lo más minimo, porque así es Yummy, siempre evoluciona y se adapta para cumplir con lo que realmente importa.
Me llevo una comprensión más profunda de sistemas financieros y operativos.
Me llevo experiencia liderando iniciativas con impacto real.
Me llevo mejores criterios para arquitectura, automatización y datos.
Me llevo aprendizajes sobre IA aplicada a ingeniería.
Me llevo conversaciones difíciles que me hicieron crecer.
Me llevo equipos, personas y momentos que marcaron mi forma de trabajar.
Pero, sobre todo, me llevo una idea muy clara: la tecnología valiosa no es la que se ve más sofisticada desde afuera, sino la que resuelve problemas reales, y esto es sumamente importante en un país tan roto como mi querida Venezuela. La tenología esta para reducir incertidumbre y permite que otros trabajenmejor.
Gracias
Gracias a todas las personas con las que compartí este camino en Yummy: la directiva, ingeniería, producto, finanzas, operaciones, data, liderazgo, soporte y todos los equipos con los que tuve la oportunidad de colaborar, y hasta los que no.
Gracias por los retos, por la confianza, por las conversaciones, por los aprendizajes y también por los momentos complejos. Todo eso forma parte de lo que uno se lleva.
Cierro esta etapa con gratitud y con orgullo por lo construido.
Y abro la siguiente con más experiencia, más criterio y más ganas de seguir construyendo tecnología con impacto real.