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.
8111

3
Errores clsicos

Contenido
3.1.
3.2.
3.3.
3.4.

Ejemplo de errores clsicos

Efecto de los errores en la programacin de un desarrollo
Relacin de errores clsicos
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. .foJ!~\),S.J>ara el programa GigaQuote !>> Era Bill, el jefe de.Mike enGiga, :qJ:}a C,mnpaa de seguros mdicos. Al comit ejecutivo le ha gustado la id~ade automatizar nuestras
cuotas de seguro mdico. Y tambin la idea de volcar cada noche las cuotas 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 capacidad de comunicacin con la oficina principaL Perfecto, sta era la oportunidad 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 ejecutivo 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. Adelantaron 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 personas-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 software 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 herramienta de elaboracin de informes que supuestamente acortaba el tiempo de desarrollo a la mitad. El proyecto tena bastantes informes, y por
tanto esos dos cambios Jos llevaran hastalos 9 meses. Consiguieron hardware nuevo y ms rpido, y esto les ahorraba un par de semanas. Si realmente 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 suficiente. 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 re~cir ~~ p~n~ ~eis ~e~e~, o .tendris
.
que hacer algunas horas extra p~a 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 extemos~:.Keiko 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 queran~contratarlo, pero Mike lo impuso. 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 serian 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 proporcionado una especificacin aproximada, y emplearon las siguientes dos semanas 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 aproximada 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 probarlas no despus del 1 de septiembre, con el propsito de tener un producto 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 comenzaron a codificar como locos para llegar al ppjpt~yq,deJe,Qerla p~in;.erajver~ .
sin de prueba el 1 de septiembre. EHral>ajo~ti;,etproy~<;~p.np:era una
balsa de aceite. Ni a Jill ni a Tomas les g1l~tab~~.~hil:l;y,Se se quejabade
que no quera que nadie se acercase a su cdgoJMike atribuy}os choques de personalidades a las muchas horas de trabajo. No obstante, a primeros 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 estaba 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,
1O 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 semanas 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 cuot~"j~~luye' un grfico de. ba~
rras. He utilizado un generador de infor.tllesque-tupo,niagen~raba grficos
de barras, pero la nica forma de geneqtrl,S'r~~~t}':t~g\AASzip:di~idual~~ '
Uno de los requerimientos del grupo de, ~entas:~~;q;~:tffl}a~;tu~,ponet grij~
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 textodeUnfof$~ c~.n1o una
leyenda del objeto grfico de barJ;BS: Realm,ente,ys 'uria trampa;,p~to.siem:
pre puedo volver atrs y reimplementarlo ~as:claramente '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 pruebas de ejecucin. Mike vio que Jill y Tomas se miraban, pero decidi ignorarlo.
El equipo trabaj duro hasta el 15 de noviembre, incluyendo las noches 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 maana 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 cumpliendo 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 semanas de trabajo de limpieza una vez que lo entregue. Mike pregunt qu
quera decir Tomas con limpieza>;. No he puesto el logotipo de la~em
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 funciona 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 dela~utilidad completa",
Ahora Mike tambin empezaba a s~.ntir~~:wa,t. ~<Si h~.~rfdo ~o que creo
que he odo, me estis diciendo que necesiti$,:-tres semanas )atll ~ompletar

el software. Es correcto?
_, ,_ -, ~-- -_:<:~:{~~~);~/;~;_;~, ,_\0~,
--~"_:: ,~ ;--,, : , _
<<Al menos tres semanas; dijp,Jill.\Sit;~{cidt:tlosdesar~l)adoresestu~

vo de acuerdo. Mike pas uno por,un y:le~.pi:egunt'si podfi8.n completar

su parte en tres semanas. Unopor \JD.9~a<l~P1B~4dot1Miij().que trtlba.:.,.

jara duro, y que pensaba que poda hacerlo. ';';; :, ,

Al final de ese da, despus de una dis~usiq~:latga 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 1O. Bill dijo que
tena que demostrar a su jefe que. estaba a:ruzan4o~aJ equipo de desarrollo.,
La revisin del plan implicaba que tendran qe probar el cdigo y preparar al personal al mismo tiempo, pero era.la,:ni~a 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 GigaQuote completo al grupo de pruebas antes dellll~.io,da, y saH~on 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 s~~de,sat el ;
infierno. En dos das el grupo de pruebas identific~ mS de 200defetf~s 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. Probablemente 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 tena 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 desarrolladores que revisasen los errores que el grupo de pruebas les haba asignado 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 integrida~ referencial de la base ;

de datos. En total, necesito cuatro seman~s ~ p~irA~ hoy. L,,,
.. ..
Tomas haba devuelto elerror #143a)osicomp~:obadores,:cambiando:'
su severidad de 1 a 3 (Cambio esttico). El grupo de pruebas respondi
que los informes resumen de Giga~Quote tenan que coincidir con informes 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 acostumb~:ados a. ver sus valores de ~entas en gr
ficos de barras a la derecha, y tenanque quedarse ~Ja derec~~; ;,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 rees~ri~ir.,e~e infom~.~.CoJ1cret()
.desde el principio,Jo que. sgnifica,;.que tengo:,que' esctibit mi'prop()
cdigo a bajo nivel para dar fo~to .al infot;rn~1y algrfic;:,o~R Mi].(e t~m.,..
. . bl~ :,y pidi tina estimacin~.!Jpro~illlad!:'d~!;c:ti,ilto)iempo. necesitaba ..
:. omas dijo que porJl()imenqs)o:
'pero;CJ.] ' gpa.,,que V".rlo ms des~ .
.. F'~~io;.:~tes de,estar:seguro.ii..
~i~j~ . . . . ':;;; ,:/;i:';,):< . ":. ,:
. >' ~ntes de volver;,a casa..l\1t~~i:., c>.~:$~~yJ~.~illque ~fe,quipo<traba . :
,Jarla mcluso ls das defiesta:yqu~:~pdo J()$: ~rt~r~~;.epcontrado.s se con:~ <
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 pasado:veran()~
..

El mes siguiente Mik~ estu;v() ?Cup~dll~~~eltj~tld() a,:t~p .ll,llid~ ..
Durante cuatro meses habtan. tr~b,aja~BJodo~o. ?~ro que .se.PP~ia ..taba
jarj y no crea que pudiesen, pacer Js. Es!ab~~~p~J~. ofi(iUltfU })pras
al da, pero empleaban mucho> tiempo leyendo 'revistas, pagand factUras'
y hablando por telfono. Pareca que se irritaban, sie~pre que lc:s. pregun"
taba cunto les quedaba para redu~rla cuetlta de errores. Pt cada errr .
que se correga,. el grupo de Pl'll~bas 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 equipo 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 software 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 dC:cundopodr~ entregar
finalmente el producto. Mib 9~sabia qu decirle.a}3iU.
.
(contina)

42

Desarrollo y gestin de proyectos informticos

V

__

,,;o';~-

~;:}!:-'/-:~,:: ~7;~,i~;~:~-

,: : ,::~ '~!t~~,~T~fi~:~~-I-~~~ri,:F~,-~'~ :ir::<

01

Tras la reuni?n;:(;hip dijo,~~ik~:quei~~~ia:;~<fep~d

;tr.'f;~q~,au.,ee?:!,'
otra compaa y que empezaba;ep <ief~br~tQ
~~:~~
. . tt'< .. ,.
sera un alivio que secancela'a~l.proyecto
'~/.;,;;:;
"' .. ,:, :~: .
Mike busc. a Kip,.el programadorque~~~~iq~.r~s~&?,J~A~(ap~:i~E:}
d(), de. comuni~aci~n~s entre e~pg:y.e,~~~~~~r~ig~g~$!.~~PP~Pi~Ht;~
proyecto, y lo dedic a corregu.los errores en~~~ ~9qtg,:qe,
,nt~a~J.J~Qes;(:
, del PC. Despus de .\~har un~. se111ana'pon, ~t.c~~go,~~i~
:,;~ i~9~J.uT':;,'1
.. y que ten fa algunos, defeclQS conceptuale~pro>fundos \qp,e; ~~"(l;'<n~:e n9n"t;;;;;
ca funcionara correctamente..l(ipse vio>obJigad<Mv~Uisear yreiQ1plement~ :.: ..
la parte PC del enlace de com9nicaciones eij~rfer:Pf 'y el. mainfune:' ' ' .
Puesto que Bill se sali por la tangente en';}~' reunin ejecutiva e mi.:.
tad de febrero, finalmente Claire decidi. que. ya hab.fa odo, .suficien~e. 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 proyecto para encajarlo en un' plan art.ficial: :Si se necesitan otros'9 ~eses;quiero
saberlo. Quieroel informe del.tr~bajo pendiente P'P:'~ . el Wi.~;:~~!e$: !i~ t,ie~
ne. que ser bonito, pero tiene que estarcompleto:>> > . . ; t< .
.
El equipo de desarrollo se alegr de tener un fin de'semana libre~.y:
durante la semana siguiente atacaron el informe detallado conenrgias're~
novadas. Estuvo en la mesa de Claire para el mircoles. Revis el informe
con Charles, un asesor en ingeniera del software que tambin haba revisado las estadsticas de errores del proyecto. Charles recomend que el
equipo centrase sus esfuerzos en un puado de n;ldtilos'propens<,>s a erro7 .
.res, que se iniciasen inmediatamente revisicmes d~!' 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 subi 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 fijla''fe~ha .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)

Captulo 3: Errores clsicos

REFERENCIA
CRUZADA
En la Seccin 8.6,
Estimaciones simples
de planificacin, se
incluye una tabla con
las estimaciones
aproximadas para
proyectos de distintos
tamaos.

43

. La corporacin Giga Safe mostr su apre~io al tr~baj9.9~roJeal~ado

por el equipo de desarrollo dando a cada d,esarroJlaqor una l:Jql\i..~i6n de
250 dlares. Unas cuantas sem11nas ro~ tatde,}l'omaspidipna.larga,baJ~tt
.;;i:~'.c ' ' ' ;,,,)
y lill se fue a trabajar a otra. coropaja. ;,< ; ': .
El producto final GigaQuot~ se entr~g9 en 13 meses eri\r~z. 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 personasmes planificadas.
;:~l producto final tena entomoa40.000 llneas de c6digoC++ no va...
ciaiy sin comentario~, superior en ms de un 33 por 100 a las estimaciones
aproximadas de M,ik,~~ 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 esfuerzo 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 productividad (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 requerimientos, 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 programacin 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. Muestra 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 productividad realmente tenan una productividad pobre, como muestra la estrecha 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.

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

Mximo
Percentil del 75%
Media
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.

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 ...

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 productividad 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 aunque es necesario utilizar alguno de los mtodos recomendables, no es suficiente 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 productividad.
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 entrenador 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 baches, 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 tenemos que evitar cometer algn gran error. La siguiente seccin enumera
los grandes errores ms habituales.

3.3. Relacin de errores clsicos

ERROR CLSICO

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 retrasado? Metamos a ms gente! Tenemos que reducir el plan? Planifiquemos 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

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 consecuencias 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 velocidad de desarrollo: personas, proceso, producto y tecnologa.

Personas
A continuacin aparecen algunos de los errores clsicos relacionados con
las personas.
REFERENCIA
CRUZADA
Para ms informacin
sobre los buenos y
malos usos de la
motivacin, consulte el
Captulo 11,
"Motivacin".

1: Motivacin dbil. Estudio tras estudio se ha mostrado que la motivacin 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 individual 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

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 rpido, 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.
REFERENCIA
CRUZADA
Para ms informacin
sobre la creacin de
equipos efectivos,
vase el Captulo 12,
Equipo de trabajo".

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 equipo saba que Chip era una manzana podrida, pero el jefe del equipo no
hizo nada. El resultado era predecible: rehacer el trabajo de Chip.

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".

4: Hazaas. Algunos desarrolladores de software ponen un gran nfasis 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 pesimistas, los directivos de estos proyectos coartan su capacidad de tomar
medidas correctivas. Ni siquiera saben que tienen que emprender acciones correctoras hasta que el dao ya est hecho. Como dijo Toro DeMarco, las actitudes ser capaz de convierten pequeos contratiempos en
autnticos desastres (DeMarco, 1995).

REFERENCIA
CRUZADA
Para ver alternativas a
la hora de salvar un
proyecto retrasado,
consulte el Captulo 16,
Recuperacin de
proyectos".

5: Aadir ms personal a un proyecto retrasado. ste es quizs

el ms clsico de los errores clsicos. Cuando un proyecto se alarga, aadir ms gente puede quitar ms productividad a los miembros del equipo
existente de la que aaden los nuevos miembros. Fred Brooks compara 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.

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 (DeMarco 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.

REFERENCIA
CRUZADA
Para ms informacin
sobre las relaciones
efectivas con los
clientes, consulte el
Captulo 1O,
Desarrollo orientado
al cliente.

7: 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 rehsan 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 despus de que stos hayan sido fijados. Pueden ser simplemente conflictos de personalidad entre dos grupos.
El principal efecto de esta friccin es la mala comunicacin, y los
efectos secundarios de la mala comunicacin incluyen el pobre entendimiento 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 llegan a ser tan severas que ambas partes consideran la cancelacin del proyecto (Jones, 1994 ). Para remediar estas fricciones se consume tiempo, y
distraen tanto a desarrolladores como a clientes del trabajo real en el proyecto.

REFERENCIA
CRUZADA
Para ms informacin
sobre fijar
expectativas, consulte
la Seccin 10.3,
Gestin de las
expectativas del
cliente.

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 planificacin demasiado optimistas. A veces prometen un conjunto de funciones 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 necesarios para asegurar el xito de los proyectos internos de software de
gestin (Standish Group, 1994).

Captulo 3: Errores clsicos

49

9: Falta de un promotor efectivo del proyecto. Para soportar muchos 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 promotor 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 equipo, 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 Sistemas de Informacin tuviesen xito es la implicacin del usuario (Standish
Group, 1994). Los proyectos que no implican al usuario desde el principio corren el riesgo de que no se comprendan los requerimientos del proyecto, y son vulnerables a que se consuma tiempo en prestaciones que
ms tarde retrasarn el proyecto.
REFERENCIA
CRUZADA
Para ms informacin
sobre las polticas de
seguridad, consulte la
Seccin 10.3, Gestin
de las expectativas del
cliente".

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 solos, 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 exploran actividades, y se coordinan con otros equipos como parte de su
modo de trabajo. Constantine indic que inicialmente los equipos polticos 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 sbita. 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 desarrollo del software se deben a la ilusin. Cuntas veces hemos escuchado
cosas como stas a distintas personas:

50

Desarrollo y gestin de proyectos informticos

Ninguno de los miembros del proyecto cree realmente que pueda completarse 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 experiencia. 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 razonables para pensar que ser as. Las ilusiones al comienzo del proyecto llevan a grandes explosiones al final. Impiden llevar a cabo una planificacin 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 muestran algunos de los peores errores relacionados con el proceso.
REFERENCIA
CRUZADA
Para ms informacin
sobre los planes
irreales, consulte la
Seccin 9.1,
"Planificacin
excesivamente
optimista.

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 predispone 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. Tambin 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.

Captulo 3: Errores clsicos

51

REFERENCIA
CRUZADA
Para ms informacin
sobre la gestin de los
riesgos, consulte
el Captulo 5, Gestin
de riesgos".

15: Gestin de riesgos insuficiente. Algunos errores no son lo suficientemente 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 proyecto con un desarrollo rpido a uno con un desarrollo lento. El fallo de
no gestionar uno solo de estos riesgos es un error clsico.

REFERENCIA
CRUZADA
Para ms informacin
sobre contratados,
consulte el
Captulo 28,
Desarrollo externo".

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 inestables o interfaces mal definidas pueden ser enormes cuando un contratado
entra en escena. Si las relaciones con los contratados no se gestionan cuidadosamente, la utilizacin de desarrolladores externos puede ralentizar
el proyecto en vez de acelerarlo.

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.

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 desarrollo 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 alternativo, 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 difuso, 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

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?
Un caso especial de escatimar en las actividades iniciales es el diseo inadecuado. Proyectos acelerados generan un
diseo indeterminado, no asignando suficiente tiempo para l y originando 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 diseo antes de poder finalizar completamente el sistema.
21: Diseo inadecuado.

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".

22: Escatimar en el control de calidad. En los proyectos que se hacen con prisa se suele cortar por lo sano, eliminando las revisiones del
diseo y del cdigo, eliminando la planificacin de las pruebas y realizando slo pruebas superficiales. En el ejemplo, las revisiones del diseo
y del cdigo se eliminaron limpiamente para conseguir una ganancia considerable 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 1O das
de actividades finales (Jones, 1994 ). Esta reduccin va contra la velocidad de desarrollo.

23: Control insuficiente de la directiva. En el ejemplo hay 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 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.

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 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,
24: Convergencia prematura o excesivamente frecuente.

Captulo 3: Errores clsicos

53

REFERENCIA
CRUZADA
Para ms informacin
sobre la convergencia
prematura, consulte
Convergencia
prematura,., en la
Seccin 9.1.

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 docena de veces o ms antes de que finalmente se produzca. Los intentos
adicionales de convergencia no benefician al producto. Slo son una prdida de tiempo y prolongan el plan.

REFERENCIA
CRUZADA
Para ms informacin

25: Omitir tareas necesarias en la estimacin. Si la gente no guarda cuidadosamente datos de proyectos anteriores, olvida las tareas menos 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 Genuchten, 1991 ).

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".

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, incluyendo 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 producto. Si el producto que estamos construyendo cambia, la cantidad de tiempo
necesaria para construirlo cambiar tambin. En el Ejemplo 3.1, los requerimientos 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 codificacin rpida, libre, tal como salga, es el camino hacia el desarrollo
rpido. Piensan que si los desarrolladores estn lo suficientemente motivados, 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 forma en la que se define el producto.

54

Desarrollo y gestin de proyectos informticos

Algunos proyectos tienen ms requerimientos 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 tienden a interesarse menos en las prestaciones complejas que en las de las
secciones de marketing o de desarrollo, y las prestaciones complejas alargan desproporcionadamente el plan de desarrollo.
28: Exceso de requerimientos.

REFERENCIA
CRUZADA
Para ms informacin
sobre el cambio de
prestaciones, consulte
el Captulo 14,
Control del conjunto
de 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 (Jones, 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.

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.

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 implementacin de una utilidad bonita que han visto en otro producto, la necesite o no su producto. El esfuerzo requerido para disear, implementar,
probar, documentar o mantener estas prestaciones innecesarias alarga
el plan.

29: Cambio de las prestaciones.

30: Desarrolladores meticulosos.

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 esperado, 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.

Seymour Cray, el diseador 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 deberan 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 razonablemente predecibles; los planes en la investigacin sobre software ni
siquiera son predecibles tericamente.
Si el producto tiene objetivos que pretenden aumentar los conocimientos
32: Desarrollo orientado a la investigacin.

Captulo 3: Errores clsicos

55

existentes, como algoritmos, velocidad, utilizacin de la memoria y dems, 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.
REFERENCIA
CRUZADA
Para ms informacin
sobre el sndrome de
la panacea, consulte la
Seccin 15.5, El
sndrome de la
panacea ...

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 tcnica, una nueva tecnologa o un proceso rgido, y espera resolver con
ello sus problemas de planificacin, est inevitablemente equivocado (Jones, 1994).

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.

34: Sobreestimacin de las ventajas del empleo de nuevas herramientas o mtodos. Las organizaciones mejoran raramente su productividad a grandes saltos, sin importar cuntas nuevas herramientas o mtodos 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 lugar de grandes saltos. El equipo del Ejemplo 3.1 debera haber previsto
como mucho un 10 por 100 de ganancia en productividad por la utilizacin 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 cuando 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.

REFERENCIA
CRUZADA
Para ms informacin
sobre la reutilizacin,
consulte el Capitulo 33,
"Reutilizacin ...

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

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 cometidos con una herramienta totalmente nueva, normalmente anulan cualquier
posible beneficio.

REFERENCIA

CRUZADA
Para ms informacin
sobre el control

del cdigo fuente,

consulte Gestin de
la configuracin
del software, en la
Seccin 4.2.

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. Deberan 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 1O
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 empezado, 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-

Captulo 3: Errores clsicos

Tabla 3.1.

Resumen de los errores clsicos

Errores relacionados
con las personas

l. Motivacin dbil
2. Personal mediocre

Errores relacionados
con el proceso

Errores relacionados
con el producto

Errores relacionados
con la tecnologa

14. Planificacin

28. Exceso de

33. Sndrome de la

excesivamente
optimista

3. Empleados
problemticos
incontrolados

15. Gestin de riesgos

insuficiente

4. Hazaas

16. Fallos de los

contratados

5.

57

Aadir ms
personal a un
proyecto retrasado

17. Planificacin
insuficiente
18. Abandono de la
planificacin bajo
presin

6. Oficinas repletas
y ruidosas
7. Fricciones entre
los clientes y los
desarrolladores

19. Prdida de tiempo

en el inicio difuso

8. Expectativas poco
realistas

20. Escatimar en las

actividades
iniciales

9. Falta de un
promotor efectivo
del proyecto
10. Falta de
participacin de
los implicados

29. Cambio de las

prestaciones
30. Desarrolladores
meticulosos

31. Tiras y aflojas en

la negociacin
32. Desarrollo
orientado a la
investigacin

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

21. Diseo inadecuado

22. Escatimar en el
control de calidad
23. Control
insuficiente de la
directiva

11. Falta de
participacin del
usuario
12. Poltica antes que
desarrollo
13. Ilusiones

panacea

requerimientos

24. Convergencia
prematura o
excesivamente
frecuente
25. Omitir tareas
necesarias en la
estimacin
26. Planificar ponerse
al da ms adelante
27. Programacin a
destajo

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.