Como Consultor de Marketing Online, una de las tareas que más veces realizo al cabo del año, es la gestión completa de un proyecto web, de principio a fin. Al principio solía hacerla de forma natural, según me iba guiando el sentido común, pero a medida que he ido realizando los proyectos (y llevo ya más de 250), he ido estandarizando o profesionalizando la metodología.
En este post me propongo hacer un breve resumen de cada punto, para compartir con todos aquellos profesionales a quienes les pueda interesar, y ya de paso para mis futuros clientes, para que sepan dónde se meten ;). Ahí va:
Captación
Podríamos decir que la captación es el proceso más largo, pues nunca se acaba. Básicamente se refiere a todas aquellas acciones que se realizan para conseguir captar un contacto comercial. Desde una campaña de AdWords o Facebook, hasta un anuncio en una revista, pasando por un post (como este mismo) o incluso ir a algún congreso a hablar de Marketing Online. Todo puede ser una acción que genere un contacto. Se trata de plantar semillas constantemente, porque nunca sabes cual germinará. Así pues, este punto se realiza constantemente, hasta el infinito y más allá.
Preventa
La preventa viene a ser el diálogo inicial con el contacto. Es un feedback inicial en el que se tantea la posibilidad de hacer un proyecto. Más del 90% de mis contactos son a través de correo. El resto suele ser por casualidades varias, y de estar en el lugar adecuado en el momento adecuado. Así que normalmente la preventa se realiza a través de mail o con una llamada telefónica. El objetivo de la preventa es saber si se puede realizar lo que pide el cliente, y si el cliente está dispuesto a aceptar tus servicios.
Hablando en plata, viene a ser algo así:
-Me interesa hacer un proyecto que bla, blah, y [···] blah. ¿Tu podrías?
-¡Pues claro! ¿Te hago una propuesta?
-Pos vale.
-Pos malegro.
Entonces me pongo manos a la obra, para pasar al siguiente punto, imprescindible y vital. La propuesta.
Propuesta
Como digo, la propuesta es un punto importantísimo. De hecho, es uno de los puntos claves para llevar a cabo el proyecto con éxito. La verdad es que merece un post aparte (lo haré en breve y en cuanto lo tenga lo enlazaré aquí). Pero para hacernos una idea, lo más importante que debe incluir una propuesta, es lo siguiente:
Análisis de requerimientos
Un listado completo, exhaustivo y detallado de todo lo que debe tener la web. Páginas estáticas, blog, formulario de contacto, registro para los usuarios, panel de control, funcionalidades, idiomas, escabalilidad, tecnología utilizada, compatibilidad para tablets o teléfonos, etc. Como digo, esto puede ser muy extenso, pero lo más importante es hacer un listado para evitar confusiones. Esto es importante para la tranquilidad del desarrollador (para que el cliente no le exija cosas nuevas dentro del presupuesto acordado) y la del cliente (que puede temer que se le cobrará por cosas que entendía ya incluidas).
Timing
Esencial. Se debe indicar al cliente el tiempo necesario para el desarrollo del proyecto. ¡Atención! Eso no quiere decir que se tengan que poner fechas concretas. Nunca se deben poner fechas concretas absolutas (p.e. 6 de Agosto) sino fechas relativas (dos meses). Esto lo recomiendo así, porque en caso que se demore la fecha de inicio del proyecto o se interrumpa por causas ajenas (por ejemplo que el cliente no entregue el contenido), después no se reclame un incumplimiento de la propuesta.
Precio
Queda claro. El precio del proyecto. A mi me gusta desglosarlo en varias partidas, ya que cara al cliente queda más justificado el porqué de ese importe. Tampoco hace falta desglosar a niveles atómicos, pero si al menos las partidas más básicas, a saber: Diseño, programación, gestión de proyecto y marketing online. Algunas veces si hay algún requerimiento especial (pasarelas de pago, foros, intranets, y otras) las desgloso también, para indicar la importancia que tienen dentro del cómputo global.
Facturación (primer pago 50%):
Esto ya es un estándar en el sector (y en muchos otros). El cliente deposita su confianza en ti, y te adelanta el 50% del pago. Y al final del proyecto, tu depositas tu confianza en él y entregas el proyecto completo, para que el pague el resto.
Si bien es cierto que en la mayoría de proyectos es así, hay algunos casos (proyectos muy complejos, que pueden llevar varios meses) en los que vale la pena establecer varias fases e ir liquidando cada una a medida que se cumplen. Incluso podrían ser las indicadas en la propuesta. Por ejemplo diseño, programación, fase de pruebas y lanzamiento. Cuatro fases en la que se podría liquidar el 25% en cada una.
Diseño
El diseño se realiza en dos fases:
Esbozos o wireframes
Consiste en un boceto rápido de la estructura de la web. Donde va el logo, el encabezado, el pie de página, las divisiones de contenido principales, etc. Se realiza un esbozo para cada página "modelo". Por ejemplo la página inicial tendrá su aspecto, la página del blog otro, las páginas internas otro, y seguramente las categorías o la página de contacto, otro. Se presenta un esbozo por cada página "modelo" para que el cliente la apruebe.
Es importante destacar que no hay vuelta atrás. Una vez se ha aprobado el wireframe y se está trabajando con el PSD (punto siguiente) ya no se puede volver atrás y cambiar el wireframe de nuevo. En caso que sucediera eso, se debe considerar algo fuera del proyecto y no debe computar ni por presupuesto ni por timing. Lo que suelo hacer para que el cliente sea consciente de esto, es hacerle firmar los bocetos. De esta forma, con el simple hecho de hacerle firmar algo, se "despierta" y se da cuenta que está tomando una decisión. Decisión tomada, no hay vuelta atrás.
Diseño PSD
Una vez aprobado el wireframe, pasamos a "llenar los cuadrados". Lo que haremos es realizar un PSD con una simulación final de la web. O sea, una especie de "foto estática", como si se tratara de una captura de pantalla, para que el cliente sepa como va a quedar la web vista en el navegador. Una vez aprobados (y evidentemente firmados), pasamos al desarrollo.
Desarrollo
Llegamos ya a la parte más divertida. Consiste en a programar todo el HTML y CSS para darle vida al diseño aprobado. Hay un par de opciones para esta fase. Se puede realizar en un servidor local (en el propio ordenador del programador), o en un servidor de pruebas accesible sólo mediante usuario y contraseña, para que únicamente lo pueda ver el cliente. Así de paso nos aseguramos que Google no indexe nada.
Yo personalmente prefiero trabajar en un servidor de pruebas, ya que facilita mucho más el feedback con el cliente, pues puede verlo desde su oficina, desde casa o incluso desde su tablet o teléfono. Pero para gustos, los colores.
A medida que vamos programando la web, tenemos que poner contenido "relleno". Hay la opción de usar un "Lorem Ipsum" cualquiera, pero yo prefiero empezar a trabajar en este punto con el contenido del cliente. Ese es precisamente el siguiente punto.
Contenido
Este punto es muy delicado, controvertido, y en ocasiones es el que más suele demorar el proyecto. ¿Por qué? Pues porque requiere de trabajo por parte del cliente, ya que nos debe facilitar el contenido. Sus textos, imágenes, vídeos, PDFs, etc. En fin, todo lo que quiere que aparezca en la web.
Si se trata de un proyecto de rediseño no hay tanto problema, pues podemos acceder al contenido de la web anterior, y lo vamos "migrando" poco a poco, y añadiendo algún punto en el caso que sea necesario. Pero si se trata de un proyecto nuevo, y no lo tienen redactado, esto puede ser el parto de la burra.
Es el cliente el que debe facilitar el contenido. En ningún caso el diseñador o el programador. Después de todo, ¿quién mejor que el cliente puede describir su empresa, sus productos, o su misión? ¿Como va a saber eso el diseñador?
En el caso que el cliente no tenga ni un triste documento, o lo que tiene no sea aprovechable, y no sepa por dónde empezar, lo que suelo hacer es ofrecerle un redactor profesional para que le escriba todo el contenido. Conozco a varios con los que suelo trabajar, y en función del cliente y del contenido, aconsejo al más apropiado. Éste se encarga de hablar con el cliente, entrevistarlo, y redactar los textos apropiados. Incluso si hace falta, buscará las imágenes de archivo correspondientes o tomará las fotografías necesarias.
Fase de pruebas
Bueno, pues ya tenemos la web diseñada, programada y llena de contenido. Ya podemos abrir la fase de pruebas. Básicamente consiste en dar acceso a la web a un grupo reducido de personas de confianza (normalmente trabajadores de la propia empresa, familiares, clientes especiales, etc.) para que la prueben y trasteen, en busca de bugs, incompatibilidades o posibles mejoras.
Durante la fase de pruebas suelen salir muchas ideas nuevas y propuestas, que no estaban reflejadas en ninguno de los puntos anteriores. Eso suele pasar porque los beta testers dan su opinión y hacen sugerencias. Debemos ser fuertes y no caer en la tentación de modificar nada. La fase de pruebas es sólo una caza de posibles bugs, errores, incompatibilidades con navegadores, etc. En ningún momento es para añadir novedades o modificar características funcionales ni de diseño.
Lo que si podemos (y debemos) hacer es un listado de todas esas sugerencias, por si en una segunda fase de modificaciones posteriores, o de mantenimiento (último punto), al cliente le interesa llevar a cabo. En el caso que sea imprescindible, se puede incorporar con un presupuesto y timing aparte.
Facturación (segundo pago 50%)
Pues simple y fácil, el cliente paga el resto del proyecto. Como ya he indicado antes, este pago puede ser del 50%, o del valor restante en función de los pagos ya realizados anteriormente, en el caso de grandes proyectos planteados por fases.
Lanzamiento
¡Día de alegría, nervios y botellas de cava estrelladas contra la proa del barco! El proyecto se abre al público, así como todas las posibles acciones comerciales ligadas al mismo. Campañas publicitarias, redes sociales y medios de comunicación. ¡Todos a celebrar que ya se puede acceder!
Es importante no hacer estos lanzamientos un viernes por la tarde si no vamos a estar el fin de semana "de guardia", por si algo se tuerce. En el caso que tengamos un servicio de 24x7 no hay problema, pero mejor asegurarnos.
Si el lanzamiento requiere de una migración del servidor de pruebas al de producción, este se debe realizar con anterioridad, para evitar problemas técnicos. Lo mejor es tener el proyecto funcionando en el servidor final un par de días antes, para curarse en salud. Y más en el caso que haya DNS de por medio, que todos sabemos que son un pain in the ass.
Mantenimiento
Opcionalmente, el cliente puede estar interesado en contratar un servicio de mantenimiento posterior al lanzamiento. Es muy importante diferenciarlo del soporte técnico que se ofrece como servicio post venta ya incluido en el proyecto. O sea, no es lo mismo que se descubra un bug que no se había detectado en la fase de pruebas, que el cliente quiera añadir una nueva funcionalidad. Este punto debe quedar muy claro en la propuesta, para no tener ningún malentendido.
Consideraciones finales
Así es como yo desarrollo mis proyectos de principio a fin. Es solo mi forma de trabajar, fruto de mi experiencia. Como he dicho inicialmente, lo he ido modificando y construyendo año tras año, proyecto tras proyecto. ¡Y a mi me funciona muy bien! A medida que vaya incorporando novedades modificaré este post para que esté siempre al día. De este modo también podré utilizarlo como guía para mis ponencias, clases o clientes.
Pero cada maestrillo tiene su librillo, o sea que soy consciente que no es el único modo de trabajar, ni seguramente perfecto (si es que existe alguno que lo sea). O sea que estoy abierto a preguntas, ideas y sugerencias que podéis dejar en los comentarios o que podéis enviarme por correo.
¡Nos vemos!