El tamaño importa

Entre las buenas noticias para la gestión de proyectos que revisábamos hace unos meses, destacábamos el crecimiento del número de proyectos exitosos en general, sobre todo aquellos que eran más pequeños y también los basados en metodologías ágiles. La mejora de la esponsorización directiva, de la cultura y formación en gestión de proyectos, las habilidades de comunicación y trabajo en equipo y la implantación de metodologías parecían las claves de estos resultados. Ciertamente no todos los proyectos fueron creados iguales y por lo tanto requieren abordajes diferentes. Una parte esencial del trabajo del jefe de proyecto en el inicio es ordenar (Fitzgerald) el proyecto y establecer su enfoque dentro del paisaje de enfoques posibles (Wysocki, Parte I, Cap. 2), más predictivos y directivos o más adaptativos y ágiles, y con qué métodos, herramientas y técnicas en cada caso. «One size fits all» no sirve en gestión de proyecto. El propio PMBOK establece unos procesos previos de preparación y planificación de la integración del proyecto. En algunas compañías tienen unas parrillas para cualificar el tipo de proyecto antes de empezar nada. Según decíamos en otra entrada reciente son la complejidad y la incertidumbre, en una correlación positiva, los dos factores que mejor definirán la clase de animal y por lo tanto la clase de manejo del proyecto o del programa. Pero para mí uno de los factores principales para establecer la complejidad es el tamaño. Tamaño quiere decir la duración del proyecto, el volumen de recursos asignados y el número de interacciones dentro de la organización (o sea, con y entre los usuarios e interesados, en especial, el número de departamento o unidades de...
El movimiento NoSQL (II)

El movimiento NoSQL (II)

Seguimos tratando las bases de datos NoSQL, de las que ya empezamos a hablar en la entrada anterior. NoSQL se orienta principalmente a entornos altamente distribuidos –donde existen miles de ordenadores (o nodos) trabajando de manera colaborativa– que necesitan gestionar grandes volúmenes de datos con alta disponibilidad. La mayoría de estos sistemas usan la replicación y fragmentación de los datos, y explotan el paralelismo para potenciar la escalabilidad y la disponibilidad. Además, a diferencia de los gestores de bases de datos relacionales, en este tipo de soluciones es posible añadir nuevos nodos (normalmente “en caliente”) para conseguir mayor capacidad. Esto se conoce como escalabilidad horizontal. En este contexto, es necesario considerar la conjetura de Brewer, también conocida como teorema CAP (Consistency, Availability and tolerance to network Partition). Dicho teorema establece que en un sistema distribuido es imposible conseguir simultáneamente las tres características, y que en consecuencia es necesario elegir dos de las tres. La consistencia (consistency) se refiere a la capacidad de que se puedan recuperar siempre los mismos datos en un mismo instante de tiempo. Por su parte la disponibilidad (availability) se refiere a que si alguno de los nodos del sistema distribuido no se encuentra disponible, el resto pueda seguir trabajando. Finalmente, la tolerancia a la partición de red (tolerance to network partition) significa que el sistema distribuido pueda seguir operando, incluso ante posibles fallos en parte de la red de comunicaciones. La tolerancia a la partición de red, más que una decisión, constituye una necesidad en la mayoría de sistemas altamente distribuidos. Por lo tanto, la decisión consiste en elegir entre consistencia o disponibilidad, y en...
El movimiento NoSQL (I)

El movimiento NoSQL (I)

El pasado 6 de Octubre se celebró en la Casa de la Convalescència de Barcelona la conferencia NoSQL Matters . La conferencia incluyó diferentes ponencias donde se trataban aspectos técnicos, presentación de productos y casos de uso. Algunas de estas ponencias están comentadas en el blog «Alapamui!«. La organización fue impecable e incluyó contenidos interesantes, proporcionando además un marco adecuado para que asistentes y ponentes pudieran compartir experiencias e inquietudes. Bajo la denominación NoSQL (Not Only SQL) se engloba un amplio abanico de tecnologías para gestionar y analizar datos en entornos de aplicación donde las bases de datos relacionales no son la mejor solución, invalidando la máxima one size fits all esgrimida en ocasiones por los fabricantes de gestores de bases de datos relacionales. Existen diferentes propuestas de bases de datos NoSQL, buena parte de ellas tratadas en NoSQL Matters, y cuyas principales tendencias pueden resumirse en 3 grandes grupos: 1) Almacenes clave-valor (Key-value stores), que emulan el funcionamiento de las tablas de dispersión (hash tables), como sería el caso del sistema Dynamo desarrollado por Amazon, Redis, y los populares almacenes para grandes datos (Big data stores) como BigTable de Google, su versión de código abierto Apache HBase y Cassandra, liberado por Facebook y ahora proyecto Apache. Los almacenes para grandes datos añaden el concepto de familias al de clave-valor para explotar el almacenamiento físico por columnas. 2) Bases de datos documentales, que se orientan al almacenamiento y recuperación  eficiente de documentos. Son similares a los almacenes clave-valor, con la peculiaridad que el valor es el documento en sí mismo. Algunos ejemplos serían MongoDB, Couchbase y Riak. 3) Bases...

Buenas noticias para la gestión de proyectos

Los libros y artículos de gestión de proyectos comienzan con las cifras apocalípticas de los desastres de gestión (el famoso informe anual del Standish Group, llamado el “Informe del Caos”, o el blog de Michael Krigsman titulado “IT Failures” han hecho del desastre una razonable manera de ganarse la vida) y el reparto de culpas entre los sospechosos habituales (las “principales causas de fracaso” ). Luego está la sección y las webs de chistes y bromas. Nosotros, en las asignaturas de gestión de proyectos solemos empezar con un debate donde los estudiantes, muchos de ellos profesionales, ponen en común sus experiencias de fracasos (y a veces también de éxitos). “El fracaso es la madre del éxito”, dicen que decía Confucio. Este año estamos usando para el debate la estupenda y “seminal” entrada de Robert Clarisó sobre el hundimiento del barco “Vasa”. Pero un paseo reciente por algunas noticias profesionales da algunos motivos de alegría a nuestra profesión, que siempre creemos maltrecha y poco reconocida. Fuera de las cifras del Standish Group, si miramos otras fuentes más ponderadas, las cosas no son tan graves, si puede decirse. El informe más o menos anual de Gartner de este año (“Survey Shows Why Project Fails”, ID: G00231952; los estudiantes de la UOC tienen acceso a la base de datos de Gartner) viene a decir que un 75% de los proyectos suelen salir bien y las cifras van mejorando. Lo pequeño es hermoso: las cifras aumentan hasta el 80% en los proyectos más pequeños y algunas compañías están implantando mecanismos para limitar el tamaño máximo de cualquier proyecto. Cuanto más grande, más equivocado, especialmente...

Ágil

En nuestros primeros blogs de gestión de proyectos empezamos, como casi todo el mundo, por los chistes, los fracasos y las mentiras (1, 2). Analizábamos las causas del fracaso y nos salían temas de tipo más organizativo (involucración de usuarios y directivos, presiones económicas que afectan al tiempo y coste), que de tipo técnico o de gestión del proyecto (requerimientos poco definidos, pruebas insuficientes). La mejora de la gestión de proyectos como disciplina y profesión y la introducción y práctica de la cultura de proyectos dentro de las empresas ha mejorado en el ciclo largo la calidad y resultados de los proyectos, más o menos hasta principios de los 2000, pero en los últimos años tiene un efecto marginal. Aproximadamente, un cuarto de los proyectos son un fracaso total y más o menos un tercio pues ni fu ni fa. El enfoque tradicional y bien establecido de la gestión de proyectos, en las TIC y en cualquier otra cosa, se basa en la obsesión por la predictibilidad y el cumplimiento, soportados por liderazgos fuertes y documentación exhaustiva. Si definimos bien el alcance, si tenemos un buen plan y si todas las partes lo cumplen y nos dirige un buen jefe, el proyecto será un éxito. Pero lo es pocas veces. El cliente y los usuarios no saben bien lo que quieren y lo cambian continuamente (o no saben explicarlo, o el analista no los entiende), aceptamos presupuestos cortos que sabemos que no podremos cumplir (también lo sabe el comprador) y las empresas no hacen lo que tienen que hacer para que el proyecto y sus resultados sirvan para algo....