Un técnico termina una jornada larga en casa de un cliente, vuelve a la oficina y todavía le queda papeleo. ¿Qué ha hecho? ¿Para qué cliente? ¿Cuántas horas?
Luego alguien necesita esa información en el sistema de gestión de proyectos. Así que el mismo trabajo se registra otra vez.
En Sensem, un fabricante español de puertas, esa era la rutina. Por la mañana, los técnicos comentaban en qué iban a trabajar y salían. Entre ocho y diez horas después, volvían a la oficina e intentaban recordar el día lo bastante bien como para rellenar el parte.
Pascual Brines describía así el proceso anterior:
"Antiguamente se realizaba mediante anotaciones manuales sobre un documento escrito… Esto era la plantilla que nosotros usábamos para el registro de los trabajos diarios de cada operario."
Las horas eran solo una parte. Los detalles del trabajo se olvidaban antes de que alguien los apuntara. Notas que podían ayudar a un responsable a planificar el siguiente encargo o entender por qué algo había llevado más tiempo se quedaban por el camino.
No era un requisito del cliente, pero había una pregunta que no me quitaba de la cabeza: "¿Cómo mejoro su operativa sin hacer que la gente trabaje más?"
Notas. Dejar que la gente apunte lo que ha pasado mientras lo tiene fresco, junto a las horas que ya tiene que registrar. Los responsables reciben los detalles que necesitan y los técnicos no tienen que reconstruir el día entero de memoria. Por ahí quería ir.
Tenía un contacto y diez personas para las que construir
Me encargué del proyecto trabajando en Neotic, alrededor de enero de 2025, como parte de su trabajo de digitalización de empresas españolas. Por entonces, Kit Digital ofrecía ayudas financiadas por la Unión Europea para que pequeñas empresas y autónomos pudieran incorporar herramientas digitales.
Mi contacto era Pascual Brines, Product Manager y propietario de Sensem. Me explicaba las necesidades del negocio, me trasladaba los comentarios del equipo y tomaba decisiones conmigo. Todas las conversaciones fueron en español. La aplicación también lo sería.
Había unas diez personas para las que construir: siete técnicos y tres responsables de proyectos. La mayoría de los técnicos eran mayores, de cuarenta, cincuenta años o más, y no se llevaban especialmente bien con la tecnología. Necesitaban registrar su trabajo y seguir con su día.
Quería que la aplicación fuera a prueba de torpes. No tiene nada de sexy tener que explicar un programa nuevo a cada técnico solo para que pueda registrar sus horas. Es más trabajo para él y para quien tenga que explicárselo.
El software debería ser sencillo para quien lo usa y cumplir lo que necesita el negocio. Abrirlo, saber qué hacer, hacerlo y cerrarlo. Si alguien necesitaba una visita guiada cada vez que quería apuntar sus horas, yo no había hecho bien mi trabajo.
Definí los requisitos, propuse la solución, escribí la especificación, diseñé las pantallas y desarrollé la aplicación. Pascual tenía una persona a la que llamar para todo lo relacionado con el proyecto. Yo tenía a alguien que conocía el negocio y podía darme respuestas.
Los requisitos eran prácticos:
- Los técnicos podían registrar horas para el cliente y el proyecto correctos, con notas sobre el trabajo.
- Los responsables podían ver las entradas sin recoger ni volver a teclear partes de horas.
- Los responsables podían gestionar los estados de los proyectos y las cuentas del personal.
- Los informes mostraban en qué se invertía el tiempo y ayudaban a repartir el trabajo.
- El uso diario tenía que ser sencillo desde el móvil.
De ese último punto dependía que todos los demás sirvieran de algo.
Una aplicación sencilla bastaba para resolverlo
Técnicamente, era una aplicación CRUD sencilla. Crear registros, leerlos, modificarlos y borrarlos. Algo que podrías hacer como proyecto de fin de carrera. Clientes, proyectos, personas, entradas de horas e informes.
Lo difícil era entender cómo encajar esas piezas en la jornada de alguien. Bubble me permitía construir las pantallas y su lógica, con el alojamiento incluido.
Eso me dejaba más tiempo para pensar en cómo la gente iba a usarla. Montar y mantener una base de datos, un alojamiento y un proceso de despliegue por separado habría añadido trabajo sin ayudar al técnico a registrar sus horas.
El coste de la suscripción era aceptable para el cliente. Neotic también estaba apostando por herramientas low-code y formando al equipo para entregar proyectos con ellas. Las necesidades del cliente encajaban con nuestra forma de trabajar.
Sinceramente, Bubble me sorprendió. No esperaba poder hacer tanto con una herramienta low-code, y trabajar con ella fue un placer. Sus guías también eran útiles de verdad. Si empiezas con Bubble, haz las guías. Te ahorras mucho ensayo a ciegas.
Para alguien que vive entre código y, últimamente, una cantidad preocupante de archivos Markdown, construir así fue un soplo de aire fresco. Podías crear algo que una empresa real usaría todos los días sin escribir código. Eso mola.
También hubo alguna piedra en el camino. Un desplegable de las pantallas de gestión necesitó una solución alternativa para funcionar bien en el móvil. Por lo visto, hasta una aplicación interna pequeña tiene su propio jefe final.
Registrar el trabajo llevaba unos 45 segundos
Los responsables creaban clientes y proyectos. Un técnico abría la aplicación, elegía el cliente y el proyecto, introducía las horas, añadía notas y guardaba la entrada.
Tardaba unos 45 segundos.
Cada persona tenía su cuenta. Los responsables podían dar de alta a trabajadores, desactivar cuentas y conceder permisos de gestión. Los clientes no necesitaban acceso. Era una herramienta para quienes hacían y organizaban el trabajo.
Los técnicos registraban lo que habían hecho. Los responsables usaban esas entradas para decidir los siguientes pasos y marcaban los proyectos como pendientes, en curso, terminados o cancelados.
También cambió la forma de atender las llamadas de los clientes. Antes, responder a una pregunta sobre el avance podía requerir llamar primero al técnico. Ahora el responsable abría el panel y podía contestar con el trabajo registrado y el estado del proyecto delante.
Los informes reunían horas y número de proyectos por cliente, tiempo medio y mediano dedicado a los proyectos, su evolución temporal, valor de los clientes y carga de trabajo de los técnicos. Los responsables podían ver dónde se iban las horas y dónde convenía redistribuir el trabajo.
En cinco días dejaron de recurrir al papel
El proyecto completo llevó unas seis semanas, incluidos los requisitos, el desarrollo, las revisiones y la entrega.
Por el camino hubo bastante intercambio. Ajusté pantallas y lógica a partir de los comentarios que me traía Pascual, y adapté los informes a lo que necesitaban ver los responsables. Cuando el equipo empezó a usar la aplicación, el flujo principal ya estaba listo. Los retoques que quedaban eran sobre todo pequeños cambios de interfaz.
Durante la primera semana laboral, los técnicos usaron la aplicación y siguieron rellenando los partes en papel. Así podían acostumbrarse y comprobar que el nuevo proceso funcionaba.
A los cinco días, dejaron el papel.
Eso es lo que más orgullo me da. Nunca hablé directamente con los técnicos. Todo pasaba por Pascual. Tenía que entender su jornada y diseñar un flujo que funcionara para personas a las que no les hacía especial ilusión aprender a usar otra aplicación.
Y fueron ellos quienes decidieron que podían prescindir del papel después de una semana. Tanto ellos como los responsables querían seguir usando lo que había construido.
Fue uno de esos lanzamientos poco frecuentes en los que todo sale como esperabas. Unos pequeños retoques, principalmente de interfaz, y el equipo ya estaba trabajando. Después de darle tantas vueltas, construir y ajustar, joder, qué bien sienta eso.
Podían dejar las herramientas e irse a casa
El cliente estimó que el nuevo proceso ahorraba unos 15 minutos al día a cada técnico. Era una estimación basada en lo que veía, no un estudio con cronómetro.
Con siete técnicos y 21 días laborables al mes, son unas 37 horas. Sin contar el tiempo que los responsables dejaban de dedicar a recoger partes, volver a introducir datos o perseguir actualizaciones.
Quince minutos parecen poco hasta que eres tú quien rellena un parte después de un día largo. Recuperar ese rato importa.
El ritual de final de jornada pasó a ser dejar las herramientas en la oficina e irse a casa. A veces ni siquiera necesitaban volver. Ya no había un parte esperándoles.
Sé que la aplicación se utilizó para la operativa diaria durante al menos ocho meses, mientras yo seguía vinculado al proyecto. Estábamos disponibles para dar soporte, pero el cliente no pidió nuevas funciones durante ese tiempo.
Hay algo muy satisfactorio en eso. A mí me gustó construirla. A ellos les gustó usarla. Y, después de unos pequeños ajustes, nadie necesitaba que siguiera explicando cómo funcionaba.
El papel tuvo una gira de despedida de cinco días. Después, cada uno siguió con su trabajo :)