Estoy seguro de que has vivido esta escena. Entras a revisar con detalle las herramientas de gestión que tienes con tus equipos. Ya sabes, cada cierto tiempo conviene hacer un chequeo a fondo para asegurarte de que está todo bien.
Te encuentras con que, nada de lo que habías dejado, ahora funciona. Eso sí, tienes horas consumidas por proyecto perfectamente registradas pero ni una sola de ellas se ha marcado como completado desde hace semanas.
La pregunta que te haces es «¿Cómo se puede perder visibilidad tan pronto si llevabas meses midiéndolo?»
Tener datos no es tener visibilidad
Esta pregunta está muy mal planteada. Realmente no has perdido visibilidad: nunca la has tenido. Solo has tenido un campo que se actualizaba porque insistías en que había que completarlo y, como el equipo lo hace, pues crees que tienes un proceso.
Ten en cuenta que si el estado de una tarea solo cambia cuando preguntas, no tienes un sistema de seguimiento. Tienes a una persona —tú— haciendo de motor manual de un proceso que aparenta ser automático y no lo es.
Las señales que hablan
Existen señales que indican que tú eres el motor del proceso.
- En los datos, los campos de estado se mueven justo después de que preguntas, nunca antes: las fechas de «última actualización» coinciden con tus mensajes, no con el trabajo real, y hay más horas registradas que tareas cerradas mes tras mes.
- En el equipo, nadie escala un bloqueo si no se lo preguntas directamente — la respuesta a «¿cómo vais?» es siempre «bien», sin matices ni fricción visible.
- En tu propia gestión dejas de bajar más a detalle porque «siempre está bien». Ya sabes no news, good news.
Por qué pasa esto
Un campo de estado de «tarea completada» en una herramienta no crea gobierno por sí solo. Crea la posibilidad de gobierno. Lo que lo convierte en real es que exista una razón para mantenerlo actualizado que no seas tú preguntando a cada paso.
Si la única razón que mueve la actualización es tu insistencia, en el momento en que dejas de insistir, el dato se congela. Las horas, en cambio, se siguen registrando porque están atadas a algo con consecuencia real: la nómina, la facturación. Nadie tiene que recordarle a nadie que registre sus horas.
El coste real de esta situación no es el desgaste de coordinación – que también. Es lo que decides tarde. Cuando detectas que el dato no sirve, ya llevas semanas o meses gestionando a ciegas, y recuperar visibilidad real cuesta más que haberla mantenido desde el principio. Ese tiempo lo empleas en auditar manualmente lo que el equipo debería haberte dicho solo, en vez de emplearlo en decidir.
Y cada vez que un dashboard demuestra que no sirve, la organización aprende —con razón— a no fiarse de los datos, y vuelve a depender del micromanagement: la misma dependencia que ese dashboard debía eliminar.
Cómo saber si tu visibilidad es real o no
Para comprobar que los datos que estás usando son reales y están actualizados puedes comprobarlo con estas acciones:
- ¿El porcentaje de tareas completadas se mueve en semanas donde no preguntas nada? Si no se mueve, no hay proceso.
- ¿Hay tareas con fecha de última actualización de más de cinco días laborables? Si las hay, el dato está muerto y nadie te lo ha dicho.
- ¿Existe alguna consecuencia —positiva o negativa— ligada a mantener el estado actualizado, distinta de que tú lo reclames? Si no la hay, no hay incentivo.
- ¿Puedes explicar el avance real de un proyecto mirando solo la herramienta, sin preguntar a nadie? Si no puedes, no tienes indicador. Tienes ilusión de indicador.
Qué hacer con esto
Tu posición real es bastante sencilla: tienes un dato fiable de las horas que se han consumido, pero no tienes un dato fiable de cuánto se ha avanzado. El campo de «completado» solo se actualiza cuando tú preguntas por él.
Y aquí creo que es fácil echarle la culpa a la disciplina del equipo, pero probablemente el problema está en otro punto. Si registrar las horas en el parte de trabajo sí tiene consecuencias claras y no actualizar el estado de las tareas no, ¿para qué se va a dedicar tiempo en esto?
Piénsalo.
Ahora mismo tienes dos opciones.
- Puedes seguir preguntando cada día, pero entonces el sistema depende de ti y vuelves al mismo problema.
- Puedes cambiar el proceso para que mantener el estado actualizado sea necesario para avanzar: cerrar un sprint, pasar un hito, liberar una fase…
Pero antes de hacer ese cambio, yo probaría algo mucho más sencillo.
Deja de preguntar.
Elige un proyecto y un campo concreto y durante dos semanas no reclames que lo actualicen. Simplemente observa qué ocurre. Si el dato sigue moviéndose, quizá el problema no era tan grave. Si se queda parado, ya tienes una evidencia bastante clara: ese indicador funciona mientras tú estás detrás de él.
Y entonces sí tiene sentido sentarse a rediseñar el proceso. No antes. Porque el objetivo no es conseguir que el equipo marque más casillas. Es saber si, cuando tú dejas de empujar, el sistema sigue funcionando por sí solo.
Cómo no volver a caer en esto
Antes de retirarte de cualquier seguimiento:
- Comprueba primero si el dato sobrevive sin tu presión: no asumas autonomía, verifícala.
- Ata cada campo de seguimiento crítico a una consecuencia operativa real, no a la buena voluntad de quien lo rellena.
- Y distingue siempre indicadores de esfuerzo, como las horas, de indicadores de resultado, como tareas cerradas o hitos: si solo tienes el primero, no tienes gobierno, tienes facturación.
Si quieres saber cómo diseñar bien esos rituales de seguimiento antes de que te pase esto, lo trato en un artículo aparte
Te propongo para esta semana que:
- Elige un proyecto y un campo de estado concreto. Deja de preguntarlo durante dos semanas.
- Mira si alguien lo actualiza sin que insistas. Apunta la fecha del último cambio real.
- Si no se mueve, no rediseñes el proceso todavía. Primero decide qué consecuencia operativa vas a atar a ese dato.
Si dejaras de preguntar mañana, ¿crees que se seguiría actualizando el estado de cada proyecto?