VBA, mimo podeszłego wieku, wciąż wywołuje wiele kontrowersji. Sporo osób wieściło mu rychły koniec już kilkanaście lat temu, inni zaś zaciekle go bronią do dzisiaj. Faktem jest, że w wielu firmach wciąż używa się z powodzeniem narzędzi opartych na makrach. Co więcej, Microsoft nie kwapi się specjalnie z usunięciem tego języka z pakietu Office. Z drugiej strony, od wielu lat go nie ulepsza, stawiając na narzędzia POWER i rozwiązania AI. Czy VBA jest zwinnym kotem mającym siedem żyć czy kulą u nogi giganta z Redmond?
PRAWDY
Przyjrzyjmy się najpierw wszystkim tezom, które w mojej opinii, są prawdziwe.
Firmy mało wiedzą o VBA
W przypadku VBA mamy do czynienia z jawnym paradoksem…
Z jednej strony „czas to pieniądz”, więc każda mądra firma z definicji będzie usprawniać powtarzalne procesy. Co więcej, te potrzeby automatyzacji widać gołym okiem, i to na wielu płaszczyznach.
Moda modą, ale codzienne realia znacznie odbiegają od lansowanego przez management wizerunku w social mediach (sorry LinkedIn 😉). Rutynowa harówka z pewnością nie jest sexy – to „brudna robota”, która nuży i frustruje. Najlepiej więc ją ograniczyć do minimum.
Z drugiej strony, Excel jest wszędzie. On lub jego tańszy substytut. Każdy pracownik coś „rzeźbi”, ale rzadko wykorzystuje do tego celu makra. I nie chodzi tu bynajmniej o ograniczenia nakładane przez IT. Problemem jest brak wiedzy na temat możliwości VBA, mimo, że technologia ta jest obecna na rynku od 30 lat. Wciąż pokutuje przekonanie, że makra to wiedza dla wtajemniczonych. Efekt jest taki, że w firmach, zamiast profesjonalnych aplikacji, często przeważają rozwiązania niewydajne, zrobione ad-hoc. Inna sprawa, że na rynku nie ma kursów, które pokazywałyby jak tworzyć aplikacje biznesowe w VBA.
Automatyzacje to ciężki kawałek chleba
Ale nie tylko firmy odpowiadają za istniejący stan rzeczy. Część przedsiębiorstw zwyczajnie mogła się zrazić do rozwiązań opartych na VBA.
Dość częstym przypadkiem, z którym spotykałem się w korporacjach było przymuszanie pracowników biurowych do tworzenia automatyzacji w Excelu. Po prostu, był człowiek, który „liznął” trochę VBA i „w nagrodę” został oddelegowany do utworzenia narzędzia, lub rzadziej – sam chciał usprawnić pracę działu. Biorąc pod uwagę przeładowanie tych ludzi i specyfikę aplikacji VBA, był to gotowy przepis na katastrofę!
Niestety efekt końcowy był łatwy do przewidzenia. Sfrustrowany pracownik nie wyrabiał z natłokiem zadań i zwalniał się. Co gorsza, często w złej atmosferze, włączając w to celowe blokowanie dostępu do aplikacji… Sam musiałem kilka razy takie hasła złamać po to, aby … napisać całą aplikację od nowa.
Na szczęście, od kilku lat dużo zmieniło się na plus. Pracownicy nie chcą już brać się za automatyzacje, bo wiedzą czym to grozi. Wolą zlecić takie narzędzie komuś z zewnątrz, z czego ja np. skwapliwie korzystam.
Projekty VBA uzależniają od twórcy
To jeden z częściej podnoszonych argumentów i jest w dużej mierze prawdziwy.
Aplikacje VBA nie są tworzone przez Software House – raczej przez pojedynczych developerów lub małą firmę. Oznacza to, że Klient jest w dużej mierze uzależniony od wykonawcy. Nawet jeżeli aplikacja zostanie wdrożona, a pracownicy przeszkoleni z obsługi, to chcąc wykonać jakąś istotną aktualizację, trzeba napisać do osoby, która to narzędzie wykonała. Wszystko sprowadza się więc do zaufania pomiędzy Klientem, a programistą.
W lipcu 2023r. mogłem wykonać przysłowiowy „strzał życia”… Korporacja, z którą współpracuję od 15 lat wdrażała nowy system na Zakładzie – SAP S/4HANA Cloud. Niezbędne było zaktualizowanie aplikacji do złomowania, którą obsługuje ok. 80 osób. Zlecenie miało priorytet krytyczny, ponieważ brak aktualizacji wiązałby się ze wstrzymaniem produkcji i drakońskimi karami za opóźnienia.
Nie postawiłem swojego Klienta pod ścianą, nie szantażowałem go. Zwiększyliśmy tylko stawkę o 2/3 za pracę po godzinach i w weekendy. W dwa tygodnie udało nam się wdrożyć nową wersję aplikacji. Na kilka dni przed GO-LIVE zamknęliśmy pomyślnie temat, a wielu osobom spadł kamień z serca.
Mogłem podać cenę zaporową i dostać 10x więcej za to zlecenie, ale mój Klient mógłby na tym etapie zakończyć naszą wieloletnią współpracę. Uznałem, że nie warto tego robić, chociaż mam świadomość, że taka okazja może się już więcej nie powtórzyć…
Klienci często są zachwyceni efektem
W dobie wodotrysków, gdzie króluje przerost formy nad treścią, formularze VBA wyglądają dość archaicznie. Pamiętajmy bowiem, że wygląd kontrolek nie zmienił się od lat 90-tych!
Nigdy jednak nie słyszałem ani jednej uwagi na ten temat! Wręcz przeciwnie, Klienci bardzo często są zachwyceni tym, że takie ładne okna można zrobić w Excelu. Prawda, że dają radę nawet w 2024? 😉
Najbardziej cieszy ich to, że aplikacja jest dopasowana pod ich biznes. Już na etapie wysyłki screenów dostaję bardzo pozytywny feedback, który jeszcze wzmacnia się po tym, gdy Klient przeklika się przez interfejs. Osobiście bardzo lubię takie spotkania, lubię pracować Agile.
Ale strona frontendowa, to nie jedyna rzecz, która spotyka się z zachwytem. Klienci często są zdumieni tym, że kod może działać tak szybko i stabilnie. Coś co zajmowało kiedyś kilka dni, teraz można wykonać w kilka sekund. Na tym polega właśnie potęga VBA i automatyzacji!
Aplikacje VBA są relatywnie tanie
Pomimo tego, że aplikacje VBA są względnie tanie (wobec np. aplikacji mobilnych), to spora część Klientów wciąż nie traktuje ich w kategoriach projektów IT. Percepcja zmienia się dopiero wtedy, gdy zaczynamy razem pracować. Zwykle jest spore zdziwienie, że taki projekt angażuje aż tyle czasu i energii.
Małe projekty zwykle do mnie nie trafiają, ponieważ zainteresowany jest w stanie znaleźć ludzi, którzy w ramach pomocy na forum czy grupie FB, pomogą mu za darmo. Osobiście uważam to za psucie rynku.
Trafiają do mnie duże projekty, ale skrajnie różni Klienci. Są tacy, którzy mają budżet 3 500zł na kombajn (sorki – 3 800zł), ale też tacy, którzy wydali 80 000zł i w ramach wdzięczności wysłali mi jeszcze paczkę na koniec współpracy.
Uważam, że to fajna kwota, ale wciąż nijak ma się do aplikacji mobilnych, gdzie za wersję podstawową MVP trzeba zapłacić dwa razy tyle. Biorąc pod uwagę relację kosztu i ryzyka do jakości rozwiązania – aplikacja VBA jest moim zdaniem, wciąż bardzo dobrym wyborem.
MITY
Przyjrzyjmy się teraz tezom, które w mojej opinii, są fałszywe, a wręcz szkodliwe.
AI zrobi każdą automatyzację
Świat zwariował na punkcie sztucznej inteligencji. Największe Firmy inwestują krocie w rozwój tej technologii, zaś sieć zalała fala szkoleń. Niektórzy twierdzą, że „sztuczna inteligencja urodzi więcej milionerów niż odkrycie ropy naftowej”. Czas pokaże, ja akurat widzę tu więcej zagrożeń niż korzyści np. możliwość preparowania dowodów wejdzie na całkiem inny poziom.
Czy boję się, że rozwój AI zabierze mi pracę? Absolutnie NIE! Powody są dwa.
Po pierwsze, automatyzacje Excel zawsze przewidują jakiś czynnik ludzki. Nie są to „roboty”, które działają całkowicie bez ingerencji człowieka. Bardziej przypomina to pracę urządzeń AGD, gdzie najpierw musimy wprowadzić ustawienia, aby uruchomić program. Po drugie, VBA jest ogromnie kontekstowe. Czat GPT nie będzie w stanie napisać kodu, dopasowanego pod specyficzny przypadek np. utworzenia druków firmowych. Nie zaprojektuje też userformów.
Praca nad aplikacją VBA to ciągła burza mózgu, która wymaga maksymalnego skupienia i ciszy. Poziom szczegółów jest tak duży, że wystarczy, że ktoś nas wybije z rytmu i tego dnia możemy już nie wrócić do pracy przy projekcie.
Narzędzia POWER dają większe możliwości
Drugi szkodliwy mit jest rozpowszechniany przez osoby, które słabo znają Excela. Twierdzą one, że nauka VBA nie ma sensu w kontekście rosnącej ekspansji narzędzi POWER. Błąd poznawczy polega na tym, że takie osoby traktują te narzędzia jako bardziej nowoczesną alternatywę dla VBA, podczas gdy te technologie wzajemnie się uzupełniają.
Owszem, Power Query mocno usprawniło cały proces ETL, Power Pivot rozbudowało możliwości tabel przestawnych (i wstrzymało rozwój Accessa), zaś dzięki Power BI możemy wejść na inny poziom tworzenia i dystrybucji dashboardów. To są istotne dobrodziejstwa i zwłaszcza PQ idzie w parze z VBA. Automatyzacja procesów to jednak inna dziedzina niż analiza danych, przede wszystkim – znacznie szersza.
Reasumując. Każdą z moich aplikacji potrafiłbym wykonać tylko dzięki VBA – bez VBA nie zrobiłbym żadnej.
A tak dla przypomnienia – w tym artykule opisuję czego nie zrobi PQ, a zrobi VBA.
VBA działa wolno i topornie
Kolejna bardzo krzywdząca opinia, która wynika z niewiedzy.
Sporo osób przygodę z makrami zaczyna od rejestratora makr, co jest złym pomysłem. Nagrany kod jest nadmiarowy i nieoptymalny. Po pierwsze, rejestruje on nie tylko nasze ruchy, ale robi pewien „printscreen” obiektu z wypisaną listą wszystkich właściwości i ich wartości. Po drugie, rejestruje on każdą zmianę zaznaczenia, co akurat jest logiczne z punktu widzenia nagrywania naszych akcji. Ale w VBA możemy edytować komórki bez ich wcześniejszego zaznaczania, co istotnie zwiększa szybkość skryptu… Niestety nagrany kod często jest podstawą całej „automatyzacji”, co przekłada się na negatywne stereotypy dotyczące VBA.
W VBA, podobnie jak w Excelu, zadanie możemy wykonać na wiele sposobów. Możemy napisać makro, które będzie działało np. 120 sekund, ale też takie, które wykona całą operację w niecałą sekundę. W dobrych kursach VBA mamy zwykle moduł, który porównuje metody powolne z optymalnymi. Warto w ten sposób podchodzić do nauki – patrzeć krytycznie i nie zadowalać się półśrodkami.
Wycena projektów jest opłacalna
Zawsze dąż do tego, aby rozliczać się na zasadzie stawki godzinowej, ale poznaj wcześniej budżet Klienta.
Automatyzacje VBA są klasycznym przykładem tego, że projekty IT rządzą się swoimi prawami. W przeciwieństwie np. do robót budowlanych, nie można tutaj zastosować metodyki Waterfall. Prace nad backendem i frontendem ciągle się mieszają, a ścisłe trzymanie się planu praktycznie się nie zdarza. Projekty rozrastają się w sposób naturalny, ale też pojawiają się obszary, które nagle stają się priorytetem w backlogu. Wszystko jest tutaj dynamiczne i wymaga ciągłej interakcji z Klientem.
Wycena projektu połączona z niskim budżetem to gwarancja tarć, a w skrajnym przypadku – zerwania współpracy. To jest też główny powód, dla którego trenerzy Excela nie chcą się bawić w robienie plików.
Automatyzacje Excel potrafią się rozrosnąć nawet kilkukrotnie względem przyjętej na starcie specyfikacji. To tak jakby kafelkarz umówił się na zrobienie łazienki, ale w praktyce musiał wykonać aż cztery w tej samej cenie!… Oczywiście zapłata jest przewidziana dopiero po odbiorze dzieła… Kto na to pójdzie?
Zdecydowanie trzeba tutaj dążyć do współpracy opartej na wartościach Agile – adaptacji, inspekcji i transparentności. Osobiście uwielbiam tak pracować i zwykle przy takich projektach mam stan flow.
Umiejętności miękkie nie są ważne
„Nie po to szedłem na informatykę, aby pracować z ludźmi”. Bawi mnie ten tekst, chociaż pod fasadą żartu, kryje się jakiś większy lęk społeczny.
Działy IT w firmach to wciąż często „państwo w państwie”. Nierzadko to introwertycy, których ciężko o cokolwiek się doprosić. Mają opinie „żyjących w swoim świecie”, „przemądrzałych” i „nierozumiejących ludzi i biznesu”. To są stereotypy, które skądś się wzięły 😉.
Rozwój Agile wymusił na programistach otwarcie się na kompetencje miękkie, komunikatywność i pracę w grupie. To już nie działa tak jak w latach 90, gdzie Klient spotykał się z IT tylko na starcie projektu (aby przedstawić specyfikację) oraz na końcu (aby odebrać dzieło). Świat zmienia się bardzo dynamicznie i aby dowieźć Klientowi satysfakcjonujący wynik, trzeba się z nim na bieżąco komunikować. W przypadku VBA, nic nie zastąpi spotkań face-to-face, gdzie Klient może sobie przeklikać całą aplikację.
Z tego punktu widzenia, warto postawić na otwartość i feedback. Oprócz umiejętności stricte technicznych, warto rozwijać kompetencje miękkie. Tylko w ten sposób będziemy mogli dostarczać przyrost, a w konsekwencji stworzyć produkt zgodny z oczekiwaniem Klienta.
