POIT #103: Low-code / no-code

Witam w sto trzecim odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest low-code / no-code.

Dziś moim gościem jest Michał Guzowski – Microsoft MVP. Od ponad 8 lat związany z technologiami Microsoft. Triathlonista, miłośnik książek i podróży. Ojciec, mąż. Biohaker. Posiadacz certyfikatów Microsoft. Przedsiębiorca i organizator spotkań dla branży IT.

W tym odcinku o low-code / no-code rozmawiamy w następujących kontekstach:

  • czym jest low-code?
  • czym jest no-code?
  • jakie są obszary zastosowań tych podejść?
  • jakie są przewagi low-code/no-code nad tradycyjnym programowaniem?
  • jakie są wady tych technik?
  • czy ich stosowanie nie wymaga żadnej wiedzy programistycznej?
  • czy takie rozwiązania się skalują?
  • czy funkcjonuje już taka specjalizacja jak no-code developer?
  • czy specjalizowanie się w tych rozwiązaniach może być dobrym punktem wejścia do IT?
  • czy no-code zabierze pracę programistom?
  • czy low-code stanie się niedługo standardem w branży?
  • jak rozpocząć pracę z tym podejściem?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, która wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner  (posłuchaj)

Transkrypcja podcastu

To jest 103. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o no-code, low-code. Przypominam, że w poprzednim odcinku rozmawiałem o tym, jak dbać o wydajność umysłową pracując. IT.  

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/103

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. 

Nazywam się Krzysztof Kempiński a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. 

Zostając patronem na platformie Patronite możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/patronite i sprawdź szczegóły!

Jednocześnie bardzo dziękuję moim obecnym patronom. 

Dzisiaj szczególnie chciałbym podziękować Karolinie Boboli za jej wsparcie. Karolina jest cloud architektem i rozwija polską społeczność wokół technologii chmurowych. Robi to między innymi w ramach inicjatywy skierowanej do community o nazwie Świat chmury, którą możesz znaleźć pod adresem: swiatchmury.pl

Teraz życzę Ci miłego słuchania! 

Odpalamy! 

 

Cześć! Mój dzisiejszy gość to osoba z tytułem Microsoft MVP, od ponad 8 lat związany z technologiami tej firmy. Triathlonista, miłośnik książek i podróży. Ojciec, mąż, biohacker, posiadacz certyfikatów Microsoft, przedsiębiorca i organizator spotkań dla branży IT.

Moim i Waszym gościem jest dzisiaj Michał Guzowski.

Cześć Michał! Bardzo się cieszę, witam cię w podcaście!

 

Cześć Krzysztofie, dziękuję za zaproszenie.

 

Z Michałem porozmawiam sobie dzisiaj o takim trendzie, można powiedzieć, który zwłaszcza w ostatnim roku się uwidocznił i przebija się do naszej świadomości w branży, który być może – na to też wszystko wskazuje – będzie trendem w tym roku, mianowicie o podejściu low-code, no-code.

Oczywiście mój podcast nie może się zacząć od standardowego pytania wprowadzającego. Michał, czy ty słuchasz podcastów? Jeśli tak, to może podzieliłbyś się swoją listą tych ulubionych audycji? 

 

Wiesz co, powiem ci szczerze i bardzo uczciwie – jestem mało podcastowy. Słucham raczej bardzo nieregularnie. Natomiast wynika to z tego, że dużo bardziej wolę czytać czy też słuchać książki. 

Książek rzeczywiście staram się czytać z każdym rokiem co najmniej 20, raz wychodzi trochę więcej. Minimum 20 książek czytam, słucham i to jest takie moje, myślę, główne źródło inspiracji.

 

Też się staram to pogodzić, aczkolwiek powiem szczerze, że ostatnio ten wysyp audycji podcastowych spowodował u mnie, że raczej przesunąłem ciężar w kierunku podcastów, natomiast też staram się to uzupełnić książkami w wersji audio i tez takimi czytanymi. To jest bardzo fajna rzecz, zwłaszcza pracując w branży IT, powinniśmy się ciągle rozwijać. 

Tak jak już powiedziałem na początku, przynajmniej z mojej obserwacji wynika, że jeden z takich trendów technologicznych czy też wokoło technologicznych w poprzednim roku, który się mocno uwidocznił, to jest właśnie podejście low-code, no-code. Mam wrażenie, że to też zaczęło funkcjonować jako taki buzzword, tzn. ludzie tego wszędzie używają, bardzo mocno nie zawsze do końca rozumiejąc co za tym podejściem tak naprawdę stoi. 

Chciałbym cię poprosić, żebyśmy zaczęli od zdefiniowania czym jest podejście low-code, czym jest no-code i czym te dwa podejścia nie są?

 

Tak, temat spotyka się z dużym niezrozumieniem, ale chyba co najgorsze to jest ogromny opór przed nim. Przede wszystkim, może zacznę od tego, że tak na dobrą sprawę z low-codem czy no-codem mamy do czynienia nie od roku czy dwóch, tylko od nastu lat, bo takim bardzo popularnym narzędziem no-code jest WordPress. 

 

Tak, temat spotyka się z dużym niezrozumieniem, ale chyba co najgorsze to jest ogromny opór przed nim. Przede wszystkim, może zacznę od tego, że tak na dobrą sprawę z low-codem czy no-codem mamy do czynienia nie od roku czy dwóch, tylko od nastu lat, bo takim bardzo popularnym narzędziem no-code jest WordPress.

 

WordPressa można rozwijać pisząc w PHP-ie, kiedy budujesz swoją stronę. I na tej stronie budujesz różnego rodzaju widgety. Układasz je – konfigurujesz, nadajesz pewną automatyzację, że jeżeli opublikujesz post, to dodatkowo możesz opublikować to na LinkedInie. Instalujesz jakieś plug-iny, to to wszystko już jest formą tworzenia rozwiązań typu no-code. Oczywiście WordPress nie jest jedynym przykładem, takimi bardziej zaawansowanymi czy też bardziej specyficznymi rozwiązaniami typu no-code jest MailChimp czy platformy do obsługi list mailingowych czy Canva do budowania grafik, landingi bądź leadpages do stron landingowych. I wszelkiego rodzaju różne narzędzia też do obsługi funnelu, czyli tych lejków sprzedażowych czy takie narzędzia typowo do cyfrowego miejsca pracy jak Office 365 i Power Platform. 

Na dobrą sprawę z tymi narzędziami mamy już styczność od dłuższego czasu, ale rzeczywiście teraz mówi się o nich dużo odważniej, już nie jako takie narzędzia wspomagające, tylko zaczynają coraz bardziej kolidować z IT, troszeczkę przejmować ich zadania, obowiązki. 

Jeżeli natomiast mówimy o low-code, to tutaj będziemy mówili o narzędziach, które w jakiś sposób też konfigurujemy czy nadajemy jakąś logikę czy automatyzację, ale już z użyciem jakiegoś prostego języka. To najczęściej jest język funkcyjny, tak jak przykładowo mamy Excela i w Excelu możemy sobie w komórce wpisać jakieś tam polecenie w stylu „sumuj mi kratki do tego, do tego”, to to już jest jakaś funkcja. I mówiąc szczerze, to jest język funkcyjny i w ten sposób, tak na dobrą sprawę, tworzy się rozwiązanie low-code. 

Excel w takiej zaawansowanej formie to już może być platforma low-code’owa, ale oczywiście rozwiązań low-code jest również wiele, tak jak no-code i przykładowo w tym low-codzie mamy wspomniane przy no-codzie Power Platform, ponieważ ona jako platforma do automatyzacji czy budowania aplikacji od strony Microsoftu pozwala na pracę i taką, i taką. 

Mamy też takie systemy niezależne oprogramowania low-code’owe jak Bubble.io do tworzenia aplikacji mobilnych czy Web Contest, duży silnik do automatyzacji i również budowania pewnych formularzy czy aplikacji. Co ciekawe – produkt pochodzi z Polski. Mamy naprawdę wiele produktów różnej maści, głównie jednak skupionych na obszarach budowania automatyzacji i zwiększania produktywności w firmach. 

 

Myślę, że zasadne jest pakowanie tego wszystkiego do jednego worka? W sensie no-code i low-code? Powiedziałeś, że jest drobna różnica polegająca na tym, że albo stosujemy pewien bardzo uproszczony czy wycinek języka programowania w tym low-codzie, w no-codzie powinniśmy bez tej wiedzy też sobie poradzić. 

Najczęściej, kiedy mówi się o tym podejściu low-code, no-code to trochę zamiennie rozumie się te dwie rzeczy. Czy według ciebie na ten stan rzeczy, z jakim mamy teraz do czynienia to są takie tożsame pojęcia? Możemy je stawiać obok siebie? Czy też powinniśmy już powoli zacząć rozróżniać te dwa trendy? 

 

Ciężko powiedzieć, które podejście jest lepsze, ponieważ według mnie wszyscy w tych obszarach poruszają się dość intuicyjnie, a więc jeszcze nie zweryfikował tego rynek, a nasze doświadczenie. 

Czysto intuicyjnie wydaje mi się, że pojęcie no-code jest takim trochę sloganem marketingowym chcącym się podczepić pod tę frazę code, niejako wedrzeć się do IT, natomiast tak na dobrą sprawę tutaj byśmy bardziej mówili o konsultantach, którzy też się pojawiają przecież w IT, więc może w sumie czemu nie?

W każdym razie – to są bardziej konsultanci, osoby, które powinny mieć szeroką wiedzę. Wyobrażam sobie na przykład zawód – wcale nie taki daleki przyszłości, który mógłby polegać na tym, że jest specjalista, który zna 100 różnych platform, umie je konfigurować i przychodzi do firmy i pomaga jej ustawić procesy czy zautomatyzować, czy jakoś tam zwiększyć wydajność, efektywność pracowników za pomocą różnych platform, które można posklejać do kupy. 

Oczywiście, znowu – nie każdą firmę takie podejście będzie interesować, raczej będziemy mówić tutaj o małych, bo duże potrzebują jednego systemu, jedynie bardzo dobrze już dostosowanego do potrzeb organizacji, ale małe firmy, zwinne, startupy, to absolutnie na no-codzie zaczynają swoją pracę. Także, jeżeli chodzi o no-code to tak wygląda ta kwestia. 

Jeżeli chodzi o low-code, znowu: to jest chyba najtrudniejsza rzecz, ponieważ low-code nie jest ani no-codem ani pełnym kodowaniem, pełnym programowaniem, w związku z czym dla wielu konsultantów no-codowych jest on trochę zbyt programowany czy zbyt skomplikowany, a dla IT jest z kolei zbyt prosty i często taki powiedziałbym niepoważny. Patrzą na niego strasznie spode łba!

 

Okej. Można mówić o jakimś hypie na no-code czy low-code, z którymi mamy do czynienia, bez dwóch zdań, ale stosując takie podejście bardziej z gatunku inżynieryjnego trzeba by zapytać, czy trzeba by powiedzieć, że to są narzędzia jak każde inne i trzeba znać mniej-więcej obszary zastosowań, czy te miejsca, w których te narzędzia się będą sprawdzać, ponieważ zwyczajnie nie jest to rozwiązanie na wszystkie problemy. 

Gdzie obecnie używa się tych rozwiązań, co dzięki nim można zyskać i skąd to zwiększone zainteresowanie, które ostatnio widzimy. 

 

Powiedziałeś jedną bardzo ważną rzecz, która się wiąże z twoim pytaniem. Powiedziałeś, że to są narzędzia. Myślę, że to jest właściwie kluczowa odpowiedź na to, dlaczego teraz jest taki hype.

Jest to związane z tym, że po pierwsze te platformy low-code, no-code są tak samo, jak języki programowania, wytwarzanie takiego custom code’u to są po prostu narzędzia, które biznes może użyć do tego,żeby zwiększyć swoją efektywność. I na koniec dnia, jak się tak dobrze zastanowimy, to biznes zupełnie nie dba o to, czy pod spodem leci custom code czy jest on napisany w jakimś C-sharpie czy w Javie, czy to wszystko leży na frontendzie, czy to jest jakieś full stackowe rozwiązanie, czy w końcu zostało to wyklikane na platformie low-code, no-code.

Biznes o to nie dba. Im chodzi o to, żeby mieć jak najszybciej to rozwiązanie przynajmniej w wersji tekstowej, gdzie szybko możemy zweryfikować pewną koncepcję. Z tego powodu na przykład low-code używa się też do MVP, ale to oczywiście nie oznacza, że jest ograniczony tylko do tego, bo czasami buduje się rozwiązania na low-codzie i oni tak sobie funkcjonują. Czym to jest spowodowane? Prosta przyczyna. Mianowicie, żyjemy w takich czasach, gdzie po pierwsze zaczynamy coraz szybciej – mamy coraz krótszy okres reakcji na rzeczywistość, jeśli chcemy się utrzymać na rynku. Wydawałoby się, że mamy już tyle narzędzi począwszy od sprzętów AGD a skończywszy na aplikacjach w telefonie, że powinniśmy mieć tego czasu coraz więcej i w sumie rzeczywiście tak jest – ale my ten czas bardzo szybko wykorzystujemy do tego, żeby jeszcze bardziej usprawnić tę pracę, jeszcze bardziej upłynnić komunikację z klientami, dotrzeć do różnych odbiorców.

Pojawiają się nowe wyzwania – o czym też pewnie powiemy, że low-code, no code wcale nie powoduje, że tej pracy jest mniej. Wręcz przeciwnie! To jest związane z tym, jak świat się rozwija. Ogólnie też jest taki trend, że przez to, że ten świat bardzo mocno wchodzi w IT, każda branża – włącznie z kierunkami studenckimi opartymi o kierunki humanistyczne wchodzą w IT. Nawet na Uniwersytecie Warszawskim jest albo był kierunek Humanistyka 2.0, który łączył elementy humanistyki z IT.

 

Pojawiają się nowe wyzwania – o czym też pewnie powiemy, że low-code, no code wcale nie powoduje, że tej pracy jest mniej. Wręcz przeciwnie! To jest związane z tym, jak świat się rozwija. Ogólnie też jest taki trend, że przez to, że ten świat bardzo mocno wchodzi w IT, każda branża – włącznie z kierunkami studenckimi opartymi o kierunki humanistyczne wchodzą w IT. 

 

W każdym razie – IT wchodzi wszędzie. Nie da się teraz wyjść z komputera, a jeszcze po tej pandemii nic nie spowoduje, że ktokolwiek stwierdzi, że jednak ta cyfryzacja to nie taka dobra rzecz. No nie – nie ma na to najmniejszej szansy! I to powoduje, że tych programistów czy ogólnie specjalistów IT jest potrzebnych na świecie bardzo dużo. Szacowało się, że do końca 2020 roku będzie brakować 500-600 tysięcy w Europie, w Polsce ok. 50, ale po tej pandemii myślę, że znacznie większe to będą statystyki, bo dane mówiły o tym, że do końca 2030 roku będzie cały czas niedobór ludzi. Myślę, że przez pandemię to się wydłuży, bo jednak teraz dużo więcej firm musiało po prostu z dnia na dzień przejść na tryb zdalny. To jest niesamowita – z jednej strony tragedia, ale z drugiej rewolucja, jaka się właśnie odbywa w gospodarce.

Wracając do osób kształcących się w kierunkach IT – nie nadążamy z ćwiczeniem kadry. Ani kierunki studenckie, ani boot campy nie dają rady wyszkolić tyle ludzi, bo ten proces trwa. Nauka programowania zajmuje wiele lat.  To nie jest coś, czego jesteśmy w stanie się nauczyć w rok i być ekspertem. Nie ma takiej szansy. Przynajmniej ja nikogo takiego nie znam, a już na pewno ja nie byłem taką osobą. To zdecydowanie zajęło kilka lat, żeby się wgryźć w to, zrozumieć, poznać nowe trendy, oszacować w ogóle co jest tylko chwilową modą w programowaniu, a co będzie jakimś standardem. Tutaj naprawdę to wymaga czasu, żeby stać się tym programistą.

Narzędzie low-code w szczególności, ale no-code również są takim obniżeniem tego progu wejścia kiedy osoby spoza IT mogą wejść do tego świata IT i ich wspomóc. Dlatego wcześniej jak mówiłem o tym, że narzędzia no-code, low-code zabierają pracę IT to bym powiedział, że nie tyle zabierają, co ich wyręczają, bo tej pracy jest mnóstwo. Ten tort jest tak ogromny, że nie jesteśmy w stanie go wszyscy zjeść i strawić. Powinniśmy jak najbardziej zachęcać ludzi do tego, żeby szli w IT i może właśnie zaczynali od low-code, no code, jak ich to bardziej zajara, jak złapie bakcyla, to wtedy wchodzą już w pełne programowanie i nagle zajarani tym, ile mają możliwości! Bo jednak ten custom code jest dużo bardziej elastyczny.

 

Postaram się jeszcze dopytać cię o szczegóły. Powiedziałeś o wielu różnych rzeczach, ale nie usłyszałem tam jednoznacznie, do czego ten low-code, w jakich zastosowaniach może być użyty?

Powiedziałeś, że może to być fajna furka wejścia do IT, ale nawet jak sobie pomyślę o tych rozwiązaniach low-code, no code, to tam i tak są jakieś specjalizacje, tam też są jakieś obszary zastosowań.

Powiedziałeś na początku o tym WordPressie. Powiedzmy o webówce –  to jest taka chyba najbardziej do wszystkich docierająca specjalizacja związana z low-code, czy takie platformy też tam działają, ale jest też tego trochę więcej.

Mógłbyś powiedzieć, gdzie jest to podejście wykorzystywane? Gdzie się sprawdza?

 

W każdej branży gdzie masz do czynienia z programowaniem, tam może też zbudować coś w oparciu o low-code, no code. Jeżeli myślisz sobie o procesach marketingowych, czyli na przykład zbieranie grup mailowych czy budowanie segmentów swoich odbiorców, następnie wysyłka jakichś maili – do tego celu są narzędzia no-code, które pozwalają ten proces bardzo zautomatyzować.

Mamy różnego rodzaju narzędzia ogólnie do automatyzacji i znowu – kiedy myślisz o automatyzacji, to możesz myśleć o każdym dziale. Możesz zautomatyzować linię produkcyjną. Mam na przykład klienta, który zajmuje się produkowaniem kamizelek kuloodpornych, czyli tak naprawdę systemów balistycznych, czyli tego co wkłada się w kamizelkę, te płyty. Proces projektowania takiej kamizelki, następnie weryfikowania testów balistycznych został zbudowany za pomocą narzędzi low-codowych. To są po prostu aplikacje mobilne – czyli pełne aplikacje, ale zbudowane na low-codzie. Taki proces możesz też zautomatyzować za pomocą innych narzędzi low-codowych do automatyzacji, jak na przykład w Microsofcie będzie to Power Automate, ale na zewnątrz, poza Microsoftem mamy Zapier, mamy IFTTT, mamy też Webcona, które pozwalają łączyć się z różnymi serwisami i integrować ich funkcjonalności między sobą.

I znowu – właściwie nie ma tu ograniczenia co do branży. To działa i w marketingu, i w sprzedaży, i w finansach – jakieś obiegi dokumentów, możesz to robić w działach HR-owych, do jakichś procesów onboardingowych, do procesów poszukiwania ludzi, do procesów exitowych, kiedy człowiek opuszcza firmę i teraz na przykład są karty obiegowe w dużych korporacjach. Znowu – to może być ta aplikacja…

Właściwie wszędzie. Obsługa ticketów supportowych, też można to zrobić na low-code, no code. Chciałem jeszcze powiedzieć jedną rzecz, bo pytałeś wcześniej, dlaczego to teraz się tak stało mega popularne. Powiedziałem przed chwilą takie zdanie o standardach i to jest myślę jedna rzecz, która umożliwiła to, że te narzędzia stały się tak bardzo popularne, mianowicie: standardy. Mówię tu o standardach w IT.

IT dopiero się rodziło – powstawało wiele konkurencyjnych standardów, np. w formatowaniu przesyłanych danych. Czy to będzie jsonem, czy to będzie może XML-em czy czymś innym, były też formaty transportowania tych danych, czy komunikacji – czy jakieś REST API, czy może jakiś WCF. Było mnóstwo różnych podejść i w związku z tym kiedy twórcy czy też tacy najbardziej kreatywni start-upowcy zaczynali budować swoje rozwiązania, oni na dobrą sprawę zawsze tworzyli je trochę jak takie zamknięte pudełka, do których nie ma wejścia. Trzeba było wejść w ten produkt na platformie i tyle.

Natomiast teraz, dzięki temu, że właściwie już wszyscy wiemy, że komunikacja leci po https, zabezpieczona jest jakimś OAuth 2 , mamy tam komunikację jakimś REST API albo Graph API i na ogół informacje przesyłane jsonem, to właściwie dzięki temu, że są te standardy już dobrze przyjęte na rynku, to my możemy skupić się na dowiezieniu funkcjonalności, a potem po prostu wystawieniu API. I jak wystawimy te API, to każdy serwis będzie mógł je wykorzystać, skonsumować po to, żeby się z nimi zintegrować. I dzięki temu, kiedy na przykład te narzędzia low-code powstają, to one właściwie są niejako takimi pośrednikami umożliwiającymi łączenie się do mnóstwa różnych serwisów. Przykładowo – kiedy sobie zrobię jakąś automatyzację, nie wiem, do obsługi swoich klientów, że na przykład wpada mi mail od klienta, to ja jestem w stanie dowolnym rozwiązaniem typu Zapier, Power Automate czy IFTTT jestem w stanie podłączyć się do swojej skrzynki w outlooku czy nawet Gmaila, pociągnąć te maile, w jakiś sposób je przefiltrować, czyli na przykład szukam po konkretnym odbiorcy albo szukam konkretnej frazy i na tej podstawie na przykład wysłać mi powiadomienie na telefon albo powiadomienie na jakąś prywatną skrzynkę odbiorczą.

Niezależnie, na czym ta skrzynka jest, niezależnie jaki telefon masz. Ty na dobrą sprawę jesteś w stanie w bardzo transparentny sposób komunikować się z różnymi usługami, a przez to ich możliwościami i funkcjonalnością.

 

Widzę tutaj bardzo dużą wartość dla biznesu – szybkie tworzenie VP, skracanie tego time to market i tak dalej. Zastanawiam się, czy są jeszcze jakieś takie przewagi, powiedzmy w tradycyjnym programowaniu. Albo też może właśnie w drugą stronę – co powoduje, że pisanie kodu, tworzenie aplikacji za pomocą podejścia no-code może być nieoptymalne i może działać wręcz przeciwnie?

 

Jednym słowem: jakie są przewagi i problemy związane z no-code w stosunku do tradycyjnego programowania?

 

To jest bardzo ważne pytanie. Często osoby, które nie chcą wchodzić w low-code, no-code nie zastanawiają się nad ich zaletami i wadami. Jeżeli chodzi o zalety, to przede wszystkim to jest dużo krótszy czas dowiezienia rozwiązania. Z mojego doświadczenia, kiedy budowaliśmy sobie – jak poznawałem dopiero narzędzie low-code i budowałem sobie rozwiązania, aplikacje – jakieś skany wizytówek, narzędzia do tłumaczenia dokumentów, to właściwie byłem w stanie uzyskać ośmiokrotnie krótszy czas zbudowania kompletnego rozwiązania w stosunku do tego, gdybym budował je zwyczajnie, programistycznie.

Często osoby, które nie chcą wchodzić w low-code, no-code nie zastanawiają się nad ich zaletami i wadami. Jeżeli chodzi o zalety, to przede wszystkim to jest dużo krótszy czas dowiezienia rozwiązania.

 

Akurat tutaj też mam doświadczenie, bo byłem programistą, więc miałem takie porównanie w miarę realne. Czyli ile mi by zajęło czasu napisanie aplikacji n przykład skanowanie wizytówek, a ile mi to zajęło faktycznie, zrobienie takiej aplikacji za pomocą low-code.

Przykładowo w low-code to wyszło mi chyba 1,5 dnia. Budowanie zupełnie własnej aplikacji do skanowania, która robi te zdjęcia, wyciąga z nich jakieś informacje – zrobienie tego w dzień czy 1,5 to jest naprawdę żaden czas. Jeżeli myślisz sobie więc o rozwiązaniach biznesowych, gdzie okej, proces analityczny i jakiś designerski trwa tyle samo co w tym programowaniu, ale potem proces implementacyjny trwa kilkukrotnie krócej, no to to jest dla biznesu spora przewaga, sprowadzając to do celu oczywiście.

Natomiast gdzie ten low-code jest słaby, no to znowu – ponieważ low-code to są najczęściej technologie SaaSowe, czyli w cloudzie mamy jakąś platformę, na jakichś serwerach, no to po pierwsze może kuleć wydajność, optymalizacja. To zależy od tego, jak duże czy jak bardzo wykorzystywane będzie to nasze rozwiązanie. Inna rzecz to będzie bariera cenowa – im większe wykorzystanie, czyli większe możliwości platformy tym większa cena i może się okazać, że my przepłacamy bardzo dużo.

Kwestia też tego, że ponieważ jest to jednak low-code, no-code, czyli my na dobrą sprawę używamy jakiś takich zbudowanych czy to kontrolek, czy funkcji, to to jest tak ograniczony zbiór i nie zawsze wszystko możemy zrealizować. I przez to może się nagle okazać, że my potrzebujemy akurat takiej funkcjonalności, czy takiej integracji, która nie jest możliwa w takim rozwiązaniu. Wtedy na dobrą sprawę należałoby patrzeć, czy sensownie jest z punktu widzenia biznesu wyłożyć trochę dodatkowych pieniędzy, żeby zbudować to customowo. Czasem się okazuje, że tak, czasem się okazuje, że nie.

 

Powiedziałeś, że ten wachlarz usług dostępnych w ramach no-code coraz bardziej rośnie. Jesteśmy w stanie się integrować z coraz większą gamą różnych dostawców, usług, api i tak dalej – konsumować i wyklikiwać. Zdarzają się jednak też takie rozwiązania, gdzie to nie jest wystarczające. Gdzie trochę takiego pseudo kodu albo jakiegoś kodu w prostym języku trzeba mimo wszystko na przykład napisać, żeby się zintegrować z jakimś api, które nie ma jeszcze podłączenia i tak dalej.

Zastanawiam się na ile według ciebie trzeba mimo wszystko mieć jakąś wiedzę programistyczną, nawet ogólną, niezwiązaną z konkretnym językiem programowania, ale na przykład z zasadami tworzenia kodu, takie zupełne tutaj podstawy, żeby zająć się właśnie tworzeniem takich rozwiązań za pomocą no-code, low-code. Czy to w ogóle jest wymagane i potrzebne? 

 

Zdecydowanie pomaga. To jest tak, że teraz sporo się mówi o citizen developers. Citizen developer jest to człowiek, osoba pracująca w firmie, będąca najlepiej jakimś process ownerem, czyli kimś, kto świetnie rozumie proces od początku do końca. Na przykład pracownik HR-u, który nie tylko bierze udział w procesach zatrudniania, onboardingu, ale również jest w stanie wpływać na ułożenie tego procesu, na jego wygląd. Ma jakieś pomysły, żeby ten proces usprawnić, ulepszyć. I taka osoba w momencie, w którym dostaje narzędzia low-code, to one widzi, że teraz jest w stanie realnie, bardzo szybko, efektywnie pomóc sobie budując jakąś automatyzację czy budując jakąś aplikację i nie potrzebuje iść do działu IT.

Dział IT teraz nie rozumie – potrzebujemy z 2 tygodnie, żeby to zrozumieć – i potem dział IT zaczyna to wdrażać, i nagle się okazuje, że to zupełnie to, co ta osoba chciała. Nie wiem, czy kojarzysz taki fajny obrazek huśtawki pokazujący jak programista rozumie pewne rzeczy, a czego potrzebuje klient. Jest tam chyba z 9 obrazków, które pokazują jak to rozumie pracownik marketingu, jak to zrozumiał pracownik IT, analityk, a co finalnie potrzebował zamawiający.

W momencie, w którym skracamy tę drogę, bo ja jestem i wymagającym, i dostarczającym, to tutaj jakość jest niebotycznie większa. Dochodzi do tego pytania, które zadałeś, czyli czy ta osoba powinna rozumieć IT – oczywiscie tak. Im lepiej ona rozumie IT, tym ma większa świadomość tego, jak może to odpowiednio właściwie zaimplementować czy też jak może to z czymś połączyć.

Powiem szczerze, pomimo tego nurtu citizen deweloperskiego, nie jestem wielkim zwolennikiem, żeby osoby bez przeszkolenia od razu łapały się za narzędzia low-code i ciach, ciach – zróbmy coś.

Nie chodzi o hurraoptymizm. Chodzi o to, żeby pokazać, że są możliwości. Teraz na przykład odpowiednio wyedukować te osoby w kierunku właśnie dostarczania tego typu rozwiązań. Tutaj w ogóle jest takie ciekawe badanie, które zostało przeprowadzone w 2018 roku, przeprowadzone przez CIMI Corporation, organizacja przetestowała przez rok kilkaset różnego rodzaju, różnej wielkości organizacji pod kątem wdrożonych projektów IT typu low-code.

Co się okazało? 54% projektów low-code prowadzonych przez citizen developerów się nie udała. Zakończyła się totalnym fiaskiem. 28% zakończyła się marginalnym sukcesem i 20% zakończyła się spektakularnym sukcesem co pokazuje, że właściwie tylko 20% jest naprawdę dobrych, a pozostałe 80% albo tak, albo w ogóle jest fail. Oczywiście nie chodziło tylko o to, żeby to zbadać, ale chodziło o to, by zdiagnozować co się właściwie zadziało.

Wydedukowali z ankiet i z rozmów ze swoją grupą badawcza, że można by podsumować czy wyszczególnić 4 elementy, aspekty kluczowe dla powodzenia projektu no-code bądź no-code. Pierwszym elementem to jest znalezienie właściwego kandydata. To jest oczywiste przy wdrażaniu jakichkolwiek rozwiązań IT, bo chodzi o to, żeby po drugiej stronie mieć po pierwsze kogoś, kto będzie zapalał innych, będzie tym takim driverem w organizacji, ale w low-code dodatkowo ta osoba musi być takim change makerem nie tylko z nadania, ale i z powołania. To nie może być ktoś mianowany, że przyjdzie szefu i powie „Kowalski, od jutra ty będziesz entuzjastą”, tylko raczej to będzie tak wyglądało, że po prostu Kowalski wali drzwiami i oknami do prezesa, żeby to wdrożyć. Prezes stwierdza – „to ma sens dla nas, to by się nam przydało. Dobra Kowalski, jedziesz!”. I Kowalski już sam leci. Jego nie trzeba namawiać. Bo on się nim interesuje. Tak jak powiedzieliśmy – tych rozwiązań jest bardzo dużo, więc trzeba ogromnie dużo poznać tych platform, żeby mieć świadomość co z czym warto połączyć.

Ponadto drugim elementem, który to badanie znalazło, to było położenie właściwych ram dotyczących współpracy czy wdrażania w organizacjach. Tego, że to ni jest taka praca chaotyczna, że wchodzi citizen developer i zaczyna sobie sam tam odpowiednio działać, tylko raczej „okej, musimy ustalić w takim razie jakiś kanał komunikacji, kanał jak będziemy to adaptować w organizacji. Musimy sobie odpowiednio tych ludzi też podzielić, żeby nie wdrażać narzędzia dla całego działu, tylko najpierw testować na małych grupach, potem zacząć to rozszerzać. Jeżeli będzie sukces – czy po jakichś kolejnych testach.

Trzecim elementem jest zbratanie się z IT. Czyli jednak rozmowa z tym IT – okej, jakie mamy możliwości? Jakie macie rozwiązania? Bycie w kontakcie z IT, który jest jednak dużo bardziej świadomy tego, jak wygląda implementacja i ją rozumie, więc jest w stanie domyślić się czy teraz taka integracja będzie możliwa czy nie. Czy zabezpieczymy ją w taki sposób, w jaki wymaga tego nasza organizacja czy nie. Czy jesteśmy w stanie zabezpieczyć pewne porty czy nie. Tutaj musi być bliska współpraca z IT. Bez tego się nie obędzie.

Ostatnia rzecz to jest reject the creep, czyli zabezpieczenie się przed ślizganiem zakresu, ale w mojej opinii bardziej bym to nazwał jako wsparcie zewnętrznych konsultantów, którzy rozumieją tę technologię, znają jej ograniczenia, znają jej możliwości, a ponadto mają doświadczenie we wdrażaniu rozwiązań IT przez co taki zewnętrzny konsultant jest w stanie po pierwsze: uniknąć ewentualnej porażki związanej z tym, że nagle zapędzimy się za daleko, dowieziemy kawał funkcjonalności, kiedy jakaś jedna z kluczowych nie będzie mogła zostać zrealizowana, bo akurat ta platforma ma takie i takie ograniczenia. Doświadczony citizen byłby w stanie od razu to wychwycić.

Po drugie, nawiązując do reject the creep, to ta osoba, która wdraża rozwiązania IT bardzo dobrze umie się zabezpieczyć przed ślizganiem zakresu, czyli tym, że taki entuzjasta jeszcze nie skończył dowozić, jeszcze nie przetestował w organizacji, jeszcze nie pokazał tego ludziom, a już wymyśla kolejną funkcjonalność. Wiesz, jak to bywa często w IT – jeszcze nie skończyłeś implementować jednej funkcji, a już masz pomysł na 10 następnych, teraz zaczynasz je zapisywać i odkładać na później, i totalnie się rozpraszasz.

Także takie wsparcie osoby zewnętrznej bardzo pomoże przez to przejść maksymalnie bezboleśnie.

 

To jest faktycznie wiele klocków! Jakby nie patrzeć, ten no-code jest jakimś rodzajem developmentu, albo aplikacji, albo integracji stron, te rzeczy, o których powiedziałeś. Jak sobie spojrzymy na ewolucję tworzenia oprogramowania, to zauważymy, że idziemy coraz bardziej w kierunku wyższej abstrakcji, w kierunku odcinania się od konkretnego sprzętu, na którym ten nasz program będzie działał.

Czy no-code to jest kolejny kierunek, kolejny krok w tym kierunku czy tutaj operujemy takimi klockami, które są jeszcze wyższym elementem w hierarchii niż na przykład instrukcje, które piszemy w kodzie? Można to według ciebie wpasować w ten kierunek rozwoju?

 

Tak! Najpierw jak sobie spojrzymy na generację języków programowania, ta druga generacja Asembler, potem trzecia generacja C-Sharp, Java, czy C++ i czwarta generacja to taki powiedziałbym, pseudokod.

Na przykład visual basic jest zaliczany do takiego języka czwartej generacji. Ogólnie rzecz ujmując jest widoczny ten proces coraz większej generalizacji języków i low-code czy no-code jest według mnie jego formą. Według mnie bardzo dobrze, że tak się dzieje, bo wszystko na koniec dnia sprowadza się do tego, że jesteśmy w stanie to rozwiązać. Pewne powtarzające się elementy, schematy w procesie wytwarzania oprogramowania w jakiś sposób ubrać w ramę szablonu, a następnie posługiwać się tym szablonem. Każda generacja języka to miała na celu.

Teraz już nie ma bojówek Asemblera, które twierdzą „nie, tylko praca na poszczególnych tikach Asemblera to jest właściwe, a C++ to dziadostwo”. Nie – teraz zdarzają się bojówkarze C, którzy twierdzą, że C ma największą optymalizację, no bo daje. Działasz na bardzo niskich elementach maszyny, natomiast nikt nie ma z tym problemu, że 70%-80%, strzelam, że zdecydowana większość rozwiązań, aplikacji IT jest robiona nie w C tylko w C-Sharpie. Co de facto i tak jest kompilowane do kodu maszynowego.

 

Zgadza się! Powiedziałeś na przykład: to jest fajne narzędzie, fajny sposób, żeby sobie szybko MVP sprawdzić. Albo, nawet żeby jakieś działające rozwiązanie stworzyły osoby, które nie mają takiego backgroundu inżynieryjnego związanego z programowaniem. Myślę, że fajnie użyć sobie takiego rozwiązania, nawet jeśli chcemy potem osobiste automatyzacje sobie porobić, nie? Żeby coś tam się działo, żebyśmy nie musieli spędzać ileś tam czasu nad takimi prostymi rzeczami dla nas.

Zastanawiam się, co się stanie, jeśli ten nasz pomysł biznesowo wypali i nagle zmierzymy się, zderzymy się z problemem wielkiej skali. Czy takie rozwiązanie się w ogóle skalują? To nie tylko myślę tutaj o takim czysto technologicznym challengu, ale również tak finansowo, kosztowo. Czy jeśli nie przekraczamy pewnej skali, to okaże się, że jednak płacimy dużo więcej niż gdybyśmy to rozwiązanie napisali. Czy to nie oznacza, że w pewnym momencie musisz to rozwiązanie takie wyklikane mimo wszystko zaorać i napisać to po bożemu w kodzie? Jak to wygląda?

 

Wiesz co, mam dwie kwestie, które chciałbym poruszyć. Pierwsza: czy to jest opłacalne z takiej perspektywy na przykład licencyjnej? Czyli mamy już tylu użytkowników, że nam się to przestaje opłacać. Wydaje mi się, że to jest stały element kosztowy, kiedy używamy platformy, jakiegoś rozwiązania, niekoniecznie technologicznego, jakiegokolwiek, które automatyzuje, no to wiadomo, że prawdopodobnie będzie trzeba od tego zapłacić podatek i wraz z wartością, którą zaczynamy sobie od tego odbierać, ten podatek będzie większy. Często przez to platformy low-code, no-code, kiedy widzą, że masz coraz większy ruch zaczynają cię coraz więcej kasować. Finansowo więc przestaje być to aż tak opłacalne, chociaż jest mnóstwo biznesów, których to zupełnie nie odstrasza, bo wartość, którą uzyskują jest znacznie większa.

Żeby nie szukać daleko – my nawet wdrożyliśmy, pamiętam, projekt od takiego klienta, aplikację do śledzenia czasu pracy. Tak na dobrą sprawę klient – to był klient szwedzki – płacił za narzędzie 50 000 koron miesięcznie. Dla 100 pracowników jakiś tool miał. Ten tool był niedostosowany, to był jakiś chyba CRM dostosowany do tego pomiaru czasu pracy, więc on był bardzo dziwnie poszyty. Dodatkowo nie miał aplikacji mobilnej i to była tragedia, żeby tego używać i my żeśmy im to zbudowali w 3 miesiące. A tak naprawdę 3 aplikacje. 2 mobilne i jeden raport Power BI-owy.

W 3 miesiące człowiek dostał rozwiązanie, które zwróciło mu się w kolejnych trzech miesiącach. Po 6 miesiącach zaczął zarabiać na tym projekcie, bo płacił koszty wdrożeniowe plus koszty utrzymaniowe za licencje microsoftowe – były i tak niższe niż te 50 000 koron miesięcznie. Po 6 miesiącach więc zaczął na tym zarabiać, w odniesieniu oczywiście do tego poprzedniego narzędzia. 

To wcale nie jest powiedziane, że takie narzędzia mogą generować koszty, ale oczywiście, jeżeli się tego nie robi jakoś tak w przemyślany sposób, bez takiej świadomości licencyjnej i produktowej, to można się wpakować w spore koszty. 

Druga rzecz, którą powiedziałeś to, czy te narzędzia, ogólnie, jeżeli budujemy takie MVP to znaczy, że to się teraz opłaca robić, mając świadomość tego, że będziemy musieli się wycofać i to napisać od nowa. Uważam, że zdecydowanie tak. Według mnie czysto biznesowo, świadomość tego, że produkt działa tylko jest za chudy, za cienki wydajnościowo czy funkcjonalnie, to jest świetna wiadomość. Bo ja w tym momencie wiem, że rynek to weźmie, tylko ja muszę popracować nad technologią. 

To jest tak, jakbyś wyprodukował drewniane koło i miał tylu klientów, że oni stwierdzą „koło super, tylko że potrzebujemy, żeby miało gumowe obicie”. W tym momencie wiesz, że produkt działa, jest świetnie przystosowany, tylko nie jest jeszcze dość doprecyzowany, doszlifowany. W tym momencie masz najprzyjemniejsza część, czyli masz pewną inwestycję, w związku z czym wchodzisz w układ z inwestorem. I inwestor dokłada ci 100 000 do tego, żebyś przepisał całą platformę. I tak się dzieje mnóstwo razy w ogóle w takich biznesach dużych, że całe rozwiązania – są takie platformy, które były przepisywane od zera, bo to była najprostsza droga do tego, żeby dostarczyć rozwiązanie zgodne z oczekiwaniami twoich klientów, których masz – czekają, błagają o to, abyś im to dostarczył. 

 

Jak tak sobie obserwujesz rynek, to zauważasz coś takiego jak taka specjalizacja no-code developer albo coś takiego jak no-software house? Butiki specjalizujące się w takim podejściu?

 

No-code developerów jeszcze nie widziałem i sami szukamy low-code developera Office 365 i Power Platform, i jest nam ciężko, bo na razie jeszcze ludzie trochę nie wiedzą, czy ten power platform, low-code to tak na stałe, czy bardziej moda. Nie są do tego przekonani. Działam już w tym rynku bardzo mocno od 2 lat – tylko w low-codzie, a w ogóle w IT siedzę dłużej, więc ogólnie widzę, że to na pewno nie będzie maleć i każdy kolejny rok pokazuje ten wzrost dobitnie. 

Natomiast jeśli chodzi o software house’y, to tak – to już się dzieje. Są nawet grupy na Slacku poświęcone tylko no-codowi, gdzie też takie software house’y się ogłaszają. Także jak najbardziej są już tego typu software house’y. 

W Polsce jednym z takich jakie ja znam, to jestem ja. Mamy firmę Developico i tam zajmujemy się właśnie budowaniem rozwiązań low-code na platformy Microsoft, czyli z użyciem Office 365, z użyciem Power Platform. 

 

Świetnie. Teraz taka inna perspektywa. – powiedziałeś, być może to podejście no-codowe jest taką fajną alternatywą czy fajnym punktem wejścia do IT. Widze tu z jednej strony taki potencjał w budowaniu dosyć szybko rzeczy, po to, żeby je na przykład zrewidować, a z drugiej strony doskonale wiem, że nauka programowania, tak jak mówiłeś na początku – to trwa. To się nie dzieje z wtorku na środę. Potrzeba ileś tych godzin przepracować. 

Tutaj ten no-code może być trochę lekiem, że nie będzie wymagane aż tak duże doświadczenie związane z inżynierią oprogramowania, żeby tworzyć, żeby wyklikiwać takie fajne rozwiązania. To jest być może trochę inne spektrum wiedzy czy umiejętności, które trzeba opanować, natomiast może być to jakimś lekiem na brak ludzi na rynku, a jednocześnie rosnącym zapotrzebowaniem na usługi IT. 

Czy wobec tego dla młodych ludzi zasugerowałbyś właśnie taką furtkę, te bramę wejścia do IT? Myślę tutaj o osobach, które nie mają backgroundu, umiejętności związanych z IT czy jakichś doświadczeń. Dla nas, programistów, pewnie opanowanie tych tooli tych narzędzi nie jest aż takim dużym wyzwaniem, natomiast jak myślisz – dla osób, które dopiero myślą o wejściu do IT to jest dobra ścieżka?  

 

Krótko odpowiem: tak. Długo odpowiem, posługując się przykładem. Mianowicie u siebie w firmie zatrudniliśmy niedawno osobę, która wcześniej pracowała wiele lat w marketingu, w dużej korporacji. Po prostu była już nauczona w ogóle pracy w korporacji i denerwowało ją podejście menedżerów, były różnego rodzaju przygody z mobbingiem. Postanowiła się przebranżowić na IT z racji tego, że IT wydawało się takim miejscem, gdzie po pierwsze panuje wyższa kultura, bo są wyższe pieniądze, po drugie miejscem, gdzie jednak twój rezultat jest dużo bardziej zero jedynkowy. Narzędzie, twój tool albo działa, albo nie działa.

Natomiast w marketingu jest tak – zrobisz trochę jakiejś aktywności, ale czy cała kampania się uda zależy jeszcze od tego, czy nie zbiegnie się w czasie z jakąś pandemią albo z tym że nagle wyjdzie jakiś event i on akurat będzie oparty o hasła, które ty wykorzystujesz i on wypali źle, i w tym momencie nagle ludzie twój też zaczynają postrzegać źle.

W marketingu jest bardzo dużo psychologii, która jest totalnie, według mnie, niezarządzalna, chociaż w miarę przewidywalna. Nie wszystko od ciebie zależy. Natomiast w IT – tak. Osoba, która postanowiła przejść do IT – i tak się akurat przycięliśmy, spotkała się ze mną i pogadaliśmy o tym low-codzie. Ona pracuje już u mnie 3 miesiące. Po 3 miesiącach jest w stanie samodzielnie wdrażać rozwiązania low-codowe – robi to, bo siedzi na projekcie od razu, rzuciliśmy ja na głęboką wodę. Ogólnie to jest nasza filozofia turkusowo – zielono – pomarańczowa. W każdym razie bardzo szybko sobie dała radę, ale co najważniejsze, właśnie uważam, że bardzo potrzebne są osoby w IT, które mają duże doświadczenie w pracy poza IT. Dlaczego?

Bo często te osoby mają zupełnie inny mindest, zupełnie inną inteligencję emocjonalną. Jednak w IT jeszcze spore pokolenie wychowane w IT, które było dla prawdziwych hobbystów, osób z zacięciem, pracujących w garażu, po godzinach w piwnicy i to powoduje, że ci ludzie często są niezwykle zdolne technicznie, ale bardzo słabi w relacji z innymi ludźmi. Często są bardzo aspołeczni albo nieumiejący się komunikować, nieumiejący się dogadywać, ustępować. To, co często się obserwuje w IT – mm osobiście problem na tyle, że zauważam to i to mnie boli, jeszcze nie wiem, jak to zmienić, chociaż mam kilka pomysłów i może kilka z nich uda się zrealizować, ale na przykład w IT taką typową manierą jest to, że kiedy rozmawiasz ze specjalistą, to dla niego… Jeżeli czyjaś prawda jest inna od jego prawy, to znaczy, że dla tej osoby prawda może być tylko jedna, to znaczy, że w tym momencie czyjaś prawda atakuje moją prawdę. Muszę zwalczyć czyjeś racje, bo inaczej one podważają moje podejście.

 

Bo często te osoby mają zupełnie inny mindest, zupełnie inną inteligencję emocjonalną. Jednak w IT jeszcze spore pokolenie wychowane w IT, które było dla prawdziwych hobbystów, osób z zacięciem, pracujących w garażu, po godzinach w piwnicy i to powoduje, że ci ludzie często są niezwykle zdolne technicznie, ale bardzo słabi w relacji z innymi ludźmi. 

 

W IT oczywiście jest tak, że wszystko może być na milion sposobów. Nie ma jednego, idealnego rozwiązania. Na dobrą sprawę warto jest eksperymentować, żeby przekonać się, jak to zadziała w tym konkretnym przypadku, a jednak wiem od takich starszych stażem architektów czy seniorów, ma takie podejście, że albo jest tak jak ja mówię, a jeśli jest inaczej, to znaczy, że nie macie pojęcia, o czym mówicie. To powoduje, że jest dużo konfliktów w IT.

Na szczęście – to się zmienia z młodszym pokoleniem, ale jednak jest jeszcze dużo pracy do wykonania. I właśnie – takie osoby spoza IT wnoszą to, w czym IT sobie słabo radzi, czyli kontakt z klientem. Mamy takiego kolegę, który pracuje z klientem, on to wdraża i jednocześnie komunikuje się z klientem. Jako marketingowiec ma genialną komunikację z klientem. On jest tak jakby… Dla nas, osób, które też działają w biznesie, to jednak jest to dość oczywiste, że nie wysyłasz klientowi suchej wiadomości „ok, zrobione”, tylko wysyłasz mu jakąś taką większą formułkę w stylu „słuchaj, sprawdziłem co było powodem tej awarii, naprawiłem to i wiem, że to było na tym i tym, zabezpieczyłem się przed tym, żeby to się więcej nie pojawiało, ale proszę daj mi informacje, gdyby coś było nie tak”. Dajesz pełen feedback, pełen komunikat użytkownikowi, temu człowiekowi po drugiej stronie, który siedzi z takimi klapkami na oczach, jeśli chodzi o technologię i troszeczkę pozwalasz mu zrozumieć swoją pracę. Poczuć swój klimat, pokazać, że ty faktycznie – to nie jest tak, że przez 24 godziny się działo i nagle ty to w końcu naprawiłeś, tylko że siedziałeś, kminiłeś, naprawiałeś to. Że były jakieś problemy, ale udało się je rozwiązać. I w tym momencie zwiększasz nawet wartość siebie jako specjalisty.

IT często nie czuje tego, czego potrzebuje druga strona. W związku z tym osoby low-code no-code, które wchodzą spoza IT, one już to często mają. I teraz jak jeszcze zapną to w jakieś umiejętności techniczne, dla mnie to jest mega combo.

 

Fajna perspektywa. Chciałbym pociągnąć ten wątek klientów, bo powiedziałeś, że no-code software house’y to już jest rzeczywistość, zaczynają się pojawiać.

Jak to działa z klientami? Czy przychodzą do was osoby, firmy, które wiedzą, że tak – one chcą to zrealizować w podejściu no-code, bo słyszały, że to jest fajne, łatwe do rozbudowywania i tak dalej, czy też jest jeszcze zbyt wcześnie i to raczej wy sugerujecie, że to jest dobre narzędzie, dobry tool do tego konkretnego zastosowania, dla tych osób, które jak powiedziałeś, na początku biznesowych to jest totalnie obojętne, jak to zostanie technicznie zrealizowane?

 

Nie wiem, czy to wynika z naszych komunikatów marketingowo-sprzedażowych, docierania do rynku czy pokazywania się tam. Nie wiem, ale na razie głównie jednak zdarzają się ci pierwsi, czyli tacy, którzy wiedzą już, że jest coś takiego jak Power Platform i to może skrócić czas dowiezienia rozwiązania i teraz powiedzcie, ile to zajmie. Oni jak już wiedzą – natomiast to są często ludzie, którzy chcą się dowiedzieć, jak by to wyglądało i jeszcze podejmują decyzje. To narazie mi się zdarzyło dwukrotnie, ale klient powiedział, że on chce to w Power Platform czy innym narzędziu low-code i w niczym innym, koniec. I nawet mam jednego klienta, któremu mówiłem, że to jest duże rozwiązania i wydajnościowo może klęknąć jak na platformę typu low-code. Ja bym raczej to robił custom codem – ale on powiedział „nie. My chcemy iść w pełni świadomie do oporu w Power Platform”.

Czy tam były jakieś układy z Microsoftem, jakieś lepsze stawki – nie mam pojęcia, nie za bardzo mnie to interesowało, natomiast rzeczywiście był taki klient, który powiedział „Power Platform i koniec”.

 

Teraz taki temat, który jest wałkowany wiele razy, ale jestem ciekawy twojej perspektywy. Czy no-code zabierze pracę programistom?

 

Lubię to pytanie. Po pierwsze: zupełnie nie. To nawet nie jest, że nie wierzę w to – ja absolutnie wiem, że tak się nie stanie. Po pierwsze dlatego, że programistów cały czas będzie potrzebna taka chmara, że nie jesteśmy w stanie tego rynku nasycić. Po drugie dlatego, że celem low-code’u nie jest zabrać pracę programistom, bo low-code nie jest tak dobry, czy tak elastyczny, efektywny w działaniu jak custom code.

 

No-code nie zabierze pracy programistom po pierwsze dlatego, że programistów cały czas będzie potrzebna taka chmara, że nie jesteśmy w stanie tego rynku nasycić. Po drugie dlatego, że celem low-code’u nie jest zabrać pracę programistom, bo low-code nie jest tak dobry, czy tak elastyczny, efektywny w działaniu jak custom code. 

 

W związku, z czym do czego takie IT może wykorzystać platformy low-code? Po pierwsze do budowania MVP czy POC, które jak stwierdza, że jest cacy, to będą wdrażać klientowi. Mają już takie szybkie przetarcie, bardzo efektywne, niedoskonałe, ale bardzo efektowne do tego, żeby sobie coś sprawdzić.

Drugi to ludzie z IT są w stanie skupić się na tych rzeczach w rozwiązaniu IT, które muszą być zrobione custom codem i wymagają wiedzy programistycznej. Nazwałbym to, że ci programiści stają się takim IT commando. Wyobraź sobie, że masz aplikację, która ma na celu tłumaczyć dokumentu. Masz jakiś interfejs aplikacji mobilnej, dołączyć dokument ze swoich plików na telefonie, ten plik zostaje zapisany w jakiejś bazie danych, w jakiejś platformie. Z tamtej platformy ten dokument jest brany i tłumaczony. I następnie tłumaczenie tego dokumentu trafia do tej bazy danych, bazy wiedzy. I wszystko to, co się dzieje przed samym tłumaczeniem, czyli to, że jest aplikacja mobilna, przekazanie dokumentu, zapisanie w bazie danych, to to wszystko może być zrobione w sposób low czy nawet no-codowy. Natomiast to mięso, ten takie secret sauce tego naszego całego rozwiązania, czyli to tłumaczenie dokumentów, czyli to, że jest jakaś funkcja czy web aplikacja, która bierze dokument, rozszywa go, tłumaczy, spowrotem zszywa w innych językach i zapisuje do źródła, to to może być robione już zupełnie custom codem. I dzięki temu programiści, ci full koderzy, nie muszą się skupiać na tych, powiedziałbym, prostych dla nich rzeczach jak aplikacja mobilna, uwierzytelnienie, podłączenie się do serwisu czy do bazy danych i przekazanie dokumentów. Zupełnie nie.

Tym się może zająć taki właśnie low-code developer, natomiast oni w tym momencie zajmują się tylko tą kluczową kwestią, czyli rozszycie dokumentów, przetłumaczenie i zszycie, wysłanie na serwer.

To jest pierwsza rzecz, czyli czy programiści stracą pracę przez low-code? Oczywiście, że nie. Natomiast ja bym jeszcze pytanie troszkę rozszerzył, mianowicie: czy w ogóle low-code, jako też mówiliśmy o automatyzacji, zabierze ludziom pracę? Tutaj jest oddzielny wątek, o którym można rozmawiać, ale chciałbym tylko szybko odnieść się do fajnych badań, które były robione przez Unię Europejską w 2018 roku i w trakcie tych badań sprawdzono właśnie pod kątem transformacji cyfrowej dwie branże, branżę spożywczą oraz branżę budowlaną. I zweryfikowano na przykład pod kątem zatrudnienia. Czy ta transformacja cyfrowa, w której się zawiera mnóstwo elementów, nie tylko automatyzacja, bo automatyzacja też, ale na przykład jakieś 3D printing, robotyzacja, również w tym RPA, czyli robots plus automation, czyli taki low-code, który działa na trochę innej warstwie. Mamy IoT, mamy Cybersecurity i tak dalej.

Czy to wszystko spowodowało, że ludzie stracili pracę? I co się okazało: okazało się w tych badaniach, że właściwie 70% ludzi, 70% firm nie zmniejszyło swojego zatrudnienia. 30%, a dokładniej 25% owszem, zmniejszyło, natomiast pozostałe procenty, czyli te 75% to właściwie było tyle samo, bądź jeszcze więcej zatrudnionych. 25% przypadków zwiększono zatrudnienie. To wynika właśnie z tego, że kiedy masz prace, którą automatyzujesz, to właściwie okazuje się, że po pierwsze ktoś musi nad tym rozwiązaniem panować. Ktoś dalej jest odpowiedzialny za proces. Nagle się okazuje, że – ale zaraz, skoro mamy to zautomatyzowane, to my możemy się zacząć rozwijać na innych polach! I nagle się okazuje, że jeżeli ta pani co zawsze przybija pieczątki, teraz może kontaktować się z klientami, z nowymi klientami, bo my przecież już właśnie szybciej operujemy na umowach. Tak naprawdę my cały czas budujemy zapotrzebowanie, dokonując takiej transformacji cyfrowej.

 

Pojawiła mi się taka myśl, czy według ciebie to nie pogorszy takiej i tak już dosyć trudnej sytuacji junior developerów na rynku pracy? To często jest tak, że tym osobom na początku daje się takie prostsze rzeczy, które być może dałoby się samemu zrobić, ale nikomu się nie chce, więc daje się juniorowi, bo zazwyczaj to są takie proste, powtarzalne tematy.

Wobec tego, skoro być może w niedalekiej przyszłości to będzie zastąpione zautomatyzowane i nie będzie tam trzeba wsadzać człowieka, czy to nie spowoduje, że trudniej będzie juniorom dostać pracę, po drugie to wejście nie będzie aż tak płynne, to trzeba będzie już faktycznie jakiś tam bagaż doświadczeń ze sobą mieć, żeby do full kodowej pracy się dostać.

 

Na wielu poziomach myślę, że nie. Po pierwsze dlatego, że platformy low-code wymagają jakiegoś programowania. Nie jest to C-Sharp, tam mówi się o języku jako o języku obiektowym. Jest to jakiś prosty język funkcyjny, ale masz w nim argumenty, masz w nim zapisywanie zmiennych, czyli operacje na zmiennych, masz w nim jakieś kolekcje. Są już więc koncepcje wykorzystywane potem dalej. W związku z czym – i już z tymi koncepcjami jesteś w stanie budować profesjonalne rozwiązanie, w pełni funkcjonalne i użyteczne. Na dobrą sprawę ten low-code to jest taki fajny przedsionek.

Druga sprawa jest taka, że żeby być takim pełnoprawnym programistą, to właściwie praca z pewnym procesem wytwarzania oprogramowania, nie tylko z samym procesem wytwórczym, ale także analizą, a potem wdrożeniem, to w projektach low-codowych jest dużo szybsza, bo masz krótką implementację i w ciągu na przykład 3 miesięcy jesteś w stanie przejść od początku do końca projektu.

W takich zwykłych projektach custom codowych to ten proces często trwa rok. Nieraz niektórzy albo zapomnieli co było na początku, albo nie pracują w firmie. T przejście całej ścieżki procesu wytwarzania czy dostarczania oprogramowania również daje bardzo dużą korzyść. Myślę, że juniorzy dostaną tutaj ogromny wręcz wachlarz możliwości i jeszcze łatwiejszego wejścia w IT.

Inna sprawa, że rzeczywiście na pewno będzie taka – czy może się pojawić taka stygmatyzacja, że „zaraz, ten ziomuś po low-codzie nic nie wie o programowaniu, żaden z niego programista”. To będzie trochę stereotypowe i też będzie wynikać z tego, że są po prostu ludzie, którzy się nie nadają do programowania, a próbują się tam pchać. I to się dzieje tez teraz! Natomiast niektórzy będą mieć swój sufit na końcu low-code’a, czyli wejdą w low-code chcąc iść do programowania i potem zaczną walić w sufit przy programowaniu. Okaże się, że sobie nie dają rady i nagle zostanie na rynku takie wrażenie, że ci low-codzerzy – żadni z nich programiści. Taka jest możliwość, więc przygotowałbym się na to, że po prostu będzie się trochę obrywało low-codem, ale według mnie to jest bardzo sensowne, żeby zaczynać od low-code’u jako takim podejściu, które pozwoli ci poznać specyfikę projektów IT, poznać klientów, różnego rodzaju mechanizmy, technologie, platformy, dowiedzieć się o integracji i tak dalej, zanim się wejdzie w ten custom code i bardzo bym sobie tego życzył, żeby low-code był uczony na kierunkach IT. Żeby low-code pokazywano na pierwszym, drugim roku jako taki przedsionek tego programowania. Zupełnie abstrahując od tego, czy żeby zostać pracownikiem IT warto iść na studia. To oddzielny temat. Ale jak już ktoś idzie na studia to fajnie, jakby tam też o tym uczono. To jest ważna gałąź rynku IT.

 

Pewnie, będzie rosła i zyskiwała na ważności, na popularności.

Ale jakby teraz spojrzeć na tą branżę programistyczną, to mam wrażenie, że no-code to jest taki dodatkowy tool, to jest dodatkowe narzędzie, takie trochę też zadanie dla chętnych. Można to wiedzieć, może ci to coś pomóc, ale nie jest to niezbędne.

Zastanawiam się, czy to za niedługi czas nie będzie już takim community, że wszyscy będą musieli to potrafić, wszyscy programiści. Czy to nie będzie tak jak trochę z Gitem, gdzie nikt już na rozmowie nie pyta, czy go znasz, bo wszyscy zakładają, że to jest na tyle standard i oczywista oczywistość, że musisz go znać, się nie okaże za jakiś czas, że takie, chociażby proste rzeczy związane z low-codem też nie będzie już taki standard. Co o tym myślisz?

 

Myślę, że nie będzie takiej community, bo Git jest akurat tutaj fajnym przykładem, bo on jest bardzo oderwany od platformy. Po prostu repo – możesz się do niego łączyć z języków skryptowych, języków funkcyjnych, języków obiektowych i właściwie nie ma z tym żadnego problemu. Natomiast w przypadku low-code to jest jednak zawsze jakieś powiązanie się z konkretną platformą, więc nie jestem przekonany. To tak jakbyśmy chcieli powiedzieć, że każdy, kto pracuje z C-Sharpem musi kumać Basha, musi kumać Powershella i jeszcze programowanie w Javie.

Z drugiej strony, no w sumie teraz jak mówimy o jakimś full stackowcu, to raczej rozumiem, że ogarniesz jakiś język server side’owy, czyli C-Sharp albo Java, do tego jakiś front, czyli JavaScript najczęściej czy jakieś jego reacktowe czy angularowe wersje, to zawsze są jakieś – języki, które potem się transpirują do tego.

Nie wydaje mi się – natomiast jeżeli mówimy o konsultantach IT, o osobach, które pomagają biznesowi odpowiednio zaprojektować architekturę, solution architect, czyli jakby architekturę rozwiązań, no to tak. To już zdecydowanie będzie konieczne, żeby taka osoba pracowała, na przykład w ramach żartu, projektując Intranet wiedziała o tym, jakie są możliwości. Ile tam jest tych platform, jak one mogą ze sobą współgrać, żeby nie trzeba było wynajdywać koła na nowo, skoro i tak za to płacimy.

Mamy to w licencji na przykład.

 

Okej Michał! To jeszcze pytanie na koniec – co byś doradził takim osobom, które chciałyby wejść w tego typu rozwiązania? Z jednej strony może dla tych, którzy mają jakieś pojęcie o programowaniu, może coś liznęli i też dla tych, którzy w ogóle nie mieli z programowaniem do czynienia, ale gdzieś tam słyszą, że to może być fajna rzecz, która im pomoże czy też w ich firmach pomoże coś zautomatyzować jednocześnie i wejść w jakieś inne buty. Jest coś takiego, od czego mogliby zacząć?

 

Tu na dobrą sprawę wyzwanie jest o tyle, bo tak jak mówiliśmy o tym, że low-code i no-code posiada bardzo dużo różnych platform zależnie od tego, w czym chcesz działać. Czy w marketingu, sprzedaży, IT – wszystko sprowadza się do pytania „a czym chcesz się zajmować? Dokąd dążysz?”.

 

Tu na dobrą sprawę wyzwanie jest o tyle, bo tak jak mówiliśmy o tym, że low-code i no-code posiada bardzo dużo różnych platform zależnie od tego, w czym chcesz działać. Czy w marketingu, sprzedaży, IT – wszystko sprowadza się do pytania „a czym chcesz się zajmować? Dokąd dążysz?”.

 

Jeżeli miałbym tak w ciemno polecić, tak na zasadzie, żeby spróbować tych platform, to tutaj nie byłbym sobą, gdybym nie polecił mojej własnej działki, czyli rozwiązań Microsoftu, w szczególności Power Platfrom, która posiada takie trzy platformy Power Apps do budowania aplikacji mobilnych, Power Automate – automatyzacji, Power BI do budowania raportów i one trzy są narzędziami low-codowymi, ale no-codowo też tam da się coś zdziałać.

One pokazują takie spektrum możliwości tego, co się da takimi platformami zbudować, jak można ich używać, Microsoft ma dużo fajnych samouczków, szkoleń, darmowo dostępnych przez strony dokumentacji Microsoftu. Dodatkowo ja również prowadzę takie szkolenia jak Akademia Aplikacji, mamy kursy szkolące pod te platformy, aczkolwiek jeżeli ktoś zaczyna i tak bardziej jest tego po prostu ciekawy, to raczej zalecam mu korzystać z darmowych materiałów, których na Internecie czy YouTube jest mnóstwo. Wtedy dopiero zobaczy, czy to jest coś dla tej osoby czy nie. Tak bym właśnie polecał.

 

Świetnie. Bardzo ci Michał dziękuję za ciekawą i pragmatyczną rozmowę o tym podejściu low-code, no-code. Na koniec powiedz proszę, gdzie cię można znaleźć w internecie? Może ktoś miałby jakieś pytania, jak się z tobą skontaktować?

 

Serdeczne dzięki za zaproszenie. To jest jeden z pierwszych – o ile nie pierwszy! – podcast, w którym biorę udział, w szczególności pod kątem low-codowym, także jest to dla mnie bardzo duże wyróżnienie.

Jeżeli natomiast chodzi o to, gdzie można mnie znaleźć, gdzie się można ze mną skontaktować, to po pierwsze polecam obserwować mnie na LinkedInie, dodanie mnie na Facebooku. Linki będą w opisie, dobrze myślę?

 

Tak, oczywiście, dodam wszystko!

 

LinkedIn i Facebook. Jestem też na Instagramie, ostatnio się troszeczkę tym bawię, eksperymentuję. Prowadzę też bloga – michalguzowski.pl, gdzie również publikuję swoje przemyślenia, refleksje z zakresu zarządzania czy na inne tematy.

Można się też ze mną kontaktować mailowo, czyli m.guzowski@developico.com

 

Świetnie, oczywiście wszystkie linki będą w notatce. Jeszcze raz ci Michał bardzo dziękuję i do usłyszenia, cześć!

 

Dzięki serdeczne!

 

To na tyle z tego, co przygotowałem dla ciebie na dzisiaj. Z pewnością narzędzia low-code czy no-code weszły już na salony i warto się z nimi zapoznać. Trzeba jednak pamiętać, że to tylko narzędzia i że są miejsca, w których ich użycie dobrze pasuje, jak również takie, gdzie ich zastosowanie jest nieoptymalne.

Jeśli ten odcinek był dla ciebie inspirujący i przydatny, odwdzięcz się proszę recenzją, oceną lub komentarzem w social mediach. 

Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl

Zapraszam też do mediów społecznościowych.

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o no-code, low-code.

Zapraszam do kolejnego odcinka już za tydzień! 

Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.