Usługa ≠ wiedza. Dlaczego narzędzie nie definiuje kompetencji

Czasem sytuacja mówi więcej, niż się wydaje.

O tym, jak usługę bierze się za wiedzę, a narzędzie za kompetencje.

W jednym z moich projektów mieliśmy analitykę wyglądającą i działającą niemal jak Power BI. Nie dlatego, że kopiowaliśmy. Produkt był tak chroniony, że nie wolno było używać zewnętrznych usług. Zespół zbudował więc własny moduł BI: osobny backend, osobna infrastruktura, ale ta sama logika, struktura i zachowanie co w Power BI.

Zasady były identyczne. To wystarczy, żeby rozumieć mechanizm.

Później na rozmowie zapytano mnie o Power BI. Odpowiedziałem uczciwie: pracowałem, ale nie natywnie na macOS. Brakowało porządnego wsparcia dla Maca, więc przez RDP wchodziłem do Windowsa i tam tworzyłem pierwsze modele oraz wizualizacje.

Obejście? Tak. Dało mi jednak to, co istotne: rozumienie logiki, struktury danych i sposobu myślenia narzędzia.

Od razu zobaczyłem reakcję rekrutera. Jak czerwona adnotacja: „używał, ale nie właściwej usługi, więc minus”. Wyjaśniłem zasady, modelowanie, typy wizualizacji i praktykę. Nic się nie zmieniło.

Nazwa usługi ważyła więcej niż rozumienie. Narzędzie liczyło się bardziej niż kompetencje.

Problem widzę nie w rekruterze, lecz w myśleniu stojącym za procesem.

Kto rozumie analizę danych, strukturę modeli i zachowanie systemów, konkretną usługę opanuje w godzinę. Kto zna Jirę, ogarnie Monday czy ClickUp bez dramatu.

Narzędzie jest interfejsem. Wiedza jest sposobem myślenia.

Firma oceniająca ludzi po nazwie narzędzia zamiast głębi rozumienia tworzy ryzyko dla siebie. Projekty nie padają dlatego, że ktoś nie zna jednego przycisku. Padają, gdy nikt nie widzi struktury, przyczyn i istoty.