Programación creativa

Este articulo es demasiado bueno para que no se publique.
La pena es que no sea yo el autor

Hoy he tenido una de las reuniones con clientes más duras y complicadas de mi vida.

Supongo que todo desarrollador ha vivido situaciones similares y le suenan cosas como listas de cambios interminables, desarrollos que tardan meses, incluso años, en cerrarse o esos proyectos que hacen que uno envidie la sencilla vida del pastor de cabras y fantasee con la idea de no volver a abrir un ordenador en su puñetera vida.

Con el tiempo uno va aprendiendo a protejerse de esas situaciones y va definiendo un modelo de trabajo que suele impedir que ocurran ese tipo de situaciones; pero hay casos imposibles.

¿Cómo se proteje uno de ese tipo de cosas?

Hay varias cosas que deben ser de obligado cumplimiento en cualquier proyecto de desarrollo web si uno quiere evitar problemas.

1. Hacer un análisis exahutivo del proyecto y un documento que lo especifique que el cliente debe firmar antes de empezar
2. No salirse de ese guión durante el desarrollo
3. Crear entregables y aprobarlos con el cliente durante todas las fases del desarrollo
4. Especificar claramente hasta donde llega el trabajo del desarrollador y cuál es el del cliente

¿Se puede aplicar lo anterior en todos los proyectos?

Los puntos anteriores son el ideal, pero en una empresa de desarrollo mediana o pequeña muchas veces no se puede hacer de forma perfecta y menos cuando estamos hablando de proyectos web de mediana envergadura. Situémonos en la típica web corporativa con algunos servicios o características especiales (catálogo, conexión a su sistema de gestión y cosas así) para un cliente de una mediana empresa; estos proyectos, en mi ámbito, suelen estar entre los 6.000 - 15.000 Euros.

En estos proyectos suele ocurrir que:

• No te encargan la creación de contenidos, en teoría, los tiene que generar el cliente. Al final, en el mejor de los casos, los redacta la secretaria en sus ratos libres o se queda una web llena de “lorem ipsum”.
• No te pagan la introducción de contenidos ¿Para qué? ¿No me habéis vendido un cms que lo hace todo solo?
• Tienes un tiempo limitado para el análisis. No puedes cumplir el punto 1
• El desarrollado y el responsable de proyecto suelen hacer más cosas, por el bien del proyecto, que lo que se ha definido inicialmente. No cumplimos el punto 2
• El cliente no participa en el proyecto, no viene a las reuniones. Si quieres que el proyecto se convierta en un ente facturable… hay que tirar pa´lante y pasar de algunos entregables (los de diseño nunca!). Al garete el punto 3
• El cliente no se lee el presupuesto ni el análisis (cuando lo hay) y considera que todo tiene que hacerlo el desarrollador. Tampoco cumplimos el punto 4

Muchos, sobre todo los que trabajáis en grandes consultoras o aquéllos que acostumbrados a trabajar con administraciones pública, que pensaréis… “- Culpa tuya, nunca deben hacerse las cosas así -”. Pero eso, fuera de las excepciones mencionadas, es una situación que ocurre diariamente y si uno no es un poco flexible tiene pocas posiblidades mantenerse en el mercado. Y no nos engañemos, situaciones parecidas ocurren en grandes proyectos.

Y es verdad que lo normal es que haya una situación donde hay una relación directa y de cierta confianza entre cliente y desarrollador que suele hacer que no haya demasiados problemas en los desarrollos y al final se genere un producto de calidad para un cliente satisfecho.

El cliente imposible

Es difícil de detectar antes de haber firmado el proyecto, pero cuando comienzas las primeras reuniones ya empiezas a verle el plumero. Su principal característica: no confía en ti.

• No le satisface ningún diseño y no solo eso, quiere diseñar el. Da igual que le argumentes que sus propuestas van en contra de los requisitos del proyectos, que afectan a cosas como accesibilidad o la usabilidad, le da igual, detesta la verdana y todas las fuente del sistema y considera que el problema es que los diseñadores no tienen ni puta idea. Mal empezamos.
• Empieza a exigir plazos, pero no interviene en el proyecto (está muy liado). Al final siempre se agarrará a que tu has incumplido plazos para pedirte mejoras infinitas
• Le da igual el análisis que ha firmado. Considera que está mal y que eso no es culpa suya, aunque lo haya firmado (normalmente ni lo ha leído).
• Niega haber aprobado ningún entregable, cuando le demuestras que lo ha hecho, dice que “no lo había mirado bien” y que el haberlo firmado no quiere decir nada
• Una vez que empiezas con listas de cambios, aprovecha el tiempo que dedicas a revisar para invertar nuevas modificaciones

Es evidente que con alguien así lo mejor es devolverle el dinero y cerrar el asunto.

Existe en nuestra profesión un perfil, el desarrollador web, que es un cajón de sastre de otras muchas cosas.

Poco a poco, este trabajo se ira diversificando y se definirá en varias especialidades que se complementarán y trabajaran en formada organización. Pero, hasta que eso pase los que tenemos que hacerlo tendremos que aprender a trabajar en la sacrificada artesanía de la multidisciplina web. Dos son para mi, los factores que no permiten una especialización:

La constante evolucion de las tecnicas y los lenguajes
Hace poco tiempo, se maquetaba con tablas en dreamweaver. Se usaba php o asp para programar, y flash estaba en auge para aplicaciones sin refresco de pagina.
Ahora la variedad de lenguajes crece exponencialmente si contamos con los frameworks, los cms permiten mejores soluciones por dias, y se usa ajax, flash o lo que venga. Ademas se han incorporado dos maximas en el desarrollo la accesibilidad y la usabilidad que tienen que estar presentes en cualquier desarrollo con un minimo de calidad.
En este contexto bullicioso, la figura del desarrollador se ha ido especializando cada vez mas, pero aun así conozco pocos maquetadores, que no esten usando, probando o integrando ajax o desarrollos de servidor en algun punto de su proceso, o lo contrario que hayan absorbido las funciones de los diseñadores. El problema creo, es que la oferta de empleo cambia demasiado rapido y no existen perfiles en el momento en el que se necesitan.

La necesidad del “chico del html”
Jose pita me mencionaba un articulo que escribió robert nyman: “The html guy”, en que hablaba de las connotaciones negativas del termino con pesar porque al ser el que desarrollaba el frontend, muchas de las preguntas de las personas que desarrollaban proyectos pasaban por el chico del html, y muchas de las decisiones que el tomara tienen consecuencias en la calidad del desarrollo. Es un titulo poco honroso para una pieza tan clave.

En la planificación de proyectos lineal,

• el diseñador diseña ( en base a algun prototipo si lo hay),
• el maquetador interpreta el diseño en el navegador y…
• el programador otorga funcionalidad al diseño

Este modelo no funciona, es muy logico, pero no funciona así.

En diseño es practicamente imposible prever todas las posibles situaciones ( incluso diseñadores expertos se encuentran una y otra vez con imprevistos ). Los prototipos minimizan los ensayos de prueba y error pero no los anulan.
El programador no entiende toda la extensión del proyecto y intentara hacer su trabajo “tal y como le han dicho”, no comprenderá en profundidad como invertir su esfuerzo.

El que esta en medio es el maquetador, este puede hacer dos cosas, maquetar las pantallas como un programador:

estas pantallas se tienen que ver igual en el diseño que en el navegador, una vez que lo consiga ya he hecho mi trabajo.
Y ademas si lo clavo soy un megamaquetador

ó vincularse con el proyecto y desarrollar un proyecto ( estas a tiempo, elige la pastilla azul ). Creo que esta es la diferencia entre un maquetador y mi concepcion de un desarrollador web.
¿ Que implica que haya un desarrollador web entre los dos puntos del desarrollo lineal ?

1. que deja de ser un proceso lineal para ser un proceso iterativo. el diseñador refleja las premisas del “html guy” y contempla sus quejas, el “html guy” intenta comprender las limitaciones que tiene el desarrollo del programador y plantea soluciones creativas
2. que el desarrollador web intenta cubrir algunas de las tareas del proceso lineal ( en nuestro caso usando un cms )
3. que la responsabilidad que se diluye entre las dos partes suele estar en los hombros del desarrollador

Caracteristicas tipicas de un desarrollador web serian entonces:

• Sabe interpretar un diseño.
• Empatia y asertividad para comprender a los demas componentes del equipo, el cliente, el responsable del proyecto, etc…
• Sabe maquetar, normalmente tiene criterios basicos de semantica y accesibilidad
• Sabe o maneja alguna herramiento o lenguaje que le permite hacer procesos en el servidor.

En la continuación de este artículo, intentare repasar las amenazas del desarrollador web y algunas pautas que pueden ser de utilidad.

Antes de que me vuelva a dar por rediseñarla de nuevo, doy por publicado mi ultimo proyecto propio:

Recetae.com es un sitio web de recetas con:

• sindicación de contenidos por usuario, por tipo de plato y por tag
• Buscador de recetas por ingredientes
• votacion y comentarios en la ficha
• algunas cosas mas

Si te gusta, piensa en el plato que mejor te sale, echa una foto del plato y publica.

Hoy he tenido la boda de un buen amigo. Como no dispongo de un ropero amplio ( eso si unos cuantos cajones repletos de camisetas ), he tenido que escoger un traje clasico con camisa y corbata al uso. El caso es que ( lo reconozoco publicamente ), no se hacerme el nudo de la corbata.
Como suele pasar en estas situaciones ya ibamos tarde cuando, mientras buscaba la ubicacion en google maps, me intentaba abrochar la corbata ( creo que los vecinos de enfrente pensaban que estaba intentando ahorcarme ). Desesperado tras cuatro intentos he visto la luz - ¿ y si busco en google nudo corbata?.

Asi es como he aparecido en esta pagina. En ella explican con un simple grafico, los pasos a seguir para hacer varios tipos de nudo en 8 idiomas.

• El nudo simple
• El doble simple
• El nudo Windsor
• El medio Windsor
• El nudo pequeño
• El nudo cruzado

Un par de intentos mas y nudo conseguido.

Secret places es una guia de hoteles con encanto en 3 idiomas. Frente a otras guias, los fundadores presumen de haber visitado los hoteles, y solo haber considerado aquellos que son realmente especiales.

Valoración
( **** ) Buena, Teniendo en cuenta que la pagina apenas se ha modificado desde el 10/09/2004, consigue que el usuario navegue y consiga casi todos sus objetivos, ofrece alternativas de navegacion, y en general respeta criterios basicos de construccion de sitios web. Eso si hay algunos detalles mejorables.

Objetivo
Buscar hoteles entre Huelva, Extremadura y sur de Portugal para Diciembre de este año.

Resultado
Positivo. He recopilado varios hoteles e ideas de viaje. Echo de menos haber encontrado antes el listado de todos los hoteles de una region. La arquitectura de la informacion flaquea en muchos aspectos, pero hay muchisima informacion relacionada con los hoteles y con los municipios.

Portada
:( . La portada muestra un extenso texto con informacion relacionada con la empresa, su nacimiento, y una relacion de tipos de hoteles que encuentran cabida en sus servicios. La unica información relevante que podemos encontrar en portada es el listado de Lugares Secretos, ( En ingles ” sitios inolvidables “). Se deberia destacar mas desde un principio uno o varios directorios de enlaces por regiones, tipos de hoteles o precios. El unico “distribuidor” que tenemos es por paises, que quizas sea un criterio de clasificacion ambiguo para el tipo de busqueda que estamos haciendo.

Dentro de Portugal
El mapa me hace mas facil ( frente a un directorio ), el reconocimiento visual de la zona a la que quiero ir, Alentejo. Pero cuando pulso me vuelve a aparecer otro mapa mas detallado localizando los hoteles. Lo cierto es que dentro de esta zona, que el hotel esté mas o menos alejado me importa poco, sin embargo si estoy echando de menos ver el listado completo de hoteles. La orientacion espacial en el territorio, es un criterio demasiado ambiguo, para tomar la decision de mi viaje. Voy pulsando puntos al azar en el mapa hasta que doy con el enlace:
Click on hotel icons on map or show all Alentejo hotels
Voila. En un listado me esta mostrando una fotografia un.a breve descripcion, y unos iconos descriptivos, lo cierto es que me requiere mucho esfuerzo comprender que significan echo de menos un pequeño texto explicativo con los servicios.

Detalle del hotel
Cuando pinchamos en View hotel, Encontramos una extensa y rica ficha con fotos, descripcion, tarifas, formulario para disponibilidad, y con comentarios ( aunque estan vacios en todos los que he mirado ). Las fotos estan cuidadas, parecen echas por la misma mano para todos los hoteles, lo que refuerza la sensacion de lugares recomendados.

Mejoras
Los contenidos de la web merecen una alta puntuacion, si ademas estos datos estuvieran mejor organizados, el sitio seria muy bueno.Usando la informacion que tiene ahora mismo, podriamos crear una web mucho mas amigable, tendiendo en cuenta al usuario. Destacando:

• La portada, no funciona como un buen distribuidor, es mas ornamental que otra cosa.
• El menu de la izquierda se usa poco o nunca.
• El mapa en un segundo nivel de acercamiento, su uso no deberia competir con un buen listado, donde aparezcan los hoteles.
• Los iconos acompañados de un texto descriptivo.

Recordar que esto no es una critica exhaustiva de experto, sino un simple acercamiento como usuario.