Al principio, pensaba que un sistema que funciona era suficiente.
Si el pago pasa, si la cuenta se crea, si el cliente instala, si todo avanza como estaba previsto, entonces el trabajo está hecho.
Pero esta semana, entendí algo mucho más importante:
Un sistema puede funcionar… y aun así dejarte completamente a oscuras.
Y para alguien que debe gestionar él mismo su producto, eso no es aceptable.
LowFlow avanzaba cada vez más solo. Pasos que antes requerían una intervención empezaban a volverse automáticos. Era exactamente lo que quería.
El problema es que yo, frente a mi pantalla, no siempre veía lo que acababa de pasar.
Un pago podía recibirse correctamente, pero mi panel no me lo mostraba de forma evidente.
Una acción podía completarse, pero su estado quedaba oculto en una sección o detrás de una pantalla que no contaba toda la historia.
Y ahí me di cuenta de que no solo necesitaba un panel de administración.
Necesitaba un cockpit.
Ver antes de actuar
Un cockpit no es solo una colección de botones.
Es un lugar donde debes poder mirar la pantalla y entender inmediatamente qué está pasando.
¿Quién acaba de comprar? ¿Quién espera una acción de mi parte? ¿Quién necesita ayuda?
Y sobre todo: ¿pasó algo sin que yo lo viera?
A partir de ahí, dejé de pensar solo en términos de funciones. Empecé a pensar en términos de visibilidad.
Y de todo eso salió una regla simple:
Automático nunca significa invisible.
Si algo pasa automáticamente, igual debo poder verlo.
No para intervenir. Solo para saber.
El problema no siempre estaba en el motor
Esta es probablemente la parte más interesante.
Durante mucho tiempo, cuando algo parecía faltar, mi primer reflejo era pensar que había un bug en el recorrido.
Pero a veces, el recorrido funcionaba. Era simplemente el cockpit el que no me contaba lo que acababa de pasar.
Y esa diferencia cambia por completo la forma de trabajar.
Porque si crees que el motor está roto cuando solo la pantalla está mal, puedes pasar horas reparando algo que ya funciona.
Es exactamente el tipo de situación que hace perder muchísimo tiempo en un proyecto.
Así que empecé a simplificar.
Menos zonas ambiguas. Estados más claros. Información visible sin tener que escarbar. Botones de emergencia disponibles si los necesito.
Pero sobre todo, ya no hay que adivinar.
La prueba que realmente contaba
Una vez el cockpit puesto en orden, quedaba una sola forma de saber si todo eso realmente se sostenía.
Había que dejar de leer el código. Dejar de mirar pruebas parciales. Y hacer pasar a un verdadero cliente nuevo por todo el recorrido.
Preparé una máquina completamente nueva.
Nueva cuenta. Nueva instalación. Nuevo recorrido.
Y esta vez, miré el cockpit.
Cada paso aparecía en el momento correcto.
La cuenta. El pago. La máquina. Luego el resto del recorrido.
Y ahí, algo diferente ocurrió.
Ya no tenía que correr detrás del sistema.
El sistema avanzaba. Yo miraba.
El nivel correcto de automatización
No busco automatizarlo todo.
Hay ciertas decisiones que quiero mantener voluntariamente bajo control. Es una elección.
Pero todo lo que no me necesita debe poder avanzar sin mí. Y sobre todo, debo poder ver que avanza.
Ese matiz es lo que cambió mi forma de pensar LowFlow.
Antes, me preguntaba: ¿funciona?
Ahora, también me pregunto: ¿puedo comprobarlo en tres segundos?
Si la respuesta es no, el cockpit no está terminado.
El momento en que cambió
Al final de la prueba, el estado final apareció frente a mí.
ACTIVADA.
Y esta vez, esa palabra realmente significaba algo.
Porque acababa de ver todo el recorrido desarrollarse sin ninguna intervención oculta.
Sabía qué había pasado. Sabía dónde estaba el cliente. Sabía que ningún paso había sido salvado manualmente detrás del telón.
El cockpit y el sistema por fin contaban la misma historia.
Y para mí, ahí es probablemente donde LowFlow cambió de categoría.
Ya no era solo una herramienta que estaba construyendo.
Era un sistema que realmente podía pilotar.