Extensión de un dominio core compartido y gobernanza de arquitectura en SaaS

En la plataforma SaaS de gestión de RR. HH. de Buk, el modelo de datos de Colaborador era un bloque transversal reutilizado a lo largo del producto. El building block de participantes construido sobre él daba servicio al módulo de encuestas y a otros módulos mantenidos por equipos distintos, y asumía implícitamente que todo usuario registrado era un colaborador activo.

Al requerir, desde el módulo de cultura, el lanzamiento de encuestas para ex-colaboradores (procesos de offboarding y encuestas de salida), el sistema no permitía cargar ni consultar usuarios desvinculados sin alterar el comportamiento de los módulos que ya dependían de ese componente.

Como champion/líder de la misión, debía conducirla de extremo a extremo — discovery técnico, planificación del delivery y desarrollo— para que el módulo de encuestas admitiera como destinatarios a los ex-colaboradores desvinculados, garantizando retrocompatibilidad con los módulos que ya consumían el componente y la aprobación técnica del equipo central de Plataforma.

1. Discovery técnico y análisis de impacto: abrí la misión con un documento de diseño que evaluaba alternativas de solución, el modelo de datos, los riesgos y el plan de despliegue. Sobre esa base audité el código para identificar todos los acoplamientos y las consultas directas a la entidad Colaborador entre los módulos consumidores, antes de tocar una sola línea de la interfaz compartida.
2. Extensión defensiva y retrocompatibilidad: sin modificar el modelo de Colaborador —mantenido por otro equipo—, extendí desde el módulo de cultura los filtros de su controlador para exponer el estado (activo/desvinculado) como criterio de selección de la audiencia al crear la campaña, apoyándome en los scopes que el modelo ya ofrecía. Las llamadas existentes conservaron su comportamiento previo sin cambios. El trabajo se concentró en el backend y en el building block de participantes —una interfaz interna de Rails que combina ERB, cells, JavaScript y widgets Vue—; los ajustes de interfaz fueron puntuales.
3. Gobernanza y estrategia de pull requests: traduje el diseño a tarjetas acotadas, con criterios de aceptación y plan de pruebas propios, y fragmenté el trabajo en cambios atómicos y revisables. Coordiné las revisiones de arquitectura con el equipo de Plataforma para cumplir los estándares de rendimiento y seguridad de la base de código principal, y con los equipos de UX, UI y design system cada vez que un cambio modificaba componentes de interfaz existentes.
4. Plan de pruebas y QA exhaustivo: asumí la calidad de la misión de punta a punta, definiendo una matriz de pruebas de regresión y automatizando pruebas unitarias y de integración para certificar que los flujos de los módulos consumidores no sufrieran alteración alguna.

Compromisos de ingeniería (trade-offs)

• Audiencia excluyente y fijada al inicio vs. audiencia mixta o editable: cada campaña se dirige a colaboradores activos o a desvinculados, nunca a ambos, y su audiencia queda congelada una vez iniciada. Renunciar a la flexibilidad de mezclar públicos o corregirla sobre la marcha evitó cruces de destinatarios y resultados entre poblaciones que no son comparables, a cambio de obligar a planificar bien la campaña antes de lanzarla.
• QA exhaustivo vs. velocidad de despliegue: invertir en revisión atómica de pull requests con el equipo de Plataforma, en aprobaciones de UX/UI/design system para los ajustes de interfaz y en pruebas de regresión cruzadas extendió el time-to-market de la funcionalidad, a cambio de reducir al mínimo el riesgo de caídas o inconsistencias en los módulos que ya consumían el componente.

Se habilitó el módulo de encuestas a ex-colaboradores (offboarding), abriendo una nueva línea de métricas de retención de talento para las empresas clientes, y su uso creció tras la habilitación.