A grandes rasgos, el desarrollo del software sigue unas etapas: se planifica (etapas previas de tomas de requisitos y análisis), se desarrolla (programación e implantación), se mantiene (arreglo de posibles fallos durante el uso del mismo, labores administrativas programadas, ...), evoluciona (se agregan nuevas características si surge la necesidad) y, a veces, muere (se deja de utilizar el producto).
Lo habitual es que la etapa de mantenimiento sea la más larga, pero no debería ser la más costosa económicamente. Sin embargo, existes numerosos sistemas en lo que esto no es así.
¿Han trabajado alguna vez con el típico programa con muchos fallos pero que, sin embargo, se utiliza desde hace mucho tiempo y no hay planes para sustituirlo? ¿Les suena la situación cuando todo el conocimiento de "las tripas" de una aplicación se deposita en muy pocas personas (incluso en una sóla)? ¿Utilizan algún programa que sólo funciona en algunos entornos muy específicos con unas versiones muy concretas del sistema operativo y otras aplicaciones? ¿Se gasta su empresa un dineral en personal subcontratado para que este programa siga malfuncionando?
Todos estos son los síntomas del "software insostenible" (la nomenclatura es propia). Programas y aplicaciones que no han sido bien gestionados y se han escapado de las manos de los que los diseñaron, los programaron, los mantienen y de los que pagan todo esto, el cliente final.
Al final nos encontramos con un dinosaurio software, lento, grande y arcaico. Los usuarios lo odian porque nunca acaba de ir bien, los responsables de área lo odian porque se lleva muchos recursos presupuestarios, los desarrolladores lo odian porque es asqueroso trabajar con el código enmarañado y mil veces parcheado, ...
Lo peor en estos casos es que la solución más obvia, que es rehacer la chapuza, o al menos, dedicarle un buen tiempo para poner orden y concierto, sale muy caro (además, no hay garantía de que la nueva versión sea buena). Pero también sigue siendo muy caro el mantener la aplicación. Un buen dilema económico.
Algunas causas:
- Mala planificación o diseño previo.
Frecuentemente las tomas de requisitos son muy vagas o imprecisas. Esto conlleva hacer cambios importantes cuando el programa ya está en producción, con los riesgos que esto conlleva: prisas, código rápido y sucio, desintegración entre las distintas partes del programa, ... - Uso de una herramientas/lenguajes inadecuados y/o obsoletos.
Algunas herramientas (lenguajes de programación, entornos de desarrollo, etc) son muy permisivas con las malas prácticas al desarrollar software. Dejan una libertad de actuación al desarrollador que puede ser perjudicial al no forzar una buena organización del trabajo y del código. - Mala organización del personal.
Personal novato al que se le pone a trabajar sin una adecuada formación y supervisión en clientes finales, alta rotación del personal, jefes de proyecto/analistas sin vocación técnica que no revisan el código que se produce, ... - Clientes mal acostumbrados.
Muchos clientes quieren las cosas para ya, y no siempre es posible hacer algo rápido y bien. Si una mejora requiere un estudio y análisis, así se le debe comunicar al cliente, y no ponerse a picar código como locos.
Podría seguir enumerando más errores, pero no merece la pena. ¿Existe alguna solución para este desaguisado?
Probablemente para los sistemas existentes sea difícil encontrarla, pero hay que aprender de los fallos:
- Sres. contratantes: no fuerce a los profesionales que contrate. Si le dan unas estimaciones, respételas, no son gratuitas.
Desconfíe de empresas de desarrollo o consultoras con mucha rotación de personal. Infórmese antes de cómo se trabaja en ellas. Los "obreros del software" somos también muy importantes, no sólo los encorbatados que van a presentar y vender el producto. - Sres. contratados: no sucumban a la tentación de dar plazos cortos, ni de presentar presupuestos muy bajos. Sean realistas.
Cuiden y formen bien a sus "picateclas", pero supervisen su trabajo: no para sancionar, sino para mejorar. Hagan una buena ingeniería y planificación, no se "aten" en exceso a una tecnología.
Muchos clientes quieren las cosas para ya, y no siempre es posible hacer algo rápido y bien. Si una mejora requiere un estudio y análisis, así se le debe comunicar al clienteQue gran verdad. El problema es que muchas veces se le dice al cliente ''Si Bwana'' y se le entrega un churro. Parece que la mentalidad es hacer algo mal en poco tiempo que hacer algo bien en el tiempo necesario
ResponderEliminarMe encanta lo que has escrito David; a mí me esta pasando algo similar con Joomla, que es una maravilla, pero a la hora de manejar las extensiones las tienes que adaptar, y eso hace que los ritmos se ralenticen; el caso, es que muchos clientes exigen, por el hecho de pagar y aún racanamente, que les hagas las cosas rápidas, ''de hoy para mañana'', luego quieren pagar a 30-60-90, y ademas, exigen que les formes a un personal lamentable con apenas formación e incentivos, de hecho, la mayoría becarios a 400 €, ¡los que cobran!, la mayoría están lampando; pero uno quiere trabajar, y les formas, al cabo de 6 meses, se le va el personal, y a mi, que me gusta salir a tomar copas, a veces me los consigo por Fuencarral, Opera, Serrano, Plaza España, Jorge Juan; a ingenieros y TSU ''sirviendo copas'' y bailando de Gogos ... ¡de risa lo del patio!, luego los propietarios te llaman, en mi caso, me han llegado a amenazar con demandas y mas, exigiendo que les mantengas el sistema funcionando, ''pues eso'', ya ves la risa que me entra cuando le lees el EULA del software propietario, ya ni siquiera les informo, les mando la grabación y a tomar por saco, a continuación llaman, se disculpan, y te dicen que te pagan el 100% de una vez, pero que les atiendas. - - Es lo que hay, y como siempre, la culpa la tiene el sistema casposo e irresponsable en que se ha montado el circo.
ResponderEliminarCreo que el principal problema con el desarrollo es que hay quien vende aplicaciones como si fuesen zapatos.¿En Piel o en ante, te los envuelvo o te los llevas puestos? Estos nuevos mocasines 2.0 son lo más en comodidad.... y con las esquinas redondeadas.Cuando se vende una aplicación hay que tener en cuenta una cosa. El verdadero trabajo empieza cuando la instalas y comienza a funcionar. Es entonces cuando de verdad se ve si funciona y cumple con las necesidades de los usuarios. Lo que hay que hacer es intentar que este paso (instalar en el cliente) se haga lo antes posible para que el desarrollo se haga teniendo en cuenta sus necesidades (ni requerimientos previos ni análisis, los usuarios solo te dan información real cuando usan el producto).Pero muchas empresas de desarrollo calculan sus presupuestos en base a un día de entrega y todo lo que pasa de ese día son pérdidas lo cual es un error ya que NINGUNA aplicación va a ser 100% funcional el día uno de trabajo. Pero como ya nos hemos pasado del presupuesto y el cliente no quiere pagar más si nos piden cambios o correcciones nos las quitamos de encima deprisa y corriendo ya que ese proyecto no da dinero.La forma de trabajo hoy día ya no es esa. Gracias a la flexibilidad que da la programación web y el uso de herramientas enfocadas a metodologías de trabajo ágiles podemos instalar en el cliente una aplicación funcional en muy poco tiempo y siguiendo sus indicaciones y formas de usar la aplicación refinarla hasta que queda a su gusto. Hay que integrar al cliente lo antes posible en el desarrollo, pero no sirve traerlo a nuestra oficina y que nos cuente lo que quiere (que casi nunca es lo que necesita) sino que use el producto y compruebe si le sirve o no.
ResponderEliminarTrabajo en una empresa, en la que se decribe todo lo que dices, puede que esta sea sostenible (aunque lo dudo), varias personas se han encargado de programarlo todo en un convinado muy peculiar, SAP y EXCEL, Es una cacharra muy moderno y todo eso, pero una cosa que utiliza bases de datos en otras ciudades, y ya pueden imaginarse lo que le cuesta a SAP, por medio de un Excel en forma de plantilla predefinida, enviar las dichosas celdas de cada plantilla al servidor. Todo esto para evitar los errores que les provocaban excel, por fallos en formulas y demas, que ahora SAP hace solito, pero que con lo que tarda cada carga una media de 5min, no compensa. Yo no soy el programador que se pelea por que funcione, soy el empleado que utiliza la herramienta y el que se pelea con el dichoso programa y sus programadores. Solo por los quebraderos de cabeza es insostenible.
ResponderEliminarNo te puedes ni imaginar la de veces que he asentido y he dicho sí leyendo el post. Parece que seas compañero mío!
ResponderEliminarHola David, me choco mucho tu apellido, llevo tiempo buscando gente con mi apellido poco conocido,por favor ponte en contacto conmigo, te lo agradeceria.Por cierto muy buen blog.Saludos
ResponderEliminar