VJOURNAL

InnovaciónMesa global27 de agosto de 2026

Plazos de desarrollo: de qué se componen — decisiones, contenido y aprobaciones

La ventana de un paquete describe el trabajo del proveedor y no tu fecha de lanzamiento. Repasamos qué le suman las decisiones, los textos, los accesos y la aceptación, y por qué «Desarrollo de producto» se indica en semanas y el resto en días laborables.

Portada de VJOURNAL para «Plazos de desarrollo: de qué se componen — decisiones, contenido y aprobaciones»

Respuesta breve

La ventana de un paquete describe el trabajo del proveedor y no tu fecha de lanzamiento. Repasamos qué le suman las decisiones, los textos, los accesos y la aceptación, y por qué «Desarrollo de producto» se indica en semanas y el resto en días laborables.

3 fuentes
La ventana del paquete describe el trabajo del proveedor; la fecha de lanzamiento es esa ventana más tus intervalos y la aceptación.
«Desarrollo de producto» se indica en semanas —2-3 semanas—, mientras que el resto de paquetes se indica en días laborables.
El contenido y las traducciones los aporta el cliente, así que la ventana empieza cuando existe el material y no con la firma.

De qué se compone un plazo: la respuesta corta: La ventana del paquete describe el trabajo del…

Un plazo se compone de cuatro tramos encadenados: la ventana de trabajo del proveedor, tus decisiones, tus materiales y la aceptación. Escribir código ocupa una parte menor del calendario que esperar una respuesta que todavía nadie ha asumido como propia.

La página de desarrollo de VITON13 indica ventanas concretas: 1-2 días laborables, 2 días laborables, 3-5 días laborables, 2-3 semanas y un ciclo mensual. Todas describen el trabajo del proveedor. La fecha de lanzamiento aparece cuando les sumas tus propios intervalos.

Por eso un mismo paquete produce dos fechas distintas para dos clientes. La construcción es idéntica, pero la cola de aprobaciones, la disponibilidad de los textos y la rapidez para entregar los accesos no lo son, y esa diferencia mueve el calendario.

A continuación se explica qué hay detrás de cada ventana, qué acciones tuyas la sostienen y por qué «Desarrollo de producto» se indica en semanas mientras el resto de los paquetes se indica en días laborables. La diferencia no es cosmética.

Qué plazo indica cada paquete

«Site Fix Pack» cuesta $70 y ocupa 1-2 días laborables: hasta cinco correcciones acordadas, una revisión en móvil y escritorio y una lista de antes y después en la entrega. Una ronda de revisión. Las páginas nuevas, el rediseño y las migraciones quedan fuera.

«Sitio para lanzamiento» cuesta $380 y ocupa 3-5 días laborables: construcción responsive, conexión de un CMS básico o de los datos y configuración del despliegue. Dos rondas antes del lanzamiento. El contenido y las traducciones los aporta el cliente, porque el proveedor no los redacta.

«Sitio para lanzamiento» Express cuesta $520 y ocupa 2 días laborables: el mismo alcance en cola prioritaria, con compilaciones diarias, una lista de verificación de lanzamiento y una llamada de entrega. Una ronda después de la primera construcción completa. Contenido, fotografía y soporte quedan fuera.

«Desarrollo de producto» cuesta $880 y ocupa 2-3 semanas: entrega de funcionalidades, lógica de estado y de rutas, pruebas y estabilización. Dos rondas por cada funcionalidad entregada. Las aplicaciones móviles nativas y las licencias de pago quedan fuera. «Soporte técnico continuo» cuesta $290/mes en ciclo mensual, con 30 días de preaviso para terminarlo.

Por qué «Desarrollo de producto» se indica en semanas

Los días laborables son una unidad honesta cuando el alcance se conoce de antemano. Cinco correcciones, o una construcción responsive, se pueden escribir como una lista, así que la ventana se nombra antes de empezar y luego se sostiene sin renegociarla.

La entrega de funcionalidades no se describe así. La lógica de estado y de rutas se despliega mientras se construye: una pantalla implica otra y comprobar los casos límite devuelve el trabajo un paso atrás. Una semana absorbe esos retornos y un día no los absorbe.

Las pruebas y la estabilización viven dentro de esas mismas 2-3 semanas. Son una parte declarada del paquete y no el tiempo que sobra cuando las funcionalidades empiezan a compilar, y generan parte del retrabajo que una cuadrícula diaria no puede sostener.

La consecuencia práctica es sencilla: no conviertas en silencio 2-3 semanas en diez o quince días laborables ni planifiques sobre esa cuadrícula. La formulación en semanas se eligió a propósito y conviene mantenerla literal también en tu propia correspondencia.

Decisiones: la cola de elecciones sin tomar

El calendario lo consumen las preguntas sin responsable, no las líneas de código. Cuál de las dos direcciones de portada se toma, cuántos niveles tiene el menú, qué ocurre tras enviar un formulario: cada una espera a alguien que la cierre.

Mientras una pregunta sigue abierta el trabajo no se detiene: rodea la zona en disputa. Ese rodeo cuesta tiempo dos veces, una por la decisión provisional y otra cuando esa decisión provisional se sustituye por la respuesta definitiva.

Lo que ayuda es una persona designada, más que una respuesta rápida. Un aprobador con la última palabra acorta el ciclo de forma más fiable que un grupo amplio donde todos comentan, nadie cierra la pregunta y la conversación vuelve a empezar.

Acordad de antemano por qué canal llegan las preguntas y en cuánto tiempo se responden. Ese intervalo pertenece a tu lado de la fecha de lanzamiento y merece la misma atención de planificación que la construcción en sí.

El contenido y las traducciones llegan del cliente

«Sitio para lanzamiento» lo dice de forma directa: el contenido y las traducciones los aporta el cliente. Express repite la misma línea y añade la fotografía. VITON13 no redacta tus textos ni los traduce, y eso es un límite del servicio, no letra pequeña.

De ahí se deriva una línea de salida. Los tres a cinco días laborables no empiezan con la firma, sino cuando los materiales existen. Los bloques vacíos no se rellenan más adelante sin una segunda pasada por la maquetación y una segunda revisión.

Los textos pueden escribirse en paralelo a la construcción si la estructura de páginas se fija antes. Entrega al redactor la lista de bloques y un límite de extensión, y el material llegará justo en el punto en que la construcción lo necesita.

Un lanzamiento multilingüe necesita su propio plan: la traducción empieza cuando el texto original deja de cambiar. Editar una sola frase en el idioma de origen devuelve a la cola todas las versiones lingüísticas, y no solo una de ellas.

Las rondas de revisión ocupan el calendario

Las rondas de revisión cambian según el paquete y esa diferencia aterriza en el calendario. Fix Pack tiene una ronda. «Sitio para lanzamiento» tiene dos rondas antes del lanzamiento. Express tiene una ronda después de la primera construcción completa. «Desarrollo de producto», dos rondas por funcionalidad entregada.

Una ronda es una lista reunida, no un flujo de mensajes sueltos. Veinte comentarios enviados en un solo documento cuestan una pasada; esos mismos veinte enviados de uno en uno durante una semana cuestan una semana entera de trabajo.

Para «Soporte técnico continuo» no se indica ningún número de rondas. Lo que sí se indica es que el volumen se acuerda al inicio de cada ciclo. No traslades una cifra desde otro paquete, porque las condiciones no se transfieren entre paquetes.

Reserva la ventana de aceptación como si fuera una reunión: quién revisa, en qué dispositivos y a qué hora se envía la lista. Sin eso, una ronda se alarga exactamente tanto como tarde la recogida de opiniones dentro de tu equipo.

Accesos, cuentas y terceros

La configuración del despliegue forma parte de «Sitio para lanzamiento», pero depende de lo que entregues tú: dominio, DNS, alojamiento y credenciales de las cuentas. Mientras no haya acceso, el trabajo puede estar terminado y el lanzamiento, en la práctica, no ha ocurrido.

Parte de esos accesos los emiten organizaciones externas a su propio ritmo. Un registrador, un banco, un proveedor de pagos o un departamento de informática corporativo responden según su propio calendario, y ningún proveedor puede comprimir ese calendario por ti.

Reúne las credenciales el primer día y no el día del lanzamiento. La lista es corta y se conoce de antemano, así que avanza cómodamente junto a la construcción y no bloquea nada mientras la vas completando punto por punto.

Las licencias de pago quedan fuera de «Desarrollo de producto». Cuando un producto necesita cobrar, la parte legal y el trabajo con el proveedor de pagos se quedan de tu lado y se planifican aparte de las 2-3 semanas de desarrollo.

Límites del alcance: qué sostiene una ventana y qué la mueve

Una ventana se sostiene con una lista. «Hasta cinco correcciones acordadas» es esa lista y es la razón por la que 1-2 días laborables sigue siendo una promesa realista. Una sexta corrección no estira el paquete: se convierte en trabajo aparte.

Fix Pack excluye páginas nuevas, rediseño y migraciones. No es una formalidad: mover datos y rehacer una maqueta viven en otra unidad de tiempo, y forzarlos dentro de una ventana de dos días rompe la ventana misma.

«Desarrollo de producto» excluye las aplicaciones móviles nativas. Una construcción web y una aplicación nativa son cuerpos de trabajo distintos, y cambiar uno por otro modifica la composición del servicio y no la fecha en que termina.

Revisa la redacción del alcance antes de empezar y no a mitad de camino. La pregunta de si algo entra cuesta un minuto al principio y varios días cuando la construcción ya está en marcha y el calendario ya está acordado.

Pruebas, rendimiento y accesibilidad

Las pruebas y la estabilización están declaradas dentro de «Desarrollo de producto», es decir, dentro de esas mismas 2-3 semanas. Ocupan su propio lugar en el calendario y no el tiempo que sobra cuando las funcionalidades ya están escritas y entregadas.

El rendimiento se comprueba midiendo y no por impresión. El material de rendimiento de MDN Web Docs describe qué expone el navegador y qué etapas de carga conviene observar; ejecutar esas comprobaciones lleva horas y esas horas pertenecen al plan.

La accesibilidad funciona igual. La referencia rápida del W3C para WCAG 2.2 enumera los criterios de conformidad con los que se revisa una interfaz, y recorrer esa lista es una tarea planificada y no un vistazo final antes de publicar.

Ambas comprobaciones cuestan menos antes del lanzamiento que después. Lo que se detecta durante la construcción se corrige dentro de una ronda; lo mismo detectado tras el lanzamiento llega como trabajo aparte y se presupuesta al margen del paquete.

Días laborables frente a días naturales

1-2 días laborables, 2 días laborables y 3-5 días laborables están indicados exactamente en días laborables. Empezar un jueves con una ventana de 3-5 días laborables empuja el final más allá del fin de semana, y eso es aritmética de la formulación y no un retraso del proveedor.

Las 2-3 semanas de «Desarrollo de producto» están indicadas de otra manera, en semanas. No hace falta convertirlas: la unidad se eligió para encajar con el carácter del trabajo y no por comodidad de una hoja de cálculo compartida.

Los festivos de tu país y los del proveedor pueden no coincidir. Nómbralos antes de empezar, porque eso cuesta menos que explicar la diferencia en el momento en que la fecha ya se ha prometido al mercado.

Para llegar a una fecha de lanzamiento, suma tres intervalos: la ventana del paquete, tus propios intervalos para decisiones y materiales, y la ventana de aceptación. Esa suma es la fecha que puedes repetir con seguridad fuera del equipo del proyecto.

Express: comprar un lugar en la cola

«Sitio para lanzamiento» Express cuesta $520 frente a los $380 del «Sitio para lanzamiento» habitual, y ocupa 2 días laborables frente a 3-5. La diferencia de precio compra una cola prioritaria y no un cuerpo de trabajo distinto.

Express añade compilaciones diarias, una lista de verificación de lanzamiento y una llamada de entrega. Una compilación diaria significa que tus comentarios aterrizan cada día sobre una versión que funciona, y eso estrecha el ciclo de retroalimentación entre las dos partes.

Aquí hay una sola ronda de revisión y llega después de la primera construcción completa. Eso cambia tu preparación: los comentarios van en un único documento y a una hora acordada, o una ventana de 2 días laborables pierde su sentido.

El contenido, la fotografía y el soporte quedan fuera de Express. Una cola prioritaria acelera al proveedor y no la redacción de tus textos, así que el material tiene que existir antes de que la ventana llegue a abrirse.

Después del lanzamiento: un ciclo mensual en lugar de una fecha

«Soporte técnico continuo» cuesta $290/mes y funciona como ciclo mensual con 30 días de preaviso para terminarlo. Aquí la unidad no es una tarea ni un día, sino un ciclo, y la planificación sigue ciclos en lugar de fechas puntuales.

El paquete cubre actualizaciones prioritarias, un ritmo de publicación semanal y mantenimiento técnico. El ritmo semanal compra previsibilidad: un cambio entra en la siguiente publicación en lugar de esperar una conversación nueva sobre cuándo podría salir.

Para el soporte no se indica ningún número de rondas. Lo que sí se indica es que el volumen se acuerda al inicio de cada ciclo. Ese es el mecanismo de planificación: acuerdas el contenido de un mes y no una cuota de retrabajos.

Una construcción nueva o un rediseño quedan fuera del soporte y se presupuestan aparte. La separación resulta útil: el ciclo mensual sostiene el sitio en marcha, mientras que el trabajo mayor recibe una ventana propia y sus propias rondas.

Lista práctica

  • Designa a una sola persona con la última palabra y fija en cuánto tiempo se responden las preguntas.
  • Reúne dominio, DNS, alojamiento y credenciales el primer día y no el día del lanzamiento.
  • Fija la estructura de páginas antes de que el redactor empiece a escribir los textos.
  • Agrupa los comentarios en un único documento y envíalos como una sola ronda a una hora acordada.
  • Comprueba las exclusiones del paquete: páginas nuevas, migraciones, apps nativas y licencias de pago.
  • Convierte la ventana del paquete en una fecha real contando fines de semana y festivos de ambas partes.

Preguntas frecuentes

¿Cuánto tarda la construcción de un sitio para lanzamiento?

«Sitio para lanzamiento» cuesta $380 y ocupa 3-5 días laborables. La ventana cubre la construcción responsive, la conexión de un CMS básico o de los datos, la configuración del despliegue y dos rondas de revisión antes del lanzamiento. El contenido y las traducciones los aporta el cliente.

¿Por qué «Desarrollo de producto» se indica en semanas y no en días laborables?

El paquete cuesta $880 y se indica como 2-3 semanas porque cubre entrega de funcionalidades, lógica de estado y de rutas, pruebas y estabilización. Ese trabajo se despliega mientras se construye, así que la unidad semanal es deliberada y no hace falta convertirla en días.

¿Se puede acelerar un lanzamiento pagando más?

En parte. «Sitio para lanzamiento» Express cuesta $520 y ocupa 2 días laborables: el mismo alcance en cola prioritaria, con compilaciones diarias, lista de verificación de lanzamiento y llamada de entrega. La única ronda de revisión llega después de la primera construcción completa, y contenido, fotografía y soporte quedan fuera.

¿Qué incluye Site Fix Pack y en qué ventana?

$70 y 1-2 días laborables: hasta cinco correcciones acordadas, una revisión en móvil y escritorio, una lista de antes y después en la entrega y una ronda de revisión. Las páginas nuevas, el rediseño y las migraciones no forman parte del paquete.

¿Cómo se cuenta el plazo del soporte técnico?

«Soporte técnico continuo» cuesta $290/mes y funciona como ciclo mensual con 30 días de preaviso para terminarlo. No se indica ningún número de rondas: lo que se indica es que el volumen se acuerda al inicio de cada ciclo. Una construcción nueva o un rediseño se presupuestan aparte.