Cómo nació Quantix: una promesa que comenzó desde el soporte

CÓMO NACIÓ QUANTIX: UNA PROMESA QUE COMENZÓ DESDE EL SOPORTE

Hay empresas que nacen alrededor de una mesa, después de meses de planificación, estudios de mercado y números. Quantix no nació así.

Mucho antes de tener un nombre, un logo o un producto, hubo una idea que comenzó a acompañarme mientras trabajaba dando soporte técnico para una empresa de desarrollo de software.

Recuerdo aquellos días con bastante claridad. El teléfono sonaba constantemente. Del otro lado había personas que necesitaban ayuda porque algo no funcionaba, porque no entendían un proceso o porque simplemente el sistema no les permitía continuar con su trabajo.

Atendíamos el problema, buscábamos una solución y seguíamos adelante. Hasta que el teléfono volvía a sonar. A veces era algo nuevo. Muchas veces era exactamente el mismo problema.

Era como apagar un incendio sabiendo que, tarde o temprano, comenzaría otro.

Quienes han trabajado en soporte probablemente conocen esa sensación. Hay algo particular en atender a una persona frustrada por un sistema que vos no diseñaste, pero que en ese momento te corresponde explicar, defender y hacer funcionar.

Y después de escuchar suficientes llamadas uno empieza a comprender algo importante: detrás de cada problema técnico hay una persona intentando hacer su trabajo.

Para nosotros puede ser un error, una validación que faltó, una excepción o una incidencia. Para el cliente puede significar no poder facturar, detener una operación, retrasar un pedido o tener a otra persona esperando frente a él.

Eso comenzó a cambiar mi manera de ver el software.

Con el tiempo dejé de preguntarme únicamente cómo resolver cada problema y empecé a hacerme otra pregunta:

¿Por qué este problema tuvo que llegar hasta soporte?

Esa pregunta terminó siendo mucho más importante de lo que imaginaba.

Porque comencé a darme cuenta de que muchas de aquellas llamadas podían evitarse. No eliminando el soporte. Siempre habrá situaciones en las que alguien necesite ayuda. Pero sí diseñando mejor desde el principio: creando procesos más claros, validando lo que debe validarse, pensando en lo que puede salir mal antes de que ocurra y haciendo que el sistema ayude al usuario a comprender lo que sucede, en lugar de obligarlo a levantar el teléfono.

Fue entonces cuando me hice una promesa:

“Si algún día tengo mi propia empresa de software, quiero hacer las cosas de otra manera.”

Todavía no existía Quantix. Ni siquiera sabía que algún día tendría ese nombre. Pero tenía claro algo: si alguna vez construía mis propios productos, no quería que nuestros clientes necesitaran tener a soporte a su lado para poder utilizarlos.

Siempre pensaba en aplicaciones que todos conocemos. Word. Excel.

Productos enormes, con una complejidad extraordinaria detrás, pero que millones de personas utilizan todos los días sin necesidad de comprender lo que ocurre internamente.

Uno abre Word y escribe. Uno abre Excel y trabaja.

Detrás existen años de ingeniería, millones de líneas de código y una enorme cantidad de decisiones técnicas. Pero el usuario no tiene por qué cargar con esa complejidad.

Con el tiempo entendí que ahí había una lección importante:

la buena ingeniería no consiste en mostrar lo difícil que fue construir algo. Consiste en conseguir que toda esa complejidad desaparezca detrás de una experiencia sencilla.

Esa idea se quedó conmigo durante años.

Y entonces apareció Hensell.

Él había vivido experiencias muy parecidas. También conocía esos problemas que se repiten, esos sistemas que terminan trasladando su complejidad al usuario y esa sensación de saber que muchas dificultades podían haberse evitado haciendo las cosas mejor desde el principio.

De repente, aquella convicción dejó de ser solamente mía. Habíamos llegado a conclusiones similares recorriendo caminos distintos.

Y cuando eso ocurre, llega un momento en que hablar de lo que debería cambiar ya no es suficiente. Había que construirlo.

Dos desarrolladores. Dos maneras de pensar. Muchas conversaciones. Muchas horas frente a una computadora. Errores. Pruebas. Cambios.

Ideas que parecían buenas y que después descubríamos que podían hacerse mejor.

Y poco a poco apareció una forma de trabajar que todavía nos acompaña:

no conformarnos simplemente con que algo funcione.

Porque conseguir que una función ejecute correctamente es apenas una parte del trabajo. Después vienen las preguntas importantes:

¿Es fácil de entender? ¿Tiene sentido para quien la va a utilizar? ¿Qué ocurre si el usuario hace algo que nosotros no esperábamos? ¿Podemos evitar que cometa un error? ¿Estamos resolviendo realmente su problema o simplemente trasladándole nuestra complejidad?

Y hay una pregunta que todavía me hago cuando revisamos nuestros productos:

¿Esto podría convertirse mañana en una llamada a soporte?

Si la respuesta es sí, probablemente todavía tenemos algo que mejorar.

Así comenzó a tomar forma Quantix.

No nació porque un día decidiéramos crear una empresa y después saliéramos a buscar algo que vender. Nació de muchos años observando problemas reales. De escuchar a usuarios frustrados. De ver errores repetirse. De preguntarnos una y otra vez si había una mejor manera de hacer las cosas.

Con el tiempo, aquella idea tuvo un nombre.

Quantix.

Y cuando miro hacia atrás, hay algo que comprendo mejor que entonces.

El soporte terminó siendo una de las mejores escuelas de desarrollo que pude tener. Me enseñó a mirar el software desde el otro lado de la pantalla. Me enseñó que detrás de un ticket no hay simplemente un número. Hay una persona.

Me enseñó que un error pequeño, cuando se repite cientos de veces, deja de ser pequeño. Y me enseñó que desarrollar software implica una responsabilidad que va mucho más allá de escribir código.

Por supuesto, no creemos en el software perfecto. Nosotros también nos equivocamos. Nuestros productos evolucionan. Encontramos cosas que podemos hacer mejor y volvemos sobre ellas.

Prometer que un sistema jamás tendrá un problema sería no comprender cómo funciona realmente el desarrollo de software.

Nuestra promesa es otra:

no acostumbrarnos a un problema que podamos solucionar desde su origen.

Si algo puede simplificarse, intentaremos simplificarlo. Si un error puede prevenirse, intentaremos prevenirlo. Y si encontramos una falla antes de que afecte a nuestros usuarios, habremos hecho bien nuestro trabajo.

Cuando alguien realmente necesite nuestra ayuda, queremos estar ahí. Pero nuestro objetivo nunca será que dependa permanentemente de nosotros para utilizar lo que construimos.

Queremos que la tecnología desaparezca detrás de lo que esa persona necesita hacer. Que pueda concentrarse en su trabajo. Y que el software simplemente cumpla su propósito.

HOY QUANTIX ES MÁS QUE AQUELLA IDEA INICIAL

La historia comenzó con Hensell y conmigo. Hoy Quantix es un equipo.

Personas distintas, conocimientos distintos y nuevas herramientas, pero una misma manera de entender el desarrollo de software.

Diseñamos productos y soluciones para problemas reales. Y nuestra forma de construir también ha evolucionado.

La automatización y la inteligencia artificial se han convertido en herramientas importantes dentro de nuestros procesos de ingeniería y aseguramiento de calidad.

No para sustituir el criterio de nuestros desarrolladores. Para ampliarlo.

Nos permiten revisar más escenarios, ejecutar pruebas repetidamente, detectar inconsistencias y encontrar posibles regresiones con una velocidad que sería difícil conseguir únicamente de forma manual.

Pero ninguna herramienta decide por nosotros qué significa que un producto esté listo. Esa responsabilidad sigue siendo humana.

Detrás de cada versión hay personas revisando, cuestionando resultados, tomando decisiones y haciéndose responsables de lo que construyen.

La tecnología nos permite ampliar nuestra capacidad. El criterio nos dice qué hacer con ella. Esa combinación forma parte de la manera en que trabajamos hoy.

Hensell y yo seguimos involucrados directamente en nuestros productos. Seguimos discutiendo cómo debería funcionar una característica. Seguimos encontrando cosas que podemos mejorar. Y seguimos aprendiendo.

Pero ahora esas conversaciones forman parte de algo más grande.

La calidad dejó de ser una preocupación de dos personas y se convirtió en una responsabilidad compartida por todo el equipo.

Y para nosotros existe algo que no debería cambiar aunque Quantix siga creciendo: que crecer no signifique bajar nuestros estándares. Que automatizar no signifique dejar de pensar. Que avanzar más rápido no signifique dejar de preguntarnos si lo que estamos construyendo realmente tiene sentido para quien va a utilizarlo.

Porque al final seguimos haciendo lo mismo que hacíamos cuando comenzamos: construir soluciones para personas.

Hoy tenemos mejores herramientas. Más experiencia. Más capacidad. Más productos. Y un equipo que continúa llevando adelante aquella forma de entender el software.

No sabemos qué tamaño tendrá Quantix dentro de algunos años. Tampoco necesitamos saberlo todavía.

Lo que sí sabemos es cómo queremos construirla.

Cuestionando. Probando. Corrigiendo. Aprendiendo.

Y procurando que cada versión sea mejor que la anterior.

Una decisión. Una prueba. Una mejora. Un producto a la vez.

Eso es Quantix.

Y apenas estamos comenzando.