Los problemas y errores comunes en el desarrollo de 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 hechofá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 lolargo 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.
2: Personal mediocre. Después de la motivación, la capacidadindividual 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 supondrá una amenaza al desarrollo. Ejemplo, hacer la selección del personal buscando quién puede contratarse más rápido, en vez de quién realizará la mayoría del trabajo durante la vida delproyecto. Esta técnica consigue un inicio rápido del proyecto, pero no determina un final rápido.
3: Empleados problemáticos incontrolados. Un fallo al tratar con personal problemático también amenaza la velocidad de desarrollo. Un fallo al tomar una decisión cuando se trata con un empleado problemático es una de las quejas más comunes que tienen los miembros del equipo respecto de susresponsabilidades (Larson y La fasto, 1989). Ejemplo, el equipo sabe que uno de ellos es una manzana podrida, pero el jefe del equipo no hace nada. El resultado es predecible: rehacer el trabajo de la manzana podrida.
4: Hazañas. Algunos desarrolladores de software ponen un gran énfasis en la realización de hazañas en los proyectos (Bach, 1995). Pero lo que hacen tiene más de malo que de bueno. Ejemplo,los directivos de nivel medio dan 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 es un modelo de planificación al límite en el que las amenazas de desajuste del plan no se detectan, no se conocen o ni se informan a la cadena de directivos hasta el último minuto. Un pequeño equipo de desarrolloy sus jefes inmediatos toman como rehenes a una compañía entera por no admitir que tiene problemas para cumplir su plan. El énfasis en los comportamientos heroicos fomenta correr un riesgo extremo, e impide la cooperación entre los múltiples elementos que contribuyen al proceso de desarrollo del software.
Algunos directivos fomentan el comportamiento heroico cuando se concentran condemasiada firmeza en actitudes del tipo “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 daño ya está hecho. Como dijo Tom DeMarco, las actitudes convierten pequeños contratiempos enauténticos desastres (DeMarco, 1995).
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)….
