Etiquetas de estado del flujo de trabajo: 7 estados claros que tu equipo puede compartir

Por qué las etiquetas vagas ralentizan el trabajo

Las etiquetas de estado vagas crean confusión que parece trabajo ocupado. La gente mueve elementos hacia adelante, pero nadie está seguro de qué cambió realmente. Un ticket marcado como “En Progreso” puede significar “empecé a pensar en esto”, “estoy bloqueado” o “ya está y espera revisión”, dependiendo de quién lo tocó por última vez.

Esa discrepancia provoca tres problemas previsibles: retrabajo, entregas perdidas y notificaciones ruidosas. Si un estado no dice qué debe hacer la siguiente persona, el trabajo rebota. Si una entrega está oculta dentro de una etiqueta vaga, se queda hasta que alguien la nota. Si todos actualizan estados solo para “señalar” actividad, tu feed se vuelve un borrón y los cambios reales son fáciles de pasar por alto.

Otro síntoma común es que la misma etiqueta se use de forma distinta en distintas pantallas. Un compañero usa “Listo” para decir “listo para revisión”. Otro usa “Listo” para decir “listo para comenzar”. Un gerente que revisa el tablero no puede saber si el equipo está esperando, trabajando o terminado.

El objetivo no es describir todos los casos límite. El objetivo es hacer que el camino normal sea obvio con menos estados y un significado más claro. Cuando los estados son consistentes en todas partes, las entregas son más rápidas y hay menos preguntas como “¿esto está realmente terminado?”.

Si tu equipo no sabe por dónde empezar, apunta a 5–7 estados que cubran la mayor parte del trabajo: uno para elementos nuevos, uno para trabajo activo, uno para trabajo en espera o bloqueado, uno para revisión o aprobación y uno para hecho. Añade detalle solo después de que lo básico esté estable y todos usen los mismos significados.

Qué debe (y no debe) significar una etiqueta de estado

Una etiqueta de estado es una promesa compartida sobre qué ocurre a continuación. Cuando alguien cambia un estado, todos deberían poder predecir el siguiente paso sin hacer una pregunta de seguimiento.

Las buenas etiquetas describen la realidad actual del trabajo, no la opinión de alguien sobre él. Si la etiqueta es verdadera, el equipo puede decir si el elemento se está moviendo, espera o está bloqueado, y quién debería tocarlo a continuación.

Un estado no es lo mismo que prioridad, responsable, categoría o notas de progreso. Esos campos pueden importar, pero mezclarlos en el estado hace que este sea poco fiable.

También ayuda separar “estado” de “etapa”. El estado es lo que es verdad ahora (por ejemplo, “bloqueado por respuesta del cliente”). La etapa es dónde está el elemento en tu proceso (por ejemplo, “revisión”). Puedes combinarlos, pero cuando un único estado intenta describir ambos, a menudo se vuelve vago.

Un estado útil debe desencadenar una de tres cosas:

• Un próximo responsable (quién lo recoge)
• Una próxima acción (qué ocurre después)
• Una condición de espera (qué se está esperando)

Una comprobación rápida: ¿puede alguien leer la etiqueta en una vista de lista pequeña y aún saber qué hacer después? Si la respuesta es “depende”, la etiqueta probablemente está ocultando una decisión que debería tomarse en otro lugar (como reglas de prioridad o asignación).

Cuántos estados usar y por qué 5–7 funciona

Un sistema de estados debe facilitar leer el trabajo de un vistazo. Demasiados estados y la gente deja de confiar en lo que ve. Muy pocos y pierdes el detalle necesario para gestionar las entregas.

Para la mayoría de equipos, 5–7 estados son el punto ideal. Caben en una sola pantalla, funcionan bien en un tablero Kanban o en una vista de lista simple, y dan suficiente señal para responder las preguntas diarias: qué está bloqueado, qué se está trabajando y qué espera revisión.

Mantener el conjunto pequeño también reduce la “caza de estado” (adivinar cuál de 12 opciones es la más cercana), facilita los informes y te obliga a mantener prioridad, responsable y tipo como campos separados.

Los nombres pueden variar, y está bien. Un equipo puede decir “En Progreso”, otro “Trabajando”. Lo que no puede variar es el significado. Si “En Revisión” a veces significa “esperando QA” y otras veces “esperando al cliente”, tu tablero se convierte en ruido.

Para mantener los significados consistentes, crea una sola fuente de la verdad: un documento corto del equipo con cada estado, qué significa y las reglas para entrar y salir de él. Léelo en dos minutos. Usa ese mismo conjunto en todos los lugares donde se muestre el trabajo.

Un conjunto simple de 7 estados con el que puedes empezar

Si quieres etiquetas de estado que sigan claras con el tiempo, empieza con un conjunto pequeño que responda tres preguntas: quién lo posee ahora, qué pasa después y qué significa “hecho”.

Aquí tienes un conjunto simple de 7 estados que funciona para la mayoría de equipos sin volverse demasiado detallado.

Regla clave: no uses “En espera” por sí solo. Si algo está atascado, llámalo Bloqueado y nombra la dependencia en la nota (por ejemplo, “Bloqueado: respuesta del cliente” o “Bloqueado: acceso concedido”).

Definiciones para cada estado (con reglas de entrada y salida)

Las etiquetas de estado funcionan mejor cuando cada una responde a una pregunta simple: ¿qué es verdad ahora?

Nuevo

Qué es verdad: el elemento se capturó, pero nadie lo ha evaluado.

Qué no es verdad: no se ha acordado prioridad, alcance ni responsable.

Entrada: se envía una solicitud.

Salida: alguien la lee y la mueve a Clasificado.

Ejemplo: “Un agente de soporte registra un informe de bug con una captura de pantalla.”

Clasificado

Qué es verdad: el equipo entiende la solicitud lo suficiente para enrutarlas y confirmar que es válida.

Qué no es verdad: está listo para comenzar.

Entrada: alguien añade contexto básico (resumen, impacto, área afectada).

Salida: se prepara para trabajo (Listo) o se rechaza intencionalmente (gestionado fuera del flujo, no como un estado).

Ejemplo: “El PM lo marca como un bug real y anota pasos para reproducirlo.”

Listo

Qué es verdad: se puede comenzar sin información faltante.

Qué no es verdad: no ha comenzado el trabajo.

Entrada: criterios de aceptación claros y dependencias resueltas.

Salida: una persona comienza el trabajo y realiza el primer cambio significativo (En Progreso).

Ejemplo: “Los campos de formulario y las reglas de validación están acordadas.”

En Progreso

Qué es verdad: se está realizando trabajo activo.

Qué no es verdad: está en una cola esperando.

Entrada: alguien lo toma y empieza a trabajar.

Salida: está lo bastante completo para revisarse (En Revisión) o se encuentra una dependencia (Bloqueado).

Ejemplo: “Un desarrollador crea el nuevo desplegable de estado y guarda la lógica.”

En Revisión

Qué es verdad: está siendo verificado (revisión entre pares, QA o aprobación de interesados).

Qué no es verdad: se están añadiendo nuevas funcionalidades.

Entrada: quien hizo el trabajo lo envía para verificación.

Salida: se aprueba y cumple la definición de terminado del equipo (Hecho), o vuelve con feedback (En Progreso).

Ejemplo: “QA confirma que funciona en web y móvil.”

Bloqueado

Qué es verdad: el trabajo no puede continuar por una dependencia específica y nombrada.

Qué no es verdad: el elemento simplemente tiene menor prioridad.

Entrada: el responsable se encuentra con una dependencia que no puede resolver solo.

Salida: la dependencia se elimina y el trabajo se reanuda (usualmente En Progreso).

Ejemplo: “Bloqueado: esperando acceso a logs de producción.”

Hecho

Qué es verdad: cumple los criterios de aceptación acordados y está desplegado o listo para desplegar.

Qué no es verdad: aún necesita revisión, pruebas o seguimiento.

Entrada: la revisión pasa y los pasos de release se completan (según la definición del equipo).

Salida: ninguno; reabrir inicia un nuevo ciclo con una razón clara.

Ejemplo: “La corrección está en producción y el bug ya no se reproduce.”

Paso a paso: crea tu sistema de estados en 60 minutos

Puedes arreglar estados desordenados en una reunión enfocada. El objetivo no es el modelo perfecto, sino un conjunto compartido de etiquetas que coincida con cómo se mueve el trabajo realmente, con reglas que el equipo pueda repetir.

Una sesión de trabajo de 60 minutos (con un resultado)

Lleva a una persona de cada rol que toque el trabajo (solicitante, ejecutor, revisor, aprobador). Comparte pantalla con tu tablero o lista actual.

Primero, mapea el flujo real (no el ideal). Elige un elemento típico y traza lo que realmente sucede, incluido el tiempo de espera. Escribe los pasos como verbos simples (“redactar”, “revisar”, “aprobar”). Si un paso ocurre solo a veces, márcalo como una bifurcación.

Luego, elimina duplicados y renombra etiquetas poco claras. Fusiona etiquetas que significan lo mismo (“En Progreso” vs “Trabajando”). Renombra las vagas (“Pendiente”) en algo accionable (“Bloqueado: respuesta de cliente”). Si no puedes explicar una etiqueta en una frase, no está lista.

Después añade definiciones con reglas de entrada y salida. Para cada estado, escribe qué debe ser verdad para entrar y qué debe ser verdad para salir. Manténlo corto. Ejemplo: “En Revisión entra cuando el trabajo se envía, sale cuando el feedback está resuelto y el revisor aprueba.”

Luego asigna responsables para cada entrega. Cada estado debe tener un responsable por defecto (un rol está bien). Esto evita que los elementos se atasquen. Ejemplo: los ítems en “En Revisión” son responsabilidad del revisor, no de quien hizo el trabajo.

Finalmente, prueba con 10 elementos recientes y ajusta. Toma 10 ítems terminados o activos de las últimas semanas y asigna a cada uno un estado en cada punto en el tiempo. Si discuten mucho, tus etiquetas se solapan. Si no puedes colocar un ítem, te falta un estado o estás mezclando dos ideas en una.

Después de la reunión, publica las definiciones en un solo lugar y haz que las etiquetas coincidan en todos los sitios donde la gente las vea.

Mantén los estados consistentes entre web y móvil

Si un estado significa una cosa en web y algo ligeramente distinto en móvil, la gente deja de confiar en él. Empiezan a preguntar en chat, volver a comprobar detalles o crear su propio “estado real” en los comentarios. El propósito de las etiquetas de estado es la verdad compartida, no la decoración.

Trata el estado como un campo compartido con una única fuente de la verdad. La misma etiqueta debe aparecer con la misma ortografía, mayúsculas y significado en todas partes: listas, pantallas de detalle, notificaciones, exportaciones y mensajes push.

Reglas para pantallas pequeñas que realmente funcionan

Las pantallas móviles penalizan nombres largos y un diseño visual débil. Una etiqueta que se ve bien en una tabla de escritorio puede convertirse en una chapa confusa y truncada en un teléfono.

• Mantén nombres cortos (1–2 palabras cuando sea posible).
• Usa colores consistentes, pero nunca dependas solo del color.
• Diseña pensando en la etiqueta más larga para que nada se trunque en fragmentos ilegibles.
• Mantén el orden consistente entre plataformas.
• Evita etiquetas “casi iguales” como “En Progreso” vs “Trabajando”. Elige una.

La colocación importa también. Pon el estado cerca del título en la vista de detalle para que se vea antes de leer la descripción completa. En las vistas de lista, muéstralo en la misma posición siempre.

Las bases de accesibilidad ayudan a todos. El color es una pista, no el mensaje. Muestra siempre la etiqueta en texto y considera un icono simple (por ejemplo, una marca para Hecho) para que las personas que usan lectores de pantalla o tienen problemas de visión de color obtengan el significado rápidamente.

Errores comunes que hacen que los estados se desvíen

Los estados se desvían cuando dejan de significar “dónde está el trabajo” y empiezan a significar “cómo se siente la gente respecto al trabajo”. Cuando eso ocurre, tu tablero parece activo, pero nadie confía en él.

Una causa común es tener demasiadas etiquetas que coinciden con cada pequeño paso. Si una tarea puede moverse tres veces en una hora, la gente deja de actualizarla o elige un estado “lo más cercano”. Un conjunto pequeño funciona mejor cuando cada movimiento es un cambio real en preparación o responsabilidad.

Otro punto de deriva es mezclar dimensiones diferentes en un mismo campo. Prioridad y urgencia importan, pero pertenecen a campos separados, no al estado. Si “Urgente” es un estado, competirá con “En Revisión” y tus informes perderán sentido.

Cuidado con estos patrones:

• Múltiples etiquetas “casi hecho” sin diferencia clara
• Etiquetas personales de un solo uso (“Esperando a Sam”)
• “En Progreso” convirtiéndose en un aparcamiento
• No tener reglas escritas de entrada y salida
• Nuevas pantallas mostrando nombres u orden distinto de estados

Para prevenir la deriva, asigna un dueño del conjunto de estados y haz que los cambios sean raros. Cuando cambies algo, escribe qué cambió, por qué y qué reemplaza.

Ejemplo: una solicitud desde el inicio hasta Hecho

Un cliente escribe al soporte: “En móvil, la página de historial de pedidos aparece vacía aunque tenga pedidos.” Soporte registra un ítem que se convertirá en una corrección de producto y luego en un release.

Nuevo: Soporte captura capturas, detalles del dispositivo y cómo debería verse lo correcto.

Clasificado: El Product Owner confirma que es un bug real, elige dónde pertenece (app móvil, no backend) y aclara el impacto.

Listo: Se confirman los pasos para reproducir y los criterios de aceptación están claros.

En Progreso: Un ingeniero reproduce el problema, descubre que la API devuelve datos pero la pantalla los filtra mal, y comienza la corrección.

Bloqueado: El ingeniero descubre que la UI depende de un campo que falta en cuentas antiguas y necesita un cambio en backend. El ítem se marca Bloqueado con una nota clara: “Bloqueado: backend necesita mapeo de campo legacy.”

En Revisión: Tras resolver la dependencia, QA verifica iOS y Android y confirma que el estado vacío sólo aparece cuando realmente no hay pedidos.

Hecho: La corrección se aprueba y se lanza (o se programa para la próxima ventana de release, si ese es el criterio del equipo). Soporte confirma que está en producción y responde al cliente.

Fíjate en lo que evita la confusión: “Bloqueado” tiene una sola razón y una sola acción siguiente, y la propiedad no salta. Cualquiera puede abrir el ítem y entender quién tiene la pelota.

Lista rápida para mantener al equipo consistente

Si tu tablero se siente desordenado, normalmente puedes detectar la causa en 10 minutos.

Escaneo del tablero en 10 minutos

Revisa el tablero y busca estas señales:

• Cada estado responde: “¿Qué es verdad ahora?”
• Cada estado tiene un responsable por defecto (un rol está bien) y una acción siguiente clara
• No hay dos estados que puedan describir el mismo ítem al mismo tiempo
• Los ítems no están aparcados sin punto de decisión (si puede quedarse días, añade una regla de salida)
• Los mismos tipos de trabajo pasan por los mismos pasos básicos, salvo excepciones documentadas

Si la gente discute dónde cae una tarjeta, ese estado se solapa con otro o no está suficientemente definido.

Comprobación de consistencia web + móvil

Abre el mismo flujo en un teléfono y confirma que las etiquetas siguen funcionando en espacios reducidos.

• Las etiquetas son cortas y legibles en vistas de lista (sin truncado)
• El texto es claro sin depender del color
• Los cambios de estado los aprueba un responsable (líder de equipo u ops), no se decide por persona
• Los cambios vienen con una nota breve para que las definiciones no deriven

Próximos pasos: mantener, medir y mejorar con el tiempo

Los sistemas de estado siguen siendo útiles cuando los tratas como un reglamento: estables, pero revisados. El objetivo no es cambiar constantemente; es el uso consistente.

Establece una cadencia ligera, por ejemplo una revisión mensual de 30 minutos con una persona de cada rol que toque el tablero. Lleva 5–10 ítems recientes y busca excepciones que puedas corregir.

Algunas señales sencillas que vale la pena seguir:

• Tiempo pasado en Bloqueado (y la razón principal)
• Ítems que rebotan entre dos estados
• Ítems que permanecen sin tocar más allá del tiempo ciclo normal

Cuando algo se siente raro, resiste la tentación de añadir un nuevo estado de inmediato. Añade un estado solo cuando el nuevo estado sea realmente diferente, cambie lo que la gente hace después y ocurra con frecuencia. La mayoría de las veces la solución es más simple: afinar la definición, añadir una regla de entrada o aclarar la propiedad.

Si estás construyendo el flujo en una herramienta interna, trata los estados como datos compartidos en lugar de texto específico de pantalla. En AppMaster (appmaster.io), por ejemplo, puedes definir el campo de estado una vez en el Data Designer y reutilizarlo en apps web y nativas, lo que ayuda a prevenir la deriva de “significa algo distinto en mi teléfono”.