Cuando un Excel deja de ser suficiente
Hoy quiero hablar de algo que aprendes observando cómo trabajan las empresas por dentro.
Muchas aplicaciones reales nacen de un Excel.
Equipos de negocio, tecnología, ventas, diseño… da igual el área.
Si necesitan guardar datos, modificarlos, analizarlos, calcularlos o simplemente extraerlos, tarde o temprano acaban creando un Excel.
El problema empieza cuando ese Excel funciona.
Y cuando funciona, deja de ser una solución improvisada y empieza a convertirse en parte del proceso.
Del Excel a la aplicación
En la mayoría de los casos, alguien se da cuenta de que ese Excel tiene demasiada responsabilidad: demasiadas personas tocándolo, demasiadas dudas y demasiadas cosas dependiendo de él.
Algunos problemas o señales claras de que el Excel empieza a quedarse corto son:
- Mucha gente depende del mismo archivo.
- Hay errores recurrentes.
- Hay versiones duplicadas.
- El conocimiento está en una persona.
- Hay cálculos difíciles de validar.
- Se necesita trazabilidad.
- Hay permisos distintos.
- Se copia y pega información entre sistemas.
- El Excel ya forma parte de un proceso de negocio.
Suele pasar que alguien pide a IT una aplicación para cubrir esa necesidad. Entonces nace un proyecto, producto empieza a ordenar y, después, diseño y desarrollo se suman al proceso.
Cuando aparecen varias de estas señales, no significa automáticamente que haya que crear una aplicación.
Pero sí significa que hay una necesidad que merece ser entendida mejor.
A veces acabará en una aplicación. A veces bastará con mejorar el proceso. Y a veces el Excel seguirá siendo suficiente.
Primero, entender la necesidad
Hay Excels que son baratos, flexibles, rápidos y suficientes. Para muchos pequeños negocios o incluso equipos internos convertirlos en aplicación sería añadir complejidad innecesaria.
La pregunta importante no es “¿podemos hacer una aplicación con esto?”.
Lo que debemos resolver es:
¿Este Excel sigue ayudando?
Si un Excel provoca errores, dudas, versiones duplicadas, dependencias entre personas o falta de trazabilidad, quizá hemos dado con la clave.
Puede que haya una caso a analizar y una necesidad que resolver.
Para aterrizarlo, me voy a ir a un ejemplo pequeño y personal.
No es un caso de empresa ni un gran producto. Precisamente por eso me sirve para explicar el criterio que hay detrás.
Un ejemplo personal: Mi Excel de cursos, libros y rutas de aprendizaje
Es el Excel que utilizo para seguir aprendiendo, registrando cursos, libros y artículos que tengo pendientes o que ya he realizado.
Lo tengo todo clasificado por temas, estado (Sin empezar / En curso / Finalizado) y con detalles de cada recurso.
¿Podría convertirse en una aplicación?
Sí, mucha gente intenta organizar su aprendizaje entre cursos, libros, artículos y recursos sueltos.
¿Tiene sentido hacerlo ahora?
No necesariamente, de momento me funciona, no me bloquea y no hay varias personas trabajando sobre él.
Que algo pueda ser una aplicación no quiere decir que tenga que serlo.
¿Qué quiero transmitir con todo esto?
Cuando alguien pide una aplicación, muchas veces ya viene de meses o años forzando una solución improvisada, puede ser un Excel, un formulario o un documento compartido.
Habrá que revisar si merece convertirse en una aplicación o no, pero ahí hay mucha información.
Antes de pensar en pantallas, componentes o arquitectura, merece la pena entender qué está intentando resolver realmente.
Porque muchas veces el producto no empieza con una gran idea.
Empieza con alguien usando un Excel porque no tiene nada mejor.