Delivery sin discovery: cómo fabricar software inútil a gran velocidad

Hay una forma bastante elegante de perder dinero en tecnología: montar un equipo eficiente, llenarlo de herramientas, medir velocidad, cerrar tickets, desplegar con frecuencia y entregar exactamente lo que nadie necesitaba.

Lo peor es que desde fuera puede parecer un equipo ejemplar. Hay planificación, sprints, reuniones, roadmap, responsables, demos y una sensación constante de movimiento. Todo el mundo está ocupado. Todo el mundo tiene algo que hacer. Todo el mundo puede señalar una columna de Jira y decir: “esto avanza”.

Hasta que alguien pregunta lo único que importa de verdad:

“¿Esto está sirviendo para algo?”

Porque una cosa es entregar software y otra muy distinta es resolver un problema. Una cosa es tener capacidad de delivery y otra tener criterio de producto. Una cosa es construir rápido y otra construir algo que merezca existir. Y una cosa es cerrar tareas y otra generar impacto real.

El problema no suele ser que los equipos no trabajen. Muchas veces trabajan demasiado. El problema es que trabajan sobre decisiones tomadas demasiado pronto, con poco contexto, poca evidencia y una confianza absurda en que “ya lo iremos ajustando”.

A eso se le puede llamar de muchas formas, pero una bastante directa es esta: delivery sin discovery. Y es una de las maneras más rápidas de fabricar software inútil.

La fábrica funciona. Ese es el problema.

Cuando una fábrica de software funciona bien, produce. Produce pantallas, endpoints, informes, automatizaciones, integraciones, workflows, permisos, dashboards, formularios y documentación. Produce cosas visibles. Cosas que se pueden enseñar. Cosas que se pueden contar en una reunión de seguimiento.

Eso no es malo. El delivery es imprescindible. Sin delivery no hay producto, solo conversaciones eternas, decisiones aplazadas y documentos que envejecen mal en una carpeta compartida.

El problema empieza cuando el delivery se convierte en la forma principal de pensar. Cuando todo entra como tarea. Cuando toda necesidad se traduce demasiado rápido a una solución.

Cuando alguien pide “un dashboard” y el equipo pregunta por los filtros, los colores y la fecha de entrega, pero nadie pregunta qué decisión se supone que va a mejorar ese dashboard.

Cuando alguien pide “automatizar este Excel” y tecnología se pone a construir una aplicación, pero nadie revisa si el proceso que vive dentro del Excel tiene sentido o si simplemente estamos digitalizando un caos que antes al menos era visible.

Cuando alguien pide “un formulario para que negocio solicite cosas” y se construye el formulario, pero no se diseña cómo se va a entender la demanda, cómo se va a completar la información que falta, quién va a priorizar, quién va a revisar y qué se va a hacer cuando la petición no tenga ningún sentido.

Fíjate en el patrón, porque aquí está una de las primeras lecciones prácticas del artículo: el equipo no está tomando malas decisiones técnicas necesariamente. Está aceptando demasiado pronto que la solución ya está decidida.

Y cuando eso pasa, el equipo no está construyendo producto. Está procesando encargos.

Procesar encargos con eficiencia no te convierte en un gran equipo técnico. Te convierte en una cadena de montaje con acceso a producción.

Delivery y discovery, sin ceremonia ni incienso

Vamos a quitarle la capa de consultoría al asunto.

Delivery es la capacidad de construir, probar, desplegar y mantener una solución. Incluye desarrollo, arquitectura, QA, seguridad, despliegue, observabilidad, operación y soporte.

Discovery es la capacidad de entender qué problema merece ser resuelto, para quién, por qué, con qué impacto, con qué restricciones y con qué evidencia.

• Delivery pregunta: “¿Cómo lo construimos?”
• Discovery pregunta: “¿Esto tiene sentido construirlo?”

Delivery convierte una solución en realidad. Discovery evita que conviertas en realidad una mala solución.

Y esta diferencia, que parece muy obvia cuando se escribe, en la práctica se ignora constantemente. Porque el delivery se ve mejor. Tiene commits. Tiene releases. Tiene demos. Tiene capturas. Tiene movimiento. Tiene esa estética tranquilizadora de “estamos avanzando”.

El discovery, en cambio, incomoda. Obliga a preguntar. Obliga a decir “todavía no lo sabemos”. Obliga a reconocer que una petición no está madura. Obliga a discutir el problema antes de enamorarse de la solución. Obliga, en definitiva, a pensar antes de producir.

Y en muchas empresas pensar antes de producir se interpreta como ir lento, y espero que sea OBVIO que, desde luego, NO lo es.

La idea que conviene llevarse aquí es sencilla: discovery no es lo contrario de delivery. Discovery es lo que evita que el delivery se convierta en una máquina muy cara de materializar malentendidos.

El primer error: tratar una petición como si fuera un problema

La mayoría de desastres empiezan con una frase aparentemente inocente:

“Necesitamos un dashboard.”

O una app. O una automatización. O una integración. O una alerta. O un botón. O una exportación a Excel. Da igual. La forma cambia, pero el patrón es el mismo: alguien llega con una solución en la mano y el equipo técnico la convierte en tarea demasiado pronto.

Pero una petición no es un problema, es una interpretación temprana de una posible solución. A veces será correcta. Muchas veces no.

Cuando negocio pide un dashboard, quizá el problema real es que no detecta a tiempo qué pedidos están bloqueados. Cuando pide una automatización, quizá el problema real es que el proceso tiene demasiadas excepciones manuales. Cuando pide una app, quizá el problema real es que varias áreas trabajan con criterios distintos. Cuando pide exportar a Excel, quizá el problema real es que no confía en la herramienta actual. Cuando pide un formulario, quizá el problema real es que no existe un canal claro para convertir una necesidad en trabajo técnico entendible.

Si aceptas la petición como si fuera el problema, ya has perdido una parte importante del trabajo.

No porque negocio sea torpe. No va de eso. Negocio conoce su dolor mejor que nadie, pero no siempre sabe traducirlo a producto técnico. Igual que tecnología conoce la solución técnica, pero no siempre entiende el contexto operativo completo.

Por eso hace falta discovery.

Aquí hay una práctica muy útil: cuando alguien llegue con una solución, no la rechaces por sistema, pero tampoco la conviertas automáticamente en ticket. Baja un nivel. Pregunta qué está pasando hoy, quién lo sufre, cuánto cuesta, qué se está intentando evitar y qué debería cambiar si lo hacemos bien.

Ese movimiento parece pequeño, pero cambia completamente la conversación. Ya no estás discutiendo una pantalla. Estás entendiendo una necesidad.

Lo que está pasando ahora mismo

Este tema no es una manía de producto ni una frase bonita para poner en LinkedIn.

En 2026 el problema se ha vuelto más importante porque producir software es cada vez más fácil, pero decidir bien qué software merece existir sigue siendo igual de difícil. Incluso más, porque ahora la maquinaria puede generar más actividad, más código y más cambios antes de que nadie haya entendido del todo el problema.

CircleCI publicó su informe 2026 State of Software Delivery a partir de 28.738.317 workflows ejecutados en septiembre de 2025. Su lectura es bastante clara: los equipos están escribiendo mucho más código, pero menos cambios llegan realmente a producción. En su resumen lo dicen sin demasiadas vueltas: la IA está acelerando el desarrollo, pero también está dejando al descubierto un cuello de botella creciente en validación, integración y recuperación. En el artículo asociado al informe añaden otro dato importante: el número medio de workflows diarios aumentó un 59% interanual, el mayor incremento que han observado. La actividad sube. La capacidad de convertir esa actividad en software entregado y fiable no sube al mismo ritmo.

DORA, el programa de investigación de Google Cloud sobre rendimiento de entrega de software, también insiste en una idea que conviene recordar cada vez que alguien quiere medir solo velocidad: el rendimiento no se entiende con una única métrica. En su guía actualizada el 5 de enero de 2026, DORA agrupa sus cinco métricas en dos grandes bloques: throughput e inestabilidad. No basta con mirar si desplegamos más o si tardamos menos. También hay que mirar lead time, frecuencia de despliegue, tiempo de recuperación ante fallos, ratio de cambios fallidos y retrabajo de despliegue.

Traducido a lenguaje menos académico: correr más no sirve de mucho si rompes más, rehaces más o necesitas más esfuerzo para sostener lo que acabas de entregar.

Y desde producto el diagnóstico tampoco invita precisamente a relajarse. Atlassian, en su State of Product 2026, encuestó a más de 1.000 profesionales de producto en Estados Unidos y Europa. El 84% de los equipos de producto afirma que le preocupa que sus productos actuales no tengan éxito en el mercado. El 80% no involucra a ingeniería de forma temprana, lo que genera oportunidades perdidas y sorpresas de última hora. Y solo el 60% experimenta de forma regular; el otro 40% experimenta poco o nada.

Ese 80% debería doler bastante.

Porque si ingeniería entra tarde, entra cuando el problema ya ha sido empaquetado como solución. Entra para estimar, construir, discutir dependencias, detectar imposibilidades y apagar fuegos que probablemente se podían haber visto antes.

Luego lo llamamos retrabajo. Pero muchas veces no es retrabajo. Es discovery hecho tarde.

La lección práctica de estos datos no es “usemos más herramientas”. Es bastante más incómoda: si aumentas la capacidad de producir sin aumentar la capacidad de entender, validar y decidir, no estás mejorando el sistema. Estás dándole más potencia a una dirección que quizá nadie ha comprobado.

Discovery no es marear la perdiz

Una parte del rechazo al discovery viene de una experiencia muy común: empresas que llaman discovery a estar semanas hablando sin decidir nada.

Discovery no consiste en convertir cada petición en una tesis doctoral. No consiste en entrevistar a media empresa antes de cambiar un botón. No consiste en crear un documento de 40 páginas para justificar una mejora evidente. Y desde luego no consiste en paralizar al equipo hasta que todas las incertidumbres estén resueltas, porque eso no va a pasar.

Discovery consiste en reducir las incertidumbres importantes antes de invertir demasiado en construir. La palabra clave es “importantes”.

• Si el cambio es pequeño, reversible, barato y evidente, probablemente no necesitas montar ningún ritual especial. Lo haces, lo mides y aprendes.
• Si el cambio es caro, visible, transversal, difícil de revertir, sensible a datos, permisos, procesos, operación o comportamiento de usuario, construir sin discovery es jugar a ser valiente con presupuesto ajeno.

La pregunta adulta no es “¿hacemos discovery o no?”. La pregunta adulta es: “¿Qué no sabemos todavía y cuánto nos costará equivocarnos?” Ese matiz cambia la conversación.

Y también ayuda a evitar el otro extremo: convertir discovery en un freno permanente. El objetivo no es saberlo todo antes de construir. El objetivo es no construir a ciegas cuando el coste del error es alto.

Los cuatro riesgos antes de construir

Silicon Valley Product Group trabaja desde hace años con una idea muy útil: antes de construir un producto o una funcionalidad relevante, conviene revisar cuatro riesgos. Valor, usabilidad, factibilidad y viabilidad.

No hace falta convertirlo en liturgia. Basta con usarlo como un mapa mental.

El riesgo de valor responde a una pregunta básica: ¿alguien necesita esto lo suficiente como para usarlo?

No es lo mismo que “alguien lo ha pedido”. Pedir algo en una reunión cuesta muy poco. Usarlo cada semana, abandonar un Excel, cambiar un hábito, confiar en una herramienta nueva o adaptar un proceso cuesta bastante más.

Aquí mueren muchos dashboards. No porque el SQL esté mal ni porque la visualización sea horrible, aunque a veces también. Mueren porque no cambian ninguna decisión. Se abren el día de la presentación, generan un entusiasmo prudente y luego quedan ahí, flotando en el cementerio silencioso de los enlaces corporativos.

Cuando eso pasa… ha fallado el valor. El riesgo de usabilidad pregunta otra cosa: ¿la persona podrá usar esto sin sufrir?

En herramientas internas este punto se desprecia con demasiada alegría. Como el usuario trabaja dentro de la empresa, parece que todo vale. Pantallas densas, campos crípticos, mensajes de error escritos para la base de datos, permisos que nadie entiende, flujos que obligan al usuario a conocer la arquitectura interna.

Luego alguien dice: “ya se les formará”.

Cuidado con esa frase. La formación ayuda, claro. Pero si necesitas una hora para explicar una operación básica, quizá no tienes un problema de formación. Quizá tienes un problema de diseño.

El riesgo de factibilidad es donde ingeniería debería estar desde el principio. No para bloquear, sino para aterrizar.

¿Tenemos los datos? ¿Son fiables? ¿Podemos integrarnos con ese sistema? ¿Qué dependencias hay? ¿Qué permisos hacen falta? ¿Qué parte parece sencilla pero no lo es? ¿Qué coste de mantenimiento introduce? ¿Qué deuda técnica estamos tocando?

Cuando ingeniería entra tarde, muchas veces parece negativa. “Eso no se puede”, “eso es más complejo”, “ese dato no está así”, “ese proceso no funciona de esa forma”. Pero a veces no es negatividad. Es realidad llegando tarde a una conversación donde ya se prometió demasiado.

Y el riesgo de viabilidad es el que más se esconde debajo de la alfombra: ¿esto encaja con la organización?

Una solución puede ser valiosa, usable y técnicamente posible, y aun así no ser viable. Puede requerir un cambio operativo que nadie va a asumir. Puede necesitar soporte que no existe. Puede crear responsabilidades nuevas sin dueño. Puede depender de catálogos que nadie mantiene. Puede exigir una disciplina que el proceso real no tiene.

Esto pasa muchísimo con aplicaciones internas. Se construye una herramienta para ordenar un proceso, pero nadie define quién revisa excepciones, quién mantiene reglas, quién audita resultados, quién corrige datos, quién atiende errores o quién decide qué ocurre cuando el sistema dice “no”.

La herramienta sale a producción. La foto queda bien. El problema empieza después.

Si tienes que quedarte con una herramienta de todo este bloque, quédate con esta: antes de construir algo relevante, obliga a la idea a pasar por valor, usabilidad, factibilidad y viabilidad. Si no sobrevive a esas cuatro preguntas, no tienes una funcionalidad lista para delivery. Tienes una hipótesis que todavía necesita madurar.

Cómo saber si tu equipo vive en delivery sin discovery

No hace falta hacer una auditoría compleja.

Si casi todo el backlog empieza con verbos de construcción, pero rara vez aparece escrito el problema, tienes una señal clara. “Crear pantalla”, “añadir campo”, “generar informe”, “automatizar proceso”, “hacer exportación”, “crear alerta”. Todo eso puede ser necesario, pero si nadie puede explicar qué comportamiento, decisión o resultado debería cambiar, el equipo está trabajando a ciegas.

También se nota cuando se estima demasiado pronto. La estimación aparece antes que el entendimiento. Se pide una fecha cuando todavía no se sabe bien qué se está resolviendo. Entonces el equipo estima una sombra. Y cuando la sombra cambia, que cambiará, la estimación se convierte en una especie de contrato emocional imposible.

Otro síntoma muy habitual: ingeniería entra cuando ya hay fecha. Ese orden es mortal. Si la fecha llega antes que el entendimiento, el equipo técnico ya no entra en modo diseño. Entra en modo defensa.

Y quizá el síntoma más revelador está en las demos. Hay equipos que enseñan funcionalidad, pero nunca explican aprendizaje. Enseñan lo construido, pero no qué riesgo se redujo. No qué hipótesis se validó. No qué se descubrió del usuario. No qué decisión nueva se puede tomar. No qué parte del problema entienden mejor ahora que antes.

Eso no es producto. Es escaparate.

Una forma rápida de auditar tu propio equipo es mirar el backlog durante diez minutos. Si encuentras muchas soluciones y pocos problemas escritos con claridad, ya tienes una señal. No hace falta una consultoría. Hace falta leer con honestidad qué tipo de trabajo estáis metiendo en la máquina.

El mínimo discovery viable

No todos los equipos pueden implantar de golpe una forma avanzada de trabajar producto. Ni falta que hace para empezar. Pero cualquier equipo puede introducir una práctica muy sencilla: antes de escribir la solución, escribir el problema.

No hablo de un documento eterno. Hablo de una ficha breve, casi incómodamente simple, que obligue a pensar un poco antes de construir.

La primera pregunta debería ser: ¿qué ocurre hoy?

Y la respuesta no debería ser “necesitamos un dashboard”. Eso no es lo que ocurre. Eso es una propuesta. Una respuesta mejor sería algo como: “los responsables de canal no detectan a tiempo caídas de venta y reaccionan cuando el cierre semanal ya ha pasado”.

Después habría que identificar quién sufre el problema. No “negocio”. No “la empresa”. Roles concretos, personas concretas, equipos concretos. Si no sabes quién lo sufre, probablemente tampoco sabes quién lo va a usar.

Luego conviene entender cómo se resuelve hoy. Esta parte suele ser una mina. Aparecen Excels, correos, pantallazos, reuniones, consultas manuales, accesos compartidos, conversaciones de Teams y procesos informales que nunca estuvieron documentados pero sostienen media operación.

Y justo ahí suele aparecer la verdad: muchas herramientas internas no sustituyen a una herramienta anterior, sustituyen a una coreografía invisible de personas haciendo apaños.

Después toca preguntar por el impacto. Qué duele exactamente. Tiempo perdido, errores, retrasos, riesgo, falta de trazabilidad, dependencia de una persona, decisiones tardías, duplicidades. Si no hay impacto, quizá no hay prioridad. O quizá la prioridad es política, que también existe, pero conviene saberlo.

Y por último hay que definir qué debería cambiar si lo hacemos bien. No vale decir “tener una herramienta”. Tener una herramienta no es un resultado. Resultado es reducir tiempo de revisión, detectar incidencias antes, evitar errores manuales, unificar criterios, mejorar trazabilidad, aumentar autonomía o reducir dependencia de soporte técnico.

Con esas pocas preguntas, la conversación cambia por completo.

No porque mágicamente sepamos todo. Sino porque dejamos de construir desde la primera ocurrencia.

Un ejemplo muy realista

Imagina esta petición:

“Necesitamos una aplicación para gestionar solicitudes internas.”

Un equipo centrado solo en delivery puede convertir eso rápidamente en una app con login, formulario, listado, estados, adjuntos, comentarios, notificaciones y panel de administración.

Suena bien. Incluso puede quedar bien.

Pero después empiezan las sorpresas. Las solicitudes llegan mal explicadas. Los usuarios no saben qué opción elegir. Los técnicos siguen pidiendo contexto por correo. Los estados no reflejan el proceso real. Nadie revisa duplicados. Las prioridades se discuten fuera de la herramienta. El formulario se convierte en otro buzón más, solo que más caro.

Con discovery, la conversación sería distinta.

Quizá el problema real no es “no tenemos una app”. Quizá el problema es que las áreas piden trabajo técnico con poca información, por canales dispersos, sin criterios claros de prioridad y sin una validación inicial que separe una necesidad madura de una idea todavía borrosa.

Si ese es el problema, la primera solución no tiene por qué ser una plataforma completa. Puede ser rediseñar la entrada de demanda, crear preguntas guiadas por tipo de necesidad, validar mínimos de información, detectar incoherencias, generar preguntas de aclaración y establecer estados simples que reflejen la realidad del proceso.

Eso ya no es “hacer una app”… eso es diseñar un sistema de demanda.

Y aquí conviene quedarse con una idea: muchas veces el producto no es la pantalla. El producto es el sistema de trabajo que la pantalla permite ordenar.

Si no entiendes ese sistema, construirás interfaz sobre confusión.

Ingeniería no debería llegar tarde

Hay una idea bastante dañina en muchas organizaciones: discovery es cosa de producto y negocio; delivery es cosa de ingeniería.

No.

Ingeniería tiene que participar en discovery porque muchas decisiones de producto son decisiones técnicas disfrazadas.

Un perfil técnico con experiencia puede detectar que una petición aparentemente sencilla toca un sistema delicado. Puede saber que un dato no significa lo que negocio cree. Puede anticipar que una integración va a introducir latencia. Puede ver que una solución generará soporte constante. Puede proponer una alternativa más simple. Puede evitar que se prometa algo inviable. Puede traducir una necesidad ambigua en una arquitectura razonable.

Cuando ingeniería solo recibe tickets, pierde capacidad de aportar criterio.

Y cuando una empresa reduce ingeniería a ejecución, luego no puede sorprenderse de que sus técnicos actúen como ejecutores.

Si quieres criterio técnico, tienes que meter criterio técnico antes de cerrar la solución. No después, cuando ya solo queda discutir plazos.

Qué puede hacer un perfil técnico desde mañana

No hace falta esperar a que la empresa cambie su modelo operativo, compre otra herramienta o pinte la palabra “producto” en una presentación corporativa.

Un perfil técnico puede empezar con preguntas.

Cuando llegue una petición, en vez de responder únicamente con “vale” o “¿para cuándo?”, puede decir:

“Antes de estimarlo, necesito entender qué problema estamos resolviendo.”

No es una frase rebelde. Es una frase profesional.

Puede preguntar quién lo va a usar de verdad, qué hace hoy esa persona, qué decisión cambiará, qué pasa si no se construye, qué riesgo preocupa más, qué dato falta, quién lo mantendrá después y cuál sería la forma más pequeña de aprender antes de comprometer una solución grande.

Estas preguntas son pura protección. Protegen al usuario de recibir algo inútil. Protegen al equipo de construir a ciegas. Protegen a negocio de invertir en soluciones que no cambian nada. Y protegen a tecnología de convertirse en una máquina de tickets sin criterio.

Si mañana solo haces una cosa distinta, haz esta: no aceptes una solución sin haber entendido antes el problema que dice resolver.

No necesitas bloquear. No necesitas ponerte intenso. No necesitas dar una clase en cada reunión. Solo necesitas introducir una pausa inteligente antes de que la máquina empiece a producir.

La velocidad necesita dirección

La industria está obsesionada con acelerar.

Acelerar desarrollo. Acelerar despliegues. Acelerar automatización. Acelerar análisis. Acelerar generación de código. Acelerar reporting. Acelerar decisiones.

Bien. No tengo ningún problema con ir más rápido. El problema es que acelerar sin dirección solo consigue que llegues antes al sitio equivocado.

Y esto es lo que muchas organizaciones no quieren mirar. No tienen un problema de velocidad. Tienen un problema de entendimiento.

No entienden bien el problema. No entienden bien al usuario. No entienden bien la decisión. No entienden bien el proceso. No entienden bien el dato. No entienden bien el coste de mantener lo que construyen.

Entonces piden más delivery. Más capacidad. Más automatización. Más IA. Más equipos. Más herramientas. Más presión.

Y producen más, pero no necesariamente mejor.

Fuentes consultadas

CircleCI, The 2026 State of Software Delivery
https://circleci.com/resources/2026-state-of-software-delivery/

CircleCI, 5 key takeaways from the 2026 State of Software Delivery
https://circleci.com/blog/five-takeaways-2026-software-delivery-report/

DORA, DORA’s software delivery performance metrics
https://dora.dev/guides/dora-metrics/

Atlassian, State of Product Report 2026
https://www.atlassian.com/software/jira/product-discovery/resources/state-of-product-2026

Atlassian, The State of Product in 2026: Navigating Change, Challenge, and Opportunity
https://www.atlassian.com/blog/announcements/state-of-product-2026

Silicon Valley Product Group, The Four Big Risks
https://www.svpg.com/four-big-risks/