.svg)
00:27 - Wstęp
00:47 - Czego potrzebujemy?
06:25 - Jak się przygotować?
10:08 - Kto bierze udział?
17:18 - Proces
22:57 - Podsumowanie
Witam was w kolejnym odcinku naszego podcastu Just No Code.
W tym odcinku opowiemy o tym, jak wygląda proces tworzenia aplikacji, jak się można do niego przygotować oraz jak de facto dokładnie to wygląda po naszej stronie. Więc nie przedłużając, zapraszam was do kolejnego odcinka.
Zaczynając, chciałbym wam powiedzieć, czego my... jako Software House, który będzie tworzył Waszą aplikację, czego my tak naprawdę od Was potrzebujemy. Bo to też nie jest tak, że Wy po prostu do nas przychodzicie z wymaganiami spisanymi na białej kartce A4, mówicie... wycencie to my to wyceniamy i w tym momencie robimy aplikację. Totalnie to tak nie działa.
W tym momencie byśmy byli po prostu jakimiś klepaczami kodu czy coś takiego, a nie de facto pomagali wam osiągnąć sukces czy zbudować aplikację, która po prostu będzie działać. Bardzo często też jest tak, że de facto wy jako nasi klienci też do końca nie wiecie... czego potrzeba, jak ten proces wygląda, bo po prostu nie macie tych technicznych kompetencji po swojej stronie.
Wiecie czego potrzebujecie od strony biznesowej, wiecie jaki efekt chcecie osiągnąć i dlaczego chcecie to zrobić, no ale nie wiecie czy lepsze będzie rozwiązanie A czy B, technologia X czy technologia Y. I od tego właśnie jesteśmy my, żeby wam... pomóc.
De facto jesteśmy też tutaj od tego, żeby powiedzieć wam ile de facto może to zająć czasu, ile może mniej więcej, i tutaj podkreślam podwójnie, mniej więcej kostować z tego względu, że nigdy nie jesteśmy w stanie przewidzieć wszystkiego co w aplikacji będzie się działo, jak dokładnie będzie to funkcjonowało, wyglądało i tak dalej. Wy też nie.
Chyba, że mówimy o takiej, wiecie, naprawdę maluteńkiej, maluteńkiej... tyci, tyci aplikacji, ale to nie na tym polega i nie tak to dokładnie wygląda. Więc czego my de facto potrzebujemy? No na początku potrzebujemy dostać od Was jakąś listę funkcjonalności, tego co chcecie zrealizować, tego jaki ma być tego efekt, jaki de facto ta aplikacja ma spełniać cel.
Dalej na pewno potrzebujemy stakeholdersów, to znaczy osoby jednej wyznaczonej po waszej stronie, która będzie powiedzmy taką osobą, która będzie dawała ostateczne zdanie. To nie znaczy, że po waszej stronie nie może być zespołu. Zespół po waszej stronie prawdopodobnie powinien być, prawdopodobnie musi też być do tego, żebyśmy mogli rozmawiać o tym co budujemy, jak ma to wyglądać itd. ale musi być wyznaczona jedna osoba decyzyjna.
Następną rzeczą, której będziemy od was potrzebowali to wiedza. Tą wiedzę oczywiście my na kilka różnych sposobów będziemy chcieli od was pozyskiwać. O tym jak ten proces wygląda opowiem odrobinkę później. Natomiast dzięki temu, dzięki tej wiedzy my będziemy wiedzieli co de facto mamy zbudować. Pamiętajcie, my znamy się na... naszej branży, wy znacie się na swojej. My wiemy jak budować aplikację. Wy wiecie dlaczego tą aplikację chcecie zbudować i co w niej ma być wartością.
I to się jakby skupia w jeden taki powiedzmy zbiorczy, duży element, te wszystkie elementy są ze sobą połączone w to, czego my od was potrzebujemy. No i jak się z tego przygotować? No oczywiście warto, żebyście mieli dobrze przegadane to, co chcecie zbudować, żeby to nie była taka wiecie tylko koncepcja chciałbym x, bo to jest dużo za mało wiecie.
Na podstawie tego, że chciałbym mieć funkcję zarządzania użytkownikami, możemy wam powiedzieć, że zajmie development tego tydzień albo 10 tygodni, bo zarządzanie użytkownikami może znaczyć, że chcecie mieć listę użytkowników, na której możecie dodawać kolejnych. A zarządzanie użytkownikami może znaczyć, że chcecie móc użytkowników blokować, edytować, usuwać, dodawać, podglądać, może chcecie dodawać im kolejne rzeczy, móc zarządzać ich dokumentami, sprawdzać raporty na temat tych użytkowników itd. Więc jeżeli definiujecie jakąś funkcjonalność, to musimy mieć jakiś minimalny opis, żeby po prostu wiedzieć co ona znaczy.
Więc żeby się przygotować, musicie to po swojej stronie de facto zrewaluować, przegadać zespołowo czego potrzebujecie i tutaj jedna bardzo ważna uwaga musimy oddzielić "chce mi się", "wydaje mi się", "chciałbym" od tego "co muszę mieć". Już pewnie niejednokrotnie rozmawialiśmy i na pewno też jeszcze niejednokrotnie będziemy rozmawiali, że na początku zbudujmy coś co daje tylko i wyłącznie mega wartość użytkownikom.
To znaczy, że oczywiście możemy mieć bardzo wiele funkcjonalności w naszej aplikacji, nieskończenie długą listę, ale musimy sobie zadać pytanie, czy rzeczywiście tych funkcjonalności potrzebujemy na początku. My bardzo zawsze zachęcamy naszych klientów do tego, aby budować minimalne rozwiązanie, które w minimalnym stopniu spełnia swoją wartość, które dostarcza tą wartość, które w minimalnym stopniu spełnia swoją funkcjonalność. Dzięki temu po prostu wydacie dużo mniej, spędzicie dużo mniej czasu na tym, na budowie pierwszej wersji produktu, żeby po prostu ten produkt zwalidować w momencie kiedy nabierzecie trakty, zobaczycie, że ma to ręce i nogi, spodoba się to wam.
Jedną z najważniejszych osób jest projekt manager. Projekt manager to osoba, która de facto, powiem trochę żartobliwie, będzie nas i was kopać w tyłek, wtedy kiedy nam czegoś nie dostarczycie lub wtedy kiedy my nie dostarczymy czegoś wam. Projekt manager to osoba, która będzie też zbierała od was wymagania, dokumentacje, ganiała was, jeżeli nie będziemy dostawali od was odpowiedzi, będzie zadawała wam pytania, będzie z wami rozmawiała.
Projekt Manager po prostu pilnuje też całego procesu tworzenia, zbierania informacji, żeby ten proces szedł sprawnie, żeby szedł szybko, żeby ta wymiana informacji między nami a wami była skuteczna, precyzyjna i żeby dla każdego było jasne co de facto w danym momencie się dzieje i co de facto robimy. Bardzo istotna rola, która de facto pilnuje bardzo wielu rzeczy.
Następne osoby to są oczywiście designerzy, osoby, które będą pracowały nad tym, jak de facto nasze rozwiązanie ma wyglądać. Prawdopodobnie nie zawsze, ale przeważnie mamy jakieś wymagania co do tego, jak nasze rozwiązanie, jak nasza aplikacja ma wyglądać, jak ma funkcjonować. To są też osoby, które są w stanie powiedzieć, "hej, ten przycisk tutaj sprawdza się słabo, lepiej go umieścić tutaj". Oczywiście tutaj wchodzimy trochę w UX, UI, rozdzielanie teraz tego na te dwie role nie ma na tym etapie znaczenia. Chodzi o to, że jesteśmy w stanie powiedzieć Wam, zasugerować jak coś powinno wyglądać, albo że powinno wyglądać, czy funkcjonować inaczej. Są niezbędne, bardzo głębokie analizy dotyczące UX-u, też jesteśmy w stanie to zrobić, czy posłużyć się kompetencjami firm trzeci, które się po prostu w tym specjalizują, ale to jest oczywiście osobny temat. Tedy taka firma czy takie osoby są po prostu wplatane w cały ten proces tworzenia tych pierwszych frame'ów, tych pierwszych obrazków, tych pierwszych screen'ów, tego jak nasza aplikacja będzie wyglądała.
Następnie mamy devów. Devowie oczywiście to są osoby, które będą tworzyły to rozwiązanie. One będą przekładały waszą wiedzę zebraną przez naszego PM-a i desajny dostarczone przez naszych designerów w to, co już będzie tym żywym produktem, coś co będzie klikalne. Oni będą się zastanawiali nad tym, jak powinna wyglądać struktura bazy danych, jak powinny płynąć workflowy, jak to wszystko po kolei będzie funkcjonowało, to oni będą dostarczali. I oczywiście oni też tak samo jak designerzy będą brali udział w naszych spotkaniach po to żeby z wami rozmawiać, żeby zadawać wam pytania żeby pytać o edge-cases, żeby pytać jak myślicie żeby sugerować pewne rozwiązania no bo tak jak mówiłem już wcześniej rozwiązanie należy do was. My tylko sugerujemy, my podpowiadamy, my realizujemy, ale to wy jesteście ownerami i to od was musimy mieć zawsze ostateczne zdanie. Oczywiście tam gdzie wy nie jesteście w stanie go podjąć, to na nas potrzeba taka odpowiedzialność, to my takie zdanie również podejmiemy.
I last but not least QA inżynierzy, czyli testerzy. Są to osoby manualnie lub automatyzujące testy w zależności od tego jak dużym rozwiązaniem mamy do czynienia, czy to jest też już faza maintenance'u, czy to jest faza budowy pierwszej wersji aplikacji, no to są zaangażowani oczywiście testerzy. Testerzy, którzy mają za zadanie zadbać o to, aby aplikacja była wolna od wad. I tutaj jedna bardzo ważna uwaga, aplikacja nigdy nie jest w 100% wolna od wad. Do dzisiaj Facebook, Twitter, Google mają przyciskę "Report a Bug", ponieważ nie zawsze pomyślimy o wszystkich edge-cases, czyli takich skrajnych przypadkach użycia naszych aplikacji, gdzie coś po prostu może nie do końca zadziałać. No i od tego są oczywiście nasi testerzy, żeby próbować wyłapać takie rzeczy, żeby upewnić się, że nie ma takich oczywistych błędów czy wpadek w działaniu aplikacji. No ale to też oczywiście nie zwalnia was od testów akceptacyjnych. I o tym też musicie pamiętać. Nasi testerzy odpowiadają za Quality Assurance. QA to jest skrót od Quality Assurance, czyli od zapewnienia tego, że produkt stoi na odpowiednio wysokiej jakości. Wiadomo, błąd w każdym oprogramowaniu czasami może się zdarzyć. Jakieś skrajne przypadki również, ale zaświadczamy o tym, że nasze oprogramowanie stoi na odpowiednio wysokiej jakości, spełnia odpowiedni performance, spełnia odpowiednie wskaźniki tego, że jest używalny i użytkownik spokojnie za każdym razem powinien móc przejść swój proces. Natomiast tak jak mówiłem nie zwalnia to was od testów akceptacyjnych, bo testy akceptacyjne są czymś takim, że my dajemy aplikację wam do tego abyście ją sobie przeklikali, zobaczyli jak ona de facto działa i powiedzieli czy wszystko jest tak jak sobie to wyobrażaliście.
No i jak de facto wygląda sam proces już tworzenia tej aplikacji. Wiemy kto bierze udział w tym procesie, wiemy jak się do niego przygotować, wiemy jak wygląda sama estymacja projektu. Więc co się dzieje, kiedy już mówimy sobie nawzajem, OK, startujemy, zaczynamy realizować ten projekt. No my zawsze zaczynamy od takiego pięciokrokowego warsztatu. Pięciokrokowego warsztatu, który polega na tym, że spotykamy się razem, wiemy oczywiście już mniej więcej gdzieś tam, co chcecie budować, ale my chcemy sobie pewnej informacji doprecyzować. Tak jak każdej platformie, każdej aplikacji, którą budujemy, jedne rzeczy są dla nas bardziej jasne, inne rzeczy są dla nas mniej jasne. I to właśnie o tym mniej jasne chcemy dopytać, chcemy zobaczyć, rozpisać sobie to, jak to będzie funkcjonowało. Może zbudować jakieś pierwsze ścieżki użytkowników, zobaczyć po prostu jak będzie wyglądał ten cały proces, zderzyć to z wami, zapytać, żebyśmy mieli pewność, że jesteśmy on the same page. Zamyślimy o tym rozwiązaniu tak samo, żeby nie było po prostu jakichś nieporozumień, żeby mieć pewność, że coś co będziemy budowali będzie odpowiadało waszym potrzebom. Kiedy już zrobimy sobie te warsztaty, bo znowu to jest bardzo ważna uwaga, warsztaty nie polegają na tym, że my spiszemy każdą najdrobniejszą rzecz, każdy najdrobniejszy szczegół, ponieważ musielibyśmy na tych warsztatach spędzić pewnie pół roku, a i tak nadal byśmy nic nie wiedzieli, bo w międzyczasie wiele rzeczy by się zmieniło. Warsztaty mają nam rozjaśnić rzeczy do tego stopnia, że mniej więcej wiemy co mamy zbudować.
Zaczynamy rozrysowywać te rzeczy, co jest bardzo ważne, ponieważ jeszcze nie zaczynamy ich budować. Na początku zaczynamy je rozrysowywać, a zaczynamy je rozrysowywać z tego względu, że czym innym jest nasza wyobraźnia, czym innym są rzeczy, które zobaczymy po raz pierwszy, a czym innym są jeszcze rzeczy, które pierwszy raz dotkniemy. Dlatego najpierw rozmawiamy o wyobrażeniach, o teorii, później tę teorię przekuwamy w jakiś obrazek. I tutaj właśnie nad tym już pochylają się designerzy. Budują jakieś pierwsze, nie wszystkie znowu, bo to znowu byłaby strata czasu, ale budują pierwsze obrazki waszej aplikacji, jak ona może wyglądać, jaka będzie identyfikacja graficzna, jak to będzie wyglądało. Zderzamy to z wami, żebyście zobaczyli, dotknęli, wtedy znowu pojawiają się jakieś uwagi, co do tego, jak to może wyglądać, jak to może funkcjonować.
I dopiero kiedy mamy zatwierdzone te pierwsze warsztaty, te pierwsze rzeczy, jak one będą wyglądały, to dopiero wtedy przechodzimy de facto do developmentu. No i tutaj sobie dewelopujemy tą naszą aplikację w momencie kiedy już jakiś pierwszy moduł, pierwsza funkcjonalność jest zbudowana dajemy ją wam do przeklikania właśnie po to, żebyście przeklikali i przekonali się czy proces, który zbudowaliśmy de facto odpowiada temu co sobie wyobrażaliście. A jeżeli odpowiada temu co sobie wyobrażaliście, to czy rzeczywiście rzeczywistość jest zgodna z waszymi wyobrażeniami.
Po prostu dajemy Wam tak najszybciej do przeklikania, żebyście mogli już na bardzo wczesnym etapie zgłaszać te poprawki, żebyśmy my znowu nie wydłużali albo nie wracali do rzeczy, które już dawno temu zamknęliśmy po naszej stronie. To żeby do nich nie wracać, nie rozkopywać tylko budować moduł po module, jak właśnie z kroków LEGO. Na końcu oczywiście robimy takie testy do zamknięcia, żeby przekazać wam aplikacje do testów akceptacyjnych i w momencie, kiedy aplikacja już przejdzie testy akceptacyjne, możemy wyjść live z naszą aplikacją.
Oczywiście to nie znaczy, że to jest już koniec całego developmentu, no bo jeżeli chcemy dalej aplikację rozwijać, ona wyszła live, wyszła ta jej pierwsza wersja, tej aplikacji, spotykanie się, zbieranie od was wymagań, zbieranie wiedzy na temat tego, co ma powstać, jak ma to wyglądać i dodawanie tych kolejnych rzeczy, czy tworzenie nawet dokumentacji. Bo też musicie pamiętać o tym, że na każdym z tych etapów powstaje też jakaś dokumentacja dotycząca designów, dotycząca test case'ów, dotycząca tego, jak zbudowaliśmy dane funkcjonalności, czy dane algorytmy, jeżeli jest taki wymóg.
My w havenocode działamy tak, że Wy na każdym etapie macie dostęp do naszej tablicy zadań, do naszego czasu, do naszej dokumentacji, bo to wy jesteście, tak jak już mówiłem, bardzo ważną częścią tego procesu. I my razem tworzymy jeden zespół. To nie jest tak, że my stoimy w opozycji do was i jesteśmy waszymi podwykonawcami. Nie. My stawiamy na to, że jesteśmy jednym zespołem, działamy bardzo transparentnie, komunikujemy wszystko, nad wszystkim razem działamy. Macie swoje tablice w naszym systemie, gdzie możecie zgłaszać różne rzeczy, modyfikacje. Wymieniamy się dokumentacją, wymieniamy się wiedzą, wymieniamy się zdaniami po to, aby właśnie zbudować aplikację, która będzie aplikacją waszą, zbudowaną razem z nami, naszymi rękoma. Nie tak, że my jesteśmy zamawiającym, wy jesteście zamawiającym, my wykonującym – oczywiście z formalnego punktu widzenia tak, ale nie tak chcemy działać, nie tak chcemy, żeby to wyglądało.
Nasz proces ma za zadanie być po prostu transparentnym, tak abyście wiedzieli na każdym etapie, jak powstaje wasza aplikacja, co się dokładnie dzieje, na jakim jesteśmy etapie, gdzie mamy ewentualne trudności, a gdzie na przykład udało nam się przyśpieszyć. Więc jak widzicie, mam nadzieję, że ten proces w całości jest dla was jasny. Jak on powstaje, co jest nam niezbędne, kto w nim bierze udział oraz jak się do niego po prostu przygotować.
To tyle dzisiaj ode mnie. Dziękuję wam bardzo. Do zobaczenia w kolejnym odcinku. Żegnajcie!
Podcast No-Code / Low-Code to podcast o technologii, w którym opowiadamy o digitalizacji, automatyzacji i tworzeniu stron, budowaniu aplikacji oraz platform internetowych. Poznasz wady i zalety low code i no code oraz zrozumiesz podstawy tych narzędzi. W odcinkach podcastu eksperci firmy havenocode poruszają także tematy biznesowe, wskazują najlepsze platformy low code i najlepsze platformy no code.
Dowiedz się jak korzystać z platform no-code i low-code, takich jak: Bubble.io, Xano, Webflow, Flutter Flow, AppSheet czy Zapier. Naucz się tworzyć aplikacje bez kodowania. Poszerz swoją wiedzę i zostań citizen developerem. Sprawdź, jak rozwija się branża low code i no code w Polsce i na świecie. Słuchaj i oglądaj podcast Just No Code!
