Mantenimiento evolutivo

Una de las pesadillas de las empresas de desarrollo de software es la confusión (querer o no querer) que existe en muchos casos entre los conceptos de mantenimiento correctivo y evolutivo. ¿Por qué una pesadilla? Porque la garantía de los desarrollos sólo afecta al mantenimiento correctivo y por tanto no se facturan y en muchas ocasiones se convierten en «sneaks» evolutivos como mantenimiento correctivo y en trabajo adicional para las empresas, no previsto y que en muchas ocasiones requiere un esfuerzo notable y que, por supuesto, no se cobra.

Un mantenimiento correctivo es aquel que tiene como objetivo resolver una deficiencia en un componente del sistema de información (puede ser software o documental). Entender la deficiencia como algo que debe funcionar o ser correcto y que no lo es.

Un mantenimiento evolutivo es aquel que intenta modificar algo que funcionaba o era correcto, con el fin de aumentar, disminuir o cambiar las funcionalidades del sistema, ya sea por las necesidades del usuario o por otras razones como, por ejemplo, cambios normativos.

El problema radica en la definición de lo que debería funcionar o ser correcto en el sistema de información, es decir, la delimitación clara de la frontera entre lo correctivo y lo evolutivo. Y no es algo que esté del todo claro en muchos casos, ya que, por ejemplo, esa funcionalidad que el cliente dice que debería estar ahí y no contempla el programa, es algo que ahora se ha sacado del sombrero o que realmente se ha contemplado en la definición y análisis del sistema de información, es algo que no se ha interpretado correctamente en el análisis, es algo que se suponía que debía extrapolarse del análisis aunque no aparezca explícitamente.

Es cierto que hay muchos casos en los que las incidencias son cajón y son correctivas y en la mayoría de las situaciones no dan problemas ni para el cliente ni para el proveedor, que será consciente de que son sus defectos y los solucionará. También es cierto que hay evoluciones que son muy complicadas de tensar como correctivas, ya que una cosa es que la pared tiene que ser pintada de blanco o crema, que el pomo de la puerta es de plata o de oro o que incluso el suelo es de mármol o de porcelana y otra es tratar de comprar un apartamento de cuatro habitaciones por el precio de un dormitorio. Sin embargo, entre un caso (correctivos claros) y otros (evolutivos claros) hay todo un abanico de posibilidades que la mayoría de las veces dan lugar a conflictos (estos serán menores si el presupuesto del proyecto es flojo, el cliente es bueno, el proyecto es una inversión para intentar conseguir más negocio con el cliente o a través del producto que se ha desarrollado, etc….).

Como ya he comentado en algún artículo en caso de conflicto casi siempre tiene la pérdida del proveedor y lo más importante es haber asumido esa circunstancia. Esto no significa que debas decir que sí a todo, pero es más fácil negociar si no pierdes el tiempo intentando remar contra la corriente.

Habrá negociación porque en los proyectos de desarrollo de software a menudo se cometen errores tanto por parte del cliente como del proveedor. Por esta razón siempre digo que ambas partes deben ser flexibles, ya que todos cometemos errores y la naturaleza de los procesos de desarrollo de software no es rígida, sino un proceso evolutivo en sí mismo.

Los primeros cuatro son obligatorios para todas las empresas de desarrollo de software, ya que implican la prevención de problemas, la predicción de lo que vendrá y la realización de los ajustes necesarios, la corrección de los fallos encontrados y la adaptación a los cambios, si los hubiere.

El mantenimiento perfecto es producido por las demandas de los clientes para aumentar la funcionalidad de la herramienta.

Y el mantenimiento evolutivo supone la adaptación del software a las exigencias del mercado; sin el cual estaría obsoleto.

Leyes de Lehman

De acuerdo con las leyes de Lehman (Lehman 1997), cuyo autor investigó el mantenimiento de software y la evolución de los sistemas desde 1974, el mantenimiento es realmente un desarrollo evolutivo y los problemas clave del mantenimiento evolutivo son administrativos y técnicos.

Lehman, a través de sus leyes, sostiene la importancia del mantenimiento evolutivo y nos habla del cambio continuo, la creciente complejidad de los desarrollos, el límite de los posibles cambios, el equipo de trabajo asignado, la gestión del conocimiento, el crecimiento continuo y la adaptabilidad del desarrollo a los usuarios, entre otros aspectos.

En resumen, Lehman muestra cómo cambia el software en función de los avances tecnológicos, la evolución del mercado y las necesidades de los usuarios.

¿Por qué es importante el mantenimiento evolutivo para los clientes?

La elección de un producto es un proceso largo e importante para las empresas. Los proveedores de software deben tener en cuenta que la adhesión a un producto implica un vínculo con dicho producto (ERP, CRM, ecommerce…) y con el proveedor:

Por el coste que puede suponer el desarrollo e implementación de un producto.
Por el costo de migrar a otro producto.
Por el proceso de aprendizaje de los usuarios.
Porque la mejora de la funcionalidad es un valor añadido en la decisión de compra.
Porque significa un compromiso de calidad para nuestros clientes.