Spotify y su cambio de política - ¿Pedir disculpas es suficiente?

¿Se han fijado como las empresas hacen cosas para ver qué pasa de forma improvisada, casual o planificada? Este es un post breve al respecto para reflexionar sobre este asunto. 

Todo surge porque hace unos días atrás, pudimos darnos cuenta de cómo algunas empresas son capaces de crear situaciones en donde se reacciona según sean valoradas por los usuarios, y con reacciones de las empresas que pueden ir desde una simple disculpa hasta “dejar que pase lo que tenga que pasar”. 

La empresa que da el ejemplo de esta declaración que hago es nada menos que la ya muy conocida plataforma de Spotify, conocida por su servicio de música digital. 

A esta empresa se le ocurrió pedir a sus usuarios registrados permiso para acceder a sus fotos y sus contactos. Por supuesto la reacción del público que los sigue no se hizo esperar: rechazo en redes sociales, el suficiente como para fuera noticia.

Spotify no accederá a datos personales si el usuario no quiere (fuente: europapress)

Y es que, seguramente saltaba la duda principal, "¿cómo para que quieren mis fotos y contactos en las redes sociales las empresas?" 

La política de privacidad nueva no fue precisamente bien aceptada por los usuarios de la página, y es que ella permitía a Spotify entrar a la cuenta de Facebook de los usuarios para compartirla. Y ésto, aparte de las quejas, produjo muchas desafiliaciones a Spotify. 

Si bien la cantidad de bajas no fue trascendental, fue motivo de preocupación para los fundadores de Spotify, los cuales pidieron una disculpa a sus usuarios por la nueva disposición en su política de privacidad. Spotify argumentó que hubo mucha confusión sobre lo que podían hacer con el conocimiento de la información que tomaban de los usuarios, pero ¿es suficiente una post aclaración? 

La idea desde Spotify era darle una mejor experiencia al usuario al personalizar futuros productos de su plataforma. Por ejemplo, se menciona una actualización que lleva por nombre Spotify Running, la cual usa GPS para medir la velocidad en carreras y lo que en teoría hará es acompasar el repertorio de tú música al ritmo del ejercicio. 

Además, aclara Spotify, que se le pide al usuario permiso sobre el registro a través de Facebook, es decir el registro mediante la red social es opcional. Y que para quienes lo hagan, se les reiteran que los datos serán usados únicamente para la configuración de una experiencia más personalizada en Spotify. 

A pesar de haber otorgado una disculpa por la nueva política, la política sigue allí. 

No debato el beneficio de mejorar la experiencia, ni tampoco que se preguntará al usuario si desea que se accedan a sus datos. Tampoco desmerece la aclaración de Spotify de que "comunicaron mal el cambio". 

El asunto es que este tipo de prácticas o experiencias deben planificarse, preverse y hay que estar preparados. No debe abusarse del "veamos que pasa". Es un juego delicado. 

Pero aparte de este análisis rápido, la cuestión es que en un mundo donde las personas estamos hiperconectadas, toda empresa debe observar y analizar las consecuencias de cada uno de sus actos. Y, lo más importante, hay que aceptar que llegará un momento en que "pedir disculpas no será suficiente" dentro de las políticas de marketing y de comunicación.

Madurez TIC: qué ocurre cuando dicen "No hay sistema" / un caso de Informática de Gestión

¿Qué puede hacer una empresa si se caen sus sistemas informáticos de atención al cliente? A mi parecer, tecnológicamente es posible, organizacionalmente es impensable, ni siquiera imposible. Estas situaciones muestran que no es lo mismo invertir en tecnología versus invertir en renovarse. 

Enfatizo que hoy en día, una organización puede invertir mucho en tecnología, pero si no sabe gestionarla como parte del camino al éxito, es como una organización del siglo pasado. 

Ya les cuento lo que pasó, pero si quiero invitar a reflexionar sobre lo que se entiende por Madurez TIC. 

Esta semana fuí a un reconocido Banco en Ecuador. No era cliente y me tocó la fila de no-clientes. Por supuesto era larga, porque además era horario de media-mañana, o sea horario en que se pagan facturas y cuentas de servicios. Por diversos motivos que no cabe analizar, aún son horarios en que por cada persona, se realizan muchos pagos. Bueno, dejemos esto del tiempo que me esperaba en la fila. 

En un momento determinado comenzó un extraño movimiento en la fila. Me fijé que en la zona de cajas las personas no eran atendidas. En ese momento un guardia privado, es decir, que no es empleado del banco sino de una empresa externa de seguridad dice: "No hay sistema". En ese momento comencé a observar con calma.

Los guardias, sin preparación obvia para estas situaciones, repetían insistentemente "No hay sistema" como si fuera la expresión mágica que todo lo resuelve ante la ya notoria molestia de las personas. 

¿Pero porqué la molestia? No quiero decir que un cliente que pierde tiempo en una fila, es menor, sino aclarar que la molestia era mayor por otra razón lógica. Resulta que ese día, un lunes y en horario de mañana, debían pagarse determinados trámites de una entidad pública. Por supuesto el trámite exigido indicaba que se pagaba ese día y punto. Ya entenderán que muchas personas querían hacer ese trámite, que era de pago y su desesperación aumentaba pues el tiempo pasaba y veían que no pagaban y en varios casos debían volver a sus trabajos en un tiempo cada vez menor.

Conforme pasaba el tiempo, se constató que el sistema no estaba caído. No había conexión informática entre el sistema de la entidad pública que requería el pago "ese día" y el banco. 

A estas alturas los guardias privados estaban molestos ¿de qué? Los guardias privados se terminaron molestando porque recibían las quejas y consultas del cliente. su paciencia obviamente es menor a la de un empleado bancario. 

Del banco no había nadie presente y los guardias pasaron de vigilantes de seguridad a incomodados funcionarios bancarios de atención al cliente. En términos económicos ya me quedaba claro que el banco debe revisar sus principios de cómo dar valor a sus inversiones. Si contrata una empresa de seguridad para que terminen atendiendo clientes y resolviendo sus problemas de operación en caja, tienen un serio problema de manejo económico pues están perdiendo dinero. 

Los guardias "por mejor" y al intuir que no estaba "todo caído", decían a los clientes que más reclamaban que se saltaran la fila y fueran directo a hablar en caja. Quienes respetábamos la fila por supuesto vimos que muchas personas comenzaron a ser atendidas. A eso llaman "viveza criolla", "ser pilas", etc. pero muestra que aún en algunas organizaciones existe una incultura de gestión de problemas y pésima gestión de clientes. 

En un momento me preguntan que trámite yo haría. Como no era un trámite de esa entidad pública con la cual había un problema informático, me invitan a saltarme la fila con otras personas y al final los guardias privados organizan por entropía más que por organización, 4 filas en paralelo a la fila oficial donde por supuesto aún quedaban personas. Esas 4 filas no siguieron el orden de la fila original. 

Ya habían pasado más de media hora.Bueno a estas alturas, hacía mucho rato me fijé que llevaba como 40 minutos. Y nadie del Banco. 

Por supuesto los guardias privados eran cautivos del problema. En la nueva fila que me tocó, escuché a las cajeras preguntando a los clientes que llegaban a la ventanilla, cuál trámite querían hacer y que -ojo- verían si las cosas funcionaban. 

Los clientes pasamos de la incertidumbre informacional a la incerteza comunicacional. 

Llegó mi turno y "por suerte" había conexión y mi trámite duró muy poco. 

Con esta historia se me vienen varios pensamientos:

• Si hay tanta inversión en tecnología en ese banco y con claras intenciones gubernamentales de interoperar, ¿porqué el banco y las entidades públicas no permiten pagos mediante servicios en internet?

• Si lo anterior es imposible o hay un segmento de clientes que quiere ir a pagar personalmente ¿porqué el banco no tenía un procedimiento offline o simplemente un procedimiento de calidad al servicio y atender manualmente a los clientes y no hacerles perder tiempo?

• Si por alguna razón que desconozco, se "debe ir a pagar" presencialmente, ¿porqué aún se aplican horarios si está todo automatizado?

• Si como clientes y no-clientes nos garantizan seguridad en personal especializado y vigilante ¿porqué el banco permite que los guardias no vigilen y terminen cuidando y organizando filas?

• Si como en todo banco, debe haber un departamento informático importante ¿porqué no existían mecanismos de calidad al servicio en lugar de procedimientos de calidad computacional -que en teoría existen pero no son lo mismo-?

• Si es un banco, ojo, no hablamos de un negocio cualquiera, ¿porque las cajeras no tenían procedimientos de actuación y todo quedaba a su libre albedrío que por suerte era correcto?

• Etc.

A estas alturas de mi historia se me viene a la mente lo que un profesor de Organización y Métodos una vez dijo. En realidad fueron dos cosas:

• Siempre las organizaciones culpan a los sistemas para justificar fallas.
• Deberíamos enviar la banco una factura para que nos pague por el tiempo perdido.

Este profesor hizo estas aseveraciones el año 1988 ... 27 años después lo primero sigue siendo regla. Lo segundo, lo estoy pensando seriamente. Pero voy más allá. 

Estas expresiones se dijeron en una asignatura clásica, y de esa fecha a hoy, la profesión informática ha dicho que avanzó bastante, pero yo diría que la informática avanzó en computación de hardware y de software, pero en términos de comprender que un sistema informático responde a un servicio, yo diría que este ejemplo demuestra que no ha avanzado. 

O sea, quienes no vean que la informática es observar personas, y no procesos modelados como cajas, círculos y flechas, es seguir comprando tecnología más sofisticada con mentalidad del siglo pasado. Acoto ésto pues se ha puesto de moda el modelado de procesos y mi comentario aclara muy bien entre comprender muy bien esta técnica ... y reducirla a un ejercicio de diagramación -que abundan-. 

Si retomo la idea de los modelos de madurez, que son modelos que permiten a una organización madurar en el desarrollo de las TIC, un banco suele certificarse en estos modelos. Entiendo que este banco ha invertido en estos modelos. Pero queda claro que meter tecnología, y lógicamente saber desarrollarla, no evita el problema de la inmadurez organizacional en mejorar sus niveles de servicio. 

Comento algo más de esta historia. El Banco es una EP (Empresa Pública), por ende la interoperabilidad con otras entidades publicas debería ser obvia. 

Yo me pregunto, si todas las personas de la fila sumamos los minutos que perdimos de entrada por ir al banco a hacer algo que podemos hacer con servicios digitales, y luego luego sumamos el tiempo adicional en resolver el problema, añadimos la pérdida de calidad del servicio, la pérdida de seguridad comunicacional y de vigilancia, y luego la demanda por insatisfacción, el coste al banco no sería menor. Pero al parecer eso no interesa o no preocupa. Y sigo. Si sumo el coste de que muchas personas dejamos de trabajar por estar allí soportando ese procedimiento, el coste al país se dispara. No sé si las utilidades del banco justifican que muchas personas dejen de trabajar. Ah, solamente hablo de la fila de no-clientes, pero en la de clientes pasaba lo mismo. Si sigo sumando, en un año, el país pierde parte de su PIB, el banco pierde dinero, y las personas pierden calidad de vida. 

Bueno, sigo. Cuando terminé mi trámite y al constatar que formalmente del Banco nadie daba solución, informé en la "isla de información" que había un serio problema en la fila de no-clientes. La respuesta fue "gracias por informarme, el banco agradece su información y lamentamos las molestias". El funcionario me miró, me dijo lo previo, terminó, se acomodó en su silla, y siguió mirando la entrada del hotel. Bueno, mejor no seguir con este Banco.

Volviendo a mis pensamientos, me salen cosas de la profesión informática. 

En un antiguo post (del 2010) llamado "Informática de Gestión/Negocios e Informática para la gestión: definiciones desde la calle"(ver http://www.christianestay.com/2010/12/informatica-de-gestionnegocios-para-la_08.html) establecí con claridad la diferencia la concepción epistemológica de la informática. 

Mi pregunta es: si estas definiciones y distinciones son tan antiguas, ¿porqué el banco no sabe qué hacer cuando se queda sin energía eléctrica o sin conexión? Esto suele ocurrir porque se confunde informática con computación. Aquí pienso que es mejor ilustrar las soluciones posibles en base a los conceptos del post que destaqué.

• Computación es pensar que este problema se resuelve con cloud, bigdata, mejor servicio de conexión de internet, arquitecturas homogéneas, etc. Pero está demostrado que pensar así no mejora servicio. Ayuda pero el servicio es independiente de las tecnologías. 

• Informática para la gestión es pensar que en este caso lo mejor habría sido cerrar las cajas y aguantar.

• Informática de gestión es pensar en que las cajeras hubiera llamado a un supervisor de atención al cliente, convocar a clientes de otros trámites no afectados y atenderlos en una fila manteniendo el orden de la fila, ordenar a los guardias privados que se remitan a su función, y a los otros clientes darles una atención en cajas especiales para recibir manualmente sus pagos. Aparte esta solución estaría alineada al análisis de pérdida de oportunidad y coste-beneficio, por lo menos.

• Informática de negocios es pensar en que ésto sería impensable, pues había sumado todo lo anterior. Es más, esta solución evaluaría las pérdidas y oportunidades financieras de cualquier solución.  

Al llegar aquí. Son estas últimas distinciones en cómo trabajar con la informática y sus dispositivos, las que permiten decir Madurez TIC no se reduce a comprar hardware y a saber desarrollar software. 

_________________________________
Post que sugiero revisar:

• ¿Es rentable la interoperabilidad? (Mayo, 25, 2015) - http://www.christianestay.com/2015/05/interoperabilidad-rentabilidad-Ecuador.html.
• Interoperabilidad sin tecnicismos (Agosto 31, 2015) - http://www.christianestay.com/2015/08/interoperabilidad-sin-tecnicismos.html.

Software Libre y SCM: Drupal y gestión de la calidad de su cambio como software libre

Siempre hemos buscado cómo mejorar el proceso de producción de Software, y el Software Libre no es la excepción. 

El asunto no es un tema menor ahora que el mundo del Software Libre es un mercado productivo y un sector económico. Y por lo mismo sujeto a ciertas reglas pero reglas surgidas del mundo del software libre.

Por eso un post que analiza un caso: DRUPAL, escrito en conjunto con Iván Campaña, RDI Director & Co-Founder de DOMO. 

Deseamos aclarar que hablaremos de la Gestión de la Configuración del Software (Software Configuration Management, SCM), pero no como observadores ajenos a la comunidad de Software Libre sino como observadores que vivimos este proceso de madurez desde la propia comunidad DRUPAL. 

Software Libre no significa hacer las cosas como se ocurren, sino cumplir un proceso de madurez propio de las comunidades. Esto es normal, y lo aclaramos. 

Todas las comunidades humanas han ido superando estados de organización, conducentes hacia estados de trabajo organizados. Así es como siendo sociedad, hemos pasado de nuestros pequeños grupos de antepasados nómadas, luego los pueblos y los primeros asentamientos, conduciendo hacia los estado-ciudad medievales, y ya por último llegando una sociedad global que igualmente busca organizarse. 

En paralelo hemos pasado de sociedades tribales, a reinados, imperios, países, más o menos burocráticos, más o menos liberales, más o menos cooperativos. Pero en suma, organizados y buscando medios que permiten la fraterna convivencia.

Gestión de la Configuración del Software o SCM -por sus siglas en inglés- permite el seguimiento y la mejora del desarrollo de software y de las versiones de los componentes y productos en producción. Como todo proceso productivo es apoyado por herramientas automatizadas, software de SCM.

Pero sobre este asunto del SCM, es un error asumir que si usamos una herramienta informática de control de versiones estoy cumpliendo con SCM. La verdad es que el control de versiones es apenas un componente del proceso, y usar un software es tener una visión acotada de la gestión de proyectos.

SCM es un proceso y una cultura organizacional de manufactura profesional y maduro ... No es usar un software, aunque eso ayude.

Aunque, si somos sinceros y recordamos nuestra época de estudiantes universitarios, el mantener un orden y seguir procesos, no es la norma.

Albores del desarrollo compartido y el software libre.

Iván recuerda como experiencia, su primer contacto con la web fue por 1996, cuando su uso era aún incipiente y por prácticas como estudiante elaboró su primera página web (con la poca información que pudo conseguir y aprender).

De manera formal como profesional lo hizo posteriormente en el año 2003. Y por ese año, a medida que fueron cambiando las necesidades y los proyectos se comenzó a volver mucho más común el uso de componentes y/o paquetes completos de software para desarrollar. 


Era un primer contacto con un CMS (Content Management System) como tal, y al momento pareció lo mejor que se podía obtener para reducir tiempos de desarrollo, aprovechar el conocimiento de otras personas con los mismos problemas y sobre todo conocer cómo lo habían resuelto.

Iván indica que se llegó a topar inclusive con casos de clientes que habían partido utilizando software libre implementado con un proveedor y literalmente habían canibalizado el proyecto, alterando a diestra y siniestra el código, haciéndolo virtualmente imposible de mantener.

Sin embargo, a medida que la complejidad aumentaba, las exigencias eran mayores y los errores y las limitaciones comenzaban a aparecer. 

Christian comenzó su trabajo años antes, a mediados de los ochenta. Software libre y CMS no existían. El software era producido y no existía la idea de compartir como se conoce hoy. En las ayudantías universitarías se compartían experiencias y códigos y se aprendían tips. Se producía en máquinas de tiempo compartido y compartir era hablar con el compañero "de al lado". 

Por los ochenta programábamos ventanas en X-Windows, "a mano" como la base de las aplicaciones que debían hacerse. O sea, debíamos incluso fabricar nuestras herramientas. Expresiones como framework, platform, API, etc. estaban partiendo. Todo era "hacer software". E internet en esos años de universidad era enviar un mensaje a alguien y esperar unos 10-15 minutos por la respuesta. 

Ya en los noventa se trabaja produciendo la primera web. Se hizo hablando directo con el usuario, y en equipos de trabajo en incipientes redes. Como se hacían sistemas de toma de decisiones gráficos, el desarrollo requería alta interacción y por lo mismo se compartían algoritmos, no códigos fuente. Era en esencia un método de algoritmos libres. A fines de los noventa ya vino todo el boom de los CMS desarrollándolos desde cero y corrigiendo miles de líneas de código pues los programadores requerían cierta formalización. 

El caso Drupal como proceso de gestión de la configuración de software.

Volvamos a Drupal. 

Aprender a utilizarlo va conectado con una curva de aprendizaje de pendiente bastante pronunciada.  A propósito de esto, hay un gráfico que se mofa del proceso de aprendizaje usual con Drupal.

Como con cualquier software, con Drupal a medida que pasaba el tiempo, se aprende más, y se van descubriendo diferentes formas de hacer las cosas con esta herramienta. Esto es lo que se conoce como "The Drupal Way" que es un conjunto de buenas prácticas obtenidas de la comunidad para sacarle más provecho a la herramienta sin llegar a canibalizar Drupal, entender cómo funcionan algunos de los componentes que lo integran y poder obtener un mejor resultado.

¿Así que, Drupal es una herramienta sin errores? No, sin embargo tiene herramientas para hacer seguimiento de los errores, saber quien es el encargado de resolver un problema, el historial de cambios, el registro de la discusión que se está teniendo para saber como solucionarlo e inclusive la comunidad aporta con recomendaciones y parches para mejorar o corregir errores.

Cada módulo tiene uno o varios encargados de su mantenimiento, gestionar la cola de errores, hacer revisión de los parches y en caso de llegar a ser integrado, aplicarlo y subirlo a drupal.org (que funge como punto de encuentro para los creadores y consumidores de componentes del CMS).

Uno de los puntos de referencia en cuanto a la gestión del cambio, y la forma en la que aporta un miembro a la comunidad, nace desde la aprobación de un módulo nuevo para ser publicado en drupal.org, donde cada uno necesita "ganarse" la reputación suficiente para que su módulo sea aprobado (un proceso que se realiza una sola vez), y esto se gana justamente siguiendo las normativas definidas por la comunidad sobre cómo escribir código seguro, haciendo revisión manual de calidad de al menos 3 módulos, y llenar la solicitud de revisión para el módulo también sea revisado y aprobado, dentro del cual puede ser enviado nuevamente para que sea mejorado, ya sea por errores encontrados, por duplicar una funcionalidad ya existente en otro módulo (lo cual no aportaría al ecosistema), no seguir los estándares de codificación o simplemente por errores de seguridad.

En el caso de lo que se conoce como el core (núcleo) de Drupal, el proceso es similar, pero mucho más estricto, por obvias razones, ya que la idea es que sólo las mejores contribuciones formen parte de la distribución oficial.  

Para poder entender esto de mejor manera Iván participó en al menos 2 sprints de código durante dos DrupalCon (encuentro de los diferentes actores que formamos parte de la comunidad).  Lo hizo desde abajo, como principiante por completo, a pesar de tener suficiente experiencia a nivel de desarrollo y proyectos, se quería saber cómo funcionaba el proceso en su totalidad y entender la manera correcta de hacerlo.

Dentro de ese proceso se recibió una corta capacitación sobre las herramientas de comunicación utilizadas para encontrar errores y realizar revisiones, cómo moverse a través de los tableros de reporte de errores, la nomenclatura utilizada para describir los problemas, cómo y cuando se puede solicitar una revisión, de qué manera se debe describir el problema o la necesidad, la automatización de pruebas de código y si se decidía aportar con código, cómo debía hacerlo.

Desde nuestra experiencia, esto va mucho más conectado al proceso de SCM en software, donde se registran peticiones de cambio, con solicitantes (clientes), responsables (personal operativo), revisión por pares y observaciones (QAS), control de versiones y un flujo de aprobación claramente identificado.

En otros proyectos de Software Libre en los que trabajamos, aportamos y buscamos conectarnos con la comunidad no encontramos un proceso que nos dé la certeza que estábamos trabajando con un equipo de gente que compartía nuestro interés por tener software que cubriera nuestras expectativas. 

Tanto Joomla, como Wordpress (2 de los CMS más utilizados al día de hoy y que evaluamos durante nuestro proceso) tienen millares de componentes, más de uno realizando la misma función, todos asegurando que uno lo hace mejor que otro (con lo cual el esfuerzo se diluye) y con niveles de calidad que dependen realmente de la persona o la empresa que lo realizó, de forma que pueden haber componentes excelentes y otros catastróficos.


Vale la pena recalcar lo que dijimos antes. Todo lo anterior no garantiza que el proceso en Drupal esté libre de errores o que no se pueda escapar algo, pero permite resolver problemas mucho más rápido y genera un alto nivel de apoyo en la comunidad que se ve retribuido como soluciones que todos podemos aprovechar.

Drupal: software libre de origen privado y de voluntarios.

Esta capacidad de unir actores empresariales y voluntarios es una de las líneas motivacionales más utilizadas en la comunidad, es lo que permite converger tanto actores de comunidad, como actores de negocios, en los que quizá la motivación es diferente para cada uno, pero marca una línea sobre la cual seguir adelante.  

Esto deja claro que el componente empresarial o corporativo tiene un peso importante, ya que existen múltiples aportes que han sido patrocinados por empresas y liberados a la comunidad como software libre.

El caso más reciente, en donde se junta el esfuerzo de la comunidad y empresa ha sido en el aceleramiento para la salida de la versión 8 de Drupal, donde se contó con un plan de incentivos (Drupal 8 Accelerate) para corregir los errores críticos y realizar mejoras al software. 

Esto fue canalizado a través de la Drupal Association, un organismo sin fines de lucro que se encarga de ser el catalizador de la comunidad, ampliando el uso de Drupal a través de eventos, capacitaciones, becas y programas de entrenamiento.


Recordando una conversación durante el último Drupal Summit Latino en Cusco-Perú donde conversábamos al respecto, el factor en común es que independiente si somos miembros por la parte empresarial o de la parte comunitaria, todos mantenemos un perfil profesional que queremos desarrollar y con el cual trabajar.  

Esto se confirma al ver que no necesariamente la ingeniería de software debe estar divorciada de un proceso creativo, ni tampoco del software libre, las reglas son diferentes, pero el resultado final debe ser el mismo, herramientas que permitan crear soluciones de negocio, obtener resultados palpables y medibles.

SCM y software libre.

El SCM es un concepto asociado directamente con la ingeniería de software, y define en términos sencillos o se puede tratar de explicar como la gestión del cambio, de forma que el desarrollo de software pueda ser trazable, evaluado y valorado en términos de calidad y responsabilidad (en el caso de un equipo de desarrollo). 

¿De qué manera se maneja esto en el software libre? Nos gustaría decir que todos los proyectos siguen un proceso estructurado, pero la verdad es que existe un gran porcentaje de estos que tienen su origen en el tiempo libre de algún neófito o aparecen como resultado del proyecto universitario de algún estudiante. 

Sin embargo, existe una parte de proyectos que nacen amparados bajo el paraguas de una empresa, o en el caso que vamos a abordar, sirven como punto de partida para crear una, en la cual se utiliza el concepto de “Dictador Benévolo”. 

En la comunidad de software libre Dictador Benévolo se utiliza para referenciar al líder de proyecto, quien probablemente sea quien dio partida al mismo y define las directrices bajo las cuales se va a manejar el desarrollo de un producto.

Algunos de los líderes de proyecto más conocidos (por nombrar algunos) son: Mark Shuttleworth (Ubuntu), Linus Torvalds (Kernel de Linux), Guidovan Rossum (Python) y Dries Buytaert (Drupal). Podemos dejar alguien fuera, pero vale el ejemplo.

Para este post nos enfocaremos en el último personaje de la lista de líderes, Dries Buytaert, quien es al día de hoy el CTO y co-fundador de la empresa Acquia, la cual según datos de febrero del 2015 maneja cerca de 600 empleados y tiene ingresos sobre los 100 millones de dólares. Acquia fue creada para dar servicios sobre Drupal, un software que creó Dries como proyecto universitario para gestionar contenido.

¿Quiere decir ésto que Drupal es más comercial que software libre? Todo lo contrario, es una de las herramientas web que se ha mantenido fuertemente amparada y apoyada en su comunidad de software libre y es esto lo que le ha permitido crecer y fortalecerse como CMS (Content Management System).

Producir software es trabajar con dos factores clave en la producción de software: la falta de control de calidad y la inflexibilidad del software que se había utilizado.

En nuestro caso y experiencia, comenzamos la búsqueda de alternativas de CMS para poder tener una base sobre la cual montar nuestros proyectos, que nos permitiera ser flexibles, pero al mismo tiempo mantener la ventaja de poder acoplarnos a diferentes escenarios.

Cerca del año 2010, tal era la demanda de proyectos con mayor envergadura (clientes que pedían poder manejar sitios web con necesidades muy específicas y con la capacidad de soportar miles de usuarios de forma concurrente), que se llegó  inclusive a considerar la opción de desarrollar nuestra propia herramienta.

Finalmente se optó por utilizar Drupal (luego de evaluar más de 10 herramientas web diferentes, no había sido el ganador, de hecho ni siquiera había quedado en la lista), pero apareció por exigencia de un cliente de EEUU. 

Así llegamos a DRUPAL, del cual se conocía poco, pero que a lo largo de los años desarrolló un proceso que se consolida, no solamente por responder a criterios de ingeniería propios del software, sino por mantener la flexibilidad y "frescura" creativa de una comunidad internacional y de voluntarios. 

Esta última aclaración es vital en el mundo del software libre. ¿Porqué?

• Las comunidades de software libre se crean para dar vida a los software o un tipo de software, lo cual dar lugar a una organización sostenible si el software comienza a masificarse y a ser popular. 
• Software libre como manufactura, no como ideología, fabrica dispositivos de uso social casi al 100% y deben ayudar a sostener esos procesos sociales en los cuales se inserta.
• La calidad del software es inmanente a cualquier dispositivo de ingeniería.
• La comentada mejor calidad de los software libre debe compartirse de lo contrario perderá el sentido originario de su esencia.

Queremos cerrar este post con una idea de Drupal:

• "Come for the software, stay for the community"
• "Ven por el software, quédate por la comunidad"

y unas reflexiones:

• Software libre se define por ciertas reglas.
• Software libre se valida por su uso.
• Pero ¿cómo gestionar la calidad de su cambio?

Bruno Latour: la teoría del Actante-Rizoma y la Internet de las cosas (IoT)

¿Qué tiene que ver la teoría del Actor Red -Actor Network- o teoría del Actante-Rizoma de Bruno Latour con la Internet de las Cosas (Internet of Things o IoT) y con nuestro rol como prosumers en la red global de datos que constituimos? ... Pues todo. En este post comento la relación y la proyecto a varios temas con énfasis en la innovación (aunque no se note mucho). 

¿Te atreverías a decir que el problema de
 gobierno electrónico no es el despliegue
tecnológico de tecnologías,  sino de saber
 gestionar la orquestación de commodities?
Lee este link no apto para puristas
 o teóricos del egob. 

Advierto. Hace tiempo no escribía un post no apto para formalistas, evangelizadores de movimientos post modernos, fanáticos tech de tendencias, papanatistas de la tecnología, o seudo ideólogos de la tecnología. Y este post es de esos pues simplifico un gran debate que estoy seguro da trabajo a muchos consultores pero que algunos ya hemos resuelto. A lo largo de este post van adjuntados.

La esencia del trabajo de Latour es que vivimos en redes de actantes en una red rizomática. O sea quienes hacemos algo o tenemos un rol, incidimos y somos incididos por otros actantes sin que seamos parte de una jerarquía establecida. 

¿A pesar que la gestión de la innovación 
"disciplina la innovación",  en un
 proyecto de innovación 

tecnológica puede que el mismo 
guión a seguir sea siempre nuevo?  
Si te interesa saber porqué pasa 
ésto y qué tiene que ver con Dr. House 
o Mazinger Z, revisa este link no apto 

para puritanos de la innovación.

Claro está, la teoría incluye componentes humanos, tecnológicos y organizacionales. O sea incluye nuestros propios dispositivos culturales, como la tecnología o los procedimientos los cuales -es sabido- inciden en nosotros una vez se integran en nuestras redes sociales y organizacionales. 

Hasta aquí nada nuevo, sólo que la visión de Latour es muy antigua al respecto y además hoy en día es muy avanzada. 

Con la IoT se posibilita que alrededor de nosotros habrán muchos dispositivos capturando datos o que ya los capturan, pero conectados a internet lo cual permite análisis inmediatos de muchas cosas. 

Esto no es novedad, ya hace muchos años estamos rodeados de aparatos que miden, registran nuestras cosas y sus cosas. Ahora solamente aparece la inmediatez de internet. 

Por ejemplo. IoT permite que cuando compremos una lata en una máquina expendedora de latas de Coca Cola, se nos remita información para que compremos determinado snack en una máquina contigua o vayamos a un sitio a comprar algo más dependiendo del horario, la zona, nuestro comportamiento y gustos, etc. 

Internet de las Cosas

¿Sabes cuáles son las cinco creencias
de la economía que no son ciertas?
Lee este link, no apto para
economistas tradicionales o
 economistas que creen han
salido de lo tradicional. 

Gracias a lo anterior, IoT es un problema técnico nuevo por los millones de dispositivos que estarán conectados. IoT es un problema legal y organizacional. E IoT abre nuevas posibilidades a campos como el marketing y el espionaje.

Si analizamos un poco más lo cotidiano, vemos y constatamos que ya estamos siendo monitoreados a diario desde las bases de datos de cadenas de supermercados o bancos, cámaras de seguridad, por otras personas, nuestros wearables, nuestras redes sociales, posibles exoesqueletos, gafas de Google o desde nuestros propios teléfonos. Otra cosa es que no lo vemos o no vemos que hoy en día somos entidades móviles tecnificadas y prosumers online, o sea: generamos datos y, producimos y consumimos información a cada momento. Esto es lo que he llamado la Internet en las cosas (ojo, no es lo mismo que la IoT o Internet de las Cosas, y lo analizo en este post donde hablo de 4 megatendencias en gobierno electrónico y gobernanza digital, en http://www.christianestay.com/2015/09/gobierno-electronico-y-gobernanza-digital--4-megatendencias-IoT-openess-Big-movility.html).

Según lo anterior, personas, máquinas y dispositivos cualquiera constituyen una red de influencias de alcance global.

Bueno, en suma, ya somos parte de IoT, pero humanos. Aquí entra la teoría del Actor-Red o Actante-Rizoma, al quedar demostrada pues todos influimos en todos dentro de las redes sociales informatizadas (una idea clave y que discutí en este post sobre redes sociales, disponible en http://www.christianestay.com/2010/12/las-redes-sociales-2010-resumen-y.html) y dentro de las redes de dispositivos en que vivimos hoy en día.

Y así proyectamos varias cosas que resumo y no limito solamente a las siguientes tres que expongo. 


Que el problema actual no son el enfrentar las posibilidades tecnológicas o las posibilidades que se abren con las tecnologías, sino que hay carencia de modelos o conceptos probados que permitan comprender y gestionar las relaciones entre personas y cosas, lo que obligará a redefinir la idea de red social.

Que vivimos una realidad donde personas y cosas son uno en el espacio hiperconectado de la información, lo que puede conducir nuevamente a debates sobre la utopía o distopia tecnológica (algo sobre lo cual comenté en "Technology as a poetic tool" en http://www.christianestay.com/2013/02/technology-as-tool-peotic-edcmooc.html), pero no creo desde la naturaleza de cada tecnología, sino de los usos que demos las personas a las diferentes tecnologías. 

Que, al ser así, procesos de gestión de la innovación quedan aclarados, pero se abre el espacio donde hay que diseñar estrategias de innovación para que las innovaciones sean sostenibles en una sociedad cada vez más innovacional.

_______________________________________________________
Otros post relacionados "no aptos":

• El ecosistema de gobierno electrónico: innovaciones, commodities y proyecto tecnológicos -Julio 1, 2015- http://www.christianestay.com/2015/06/e-government-innovations-ICT-commodities.html.

• Mazinger Z, Dr House y los proyectos de innovación tecnológica -Junio 27de 2012- http://www.christianestay.com/2012/06/mazinger-dr-house-y-los-proyectos-de.html.

• Otras reglas de mercado:una visión crítica -Agosto 23, 2012- http://www.christianestay.com/2012/08/otras-reglas-de-mercado-una-vision.html.

Nuevos retos de Gestión: Megatendencias de Gobierno Electrónico y Gobernanza Digital

Impulsar la innovación con un enfoque competitivo y a la vez cooperativo será la filosofía de las nuevas tecnologías sociales de cambio y del cambio social de la tecnología.

Y es allí donde surgen sectores nuevos de negocio que requieren de una innovadora gestión de las megatendencias para conseguir el desarrollo que todos anhelamos.

¿Cuáles son las megatendencias tecnológicas
en gobierno electrónico y gobernanza digital?

Antes, en el post Internet en las cosas, Big,Ubiquo y Movil: megatendencias de gobierno electrónico y gobernanza digital (ver http://www.christianestay.com/2015/09/gobierno-electronico-y-gobernanza-digital--4-megatendencias-IoT-openess-Big-movility.html) presenté cuatro (4) megatendencias ligadas a las tecnologías y su relación con el cambio y la sociedad. 

Aquellas megatendencias, de base técnica, se relacionan con otras cuatro (4) megatendencias que aquí presento y que están ligadas a los nuevos retos de gestión cuando las tecnologías se han permeado en la sociedad y sus organizaciones: 

• gestión de una cultura social de cambio; 
• gestión de las competencias digitales de los ciudadanos;
• gestión de los recursos críticos de las tecnologías; y, 
• gestión de soporte inteligente. 

A ver, que no es nada nuevo visto de manera simple, pero la pertinencia de esta clasificación es saber si estamos preparados. ¿Estamos preparados para gestionar las nuevas relaciones de organización social?

El éxito del desarrollo que se quiere en nuestra sociedad parte de comprender la necesidad de impulsar una competitividad con cooperación global, pues aunque la mayoría de los países desarrollados son los principales impulsores y beneficiarios del proceso tecnológico con grandes avances colaborativos, también es necesario comprender que no poseen materias primas y no pueden competir en precio, por lo que las necesidades de avance tecnológico proyectan la oportunidad de un Ecosistema Compartido, megatendencia que requiere la Gestión de una Cultura Social de Cambio que amplía el concepto de una mera Cultura Digital. 

¿Cómo impactan las megatendencias en el
sector de la educación? Conoce este caso en Barcelona.

No obstante, esta megatendencia tendrá que lidiar con la brecha cognitiva que existe en el entorno mediático digital, visto como el nuevo tipo de analfabetismo que podría constituir una barrera seria al desarrollo personal, social y cultural. Recientes datos muestran que en Suecia el ciudadano promedio utiliza 2,3 gigabytes de datos móviles cada mes, mientras que en España, el ciudadano promedio utiliza solo 230 megabytes, es decir, 10 veces menos. En Latinoamérica, las cosas van en menor volumen. Esto indica cambios de estrategias en la Economía Digital, megatendencia, que ahora no sólo debe enfocarse en la gestión de infraestructuras sino también en la Gestión de las Competencias Digitales de los Ciudadanos, visto no nada más como la educación formal a través de herramientas digitales sino aprender a manejar herramientas digitales (teléfonos, tablets, portátiles), o sea, usar las tecnologías con sentido productivo para avanzar en la educación formal. 

Otra megatendencia es, sin duda, la mejora de las regulaciones tecnológicas, pues las conductas de los usuarios de tecnología y de las empresas que ofertan sus servicios están sometidas a diferentes legislaciones nacionales -e internacionales- que, lamentablemente, no avanzan tan rápido como los cambios tecnológicos, incluso muchas veces son contradictorias con el desarrollo que se requiere. Por lo que la participación de los gobiernos en la Gestión de los Recursos Críticos de las Tecnologías será necesaria con un enfoque cooperativo entre el gobierno, las empresas y la sociedad, más allá de las alianzas público-privadas. 

Finalmente, no se puede olvidar que las TIC deben servir a las personas para desarrollar su inteligencia ya sea personal, grupal o colectiva. Algunos investigadores indican que la clave para ello es la interacción y el soporte inteligente, pues de la integración de máquinas inteligentes y personas saldrán los nuevos servicios. En otras palabras, los negocios TIC del futuro requieren una Gestión de Soporte Inteligente con enfoque en el usuario y no sólo con enfoque en el proveedor de servicios (buscando tecnologías que se diferencien de su competencia) o del llamado "cliente", sino que también se establezca cooperación entre los proveedores del servicio permitiéndole a los usuarios, por ejemplo: tanto movilizar sus datos con una sola aplicación entre sus dispositivos móviles como cambiar los datos de proveedor cuando este lo considere. La idea es no quedarse en la alianza comercial, sino integrar formalmente las cadenas de valor y modelos de negocio.

Entonces el reto está en incrementar la inversión en TIC con una clara planificación y gestión estratégica de acuerdo a las megatendencias que se presentan, lo que ofrecería importantes beneficios productivos a un país o una empresa.




_____________________________________________
Post relacionados:

• ¿Cuáles serían las áreas de conocimiento para una gestión en el Siglo XXI? -Enero 23, 2013- (https://cestay.wordpress.com/2013/01/23/cuales-serian-las-areas-de-conocimiento-para-una-gestion-en-el-siglo-xxi/).

• Gestión 2.0+: Uniendo viejas tradiciones con nuevos enfoques -Diciembre 20, 2010- (https://cestay.wordpress.com/2010/12/20/gestion-2-0-viejas-tradiciones-y-management-2-0/). 

• Internet en las cosas, Big, Ubiquo y Movil: megatendencias de gobierno electrónico y gobernanza digital -Septiembre 10, 2015- (ver http://www.christianestay.com/2015/09/gobierno-electronico-y-gobernanza-digital--4-megatendencias-IoT-openess-Big-movility.html.

• Hay experiencias b-learning que permiten construir el futuro observado en megatendencias tecnológicas y sociales -Mayo 15, 2013- (https://cestay.wordpress.com/2013/05/15/hay-experiencias-b-learning-que-permiten-construir-el-futuro-observado-en-megatendencias-tecnologicas-y-sociales/).