Respuesta breve
El desarrollador cuenta su trabajo y no tus aprobaciones, textos y accesos, que son la mitad del proyecto. De qué se compone un plazo de verdad y qué se puede acelerar.
Por qué el plazo que te dan siempre es menor que el real
Cuando un desarrollador da un plazo, cuenta honestamente su propio trabajo. No cuenta tus aprobaciones, la espera de los textos, el acceso a la pasarela de pago ni las dos semanas que se irán en vamos a mirarlo otra vez.
No es un engaño. Hará de verdad su parte en el tiempo indicado, si todo lo demás llega cuando toca. El problema es que todo lo demás es más o menos la mitad del proyecto, y es tuyo.
De ahí una regla práctica que rara vez se dice en voz alta: el plazo de desarrollo y el plazo hasta el lanzamiento son cifras distintas, y la segunda es como vez y media la primera.
Abajo va de qué se compone cada una, qué corre en paralelo y qué no, y qué señales se ven en la segunda semana de que el calendario se va a mover.
De qué se compone el plazo: La parte más larga del proyecto no es el código, sino…
Seis etapas, y el desarrollo no es la más larga.
Briefing y valoración: de unos días a dos semanas. Depende enteramente de ti, de lo preparado que estés para formular el encargo.
Diseño: de una semana para una maqueta estándar a un mes para una a medida con varios estados por bloque.
Desarrollo: de dos semanas para una web sencilla a varios meses para un catálogo con integraciones. Es la única etapa que el desarrollador estima con precisión.
Contenidos, pruebas y lanzamiento: se subestiman normalmente por tres. Textos, fotografías, comprobación en dispositivos, traslado de dominios y correo.
Qué puede ir en paralelo
No todo es secuencial, y ahí es donde más tiempo se ahorra.
Los textos se escriben a la vez que el diseño, no después. Es más: un diseño hecho sobre texto real sale mejor que uno en el que el texto se vierte luego.
La sesión de fotos y la preparación de imágenes van en paralelo a todo. Se pueden empezar el primer día, y casi nunca se hace.
La recogida de accesos empieza el día de la firma. Dominio, correo, pasarela de pago, sistema de gestión: todo eso tarda más de lo que parece y no depende de nadie del proyecto.
El desarrollo tras el diseño, en cambio, es casi siempre secuencial: maquetar una propuesta no aprobada es una manera de hacer el trabajo dos veces.
La parte más larga no es el desarrollo
Si miras proyectos cerrados, la mayor parte del tiempo no se va en código.
Se va en esperar: decisiones, textos, accesos, comentarios. En el calendario se ve como semanas en las que no pasa nada, porque una parte espera a la otra.
Se nota sobre todo en la aprobación del diseño. La maqueta salió el martes, los comentarios llegaron diez días después y tres de ellos se contradicen porque la miraron dos personas distintas.
La cura no es presionar al desarrollador, sino una decisión organizativa simple: una persona con la última palabra y un plazo acordado de respuesta. Tres días laborables para comentar una maqueta es una norma razonable.
Un proyecto donde se responde en tres días avanza el doble de rápido que uno donde se responde en dos semanas. Con el mismo volumen de trabajo.
Tres retrasos del lado del cliente
Dichos con honestidad, porque de ahí sale la mayor parte del desfase.
Los textos. Se aplazan porque escribir cuesta y el plazo parece lejano. Luego resulta que sin ellos no hay nada que enseñar. La solución es escribirlos en paralelo y entregarlos por páginas.
La aprobación por comité. Cada participante adicional no añade una opinión, añade un ciclo de espera. Si deciden tres y se reúnen cada dos semanas, cada corrección cuesta dos semanas.
Los accesos. Sobre todo los de pago y gestión, donde hacen falta documentos y confirmaciones. Hay que empezar el primer día, no cuando bloquee.
Tres retrasos del lado del desarrollador
Por simetría, y para saber qué preguntar.
Proyectos en paralelo. Una persona en tres proyectos no trabaja tres veces más rápido: alterna, y cada cambio cuesta tiempo. Pregunta de antemano en qué más está tu desarrollador.
Integraciones subestimadas. El intercambio con un sistema externo casi siempre es más difícil de lo que sugiere la descripción, porque la documentación está incompleta y el acceso de pruebas tarda una semana.
Vacaciones, enfermedad, baja. En un equipo pequeño la marcha de una persona es una parada. Preguntar qué pasa si el desarrollador enferma resulta incómodo, pero sale más barato que averiguarlo sobre la marcha.
Por qué lo hacemos en una semana a veces es cierto
No todo plazo corto es señal de poca seriedad.
Una web de tres a cinco páginas sobre una base ya hecha, con tus textos y tus fotos, se monta de verdad en una semana. Es trabajo normal y no hay que alargarlo por aparentar.
La semana deja de ser cierta en cuanto aparece algo de la lista: catálogo, área de cliente, pagos, intercambio con un sistema externo, varios idiomas, diseño no estándar.
Se comprueba fácil: pregunta qué se hará exactamente en esa semana y qué no entra en ella. La respuesta a la segunda pregunta es la informativa.
Cuánto tarda un proyecto típico
Puntos de referencia de los que partir. Es tiempo de calendario hasta el lanzamiento, no horas de trabajo.
Una web de presentación de pocas páginas: de una a tres semanas. La variable principal es si los textos están listos.
Una web corporativa con secciones de servicios y blog: de mes y medio a tres meses. La mayor parte del tiempo se va en contenidos y no en desarrollo.
Un catálogo o una tienda: desde tres meses. Datos, filtros, pago, envío, intercambio con el sistema de gestión: cada punto añade semanas.
Migrar una web existente: al plazo de desarrollo se suma el trabajo con las direcciones antiguas. Nosotros tuvimos 673, y repasarlas ocupó varios días aparte.
Cómo acortar el plazo sin perder calidad
Cuatro medidas que funcionan de verdad, a diferencia de exigir que se haga más rápido.
Lanzar por partes. Primero lo que genera dinero: las páginas de servicios y el formulario. Blog, galería y la sección de empresa en una segunda entrega. La web empieza a funcionar un mes antes.
Encargar los textos a un profesional en vez de escribirlos tú. Rara vez sale más caro que un mes de retraso y casi siempre es más rápido.
Nombrar a una persona con la última palabra. La medida de aceleración más barata que existe.
Reducir el número de estados en el diseño: una plantilla de ficha en vez de tres, un estilo de formulario en vez de cuatro. Cada estado es diseño, maquetación y prueba.
Qué no se acelera con dinero
Tres cosas que van a su ritmo al margen del presupuesto.
La indexación en buscadores. Tras el lanzamiento el buscador tiene que encontrar las páginas, rastrearlas y decidir que merecen un sitio. Son semanas y meses, y no hay pago que lo acorte.
Los accesos que dan organizaciones externas. Bancos, pasarelas de pago y registradores de dominios trabajan con sus propios procedimientos.
Tu propia decisión. Si no tienes claro qué quieres, meter más gente en el proyecto solo acelera el gasto. Una semana dedicada a decidirte ahorra un mes de rehacer.
Las señales de la segunda semana
Las señales aparecen pronto si sabes dónde mirar.
El briefing sigue sin fijarse por escrito y el trabajo ya ha empezado. El alcance crecerá sobre la marcha, y el plazo con él.
Tardaste más de tres días en responder a la primera pregunta del desarrollador. Ese es tu propio ritmo, y no se acelerará solo.
Los textos ni se han empezado y el diseño ya se está enseñando. Al llegar la maquetación no habrá textos, y el proyecto se parará justo ahí.
Ninguna es fatal, pero cada una cuesta aproximadamente una semana. Detectarlas en la segunda semana sale más barato que en la octava.
Lista práctica
- Separa en el calendario el plazo de desarrollo del plazo hasta el lanzamiento.
- Empieza a reunir los accesos el día de la firma del contrato.
- Arranca la escritura de textos en paralelo al diseño.
- Nombra a una persona con la última palabra.
- Acuerda un plazo de respuesta a maquetas y correcciones.
- Pregunta en qué otros proyectos está tu desarrollador.
- Decide qué puede pasar a una segunda entrega.
Preguntas frecuentes
¿Por qué el plazo real supera al que dan?
Porque el desarrollador cuenta su trabajo y no el tuyo: aprobaciones, textos, fotografías, accesos a sistemas de pago y gestión. Eso es más o menos la mitad del proyecto. El plazo de desarrollo y el de lanzamiento suelen diferenciarse en vez y media.
¿Cuánto tarda una web de presentación pequeña?
De una a tres semanas de calendario. La variable principal es si los textos y las fotos están listos. Si el material existe, una semana es realista; si aún hay que escribirlo y fotografiarlo, eso marca el plazo y no el desarrollo.
¿Se puede acelerar un proyecto metiendo más gente?
Rara vez. Añadir personas ayuda donde el trabajo se puede repartir y no ayuda donde el cuello de botella es una decisión del cliente o la espera de accesos. Si no tienes claro qué quieres, más manos solo aceleran el gasto.
¿Qué se puede pasar a una segunda entrega?
Todo lo que no participa en conseguir solicitudes: el blog, la galería, la sección extensa de empresa, las versiones en otros idiomas. Primero se lanzan las páginas de servicios y el formulario: la web empieza a funcionar un mes antes.
¿Cómo se ve en la segunda semana que el plazo se moverá?
Tres señales: el briefing sigue sin fijarse por escrito y el trabajo ya empezó; tardaste más de tres días en contestar la primera pregunta del desarrollador; los textos no se han empezado y el diseño ya se enseña. Cada una cuesta cerca de una semana.