En esta tercera entrega de la serie de artículos sobre cómo gestionar proyectos interactivos, quisiera comentar aspectos que tienen menos que ver con detalles técnicos del proceso y más sobre la actitud con la cual hay que afrontarlos. No solamente desde la perspectiva del desarrollador si no también del cliente final (o del intermediario).
Llevar a buen puerto un proyecto relacionado con las tecnologías de la información no es algo sencillo en general y hay que saber interiorizar lo que supone antes incluso de ponerse manos a la obra. En mi opinión, existen una serie de axiomas que merece la pena tener en mente, a saber:
1) “No hay proyecto pequeño”. En el mundo del fútbol se ha hecho popular una frase que mencionan los entrenadores habitualmente:
“No hay rival pequeño”. Pues bien, en el caso de los proyectos digitales, yo creo que esta frase se aplica de manera imperturbable.
Cuando un cliente me requiere para un nuevo proyecto y menciona que es “poca cosa” o “simple” lo primero que hago es echarme a temblar y reservar un buen paquete de horas de trabajo. Y no me excluyo, esta subestimación del poder complicador de la tecnología la practicamos –creo yo– la mayoría de nosotros. No recuerdo ni un solo proyecto interactivo en los que haya participado, por simple que pareciera al inicio, que no haya acabado sin saber cómo realizando tareas repetitivas y tediosas (como miles de clics para over miles de imágenes) hasta altas horas de la madrugada para implementar un aspecto o cambio de la aplicación.
Y es que en IT todo, repito, todo se puede volver endemoniadamente complicado.
Los motivos pueden ser de lo más variopinto: desde que de repente el cliente solicite un cambio que a él se le antoje nimio pero que a unas alturas del desarrollo lo convierte en un trabajo de chinos hasta que el software con el que trabajes “sufra” una actualización de última hora que inutilice archivos o la aplicación misma. Todo puede suceder y todo es esperable en mitad de un desarrollo.
Por lo tanto, la respuesta instantánea que hay que decir cuando nos vengan con lo de “es algo sencillo” debe ser de una firme cautela y de una humildad extrema. No se me ocurre una réplica más sabia que un prudente y honesto “bueno, ya veremos”.
2) El perfeccionismo no es tu amigo. Si cuando gigantes como Microsoft, Apple, Adobe, Google… sacan al mercado productos que son una selva de fallos e imperfecciones ¿por qué nosotros deberíamos ser mejor que ellos? No quiero hacer una apología de la chapuza, pero en proyectos digitales “pequeños”, buscar el 100% de fiabilidad y compatibilidad en un escenario donde los propios fabricantes de tecnología acaban de entender lo que ellos mismos están produciendo me parece una actitud poco realista y coherente.
Es habitual tener que lidiar con exigencias de máximos por parte del cliente final, o bien con el intermediario que hace de mera correa de transmisión. “Se tiene que ver todo igual en Android, iPad, ordenadores y por supuesto en Internet Explorer 6”. Y de ahí no se mueven un milímetro, oye.
Entiendo que es lógico y humanamente comprensible querer ofrecer un producto universal y fiable, pero quien está pidiendo eso creo que conoce poco o nada el mundo de la tecnología digital. En este punto es cuando uno debe proceder con la máxima cautela y explicar la cruda realidad de la misma, evitando dar la imagen de querer esquivar el trabajo o poner pegas gratuitas. En este aspecto el posibilísimo es nuestro amigo y el perfeccionismo es el enemigo.
Es por eso que puede servir el argumento socorrido del
“Vamos a sacar una versión 1.0 y luego ya introduciremos mejoras en versiones posteriores” (mi experiencia me dice que al final en el mayoría de los casos esa versión 1.0 será más estable y duradera de lo que piensan y que en realidad debería llamarse versión “virgencita que me quede como estoy”). Otra amiga es la
filosofía Kaizen “Primero se hace, luego se mejora”.
3) Respeta a tu developer (desarrollador): no sé vosotros, pero yo a menudo me he topado con que se respeta poco al auténtico constructor de los proyectos digitales interactivos, al que más se “pringa” las manos en ello: el desarrollador, alias “developer”, alias “programador”.
Aunque no sea el director del proyecto, hay que escuchar con cariño sus sugerencias y criterios. Cuando el developer te avisa que no una característica de la aplicación solicitada por el cliente o diseñador no es prudente implementarla, o que directamente no es viable, escúchale. Como norma general no lo dice por fastidiar o torpedear el proyecto. A los programadores de verdad les gusta programar, experimentar y superarse a si mismos haciendo nuevos trucos. Pero recuerda que ellos conviven en un mundo de complejidad extrema donde la normal general es que las cosas sencillamente no funcionen a la primera.
Y la mayoría de efectivos chulos que ves en páginas web, etc. a menudo están basados en tecnología pseudo experimental que se sostiene con pinzas, y la idea de que algo que viste automáticamente es extrapolable a tu proyecto interactivo es en la mayoría de casos errónea.
Una vez más, humildad. Se empieza por algo estable y luego se intenta refinar.
4) No ocultar NADA. Una vez más, la mente extrapoladora y auto-completadora de la que gozamos la mayoría de nosotros nos juega malas pasadas. Por eso es fundamental no escamotear absolutamente nada al inicio del desarrollo de una aplicación interactiva. El ejemplo más típico pero no por ello menos dramático es de las aplicaciones multi-idioma.
La escena es bastante habitual: estamos en la recta final de un desarrollo que ha superado cientos de obstáculos debido en parte a lo explicado hasta ahora en los puntos 1, 2 y 3… y de repente, cuando ya se ve la luz al final del túnel, el cliente (o cualquier otro agente implicado en el encargo) menciona la frase fatídica: “Bueno y hacer que esto esté en tres idiomas es fácil, ¿no?”.
Si alguna vez habéis estado en el rol de desarrolladores y habéis pasado por esta circunstancia, supongo que no hace falta añadir más para saber qué se siente en ese instante. Es por eso que lo prudente es trabajar con arquitecturas que siempre prevean la posibilidad de que los textos o los sonidos sean en 2, 3… N idiomas, aunque el cliente no lo haya solicitado al principio. Y por supuesto reflejar esta previsión en el presupuesto, aunque no figure explícitamente.
En fin, seguramente me dejo más puntos en el tintero digital pero a grandes rasgos éstas son mis impresiones acerca del interesante mundo del desarrollo de proyectos interactivos originales. Os deseo la mejor de las suertes y espero que os hayan quedado fuerzas suficientes para leer las futuras entregas de esa saga o incluso las anteriores:
