Cómo descubrir necesidades antes de definir soluciones

Cuando se nos presenta un proyecto, una de las primeras cosas que intentamos averiguar es algo aparentemente sencillo:

¿Qué necesita realmente el cliente, usuario?

La respuesta, rara vez es tan evidente como parece.

Los usuarios y clientes suelen describir problemas, expresan preferencias y expectativas, o proponen soluciones concretas, pero eso no siempre significa que estén definiendo con claridad la necesidad que existe detrás. Sin duda, una de las dificultades más habituales en cualquier proyecto consiste precisamente en interpretar correctamente lo que las personas necesitan o esperan conseguir.

Por eso, descubrir requisitos no suele ser un ejercicio de recopilación de información, sino un proceso continuo de conversación y validación.

1. Las historias de usuario: una forma más realista de descubrir necesidades

Cualquiera que haya trabajado en proyectos sabe que al inicio las cosas no están tan claras como nos gustaría: los usuarios y clientes cambian de opinión, aparecen nuevas necesidades, algunas dejan de tener sentido y otras, que parecían secundarias, terminan siendo críticas para el negocio.

Esas necesidades se entienden mejor a medida que el equipo empieza a trabajar, recibe feedback y contrasta sus primeras ideas con lo que va aprendiendo…y aquí es donde entran en juego las historias de usuario.

Las historias de usuario nacieron en los años noventa dentro de Extreme Programming (XP), una de las primeras metodologías ágiles de desarrollo de software. Su propuesta era sencilla: en lugar de intentar capturar desde el principio todos los requisitos en extensos documentos, proponían descripciones breves que sirviesen como punto de partida para conversar con el cliente o usuario sobre sus necesidades reales.

1.1 Las 3 C’s detrás de una buena historia de usuario

La verdadera utilidad de una historia no está únicamente en el texto, sino en las conversaciones que provoca dentro del equipo. Mike Cohn, autor de varios libros clave sobre métodos ágiles, popularizó el concepto de las 3 C’s para explicar precisamente esta idea:

Y aquí aparece una idea importante: una buena historia no pretende eliminar la conversación, sino precisamente provocarla.

1.2 La historia es solo el comienzo de la conversación

Hoy compramos productos y servicios por Internet casi sin pensarlo. Entramos en Amazon o en cualquier tienda online y damos por hecho que podremos guardar productos en un carrito, recuperar una compra más tarde, recibir avisos de cambios de precio, elegir la forma de pago o seleccionar distintas opciones de envío.

Son funcionalidades tan habituales que probablemente abandonaríamos una tienda online si no estuvieran disponibles. Sin embargo, no siempre estuvieron tan claras. Alguien tuvo que descubrir qué necesitaban realmente los usuarios y cómo podían facilitarles el proceso de compra.

Las historias de usuario ayudan precisamente a plantear ese tipo de conversaciones desde la perspectiva de quien utilizará el producto.

Por ejemplo:

Como cliente, quiero guardar productos en mi carrito para finalizar la compra más tarde.

A partir de ahí empieza la conversación real.

¿Cuánto tiempo debe mantenerse el carrito? ¿Se mantienen los productos si el usuario continúa la compra desde otro dispositivo? ¿Qué ocurre si cambia el precio de un producto?…

Muchas de estas cuestiones no aparecen hasta que negocio, usuarios y equipo empiezan a hablar sobre la necesidad que existe detrás de la solicitud inicial.

Después llegan los criterios de aceptación:

• El carrito debe conservarse aunque el usuario cierre sesión.
• Los productos agotados deben notificarse.
• El usuario debe poder eliminar productos fácilmente.

La historia inicial no pretende definir todos los detalles desde el principio. Su función es abrir una conversación que ayude al equipo a comprender mejor la necesidad, definir qué aporta valor y crear una solución útil para el usuario.

1.3 Cómo saber si una historia está bien escrita: el modelo INVEST

Una vez que el equipo empieza a trabajar con historias de usuario, aparece otra dificultad bastante habitual: no todas las historias están igual de bien definidas. Algunas son demasiado grandes. Otras generan dependencias imposibles de gestionar. Y en muchos casos, la historia parece clara… hasta que alguien intenta desarrollarla y descubre que cada persona había entendido algo diferente.

Precisamente para evitar este tipo de problemas, en Agile suele utilizarse el modelo INVEST, una forma sencilla de comprobar si una historia de usuario realmente está preparada para entrar en desarrollo.

El nombre viene de las iniciales de seis características que ayudan a evaluar la calidad de una historia:

1.4 Cuándo una historia está realmente terminada

Un problema muy habitual en los proyectos es creer que algo está “terminado” cuando, en realidad, todavía existen dudas, errores o expectativas diferentes sobre lo que significa «terminado».

Esto genera una falsa sensación de avance. Las tareas aparentemente progresan “sobre el papel”, pero parte del trabajo sigue sin cumplir los criterios necesarios para considerarse realmente finalizado. Y ese trabajo incompleto termina aflorando cerca de las fechas de entrega.

Por eso los equipos ágiles necesitan acordar de forma explícita qué significa realmente que algo esté hecho.

La Definition of Done, DoD, (Definición de hecho) es un acuerdo compartido dentro del equipo que define qué condiciones debe cumplir una historia de usuario para considerarse realmente terminada, de forma que todos trabajen con los mismos criterios, evitando ambigüedades sobre el estado real del trabajo.

Además, obliga al equipo a trabajar con una mentalidad mucho más orientada a entregar valor real, no simplemente a “mover tareas” dentro de una herramienta.

1.4.1 Qué gana realmente un equipo al utilizar una Definition of Done

1. Evita malentendidos dentro del equipo.
2. Reduce sorpresas de última hora. Muchas tareas parecen acabadas …hasta que aparecen incidencias o revisiones pendientes.
3. Mejora la calidad de las entregas. El equipo trabaja con unos mínimos de calidad compartidos.
4. Genera más confianza con clientes y usuarios. Cuando el equipo dice que algo está terminado, realmente lo está.

2. Descubrir requisitos es mucho más difícil que documentarlos

Aunque parezca contradictorio, muchos proyectos fracasan porque construyen exactamente lo que se pidió, pero no lo que realmente se necesitaba.

De hecho, hay una situación bastante habitual en muchos proyectos, conocida como IKIWISI (I’ll Know It When I See It): los usuarios no siempre saben describir con precisión la solución que necesitan, pero reconocen rápidamente cuándo una propuesta no encaja con sus expectativas. En la práctica, les resulta más fácil identificar lo que no quieren que explicar exactamente lo que quieren.

A diferencia de las historias de usuario, que describen una necesidad desde la perspectiva del usuario, los prototipos y los wireframes permiten visualizar una idea antes de desarrollarla por completo.

• Los wireframes muestran la estructura básica de una pantalla, organizando la información y los elementos principales.
• Los prototipos, por su parte, permiten probar cómo se comportará la solución, simulando la navegación o la interacción antes de construir el producto final.

Aunque no son lo mismo, cumplen una función similar: hacer visible una posible solución para poder comentarla y validarla antes de desarrollarla. Ambos ayudan a convertir requisitos abstractos en algo más concreto y a comprobar si encaja con lo que los clientes y usuarios esperan.

2.1 Los prototipos ayudan a conversar mejor

Los usuarios reaccionan mejor ante algo que pueden ver que ante una lista de requisitos.

3. Conclusión

Comprender una necesidad suele ser mucho más difícil que documentarla. Los usuarios no siempre expresan con claridad lo que necesitan y, en muchos casos, las primeras soluciones que imaginamos no son las que más valor aportan.

Por eso herramientas como las historias de usuario, los criterios de aceptación, los prototipos o los wireframes siguen siendo tan útiles. No porque permitan definir requisitos perfectos desde el principio, sino porque ayudan a contrastar ideas, detectar malentendidos y construir una visión compartida de lo que realmente se necesita.

Al final, definir soluciones suele ser la parte sencilla. Lo verdaderamente difícil es descubrir qué necesidad hay detrás de ellas. Y precisamente por eso resulta tan importante descubrir necesidades antes de definir soluciones.

---