La prioridad es el impacto, no el cargo

La pregunta más difícil de responder en una empresa pequeña no es cuánto se gasta. Es dónde se fue el día.

Todo el mundo trabajó. Nadie paró. Y aun así, al final del mes, no existe una frase que explique qué se hizo — solo la sensación de que se corrió bastante.

Eso no es falta de esfuerzo, y casi nunca es falta de gente. Es que el trabajo entró por lugares que no guardan registro: el mensaje al móvil, el "solo una cosita rápida" en el pasillo, el pedido hecho en la puerta del despacho. Cada uno es pequeño. Juntos, son el día entero.

El pedido que no deja registro

Un pedido que no se anota en ninguna parte tiene una propiedad curiosa: para la empresa, no ocurrió.

Nadie sabe cuántos hubo, cuánto tiempo consumieron, ni cuántas veces volvió el mismo problema. Quien lo atendió lo sabe, y nadie más.

Y hay un efecto que nadie anticipa: quien atiende bien se convierte en el más interrumpido. No porque alguien lo decidiera, sino porque el camino más corto para resolver algo es ir a hablar con esa persona. La recompensa por ser eficiente es que te interrumpan más veces.

Una entrada única no es burocracia

La corrección es más simple de lo que parece, y cabe en una frase: todo pedido entra por un solo lugar. Un portal de tickets, una bandeja de entrada, lo que sea — la herramienta importa poco.

Lo que suele frenar este cambio es leerlo como burocracia. No lo es:

El propósito real de la disciplina: gobierno sobre el tiempo de la empresa. El portal no es burocracia — es el instrumento que hace visible dónde se invierte el tiempo de TI, y por lo tanto gobernable.

Fíjate en lo que cambia: no pasas a controlar a las personas. Pasas a ver adónde se fue el tiempo, que es una información que hoy sencillamente no existe en la empresa.

La regla que incomoda al principio

Con la fila montada, aparece la pregunta que obliga a responder: ¿quién va primero?

Regla de oro: la prioridad se define por el impacto en el negocio, no por el cargo de quien pide. Lo que llega por fuera lo registra quien atiende — sin excepción.

Esa es la parte que exige una decisión del dueño, y no del equipo técnico. Sin ella, la fila se vuelve un adorno: sigue existiendo, pero quien grita más fuerte — o tiene el cargo más alto — sigue pasando delante, y la persona que atiende queda en medio de una disputa que no es suya.

Y vale fijarse en el final de la regla, que es la mitad más fácil de olvidar: lo que llega por fuera no se rechaza, se registra. Nadie tiene que decirle que no al dueño. Solo tiene que anotarlo antes de resolverlo.

Tres tipos, y por qué la diferencia importa

Vale separar lo que entra en tres, por su relación con lo que ya existe:

Un proyecto es algo nuevo, que todavía no existe. Un incidente es algo ya entregado que presentó un problema. Una solicitud es un ajuste o mejora sobre algo ya entregado.

Parece clasificación de manual, y es lo más revelador de la lista. Sin ella, todo es "demanda", y un equipo que pasó el mes entero apagando incendios parece un equipo ocupado y productivo. Con ella, queda visible que nadie construyó nada — y eso cambia lo que se decide el mes siguiente.

El número que solo aparece después

Cuando los pedidos pasan a registrarse y separarse, surge gratis un número que el dueño entiende sin traducción: la proporción entre incendio y construcción.

Cuánto del mes fue arreglar lo que se rompió, y cuánto fue construir lo que aún no existía. Es la medida de salud más honesta que tiene una operación de tecnología, y no pide ninguna herramienta nueva — pide que los pedidos existan por escrito.

La prueba

Piensa en el mes pasado, y responde sin consultar a nadie:

¿Cuánto del tiempo de tu equipo fue apagar incendios, y cuánto fue construir?

Si la respuesta es una estimación, no es que la operación esté mal. Es que todavía es invisible — y una operación invisible no mejora a propósito. Mejora por suerte.