Informe 03 / Arquitectura de puestos y análisis retributivo
Producto en fase piloto con un trabajo detallado de producto, cumplimiento normativo, seguridad y precios.
03
Gradimio
Arquitectura de puestos y análisis retributivo
Una plataforma diseñada para el contexto español que reúne arquitectura y valoración de puestos, decisiones retributivas, transparencia salarial, documentación revisable, exportaciones y preparación para el cumplimiento normativo.
La gestión retributiva necesita decisiones trazables, no solo cifras finales.
El producto parte de las necesidades de RR. HH., Legal, Finanzas y los equipos retributivos: decisiones explicables, fuentes identificadas, procesos de revisión y documentación que puedan defender.
Cadena de decisión
RolValorBandaDocumentaciónInforme
Un ámbito de gran impacto donde los textos del producto deben evitar promesas que los datos no respaldan.
2
Prototipo codificado
El producto se convirtió en un espacio de trabajo retributivo que evoluciona con cada revisión.
El producto reúne puestos, descripciones, valoración por factores, empleados, importaciones y exportaciones, módulos de cumplimiento, documentación, análisis retributivo, precios y permisos por plan.
Módulos de producto
catálogo de roles
valoración de factores
registro retributivo
repositorio documental
Trabajo directo sobre el repositorio en un ámbito regulado y con gran volumen de datos.
3
Control de lanzamiento
La seguridad y la gobernanza están dentro de la promesa del producto.
El refuerzo cubrió riesgos de dependencias, referencias de empleados entre organizaciones, límites de importación CSV, esquemas de validación, cabeceras de seguridad, regresiones de autenticación, gobernanza de fuentes e informes que protegen la privacidad.
Controles de gobernanza
referencias entre organizaciones validadas
límites de CSV aplicados
encabezados de seguridad
límites del mapa de fuentes
reglas de supresión de privacidad
Trabajo de producto responsable: no convertir datos sensibles en automatización sin control.
4
Proceso de mejora
El producto mejora al aumentar la calidad de los datos y de la revisión.
La prueba más sólida está en el trabajo acumulado: validaciones, revisiones manuales, pruebas de precios, criterios sobre las fuentes, análisis de carencias normativas y una hoja de ruta disciplinada.
Ciclo de revisión
calidad de la fuente
decisiones de revisión
bandas de precios
brechas en la hoja de ruta
Desarrollo guiado por datos y revisión, sin presentar el producto como una solución legal completa.
Las decisiones retributivas tienen consecuencias importantes. Los equipos necesitan una arquitectura clara de puestos, datos salariales trazables, interpretación normativa, revisión humana y procesos que protejan la privacidad.
Lo que diseñé y construí
Un producto de análisis retributivo con catálogos de puestos, valoración por factores, correspondencias entre empleados y puestos, vistas de cumplimiento, fuentes documentadas, informes para revisión, planes de precios, exportaciones y medidas de seguridad.
Lo que demuestra
Que puedo convertir regulación, metodología y datos sensibles en funciones concretas, sin ocultar dónde hace falta revisión humana ni qué afirmaciones puede respaldar el producto.
Responsable y creador del productoRol
Producto en fase pilotoEstado
Datos y documentación retributivaLímites y controles
Controles normativos del productoMétodo de trabajo
01 / Capacidades demostradas
Criterio de producto B2B aplicado a decisiones sensibles que necesitan datos y documentación sólidos.
Gradimio muestra cómo trabajo en un ámbito B2B sensible donde el respaldo en fuentes, la trazabilidad, la privacidad, la revisión humana, los límites legales, el modelo de precios y la arquitectura de producto importan tanto como la interfaz.
Dominio
Gestión retributiva y preparación normativa en España
Modelo de producto
Puestos, empleados, valoración, informes y documentación
Planes
Inicial, Profesional, Empresa
La historia
La regulación se convirtió en un modelo de producto antes de convertirse en automatización.
Gradimio es el caso B2B donde más importa la calidad de los datos. El producto no podía limitarse a mostrar gráficos retributivos y llamarlos análisis. Había que explicar qué significa cada resultado, qué no puede concluirse y qué fuente o proceso respalda la decisión.
Convertí las obligaciones españolas y europeas de transparencia salarial en datos, estados de revisión, advertencias, documentación, permisos, informes y decisiones pendientes. Mantener estas piezas separadas es importante: una métrica interna útil no equivale por sí sola a una conclusión legal.
El caso muestra el trabajo de producto que debe ocurrir antes de modificar el código: comprender el repositorio, ordenar el ámbito, identificar los riesgos, definir qué datos respaldan cada decisión y solo entonces convertirlo en funciones concretas.
02 / Producto en funcionamiento
Capturas seleccionadas para mostrar cómo funciona el producto, no solo para decorarlo.
Pantallas seleccionadas del producto real.
Capturas del producto en funcionamiento, recortadas para que cada detalle pueda verse con claridad.
123Fig. 02 - Análisis retributivo con gráficos, filtros y tablas de datos.
1
Contexto ejecutivo antes del análisis
La página explica qué se está mostrando antes de pedir al usuario que interprete los datos retributivos.
2
Los datos que sustentan el gráfico permanecen visibles
Los gráficos, filtros, leyendas y tablas permanecen conectados para que el producto no convierta decisiones sensibles en resultados de caja negra.
3
Un espacio de trabajo preparado para la revisión
El cumplimiento, el contexto de la organización y la configuración siguen visibles porque cada decisión debe poder revisarse.
FactoresUn mapa de calor de factores permite examinar la arquitectura de puestos.
La matriz permite a los equipos de RR. HH. y retribución comparar puestos sin ocultar los criterios.
CumplimientoLos controles ejecutivos están separados del análisis detallado.
El estado de cumplimiento, los bloqueadores, las advertencias y las áreas de acción están estructurados para su revisión en lugar de estar enterrados en tablas de datos.
EvaluaciónLa valoración de puestos mantiene visible la puntuación.
La pantalla de detalle muestra la lógica de valoración para que las decisiones retributivas puedan explicarse y revisarse.
03 / Cadena de decisiones estratégicas
La cadena de decisiones que define la dirección del producto.
Esta sección explica el producto desde la perspectiva de gestión: para quién es, dónde empieza, cómo puede diferenciarse, qué capacidades necesita y cómo seguirá mejorando.
Aspiración
Hacer que las decisiones sobre puestos y retribución sean trazables, explicables y estén preparadas para una revisión normativa.
Dónde competir
Procesos para RR. HH., equipos retributivos, Legal, dirección y consultoría, diseñados para el contexto español.
Cómo ganar
Convertir un trabajo retributivo que exige conocimiento experto en valoraciones por factores, arquitectura de puestos, exportaciones, documentación y análisis.
Capacidades
Auth, Postgres/Prisma, modelo de datos de empleados, evaluaciones de factores, historial de auditoría, exportaciones, módulos de cumplimiento.
Sistema de gestión
Plan de reconstrucción y paridad, actualizaciones semanales de producto, módulos de precios, scripts de validación y monitorización de seguridad.
04 / Mapa de producto
Los usuarios, las interfaces y las capacidades que sostienen el producto.
Responsable integral del producto: investigación del ámbito, modelado regulatorio, arquitectura de datos, interfaz, precios, seguridad y flujos de validación.
Usuarios
Director de recursos humanos
Analista retributivo
revisor legal
Finanzas/director financiero
Auditor externo
Partes del producto
Catálogo de puestos
Datos de los empleados
Panel de cumplimiento
Repositorio documental
Informes y exportaciones
Capacidades
Métodos de valoración
Criterios de pago
Mapas de fuentes
Aprobaciones
Informes que protegen la privacidad
05 / Modelo de riesgos de producto
Valor, usabilidad, viabilidad técnica, viabilidad de negocio y confianza.
El mapa de riesgos muestra qué debía ser cierto antes de poder tratar el producto como algo más que un concepto.
Valor
¿El producto está anclado en obligaciones reales?
Los requisitos se corresponden con las obligaciones españolas y europeas de transparencia salarial y con la documentación necesaria para revisarlas.
Usabilidad
¿Pueden los equipos navegar por la complejidad?
El producto separa roles, datos, módulos de cumplimiento, informes y flujos de revisión en áreas diferenciadas.
Viabilidad técnica
¿Puede el modelo de datos soportar el dominio?
Los documentos definen fuentes legales, obligaciones, conceptos retributivos, grupos de igual valor, registros, entregables y eventos de auditoría.
Viabilidad de negocio
¿Pueden los planes reflejar el valor?
Tres planes públicos y bandas de empleados asignan el alcance del producto al tamaño de la empresa y las necesidades de cumplimiento.
Confianza
¿Se pueden manejar con cuidado los datos salariales confidenciales?
El refuerzo de la seguridad cubre referencias entre organizaciones, límites de CSV, validación de esquemas, cabeceras de seguridad, regresiones de autenticación y controles de privacidad.
La lección
Los productos sensibles necesitan reglas rastreables, no una automatización impresionante.
El análisis salarial empezó deliberadamente con un informe pequeño y respaldado por fuentes, no con una gran promesa de comparación automática. El objetivo era comprobar si la documentación ayudaba a quien revisa antes de formular afirmaciones más ambiciosas.
Ese criterio se repite en todo el caso: las versiones de metodología protegen las valoraciones históricas, la validación entre organizaciones protege los datos y los textos regulatorios evitan reducir obligaciones distintas a una puntuación de cumplimiento ambigua.
06 / Historias de aprendizaje de producto
Decisiones concretas que cambiaron el rumbo del producto.
Qué era ambiguo, qué decisión tomé y qué aprendimos de sus resultados.
De la regulación al producto
Las obligaciones legales se tradujeron en funciones y controles que pueden auditarse.
Restricción
Las normas europeas y españolas de transparencia salarial se solapaban. Habría sido fácil mezclar umbrales legales, análisis internos y documentación para revisión en una función poco definida.
Decisión
Separé las obligaciones legales del análisis interno de equidad y las convertí en datos, procesos, documentación, permisos y acciones concretas para el usuario.
Prueba
El modelo cubre grupos de igual valor, registros retributivos, solicitudes de trabajadores, auditorías, acciones correctivas y documentación, sin presentar sus resultados como conclusiones legales.
Validación de IA
El primer entregable de análisis salarial fue un informe documentado para revisión.
Restricción
Una propuesta amplia de comparación salarial con IA podía llevar a automatizar respuestas antes de aclarar la calidad de las fuentes, la privacidad y el papel de quien revisa.
Decisión
Probé el entregable útil más pequeño: un informe para revisión con fuentes citadas, evaluación de proveedores, reglas de privacidad y criterios explícitos de inclusión.
Prueba
La validación confirmó que el formato de revisión era útil y, a la vez, que todavía era pronto para publicar comparativas salariales automáticas.
Migración de metodología
Un nuevo método de puntuación no podía invalidar las valoraciones históricas.
Restricción
El cambio del método de valoración afectó a la interfaz de usuario, las API, las importaciones, los informes y los registros existentes.
Decisión
Usé un único motor de puntuación, versiones de metodología, cálculo al guardar, migración por fases, actualización de datos históricos, flags, pruebas controladas y un plan de reversión.
Prueba
Las valoraciones históricas permanecen fijadas en su método, mientras que los puntos de entrada futuros se calculan de forma coherente.
Causa raíz
La desaparición de un organigrama reveló un fallo en las invariantes de datos.
Restricción
Un organigrama desapareció sin que hubiera un error de ejecución porque las relaciones circulares, los empleados que dependían de sí mismos o los nodos sin raíz rompían la jerarquía.
Decisión
Seguí el problema hasta las invariantes de datos, reparé los registros y añadí detección compartida de ciclos, avisos recuperables en la interfaz y rechazo de relaciones inválidas en el límite de la API.
Prueba
Ahora el producto protege la invariante de jerarquía, en vez de tratar el problema como un simple fallo de renderizado.
07 / Relación con el método
Cómo se relaciona este caso con mi método de trabajo.
Cada caso principal muestra el mismo patrón: usar la IA para ampliar la capacidad de ejecución, mantener las decisiones bajo supervisión humana, reducir riesgos y establecer un proceso de mejora continua.
Creación asistida por IA
El brief antes de construir.
El trabajo se apoya en briefs de producto, conocimiento del repositorio, revisión de la implementación, controles de validación y mensajes verificables, no en instrucciones aisladas a la IA.
Criterio de producto
Criterio de producto B2B aplicado a decisiones sensibles que necesitan datos y documentación sólidos.
El caso muestra cómo reduje los riesgos de valor, usabilidad, tecnología y negocio, y qué límites y controles preparé para lanzar el producto con seguridad.
Siguiente etapa de mejora
Producto en fase piloto con un trabajo detallado de producto, cumplimiento normativo, seguridad y precios.
El siguiente paso es reunir mejores datos sobre el uso, los resultados del piloto, los controles operativos, la seguridad y las prioridades del producto.
Cómo la idea se convirtió en un sistema preparado para su lanzamiento.
El PRD de cumplimiento separa objetivos, exclusiones, perfiles, objetos, requisitos del MVP, módulos posteriores y límites para los textos del producto.
El modelo de precios y empaquetado conecta las capacidades del producto con las bandas de empleados y las familias de derechos.
La validación registra decisiones humanas sobre las fuentes y la documentación, en lugar de tratar el resultado de la IA como una verdad incuestionable.
El refuerzo de seguridad documenta el trabajo completado, los riesgos residuales, los resultados de las pruebas y los límites del lanzamiento.
09 / Seguridad y control
Cómo el producto protege a usuarios, datos y operaciones.
La validación de referencias de empleados evita guardar relaciones de roles o responsables que crucen los límites entre cuentas.
Los límites de tamaño, fila, columna, esquema y velocidad de importación de CSV reducen el abuso y la exposición accidental al riesgo de datos.
Una política CSP en modo report-only, cabeceras de seguridad, pruebas de regresión de autenticación y límites para datos sensibles sostienen un lanzamiento responsable.
10 / Lo que demuestra
Qué demuestra este caso a un equipo de producto.
Puede tomar decisiones de producto en ámbitos B2B regulados y con grandes exigencias de seguridad y fiabilidad.
Entiende cuándo los textos, los datos y la revisión humana forman parte de la seguridad del producto.
Puede crear una arquitectura de producto a partir de objetos legales/de dominio sin inutilizar la interfaz de usuario.
Puede integrar precios, permisos, seguridad y secuencia de roadmap dentro de una estrategia de producto.