Fase de descubrimiento: por qué conviene antes de construir software

Porque una fase de descubrimiento cuesta una fracción del proyecto y te evita pagar por construir lo equivocado: aclara procesos, prioridades y alcance antes de escribir la primera línea de código.

Casi todos los sobrecostos de un software se originan antes del desarrollo: en lo que no se preguntó, en lo que se supuso y en lo que nadie dejó por escrito. El levantamiento de requisitos, que aquí llamamos fase de descubrimiento o diagnóstico, existe para sacar esas sorpresas a la luz cuando todavía son baratas. En esta guía te explicamos qué incluye, qué entregables deberías recibir, cuánto suele costar y cómo saber si tu proyecto lo necesita.

Qué es una fase de descubrimiento y en qué se diferencia de una cotización

Una cotización responde “cuánto cuesta lo que pediste”. Un descubrimiento responde una pregunta anterior: “qué es lo que de verdad necesitas construir”. La diferencia parece sutil, pero cambia el resultado del proyecto.

En TBA Digitals el primer paso siempre es un diagnóstico gratuito de 30 minutos, que termina en una propuesta con alcance, precio y cronograma por escrito. Para un sitio web o una integración acotada, esa conversación suele ser suficiente. Para un software a la medida con varios módulos, conviene que el levantamiento de requisitos sea más profundo y que forme parte explícita del plan de trabajo.

Lo que cuesta saltarse el levantamiento de requisitos

Las cifras de la industria apuntan en la misma dirección. En un informe de 2014, el Project Management Institute (PMI) encontró que casi la mitad (47 %) de los proyectos que no cumplen sus objetivos fallan por una gestión deficiente de los requisitos. Y un estudio de 2012 de McKinsey con la Universidad de Oxford, que analizó más de 5.400 proyectos de tecnología, encontró que los proyectos grandes se exceden en promedio 45 % en presupuesto y entregan 56 % menos valor del previsto.

Tu proyecto seguramente es mucho más pequeño que los del estudio, pero el mecanismo es el mismo: requisitos que cambian a mitad de camino, decisiones que nadie documentó y poca comunicación sobre los cambios de alcance.

¿Por qué duele tanto? Porque el costo de cambiar algo crece a medida que avanza el proyecto. Nielsen Norman Group cita una estimación muy difundida según la cual es 100 veces más barato hacer un cambio antes de escribir código que después de implementarlo. Mover un botón en un prototipo toma minutos; cambiar la estructura de la base de datos con el sistema en producción implica migraciones, pruebas y riesgo.

Qué incluye un buen levantamiento de requisitos de software

Entrevistas con quienes operan, no solo con la gerencia

La gerencia sabe qué resultado quiere; quien opera sabe dónde se rompe el proceso. Un buen levantamiento habla con ambos: el vendedor, la persona de bodega, quien hace el cierre de caja y quien factura. Las excepciones del día a día casi nunca aparecen en la reunión con el gerente.

Mapa del proceso actual y del proceso deseado

Primero se documenta cómo se trabaja hoy, con sus atajos y sus hojas de cálculo. Luego se diseña cómo debería funcionar con el software. La diferencia entre los dos mapas es, literalmente, el alcance del proyecto.

Inventario de datos y sistemas

Dónde viven hoy los datos (Excel, un ERP, el software contable, WhatsApp), quién los alimenta y con qué calidad. Aquí aparecen las integraciones: facturación electrónica, pasarelas de pago, CRM. Cada una tiene un costo y conviene conocerlo antes de firmar. Si tu proyecto depende de conectar varias herramientas, revisa cómo trabajamos las integraciones entre sistemas.

Requisitos funcionales y no funcionales

Los funcionales describen lo que el sistema hace: crear un pedido, aplicar un descuento, generar un reporte. Los no funcionales describen cómo debe hacerlo: cuántos usuarios simultáneos, desde qué dispositivos, qué nivel de seguridad, qué datos personales se tratan y qué tiempo de respuesta es aceptable. Los segundos se olvidan con frecuencia y son los que más sorprenden en la factura.

Priorización

No todo cabe en la primera versión. Un método simple es clasificar cada requisito en “debe tener”, “debería tener”, “podría tener” y “no tendrá por ahora”. Lo que queda en “debe tener” define la primera entrega; si tu producto es nuevo, esa entrega se parece mucho a un MVP para validar la idea.

Prototipo navegable

Pantallas clicables, sin base de datos, que tu equipo puede recorrer y criticar. Es la forma más barata de descubrir que un flujo no funciona como lo imaginabas, y de alinear a todos antes de invertir en desarrollo.

Alcance cerrado con criterios de aceptación

Cada funcionalidad queda descrita con una condición verificable de “terminado”. Por ejemplo: “al confirmar una venta, el inventario del producto se descuenta y queda registrado quién hizo el movimiento”. Sin criterios de aceptación, “terminado” significa cosas distintas para ti y para el proveedor.

Entregables que deberías recibir

• Mapa del proceso actual y del proceso deseado.
• Lista de requisitos priorizada, con lo que entra y lo que no entra en la primera versión.
• Historias de usuario o casos de uso con criterios de aceptación.
• Prototipo navegable de los flujos principales.
• Modelo de datos preliminar: qué entidades existen y cómo se relacionan.
• Mapa de integraciones, con sus supuestos y riesgos.
• Plan por fases con cronograma y presupuesto por fase.
• Lista explícita de exclusiones.

El último punto es el más subestimado. Una lista de lo que no incluye el proyecto evita más discusiones que cualquier cláusula. Antes de firmar, revisa también qué debe incluir un contrato de desarrollo de software. Y un detalle clave: los entregables del descubrimiento deben quedar en tus manos. Si decides construir con otro proveedor, deberías poder llevártelos.

Un ejemplo real: del cierre de caja a mano a un POS con ocho módulos

Culto Orquídeas es un vivero de orquídeas que operaba con hojas de cálculo y cierres de caja reconstruidos a mano. Cuando el punto de partida es ese, el mapeo del proceso deja claro lo que el sistema debe resolver: que cada venta quede registrada en el momento, que el inventario se descuente solo, que cada movimiento tenga un responsable y que las ventas se puedan comparar con el año anterior sin armar informes a mano.

El sistema POS e inventario a la medida que construimos responde a esos puntos con ocho módulos, entre ellos punto de venta con descuentos y órdenes en borrador, inventario con alertas de stock bajo e historial auditable, análisis de ventas contra el año anterior, órdenes, clientes y descuentos. Todo funciona con acceso autenticado, en una aplicación propia sin CMS en su subdominio. Ninguno de esos módulos es un capricho técnico: cada uno corresponde a un paso del proceso que antes se hacía a mano.

Si tu operación se parece, te puede servir la comparación entre un POS a la medida y un POS genérico, o la guía sobre cuándo la hoja de cálculo se vuelve un riesgo.

Cuánto cuesta y cuánto dura un diagnóstico

Depende del tamaño del proyecto. Para un sitio web o una integración acotada, una buena conversación inicial y algunas preguntas por escrito suelen bastar. Para un software con varios módulos, roles e integraciones, el levantamiento de requisitos se mide en sesiones de trabajo y entregables, no en una sola reunión.

En TBA Digitals el diagnóstico inicial de 30 minutos no tiene costo. Como referencia de lo que viene después, una aplicación web a la medida parte desde $2.400.000, y el valor final depende del alcance que se defina. Puedes revisar los valores de partida en nuestra página de precios.

Una regla útil para evaluar cualquier propuesta: si un proveedor te da un precio cerrado por un software complejo sin preguntarte por tus procesos, tus datos y tus usuarios, ese precio no está basado en tu proyecto. Está basado en una suposición, y las suposiciones se cobran después en forma de “cambios de alcance”.

Señales de que tu proyecto necesita un descubrimiento más profundo

• Varias áreas usarán el sistema y cada una lo describe de forma distinta.
• Hay que conectar el software con otros sistemas: contabilidad, facturación electrónica, CRM o WhatsApp.
• El proceso actual vive en la cabeza de una o dos personas.
• Hay datos personales o información sensible de por medio.
• Las cotizaciones que recibiste varían muchísimo entre sí.
• No sabes con certeza qué debe ir en la primera versión.

Si marcaste dos o más, invertir en el levantamiento te va a ahorrar dinero. Y si lo que buscas es quitarte tareas repetitivas antes de pensar en un sistema completo, quizás la respuesta esté en automatizar procesos puntuales primero.

Cómo prepararte para sacarle el máximo al diagnóstico

1. Escribe el problema en una frase, sin mencionar la solución.
2. Reúne ejemplos reales: la hoja de cálculo, el formato impreso, los mensajes de WhatsApp con pedidos.
3. Identifica quién decide y quién usa, e invita a ambos.
4. Define qué sería un éxito medible en seis meses.
5. Ten un rango de presupuesto. No es para que te cobren el máximo; es para diseñar algo que quepa.

Si quieres una plantilla con las preguntas clave, revisa la guía para preparar un brief para cotizar una página web o un software.

Errores comunes en el levantamiento de requisitos

• Describir soluciones en lugar de problemas. “Quiero un botón que exporte a Excel” esconde la necesidad real: “necesito enviarle al contador las ventas del mes”.
• Copiar el proceso actual tal cual. Digitalizar una ineficiencia la hace más rápida, no mejor.
• Dejar los requisitos no funcionales para el final. Seguridad, rendimiento y permisos afectan la arquitectura desde el principio.
• No validar el prototipo con quienes van a usar el sistema. La aprobación de la gerencia no garantiza la adopción del equipo.
• Tratar el alcance como un documento muerto. Los cambios van a llegar; lo importante es que tengan un procedimiento y un costo claros.

Preguntas frecuentes

¿Qué es el levantamiento de requisitos de un software?

Es el trabajo de entender y documentar qué debe hacer el sistema antes de construirlo: procesos, usuarios, datos, integraciones y reglas de negocio. Su resultado es un alcance claro, priorizado y con criterios de aceptación. Sin ese documento, el proveedor cotiza sobre suposiciones y tú no tienes cómo verificar si lo entregado está completo.

¿Vale la pena el diagnóstico si al final no contrato el desarrollo?

Sí, siempre que los entregables queden en tus manos. Un mapa de procesos, una lista de requisitos priorizada y un prototipo te sirven para cotizar con cualquier proveedor en igualdad de condiciones. Además, a veces el diagnóstico revela que no necesitas un software nuevo, sino una automatización o una integración más pequeña.

¿Cuánto vale una hora de desarrollo de software en Colombia?

Varía según el perfil y el tipo de proveedor. En TBA Digitals la hora de desarrollo adicional se cotiza en el diagnóstico. Aun así, para un proyecto nuevo es mejor comparar propuestas por alcance cerrado y entregables, no por tarifa horaria, porque la tarifa sola no te dice cuántas horas va a necesitar cada proveedor.

¿El diagnóstico reemplaza el contrato?

No. El diagnóstico define qué se va a construir; el contrato define las reglas del juego: pagos, propiedad del código, garantía, soporte y manejo de cambios. Lo ideal es que el contrato haga referencia al documento de alcance que salió del descubrimiento, para que ambos tengan el mismo punto de comparación al final.

¿Qué pasa si los requisitos cambian durante el desarrollo?

Es normal que cambien, porque al ver el software funcionando aparecen ideas nuevas. Lo importante es tener un procedimiento: cada cambio se describe, se estima en tiempo y costo, y se aprueba por escrito antes de hacerlo. Así decides con información si entra ahora, en la siguiente fase o nunca.

Empieza por un diagnóstico, no por una cotización

Si estás pensando en construir un software y quieres saber qué debería incluir la primera versión, agenda un diagnóstico gratuito de 30 minutos. Revisamos tu proceso, identificamos riesgos e integraciones, y te entregamos una propuesta con alcance, precio y cronograma por escrito. También puedes escribirnos por WhatsApp y contarnos en qué punto está tu proyecto.