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.

CoScripter es una extension desarrollada por los ingenieros de alphaworks de ibm, que permite “grabar” los pasos en tu navegador, para reproducirlos posteriormente. Viene a ser como las macros de office pero para tu navegador.

Creo que puede puede convertirse en una herramienta basica para documentar procesos.

En alphaworks tambien se desarrolló aDesigner, software imprescindible para consultores de accesibilidad.

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.