Infotectura

Las 5 fases de los proyectos web: Implementación

25 de Septiembre, 2008 5 comentarios

Como vimos en los artículos anteriores, los proyectos web que desarrollamos en BootStudio atraviesan un proceso de cinco fases. Hemos visto ya la primera fase (“Negociación”) y la segunda (“Diseño”). Si no lo has hecho todavía, recomiendo que leas estos artículos para ver el contexto completo del proceso.

En la fase anterior, vimos que el diseño abarca mí¡s que las visuales del proyecto: también incluye la estrategia de diseño y la arquitectura de la información del sitio. Una vez que el cliente se siente satisfecho con el diseño de estos componentes, podemos comenzar la implementación del sitio.

Fase 3 — Implementación

La implementación no es más que la creación de los elementos—textos, código, visuales, etc.—que van a formar parte del sitio una vez que se encuentre en producción. O sea, dejamos atrás la parte especulativa del proyecto (el diseño), y nos movemos a la creación del producto final: un sitio o aplicación web.

Esta es la parte del proceso que más varía entre proyectos: algunos sitios son más grandes que otros, algunos son totalmente dinámicos (por ejemplo, corriendo sobre un framework o sobre un sistema de gestión de contenido), otros son muy sencillos, con páginas estáticas. En algunos casos, nuestro entregable ni siquiera es un sitio web terminado, sino plantillas XHTML/CSS para ser implementadas por terceros sobre una aplicación web.

Voy a presentar aquí algunos de los retos que tienen en común los diversos tipos de proyectos, y algunas de las técnicas que usamos para manejarlos. Sin embargo, prestaremos particular atención a los sitios ricos en contenido, ya que estos parecen ser los más comunes. Vamos a enfocarnos en las siguientes actividades:

1. Crear un ambiente de desarrollo y un ambiente de pruebas
2. Compilar el contenido que va a ser publicado en el sitio
3. Crear los componentes del sitio
4. Hacer pruebas del sistema

Cabe mencionar que estas fases normalmente no ocurren concurrentemente: en la mayoría de los casos todas estas funciones se llevan a cabo en paralelo (con la excepción de las pruebas, que suelen ocurrir al final de la fase). Sin embargo, es más fácil estudiarlas independientemente.

Crear ambientes de desarrollo y pruebas

El web es uno de los medios de colaboración más efectivos que existen. (De hecho, fue creado por Tim Berners Lee para ese propósito.) Es muy fácil para un equipo de personas crear documentos, imágenes, código, etc. y compartirlos remotamente. Sin embargo, esta ventaja conlleva un riesgo: el potencial de desorden. De no tener estándares y estructuras para facilitar la colaboración, los diferentes miembros del equipo rápidamente pueden ir—cada uno por su cuenta—y duplicar trabajo, o peor aún, asumir que otros están haciendo las tareas que les corresponden a ellos.

Otra complicación es que los equipos web producen una cantidad prodigiosa de artefactos: documentos HTML, archivos FLA, PNG, PSD, etc., todos conteniendo diferentes elementos clave del proyecto. —¿Qué ocurre cuándo un miembro del equipo necesita información que se encuentra en un documento producido por otro miembro del equipo? —¿Cómo sabe dónde encontrarlo?

En BootStudio hemos intentado resolver estos problemas de dos formas. Primero, hemos contratado una cuenta en Basecamp, una aplicación web que permite a equipos colaborar en proyectos. Esta es la cuarta herramienta de este tipo que hemos usado, y después de muchos años de estar buscando nos parece la mejor. (La principal desventaja es que no provee un interfaz en español. Muchos de nuestros clientes saben leer inglés, pero sospecho que puede ser un problema para otros equipos en países hispanoparlantes.)

Lo segundo que hicimos fue instalar una pequeña finca de servidores en nuestra oficina que nos permite guardar copias de respaldo de los materiales de trabajo de los proyectos (PSDs, imágenes originales, documentos Word, etc.) y hospedar versiones de prueba de los proyectos en que estamos trabajando. La versión más reciente de los proyectos siempre está en estos servidores, y todos los directorios comparten una nomenclatura similar. De esta forma, todos los miembros del equipo saben dónde están las cosas, y cuáles son las versiones más recientes.

Compilar el contenido del sitio

San Francisco de Asis rezaba la siguiente plegaria:

Señor, dame la fortaleza para cambiar las cosas que puedo cambiar, la paciencia para tolerar las cosas que no puedo cambiar, y la sabiduría para distinguir la diferencia.

—¡Quizás San Francisco hubiera sido un excelente productor web! El proceso de implementación requiere grandes cantidades de las tres características. La compilación del contenido—obtener las imágenes y textos que van a aparecer en el sitio—es una de esas actividades que requiere fortaleza, paciencia, y la sabiduría para saber cuándo emplear una o la otra. Esta es, si duda, una de las tareas más difíciles de estimar, y por ende, que más atrasa los proyectos.

La mayoría de las veces, asumimos que el cliente va a producir el contenido. (De hecho, la mayoría de los clientes también parecen asumir que esto les corresponde a ellos.) Sin embargo, escribir textos efectivos y producir visuales atractivas no es una tarea para la que tienen aptitud la mayoría de las personas.

Siempre que es posible sugiero a los clientes que contratemos los servicios de profesionales que se dediquen específicamente a estos rubros. Una escritora profesional (especialmente una con experiencia escribiendo para web) va a producir textos mucho mejores que uno de los miembros del equipo del cliente. Lo mismo ocurre con las fotografías: un fotógrafo profesional va a tomar mejores fotos que una persona para quién la fotografía es un mero pasatiempo. (Cuando un cliente me dice —yo tomo las fotos—, es una señal de alarma de que el proyecto va a tener problemas de calidad—a menos que se trate de un sitio web para un fotógrafo profesional, por supuesto.) Las traducciones son otro elemento que puede, y debe, ser subcontratado a profesionales dedicados.

La realidad es que, por más buenos escritores, traductores o fotógrafos que sean los miembros del equipo del cliente, cada uno de ellos va a tener otras responsabilidades más prioritarias que la producción del sitio web. La mayoría de los atrasos que hemos visto en proyectos de este tipo se han dado por atrasos en la producción de los contenidos. —¿Porqué introducir este riesgo al proyecto cuándo son funciones que fácilmente se pueden delegar?

El rol de nuestro equipo en estos casos consiste en coordinar a los diversos escritores, traductores, diseñadores visuales, fotógrafos, etc. para que produzcan 1) los contenidos que requiere el sitio, con el enfoque indicado por la estrategia de diseño, y 2) que lo hagan dentro del tiempo requerido para cumplir con las fechas de entrega del proyecto.

Crear los componentes del sitio

Una vez están terminados los contenidos, el equipo de producción debe armarlos para que puedan ser presentados en navegadores web. Esto requiere la conversión de los diversos medios a XHTML/CSS, imágenes, elementos Flash, etc.

Esta es la parte del proceso más comúnmente percibida como —armado de páginas web—, y seguramente es la que mejor conoces, por lo que no voy a ampliar mucho sobre el tema. Solo basta con mencionar que en BootStudio intentamos crear sitios que emplean estándares con código estructurado. (En mi opinión, la más clara señal de incompetencia en esta industria son los layouts hechos con tablas en vez de elementos sintácticos y CSS.) Existe amplia documentación en el web sobre los estándares web, recomiendo que leas A List Apart para más información sobre el tema.

Pruebas del sistema

Al final del proceso, contamos con un sitio web que está casi listo para entrar en producción. Pero casi listo no es lo mismo que listo: todavía existen en el sitio errores ortográficos, vínculos rotos, imágenes con las dimensiones equivocadas, elementos Flash sin alternativas para navegadores sin Flash, etc.

Además, una vez que el sitio está armado, el cliente está en una mejor posición de juzgar si cumple con sus objetivos. Es normal que el cliente solicite cambios a los textos y a algunas imágenes durante esta fase del proceso. No es normal que pida cambios radicales a la presentación del sitio en esta parte del proceso: si lo hace, es porque algo no quedó claro en la fase 2. Cambios grandes al diseño o estructura del sitio en esta fase pueden ser catastróficos y atrasar el proyecto considerablemente.

Eso dicho, la mayoría de los cambios no son tan complicados: eliminar una oración aquí, corregir un error ortográfico acá, etc. Estos cambios pueden ser hechos fácilmente por el equipo de producción, pero es importante saber poner límites al proceso: si después de varias semanas todavía se están haciendo cambios considerables a los contenidos del sitio, algo está mal. Quizás sería mejor en ese momento hacer pausa y consultar con los autores del contenido para ver si es necesario crear textos o imágenes completamente diferentes.

El riesgo más grande que tienen los equipos web en esta parte del proceso es no estimar tiempo suficiente de antemano para hacer las pruebas. Los clientes siempre tienen urgencia para lanzar el proyecto, y las pruebas son la tarea más fácil de eliminar para”ahorrar tiempo”. Creo que tendemos a ser optimistas, y pensamos que podemos prescindir del tiempo que requieren las pruebas. ¡Es un error! Las pruebas van a ocurrir aunque no lo queramos; es más saludable tomarlas en cuenta desde el comienzo del proyecto.

Una vez terminadas las pruebas, contamos 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 hacerlo.