Proyectos

Estos casos demuestran evaluación, rediseño y mejora de capacidad de entrega en dominios tecnológicos diversos (Salesforce, CMS, Design Systems, arquitecturas de autorización), frecuentemente sin autoridad formal sobre los equipos. Delebe ofrece este tipo de trabajo —centrado en entrega, arquitectura, flujo y organización— a otras empresas en forma de colaboraciones independientes.

Lideró durante tres años la transformación completa de la capacidad de entrega de una scale-up fintech europea. El punto de partida: aproximadamente nueve releases trimestrales, treinta días de lead time, ochenta por ciento de tasa de fallo en cambios, proceso de despliegue manual.

La transformación se ejecutó en fases sistemáticas: automatización del pipeline de release, experimento de releases diarias con cinco iteraciones durante dieciocho meses aprendiendo qué impedía a los equipos liberar código, implementación de cambios organizacionales. Resultados: ciento cincuenta y seis releases trimestrales (aumento de diecisiete veces), tres días de lead time (reducción del noventa por ciento), cinco por ciento de tasa de fallo (reducción del ochenta y siete por ciento). Durante el último año de la transformación, cuando la empresa añadió quince ingenieros (cincuenta por ciento de crecimiento), el lead time continuó mejorando de cuatro a tres días en lugar de degradarse, demostrando que la capacidad de entrega se mantuvo incluso durante el crecimiento rápido del equipo.

Un equipo de una empresa de trading online llevaba tiempo bloqueado en su integración con Salesforce: arquitectura frágil, problemas de resiliencia, metodología de testing pobre e incapacidad para entregar cambios sin romper producción. Desde una posición de consultoría interna y sin ser el manager del equipo, Daniel se incorporó temporalmente durante unos meses para rediseñar la arquitectura de integración, el modelo de APEX y el enfoque de pruebas. Partiendo de cero conocimiento previo de Salesforce, el trabajo se centró en principios de diseño, fiabilidad y disciplina de testing. El resultado fue una integración más estable, con menos incidentes encadenados y capacidad de entrega sostenida.

El equipo responsable del CMS corporativo de una empresa sufría problemas graves de rendimiento, bugs constantes y una incapacidad práctica para dar servicio al negocio. Sin autoridad jerárquica sobre el equipo, Daniel se incorporó temporalmente para analizar la arquitectura elegida, identificar cuellos de botella y ajustar tanto el diseño como la forma de trabajar. El objetivo fue estabilizar la plataforma y devolver al equipo capacidad de entrega.

Un equipo de Design System estimaba un año de trabajo. Tras análisis estratégico, el problema no era técnico ni de recursos: el equipo actuaba como cuello de botella («nosotros construimos todo antes de que nadie pueda usarlo») en lugar de como plataforma habilitadora. La intervención consistió en separar objetivos mezclados, reducir el scope inicial agresivamente, y cambiar el modelo operativo: de construir componentes a gobernar cómo otros los construyen. Resultado: integración completada en menos de 4 meses.

Una organización internacional de software para el sector público necesitaba decidir cómo evolucionar su arquitectura de seguridad basada en Keycloak. Daniel evaluó seis combinaciones de autenticación (frontend vs backend, stateful vs stateless) y autorización (UMA, Entitlements, solución propia), documentando cada flujo con diagramas de secuencia detallados y analizando su escalabilidad para volúmenes de producción (150 tenants, 15k recursos). El análisis incluyó pruebas de concepto funcionales y concluyó con recomendaciones concretas: las opciones Entitlements y UMA no escalaban para el caso de uso, mientras que la arquitectura actual podía mantenerse salvo necesidad de single sign-off o crecimiento significativo de roles por usuario.