Proyectos web: qué falla cuando falta una estrategia compartida

La historia del desarrollo web está plagada de fracasos absolutos, a saber:

• Proyectos web de dos meses que tardan dos años en publicarse
• Sitios web que jamás ven la luz
• Páginas web que tras publicarse nadie visita
• Sitios web que parecen hechos en los años 80, pero tienen… ¿un timeline de facebook?

De hecho, podría arriesgarme a decir:

Según un estudio de la universidad de New Develdong realizado por el doctor Kevin C.I. el 98.53% de los directores de marketing han sufrido al menos dos experiencias traumáticas durante el desarrollo de un sitio web.

Aunque el estudio es un fake de principio a fin, seguro que no estaría para nada desencaminado y más de uno se sentirá totalmente identificado. Y esto es lo realmente triste y peligroso.

Triste, porque personalmente me genera un profundo pesar ver que tanto esfuerzo por todas las partes implicadas (los clientes, los project, diseñadores, programadores…) quede absolutamente desvirtuado y devaluado.

Y peligroso porque genera una desconfianza sobre los programadores que ya ha llegado a niveles tales que por el hecho de aparecer un programador se levanten todas las alertas tanto en los clientes como en los diseñadores, projects, etc.

O sea: tanto los clientes como los propios compañeros (ya sean de trabajo o de viaje) de los desarrolladores. Y esto último es una realidad del día a día… muchísimas veces he escuchado en el pasado la frase:

«queremos hacer X, pero si hay forma de hacerlo sin desarrollo»

Si se pregunta a los programadores sobre este tema, muchos comentarán que el problema está en que aquí se mete a hacer webs cualquiera, etc etc. En mi casa a eso lo llamamos «echar balones fuera». Aquel que es un mal profesional acaba cayendo por su propio peso, el problema no es de «los otros» o de «los intrusos».

El problema es siempre, y recalco el siempre, el mismo: No existe ninguna estrategia para el proyecto web y lo que es peor… se la inventa el programador.

Desde hace unos cuantos años que llevaba madurando una idea: Todos los desarrollos en los que formaba parte activa partían con el mismo error de base. En los últimos meses esta idea se ha transformado en una certeza absoluta. Creo que puede resumirse en: independientemente de que tu sitio web sea corporativo, un ecommerce o un «simple» blog tienen que existir unos objetivos claros que justifiquen su creación, de modo que todo el sitio web esté hecho por y para esos objetivos. Lamentablemente casi nunca es así, y por eso existe tanta frustración y fracaso en los desarrollos web.

Esta realidad tiene que cambiar sí o sí por el bien de todos, hay que olvidarse de las viejas costumbres que sólo nos llevan a equivocarnos una y otra vez. ¿viejas costumbres? Venga, para que quede nítido y cristalino comentemos «brevemente» el viejo proceso de creación, las «teóricas soluciones» (fracaso absoluto y seguro) y cómo lo estamos solucionando en Roi Scroll, porque sí, este problema lo estamos trasladando a un problema del pasado.

Nace la idea

Un día, a una empresa de marketing digital le llega un cliente pidiendo que le hagan un site corporativo. El departamento de cuentas empieza a trabajar en la propuesta, total es una web ¿molestar al equipo para eso? por favor… si fuera otra cosa, pero ¿hacer webs? bah, eso ni se pregunta.

Arranca el proyecto

El cliente da el OK y comienza el proyecto. Aquí se abren dos posibilidades:

1. Existe departamento de desarrollo.
2. No existe departamento: Tenemos que subcontratar el desarrollo.

Tenemos departamento de desarrollo

El chico de cuentas, todo feliz él, coge al primer desarrollador que pasa cerca de él y le cuenta la noticia «tío, te he conseguido una web, sencillita, en una semana te la sacas fijo». Comienzan los problemas.

El programador, que ya sabe de qué va el tema pregunta:

1. ¿cual es el objetivo de la web?
2. ¿qué secciones tiene?
3. ¿qué hay dentro de cada sección?
4. ¿hay área privada?
5. ¿lo gestionan ellos?
6. ¿cual es su logo?
7. ¿qué webs le gustan?
8. ¿cuales son sus colores corporativos?
9. ¿hay videos?
10. ¿descargas?
11. ¿quien crea los contenidos? (la pregunta del millón de dólares)

El chico de cuentas, un poco menos feliz, contesta:

1. aparecer en Internet
2. ¿eso no lo dices tú?
3. ¿eso no lo dices tú?
4. no sé, tú sabrás
5. si no lo vas a hacer tú, pues deberían…
6. creo que lo tienen en su Facebook
7. ¿esto te hace falta? bueno, le pregunto
8. ¿para qué?
9. no sé, tu dirás
10. no sé, tu dirás
11. hombre, los crearás tú ¿no?

La felicidad se esfuma en menos de un segundo, al final el chico de cuentas parece que ha envejecido 20 años de golpe y se va con la libreta llena de cosas que preguntar al cliente.

Tenemos que subcontratar el desarrollo

Alguien podría pensar que claro, esto ocurre porque los programadores son unos vagos, que lo único que quieren es jugar con sus pantallas «matrix»

Sí… piensan que esto es jugar

Lo subcontratamos y que otros se coman el marrón de pegarse con los programadores.

Así que, se busca una empresa de desarrollo para ello, pero amigo… te piden un documento de requisitos dónde dejes descrito todo, absolutamente todo, lo que va a llevar la web. Pero no sólo eso, sino que también te piden que exista un diseño por cada una de las pantallas del sitio web ¿por cada una? sí, por cada una.

Y aquí entra lo que llamo «complejo de IKEA» porque te sientes como si tu hicieses la silla de IKEA y el programador es quien la compra, ve las instrucciones y junta «El a con el a» etc.

Primer momento crítico: El proyecto puede caerse

Aún no hemos arrancado de verdad, pero puede que el proyecto ya entre en fase crítica ¿por qué? fácil… nuestro chico de cuenta, ya todo un hombre, le fue al cliente con todas las dudas planteadas y, a grosso modo, tenemos dos vías:

1. No obtiene respuesta a casi nada, porque para eso nos han contratado.
2. Se obtiene un batiburrillo de información.

El hombre de cuentas puede decidir aquí parar el proyecto o encargarse él de cubrir todos los «vacíos» del proyecto que pueda y que el programador se invente el resto.

Estamos en plena fase de desarrollo

Hagamos un pequeño salto temporal. El hombre de cuentas, que ya ha envejecido a nivel de «señor mayor» lleva un par de meses peleando con el programador (o los programadores, todavía peor) junior de turno y entre los dos han tomado todas las decisiones del sitio web.

Detalle: programador junior ¿te sorprende? ¿acaso no hay seniors en la empresa? no siempre… pero sí, claro que hay programadores senior, ahora bien… suelen ser ya gente más que curtida, que sabe de qué va la película y que tienen ese empaque que te dan los años de rodaje, por lo que no van a aceptar este tipo de proyectos, puede que de vez en cuando consigas liar a alguno en el proyecto, pero lo normal es que tengan la suficiente seguridad en si mismos como para decirte que así no trabajan y que si quieres contar con ellos las cosas se hacen bien o, simplemente, búscate a otro. Y como les obligues, pues se desmotivan, entran al proyecto a hacer lo justo y necesario, casi peor que si fuesen junior, y ten por seguro que se irán a otro sitio dónde puedan hacer aquello que quieren hacer.

En fin, se desarrolla todo, pim pam pim pam y llega el momento de que el cliente lo vea.

Segundo momento crítico: al cliente no le gusta el resultado

Puede que el cliente no sea capaz de trasladar al mundo online su negocio, pero sabe de su negocio y cuando ve el resultado sabe que lo que ve no es su negocio. ¿no lo es? No claro… pero… ¿acaso podría ser de otra forma?

Todo el sitio web está hecho en base a unos criterios que surgieron «por arte de magia», sin nada detrás que lo justifique. No existe un motivo, un por qué, una finalidad… ni a nivel de estructura, ni de funcionalidad, ni de diseño, ni de contenidos…. como mucho hay un «porque es molón» detrás… o sea: nada. Y no hay nada peor que no tener nada detrás.

El cliente toma el mando

Como el cliente no está satisfecho, empieza a solicitar cambios sobre lo que ya existe. Por lo que se inicia la fase o traca final, en la que todo ya va hacia el fracaso seguro. ¿por qué? Porque es algo que está fuera de sus competencias… es como si llevases el coche al taller, al ver el resultado no te gustase y como no te gusta, abres el motor y empiezas a decirle al mecánico que tiene que apretar, cambiar o eliminar. ¿A que nunca lo harías? Pero claro… la web tiene que salir, el cliente ve que eso no vale, ya no se fía del equipo y no le queda otro remedio que tomar el mando… o parar el proyecto.

Día de publicación

Seguramente desde el inicio del proyecto ya han pasado varios meses, e incluso más de un año. Nuestro «señor mayor» de cuentas ya ha envejecido a niveles de jubilado, pero por fin se consigue publicar el proyecto.

¿y ahora? Pues… llega el último momento crítico

Muerte por publicación

Lo que se ha publicado no es bueno, es imposible que lo sea. Pero el cliente no quiere saber nada, pero nada, del proyecto y mucho menos de los desarrolladores. Los desarrolladores no quieren oír el nombre del proyecto, nuestro ancianito de cuentas ya no tiene energías para hablar con nadie…

Y llega la terrible conclusión: Habría sido mejor no publicar.

Las soluciones mágicas que la gente se inventa para evitar estos problemas merecerían una serie de post propia, así que iré directo a una sola… que realmente sí funciona, aunque tiene una serie de premisas que pocas veces se cumplen.

Scrum llega a nuestras vidas

Un día, alguien se entera de que existe algo llamado «metodologías ágiles» y que tiene su máximo exponente en Scrum Alliance… y ve la luz. «Es justo lo que necesitamos, agilidad, porque tardamos mucho». Empieza a leer (los menos, pero bueno…) la metodología y descubre que cuando se habla de agilidad no se hace en el contexto de «te lo saco en dos días».

De todas maneras, le convence muchas cosas que lee y como escucha que funciona y que no pasa nada, que lo puedes adaptar a la realidad de tu empresa (¡la gran mentira!). Ahí que se ponen a tope con SCRUM… hago mi tablero, pongo mis post-it, bla bla bla bla bla.

La realidad es que no solucionan nada, lo empeoran, porque sólo consiguen que los problemas se inicien antes, pero no se solucionan.

Pero SCRUM no es malo, funciona

Ojo, que SCRUM funciona. Como se dice «El problema no es SCRUM, eres tú». SCRUM se basa en unas premisas muy importantes:

• Equipo:
• • comprometido
  • (muy) experimentando
  • multi-disciplinar
• Conocimiento profundo «del producto»

¿por el hecho de usar SCRUM cumples las premisas? Por supuesto que no. Si las premisas se cumplen, SCRUM es una maravilla, lo mejor sin duda, pero sin eso…. es peor que el infierno, pero esto es cuestión de otro artículo.

Si la depresión no ha impedido que llegues a este punto del artículo… tranquilo hay luz al final del túnel. Y brilla mucho, pero mucho.

La base del problema es sencilla: No se puede pretender que un desarrollador o el cargo X de turno tenga una visión tan global y a la vez concreta de cada negocio, sector, modelo, etc. Por algo existen las estrategias… y las estrategias online las crea un equipo… y cuando hablo de equipo no me refiero a las «primeras espadas» sino al equipo con mayúsculas: Todos.

Vale, un programador experimentado, un senior de verdad (no de esos que lo son por el mero paso de los años) es capaz de detectar muchas cosas, puede ver un contenido que el cliente quiere poner «así por que sí » y darse cuenta de que es un contenido de muchísimo valor y que tiene que explotarse de alguna manera… pero recuerda, un programador serio, un «peso pesado» no aceptaría formar parte de un proyecto como el que he comentado en este post.

Para que un sitio web salga con todo lo necesario para ser un éxito (lo que nunca garantiza que lo sea, como todo en la vida) hace falta que trabajen juntos, idealmente, los siguientes agentes (o los más posible)

El equipo ideal para definir tu comunicación online

• Un product owner que conozca de verdad lo que se quiere transmitir con el proyecto, para que pueda transmitirlo a todo el equipo y que pueda ayudar en todo momento a detectar lo que importa y que pueda priorizar todo en base a la utilidad que va a aportar al modelo de negocio del cliente.
• Un inbound specialist de verdad. Una persona, al menos una, que no sólo esté especializada en marketing, sino que entienda la web (no sólo de redes sociales vive la red). Que tenga la capacidad de:
• • Estructurar la información.
  • Detectar al vuelo los contenidos de valor.
  • Tener propuestas sobre cómo explotarlos.
  • Una persona que sepa cómo se debe comunicar en base a quién nos dirijamos.
• Un CTO de los de verdad. O sea, un CTO que venga del desarrollo, pero:
• • Que haya sido capaz de evolucionar para entender el lenguaje de negocio
  • Que tenga la experiencia suficiente como para ser capaz de ver interconexiones y nuevos modos de explotar todo lo que inbound piensa o comenta.
• Un desarrollador senior que junto con el CTO tengan la capacidad de modelizar todo para poder escribir el código que lleve a la realidad el proyecto.
• Un diseñador que entienda la web… pero de verdad. Que el contenido prima sobre lo bonito y que la usabilidad y experiencia de usuario es básica.

Cuando todos estos profesionales se juntan para definir un sitio o proyecto web, el resultado parece magia.

Porque el trabajo en equipo funciona

A nivel profesional, puedo asegurar que no hay nada más satisfactorio y de lo que me pueda sentir más orgulloso que el formar parte de esas reuniones de mesa redonda y pizarra en la que profesionales que, a priori, pertenecemos a mundos opuestos somos capaces de definir cómo queremos que un sitio se comporte, cómo se debe mostrar, cómo se vincula la información, qué importa, qué no… qué es vital tener… cómo vamos a dar continuidad al sitio, para que vaya creciendo una vez publicado.

Cómo, en resumen, un equipo de verdad va generando una estrategia a largo plazo en base a las necesidades del cliente. Y cómo esta estrategia va mucho más allá de lo que el cliente haya podido imaginar inicialmente.

Sin lugar a dudas, es la clave del éxito en todo proyecto web. Que el equipo (inbound, cuentas, desarrollo, performance, diseño) formen parte activa del proceso. Y que sean ellos los que decidan lo que se va a hacer y cómo. Puede que al principio el cliente sienta un poco de vértigo… pero la alternativa es fracasar y nadie quiere eso ¿verdad?

RS for victory and glory