6 problemas típicos en proyectos UX – Parte 3: Productos Inútiles

Segway_Police_(2529167270)

Segway: un producto que quería cambiar el transporte de personas en un mercado masivo, fracasó espectacularmente en ello, y finalmente encontró un nicho en el personal de seguridad.

Éste es el tercer capítulo de la serie sobre los 6 problemas típicos en proyectos UX que hemos encontrado en Continuum.

Ya hemos revisado cómo el Feature creep y el Deadline creep arruinan proyectos de UX y terminan convirtiendo buenas ideas en proyectos fallidos o desfigurados. Ambos problemas hacen que las energías se gasten en tiras y alojas internos, en lugar de estar mejorando el producto para sus usuarios.

Pero nos ha tocado enfrentar proyectos que padecen un problema mucho más de raíz: la idea, en sí misma, es pésima. ¿Qué haces cuando te encargan (y te pagan por) trabajar en un proyecto que sabes que está destinado a morir? Y de hecho, hay una pregunta anterior que hacerse: ¿cómo sabes cuando una idea es realmente mala?

La ilusión de que si insistes lo suficiente, también podrás ser Steve Jobs

El lector estará familiarizado con esas historias donde un genio visionario (Steve Jobs, Henry Ford, Gastón Acurio, etc.) tiene una idea que todos en un principio encuentran estúpida, hasta que el obsesivo y tenaz genio termina haciendo realidad su visión, cambiando toda una industria y generando un par de frases para el bronce que luego nosotros compartiremos en redes sociales.

El problema con estas historias es que son sumamente engañosas: nos hacen creer que cada vez que el resto del mundo encuentra estúpida nuestra idea, es porque nuestra idea en realidad es genial. Y la mayoría de los seres humanos, cuando nos dan a elegir entre considerarnos estúpidos o considerarnos unos genios, vamos a elegir la opción que nos deja mejor parados. Y vamos metiendo plata, esfuerzos y recursos a una idea, bajo la premisa de que “si no funciona aún es porque no hemos insistido lo suficiente”.

El otro problema con estas leyendas es que ocultan la cantidad de veces que estos genios visionarios han fracasado o han tenido que modificar su idea original hasta convertirla en lo que realmente funcionó. Y acá la línea que divide al perseverante del obstinado es delgadísima: mientras que el primero modifica y cuestiona su idea mil veces en pos de llegar a algo realmente útil, el segundo da por hecho que su idea ya es perfecta y que tan sólo basta que el mundo se dé cuenta.

Y eso definirá si nos estamos embarcando en un proyecto destinado a alcanzar nuevos horizontes, o si nos tocará, cual camareros del Titanic, hacer de comparsas mientras todo se hunde.

Las buenas ideas están conectadas, las malas ideas están desconectadas

Como líderes de UX, muy a menudo somos los primeros en tomar contacto con la idea del cliente y evaluarla. Y nos corresponde tener la disciplina para resistir el impulso de correr al Photoshop, y en cambio hacer una pausa para preguntarnos,¿es ésta la idea correcta?

Supongamos que es 2007 y Google se acerca a ti, consultor de UX, para pedirte ayuda con un proyecto ambicioso, que promete reemplazar al e-mail: Google Wave. La idea, en el papel, suena increíble. Hoy sabemos que fue un completo fracaso.

¿Qué le habrías dicho tú a Google acerca de su idea?

En Continuum ideamos un canvas especialmente para esto: se llama el Scope Canvas. Usándolo buscamos que el contexto de la idea, por sí sola, muestre si está conectada o no con las necesidades de algún usuario. Una de las ideas básicas del Scope Canvas es que todo, al principio, se encuentra en estado hipotético; por muy convencidos que estemos de que esta idea es absolutamente genial y que el mundo la amará, necesitamos validarlo en el mundo real.

Google Wave falló, entre otras razones, porque no estaba conectado con ningún problema de sus usuarios objetivos. Efectivamente, era una mejora al e-mail; pero la gente se las arreglaba (y aún lo hace) bastante bien con el e-mail y sus imperfecciones. ¿Qué razón tengo yo para dejar de hacer lo que hago actualmente y adoptar este producto nuevo? El equipo de Wave nunca se hizo esa pregunta, y una vez que pasó el efecto de la novedad, el público abandonó la plataforma a su suerte.

Como ven, la palabra clave para separar buenos y malos productos es conexión.Cuando una idea de producto parece estar flotando en un limbo y en el Scope Canvas no se ve ninguna relación con motivadores o necesidades de usuarios, es hora de intentar conectarla para salvarla.

Se puede arreglar una mala idea, conectándola

Hay dos maneras de conectar un producto con las necesidades de un grupo de usuarios: refinando la idea o refinando el grupo objetivo.

En la primera estrategia, el doloroso pero educativo feedback de usuarios —obtenido mediante prototipos, entrevistas, tests de usuario y análisis de datos— irá moldeando gradualmente la idea, aumentando el foco en algunos aspectos, descartando otros, agregando nuevos, hasta que logramos llegar a un modelo de producto que tenga una necesidad clara y concreta a la cual satisfacer.

Por el contrario, en la segunda estrategia partimos de la base que la idea es potencialmente buena, pero que está apuntando al grupo equivocado. Tanteamos nuevos segmentos de usuarios con necesidades afines al producto, intentando identificar el que mejor resuena con la idea del producto y con el core de negocio del equipo. Esto es lo que ocurrió con el Segway: fracasó como medio de transporte masivo, pero encontró un nicho en el personal de seguridad y ayuda en centros comerciales y lugares públicos.

En realidad, lo que solemos hacer es una mezcla de ambas: a medida que refinamos la idea, refinamos también la necesidad que estará satisfaciendo. Como profesionales de UX, nuestro negocio es la creación y la transmisión de valor. Si el valor no está inmediatamente presente en el proyecto o en el equipo, haremos lo mejor que podamos para develarlo.

Pero eso no siempre es posible.

Cuando ya no hay salida

A veces, incluso después de refinar una idea y su conexión con una necesidad, es el mismo equipo quien se mantiene desconectado de sus usuarios. En ocasiones es por ego, y en otras es por apatía. Y hay casos donde la idea es genuinamente buena (y el equipo lo sabe), pero el timing es el incorrecto (y el equipo no lo quiere ver). El resultado es el mismo: no hay voluntad de enmendar el rumbo de un proyecto sin utilidad real o potencial.

Podemos decir “el cliente tiene la razón” y pasar por caja a cobrar nuestro cheque, y es válido. Pero personalmente creo que tenemos una responsabilidad un poco mayor como diseñadores de experiencia de usuario; estamos para crear productos útiles, y debemos avisarle al equipo cuando no lo estamos logrando.

Decir “lo lamento, pero creemos que este producto, así como lo han pensado, está destinado a fallar” requiere mucho valor; generará fricción y tensión, e incluso arriesgamos quedarnos afuera del proyecto.

Pero tal como con rayarle la cancha al cliente, no hacerlo tiene un costo mayor: nos veremos trabajando en un proyecto que sabemos que no tiene sentido. Esto impactará la motivación de todos, y con ello se terminan las esperanzas de corregir la marcha. Aún peor, si el producto es realmente un fracaso sonoro, arriesgamos ver nuestro nombre anclado a él, con la reputación negativa que eso acarrea. Y después de todo, hay veces donde esa inyección de honestidad era lo que el equipo necesitaba para salir adelante. La transparencia tiende a ser muy valorada y respetada, y en varios casos la relación termina saliendo más fortalecida.

Dar la voz de alarma no es fácil y muchas veces es un trabajo ingrato. Pero mientras antes, como líderes de UX, sepamos reconocer esa desconexión tempranamente y creemos las estrategias para solucionarla, más fácil se nos volverá luego desenterrar y comunicar el valor que crea productos satisfactorios para todos: usuarios y equipo.

6 problemas típicos en proyectos UX – Parte 2: Deadline Creep

Éste es el segundo capítulo de la serie sobre los 6 problemas típicos en proyectos UX que hemos encontrado en Continuum

En esta ocasión hablaremos del Deadline creep, o cómo los plazos (y los costos) de un proyecto se desbordan, muchas veces agotando todos los recursos disponibles sin llegar a tener un producto lanzado.

Deadline creep, o la fantasía de que tenemos todo el tiempo del mundo

La Sagrada Familia de Gaudí: el ejemplo por excelencia de un proyecto tan ambicioso y complejo que lleva 133 años construyéndose.

La Sagrada Familia de Gaudí: el ejemplo por excelencia de un proyecto tan ambicioso y complejo que lleva 133 años construyéndose y aún no termina.

La manera en la que los proyectos se salen de cauce y terminan durando el doble, el triple o diez veces más de lo originalmente planteado está bastante documentada (irónicamente, el exceso de documentación suele tener que ver con el problema).

La primera y más obvia causa de que los proyectos se estiren como chicle en verano es el feature creep, del que ya hablamos en el artículo anterior de esta serie. La ansiedad de “agregar un par de cositas más antes de salir” va prolongando el tiempo en el que se invierte en un proyecto sin tener feedback de usuarios.

La segunda causa, no tan obvia, es cuando el equipo cree que “este momento es tan bueno como cualquier otro para plantear mi idea y hacer cambios”. Esto trae un continuo tira y afloja, donde la ansiedad de que todo quede perfecto ocasiona que las decisiones se deshagan y rehagan una y otra vez. Otros actores se suman tarde a la mesa, y usualmente son quienes tienen más poder dentro del equipo y por ende son capaces de descarrilar un trabajo completo.

El Deadline creep agota al equipo

Además de las consecuencias obvias (fallar en los plazos y gastarse más plata de la presupuestada), el Deadline creep deja tras de sí a un equipo exhausto, que se ha pasado los últimos meses en:

  • Pelear porque no se sigan añadiendo funcionalidades antes de lanzar
  • Perder la pelea por no tener el poder de decisión suficiente
  • Implementar esas funcionalidades a toda prisa
  • Sufrir la presión del project manager o del cliente, que (por supuesto) sigue trabajando con los plazos originales
  • Correr en círculos solucionando las quejas de usuario por las funcionalidades mal implementadas
  • Perder plata (y por ende motivación) en el proceso

¿Cómo evitas esta espiral?

Mostrar la guagua fea

En Continuum tenemos el dicho de “no tenerle miedo a mostrar la guagua fea”. Esto significa que necesitamos reconocer que, en realidad, nunca nos sacaremos del todo la sensación de que el producto no está perfecto, en especial cuando es un producto digital que en teoría puede evolucionar eternamente.

Decidirse a lanzar requiere carácter y disposición a “dejar ir” una discusión o una idea en pos de obtener feedback de usuarios más temprano. La imperfección no tiene nada de malo; al contrario, muchas veces se convierte en el motor que mantiene un producto vivo. El problema es el estancamiento y el exceso de perfeccionismo que bloquea las mejoras.

Pragmatismo versus perfeccionismo

¿Cómo concilias entonces pragmatismo con perfeccionismo? ¿Cuándo sabes si es demasiado temprano o demasiado tarde para lanzar? Si lanzamos productos imperfectos al mercado, ¿esto significa que nunca los mejoraremos realmente?

La clave está en pintar las cosas claras al principio del proyecto: las ideas y suposiciones que traemos en la cabeza al empezar son sólo eso, suposiciones, y debemos deshacernos de ellas lo más pronto posible. Esto quiere decir que hay una cierta ventana de tiempo en la que podemos darnos el lujo de divagar, hacer brainstormings y debatir ideas; esa ventana se cierra y debe darle paso a las decisiones sustentadas en la experiencia en terreno, ya sea directamente de usuarios o a través de datos (analytics, métricas de negocio, etc).

Cuando entendemos que no tenemos todo el tiempo del mundo para divagar, nuestra misma mente se ordena y prioriza. Los seres humanos funcionamos mejor cuando tenemos la cancha rayada.

Cómo rayamos la cancha

Cuando comenzamos un proyecto de Lean UX en Continuum, lo primero que hacemos es explicarle al cliente la dinámica del proceso y comunicarle la necesidad de efectuar due dilligence. Las reglas son sencillas:

  • Como mencioné arriba, las decisiones tienen un cierto tiempo límite de ser tomadas si queremos cumplir con los plazos. Pasados esos límites, cualquier cambio de rumbo queda postergado hasta después de lanzar y obtener feedback de usuarios.
  • Además, las decisiones se toman en vivo en la mesa de trabajo. Esto requiere que estén las personas que realmente toman las decisiones en la mesa. Si la persona que toma la decisión es alguien que acostumbra ausentarse de las sesiones y delegar con sus subalternos, dejamos en claro que las decisiones de ese subalterno serán consideradas como definitivas.

Este último punto es especialmente delicado, dado que muchos clientes acostumbran a dejar a sus subalternos a cargo de asistir a las reuniones y tomar las decisiones; y cuando el cliente original llega a chequear todo al final del proyecto, se encuentra con cosas que no le gustan, y —dado que es quien manda— intenta cambiarlas. Y así volvemos a fojas cero.

En muchas empresas es costumbre que los proyectos vayan pasando por etapas de aprobación sucesivas, de creciente autoridad. De esta forma, la persona con el verdadero poder de decisión termina siendo la última en enterarse del proyecto. Nosotros hacemos exactamente lo inverso: las personas clave toman las decisiones importantes al principio y señalan el rumbo general del proyecto. Una vez que el proyecto está encauzado, las decisiones menores pueden efectivamente ser delegadas.

La técnica del aikido

Una de las bases del aikido y artes marciales similares es que nunca opones tu fuerza a la del atacante; por el contrario, rediriges la fuerza del ataque a un lugar en el que no pueda hacer daño. ¿Qué tiene que ver esto con evitar el Deadline Creep?

La idea es que cuando el cliente plantea “hey, pero sería bueno si añadimos esta última cosa antes de lanzar”, en lugar de oponernos respondiendo “no, no lo haremos” (que con toda seguridad comenzará una pelea), replicamos con: “Es una idea interesante, considerémosla para implementarla en la próxima iteración, cuando ya tengamos feedback de nuestros usuarios”.

No hemos dicho que no será implementada; sólo estamos diciendo que no todavía. Esto permite que ideas que surgen tarde en el proceso — ¡y que muchas veces son valiosas!— no se pierdan en el camino, evitamos que alguien sienta que sus ideas no son escuchadas, y al mismo tiempo reforzamos la idea de que tenemos un plazo que cumplir si queremos que esto avance.

***

Rayar la cancha requiere mucha confianza con el cliente… y también requiere mucha autoconfianza. No es fácil, pero el costo de no hacerlo a tiempo es perder la capacidad de cobrar estos acuerdos más tarde. Ésta es sólo una de las razones por las que un Líder de UX requiere carácter, diplomacia y habilidades de negociación.

Pero dejar claras las reglas del juego (con respeto, humildad y buena onda) es impagable, dado que construimos una dinámica de trabajo que va en favor de los mismos intereses del cliente: el proyecto se termina a tiempo, dentro de los costos, listo para ser hecho realidad. Las fricciones se minimizan: muchas veces el cliente sugiere ideas o cambios al final del proyecto porque nunca nadie le explicó que ya era demasiado tarde. Comunicarse en tiempo real y trabajar codo a codo reduce la cantidad de documentación y registros del proceso y permite que el equipo se enfoque en lo que realmente importa: crear valor.

Próximo artículo de la serie: Productos que no le sirven a nadie.

6 problemas típicos en proyectos UX – Parte 1: Feature Creep

En los años que llevamos en Continuum desarrollando proyectos de experiencia de usuario para una amplia variedad de clientes y necesidades, es imposible no notar algunos patrones comunes en la manera en que dichos proyectos evolucionan, sin importar el tamaño del proyecto, del equipo, de la empresa o incluso el tiempo y el presupuesto disponibles.

Con el tiempo, hemos aprendido a lidiar con ellos, con algunos de mejor manera que con otros. Probablemente el lector los reconozca también en su propia realidad. Hemos preparado una serie de 6 posts, cada uno identificando un problema en particular y algunas estrategias que hemos desarrollado para evitarlo o solucionarlo:

  1. Feature Creep
  2. Deadline Creep
  3. Productos que no le sirven a nadie
  4. Mala investigación
  5. Brecha entre diseño y desarrollo
  6. Waterfall UX

En este post en particular hablaremos de Feature Creep; una expresión difícil de traducir al español, pero que hace referencia al acto en el que las cosas se inflan o expanden sin control.

Feature Creep, o la ansiedad por tener más que el vecino

Es fácil identificar el feature creep en un producto: son esos “barriles sin fondo” donde la intención de satisfacer absolutamente todos los casos de uso posibles termina con productos atestados de funcionalidades, servicios y opciones

Es un problema bastante común y tiene varios causantes: demasiados stakeholders con similares posiciones de poder intentan inyectarle al proyecto su propia visión; inseguridad y miedo de ser el “rival más débil”; falta de priorización y el “diseño por comité”, que intenta buscar el consenso dándoles a todos la razón.

El resultado del feature creep son productos complicados, ambiguos, excesivamente ambiciosos y glotones, que intentan ser todo para todos. El razonamiento de fondo es que “si está en el producto, los usuarios lo encontrarán”. Pero si esto fuera cierto, sería tan simple como hacer mejores productos metiéndole más funcionalidades (y así, de hecho, fue la manera en la que Microsoft Office se convirtió en el mastodonte que es hoy).

En cambio, cuando las limitaciones y el desinterés de nuestros usuarios están presentes en el equipo, sientes la dolorosa necesidad de priorizar y simplfiicar. Google Docs entendió esto, y básicamente ofrecen menos funcionalidad que Office, pero con dos combos ganadores: el precio (gratis) y la edición en tiempo real. Así es como Google Docs se convirtió en la primera amenaza real que Office ha enfrentado en dos décadas.

Combatiendo el feature creep

¿Cómo vences la inseguridad de un equipo que siente que necesita una carrera armamentista para competir en el mercado? Conectándolo directamente con las necesidades de los usuarios. El golpe inicial de este feedback es doloroso, porque sin importar la experiencia y el conocimiento del negocio del equipo, los puntos ciegos (necesidades insatisfechas, suposiciones infundadas, estrategias erróneas) surgen de inmediato.

Pero la siguiente sensación es refrescante: el contacto continuo con los usuarios comienza a traer una nueva seguridad, basada en la evidencia y en el ensayo/error. Desarrollar la empatía con los usuarios y sus necesidades hace que priorizar sea fácil: cuando entiendes dónde les aprieta el zapato, las discusiones teóricas muestran rápidamente su irrelevancia.

Minimizar

Una segunda estrategia, que complementa la anterior, consiste en enfocar el trabajo hacia un producto mínimo viable. Cuando el equipo tiene como meta lanzar — y lanzar pronto —, las conversaciones se orientan hacia priorizar y ser pragmáticos. Ahora bien, el dilema que inmediatamente surge es: ¿qué tan mínimo tiene que ser el producto? ¿Y si nos excedemos y terminamos sacando al mercado un producto demasiado pobre? ¿Y si terminamos lanzando el set equivocado de funcionalidades?

¿Cómo sabemos?

Prototipa la historia

Una buena técnica es prototipar la historia de tus usuarios en relación al producto. Hay varias maneras de hacerlo: en forma de cómic, representación con títeres, radioteatro o role playing, entre otras.

Una vez que el equipo escogió una forma de contar la historia, hay cuatro cosas de las que preocuparse:

  • Contexto: Sitúa al usuario en medio de su realidad, en el lugar y momento en el que ocurrirá el problema.
  • Problema: Retrata el dolor del usuario.
  • Solución: Sitúa la idea del producto en acción, resolviendo el problema.
  • Desenlace feliz: Muestra el efecto posterior del producto y cómo el contexto ha mejorado gracias a éste.
low-fi_prototip016

Ejemplo del prototipado de una historia.

Este ejercicio por sí solo tiene el poder de mostrar qué es lo prioritario en nuestro producto, precisamente gracias a que lo muestra en el contexto de los usuarios y sus problemas. También es útil para probar diferentes soluciones o distintas estrategias, aunque en nuestra experiencia suele ser el mismo contexto el que te insinúa la solución.

***

Combatir el feature creep priorizando y reconectando al equipo con los usuarios finales aliviana notablemente los proyectos y los flujos de trabajo. Sin importar qué tan “clara y definida” parezca estar la estrategia, siempre hay espacio para afilar un poco más la propuesta de valor y asegurarse de que el beneficio del producto llegue de manera cristalina a quienes lo necesitan.

Siguiente post: Deadline Creep.

¿Qué se necesita para ser un Diseñador Móvil hoy?

Ésta es la traducción del artículo What Does It Take To Be A Mobile Designer Today?, que publiqué en UX Magazine y que apareció también en Mashable.

Las tecnologías móviles llegaron para quedarse, con su propio set de reglas y limitaciones. Al mismo tiempo, es una plataforma que evoluciona velozmente, saludando cada trimestre a nuevas tecnologías y capacidades. No podemos seguir diseñando para mobile como lo hemos estado haciendo con posters y páginas Web. Entonces, ¿cuál es la caja de herramientas y la actitud que necesita un diseñador mobile para salir airoso?

Desafíos y limitaciones

Todo medio o soporte tiene sus limitaciones, y mobile – siendo uno de los lienzos soñados para cualquier diseñador – no es la excepción:

Demasiados dispositivos distintos

Es imposible contar la cantidad de modelos de smartphones y tablets que andan sueltos, cada uno con su propio tamaño de pantalla, densidad de pixeles y botones físicos (sin mencionar las orientaciones de cada uno). Esto significa que no podemos tomar las dimensiones del iPhone 5 y diseñar tranquilamente en base a eso. En mobile Web, el diseño responsive nos permite planificar las variaciones y hacer que el diseño se ajuste a diferentes pantallas con poco esfuerzo. En las plataformas mobile nativas hay mucha menos flexibilidad, así que necesitamos concebir nuestros diseños como tolerantes a las diferencias de pantalla, y documentar la forma en la que dichas variaciones impactan el layout general.

Demasiados sistemas operativos distintos

A la fecha, tenemos tres sistemas operativos móviles importantes: Android, iOS y Windows Phone, en orden de uso (sin mencionar otros que ya vienen en camino, como Firefox OS o Tizen). Cada uno tiene su propio set de patrones de interfaz, inputs externos y lineamientos… y aún no hemos llegado a la variación entre versiones. Con Android las cosas se ponen aún más complejas: la versión de Android que un dispositivo usa estará influenciada por el fabricante del aparato (que, como por si fuera poco, puede superponer su propia capa de interfaz) y el equipo en sí mismo y sus capacidades de procesamiento (y mejor ni pensemos en el tiempo que corre desde que es lanzada una nueva versión de Android hasta que tu celular Android es realmente actualizado).

Incluso si esta fragmentación no hace variar demasiado el diseño, sí influencia la manera en la que los usuarios experimentan un OS y lo que esperan de sus aplicaciones. De muestra un botón: piensa que la experiencia de Android que tienen la mayoría de los usuarios en realidad son las interfaces creadas por TouchWiz (de Samsung) o Sense (de HTC).

Rendimiento y consumo energético

La manera en la que una aplicación es diseñada puede influir grandemente en la cantidad de energía que consume.  O dicho de otro modo, tu diseño puede dejar a tus usuarios sin batería. Efectos visuales innecesarios o demasiado espectaculares pueden necesitar procesamiento gráfico intensivo para correr; una página Web demasiado intensiva en JavaScript o efectos CSS3 puede consumir un montón de energía. Y mientras nuestro smartphone de alta gama recién comprado puede estar corriendo nuestra app suavemente, un equipo de 2 años de antigüedad puede estar sufriendo con ella.

De la misma forma, un consumo innecesario o absurdo de datos puede dejar a nuestros usuarios sin saldo, o en el peor de los casos, causarles enormes gastos en roaming (me ha sucedido). Por otro lado, si sólo probamos nuestra app con una conexión Wi-Fi de alta velocidad, jamás entenderemos cuál es la experiencia de un usuario que sólo puede acceder a una red EDGE.

Éstos son sólo ejemplos para ilustrar el hecho de que un diseñador mobile necesita entender el impacto que sus decisiones tienen en el rendimiento de una aplicación y el uso de los recursos de un dispositivo.

Costos y tiempos de desarrollo

No porque vimos algo en esa linda aplicación que acabamos de bajarnos, significa que es fácil o rápido de implementar. La manera en que diseñamos una app puede significar la diferencia entre cumplir o fallar con los plazos de desarrollo. Si no entendemos el costo asociado a las decisiones de diseño que tomamos, estamos básicamente poniéndoles esa “mochila” a los desarrolladores, y creando fricción para el futuro.

Cosas que hay que desaprender

Muchos de nosotros fuimos formados como diseñadores en una época donde lo digital era absolutamente experimental e incipiente. Esto, probablemente, ha sido el causante de que nos aproximemos al diseño digital desde un punto de vista estático (como cualquiera que exportó HTML directamente desde Fireworks podrá atestiguar). Este desalineamiento aún sigue siendo enseñado en la mayoría de las escuelas de diseño, tradicionalmente lentas para renovarse y adaptarse. Con la llegada del diseño mobile, la brecha se vuelve aún más amplia: las tecnologías móviles traen un lenguaje, un contexto y una forma de uso para la cual casi todos nuestros viejos métodos y herramientas se quedan cortos.

Es tiempo, entonces, de actualizarnos:

Mobile no es un lienzo

Tal como HTML tampoco es un lienzo, en caso de que no lo hayas reflexionado antes. No puedes llegar y lanzarle objetos como si estuvieras haciendo un afiche o una tapa de libro. Sospecho que diseñar en Photoshop no nos está ayudando mucho, dado que lo hemos estado usando para diseñar afiches y tapas de libros por dos décadas. Aún “pintamos” nuestras interfaces, cuando las diferencias de tamaños de pantalla y la naturaleza dinámica de mobile piden un acercamiento totalmente diferente al diseño.

Deja de pensar en pantallas, comienza a pensar en transiciones

Estamos recién empezando a darnos cuenta que diseñar en “pantallas” no da el ancho cuando se trata de diseño mobile. Gracias a aplicaciones como Facebook Paper o Yahoo! Weather, hemos visto que hay una nueva manera de diseñar, basada en transiciones y estados más que en imágenes estáticas.

Las transiciones, alguna vez vistas como eye candy innecesario, se han vuelto el centro de una experiencia móvil. No sólo le dan un tono vivo a la interfaz: son un elemento de diseño en sí mismos. Las transiciones comunican movimiento, espacio, cambio y jerarquía, y son un gran aliado en comunicarle al usuario la meta-estructura del producto. Todo esto vuelve el diseño basado en “pantallas” totalmente obsoleto.

Deja a un lado tu ego de diseñador

Esto es un poco como dejar la adolescencia: No necesitas ser todo el tiempo único y original, en especial si tu idea de ser “único” consiste en rediseñar un patrón de interfaz probado y conocido sólo porque te dieron ganas de hacerlo diferente.

En la mayoría de los casos, apegarse a los componentes y patrones de UI nativos es la jugada más inteligente para terminar una aplicación a tiempo. En lugar de abogar por tu set de controles diseñados desde cero, enfócate en crear una interfaz simple y efectiva, y ocupa tu talento gráfico en crear un branding que realmente brille.

Para inspirarte usa aplicaciones reales, no sitios de “inspiración para diseñadores”

Muchos diseñadores van a sitios como Behance o Dribbble en búsqueda de inspiración para su próximo proyecto móvil. Y claro, siempre encontrarás diseños hermosamente creados en dichos sitios. El problema es que, a menos que seas un diseñador mobile muy experimentado, estos mockups pueden ser sumamente engañosos. La mayoría son sólo eso: mockups que no han conocido la luz, que no han sido implementados en una aplicación real, usada por personas reales. Y es más, potencian la idea de que tú también deberías crear una interfaz nunca antes vista para estar en este juego (ver punto anterior).

Inspírate por aplicaciones reales. Mientras más exitosas, mejor: ésos son los diseños que ayudaron a un producto a crecer, que han sido probados y mejorados en el mundo real, y tienes la certeza de que pueden ser implementados.

Cosas que sí hay que aprender

Conoce tu plataforma

Tal como necesitas entender HTML/CSS para ser un buen diseñador Web, necesitas entender cómo funcionan y son hechas las aplicaciones móviles nativas. Y caramba que son diferentes a las páginas Web. Por ejemplo, el contenido no “fluye” como en las páginas Web, y eso cambia un montón la manera de pensar una interfaz: estamos acostumbrados a que el contenido se readapte automáticamente, y eso en mobile no sucede. No tendrás tampoco la magia de la herencia CSS para separar la presentación del markup. Ah, y se me olvidaba: no existe tal cosa como markup en móvil.

Tendrás que meterte en la documentación para desarrolladores, leer manuales y entender cómo las aplicaciones móviles son confeccionadas, compiladas y publicadas. Tal vez incluso te convenga aprender algo básico de Objetive-C o Java, que al largo plazo es una inversión de tiempo que vale la pena: podrás aprender el idioma de un desarrollador y diseñarás con eficiencia y factibilidad en mente.

Además, te tocará comprender cómo funcionan los App Stores, el proceso de aprobación y publicación, y tips para optimizar lo mejor posible el posicionamiento de la app en dichos buscadores.

Mira debajo del capó

Necesitas saber y entender cómo funcionan e interactúan las tecnologías móviles, sus partes y piezas y los servicios que un sistema operativo pone a disposición de sus apps. Acá tienes una lista para empezar: servicios de localización (basados en Wi-Fi y GPS), Bluetooth, Low-Energy Bluetooth, beacons, cámaras frontal y trasera, micrófono, giroscopio, acelerómetro, vibrador, lector de huellas digitales, reconocimiento facial, de voz y ojos, detección de taps… y la lista crece cada vez más. Y cada nueva tecnología abre un campo completo de posibilidades para nuevas generaciones de aplicaciones. Tu responsabilidad como diseñador es estar al día con la vanguardia.

Descubre qué tan lejos puedes llegar con componentes nativos

En realidad, si los sabes tratar, los componentes nativos de interfaz pueden darte un montón de libertad… pero necesitas saber exactamente cómo y cuándo. Si puedes realizar la mayor parte de tu interfaz con componentes nativos y un grado razonable de personalización, le salvarás una gran cantidad de tiempo a los desarrolladores, para beneficio de todos.

Conoce el flujo de trabajo de una aplicación móvil

Trabaja como trabajan los desarrolladores. Aprende sobre los distintos SDK’s móviles, instálalos y consigue echarlos a andar. Investiga sobre frameworks de integración mobile, como RubyMotion, Xamarin o Titanium. Conoce las nuevas plataformas de integración horizontal, como Parse, Layer o Stripe para los pagos. Averigua por qué Sencha o jQuery Mobile son una mala idea para la performance de apps nativas. Familiarízate con los IDE’s (lo cual probablemente implica que sueltes de una buena vez el Dreamweaver), las carpetas donde los assets gráficos están ubicados, los nombres que deben tener, etc.

Vuélvete un experto en sistemas de control de versiones, pull requests y en cómo usar correctamente sistemas tracker como Pivotal o Jira.

Apréndete los patrones de interfaz móvil, y úsalos

Los tres sistemas operativos móviles más importantes tienen similitudes y diferencias profundas en su modo de entender la interacción con un dispositivo móvil. Sus usuarios esperan distintas cosas de cada uno. Como un diseñador móvil, deberías estar completamente al tanto de dichas diferencias y detectarlas al vuelo (por ejemplo: ¿en qué se nota que el nuevo Skype para iOS toma elementos de UI de Windows Phone?).

No te quedes pegad@ con una sola plataforma móvil. Pruébalas todas, o al menos usa Android e iOS como tu teléfono principal durante 6 meses cada uno. Yo lo hice, y es fantástico: entiendes cosas de cada plataforma que jamás entenderás con el uso casual o mirando pantallazos. Además, cambiar te hará bien: los fanboys son los peores diseñadores mobile.

Documenta y explica tu UI

Ahora que sabemos que las pantallas no cuentan toda la historia, tendrás que documentar diferentes estados, transiciones y animaciones, así como la forma en que la app reacciona a los datos (o la falta de ellos) y al entorno en general. Llena tus mockups con notas y comentarios, entrega ejemplos de animación, y planifica para la orientación del dispositivo.

Adopta Lean UX en la fase de diseño

Un diseñador moderno debería ser un diseñador estratégico. Así que tu meta, más que simplemente “hacer algo bonito”, es asegurarte de que el diseño refleje todo lo que el equipo ha aprendido acerca del producto. Prioriza los prototipos rápidos para tener insights tempranos de lo que quieren los usuarios. Guarda el trabajo artístico detallado para más adelante. Asegúrate de que todo lo que se diseña está alineado con la propuesta de valor central y con las necesidades de tus usuarios.

En Continuum tenemos una metodología para Lean UX que tú también puedes usar en tu proyecto.

Adopta Agile UX a la hora de implementar

No puedes entregarle tus mockups al desarrollador y luego olvidarte del asunto, dado que la mayor cantidad de requerimientos de diseño surgirán a la hora de desarrollar. Siempre hay pantallas que no fueron consideradas previamente, nuevas transiciones y cambios de estado que requieren nuevos assets gráficos, o como mínimo una validación de diseño para asegurarse que todo está en orden. Ello requiere que estés presente y respondas en tiempo real.

Así que siéntate al lado de los desarrolladores, preparado para intervenir en el diseño cuando se necesite. De esta forma, los desarrolladores sólo tendrán su mente puesta en desarrollar, y no tendrán que tomar decisiones de UX para llenar tus vacíos.

Algunos tips extra para Mobile Web

Responsive no es la panacea

Por más que queramos creerlo, el diseño responsive no es la solución milagrosa para adaptar cualquier diseño a mobile. En algunos casos tiene sentido, en otros no. Es tu responsabilidad saber los escenarios en los que se requiere una solución móvil dedicada, y dónde un par de ajustes responsive permiten mantener una sola base de código. ¿Y si estás diseñando solamente para Web tradicional? CUEEEC, ya no existe la “Web tradicional”. Tu página será vista por dispositivos móviles de todas formas. Planifica tu layout para que se adapte armónicamente a diferentes tamaños de pantalla (mal que mal, responsive no es sólo para móviles). Y fíjate bien en los tamaños de assets: como ya dijimos antes, esa linda imagen de 1Mb que se te ocurrió poner de fondo puede significarle un gasto de datos, tiempo y plata a tus usuarios móviles.

Usa CSS y JS con precaución

Yo sé. Es lindo poder usar todas esas gradientes, animaciones, transiciones y sombritas de CSS3. Es lindo usar parallax. El problema es que estos elementos pueden estrujar la batería de un teléfono móvil, y te puedo asegurar que tu página no es más importante que la capacidad de realizar llamadas o enviar mensajes.  Mientras más efectos acumules, más trabada se sentirá la interacción y más energía consumirá.

Incluso los (aparentemente inocentes) selectores CSS3 pueden impactar la performance en equipos de gama baja. Prefiere siempre ID’s y clases, y trata de mantener baja la jerarquía de selectores. Así que, si te las puedes arreglar con #submit en vez de .main .container .form:first-child > div .submit, mucho mejor.

Usa las herramientas correctas

Esto de ninguna manera es una lista definitiva, y encontrarás alternativas fantásticas para muchas de ellas, pero aquí van varias herramientas realmente apropiadas para diseño móvil (algunas son gratis, algunas son basadas en Web, y muchas de ellas son sólo para Mac):

  • Sketch para diseño gráfico y exportar en alta resolución (@2x). Sketch es probablemente el heredero del ahora descontinuado y obsoleto Adobe Fireworks, y ha sido construido con mobile en mente.
  • LiveView y Sketch Mirror (un complemento de Sketch) para poder visualizar tu pantalla de computador en tu teléfono. Las cosas se ven y se sienten bastante distintas en un dispositivo móvil. Además, podrás fácilmente probar el tamaño de controles y áreas de interacción,
  • Origami (de Facebook) y Quartz Composer para interacción móvil y prototipado de animación. Esto es lo más cerca que podrás llegar a simular una interfaz nativa sin escribir código, y aunque es difícil de manejar al principio, te dará una buena idea del tipo de pensamiento lógico que deben usar los programadores.
  • PaintCode para crear gráficos e interfaces que pueden ser exportados directamente a código nativo Objective-C.
  • Software Web para mockups. Hay montones: Balsamiq Mockups, Axure, UXPin, Moqups, Proto.io, etc.
  • Flinto o Proto.io para crear mockups interactivos instalables en tu iPhone. Ofrecen una simulación bastante convincente de aplicaciones reales (aprovechando la capacidad de Safari de añadir botones Web a la pantalla de inicio).
  • ImageOptim para comprimir (en algunos casos, dramáticamente) tus archivos PNG y JPG sin perder calidad.
  • Software de control de versiones, Git o Mercurial dependiendo del entorno de trabajo de los desarrolladores. En lugar de enviarle un ZIP a los programadores, envía directamente tus imágenes como commits.

Todo esto ya está obsoleto

En realidad no tanto, pero el ritmo al cual avanza la tecnología móvil volverá todo este artículo sumamente incompleto, en un tiempo muy corto. A la vuelta de la esquina están ya los desafíos de diseñar para wearables, dispositivos inteligentes, hogares inteligentes, sensores… Si hay un talento que un buen diseñador mobile debe tener por sobre todos los demás, es el ser dinámico, flexible, proactivo y sumamente curioso. Ésta debería ser la última guía que leas antes de salir a aprender en terreno. Es la única forma de que te asegures un asiento en esta montaña rusa.

Si estás interesado en aprender más sobre el proceso de diseño para mobile, consulta la presentación de nuestro workshop de UX para móviles.

¿Cómo funciona el simulador de impuestos?

Este post es una explicación de como funciona el Simulador de Impuestos que creamos para que cualquier PYME pueda calcular el calcular el impacto aproximado de la reforma tributaria para su caso particular. Si eres socio de una empresa o tienes curiosidad para ver el impacto de la reforma en las empresas, debieras darle una mirada.

Supuestos

Si hiciéramos un simulador que funcione para todos los casos de manera precisa, terminaríamos con el equivalente del formulario de declaración de impuestos y tendrías que pedirle ayuda a tu contador para llenarlo. Por tanto, fuimos prácticos y creamos una herramienta simple que aproxima tu caso usando los siguientes supuestos:

  • La empresa tiene uno o mas socios, quienes participan de formas iguales en retiros de utilidades y quienes se pagan el mismo sueldo.
  • La empresa NO está acogida al regímenes tributario 14ter, ni a la renta presunta.
  • No se considera el impuesto de segunda categoría pagado por cada socio (en realidad descontado en su liquidación de sueldo, tal como le ocurre a todo el mundo que trabaja de manera dependiente).
  • Se considera el impuesto de primera categoría pagado por la empresa (20% de las utilidades este año 2014).
  • Se considera el diferencial en el global complementario de los socios producido por los retiros. Esto asumiendo que los socios pedirán a la empresa que cubra estos impuestos extras que pudieran producirse por haber retirado utilidades.

Para calcular la diferencia en el resultado, se consideran los cambios de la reforma en el siguiente orden:

  1. Eliminación de regímenes especiales 14bis y 14quater.
  2. Aumento de tasa de primera categoría del 20% al 25%.
  3. Incremento (o decremento) en el diferencial del global complementario producido por la renta atribuida (eliminación del FUT).

Los cálculos

Luego de ingresar la información el resultado se muestra gráficamente como en este ejemplo:

Continuum___ASECH_____Simulador_de_Impuestos__Reforma_tributaria_2014_Chile_

En primer lugar se calculan los impuestos hoy (“2014″)  considerando el 20% sobre utilidades más los pagos del global complementario de los socios, si es que se declaran retiros. Ese valor es el que aparece como “Impuestos hoy (2014) antes de la reforma”

Luego, en caso que el escenario incluya el uso del 14bis o el 14quater, se suma el efecto de retirar estas franquicias (es decir, de revertir el ahorro de impuestos que estas herramientas le generan hoy a la empresa). Esto aparece en la barra “…más impuestos por la eliminación del 14bis/quater” si es que aplica a tu caso (En el ejemplo de más arriba no aplica y por ende no aparece dicha barra).

Lo siguiente es calcular el 5% adicional sobre utilidades que pagará la empresa, por el aumento del 20% al 25% de la tasa de primera categoría.  Este valor es representado por la barra “…más el incremento del 20% a 25% (tasa de 1ra cat.)”

Por último se calcula el impacto en el global complementario de los socios bajo la modalidad de renta atribuida que incluye la reforma, que es el corazón de la eliminación del FUT. Este impacto puede ser favorable (devolución de impuestos) o desfavorable (impuesto adicional a pagar).

En el caso que hayan devoluciones, se representa por la barra “…menos la devolución automática (por eliminación del FUT)”. En el caso que haya impuesto adicional a pagar, se representa por la barra de “…más la tributación por utilidad atribuida (por eliminación del FUT)”. En el ejemplo el efecto es mínimamente favorable y puede verse en la barra verde correspondiente.

Todas las barras sumadas generan la última barra correspondiente a los impuestos a pagar con reforma. De esta forma se puede saber si la reforma afecta o no a la empresa y también se puede y apreciar muy rápidamente cuáles son los factures que más afectan.

Más información

Todo lo anterior es una descripción general de todos los cálculos, pero muchos de ellos tienen su propia complejidad. Por ejemplo, el cálculo del global complementario depende en qué tramo de ingresos, sumando sueldo y retiros (o renta atribuida en el caso con reforma) caen los socios. A cada tramo de ingreso de corresponde una tasa marginal, pero el cálculo no es tan fácil como llegar y multiplicar, pues también se debe descontar un monto  (que básicamente representa el impuesto de la porción de la renta que cae en tramos anteriores y por tanto se grava con tasas menores que la tasa marginal).  De igual forma funciona el impuesto de segunda categoría.  Por otra parte, el 14bis y el 14quater no tienen efecto sobre utilidades retiradas. También hay que considerar que el 14quater tiene un límite máximo de ingresos para los que aplica la franquicia (1440 UTM) y mas allá de eso se aplica el impuesto de primera categoría de manera normal. Todos esos son detalles que están incluidos en los cálculos descritos más arriba.

Para informate de todos estos detalles te recomendamos consultar con tu contador y/o asesor tributario. O si eres curioso y/o puedes leer código CoffeeScript puedes mirar el corazón del simulador, que está publicado en el github de Continuum.

Ágil, “Corrupto” y Orgulloso

Bob Martin defiende el juntar cultura con prácticas en su último blog post. De acuerdo a él,

“Sabes la cultura en la que estás observando las prácticas de las personas alrededor tuyo. Si ves una mujer con una burka, puedes adivinar su cultura. Si ves a una novia y novio rompiendo una copa, puedes adivinar su cultura. Si ves un grupo de niños agitando una vara hacia un burro de papel maché colgando de un árbol, puedes adivinar su cultura.

No puedes tener una cultura sin prácticas; y las prácticas que sigues identifican tu cultura.”

Ese razonamiento es muy estrecho. Si bien es cierto que las prácticas son probablemente la expresión más visible de una cultura, lo que a mí me importa más son los valores (o, si prefieres llamarlos así, creencias).

Piensen en como algunos movimientos/culturas se han hecho irrelevantes enfocándose en sólo prácticas. El catolicismo, al menos en esta parte del mundo, se enfocó mucho en asistir a misa y grabar algunos rezos en la memoria y muy poco en el valor y sentido de ser católico (por supuesto no es la única religión culpable de eso, pero los uso como ejemplo porque la Iglesia Católica era la religión principal indiscutida en la mayor parte de Latinoamérica hace no tanto tiempo, y está en decadencia constante).

Piensen en la cantidad de empresas que se congelaron a si mismas en una manera particular por enfocarse en practicas en lugar de sus propios valores y cultura. Se me viene rápidamente a la cabeza el caso de Microsoft y su “stack ranking” como uno de esos ejemplos.

No es una calle con un sólo sentido, sólo las prácticas como la expresión de culturas. Adherencia excesiva de los individuos a las prácticas puede destruir (quizás una mejor palabra sería diluir) una cultura.

Como llegué a mundo ágil

Me interesé en el movimiento de la  agilidad porque sus valores se alineaban bien con mis propios valores y mi experiencia trabajando en proyectos open source. Había visto como se puede hacer software de alta calidad sin toda esa basura de cascada. Había visto (por ejemplo) como unos pocos individuos (ligeramente) coordinados podían ganarle a un comité con procesos, dirección, lo que sea.

Quizás el único principio de la agilidad que no es obvio en el Open Source es “Colaboración con el cliente sobre negociación de contratos”, pero se puede hacer el punto de que la manera en que IBM, Google, Red Hat y cualquier otra compañía puede convertirse en un cliente del open source es colaborar con él.

Noten que hay muy poco en común entre las prácticas ágiles y las prácticas del open source mas allá de (en algunos casos) testing automático y (en menos casos) integración continua.

Yo probé TDD, Pair Programming, Continuous Integration, Reuniones ”Standup” frecuentes, y todas esas técnicas porque venían de gente con valores compartidos

En lo personal, aún practico muchas de ellas. Algunas de ellas algunas veces, otras casi siempre, otras rara vez.

Noten lo indefinido — lo relativo — reflejado en el párrafo de arriba. Eso no es, en mi opinión, un problema. Es algo bueno. Arranquen de la gente predicando verdades absolutas! (¡incluyendo esta!)

Lo que puedo observar en el equipo donde trabajo es la misma historia — valoramos la libertad de adaptar nuestras prácticas caso a caso, proyecto a proyecto. Por supuesto no cambiamos a tontas y a locas la forma en que trabajamos. Pero la cambiamos, probamos nuevas formas, experimentamos, fallamos, acertamos, intentamos de nuevo, exploramos. Ningún proceso es sagrado y nos gusta así. Si no fuéramos así, nos sería difícil seguir aprendiendo, descubriendo como trabajar literalmente distribuidos por el mundo, entre otras cosas.

Bob piensa de otra manera:

“[…] si te encuentras en un equipo que practica integración continua, iteraciones cortas, pair programming y TDD, es una indicación de que estás en un equipo que comparte los valores del manifiesto ágil. Si no compartieran esos valores, no seguirían esas prácticas.”

Pero eso es lógica errada. He visto gente con valores diferentes usando cartas gantt (¿chantas gantt?), estimación PERT y otras prácticas de gestión de proyectos, simplemente porque les fueron enseñadas dichas prácticas como estándar. Lo mismo puede pasar (¿está pasando?) con las prácticas ágiles.

El Ritualismo es un problema

Bob dice:

“[…] el ritualismo no ha sido el problema. No vemos mucha gente practicando de forma ritual pair programming, TDD, pequeños releases, cliente on-site, etc. Vemos gente adoptando estas prácticas por entusiasmo. Pero el entusiasmo no se debe confundir con religión o ritualismo. Entusiasmo implica un cambio en el statu quo; ritualismo implica justo lo contrario.”

Aunque no estoy para nada convencido sobre la supuesta distinción entre entusiasmo y ritualismo, me enfocaré en argumentar otro punto: el llamado statu quo no es una propiedad global del universo completo. Es fácil armar micro culturas donde su statu quo sea diferente del status quo de los otros.

Trabajé en un entorno donde las prácticas ágiles eran el statu quo. Y se sentían ambas cosas: entusiasmo y ritualismo (pero solo ritualismo según la forma de ver las cosas de Bob). Un amigo llegó al punto de testificar como experto en un caso judicial y decir que no adoptar ciertas prácticas ágiles era signo de poco profesionalismo.

A propósito:

”Por supuesto que buen software fue construido antes de TDD. Buen software se construye hoy sin TDD. Y qué? Esos hechos no implican nada sobre la efectividad de TDD.”

Cierto. Pero piensen por qué alguien tuvo que hacer un punto sobre como igual se puede hacer buen software sin TDD.

Yo lo he hecho sólo para rebatir a la gente entusiasta/ritualista que hace el punto absurdo de que no se puede hacer buen software sin las profesionales-mejores-prácticas-súper-híper-ágiles (como mi amigo testigo experto) y sospecho que lo mismo está pasando aquí.

Corrupción

Bob finalmente va tras los herejes:

Así, para mí, la verdadera corrupción de la agilidad está en lo que dice Holub:

“…agilidad es una cultura, no un conjunto de prácticas…”

No. Agilidad es una cultura expresada a través de un conjunto de prácticas.

¿Tal vez tales prácticas pueden cambiar y (dada la complejidad del desarrollo de software) no ser universales? Él está parcialmente de acuerdo con la primera parte:

¿Están esas prácticas escritas en piedra? ¿Son las 13 prácticas originales de XP la escritura sagrada? ¿Eres un apóstata si no practicas TDD? Por supuesto que no. Pero si no usas esas prácticas particulares, lo mejor es que uses algunas que sean tan buenas o mejores.

Desafortunadamente él parece creer en prácticas mas o menos universalmente buenas/mejores.  A veces no tengo idea si algo que probamos en Continuum va a ser aplicable para nuestro siguiente proyecto/cliente — Difícilmente podría saber si son generalizables incluso más allá.

Y en cualquier caso, ¿cómo se supone que uno sabe si una práctica puede ser igual de buena o mejor sin — ¡horror! — “corromperte” y desviarte de las prácticas “originales” para intentar algo distinto (por tanto creyendo que la agilidad es realmente acerca la cultura/valores/principios/creencias en lugar de tales prácticas originales)?

Por lo tanto, me declaro un profundamente corrupto agilista. Y estoy orgulloso de ello.

Proyectos remotos: Confianza, libertad, respeto y colaboración

En los últimos días estuvimos inmersos en el desarrollo de un prototipo funcional, como parte del proceso de licitación de un importante proyecto para un cliente internacional (un documento de confidencialidad nos obliga a omitir nombres).

Nada sorprendente ahí; no estaría escribiendo acerca de esto si no fuera por los desafíos de la naturaleza del proyecto: el cliente era de una localidad muy remota, digamos que era de China (sí, así de lejos) y el equipo de desarrollo estuvo distribuido entre Santiago, Lima y Miami.

La comunicación directa —elemento clave para inyectar agilidad a cualquier proyecto— era limitada: nos separaban muchas horas de diferencia con el cliente. Entre el equipo de desarrollo también teníamos la limitación de no estar sentados programando codo a codo. Lo que sigue es una retrospectiva de cómo lo hicimos, y es un buen reflejo de cómo hacemos las cosas en Continuum en general.

Reuniones con el cliente

A pesar de que el cliente nos hizo saber que estaría disponible, el problema era la diferencia horaria: cuando ellos trabajaban, nosotros “dormíamos”, y viceversa. Entonces tuvimos que definir un horario para las reuniones que nos acomodara relativamente a todos: Lima, por ejemplo, tuvo que entrar a Skype a las 6:00 AM. Por suerte la última semana el cliente viajó a Santiago, lo que facilitó las cosas. Al final hicimos cuatro reuniones de una hora, dos via Skype y dos presenciales en nuestras oficinas en Santiago.

Estrategia

Tal como un director de cine reúne al equipo y los actores para leer el guión y tomar decisiones, cada uno de nosotros leyó los documentos, tomó sus propias conclusiones y luego nos reunimos en Google Hangout a conversar. Decidimos que el tiempo no alcanzaba para hacer todo, así que implementaríamos solo una porción que sirviera para cumplir las expectativas del cliente.

Dado que estábamos distribuidos en diferentes locaciones, para que todos estuviéramos en la misma página y para tener feedback lo más temprano posible se usó un mockup, que evolucionó en las dos primeras reuniones con el cliente, y que sirvió a cada uno para saber qué componentes construir e imaginar como se *integraría/comunicaría* con el resto del sistema.

Ambiente remoto colaborativo

Acá no hubo que hacer nada especial. Como parte del día a día, en Continuum usamos un conjunto de herramientas que nos permiten colaborar remotamente. No está de más mencionarlas:

HipChat es la herramienta que usamos para comunicación entre los integrantes de un equipo dentro de un proyecto. El proyecto es creado como sala (la mayoría de las veces pública) y el equipo es invitado. HipChat trae clientes para la mayoría de las plataformas (desktop y mobile), lo cual vuelve posible estar offline y recibir notificaciones para estar presente cuando se te necesite. Otra buena alternativa a HipChat es, por ejemplo, Slack.

Yammer es nuestro Facebook privado y plataforma de comunicación multiuso. Sirve tanto para preguntar/validar temas técnicos, como para enterarnos de lo último en noticias o relajarnos y lanzar bromas. También para hacer saber al resto del equipo Continuum a que horas llegamos a la oficina o si estaremos o no disponibles y a través de qué canales.

BitBucket o Github. Usamos Git para compartir y versionar el código. Tenemos nuestra cuenta gratuita en GitHub para los proyectos Open Source (como ActiveImporter) y una cuenta pagada en Bitbucket para los proyectos privados, que incluyen a la mayoría de clientes (aunque también proyectos propios como Get On Board o BeautifulLogs están hosteados allí).

Google Hangouts. A veces conversar o vernos las caras acelera la comunicación, así que usamos Hangout, aunque también hemos estado probando con las llamadas de video de HipChat (aún en beta). Si hay algo que mostrar, tanto Hangout como HipChat permiten compartir una porción de la pantalla. Hangout o Skype es usado para las reuniones frecuentes con los clientes cuando éstos no pueden pasar a la oficina.

Ambientes de desarrollo e IDEs

No hay una regla general; sin embargo, casi todos usamos lo mismo. Creo que lo que sucede acá —y que supongo pasa en otros lados— es que cuando tienes un equipo equilibrado técnicamente y con la frecuencia de comunicación que tenemos en Continuum, las herramientas y procesos se tienden a nivelar, pasando de uno para otro y evolucionando. Por ende todos terminan usando aquello que por consenso se ve como la mejor herramienta. Por otro lado compartir código (Git) y cambiar los equipos entre proyecto también obliga en forma natural a que igualemos los ambientes.

Cultura

Todo lo anterior forma parte de nuestro día a día en Continuum, y son habilidades duras del equipo. Sin embargo hay algo que suele pasar desapercibido, y que a mi parecer es lo que hace al equipo y a la empresa *especial*. Es aquello que hace que lo que parece difícil termine siendo fácil y lo que parece imposible se haga realizable.

Me refiero a habilidades como la confianza, la libertad y el respeto. Estos son conceptos abstractos, así que los voy a intentar materializar en el contexto de este proyecto, que personalmente me sirvió para ver a donde habíamos llegado como equipo en el transcurso de estos casi seis años.

Una vez que estuvimos de acuerdo sobre lo que haría cada uno, pusimos manos a la obra. En Miami se construyó la arquitectura MVC, en Lima se hizo todo el diseño UX / UI y en Santiago se construyeron las componentes 2D y se mantuvo la coordinación del proyecto (mail y reuniones presenciales con el cliente). Sin embargo, y en retrospectiva, nunca se consideró el que fuera un proyecto 100% remoto como un problema: sencillamente nos pusimos a trabajar.

Nuestro Bitbucket está integrado con HipChat, así es que cada commit en el proyecto aparece en la respectiva sala de chat. En los ochos días que nos tocó desarrollar hubo exactamente 106 commits: muchos fueron independientes, algunos resolvían conflictos y otros cambiaban/refactorizaban código del resto del equipo. Mirar la entrada del commit en HipChat servía para saber que cambios se hacían, y entre commits conversábamos los cambios, discutíamos y tomábamos más decisiones en contexto.

Las partes se construyeron/probaron por separado y en cierto punto se hizo la integración: a partir de ese punto, todos trabajamos sobre el mismo código. Decidimos un plazo fijo con su respectivo deadline y todos nos ajustamos a él. Si quedaban cosas afuera, entonces ajustaríamos el alcance del prototipo: la idea era evitar el típico stress de hacerlo todo en plazos apretados. Los últimos commits fueron todos trabajando en el código de todos.

La compilación, empaquetado y envío del entregable fue exactamente a la hora acordada. Una hora antes tuvimos el último Hangout, donde resolvimos en conjunto pequeños problemas de último momento y nos pusimos todos de acuerdo en las limitaciones. Halagos y felicitaciones siguieron a la entrega.

Conclusiones

No es fácil encarar un desafío como este y cumplirlo, hace falta tener habilidades técnicas, hablar buen inglés, saber gestionar en forma ágil, etc. Pero creo que incluso eso es sólo una parte: hace falta tener valores como colaboración, respeto, confianza y libertad incorporados en la cultura de tu empresa; tan incorporados que se dan por sentados, de modo que uno simplemente llega y se pone a escribir código junto a tu co-worker, sin importar el país o la zona horaria donde esté.

Y con éste, a la fecha hemos realizado al menos tres proyectos con naturaleza 100% remota: todos diferentes, con distintos grados de complejidad, pero con un denominador común: la cultura de Continuum haciendo posible lo que a muchos les parece imposible.

Validation Onion: La UX es mejor por capas

Mi llegada a Lean UX fue una mezcla de intuición y accidente. Comencé a darme cuenta que los mismos problemas surgían una y otra vez en los proyectos en los que participábamos en Continuum: ideas que se ejecutaban sin ser cuestionadas, gerentes entrando al final del proyecto a cambiarlo todo desde cero, decisiones de diseño dominadas por el debate de “yo creo” versus “a mí me parece que”, diseños que al ser implementados por los desarrolladores terminaban desbaratados… ¿les suena?

Muchos se encogen de hombros y dicen que “así es la industria”, “así son los clientes”, y pavadas por el estilo. En realidad todos estos problemas son un defecto de gestión: los diseñadores tendemos a traspasar pasivamente al papel lo que escuchamos en las reuniones, como si se tratara de un retrato hablado. El rol de un diseñador debiese ser más bien el de un líder y moderador, que por añadidura tiene talento para plasmar ideas abstractas en productos y sistemas concretos. Pero, desde luego, es más fácil decirlo que hacerlo.

Pues aquí van cuatro ideas para empezar a allanar el terreno:

1) Todos deben estar sentados en la mesa desde el principio

Todos: diseñadores, desarrolladores, el dueño de la idea, las áreas involucraadas y todos quienes tienen potencial de estorbar o cambiarle la dirección a un proyecto.

Cuando todos están participando de las decisiones desde el principio, se minimiza el tener que volver atrás, y por ende se reduce el riesgo (y menos riesgo equivale a más dinero). Asimismo, el trabajo de UX es alinear todas las visiones y necesidades en torno a una sola propuesta de valor. Cuando no hacemos este trabajo, se termina volviendo en contra nuestra en forma de constantes retrocesos y limitaciones que van apareciendo en el camino.

2) Amplía tu concepto de prototipo

¿Para qué prototipamos? Para saber si las cosas van a funcionar antes de construirlas a gran escala. Usualmente aplicamos esta idea a cosas físicas o tangibles. Pero ¿qué hay de las ideas abstractas que soportan a un producto o negocio, como la propuesta de valor?

Hay un concepto de simulación inherente en el prototipo, que es necesario para tomar el atajo entre la idea y la realidad. Y aquí viene la idea clave: las cosas intangibles también pueden ser prototipadas. Una idea de negocio, por ejemplo, puede ser prototipada llamando por teléfono a varios amigos y contándoles de un nuevo servicio que acaba de salir, como si existiera.

Prototipar las ideas antes siquiera de construirlas es especialmente útil porque no sólo lo necesitas para refinar tu propuesta de valor, sino también la manera de comunicarla.

3) La documentación está viva e incompleta

Nuestra memoria es frágil, pero nuestra memoria emocional lo es aún más (es así como nos enamoramos y des-enamoramos). Y entre las cosas que olvidamos más rápido es la motivación que tenemos para hacer algo. Todos hemos estado en esos proyectos (o empleos) donde todo es risas y canciones al principio, para un par de meses más tarde terminar exhaustos, desmotivados y preguntándonos quién nos mandó a meternos en esto. Necesitamos documentar tanto lo que vamos aprendiendo en el camino como las razones por las que este proyecto vale la pena: su propuesta de valor.

Y al mismo tiempo, esta documentación nunca puede ser una biblia dogmática, sino todo lo inverso: un punto de partida, un registro que está constantemente actualizándose. Si consideramos una documentación como “terminada”, significa que hemos dejado de aprender. Por eso es una buena idea que el registro sea una wiki o un Google Doc, algo que reciba las colaboraciones de todos y que se mantenga en continua edición.

4) Las decisiones más importantes vienen primero

Tal como en una casa el techo no puede ir antes que los cimientos, en los productos y servicios orientados al usuario también hay una jerarquía y orden lógico, sin el cual la construcción no tiene sentido. El problema es que, a diferencia de una casa mal construida, en el mundo digital es difícil distinguir cuando las cosas han sido hechas en desorden.

Y es así como tenemos proyectos que comienzan por el diseño gráfico y el look&feel antes de preocuparse de si el producto merece ser hecho en primer lugar. El orden en el que se construye un producto digital no es trivial; se gastan recursos de tiempo y dinero construyendo cosas que no han sido validadas en primer lugar. Podemos pasarnos meses iterando sobre una interfaz, para luego construirla y descubrir que nadie la quería.

Esto se conecta con el punto 1: dado que las decisiones más importantes para el proyecto son las que ocurren al principio, tiene sentido que estén todos los actores importantes en ese momento.

Imagino que el lector se preguntará: Ok, si hay un orden lógico, ¿cuál es?

Aquí es donde entra Validation Onion.

Cuatro capas de validación

Estas cuatro capas tienen una cierta inspiración en el modelo de capas de Experiencia de Usuario propuestas por Jesse James Garrett:

1) Scope. Aquí validamos la razón de ser del proyecto: su propuesta de valor, sus usuarios, la necesidad que soluciona, la variable que lo vuelve innovador respecto a lo ya existente, las limitaciones y recursos humanos y técnicos para llevarlo a cabo, etc. Esta capa debe asegurarse de que existe mercado: que hay personas con una necesidad concreta, dispuestas a comprar/usar el producto para satisfacerla.

2) Estructura. Una vez que hemos validado que el proyecto merece existir, debemos asegurarnos que sus features y funcionalidad son exactamente las requeridas a este punto. Esto también implica eventualmente definir una estrategia para construir un producto mínimo viable (MVP) y un roadmap de futuras funcionalidades en el caso en que el MVP se valide con los usuarios. Esta capa se asegura de que el producto sea simple en su esencia, más allá de su interfaz. La Arquitectura de Información es clave en este punto para definir flujos de usuario y la manera en la que se organiza el contenido.

3) Interfaz. Una propuesta de valor sólida y una estructura clara y entendible por los usuarios son la materia prima perfecta para un correcto diseño de UI. Aún cuando es cierto que empezaremos a prototipar desde la fase 1, es aquí donde se concentran todos los esfuerzos de lograr una interacción simple y elegante. No interesa el look&feel en este punto; esta capa se asegura de que el producto sea usable y sea percibido como simple.

4) Identidad. Cuando todo lo anterior ha sido definido, aquí validamos que el producto sea atractivo y enamore por su aspecto. En este punto los valores definidos en el Scope son más fácilmente trasladables a un diseño de marca; los aspectos diferenciadores de la interfaz (“signature moments”) son enfatizados, y a todo el producto se le da un carácter único.

Sólo el comienzo

Cada una de estas capas de Lean UX merece un artículo aparte. Existen metodologías y herramientas que facilitarán la validación en cada etapa, muchas surgidas de la experiencia aplicando Validation Onion en proyectos de muy variada naturaleza.

En las primeras versiones de esta metodología, las capas se llamaban “fases”. Me parece mejor el nombre “capas”, dado que sugieren una cierta simultaneidad; no podemos ver una sola totalmente abstraída de las demás. Por ende, incluso habiendo un orden lógico para estas capas, pronto se comienza a ver que los insights y decisiones de una capa impregnarán a las siguientes.

Este proceso está pensado para ser rápido y ágil: no debería durar más de 5-6 semanas para los proyectos más complejos. El trabajo de UX que demora meses antes de sacar algo a la luz no tiene cabida aquí. Los procesos largos, que toman meses, usualmente parten de una noción equivocada: que “tiene que resultar bien a la primera”.

Esto no es cierto: dado que no estamos construyendo cohetes espaciales o equipamiento médico, hay un cierto margen para la imprecisión. Dicha tolerancia al error es aprovechada por Lean UX, demorándose menos en validar con usuarios productos incompletos y premisas imperfectas. Esta agilidad permite aprender antes de los usuarios, disminuyendo el riesgo del proyecto antes que se gasten grandes sumas de dinero en construir e implementar.

Si quieres saber más sobre esta metodología, mira esta presentación.

Éste es un post que publiqué originalmente como invitado en el blog UX in Perú.

El futuro de Bitcoin

Ultra-resumen: En mi opinión, el éxito de Bitcoin depende principalmente en derrotar a las tarjetas de crédito, paypal y similares como una forma de comprar cosas online. No está claro de que los vaya a derrotar. Lee más para ver por qué.

Moraleja: No se obsesionen con los costos ni con la tecnología. Fíjense en la experiencia de usuario.

Donde Bitcoin no tiene futuro

Voy a empezar estableciendo que Bitcoin es una mala idea si se la piensa como la moneda de cualquier economía en expansión. Ser “deflacionaria” es un problema, y no algo positivo, pues incentiva a acumular la moneda en lugar de gastarla, lo cual si es hecho por muchas personas tiende a paralizar la economía.

Lo que sigue es sobre cómo sin ser la moneda, Bitcoin puede igual ser una moneda. No ser la moneda significa que es poco probable que Bitcoin funcione como “Unit of Account” (Unidad de Cuenta), esto es, la cosa contra lo que comparas los otros bienes. Como cuando piensas en el precio de la leche (o de cualquier cosa) en pesos chilenos si vives en Chile o en soles si vives en Perú y así según donde vivas y cómo se llame tu moneda.

Sin embargo, una moneda tiene muchas funciones y “Unit of Account” es solo una de ellas. Las otras dos funciones muy importantes son “Store of Value” y “Medium of Exchange”.

(He usado los términos en inglés para las funciones de la moneda para que los interesados en leer más tengan una buena referencia; las versiones en español en Wikipedia de los artículos linkeados son sumamente pobres)

Donde Bitcoin puede tener futuro

Si en un determinado lapso de tiempo (digamos, este año) resulta que produces (te pagan) más de lo que consumes (pagas por tus gastos), es muy probable que quieras guardar ese extra que te sobra para usarlo en el futuro (digamos, para las vacaciones del próximo año).

Algo es un “Store of Value” (Almacén de Valor)  si puedes usarlo para convertir ese extra que te sobró, y además luego tengas una alta posibilidad de poder hacer la conversión de vuelta en consumo con un valor similar al que guardaste. En una economía estable, tu moneda es un “Store of Value” que puedes usar simplemente apilando billetes bajo el colchón.

Cuando la economía falla de cierta manera y se dispara la inflación, tu moneda deja de ser un “Store of Value” (digamos que los precios se duplicaron en un año y que el dinero que te costó tanto ganar y con el que planeabas viajar alrededor de toda Europa ahora apenas cubre el pasaje de avión inicial). En esos casos uno puede ver a la gente buscando “Stores of Value” alternativos, como la moneda extranjera (típicamente dólares) y metales preciosos (oro, plata).

Lo interesante es que Bitcoin ha estado en demanda por parte de gente viviendo en ciertos países donde la economía no ha andado precisamente bien, dándole a Bitcoin el status práctico de “Store of Value”. Si bien eso es genial, hay que mantener la perspectiva y darnos cuenta de que Bitcoin sólo juega ese rol cuando las alternativas (dólares, euros, oro, etc) dejan de estar disponibles.

¡Oh, pero estás equivocado! Dado que los Bitcoins van a subir de precio en el futuro, son mejores “Stores of Value” que el oro, dólares, etc

— Fanboy de Bitcoin

Uno puede escuchar cosas como esa de parte de los “creyentes” en Bitcoin. Como probablemente te has dado cuenta, nuestro fan está equivocado. Un buen “Store of Value” tiene que ser predecible. ¡La lesera se llama almacén de valor y no inversión ni apuesta por una razón! Algo volátil es — por definición — un mal “Store of Value”.

¿Te gustaría tener una caja fuerte en la que guardes algo de dinero y luego (mediante algún raro proceso) tengas una posibilidad de que el dinero ingresado se duplique, pero también una posibilidad de que el dinero se divida por la mitad una vez abras la caja fuerte? Si bien acepto que a algunas personas le puede gustar la idea de jugar con tal artefacto, lo mas probable es que no lo describirías como una caja fuerte a tus amigos.

Por lo tanto, ahora mismo, Bitcoin es un “Store of Value” viable solo cuando estás cagado y no puedes encontrar alrededor tuyo ninguno de los muchos mejores “Store of Value” que existen (lo que lamentablemente pasa, y por tanto la existencia de Bitcoin hace el mundo un poco mejor).

¿Que pasará más adelante cuando Bitcoin sea menos volátil? Bueno, para que Bitcoin no sea volátil tiene que dejar de ser un jueguito en el que “inviertes” y pasar a tener un valor real y concreto. Valor que sea estable según las expectativas de mucha, mucha gente.

Y de esta forma vamos llegando a la tercera función del dinero: “Medium of Exchange” (Medio de intercambio). Si Bitcoin se puede establecer como una buena manera de pagar por cosas que quieres, no se puede negar que tomará valor debido a eso.

Donde Bitcoin debe tener futuro (para tener éxito)

Por supuesto nuestra perfectamente funcional “Unit of Account” (es decir, tu moneda local) , que además es la mayor parte del tiempo un decente “Store of Value” (guardándolo bajo el colchón o en cuentas de ahorro) es también un perfecto “Medium of Exchange” (Medio de Intercambio). ¡Lo usamos todo el tiempo para comprar cosas y para que nos paguen!

La pregunta a hacer entonces es: ¿Qué puede Bitcoin hacer mejor que la moneda local? Veamos algunas respuestas:

  • Evitar impuestos. Si me pagas en Bitcoins (hoy, en muchas partes del mundo) no estoy obligado a llevar contabilidad de ese pago (¡ni tú tampoco!). Así que podemos ser parte de la “economía informal” y evitar pagar IVA, impuestos a la renta, etc. Si bien eso es probablemente ilegal en muchos países, es también probablemente difícil para dichos países el hacer cumplir la ley que lo prohíbe, así que puede funcionar. Pero tomemos una vista con un poco más de perspectiva: Quitarle a los gobiernos y estados la habilidad de recaudar fondos es una excelente manera de convertirse en los enemigos de los gobiernos y estados. ¡No suena como una estrategia brillantemente sostenible! Así que asumamos que si Bitcoin se vuelve suficientemente popular para volverse un problema para los gobiernos y estados, ellos encontrarán una forma de cobrar impuestos sobre Bitcoin. De hecho ya está pasando en algunos países. Así que vamos a otras ventajas sobre la vieja y querida moneda local.
  • Transferencias electrónicas remotas (casi) instantáneas. Esta es una ventaja grande, especialmente cruzando fronteras. También puede ser algo grande dentro de algunos países, en especial cuando hay cobros asociados a transferencias entre bancos — acá en Chile sólo necesitas una cuenta bancaria y puedes transferir tu dinero a cualquier otra cuenta bancaria de manera electrónica, sin costo adicional y con confirmación instantánea (con algunas restricciones en los montos, pero nada que te haga problema como individuo). De hecho el retraso de Bitcoin en confirmar transacciones (que dependiendo de cuántas confirmaciones quieres puede tomar varias horas) es una desventaja para nosotros los chilenos, y para cualquier otro ciudadano de un país con un sistema bancario decente. Pero para hacer compras entre países distintos no nos queda otra que las “wire transfers” y las tarjetas de crédito, que incluyen cobros (3% y más) para una o ambas partes involucradas. Si Bitcoin lo puede hacer mejor, se puede convertir en el PayPal del futuro.

¿Pero puede realmente?

Antes de contestar esta pregunta, hagamos un resumen de nuestro camino hasta ahora: Es muy poco probable que Bitcoin se conviertan en “Unit of Account”. Y sólo será un “Store of Value” decente si su naturaleza como “Medium of Exchange” termina funcionando bien. Y para tener alguna oportunidad de ser un buen “Medium of Exchange” tiene que ganarle a las  Tarjetas de Crédito y a otras maneras electrónicas de transferir dinero alrededor del mundo. Por eso nos estamos preguntando que cosas Bitcoin hace mejor que esas maneras “antiguas”.

¡Comisiones! Esta es una de las típicas respuestas. Pero tal como yo no tengo una cuenta en dólares en mi banco para hacer mis compras ocasionales en Amazon u otras transacciones internacionales, veo muy poco probable que vaya a tener bitcoins guardados en algún lado. Si quiero comprar algo en bitcoins, voy a hacer un cambio de pesos chilenos a bitcoins y el vendedor intercambiará de bitcoins a su moneda local. Eso es fácil una comisión de 1% considerando ambos intercambios. Además hay comisiones que en algún momento tendrán que cobrar los “mineros” de bitcoins cuando la recompensa por sumar su poder de cómputo a la red bitcoin deje de ser en forma de nuevos bitcoins recién creados. Pero aún así, si decimos que la comisión total bordea el 1.5%, eso es mucho mejor que el 3% (y más!) de las tarjetas de crédito.

Claro que hoy muchos consumidores no perciben ninguna comisión en el uso de tarjeta de crédito debido a que los costos son pagados por los vendedores, pero asumamos que los vendedores encontrarán una forma de incentivar a la gente a usar bitcoins si las transacciones en bitcoins les ahorran dinero. Check!

El fraude es otra cosa que la gente menciona como una ventaja de los Bitcoins comparados con los métodos de pago electrónicos que existen. Y yo creo que están terriblemente equivocados. El fraude es mucho más peligroso con Bitcoins, sólo que de una manera diferente.

Por supuesto que los vendedores, a diferencia de la situación actual, pueden estar seguros que recibirán el pago por los bienes vendidos — aunque me pregunto como lo harán con bienes digitales: ¿los enviarán sólo después de un par de horas, una vez que la transacción se confirme? ¡eso sería un tremendo desincentivo para mí! —. Pero si alguien hackea a cualquiera de las partes que pueden transferir Bitcoins, el peligro no está limitado más que a la cantidad de Bitcoins disponibles en la “billetera” Bitcoin hackeada. Y esto incluye las billeteras de los consumidores, de los vendedores, de las casas de cambio, etc.

Simplemente mira lo que está pasando con el hackeo de varias casas de cambio de Bitcoins en esta fase temprana. Ahora piensa lo que pasa cuando las potenciales víctimas (cualquier computador que contenga una billetera con bitcoins) sean más ubicuas.

Los participantes de este mercado tendrían que tener pólizas de seguro contra este tipo de pérdidas, o partir asumiendo que tendrán dichas pérdidas. Lo que termina siendo lo mismo: Para cubrir este costo de pérdidas tendrán que cobrar más comisiones las que — dependiendo de que tan frecuente los robos de bitcions ocurran — podrían incluso superar a las comisiones que vemos hoy en los medios de pago tradicionales.

Así que terminamos con un caso débil basado en comisiones potencialmente más bajas. Eso no es suficiente.

Yo creo que la batalla real será en conveniencia. Las compañías de tarjetas de crédito hacen lo imposible para hacer el plástico más conveniente que el efectivo cuando ambas alternativas están disponibles. Por supuesto que el crédito en sí mismo es una de esas conveniencias. Pero también tienes disponibilidad, facilidad de uso y hasta “puntos de fidelización”. Y han tenido éxito en muchos mercados, incluso con costos inherentemente más altos. ¿Cómo es eso posible?

Porque los costos no importan mucho cuando en retorno ofreces un valor mucho mayor.

Estaré listo para “creer” en los Bitcoins como un “Medium of Exchange” viable cuando el ecosistema Bitcoin encuentre una forma en que uno disfrute pagando con bitcoins más que con tarjetas de crédito o transferencia bancaria electrónica.

Eso aún no ocurre.

Presentamos ActiveImporter: De Excel a ActiveRecord en pocas líneas de código

A los desarrolladores nos gusta usar YAML o JSON para serializar y almacenar información para ser consumida por nuestras aplicaciones. Pero lo cierto es que a menudo nuestros softwares necesitan consumir información ya disponible en otros formatos. Las hojas de cálculo o spreadheets son un ejemplo común, en especial el formato Excel de Microsoft Office.

Acá en Continuum nos hemos encontrado en esta situación más de una vez. A menudo nuestros clientes necesitan que sus aplicaciones sean capaces de importar información en formatos de datos que ellos mismos puedan generar y proveer. ¿Y qué otro formato de uso generalizado y fácil para ellos sino el Excel? Afrontémoslo: necesitamos hacer interfaz entre nuestros sistemas y los formatos de hojas de cálculo, nos guste o no.

En el mundo de Ruby ya tenemos la gema Roo, más que suficiente para abrir y leer los contenidos de los más comunes formatos de hojas de cálculo que hay por ahí. Pero eso es sólo la mitad del proceso. La información no se importará en nuestros modelos de datos por sí sola, ni por arte de magia. Y de esta necesidad es que hemos creado active_importer.

Lo básico

Al inicio necesitábamos una interfaz simple y genérica entre las hojas de cálculo y nuestros modelos de datos. El enfoque más sencillo inicialmente consistía en declarar una equivalencia o mapping entre las columnas de la hoja de cálculo y los atributos del modelo. La intención era que el importador se ocupara de todo el trabajo sucio: identificar la fila de encabezado de la tabla, iterar por las filas, y crear un nuevo registro en el modelo de datos tomando las celdas de la tabla de acuerdo al mapping declarado. Así que partimos tratando de lograr algo como esto:

class EmployeeImporter < ActiveImporter::Base
  imports Employee
  column 'First name', :first_name
  column 'Last name', :last_name
  column 'Department', :department
end

Con la intención de invocarlo de esta forma:

EmployeeImporter.import('/path/to/some/spreadsheet.xlsx')

Es una caracterización bien directa de lo descrito anteriormente. Así que comenzamos con esto en mente, y desarrollamos la librería que le diera vida a este código.

Relaciones

Pero esperen: usualmente el modelo de datos que se puede inferir del ejemplo anterior no se diseña para que el nombre del departamento se almacene repetido como cadena de caracteres en cada registro de empleado. En lugar de esto, se debería crear un modelo de datos Department, y luego asociar a cada empleado con el registro de departamento que le corresponde. Así que no podemos asignar el valor de la tabla directamente al atributo del modelo. Necesitamos que el importador busque el departamento con el nombre dado, y asocie al registro de empleado con el departamento encontrado. Así que se nos ocurrió hacer algo como esto:

class EmployeeImporter < ActiveImporter::Base
  imports Employee
  column 'First name', :first_name
  column 'Last name', :last_name
  column 'Department', :department do |department_name|
    Department.find_by(name: department_name)
  end
end

Al añadir un bloque a nuestra declaración de columna, podemos procesar el valor a asignar al atributo del modelo, en lugar de asignar ciega y directamente.

Actualizar en lugar de crear nuevos registros

Luego de un corto tiempo este enfoque tan sencillo demostró tener algunas deficiencias. Por ejemplo, ¿qué pasa si no queremos que el importador siempre genere nuevos registros por cada fila procesada? Los datos en una fila dada de la tabla pudieran referirse a registros ya existentes, y la intención en ese caso sería actualizar el registro en cuestión. Lo que necesitamos es una manera de indicarle al importador si una fila de la tabla corresponde a un registro ya existente, en cuyo caso debe actualizarlo, o sino crear un registro nuevo.

class EmployeeImporter < ActiveImporter::Base
  imports Employee

  fetch_model do
    Employee.where({
      first_name: row['First name'],
      last_name: row['Last name'],
    }).first_or_initialize
  end

  # ...
end

Aquí estamos programando al importador para que busque si existe un registro de empleado con el nombre dado, en cuyo caso se actualiza ese registro con los restantes datos de la fila. De no existir se genera un nuevo registro de empleado para insertar estos mismos datos.

¿Qué sigue?

Esto es sólo la punta del iceberg de lo que hemos logrado con active_importer. Le hemos añadido nuevas funcionalidades, todas surgidas de la necesidad en distintas circumnstancias: callbacks de eventos, parámetros personalizados, manejo de errores, omisión de filas, abortar el proceso, e incluso habilitar soporte de transacciones. Hemos ido documentando todo en el wiki del proyecto en github. El proyecto es aún bastante joven, con un gran potencial para ser mejorado en el futuro, y realmente esperamos que resulte de interés para otros desarrolladores que se vean en la necesidad de implementar este tipo de funcionalidad en sus aplicaciones.

Y por supuesto, es un proyecto de código abierto, así que las contribuciones son muy bienvenidas, ya sean reportes de errores, sugerencias de nuevas funcionalidades o pull requests.