El enunciado del problema es todo el proyecto: cómo redactarlo

Un buen enunciado del problema dice a quién afecta, qué le ocurre, cuándo y dónde sucede y por qué importa, en dos o tres frases sencillas y sin ninguna solución escondida dentro. Se escribe a partir de evidencias, no de opiniones; deja claro qué queda fuera del alcance y se pone a prueba con personas ajenas al equipo antes de generar una sola idea. Si se acierta aquí, cada paso posterior, de las ideas a los prototipos y al business case, tiene un suelo firme sobre el que apoyarse.

Por qué el enunciado decide el proyecto

Los equipos rara vez fracasan por no encontrar ideas. Fracasan porque resolvieron un problema que nadie tenía, resolvieron la parte equivocada de un problema real o pasaron semanas discutiendo porque cada persona estaba resolviendo, en silencio, uno distinto. El enunciado del problema es donde esos fracasos empiezan o se cortan.

Tres razones explican que pese tanto. Marca el límite de lo que cuenta como una buena idea. Indica con quién hablar y qué medir. Y es la frase que la dirección recordará, así que condiciona si el trabajo recibe apoyo. Un enunciado vago no se queda vago: lo acaba rellenando quien tenga más autoridad en la sala.

Las cinco partes de un enunciado útil

Un enunciado con el que se puede trabajar responde a cinco preguntas:

1. ¿A quién afecta? A un grupo concreto, no a "los usuarios" ni a "los stakeholders". "Solicitantes primerizos con la documentación incompleta" es un quién. "Clientes" no lo es.
2. ¿Qué les ocurre? La situación observable, en sus propios términos. Algo que se pueda ver o contar.
3. ¿Cuándo y dónde sucede? El momento o el canal. A menudo es ahí donde se esconde el verdadero insight.
4. Por qué importa, a ellos y a la organización. El coste de no hacer nada: tiempo, dinero, confianza, riesgo.
5. Qué sabemos y cómo lo sabemos. Una línea sobre la evidencia: entrevistas, datos de reclamaciones, observación. Esto mantiene honesto el enunciado.

Muchos equipos añaden una sexta línea igual de útil: qué no es el problema. El análisis "es / no es" de Kepner-Tregoe es una forma clásica de hacerlo. Señalar, por ejemplo, que el fallo se da en las solicitudes en línea pero no en las oficinas acota la búsqueda de inmediato.

Cómo redactarlo, paso a paso

1. Escribir un primer borrador rápido y sin miedo a que salga mal. Cada persona escribe su propia versión del problema en una frase, en silencio, en tres minutos. Se ponen una junto a otra. Las diferencias entre ellas son el primer hallazgo: muestran dónde el equipo todavía no está de acuerdo.
2. Eliminar las soluciones. Subrayar cualquier palabra que describa un arreglo: "app", "portal", "formación", "falta de un sistema". "Nos falta un sistema de reservas" es una solución disfrazada. Reescribir cada una como la situación que vive la gente: "Los clientes no pueden saber de antemano si hay una franja libre".
3. Preguntar por qué y, después, qué lo impide. Usar Los cinco porqués (5 porqués) o un Árbol de problemas para pasar del síntoma a la causa. Parar al llegar a un nivel sobre el que el equipo pueda actuar de verdad. Si se baja demasiado, se termina en "la economía"; si se queda en la superficie, solo se tratan síntomas. Para un tratamiento completo, ver cómo encontrar la causa raíz de un problema.
4. Ir a comprobarlo. Llevar el borrador a cinco o seis personas que viven el problema. Recurrir a Entrevistas a partes interesadas (stakeholders) y pedirles que describan la última vez que ocurrió, no lo que piensan en general. Si su relato no encaja con el enunciado, se cambia el enunciado.
5. Completar las cinco partes. Reescribir con el quién, el qué, el cuándo y dónde, por qué importa y qué se sabe. Tres frases como máximo. Si hacen falta más, probablemente hay dos problemas.
6. Fijar los límites. Añadir una línea sobre lo que queda fuera del alcance y otra sobre las restricciones que hay que respetar, como la normativa, el ciclo presupuestario o un sistema que no se puede cambiar este año.
7. Convertirlo en un punto de vista. Un Enunciado de punto de vista (point of view), el formato usuario–necesidad–insight que enseña la d.school de Stanford, condensa el problema en una sola frase humana: "[Quién] necesita [necesidad] porque [insight]".
8. Abrirlo en forma de preguntas. Solo ahora se escriben Preguntas ¿Cómo podríamos? (How Might We) a partir del enunciado. Para ver ejemplos buenos y malos, ver 10 preguntas "¿cómo podríamos?": cinco buenas y cinco malas.
9. Probarlo con alguien de fuera. Leérselo a alguien de otro departamento y pedirle que repita cuál es el problema y quién lo tiene. Si no puede, todavía no está listo.

Antes y después

Qué hacer y qué evitar

Qué hacer

• Escribir el enunciado en el lenguaje de las personas afectadas, no en la jerga interna.
• Basarlo en algo que se haya observado o escuchado, y decir qué.
• Mantenerlo lo bastante corto como para decirlo en voz alta en veinte segundos.
• Revisarlo abiertamente cuando llegue nueva evidencia y conservar las versiones anteriores para que el equipo vea cómo ha cambiado su comprensión.
• Usar el Mapa de supuestos (assumption mapping) para listar lo que todavía se cree pero no se ha comprobado.

Qué evitar

• Que el enunciado contenga una solución, una tecnología o el nombre de un departamento como causa.
• Redactarlo en una reunión sin evidencias y darlo por definitivo.
• Hacerlo tan amplio que cualquier idea encaje, o tan estrecho que solo encaje una.
• Usar "falta de" como verbo principal. Casi siempre esconde una solución.
• Saltarse la línea de "por qué importa". Sin ella, el trabajo perderá apoyo en la primera revisión presupuestaria.

Ejemplo ilustrativo

Ilustrativo. Un ayuntamiento de Australia pidió a su equipo de servicio "construir un portal en línea para las licencias de obra". El primer borrador del equipo repetía el encargo. En lugar de empezar a construir, dos personas del equipo pasaron una semana en la ventanilla de licencias y hablaron con ocho solicitantes y cuatro técnicos evaluadores.

Lo que escucharon fue distinto. La mayoría de las solicitudes ya se presentaban en línea. El retraso llegaba después: muchas de las solicitudes que revisaron habían sido devueltas por falta de información, y los solicitantes no entendían las cartas de requerimiento. Los técnicos dedicaban buena parte del día a llamadas telefónicas para explicarlas.

El enunciado reescrito decía: "Los propietarios que solicitan licencias para obras menores presentan a menudo solicitudes incompletas porque los requisitos están repartidos en varios documentos y las cartas de requerimiento usan lenguaje técnico. Cada devolución añade semanas al proceso y llena el tiempo de los técnicos con llamadas de explicación. Esto se aplica a obras residenciales menores, no a promociones comerciales".

Las ideas que siguieron fueron más baratas y rápidas que un portal: una lista de comprobación de una página por tipo de obra, cartas de requerimiento en lenguaje claro y una breve llamada previa a la presentación. La idea del portal no se descartó; simplemente dejó de ser el punto de partida.

Preguntas frecuentes

¿Cuál es un buen ejemplo de enunciado del problema? Uno bueno nombra un grupo concreto, describe qué le ocurre y cuándo, dice por qué importa y no contiene ninguna solución. Por ejemplo: "Las enfermeras del turno de noche pierden información del relevo porque las notas se escriben en tres sitios distintos, lo que obliga a repetir comprobaciones al inicio de cada turno".

¿Qué extensión debe tener un enunciado del problema? Dos o tres frases, más una línea sobre el alcance. Si hace falta una página entera, o se están describiendo varios problemas o se está incluyendo la solución. Los enunciados breves son más fáciles de probar, recordar y compartir con la dirección.

¿Qué diferencia hay entre un enunciado del problema y una pregunta "¿cómo podríamos?"? El enunciado describe la situación tal como es, a partir de la evidencia. Una pregunta "¿cómo podríamos?" la convierte en una invitación abierta a generar ideas. Primero se escribe el enunciado y después se derivan de él varias preguntas, cada una desde un ángulo distinto.

Por dónde seguir

Trabajar las guías del Árbol de problemas y de Los cinco porqués (5 porqués) para dar con la causa, condensarla después con un Enunciado de punto de vista (point of view) y abrirla con las Preguntas ¿Cómo podríamos? (How Might We). Para ver dónde encaja este paso en el proceso completo, leer design thinking, paso a paso y la guía central qué herramienta de innovación usar.