PROCESO · DESARROLLO WEB A MEDIDA
Cómo desarrollamos una web a medida: fases, plazos y entregables
Del problema que quieres resolver a una solución que puedas revisar y utilizar. Te explicamos qué decisiones hay que tomar, cómo se comprueban las funciones y qué puede condicionar la entrega.
Esta página explica la ejecución del trabajo. En el servicio de desarrollo web a medida puedes ver qué construimos y ejemplos reales.
De una necesidad a una solución web que funciona
Un desarrollo no comienza necesariamente escribiendo código. Primero hay que entender el problema y decidir cómo comprobar que la solución lo resuelve. Después se concretan las funciones, se diseña, se planifica, se construye, se prueba y se prepara la puesta en marcha y la continuidad.
El recorrido admite revisiones. Una prueba puede revelar una excepción que obliga a ajustar un requisito; una limitación de un proveedor puede cambiar el diseño. Volver a una decisión anterior no implica empezar todo de nuevo: hay que revisar su impacto y acordar el cambio.
Las fases y los documentos se adaptan al encargo. Esta explicación ayuda a entender el trabajo; los entregables, las comprobaciones y los servicios incluidos se concretan en cada propuesta.
El ejemplo que seguiremos es hipotético: una empresa recibe solicitudes de reserva por correo y teléfono y quiere reducir la intervención manual. No representa un contrato ni se atribuye a un cliente real.
1. Entendemos el problema que necesitas resolver
Una frase como «queremos automatizar las reservas» expresa una dirección, pero todavía no dice qué hay que construir. Necesitamos conocer el objetivo empresarial, quién utiliza el proceso, qué hace ahora y dónde aparecen los problemas.
Revisamos las herramientas existentes, las restricciones y las excepciones: por ejemplo, si la disponibilidad está en otra aplicación, si hay recursos compartidos o si una persona debe autorizar determinadas operaciones. Eso permite poner límites a la necesidad y separar lo que se quiere mejorar de lo que ya funciona.
Ejemplo de reservas · hipotético. Las solicitudes llegan por varios canales y una persona consulta una hoja antes de responder. Primero hay que aclarar si la web solo debe recoger solicitudes o si también tendrá autoridad para confirmar plazas. Son resultados distintos.
- Resultado que revisar
- Una descripción comprensible del problema, sus límites y el resultado esperado.
- Tu participación
- Aportar ejemplos reales de solicitudes, explicar las excepciones y validar que hemos entendido la operación.
- Qué puede condicionar el siguiente paso
- No conocer dónde está la disponibilidad fiable o quién puede autorizar una reserva puede impedir concretar la solución.
2. Convertimos la idea en requisitos y funcionalidades
El siguiente paso es convertir el objetivo en acciones comprobables: quién puede hacer qué, con qué datos y bajo qué condiciones. «El cliente puede reservar una actividad» no aclara si envía una petición pendiente o si obtiene una plaza confirmada.
Ejemplo de reservas · hipotético. Una especificación más útil sería: el usuario selecciona actividad y fecha, consulta plazas, introduce sus datos y confirma una solicitud. Antes de asignar una plaza, el sistema comprueba la capacidad; se define qué ocurre al aceptar o cancelar y cuándo se libera esa plaza. Una solicitud pendiente no se confunde con una reserva confirmada.
Para poder implementar y revisar ese recorrido hay que definir:
- Actores y permisos: visitante, cliente identificado y persona administradora; qué datos y operaciones puede ver cada uno.
- Acciones, datos y validaciones: consultar fechas, solicitar plazas, revisar o cancelar; qué información es obligatoria y qué entradas se rechazan.
- Reglas, estados y transiciones: cuándo una solicitud pasa de pendiente a confirmada o cancelada, quién lo autoriza y qué efecto tiene en la disponibilidad.
- Excepciones e integraciones: solicitudes simultáneas, información desactualizada, fallos de un servicio externo y responsabilidad de cada sistema sobre los datos.
- Criterios de aceptación: condiciones concretas para comprobar si el resultado cumple lo acordado, incluyendo lo que debe impedir.
Un requisito funcional describe una acción o comportamiento: cancelar una reserva y actualizar las plazas según las reglas. Un requisito no funcional establece condiciones de funcionamiento: rendimiento con el uso previsto, seguridad, accesibilidad, disponibilidad, privacidad, compatibilidad o facilidad de mantenimiento.
No basta con pedir «una web rápida y segura». Hay que concretar qué condiciones relevantes se comprobarán, con qué escenario y dentro de qué alcance. No todos los proyectos necesitan los mismos objetivos ni la misma documentación. Puedes profundizar en el análisis de requisitos de software si el encargo necesita esa definición previa.
- Resultado que revisar
- Un alcance funcional y criterios de aceptación que permitan revisar acciones, reglas y límites.
- Tu participación
- Confirmar qué debe ocurrir ante los casos normales y las excepciones; decidir qué es imprescindible.
- Qué puede condicionar el siguiente paso
- Reglas contradictorias, datos que faltan o dependencias externas sin definir pueden exigir aclaraciones antes de estimar o programar.
3. Diseñamos cómo funcionará la web
Diseñar es resolver tanto lo que una persona ve como lo que debe ocurrir detrás. Las dos partes responden a los requisitos y necesitan encajar.
Experiencia e interfaz
Ordenamos recorridos y pantallas, formularios, navegación y mensajes. Consideramos adaptación móvil, accesibilidad y estados de carga, error o ausencia de resultados. El usuario debe saber qué está pasando y cómo continuar.
Diseño técnico
Definimos componentes, datos y relaciones, reglas, identificación de usuarios y permisos. Cuando corresponde, también servicios, APIs, integraciones e infraestructura. La tecnología se elige por lo que necesita resolver, no se impone como punto de partida.
Ejemplo de reservas · hipotético. El recorrido conecta actividad, fecha, plazas y solicitud. El modelo debe relacionar esas entidades y determinar dónde se guarda la capacidad. La pantalla no debe anunciar una confirmación si el sistema solo ha registrado una petición pendiente.
Según el proyecto, el diseño puede apoyarse en prototipos, pantallas, modelos de datos o documentación técnica. No todos esos elementos forman parte de todas las entregas. El diseño de interfaces de usuario permite profundizar en la parte visual y de interacción.
- Resultado que revisar
- Una propuesta funcional y técnica suficiente para implementar el alcance acordado, con los artefactos que se hayan previsto.
- Tu participación
- Revisar el recorrido y las decisiones que afectan a la utilización o gestión de la web.
- Qué puede condicionar el siguiente paso
- Una limitación de la plataforma existente o de una API puede obligar a revisar una interacción o la distribución de responsabilidades.
4. Organizamos el desarrollo en fases y entregas
Ordenamos lo imprescindible, las dependencias y las revisiones necesarias. Un hito debe representar algo revisable, no solo una fecha en un calendario. Las responsabilidades y los criterios de aceptación ayudan a saber qué hace falta para avanzar.
- Alcance
- Qué funciones y resultados se construirán.
- Esfuerzo
- El trabajo necesario para construir y comprobar ese alcance.
- Plazo
- El tiempo transcurrido hasta la entrega, incluidas las dependencias y validaciones.
- Coste
- El importe de la propuesta y sus partidas, con las condiciones acordadas.
No son magnitudes equivalentes. Un cambio pequeño puede necesitar poco trabajo de implementación y quedar pendiente de que un proveedor habilite un acceso o de una decisión del cliente. Para la dimensión económica, consulta cómo calculamos el precio de una web a medida.
Ejemplo de reservas · hipotético. La primera versión podría recoger y gestionar solicitudes, con confirmación por una persona. La confirmación automática de plazas o una conexión de pagos pueden plantearse después. Hay que comunicar esa diferencia al usuario y no vender la primera fase como una reserva automática completa.
- Resultado que revisar
- Una planificación con prioridades, entregas revisables, dependencias y condiciones de ejecución acordadas.
- Tu participación
- Priorizar las funciones y designar quién revisa cada entrega o decisión.
- Qué puede condicionar el siguiente paso
- Accesos, datos, decisiones pendientes y disponibilidad para validar pueden condicionar el calendario.
5. Construimos y verificamos las funcionalidades
La implementación convierte las reglas y pantallas definidas en operaciones que funcionan juntas. La interfaz recoge y muestra información; la parte que la procesa debe aplicar permisos, validaciones y reglas, y guardar los datos cuando corresponde. Una restricción importante no puede depender solo de que un botón esté oculto en el navegador.
El control de versiones permite identificar cambios en el código. La revisión del código y las pruebas durante el desarrollo ayudan a detectar problemas antes de publicar. Las comprobaciones y las revisiones de entregas se adaptan al trabajo; no implican una auditoría independiente ni una metodología con reuniones o ciclos fijos por defecto.
Ejemplo de reservas · hipotético. Se implementan la consulta de disponibilidad y el registro de solicitudes para el alcance de esa entrega. Si la confirmación sigue siendo manual, se mantienen sus estados y permisos. Cuando se incorpore la asignación automática, habrá que comprobar capacidad y concurrencia en el punto que confirma la plaza, no solo al mostrar el calendario.
- Resultado que revisar
- Funciones implementadas y disponibles para revisión en el entorno previsto; las limitaciones de la entrega deben estar identificadas.
- Tu participación
- Probar los recorridos que afectan a tu actividad con ejemplos representativos y comunicar lo que no encaje.
- Qué puede condicionar el siguiente paso
- Una excepción descubierta al revisar puede necesitar una corrección o una decisión de alcance antes de continuar.
6. Comprobamos que la solución funciona correctamente
Que una pantalla se vea bien no demuestra que el proceso completo funcione. Las pruebas deben cubrir los recorridos y condiciones relevantes del encargo.
- Funcionales: comprobar las acciones y reglas especificadas.
- De integración: revisar la comunicación entre componentes o sistemas y la interpretación de sus respuestas.
- De permisos: verificar quién puede consultar datos o ejecutar operaciones.
- De errores y excepciones: revisar entradas incorrectas, interrupciones y servicios externos no disponibles.
- De aceptación: contrastar el resultado con los criterios acordados para la entrega.
Ejemplo de reservas · hipotético. Cuando exista confirmación de plazas, comprobar que no se supera la capacidad, incluso ante peticiones coincidentes. Verificar que una persona no ve datos privados de otra y que un reenvío accidental no duplica la operación. Si se añade un proveedor de pagos, comprobar cómo se trata una respuesta fallida o pendiente sin marcar una reserva como pagada por error.
También se revisan las condiciones no funcionales que se hayan acordado. El alcance y la evidencia de las pruebas dependen del proyecto: no se promete una cobertura universal ni auditorías externas incluidas por defecto.
- Resultado que revisar
- Evidencia de las comprobaciones previstas y una relación de incidencias pendientes, si existen, con su situación conocida.
- Tu participación
- Validar que los recorridos representan tu operación y contrastar los resultados con lo definido.
- Qué puede condicionar el siguiente paso
- Una incidencia que afecte a un criterio de aceptación puede impedir dar por lista esa entrega o requerir una decisión explícita.
7. Publicamos la solución y comprobamos su funcionamiento
Publicar es pasar de un entorno de desarrollo o pruebas a uno utilizado de verdad. Según el alcance, hay que preparar infraestructura, dominio y certificado, configuración, variables, credenciales, base de datos, migraciones e integraciones.
En una web nueva se prepara el inicio de la operación. En una web que ya tiene usuarios también hay que estudiar compatibilidad, conservación de datos y cómo se realizará el cambio. Las copias y los procedimientos de recuperación que correspondan deben permitir responder si algo no funciona como se esperaba.
Ejemplo de reservas · hipotético. Hay que revisar que la actividad y su capacidad estén configuradas en el entorno real, que las notificaciones lleguen al destino previsto y que las credenciales de pruebas no se confundan con las de producción. Se comprueba el recorrido de solicitud y, si están incluidos, la administración y los servicios externos.
Después del despliegue se realizan las comprobaciones acordadas y el seguimiento inicial que corresponda. No basta con que la portada cargue: deben revisarse las operaciones relevantes. La publicación de una modificación puede requerir una ventana de intervención; no se promete ausencia de interrupciones o riesgos.
- Resultado que revisar
- La solución publicada y comprobada conforme al alcance contratado, con el estado de las incidencias conocido.
- Tu participación
- Coordinar accesos autorizados, fechas de cambio y las comprobaciones de negocio que te correspondan.
- Qué puede condicionar el siguiente paso
- La disponibilidad de un servicio externo, un dato pendiente de migración o una restricción operativa puede condicionar la puesta en marcha.
8. Entregamos el proyecto y preparamos su continuidad
La entrega necesita identificar qué funciones se han completado y qué queda pendiente o fuera del encargo. También conviene dejar claras las condiciones de acceso, uso y continuidad.
- Accesos y credenciales necesarios, responsables de las cuentas y forma de transferencia.
- Código fuente específico, condiciones de titularidad y licencias aplicables.
- Dependencias, componentes y servicios de terceros que intervienen.
- Documentación de uso y documentación técnica previstas.
- Procedimiento de despliegue o mantenimiento cuando forme parte del alcance.
- Responsabilidades posteriores y condiciones de soporte o evolución.
Esto no significa que todo el código, la infraestructura o cualquier documento pertenezca automáticamente al cliente. Hay que distinguir los activos y entregables acordados de las herramientas de terceros y sus licencias.
Ejemplo de reservas · hipotético. La persona responsable debe poder identificar cómo se administran actividades y solicitudes, qué proveedor envía los avisos y quién mantiene la configuración. Los accesos y las instrucciones necesarias para continuar se concretan en la entrega.
Una solución mantenible debe poder comprenderse y evolucionar sin depender de decisiones que nadie pueda reconstruir. Puedes conocer cómo planteamos la responsabilidad técnica y la continuidad en dev2bit.
- Resultado que revisar
- Una entrega identificable y condiciones conocidas sobre accesos, entregables y continuidad.
- Tu participación
- Confirmar quién recibe y custodia los elementos de la entrega y qué responsabilidades asume.
- Qué puede condicionar el siguiente paso
- Accesos de terceros no transferibles o documentación fuera del alcance requieren aclarar cómo continuará la operación.
9. Mantenimiento y evolución después del lanzamiento
Después de publicar conviene distinguir cuatro tipos de intervención:
- Corrección de incidencias
- Resolver comportamientos incorrectos respecto al funcionamiento previsto.
- Mantenimiento preventivo
- Revisar dependencias, compatibilidad, seguridad y funcionamiento dentro del alcance acordado.
- Soporte
- Atender consultas y problemas de operación conforme al servicio contratado.
- Evolución funcional
- Incorporar capacidades que antes no formaban parte de la solución.
Ejemplo de reservas · hipotético. Una notificación que no se envía como estaba definido puede ser una incidencia. Añadir un segundo centro, nuevas reglas de disponibilidad o un medio de pago es una necesidad que habrá que analizar. No se decide su tratamiento solo por llamarlo «un cambio pequeño».
El lanzamiento no obliga a contratar nuevas funciones ni significa que estén incluidas. Revisar las necesidades según el uso permite decidir si una nueva intervención aporta valor. Las condiciones de cada actuación dependen del acuerdo correspondiente.
- Resultado que revisar
- El tipo de atención y las responsabilidades posteriores definidos; si se acuerdan ampliaciones, sus prioridades y alcance.
- Tu participación
- Comunicar incidencias con ejemplos y separar necesidades nuevas de lo que no funciona como se había previsto.
- Qué puede condicionar el siguiente paso
- Cambios de un proveedor, nuevas prioridades o dependencias de la solución pueden requerir revisar una intervención antes de ejecutarla.
¿Cuánto tiempo tarda el desarrollo de una web a medida?
La duración se estima al conocer el alcance, su complejidad y sus dependencias. No hay un plazo único que se pueda deducir del número de pantallas. Una función aparentemente sencilla puede depender de una API que todavía no está disponible.
Encargo A: registrar una solicitud
Un formulario con validación y almacenamiento exige definir los datos, controlar entradas, guardar la información y comprobar el recorrido. Si se incorpora a una web existente, también hay que revisar esa base.
Encargo B: operar una plataforma de reservas
Usuarios, pagos, disponibilidad, administración e integraciones añaden reglas, dependencias, permisos y escenarios de fallo. Hay más decisiones y recorridos que comprobar, aunque la pantalla de entrada pueda parecerse a la del formulario.
Para planificar es útil separar tiempo de trabajo, esperas por decisiones o recursos, pruebas y validación y tiempo hasta la publicación. Una entrega puede estar implementada y seguir pendiente de datos reales, de la revisión de un responsable o de una ventana para cambiar el sistema.
El grado de definición inicial, la documentación de las integraciones, los datos disponibles y la participación del cliente afectan al calendario. También las revisiones, los requisitos de prueba y las restricciones del entorno real. Identificar quién aporta cada elemento permite detectar qué puede bloquear la siguiente entrega.
Por eso la planificación debe hacer visibles hitos, dependencias y supuestos. Si cambian, se revisa su impacto. No publicamos aquí rangos temporales universales ni convertimos los plazos de un proyecto pasado en una promesa para otro.
¿Qué ocurre si cambian los requisitos durante el desarrollo?
Los cambios necesitan entenderse antes de clasificarlos. No todos son una ampliación ni todos son una corrección.
- Defecto: el resultado no cumple un comportamiento acordado.
- Aclaración: se concreta una interpretación que estaba pendiente o era ambigua.
- Nueva necesidad: aparece una capacidad que no se había definido.
- Cambio de alcance: se modifica lo que estaba previsto construir.
- Repriorización: se cambia el orden o la composición de una entrega.
Ejemplo de reservas · hipotético. Si se había acordado impedir superar la capacidad y el sistema lo permite, hay un incumplimiento del comportamiento previsto. Si ahora se quiere una lista de espera, hay que estudiar una función nueva. Decidir pasar esa función a la primera entrega puede requerir posponer otra y revisar sus dependencias.
Para decidir, contrastamos la petición con lo acordado y se valora qué afecta: reglas, datos, pantallas, conexiones, pruebas y publicación. Después se revisa su impacto en esfuerzo, presupuesto y plazo según las condiciones del proyecto.
No todos los cambios son gratuitos ni todos generan automáticamente un coste adicional. Mantener visibles los criterios de aceptación, las decisiones pendientes y los acuerdos evita dar por autorizada una modificación que cambia el resultado esperado.
¿Qué necesitamos de ti durante el desarrollo?
No tienes que convertirte en responsable técnico. Tu conocimiento del negocio permite resolver decisiones que el código no puede deducir: quién puede autorizar una operación, qué excepción es válida y qué necesita funcionar primero.
- Describir el problema y facilitar ejemplos reales, sin compartir datos innecesarios.
- Identificar a la persona que puede validar prioridades y entregas.
- Proporcionar los accesos autorizados y la información de las herramientas que deban conectarse.
- Revisar las decisiones y los recorridos relevantes, comunicando dudas o restricciones.
- Aclarar qué debe quedar resuelto para empezar a utilizar la solución.
Conviene acordar cómo se revisarán los avances para evitar instrucciones contradictorias o decisiones sin responsable. La frecuencia y el formato se adaptan al trabajo, sin imponer un calendario fijo por defecto.
Si todavía estás preparando la contratación, la guía qué necesitas para encargar tu web a medida ayuda a ordenar la información inicial. Esa guía trata la preparación del encargo; aquí explicamos lo que ocurre durante su ejecución.
Preguntas frecuentes sobre el proceso de desarrollo web
¿Necesito tener todos los requisitos definidos antes de contactar?
No. Puedes empezar explicando el problema y aportando ejemplos. Habrá que concretar lo necesario antes de comprometer una entrega; la definición previa y sus condiciones se acuerdan según el caso.
¿Puedo ver avances antes de terminar el proyecto?
Se pueden plantear entregas revisables que permitan comprobar recorridos y decisiones antes de la publicación. El entorno, los hitos y la forma de revisión se concretan para el encargo.
¿Puedo comenzar con una versión reducida?
Sí, si resuelve un recorrido operativo completo. Lo que se pospone debe quedar identificado para no presentar una función parcial como si ya estuviera terminada.
¿Se puede desarrollar sobre una web existente?
Puede ser viable ampliar la base actual. Antes hay que revisar compatibilidad, código, accesos y dependencias, y prever cómo comprobar que se conserva lo que ya funciona.
¿Qué sucede cuando aparece una funcionalidad nueva?
Se analiza su relación con el alcance y su impacto antes de acordar la intervención. También puede cambiar la prioridad de otras funciones, sin que eso garantice que el esfuerzo total sea el mismo.
¿Cómo sé que el desarrollo cumple lo acordado?
Los criterios de aceptación permiten contrastar acciones, reglas y límites. Las comprobaciones previstas y el estado de las incidencias deben permitir revisar el resultado sin depender solo de una impresión visual.
¿Quién se encarga del mantenimiento después?
Las responsabilidades y la cobertura deben quedar acordadas. La entrega inicial no implica que cualquier soporte o ampliación posterior esté incluido ni que debas contratar nuevas funciones.
Cuéntanos qué necesitas desarrollar
Puedes llegar con una especificación preparada o con una necesidad que todavía no sabes convertir en funciones. Empezamos por entender qué debe quedar resuelto y qué información falta para definir el encargo.
Conoce a Francisco Javier Bohórquez Ogalla, responsable técnico de dev2bit. También puedes llamar al 605 639 721 o escribir a info@dev2bit.com.