EL PROYECTO DE UN VISTAZO
Rol
Iniciativa propia · Liderazgo de adopción
Dominio
Salud · Entorno regulado
Alcance
14 equipos · Diseño, desarrollo, producto, stakeholders
Framework
Ramas de Figma · Jira · SAFe
Foco
Cambio de comportamiento a escala · Romper silos · Documentación viva
Cómo una metodología nacida de la escucha cambió la forma de trabajar de un equipo completo.
Catorce equipos. Cada uno con su PM, su PO, sus diseñadores, sus desarrolladores. Cada uno entregando funcionalidad. Sobre el papel, una organización funcionando.
En la práctica, catorce islas.
Nadie había decidido que esto fuera así. Simplemente, nadie había tenido el espacio, el tiempo o el mandato para mirar el conjunto y preguntarse: ¿y si trabajáramos de otra forma?
PLANTAR UNA SEMILLA, NO IMPONER UN PROCESO
Ninguno tenía el problema completo. Todos tenían un fragmento.
No llegué con un documento de quince páginas explicando cómo debíamos trabajar todos a partir de entonces. Eso habría cerrado la conversación antes de empezar.
Lo que hice fue más simple, y ahora sé que mucho más eficaz. Escuché de cerca lo que cada equipo necesitaba, y conecté esas necesidades entre sí. Una diseñadora que no sabía cómo versionar su trabajo sin pisar el de otra persona. Un PO que no entendía por qué Jira parecía hablar un idioma distinto al de diseño. Un desarrollador que recibía un archivo de Figma sin saber qué había cambiado desde el anterior.
Ninguno tenía el problema entero. Cada uno tenía una parte. Mi trabajo era juntar las partes y mostrar que todas describían el mismo problema desde ángulos distintos.
Esa fue la semilla. No impuse nada a nadie. Puse en voz alta lo que todos sentían pero nadie había nombrado, y pregunté: ¿y si lo resolvemos juntos?
La respuesta fue que aparecieron aliados. Personas dispuestas a probar, a iterar, a dar feedback honesto cuando algo no funcionaba. Eso fue lo que convirtió una idea en una metodología de verdad.
La diseñadora
No sabía cómo versionar su trabajo sin pisar el de otra persona.
El PO
No entendía por qué Jira parecía hablar un idioma distinto al de diseño.
El desarrollador
Recibía un archivo de Figma sin saber qué había cambiado desde el anterior.
LA METODOLOGÍA, PIEZA A PIEZA
Construimos la base con cuatro piezas que se sostienen entre sí.
Roles claros desde el principio
Quién reporta una feature, quién decide si va al backlog o se prioriza, quién la convierte en un issue de Jira, quién la diseña, quién la revisa, quién da la aprobación final. Esto no iba de añadir burocracia. Cuando nadie sabe de quién es una decisión, todos esperan a todos.
Un recorrido compartido para cada feature
Desde que un manager reporta una necesidad hasta que la feature se integra en el archivo maestro, mapeamos un camino con pasos claros y con nombre: discovery, exploración de diseño, revisión con los equipos que debían validarla, iteración, una segunda revisión, aprobación, merge. Once pasos. Pocas features necesitaban los once. Lo que importaba era que todos podían ver por fin qué pasos existían, y en qué punto estaba cualquier trabajo en cada momento.
Jira como lenguaje compartido
Bajo el framework SAFe, definimos qué significaba cada tipo de issue (Epic, User Story, Task, Bug, Enabler) y qué aspecto tenía una tarea bien definida: clara, específica, asignada, priorizada, estimada, vinculada a una user story y rastreable. Escrito así suena obvio. Antes de esto, cada equipo leía esas palabras a su manera, lo que significaba que dos equipos podían usar la misma palabra para cosas completamente distintas.
Ramas en Figma, con trazabilidad real
Cada cambio en su propia rama, vinculada a un ticket de Jira. Nadie tocando el archivo maestro directamente. Un historial de versiones que cualquiera podía seguir, y una forma clara de crear una nueva release: duplicar el archivo principal, congelarlo, renombrarlo y seguir sin perder ni un paso del trabajo ya hecho.
EL MOMENTO DE TENSIÓN: LAS RAMAS
No era resistencia al cambio. Era miedo. Y un miedo completamente legítimo.
De las cuatro piezas, una generó más resistencia que las otras tres juntas: las ramas.
La resistencia venía del miedo, y de un miedo del todo legítimo. ¿Y si olvido crear una rama vinculada a un ticket de Jira? ¿Y si toco el archivo maestro por error? ¿Y si rompo el trabajo de otra persona sin darme cuenta?
Para alguien que ha pasado años en un único archivo de Figma, sin versionado y sin ramas, mover cada cambio a su propio espacio hasta que está listo es más que un cambio de herramienta. Cambia cómo entiendes tu propio trabajo dentro de un sistema más grande.
Un manual no habría resuelto esto. Hicimos sesiones, una tras otra, donde la gente podía hacer la pregunta que le daba vergüenza plantear en una reunión grande. Donde podían ver, en tiempo real, qué pasaba si creaban una rama, qué pasaba si no, y por qué el historial de versiones que tanto temían perder estaba ahora más seguro que nunca.
Poco a poco, el miedo se volvió hábito. Y el hábito, con el tiempo, se volvió algo que nadie cuestionaba.
"Llegamos a un punto en el que el 90% del equipo de diseño ya no sabía abrir un archivo de Figma sin abrir antes una rama. No porque se les obligara. Para entonces, trabajar de cualquier otra forma simplemente habría costado más."
Y cuando un equipo completó una feature de principio a fin por primera vez, siguiendo el recorrido entero desde el reporte inicial hasta el merge en el archivo maestro, sin que nadie se parara a preguntar "¿y ahora qué?", supimos que ya no era un experimento. Era, sin más, cómo trabajábamos.
EL DOCUMENTO PARA TU YO DEL FUTURO
Memoria de pez organizacional. La única vacuna es documentar para quien todavía no ha llegado.
Hay algo que aprendes en las organizaciones grandes y que nadie te cuenta hasta que lo vives: los equipos rotan. La gente cambia de trabajo, los proyectos se pausan por presupuesto, el foco salta de un producto a otro, y de repente alguien nuevo tiene que entender en una semana lo que a otra persona le llevó dos años aprender.
Yo lo llamo memoria de pez organizacional. La única cura es la documentación correcta, escrita en el momento correcto, para la persona que aún no ha llegado.
Así que creamos un documento funcional que respondía a las preguntas que esa persona del futuro haría:
Para qué sirve el producto, quién lo usa.
En qué contexto corre, qué dispositivos e idiomas debe soportar.
Qué requisitos de negocio hay detrás, qué es esencial y qué es solo deseable.
Qué investigación lo respalda y qué guías de uso existen.
Cómo se comportan de verdad los componentes: cómo desborda el texto, cómo se ven y funcionan en RTL, cómo había que estructurar el handoff a desarrollo para que ingeniería nunca tuviera que adivinar.
"Propusimos una librería intermedia, entre el design system oficial y los productos finales, donde los equipos pudieran construir sus propias moléculas, organismos y páginas, documentados en el mismo lenguaje que el sistema central."
— Librería intermedia de producto
Significaba que, cuando el design system sacaba una versión nueva, cada equipo de producto podía decidir, con información real, cuándo actualizar o cuándo mantener su versión actual sin perder su conexión con el sistema más amplio.
EVIDENCIA: LA METODOLOGÍA DENTRO DE LOS ARCHIVOS
Esto no vivía solo en la cabeza de la gente. Vivía dentro de cada archivo de Figma, como parte de su estructura.
