IEDGE – Dirección de Proyectos Informáticos
1.- La percepción de sencillez
Los sistemas informáticos se han ido haciendo cada vez más amigables y sencillos para los usuarios. La curva de aprendizaje en el uso de los sistemas informáticos es cada vez más suave y cualquier “nativo digital” usa decenas de sistemas sin dificultad. Incluso los usuarios menos avanzados son capaces de hacer trabajos bastante complejos con herramientas cada vez más intuitivas.
La apariencia de sencillez esconde una cada día mayor complejidad. Los informáticos tienen que integrar de forma eficiente y sin errores una gran cantidad de sistemas operativos, bases de datos, librerías, aplicaciones, servicios, infraestructuras, etc.
La informática, lejos de ser una ingeniería madura y académica, está dominada por una frenética evolución y cambio. Esta evolución se ve acelerada por un mercado tecnológico de crecimiento exponencial, que no para de lanzar al mercado versiones y productos nuevos que sustituyen los sistemas existentes y los hacen rápidamente obsoletos.
Ilustración 1: Ilusión de simplicidad
En ocasiones, sobre todo cuando se producen errores, la ilusión de simplicidad se rompe y se puede percibir la complejidad oculta que hay tras los más o menos ergonómicos y amigables sistemas que utilizamos en nuestra vida cotidiana y en nuestros trabajos y empresas.
La construcción de los Sistemas de Información y en general la gestión de las Tecnologías de la Información es un trabajo difícil, que debe ser capaz de compaginar la comprensión de las necesidades del usuario con la complejidad interna de la tecnología.
2.- El caos de los proyectos informáticos
Todo el que ha trabajado con equipo informáticos o de desarrollo de software sabe lo poco fiables que son sus estimaciones en cuanto a tiempo y esfuerzo, así como lo poco convincentes son sus promesas sobre la funcionalidad que tendrán los sistemas y sabe cómo muchos requisitos serán siempre implementados en la “siguiente versión”.
En la práctica el desarrollo de software es una actividad muy artesanal, que depende principalmente de la capacidad de las personas que lo construyeron y por ese mismo motivo terminan siendo necesarias para su mantenimiento y evolución. Aunque parezca sorprendente, en el desarrollo de software parece que se utiliza más el ingenio que la ingeniería.
Esta situación de caos en la construcción de software es lo que se ha denominado “LA CRISIS DEL SOFTWARE”. Desde los años 70 se viene hablando de esta crisis y aun no se ha resuelto. Otras actividades de TI, como el hardware o las comunicaciones, no han sufrido una crisis tan profunda y compleja, pero el desarrollo de software sigue siendo el mayor y más difícil problema al que se enfrentan de los directores de SI/TI.
The Standish Group publica desde 1994 el denominado Chaos Report, donde muestra el resultado de las encuestas que realiza a una gran cantidad de empresas de diferentes tamaños sobre el éxito de sus proyectos informáticos. Los datos son impresionantes:
Ilustración 2: Chaos Report – The Standish Group, 2004, 2006, 2009
En 2009 poco menos del 25% de los proyectos no terminan, es decir, son cancelados y todos los esfuerzos realizados son dados como pérdida para la empresa (sin contar el coste de oportunidad que estas cancelaciones pueden suponer). Más del 40% de los proyectos no han cumplido plazos, coste o alcance. Sólo el 32% de los proyectos terminan dentro de unos márgenes razonables de éxito.
A esta situación habría que añadirle los defectos del software, es decir, cuantos errores aparecieron tras la puesta en marcha del sistema. La calidad del software, como efecto colateral, se ve afectada en gran medida por las presiones para cumplir plazos, costes o alcance. ¿De qué nos sirve un sistema informático entregado en plazo, coste y alcance si está lleno de errores que nos impiden trabajar?
Parece que el caos se ha apoderado en gran medida de los proyectos informáticos.
3.- ¿Qué podemos hacer?
Desde luego no debemos resignarnos a esta situación y debemos hacer todo lo que esté en nuestra mano para que los proyectos informáticos de nuestras empresas se sitúen en el porcentaje de proyectos de éxito. No es imposible, es necesario aplicar las mejores prácticas y un poco de organización para que podamos aumentar de forma drástica la calidad nuestros proyectos.
Para ello vamos a revisar dos grandes líneas:
- La gestión de proyectos
- La ingeniería de software
Cualquier proyecto conlleva una gran cantidad de problemas y riesgos. El carácter único de cada proyecto hace que no podamos aplicar con facilidad procesos estandarizados que nos garanticen la consecución de nuestros objetivos. La problemática de gestión de proyectos no es exclusiva de los proyectos informáticos y es compartida por todos los proyectos empresariales, e incluso de la vida cotidiana. Todos hemos participado en algún proyecto y seguramente tenemos experiencia de lo difícil que es planificar, ejecutar y controlar todos los aspectos que intervienen.
Afortunadamente las mejores prácticas en la gestión de proyectos se han reunido en METOLODOGÍAS Y ESTÁNDARES DE GESTIÓN DE PROYECTOS, que podemos seguir para facilitar su gestión. De estas metodologías y estándares vamos a tratar en los próximos post.
Para intentar paliar los problemas específicos de la construcción de software se ha intentado aplicar técnicas y métodos propios de la ingeniería, creando la INGENIERIA DEL SOFTWARE. El IEEE Std 610.12-1990 Standard Glossary of Software Engineering Terminology define la ingeniería de software como: “La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, la operación y el mantenimiento del software”.
No se asusten, no vamos a tratar aquí de los aspectos técnicos de esta ingeniería de software, solo trataremos algunos aspectos generales que combinados con la gestión de proyectos nos pueden ayudar a tener un mayor éxito en nuestros proyectos informáticos.
4.- Propuesta
Les invito a realizar un ejercicio de análisis y valoración de la los proyectos relacionados con las tecnologías de la información en sus respectivas empresas, especialmente de aquellos que han tenido problemas y dificultades. En especial les pido que respondan a las siguientes preguntas:
- ¿Qué tipo de problemas han surgido? ¿coste? ¿alcance? ¿plazo? ¿calidad?
- ¿Cuáles creen que han sido las causas de estos problemas?
- ¿Qué coste ha tenido para la empresa estos problemas?
¡Quedo a la espera de sus comentarios!
Profesor de Dirección de Sistemas y Tecnologías de la Información
Nota: aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información
* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.
¡Pronto grandes sorpresas en Facebook y Twitter!:
- Síguenos en Twitter: @iedge
- Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool
alma gutierrez
comento el día 12 de septiembre a las 4:18 pm (#)
Hola Pablo. Mi negocio es de restaurantes y nosotros compramos ya un sistema hecho especialmente para restaurantes, hay varios, unos mejores que otros, pero este es realmente bueno pero muy caro, y cada que hay un problema te cobran muy caro la hora de asisitencia. Y el problema basico que yo veo es que si las personas que lo alimentan no se les da la capacitacion adecuada, o por algo tienen errores, de verdad que toda la informacion te sale mal. Mi problema proncipal con los sistemas de informacion es en como son alimentados de los datos. Gracias y saludos.
Alfonso
comento el día 12 de septiembre a las 5:23 pm (#)
Hola Alma,
No se que sistema de restaurantes habrás adquirido, que sea muy caro no significa que sea el mejor. Yo he desarrollado mucho software en mi carrera profesional y, de acuerdo que la toma de datos tiene que ser correcta para poder obtener resultados, pero también hay que tener en cuenta si el equipo de profesionales que ha creado ese software se ha puesto en el lugar de la persona que va a manejar el sistema, si ha sabido intuir (y entender) las necesidades reales de, en tu caso, un restaurante.
Muchas veces, los encargados de estudiar los requisitos de un sistema: toma de datos, interfaz del usuario, procesos a realizar, casos de uso, etc., no viven directamente la realidad el usuario e intentan, desde su mesa, diseñar una aplicación que, finalmente, no cumple con lo que se espera de ella.
Cuando hice por primera vez un sistema terminal punto de venta para un comercio iba tomando notas mentales de las cosas que veía hacer en las tiendas que entraba a comprar y después me pasaba horas imaginando como trasladar ese trabajo al software y hacer del equipamiento informático una herramienta de trabajo para mi cliente en vez de convertirlo en un quebradero de cabeza. Cuando hice ese primer sistema no había pantallas táctiles, ni entornos gráficos, y para dar soltura al sistema sin necesidad de que el cliente hubiese de adquirir un teclado especial, invente una forma de asignar artículos a las teclas del teclado convencional de forma muy sencilla.
Saludos
Jose Alfonso Suárez Moreno
Luis Hernández
comento el día 12 de septiembre a las 4:49 pm (#)
Hola Pablo,
me parece muy interesante y acertado que definas como claves tanto la «Gestión de proyectos» como la «Ingeniería del software» para el éxito de cualquier proyecto. Pero creo que el otro pilar necesario es la gestión de expectativas, pues no siempre es el cumplir con lo especificado en el proyecto lo que llega a satisfacer al cliente, sino el que cubra sus expectativas (erróneas o no) acerca del mismo.
un saludo,
Luis
Alfonso
comento el día 12 de septiembre a las 5:02 pm (#)
Hola Pablo,
La experiencia me ha enseñado que cualquier desarrollo informático de cierta envergadura (media-grande) no puede darse por acabado nunca. No es tarea fácil hacer comprender al cliente que su sistema va a estar siempre en estudio-desarrollo, bien sea por que cada vez que se da por terminada una fase del proyecto antes de entregar la siguiente aparecen cambios no planificados, ya sea por que aparecen imprevistos que no se tuvieron en cuenta en la fase de estudio o por que se han ido haciendo tantos ajustes durante la fase de desarrollo que las piezas nunca terminan de encajar bien.
A mi, después de 30 años de profesión como analista programador (trabajando por cuenta ajena y propia), me cuesta mucho precisar con exactitud el valor de una aplicación, dar una fecha de entrega, imponer plazos y límites a algo que es, en gran medida, un arte. Digo esto por que, aunque escribir código y hacer programas puede tomarse como una tarea mecánica, conseguir el elemento casi mágico que convierte un programa informático en una herramienta cómoda y fácil de usar para el usuario.
En muchos de los casos, después de haber estudiado los requisitos del software a desarrollar y haber comenzado la fase de escritura de código, es cuando el cliente cae en la cuenta de que «se le han olvidado» incluir determinados procesos. A veces no pasa nada, se quedan para incluirlos al final, se presupuestan a parte y listo; pero ¿que pasa cuando lo que acaba de «recordar» el cliente supone un cambio profundo en lo que ya está aceptado y cocinándose?
Desde hace unos años, cada vez que me piden valoración sobre un proyecto, intento hacer comprender al cliente que el software que me está pidiendo va a ser algo vivo y cambiante que jamás tendrá un fin, por lo que mis honorarios pasarán a ser mensuales a partir de la puesta en producción de la versión 1 (la que se aprueba al firmar el contrato); como es de suponer, hay clientes que entienden esta forma de trabajo y otros que no la aceptan por que piensan que un programa informático es algo que comienza y termina.
Saludos
Jose Alfonso Suárez Moreno
Lorenzo H
comento el día 14 de septiembre a las 9:40 am (#)
Hola Pablo:
Son varios años los que llevo en el mundo de la informática en la vertiente de las empresas de servicios. En estos años he visto muchos proyectos, pequeños y grandes y mis datos no coinciden del todo con la estadística que muestras. Personalmente creo que el segundo grupo de proyectos – los que no cumplen ni plazos ni expectativas – es mucho más alto, mientras que el tercer grupo – proyectos abandonados – es inferior (no hay ‘narices’ de asumir la responsabilidad de cancelar el proyecto).
Contestando a tu invitación. ¿Qué tipo de problemas han surgido?
. De calidad: herramientas que son difíciles de modificar – bien para aumentar prestaciones, bien para implementar ‘pequeños cambios’, incluidos los arreglos a errores existentes desde el inicio – mal documentadas y con fallos inesperados dificilísimos de localizar y subsanar.
. De plazo: proyectos de construcción y mantenimiento en los que durante la fase de mantenimiento es cuando realmente se construye el aplicativo porque la construcción fracasó estrepitosamente.
. De alcance: entregas de proyectos en las que el producto entregado y las expectativas del usuario no tienen casi ningún punto en común.
Origen de estos problemas:
Estos problemas son síntomas de varias enfermedades y pueden aparecer juntas o separadas. Y casi todas ellas tienen una fiebre común: aumentan el coste inicial de forma alarmante.
Las mencionadas ‘enfermedades’ son:
– No se respetaron las fases de ninguna de las metodologías de desarrollo de software. Por ejemplo: se diseñaron las pantallas y los informes con todo detalle mucho antes – y probablemente sin – el Análisis Funcional. Puede que el equipo desconociese en gran medida la metodología que se estaba siguiendo. Y esta posibilidad enlaza con el siguiente mal.
– Se construyó con una tecnología desconocida para la gran mayoría del equipo del proyecto. Con lo que ni se evitaron errores comunes ni se pudo utilizar el potencial de la herramienta de desarrollo.
– El alcance y objetivos del aplicativo no estaban definidos en un principio y se fueron creando por el camino, con lo que algunos elementos de la cimentación, tal como el modelo de datos, no se crearon con la coherencia y solidez necesarias (se podría considerar que esta fase forma parte del ciclo de vida del desarrollo del proyecto y hablaríamos entonces de la primera ‘enfermedad’.
– Una pésima gestión de los profesionales. Bien porque no se les asigno en el momento y número adecuado, bien porque no tenían la formación necesaria, bien porque carecían de la motivación adecuada.
Espero te sirva de algo mi aportación. Un saludo, Lorenzo H.
Fernando Pulido Soto
comento el día 14 de septiembre a las 10:20 pm (#)
Hola Pablo,
Primeramente desandote que te recuperes pronto.
Opino que verdaderamente la teconolia parace que no deja de evolucionar, es sorprendente la rapidez de su evolución, que es difícil de predecir el futuro, como esta frase dicha en 1981 “640 Kb -de memoria- deben ser suficientes para cualquiera» Bill Gates
Respecto a mi empresa
• ¿Qué tipo de problemas han surgido? ¿coste? ¿alcance? ¿plazo? ¿calidad?
Reportes diferentes y/o no cumple requisiones y familiaridad.
Mas complejo la manera de hacer el trabajo (mayor costo de mano hombre)
• ¿Cuáles creen que han sido las causas de estos problemas?
Tiempo, persistencia, compromiso.
• ¿Qué coste ha tenido para la empresa estos problemas?
Mayor tiempo en trabajo mas dinero, y mas dificl la supervicion de resultados.
Saludos
Fernando
Alejandra Torres
comento el día 02 de octubre a las 9:17 pm (#)
Excelente post, la información muy sencilla y contundente. No cabe duda que la TI han venido a facilitar nuestro mundo globalizado mientras dificultan el mundo de los programadores. Considero que una sistemas bien planeado, con la información exacta y ejecutado correctamente, disminuye costos considerables de la empresa haciéndola mucho mas eficiente y competitiva.
saludos