S02E04 Ten o Low-Code

Dzień dobry, dobry wieczór. Witamy Cię w Draft Rozmowy. To podcast o biznesie, o życiu i o IT. Nie zawsze na poważnie, ale zawsze na serio. Do wysłuchania kolejnego odcinka zapraszają Cię Łukasz Falaciński, Michał Guzowski i Łukasz Zajączkowski. Cześć, witamy Was bardzo serdecznie w kolejnym odcinku naszego Draftu Podcastu, Draftu Rozmowy. Po raz kolejny się mylę, to coś musi oznaczać. Słuchajcie, pomyśleliśmy, że dzisiaj zrobimy mały wyjątek od naszych głębokich przemyśleń i różnych dziwnych dygresji i spróbujemy pogadać o rzeczach bardzo technicznych, a może nie bardzo technicznych, zobaczymy. Tematem dzisiejszego naszego spotkania będzie Low-Code. No i nie sposób nie zacząć od oczywistego pytania, z czym wam się kojarzy ten Low-Code i jaki to ma związek po prostu z kodowaniem.

Czyli jest to taki powiedzmy laik informatyczny, który jednak Nie boję się technologii i mam tyle w sobie takiej ciekawości, samozaparcia i logicznego myślenia, aby Zbudować nową funkcjonalność w programie. I to jest chyba najważniejsze, że są ludzie, którzy mają po prostu taką smykałkę. Jedni to robią, nie wiem, majsterkując, inni pisząc makro w Excelu. A Low-Code to jest taka odpowiedź właśnie dla tych osób, żeby wykorzystać ten potencjał w bardzo konkretnych biznesowych scenariuszach, wykorzystując narzędzia, które nie są zbyt skomplikowane. Ten próg wejścia, to jest chyba kolejna cecha, nie jest jakiś za duży. Czy jest? Moim zdaniem jest tak niski, jak jeszcze nigdy nie był w przyszłości.

No właśnie, o przyszłość. Zdając, że ty pamiętasz jakieś low-codowe... Przeszłość? Przeszłość, tak. Wyciągają mnie z formaliny i... Jakie jest pytanie o przeszłość? Ale gdy zaczynaliśmy z Sharepointem, bo low-code jest teraz takim buzzwordem, który jest Często powtarzane, ale to nie jest nowy pomysł. On już był próbowany. Najprostsze np. jakieś CMSy, czy jakiś WordPress, to już jest Low-Code tak naprawdę. Ja pamiętam gdzieś tam na początku. Pamiętasz InfoPafy na przykład? O Jezus. O mój Boże, pamiętam. Robiłem w tym aplikację. Sam koncept nie jest nowy po prostu. Nie powiem dla jakiej firmy, ale mogę powiedzieć, że obsługuje energię i gaz. No a to PowerAppsy. To, co ostatnio rozmawialiśmy, czyli nałożenie innego kolorku i nazwy na z dawniejszego CRM-a.

Może prostsze niż sobie wyobrażamy nawet dzisiaj. A tak de facto, no to jest to jakiś nowy sposób opakowania pomysłów, które już były i były trochę inaczej wykorzystywane. Ja sobie tak to wyobrażam. Taki infopuff nawet wspomniany. To już był wtedy szał, że my wszystko wyklikamy i nie trzeba będzie... Ten formularz już ma maski filtrowania, może tyle za nas sprawi zautomatyzować... I ogarnie nagrani. Tak. I w pewnym momencie, no ach, tego nie może, no to trzeba pisać. I też dochodzimy do tego, że te wszystkie... Chyba mieliśmy już taką rozmowę, czy to jest Low-Code, czy No-Code. Ale poczekaj, bo wspomniałeś o infopuffie, że on już był, to dlaczego się nie utrzymał, skoro był Low-Codem w sumie? A to może znasz z pola historię, nie wiem. To nie będzie historia infopafa. Moim zdaniem to, co się zmieniło, to to, że mamy coraz więcej standardów, że coraz więcej providerów dużych usług korzysta z podobnego sposobu implementowania swojego wszechświata.

I to, co kiedyś było niemożliwe, czyli zintegrowanie rozwiązania zrobionego w Microsoftcie, W prosty sposób, taki low-code'owy, z rozwiązaniem zrobionym przez innego prowajdera, to tego po prostu zrobić się nie dało. To była ściana. Po prostu te ściany się przestawiły troszeczkę dalej. Ale one cały czas też są, nawiązując do tego, co mówił Zając, że to oczywiście te rozwiązania low-code'owe są super, ale częsty błąd, jaki jest tutaj popełniany, tak mam wrażenie, że bardzo entuzjastycznie do nich podchodzimy, nie sprawdzając, gdzie są ich limity. Albo się naoglądamy, że w zasadzie w takim rozwiązaniu XYZ to mogę sobie zrobić ERP-a, a tutaj CRM-a, a tutaj obieg faktur. To jasne jest możliwe pod wieloma, wieloma założeniami, ale podpowiadając na to poprzednie pytanie, standardy moim zdaniem.

Czyli wcześniej nie było takiej standaryzacji tej warstwy komunikacyjnej, jaka jest teraz. Ja się pod tym absolutnie podpisuję. To pewnie jest konsekwencją z kolei pojawienia się chmury bardziej niż samego zmian w samym low-code. Oj, ale myślę też, że jednak bardzo dużo zrobiła otwartość, otwarty umysł i zmiany też na poziomie strategicznym takich organizacji jak Microsoft, który kiedyś powiedziałbym, że był trochę taką ślepą determinacją, próbował forsować swoje standardy, swoje podejście do jakichś tam różnych standardów. A po jakimś czasie zrozumieli, że nie ma co się kopać z koniem, zaczęli implementować cudze rozwiązania i gitara. Nie było z tego powodu tragedii, a nawet zyskali na tym. A jakieś przykłady? Bo mówimy, myślę, że dla kogoś, kto nie siedzi w Microsoftcie w tej technologii, to może się wydawać, że rzucamy jakimiś dziwnymi nazwami nie wiadomo czego, a takie bardziej przyziemne platformy Low-Code, które można by tak zaklasyfikować, które jest szansa, że zna szersze grono.

Może jakieś pomysły? No, my oczywiście siłą rzeczy w platformach Microsoftowych siedzimy, więc Microsoft PowerApps, Microsoft Power... A WordPress na przykład? Nie wydaje ci się, że można by go podciągnąć też pod taką... Absolutnie tak, absolutnie tak. Znaczy tych platform jest w ogóle multum. Na dobrą sprawę, jeżeli byśmy chcieli sobie podyskutować o tym, jakie są platformy low-code'owe czy no-code'owe, to moglibyśmy śmiało w ogóle zacząć od tego, że rynek low-code'owy jako taki. To jego wartość, ona diametralnie się zwiększa i jest to oczywiście odpowiedź na zapotrzebowanie, ale sam rynek był wyceniany na 46 miliardów dolarów w 2026 roku i podwoi się w przeciągu kolejnych dwóch lat. Co pokazuje właśnie ogromne ssanie. Mało tego, Gartner, duża taka firma zajmująca się, audytująca rynek, przedstawiła w jednym ze swoich raportów, że do 2025 roku 70% wszystkich nowych powstających aplikacji dla biznesu będzie oparta o Low-Code albo No-Code.

70%. I tutaj, jeżeli znowu mówimy o Low-Code, to musimy sobie zdać sprawę, że tych kategorii jest bardzo dużo, bo mamy zarówno takie webbuildery, czyli do budowania witryn www, mamy buildery do aplikacji, mamy jakieś narzędzia wewnętrzne, narzędzia do automatyzacji, do obsługi płatności, mamy narzędzia do analityki, mamy narzędzia do budowania formularzy. Proszę? RPA. RPA, tak, Robotic Process Automation, dokładnie. Więc tych kategorii jest mnóstwo i w każdej z tych kategorii mamy bardzo dużo, wiele rozwiązań, zarówno takich dużych organizacji jak Microsoft czy Google, ale również niezależnych, tak? Na przykład jeżeli mówimy o automatyzacji procesów, no to Microsoft ma Power Automata, Google tam, z tego co wiem, to rozpoczyna rozwój swojego upsheeta, żeby on poza aplikacjami robił też procesy, a na przykład niezależnymi, popularnymi narzędziami jest Integromat czy Zapier.

Albo IFTTT, proszę? IFTTT, dokładnie. Webbuildery to najpopularniejszym WordPress. A jeżeli byśmy chcieli sobie znowu wejść w świat Microsoftu, to mamy tutaj Sway'a albo SharePoint'a. No właśnie, więc jest duża szansa, że nawet jeżeli wcześniej nie spotkały się nasz drugi słuchaczu z tym terminem, To jest duża szansa, że korzystasz z tych narzędzi, bo one są tak powszechne i wszędzie wokół nas i patrząc na to, jak szybko rosną zapotrzebowania, nie tylko biznesu, jak szybko trzeba te nowe funkcje, aplikacje wdrażać, to jest nie do uniknięcia, to co powiedziałeś, te 70% rozwiązań, które gdzieś tam Low-Code wykorzystują, bo to też, moim zdaniem, tak na marginesie ważna rzecz, że to nie jest tak, że musimy

Wszystko robić low-codowo i koniec, tak? I się na to zamykać. Jak najbardziej gdzieś tam te rozwiązania pisane mogą być fajnym uzupełnieniem. To jak najbardziej tak może być. A zmieniając kontekst, patrzę na zająca. Dla kogo jest ten low-code? Kto byłby takim idealnym kandydatem? Nie, nie, mam na myśli ciebie. A kto by się dobrze odnalazł w takich technologiach jak citizen developer? Heavy user. Czyli ktoś, kto zna dobrze środowisko, w którym siedzi i zaczyna mieć zrozumienie głębszych potrzeb. Wyobrażam sobie dowolną osobę w biznesie, która korzysta z jakiejś aplikacji mocno. Na przykład siedzę mocno w CRM, siedzę mocno w fakturach, siedzę mocno w Excelu, znam proces.

Znam proces i narzędzie. Zacznę moim zdaniem. Ja sobie tak wyobrażam idealną osobę, bo znajomość narzędzia dobra też pokazuje, że ja chcę i umiem No umówmy się, jak ktoś umie dobrze Excela, to nieważne czy jest informatykiem, deweloperem, czy nie ma nazwy, to znaczy, że naprawdę ogarnia Excel, jest olbrzymi. Jak znamy jakikolwiek system dobrze, to pewnie umiem się je nauczyć. Jak to od strony informatycznej, nie mówimy o trzewiach, bo to warstwa Low-Code, jak dla mnie, to nie trzeba rozumieć wszystkiego pod spodem, wystarczy rozumieć moduły, puzzle, z których to się składa. To taka osoba plus znajomość biznesu, czyli osoba najbliżej i najgłębiej w procesie i w technologii, która ten proces obsługuje. Tak sobie to wyobrażam.

My to zauważamy z pierwszej ręki, że coraz więcej osób szuka swojego miejsca na rynku pracy. Jedzą w jakichś takich typowych biznesowych działach i z jednej strony szkoły, bootcampy, jakieś deweloperskie, a ludzie skuszeni perspektywami niesamowitych zarobków. To się dzieje wokół nas. Jak to ma się do Low-Code? Czy to jest jakaś alternatywa, uzupełnienie, realna ścieżka rozwoju, kariery? Dobrze to nazwałeś, realna ścieżka rozwoju, bo ja niestety często widzę przypadki, gdzie np. człowiek, który przez całe życie siedział w jakiejś branży finansowej, czy jakiejś marketingu, czy gdzieś, nagle wchodzi w świat Pythona, robiąc sobie kurs Pythonowy, bo Python jest teraz najbardziej sexy, Więc uczy się tego i myśli, że po roku będzie normalnie takim regular devem, który będzie zarabiał 15k na rękę.

Albo Java. Albo Java, tak? Nie, Python jest teraz absolutnie na topie, bo możesz i aplikacji, i analitykę, i tam wszystko, o Jezu. A prawda jest taka, że jak masz już wiele doświadczenia w jakiejś branży, to takie zupełne wychodzenie z niej To jest trochę jakby nieszanowanie swojego doświadczenia i czasu, jaki spędziłeś w tej branży i jaki poświęciłeś na poznanie procesu, więc dużo lepiej byłoby, gdybyś jednak skupił się na przykład na technologii, która jest prostsza w rozpoznaniu, ale z kolei bardziej wymaga tej znajomości merytorycznej, tej branżowej, czyli na przykład jak jesteś Pythonowcem, no to zanim zaczniesz robić te swoje aplikacje dla marketingu, powiedzmy, bo jesteś po marketingu, no to minie parę lat, ale jak jesteś Po marketingu i dodatkowo byś wszedł w technologie low-code'owe do, nie wiem, automatyzacji procesów w marketingu czy budowania aplikacji dla marketingu, to jesteś w stanie w sześć miesięcy stać się normalnie już takim regular deweloperem, który jest w stanie, czy regular citizen deweloperem, który jest w stanie te rozwiązania budować niejednokrotnie znacznie sprawniej niż taki

Zwykły deweloper. Czyli reasumując, to nie tylko rozwiązania powstają szybciej, ale też łatwiej zaadoptować te narzędzia po prostu od strony i twórcy. A jak to jest, no bo po coś te rozwiązania robimy, niezależnie czy to będzie właśnie jakieś rozwiązanie w Pythonie wyrzeźbione, czy jakiejś innej technologii, czy w Low-Code, to jednak robimy to dla biznesu, dla kogoś. Oczywiście biznes to jest uogólnieniem. Dla odbiorców. Z ich perspektywy to ma znaczenie? Czy czymś się różnią te rozwiązania low-code'owe od tych takich customowych? No to jak jeździcie się dobrze samochodem, to nie pytasz jak on był zrobiony. Dokładnie. Znaczy, one się niczym nie różnią. Aplikacja wygląda jak aplikacja, a czy ona jest była budowania Low-Code? No tak jak wiesz, strona Wordpressowa, nie wiesz, czy ona jest... Mi to super pięknie, no bo z jednej strony mamy technologię, która pozwala wszystko zrobić szybciej.

Łatwiej jest wyszkolić, wyprodukować sobie ludzi albo nawet znaleźć, tak? Bo to też jest ciekawa ścieżka. Można po prostu takich ludzi poszukać w swojej organizacji, którzy coś takiego mogliby zrobić. No to gdzie jest haczyk? Haczyk jest na pewno w pewnych ograniczeniach tych platform. Ponieważ to jest Low-Code, to jest troszeczkę jak z klockami LEGO, gdzie klocki LEGO mają pewien już swój zdefiniowany kształt. I owszem, z nich możemy robić najróżniejsze, Bardzo skomplikowane budowle, ale jeżeli chcemy zejść jeszcze poziom niżej, to nie możemy, nie wiem, podzielić klocka na pół. On jest niepodzielny, to jest atomowa część. Programując tak w standardowy sposób, jesteśmy w stanie każdy klocek dowolny zbudować, wymyślić i zbudować. W Low-Code takiej możliwości nie mamy. Są pewne ograniczenia, plus często jest to związane z jakimiś opłatami licencyjnymi.

Wiele platform posiada opcje darmowe, ale tam znowu ograniczone tym, że np. na Flowach to macie jakieś tam, nie wiem, maksymalnie 6 minut na odpalenie, powiedzmy. Różnie. No właśnie, kasa, bo to też jest pewnie na początku w ogóle wyboru rozwiązania czy ścieżki, w którą idziemy, żeby dowieźć jakąś funkcję. No to kluczowa sprawa. Wiele osób sądzi, że i według mnie to nie jest takie proste i prawdziwe, że Low-Code skoro jest prostszy i szybszy, to musi być tańszy. Czy to zawsze jest tańsze? Nie, wiemy, że nie jest tańsze. To kiedy jest droższe? Tutaj wydaje mi się, że Low-Code staje się droższy w szczególności wtedy, kiedy zaczyna być albo bardzo, bardzo duży i finalnie rzeczywiście opłacałoby się to bardziej przenieść na niezależną platformę, w sensie normalnie to zbudować jakimś tam Pythonem właśnie, albo wtedy, kiedy korzystamy z jego zbyt mało wolumenowo, czyli np. płacimy za licencję dającą nam, nie wiem,

100 flowów do wykorzystania, a wykorzystujemy 2. Opłacimy ze 100. Opłacimy ze 100. No właśnie, bo to chyba wszystko się sprowadza do tego, że to bywa droższe, jak nie dopasujemy tego rozwiązania do modelu licencyjnego, bo to jest coś, co w każdym jakimś rozwiązaniu low-code'owym występuje, że jest pewna zawiła matematyka, wiem, że Zając się zajmuje licencjami, więc wie, jak to jest skomplikowane, którą trzeba rozwikłać w przypadku takiego budowanego rozwiązania. Bywa łatwiej, bo Mnożymy MD-e czy tam godziny tego dewelopera i dostajemy coś, jeżeli robimy to oczywiście dla siebie. No chyba i to i to podejście jest obarczone, inaczej, ma perspektywy błędów. No bo nawet jak piszemy apkę, to możemy po pierwsze niedoszacować, po drugie może się przeciągnąć projekt, po trzecie nie weźmiemy pod uwagę, co jest dość istotne, obsługi administracyjnej, bo potem rzadko umiemy to sami obsługiwać, jak ktoś nam napisał.

Koszty serwerów, wiesz, i tak można pomylić się faktycznie, jak to Prawda jest taka, jak źle te koszty policzymy, to nam wyjdzie zły wynik, będziemy zaskoczeni, że to dużo kosztuje. Ale przy dobrym liczeniu, to trudno mi kosztów licencyjnych, to trudno mi sobie wyobrazić, gdzie to jest droższe. Przez to, że to jednak z założenia, mówię o Low-Code, versus kodowanie od zera. Kodowanie od zera, jak ktoś mówi, że wszystko można, to właściwie ma rację. W Low-Code możemy od razu powiedzieć, że będą pewne ograniczenia, gdzieś daleko, ale będą. Też sobie trudno powiedzieć jakie, bo to bardzo zależy... Ale gdzieś tam wiemy, że gdybyśmy byli w stanie wymyślić, że one będą, to przez ten bufor, tę różnicę Low-Code jest tańszy. Przy obu podejściach, dobrze obliczonych kosztowo, to Low-Code musi być trochę tańszy, bo on nie dotknie wszystkich rzeczy.

Tylko pytanie, czy tu, nawet już nie mówię o zasady Pareto, czy faktycznie potrzebujemy 100% wszystkiego, a życie pokazuje, że nie, Nawet my się w pewnym momencie, z Falą mieliśmy taką rozmowę, jak na początku wszystko kodowaliśmy, gdzie z kodowania zrobić low-code, ale chodzi o mindset, gdzie powiedzieć, że już nie da się. Chociażby się dało, tylko po co? Lepiej zrobić tego mniej w module low-codowym, w cudzysłowie, żeby ograniczyć te ciągłe potrzeby, które w pewnym momencie są koncertem życzeń, bo jak się spyta kogoś, czy on to chce, to on ci odpowie, nie wiedząc o co chodzi, że on to chce. Bo lepiej mieć więcej. Jakby cię spytali, czy pana samochód miałby mieć to, to już nieważne, co jest po tym, co ja powiedziałem, to ty już to chcesz. Jak to jest w cenie, no pewnie, że ja to chcę.

I wystarczy popatrzeć na rosyjskie przeróbki samochodów tuningowane w internecie. Spoiler, większe od samochodu. Ciekawe pytanie, kiedy jest droższe? Nie umiem sobie tego wyobrazić, ale może po prostu mam za małe doświadczenie. Ja bym na pewno powiedział jeszcze jedną rzecz, którą trochę wspominałem wcześniej, ale ugryzę temat od innej strony, to znaczy warto też pamiętać o tym, kiedy nawet jak podnosimy pewne koszty związane z Low-Codem, to kiedy te koszty zaczynają maleć. Czyli na przykład zaczynają maleć wraz ze skalą. Im więcej zaczynamy używać tych rozwiązań, na przykład budujemy nie dwie aplikacje, a 20 aplikacji, a to wcale nie jest dużo, jak wiemy, są instalacje i po 100 aplikacji low-code'owych w organizacji, to te koszty się bardzo rozkładają.

Ale to też jest ważna rzecz, właśnie te licencje. Te koszty będą zawsze liniowo związane z ilością licencji, a to niekoniecznie musi oznaczać ilość użytkowników. Więc tutaj ta korelacja jest zawsze stała. W przypadku tych customowych rozwiązań na ogół, oczywiście są zawsze jakieś stałe koszty związane z utrzymaniem, ale to czy obecna technologia, czy to będzie 100 użytkowników, czy 100 tysięcy, no to jest czasami przesunięcie jakiegoś tam suwaczka. No to prawda. Więc wydaje mi się, że Low-Code, tutaj często popełniany błąd polega na tym, że jest właśnie traktowany jako taki prosty, także na tym etapie koncepcyjnym i planowania, bo chyba się zgodzicie, że to do zasady ten proces wytworzenia tego rozwiązania w obu podejściach jest bardzo podobny.

Ale to też jeszcze trzymając się tych licencji, my mamy często w praktyce sytuacje, kiedy klient już za to zapłacił. A, to jest bardzo ciekawy przypadek, tak, masz rację, słusznie. Mówimy o sytuacji, w której na przykład posiadamy już ten Low-Code, a my go nawet nie wiemy, że go posiadamy. Tak, drodzy Państwo, licencję macie, płacicie już od roku, można zrobić to, to i to. Podpowiem konkretnie, że chodzi o FISA 365, gdzie PowerApps, Power Automate, te rozwiązania już są, więc jeżeli posiadacie takie subskrypcje, Dowolna licencja Office 365 posiada pełen zestaw narzędzi low-code'owych do budowania stron, do automatyzacji, do budowania aplikacji. Co to za rozwiązania? Co do rozwiązania, macie w licencji Office'a 3.5 Teamsy, macie SharePoint'a online, macie Power Automata, macie Power Apps'y, macie Power BI'a, macie Power Virtual Agent.

Power-ups. Żegnaj. Ale to, co ważne jest, żeby dodać, to jest, że mając dostęp do kursu, dostajecie dostęp do grupy i na tej grupie te wszystkie przykłady są opublikowywane. Wkurzacie sąsiad, power up. Ja go nie wyciszę do końca. Tak jest. Dobra, myślę, że czas na draft. Low-Code, Low-Code. Draft wokół Low-Code będzie następujący. Trochę bez szydery, nieprześmiewczy. Spróbujmy wskazać Waszym zdaniem takie top 5, ale wiecie, to ma być naprawdę takie najlepsze Waszym zdaniem, czy najlepszych kandydatów. Na aplikację zrobioną w Low-Code, którą każda organizacja powinna wdrożyć.

Tylko tutaj założenia. Co oznacza Low-Code? Do wyklikania w miesiąc przez jedną osobę. Nie wymyślałem tam ERP-ów, wiecie, i systemu do zarządzania wszechświatem. Proste rozwiązania, takie low-hanging fruits, jak mówiąc po staropolsku, po które warto sięgnąć, jeżeli zorientowałem się na przykład, że o, mam power-upsy, to co z tym zrobić? Okej. I nie powtarzamy swoich. Tak, tu jest duża szansa właśnie. Dobra, kto zaczyna? No to powinniśmy losować, bo to w sumie ważne, kto zaczyna. Dobra, mogę zaczynać. Pewnie i tak nie macie mojego. Dobra, kto chce mieć złoto olimpijskie, mogę wziąć. Proszę. Dobrze, ja mogę być drugi, skoro losuję. Który chcesz być, Łukasz? Ja to montuję i tak będę pierwszy. No dobrze, to moja pierwsza propozycja to jest bardzo ciekawy przykład, który namierzyłem na projekcie u jednego z klientów.

Są generatory. S02E04 Ten o Low-Code Nie wiem, może źle zrozumiałem, że mamy te najbardziej znane wybrać, więc i tak one będą. Tak, ja to rozumiem. Wszystkie, które podamy, to prawdopodobnie znajdę ze trzech konkurentów na rynku i mogę kupić to. Myślałem o takim, którym bym był sam w stanie wyklikać według swoich potrzeb. A nie mam gotowego rozumienia. Nie wybieram gotowego, bo pewnie ono jest. Okej. No dobra, to ja na pierwszy rzut zrobiłbym rozliczanie różnego rodzaju wydatków.