Transkrypcja
Dziś moim gościem jest Jacek Zawadzki. Jacek opowie nam o narzędziach typu no-code oraz low-code, którym ufają duże organizacje i dzięki nim usprawniają swój biznes. Jacku, dziękuję, że przyjąłeś moje zaproszenie na rozmowę.
Cześć Mateusz, dzięki bardzo. Witam wszystkich słuchaczy serdecznie i mam nadzieję, że będzie ciekawie.
Myślę, że będzie bardzo ciekawie. Chwilę sobie porozmawialiśmy przed nagraniem i myślę, że temat bardzo interesujący. Ale zanim o nim, to powiedz nam coś więcej o sobie i co łączy Cię z branżą IT.
Parę słów o mnie. Rozpocząłem moją karierę około 30 lat temu, więc trochę doświadczenia mam. Zawsze byłem związany z wytwarzaniem oprogramowania czyli z tą częścią software development. Pierwsze kroki stawiałem w dużej amerykańskiej korporacji GE, gdzie spędziłem lat kilkanaście, począwszy od programisty, poprzez stanowiska kierownika projektu, aż do stanowiska dyrektora. Później pracowałem w dużej firmie windykacyjnej, byłem odpowiedzialny za transformację cyfrową całości organizacji. Aktualnie jestem współwłaścicielem i prezesem w firmie 3QCode. Staramy się jako firma dostarczać rozwiązania dla naszych klientów, dla biznesu. Zarówno rozwiązania oparte o tradycyjny software development, jak i rozwiązania oparte o platformy low-code i no-code, o których dzisiaj właśnie będzie mowa.
Może zaczniemy od wyjaśnienia, czym są narzędzia no-code i low-code. Mile widziane będą przykłady na podstawie konkretnego rozwiązania.
No-code, jak sama nazwa wskazuje, to są aplikacje czy pewne platformy, które pozwalają nam budować aplikacje z klocków, czyli z gotowych komponentów. Nie ma tutaj z założenia potrzeby programowania. Budową takiej aplikacji, różnego rodzaju rozwiązań na tej platformie mogą zajmować się analitycy systemowi, analitycy biznesowi, a nawet osoby bezpośrednio odpowiedzialne za biznes, niekoniecznie związane z IT. Oczywiście mówimy o pewnych relatywnie prostych lub niezbyt skomplikowanych rozwiązaniach. Przy tych bardziej skomplikowanych to tworzenie kodu również w platformach no-code ma miejsce. Jeżeli chodzi o platformy low-code, to tam ten element kodowania występuje bardzo często, dlatego że tylko elementy związane z modelem danych, workflow i związane z interfejsem użytkownika można tworzyć z gotowych komponentów na zasadzie takiego no-codu. Tutaj kodowania jest dużo więcej, ale to też wynika z tego, jakie zastosowanie mają platformy no-code, a jakie zastosowanie mają platformy low-code w biznesie. A ono jest zdecydowanie różne. My, jako partner Creatio, platformy no-code i jako partner Mendix, jeżeli chodzi o platformę low-code, nie mamy większego problemu, żeby zarekomendować czy polecić naszemu klientowi realizację projektów w oparciu o jedną lub drugą platformę. Nie ma tutaj raczej konfliktu. Zawsze, w zależności od tego, jakie są potrzeby klienta, wiemy od razu, czy lepszym zastosowaniem będzie platforma no-code, czy platforma low-code. Oczywiście nie zawsze klienci chcą skorzystać z platformy no-code czy low-code, preferują tradycyjne programowanie, tradycyjne pisanie aplikacji i też oczywiście taką usługę mamy w naszym portfolio.
Często się słyszy, że low-code to jest napisanie kodu, ale co to oznacza? Czy tam możemy napisać na przykład pętlę, funkcję, czy piszemy całe rozwiązanie? Klasa, która jest potem implementowana jako ten kafelek wewnątrz tej platformy? Czy jesteś w stanie nam powiedzieć, jaki jest zakres pisania tego kodu, tego algorytmu, żebyśmy mogli lepiej zrozumieć, o co chodzi z tym pisaniem kodu w kontekście platform low-code?
Zakres jest bardzo szeroki, począwszy od tego, co powiedziałeś, czyli jeżeli brakuje nam jakiegoś komponentu, elementu. Oczywiście pewien zestaw komponentów gotowych do użycia jest zamknięty czyli jest stworzony przez producenta, ewentualnie jest dostępny na marketplace. To jest też bardzo istotne, że każda z tych platform, oprócz tego, że jest platformą, na której buduje się aplikacje z gotowych komponentów, ma również swój marketplace. Ma pewne komponenty, pewne rozwiązania, które są zbudowane przez partnerów, przez niezależne osoby i można z nich skorzystać. To też jest duża wartość. W związku z tym budowanie takich dodatkowych elementów, dodatkowych komponentów, które nie są dostępne bezpośrednio w aplikacjach, to jest element programowania. Musimy mieć tutaj programistę w zależności od platformy albo .NET, C-Sharp albo Java, który takie komponenty stworzy. To jest jeden z elementów. Drugi z elementów to jest to, że możemy implementować swoje własne funkcje. Jeżeli mamy nasze unikalne, customowe algorytmy, które muszą coś wyliczyć czy przeliczyć, to też możemy to zbudować w zależności od platformy. Jeżeli chodzi o Creatio, to jest .NET, jeżeli chodzi o Mendix, to jest Java. Możemy tutaj budować swoje własne funkcje, algorytmy. Trzecim elementem jest integracja, dlatego że te platformy oczywiście jak najbardziej mogą się integrować poprzez API, ale nie tylko także z całym środowiskiem zewnętrznym. W związku z tym pewne interfejsy, pewne możliwości integracji na różnym poziomie są budowane bezpośrednio przez programistów. Zakres działań programisty, czyli zakres, w którym wykorzystuje swoje umiejętności programowania, jest bardzo szeroki zarówno w jednej, jak i w drugiej platformie.
Powiedzmy sobie teraz, jakie są wady i zalety każdego z tego typu narzędzi. Może też spróbujmy w jakimś sensie porównać je z technologiami typu Java czy PHP. To jak to wygląda?
Jeżeli chodzi o zalety każdej platformy low-code i no-code, to jest ich oczywiście wiele. Postaram się skupić na tych najważniejszych. Pierwsza to szybkość wdrożenia, czyli jesteśmy w stanie dużo szybciej tworzyć aplikacje na platformie low-code i no-code w stosunku do tradycyjnego pisania programów. Oczywiście są różne wskaźniki, każda z tych platform podaje różne procenty czy różne czasy przyspieszenia. Pamiętajmy jednak, że każdy projekt składa się z kilku faz. To jest też takie krótkie wytłumaczenie tej szybkości wdrożenia, dlatego że faza przygotowawcza czyli faza definicji, faza analizy i faza testów nie różni się znacząco od tradycyjnego pisania oprogramowania. Natomiast sam proces developmentu, czyli ta środkowa faza, kiedy developerzy siadają i piszą dane rozwiązania w oparciu o specyfikację, analizę funkcjonalną czy analizę systemową, to tutaj jest duży zysk. Tu jest ta duża szybkość wdrożenia, czasami dochodząca nawet do kilkukrotnego przyspieszenia pisania takiej aplikacji. Czyli szybkość wdrożenia to jedna z istotnych zalet. Druga to dostępność. Nie potrzebujemy specjalistycznych, bardzo doświadczonych programistów z różnych języków programowania. Nie musimy mieć też DevOpsów, czyli specjalistów z działu IT, żeby tworzyć takie oprogramowanie. Platforma jest pewnym zamkniętym ekosystemem i nie potrzebujemy do prostych rozwiązań zaawansowanej znajomości programowania. Możemy takie aplikacje budować bardzo prosto, czyli osoby bez doświadczenia mogą to robić. Trzecie to koszty. Oczywiście można pewnie z tym dyskutować, natomiast jeżeli weźmiemy pod uwagę całościowy koszt projektu od momentu rozpoczęcia, poprzez fazę wdrożenia, stabilizacji i dalszego rozwoju aplikacji, to nawet biorąc pod uwagę konieczność zapłacenia kosztów licencji, z naszego doświadczenia wynika, że zawsze są one znacząco niższe. Oprócz tego każda z platform, które mają wieloletnie doświadczenie na rynku, wyróżnia się trzema podstawowymi elementami. To właśnie te elementy odróżniają platformy low-code i no-code od tradycyjnego software developmentu. Po pierwsze, to jest wewnętrzny governance, taka platforma zapewnia nam pewną wewnętrzną spójność i nie pozwala popełnić prostych błędów programistycznych. Po drugie, każda platforma pozwala nam budować rozwiązania przy założeniu security by design, czyli to platforma w dużej części gwarantuje nam, że rozwiązanie, które zbudujemy, będzie spełniało wymogi bezpieczeństwa.
Czy mógłbym Ci wejść tutaj w słowo? Bo rozmawialiśmy o tym, że możemy sami pisać kod, a teraz mówimy o bezpieczeństwie. Czy w taka platforma jest w stanie sprawdzić nasz kod już na poziomie wdrożenia? Czy to, co napisaliśmy, w jakimś stopniu nie zagraża bezpieczeństwu? Czy jest to jakoś weryfikowane albo opakowane w taki sposób, że kod napisany przez programistę nie wpływa na poziom bezpieczeństwa całej aplikacji?
Jeżeli chodzi o bezpieczeństwo, bardziej miałem na myśli całe środowisko pracy. Oczywiście zawsze możemy, jeśli tylko chcemy i robimy to świadomie, zaimplementować lukę bezpieczeństwa, ale będzie to świadome działanie programisty i żadna platforma nie będzie w stanie tego wyłapać. Natomiast jeżeli działamy zgodnie z pewnymi standardami pracy w aplikacji i wykorzystujemy gotowe komponenty, na przykład dotyczące integracji ze środowiskiem zewnętrznym, to mamy zagwarantowane bezpieczeństwo. Te komponenty były tworzone właśnie w taki sposób, aby to bezpieczeństwo zapewnić. Jeżeli świadomie napiszemy coś, co jest niezgodne ze standardami bezpieczeństwa, to żadna platforma tego nie wykryje ani nie zablokuje. Sama platforma ma wbudowane mechanizmy, które nie pozwalają napisać błędnego kodu. Będzie sprawdzała, czy kod jest napisany w sposób prawidłowy. Odpowiadając na Twoje pytanie. Platforma w 100% nie zapewni nam bezpieczeństwa, jeśli ktoś świadomie będzie chciał je naruszyć w aplikacji. Natomiast, jeśli korzystamy z gotowych komponentów i elementów, które gwarantują bezpieczeństwo, to platforma dba o to, by je zapewnić. Wracając do ostatniej zalety, to jest nią wydajność i skalowalność takiego rozwiązania. W przypadku rozwiązań tworzonych od zera często pojawia się wyzwanie związane z wydajnością. Po pierwszym wdrożeniu, w momencie wejścia na produkcję, gdy gwałtownie rośnie liczba rekordów czy użytkowników, zaczynamy obserwować problemy z wydajnością. Tutaj platforma gwarantuje skalowalność i wydajność. Platformy, których jesteśmy partnerem, czyli Creatio i Mendix, obsługują rozwiązania działające dla tysięcy, a nawet dziesiątek tysięcy użytkowników. Nie ma więc żadnego problemu z wydajnością. To są zalety, ale oczywiście są też wady platform low-code i no-code. Pierwsza wada, często wskazywana, to tak zwany vendor lock-in, czyli zależność od dostawcy. I rzeczywiście, jeśli budujemy rozwiązanie w oparciu o daną platformę, nie jesteśmy w stanie łatwo zmigrować go na inną platformę. Dzieje się tak, ponieważ pewne integralne mechanizmy danej platformy są jej wewnętrzną częścią i nie ma możliwości ich eksportu. Jeżeli chodzi o platformę Mendix, to są tutaj pewne możliwości wyeksportowania modelu danych czy customowych funkcji i algorytmów pisanych przez programistów w Javie. Jeśli tworzymy interfejs użytkownika w oparciu o gotowe komponenty, to nie da się tego w żaden sposób wyeksportować. Na pewno zależność od dostawcy to jeden z kluczowych elementów. Niektórzy wskazują również na kwestie bezpieczeństwa, ale dotyczy to głównie rozwiązań działających w chmurze. Chmura powinna być bezpieczna, natomiast istnieje wiele przykładów pokazujących, że nie zawsze tak jest. W tym przypadku nie chodzi nawet o samą platformę, ale o wykorzystanie chmury, która w porównaniu do rozwiązań on-premise jest znacznie bardziej podatna na różnego rodzaju ataki. Kolejne ograniczenie to personalizacja. Jeśli mamy do czynienia z bardzo nietypowymi, unikalnymi na rynku rozwiązaniami, które i tak trzeba programować od zera, to wykorzystanie platform no-code mija się z celem. Jeśli bowiem 90% kodu musi być napisane ręcznie, to zastosowanie takiej platformy nie przynosi korzyści. W takich przypadkach tradycyjny software development jest bardziej skuteczny, efektywny i polecany dla klientów z tego typu wymaganiami.
Dopytam jeszcze o ograniczenia personalizacji, o których mówisz. Mam wrażenie, że czasami właściciele biznesów niepotrzebnie komplikują pewne rzeczy, myśląc, że to będzie super rozwiązanie. A wystarczy uprościć temat i można go od razu wdrożyć na platformie low-code albo zrezygnować z części funkcjonalności, która wymaga dużego nakładu pracy, choć efekt końcowy będzie bardzo podobny. Czy w Twojej firmie zdarzają się sytuacje, kiedy początkowo wydaje się, że coś nie jest możliwe do wdrożenia, a po innym podejściu okazuje się, że można osiągnąć ten sam efekt w prostszy sposób?
Zdecydowanie tak. Wszystko zależy od konkretnego przypadku, projektu i wymagań klienta. Pierwszy etap, czyli analiza wymagań biznesowych, często determinuje wybór technologii, którą rekomendujemy i wykorzystujemy do implementacji. Nie zawsze jest to platforma low-code lub no-code, bo tak jak wcześniej wspomniałem, nie zawsze jest to opłacalne. W większości przypadków okazuje się, że możemy wykorzystać platformę low-code lub no-code, ponieważ znacząco przyspiesza ona realizację projektu. Jeżeli klientowi zależy na czasie i chce zmigrować stare, ograniczone rozwiązanie do nowoczesnej, skalowalnej i bezpiecznej platformy, to narzędzia low-code i no-code są niezastąpione. W tradycyjny sposób nie bylibyśmy w stanie w tak krótkim czasie przepisać starszego rozwiązania. Drugim istotnym aspektem jest, jeśli klient musi tworzyć wiele MVP, eksperymentować i dostarczać użytkownikom różne aplikacje na przykład kilka lub kilkanaście miesięcznie. Najlepiej robić to na platformie low-code lub no-code. Dzięki temu możemy błyskawicznie stworzyć aplikację, przekazać ją użytkownikom, sprawdzić jej działanie i zweryfikować pomysł, czyli przeprowadzić test w ramach MVP lub Proof of Concept. Jeżeli się nie sprawdza, to możemy bardzo szybko zamienić to na jakąś inną aplikację, kolejną do testowania i do sprawdzania. Jeżeli się z kolei sprawdzi, to w prosty sposób możemy kontynuować rozbudowę i wdrożenie takiego rozwiązania już docelowego. W zależności od potrzeb klienta i od tego, z jakim projektem mamy do czynienia, stosujemy właśnie platformy low-code i no-code.
Dodam od siebie, że mimo iż jestem programistą, to swoją stronę mam postawioną na WordPressie, a różnego typu automatyzacje piszę w make.com, bo tak jest szybciej. Czas, w którym jestem w stanie osiągnąć efekt, jest dużo krótszy, niż gdybym miał wszystko robić od nowa. Mimo że część osób się dziwi, to tak biznesowo dużo lepiej mi się to sprawdza i jestem zwolennikiem platform typu no-code czy low-code.
Tak, to prawda. Oczywiście wszystko, co pomaga przyspieszyć, zwiększa bezpieczeństwo i stabilność rozwiązania, to trzeba z tego po prostu korzystać. To są rzeczy, które cały czas powstają, a przynoszą bardzo dużą wartość, nie tylko dla samego programisty, ale też dla klienta, który korzysta z końcowego rozwiązania. Przykładem tutaj oczywiście jest typowy workflow. Jeżeli mamy dobry, sprawdzony silnik workflow, który jest w stanie równocześnie przetwarzać kilka milionów procesów i robi to w sposób bezpieczny, wydajny i pewny, to znaczy, że mamy gwarancję, iż dany proces faktycznie z punktu widzenia automatyzacji będzie przechodził z punktu A do punktu B. Próba napisania od zera silnika workflow, który realizowałby dokładnie to samo, moim zdaniem kompletnie mija się z celem. Te silniki są naprawdę już na tyle dojrzałe, że należy z nich korzystać. Platformy low-code i no-code są niejako kolejnym etapem. Nikt dzisiaj nie pisze silnika workflow sam. Nawet jeżeli programista siada i tworzy rozwiązania od zera, to raczej wykorzystuje gotowe silniki workflow, które są potrzebne do realizacji danego projektu. Obudowuje i oprogramowuje je, ale nie pisze ich od podstaw, bo na rynku dostępnych jest już bardzo wiele takich silników zarówno darmowych, jak i płatnych. Platformy low-code i no-code to, jak mówiłem, kolejny poziom. Idziemy trochę dalej, nie wykorzystujemy tylko workflow jako gotowego silnika w samej platformie, ale również komponenty do budowy modelu danych, interfejsu użytkownika, przepływu danych oraz, co ważniejsze, gotowe komponenty do integracji ze światem zewnętrznym. Na przykład z Office’em 365, SAP-em czy innymi programami, które funkcjonują w naszym środowisku aplikacyjnym. Tych komponentów do integracji w każdej z tych platform są już setki, a nawet tysiące. W związku z tym szybkość i elastyczność budowania rozwiązań wchodzą na coraz wyższe poziomy, co pozwala nam tworzyć je szybciej i taniej. Podobnie jak powiedziałeś, jeżeli chodzi o automatyzację pewnego przepływu danych, na przykład w Zapierze czy w innych tego typu rozwiązaniach.
Dodam jeszcze jedną rzecz do zalet tych platform. Możemy taką platformę postawić na własnym serwerze i mieć całkowity wpływ na to, jak ona się zachowuje. Nie jesteśmy uzależnieni od firmy zewnętrznej ani od jej serwera, który może ulec awarii. Mając to u siebie na miejscu, nie mamy problemu z dostępnością. Potwierdzisz, że tak to wygląda?
Tak, to prawda. Są oczywiście platformy no-code i low-code, które są dostępne wyłącznie w chmurze. Raczej w takie partnerstwa nie wchodzimy, ponieważ zależy nam na zapewnieniu pełnej elastyczności naszym klientom. Jeżeli proponujemy rozwiązanie oparte na platformie low-code lub no-code, to zawsze dajemy klientowi wybór. Może skorzystać z chmury, bo każda z naszych platform, których jesteśmy partnerem, czyli Creatio i Mendix, ma taką możliwość. Może też postawić rozwiązanie na chmurze prywatnej albo we własnym centrum danych jako rozwiązanie on-premise. Tutaj jest pełna dowolność. W przypadku rozwiązania on-premise mamy pełną kontrolę nad tym, gdzie platforma przechowuje dane i aplikacje oraz w jaki sposób integruje się z wewnętrznymi lub zewnętrznymi aplikacjami.
Czas powiedzieć, w jaki sposób do tego typu narzędzi podchodzą duże firmy w Polsce i za granicą. Czy widać różnicę w podejściu?
Jeżeli chodzi o światowe trendy, to generalnie low-code i no-code zyskują coraz większą popularność. Duże firmy analityczne, takie jak Gartner, wskazują, że te rozwiązania mają znaczącą przewagę i oferują wiele korzyści. Na świecie mówi się, że od 2025 roku 70% nowo budowanych rozwiązań będzie opartych na platformach low-code i no-code. To pokazuje, że rozwój w tym kierunku postępuje bardzo dynamicznie. Oczywiście istniejące aplikacje mogą zostać zmigrowane na platformę low-code lub no-code, ale tylko wtedy, gdy jest ku temu odpowiedni biznesowy powód. Gdy jest to potrzebne, opłacalne i wymagane. Jeśli chodzi o firmy, to na świecie wiele dużych korporacji korzysta z platform low-code i no-code. W Polsce te rozwiązania są jeszcze stosunkowo mało popularne. W większości wykorzystują je mniejsze firmy, podczas gdy duże korporacje opierają się na własnych rozwiązaniach lub gotowych systemach, takich jak ERP w logistyce i produkcji czy dedykowane systemy do danej branży na przykład systemy bankowe. Jednak zainteresowanie tym tematem rośnie. Coraz więcej nowych projektów uwzględnia wykorzystanie platform low-code i no-code, a ich zastosowanie się poszerza.
Czy myślisz, że Polska dogoni Zachód albo resztę świata? Jeśli tak, to w jakim czasie?
Myślę, że będzie to przebiegało podobnie jak w przypadku każdej mini rewolucji w IT. Jeśli chodzi o chmurę, to zawsze byliśmy kilka lat do tyłu w stosunku do Zachodu, Stanów Zjednoczonych czy Europy Zachodniej. W Polsce, z powodu regulacji, niedojrzałości rozwiązań lub braku edukacji, chmura wdrażana była z opóźnieniem. Podobnie wyglądało to z AI. Dziś widzimy, że sztuczna inteligencja jest szeroko wykorzystywana w Stanach Zjednoczonych i Europie Zachodniej, podczas gdy w Polsce jej rozwój przebiega wolniej. Jednak stopniowo także u nas zaczyna się coraz częściej pojawiać. Podobnie jest z platformami low-code i no-code, które na szeroką skalę są wykorzystywane na Zachodzie. Bardzo duże firmy stawiają swoje systemy krytyczne na platformach low-code, no-code, budują swoje własne dedykowane systemy ERP jako systemy krytyczne na platformach low-code, no-code. W Polsce, jeszcze to na razie nie ma miejsca, ale wydaje mi się, że ta świadomość i ta edukacja, między innymi dzięki tego typu podcastom, spowoduje, że platformy low-code, no-code zagoszczą również u naszych polskich dużych klientów. Pewnie na początku w jakichś małych procesach, bardziej niszowych, a w momencie, kiedy klienci przekonają się, jakie są dobre cechy takiej platformy, jaką wartość biznesową mogą przynieść i jaki jest stosunek tej wartości do ceny, którą trzeba za to zapłacić, to pójdzie również do dużych krytycznych procesów operacyjnych, sprzedażowych czy administracyjnych.
Jak wygląda proces wdrożeniowy aplikacji opartej o no-code czy low-code? Może jesteś w stanie przytoczyć jakiś konkretny przykład realizacji twojej firmy?
Często zapomina się o tym, że platforma low-code, no-code jest tylko tym elementem wytwórczym, na którym umieszczamy dane rozwiązanie. Cały projekt składa się standardowo z elementu definicji, czyli musimy sobie zdefiniować ten projekt, musimy określić cele, a następnie przeprowadzić całą analizę. To jest niezależne od rozwiązania, które w fazie developmentu będzie wykorzystywane i zajmuje dokładnie tyle samo czasu, co w tradycyjnym software development. Tych elementów nie da się skrócić, musimy dokładnie przeprowadzić analizę. Potem mamy fazę developmentu, czyli fazę budowania tego rozwiązania. Na platformie low-code, no-code, robi się to szybciej, czasami nawet kilkukrotnie szybciej niż w tradycyjnym software development. Następnie przechodzimy do fazy testów. Standardowo należy przeprowadzić testy jednostkowe, testy regresyjne, testy wydajnościowe. Wszystko po to, aby dostosować platformę do potrzeb klienta. Z naszych doświadczeń wynika, że testy te trwają krócej niż w tradycyjnym software development. Głównie wynika to z tego, że liczba błędów funkcjonalnych jest znacząco mniejsza, a problemy z wydajnością praktycznie nie występują. W związku z tym quality assurance może być mocno ograniczony, co skraca cały proces testowania. Ostatnim elementem jest wdrożenie, czyli deployment gotowego rozwiązania, szkolenia oraz stabilizacja systemu. Pod tym względem niewiele różni się to od tradycyjnych projektów IT. My korzystamy z najbardziej optymalnej metodyki pracy, czyli metodyk Agile'owych. Nie ma większej różnicy, czy to jest tradycyjny software development, czy rozwiązanie oparte o platformę no-code, low-code. Sam proces budowania rozwiązania w ramach projektu jest bardzo podobny. Różni się tylko faza developmentu, która jest znacząco łatwiejsza, krótsza i bardziej przewidywalna, jeśli robimy to w oparciu o platformy low-code, no-code.
Ile mniej więcej zajmuje faza developmentu? Mam na myśli, czy trwa tyle, ile suma poprzednich wszystkich etapów, czy może jest kilkakrotnie krótsza? Zastanawiam się, jak całościowo jesteśmy w stanie przyspieszyć, gdy na przykład development trwa 3–4 razy szybciej.
Kiedyś szkoła wytwarzania oprogramowania mówiła, że około 25% czasu należy przeznaczyć na analizę, 50% na development i 25% na testy. Oczywiście to jest duże uproszczenie. Jeśli chodzi o czas potrzebny na development, to wszystko zależy od specyfiki projektu. Na przykład w jednym z prostych, krótkich projektów, które realizowaliśmy w ostatnich miesiącach, rozwiązanie, które w tradycyjnym modelu budowano przez 4 tygodnie, na platformie low-code zostało zaimplementowane w 3 dni. To oznacza, że udało się skrócić czas wdrożenia 6–7 razy. Oczywiście mówimy tu o prostym rozwiązaniu, które w dużej mierze opierało się na interfejsie użytkownika. W tradycyjnym software development wszystko musielibyśmy ręcznie zaprogramować, a tutaj 90% pracy polegało na metodzie drag and drop, składaliśmy interfejs użytkownika z gotowych komponentów. Stąd tak duży zysk czasowy. W przypadku bardziej skomplikowanych rozwiązań przyspieszenie wynosi od 50% do 70% w porównaniu z tradycyjnym podejściem do software development. To zależy od tego, z czym mamy do czynienia. My na etapie analizy jesteśmy w stanie mniej więcej określić tę efektywność wykorzystania platformy low-code czy no-code w konkretnym projekcie u klienta.
Wspomniałeś kilka razy o sztucznej inteligencji. Jak postrzegasz przyszłość narzędzi no-code i low-code w dobie sztucznej inteligencji? Czy specjaliści z tej dziedziny są mniej czy bardziej zagrożeni niż programiści Javy, PHP czy innych języków?
W sumie o AI powiedziano już chyba wszystko w ostatnich miesiącach, każdy się na ten temat wypowiedział. Są osoby, które są dużymi zwolennikami wykorzystania AI i są osoby, które podchodzą do tego dość ostrożnie. Uważam, że AI jest dobrym kierunkiem i mądre wykorzystanie sztucznej inteligencji jak najbardziej przynosi wartość biznesową. Natomiast nie można zaczynać od AI. Zawsze trzeba najpierw uporządkować procesy, narzędzia, z którymi mamy do czynienia oraz aplikacje, a dopiero potem wykorzystywać AI. W kontekście platform low-code i no-code mamy do czynienia z dwoma obszarami. Pierwszy to budowanie aplikacji. Wyobraź sobie, że dziś na platformie no-code jesteśmy w stanie, bez konieczności pisania kodu, stworzyć aplikację, wystarczy przeciągać komponenty, określać ich właściwości i definiować relacje między nimi. Teraz wyobraźmy sobie wykorzystanie AI, gdzie opisujemy lub wręcz dyktujemy, jak aplikacja powinna wyglądać i co powinna zawierać. AI, działając na zasadzie drag and drop, może samodzielnie zbudować aplikację na podstawie krótkiego opisu biznesowego lub naszej wypowiedzi. Takie rozwiązania już istnieją w większości platform low-code czy no-code, dostępne są tzw. Copiloty, które pozwalają na opisanie co aplikacja ma robić, a sztuczna inteligencja buduje ją za użytkownika. To jest dużo łatwiejsze niż napisanie kodu od podstaw, choć oczywiście programiści również coraz częściej wspomagają się AI przy pisaniu kodu. Jeśli chodzi o sam koncept, czyli zaprojektowanie aplikacji, wymyślenie jej działania i funkcjonalności, sztuczna inteligencja nie zastąpi tutaj człowieka. Zawsze to człowiek musi określić wymagania i cele. Jeżeli miałbym porównać, który zawód jest bardziej zagrożony, to powiedziałbym, że bardziej narażony jest typowy programista Java, który nie ma wpływu na to, jak dane rozwiązanie ma wyglądać, a jedynie pisze kod na podstawie specyfikacji systemowej czy funkcjonalnej. W przyszłości łatwiej będzie zastąpić takiego programistę. Specjalista od systemów low-code i no-code musi być w dużej mierze analitykiem i kreatorem procesów. To on określa, jak dany proces ma wyglądać, jakie mają być kroki i właściwości. Fakt, że fizycznie nie będzie musiał klikać i przeciągać komponentów, bo zrobi to za niego AI, to kolejny poziom uproszczenia oraz oszczędności czasu i kosztów. Jednak sama definicja procesu nadal musi zostać dostarczona sztucznej inteligencji czyli poprawne zapromptowanie musi mieć miejsce.
Jak zacząłeś o tym opowiadać, to pomyślałem, czy przypadkiem zawód takiego programisty Java czy PHP właśnie nie ewoluuje w coś, co przed chwilą powiedziałeś. Czyli programista będzie bardziej takim analitykiem niż faktycznym klepaczem kodu. Do tego będzie się sprowadzać bycie programistą? Nie wiem, czy wtedy to się będzie nazywać programistą, ale myślę, że to może być taki kierunek.
Myślę, że już dzisiaj mamy do czynienia z czymś takim, że dobry programista też potrafi rozmawiać z biznesem, przeprowadzić analizę, wskazać pewne dobre i złe elementy i wejść bardziej w tę część analityczną. Wydaje mi się, że dobrzy programiści to nie są ci, którzy na podstawie dokumentu bez zadawania pytań, piszą kod i oddają to, co zostało napisane przez nich. Raczej tutaj jest ta interakcja, zawsze jest komunikacja. Mamy też do czynienia z metodykami zwinnymi, czyli w Agile'u zarówno programiści, jak i analitycy prowadzeni przez Scrum Masterów komunikują się, działają wspólnie również z DevOpsami, z szefami odpowiedzialnymi za bezpieczeństwo itd. Więc ta komunikacja musi być. Ten element programowania tak naprawdę stanowi już dzisiaj z punktu widzenia programistów pewnie gdzieś około 50-60%. Reszta to są elementy analityczne, elementy związane z bezpieczeństwem, z komunikacją, ze zrozumieniem, z wyjaśnieniem itd. Zarówno w kontekście platform low-code i no-code, jak i sztucznej inteligencji to będzie ewoluowało właśnie w tę stronę, że elementu programowania będzie coraz mniej. Może będzie to 10%, może 20%, reszta to będzie raczej komunikacja, rozumienie, definiowanie pewnych rzeczy. Czy to się będzie nazywało programistą? Trudno mi powiedzieć. Pewnie to będzie jakiś specjalista do spraw rozwiązań takich albo innych i bardziej to pewnie będzie szło w tym kierunku niż jakiś konkretny programista Javy, .NET czy PHP.
Jakie umiejętności powinny posiadać osoby, które chcą znaleźć swoją pierwszą pracę jako programista no-code czy low-code? Lepiej skupić się na konkretnym narzędziu, czy może zdobyć jakąś ogólną wiedzę?
Jak zawsze na początek pewnie dobrze zdobyć ogólną wiedzę, czyli wiedzę związaną z analizą procesów biznesowych. Żeby mieć też pewne narzędzia i móc w każdej firmie, w każdej branży bardzo szybko zdobyć umiejętność analizowania procesów i wymagań biznesowych, bo to jest kluczowe do tego, żeby zrozumieć, jaka jest potrzeba. Kolejna rzecz to umiejętność algorytmicznego czy logicznego myślenia, rozkładania pewnych procesów na mniejsze części.
Wcześniej mówiliśmy, że pewnie nie będzie potrzeby programowania, a z drugiej strony jest też ta logika działania tego wszystkiego. Myślisz, że jesteśmy w stanie przeskoczyć brak programowania i nauczyć się tego całego procesu? Bo mi się wydaje, że faktycznie może nie będziemy pisać kodu, ale dobrze go zacząć pisać i od tego zacząć naukę, żeby lepiej zrozumieć, na jakich zasadach to działa, jak dzielić problem na mniejsze części. Myślisz, że jesteśmy w stanie ten element usunąć ze swojej edukacji czy raczej nie?
Nie wydaje mi się. To, że aplikacja działa w sposób prawidłowy i realizuje funkcje biznesowe, to takie myślenie algorytmiczne jest bardzo potrzebne. W związku z tym, oprócz samych narzędzi czy metod, które pozwalają nam zrozumieć procesy biznesowe, drugim istotnym elementem jest umiejętność algorytmicznego myślenia. Jeśli mamy problem biznesowy, to nawet w głowie możemy ułożyć sobie algorytm, który doprowadzi do najprostszego rozwiązania tego problemu. Chodzi o to, żeby nie komplikować pewnych rzeczy, tylko robić je prostymi. Oczywiście w dużej części może nam w tym pomagać sztuczna inteligencja, natomiast nie rozwiąże za nas wszystkich problemów i nie podejmie ostatecznej decyzji dotyczącej logiki zaimplementowanej w danej aplikacji. To zależy od wymagań biznesowych i od tego, jak my, od strony logiki, sobie ułożymy wewnętrznie, jak to rozwiązanie powinno wyglądać. To jest na pewno bardzo istotne. Trzecim elementem jest znajomość samego narzędzia. Tutaj nie ma innej możliwości, trzeba przejść odpowiednie szkolenia. Każde z tych narzędzi jest inne, każde ma swoje własne procesy budowania, a także wewnętrzne procesy CI/CD. W związku z tym nie ma innej opcji niż przejście szkolenia dotyczącego konkretnego narzędzia. Mamy kilka poziomów zarówno w przypadku Creatio, jak i Mendix. Istnieją szkolenia biznesowe, szkolenia dla analityków, dla programistów, dla architektów i ekspertów. Tych poziomów jest bardzo dużo, ale nie są one szczególnie skomplikowane ani długotrwałe. To nie jest tak, że szkolenie trwa kilka miesięcy, raczej mówimy o kilku tygodniach. Warto poznać przynajmniej kilka narzędzi no-code i low-code, bo podobnie jak w przypadku języków programowania im więcej ich znamy, tym łatwiej przyswajamy kolejne. Dobrze wiemy, że jeśli znamy 3, 4 czy 5 języków programowania, to wejście w kolejny nie stanowi większego problemu. Bardziej chodzi o doświadczenie niż o samą znajomość składni czy sposobu budowania aplikacji.
Zapytałem o pierwszą pracę, ale jak to wygląda w przypadku doświadczonych programistów? Czy oni chętniej przechodzą ze swojej technologii, na przykład Javy, na no-code? Na Mendixa? Może upraszcza im to pracę albo daje nowe wyzwania na innym poziomie nie kodowania, a rozwiązywania problemów? Czy oni chętnie się na to decydują, czy raczej widzisz, że niektórzy mają dużą awersję do tego typu rozwiązań?
Jeżeli chodzi o seniorów, czyli osoby, które mają za sobą 10-15 lat programowania w Javie, to oni bardzo chętnie uczą się czegoś nowego. Chcą robić rzeczy szybciej i łatwiej, ale jednocześnie wykorzystują swoje doświadczenie zarówno znajomość Javy, jak i doświadczenie w realizacji różnych projektów. Niektórzy z nich mają za sobą kilkanaście, a nawet kilkadziesiąt różnych projektów w Javie, są ekspertami w tej dziedzinie. Dlatego chętnie przechodzą na Mendixa i zaczynają budować rozwiązania w oparciu o platformy low-code. Natomiast Ci, którzy dopiero zaczynają swoją karierę, chcą zdobywać doświadczenie i wolą kodować w Javie. Wydaje mi się, że tutaj kluczową rolę odgrywa liczba lat doświadczenia i liczba zrealizowanych projektów. Młodzi programiści, którzy mają dwa czy trzy lata doświadczenia w Javie, chcą ją dalej zgłębiać i realizować projekty w czystej Javie, by zdobywać wiedzę i umiejętności. Z kolei Ci, którzy przez 15 lat intensywnie programowali, nie chcę powiedzieć, że się tym znudzili, ale po prostu znają Javę wzdłuż i wszerz. Potrafią napisać w niej każde rozwiązanie, więc chętnie korzystają z platform low-code, żeby uprościć sobie pracę i wykonywać zadania szybciej. Oczywiście, bardziej skomplikowane algorytmy i funkcje nadal piszą w Javie, ale potem integrują je w ramach platformy. Efekt końcowy jest ten sam, ale osiągnięty szybciej, łatwiej i taniej.
Zapytałem o pierwszą pracę i jak ją dostać, czego się trzeba nauczyć, to też zapytam: które narzędzia będą miały największy udział w rynku? Myślę, że warto właśnie wtedy takich narzędzi się uczyć, żeby mieć jak największe możliwości. Jak myślisz, jakie rozwiązania dla dużych organizacji będą najpopularniejsze w najbliższych latach?
Dla bardzo dużych organizacji i dużych organizacji, które muszą zbudować dość skomplikowane rozwiązania przykładem może być na przykład ERP to są rozwiązania typu Mendix. To jest platforma dedykowana do segmentu Enterprise. Creatio jako platforma no-code też jest dedykowana w zasadzie dla każdego segmentu klientów, czyli zarówno do małych, jak i do dużych firm, ale również jak najbardziej sprawdza się w rozwiązaniach typu Enterprise. Jeżeli chodzi o klientów, którzy są bardzo mocno związani z technologią Microsoftu, to oczywiście Microsoft Power Apps jest rozwiązaniem, które Microsoft promuje jako konkurencję właśnie do zewnętrznych, nazwijmy to, dostępnych platform, czyli Mendix i Creatio. Pewnie dla małych firm rozwiązania tylko i wyłącznie w chmurze, czyli rozwiązania typu Bubble, też będą cały czas zyskiwać na popularności. To jest już kwestia ceny licencji oraz kalibru rozwiązania, które chcemy zbudować. Moim zdaniem byłoby nieco nadmierne budowanie jakiejś prostej strony internetowej, wykorzystując Creatio czy Mendix, bo te platformy są przeznaczone do bardziej skomplikowanych zastosowań. Jeżeli chcemy zbudować proste rozwiązanie webowe, to Bubble jest jak najbardziej wystarczający zarówno z punktu widzenia ceny, jak i tego, co chcemy stworzyć.
Jaką książkę polecasz osobom, która chce najlepiej zrozumieć świat no-code i low-code?
Nie ma za dużo książek dostępnych na rynku, szczególnie w języku polskim. Natomiast jest taka książka: No-Code Playbook autorstwa Burleya Kawasaki i właśnie mam ją tutaj przed sobą. Mogę ją zdecydowanie polecić wszystkim, którzy chcieliby dowiedzieć się trochę więcej na temat tego, czym jest no-code lub low-code, w jaki sposób podejść do definiowania założeń oraz jak efektywnie realizować rozwiązania oparte na platformach low-code i no-code.
Jest też dostępna w formie PDF, którą możemy pobrać?
Tak, jak najbardziej. Możemy ją pobrać na przykład ze strony Creatio.
To polecamy wszystkim!
Jeśli ktoś chciałby na przykład zrealizować jakieś zlecenie związane z no-code i low-code, a może będziesz poszukiwał programistów i ktoś chciałby się do Ciebie odezwać, to gdzie mogą Cię szukać i zaczepiać?
W dwóch miejscach. Pierwsze to nasza strona internetowa: 3qcode.com Drugie po imieniu i nazwisku, Jacek Zawadzki, możecie mnie znaleźć na LinkedInie. Tam czekam na wiadomości prywatne, zaproszenia i możliwość porozmawiania czy podyskutowania na temat platform low-code i no-code, ale nie tylko.
Jacku, bardzo Ci dziękuję za tę rozmowę i za podzielenie się swoim doświadczeniem oraz wiedzą.
Super, ja również bardzo dziękuję! Dziękuję, Mateusz, za zaproszenie, dziękuję za miło spędzony czas i dziękuję Państwu za wysłuchanie tego podcastu.
Jeszcze raz wielkie dzięki! Hej!
Dzięki, hej!
