Servicio ≠ experiencia. Las herramientas no definen la competencia

A veces una situación dice más de lo que parece.

Es lo que pasa cuando se confunde un servicio con experiencia y una herramienta con competencia.

En un proyecto teníamos una plataforma analítica que parecía y funcionaba casi como Power BI. No por copiarla. El producto estaba tan protegido que no se permitía ningún servicio externo. El equipo construyó un módulo BI propio: backend e infraestructura separados, pero la misma lógica, estructura y comportamiento de Power BI.

Los principios eran idénticos. Y con eso entiendes el mecanismo.

Después, en una entrevista, me preguntaron por Power BI. Respondí con honestidad: sí había trabajado con él, pero no de forma nativa en macOS. No había un soporte adecuado para Mac, así que entraba por RDP en Windows y allí construí mis primeros modelos y visualizaciones.

Era un rodeo. Pero me dio lo importante: entender la lógica, la estructura de datos y cómo piensa la herramienta.

Vi la reacción del reclutador al instante. Como una marca roja: «lo ha usado, pero no el servicio correcto; punto menos». Expliqué principios, modelado, tipos de visualización y experiencia práctica. Nada cambió.

El nombre del servicio pesó más que la comprensión. La herramienta importaba más que la experiencia.

El problema no lo veo en el reclutador, sino en la forma de pensar que sostiene el proceso.

Quien entiende análisis de datos, modelos y comportamiento de sistemas puede hacerse con un servicio concreto en una hora. Quien conoce Jira aprenderá Monday o ClickUp sin dramas.

Una herramienta es una interfaz. El conocimiento es una forma de pensar.

Una empresa que evalúa por nombres de herramientas en lugar de por comprensión se fabrica su propio riesgo. Los proyectos no fracasan porque alguien no sepa pulsar un botón. Fracasan cuando nadie ve estructura, causas y esencia.