Elevate ·
Woffu · Contexto inicial
¿Por qué Woffu?
Punto de partida

Woffu es una de las plataformas líderes de gestión de RRHH y presencia laboral en España. Fundada en Barcelona y hoy parte del grupo Visma, la empresa ayuda a miles de negocios a gestionar control horario, turnos y presencia de empleados — un producto construido a lo largo de una década por un equipo muy cohesionado.

Cuando Elevate entró en escena, Woffu no estaba en crisis. Woffu tiene personas con talento. El producto era real. Pero la organización había crecido de una forma en la que el sistema de entrega no había escalado a la par que la ambición. La expectativa de Visma era clara: más impacto con el mismo equipo.

Elisabeth, CEO de Woffu, señaló específicamente a Producto e Ingeniería como la siguiente palanca de cambio — tanto cultural como operacional. El mandato era preciso: evolucionar hacia una organización más orientada al mercado y a los objetivos, sin perder lo que hace especial a Woffu.

La colaboración con Elevate nace con el compromiso de empezar midiendo el estado actual antes de tocar nada, y secuenciar los cambios para crear un efecto bola de nieve en lugar de abrir todos los frentes a la vez.

Objetivo Elevate
Claridad · Foco · Autonomía
Woffu · Lo que encontramos en las entrevistas
Los Problemas
3 problemas clave
01
Estrategia de Producto débil frente a la presión de demanda
Muchas peticiones, sin datos para decidir
Las decisiones de producto se tomaban por peticiones de clientes e intuición, no por métricas de uso, adopción o ingresos.
El backlog ICE tenía alrededor de 1.500 entradas — muchas duplicadas, creando la ilusión de opciones sin aportar dirección real.
En un contexto donde Visma espera "más impacto con el mismo equipo", cada apuesta equivocada era cara.
02
Multitarea crónica y tickets interminables
PBIs que se arrastran de sprint en sprint durante meses
Los equipos "atacaban muchos frentes a la vez" porque la demanda constante hacía que parar pareciera imposible.
El conocimiento estaba concentrado en personas concretas — si esa persona se iba de vacaciones, esos tickets simplemente esperaban.
Nadie lo notaba. Nadie presionaba. El WIP invisible era el doble de lo que cualquiera percibía.
03
Función de Producto inmadura y con exceso de dependencias
Pensamiento estratégico concentrado en una o dos personas
La distinción PM/PO era de etiquetas, no de una definición compartida e impulsada por impacto de lo que "producto" debía poseer.
El pensamiento estratégico estaba concentrado en muy pocas personas, lo que generaba un punto único de fallo en la toma de decisiones.
Marcos reconoció abiertamente las carencias y solicitó apoyo externo para construir una organización más sólida y autónoma.
Woffu · Feedback directo de los empleados
En palabras de Woffu
Entrevistas iniciales
"
El principal problema era la falta de foco. El equipo estaba atacando muchísimos frentes al mismo tiempo debido a la llegada constante de trabajo.
Gonzalo Lebron · Team Lead
"
El día a día se caracterizaba por plannings en las que las tareas no terminadas se movían al siguiente sprint, generando un 'tocho gordo' de tareas.
Kiko Meroño · Frontend Developer
"
No era muy raro ver PBI de un mes. Una tarea que tiene dos semanas o una semana y no pasaba nada. A nadie le picaba.
José Manuel Rivas · Sr. Backend Developer
"
El conocimiento estaba concentrado en una sola persona. Siempre esa misma persona tomaba los mismos tickets porque es lo que conoce.
Gonzalo Lebron · Team Lead
"
Teníamos un problema muy grande que era que no éramos capaces de visualizar y comunicar todo el trabajo que se hacía.
Helena Valls · Head of Product
"
Se trabajaba prácticamente solo. Siempre esa misma persona tomaba los mismos tickets porque es lo que conoce. Si esa persona se iba de vacaciones, esos tickets simplemente esperaban.
Gonzalo Lebron · Team Lead
Ciclo 1 · Qué queríamos lograr
Objetivos del Ciclo
4 objetivos
01 · Estratégico
Establecer una línea base de medición
02 · Proceso
Introducir un sistema de trabajo compartido
03 · Cultural
Iniciar el cambio de mentalidad
04 · Visibilidad
Hacer visible el impacto del trabajo
Ciclo 1 · Estructura y entregables
Estructura del Ciclo y Tareas
Semanas 1–6
Estructura del ciclo
1
Semanas 1–2
Diagnóstico inicial
2
Semanas 3–4
Sistema en marcha
3
Semanas 5–6
Aprendizajes y ajustes
Ciclo 2
Próximas semanas
✓ Completado
Kick-off de la clínica Proceso
Power-up 1: Preparar un Board que no mienta Formación
Power-up 2: Métricas en el Delivery. Qué medir y por qué. Formación
Power-up 3: Roles y Responsabilidades en el Delivery Formación
Power-up 4: Mejora Continua en equipos Formación
Primera foto consistente del estado de los equipos (ESTT y métricas) Diagnóstico
Métricas del ciclo
5
Squads
activados
4
Power-ups
realizados
1
Diagnóstico
ESTT + métricas
Ciclo 1 · Qué hemos encontrado
Aprendizajes Clave
5 aprendizajes
Riesgo
Desalineación entre percepción y realidad del avance
Aunque el programa ha empezado a mejorar comportamientos y métricas de delivery, parte del leadership sigue percibiendo una pérdida de velocidad. Esto ha generado tensión: los datos apuntan a más orden, pero la sensación interna es de freno y estancamiento.
Learning
Antes de acelerar producto, había que ordenar el flujo
El principal aprendizaje ha sido que Woffu no puede mejorar de forma sostenible solo empujando más trabajo. Primero hace falta instalar unas bases comunes de delivery: WIP, métricas, backlog, roles, mejora continua y definition of ready/done.
Riesgo
Los problemas de delivery escondían problemas más profundos
Lo que parecía un problema de organización del trabajo ha terminado revelando algo más estructural: legacy, knowledge silos, equipos con encaje desigual en el modelo y fronteras difusas entre producto y tecnología.
Turning Point
El cambio ha dejado de ser teórico y ha empezado a tocar poder, hábitos y expectativas
El punto de inflexión ha llegado cuando el marco ha empezado a hacer visibles excepciones y fricciones reales. Ahí se ha visto que el reto ya no es solo "entender Elevate", sino sostener las implicaciones del cambio en la práctica.
Learning
La adopción ha sido rápida, pero no homogénea
Woffu ha mostrado una buena disposición inicial y algunos equipos han incorporado pronto el lenguaje y las prácticas del sistema. Pero el avance no ha sido uniforme: el ritmo de adopción varía según el equipo, y consolidar el cambio requiere un acompañamiento diferenciado.
Ciclo 2
Alinear percepciones, atacar excepciones y conectar el orden del delivery con las decisiones de producto.
Ciclo 2 · Estructura y entregables
Estructura del Ciclo y Tareas
Semanas 7–12
Estructura del ciclo
1
Semanas 7–8
Profundizar en prácticas
2
Semanas 9–10
Consolidar y estabilizar
3
Semanas 11–12
Métricas estabilizadas
Ciclo 3
Próximas semanas
✓ Completado
Power-up 5: Stop starting, start finishing. Limitar el WIP en los equipos de software. Formación
Power-up 6: Definir bien las tareas, asegurarse que se completan Formación
Power-up 7: Tamaños y estimaciones de las tareas Formación
Power-up 8: Por qué y cómo partir tareas grandes Formación
Power-up 9: Categorizar los distintos tipos de tarea Formación
10 iteraciones semanales de mejora continua de los equipos Proceso
Métricas de delivery estabilizadas Diagnóstico
Métricas del ciclo
5
Power-ups
realizados
10
Iteraciones
de mejora
5
Squads
estabilizados
Ciclo 2 · Qué hemos encontrado
Aprendizajes Clave
4 aprendizajes
Learning
Ordenar el delivery ha reducido el caos y ha mejorado el foco del trabajo
El mayor impacto del ciclo ha estado en instalar una forma de trabajo más clara: menos multitarea, más capacidad de cerrar dentro del sprint y más colaboración real entre personas del mismo equipo.
Turning Point
WIP ha pasado de ser una fricción a convertirse en la palanca más valorada
Al principio ha generado resistencia e incomodidad, pero ha terminado siendo una de las piezas que más ha ayudado a crear foco, repartir conocimiento y detectar cuándo el equipo está abriendo demasiado trabajo a la vez.
Learning
Las métricas han empezado a dar visibilidad real al trabajo del equipo
El orden en delivery ha permitido empezar a demostrar con datos qué trabajo se hace, cuánto cabe realmente y qué capacidad tiene cada equipo. Eso ha mejorado la conversación con leadership y con otras áreas.
Next Step
El orden del delivery ha empezado a exponer problemas que ya no viven dentro del equipo, sino fuera de él
Cuando el flujo ha empezado a estabilizarse, ha quedado más visible que parte del bloqueo real está en la conexión entre liderazgo, estrategia, producto y toma de decisiones.
Ciclo 3
Convertir el orden del delivery en decisiones de producto más claras, medibles y sostenibles.
Ciclo 3 · Estructura y entregables
Estructura del Ciclo y Tareas
Semanas 13–18
Estructura del ciclo
1
Semanas 13–14
Kick-off Fase 2: Delivery & Discovery
2
Semanas 15–16
Alineación OKRs y diagnóstico cross-funcional
3
Semanas 17–18
Impact Mapping con equipos
Ciclo 4
Próximas semanas
✓ Completado
Kick-off Fase 2: Delivery & Discovery Proceso
Power-up: Input Mapping — conectar iniciativas con objetivos de negocio Formación
Taller de alineación OKRs con middle management y liderazgo Proceso
Power-up: Conectar iniciativas a OKRs — ejercicio de Impact Mapping Formación
Diagnóstico cross-funcional con Customer Experience Diagnóstico
Sesiones de alineación con dirección: priorización y gestión de producto Diagnóstico
Métricas del ciclo
2
Power-ups
realizados
1
Taller
OKRs
3
Sesiones
de coordinación
Ciclo 3 · Qué hemos encontrado
Aprendizajes Clave
5 aprendizajes
Turning Point
El delivery está instalado: el foco se mueve al upstream
La parte de delivery se considera consolidada. El ciclo ha sido el punto de inflexión para pasar de "cómo sacamos cosas" a "qué cosas deberíamos estar sacando y por qué". El nuevo reto ya no es la velocidad de entrega, sino ligar cada iniciativa a objetivos reales de negocio.
Riesgo
Los equipos trabajan sin saber a qué objetivo sirven
El mapa de producto arroja un diagnóstico claro: los equipos de desarrollo desconocen el foco estratégico. Sacan tareas del backlog sin trazabilidad hacia objetivos. La brecha entre la dirección de producto y la ejecución de los equipos es el principal punto rojo del ciclo.
Learning
Los bugs acumulados son el síntoma de una priorización rota, no de falta de capacidad
Experience y soporte llevan meses absorbiendo el impacto de bugs sin resolver. La causa raíz no es la velocidad de los equipos, sino la falta de criterios claros para decidir qué bug se ataca primero. Sin objetivos definidos, el listado de 50+ bugs no tiene ningún orden racional.
Riesgo
La desconexión con Experience y Cliente se ha hecho visible
El canal entre producto y las áreas de cara al cliente lleva meses sin funcionar de forma estructurada. Las peticiones de mejora se acumulan sin priorización, las funcionalidades salen sin criterio de "done" y el cliente percibe el producto como algo que no mejora.
Next Step
Conectar cada iniciativa a un objetivo, un actor y un impacto medible
El trabajo del próximo ciclo es bajar los OKRs hasta el backlog real de cada equipo: objetivo → actor → impacto → iniciativa. Cada equipo debe ser capaz de trazar por qué está haciendo lo que está haciendo.
Ciclo 4
Conectar cada iniciativa a un objetivo, un actor y un impacto medible. Impact Mapping y definición de roles de producto.
Ciclo 4 · Estructura y entregables
Estructura del Ciclo y Tareas
Semanas 19–24
Estructura del ciclo
1
Semanas 19–20
Roles de producto y formación
2
Semanas 21–22
Impact Mapping con producto
3
Semanas 23–24
Alineación estratégica y OKRs
Ciclo 5
Próximas semanas
✓ Completado
Impact Mapping con equipos de producto — 3 sesiones de trabajo Proceso
Power-up: Roles y Responsabilidades en el equipo de producto Formación
Sesión de cierre de Job Description — nuevo perfil de producto Proceso
Sesiones de alineación estratégica con dirección Diagnóstico
Revisión de OKRs y simplificación del modelo de seguimiento Diagnóstico
Métricas del ciclo
3
Sesiones
Impact Mapping
1
Power-up
realizado
3
Sesiones
de dirección
Ciclo 4 · Qué hemos encontrado
Aprendizajes Clave
4 aprendizajes
Turning Point
El Impact Mapping llega al producto, pero revela que se trabaja en proyectos, no en outcomes
Al conectar iniciativas con objetivos, se ha expuesto el patrón real: grandes proyectos que impactan a muchos actores a la vez, sin slicing, sin criterio claro de cuándo algo está terminado. El ejercicio no solo enseña una herramienta, sino que evidencia que el equipo aún opera como project managers, no como product managers.
Riesgo
La función de producto necesita liderazgo estratégico con urgencia
Se ha hecho evidente que la organización necesita una figura que gobierne el producto con criterio estratégico. Mientras eso no ocurra, los equipos seguirán resolviendo tareas sin una dirección clara que conecte su trabajo con los objetivos de negocio.
Learning
Los OKRs están bien definidos, pero no han aterrizado en el trabajo real
Los OKRs están bien construidos técnicamente, pero flotan desconectados de lo que los equipos hacen cada día. Nadie se responsabiliza de moverlos, nadie sabe qué tipo de trabajo contribuye a qué métrica. La brecha entre los objetivos estratégicos y el backlog de los equipos es total.
Next Step
Poner a cada persona en su sitio — OKRs con el Motor Team, slicing con los POs, y liderazgo de producto
Los tres frentes abiertos son: (1) redefinir quién define los OKRs y con qué responsabilidad real, (2) entrenar a los POs en slicing para pasar de proyectos a entregas pequeñas y trazables, y (3) cerrar el proceso de búsqueda de un perfil de producto con visión estratégica.
Ciclo 5
OKRs con el Motor Team, slicing con los POs, y liderazgo de producto con visión estratégica.
Ciclo 5 · Estructura y entregables
Estructura del Ciclo y Tareas
Semanas 25–30
Estructura del ciclo
1
Semana 25
Impact Mapping con Motor Team
2
Semana 26
Nueva dinámica Motor Team
Semanas 27–30
En progreso
Ciclo 6
Próximas semanas
✓ Completado
Impact Mapping con Motor Team ampliado — sesión presencial Proceso
Primera sesión Motor Team con nueva dinámica de review Proceso
○ En progreso
Consolidación de la dinámica del Motor Team y métricas compartidas
Ciclo 5 · Qué estamos encontrando
Aprendizajes Clave
4 aprendizajes
Turning Point
El Motor Team se ve por primera vez como un equipo, no como un comité de reporting
La sesión presencial de Impact Mapping y la nueva dinámica del Motor Team son el primer momento real en que el liderazgo de Woffu se sienta junto a co-crear en lugar de reportarse mutuamente. La dinámica de silos no era intencional, pero estaba totalmente instalada.
Learning
Los objetivos siempre han estado claros. El problema era el sistema para ponerlos juntos
Lo que ha faltado es un sistema compartido que conecte esos objetivos con el trabajo diario de cada área y que obligue a una cadencia de revisión real.
Riesgo
La empresa sigue gestionando proyectos grandes en lugar de MVPs
Las métricas de delivery revelan que la capacidad real para entregar cosas nuevas es una fracción del total: la mayoría del tiempo se va en bugs, mejoras reactivas y requests entre equipos. Con ese contexto, los proyectos de varios meses son irreales por definición, y generan costes hundidos cada vez que se interrumpen.
Riesgo
Las métricas de la empresa no tienen dueño y no se miran juntas
Se ha confirmado que los OKRs llevan tiempo sin actualizarse de forma colectiva. Nadie persigue las métricas porque nadie se siente responsable de ellas colectivamente. El acuerdo de rotating ownership para actualizar las métricas clave es el primer paso real para romper este patrón.
Este ciclo se completará al finalizar las semanas 31–36.
Product & Engineering
Equipo Priorizador Miembros Board Acciones
Connectivity Víctor Ramírez Arnau Casanova, Cristian Moreno, Luis Felipe Martín 🔗 Azure DevOps
Cross-Cutting Marcos / Helena Rodrigo Valdez, Francisco Meroño, Alejandro Lazarte 🔗 Azure DevOps
Turnos Víctor Pérez Dean Fentes, Gonzalo Gallego, Héctor García, Hiran Díaz 🔗 Azure DevOps
Presencia-Ausencia Gersom Peris Gonzalo Lebron, Reynier Claro, José Manuel Rivas, Joaquin Mautone, Diego Jiménez, Gilberto Arquiz 🔗 Azure DevOps
DevOps Marcos Varela Luis Cobarrubia, Sara Morán 🔗 Azure DevOps
ESTT ·
Métricas ·
Historial