Long Suciu construyó una suite de dashboards de Power BI en Gartner que extraía datos directamente de Jira y se actualizaba diariamente. En este segmento de su conversación con Patrycja Radwanska en la serie Let’s Talk Operations, explica por qué los dashboards funcionaron cuando la mayoría de dashboards internos no funcionan, cómo la visibilidad de los objetivos de sprint cambió la forma en que los managers de ingeniería dedicaban sus mañanas, y por qué mostrar a la gente el tamaño de su backlog es el camino más eficiente para conseguir que lo limpien.
El principio de diseño: legible, accesible, comprensible
Suciu es directo sobre lo que hace útil a un dashboard. No es la sofisticación de las visualizaciones ni el número de fuentes de datos que agrega. Es si la audiencia para la que fue construido puede leerlo, interpretarlo y actuar en consecuencia. Suena al listón más bajo posible. Es, en la práctica, el listón que la mayoría de dashboards internos no logran superar.
Los dashboards de Power BI que construyó fueron diseñados con managers de ingeniería y líderes de producto como audiencia principal. No analistas de datos. No especialistas de BI. Gente que tenía 15 minutos por la mañana antes de su primera reunión y necesitaba saber si algo requería su atención. Todo lo que aparecía en el dashboard tenía que pasar una prueba de legibilidad: ¿podría alguien que lo abriese por primera vez entender lo que le estaba contando en 30 segundos?
Objetivos de sprint en una sola pantalla
El primer dashboard mostraba el objetivo de sprint declarado de cada equipo. No enterrado a tres clics de profundidad en un proyecto de Jira. No en una página de Confluence que nadie había actualizado desde el sprint anterior. Ahí, en una pantalla, todos los equipos visibles, actualizado diariamente.
El efecto en el comportamiento organizacional fue inmediato y sorprendentemente amplio. Los managers de ingeniería podían ver de un vistazo a qué estaba dedicado cada equipo. Un director de producto que creía que otro equipo iba a trabajar en su dependencia podía ver, sin preguntar a nadie, que el equipo tenía otras prioridades. Esa visibilidad por sí sola eliminó toda una categoría de reuniones – la reunión de “solo quería comprobar si estáis haciendo lo que dijisteis que haríais” que consume horas en una organización y no produce nada excepto la confirmación de que deberías haber mirado el dashboard.
“Un director de producto podía leer lo que un equipo estaba haciendo y empezar la pregunta: pero necesito que hagan algo para mí.”
Los dashboards también mostraban el progreso de sprint y la distribución de trabajo dentro de cada equipo. Esto servía un propósito más matizado: antes de pedir a un equipo que dejara todo para una petición urgente, un stakeholder podía ver qué tendría que sacrificarse. La conversación pasó de “¿podéis hacer esto?” a “¿a qué estáis dispuestos a renunciar para hacer esto?” – que es una pregunta fundamentalmente más productiva porque reconoce que la capacidad es finita y las prioridades son reales.
Visibilidad de backlog: el dashboard que nadie quería
El dashboard de tamaño de backlog fue, según la propia descripción de Suciu, el que más incomodó a la gente. Cuando pones el tamaño de backlog de cada equipo en una sola pantalla, las disparidades son imposibles de ignorar. Algunos equipos iban al día, con apenas suficiente trabajo en cola para el próximo sprint. Otros tenían backlogs tan grandes que, si dejaran de crear tickets nuevos por completo, tardarían dos años en completar lo que ya había ahí.
La incómoda verdad era que la mayoría de esos backlogs de dos años estaban llenos de tickets en los que nadie iba a trabajar jamás. Ideas que parecían urgentes hace seis meses y se habían olvidado silenciosamente. Bugs que no eran realmente bugs. Peticiones de funcionalidades de stakeholders que se habían trasladado a otros departamentos. El backlog se había convertido en un desván digital: un lugar donde las cosas iban a almacenarse indefinidamente y nunca volvían a examinarse.
El enfoque de Suciu para la limpieza se enmarcaba deliberadamente de una forma difícil de rebatir. Identificaba tickets creados hace más de un año, calculaba qué porcentaje del backlog representaban, y luego preguntaba: “¿Te parece bien si los archivo todos?” Planteado así – lógico, específico, cuantificado – la resistencia emocional a borrar cualquier cosa se encontraba con la realidad práctica de que nadie iba a trabajar en ello jamás.
“No tiene sentido lógico que digan que no en voz alta, aunque en el fondo estén pensando: no, no eliminamos tickets.”
La objeción más frecuente era “¿y si ese bug vuelve?” La respuesta de Suciu era desarmantemente simple: si vuelve, creas un ticket nuevo. O desarchivas el antiguo. El coste de mantener mil tickets irrelevantes a perpetuidad – la carga cognitiva de escanearlos, la distorsión que crean en cualquier métrica que referencie el tamaño del backlog, la falsa sensación de ocupación que producen – supera con creces el coste de recrear el ticket ocasional que resulta haber sido relevante después de todo.
Expansión incremental de dashboards
Suciu no construyó todos los dashboards a la vez. Empezó con objetivos de sprint, demostró el valor, y luego añadió incrementalmente nuevas vistas que introducían nuevos conceptos. Esta era una estrategia deliberada. Cada nuevo dashboard era una oportunidad para cambiar comportamiento: no mediante mandatos, sino mediante visibilidad. Cuando la gente puede ver los datos, empieza a hacer preguntas sobre los datos, y esas preguntas llevan a las conversaciones que impulsan la mejora.
El principio subyacente a todo ello es uno al que vuelve a lo largo de toda la entrevista: las herramientas deben reforzar el comportamiento que quieres, no crear comportamiento que no pretendías. Un dashboard que muestra objetivos de sprint refuerza el comportamiento de establecer objetivos. Un dashboard que muestra el tamaño del backlog refuerza el comportamiento de mantener los backlogs limpios. La herramienta no hace el trabajo. Hace visible el trabajo correcto, y la visibilidad – genuina, diaria, imposible de ignorar – resulta ser una de las palancas más poderosas que tiene un líder de operaciones.
Para el desglose completo de la entrevista, consulta nuestra entrevista completa con Long Suciu.
Herramientas mencionadas en la entrevista
Las siguientes herramientas y plataformas fueron mencionadas durante esta conversación.
Contenido relacionado
Operaciones de producto a escala sin romper equipos: entrevista con Long Suciu
Long Suciu lleva 25 años rediseñando cómo los equipos de producto e ingeniería planifican, priorizan y entregan. Explica por qué los story points suelen ser lo primero en eliminarse, cómo una cadencia de planificación trimestral de seis semanas alineó a más de 30 equipos en Gartner, y por qué las herramientas deben reforzar comportamientos en lugar de reemplazarlos.
Reducir el lead time de 52 a 13 semanas mapeando el recorrido del cliente
Long Suciu ayudó a un equipo de APIs de la industria de viajes a reducir su lead time de entrega de más de un año a un solo trimestre. El método no fue un cambio de proceso: fue una conversación sobre recorridos de cliente que hizo que un director de producto viera una funcionalidad que podía entregar inmediatamente.
Una cadencia de planificación trimestral de seis semanas que escala en 30 equipos
Long Suciu construyó un proceso de planificación trimestral en Gartner que eliminó el caos del patrocinio ad-hoc de proyectos. Desglosa la cadencia exacta de seis semanas -- pensar, compartir, solidificar -- que trajo alineamiento a más de 30 equipos de producto.