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.