Planteo de la situación problemática

¿Qué es un problema?

Un problema es la distancia entre lo que pasa y lo que debería pasar. Ni más ni menos: hay una situación actual que no conforma y una situación deseada que todavía no existe. El trabajo del proyecto es cerrar esa distancia.

Definido así, un problema no es una queja ni una carencia abstracta: es una brecha concreta y verificable. "Los alumnos no aprenden programación" es una queja. "Los alumnos de 4.º año no pueden entregar los trabajos prácticos porque la sala de computación no tiene el software instalado" es un problema: se puede comprobar, tiene afectados concretos y admite una solución.

Un problema no es una solución disfrazada

Este es el malentendido más frecuente, y el que arruina proyectos antes de empezar. Frases como "el problema es que falta una app" o "el problema es que no hay una página web" no son problemas: son soluciones elegidas de antemano, disfrazadas de problema.

El riesgo de empezar así es concreto: si la solución elegida no era la adecuada, nunca se va a notar, porque nunca se miró el problema real. La app se construye, funciona, y el problema sigue ahí.

La forma de comprobarlo es simple: si la frase nombra una tecnología, no es un problema. Un problema se puede formular sin mencionar ninguna herramienta.

La situación problemática

Antes del problema formulado hay algo más difuso: la situación problemática. Es el contexto real, desordenado y lleno de detalles, donde aparecen las molestias. Es el punto de partida honesto de cualquier proyecto.

La diferencia entre las dos es de grado de elaboración:

Un ejemplo del recorrido completo:

1. La situación. En el taller de la escuela, las herramientas se guardan en un armario común. Varias veces por semana alguien necesita una herramienta y no la encuentra. Se pierde tiempo de clase buscándola, y algunas herramientas se han perdido directamente.
2. Lo que se observa. No hay registro de quién saca qué. El armario no está ordenado por tipo de herramienta. Nadie sabe con certeza qué hay adentro.
3. El problema formulado. Las herramientas del taller se pierden y se buscan sin éxito porque no hay ningún registro de quién las retira ni de qué hay disponible. Afecta a los alumnos y al profesor, y cada episodio cuesta entre cinco y quince minutos de clase.

Fijate que en el problema formulado todavía no se eligió ninguna solución. Podría resolverse con un sistema informático, con un pizarrón y una ficha de papel, o simplemente cambiando la forma de guardar. Decidir eso viene después, y con la información a la vista.

Cómo formular el problema

Formular bien el problema es la etapa más barata del proyecto y la que más ahorra. Un error acá se paga después, con creces: se construye algo que funciona pero que no resuelve nada.

Las preguntas que hay que responder

1. ¿Qué pasa exactamente? Hechos observables, no opiniones. "Se pierde tiempo buscando herramientas" es un hecho; "los alumnos son descuidados" es un juicio.
2. ¿A quiénes afecta? Personas concretas y cuántas. Un problema sin afectados identificados no se puede evaluar después.
3. ¿Con qué frecuencia y desde cuándo? "Todas las clases" es muy distinto de "una vez por mes".
4. ¿Qué se hace hoy para resolverlo? Casi siempre hay una solución precaria en marcha. Conocerla evita proponer algo que ya se intentó y falló.
5. ¿Por qué eso no alcanza? Es la pregunta que señala el hueco real.
6. ¿Cómo sabremos que se resolvió? La respuesta se convierte en los criterios de aceptación del proyecto.

Problemas bien y mal formulados

Necesidades y requisitos

Formulado el problema, el paso siguiente es traducirlo a algo que se pueda construir y verificar. Ahí aparecen tres conceptos que se confunden entre sí y conviene separar.

• Necesidad. Lo que hace falta desde el punto de vista de quien tiene el problema. "Necesitamos saber qué herramientas están disponibles."
• Requisito. Lo que la solución tiene que hacer para cubrir esa necesidad. Es una afirmación verificable: se puede comprobar si se cumplió o no. "El sistema debe mostrar una lista actualizada de las herramientas y quién las tiene."
• Criterio de aceptación. Cómo se comprueba ese requisito. "Al retirar una herramienta, la lista se actualiza en menos de un minuto."

Requisitos funcionales y no funcionales

Quiénes intervienen

Un problema nunca afecta a una sola persona, y cada una tiene una expectativa distinta sobre la solución. Identificarlas todas al principio evita conflictos que de otro modo aparecen al final, cuando ya no hay margen para cambiar nada.

La distinción entre usuario y cliente es la que más problemas causa. El cliente encarga y firma; el usuario trabaja todos los días con el resultado. Si solo se escucha al cliente, es muy probable terminar con un sistema que cumple el contrato y no lo usa nadie.

Resumen