Cómo definir mejor un problema

«Necesitamos una aplicación» parece una tarea clara. Alguien puede estimar el desarrollo, elegir la tecnología y empezar a dibujar pantallas. Sigue sin conocerse el problema que la aplicación debe resolver.

Definir un problema exige describir la distancia entre lo que ocurre y lo que debe ocurrir. La solución puede venir después. Empezar por una organiza la investigación alrededor de justificar una elección ya hecha.

Considera una empresa ficticia que recibe pedidos por mensajes y pierde parte de la información antes de preparar las entregas. Su primera propuesta es sustituir los mensajes por una aplicación. Eso podría ayudar. También podría trasladar la comprobación a los clientes sin corregir el fallo que causa las pérdidas.

Describe un incidente antes de nombrar el problema

Elige un caso reciente y sigue lo que ocurrió. ¿Quién recibió el pedido? ¿Dónde registró los artículos? ¿Cuándo dejó de estar disponible la información? ¿Cómo detectó el equipo que faltaba?

«Hay desorganización» es una valoración. «El pedido se remitió sin dirección y el equipo tuvo que buscar la conversación original» describe un incidente. La segunda frase permite localizar una etapa del proceso y examinar otros pedidos que siguieron el mismo recorrido.

Busca también entregas correctas. Las diferencias entre casos pueden revelar algo que la descripción general oculta: un formulario que algunas personas usaban, una comprobación realizada en un turno o un mensaje reenviado solo en parte.

Evita convertir el primer caso en explicación de todos. Te ofrece un punto de partida para observar con más precisión.

Separa el suceso de la hipótesis

La ausencia de la dirección es observable. La idea de que faltaba porque las personas estaban distraídas es una hipótesis. La idea de que una aplicación resolvería esa ausencia es otra.

Cada hipótesis requiere una comprobación diferente. Si el sistema exige buscar la dirección entre varios mensajes, las personas atentas quizá necesiten el mismo esfuerzo. Si la dirección ya consta en un registro accesible, el problema puede estar en el traspaso entre quien recibe el pedido y quien lo prepara.

Esta distinción ayuda a evitar acusaciones prematuras. «El equipo no se comunica» puede convertirse en una exigencia vaga. Identificar que nadie sabe quién debe comprobar los datos permite discutir una responsabilidad concreta.

Registra las interpretaciones como posibilidades en lugar de incorporarlas a la descripción inicial. Así la investigación podrá contradecirlas sin que parezca negar un hecho.

Define el resultado que importa

Resolver la dificultad no exige necesariamente eliminar los mensajes o poner todas las tareas en una plataforma. El resultado deseado podría ser que el equipo reciba la información necesaria para cada entrega sin volver a la conversación original.

Esa formulación admite soluciones diferentes. Un campo obligatorio, una confirmación antes de reenviar o un proceso separado para pedidos incompletos pueden ser opciones. Compara sus resultados, el esfuerzo de usarlas y el coste de mantenerlas.

Pregunta quién debe experimentar la mejora. Una herramienta puede facilitar la administración y dificultar los pedidos para los clientes. Definir solo una métrica interna deja esa consecuencia fuera.

Fija también un límite. «Mejorar toda la operación» puede incluir cualquier tarea y dificulta saber si la intervención funciona. Empezar por un tipo de pedido o una etapa hace más manejable la investigación.

Comprueba las condiciones antes de elegir

¿Qué impide que la empresa resuelva esto hoy? Quizá el volumen de pedidos sea demasiado bajo para justificar un sistema propio. Quizá nadie haya configurado una herramienta que ya paga. Quizá el equipo no pueda solicitar todos los detalles en el primer contacto porque parte de la información depende de una conversación posterior.

Estas condiciones afectan a qué soluciones son viables. Descubrirlas pronto evita comparar una alternativa sencilla pero insuficiente con una solución ideal que no encaja en el contexto.

Una formulación provisional podría ser: «En este tipo de pedido, los datos de entrega llegan incompletos al equipo responsable. Necesitamos identificar dónde se pierden y probar una forma de recibirlos completos que mantenga la facilidad de hacer pedidos».

Esto identifica el comportamiento, el grupo de casos y el resultado deseado, y deja abiertas las causas. Las nuevas observaciones pueden ampliar la investigación sin reiniciar la conversación.

Revisa la formulación después de investigar

La descripción inicial puede cambiar. Si se perdieron datos completos durante la copia manual, el foco pasa de la recogida al traspaso. Si los pedidos llegan a personas distintas y no existe una cola compartida, el problema puede ser seguir su estado.

Reformular forma parte del trabajo. Registra qué provocó el cambio para distinguir un descubrimiento de un giro arbitrario de prioridades.

Usa la ficha de investigación de problemas para un caso atascado. Describe un incidente, anota una explicación rival y elige una observación que permita distinguirlas. Después compara soluciones para el problema que realmente encontraste.