Los Problemas y Errores Comunes Proyectos Cos
Los Problemas y Errores Comunes Proyectos Cos
Los Problemas y Errores Comunes Proyectos Cos
proyectos informáticos.
Los desarrolladores, directivos y clientes normalmente tienen buenas razones para tomar las
decisiones que toman, y la apariencia seductora de los errores clásicos 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 fáciles de predecir. Y los errores rara vez
producen los resultados que la gente espera.
1. Personas
A continuación aparecen algunos de los errores clásicos relacionados con las personas.
1: Motivación débil. Estudio tras estudio ha mostrado que la motivación probablemente tiene
mayor efecto sobre la productividad y la calidad que ningún otro factor (Boehm 1981). Ejemplo:
directivos que a lo largo de todo el proyecto toman medidas que minan la moral: como dar
ánimos a diario al principio para pedir horas extras en la mitad, y como irse de vacaciones
mientras el equipo esta trabajando incluso los días de fiesta, para dar recompensas al final del
proyecto que resultan ser de menos de un dólar por cada hora extra.
5: Añadir más personal a un proyecto retrasado. Este es quizás el más clásico de los errores
clásicos. Cuando un proyecto se alarga, añadir más gente puede quitar más productividad a los
miembros del equipo existente de la que añaden los nuevos miembros. Fred Brooks compara
añadir gente a un proyecto retrasado con echar gasolina en un fuego (Brooks, 1975).
7: Fricciones entre los clientes y los desarrolladores. Las fricciones entre los clientes y los
desarrolladores pueden presentarse de distintas formas. A los clientes pueden parecerles que
los desarrolladores no cooperan cuando rehusan comprometerse con el plan de desarrollo que
desean los clientes o cuando fallan al entregar lo prometido. A los desarrolladores puede
parecerles que los clientes no son razonables porque insisten en planes irreales o cambios en
los requerimientos después de que éstos hayan sido fijados. Pueden ser simplemente conflictos
de personalidad entre dos grupos.
El principal efecto de esta fricción es la mala comunicación, y los efectos secundarios de la mala
comunicación incluyen el pobre entendimiento de los requerimientos, pobre diseño 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 cancelación 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.
8: Expectativas pocos realistas. Una de las causas más comunes de fricciones entre los
desarrolladores y sus clientes o los directivos son las expectativas poco realistas. Ejemplo, no
tener razones técnicas para pensar que un software se podrá desarrollar en 6 meses, pero ése
es el plazo en que lo quiere el comité ejecutivo de la compañía. La incapacidad del jefe de
proyecto para corregir esta expectativa irreal será la principal fuente de problemas.
En otros casos, los directivos o los desarrolladores de un proyecto se buscan problemas al pedir
fondos basándose en estimaciones de planificación demasiado optimistas. Aunque por sí
mismas las expectativas irreales no alargan el plan, contribuyen a la percepción de que el plan
de desarrollo es demasiado largo, y de que puede ser malo. Una inspección 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 gestión (Standish Group, 1994).
9: Falta de un promotor efectivo del proyecto. Para soportar muchos de los aspectos del
desarrollo rápido es necesario un promotor del proyecto de alto nivel, incluyendo una
planificación realista, el control de cambios y la introducción de nuevos métodos de desarrollo.
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 Thomstt afirma que la falta de un promotor efectivo garantiza
virtualmente el fracaso del proyecto (Thomstt, 1995).
10: Falta de participación 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 cooperación estrecha sólo se
produce si se han implicado todos los participantes, permitiendo una coordinación precisa del
esfuerzo para el desarrollo rápido, que es imposible conseguir sin una buena participación.
11: Falta de participación del usuario. La inspección de Standish Group descubrió que la
razón número uno de que los proyectos de Sistemas de Información tuviesen éxito es la
implicación 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 más tarde retrasarán el proyecto.
12: Política antes que desarrollo. Larry Constantine indicó que si hay cuatro tipos diferentes
de orientaciones políticas (Constantine, 1995a). Los "políticos" están especializados en la
"gestión", centrándose en las relaciones con sus directivos. Los "investigadores" se centran en
explorar y reunir la información. Los "aislacionistas" están 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 políticos y generalistas están bien vistos por los
directivos de alto nivel. Pero después de un año y medio, los equipos políticos llegan a la muerte
súbita. Primar la política en vez de los resultados es fatal para el desarrollo orientado a la
velocidad.
13: Ilusiones. Muchos problemas del desarrollo del software se deben a la ilusión. Cuántas
veces hemos escuchado cosas como éstas a distintas personas:
"Ninguno de los miembros del proyecto cree realmente que pueda completarse el proyecto de
acuerdo con el plan que tienen, pero piensan que quizás si trabajan duro, y nada va mal, y
tienen un poco de suerte, serán capaces de concluir con éxito".
"Nuestro equipo no hace mucho trabajo para la coordinación de las interfaces entre las distintas
partes del producto, pero tenemos una buena comunicación para otras cosas, y las interfaces
son relativamente simples, así que probablemente sólo necesitaremos un día 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 difícil ver cómo va a acabar el trabajo con los niveles de personal que
ha especificado en su propuesta. No tienen tanta experiencia como algunos de los demás
desarrolladores externos, pero puede que compensen con energía 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 días, pero creo que alcanzarán éste a
tiempo."
Las ilusiones no son sólo 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
planificación coherente y pueden ser la raíz de más problemas en el software que todas las
otras causas combinadas.
2. Proceso
Los errores relacionados con el proceso malgastan el talento y el esfuerzo del personal. A
continuación se muestran algunos de los peores errores relacionados con el proceso.
14: Planificación excesivamente optimista. Los retos a los que se enfrenta alguien que
desarrolla una aplicación en tres meses son muy diferentes de aquellos a los que se enfrenta
alguien que desarrolla una aplicación que necesita un año. Fijar un plan excesivamente
optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto, minando la
planificación efectiva, y reduciendo las actividades críticas para el desarrollo, como el análisis de
requerimientos o el diseño. También supone una excesiva presión para los desarrolladores,
quienes a largo plazo se ven afectados en su moral y su productividad.
16: Fallos de los contratistas. Las compañías a veces contratan la realización de partes de un
proyecto cuando tienen demasiada prisa para hacer el trabajo en casa. Pero los contratados
frecuentemente entregan su trabajo tarde, con una calidad inaceptable o que falla al no coincidir
con las especificaciones (Boehm, 1989). Riesgos como requerimientos inestables o interfaces
mal definidas pueden ser enormes cuando un contratado entre en escena. Si las relaciones con
los contratados no se gestionan cuidadosamente, la utilización de desarrolladores externos
pueden retardar el proyecto en vez de acelerarlo.
18: Abandono de planificación bajo presión. Los equipos de desarrollo hacen planes y
rutinariamente los abandonan cuando se tropiezan con un problema en la planificación
(Humphrey, 1989). El problema no está en el abandono del plan, sino más bien en fallar al no
crear un plan alternativo, y caer entonces en el modo de trabajo de codificar y corregir. Ejemplo,
un equipo abandona su plan después de fallar en la primera entrega, y esto es lo habitual. A
partir de este punto, el trabajo no tiene coordinación ni elegancia.
19: Pérdida 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 común que un proyecto desperdicie meses o años en un
inicio difuso, y entonces se está a las puertas de un plan agresivo. Es mucho más fácil 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 se aceleran intentando acortar las
actividades "no esenciales", y puesto que el análisis de requerimientos, la arquitectura y el
diseño no producen código directamente, son los candidatos fáciles.
Los resultados de este error, también conocido como "saltar a la codificación", son todos
demasiado predecibles. Los proyectos que normalmente escatiman en sus actividades iniciales
tendrán que hacer ese trabajo en otro momento, con un costo de 10 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, ¿cómo vamos a
encontrar 50 para hacerlo correctamente más tarde?
21: Diseño inadecuado. Un caso especial de escatimar en las actividades iniciales es el diseño
inadecuado. Proyectos acelerados generan un diseño indeterminado, no asignado suficiente
tiempo para él y originado un entorno de alta presión que hace difícil la posibilidad de considerar
alternativas en el diseño. El énfasis en el diseño está más orientado a la conveniencia que a la
calidad, por lo que necesitará varios ciclos de diseño de poder finalizar completamente el
sistema.
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 diseño y del código, eliminando la planificación
de las pruebas y realizando sólo pruebas superficiales. Acortar en un día las actividades de
control de calidad al comienzo del proyecto probablemente supondrá de 3 a 10 días de
actividades finales (Jones, 1994).
23: Control insuficiente de la directiva. Poco control de la directiva para detectar a tiempo los
signos de posibles retrasos en el plan, y los pocos controles definidos al comienzo se
abandonan cuando el proyecto comienza a tener problemas. Antes de encarrilar un proyecto, en
primer lugar debemos ser capaces de decir si va por buen camino.
Otro tipo de error es la reestimación que se debe a cambios en el producto. Si el producto que
estamos construyendo cambia, la cantidad de tiempo necesaria para construirlo cambiará
también. El crecimiento de las nuevas prestaciones sin ajustar el plan garantiza que no se
alcanzará la fecha de entrega.
27: Programación a destajo. Algunas organizaciones creen que la codificación rápida, libre, tal
como salga, es el camino hacia el desarrollo rápido. Piensan que si los desarrolladores están lo
suficientemente motivados, pueden solventar cualquier obstáculo. Este enfoque muchas veces
se presenta como un enfoque "empresarial" al desarrollo de software, pero realmente es sólo la
envoltura del viejo paradigma a destajo combinado con una planificación ambiciosa, y esta
combinación raras veces funciona. Es un ejemplo de que dos negaciones no constituyen una
verdad.
3. Producto
A continuación se muestran los errores clásicos relacionados con la forma en la que se define el
producto.
28: Exceso de requerimientos. Algunos proyectos tienen más requerimientos de los que
necesitan, desde el mismo inicio. La eficiencia se fija como requisito más a menudo de lo que es
necesario, y puede generar una planificación 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.
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 (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.
Si el producto tiene objetivos que pretenden aumentar los conocimientos existentes, como
algoritmos, velocidad, utilización de la memoria y demás, debemos asumir que la planificación
es altamente especulativa. Si queremos mejorar el estado del arte y tenemos algún otro punto
débil en el proyecto, recortes de personal, debilidades en el personal, requerimientos vagos,
interfaces inestables con contratados externos, etc., podemos tirar por la ventana la
planificación prevista. Si queremos superar el estado del arte por todos los medios, hagámoslo.
¡Pero no debemos esperar hacerlo rápidamente!
4. Tecnología
El resto de los errores clásicos están relacionados con el uso correcto o incorrecto de la
tecnología moderna.
34: Sobreestimación de las ventajas del empleo de nuevas herramientas o métodos. Las
organizaciones mejoran raramente su productividad a grandes saltos, sin importar cuántas
nuevas herramientas o métodos empleen o lo bueno que sean. Los beneficios de las nuevas
técnicas son parcialmente desplazados por las curvas de aprendizaje que llevan asociadas, y
aprender a utilizar nuevas técnicas para aprovecharlas al máximo lleva su tiempo. Las nuevas
técnicas también suponen nuevos riesgos, que sólo descubriremos usándolas. Más bien
experimentaremos mejoras lentas y continuas en un pequeño porcentaje por proyecto en lugar
de grandes saltos.
35: Cambiar de herramientas a mitad del proyecto. Es un viejo recurso que funciona
raramente. A veces puede tener sentido actualizar incrementalmente dentro de la misma línea
de productos, de la versión 3 a la 3.1, o incluso a la 4. Pero cuando estamos a la mitad de un
proyecto, la curva de aprendizaje, rehacer el trabajo y los inevitables errores cometidos con una
herramienta totalmente nueva, normalmente anulan cualquier posible beneficio.
36: Falta de control automático del código fuente. Un fallo en la utilización del control
automático del código fuente expone a los proyectos a riesgos innecesarios. Sin él, si dos
desarrolladores están trabajando en la misma parte del programa, deben coordinar su trabajo
manualmente. Deberían ponerse de acuerdo para poner la última versión de cada archivo en el
directorio maestro y verificarlos con los demás antes de copiarlas en este directorio. Pero
invariablemente alguno sobreescribirá el trabajo del otro. Se desarrolla nuevo código con
interfaces desfasadas, y después se tiene que rediseñar el código al descubrir que se ha
utilizado una versión 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 manual del código fuente no deberían crecer (Jones, 1994).