Saltar al contenido
Condictor Studio
Aplicaciones
Aplicaciones

Discovery de producto antes de crear una aplicación

Cómo definir problema, personas usuarias, alcance, riesgos y criterios de aceptación antes de crear una aplicación, y qué documento debe cerrar discovery.

Aprox. 5 min de lecturapor
Materiales de evidencia convergen en un marco de plano vacío y pasan por una puerta coral hasta un prototipo compacto verde menta

Discovery es la fase previa al desarrollo en la que se acuerdan problema, personas usuarias, efecto esperado, límites de alcance, riesgos y supuestos técnicos. El resultado debe ser un documento suficiente para comparar alternativas y preparar un presupuesto, con un alcance proporcional al tamaño del proyecto.

No garantiza un coste menor, pero reduce incertidumbre: revela expectativas contradictorias, ausencia de datos, integraciones difíciles o riesgo jurídico antes de que dependan de ellos muchas funciones terminadas.

Para qué sirve si ya sé qué quiero construir

Una descripción de idea puede entenderse de modo diferente por quien encarga, usa y desarrolla. Antes de la primera línea de código conviene comprobar tres desajustes:

  • De alcance. «Panel de administración» puede significar tres pantallas o treinta. Sin acordar qué entra en presupuesto, el conflicto es cuestión de tiempo.
  • De problema. Se quiere una aplicación para gestionar encargos, pero el problema real es que llegan por cinco canales y nadie los recoge. Una aplicación no resuelve un problema que no toca.
  • De persona usuaria. Quien compra y quien usa suelen ser personas distintas, con necesidades distintas. Una aplicación diseñada para quien compra puede no ser utilizada por el equipo.

Qué ocurre durante discovery

1. Objetivos de negocio, no lista de funciones

La primera pregunta no es «qué debe hacer la aplicación», sino «qué debe cambiar en la empresa si funciona». La respuesta sirve luego para descartar funciones: si no contribuyen a ese cambio, salen de la primera versión. Las buenas respuestas se pueden medir: reducir tiempo de gestión, dejar de transcribir datos entre sistemas o permitir a la clientela consultar sin llamar a la oficina.

2. Personas usuarias y sus tareas

Quién la utilizará, con qué frecuencia, en qué dispositivo y qué intenta lograr. La pregunta más útil es: ¿cómo se hace hoy? Aunque la respuesta sea una hoja de cálculo y tres correos, describe el proceso que hay que atender.

3. Proceso actual y proceso deseado

Se mapea el recorrido actual, los lugares donde se pierde algo y el recorrido objetivo. En cada paso preguntamos: «¿qué haces cuando los datos no encajan?» Esas respuestas describen el proceso real y a menudo determinan el coste.

4. Modelo de datos

Definimos los conceptos principales del dominio y sus relaciones, no todas las tablas «por si acaso». Comprobamos que el alcance no depende de definiciones contradictorias: cambiar relaciones básicas después puede exigir migraciones y actualizar muchas funciones.

5. Restricciones e integraciones

Sistemas que conectar, requisitos legales, datos personales, plazos externos y presupuesto. Una restricción puede cambiar de forma importante el presupuesto: por ejemplo, si un sistema no expone la interfaz necesaria o un contrato prohíbe cierta forma de tratar datos.

6. Alcance de la primera versión

Separa «debe existir para que funcione» de «sería bueno tener», justificando cada elemento. Para un producto con un recorrido clave, un referente puede ser MVP en 4–6 semanas.

7. Riesgos explícitos

Una lista de cosas que pueden salir mal con su impacto. Un proyecto sin riesgos anotados no es más seguro: simplemente los descubrirá tarde y con mayor coste.

Siete puntos dispuestos en arco, cuyas flechas convergen en un rectángulo de documento a la derecha; dos flechas salen del documento en direcciones opuestas
Siete pasos de taller convergen en un documento: ese documento, no los acuerdos verbales, es el producto del discovery.

Qué debe resultar

Un documento concreto, no notas de conversación. En nuestro caso incluye:

  • descripción del problema y objetivos medibles;
  • personas usuarias y tareas;
  • proceso objetivo;
  • modelo de datos y arquitectura;
  • alcance de primera versión y lista de elementos pospuestos conscientemente;
  • calendario por etapas y presupuesto;
  • riesgos con plan de respuesta.

El documento es tuyo y puedes ejecutarlo con nosotros o con otra empresa. Si encargas el desarrollo con nosotros, descontamos el importe de discovery del presupuesto del proyecto. Los pasos siguientes se describen en cómo crear una aplicación desde cero.

Cuánto cuesta y cuánto dura

Nuestras horquillas de agosto de 2026: taller discovery con documento de dirección 3.000–8.000 PLN netos; diseño y planificación completos con arquitectura, hoja de ruta y estimaciones 8.000–25.000 PLN netos. Depende de participantes, integraciones y materiales disponibles; normalmente va desde un taller hasta unas dos semanas.

Presupuestar un proyecto descrito en un párrafo contiene más supuestos y riesgo para ambos lados. Un alcance detallado permite señalar qué incluye el precio, qué datos debe aportar la clientela y qué provoca una nueva estimación. Discovery puede reducir el colchón de incertidumbre, pero también descubrir un requisito que eleve el precio honesto.

Cuándo no hace falta discovery

  • Cuando el alcance es realmente pequeño e inequívoco: una integración, una pantalla, un flujo.
  • Cuando ya tienes una buena especificación, especialmente si alguien técnico está de tu lado; entonces basta una revisión.
  • Cuando el problema es validar la idea, no delimitarla. Primero comprueba, incluso manualmente, si alguien lo quiere. Discovery sirve cuando se sabe que el problema es real.

Cómo prepararte

  1. Reúne ejemplos reales: encargos, documentos, correos y hojas que utilizáis.
  2. Invita a quien realiza el trabajo, no solo a quien lo encarga.
  3. Anota qué no se puede hacer hoy aunque debería poderse.
  4. Decide quién toma las decisiones de alcance. La ausencia de una persona con autoridad provoca pausas y acuerdos contradictorios.

Preguntas frecuentes

¿Se puede hacer discovery en remoto?

Sí; es como solemos hacerlo: taller online de 2–3 horas, trabajo por nuestra parte y después una ronda de preguntas complementarias.

¿Tenemos que encargaros el desarrollo después?

No. El documento es tuyo y no obliga a nada. Si continuamos, descontamos el importe del proyecto según las condiciones de la oferta.

¿En qué se diferencia de una auditoría de IA?

La auditoría de IA responde «dónde compensa IA en nuestra empresa». Discovery responde «qué construir exactamente y cómo». A veces la auditoría precede al discovery.


Llevamos proyectos propios por la secuencia discovery → brief → plan → implantación; así dirigimos también la renovación de este sitio. Consulta diseño y planificación o cuéntanos tu idea.

Maciej Szukalski

Autor

Maciej Szukalski

Fundador de Condictor · arquitecto de sistemas · investigación y desarrollo

Diseña y desarrolla productos digitales desde 2014. Se especializa en arquitectura, investigación y aplicaciones con capas de automatización e inteligencia.

¿Tienes un problema que resolver?

Veamos cuál es el mejor primer paso

Describe tu situación en unas frases. Volveremos con preguntas o una propuesta concreta para el siguiente paso.

Describe tu tema

Ver también

Todos los artículos