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.

Desarrolladores: ¡Aprendan diseño!

grfcc

Hace unas semanas, Sergio opinaba (con mucha razón, si me preguntan a mí):

“No hay duda: un(a) diseñador(a) que entiende código y es capaz de ayudar a implementar lo que diseña siempre tendrá una ventaja por sobre quien no lo hace”

 

Así que en un arranque de creatividad, permítanme agregar:

“No hay duda: un(a) desarrollador(a) que entiende de diseño y es capaz de entender el trasfondo de lo que implementa siempre tendrá una ventaja por sobre quien no lo hace”

Antes de bajar a la caja de comentarios y empapelarme, téngame un poco de paciencia. Lo que digo no es muy diferente de algo que los desarrolladores hace rato tenemos asumido: Programar sin al menos entender algo del “negocio” es receta para hacer pega que no funciona, que no se usa, o que hay que hacer de nuevo.

Imaginemos que somos un equipo desarrollando la infraestructura para administrar una liga amateur de tenis. Más nos vale saber cuales son las reglas del torneo, y las reglas del tenis. Y si un compañero desarrollador que lleva tiempo en el equipo no advierte que 3-2 3-2 no es un marcador final válido, probablemente no le daremos el premio al programador del mes, ¿cierto?

Pues bien, es hora de que despertemos y nos demos cuenta de que ya no estamos en la era en que programábamos para una minoría del mundo, para las empresas que podían pagar un sistema, para los empleados que sufrían usaban las herramientas que les dábamos para ordenar y apoyar su trabajo, o para los curiosos (¡como nosotros!) que se atrevían a comprar un computador y gastarse un tiempo considerable entendiendo como funcionaba.

Hace rato que estamos en una era en que programamos para la mayoría. Un tercio de los seres humanos están ya conectados a internet. Y la revolución de los smartphones aún está recién empezando en áreas como África, sectores de Asia, y nuestra Latinoamérica.

¡Despertemos!

La mayoría ya no se conforma con que nuestros sistemas simplemente cumplan las mentadas “reglas de negocio”. ¿Alguien cree que los usuarios leen manuales? ¿Leen ustedes manuales de sus editores de texto, IDEs, etc?

Una de las razones por las que podemos usar esas herramientas sin leer manuales es porque hay diseño detrás. Y ahora recuerden que somos parte de esa minoría que tiene un interés particular por la computación, y aún así dependemos del diseño. Extrapolen ahora a esa mayoría “allá afuera”.

Es por eso que hay que entender algo de diseño. No digo que haya que ser seco para el Photoshop, Fireworks, o siquiera manejar el Paint. Pero tal como aprendemos algo de tenis para comunicarnos con nuestro cliente que organiza ligas de tenis, aprendamos algo de diseño para comunicarnos con nuestros compañeros diseñadores.

Y bueno, para no diseñar interfaces horribles también.

Si hacen el intento verán que el diseño también tiene muchas joyas para los geeks. Hay una cantidad de teoría (y ciencia) detrás del diseño que la verdad yo no conocía, ni menos apreciaba, antes de aventurarme a averiguar. Teoría del color, composición, arquitectura de información y tipografía son algunas de las joyitas que yo he encontrado hasta ahora. Todas son un arte en sí mismas, pero basadas en conceptos que no requieren ser un artista para comprenderlos.

¿Aun siguen conmigo? ¡Sabía que aún tenemos esperanza! :) Aquí van algunos recursos y tips para empezar:

  • Si te gusta hacer presentaciones, recomiendo el libro Slideolgy de Nancy Duarte. Aunque sean presentaciones técnicas, igual pueden beneficiarse de un mejor diseño, igual que tú y tu IDE/editor. Y luego de aprender algunas cosas sobre como diseñar slides, verás que muchos principios sirven para otras aplicaciones.
  • Si te dedicas a la web, Design for the web es un excelente y conciso libro que puedes leer online (y gratis) y que te introducirá a los temas del diseño desde la perspectiva de este cada vez más popular medio (recuerdas aquello de que el tercio de la humanidad está conectada a internet, ¿cierto?)
  • Si sientes que hay un abismo entre el hacker que hay en tí y el mundo del diseño, Design for Hackers es tu libro. Su slogan (“Haciendo ingeniería reversa a la belleza”) lo dice todo.
  • Si el minimalismo, la historia y/o los detalles son lo tuyo, Practical Typography es para tí. Es gratis, fácil de leer por ratos cortos, y hasta divertido.

Recuerden: El objetivo no es convertirse en programador-y-diseñador todo-en-uno (los hay y son invaluables, pero sospecho que son prodigios). El objetivo es empaparse de conceptos que nos permitan comunicarnos con nuestros compañeros diseñadores, entender un poco más sus decisiones  y en conjunto construir mejor software.

¿Conocen ustedes otros recursos para introducirse en el mundo del diseño? ¿Están de acuerdo? ¿Creen que estoy puro diciendo barbaridades? Ahora ya pueden empapelarme, si quieren 😉

Primer ContinuumOnTour: Regalando conocimiento

cot1

A fines del 2012 asistimos a un evento de tecnología, cuya audiencia estaba formada en gran parte por estudiantes ansiosos por conocer técnicas y tecnologías que hasta la fecha sólo aplicaban de forma muy teórica en sus trabajos universitarios. Conversé con varios de ellos: su expectativa de conocer en estas charlas la realidad del mundo tecnológico, para saber cómo prepararse y enfrentar el desafío del mercado laboral informático, no se había visto satisfecha.

Esa misma noche, hablando con el equipo, propuse la idea de hacer un evento donde fuésemos nosotros mismos los encargados de mostrar la realidad actual de un ejemplo exitoso de empresa tecnológica: nosotros mismos, Continuum. El equipo completo de Continuum se quiso sumar a este desafío. Y así comenzamos los preparativos del ContinuumOnTour.

Coordinando el primer ContinuumOnTour

Estando el equipo a bordo, sólo faltaba comenzar las gestiones y definir fechas. Un amigo de Puerto Montt, Roberto Sánchez, se ofreció a ayudarnos con los contactos en universidades de la zona sur de Chile. Luego de un par de semanas, varias universidades confirmaron su interés por presentar esta oportunidad a sus estudiantes:

  • Inacap Puerto Montt
  • Universidad de los Lagos Puerto Montt
  • Inacap Osorno
  • Araucana Osorno

Teniendo listos los lugares, definimos la fecha (29 y 30 de agosto de 2013) y las charlas:

  • Vender y/o evangelizar el desarollo de proyectos por Ricardo Jara
  • UX Diseño – Paso a paso y buenas prácticas por Felipe Funes
  • Mis primeros pasos con Ruby por Alba Cardenas
  • La magia de Ruby / Rails por Miguel Michelson
  • BitTorrent se abre a aplicaciones web por Luis Porras
  • ¿Por qué aprender a desarrollar aplicaciones móviles? por Rodrigo Ayala
  • Desarrollo móvil para IOS y Android por Victor Utreras
  • Desarrollo web con Python por Roberto Sanchez

Llegó el día de viajar, nos subimos al avión y comenzamos esta nueva aventura.

Jueves 29 en Puerto Montt

cot2

Iniciamos a las 15:00 horas en Inacap Puerto Montt, (donde nos recibieron con un gran almuerzo) y estuvimos hasta las 22:00 horas con alumnos diurnos y vespertinos.

Estudiantes y profesores escuchaban con gran expectación. Para mí, es un momento increíble donde los nervios son opacados por las ganas de compartir experiencias y conocimientos. Les conté sobre Continuum y por qué hacemos esto, para luego continuar con la planificación de las charlas. La audiencia se muestra curiosa sobre nuestra motivación y agradecida de que les mostremos una realidad a la cual ellos no tienen acceso.

En la tarde, mientras las charlas continúan en Inacap, tres de nosotros nos trasladamos a la Universidad de los Lagos para realizar tres charlas, dirigidas a un grupo de estudiantes de primer semestre de Ingeniería Civil en Informática. La idea era entregar una motivación sobre lo que será su futuro en unos 5 años más. Personalmente fue muy grato hablarles sobre mi propia experiencia al iniciar esta carrera, además de ver a Alba y Rodrigo con gran pasión entregar sus temas. Al finalizar las charlas, el responsable de la carrera y sus alumnos nos agradecen y concluye: “estos chicos tendrían una visión y oportunidades más realistas, si más empresas como ustedes realizaran estas actividades”.

Viernes 30 en Osorno

Superando el cansancio de la jornada anterior, iniciamos el viaje a Osorno temprano en la mañana. A las 10:30 estamos en Inacap Osorno, donde nos reciben y solicitan de inmediato una gran foto grupal con los estudiantes asistentes al evento:

cot4

En la mañana hay charlas de Felipe, Alba, Miguel y yo. Luego de almorzar, siguen Rodrigo, Victor, Roberto y Luis. Terminamos a las 17:30 horas con muchos agradecimientos de asistentes y profesores, incluso con nuevas invitaciones para realizar otro evento como éste en noviembre.

Nos trasladamos a La Araucana caminando bajo una tenue lluvia e iniciamos las charlas a las 19:15. Los estudiantes escuchan y preguntan con gran interés, para luego compartir junto a nosotros sus dudas e intereses.

cot3

El sábado nos dedicamos a descansar y viajar para conocer la zona y descubrir los variados y hermosos pasajes que el Sur de Chile tiene para ofrecer, todo regado con asados al palo, tours marítimos, y un par de visitas al Saltos del Petrohué y al Volcán Osorno.

cot5

Conclusiones

Muchos nos indicaban que es primera vez que se realizaba este tipo de eventos por la zona. Nunca una empresa había compartido la realidad tecnológica tan al detalle, compartiendo desde habilidades blandas y experiencias de inicios en tecnología, hasta desarrollo de aplicaciones con lenguajes de última generación. Los agradecimientos de los estudiantes y sus profesores fueron el pago a este gran esfuerzo. Esperamos sinceramente que esta iniciativa (tal como las buenas ideas) sea copiada por otras empresas.

El sitio oficial del ContinuumOnTour es tour.continuum.cl.

¡Les estaremos avisando de las próximas fechas!

Mis primeras impresiones de Objective-C

Objective-C es un lenguaje de programación relativamente desconocido. Sólo recientemente, con el boom de apps para iPhone, es que ha logrado generalizarse su uso un poco más. El nombre como tal provoca cierta curiosidad, dejando entrever sutilmente que hay algo de programación orientada a objetos por un lado, y de C por el otro. Un ingenioso juego de palabras.

Pero el ingenio no se queda sólo en el nombre. El lenguaje en sí es una amalgama entre la dinamicidad de Smalltalk y el inmenso poder y simplicidad de C, dos de los lenguajes mas influyentes en la historia de la computación, y que a primera vista parecerían irreconciliables, pero que Objective-C logra combinar muy exitosamente.

Después de una breve incursión con algo de hobby en el mundo de la programación de apps para iPhone, puedo decir que el lenguaje superó mis expectativas. En este artículo me propongo enumerar brevemente algunas características de este lenguaje que me hacen pensar así.

Es dinámico (aunque no lo parezca)

Aunque pudiera no parecerlo a primera vista, Objective-C es un lenguaje bastante dinámico.

Para empezar, este lenguaje basa su filosofía OOP en el concepto de envío de mensajes entre objetos. Existe una diferencia muy sutil pero importante entre el concepto clásico de lenguajes como C++, en los cuales se dice que se invoca un método de un objeto, y el concepto de lenguajes como Objective-C, Smalltalk y Ruby, en los cuales se habla de enviar mensajes a un objeto.

Lo importante es que esta característica le da a Objective-C una dinamicidad poco común en lenguajes compilados, y le permite hacer uso de estrategias de polimorfismo más liberales, como el conocido Duck typing. En contraste, lenguajes como C++, e incluso lo más dinámicos Java y C#, sólo permiten esta dinamicidad dentro del contexto de clases relacionadas por herencia (polimorfismo clásico).

Otras características que avalan el calificativo de dinámico son:

  • Las clases son también objetos, a su vez instancias de la clase Class. En esto también es similar a Ruby y a Smalltalk, y abre toda una seria de posibilidades dentro del campo de la metaprogramación, como crear métodos y clases dinamicamente en tiempo de ejecución, etc.
  • Type introspection y Reflection, lo que se deriva del punto anterior.
  • Los bloques de código, también similares a los bloques en Ruby, son una característica poco conocida y poco explotada, a pesar de la versatilidad que ofrecen. Para ser justos, es una característica añadida recientemente.

Propiedades declaradas

Objective-C brinda un simple mecanismo para declarar las propiedades o atributos que definen y describen el estado de un objeto, a la vez que se implementa la manera en que estos atributos son accedidos. En esencia, todas las variables de instancia son privadas del objeto, y sus valores solo se pueden acceder y modificar por medio de propiedades y métodos.

La declaración de una propiedad también incluye una serie de características que influyen en la implementación automática de los getters y setters de la misma, como por ejemplo, si la asignación funciona por copia o por referencia, si son thread safe o no, o si la propiedad es de solo lectura, por citar algunos ejemplos.

@interface XYPerson : NSObject {
  NSString *name;  // Variable privada
}

// Propiedad que encapsula la variable
@property (copy) NSString *name;

// ...
NSString *name = somePerson.name;
somePerson.name = @"John Doe";

Esta característica del lenguaje nos permite adherirnos al principio de la encapsulación, una de las bases de la OOP, que permite a cada objeto controlar la manera en que otros objetos acceden a su estado interno y lo manipulan.

Estas propiedades declaradas también juegan un papel importante en algunas de las funcionalidades fundamentales de la runtime library, tales como KVCKVO, etc.

Protocolos

Un protocolo define un contrato, que no es más que un conjunto de métodos, que luego distintas clases pueden adoptar. El protocolo no define implementación alguna, solo el encabezado de los métodos que lo conforman. Cada clase que adopta un protocolo es la que asume la responsabilidad de la implementación.

@protocol XYEnumerator
- (bool)hasNext;
- (id)next;
@end

// Clase que implementa el protocolo
@interface XYArrayEnumerator : NSObject <XYEnumerator>
// Implementación
@end

En este sentido los protocolos de Objective-C son equivalentes a las interfaces de Java y C#, y de hecho se puede decir que son sus precursores también.

Sin embargo, los protocolos, a diferencia de las interfaces de Java y C#, también pueden incluir métodos opcionales, es decir métodos que las clases pueden optar por omitir, dejándolos sin implementación. En este caso, cuando se pretende invocar un método de estos, debe verificarse primero, usando reflection, si el objeto que recibirá el mensaje lo tiene implementado o no.

Otra diferencia es que los protocolos pueden incluir definiciones de métodos de clase, en adición a los métodos de instancia. Y al igual que en Java y C#, una clase puede implementar más de un protocolo.

Un uso obvio para los protocolos consiste en burlar la falta de herencia múltiple, aunque no sólo se limita a esto, como se evidencia en la librería estándar de iOS y Mac OS X, donde abundan protocolos cumpliendo roles como delegatesobservers y demás.

Categorías

Las categorías permiten re-abrir la declaración de una clase para añadirle nuevos métodos, o reemplazar la implementación de métodos ya existentes en la misma. Esto es posible hacerlo con cualquier clase, incluso clases ya compiladas, a cuyo código fuente no tenemos acceso, e incluso a las propias clases de la runtime library.

Muchos puristas de la OOP son contrarios a este tipo de posibilidades en un lenguaje (véase SOLID y Open/Closed Principle), pero yo creo que las ventajas pueden ser mayores que los problemas que pueden venir asociados, si se utiliza inteligentemente. Reconozco que es una característica del lenguaje que se presta para ser utilizada erróneamente, y por lo general el abuso de la misma es un indicio de que el sistema de clases sobre el que se está trabajando no es lo suficientemente sólido y extensible.

No obstante, si se utiliza sabiamente, y no más de lo necesario, puede ser una característica clave en la implementación de un sistema o librería. La prueba de ello está en Ruby, un lenguaje que comparte esta característica, sin la cual un framework como Ruby on Rails no fuera posible tal y como lo conocemos hoy.

Un uso más mundano pero válido para las categorías, es el de separar la implementación de una clase en varios ficheros de código fuente, ya sea por razones organizativas, o porque la implementación es muy extensa y compleja, y la interfaz de la clase se puede separar en grupos relacionados lógicamente.

Compatibilidad con C (y C++)

A diferencia de C++, Objective-C es totalmente compatible con C, siendo este último un subconjunto estricto del primero. Cualquier código en C puro es utilizable en un programa escrito en Objective-C, y las librerías pueden enlazarse sin necesidad de wrappers ni nada por el estilo.

La ventaja más evidente es que los programas Objective-C pueden hacer uso de infinidad de librerías escritas en C, como por ejemplo sqlite y OpenGL, dos ejemplos de uso notable en aplicaciones para iOS especialmente.

También debe mencionarse que Objective-C puede ser combinado con código fuente C++, aunque son lenguajes bastante diferentes. En este caso existen varios requerimientos o restricciones que deben ser observadas.

Conclusiones

El lenguaje, como cualquier otro, está lejos de ser perfecto, y ciertamente tiene algunas características que lo hacen parecer extraño, sobre todo desde el punto de vista sintáctico. También el proceso de inicialización o construcción de objetos es un poco más complejo de lo necesario, en mi opinión.

Mi percepción de este lenguaje ha cambiado con el tiempo. Cuando uno empieza a utilizarlo, aparenta ser algo incómodo y complicado. Pero más temprano que tarde uno comienza a apreciar sus cualidades, a aceptar sus limitaciones y su sintáxis poco convencional, y eventualmente uno llega a gustarle trabajar con él. Especialmente si uno viene de un background de trabajo con otros lenguajes de corte dinámico.

Este artículo sólo pretende rozar la superficie de un tema mucho más amplio y complejo, sin pretender abordar todos los detalles ni tocar todas las aristas.

Espero que su lectura pueda despertar el interés por Objective-C en más de un lector.