Visita también BootStudio, nuestra consultoría de diseño de experiencias de usuario.

Las 5 fases de los proyectos web: Estabilización y Lanzamiento

30 de Septiembre, 2008 3 comentarios

Server FarmEn esta serie hemos visto ya las primeras tres fases del proceso que usamos en BootStudio para producir sitios web: Negociación, Diseño, e Implementación. Si no lo has hecho todavía, recomiendo que leas esos artículos ahora.

Una vez que hemos completado el diseño y producción del sitio, estamos listos para publicarlo de forma que pueda ser utilizado por sus audiencias meta. Esto lo hacemos en la cuarta fase del proceso, que veremos a continuación.

Fase 4: Estabilización y Lanzamiento

El sitio está terminado. El equipo de producción ha eliminado los errores de contenido, ajustado el diseño, y corregido inconsistencias entre los diferentes componentes del sitio. El cliente ha probado (y aprobado) el sitio en el ambiente de pruebas, y se siente contento con el resultado. Es hora de hacer el sitio público. (O en caso de un sitio para uso interno, publicarlo para que pueda ser utilizado por los miembros del equipo del cliente.)

La complejidad de este proceso de “puesta en producción” depende enteramente de la sofisticación del proyecto: si se trata de un sitio web estático y pequeño, el proceso es relativamente sencillo. Por el contrario, si se trata de un sitio que corre sobre un sistema de gestión de contenido, o de una aplicación web que hace uso de bases de datos o que emplea conexiones con otras aplicaciones, el proceso es mucho más delicado y complejo.

Para los propósitos de este artículo, vamos a ver cuatro componentes del proceso de lanzamiento que son aplicables a todos los proyectos:

  1. Preparación del ambiente de producción
  2. Publicación del sitio a producción
  3. Pruebas del sitio en producción
  4. Cierre del proyecto

Preparación del ambiente de producción

Como mencioné en mi artículo anterior, desarrollamos los sitios en servidores dedicados específicamente a este propósito. Los clientes tienen acceso a estos servidores, pero saben que son una residencia temporal de sus sitios y que al final del proyecto va a tener que migrarse a un ambiente de producción que cumpla con las necesidades de disponibilidad y rendimiento que requieren. El objetivo de la preparación del ambiente de producción es lograr que éste se parezca lo más posible al ambiente de desarrollo/pruebas en que el cliente aprobó el sitio, y evitar sorpresas al momento de publicar.

BootStudio no cuenta con servidores de producción propios. Como hacen muchas otras consultorías de experiencia de usuario, empleamos los servicios de proveedores dedicados a servicios de hospedaje. (Además, muchos de nuestros clientes cuentan con ambientes de hospedaje propios.) Los servidores de hospedaje de estos proveedores por lo general proveen todo lo necesario para hospedar el sitio, sin requerir mucha configuración adicional. Sin embargo, para muchos sitios es necesario preparar el servidor de hospedaje para que pueda recibir y hospedar el sitio terminado. En el caso más sencillo, esta preparación consiste en configurar los servidores de DNS para que el dominio (o dominios) requeridos para el sitio apunten al servidor de hospedaje. En casos más complejos, la preparación puede incluir la instalación y configuración de bases de datos, configuraciones especiales en el servidor web, la revisión de servicios para envío de emails a través de los formularios de contacto del sitio, etc.

Publicación del sitio a producción

Una vez que el ambiente de producción está listo para recibir al sitio, copiamos los archivos del servidor de desarrollo al servidor de producción. Este quizás es el paso más sencillo en todo el proceso, por lo que no voy a entrar en detalles al respecto. Sin embargo, cabe resaltar que en muchos casos es deseable publicar una página de inicio temporal en la raíz del sitio para avisar a los visitantes que el sitio está atravesando cambios, y pedir disculpas por las molestias. Esto es especialmente importante cuando se trata de un rediseño a un sitio existente; dado que es un sitio que ya es conocido y está siendo utilizado, los visitantes del sitio van a ver anormalidades mientras transcurre la publicación de los nuevos documentos del sitio. (En casos extremos, es deseable publicar el sitio en un servidor de producción alterno, y cambiar los DNS para que apunten al nuevo sitio. De esta forma se reducen aún más las inconsistencias y errores que perciben los usuarios.)

También debemos notar que antes de publicar el sitio nuevo es ideal analizar las bitácoras de uso del sitio (en caso de que se trate de un sitio existente) para buscar las horas de menor actividad de los visitantes. Obviamente, es deseable publicar los cambios cuando haya la menor cantidad de visitantes en el sitio. En muchos casos, esto ocurre durante el fin de semana, particularmente los domingos después del medio día, por lo que este es un momento propicio para publicar.

Pruebas en el ambiente de producción

Una vez que el sitio nuevo se encuentra en el ambiente de producción, es recomendable hacer una última ronda de pruebas. Lo más probable es que el contenido no haya cambiado, por lo que los errores en el texto ya no deben ser un problema. Sin embargo, puede que se hayan colado otros errores; el más común que hemos visto son las imágenes con llamados al directorio original en el servidor de desarrollo. En estos casos, las imágenes aparecen rotas en el servidor de producción. Esto es fácil de corregir.

Es importante también probar los aspectos funcionales del sitio. Por ejemplo, los formularios de contacto a veces no funcionan en el ambiente de pruebas exactamente igual que lo hacían en el ambiente de producción. Es deseable hacer pruebas para confirmar que los destinatarios de los emails los estén recibiendo sin problemas. Éste también es un buen momento para hacer los ajustes finales al sitio. Un ejemplo común es la adición del llamado a Google Analytics en las páginas para recoger estadísticas sobre el uso del sitio.

Cabe mencionar que es ideal hacer estos cambios y mejoras finales antes de quitar la página de inicio temporal que recomendamos en la fase anterior. Queremos que cuando los usuarios vean el sitio por primera vez lo encuentren tan perfecto como es posible, y si todavía estamos haciendo cambios al contenido en producción esto puede dar una mala imagen.

Cierre del proyecto

Por fin hemos terminado, ¡es hora de celebrar! Pero antes, es importante dar cierre formal al proyecto. Es saludable para los miembros del equipo del proyecto—incluyendo a los miembros del lado del cliente—tener una breve ceremonia de cierre que ayude a todos a resumir lo que han atravesado, los retos que se han vencido, y lo que se ha logrado. Esto no tiene que ser muy formal, pero es preferible hacerlo en persona; basta con organizar una reunión para hacerlo.

Desafortunadamente, no siempre es posible hacer una ceremonia de cierre. Sin embargo, es altamente recomendable, y no solo porque ayuda a dar cierre al proyecto: hay muchas actividades que van a requerirse en el sitio después de la puesta en producción, y es importante que todos los miembros del equipo—y en especial, el cliente—sepan cuáles son los siguientes pasos. Esto es lo que vamos a ver en el siguiente artículo en esta serie.

Comparte este post:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • email
  • StumbleUpon
  • Twitter

3 Comentarios

[...] con un sitio web prístino, listo para ser visto en público por primera vez. En el próximo artículo en la serie vamos a ver cómo [...]

[...] Estabilización y Lanzamiento [...]

[...] cubierto las primeras cuatro fases: Negociación, Diseño, Implementación, y Estabilización y Lanzamiento. Si no lo has hecho todavía, recomiendo que leas esos artículos antes de [...]

Deja un comentario

Requerido

Requerido y oculto

Estás en Infotectura, un blog sobre diseño de experiencias de usuario, arquitectura de información, diseño de interacción, y usabilidad.

Acerca del sitio | Archivos