Diseñar para el mantenimiento, no solo para el lanzamiento

La mayoría de los productos físicos se conciben para un ciclo de vida largo, y sin embargo el equipo de diseño suele medir su éxito en el momento del estreno. Es comprensible. La ideación es la parte más generosa del oficio: entender al usuario, descubrir lo que necesita sin saber nombrarlo, convertirlo en forma, material y proceso. A mí me sigue pareciendo una de las partes más bonitas de trabajar en producto.

Pero a quienes diseñamos producto rara vez se nos enseña a pensar en el largo plazo, y menos en el mantenimiento, a menos que venga escrito en la especificación. La presión de rentabilidad y de entrega concentra la atención en la fecha de salida: ahí está el dinero invertido, ahí está el compromiso con el cliente, ahí se cierra el trimestre. Lo que ocurre dieciocho meses después le pertenece a otra área, a otro presupuesto o, con frecuencia, a nadie.

Lo cuento como experiencia propia, no como un juicio sobre toda la formación en diseño: hay escuelas y equipos que lo hacen muy bien. En mi caso, el mantenimiento apareció con claridad cuando alguien lo puso por escrito como requisito. Dos productos me obligaron a mirar más allá de la entrega, y los cuento a continuación porque cambiaron la manera en que hago preguntas.

El segundo recuerdo es un audífono de largo alcance. Conservo la denominación tal como se usaba en el proyecto, y aquí no voy a entrar en especificaciones técnicas: lo que importa para este capítulo es que la durabilidad estaba en la especificación desde el principio.

Increíblemente, el requerimiento consideraba el desgaste de los componentes tecnológicos y de las carcasas, y sus posibles reemplazos. Es decir, alguien había aceptado en el papel que ciertas piezas se degradarían y que el producto debía diseñarse para que esa degradación no lo volviera inútil. En mi experiencia, no es lo más común: los componentes y las carcasas suelen diseñarse para el mejor primer día, no para el reemplazo.

Lo que une a los juegos infantiles con el audífono es una idea sencilla: especificar el mantenimiento cambia materiales, uniones, acceso, modularidad y abastecimiento. Pero hay una condición que aprendí a vigilar: la reparación debe ser posible técnica y económicamente. Tener un repuesto disponible no sirve si desmontar el producto cuesta más que sustituirlo; en ese caso, el repuesto existe y la reparación no.

Desde entonces, cuando alguien me presenta un producto, además de preguntar para quién es y cuánto cuesta fabricarlo, pregunto cómo se abre, quién puede abrirlo y qué pasa cuando una pieza deja de funcionar.

Si miramos el automóvil como modelo de negocio, aparece algo que el diseño suele pasar por alto: el valor económico de un producto no se agota en la venta. Alrededor de un vehículo conviven la venta inicial, las refacciones, los servicios, el financiamiento, los seguros y otros ingresos posteriores. Y no son iguales para todos: la estructura de rentabilidad de un fabricante, la de un distribuidor y la de un taller son distintas.

Por eso conviene evitar dos simplificaciones. Una es decir que las manufactureras ya no ganan dinero vendiendo vehículos; la otra, que toda su rentabilidad depende del mantenimiento. Ninguna es cierta de forma general. Lo que sí puedo afirmar es que, para muchos productos durables, una parte importante del negocio ocurre después de la entrega, y que quien diseña el producto influye en cómo ocurre.

Aquí vuelve una idea del capítulo 4: las necesidades no siempre son naturales; a veces son diseñadas. La crítica al consumo apunta con razón a quienes generan la oferta. Pero conviene separar cuatro conceptos que suelen mezclarse, porque cada uno pide una pregunta distinta.

En tecnología digital el mantenimiento es todavía más difícil de diseñar, porque no se ve. Un objeto físico se oxida, se rompe, se despinta; un sistema puede estar encendido y, a la vez, acumulando datos sin límite, dependencias sin soporte y vulnerabilidades sin parche.

Las metodologías incluyen un ciclo completo hasta la entrega a producción. SSDLC, por ejemplo, son las siglas de Secure Software Development Life Cycle: el ciclo de vida de desarrollo seguro de software. No es una única metodología con dueño; describe la idea de integrar la seguridad en el ciclo de desarrollo. Es distinto del SSDF, el Secure Software Development Framework del NIST (SP 800-218), que ofrece prácticas que una organización puede incorporar a su ciclo de desarrollo, sea cual sea.

Hay manuales, pruebas, listas de verificación y una entrega ordenada, y aun así veo una distancia enorme con el mantenimiento real. El problema no está en el SSDLC: aparece cuando tratamos la entrega como un cierre y no le asignamos a la operación capacidad, presupuesto, responsables ni aprendizaje.

Las cosas que menos observamos en un proyecto de implementación de tecnología son justo las que más pesan después: el espacio, el cálculo de volúmenes, la seguridad a largo plazo, el mantenimiento de la operación y el mantenimiento de la arquitectura. Muchos stakeholders no las ven como parte del todo y se les escapan de sus casos de negocio, porque todo eso cuesta, y cuesta más conforme crece el uso.

En un producto físico estudiamos la frecuencia de uso, las cargas, el ambiente y la resistencia del material. Nadie diseña una banca pública sin preguntarse cuántas personas se sentarán en ella y bajo qué clima. En un producto digital la pregunta equivalente es cuánta concurrencia, cuántas peticiones, cuánto almacenamiento, cuánta transferencia y cuántas dependencias soportará.

Hoy existen servicios de autoescalado y arquitecturas serverless, y es una gran noticia. Pero no siempre fue así, y aun hoy lo que cambia es la manera de obtener capacidad, no sus costos, sus límites o sus cuellos de botella. Un producto puede crecer en usuarios y perder margen si aumenta el consumo por usuario, los reintentos, el soporte o las llamadas pagadas a terceros.

Tampoco conviene suponer que el costo es proporcional al uso. Hay costos fijos, costos variables, escalones de capacidad y economías de escala. Y los usuarios activos mensuales (MAU) no miden la carga: dos usuarios activos pueden consumir cantidades muy distintas.

Pongamos un ejemplo que construí para este libro, no un caso de un producto mío: una app de emergencias por fenómenos naturales y desastres. Es un caso extremo pero realista. En un día normal podría recibir entre 1,000 y 5,600 interacciones; en una emergencia, según la localidad y el tamaño del evento, fácilmente 50,000. Antes de dimensionar nada hay que definir qué es una «interacción» y en qué ventana de tiempo ocurre.

Porque 50,000 interacciones repartidas en un día no son lo mismo que 50,000 concentradas en diez minutos. En la segunda ventana son unas 83 por segundo, y todavía hay que multiplicar por las llamadas técnicas que cada interacción dispara y por los reintentos. Con, digamos, cuatro peticiones por interacción serían unas 333 por segundo y, si cada una tarda dos segundos en promedio, alrededor de 667 en curso al mismo tiempo, bajo condiciones estables.

Pero el tráfico es solo una parte. En una emergencia las telecomunicaciones se degradan, la latencia sube, las baterías escasean y los proveedores externos se saturan. Escalar el servidor no repara una red móvil caída. El mantenimiento de la operación debe prever caché, información esencial disponible sin conexión, la fecha de la última actualización, solicitudes pendientes y una degradación controlada: que el producto haga menos, pero siga haciendo lo esencial.

También está la perspectiva humana. ¿Puede una persona mayor reconocer la alerta, entender qué hacer y distinguir la información vigente de la desactualizada? ¿Funciona en un teléfono antiguo, con baja visión o poca familiaridad digital? Estas preguntas se responden antes del lanzamiento y son mantenimiento de la operación, casi siempre invisible.

Y está la actualización. Los cambios del servidor y la configuración remota no son lo mismo que una nueva versión de la app, y no conviene prometer actualizaciones automáticas universales. Lo prudente es prever compatibilidad, despliegue gradual y reversión, y evitar que alguien necesite actualizar la app para acceder a información esencial durante una emergencia. Los ensayos se hacen en entornos de prueba: no se le retira protección esencial a un grupo de usuarios reales para ver qué pasa.

Una manera práctica de empezar es hacer un mapa del ciclo de vida a tres años: volúmenes, forma de uso, perfil de usuario e incidencias. No es una predicción cerrada; es un conjunto de hipótesis revisables que se cuestionan cada vez que llegan datos nuevos.

Para cada horizonte conviene elaborar tres escenarios —uso bajo, esperado y de estrés— y registrar el perfil de usuario, el volumen, la frecuencia, las incidencias, el costo, la seguridad, las dependencias, un responsable y el umbral a partir del cual se interviene.

El mantenimiento de un producto físico se apoya en instrumentos: un calibre o micrómetro para la pérdida dimensional, un medidor de espesor del recubrimiento, ensayos de corrosión, de carga, de fatiga o de abrasión según el material y la función, y a veces una balanza, cuando la pérdida de masa tiene sentido. Lo importante es llevar un registro.

El peso por sí solo no mide toda forma de desgaste, así que conviene anotar la unidad o el lote, las condiciones de exposición, los ciclos de uso, el método de medición, el instrumento, su calibración cuando proceda y el criterio de aceptación.

En digital existe un paralelo, aunque no una equivalencia literal: el desgaste del material y las fallas del software no son lo mismo. Pero ambos dejan evidencia que se puede medir y documentar.

En un producto físico se pueden instalar unidades piloto o grupos de seguimiento expuestos a condiciones conocidas y revisarlos con la frecuencia que se haya definido. Conviene reservar la expresión «grupo de control» para las comparaciones que realmente tienen un control y un diseño de medición; seguir unidades en campo es valioso, pero no es lo mismo que un experimento controlado.

En digital ocurre algo parecido. Se usan cohortes, pilotos y despliegues graduales para detectar necesidades de soporte, degradación y diferencias entre perfiles. Un A/B test puede evaluar un cambio específico, pero no sustituye las pruebas de recuperación, seguridad o capacidad. Y conviene comparar dispositivos, redes y patrones de uso para no atribuir al cambio lo que corresponde al contexto.

Todo esto forma un ciclo de aprendizaje: medir, interpretar, decidir, verificar. En cada vuelta se documenta el problema, la evidencia, la hipótesis, la intervención, el responsable y el resultado, y se verifica si la corrección mejoró la experiencia y redujo el costo de sostenerla. El diseño del mantenimiento no termina con el lanzamiento: es un proceso iterativo y de aprendizaje constante.

Vuelvo a los juegos infantiles y al audífono. En ambos casos, pensar en la vida posterior al estreno cambió tanto el objeto como el servicio que lo acompañaba. Esa es la parte que más me entusiasma hoy: el mantenimiento no es solo un costo que se administra; muchas veces es una fuente de oportunidades.

Reparación, reacondicionamiento, repuestos, extensión de la vida útil, soporte especializado, niveles de servicio con costo diferenciado según el tipo de cliente. En digital, la evidencia del mantenimiento también revela segmentos nuevos, necesidades de integración y servicios operativos que nadie imaginó en el lanzamiento: diversificación de mercado nacida del uso real.

Con una advertencia: una cosa es la oportunidad de cobrar por un servicio adicional y otra, muy distinta, el incentivo de crear dependencia o fallas evitables. Los niveles de soporte pueden variar en acompañamiento o en tiempos de respuesta; las obligaciones básicas de seguridad deben cumplirse para todos los clientes.