Consultoría

⏳ Cuando la ambigüedad se convierte en trabajo

«Explóralo» no es un criterio de aceptación. Cuando una petición sin resultado ni alcance se acepta como trabajo, la incertidumbre cambia de manos y la tarea se vuelve potencialmente infinita.

Hay un tipo de tarea que puede consumir tiempo casi sin límite. Llega por correo y suena razonable.

«¿Puedes explorar esto?» «Echa un vistazo a las opciones.» «¿Podrías desarrollar algo en esta línea?»

Al principio parece una petición normal. Empiezas a trabajar y descubres lo importante: no hay un resultado definido, ni alcance, ni criterios de aceptación. A veces ni siquiera hay un problema formulado.

Así que haces lo que haría cualquier profesional responsable: intentas crear la claridad que falta. Preguntas qué resultado se espera, identificas interpretaciones posibles, propones variables de alcance. Incluso planteas: ¿quieres A, B o C?

Y la respuesta vuelve: «explóralo».

Acaba de ocurrir algo que conviene nombrar. La incertidumbre se ha transferido de quien pide a quien ejecuta. Y como nada define cuándo la tarea está terminada, la tarea es potencialmente infinita.

El defecto se creó antes de empezar el trabajo

Desde la mejora de procesos, esto importa. El problema no es principalmente que alguien necesite gestionar mejor su tiempo. El defecto se produjo en la entrada: se permitió que una petición insuficientemente definida se convirtiera en trabajo comprometido.

Imagina el equivalente en una planta. Llega un componente a la siguiente operación y nadie sabe qué especificación debe cumplir, qué transformación hay que hacerle, qué aspecto tiene una salida aceptable ni cuándo hay que dejar de procesarlo.

Lo reconoceríamos de inmediato como un problema de calidad del proceso. En el trabajo de conocimiento aceptamos esa condición con normalidad, y luego pedimos a gente competente que la compense.

Quien recibe se convierte en el mecanismo de corrección

Una vez que el trabajo ambiguo entra en el sistema, alguien tiene que absorber la ambigüedad. Casi siempre es quien lo recibe.

Investiga, interpreta, supone, produce alternativas, manda correos de aclaración, prepara material preliminar y lo rehace después del primer comentario. La organización ve «trabajo en curso». Buena parte de esa actividad es retrabajo provocado por una entrada defectuosa.

Aquí es donde la inspección en la fuente de Shigeo Shingo resulta útil de verdad: no esperes a haber gastado diez horas para comprobar si el entregable cumple las expectativas. Inspecciona las condiciones necesarias para hacer el trabajo antes de empezarlo.

Los desperdicios que esconde una petición ambigua

Dicho así puede sonar abstracto. Traducido a los desperdicios clásicos del lean se vuelve concreto: una sola petición mal definida los activa casi todos a la vez.

DESPERDICIO	CÓMO APARECE CON UNA PETICIÓN AMBIGUA
Defectos	El entregable no era lo que se esperaba, y no por mala ejecución: nunca se definió qué era correcto
Retrabajo	Se rehace tras el primer comentario, que es cuando por fin aparece el criterio que faltaba al principio
Espera	La tarea queda parada esperando una aclaración que llega dos días después, y nadie contabiliza ese tiempo
Sobreproceso	Se preparan tres alternativas por si acaso, cuando con el criterio claro habría bastado una
Sobreproducción	Se investiga más de lo necesario porque no hay forma de saber qué es suficiente
Inventario	Tareas abiertas que nadie ha cerrado ni cancelado, acumuladas en la cabeza de quien las recibió
Movimiento	Idas y venidas de correos, hilos que se reabren, contexto que hay que recuperar cada vez
Talento no utilizado	Personas cualificadas dedicadas a adivinar intenciones en lugar de a resolver el problema

Conviene subrayar un detalle: ninguno de los ocho aparece en el informe de horas. Todos se registran, si acaso, como «trabajo».

«Explorar» no es un criterio de aceptación

La exploración puede ser trabajo perfectamente legítimo. Pero también necesita límites.

«Dedica hasta cuatro horas a identificar tres enfoques viables y entrega una comparación de una página» tiene propósito, tiempo, salida y condición de parada. «Explora posibles soluciones» no tiene ninguna de las cuatro.

Sin definición de terminado ocurre algo sutil: quien ejecuta pasa a ser responsable no solo de hacer el trabajo, sino de adivinar qué acabará considerando suficiente quien lo pidió. Si el cliente no sabe describir qué significa «bastante», el que trabaja no puede saber cuándo parar.

Si no puedo saber cuándo la tarea está terminada, la tarea todavía no está suficientemente definida.

La paradoja de ser servicial

De aquí sale una de las dinámicas más peligrosas para quien hace bien su trabajo: cuanto más concienzudo eres, peor se vuelve el problema.

Llega una petición vaga.
Lo compensas investigando más.
Como lo compensas, quien pidió no experimenta el coste de pedir así.
Como no lo experimenta, la siguiente petición llega igual.
Y vuelves a compensar.

Tu disposición a ayudar ha hecho sostenible un proceso de entrada defectuoso. Es la paradoja clásica: el heroísmo tapa los defectos del proceso, y quien mantiene el sistema en pie impide a la vez que la organización reciba la señal que necesitaría para mejorarlo.

Pedir aclaraciones también puede ser desperdicio

Hay un segundo punto contraintuitivo. «Pide aclaraciones» suena a solución obvia, pero la aclaración puede convertirse en un bucle: petición, aclaración, respuesta vaga, más aclaración, interpretación, más preguntas.

En algún momento, seguir preguntando deja de resolver el problema del proceso. Lo que hace falta es una puerta de calidad: el trabajo no empieza hasta que están presentes las condiciones mínimas para ejecutarlo. No es negarse a ayudar. Es trabajo estándar para aceptar trabajo.

¿Qué sería un poka-yoke aquí?

Antes de que una petición se convierta en trabajo activo, quien pide y quien ejecuta deberían poder responder a seis preguntas. No hace falta un formulario complicado: a veces bastan cinco minutos de conversación.

COMPROBACIÓN DE ENTRADA	PREGUNTA QUE HAY QUE PODER RESPONDER
1. Problema o necesidad	¿Qué problema, necesidad o pregunta queremos abordar?
2. Resultado esperado	¿Qué debería ser distinto, o existir, cuando el trabajo esté terminado?
3. Entregable	¿Qué produzco exactamente: recomendación, análisis, documento, opciones, reunión, prototipo?
4. Alcance	¿Qué está incluido y, cuando sea útil, qué queda explícitamente fuera?
5. Prioridad y plazo	¿Para cuándo se necesita y qué prioridad tiene frente a lo que ya tengo?
6. Definición de terminado	¿Qué nos permitiría a los dos decir que esta petición está completada?

Shingo clasificaba los poka-yoke por la forma en que detectan el error, y los tres tipos se traducen bien a la entrada de trabajo.

MÉTODO (SHINGO)	APLICADO A LA ENTRADA DE PETICIONES
Método de contacto	El canal solo acepta peticiones con los campos imprescindibles rellenos: lo incompleto no entra
Método de valor fijo	La exploración se acota a un número concreto de horas y de opciones; agotado el valor, se para y se revisa
Método de secuencia	Primero se encuadra el problema, después se desarrolla la solución; no se puede saltar el primer paso

Ninguno de los tres pide a nadie que se esfuerce más ni que recuerde mejor. Esa es la diferencia entre un poka-yoke y una norma: el primero también funciona los días con prisa.

Cuando la petición es exploratoria

A veces quien pide no puede responder a las seis, y es legítimo. Eso no impide empezar: significa que la exploración misma pasa a ser la tarea definida.

ELEMENTO	QUÉ HAY QUE FIJAR
Pregunta a explorar	¿Qué queremos entender?
Frontera	¿Qué áreas se investigan y cuáles no?
Tiempo acotado	¿Cuánto esfuerzo invertimos antes de parar y revisar?
Salida	¿Qué se produce con la exploración?
Punto de decisión	¿Qué pasa después?

En la práctica: «explora hasta cuatro horas si A o B resolverían el problema; entrega una página con hallazgos y una recomendación; después decidimos si se justifica seguir». Eso es otra cosa que «explora esto».

La regla, en cuatro pasos

Petición indefinida → aclarar.
Sigue indefinida → acotar la exploración en tiempo.
Exploración terminada → parar y decidir.
Hace falta más trabajo → nueva petición, esta vez definida.

El control importante es el punto de parada. Sin él, «explorar» se convierte en silencio en un compromiso ilimitado. La petición no necesita estar perfectamente definida: necesita estarlo lo suficiente para que quien trabaja sepa qué persigue y pueda reconocer cuándo debe detenerse.

Cuando el cliente de verdad no lo sabe

Esto merece cuidado. Alguien puede necesitar ayuda legítima para definir el problema, y eso también es trabajo de consultoría. Pero conviene reconocerlo como una tarea distinta.

En lugar de fingir que la petición es «desarrolla la solución», la primera tarea pasa a ser «define el problema y determina el alcance», con sus propios límites: una sesión de descubrimiento y una propuesta de enunciado del problema, alcance y opciones, para confirmar. Solo después empieza el desarrollo.

Separar el encuadre del problema de la ejecución de la solución evita, por sí solo, una cantidad enorme de desperdicio.

Y hay un problema de trabajo en curso

Una tarea ambigua se lleva. Cinco agotan. Porque el trabajo mal definido genera un trabajo en curso mental inusualmente alto.

Cada tarea queda abierta en la cabeza: ¿qué quiere en realidad?, ¿debería mirar esto?, ¿entraba aquello?, ¿hasta dónde llego?, ¿he terminado? Son decisiones sin resolver. La tarea no está delante de ti, pero una parte de tu atención sigue enganchada a ella.

Por eso la carga ambigua cansa de forma desproporcionada respecto al tiempo que ocupa. El problema no es la cantidad: es el inventario de bucles abiertos.

Poner un límite es mejorar el proceso

Una respuesta posible: «encantado de explorarlo. Antes de seguir necesito que fijemos el resultado buscado y una condición de parada. Con lo que entiendo ahora, propongo dedicar hasta cuatro horas a A y B y darte una recomendación breve; C quedaría fuera de alcance. Confírmame o dime qué cambiarías».

Fíjate en lo que ha pasado: no te has vuelto poco colaborativo, has introducido un control de proceso.

¿Y si la respuesta vuelve a ser simplemente «explóralo»? Queda otra salida: «entonces lo trato como tarea exploratoria y no como entregable definido. Lo acoto a cuatro horas y comparto lo que encuentre. Cualquier desarrollo posterior lo acordamos como tarea aparte». La incertidumbre deja de generar trabajo ilimitado porque el sistema ya tiene dónde parar.

Varias paradojas a la vez

Ser más servicial puede consolidar la mala calidad de las peticiones.
Más aclaraciones no producen necesariamente más claridad.
Empezar rápido puede hacer que se entregue más tarde.
Negarse a empezar trabajo indefinido puede mejorar el servicio al cliente.
Un límite puede aumentar la colaboración en lugar de reducirla.
Acotar la incertidumbre en el tiempo enseña más que intentar eliminarla del todo.

Y la más importante: quien recibe la petición no debería tener responsabilidad ilimitada sobre una ambigüedad creada aguas arriba.

De la culpa al proceso

Nada de esto exige culpar a quien pide. Las personas también operan dentro de un sistema: puede estar saturada, puede haber recibido a su vez una petición confusa, puede no saber de verdad qué necesita.

Precisamente por eso el proceso tiene que ayudar a los dos lados. Un buen mecanismo de entrada no dice «no has sabido explicarte». Dice: «antes de invertir capacidad, asegurémonos de que entendemos qué queremos conseguir». Es una relación completamente distinta.

La pregunta que yo pondría en el centro

Cuando llega una petición indefinida, la primera pregunta no es «¿cómo hago esto?». Es otra:

¿Qué tiene que ser verdad antes de que esto pueda convertirse en trabajo?

Esa es la pregunta de la inspección en la fuente. Porque en cuanto la ambigüedad entra como trabajo en curso, alguien tiene que cargar con ella. Y si el sistema pide una y otra vez a las personas concienzudas que carguen con ambigüedad ilimitada, al final no solo genera desperdicio: consume a quien lo está compensando.