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)

Anuncios

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.

9+1 razones por las que trabajo en Sngular

Sngular MIT

Cuando me fui con Dani, Emilio y César a Boston

Una de las actividades a la que más tiempo dedico al día es a expresar de forma emocional, pero a partir de argumentos objetivos, por qué Sngular es la empresa más adecuada para hacer un proyecto digital construido sobre tecnología. Esa explicación debe ser única, específica para cliente con el que hablo y para cada proyecto que presento; y debe ser algo diferente de lo que podría contar cualquier otra empresa de las que están tratando de hacer las cosas que hacemos en Sngular. Hasta que no encuentro esa propuesta de valor diferencial no me quedo tranquilo, noto que algo me falta y no doy por terminada una propuesta.

Hoy en cambio voy a escribir sobre por qué creo que cualquier profesional de tecnología interesado por su carrera debería pasar por Sngular, marcarse unos objetivos a medio plazo, conseguirlos, y a partir de ahí comprobar si tiene recorrido o no.

1) Tenemos cultura de startup. Es normal, aplicamos los principios del agilismo, organizaciones distribuidas, equipos por conocimiento técnicos… y sobre todo, delegamos la toma de decisión porque no creemos en las organizaciones basadas en Comités y en Burocracias. No sólo tenemos cultura de startup, es que hace años montamos una y luego se la vendimos a Amazon. Todos los años invertimos en proyectos de emprendimiento, a veces tiempo, otras dinero, siempre en nuevas ideas que nos ilusionan y que pensamos que tienen futuro.

Soy una persona flexible que se adapta

2) Unidos somos mejores. Tenemos claro que el todo es más que la suma de las partes. Nos gusta trabajar en equipo porque sabemos que de la unión de las capacidades de las personas y de su mezcla se crea valor. Sabemos que en realidad el Llanero Solitario iba con su caballo Silver y con Tonto el Comanche.

Quiero llegar lejos, no quiero llegar rápido

3) Construimos software, no somos una empresa papelera. En Sngular nos dedicamos a crear e implementar la ventaja competitiva de nuestros clientes. No estamos aquí para rellenar documentos, ni queremos sepultar a nadie con papeles. Por cierto, que respetamos profundamente que haya gente que lo haga (siempre que sean responsables con el medio ambiente).

Me gusta construir

4) Acabamos lo que empezamos, nunca dejamos las cosas a medias. No sólo somos una empresa de tecnología, es que siempre terminamos lo que empezamos. Incluso a veces terminamos lo que otros empiezan. Eso significa “compromiso”, una de tantas palabras prostituidas del sector. Sabemos que las cosas se tuercen, incluso sabemos que algunas nacen torcidas. Sinceramente, nunca nos ha preocupado de quién sea la culpa, sabemos que alguien tiene que terminar los proyectos, y esos somos nosotros. Es nuestra forma de entender el “compromiso”.

Nada termina hasta que está terminado

5) Retos técnicos por doquier, porque nos gusta cacharrear. Tenemos la suerte o la desgracia de trabajar con tecnologías de vanguardia. Sí, esas de las que no hay mucha documentación, con tendencia a ser versiones previas o beta, adoptadas por pequeñas comunidades incipientes, donde quizá no haya mucha gente a la vuelta de la esquina para preguntar. Esas tecnologías disruptivas que traen una promesa de eficiencia y productividad que nadie quiere pasar por alto, y que alguien tiene que ser el primero en poner en producción. Como cuando empezamos a trabajar en entornos reales con Amazon AWS en 2009, con Angular y BackboneJS en el año 2012, con Polymer desde el 2014, etc.

Tengo espíritu aventurero y me gusta explorar

6) Reconocimiento y visibilidad de nuestros proyectos. En Sngular hacemos proyectos que impactan en la sociedad.Tiendas online, startups, apps móviles, bancas digitales, aplicaciones corporativas… nuestros proyectos salen a la luz y los usan las personas. Son prácticos porque tienen como objetivo hacer un poquito mejor la vida de la gente que los usa. A veces incluso lo consiguen. Lo importante es que nuestro trabajo no acaba en un cajón, ni cogiendo polvo en una biblioteca.

Por fin podré contarle a mi abuela a qué me dedico

7) Excelentes personas. Antes que profesionales somos personas, y en particular en Sngular además queremos trabajar con grandes personas. Con gente que tiene una mente abierta, que sabe compartir, que cree en el trabajo en equipo, y que deja lo que está haciendo para ayudar a un compañero en apuros. Esa clase de personas que nunca son un obstáculo ni un pero, sino un apoyo. La gente que quieres tener a tu lado cuando llegan los problemas, porque te hace sentir que no estás solo. La verdad es que para mí es una suerte trabajar con tantas personas que el mero hecho de intentar nombrarlas sería sonrojante. También ha sido una suerte haber trabajado con otras muchas personas que luego tomaron otros caminos como las sucias comadrejas que son.

Lo importante son las personas

8) Referentes técnicos. Siempre decimos que no importa la antigüedad o la experiencia, en Sngular esperamos que todo el mundo sea el mejor en su trabajo. Fomentamos una cultura en la que cualquiera puede aportar y donde de todo el mundo se puede aprender. Nos gusta que las personas tengan un referente, es más, nos gusta que las personas puedan convertirse en referente. Es una pena que nuestros compañeros tengan más interés por trabajar, aprender y construir que por conseguir followers; pero aquí se aprende cada día.

Reconozco que tengo mucho que aprender

9) Aspiraciones en el largo plazo. Si llevamos desde el año 95 en tecnología y seguimos creciendo año tras año es porque nunca tomamos decisiones pensando en el corto plazo y en salir del paso. A veces nos toca tomar decisiones difíciles, pero lo hacemos siempre desde la coherencia con nuestros valores, y pensando que en el largo plazo será lo mejor. Y sobre todo, que nos gusta poder mirar a los ojos a las personas y poder cruzarnos con ellas por la calle sin tener que agachar la cabeza.

Quiero construir catedrales, no picar piedras

Seguramente cada uno de las 320 personas que hacen Sngular tendrán sus propios motivos de por qué han elegido trabajar aquí; estos sólo son los míos y responden a mi vivencia personal después de 6 años. Se que habrá gente que lo verá de otra manera, lo cual es respetable y sano. Pero estos son mis 9 motivos, si los recorres verás que el más importante es TU CARRERA. Si crees que son lo suficientemente buenos para ti, echa un vistazo a nuestras oportunidades en Madrid, Oviedo, Badajoz, Dallas, Birmingham o Ciudad de México http://sngular.team/es/jobs

¿Y en tu caso? ¿Qué es lo que hace que todas las mañanas vayas a tu trabajo, y no a otro?

Indiana Jones y el Talento Perdido

Se que muchos de vosotros consideráis incompletos los trabajos de Carl Jung (y followers) sobre arquetipos de personalidad aplicados al mundo laboral. Sobre todo porque no tienen en cuenta modelos de comportamiento tan españoles como son por ejemplo:

  • El Jeta. No hace nada y se aprovecha del sentimiento de responsabilidad de los demás, que no sólo acaban haciendo su trabajo sino que no exponen abiertamente su descarada actitud por no ser unos acusicas. La sensación de impunidad / injusticia dinamita los equipos
  • El Cuñao. Opina categóricamente sobre temas que desconoce, especialmente a toro pasado y siempre dentro de un ámbito de responsabilidad que no es el suyo, consiguiendo tener a todo el mundo encabronado. Paradójicamente, no aplica su doctrina a lo que sí es su ámbito de responsabilidad.
  • El Veleta. Se pasa el el día dando vueltas de un lado a otro, moviéndose atareado de aquí para allá dedicando su tiempo a tareas que le mantienen ocupado, pero que por desgracia no le llevan a ninguna parte. Ni a él, ni al resto de gente a la que arrastra a su alrededor.
  • El Flojeras. Todo le viene grande, nunca puede hacer nada por sí mismo, y siempre necesita ayuda.

Seguramente has identificado al menos a una persona que cumple con alguno de estos perfiles, ¿a que sí? Lo has hecho porque eres capaz de cultivar y mantener relaciones con una red de entre 100 y 150 personas en diferentes ámbitos; y estadísticamente siempre hay alguien así. Cuando conoces lo suficiente a un compañero para ubicarle mentalmente en alguna de estas categorías, puedes tomar decisiones sobre cómo relacionarte con él, cómo hacer que trabaje en el equipo, lograr que no te amargue la vida, etc.

People Analytics decisions

Mítica escena en la que Indiana Jones resuelve el problema del gigante con espadón

También te habrás dado cuenta de que esto no escala.  En general, todas las empresas que tienen en su ventaja competitiva la gestión del talento humano comparten dos necesidades:  identificar talento oculto en la organización, y mantener la relación de la empresa y el trabajador a través de la carrera profesional de la persona.

En empresas pequeñas, donde el contacto es cercano, esto no es problema, sin embargo grandes organizaciones con miles de empleados de diferentes perfiles repartidos por varios países necesitan una gestión diferente. Y para ayudar a conseguirlo, se pueden implantar procesos de People Analytics, como los que usamos en s|ngular internamente e implantamos en clientes que quieren diferenciarse de su competencia por la gestión del talento.

“No me escandaliza nada, soy científico”

Por People Analytics se entiende el conjunto de prácticas de análisis de datos de la propia organización, para extraer conclusiones que permitan ayudar y optimizar su gestión.

Eh, eh, Guardiola, espera… ¿Qué tipo de datos? ¿Te refieres a analizar los correos electrónicos y violar la privacidad de las personas?

No por Dios. Para eso ya está Google. Me refiero a datos como encuestas de desempeño, valoración de empleados y clientes, asignaciones a proyectos,resultados de los proyectos, horas incurridas, ausencias, clientes por los que ha pasado, oficinas en las que ha trabajado, equipos, responsables de esos equipos, habilidades, formación,  y un largo etcétera. Información que se genera en todas las áreas de la organización y que se vuelca en todo tipo de sistemas y soportes para que sestee digitalmente. Toda esa información está ahí, y va siendo hora de darle utilidad.

People Analytics big data

A lo largo de su carrera, el Dr. Jones (padre) acumuló toda clase de información

Aplicar el análisis de estos datos al mundo del Talento y Personas permite definir planes de carrera, identificar a los mejores candidatos en un proceso de selección, descubrir talento fuera de la empresa que interesaría atraer, optimizar el proceso de asignación de personas a tareas, crear planes decapacitación, anticipar causas de abandono, ayudar en la toma de decisión ante promociones o procesos de selección interna, etc.

Conocer a las personas que trabajan en una empresa, sus motivaciones y objetivos, es un éxito en sí mismo. Desde todos los puntos de vista, por ejemplo:

  • Para la Empresa, sobre todo de aquellas que tienen en el talento del equipo su ventaja competitiva.
  • Para el área de Personas, que puede crear planes de carrera profesional, modelos de retribución y compensación personalizados
  • Para los managers, que pueden asignar a las personas proyectos y responsabilidades acordes
  • Y sobre todo, para las personas, que se pueden desarrollar como profesionales (o como setas), según los intereses de cada cual (que de todo tiene que haber)

“Fortuna y gloria, muñeca. Fortuna y gloria”

Volvamos al doctor Jones y a los arquetipos. Partiendo de los trabajos de Jung, la doctora Carol S. Pearson publicó a lo largo de los años 80 y 90 hasta doce modelos arquetípicos: “Inocente”, “Huérfano”, “Guerrero”, “Cuidador”, “Buscador”, “Amante”, “Destructor”, “Creador”, “Dirigente”, “Mago”, “Sabio” y “Bufón”. Para cada uno de ellos, la autora define objetivos y motivaciones, y también sus miedos, la forma de afrontar los problemas, y los perfiles con los que no se entiende.

Se que hay muchos modelos de definición y estudio de perfiles psicológicos, pero el de Jung-Pearson  permite que las personas se identifiquen con Indiana Jones, el Señor Miyagui o Harry el Sucio, así que no hacen falta más excusas para usarlo 🙂 Según este estudio, el perfil del Buscador / Aventurero se caracteriza de la siguiente manera:

  • Al aventurero no le interesa la rutina y la seguridad, más bien siente atracción hacia lo nuevo y lo desconocido. Quiere explorar nuevos caminos por sí mismo, aunque tenga que hacerlo en soledad y aislado del grupo. Como suele oponerse al orden establecido y a la forma tradicional de hacer las cosas, impulsa a que la organización se replantee procesos, procedimientos y formas de resolver problemas.
  • Otro factor motivacional importante es la sensación de autonomía a la hora de resolver el problema. El aventurero necesita saber que está haciendo las cosas a su manera, por sí mismo, es más, quiere sentir que lo hace sin el apoyo del resto, ya que luchar contra condiciones adversas aumenta el valor de su logro.
  • La combinación de “explorar lo desconocido” y “tener autonomía” es la fuente del aprendizaje y descubrimiento interior de las personas con perfil de Seeker / Buscador / Aventurero.

Otros rasgos de personalidad interesantes a destacar son:

  • Búsqueda de la mejora contínua por su carácter perfeccionista
  • Necesidad de potenciar su autonomía, como forma de encontrar su identidad e independencia
  • Por ello, el Aventurero tiene pánico a la rutina, la burocracia y el inmovilismo

Cuando un Aventurero no encuentra desafíos en su trabajo empieza a perder su capacidad de compromiso, cae en el pesimismo y el descontento crónico, siendo cada vez más difícil de motivar, y tiende quedar aislado del resto de la organización. En este círculo vicioso de descontento, que lleva a estar aislado, que aumenta el descontento, suele acabar con el Aventurero buscando nuevos desafíos fuera de la organización.

People Analytics career

Dar clase de arqueología es más aburrido que saquear templos Mayas, dónde va a parar

Bien. ¿Cuántos Aventureros hay en tu organización? ¿Cuántos quieres tener? ¿Sabes quiénes son? ¿Qué están haciendo? ¿Les has asignado la búsqueda del Arca Perdida, o están rellenando formularios? ¿Tienes retos para todos ellos? Esta es la clase de preguntas con las que lidian habitualmente las personas que trabajan en Gestión de Talento, y para resolverlas, pueden aplicar People Analytics. ¿Cómo?

“No son los años, cariño. Es el rodaje”

Os cuento cómo lo hacemos en s|ngular. Para empezar, como si de una película de infecciones víricas se tratase, tenemos definido un vector origen, una muestra cero que es la que usamos de patrón. Una persona que sabemos fehacientemente que tiene un perfil de Aventurero, que consideramos valiosa y que nos gustaría que hubiera más, en este caso nuestro CTO. A partir de su evaluación de desempeño identificamos cuáles son las competencias por las que destaca. Dentro del argumentario de nuestro modelo de competencias, las claves que definen a un perfil Aventurero son:

  • “Proactividad para solucionar y anticipar problemas”. Tiene que ser una persona con interés por recorrer caminos.
  • “Eficacia”. La cualidad de recorrer los caminos adecuados. Estamos en una empresa, no hay que olvidarlo.
  • “Interés por formación.” Deben demostrar su búsqueda constante de aprendizaje, puesto que estas personas deben liderar la adopción de nuevas tecnologías.
  • “Capacidad de aprendizaje técnico.” Una cosa es querer aprender, y otra hacerlo. El aprendizaje técnico va más allá de saber que algo funciona y aplicarlo, hay que entender por qué, cómo, para qué, cuándo, alternativas…
  • “Valoración potencial por el resto de compañeros”, que deben reconocer y respetar su capacidad de liderazgo tecnológico.
People Analytics attributes

¿Para ser Aventurero tienes que tener fobia a las serpientes?

Como ser Aventurero es un rasgo de personalidad, que no está necesariamente ligado al puesto o a la experiencia, el algoritmo de análisis no busca valores absolutos, sino que tiene en cuenta:

  • La aparición de estas habilidades, que tienen que destacar como “top” de la persona. Es decir, no importa que la persona alcance la mayor puntuación absoluta en estas habilidades, sino que para que la persona se manifiesten como destacadas.
  • La correlación entre las habilidades complementarias del perfil. Aunque en nuestra definición del perfil utilizamos como competencias principales las que hemos repasado, existen otras que tienen que estar presentes. En este caso, la “responsabilidad sobre tareas asignadas” y “respuesta ante picos de trabajo”. Esta relación no es algo meramente lógico, tiene que cumplirse en los modelos de análisis matemáticos.
  • La correlación con otras habilidades antagónicas. Por ejemplo, estadísticamente en el modelo de competencias de s|ngular, la “valoración potencial por compañeros” tiene una correlación de factor 0,6 con la competencia de “solidaridad y apoyo a los compañeros”. Sin embargo, en el caso del perfil Aventurero, donde las personas encuentran satisfacción en recorrer el camino por su cuenta, buscamos personas que aún siendo valoradas por sus compañeros, no son especialmente reconocidos por sacarles de los apuros (ese es el papel de otro perfil, el “Cuidador”) Por eso hacemos la agrupación en cluster de personas en los que la correlación valoración – solidaridad esté en los valores bajos de correlación.

Otros elementos que toma en cuenta nuestro modelo de People Analytics, y que se obtienen de otras fuentes de la organización, son por ejemplo:

  • Participación en proyectos que se han considerado innovadores o con un componente de reto tecnológicos. Este es un factor que no es determinante, puesto que precisamente el objetivo del proceso es identificar talento oculto. Esta información sale de nuestra base de datos de dedicaciones, viendo la asignación de una persona a proyectos de determinado tipo.
  • Asignación a las etapas iniciales de los proyectos. Las personas con perfil de aventurero suelen participar en las fases de lanzamiento, puesto que su principal aporte es establecer líneas maestras de solución, pautas, anticipar problemas, etc. Por eso en este perfil buscamos a esas personas que aportan más valor arrancando proyectos, lo que se demuestra porque los responsables de áreas y asignación tiran de ellos durante las etapas iniciales de los proyectos. Esta información se obtiene de la base de datos de dedicaciones, filtrando las asignaciones de personas a proyectos durante al menos en su primer cuarto.
  • Nuestro mapa de competencias, donde identificamos aquellas tecnologías menos frecuentes entre el resto de la plantilla, o tecnologías en diferentes estados de madurez (por ser vanguardistas, o versiones beta, o por su penetración en el mercado). Esta información se obtiene del tesauro técnico que mantiene el equipo de People Operations.
  • Las competencias que la persona publica en LinkedIn, y sus endorsments. De manera que se tenga en cuenta no sólo la visión que la empresa tiene de la persona, sino la que la persona expone públicamente de sí mismo. Esta información es pública.
  • Nivel de implicación en eventos técnicos internos. En el caso del Aventurero, nos interesan personas que proponen y preparan formaciones en nuevas tecnologías y que forman a los que vienen detrás. Esta información se obtiene de la base de datos de formación del equipo de People Operations
  • Nivel de implicación en comunidades. La búsqueda de conocimiento tiene que trascender las fronteras de la organización. Esta información es pública y se obtiene de redes sociales.
  • Presencia en eventos técnicos, en diferentes niveles, como asistente, ponente, etc. Esta información se obtiene del área de Administración en el caso de pago de cuotas de participación, y/o de la base de datos de formación del equipo de People Operations

“Doctor Jones. Sabía que era usted”

Para cada una de estas variables definimos nuestras propias tablas, con unos valores según escalas predefinidas que vamos actualizando y ponderando, de manera automática con los algoritmos de machine learning, y manual, cuando revisamos los resultados. Igualmente, la ponderación que cada uno de estos factores tiene en la fórmula es algo que afinamos periódicamente en nuestro proceso de mejora continua.

People Analytics review

El hábito no hace al monje, ni el látigo al Aventurero

Una vez aplicamos y parametrizamos el algoritmo, obtenemos tres grupos basados en la probabilidad de adherencia de cada persona al perfil, según criterios de coincidencia por encima del 95%, del 90% y del 85%.

A partir de esta información, el equipo de People Operations revisa la validez de los resultados, y desencadena procesos corporativos para entrevistar personalmente a las personas y hacer un seguimiento cercano de las mismas, compartiendo la información con responsables de área y managers para adecuar la carrera profesional y las asignaciones al perfil.

Hay otros perfiles de comportamiento que son especialmente interesantes para s|ngular, que también detectamos aplicando People Analytics. Y también hay otras líneas de actuación de People Analytics que espero tener tiempo para compartir, como son:

  • Medición del clima organizativo y compromiso, a través del cálculo del Net Promoter Score, solo que en lugar de aplicarlo a la lealtad de los clientes, se aplica a la plantilla.
  • Identificación de la características de los empleados que tienen éxito en su desempeño, es decir, qué cualidades tienen aquellas personas que destacan en su puesto de trabajo.
  • Identificación de causas de abandono, de manera que se pueda anticipar aquellas personas que están pensando en su nueva vida antes de que sea demasiado tarde.
  • Descubrimiento de talento externo, contrastando factores de éxito o de interés que pueden extrapolarse de la información pública de personas ajenas a la organización. Por ejemplo, por lo que dicen o hacen, su contenido online, sus contribuciones a repositorios de código fuente, etc.

Pero eso ya es otra historia

Making of SNGULAR810

El 8 de Octubre de 2015 fue un día muy especial. Compañeros, amigos y clientes nos juntamos en el Kinépolis para compartir el nacimiento del grupo SNGULAR, un proyecto empresarial articulado en torno a MediaNet. Para celebrarlo queríamos hacer algo especial y original, algo distinto, pero ¿es posible hacer algo diferente cuando hablamos de eventos de empresa? Sin que se entienda por diferente el catering, azafatas disfrazadas, consolas de videojuegos ni otras atracciones de feria.

IoT (Interest of Things)

Fue un 26 de Agosto, en un viaje de vuelta de Badajoz a Madrid cuando César Camargo, Jose Antonio Gallego, José Luis Vallejo y yo empezamos a fantasear con la idea de hacer un evento que no girase en torno a lo que los organizadores quisieran contar, sino en lo que a la audiencia le interesase escuchar. En hacer el primer evento en el que el público no aceptase ser triturado de aburrimiento en una charla acerca de la misión y los valores de una empresa, su nueva organización, o lo maravillosos que son sus productos. O peor aún, en castigarles con una muermo-charla para sestear como penitencia antes de tomarse los canapés. Queríamos hacer un evento en el que la gente eligiese lo que quería escuchar.

Sngular People

Los 3 Mosqueteros y D’Artagnan (hagan sus apuestas)

¿Pero cómo? Teníamos claro desde el principio alimentar los procesos de análisis de Lenguaje Natural (NLP) de Sngular Meaning, una de las empresas incorporadas al grupo, con un doble objetivo: a partir de los comentarios que los invitados hacen públicamente en las redes sociales, ser capaces de extraer sus aficiones y áreas de interés. Pero también, saber qué personas pueden encajar en un patrón predefinido (los que defienden los derechos de los clientes frente a los abusos de las marcas, los que prueban las nuevas tecnologías, los que se interesan por nuevos modelos de negocio…) Al fin y al cabo conocer al cliente es clave en behavioral targeting y motores de recomendación eso es lo que hacemos en eCommerce.

En un alarde de imaginación, se nos ocurrió utilizar pulseras Xiaomi Mi, integrarlas con una app desarrollada a medida, y regalarlas a los invitados para que así, a través de la personalización, los indicadores luminosos y la vibración respondiesen a los intereses concretos de la persona. Imaginábamos clusterizar a los asistentes por colores, que les indicasen que compartían intereses, creando zonas específicas para que se juntasen en el coktail. Pensábamos que podría ser una forma diferente de fomentar el networking. Llegamos a tener listo un pedido de 600 pulseras con su correspondiente brazalete con la imagen de la marca. ¿Que por qué no lo hicimos? Porque para integrarse con las pulseras hay que usar unas librerías que alguien en sus ratos libres había hecho descompilando y esnifando tramas, sólo funcionaba en Android una de cada tres veces y aunque nos gusta el riesgo, ese día nos la íbamos a jugar delante de mucha gente.

La otra línea argumental que surgió en ese viaje fue la de ofrecer a los invitados una app cargada con todo tipo de datos curiosos que no fuesen de dominio público, pero que reflejasen lo que desde SNGULAR nos llama la atención. Por ejemplo, que las 10 profesiones más demandadas hoy no existían en el año 2000; que ya no hay una correlación entre la valoración de una empresa y  sus activos tangibles; que sólo el 25% de las apps sobreviven a la primera semana en tu teléfono; etc. Ofreciendo esos bocados de información a los invitados, y midiendo la curiosidad que despertaban en ellos, se iba a configurar la agenda del evento.

Sngular Tools

Me alegra que me haga esa pregunta

Porque cada una de estas preguntas y sus respuestas aumentaban los contadores de valoración de una serie de ponencias, con la peculiaridad que no se podía extraer una relación directa entre las píldoras de información y las conferencias o sus ponentes. Ponentes que José Luis había invitado uno a uno.

Efectivamente, al contrario que un modelo openspace donde cualquiera puede proponer un tema y hablar de ello, en #SNGULAR810 pensábamos que era fundamental que los ponentes, participasen o no, fueran referentes de su actividad profesional, tanto por su experiencia como por su trayectoria. Y además, que no fuesen profesionales de la cosa de las saraos, queríamos que sus intervenciones las preparasen para un día tan importante y una audiencia tan especial. Se acabó pasear la misma charla por el circuito de conferencias 🙂

Por eso decíamos que #SNGULAR810 era un evento sin Agenda, nadie sabía de antemano quién iba a hablar ni de qué: los encargados de la comunicación no podían compartir la Agenda con los invitados (que venían a ciegas), los organizadores tampoco sabían a quién tenían que llamar al escenario, y los ponentes, listos para saltar al ruedo, no sabían si serían o no finalmente convocados. La verdad es que fue una apuesta para todos, y desde aquí quiero darle las gracias de corazón a Agustín Vivancos, Juan Fernández-Aceytuno, Enrique Samper, José Antonio Gallego, Carlos Mira, Julián de Cabo, Manuel Desco, Borja Adsuara, José Manuel Cruz, Esteban Moro y Nuria Villanova su disposición a participar.

There’s no business like Show business

Porque queríamos darle el mando al público: al más típico estilo Talent Show, queríamos que el público, a través de sus votaciones en tiempo real, optase no sólo por elegir a los ponentes, sino por darle más tiempo a su intervención, o abrir el turno de preguntas. Al final, debido al formato del evento, decidimos convertirlo en una opción para que los ponentes consiguieran un 20% de tiempo adicional para desarrollar su tema. (Por cierto, que nadie me dejó añadir el botón “Me Aburre” para que a partir de un umbral, se abriera un foso de escorpiones bajo los pies del ponente, pero todo llegará 😉

Al final, gestionar la relación entre la audiencia y el evento supuso convertir al smartphone en un mando a distancia.

Sngular App

El primer mando a distancia que hace selfies

Así, mientras el equipo de Marketing se encargaba de los preparativos del evento, buscar el espacio, la logística, etc, en SNGULAR formamos un grupo de trabajo multidisciplinar para construir todas las herramientas del evento:

  • El equipo de experiencia de usuario y diseño de MediaNet, que hizo la propuesta de interacción y diseño visual de las diferentes fichas
  • El equipo de Front-end development de MediaNet construyó las interfaces web del evento, en paralelo al equipo de desarrollo móvil de Trecone que desarrolló las apps nativas
  • El equipo de software Labs de MediaNet creó la infraestructura del back-end y los servicios de integración de la web y las apps
  • El equipo de Sngular Meaning aplicó sus motores de NLP a los streams de twitter (tanto antes como durante el evento)

Por último, se creó una web que permitía gestionar el panel de control, eligiendo cuál de las viñetas de backchannel se mostraba en pantalla. Porque el backchannel del evento se materializó en 6 de fichas que permitían en tiempo real:

  1. Seguir los intereses de la audiencia: según las respuestas a sus preguntas, lo que permitía conocer los temas que más curiosidad despertaban entre el público
  2. Controlar la parrilla de ponentes: a medida que las respuestas de la audiencia configuran el orden de participación se iba haciendo un ranking para elegir los 6 ponentes que saldrían al escenario
  3. Mostrar el seguimiento del evento en las redes sociales, compartiendo con el público la actividad y los comentarios del hashtag #sngular810 en twitter
  4. Conocer los términos más relevantes que se estaban comentando, a través del análisis de los tweets y extrayendo conceptos según su nivel de relevancia
  5. Identificar de entre los asistentes, aquellas personas que tienen mayor influencia en las redes sociales, no sólo por el impacto de sus tweets ni por el número de followers, más bien por su alineación con los términos relevantes
  6. Y finalmente, conocer el nivel de satisfacción de los asistentes con las charlas y su sentimiento general a través de sus opiniones. Aquí el término “bullshit” que tanto entusiasmo despertó en la charla de Jose Antonio hizo daño a los marcadores de felicidad (añadámoslo al backlog)

El resultado, visto en una de las pantallas del Kinépolis, no deja de ser espectacular

Sngular Event Tools

En directo impresiona más

The Show Must Go On

Activar y desactivar las votaciones en el móvil, sincronizar los ponentes en escena, ayudar a la realización del evento con los pasos a las diferentes viñetas… la verdad es que todo el entramado de aplicaciones, pantallas, servidores y servicios que montamos en torno a #SNGULAR810 requirió de la dedicación a lo largo de todo el evento de un equipo de profesionales que, como si de la tripulación del Enterprise se tratase, estaban a los mandos de la nave para que no le faltase nada a Evaristo Nogales, el Maestro de Ceremonias.

Sngular Engine Room

The (mad) men behind the curtain

En resumen, un despliegue de ingenio, diseño y tecnología, pero también de esfuerzo y compromiso, puesto al servicio de nuestros invitados. Para conocerles mejor, entender lo que les interesa y crear una experiencia a su media. A mí tampoco me resulta tan raro; al fin y al cabo, es a lo que me dedico, antes desde MediaNet y ahora desde SNGULAR. Supongo que a los que organizan eventos simplemente llenando huecos en un track les parecerá transgresor o una pérdida de tiempo (total, mientras haya cerveza y queso esto se acaba llenando) En fin, ese no es nuestro estilo.

Muchas gracias a todo el equipo que hizo posible esa idea peregrina que se nos ocurrió un miércoles de agosto volviendo de Badajoz: Pablo, Dani, Virginia, Nassim, Rocío, Emilio, Carlos, Raúl, Joaquín, Rubén, Jon, Paulino y Oleksandr #respect