4 razones por los que los proyectos de software necesitan soporte y mantenimiento.

Trabajo en una empresa de desarrollo web que desarrolla proyectos de software a medida y a menudo nos encontramos con clientes que no quieren firmar contratos de mantenimiento del proyecto.

Es curioso, porque nunca nos cuestionamos cuánto y cómo pagamos el soporte del “software empaquetado” y, de hecho, cuando Microsoft dejó de dar soporte a Windows XP fue noticia en todos los medios, incluso en los generalistas. Sin embargo, cuando hacemos soluciones a medida no nos parece relevante contratar soporte o mantenimiento.

Seguramente habrá muchas razones por las que esto sucede; tantas como dos: no se aprecia el valor y la ausencia de presupuesto…y muchas por las que el mantenimiento de un proyecto es una parte fundamental e imprescindible del proyecto.

1. La (deseable) larga vida de un proyecto de software.

Cada proyecto es único e irrepetible. Cada uno de ellos nace con un propósito que puede ir desde vender algo hasta difundir ideas, hasta llevar la contabilidad de las empresas.

En cualquier caso, los proyectos de software tienen un ciclo vital, ya sean desarrollados en cascada o de forma ágil, ya sean en una multinacional que va a lazar su producto invirtiendo miles de millones euros en marketing para su venta o una startup que lanza un mpv con la estrategia de ver cómo evolucionarlo con sus clientes y con las tendencias del mercado.

Esquema de metodología Scrum
Esquema de metodología de desarrollo en cascada

Un proyecto que funciona necesariamente, tras la puesta en marcha, necesita ajustes, cambios y actualizaciones. La llegada de usuarios, la experiencia de los administradores, la implantación o el despliegue ponen en relieve pequeñas cosas que se nos han quedado en el aire o arquitecturas que no soportan n número de usuarios o que no funcionan con determinados modelo de datos.

El paso de los años (e incluso de los meses) hace que las tecnologías que utilizamos para nuestro proyecto queden obsoletas o que requieran actualizaciones de seguridad para protegerlo. Cambios legislativos, cambios en los medios de pagos, cambios en el lenguaje…nuestro proyecto no sólo tiene vida, sino que está inmerso en un mundo conectado en constante cambio.

Entre el 70–80% de la mejora y evolución de la funcionalidad de un proyecto de software implementa actuando sobre software desarrollado y prestando servicio en producción.

2. Seguridad y versiones y actualizaciones.

Actualmente una aplicación, un proyecto de software se compone de muchas piezas conectadas que generan dependencias unas de otras ( el lenguaje de programación, las librerías, el framework, servidor…). La actualización de un parche de seguridad puede hacer que tenga que modificar la configuración de mi servidor y que a su vez puede incurrir en conflicto con una librería.

El problema es que no apreciamos el valor de las actualizaciones hasta que tenemos problemas serios y la aplicación “no funciona”. Y no lo hacemos porque tenemos que dedicar recursos a mejoras en las que no vamos a ver el retorno de la inversión y que no van a impactar directamente y a corto plazo en el resultado de negocio.

Sin embargo se calcula que una aplicación pasa de media un 10% de su vida en fase de desarrollo y un 90% en fase de mantenimiento.

A todo esto se le suma que el trabajo de mantenimiento suele ser caro por dos razones: uno, es un trabajo altamente especializado y, muchas veces, complejo, y dos, es un trabajo que no conecta con la pasión de las personas; no se trata de rediseñar una arquitectura, no es una fase del trabajo donde la creatividad deba reinar; suele ser un trabajo de bajo detalle que se suele hacer bajo al presión de que “algo importante no funciona o ha dejado de funcionar”

3. Internet siempre está un poco roto.

“Internet is always is a little bit broken”. Tim Berners Lee

Unos años más tardes de que el inventor de internet dijera esto, el Cluetrain manifesto señaló como una de las características de la web el estar rota “Because the Web is by far the largest, most complex network ever built, and because no one owns it or controls it”

Muchas veces entendemos que cuando contratamos mantenimiento parece que estamos pagando por arreglar algo que está roto. Peor, tenemos la sensación de estar pagando por algo que se nos ha dado roto. No pagaríamos por una camisa que está rota y demás, le pagaríamos a la tienda que nos la vendió para que la cosa. Pero la realidad es que pagar por una solución web no es pagar por un producto cualquiera ni por un servicio como cualquier otro; tiene sus peculiaridades y ésta es una de ellas.

4. Construye un equipo.

“Colaboración con el cliente en lugar de grandes negociaciones”. Agile manifesto

Actualmente, tal y como reconocen ya las grandes consultoras, las metodologías ágiles son las más efectivas para desarrollar proyectos de software y éste es uno de los principios más valorado por los desarrolladores.

Incluir al cliente como parte del equipo con el que iterar a diario, con el que establecer prioridades y con el que compartir dudas de diseño es la mejor forma de tener los objetivos de negocio siempre presentes en el proyecto.

Esto está claro para todas las partes; sin embargo muchas veces terminamos negociando con el cliente qué es un bug y qué no lo sé. Para los neófitos o recién iniciados en los proyectos de software: cuando el cliente prueba el producto y encuentra errores, esos errores se arreglan sin ir contra la bolsa de horas contratadas. Cuando no lo es, este tipo de cambios consumen recursos contratados. Y es aquí dónde vienen las negociaciones y los desacuerdos.

Estas tensiones y la presión de la bolsa de horas se acaba en el momento en el que un cliente entiende que la mejor manera de que su proyecto tenga éxito es firmar un acuerdo estratégico con su proveedor que contemple horas de desarrollo mensuales.

En resumen…

Contratar mantenimiento u horas de desarrollo una vez lanzado el proyecto no es una comodity, ni un gasto innecesario. Es una inversión casi de corte estratégico necesaria para tener el mejor producto posible