Cześć, dzień dobry. Witam was w podcaście IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce.Podcast IT i Biznes kieruje do właścicieli firm oraz menedżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek 30. No Code, Low Code.

Czy to koniec software house'ów? Czy no code i low code to rewolucja, która wywróci rynek technologiczny do góry nogami? A może to tylko chwilowy trend, który wspiera, ale nie zastąpi pracy programistów? W tym odcinku bierzemy na warto te popularne technologie, analizując jak wpływają na branżę i odpowiadamy na pytanie, czy software house'y mają się czego obawiać. Głównymi punktami tego odcinka będą po pierwsze, czym jest no code i low code, wyjaśnimy różnice i przykłady zastosowań. Po drugie, czy te technologie mogą zastąpić programistów, omówienie tutaj ich potencjału i ograniczeń.

Po trzecie, dlaczego no code to nie wszystko, czyli trochę o problemach ze skalowalnością, trochę o problemach z dostępem do kodu, ale też i problemami potencjalnymi z bezpieczeństwem, na co tutaj szczególnie zwrócić uwagę. A także po czwarte, jak software house'y mogą wykorzystać te technologie trochę o szansie na adaptację i przewagę konkurencyjną. Nie przedłużając, jeżeli ten temat jest dla Ciebie ciekawy, to znaczy jest dla Ciebie ciekawe, w jaki sposób można dziś szybciej i taniej tworzyć aplikacje, z czym to się jest, z czym to się wiąże, serdecznie zapraszam do części merytorycznej dzisiejszego odcinka.

Cześć, dzień dobry. Witam Was serdecznie w kolejnym odcinku mojego podcastu i bierzemy od razu na warsztat temat, który już od jakiegoś czasu robi sporo zamieszania w świecie technologii. Jednych rozgrzewa, innych nazwijmy to mrozi.

Temat technologii no code i low code, czyli takie nazwijmy to dwie magiczne frazy, które dla jednych brzmią jak początek rewolucji, a dla innych jak coś, co może wywrócić biznes do góry nogami, szczególnie taki biznes typowo software house'owy, gdzie coś po prostu ludzie programują. No i właśnie, czy to jest koniec software house'ów? To jest to nasze tytułowe pytanie, które możemy trochę bardziej rozwinąć jako to, czy my jako specjaliści od budowy zaawansowanego oprogramowania powinniśmy się bać, a może no code, low code to po prostu kolejny krok w rozwoju technologii, który otwiera przed nami nowe możliwości. Dziś podzielę się z Wami naszym spojrzeniem na ten temat, zarówno z perspektywy software house'u, jak i też osoby, która stanowczo widzi potencjał w tych narzędziach.

No i tak naprawdę zacznijmy od podstaw. Jeżeli te terminy są dla Was nowe, to wyjaśnię w skrócie o co w nich chodzi. No code to narzędzia, które pozwalają tworzyć aplikacje, strony czy różnego rodzaju automatyzacje bez pisania kodu.

Czyli to tak jakbyś chciał skorzystać z takiej magii, chciał, chciała, czyli bez ani jednej linijki kodu można było wykorzystać możliwość wykonania jakiejś automatyzacji czy na przykład już nawet całej aplikacji. Można powiedzieć, że to jest taki spełniony sen na przykład każdego marketingowca czy kogoś, kto chciał uzyskać jakiś efekt biznesowy, jakąś automatyzację, ale niekoniecznie z udziałem prac programistycznych. No bo umówmy się, jeżeli jako marketingowiec byłbyś, byłabyś w stanie sobie przygotować sama jakaś landing page czy przygotować jakąś automatyzację, że lidy, które zostaną zapisane przez tę landing page znajdą się w Twoim CRM automatycznie, jeszcze podzielone na jakieś kategorie z jakimiś etykietami, z wykorzystaniem AI pojawi się też jakaś segmentacja tych lidów, no to czad można powiedzieć i robić takie rzeczy nie czekając na gdzieś tam dział IT, który często może być po prostu zajęty swoimi tematami, no to na pewno bardzo fajna sprawa.

Z kolei low-code to coś takiego już bardziej zaawansowanego, czyli to jest już taki rodzaj powiedzmy platform, rodzaj technologii, która bardziej przydaje się programistom, którzy mogą zaoszczędzić czas dzięki gotowym komponentom, trochę coś na zasadzie takiego drag and drop, czyli tak jakby możliwość wykorzystania jakiegoś szablonu czy zbioru elementów, takie układanie z klocków, ale z możliwością dostosowania tego co w pojedynczym klocku, czy co w zestawie tych klocków pojedynczych elementów można wykorzystać. No dobra, czyli teoretycznie możemy wykorzystać jakieś gotowe mechanizmy no-code'owo, czyli bez użycia kodu coś już stworzyć konkretnego, czy low-code'owo, czyli z bardzo małą ilością programowania, programiści bądź nawet osoby nietechniczne, które delikatnie z nielizną programowania albo z czatem GPT wyrzeźbią jakiś kod, będą w stanie sobie coś zaprogramować. Czyli można by przyjąć, że programiści odejdą tutaj do lamusa, ale zanim zaczniemy planować świat, w którym kodowanie przestaje już zupełnie istnieć, spójrzmy na to trochę inaczej.

No bo zobaczcie, nie tak dawno na rynku pojawił się na przykład czat GPT, czyli coś co znana dzisiaj chyba każda osoba, która działa w internecie, ale czy pamiętacie jakie były pierwsze reakcje? No właśnie w świecie marketingu na przykład często były takie reakcje typu, że copyrighterzy znikną z rynku, ten zawód już umiera, ale czy finalnie tak się stało? No według mnie nie. Znowu pojawiła się sytuacja, w której copyrighterzy, którzy potrafili zaadaptować się i wykorzystać AI, wykorzystać czata GPT w tym wypadku jako wsparcie, a nie zagrożenie, mają się świetnie. Bo wiecie co? Tak naprawdę ta kreatywność, strategia i umiejętność rozumienia odbiorcy to jest coś, czego AI nie zastąpi w tym wypadku.

I uważam, że podobnie jest z no-kodem i low-codem, czyli tak samo jak czat GPT nie zastąpił copyrighterów, tylko wspomógł ich pracę, którzy umiejętnie potrafią z tej platformy, z tej technologii korzystać, tak samo platformy no-kodowe, low-kodowe moim zdaniem nie zastąpią software house'ów. Oczywiście one będą wspierać, by pewne rzeczy wykonać łatwiej i szybciej, bez takiej typowej nauki programowania, szczególnie w przypadkach, które są biznesowo dość powtarzalne. No i teraz właśnie.

Gdzie to faktycznie zadziała? Gdzie warto wykorzystać low-code i no-code naszym zdaniem? Według nas sprawdzą się one tam, gdzie potrzeba szybkości i prostoty. Weźmy sobie, już idąc tym przykładem, czy to marketingowego zespołu, czy po prostu pojedynczego marketing managera. Wyobraźmy sobie, że chcesz szybko stworzyć jakiś landing page, podpiąć właśnie formularz do CRMA, a może ustawić wysyłkę automatyczną maili po zapisaniu do tego landing page'a.

Masz do tego narzędzia takie jak Webflow, Zapier czy Bubble, gdzie tak naprawdę bez czekania, bez budżetu na zespół programistów jesteś w stanie tego typu potrzeby pokryć samodzielnie. I super, bo to oszczędza czas, oszczędza pieniądze. Sam widzę, że wiele firm korzysta z tego z powodzeniem.

Zresztą my w niedalekiej przyszłości też budowaliśmy stronę internetową właśnie np. korzystając z Webflow właśnie dlatego, żeby skorzystać z tej szybkości wdrożenia i możliwości szybkiego budowania np. kolejnych landing page'y i ustaleń po prostu, żeby ten time to market danego landing page'a był jak najkrótszy.

Ale tu pojawia się wielkie ale tak naprawdę, no bo, no właśnie, dlaczego Software House i zawód programistów, nazwijmy to, że nie wymrą, czyli moim zdaniem po prostu tak się zadzieje. Przez długi czas jeszcze programiści jednak będą potrzebni. No bo no-code i low-code, jak to takie rozwiązania uniwersalne, są świetne kiedy mamy pewne uniwersalne, powtarzalne problemy, które są podobne w różnych firmach, ale oczywiście te technologie przez to, że są uniwersalne, mają też swoje ograniczenia.

I teraz kiedy mówimy o zaawansowanych projektach, takich, które muszą być skalowalne, muszą być bezpieczne, nie muszą być skrojone na miarę, czyli po prostu dopasowane do procesów w firmie, a nie na odwrót, no to no-code często przestaje wystarczać. No wyobraźcie sobie budowę platformy fintechowej np. czy aplikacji do analizy danych w czasie rzeczywistym, albo systemu ERP dla dużej firmy, takiego typowo autorskiego ERP, gdzie już te gotowe rozwiązania nie są wystarczające.

Czy myślicie, że dałoby się to zrobić w no-code? Według mnie nie. W sensie nie dałoby się, żeby to miało ręce i nogi, bo nie jest to tylko kwestia ograniczenia technologii. Problemem jest tutaj też dopasowanie po prostu takich narzędzi do specyficznych potrzeb.

I no-code to trochę jak takie ubranie one-size-fits-all, czyli takie na pierwszy rzut oka wygląda dobrze, ale jak już przyjdzie co do czego, to może gdzie nie gdzie uwierać. I korzystając z platform no-code, low-code tworzysz rozwiązania w ramach ich środowisk. To też trzeba wziąć pod uwagę.

Czyli oznacza to, że masz dostęp do funkcji i możliwości, które oferuje dostawca danej platformy, czy to no-codowej, czy low-codowej. Ale to wszystko. Czyli nie możesz wejść pod maskę, nie możesz zmodyfikować kodu, by lepiej odpowiadał twoim potrzebom.

W wielu przypadkach możesz zmienić kolor, ale tego silnika już nie możesz zmienić. Czyli tak jakby masz ten zbiór gotowych właśnie klocków, gotowych elementów. W nich delikatne możesz modyfikacje wprowadzić, szczególnie w platformach low-codowych.

Możesz po prostu jakiś customowy, czyli tak zwany niestandardowy kod wstawić, który w pewnym momencie coś zrobi na przykład na zbiorze danych. Natomiast nie możesz pewnych zachowań już w tych platformach zmienić. Musisz po prostu działać według takiego flow, jakie dane platforma ci zapewnia.

Po prostu. Idąc dalej. Rozwiązania oparte od no-code często nie są wystarczająco wydajne, aby sprostać duże ilości danych.

Na przykład w zakresie przetwarzania danych, czy integracji z innymi systemami. Tutaj warto zwrócić uwagę na to, że często jeżeli mamy bardzo, bardzo duże zbiory danych, a na platformach no-codowych często rozliczamy się za wykonane akcje, może okazać się, że ich przetwarzanie w dużej ilości będzie zwyczajnie drogie też. Powinien to być kwestia samej wydajności.

Może być to po prostu proces bardziej czasochłonny, ale może być to też proces stosunkowo drogi, niż gdyby mieć swoje rozwiązania, które byłoby napisane. Ale to wszystko zależy oczywiście od konkretnej sytuacji, którą należałoby przeanalizować. To nie jest tak, że to jest mój werdykt one size fits all, na każdą sytuację taki sam.

To musimy na pewno brać pod uwagę. W takim tradycyjnym podejściu, kiedy realizujemy jakiś projekt po prostu jako software house, na pewno możemy od razu przewidzieć rozwój projektu i w pewnym sensie też zaprojektować go tak, by skalowanie tego rozwiązania było możliwe bez większych problemów i bez nieprzewidzianych nakładów czasu i pieniędzy. Jeszcze jeden punkt, na który chciałbym zwrócić w kontekście platform no-codowych czy low-codowych, to jest aspekt bezpieczeństwa.

Tak naprawdę w ramach tych technologii, czy tak naprawdę w ramach dostawców platform tych technologii, jesteśmy w dużym stopniu zależni od dostawcy platformy. To jest kwestia i bezpieczeństwa, i kwestia funkcjonalności. Tak naprawdę oznacza to, że bezpieczeństwo danych użytkowników będzie zależało od poziomu zabezpieczeń danego dostawcy, więc tego trzeba być po prostu świadomym.

To jest niby oczywiste, ale można o tym zapomnieć, dlatego to tak tutaj podkreślam. Też w przypadku awarii dostawcy, czy na przykład ataku na jego infrastrukturę, twoje rozwiązanie może przestać zwyczajnie działać. No i też jest kwestia tego typu, że nie masz do końca pełnej kontroli nad tym, gdzie dane są przechowywane, czyli w przypadku na przykład RODO też trzeba się upewnić, czy te dane są przechowywane we właściwej lokalizacji no i też po prostu, czy dana platforma spełnia wymogi tak naprawdę RODO, czyli w przypadku firm, które przetwarzają wrażliwe dane typu w finansach, dane zdrowotne, medyczne, czy na przykład w przemyśle, może być to duże ryzyko, żeby z tego typu platform korzystać dla jakichś właśnie danych wrażliwych.

Podsumowując dzisiejszy odcinek, my jako firma programistyczna, jako Software House widzimy w no-code i low-code na pewno potencjał, na pewno jako takie wsparcie, szczególnie w przypadku, kiedy korzystamy już z takich narzędzi, żeby przyspieszyć prototypowanie, czy na przykład zautomatyzować wewnętrzne procesy i to też jest taki świetny sposób na szybkie pokazanie klientowi, jak może wyglądać jego pomysł, czyli jeżeli mamy różne fazy budowy produktu, mamy tak zwaną fazę proof of concept, czyli taką fazę, kiedy próbujemy po prostu sprawdzić, czy tego typu rozwiązanie, jakie próbujemy zrobić to faktycznie ma sens, potem często mamy fazę MVP, czyli budujemy już jakąś taką w pełni stabilną działającą aplikację z jakimś interfejsem dla użytkownika, gdzie to użytkownik może sam jakiś proces wykonać, czyli jako przykład proof of concept możemy rozumieć na przykład jakiś skrypt, który generuje nam jakiś raport, czego wynikiem końcowym jest po prostu ten raport, który możemy sobie obejrzeć, a już jako MVP możemy rozumieć na przykład aplikację, w której możemy sobie sparametryzować pewne rzeczy, no i według tego generuje nam się dopiero raport, czyli już mieć ten taki kroczek dalej, że już widzieć więcej, a w wersji na przykład docelowej aplikacji możemy mieć różne rodzaje raportów z różnymi kolumnami, w oparciu o różne dane, czyli jest już takie bardziej, bardziej rozbudowane narzędzie na przykładzie, znaczy idąc tym przykładem, po prostu na mechanizmie, który został już zwalidowany, czyli najpierw skrypt, który buduje nam raport, potem dopiero już interfejs użytkownika, według którego użytkownik może na przykład jakiś jeden określony raport sobie zbudować, no i potem już cała aplikacja, która ma te wszystkie możliwości takie, no względem różnych po prostu raportów, różnych możliwości jego filtrowania. No i teraz właśnie, kiedy przychodzi do budowy tego finalnego produktu, czyli na przykład tej aplikacji, która ma różne raporty z różnymi kolumnami, różną opcją filtrowania danych, to wtedy w grę właśnie wchodzi nasze doświadczenie, wiedza i kreatywność, których no-code sam sobie po prostu nie zastąpi i z reguły już w tym konkretnym przykładku będzie niewystarczający. Tutaj trzeba na to na pewno wziąć po prostu to pod uwagę, że klienci będą nadal potrzebować ekspertów, którzy zrozumieją ich potrzeby i dostarczą rozwiązania, które będą działać później niezawodnie przez tak naprawdę lata.

To, gdzie my polecamy narzędzia no-code'owe, low-code'owe, to są proste procesy automatyzacyjne, czyli miejsca, gdzie chcemy dane przesłać z punktu A do punktu B, szczególnie jeżeli tych danych nie ma dużo, no to wtedy nie opłaca się pisać jakichś autorskich integracji. To są też takie bardzo mikroskopijne aplikacje, gdzie to są proste zbiory danych, na których też nie wykonuje się dużych czynności i one też nie są jakieś super duże, no i tam, gdzie nie ma też jako tako danych wrażliwych, których nie musimy się wtedy obawiać, jakieś kwestie związane z RODO i tego typu kwestie. Uważamy, że to będzie taki początek nowej współpracy między technologiami a software house'ami i tak naprawdę software house'y, które się zaadoptują do technologii low-code'owych no-code'owych i będą w dobrych procesach biznesowych je wykorzystywać, mają na pewno tutaj szansę wykorzystać ten, nazwijmy to trend jako stanowczy, jako przewagę konkurencyjną, a nie jako zagrożenie.

Jak zawsze czekam na Wasze komentarze w tym temacie. Jeśli ten odcinek Was zainteresował, to podzielcie się swoją opinią, to jest dla mnie naprawdę ogromna pomoc, każdy feedback jest tutaj mile widziany, a jeśli szukacie partnera do budowy dedykowanego oprogramowania albo właśnie do wdrożenia jakiegoś próbow konceptu low-code'owo albo no-code'owo, to wiecie gdzie nas znaleźć, ale w razie czego podpowiem, że dane kontaktowe zawsze są w opisie do danego odcinka. Dzięki za dziś i do usłyszenia za tydzień we wtorek.

Cześć!