Unidad 1 — Dirección de proyectos

Las operaciones son actividades repetitivas y sin un final en el tiempo determinado dentro de una organización. Las operaciones son las actividades regulares dentro de una organización. Contrastan de manera clara con los proyectos ya que:

Un ejemplo de la diferencia entre operaciones y proyectos en una empresa de informática podría ser el siguiente. Un cliente encarga a una compañía de desarrollo web un nuevo sitio para vender sus productos. La concepción, diseño e implementación del sitio es un nuevo proyecto. Es entregado en una fecha determinada con el cliente y con un contenido previamente acordado. El cliente luego necesita realizar ajustes u obtener soporte técnico de esta compañía para su sitio. El soporte brindado es parte de las operaciones de la empresa.

Veáse PMBOK 2.2

Los interesados de un proyecto son todos los miembros del equipo del proyecto y todas las personas u organizaciones que se pueden ver afectados por una actividad, decisión o resultado del proyecto. Los interesados pueden ser afectados de manera positiva o negativa por el proyecto. Es posible, a menudo probable, que los interesados de un proyecto tengan intereses contrapuestos y generen conflictos dentro del proyecto. Los distintos interesados pueden ejercer distintos grados de influencia sobre el desarrollo del proyecto.

Los interesados pueden ser internos o externos a la organización que lleva a cabo el proyecto. Es importante que el director del proyecto gestione de manera adecuada las expectativas de los distintas partes afectadas por el proyecto.

Algunos ejemplos de interesados de un proyecto son:

Veáse PMBOK 2.3

El equipo del proyecto son todas las personas que trabajan para lograr el objetivo del proyecto. La cantidad de miembros y su organización interna varía de proyecto en proyecto, pero siempre existe un líder o director del proyecto que se dedica a gestionar y dirigir el esfuerzo colectivo del grupo. Las personas que participan de la dirección del proyecto pueden o no involucrarse en el trabajo concreto del proyecto (el trabajo específico del área del proyecto). Pero se espera que el director del proyecto sea idóneo en la disciplina del proyecto. Es decir, un arquitecto no dirigiría la implementación de un sistema operativo como un ingeniero de software no dirige la construcción de un edificio.

Veáse PMBOK 1.3

Existen distintos estándares para la dirección de proyectos, todos muy similares entre sí. Entendemos por estándar un conjunto de prácticas recomendadas, que los profesionales de la dirección y gestión de proyectos consideran útiles a la hora de llevar a cabo sus objetivos de manera satisfactoria. Es un documento formal que recomienda y busca normalizar una práctica profesional determinada. Estos estándares pueden referirse a la dirección de proyectos en general, o a la dirección de proyectos dentro de una rama o industria específica. Algunos ejemplos son:

El estándar de referencia que tomamos nosotros es el del PMI (Project Management Institute). Sus prácticas están desarrolladas en el PMBOK (Project Management Body of Knowledge) y es de hecho el estándar internacional con mayor presencia. También es uno de los más generales, por lo tanto intenta ser de aplicación a casi cualquier situación.

El estándar descrito en el PMBOK consta básicamente de 47 procesos con sus entradas y salidas. Para organizarlos éstos están divididos en diez áreas de conocimiento relevantes para la dirección de proyectos. Además se agrupan en cinco grupos definidos en relación con el ciclo de vida del proyecto.

Veáse PMBOK 1.7

El director del proyecto tiene la tarea de satisfacer las necesidades del equipo del proyecto, de las actividades que este lleva a cabo, de los interesados, etc. Algunas habilidades con las que debería contar un director de proyectos:

También es responsabilidad del director del proyecto la planificación del mismo. Las dos habilidades más importantes para esto son las de manejar los tiempos y costos del proyecto, ya que cualquier cambio de estos dos factores en general deben ser autorizados por fuera del equipo del proyecto.

Veáse PMBOK 2.4.2

Un proyecto puede contener un número cualquiera de fases. Una fase es una agrupación lógica de actividades del proyecto. Una fase debe terminar con algún hito claramente definido y de importancia para la totalidad del proyecto. A menudo el cierre de cada fase es una oportunidad para realizar una revisión del trabajo realizado hasta el momento. También se debe considerar el cierre de cada fase como un momento propicio para tomar la decisión de continuar o abandonar el proyecto.

Las fases de un proyecto pueden estar relacionadas de dos maneras. Pueden estar en una relación secuencial o superpuestas entre sí. Las fases son secuenciales si para que empieze una nueva fase debe si o sí terminar la anterior. Las fases superpuestas admiten la ejecución en paralelo de distintas fases del proyecto.

Una división genérica que aplica prácticamente cualquier proyecto sería la siguiente:

Véase PMBOK 2.4.2.2

Los ciclos de vida predictivos se denominan así por estar orientados a la planificación. El alcance, el costo y el tiempo del proyecto se determinan lo antes posible para poder mantener los cambios futuros al mínimo. Esto se realiza así para bajar los costos ya que cualquier cambio que se quiera introducir al proyecto tiene un costo mayor mientras más avanzado está el desarrollo. Este tipo de ciclo de vida permite también mantener los riesgos de fracaso al mínimo posible y formar un equipo del proyecto especializado por cada fase del mismo. Generalmente se compone de fases secuenciales o levemente superpuestas.

En ingeniería de software tenemos un ejemplo paradigmático de ciclo de vida predictivo. El modelo en cascada es un método de desarrollo de software de larga tradición y que pone todo su esfuerzo en evitar cambios al proyecto durante la fase de implementación (código).

Veáse PMBOK 2.4.2.3

Los ciclos de vida iterativos e incrementales son aquellos en los cuales, dentro de las fases del proyecto (también llamadas iteraciones), se repiten de manera intencionada una o más actividades del proyecto a medida que aumenta el entendimiento del producto por parte del equipo del proyecto. Las iteraciones desarrollan el producto a través de una serie de ciclos repetidos, mientras que los incrementos van añadiendo sucesivamente funcionalidad al producto. Estos ciclos de vida desarrollan el producto de forma iterativa y con incrementos graduales. Los proyectos iterativos e incrementales pueden desarrollarse en fases, y las propias iteraciones se realizarán de un modo secuencial o superpuesto.

Generalmente este tipo de ciclo de vida se prefiere cuando es probable que el alcance del proyecto cambie a lo largo del mismo o cuando se emprende un proyecto poco familiar para el equipo del mismo, incorporando las lecciones aprendidas durante cada iteración.

Veáse PMBOK 3.2

En el PMBOK se detallan cinco grupos de procesos en relación a su lugar en el ciclo de vida del proyecto. Éstos son:

Cabe destacar que según el PMBOK estos cinco grupos no son fases dentro del ciclo de vida del proyecto. Estos grupos pueden aparecer dentro de cada fase del proyecto.

Veáse PMBOK 3.9

Los 47 procesos definidos en el PMBOK a su vez están organizados en diez áreas de conocimiento:

La división en áreas de conocimiento de los procesos busca separar las distintas herramientas y especialidades dentro de la profesión del director de proyectos. Los capítulos 4 al 13 del PMBOK describen los procesos específicos de cada área y su relevancia dentro de la dirección de proyectos. La siguiente tabla resume la relación entre los 47 procesos del estándar, los grupos de procesos y las áreas de conocimiento.

Este proceso se lleva a cabo prácticamente en cualquier proyecto. Se trata básicamente de conseguir autorización por escrito para iniciar un proyecto. Es por supuesto indispensable si se trata de un proyecto que requiere destinar recursos financieros o de algún tipo y es lo primero que se hace en un proyecto. Es el proceso que lo inicia. Requiere algún tipo de formalidad, por ejemplo, la firma de alguna autoridad por encima del proyecto que se va a llevar a cabo. Para el PMBOK el documento que se firma y da origen al proyecto se denomina acta de constitución del proyecto. Lo que típicamente da origen al proyecto y aparece por escrito en esa acta es lo que se conoce en la jerga como SOW o enunciado de trabajo del proyecto. Un enunciado de trabajo típico es el pedido de un cliente que se nos acerca pidiendo la implementación de algún sistema de información en particular.

Estos dos procesos del área de integración son importantes para nosotros porque en ingeniería de software tenemos una herramienta de uso muy difundido que automatiza parte de estos procesos. Esa herramienta es un VCS (version control system) y la que vamos a utilizar es Git. Básicamente estos dos procesos nos hablan de la importancia de saber quién, cómo y cuándo se introducen cambios en el proyecto. Ya sea trabajo previamente acordado en la definición del alcance, o cambios propuestos más adelante en el ciclo de vida del proyecto. Un VCS nos da la posibilidad de revisar la historia completa del desarrollo (al menos la parte de implementación y testing) del proyecto. Además se debe proveer un mecanismo formal para introducir cambios en el proyecto. Por ejemplo si se desea agregar una nueva característica a un sistema no definida al inicio, o cambiar una librería de software por otra más nueva.

El derecho de autor es el conjunto de normas jurídicas que regulan la propiedad sobre la obra de un individuo u organización. Por obra entendemos por supuesto sistemas informáticos. El derecho de autor puede expirar y la obra o invento puede pasar al dominio público. En el derecho anglosajón se conoce como copyright (literalmente derecho de copia). Todo sistema informático, o de manera más general, todo el código que escribimos como programadores pertenece a sus autores al menos que se indique lo contrario.

Las licencias de software pueden establecer entre otras cosas: la cesión de determinados derechos del propietario al usuario final sobre una o varias copias del programa informático, los límites en la responsabilidad por fallos, el plazo de cesión de los derechos, el ámbito geográfico de validez del contrato​ e incluso pueden establecer determinados compromisos del usuario final hacia el propietario, tales como la no cesión del programa a terceros o la no reinstalación del programa en equipos distintos al que se instaló originalmente. El software propietario generalmente contiene un EULA (End User License Agreement) que son los términos legales explícitos con los que se distribuye el software.

El copyleft es una práctica legal que consiste en el ejercicio del derecho de autor con el objetivo de propiciar el libre uso y distribución de una obra, exigiendo que los concesionarios preserven las mismas libertades al distribuir sus copias y derivados.​ Los autores pueden aplicar una licencia con copyleft a programas informáticos, obras de arte, textos o cualquier tipo de trabajo creativo que sea regido por el derecho de autor.

El copyleft es propuesto como alternativa y defensa contra las restricciones al público en las que normalmente incurren los editores y la industria del entretenimiento. Se pretende así que quienes poseen los derechos patrimoniales de una obra la ofrezcan mediante una licencia libre; al mismo tiempo que una cláusula adicional (el copyleft en sí) protege los derechos ofrecidos en la licencia de intentos subsecuentes de privatización por parte del público (mientras la obra no pase al dominio público). Las licencias con copyleft son entonces una de las categorías principales de licencia libre, en contraste con las llamadas licencias permisivas o sin copyleft, y en contraste con el dominio público.

Licencia copyleft de tipo fuerte. Esta licencia es la versión moderna de la licencia original creada por Richard Stallman para la FSF (Free Software Fundation) y el proyecto GNU. La idea de esta licencia no es prohibir la distribución comercial (con fines de lucro) del software. Pero los trabajos derivados de software bajo esta licencia tienen la obligación de conservar esta licencia. Un ejemplo de software bajo esta licencia que persigue fines comerciales es Red Hat.

Licencia de software de código abierto permisiva. Permite cambiar el tipo de licencia en versiones modificadas del software a diferencia de la GPL. A diferencia de la licencia MIT cualquier cambio realizado en el software original debe ser informado explícitamente.

Licencia de software de código abierto permisiva. Licencia simple que permite prácticamente hacer cualquier cosa con el software pero desliga al autor de ofrecer cualquier garantía o recibir juicio alguno por parte de los usuarios.

Esta licencia, literalmente la no licencia dice que el software se libera al dominio público resignando cualquier derecho de autor sobre la obra.

Los requisitos son las características que deben cumplir los entregables del proyecto. Generalmente los interesados del proyecto definen los requisitos. Los requisitos deben ser documentados para poder ser usados en la planificación, y para tener constancia de qué se espera de manera precisa del producto a entregar. Forman un mínimo de lo que se espera, y por lo tanto sirven para controlar el progreso del proyecto y que el mismo se ajuste a la calidad deseada en el resultado final. Decimos que los requisitos son funcionales cuándo describen qué debe hacer nuestro producto. Esto es muy común en ingeniería de software, generalmente los requisitos funcionales son las capacidades y funciones de nuestra aplicación. Los requisitos pueden también ser no funcionales (relativos a la calidad, diseño, costos, etc.).

Algunas técnicas de recolección de requisitos son:

Lo importante es generar a través de estas y otras técnicas una documentación exhaustiva sobre los requisitos de nuestro proyecto y posteriormente realizar un análisis integral de los mismos. En el análisis de los requisitos buscaremos inconsistencias (requisitos incompatibles) o requisitos que no pueden ser alcanzados dadas las restricciones del proyecto (costo, tiempo, recursos humanos, etc.). También hay que eliminar las ambiguedades en los requisitos, y descartar cualquier requisito que no sea verificable, es decir, que no se pueda determinar en un tiempo finito si el proyecto cumple o no dicho requisito.

Definir el alcance de un proyecto es dar una descripción detallada del proyecto y del producto a realizar. Es posible que no todos los requisitos encontrados en la etapa anterior pasen a formar parte del proyecto. En esta etapa se definen los requisitos definitivos a partir de la documentación generada en el paso anterior. El proceso de definir el alcance debe generar un documento con la descripción final del trabajo a realizar, qué es lo que se va a entregar, los supuestos y las restricciones. Aquí podemos definir también explícitamente que cosas no entran en el alcance del proyecto de modo que los interesados del proyecto no se lleven ninguna sorpresa más adelante. Este documento o enunciado debe contener lo siguiente:

Es importante que el trabajo final, lo que se entrega, esté bien definido, así como los hitos, que pueden marcar la finalización de una fase, generalmente con algún entregable asociado para verificación por parte de los interesados. Los hitos del proyecto marcan un momento en el qué se pueda controlar el progreso del proyecto y decidir por la continuación del mismo.

La estructura de desglose del trabajo es el paso final en la definición del alcance del proyecto. Consiste en un gráfico jerárquico del trabajo a realizar para alcanzar los objetivos del proyecto. El primer nivel consiste en el proyecto entero, y a partir de ahí se descompone el proyecto en unidades cada vez más pequeñas. El objetivo de esta representación es llegar a un nivel dónde las unidades de trabajo sean más fáciles de estimar en su duración o costo, también conocidas como paquetes de trabajo o actividades. Por ejemplo, si el proyecto es el de construir una casa, una actividad en el último nivel de la EDT puede ser pasar los cables, o pintar la cocina, etc. Es importante respetar la jerarquización de las unidades de trabajo, y que en cada nivel esté contenido el esfuerzo total del proyecto. Esta herramienta hace más sencillo gestionar luego el cronograma y el presupuesto del proyecto. La siguiente imagen muestra un ejemplo de EDT.

Veáse PMBOK 6.2 y 6.3

La primer tarea en la planificación de las actividades del proyecto es definirlas. El resultado final de este proceso es una lista detallada de todas las actividades y sus duraciones estimadas. Para poder realizar esta lista necesitamos una buena EDT realizada previamente. Para el estándar del PMI los nodos hoja (los nodos que no tienen hijos) en el gráfico de la EDT son denominados paquetes de trabajo. Cada paquete de trabajo puede tener un número (relativamente pequeño) de actividades asociadas.

En la práctica, y si nuestro proyecto no es excesivamente grande, los nodos finales de la EDT se corresponden con las actividades de nuestro proyecto. Lo importante es realizar la descomposición del trabajo a realizar de manera que la estimación que hagamos de las duraciones sea lo más acertada posible. Cualquier otro atributo relevante de las actividades (recursos humanos necesarios, herramientas para la tarea, etc.) debe aparecer en esta lista. La lista de hitos (distintos entregables para el cliente, fases completadas del proyecto, etc.) también son documentados.

Veáse PMBOK 6.3

Las actividades del proyecto deben secuenciarse de acuerdo a sus relaciones. Teniendo en cuenta la lista de actividades ya definida, deben analizarse las relaciones que existen entre las mismas. Para secuenciar las actividades y armar un cronograma a menudo se usa el método del camino crítico (CPM Critical Path Method). El CPM es un método que ayuda a calcular parámetros básicos del cronograma del proyecto. La manera gráfica de realizarlo es a través de un diagrama de red.

El cronograma del proyecto representa una línea base para el desarrollo y control del tiempo del proyecto. Comparamos el rendimiento y avance del proyecto contra el cronograma, y gestionamos los recursos de acuerdo a las desviaciones de lo planificado. Generalmente la herramienta esencial para esta tarea es un diagrama de Gantt completo que represente el estado actual real del proyecto. Comparando la ejecución real del proyecto con los plazos acordados durante la planificación podemos gestionar los recursos (humanos, herramientas, insumos) y ajustar las desviaciones que son casi ineludibles, o pactar nuevos plazos con los interesados del proyecto.