El diagnóstico de un proyecto de edición digital

Cuando visitamos al médico, éste nos hace una serie de preguntas para conocer qué nos sucede. Dado el caso, nos manda hacer unas pruebas para saber más sobre nuestro cuadro clínico.

Del mismo modo, al afrontar un proyecto de edición digital, sobre todo si es innovador, hemos de enfrentarnos a una situación similar de indagación, para conocer a fondo qué vamos a necesitar, qué tecnología se puede usar y sobre todo, qué limitaciones nos vamos a poder encontrar por el camino para anticiparnos y evitar que el desarrollo de nuestro proyecto termine en un «development hell».



Es por eso que cuando un cliente viene con un nuevo proyecto o idea bajo el brazo para desarrollar, acostumbro a enfundarme la bata blanca de galeno y empiezo el necesario y siempre algo incómodo interrogatorio. En la mayoría de los casos la idea que tiene el cliente sobre su producto se ve limitada por detalles ajenos a su entusiasmo, y que vienen dados por la disparidad de posibles formatos, productos, dispositivos y circunstancias en las cuales se ha de desarrollar el libro electrónico o equivalente.

El esquema básico de mi cuestionario suele incluir preguntas como:

  • ¿En qué dispositivos ha de poder rodar su libro? ¿Móviles, también ordenadores… (Mac, Windows…) ¿Lo limitamos a iPad, Android…?
  • Importante: ¿su producto va a estar a la venta o será de distribución gratuita?
  • ¿La publicación depende en parte de contenidos online? 
Pueden parecer muy obvias estas preguntas pero creedme si os digo que son verdaderas trampas puestas a propósito.


Por ejemplo, a menudo se ignora que soluciones tan maravillosas de publicación digital como iBooks Author son capaces de crear e-books para Mac, iPad… pero no para iPhone! Con lo cual si se desea cubrir ese segmento, hay que pensar en crear un producto paralelo, con todo lo que ello conlleva.

De igual modo, un precioso libro EPUB3 que tiene multitud de funcionalidades multimedia en un iPad, puede verse capado en Android, o no ser posible su distribución en los markets habituales.

Hay apps o web apps que pueden sencillamente quedar totalmente inutilizadas cuando el usuario no dispone de conexión online.

Hay que tenerlo todo absolutamente todo en cuenta antes de ponerse a producir, que siempre debe considerarse como una fase final del proyecto en lo que todo debe fluir de manera rápida y con los mínimos inconvenientes posibles. Es preferible pasar por el mal trago del «poli malo» al inicio de un proyecto que no al final cuando todo son prisas y agobios.

¡Felices desarrollos!


Afrontar proyectos interactivos (III): cuestión de Actitud

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:
Segunda entrega: Empezar a prototipar (II)

Afrontar proyectos interactivos (1)

Estamos en una época interesante de efervescencia creativa en lo que a contenidos digitales se refiere: e-books, apps, webs, blogs, etc. florecen de manera acelerada llenando de posibilidades ocio y aprendizaje las memorias de los dispositivos móviles de millones de usuarios en un mercado global.



Pero afrontar un proyecto interactivo es, en general, un proceso complejo no exento de riesgos, y como tal tiene que superar una serie de obstáculos que pueden hacerlo naufragar en cualquier instante.

Tanto si se trata de un sitio web, una app o un libro electrónico, los proyectos interactivos digitales tienen una serie de peculiaridades que hay que tener en cuenta desde la misma concepción del proyecto. A menudo, por motivos variopintos, se suele empezar la casa por la ventana y eso es un error que suele pagarse caro al cabo del tiempo.

Es por eso que en esta serie de artículos quisiera sacar a la luz cuáles son —en mi opinión— los puntos más delicados de este tipo de procesos, por si pueden ser de utilidad.

Para empezar, siempre es conveniente hacer un listado básico de requerimientos del proyecto. Para ello, podemos realizarnos una serie de preguntas rápidas:

1) El producto ¿saldrá a la venta pública o es para distribuirlo en un entorno privado? (una intranet de una empresa, por ejemplo).
2) ¿En cuántos idiomas estará disponible?
3) ¿Para cuántos sistemas o entornos estará disponible? (iPad, Android, Ordenadores…)


Con estas tres respuestas se puede concretar bastante la envergadura del proyecto en cuanto a su desarrollo, y se pueden empezar a plantear posibles soluciones tecnológicas ¿por qué?

1) Existen diferentes mercados (AppStore, Google Play, iBookStore, Amazon…) cada uno con sus particularidades y restricciones.

2) Hay que plantearse desde el principio si una aplicación o libro estará en varios idiomas a la vez o habrá una edición por cada idioma, ya que es un condicionante bastante importante que determina el cómo se hará la posterior implementación.

3) Cada sistema suele ir ligado a un mercado o tienda (AppStore a iOS, Google Play a Android,  etc.) pero además cada herramienta de producción puede estar también ligada a una de estas opciones, como es el caso de iBooks Author, que permite desarrollar libros electrónicos disponibles solamente en iBookStore y solamente para iOS y MacOS.

Con frecuencia estas preguntas podrían parecer absurdas para el cliente estándar, o sea el que quiere algo “Que haga de todo, que funcione en todos los dispositivos, que esté en todos los mercados”. Y por supuesto, en un solo producto B.B.B. y para antes de ayer.

Éste es el primer paso delicado en el desarrollo de un proyecto interactivo: decidir qué formato tendrá el producto. ¿Será una app? ¿Será una web? ¿Una web app? ¿Un e-book? ¿Todo a la vez?

Imagen de obra inacabada. (fuente: La Verdad de Murcia)

En este punto, se puede aplicar la filosofía Kaizen: primero se hace, luego se mejora. Desde que se genera el encargo de realizar un proyecto, pesa sobre él una espada de Damocles: que se acabe convirtiendo en un Development Hell, en una obra faraónica que jamás esté terminada. Esta amenaza se cierne en todas las fases del desarrollo y por múltiples motivos, así que en el estadio inicial de conceptualización hay que ser flexibles y desechar (al menos temporalmente) una multiplicidad de opciones o caminos que incrementen desproporcionadamente el coste/tiempo de desarrollo.

Para ayudar a hacer esta criba, se pueden aportar datos estadísticos sobre el mercado: cuál es la penetración de mercado de un cierto dispositivo, cuál es la visibilidad de en qué tiendas de qué tipo de producto, etc.

Hay ideas que se adaptan mejor a un formato app para smartphone, otras que tendrían mejor salida en forma de e-book para iPad, etc. Para apoyar esta decisión, se pueden listar los pros y contras en cuanto a las funcionalidad que ofrece cada plataforma, y contrastarlo con las bondades de cada uno de sus mercados asociados.

Por ejemplo: un videojuego sencillo gratuito puede tener una gran acogida en el mercado Android (Google Play) y no ser prioritario como juego para ordenadores via Facebook, dependiendo de cómo sea ese juego. 

De igual modo, un catálogo de arte puede ser un producto atractivo como un libro para el iPad, pero no tanto como una app para Android. Esto no es para descartar una plataforma pero sí para acotar y priorizar objetivos. Un producto puede salir al mercado en un formato determinado en una fecha determinada y más adelante ampliar su radio de acción a otros mercados y plataformas. Esperar a tenerlo todo terminado y perfecto puede ser una fuente multiplicadora del tiempo de desarrollo, y cuando los productos van asociados a campañas de marketing, la presión sobre éste puede derivar en multitud de males propios de los Development Hells.

En una próxima entrega hablaré de la fase de diseño de prototipos, el inicio del ahora tan manido UI/UX.

Hasta la próxima, ¡felices conceptualizaciones!