Mapa de descubrimiento: qué definir antes de desarrollar software

¿Qué es un mapa de descubrimiento?

Un mapa de descubrimiento es una forma de ordenar el problema, las personas, el proceso, los datos y las prioridades antes de desarrollar una solución. Te ayuda a concretar qué necesitas resolver y qué debería incluir una primera versión de una página web, sistema, automatización o aplicación.

En esta guía usamos el nombre como una descripción práctica, no como un estándar universal, una metodología certificada o un producto con resultados garantizados. La etapa de descubrimiento, también llamada discovery, consiste en investigar y aclarar decisiones antes de construir; puede revelar que basta con mejorar un proceso o configurar una herramienta existente.

Empieza por el problema, no por la tecnología

“Quiero una app” o “quiero IA” describe una posible herramienta, pero todavía no explica el problema. Escribe qué ocurre hoy, qué debería ocurrir y quién necesita ese cambio. Distingue hechos observados de suposiciones que debes comprobar.

Por ejemplo, “necesitamos que cada solicitud tenga un responsable y un estado consultable” define una necesidad con más claridad que “necesitamos un sistema moderno”. Es un ejemplo conceptual, no un caso realizado por Finbalo.

• ¿Qué ocurre hoy y en qué momento aparece el problema?
• ¿Qué debería ocurrir para considerar resuelta la necesidad?
• ¿Dónde se pierde tiempo o información, según lo observado?
• ¿Quién se ve afectado y cómo puedes contrastar su experiencia?

Dibuja cómo funciona el proceso actualmente

Describe el recorrido real desde el inicio hasta el resultado final. Puedes usar una lista o un dibujo sencillo: quién recibe la información, qué hace después y a quién la entrega. Incluye las herramientas actuales, aunque sean correos, hojas de cálculo o archivos.

Marca las decisiones y excepciones: qué pasa si falta un dato, alguien rechaza una solicitud o el responsable no está disponible. Revisa el recorrido con las personas que lo ejecutan; el proceso escrito puede ser distinto de lo que sucede en la práctica.

• Inicio: qué evento pone en marcha el proceso.
• Participantes, pasos y herramientas utilizadas.
• Decisiones, condiciones y excepciones.
• Resultado final y persona que confirma que el trabajo terminó.

Identifica usuarios y responsabilidades

Define quién usará la solución, quién la administrará, quién aprobará cambios y quién solo necesita consultar información. Un cliente, una persona de operación y un administrador pueden necesitar accesos diferentes.

Para cada tarea, indica quién puede ver, crear, modificar, aprobar o eliminar información. Identifica también quién puede responder dudas del negocio y validar lo construido. No supongas que todas las personas necesitan los mismos permisos.

Define qué datos necesita la solución

Enumera los datos que entran, dónde están actualmente y quién los mantiene. Revisa archivos, registros duplicados, campos incompletos y diferencias de formato. Si habrá que trasladar información a la nueva solución, deja pendiente una revisión de su calidad y de cómo comprobar el traslado.

Anota qué herramientas deben intercambiar información y qué accesos existen. Define qué datos son necesarios para la tarea y quién puede consultarlos; evita usar datos personales reales en ejemplos de revisión cuando no hagan falta. Las condiciones de privacidad y acceso deben aclararse según la información y el contexto del proyecto.

Separa necesidades de funciones

La necesidad expresa el resultado que una persona busca; la función describe una forma de conseguirlo. Define primero el resultado y después evalúa qué funciones son necesarias. No todas las ideas de funciones tienen que entrar en la primera versión.

Ejemplo conceptual: la necesidad es “necesitamos saber en qué estado está cada solicitud”. Las posibles funciones son estados, responsables, historial y alertas. Antes de incluirlas todas, aclara quién necesita consultar el estado, cuándo y qué debe hacer con esa información.

• Necesidad: saber qué ocurre con una solicitud.
• Posibles funciones: estado visible, responsable e historial de cambios.
• Decisión pendiente: si una alerta es necesaria o si basta con consultar el estado.

Define una primera versión útil

La primera versión debe permitir completar el flujo principal con los datos y permisos necesarios. A veces se llama MVP, o producto mínimo viable: aquí significa un alcance inicial útil que puedas evaluar, no una entrega incompleta ni una garantía de éxito.

Clasifica las funciones por prioridad y escribe cómo comprobarás que el flujo funciona. Por ejemplo: una persona autorizada registra una solicitud, la asigna y consulta su estado. Indica también qué queda fuera; una lista de exclusiones evita que cada idea nueva se interprete como parte de lo acordado.

• Imprescindible: sin ello no puedes completar el flujo principal de forma adecuada.
• Importante: aporta valor, pero puedes evaluar una etapa posterior.
• Puede esperar: no es necesario para comprobar la utilidad inicial.

Identifica riesgos y dependencias antes de desarrollar

Una dependencia es algo que debe estar disponible para avanzar: datos, permisos, una decisión interna o un servicio externo. Un riesgo es una situación que podría dificultar el proyecto. Registra ambos, quién debe resolverlos y qué falta confirmar.

Si necesitas una API, es decir, una conexión que permite intercambiar información con otro sistema, comprueba que exista documentación y acceso autorizado. No des por hecha una integración solo porque un proveedor la menciona. Señala también las fechas externas que condicionan el lanzamiento, sin convertirlas en plazos prometidos de desarrollo.

• Acceso, condiciones y disponibilidad de APIs o proveedores externos.
• Datos sin ordenar y posibles migraciones.
• Permisos y aprobaciones pendientes.
• Responsables internos disponibles para resolver dudas y validar.
• Fechas externas y decisiones que condicionan el siguiente paso.

Qué debería salir de una etapa de descubrimiento

Debería quedar una base compartida para decidir qué construir, qué investigar todavía y cómo continuar. Las dudas no tienen que desaparecer: deben quedar identificadas para no tratarlas como requisitos confirmados.

La forma de registrar estas decisiones se acuerda con el proveedor. Esta lista es orientativa y no anuncia documentos, entregables oficiales ni servicios específicos de Finbalo.

• Problema claramente escrito y objetivo de la solución.
• Usuarios, responsabilidades y proceso actual.
• Funciones prioritarias y alcance inicial, con exclusiones.
• Datos necesarios e integraciones por confirmar.
• Riesgos, dependencias y dudas pendientes.
• Siguiente paso y quién debe tomar cada decisión.

Qué preparar antes de pedir una propuesta de software

Prepara un resumen del problema y ejemplos del proceso actual. No necesitas elegir un lenguaje de programación ni llegar con todas las respuestas: señala qué conoces y qué necesitas definir junto al proveedor.

Usa el siguiente checklist para iniciar la conversación. Esta guía se centra en definir el problema y el alcance; las guías relacionadas profundizan en digitalización, procesos automatizables y comparación de costos de software.

• Tipo de negocio, problema observado y resultado que buscas.
• Personas involucradas y responsable de validar decisiones.
• Pasos actuales, herramientas y ejemplos sin información sensible innecesaria.
• Datos disponibles, accesos e integraciones necesarias.
• Funciones imprescindibles, exclusiones y dudas pendientes.
• Fecha deseada, motivo de esa fecha y dependencias conocidas.