Ingeniería del proyecto: el problema del desarrollo de software (2/7): problemas comunes

Para entender el rol de la gestión de proyectos en la Informática es conveniente comenzar comprendiendo los problemas que existen en los proyectos informáticos.

Podemos decir que hay tres ‘problemas comunes’, dos de ellos habituales y, un tercero, de índole social.

A. Necesidades no satisfechas o no identificadas

En el caso de las necesidades no satisfechas o no identificadas, el error puede aparecer debido a que se omiten datos durante el desarrollo del proyecto, es por esto que es muy importante no saltar ninguna etapa del ciclo de vida del desarrollo de sistemas. Otra causa de insatisfacción de necesidades es la mala definición de las expectativas de un proyecto en sus orígenes, ya que si no están bien definidos los requerimientos máximos y mínimos que el proyecto debe satisfacer desde el comienzo, los desarrolladores verán afectado su trabajo por el “síndrome de las necesidades que crecen” el cual les dejara hacer cambios en el proyecto en cualquier momento sin detenerse a pensar si esos cambios serán buenos para el proyecto como un todo (por supuesto todos estas modificaciones acarrearan alteraciones en los costos y en los tiempos de entrega).

B. Los habituales: atrasos y costes

Uno de los rasgos característicos y síntoma de “normalidad informática” es que los proyectos informáticos se atrasan y se exceden en los presupuestos económicos.

Decir que el tiempo y dinero se duplican, triplican o cuadruplican ya no tiene sentido, es un hecho y tradición del vulgo. Esto sucede debido a que un proyecto generalmente exige un estudio de viabilidad en el cual muchas veces no se incluyen datos completamente precisos de la cantidad de recursos que cada tarea consumirá, y es en base a este estudio que se hacen estimaciones de los recursos totales que el proyecto va a necesitar. Ya se sabe que en un proyecto informático hay muchas cosas no definidas, pero si esto es sabido y repetido se puede prever. Basta con ver cómo otras profesiones han resuelto estos problemas sabiendo que existen y luego apoyándose con herramientas pero no dejando al azar el propio azar.

En cuanto al atraso, generalmente se debe a que los gestores del proyecto no son buenos gestionando los tiempos de entrega de cada una de las diferentes tareas que el proyecto involucra, es así que cuando tienen un retraso no son capaces de alterar los plazos de entrega finales creyendo que podrán recuperar el tiempo perdido con largas noches y extensos fines de semana. En general esta es una muy mala política de trabajo porque no siempre es posible acelerar otras tareas para ahorrar tiempo en la entrega final.

Por ejemplo, Glass señala que el 40% de los proyectos informáticos son cancelados por estos excesos; mientras, un 33% se enfrentan a cambios de tiempo, costes y alcance. Sin embargo, esta imagen no es propia de la informática, por ejemplo Ribera, nos muestra algunos ejemplos dignos de mención:

El proyecto del Opera House de Sidney pasó de 7 millones de dólares a 107 millones de dólares.
El proyecto de desarrollo del avión F-22 Raptor que ha superado un coste del billón de dólares.
El proyecto del túnel del Canal de la Mancha, cuyo coste inicial de 7,5 billones a llegado a los 17,5 billones de dólares, y se terminó en 1994 en lugar de 1992.

Pero no es necesario pensar en esas grandes empresas humanas, cuya complejidad puede justificar cualquier superación de estimaciones. Se puede pensar en el simple atraso en la construcción de un edificio, algo tan habitual y corriente que se nos pasa desapercibido. Lo que se quiere decir es que fuera de la Informática, los proyectos también se atrasan y cuestan más caros por motivos tan diversos y variopintos como los que se escuchan en informática. Lo que es preocupante es que dentro de la Informática estos problemas se manifiestan tanto a gran escala (como los ejemplos dados por Ribera) como a escala “casera”, viéndose afectado por tanto todo el tejido socio-económico, incluyendo aspectos como el crecimiento organizacional, los planes de empresa, o el presupuesto de una PyME. Y lo peor, se consideran «normales»(!!!!).

C. El social: la imposición de los resultados

Aparte de los comunes problemas de tiempo y coste, está en lo que podría llamarse el problema de ‘adopción por decreto’.

En muchas ocasiones los productos informáticos son impuestos por las jerarquías administrativas sin una asimilación y/o aceptación del personal o los trabajadores.

Según ciertas culturas este tema resulta conflictivo y un problema a ser resuelto. Un caso de cultura que rechaza esta situación es la escandinava, así, Iivari y Lyytinen destacan que los productos informáticos son artefactos surgidos y definidos por quienes les usarán, los trabajadores.

El problema es básicamente de los principios ligados a la historia de la ingeniería, donde ella busca ser generadora de soluciones a las necesidades de la humanidad, aportando artefactos con un valor agregado y márgenes de ganancia social siempre positivos para el ‘hombre de la calle’. Esta visión se contradice con la costumbre informática de imponer soluciones según el último avance en el área, la última tendencia o lo que sencillamente hay que tener. Al final, ocurren ajustes de trabajo de índole tayloristas que imponen aparentes mejores niveles de eficiencia, lo cual produce una confusión en los fines, por ejemplo, se confunde la búsqueda de procesos de negocios más eficientes (que muchas veces no requiere tecnología) con el aumento de velocidad computacional (se cree que con meter más maquinaria todo será mejor), y/o se confunden mejoras de la eficacia que se pueden conseguir con nuevas prácticas laborales con simples automatizaciones de prácticas de trabajo.

En una sociedad del conocimiento este tipo de actitudes no son permitidas. Imponer resultados no es positivo y más aún cuando existe una tecnología que es esencialmente socio.organizacional como las TIC, pues es necesaria la participación libre y colaborativa de todas las personas involucradas en un proceso de construcción de productos informáticos, sean tanto diseñadores de sistemas como usuarios finales.

____________________

Fuentes citadas:

GLASS, ROBERT L. (1998). Software Runaways. Lessons Learned from Massive Software Project Failures. Prentice Hall. 259 pp.
GLASS, ROBERT L. (1999). Computing calamities. Lessons learned from product, projects, and companies that failed. Prentice Hall. 302 pp.
IIVARI, JUHANI: y LYYTINEN, KALLE. (1997). Research on Information System Development in Scandinavia: Unity in Plurality. En Currie, Wendy L.; y Galliers, Bob. (1997). Rethinking Management Information Systems. Oxford. 510 pp. 57-102 pp.
RIBERA, J. L. (2000). Project Management. MBA Course IESE, Universidad de Navarra (Spring 2000).

____________________________________

Este post se relaciona con otros más, todos vinculados al tema de estudiar y comprender el problema del desarrollo de software desde una fuerte óptica de la gestión de proyectos.