¿Cómo funciona el desarrollo web? El proceso completo
Desde fuera, el desarrollo web puede parecer un silencio largo seguido de un sitio terminado. En la práctica es una secuencia de entornos, puntos de control y decisiones, y el lado del cliente tiene obligaciones en casi todos ellos.
Esta guía cubre cómo transcurre realmente un proyecto, qué se le pedirá y cuándo, y los puntos de control donde un problema todavía es barato de arreglar.
Entornos: dónde vive el sitio antes de estar en línea#
Casi todo proyecto profesional mantiene tres copias del sitio. Saber cuál está mirando evita muchísima confusión durante las revisiones.
| Entorno | Quién lo usa | Para qué |
|---|---|---|
| Local | Quien desarrolla | Trabajo diario; usted nunca lo ve |
| Preproducción | Usted y quien desarrolla | Revisión, pruebas y aprobación; bloqueado a los buscadores |
| Producción | Los visitantes | El sitio en línea |
El contenido añadido en preproducción no aparece automáticamente en producción salvo que el proyecto esté preparado para migrarlo. Pregúntelo pronto, porque teclear 200 productos dos veces es un riesgo real.
La secuencia de una construcción típica#
Los nombres varían entre equipos, pero el orden es bastante constante porque cada paso depende del anterior.
- Arranque. Requisitos confirmados, accesos concedidos, contactos nombrados, fechas acordadas.
- Preparación. Repositorio, entornos, CMS o framework instalado, canal de despliegue.
- Plantillas. El diseño se convierte en plantillas funcionando, normalmente la más compleja primero.
- Modelado de contenido. Campos y tipos para que su equipo edite sin romper maquetaciones.
- Integraciones. Pago, CRM, correo, analítica: cada una necesita credenciales suyas.
- Carga de contenido. Suya o de ellos, según lo que dijera el presupuesto.
- Pruebas. Funcionales, entre navegadores, de rendimiento, de accesibilidad.
- Comprobaciones previas. Redirecciones, robots, sitemap, analítica, copias de seguridad.
- Lanzamiento. Cambio de DNS, verificación, monitorización.
- Después del lanzamiento. Arreglos, traspaso, formación y luego mantenimiento.
Qué tiene que entregar su lado, y cuándo#
Casi todos los retrasos que parecen del equipo de desarrollo son retrasos esperando al cliente. Estos son los elementos que conviene tener listos antes de que se los pidan, porque cada uno bloquea trabajo cuando llega tarde.
| Usted aporta | Necesario en | Si llega tarde |
|---|---|---|
| Acceso al dominio y al DNS | Preparación | No se puede programar el lanzamiento |
| Materiales de marca y archivos del logotipo | Plantillas | Marca provisional durante toda la revisión |
| Contenido e imágenes de las páginas | Carga de contenido | La causa más común de una fecha de lanzamiento incumplida |
| Datos de producto | Carga de contenido | La construcción de la tienda se detiene por completo |
| Credenciales de terceros | Integraciones | El trabajo de integración se bloquea a mitad de sprint |
| Comentarios en cada revisión | Cada punto de control | Trabajo rehecho, porque la construcción ha avanzado |
| Páginas legales | Antes del lanzamiento | Lanzamiento retrasado por una política de privacidad |
Puntos de control donde un problema todavía es barato#
El coste del cambio sube con fuerza a lo largo de un proyecto. Estos son los momentos para mirar de verdad en vez de por encima, porque después de cada uno el mismo cambio cuesta varias veces más.
- Tras los wireframes: la estructura y las prioridades todavía se cambian gratis.
- Tras construir la primera plantilla: aquí descubre si el diseño sobrevive al contenido real.
- Tras el modelado de contenido: intente editar una página usted mismo. Si ahora es incómodo, lo será durante años.
- Tras la primera integración: confirme que los datos aterrizan donde su equipo trabaja de verdad.
- En preproducción con contenido real: el último punto en el que los problemas de maquetación son baratos.
- Antes del cambio de DNS: redirecciones, analítica y formularios verificados.
Revisar en un móvil no es opcional. Casi todos los sitios reciben la mayoría de su tráfico desde móviles, y revisar solo en escritorio es como los problemas móviles llegan a producción.
Preguntas frecuentes
¿Cuánto tiempo mío consumirá el proyecto?
Más de lo que casi nadie presupuesta. Cuente con un punto de control semanal de treinta a sesenta minutos, más el trabajo de contenido, que se mide en días y no en horas. El mejor predictor de que un proyecto termine a tiempo es si el lado del cliente tiene una persona con autoridad para decidir y tiempo para revisar.
¿Qué es un sprint y debería importarme?
Un sprint es un periodo fijo —normalmente una o dos semanas— en el que se completa un conjunto de trabajo acordado y se le muestra. Le importa porque define el ritmo de las decisiones: los comentarios dados durante un sprint son baratos y los dados tres sprints después son trabajo rehecho. Si su equipo no trabaja por sprints, querrá igualmente un punto de control regular por la misma razón.
¿Puedo ver avances antes de que el sitio esté terminado?
Sí, y debería. Pida acceso a preproducción desde la primera plantilla. Ver trabajo a medias es incómodo pero es mucho mejor que una revelación al final, cuando los comentarios estructurales salen caros. Espere que se vea sin terminar: para eso se mira pronto.
¿Qué pasa justo después del lanzamiento?
Un periodo corto —habitualmente de dos a cuatro semanas— en el que se cubren arreglos pequeños, y luego una transición a un acuerdo de mantenimiento o a nada. Acuerde por adelantado cuál de los dos es, qué cuenta como arreglo frente a petición nueva, y a quién llamar fuera de horario si el sitio se cae. «Ya lo veremos» es como los sitios acaban sin mantenimiento.
como funciona el desarrollo webproceso de desarrollo webfases desarrollo webentorno de preproduccióngestión de proyecto webplazos desarrollo web
