Jak ekstremalnie szybko prototypować?

Transkrypcja

Dziś moim gościem jest Adam Majcher, dwukrotny laureat NASA Space App Challenge. Adam opowie nam o prototypowaniu, które pozwoli nam szybciej i lepiej zbudować naszą aplikację. Adamie, dziękuję, że przyjąłeś, moje zaproszenie na rozmowę.

Cześć, również dziękuję.

To może zacznijmy od Twojej osoby – powiedz nam, co łączy cię z branżą IT?

Może zacznijmy od początku. Kiedy miałem 13-14 lat, jak większość programistów, zacząłem od tego, że interesowało mnie to, jak powstają strony internetowe. Kiedy zacząłem zadawać sobie pytania, jak one powstają – dlaczego niektóre są na telefonie, a niektóre na komputerze, jak to działa – to postanowiłem się tego nauczyć. Wtedy też zacząłem chodzić do technikum informatycznego i od tego to wszystko się zaczęło. Moim pierwszym zakończonym z sukcesem projektem była strona szkoły i dzięki niemu dostałem się na praktyki w Hiszpanii poprzez program Erasmus, gdzie pracowałem przez cztery tygodnie. Było to moje pierwsze zetknięcie z branżą. Zobaczyłem od środka, jak wygląda Software House, jakie role przyjmują osoby w zespole po to, żeby zarządzać projektami, rozpoczynać te projekty, kończyć je z sukcesem i rozwijać.

Potem, po powrocie do Polski postanowiłem, że chciałbym, aby taka praca była moim celem, do którego będę dążył. W trakcie jednego z takich szalonych projektów, w których miałem przyjemność uczestniczyć, Uczelni dla nastolatków na WSIiZ (uczelni u nas na Podkarpaciu), pierwszy raz nauczyłem się, czym jest Design Thinking i czym jest proces rozwiązywania problemów. Zaraz po niej zostałem zachęcony do tego, żeby wziąć udział w NASA Space Apps, o którym wspomniałeś. To jest hackathon, czyli 24/48-godzinny maraton rozwiązywania problemów. W tym przypadku był on nastawiony głównie na to, że rozwiązywaliśmy problemy. Co roku NASA udostępnia dla studentów/uczniów około 30 problemów po to, żebyśmy zmierzali się ze sobą w tych konkurencjach i walczyli o najlepsze nagrody. Zdecydowałem się zebrać grupę znajomych. Pojechaliśmy na ten hackathon i zaczęło się.

W trakcie tego hackathonu okazało się, że nie tylko programowanie jest najważniejszą umiejętnością, ale poza nią jest też cały proces związany z rozwiązywaniem problemów, z definiowaniem tych problemów jeszcze wcześniej, z pomyśleniem o tym, w jaki sposób użytkownicy korzystają z naszych aplikacji, jaki jest ich cel, jakie mają motywatory i myślenie o dostarczaniu wartości. Okazało się, że hackathonów nie wygrywają ci, którzy najlepiej programują, ale właśnie ci, którzy znajdą ten najbardziej palący problem, potrafią go nazwać, zdefiniować i rozwiązać tak, że to użytkownik jest prze szczęśliwy z powodzenia aplikacji. Takich hackathonów miałem w życiu kilka, tak jak wspomniałeś, dwa z podium i zaraz po nich zaczęła się moja aktualna przygoda, czyli tworzenie pobocznych projektów, praca jako programista i, można już nawet powiedzieć, project manager. Zarządzałem też różnymi projektami dla firm i w tym momencie jestem w miejscu, w którym sam tworzę swoje projekty, wymyślam, jakimi problemami mógłbym się zająć i prototypuję je na boku.

Skoro wywołałeś już ten temat, to może powiedzmy, czym w ogóle jest prototypowanie oprogramowania i jakie są jego główne zalety? Powiedziałaś już, że dzięki temu można wygrać hackathon, ale może jest jeszcze coś więcej?

Jasne. Wyjaśnienie dla naszych słuchaczy: proces prototypowania to jest jeden z elementów całego procesu rozwiązywania problemów i żeby być genialnym w prototypowaniu, warto zrozumieć cały kontekst tego, czym tak naprawdę jest prototypowanie i rozwiązywanie problemów poprzez tworzenie rozwiązań. Zacznijmy od początku – kiedy przychodzi do nas klient/użytkownik, dla którego chcemy coś zrobić albo kiedy tworzymy jakąś aplikację/jakiś nowy feature, musimy na początku zastanowić się po co, dlaczego, z czym ta osoba do nas przychodzi? Jedną z takich najwspanialszych metodyk do tego, żeby to sobie poukładać w głowie i rozwiązać w taki sposób, żeby zadowolić tego naszego użytkownika, jest metoda Design Thinking. Polega ona na tym, że na początku mamy wywiad z naszym klientem/ potencjalnym użytkownikiem i ten etap nazywa się empatyzacją. Chodzi tutaj o to, że wchodzimy w buty naszego użytkownika, poznajemy jego projekty, próbujemy się wczuć w jego buty.

Następnie mamy definiowanie problemów. To jest jeden z najważniejszych etapów, który definiuje nam później sukces, albo porażkę naszego eksperymentu, jakim jest proces produkcji oprogramowania, rozwiązań, między innymi właśnie w branży IT. Pozwolę sobie opowiedzieć taką anegdotkę, którą usłyszałem ostatnio w Lenny's Podcast. Bardzo polecam ten podcast wszystkim, którzy interesują się branżą IT, tworzeniem produktów i przygotowaniem rozwiązań. Jeden z gości opowiedział tam historię, w której, kiedy był mały, został wysłany na biwak – na taki wyjazd harcerski i przed wyjazdem dostał od rodziców szkło powiększające. Kiedy przyjechał na ten biwak, świetnie się bawił i ciągle eksperymentował. Pewnego razu przyłożył swoje szkło powiększające (dużą lupę) do pnia drzewa i chciał ten pień podpalić. Stał z tą lupą, próbował z jednej i z drugiej strony – wydawało się, że promienie skupiały się w jednym miejscu, ale płomień nawet się nie pojawił. Po czym przyszedł do niego inny harcerz, jego opiekun i mówi, słuchaj spróbuj tego i dał mu czarną nić, taką drobną czarną niteczkę. Kiedy przyłożył ten przyrząd do powiększania, niteczka natychmiast zapłonęła. O co chodzi? Chodzi o to, abyśmy definiowali problemy, które są możliwe do wykonania i którym damy radę sprostać, ale też takie, które będą miały impact i rozwiążą nasz pierwszy problem.

Tutaj dochodzimy do trzeciego etapu, jakim jest generowanie pomysłów. Zauważcie, że ten drobny chłopak, który był na obozie, mógł tę nitkę przeciąć na różne sposoby: mógł użyć zapalniczki, mógł użyć szkła powiększającego, nożyczek. Tych pomysłów na rozwiązanie danego problemu jest naprawdę cała masa i ludzie genialni w prototypowaniu i w całym procesie Design Thinkingu mają łatwość w tym, żeby te pomysły jak najszybciej generować w dużych ilościach (później opowiem wam jeszcze o tym, jakie kompetencje są do tego potrzebne i jak się ich nauczyć). Kiedy mamy już ten zestaw całej masy szalonych pomysłów, to wtedy przechodzimy do prototypowania.

Jednym z najczęstszych błędów w IT, jaki widzę w projektach, w których uczestniczyłem/które widzę na rynku, jest to, że zapala nam się magiczna lampka w głowie. Myślimy sobie: to rozwiązanie będzie genialne, będzie naprawdę wspaniałe. Natomiast w zasadzie zapominamy o tym, jaki problem ono rozwiązuje, czy rzeczywiście jest jakiś użytkownik, który z tym w jakiś sposób żyje – jest to dla niego coś, co jest problemem, co ma wpływ na jego codzienne życie i pracę. Bez tego zrozumienia nie mamy nawet po co przechodzić do prototypowania, rozwiązywania problemów, wymyślania rozwiązań na te problemy. Kiedy jednak zrozumiemy już dobrze ten etap, wymyślimy te nasze pomysły, przechodzimy do generowania takich prototypów.

Czym jest prototyp? Prototyp jest to sposób/próba rozwiązania problemu, który mamy na samym początku, w bardzo maksymalnie uproszczony sposób, który zajmuje mało czasu. Często stworzenie prototypu powinno zająć nawet kilkanaście albo kilkaset razy mniej czasu niż standardowe wytworzenie produktu. Bardzo ważne jest też to, żeby nie poświęcać zbyt dużo czasu na swój pierwszy prototyp – on powinien dać nam jedną bardzo prostą odpowiedź i ta odpowiedź jest nam dawana przez naszego użytkownika: czyli tworzymy sobie prototyp na bazie jednego z naszych pomysłów, które wygenerowaliśmy wcześniej. Takie pomysły warto też wcześniej ocenić, pod kątem tego, czy jesteśmy w stanie je wykonać – jest to potencjalnie jedno z kryteriów. Zadajmy sobie pytanie: czy ten pomysł robi to najefektywniej? Ile nas to będzie kosztować? Możemy ten pomysł rozwiązać bardzo długim procesem dewelopmentu funkcjonalności i będzie on niesamowicie drogi albo możemy użyć np. jakiegoś małego gotowego narzędzia, z drobnym costem, ceną API i osiągniemy ten sam rezultat.

Może dopytałbym tutaj o jedną rzecz – bo chyba mało osób zdaje sobie sprawę z tego, że prototyp jest po to, by w większości przypadków się nie udać. To znaczy, mam wrażenie, że często ludzie podchodzą do tematu w ten sposób, że OK, mam prototyp i chcę, żeby on już zadziałał. A zadziała on raczej za którymś razem, a nie za pierwszym?

Niesamowicie problematyczne staje się przywiązywanie emocjonalne do swoich prototypów i do swoich eksperymentów. My jako ludzie z IT nie mamy za bardzo połączenia z branżą medyczną albo z branżą związaną z naukowcami, z biologami itd. Kiedy podpatrzymy sobie na to jak robią to oni, jak wymyślają leki, jak konstruują swoje hipotezy, to zwrócimy uwagę, że oni nie przywiązują takiej wartości emocjonalnej do swoich prototypów, przynajmniej nie starają się przywiązywać do swoich eksperymentów itp. I to jest jednym z kluczy – czyli z góry sobie załóżmy, że tych prototypów powinno być wiele, że te prototypy nie powinny być w żaden sposób tak wypieszczone do ostatniego piksela, czy do ostatniej linijki kodu, ponieważ proces prototypowania powinien być zapętlony. Przygotowujemy sobie jakieś nasze rozwiązanie i teraz powiem o tym, jak może to wyglądać w branży IT (jak polecam, żeby to wyglądało): np. w tworzeniu prototypów aplikacji webowych możemy podejść do tego w ten sposób, że nakodzimy całą aplikację z palca od zera. Czy jest to spoko? Pewnie już wiecie, że raczej nie, bo mamy bardzo długi koszt i czas związany z tym, żeby dostać odpowiedź na pytanie, czy ta aplikacja rozwiązuje problem naszego użytkownika. Natomiast ten sam efekt możemy uzyskać, kiedy bardzo szybko zaprototypujemy np. w takich narzędziach jak Figma czy FigJam – to bardzo proste prototypy, czyli makiety, różnego rodzaju schematy, pewnego rodzaju wytłumaczenie, jak coś może działać.

Może nie wszyscy wiedzą, o co chodzi z makietami, że często jest to też interaktywne, że możemy zrobić coś w taki sposób, że coś jest klikalne, możemy przejść do kolejnego widoku, że tam działa już coś, co powoduje, że użytkownik nietechniczny może już nawet widzieć, na jakiej zasadzie to działa.

Oczywiście. Polecam w tym procesie zacząć od jak najprostszych rozwiązań. To o czym wspomniałeś to są np. high level koncepty, prototypy. One są wspaniałe w przypadku prototypowania, kiedy mamy dużą ilość czasu, kiedy nie musimy się spieszyć. Powrócę tutaj do przykładu hackathonów: np. popatrzcie sobie jak robią to najlepsi kiedy mają np. 24 godziny, żeby coś wyprototypować. Nie ma czasu na to, żeby zaczynać od pieszczenia, tworzenia elementów od zera. Tam jest czas tylko na to, żeby jak najszybciej zwalidować swoje hipotezy, sprawdzić i dostać odpowiedź na pytanie: drogi użytkowniku, czy gdyby takie rozwiązanie istniało, działało w taki sposób, to byłbyś usatysfakcjonowany z tego rozwiązania? To jest najważniejsze pytanie, jakie powinniście dzisiaj wyjąć z tego podcastu – czyli zapytanie się użytkownika: hej, czy gdyby to tak działało, to byłbyś w stanie zapłacić za to, byłbyś usatysfakcjonowany? I odpowiedź może was totalnie wybić i zdziwić, ale macie pewność, że jest prawdziwa, że ona was doprowadzi do tego produktu, do tego idealnego rozwiązania, którego chcecie.

Przypomina mi się też historia Henry’ego Forda: gdybym zapytał ludzi czego potrzebują, to powiedzieliby, że szybszego konia, a nie zawsze o to chodzi, więc trzeba też na to mocno uważać.

To jest świetna anegdota i jest ona powielana przez różnych specjalistów, founderów naprawdę wielkich spółek np. takich jak Waze, którego founder powiedział o tym Fall in love with the problem: totalnie zakochaj się w problemie swojego użytkownika, bo rozwiązań jest naprawdę masa. Nie wszystkie będą najlepsze. Część z nich sprawdzi się na jednych rynkach, druga część się nie sprawdzi. Nawet ich większość może być totalnie odrzucona w całym procesie produkcji i oprogramowania. Natomiast fall in love with the problem, czyli zakochaj się w problemie – problem się raczej nie zmieni, chyba że rozwiąże go nasza konkurencja.

Trochę wybiłem cię z rytmu. Czy chciałbyś coś dodać odnośnie do samych prototypów?

Tak. Jednym z ostatnich i de facto tym najważniejszym elementem prototypowania jest testowanie. Trochę już o nim opowiedziałem – chodzi tu o to jedno ważne pytanie, które powinniśmy zadać. Kiedy mamy okazję przeprowadzać ten proces dłużej, to warto poszerzyć je o inne pytania: gdybyś miał /miała dodać tu coś co usprawni, coś nowego, coś, co bardziej przybliży cię do rozwiązania tego problemu, to co by to było? Albo zapytaj: czy gdyby to działało w taki sposób, to czy bardziej by cię to usatysfakcjonowało? Czy przybliżyłoby cię do tego rozwiązania? Czy byłbyś bardziej szczęśliwy? Czy byłbyś w stanie zapłacić za to więcej? To są bardzo ważne pytania, na które musicie znać odpowiedź tworząc produkty, ale nie tylko tworząc. Jeżeli jesteście programistami, jesteście w jakimś drobnym ułamku tego całego procesu, to waszą gigantyczną przewagą będzie prototypowanie. Nie boję się tego powiedzieć, ale zginiecie na rynku w zderzeniu z seniorami, z osobami, które mają więcej kompetencji od was, jeżeli nie nauczycie się czegoś więcej niż tylko programowania. A prototypowanie i cały proces tworzenia rozwiązań może być u was kluczem do sukcesu.

Miałeś też przykład z NASA Space Apps. Chciałbyś go przytoczyć?

Oczywiście. Kiedy podchodziłem do swojego drugiego hackathonu były ogromne emocje, dlatego że pierwszym razem zwyciężyłem z drugim miejscem w ogólnej klasyfikacji u nas lokalnie w NASA Space Apps i wtedy ciążyła nade mną gigantyczna presja tego, żeby znowu stanąć na tym podium. Kiedy chciałem się z nią zmierzyć, to jednym z elementów, które sprawiły, że zdobyłem wtedy trzecie miejsce i stanąłem na podium było to, że jeszcze bardziej skupiłem się na procesie prototypowania i bardzo szybkiej walidacji. Akurat w tym wyzwaniu NASA wybrałem sobie problem, jakim były bardzo duże zbiory danych dotyczące projektów open source NASA. To było 550 projektów z bardzo różnymi dokumentacjami, często bardzo niekonkretnymi, napisanymi w jakimś HTML-u i CSS-ie bez żadnego JS-a, w różnych porozrzucanych repozytoriach. I nie myślcie sobie tutaj o repozytorium, jakie mamy na GitHubie, gdzie mamy dokumentacje, link i wszystkie szczegóły oraz osoby. Nie − to były takie bardzo proste strony, które tłumaczyły czym zajmują się projekty, które NASA promuje i sam tworzy. Problem był taki, że ta informacja była bardzo rozproszona, tych projektów było bardzo dużo, one były nieczytelne i wyobraźcie sobie, jak gigantyczny problem miał student, który chciał się zaangażować w taki projekt open source, ale nie mógł wybrać tego idealnego. To był ten pain problem – muszę zobaczyć 550 projektów, żeby wybrać ten idealny dla siebie. Dramat.

Przechodząc przez cały ten cykl, mogę opowiedzieć wam o tym, że wtedy zdefiniowałem sobie ten problem i zacząłem generować pomysły. Moimi pomysłami na rozwiązanie tego problemu bardzo szybko stała się aplikacja webowa. To jest coś, w czym mam kompetencję, by bardzo szybko ją zrobić, zaprototypować, więc od razu poszedłem w tą stronę. Kiedy pomyślałem sobie, dobra, to jaka aplikacja rozwiąże ten problem? – może zróbmy wyszukiwarkę, może zróbmy porównywarkę, może zróbmy listę rankingową, może zróbmy jakiegoś AI toola, (tak, już wtedy zaczynały się te czasy, kiedy jednym z pomysłów stawał się AI tool), może zróbmy coś, co samo za użytkownika wybierze ten idealny projekt i dopasuje go do niego: hej, przecież Netflix podpowiada nam, jaki serial powinniśmy obejrzeć. Czemu to nie może działać w ten sam sposób? I zacząłem opowiadać mentorom, innym uczestnikom hackathonu o swoim pomyśle: hej, słuchajcie, czy gdybyście mieli wyszukiwarkę, gdzie piszecie o waszym stacku technologicznym, o tym, jakich projektów szukacie i ta wyszukiwarka dałaby wam trzy projekty z uzasadnieniem – hej, ten projekt NASA będzie idealny, bo interesujesz się biotechnologią, programujesz w Pythonie, a oni akurat mają taki stack itd., kolejne projekty – czy korzystałbyś z tego, czy dałoby ci to jakąś wartość? I w tym momencie usłyszałem to magiczne: tak, dałoby mi to wartość, to jest spoko dla mnie, chciałbym z tego korzystać, to rozwiązałoby mój problem. I po tych 12 godzinach pracy miałem tego orła w garści. Chodzi tutaj o to, że wiedziałem, jakie rozwiązanie będzie satysfakcjonowało moją grupę docelową. A miałem do niej niedaleko, bo siedzieli obok mnie, byli ze mną. Sam też byłem potencjalną grupą docelową, więc było mi o wiele łatwiej. Kiedy wiedziałem już, co takiego mogę zrobić, przeszedłem do prototypowania.

Moje prototypowanie wyglądało w ten sposób, że odpaliłem sobie na początku FigJam'a – to jest taki whiteboard, możecie porównać go do kartki papieru, tylko tej elektronicznej i zacząłem sobie szkicować: dobra, jak mógłby wyglądać taki potencjalny portal, taka wyszukiwarka? Zacząłem też szukać patternów, które są już wykorzystywane w świecie IT. Zwróciłem uwagę np. na to, jak działa product hand: macie jakąś listę rankingową różnych produktów, które są na rynku. Macie też wyszukiwarkę na górze, ale taką wyszukiwarkę trzeba „podrasować”. Co by tu zrobić, żeby jeszcze bardziej dopasować ten projekt do użytkownika? Zwykłe filtry nie wystarczą, żeby z 550 znaleźć coś indywidualnego. I wtedy wpadłem na pomysł: hej, wrzućmy do tego AI. Zaprojektujmy, jak mógłby działać model, który dopasowuje te projekty do studentów. Wtedy byłem już w domu. Wystarczyło kilka godzin by zaprototypować makietę (dokładnie tak jak wspomniałeś, już high-levelowo, bo wiedziałem dokładnie, co rozwiąże problem mojego użytkownika), po tym czasie stworzyć do tego prezentację. Jak na wszystkich hackathonach, powinniście omówić, jaki problem rozwiązujecie, dlaczego wasze rozwiązanie jest dobre i skuteczne. I stało się – magiczny gong albo dzwonek wybił czas. 24 godziny się skończyły. Twoje rozwiązanie poszło już do jurorów.

Radą, którą mógłbym dać wszystkim, którzy zaczynają brać udział w hackathonach jest to, że 24 godziny to jest naprawdę mało. Nie macie czasu na robienie bardzo zaawansowanych rozwiązań, na robienie pełnego kodu takiego rozwiązania. Taka makieta jako prototyp w Figmie wygrała trzecie miejsce, pokonała kilkaset uczestników, którzy mieli inne, równie świetne pomysły, ale to, co sprawiło, że ta prosta makieta (patrząc na nią dzisiaj nie ma ona nic skomplikowanego) okazała się być najbardziej wartościowa jest to, że doskonale zrozumiała problem, w prosty sposób na niego odpowiedziała i wyczerpała ten problem przez prototyp. Ot i cała historia.

OK, to skoro wiemy już, że prototypowanie jest tak istotne i takie pomocne, to powiedz nam proszę, jakie w ogóle kompetencje, narzędzia i technologie uważasz za kluczowe w szybkim prototypowaniu?

Super. Zacznijmy tu od kompetencji. Są takie dwie podstawowe kompetencje, które moim zdaniem odgrywają największą rolę w całym procesie tworzenia rozwiązań, ale w szczególności w szybkim prototypowaniu. Chodzi tutaj o kreatywność i otwartość na rozmawianie z potencjalnymi użytkownikami. Są to totalne game changery. Dlaczego? Dlatego że kreatywność i nasze doświadczenia są szczególnie ważne na etapie wymyślania pomysłów. To, że nie macie 15 lat doświadczenia w branży, nie jesteście jeszcze seniorem, nie znaczy, że nie obejrzeliście tysiąca przykładów rozwiązań danych problemów. Pewnie na co dzień korzystacie z tych rozwiązań. Widzicie je otwierając kartę w przeglądarce, widzicie je oglądając nowy serial na Netflixie. Wy te wszystkie patterny i rozwiązania macie w głowie.

To może wejdę ci w słowo i powiem, że może nawet jeśli nie mamy tego w głowie, to może jest nam w stanie podpowiedzieć ChatGPT lub inna sztuczna inteligencja? Co o tym sądzisz?

Tak. Możemy tutaj wybrać dwie drogi – odwołać się do doświadczeń, które mamy w głowie albo zacząć szukać. Poruszyłeś tu bardzo ciekawy wątek, czyli nowe technologie – LLM-y, które powstają, są w stanie nam w tym pomóc, a może nawet przeszkodzić. Jak to wygląda? Wróćmy do tego jak działają LLM-y: mamy jakiś zbiór danych, jakąś bardzo dużą bazę danych, którą karmimy, do której dodajemy kolejne źródła wiedzy i ta gigantyczna baza danych w dużym uproszczeniu jest użyta do tego, żeby wytrenować nam model językowy. Model językowy w ogromnym uproszczeniu polega na tym, że przewiduje on jakie kolejne słowa powinniśmy wygenerować/wypluć z naszego modelu, żeby statystycznie zadowolić naszego użytkownika – żeby miało to jak największy sens, było statystycznie najbardziej poprawne i najbardziej prawdziwe (najbardziej prawdziwe to nie znaczy, że będzie to fakt). I takie rozwiązania, kiedy wpiszemy: hej ChatGPT, słuchaj, mam problem z tym, że studenci NASA chcieliby, aby te projekty, które widzą na open source'owych portalach były po prostu bardziej przystępne. Oczywiście ChatGPT podpowie nam, że hej, słuchaj – może wyszukiwarka, może jakiś inny pattern? Natomiast to, co zrobi ChatGPT to będzie odwołanie się do tych wszystkich danych, które już na początku zostały do niego załadowane. Jest to świetne rozwiązanie, kiedy potrzebujemy coś zrobić na szybko np. kiedy mamy kilka godzin i musimy wymyślić bardzo dużą ilość propozycji – uważam, że to jest świetne rozwiązanie. Natomiast przestrzegam was przed nim w jednym bardzo konkretnym przypadku – kiedy marzycie o start-upie, chcecie stworzyć coś unikalnego, chcecie stworzyć coś, co jest bardzo ryzykowne, co ma małą szansę na udanie się, ale ta mała szansa – kiedy się uda – stworzy gigantyczną wartość. Nie szukajcie wtedy pomysłów w już istniejących narzędziach AI, bo one powiedzą wam o tym wszystkim, co już było.

Czyli wracając do tej historii z Henrym Fordem, rozumiem, że ChatGPT odpowie, że potrzebujemy szybszego konia, a nie po prostu auta, tak?

Tak. Wracając do historii z Henrym Fordem, ChatGPT mógłby dodać dowolną inną odpowiedź, która byłaby na podstawie tych wszystkich danych, które zostały wtedy zebrane. To, co zrobił Henry Ford było po prostu majstersztykiem – nie był to jakiś rocket science – po prostu zwrócił uwagę na to, co się nie zmieni. Nie zmieni się problem: ludzie chcą podróżować jak najszybciej z punktu A do punktu B. Taką filozofię wyznają również w Amazonie. Kiedy przeczytacie analizę bądź sami sprawdzicie listy do akcjonariuszy, jakie wysyłał Jeff Bezos, to nic tam się nie zmieniło na początku od lat. Jeff zawsze wspominał o kilku takich bardzo podstawowych rzeczach, które nigdy się nie zmienią. Nigdy nie zmieni się to, że użytkownik chciałby mieć zawsze największy wybór, jaki tylko może mieć. Raczej nie ma ludzi na świecie, którzy chcą powiedzieć no ja nie chcę mieć wyboru. Problemem jest to, jak dostarczyć duży wybór użytkownikom. Nigdy też nie chcemy, aby nasza paczka się spóźniała. Nie znam takiej osoby na świecie, która lubi, kiedy paczki się spóźniają. Trzecia sprawa to jest dostęp do nieograniczonego zbioru produktów w jak najniższych cenach. Ludzie nie lubią przepłacać. To są jedne z trzech rzeczy, które wskazał Jeff Bezos na samym początku i to na nich się skupił.

To może opowiedziałbyś jeszcze o otwartości – porozmawialiśmy sobie na temat kreatywności, a jak jest z otwartością?

Super. To jest bardzo niepopularna w Polsce (i powiem to śmiało przy skali naszego 40-milionowego kraju) kompetencja. W naszych korzeniach mamy coś, co sprawia, że raczej obawiamy się oceny innych: obawiamy się tego, co ktoś pomyśli, kiedy ja go o coś zapytam. Może uzna mnie za wariata, może uzna mnie za dziwaka – raczej tego nie chcemy? Natomiast kluczem do sukcesu jest kompetencja, którą część osób ma naturalnie. Tutaj was pocieszę – tak, da się ją wyćwiczyć, da się wytrenować otwartość poprzez trenowanie i uczenie się o niej, o czym też powiem. Otwartość pomoże i będzie naszym wytrychem w jednym bardzo konkretnym procesie. Chodzi tutaj o proces walidacji naszego rozwiązania i proces jeszcze przed nim – tego, żebyśmy w ogóle poznali problemy. Czyli nie poznasz problemów swoich użytkowników, jeśli z nimi nie porozmawiasz. To jest oczywiste.

Możesz czytać najlepsze opracowania McKinseya, wszystkich wielkich firm konsultingowych. Możesz czytać najlepsze raporty, ale kiedy nie zadzwonisz, nie porozmawiasz, nie zapytasz na Facebooku czy na LinkedInie swojej grupy docelowej, swoich potencjalnych użytkowników, nie zdzwonisz się z nimi: hej, masz ochotę na 15-minutowego calla? Chciałbym poznać jak robisz to i to albo jaki masz problem z tym i tym. Bez tego tak naprawdę skazujemy cały nasz projekt na porażkę i na to, że on rozwiąże problem, ale będzie to tylko nasz problem, bo naszym problemem jest to, że chcemy stworzyć taki produkt.

Wracając do kompetencji, jaką jest otwartość – na końcowym etapie mamy testowanie. Nie wyobrażam sobie testowania bez swojej grupy docelowej. To jest bezsensowne, żeby testować rozwiązanie z grupą, która nie jest reprezentatywna, do której to rozwiązanie nie jest kierowane. I wtedy też potrzebujemy mieć tę otwartość do tego, żeby zagadać, podpytać.

Kiedy Stefan Batory, CEO Booksy, zaczynał z iTaxi, chodził on po lokalnych parkingach dla taksówek i pytał tych taksówkarzy: hej, słuchaj, jakie ty masz w ogóle problemy w związku ze swoją korporacją taksówkarską? Jak to się dzieje, że ty jeździsz? Na jakich zasadach? Jak wygląda ten proces? Co cię w nim wkurza? – polecam wam serdecznie przesłuchać kilka podcastów o tym, jak powstawało Booksy i iTaxi. I na początku tej historii ci ludzie odpowiadali: Panie, weź tam w ogóle, a idź, mi tu żadnych takich pytań nie zadawaj, ale upór, kreatywność i otwartość sprawiła, że na końcu Stefan dowiedział się o tych rzeczach – dowiedział się o tym, że korporacje taksówkarskie traktowały nie fair swoich pracowników, że był problem z tym, żeby znajdować nowe osoby do wsiadania do taksówek. Była cała masa problemów, które magicznie rozwiązał iTaxi.

To powiedz nam proszę jeszcze coś na temat narzędzi i technologii, bo ten temat na razie pominąłeś.

Jasne. Wróćmy może do tego przykładu NASA, bo już jesteście z nim zaprzyjaźnieni, znacie go. Kiedy tworzyłem swój produkt, czyli prototyp (można go tak nazwać) zwróciłem uwagę na to, że to powinna być aplikacja webowa – raczej ten interfejs będzie super. Naturalne jest więc to, że wybrałem do niego narzędzia, które jak najszybciej pozwolą mi sprototypować aplikację webową. Takie narzędzia to np. Figma, Adobe XD, wszystkie inne tego typu narzędzia, które w bardzo łatwy sposób pozwolą nam stworzyć szkic, np. low-levelowy prototyp czy mockup, czy też high-levelowy prototyp, czy mockup, który będzie wyglądał identycznie jak aplikacja, którą stworzymy – to wszystko zależy od tego ile czasu i zasobu mamy.

Narzędzia do prototypowania aplikacji webowych to więc zdecydowanie Figma, Adobe XD, inne podobne. Relume został ostatnio bardzo pozytywnie odebrany przez społeczność − bardzo szybko dzięki AI-owi jesteście w stanie wymyślić swoje kolejne podstrony, ułożyć schemat swoich aplikacji jako aplikacji webowych, czy w ogóle landing page'y. A co z całą resztą? Przecież tworzenie, rozwiązywanie problemów to nie tylko aplikacje webowe. Mamy też problemy, kiedy musimy zaprojektować bazę danych, kiedy musimy sprototypować: hej, Adam, Mateusz, zróbcie mi do wtorku schemat bazy danych – kto tego nie zna? I wtedy niesamowicie pomocne może okazać się takie narzędzie jak np. Postgres.new, który za pomocą AI pomoże wam w tym, żeby tę bazę wyprototypować, stworzyć jakieś wstępne połączenia i pokazać waszemu użytkownikowi, nawet PM-owi, czy członkom zespołu, jak to może wyglądać.

Kolejnym narzędziem do baz danych jest DBDiagram – bardzo popularne narzędzie (sam z niego wielokrotnie korzystałem) gdzie jeszcze nie napisałem żadnej linijki kodu, a już jestem w stanie widzieć i zwalidować to, czy moja baza danych ma sens, gdzie ma największe problemy, czy ona obsłuży te wszystkie dane, które potrzebuję, żeby się w niej zawarły.

Przechodząc już do ostatniej kategorii: wszystkie utilsy, można powiedzieć takie malutkie narzędzia, minitipy, które pozwolą wam szybciej prototypować. Tutaj może się ktoś śmiać, ale polecam kartkę papieru i ołówek. Gdy zaczynamy, nie ma nic prostszego niż nauczyć się opowiadania o waszych konceptach, pomysłach pokazując prototyp czy pomysł po prostu na kartce papieru – i jest to jeden z najprostszych sposobów, jakie wam zawsze rekomenduję, od którego warto zacząć. To, że nauczycie się jakichś narzędzi: Figmy, FigJama, czy nawet jest takie fajne narzędzie IcePanel – ono pozwoli wam zaprojektować architekturę aplikacji, szczególnie tych bardziej rozbudowanych nie pisząc ani jednej linijki kodu. Możecie przyjść na spotkanie ze swoim zespołem: Słuchajcie, robimy tak duże przedsięwzięcie, że powinniśmy zastanowić się nad tym, czy nie będzie żadnych problemów z integracjami albo z jakimiś kosztami np. tak wielkiej infrastruktury – hej, zaprojektujmy to na kartce, zanim będziemy szli w to dalej. I ja wiem, że dla części z was wydaje się to oczywiste, ale niestety jest jeszcze bardzo dużo osób, dla których prototypowanie i rozwiązywanie problemów w ten sposób nie jest domyślne.

To może po tej dawce informacji na temat narzędzi, warto w ogóle powiedzieć kto w zespole zajmuje się prototypowaniem?

Świetny temat. Zacznijmy od tego, że zginiecie, jeżeli nie nauczycie się prototypować i nie zaczniecie rozwijać swoich kompetencji poza waszą główną kompetencją, którą już macie. Wielu z was zaczynało swój proces rekrutacyjny albo zaczyna swój proces rekrutacyjny i w trakcie niego jednym z najbardziej widocznych, zostawiających jakiś ślad w pamięci HR-ów i w ogóle osób, które was zatrudniają, są takie wasze ekstra umiejętności. Jedną z takich umiejętności może być właśnie szybkie prototypowanie, znajomość tego procesu. Odpowiadając na pytanie kto w zespole powinien posiadać takie umiejętności – z definicji mamy takie dwie skrajności. Wyobraźcie sobie taką oś, na której po jednej ze stron mamy organizację/zespół, w której to jedna osoba tak do perfekcji wytrenowała tę umiejętność, niezależnie jaka jest to osoba. Może być to grafik, może być to UX, UI, może być to wasz PM, product owner, czy nawet back-endowec – to nie ma żadnego znaczenia. Po prostu ta osoba ma kompetencje świetnego generowania pomysłów, doskonale wie jakie problemy dotykają użytkowników, dla których tworzy, jakie prototypy mogłyby się sprawdzić w takich rozwiązaniach. Nie popadajmy też w skrajność, żeby te wszystkie kompetencje posiadała jedna osoba. Możecie sobie np. w zespole rozłożyć, że hej, słuchaj, ty genialnie robisz product discovery, rozmowy z potencjalnymi użytkownikami, klientami. Słuchaj, zrób to i podziel się z nami wnioskami. To jest jedna strona, kiedy to my wyznaczamy konkretne osoby. Po drugiej stronie spektrum mamy całe zespoły, które równomiernie posiadają te kompetencje w tym, żeby prototypować, wymyślić, znajdować problemy i je testować.

Oba te rozwiązania mają swoje wady i zalety. Na pewno, kiedy to wy jesteście w sytuacji, kiedy chcecie brać udział w najlepszych zespołach na świecie, tworzyć najlepsze technologie, to jakąś podstawę tego procesu powinniście mieć. To jest pewnik. Natomiast poszczególnymi etapami zajmują się już wyspecjalizowane osoby. Wyobraźcie sobie np. organizację jaką jest Booksy, gdzie niedawno przekroczyli 700 pracowników (ta liczba się zmienia tak szybko, że prawdopodobnie już teraz jest ich jeszcze więcej). Tam, Stefan Batory, CEO Booksy, mówił o tym, że on nie wyobraża sobie, żeby miał w zespole, przy tak dużej skali osoby, które mają archetyp takiej polskiej złotej rączki. To jest bardzo fajne na podstawowym poziomie, kiedy zaczynamy, natomiast na high-endzie, kiedy robimy największe technologie na świecie, chcemy mieć armię specjalistów najlepszych w swojej dziedzinie. To jest jedno spektrum. W przypadku tych kompetencji, które są wokół zespołu – to się świetnie sprawdza, kiedy te zespoły mamy małe, kiedy mamy zespoły, które dopiero zaczynają i wtedy wszyscy rozumieją. Natomiast podsumowując to wszystko – jakaś podstawa powinna być u każdego. Każdy przynajmniej raz w życiu powinien być na warsztatach z Design Thinkingu, przejść taki proces (opowiem wam też o tym, czym są warsztaty, jak wspaniałe jest to narzędzie do nauki), ale warto też dążyć do tego po drugiej stronie spektrum – żeby mieć takie perełki w naszych zespołach w tych kompetencjach, których potrzebujemy.

Gdy wspomniałeś o tej kompetencji, to tak sobie pomyślałem, że właśnie tym elementem, który cię wyróżnia mogłoby być – w przypadku zadania rekrutacyjnego – stworzenie prototypu, zanim zrobisz aplikację i wysłanie go do osoby, która zajmuje się tematem: słuchaj, zrobiłem prototyp, daj mi znać, czy to jest to, o co wam chodziło. I myślę, że to też będzie podejście inne od reszty, gdzie wszyscy po prostu robią zadanie i wysyłają je, zamiast zacząć od etapu wstępnego, który też w jakimś sensie pozwoli ci nawiązać kontakt z tą osobą, która potem będzie oceniać twoją pracę.

To, co zaproponowałeś to jest game changer w procesach rekrutacyjnych. I nie boję się tego powiedzieć: każdy, kto włoży coś ekstra, ekstra wartość do tego swojego procesu rekrutacyjnego, do zadania rekrutacyjnego albo podejdzie do tego totalnie out of the box, zrobi coś więcej niż przeciętna osoba, która chce się zrekrutować – na bank zostanie w pamięci rekrutera i jest bardzo duża szansa, że to właśnie was wybiorą, bo wy zrobiliście coś więcej, bo zadzwoniliście do pięciu klientów tej firmy i zapytaliście ich: hej słuchajcie, jakie macie problemy z korzystaniem z tego oprogramowania? Albo np.: co was denerwuje, kiedy występuje sytuacja X? Idziecie na taką rozmowę rekrutacyjną np. z waszym zadaniem albo bez waszego zadania: hej słuchajcie, wiem, że waszym celem jest polepszać usługi dla swoich klientów. Rozmawiałem z pięcioma waszymi klientami, wszyscy powiedzieli albo trzy czwarte powiedziało, że waszym problemem jest to i to, czy wy się z tym zmagacie? Czy pracujecie nad tym? Może się okazać, że oni nad tym pracują – świetnie, w takim razie ja jestem w stanie od razu wskoczyć do tego procesu, od razu nad nim pracować, bo ja przed rekrutacją wykonałem jakiś etap pracy, który mnie przybliży do tego, żeby wejść do waszej organizacji, żeby już wskoczyć i już zaczynać pracować nad rozwiązaniem tego problemu. To jest jedna z takich najbardziej wymarzonych sytuacji (jeśli mówimy o osobach, które szukają pracowników/członków zespołu), kiedy mamy osobę, która jest świetnie obeznana w branży, w której pracujemy, rozmawiała też z naszymi klientami. Jaki programista na co dzień myśli o tym, żeby porozmawiać z klientami? Wszyscy wy, którzy to robicie – totalny szacun i warto o tym opowiadać w waszych zespołach, że: hej, ja nie boję się zadzwonić do naszego klienta i zapytać go o to, co go denerwuje. To nie jest żadną ujmą, żeby tak zrobić. Prawdopodobnie klient bardzo się uśmiechnie i powie wam całą prawdę, która leży mu na sercu, bo jego interesem też jest to, żeby korzystać z waszego oprogramowania w sposób taki, który go uszczęśliwia, który upraszcza mu życie.

Gorzej, jeśli okaże się, że nasz PM albo ktoś odpowiedzialny nie będzie tak bardzo zadowolony, bo to on miał rozmawiać z tym klientem, a nie programista.

Na przykład – to też jest bardzo szeroki temat kultury organizacyjnej w polskich firmach IT.

Proponuję, żeby ci, którzy zrobili prototyp i dzięki niemu dostali pracę dali znać, czy to w komentarzu czy to napisali do mnie na maila – chętnie podzielę się z Adamem tą informacją i ciekawy jestem, czy będzie się sprawdzać.

Chciałbym cię teraz zapytać o to gdzie istnieje granica między prototypem a MVP, czyli taką podstawową wersją naszej działającej aplikacji, bo mówimy sobie o tych prototypach, ale w końcu trzeba zacząć pisać ten kod?

Kiedy zaczynacie proces rozwiązywania jakiegoś problemu, czy on jest duży, czy mały – ustalcie sobie na początku kryterium sukcesu: kiedy, albo lepsze pytanie: ilu naszych klientów (jaki procent klientów, ile ma ich być – czy to ma być pięćdziesiąt, czy sto, czy może trzech, może jeden, jak mamy jednego) ma nam powiedzieć, że ten prototyp, który my im daliśmy ich usatysfakcjonuje i zapytajcie siebie dodatkowo, w jakim stopniu ich usatysfakcjonował. Takie decyzje warto opierać o bardzo twarde dane, a nie o odczucia – czyli czterech na pięciu klientów, z którymi konfrontowaliśmy nasz prototyp, mówi, że to jest miodzio, że to jest rewelacja, że panie, gdzie to się da kupić? Wtedy macie bardzo jasny sygnał do tego, żeby to, co stworzyliście w prototypie dokładnie dopracować, żeby nie miało błędów, zakodować i stworzyć z tego MVP. I teraz to, co powiem jest bardzo niepopularne: wasze MVP i wasz potencjalny produkt też powinniście zapętlić w proces testowania. To się nigdy nie kończy. Nigdy nie ma tak, że jakieś rozwiązanie przez lata zostaje najlepsze na rynku. Firmy typu IBM i inne, które były królami lat jeszcze przed milenium, doskonale wiedzą o tym, co teraz mówię. Nokia kiedyś była jednym z kluczowych graczy na rynku, dzisiaj zajmuje jakieś marginalne stanowisko.

Tego przeskoku pomiędzy prototypem a MVP nie definiujecie wy – tzn. wy o nim nie decydujecie – decyduje tylko klient, tylko użytkownik. I to jest super metodyka, którą wam serdecznie polecam, bo nie zmarnujecie czasu na rzecz, której klient nie będzie chciał, bo wy już rozmawialiście z tym klientem, wy doskonale będziecie wiedzieć, co klient będzie chciał. Wracając do tych kryteriów – to jest dosyć trudne. Ja też w swoich projektach zmagam się z tym, że np. co jeśli klienci odpowiedzą nam 50/50 – połowa powie, że my to chcemy, że jest super, podoba się nam, a połowa powie, że jest to takie nice to have, że w sumie to jest OK, ale ja na to kasy nie wyłożę. Warto wtedy pogłębić te pytania: no to słuchaj, mój drogi kliencie, co bym musiał dodać tutaj? Albo najlepsze pytanie: gdybyś miał magiczną różdżkę i jednym pstryknięciem palca dodajesz jakąś funkcjonalność – jaką funkcjonalność byś tu dodał, żebyś za to zapłacił albo żebyś z tego korzystał, żeby dało ci to wartość? Jest to totalny game changer. I kiedy dodamy tę funkcjonalność, to wzrasta nam score zadowolenia z 50% do 60%, 70%, 75%. Jesteśmy jeszcze bardziej pewni tego, że powinniśmy iść w tę stronę.

Albo w drugą stronę: kiedy mamy bardzo zadowolonych użytkowników to możemy zapytać ich hej, słuchajcie, co sprawia, że wy jesteście tak zadowoleni? Gdybyście mogli wyrzucić całą resztę i zostawić tylko jedną rzecz w aplikacji, co by to było? Stefan Batory przekonał się o tym (dalej, powracam do Booksy). Kiedy mieli już zamykać Booksy i doszło do takiej sytuacji, że firma miała problemy, to jednym z game changerów (a mieli ich dwa) było to, że jedna z klientek napisała takiego maila, w którym powiedziała o tym, że Marketplace to mnie w ogóle nie obchodzi, ale ten kalendarz – ja nie wyobrażam sobie, żeby miało go zabraknąć. Nie wyobrażam sobie już pracy bez tego kalendarza. I to się okazał game changer, który sprawił, że dzisiaj Booksy jest tu, gdzie jest. Podsumowując temat przejścia pomiędzy prototypem a MVP: nie decydujecie wy, tylko decyduje wasz klient i miara, którą sobie na początku ustalicie. Nie ma nic złego w powrocie do samego początku. To, że my to uznajemy za porażkę – taka jest już nasza natura, bo my zakochujemy się w naszych decyzjach. Nie ma totalnie nic złego w tym, żeby wrócić do samego początku, bo jesteście wtedy bogatsi o te wszystkie doświadczenia, które zdobyliście w tym procesie.

To teraz mam przygotowane pytanie, na które już odpowiedziałeś. A chodzi mi o to, czy możesz przedstawić przypadek, w którym szybkie prototypowanie było kluczowe w dowiezieniu projektu. Wspominałeś o tym hackathonie – czy chciałbyś tutaj coś jeszcze dodać, czy idziemy z kolejnym pytaniem?

To nie tylko musi być hackathon. Zauważcie, że taka sytuacja, kiedy macie bardzo ograniczony czas w swojej pracy może się powtarzać co tydzień, dwa, trzy. Tak jak wcześniej wspomniałem, kto nie zna PM-a, który powiedział, że słuchaj, to musi być do wtorku i musimy to mieć. Wtedy ten proces odgrywa kluczową rolę, bo wy chcecie zmaksymalizować to, jak bardzo zadowolony będzie wasz szef, PM, wasz użytkownik, więc dlaczego by tego nie ułatwić takim procesem, nauczyć się go, wytestować (o tym, jak się uczyć, opowiem wam na końcu i polecę kilka źródeł). Totalnie chcecie mieć tę umiejętność w swoim zespole, w swojej kieszeni i wykorzystywać ją na każdym etapie pracy.

Dobrze, to teraz czas na jakieś rady dla osób, które dopiero zaczynają swoją przygodę z prototypowaniem.

Mogę się powtórzyć, ale top 1 najczęściej popełnianych błędów to jest zakochanie się w swoim rozwiązaniu – chodzi tu o to, że my poklaskujemy swoim pomysłom i przybijamy sobie taki high five w głowie: hej, super, wymyśliłem coś wspaniałego, to zmieni świat, zrewolucjonizuje naszą branżę. Osobom, które często popadają w takie samouwielbienie swojego pomysłu (mi też bardzo często zdarza się to robić) mogę doradzić ustalenie w zespole, ze swoim co-founderem, zaprzyjaźnioną/zaufaną osobą, żeby wylewała na was np. kubeł zimnej wody, żeby sprowadzała was na ziemię i żebyście wracali do tych podstawowych założeń, które sobie założyliście: ilu klientów musi powiedzieć, że ich to satysfakcjonuje, żebyśmy przeszli dalej? Jeżeli nie spełnicie tej miary, to naprawdę nic się nie dzieje. Porażka – nieudany eksperyment – nie powinna być w ogóle traktowana jako porażka. To jest wartość dla was. Podsumowując ten podstawowy błąd: zwróćcie uwagę na to, jakie kryteria założyliście sobie na początku, żeby ten sukces osiągnąć i po prostu się ich trzymajcie. Podejdźcie do tego troszeczkę na chłodno, nie przywiązując emocji, a bardziej patrząc na to jako cel do spełnienia: a może tym razem znajdę narzędzie, które spełni ten cel, które zrobi ten wytrych, które otworzy te drzwi, czyli na przykład 75% zadowolonych użytkowników, z którymi rozmawialiśmy?

To może tylko dodam od siebie, żeby osoby, które nas słuchają sprawdziły, za którym razem została wynaleziona żarówka. To może też im to troszkę poprawi humor.

Tak, myślę, że to jest gigantyczny problem szczególnie wśród start-upowców, wszystkich PM-ów, product ownerów, ale też programistów. Popatrzcie np. na Netflixa − kiedy Netflix startował, to była wypożyczalnia płyt CD, kaset. Te filmy były na początku wysyłane do swoich użytkowników za pomocą poczty. Dzisiaj Netflix jest jedną z największych platform VOD na świecie i zarabia pewnie jakieś gigantyczne miliardy dolarów dla swoich akcjonariuszy i nie tylko.

Właśnie zastanawiam się, czy zarabia, czy są na plusie? Nie sprawdzałem ostatnio i nie wiem, ale zastanawiam się, czy oni ciągle nie są pod kreską podsumowując całość?

Wchodzisz teraz w temat tego, jak zarządzać finansami w bardzo dużych spółkach i to prawda. Tu w ramach ciekawostki możecie spojrzeć na całą masę start-upów, które świetnie się rozwijają, które super idą do przodu, rozwijają produkty, a np. od 10-15 lat są pod kreską. To nie znaczy, że oni są bankrutami. Po prostu w pewnych strategiach rynkowych opłaca się trzymać tego poziomu zero zysku albo zysku bardzo małego z bardzo prostych przyczyn – maksymalizowania i jeszcze szybszego rozwoju.

To już jedno z ostatnich pytań, może najciekawsze: jakie nowe technologie lub narzędzia mogą twoim zdaniem zrewolucjonizować proces tworzenia prototypów w najbliższych latach? Oczywiście mam tu też na myśli AI.

Super pytanie, bo de facto tym tematem jestem teraz najbardziej zaciekawiony – słucham całej masy podcastów. Jak wpiszecie sobie jakiekolwiek zagraniczne podcasty np. Lenny’s Podcast albo podcasty polskie jak np. podcast Interesy Bartka Majewskiego bądź podcasty innych osób, które zajmują się takimi nowinkami technologicznymi np. Michała Sadowskiego – widzicie tam jeden wielki trend, że przyszłość AI-a to są AI Agenty i to jest jedna z niesamowitych rzeczy dlatego, że AI Agent to jest pewnego rodzaju sztuczna inteligencja, to de facto jest sztuczna inteligencja, która jest mega wyspecjalizowana na jakiś obszar, na rozwiązywanie jakiegoś problemu i dzisiaj rynek pokazuje, że ChatGPT super się rozwija, ale nie bez powodu oni inwestują w GPTs – w małe agenty, które rozwiązują jakieś problemy dlatego, że tworzenie produktów do wszystkiego mija się z celem. Bardziej opłaca się stworzyć produkt bardzo wyspecjalizowany, np. taki AI Agent do tworzenia stron internetowych, do programowania w Pythonie, do rzeczy nie tylko programowych.

Mamy też całą masę AI Agentów, które zajmują się analizą danych. Wychodzą nawet poza Generative AI, czyli np. cały segment Computer vision (wizji komputerowej). To, że tło za mną się bluruje jest pewnego rodzaju sztuczną inteligencją, bo AI stara się mnie wyciągnąć z tego całego obrazu i nadać blur. Tego rodzaju rozwiązania, połączone ze sobą i wyspecjalizowane, tworzą AI Agenty.

Jednym z najpopularniejszych projektów, które są teraz w świecie IT – ukochane dla tych, którzy korzystają – jest Copilot (mówię tu o Copilocie GitHubowym, wiem, że Amazon ma swojego, jest też kilka innych rozwiązań, a ten GitHubowy jest teraz mam wrażenie najpopularniejszy na rynku), który szczyci się gigantycznymi osiągnięciami: napiszesz kod kilka razy albo ileś procent szybciej, będzie on miał ileś razy mniej błędów – przyśpieszysz ten cały proces. To są jedne z takich kluczowych dźwigni, które się pojawiają i zaczną się pojawiać na rynku, tak że w trakcie procesu tworzenia zacznie się okazywać, że warto użyć np. rozwiązania, które nam zbuduje całą architekturę aplikacji poprzez jakiegoś agenta, który to zaprojektuje. My, jako człowiek to sprawdzimy, podejmiemy jakieś decyzje, korekty, a następnie cała masa agentów od tych technologii np. specjalny agent od Next.js-a, Reacta, frameworków backendowych zrobi nam aplikację.

To jest niesamowity trend, któremu warto się przyglądać. Warto też zwrócić uwagę, jak bardzo długoterminowo patrzymy. Może warto się uczyć je kodować – to na pewno. Listy karier do firm, które zajmują się AI Agentami, są cały czas otwarte. Jest np. taki start-up WorldWare, ostatnio jeden z najbardziej wyhypowanych i rozgrzanych do czerwoności start-upów. Byli oni numerem jeden na Produkt Hunt’cie, są też w Y Combinatorze. Y Combinator to jest najpopularniejszy, gigantyczny światowy akcelerator start-upów i technologii i tam listy karier i listy osób, których potrzebują do załogi są otwarte. To samo Proofs, start-up, w który jest zaangażowany Bartek Pucek. To jest start-up, który ma tworzyć armie AI Agentów do tworzenia aplikacji i rozwiązań dla twoich API, które są od razu Go-To-Market. Wyobraźcie sobie, że macie jakiś stan magazynowy, macie w nim API i jednym promptem: hej stary, zbuduj mi sklep e-commerce na podstawie mojego stanu magazynowego i wyszczególnij te wszystkie produkty, na których mam największą marżę. Dzisiaj tworzą się rozwiązania na świecie, które mają takim problemom sprostać i takie zadanie, które programiści/analitycy/wszyscy specjaliści UI/UX robiliby przez x określonego czasu, takie agenty mogą bardzo szybko sprototypować (bo to też nie jest idealne rozwiązanie na ten moment).

Podpytam cię o takiego agenta np. w Figmie – nie korzystałem z niego – co on jest w stanie zrobić na ten moment? Korzystając np. z no-codu typu make.com, przez prompt jesteś w stanie napisać, że chcesz np. prompt do pobierania danych z jakiegoś API − on ci faktycznie stworzy te kafelki i coś tam się dzieje. Czy tutaj wygląda to podobnie?

Moim zdaniem branża no-code i low-code zostanie poddana gigantycznej próbie. Chodzi tutaj o to, że dzisiaj rzeczywiście możesz wyklikać coś w no-code/low-code, napisać sobie prompt – świetnie ci połączy jakieś API, zbuduje ci jakąś prostą automatyzację itd. – to jest całkiem spoko. Natomiast po drugiej stronie masz zwykłego ChatGPT, wersję 4o albo 4o mini, która napisze ci skrypt w Pythonie, która ci jeszcze nawet uruchomi ten skrypt i wypluje ci rozwiązanie, albo jak będziesz chciał je często powtarzać, to wrzucisz je sobie copy-pastem do swojej chmury, którą uruchomisz za pstryknięciem palców. Tutaj stawiam bardzo śmiałą tezę, że AI Agenty wyprzedzą już istniejące rozwiązania no-code, więc ta branża albo się zrestrukturyzuje, albo dojdą tam nowe zmiany technologiczne dotyczące tego, w jaki sposób użytkownicy mieliby pracować z tymi agentami, albo w jaki sposób miałoby to działać, bo przy aktualnej prognozie − gdy dzisiaj Proofs pokazuje, że ich narzędzie jest w stanie zbudować cały e-commerce na pstryknięcie palców − AI Agenty wyprzedzą, make'a, Zapiera i wszystkie inne no-code'owe toole.

To ciekawe − będę musiał chyba nagrać inny odcinek na temat tego, jaka jest przyszłość no-code'u i low-code'u.

I to nie jest tak, że to jest w jakimś Webflow, czy Framer'erze, czy w Shopify'u – w repozytorium na GitHub'ie jest normalnie kod, z dokumentacją, z napisanymi testami przetestowanymi. To jest przerażające.

Może się okazać, że programiści już będą tylko wdrażać małe popraweczki.

Jest taka bardzo popularna wypowiedź CEO Nvidia, który powiedział na jednej z konferencji, że programiści stracą pracę przez to, że wyprzedzi ich sztuczna inteligencja. Bardzo śmiała teza.

Może tylko zdementuję i powiem tylko tyle, że trzeba też pomyśleć, dlaczego tak mówi – ile on na tym zarabia?

Myślę, że świat w tym zakresie nie jest czarno-biały i oczywiście programiści z dnia na dzień nie zostaną wyrzuceni, ale kryzys, który mamy dzisiaj przez to, że wiele osób ma problem z dostaniem się do pracy, czy ze zmianą pracy pokazuje, że nie tylko umiejętność programowania jest tym wszystkim najważniejsza – budujcie twarde i miękkie kompetencje wokół całego ekosystemu tworzenia produktów cyfrowych i rozwiązywania problemów, bo dzięki temu zagwarantujecie sobie miejsca w najlepszych firmach, w których będziecie chcieli się znaleźć, będziecie uczestniczyli w transformacji technologicznej, która teraz trwa i po prostu nie wyprzedzi was syn koleżanki waszej mamy.

Dobrze, to już zakończmy ten temat. Tak na podsumowanie – jaką książkę polecisz osobie, która chce zgłębić temat prototypowania?

Ja nie lubię książek o prototypowaniu. Prototypowanie to pewnego rodzaju umiejętność, która jest trochę na skraju umiejętności twardych i miękkich – mogę wam powiedzieć o tym, jak ja i wielu moich przyjaciół, znajomych pozyskało tę umiejętność. Są tutaj dwie rzeczy. Jedna to jest edukacja, która w dzisiejszych czasach jest bardzo przystępna na YouTubie, na jakichś źródłach jak medium.com czy np. jest takie super narzędzie jak Substack, w którym czytacie newsletter ludzi z zagranicy i z Polski − skierowałbym tam waszą uwagę. Zamiast wydawać czterdzieści parę czy sześćdziesiąt złotych na książkę, zwróćcie uwagę na te darmowe źródła, które już tam są, które opisują w jaki sposób ci ludzie prototypują. Nie spędzajcie też jakiejś masy gigantycznych godzin na samym czytaniu, tylko połączcie to czytanie i oglądanie np. TEDx-ów, materiałów ze Stanforda, z Harvard Business School z praktyką.

I teraz mogę wam dać najlepszą rekomendację, jaką dałbym sobie na początku: jeździjcie na hackathony. To jest jeden z najlepszych w ogóle sposobów, który kompleksowo da wam wiedzę branżową. Do tego nawiążecie kontakty z osobami, które są z branży, takimi jak wy, z waszymi przyszłymi przyjaciółmi, kolegami, z którymi możecie mieć świetne relacje, gdzie nauczycie się tego, czego chcielibyście się nauczyć, tych kompetencji, które dadzą wam najlepsze stanowiska pracy w firmach, w których chcecie, a na koniec jeszcze możecie wygrać jakąś fajną nagrodę i pochwalić się super tytułem.

Na koniec tego podcastu podsumowując – gdybym dzisiaj miał się uczyć prototypować i programować od zera to na pewno: czytałbym, oglądał materiały na ten temat, do tego miałbym pewnego rodzaju praktykę, czyli hackathony, swoje projekty. Jest jednak jeszcze jedna rzecz, której nam w tej rozmowie zabrakło, czyli czerpanie z doświadczenia innych poprzez zwykłe rozmowy. Nie ma nic bardziej prostego, niż po prostu zapytać się kolegi z branży, zadzwonić do niego albo poznać go na Facebooku czy na LinkedInie i zapytać się hej, siema stary – słuchaj, bo ja w sumie to bym bardzo chciał zacząć w tej branży, ale boję się i wiesz, powiedz mi kilka rzeczy, jak to wygląda od środka. Za taką wiadomość jeszcze nikomu głowa nie została ucięta, a z takich wiadomości rodzą się naprawdę wspaniałe rozmowy i kto wie, czy przyjaźnie i przyszłość w jakichś fajnych firmach.

Tak jest – dobrze, że wywołałeś ten temat. Zanim jeszcze powiem to, co chcę powiedzieć, to tylko wspomnę, że w tamtym roku nagrałem odcinek na temat hackathonów. Tam możecie dowiedzieć się więcej o tym, jak to wygląda i czy w ogóle warto.

A jeśli już wywołałeś temat zapytania kogoś, to jeżeli ktoś ze słuchaczy naszego podcastu chciałby zapytać cię o jakieś tematy, to w jaki sposób może to zrobić? Gdzie możemy cię znaleźć w sieci?

Najprościej – wystarczy, że wpiszecie Adam Majcher na LinkedInie, od razu wam wyskoczę. Na Facebooku też jestem, pewnie tam jakoś rzadziej wam będę mógł odpisać. Najprościej jest odezwać się do mnie na LinkedInie – tam też w zakładce Spotkaj się ze mną, macie link do spotkania ze mną. Każdemu, kto chciałby porozmawiać totalnie na osobności czy podzielić się jakimiś swoimi przeżyciami albo zapytać o radę, jeżeli jakkolwiek uważacie moje doświadczenie za wartościowe dla was, to zapraszam. Dla mnie to jest totalnie spoko i te drzwi stoją przed wami otworem.

A może po prostu zapytajcie też Adama, gdzie w najbliższym czasie wybiera się na hackathon, to będziecie mieli okazję się spotkać na żywo.

Dokładnie, tak. Te plany są dosyć odległe, aczkolwiek takie dwa hackathony, na których najczęściej mnie zobaczycie w Polsce, to jest HackYeah w Krakowie. Wydaje mi się, że rozmawiałeś z jedną z organizatorek HackYeah?

Tak jest, potwierdzam.

Tak, on jest na Tauron Arenie. A drugi hackathon to jest mój ukochany NASA Space Apps, który jest w różnych lokalizacjach w Polsce i na świecie.

Super. Adamie, bardzo dziękuję za tę rozmowę i podzielenie się z nami swoimi doświadczeniami.

Ja też wam bardzo dziękuję. Pamiętajcie – chwytajcie marzenia i uczcie się prototypować. Na razie, cześć.

Dzięki, cześć.