El proceso de desarrollo web explicado
Todas las metodologías de desarrollo web ordenan las mismas fases de forma distinta. Entender las fases en sí —qué produce cada una y qué la cierra— es más útil que el nombre de la metodología, porque le dice si el proyecto está donde debería estar.
Esta guía cubre las siete fases, duraciones típicas para un sitio mediano y cómo es una aprobación real en cada una.
Las siete fases#
Las duraciones suponen un sitio a medida de tamaño medio con un equipo pequeño. Se alargan mucho más con el volumen de contenido y las integraciones que con el número de páginas.
| Fase | Produce | Duración típica |
|---|---|---|
| 1. Descubrimiento | Objetivos, público, alcance, restricciones | 1–2 semanas |
| 2. Estructura | Estructura de páginas, modelo de contenido, wireframes | 1–2 semanas |
| 3. Diseño | Plantillas, sistema de componentes, reglas adaptables | 2–4 semanas |
| 4. Construcción | Plantillas funcionando, CMS, integraciones | 4–10 semanas |
| 5. Contenido | Textos, imágenes y datos reales en el sistema | En paralelo; a menudo la más larga |
| 6. Pruebas | Funcionales, entre navegadores, rendimiento, accesibilidad | 1–2 semanas |
| 7. Lanzamiento | Sitio en línea, redirecciones, monitorización, traspaso | 2–5 días |
La fase 5 es la que se desborda. Se dibuja en paralelo porque debería empezar en la fase 2, no porque sea pequeña.
Qué cierra cada fase#
Una fase no termina porque haya pasado el tiempo. Termina cuando algo concreto se ha acordado, por escrito, por alguien con autoridad. Sin eso, el trabajo continúa sobre unos cimientos que todavía pueden moverse.
- Descubrimiento: un alcance firmado con una lista explícita de exclusiones.
- Estructura: una estructura de páginas y un modelo de contenido aprobados, con nombres de campo que su equipo entienda.
- Diseño: plantillas aprobadas para cada maquetación distinta, incluidos móvil y estados vacíos.
- Construcción: cada plantilla demostrada en preproducción con contenido realista.
- Contenido: cada página crítica llena y revisada por una persona con nombre.
- Pruebas: una lista de incidencias acordada y dividida entre bloqueantes del lanzamiento y arreglos posteriores.
- Lanzamiento: una checklist previa completada y el traspaso de accesos confirmado.
Cascada, ágil o algo intermedio#
La diferencia real está en cuándo se fija el alcance. Los proyectos de alcance fijo se presupuestan con precisión y llevan mal el cambio; los iterativos llevan bien el cambio y no pueden prometer un total fijo. Casi todo el trabajo web queda en medio: alcance fijo hasta el lanzamiento e iterativo después.
| Alcance fijo | Iterativo | |
|---|---|---|
| Precio | Conocido por adelantado | Tarifa por sprint o por mes |
| Cambio | Petición formal, revalorada | Absorbido repriorizando el backlog |
| Mejor para | Requisitos claros y estables | Productos en evolución y requisitos poco claros |
| Su riesgo | Pagar por algo que ya no encaja | Que el coste derive sin un tope duro |
| Necesita de usted | Decisiones por adelantado | Disponibilidad continua para priorizar |
Cuidado con el precio cerrado con alcance vago. Es la peor combinación: quien desarrolla protege su margen interpretando la ambigüedad de forma estrecha, y cada aclaración se convierte en una negociación.
Dónde suele torcerse el proceso#
Los mismos cuatro fallos explican casi todos los desbordes, y ninguno es técnico.
- Diseño aprobado contra contenido de relleno. El texto real llega con el doble de longitud y la maquetación se rehace.
- Integraciones descubiertas tarde. «También tiene que hablar con nuestro sistema de stock» en la semana ocho es un proyecto nuevo, no un cambio.
- Sin una única persona que decida. Los comentarios llegan de cinco personas, dos se contradicen y nadie tiene autoridad para zanjarlo.
- Pruebas tratadas como fase y no como hábito. Los fallos encontrados en la semana diez que se introdujeron en la tres cuestan varias veces más de arreglar.
Preguntas frecuentes
¿Cuánto tarda un sitio web típico?
Un sitio pequeño basado en plantillas, de dos a cuatro semanas. Un sitio a medida mediano, normalmente de tres a cinco meses de principio a fin. Las tiendas y las aplicaciones tardan más. La variable que más mueve esto no es la complejidad del código sino la disponibilidad del contenido y la velocidad de decisión del lado del cliente.
¿Pueden solaparse las fases?
Algunas deberían. El contenido debería empezar durante la estructura, y las pruebas deberían acompañar toda la construcción en vez de estar solo al final. Lo que no debería solaparse es el diseño y la construcción de la misma plantilla: construir contra un diseño que aún se mueve garantiza trabajo rehecho y es la fuente más común de discusiones del tipo «eso ya lo habíamos construido».
¿Y si necesitamos cambiar algo a mitad de proyecto?
Cuente con ello y acuerde el mecanismo por adelantado: quién puede pedir un cambio, quién lo valora y si mueve la fecha de lanzamiento. Los cambios pequeños absorbidos en silencio son como un proyecto deriva un mes sin que nadie pueda decir cuándo ocurrió. Un registro escrito de cambios resuelve la mayor parte.
¿Debo pagar por fases?
Los pagos por hitos vinculados a entregables que puede inspeccionar son la estructura más justa para ambas partes: normalmente una señal y luego pagos en la aprobación del diseño, la finalización de la construcción y el lanzamiento. Evite pagar todo por adelantado y evite pagar todo al terminar, lo que traslada todo el riesgo de tesorería a quien desarrolla y suele salirle más caro.
proceso desarrollo webfases desarrollo webetapas proyecto webdesarrollo web ágilcronograma webmetodología desarrollo web
