Está en la página 1de 78

Introducción

Fundamentos de la
Gerencia de Proyectos

Peter M. Yamakawa T.
Ph.D., MBA, Msc. Ing., PgMP., PMP.,RMP
pyamakawa@esan.edu.pe

Actualizado al 18/09/2018
Objetivos de aprendizaje

1 Entender la importancia de la gerencia de


proyectos

2 Explicar que es la gerencia de proyectos y sus


elementos clave

Conocer los errores clásicos en proyectos


3 respecto de las personas, procesos, productos
y tecnología
Agenda

¿Qué pasa con los proyectos?

Gerencia de proyectos

Ciclo de vida de proyectos

Procesos de dirección de proyectos

Errores clásicos
¿Qué pasa con los proyectos?
¿Qué es un proyecto?
Definición

- Es una combinación - Un propósito único


de recursos en un - Es temporal
tiempo determinado,
generalmente para una - Uso de múltiples
organización y para recursos
lograr un propósito - Debería contar con un
específico patrocinador o un
- Crea un producto, cliente principal
servicio o un resultado. - Incertidumbre

Atributos
Información sobre la gerencia de
proyectos

• Sólo el 55% de los proyectos finalizan cumpliendo el


presupuesto inicial del proyecto( PMI’s Pulse of the
Profession, 2015)

• Tom Peters nos dice: “Para ganar hoy debemos dominar el


arte de la gerencia de proyectos”

• 50% de los proyectos fallan por mala comunicación


interna (América Economía, 2015)
Información sobre la gerencia de
proyectos

• Actualmente, según el estudio de PMI, solo el 48% de los proyectos


son diseñados para responder a objetivos estratégicos.

• Además, se reporta una disminución en el éxito de los proyectos


desde el año 2012 (62% vs 64%) que lleva implícito un sobrecoste
(que cuantifica en 122 millones de dólares por cada mil millones
invertidos).

• En comparación con la encuesta realizada en el año 2015, más


proyectos están fallando, lo que resulta en una pérdida monetaria
significativa.

• Es hora de fortalecer la conversación sobre los beneficios de la


gestión de proyectos y su valor en la producción de mejores
resultados empresariales.

Fuente: PMI’s Pulse of the Profession,2016


Información sobre la gerencia de proyectos

Estado actual de los resultados de los proyectos


Ventajas de la gerencia de proyectos
Mejor control financiero, físico y recursos humanos

Mejora la relación con los clientes

Reduce lo tiempos de desarrollo

Reduce los costos

Mejora la calidad y la confiabilidad

Mayores márgenes

Mejora la productividad

Mejora la coordinación interna

Mejora el ambiente de trabajo


La triple restricción de la gerencia de
proyectos
Una visión expandida de las
“3 restricciones”

Alcance

Calidad Costo

Riesgo tiempo

Satisfacción al
cliente
Portafolio de proyectos

Portafolio

Portafolio Proyectos Programas

Programas Proyectos Programa Proyectos

Proyectos Proyectos Proyectos


Gerencia de Proyectos
¿Qué es gerencia de proyectos?

Es la aplicación de conocimientos,
habilidades, herramientas a las actividades
de los proyectos para satisfacer los
requerimientos de los proyectos

Los gerentes de proyectos trabajan para


satisfacer la triple restricción
10 áreas de gerencia de proyectos

Las áreas describen las competencias claves que todo gerente de


proyectos debe desarrollar:
• 4 áreas principales de conocimiento principales para lograr los
objetivos
(Gestión del alcance, tiempo, costo, calidad)
• 5 áreas de apoyo como medio por el cual los objetivos son
logrados
(Gestión de recursos humanos, comunicación, riesgo,
compras, interesados)
• 1 área de integración
Grupos de Interés
Gente involucrada en el proyecto o es afectada por sus
actividades, incluye:

Sponsor

Opositores Gerente
del del
proyecto proyecto

Grupos
de
Interés
Proveedores Equipo

Usuarios Clientes
Relación entre los interesados y el
proyecto
Herramientas y técnicas de gestión de
proyectos

Acta de
constitución

Ruta crítica, Definición


etc. del alcance

Estimación
EDT
de tiempos

Diagrama
de Gantt
“Super- herramientas”
Son las herramientas que tiene un alto uso y alto impacto en el
éxito del proyecto, tales como:
• Reporte de lecciones aprendidas
• Software
• Definición del alcance
• Reporte de los avances
• Requerimientos de cambios
• Kick-off meeting
• Diagrama de Gantt
¿Qué ayuda a tener éxito en los
Proyectos?

Apoyo de la alta Compromiso del Experiencia del


gerencia usuario gerente de proyectos

Claros objetivos de Infraestructura


Objetivos Reales
negocios estándar de Sw y Hw

Otros criterios como


hitos, apropiado plan,
Metodologías Estimaciones
equipo competente,
formales confiables
adueñarse del
proyecto
¿Qué hacen los ganadores?

Utilizar herramientas y técnicas de la


gerencia de proyectos (muchas
plantillas por ejemplo).

Dan énfasis en el negocio

Desarrollan un proceso simple de


gerencia de proyectos

Miden la salud del proyecto


utilizando métricas como satisfacción
del cliente, retorno de la inversión
Sugerencias para los gerentes de
proyectos

Deben tener Entender las


una serie de organizaciones
habilidades donde trabajan

Adecuarse a
los cambios

Ser capaz de
guiar al equipo
a cumplir los
objetivos del
proyecto
Las 10 habilidades y competencias de los
gerentes de proyectos

Habilidades Capaz de
Capaz de
para llegar a Liderazgo Integridad construir
escuchar
la gente confianza

Pensamiento Pensamiento
Entender y
Habilidad de Gestión de crítico, crítico,
balancear
comunicación conflicto solucionar solucionar
prioridades
problemas problemas
Diferentes habilidades en diferentes
situaciones

Proyectos altamente
Proyectos Grandes Proyectos novedosos
inciertos

Liderazgo, Gestión de riesgos, Liderazgo, manejo de


experiencia, gestión de las gente, visión,
planeamiento, manejo expectativas, confianza, manejo de
de gente, liderazgo, manejo de las expectativas,
comunicación, “team gente, habilidades de habilidades de
building” son los más planeamiento son los escuchar son los más
importantes más importantes importantes
Ciclo de Vida de los Proyectos
Estructura del ciclo de vida

Organización
Inicio
y preparación

Ejecución

Cierre
Costos y dotación de personal durante
el ciclo de vida del proyecto

Inicio Organización Ejecución Cierre


y preparación
Nivel de costo y personal

Salidas de la Acta de Plan de Entregables Documentos


gestión de constitución Dirección del Aceptados del Proyecto
proyectos Proyecto Aceptados

Tiempo
Impacto de los interesados, riesgos y la
incertidumbre

Alto

Influencia de los
interesados,
riesgo e incertidumbre
Nivel

Costo de los
cambios

Bajo

Tiempo
Fases del proyecto

Son las divisiones dentro del mismo proyecto, donde es


necesario un control adicional con el fin de gestionar
eficazmente la conclusión de un entregable mayor.

Las fases pueden completarse de manera secuencial, pero en


determinados casos de un proyecto pueden superponerse.

La estructuración de fases permite la división del proyecto en


subconjuntos lógicos para facilitar su dirección, planificación y
control.
Proyecto de una sola fase
Proyecto de tres fases

Proyecto de fases superpuestas


Activos de los procesos de la
organización

Son algunos o todos los activos


relativos a procesos de alguna o
todas las organizaciones
participantes en el proyecto que Estos activos contemplan planes,
puedan utilizarse para influir en el políticas, procedimientos y
éxito de un proyecto. lineamientos, formales e
informales.
Procesos de la organización

Procesos y procedimientos Base corporativa del


conocimiento
• Procesos estándar de la organización
• Lineamientos, instrucciones de • Base de datos para la medición de
trabajo, etc. procesos
• Lineamientos y criterios para adaptar • Archivo de proyectos
el conjunto de procesos • Información histórica y bases del
• Requisitos de comunicación de la conocimiento de lecciones aprendidas
organización • Base de datos sobre la gestión de
• Lineamientos del cierre del proyecto problemas y defectos
• Procedimientos de control financiero • Base del conocimiento de la gestión
• Procedimientos para la gestión de de la configuración
problemas y defectos • Base de datos financieros que
• Procedimientos de control de cambios contienen informaciones como horas
• Procedimientos de control de riesgos de trabajo, costos incurridos,
• Procedimientos para priorizar, aprobar presupuestos y déficit presupuestario.
y emitir autorizaciones de trabajo.
Procesos de Dirección de
Proyectos
Procesos de dirección de proyectos
El grupo de procesos de la gestión de
proyectos

Procesos de Proceso de
iniciación Planificación

Procesos de control Procesos de ejecución

Procesos de cierre
Grupos de procesos de la dirección de
proyectos
Grupo de procesos que interactúan en
una fase o proyecto
Procesos de Iniciación
Procesos de Iniciación

Compuesto por aquellos procesos realizados


para definir un nuevo proyecto o una nueva fase
de un proyecto existente al obtener la
autorización para iniciar el proyecto o fase.

Dentro de los procesos de inicio, es donde se


define el alcance, se comprometen los recursos
financieros iniciales, se identifican los
interesados internos y externos, y si no ha sido
nombrado se selecciona al director del proyecto.
Propósito

Alinear las expectativas de los


interesados con el propósito del
proyecto.

Dar visibilidad sobre el alcance y los


objetivos.

Mostrar cómo su participación en el


proyecto y sus fases asociadas puede
asegurar el logro de sus expectativas.
Procesos de Planificación

Compuesto por aquellos


procesos realizados para Desarrollan el plan para la
establecer el alcance total dirección del proyecto y los
del esfuerzo, definir y refinar documentos del proyecto
los objetivos y desarrollar la que se utilizarán para llevarlo
línea de acción requerida a cabo.
para alcanzar los objetivos.
Beneficios

Resulta sencillo conseguir la


aceptación y participación de los
interesados.

Trazar la estrategia y las tácticas,


como la línea de acción o ruta
para completar con éxito el
proyecto o fase.
Procesos de Ejecución

Compuesto por aquellos procesos realizados


para completar el trabajo definido en el plan para
la dirección del proyecto a fin de cumplir con las
especificaciones del mismo.

Implica coordinar personas y recursos, gestionar


las expectativas de los interesados, así como
integrar y realizar las actividades del proyecto
conforme al plan para la dirección del proyecto.
Procesos de Monitoreo y Control

Compuesto por aquellos procesos


realizados para establecer el Desarrollar la línea de acción
alcance total del esfuerzo, definir requerida para alcanzar los
y refinar los objetivos. objetivos.
Procesos de Monitoreo y Control

Compuesto por aquellos procesos requeridos


para rastrear, analizar y dirigir el progreso y el
desempeño del proyecto, para identificar
áreas en las que el plan requiera cambios y
para iniciar los cambios correspondientes.

El beneficio de este proceso es que el


desempeño del proyecto se mide y se analiza
a intervalos regulares y como consecuencia
de evento determinados condiciones de
excepción.
Procesos de Monitoreo y Control

Controla los cambios y


recomienda acciones
correctivas o preventivas para
anticipar posibles problemas.

Monitorear las actividades del


proyecto, comparándolas con el
plan para la dirección del
proyecto y con la línea base
para la medición del
desempeño del proyecto.

Influir en los factores que podrían


eludir el control integrado de
cambios o la gestión de la
configuración, de modo que
únicamente se implementen
cambios aprobados.
Procesos de Cierre

Verifica que los procesos


Compuesto por aquellos procesos definidos se han completado
realizados para finalizar todas las dentro de todos los Grupos de
actividades a través de todos los Procesos a fin de cerrar el
grupos de procesos de la proyecto o una fase del mismo y
dirección de proyectos. establece formalmente que el
proyecto o fase del mismo ha
finalizado.
Errores en los proyectos
Errores clásicos que se comenten en
los proyectos

PERSONAS PROCESOS

PRODUCTOS TECNOLOGÍA

Fuente: “Rapid development” Steve McConnel


Motivación débil o mediocre
Motivación débil
• Estudio tras estudio se ha mostrado que la motivación
probablemente tiene mayor efecto sobre la productividad y la
calidad que ningún otro factor.

Personal mediocre
• Después de la motivación la capacidad individual de los
miembros del equipo, así como sus relaciones como equipo,
probablemente tienen la mayor influencia en la
productividad.
Empleados problemáticos incontrolados

• Un fallo al tratar con personal problemático también


amenaza la velocidad de desarrollo.

• Un fallo al tomar una decisión cuando se trata con un


empleado problemático es una de las quejas mas
comunes que tienen los miembros del equipo respecto de
sus responsables.
Añadir mas personal a un proyecto
retrasado

Cuando un proyecto se alarga,


añadir mas gente puede quitar
mas productividad a los miembros
Esta es quizás el mas clásico de del equipo existente de la que
los errores clásicos. añaden los nuevos miembros.
Fred Brooks compara añadir
gente a un proyecto retrasado
con echar gasolina en un fuego
Oficinas repletas y ruidosas

• La mayoría de los desarrolladores consideran sus


condiciones de trabajo como insatisfactorias.
Alrededor del 60 por 100 indican que no tienen
suficiente silencio ni privacidad
Fricciones entre los clientes y los
desarrolladores
Las fricciones entre los clientes y los desarrolladores
pueden presentarse de distintas formas. A los clientes
puede parecerles que los desarrolladores no
cooperan cuando rehúsan comprometerse con el
plan de desarrollo que desean los clientes o cuando
fallan al entregar lo prometido.

A los desarrolladores puede parecerles que los


clientes no son razonables porque insisten en planes
irreales o cambios en los requerimientos después de
que estos hayan sido fijados.

En el caso medio, las fricciones entre clientes y


desarrolladores de software llegan a ser tan severas
que ambas partes consideran la cancelación del
proyecto.
Expectativas poco realistas

Una de las causas mas


comunes de fricciones entre
los desarrolladores y sus Una inspección de Standish Group
clientes o los directivos son las marcó las expectativas realistas
expectativas poco realistas como uno de los cinco factores
principales necesarios para
asegurar el éxito de los proyectos
internos de software de gestión
(Standish Group, 2013)
Falta de un patrocinador efectivo del
proyecto

Para soportar muchos de los aspectos del


desarrollo rápido es necesario un promotor del
proyecto de alto nivel, incluyendo una
planificación realista, el control de cambios y la
introducción de nuevos métodos de desarrollo.

El consultor Australiano Rob Thomsett afirma


que la falta de un promotor efectivo garantiza
virtualmente el fracaso del proyecto.
Falta de participación de stakeholders

Falta de participación de los implicados:


Todos los principales participantes del esfuerzo Falta de participación del usuario: La
de desarrollo de software deben implicarse en el inspección de Standish Group descubrió
proyecto. Incluyendo a los promotores, que la razón numero uno de que los
ejecutivos, responsables del equipo, miembros proyectos de Sistemas de Información
del equipo, personal de ventas, usuarios finales, tuviesen éxito es la implicación del
clientes y cualquiera que se juegue algo con el
proyecto.
usuario. (Standish Group, 2013)
Política antes que desarrollo

• Larry Constantine indicó que si hay cuatro equipos. Hay


cuatro tipos diferentes de orientaciones políticas.
• Los políticos están especializados en la gestión,
centrándose en las relaciones con sus directivos. Los
investigadores se centran en explorar y reunir
información.
Ilusiones
• Cuantas veces hemos escuchado cosas como estas a distintas
personas: “Ninguno de los miembros del proyecto cree
realmente que pueda completarse el proyecto de acuerdo
con el plan que tiene, pero piensan que quizás se trabajan
duro, y nada va mal, y tienen un poco de suerte, serán
capaces de concluir con éxito.”.
• Las Ilusiones no son sólo optimismo. Realmente consisten en
cerrar los ojos y esperara que todo funcione cuando no se
tienen las bases razonables para pensar que será así. Las
Ilusiones al comienzo del proyecto llevan a grandes
explosiones al final. Impiden llevar a cabo una planificación
coherente y pueden ser la raíz de mas problemas en el
software que todas las otras causas combinadas.
Errores clásicos que se comenten en
los proyectos

PERSONAS PROCESOS

PRODUCTOS TECNOLOGÍA

Fuente: “Rapid development” Steve McConnel


Planificación excesivamente optimista:
Fijar un plan excesivamente optimista
predispone a que el proyecto falle por Gestión de riesgos insuficientes
infravalorar el alcance del proyecto,
minando la planificación efectiva y Si no ejercemos una gestión activa de los
reduciendo las actividades criticas para el riesgos, con que solo vaya mal una cosa se
desarrollo, como análisis de requerimientos pasara de tener un proyecto con un
o el diseño. desarrollo rápido a uno con un desarrollo
También supone una excesiva presión para lento. El fallo de no gestionar uno solo de
los desarrolladores, quienes a largo plazo estos riesgos es un error clásico.
se ven afectados en su moral y su
productividad.
Fallo de los contratados
• Las empresas a veces contratan la realización de partes de
un proyecto cuando tienen demasiada prisa para hacer el
trabajo en casa. Pero los contratados frecuentemente
entregan su trabajo tarde, con una calidad inaceptable o que
falla al no coincidir con la especificación.
• El problema no esta en el abandono del plan, sino mas bien
en fallar al no crear un plan alternativo, y caer entonces en el
modo de trabajo de codificar y corregir.

Planificación insuficiente
• Si no planificamos para conseguir un desarrollo rápido, no
podemos esperar obtenerlo.
Abandono de la planificación bajo presión
• Los equipos de desarrollo hacen planes y rutinariamente
los abandonan cuando se tropiezan con un problema en
la planificación.
• El problema no está en el abandono del plan, sino mas
bien en fallar al no crear un plan alternativo, y caer
entonces en el modo de trabajo de codificar y corregir.

Pérdida de tiempo en el inicio difuso


• El inicio difuso es el tiempo que trascurre antes de que
comience el proyecto; este tiempo normalmente se
pierde en el proceso de aprobar y hacer el presupuesto.
Escatimar en las actividades iniciales
• Los proyectos que se aceleran intentando acortar las
actividades no esenciales, y puesto que el análisis de
requerimientos, la arquitectura y el diseño no producen
código directamente, son los candidatos fáciles.

Diseño inadecuado
• Un caso especial de escatimar en las actividades
iniciales es el diseño inadecuado. Proyectos acelerados
generan un diseño indeterminado, no asignando
suficiente tiempo para él y originando un entorno de alta
presión que hace difícil la posibilidad de considerar
alternativas en el diseño.
Escatimar en el control de calidad
• En los proyectos que se hacen con prisa se suele cortar
por lo sano, eliminando las revisiones del diseño y del
código, eliminando la planificación de las pruebas y
realizando solo pruebas superficiales.
• Acortar en un día las actividades de control de calidad al
comienzo del proyecto probablemente supondrá de 3 a
10 días de actividades finales .Esta reducción va contra
la velocidad de desarrollo.

Control insuficiente de la directiva

• Poco control de la directiva para detectar a tiempo los


signos de posibles retrasos en el plan, y los pocos
controles definidos al comienzo se abandonan cuando el
proyecto comenzó a tener problemas. Antes de encarrilar
un proyecto, en primer lugar debemos ser capaces de
decir si va por buen camino.
Convergencia prematura o excesivamente
frecuente
• Bastante antes de que se haya programado entregar un
producto, hay un impulso para preparar el producto para
la entrega, mejorar el rendimiento del producto, imprimir
la documentación final, incorporar entradas en el
sistemas final de ayuda, pulir el programa de instalación,
eliminar las funciones que no van a estar listas a tiempo
y demás.

Omitir tareas necesarias en la estimación

• Si la gente no guarda cuidadosamente datos de


proyectos anteriores, olvida las tareas menos visibles,
pero son tareas que se han de añadir. El esfuerzo
omitido suele aumentar el plan de desarrollo en un %20
o %30.
Planificar ponerse al día mas adelante
• Un tipo de estimación es responder inapropiadamente al
retraso del plan. Si hemos trabajado en un proyecto durante 6
meses, y hemos empleado tres meses en llegar al hito
correspondiente a los dos meses, ¿Que hacer? En muchos
proyectos simplemente se plantea recupera el retraso mas
tarde, pero nunca se hace.
Otro tipo de error en la reestimación se debe a cambios en el
producto. Si el producto que estamos construyendo cambia, la
cantidad de tiempo necesaria para construirlo cambiara
también.
Errores clásicos que se comenten en
los proyectos

PERSONAS PROCESOS

PRODUCTOS TECNOLOGÍA

Fuente: “Rapid development” Steve McConnel


Exceso de Requerimientos
• Algunos proyectos tiene mas requerimientos de los que
necesitan, desde el mismo inicio. La eficiencia se fija como
requisito mas a menudo de lo que es necesario, y puede
generar una planificación del software innecesariamente
larga.

Cambio de las prestaciones


• Incluso si hemos evitado con éxito los requerimientos
excesivos, los proyectos sufren como media sobre un %25
de cambios en los requerimientos a lo largo de su vida .
• Un cambio de este calibre puede producir un aumento en el
plan de al menos %25, lo que puede ser fatal para los
proyectos de desarrollo rápido.
Desarrolladores meticulosos

• Los desarrolladores encuentran fascinante la nueva tecnología,


y a veces están ansiosos por probar nuevas prestaciones de
su lenguaje o entorno, o por crear su propia implementación de
una utilidad bonita que han visto en otro producto, la necesite o
no su producto. El esfuerzo requerido para diseñar,
implementar, probar, documentar o mantener estas
prestaciones innecesarias alarga el plan.
Tiras y aflojas en la negociación
• Cuando un directivo aprueba un retraso en el plan e un
proyecto que progresa mas lento de lo esperado, y entonces
añade tareas completamente nuevas después de un cambio en
el plan, se produce una situación curiosa.
• La razón subyacente de esto es difícil de localizar, puesto que
el directivo que aprueba el retraso en el plan lo hace sabiendo
implícitamente que el plan estaba equivocado. Pero una vez
que se corrige, la misma persona realiza acciones explicitas
para volver a equivocarse. Esto solo puede ir en contra del
plan.
Desarrollo orientado a la investigación

Seymour Cray, el diseñador de los supercomputadores Cray, dijo


que no intentaba sobrepasar los limites de la ingeniería en mas de
dos áreas a la vez, por que el riesgo de fallo es demasiado alto.

Si el proyecto fuerza los limites de la informática por que necesita la


creación de nuevos algoritmos o de nuevas técnicas de
computación, no estamos desarrollando software; estamos
investigando en software. Los planes de desarrollo de software son
razonablemente predecibles; los planes en la investigación sobre
software ni siquiera son predecibles teóricamente.
Errores clásicos que se comenten en
los proyectos

PERSONAS PROCESOS

PRODUCTOS TECNOLOGÍA

Fuente: “Rapid development” Steve McConnel


Síndrome de la panacea
• Cuando un equipo de proyecto se aferra solo a una nueva
técnica, una nueva tecnología o un proceso rígido, y espera
resolver con ello sus problemas de planificación, esta
inevitablemente equivocado.

Cambiar de herramientas a mitad del proyecto


• Es un viejo recurso que funciona raramente. A veces puede
tener sentido actualizar incrementalmente dentro de la misma
línea de productos, de la versión 3 a la 3.1 o incluso a la 4.
Pero cuando estamos a la mitad de un proyecto, la curva de
aprendizaje, rehacer el trabajo y los inevitables errores
cometidos con una herramienta totalmente nueva,
normalmente anulan cualquier posible beneficio.
Sobreestimación de las ventajas del empleo de
nuevas herramientas o métodos

Las organizaciones mejoran raramente su


productividad a grandes saltos, sin importar cuantas
nuevas herramientas o métodos empleen o lo buenos
que sean.

Los beneficios de las nuevas técnicas son


parcialmente desplazados por las curvas de
aprendizaje que llevan asociadas, y aprender a
utilizar nuevas técnicas para aprovecharlas al máximo
lleva su tiempo.

Un caso especial de sobreestimaciones de las


mejoras se produce cuando se reutiliza código d e
proyectos anteriores. Este tipo de reutilización puede
ser una técnica muy efectiva, pero el tiempo que se
gana no es tan grande como se espera.
Cambiar de herramientas a mitad del
proyecto
• Es un viejo recurso que funciona raramente. A veces puede
tener sentido actualizar incrementalmente dentro de la misma
línea de productos, de la versión 3 a la 3.1 o incluso a la 4.
Pero cuando estamos a la mitad de un proyecto, la curva de
aprendizaje, rehacer el trabajo y los inevitables errores
cometidos con una herramienta totalmente nueva,
normalmente anulan cualquier posible beneficio.
Falta de control automático del código
fuente

• Un fallo en la utilización del control automático del código fuente


expone a los proyectos a riesgos innecesarios. Sin el, si dos
desarrolladores están trabajando en la misma parte del
programa, deben coordinar su trabajo manualmente. Deberían
ponerse de acuerdo para poner la ultima versión de cada
archivo en el directorio maestro y verificarlos con los demás
antes de copiarlas en este directorio. Pero invariablemente
alguno sobrescribirá el trabajo del otro.

• Se desarrolla nuevo código con interfaces desfasadas, y


después se tiene que re-diseñar el código al descubrir que se ha
utilizado una versión equivocada de la interfaz.
Como media, los cambios en el código fuente suelen ser de un
%10 al mes y con un control manual del código fuente no
deberían crecer.

También podría gustarte