Jummp’s Blog

Hay algo a lo que todavía no me he acostumbrado y es a lo desproporcionado que le parece a personal no relacionado con la informática el coste del desarrollo de proyectos informáticos.

Es una situación que no alcanzo a entender sobre todo cuando esas personas que se sorprenden incluso cuando comentas cantidades irrisorias se gastan muchísimos dinero en hacer otras actuaciones que sí que son realmente caras en relación al precio de los proyectos informáticos.

Esto provoca que en muchas ocasiones se subestime el coste de un proyecto informático con todos los problemas que esto supone, ya que como he comentado en otras ocasiones, los profesionales de la informática no tenemos una varita mágica que haga surgir un análisis y su codificación posterior de la nada, por lo que si el importe del proyecto es inferior a lo que cuesta realmente lo más probable es que el proyecto no vaya bien, por muy diligente que sea el responsable del proyecto y por muchas horas que dediquen los programadores.

Los profesionales de la informática tenemos que hacer sobre esto una labor didáctica, de manera que las personas con las que trabajamos y costean los proyectos entiendan que el desarrollo de software es una actividad tremendamente compleja y como tal tiene su coste.

¡Qué difícil es sacar un proyecto hacia adelante, cuando solo tú y pocos más creen en el proyecto!.

Todavía es más duro si pones encima de la mesa los datos, los resultados y muestras como con prácticamente sin ayuda de tu organización estás a punto de resolver una problemática importante de su negocio.

¿Qué provoca la falta de implicación en el proyecto? Muchos años de desarrollo, en el cual los ideólogos y mecenas del mismo y los usuarios expertos ya están en muchos casos en otros puestos de trabajo, en otras organizaciones. Muchos años de funcionamiento sin una estructura organizativa sólida. Al ser un sistema con características horizontales, nunca se ha tomado la iniciativa en la organización de establecer un equipo gestor que resista a la rotación tan grande que existe en la misma, esto ha provocado que la gestión general y grandes iniciativas del proyecto siempre estuvieran volcadas en el área informática, más estable, algo que es un gran error, porque zapatero a tus zapatos y no es bueno que las áreas temática y técnica estén unificadas.

Mientras tú creas en el proyecto, el proyecto seguirá a flote, ya que te encargarás de conseguir los recursos necesarios para que salga adelante y siempre estarás haciendo las labores de relaciones públicas del mismo y de dotarlo también de la implicación de personas. No obstante, muchas veces te llega el desánimo porque sabes que con apoyo de la organización todo sería mucho más fácil y mucho más rápido.

Yo animo a todos los que crean en el proyecto o proyectos en los que están trabajando que no bajen las manos y demuestren con su esfuerzo que aquella idea que tenían en la cabeza o que le encomendaron ejecutar no era un error, sino un éxito.

La base de cualquier proyecto informático es saber qué es lo que quiere el cliente. Esto que parece es muy sencillo es tremendamente complicado, en ocasiones por la dificultad de entender el proceso que quiere informatizar y otras porque no siempre es sencillo sacar del cliente todo lo que quiere.

Un buen analista de requisitos es una pieza fundamental en cualquier proyecto, sin embargo no suele ser un puesto especializado, sino que un analista o varios llevan el proyecto del principio hasta el final. De hecho en ninguna de las empresas con las que he trabajado y en ninguno de los proyectos en los que he trabajado me he encontrado con un técnico especializado en análisis de requisitos.

Yo particularmente apostaría por intentar encontrar un especialista en este área, ya que alguien que consiga plasmar en un papel con claridad que es lo que quiere el cliente traducido a un lenguaje que entienda éste y el equipo va a trabajar con el proyecto va a ahorrar muchos problemas al mismo.

Es una garantía para el cliente y para el proveedor que el análisis de requisitos esté por escrito y se obtenga la aprobación de ambos y a ser posible que quede también reflejada dicha aprobación de alguna forma.

En un mundo ideal con un cliente ideal y un analista de requisitos ideal el análisis de requisitos saldrá perfecto, en el mundo real no es así, sobre todo si el sistema de información que hay que implementar es muy complejo desde el punto de vista funcional. Un analista de requisitos excelente hará que casi todos sus análisis no requieran ningún tipo de ajuste y que cuando lo requieran sean menores.

Si hay que hacer ajustes en un análisis de requisitos se hacen, ya que lo importante es que el cliente termine satisfecho del producto, pero es fundamental que esos ajustes se produzcan en las etapas más tempranas del proyecto y es básico que el cliente sepa las consecuencias de futuras o posibles modificaciones en el análisis de requisitos en fases posteriores del proyecto, es decir, que el producto sufrirá retrasos, que rehacer cosas implica un coste que tendrá que asumir, etc…

Hacer una aplicación que verifique los requisitos no significa una ejecución óptima del proyecto, hay muchos más factores, pero esto no debe minusvalorar el análisis de requisitos, ya que permite delimitar el alcance del proyecto (si no se delimita se corre el riesgo de que el proyecto no termine nunca) e indica el resultado final que espera el cliente.