Caso: Dirección de un Proyecto

Del libro “Desarrollo y gestión de Proyectos Informáticos”, Steve McConnel, Mc Graw Hill
(Se sugiere fuertemente comprar el libro)

1 Mike, un responsable técnico de Giga Safe, estaba comiendo en su oficina y mirando por la
ventana una brillante mañana de abril.
2. «¡Felicidades! ¡Mike ya tienes los fondos para el programa Giga-Quote!» Era Bill, el jefe de
Mike en Giga, una compañía de seguros médicos. «Al comité ejecutivo le ha gustado la
idea de automatizar nuestras cuotas de seguro médico. Y también la idea de volcar cada
noche las cuotas del día en la oficina principal para que siempre tengamos al día los
últimos valores de ventas. Ahora tengo una reunión, pero podemos discutir los detalles más
adelante. Buen trabajo!»
3. Mike escribió la propuesta para el programa Giga-Quote meses antes, pero estaba
pensada como un programa para un solo PC, sin ninguna capacidad de comunicación con
la oficina principal. Perfecto, ésta era la oportunidad de dirigir un proyecto cliente-servidor
en un moderno entorno GUI (interfaces gráficas de usuario), lo que siempre había querido
hacer. El proyecto llevaría al menos un año, y lo ocuparía a tiempo completo. Mike
descolgó el teléfono y marcó el número de su esposa. «Cariño, esta noche cenaremos
fuera para celebrarlo»
4. A la mañana siguiente, Mike quedó con Bill para discutir el proyecto, «Vamos a ver, Bill.
¿Que pasa? Esto no se parece a la propuesta en la que he trabajado .»
5. Bill se sintió inseguro. Mike no había participado en las revisiones de la propuesta, pero no
hubo tiempo de avisarle. Cuando el comité ejecutivo estudió el programa Giga-Quote,
tomaron los mandos. «Al comité ejecutivo le gustó la idea de construir software para
automatizar las cuotas de seguros médicos. Pero querían que se pudieran transferir
automáticamente las cuotas locales al computador central. Querían tener hecho el sistema
antes de que se hagan efectivas las nuevas cuotas del 1 de enero. Adelantaron la fecha de
finalización del software que propusisteis del 1 de marzo al 1 de noviembre, con lo que se
acortó el plan propuesto a seis meses.»
6. Mike había estimado que el trabajo llevaría 12 meses. No creyó que tuviera la suerte de
acabar en 6 meses, y así se lo dijo a Bill. «Vamos a ver si me he enterado», dijo Mike.
«Parece que estás diciéndome que el comité añadió requisitos de comunicaciones a gran
comunicaciones a gran escala y ha acortado el plan de 12 a 6 meses»
7. Bill se encogió de hombros. «Sé que será un reto, pero tu eres creativo y creo que puedes
con todo. Han aprobado el presupuesto que querías, y añadir el enlace de comunicaciones
no debe ser difícil. Pedisteis 36 personas mes y las tienes. Puedes reclutar, a quien quiera
que necesites para el proyecto e incrementar el tamaño del equipo» Bill le dijo que hablase
con algún otro desarrollador y buscasen la forma de entregar el software a tiempo.
8 Mike se reunió con CarI, otro responsable técnico, y buscaron la forma de acortar el plan.
«¿Por qué no usas C++ y diseño orientado a objetos?-», comentó Carl. »Serás más
productivo que con C, y el plan se acortará en uno o dos mese.» A Mike le pareció bien.
Carl también conocía una herramienta de elaboración de informes que supuestamente
acortaba el tiempo de desarrollo a la mitad. El proyecto tenía bastantes informes, y por
tanto esos dos cambios los llevarían hasta los 9 meses. Consiguieron hardware nuevo y
más rápido, y esto les ahorraba un par de semanas. Si realmente podía reclutar a
desarrolladores de primerísima categoría, podría bajar a 7 meses- Esto era suficientemente
ajustado. Mike comentó sus progresos a Bill.
9. «Mira», dijo Bill, «dejar el plan en 7 meses está bien, pero no es suficiente. El comité dejó
claro que el plazo de entrega eran de 6 meses. No me dieron opción. Puedo daros el

1
 hardware que necesitáis, pero tú y tu equipo tenéis que encontrar una forma de reducir el
plan a 6 meses, o tendréis que hacer algunas horas extra para palia diferencia».
10. Mike se planteó el hecho de que su estimación inicial sólo fue una aproximación y pensó
que quizás podría bajarla a 6 meses. «De acuerdo, Bill buscare un par de personas
externas espabiladas para el proyecto. Quizás pueda encontrar gente con experiencia en
comunicaciones para que nos ayude en la descarga de datos desde el PC al mainframe»
11. El 1 de Mayo Mike había formado el equipo, Jill Sue y Tomas eran buenos desarrolladores
de la casa, y fueron liberados. Completó el equipo con Keiko y Chip, dos contratados
externos. Keiko tenía experiencia tanto en PC como en los mainframe que tenía que
conectarse, Jill y Tomas habían entrevistado. a Chip y no querían contratarlo, pero Mike lo
impuso. Tenía experiencia en comunicaciones y estaba disponible, así que Mike lo
contraté.
12. En la primera reunión del equipo, Bill dijo que el programa Giga-Quote era
estratégicamente importante para Giga Safe Corporation. Algunos de los magnates de la
compañía estarían pendientes de ellos. Si tenían éxito serían recompensados. Dijo que
estaba seguro de que lo conseguirían.
13. Después de lo ánimos infundidos por el discurso de Bill, Mike se sentó con el equipo y
mostró el plan. El comité ejecutivo les había proporcionado una especificación aproximada,
y emplearon las siguientes 2 semanas en completar las lagunas. Después se emplearían 6
semanas en el diseño, lo que dejaba 4 meses para la construcción y la prueba. Su
estimación aproximada fue que el producto final tendría unas 30.000 líneas en C++. Todos
los asistentes asintieron, dando su conformidad. Era ambicioso, pero lo sabían cuando se
comprometieron con el proyecto.
14. A la semana siguiente, Mike se reunió con Stacy, la responsable de la prueba. Indico que
debería tener partes del producto terminadas para probarlas no después de el 1 de
septiembre, con el propósito de tener un producto con las funciones el 1 de Octubre Mike
estaba de acuerdo.
15. El equipo acabó la especificación de los requerimientos rápidamente, y se metió en el
diseño. Obtuvieron un diseño que parecía hacer buen uso de las prestaciones de C++
16. Acabaron el diseño el 15 de Junio, adelantándose al plan, y comenzaron a codificar como
locos para llegar al objetivo de tener la primera versión de prueba el 1 de septiembre El
trabajo en el proyecto no era una balsa de aceite. Ni a Jill ni a Tomas les gustaba Chip, y
Sue se quejaba de que no quería que nadie se acercase a su código. Mike atribuyó los
choques de personalidades a las muchas horas de trabajo. No obstante, a primeros de
agosto, le indicaron que estaba hecho entre el 8 5 y 90 por 1 00.
17. A mitad de agosto, el departamento actuarial dio las tasas para el año siguiente, el equipo
descubrió que tenía que modificar completamente la estructura para las nuevas tasas. El
nuevo método de tasación necesitaba realizar preguntas sobre hábitos de ejercicio, en la
bebida, en la comida, actividades de ocio y otros factores que no se habían incluido antes
en las formas de tasación. Pensaron que C++ debía protegerlos de los efectos de esos
cambios. calcularon que solo tendrían que incluir nuevos valores en las tablas de tasas.
Pero tendrían que cambiar el diálogo de entrada, el diseño de las bases de datos, el
acceso a las bases de datos y los objetos de comunicaciones para adaptarlos a la nueva
estructura. Como el equipo estaba resuelto porque tenía que reajustar su diseño, Mike dijo
a Stacy que se retrasarían unos días en la entrega para la primera versión para la prueba.
18. El equipo no había terminado para el 1 de septiembre, y Mike aseguró a Stacy que
acabarían en sólo uno o dos días.
19. Los días se volvieron semanas. El límite del 1 de Octubre para entregar el producto
completo para su prueba llegó y fue rebasado. Desarrollo aún no había acabado el primer
producto para prueba. Stacy llamó a Bill a una reunión para tratar el plan. «Aún no
tenemos nada de desarrollo», dijo, «suponíamos que tendríamos la primera versión el 1 de

2
 septiembre, y puesto que aún no tenemos nada, por lo menos nos retrasaremos un mes
respecto al plan original. Creo que tenemos un problema».
20. «Es cierto, tenemos un problema», dijo Bill «Déjame que hable con el equipo He prometido
a 600 agentes que tendríamos el programa el 1 de noviembre Lo entregaremos a tiempo
para el cambio de tasas»
21. Bill convocó una reunión con el equipo- «Este es un equipo fantástico, y debería cumplir
con sus compromisos», les dijo- «No sé que es lo que ha ido mal, pero espero que todos
trabajéis duro y entreguéis el software a tiempo. Aún podéis conseguir las bonificaciones,
pero ahora tendréis que luchar por ellas. Desde ahora os asignaré un horario de 6 días por
semana, 10 horas al día, hasta que el software este hecho» Después de la reunión, Jill y
Tomas se quejaron a Mike de que no había necesidad de que los tratasen como niños,
pero accedieron a trabajar las horas que Bill quería.
22. El equipo retrasó el plan 2 semanas, prometiendo tener la utilidad completa construida el 1
5 de noviembre- Esto dejaba 6 semanas para la prueba antes de que entrasen en vigor las
nuevas tasaciones de enero.
23. El equipo entregó su primera versión al grupo de pruebas cuatro semanas después del 1
de noviembre, y se reunió para trabajar algunas de las áreas problemáticas que quedaban.
24. Tomas estaba trabajando en la generación de informes y se encontró con una barrera.«La
página resumen de cuotas incluye un gráfico de barras. He utilizado un generador de
informes que se suponía generaba gráficos de barras, pero la única forma de generarlos es
en páginas individuales. Uno de los requerimientos del grupo de ventas es que, hay que
poner gráficos de barras y texto en la misma página, He pensado puede trampear un
informe con gráfico de barras pasando el texto de¡ informe como una leyenda del objeto
gráfico de barras. Realmente es una trampa, pero siempre puedo volver atrás y
reimplementarlo más claramente después de la primera versión.»
25. Mike respondió: «No veo donde está el problema. Tenemos que acabar el producto y no
hay tiempo de hacer un código perfecto. Bill a dejado bien claro que no podemos tener
más fallos. Usa ese truco»
26. Chip comentó que su código de comunicaciones estaba hecho al 95 por 100 y que
funcionaba, pero que aún tenía que hacer algunas pruebas de ejecución- Mike vio que Jill y
Tomas se miraban, pero decidió ignorarlo.
27. El equipo trabajó duro hasta el 15 de noviembre, incluyendo las noches de] 14 y 15 de
noviembre, pero no pudieron hacer que la fecha de entrega fuese el 15 de noviembre. El
equipo estaba exhausto, pero la mañana del dieciseisavo día, fue Bill quién se sintió
deprimido. Stacy le había avisado de que desarrollo no había entregado la versión
completa el día anterior. La última semana le había dicho al comité ejecutivo que el
proyecto estaba encarrilado. Otra gestora de proyectos, Claire, había investigado en los
progresos del equipo, diciendo que había oído que no estaban cumpliendo las entregas
planificadas con el equipo de prueba, Bill pensó que Claire estaba tensa y no le gustaba su
informe Le había asegurada a ella que su equipo estaba en buen camino para cumplir las
entregas planeadas
28. Bill dijo a Mike que reuniese al equipo, y cuando lo hizo, parecían derrotados Un mes y
medio a 60 horas semanales habían sido la puntilla. Mike preguntó cuanto tiempo les
llevaría acabar, pero su única respuesta fue el silencio- «¿Que me estáis diciendo'7», dijo.
«Hoy íbamos a tener lista la versión con todas las funciones ¿La tenemos?»
29. «Mira, Mike», dijo Tomas, «puedo entregar hoy mi código y decir que incluye toda la
funcionalidad", pero probablemente necesitaré 3 semanas de trabajo de limpieza una vez
que lo entregue»- Mike preguntó que quería decir Tomas con «limpieza». «No he puesto el
logotipo de la empresa en cada página, tú que el nombre y el teléfono del agente aparezca
al pie de página. Son pequeñas cosas como esas. Todo lo Importante funciona bien, he
terminado el 99/o».

3
30. «Yo tampoco he hecho exactamente el 100 %», admitió Jill. «MI antiguo grupo me ha
llamado para que le diese apoyo técnico, y he tenido que emplear un par de horas diarias
con ellos. Además, había olvidado hasta ahora mismo que los agentes pedían poner su
nombre y teléfono en los informes. Aún no he implementado los diálogos de entrada para
esos datos, y también tengo que hacer algunos diálogos de mantenimiento. No creía que
fuesen necesarios para el hito de "Utilidad completa"».
31. Mike también empezaba a sentirse mal. «Si he oído lo que creo que he oído, me estáis
diciendo que necesitas 3 semanas para completar el software, ¿es correcto?»
32. « Al menos tres semanas» dijo Jill. El resto de los desarrolladores estuvo de acuerdo. Mike
paso uno por uno y les preguntó si podrían completar su parte en 3 semanas. Uno por uno
cada programador respondió que trabajaría duro y que pensaban podrían hacerlo.
33. Al final de ese día después de una discusión larga e incómoda, Mike y Bill acordaron
retrasar el plan 3 semanas, hasta el 5 de Diciembre, siempre que el equipo prometiera
trabajar 12 horas diarias en vez de la 10. Bill dijo que tenía que demostrarle a su jefe que
estaba azuzando al equipo de desarrollo- La revisión del plan implicaba que tendrían que
probar el código y preparar al personal al mismo tiempo, pero era esta la única posibilidad,
para entregar el primero de enero. Stacy se quejó que el tiempo asignado a control de
calidad no era suficiente, pero Bill no hizo caso.
34. El 5 de diciembre el equipo Criga-Quote entregó el programa Gga-Quote completo al grupo
de pruebas antes del mediodía, y salieron pronto del trabajo para tener su largamente
esperado descanso, Habían trabajado casi constantemente desde el 1 de septiembre.
35. Dos días más tarde, Stacy dio la primera lista de errores, y se desató el infierno. En dos
días el grupo de pruebas identificó más de 200 defectos en el programa Giga-Quote,
incluyendo 23 clasificados como de severidad 1 «<Tienen que corregirse») «No veo la
forma de que el software esté listo para entregarlo a los agentes locales antes del 1 de
enero», dijo. «Probablemente el grupo de pruebas necesite ese tiempo para escribir los
plazos de prueba de los defectos que ya ha descubierto, y está descubriendo defectos
cada hora.»
36. Mike convocó una reunión de personal a las 8 en punto de la mañana siguiente. Los
desarrolladores estaban quisquillosos, Decían que habían unos cuantos errores serios,
pero la mayoría de los errores indicados no eran realmente errores, sino malas
interpretaciones de cómo se suponía que tenía que funcionar el programa. Tomas indicó
que el error #143 era un ejemplo de eso, «El informe del error #143 dice que en la página
resumen de la cuota, el gráfico de barras tiene que estar en la derecha de la página en vez
de la izquierda. Esto no es un error de severidad 1. Es la típica forma en que los
comprobadores sobrestiman un problema».
37. Mike distribuyó copias de los informes de errores. Encargó a los desarrolladores que
revisasen los errores que el grupo de pruebas les había asignado y estimasen cuánto
tiempo, les llevaría corregir cada uno de ellos
38. Cuando el equipo se reunió de nuevo por la tarde, las noticias no eran buenas. « Siendo
realista, estimo que necesito dos semanas completas de trabajo para corregir los errores
que ya nos han pasado», dijo Sue. «además tengo que acabar las comprobaciones de
integridad referencial de la base de datos. En total, necesito 4 semanas a partir de hoy.»
39. Tomas había devuelto el error # 143 a los comprobadores, cambiando su severidad de 1 a
3 «Cambio estético»). El grupo de pruebas respondió que los informes resumen de Giga-
Quote, tenían que coincidir con informes similares generados por el programa instalado en
el mainframe para políticas de renovación, que era similar a los formatos de marketing
preimpreosos que la compañía había usado durante muchos años. Los 600 agentes de la
compañía estaban acostumbrados a ver sus valores de ventas en gráficos de barras a la
derecha. El error se quedó con un nivel 1, y supuso un problema.

4
40. «¿Recuerdas la trampa que utilicé para que se pudiesen imprimir en la misma página el
gráfico de barras y el informe»>, preguntó Tomas. «Para poner el gráfico a la derecha,
tengo que reescribir ese informe concreto desde el principio, lo que significa que tengo que
escribir mi propio código a bajo nivel para dar formato al informe y al gráfico.» Mike tembló,
y pidió una estimación aproximada de cuánto tiempo necesitaba-- Tomas dijo que por lo
menos 10 días, pero tendría que verlo más despacio antes de estar seguro.
41. Antes de volver a casa, Mike dijo a Stacy y Bill que el equipo trabajaría incluso los días de
fiesta y que todos los errores encontrados se corregirían para el 7 de enero Bill dijo que se
lo esperaba y que había aprobado un retraso en el plan de 4 semanas antes de irse a un
crucero de un mes por el Caribe que tenía planeado desde el pasado verano.
42. El mes siguiente Mike estuvo ocupado manteniendo al grupo unido. Durante 4 meses
habían trabajado todo lo duro que se podía trabajar, y no creía que pudiesen hacer más.
Estaban en la oficina 12 horas al día, pero empleaban mucho tiempo leyendo revistas,
pagando facturas y hablando por teléfono, Parecía que se irritaban siempre que les
preguntaba cuánto les quedaba para reducir la cuenta de errores. Por cada error que se
corregía, el grupo de pruebas descubría 2 nuevos. Errores cuya corrección debía haber
llevado 2 minutos tenían implicaciones en el proyecto completo y podían llevar días. Pronto
calcularon que no había forma de que pudiera corregir todos los defectos para el 7 de
enero.
43. El 7 de enero BUI volvió de sus vacaciones, y Mike le dijo que el equipo de desarrollo aún
necesitaba 4 semanas más. «Esto es serio», dijo Bill, «tengo 600 agentes locales que
están hartos de dar vueltas alrededor de un puñado de aprendices de informáticos. El
comité ejecutivo está hablando de cancelar el proyecto. Tienes que encontrar una forma
de entregar el software en las próximas dos semanas, sea como sea».
44. Mike convocó una reunión del equipo para estudiar sus opciones. Les comunicó el
ultimátum de Bill y les pidió una estimación aproximada de cuándo entregarían el producto,
primero en semanas, luego en meses - El equipo se calló. Ninguno se arriesgaba, acerca
de cuándo podrían entregar finalmente el producto. Mike no sabía que decirle a Bill.
45. Tras la reunión, Chip dijo a Mike que había aceptado un contrato de otra compañía y que
empezaba el 3 de febrero. Mike comenzó a sentir que sería un alivio que se cancelara el
proyecto.
46. Mike buscó a Kip, el programador que había sido responsable del apartado de
comunicaciones entre el PC y el mainframe, reasignado de apoyo al proyecto, y lo dedicó a
corregir los errores en el código de comunicaciones del PC. Después de luchar una
semana con el código de Chip, Kip concluyó que tenía algunos defectos conceptuales
profundos que harían que nunca funcionara correctamente. Kip se vio obligado a rediseñar
y reimplementar la parte PC del enlace de comunicaciones entre el PC y el mainframe.
47. Puesto que Bill se salió por la tangente en la reunión ejecutiva de mitad de febrero,
finalmente Claire decidió que ya había oído suficiente y mandó un «stop» al programa
Giga-Quote, Se reunió con Mike el viernes «Este proyecto está fuera de control», dijo.