Transkrypcja
Wstęp: Tradycyjne podejście, czyli jak nie zaczynać
Cześć, witamy w kolejnym odcinku podcastu.
Cześć.
Tym razem bez gości, mamy tylko Michała i mnie. Możemy już sobie wygodnie rozłożyć łokcie.
Nooo… Nie to, że gości nie lubimy, bo wręcz przeciwnie.
Oczywiście gości lubimy i goście jeszcze będą.
Ale może kiedyś dorobimy się jakiegoś większego studia, tak, niż to, co mamy, to i łokcie będą komfortowe.
Zwłaszcza dla gości.
Zwłaszcza dla gości, tak.
To co dziś hejtujemy?
Poddamy konstruktywnej…
Konstruktywnej…
No właśnie, często rozmawiamy sobie o legacy. Nieraz tutaj wybrzmiało, że legacy nas nie przeraża i legacy jest…
Czyli jak zrobić legacy porządne?
Jak zrobić legacy… No, do tego też pewnie dojdziemy w toku tematu, ale nawet tam czasami przydarza się coś innego niż legacy, o dziwo. Gdzieś tam jakiś greenfield wpadnie, jakiś nowy projekcik. No i teraz, jak za taki projekcik się zabrać? Czyli co, przychodzi do nas klient, mówiąc, że chce projekt, albo może my mamy jakiś pomysł na projekcik? Czyli co, klasycznie? Stawiamy serwer, Springa…
No to nawet jak my mamy, to jeszcze gorzej…
Zabieramy się tak, tak jak zwykle się zabieramy, czyli stawiamy tutaj całą infrę, bazę danych, oczywiście…
Ra-ta-ta-ta-ta i jedziemy, nie?
…migracja SQL-owa, frontendzik, jakiś Node przed tym stojący, no i jakiś kubernetes, bo to wiadomo, zaraz musi być rozbudowane wszystko i…
To się musi skalować. Nie ma „letko”.
Musi się skalować. Nie wiemy, czy biznes wypali, ale musi się skalować.
Czym jest Rapid Development?
W zależności od doświadczenia, po kilku dniach albo po dwóch tygodniach mamy przygotowaną naszą tutaj „Hello World”, wystawione jest na weba, no i wtedy klient mówi, że…
Ale będzie gotowy na skalowanie już.
… już fundusze się skończyły.
No to jak to klient mówi: „To kto wie, co gorsze – czy to, kiedy nasze się kończą, czy klienta”.
No pewnie klienta. Nasz skalowalny „Hello World” niestety nie zdobędzie rynku.
Pewnie mu trochę zabraknie.
Może by tak dało się to zrobić inaczej?
No tak, słyszałem, że to się tak nawet da i to się nazywa Rapid Development.
Rapid, właśnie…
To takie jest, siadamy i tak bardzo szybko piszemy. Szybko piszemy i po prostu mamy.
No to jest, to jest taka koncepcja, którą sobie tutaj ukuliśmy, troszkę, i takie podejście, które testujemy w różnych projektach. No my przez Rapid Development… Nie będziemy tutaj poruszać jakby tematów biznesowych na zasadzie szybkiej iteracji pomysłu, takiego Agile’owego podejścia, bo to jest jakby inna strona tego Rapidu. Oczywiście, raczej takie proste… może nie tyle proste…
Też ważna strona i też, i co ważne jest, żeby to było zrobione, zanim my siądziemy do tego Rapidu.
Zdecydowanie.
Bo jak my siądziemy i będziemy tutaj błyskawicznie wymyślać koncept, to już nie będzie taki Rapid sam w sobie, nie?
Dokładnie. Więc to, to jest też strona tego samego medalu o nazwie „tworzenie aplikacji” i „szybkie tworzenie aplikacji”, ale chyba bardziej byśmy teraz chcieli skupić na takim podejściu technicznym i co możemy zrobić z naszej strony, z takiej strony czysto inżynierskiej, żeby faktycznie ten nowy produkt czy nową aplikację, czy nawet nasz jakiś pomysł, który też możemy mieć na coś, żeby dowieźć szybciej troszeczkę. Żeby jednak no nie czekać takiego standardowego cyklu „trzech lat”… na dowiezienie feature’a, tylko żeby… No, czy jest w ogóle, czy jest możliwe, żeby to zrobić szybciej?
Nie, to się nie da…
Trzeba trochę chyba zmienić takie, taki swój mindset i długo siedząc w takich rozbudowanych, cięższych projektach, gdzie wiadomo, to trzeba usiąść na spokojnie, trzeba sobie wszystko dobrze przemyśleć, wiadomo też, pozmieniać w wielu miejscach, bo mamy, mamy spaghetti, pozmieniać trochę testów… No, w takim greenfieldzie czy naprawdę w projekcie na początku, no jednak to ta praca chyba jest troszkę inna, a przynajmniej powinna być.
No jak już zaczynamy coś tak na zielono, całkiem elegancko, nie, to przynajmniej dołóżmy trochę tych starań, żeby na początku przynajmniej, nie, żeby to jeszcze przez pierwsze miesiące nie zaczynało przypominać legacy kodu.
No tak, tam gdzieś po roku to już pewnie spoko.
Później sobie oczywiście poradzimy, bo my to wiemy, jak sobie radzić z legacy kodem, zwłaszcza z naszym własnym, także luz, nie. Ale tutaj żeby, żeby ten, faktycznie można było mówić o takim szybkim wytwarzaniu aplikacji.
Fazy projektu: PoC, prototyp i MVP
Właściwie jeszcze musimy rozgraniczyć pewne pojęcia, no bo czy my wytwarzamy aplikację tutaj taką pełnoprawną… i dajmy na to, że już go zdążyliśmy wtajemniczyć albo na przykład sam w ogóle z tą koncepcją przychodzi i mówi: „Spoko, to już jest nie mój pierwszy projekt, tylko siedemnasty. Dwanaście mam w koszu, więc git. Kilka tam zadziałało ładnie, a ten już bym chciał zrobić tak, żeby to było z głową zrobione”. Czyli no po prostu nie przepalić tej swojej kasy, jaką mam na to, tak, i żeby szybko dostać informację zwrotną, czy te pomysły w ogóle działają, nie. Czyli i zadaje nam to pytanie… To może jak taką scenkę odegramy – ty jesteś klient, tak, zadajesz to pytanie.
Czy to się da zrobić?
Czy to się da zrobić? No nie, nie da się.
Dziękuję bardzo, pouczająca scenka.
W innej wersji też, w innej wersji też, ale nie, tak naprawdę to to, to taki żarcik branżowy, bo to się da zrobić i my to robimy, i ostatnio właśnie zrobiliśmy.
Pytanie: czemu tak drogo?
Czemu tak drogo? To też ja jako klient mówię: „Czemu tak drogo?”.
Ta scenka… no bo to nie są tanie rzeczy. Wszystko kosztuje.
To… no właśnie, właśnie. Też możemy zapytać klienta, którą z tych dwóch słynnych rzeczy chce mieć: szybko, tanio czy dobrze? I drogi kliencie, wybierz tylko dwie.
Dwie z trzech.
Dwie z trzech, tak, tak. Bo my trzech to nie dostarczamy, to, to nie ma, nie ma trzech. To nikt nie dostarcza. Nie ma, nie ma szans.
A może da się to jakoś pogodzić?
Może. No właśnie, i tutaj kwestia tego mindsetu i, w miarę dobrze, to ona by tak, jak to tak po naszych tutaj ćwiczeniach można by wnioskować, ona odgrywa taką dość istotną rolę. No bo my możemy być nastawieni na to, że owszem, zrobimy sobie taki… już będziemy go nazywać bardziej prototypem niż jakimś tam takim PoC-em zwykłym, proof of concept, ale to jeszcze będziemy lawirować między tymi pojęciami. Bo koniec końców klient by chciał, żeby skończyło się na MVP.
MVP to jest taka fajna rzecz, że to jest… to takie fajne… nigdy nie umiem wymówić tego w środku… minimum viable product, tak. Czyli minimal…
Udało się.
Dzięki. Także tak, coraz lepiej mi to idzie. Coś takiego, co już ma minimalną funkcjonalność zauważalną i może nawet pretendować do miana jakiegoś tam produktu i daje wartość, tę wartość, tak. Bo bo jeszcze się też kiedyś spotkałem z takim tłumaczeniem tego skrótu MVP na minimum value product, albo jakiś valuable, czy coś w ten deseń. Czyli, że taki pokrewne, troszkę pokrewne, że już pokazuje, że to jest produkt, który ma tą minimalną wartość biznesową, bo klient oczekuje, że jego biznes zyska, jak my mu dostarczymy soft, który te jego wartości biznesowe potrafi obsłużyć, nie. Więc on do nas przychodzi z tym czymś i chce te wartości biznesowe po prostu mieć w naszym, w tym swoim produkcie, i prosi nas o to, czy możemy mu go zrobić szybko.
Generalnie tak też z obserwacji może wynikać, że taki klient to w ogóle ma takie nastawienie przeważnie, nie, że chciałby szybko, oczywiście, no i przeważnie tanio, nie. A dobrze, to jak jakby było dobrze, to to dobrze. No właśnie, wspomniałeś tu już o MVP, jeszcze tak może zróbmy krok wstecz, cofnijmy się do tyłu, albo cofnijmy się do tyłu. No bo tutaj też już przewinęły się właśnie pojęcia jak PoC, jak MVP, czasami się jeszcze pojawia prototyp, i co właściwie te wszystkie pojęcia oznaczają?
Bo tutaj one generalnie jakby określają pewne fazy projektu i te fazy, one też pomagają właśnie nam faktycznie urzeczywistnić tą prędkość. No bo faktycznie, jeśli chcemy od razu zrobić gotowy produkt, no to nie oszukujmy się – to nie będzie szybko. To nie będzie tanio też pewnie.
To już mówiliśmy, to nie są tanie rzeczy.
To nie są tanie rzeczy, natomiast jednym z wyjść…
Ale dobrze może być.
Dobrze może być. Tak, oczywiście, to chociaż tą jedną rzecz warto byłoby dowieźć, bo inaczej to… Ale może tak jeszcze pokrótce sobie przybliżmy, czym są te właściwie te terminy i kiedy można powiedzieć… To są oczywiście takie trochę luźne definicje, może pomijając MVP, które jest takie bardziej restrykcyjne. Już trochę się utarło też MVP, i trochę się utarł sam termin PoC, czyli taki proof of concept. Z prototypem czasami jest, czasami jest używany zamiennie. No tutaj można to różnie definiować.
Natomiast czasami proof of concept używa się bardziej w kontekście troszkę takiego technicznego sprawdzenia, czy jakiś koncept rzeczywiście jest w ogóle realizowalny. Załóżmy na przykład, że mamy, nie wiem, chcemy wykorzystać jakiś ciekawy algorytm sztucznej inteligencji, żeby zrobić jakąś aplikację rozpoznawczą czy czy klasyfikującą…
I chcemy siłę grawitacji na Słońcu na przykład.
Na przykład, bardzo dobry przykład i bardzo życiowy, życiowa aplikacja. No i chcielibyśmy w ogóle technicznie wiedzieć, czy coś takiego jest możliwe. Sprawdzić sobie pokrótce, może jakieś modele przetestować, zobaczyć co…
Albo chociażby narzędzi użyć jakichś, gdzieś tam mamy w zakresie zasięgu.
W ramach proof of conceptu możemy dokonać takiej technicznej walidacji, czy to w ogóle jest zwalidalne, można powiedzieć. Czy mamy algorytmy, czy mamy narzędzia, żeby to wykonać. Na tym etapie taki proof of concept to może być w ogóle bardzo taki deweloperski koncept, to jeszcze na pewno nie będzie aplikacja, którą gdzieś tam będziemy wystawiać na świat. Może coś, co pokażemy na jakieś maszynie naszemu naszemu biznesowi czy nawet sami sobie, żeby sprawdzić, czy nasz własny pomysł jest jest jakby do zrobienia, można powiedzieć.
Natomiast w sytuacji, kiedy mamy takie zwykłe biznesowe aplikacje, no to ten tak, etap takiego proof of conceptu i prototypu troszeczkę się zlewają. No bo w tym momencie bardziej już mówimy o takiej bardzo, bardzo wstępnej wersji naszego naszego systemu, naszego projektu i czymś, co już rzeczywiście możemy sobie zbudować, możemy sobie uruchomić, może też wystawić na świat i pokazać właśnie klientowi. To jest taka pierwsza walidacja tego pomysłu, pokazanie właśnie jakichś bardzo wstępnych szkicy interfejsu czy funkcjonalności. No i wtedy generalnie staramy się ograniczyć, ograniczyć zakres pracy.
Czyli to jest jeszcze level niżej, poziom niżej pod MVP. Czyli w tym momencie znika nam trochę to słowo „product”. To w tym momencie nie będzie produkt. Czyli generalnie nie wystawiamy tego użytkownikom, chyba że bardzo wąskiej, testowej grupie tych użytkowników. Więc jeśli to nie będzie produkt, no to też nie musi mieć wszelkich jakby takich cech produktu.
Czyli wiadomo, nie musi być pewnie stabilny, nie musi…
Znamion. Nie musi być stabilny, nie musi być, wiadomo, pewne jakieś rzeczy…
Nie musi działać.
Nie musi działać, ale musi już jakby wykazywać chęć do działania i musi jakby wywalidować te pomysły czy te pewne założenia, które które nasz projekt w tym momencie sobie sobie zakłada.
I to jest fajny taki etap, żeby tutaj może się zastanowić nad rozumieniem pojęć. Bo to my sobie tutaj już po naszej stronie, po stronie technicznej, utarło się też, że ten cały proof of concept, zwany potocznie „pocem”, tak po naszemu, albo jak jest mały, to „pocykiem” – czasem się takiego pocyka robi – to on jest właśnie do sprawdzenia technikaliów. Czy przypadkiem to coś takiego fajnego, co nam by tu się przydało, zadziała. Jak zadziałało w tym pocu, jest spoko, możemy użyć do właśnie budowania prototypu, gdzie na przykład klient by mógł za taki proof of concept uważać już ten prototyp, nie. Że on… w sensie jemu zależy na tym, klientowi, żeby już jednak jakaś taka… te znamiona tego produktu gdzieś tam już były, nie. I wtedy on może sprawdzić to na swojej grupie jakiś tam pierwszych tych użytkowników i może stwierdzić: „dobra, ten dowód tego przydatności konceptu”, jakby to tak koślawo przetłumaczyć, nie, „to on faktycznie ma sens, bo użytkownik zrozumiał, co tam się w ogóle wyrabia”.
Czyli okej, nie tylko, że to, co dla klienta będzie tym proof of concept, dla nas może już być takim bardziej w stronę zmierzającym czymś w stronę prototypu, który następnie rozbudujemy aż do takiego MVP, nie. No i teraz ten ten właśnie ten ten pocyk, w sensie to, co przejdzie z tych naszych… w ogóle możemy mieć więcej niż jeden proof of concept, nie, bo na przykład kilka rzeczy sprawdzamy. One dopiero się złożą w ten cały prototyp, nie.
Bo to jest właśnie też najważniejsza część takiego proof of conceptu – on w ogóle nie musi być realizowany w docelowych technologiach, na docelowych platformach, które mamy gdzieś tam, powiedzmy, założone w przyszłości. Żeby właśnie przyspieszyć walidację tego pomysłu, możemy zdecydować się na troszkę inne narzędzia, niż docelowo byśmy…
Pułapka inżynierskiego myślenia i prototyp bez backendu
Właśnie na tym też ma polegać ta prędkość tej walidacji. To nie jest tylko szybka walidacja pomysłu biznesowego, czyli sprawdzenie tego naszego założenia, ale chcemy to umożliwić przez szybsze dostarczenie tego oprogramowania. Więc jeśli wiemy, że na przykład jakiś framework czy jakieś rozwiązanie techniczne sprawi, że dostarczymy to rozwiązanie szybciej, to możemy wtedy tego użyć. I właśnie to jest jakby największa zaleta takiego prototypu czy takiego proof of conceptu, że możemy zdecydować się na zupełnie różny zestaw narzędzi. Czasami nawet może na brak pewnych elementów w ogóle w naszym stacku.
Jak na przykład wyrzucenie backendu. Na co to komu?
Na co to komu. No bo jeśli na naszym etapie możemy sobie poradzić na przykład tylko z frontem albo w ogóle, nie wiem, z aplikacją konsolową, jeśli to jest jakiś bardziej do obliczeń, czy może jakiś taki, że tak powiem, narzędzie innego rodzaju, jeśli to jest przyspieszy faktyczną walidację pomysłu…
Konsole się gry nazywają.
Konsolowe. Nie o takie, to może chodziło, ale nie takie konsole. Nie o takie konsole, ale wszystko, co przyspieszy jakby dojście do momentu walidacji tego naszego pomysłu biznesowego, a niekoniecznie będzie realizowane w ten taki techniczny, nasz docelowy sposób, to naprawdę warto zrobić i warto użyć czasami nawet dziwnych rozwiązań, jeśli tylko potrafimy sprawdzić, sprawdzić to rozwiązanie.
Czasami to nawet się może sprowadzać wręcz do takich mniej lub bardziej interaktywnych makiet interfejsu czy w ogóle samej aplikacji, można powiedzieć frontowej, która okej, będzie działać jako aplikacja frontowa, ale kto powiedział, że musi zapisywać cokolwiek w bazie danych? Czy to jest na tym etapie w ogóle ważne, że ja, robiąc jakąś akcję, zapiszę sobie to w bazie, a nie na przykład w moim Local Storage albo gdzieś w innym miejscu, które nie jest jakieś persystentne? Jeśli sprawdzimy nasz pomysł i to nie przeszkadza w sprawdzeniu, no to to jest jak najbardziej okej rozwiązanie.
Tak, to wymaga tylko właśnie tego zrozumienia, bo bo teraz jak na przykład ja będę klientem, tak, i teraz zapytam ciebie: „No dobrze, no to teraz zrobimy coś, co później będzie może zostać użyte w wersji docelowej, tak?”.
Nie, drogi kliencie, niekoniecznie.
O matko, to ja teraz co, wywalę… zapłacę razy dwa i to wszystko do kosza?
Właśnie, i tutaj jest mały haczyk. Tutaj jest mały haczyk, bo tak naprawdę technicznie, okej, sporo rzeczy może być do kosza, ale tak naprawdę koncepcja…
Zależy. Niekoniecznie, bo jeśli tego backendu nie zrobimy, to nie musimy go wyrzucać do kosza, bo go nie ma po prostu.
Dobre. I tu jest nasza oszczędność.
Tu jest nasza oszczędność. Czyli generalnie nie opłaca się robić backendu.
To jest za daleko idący wniosek i proszę takich wniosków nie wyciągać. Przepraszam, ale właśnie o to chodzi, że przez ograniczanie na samym początku tych naszych komponentów w takim naszym standardowym rozumieniu – bo wiadomo, że od razu widzimy, co będzie potrzebne – ale jakby z rozmysłem nie wprowadzamy tego, dopóki to nie jest konieczne, nie musimy wtedy też klientowi tłumaczyć, że: „Drogi kliencie, musimy zrobić backend, a za chwilę go wyrzucimy”. Nie, nie musieliśmy robić backendu. Być może frontend będzie na jakiejś makiecie, być może frontend będzie na przykład w naszym frameworku, który my bardziej umiemy, a na koniec przepiszemy to na jakiś inny framework, bo na przykład ktoś inny będzie to robić. Więc jakby tutaj nie ma to żadnego, że tak powiem, znaczenia dla klienta, bo tych kosztów prawdopodobnie nie poniesie albo w bardzo niewielkim zakresie. Natomiast tak jak wspomniałeś, na pewno nauczymy się wiele, robiąc to nawet w inny sposób, nawet w innej technologii.
Dokładnie tak, i wtedy przepisując to… przepisując to tak może za bardzo powiedziane, wręcz pisząc to, przyjdzie nam to o wiele łatwiej. Czyli możemy sobie trochę tak podciągnąć pod taką produktową katę, czyli tak jak pisaliśmy setki razy różne gry w życie czy innego typu katy, tak każdy kolejny taki kawałek się pisze troszkę szybciej, bo już się zna.
Bo już się zna. I tutaj właśnie, tutaj prototypujemy pewne koncepty, sprawdzamy je, zarówno techniczne, jak i biznesowe, bo bo też to nie musi być taka… to jest taka po części praca… Na przykład klient ma swoją wizję, co tam się dokładnie ma zadziać od strony biznesowej, my mamy wizję, jak to zrealizować od strony technicznej, i my sobie równolegle te wizje badamy. Czyli badając główną tą wizję klienta, biznesową, potwierdzamy, czy da się to zrobić tymi technikami. Jeśli się nie da, to coś tam modyfikujemy, wymieniamy na fajniejsze i dalej próbujemy, aż osiągniemy pożądany wynik.
Współpraca z klientem i ewolucja pomysłu
W międzyczasie ta cała koncepcja klienta może się zmieniać, czego nasz fajny projekt właśnie takiego prototypu ostatni… A jak dobrze pójdzie, to może kiedyś opowiemy o nim jeszcze szczyptę więcej, bo to naprawdę ciekawe cacko i powstawało, i powstało. Czyli w sensie, ta droga budowania tego prototypu mi osobiście bardzo się podobała. Full zabawy tam przy tym pozytywnej i później na koniec też wyszło fajne, ale ono wyszło inne, niż na początku się zakładało, że wyjdzie, nie.
Nawet takie coś jak jakiś pojedynczy feature, gdzieś tam już wzięty na warsztat, on potrafił z tygodnia na tydzień ewoluować, gdzie tych tygodni też nie było jakoś strasznie dużo, nie. Więc kilka tam faz on miał na wypięknienie, tak to powiem, po to, żeby się zmienić i na samym końcu już być tym docelowym, takim prototypowym feature’em, który już daleko odbiegał od tego, co było na początku. Czasem tak.
Tak, no bo tutaj warto sobie też uzmysłowić, no bo często pewnie jako jako programiści, gdzieś tam pracujący w różnych produktach, poniekąd oczekujemy od od biznesu, od właścicieli produktu takiej bardzo… że wiedzą dosłownie, że mają jasną, klarowną wizję tego, co dalej, co co będziemy…
Się obrażamy, jak nie wiedzą.
Oczywiście. I mówimy, że oni są tacy i tacy, bo bo nie wiedzą, nie znają swego biznesu. A tak naprawdę to nie jest takie oczywiste, w którą stronę dany biznes pójdzie, w którą stronę w ogóle pójść. Większość z tych rzeczy no to jednak jest bardziej na drodze jakiś eksperymentów, na drodze no pewnych działań w jedną czy w drugą stronę i później jakieś adaptacji do rzeczywistych wyników.
Bo musimy się wpasować w sposób myślenia klientów naszych klientów.
Dokładnie, dokładnie, właśnie, oni decydują o tym, jak ten biznes końcowo będzie wyglądał. No bo jeżeli my zrobimy super wypasione cacko, tylko klient nie zrozumie, jaką intencję mieliśmy, bo nasz wypasiony przycisk jest po prostu nie w tym miejscu albo nie nazywa się tak, albo w ogóle nie wygląda, jest ma inny odcień czy coś, nie rzuca się w oczy, nie budzi skojarzenia, to już jest źle, nie. Na szczęście mamy te takie testy z użytkownikami, które już mogą nam na etapie tego prototypu powiedzieć, czy użytkownik w ogóle kuma, o co biega tutaj.
Tak, tak. I właśnie te wszystkie problemy są jeszcze bardziej spotęgowane na tych początkowych etapach projektu, gdzie tak naprawdę wiemy jeszcze mniej i ten feedback od użytkowników istniejących jest, można powiedzieć, zerowy. Chyba że mamy gdzieś tam jakąś naszą bazę czy czy grupę, czy czy mamy tak świetny pomysł, że wiemy, że na pewno tutaj zawładnie światem.
To zawsze tak, to zawsze tak.
No ale i wtedy, i wtedy jakby do tej zwinności biznesu i do tej zmienności biznesu warto może też zastosować troszkę większą zwinność rozwiązań, które mają zaimplementować ten biznes, czyli właśnie naszego oprogramowania. Bo jeśli my teraz do każdego projektu będziemy podchodzić na zasadzie: „tutaj mam standardowy stack, stawiam backend, stawiam frontend, potrzebuję to wdrożyć i to wszystko zajmie dwa tygodnie, bo ja tak robię każdą aplikację, nieważne na jakim etapie ona jest życia i jaką w ogóle ma pewność, że będzie sukcesem”, no to to nie jest dobranie właściwych rozwiązań.
Bo to musi być baza, Kibana, Grafana i jeszcze tam coś tam.
No właśnie, albo inny tam gorszy. Właśnie, właśnie chodzi o to, żebyśmy ten nasz taki sposób myślenia i ten mindset przysłowiowy właśnie przeszli w stronę tego, że nie musi. Właśnie, to jest „nie musi”. Nie musi właśnie być nawet do tego poziomu, że nie musi być w ogóle frontu czy czy backendu, możemy sobie…
To, to tak jednak ostrożnie, bo w większości przypadków gdzieś musimy klikać. W większości przypadków to jednak nasi klienci chcieliby coś zobaczyć, nie.
To, no nie piszemy jeszcze dla sztucznej inteligencji, która może sobie sama front do tego zrobić na przykład. Czyli jednak ten frontek to będzie nam potrzebny i najczęściej, i pewnie będzie też chciał jakoś wyglądać, tak, żeby troszkę zachęcić użytkownika końcowego, któremu właśnie na końcu damy do potestowania nasze cacko, żeby w ogóle zobaczyć, czy on kuma, o co chodzi, czy go to cieszy w ogóle korzystanie z tego, żeby zrobić co…
Tak, natomiast tego backendu to już owszem, możemy nie mieć.
No właśnie, tam jest taka mała gwiazdka, to tam się później doczyta. No to jest taki backend z gwiazdką, to prawda.
Z gwiazdką, bo tutaj, że to jest niemanie backendu z gwiazdką, tak, tak, tak. No bo na pewno, na pewno jak robimy taki klasyczny backend i zaraz tam się zagrzebiemy w naszych adnotacjach i mapowaniu bazy danych, i mapowaniu…
Szybko się robi na kilku propertiesach.
W Springu tam, tak. No szybko się robi, ale okaże się, że akurat do nowego projektu podbijemy sobie trochę stack i troszkę coś tam już inaczej działa niż w poprzednim i musimy spędzić…
Level poszedł w górę ostatnio.
Na przykład, właśnie, świetny przykład. Właśnie, co, który miałeś ostatnio – nowsza wersja Elastica i nagle się okazało, że i już trzeba jednak większą maszynkę, bo jednak, jednak już jest problem z nowym Springiem, jest problem. I to, co się wydawało teoretycznie postawieniem stacka takiego, który no masz dopiero co obok postawiony, tylko numerki podbite, no już nie jest takie proste. Mhm.
Więc no teraz, stawiając taki taki, można powiedzieć, proof of concept, gdzie wiadomo, liczy się każda godzina, każdy dzień, jeśli już na dzień dobry mamy techniczny problem, który zabierze nam dzień czy dwa, no to wydatnie potrafi jednak tą prędkość nam zbić.
I entuzjazm też.
I entuzjazm. Może bardziej mówią o portfelu jeszcze, bo na przykład im więcej tych klocków nastawiamy, no to tym więcej nam przyjdzie później w rachunku, bo gdzieś one muszą być hostowane, nie. I teraz po prostu z szerokiego wachlarza dostawców chmury wybierzemy sobie takiego fajnego, który nam tu wszystko da, tak. I jak tego Elastica u niego wyklikamy, to później ten rachunek… a może go wcale nie użyjemy, bo nie dojdziemy do tego etapu. On tam będzie cykał, on będzie sobie chodził, ale, ale obiecamy, że będą wykresy. I one rzeczywiście mogą być, tylko że tak naprawdę nie dojdziemy do momentu, kiedy będą potrzebne.
No, także to wszystko, taka wstrzemięźliwość na każdym etapie, nie. Czyli przychodzi do nas klient i już ma pomysł przemyślany na tyle, żeby dało się go upchnąć w sensowne ramy czasowe. I tutaj nie będziemy ukrywać, że ciężko jest zrobić cokolwiek w dwa tygodnie, o tygodniu to już zapomnijmy w ogóle, nie. Tak naprawdę na tydzień nam się nie opłaca klapki otwierać w laptopie. Sorry, ale brutalna prawda, bo bo tydzień czasu to tak błyskawicznie mija, że zanim się w ogóle ustali jakieś tam warunki początkowe, to na samych spotkaniach potrafi zeżreć… Przepraszam, coś tam z grubsza naszkicować, ale nie oczekujmy, że jakoś magicznie wyprodukujemy…
Tutaj jest to lekko wzion… ale nie aż tak znowu dalekie od prawdy.
Tak znowu dalekie. Ale żeby jakiś klient się nie obruszył, że że nie da się zrobić nic zupełnie… To już mówimy o takiej fazie, można powiedzieć…
Żartowałem, da się.
No wiesz, no. Tylko żartowałem, dwa dni będzie gotowe. Na ten, na piątek.
Na piątek, co już jutro, jutro, pojutrze.
To nie, na sobotę.
To na sobotę, to już bardziej rozumiem. Masz też na myśli też pewne biznesowe ustalenia, nie tylko ten, nie tylko postawienie stacku, że tak powiem.
Zdecydowanie, nie. To w ogóle zaczynamy rozmowę od biznesowych ustaleń, czyli przychodzi do nas klient i mówi: „Słuchajcie, ja tu mam taki super pomysł i ja tu jestem totalnie i w ogóle tam znam te wszystkie wasze myki i wiem, że to nie są tanie rzeczy”. Jak przyjdzie, to jest w ogóle poezja. I tylko mówi, że: „No nie mam takiego budżetu, żeby te niedrogie rzeczy ogarnąć, więc robimy prototyp i mam koncept na ten prototyp taki, nie”.
W takiej sytuacji, jak on już przychodzi, ten klient, i wie, czego chce, i na przykład pyta, czy w miesiąc mu wystukamy taki prototyp, no to my popatrzymy, pokiwamy mądrze głowami i pomyślimy, czy to się da poukładać w jakąś sensowną całość. Może co wywalić i na etap prototypu po prostu tylko ograniczyć do takiej najbardziej totalnie elementarnej funkcjonalności, która musi być, bo wiadomo, że klienci jego końcowi na pewno z tego będą korzystać, nie. Tak, bo na przykład, że on by chciał mieć w tym raport, jak klienci skorzystali z tej funkcjonalności. To jest fajne i w MVP to możemy zawrzeć, ale MVP to już jest kolejna rzecz po po prototypie, nie. Więc my sobie możemy wtedy, wiedząc, że to będzie potrzebne i fajne, i że się sprawdził ten pierwszy koncept, możemy to sobie zawrzeć. Ale teraz skupmy się na tym najbardziej ważnym czymś, bo no bo tutaj nie ma co ukrywać, my też ulegamy czasem entuzjazmowi i mówimy: „Pewnie, a co tam, robimy! No da się zrobić, nie”. A później się okazuje, że ten miesiąc to wcale nie jest tak długo, nie.
Zdecydowanie. O ile ten tydzień jest w ogóle krótko, to razy cztery, no to jak tydzień ma tyle, to miesiąc tu kończy.
No tak, a jeszcze jakiś urlop, jakieś święta wypadną i to już w ogóle leci.
Jak jedź na ferie do dziadków, kurde, i na narty po drodze, to nie wiem, robić nie ma komu.
Nie ma komu. No właśnie. No tak, oczywiście, to są takie obiektywne przeszkody, ale chyba bardziej…
Te ferie.
Ale bardziej subiektywną przeszkodą jest chyba też taki naturalny, inżynierski ciąg, żeby jednak robić rzeczy porządnie, jak najlepiej, z myślą oczywiście o przyszłości, bo „bo to nam się przyda”.
Bo to nam się przyda.
I tutaj niestety musimy te nasze tendencje powstrzymać. To jest taka trochę pułapka. To jest trochę pułapka. Oczywiście nie chodzi o to, żeby robić źle, na odwal i w ogóle i do kosza, bo to to nie o to chodzi. Chodzi jednak o to, żeby troszkę pomyśleć, czy faktycznie rzeczy, które robimy bardzo może generycznie, może przyszłościowo, rozpatrując bardzo wiele różnych case’ów, czy one faktycznie w ogóle będą miały miejsce w tym projekcie. Czy my dotrwamy z tym projektem do momentu, gdzie wykorzystamy te nasze tutaj wspaniałe abstrakcyjne wynalazki, które…
Rozważania, które nam to nam w tym pomogą.
To jest bardzo trudne, bo na każdym kroku mamy zwykle właśnie w dowolnych historiach, które implementujemy, o których oczywiście myślimy, czy jakieś problemy, jak ulepszyć dany proces, jak zrobić go bardziej przyjaznym użytkownikowi. Jest bardzo dużo takich rzeczy, gdzie jakby naturalnie z naszego doświadczenia wiemy, że powinniśmy zrobić pięć jeszcze kroków, żeby ten proces wyglądał tak, jakbyśmy go implementowali w istniejącej aplikacji. Natomiast tutaj no musimy nie dość, że jakby techniczne komponenty mocno ociosać, czyli na przykład właśnie brak backendu, baza danych – może tylko jakiś key-value store bez jakichś skomplikowanych tutaj komponentów – ale też na takim etapie niższym, czyli na etapie implementacji już musimy pewne rzeczy jednak troszeczkę ograniczać, żeby no po prostu nie okazało się, że ta implementacja no już jest, można powiedzieć, gotowym, produkcyjnym rozwiązaniem, bo nie o to nam chodzi właśnie w tym prototypie.
W tym prototypie bardziej chodzi nam właśnie o tą wspomnianą walidację. Pewnie jakaś niewielka grupa użytkowników sobie po tym poklika. Jak wyskoczy jakiś wyjątek, jeśli gdzieś będziemy jakiś warunek brzegowy, jakąś walidację specyficzną, jakiś bardzo, no właśnie, brzegowy przypadek przeoczymy, że użytkownik zrobi to i to, i wtedy będzie coś tam, to nie jest problem, bo to nawet jeszcze nie jest MVP.
To nawet dobrze, bo wtedy już mamy gotową wskazówkę, że jeszcze to trzeba wziąć pod uwagę, już budując produkt.
Dokładnie, to jest bardzo trudne i wiemy to też z doświadczenia, chociażby po ostatnich tutaj naszych, że tak powiem, bojach z tego typu podejściem do do właśnie nowych produktów. No to jest bardzo trudne, to wymaga tak naprawdę skupienia no, można powiedzieć, całego zespołu, który nad tym pracuje – od klienta…
Po każdej stronie.
Po każdej stronie. Klient, jakiś product, project manager, po dewelopera. No wszyscy muszą sobie zdać sprawę, że no tak naprawdę, jeśli naszym celem jest prędkość i chcemy to zrobić szybko, a dzięki temu też tanio – to jest właśnie ten element, że możemy osiągnąć trzy cechy z tych trzech. Możemy to zrobić i szybko, i tanio, bo zrobiliśmy to szybko, a jednocześnie też dobrze, bo odkryliśmy dużo – w rozumieniu dobrze prototypu, nie dobrze gotowego produktu, bo to nie o to nam chodzi.
Właśnie tak jest.
Więc wtedy mamy trzy cechy osiągnięte, tylko naprawdę no wymaga to pewnego wysiłku i pewnej takiej kontrintuicji, niż mamy zazwyczaj.
Otóż to, bo dokładnie tak, bo bo ten cały biznes też może się rozwijać w trakcie, co co już zresztą wspomnieliśmy, nie. Więc nawet te warunki brzegowe, to one mogą wynikać z tego, że po prostu odkryliśmy kolejny jakiś flow, którego nie byliśmy świadomi, albo może świtał nam tam gdzieś nieśmiało, ale okazało się, że to będzie miało znaczenie, bo bo tak, bo po prostu ludzie tak proces realizują.
Więc jak najbardziej. Czyli już wiemy, co to jest ten proof of concept, wiemy, co to jest prototyp. Wiemy – prototyp to jest właśnie to, co ma wyskoczyć z tego naszego Rapid Developmentu.
Tutaj byśmy chcieli po obydwu stronach, czyli po naszej stronie – dostawcy – i po stronie klienta, żeby ten Rapid faktycznie był szybki. Czyli no taki pewnie miesiąc, miesiąc z lekkim hakiem.
Tak, właśnie jednostką czasu są tygodnie, względnie pojedyncze miesiące. Raczej, raczej tutaj w takie…
To się wiąże, tak, to się wiąże raz, że z takim pozytywnym entuzjazmem, że… entuzjazm to raczej powinien być pozytywny… że z tego, że fajnie, za miesiąc już mamy coś działającego.
Ale też wiąże się… może istnieć ryzyko pułapki, że tutaj entuzjastycznie podchodzimy do tego miesiąca.
Dyscyplina i ryzyko „rozhulania” projektu
Z jednego do dwóch się rozciągnie.
I może nam się rozciągnąć, bo kto mu zabroni, jak będziemy sobie zbytnio folgować w trakcie, nie. Tylko że nadal, nie będzie to jeszcze taka deweloperka, która już nas miałaby doprowadzić do MVP. No bo MVP to już właśnie musi być ten produkt zrobiony dobrze, nie. On musi mieć wszystkie plusy dodatnie tego prototypu i jeszcze więcej, bo pewnie w trakcie MVP my sobie odkryjemy…
Jeszcze nikt nie zabroni klientowi znowuż testować tego w locie, może nawet na tej samej grupie albo jakiejś fajniejszej grupie użytkowników, tych, którzy testowali ten ten prototyp, nie. Kto tam wie, zależnie, jak to sobie… i jakie są tutaj plusy, minusy.
Trzeba jednak zachować dyscyplinę, żeby nie pozwolić temu konceptowi się za bardzo rozhulać w środku, bo zarówno klient może wpadać na ciekawe pomysły: „A wiecie co, jeszcze tu byśmy dodali takie małe coś, a tu jeszcze, a tu jeszcze coś takiego, bo kurde, ta formatka do… no nie powiem jakiego feature’a, ale ta formatka do tego tutaj jest już prawie super, ale jeszcze musimy dociągnąć tam dane z poprzedniego etapu, nie”. I trochę dociągamy, tu taki przycisk, to w górę, to w dół, ciach, ciach, ciach, wszystko pięknie, nie. Tylko później nam się z tego jednego miesiąca szybko zrobią dwa, nie.
I tak samo po naszej stronie. My możemy też zaproponować: „Wiecie co, to wszystko jest super, ten biznes macie wypasiony, ale my to byśmy jeszcze tak podkręcili. Zrobimy tu jeszcze lepiej, coś tam, coś tam, cuda-wianki”. I tak samo możemy to wydłużyć, nie. Więc po obydwu stronach dyscyplina po to, żebyśmy dojechali do tego prototypu, do pokazania użytkownikom, tych użytkowników do testów pierwszych, i nie wypalili całego budżetu na MVP.
Dokładnie tak, dokładnie tak. Bo się umawiamy na jakiś tam zakres, nie. I w tym zakresie robimy, w tym budżecie, coś. Więc jak wypalimy ten budżet za szybko, kasa nam się skończy, no to, to co? Zostaniemy bez prototypu czy czy robimy za darmo po lekcjach?
No właśnie, tak. Oczywiście trzeba wspomnieć, mówimy tutaj, gdzie mamy pewne ograniczenia, właśnie czy to czasowe, czy czy budżetowe, a tutaj mamy same ograniczenia. Bo to się równie dobrze stosuje też do warunków, gdzie mamy na przykład jakieś deadliny. Możemy mieć furę tutaj pieniędzy, ale mamy jakieś deadline’y, no i tego nie unikniemy.
Więc też na przykład musimy zdążyć na targi jakieś, nie. Klient chce wystąpić z tym na targach, a my mamy do targów na przykład trzy miesiące, czyli nie możemy przez trzy miesiące rzeźbić. Nawet przez te dwa miesiące ciężko by było, bo jest jeszcze czas na zorganizowanie tych testów, czyli efektywnie mamy miesiąc na wyrzeźbienie czegoś, co później klient będzie sobie testował, żeby zdążyć dojechać na te targi.
No to jest patent często stosowany chociażby w gamedevie i w grach szeroko pojętych. Wersje, które wystawiane są na targach, dramatycznie różnią się od gotowego produktu.
A gotowe produkty testują użytkownicy. Więc zajawka na nowy odcinek, nasza strategia w pełnej okazałości.
Oczywiście, ale tak, to, to trochę też od innych rzeczy zależy. Oczywiście to jest tylko taki żarcik, proszę sobie nie brać tego do serca. Natomiast tak, no tutaj eksplozja jakby tego zakresu, eksplozja właśnie scope’u produktu – i techniczna, i biznesowa – to jest coś, co musimy cały czas trzymać w ryzach. No nie możemy, nie możemy sobie, że tak powiem, folgować, no bo jeśli mamy budżet, jeśli nie mamy żadnych ograniczeń, oczywiście możemy robić, co chcemy. Jakby tutaj wtedy to podejście się totalnie nie…
Tylko wyobraźnia.
Tak, tak. Równie dobrze, jeśli to jest nasz własny, prywatny projekt, jeśli nie przeszkadza nam, że nasz własny projekt będziemy robić dwa lata, bo chcemy najnowsze zabawki i wszystko, co co tam tylko nam się wymarzy, nie ma problemu. To jest nasz prywatny projekt, no nikt nas tutaj nie goni. Ale jeśli na przykład myślimy, żeby, nie wiem, nasz wspaniały pomysł jednak gdzieś tam przedstawiać jakimś użytkownikom, no to pewnie fajnie by to było zrobić szybciej niż później i może na początek nie potrzebujemy tutaj najnowszych rzeczy, żeby z tym produktem wystartować.
Więc no, po raz kolejny, jakby tutaj trzeba, trzeba to trzymać w ryzach. No i właśnie to podejście prototypowe z tymi wszystkimi rzeczami, które tutaj wymieniliśmy, wydaje się sprawdzać, przynajmniej tutaj w naszym, w naszym doświadczeniu. No bo to jest jednak, jednak, jednak te, te trzy cechy, o których mówiliśmy, jest większa szansa, że je dostarczymy, czyli szybko, tanio, dobrze.
Tym bardziej, że można na tym bazować w dalszych pracach.
Tym bardziej, że można to jeszcze rozszerzyć i jeszcze bardziej hardkorowo to zrobić, nie. Czyli o ile tu jeszcze tak między wierszami i tak się pojawia to kodowanie, bo no, nie mamy backendu… nie mamy backendu. No dobra, to tak żartowaliśmy. No my nie mamy, bo nie piszemy, ale tam coś tam jednak mamy, bo gdzieś tam musimy coś zapisać, jakieś tam te dane, zmiany. Czyli korzystamy z jakiegoś tam gotowca i najczęściej coś tam kodujemy, nie. Ale gdyby w ogóle nie kodować? Czyli gdyby zrobić taki prototyp tak na dziko całkiem?
Alternatywa dla kodu: low-code i no-code
W takim low-code albo no-code podejściu, nie.
Czyli szukałeś tłumaczenia, ale chyba, chyba polskiego ciężko, ciężko jakoś tak…
No bez kodowania albo mało kodu. Brak kodu, mało kodu.
No tak, takie coś. Czyli po prostu, żebyśmy nie musieli w ogóle… Pytanie, czy my jesteśmy do tego potrzebni, bo my jednak jako, jako firma, która no nie tylko pisze, trochę, ale czasem nawet dużo kodu wytwarza, w sensie całe projekty, nie, to my jednak jesteśmy po stronie tych kodujących. Dla nas jest to łatwiejsze po prostu. Ale ktoś mógłby się chcieć pokusić o prototyp w jakimś takim gotowym narzędziu, w jakimś wyklikiwaniu…
Na granicy papieru, w ogóle można by to narysować sobie na papierze, nie, i sprawdzić zwalidowany po prostu. Obojętnie, czy to będzie gra planszowa, czy czy gra, jakaś prosta gierka. Bo to o tym się właśnie nawet też projektanci gier zawodowi w ten sposób wyrażają, że jak prototypujesz grę, jakąś, to zrób ją najpierw w formie papierowej i sprawdź w ogóle założenia gameplayu, albo w ogóle wybierz sobie jakieś elementy tego gameplayu i sprawdź, jak to działa w wersji planszówkowej, papierowej, takiej symulowanej na kartce.
No i podobnie z naszymi feature’ami też możemy sobie… w sensie, w aplikacjach biznesowych może nie będą tak grywalne takie elementy planszówki, ale też możemy sobie chociaż rozrysować na kartce. Potem, wchodząc ciutkę wyżej, już skorzystać z jakiegoś narzędzia. No jak mamy jakieś zapędy troszkę takie projektowo-UX-owe, to pewnie Figma byłaby tutaj przykładem takiego narzędzia, gdzie jeżeli się wie, jak, coś można zrobić, to można zrobić wszelkiej maści jakieś mockowe cacka, gdzie po prostu robi się symulację ekranów wyświetlanych w aplikacji i jakieś proste przejście między nimi. Tam nie będzie żadnej logiki skomplikowanej. Po jakieś takie kombajny wielkie, gdzie można sobie wyklikać w teorii tą całą aplikację, ten cały prototyp. Tylko pytanie, czy czy to będzie się… czy będzie się łatwiej nauczyć tego kombajnu, czy jakiegoś prostego frameworka do napisania frontendu?
A drugiego do backendu. Fajnie, że wspomniałeś o kartce, bo rzeczywiście kartka to może być i szkic interfejsu to może być w dzisiejszych czasach równie dobry punkt wyjścia do aplikacji. Bo Microsoft na przykład w swoim pakiecie Power Apps chwali się funkcjonalnością wygenerowania takiej aplikacji ze zdjęcia interfejsu, czyli szkicujemy sobie długopisem, ołówkiem jakieś nasze pola, jakieś labelki, robimy sobie zdjęcie i tutaj generuje się nam jakaś prosta aplikacja. Bardziej formularz, bo to mówimy o jakiś prostych formularzach do zamówień, tego typu rzeczach, czy takich, takie biznesowe klimaty.
Takie biznesowe. Jakby nie wygenerujemy z tego oczywiście pełnych przejść, no bo ciężko na kartce pewnie narysować, że przejdź z tej strony do tamtej.
Tak nagrywać, jak się tak z zeszytu to animuje, i żeby szybko, to zdążył sobie przeliczyć.
Szybka kamera musi być.
Szybka kamera, ale jakby to już pokazuje rzeczywiście, że jakby ten krok od takiego narysowania nawet do pierwszego jakiegoś działającego formularza nie jest w obecnych czasach aż tak skomplikowany. Wiadomo, tutaj wchodzą różne rozwiązania sztucznej inteligencji, które też wybitnie nas w tym wspierają. No i ogólnie jakby tego typu narzędzia właśnie, low-code, no-code, tak jak wspomniałeś, no one różnią się stopniem skomplikowania, różnią się jakby możliwościami i tym, co możemy z nich otrzymać. Natomiast jeśli mówimy o takim prostym prototypie, mogą gdzieś tam się sprawdzić, przynajmniej do do etapu takiego, takiej wersji właśnie prototypowej, żeby zebrać pierwszy, pierwszy feedback.
No ale jakby nie patrzeć, no, toole takie jak Bubble, gdzie sobie tam klikamy po tej, po tej aplikacji… No tam jest oczywiście dużo templatek i możemy sobie coś gotowego wygenerować i sobie tylko to pozmieniać, ale jakby stopień skomplikowania w ogóle tego kreatora i tych wszystkich elementów, które tam modyfikujemy, no dla mnie zaczyna niebezpiecznie blisko wyglądać już samego kodu praktycznie. No bo jednak, no nie da się ukryć, no jeśli mamy aplikację webową, no to mamy tam ileś parametrów CSS-owych, które później w takim Bubble są gdzieś tam ukryte w dialogach, w jakiś formatkach, no które chcemy zmienić.
Patrząc na coś takiego, no dla mnie… my oczywiście mamy trochę inny punkt widzenia, bardziej deweloperski, bo znamy te języki, znamy. Nam po prostu prościej jest to zakodować, niż gdzieś tam klikać po interfejsie, bo wiemy, że to są po prostu dwa parametry CSS i gotowe. Więc jakby dla nas to jest ograniczające, a jednocześnie mimo wszystko trudne, bo ten interfejs jest, jest bardzo przeładowany.
Musimy najpierw poznać koncept.
Musimy poznać koncept, musimy nauczyć się tego narzędzia, a dla kogoś nietechnicznego, można powiedzieć, albo nie programisty, tylko właśnie kogoś z biznesu albo kogoś, kto chciałby zrobić jakąś aplikację, ale niekoniecznie umie programować, no to to narzędzie jest naprawdę skomplikowane wtedy. Tak bym sobie wyobrażał, że taka osoba, można powiedzieć mniej techniczna, no to może mieć spore problemy, żeby takie narzędzie ogarnąć, więc ono tak stoi troszkę na takim rozdrożu.
No już pomijając takie rzeczy też, o których wcześniej sobie rozmawialiśmy, że to są bardzo specyficzne rozwiązania. Nie ma co ukrywać, że jak nauczymy się takiego Bubble’a czy Power Appsa, czy wielu różnych innych, które są, no nauczymy się jednego z nich. One nie są ze sobą kompatybilne, to nie są jakieś… to nie są standardy branżowe i takich standardów też nigdy nie będzie zapewne. Więc ograniczamy się do jednego narzędzia, mocno specyficznego, no i ciężko tak naprawdę przeskoczyć gdzieś dalej i jakby, jakby, jakby wykorzystać tą wiedzę, żeby, żeby coś więcej zrobić.
Z drugiej strony, no też te aplikacje nigdy nie będą na tyle elastyczne, żeby żeby zastąpić jakieś bardziej skomplikowane systemy. No bo naprawdę trzeba by się było pewnie mocno w nich tam nagrzebać i tam pewnie książki są napisane odnośnie pryncypiów użytkowania tego, nie. Bo i na pewno to się nawet pewnie w dużej mierze da zrobić w tych, w tych tego typu wyklikiwaczach. Tylko pytanie, jaką drogę musimy przejść, ile pluginów, ile templatek, ile customowych rozwiązań musimy użyć, żeby faktycznie ten cel osiągnąć.
I też pytanie, czy jest tam mój plugin.
Czy jest tam mój plugin, to jest, to jest jedna rzecz. Tylko że tego typu narzędzia mają też ten problem, że przez to, że łączymy tam różne pluginy, różne rozwiązania i różne integracje – no bo wiadomo, też czasami potrzebujemy jakieś API, wysłać jakiegoś maila, z czymś się skomunikować – wszystkie te rzeczy potrafią nam troszkę tak pod spodem, niejako, no zmieniać się. No bo wiadomo, integrując się z jakimś API albo używając jakiegoś plugina, on będzie miał cały czas jakieś nowsze wersje, sama platforma może mieć nowsze wersje, więc nasza aplikacja no nigdy nie będzie stałym…
Samo to zdalne coś, gdzie on tam uderza, też może mieć inne wersje, nie.
Tak, więc jakby nie dość, że mamy zmienność, dużo ruchomych punktów, zmienność naszych danych, naszego, można powiedzieć, biznesu, to w ogóle mamy bardzo dużą zmienność tej platformy samej w sobie, której zmienności w ogóle nie kontrolujemy. Bo to nie jest jak nasz package.json czy czy build.gradle, gdzie mamy po prostu wersję naszych bibliotek i możemy to zostawić na stałe takie samo i generalnie jakoś tam przeżyjemy.
Chyba, że ktoś stosuje latest.
Dopóki oczywiście tak, albo coś nie wyjdzie, tak, tak, zgodnie z prawidłami, to tak jak możemy ten artefakt, można powiedzieć, wyryć w kamieniu i będzie, będzie okej. Chociażby przez niedostarczanie najnowszego artefaktu, po prostu będziemy mieli ten stary.
Dokładnie. Natomiast w tego typu no-code’ach no będzie bardzo ciężko to to osiągnąć, bo nigdy nie wiemy, co się zmieni gdzieś tam pod maską tej naszej platformy, tego naszego Bubble, Power Appsa czy czy czy innych rozwiązań. No tutaj podobnie też jest z narzędziami typu właśnie WordPress, który też może być takim troszkę no-code’em, względnie low-code’em, gdzie możemy sobie posklejać z różnych pluginów, z różnych elementów naszą stronkę i tak naprawdę… No tutaj oczywiście, jak ktoś ma czarny pas w WordPressie, no to to są bardzo fajne rozwiązania, żebyśmy tutaj nie byli…
Czy my mamy wystarczający poziom? Czy na przykład postawmy się teraz po stronie klienta. Na przykład klient sobie wygoogla, chce mieć szybko, żeby zdążyć na tych targach, i koniec kropka. Czy nauka tego cacka zajmie tydzień, dwa, czy miesiąc? Nie wiadomo, nie. Czy da się to zrobić później przez ten, na przykład dodatkowy miesiąc, tak? Nie wiadomo, nie. Na końcu może się okazać, czegoś tam zabrakło jednak i w ogóle klapa, nie. Nie wyślemy tego maila, albo nie zaciągniemy danych z jakiegoś API, bo nagle się okaże, że musieliśmy się zintegrować z jakąś tam końcówką, gdzieś tam wystawianą przez jakąś tam tą, no agencję jakąś tam rządową, gdzieś tam, nie. Czyli oficjalne API do zawołania, piękne dane się z tego dostaje. No to u nas rach-ciach-ciach, jeden mały JSON, poszło, nie, z grubsza upraszczając.
Tak ze dwa razy tyle, ale ogólnie prosto. I jeżeli coś gdzieś by nie grało, no to wchodzimy, poprawiamy i jest git, nie. A tak zróbmy to na takim właśnie Bubble’u.
Ale trzeba jeszcze jedną rzecz tutaj… do tych narzędzi tutaj z premedytacją wrzuciliśmy… Uwaga, teraz będzie się działo… Excela. Bo przecież kiedyś mieliśmy taki przypadek, że przyszedł do nas bardzo ogarnięty klient i mówi tak: „Mam taką fajną apkę, ona mi działa, sam ją zrobiłem”. Zajęło mu to tam ileś tam, nie pamiętam, ile tam powiedział, pokazał, co to robiło i jak na końcu powiedział, że sam to zrobił i że to było w Excelu, to nam prawie kapcie pospadały. Bo jak mu to wyceniliśmy, to po prostu najprościej było zawinąć się z tym Excelem i podziękować.
No właśnie, bo już miał po prostu. To to jest w ogóle świetny przykład. I też żebyśmy nie byli źle zrozumiani, oczywiście tego typu narzędzia mają gdzieś tam swoje zastosowanie i jakby tutaj nie, nie robimy, nie robimy rantu na na na tego typu…
Ale w cenie, że to się w Excelu dało zrobić, nie.
Tak, ale Excel to jest w ogóle case świetny sam w sobie. To się też troszkę chyba łączy ogólnie jakby z ekosystemem Microsoftu, no bo Access, Microsoft Access, swego czasu też był takim no-code’em, low-code’em, powiedzmy, gdzie bardzo często gdzieś tam w organizacjach ludzie robili sobie bazy w Accessie i mieli już kawałek aplikacji, mieli już de facto kawałek aplikacji. Ta baza, ten ten arkusz gdzieś tam był udostępniony, każdy sobie z niego mógł albo skorzystać, albo skopiować, czy tak jak to w przypadku Exceli bywa. No teraz to jest troszkę łatwiejsze, jak już mamy te wersje online’owe, podobnie Google Spreadsheet. To już naprawdę może być aplikacja, bo mamy link do tego naszego Excela, więc to już jest w ogóle, już można powiedzieć, skalowalne i w ogóle tak jak prawdziwa aplikacja.
No i de facto, no tam można zawrzeć naprawdę dużo logiki. Na YouTubie jest pełno filmików, jak zrobić sobie z Excela ładne dashboardy, które w ogóle nie wyglądają jak arkusz, ale są kolorowe, przejrzyste, wyświetlają jakieś statystyki, coś tam agregują, więc można powiedzieć normalna aplikacja, a Excel w tym momencie jest takim silnikiem low-code’owym. No bo no-code’em to ciężko, bo coś tam musimy w tych komórkach zakodować. Nawet tą sumę głupią, no to to już jest, jest wymagana ta wiedza excelowa.
Czyli tak, przeciętny śmiertelnik, który wie, że tam może coś policzyć w tych komórkach, to to jeszcze musi trochę doczytać, nie, żeby to, takie coś zrobić. Ale mimo wszystko, ta wiedza nie jest zupełnie bezużyteczna w odróżnieniu troszkę od tych specyficznych umiejętności, bardzo, bardzo konkretnych narzędzi low-code’owych. Więc tutaj, jeśli mamy jakiś problem, który możemy rozwiązać Excelem i możemy to zwalidować, no to też nie jest żadna ujma. I czasami jakieś obliczenia czy tego typu rzeczy możemy sobie tam zrobić.
Pewnie w wielu firmach masa rzeczy działa na Excelu.
I tak naprawdę, tak naprawdę też w ogóle źródłem wielu aplikacji właśnie jest ten Excel, na zasadzie, że był jakiś tam właśnie Excel, jakiś arkusz, który się rozrastał, aż w pewnym momencie jakiś product owner czy jakiś inny menadżer stwierdził, że: „Dobra, to już jest za dużo. Zróbmy z tego aplikację”.
Dość tych świństw, robimy aplikację.
W którymś momencie to już faktycznie będzie za dużo do ogarnięcia gdzieś tam, albo po prostu braknie w tym Excelu jednak czegoś, nie, bo to też nie jest rozwiązanie. Jakby tak było, to byśmy klepali w Excelu apki, nie, a jednak nie klepiemy. Więc no czegoś tam na pewno zabraknie, wcześniej czy później.
To jest też w ogóle, uważam, bardzo taki fajny pomysł na start jakiejś własnej aplikacji. Jeśli mamy w organizacji, wiemy na przykład, że istnieje jakiś Excel, gdzie liczy się coś – czy to jest jakieś obiady, czy jakieś premie – jeśli mamy dostęp do takich i na przykład widzimy, że można zrobić to w aplikacji, no to tego typu szybkie podejście też może być fajnym, fajnym właśnie podejściem, żeby sprawdzić, czy nie lepiej by się to robiło w naszej aplikacji. I jeśli szukamy pomysłu na jakiś nowy projekt, może warto zastąpić na przykład jakąś bazę Accessa czy innego Excela naszą aplikacją, w tym robioną na przykład.
Zdecydowanie. Ale to jest, no to jest na pewno jedno z narzędzi, które może… w sensie, w ogóle taki microsoftowy ekosystem, który może nie rozpatrujemy jako typowo aplikacyjny, ale jak widać, masa rzeczy na tym działa. Te arkusze sobie liczą. No i tak naprawdę, czym się to różni od normalnej aplikacji webowej, która by robiła to samo, tylko że w widoku tabelarycznym, ale w przeglądarce? No nie ma tutaj większego, większego…
Nie ma. I co gorsza, trochę ciężko znaleźć właśnie argumenty za tym, żeby to jednak robić tak customowo.
No trochę tak, w takiej sytuacji trochę tak. Jeśli to są stricte wyliczenia bez, nie wiadomo jak skomplikowanych flow, czyli po prostu nadają się do tego narzędzia, to no to siup, nie. Mamy, mamy dobry młotek, możemy wbić tego gwoździa tym młotkiem właśnie.
Dokładnie tak. No ale w takim ogólnym przypadku aż tak dobrze nie będzie, że na tym Excelu ogarniemy, więc tak czy siak jesteśmy w stanie się jakoś tam dogadać – klient z nami, my z klientem – jak to ogarnąć ten kawałek jego grajdołka, żeby wyszło z takimi, że tak powiem, korzyściami na przyszłość. Czyli żebyśmy poznali, i czego się spodziewać po tym biznesie, i jak to ogarnąć technologicznie, i jak to zrobić bez backendu.
Backend z gwiazdką, czyli prototyp na Firebase
I teraz może rozkmińmy to zagadnienie, co chodzi, jak bez backendu. Tą gwiazdkę rozkmińmy.
Gwiazdkę, nie. No to jak to tak, bez…
Bardzo prosto. Co na początku też… co w ten czas jest w jego miejscu?
No właśnie. Na samym początku też wspomnieliśmy, że możemy nie mieć backendu w ogóle, czyli na przykład warto sobie zadać pytanie, czy nasza aplikacja w ogóle potrzebuje coś persystować. Bo być może mamy jakiś flow czy mamy jakiś przypadek użycia dla naszego biznesu, który jest stricte dla tego jednego użytkownika. Na przykład nie musimy komunikować się czy synchronizować danych pomiędzy użytkownikami, więc wystarczy na przykład, że to się chwilowo zapisze w Local Storage w przeglądarce. Użytkownik będzie sobie klikał, nawet jeśli zrobi odświeżenie strony, wciąż będzie te dane widział, więc jakby dla niego nie ma to większego znaczenia, a my sobie to po cichutku w Local Storage przetrzymamy i w ten sposób będziemy to sprawdzać. Więc w tym momencie w ogóle nie potrzebujemy żadnego backendu i tutaj nawet nie ma gwiazdki. Po prostu mamy sam frontek i jest naprawdę przejrzyście i wszystko sobie działa.
Natomiast w sytuacji, kiedy nasze przypadki potrzebują na przykład działalności dwóch użytkowników, którzy robią coś jednocześnie, widzą swoje zmiany nawzajem…
Czy, odpukać, w różnych rolach.
W różnych rolach, ale to akurat nie jest konieczne. Ogólnie, jeśli mamy różnych użytkowników, którzy jednak muszą jakoś się synchronizować, no to tutaj bez tego, można powiedzieć, centralnego źródła prawdy, bez tego backendu, który coś tam nam zrobi, no tutaj się nie obejdzie. Oczywiście mówimy bardziej tutaj w sytuacji backendu jako takiego też chyba miejsca do zapisu danych, bo niekoniecznie musimy mieć już jakąś logikę, która się będzie…
Właśnie, procesy biznesowe to też tak troszkę traktujemy tutaj pobłażliwie, nie, że nie, nie implementujemy tej domeny aż tak w rozumieniu implementowania domen, tak. Czyli że faktycznie, że mamy tam coś, co trzyma spójność tego naszego procesu, realizuje ten proces i dba o to, żeby wszystko, co się dzieje tam na poszczególnych jego etapach, było spójne, nie.
Czyli tak jak mówisz, tutaj jakieś pudełeczko na dane. Tak jak w tym pierwszym przykładzie pudełeczkiem jest sama przeglądarka, bo nie potrzebujemy się dzielić danymi. W drugim przykładzie, gdy potrzebujemy się trochę podzielić, to po prostu musimy mieć inne pudełeczko na dane.
Tak. No i tutaj mamy takie fajne pudełeczko, po łebkach się nazywa baza ogniowa.
Baza ogniowa, czyli po angielsku bardziej znana wersja…
Firebase.
Firebase. Rzeczywiście, swego czasu był, można powiedzieć, tylko bazą, teraz, teraz już po przyjęciu przez Google jednak stał się troszkę większym kombajnem. To wciąż…
Bardziej platformą.
Bardziej platformą, tak, bo to już jest bardziej, bardziej taki troszkę może taki Platform as a Service, coś takiego, bardziej. Bo sam Firebase oczywiście wciąż oferuje nam storage, czyli taką NoSQL-ową, dokumentową bazę, bazę danych. Natomiast ma też komponenty właśnie identity provider, czyli autentykacji użytkowników, ma też właśnie jakiś taki storage bardziej dokumentowy, a la bucketowy, powiedzmy, ma również Cloud Functions, które możemy gdzieś tam sobie użyć jako takie elementy backendu na zasadzie właśnie jakiś tam…
Kiedy trzeba, żeby coś jednak się zadziało gdzieś, nie, to tak w takim ograniczonym zakresie jak najbardziej.
Bo no nie powiem, że to jest takie specjalnie wygodne.
No właśnie, nie jest może to super wygodne, nie jest to też pewnie przejrzyste. Przeglądanie logów z tego troszkę było drogą przez mękę.
Tak, troszkę było kłopotliwe i debugowanie tego też nie było jakieś super wygodne, już nie wspomnę o debugowaniu w ogóle takiego czegoś.
Tak, no ma to, ma to troszkę takiego narzutu, nie jest to super wygodne, ale jeśli potrzebujemy, żeby jakieś procesy jednak wykonały się na backendzie, czy to ze względów bezpieczeństwa, czy ze względów może jakiś, może jakiś innych, może jakieś mamy joby czy czy inne schedulery, które jednak coś muszą zrobić w tle, czego nie da się zrobić na froncie, no bo tak właśnie, wiadomo, to to to jest po stronie użytkownika, no pewnie jakoś to tam sobie możemy, możemy użyć.
Ale na pewno zaletą, tutaj akurat tego Firebase, jest to, że te wszystkie usługi bardzo fajnie się ze sobą integrują i też bardzo fajnie integrują się ogólnie z naszą aplikacją, czy to frontową, czy czy backendową. Więc no kilkoma, kilkoma ruchami…
Kilkoma, właściwie jednym plikiem konfiguracyjnym, możemy sobie… takim, takim, dokładnie, jak Michał pokazuje, możemy sobie, możemy sobie ten, ten nasz, tego naszego Firebase podłączyć. I Firebase też może hostować naszą aplikację, w rozumieniu hostowania statycznej aplikacji frontowej, bo jakby tego też za bardzo nie poruszaliśmy.
Gdzie to wystawić na świat?
Gdzie to wystawić na świat? Bo jakby nie ma co ukrywać, że… a to może też za chwilkę o tym sobie powiemy, o hostingu. No ale Firebase właśnie też to, też to potrafi. Więc nie jest to oczywiście tak rozbudowane i skomplikowane jak na przykład usługi AWS i nie mamy tego aż tak dużo do wyboru. Same w sobie są na pewno znacznie prostsze niż niż tutaj usługi chmurowe, czy Google, czy czy AWS-u, czy czy czy Microsoftu.
Więc mimo, że to stoi na Googlu.
Właśnie, mimo że to stoi na Googlu, więc to jest taka wewnętrzna konkurencja. Także no, to jest na pewno spoko rozwiązanie, fajne, jeśli, jeśli rzeczywiście tego backendu nie mamy, a potrzebujemy jednak czegoś więcej niż samej bazy danych. Bo może chcemy zalogować się na przykład Gmailem czy tam Facebookiem, może chcemy sobie zapisać jakieś pliki – wideo, obrazki – i możemy sobie to też tam wrzucić. Potrzebujemy kilka takich rzeczy więcej niż sama, sama, sama baza danych.
No tutaj tego typu usługi też… no Heroku, też dość starszy, może nie tyle starszy, co doświadczony projekt, gdzie też możemy sobie taki back-end as a service… Na takim Heroku… Heroku też na Googlu chyba, nie wiem.
Nie pamiętam, ale też to jest, też taka sprytniejsza warstwa na jakieś, na jakimś providerze takim.
Tak. To wszystkie tego typu usługi właśnie ukrywają pewne, pewne rzeczy przed nami, udostępniając tą konkretną funkcjonalność, którą chcemy. No tutaj też możemy wszelkiej maści takie headless CMS-y zastosować, tak jak Strapi na przykład, gdzie generalnie po prostu setupujemy sobie, można powiedzieć jak w klasycznym CMS-ie, nasz content czy nasze, czy nasze jakieś tam rzeczy, które chcemy gdzieś hostować, gdzieś zapisać, i nasza aplikacja frontendowa, ten headless nasz end, tą usługę odpytuje, przedstawia, prezentuje to, co potrzebujemy.
Więc no, to są oczywiście rzeczy, które możemy użyć produkcyjnie, jak najbardziej. To nie ma tutaj jakby żadnego, one nie są jakieś, jakieś gorsze, jakieś bardziej…
Przeciwnie, są przygotowane na to, nawet bardzo…
Fajna nawet w tym darmowym, darmowym jakby tutaj okresie ma bardzo wysokie limity na, na ilość danych czy na ilość requestów, więc spokojnie sobie poradzimy nawet z jakąś małą aplikacją produkcyjną pewnie, a te poziomy wyższe też nie są jakieś super drogie.
No i poziomy wyższe są już potrzebne na przykład do Cloud Functions.
Tak.
Albo, albo do storage’u.
Albo do storage’u, więc czegoś takiego, tego właśnie bucketowego, a la S3 na przykład. Tak, więc tutaj jak już musimy tam troszkę przejść krok wyżej, troszkę wsypać, ale tak jak mówisz, nie boli to, bo można przejść na ten plan wyższy i dalej mieć jeszcze te limity niewykorzystane, także spoko. A w darmowym jest naprawdę, spokojnie powinno wystarczyć do większości zastosowań, więc tutaj nie ma żadnego problemu.
No i w tym momencie też… bardzo dobry ten, ten ogniowy… ogniowy… znaczy, ja sobie bardzo chwalę, ale…
Ale żeby nie było…
Ale żeby nie było, to może zapytamy też o kilka przykładów tutaj negatywnych.
Właściwie tak fajnie było, że ja już zapomniałem większość. Ale coś, coś mnie tam faktycznie ugryzło w nim, nie pamiętam już, o co to chodziło.
Bo ten twój przykład z tymi warunkami logicznymi, których było tam N, już nie dało rady więcej.
Pewne ograniczenia, właśnie, jeśli chodzi o warunki logiczne w zapytaniach, ale jest to dość dobrze w dokumentacji opisane, więc nie powinno to być zaskoczeniem. Dość łatwo jest to odgrzebać i możemy sobie to odnaleźć, ale są tam pewne takie kruczki. Ale dokumentacja jest bardzo fajna i są przykłady naprawdę w wielkiej ilości języków, jak poszczególne rzeczy można sobie zapisać, więc jakby używanie tego…
Chyba właśnie najbardziej zgrzytało w tych funkcjach, tak tak sobie teraz szybko odświeżyłem, bo bo właśnie to było coś takiego, co chcieliśmy zastosować przez moment, ale skończyło się, że jednak ominęliśmy to i zrobiliśmy inaczej, nie. Także to właśnie chyba przez, że po prostu te funkcje jakieś takie bardziej toporne były, nie. To wszystko było takie zwinne, sprytne, eleganckie, a te funkcje takie ciężkie.
Tak, odstawały troszeczkę. Wygoda użycia była niespecjalnie.
Że one też były tak… Firebase się tak trochę do nich nie przyznawał, bo odsyłał do funkcji Google’owych w ogóle z ichniej chmurki.
Ale musimy przyznać, że akurat w tym projekcie, który tu często, często przypominamy, wydaje się, że wydatnie nam pomógł, jeśli chodzi o szybkość. I jeśli pomyślę sobie, że miałbym teraz mieć zamiast tego nawet klasycznego, lekkiego Spring Boota, ale jednak mieć jakąś instancję, której gdzieś tam musiałbym doglądać, mieć tego Springa, logi przepatrywać, to tak naprawdę zabrałoby nam to zdecydowanie więcej czasu i na pewno by nie było to to takie szybkie.
Nawet jeśli chodzi o taki prosty cykl developmentu na zasadzie, wiadomo, interfejs jest zmienny w takich pierwszych etapach życia projektu, bardzo często gdzieś tam jakieś pola, obiekty rozszerzamy, dodajemy jakieś atrybuty, wartości. No i naprawdę wygodnie jest, mając po prostu tą NoSQL-ową, dokumentową bazę danych, dodać w naszym TypeScripcie, w naszej formatce nowe pole, automatycznie widzieć je, jak zapisuje się w Firebase.
TypeScript mi zgrzyta.
Już wiem właśnie, tak mi się chyba kojarzyło, że tutaj więcej zgrzytów było odnośnie frontu niż samego Firebase’a.
Jakieś takie śmieszne… No właśnie, konstruktorów nie idzie robić porządnie. No dobra, to tak do końca nie, ale trzeba było to w nim rzeźbić.
Firebase, ta. No ale właśnie taka, taki brak schematu w ogóle to będzie taki plusik dodatni do wszystkich takich NoSQL-owych wynalazków, bo dużo szybciej się nawet na zwykłym Mongo robi takie prototypowanie niż na najprostszym SQL-u.
Ale zwłaszcza w takim połączeniu, tego braku schematu bezpośrednio z frontem, no bo tutaj mieliśmy to połączenie z Firebasem, więc nawet to nie musi przechodzić przez jakieś Spring JPA, gdzie jednak musimy to pole chociażby dodać, ten atrybut dodać, adnotację może jakąś.
De facto JSON w JSON i poszło.
Dokładnie, dokładnie. Na tym etapie jakby to super działa, bo nie potrzebujemy tu jakiś wielkich rozważań, jak pole ma się nazywać, jak w ogóle…
Bo ono się będzie zmieniało 1500 razy.
Dokładnie, dokładnie, więc tutaj to.
Czyli testujemy to jakoś? Nic nie testujemy, czy…
Kwestia długu technologicznego
Znaczy, w sensie automatycznie. Właśnie, to jest, to jest kolejna z tych rzeczy. Co z tym długiem technologicznym, bo myśmy go tylko tak na ząb, na szczyptę.
Ja powiem tak. Dobra. A ja przytnę. Nie musisz spłacać długu technologicznego, jeśli twój projekt upadnie.
O! No to może, może niekoniecznie jest to dobra przesłanka dla prototypowania. Albo parafrazując, parafrazując…
Dług technologiczny, czyli pewnie powstanie pisząc w ten sposób, tak jak tutaj omawiamy, on pewnie powstanie. Oczywiście ten dług, w jakiej wysokości, to już zależy od nas. Ale dług technologiczny musimy spłacić dopiero, kiedy projekt naprawdę wejdzie w fazę no już nawet może poza MVP. Może gdzieś tam nam delikatnie doskwierać w fazie MVP, ale w tym momencie jakby, można powiedzieć, finansowanie naszej aplikacji długiem technologicznym przyspiesza poniekąd rozwój. Bo to jest taki mały trik, że my tego długu najczęściej nie będziemy spłacać.
Dokładnie, bo po prostu genialnym posunięciem wywalimy to wszystko do kosza.
Czyste cięcie: od prototypu do MVP
Dokładnie. I zaczniemy pisać porządnie, bez długu. Czyli tam się wszystko odbędzie zgodnie z przepisami, tak jak w Fyre było, nie, że się tam te 3 miliardy zapodziały kiedyś i jakoś tam się to tam… no dokładnie, piętrzy się ten dług gdzieś tam wysoko.
Tutaj tak sobie, sobie delikatnie, ale generalnie właśnie chodzi o to podejście, żeby zapomnieć o pewnych wzorcach, no które zmuszają nas w takim normalnym, codziennym życiu do jakiś ekstra kroków, które mają właśnie, no czy to zapobiec właśnie powstawaniu pewnych problemów w przyszłości, czy chociażby to pokrycie testami. No bo jeśli mamy ten produkt, ten projekt na początkowym etapie życia, wiemy, że wymagania będą się zmieniać, wiemy, że klient będzie to zmieniał, bo też jest etap…
To jest ciągła ewolucja.
Ciągła ewolucja. Więc jak w takiej sytuacji możemy polegać na testach, jeśli one tak naprawdę będą musiały być cały czas przepisywane? No nie ma to większego sensu.
Chyba że mamy już w tym momencie naprawdę jakieś wyryte w kamieniu flow, co się raczej rzadko zdarza. Może mamy jakieś strasznie restrykcyjne wytyczne. Może tak jak jakiś algorytm srogi musimy mieć, nie. I musimy wiedzieć, że ten algorytm dobrze działa, bo zaraz nam tutaj testy użytkowników wykażą te wszystkie warunki brzegowe, o których mówiliśmy, nie. No to okej, tu możemy sobie w tym obszarze pozwolić na luksus i obtestować to jednostkowo i git, mieć pewność, że to, co zaimplementowaliśmy, jest okej.
Ale trzeba sobie zdawać sprawę, że jakbyśmy tak na linii czasu rozłożyli ten kod, który budujemy na potrzeby prototypu, a później MVP, to pomiędzy nimi jest przerwa. I to nie są dwa te same kody.
Nie muszą być.
Nie muszą być. Czyli możemy sobie to wyprototypować w technologiach takich, których używa się szybko – właśnie te, które na przykład omówiliśmy – a później przejść do stabilnych rozwiązań, takich, które cały świat rozumie, na przykład, nie. Żeby tam już nie było, że nie mamy backendu, bo musimy mieć backend, to miejmy go w czymś normalnym, a nie w czymś dzikim, nie. No to napiszmy go sobie tak, jak się pisze te backendy, nie, użyjmy architektury takiej, jak trzeba. Bo prototyp nam pokazał, jakie są wymagania, na przykład, nie.
Już my sami wiemy, jakie są wymagania techniczne. Na przykład wiemy, jakie są problemy, więc może możemy dobrać odpowiednie narzędzia do nowych problemów. Więc też to, ta ta iteracyjność, no też mocno pokazuje właśnie jakby te, te zalety, które, które nam z tego wychodzą. No nie możemy jakby do wszystkich problemów stosować tych samych narzędzi, wszystkiego tam młotkować tym naszym młotkiem.
Wszystko.
Więc no tutaj jakby to, nie są może wszystkie z tych narzędzi, nie są może jakieś super powszechnie czy czy często używane w takiej codziennej pracy, ale generalnie no warto jednak w swoim gdzieś tam takim, można powiedzieć, przyborniku wiedzieć, że jeśli potrzebujemy zrobić coś na szybko, weźmy sobie ten kawałek, sklejmy sobie z tą rzeczą i będziemy mieli gotowy kawałek działający. Zobaczymy, jak to działa, zobaczymy, jak biznes to przyjmie.
Jeśli to się sprawdzi, przejdziemy dalej.
Jak ludzie to przyjmą, jak ludzie to przyjmą. Tutaj też może, jakby też takie, też może przekonanie też klienta czy biznesu, że to, co teraz, te narzędzia, które teraz używamy, one niekoniecznie są gorsze, niekoniecznie oznaczają, że będziemy musieli wszystko przepisać. Że tak jak ty, drogi kliencie, zmieniasz swoje wizje i dostosowujesz swój produkt, tak i my od strony technicznej musimy robić to samo. Nie możemy wyjść od takiego pełnego stacku w pełnej okazałości, robić jakąś malutką biznesową rzecz i kontynuować to od początku do końca, no bo to, to może się nie sprawdzić.
I to się nie sprawdzało.
I to się nie sprawdzało. No tak naprawdę tak powstawały projekty wiele, wiele lat temu, kiedy startowało się…
I tak upadały.
I tak upadały. Startowało się z pełnym stackiem. No można też powiedzieć, wybór narzędzi i technik był mniejszy, więc wiadomo, zawsze się brało Oracle’a.
Zawsze się brało, oczywiście.
Jakiegoś JBoss… JBoss to jeszcze w miarę lekki. Jakiegoś WebSphere’a…
To był, to był luksus.
Czy inny Oracle Application Server. I z takim wielkim orężem podchodziliśmy do naszego klienta i mówiliśmy: „Dobra, to co tam trzeba zrobić, bo my to już mamy odpalone nasze agregaty”.
A on: „Targi już były wczoraj”.
No właśnie. Więc, więc tutaj, tutaj, tutaj takie podejście troszkę zwinniejsze jest nie tylko jakby w fazie prowadzenia projektu, ale też technicznego prowadzenia i rozwiązań projektowych. Tak bardziej, no kompleksowego prowadzenia tego od początku do końca.
Podsumowanie i zaproszenie do eksperymentów
W tym zagadnieniu interesuje nas to, drogi kliencie, żebyś jak przyjdziesz – jeśli nasz słuchasz, tak, lepiej, żebyś słuchał – jeśli przyjdziesz ze swoim pomysłem, to żebyśmy ci jednak pomogli ten pomysł dowieźć, nie, do takiej fazy, gdzie można stwierdzić: „okej, jest spoko i jedziemy dalej, robimy to właśnie MVP”.
Czyli zapraszamy do robienia takich eksperymentów. One są bardzo przyjemne.
Jak najbardziej, kupa zabawy po drodze.
Mnóstwo, mnóstwo śmiechu i, i ten, i efekty są…
Efekty są pozytywne.
Pozytywne, co już sprawdziliśmy na…
Widzimy je.
Dokładnie. I jeszcze może będzie okazja nawet trochę więcej o nich porozmawiać, tak jak Michał powiedział na początku.
Tak, tak. Uknuliśmy taki plan, żeby zorganizować tutaj może jakąś kontynuację tego wątku i już właśnie zaprosić może ekipę ze strony klienta, żeby klient sam poopowiadał o tym, jak my ten Rapid robiliśmy, bo razem robiliśmy – i my, i klient. Czyli dobry ten Rapid, co?
Dobry ten Rapid, dobry. Ja będę, ja będę kontynuował, jeśli będę miał okazję.
Ja też tam wytrzymam z tym TypeScriptem.
TypeScript nie jest wymagany do Rapidu. Oczywiście ktoś mógłby powiedzieć, że w JavaScripcie byłoby jeszcze bardziej Rapid, więc może tutaj wzięliśmy, wzięliśmy nie to rozwiązanie do naszego Rapidu.
W JavaScripcie to już w ogóle nie wiem, co z konstruktorami.
W ogóle. No, no, okej. Także oczywiście tak, jeśli ktoś zarzuci, że że wzięliśmy TypeScript, a mówimy o Rapid, okej, no tutaj po prostu nasze backendowe naleciałości wzięły górę.
Mimo że nie było backendu.
Więc proszę, proszę nas nie hejtować w komentarzach. Ale zapraszamy do komentowania, oczywiście, do lajkowania.
Zakończenie
Może ktoś ma jakieś fajne spostrzeżenia.
Jasne.
Albo lepsze, na przykład.
Albo uwagi wręcz odwrotne do naszych tutaj.
Że jednak do kitu ten Rapid, to nie powinno tak robić.
Nie powinno. Jednak, jednak solidny Oracle jest, jest lepszy.
Tak. To też chętnie możemy podyskutować. No to co, to chyba, chyba jednak ogólnie pozytywnie.
Ogólnie pozytywnie.
Dzięki, Wojtek, i do następnego.
Do następnego, dzięki. Trzymajcie się, cześć.