viernes, 18 de agosto de 2017

El impacto de la digitalización en la economía de un país


Como complemento al artículo anterior, en que resumía la propuesta de McKinsey para medir la digitalización de un país, y basándome en el mismo informe, 'La reinvención digital: una oportunidad para España', paso revista a otro aspecto relevante que se menciona en el informe: qué aporta la digitalización a un país.

El informe nos habla de mejoras en la productividad, la eficiencia del mercado laboral y el uso del capital y menciona cinco puntos. Son estos:

  • Mejoras de procesos y operaciones habilitado por Internet de las Cosas: Se refiere la optimización, por ejemplo, de cadenas de producción especialmente mediante monitorización o también control en tiempo real de rutas. También se incluye aquí el uso de Big Data para control de inventarios. Para el caso de España valora el impacto de esta palanca en 91 mil millones de euros.

  • Utilización de las tecnologías digitales para mejorar en I+D: En esta palanca se incluyen cosas como la mejora en las habilidades y velocidad para el análisis de datos (Big Data) para incrementar descubrimientos o también el uso de diseño asistido por ordenador o la impresión 3D por ejemplo para reducir el peso de aviones. En España esto se cuantifica en una oportunidad por valor de 64 mil millones de euros.

  • Mejoras en la gestión de recursos: por ejemplo, gestión energética y de residuos y se ejemplifica con la aplicación de redes neuronales por una química. Esto podría suponer para España un crecimiento de hasta 4 mil millones de euros.

  • Mejoras en la eficiencia del capital y uso de los activos: se habla, por ejemplo, de mejoras en mantenimiento preventivo mediante aplicaciones que indiquen el momento adecuado para realizarlo, e incluso aplicando un mantenimiento predictivo que actúe sólo cuando realmente se necesita en lugar de hacerlo de forma rutinaria. Para España se estima en una oportunidad de 24 mil millones de euros

  • Uso de las herramientas digitales en el mercado laboral: permitiendo emparejar oferta y demanda en plataformas de empleo y optimizar la búsqueda de talento, lo que influye, a nivel macro, en más días trabajados y, por tanto, más productividad. También se menciona, de una forma algo genérica, la productividad de los empleados en el puesto de trabajo por el uso de herramientas digitales.

Según el mismo informe, la suma de todas estas oportunidades suponen para España, y hasta 2025, una oportunidad de entre 150 y 225 mil millones de euros, es decir, entre el 1,3% el 1,8% del PIB

La verdad es que veo los cinco puntos algo simplificados, y echo en falta  quizá una visión más amplia de las tecnologías y sus aplicaciones (se concentra mucho en Internet de las Cosas y Big Data) auqnue puede que ese presunto defecto sea más la forma de expresarlo que el análisis en sí (que no se detalla). Lo que no me cabe duda es de que las posibilidades son inmensas y que tenemos una oportunidad, y casi una obligación, de aprovechar esta oportunidad que supone la digitalización.

miércoles, 16 de agosto de 2017

¿Cómo medir la digitalización de un país? La propuesta de McKinsey


No es tarea sencilla: resumir en un único índice el nivel de digitalización de país. Un número que nos permita comparar el desarrollo de los diferentes países y conocer los puntos fuertes y débiles.

Acabo de leer el informe ‘La reinvención digital: una oportunidad para España’ elaborado por COTEC y McKinsey y, aparte de algún otro aspecto (que será objeto de algún otro post en este blog) me ha llamado la atención el llamado ‘Indice de digitalización’, un número que mide el nivel de digitalización de un país y cuya metodología ha sido definida por McKinsey.

El índice agrega información de 24 variables, cada una medida de diferentes formas o tomada de diferentes fuentes. Las medidas incluyen la visión tanto de oferta de servicios digitales como de demanda de los mismos.

A su vez, esas 24 variables se estructuran en 4 subíndices (Consumidores, Empresas Gobierno y Oferta en TIC e Innovación). Dentro de cada subíndice existen unas nuevas subdivisiones, de dos a seis por subíndice, en las llamadas áreas. Y, finalmente, tenemos las variables.

Sin entrar en detalles (la mayoría de las variables son autodescriptivas), éstas son las variables que componen el índice:
  • SUBÍNDICE CONSUMIDORES
    • Área Uso de Internet
      • Variable: penetración de Internet
      • Variable: Uso de banda ancha móvil
    • Área Uso de Smartphones
      • Variable: Penetración de smartphones
    • Área: Uso de redes sociales
      • Variable: Cuentas activas en redes sociales
      • Variable: Tiempo dedicado a redes sociales
    • Área Ventas en Internet
      • Variable: Ventas en Internet sobre total de ventas

  • SUBÍNDICE EMPRESAS
    • Área Uso de nuevas tecnologías
      • Variable: Uso de Internet en B2B
      • Variable: Adopción de nuevas tecnologías en empresas
    • Área Publicidad
      • Variable: Gasto online per cápita
      • Variable: Gasto online sobre gasto total

  • SUBÍNDICE GOBIERNO
    • Área Promoción de las TIC
      • Variable: éxito del gobierno en promover las TIC
    • Área Uso de las TIC
      • Variable: Índice de servicios online del Gobierno
      • Variable: uso de las TIC y eficiencia del gobierno
      • Variable: Digitalización de los sistemas de la administración
      • Variable Índice e-government

  • SUBÍNDICE OFERTA TIC E INNOVACIÓN
    • Área Cobertura
      • Variable: Cobertura 3G
    • Área Conectividad
      • Variable: Cobertura en Internet Internacional
      • Variable: Servidores de Internet seguros per cápita
      • Variable: Velocidad media de descarga
    • Área Asegurabilidad
      • Variable: Tarifas de banda ancha fija
      • Variable: Tarifas de banda ancha móvil
    • Área Patentes PCT
      • Variable: Peticiones de patentes PCT per cápita
    • Área Compañías TIC
      • Variable: Participación de las empresas del sector TIC en ingresos sobre el top 1000 mundial

Algunas variables son de disponibilidad casi inmediata. Otras se estiman, por ejemplo, mediante encuestas. Por supuesto, el índice es sólo una forma de estimar y, por supuesto, siempre es discutible la selección de variables o la forma de medirlas, pero me parece un más que interesante esfuerzo de abstracción y sistematización.

Aunque este índice no podrá nunca tomarse como un valor absoluto indiscutible, sí proporcionará, sobre todo, un buen elemento para la comparación inter-países y en el tiempo.

lunes, 14 de agosto de 2017

Smart Factories: un informe y tres comentarios




Se trata de un informe elaborado por Cap Gemini a partir, fundamentalmente, de unas encuestas a más de 1000 ejecutivos de grandes empresas relacionadas con la fabricación.

No se define claramente en el informe qué se entiende por una Smart factory pero no cuesta mucho deducir que se trata de un concepto, algo vago y abierto, que recoge aquellas fabricas a las que se han aplicado las últimas tecnologías digitales incluyendo aspectos como robótica, impresión 3D, Internet de las cosas, inteligencia artificial o Big Data.

Se enmarca, pues, este concepto de Smart Factory, como un caso particular del también algo vago y abierto concepto de Transformación Digital llevado en esta ocasión al ámbito de la manufactura y, más específicamente, como caso particular del, de nuevo, abierto y ambiguo concepto de Industria 4.0.

No es sorprendente el informe en cuanto a sus conclusiones. Como es de imaginar, prevé un amplio crecimiento e implantación de este modelo de fábrica, y augura enormes crecimientos en productividad, eficiencia y beneficios para las compañías que lo implementen. No es, digo, sorprendente el informe, pero sí he tomado nota de tres elementos que me han llamado la atención.

Por un lado, me ha parecido atractivo e interesante el ‘Cap Gemini Factory Framework’, una suerte de estructuración de los elementos que componen una fábrica inteligente y que, de alguna manera, hace más concreta, tangible y ordenada, la propia idea de fábrica inteligente. El Framework es el que se muestra en la figura: 



Por desgracia, el informe muestra esta figura sin apenas explicación, por lo que me quedo con las ganas de entender mejor el modelo y la completitud y profundidad del mismo. A lo mejor vale la pena bucear por el ciberespacio en busca de una mayor descripción.

Otro aspecto, en este caso triste, pero no desconocido, es la estimación del grado de penetración de las fábricas inteligentes. Se trata del siguiente mapa: 



En él vemos que, como suele ser habitual, los mayores niveles de penetración se dan, por este orden, en Estados Unidos, Alemania, Francia, Reino Unido, Suecia, Italia, India y China. Sorprende, y mucho, el hecho de no ver representados a Japón, Corea o, en general, los denominados ‘tigres asiáticos’. Me resulta sospechosa esa exclusión que puede venir provocada, seguro que es así, por el método de elaboración del informe en que, como se reconoce al final del mismo, se han elegido ejecutivos de los países que aparecen destacados. Es decir, el propio informe lleva a que sean esos países de los que se tenga una estimación de penetración lo que creo constituye un error de método.

Lo que no sorprende, por desgracia, es no ver representada a España. El método del informe hace previsible esa exclusión pero, el hecho mismo de no entrevistar a ejecutivos españoles no deja de ser indicativo.

¿Dónde estaremos realmente nosotros?

Finalmente me quedo con el modelo de madurez digital que se propone, un modelo que, por común, no deja de ser ilustrativo. Recurren los autores del informe a la típica matriz de dos dimensiones y cuatro cuadrantes y eligen, en esta ocasión, como dimensiones, por un lado la intensidad de la aplicación de técnicas digitales (‘digital intensity’) y, por otro, la intensidad con la que la transformación ha conseguido la coherencia necesaria para proporcionar una visión clara del modelo de fábrica inteligente, implementar un gobierno, desarrollar las habilidades necesarias y, en definitiva, concretarse en beneficios (‘Transformation Management Intensity’).



Con base en esas dos dimensiones se definen cuatro cuadrantes y se deduce que el 78% de las empresas son todavía principiantes (niveles bajos de ambas dimensiones) y sólo el 6% son maestros digitales (niveles altos de ambas dimensiones). El resto se reparte entre un 15% de ‘conservadores’ (buena visión pero baja aplicación) y un exiguo 1% en que se da la situación, algo paradójica, de una alta aplicación de tecnología digital sin una clara visión (‘fashionistas’ o, a la moda).

Un concepto, el de Smart Factory, sin duda muy importante, aunque algo abierto y un informe que, sin sorprender, sí nos ayuda a conocer o intuir algunos elementos del desarrollo de esta potente idea.

miércoles, 9 de agosto de 2017

¿Necesidad o virtud? Una reflexión inesperada sobre Lean Startup y Agile


Hace tiempo que le doy vueltas al mérito relativo de las metodologías 'rápidas', basadas en acción y aprendizaje frente a las metodologías 'de planificación', que intentan establecer un plan que luego se sigue y monitoriza.

¿De qué metodologías hablo?

Pienso en dos ámbitos. 

Por una parte en lo relativo a la estrategia competitiva y el marketing estratégico. Las metodologías tradicionales exhiben unas herramientas de análisis y, tras la reflexión estratégica, se realiza el plan estratégico, con sus derivadas financieras y presupuestarias, que marcan el devenir de los siguientes años (bien es cierto que con revisión anual). En el ámbito del marketing, especialmente el marketing de producto, se trabajan las carteras de producto, los estudios de mercado, etc y se decide y planifica el lanzamiento de productos. 

Frente a esto, la muy popular metodología Lean Startup aboga por la prueba y error, por la definición del famosísimo Producto Mínimo Viable (MVP Minimun Viable Product) su pronto lanzamiento al mercado y el aprendizaje y corrección del rumbo en función de los resultados.

En el ámbito de la dirección de proyectos, especialmente proyectos de software, las metodologías tradicionales abogan por delimitar un alcance y luego, siguiendo unos ciclos bien definidos establecer un plan con actividades, responsables, recursos, costes e hitos. Un plan que luego se intenta seguir a rajatabla.

Por su parte, los métodos agile, más modernos (aunque ya llevan muchos años entre nosotros), abogan por la construcción incremental, es decir, definir un conjunto muy acotado de requisitos mediante las denominadas 'user stories', construrr lo así definido, desplegarlo y seguir aprendiendo, definiendo y construyendo en continuas iteraciones.

Hay, creo, una ineficiencia intrínseca en esos métodos de prueba y error y, sin embargo, son modelos de éxito, cada vez más populares, más aceptados.

¿Por qué? 

Creo que, en el fondo, esas metodologías 'rápidas' (evito decir ágiles para no confundir con el caso específico de 'agile') hacen de la necesidad virtud. La necesidad, en este caso, viene dada por la incapacidad humana para imaginar, prever y planificar a largo plazo. A veces, de manera perfectamente justificada, ya que, por ejemplo, el éxito de un producto en el mercado depende de muchos factores no controlables ni cognoscibles por el presunto planificador. En otros casos, menos justificable...pero probablemente igual de real, como cuando hablamos de proyectos internos de una compañía. La virtud, pues, estriba en reconocer esa realidad, esa incapacidad para ver y planificar el largo plazo y proponer unas metodologías que, sin dejar de gozar de un cierto rigor, se adaptan a esa incapacidad humana para el largo plazo.

Y todo esto, que no hace tanto comentaba brevemente con una colega del ámbito tecnológico, me lo encuentro, bien que de una forma mucho más ligera, en un campo bastante diferente, en concreto en el de las empresas sociales, leyendo el libro titulado, precisamente, 'Las empresas sociales' donde su autor, el Nóbel de la Paz Muhammad Yunus afirma:

La vida es demasiado complicada para cualquiera, por mucha visión de futuro que se tenga para predecir las contingencias.
Así que, no hay que tener miedo a ajustar el plan de negocio cuando las circunstancias lo hagan necesario.


¿Está Yunus abogando por Lean Startup? Probablemente no conscientemente (desde luego no lo menciona ni nada que se le parezca), pero en el fondo late la misma necesidad, la incapacidad para la previsión... y, como respuesta, el ajuste del plan de negocio, es decir, parecida virtud...

lunes, 7 de agosto de 2017

Los siete principios de la empresa social


Desde hace tiempo le vengo dando vueltas al razonamiento de que, realmente, la caridad, por loable e incluso admirable que resulte, no es la vía para resolver realmente los problemas sociales (hambre, pobreza, etc) que aquejan a la humanidad. Que se precisa, no sólo buena voluntad, sino también método, rigor, ciencia... Que lo que necesitamos, en definitiva, es aplicar las técnicas de gestión de las empresas privadas al ámbito de la acción social.

Y eso es, ni más ni menos, el significado de la empresa social.

Me encuentro leyendo el libro 'Las empresas sociales' de Muhammad Yunus, Premio Nóbel de la Paz y creador del concepto de los microcréditos.

En ese libro, en efecto, se define de esta forma sencilla y muy clara lo que es una empresa social: se trata de una empresa que...

su objetivo es resolver un problema social usando los métodos de los negocios.

Ni más ni menos. Pero un poco más adelante, tenemos algo más de detalle cuando  Muhammad Yunus menciona los siete principios de la empresa social, siete principios que elaboró con la colaboración de  Hans Reitz: Los principios que concluyeron son los siguientes:


  • El objetivo del negocio es superar la pobreza o resolver uno o más problemas que amenacen a la población y la sociedad (como educación, salud, acceso a la tecnología, medio ambiente), no maximizar beneficios.

  • La empresa logrará sostenibilidad financiera y económica.

  • Los inversores recuperarán sólo el dinero invertido. No recibirán ningún dividendo que supere la inversión original.

  • Cuando se devuelve la cantidad invertida, el beneficio permanece en la compañía para ampliación y mejoras.

  • La compañía será ambientalmente consciente

  • La mano de obra recibe un salario mejor que las condiciones de trabajo estándar

  • ¡¡¡ Hazlo con alegría !!!

Creo que, de estos principios, los que realmente caracterizan a la empresa social son los dos primeros, el hecho. que su objetivo es de naturaleza social y el segundo, que es el que realmente más las diferencia de la caridad tradicional o las ONG, a saber, la sostenibilidad económica. La empresa social genera ingresos suficientes para mantenerse sin necesidad de acudir a donaciones o fondos perdidos.

El tercer y cuarto principios, el hecho de que no se devuelven dividendos e intereses a los inversores y que el beneficio se reinvierta, creo que, más que definir la empresa social sirven como salvaguardas para que la empresa social no se desvíe de su objetivo y no se confunda con una empresa con ánimo de lucro tradicional.

El hecho de ser ambientalmente conscientes y el salario de la mano de obra creo que, de nuevo, más que definir lo que es una empresa social, son ejercicios de coherencia con las connotaciones éticas de este tipo de empresas.

En cuanto a la alegría... bueno, supongo que es difícil embarcarse en algo así sin una fuerte motivación...probablemente con alegría...

viernes, 4 de agosto de 2017

#macrotweet: acerca de la escalabilidad de las inspecciones de código

Ask a programmer to review ten lines of code, he'll find ten issues. Ask him to do five hundred lines, and he'll say it looks good.




Giray Özil
Mencionado en 'The DevOps Handbook'

miércoles, 2 de agosto de 2017

La justicia como palanca del aprendizaje y la innovación


Hace unos días hablábamos de la empatía como un mecanismo de eficiencia.

Hoy le toca a la justicia como mecanismo de aprendizaje e innovación.

¿A qué nos referimos?

Nos referimos a tratar 'justamente' a los empleados, a reconocer en su justa medida sus méritos y el alcance real de sus fracasos. El alcance real... y no tanto el alcance de las consecuencias de un eventual error, sino la 'culpabilidad' inherente, si es que, siquiera, hablar de culpabilidad tiene sentido.

En estos tiempos, a nivel de discurso, en los medios sociales, en las conferencias, en las comunicaciones corporativas, se 'entroniza' el error, como forma de aprendizaje e innovación

A nivel de discurso si, pero ¿Y en el día a día? ¿Se tolera realmente el error? ¿Se admite como algo humano y natural? ¿Se busca realmente más la causa que el culpable? ¿O preferimos abroncar y humillar al que se equivoca? ¿O, tal vez, encontrar un chivo expiatorio que nos libre de una responsabilidad más amplia?

No estoy seguro.

Y si, por una parte, entiendo algo exagerado y vacío el recurrente elogio del fracaso en el discurso oficial, por otra considero que debemos ser más tolerantes, mucho más tolerantes, con el pequeño error del día a día, no el de los discursos, sino el que observamos directamente a nuestro alrededor.

Sidney Dekker
Y no se trata sólo tolerancia, sino también de justicia, de justicia entendida como la mesurada y equilibrada asignación de responsabilidad en el error. 

Una organización que abronca a sus empleados, que los culpabiliza de cualquier error, es una organización que se paraliza y que se hace opaca. Si, además, la culpabilización es injusta, si 'pagan justos por pecadores', no sólo se enseñorea la parálisis sino que también cunde la desmoralización y el ocultismo.

Así se cuenta en 'The DevOps Handbook', citando a Sidney Dekker,  cuando nos habla del análisis forense, el análisis de problemas ya resueltos:

When responses to incidents and accidents are seen as injust, it can impede safety investigations, promoting fear rather than mindfulness in people who do safety-critical work, making organizations more bureaucratic rather than more careful, and cultivating professional secrecy, evasion and self-protection.

Si queremos promover el aprendizaje, necesitamos la trasparencia. Y la trasparencia es imposible en un ambiente de culpabilidad y de injusticia.

Si queremos que nuestros equipos y colaboradores sean creativos, innovadores, que propongan nuevas ideas y se atrevan con nuevos planteamientos, si queremos promover el aprendizaje organizativo y la innovación, hemos de eliminar la culpa, hemos de animar y facilitar y, para empezar, y como nivel mínimo, debemos ser justos.

Al menos, justos.

lunes, 31 de julio de 2017

DevOps versus Bimodal IT


Hace un tiempo, reflexionaba yo sobre la viabilidad de aplicar metodologías Agile de forma generalizada en una empresa compleja con un mapa de sistemas complejo.

Y mi sensación, que en el fondo todavía mantengo, es que la aplicabilidad de Agile no es el todo general, que los proyectos más complejos precisan algo más de planificación y visión a largo plazo, y un ciclo de vida que, al menos al principio, no se adapta a la velocidad y metodología de Agile. Pensaba yo que ciertos proyectos deben seguir una gestión de proyectos más tradicional (en general los más complejos y los que más determinan la arquitectura y mapa de sistemas) y otros, sin embargo, se beneficiaría de un enfoque agile (aquellos de planteamientos funcionales más sencillos, con mayor orientación hacia el cliente y con más peso en los aspectos de interfaz de usuario).

Y en eso descubrí el concepto de Bimodal IT, creado por Gartner y que se parecía mucho a lo que yo había pensado. Bimodal IT distingue, en efecto, dos tipos de proyectos y dos formas de gestionarlos. 

Los sistemas que se denominan 'sistemas de registro ('record systems'), es decir, los que soportan la columna vertebral de los procesos y datos corporativos, se gestionarían en el modo 1 según el modelo en cascada más tradicional y buscando sobre todo la fiabilidad. 

Los sistemas que denominan de relación ('engagement system'), los dedicados a interaccionar con el cliente y crear un vínculo con él, se gestionarían en el modo 2, que sería 'agile' y donde lo que primaría sería la velocidad y capacidad de respuesta.

Me encuentro ahora leyendo 'The DevOps Handbook' para profundizar en DevOps que, como ya vimos, es heredero de, aunque no se limita a, la filosofía agile. Y veo que uno de sus autores, Jez Humble, hace poco más de un año dedicó en su blog, 'Continuous Delivery', un post en que criticaba esa filosofía promovida por Gartner.

Tres son los argumentos que esgrime Jez Humble en contra de Bimodal IT

  • Reduccionismo: Opina Humble que es una simplificación el pensar que con esos dos modos se resuelve toda la problemática.

  • Acoplamiento entre los sistemas de registro y los de interacción: Afirma en este sentido Humble que la modificación de un sistema de relación (modo 2) suele precisar de modificaciones en los sistemas de registro (modo 1), por lo que no es correcta una separación drástica entre ambos tipos de sistemas y entre ambos modos.

  • La fiabilidad no está reñida con la velocidad: Aquí, Humble va más allá y, por decirlo de alguna manera, 'niega la mayor': no es cierto que la fiabilidad esté reñida con el tiempo de respuesta. Jez Humble entiende que DevOps da respuesta a ambas necesidades y, por tanto, no es necesaria la famosa gestión bimodal.

Jez Humble en acción
Finaliza Humble su artículo en un tono algo más conciliador y entreve que, quizá, la gestión bimodal sea útil como un primer paso, en el caso de empresas con una gestión muy tradicional, para acercarse a DevOps. Un primer paso que en opinión de Humble no puede exceder de unos meses.

Un debate, en cualquier caso, muy interesante y más que necesario y realista. Mi experiencia me lleva a estar más cerca del modelo de Gartner... y mi esperanza a estar más cerca de Jez Humble y DevOps.

¿Conclusión?

Supongo que no hay otra: debemos aspirar al modelo DevOps, pero ser muy realistas y cuidadosos en la transición... y ser muy conscientes de la realidad (la realidad, no la aspiración) de nuestras compañías. Quizá no estemos tan cerca de un DevOps o un Agile como quisiéramos...

viernes, 28 de julio de 2017

La prueba del algodón de la Customer Experience


Ahora que tan de moda está la así llamada 'Customer Experience', ahora que se aboga tanto por construir experiencias memorables y por apelar a la simplicidad y la emoción, corremos el riesgo de construir metodologías de laboratorio, formular complejas teorías, olvidarnos realmente de lo esencial.

Lo esencial es el cliente, lo esencial es el usuario.

Y lo que éste necesita o desea puede ser mucho más sencillo de lo que se puede imaginar desde un laboratorio o, en cualquier caso, es fácil que sea distinto.

Si queremos conseguir una excelente experiencia de cliente o de usuario no nos retiremos al laboratorio. nos nos aislemos. Hablemos con él o, incluso mejor, observemosle, veamos cómo usa un sistema o producto, cómo interacciona con él, qué espera...

Así se nos recomienda en 'The DevOps Handbook', abogando por la técnica del contextual enquiry, cuando se nos dice:

One of the most powerful techniques in interaction and user experience design (UX) is contextual inquiry. This is when the product team watches a customer use the application in their natural environment, often working at their desk.

He tenido personalmente la experiencia de comparar lo que uno se imaginaba, con la mejor de las intenciones, en un laboratorio, con lo que un verdadero usuario esperaba. Una experiencia más que reveladora, una lección inolvidable. 

La experiencia de cliente empieza y acaba en el cliente.

¿Por qué buscarla en otro sitio?

miércoles, 26 de julio de 2017

En Pulse: La sonrisa triste


Sonrío.

Y la sonrisa puede tener muchos significados.

Puede ser el reconocimiento espontáneo de una agudeza, de un ingenio, de un chisporroteo de inteligencia.

Sonrío con cariño mal disimulado ante la inocencia de una niña de significado especial que despliega ingenuidad o simplemente espontaneidad.

Sonrío ante lo cercano, lo conocido, lo entrañable.

Pero a veces, sólo a veces, un velo tenue tiñe de sombras tristes esa sonrisa.

Sonrío tristemente ante el reconocimiento casi cómico de esas pequeñas miserias tan entrañables por tan conocidas, tan conocidas por tan frecuentes, tan frecuentes que las hacen aún más tristes…

Sonrío tristemente al leer en ‘The DevOps Handbook’ la siguiente argumentación:

Examples of ineffective quality controls include:
  • Requiring another team to complete tedious, error-prone, and manual tasks that could be easily automated and run as needed by the team who needs the work performed.
  • Requiring approvals from busy people who are distant from the work, forcing them to make decisions without an adequate knowledge of the work or potential implications, or to merely rubber stamp their approvals.
  • Creating large volumes of documentation of questionable detail which become obsolete shortly after they are written.
  • Pushing large batches of work to teams and special committees for approval and processing and then waiting for responses.

Sonrío tristemente ante lo entrañable, ante lo conocido, ante lo frecuente...

Pero antes de que el abatimiento borre definitivamente la sonrisa, me acuerdo de niñas especiales y del deber y aspiración a la educación, la enseñanza y la transformación.

Entreveo caminos y opciones, proyectos y ambiciones, mejora y transformación, digital o no.

Una luz brillante disuelve los últimos velos y mi sonrisa, más profunda, más franca, más abierta, celebra el triunfo de la posibilidad, la voluntad y la inteligencia.

*****
Artículo publicado en Pulse el 25/07/2017
Pulse es el servicio de noticias personalizadas de la red social profesional LinkedIn

martes, 25 de julio de 2017

Colaboración: “Las smart cities aúnan lo social, lo económico y la sostenibilidad” en 'A un CLIC de las TIC'


El pasado Jueves 20 de Julio se publicaba en A un CLIC de las TIC, el blog de la unidad de Grandes Clientes de Telefónica, el artículo titulado "Las smart cities aúnan lo social, lo económico y la sostenibilidad".

El artículo consiste en una entrevista a Marieta del Rivero sobre su libro titulado 'Smart Cities: una visión para el ciudadano', publicado por LID Editorial y, quizá más importante, sobre el propio concepto de Smart City y la visión de la autora sobre el mismo.

La entrevista estuvo precedida, unos días antes, por un encuentro personal con la autora, un encuentro muy agradable en lo personal y muy interesante en lo profesional.

El resultado, este artículo "Las smart cities aúnan lo social, lo económico y la sostenibilidad" que espero os animéis a leer.


lunes, 24 de julio de 2017

Tres interesantes patrones de gestión de sistemas


A aquellos que estén familiarizados con el diseño software, especialmente el diseño orientado a objetos, les resultará seguramente familiar el término 'patrones de diseño'. Un patrón de diseño es algo así como un diseño genérico, un modelo de diseño repetitivo. una buena solución 'ya enlatada' para un problema común de diseño software.

Los patrones de diseño se hicieron populares (y tremendamente útiles) a partir del afamado libro 'Design Patterns. Elements of Reusable Object-Oriented Software' de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. El libro, debo decirlo, con el que creo que más aprendí de diseño orientado a objetos en su momento (un momento algo lejano ya).

Pero los patrones no tiene por qué limitarse a diseño de software orientados a objetos. Siempre que existan unas problemáticas frecuentes y similares en cualquier ámbito, y siempre que identifiquemos un tipo de solución válida para ese tipo de problemáticas, nos encontraremos ante un patrón.

Leyendo 'The DevOps Handbook' me encuentro con esta misma palabra, patrón ('pattern'), pero en un ámbito diferente, aunque todavía dentro del mundo del software. Se trata de tres patrones que tienen que ver más con la arquitectura y explotación de sistemas que con la ingeniería del software.

En el caso de los dos primeros patrones, el problema a resolver es cómo conseguir un despliegue frecuente (idealmente continuo) de nuevo software en producción con un riesgo tolerable. Para este problema, se nos proponen dos patrones: 'feature toggles' y 'dark launching' que, por cierto, pueden ser complementarios.

'Feature toggles' (conmutadores de características) consiste en dotar al sistema de unos elementos de configuración (por ejemplo vía fichero XML o JSON) que permitan realizar activación/desactivación o la apertura de las nuevas funcionalidades de forma controlada. Por ejemplo, se puede controlar a qué usuarios se les permite o no el acceso a la funcionalidad reciente, implementando políticas de número crecientes de usuarios como podría ser: al principio sólo el equipo de desarrollo, luego los usuarios de la compañía proveedora del servicio, luego un número limitado de clientes y, finalmente, toda la planta de clientes. También se puede utilizar para desactivar completamente una funcionalidad que se ha mostrado defectuosa o no escalable.

'Dark launching' (lanzamiento opaco) habla de desplegar en entorno de producción software y funcionalidad pero de modo que no son visibles para los usuarios finales, ya sea porque está desactivadas para ellos, ya sea porque no producen ninguna manifestación visible sino sólo trabajo en 'background' (por ejemplo, medidas y obtención de KPIs). En la sombra, el equipo de proveedor del servicio puede trabajar comprobando el funcionamiento correcto y las prestaciones y escalabilidad, antes de decidirse a desplegar 'en abierto'. Este patrón pude apoyarse en el de 'feature toggles' ya que pueden ser esos conmutadores de características lo que nos sirva para mantener la nueva funcionalidad como 'opaca'. 

El tercer patrón cambia de tercio y se centra ahora más en una solución de arquitectura para permitir desplegar una nueva tecnología conviviendo con otra legacy.

'Strangler application' (estrangulador de aplicaciones') lo que propone es, simplemente, recubrir el 'legacy con un API, de forma que se concentre ahí toda la interacción entre la nueva tecnología o aplicación y la legada. De esta forma, se reduce drásticamente el acoplamiento entre ambas y se habilita una relativamente sencilla eliminación de la aplicación legada, si así lo decidimos, mediante una nueva implementación del API que recubría al legado. La re-implementación de esa API puede incluso, ser gradual, resultando en cualquier caso trasparente el ritmo de sustitución para la nueva tecnología o aplicación.



Probablemente, aquellos lectores duchos en ingeniería software y con experiencia real con sistemas reconozcan estos patrones, incluso aunque puedan no haber oído nunca el nombre que se les aplica. En mi caso particular, puedo decir que, en efecto, he conocido las tres estrategias en la práctica, aunque hasta ahora no las había catalogado como patrón ni conocía el nombre que las denomina.

Es lo que tienen los patrones: son soluciones comunes, y muchos profesionales probablemente han llegado a y aplicado las mismas conclusiones, incluso sin saber que otros colegas hacían lo mismo en otras compañías o proyectos.

El identificarlos como patrones hacen más fácil, sin embargo, entenderlos, comunicarlos  e identificarlos la próxima vez.

Y con ese espíritu, y por lo que pueda ayudar, he escrito este post.

viernes, 21 de julio de 2017

Entender el trabajo del desarrollo software


La tecnología es bella y absorbente en sí misma.

Y el desarrollo software es bello y absorbente en sí mismo. Prendados de la belleza del propio software, entusiasmados por el desafío que significa hacer un programa o implementar una nueva tecnología, los desarrolladores profesionales pueden a veces olvidarse de cuál es el verdadero sentido de su trabajo.

El desarrollo software profesional rara vez es un objetivo en sí mismo. Está al servicio del negocio. Sirve para crear un producto vendible, o para automatizar procesos, o para disponer de un canal de relación con clientes, o para integrarse con proveedores, o para medir la actividad, o para... 

Una tecnología, por atractiva y elegante que resulte para el desarrollador, no es un fin si no está al servicio de los objetivos del negocio, si no nos ayuda a conseguirlos o mejorarlos.

Puede resultar algo triste para el desarrollador más vocacional...pero es así. Y mejor tenerlo claro.

En el libro 'The DevOps Handbook' se menciona a Randy Shoup, antiguo director de ingeniería de Google. Cuando describe el ambiente en el equipo que desarrolló Google App Engine dice:

everyone knew that our job was not to 'write code' but it was 'run a service'.

Esa es justo la idea. El trabajo no es hacer código por sí mismo, sino disponer de un servicio.

Si en Google lo tienen claro, el resto también puede ¿no?

miércoles, 19 de julio de 2017

La empatía que conduce a la eficiencia


La empatía es una virtud muy humana, una virtud que, en el mundo profesional, relacionamos con la comunicación, con el 'engagement', quizá con el liderazgo...pero pocas veces se nos habrá ocurrido ponerla en relación con algo tan'árido', tan aparentemente maquinal como es la eficiencia ¿verdad?

Pues a lo mejor tenemos que cambiar de opinión. Leyendo en 'The DevOps Handbook' algo más de detalle sobre los tres caminos de DevOps, y en concreto sobre el primero, el que promueve el paso rápido entre el desarrollo y la operación, en busca de la agilidad y calidad,  me encuentro la siguiente afirmación:

According to Lean, our most important customer is our next step downstream. Optimizing our work for them requires that we have empathy for their problems in order to better identify the design problems that prevent fast and smooth flow.

Según los principios de Lean, adoptados por DevOps, cada elemento de la cadena productiva de tecnología debe estar pendiente del siguiente eslabón, pero no de una forma mecanicista, más propia de una cadena industrial tradicional, sino de una forma empática, es decir, entendiendo y anticipándose a los problemas que el siguiente del equipo se puede encontrar. Si esta empatía existe, se harán todos los esfuerzos por evitar problemas al siguiente eslabón y, de esta forma, se ganará agilidad, se eliminarán retrabajos y, en conjunto, se ganará eficiencia.

Tal vez, lo humano sea eficiente o, quizá, ya que somos humanos, hemos de tratarnos como tal si queremos sacar lo mejor de nosotros... y obtener frutos de eficiencia y calidad.

lunes, 17 de julio de 2017

Dónde ahorra Lean Manufacturing... y mucho más


A modo de recordatorio y para inventario.

Me interesa ir reuniendo los diversos aspectos que hemos de buscar en un proceso de negocio para poder mejorarlo. Así que apunto las fuentes que apuntan temas a vigilar en un proceso para hacerlo más óptimo.

Leyendo 'The DevOps Handbook' me encuentro una referencia a Lean Manufacturing que conviene recordar. No es extraña esta referencia dado que, como veíamos hace poco, Lean Management es un claro antecedente de DevOps.

Uno de los 'mantra' de Lean Manufacturing es la eliminación del desperdicio, 'muda', todo aquello que no aporta valor final. En el libro sobre DevOps nos recuerdan los siete tipos de desperdicio que identifica Lean Manufacturing.

Son éstos:
  • Inventario
  • Exceso de producción
  • Procesado extra
  • Transporte
  • Esperas
  • Movimiento
  • Defectos
Sin duda, cada apartado merece un largo tratamiento en sí mismo, pero de momento queda a modo de apunte, de recordatorio, y para añadir al censo de cosas a vigilar o mejorar en procesos de negocio, en este caso, de fabricación.

Aproximadamente esto mismo lo vimos hace ya más de tres años en el artículo que titulamos 'Aplicando los principios lean al mundo del software: 7 fuentes de desperdicio a eliminar', pero me ha parecido interesante revisitarlos.

Además, la ocasión me sirve de 'excusa' para reunir los artículos que he publicado en este blog, basados en diversas fuentes, pero que identifican puntos generales de mejora en un proceso de negocio... y quizá ese sea el mayor interés de todo el artículo...

Otros artículos relacionados (censo de mejoras en procesos de negocio)

viernes, 14 de julio de 2017

Los tres caminos de DevOps


Tres son tres los caminos que sigue DevOps para conseguir sus objetivos de agilidad y calidad.

Tres caminos que nos describen Gene Kim, Jez Humble, Patrick Debois y John Wilis en su libro 'The DevOps Handbook'.

Se trata de los tres caminos que se muestran en la figura:

El primer camino es el que va linealmente desde el desarrollo (Dev) a la Operación (Ops) y finalmente al cliente y se esfuerza en la agilidad. En este camino nos esforzamos en reducir el tamaño de lotes y los intervalos de trabajo y en evitar que los defectos viajen aguas abajo.

El segundo camino proporciona un feedback continuo aguas arriba con el objetivo de evitar repetir problemas ya conocidos o posibilitar una detección y recuperación más temprana.

El tercer camino tiene que ver con el aprendizaje continuo, con una cultura de alta confianza que soporta el riesgo y la experimentación.

Tres son tres los caminos... y grande la transformación.

miércoles, 12 de julio de 2017

Las influencias de DevOps: Lean y Agile.


Cuando hablamos de música, de literatura, de artistas, muchas veces los eruditos o los propios artistas disertan sobre sus influencias, sobre aquellos otros personajes que han marcado y moldeado de alguna forma, su manera de interpretar el arte.

No se trata de arte (¿o tal vez si?) pero en metodologías y técnicas de gestión también se producen influencias, una suerte de polinización cruzada entre ámbitos de gestión, sectores y gurús que hacen nacer cosas nuevas a partir de hallazgos anteriores.

Un caso que podría ser claro al respecto es DevOps, una forma de gestión de la TI que nace integrando enseñanzas de oras disciplinas y ámbitos más o menos cercanos  que busca la agilidad y la calidad integrando el mundo del desarrollo y la operación TI..

Me encuentro inmerso en la lectura de 'The DevOps Handbook', escrito por Gene Kim, Jez Humble, Patrick Debois y John Wilis y en sus primeros pasos nos hablan de alguna de esas influencias.

La primera es Lean Manamegement, una filosofía de gestión nacida en Toyota en su famoso TPS (Toyota Production System) cuya obsesión es la eliminación de los desperdicios ('muda') es decir, de todo aquello que no aporta valor, mediante una revisión y vigilancia continua del proceso.

Así no explican los autores esta influencia:

DevOps is the result of applying Lean principles to the technology value stream

Y también:

DevOps is the outcome of applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream.


La otra influencia viene ya del propio mundo del TI y se trata de Agile, esa filosofía de gestión de proyectos software que busca los desarrollos rápidos e incrementales con alta participación del cliente/usuario:

many also view DevOps as the logical continuation of the Agile software journey that began in 2001.

No es extraña la convergencia de ambas influencias. Al fin y al cabo, una de las metodologías Agile es precisamente Lean y otra es Kanban, con la misma ascendencia de las técnicas japonesas de mejora continua y calidad total.

No es extraña tampoco esa convergencia si se tiene en cuenta que DevOps intenta aunar los esfuerzos de desarrollo (más anclados en técnicas de dirección de proyectos, como Agile) con la operación (lo que ofrece más cercanía con filosofías tipo Lean)

Y, al final, ¿que se obtiene de todo esto? Pues el objetivo no está falto de ambición. Así nos lo explican los autores:

Lean principles focus on how to create value for customer through systems thinking by creating constancy of purpose, embrace scientific thinking, creating flow and pull (versus push), assuring quality at the source, leading with humility, and respecting every individual.

Valor, pensamiento científico, propósito, flujo, calidad, liderazgo y respeto. Casi nada al aparato.

En siguientes artículos veremos algunos aspectos de cómo DevOps se articula para intentar conseguir tan exigentes expectativas.

lunes, 10 de julio de 2017

Deuda técnica


La deuda no es mala por sí misma.

Endeudarse es una forma de obtener recursos y con base en ellos impulsar nuestro negocio o nuestra vida. Mediante la deuda podemos afrontar iniciativas que, tal vez sin ella, fuesen imposibles. Nos endeudamos como personas, 'nos hipotecamos', para comprar una casa que difícilmente podríamos pagar al contado, o para permitirnos unos estudios o quizá un coche. Nos endeudamos como empresa para invertir en proyectos de futuro: una expansión internacional, una nueva línea de productos, una nueva tecnología productiva, unas nuevas infraestructuras...

La deuda proporciona lo que se denomina el apalancamiento financiero, y la palabra apalancamiento nos sugiere impulso, potenciación de capacidades. Y es así, sin el capital que se nos aporta al contraer una deuda, no podríamos imaginar llevar a cabo ciertos proyectos.

No. La deuda no es mala en sí misma. No es mala siempre que se gestione responsablemente, siempre que se mantenga en límites asumibles, siempre que seamos capaces de saldarla, siempre que la controlemos y no seamos controlados por ella.

Pero no sólo existe deuda financiera.

En el ámbito de las tecnologías de la información, Ward Cunningham acuñó el término deuda técnica, algo así como problemas latentes que creamos por decisiones erróneas o cortoplacistas y que, poco a poco comprometen la evolución de nuestra TI.

Esta es su explicación según es citada en 'The DevOps Handbook' de Gene Kim, Jez Humble, Patrick Debois y John Willis:

technical debt describes how decissions we make lead to problems that get increasingly more difficult to fix over time, continually reducing our available options in the future- even when taken on judiciously, we still incur interest.

¿Tampoco es mala la deuda técnica? ¿La podemos considerar un apalancamiento?

La verdad es que creo que la deuda técnica es fundamentalmente negativa. Suele responder a errores o falta de visión o planificación a medio/largo plazo.

En algunos casos particulares podría considerarse como un apalancamiento: situaciones en que adoptamos una solución no óptima a corto plazo, para tener resultados más rápido. Quizá, por ejemplo, en lugar de renovar sistemas para adaptarse a una nueva tecnología o arquitectura, construimos una capa sobre los existentes que 'simulan' esa adaptación.  El problema es que, rara vez se gestiona la deuda. Rara vez, eliminamos la capa que creamos como solución a corto para realizar la verdadera renovación. Rara vez, en definitiva saldamos la deuda contraída. Muchas veces ni siquiera recordamos haberla contraído. 

Por desgracia, la deuda técnica no suele controlarse sino que aumenta y aumenta... aumenta sin medida hasta que es preciso un 'rescate'.. o una desaparición.

viernes, 7 de julio de 2017

La realidad aumentada explicada por Alan B. Craig

'Understanding augmented reality' es una revisión amplia de los conceptos y estado del arte de la realidad aumentada, una disciplina que el autor define como 'un medio' más que una tecnología, resaltando el hecho de que combina muchas tecnologías, que éstas pueden evolucionar sin que sin embargo el concepto de realidad aumentada varíe, y de que lo más importante es el contenido, aquello que se transmite mediante técnicas de realidad aumentada.

El tratamiento es muy ordenado y sistemático, a veces incluso ligeremente aburrido, y con ello se tiene al menos la aparente tranquilidad de no haber dejado ningún punto imporante sin tratar.

El libro se estructura en nueve capítulos:
  • 'What is aumented reality?': propone la definición de realidad aumentada como un medio, hace un brillante repaso histórico de cómo hemos alcanzado el concepto actual de realidad aumentada y pone la realidad aumentada en relación con otras tecnologías.

  • 'Augmented reality concepts': habla de los principales elementos y conceptos presentes en una solución de realidad aumentada incluyendo los sensores, el procesador y los visualizadores.

  • 'Augmented reality hardware': Hace un muy sistemático repaso por el hardware necesario y su estado del arte siguiendo el mismo orden que en el capítulo anterior, a saber, sensores, procesador y visualizadores.

  • 'Augmented reality software': Toca ahora el turno para el repaso del software, una materia que ordena en cuatro apartados, software directamente involucrado en la aplicación de realidad aumentada, software usado para crear la aplicación, software usado para crear contenido y otros tipos de software

  • 'Content is key! Augmented reality content': defiende la importancia del contenido para cualquier aplicación de realidad aumentada y repasa algunas ideas como los diferentes tipos de contenidos para los diferentes sentidos, la creación estática o dinámica de contenidos, etc

  • 'Interaction in augmented reality': se centra ahora en la interacción del usuario con la aplicación y aborda temas como la comunicación, la navegación o los entornos multipersona

  • 'Mobile augmented reality': hace foco brevemente en el uso de los dispositivos móviles para soportar aplicaciones de realidad aumentada, con sus ventajas y limitaciones, y los tipos de arquitecturas aplicables.

  • 'Augmented reality aplications': Propone una tipología de aplicaciones de realidad aumentada e identifica áreas de uso.

  • 'The future of augmented reality': Hace una prospección de lo que el futuro puede deparar a la realidad aumentada, repasando primero el estado en cuanto a aplicaciones, tecnología y desarrollo de contenidos para, a continuación, identificar una serie de tendencias de índole general.

'Understanding augmented reality' es un tratado serio, riguroso y abarcador de esta disciplina, muy ordenado en su desarrollo, abundantemente acompañado por fotografías y esquemas para ayudar a entender o visualizar aquello que se explica, no profundamente técnico aunque sin eludir tampoco la tecnología y, en general, de muy buena factura. El único pero sea, tal vez, el tono tan plano de la exposición a la que se le echaría en falta un puntito de pasión u originalidad para el tratamiento de un tema tan atractivo.

En cualquier caso, una más que buena referencia.

Alan B. Craig

(Fuente: Traducción y ligera elaboración propia de su perfil en la página oficial del libro 'Understanding Augmented Reality'.)

Alan B. Craig
El doctor Alan B. Craig ha estado en el National Center for Supercomputing Applications (NCSA) durante más de 25 años. Además, es Director Asociado de interacción hombre-máquina en el Institute for Computing in Humanities, Arts, and Social Science (I-CHASS). Es también el interlocutor acerca de humanidades, arte y ciencias sociales del Extreme Science and Engineering Discovery Environment (XSEDE).

El doctor Craig no es nuevo en el mundo de la escritura. Además de 'Understanding augmented reality', también ha escrito 'Understanding Virtual Reality' con William R. Sherman. Ha escrito numerosos capítulos de libros y artículos. Habla nacional e internacionalmente sobre una variedad de materias a audiencias que van desde las académicas a la administración o la industria.

A lo largo de su carrera ha estado implicado en el desarrollo y estudio de muchas tecnologías y conceptos, incluyendo la realidad virtual, realidad aumentada, visualización científica, computación de altas prestaciones, sistemas colaborativos, data mining y sistemas web. Le han sido concedidas 3 patentes americanas por sus innovaciones. Además de su trabajo en representación visual de la información, el doctor Craig has estado fuertemente implicado en el uso del sonido para representar datos, así como en sistemas multimodales. Su trabajo ha abarcado todo el continuo de la realidad, desde lo real a lo digital y vuelta a lo digital a través de la invención personal, así como en la frontera entre ambos mundos. En todos sus empeños se ha enfocado fundamentalmente en aplicaciones relacionadas con la educación.

Más allá de su vida profesional, el doctor Craig ha estado implicado en numerosos otros empeños creativos, concentrándose fundamentalmente en la escritura, grabación e interpretación de música.

Puedes saber más acerca del autor visitando su perfil en I-CHASS.

miércoles, 5 de julio de 2017

Tendencias en realidad aumentada


Vamos a ir cerrando la serie de posts dedicados a realidad aumentada inspirados en la lectura del libro 'Understanding Augmented Reality' de Alan B. Craig.

Antes de echar ese cierre con una reseña del libro, vamos a repasar brevemente las tendencias que al autor apunta para la realidad aumentada. Cabe advertir que el libro está escrito en 2013 así que pudieran estar ligeramente desactualizadas pero creo que, en realidad, son bastante actuales.

Éstas son las tendencias apuntadas:

  • Aplicaciones de realidad aumentada móvil

  • Marcadores de referencia (fiducial markers) especializados. Los marcadores de referencia ayudan a orientarse a las aplicaciones de realidad aumentada, especialmente a su 'visión'. El autor prevé nuevos tipos de marcadores, más naturales, incluyendo marcadores del tipo del 'skyline' de una ciudad

  • Trazado mejorado y tecnologías de trazado híbridas como, por ejemplo, la combinación de GPS con trazado óptico.

  • Menos estorbos, es decir, uso de pantallas en lentillas, sensores más pequeños y ligeros, etc de forma que el usuario se sienta más libre, más natural...

  • Uso de más sentidos, desplazando algo del foco actual en lo visual hacia el olfato, el tacto, etc

  • Visualizadores y representaciones de más alta fidelidad.

  • Sistemas de proyección, Es decir, no tanto que el usuario vea la realidad aumentada sino que la proyecte lo que soportaría, por ejemplo, múltiples participantes en la experiencia.

  • Mayor control sobre el mundo real, es decir usar menos botones y dispositivos y emplear más el propio mundo real para controlar la experiencia.

  • Aplicaciones privadas y multipersona.

  • Aplicaciones que pueden cambiar de contenido, es decir, aplicaciones más genéricas pero que pueden aplicarse sobre contenido diferente de forma sencilla.

  • Repositorios de contenidos y aplicaciones de realidad aumentada

  • Más áreas de aplicación.

  • Contenido ubícuo y canales de 'aumento'.

  • Nuevos mecanismos de descubrimiento de contenido aumentado, es decir, que el usuario puede 'descubrir' que hay contenido disponible sin necesidad de saberlo previamente.

  • Herramientas de edición más simples de usar

  • Atención a discapacitados.

  • Mejoras y más formales mecanismos de evaluación de las experiencias aumentadas.

Muchas tendencias, y todas bastante razonables. Algunas, como lo de la movilidad, parecen confirmarse. iremos viendo las otras...