¿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...

Estrategia de SI: ¿qué evaluamos cuando evaluamos?

Estamos dedicando una temporada a la formación de la estrategia de sistemas de información, o sea, los procesos sociales y organizativos mediante los cuales las empresas hacen estrategia, que pueden incluir o no procesos más o menos explícitos de formulación y ejecución de la estrategia. De lo poco que sabemos, los principales problemas relacionados con la implantación tienen que ver avasalladoramente con la ausencia de soporte sostenido de la alta dirección, la dificultad de medir los resultados y beneficios del plan, la falta de flexibilidad para adaptarse a las nuevas estrategias de la empresa, problemas de dedicación, calidad y compromiso de los recursos del negocio y de TI, el complicado diálogo entre ambas partes y cuestiones políticas y organizacionales. Os recomiendo la lectura de los papeles más clásicos de Wilson, Teo y Ang y Luftman y Brier. Hablemos hoy de la evaluación. Si vale mi experiencia, la evaluación es una buena oportunidad para recrear el ciclo de planificación y dirección estratégica de los sistemas y aumentar o, al menos, mantener la tensión (el momentum, que dicen los anglosajones) del plan y el compromiso de la dirección. Es un ejercicio tanto de planificación como de gobernanza. El problema es que la medición de resultados, en la informática y en la vida, tiene muchas dimensiones y para cada contexto y nivel de madurez de la organización tenemos que elegir entre un repertorio. Y encima, disponer del tiempo, de los datos y del compromiso de la gente para hacer un ejercicio que no suele ser cómodo. 1. Lo primero que deberíamos medir es si hemos conseguido el famoso alineamiento estratégico, o sea hasta qué punto la ejecución...

Notas de literatura y estrategia de sistemas de información

Me refiero a la literatura académica sobre la estrategia de los sistemas de información. 0.  En los tiempos que corren vale la pena reivindicar la importancia y la belleza de los trabajos finales de la carrera. Lo son (importantes y bellos) para los estudiantes, que culminan el esfuerzo de años y tienen la oportunidad de aplicar sus conocimientos no sólo técnicos (entender y resolver problemas y fabricar artefactos teóricos o prácticos) sino transversales (leer literatura, analizar enigmas, encontrar avenidas de solución, escribir y presentar, resolver dudas y cuestiones). Lo son para los profesores y colaboradores docentes, aunque nos den mucho trabajo: es una ocasión para mantenernos al día, enfrentarnos a retos conocidos y nuevos, a nuevas formas de estudiar y nuevos tipos de estudiantes y acompañarles de una forma especial, mucho más individual y directa. Y nos hace ilusión cuando coinciden los intereses, aficiones y entusiasmos del estudiante con los nuestros. Estoy dirigiendo, junto con otra colaboradora, un trabajo final que consiste en analizar un proceso de revisión de la estrategia de sistemas de información de una empresa. 1. Parece mentira el poco interés académico dedicado a estudiar la ejecución de la estrategia, su evaluación y su puesta al día. En 2008, Teubner y Mocker, del ERCIS de Munster, estudiaron más de 400 artículos sobre estrategia de sistemas y tecnologías de la información publicadas en las principales revistas de la especialidad a lo largo de 30 años. Sólo el 4,8% cubrían temas relacionados con la implantación. En 2014, Amrollahi y colegas hicieron una revisión sistemática de la literatura incluyendo nuevas categorías. Entre 2000 y 2009 encontraron 102 papeles sobre planificación...