• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

transformación digital

Transformación digital: Foundations Model

La explosión del agilismo de los últimos años se debe, en gran medida, a los procesos de transformación que han arrancado en organizaciones de todo tipo en la última década. Pero, ¿todos tenemos claro qué se busca y qué piezas la componen?

En Diciembre de 2019 Jero y yo visitamos a un posible cliente que quería transformarse. Este cliente es una empresa internacional, grande y potente. Para poder dejarla en el anonimato, no puedo decir a qué se dedica, porque reina en su sector de una manera abrumadora desde hace años.

Nos llamaron por que una empresa nueva, pequeña, a la que no prestaban mucha atención, estaba empezando a robarles cuota de mercado. En los últimos 6 meses, esta pequeña startup, había sido capaz de poner en el mercado un producto disruptivo, aprender del comportamiento de sus usuarios, tirar el producto a la basura y rehacer uno nuevo con otro nombre que incorporaba todo lo aprendido. Este nuevo producto estaba funcionando muy bien y robándole clientes.

En esos 6 meses, los directivos de la empresa que nos llamó, aún no habían sido capaces de juntarse y ver cómo podrían competir. ¿Os suena esta historia?

Esto me recordó al Chaos Report 2018. Si no conoces el Chaos Report, es un reporte anual generado por Standish Group. Tienen una base de datos con miles de proyectos y siguen su evolución. Proyectos de todo tipo: grandes, pequeños, medianos, ágiles, no ágiles, en diferentes localizaciones. Hacen seguimiento de estos proyectos y luego nos proporcionan los factores de éxito. Nos mastican datos como el porcentaje de éxito de los proyectos ágiles y los no ágiles, o cómo influyen en el éxito del proyecto las soft skills o las hard skills del equipo. Son informes realmente interesantes y, si no recuerdo mal, tienen un precio alrededor de los 300$.

El informe de 2018 comenzaba con la “Teoría de la latencia en la toma de decisiones” (decision latency theory) donde argumentaban que el factor que más influía en el éxito de proyectos (o productos) era la capacidad que existía en la organización a la hora de tomar decisiones respecto de este producto.

El agilismo nació para poder hacer frente a la creación de productos complejos a través de la inspección y adaptación. Evidentemente, si tu tiempo de respuesta a un suceso inesperado es muy alto, tu capacidad de adaptación es bajísima. Por ello Agile se basa en equipos auto-organizados, en roles de negocio empoderados que pueden tomar decisiones, en desarrolladores que tienen control de todo el flujo del software, desde la creación hasta el deployment. 

¿Es todo agilidad?

Cuando surgió el término transformación digital era para hacer referencia a todos esos cambios que empresas grandes y tradicionales estaban realizando para poder competir con las nuevas empresas nativas digitales. 

Empresas que aún tienen sótanos llenos de archivadores con datos en papel, intentando subir su nivel de competitividad para luchar con empresas que surgieron directamente con lago de datos, tecnologías big data, data scientists y arquitecturas escalables en la nube.

La digitalización de la humanidad cambió por completo el paradigma empresarial. Antes, el pez grande se comía (o compraba) al pez chico. Ahora, el pez rápido se come al pez lento. Esta transformación es profunda, difícil y engloba tecnología, negocio, cultura, perfiles, management, métricas, productividades o gestión de presupuestos.

¿Qué es transformarse?

Cuando desde una organización nos decían “nos queremos transformar, queremos que nos ayudéis” desembocaba en una conversación larga sobre qué era lo que querían, que significaba para ellos la transformación, que esperaban, qué métricas buscaban mejorar, qué iniciativas habían pensado y qué era en lo que podíamos ayudarles y en qué no.

Recuerdo una empresa que visitamos en 2018 por primera vez. Querían empezar su proceso de transformación implantando Scrum directamente. Su tiempo de entrega mínimo era de 5 meses. Tenían mucha deuda técnica, un stack tecnológico muy primitivo y técnicos que no habían tenido tiempo para innovar ni ponerse al día con nuevas prácticas. Les aconsejamos que primero pusieran el foco en bajar ese tiempo de entrega y les pusimos en contacto con un partner nuestro especializado en crear flujos de integración continua bajo tecnología de Microsoft, que es lo que ellos usaban. Y una vez hecho, podríamos seguir trabajando.

Transformación Digital: Foundation Model

Para poder tener todas estas conversaciones sobre transformación necesitábamos un entendimiento común sobre qué es la transformación digital y qué partes la componen. Desarrollamos un modelo basado en nuestra experiencia. A mi me gusta llamarlo “Foundation Model” porque habla sobre los pilares de una transformación digital

Como nosotros entendemos la transformación digital, ésta tiene tres pilares y una base que sustenta todo:

  • Transformación de negocio: Ahora tenemos mucha información sobre los hábitos de nuestros usuarios y ellos quieren productos personalizados e inmediatos. Hay que buscar modelos de negocio que exploten esta nueva relación.
  • Transformación tecnológica: Entender todos los datos que tenemos y ser capaces de tener ciclos de entrega reducidos requiere de DevOps, big data, nube…
  • Agile: Al incluir nuevos modelos de negocio y nuevas tecnologías hemos introducido una gran incertidumbre dentro de nuestra organización. Tener procesos ligeros basados en equipos de trabajo con alta capacidad de respuesta y foco en entregar alto valor a nuestros usuarios es clave.
  • Cultura: Por mucho que cambiemos nuestras tecnologías o nuestros procesos, si los comportamientos dentro de la empresa sigue buscando crear reinos de taifas, nadie comprometido con los resultados de la empresa o un sistema que sigue alejando a los que crean los productos del usuario final, nada se sustentará.

Hemos creado un paper donde explicamos este modelo de transformación digital de forma más extensa y cómo lo usamos con nuestros clientes. Puedes descargártelo de forma totalmente gratuita aquí.

Conclusión

Este modelo surge simplemente para facilitarnos las conversaciones con nuestros clientes. Su intención es crear un entendimiento común sobre qué es una transformación digital, qué partes tiene, qué necesitan ellos, qué podemos ofrecerle nosotros y qué no.

Es totalmente abierto y está en construcción. Siéntete libre de usarlo si crees que te puede servir, o de modificarlo y ampliarlo si así te es más útil. 

Me encantaría que me dieras feedback. ¿Qué opinas? Puedes dejarme un comentario en este post o tirarme un tweet.

El estado de Agile en 2020

Hace más de 10 años estuve trabajando en un proyecto financiado con fondos europeos llamado Tratamiento 2.0. El objetivo era definir un marco para la obtención de información para la toma de decisiones médicas y la verificación automatizada de estas decisiones.

Me llevó unas cinco semanas definir ese marco teórico utilizando una metodología desarrollada por la Universidad de Amsterdam y hacerla cumplir con lo que se buscaba, que era una especie de UML para las decisiones médicas.

Ese proyecto se enmarcaba dentro de lo que posteriormente sería Horizonte 2020, un programa de la Unión Europea para el desarrollo de actividades de investigación científico-técnicas. Lamentablemente, mi trabajo nunca llegó a usarse.

Por aquel entonces 2020 era una quimera. Un puerto gris. Algo que quedaba lejano en el tiempo. Y sin embargo, hemos llegado.

La transformación del sector

Durante estos últimos años, el sector de la tecnología en España ha cambiado radicalmente.

Aunque quizás parezca lejano, hasta bien entrado el 2016 seguía existiendo un techo de cristal para las carreras técnicas (Programadores, Arquitectos de Software) que requería pasar a un puesto de gestión para poder ver incrementado tu salario.

En 2013 me mudé a Londres y apliqué a 20 ofertas para desarrollador un Lunes por la noche. Al día siguiente tenía 15 llamadas perdidas y mensajes en el buzón de voz. Contrastaba con la sequía de interés por parte de las empresas en España. En las consultoras andaluzas, el sueldo era de 850€ netos.

Fue una de las primeras cosas que me sorprendió cuando me fui de España en los peores años de la crisis.

Por otro lado, encontrar compañeros de 50 años que arrastraban una carrera técnica sin intención de cambiar, porque sus expectativas estaban más que satisfechas. 

Al principio se me hizo extraño. Nunca había trabajado en equipos técnicos con gente que estaba más cerca de la jubilación que del comienzo de su carrera profesional. Fue interesante descubrir como la madurez personal puede aportar mucho más que los conocimientos técnicos a los proyectos de Software.

Durante ese tiempo tuve la oportunidad de conocer en profundidad proyectos como el del Government Digital Services del gobierno británico, en el que introdujimos principios DevOps para garantizar la calidad de la arquitectura, la testeabilidad y reducir los ciclos de vida del desarrollo y la producción. Hablé de ello en la Conferencia Agile Spain de 2014.

El concepto de transformación digital también llegó tarde a España. Trabajando en la transformación digital de CapOne UK en 2014, vine unos días a España y descubrí a través de una búsqueda rápida en Google que nadie hablaba del tema. Fue BBVA en 2015 la que se embarcó en un proyecto de transformación que todavía dura.

En 2017, los recruiters invadieron el mercado después de haber pasado por Centroeuropa. Se destapó el pastel. A pesar del esfuerzo de muchas empresas para mantener unos salarios contenidos, se hizo patente que no había tanto talento técnico como demanda.

Durante esta década han surgido multitud de pequeñas compañías que se han especializado en el apoyo a determinados aspecto del proceso de transformación. También las grandes se han lanzado con los dos pies a intentar llevarse un trozo del pastel.

Los casos de éxito y de fracaso

Hay pocos casos de éxito a gran escala pero multitud de ellos a pequeña escala. De hecho, hay muchas startups y pequeñas compañías que no existirían de no llevar la Agilidad de Negocio en su ADN.

El motivo para que las grandes todavía no puedan presumir de casos de éxito rotundo es sencillo. La cultura de una compañía de décadas y decenas de miles de empleados no se puede cambiar en uno, dos o cinco años. Probablemente requiere jubilar a una generación de personas para dejar paso a las nuevas ideas.

Muchas personas siguen viendo Agile como algo perteneciente a tecnología. Y a tecnología como algo separado del negocio. Incluso peor: Abrazan Agile como un fin en si mismo cuando en realidad es un medio para conseguir un fin. Organizaciones más competitivas, innovadoras y aptas para sobrevivir.

Por supuesto, el crecimiento de la demanda de Scrum Masters, Product Owners y Agile Coaches no ha hecho sino atraer personas externas al sector que han buscado la mejor manera de incorporarse a puestos bien pagados en compañías que se preocupan de sus empleados. Tardará un tiempo y llevará una criba, pero muchos de ellos han llegado para quedarse.

Tal y como dice un buen amigo y conocida figura del desarrollo de Software: “¿Y cual es el problema? Yo empecé a hacer Software en el 2000 tras pasar un curso de tres semanas en una desaparecida consultora después de suspender las oposiciones a profesor de filosofía”

Conforme arrancamos 2020, Agile no es una palabra desconocida para la mayoría de las organizaciones. Quizás no todos entienden de la misma manera lo que es, pero ya no es desconocido.

Agile no es un puerto gris. Es un puerto que hace tiempo superamos.

Ahora el trabajo es más difícil, ya que supone ir alineando, descubriendo y acompañando organizaciones en descubrir como usar esa amalgama de cosas inconexas para obtener un resultado tangible en su cuenta de resultados.

Hace cuatro años publiqué un artículo en LinkedIn que tuvo cierto éxito: 9 Easy Mistakes to Avoid during your Agile Journey. Uno de los puntos a evitar era “No despedir gente“, en el que hacía una clasificación rápida del tipo de reacciones que la gente tiene ante estos procesos de cambio: Aceptarlas, Irse o lucharlas desde una falsa aparicencia de aceptación.

El problema son los terceros. Tienen una evidente falta de Skin in the game, cuidan mucho su exposición pública, no ponen su nombre junto a lo que dicen y utilizan a otros para sus fines publicitarios.

En el libro Skin in the Game, Nassim Nicholas Taleb explora las asimetrías cotidianas en las que no nos fijamos en lo que la gente dice, sino en como se están arriesgando para defender desde El Mundo Real™ esas ideas.

Los falsos ídolos

No quiero terminar de escribir este artículo sin hablar de las certificaciones: los falsos ídolos.

Al parecer, existe una creencia generalizada en el mercado Agile que las certificaciones son una especie de sistema mágico que te habilita para hacer cualquier tipo de transformación mágicamente.

No lo son.

Las validaciones profesionales existen desde hace muchos siglos como complemento a una experiencia profesional que es insustituible. Habitualmente son una manera de establecer un reto claro en el objetivo es mejorar el conocimiento para luego llevarlo a una realidad. Proporcionan una base que permite comparar, aprender y descartar en función de una variable más. No la única.

Aquí hay dos falacias a explorar.

La primera es que hay grandes profesionales que no ostentan ninguna certificación. Sin embargo, no ostentarla no te hace por defecto un gran profesional.

La segunda es que sirven como muñeco de paja para golpear con el argumento de que sólo sirven para obtener un título y que la formación en torno a ellas es solamente una preparación -un peaje- para ganar más, aunque no tengas ni idea.

Es un problema de calidad de la fruta que compramos.

Hace un tiempo escribí sobre la teoría del mercado de los limones, una metáfora para ilustrar el problema que supone poner a competir un producto de buena calidad con uno de mala calidad. La solución en este entorno es disminuir la asimetría de la información -que el consumidor esté mejor informado- para hacer evidente la diferencia de calidad de los productos existentes en el mercado.

Estas falacias son fácilmente rebatibles.

Agile como moda

Para aquellos que piensen que esto es una moda, les recomiendo que hagan una comparativa de búsqueda entre Agile y Televisión 3D, para descubrir qué es una moda y qué es un movimiento que poco a poco está transformando el mundo.

Agile en 2020 está más vivo que nunca.

Hay muchos retos por delante: Profesionalizar cada vez más el sector, conseguir que los programadores dejen de estar enamorados de su código y empiecen a enamorarse del valor que su código crea y convencer a muchos responsables de toma de decisiones que las bolas mágicas están pasadas de moda.

Por supuesto hay quien seguirá vendiendo Scrum o Kanban como la solución mágica a los problemas de las organizaciones, pero no lo son. Aportan la estructura necesaria para poder afrontar esos problemas, pero no los resuelven.

Esto significa contar con gente técnicamente preparada y darles el espacio que necesitan para poder empezar a aportar, eliminando capas de gestión que están ahí para dar una falsa apariencia de control sobre el Caos.

¿Qué es la transformación digital?

No importa si llevas tiempo en este sector de la Tecnología o si estás acercandote por primera vez. La transformación digital es un hecho. Todo el mundo habla de ella.

Todas las organizaciones están invirtiendo en su estrategia digital, empleando miles de profesionales para ello. Si preguntáramos a una selección de estos miles ¿Qué es la transformación digital? posiblemente obtendríamos respuestas muy dispares.

La irrupción de la Informática

No hace tanto tiempo -el suficiente para que los más jóvenes no se acuerden- llegaron los primeros ordenadores a las empresas en España.

Un antiguo presidente de una empresa cotizada del IBEX me contaba que hicieron una gran inversión en la compra de equipos informáticos allá por 1987 o 1988 sólamente para darse cuenta que no había nadie en la fábrica que supiera usarlos.

En no pocas ocasiones, las organizaciones se subieron al carro de la informática más por moda que por necesidad. Sin embargo, la moda fue calando y en pocos años no había una empresa en la que todos los empleados no tuvieran un ordenador para realizar su trabajo diario.

En 1987 mi padre aquirió un Amstrad 1512 con 512Kb de memoria y sin disco duro que dió 11 años de servicio y en el que por primera vez tuve la oportunidad de enfrentarme a retos con LOGO y QBasic -además de darme la oportunidad de probar todos los juegos de la época-. Aprender fundamentos de programación fue algo que cambiaría mi vida para siempre.

Pertenezco a la ultima generación de la historia que sabe que es vivir sin internet.

Los departamentos de informática empezaron a crecer al mismo tiempo que decrecían muchos trabajos manuales, como el de los contables, los administrativos o las secretarias de dirección. Un nuevo mundo se abría.

Por primera vez éramos capaces de analizar datos rapidísimamente, escribir textos fácilmente editables o hacer consultas a bases de datos de clientes estando a cientos de kilómetros de distancia. Había comenzado una nueva era, una en la cual el conocimiento era más valioso para la gran mayoría de la fuerza laboral que la capacidad manual de hacer determinadas tareas.

Negocio e IT se separan

El departamento de informática, estratégicamente situado lejos de la vista de los transeuntes -lleno de monitores y teclados viejos- recibía cada vez más peticiones para hacer cosas más y más complejas.

Ya no se trataba de informatizar pedidos, sino de automatizar todo el proceso de pedido. Más tarde el de producción. Y todo mientras se actualizaban los balances y las cuentas de resultados sin necesidad de un contable.

Durante los 90, a informática se le dió un nuevo nombre: Tecnologías de la Información y la Comunicación (TIC). El trabajo ya no consistía en el mantenimiento de equipos o la entrada de datos, sino que también incluía redes, servidores y programación. Eso provocó un importante crecimiento en el personal dedicado a esta labor.

El departamento se mudó a otra planta, o incluso a otro edificio y se contrataron directores y ejecutivos que se aseguraran que todas las peticiones salían adelante. Los informáticos eran gente extraña, siempre ponían problemas a todo.

Al abrigo de este crecimiento emergió un nuevo tipo de compañía de servicios, la que proporcionaba apoyo técnico a organizaciones que ya existían para momentos puntuales o proyectos específicos de alta carga.

La premisa era la siguiente: No es necesario que contrates a todos estos ingenieros ya que una vez que completes tu proyecto no los vas a necesitar. Nosotros te proporcionamos el know-how, la fuerza laboral que necesitas y tu sigues en control de tu negocio. Era una propuesta de valor sólida.

OPEX y CAPEX

Al comienzo del nuevo milenio y con la burbuja punto com a punto de ser dinamitada, las compañías empezaron a mirar a sus balances buscando maneras de mejorar sus beneficios sin necesidad de reducir su competitividad.

Una nueva hornada de ejecutivos que habían crecido en los 70 y estudiado MBAs tomaba el mando para dar un nuevo rumbo a estas organizaciones. Lo primero que hicieron fue preguntar y profesores cómo hacerlo. Había una forma de incrementar los beneficios mágicamente.

Si tenemos una empresa y compramos un vehículo, no podemos deducir al gasto de la compra inmediatamente. Dado que le vamos a dar uso durante varios años, las normas contables exigen que cada año nos deduzcamos un poco de ese gasto, hasta completar la vida útil del mismo.

Cuando una compañía desarrolla una aplicación que le va a permitir gestionar sus clientes durante varios años, sigue el mismo procedimiento. Así que la inversión en los abultados departamentos de informática ni siquiera podía ser deducida como gasto, sino que había que amortizarlo en varios años, lo cual lastraba el beneficio. Este tipo de inversiones se denominan CAPEX.

¿Que ocurre si en lugar de comprar un vehículo pagamos un alquiler todos los meses por el uso de uno? Pues que esa operación pasa de ser inversión a ser gasto y entonces si que lo podemos deducir de forma inmediata. Lo que se conoce como OPEX. ¿Podríamos aplicar la misma lógica a nuestras aplicaciones contratando a una empresa externa que se encargara de nuestro personal y asi mejorar nuestros beneficios? Sí, podemos. Las empresas decidieron externalizar su personal a empresas de servicios y contrataron a esas mismas empresas para continuar desarrollando sus productos. Había nacido el outsourcing.

De aquellos polvos, estos lodos

Esta decisión -aparentemente- no tendría por qué tener un impacto más allá de incrementar el porcentaje de beneficios de una organización. Las empresas conservaron y contrataron Project Managers, especialistas dedicados a supervisar y asegurar que el gasto en TIC estaba bien gestionado. Y durante un tiempo, fue bien.

Sin embargo, tuvo un efecto colateral. Las organizaciones dejaron de conocer las entrañas de sus sistemas y aplicaciones, ya que los que tenían ese conocimiento ahora trabajaban para otros.

La capacidad de negociar se veía mermada. ¿Cómo puedes pedirle algo a quien tiene el verdadero control de tu negocio?

Esta situación provocó que durante años se dedicara poca inversión a sistemas ya obsoletos y que muchas organizaciones fueran totalmente inconscientes del impacto que sus sistemas y aplicaciones tenían en la gestión del ciclo de vida de sus clientes. A pesar de ello, como el mercado estaba dominado por grandes monopolios y oligopolios, no era necesario ser más competitivo que el resto sino al menos tan competitivo como el resto. Y todos hacían lo mismo.

Llegó la crisis

En España y latinoamérica, la crisis financiera del año 2008 impactó con fuerza. La situación histórica de los paises de habla hispana provocó que les fuera mucho más difícil sobreponerse a la crisis que a los anglosajones.

En España no se habló sólidamente del final de la crisis hasta el año 2016. Durante todo ese tiempo, todas las empresas habían recortado a causa de -o usando como excusa- la crisis.

Cuando los presupuestos empezaron a fluir de nuevo hacia el interior de la organización el panorama había cambiado. Los osos despertaban de su letargo para darse cuenta que el bosque que antes conocían ya no les era familiar. Mientras ellos dormían, una generación nueva -los millenials- había tomado el relevo y estaba dándoles a sus clientes lo que necesitaban más rápido, mejor y a una fracción del coste.

Los sistemas obsoletos, en los que se había ahorrado al máximo durante años, hacían que cualquier cambio tomara meses. Mientras, cualquier startup era capaz de implementar esos cambios en minutos. El problema no era tecnológico -o al menos, no sólamente tecnológico-.

Darle la vuelta a esta situación suponía darle la vuelta a todo: Personas, trabajo y tecnología. Si lo pensamos detenidamente, es darle la vuelta a organizaciones que lo que mejor saben hacer es hacer que su manera de trabajar prevalezca y expulsar a todo aquel que no esté contento con el statu quo.

El reto es aceptar que la tecnología ha dejado de ser un centro de coste o algo que mejora nuestra propuesta de valor para abrazar el hecho de que la tecnología es nuestra propuesta de valor. Todo lo que hemos hecho hasta ahora, lo que nos diferenciaba, ya no vale.

Ha llegado la hora de que todas las organizaciones sean tecnológicas.

No hay bancos, hay tecnológicas con licencia bancaria. No hay electricas, hay tecnológicas que operan en el mercado energético. No hay hoteleras, hay tecnológicas que operan en el mercado turístico.

Esto es la transformación digital.

Ciencia de Datos, Producto y Agilidad

Muchas son las empresas que se están amparando en la agilidad para sobrevivir ante un mercado y contexto social cada vez más dinámico y donde la disrupción de tecnologías, nuevos modelos de negocio y gestión del talento han hecho que antiguas mentalidades y formas de trabajo no sean las más adecuadas para estos tiempos.

La agilidad nos lleva a trabajar colaborativamente con equipos multidisciplinares y esto no excluye a disciplinas como la ciencia de datos, que además entendemos estratégica a todos los niveles de una organización. Cada vez son más las empresas que apuestan por obtener valor de sus activos en forma de datos, utilizando el talento de los científicos de datos para impactar considerablemente en el negocio.

Sin embargo, la (relativa) novedad de la ciencia de datos y la cada vez más habitual aplicación de las metodologías ágiles no siempre tienen una convivencia fácil en el contexto de creación de productos.

El objetivo de este artículo es buscar un punto de encuentro entre responsables de producto y los equipos involucrados en la creación de producto, asumiendo que la involucración de la disciplina de datos cada vez va a ser más habitual.

Nos gustaría Identificar y explicar los momentos donde esta disciplina es un factor diferencial en la creación de productos y cómo se podría organizar de forma ágil.

Cada responsable de producto tiene su propia manera de crear productos, basada normalmente en frameworks, métodos, gurús o experiencia (Lean Startup, Design Thinking, Scrum, SAFe, Less, etc) o una combinación de todo lo anterior.

Para evitar que nuestra conversación se focalice en frameworks o métodos, vamos a suponer que independientemente del framework que utilice, un equipo involucrado en la creación de un producto pasaría por ciertos “planos”, que representamos en la siguiente figura.

  • Identificación de oportunidades: Registro de oportunidades que pueden venir  de cualquier miembro o grupo de trabajo de la empresa.
  • Entendimiento de la oportunidad: Entendemos el problema a solucionar o la necesidad a cubrir junto con el potencial impacto de negocio.
  • Ideación de soluciones: Identificamos las posibles soluciones para solventar los problemas y las necesidades.
  • Implementación de soluciones: Desarrollamos y entregamos los incrementos de producto a nuestros beneficiarios.
  • Feedback contínuo: Comúnmente hablamos de feedback en relación al impacto y el valor esperado de la solución pero podemos pensar en el feedback como planos transversales a los anteriores, unos más orientados a la forma de trabajo y otros relativos al valor entregado.

Supuestamente a medida que avanzamos desde ideación hasta feedback, vamos disminuyendo nuestro nivel de incertidumbre (de ahí la forma de funnel). Además, la madurez del producto con respecto a su ciclo de vida influye a la hora de organizar el trabajo de creación de dicho producto.

A continuación vamos a recorrer cada plano explicándolo con más detalle:

Plano Identificación de Oportunidades

Asumimos que este plano representa el espacio donde todas las ideas u oportunidades son merecedoras de consideración. Dichas oportunidades pueden haberse originado en workshops de ideación, discovery, design thinking, resultados de una investigación con usuarios, estudios de mercado, análisis de la competencia, ideas de cualquier grupo de trabajo o miembro de un equipo que participe en la creación del producto, refinamientos, revisiones, etc.

Todas estas potenciales oportunidades de mejora o evolución del producto son recogidas de forma que puedan pasar a otros planos, normalmente a lo que llamamos Entendimiento donde articulamos dichas oportunidades (lo explicamos en el siguiente apartado)

En esta fase, el papel de la disciplina de datos y en particular la del científico de datos no se diferencia de la de otros roles, excepto porque las ideas podrían venir de un proceso relativo a la ciencia de datos, como por ejemplo el uso de nuevas fuentes de datos externas o internas, los avances técnicos en algoritmos o la identificación de ciclos de adquisición y realimentación de datos.

Uso de nuevas fuentes de datos (externas o internas)

En muchos productos uno de los diferenciadores puede ser el uso de datos. En este sentido identificar fuentes de datos diferenciales y poder valorar su utilidad en etapas tempranas del proyecto es clave para la viabilidad de las ideas generadas. Por ejemplo, podemos tener la idea de que la información en portales públicos de compra venta de pisos podría ser utilizada para mejorar  la valoración del precio de una vivienda, que hasta ahora era generada basada en datos internos.

Avances técnicos en algoritmos

Algo similar ocurre con la disponibilidad de nuevas herramientas o algoritmos para el tratamiento de datos. En ocasiones, el acceso a un nuevo algoritmo puede hacer viable, técnica o económicamente, una idea. Los avances en algoritmos de Deep Learning aplicados a Visión Artificial han permitido rebajar el número de ejemplos necesarios para clasificar imágenes abriendo la puerta a nuevas aplicaciones. Por ejemplo, gracias a estos avances decidir si una imagen proporcionada contiene un coche es ahora mucho más sencillo y preciso.

Identificación de ciclos de adquisición y realimentación de datos

Otra tipo de aportación desde el equipo de datos consiste en identificar cuáles serían los mecanismos para obtener los datos deseables para nuestro producto y definir una estrategia para su adquisición. Esta estrategia, que DJ Patil define como Data Jiujitsu, ha sido ampliamente utilizada en el caso de las redes sociales como LinkedIn o Facebook para soportar su modelo de negocio.

Cabe destacar que el feedback de los resultados generados en otros planos (Entendimiento, Ideación, Ejecución, etc. explicado en apartados posteriores) podría ser una de las fuentes más interesantes de las que se puede nutrir el plano de Identificación.

Plano Entendimiento

En este plano articulamos la oportunidad y, por lo tanto, la hipótesis que tenemos con respecto al beneficio que nos reportaría llevarla a cabo, tanto a nivel de negocio como para nuestros clientes o usuarios. Además, en este plano podemos empezar a perfilar una visión o a alinearnos con una ya existente.

Como parte de ese refinamiento, el equipo de datos puede acometer tareas como:

Análisis exploratorio de datos para validar idea

Como parte del entendimiento de una idea, el análisis de los datos del mercado nos va a ayudar a definir mejor la oportunidad (público objetivo, segmentación, modelo de negocio, etc) y a acotar el trabajo a realizar en el resto de planos.

Identificar problemas e implicaciones éticas en el uso de datos

En esta etapa es necesario profundizar en las implicaciones de usar las fuentes de datos que se hayan identificado  y la forma en la que se van a usar. En este caso hay que tener en cuenta tanto aspectos legales, de privacidad y éticos. Es el momento de identificar posibles sesgos en los datos y considerar si el producto agravaría esos sesgos.

También si es capaz de satisfacer a todos los usuarios objetivo, o por el contrario se requieren mecanismos o acciones especiales para que la solución elegida sea inclusiva. Por ejemplo, en aplicaciones que incluyen reconocimiento de voz se ha encontrado que la baja representación de ejemplos femeninos o de voces no nativas suele implicar un peor calidad en el reconocimiento para estos colectivos.  

Viabilidad y análisis crítico de los datos disponibles

Es labor del equipo de datos, además del uso responsable de los mismos, velar por la utilidad práctica de dichos datos y así como de los correspondientes algoritmos. Aunque en la etapa de ideación es necesario mantener una mentalidad abierta para identificar datos que supongan una ventaja competitiva, en esta etapa es el momento de mirar los datos desde un punto de vista más crítico. Los sesgos en la recolección de datos, además de tener implicaciones éticas, pueden invalidar o limitar su utilidad en términos analíticos. Otro problema frecuente es que no se disponga de la profundidad histórica necesaria o no se recojan los datos con la frecuencia o la resolución necesaria.

Por ejemplo, un dataset puede registrar la fecha en la que sucede un evento pero en cambio, para ser útil en un  nuevo contexto se requiere el timestamp con información de hora, minuto y segundo. Identificar este tipo de necesidades y problemas, así como corregirlos para que se disponga del histórico necesario también es responsabilidad de la disciplina de datos.

Plano Ideación de Soluciones

Este es el nivel donde pensamos en las diferentes soluciones para la creación del producto, así como todo lo necesario como para poder empezar a experimentar y aprender con algo tangible (a algunos les sonará el concepto de MVP).

El objetivo es definir las características del producto y en el caso específico de que requieran funcionalidades basadas en el uso y explotación de datos, abordar cómo se podrían construir.

A grandes rasgos las aportaciones que se pueden hacer desde el equipo de datos para contribuir a la solución se agrupan en los siguientes  grandes bloques:

  • Análisis Exploratorio de Datos: Se trata en este caso de responder preguntas de negocio, por ejemplo, mediante los datos de uso del producto. Estos análisis pueden ayudar a definir una estrategia de producto, escoger una solución o priorizar el problema en el que enfocarse.
  • Visualización y Resumen de Datos: Muchos productos basados en datos incluyen alguna forma de visualización de los propios datos generados por sus usuarios, por ejemplo un gadget destinado a medir nuestra actividad física Es labor del equipo de datos buscar una visualización eficaz y adecuada.
  • Predicción Es la capacidad para inferir el valor de una o varias variables de interés para nuestra aplicación  Puede tratarse, entre otras, de la categoría de un objeto (imagen), el valor numérico de una cantidad medible (el precio de un vuelo) o las películas en las que puede estar interesado un usuario, como en el caso de un recomendador.
  • Diseño de ciclos de realimentación de datos: Cualquier funcionalidad basada en datos tiende a obtener mejores resultados si dispone de más datos, así que parte de la labor del equipo de datos es definir mecanismos que permitan recogerlos y transformarlos en mejores predicciones o visualizaciones de mayor exactitud.
  • Otras funcionalidades: La disciplina de datos puede proporcionar otras soluciones basadas en datos como la optimización o la simulación, ambas relacionadas con los puntos anteriores.

Como ejemplo, pensemos en una funcionalidad familiar para muchos de nosotros: organizar las fotografías de nuestro dispositivo móvil según las personas que aparecen.Si tratamos de asociar las aportaciones al diseño que puede aportar un científico de datos:

  • En primer lugar, puede ser necesario clasificar qué fotografías tienen personas y cuáles no, que claramente es un problema de predicción.
  • Del mismo modo, agrupar qué fotografías son de la misma persona aunque puede ser abordado de diferentes formas como clustering, clasificación o ranking, es en general, otro ejemplo de problema de predicción.
  • Un tercer punto es cómo mostrar los grupos de fotografías que se podría clasificar como un problema de visualización de datos. Si bien podemos usar heurísticos sencillos (primero los grupos más numerosos o los que tienen alguna foto más reciente), también podríamos pensar en otros  más complejos (primero las personas que aparecen en más selfies) que a su vez podría requerir más problemas de predicción.
  • Además, podríamos facilitar que los usuarios pudiesen hacer sus propios grupos o quitar, poner o mover una foto mal clasificada. Si capturamos este tipo de acciones, podríamos usarlas para mejorar los modelos de predicción anteriores, que serían un buen ejemplo de la creación de un ciclo de realimentación de datos.

Para cada funcionalidad donde la ciencia de datos contribuye, hay que considerar la participación del resto de disciplinas (UX, visual design, backend, frontend, servicios, etc) y pensar en ¿qué impacto tiene para nuestros beneficiarios y/o negocio el hecho de ofrecer dicha funcionalidad? En este caso, podemos expresarlo como hipótesis de beneficio.

Por ejemplo, si incluimos la funcionalidad de ver fotos organizadas por personas, aumentará un 20% el tiempo que pasan los usuarios en la aplicación y crecerán los usuarios que suscriban un plan superior partiendo del journey “ver sus fotos organizadas”. Como consecuencia de esta funcionalidad esperamos aumenta nuestro beneficios un 5%. Es en este caso, el que el equipo de científicos de datos también puede colaborar definiendo los KPIs de negocio, definiendo el experimento científico y facilitando la obtención de conclusiones.  Del mismo modo, mediante por ejemplo la realización de test A/B, podemos validar los resultados obtenidos con la entrega de un incremento de producto.

Plano Implementación

Este es el plano donde generamos un incremento de producto de forma que entregamos valor al cliente o beneficiario. Aquí el científico de datos tiene la oportunidad de contribuir en el impacto esperado con dicho incremento, “exprimiendo” lo trabajado en todos los planos anteriores y de forma conjunta con el resto del equipo, para así entregarlo a los correspondientes beneficiarios o clientes finales.

Se asume que gran parte del trabajo en entendimiento del negocio y en la decisión del enfoque análitico se ha llevado a cabo en los planos etapas previas de entendimiento e ideación. Para la disciplina de datos este plano abarca desde el trabajo técnico de la  ingesta de datos, la validación de estos mismos, exploración, construcción del modelo predictivo (o de una visualización) hasta la posterior validación de sus resultados y en el mejor de los casos el despliegue de la funcionalidad y la infraestructura adecuada. Dejamos aparte  la medición de los resultados del proyecto, y por tanto la obtención de feedback, como parte los niveles transversales.

Construcción interaccionando con otras disciplinas

Muchas veces existen complicaciones al compatibilizar el ciclo de desarrollo tradicional de la disciplina  de datos con las iteraciones llevadas a cabo por el resto del equipo. Suponemos que el equipo en su conjunto es capaz de entregar un incremento de producto por ellos mismos, pero  las dependencias y la burocracia son típicas complicaciones que entorpecen el flujo de valor. De hecho, son habituales no sólo para científicos de datos si no para cualquier equipo ágil en general. En muchos casos la solución está más relacionada con la organización y estilos de liderazgo. Aunque esta es una discusión muy interesante, no la abordamos directamente aunque sí podemos comentar una serie de comportamientos que obstaculizan la inclusión de un científico de datos en un equipo ágil.   Se trata del mismo concepto pero abordado desde dos perspectivas diferentes, una desde el responsable de producto y la otra desde el científico de datos:

  • El responsable de producto piensa que todos los miembros del equipo tienen que contribuir en cada iteración con un incremento de funcionalidad y no tanto en un incremento de valor, no entendiendo que la ciencia de datos conlleva cierta parte de experimentación (incluso investigación) con niveles bajos de predictibilidad: Esta preocupación se hace más latente cuando un equipo no trabaja de manera multidisciplinar y colaborativamente para conseguir un objetivo, sino que se distribuyen el trabajo por disciplina o tecnología. La peor consecuencia de esta forma de trabajo es la imposibilidad de entregar valor con un flujo continuo, haciendo necesaria la integración (en algún punto futuro) de las diferentes partes implementadas a lo largo de los anteriores sprints, creando un estilo de trabajo waterfall. Por lo tanto, es importante entender que el científico de datos podría tener como resultado final de una iteración, un aprendizaje o algo que no se incluya directamente en el incremento de producto. Pero son estos experimentos los que nos llevan iterativamente a conseguir algo que finalmente sí contribuya en el incremento de producto (normalmente de manera muy significativa).
  • El científico de datos trabaja en una caja negra que se integra con el resto de funcionalidad cuando tiene un rendimiento determinado: Entendemos que las iteraciones deberían de ser incrementales, pero del producto y no solo de la parte de datos. Hay que entender que es el equipo el que tiene como objetivo entregar un incremento de producto que aporte valor en cada iteración, y no partes específicas  del equipo o individuos concretos. Como consecuencia, los ciclos de inspección y adaptación son del producto, donde el valor aportado por un incremento depende de todas las disciplinas aunque alguna sea más estratégica que otras. Por ejemplo, por muy brillante que sea un algoritmo, no va a tener el impacto esperado si UX o el visual designer no lo hace deseable o usable para el usuario, o de igual forma, las personas de operaciones no han conseguido la disponibilidad que el usuario espera.

Cadencia, Timebox, Avance Iterativo e Incremental

Creemos que merece la pena comentar un tema bastante habitual cuando científicos de datos pertenecen a un equipo ágil que itera con un timebox típico de por ejemplo 2 semanas.

Al final de la iteración se espera un incremento de valor, este incremento puede tener diferente naturaleza, aunque al final muchos entiendan o simplifiquen este valor a beneficio financiero, que ya sea de forma directa o indirecta.

La naturaleza del valor aportado en esta fase puede tener un potencial de predictibilidad diferente, de forma que ciertos trabajos sean más de research con un nivel de predictibilidad bajo y otros más de ejecución con alto nivel de predictibilidad. Normalmente está relacionado con los planos explicados con anterioridad, donde por ejemplo la predicción es complicada si nos encontramos con actividades del nivel de identificación de oportunidades o entendimento.

Cuando tenemos objetivos complicados de estimar debido a que el camino para conseguirlos es difuso, las prácticas iterativas destinadas a conseguir un objetivo en un timebox determinado podrían no ser demasiado útiles. De esta forma, intentar meter todo el trabajo realizado por los equipos en todos los planos dentro de la iteración de dos semanas, no tiene sentido en muchas ocasiones. Pero eso no quiere decir que los ciclos de inspección y adaptación no sean útiles en cualquiera de los planos, en nuestra opinión siguen siendo útiles para gestionar las expectativas del propio equipo y de los diferentes stakeholders. Sería el plano de implementación donde las iteraciones con un timebox específico resultarían más adecuadas.  

Aun así, la labor de construir una funcionalidad completa basada en datos en el nivel de implementación, en un periodo de dos semanas es en general complicada. Es la labor de los responsables de producto y los científicos de datos establecer la estrategia adecuada para facilitar la entrega de incremento de producto en el menor tiempo posible sin que eso implique tener una funcionalidad completa.

Estas son algunas estrategias para facilitar el trabajo colaborativo de un DS con el resto del equipo:

  • Construir hacia atrás. En ocasiones disponemos de funcionalidades que se pueden empezar a desplegar mediante heurísticos sencillos que luego podemos reemplazar con algoritmos más complejos. En este caso podemos trabajar en integrar estos heurísticos como un stub con el resto de la aplicación y junto al resto del equipo. La gran ventaja es que podemos empezar a testear el valor que la funcionalidad  aportaría al producto sin necesidad de construir una funcionalidad completa.
  • Construir por dominios de datos. En este caso el objetivo es identificar cual es el conjunto mínimo de datos que facilitan la mejor aproximación al modelo ideal. El objetivo es centrarse solo en la adquisición de estas fuentes de datos y su explotación combinando criterios de utilidad y disponibilidad. Posteriormente se pueden ir  incrementando el número de dominios de datos a introducir.
  • Construir por incremento de resolución. Uno de los grandes problemas en el tratamiento de datos es que tanto la adquisición y limpieza de datos requieren una gran cantidad de tiempo. En muchos casos, es viable rebajar los requisitos de este procesos si en vez de un incremento de producto, buscamos un incremento de valor. Como por ejemplo determinar si una fuente de datos o un enfoque es el adecuado. 
  • Construir mediante incrementos de complejidad. En general, conviene explorar el uso de los algoritmos (o visualizaciones) más sencillos o estándar antes de buscar soluciones más complejas, y que requieren mucho más trabajo y experimentación. Hay pocas cosas peores que contrastar, gracias al feedback de los usuarios que la funcionalidad que hemos tratado de resolver, no es en realidad deseable. Es preferible determinar cuánto antes que se trata de una funcionalidad interesante aunque requiera de mayor exactitud o sofisticación para ser útil.

Planos Feedback

Representamos el feedback como planos que cortan de manera transversal al resto de los planos. Un tipo feedback serían el relativo al proceso o mejora de la forma en que se trabaja para crear el producto en cada uno de los planos. El otro tipo de feedback se corresponde con la forma con la que que podemos validar nuestras hipótesis y criterios de éxito para pivotar o persistir en nuestras siguientes iteraciones. El feedback puede tener lugar dentro de cada plano debido a que una iteración no implica necesariamente un cambio de plano.

También puede tomar varias formas, desde el feedback cualitativo del equipo o de los usuarios hasta feedback cuantitativo. Precisamente es en este último, donde la disciplina de datos también ha contribuido en el diseño de experimentos destinados a la validación de hipótesis del producto, de la solución o sobre detalles de la implementación. Cualquier cambio o mejora, como un nuevo algoritmo para una predicción o un cambio en la interfaz, es susceptible  de ser validado con usuarios reales.

Uno de los mayores retos es que el periodo para obtener feedback accionable es   demasiado largo como para trabajar en iteraciones cortas. Para afrontar esta problemática podríamos definir leading indicators que nos permitan validar nuestras hipótesis a más corto plazos.

Ejemplos de Implantación

Dependiendo del contexto la forma de aterrizar todo lo explicado en los anteriores apartados puede variar considerablemente. Especificar un framework para todos los casos sería una simplificación de una situación que seguramente es muy compleja. Incluso algunas personas pensarán que para todos o la mayoría de casos, la utilización de un framework  es un error y la mejor aproximación sería la mejora contínua de los equipos basada en principios y valores ágiles sin especificar prácticas específicas.

Con la simple intención de ayudar a generar ideas, algunas alternativas  serían:

  • Realizar el trabajo con sistemas Kanban de manera que cada work item atraviese uno o varios planos y lo completen las personas que tengan las skills oportunas.
  • Utilizar un sistema Kanban para los planos de identificación, entendimiento e ideación y luego trabajar con los diferentes equipos en scrum (por decir el framework de agilidad más usado) en el plano de implementación. A la hora de gestionar la capacidad (sobre todo en la estimación de scrum) habría que considerar que algunos miembros contribuyen en varios planos.
  • Trabajar con un equipo scrum en los planos de identificación, entendimiento e ideación y luego trabajar con los diferentes equipos en scrum en el plano de implementación. En este caso, como scrum tiene una serie de ceremonias determinadas, si un integrante del scrum de un plano pertenece o participa también en otros scrums, podría existir un riesgo de ineficiencia.

Muchas gracias por el feedback y ayudar en la divulgación a Jerónimo Palacios, Marcelo Soria, Victor Adaíl y Jairo Alberto.

Los autores de este artículo somos César de Pablo Sánchez y Félix Serrano Martín. Nos conocimos trabajando en BBVA D&A, César trabajando como Científico de Datos y Félix como Agile Coach. Las opiniones expresadas por ambos en este artículo son personales y no necesariamente las de su empleador.

César de Pablo es Ingeniero de Telecomunicaciones por la ETSIT-UPM y Doctor en Ingeniería Informática por la UC3M. Tiene más de 15 años de experiencia en desarrollo de productos y soluciones basadas en análisis de datos, aprendizaje automático y procesamiento de lenguaje natural.

¿Cooperar o competir en un mundo digital?

Mi empresa actual no es la primera en la que soy propietario u ostento una participación significativa. Durante los últimos doce años he creado varias, de las cuales esta ha sido la más exitosa. Algunas incluso las he vendido a otros competidores del mercado.

Cooperar o Competir, ese es el dilema

Uno de los aspectos que siempre me ha parecido más interesante del mundo empresarial es el de colaborar o competir con otras empresas que, en principio, son competidores nuestros.

Probablemente el primer impulso cuando tratamos con un competidor sea el de evitar colaborar. ¿Por qué querría colaborar con alguien que puede quitarme lo mío? Detrás de este pensamiento a priori lógico se encuentra un dilema bastante más amplio de lo que pensamos.

Imaginemos que estamos ante una oportunidad empresarial enorme a la que concurrimos en competencia con otra compañía a la que conocemos bien. Si colaboramos para conseguirla, ambos ganamos. Si nosotros intentamos colaborar pero nuestro competidor se aprovecha de esa posición, entonces perdemos. Si nuestro competidor intenta colaborar pero nosotros nos aprovechamos, entonces ganamos. Si ambos intentamos aprovecharnos el uno del otro, entonces ambos perdemos.

Esta es una adaptación del dilema del prisionero y parte de la teoría de juegosfruto del trabajo de John Nash, que fue ilustrada en la película Una mente maravillosa.

El contexto es clave

En el caso del dilema del prisionero, el contexto es clave. No es lo mismo un contexto de suma cero, donde si uno gana otro pierde, que un contexto más rico donde si perdemos, tenemos otra oportunidad. Los entornos empresariales modernos son del segundo tipo, lo cual permite adaptar nuestra estrategia a la de los competidores.

Volviendo al ejemplo anterior, si en una oportunidad posterior nos volvemos a encontrar con el mismo competidor, entonces podemos decidir colaborar o no dependiendo de lo que este haya hecho la vez anterior. En general podemos optar siempre por una estrategia (colaborar o competir) o adaptar nuestra estrategia en función de lo que haga nuestro competidor. Por último, podemos actuar aleatoriamente, o dejándonos llevar por otros factores.

¿Y que hay de la falta de comunicación?

Imagina que en el ejemplo, nuestro competidor se aprovecha de nosotros pero es a causa de un error de comunicación. ¿Deberíamos de darle otra oportunidad? ¿Y si no sabemos que ha sido a causa de un problema de comunicación?

En ese caso, podríamos incorporar una regla a nuestra estrategia que nos indicara si debemos dar una segunda o una tercera oportunidad cuando pensamos que nuestra falta de colaboración se debe a un error de comunicación.

Adoptando heurísticos

La clave es adoptar una posición fija ante cierto tipo de situaciones. Un marco de decisión que nos facilite el tomar decisiones sin tener que hacerlo una por una. En nuestra vida real lo hacemos continuamente, están estudiadas y se llaman heurísticos. El problema es que no siempre somos conscientes de ellas y de las consecuencias de las mismas.

Daniel Kahnehman lo describe en su libro thinking fast and slow. El problema de los humanos es que tenemos un cerebro primitivo, mucho más viejo evolutivamente hablando, y un cerebro moderno, que es capaz de tomar decisiones infiriendo información. Eso hace, por ejemplo, que nos sintamos en ocasiones tristes, o amenazados, sin saber por qué. Nuestro cerebro más viejo toma el control para protegernos de peligros que identificamos como amenazantes aunque realmente no lo sean.

¿Entonces que debo hacer? ¿Colaborar o competir?

La regla de oro es: trata a otro como deseas ser tratado. El problema es que el mundo es injusto y en ocasiones poner la otra mejilla no es fácil. ¿Quieres simularlo? Los chicos de NCASE han desarrollado un simulador de confianza que permite ver cuales son las estrategias más óptimas desde todos los parámetros que hemos visto.

Tener conocimiento de esto permite desarrollar una estrategia de toma de decisiones rápida sobre colaborar o competir. Solamente este mes me he encontrado ante 3 de estas situaciones. Este marco me ha ayudado a tomar una decisión rápida y coherente a lo largo del tiempo.

  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página siguiente »

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad