¿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.

Tips sobre cómo escribir, por C. S. Lewis

No, no soy un fan de las “Crónicas de Narnia” ni nada por el estilo. Pero me topé con esta carta del autor de esta exitosa serie, con tips sobre cómo escribir, que la verdad permanecen vigentes y aplican a cualquier idioma. Por algo era escritor el tipo, después de todo.

Como hoy en día es tan importante la comunicación escrita (¿se han fijado cuantos e-mails escriben al día?), me pareció que sería un aporte traducir los tips del señor Lewis para beneficio de todos. Acá van:

  1. Siempre intenta usar el idioma de manera que quede claro lo que quieres decir, y asegúrate que tu oración no pueda significar ninguna otra cosa.
  2. Siempre prefiere una simple palabra directa que una larga y vaga.
  3. Nunca uses sustantivos abstractos cuando sirvan los sustantivos concretos. Si quieres decir “Murió más gente”, no digas “Subió la mortalidad”.
  4. No uses adjetivos que meramente nos dice como quieres que nos sintamos sobre lo que sea que estás describiendo. Quiero decir: en lugar de decirnos que algo fue “aterrador”, descríbelo de forma que nos aterrorice. No digas que algo es “encantador”, haz que nosotros digamos “encantador” cuando leamos su descripción. Ya ves, todas esas palabras (horroroso, maravilloso, horrible, exquisito) son sólo como decirle a tus lectores “por favor hagan el trabajo por mí”.
  5. No uses palabras que queden grandes. No digas “infinitamente” cuando quieres decir “muy”, de lo contrario no te quedarán palabras disponibles para cuando quieras hablar de algo realmente infinito.

Las negritas son mías, en lo que me pareció más interesante.

PD: Por supuesto todo depende del contexto. Nadie puede negar que Apple tiene éxito diciéndole a sus usuarios cómo sentirse con sus productos y usando la mayor cantidad de superlativos posibles. Sospecho que su truco es que también se esfuerzan para que los usuarios se sientan de esa forma cuando usan sus productos.

Bullshit Gamification, o cómo evitar tratar a tus usuarios como tontos

(aka Bullshification, créditos para Leo)

No cabe duda que el Gamification (a los gringos siempre les suenan mejor estos neologismos) está en boga. En un sentido muy amplio, esta estrategia consiste en recoger elementos o dinámicas propias de los juegos (o del estado lúdico) y aplicarlos a cosas que no lo son, con el objetivo de mejorar la motivación de los usuarios. La exitosa campaña The Fun Theory de Volkswagen se basa en este principio, aplicado a elementos del mundo físico.

Pareciera que aplicar Gamification es la panacea para lograr engagement y usuarios felices. ¿Es así realmente? Veamos: Foursquare, que durante mucho tiempo se ha erguido como el ejemplo estrella del Gamification, ha dado cada vez más pasos para desprenderse de los puntos, las alcaldías y las medallitas, y en Stack Overflow, uno de los sitios preguntas/respuestas más exitosos, dicen que Gamification realmente no fue la clave de su éxito. Pero por otro lado tenemos ejemplos como el de Duolingo y su uso de Gamification para enseñar idiomas que ha funcionado de maravillas.

¿En qué va? ¿Es culpa o no del Gamification? Tal vez es culpa de cómo se entiende y dónde se aplica. A continuación, algunas ideas al respecto.

Las medallitas, puntitos y rankings suelen ser ridículos

Sin lugar a dudas, los puntos, medallas y rankings (conocida como la tríada PBL) son lo primero que viene a la mente de quienes quieren aplicar Gamification a un producto: “pongámosle puntos y medallas, y todo irá increíble“. Si queremos que un usuario comparta, démosle puntos por compartir. Si queremos que publique, démosle puntos por publicar. Si junta suficientes puntos, démosle una medallita, dos, tres. “A la gente le gusta coleccionar esas cosas“, parecen pensar.

“No sé si a la gente le gusta que la traten como perrito amaestrado”, pienso yo. Los puntos y las medallas me recuerdan al adiestramiento canino y a las estrellitas y las caritas felices que te ponían en el dentista cuando te portabas bien: son condescendientes. Asumen que el usuario es lo suficientemente tonto o básico como para mantenerse contento y motivado con un montón de premios virtuales irrelevantes.

Y la palabra clave es, precisamente, irrelevancia. Si tu sistema de puntos y medallas realmente no significa ni vale mucho, a nadie le interesará juntarlos. Es lo que ocurre con los puntos de Foursquare: después de pelearte un par de alcaldías (también irrelevantes) con tus amigos, te empiezas a aburrir. Estar en el primer lugar no significa nada. Estar en el último tampoco. Las medallitas no le importan a nadie. Nadie te las envidia ni te las celebra (los check-ins son un tema aparte, que discutiré más abajo).

Ok“, pensaron entonces algunos, “si los puntos y medallas no funcionan por sí solos, entonces hagamos que los usuarios puedan canjearlos por cosas: descuentos, premios, plata…“. Y eso nos lleva al siguiente error.

Darle regalos a la gente por hacer cosas es como comprar amigos

El Gamification bien entendido tiene como centro la motivación. Y básicamente, hay dos tipos de motivaciones: la intrínseca (hago esto porque me gusta hacerlo, sin importar nada más) y la extrínseca (hago esto porque espero una recompensa a futuro). “Me gusta tanto este trabajo que lo haría incluso gratis“, es motivación intrínseca, mientras que “Si no me pagan no pienso ir a trabajar” es motivación extrínseca.

Usar premios y regalos para estimular comportamientos hace que la gente los realice por la oportunidad de obtener los premios (motivación extrínseca) y no por el gusto de usarlo o por el valor que agrega (motivación intrínseca). “Bueno“, podrá decir usted, “si tengo plata para gastar en eso, puedo encargarme de seguir premiando a la gente para que sigan usando mi producto“.

El problema en que si la motivación está en la recompensa externa, los usuarios la irán a buscar dondequiera que la encuentren. Si hoy me hice fan de la marca A porque sorteaban un televisor, mañana me haré fan de la marca B porque sortean un notebook. No existe engagement ni lealtad (y muchos community managers de marcas importantes se están tardando demasiado en entender esto).

En el largo plazo, esta medida es altamente ineficiente: estoy sustentando mi sistema y mis usuarios en mi capacidad de, básicamente, pagarles para que lo hagan. Si en algún momento se me acaba la plata para comprar regalos, adiós usuarios. Y ésta fue una de las cosas que hizo nacer el Gamification en primer lugar: ¿cómo puedo motivar a la gente sin tener que “comprarla”?

La motivación pasa por sentir que progresamos (en algo importante)

En los videojuegos, los puntos, medallas y etapas sirven para saber en qué etapa voy. ¿Y por qué me interesa saber en qué etapa voy? Porque así puedo saber cuánto me falta para conseguir mi objetivo. ¿Y cuál es mi objetivo? Dominar este juego, superarme a mí mismo o vencer a otros.

Tristemente, muchos de quienes piensan y aplican Gamification jamás realizan esta sencilla progresión de preguntas. El deseo de ser expertos (Desire for Mastery) es uno de los motivadores más potentes que tiene el ser humano. Está detrás de las carreras profesionales, el aprendizaje de idiomas e instrumentos musicales y la pasión por los deportes extremos. Obtenemos un intenso placer al sentir que estamos mejorando en algo que nos importa. La satisfacción de este deseo es totalmente intrínseca: disfruto haciendo esto porque quiero ser mejor en esto.

El mejor detonante para estimular el deseo de maestría es el desafío: si algo que me interesa me es difícil de obtener, más intentaré lograrlo. Esto es válido en todo nivel (por eso, en la conquista el que se hace el difícil suele tener las de ganar). Pero por otro lado, el desafío por el desafío es totalmente inefectivo si no está conectado al deseo de obtener algo importante a cambio. Nuevamente: no importa que le ponga dificultad progresiva a mi sistema de puntos, si la recompensa que hay detrás no es relevante para los usuarios (y no importa mucho que una chica se haga la difícil si en realidad no me gusta).

Conéctate con eso que es importante

La diferencia entre una estrategia efectiva de Gamification y seguir una receta vacía es el grado de conexión con las necesidades y prioridades que ya existen en los usuarios. Como dicen los de Stack Overflow: “en el mejor de los casos, el Gamification y la estructura del sitio no hicieron mucho más que ayudar a que la gente hiciera lo que ya viene haciendo“.

¿Por qué siguen funcionando los check-ins de Foursquare? No por los puntos, sino porque me permiten mostrar dónde estoy. Esto puede satisfacer varias necesidades, como el ego (“estoy en un lugar top”), comunicar estilo de vida (“estoy en el gym, imagínate como quedaré en el verano”) o llamar la atención de otros (“ojo, estoy acá, les aviso”). Esas necesidades, está claro, no las creó Foursquare (y puede que ni siquiera las hayan tenido en mente inicialmente). Pero al conectarse con ellas, creó un hábito de uso.

¿Por qué funciona Duolingo? Porque conectó con algo que a la gente le interesa: aprender idiomas. Aprender idiomas no es fácil, y Duolingo ha sabido convertirlo en un juego, en el que puedo sentir que progreso. Aprender idiomas ya era importante para la gente desde antes; Duolingo sólo creó una manera entretenida de hacerlo.

Uno de los estados más agradables que puede experimentar el ser humano es el que Mihály Csíkszentmihályi llama “flow”: sentirnos absolutamente despiertos e inmersos en algo, sentir que lo estamos haciendo bien y que podríamos pasarnos horas en eso. Si le das a tus usuarios la oportunidad de ser buenos y expertos en lo que hacen, nunca más los perderás. Y por eso es que quizá Sublime Text sea un ejemplo mucho mejor a imitar que Foursquare.

Y es que finalmente, intentar forzarlo todo a que parezca un videojuego es absurdo. Los sistemas que perduran son los que le dan a la gente aquello que los hace sentir bien consigo mismos, más allá de seguir ciegamente una receta. Desconfía de cualquier experto en Gamification que no ponga como primer paso detectar qué motiva y mueve a tus usuarios. Ésa es la parte más difícil. Y tal vez ese proceso por sí solo termine cuestionando todo tu modelo de negocio, tu producto y tu proyecto. Pero eso es tema para otra ocasión. :)

Continuum en StartupQuest: cómo crear empresas rápidas en torno a la tecnología

StartupQuest es un programa estadounidense gratuito de innovación en el estado de Florida, creado como parte de un partnership entre varias entidades gubernamentales y privadas norteamericanas, para proveer de entrenamiento en emprendimiento a profesionales calificados provenientes de diferentes universidades conectándolos con emprendedores exitosos.

startup-quest

El programa, en pocas palabras, consiste en escoger una tecnología (que es real) y simular la creación de una empresa para comercializar dicha tecnología como producto. En total son diez sesiones y premios para el primer, segundo y tercer lugar. Fui recomendado como CEO de Continuum y recibí una invitación para participar como mentor.

Lo que sigue es un resumen del programa y mi idea para ganar.

Mentores

Cada equipo es formado por ocho o nueve miembros y liderado por un mentor. La labor del mentor es guiar al equipo en la generación de la compañía a través de su experiencia, de la creación de roles, la delegación de tareas y brindar ayuda en la elaboración del “plan de negocios” y la hoja de ruta que permitan comercializar la tecnología seleccionada a través de la creación de un producto.

Las tecnologías

Cada mentor debe escoger una tecnología de una lista grande. Cada tecnología es una invención de alguna universidad que incluso puede estar en proceso de patentizar. Participan la NASA y varias universidades de la Florida.

Algunas de las tecnologías más notables de esta versión de StartupQuest que vi fueron: “Communication Virtual Machine“, “Nanosilicone particles for breast implants and Advanced video and image editing tool“, “ShuttleSCAN 3D (3D Scanner)“, “Extended Range RFID and Sensor Tag“, “A Transparent, Solar-Powered Lighting Module With Integrated Energy Storage“, “3-D magnetic memory device“, “Therapeutic agents for the prevention and restoration of bone“.

Yo escogí Communication Virtual Machine.

El pitch

En la primera sesión cada mentor tiene cinco minutos para demostrar porque él y su tecnología son la mejor apuesta, para esto debe hablar de su pasado emprendedor, la tecnología escogida y el plan que tiene para ganar el concurso. Los participantes clasifican en orden de preferencia al mentor y la tecnología. Luego cada mentor recorre las mesas en rondas de Q&A de cinco minutos.

Los equipos

Los organizadores finalmente arman los equipos agrupando miembros con diferentes perfiles (finanzas, ciencia de la computación, marketing, business, etc). De esta forma cuidan que queden lo más diversos posible, y garantizan la posterior división de roles y asignación de tareas en diferentes áreas tal como ocurre en una empresa “real”.

Contenido de las sesiones

  1. Technology matching and team building
  2. Understanding the Value Proposition
  3. Market Analysis and Strategy
  4. Commercialization Strategy and Intellectual Property
  5. Financial Requirements to bring producto to Market
  6. Presentation Skills
  7. Corp Structures and Management Team
  8. Sources of funding
  9. Business Plan Submission and Work Session
  10. Investor Pitch

Como pueden ver, son tópicos clásicos de una clase de negocios norteamericana.

Mi plan

Mi plan es cumplir con la creación de la startup escribiendo el plan de negocios que esperan los organizadores e inversionistas en el pitch final.

Sin embargo tal como argumenta Steve Blank, ningún plan de negocio sobrevive al primer contacto con clientes reales, además startup no son versiones chicas de compañías sino transiciones de como encontrar un modelo de negocio repetible que le permita escalar a una compañía establecida. Por lo tanto mi plan realmente es intentar hacer Customer Development, usar un Business Model Canvas para documentar en estas diez semanas (saliendo de la oficina e iterando en casa sesión), quiénes son los verdaderos clientes (no los que imaginamos), que propuesta de valor estos ven en la tecnología, qué problemas reales les resuelve la solución que la tecnología brinda, de qué forma (revenue streams) y cuánto (pricing) estarían dispuesto a pagar por dicha solución a sus problemas.

bmcanvas-basic-model3

Con el resultado de la aplicación del Business Model Canvas, se podrá revisar o rearmar el plan de negocios, elaborar un elevator pitch, entrenar al más elocuente del equipo y tratar de ganar el concurso.