“Mantenimiento” es cuando hay que reparar baches producto del paso de los autos. O reparar manchas de humedad, producto de la lucha entre el agua y los materiales. O reponer piezas sometidas a desgaste mecánico. 

Nada de eso pasa con el software.

Lo que se llama “mantenimiento” en software, en arquitectura se llama “ampliaciones y refacciones”.

Cuando hay que atender a nuevos requerimientos, es lo mismo que…

  • proyectar un nuevo piso en una casa, para que tengan sus habitaciones privadas los niños que ahora son adolescentes.
  • tapiar una ventana, porque se mudaron vecinos enfrente.
  • instalar barandas en la bañadera, porque la pareja que encomendó la vivienda cuando era joven, ahora tiene problemas de cadera. 
  • construir una pirámide de cristal en medio del Louvre.

¿Por qué entonces en el caso de software, a esto se lo llama “mantenimiento”?

Quizás porque hace unos 30 o 40 años, los comerciales encontraron que esa metáfora se aceptaba sin tener que explicar a sus clientes qué es realmente el software, algo que no iban a entender. En esa época, el software que se contrataba, no necesitaba atender a factores humanos ni responder a una realidad cambiante. Tenía sentido entonces invertir meses en negociaciones contractuales y definiciones de requerimientos, para luego aferrarse a un plan. Algo que desde hace 15 años, sabemos que no logra resolver los problemas que nuestros clientes tienen hoy.

Quizás hoy un comercial pueda lograr una venta empleando las metáforas de hace 30 o 40 años. Pero difícilmente logre los compromisos que un equipo necesita para construir la solución. 

Nuestros clientes hoy viven rodeados de tecnología que mejora día a día. No quieren funcionalidades: quieren desarrollar un negocio. Y para ello, tienen que entender qué es el software y cómo se construye. Porque los problemas para los cuales nos contratan hoy, requieren que sean parte comprometida de una solución que requerirá de agilidad y compromiso en las decisiones de negocio.

Dejemos de hablar de “mantenimiento”.

Hablemos de decisiones informadas de diseño, tecnología y negocios, construyendo hoy con previsión razonable de necesidades futuras. Hablemos de estar allí para reaccionar, demoler y construir cuando esas necesidades tomen forma y el negocio decida responder a ellas. Hablemos de colaboración necesaria para lograr objetivos bien definidos. Hablemos de qué problemas hay que resolver y no de cuál es el gusto particular de stakeholders que no serán usuarios.

Tengamos conversaciones propias de nuestro siglo.

Santiago Bustelo