Monetización de videojuegos – El caso War Robots

Entre las distintas charlas que se llevaron a cabo en el pasado Unity Unite 2018 en Berlín, una que me llamó bastante la atención fue la titulada “Pixonic’s recipe for success – Pairing Ads and IAP” (IPA = “In-app purchases“, compras en la aplicación), llevada a cabo por la empresa rusa Pixonic, los desarrolladores de War Robots, un juego Free-to-Play (F2P) multijugador de luchas entre robots por equipos (6v6), especialmente orientado a dispositivos móviles, pero también disponible en Steam. Todas las charlas del evento fueron muy interesantes, pero esta me llamó la atención como una experiencia de análisis tanto previo como posterior en el proceso de integración de modelos de monetización típicos (anuncios), con algunas conclusiones bastante interesantes y, hasta cierto punto, no evidentes a primera vista. Esto me llamó la atención, más allá de si el juego propiamente se considere o no original, o tenga mejores o peores críticas (que gustos hay para todos).

War Robots, by Pixionic.

El punto de partida es simple. Se dispone de un juego modelo F2P que sigue un patrón bastante normal: luchando obtienes recursos que te permiten mejorar, pero pagando puedes acelerar este proceso. Ahora se desea aumentar el dinero que se gana añadiendo anuncios. ¿Los motivos? Somos avariciosos (presentadores dixit). Lo que hay que ver es de qué manera se ha de hacer, pues no es tan simple como ponerlos de cualquier manera y ya está, o el tiro nos puede salir por la culata. Hicieron su estudio y vieron que el número de jugadores que realmente pagaban eran el 4-5% del total (lo normal, las “ballenas“) y el 70% declararon que no les importaría tener una ayudita en el juego a cambio de ver anuncios.

El primer paso es estudiar en qué momento del juego se han de poner los anuncios y sus repercusiones. Actualmente, el modelo tipo “anuncio de televisión”, situado arbitrariamente o, incluso, en lugares que rompen el flujo del juego, que tienes que ver obligatoriamente, lo único que va a conseguir es que la gente se enfade contigo. Aun cuando hablamos de modelos de monetización, empoderar al jugador es clave. Por lo tanto, su decisión fue la del modelo de anuncios recompensados (“Rewarded Ads“), que el jugador elige si quiere ver, y al cual hacerlo le comporta una recompensa en recursos del juego. En este caso, y de modo similar a otros juegos de móvil, el lugar indicado es al final de cada misión, y se ofrecen diferentes alternativas que permiten acelerar la producción de recursos obtenidos. Otro juego similar que también ofrece esta opción es la versión móvil del Galaga o distintos runners. Si alguien no quiere ver anuncios, pues el juego es igual que siempre, no hay problema, todo contentos.

Implementación de anuncios recompensados en War Robots.

¿Todo solucionado? Pues no, ya que resulta que aquí aparece el primer problema oculto grave. Al tratarse de un juego multijugador, acabamos de poner en grave peligro su estabilidad, pues hemos introducido una nueva fuente de ingresos (“source”) para los jugadores (poder ver anuncios), sin haber introducido ningún mecanismo de gasto extra (“sink”). Por lo tanto, nos hemos cargado la economía del juego. Los jugadores no lo van a abandonar porque los anuncios les molestan, lo van a hacer porque de repente hemos roto el equilibrio de la economía de juego, que ya había costado lo suyo ajustar. Como popularmente se dice, el camino al infierno está plagado de buenas intenciones: generas anuncios a elección del jugador y les recompensas por ello, y el resultado es que todos los jugadores se van (porque has destruido el equilibrio del juego). Por lo tanto, paso dos: ajuste de las recompensas por anuncio y de cuántos anuncios es posible ver cada cierto tiempo, no automáticamente tras cada partida jugada. Solo un número limitado de veces. De hecho, si no se ajusta bien esto, puede que al final la gente prefiera ver anuncios más que jugar, como modo de recopilar recursos y progresar en el juego. ¡Viva la jobification!

Al final, con un poco de análisis de los datos, y diversificando las recompensas obtenidas en anuncios (recompensas tras batalla, aceleración de construcciones, lootboxes, etc.), se consiguió introducir este modelo de monetización sin que afectara gravemente al equilibrio del juego. De hecho, a posteriori, los desarrolladores pensaron que incluso este modelo podía ser positivo, pues “democratizaba” la producción de recursos, de modo que los jugadores que no pagan ahora pueden generar recursos de un modo que les permita disminuir la brecha con aquellos que sí que pagan (y claramente tienen una gran ventaja, ¿Free-to-Play, o Pay-to Win?).

Sin embargo, y aquí vino la otra sorpresa, resulta que al final la gente que mira más anuncios no es aquella a la que no le queda más remedio al no querer pagar. Los mayores consumidores son los mismos jugadores que, a su vez, pagan por los contenidos (66% vs 44%). De eso de “igualar el juego”, nada de nada. El jugador dedicado cuyo único propósito en el juego es maximizar el uso de sus recursos va a usar todas las herramientas posibles para ello, y no solo la más eficiente (pagar), en pos de la otra menos eficiente (anuncios). Moraleja: al final, todo quedó como al principio. Bueno, solo que ahora los desarrolladores cobran más, al integrar anuncios en la aplicación.

Y un resumen de sus conclusiones (que escribo tal cual, como quien dice):

  • Integrar anuncios a una aplicación F2P vale la pena.
  • Mostrar anuncios a tus jugadores no es un tema tabú.
  • Alerta con el nivel de las recompensas.
  • Hay que analizar muy bien los perfiles de tus jugadores.
  • Hay que empoderar al jugador y dar la opción a escoger (e.g. si ver el anuncio, tipo de recompensa…).

Joan Arnedo es profesor de los estudios de Informática, Multimedia y Telecomunicación en la UOC. Director académico del Máster en Diseño y Desarrollo de Videojuegos e investigador en el campo de la ludificación y los juegos serios. Su experiencia se remonta a cuando los ordenadores MSX poblaban la Tierra…

Quiero aprender a programar. ¿Por dónde me pongo?

¡Excelente pregunta!

Antes de entrar en materia… ¡Felicidades! La curiosidad por aprender a programar es, quizá, la curiosidad del siglo XXI. Hoy en día cuesta decir que un conocimiento es imprescindible, pero entender qué es programar está muy, pero que muy cerca de serlo. Cada día suceden infinidad de cosas que nos afectan —por muy poco conectados que estemos— que pasan por un algoritmo (¡o muchos!) que toma unos datos, los procesa de una determinada forma y acaba dando un resultado que nos atañe muy directamente. Ya sea tu declaración de la renta, pedir hora en el médico, que te asignen colegio para tus hijos… prácticamente todo pasa en algún momento por un programa informático. Y si quieres entender cómo se programa… difícilmente lo vas a conseguir de verdad sin haber programado al menos un poco. Así pues, insistimos, felicidades por haber tomado una excelente decisión.

En segundo lugar, una advertencia. ¿Sabéis esos cursos milagrosos que aseguran enseñaros inglés en treinta días? Aprender a programar es, en parte, aprender un idioma (y mucho más que eso: es aprender a enseñar a una máquina a hacer cosas extraordinarias). Muy poca gente va a aprender un idioma —informático o no— en treinta días. Existe un pequeño riesgo, además, de que no aprendáis a programar (pequeño, insisto). Aun así, esforzarse e intentarlo de verdad va a tener como resultado, en el peor de los casos, el entender mucho mejor cómo funciona el universo en que nos movemos. Pero os vais a tener que poner de verdad. Si alguien os asegura que a programar se puede aprender sin esfuerzo, desconfiad. Añado, además, que es un aprendizaje que con cierta frecuencia nos va a frustrar: si no has querido tirar nunca el ordenador por la ventana… es que no has aprendido a programar. Si buscáis algo que aprender sin riesgo de frustración, la programación no es el camino. Eso sí: a cambio, pocas cosas hay más satisfactorias que escribir tu primer programa. O el segundo. O…

Dicho lo cuál… por dónde comenzar. Repitamos: excelente pregunta. Hay muchas, muchísimas opciones, tanto de metodologías como de lenguajes.

Qué lenguaje elegir

La lista de lenguajes de programación es enorme. Hay una lista en Wikipedia que enumera hasta 58 lenguajes de programación… que comienzan por la letra A (contar cuántos lenguajes de programación hay en esa página es, por cierto, un excelente ejemplo de ejercicio de programación ;-)). Hasta la lista de lenguajes de programación educativos (esto es, diseñados para enseñar a programar) es enorme. Si conocéis a alguien que hace años que sabe programar, seguro que le podéis sacar alguna anécdota sobre los vetustos BASIC o Pascal, por ejemplo. Probad, ya veréis.

Hoy en día, el lenguaje educativo por excelencia es Scratch. Y, si tenéis niños, muy probablemente sea la mejor opción para que se inicien en este mundillo (algo sabemos del tema ;-)), gracias a su entorno de programación amigable y las posibilidades que ofrece para crear juegos con relativamente poco esfuerzo. Puestos a criticarlo por alguna cosa, ese mismo entorno hace que, a partir de un cierto nivel de sofisticación, deje de ser una opción viable (aunque hay pequeñas maravillas —y no tan pequeñas— por ahí hechas en Scratch). Y el entorno que lo hace tan atractivo para muchos niños y niñas a veces tira para atrás a los mayores…

Otro lenguaje muy en boga para aprender a programar es Python, un lenguaje de programación diseñado, entre otras cosas, con el objetivo de ser fácilmente legible, y a cuyo alrededor se ha creado una enorme y potente comunidad que ha desarrollado una gran cantidad de recursos tanto para expandir sus funcionalidades como para facilitar su aprendizaje. (Nos permitiremos recordar, además, que Python es el lenguaje que recomendamos para hacer ciencia de datos).

Una opción quizás menos conocida pero extremadamente interesante es Processing, un lenguaje pensado para las comunidades del arte electrónico, el new media y el diseño visual. Para satisfacer a esas comunidades se pensó con una sintaxis simple y la capacidad de generar resultados visuales sofisticados con relativamente poco esfuerzo. La combinación de ambos factores lo convierte en un excelente lenguaje para dar nuestros primeros pasos.

Pero, si nos lo permitís, os vamos a presentar una alternativa quizás menos popular pero, en seguida veréis por qué, muy interesante: JavaScript. JavaScript es un lenguaje de programación creado a finales de 1995, cuando los desarrolladores de Netscape Navigator (el antiguo navegador de cuyas cenizas nació el actual Firefox) tuvieron la necesidad de añadirle un lenguaje de programación a su navegador. En apenas diez días (literalmente) Brendan Eich creó un primer prototipo. Y hoy, más de dos décadas después, ese lenguaje (después de muchísimas evoluciones) es el que sigue reinando en la web, implementado en todos los navegadores (¿Facebook? ¿GMail? ¿Twitter? Sí, grandes cantidades de JavaScript). Incluso cuando no estáis usando un navegador, es difícil que estéis usando un ordenador (aunque este tenga la forma de un smartphone) y estéis muy lejos de algo que funciona gracias a JavaScript: la aplicación de Spotify, por poner un ejemplo, funciona gracias a miles de líneas de código JavaScript (y bastante C++ también, todo sea dicho). ¿Habéis usado alguna vez la aplicación de escritorio de WhatsApp? Pues sí, también está hecha en JavaScript. Y nos podríamos pasar así un buen rato.

¿Cuáles son las ventajas de JavaScript?

  • En primer lugar, desde luego, su universalidad: difícilmente vais a encontrar un ordenador (o smartphone, o tablet) que no ejecute JavaScript. Si tiene un navegador, tiene JavaScript (y si no la tiene, casi seguro que también).
  • En segundo lugar, que no necesitáis absolutamente nada para empezar a programar en JavaScript: en vuestro ordenador ya tenéis un editor de texto (si estáis en Windows, se llama “Bloc de notas”; en Mac disponéis, por ejemplo, de TextEdit) con el que comenzar a escribir y vuestro navegador favorito para ejecutar código (los navegadores, además, cada vez ofrecen mejores developer tools que nos asisten a la hora de analizar, depurar y mejorar nuestro código). Prácticamente todo el resto de lenguajes necesita que os bajéis e instaléis al menos un pequeño entorno de desarrollo sin el que no podréis trabajar. Y si queréis entornos más sofisticados sin la necesidad de instalar nada, tenéis una variedad de sitios web, como Codepen, por ejemplo, que os ofrecen mejores herramientas y todo el código de ejemplo que podáis necesitar.
  • En tercer lugar, que existen multitud de recursos educativos en abierto con los que podéis comenzar. Nuestros favoritos son los tutoriales de Mozilla (la fundación que desarrolla Firefox, entre otras muchas cosas) y un libro de texto disponible de forma gratuita en la web, Eloquent JavaScript.
  • Finalmente (por no alargarnos más), a pesar de lo que quizá hayáis oído por ahí, porque JavaScript (y su primo cercano, TypeScript) es hoy en día un lenguaje de programación moderno que dispone de todas las funcionalidades que vais a necesitar, primero, para aprender a programar y, después, para desarrollar la aplicación que se os pase por la cabeza.

Pero, en cualquier caso, lo importante es empezar por algún sitio. Y, de todas formas, si os acaba picando el gusanillo, lo más probable es que acabéis aprendiendo a programar en muchos lenguajes. Y, como con los idiomas, el segundo es mucho más fácil de aprender que el primero :-).

Y cómo lo hago

Afortunadamente, casi todos los caminos llevan a Roma (como decíamos antes, eso sí, el camino es largo y requiere de esfuerzo).

Podéis, desde luego, optar por la vía de la autoformación. Hace dos párrafos hablábamos de los tutoriales de Mozilla o de Eloquent JavaScript. Son excelentes recursos que os animamos a consultar y que os van a llevar muy, pero que muy lejos, si les dedicáis el tiempo y el trabajo necesarios. Hay por el mundo una enorme cantidad de profesionales que han comenzado a programar solos (nosotros preferimos decir que apoyándose en hombros de gigantes, eso sí) y han seguido aprendiendo por su cuenta gracias a la gran comunidad de desarrolladores y el conocimiento que genera.

La mayoría de vosotros, eso sí, va a querer algo más de acompañamiento cuando os encontréis con los dolores de cabeza que casi inevitablemente os encontraréis por el camino. Una opción de moda actualmente es la de buscar un MOOC de programación, en JavaScript o, como decíamos antes, en cualquier otro lenguaje. Un MOOC buen diseñado (no todos lo están, desafortunadamente) y apoyado en buenos materiales de aprendizaje os va a dar un extra de acompañamiento que seguramente os sea muy útil y puede ser una gran opción.

Y, naturalmente, queda la opción de cursos más convencionales, ya sea en línea o presenciales, de los que, por poco que busquéis, encontraréis una miríada. Como siempre en estos casos, lo mejor es documentarse bien, explorar las opciones que ofrece el mercado. Desde los estudios de Informática, Multimedia y Telecomunicación de la UOC hemos creado nuestra alternativa de introducción a la programación en JavaScript, respaldada por nuestros más de veinte años de experiencia en la enseñanza de la informática en línea. Creemos que es una excelente opción, diseñada para daros el máximo acompañamiento y flexibilidad y poniendo todo el acento en el trabajo continuo en la resolución de problemas y la elaboración de pequeños proyectos que os permitan avanzar con seguridad en el objetivo de aprender a programar.

Sea en nuestras aulas o en cualquier lugar, os deseamos todo el éxito del mundo en la aventura. ¡Adelante!


Carlos Casado es licenciado en informática (UPC), máster en software libre (UOC), director del máster de Aplicaciones Multimedia y profesor responsable del curso Introducción a la programación en JavaScript.

César Córcoles es licenciado en matemáticas (UAB) y director del máster de Desarrollo de sitios y aplicaciones web.


PS ¡¿En serio JavaScript?! Es posible que alguno de vosotros haya oído hablar mal de JavaScript. Y es cierto que es un lenguaje que, durante sus primeros años de existencia, se ganó una cierta mala fama (teniendo en cuenta que se diseñó en diez días, difícil habría sido que no fuera así). A pesar de ello, en los últimos años, con el advenimiento del estándar ECMAScript, JavaScript (y, como comentábamos antes, TypeScript) se ha convertido en un lenguaje de programación de primera categoría. Si alguien lo critica, indagad un poco cuándo actualizó por última vez sus conocimientos sobre JavaScript (y, naturalmente, elegid con total libertad por dónde avanzar, que la cantidad de buenas opciones es enorme).

Unity Unite 2018

Cada año, en distintas ciudades del mundo repartidas en cada continente, se celebra la Unity Unite, la conferencia para desarrolladores, evangelistas e interesados en general sobre el motor de creación de videojuegos Unity. Los días 19 a 21 de junio se celebró la ubicada en Europa, concretamente en Berlín (el año pasado tocó Amsterdam), y como la UOC es partner oficial Unity, nos invitaron a ir.

Esta conferencia está orientada a la industria, y claro está, absolutamente centrada en cantar las bondades del producto del organizador, muy similar a otras vinculadas a fabricantes en otros ámbitos (me viene a la cabeza el “Cisco Live”, que se llevó a cabo a principios de este año en Barcelona), pero siempre es interesante acudir para saber qué nos espera este año y poder conversar con expertos en esta herramienta. El programa se basa en ciclos de conferencias, tutoriales/talleres y una sala general de expositores, tanto empresas de desarrollo de videojuegos que utilizan el motor Unity, como de plug-ins o assets que permitan facilitar algunas funcionalidades extra: juegos en red, VR/AR, análisis de métricas, IDEs o incluso, este año, temas de interfaces para la automoción.

Bienvenidos al Unity Unite 2018, Berlín.

La visión general siempre se ofrece al final del primer día, en la “opening keynote”, que sirve como presentación de todas las novedades, si bien no mucho más allá de presentar un titular. Después, a lo largo de la conferencia, ya existen distintas charlas más especializadas para cada una de estas novedades. El punto de partida y una de sus principales apuestas, ya que le dedicaron bastante tiempo, fue el eslogan: “Reality is our build target“. Con esto se referían a la integración de todo tipo de herramientas ligadas al desarrollo de aplicaciones, de realidad aumentada o virtual, bajo el paraguas XR, tanto desde el punto de vista de captura de movimiento, sobretodo caras, como de la creación de manera relativamente simple de escenarios en 3D sobre el mundo real. Para ello, más que palabras, pusieron sobre el escenario todo tipo de demos basadas en sus recientes kits de creación en 3D. Así pues, se vienen muchas novedades en este campo, ya tan de moda desde hace un tiempo. De hecho, el stand de Google sobre ARCore tenía un lugar prominente en la sala de exposiciones, y más adelante, el día siguiente, habría una charla específica sobre cómo integrarlo con Unity (pero el presentador dijo que también estaba disponible para “aquello que no puede ser mencionado“).

Un paso más hacia la realidad aumentada.

Después se presentaron temas a los que no dedicaron tanto tiempo, pero que también resultaron bastante interesantes, un poco en plan menú degustación:

  • El despliegue de un “runtime” reducido, exactamente de 72kb en total, con el propósito de poder integrar pequeñas aplicaciones en entornos de mensajería instantánea o distribuir demos de manera dinámica. No hace falta instalar nada en local, todo se ejecuta sobre navegador. Esto es bastante interesante ya que Unity, como motor de propósito general, suele generar binarios bastante pesados.
  • El sistema de “kinematica”, de modo que generas un conjunto de “clips” con animaciones 3D del personaje a partir de mecanismos de captura de movimiento (en la demo salía un individuo lleno de sensores saltando por paredes en plan Chun Li), y ya está. A través de un sistema de Machine Learning basado en la posición del personaje, su movimiento y el contexto del entorno de juego, el motor elige en cada momento la animación que es más pertinente. Esto evita la creación de grafos de estados de animaciones cada vez más y más complejos.
  • Con el mismo propósito, pero para 2D, el “sprite shaping” de generación de mecanismos de animación esqueletal, tanto en el caso de personajes como incluso en la creación del propio terreno. Para cada sprite se genera un “rig”, con distintas articulaciones y pesos, y el propio motor genera las animaciones automáticamente a partir de la rotación y escalado de partes de la figura original. No hemos de crear y subministrar nosotros todos los sprites o “clips” posibles para las distintas animaciones.
  • La presentación de la demo del “Book of the Dead“, con el propósito de mostrar hasta dónde puede llegar el motor si se exprime al máximo, pero también una muestra más del hecho que Unity ya se presenta como motor de animación para el desarrollo de cortometrajes o de demos en entornos virtuales, y no solo como herramienta para videojuegos en exclusiva.
  • La nueva alianza entre Unity y Google, de modo que toda su infraestructura de red se migra a Google Cloud en breve y empiezan a trabajar para integrar servicios de Google en Unity, sobretodo en tema de funcionalidades on-line (e.g. matchmaking).

Pero quizá el tema clave, y que dejaron para el final en plan sorpresa, fue el nuevo workflow de “prefabs“, los assets de Unity que permiten desplegar copias de objetos pre-personalizadas. Año tras año los desarrolladores habían pedido algunas modificaciones y, por fin, llegaron. Alegría y muchas risas cuando llegó el momento, e incluso dejaron caer papeles y serpentinas al presentarlo a modo un tanto de auto-parodia. Las modificaciones esenciales se resumen en dos, más allá de un lavado de cara de bugs en general. Por una parte, en breve, existirá un modo de edición de “prefabs” (“prefab mode”) en el que todos los cambios sobre el “prefab” se trasladan automáticamente en tiempo de edición a todos los objetos en el escenario creados a partir de él. Y, por otra parte, la posibilidad de crear jerarquías de “prefabs”, igual que se pueden hacer ahora con los GameObjects, con el propósito de crear elementos complejos a través de la agregación de más simples. Como detalle final, aparece un nuevo tipo de “prefab” llamados “variantes”, que son copias de otros ya existentes, pero con unas pocas modificaciones, de tal modo que cambios en el original se transmiten también a la variante. Básicamente, las relaciones clase-subclase tipo orientación a objetos, llevadas a los “prefabs” de Unity.

¡Aleluya, nuevo sistema de prefabs!

Al final, si uno filtra las partes más “evangelizadoras”, no dejó de ser un evento la mar de interesante que permitió una visión en primicia y bastante “hands on” del camino previsto para Unity, de gran utilidad ya seas desarrollador o, como en nuestro caso, docente.

Joan Arnedo es profesor de los estudios de Informática, Multimedia y Telecomunicación en la UOC. Director académico del Máster en Diseño y Desarrollo de Videojuegos e investigador en el campo de la ludificación y los juegos serios. Su experiencia se remonta a cuando los ordenadores MSX poblaban la Tierra…

Datos abiertos para tod@s

(Trobareu la versió en català més avall)

El fenómeno de la apertura de datos (open data en inglés) se ha convertido en una tendencia a nivel mundial. Cada día se publican más y más datos provenientes tanto del sector público como de fuentes privadas. Los gobiernos, las ciudades y la industria privada producen una gran cantidad de datos a los que se puede acceder públicamente. A modo de ejemplo, el portal europeo de datos registra más de 800.000 conjuntos de datos (datasets en inglés). También el Ayuntamiento de Barcelona, mediante su portal Open Data BCN, dispone de un amplio catálogo de datos abiertos, como ya vimos en este mismo blog. Por otro lado, según diversos informes publicados en el portal europeo de datos, un 87% de los países europeos poseen iniciativas activas de portales de datos abiertos y un 71% de ellos han desarrollado políticas de datos abiertos.

El denominado movimiento Open Data tiene como objetivo capacitar a los usuarios finales para explotar y beneficiarse de los datos abiertos, prometiendo a la sociedad tener cualquier dato al alcance de su mano, ya sea para planificar su próximo viaje como para supervisar a su gobierno. A pesar de las iniciativas para promover el uso de datos abiertos, como el reto “Barcelona Dades Obertes” del que hablamos en este mismo blog, actualmente sólo el 2,7% de las organizaciones involucradas en datos abiertos son habilitadores (es decir, facilitan el suministro o uso de datos abiertos), según un informe publicado en el portal europeo de datos. Además, la mayoría de las iniciativas para promover los datos abiertos se basan principalmente en la provisión de portales de datos abiertos que actúan como repositorio de conjuntos de datos y que proporcionan un número limitado de visualizaciones y usos.

En resumen, aunque la sociedad está abriendo poco a poco sus datos, lo cierto es que no está construyendo la tecnología ni la infraestructura necesarias para que los ciudadanos puedan acceder a ellos y manipularlos. Solo las personas con conocimientos tecnológicos tienen las habilidades para consumir las fuentes de datos heterogéneas, mientras que el resto de ciudadanos se ven obligados a depender de aplicaciones o desarrolladas por terceros.

Con el objetivo de superar esta barrera, recientemente se celebró el 1r Workshop Internacional sobre Ingeniería de Datos Abiertos (WEOD 2018), que tuvo lugar conjuntamente con la 18º Conferencia Internacional de Ingeniería Web (ICWE 2018). El taller reunió a investigadores, profesionales, partes interesadas y usuarios de datos abiertos que propusieron y debatieron enfoques prácticos de la ingeniería aplicada a dos ámbitos principalmente:

  1. El diseño y desarrollo de medios para promover el consumo de datos abiertos, aprovechando técnicas existentes bien conocidas de la ingeniería (por ejemplo, el modelado conceptual, la extracción de datos, la inteligencia de datos, etc).
  2. El diseño y desarrollo de mecanismos de composición que ayuden a combinar las distintas fuentes de datos abiertos.

Durante el taller se presentaron un total de cuatro ponencias, el detalle de todas las ponencias se puede consultar en este enlace:

Fue un encuentro muy fructífero que esperamos poder repetir el próximo año para, poco a poco, empoderar a los ciudadanos para que puedan acceder directamente a la enorme  y creciente cantidad de datos abiertos disponibles hoy en día a través de la red.

Para más información, puedes consultar el proyecto de investigación Open Data for All: an API-based infrastructure for collecting and disseminating online data sources, impulsado desde el grupo de investigación SOM Research Lab y liderado por el Dr. Jordi Cabot Sagrera.

 

Elena Planas es Ingeniera en Informática y Doctora por la Universitat Politècnica de Catalunya. Actualmente es profesora de los Estudios de Informática, Multimedia y Telecomunicación (UOC), donde es responsable de asignaturas del área de Ingeniería del Software, e investigadora del grupo del SOM Research Lab (UOC-IN3).

Dades obertes per tothom

El fenomen de l’obertura de dades (open data en anglès) s’ha convertit en una tendència a nivell mundial. Cada dia es publiquen més i més dades provinents tant del sector públic com de fonts privades. Els governs, les ciutats i la indústria privada estan produint una gran quantitat de dades a les quals es pot accedir públicament. A tall d’exemple, el portal europeu de dades registra més de 800.000 conjunts de dades (datasets en anglès). També l’Ajuntament de Barcelona, mitjançant el seu portal Open Data BCN, disposa d’un ampli catàleg de dades obertes, com ja vam veure en aquest mateix bloc. D’altra banda, segons diversos informes publicats al portal europeu de dades, un 87% dels països europeus tenen iniciatives actives de portals de dades obertes i un 71% d’ells han desenvolupat polítiques de dades obertes.

L’anomenat moviment Open Data té com a objectiu capacitar els usuaris finals per explotar i beneficiar-se de les dades obertes, prometent a la societat tenir qualsevol dada a l’abast de la seva mà, ja sigui per planificar el seu proper viatge com per supervisar el seu govern. Tot i les iniciatives per promoure l’ús de dades obertes, com el repte “Barcelona Dades Obertes” del qual en vam parlar en aquest mateix bloc, actualment només el 2,7% de les organitzacions involucrades en dades obertes són habilitadores (és a dir, faciliten el subministrament o l’ús de dades obertes), segons un informe publicat al portal europeu de dades. A més, la majoria de les iniciatives per promoure les dades obertes es basen principalment en la provisió de portals de dades obertes que actuen com a repositori de conjunts de dades i que proporcionen un nombre limitat de visualitzacions i usos.

En resum, tot i que la societat està obrint a poc a poc les seves dades, la realitat és que no està construint la tecnologia ni la infraestructura necessàries perquè els ciutadans puguin accedir-hi i manipular-les. Només les persones amb coneixements tecnològics tenen les habilitats per consumir les fonts de dades heterogènies, mentre que la resta de ciutadans es veuen obligats a dependre d’aplicacions o desenvolupades per tercers.

Amb l’objectiu de superar aquesta barrera, recentment es va celebrar el 1r Workshop Internacional sobre Enginyeria de Dades Obertes (WEOD 2018), que va tenir lloc conjuntament amb la 18º Conferència Internacional d’Enginyeria Web (ICWE 2018). El taller va reunir a investigadors, professionals, parts interessades i usuaris de dades obertes que van proposar i debatre enfocaments pràctics de l’enginyeria aplicada a dos àmbits principalment:

  1. El disseny i desenvolupament de mitjans per promoure el consum de dades obertes, aprofitant tècniques existents ben conegudes de l’enginyeria (per exemple, el modelatge conceptual, l’extracció de dades, la intel·ligència de dades, etc.).
  2. El disseny i desenvolupament de mecanismes de composició que ajudin a combinar les diferents fonts de dades obertes.

Durant el taller es van presentar un total de quatre ponències, el detall de les quals es pot consultar en aquest enllaç:

Va ser una trobada molt fructífera que esperem poder repetir l’any que ve per, a poc a poc, empoderar els ciutadans per a què puguin accedir directament a l’enorme i creixent quantitat de dades obertes disponibles avui en dia a través de la xarxa.

Per a més informació, pots consultar el projecte de recerca Open Data for All: an API-based infrastructure for collecting and disseminating online data sources, impulsat des del grup de recerca SOM Research Lab i liderat pel Dr. Jordi Cabot Sagrera.

 

Elena Planas és Enginyera en Informàtica i Doctora per la Universitat Politècnica de Catalunya. Actualment és professora dels Estudis d’Informàtica, Multimèdia i Telecomunicació (UOC), on és responsable d’assignatures de l’àrea de l’Enginyeria del Software, i investigadora del grup SOM Research Lab (UOC-IN3).

¿Es la gestión de proyectos un mito? (y II)

Mi post anterior ha merecido dos comentarios aquí, muy bien argumentados y escritos y cuya lectura os recomiendo, se ha difundido en alguna red y me han llegado directamente otras reacciones y ningún hate, al menos público. Dejadme seguir un rato el análisis antes de escribir propuestas o caminos de mejora en otra entrada y antes de irnos de vacaciones, promise.

 Freepik 1098259

El alcance y el valor. Los jefes de proyecto y quienes los controlan viven obsesionados por el alcance y esto les pierde. El alcance es una lista de requisitos y también dos huevos duros (como decía Marx, Groucho). No tiene que ver frecuentemente con ninguna clase de valor o beneficio para el negocio, más allá de la comodidad pasajera de un usuario… a quien nadie se atreve a contradecir. ¡Y no es el valor ganado! El famoso valor ganado es un engendro que mide el trabajo ejecutado contra el presupuesto aprobado, pero no mide el valor aportado o recuperado de una inversión en informática.

El proyecto y las otras cosas. A mí me parece que, como en todas las comunidades, la cofradía de la gestión de proyectos decidió que el proyecto tenía una lógica propia, separada de lo que pasa en la empresa, de lo que el cliente hace o tiene que hacer y de lo que ocurre en el resto del departamento de informática. Esta resulta una opción más segura y, si algo sale mal, siempre se puede culpar a otros. Las metodologías, y lo escribe un autor de metodologías, tienen efectos colaterales. Una mejor metodología o un reporting más completo o mayor número de herramientas y artefactos no hará mejores productos… y es un sobrecoste cuyo valor hay que justificar bien.

Y el cliente, ¿dónde está? La gestión de proyectos, tal como la conocemos, es una entidad defensiva. Los clientes se defienden de los proveedores y viceversa. El jefe de proyecto levanta acta, intentando que no se hagan mucho daño. Los jefes de proyecto se defienden entre sí, como un gremio, pactando semáforos y líneas rojas, como en el primer capítulo de Las aventuras de un líder de TI.  Esto tranquiliza a la dirección… hasta que el desastre no tiene remedio. El cliente se retiró o lo retiramos lo antes posible: no ha participado en el delivery ni participa del reporting. En la obsesión por el control, paradójicamente, nadie es responsable (accountable).

El jefe de proyecto superhombre. La respuesta es, con frecuencia, creer que los jefes de proyectos no son buenos, no están suficientemente cualificados. O reclutar otros jefes de proyecto u oficinas externas que controlarán a los jefes de proyecto. Se pide a los nuevos jefes de proyecto mayores capacidades gerenciales y de liderazgo, pero también conocimiento técnico y funcional, que controle los contratos y administre los recursos, que forme y desarrolle a su equipo, habilidades consultivas (saber escribir, presentar o hacer entrevistas), autoridad pero buen rollo y carisma. Olvidémoslo: todo eso junto no existe y, si lo encontramos, será un agobio. ¡Tendremos que gestionar al gestor de proyectos!

La obsesión por la predictibilidad, por la precisión en la definición de requisitos, por el control y el reporting, por las metodologías robustas y por los liderazgos fuertes, sólo han mejorado marginalmente la gestión de proyectos, según la ley de rendimientos decrecientes. A lo mejor porque el problema no está bien definido y diagnosticado y no tiene que ver, o no principalmente, con la gestión de proyectos…

José Ramón Rodríguez es profesor de dirección de las TIC en diferentes programas de la UOC y consultor independiente. Investiga la planificación y gestión de proyectos de transformación empresarial facilitados por los sistemas y tecnologías de la información.