La Voz es la Plataforma

Tiempo de lectura: 19 minutos (22 si te ves el vídeo)

No sabemos cuánto tiempo pasó desde que los humanos empezaron a hablar entre ellos, hasta que dejaron constancia escrita de que lo hacían. Ni siquiera sabemos si eran humanos o proto-humanos, o si gracias a la comunicación con palabras dejaron de ser animales y pasaron a ser personas. Lo que sí sabemos es que la interfaz más extendida y natural de comunicación entre dos seres humanos es la voz: nuestro lenguaje se clasifica primordialmente como verbal. Aunque no hay una teoría aceptada como universal que explique los orígenes del lenguaje verbal, lo cierto es que los bebés adquieren una forma de comunicación estructurada para expresar ideas y mensajes basada en sonidos antes de empezar a leer y escribir. Y está generalmente aceptado que la mejor manera de resolver un conflicto entre dos personas es hablando (y no a través del correo electrónico, por muchas caritas que pongas)

La forma con la que nos comunicamos con los ordenadores ha seguido el proceso inverso. Primero aprendimos a relacionarnos con las computadoras a través de tarjetas perforadas, luego enviando comandos escritos a través de un teclado, después dimos el salto a las interfaces basadas en un puntero (ratón), y con las pantallas táctiles nuestros propios dedos y gestos son ese puntero.

Y casi sin darnos cuenta, gracias a los avances en reconocimiento de voz, procesamiento del lenguaje natural y computación cognitiva, hemos llegado al momento en que podemos interactuar con nuestros dispositivos (ordenadores, electrodomésticos, teléfonos incluso coches) a través de la voz. Y sobre todo, ellos son capaces de respondernos también a través de la voz. Hay un dispositivo diseñado para centralizar la comunicación a través de la voz entre humanos y artilugios, y se llama Smart Speaker.

NO DIGA ALTAVOCES, DIGA PLATAFORMAS

Aunque en España son relativamente una novedad (Google Home ha aparecido en verano de 2018), en Estados Unidos los altavoces inteligentes están a disposición de los consumidores desde el lanzamiento de Amazon Alexa en 2014. Un Altavoz Inteligente (Smart Speaker) no deja de ser una interfaz para que una persona y un Asistente Virtual interactúen.

Y los Asistentes Virtuales no son una novedad. Es un área de la Inteligencia Artificial convertida en mainstream desde que millones de personas llevan uno en su teléfono. Concretamente Apple presentó Siri en 2011 como parte de iOS 4. Quizá, esa familiaridad que tenemos con el concepto Asistente Virtual que llevamos en el bolsillo es lo que ha hecho que la adopción de la tecnología de Smart Speaker sea tan rápida. Al fin y al cabo, un Smart Speaker es algo que ponemos en el salón o en la cocina, y que nos permite pedirle a nuestro asistente que haga cosas.

 

Adopcion Smart Speaker

Adopción de Smart Speakers comparado con otras tecnologías del hogar

 

Sin embargo, los “Asistentes” de los que estamos hablando no son únicamente un software accesible a través de un altavoz inteligente. Son mucho más, son modelos de negocio de plataforma, y esto es interesante tenerlo en cuenta por las implicaciones que tiene. Es algo que ya ha ocurrido en el pasado y que está a punto de volver a ocurrir.

Para introducir este concepto de importancia de los modelos de plataforma, pensemos en la App Store de Apple. En 2007 Apple lanzó un producto único y exclusivo que era el iPhone. Nadie más que Apple vende el iPhone. Y a ese producto único y exclusivo sólo hay una forma de instalarle aplicaciones: a través de la App Store. La App Store fue lanzada en Julio de 2008 a su vez como una plataforma única y exclusiva de Apple. Nadie más que Apple puede gestionar la App Store.

Pero esa plataforma está abierta a terceros, y aquí es cuando plataforma se convierte en el ecosistema. Cualquiera puede intentar subir apps a la App Store, sólo tiene que pagar un coste de licencia. Después es Apple quien revisa si esa app puede o no estar publicada, según unos criterios que ellos mismos han decidido. Además, el ecosistema es virtuoso, ofrece más valor que la mera conexión con el usuario: ya que permite a los terceros hacer modelos de negocio. La App Store ofrece diferentes formas de obtener ingresos a los desarrolladores de apps (pago por descarga, compras dentro de la app, suscripciones…), de los que por cierto Apple se queda con un porcentaje.

Finalmente, para que los usuarios encuentren las apps, es Apple quién determina una serie de categorías y listados, permite que se valoren las apps, y fija unas reglas sobre etiquetas y descripciones para optimizar el uso del buscador. Lo que por cierto da lugar a una nueva disciplina de conocimiento, que se llama ASO (App Store Optimization) que es el equivalente al SEO pero en la tienda de apps.

Poco después, en Octubre de 2008, Google lanzó su propio ecosistema de plataforma para dispositivos Android. El modelo de plataforma de las tiendas de apps para smartphone es uno de los casos de éxito de referencia de negocio digital innovador. Según Sensor Tower, se estima un volumen de negocio de 58,6 mil millones de dólares en 2017, y un crecimiento del 35% respecto a 2016.

Ingresos app stores

¿Por qué ganar millones cuando podemos ganar miles de millones?

 

Las plataformas de Apple y Google tienen algunas diferencias. Una es que en Google no hay un fabricante de terminales exclusivos. Otra de las diferencias es la capacidad que tienen los fabricantes de saltarse la plataforma para desplegar apps. En Apple no se puede uno saltar el store para instalar una app, salvo que el usuario haga jailbreak. En Google sí. Por eso los del Fortnite confirmaron que no van a darle a Google el 30% de sus ingresos, y la versión para Android se descarga directamente de la web de Epic. A cambio Google dijo que el instalador del juego tiene una vulnerabilidad crítica.

Bueno, pues en el caso de los Asistentes Virtuales de Voz es equivalente. Cada proveedor está intentando a su manera crear un nuevo ecosistema de plataforma. Así por ejemplo, Apple lanzó los Homepod, en los que se puede integrar a Siri y sólo Siri siguiendo su premisa de ecosistema cerrado. En cambio Google, con su política de llegar al máximo número posible de usuarios, tiene sus propio catálogo Google Home para integrar su Google Assistant, pero hay marcas como Panasonic, LG o incluso Bang & Olufsen que han lanzado al mercado (o lo harán próximamente) sus propios Smart Speakers. Amazon empezó por el mismo camino: ellos venden la gama de dispositivos Echo pero hay productos de terceros que integran Alexa, como por ejemplo el de Sonos.

TRES SON MULTITUD

Lo cierto es que los usuarios (consumidores) estamos ahora mismo expuestos a varias formas de Asistentes Virtuales de Voz:

  • el del sistema operativo del smartphone. Los teléfonos iOS tienen a Siri, y los Android tienen Google Assistant (algunos preinstalados, todos lo tienen disponible en Google Play)
  • opcionalmente, el del fabricante del smartphone, que puede convivir en el mismo dispositivo. Samsung ha creado Bixby, Xiaomi Xiao Ai, etc.
  • los Smart Speakers de fabricante, como Google Home, Amazon Echo, Xiaomi Mi Smart…
  • dispositivos de terceros, no sólo Smart Speakers o barras de sonido, estamos hablando de que Android Auto integra el Google Assistant, y Apple CarPlay integra Siri
  • incluso los del sistema operativo del ordenador, pensad en los millones de ordenadores con Windows que incluyen a Cortana de Microsoft

Con tantas alternativas ahora mismo encima de la mesa, podemos decir que nos encontramos en una fase exploratoria. Primero, porque estamos en el punto de adopción de la innovación. Es decir, puede que mi teléfono tenga a Bixby y a Google Assistant, o que mi portátil traiga a Cortana. Otra cosa es que lo use. En el punto de adopción de la innovación lo que debe producirse es el establecimiento de una base relevante de usuarios, a partir de casos de uso que fomenten la recurrencia (más allá de pedirle a Siri que te cuente un chiste).

Esta adopción inicial de usuarios parece que está siendo liderada por las nuevas generaciones, principalmente por los nacidos entre 1981 y el año 2000 (sí, otra vez los millennials)

Millenials

Los Millenials tirando del carro de los Asistentes Virtuales

En el caso de la adopción del uso de Asistentes virtuales basados en Voz y la consolidación de sus modelos de plataforma, la hipótesis que alguien debería querer validar es si los consumidores perciben o no valor en su uso, y hay algunos datos que parecen apuntar que sí. Veamos.

En el caso de Apple, anunció en Enero de 2018 que Siri está activo en más de 500 millones de dispositivos al mes, si bien la cifra de “dispositivos” activos en esa fecha era de 1.300 millones. En la conferencia de desarrolladores WWDC de Junio de 2018 reveló que Siri responde 10.000 millones de consultas al mes. Por su parte, Google Assistant está también en 500 millones de dispositivos, según se anunció en el I/O 2018, y Samsung confirmó que Bixby tenía 10 millones de usuarios activos en Octubre de 2017.

La impresión es por tanto que los Smart Speakers dispararán el uso de los Asistentes Virtuales de Voz, sobre todo por la privacidad y la intimidad de uso que puede hacerse en el hogar. Sin que tus compañeros de trabajo, o desconocidos que pasan por la calle te miren con cara de «este tío es gilipollas».

Contextos

¿En qué contextos se usan los asistentes virtuales de voz?

Amazon lanzó el Echo para hablar con Alexa en Noviembre de 2014 y por tanto no había muchas más alternativas; sin embargo, hoy tenemos Google Home, y total, si llevo a mi Google Asistant en el teléfono, lo normal es que me lo ponga en casa. Es de esperar que las cuotas de uso de Asistentes Virtual de Voz se vayan equiparando a las cuotas de uso de smartphone (lo que a su vez está ligado muchas veces a la región geográfica / país).

En el mercado ya se está viendo una redistribución de los usuarios entre diferentes alternativas, como muestran los datos de ventas en los últimos 18 meses.

Fragmentación

Framentación de las plataformas

Sin embargo, en el medio-largo plazo, los usuarios tenderá a elegir el Asistente Virtual que les transmita confianza, y para mí esa es la clave que determinará qué plataformas sobrevivien. Porque crear estas plataformas no está al alcance de cualquiera.

Efectivamente, las inversiones en crear los Asistentes Virtuales de Voz han sido enormes y vienen desde mucho tiempo atrás. Por ejemplo, Microsoft comenzó el desarrollo de Cortana en el año 2009, y se presentó en sociedad en Abril de 2013. Siri nació como una spin-off del Stanford Research Institute, que había levantado 24 millones de dólares para crear el asistente virtual del mismo nombre. Se publicó como app en 2010 y Apple la adquirió dos meses más tarde, por una cifra que no he conseguido encontrar, pero que ronda los 200 millones. Amazon empezó el desarrollo de Echo en 2010.

Recordemos que el Asistente no es el objetivo que persiguen estas empresas; lo que se busca es el modelo de ecosistema de plataforma, y para que sea virtuoso no basta con el producto: hay que tener masa crítica de usuarios, y terceros que publiquen en la plataforma.

¿POR QUÉ TRIUNFA UNA PLATAFORMA?

Como todos sabemos lo bien que funcionan App Store y Google Play, los grandes players están ahora mismo intentando consolidar las suyas. Para ello es necesario que le resulten atractivas a sus usuarios, y eso se consigue a través de la utilidad. O para ser más precisos, de la capacidad de terceros (empresas o desarrolladores) para publicar servicios útiles en la plataforma.

¿Qué se publica en la plataforma de Asistentes Virtuales de Voz? Pues capacidades, osea, cosas que el Asistente Virtual sabe hacer, y que ofrece al usuario (consumidor). En el ecosistema de Amazon se llaman skills, en el de Google se llaman actions, etc. PCMag identificó en Enero de 2018 que había 1.830 acciones de Google publicadas, mientras que Alexa tenía la friolera de 26.000 Se lo que estáis pensando, si publico un skill, ¿cómo va alguien a descubrirlo? ¿Recordáis la reflexión sobre el ASO al inicio de este post? Lo retomaremos más adelante.

Idealmente, cuantos más proveedores hayan subiendo y creando capacidades para el Asistente, más cosas será capaz de hacer, y por tanto más valor aportará al usuario, más usuarios habrá y más relevante será esa plataforma. Y por desgracia, otras plataformas terminarán por volverse irrelevantes y desaparecer. Igual que desaparecieron Nokia, Blackberry o los smartphones basados en Windows.

¿Cuáles son los criterios que determinarán la adopción de plataformas de Asistentes Virtuales? Quizá no por este orden, pero yo diría sin duda que depende de la utilidad, de la omnicanalidad, de la fiabilidad, de la privacidad y de la transparencia. Veamos uno a uno.

Criterio de Utilidad

Lo primero que alguien necesita de un producto o servicio es que le resulte útil. En el estado actual de la cuestión, donde se está empezando a construir la propuesta de valor, parece que hay un sesgo hacia el canal por el que se usa el asistente, y su contexto. En el smartphone tenemos casos de uso muy dirigidos al aquí y ahora (busca esto, guarda info, llama a un sitio…), mientras que en casa (a través de los speakers) hay muchas features de información y productividad (que el asistente haga cosas por mí mientras yo hago otras, como cocinar), interacción con la domótica (enceder luces, programar termostatos…) o con elementos multimedia (tema listas de audio, poner el Netfilx, etc). Desde mi punto de vista, una vez pasado el efecto de la novedad y el trolleo al asistente, cuanta más completa sea la oferta de una plataforma, mayor será la fidelidad del usuario.

Uso

¿Para que se usan los asistentes de voz?

Criterio de Omnicanalidad

Relacionado con lo anterior, cuántos más canales existan para interactuar con la misma plataforma, y por tanto, mayor amplitud de contextos de uso, mayor será la adherencia del usuario. No he encontrado evidencias que demuestren que sea relevante en términos de mercado el número de consumidores que combinan varias plataformas excluyentes; el consumidor medio no busca cosas en Google y cosas en Bing, ni tiene un iPhone para unas cosas y un Android para otras.

Otra cosa diferentes es el uso de plataformas complementarias. Por ejemplo, se puede comprar en Amazon o en AliExpress siguiendo un criterio de calidad / precio. Otro ejemplo es el del carsharing; los más de 460.000 usuarios que hay en Madrid según datos de las propias empresas no son “únicos”, usan varias plataformas siguiendo el criterio de disponibilidad. Lo normal es que una vez que alguien se da de alta en car2go, emov y Zity se dará de alta en WiBLE, porque lo que espera es tener cuantas más opciones posibles para ampliar su movilidad urbana.

Al igual que Android e iOS son plataformas excluyentes (o estás en una o estás en otra, y te quedas en la que elijas), mi proceso de pensamiento crítico me lleva a pensar que las plataformas de voz también acabarán por ser excluyentes.

Quizá por eso, Google Home llegó por sorpresa a España en Junio, ante los enigmáticos anuncios que había estado haciendo Amazon sobre la disponibilidad de Echo (los rumores apuntaban al Prime Day de 2018). Si ya has comprado un Home, ¿para qué comprar un Echo? Bueno, quizá el motivo sea el tema de las compras por internet, que me parece la feature más diferencial. Quizá ahí Amazon Echo lleva una cieta ventaja. Hoy en día no puedes comprar en Amazon desde Google Home (sí es posible hacerlo en Google Express)

¿Será ese uno de los casos de uso que inclinarán la balanza? El escenario más probable sea que aquellos que compren un Amazon Echo de ciento y pico euros no comprarán otro Google Home para tener los dos en casa; aunque sí puedan tener Siri o Google Assitant en su smartphone. Igualmente, aquellos que compren un Google Home descartarán la opción del Echo.

Criterio de Fiabilidad

Bien, yo creo que todos más o menos hemos pasado por una de las peores experiencias de uso del mundo, que es hablar con un IVR (Interactive Voice Response) que no te entiende. Y eso que el reconocimiento de voz es una tecnología que además de seguir viva (se sigue metiendo dinero para investigar y mejorar) empezó a desarrollarse con el proyecto “Audrey” de Bell Labs en 1952. Audrey era capaz de reconocer con un 90% de precisión un dígito si lo decía un usuario en concreto (concretamente su creador). 70 años después no hemos perdido la frustración de hablar con un sistema que no te entiende. Es una experiencia de uso demoledora para el cliente, y por tanto, para su visión de la empresa a la que se dirige.

 

Esto, que a priori es algo que sabemos que depende de la madurez tecnológica, y que por tanto se acaba por conseguir con el paso del tiempo (y metiendo pasta), es una barrera de entrada brutal para la consecución de usuarios. Cuanto más tarde un player en lanzar su plataforma, más difícil le resultará conseguir masa crítica; pero lanzar una plataforma de Voz que no reconoce las intenciones del usuario, hará que sea rápidamente descartada (y por tanto, no tenida en cuenta cuando evolucione hasta su nivel de madurez)

Precisión

La precisión del entendimiento llega a la cuota del umbral humano

Criterio de Privacidad

No tanto porque responda a una necesidad real de los usuarios, actualmente es una cuestión política y regulatoria. Pero la obligada aplicación del GDPR en Europa el 25 de Mayo de 2018 ha puesto de manifiesto la dificultad de las empresas en adaptarse a unas directivas, que se publicaron y aprobaron en 2016.

Aún así, pese a los escándalos sobre venta de datos y manipulación de la opinión que ha puesto de manifiesto el caso de Cambridge Analítica en Facebook, la plataforma pierde usuarios más por el hartazgo y la falta de valor para las nuevas generaciones que por la sensación de exposición de sus usuarios. La realidad es que el usuario medio no valora su privacidad y está dispuesto a ceder información personal a cambio de funcionalidad.

Criterio de Transparencia

Esta es una de las claves de los sites que se basan en algoritmos de recomendación, como los que Facebook, Twitter o Instagram usan para configurar tu timeline, o los que usan Google o Bing para mostrar resultados, o Amazon para ordenar las búsquedas.

En el caso del buscador de Google, queda perfectamente claro qué es un resultado “promocionado” (es decir, que alguien ha pagado por ponerlo ahí) y qué resultado proviene del algoritmo (que por cierto, la gente no sabe cómo funciona, pero le vale y lo da por bueno)

Cuando un Asistente Virtual empiece a recomendarnos o a interactuar con los productos y servicios de un tercero, como clientes querremos saber qué criterio ha elegido para usarlo / elegirlo. Por ejemplo, cuando digas a Google Home que te ponga algo de rock, ¿cómo elegirá la banda? ¿dependerá de que alguien esté promocionando su nuevo disco? ¿o su nueva gira? Cuando le preguntes a tu Siri qué sitios hay cerca para cenar, ¿cuál te dirá primero? ¿el que más pague? ¿el que tenga mejores recomendaciones? ¿Dónde? ¿En Goole Maps? ¿En el Tenedor? ¿Por qué no en Trip Advisor?

Se supone que aquí entra en juego la personalización y la inteligencia predictiva, que es algo de lo que llevamos oyendo hablar ya años, pero que parece que sigue siendo una tendencia. Cuanto más sepa de ti el algoritmo, más fácil es que pueda recomendarte algo. Y cuanto más sepa de tus amigos y de la gente como tú, más posibilidades de acertar.

Y aquí es donde entran en juego las empresas de productos y servicios, en general todos los que necesiten llegar al consumidor. Lo que muchos llaman así por resumir, las “marcas”.

¿Y ESTO A MÍ QUÉ MÁS ME DA?

¿Cómo les impacta a las marcas que aparezcan estas nuevas plataformas? Podemos hacer una equivalencia a cómo les ha impactado por ejemplo la aparición de las plataformas de apps para móvil. El pensamiento crítico nos dice que usar el pasado para predecir cómo va a ser el futuro es un sesgo. Eso no quita, sin embargo, que es importante entender qué pasó para aprender, y poder prepararse para lo que pueda pasar.

«Fase de negación»

Cuando salió el iPhone y meses más tarde la App Store, muchas empresas optaron por esperar a ver qué pasaba con este nuevo dispositivo y el ecosistema de las apps. Por aquél entonces, Apple sólo era la empresa que hacia los MacBook, y aquello no era tan masivo como ahora. Los reyes del mercado de la movilidad eran Nokia y Blackberry, y esto del iOS nadie sabe muy bien cómo va, y que si las operadoras no tienen tarifas de datos, etc.

Total, vamos a esperar a ver qué pasa. Resultado: cuando se quisieron meter llegaron tarde, el espacio que querían estaba ocupado o saturado, y la inversión para entrar y conseguir relevancia en el ecosistema fue mayor que la de su competencia.

Creo que esta fue una lección importante, y por suerte cada más empresas tienen departamentos de innovación que hacen exploración (tecnológica y de negocio) para que esto no les vuelva a pasar.

«La Urgencia por la Presencia»

Recuerdo que allá por 2010 o así había una mantra que se repetía en cualquier congreso digital. “Hay que estar en el smartphone de los consumidores”. Los gurús de la cosa hablaban de que había que conseguir a toda costa colocar el logo de una marca en alguna de las pantallas del teléfono de los clientes. Cuanto más cerca de la home, mejor. Que esto era un objetivo en sí mismo. Para mí este fue el segundo error. Pasar del “no hago caso a esto” a “tengo que estar pero no se para qué”. Porque estar, había que estar, y entonces las grandes empresas se pusieron a gastar dinero en hacer apps sólo para que alguien se las descargase.

Problema, su propósito de “estar” no le interesa a los usuarios. Si lo recordáis, vivimos un boom de apps que no valían para nada, que todavía seguimos arrastrando. Por lo general, siguiendo recomendaciones de agencias que no habían entendido que el negocio de la utilidad no es el negocio de la reputación. Después de gastarse la pasta en hacer una app que no valía para nada, había que gastarse en la pasta en promoverla y conseguir que la gente la descargase. Y después venía gastarse la pasta en conseguir que la gente la mantuviese viva. Y por último, justificar el retorno de la inversión en términos tangibles, de negocio. Algo imposible, porque la app no servía para nada. Resultado: los App Stores correspondientes llenos de apps que nadie descarga, empresas lanzando propuestas de valor que no interesaban a su público, y gente volviéndose loca para que sus apps sean relevantes.

Número de apps

No hay suficientes apps, haced más

«La búsqueda del Valor»

Los datos de uso de apps más recientes dice que el 36% de los usuarios no pasa de la primera sesión de uso de una app si no tiene notificaciones push. Con los rankings de descargas y sobre todo, el uso de internet desde el móvil terminaron por definir un panorama poco alentador para la «presencia» de marcas en los terminales del usuario. El usuario medio donde más tiempo pasa es en las apps que más valor le aportan, por lo general, las de hacer tonterías sociales.

Retención

Lo que cuesta retener a los usuarios

Uso

Pregúntale: ¿a qué dedica el tiempo libre?

 

En el punto en el que estamos, diría que todas las empresas saben que construir una app es fácil, lo complicado es conseguir que la gente la descubra, se la baje y la utilice. Por eso creo que cada vez hay más apps para clientes, y menos apps para captar clientes. Es decir, más apps que ofrecen un nuevo modelo de relación o de acceder a los servicios de alguien que conoce los productos y servicios de una marca, y menos que se hacen con la esperanza de captar nuevos usuarios.

Considerar un smartphone (y por tanto, su ecosistema de plataforma) un Canal es algo bastante común, y por eso cada vez más empresas tienen departamentos de Canales Digitales. Donde se asume que hay un medio de comunicación (o de diálogo, o de operación, o de engagement, o como lo que queráis llamar) entre un producto / servicio y sus consumidores / usuarios, con unas reglas, propósito y particularidades específicas a ese canal.

Hay alguna forma de llevar estas lecciones al modelo de plataforma de Asistentes Virtuales de Voz? ¿qué aprendizaje deberíamos aplicar?

5 CLAVES PARA ENTRAR EN PLATAFORMAS DE VOZ

Pues toda esta reflexión me sirve para presentar a las marcas / empresas de productos y servicios una recomendación sobre cómo entrar en Plataformas de Voz:

  1. Reforzar el vínculo con el cliente. Uno de los principales objetivos de los Asistentes Virtuales de Voz es convertirse en intermediario entre el cliente / consumidor y las empresas que ofrecen productos y servicios. Y no hacer de intermediario exclusivamente como “canal”, sino que lo hace teniendo en cuenta datos que permiten su perfilado. Igual que Google sabe por dónde navegas o Amazon lo que ves y lo que compras. De esta manera, el Asistente termina por convertirse en un prescriptor, que puede por tanto filtrar qué productos y servicios ofrece o recomienda. Es importante que los consumidores (tanto potenciales como actuales) se mantengan vinculados a la marca, para que el Asistente Virtual tenga en cuenta este vínculo en sus relaciones. Creo que este es uno de los principales objetivos de los equipos de marketing: aprender a relacionarse con los usuarios a través del Asistente, para que el asistente detecte y cualifique esta relación.
  2. Crear una identidad propia. Hoy sabemos cómo transmitir la identidad de nuestra marca en canales digitales. Un sitio web, una landing, una app, incluso una cuenta de Facebook o Snapchat, transmiten una serie de conceptos, valores y principios. De momento, Siri, Google Assistant, etc, tienen su propia voz, y su propia identidad. En una primera etapa, la voz de una empresa / marca es la del tercero; pero la forma en que se generan los mensajes de la respuesta, o cómo se construyen las preguntas que ayudan a clasificar la intención del usuario, puede desarrollarse en aspectos como cercanía, tono, ironía, etc. Puede que Adidas y Nike, o Coca-Cola y Pepsi hablen con la misma voz, pero tendrán que expresarse de forma distinta. Esta es ya una forma de crear la identidad de esa marca. Además, las plataformas están ampliando el abanico de voces que pueden emplearse, no sólo por los usuarios, sino por los propios desarrolladores, como en el caso de Amazon Polly. Eso quiere decir dos cosas: primero, que como marca podemos elegir entre un catálogo de voces cómo queremos que suene la nuestra. Eso ya es otra decisión de identidad. Segundo, que lo normal sería que por el módico precio y siguiendo una serie de reglas, permitan a terceros incorporar nuevas voces.
  3. Trabajar el posicionamiento en las plataformas. Gracias a Google se inventó el concepto de SEO y gracias a Apple el de ASO. Conseguir aparecer en los resultados de los buscadores es un arte, y además, requiere un trabajo constante de adaptación conforme cambian los algoritmos. En este caso será necesario hacer un proceso equivalente para entender cómo funcionan los skills / actions / etc. de cada plataforma, y los algoritmos que siguen para lanzar o no los servicios y acciones equivalentes. Este es un proceso que debe hacerse combinando equipos de tecnología / innovación y equipos de datos.
  4. Lograr la valoración positiva. Dado que tanto Alexa como Google Assistant por ejemplo permiten clasificar con “estrellas” los skills y actions publicados. El criterio de descubrimiento de utilidad basado en la valoración de terceros es uno de los más relevantes en el proceso de exploración de un market. Sabemos que el 88% de las personas confían en las reviews como si fueran recomendaciones personales, y que el 90% de las personas utilizan las reviews en su proceso de compra.
  5. Conseguir llevar una experiencia cross a varias plataformas. Ahora mismo hay una eclosión de plataformas, pero como comentaba anteriormente, es posible que se produzca una importante especialización o polarización de las mismas. A priori es difícil saber cuál elegir, aunque todo hace pensar que Google tendrá la mayor base de usuarios, o que Apple tendrá los usuarios “más valiosos”. Sin embargo, ¿qué pasará con las plataformas Chinas? ¿Será Samsung un player relevante? Mi recomendación es construir los servicios o canales de interacción con los asistentes en modo proxy, de manera que exista una solución común y homogénea, donde sólo cambie el mecanismo de publicación en un market.

Como hemos visto en este post, los ecosistemas de plataformas suponen una oportunidad para las marcas, y también pueden suponer una amenaza. Cuanto más poderosas se hacen las plataformas que se colocan por delante de los consumidores, mayor es el riesgo de prevalencia de la plataforma sobre la marca. Cuanto mayor notoriedad consigan sus competidores, más difícil será recuperar el terreno.

Previsiones

Previsiones de ventas a 2022

Considerando las previsiones de crecimiento, es fácil pensar que las plataformas de asistentes virtuales basados en voz pueden generar modelos de negocio muy importantes para marcas y desarrolladores. También puede servir para mejorar los ratios de adquisición o retención de clientes.

Espero que con los datos que he compartido en esta reflexión, consideréis como yo que este es un campo mucho más relevante para invertir a día de hoy que el blockchain, por ejemplo. El reto por delante es descubrir cuál es la propuesta de valor que llevar al usuario en este nuevo Canal. Tendría que escribir otro post para explicar cómo implementar programas de exploración de la innovación tecnológica aplicando procesos de user research, diseño de modelos de negocio digitales, propuesta de valor centrada en la persona, construcción de prototipos mínimos viables, y validación de hipótesis basada en métricas

Pero ya sabéis que últimamente estoy como George R.R. Martin: un poco más gordo, con más barbas, con facilidad para irme por las ramas, y tendencia a no encontrar tiempo para escribir.

Casi lo mejor es que me llames, y acabamos antes.

Technovation Challenge: La Transformación Digital es cosa de niñas

Tiempo estimado de lectura: 25 minutos :_)

Pues parece que se ha quedado un post muy largo, lo se. Refleja el trabajo de las Perfect Stranger Girls, un equipo de 5 niñas de 11 y 12 años durante los 4 meses que dura el Technovation Challenge: desde que se formaron como equipo, hasta que quedaron entre las 3 mejores de la categoría Junior en la final regional de Madrid en 2018. Así que merece la pena leerlo.

¿Que por qué tienes que unirte al Technovation Challenge?

«Software is Eating the World», el artículo que publicó Marc Andreessen en el Wall Street Journal en agosto de 2011, es mi arranque habitual en charlas sobre Transformación Digital. Trata sobre cómo el software, y en general la tecnología, se han convertido en el motor del crecimiento prácticamente de cualquier sector, pero ahora lo voy a usar para hablar sobre qué puedes hacer para formar a las líderes innovadoras de mañana, y por qué tienes que hacerlo.

Software is eating the world

Evolución de las principales compañías por capitalización bursátil (visualcapitalist.com)

Precisamente estas grandes empresas de software, como Apple, Alphabet, Amazon, etc., que lideran sus respectivos sectores; que son ejes de transformación y disrupción; y que crean productos y servicios consumidos por millones de personas en todo el mundo, son también un ejemplo de desigualdad de género en trabajos técnicos.

Brecha de género

Presencia de la mujer en las grandes empresas tecnológicas (Statista)

Pero lo cierto es que no es algo exclusivo de esas empresas. Los datos en USA muestran que en el periodo de 2002 a 2016, hay un 5,5% menos de mujeres desarrollando software. La primera vez que escuché hablar del programa Technovation Challenge y de Girls for a Change pensaba, desde mi ignorancia, que viviendo en un mundo donde el software es motor de la economía y el cambio, la brecha de género en tecnología iría disminuyendo. Pues au contraire, resulta que aumenta.

Estadísticas de brecha de género

La brecha de género en el mundo del desarrollo de software ha aumentado (Brookings)

Cuando te pones a leer sobre ello, descubres que, por desgracia, se trata de una pauta decreciente que se viene observando desde hace más de 20 años. El Foro Económico Mundial calcula que Europa occidental necesitará al menos 61 años para cerrar la brecha de género. ¿Y USA? Pues USA más del doble, 158 años.

¿Qué pasó en 1984?

1984 (Quoctrung Bui/NPR)

Esta tendencia también se refleja en España. El porcentaje de mujeres que eligen estudiar carreras técnicas o ingenierías ha bajado un 1,4% en 7 años como muestran los datos que publicó El Mundo en verano de 2017.

Datos de España

En España también hay menos ingenieras (El Mundo)

Hay muchas personas inteligentes trabajando en este tema; hay gente analizando los motivos que explican por qué está pasando esto, también hay gente haciendo propuestas políticas, programas sociales, etc. Yo conocí a finales de 2017 el programa Girls for a Change, dirigido a niñas de 10 a 18 años. Su objetivo es despertar en ellas el interés por la innovación, la tecnología, y el desarrollo de software; de manera que tengan las herramientas y competencias para desarrollar su liderazgo a través de la tecnología. Lo organiza una ONG estadounidense que se llama Iridiscent, y el programa se materializa en el Technovation Challenge.

El Technovation Challenge es una competición internacional de proyectos de transformación digital que tienen que hacer en su totalidad las niñas, trabajando en grupos de 4 o 5 más o menos durante 12 semanas. El proyecto cubre todas las etapas: desde la identificación de problemas en su entorno, la ideación de soluciones, conceptualización y prototipado, desarrollo de una app, y preparación y presentación de un pitch ante un jurado. Lanzado en 2010, hasta la edición de 2017, habían participado más de 15.000 niñas de 100 países. Y por lo visto, parece que funciona. Según sus datos, el 58% de las niñas que participan se inscriben en cursos de programación o tecnología, y un 26% de las mayores eligen estudios universitarios en informática.

Equipos 2017

Equipos de Technovation Challenge (2017)

En realidad cada año van a más, y tienen más impacto. En España participaron en 2017 más de 350 niñas, y un equipo de niñas de Las Rozas consiguió llegar a la final en San Francisco. En 2018 todas las expectativas se han desbordado. De hecho en Madrid llegaron a la fase final 92 equipos, en Valencia 65, en Aragón había cerca de 40, etc.

Os voy a contar en este post mi experiencia con las Perfect Stranger Girls, un equipo de 5 niñas de 11 y 12 años (aunque la más pequeña empezó con 10) que ha quedado entre las 3 mejores de Madrid y se ha clasificado para las semifinales de España. Con ellas hemos trabajado de mentores Isabel Alonso Matey y yo, con la ventaja de que ella ya fue mentora en 2017 y se sabía el proceso, los pasos, etc. Hemos estado trabajando en las aulas que nos ha cedido el American Space de Madrid.

Como veréis, es un proceso que cubre las etapas de inception, conceptualización, diseño, desarrollo y venta, aplicando técnicas de Design Thinking, UX, prototipado rápido… Vamos como lo que hago en la vida real, sólo que con niñas, lo que lo convierte en algo completamente estimulante, inspirador, rejuvenecedor y muy divertido.

Inception

Lo primero que hicimos durante la primera sesión fue presentarnos, conocernos, y hacer un proceso de Inception. Primero para que todas tuvieran la misma información sobre para qué estaban allí, cuál iba a ser el proceso que íbamos a seguir y los pasos que teníamos que dar. Pero sobre todo para que compartieran cuáles eran sus objetivos y también sus prioridades.

Para ello hicimos dos de las dinámicas habituales del proceso de Inception:

  • Definición de Objetivos personales. Con un brain storming de los objetivos que cada niña traía. Siendo el primer día, venían muy condicionadas con objetivos del tipo «crear un mundo mejor», «ayudar a otras personas», «superar retos», etc, quizá un poco por el contexto que habían recibido antes de empezar, en las charlas introductorias a technovation. No se si es la clase de objetivos que en realidad se plantean niñas de 11 años, pero bueno, no soy pedagogo ni psicólogo… Es lo que dijeron y sobre ello trabajamos. Quizá el año que viene la definición de esos objetivos sería diferente, who knows?
  • Trade-offs, o criterios de toma de decisión. Lo que hicimos fue básicamente que cada una de ellas priorizara sobre esos objetivos cuáles tendríamos que utilizar a la hora de tomar una decisión en caso de disparidad.
Inception

Objetivos y criterios de toma de decisión

En general, me gustó que este primer día ninguna de ellas venía condicionada por la parte «challenge», es decir, aunque es una «competición» que tiene «rondas» y «finales», ninguna dijo que esperaba ganar.

El primer día hicimos también una dinámica de generación de nombre para el grupo. Utilizamos algunas técnicas combinando sus «cosas favoritas»: nombres de canciones, grupos musicales, personajes de ficción, colores, sabores, sus propios nombres, sus iniciales, etc.

De aquí salieron dos conceptos, el primero fue RAPAZes que está compuesto por sus iniciales en un determinado orden, y su país de origen; y además suena a «rapaces», lo que por una parte recuerda a ave de presa, y por otra, a que en el norte a los niños se les llama también rapaces. A partir de ese día, ya no había duda de en qué orden tenían que hacer las cosas o ponerse, el orden era el que formaba «RAPAZes». El segundo concepto fue el nombre final del grupo, las PERFECT STRANGER GIRLS, que venía de evolucionar Stranger Things (a todas les llamaba mucho la atención esta serie de Netflix, imagino sobre todo que porque no les dejarían verla) a Stranger Girls, y de ahí añadieron lo de Perfect (aunque ellas no sabía que Perfect Strangers era como se llamaba lo que aquí conocemos por Primos Lejanos o la serie del Primo Balki)

Ideación

El segundo paso fue buscar un propósito para el equipo, ¿qué problema querían resolver? Al fin y al cabo, el objetivo de Technovation Challenge es identificar un problema que las niñas vean en su entorno cercano, y que sean ellas las que busquen una solución a través de la tecnología.

Technovation Challenge toma como punto de partida los Objetivos de Desarrollo Sostenible (ODS o SDG en inglés) que promueve la ONU. Así que lo que hicimos fue: primero un brainstorming general de qué cosas se les ocurría que podrían trabajar, y luego intentamos alinear esas ideas con los ODS.

Ideacion

Las niñas van como una metralleta

Bueno, deciros que disfruté en esa ideación como un enano. Las niñas enseguida entendieron que el objetivo era generar y crear ideas, y en todo caso construir unas sobre las ideas de otras. No entraron ni a juzgar ni a cuestionar las ideas del resto. Hicimos una dinámica de «me gustaría». En media hora sacaron 40 y pico ideas, algunas tan geniales como:

  • «Me gustaría que la gente leyese más y estuviera menos tiempo con el móvil».
  • «Me gustaría que los mayores se atreviesen a teñirse el pelo de colores divertidos que les apeteciera, y no pensasen en lo que dicen los demás».
  • «Me gustaría crear una comida especial para que los perros cuando hagan **** cuiden y abonen los árboles».
  • «Me gustaría tener una fábrica de OREO».
  • «Me gustaría que las personas fuesen más valientes para conseguir sus sueños».

Los ejes en las que las agrupamos fueron: «Erradicación de la Pobreza», «Lucha contra el Hambre», «Salud», «Educación de Calidad», «Igualdad de Género», «Empleabilidad», «Innovación e Infraestructuras», «Ciudades y comunidades sostenibles», «Consumo Responsable», «Lucha contra el cambio climático», «Ecología», y «Paz y justicia».

Filtrado de ideas

Una vez que tuvimos las ideas, hicimos un proceso de filtrado para ir convergiendo hacia la solución que íbamos a elegir. Para ello, creamos 3 ejes:

  • Cuáles contribuían a mejorar la sociedad, porque era uno de los objetivos que se habían planteado el primer día en el proceso de Inception.
  • Cuáles tenían una utilidad real desde el punto de vista práctico, independientemente de que «mejorasen la sociedad».
  • Cuáles podían poner en práctica como parte del Technovation Challenge.
Filtrado

Filtrado de ideas en 3 ejes

¿Dónde entraba la parte de la autoridad o el criterio personal en la toma de decisión? Cada niña cogía un postit de todos los disponibles, y explicaba al resto los motivos de por qué lo colocaba en alguno de los 7 conjuntos resultantes. Como veréis en la foto, acordamos que «la que tiene el postit es su dueña». Como resultado de esta sesión de filtrado, conseguimos pasar de 42 ideas en bruto a 18 ideas que estaban en el centro de los 3 ejes.

Sobre esas 18 hicimos una segunda ronda de filtrado. Aplicamos una técnica de consenso entre iguales, de manera que cada una de ella tenía varios gommets para «votar» entre las 18 cuáles eran las ideas con las que se sentían más cómodas, y en general, cuáles querían seguir desarrollando. Se que muchas veces se cuestiona la técnica del consenso, porque diluye la toma de decisión y la responsabilidad en el «grupo» en lugar de en el «líder». Sin embargo, yo creo que en un contexto de voluntarismo (las niñas están allí porque quieren) y de igualdad (no existen relaciones asimétricas entre ellas) es la mejor alternativa.

Después de esta fase, quedaron 5 ideas:

  • Aprovechar las casas abandonadas o vacías para las personas sin techo
  • Luchar contra el hambre evitando tirar a la basura comida en buen estado
  • Trabajar en la igualdad de la mujer
  • Hacer la ciudad más accesible para personas con movilidad reducida
  • Conservar la biodiversidad luchando contra la extinción de especies

Elaboración de ideas

Sobre estas 5 ideas que quedaron del paso anterior, hicimos una dinámica de construcción conjunta, para elaborar más la idea y darle recorrido. Conjunta, para hacer que todas las ideas tuvieran un poco de la creatividad de cada niña, y cada niña hubiera aportado en todas las ideas. De esta manera, se consigue la adhesión de las personas a las ideas, que no son percibidas como «del otro» y por tanto se evita el rechazo. De todas maneras, estas barreras mentales yo creo que se dan entre los adultos, las niñas de 11 años no ven así el mundo.

Para ello, hicimos una adaptación del proceso SCAMPERa través de una dinámica muy apropiada para niñas, que es la técnica del cadáver exquisito.

SCAMPER son las iniciales de Sustitute, Combine, Adjust, Modify, Put to other uses, Eliminate y Reverse. Lo que se persigue es que a partir de una idea existente, se aplique alguna de las técnicas que forman parte de las siglas. El cadaver exquisito (cadavre exquis) es la técnica que usaban los surrealistas franceses para crear un texto o una imagen de manera colectiva; de forma que cada persona continúa lo que ha empezado otra, pero a partir de una visión parcial de su creación.

Cadaver Exquisito

La primera versión de la idea de DONATE

Una vez que las cinco niñas hicieron un primer ejercicio de elaborar todas las ideas, cada una cogió una y la leyó al resto. Y finalmente, tuvieron que elegir la que usarían como eje de trabajo de su proyecto de Transformación Digital.

La decisión final estuvo reñida, pero finalmente eligieron trabajar en cómo luchar contra el hambre haciendo que no se tirase a la basura comida en buen estado, poniendo en contacto directamente a las personas, empresas o restaurantes que la van a tirar con las personas u ONGs que la pueden necesitar. Una especie de Wallapop de la donación de comida.

Research

El siguiente paso que hicieron las niñas fue un proceso de investigación, en el que combinaron el acceso a información pública con datos socioeconómicos y demográficos, la entrevista con usuarios potenciales, y la investigación de soluciones existentes.

  • Identificación de datos de contexto generales, a través de búsqueda de información pública. Estuvieron buscando en Google con términos en castellano e inglés con los siguientes patrones: informes de entidades públicas, organismos internacionales y ONGs sobre cantidades de comida que se desperdicia, personas en riesgo de exclusión social, y niños que pasan hambre.
Research

¿Qué tipo de comida se desperdicia en el mundo?

  • Entrevistas con usuarios potenciales. Para ello tuvimos la suerte de contar con la ayuda de Rocío Carrasco, Amanda Fernández y Elena Flores , compis mías en Sngular. Plantearon la entrevista alrededor de varias cuestiones, como los motivos que las llevarían a donar comida en vez de tirarla, cómo les gustaría que fuese el proceso, si estarían dispuestas a llevar la comida a algún sitio o preferirían que alguien fuese a recogerla a su casa, etc. Además de posibles usuarias, resulta que Rocío trabaja en el equipo de User Xperience de Sngular creando patrones de interacción y sistemas de diseño para los canales digitales de grandes clientes; Amanda trabajaba en el equipo de DevOps montando arquitecturas en la nube y entornos de integración y despliegue continuo; y Elena, que además de diseñadora de videojuegos, trabaja conmigo en el equipo de Innovación planteando soluciones y modelos de negocio. Pensaba que podría ser inspirador que conocieran a chicas jóvenes, profesionales del mundo de la tecnología y la transformación digital.
Research

Muchas gracias Amanda, Elena y Rocío 😀

  • Análisis de la competencia. Para hacer el análisis de otras soluciones existentes en el mercado, estuvieron buscando en Google y también en la tienda de apps de Google Play. Una vez que identificaron qué apps se declaraban alineadas con objetivos similares a los suyos, las descargaron y las instalaron en un teléfono Android que les habían dejado alguno de los padres para cacharrear. Después, crearon una tabla con las principales características que habíamos planteado para nuestra aplicación, y lo que hicieron fue un benchmark, para ver qué funcionalidades estaban cubiertas en cada app, y cómo se cubrían. Las principales conclusiones a las que llegaron fue que muchas de las apps no estaban terminadas; la mayoría no daba información nutricional o sobre todo, de posibles alergias; y algunas eran para comprar y vender comida a precios más bajos.
Research

Análisis comparativo de competidores

Identidad

Veréis que las slides anteriores incluyen el nombre de la app y un isologo. Eso es porque aprovechamos el día que estuvieron mis compis para trabajar la identidad de la app. Primero estuvieron aprendiendo las diferencias entre isotipo, logotipo, imagotipo e isologo, identificando sus marcas favoritas y clasificándolas según cada categoría.

Marca

4 formas de representar una marca

Después hicieron una sesión de naming, a partir del propósito que habían definido para su app. Recordemos que tiene que ver con compartir comida para personas que la pueden necesitar. Por eso estuvieron trabajando con nombre y conceptos relacionados con la alimentación y compartir. Desde el principio les interesó la idea de hacer juegos de palabras con «eat» e «it», que en el inglés de los españoles, pues suenan igual.

Donate

Creación del nombre DON·ATE

Quedaron dos nombre: Share + eat = SHAREAT y Don’t + Ate = DONATE. Cada una eligió cuál de los dos nombres les gustaba más y quedó encargada de la misión de preparar un representación de la marca.

Donate

Propuestas de identidad

Al final la opción con la que se sintieron más cómodas fue con DONATE. El isologo de DONATE lo hicieron en un momento con el power point, es el nombre de la app con las letras en colores que ellas eligieron, y una olla humeante. Además, se les ocurrió un slogan / call to action «DON’T WASTE, DONATE». Como nota adicional, uno de los jueces decía que se le había quedado ese mensaje en la cabeza, jijij.

Don't waste, DONATE!

Don’t waste, DONATE!

Propuesta de Valor

El último paso que hicieron antes de empezar a diseñar la experiencia de usuario, fue terminar de recoger todos los elementos de la propuesta de valor. Para ello, aplicaron la técnica del business model canvas. Usamos la pizarra del American Space como canvas, y ellas mismas fueron complementando la información de las diferentes secciones. Algunas de las conclusiones más importantes a las que llegaron fueron:

  • Es importante mantener la información de la fecha de caducidad de los alimentos, y también de las alergias. Descubrieron que hay normas en la Ley de Información Alimentaria que obligan a informar de las posibles intolerancias alimenticias tanto en los envases de comida como en los restaurantes que venden comida elaborada.
  • También consideraron que en un modelo de relación entre personas es importante incluir un la valoración y reputación de los usuarios, al igual que hacen Wallapop, Airbnb etc.
  • En el caso de las personas que pueden estar en situación de necesidad, pensaron que no todas podrían tener un teléfono móvil ni conexión a internet, así que pensaron que las ONG podrían tener una red WiFi en sus sedes, de manera que si todas compartían el nombre de la misma WiFi (algo tipo donate_wifi) las personas podrían conectarse en esos puntos y acceder a la app.
  • Como habían visto que muchos restaurantes tienen la pegatina del búho de TripAdvisor o de Just Eat, pensaron en crear el sello DONATE para reconocer a aquellos restaurantes o supermercados que colaboran con la app.
  • Finalmente, pensaron que estas empresas u ONGs podrían crear un sistema de recompensas, para reconocer a las personas anónimas que se comprometan con DONATE. Por ejemplo, un premio podría tener que ver con donar alimentos saludables, o por llegar a un número x de donaciones, etc.
Business Model Canvas

El Business Model Canvas de DONATE

Wireframes

Una vez que estaban claras las principales funcionalidades de la app, el siguiente paso fue empezar a diseñar la interfaz para los usuarios. Para ello, les pedimos que trabajasen con sus padres en ver las apps que les gustaban (YouTube, Netflix, etc) para que identificasen qué aspectos de usabilidad a ellas le parecían relevantes.

A partir de ahí, empezamos a trabajar también en la pizarra varios conceptos. Primero hicimos una aproximación ultra sencilla a los sistemas de diseño, poniéndonos de acuerdo en cómo íbamos a representar los componentes y elementos de la app, la forma en que se iban a producir la interacción con ellos, las transiciones entre pantallas, etc.

Después fuimos funcionalidad por funcionalidad, dibujando en la pizarra una primera versión de la secuencia en que se podría producir la interacción. Como están en la liga Junior de Technovation Challenge, las reglas establecen que no es necesario que implementen toda la app, sino sus funciones principales. Por eso las pantallas y procesos clave que eligieron fueron:

  • El perfil y valoración de los usuarios. Se les ocurrió utilizar emojis de comida en lugar de estrellas para el scoring de usuarios
  • Subir a la plataforma un nuevo alimento que donar. Incluía la parte de hacer una foto, escribir la descripción y resolver cómo meter la información de alergias. La idea era tener un panel de iconos con todas las posibles alergias (gluten, pescado, etc) de manera que el usuario pudiera pulsar en aquellos elementos sobre los que quiere avisar. También habría un elemento de calendario para reportar la fecha de caducidad, la de envasado, etc.
  • El buscador de alimentos. Pensaron que el eje central de esta funcionalidad fuese un mapa donde se geoposicionasen los resultados por proximidad a la ubicación del usuario. Y que se pudiese filtrar por las alergias, fecha de caducidad, o la reputación del usuario que dona.
  • La WiFi gratis. Aquí planteaban tener una especie de catálogo de WiFi abiertas a las que se pudieran conectar las personas, indicando además en qué zonas de la ciudad estaban operativas.
  • La home de la app y el menú. Dado que es el punto de entrada a la app.
Wireframes

Wireframes de las pantallas clave

Prototipado

Una vez hechos los wireframes pasaron a la fase de hacer prototipos. Para ello usaron varias técnicas, desde hacerlos con cartulinas, a mano alzada coloreando, o con herramientas de diseño. Algunas de las herramientas que estuvieron valorando fueron balsamiq y moqups.

Lo que hicieron fue repartirse entre ellas las pantallas que habían identificado el día de los wireframes. Los prototipos pueden ser una de las entregas de Technovation, ya que para hacer la subida a la plataforma piden un esquema del proceso de cómo funciona la app.

Prototipos

Prototipos de DONATE

Los prototipos luego los usaron como guía durante la fase de desarrollo de la app.

Desarrollo

El desarrollo de los proyectos digitales de Technovation Challenge se hace con app Inventor, que es un entorno de programación visual y por bloques que desarrollaron de manera conjunta Google y el MIT. Permite trabajar en la edición de pantallas en un entorno que presenta los diferentes elementos que generalmente tiene una app, como formularios, botones, menús, imágenes, etc. Además, también ofrece mecanismos sencillos para usar otros elementos del teléfono como la cámara o el GPS.

App Inventor

Editor de pantallas de App Inventor

El mecanismo de edición visual es muy sencillo: existe una galería de componentes agrupados funcionalmente. En primer lugar, están los elementos que permiten crear interfaces de usuario: botones, check boxes, imágenes, cuadros de texto, etc. Para ordenar estos elementos en pantalla, hay una galería de componentes de Layout. La idea es que los layouts son contenedores de los elementos en pantalla, que se tiran dentro sencillamente con drag-and-drop, así que mi recomendación es empezar por transformar los mockups que se hayan preparado al layout correspondiente. Hay otra galería de componentes de Medios, donde está el componente de acceso a la cámara, otra de Mapas, Sensores donde está el acceso al GPS, el podómetro o el giróscopo, otra de Almacenamiento, donde está la base de datos local, etc.

Una vez compuesta la pantalla, se pasa al entorno de programación por bloques. El editor de código está estructurado de forma equivalente, con un área de trabajo y una zona lateral en la que se agrupan conceptualmente los elementos que se pueden utilizar. Así, las secuencias de control de flujo están entre los elementos de «control», las expresiones lógicas en «logic», etc. Y en cada pantalla existe una sección con el nombre del screen que se está desarrollando, donde se expone el acceso a las particularidades de los elementos que forman parte de dicha pantalla. De manera que desde aquí se accede y opera con los componentes que se han creado en el editor visual.

Bloques

Programación por bloques

La idea es de nuevo arrastrar con drag-and-drop al área de trabajo los componentes con los que se quiere construir la lógica de la pantalla. Por lo general, habrá que declarar acciones que ocurren al cargarse la app en la main screen. El almacenamiento de datos que incluye app inventor es bastante sencillo: aunque es persistente dentro de una sesión, se pierde cuando la app se reinicia. Así que por ejemplo, si hay que inicializar una base de datos habría que hacerlo en la pantalla principal. Otras acciones se lanzan al cargarse una pantalla en concreto, así que se declararán en el evento Initialize de esa pantalla. También se pueden asociar eventos que responden a las acciones del usuario en la pantalla, etc.

Por ejemplo, en la imagen anterior se muestra una forma de hacer:

  • que el componente «Cámara 1» ejecute la función «Take Picture» cuando se pulse el «botón 1»
  • que con el evento «After Picture» del componente «cámara 1» se fije el campo «Picture» del componente «Imagen 1» a la fotografía que se ha sacado
  • que cuando se presione el «botón 3» se compruebe si se ha hecho una foto, y si no se ha hecho, se muestre un mensaje al usuario en el cuadro de texto «Texto 3» diciendo que es obligatorio hacer una foto de la comida que se va a donar.

Veréis que la programación no es demasiado ortodoxa, lo importante es que la han hecho las niñas. Hemos primado que hicieran el proyecto a su manera por encima de seguir patrones y modelos de desarrollo. Por ejemplo, usamos una variable local a la pantalla para controlar si se ha hecho o no la foto, podríamos haberlo hecho de otra manera, pero así matábamos dos pájaros de un tiro: la guía de evaluación de Technovation Challenge indica que hay que usar variables.

Efectivamente, existe una guía de evaluación de código de las app, donde se comprueba que se hayan usado al menos 4 de 7 posibles «componentes», una base de datos, al menos uno de los dispositivos del teléfono, etc.

Para hacer las pruebas, hay que instalarse el MIT AI2 Companion en Google Play, y que a partir de ahí te instalas y sincronizas con el editor. También se puede sincronizar con un emulador de Android que te instales en el ordenador, pero es más gratificante probarlo en un teléfono. Cuando nosotros empezamos, no había una versión del App Inventor para iOS, aunque al parecer están en ello. Cuando está terminada la parte de pruebas, se puede empaquetar la app en un pkg que dejar instalado en un smartphone, o incluso subirlo a Google Play.

Por último, un par de cosas importantes a tener en cuenta durante la parte de desarrollo y que a nosotros nos dieron mucha guerra:

  • Para sincronizar la app con el teléfono y hacer pruebas, tanto el ordenador con el que se trabaja como el smartphone deben estar en la misma WiFi. Nosotros trabajábamos en el American Space y había varias WiFis, como cada día nos conectábamos a una a veces al conectarse y desconectarse de red se perdía la sesión de depuración.
  • Cuando estuvimos con la parte de desarrollo, App Inventor no soportaba que varias personas editaran con la misma cuenta el mismo proyecto de manera concurrente. Tuvimos varias situaciones en las que estuvimos a punto de perder el trabajo. Esto es un poco incordio; ya que un «proyecto» está asociado a una cuenta, y App Inventor permite exportar e importar «proyectos» pero no vimos la manera de exportar e importar «pantallas» o hacer un merge de «proyectos». Es decir, no podía trabajar cada una en una pantalla y luego juntarlas todas, porque una «pantalla» pertenece a un «proyecto». Al final tuvimos que trabajar en modo Peer Programming, cuando lo divertido para las niñas es precisamente crear pantallas, hacer las interacciones, y ver qué pasa.

Vídeos de Presentación

El reto Technovation también requiere preparar dos vídeos: uno en el que se recoja el uso de la app a modo de demostración, y otro en el que se haga el pitch. Ambos en inglés.

Para el primero, las chicas prepararon un guión que recogía en orden en que se navegaba la app y la explicación de las diferentes funcionaldiades. Después, una iba navegando por las diferentes pantallas haciendo las operaciones mientras otra, a modo de voz-en-off, iba narrando el propósito y el uso de DONATE.

Para el vídeo de presentación de DONATE, prepararon un guión un poco más largo. Las chicas hicieron un vídeo de 2 minutos y medio, en el que empezaban por introducir el problema en el que habían decidido trabajar, presentando los datos que encontraron durante la fase de research, y los elementos clave de la descripción de la app (aplicando la técnica de las 6W que veremos más adelante). Después, aprovechando el entorno del American Space, hicieron una serie de situaciones que recogían los diferentes casos de uso del sistema. Así, grabaron por una parte el papel de las ONGs como nexo sobre el que gira la mayor parte de las acciones del sistema; después también a los RESTAURANTES o TIENDAS que eligen colaborar con DONATE subiendo a la app la comida que les sobra al final del día; y finalmente a las PERSONAS comprometidos con la acción social. Después grabamos la escena en la que estas personas acuden a la ONG para entregar la comida, y cómo la recogería un NECESITADO. El modelo también podría ser P2P, entre la PERSONA y el NECESITADO, pero bueno, se ajustaron a la localización que teníamos para grabar.

Video

Hitchcok no era el único que hacía cameos

Los vídeos los editaron con la versión gratuita del Power Director directamente desde una tablet, y los subimos a YouTube para presentarlos al jurado, aunque están dados de alta como privados, sólo visibles a las personas con el link.

Pitch y Validación

La última parte fue preparar el guión de la presentación del proyecto, que corresponde con otro de los entregables de Technovation Challegne. Para ello las chicas trabajaron de forma colaborativa en crear un discurso que recogiera: quiénes eran las Perfect Stranger Girls, el research que justificaba el problema que habían identificado, una visión general de la forma en que habían pensado resolverlo, los diferentes usuarios a los que se dirige Donate y qué les aporta a cada uno, una presentación de alto nivel de la app, y finalmente el benchmark de las apps equivalentes que hay en el mercado y por qué Donate es diferente.

Primero lo escribieron en castellano, y lo pasaron a inglés cuando tenían claro lo que iban a contar y cómo iban a contarlo.

Después, prepararon un guión sobre cómo exponer la presentación, y qué parte debía cubrir cada una. Para ensayar la presentación, se nos ocurrió pedir ayuda a dos personas que podían echar una mano a las chicas a la hora de hacer un pitch. Y no sólo ayuda a pulir la presentación, sino que tuvieran una experiencia previa de exponer su idea ante unos desconocidos que la van a valorar, con la esperanza de que el día de la presentación al jurado estuvieran más tranquilas.

Pitch

Ensayando el pitch de Donate

Así que tuvimos la suerte de contar con la ayuda de  Luis Ramasco, que trabaja en el área de Imagen de Aldeas Infantiles. Al tratarse de una ONG cuya acción directa se destina a niños, podría ser un ejemplo de entidad que llegase a darse de alta en Donate. Así podrían validar la propuesta de valor de su idea / modelo ante un posible usuario. También nos acompañó Carmen Bartolomé, que además de haber lanzado varios proyectos de emprendimiento, también trabaja habitualmente con niños. Por tanto ella, como persona que ha tenido que buscar financiación para sus proyectos, podía orientar a las niñas a la hora de exponer su idea y destacar aquellos aspectos que la hacen viable y atractiva para inversores. Estuvieron con nosotros toda una sesión de trabajo, las chicas tuvieron tiempo de hacer 3 o 4 presentaciones, y la verdad es que notaba cómo mejoraba la presentación en tiempo real. De todas maneras, tuvieron todavía una sesión adicional para retocar el guión de la presentación y hacer que sus intervenciones y el paso que se daban unas a otras fuera más natural.

Otras actividades

  • Retrospectivas. Al acabar algunas sesiones de trabajo de los viernes, hacíamos retrospectivas para que las niñas compartieran su sensación con el proceso que estábamos siguiendo. En algunas ocasiones, aplicábamos la dinámica de la estrella de mar, que consiste en crear 5 sectores en los que se apuntan aquellos aspectos que hay que «mantener» (es decir, seguir haciendo), «empezar a hacer» (cosas que no se hace y que debería), «hacer más» (algo que parece valioso y que por tanto hay que potenciar), «hacer menos» y «dejar de hacer» (algo que no aporta valor o que obstaculiza el trabajo). Una vez hechos los sectores, los íbamos recorriendo y cada una de ellas compartía su punto de vista, que quedaba recogido y que intentábamos tener en cuenta en las siguientes sesiones. En otras ocasiones, las chicas usaban el medidor del diverómetro, que consistía en un marcador de 0 a 100, donde 0 era el aburrimiento absoluto y 100 la diversión máxima, y cada una ponía un score (solía estar en el 100 o por encima jeje)
  • Descripción de la App. El challenge les obligaba a presentar una descripción en menos de 100 palabras en inglés de qué es DONATE. Para hacerla, planteamos una dinámica de noticia periodística; yo recuerdo que me explicaron en el instituto el tema de las famosas 6Ws que tenía que tener una noticia en un periódico: What, When, Who, Why, Where y hoW… Cada una de las niñas hizo una frase que respondiera a una de esas preguntas, las pusimos en común y cuando todas se sintieron cómodas con la descripción y no quedaba ninguna de las 6 por responder, las pasamos a inglés.
  • Póster del proyecto. El evento de presentación de Technovation Challenge es una especie de feria tecnológica, en la que se destina un gran salón para que las niñas expongan sus proyectos. En 2018 hubo un total de 92 equipos, que se repartían en mesas de 3 equipos. En cada mesa, los equipos ponían un «poster» de exhibición de su proyecto. Las chicas lo hicieron a partir de las slides del documento de presentación, la verdad es que quedó super sencillo. Otros equipos llevaron regalos para los asistentes (pulseras, caramelos…), incluso había auténticos festivales de repostería (bizcochos caseros, muffins…) y despliegues de tecnología (terminales para probar la app, etc) En fin, sacamos muchas ideas para la feria, aunque tuvimos un stand muy discreto, en realidad esta exhibición no forma parte de la valoración del jurado.
  • Entorno colaborativo. Utilizábamos Google Drive para subir los materiales que íbamos generando en cada sesión, así como los que iban trabajando en casa; y Google Presentations para preparar el docu de presentación.

Technovation Challenge 2018

El 12 de Mayo, en el Auditorio de Leganés de la Universidad Carlos Tercero de Madrid tuvo lugar la final regional del Technovation Challenge. La verdad es que el evento fue impresionante y muy muy emocionante. Participaron un total de 92 equipos de las divisiones Junior y Senior, con equipos que vinieron de otras partes de España (Galicia, Canarias y Murcia). Ver a todas esas niñas con sus proyectos de transformación digital, el auditorio lleno, una pasada. Enhorabuena a Lorena Martín por todo lo que ha movido en términos de participación, a todos los mentores que ha reclutado, a los jueces, patrocinadores, la verdad es que una pasada.

Las Perfect Stranger Girls hicieron su presentación a medio día, ante un jurado compuesto por 5 personas que debía valorar de acuerdo a los criterios generales aspectos como la claridad y la viabilidad de su idea, la solución técnica presentada, o la claridad y argumentación de la defensa de su proyecto.

Pitch

Presentación ante el Jurado

Para mí fue muy emocionante ver a las chicas defender el proyecto Donate delante del jurado, cómo hicieron la exposición y respondieron a algunas preguntas que les hicieron, que obviamente las tuvieron que responder por sí mismas «en tiempo real». El jurado les dio la enhorabuena tanto por la idea, como por su exposición, y todos les dijeron que el slogan que se habían inventado «Don’t waste, Donate!» les había resultado muy pegadizo.

Después llegó la espera hasta conocer los resultados del jurado. Fue un momento de mucho nerviosismo, aunque el primer día habíamos quedando que el objetivo que tenían las chicas era divertirse y aprender, pues estando allí quién más quién menos, todo el mundo esperaba ganar. Y bueno, después de una larga espera empezaron a decir los nombres de los ganadores, y tuvimos un momento Oscars 2017. Anunciaron por orden alfabético los tres equipos ganadores de la final regional de Madrid, y llamaron al equipo «Perfect Strangers». Sabíamos que «Stranger Things» había tenido tirón, porque otro equipo se llamaba «Stranger Girls», así que no sabíamos a quién habían llamado y nos quedamos en nuestros sitios con una sensación un poco agridulce 😦

Perfect Stranger Girls

Las Perfect Stranger Girls on stage

Pero entonces la organización, al ver que sólo habían bajado dos equipos, aclaró que el nombre correcto del equipo era «Perfect Stranger Girls», OMG!

Así que las chicas tuvieron que bajar corriendo al estrado, recoger su premio, y presentar Donate delante de un auditorio que estaba lleno. Fue una pena que no pudieran todas disfrutar de su momento, porque una había tenido que irse a una Comunión.

One more thing…

Como os podéis imaginar, para mí todo esto ha sido una de las mejores experiencias que he tenido últimamente. Trabajar con las niñas es algo divertido, refrescante y rejuvenecedor. Verlas trabajar como un equipo, sin prejuicios, respetándose, dejando decisiones sin tomar los días que no estaban todas juntas… Y bueno, pensar que quizá he podido impactar en su vida de alguna manera positiva, y que quién sabe, lo mismo de mayores eligen estudiar una carrera técnica y trabajar en tecnología.

Yo os recomiendo a todos los que me estáis leyendo que el año que viene os impliquéis con el programa Technovation Challenge. Apuntando a vuestras hijas, si las tenéis. O contándolo en los colegios o en las AMPA. O como entrenadores de un equipo, o como jueces, o patrocinándolo. En fin, como sea. Merece la pena formar parte de este movimiento.

Actualización 05/06/2018

La sección de tecnología de la Segunda Edición del Telediario de la RTVE se hizo eco de DONATE

RTVE – Segunda Edición del Telediario 05/06/2017

El software es como un toro, ¿no?

En el año 2001 tuve la suerte de conocer a una persona que trabajaba en uno de los mayores fabricantes de software del mundo. Cuando me dió su tarjeta de visita, no pude sino observar estupefacto su título: era Evangelista Técnico. Me quedé siberet. Yo era un miserable Analista Programador, y eso de ser Evangelista me parecía lo más de lo más.

Con la edad, he llegado a asumir como algo normal la existencia de toda clase de Evangelistas; no en vano, el mundo de la informática está lleno de parábolas que intentan explicar, hacer ver, abrir los ojos, o simplemente, adoctrinar, qué es o qué deja de ser un proyecto de desarrollo de software. La mayoría de las veces, se usan para que alguien que paga por un sistema entienda que va a tener un retraso en un proyecto, un aumento del precio, la imposibilidad de lograr ciertos resultados, o todas ellas.

Software es como un toro

«En peores plazas hemos toreao»

Así que, iluminado por el trabajo ingente de Antii Aarne y Stith Thomson, me embarco en la romántica tarea de recopilar fábulas y folclore tradicional de los que vivimos en el mundo de la programación. Si conoces alguna analogía que no esté aquí recogida, estaré encantado de añadirla 🙂

Las Parábolas del Software

Lo que pasa es que el tema de las metáforas sobre el desarrollo de software tienen un riesgo inherente, ya lo decía Martin Fowler en el 2004. Utilizar esta clase de paralelismos puede no ser la mejor forma de responder a las inquietudes o problemas de la persona que está pagando por tu trabajo. Sobre todo si tu argumento se apoya en un concepto que la otra persona puede contra-argumentar, lo que en la práctica supone que has trasladado un problema a un dominio semántico diferente, en el que quizá no seas experto o no te sientas tan cómodo.

  • «9 mujeres no hacen un niño en 1 mes». Porque llega un momento en que por mucho que se añada gente a un equipo, la capacidad de reducir los plazos paralelizando el trabajo no es infinita. Sin embargo, tener un hijo es una tarea que por definición sólo puede hacer una persona y tiende a tardar en torno a 40-42 semanas. Por desgracia, lo normal es que tu proyecto de software incluya tareas que se pueden paralelizar hasta cierto límite y bajo ciertas consideraciones; y eso es exactamente lo que espera la persona que te paga por hacerlo: que seas capaz de organizar el trabajo de tu equipo dentro de ese límite.
  • «Desarrollar software es como construir una casa: necesita unos cimientos sólidos para no derrumbarse». Por eso, antes de poner las cortinas en las ventanas hay que levantar las paredes. Muy bonito, si no fuera porque el proceso de hacer los cimientos de una casa está sujeto leyes físicas, como cálculos de cargas o resistencia de materiales, profundidad, disposiciones, drenajes… Y sobre todo, donde hay normativas que cumplir. Nada de esto aplica a tu proyecto de software, la solidez de los cimientos de tu arquitectura en general depende de la persona que la diseña, y de su experiencia. Aunque hay patrones más o menos estándar, cada empresa de software construye los cimientos de sus proyectos a su manera, y la persona que los paga tiene que tener la certeza de que se están haciendo de manera correcta.
  • «Si quieres mover el baño 5cm, hay que tirar las paredes y romper los azulejos». Es una metáfora especialmente útil en aquellas situaciones en que si se hubieran pensando las cosas desde el principio, no habría que deshacer el trabajo. Nos lo recuerda habitualmente José Luis Vallejo, que además de ser mi CEO, es una de las pocas personas que conozco que ha lanzado una startup y se la ha vendido a Amazon. Sin embargo, a veces un cliente no quiere mover el baño, sólo quiere cambiar el modelo del sanitario, y para eso no hace falta picar el suelo ni romper los azulejos. Si lo haces, entonces tienes un problema.
  • «No puedes tener un Ferrari GTO al precio de un SEAT Panda». Usado para expresar que hay una relación entre calidad, potencia, rendimiento, diseño… y el precio que se ha de pagar por ello. Esta metáfora parte de la base de que una persona no sabe distinguir lo que es un Ferrari GTO de lo que es un SEAT Panda; cuando muchas veces lo único que quieren es un SEAT Panda con un motor preparado, faros tipo rally en la parrilla y unas llantas molonas.
SEAT Panda Carlos Sainz

Ojito con el Panda de Carlos Sainz (Imagen de brb83 en Slot Adictos)

  • «Esto tiene que hacerlo un experto, igual que no vas al dentista para que te opere de la cadera». No todas las personas son capaces de solucionar los mismos problemas, y con las mismas garantías. Lo que pasa es que tanto dentistas como cirujanos tienen una formación, una titulación y un Colegio que les habilita para hacer su profesión, de manera que cualquier persona puede comprobar su capacitación para esa intervención. Esto obviamente no ocurre en el mundo del software, donde muchas veces la única prueba que tiene el cliente de la capacitación del profesional proviene de su confianza en la empresa para la que trabaja.
  • «Para hacer unos huevos con bacon, la gallina se involucra, pero el cerdo se compromete» Usado durante muchos años para diferenciar el rol de las personas que son responsables del resultado del proyecto (Product Owner, Scrum Master y Equipo de Desarrollo) y los que están informados, opinan, o lo pagan. Por cierto, hace casi 5 años esta analogía desapareció de la guía Scrum, pero hay gente a la que le gusta mantenerla.
  • «No me pagas por apretar un tornillo, sino por saber qué tornillo hay que apretar». Es decir, no se juzga la tarea por la complejidad relativa a ojos de quién la observa, sino por el conocimiento que tuvo que adquirir el que la realiza. Esta es muy buena, y difícil de rebatir. En todo caso, diría que el problema muchas veces está en cuánto tiempo tarda un experto en encontrar el tornillo que hay que apretar, o que lo haga a través de un proceso de prueba y error que mine su credibilidad.
  • «Un proyecto de software es como subir al Everest: sabes de dónde sales, dónde quieres llegar y el camino que vas a seguir, crees que llevas todas las provisiones que necesitas y todos los días rezas por que no empeore el tiempo» Una metáfora útil para explicar que por muy experto que uno sea, hay circunstancias que escapan a nuestro control y que pueden hacer que todo acabe en tragedia. Esta también es buena. Sin embargo, puede volverse en tu contra si tú asumiste la responsabilidad planificar la expedición para llevar al equipo a la cumbre y ahora estás perdido en medio de la ventisca y se te ha olvidado coger el teléfono con enlace satélite.
  • «Programar es como conducir en mitad de un atasco, puedes ver lo que pasa a tu alrededor y tomar pequeñas decisiones, pero cambiar de carril no hará que el atasco termine antes» Útil para explicar que el ciclo de desarrollo es el que es, y llega un momento en que no puede acelerarse. Aquí lo que diría es que hay personas que no están dispuestas a comerse el atasco, y por eso sacan el Google Maps o el Waze antes de salir y coger una ruta más óptima, o que planifican su viaje para irse el día antes de la Operación Salida del Puente de Mayo.
  • «Un proyecto de software es como jugar con un Lego: puedes hacer una casa o un coche encajando las piezas que hayas comprado» Esta analogía que me sugería Luis Sánchez incluye además que hay es necesario un diseño preliminar tanto de la construcción como de las piezas, y que puede que no todas las piezas que tengas las necesites, ni que hayas comprado todas las que necesitas. Lo que está claro es que si el cliente quería hacer el coche, tienes que haber cogido ruedas.
  • «Cuando haces un jardín tienes una idea de cómo va a ser antes de plantarlo, aunque los detalles emergen después». Una idea de Félix Menéndez, que nos hace pensar que no sabes exactamente si debajo de la tierra habrá piedras, ni qué clase de insectos vas a encontrar, pero en cualquier caso, si no cuidas tu jardín seguramente las flores se sequen, y acabe todo lleno de malas hierbas. Interesante analogía, en este caso yo diría que es responsabilidad del jardinero haber elegido qué semillas tenía que plantar conociendo su ciclo de floración, cuándo había que regar, etc.
  • «Un proyecto de software es como hacer un pastel: necesitas una receta, reunir los ingredientes adecuados, seguir las instrucciones y respetar los tiempos de horneado» Esta idea foodie me la sugiere Daniel González, muy apropiada porque en la oficina echamos de menos las tartas que traía (a él también le echamos de menos) En este caso, es responsabilidad del cocinero haber comprado el producto en el Club del Gourmet o en los chinos. También diría que en el caso del software a medida, es el cocinero el que se ha inventado la receta, y que seguir la receta de un tercero no siempre es suficiente.
Pesadilla en la Cocina

Loca academia de cocineros

  • «Construir software es como levantar una Catedral: una combinación de arte y ciencia». Los que hemos leído «Los Pilares de la Tierra» nos sobrecogemos pensando en proyectos de 30 años y los malvados Hamleigh cuando Victor Sánchez utiliza esta metáfora. Tiene una derivada, y es que a veces las personas que están picando las piedras se olvidan de que su propósito es construir una catedral. Lo malo de construir catedrales es que a veces te coge a medio camino el cambio del románico al gótico.
  • «Desarrollar software a medida es como resolver un puzzle cuyas piezas tú mismo estás construyendo» Esta analogía es, hasta donde yo se, de mi propia cosecha. No recuerdo haberla leído, y estoy seguro de usarla desde el año 2008. Si estás resolviendo un puzzle y cambia la imagen de la referencia, seguramente las piezas que has construido ya no te sirvan. Como es mi propia analogía dejaré que seáis vosotros los que hagáis la contra-argumentación 🙂

¿Conoces más metáforas? Estoy ansioso por incorporarlas.

Tech Trends to ignore in 2015 (ft. Led Zeppelin)

Improve your reading listening to the playlist of this post! (powered by Spotify)

The Song remains the same

Dear friends, maybe you have noticed we are getting closer to New Year’s Eve. We should be out there shopping our Christmas gifts, but instead, we are about to be buried by Tech Predictions and Trends for 2015. Predictions made by Business Analysts, Market Researchers, Innovation Gurus… that dozens of LinkedIn members, hundreds of blog writers, and thousands of twitter users are anxiously waiting to comment and share. Sounds scary, doesn’t it?

Rocket Mailmen

This is one of my favourite Paleofuture pics. To hell with email, I want my jet pack (Rocket Mailmen, by Arthur Radebaug)

The best part is you can avoid it, by making a little research. If you invest 5 or 6 minutes in Google, you’ll find that most tech ‘predictions’ are like that Led Zeppelin’s song: they remain the same. Year after year. Of course, from time to time you’ll find these ‘predictions’ somehow presented in a different order (random). I bet you one pincho of Spanish omelette coupled with a caña of beer that the following 5 topics will be covered on most posts and articles of technological trends in 2015.

Communication Break Down

We are going to connect every single object to the Internet. There are enough IP addresses available to do it. Processors are as small as needed, and we can insert a mini SIM card in any possible object. So again, 2015 is going to be the year of the IoT. Like it was 2014, 2013, and 2012. Please, I just want to ask for a favour: be creative. Stop talking about the connected pacifier, the connected diaper or the connected fridge. We’ve been reading about the connected fridge since June 2000 when LG launched the first one. Do you own one? Do you actually know anyone who owns one? Exactly.

Babe, I’m gonna leave you

Companies are tired of buying servers. And they don’t want to maintain them neither. So this year we are going to invest more and more money in virtualization and cloud computing. I made my first talk about cloud computing 4 years ago, trying to break 10 common objections shared by my clients. Sometimes I still hear them 😦

Good Times, Bad Times

The way people interact with contents is no longer the same, it’s changing every day. This topic includes ‘we are going to buy better and bigger smartphones’ (although some Marketing Wizard coined the term phablet to refer a smartphone as big as a tablet), and ‘we are going to download more apps’, so there’s a lot of money in building phones and building apps. It doesn’t matter if (according to Nielsen) the average person uses each month only 26.8 of the million apps in each marketplace (1,2M in iOS, 1,4M in Android). It doesn’t matter that Canalys discovered years ago that 50% of the incomes generated in marketplaces are made by the 0.009% of the publishers (farewell Mr. Pareto). Damn it, I’ve read a week ago that apps are going to kill freedom in the Internet. I thought it was related with Net Neutrality and FCC, but it was the apps

Kashmir

Applications and services are going to be connected. Big deal. I remember being in a training course about Services Oriented Architectures in 2008 when a Evangelist of one of the biggest ICT companies in the world dared to say that by 2013, all the software was to be built using SOAP protocols. I was about to be late to my company’s Christmas Party for listening this kind of bullshit. With time, the debate on this topic evolved to micro services, open APIs, and API management.

Whola Lotta Love

Let’s do something with all the data we are gathering. Twitter is creating more content during a week, than the whole World during the Renaissance (I wonder which will have more impact in mankind) The point is: do we need all this digital garbage? The answer is plainly easy! We don’t need it at all 🙂 But once you are spitting data to a storage, you can identify patterns, learn something, and make choices. Don’t go to a meeting talking about Business Intelligence, or your partners are going to believe you are a time traveller from 2005. But remember: it’s not about the quantity, it’s about the quality.

Stairway to Heaven

Just tell me you have not been listening this tracklist for the last three years (at least). I have left behind ‘Security Concerns‘ intentionally, as it’s being a issue since the invention of the Internet.

Jimmy Page and Robert Plant

Ey, Mr. Tambourine Man, play a song for me (Imagen de Heinrich Klaffs)

Once we agreed in being tired of ‘Predictions’ and ‘Trends’, what I’d really like to know is what are going to do (or how are going to innovate) the people I know. So if you don’t mind, I’ll start by sharing my own Top 5 Innovation Trends for 2015.

  1. Workforce Gamification. Using game elements to provide awesome experiences that engage employees in learning/ transmission of company’s culture / etc. I find gamification to be an interesting technique to promote behavioral change, and companies are places where people want their colleagues to behave in a different way. Yet the truth is grown people never change, unless they find good reasons to do it. Tags: #gamification #digitaltransformationmanagement
  2. Behavioral targeting outside eCommerce. Businesses based on eCommerce and online sales are focused (I’d say, obsessed) with conversion. Since their very beginning. But there are a lot of sectors where using data to predict client’s activity and enhance conversion is not being used, when it would be a good way to achieve growth! I’m aware there’s a lot of space to apply these techniques in FinTech. Tags: #bigdata #conversion #personalization
  3. Online loves Offline. It’s good to know online sales are growing each year, but the truth is offline purchases provides people a meaningful experience of service, caring and support. Many companies invest a lot of effort by taking offline customers to online sales, but would it be possible to stop canibalizing the offline experience? What if we use technology to make it better instead? Tags: #bigdata #wearables #beacons #ecommerce #personalization
  4. People wear the power. It doesn’t matter if you don’t want to: smartphones, bracelets, watches, glasses… you are going to wear them, and they can monitor what you do. So use them wisely! For example, to understand where you are, what you are doing, how you are doing it, identify patterns and help users promoting healthy habits Tags: #wearables #mHealth #gamification #beacons
  5. Sustainability. Let’s make something useful with all the data available from your car, your house, and the energy you are using. The goal is not create a dashboard, but to provide people instant feedback on the impact that their actions have in environment and nature. Thus, to create a culture of sustainability and efficiency. Tags: #bigdata #internetofthings #energy

For me, it means Innovation because neither me nor the people I work with are doing it. And yet these are real projects that I’m planning to embrace in 2015.

What will be yours?

La Cúspide del Diseño Centrado en el Usuario

La Cúspide del Diseño centrado en el Usuario

Hace unos días compartía en la entrevista con los organizadores del Gamification World Congress que en mi opinón, la Gamificación debería considerarse la cúspide del Diseño Centrado en el Usuario.

Si echamos la vista atrás, veremos que el desarrollo de sistemas de usuario ha ido evolucionando desde que empezaron a hacerse masivas las aplicaciones en Internet en los años 90. La primera revolución fue la del diseño: los sites empezaron a diferenciarse de los demás dejando de tener ese aspecto Frontpage que todos recordamos. Para que los usuarios eligieran tu site frente al de los demás parecía que bastaba con que fuese “más bonito” que el resto. Luego vino la revolución de la arquitectura de información y la experiencia de usuario. No bastaba que tu site fuese más bonito: tenía además que lograr que los usuarios entendiesen cómo debían interactuar con él, y que esta interacción fuese lo más “natural” e intuitiva posible. Después llegó la revolución de la relevancia y los contenidos: con el exceso de información y la gran cantidad de sites que hay en el mundo, hemos tenido que luchar por el posicionamiento para captar la atención del usuario y por ofrecerle un contenido relevante.

Gracias a la Gamificación, entramos en una nueva forma de interacción con el usuario: ya sabemos cómo lograr que nos encuentre ante nuestra competencia, sabemos ofrecerle contenidos que le aportan valor, y sabemos mostrarle cómo consumirlo de una forma que le resulte intuitiva y estéticamente atractiva. La siguiente frontera es entender que más allá del valor que pueda aportar nuestro sistema en sí mismo (por su utilidad, contenido, etc) está nuestra capacidad como diseñadores para ofrecer al usuario una experiencia de interacción que responda a aspectos motivacionales: es decir, a aquellas interacciones que el usuario realiza porque realmente quiere hacerlas, porque hacerlas le aporta un valor psicológico intangible, relacionado con el sentimiento de diversión, de logro, de desafío, de superación, de compartición, etc.

Como la Gamificación se basa por tanto en el comportamiento del usuario y en aquello que le motiva, creo que es la disciplina de diseño más profunda, y por eso la considero en la cúspide de esa pirámide imaginaria del diseño de sistemas de información.

Veamos con más profundidad el detalle de este razonamiento .

Evolución del Diseño Visual y Arquitectura de Información

Los que somos un poco más viejunos sabemos que hubo un tiempo (lejano y feliz) en el que se navegaba por Internet en modo texto. Cuando entré en la Facultad de Informática (en el año 93), en el mítico Centro de Cálculo usábamos terminales que nos permitían acceder a la red usando Lynx. Lynx, que nació en el año 92, era un navegador en modo texto. Los sites, principalmente BBS, se veían por tanto como recopilaciones de contenidos en texto plano y enlaces que se podían seguir.

.

Lynx

Lynx, el navegador en modo texto del año 92

Las imágenes por ejemplo, tenían que descargarse como cadenas de caracteres que luego debían volver a codificarse. Eso no impedía que en aquellos incipientes años, la Red fuese un hervidero de porno (o eso me han dicho)

Pero enseguida alguien (concretamente en el National Center for Supercomputing Applications) se dio cuenta de que esto no iba a ninguna parte, y se puso a desarrollar el que se considera primer navegador basado en interfaz gráfica. Se llamaba Mosaic y la versión 1.0 salió al mundo en Noviembre de 1993. Antes de Mosaic hubo algún otro navegador, pero en general se asocia Mosaic como uno de los hitos en la masificación de Internet. Empezamos por tanto con la historia del diseño de sites. Según las estadísticas de Internet Live Stats, en 1995 se considera que había 25.300 sitios web. Como podréis ver a continuación, en aquella época la estética de los sitios era la que era, había que tener en cuenta lo incipiente de los estándares, el peso de las imágenes, la velocidad de conexión por módems, y demás. De cualquier manera, aunque muchos nos hagan creer que se han inventado el concepto de marketing de contenidos, fue en 1996 cuando Bill Gates dijo «Content is King»

 

Apple 1997

Apple en 1997, cortesía de la Máquina del Tiempo de Internet en web.archive.org

Pese a lo rupestre que nos pueda parecer, podemos identificar una cierto diseño en el site: la marca está presente, se separan las secciones, se utiliza un árbol de navegación con diferentes secciones de contenido, elementos destacados de diferente peso, se identifican claramente los enlaces… En la captura de pantalla no se ve, pero hay un footer con secciones de contenidos empresariales, información corporativa, contacto. En definitiva, ya se tiene en cuenta un diseño pensado para ser consumido desde un navegador. Han pasado 17 años y muchos de estos conceptos siguen aplicándose.

Pero Internet sigue creciendo y masificándose. En el año 2000 ya hay más de 17 millones de sitios web. Las empresas tienen que evolucionar, la estética y el diseño pasan a ser elementos diferenciadores del mensaje de una compañía, tanto en offline como en online. La imagen de Apple en el 2000 incluye cambios sustanciales en el diseño visual y en la forma de estructurar los contenidos.

 

Apple 2000

Apple en el año 2000, cortesía de la Máquina del Tiempo en Internet de web.archive.org

Podemos apreciar la transformación del site en el año 98 y 99, muy ligada a la Arquitectura de Información y la Experiencia de Usuario. En general, la evolución de los sitios web está íntimamente ligada a la creación de un cuerpo de conocimiento y maestría en ambas disciplinas. Su ámbito de aplicación está ligado a la ventaja que supone para una organización frente a su competencia la capacidad de que un usuario pueda acceder a la información que desea e interactuar con ella de forma natural e intuitiva. Por resumir discretamente y sin ánimo de ofender a los expertos :

  • La Arquitectura de Información trata sobre la construcción de estructuras que sean fáciles de entender por parte de los usuarios de un sistema. Es decir, trabaja en el contenido que se consume .
  •  Mientras que la Experiencia de Usuario se centra en las interacciones que realiza el usuario con el sistema para consumir el contenido. Es decir, trabaja en cómo se consume el contenido.

Precisamente en el año 2000 se publica la primera edición de “Don’t make me think”, escrito por Steve Krug, y que 14 años después se sigue considerando un libro de referencia.

En 2005 se lanza el servicio Google Analytics. Desde entonces vivimos obsesionados con la importancia de la medición del tráfico, de las tasas de rebotes, de la conversión de visitantes en clientes, del tiempo de permanencia en las páginas. En 2009 se estima que hay más de 238 millones de sites en el mundo. Llegamos a una época en la que se vuelve precioso el tiempo que pasa un usuario en tu web. Como cada vez se hace más difícil mantener la atención del usuario en un site, la experiencia de usuario evoluciona hacia la simplicidad. Los diseñadores de sitios web se centran en los comportamientos esperados de los visitantes, en qué es aquello esencial para el usuario, que no queremos que se pierda. Se reducen los elementos de interacción, los clicks necesarios, se estandarizan elementos comunes de referencia como mapas de web, buscadores arriba a la derecha, los caminos de regreso con migas de pan, etc.

Apple 2009

Apple en 2009, cortesía de la Máquina del Tiempo de Internet en web.archive.org

De un tiempo a esta parte, vivimos en una época dominada por el SEO. Nos guste o no, Google se ha convertido en una herramienta que puede determinar el éxito o el fracaso de un site: no hay vida más allá de la segunda página de Google. Google nos ha enseñado que si algo no aparece en la primera página es que hemos hecho mal la búsqueda. Pero ¿tiene eso sentido cuando resulta que hay más de 990.000.000 webs? Ya hemos aprendido a organizar la información que mostramos al usuario, ya sabemos cómo proporcionarle una experiencia de uso del sistema sencilla e intuitiva. Pero ¿cómo asegurarnos de que los usuarios nos eligen? Surge la necesidad de trabajar permanentemente en cómo Google nos muestra, cómo nos posiciona cuando los usuarios nos buscan, y cómo tenemos que responder a las actividades de nuestra competencia.

Cuando todos aplicamos las mismas técnicas, el resultado tiende a ser el mismo.

Viaje con nosotros

Busca las diferencias

 Se espera que haya 1 billón de sitios web en Junio de 2014. Todos comparten tendencias en diseño visual, todos saben cómo estructurar la información, cómo ofrecer una interacción intuitiva y cómo hacer que los usuarios les encuentren.

La Pirámide del Diseño centrado en el Usuario

¿Y qué tiene que ver esto con la Gamificación? La Gamificación es una disciplina que se basa en el uso de técnicas de juego en entornos no lúdicos, para conseguir el compromiso de los usuarios con el sistema.

La característica principal de los juegos es la voluntad del jugador, que participa en la experiencia del juego porque haciéndolo se lo pasa bien. Ese “pasarlo bien” es algo relativo, no a todo el mundo le gusta pasarlo bien de la misma forma. En general, se considera que hay una serie de factores que hacen que un juego sea divertido:

  • Proporciona feedback constante
  • Permite espacios para el fracaso
  • Contempla un camino de aprendizaje y maestría, basado en la dificultad para hacer determinadas acciones
  • Combina pequeñas y frecuentes victorias, con grandes retos que proporcionan sensaciones de victorias épicas
  • Incluye múltiples tipos de recompensas
  • Existe una coherencia entre las acciones con sus resultados

 

Mr Toledano Gamers

Las mítica galería de jugadores de Mr. Toledano

Para que funcione, el motor de un sistema Gamificado busca encontrar los aspectos de motivación de la persona que interactúa con el sistema, frente a la aproximación habitual de diseño basado en las funcionalidades que expone la aplicación. La historia de la evolución de Internet muestra los diferentes ejes sobre los que han ido construyendo los sistemas en la web: la apariencia, la sencillez de uso, la información, la utilidad del servicio proporcionado, la rapidez para la venta, la relevancia, la retención… Todos ello orquestado sobre una serie de requisitos o funcionalidades de un sistema: mostrar información o contenidos multimedia, vender productos y servicios, hacer operaciones financieras, etc.

Sin embargo cuando se construye un sistema Gamificado el eje central es el jugador. Para tener éxito, un sistema Gamificado debe diseñar las experiencias que el jugador quiere vivir porque responden a aspectos psicológicos de motivación. Al fin y al cabo, la Gamificación se centra en la psicología del jugador, debe dar respuesta a sus intereses, a lo que le divierte y le apetece, pero también a lo que puede hacer, o al conocimiento que debe adquirir para poder hacerlo; debe combinar un mecanismo de refuerzo de sus acciones, y también una forma de mostrarle rápidamente el resultado de las mismas. Primero se identifican estos aspectos, y luego se diseña cómo debe ser el sistema.

En resumen, hasta ahora las técnicas de diseño de sistemas de información se centran en la capacidad que tiene un usuario para interactuar con un sistema para obtener unos resultados. Mientras que la Gamificación se centra en los resultados que obtiene un jugador como consecuencia de la interacción con un sistema. De hecho, los propios términos ya dejan entrever esta diferencia. La Experiencia de Usuario se aplica a «personas» y usuarios, mientras que la Gamificación se aplica a jugadores, algo que ya de por sí tiene una connotación relacionada con la psicología y el comportamiento.

Por tanto, si existiera una pirámide que ordenase de mayor a menor la profundidad del conocimiento que se necesita del usuario, y la importancia que se da a sus intereses a la hora de hacer el diseño de un sistema de información, sin duda la Gamificación ocuparía la cúspide.

 

Sutter, Marshall, Brannan

Sutter, Marshall, Brannan

Suiza, 1833. Johann Sutter ha terminado su servicio en el cuerpo de Artillería del ejército suizo. Johann Sutter ha dilapidado la fortuna de la familia de su mujer. Johann Sutter sabe gastar dinero. No sabe gestionar un negocio. No sabe cómo hacer frente a sus deudas. No quiere ir a la cárcel. Francia, 1834. Johann Sutter abandona a su mujer y a sus cinco hijos, y se embarca camino de Nueva York.

Oregón, 1838. John Sutter y un grupo de alemanes, rusos y nativos recorren Oregón hasta Yerba Buena. California, 1839. El Capitán Sutter de la Guardia Suiza ha establecido una colonia en la Alta California de más de 48 mil acres de tierra. Él la llama «Nueva Helvetia». Los demás, Fort Sutter. Fort Sutter acoge a colonos, pioneros, indios Mewuk y Maidu. En Fort Sutter trabaja James Marshall.

Fort Sutter

Fort Sutter, 1849 (Obra de J.W. Revere, publicada en New York por C.S. Francis en 1849. Imagen de Dominio Público en USA extraída de Wikimedia Commons)

Illinois 1844. Los doctores recomiendan al granjero James Marshall viajar al Oeste para recuperarse de la malaria. James Marshall recorre el Oeste siguiendo la Ruta de los indios Siskiyou. California, 1845. James Marshall llega a un asentamiento de colonos que se dedican a la ganadería. El asentamiento tiene un aserradero. El asentamiento necesita a alguien que eche una mano. El asentamiento necesita ampliar las tierras. El asentamiento necesita más reses en las tierras. El Capitán Sutter de la Guardia Suiza consigue dos leguas de terreno para James Marshall. Mayo de 1846. James Marshall se alista en el Batallón del Capitán John Frémont para luchar en la guerra contra México. Febrero de 1847. James Marshall termina su servicio y descubre que ha perdido su tierra y sus reses.

Agosto de 1847, James Marshall se asocia con John Sutter y recluta una cuadrilla de nativos y mormones para construir un nuevo aserradero en Coloma, 60 kilómetros al norte de Fort Sutter, en el cauce del Río de los Americanos. El material que necesitaban lo había comprado en la tienda de Sam Brannan.

Sutter's Mill

James Marshall posa frente al aserradero de Fort Sutter (Imagen de Dominio Público extraída de Wikimedia Commons)

Yerba Buena, 1846. Sam Brannan llega al pueblo junto con otros 250 mormones y funda la primera Misión de la congregación de los Santos de los Últimos Días. Aprovechando la imprenta de la Misión, lanza el segundo periódico de la región, el California Star. 1847, Sam Brannan abre una tienda de suministros en Fort Sutter. El consejo de Yerba Buena renombra la ciudad durante la guerra con México. Deciden llamarla San Francisco.

Enero 1848

La mañana del 24 de Enero de 1848, James Marshall baja al dique que su cuadrilla está construyendo para ensanchar el cauce del Río de Los Americanos. Encuentra reflejos dorados entre el barro. Encuentra piedras del tamaño de nueces. Decide envolverlas en un pañuelo y llevárselas a John Sutter. John Sutter tiene una enciclopedia. Tiene ácido nítrico. James Marshall y John Sutter tienen oro puro. También tienen miedo. No quieren que el oro arruine los planes de expansión de sus tierras de ganado. No quieren que el oro arruine la construcción del aserradero. Deciden mantenerlo en secreto.

No lo consiguen. Los mormones que trabajan en el aserradero avisan a sus hermanos en Fort Sutter. Los hombres de la cuadrilla sacan 100$ del lecho del río todos los días. Los hombres de la cuadrilla no quieren construir un aserradero. Que le den al aserradero. El 9 de Febero de 1848, el encargado de la tienda de Sam Brannan en Fort Sutter recibe a Jacob Wittmer, que quiere pagar con oro una botella de brandy. El propio Sutter tiene que intervenir y confirma que el oro es auténtico. Sam Brannan se entera. Sam Brannan viaja a Fort Sutter. Joder han encontrado más oro del que pueden sacar del río. Sam Brannan no quiere mancharse las manos de barro.

California

Young man, go west! (Sailing to California for the Californian Gold Rush, imagen de Dominio Público en USA extraída de Wikimedia Commons)

Mayo 1848

Sam Brannan lleva semanas comprando todas las bateas de la región. Todos los picos y las palas. Acapara provisiones. San Brannan tiene todo lo que alguien necesita para buscar oro. Sam Brannan tiene la única tienda que hay entre San Francisco y Coloma. Sam Brannan tiene un periódico.

El 12 Mayo de 1848 Sam Brannan recorre las calles de San Francisco gritando que se ha encontrado oro en el Río de los Americanos.

Sam Brannan vende a 15$ las bateas que a él le costaron 20 céntimos. Trabaja con un 99% de margen de beneficios. Ingresa 36.000$ en 9 semanas. Ingresa 149.000$ al mes. En 1856, la ambición y la lujuría de Sam Brannan le deja fuera de los Santos de los Últimos Días. ¿A quién le importa? Posee la quinta parte de San Francisco y Sacramento. San Brannan está haciendo 500.000$ al año.

La Fiebre del Oro

En 1850, una persona tenía que pagar el sueldo de 6 meses para cruzar los Estados Unidos y llegar a California. Aunque muchos de los mineros encontraban oro, lo cierto es que resultaba una inversión ruinosa. Los diarios de la época recogían que los ingresos medios de un buscador de oro estaban en torno a los 4,19$ al día. Pero como la mayor parte de la población activa se echó al monte a buscar oro, se disparó la demanda de mano de obra en las ciudades. En San Joaquín, un carpintero ganaba 25$ al día. Un minero 8$.

Por otra parte, de estos salarios había que descontar los gastos derivados de material, comida y alojamiento. Debido al exponencial incremento de la población, y a que cada vez menos gente trabajaba en el campo y en las granjas, el precio de la vida subió en California. Los gastos de manutención se dispararon. La estimación es que cada semana un habitante del condado de El Dorado gastaba entre 12$ y 14$ en manutención. En Nueva York, 1,78$.

Mineros

Audentes fortuna iuvat (Imagen de Dominio Público de autor desconocido)

La Fiebre del Oro no contribuyó a la riqueza de los mineros. En 1855 era una tarea tan penosa que sólo resultaba rentable para los propietarios de las empresas mineras. Sin embargo contribuyó al crecimiento de California. En 5 años, San Francisco pasó de tener 400 habitantes a 35.000. Con 250.000 habitantes en 1850, California fue admitida como Estado Libre. Además de Sam Brannan, otros emprendedores consiguieron hacerse millonarios:

  • Phillip Armour controlaba las exclusas de uno de los canales que permitía el paso del agua a los ríos donde se buscaba oro. Con la fortuna que hizo se trasladó a Milwaukee, donde fundó Plankinton, Armour & Company, un emporio de carne de cerdo enlatada con el que logró facturar cerca de 2 millones de dólares durante la Guerra Civil Americana.
  • John Studebaker empezó fabricando carretillas para los mineros. Con el dinero que consiguió fundó Studebaker Wagon Corporation, empresa proveedora de vagones de suministros del Ejército de la Unión. A principios del siglo XX, Studebaker entró de lleno en el negocio de los automóviles. En 1909, había ingresado más de 9 millones de dólares distribuyendo maquinaria agraria.
  • Henry Wells y Willian Fargo fundaron en 1852 en San Francisco una empresa que ofrecía servicios postales y financieros a sus clientes, con una capitalización inicial de 300.000$. En 1866, el servicio de diligencias de Wells & Fargo cubría más de 3.000 millas de territorio, desde California a Nebraska. En 1888, Wells & Fargo conectaba más de 2.500 comunidades en 25 estados de Costa a Costa.
  • Levi Strauss abrió su tienda en 1853, donde pertrechaba de provisiones a los mineros. En 1872, junto con su socio Jacob Davies, patentó un nuevo modelo de pantalones de trabajo, más resistentes y con ribetes en los bolsillos. A partir de ahí comenzó la producción de la prenda de vestir más fabricada de todos los tiempos.

En los Brazos de la Fiebre

En 1848 hay 5.000 mineros en las tierras que reclama Sutter buscando oro. En 1849, 40.000. En 1852 llega a haber más de 100.000 mineros buscando oro en California. James Marshall no puede terminar su aserradero. James Marshall es expulsado de sus tierras por los buscadores de oro. John Sutter ve como todas sus tierras son devastadas por los buscadores de oro y expropiadas por el Estado. John Sutter quiere formar una ciudad, pero en 1858 el Congreso de los Estados Unidos desoye su reclamación por la propiedad de las tierras. En 1860 James Marshall hace fortuna con unos viñedos en Coloma y decide probar suerte buscando oro. En 1870 John Sutter consigue una pensión de 250$ al mes por los impuestos pagados por una tierra que no era suya. Pasaría el resto de su vida reclamando al Congreso que restituyesen sus posesiones. En 1872 James Marshall consigue una pensión del Estado de California. En 1878 James Marshall vive arruinado en una cabaña en Coloma, donde moriría 7 años más tarde. En 1880 John Sutter murió sin recibir la indemnización que reclamaba.

Sam Brannan no acabó mucho mejor. Fracasó en sus inversiones. El adulterio le llevó a liquidar sus propiedades tras un acuerdo millonario de divorcio. Cayó en el alcoholismo. En 1888 consiguió vender las pocas tierras que le quedaban para cancelar sus deudas. En 1889 Sam Brannan dormía en las bodegas de los Salones. La mañana que le encontraron muerto, nadie sabía quién era.

Mitos y realidades del negocio de la mHealth

mHealth, con m de More Money

Reconozco abiertamente que me subo por las paredes cada vez que veo esos artículos sobre la cantidad de dinero que se mueve en el negocio de la mHealth. Lo digo porque soy tan obtuso que en lugar de salir a brindar con champagne  (y eso que no me gusta), intento rascar más allá de los titulares a ver qué hay, y cuánto más rasco, más me pica. Sí amigos, en el mundo de la movilidad y las apps hay gente amasando auténticas fortunas. Lo que pasa es que hay más bien tirando a poca, y son siempre los mismos.

Y eso es lo que os voy a contar hoy. En fin, que si te gusta el tema de las Apps y la salud, te recomiendo que no sigas leyendo, a lo mejor te vas a llevar una desilusión. La vida puede ser mucho mejor si pulsas aqui.

Here's Johny

Traigo noticias, y no te van a gustar (Imagen de tellmewhat)

El dinero que mueven las Apps

Según Gartner publicaba en Septiembre de 2013 el negocio de las Apps generará unos ingresos de 26.683 millones de dólares, entre Apps de pago, compras desde las Apps, y publicidad. ¿Cómo se reparten estos ingresos? Pues se reparten mal, muy mal.

Para empezar, según los análisis de App Annie, el 80% de los ingresos en Google Play se generan en la categoría de Juegos mientras que en iTunes, el porcentaje es ligeramente menor. Los juegos se llevan sólo el 75% de los ingresos.

Vamos a empezar a quitar parte del pastel. El 27% de los ingresos se obtienen en Google Play, y el 73% en iTunes según los datos de Distimo. Aplicando estos valores tenemos los siguientes datos:

  • En Google Play se generan 7.204 millones de $, de los cuales el 80% se lo llevan los juegos. Eso significa, que quedan 1.440 millones de $ para repartir entre el resto de categorías.
  • En Apple iTunes se generan 19.478 millones de $, como el 75% se queda en los juegos, quedan 4.869 millones de $ para repartir entre el resto de categorías.

Pero claro, es que los juegos representan sólo el 17% de las Apps en iTunes y el 14% en Google Play. Eso quiere decir, que estadísticamente:

  • Los ingresos de 1.440 millones de $ se reparten entre más de 740.000 apps en Google Play, lo que da lugar a un ingreso medio de 1.945,94$ por App. Unos 1.440€
  • Los ingresos de 4.869 milliones de $ se reparten entre más de 726.000 apps en iTunes, lo que significa un ingreso medio de 6.706,61$ por App. En euros, vienen a ser unos 4.960€
Comor

¿Comor? ¿Me estás diciendo que para ganar 6.500€ tengo que hacer una versión iOS y otra Android? (Imagen de Wiedmaier)

¿Cómo que ganar 6.500€? ¿Qué pasa, que las Apps se hacen gratis ahora o qué? Descuenta lo que hayas tenido que invertir para hacer esas Apps. A ver qué queda. O cuánto debes. Ah, que no sabes cuánto cuesta hacer un App. A lo mejor aquí te puedes hacer una idea aproximada.

La Salud es lo que Importa

«Pero bueno, Guardiola, vamos a ver. Intentas decirnos que esto de las Apps no es un negocio y no vas a ser tú ahora más listo que los analistas internacionales. Que están todo el día diciéndonos la pasta gansa que se va a mover en el negocio de las Apps móviles relacionadas con la salud»

No, si yo no dudo que se mueva dinero. Si lo que dudo es que vayas a moverlo tú. Bueno, vamos a hacer las cuentas de otra manera. Vamos a ir directamente al grano de la salud. Los analistas estimaron que en Apps de mHealth se iban a generar unos ingresos de, atención, 1.300 millones de US$ en 2012. Como veis, la cifra no va muy desencaminada, pero vamos a hacer las divisiones por las Apps de la categoría adecuada. Pero espera, es que la categoría adecuada es la combinación de Medical y de Health & Fitness.

Bikini Fitness

No se han leído el Harrison, pero seguro que consigen más descargas (Imagen de Rev. Voodoo)

Efectivamente. Según esto, en iTunes hay nada más y nada menos que 23.701 Apps de Fitness y Salud, y 19.499 Apps Médicas, dando un total de 43.200 Apps de mHealth. Y en Google Play, otras 31.279. Curiosamente, de todas esas Apps, más del 60% de las descargas corresponden a Apps de ejercicio, entrenamiento y pérdida de peso según datos de IDC Health Insights. El 12% están relacionadas con la mujer (salud de la mujer y embarazo) y otro 12% con referencia médica.

Pero bueno, hagamos las cuentas partiendo de esa cifra.

  • 351 millones de $ en Google Play, a repartir entre 31.279 Apps, tocamos a 11.221$ de ingresos por App. Unos 8.300€
  • 949 millones de $ en iTunes, a repartir entre 43.200 Apps, salimos a 21.968$ de ingresos por App, al cambio, 16.246€

Parece que la cosa ha mejorado, ¿verdad? Pues la verdad es que no. Lo que no os he dicho porque soy muy cuco, un poco sofista y me gusta que nos demos de bruces con la realidad es que esa cifra de 1.300 millones de $ amigos míos incluye:

  • Ingresos directos. Descargas y compras dentro de las Apps, ok. Pero también
  • Promoción. Ads y campañas de marketing. Es decir, el dinero que se mueve por promocionar aplicaciones dentro de aplicaciones, y fuera de estas. ¿O es que os creéis que las descargas se consiguen solas? Tengo pendiente contaros cuánta pasta os tenéis que gastar en conseguir que haya gente que se descargue vuestras Apps.
  • Servicios profesionales. Es decir, lo que uno se gasta en hacer las aplicaciones (conceptualizarlas, diseñar la interacción, su aspecto final y lo que vienen siendo programarlas), los especialistas médicos que tienen que dar solvencia al App, etc.
  • Venta de dispositivos. Dado que muchas Apps están pensadas para integrar dispotivos vía Bluetooth, como sensores, pulsómetros, medidores de glucosa, etc.

En fin.Es difícil valorar qué % responde exactamente a los ingresos que genera un App de mHealth. Pero nos hacemos una idea, ¿verdad? Más bien tirando a poco.

La Fiebre del Oro

El mercado de la movilidad es duro, salvaje y difícil. Hay demasiada gente intentándolo. Hay mucha gente perdiendo dinero. También hay gente que se está forrando. En 2012, Canalys llegó a la conclusión que 25 publicadores de Apps se llevan el 50% de los ingresos; hablamos de empresas como Electronic Arts, Disney, Rovio, Gameloft…  Empresas que entre ellas ingresaban 60 millones de $ en 20 días. ¿Y el resto? ¿Sabes que en sólo en iTunes USA hay registrados más de 251.000 publicadores?

Teorema de Pareto de las Apps: El 50% de los ingresos es generado por el 0,009% de las empresas

En el siglo XIX California vivió la denominada Fiebre del Oro (Gold Rush) Durante 7 años, más de 300.000 mineros se lanzaron a buscar oro por montes y rios. Durante ese tiempo las ciudades crecieron, se desarrollaron nuevas leyes y nuevas técnicas para encontrar el oro, murieron cientos de miles de nativos americanos y se hicieron toda clase de daños medioambientales. Se estima que en 5 años se sacaron 370 toneladas de oro. Lo curioso es que los estudios demuestran que los que realmente se beneficiaron de la Fiebre del Oro fueron los comerciantes, transportistas, constructores, políticos… y los dueños de bares y burdeles, claro.

Oro

Nos han rechazado el App, Jebediah, mira que te dije que lo probases en iOS7 (Imagen de Mike Overall)

Pues con las Apps pasa lo mismo. Estos números apestan. Lo mires por donde lo mires. Los números no salen. Hay una última cuenta que quiero hacer, para que la imprimas y lo pienses 2 veces la próxima vez que quieras hacer un App. Vuelvo a los datos del principio. A los de descargas gratis y descargas de pago que decía Gartner.

  • Con 11.105 millones de descargas de pago que generan 20.204 millones de $, cada descarga de pago genera una media de 1,82$. Osea, 1,34
  • Con 92.876 millones de descargas gratuitas que generan 6.442 millones de $ en anuncios y compras desde el App, la media es que cada descarga genera 0,06$. Osea, 0,04€

Esos son los números que tienes que tener en cuenta cuando hagas tu App. ¿Cuántos miles de descargas necesitas para recuperar tu inversión? ¿Y para ganar dinero? Pues ahora tira esa cifra a la basura, porque no has contado con lo que tienes que invertir en posicionar tu App para que la gente se la baje.

Odiseo Unchained

Si has llegado hasta aquí, entonces felicidades, porque sabes cómo está el patio. Atado al mástil, has sobrevivido a los cantos de las sirenas que intentaban atraerte a los acantilados de su isla para hacerte naufragar y luego devorarte. Ya sabes lo que hay detrás de esos números tan grandes.

Ahora piensa qué vas a hacer para que la gente se baje tu App, compre tu App, use tu App, recomiende tu App. Piensa en cómo vas a ser diferente,  en por qué tu App va a ser la que funcione.

No sé cuál es tu modelo de negocio. No sé si tu App de mHealth te la va a pagar el Estado, o se va a financiar con las cuotas de los asegurados. No sé si la planteas como una inversión en Marketing super segmentado, o quieres crear una base de usuarios para explotarla. No sé si quieres obtener ingresos por descarga o compras en el App, o es una herramienta que complementa un negocio tradicional de venta de dispositivos o consumibles.

No lo sé, pero no importa. Por que la buena noticia es que todos ellos pueden funcionar. La buena noticia es que hay gente que lo está haciendo. Otro día os contaré el caso de:

  • Una empresa que ha recibido más de 3 Millones de $ de financiación de Venture Capital
  • Una empresa que ha desarrollado un App especializada,  cuyo uso está ligado a la compra de un dispositivo.
  • Una empresa que ha diseñado un modelo de pago recurrente de consumibles necesarios para el uso de su App.
  • Una empresa que ha logrado una base de datos de 250.000 usuarios en 1 año.

Y todas ellas están en la categoría de mHealth. Pero eso será otro día. ¿Ya sabías cómo funcionaba esto de las Apps? ¿Has hecho un App de mHealth? ¿Cómo te está yendo?

PS1- Como en todos los post de la categoría Money Talks, ampliamos el repertorio de temazos del rock relacionados con el vil metal. Esta vez, una buena recomendación de la mano de la Steve Miller’s Band

mHealth: Las Oportunidades superan a las Amenazas

Una visita inesperada

Tengo una entrada a medio escribir sobre el tema de monetizar Apps en el proceloso mundo del #mHealth, pero he tenido que dejarla parada. Sí, es que este post se me ha colado en el camino, qué queréis que os diga. Podría inventarme alguna historia sobre que mi perro se comió mi MacBook, pero desde algunos años no tengo perro.

Lo cierto es que el otro día, como dice la entradilla, me invitaron a una reunión del Club Gertech un Club de Debate sobre Tecnología formado por Gerentes y directores del ámbito sanitario. Fue una reunión de lo más interesante, me hubiese gustado participar un poco más, pero también me gustaría que me invitasen a la siguiente, así que fui un buen chico  🙂

El caso que salí del encuentro en plena ebullición de ideas, pero con todo el lío del Encuentro que organizamos desde MediaNet en la UIMP no he tenido tiempo de pensar en ellas ni 5 minutos; como no quiero que se me olvide, me salto mi línea editorial para hablar de ello.

Exciting Changes Happening Soon

«May you live in interesting times», una maldición china que podría ser gitana (Imagen de kevin dooley)

Me gustó una de las reflexiones finales de D. Joaquín García Guajardo (@quinoguajardo), que apuntaba que si se hiciese el DAFO del mHealth, «las Oportunidades superarían ampliamente a las Amenazas». Así que después de fusilar la frase para el título del post, os cuento un poco.

La inteligencia social

La primera intervención de la jornada corrió a cargo de Esteban Moro (@estebanmoro) para hablar sobre redes sociales, el big data que alimentan cada minuto decenas de miles de personas y que está ahí, al alcance de cualquiera que le interese cogerlo, procesarlo y darle valor.

Gracias a la información que se obtiene de twitter de manera profesional a través de sus canales oficiales (GNIP y DATA SIFT), a la razón de 1$ cada 10.000 tweets en el caso del segundo, el grupo de Esteban Moro es capaz de analizar y georeferenciar la incidencia de enfermedades como la gripe. ¿Cómo? A través de la inteligencia semántica que puede aplicarse sobre esos 140 caracteres que la gente va por ahí publicando alegremente cuando tiene fiebre o le duele el cuerpo.

One Dollar

Pues vaya ful. Mis 9.871 tweets se podrían comprar por menos de un dollar (Imagen de Images_of_Money)

Si lo piensas, tiene todo el sentido del mundo. ¿Qué es lo que se supone que quiere el sistema sanitario? Por lo que veo en la tele, evitar el colapso de sus diferentes niveles, y si no se puede evitar, por lo menos que se preste la atención de la forma más ordenada posible. En general, si le preguntas a cualquier médico, lo que te dirá es que él en sí mismo es un recurso escaso, cuyo uso debe optimizarse en la atención de aquellos casos importantes, y no malgastarse en casos que no lo necesitan.

A mí utilzar la información que sale de twitter para conocer si hay picos de propagación de la gripe, si va por barrios, si pueden planificarse campañas, o adaptar los recursos a la necesidad real… Por ejemplo, haciendo que se refuercen los médicos de atención primaria en determinados centros, o llevando más dosis de la vacuna a unos que a otros, o empezando las campañas de vacunación antes, o después… Pues no se, a mí me parece que tiene ventajas para todos: para los pacientes, para los profesionales, para los que gestionan, para los que ponen la pasta…

Claro, montar algo así yo imagino que debe ser complicado. Imagino que habría que hacer alguna clase de comité que agrupe a gente de atención primaria, de hospitales, de servicios centrales… Y luego un comité para analizar las recomendaciones del comité. Ya se sabe cómo va esto.

Pues no… Por lo visto el problema no va a ser ese, viene un poco antes: en la viabilidad de obtener y procesar datos de salud obtenidos de una red social. Y claro, yo abro tuiter, veo que la gente dice lo que le da la gana y lo suelta en Internet, así, en abierto. Para que todo el mundo sepa que está acatarrado, le han operado del riñón, o el feto tiene ya 20 semanas y mira, parece que se le ven los huevecillos. Y es que les da igual su privacidad; porque por mucho que nos duela, vivimos en una sociedad que renuncia tranquilamente a su privacidad, no le interesa leerse los términos de servicio de nada, y además, si no renuncia le da igual porque se la quitan.

Who Watches The Watchmen?

Who Watches The Watchmen? (Imagen de FlintWeiss)

¿Nadie se ha parado a pensar que si lees twitter con el cliente para móvil, te bajas un tuit de uno que dice que tiene un herpes, te desconectas de internet, sigues viendo ese dato? Osea, que cualquiera de nosotros vamos por ahí con una base de datos con información LOPD nivel 3, puesto que incluye datos relativos a salud de personas que podrían ser identificables. Nos salvamos porque en el ámbito de actuación de la LOPD no intervienen los ficheros mantenidos por personas físicas en el ejercicio de actividades personales o domésticas. ¿Y si una empresa de regalos para recién nacidos se pusiera a navegar por tuiter escribiendo a la gente que dice que su mujer está de parto y el niño ya viene de camino? Me niego a creer que esto se me acabe de ocurrir a mí.

En fin, lo importante es:

  • que la política de privacidad de los términos de servicio de twitter, dice que autorizas que twitter recoja, ceda, trate, almacene, comparta y revele tu información, especialmente la que sea pública; como por ejemplo, tus tweets si no están protegidos
  • que según el Artículo 3 de la LOPD se considera un Dato Personal cualquier información concerniente a personas físicas identificadas o identificables
  • y que aunque no fuesen datos anónimos, el Artículo 7 apartado 6 dice  que podrán ser objeto de tratamiento los datos de carácter personal cuando dicho tratamiento resulte necesario para la prevención o para el diagnóstico médicos, la prestación de asistencia sanitaria o la gestión de servicios sanitarios, siempre bajo las condiciones de secreto profesional.

Dicho lo cual, queda zanjado el tema de si se pueden aplicar técnicas de análisis y monitorización en redes sociales de datos relativos a la salud para optimizar la atención sanitaria; sí que se puede, así que ahora hay que ponerse a ello.

En cuanto a la presencia en redes sociales y la exposición al trolleo… Bien, la gente ya habla de hospitales y sanidad, y les trollea, estén o no en RRSS. Todo el mundo sabe que al troll no hay que hacerle caso, pasemos de los trolles y centrémonos en las personas que sí están interesesadas en interactúar.

No diga Apps, diga Observatorio

La siguiente ponencia corrió a cargo del Dr. Julio Mayol (@juliomayol) a quién espero convencer para que suba a SlideShare todas esas presentaciones suyas tan interesantes, cargadas de datos y realidades sobre las que cimenta sus ideas y llamadas a la acción.

Trataba sobre las posibilidades que ofrece el smartphone en el mundo de la salud, por su capacidad de cálculo, dispositivos y sensores integrados o integrables, cámara y micrófono, etc. Teniendo en cuenta que prácticamente todo el mundo tiene uno de estos encima, ¿será posible dotar de utilidades al teléfono que aporten valor a la persona y al mismo tiempo ahorren recursos al sistema de salud? Parece que a priori lo raro sería no conseguirlo. En general, desarrollar una línea de Apps puede ser clave para que las personas vayan a los servicios de salud, primaria y especializada, cuando deban, y a ser posible, presentando información adicional que pueda ser aportada al sistema para su uso por todos los actores que interactúan con el paciente.

Marea Blanca

Qué manía os dado con que la gente no vayamos a los Hospitales (Imagen de San Diego Shooter)

Sin embargo, una de las cosas que más me sorprende en esta clase de debates sobre mHealth es el tema de la regulación. Es indudable que en materia de salud hay que mantener siempre una serie de requisitos. Por ejemplo, si estamos hablando de dosis de medicamentos, las personas tienen que tener la garantía que el App que le dice la dosis de apiretal al niño le está dando la cantidad adecuada. ¿Pero cuál es la forma de conseguirlo? ¿Abrir un proceso regulatorio que puede tardar años? ¿O mostrar al usuario los elementos que le den seguridad y garantías y decida por sí mismo?

Obviamente yo abogo por la segunda. Sobre todo por dos motivos:

  • La tecnología no espera. Ni las Redes Sociales. Ni… Nada. Nadie espera a la regulación. La regulación siempre llega tarde, igual que la policía por lo general llega cuando el crimen se ha cometido, o está a punto de cometerse.
  • El mal nunca descansa. En lo que he tardado en escribir este post, dos o tres tipos sin escrúpulos han visto que pueden hacer dinero jugando con el desconocimiento, la incertidumbre y la necesidad de los demás.

Por cierto, escuché un comentario que me puso la carne de gallina; hacía referencia a la obligatoriedad de mantener piezas de recambio de los dispositivos médicos, y si cómo esto se debería aplicar a los smartphones. Sí, a los smartphones, esos cacharros que fabrican para que tires a la basura cada dos años y que detrás de las bombillas, las medias y las impresoras, son el culmen de la obsolescencia programada. En fin.

Bueno, como todos los post que tienen que ver con mHealth, vuelvo al tema del Observatorio. Ese Observatorio que tiene que poner al paciente en el centro de todo el lío; porque el paciente es el que se descarga las Apps. Si no se las descarga, no existen. Y si no existen, el resto de los planes se vienen abajo. Construir un mecanismo de eficiencia, ayuda a la gestión, optimización de recursos, mejora en la atención, ahorro de costes, etc, basado en Apps tiene que tener la orientación total a las necesidades del paciente. Una vez que quede claro por qué la gente se va a descargar y mantener en sus teléfonos tu aplicación ya se puede pensar en qué beneficios va a tener para los doctores y para el sistema.

Fail

Adivinad qué ocurre cuando lanzas productos sin pensar en las personas que los van a consumir (Imagen de Nima Badley)

Pero no, este no es el post del Observatorio. Todavía me quedan dos post más para contarlo.

700 años de experiencia

A modo de conclusión, uno de los asistentes comentó que GerTech acumula entre sus socios unos 700 años de experiencia en la gestión sanitaria.

Gold Mine

Lo malo del oro es que hay que bajar a picarlo (Imagen de GSofV)

Exacto, ese sitio es una mina de oro. Toda esa información sobre necesidades en el ámbito de la salud y la gestión hospitalaria debería ponerse al alcance de gente con iniciativa, ganas de solucionar problemas, capacidad de obtener financiación y sobre todo, capacidad de aportar valor. Últimamente se les llama emprendedores.

mHealth: Cómo monetizar las Apps (1,5)

Sé que «me tocaba» escribir un post sobre organización y gestión del tiempo; pero no me he podido resistir a hacer una pequeña actualización sobre el tema de las Apps de #mHealth gracias al excelente post de los chicos de Game Oven en el que hablan de las cifras de su juego de éxito, Fingle.

Bien, en este post tan interesante que os he enlazado, se dan algunas cifras que van en la línea de mi anterior post sobre monetización de Apps en mHealth, que (Dios me libre de citarme a mí mismo pero) es este Vamos a ver qué cifras son esas.

Phileas Phogg and Passepartout

– Rigodón, no se cómo decirle a este chico que los caballeros no hablamos de dinero. – Es Passepartout si no le importa, Sr. Fogg (Foto de EssjayNZ)

Los datos que ofrecen sobre ingresos por publicidad son los siguientes:

  • Fingle Free revenue: €3.110,- with 132.857 downloads (since December 2012)
  • (…) Fingle Free’s average revenue was €17 / day
  • About 2.3% of Fingle Free’s downloads convert to revenue. We’ve heard that’s a good number

Bien, lo que esto significa básicamente es que con 132.857 descargas de un juego han ingresado 3.110€, lo que supone que cada descarga genera un eCPM de 0,023€ a un CTR del 2,3% Algo en la línea de lo que habíamos comentado el otro día.

Pero claro, independientemente de que chapeau! por los amigos de Game Oven, a los que desde aquí mando en perfecto castellano un abrazo cargado de admiración, vamos a ver la otra parte de la ecuación. ¿Cuál ha sido la inversión? Podemos hacernos una idea combinando este otro post.

  • Length of Development: 5 months
  • Budget: €2000,- of our own money
  • Fingle was made by 5 people of which two were full time employees of Game Oven and three with whom we set up a royalties contract.
  • The two employees at Game Oven have been paid minimum wage for over a year

Hagamos una idea de los costes de desarrollo: 5 personas 5 meses, de las cuales dos cobraban un sueldo mínimo y las otras 3 van a comisión (el post cita una cifra X cada 10,000 descargas de pago) No seré yo el que diga aquí lo que debería costar un equipo de desarrollo de aplicaciones móviles de 5 personas 5 meses formado por profesionales de Experiencia de Usuario, Diseño y Desarrollo iOS, pero seguro que cualquiera os podéis hacer una idea buscando cualquier informe de los que publica Infojobs o Hayes al respecto.

A eso, hay que añadir los costes de promoción del App. Que tampoco son explícitos, pero se cita:

  • The coolest thing we did was showing the game on national television for about three minutes, in a morning show mainly for women in their mid-life crisis
  •  Even with minimal effort, our game hit the newspapers but returned close to zero extra sales!
  • Another thing we experimented with were Facebook ads. The problem was that for each $2 unit sold on Fingle, our return from Apple would be about €1, but in order for the ad to show up for the right target audience, we had to put in about €0.70 cents
  • Promoter (paid & totally worth it)
  • a press release to all western iOS-covering websites, including a presskit. We constructed a huge list of emails and submission forms with the help of Promoter’s index of games-covering website
  • two narrative videos and one gameplay video found here, made with the help of filmmaker Gilles van Leeuwen
  • a  product specific website
  • a newsletter to all the people who subscribed on the Fingle website

Todo ese esfuerzo de Marketing es difícil de concretar en una cifra, pero parecen los clásicos de una campaña de comunicación online/offline. Si alguien puede darme una cifra orientativa, se lo agradecería.

Pero lo que no os he comentado (todavía) y es lo verdaderamente importante, es que Fingle es un juego de pago, que al cabo del tiempo ha sido complementado con una versión gratuita con publicidad (y no al revés). Los datos de la versión de pago también están publicados:

Fingle revenue: €76.920,- with 117.611 downloads

Es decir, el App se financia como aplicación de pago, y el artículo deja claro que desde el 12 de Enero que salió la versión de pago hasta Diciembre de 2012 que salió la gratuita, seguramente los costes de desarrollo ya se habían cubierto y estaban en beneficios.

Tío Gilito, Uncle Scrooge McDuck

Twisting by the Pool (Imagen de KentonNgo)

A modo de conclusión, y para que no se me malinterprete, el éxito de esta App es que se vende como churros, y se ha conseguido posicionar como un producto por el que la gente paga. Pero no se financia como App gratuita con ingresos por publicidad, porque ese modelo no se sostiene, como quería comentar en el post del otro día; y como espero que haya quedado claro.

Ahm. ¿Significa eso que las Apps de mHealth tienen que ser aplicaciones de pago? Tampoco he dicho eso, especialmente si una App está desarrollada por un organismo público, como puede ser una Consejería de Salud; en cuyo caso habrá que ver exactamente cómo Apple o Google le hacen un ingreso a un número de cuenta corriente. Entro en cortocircuito sólo de imaginarlo.

Hay otros modelos, pero ya os dije que los trataríamos en otro post. No quiero despedirme por hoy sin dos comentarios:

Comentario número 1. Estamos en un post sobre Money Talks, y aquí viene otro temazo relacionado con el vil metal

Comentario número 2. Un dato adicional; «People confessing to have had sex after playing Fingle: 479 and counting» Perdonad que os deje, pero voy a ver si me echo una partidita 😉

mHealth: Cómo monetizar las Apps (i)

Todos los meses reviso las discusiones sobre si es mejor o no hacer Apps nativas, y adivinad qué: exacto. Son discusiones que hacen técnicos para técnicos. En ninguna de esas discusiones he leído nada sobre la forma de obtener ingresos para las Apps.

Desde mi punto de vista, esa es la única cuestión a tener en cuenta a la hora de hacer un App: ¿esperas conseguir dinero con ella? Un momento, ¿he dicho la palabra dinero? No era mi intención, lo prometo, los caballeros nunca hablan de dinero.

Mr. Datta Phuge

Mr. Datta Phuge tampoco habla de dinero (Foto de OddityCentral.com)

Pero es cierto; hacer aplicaciones para el móvil es muy bonito y muy gratificante (es cierto), pero hay que desarrollarlas, y eso cuesta dinero. Lo primero que alguien debería tener claro cuando hace una aplicación para el móvil es si está haciendo una «inversión»; es decir, si espero recibir a cambio más de lo que me costó hacerla, o me conformo con cubrir costes.

Bien, los modelos de monetización de Apps están claros y son los que son. Hagamos un pequeño repaso, y veamos cuáles de ellos tienen cabida en el mundo del mHealth, porque recordemos que este artículo tiene la palabra mHealth en el título.

  • Canal de Venta. Está claro, uno puede hacer un canal de movilidad para vender sus productos que ya está vendiendo en el mundo offline. El teléfono se convierte en un complemento a la Web y a la tienda física, compro ropa o lo que sea y pago con PayPal o VISA. Los informes al respecto son fascinantes: según Forrester, en 2017 el 6,8% de las ventas online se harán desde el móvil (frente al 1% en 2011). El mensaje entonces parece claro: considera que tu canal móvil es una inversión más, igual que lo fue la Web en su día, y antes o después lo acabarás rentabilizando. ¿Qué tiene que ver la venta física con el mHealth? De momento parece que poco, así que nos olvidamos de ello.
Agencia Española del Medicamento

No compréis v1agra por Internet, que os vais a matar

  • Publicidad. Es posible hacer ingresos con la publicidad dentro de las Apps. De hecho, lo cierto es que se hace más dinero que antes. Según Flurry, entre iOS y Android se estima que se generaron más de 9 billones de US$ en 2012, de los cuales el 23% venían de la publicidad (siendo esta la fuente de ingresos que más creció respecto al año anterior). Ahora bien, ¿meterías Ads dentro de una aplicación de #mHealth?. Si te respuesta es «sí», pulsa -> aquí <-

Hagamos una breve pausa para ver cómo funciona la Publicidad Dentro de las Apps; os anticipo que la conclusión es que desde mi punto de vista un App con publicidad tiene menor valor percibido por parte del usuario, ya que la publicidad en el móvil suele ser molesta e intrusiva (que levante la mano el que quiera ver publicidad en su teléfono) y esto no compensa los ingresos que se consiguen a cambio. Ahora, lo vemos en detalle.

Hay muchas redes de publicidad en el móvil; los fabricantes de sistemas operativos móviles tienen las suyas; son AdMob de Google e iAd Network de Apple, pero hay muchas otras, como TapJoy, AppFlood , o en España MobiTargets Al final lo que un anunciante espera de una red de publicidad es llegar a cuanta más gente mejor, según sus criterios de público destino (al menor precio, claro). Y un desarrollador lo que espera es  obtener los mayores ingresos posibles. Como estamos hablando de monetizar Apps, veamos exactamente cómo va el negocio.

Cuando se entra en el modelo de ingresos por publicidad hay que tener en cuenta varios conceptos, que resumo rápidamente:

  1. Puedo cobrar porque el anuncio lo ven, en cuyo caso, se usa el concepto de CPM, o coste por mil impresiones. Como el CPM se mide por mil impresiones pero no siempre el número es redondo, hay otro parámetro que es el eCPM, o CPM efectivo.
  2. También puedo cobrar porque el anuncio genera tráfico a algún sitio (o CPC,coste por click). En general, este parámetro se mide con un indicador CTR, o click-through. Suele representarse como el % de impresiones que han generado tráfico hacia el destino (en este caso, lo normal es que sea otro App). Lo más habitual en el mundo de la publicidad móvil es combinar el modelo 1 y 2. También se usa el concepto de eCPM, básicamente una campaña de CPC combina los clicks con el tráfico, cada uno con su respectivo valor de ingresos y se ponderan.
  3. En el mundo del marketing online hay otros modelos de ingresos, como la generación de leads (CPA) en la que lo que se mide son las conversiones de usarios; pero en el mundo móvil no se estila mucho.

El CPM que generan los anuncios que colocas en tu aplicación no es un valor fijo, depende de muchos factores; principalmente de lo que los anunciantes están dispuestos a pagar según el público al que llega tu producto, y de cómo los desarrolladores han fijado los espacios publicitarios (recomendaciones a toda página, banners inferiores, etc.) De ahí que leáis alguna vez el concepto de «subastas».

Bien, empecemos a pintar el símbolo del $ por algún sitio. Por ejemplo, en el obsoleto modelo de banners lograr un CTR del 0,6% le reporta al desarrollador un eCPM que oscila 0,01$ y 0,5$.  Hay informes e informes que muestran que el CTR medio en iPhone es del 1,7% y un eCPM de 1,07$ mientras que en Android es del 1,1% y un eCPM de 0,88$. Por cierto, que el iPad es el rey del CTR, con un 2,5%

Asumamos un eCPM de 1$ que está muy bien, y supongamos que no te lo corten con una comisión la red de Ads. Pues para lograr recaudar 1.000$ hay que conseguir un bonito millón de impresiones. Covierte millones de impresiones a cientos de miles de descargas, y luego forget about it: recordadme que en otro post estudiemos cuánto va a costar lograr cientos de miles de descargas. Es la pesadilla que se muerde la cola: necesito gastar en publicidad para obtener ingresos por publicidad.

Nightmare

La Pesadilla, del Magic. Tuve una de la primera edición, ¿seré rico?

Resumiendo:

Para que una aplicación se financie con publicidad tiene que lograr cientos de miles de descargas, y un uso recurrente de la misma; y para ello hay que destinar una inversión importante en el marketing del producto. Y todo ello a cambio de ofrecer una experiencia de uso molesta para el usuario.

Moraleja: cuando veas anuncios en los que una red te promete un CPM de 30$ o incluso de 100$ recuerda que «si parece demasiado bueno para ser cierto, posiblemente no sea cierto»

De momento esta entrada se está alargando, así que habrá que continuarla otro día con otros modelos de ingresos. Los temas que tengan que ver con modelos de negocio los etiquetaré como Money Talks.