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

Cómo construir un eCommerce Singular. Capítulo 2, El Monolito

Aunque es verdad que a veces hacer las cosas mal cuesta más que hacerlas bien, nadie se propone de manera consciente construir un sistema de software que sea ineficiente o inmantenible. Simplemente, pasa. Algo se desarrolla pensando en resolver un problema; pero el problema va cambiando, o creciendo; y entonces se van añadiendo nuevos módulos, nuevos componentes, o se añade funcionalidad sobre algo que ya existía, y la cosa se termina por complicar.

Frankenstein, o el Nuevo Monolito

Un sistema de software donde todos sus elementos están fuertemente acoplados y además está autocontenido y se ejecuta como un sistema único puede llegar no sólo a ser difícil de mantener y evolucionar, sino que también podría no ser capaz de mantener su rendimiento y eficiencia cuando aumenta su uso y por tanto las interacciones, lo que viene conociéndose como escalar.

El concepto de acoplamiento en términos de ingeniería del software hace referencia a la dependencia que tienen diferentes partes de un sistema, a la hora de realizar la función para la que fueron diseñadas. Aunque es normal que cuando se construye un sistema, haya partes que necesiten de otras para realizar ciertas tareas, la forma en que esta dependencia se construye podrá hacerse con mayor o menor acoplamiento. Por ejemplo: el caso de un formulario en una web que acaba insertando información en una base de datos. Puede hacerse con cierto desacoplamiento cuando los datos de los formularios viajan por diferentes capas / componentes que los piden, los recogen, los validan y los procesan cada uno como corresponda; o muy acoplada cuando un único componente coordina la operación, y le va pasando al resto no sólo los datos, sino instrucciones sobre qué hacer con ellos y cómo hacerlo.

Monolito Obelix

UX Designer FullStack Developer DevOps as a Service

Tradicionalmente, se define un sistema Monolítico como aquél en el que todas las capacidades de representación, procesamiento y almacenamiento están entrelazadas, y son gestionadas como una única unidad de ejecución, prevista para correr en un único servidor. Es decir, una única aplicación contiene y es responsable de todas sus funcionalidades.

Hay muchos motivos por los que alguien acabaría teniendo un sistema Monolítico. Estadísticamente yo diría que de menor a mayor probabilidad, serían cuatro.

Primer motivo: porque alguien lo habría diseñado así intencionadamente.

En esta categoría podemos meter por ejemplo el llamado “Majestic Monolith” (no hace falta traducción) de Basecamp. En un artículo de 2016, David Heinemeier presenta el concepto Majestic Monolith para referirse a la forma en que Basecamp está construida. Los conceptos subyacentes a esta decisión de arquitectura son: eliminar abstracciones innecesarias, y hacer distribuidas únicamente las partes del sistema necesarias. Básicamente defiende que es la mejor alternativa en el escenario de un equipo reducido de desarrolladores (12), con experiencia y criterio, que conocen y entienden el código del sistema; código que se ha escrito con criterios de simplicidad, limpieza y orientación a la prueba. Teniendo en cuenta que este hombre creó Ruby on Rails, parece que es una decisión razonada que le permite mantener y evolucionar un sistema que en 2018 tiene más de 2,8 millones de cuentas registradas, accesible desde 6 plataformas.  

Segundo motivo: porque estaba mal diseñado.

Asumamos como cierto que las personas que han estudiado una carrera de informática (técnica o superior; en la universidad o en la FP, o como se llamen ahora respectivamente, que yo no estoy muy al día) han recibido los conceptos y bases necesarios para diseñar arquitecturas de software. Asumamos también como cierto que otras personas que no han estudiado en las universidades o centros de formación profesional pueden adquirir conocimiento a partir de la experiencia, la lectura de documentación y el aprendizaje autodidacta o desde un referente. Asumir estos planteamientos significa partir de la base de que las empresas ponen a diseñar arquitecturas de software a personas que saben como hacerlo, que han leído, conocen patrones de referencia, y quieren hacer bien su trabajo.

Sin embargo, shit happens. Como decía al empezar este post, no creo que nadie diseñe de manera consciente sistemas para que sean ineficientes o no escalen; simplemente a veces se toman las decisiones erróneas. En 2013 tres investigadores de la universidad de Groningen (Holanda) D. Tofan, M. Galster y P. Avgeriou publicaron un paper en el que analizaban las causas por las que un Arquitecto de Software llegaba a tomar malas decisiones a la hora de plantear una solución técnica.

D. Tofan, M. Galster y P. Avgeriou, ECSA 2013

Como resultado del estudio, llegaron a varias conclusiones, aunque a lo mejor no todas sorprendentes e inesperadas:

  1. El principal motivo que lleva a tomar decisiones erróneas a la hora de hacer una arquitectura de software es la dependencia con otras decisiones ajenas a la decisión técnica en sí; seguido por el impacto que una decisión a priori técnica tenía en el negocio. Es decir, al propósito por el que se está construyendo el software en la organización, en el caso de un eCommerce: ganar dinero vendiendo cosas por internet.
  2. Por el contrario, que hubiera demasiadas alternativas o muchas personas en el proceso de toma de decisión no se consideraban motivos relevantes de un diseño mal planteado.
  3. Existe una diferencia entre los motivos que detectan los arquitectos de software según su experiencia. Los que tenían menos de 5 años de experiencia consideraban problemático tener que enfrentarse a criterios y recomendaciones contradictorias a la hora de tomar una decisión, y que cuanto más había que pensar, más difícil les resultaba decidirse. Por el contrario, los arquitectos de software con más de 5 años de experiencia no daban importancia a estos conceptos, sino al tema del contexto y el negocio (lo cual hace inevitable resucitar la paradoja del Arquitecto de Software Junior)
  4. El tiempo medio que se se consideraba necesario para tomar las decisiones de diseño de una arquitectura de software era de 8 jornadas de trabajo. Paradójicamente, el estudio también apunta a que los arquitectos de software con menos experiencia tardaban la cuarta parte en tomar decisiones de diseño (de ahí el refrán acerca de la ignorancia y el atrevimiento)

Tercer motivo: porque estaba bien diseñado, pero en algún momento las cosas se torcieron.

Se que al final se me hacen unos post muy largos, que a veces abro muchos temas y demás, pero es que hay que hablar de la deuda técnica. Más allá de que nos guste más o menos el término, o su sentido; en el contexto de este post voy a usarlo porque me parece la forma más universal de hacer referencia a la degradación que sufren los sistemas durante su desarrollo y evolución. Puede que se partiese de un sistema bien definido y planteado, pero con el paso del tiempo la aplicación acaba siendo ponzoña. ¿Por qué? De nuevo, es algo que nadie quiere que ocurra de manera intencionada, yo creo en la buena fe de las personas. Pero ocurre.

Por lo general, el código de un sistema se degrada poco a poco, como respuesta a situaciones del tipo “me ha quedado complicado, pero ya lo arreglaré más adelante”, “no tengo tiempo para hacer las pruebas”, “este fallo debe ser un Expediente X, porque suele funcionar”, etc.

En 2015, Neil Ernst del Software Engineering Institute de la Universidad Carnegie-Mellon publicó un estudio / paper sobre los motivos de por qué sucede esta degradación. Os comparto la gráfica que me parece más relevante. Es bastante auto-explicativa, la verdad.

Neil Ernst, SEI 2015

Cuarto y último motivo: porque no sabía que se lo estaba comprando.

Creo que es lo más normal, y suele pasar cuando alguien compra un producto mirando los Cuadrantes que publican los analistas de negocio, o porque nobody ever was fired for buying IBM, o porque las demos de jugar estaban bien, etc. En lugar de hacer una due diligence tecnológica como Dios manda.

¿Qué hace aquí este Monolito?

El esfuerzo e interés por desarrollar aplicaciones desacopladas no es algo nuevo, y forma parte del corpus teórico de la ingeniería del software desde sus inicios. En el caso que nos ocupa en este contexto, que es el eCommerce (algo inherentemente ligado a la Web y en los últimos años al móvil) las arquitecturas en tres capas (presentación, lógica de negocio y datos) y el Patrón Model-View-Controller han sido la forma habitual de construir sistemas con bajo acoplamiento.

No sólo desde el punto de vista de la construcción, ya que al separar de forma conceptual las distintas partes del sistema es más fácil actuar sobre ellas; sino desde el punto de vista de la infraestructura que las soporta, con el objetivo de mejorar el escalado y el rendimiento. Poder empaquetar y desplegar cada una de las capas en servidores diferentes permite al sistema escalar de manera independiente cada capa cuando se producen los picos de acceso al sistema (cuando hay ventas privadas, o campañas como Rebajas, San Valentín, Navidades o el Black Friday) Por eso es bastante habitual ver infraestructuras donde se ha separado la parte de presentación en unos servidores optimizados para servir el front, complementados con un CDN para los estáticos (las imágenes, vídeos, etc), la parte que hace la lógica de operaciones en servidores de aplicación, y otra capa con la base de datos en alta disponibilidad.

Monolito Scrum

El equipo Scrum hace sus dailies frente al Monolito

Sin embargo, dejadme que os diga que la primera referencia a patrón MVC se remonta a finales de los 70. Y la idea de crear una arquitectura en 3 capas para construir aplicaciones cliente / servidor es de mediados de los 90. Así que, ¿a qué nos referimos hoy en día cuando se habla de un Monolito? Porque es lógico suponer que la mayoría de los eCommerce Singulares, que es de lo que va esa serie de posts, se han construido bien sobre plataforma, bien a medida, siguiendo arquitecturas y patrones que desacoplan al menos las capas de presentación-negocio-datos.

Bien. En primer lugar, aunque la tienda como tal esté desarrollada en 3 capas, puede que la capa de lógica de negocio (o back-end) se haya construido como un Monolito. Significaría que es un bloque único que recibe las peticiones de la parte del cliente (web o móvil o por qué no, un botón IoT), hace cierta lógica (como una búsqueda de productos según un criterio,  o añadir un elemento al carrito) y genera la información que se renderizará en la capa de presentación a modo de respuesta. Entendido de esta manera, el servidor puede estar construido de manera modular, con sus elementos desacoplados en paquetes y clases, de forma que tenga su componente de carrito, otro de catálogo, etc. Pero lo cierto es que al final todas importarán las mismas librerías con las mismas dependencias, compartirán el mismo modelo de almacenamiento de datos en sesión, y  la misma política de persistencia.

También el back-end de la aplicación puede considerarse un monolito si se empaqueta como un único artefacto. Podría llegar a desplegarse en varios servidores, lo que le permitiría escalar en caso de aumento de peticiones. Pero es una única unidad lógica; de forma que en caso de ser necesario hacer una modificación, hay que volver a compilar, empaquetar y desplegar toda la parte servidora, haya o no sido actualizada. Y una vez que se empaqueta, la misma versión es la que se despliega (y por tanto se ejecuta) en todos los nodos de la infraestructura. Al hacer el despliegue, aunque sea por nodos, es necesario reiniciarlos. En la medida en que haya un entorno distribuido con alta disponibilidad y persistencia compartida de sesiones, los usuarios podrían no verse afectados; sin embargo, tareas programadas o procesos de sistema (como sincronizaciones de inventario, confirmaciones de pago, o envío de newsletters) que estuvieran ejecutándose, se perderían. Por eso muchas veces hay que hacer las actualizaciones de manera programada, lo que es una barrera para llegar al despliegue continuo.   

Y el artefacto que se despliega en cada nodo, se ejecuta en un mismo entorno, compartiendo la misma configuración y el espacio de memoria y en general, los recursos del nodo. Cuanto más pesado sea, más tiempo tardará en arrancar y mayores recursos necesitará. Por tanto, todos los servicios o end-points del artefacto están replicados por igual en cada nodo y acceden a los mismos recursos del sistema, con independencia de la frecuencia con que se usen para resolver las tareas del sistema. En todos los servidores se ejecutan réplicas idénticas del back-end, capaces de hacer las mismas operaciones de lectura y escritura contra la base de datos; por tanto lo normal es que escalar la capa de negocio conlleve escalar la capa de datos.

Cuando alguna de las partes de tu sistema se ha convertido en un Monolito lo normal es que tengas algunas desventajas, que veremos a continuación.

Cosas malas que pasan cuando tienes un Monolito

Desde el punto de vista del desarrollo, cuando todo el back-end de una plataforma (y en este artículo estamos hablando de un eCommerce Top 100) está construido como un Monolito, se producen unos efectos indeseables que impactan en la productividad y eficiencia del equipo. ¿Por qué?

Porque todo el equipo de desarrollo del back-end trabaja sobre el mismo artefacto. Cuando hay demasiada lógica de negocio en la misma capa, es normal que se rompa la modularidad de los componentes con el paso del tiempo, conforme se van haciendo extensiones del producto, o se corrigen errores. Por ejemplo, añadir un nuevo medio de pago a un eCommerce puede afectar: al módulo desde el que se procesan los pagos, al que renderiza el selector de medios de pago durante el proceso de checkout, al que gestiona el medio de pago favorito en el perfil del usuario (necesario para los one-click-payments), etc. Eventualmente llega un momento en que el sistema es una maraña y es costoso tener una visión global de cómo funcionan las cosas.

Como además el back-end es un único componente que se carga completamente, los entornos de desarrollo son cada vez más costosos de arrancar, se tarda más tiempo en compilar y en ejecutar y depurar en local. Esto hace que cada vez los ordenadores para el desarrollo requieran mayores prestaciones; algo que no siempre es posible conseguir porque puede llegar a  chocar con las políticas de actualización de los departamentos de tecnología, o los responsables de compras. ¿Alguna vez habéis visto a personas cronometrando cuánto tiempo tarda en arrancar el Eclipse, o cuántas horas pierde al día mientras espera en las compilaciones? Yo sí, y es muy lamentable.

Un back-end que acaba siendo un Monolito hace que todos sus componentes y módulos que se despliegan como un mismo artefacto, estén ligados a un lenguaje de programación específico, y a unas determinadas versiones no sólo del framework de desarrollo, sino de las librerías que se importan. Los cambios de versiones son más costosos, porque se hace necesario validar el impacto que puede tener el cambio de librería en todo el sistema como un conjunto (en lugar de en partes concretas donde el cambio puede tener más sentido). Eso por no hablar de cambiar de stack tecnológico. Un proyecto de refactorización de un sistema para ir aliviando la deuda técnica, puede ser una inversión en tiempo y dinero difícil de justificar ante el responsable de asignar recursos económicos a los proyectos.

Monolito Asuán

Antes de levantar este monolito de 36m y 150 toneladas se rompió la build. Por eso se llama El Obelisco Inacabado de Asuán

A la larga, todo esto unido significa que se incrementa la curva de entrada de las nuevas incorporaciones al equipo, con lo que aumenta el tiempo que necesita una persona para hacer trabajo productivo. Cuando el tamaño del equipo de desarrollo alcanza un nivel importante, y estamos hablando de un eCommerce Top 100 (no de la demo de la tienda de mascotas), aumenta el esfuerzo de coordinación de los diferentes subproyectos / extensiones que se van haciendo en paralelo. Esto puede llegar a hacer difícil segregar las responsabilidades de los diferentes equipos, y por tanto su autonomía e independencia; y complicar el modelo de gestión de los diferentes proyectos / equipos. Podemos añadir a esta ecuación que las personas pueden estar distribuidas en diferentes localizaciones, cosa habitual en los tiempos que corren.

Desde el punto de vista del delivery, actualizar un sistema Monolítico requiere recompilar toda la aplicación, volver a empaquetarla y redespeglar. Al ser una sola pieza, hay que parar todo el sistema por completo para hacer la actualización.

Además, si llega el caso en que el sistema tiene que escalar, es necesario hacer que escale todo el monolito al completo; en lugar de aumentar la capacidad de aquella parte del proceso / operación que realmente lo necesita. Lo que lleva a aumentar la capacidad (procesamiento, memoria, almacenamiento) del servidor en el que corre, y podría no ser la estrategia de infraestructura más óptima en términos de inversión.

Finalmente, una vez que empiezan a dar servicio, en caso de que se produzcan errores, el proceso de depurarlos e identificar dónde se está produciendo el error puede llegar a ser complejo debido al acoplamiento. Es cierto que desde hace años (de cuando yo programaba) ya están inventados los IDE de desarrollo que se conectan a un servidor y permiten hacer depuración en tiempo real, y esto ayuda a encontrar los errores. Sin embargo, cuanto mayor sea el acoplamiento, y más pesado el entorno de desarrollo y sus dependencias, más implicaciones puede tener encontrar y depurar un error, corregirlo y validar la solución, por el efecto secundario que pueda tener en otros componentes.

Cuando existe fuerte acoplamiento entre los elementos de la aplicación, lo normal es que no se haya logrado separar operaciones y reutilizar código. De forma que cuando hay que modificar o corregir cualquiera de sus funcionalidades, se requiere primero entender cómo el cambio puede afectar a sus diferentes partes; y lo que es peor, identificar todos los puntos en los que se tendría que replicar la actualización.

¿Entonces?

Esta casuística la comparten centenares de plataformas y sistemas de software; y la extienden a los centenares de miles de sites de comercio electrónico por todo el mundo construidos sobre ellas. Podríamos pensar que tampoco pasa nada, que no van a morir niños de hambre en el Tercer Mundo, ni vamos a prolongar el Cambio Climático (y eso sí que son problemas de verdad).

Monolito Obelix Happy

Pues me siento más ligero sin mi Monolito

Recordemos: estamos hablando de construir un eCommerce Top 100, uno que se espera que sea referente de su sector porque lo va a construir una empresa líder. Si a tu eCommerce le vas a exigir facturar millones de euros al año; operar en decenas de países; recibir miles de peticiones concurrentes de personas de todo el mundo; conocer en tiempo  real el stock de artículos y tallas; y cerrar procesos de compra con seguridad. Y por qué no, conseguir finalizar las transacciones en ese milisegundo que es la diferencia entre comprar o quedarte sin stock.

Hoy en día tiene cierta madurez y solvencia la aproximación tecnológica que permite dividir el back-end de la aplicación en partes más pequeñas, especializadas en hacer una única tarea, cada una con su propia capacidad de desarrollarse, desplegarse y escalar por separado. Con su propia arquitectura, consumiendo los recursos que necesita, y gestionando únicamente aquellos datos sobre los que tiene responsabilidad. Pero antes de hablar sobre cómo materializar este planteamiento en una arquitectura de microservicios, habrá que saber cuáles son los elementos que tiene que tener un eCommerce Top 100. Y eso lo veremos en el siguiente capítulo.

(Continuará…)

(Espero que antes de 6 meses)

Cómo construir un eCommerce Singular. Capítulo 1, El eCommerce Top 100

Introducción

Comienzo aquí una serie de posts sobre cómo construir un eCommerce Singular, candidato a estar en un listado de Top 100, utilizando una arquitectura de microservicios. Son dos de los temas a los que dedico mi atención últimamente en Sngular. En cierta medida es normal: por una parte Sngular es una empresa que lleva construyendo tiendas online prácticamente desde sus orígenes como MediaNet, a mediados de los años 90. Algunos de los proyectos que hemos hecho son www.lolamarket.com , el caso de ModeloNow de Grupo Modelo (ahora https://www.pepedelivery.com/), https://www.cuidadoconelperro.com.mx/ y sus dos millones de fans en Facebook, cuando hicimos Planeo.com del Grupo PRISA, y por encima de todos ellos, el caso de BuyVIP y su posterior adquisición por Amazon. Por otra parte, porque los compañeros del área de Arquitectura llevan ya unos años construyendo soluciones basadas en microservicios. Empezamos en entornos de banca, pero la realidad es que se trata de una aproximación que cada vez tiene más adopción a la hora de construir grandes sistemas distribuidos, que gestionan miles de transacciones al día y que tienen que responder y escalar ante picos de carga.

Total, que me parecía interesante compartir algunas reflexiones. El hilo argumental que voy a seguir se materializa en los siguientes capítulos:

  • ¿Qué es un eCommerce Top 100 y por qué hay que hacerlo a medida? Donde vamos a repasar los diferentes tipos de sites de eCommerce que construimos en Sngular, los criterios de cualificación con los que los clasificamos, y sobre todo, qué es lo que nosotros consideramos un eCommerce Singular. Aprovecharé para compartir algunos datos que me parecen relevantes a la hora de enunciar nuestra definición, y que además, son la clave de la argumentación de los 3 motivos por los que siempre vamos a recomendar hacerlos a medida.
  • El bloque Monolítico. Una de las principales áreas de trabajo y evolución de la disciplina de la Arquitectura de Software es la creación de sistemas desacoplados, que combinen la eficiencia en el consumo de recursos para producir resultados, la capacidad de escalar ante los picos de carga del sistema, y que puedan ser extendidos y mantenidos por un equipo de desarrollo. Desde los años 90 existe el patrón de 3 capas (presentación, negocio y datos) que aplican todos los eCommerce del mundo, pero un back-end puede terminar por convertirse en un Monolito, y eso podría ser una barrera para el crecimiento / rendimiento de un eCommerce Top 100. Por cierto, que hay empresas como Basecamp o Etsy que defienden sus arquitecturas de Monolito Majestuoso; también hablaremos sobre ello en los Apéndices.
  • Los elementos de un eCommerce. Para crear una arquitectura de referencia de microservicios sobre la que construir un eCommerce Singular, hay que tener una idea de los elementos estarán presentes en la tienda online. En este capítulo haremos un benchmarking de sites que servirá posteriormente como base para plantear la arquitectura. Me refiero a aspectos como la gestión de múltiples países, el registro de usuarios, el catálogo, las páginas de producto, las recomendaciones, el proceso de checkout, el pago en one-click, la integración de medios de pago, etc. Para escribir sobre esto intentaré engatusar a Farid Fleifel y Javier Cuervo.
  • Arquitectura de Microservicios de Referencia. Donde se presentará un modelo de arquitectura que contenga los elementos descritos anteriormente, y un planteamiento de muy alto nivel sobre qué tecnologías utilizar para construirlos. Se que muchos pensaréis que qué coño voy a contar sobre esto si la última vez que abrí un Eclipse fue en 2009, pero no os preocupéis porque en este capítulo espero contar con la visión de César Camargo, Eugenio Concepción, Iñaki Reta, Daniel Castilla, y el resto de compañeros del equipo de Arquitectura de Sngular. (Puede que os parezca un truco sucio dejar sus nombres por escrito, pero así es la vida¯\_(ツ)_/¯  )
  • ¿Cómo hacer la transición? En el último capítulo haremos una pequeña revisión de diferentes estrategias para hacer la transición de un sistema a una nueva arquitectura de microservicios, sin pérdida de continuidad del negocio (sin dejar de vender, vamos). Lo que viene siendo el símil de cambiar el motor del avión en pleno vuelo.

En fin, es un reto ambicioso porque me salen unos cuantos posts. Pero bueno, lo mejor es empezar por el principio. Así que vamos a ello. Espero que os parezca interesante 😉

Capítulo 1. ¿Qué es un eCommerce Top 100 y por qué hay que hacerlo a medida?

Estoy en condiciones de afirmar, sin posibilidad de error (incluso con apuesta de pincho de tortilla y caña) que en todas las reuniones en las que he estado donde una o más personas querían crear un modelo de negocio de eCommerce, siempre ha salido la pregunta del millón. Y contra todo pronóstico, la pregunta del millón no es “¿qué tengo que hacer para vender mi primer millón de euros online?”, sino “¿esto se hace con una plataforma o se desarrolla a medida?” La siguiente pregunta es “¿y cuánto va a costar?”.

En Sngular, como somos gente muy práctica y además transparente, estudiamos cada caso y hacemos una recomendación basada en la necesidad, el escenario y en general todas las condiciones de contorno del caso del cliente. Esto siempre gira en torno a las dos Cs Elementales del eCommerce. La primera es la de la Cualificación del tráfico y la segunda la de Conversión. El propósito de cualquier plataforma que se construya debe ser la de convertir tráfico cualificado en ventas de productos de calidad, y eso se consigue a través del diseño de una experiencia de compra construida sobre una plataforma tecnológica. Hay otros elementos del círculo virtuoso del eCommerce, como es la capacidad de hacer la entrega de los productos, y el servicio post venta que se da al cliente. Todos son importantes para lograr el éxito.

Pero lo más importante desde nuestro punto de vista es que una tienda online, es un modelo de negocio de base tecnológica. Es decir, la tecnología es una condición necesaria (pero no suficiente) para el negocio: para que funcione y crezca. Dicho lo cual, en nuestro árbol de decisión, existen cuatro categorías de eCommerce.

En el escalón más básico está el eCommerce MVP (de Minimun Viable Product) que refleja aquellas situaciones donde se está creando un modelo de venta estándar que incluye las 3 Cs Básicas del eCommerce (Catálogo, Carrito y Check-Out), en una compañía 100% online (es decir, no hay venta física), que inicia una etapa exploratoria de la viabilidad de su idea con un catálogo de productos reducido. Aquí nuestra recomendación es concentrarse en validar la idea negocio lo antes posible, con una inversión acotada. Por eso apostamos por plataformas tipo Shopify (un eCommerce as a Service) o WooComerce (que por resumir, es una extensión de WordPress) En un eCommerce MVP el rango de inversión inicial empieza en torno a los 16 o 20K y puede llegar a los 50K sólo en tecnología (es decir, sin contar otras inversiones necesarias como el sourcing o campañas captación de tráfico, etc), y un time to market que no supera las 6 semanas. Es una inversión pequeña, como pequeño es también el control que se tiene sobre la solución. Lo importante en este caso es validar el modelo con una inversión que si no cubre la expectativa no suponga grandes pérdidas; pero que si se demuestra que el modelo de negocio es viable, se pueda tirar a la basura sin gran tristeza, y pasar al siguiente escalón.

Ese sería el de un eCommerce Standard, aquellos casos en los que existe un catálogo con más o menos cierta profundidad, en un modelo de venta que empieza a considerar las 2 Cs Adicionales (Consejos y Comentarios) para incrementar el ticket medio y la fidelización de los usuarios. En este escenario, el promotor no necesita validar la viabilidad de su idea, porque ya se sabe que lo es; y tiene prevista una inversión moderada en un horizonte temporal de medio plazo (1 o 2 años). Nuestra recomendación es ir o bien a una plataforma estándar tipo Magento / Prestashop o construir sobre nuestra plataforma Sngular Billionlabs basada en PHP Laravel. La decisión fundamentalmente depende de las integraciones a realizar, de cómo se espera abordar la omnicanalidad, y en general de hasta qué punto se quiere o necesita construir sobre la plataforma para lograr materializar el site. Cuanto más estándar sea, más fácil es que se pueda construir sobre una plataforma de mercado; sin embargo, la particularidad del modelo, o del diseño, o de las integraciones pueden marcar la diferencia entre construir sobre plataforma de mercado y re-construir una plataforma de mercado. Por lo general, re-construir la plataforma es una mala idea, se pierde la continuidad con futuras versiones, aumenta la complejidad del mantenimiento y la extensión, y se acaba con un bonito Frankenstein. Si en tu horizonte te ves con un Frankenstein, lo mejor es que te plantees un desarrollo a medida desde el principio. En este tipo de eCommerce, la inversión sólo en tecnología puede empezar en el rango de los 60K-80K anuales y llegar a los 100K-120K. En cuanto al time to market, ya varía entre usar plataforma o desarrollo a medida, sin embargo nuestra experiencia nos dice que a partir de la semana 8 ya es posible tener una primera versión lista para empezar a vender online, en un proyecto que con entregas iterativas puede llegar a las 16 semanas.

eCommerce Usage Stats

Estadísticas de plataformas de eCommerce según datos de https://trends.builtwith.com/shop

 

El tercer escenario es el eCommerce Pro, el de empresas en un importante nivel de madurez que apuestan por el online como una fuente de ingresos relevantes dentro de un plan de negocio en varios países. En este caso el nivel de adaptaciones específicas es cada vez mayor, sobre todo con la integración de otros sistemas corporativos. Este tipo de proyectos tienen previstos fuertes inversiones no sólo en tecnología, también en captación de tráfico para el site. El catálogo de productos es relevante, el modelo online incluye todas las Cs del eCommerce habidas y por haber; y otros aspectos como la gestión de inventario (que puede estar distribuido) y logística de entrega (donde puede haber diferentes proveedores) o medios de pago (incluyendo por ejemplo diferentes plataformas para cada país) tienen mayor peso. Hay además una necesidad fuerte de integración de sistemas existentes (propios o de terceros), y el site forma parte de una estrategia omnicanal donde el cliente puede llegar a interactuar con la marca y el producto en tiendas físicas, en el online, en el móvil, etc. En este caso, la recomendación de Sngular es ir con grandes plataformas como Hybris / Oracle ATG / IBM Websphere según lo aficionado que uno sea a dejarse guiar los Gartner y Forrester de turno, o hacer un desarrollo completo a medida.

En general, si la tienda online requiere integrar un elevado número de sistemas legacy para procesar las operaciones; o está concebido como una plataforma en la que acceden diferentes terceros; o el modelo de negocio no encaja al 90% con el estándar de una plataforma, nuestra recomendación es un desarrollo a medida.

En un eCommerce Pro, el rango de inversión empieza en los 120K-160K anuales sólo en tecnología, y puede llegar al millón de euros cuando empezamos a meter licencias e infraestructura. En estos escenarios hay mayor variabilidad en el time to market, si bien es razonable pensar que en el mes 4 puede haber una plataforma bastante parecida al resultado final, sobre que la que se puede seguir iterando ampliando funcionalidades hasta los meses 6-8.

 

 Gartner Magic Quadrant Digital Commerce 2017  Forrester Wave Report for B2C eCommerce, Q1 2017
Gartner Magic Quadrant to Digital Commerce, April 2017 Forrester Wave Report for B2C eCommerce, Q1 2017

eCommerce Singulares según Sngular

Por último tenemos la joya de la corona. Esos que llamamos los eCommerce Singulares. La clase de eCommerce que siempre recomendaremos construir a medida, porque nuestro cliente quiere entrar en el Top 100. Para lograrlo es posible que haya que dar respuesta la creación de un modelo de venta propio, clave para la ventaja competitiva y por tanto, no cubierto por ninguna plataforma estándar. En este caso estamos hablando de inversiones por encima de los 250K sólo en tecnología el primer año, que pueden empezar directamente en los 400K-500K.

 

 DigitalCommerce360 Top500 USA DigitalCommerce360 Top500 Europa

DigitalCommerce360 Internet Retailer Top500 Report (USA y Europa)


Los datos que publica DigitalCommerce360 son muy interesantes, muestran que
el 41% de los Top 100 eCommerce de Estados Unidos desarrollan a medida su tienda online. Este dato sube hasta el 58% si lo filtramos al Top 100 eCommerce en Europa. Amazon, Alibaba o Rakuten, los gigantes del eCommerce mundial, han desarrollado a medida sus plataformas (propias, que luego abren a terceros o incluso permiten que se construya sobre ellas). Si miramos la lista de los principales eCommerce de Estados Unidos, podemos comprobar que todos han desarrollado su propia plataforma de comercio electrónico, y de hecho en algunos casos como Amazon.com o Wal-Mart la han abierto a que otras empresas puedan construir con ellas.

Facturación del Top5 eCommerce US en 2016 (Fuente: WWD)

Facturación del Top5 eCommerce US en 2016 (Fuente: WWD)

El eCommerce Singular siempre hay que hacerlo a medida

Nuestra recomendación para crear un eCommerce Singular es siempre el desarrollo a medida. Para conseguir un eCommerce que entre en el Top 100 tienes que mantener el liderazgo estratégico frente a tu competencia, tener el control sobre tu plataforma, y evitar el vendor lock-in;

  • Liderazgo estratégico. No se puede condicionar en ningún caso la implementación de una estrategia de comercio online a las capacidades o features de una plataforma, y mucho menos al roadmap de evolución que haya decidido un fabricante. Esto es fundamental: ser un eCommerce Top 100 significa innovar, liderar y estar por delante de los competidores. Construir sobre una plataforma implica tener los mismos niveles de libertad y las mismas funcionalidades que el resto de tus competidores que la usan. Crear tu propia plataforma te permite construir tu propio liderazgo.
  • Continuidad del producto. Construir extensiones o adaptaciones sobre una plataforma propietaria no evita una inversión elevada, por la especialización de las personas que tienen certificados los conocimientos para hacer las extensiones o adaptaciones sin que impacten en el rendimiento o escalabilidad. Sobre todo, tampoco garantizan que ante una nueva versión del core de la plataforma las extensiones vayan a seguir funcionando. Tu propia plataforma puede evolucionar y re-evolucionar según tu necesidad.
  • Vendor lock-in. Utilizar tecnología propietaria, es decir, no estándar, siempre tiene asociado el riesgo de convertirse en una relación asimétrica, en la que el proveedor tiene un papel dominante sobre el cliente, llegando incluso a coartar su independencia. El temido vendor lock-in. Construir una plataforma según tus propias especificaciones usando tecnología estándar y abierta te permite crear tu propio equipo de desarrollo in-house, o abrir el desarrollo de forma transparente a un amplio abanico de proveedores.

En general, una plataforma a medida permite tener el control absoluto sobre el modelo de negocio, la experiencia del usuario, la tecnología y su evolución.

Categorías eCommerce Sngular

Las cuatro categorías de eCommerce tal y como las concebimos en Sngular

 

De cualquier manera, supongamos que tienes un eCommerce Top 100 construido sobre una plataforma de terceros, que ha ido evolucionando con integraciones y extensiones. O que es un desarrollo a medida hecho entre 2010 y 2015 (me resultaría difícil pensar que a día de hoy alguien está vendiendo como churros algo en internet con un desarrollo de hace más de 8 años) Puede que esté desplegada en la nube de Amazon AWS o de Microsoft Azure; de cualquier manera, seguramente lo que tienes es, como se dice en el ámbito del software, un Monolito.

Y si estás en el momento de rehacer tu eCommerce, o tienes luz verde para crear un nuevo eCommerce Top 100, lo que deberías evitar es ponerte a construir un Monolito. Pero, ¿qué es eso del Monolito?

(Continuará…)

Cómo crear una Proto-Persona

Este artículo es un adelanto de Sngular Sales Connect, una metodología que sirve para trasladar la estrategia, capacidades y propuesta valor diferencial de una organización a su equipo de desarrollo de negocio y fuerza de ventas

Sales Connect es un proceso que aplica, en una determinada secuencia y en un escenario concreto, ciertas dinámicas de Diseño Centrado en la Persona, que se trabajan por equipos.  Se basa por tanto en el learn by doing, en la compartición y el intercambio, y en el trabajo en equipo. 


 

Dinámica 1 ¿Quién es el Cliente?

Aunque cada persona es única y tiene una situación y un contexto diferente, es cierto que en el mundo de los negocios resulta habitual que aquellos que están en un determinado rol en un mismo tipo de empresa, compartan ciertas responsabilidades, objetivos y necesidades.

Parte del trabajo de los profesionales de Negocio y Venta es conocer a la persona para la que trabajan, y eso se consigue a través de las relaciones. El modelo de la Venta Efectiva está centrado en la persona: al igual que hay Human Centered Design, podríamos decir que hay Human Centered Sales. Estableciendo el paralelismo entonces, si en el diseño centrado en la persona el primer paso es hacer el research de la persona para la que diseñamos; en la venta centrada en la persona lo primero que hay que saber es quién es la persona que tiene una necesidad. Por eso el proceso empieza con la dinámica de Persona. Una Persona es una definición ideal, fiable y realista del arquetipo del ser humano para el que se hace un ejercicio de diseño.

Proto-Personas

Idealmente, el punto de partida debe ser el research que se haya hecho desde las áreas de Marketing sobre el cliente. Es de suponer, que está información se recopila de manera habitual y está disponible para los equipos de Negocio y Ventas.

Existen varios tipos de Personas, según la profundidad del ejercicio y su aplicación en diferentes disciplinas de diseño de productos / servicios o experiencia de usuario. En el ámbito de la metodología Sales Connect (donde el tiempo es acotado y los equipos no están formados por profesionales del research), es suficiente con hacer la dinámica más sencilla, que es la de Proto-Persona. Una Proto-Persona es una versión simplificada de Persona, puesto que se basa en las creencias asumidas por el equipo de diseño, en lugar de en los datos que provienen del research.

Al crear una Proto-Persona se definen:

  • Aspectos demográficos y sociológicos. En este punto planteamos respuestas a preguntas tipo ¿Cómo se llama?, ¿Cuántos años tiene?, ¿Qué ha estudiado? ¿Tiene estudios de post-grado?, ¿Ha vivido en otros países?, ¿Está casado/a? ¿Tiene hijos?, ¿Dónde vive? ¿En el centro de la ciudad? ¿En una urbanización de la periferia?, ¿A qué dedica el tiempo libre? Etc.
  • Comportamientos. Para definir el comportamiento, lo ideal es partir de ejemplos concretos o situaciones reales. Si el equipo de diseño ha interactuado con el prototipo de cliente para el que se está trabajando, la observación del comportamiento es un buen punto de partida. En cualquier caso, un mecanismo interesante es hacer la técnica de los espectros. Consiste en valorar, de forma numérica o cualitativa, y siempre a ser posible no binaria, la adherencia de la persona con un determinado comportamiento relacionado con el ejercicio. Por ejemplo:
    • El aprendizaje
    • El riesgo
    • La tecnología
    • La ambición
    • La inversión
    • La experiencia en su cargo
    • La responsabilidad
    • Las relaciones con otras áreas de su empresa
    • Las relaciones con sus proveedores
    • Las relaciones con sus clientes
  • Necesidades y Objetivos. Se trata de una primera aproximación a las necesidades y objetivos de la Persona, que se trabajarán con más detalle en la dinámica del Mapa de Empatía del paso 2. En este punto basta con intentar empezar a recopilar aquellos aspectos que puedan llegar a estar relacionados con nuestros productos y servicios. La naturaleza específica del entorno en el que se está haciendo el ejercicio Sales Connect determinará cuáles son las preguntas más adecuadas. A modo de ejemplo, o para empezar el ejercicio, se puede tratar de responder a estas cuestiones:
    • ¿Qué habilidades y competencias son las que se espera que tenga en su puesto? ¿Cómo puede conseguirlas o mejorarlas?
    • ¿Qué responsabilidad y objetivos tiene? ¿Cómo espera conseguirlos? ¿Cómo sabe que los ha logrado?
    • ¿Cómo es su carrera profesional? ¿Qué debe hacer para avanzar?
    • ¿Qué procesos ha desarrollado o construido por sí misma esta persona? ¿Cuáles le vienen impuestos?
    • ¿Cuál es la parte más motivadora de su trabajo? ¿Y la más frustrante?
    • ¿Qué actividades son las que ocupan más parte de su tiempo? ¿Cuáles debería dejar de hacer?

De cualquier manera, aunque la Proto-Persona es una versión elemental con un nivel de sesgo importante, este primer paso es un buen punto de partida para el resto del proceso. Al definir a la persona para la que se trabaja (alguien real, concreto, un ser humano al que algún día habrá que llamar por teléfono o hacer una visita), el equipo construirá y concentrará sus esfuerzos sobre alguien tangible y real. Trabajar sobre personas concretas ayuda a aterrizar las soluciones y sus características durante las fases de convergencia. Por eso lo importante es que la Proto-Persona sea precisa (es decir, esté bien definida) y no tanto que sea acertada (es decir, que exista de verdad)

Proto-Persona

Proto-Persona : Ana es la CEO de una empresa Energética

 

Durante la primera dinámica, cada uno de los equipos definirá de manera conjunta cómo es la Proto-Persona del área de trabajo en la que se encuentra. Los integrantes del equipo compartirán la visión que cada uno de ellos tiene del arquetipo de cliente con el que trabajan, alcanzando un consenso común que no tiene por qué ser necesariamente ni la intersección, ni la agregación de todos los modelos. Gracias a la puesta en común de la experiencia personal de cada uno de los integrantes del equipo de diseño, se matiza el sesgo o la falta de datos objetivos del ejercicio.

House D. T. (Design Thinking)

Bien, empecemos por el principio. ¿Qué es el Design Thinking? Es una aproximación a la resolución de problemas. Ah, muy bien. ¿De qué tipo de problemas? Problemas de todo tipo. Nos pensamos que esto sólo vale para crear servicios y productos digitales, pero no. Ah, qué pasa, ¿qué antes no se podía innovar? Por supuesto que sí. ¿Entonces por qué se ha puesto de moda? Por lo mismo que las aproximaciones Lean al ciclo de vida de un producto digital, o el desarrollo ágil a la construcción de software. Porque está orientado al éxito en el mundo de la transformación digital, caracterizado por la incertidumbre, la necesidad de adaptación al cambio y la evolución tecnológica que habilita la disrupción.

Vale. ¿Y qué tiene que ver HOUSE en esto?

House Design Thinking

Manos a la obra (Imagen de Cris HE)

No se si alguna vez habéis visto esa serie. Va de un doctor insoportable que dice todas las impertinencias que se le pasan por la cabeza disfrazándolas de honestidad, pero la gente se lo consiente porque acababa por resolver los casos más difíciles del hospital. Bueno, cuando termines de leer este post podrás decir que el Design Thinking es como un capítulo de HOUSE, sólo que sin un cojo cabrón que te da bastonazos (y sin que muera gente cuando te equivocas)

No es Lupus

Gracias a House descubrimos lo que es el Lupus, ya que era una hipótesis prácticamente en todos los episodios. Bueno, para mí el DT es en cierta medida el proceso de diagnóstico diferencial que hacía el doctor House con su equipo.

Si recordáis en todos los capítulos (casos) se probaban diferentes hipótesis, ninguna era la buena, salvo la que se probaba antes del final del episodio. Cosa normal por otra parte, forma parte del estilo de este tipo de series; en CSI el sospechoso culpable es el último al que interrogan y en Mentes Criminales la chica secuestrada siempre está en la última granja que registran.

Lo primero que tienes que saber sobre DT es que es un proceso para resolver problemas de forma iterativa, lo que significa que después de unas actividades más o menos descritas y consensuadas como corpus del proceso, se llega a una hipótesis. Y en la propia naturaleza del proceso se encuentra materializar esa hipótesis de una forma que permita ponerla a prueba rápidamente, antes de que caduque, y así obtener conclusiones que permitan el refinamiento. Y vuelta a empezar en el proceso.

Por tanto recuerda: nadie espera que soluciones un problema a la primera; ni House ni Horatio han resuelto un caso en su vida a la primera, pero se han hinchado a Emmys.

Los Síntomas no son la Enfermedad

Cuando los niños tienen fiebre, se les puede dar Dalsy para que les baje; pero sólo explorando el oído y viendo la otitis se les puede dar antibiótico, reducir la inflamación, curar y en el proceso, le bajará la fiebre. Pues esto es lo mismo. Aplicar el proceso de DT supone olvidarse de los síntomas del problema; e invertir tiempo en conocer y comprender sus causas, en lugar de paliar sus síntomas.

House Design Thinking

Abre tu mente, Quaid (Imagen de Peter Pham)

Una de las diferencias que aporta el Pensamiento de Diseño a otras metodologías de innovación es que las primeras etapas del proceso, el research se centra en las personas y sus propósitos, para detectar sus pain points o necesidades no detectadas. Es quizá la importancia que tiene la observación de la persona y sus problemas lo que diferencia este proceso, de otros en los que o bien el centro de la innovación es un proceso que se busca mejorar (por lo general para eficientarlo o desintermediarlo) o en los que se trabaja sobre grupos de clientes a partir de agregados estadísticos (impersonales porque se sustentan en la fuerza del número)

Todo el Mundo Miente

Hemos visto que una de las características principales de DT es que se busca el origen del problema en la experiencia / vivencia de la persona (usuario, cliente, empleado, recurso… cuanto antes olvides esas palabras y vuelvas a usar la palabra “persona”, mejor) Por eso,  una de las formas de referirse o definir DT es Human Centered Design. Podría traducirse como Diseño Centrado en la Persona, a mí al menos me gusta más, porque Diseño Centrado en el Humano suena un poco ridículo (no va a ser Diseño Centrado en el Wookie)

Precisamente, una de las frases recurrentes en los capítulos de HOUSE es que todo el mundo miente. El paciente miente. Y parte del trabajo del episodio era descubrir que el niño lleva sordo desde los 7 años pero no lo quería reconocer, que el padre oye voces, o la madre se mete unos tiros cuando nadie mira. A veces los médicos tenían incluso que colarse en casa del paciente para descubrir que tenía moho en el cabecero de la cama, etc.

En general, sabemos menos de nuestros clientes de lo que nos gusta reconocer. Por eso es tan importante para mí el pensamiento crítico, la habilidad de sacar conclusiones a partir de la objetividad evitando el sesgo o el prejuicio. Cada vez que alguien dice “es que los clientes no quieren (pon aquí lo que sea)” deberíamos preguntarle en qué datos se sustenta esa afirmación. Y si alguien dice “mi madre no usaría (pon aquí lo que sea)” hay que invitarle amablemente a dejar el equipo.

El Equipo

Aunque no lo parezca, House trabaja con un equipo de doctores que se involucran tanto en el proceso de descubrimiento del paciente, como de diagnóstico de la enfermedad; y además se reparten los papeles durante la parte de aplicar el tratamiento. Y esto es así porque cada miembro del equipo aporta desde su propia especialidad y experiencia.

De la misma forma, otra de las características del proceso de DT es la creación de equipos multidisciplinares e interdepartamentales. De esta manera, se comparte a lo largo de la organización no sólo la visión del cliente y su necesidad (¿habéis conocido a alguien de Compras a quién le importe el cliente final?) sino la resolución del problema a través de la creación de un producto o servicio. Además, se rompen silos de información y estructuras monolíticas… vamos, todo ventajas.

Deja al Doctor, que sabe lo que hace

En muchos episodios los pacientes cuestionan el conocimiento o capacidad de las personas que les están atendiendo; bueno, en episodios y en la vida real. En general y por sobre-simplificar, un doctor adquiere durante la carrera un conocimiento general de muchos temas y luego se especializa en un área concreta en la que se desarrolla profesionalmente. En el caso de HOUSE, no es sólo la especialidad la que les lleva a entrar al Departamento de Diagnóstico Médico, sino su forma de pensar, abordar problemas y en general, apertura de miras.

House Design Thinking

Vicodin, divino tesoro (Imagen de Nancy L. Stockdale)

Podríamos decir que en el caso del DT la aproximación es equivalente. Quizá el campo de conocimiento o formación en DT no tiene la formalidad ni el reconocimiento de una carrera de Medicina, es más amplio y a la vez difuso (pese a que algunos centros de formación aspiran a erigirse en referentes). Pero igualmente, serán la especialización del profesional en competencias relacionadas con la creatividad y el diseño, junto con su forma de pensar y amplitud de miras las que le llevan a formar parte del equipo de diseño.

Como decía un poco más arriba, hay una serie de prácticas o técnicas que se asocian con el proceso de DT, aunque la verdad es que son comunes a muchas metodologías y disciplinas creativas, tanto del mundo del diseño industrial, la experiencia de usuario, el desarrollo de software o la gestión de la innovación en general. Hay también un cierto consenso es que no es tan importante la formación en el proceso general, como el dominio en el uso de las técnicas concretas que cada equipo emplee durante su proceso creativo.

A veces el Enfermo Empeora

Claro, como en HOUSE el caso tiene que durar lo que dura el episodio, en el proceso se prueban diferentes alternativas hasta dar con la causa (igual que Horatio, por mucho Horatio que sea, interroga y acosa policialmente a siete antes de trincar al malo) (no como Colombo, que siempre sabía quién era el asesino desde el principio, pero ese es otro post) Durante ese proceso iterativo, House y su equipo se enfrentan al fracaso, recogen nuevas hipótesis y vuelven a empezar.

Por eso también podríamos decir que el proceso de DT requiere una predisposición mental al proceso creativo, un orden para dar con la solución, y una importante tolerancia a la frustración para ser capaz de aprender y volver a empezar.

Quizá ese es el motivo por el que en muchas organizaciones la entrada en este proceso se hace a través de pequeños experimentos (como la gaseosa)

House es Hugh Laurie

Por último, no olvidemos que HOUSE es una ficción. Una ficción que además tiene como nombre el del protagonista. Hay una serie de 8 temporadas con su nombre porque House es el dueño absoluto e indiscutible de la resolución del caso, muchas de las veces por una genial ocurrencia de última hora (durante los últimos 10 minutos del capítulo, en el bloque que sigue a la última pausa para los anuncios).  

¿Y el equipo? Los del equipo están ahí como actores secundarios, para aportar equilibrio a la trama o para dinamizar la narración.

Bien, quizá esta sea otra de las lecciones a aprender de la serie. No existe la magia. No existe House. House en realidad es un actor inglés que se llama Hugh Laurie y acabó odiando su personaje y padeciendo secuelas físicas.

No puedes confiar en la ocurrencia genial de última hora. Sólo el Chamán te dirá que el éxito en el proceso de innovación depende del Chamán. En realidad, el éxito de proceso está en manos del equipo.

Operaciones, Innovación y la Guerra de los Mundos

Investigar es meter dinero y sacar conocimiento; innovar es meter conocimiento y sacar dinero (José Luis Vallejo, CEO de s|ngular)

Puede que algunos penséis que está feo citar al jefe de cada cual, pero esta frase que José Luis dijo en uno de los cursos de verano que organizamos en la Universidad Internacional Menéndez Pelayo resume a la perfección mi punto de vista al respecto (entended que quizá pueda estar condicionada porque trabajo en una empresa privada)

Las empresas tienen que innovar para sobrevivir

Bien, esto es algo que me gustaría que se me hubiese ocurrido a mí, pero por desgracia es algo universalmente conocido. Vivimos en un mundo en el que los cambios suceden cada vez más deprisa, principalmente de la mano de la tecnología. Efectivamente, en la última mitad del siglo XX, el avance en capacidad de computación y la conexión ubicua está fomentando cambios radicales en toda clase de industrias. Por ejemplo, a través del efecto de la desintermediación que está destrozando cadenas de suministro tradicionales y dadas por hecho. Como reflexionaba Tom Goodwin en Tech Crunch

  • Uber, la mayor compañía de taxis no tiene ningún coche
  • Airbnb, la empresa que más habitaciones pone a disposición de turistas, no tiene propiedades inmobiliarias
  • Facebook, el mayor proveedor de contenidos, no crea ni produce contenidos
  • Instagram, la empresa de fotografía más valiosa, no vende cámaras
  • Netflix, la mayor cadena de televisión, no tiene cables ni antenas
  • Y Alibaba, el distribuidor que llegó a sobrepasar a Amazon en valoración, no tiene inventario

Recordemos que Netflix arrancó sus operaciones en 1997 y Alibaba.com en 1999. La tecnología habilita la innovación, que a su vez propicia modelos de negocio exponenciales. Por lo general, una compañía de las que tradicionalmente formaban parte de la lista de S&P 500 necesitaban 20 años en conseguir una capitalización del billón (americano) de dólares (americanos). Sin embargo, Oculus, que se fundó en Junio de 2012, fue adquirida por 2 billones (americanos) de dólares (americanos) en marzo de 2014.

Exponential Organizations

¿Velocidad absurda? Señor jamás hemos ido tan deprisa, la nave no la resistirá (Imagen de Yuri Van Geest)

La historia empresarial desde los años 40 se ha basado en el axioma de la Calidad Total: la ventaja competitiva se conseguía a través de la excelencia en los procesos productivos y en el servicio al cliente. Sin embargo, y por injusto que parezca, grandes empresas han sido barridas del mapa cuando sus competidores han roto las reglas tradicionales del juego. Y si todo el mundo estamos viendo estas clase de cosas pasar a nuestro alrededor, ¿por qué muchas empresas y modelos de negocio siguen condenados a extinguirse?

Operaciones vs Innovación ¡FIGHT!

Principalmente, porque estadísticamente la mayoría de las empresas no consiguen combinar la Gestión de las Operaciones y la Gestión de la Innovación. Y esto es básicamente porque el Mundo de la Implementación y el de la Creación son dos mundos diferentes, con escenarios, necesidades, personas y mapas mentales diferentes. Algo muy parecido al tema del hemisferio derecho y el hemisferio izquierdo, solo que aplicado a la empresa.

operacionesinnovacion

En un combate entre Operaciones e Innovación, pierde la Empresa

Podríamos decir que las personas que trabajan en el Mundo de las Operaciones trabajan con “certezas”: sus datos son objetivos, y sus procesos están documentados. Hay reglas. Se puede predecir lo que va a pasar. Si A entonces B. Etc. En general, en el Mundo de Operaciones se invierte (tiempo, esfuerzo y dinero) en hacer cada vez un poco mejor algo que ya se sabe cómo hacer (lo que está muy bien y es muy necesario). Por resumir las características del Mundo de las Operaciones:

  • Visión del corto plazo. Se trabajan para los ingresos del hoy y en las cuentas de resultados del año en curso, por tanto se toman Decisiones Ejecutivas, a partir de la observación o medición y evaluación. Además, el resultado de estas decisiones tienen resultados igualmente medibles en el corto plazo.
  • Procesos conocidos. La forma de trabajar es conocida, por eso está claramente definida, delimitada, documentada y compartida. No sólo eso, sino que seguramente haya sido certificada con alguna norma de Calidad. De esta forma, se conocen los resultados esperados ante determinadas situaciones, existen reglas y se trabaja para evitar los errores.
  • Objetivos definidos. La mezcla de los dos anteriores. Las áreas de Operaciones tienen sus objetivos de crecimiento, facturación, rentabilidad, etc. definidos a principio de año.
  • Equipos consolidados. Por lo general, los departamentos de Operaciones tienen su estructura y composición. Los puestos están definidos y se conocen sus características. En caso de crecimiento, los perfiles profesionales son conocidos por el área de selección.
  • Búsqueda de la eficiencia. El proceso de mejora del área de Operaciones por lo general tiene que ver con hacer los procesos más eficientes, bien porque se reducen los costes o porque se mejorar los resultados. Además, existen métricas claras para medir la productividad, y datos históricos que permiten el análisis.

Sin embargo, el Mundo de la Innovación es completamente diferente: se trabaja con la incertidumbre y la subjetividad, experimentando con nuevas formas de trabajo. Vivir en el Mundo de la Innovación supone:

  • Tener una visión a largo plazo. Se trabaja para buscar los ingresos del mañana. A partir de tendencias, patrones o investigación, las áreas de innovación intentan definir nuevos productos y servicios que signifiquen éxitos comerciales o fuentes de ingresos del mañana. Puede conseguirse o puede que no. Pasa hasta en las mejores familias. A menudo las decisiones se toman en forma de apuesta, con incertidumbre y sin un historial previo de acierto.
  • Procesos por descubrir o definir. Dado que se está trabajando en nuevos productos o servicios, la forma en que se construyen o se prestan todavía no está consolidada ni optimizada. Eso significa que muchas veces el proceso se construye sobre la marcha, como parte de la innovación, o peor aún, como resultado de la misma entendiendo cómo se ha conseguido. Lo importantes que tener procesos por definir supone que no están claros los pasos, ni los entregables, ni las responsabilidades.
  • Objetivos inciertos. Crear un nuevo producto o servicio implica la mayor parte de las veces inventarse también cuáles van a ser sus objetivos, y cómo se van a medir.
  • Equipos incipientes. Quizá uno de los aspectos más complicados del Mundo de la Innovación es la necesidad de romper esquemas de trabajo habituales para crear equipos de trabajo multi-disciplinares y transversales a la organización. Es algo complicado precisamente porque muchas empresas fomentan las unidades o direcciones estancas, y cuando llega el momento de trabajar en equipo en el Mundo de la Innovación surgen los roces, fricciones e ineficiencias.
  • Búsqueda del aprendizaje. Teniendo en cuenta que el error es una parte esencial del aprendizaje. Y que el aprendizaje no es lineal, de la misma forma que la innovación tampoco lo es. La exploración a menudo supone que muchas veces hay que deshacer un camino que parecía prometedor pero que termina por no llevar a ninguna parte. Como se está creando algo nuevo, no hay un histórico de resultados sobre los que hacer análisis.
Guerra de los Mundos

¿Quién invade a quién?

Por desgracia, la división entre ambos mundos no es tan evidente. Más bien al contrario. Cuesta mucho darse cuenta que no se puede aplicar una mentalidad, forma de trabajo y modelos de toma de decisión del Mundo de Operaciones en el Mundo de la Innovación. Tampoco se puede hacer a la inversa.

Las empresas son para el verano

Una forma muy gráfica de representar este planteamiento es la metáfora de la bicicleta: que tiene una rueda delantera desde la que se controla la dirección (Estrategia e Innovación) y unos pedales y una cadena que proporciona tracción a la rueda trasera (las Operaciones)

Hay bicicletas que se adaptan mejor a unos terrenos o entornos que a otros (así existen bicicletas de montaña, de carreras, de contrarreloj…) lo cierto es que hay algunas que no son prácticas y tienden a dejar de usarse:

  • Bicicletas de Equilibrio.La forma de avanzar es costosa, ya que requiere de la capacidad de aguante del niño que va subido encima empujando. Sin pedales ni cadena se puede avanzar, pero nunca se llega demasiado lejos. Hay empresas en las que las áreas de innovación y operaciones no se entienden y por tanto no se comunican. Cada una va por su lado.
  • Velocípedo. Famosas a finales del siglo XIX, este tipo de bicicletas se caracterizaban por tener los pedales directamente en una gran rueda frontal, de manera que la tracción es directa a la rueda. Aunque alcanzaban gran velocidad incluso por calles adoquinadas, eran peligrosas por su peso, equilibrio y esfuerzo necesario. Quedaron obsoletas tras la invención de la cadena y los piñones, que aportaban mayor velocidad a las bicicletas. Este mismo paralelismo ocurre empresas en las que las Operaciones dirigen la Innovación. Pueden llegar a optimizar sus costes y procesos, pero son desbancadas por las innovaciones de su competencia.
  • Monociclo. Para poder desplazarse en monociclo hace falta tener muy buen equilibrio y mucha práctica. Aunque uno pueda desplazarse por la calle, es difícil subirse una cuesta o recorrer largas distancias. Del mismo modo, las empresas donde no hay innovación sobreviven a base de músculo financiero y no suelen llegar muy lejos.
Operaciones vs Innovación

Freak Show! Alive on our Stage!

La realidad es que cada Mundo tiene que tener su espacio: el Mundo de las Operaciones debe ser el sustento del Mundo de la Innovación, y el Mundo de la Innovación a su vez debe ser el que garantice la continuidad del Mundo de las Operaciones, en un entorno cada vez más competitivo y cambiante.

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.

Yo, robot

Aunque se estima que en el mundo vivimos más de 7 billones y medio de personas, en realidad la mayoría no existimos. Al menos en Internet. Queridos amigos, reconoced conmigo que el captcha no es suficiente, vamos a acabar implantando el test de Voight-Kampff para cualquier click, like o submit que se precie (sí, el de Blade Runner) Veamos 3 ejemplos de negocios exitosos que alimentan ecosistemas emprendedores basados en el fraude.

1. El restaurante mejor valorado que no existía

Imagina que estás pasando unas apacibles vacaciones en el paradisíaco entorno del Lago de Garda y no sabes dónde ir a comer. Abres TipAdvisor y buscas los restaurantes mejor valorados de la zona, siguiendo la promesa de la red social de que son las personas como tú, con sus puntuaciones y comentarios, los que hacen los rankings (y no la maldita propaganda, o la inversión en publicidad). La verdad es que te llevarías una decepción, porque irías de cabeza al “Ristorante Scaletta” que no sólo no existía, sino que estaba en lo alto de un monte 😦

Ristorante Scaletta

Ristorante Scaletta, vaya jeta

En efecto, todo era una invención de un diario italiano, que quería demostrar que TripAdvisor no sólo no valida ni comprueba las valoraciones de los usuarios, sino que le daba igual que los locales existiesen. En un mes, este restaurante se convirtió en una referencia de la zona. Puedes leer el experimento aquí (no hace falta italiano nivel Dante, se entiende por el contexto)

Precisamente en Italia, la autoridad Antimonopolio fijó una multa para TripAdvisor por la falsedad de sus reviews, de nada más y nada menos que de 500.000€ Al final, un juez resolvió este verano el caso, admitiendo la apelación de la empresa y desestimando la denuncia. El motivo:

TripAdvisor never asserted that all the opinions were real, even mentioning that verification was impossible and to consider the trend rather than each comment one by one”

TripAdvisor tiene más de 250 millones de reviews. ¿Cuántas de ellas corresponden a personas que han pagado realmente por un servicio? NPI (No Puedo Intuirlo) Recientemente se ha lanzado una campaña en twitter (#noreceiptnoreview), en la que los hosteleros que no pagan por sus reviews (o sus bots amaestrados) quieren concienciar a TripAdvisor de la necesidad de que se verifique que los usuarios realmente están valorando servicios que han consumido. La empresa ya ha comunicado que de momento lo descarta.

Todo esto tiene que ver con que un estudio de la Harvard Business Review concluyó que una, una miserable estrella más en Yelp hacía que el volumen de ingresos de un restaurante independiente subiese entre un 5 y 9%.

Se lo que estás pensando: hagamos un ejército de bots y gestionemos esas reviews a cambio por ejemplo del 30% de aumento de facturación.

2. No te libras de tu cuñao ni en Amazon

Al igual que en TripAdvisor, también Amazon es un nido de cuñaos. Entendiendo como tal el término cariñoso con el que nos referimos a personas que opinan de cosas de las que no saben y sin tener el contexto. Y lo que es peor, a muchos les pagan y hay varias empresas que viven de ello.

¿Por qué? Porque por ejemplo en España 2 de cada 3 consumidores leen las recomendaciones antes de comprar, y en su día, la plataforma de revisión y valoración Reevoo estimó que los productos con más de 50 reviews incrementaban su tasa de conversión en un 4,6% Es más, la propuesta de valor de Reevoo a los retailers es aumentar sus ventas un 18%

fiverr

Hago reviews por cerveza

Algunos datos que pueden interesar:

  • En internet te hacen por 5$ una valoración de 5 estrellas de tus artículos en la tienda de Amazon; por ejemplo en el sitio de micro empleos Fiverr (que por cierto levantó 30 millones de $ en rondas de financiación en 2014). Hay sitios, como BuyAzonReviews que te las venden por 22€, pero ojo, porque son revisiones de calidad
  • Precisamente Amazon acaba de demandar a 1.114 personas que desde Fiverr se ofrecían a escribir valoraciones falsas, alegando que están incumpliendo los términos de servicio. Si alguno tiene interés, puede leerse la demanda porque está subida a scribd. Ya lanzó otro proceso de demanda en abril contra cuatro empresas que ofrecían este servicio.

De hecho, Amazon anunció en junio que empezaría a usar sus modelos de Machine Learning desarrollados a medida para detectar recomendaciones falsas, preocupados por ese ecosistema que surge a su alrededor de gente que se lucra con las reviews falsas, y el impacto que esto tiene en la credibilidad que perciben los clientes. El objetivo del sistema es aprender qué reviews han sido útiles y valiosas para los usuarios, y se aplicará tanto a las estrellas como a los comentarios de texto; dando peso a las valoraciones de usuarios validados, tomando en cuenta las valoraciones de 5 estrellas de productos mediocres, etc.

¿Cuánto puede haber invertido Amazon en sus motores de ML? Ojalá lo supiera. Lo suficiente como para haber llegado a paquetizarlo y ofrecerlo como Machine Learning as a Service.

3. Nadie clickea en tus banners

Aunque algunos expertos de la cosa parece que acaban de darse cuenta, el modelo de pago por impresiones está robotizado que se sepa al menos desde marzo del año 2004.

Por aquél entonces, un señor llamado Michael A. Bradley intentó extorsionar a Google: si no le pagaban 100.000$ abriría masivamente un software de su inversión en el que había trabajado durante 5 años, capaz de generar 3.000$ al mes de ingresos para todos aquellos que quisieran montar modelos de estafa en publicidad. Entre los testimonios de su web, alegres apandadores reconocían haber generado 30.000$ al mes con sólo 10 cuentas de AdSense, con el irrisorio coste de 250$ en concepto de licencia.

Quizá el problema pase de castaño a oscuro cuando son los propios intermediarios del modelo de publicidad online quienes crean los esquemas de fraude. En 2013, The Wall Street Journal publicó que el 54% del tráfico publicitario que redes de anunciantes, brokers y agencias vendieron (y cobraron) entre Mayo de 2012 y Febrero de 2013 no lo vio ningún ser humano.

La Association of National Advertisers (ANA) publicó en Diciembre de 2014 datos demoledores sobre el dinero que se están gastando los anunciantes en conseguir que haya bots que vean sus anuncios. En particular, 6,3 mil millones de $. El estudio, que tuvo en cuenta las campañas online de 36 grandes empresas (como Ford, Nestlé o Pfizer) analizó 3 millones de dominios durante 60 días, contabilizando 5,5 mil millones de visitas. Algunos de los datos:

  • El 11% de las impresiones en display son generadas por bots
  • Lo que se dispara hasta el 23% en el caso de vídeos. Vamos, que si te quieres hacer Youtuber, monta una botnet
  • Por la noche todos los gatos son bots. El 28% del tráfico nocturno lo generan las máquinas
  • Hay dominios en los que el % de bots se sale de la media, relacionados con finanzas (22%), familia (18%) y hogar (16%)
  • En el caso del sourced traffic el % de bots llega hasta un deslumbrante 52%, cuando debería ser una garantía de mayor calidad de la visita

En fin, es un negocio redondo. La siguiente imagen os podrá dar una pista de toda la gente que puede llegar a lucrarse gracias a una sencilla red de bots.

Bots

Chain of fools

Como veis, el único que no sale es el anunciante, o como a muchas personas les gusta decir, “el que paga la fiesta”

4. Arañas contra Bots

Si estás pensando montar una estafa de publicidad en internet, ten en cuenta que los principales esquemas de fraude se simplifican en dos:

  • Creas una red de bots en sólo 15 minuos, te pones a infectar ordenadores y te acercas a algún eslabón de la cadena a vender tráfico. Siempre que alguien considere que puede meterle un markup a tu coste y vea los grandes números, hay mercado seguro.
  • Montas una red de sites donde coloques los anuncios, inviertes en SEO para justificar lo bien posicionado que estás, y sobre esos, generas tu propio tráfico.

Pero esto no es todo vino y rosas, hay gente ahí fuera que te va a intentar cazar. En Febrero de 2014, Google compró spider.io una startup con sede en Londres en la que un equipo de 7 personas llevaban 3 años desarrollando herramientas que detectasen esquemas de click fraud. Aunque los detalles de la operación no son públicos, el movimiento de Google iba encaminado a luchar contra la principal lacra de su negocio de publicidad. Las redes de bots perjudican la credibilidad de todos los actores de la cadena, afectan a los precios, pervierten el modelo y sobre todo, es una estafa para el paganini. Un año después de la compra de Google, el equipo Antifraude está formado por 100 personas. No es de extrañar si tenemos en cuenta que según la consultora Evidon (hoy Ghostery), Google sirvió más de 316 mil millones de impresiones de anuncios en 2013.

Precisamente, en 2013 spider.io desveló la red Chamaleon, una botnet de más de 120.000 equipos infectados que costaba a los anunciantes del orden de 6 milones de dólares al mes gracias a 9 millones de visitas ficticias. Estamos hablando de un CPM de 0,66$ El informe había detectado además que la red estaba entrenada para simular tráfico en 200 servidores diferentes.

Lo interesante, al menos para mí, era el por aquél entonces refinado funcionamiento de la botnet, cuyo primer rastro se remonta a 2012. Porque los ordenadores infectados simulaban comportamientos y patrones de navegación humanos.

bladerunner

Es su cumpleaños y le regalan una cartera de piel

Cada una de las máquinas de la red simulaba sesiones concurrentes en diferentes sitios web, creando peticiones de navegación que haría un ser humano. Por ejemplo, para no despertar sospechas, los bots eran conservadores: hacían click según patrones aleatorios en varias zonas de la página, hacían movimientos del cursor también al azar, mantenían el ratio de click through en los anuncios por debajo del 0,02%, y generaban patrones de movimiento de ratón sobre los banners del 11%.

Detectar el fraude no es sencillo, y muchas veces tiene que ver con la comparación estadística de la navegación y comportamiento de sesiones, zonas en las que se producen los clicks, la detección de operaciones masivas de destrucción de sesiones y creación de las mismas, etc. Aunque también incluye meterse en los foros del mercado negro, donde donde se compra y vende tráfico, y se gestionan rankings de reputación. Una vez que se identifica un patrón de una botnet, se sube a los servidores PowerDrill de Google, capaces de procesar medio trillón de datacells en menos de cinco segundos, de forma que procesan cantidades masivas de tráfico recibido en un site buscando esos patrones.

chamaleon-patterns

El patrón de comportamiento de Chamaleon que detectó spider.io

Cuando se identifican patrones de navegación robóticos, Google echa el freno: deja de pagar al publisher que publicó el anuncio, y no cobra al anunciante.

PS. Bot Data

Teniendo en cuenta que el 61,5% del tráfico de Internet es cosa de bots, a veces me pregunto cuántos data scientist hay por ahí analizando pautas generadas por máquinas.

PPS. Los bots de LinkedIn

Y en LinkedIn ¿también hay bots y cuentas fake?

Pues claro, ¿qué os habéis creído? Tened en cuenta que como dice el título del post, al contrario que en muchas redes sociales, en LinkedIn existimos de verdad. Y desde vuestra lista de contactos podéis exportar una bonita hoja Excel de direcciones de correos validadas de personas validadas.

Oro en paño para los reyes del spam. O las reinas.

 

spam

Solamente di NO

A (Design Thinking) Day at the (Innovation) Palace

Este artículo recoge de forma práctica las etapas del proceso de Design Thinking, a través de la crónica de #FinDesign, el workshop de Design Thinking dinamizado por profesores de la D.School de Stanford que tuvo lugar el 30 de Septiembre, en el que fuera Palacio de los Condes de Guevara y hoy Centro de Innovación de BBVA.

Introducción al Design Thinking

Aunque el proceso de Design Thinking (DT) se ha desarrollado a lo largo de todo el siglo XX, su aplicación al mundo del diseño de productos y servicios se ha popularizado en los últimos 15 años, gracias a la labor de difusión de empresas como IDEO, su enseñanza en el Hasso-Plattner Institute of Design en Standford y Postdam, y las obras de autores como Tim Brown, Nigel Cross o Tom Kelley.

Algunos recursos que a mí me han resultado útiles para empezar a meterse en el tema y que por eso recomiendo:

  • Creative Confidence“, de los hermanos Tom y David Kelley. Un libro interesante para todos aquellos que creen que las personas creativas tienen un don de nacimiento, y están obligadas a llevar camisas estampadas y deportivas de colores. Aún así, merece la pena porque no es un libro de auto-ayuda
  • Change by Design“, de Tim Brown. Otro de los fundadores de IDEO. Repasa el proceso de DT a través de referencias y casos prácticos. Como es del año 2009, algunos casos puede que os parezcan trasnochados, pero es interesante y se lee del tirón
  • The Design of Everyday Things” de Don Norman. Un libro necesario para todos los que vienen del mundo de la ingeniería y piensan que la culpa es de los usuarios que no se leen los manuales
  • Design for Social Impact” El Manifiesto de IDEO para diseñar soluciones que influyen en la sociedad
  • The Field Guide to Human Centered Design” Una guía práctica para poner en práctica el manifiesto anterior, y diseñar soluciones centradas en las personas que tengan impacto en la sociedad

De cualquier manera, la mejor forma de meterse en algo es por la vía práctica. En general, se considera que el proceso sigue cinco etapas, que se recogen en la figura:

design thinking

Las 5 etapas del proceso

Veamos el propósito de los pasos del proceso, en el caso concreto de #FinDesign, y en el equipo que formábamos Sergio Gómez (Mapfre), Pablo Hernando (Repsol), Gabriel Herrero (Bluemove), Vicent Rosso (BlaBlaCar), Gustavo Vinacua (BBVA), Luis Villa (Fjord) y yo.

1. Empatía. “Todo cuanto hay en usted me recuerda a usted, excepto usted”

El proceso de Design Thinking es fundamentalmente Diseño Centrado en la Persona (Human Centered Design) Se basa en el conocimiento de la persona, sus intereses, sus problemas, sus necesidades. Y sobre todo, sus motivaciones. Yo es que soy un poco burro, pero qué queréis que os diga,la mejor manera de saber lo que a una persona le interesa o necesita y sus motivos es preguntar.

Al contrario que en el proceso de Marketing, donde la Persona representa la agregación de un conjunto de usuarios que encajan en un patrón de conducta, en DT nos planteamos conocer a personas concretas y específicas, queremos verlas y hablar con ellas, y a ser posible en su ambiente.

Lo importante en DT es que cuando diseñamos, estamos resolviendo los problemas de otra persona, y por eso tenemos que desarrollar la capacidad de ponernos en su lugar, de saber por qué hacen lo que hacen y por qué necesitan lo que necesitan.

Persona

Atributos, Comportamientos y Necesidades de una Persona

¿Cómo? Durante la fase de Empatía, intenta observar a la persona para la que diseñas en la realización de sus tareas, pero sin condicionar o entorpecer la forma en que las hace. Eso no quita para que sea necesario involucrarse con la persona, conocerla, hablar. Para ello, puede ser buena idea tener en cuenta algunas consideraciones:

  • Super Importante: nunca hables en nombre de la Persona que estás entrevistando. Deja que termine sus propias frases
  • Más Super Importante: no juzgues a la Persona
  • Intenta evitar hablar de generalidades (habitualmente) y busca ejemplos concretos (la última vez que)
  • Fomenta que la persona cuente historias en lugar de hacer preguntas binarias (sí o no). Explora las emociones que pueda manifestar
  • Busca las inconsistencias en las historias. A veces lo que la gente dice no coincide con lo que la gente hace
  • Organízate de forma que tu necesidad de tomar notas no interrumpa la conversación

No importa lo informal que sea la entrevista, necesitas prepararla previamente para poder mantener una conversación más o menos estructurada, al fin y al cabo tu objetivo es descubrir los por qué. Precisamente, hay una técnica de entrevista que es la de los Cinco Porqués (encadena “por qué” cinco veces seguidas para llegar al fondo de la cuestión)

Tan importante como lo que la persona dice es cómo lo dice. Observa el lenguaje corporal, no hace falta ser un experto para saber si una persona se siente cómoda, ilusionada o triste.

Hay muchas formas de definir a un usuario, pero la más habitual es separar Atributos, Comportamientos y Necesidades. Recuerda siempre que puedas ceñirte a hechos que hayas podido contrastar, en general, evita tu sesgo, la generalización y aplica el Pensamiento Crítico.

Después de casi un año dejándome caer por talleres de DT para cotillear si la forma en que lo aplicamos en MediaNet es muy diferente de la del resto, por fin estoy en un evento donde la mecánica pasaba por entrevistar a una persona y apabullarla a preguntas. Gracias Lucía 🙂

2. Definición. “La Parte Contratante de la Primera Parte será considerada la Parte Contratante de la Primera Parte”

Siendo un evento cerrado, BBVA proponía una serie de desafíos iniciales. El que correspondía a mi equipo era “¿Cómo podrían crear los bancos sinergías para ofrecer un portfolio conjunto de productos y servicios?

How might we

¿Cómo podríamos…?

Una forma habitual de empezar a trabajar en la definición del problema es a través del enunciado “How might we help“, partiendo de la información que se obtiene del usuario en el punto anterior (necesidades y motivaciones) y del desafío a resolver. Es una forma positiva e inspiradora de crear el planteamiento, en la que la propia frase encierra la necesidad y la motivación. Una frase del tipo “How might we help” debe servir como catalizador para el proceso de ideación; para ser apropiada debe ser tan abierta que permita un gran abanico de soluciones, pero al tiempo debe ser lo suficientemente precisa para que aporte ciertos límites que ayuden a afinar el tiro. Por ejemplo, “Cómo podríamos ayudar a que una persona consiga llevar la vida que desea cuando siente la presión de mantener los compromisos adquiridos“.

Algunas técnicas interesantes para formular las preguntas “¿Cómo podríamos?” puede ser:

  • Buscar el bien común, o aumentar el beneficio
  • Reducir o minimizar un aspecto negativo
  • Cuestionar certezas que se asumen como ciertas
  • Poner patas arriba el status-quo
  • Explorar conceptos contrarios
  • Crear una analogía con un problema similar en un entorno diferente

Como es normal que surjan muchos planteamientos, una forma de tomar decisiones abiertas, de manera rápida y sin tirar de galones es usar gomets para hacer una ronda de votaciones. Lo mismo que en la guarde xD

3. Ideación. “¡Más Madera! ¡Es la Guerra!”

En la fase de Ideación, el equipo empieza a generar ideas para resolver el problema. Hay muchas formas de hacerlo, aunque en este punto viene bien aplicar el proceso de Synectics para resolución de problemas a través de la ideación (que por cierto, es de los años 50). Básicamente, y a modo de resumen, podemos decir que es un proceso de co-creación en el que:

  • Todas las ideas son buenas, y eso es clave hay que fomentar un ambiente creativo
  • Dejamos que las ideas vivan. No es el momento de criticarlas ni de cuestionarlas, porque entonces coartamos la creatividad. Se que esto es algo muy difícil en España, donde lo primero que hacemos con una idea es machacarla, pero así es la vida.
  • Los galones y las jerarquías se quedan fuera, porque la burocracia nos vuelve grises
  • Todas las personas participan, y sólo hay una conversación al tiempo
  • A veces hay que parar para reformular el marco del problema
  • ¡Nada de trollear! Mantén la concentración en el problema que hay que resolver
  • Deja claro cuándo empieza y cuándo termina el “modo brainstorming”. En general 30 o 45 minutos debería ser suficiente
cocreate

Un proceso de co-creación muy co-creativo

Recomiendo un par de técnicas que ayudan a crear más ideas, todas las que haga falta, cuando el equipo está bloqueado. La primera es la re-escritura de ideas, creando ideas nuevas a partir de otras existentes (bien porque se combinan, extienden o reformulan). O la técnica de cambiar el dominio de solución, por ejemplo, imaginando cómo se resolvería el problema en otro sector (cómo lo haría un arquitecto o un abogado) o llevándolo a un entorno extremo (qué pasaría en un musical de Bollywood o en un espectáculo del circo).

Una vez que se han llenado dos o tres paredes de post-its, aplicamos de nuevo el mecanismo de votación del equipo, a base de gomets. Como se puede ver en la foto, tener a una persona como Luis Villa a mano le da otro aire a las ideas 🙂

Como el proceso tiene que seguir y hay que empezar a pasar de la poesía a las matemáticas, toca elegir las ideas sobre las que se trabajará en la siguiente fase.

Para ello, hay una técnica de selección de ideas que consiste en encuadrarlas en conjuntos: aquellas que son importantes para el usuario por el impacto que pueden tener en sus necesidades; aquellas que son disruptivas y por tanto tienen mayor capacidad de innovación o atracción; y aquellas que pueden escalar y aplicar a grandes conjuntos de personas. Otra forma de agruparlas cambia esta última por la viabilidad desde el punto de vista de las capacidades y procesos de la empresa.

seleccion de ideas

Técnica de selección de ideas Disruptiva / Escalable / Importante

Parte de la gracia de la cuestión consiste en ver cómo refinar o mejorar las propuestas para que se coloquen en el centro del diagrama, en el punto de intersección.

4. Prototipado. “¿A quién va usted a creer, a mí o a sus propios ojos?”

El paso del prototipado es el puente hacia la validación de la solución que se está diseñando. Una de las grandes aportaciones de la cultura Lean / Agile / Startuperismo al mundo del diseño es el concepto de “Fail Fast, Fail Often” a lo que habría que añadir “Fail Cheap” y por eso la etapa de prototipado es clave.

En este punto, a mí me funciona plantear el MVPr (Minimum Viable Prototype) que permite empezar a validar la solución con las personas a las que se dirige, y hacer técnicas de Rapid Prototyping para que no pase demasiado tiempo desde que se concibe el alcance del prototipo hasta que se saca a la calle. Un prototipo, por definición, debe ser una versión sencilla de la solución que permita la interacción o recogida de feedback del usuario, al tiempo que facilita que el equipo de diseño valore, plantee y descarte alternativas.

En el grupo salieron dos ideas para las que crear un prototipo, y Pablo Hernando, Vicent Rosso y yo elegimos LIQUID STATE. Es una vuelta de tuerca a la economía colaborativa, una especie de “Préstame tu Vida” en tiempo real, donde una persona puede elegir un trabajo / estilo de vida en una ciudad, y tener el nivel de gasto e ingresos de la misma (quitando los fees del proveedor del servicio, claro)

Go Liquid

Cualquier guardería tiene los ingredientes para hacer prototipado

En fin, para haberlo hecho en 20 minutos con cartulina, tijeras, pegamento de barra y revistas de moda femenina no está mal. Aunque hicimos un prototipo rápido con POP reconozco que en la vida real soy afortunado, porque para hacer prototipos de los sistemas y aplicaciones que diseño para los clientes de mis clientes cuento con los especialistas de Arquitectura de Información, Diseño de Experiencia de Usuario y Diseño Visual del UX Lab MediaNet.

5. Prueba. “¡Y también dos huevos duros! (Moooc) En lugar de dos, pon tres”

El proceso de prueba pasa por contrastar los prototipos con usuarios reales del producto o servicio que se está diseñando.  Aunque cuando se diseña hay que pensar que se está haciendo lo correcto, cuando se prueba conviene partir de la premisa que nos hemos equivocado. Contrastar la solución con el usuario permite no sólo validar la viabilidad del prototipo, sino descubrir nuevos puntos de vista o necesidades que se verbalizan a través de la confrontación de la necesidad con la solución.

A Day at the Races

Groucho, Chico y Harpo validando a Hi-Hat

Lo ideal es dejar que sea la propia persona la que dirige la interacción con el prototipo, para no condicionar su uso ni sesgar su expectativa. De nuevo se notó el nivel de los organizadores y la profesionalidad del equipo de la D.School.

En #FinDesign tuvimos tiempo para salir a la calle a validar el prototipo. En mi caso, fuimos al Starbucks y tuvimos la ocasión de hablar con desconocidos sobre nuestra idea. Es una experiencia que os recomiendo a todos. Hablar con personas que no conoces de nada, que te dediquen su tiempo y te cuenten lo que piensan de algo tiene un valor incalculable. Y además es divertido.

Los insights que consigues durante el proceso de prueba te permiten afinar en tu solución, comenzando un proceso iterativo. Puesto que efectivamente, comprobar cómo la persona utiliza el prototipo puede dar lugar a nuevas observaciones, nuevas ideas, la necesidad de seguir trabajando en el prototipo, etc.

findesign

De izquierda a derecha, Hannah Lippe, Adam Royalty y Daniel Stringer

En resumen, una gran jornada de colaboración, compartición y creación. No quería dejar de dar las gracias a Hannah Lippe, Adam Royalty y Daniel Stringer del D.School por su cercanía; la enhorabuena a Belén Herreros y el resto de responsables del Centro de Innovación de BBVA por promover y organizar la jornada y por invitarme; y al equipo de facilitadores de Opinno por su ayuda.

Ghosting, la nueva vieja forma de ignorar al Vendedor

Tú no lo sabes, pero es la última vez que hablaréis. Crees que es una despedida más, igual que las anteriores, sin embargo, esta vez va a ser diferente. A partir de mañana no va a contestar al teléfono cuando llames. Y no es que tenga lío, no. No piensa devolver tus llamadas.Tu teléfono seguirá en su agenda, sólo para saber que eres tú quién llama. Tampoco va a contestar tus whatsapps, olvida del doble tick azul, no los va a leer. Tampoco va a contestar tus emails. Vas a dejar de ver sus post en Facebook, y sus fotos en Instagram.

Una persona normal esperaría al menos una explicación. Un motivo. Nada. No te esfuerces, no pierdas el tiempo, y sobre todo, no pierdas la decencia: no existes. Te has convertido en un Fantasma.

Ghosting

Agárrame ese Fantasma

¿Qué es el Ghosting?

El Ghosting es la nueva forma de terminar una relación: convertir a otra persona en un fantasma, alguien que no existe, simplemente ignorándolo. Sin pasar por el penoso y a veces engorroso proceso de dar explicaciones. Por el camino fácil.

Aunque el Ghosting es algo que parece fomentar una sociedad que nos ha dado Tinder, Grindr, Happn, las Adopciones de Tíos y demás, el caso más sonado es el de Sean Penn. Efectivamente, un hombre que tiene 2 Oscars© de la Academia y que estuvo casado con Madonna y con Robin Wright, pero al que Charlize Theron sacó de un plumazo de su vida, haciéndole desaparecer como un fantasma.

Por lo demás, una encuesta de YouGov demostró que el 11% de los encuestados había hecho Ghosting para terminar una relación (un 6% adicional de cachondos decían no estar seguros, osea, que sí) La revista Elle también publicó una encuesta que mostraba que casi el 17% de los hombres y el 24% de las mujeres se habían convertido en fantasmas alguna vez en su vida.

Lo que las encuestas no te dicen es que el 100% de los vendedores hemos sufrido Ghosting alguna vez en la vida.

Cómo saber si eres víctima del Ghosting

Efectivamente, queridos amigos. Todos los que estamos en el mundo de la venta hace años que sabemos que el Ghosting existe. Seguramente lo aprendimos la primera vez que presentamos una propuesta. Es algo que hemos incorporado a nuestro día a día, pero no le habíamos puesto un nombre molón ni hablaban de ello las revistas de moda.

¿Reconoces alguno de estos síntomas?

  1. Parece que no contesta a mis correos, el caso es que no me los rebota
  2. Le dejé un mensaje en el buzón de voz, lo debe tener lleno porque no me devuelve la llamada
  3. Qué mala suerte, es la tercera vez que me cancela la cita
  4. Siempre le llamo cuando está reunido
  5. Le mandé una propuesta pero nunca me contestó, creo que sólo quería mirar precios
  6. No pone su teléfono en la firma de los correos, es que ya me conoce
  7. Me dijo que me invitaría al siguiente concurso, lo que pasa es que para este año ya no tiene presupuesto
  8. Nunca aceptó la invitación a conectar en LinkedIn, porque no usa mucho las redes sociales
  9. Nos cruzamos frente a frente en la cola del café de un congreso, lo que pasa es que no hablamos porque tenía que enviar un email
  10. Le fui a dar la mano, y se la metió en el bolsillo, lo mismo es que le sudan mucho

Bien, ahora que ya sabes que te has convertido en un fantasma, veamos por qué.

Game Over

Los fantasmas atacan al Jefe

No soy yo, eres tú

Ignorar a un vendedor es algo que todos hemos hecho alguna vez en la vida, basta con pensar en la persona que te llama por teléfono a la hora de la siesta para que te cambies de operador; en el que te quiere vender un seguro en un centro comercial; o el que quiere que alivies tus pecados de burgués colaborando con una ONG.

Después de muchos años estudiando al respecto, la conclusión a la que llego de los motivos del rechazo giran en torno a cuatro grandes ejes:

  • No me interesa escuchar lo que me estás contando
  • Tengo cosas más importantes que hacer
  • Eres un cansino y me aburres
  • No quiero establecer una relación contigo

Partiendo de la base de que todos tenemos derecho a no comprar algo, ni a comprar siempre en el mismo sitio, ¿tenemos la obligación de explicar el motivo por el que no compramos? Obviamente no.

Al igual que en el Ghosting de las relaciones de pareja, exponer los motivos del rechazo de una oferta puede convertirse en algo desagradable. Supone dar explicaciones, lo que en general muchas personas prefieren evitar. Incluso puede abrir la puerta a los reproches. “Nos quedamos ayer currando hasta las 2, podríamos habernos ido a casa”

Nadie quiere explicaciones y reproches en la relación con sus proveedores. Por eso a veces lo más fácil es ignorar a una persona a la que con suerte uno no va a volver a ver. Y aunque a nadie le gustaría ser víctima del Ghosting, lo hacemos por dos motivos:

  • Porque asumimos que la otra persona se va a dar por enterada de que no queremos comprarle nada y acabará por desistir
  • porque no vemos directamente la incertidumbre o duda que generamos en el vendedor ni las explicaciones que tiene que dar en su empresa. Al fin y al cabo, cómo haya gestionado las expectativas ante sus responsables es asunto suyo

Lo que pasa es que alguna mente perversa inventó los conceptos de “prospect”, “lead”, “Funnel”, “CRM” y otras aberraciones infames, y por eso cada mes tienes un contacto de alguien que te abrasa para ver qué pasa con lo suyo. Con lo suyo, no con lo tuyo. No te llama para ver cómo estás, qué tal van las cosas, si tienes algún problema, nada nada, te llama para ver si cambia el estado de una oportunidad registrada en su SalesForce de “Negotiation/Review” a “Closed Won”.

El subconsciente de estas personas desea en secreto que les digas que te dejen en paz para poner de una vez la oportunidad como “Closed Lost” y no tener que volver a llamarte, porque les da vergüenza.

Y por eso el primer griego que quiso deshacerse del primer fenicio se inventó El Motivo.

Ghostbusting

Supongo que ya sabes que El Motivo es el precio. “No, es que sois muy caros”. Es la mentira piadosa de la venta.

  • Es universal: la mayoría de las personas creen que las ventas se basan en el precio
  • Es un argumento incontestable: nadie sabe el precio de sus competidores
  • Permite delegar la responsabilidad del rechazo en un tercero sobre el que no se puede influir: como El Área de Compras (si hubiera Polis Malos en el Lado Oscuro trabajarían en el Área de Compras)

Osea, es el camino fácil.

Hay un antes y un después en la venta, y es cuando dejas de escuchar El Motivo. Cuando alguien se toma la molestia de explicarte que no has entendido lo que necesita. O que le estás poniendo unas condiciones que sinceramente, no tiene por qué asumir; que las condiciones las pone él que para eso paga. O porque no se cree que seas capaz de cumplir y no se quiere jugar su dinero, su ascenso o su variable en una lotería. O simplemente, que hay más empresas ahí fuera perdiendo el culo para trabajar con él, que le hacen más caso y se lo toman más en serio. Etc.

Esa clase de explicaciones requieren una relación de confianza entre cliente y vendedor que muy pocas personas cultivan.

Ghostbusters

¿A quién vas a llamar? (Imagen de Birds of North America en Wikimedia Commons)

Sobre todo piensa. ¿Cuándo has dado explicaciones a un vendedor? ¿Cuando te has sentido obligado a hacerlo? Nah. Lo has hecho cuando has creído que era importante explicar tus motivos. Porque estás construyendo una relación con esa persona/empresa. De la misma manera  tu cliente te las dará cuando considere valioso construir una relación contigo.

Sólo te harán Ghosting cuando quieran perderte de vista. En ese caso no insistas y trata de entender por ti mismo los motivos.

PS- A Debbie Harry tampoco la llamaban