Low-code / no-code

Krzysztof Kempiński
Feb 8 · 17 min read

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Michałem Guzowskim o low-code / no-code.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

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.

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.

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.

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.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-103-low-code-no-code/

kkempin’s dev blog

Dev and life blog.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store