Fábrica

Tecnología sin humo.

Diseño soluciones mantenibles, integro sistemas y reduzco el riesgo de cambiar software que ya está en producción.

01 ALD Análisis de negocio Análisis de negocio Leer más
Análisis de negocio

El analista de negocio (BA) ayuda al desarrollador a entender la historia detrás de un requerimiento. Aunque un pedido pueda llegar inicialmente como una frase simple, un ticket o una regla de negocio, el BA investiga quién lo necesita, por qué importa y cómo encaja en los procesos de la organización.

A veces, eso significa que el BA puede recorrer instalaciones del cliente para ver productos increíbles funcionando en el mundo real. Naturalmente, el desarrollador no necesita viajar para eso; simplemente se queda en su escritorio y modela todo meticulosamente en un esquema de base de datos. Después de todo, ¿para qué vivir el producto de primera mano si podés pasar la tarde debatiendo si una propiedad debería ser string o integer?

Mientras tanto, el desarrollador aporta la mirada técnica, identificando escenarios faltantes, dependencias, limitaciones y posibles alternativas. La relación funciona mejor cuando ambos cuestionan supuestos antes de que empiece el desarrollo, evitando que los malentendidos se conviertan en cambios de software costosos.

02 A Arquitectura Arquitectura Leer más
Arquitectura

El arquitecto ve la ciudad mientras el desarrollador trabaja en uno de sus edificios. Considera cómo aplicaciones, servicios, bases de datos, integraciones, límites de seguridad e infraestructura deben convivir a lo largo del tiempo.

Naturalmente, esto suele significar que el arquitecto aparece en la oficina usando un casco amarillo impecable, recién estrenado, completamente limpio y sin polvo, mirando diagramas desde lejos, mientras el desarrollador está en la trinchera con un casco blanco golpeado que sobrevivió a tres incidentes de producción y a una migración de base de datos un viernes de tarde.

El desarrollador aporta información práctica desde la implementación y puede descubrir que una idea arquitectónica se comporta distinto en condiciones reales. La comunicación entre ambos debe fluir en los dos sentidos: la arquitectura da guía, mientras el desarrollo aporta evidencia. Una arquitectura fuerte debe sostener el trabajo real, no existir solo en diagramas.

03 CDB Cazador de bugs Cazador de bugs Leer más
Cazador de bugs

Mi trabajo empieza siguiendo la historia del software: rastrear una acción de usuario a través de interfaces, reglas de negocio y sistemas externos para entender el recorrido completo. En entornos full-stack y legacy, navego arquitecturas complejas mientras convivo con una sopa de letras de acrónimos de ambientes y convenciones internas de nombres.

Un día normal trae nuevos requerimientos, errores inesperados o procesos rotos. Como uno de los bomberos del universo IT, antes de cambiar cualquier cosa investigo el contexto completo: hablo con personas, reproduzco incidentes y sigo los problemas a través de servidores, permisos y datos. Ya sea que un bug venga de lógica incorrecta o de datos malos, diseño, pruebo y despliego soluciones sabiendo que “en mi máquina funciona” nunca alcanza.

Veo las bases de datos como la memoria organizacional que guarda transacciones vitales y resultados operativos, permitiéndome seguir la información sin saltos desde la interfaz hasta el almacenamiento y asegurar precisión en sectores sensibles como salud y finanzas.

En definitiva, diagnosticar problemas se parece a la arqueología de software, y trabajar con sistemas legacy es simplemente parte del oficio de preservar conocimiento crítico del negocio mediante una evolución controlada. Con el casco de desarrollador puesto, construyo para ayudar al sistema a crecer. A través de ingeniería sostenible y mejoras incrementales bien pensadas, reduzco desperdicio de recursos y extiendo la vida del sistema, manteniendo el software eficiente y en mejora continua, paso a paso.

04 D DevOps DevOps Leer más
DevOps

El desarrollador crea el software, mientras el ingeniero DevOps ayuda a que viaje con seguridad desde un entorno local hacia testing y producción. Colaboran en builds, despliegues, infraestructura, configuración, monitoreo, automatización y procedimientos de recuperación.

Naturalmente, esta sociedad siempre empieza con las palabras mágicas favoritas del desarrollador: “Bueno, en mi máquina funcionaba perfecto, así que debe ser un problema de DevOps.” En respuesta, el ingeniero DevOps actúa como el guardián definitivo, asegurándose de que nadie pueda colar un build rebelde directo a producción sin disparar una docena de alertas automáticas y ser detectado al instante.

Esta relación elimina la pared entre “el código funciona” y “el sistema funciona.” Ambos deben entender que el despliegue es parte del desarrollo, no un evento que ocurre después. El objetivo compartido es hacer que los releases sean predecibles, observables, repetibles y menos dependientes de intervención manual, preferiblemente sin que nadie tenga que despertarlos a las 3:00 AM de un domingo.

05 UX Diseño UX/UI Diseño UX/UI Leer más
Diseño UX/UI

El diseñador UX/UI imagina cómo los usuarios van a vivir el producto, mientras el desarrollador transforma esa visión en una interfaz funcional. Uno se enfoca en claridad, accesibilidad, consistencia e interacción; el otro evalúa cómo implementar esas ideas en dispositivos, navegadores, plataformas y sistemas existentes. Incluso cuando los frameworks modernos hacen que “full-stack” parezca fácil, un diseño realmente excepcional todavía puede llevar cualquier aplicación al siguiente nivel.

Por supuesto, los diseñadores cruzan célebremente al lado oscuro en el momento en que dejan de mostrar dibujos estéticos lindos e inofensivos en Figma y empiezan a commitear cambios de código directamente en el repositorio. Pocas cosas meten más miedo en el corazón de un equipo que un diseñador subiendo un arreglo de CSS que accidentalmente reescribe toda la arquitectura de manejo de estado.

Ninguno debería trabajar aislado. El desarrollador no debe reducir cada diseño a lo más fácil de programar, y el diseñador no debe ignorar las limitaciones técnicas. A través de comunicación continua, crean una experiencia atractiva, práctica, responsive y genuinamente útil.

06 GND Gestión de proyectos Gestión de proyectos Leer más
Gestión de proyectos

La gestión de proyectos coordina el recorrido más amplio: prioridades, recursos, dependencias, riesgos, comunicación y tiempos. El desarrollador aporta una mirada honesta sobre avance técnico, incertidumbre, complejidad y consecuencias de cambiar de dirección.

Por supuesto, esto suele significar que el ritual matutino favorito de quien gestiona el proyecto es tomar un desafío arquitectónico profundamente complejo y de varias capas, y preguntar si de alguna forma puede estar listo para el próximo martes porque una parte interesada se entusiasmó en una reunión. En respuesta, el desarrollador tiene que canalizar su filósofo interior para explicar que estimar software no es un menú donde se pueden negociar las leyes de la física para entregar más rápido.

Las fechas deberían estar informadas por la realidad más que por la presión. La gestión del proyecto debería ayudar a remover obstáculos organizacionales y crear claridad, mientras el desarrollador debe comunicar problemas temprano en lugar de esperar a que el plazo ya haya fallado. La confianza depende de que ambos lados presenten la verdad, incluso cuando incomoda, e idealmente de mantener los diagramas de Gantt y tableros de Jira conectados con la realidad real.

07 IAD Ingeniería de datos Ingeniería de datos Leer más
Ingeniería de datos

El ingeniero de datos / DBA protege las bases de datos que preservan la memoria operativa de la organización y se asegura de que la información se mueva de forma confiable entre sistemas, plataformas y entornos analíticos. El desarrollador trabaja con esa información mediante consultas, transacciones, procedimientos y lógica de aplicación, por eso son esenciales los acuerdos claros sobre formatos, validación, propiedad, frecuencia y comportamiento esperado.

Por supuesto, esto suele significar que el ingeniero de datos (DBA) se parece bastante a alguien que vive permanentemente en un sótano con poca luz, rodeado por un ecosistema caótico de triggers anidados, vistas complejas, paquetes antiguos y stored procedures de 500 líneas que nadie se anima a tocar. Cada vez que un desarrollador pide casualmente “agregar una columnita rápida”, emerge de su guarida subterránea usando lentes de sol para protegerse de la luz normal, listo para explicar por qué esa modificación menor hará implosionar tres pipelines ETL nocturnos y pondrá de rodillas a todo el cluster de base de datos.

Su colaboración protege los datos de volverse inconsistentes, duplicados, demorados o malinterpretados. El desarrollador y el ingeniero de datos (DBA) deberían conversar los cambios antes de que se conviertan en emergencias, optimizando consultas, planificando migraciones y protegiendo accesos. Una funcionalidad no está completa solo porque la información fue enviada; ambas partes deben saber que llegó correctamente, conservó su significado y puede rastrearse cuando algo sale mal sin afectar todo el sistema.

08 INI Integración inicial Integración inicial Leer más
Integración inicial

Sumarse a un proyecto de software con experiencia amplia en finanzas, salud, comercio, comercio internacional, fraude, pagos, sector público y sector privado implica entrar en una historia continua, ya sea que empiece en un repositorio moderno y limpio o en un sistema legacy con comentarios olvidados. Mi rol va mucho más allá de escribir código: implica entender a fondo cómo funciona el negocio, cómo se comunican sus personas y sus sistemas, y cómo unir esas partes con software confiable, seguro y mantenible.

El recorrido empieza parecido a entrar en una ciudad nueva, donde orientarse es esencial antes de poder aportar algo significativo. Esta etapa comienza con recibir y configurar el equipamiento necesario, desde estaciones de trabajo y tokens de seguridad hasta hardware básico de comunicación. Una vez listo el entorno físico, configuro el ambiente, me conecto de forma segura a la red de la compañía o del cliente, aplico las políticas de la organización y verifico accesos a plataformas de desarrollo, testing, documentación y despliegue.

Al mismo tiempo, construyo mi identidad digital dentro de la organización. Configurar perfiles en portales internos, hubs de mensajería, repositorios de código y sistemas de tickets funciona como el primer apretón de manos digital, especialmente en equipos remotos, viajeros o internacionales. Completar esos perfiles sin caer en un conjunto aburrido de símbolos o una foto genérica de paisaje, agregar ubicación y dejar una visión clara de mi experiencia ayuda a mostrar y compartir personalidad dentro de la compañía, mientras prepara el terreno para una comunicación efectiva, colaboración e integración sin fricciones. En el camino, reconozco que el conocimiento técnico a veces viaja más rápido a través de una conexión humana genuina, permitiendo que los equipos construyan confianza y resuelvan problemas juntos.

Juego compartido

Team Building

Atrapando desarrolladores

Atrapando desarrolladores

¡Un juego de detectives donde desenmascarás los pasados más insólitos de los integrantes de tu equipo y hacés trampa para alcanzar la victoria!

Xplorify

Xplorify

¡Relacioná las canciones, exponé a los integrantes de tu equipo y engañá al resto para ganar un juego de adivinanzas musicales!

09 L Liderazgo Liderazgo Leer más
Liderazgo

Un líder excepcional de IT conecta personas, tecnología y resultados de negocio traduciendo objetivos amplios en prioridades técnicas claras que mantienen al equipo enfocado en trabajo de alto valor. En lugar de hacer el trabajo de todos, espero que esa persona habilite el éxito proporcionando los recursos necesarios, dando espacio para tomar decisiones y removiendo obstáculos activamente. Frente a decisiones difíciles sobre arquitectura, seguridad, presupuesto y riesgo, espero que consulte especialistas, evalúe consecuencias y asuma plena responsabilidad por decisiones oportunas sin quedar paralizada por la incertidumbre.

Durante todo el proceso de entrega, quiero que equilibre velocidad y confiabilidad, protegiendo mantenibilidad, testing y seguridad mientras evita atajos dañinos. Como puente clave, debe traducir riesgos técnicos complejos a lenguaje claro para stakeholders no técnicos y aclarar requerimientos de negocio para desarrolladores. Por encima de todo, busco alguien que construya confianza inquebrantable y fomente una red profunda de seguridad psicológica donde los errores puedan exponerse abiertamente sin miedo, como base esencial desde la cual emergen la verdadera excelencia y maestría. En ese espacio seguro, los equipos pueden mostrar problemas temprano, aprender sin temor y hacerse cargo de sus compromisos.

Este líder también debe enfocarse en el crecimiento, mentoreando a otros y delegando responsabilidad para construir un equipo independiente y capaz, en lugar de fomentar dependencia. Cuando se trata de tecnologías emergentes como IA y servicios cloud, espero que impulse innovación práctica, adoptando nuevas herramientas solo cuando resuelven problemas reales de negocio. Además, necesita integrar seguridad y eficiencia directamente en las prácticas diarias y en la arquitectura del sistema para lograr sostenibilidad a largo plazo. En definitiva, al defender plazos realistas, proteger al equipo de distracciones y asumir la responsabilidad final, espero que aporte claridad frente a la incertidumbre, consolide confianza bajo presión y entregue tecnología que haga avanzar a la organización.

Juego compartido

Team Building

Atrapando desarrolladores

Atrapando desarrolladores

¡Un juego de detectives donde desenmascarás los pasados más insólitos de los integrantes de tu equipo y hacés trampa para alcanzar la victoria!

Xplorify

Xplorify

¡Relacioná las canciones, exponé a los integrantes de tu equipo y engañá al resto para ganar un juego de adivinanzas musicales!

10 LTC Liderazgo técnico Liderazgo técnico Leer más
Liderazgo técnico

El líder técnico ayuda al desarrollador a tomar decisiones que se mantengan alineadas con la dirección del equipo. En lugar de dictar cada línea de código, orienta, revisa decisiones importantes, comparte experiencia y ayuda a identificar riesgos antes de que se propaguen por el sistema.

Por supuesto, la prueba definitiva de un gran líder técnico es si puede explicar una arquitectura compleja usando solo un marcador de pizarra y una cantidad alarmante de café, mientras hace que todo parezca engañosamente simple.

Un buen líder técnico crea independencia en lugar de dependencia. Los desarrolladores deberían sentirse cómodos hablando de dudas, proponiendo alternativas y discrepando con respeto. El propósito no es demostrar quién sabe más, sino elevar la calidad técnica de todo el equipo.

11 PI Partes interesadas Partes interesadas Leer más
Partes interesadas

Los stakeholders representan a las personas que invierten en el producto, dependen de él, lo influencian o se ven afectadas por él. Aportan dirección de negocio, prioridades, expectativas y la definición de valor.

Naturalmente, esta relación suele empezar cuando un stakeholder deja caer casualmente un pedido completamente menor, como “¿podemos agregar un dashboard con IA y blockchain para fin de semana?”, sin saber que el sistema legacy de base se mantiene unido con cinta adhesiva y puro optimismo. En respuesta, el desarrollador tiene que traducir cuellos de botella técnicos complejos a términos humanos sin sonar como si hablara un idioma alienígena.

El desarrollador ayuda a los stakeholders a entender qué puede implicar cada decisión. Un pedido que suena pequeño puede afectar seguridad, datos, integraciones, mantenimiento o desarrollo futuro. El desarrollador debe explicar esas consecuencias con honestidad, asegurándose de que los líderes de negocio entiendan que el desarrollo de software no es una máquina expendedora mágica donde se aprieta un botón y aparece código al instante.

La relación funciona cuando el esfuerzo técnico se conecta con resultados significativos. El objetivo no es construir cada funcionalidad pedida solo porque sonó genial en una reunión de pitch, sino crear el producto correcto, resolver los problemas correctos y usar el tiempo y los recursos de la organización de forma responsable.

12 P Producto Producto Leer más
Producto

La relación entre un desarrollador y un cliente o responsable de producto muchas veces se parece a la dinámica de alguien frotando una lámpara y un genio listo para conceder deseos. Los clientes llegan con pedidos que parecen simples, como un botón nuevo, un campo menor o una notificación rápida, creyendo que solo llevará unas pocas líneas de código. Pero el desarrollador mira más allá de la superficie y ve la red de impactos en base de datos, controles de seguridad, integraciones y mantenimiento futuro escondida detrás del pedido.

En lugar de actuar ciegamente como quien concede deseos, un desarrollador responsable investiga el verdadero problema detrás de la idea. Trabajando junto al responsable de producto, que prioriza las necesidades del negocio, el desarrollador descubre las consecuencias técnicas que se esconden en la sombra de los pedidos pequeños. Ambos entienden que los deseos “pequeños” sin control terminan acumulándose y convierten un sistema limpio en un enredo demasiado complejo.

En vez de transformarse en un guardián poco útil que dice que no a todo o en alguien que dice que sí y siembra desastres futuros, el desarrollador ofrece transparencia honesta. Al explicar opciones, trade-offs y costos de largo plazo, se asegura de que el cliente entienda las implicancias de sus decisiones. En definitiva, el cliente trae la visión, el responsable de producto trae la prioridad de mercado y el desarrollador trae la realidad sistémica, convirtiendo la magia en una decisión compartida y responsable.

13 QA QA QA Leer más
QA

Desarrollo y QA no son fuerzas opuestas en un campo de batalla; son dos músicos afinando la misma guitarra.

El desarrollador construye el instrumento, conecta sus partes, ajusta las cuerdas y se asegura de que el código compile y entregue el flujo principal. Pero QA escucha con otro oído. Pulsa cada cuerda, prueba ritmos poco habituales y encuentra las fallas sutiles que se le escapan a quien construyó el instrumento, descubriendo si la música resiste en un escenario ruidoso o se desarma bajo presión.

Cuando QA reporta una falla, no es una crítica, sino una invitación a escuchar más de cerca. Pero para que la música suene fluida, la comunicación debe ser precisa. Una queja vaga como “no suena bien” no ayuda a nadie; QA debe compartir las notas exactas, las condiciones y las expectativas, mientras el desarrollador escucha sin ponerse a la defensiva.

A veces descubren que estaban tocando versiones completamente distintas de la canción por requerimientos poco claros. En lugar de intentar demostrar quién tiene razón o quién se equivoca, desarrollador y tester colaboran: intercambian notas, ajustan acordes y refinan el sistema juntos hasta que el software suena armónicamente para el usuario.

14 SM Scrum Master Scrum Master Leer más
Scrum Master

En lugar de actuar como perseguidor de fechas límite, un buen Scrum Master funciona como una fuerza silenciosa detrás del avance, como alguien que mantiene despejado el camino para un desarrollador enfocado en construir el producto. En vez de preguntar una y otra vez por fechas de llegada o presionar por estimaciones prematuras, lo que solo genera presión e interrupciones, el Scrum Master se enfoca en eliminar fricción. Quita obstáculos burocráticos, consigue aprobaciones, ordena prioridades dispersas y absorbe la confusión externa para que el equipo de desarrollo pueda concentrarse por completo en resolver problemas y escribir código.

Más allá de gestionar la logística, un Scrum Master efectivo escucha las señales sutiles y no dichas del proyecto: detecta dudas, cuellos de botella ocultos y deuda técnica creciente que las métricas crudas y los tableros de tareas no muestran. En definitiva, su éxito no se mide por cuántas veces pide actualizaciones de estado, sino por cuántos obstáculos desaparecen, cuán claras se vuelven las prioridades y con qué consistencia el proyecto avanza por su propio impulso.

15 S Seguridad Seguridad Leer más
Seguridad

El especialista en seguridad ayuda al desarrollador a ver las puertas, ventanas y entradas ocultas que pueden existir en un sistema. Autenticación, permisos, encriptación, APIs, credenciales, datos sensibles y dependencias externas deben considerarse durante todo el desarrollo, no revisarse recién antes de liberar.

Naturalmente, esta relación siempre empieza con el especialista en seguridad teniendo un mini infarto al descubrir que alguien hardcodeó una contraseña en texto plano dentro de un archivo público de configuración, la llamó admin123 y le dio a cada servicio acceso completo de root/escritura en todos lados. En respuesta, el equipo de seguridad aparece para recordarle a todos que “permisos de solo lectura” realmente significa solo lectura, y que imprimir tokens de API sin procesar y tarjetas de crédito de clientes directamente en logs de error estándar en texto claro suele estar bastante mal visto.

La seguridad no debería ser una batalla entre alguien que quiere entregar y alguien que siempre dice que no. El especialista explica riesgos y posibles protecciones, mientras el desarrollador ayuda a encontrar soluciones que sigan siendo usables y mantenibles. Juntos hacen que la seguridad sea parte del producto, no un obstáculo agregado al final.

16 S Soporte Soporte Leer más
Soporte

El equipo de soporte escucha al usuario antes que el desarrollador. Recibe las preguntas, frustraciones, escenarios inusuales y problemas del mundo real que no siempre aparecen durante el diseño o el testing.

Naturalmente, esto crea una regla sagrada y no dicha entre desarrolladores: el estándar de oro absoluto del código limpio es una notificación de Slack de soporte diciendo que no vieron un solo ticket con tu nombre en toda la semana. Después de todo, nada valida tu arquitectura como que nadie necesite escribirte para preguntar por qué una funcionalidad se está comiendo datos de usuarios en producción.

Soporte aporta contexto valioso, mientras el desarrollador investiga la causa técnica de fondo y explica la solución con claridad. La relación no debería limitarse a pasar tickets entre colas. Cuando ambos equipos comparten conocimiento, los incidentes recurrentes pueden convertirse en mejoras permanentes del producto, lo que significa menos sesiones de emergencia para apagar incendios para todos los involucrados.

  1. Globant Globant University 47 trainings

    Globant

    Trainings

  2. Atos Atos University 30 trainings

    Atos

    Trainings

Hi

¿Tenés un problema interesante?

Saquemos esa visión directamente de tu mente y construyámosla como una experiencia digital.

Hablemos de trabajo