Documentos de Académico
Documentos de Profesional
Documentos de Cultura
La Gestion de Un Proyecto Informatico PDF
La Gestion de Un Proyecto Informatico PDF
Proyecto: esfuerzo temporal que se lleva a cabo para crear un producto, un servicio o una obra.
1. Cada proyecto tiene un comienzo definido y un final definido
2. La duración de un proyecto es limitada aunque sea de años
3. Temporal NO es aplicable generalmente al producto, servicio o resultado creado por el
proyecto
Proyectos Operaciones
Similitudes Realizados por personas
Limitación de Recursos
Planificados – Ejecutados - Controlados
Diferencias Temporales Continuas
Únicos Repetitivas
Graduales
Finalidad Alcanzar el objetivo Respaldo al negocio
Finalización Concluye al alcanzar Adoptan nuevos
su objetivo objetivos
No concluyen
En Teoría
Un proyecto se considera exitoso los plazos estipulados, dentro de especificaciones requeridas.
En la Práctica
1. Excelente comunicación
2. Liderazgo, conocimiento y poder
3. Sigue una metodología probada
4. Mostrar resultados, dar calidad
5. Validar las estimaciones
6. Más y mejor conocimientos y experiencias
7. Hace ganar dinero
EDT (Estructura de descomposición del trabajo) Work Breakdown Structure o WBS, es una
estructura exhaustiva, jerárquica y descendente formada por las diferentes tareas (unidades de
trabajo) a realizar en un proyecto.
El diagrama de Gantt, gráfica de Gantt o carta Gantt es una herramienta gráfica cuyo objetivo es
mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un
tiempo total determinado.
Program Evaluation and Review Technique, PERT, es básicamente un método para analizar
las tareas involucradas en completar un proyecto dado, especialmente el tiempo para completar
cada tarea, e identificar el tiempo mínimo necesario para completar el proyecto total.
Método de la ruta crítica, Critical Path Method, CPM. Una ruta crítica es la secuencia de las
tareas de un proyecto con la mayor duración entre ellos, lo cual determina el tiempo más corto en
el que es posible completar el proyecto. La duración de la ruta crítica determina la duración del
proyecto entero. Cualquier retraso en un elemento de la ruta crítica afecta a la fecha de término
planeada del proyecto, y se dice que no hay holgura en la ruta crítica.
A diferencia del método PERT, el método de la ruta crítica usa tiempos ciertos (reales o
determinísticos). Sin embargo, la elaboración de un proyecto en base a redes CPM y PERT son
similares y consisten en:
1. Identificar todas las actividades que involucra el proyecto, lo que significa, determinar
relaciones de precedencia, tiempos técnicos para cada una de las actividades.
2. Construir una red con base en nodos y actividades (o arcos, según el método más usado),
que implican el proyecto.
3. Analizar los cálculos específicos, identificando las rutas críticas y las holguras de los
proyectos.
Diagrama de Gantt
En el eje Vertical: Las actividades que constituyen el trabajo a ejecutar. A cada actividad se hace
corresponder una línea horizontal cuya longitud es proporcional a su duración en la cual la
medición efectúa con relación a la escala definida en el eje horizontal conforme se ilustra.
Contenido
El diagrama de Gantt consiste en una representación gráfica sobre dos ejes; en el vertical se
disponen las tareas del proyecto y en el horizontal se representa el tiempo.
Características
1. Cada actividad se representa mediante un bloque rectangular cuya longitud indica su
duración; la altura carece de significado.
2. La posición de cada bloque en el diagrama indica los instantes de inicio y finalización de las
tareas a que corresponden.
3. Los bloques correspondientes a tareas del camino crítico acostumbran a rellenarse en otro
color (en el caso del ejemplo, en rojo).
Ejemplo
Finalmente, una vez realizados los cálculos del proyecto utilizando un sistema adecuado, como el
diagrama PERT o el Roy, resulta conveniente destacar con un color distinto las tareas con margen
total 0, para poder identificar con facilidad los caminos críticos.
La ventaja principal del gráfico de Gantt radica en que su trazado requiere un nivel mínimo de
planificación. Los gráficos de Gantt se revelan muy eficaces en las etapas iniciales de la
planificación. Sin embargo, después de iniciada la ejecución de la actividad y cuando comienza a
efectuarse modificaciones, el gráfico tiende a volverse confuso. Por eso se utiliza mucho la
representación gráfica del plan, en tanto que los ajustes (re planificación) requieren por lo general
de la formulación de un nuevo gráfico. Para superar esa deficiencia se crearon dispositivos
mecánicos, tales como cuadros magnéticos, fichas, cuerdas, etc., que permite una mayor
flexibilidad en las actualizaciones. Aún en términos de planificación, existe todavía una limitación
bastante grande en lo que se refiere a la representación de planes de cierta complejidad. El Gráfico
de Gantt no ofrece condiciones para el análisis de opciones, ni toma en cuenta factores como el
costo. Es fundamentalmente una técnica de pruebas y errores. No permite, tampoco, la
visualización de la relación entre las actividades cuando el número de éstas es grande.
el periodo durante el cual el recurso estará disponible para el trabajo (representado por una línea
fina) y la carga total de trabajo asignada a este recurso (representado por una línea gruesa).
PERT Y CPM
Un diagrama de red es cualquiera de las representaciones que vinculan las actividades y los
eventos de un proyecto entre sí para reflejar las interdependencias entre las mismas. Una actividad
o evento puede presentar interdependencias con actividades o eventos sucesores, predecesores,
o en paralelo. Los más importantes son:
PERT (Program Evaluation and Review Technique). Desarrollado por la Special Projects Office de
la Armada de EE.UU. a finales de los 50s para el programa de I+D que condujo a la construcción
de los misiles balísticos Polaris. Está orientada a los sucesos o eventos, y se ha utilizado
típicamente en proyectos de I+D en los que el tiempo de duración de las actividades es una
incertidumbre. Dado que las estimaciones de duración comportan incertidumbre se estudian las
distribuciones de probabilidad de las duraciones. Con un diagrama PERT se obtiene un
conocimiento preciso de la secuencia necesaria, o planificada para la ejecución de cada actividad y
utilización de diagramas de red.
Se trata de un método muy orientado al plazo de ejecución, con poca consideración hacia al coste.
Se suponen tres duraciones para cada suceso, la optimista a, la pesimista b y la normal m;
suponiendo una distribución beta, la duración más probable: t = (a + 4m + b) / 6 .
Camino crítico
El camino crítico en un proyecto es la sucesión de actividades que dan lugar al máximo tiempo
acumulativo.
Determina el tiempo más corto que podemos tardar en hacer el proyecto si se dispone de todos los
recursos necesarios. Es necesario conocer la duración de las actividades.
Principios
Estos tres principios deben respetarse siempre a la hora de dibujar una malla PERT:
1. Principio de designación sucesiva: se nombra a los vértices según los números naturales,
de manera que no se les asigna número hasta que han sido nombrados todos aquellos de
los que parten aristas que van a parar a ellos.
2. Principio de unicidad del estado inicial y el final: se prohíbe la existencia de más de un
vértice inicial o final. Sólo existe una situación de inicio y otra de terminación del proyecto.
3. Principio de designación unívoca: no pueden existir dos aristas que tengan los mismos
nodos de origen y de destino. Normalmente, se nombran las actividades mediante el par
de vértices que unen. Si no se respetara este principio, puede que dos aristas recibieran la
misma denominación
Red PERT.
Cada nodo contiene la siguiente información sobre la actividad:
Nombre de la actividad
Duración esperada de la actividad (t)
Tiempo de inicio más temprano (ES = Earliest Start)
Tiempo de término más temprano (EF = Earliest Finish)
Tiempo de inicio más tardío (LS = Latest Start)
Tiempo de término más tardío (LF = Latest Finish)
Holgura de la Actividad (H)
Por convención los arcos se dibujan siempre con orientación hacia la derecha, hacia el nodo de
término del proyecto, nunca retrocediendo. El dibujo de una malla PERT se comienza en el nodo
de inicio del proyecto. A partir de él se dibujan las actividades que no tienen actividades
precedentes, o sea, aquellas que no tienen que esperar que otras actividades terminen para poder
ellas iniciarse. A continuación, se dibujan las restantes actividades cuidando de respetar la
precedencia entre ellas. Al terminar el dibujo de la malla preliminar, existirán varios nodos ciegos,
nodos terminales a los que llegan aquellas actividades que no son predecesoras de ninguna otra,
es decir aquellas que no influyen en la fecha de inicio de ninguna otra, éstas son las actividades
terminales y concurren por lo tanto al nodo de término del proyecto. para esto no es necesario
utilizarlo
El tiempo de inicio más tardío “LS” (Latest Start) y de término más tardío “LF” (Latest finish) para
cada actividad del proyecto, se calculan desde el nodo de término retrocediendo hacia el nodo de
inicio del proyecto según la siguiente relación:
Donde (t) es el tiempo esperado de duración de la actividad y donde LF queda definida según la
siguiente regla:
Regla del tiempo de término más tardío:
El tiempo de término más tardío, LF, de una actividad específica, es igual al menor de los tiempos
LS de todas las actividades que comienzan exactamente después de ella.
El tiempo de término más tardío de las actividades que terminan en el nodo de término del
proyecto es igual a la duración esperada del proyecto (T).
H = LF – EF
o bien
H = LS – ES
Actividades críticas
Se denomina actividades críticas a aquellas actividades cuya holgura es nula y que por lo tanto, si
se retrasan en su fecha de inicio o se alargan en su ejecución más allá de su duración esperada,
provocarán un retraso exactamente igual en tiempo en la fecha de término del proyecto.
Rutas críticas
Se denomina rutas críticas a los caminos continuos entre el nodo de inicio y el nodo de término del
proyecto, cuyos arcos componentes son todas actividades críticas. Las rutas críticas se nombran
por la secuencia de actividades críticas que la componen o bien por la secuencia de nodos por los
que atraviesa. Nótese que un proyecto puede tener más de una ruta crítica pero a lo menos tendrá
siempre una.
Otras consideraciones:
i j
El evento inicial se llama i y el evento final se denomina j. El evento final de una actividad será el
evento inicial de la actividad siguiente. Las flechas no son vectores, escalares ni representan
medida alguna. No interesa la forma de las flechas, ya que se dibujarán de acuerdo con las
necesidades y comodidad de presentación de la red. Pueden ser horizontales, verticales,
ascendentes, descendentes curvas, rectas, quebradas, etc.
En los casos en que haya necesidad de indicar que una actividad tiene una interrelación o
continuación con otra se dibujará entre ambas una línea punteada, llamada liga, que tiene una
duración de cero
La liga puede representar en algunas ocasiones un tiempo de espera para poder iniciar la
actividad siguiente
Introducción
Objetivos
4. Saber cuáles son las decisiones más habituales que se han de tomar en el
proceso de control de un proyecto informático y los aspectos que más las
condicionan.
5. Conocer las herramientas informáticas que ayudan tanto en el proceso de
planificación del proyecto, como en el de seguimiento y control de una
planificación ya efectuada.
6. Obtener una visión inicial de los problemas de aseguramiento de la calidad
del Software (software quality assurance ) y, en definitiva, de la dificultad
de obtener Software seguro, fiable y de calidad
Una vez determinada la voluntad de iniciar un proyecto informático, las etapas que
caracterizan la gestión son dos: la primera es la calificación inicial (estimación de costes y
planificación temporal) y la segunda es el desarrollo (seguimiento y control del proyecto,
tal vez acompañados de nuevas estimaciones y planificaciones) para llegar, de una
manera o de otra, con éxito o sin él, al final o cierre definitivo del proyecto. Una vez
conocida la amplia problemática de la estimación de costes, ahora planificaremos en el
tiempo las diferentes tareas o actividades de las que consta el proyecto. Cabe mencionar
que la planificación temporal de proyectos a partir de su descomposición en tareas (WBS)
y la estimación de la duración de cada una es un proceso suficientemente conocido y que
los proyectos informáticos de construcción de software comparten con muchos otros
proyectos de ingeniería. Por otra parte, como veremos, salvo una particular manera de
tener en cuenta los recursos (las personas que forman el equipo del proyecto), no se dan
diferencias esenciales con otros proyectos de ingeniería. Comenzamos con la exposición
breve y sintética de conceptos tradicionales de la planificación temporal de actividades
como la técnica del PERT y el método del camino crítico (CPM) y después analizamos el
caso general de la planificación temporal de proyectos informáticos.
El fundamento central de las técnicas del PERT es la representación gráfica del proyecto
en un diagrama que muestre las relaciones y, sobre todo, las precedencias entre las
tareas que constituyen el proyecto. Este diagrama, que algunos denominan diagrama
PERT, en el fondo no es más que un grafo de precedencias de actividades que a menudo
se llama red de actividades (activity network) o, también, diagrama de precedencias
A menudo, los dos métodos se pueden tratar conjuntamente, tal como haremos en esta
exposición simplificada. Conviene advertir que, aunque aquí se habla de tareas o
actividades indistintamente, a menudo la nomenclatura más habitual utiliza el término
actividades cuando se refiere a PERT, aunque actualmente la elección suele depender de
la manera como se haya traducido el concepto en la herramienta informática de la que
nos ayudamos a la hora de llevar a cabo la planificación de un proyecto. El conjunto de
las técnicas PERT y el método del camino crítico (CPM) proporcionan herramientas
cuantitativas que permiten determinar lo siguiente:
1. El camino crítico del proyecto, que es la secuencia o cadena de actividades que
determina la duración total del proyecto.
2. Las estimaciones de tiempos más probables, tanto para la totalidad del proyecto
como para el inicio y el final de cada una de las tareas o actividades individuales.
3. Los márgenes de tiempo que se dan para cada tarea o actividad individual y que
no impliquen un retraso del proyecto.
Pongamos un ejemplo, que es la manera más clara de verlo. Para no tener que realizar
un diagrama complejo, imaginamos un pequeño proyecto del cual hemos efectuado una
descomposición en diez actividades, como las que se indican en la tabla siguiente
Conviene, tal como se lleva a cabo aquí, incluir siempre las actividades de inicio y final,
puramente ficticias y con duración cero. La tabla nos ofrece para cada actividad un
nombre, una identificación numérica (de uno a diez), la duración estimada de la actividad
(en unidades arbitrarias; por ejemplo, en semanas) y las tareas que son inmediatamente
anteriores e imprescindibles para poder empezar cada actividad en concreto
(precedencias).Si se quiere, se puede imaginar que se trata de construir un sistema
informático determinado que utiliza datos que ya tenemos (recogidos en la actividad 5) y
que utiliza una serie de drivers diferentes (que se seleccionan en la actividad 3 y se
prueban en la actividad 6) para acceder a periféricos o a aquello que sea necesario. De
hecho, el proyecto en sí no es importante, ya que se trata de un ejemplo ficticio para
ilustrar el PERT y el CPM. Si se dispone de estos datos (actividades, duración estimada y
precedencias) se puede dibujar un grafo como el de la figura de la página siguiente. Como
se puede ver en el diagrama, las flechas marcan las relaciones de precedencia que
existen entre las actividades, mientras que los nudos son las actividades, de las cuales se
han recogido también una serie de datos: el número identificador, el nombre de la
actividad y la duración estimada (puesta entre paréntesis dentro del nudo).Sobre cada
nudo se ha añadido también la información que sale directamente de la explotación del
diagrama de precedencias: las semanas de inicio y final de cada actividad. Conviene
darse cuenta de que la actividad final tiene como precedentes todos los arcos pendientes
del diagrama.
Por ejemplo, la actividad 1 (inicio) empieza en la semana cero y, al tener una duración
nula, termina también en la semana cero. Pero la actividad 2 (establecer los
requerimientos) comienza en la semana cero (justo después de la actividad precedente,
inicio) y finaliza al final de la semana tres, ya que dura precisamente tres semanas. Del
mismo modo, la actividad 4 (realizar el diseño no puede iniciarse hasta que no termine la
precedente (la 2, establecer los requerimientos), es decir, no puede empezar hasta que
En el diagrama, el camino crítico está marcado por flechas continuas. Por otra parte, el
diagrama PERT nos permite ver que existen actividades que no son tan decisivas en la vida del proyecto.
Por ejemplo, la actividad 6 (probar los drivers) tiene marcados un inicio y un final (2, 8). Es decir, se
puede comenzar a efectuar una vez finalizada la segunda semana del proyecto (justo cuando
acabala actividad precedente 3, Seleccionar los drivers) y, si se cumplen las estimaciones de duración,
terminará al final de la semana ocho. Ahora bien, la actividad 9 (probar el producto), de la cual la 6
es precedente, tiene también como precedente la actividad 7 (codificar); y ello provoca que no
pueda empezar hasta que no haya finalizado la semana once y que la actividad 6 tenga un margen de
tres semanas (11−8=3), de manera que no será nada crítica. Es decir, si la actividad 6 (probar los
Drivers) tardara siete semanas en lugar de las seis semanas estimadas, el proyecto
duraría también quince semanas, ya que la actividad 6 no forma parte del camino crítico y,
como se ve en el diagrama, tiene un margen de tres semanas (podría empezar más tarde
o durar más de lo que se había estimado).Con vistas a la gestión de un proyecto es muy
importante saber qué actividades son críticas (es decir, qué actividades forman parte del
camino crítico) y cuáles no. Por otra parte, conviene remarcar que las actividades no
críticas disponen de un margen que permite que el planificador acomode mejor los
recursos y, sobre todo, que la buena gestión del proyecto pase por el control estricto de
las actividades que forman parte del camino crítico.
que se utiliza desde hace más tiempo, ya que es lo más conocido y familiar. Una vez
explicado esto, debería quedar claro que si los ejemplos de este módulo se presentan en
MS-PROJECT es únicamente porque esta herramienta ha estado disponible, pero no
porque exista alguna preferencia que se pueda generalizar a otros usuarios. Lo que
importa de las herramientas informatizadas para la ayuda a la planificación de
proyectos es que todas ofrecen la posibilidad de mostrar el diagrama PERT (o red
de actividades) y marcar, además, el camino crítico de manera automática.
También ofrecen una gestión de recursos completa y un montón de diagramas y
listas (que aumentan día a día) que permiten incluso realizar una presentación
brillante y muy profesional de la planificación de un proyecto.
En el caso del proyecto ficticio que se ha utilizado para exponer el PERT y el CPM, el
diagrama de Gantt sería el que se muestra en la figura siguiente
Realizar el diagrama de Gantt o PERT (red de actividades), preferentemente con una herramienta
informatizada para la ayuda a la planificación de proyectos. Para finalizar, es importante saber
que, tal como se ha llevado a cabo con las actividades Inicio y Final, de duración nula,
conviene añadir siempre algunas actividades ficticias con duración nula como hitos de
control para establecer momentos concretos en los que es necesario recopilar los datos y
efectuar un balance de la gestión del proyecto. Cuando el proyecto dispone de fases y
etapas diferentes, añadir un hito de control al final de cada fase sería lo más correcto,
aunque muchas veces se ponen hitos temporales de control: uno cada dos semanas, uno
cada mes, etc., según la duración total del proyecto.
Conviene señalar que a la hora de establecer precedencias, las hay que son lógicas y las
hay que surgen, en el caso concreto de los proyectos informáticos, de la gestión de los
recursos. Por ejemplo, en el diagrama de Gantt de la figura anterior hemos imaginado que es posible
efectuar simultáneamente las tareas 2 (establecer los requerimientos) y 3 (seleccionar los drivers). Sin
embargo, si las dos las debe realizar la misma persona, este diagrama de Gantt nos dice que esta
persona tiene una jornada de dieciséis horas y no de ocho como es habitual. No parece, pues,
posible.
En el caso de los proyectos informáticos de construcción de software, los recursos son las personas,
los profesionales informáticos que forman el equipo del proyecto. Se ha de procurar que nadie deba
trabajar más de una jornada por culpa de una planificación incompleta que no ha tenido en cuenta los
recursos. De hecho, el diagrama de Gantt de la figura anterior sería realista si imaginamos
que disponemos de tres personas en el equipo del proyecto:
1. Una primera persona podría llevar a cabo las tareas 2 (establecer los
requerimientos), 4
2. (realizar el diseño), 7 (codificar) y 9 (probar el producto).
3. Un segundo miembro del equipo se podría encargar de las tareas 3 (seleccionar
los drivers ) y 6 (probar los drivers ) y, tal vez, participar también en la actividad 9
(probar el producto).
4. Para no tener problemas de jornada doble, una tercera persona del equipo debería
encargarse de las actividades 5 (recoger datos) y 8 (elaborar la documentación).La
figura siguiente muestra una modificación sencilla en el caso de que el equipo del
proyecto estuviera formado por dos miembros. Para evitar jornadas dobles de los
miembros del equipo, se han tenido que introducir nuevas precedencias: provocar
que la actividad 5 (recoger datos) dependa de la 6 (pro-bar los drivers) y, también,
que la actividad 8 (Elaborar la documentación) dependa de la 5 (recoger datos),
para conseguir que las realice la misma persona
Cabe decir que, aunque en este ejemplo no ha ocurrido, estas precedencias adicionales
suelen cambiar a menudo el camino crítico e incluso la duración global del proyecto. De
hecho, a la hora de planificar un proyecto se juega con los recursos disponibles (teniendo
en cuenta el coste) y las precedencias de actividades hasta que se encuentra un
resultado aceptable.
Una vez iniciado el proyecto informático, la tarea de gestión consiste en conseguir que las
previsiones se cumplan y, en caso de que no sea así, poder detectar lo antes posible las
desviaciones que se deben producir para poder encontrarles una solución. Para conseguir
En los hitos de control introducidos en la planificación (bien sea al final de fases o etapas
de proyecto, o bien de manera periódica) es cuando debemos plantearnos, entre otras
cosas, lo siguiente:
1. Si conviene rehacer la descomposición del proyecto en tareas (WBS) o no,
posiblemente con la intención de incluir algunas no previstas en el momento inicial,
pero que son totalmente necesarias e imprescindibles a medida que avanza el
proyecto
Como se dice en otro módulo, los problemas de una deficiente calificación inicial se
intentan “resolver” demasiadas veces de puertas afuera, haciendo todo lo posible para
cumplir con los plazos y el presupuesto a fuerza de reducir las funcionalidades del
proyecto, sobre todo las funcionalidades de calidad. Ésta es, evidentemente, una solución
totalmente falsa que simplemente aplaza los problemas hasta la fase de mantenimiento,
al mismo tiempo que consigue a menudo que los problemas se conviertan en mucho más
graves y que tengan una solución mucho más difícil.
Para poder llevar a cabo una comparación correcta entre la realidad y la previsión, es
necesario “saber cómo va” el proyecto y, con esta finalidad, se deben recoger datos de su
desarrollo. Con estos datos del seguimiento será posible tener elementos para tomar
decisiones de cambio de los objetivos del proyecto y, en definitiva, controlar el desarrollo.
La práctica habitual es recoger estos datos del seguimiento en unas hojas de actividad.
Conviene recoger de manera individual por cada tarea y cada persona involucrada estos
datos de seguimiento, a partir de los cuales el jefe de proyecto debe elaborar los datos
globales que permiten construir un informe de situación del proyecto. Este informe se
suele llevar a cabo para cada uno de los hitos de control establecidos
Cuando una tarea finaliza, el jefe de proyecto puede saber el esfuerzo real que ha
supuesto realizarla y lo puede comparar con el esfuerzo previsto, para ver si las
estimaciones de productividad eran optimistas, pesimistas o realistas. El hecho de
disponer de esta productividad real es precisamente lo que debe permitir anticipar los
problemas. Con los datos reales obtenidos de la hoja de actividad, el jefe de proyecto
realiza el seguimiento, a menudo mediante herramientas informatizadas que permiten,
para cada actividad del proyecto, introducir las fechas reales del trabajo acabado o el
porcentaje del trabajo hecho en cada momento. Estas herramientas ofrecen también una
gran cantidad de listas y gráficos que, una vez escogidos los que son útiles, ayudan a las
tareas de seguimiento y control del proyecto
La ley de Brooks
Según el propio libro de Brooks, la ley es una "frívola sobre simplificación", pero se hace
eco de la idea. Brooks destaca dos factores principales que explican el porqué de la ley:
La ley de Brooks se cita a menudo para justificar que los proyectos no se terminan a
tiempo, a pesar de los esfuerzos gestores. Sin embargo, hay algunos puntos clave de la
ley de Brooks que permiten excepciones y abren la puerta a posibles soluciones.
El primer punto es que la ley de Brooks se suele aplicar a proyectos que tienen retraso.
Se puede volver a controlar (o mantener bajo control) si se refuerza el equipo en fases
previas. También es importante determinar si un proyecto se encuentra realmente en
retraso o si las estimaciones iniciales fueron demasiado optimistas, algo frecuente.
Corregir la planificación es la mejor manera de disponer de una ventana de tiempo fiable y
útil para finalizar el proyecto. La cantidad, calidad y papel de la gente que se incorpora al
proyecto son factores a tener en cuenta. Una vía simple de evitar la ley en un proyecto en
retraso es añadir más gente de la necesaria, de forma que la capacidad extra compensa
el overhead en comunicación y formación. Los buenos programadores o especialistas se
pueden incorporar con menos necesidad de tiempo para su formación. También se puede
incorporar personal para realizar otras tareas relacionadas con el proyecto, por ejemplo
documentación o garantía de calidad en caso de que la tarea esté disponible, así se
disminuye el tiempo de la rampa de subida. Una buena labor de gestión y desarrollo
también ayuda a reducir el impacto de la ley de Brooks. Las prácticas modernas de
integración continua, desarrollo guiado por pruebas, y desarrollo iterativo reducen
significativamente el overhead de comunicación entre los desarrolladores, permitiendo
mejor escalabilidad. También nuevas herramientas para el desarrollo de software y su
documentación son de ayuda a minimizar el tiempo de rampa de subida, haciendo más
sencilla la incorporación al proyecto. Los patrones de diseño simplifican la distribución del
trabajo, dado que el equipo completo puede realizar el trabajo dentro del patrón que se le
asignó. Los patrones de diseño definen las reglas que han de seguir los programadores,
simplifica la comunicación por medio del uso de un lenguaje estándar y proporciona
consistencia y escalabilidad. Finalmente, una buena segmentación ayuda minimizando el
overhead entre los miembros del proyecto. Los problemas menores se resuelven en
equipos pequeños y un equipo superior es responsable de la integración del sistema.
Para poder trabajar así es necesario segmentar el problema de forma correcta; en caso
contrario, puede empeorar el problema, impidiendo la comunicación entre los
programadores que trabajan en diferentes partes del problema que están directamente
relacionados, aunque el plan del proyecto afirme que no los están. Algunos autores
véase, por ejemplo, Creating a Software Engineering Culture de Karl E. Wiegers – han
recalcado la importancia de los aspectos sociales y políticos del clima de trabajo como
determinantes de la efectividad de los programadores individuales y del equipo del
proyecto como un todo. En lugar de depender de "héroes" para llevar a cabo la tarea con
esfuerzos extraordinarios, Wiegers afirma que un equipo de individuales de cualidades
ordinarias pueden proveer resultados a tiempo de forma periódica con el ambiente de
trabajo correcto. Los esfuerzos para mejorar la efectividad de los equipos puede mitigar
sino eliminar, las consecuencias de la ley de Brooks.
Una teoría que proviene de la experiencia del autor de la obra The Mythical Man-Month
(1975) como director del proceso de construcción del sistema operativo de IBM 360. Es
necesario entender esta advertencia en el sentido de que no se pueden intercambiar
hombres y meses. Y también se debe entender que la ley no es algo matemático, sino
sólo una advertencia para los que todavía no han captado el mito del hombre-mes.
Resumen