Estás en el blog de Nicolau Roca
La religión de la entrega: cómo sacrificar a tu equipo en el altar del deadline
Una crítica a la cultura de entregar por entregar: deadlines sagrados, MVPs vacíos, deuda técnica normalizada y equipos quemados por falta de criterio.

Cuando entregar se convierte en dogma
Hay algo profundamente roto en la forma en que muchas empresas planifican y ejecutan trabajo. En algún momento, entregar dejó de estar conectado con valor, contexto o lógica y se convirtió en un ritual sagrado.
Una funcionalidad, un dashboard, un dataset, un informe: da igual qué sea. Tiene que estar entregado. No porque esté listo. No porque sea útil. Sino porque alguien puso una fecha en una diapositiva hace dos semanas.
“Tiene que estar para el comité.”
“Enseñamos algo y ya lo mejoramos luego.”
“La fecha ya se comunicó.”
Y entonces construimos. Empaquetamos. Presentamos. Aunque esté vacío. Aunque esté mal. Aunque nadie lo haya pedido así. Bienvenido al culto de la entrega sin sentido.
El mito del deadline innegociable
El problema: muchas fechas se fijan sin hablar con quienes harán el trabajo real. Sin validar complejidad. Sin dimensionar. Sin entender dependencias. Bajan como mandamientos desde un cielo con forma de Gantt.
No importa si el sistema necesita refactorización, si los datos aún no existen, si el equipo acaba de cambiar o si el alcance no está claro. La fecha ya está en el roadmap. Y tú ya llegas tarde.
La solución: una fecha debería ser el resultado de una conversación, no su punto de partida. Primero se entiende el objetivo, la complejidad, el riesgo y la capacidad real. Después se compromete una entrega.
MVP: mínimo, viable… ¿y producto?
El problema: el concepto de MVP se ha usado como excusa para entregar cosas incompletas, poco usables o directamente inútiles bajo apariencia de agilidad. Muchas veces no son mínimas, no son viables y no son productos.
Un MVP real valida una hipótesis. Un falso MVP solo desplaza el coste al futuro: deuda técnica, confusión de usuarios, pérdida de confianza y más reuniones para explicar por qué algo “todavía no está terminado”.
La deuda técnica como sacrificio aceptado
Cuando la entrega manda sobre el criterio, la deuda técnica deja de ser una excepción y se convierte en estrategia. Se normaliza copiar, parchear, duplicar, saltarse validaciones y dejar “pendiente de revisar” aquello que sostiene el sistema.
El problema es que la deuda siempre cobra intereses. Y los cobra en forma de incidencias, lentitud, miedo a tocar el código, dependencias personales y equipos que cada vez tardan más en hacer cambios pequeños.
Qué hacer en lugar de sacrificar al equipo
- Definir el valor antes de definir la fecha.
- Separar lo urgente de lo realmente importante.
- Validar alcance con quienes conocen el sistema.
- Entregar menos, pero entregar algo usable.
- Hacer visible la deuda técnica y sus consecuencias.
- Proteger tiempo para calidad, documentación y mantenimiento.
Conclusión
Entregar no es malo. Lo malo es convertir la entrega en religión. Un equipo sano no necesita sacrificar criterio para parecer productivo. Necesita objetivos claros, estructura, conversación honesta y margen para construir cosas que sigan funcionando después de la presentación.


