El contexto
Una pyme cuya actividad se basa en intervenciones en casa de sus clientes: técnicos en carretera, planificaciones que se mueven, partes de trabajo que rellenar in situ y llevar de vuelta a la oficina.
Antes del proyecto, todo ello se sostenía sobre hojas de cálculo, impresiones y llamadas de teléfono. Funciona — hasta cierto volumen.
El reto
La trampa, en este tipo de software, es diseñar para quien compra en lugar de para quien usa.
El gerente quiere visibilidad: dónde están los equipos, qué se ha hecho, qué queda por facturar. El técnico, en cambio, está de pie, en una sala técnica mal iluminada, con una sola mano libre y a veces sin cobertura. Si la herramienta le lleva más tiempo que el papel al que sustituía, no se usará — y un software de negocio que el terreno esquiva no produce ningún dato fiable.
Y había que convivir con lo existente. La empresa ya gestiona su actividad con un sistema de gestión: sus clientes, sus contratos, sus técnicos y sus partes viven allí desde hace años. Sustituirlo no era ni lo pedido, ni razonable, ni financiable. El nuevo software tenía que instalarse al lado, trabajar sobre los mismos datos y no poner nunca en juego lo que ya funciona.
Lo que hicimos
- Una API conectada a la base del sistema de gestión existente. Los clientes, los contratos, los técnicos y los partes siguen siendo propiedad del sistema histórico: los leemos sin modificar jamás su estructura. Lo que pertenece en exclusiva al nuevo software —vacaciones, notificaciones, documentos internos— vive en sus propias tablas, junto a las demás.
- Una regla estricta sobre la base compartida: ninguna evolución automática del esquema. Toda modificación pasa por un script escrito, revisado y ejecutado a mano. En una base que no es tuya, el automatismo no es una comodidad, es un riesgo.
- Una aplicación móvil para los técnicos, con una introducción de datos pensada para el campo: recorrido corto, campos reducidos a lo necesario, nada que presuponga un teclado cómodo.
- Un registro que sobrevive a la falta de cobertura. La planificación, los partes y las lecturas se conservan en el teléfono: el técnico rellena su parte en un sótano, lo hace firmar in situ, y la sincronización se pone al día cuando vuelve la red.
- Una herramienta de oficina, organizada en torno a una planificación en calendario, para quienes asignan las intervenciones y siguen lo que queda por facturar.
- Un desarrollo iterativo, entregado en pequeños incrementos en lugar de un cambio único. Un software de negocio no se especifica correctamente a la primera: son los primeros usos reales los que revelan qué falta y qué no servirá nunca.
El resultado
El software lleva en desarrollo continuo desde 2024 y sigue en evolución activa — lo que, en una herramienta de negocio, es la mejor señal posible: solo se sigue invirtiendo en aquello que se usa. El sistema de gestión histórico, por su parte, no se ha movido.
Este proyecto ilustra dos convicciones. La primera: en un software de campo, el criterio de éxito no es la riqueza funcional, es la tasa de adopción. Una funcionalidad que nadie rellena no vale nada, sea cual sea la calidad de su código.
La segunda: casi nunca hace falta sustituir el sistema histórico de una empresa. Basta las más de las veces con añadirle lo que le falta, allí donde sus usuarios lo necesitan —lo que cuesta una fracción del precio de una sustitución y no pone la actividad en juego.
Cliente cubierto por un acuerdo de confidencialidad
