McConnell, S. (1997). Errores clsicos.

En Desarrollo y gestin de
proyectos informticos (pp.35-58). Madrid : McGraw Hill. (C21006)
TOMADO DE: DESARROLLO Y GESTION DE PROYECTOS INFORMA TICOS.
Por Steve McCONNELL; ed. McGraw Hill; Espaa 1997.
3
8111
Errores clsicos
Contenido
3.1. Ejemplo de errores clsicos
3.2. Efecto de los errores en la programacin de un desarrollo
3.3. Relacin de errores clsicos
3.4. La fuga de La isla de Gilligan
Temas relacionados
Gestin de riesgos: Captulo 5
Estrategia para el desarrollo rpido: Captulo 2
EL DESARROLLO DE SOFTWARE ES UNA ACTIVIDAD COM-
PLICADA. Un proyecto software tpico puede presentar ms oportuni-
dades para aprender de los errores que las planteadas a algunas perso-
nas durante toda su vida. Este captulo examina algunos de los errores
clsicos que se cometen cuando se intenta desarrollar software rpida-
mente.
3.1. Ejemplo de errores clsicos
El siguiente ejemplo es un poco como los pasatiempos de los nios, en
los que intentamos encontrar todos los objetos cuyo nombre comienza
con la letra M. Cuntos errores clsicos puede encontrar en el siguien-
te ejemplo?
35
Material didactico reproducido en ESAN para su uso exclusivo en clase.
36 Desarrollo y gestin de proyectos informticos
Ejemplo 3.1. Errores clsicos
Mike, un responsable tcnico de Giga Safe, estaba comiendo en su oficina
y mirando por la ventana una brillante maan4 de abriL
Felicidades! Mike, ya tienes los . el programa Giga-
Quote !>> Era Bill, el jefe de.Mike en Giga, :qJ:}a C,mnpaa de seguros mdi-
cos. Al comit ejecutivo le ha gustado la automatizar nuestras
cuotas de seguro mdico. Y tambin la idea de volcar cada noche las cuo-
tas del da en la oficina principal para que siempre tengamos al dia los
ltimos valores de ventas. Ahora tengo una reunin, pero podemos discutir
los detalles ms adelante. Buen trabajoh>
Mike escribi la propuesta para el programa Giga-Quote meses antes,
pero estaba pensada como un programa para un solo PC, sin ninguna capa-
cidad de comunicacin con la oficina principaL Perfecto, sta era la opor-
tunidad de dirigir un proyecto clente-servidoren;un moderno entorno GUI
(interfaces grficas de usuario), lo que siempre haba querido hacer. El
proyecto le llevara al menos un ao, y lo ocupada a tiempo completo.
Mike descolg el telfono y marc el nmero de su esposa. <<Cario, esta
noche cenaremos fuera para celebrarlo ... >>
A la maana siguiente, Mike qued con Bill pafa discutir el proyecto.
Vamos a ver, Bill. Qu pasa? Esto no se parece a la propuesta en la que
he trabajado.
Bill se sinti inseguro. Mike no haba 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 ejecuti-
vo le gust la idea de construir software para automatizar las cuotas de
seguros mdicos. Pero queran que se pudieran.transferir automticamente
las cuotas locales al computador central. Y queran tener hecho el sistema
antes de que se hagan efectivas las nuevas cuotas el 1 de enero. Adelanta-
ron la fecha de finalizacin del software que propusiste del 1 de marzo al 1
de noviembre, con lo que se acort el plan propuesto en 6 meses.
Mike babia estimado que el trabajo llevarla 12 meses. No crey que
tuviese la suerte de acabar en seis meses, y as se lo dijo a Bill. Vamos a
ver si me he enterado, dijo Mike. Parece que ests dicindome que el
comit aadi requisitos de comunicaciones a gran escala y ha acortado el
plan de 12 a 6 meses.
Bill se encogi de hombros. S que ser un reto, pero t eres creativo
y creo que puedes con todo. Han aprobado el presupuesto que queras, y
aadir el enlace de comunicaciones no debe ser difcil. Pediste 36 perso-
nas-mes y las tienes. Puedes reclutar a quien quiera que necesites para
el proyecto e incrementar el tamao del equipo. Bill le dijo que hablase
con algn otro desarrollador y que buscasen la forma de entregar el soft-
ware a tiempo.
Mike se reuni con Carl, otro responsable tcnico, y buscaron la forma
de acortar el plan. Por qu no usas C++ y diseo orientado a objetos?>>,
(contina)
Captulo 3: Errores clsicos 37
. coment Carl. Sers ms productivo que con C, y el plan se acortar en
uno o dos meseS.)) A Mike le pareci bien. Carl tambin conoca una he-
rramienta de elaboracin de informes que supuestamente acortaba el tiem-
po de desarrollo a la mitad. El proyecto tena bastantes informes, y por
tanto esos dos cambios Jos llevaran hastalos 9 meses. Consiguieron hard-
ware nuevo y ms rpido, y esto les ahorraba un par de semanas. Si real-
mente poda reclutar a desarrolladores de primerisima 9ategora, podra bajar
a 7 meses. Esto era suficientemente ajustado. Mike coment sus progresos
a Bill. ....
Mira, dijo Bill, dejar el plan en 7 meses est bien, pero no es sufi-
ciente. El comit dej claro que el plazo de eQtrega eran seis meses. No me.
dieron opcin. Puedo daros el ha,r:dware que:Q.ecesitis, pero t y tu equipo
tenis que encontrar una fornu, de o .tendris
que hacer algunas horas extra p.ali.arl.a.dtferencta>). ,: ::'J: . . , .
. . Mike se plante el hecho de que su ;esti,ttu:lcin inicial slo fue una
aproximacin y pens que quizs podria bajarla a 6 meses. De acuerdo,
Bill, buscar un par de personas externas espabiladas para el proyecto. Quizs
pueda encontrar gente con experiencia en comunicaciones para que nps
ayude en la descarga de datos desde el PC al mainframe.
El 1 de mayo, Mike babia formado el equipo. JiU, Sue y Tomas eran
buenos desarrolladores de la casa, y fueron Uberacl.os. Complet el equipo
con Keiko y Chip, dos contratados tenia experiencia tanto
en PC como en los mainframe con los qut tenla que conectarse. Jll y To-o
mas haban entrevistado a Chip y no pero Mike lo im-
puso. Tena experiencia en comnicaciones y estaba disponible; asique
Mike Jo contrat.
En la primera reunin del equipo, Bill dijo que. el programa Giga,.Quote
era estratgicamente importante para Giga Safe Corporation. Alguns de los
magnates de la compaia estarlan pendientes ele ellos .. Si tenian.Jdto se-
rian recompensados. Dijo que estaba seguro de que lo conseguiran.
Despus de los nimos infundidos por el discurso de Bill, Mike se sen,.
t con el equipo y mostr el plan. El comit ejecutivo les babia proporcio-
nado una especificacin aproximada, y emplearon las siguientes dos sema-
nas en completar las lagunas. Despus se emplearan 6 semanas en el diseo,
lo que dejaba 4 meses para la construccin y la prueba. Su estimacin aproxi-
mada fue que el producto final tendria unas 30.000.Hneas en C++. Todos
los asistentes asintieron, dando su conformidad. Era ambicioso, pero lo
saban cuando se comprometieron con el proyecto.
A la semana siguiente, Mke se reuni con Stacy, la responsable de la
prueba. Indic que debera tener partes del producto terminadas para pro-
barlas no despus del 1 de septiembre, con el propsito de tener un produc-
to con todas las funciones el 1 de octubre. Mike estaba de acuerdo.
El equipo acab la especificacin de los requerimientos rpidamente,
y se meti en el diseo. Obtuvieron un diseo que parecia hacer buen uso
de las prestaciones de C++.
(contina)
38 Desarrollo y gestin de proyectos informticos
Acabaron el diseo el 15 de junio, adelal}tn<Jose al plan, y comenza-
ron a codificar como locos para llegar al .
sin de prueba el 1 de septiembre. una
balsa de aceite. Ni a Jill ni a Tomas les se quejabade
que no quera que nadie se acercase a su cdgoJMike atribuy}os cho-
ques de personalidades a las muchas horas de trabajo. No obstante, a pri-
meros de agosto, le indicaron que estaba hecho entre el85yel90 por 100;
A mitad de agosto, el departamento actuarial dio las tasas para el ao.
siguiente, el equipo descubri que tena que modificar completan;.ente la
estructura para las nuevas tasas. El nuevo mtodo 'de tasacinnecesitaba
realizar preguntas sobre hbitos de ejercicio, en la bebida, 'en la comida,
actividades de ocio y otros factores que no se habanincludo antes en las
frmulas de tasacin. Pensaron que C++ deba protegerlos de los efectos
de esos cambios. Calcularon que slo tendrlan que incluir nuevos valores
en las tablas de tasas. Pero tendran que cambiar el dilogo de entrada, el
diseo de la base de datos, el acceso a la base de datos y los objetos de
comunicaciones para adaptarlos a la nueva .estructura. Como el equipo es-
taba revuelto porque tena que reajustar su diseo, Mike dijo a Stacy que
se retrasaran unos das en la entrega de la primera versin para la prueba.
El equipo no haba terminado el 1 de. septiembre, y Mike asegur a
Stacy que acabaran en slo uno o dos das.
Los das se volvieron semanas. El lmite dell de octubre para entregar
el producto completo para su prueba lleg y fue rebasado. Desarrollo an
no haba acabado el primer producto para prueba. Stacy llam a Bill a una
reunin para tratar el plan. An no tenemos nada de desarrollo, dijo,
suponamos que tendramos la primera versin el 1 de septiembre, y puesto
que an no tenemos nada, por lo menos nos retrasaremos un mes respecto
al plan original. Creo que tenemos un problema.
Es cierto, tenemos un problema, dijo Bill. <<Djame que hable con el
equipo. He prometido a 600 agentes que tendramos el progran;.a el 1 de
noviembre. Lo entregaremos a tiempo para el cambio de tasas.
Bill convoc una reunin con el equipo: ste es un equipo fantstico,
y debera cumplir con sus compromisOS)), les dijo. No s qu es lo que ha
ido. mal, pero espero que todos trabajis duro y entreguis el software a
tiempo. An podis conseguir las bonificaciones, pero ahora tendris que
luchar por ellas. Desde ahora os asignar un horario de 6 das Por semana,
1 O horas al da, hasta que el software est hecho. Despus de la reunin,
Jill y Tomas se quejaron a Mike de que no habla necesidad de que los
tratasen como nios, pero accedieron a trabajar las horas que Bill quera.
El equipo retras el plan dos semanas, prometiendo tener la utilidad
completa construida el 15 de noviembre. Esto dejaba 6 semanas para la
prueba antes de que entrasen en vigor las nuevas tasas en enero.
El equipo entreg su primera versin al grupo de pruebas cuatro sema-
nas despus del l de noviembre, y se reuni para tratar algunas de .las reas
problemticas que quedaban.
(contina)
Captulo 3: Errores clsicos 39
Tomas estaba trabajando en la generacin 4ejnformes y se encontr
con uha barrera. <<La pgina resumen. de un grfico de.
rras. He utilizado un generador de grficos
de barras, pero la nica forma de '
Uno de los requerimientos del grupo de,
cos de barras y texto en la misma pgina.Htrpensado. que P1ledo Jl;an1pef1t
un informe con un grfico de bfl.l'J;'as pasqnd9 e,l una
leyenda del objeto grfico de barJ;BS: Realm,ente,ys 'uria
pre puedo volver atrs y reimplementarlo 'despus de laJ
primera versin. .
Mike respondi: No veo dnde este}pt;oblem,a. Tenemos que acabar
el producto, y no hay tiempo de hacer un cdigo perfecto. Bill ha dejado
bien claro que no podemos tener ms fallos. Usa ese truco.>>
Chip coment que su cdigo de comunicaciones .estaba hecho al
95 por 100 y que funcionaba, pero que an tenia que hacer algunas prue-
bas de ejecucin. Mike vio que Jill y Tomas se miraban, pero decidi igno-
rarlo.
El equipo trabaj duro hasta el 15 de noviembre, incluyendo las no-
ches del 14 y el 15 de noviembre, pero no pudieron hacer que la fecha de
entrega fuese el15 de noviembre. El equipo estaba exhausto, pero la maa-
na del dieciseisavo da, fue Bill quien se sinti deprimido. Stacy le haba
avisado de que desarrollo no haba entregado la versin completa el da
anterior. La ltima semana haba dicho al comit ejecutivo que el proyecto
estaba encarrilado. Otra gestora de proyectos, Claire, haba investigado en
los progresos del equipo, diciendo que haba odo que no estaban cum-
pliendo las entregas planificadas con el equipo de prueba. Bill pens que
Claire estaba tensa y no le gustaba su informe. Le haba asegurado a ella
que su equipo estaba en buen camino para cumplir las entregas planeadas.
Bill dijo a Mike que reuniese al equipo, y cuando Jo hizo, parecan
derrotados. Un mes y medio a 60 horas semanales hablan sido la puntilla.
Mike pregunt cunto tiempo les llevara acabar, pero su nica respuesta
fue el silencio. Qu me estis diciendo?, dijo. <<Hoy bamos a tener lista
la versin con todas las funciones. La tenemos?
Mira, Mike, dijo Tomas, puedo entregar hoy mi cdigo y decir que
incluye "toda la funcionalidad", pero probablemente necesitar tres sema-
nas de trabajo de limpieza una vez que lo entregue. Mike pregunt qu
quera decir Tomas con limpieza>;. No he puesto el logotipo de
presa en cada pgina, ni que el nombre y el telfono del agente aparezca al
pie de la pgina. Son pequeas cosas como sa. Todo lo importante funcio-
na bien. He acabado al 99 por 100.
Yo tampoco he hecho exactamente el lOO por 100, admiti Jill. Mi
antiguo grupo me ha llamado para que les diese apoyo tcnico, y he tenido
que emplear un par de horas diarias con ellos. Adems, haba olvidado
hasta ahora mismo que los agentes pedan poner su nombre y su telfono
en los informes. An no he implementado los dilogos de entrada para esos
(contina)
40 Desarrollo y gestin de proyectos informticos
datos, y tambin tengo que hacer algunos di4logos .de mantenimiento. No ,
crefa que fuesen necesarios para el hito completa",
Ahora Mike tambin empezaba a que creo
que he odo, me estis diciendo que necesiti$,:-tres semanas )atll
el software. Es correcto? _, ,_ -, ;--,, : , _
<<Al menos tres semanas;
vo de acuerdo. Mike pas uno por,un podfi8.n completar
su parte en tres semanas. Unopor trtlba.:.,.
jara duro, y que pensaba que poda hacerlo. ';';; :, ,
Al final de ese da, despus de una e incmoda, Mike y.
Bill acordaron retrasar el plan 3 semanas, hasta el S de diciembre, siempre
que el equipo prometiera trabajar 12 horas ;8.1 dia en vez de 1 O. Bill dijo que
tena que demostrar a su jefe que. estaba equipo de desarrollo.,
La revisin del plan implicaba que tendran qe probar el cdigo y prepa-
rar al personal al mismo tiempo, pero posibilidad deent,regar
el cdigo el 1 de enero. Stacy se quej de .que elcontrol de calidad del
software no tenia asignado el tiempo suficiente para probarlo, pero Bill no .
le hizo caso.
El 5 de diciembre el equipo Giga-Quoteent:reg elprograma Giga-
Quote completo al grupo de pruebas antes y pronto
del trabajo para tener su largamente esperado descanso. Habln trabajado
casi constantemente desde el 1 de septiembre;. .. . . . ..
Dos das ms tarde, Stacy dio la primeraJista.de errores, y el ;
infierno. En dos das el grupo de pruebas mS de 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 Lde enero, dijo. Probable-
mente el grupo de pruebas necesite ese tiempo para escribir los casos de
prueba de los defectos que ya ha descubierto, y .est descubrie11do. defectos
cada hora.>>
Mike convoc una reunin de personal a las 8 en punto de la maana
siguiente. Los desarrolladores estaban quisquillosos. Decan que haba unos
cuantos errores serios, pero la mayora de los errores indicados no eran
realmente errores, sino malas interpretaciones de cmo se supona que te-
na que funcionar el programa. Tomas indic que el error# 143 era un ejemplo
de eso. El informe del error #143 dice que en la pgina resumen de la
cuota, el grfico de barras tiene que estar en la derecha de la pgina en vez
de en la izquierda. Esto no es un error de severidad 1. Es la tpica forma en
que los comprobadores sobreestiman un problema.>>
Mike distribuy copias de los informes de errores. Encarg a los desa-
rrolladores que revisasen los errores que el grupo de pruebas les haba asig-
nado y estimasen cunto tiempo les llevara corregir cada uno de ellos.
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 pasadm>, dijo Sue. Adems,
(contina)
Captulo 3: Errores clsicos 41
tengo que acabar las comprobacion!!S de referencial de la base ;
de datos. En total, necesito cuatro hoy. L ,,, . . . .
Tomas haba devuelto elerror
su severidad de 1 a 3 (Cambio esttico). El grupo de pruebas respondi
que los informes resumen de tenan que coincidir con infor-
mes similares generados por el programa instalado en el mainframe para
polticas de renovacin, que era similar a los formatos de marketing preim
presos que la compaia haba usado durante muchos.aos. Los 600 agentes .
de la compaa estaban a. ver sus valores de en gr
ficos de barras a la derecha, y tenanque quedarse ;,1 error ;Se
qued con un nivell, y supuso unproblema. .. , . .
Recuerdas la trampa que utilic para que se pudiesen itnpri,mir en
la misma pgina el grfico de ballJls y el informe?;pr.egunt6Tomas. Para
poner el grfico a la ,derecha, tengo que
. desde el principio,Jo que. sgnifica,;.que tengo:,que' esctibit mi'prop()
cdigo a bajo nivel para dar . al

Mi].(e
. . :,y pidi tina necesitaba ..
:. omas dijo que porJl()imenqs)o: 'pero;CJ.] ' gpa.,,que V".rlo ms .
.. de,estar:seguro.ii.. . . . . ':;;; ,:/;i:';,):< . ":. ,:
. >' de volver;,a . :
, Jarla mcluso ls das J()$: se <
giran para el 7 de enero. Bill. dijo que'se lo sP,eraba'yque habia aprobado
un retraso en el plan de 4 semans antesdeirs,iru,tl'Crucero deunmes por
el Caribe que tenia planeado des.c:le !i!l ..
El mes siguiente estu;v() ..
Durante cuatro meses habtan. que .. taba
jarj y no crea que pudiesen, pacer Js. .. ofi(iUltfU })pras
al da, pero empleaban mucho> tiempo leyendo 'revistas, pagand factUras'
y hablando por telfono. Pareca que se irritaban, que lc:s. pregun"
taba cunto les quedaba para cuetlta de errores. Pt cada errr .
que se correga,. el grupo de d,escubtia.E:do,.nevos Brrotes.cuya .
correccin debia haber llevado 2 minutos tenan nplicaciones en el pro
yecto completo y podan llevar dias: Pronto calcularon que no habia forma
de que pudieran corregir todos los defectos par el 7 de enero.
El 7 de enero Bill volvi de sus vacaciones, y Mike le dijo que el equi-
po de desarrollo an necesitaba. 4 semanas ms. <{Esto es serio>>, dijo Bill. ,
tengo 600 agentes locales que estn hartos de dar vueltas alrededor de un
puado de aprendices de informticos. El comit ejecutivo est hablando
de cancelar el proyecto. Tienes que encontrar una forma de entregar el soft-
ware en las prximas dos semanas, sea como sea.
Mike convoc una reunin del equipo para estudiar sus opciones. Les
comunic el ultimtum de Bill y les pidi una estimacin aproximada de
cundo entregaran el producto,. primero en semanas, luego ett meses. El
equipo se call. Ninguno searriesgaba acerca entregar
finalmente el producto. Mib qu decirle.a}3iU. .
(contina)
42 Desarrollo y gestin de proyectos informticos
V __ ,: :: :ir::<
Tras la reuni?n;:(;hip

ee?:!,'
otra compaa y que empezaba;ep ... tt'< .. ,.
sera un alivio que "' .. ,:, .
Mike busc. a Kip,.el
d(), de. entre
proyecto, y lo dedic a corregu.los errores
, del PC. Despus de se111ana'pon,
.. y que ten fa algunos, defeclQS \qp,e; n9n"t;;;;;
ca funcionara correctamente .. l(ipse :.: ..
la parte PC del enlace de com9nicaciones 'y el. mainfune:' ' ' .
Puesto que Bill se sali por la tangente reunin ejecutiva a e mi.:.
tad de febrero, finalmente Claire decidi. que. ya hab.fa odo, y
mand un stop alprograma Giga-Quote:Se reuni conMike.elviemesi .
Este proyecto est fuera de controb>, dijo. Oesde hace meses, Billno me
ha dado una estimacin fiable. Es un proyecto de'6 meses,'y'ya llev ms.
de 3 meses de retraso sin un final claro. Estis trabajando tantas' horas que
no hacis progresos. Quiero que descansis todos.unfin de semllna;quiero
que desarrolles un informe detallado, paso a paso, que incluya t9d0
1
y digo
todo, lo que queda por hacer. del proyecto. N9 quiero qlJ,eforcis el proyec-
to para encajarlo en un' plan art.ficial: :Si se necesitan otros'9
saberlo. Quieroel informe pendiente ..el
ne. que ser bonito, pero tiene que estarcompleto:>> > . . ; t< . .
El equipo de desarrollo se alegr de tener un fin de'semana
durante la semana siguiente atacaron el informe detallado
novadas. Estuvo en la mesa de Claire para el mircoles. Revis el informe
con Charles, un asesor en ingeniera del software que tambin haba revi-
sado las estadsticas de errores del proyecto. Charles recomend que el
equipo centrase sus esfuerzos en un puado de n;ldtilos'propens<,>s a erro
7
.
. res, que se iniciasen inmediatamente revisicmes diseno y la'codifica-.
cin para corregir todos los errores y.queel equipo comenzase trabajando
horas fijas, para que se pudiesen hacer mtricas precisas del esfuerzo em.:.
pleado en el proyecto y cunto se necesitara para terminarlo. : '
Tres semanas ms tarde, en la primera semana de marzo, .la lista de
errores pendientes baj un poco por primera vez. La moral del equipo su-
bi un poco, y basndose en los progresos regulares que se iban haciendo,
el asesor estim que el software podra entregarse, completamente probado
y fiable, el 15 de mayo. Puesto que el incremento semestralde latasade
Giga Safe tendra efecto a partir de l de julio, Claire .oficial,
de lanzamiento el 1 de junio. '
Eplogo
El programa Giga Quote se entreg a los agentes locales de acuerdo con el
plan el 1 de junio. Los agentes locales de Giga Safe lo acogieron con entu;.
siasmo y algo de escepticismo.
(contina)
REFERENCIA
CRUZADA
En la Seccin 8.6,
Estimaciones simples
de planificacin, se
incluye una tabla con
las estimaciones
aproximadas para
proyectos de distintos
tamaos.
Captulo 3: Errores clsicos 43
. La corporacin Giga Safe mostr su al
por el equipo de desarrollo dando a cada d,esarroJlaqor una de
250 dlares. Unas cuantas sem11nas
y lill se fue a trabajar a otra. coropaja. ;,< ; ': . . ' ' ' ;,,,)
El producto final se en 13 meses deeri 6,
pasndose del limite ms de. un 100 pot lOO. E1 sfuetz(f de dt'!$aJ:!:ollo,
incluyendo las horas extras, fue de 98 personasroes, lo quesupuso un ex-
ceso del.l70 por 100 respecto a las 36 personas mes planificadas.
producto final tena entomoa40.000 llneas de c6digoC++ no va ...
ciaiy sin superior en ms de un 33 por 100 a las estimaciones
aproximadas de Puesto que fue un producto distribuido .. en ms de
600 puestos internos, Giga-,Quote es un hbridq entre un producto de ges.:
tin y un producto <<Pret-a-porter>>. Un producto de este tamafio y este tipo
normalmente se debera haber acabado en 11 meses y medio con un esfuer-
zo de 71 personas-mes. El proyecto sobrepas ambas cantidades.
3.2. Efectos de los errores en la programacin
de un desarrollo
Michael Jackson (el cantante, no el informtico) cantaba que ne bad
apple don't spoil the whole bunch, baby (una manzana podrida no estropea
el barril completo, pequea). Esto puede ser cierto para las manzanas,
pero no lo es para el software. Una manzana podrida puede estropear el
proyecto completo.
Un grupo de investigadores de ITT revis 44 proyectos de 9 pases
para examinar el impacto de 13 factores de productividad en la producti-
vidad (Vosburgh et al., 1984 ). Los factores incluan el uso de tcnicas de
programacin modernas, dificultad del cdigo, requisitos de eficiencia,
nivel de participacin del cliente en la especificacin de los requerimien-
tos, experiencia personal y alguno ms. Asignaron a cada factor distintas
categoras que esperaban asociar con una eficiencia baja, media o alta.
Por ejemplo, asignaron al factor uso de tcnicas modernas de programa-
cin valores de bajo uso, uso medio o alto. La Figura 3.1 de la pgina
siguiente muestra lo que descubrieron los investigadores acerca del factor
uso de tcnicas modernas de programacin.
Cuanto ms estudiamos la Figura 3.1, ms interesante resulta. Mues-
tra un patrn general que es representativo de los descubrimientos de cada
uno de los factores de productividad estudiados. Los investigadores de
ITT vieron que los proyectos de las categoras que tuvieran poca produc-
tividad realmente tenan una productividad pobre, como muestra la estre-
cha franja de la categora Baja en la figura 3.1. Pero la productividad en
44 Desarrollo y gestin de proyectos informticos
REFERENCIA
CRUZADA
Para un anlisis
ms detallado
de este grfico
concreto, consulte la
Seccin 4.2, Bases
tcnicas.
REFERENCIA
CRUZADA
Para ms informacin
acerca del papel que
juegan los errores en
el desarrollo rpido,
vase la Seccin 2.1,
Estrategia general
para el desarrollo
rpido ...
Uso de tcnicas modernas de programacin
(porcentaje del sistema total)
Porcentaje de
la planificacin
nominal
Baja
(0-25%)
Media
(26-75%)
Alta
(76-100%)
+200 ----------
+100 ------,
O (media) ---------------
Leyenda
I
Mximo
Percentil del 75%
Media
1
Percentil del 25%
Mfnimo
Figura 3.1. Estudio sobre el factor <<Uso de tcnicas modernas de
programacin (Vosburgh et al., 1984). Hacer algunas cosas bien no
garantiza el desarrollo rpido. Tambin tenemos que evitar hacer mal
cualquier cosa.
categoras de alto rendimiento variaba mucho, segn muestra la franja
ancha de la categora Alta en la figura. La productividad de los proyectos
de la categora Alta variaba desde pobre a excelente.
No es sorprendente que proyectos que se espera que tengan una pro-
ductividad pobre la tengan realmente. Pero s debiera ser una sorpresa el
descubrimiento de que muchos proyectos que se esperaba que tuviesen
una productividad excelente tienen una productividad pobre. Lo que este
grfico y otros como ste muestran a lo largo de todo el libro es que aun-
que es necesario utilizar alguno de los mtodos recomendables, no es sufi-
ciente para obtener la mxima velocidad de desarrollo. Incluso si se hacen
algunas cosas bien, como la utilizacin de tcnicas de programacin
modernas, an podemos cometer un error que anule las mejoras en la pro-
ductividad.
Al pensar en el desarrollo rpido, resulta tentador pensar que todo lo
que hay que hacer es identificar las causas iniciales de un desarrollo lento y
eliminarlas, y despus obtendremos un desarrollo rpido. El problema es
que no hay slo unas pocas causas del desarrollo lento, y que al final no
es muy til intentar identificar todos los orgenes del desarrollo lento. Es
como preguntarse: cul es la causa principal de que no sea capaz de correr
una milla en cuatro minutos? Bueno, soy demasiado viejo. Peso mucho.
No estoy en forma. No me atrevo a intentarlo. No tengo un buen entrena-
dor o capacidades atlticas. No podra ir tan deprisa aunque fuese ms
joven. La lista crece y crece.
Cuando hablamos de proezas excepcionales, las razones de que la gente
no las alcance son simplemente demasiado numerosas como para contar-
Captulo 3: Errores clsicos 45
las. El equipo de Giga-Quote del Ejemplo 3.1 cometi muchos de los errores
que han plagado el desarrollo de software desde los tiempos ms remotos
de la informtica. El camino del desarrollo de software est lleno de ba-
ches, y los baches en que caigamos determinan la rapidez o la lentitud
con que desarrollamos el software.
En el software, una manzana podrida puede estropear todo el barril,
pequea. Para caer en el desarrollo lento, todo lo que hay que hacer es
cometer realmente un gran error; para conseguir el desarrollo rpido te-
nemos que evitar cometer algn gran error. La siguiente seccin enumera
los grandes errores ms habituales.
3.3. Relacin de errores clsicos
Algunas tcnicas de desarrollo inefectivas han sido elegidas con tanta
frecuencia, por tanta gente, con resultados tan malos y predecibles que
son dignas de ser llamadas errores clsicos. Muchos de los errores
tienen una apariencia seductora. Necesitamos salvar un proyecto re-
trasado? Metamos a ms gente! Tenemos que reducir el plan? Plani-
ERROR CLSICO fiquemos de forma ms agresiva! Alguno de los miembros clave in-
Figura 3.2. El proyecto software estaba repleto de errores, y todos /os
directivos de mayor categora y /os responsables tcnicos juntos no lo
pueden salvar a ningn precio.
46 Desarrollo y gestin de proyectos informticos
REFERENCIA
CRUZADA
Para ms informacin
sobre los buenos y
malos usos de la
motivacin, consulte el
Captulo 11,
"Motivacin".
comoda al resto del equipo? Esperaremos hasta que acabe el proyecto
para despedirlo! Hay que acelerar el proyecto para acabar? Cogeremos
cuantos desarrolladores estn ya disponibles, y que comiencen lo antes
posible!
Los desarrolladores, directivos y clientes normalmente tienen buenas
razones para tomar las decisiones que toman, y la apariencia seductora de
los errores clsicos es una de las razones de que esos errores se cometan
tan a menudo. Pero debido a que se han cometido muchas veces, sus con-
secuencias se han hecho fciles de predecir. Y los errores clsicos rara
vez producen los resultados que la gente espera.
Esta seccin enumera alrededor de dos docenas de errores clsicos.
Personalmente he visto cometer cada uno de esos errores al menos una
vez, y yo mismo he cometido bastantes. Muchos de ellos aparecen en el
Ejemplo 3.1. El comn denominador de esos errores es que el desarrollo
rpido no se consigue necesariamente si se evitan, pero si no se evitan,
seguro que se consigue el desarrollo lento.
Si alguno de estos errores nos resulta familiar, hay que animarse;
muchos otros los han cometido antes. Una vez que comprendamos sus
efectos en la velocidad de desarrollo, podremos utilizar esta lista para
ayudarnos en la planificacin de nuestro proyecto y en la gestin de
riesgos.
Algunos de los errores ms significativos tienen sus propias secciones
en otras partes de este libro. Otros no se tratarn ms. Para facilitar la
consulta, la lista se ha dividido empleando las dimensiones de la veloci-
dad de desarrollo: personas, proceso, producto y tecnologa.
Personas
A continuacin aparecen algunos de los errores clsicos relacionados con
las personas.
1: Motivacin dbil. Estudio tras estudio se ha mostrado que la motiva-
cin probablemente tiene mayor efecto sobre la productividad y la calidad
que ningn otro factor (Boehm, 1981 ). En el Ejemplo 3 .l, los directivos
tomaron a lo largo de todo el proyecto medidas que minaban la moral: como
dar nimos a diario al principio para pedir horas extras en la mitad, y
como irse de vacaciones mientras el equipo estaba trabajando incluso los
das de fiesta, para dar recompensas al final del proyecto que resultaron
ser de menos de un dlar por cada hora extra.
2: Personal mediocre. Despus de la motivacin, la capacidad in-
dividual de los miembros del equipo, as como sus relaciones como
equipo, probablemente tienen la mayor influencia en la productividad
(Boehm, 1981; Lakhanpal, 1993). Contratar apurando el fondo del barril
REFERENCIA
CRUZADA
Para ms informacin
sobre la creacin de
equipos efectivos,
vase el Captulo 12,
Equipo de trabajo".
REFERENCIAS
CRUZADAS
Para ms informacin
sobre proyectos
heroicos y basados en
compromiso, consulte
la Seccin 2.5, Una
estrategia alternativa
para el desarrollo
rpido; la Seccin 8.5,
Planificacin basada
en compromiso, o el
Captulo 34,
Compromiso".
REFERENCIA
CRUZADA
Para ver alternativas a
la hora de salvar un
proyecto retrasado,
consulte el Captulo 16,
Recuperacin de
proyectos".
Captulo 3: Errores clsicos 47
supondr una amenaza al esfuerzo del desarrollo rpido. En el ejemplo, la
seleccin del personal se hizo buscando quin podra contratarse ms r-
pido, en vez de quin realizara la mayora del trabajo durante la vida del
proyecto. Esta tcnica consigue un inicio rpido del proyecto, pero no
determina un final rpido.
3: Empleados problemticos incontrolados. Un fallo al tratar con
personal problemtico tambin amenaza la velocidad de desarrollo. Es un
problema habitual, y se ha comprendido bien, al menos desde que Gerald
Weinberg public Psychology of Computer Programming en 1971. Un fallo
al tomar una decisin cuando se trata con un empleado problemtico es
una de las quejas ms comunes que tienen Jos miembros del equipo respecto
de sus responsables (Larson y LaFasto, 1989). En el Ejemplo 3.1, el equi-
po saba que Chip era una manzana podrida, pero el jefe del equipo no
hizo nada. El resultado era predecible: rehacer el trabajo de Chip.
4: Hazaas. Algunos desarrolladores de software ponen un gran nfa-
sis en la realizacin de hazaas en los proyectos (Bach, 1995). Pero lo
que hacen tiene ms de malo que de bueno. En el ejemplo, los directivos
de nivel medio dieron mayores aplausos a actitudes del tipo ser capaz de
que a los progresos firmes y consistentes y a los informes significativos
de progreso. El resultado fue un modelo de planificacin al lmite en el
que las amenazas de desajuste del plan no se detectaban, ni se conocan o
ni se informaban a la cadena de directivos hasta el ltimo minuto. Un
pequeo equipo de desarrollo y sus jefes inmediatos toman como rehenes
a una compaa entera por no admitir que tienen problemas para cumplir
su plan. El nfasis en los comportamientos heroicos fomenta correr un
riesgo extremo, e impide la cooperacin entre los mltiples elementos que
contribuyen al proceso de desarrollo del software.
Algunos directivos fomentan el comportamiento heroico cuando se
concentran con demasiada firmeza en actitudes ser capaz de. Elevando
estas actitudes por encima de informes del estado exactos y a veces pesi-
mistas, los directivos de estos proyectos coartan su capacidad de tomar
medidas correctivas. Ni siquiera saben que tienen que emprender accio-
nes correctoras hasta que el dao ya est hecho. Como dijo Toro DeMar-
co, las actitudes ser capaz de convierten pequeos contratiempos en
autnticos desastres (DeMarco, 1995).
5: Aadir ms personal a un proyecto retrasado. ste es quizs
el ms clsico de los errores clsicos. Cuando un proyecto se alarga, aa-
dir ms gente puede quitar ms productividad a los miembros del equipo
existente de la que aaden los nuevos miembros. Fred Brooks com-
para aadir gente a un proyecto retrasado con echar gasolina en un fuego
(Brooks, 1975).
48 Desarrollo y gestin de proyectos informticos
REFERENCIA
CRUZADA
Para ms informacin
sobre los efectos del
entorno psicolgico en
la productividad,
consulte el Captulo 30,
Entornos
productivos.
REFERENCIA
CRUZADA
Para ms informacin
sobre las relaciones
efectivas con los
clientes, consulte el
Captulo 1 O,
Desarrollo orientado
al cliente.
REFERENCIA
CRUZADA
Para ms informacin
sobre fijar
expectativas, consulte
la Seccin 10.3,
Gestin de las
expectativas del
cliente.
6: Oficinas repletas y ruidosas. La mayora de los desarrolladores
consideran sus condiciones de trabajo como insatisfactorias. Alrededor
del 60 por 100 indican que no tienen suficiente silencio ni privacidad (De-
Marco y Lister, 1987). Los trabajadores que estn en oficinas silenciosas
y privadas tienden a funcionar significativamente mejor que aquellos que
ocupan cubculos en salas ruidosas y repletas. Los entornos repletos y
ruidosos alargan los planes de desarrollo.
7: Fricciones entre los clientes y los desarrolladores. Las friccio-
nes entre los clientes y los desarrolladores pueden presentarse de distintas
formas. A los clientes puede parecerles que los desarrolladores no coope-
ran cuando rehsan comprometerse con el plan de desarrollo que desean
los clientes o cuando fallan al entregar lo prometido. A los desarrollado-
res puede parecerles que los clientes no son razonables porque insisten en
planes irreales o cambios en los requerimientos despus de que stos ha-
yan sido fijados. Pueden ser simplemente conflictos de personalidad en-
tre dos grupos.
El principal efecto de esta friccin es la mala comunicacin, y los
efectos secundarios de la mala comunicacin incluyen el pobre enten-
dimiento de los requerimientos, pobre diseo de la interfaz de usuario y,
en el peor caso, el rechazo del cliente a aceptar el producto acabado. En el
caso medio, las fricciones entre clientes y desarrolladores de software lle-
gan a ser tan severas que ambas partes consideran la cancelacin del pro-
yecto (Jones, 1994 ). Para remediar estas fricciones se consume tiempo, y
distraen tanto a desarrolladores como a clientes del trabajo real en el pro-
yecto.
8: Expectativas poco realistas. Una de las causas ms comunes de
fricciones entre los desarrolladores y sus clientes o los directivos son las
expectativas poco realistas. En el Ejemplo 3.1, Bill no tena razones para
pensar que el programa Giga-Quote se podra desarrollar en 6 meses, pero
se era el plazo en que lo quera el comit ejecutivo de la compaa. La
incapacidad de Mike de corregir esta expectativa irreal fue la principal
fuente de problemas.
En otros casos, los directivos o los desarrolladores de un proyecto se
buscan problemas al pedir fondos basndose en estimaciones de planifi-
cacin demasiado optimistas. A veces prometen un conjunto de funcio-
nes tan altas como la Luna.
Aunque por s mismas las expectativas irreales no alargaran el plan,
contribuyen a la percepcin de que el plan de desarrollo es demasiado
largo, y de que puede ser malo. Una inspeccin de Standish Group marc
las expectativas realistas como uno de los cinco factores principales ne-
cesarios para asegurar el xito de los proyectos internos de software de
gestin (Standish Group, 1994).
REFERENCIA
CRUZADA
Para ms informacin
sobre las polticas de
seguridad, consulte la
Seccin 10.3, Gestin
de las expectativas del
cliente".
Captulo 3: Errores clsicos 49
9: Falta de un promotor efectivo del proyecto. Para soportar mu-
chos de los aspectos del desarrollo rpido es necesario un promotor del
proyecto de alto nivel, incluyendo una planificacin realista, el control de
cambios y la introduccin de nuevos mtodos de desarrollo. Sin un pro-
motor ejecutivo efectivo, el resto del personal de alto nivel de la empresa
puede forzar a que se acepten fechas de entrega irreales o hacer cambios
que debiliten el proyecto. El consultor australiano Rob Thomsett afirma
que la falta de un promotor efectivo garantiza virtualmente el fracaso del
proyecto (Thomsett, 1995).
10: Falta de participacin de los implicados. Todos los principales
participantes del esfuerzo de desarrollo de software deben implicarse en
el proyecto. Incluyendo a los promotores, ejecutivos, responsables del equi-
po, miembros del equipo, personal de ventas, usuarios finales, clientes y
cualquiera que se juegue algo con el proyecto. La cooperacin estrecha
slo se produce si se han implicado todos los participantes, permitiendo
una coordinacin precisa del esfuerzo para el desarrollo rpido, que es
imposible conseguir sin una buena participacin.
11: Falta de participacin del usuario. La inspeccin de Standish
Group descubri que la razn nmero uno de que los proyectos de Siste-
mas de Informacin tuviesen xito es la implicacin del usuario (Standish
Group, 1994). Los proyectos que no implican al usuario desde el princi-
pio corren el riesgo de que no se comprendan los requerimientos del pro-
yecto, y son vulnerables a que se consuma tiempo en prestaciones que
ms tarde retrasarn el proyecto.
12: Poltica antes que desarrollo. Larry Constantine indic que si
hay cuatro equipos hay cuatro tipos diferentes de orientaciones polticas
(Constantine, 1995a). Los polticos estn especializados en la gestin,
centrndose en las relaciones con sus directivos. Los investigadores>> se
centran en explorar y reunir informacin. Los aislacionistas estn so-
los, creando fronteras para el proyecto que mantienen cerradas a los que
no son miembros del equipo. Los generalistas hacen un poco de todo:
establecen relaciones con sus directivos, realizan investigaciones y ex-
ploran actividades, y se coordinan con otros equipos como parte de su
modo de trabajo. Constantine indic que inicialmente los equipos polti-
cos y generalistas estn bien vistos por Jos directivos de alto nivel. Pero
despus de un ao y medio, los equipos polticos llegan a la muerte sbi-
ta. Primar la poltica en vez de los resultados es fatal para el desarrollo
orientado a la velocidad.
13: Ilusiones. Estoy impresionado de ver cuntos problemas del desa-
rrollo del software se deben a la ilusin. Cuntas veces hemos escuchado
cosas como stas a distintas personas:
50 Desarrollo y gestin de proyectos informticos
REFERENCIA
CRUZADA
Para ms informacin
sobre los planes
irreales, consulte la
Seccin 9.1,
"Planificacin
excesivamente
optimista.
Ninguno de los miembros del proyecto cree realmente que pueda com-
pletarse el proyecto de acuerdo con el plan que tienen, pero piensan que
quizs si trabajan duro, y nada va mal, y tienen un poco de suerte, sern
capaces de concluir con xito.
Nuestro equipo no hace mucho trabajo para la coordinacin de las
interfaces entre las distintas partes del producto, pero tenemos una buena
comunicacin para otras cosas, y las interfaces son relativamente simples,
as que probablemente slo necesitaremos un da o dos para eliminar los
errores.
Sabemos que contamos con un desarrollador externo de poco talento
para el subsistema de la base de datos, y que es dificil ver cmo va a acabar
el trabajo con los niveles de personal que ha especificado en su propuesta.
No tienen tanta experiencia como algunos de los dems desarrolladores
externos, pero puede que compensen con energa lo que les falta en expe-
riencia. Probablemente acaben a tiempo.
No necesitamos reflejar la ltima lista de cambios en el prototipo para
el cliente. Estoy seguro de que por ahora sabemos lo que quiere.
El equipo est diciendo que realizar un esfuerzo extraordinario para
cumplir con la fecha de entrega, y que no han llegado a su primer hito por
pocos das, pero creo que alcanzarn ste a tiempo.
Las ilusiones no son slo optimismo. Realmente consisten en cerrar
los ojos y esperar que todo funcione cuando no se tienen las bases razona-
bles para pensar que ser as. Las ilusiones al comienzo del proyecto lle-
van a grandes explosiones al final. Impiden llevar a cabo una planifica-
cin coherente y pueden ser la raz de ms problemas en el software que
todas las otras causas combinadas.
Proceso
Los errores relacionados con el proceso ralentizan los proyectos porque
malgastan el talento y el esfuerzo del personal. A continuacin se mues-
tran algunos de los peores errores relacionados con el proceso.
14: Planificacin excesivamente optimista. Los retos a los que se
enfrenta alguien que desarrolla una aplicacin en tres meses son muy
diferentes de aquellos a los que se enfrenta alguien que desarrolla una
aplicacin que necesita un ao. Fijar un plan excesivamente optimista pre-
dispone a que el proyecto falle por infravalorar el alcance del proyecto,
minando la planificacin efectiva, y reduciendo las actividades crticas
para el desarrollo, como el anlisis de requerimientos o el diseo. Tam-
bin supone una excesiva presin para los desarrolladores, quienes a largo
plazo se ven afectados en su moral y su productividad. sta es la mayor
fuente de problemas del Ejemplo 3.1.
REFERENCIA
CRUZADA
Para ms informacin
sobre la gestin de los
riesgos, consulte
el Captulo 5, Gestin
de riesgos".
REFERENCIA
CRUZADA
Para ms informacin
sobre contratados,
consulte el
Captulo 28,
Desarrollo externo".
REFERENCIA
CRUZADA
Para ms informacin
sobre la planificacin,
consulte
Planificacin",
en la Seccin 4.1.
REFERENCIAS
CRUZADAS
Para ms informacin
sobre planificacin
bajo presin, consulte
la Seccin 9.2,
Disminucin de la
presin de la
planificacin", y el
Captulo 16,
Recuperacin de
proyectos".
REFERENCIA
CRUZADA
Para ms informacin
sobre escatimar en las
actividades iniciales,
consulte "Electos de la
planificacin
excesivamente
optimista", en la
Seccin 9.1.
Captulo 3: Errores clsicos 51
15: Gestin de riesgos insuficiente. Algunos errores no son lo sufi-
cientemente habituales como para considerarlos clsicos. Son los llamados
riesgos. Como con los errores clsicos, si no ejercemos una gestin activa
de los riesgos, con que slo vaya mal una cosa se pasar de tener un pro-
yecto con un desarrollo rpido a uno con un desarrollo lento. El fallo de
no gestionar uno solo de estos riesgos es un error clsico.
16: Fallos de los contratados. Las compaas a veces contratan la
realizacin 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 especificacin (Boehm, 1989). Riesgos como requerimientos inesta-
bles o interfaces mal definidas pueden ser enormes cuando un contratado
entra en escena. Si las relaciones con los contratados no se gestionan cui-
dadosamente, la utilizacin de desarrolladores externos puede ralentizar
el proyecto en vez de acelerarlo.
17: Planificacin insuficiente. Si no planificamos para conseguir un
desarrollo rpido, no podemos esperar obtenerlo.
18: Abandono de la planificacin bajo presin. Los equipos de desa-
rrollo hacen planes y rutinariamente los abandonan cuando se tropiezan
con un problema en la planificacin (Humphrey, 1989). El problema no est
en el abandono del plan, sino ms bien en fallar al no crear un plan alter-
nativo, y caer entonces en el modo de trabajo de codificar y corregir. En
el Ejemplo 3.1, el equipo abandon su plan despus de fallar en la primera
entrega, y esto es lo habitual. A partir de este punto, el trabajo no tuvo
coordinacin ni elegancia, hasta el punto de que Jill empez a trabajar
parte del tiempo para un proyecto de su viejo grupo y nadie lo supo.
19: Prdida de tiempo en el inicio difuso. El inicio difuso>> es el
tiempo que transcurre antes de que comience el proyecto; este tiempo
normalmente se pierde en el proceso de aprobar y hacer el presupuesto. No
es poco comn que un proyecto desperdicie meses o aos en un inicio difu-
so, y entonces se est a las puertas de un plan agresivo. Es mucho ms fcil
y barato y menos arriesgado suprimir unas pocas semanas o meses del inicio
difuso en vez de comprimir el plan de desarrollo en ese mismo tiempo.
20: Escatimar en las actividades iniciales. Los proyectos que se
aceleran intentando acortar las actividades no esenciales, y puesto que el
anlisis de requerimientos, la arquitectura y el diseo no producen cdigo
directamente, son los candidatos fciles. En un proyecto desastroso en el
que particip, ped que me enseasen el diseo. El responsable del equipo
me dijo: No hemos tenido tiempo de hacer el diseo.
52 Desarrollo y gestin de proyectos informticos
DATOS REALES
REFERENCIA
CRUZADA
Para ms informacin
sobre control de
calidad, consulte la
Seccin 4.3, Bases
del control de calidad".
DATOS REALES
REFERENCIAS
CRUZADAS
Para ms informacin
sobre controles de la
directiva, consulte
Seguimiento", en
la Seccin 4.1, y el
Capftulo 27, Hitos
miniatura".
Los resultados de este error, tambin conocido como saltar a la
codificacin, son todos demasiado predecibles. En el ejemplo, un truco
de diseo en el informe del grfico de barras fue sustituido por un trabajo
de diseo de calidad. Antes de poder entregar el producto, el trabajo con
truco tuvo que tirarse, y hubo que hacer de todos modos el trabajo bien
hecho. Los proyectos que normalmente escatiman en sus actividades
iniciales tendrn que hacer ese trabajo en otro momento, con un coste
de lO a 100 veces superior a haberlo hecho bien inicialmente (Fagan, 1976;
Boehm y Papaccio, 1988). Si no podemos encontrar cinco horas para hacer
el trabajo correctamente la primera vez, cmo vamos a encontrar 50 para
hacerlo correctamente ms tarde?
21: Diseo inadecuado. Un caso especial de escatimar en las activi-
dades iniciales es el diseo inadecuado. Proyectos acelerados generan un
diseo indeterminado, no asignando suficiente tiempo para l y originan-
do un entorno de alta presin que hace dificil la posibilidad de considerar
alternativas en el diseo. El nfasis en el diseo est ms orientado a la
conveniencia que a la calidad, por lo que necesitar varios ciclos de dise-
o antes de poder finalizar completamente el sistema.
22: Escatimar en el control de calidad. En los proyectos que se ha-
cen con prisa se suele cortar por lo sano, eliminando las revisiones del
diseo y del cdigo, eliminando la planificacin de las pruebas y reali-
zando slo pruebas superficiales. En el ejemplo, las revisiones del diseo
y del cdigo se eliminaron limpiamente para conseguir una ganancia con-
siderable en el plan. Al final, cuando el proyecto alcanz su hito de plena
funcionalidad, an tena demasiados errores y se retras ms de 5 meses.
Este resultado es tpico. Acortar en un da las actividades de control de
calidad al comienzo del proyecto probablemente supondr de 3 a 1 O das
de actividades finales (Jones, 1994 ). Esta reduccin va contra la velo-
cidad de desarrollo.
23: Control insuficiente de la directiva. En el ejemplo hay poco con-
trol de la directiva para detectar a tiempo los signos de posibles retrasos en
el plan, y los pocos controles definidos al comienzo se abandonaron 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.
24: 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 pro-
ducto, imprimir la documentacin final, incorporar entradas en el sistema
final de ayuda, pulir el programa de instalacin, eliminar las funciones que
no van a estar listas a tiempo y dems. En proyectos hechos con prisa,
REFERENCIA
CRUZADA
Para ms informacin
sobre la convergencia
prematura, consulte
Convergencia
prematura,., en la
Seccin 9.1.
REFERENCIA
CRUZADA
Para ms informacin
sobre las tareas
habituales omitidas,
consulte No omita
tareas comunes", en la
Seccin 8.3.
REFERENCIA
CRUZADA
Para ms informacin
sobre la reestimacin,
consulte
Recalibracin .. , en la
Seccin 8. 7.
REFERENCIA
CRUZADA
Para ms informacin
sobre el enfoque de
codificar y corregir,
consulte la Seccin 7.2,
Codificar y corregir".
Captulo 3: Errores clsicos 53
hay una tendencia a forzar prematuramente la convergencia. Puesto que
no es posible forzar la convergencia del producto cuando se desea, algunos
proyectos de desarrollo rpido intentan forzar la convergencia media do-
cena de veces o ms antes de que finalmente se produzca. Los intentos
adicionales de convergencia no benefician al producto. Slo son una pr-
dida de tiempo y prolongan el plan.
25: Omitir tareas necesarias en la estimacin. Si la gente no guar-
da cuidadosamente datos de proyectos anteriores, olvida las tareas me-
nos visibles, pero son tareas que se han de aadir. El esfuerzo omitido
suele aumentar el plan de desarrollo en un 20 o 30 por 100 (Van Genuch-
ten, 1991 ).
26: Planificar ponerse al da ms adelante. Un tipo de reestimacin
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, qu hacer? En muchos proyectos
simplemente se plantea recuperar el retraso ms tarde, pero nunca se hace.
Aprenderemos ms del producto conforme lo estamos construyendo, in-
cluyendo ms sobre lo que nos llevar construirlo. Estos conocimientos
necesitan reflejarse en la reestimacin del plan.
Otro tipo de error en la reestimacin se debe a cambios en el produc-
to. Si el producto que estamos construyendo cambia, la cantidad de tiempo
necesaria para construirlo cambiar tambin. En el Ejemplo 3.1, los reque-
rimientos principales cambiaron entre la propuesta original y el comienzo
del proyecto sin la correspondiente reestimacin del plan o de los recursos.
El crecimiento de las nuevas prestaciones sin ajustar el plan garantiza que
no se alcanzar la fecha de entrega.
27: Programacin a destajo. Algunas organizaciones creen que la co-
dificacin rpida, libre, tal como salga, es el camino hacia el desarrollo
rpido. Piensan que si los desarrolladores estn lo suficientemente moti-
vados, pueden solventar cualquier obstculo. Debido a las razones que se
vern claramente a lo largo de todo este libro, esto est lejos de la verdad.
Este enfoque muchas veces se presenta como un enfoque empresariab)
al desarrollo de software, pero realmente es slo la envoltura del viejo
paradigma a destajo combinado con una planificacin ambiciosa, y esta
combinacin raras veces funciona. Es un ejemplo de que dos negaciones
no constituyen una verdad.
Producto
A continuacin se muestran los errores clsicos relacionados con la for-
ma en la que se define el producto.
54 Desarrollo y gestin de proyectos informticos
REFERENCIA
CRUZADA
Para ms informacin
sobre el cambio de
prestaciones, consulte
el Captulo 14,
Control del conjunto
de prestaciones.
REFERENCIA
CRUZADA
Para consultar
un ejemplo sobre
cmo, incluso
accidentalmente, un
desarrollador puede
caer en requerimientos
excesivos o superfluos,
vase Objetivos poco
claros o imposibles,
en la Seccin 14.2.
28: Exceso de requerimientos. Algunos proyectos tienen ms reque-
rimientos de los que necesitan, desde el mismo inicio. La eficiencia se
fija como requisito ms a menudo de lo que es necesario, y puede generar
una planificacin del software innecesariamente larga. Los usuarios tien-
den a interesarse menos en las prestaciones complejas que en las de las
secciones de marketing o de desarrollo, y las prestaciones complejas alar-
gan desproporcionadamente el plan de desarrollo.
29: Cambio de las prestaciones. Incluso si hemos evitado con xito los
requerimientos excesivos, los proyectos sufren como media sobre un
25 por 100 de cambios en los requerimientos a lo largo de su vida (Jo-
nes, 1994). Un cambio de este calibre puede producir un aumento en el
plan de al menos un 25 por 100, lo que puede ser fatal para los proyectos
de desarrollo rpido.
30: Desarrolladores meticulosos. Los desarrolladores encuentran
fascinante la nueva tecnologa, y a veces estn ansiosos por probar nuevas
prestaciones de su lenguaje o entorno, o por crear su propia implementa-
cin de una utilidad bonita que han visto en otro producto, la nece-
site o no su producto. El esfuerzo requerido para disear, implementar,
probar, documentar o mantener estas prestaciones innecesarias alarga
el plan.
31: Tiras y aflojas en la negociacin. Cuando un directivo aprueba
un retraso en el plan de un proyecto que progresa ms lento de lo espera-
do, y entonces aade tareas completamente nuevas despus de un cambio
en el plan, se produce una situacin curiosa. La razn subyacente de esto
es dificil de localizar, puesto que el directivo que aprueba el retraso en el
plan lo hace sabiendo implcitamente que el plan estaba equivocado. Pero
una vez que se corrige, la misma persona realiza acciones explcitas para
volver a equivocarse. Esto slo puede ir en contra del plan.
32: Desarrollo orientado a la investigacin. Seymour Cray, el di-
seador de los supercomputadores Cray, dijo que no intentaba sobrepasar
los lmites de la ingeniera en ms de dos reas a la vez, porque el riesgo de
un fallo es demasiado alto (Gilb, 1988). Muchos proyectos software debe-
ran aprender la leccin de Cray. Si el proyecto fuerza los lmites de la
informtica porque necesita la creacin de nuevos algoritmos o de nuevas
tcnicas de computacin, no estamos desarrollando software; estamos
investigando en software. Los planes de desarrollo de software son razona-
blemente predecibles; los planes en la investigacin sobre software ni
siquiera son predecibles tericamente.
Si el producto tiene objetivos que pretenden aumentar los conocimientos
REFERENCIA
CRUZADA
Para ms informacin
sobre el sndrome de
la panacea, consulte la
Seccin 15.5, El
sndrome de la
panacea ...
REFERENCIA
CRUZADA
Para ms informacin
sobre cmo salvar las
estimaciones usando
herramientas de
mejora de
productividad,
consulte "Reduccin
realista del plan .. , en
la Seccin 15.4.
REFERENCIA
CRUZADA
Para ms informacin
sobre la reutilizacin,
consulte el Capitulo 33,
"Reutilizacin ...
Captulo 3: Errores clsicos 55
existentes, como algoritmos, velocidad, utilizacin de la memoria y de-
ms, debemos asumir que la planificacin es altamente especulativa. Si
queremos mejorar el estado del arte y tenemos algn otro punto dbil en
el proyecto, recortes de personal, debilidades en el personal, requerimientos
vagos, interfaces inestables con contratados externos, etc., podemos tirar
por la ventana la planificacin prevista. Si queremos superar el estado del
arte por todos los medios, hagmoslo. Pero no debemos esperar hacerlo
rpidamente!
Tecnologa
El resto de los errores clsicos estn relacionados con el uso correcto o
incorrecto de la tecnologa moderna.
33: Sndrome de la panacea. En el ejemplo, se confi demasiado
en las ventajas proclamadas de tecnologas que no se haban usado antes
(generadores de informes, diseo orientado a objetos y C++) y demasiada
poca informacin sobre lo buenas que seran en este entorno de desarrollo
concreto. Cuando el equipo del proyecto se aferra slo a una nueva tc-
nica, una nueva tecnologa o un proceso rgido, y espera resolver con
ello sus problemas de planificacin, est inevitablemente equivocado (Jo-
nes, 1994).
34: Sobreestimacin de las ventajas del empleo de nuevas herra-
mientas o mtodos. Las organizaciones mejoran raramente su produc-
tividad a grandes saltos, sin importar cuntas nuevas herramientas o m-
todos empleen o lo buenos que sean. Los beneficios de las nuevas tcnicas
son parcialmente desplazados por las curvas de aprendizaje que llevan
asociadas, y aprender a utilizar nuevas tcnicas para aprovecharlas al
mximo lleva su tiempo. Las nuevas tcnicas tambin suponen nuevos
riesgos, que slo descubriremos usndolas. Ms bien experimentaremos
mejoras lentas y continuas en un pequeo porcentaje por proyecto en lu-
gar de grandes saltos. El equipo del Ejemplo 3.1 debera haber previsto
como mucho un 10 por 100 de ganancia en productividad por la utiliza-
cin de las nuevas tecnologas en vez de asumir que estaran cerca de
duplicar su productividad.
Un caso especial de sobreestimaciones de las mejoras se produce cuan-
do se reutiliza cdigo de proyectos anteriores. Este tipo de reutilizacin
puede ser una tcnica muy efectiva, pero el tiempo que se gana no es tan
grande como se espera.
35: Cambiar de herramientas a mitad del proyecto. Es un viejo
recurso que funciona raramente. A veces puede tener sentido actualizar
56 Desarrollo y gestin de proyectos informticos
REFERENCIA
CRUZADA
Para ms informacin
sobre el control
del cdigo fuente,
consulte Gestin de
la configuracin
del software, en la
Seccin 4.2.
incrementalmente dentro de la misma lnea de productos, de la versin 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 cometi-
dos con una herramienta totalmente nueva, normalmente anulan cualquier
posible beneficio.
36: Falta de control automtico del cdigo fuente. Un fallo en la
utilizacin del control automtico del cdigo fuente expone a los proyectos
a riesgos innecesarios. Sin l, si dos desarrolladores estn trabajando en la
misma parte del programa, deben coordinar su trabajo manualmente. De-
beran ponerse de acuerdo para poner la ltima versin de cada archivo
en el directorio maestro y verificarlos con los dems antes de copiarlas en
este directorio. Pero invariablemente alguno sobreescribir el trabajo del
otro. Se desarrolla nuevo cdigo con interfaces desfasadas, y despus se
tiene que redisear el cdigo al descubrir que se ha utilizado una versin
equivocada de la interfaz. Los usuarios avisan de errores que no podemos
reproducir porque no hay forma de volver a crear los elementos que han
utilizado. Como media, los cambios en el cdigo fuente suelen ser de un 1 O
por 100 al mes, y con un control manual del cdigo fuente no deberan
crecer (Jones, 1994).
La Tabla 3.1, de la pgina siguiente, contiene una lista completa de
los errores clsicos.
3.4. La fuga de La isla de Gilligan
Una lista completa de los errores clsicos ocupara muchas ms pginas,
pero los que se indican son los ms comunes y los ms serios. Como indic
David Umpress, de la Universidad de Seattle, la vigilancia que la mayora
de las organizaciones realiza para evitar estos errores es como ver una y
otra vez La isla de Gilligan. Al principio de cada episodio, Gilligan, el
Capitn o el Profesor llegaban con un plan tonto para salir de la isla. El plan
pareca funcionar inicialmente, pero, como revelaba el episodio, algo iba
mal, y al final del episodio los nufragos volvan donde haban empeza-
do, perdidos en la isla.
De igual forma, la mayora de las compaas descubre al final de cada
proyecto que han cometido otro error clsico y que han entregado otro
proyecto fuera de plazo, con mayor coste, o ambas cosas.
Su propia lista de malos hbitos
Debe ser cuidadoso con los errores clsicos. Puede crear listas de malos
hbitos para evitarlos en futuros proyectos. Comience por la lista que apa-
Tabla 3.1. Resumen de los errores clsicos
Errores relacionados
con las personas
l. Motivacin dbil
2. Personal mediocre
3. Empleados
problemticos
incontrolados
4. Hazaas
5. Aadir ms
personal a un
proyecto retrasado
6. Oficinas repletas
y ruidosas
7. Fricciones entre
los clientes y los
desarrolladores
8. Expectativas poco
realistas
9. Falta de un
promotor efectivo
del proyecto
10. Falta de
participacin de
los implicados
11. Falta de
participacin del
usuario
12. Poltica antes que
desarrollo
13. Ilusiones
Errores relacionados
con el proceso
14. Planificacin
excesivamente
optimista
15. Gestin de riesgos
insuficiente
16. Fallos de los
contratados
17. Planificacin
insuficiente
18. Abandono de la
planificacin bajo
presin
19. Prdida de tiempo
en el inicio difuso
20. Escatimar en las
actividades
iniciales
21. Diseo inadecuado
22. Escatimar en el
control de calidad
23. Control
insuficiente de la
directiva
24. Convergencia
prematura o
excesivamente
frecuente
25. Omitir tareas
necesarias en la
estimacin
26. Planificar ponerse
al da ms adelante
27. Programacin a
destajo
Captulo 3: Errores clsicos 57
Errores relacionados
con el producto
28. Exceso de
requerimientos
29. Cambio de las
prestaciones
30. Desarrolladores
meticulosos
31. Tiras y aflojas en
la negociacin
32. Desarrollo
orientado a la
investigacin
Errores relacionados
con la tecnologa
33. Sndrome de la
panacea
34. Sobreestimacin
de las ventajas del
empleo de nuevas
herramientas o
mtodos
35. Cambiar de
herramientas a
mitad del proyecto
36. Falta de control
automtico del
cdigo fuente
rece en este captulo. Vaya incrementando la lista segn se vayan acabando
proyectos para aprender de los errores cometidos por su equipo. Estimule
este comportamiento para otros proyectos dentro de la empresa, para
58 Desarrollo y gestin de proyectos informticos
aprender de sus errores. Intercambie experiencias con los colegas de otras
organizaciones y aprenda de su experiencia. Exhiba en lugar visible la
lista de errores, y as la gente la ver y aprender sin cometer de nuevo los
mismos errores.
Bibliografa adicional
Aunque algunos libros tratan sobre errores de cdigo, no conozco libros
que describan los errores clsicos relacionados con los planes de desarrollo.
En el resto de este libro se incluyen referencias sobre temas relacionados.