Sobre el valor de los Sistemas y Tecnologías de la Información (2)

Hace unos meses publiqué en este mismo blog una entrada con el mismo título que esta y hace un tiempo también se han publicado aquí algunas más, a propósito de las aportaciones de Nick Carr o Erik Brinjolffson, y otros. En mi post recordaba algunas teorías importantes sobre el ‘valor’ en economía (destacando la basada en el coste de los factores de producción) y algunas métricas aplicadas al valor de los sistemas de información (destacando las más usadas, basadas en el tamaño y complejidad del software, como FPA). Todas esas reflexiones estaban hechas desde una perspectiva micro o local, quizá extrapolable a lo sectorial. En esta entrada me planteo una perspectiva más macro o global. Ambas perspectivas, micro y macro —en el mundo de la economía y de la informática— no están reñidas entre sí porque —aunque pueden usar indicadores, métricas y procedimientos muy distintos— hacen todo ello, por el momento, bajo un mismo paradigma (a diferencia, por ejemplo, de la física cuántica [más ‘micro’] respecto de la clásica [más ‘macro’]; aunque está por ver si la economía sigue tolerando la coexistencia de dos paradigmas distintos, el de los modelos prescriptivos y el de los modelos descriptivos —ver Misbehaving, de R. Thaler (Nobel de Economía, 2017 ) y Phishing for Phools de G. Ackerlof (Nobel de Economía, 2001) y R. Shiller (Nobel de Economía, 2013), defensores de las behavioral economics (economía conductal o del comportamiento). Desde una perspectiva macro, global, se han realizado numerosos intentos históricos para estudiar el valor de los Sistemas y Tecnologías de la Información (SITI). Casi todos ellos planteados, en mi opinión, desde ópticas parciales...

Agilidad a lo grande

En los últimos 20 o más años, los departamentos de TI y las empresas tecnológicas han implantado metodologías de gestión de proyectos y producción de software basadas en los principios del manifiesto Ágil. Más recientemente, otros departamentos y empresas de todos los sectores están llevando este enfoque más allá de los proyectos de TI. Se plantean escalar la agilidad al conjunto de la organización, en sus procesos de gestión, su estructura, su estrategia y sus políticas de recursos humanos o de gestión presupuestaria… como parte de su transformación digital. Portada del número 96 (3) de la Harvard Business Review El artículo de portada de la Harvard Business Review de hace unos meses (la revista de management más vendida e influyente, pero también de las más conservadoras) evangelizaba a favor de estos cambios. Es un buen artículo, escrito por consultores de Bain, que también mereció la ovación de Forbes (otro medio bastante moderado, la verdad). Según una encuesta reciente de McKinsey, un 38% de los participantes declararon que estaban introduciendo cambios estructurales de alcance basados en ágil, aunque sólo el 4% confesaban haberlo conseguido completamente. En casi el 75% de las empresas, la agilidad forma parte de sus mayores tres prioridades para los siguientes años (más del 90% en otra encuesta de Deloitte). Los mejores candidatos son aquellos procesos relacionados con los clientes, con la innovación y con el desarrollo de productos. Los sectores más avanzados son la alta tecnología y las empresas farmacéuticas, seguidos de las empresas de servicios públicos (agua, gas, electricidad y telecomunicaciones), los servicios financieros y el “tercer sector”. En general, las empresas abordan esta transformación creando equipos y unidades separados,...

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

Mi post anterior ha merecido dos comentarios aquí, muy bien argumentados y escritos y cuya lectura os recomiendo, se ha difundido en alguna red y me han llegado directamente otras reacciones y ningún hate, al menos público. Dejadme seguir un rato el análisis antes de escribir propuestas o caminos de mejora en otra entrada y antes de irnos de vacaciones, promise.  Freepik 1098259 El alcance y el valor. Los jefes de proyecto y quienes los controlan viven obsesionados por el alcance y esto les pierde. El alcance es una lista de requisitos y también dos huevos duros (como decía Marx, Groucho). No tiene que ver frecuentemente con ninguna clase de valor o beneficio para el negocio, más allá de la comodidad pasajera de un usuario… a quien nadie se atreve a contradecir. ¡Y no es el valor ganado! El famoso valor ganado es un engendro que mide el trabajo ejecutado contra el presupuesto aprobado, pero no mide el valor aportado o recuperado de una inversión en informática. El proyecto y las otras cosas. A mí me parece que, como en todas las comunidades, la cofradía de la gestión de proyectos decidió que el proyecto tenía una lógica propia, separada de lo que pasa en la empresa, de lo que el cliente hace o tiene que hacer y de lo que ocurre en el resto del departamento de informática. Esta resulta una opción más segura y, si algo sale mal, siempre se puede culpar a otros. Las metodologías, y lo escribe un autor de metodologías, tienen efectos colaterales. Una mejor metodología o un reporting más completo o mayor número de herramientas y artefactos no hará mejores productos… y es...

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

Hay un conjunto de razones que están cambiando en muchas empresas la manera de ver la gestión de proyectos y la gestión de las TI en su totalidad. Desde el lado de la demanda: la presión de los clientes internos (los líderes de negocio) por el tiempo de respuesta (el time-to-market), las TI de en la sombra (el shadow IT) y las soluciones de usuario final y autoservicio, entre otras. Desde el lado de la oferta: los modelos de entrega continua (continuous delivery y DevOps), la construcción ágil, las nuevas fórmulas de subcontratación (outsourcing), la interdependencia de las plataformas de software y las nuevas arquitecturas de componentes, entre otros. Según Gartner, las empresas vienen a gastar un 77% del presupuesto de informática en el funcionamiento ordinario de las operaciones (el run), un 13% en el mantenimiento y evolución del parque de activos (el grow) y sólo un 10% en la transformación y creación de nuevos productos (el transform). A mí (que he dedicado una parte de la carrera a la gestión de proyectos en la docencia, en la consultoría y en la gestión, y sobre la que he publicado algunos libros (1, 2), artículos, materiales y un montón de entradas en este blog) estos datos y tendencias me hacen dudar y me provocan. Y quiero compartir esta provocación con vosotros. Puede que alguno de los principios de oro en que se basó la gestión de proyectos estén ahora en cuestión y, con ellos, la profesión. Comencemos hoy y, si os interesa y me voy animando, seguiremos otros días. Un proyecto es una entidad única, distinta y separada de las operaciones. Creo que hoy esto no es ya así. La...

Introducción a Cypher

Ahora que ya conocemos las características de las bases de datos NoSQL en grafo, y tenemos Neo4j instalado y funcionando, es el momento de empezar con Cypher. Cypher es un lenguaje declarativo, inspirado en SQL, que permite manipular datos en Neo4j. Es aconsejable tener a mano la guía de referencia de Cypher siempre que estemos trabajando con Neo4j. Esta guía recoge la sintaxis y la semántica de las sentencias y funciones disponibles en Cypher. Hay que tener en cuenta que existe una guía de referencia (refcard) para cada versión de Neo4j (nosotros hemos elegido la guía de referencia para Neo4j versión 3.4). Antes de continuar os animamos a que abráis el browser de la base de datos que creamos en la segunda entrada. En el siguiente vídeo mostramos cómo abrir el browser y explicamos los elementos básicos del entorno de trabajo de Neo4j.     Ahora que ya conocemos la interfaz es el momento de empezar a trabajar con datos. Lo primero que vamos a hacer es aprender a crear nodos y relaciones en Neo4j. Para ello tendremos que usar la cláusula CREATE. Por ejemplo, empezamos ejecutando la siguiente sentencia: ¿Qué es lo que se ha creado? Podemos averiguarlo mediante la siguiente consulta: La sentencia anterior nos devuelve todos los nodos de la base de datos. En este caso nos ha devuelto un nodo, el que acabamos de crear. Pero, ¿qué información tiene ese nodo? Pues la verdad es que ninguna, es un nodo vacío. Sin tipo y sin propiedades (o atributos). Un nodo sin información por lo general no tiene mucho sentido, por lo que vamos a aprender...

Introducción a Neo4j

Ahora que ya conocemos las principales características de las bases de datos NoSQL en grafo y del modelo de datos que utilizan es el momento de ver, mediante ejemplos prácticos, cómo almacenar y manejar datos en estas bases de datos. En esta entrada comentaremos las principales características de Neo4j, veremos cómo instalar Neo4j en nuestro ordenador y cómo crear una base de datos y empezar a “jugar” con ella. Actualmente, Neo4j es la base de datos en grafo más popular según el ranking de db-engines.com. A fecha 2018, también es el número 21 de 295 en el ranking general de bases de datos. El modelo de datos utilizado por Neo4j es un grafo de propiedades etiquetado. Por tanto, las unidades básicas de procesamiento en Neo4j son las mismas que explicamos en la entrada anterior: nodos, relaciones entre nodos, propiedades (definidas sobre nodos o relaciones) y etiquetas que permiten definir el tipo de los nodos y de las relaciones. En Neo4j se utilizan los dos puntos “:” para representar las etiquetas. Por lo tanto, :Book, :Person y :HAS_READ, representarán las etiquetas Book, Persony HAS_READ. Por otro lado, para distinguir fácilmente las etiquetas de nodo de las de relación, en Neo4j se escriben las etiquetas de relación en mayúsculas y las etiquetas de nodo con la primera letra en mayúscula y el resto en minúsculas. Así pues, Book y Person serían etiquetas de nodo y HAS_READ una etiqueta de relación que representa qué libros (nodos de tipo :Book) ha leído una persona (nodo de tipo :Person). Las propiedades acostumbran a representarse en minúsculas. Neo4j es una base de datos schemaless. Esto no quiere...