El Fracaso de los Proyectos de Software

SITUACIÓN ACTUAL
En el año 2006, John Avellanet utilizó un estudio realizado por Accenture para establecer los puntos necesarios que se requieren para alcanzar el éxito de un proyecto. Los datos sobre el entorno en el desarrollo de proyectos de TI era desalentador, desafortunadamente del 2006 a la fecha, las cosas no han cambiado en mucho.

• Solo el 27% de los proyectos de TI puede ser considerado un éxito. 
• Los proyectos de TI sobrepasan su costo en un 56%. 
• Se estima que los proyectos sobrepasan su calendario en un 84%. 
• El 31.1% de los proyectos son cancelados antes de que sean terminados. 

Lo anterior son números rojos alarmantes, que sin embargo, no son nada nuevos , estos números han existido desde un inicio.

CAUSAS DE TAN DESALENTADOR PANORAMA
Las causas son diversas. El Dr. Daniel Tapia, Profesor Investigador del Centro de Investigación en Tecnologías de la Información (CITIS) de la Universidad Autónoma del Estado de Hidalgo, atribuye el fracaso de un proyecto de TI a las siguientes razones;

• Se daba mayor atención a las cuestiones operativas que a la planificación. 
• Planeación deficiente. 
• Los objetivos del proyecto no estaban alineados con los objetivos de la organización. 
• El entorno global hace que la planeación tradicional ya no sea suficiente. 
• Una mera planificación de actividades y recursos no sirve de nada. 
• Se requiere una gestión estratégica. 

Existen puntos interesantes en las presentaciones del Dr. Tapia que recomiendo leer (ver al final de este artículo), aunque en algunas cuestiones, no concuerdo del todo, como por ejemplo donde hace mención que se requieren procesos bien definidos y una documentación extensa. Fuera de esto, el Dr. Tapia concluye que un simple enfoque de Ing. de Software ya no es suficiente, lo cuál es extremadamente cierto, sin embargo, en este artículo nos enfocaremos en dicho aspecto.
A los puntos anteriores, voy a agregar uno que seguramente puede ser causa de polémica por ser tan directo y acusador.

Durante muchos años, el sector académico ha tenido erróneamente mucha injerencia en el desarrollo de software cuando su papel no es precisamente ser el protagonista en este ámbito. Las universidades estan más interesadas en crear pequeñas fábricas de software, que en preparar de forma adecuada a los alumnos. Las empresas por su parte, se están enfocando en capacitar en cuestiones básicas a los alumnos que egresan en lugar de desarrollar software, es decir, los papeles se estan invirtiendo!! Las universidades están desarrollando software y las empresas están capacitando!!.

Hace poco más de un año, escuche al Director General de QuarkSoft, Cesar Montes de Oca, decir todo lo anterior! Ellos como empresa tenían que capacitar a los recién egresados sobre temas tan sencillos como realizar una simple conexión a base de datos con Java! Sin duda que algo muy pero muy grave esta fallando con las Universidades, pero bueno, afortunada o desafortunadamente no es tema de análisis en este estudio.

Grandes universidades que sin duda han hecho grandes aportes a la Ing. del Software, como por ejemplo la University Carnegie Mellon (en conjunto con el SEI), han desarrollado varios de los modelos y procesos para el desarrollo de Software como por ejemplo (CMM/CMMI, PSP/TSP., etc., “Avances” mismos que al día de hoy han demostrado ser ineficientes para la mayoría de los casos reales. Aquí en México por ejemplo, se ha creado MoProSoft como un modelo de desarrollo de software para las empresas mexicanas, modelo que ha sido lidereado por la Dra. Hanna Oktaba, académico del IMAS en la UNAM.

Es importante hacer un pequeño paréntesis y aclarar todo lo anterior para no crear malos entendidos. El sector académico ha hecho no solamente grandes aportes, más bien ha hecho todos los aportes de la actualidad en cuanto a las Ciencias Computacionales [Ver Ing de Software de Ian Somerville para una diferencia entre las Ciencias Computacionales y la Ing de Software]. Debemos agradecer a nuestros maestros de la universidad por enseñarnos aquellas estructuras de datos, por hacernos entender el algoritmo de Dijkstra, por explicarnos la notación O, por aquellos difíciles proyectos en lenguaje ensamblador y por aquellas Series de Fourier, etc., sin embargo, han olvidado que mucho de su trabajo es eminentemente teórico que puede demostrarse y realizarse en laboratorios, pero un proyeto de desarrollo de software no puede ser simulado y demostrado fácilmente.

¿Cuál es el problema de las Metodologías actuales?

Ha sido un error tomar casi al pie de la letra la filosofía de otras ingenierías y aplicarlas al desarrollo de software. En la ingeniería civil por ejemplo, los problemas importantes son suceptibles de un análisis matemático que determina por ejemplo, la fuerza a aplicar a ciertos elementos, la resistencia de los materiales, etc. En pocas palabras, los métodos que se utilizan en otras ingenierías son “predictivos” [entiéndase por predictivo que es posible "predecir" el comportamiento de un Sistema bajo ciertas condiciones]y funcionan muy bien en ese ámbito. Sin embargo, en el mundo del desarrollo de software comercial, ¿Como es posible predecir un cambio de requerimientos? ¿Es posible predecir la duración de un proyecto?… Muchas personas podrían argumentar que si es posible predecir lo anterior, quizá sí, pero no bajo modelos matemáticos como en otras ingenierías y por ende esta filosofía debería desecharse.

Lamentablemente, esta predicibilidad es muy usada en procesos tales como el PSP [Ver Personal Software Process del Dr. Watts Humprhey] , en donde debes ir haciendo todo un registro de tus tiempos, de tus distracciones, e ir sacando promedios de cada actividad a la que te dedicas para que de esta forma, en actividades similares posteriores, puedas predecir el tiempo que llevaras en construir cierto componente de software, aunado a esto, toda una serie de procesos formales intentan mejorar tu productividad y calidad en tus desarrollos. Los principios del PSP pueden ser aun muy discutidos, yo mismo me encuentro aún valorando sus bondades en ciertos tipos de proyectos.

Las metodologías tradicionales, al ser meramente predictivas, dicen que debemos hacer una toma completa y detallada de requerimientos al iniciar un proyecto, posteriormente asentar en documentos y diagramas UML la arquitectura del sistema a utilizar, después comenzar la construcción del sistema y finalmente una etapa de pruebas. Nótese la gran similitud con la ingeniería civil, en donde primero se diseña y después se construye!

Cuando se trabaja con metodologías tradicionales, existe una resistencia nativa al cambio. Las personas que trabajan en el proyecto se resisten a cualquier cambio de requerimientos, cosa contraria a lo que pasa con los métodos ágiles, en donde se piensa que los cambios son bienvenidos, se trata sencillamente de convivir con ellos y transformar una debilidad en una fortaleza.
La toma de requerimientos tradicional, indica hacer una detallada documentación y casos de uso donde se plasmen los requerimientos. Hoy en día ya sabemos que un desarrollo iterativo es mejor, en donde al inicio del proyecto se de solo un panorama general de todo lo que el usuario quiere y en cada iteración se desglosen un poco más los requerimientos.

El diseño de una arquitectura antes de la codificación es otro problema fundamental! Teóricamente lo anterior suena bien e incluso lógico, pues a final de cuentas, esto mismo se hace en otras ingenierías! Pero la práctica nos ha demostrado que el definir una arquitectura anterior a la codificación resulta muy problemática a la hora de codificar. La filosofía agile, nos indica que la mejor arquitectura que podemos definir en un inicio son cuestiones generales como la plataforma de programación, la BD y los frameworks que utilizaremos, pero la arquitectura detallada, ira fluyendo durante la codificación!

La etapa de pruebas es un asunto discutido. Por un lado, los tradicionalistas opinan que debe haber un equipo aparte del equipo de desarrollo que se encargue de probar el sistema, además de esto, nos indica que la etapa de pruebas se realiza al final de la etapa de codificación! En el lado ágil, tenemos que no existe un equipo aparte del equipo de desarrollo, los desarrolladores son y deben ser los mejores testers, además de esto, la práctica de TDD, nos dice que primero debemos crear la prueba unitaria antes de crear el módulo! Es decir, debemos crear primero una prueba unitaria para algo que aun no existe!! Esto es raro al inicio, pero aporta muchas ventajas!

El error de las personas que practican metodologías tradicionales
Son muchos los errores que siguen los project manager tradicionales. Desde el hecho de que las empresas gastan o se desviven en piratear licencias de sofisticados programas para elaborar diagramas de Gantt y hacer un detallado calendario de todo el proyecto con fechas de entrega, personas que realizarán cada una de las tareas y/o módulos existentes, plan de trabajo que desarrollo una noche antes el departamento de ventas para poder vender un proyecto de miles de pesos etc., hasta el hecho de designar un equipo especializado en “pruebas de software” que sea diferente al del equipo de desarrollo que realizará las pruebas al software en base a un detallado análisis en casos de uso de 100 páginas.

Otro error que cometen frecuentemente los administradores de proyectos es,

Yo Administrador de Proyectos, soy el único que puede dialogar con el cliente! Tu programador, tienes prohibido hablar con el cliente de cosas relacionadas con el proyecto, cualquier duda que tengas en los requerimientos debes dirigirte a mi, cualquier duda que tenga el cliente en la estimación de tiempo debes indicarle que se dirija conmigo.

Acaso al construir una casa, el maestro de obra habla con nuestros papás en lugar de hablar directamente con nosotros que somos los clientes??

Algo más irónico es por ejemplo, cuando una vez que el departamento de ventas diseñó nuestro plan de trabajo y decidió que nos llevaríamos 2 días en construir la interfaz que comunicaría nuestro módulo de consultas de proveedores externos con la tabla que existe en DBASE y que la transmición de datos se haría mediante un certificado digital de seguridad web SSL, además claro esta, de tener la opción de enviar un correo electrónico a los directivos cuando el monto de las facturas exceda el monto planeado que se tiene en SAP. Una vez que en la primer reunión que tuvo el depto de ventas con el cliente y entrego dicho plan de trabajo, el cliente quedo asombrado ante la rapidez de desarrollo y le dijo al departamento de ventas que entonces comenzaran ese mismo día con el proyecto! Entonces el departamento de ventas, corre inmediatamente a darle la excelente noticia al equipo de desarrollo que tiene 2 días para mostrar un primer entregable, que de el plan de trabajo y las estimaciones de tiempo, que ya ni se preocupen, que ellos muy amablemente ya lo hicieron por nosotros!

Lo anterior, obviamente es una descripción subjetiva que no esta muy alejado de la realidad. Por un lado, tenemos a muchosStakeholder como el cliente, el depto de ventas, gerencia, etc., que piensa que hacer software es como manufacturar algo o hacer enchiladas, que en cuestión de horas estará listo para funcionar!!

Por otro lado, tenemos a métodos formales que nos exigen hacer una detallada toma de requerimientos en extensos casos de uso y más importante aún, estar persiguiendo al cliente para que firme dichos requerimientos y así “asegurar” que estos no cambien en un futuro y si cambian entonces tenemos a un “cliente que no sabe lo que quiere” y nos negaremos a realizar el cambio y si lo realizamos, será con un costo adicional sobre lo planeado. Por si esto fuera poco, se nos ha enseñado que antes de iniciar la etapa de codificación, debemos elaborar una detallada arquitectura del sistema y plasmarla en muchos diagramas UML y documentos que puedan servir como referencia “más adelante”.

Esta idea de una Arquitectura detallada y modelado UML, funciona bien en la Ingeniería Civil, pero no en el desarrollo de software… Incluso, el hecho de que muchos catedráticos piensen que el UML es la octava maravilla del mundo, es debido a que los diseños en papel o en una herramienta UML son consistentes y se ven bien! De la misma forma en el mundo real y productivo, los diseños UML en un principio parecen ser correctos y el modelo parece ser lo suficientemente bueno para generar una buena arquitectura, pero los problemas surgen a la hora de la codificación, y es cuando vemos que los diagramas UML solo nos han servido para perder el tiempo!! Cuando lo anterior pasa, es entonces que vociferamos a todo mundo que el cliente tiene la culpa por no saber lo que quiere, que nuestro analista no “predijo” como si lo hubiera hecho Walter Mercado lo que el cliente iba a querer más adelante y que nuestro arquitecto de software no supo diseñar una arquitectura escalable y preparada para el cambio!! Y es que aún si suponemos un modelo exitoso con UML, el constante cambio de requerimientos hará que sucedan dos cosas posibles:

• Se actualiza toda la documentación existente y además se procede con dicho cambio a nivel de codificación. Al actualizar los cientos de documentos existentes y dejarlos actualizados y acorde a los nuevos requerimientos, hemos perdido tiempo valioso en aquello que realmente aporta un valor o ventaja competitiva a nuestro cliente! Por lo tanto, ya tenemos un retraso de más de un 50% y no entregaremos a tiempo la funcionalidad o si la entregamos, estará llena de errores por la premura del tiempo. 
• Dejamos de lado la documentación y nos enfocamos a lo que realmente aporta un valor al cliente! Desafortunadamente, a mitad del proyecto, este enfoque resulta triste, ya que hemos perdido la mitad de tiempo en elaborar documentación que, conforme el proyecto fue avanzando y evolucionando ha quedado obsoleta y ya no sirve de “base” para el mantenimiento del sistema, pues lo que comenzó como un simple sistema de facturación, terminó acercándose más a lo que es un ERP. Finalmente, la documentación pasa a ser un bonito recuerdo! 

No faltara quien a estas alturas pueda argumentar algo a favor del modelado detallado en UML y pueda decir:

“Uhmm, pero un diagrama de clases o de componentes, nos da una visión general de la estructura del sistema y esto es muy útil para saber como interactuan los componentes del sistema, así que es necesario realizar estos diagramas. Además los diagramas de despliegue por ejemplo son muy útiles cuando tratas con un cliente técnico.”

Lo anterior, es una idea desesperada por encontrarle un sentido a la existencia del modelado excesivo en UML. Bastaría hacer un refactoring a nuestro código fuente para obtener un diagrama siempre actualizado de clases o de componentes del sistema! Y todo en cuestión de minutos!!… ¿Para que perder el tiempo diseñando y planeando algo de naturaleza intangible que con el tiempo irá cambiando y evolucionando? Ahora bien, no todo en el UML es malo, los diagramas de despliegue por ejemplo son útiles, los diagramas de actividades son una versión más bonita de los diagramas de flujo, en un momento dado podrían ser útiles 2 o 3 diagramas de secuencia, etc. El punto aquí es el “exceso” que se comete con UML.
Aunado a lo anterior, todavía podemos decir mucho más….

1. Los líderes y clientes, piensan que el hacer software es tan sencillo y rápido como introducir una fórmula en excel, por esto mismo, obligan a los desarrolladores a trabajar jornadas mayores a las 8 horas! 
2. Los líderes de proyecto no están dispuestos a perder su autoridad! Es común que en los equipos, siempre exista una autoridad que tome todas las decisiones [programadores extrella, líderes absolutos]. Cuando un desarrollador sugiere o habla algo con el cliente, el líder siente perder autoridad, reacciona y entonces prohíbe una comunicación con el cliente! 
3. Los equipos de trabajo siempre están a la espera de recibir órdenes, a que se les asigne una tarea, muchas veces a que se les diga como hacerla, etc. Mientras en la forma tradicional perdemos el tiempo esperando recibir ordenes, en las metodologías ágiles se fomenta a equipos auto-dirigidos! 

¿Es importante estar certificado en una norma ISO, CMM/CMMI/, MoProSoft, etc?
Muchas empresas no ven lo anterior como una posibilidad para realizar un cambio y mejora en sus procesos, en vez de eso, lo ven como algo superficial del cual pueden alzar el cuello y presumir ante sus clientes que tienen una certificación ISO xxxx-xxxx y que entonces son la mejor opción ya que sus competidores hacen software basura y ellos al tener una ISO, hacen desarrollos de calidad!

Yo mismo he vivido lo anterior. En mi primer trabajo profesional que tuve en el desarrollo de software, yo aún era estudiante y me toco vivir como la empresa para la que trabajaba, se preocupaba más por dar a conocer a los clientes que se contaba con la certificación MoProSoft nivel 1, cuando internamente no se conocía muy bien la forma de aplicar efectivamente dicho modelo.

El presidente de la empresa, siempre aseguraba que no podíamos presumir nuestras miserias al cliente! Ciertamente algo muy cierto, el problema era que nunca se preocupo por hacer un verdadero cambio de fondo. Pero bueno, el asunto original es si realmente es importante estar certificado en alguna de las anteriores normas y procesos formales para tener éxito en el desarrollo de software! Me permito citar nuevamente al Dr. Tapia:

No existe interés por métodos formales de aseguramiento de la calidad del software. Las empresas mexicanas están más preocupadas por conseguir la certificación de sus procesos con un distintivo de calidad, aunque dicha certificación no garantice la satisfacción de sus clientes.

Finalmente…
Para terminar esta primera parte del artículo “El fracaso en los proyectos de Software”, debemos sacar las concluciones más relevantes.

• Los métodos tradicionales, siguen un enfoque utilizado en otras ingenierías como la Ingeniería Civil y Mecánica, en donde, sus problemas son susceptibles a un análisis matemático que determinará el comportamiento de un sistema bajo ciertas condiciones. En el desarrollo de software, no es posible determinar con exactitud el comportamiento de los sistemas de software. 
• Los métodos tradicionales y las personas que trabajan con ellos, siguen un riguroso esquema, en donde se aleja mucho al equipo de desarrollo y al cliente. El desarrollo ágil fomenta la comunicación desarrollador/cliente e invita al cliente a ser parte del equipo, mientras que los tradicionalistas sostienen que el líder de proyecto debe ser el responsable de hablar con el cliente. 
• Cuando los proyectos fracasan, se cree que todavía debe agregarse una capa más detallada de procesos aún más formales y definidos, de planes aún más detallados, de más documentación, de más juntas de 3 horas, de una mayor vigilancia al equipo de desarrollo y de más horas de trabajo, cuando en realidad los principios deben ser muy sencillos. [ver el artículo de Emilio Osorio] 
• Las empresas se preocupan más por tapar hoyos superficiales, por presentar un mundo de caramelo en sus desarrollos con el cliente y de obtener certificaciones aunque no entiendan como aplicarlas. 
• En muchas empresas, la gerencia toma decisiones que no le corresponden y debe dejarlas a los verdaderos expertos. Muchas veces son estos niveles los que fijan el costo de un proyecto de software y la duración del mismo. Cuando menos lo esperamos, ya nos entregan un plan de desarrollo con fechas ya establecidas!. 
• Durante más de 10 años, los métodos formales no han dado tantos resultados positivos. Lo preocupante de esto, es que al no dar los resultados esperados, día a día se piensa en agregar más formalidad y rigidez a su proceso. Los métodos ágiles tampoco son la solución a todos los problemas, pero si dan unas buenas pautas para reformular las actuales ideas de la Ingeniería de Software. 

En la segunda parte de este artículo, comenzaremos a ver a la filosofía de los métodos ágiles y veremos en ellos una mejor herramienta para tratar de resolver los problemas actuales en la administración y desarrollo de software.

Visita el blog próximamente para leer la segunda parte que será mucho más interesante! No olvides vertir tus comentarios que serán muy útiles para enriquecer este artículo! Tanto si eres un estudiante con o sin experiencia, un académico dando o no dando clases de Ing de Software, o un profesionista desarrollador o líder de proyecto! Todos los comentarios, buenos o malos, pero constructivos, son bienvenidos!

REFERENCIAS BIBLIOGRÁFICAS

• Software Engineering: An Idea Whose Time Has Come and Gone? – Tom DeMarco 
• Six Rules For Great It Project Success. – John Avellanet
• The New Methodology – Martín Fowler
• Desarrollo y Gestión de Proyectos – Dr. Daniel Tapia
• Lean Development en México – Emilio Osorio 
• Libera tus Proyectos con Lean Software Development – Emilio Osorio 
• PODCAST sobre temas ágiles – Open Knowledge Scrum Manager