Descubrimiento de proyectos de software

El descubrimiento de proyectos de software es la fase estructurada de definición de alcance que precede al compromiso de desarrollo. Su trabajo no consiste en celebrar una reunión de inicio ni en listar requisitos sin fricción. Su trabajo es eliminar las fuentes principales de fallo en delivery: requisitos ambiguos, incógnitas técnicas sin resolver, complejidad de integración subestimada y expectativas desalineadas entre alcance, coste y plazo.

La distinción importa porque la mayor parte de los problemas de alcance son, en el fondo, fallos de descubrimiento. Cuando un proyecto entra en delivery con supuestos sin desafiar, integraciones sin validar o restricciones mal entendidas, la expansión de alcance y la deriva de arquitectura dejan de ser accidentes y pasan a ser un resultado probable.

Qué es realmente el descubrimiento de proyectos de software

El descubrimiento es una investigación estructurada cuyo objetivo explícito es producir decisiones validadas, no una simple lista de requisitos. Una lista de requisitos refleja lo que alguien cree hoy que debería construirse. Las decisiones validadas reflejan lo que se ha examinado, cuestionado y confirmado con restricciones y alternativas a la vista.

Una prueba práctica es sencilla: si nada cambió respecto a las hipótesis iniciales, no hubo descubrimiento real. Un buen descubrimiento modifica el alcance, cambia el enfoque de arquitectura, revela riesgos de integración que al principio no eran visibles o identifica restricciones que alteran la forma del delivery.

El descubrimiento debe estar acotado en tiempo y en entregables para mantener disciplina comercial. Un proceso abierto indefinidamente genera coste abierto y retrasa el inicio de desarrollo. Si no puede producir sus entregables dentro del tiempo previsto, probablemente el alcance del proyecto necesita revisarse antes de comprometer delivery.

Qué ocurre cuando se omite el descubrimiento

Omitir el descubrimiento no elimina el trabajo de definición: lo empuja hacia la fase de delivery, donde cuesta más y causa más daño. Ese patrón se repite en distintos tipos de proyecto.

Expansión de alcance a mitad de delivery. Los requisitos que no se investigaron en la fase de alcance aparecen durante el desarrollo. Cada requisito descubierto tarde amplía presupuesto y plazo, comprime la calidad de lo ya comprometido o activa procesos de change request que tensan la relación con el cliente.

Fallos de integración. Sistemas de terceros, plataformas internas, pipelines de datos y capas de autenticación suelen tener restricciones que no se ven en la documentación: rate limits, inconsistencias de esquema, comportamientos no documentados o tiempos de provisión de acceso. Discovery es el mecanismo para sacar eso a la superficie.

Deriva de arquitectura. Las decisiones arquitectónicas tomadas con presión de calendario y sin investigación previa suelen requerir revisión profunda cuando aparece el conjunto real de restricciones. Esa revisión a mitad de delivery es costosa técnica y comercialmente.

Expectativas desalineadas. Sin discovery, cliente y equipo de delivery suelen operar con supuestos implícitos distintos sobre límites de alcance, niveles de calidad y contingencias de plazo. Discovery obliga a hacer visibles esos supuestos y deja una base documentada para gobernar el trabajo.

Normalmente el fallo no aparece el día en que se decide omitir discovery. Suele hacerse visible meses después, cuando se incumplen hitos tempranos o la negociación de alcance se vuelve inevitable.

Actividades centrales del descubrimiento

El descubrimiento no es una única actividad, sino una secuencia de investigación con salidas concretas.

Challenge de requisitos. Los requisitos iniciales no se revisan para validarlos sin más, sino para cuestionarlos. ¿Son restricciones reales o asumidas? ¿Describen una necesidad o una solución propuesta? ¿Qué cambia si se aplazan, relajan o abordan de otra forma?

Technical spikes. Las incógnitas técnicas específicas se investigan mediante trabajo acotado y time-boxed. Un spike sobre una API de terceros entrega conocimiento real sobre endpoints, autenticación, rate limits y tratamiento de errores. Un spike de rendimiento aporta líneas base medidas, no conjeturas.

Architecture Decision Records o ADRs. Las decisiones relevantes de arquitectura se registran con contexto, opciones consideradas, razones y consecuencias. Los ADRs preservan memoria institucional, ayudan al onboarding y dejan trazabilidad para explicar por qué el sistema se construyó así.

Mapeo de restricciones. Infraestructura, seguridad, cumplimiento, presupuesto, límites de plazo y dependencias de integración se documentan de forma explícita. Hacer visible ese entorno de decisión evita que las prioridades de restricción diverjan en silencio durante el delivery.

Entregables del descubrimiento y puertas de decisión

El descubrimiento produce entregables concretos que gobiernan la fase de desarrollo. Su calidad y completitud distinguen un proyecto bien gobernado de uno que depende de alineación informal.

Scope statement. Un documento que deja claro qué está dentro y fuera del compromiso de delivery y bajo qué criterios algo pasa a considerarse cambio de alcance.

Architecture Decision Records. El conjunto de decisiones técnicas relevantes tomadas durante el descubrimiento, especialmente cuando había varias opciones viables o el razonamiento no será obvio al leer la implementación final.

Inventario de integraciones. Lista documentada de sistemas de terceros, plataformas internas y dependencias externas con su enfoque de integración, complejidad estimada, restricciones conocidas y estado de provisión de accesos.

Estimación por rangos. Una estimación que refleje la incertidumbre real restante después del descubrimiento, expresada como rango con niveles de confianza y con las condiciones necesarias para sostener el extremo más optimista.

Criterios de go o no-go. Condiciones explícitas para avanzar tal como está definido, para recomendar rescoping o para no iniciar todavía el proyecto. Hacer esto antes del desarrollo protege a ambas partes del coste de descubrir demasiado tarde que el compromiso no estaba bien fundado.

Cómo ejecuta Logic Grid Studio el descubrimiento

La revisión de alcance de Logic Grid Studio es un proceso de descubrimiento acotado en tiempo y en entregables, diseñado para producir los artefactos anteriores con disciplina comercial. Los outputs pertenecen al cliente y siguen siendo utilizables aunque el desarrollo continúe con otro partner.

Una revisión de alcance es adecuada para nuevos proyectos por encima de cierto umbral de novedad o complejidad de integración, para segundas fases con cambio material de alcance y para organizaciones que necesitan decidir si su código o infraestructura actual son una base sana para seguir invirtiendo.

Los outputs de una revisión de alcance son el prerrequisito de una propuesta de desarrollo. Logic Grid Studio no plantea propuestas de delivery sin estar ancladas en esos resultados, porque una propuesta sin descubrimiento es una propuesta sin conocimiento.