Ingeniera del proyecto: el problema del desarrollo de software (2/7): problemas comunes

Para entender el rol de la gestin de proyectos en la Informtica es conveniente comenzar comprendiendo los problemas que existen en los proyectos informticos. 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 insatisfaccin de necesidades es la mala definicin de las expectativas de un proyecto en sus orgenes, ya que si no estn bien definidos los requerimientos mximos y mnimos que el proyecto debe satisfacer desde el comienzo, los desarrolladores vern afectado su trabajo por el sndrome de las necesidades que crecen el cual les dejara hacer cambios en el proyecto en cualquier momento sin detenerse a pensar si esos cambios sern 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 caractersticos y sntoma de normalidad informtica es que los proyectos informticos se atrasan y se exceden en los presupuestos econmicos. Decir que el tiempo y dinero se duplican, triplican o cuadruplican ya no tiene sentido, es un hecho y tradicin 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 informtico hay muchas cosas no definidas, pero si esto es sabido y repetido se puede prever. Basta con ver cmo otras profesiones han resuelto estos problemas sabiendo que existen y luego apoyndose 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 podrn recuperar el tiempo perdido con largas noches y extensos fines de semana. En general esta es una muy mala poltica de trabajo porque no siempre es posible acelerar otras tareas para ahorrar tiempo en la entrega final. Por ejemplo, Glass seala que el 40% de los proyectos informticos 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 informtica, por ejemplo Ribera, nos muestra algunos ejemplos dignos de mencin:

El proyecto del Opera House de Sidney pas de 7 millones de dlares a 107 millones de dlares. El proyecto de desarrollo del avin F-22 Raptor que ha superado un coste del billn de dlares. El proyecto del tnel del Canal de la Mancha, cuyo coste inicial de 7,5 billones a llegado a los 17,5 billones de dlares, y se termin en 1994 en lugar de 1992.

Pero no es necesario pensar en esas grandes empresas humanas, cuya complejidad puede justificar cualquier superacin de estimaciones. Se puede pensar en el simple atraso en la construccin de un edificio, algo tan habitual y corriente que se nos pasa desapercibido. Lo que se quiere decir es que fuera de la Informtica, los proyectos tambin se atrasan y cuestan ms caros por motivos tan diversos y variopintos como los que se escuchan en informtica. Lo que es preocupante es que dentro de la Informtica estos problemas se manifiestan tanto a gran escala (como los ejemplos dados por Ribera) como a escala casera, vindose afectado por tanto todo el tejido socio-econmico, 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 imposicin de los resultados Aparte de los comunes problemas de tiempo y coste, est en lo que podra llamarse el problema de adopcin por decreto. En muchas ocasiones los productos informticos son impuestos por las jerarquas administrativas sin una asimilacin y/o aceptacin del personal o los trabajadores. Segn ciertas culturas este tema resulta conflictivo y un problema a ser resuelto. Un caso de cultura que rechaza esta situacin es la escandinava, as, Iivari y Lyytinen destacan que los productos informticos son artefactos surgidos y definidos por quienes les usarn, los trabajadores. El problema es bsicamente de los principios ligados a la historia de la ingeniera, donde ella busca ser generadora de soluciones a las necesidades de la humanidad, aportando artefactos con un valor agregado y mrgenes de ganancia social siempre positivos para el hombre de la calle. Esta visin se contradice con la costumbre informtica de imponer soluciones segn 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 confusin en los fines, por ejemplo, se confunde la bsqueda de procesos de negocios ms eficientes (que muchas veces no requiere tecnologa) con el aumento de velocidad computacional (se cree que con meter ms maquinaria todo ser mejor), y/o se confunden mejoras de la eficacia que se pueden conseguir con nuevas prcticas laborales con simples automatizaciones de prcticas de trabajo. En una sociedad del conocimiento este tipo de actitudes no son permitidas. Imponer resultados no es positivo y ms an cuando existe una tecnologa que es esencialmente socio.organizacional como las TIC, pues es necesaria la participacin libre y colaborativa de

todas las personas involucradas en un proceso de construccin de productos informticos, sean tanto diseadores 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 ms, todos vinculados al tema de estudiar y comprender el problema del desarrollo de software desde una fuerte ptica de la gestin de proyectos.

0.- Hacia una ingeniera de software bajo la ptica de la gestin de proyectos. 1.- Identificar la naturaleza intrnseca del objeto de estudio (el software y su produccin/evolucin). 2.- Identificar los problemas ms comunes en la produccin de software. 3.- Comprender las consecuencias de no resolver los problemas. 4.- Identificar las causas de los problemas comunes. 5.- Establecer mecanismos para evitar los problemas a nivel de gestin. 6.- Reconocer los estados que caracterizaran una mala gestin de un proyecto. 7.- Establecer la finalidad o razn de ser de una gestin de proyectos en el mbito de la produccin de software.