25 May Contrataste un software a medida y aún así no funciona. Esto es lo que falló
Invertiste en un software a medida. Nada de soluciones genéricas que no encajaban. Contrataste desarrolladores, definiste funcionalidades, pagaste por un traje a medida. Y meses después, tu equipo lo usa a medias, se queja en voz baja y tú te preguntas dónde se fue el dinero. La respuesta es incómoda pero simple: el fallo no está en el código.
El error que se repite en el 90% de los proyectos
Pongamos una escena realista. El propietario contrata al equipo de desarrollo. El director de tecnología define los requisitos técnicos. El project manager traduce necesidades a funcionalidades. Y los desarrolladores escriben código. ¿Quién falta en esa cadena? Exacto: la persona que usará el software 8 horas al día.
Cuando quienes definen lo que el software debe hacer no son quienes van a usarlo, el resultado es predecible: un sistema que técnicamente hace lo que se pidió pero que nadie quiere usar porque no resuelve los problemas reales del día a día.
Lo que pide la dirección vs. lo que necesita el equipo
El propietario quiere reportes. El director quiere que escale. El gerente quiere control de procesos. Pero la persona que introduce datos 200 veces al día quiere que el formulario no le haga perder el tiempo. Quiere que el sistema recuerde lo que ya introdujo ayer. Quiere no tener que abrir tres pantallas para completar una tarea de 30 segundos.
Si el diseño del software solo satisface a la capa directiva —reportes bonitos, dashboards completos— pero castiga a quien lo alimenta de datos, el sistema se muere por abajo. Los datos no entran, o entran mal, y los reportes que tanto costó diseñar se vuelven inservibles.
La trampa del «yo ya sé lo que necesito»
Otro patrón clásico: el propietario o el director de tecnología fueron quienes usaban el sistema hace 5 años. Creen que saben lo que hace falta porque «conocen el negocio». Pero el negocio ha cambiado, los procesos han evolucionado y las necesidades diarias de un empleado nuevo no son las mismas que cuando la empresa tenía 5 personas.
El software a medida fracasa cuando se diseña basándose en suposiciones en lugar de en observación directa. No basta con preguntar «¿qué necesitas?». Hay que sentarse al lado de la persona, ver cómo trabaja, entender sus atajos, sus frustraciones y sus soluciones improvisadas.
Lo que aprendimos con nuestro propio software
En Vidasoft cometimos exactamente este error con GiveFeedback. Tuvimos que rediseñar la interfaz entera porque nosotros mismos —los creadores— evitábamos usar nuestro SaaS. El código funcionaba. Las funcionalidades estaban. Pero la experiencia era tan frustrante que preferíamos cualquier alternativa antes que abrir nuestra propia herramienta.
La lección fue clara: el mejor código del mundo no salva un software que nadie quiere usar. Y la única forma de evitarlo es incluir a los usuarios reales desde el minuto cero del diseño.
Tres preguntas que deberías haber hecho antes de desarrollar
Si estás a tiempo de corregir el rumbo —o si estás planeando un nuevo desarrollo—, haz estas tres preguntas a las personas que realmente usarán el sistema:
- «Enséñame cómo haces ahora esta tarea, paso a paso, sin saltarte nada». No preguntes qué necesitan. Observa lo que hacen. Los workarounds, los atajos, las herramientas externas que usan para compensar carencias. Ahí están los requisitos reales.
- «Si esta tarea te llevara la mitad de tiempo, ¿qué harías con el resto?». Esta pregunta revela el coste de oportunidad. No es solo que el sistema actual es lento: es que está consumiendo tiempo que podría dedicarse a tareas de más valor.
- «¿Qué es lo primero que cambiarías si pudieras?». No preguntes por una lista de funcionalidades. Pide una sola cosa. La respuesta suele apuntar al punto de fricción más doloroso.
Tu software no ha fracasado: está mal enfocado
La buena noticia es que rara vez hay que tirar todo el código. Normalmente el motor es sólido, la base de datos funciona y las integraciones están bien. Lo que falla es la capa que conecta todo eso con las personas: la interfaz, los flujos de trabajo, la forma en que la información se presenta y se captura.
Un rediseño centrado en el usuario —en quien realmente pasa 8 horas al día con la herramienta— puede rescatar una inversión de decenas de miles de euros. Y lo hace sin tocar una línea de la lógica de negocio. Solo cambiando cómo se presenta y cómo se interactúa con ella.
Si al leer esto has pensado en tu propio software —ese que funciona pero nadie quiere—, el problema tiene solución. Cuéntanos tu caso. Empezamos por escuchar a quien de verdad importa: tu equipo.
