Wyobra\u017a sobie tak\u0105 sytuacj\u0119: stoisz w kuchni, r\u0119ce masz umazane m\u0105k\u0105 i gor\u0105czkowo przeszukujesz szuflad\u0119 w poszukiwaniu po\u017c\u00f3\u0142k\u0142ej kartki z przepisem na popisowe ciasto Twojej babci. Kartki nie ma. Znowu. W Twojej g\u0142owie rodzi si\u0119 genialna my\u015bl: „A gdyby tak stworzy\u0107 aplikacj\u0119 – cyfrow\u0105 ksi\u0105\u017ck\u0119 kucharsk\u0105, w kt\u00f3rej mia\u0142bym wszystkie przepisy pod r\u0119k\u0105, a na dodatek robi\u0105c zdj\u0119cie produkt\u00f3w z lod\u00f3wki AI samo generowa\u0142oby nowe przepisy, do kt\u00f3rych posiadasz wszystkie sk\u0142adniki?\u201d.<\/p>\n\n\n\n
Gratulacje, w\u0142a\u015bnie wpad\u0142e\u015b na pomys\u0142 stworzenia oprogramowania.<\/p>\n\n\n\n
Niezale\u017cnie od tego, czy Twoim celem jest zbudowanie wspomnianej ksi\u0105\u017cki kucharskiej, stworzenie osobistego trenera na si\u0142owni\u0119, czy ogromnej aplikacji dla tysi\u0119cy u\u017cytkownik\u00f3w, pocz\u0105tek zawsze wygl\u0105da tak samo. Jeste\u015b pe\u0142en entuzjazmu i chcesz od razu siada\u0107 do pisania kodu. Zatrzymaj si\u0119. Najgorsze, co mo\u017cesz teraz zrobi\u0107, to rzuci\u0107 si\u0119 w wir programowania bez przygotowania.<\/p>\n\n\n\n
W tym rozdziale dowiesz si\u0119, jak krok po kroku przej\u015b\u0107 od lu\u017anego pomys\u0142u do gotowego planu dzia\u0142ania, unikaj\u0105c przy tym najdro\u017cszych b\u0142\u0119d\u00f3w w \u015bwiecie IT. Pami\u0119taj o jednej zasadzie: w \u015bwiecie tworzenia oprogramowania pomys\u0142y i wymagania mog\u0105 zmienia\u0107 si\u0119 bardzo szybko, a wszystkie pocz\u0105tkowe za\u0142o\u017cenia mo\u017cemy (i powinni\u015bmy) podwa\u017ca\u0107.<\/p>\n\n\n\n
Zanim zaczniesz wymy\u015bla\u0107 rozwi\u0105zania, musisz dok\u0142adnie zrozumie\u0107, z czym walczysz. Je\u015bli pominiesz ten etap, ryzykujesz, \u017ce stworzysz \u015bwietne rozwi\u0105zanie dla problemu, kt\u00f3ry w og\u00f3le nie istnieje.<\/p>\n\n\n\n
Proces ten nazywamy Problem Discovery (odkrywaniem problemu). Polega on na zadaniu sobie serii trudnych pyta\u0144, zanim zainwestujesz sw\u00f3j czas i pieni\u0105dze. Zastan\u00f3w si\u0119:<\/p>\n\n\n\n
W przypadku naszej ksi\u0105\u017cki kucharskiej problemem nie jest „brak aplikacji w telefonie\u201d. Problemem jest chaos oraz brak do\u015bwiadczenia w wymy\u015blaniu nowych potraw. User pain points<\/strong> to frustracje, z kt\u00f3rymi spotykasz si\u0119 na co dzie\u0144. Mo\u017ce to by\u0107 gubienie lu\u017anych kartek z przepisami, trudno\u015b\u0107 w znalezieniu odpowiedniego dania na szybko, albo fakt, \u017ce po prostu nie istnieje \u017caden znany przepis kt\u00f3ry sk\u0142ada si\u0119 wy\u0142\u0105cznie ze sk\u0142adnik\u00f3w jakie mamy w lod\u00f3wce.<\/p>\n\n\n\n Je\u015bli na wczesnym etapie zidentyfikujesz te rzeczywiste problemy, \u0142atwiej b\u0119dzie Ci nada\u0107 priorytety funkcjom Twojej aplikacji i unikn\u0105\u0107 tworzenia rzeczy, kt\u00f3rych nikt nie u\u017cyje.<\/p>\n\n\n\n Gdy ju\u017c wiesz, jaki problem chcesz rozwi\u0105za\u0107, wkraczasz w kolejn\u0105 faz\u0119 Product Discovery (odkrywania produktu). To proces badawczy, w kt\u00f3rym sprawdzasz, czy Twoja wizja rozwi\u0105zania (np. cyfrowa ksi\u0105\u017cka kucharska) ma w og\u00f3le sens, zanim po\u015bwi\u0119cisz czas i pieni\u0105dze na jej stworzenie.<\/p>\n\n\n\n Celem Product Discovery jest szybkie odfiltrowanie z\u0142ych pomys\u0142\u00f3w i pozostawienie tylko tych, kt\u00f3re:<\/p>\n\n\n\n Cz\u0119sto wydaje nam si\u0119, \u017ce wiemy, czego chc\u0105 ludzie. To pu\u0142apka! Rozwijanie aplikacji wy\u0142\u0105cznie na podstawie w\u0142asnych domys\u0142\u00f3w lub \u017cycze\u0144 inwestor\u00f3w ko\u0144czy si\u0119 stworzeniem funkcji, kt\u00f3rych nikt nie potrzebuje. Wed\u0142ug statystyk, oko\u0142o 40% funkcji w gotowych produktach jest u\u017cywanych rzadko lub wcale. Dlatego tak wa\u017cne jest, aby rozmawia\u0107 z potencjalnymi u\u017cytkownikami i testowa\u0107 za\u0142o\u017cenia (walidowa\u0107 pomys\u0142y) za pomoc\u0105 prostych szkic\u00f3w, ankiet czy wywiad\u00f3w, jeszcze przed napisaniem prawdziwego kodu.<\/p>\n\n\n\n Skoro ju\u017c wiesz, \u017ce Twoja aplikacja rozwi\u0105zuje realny problem, czas zacz\u0105\u0107 budowa\u0107. Ale nie od razu „Wielki Pa\u0142ac\u201d. Tworzymy MVP – Minimum Viable Product (produkt posiadaj\u0105cy tylko kluczowe funkcjonalno\u015bci).<\/p>\n\n\n\n Wiele os\u00f3b mylnie uwa\u017ca, \u017ce MVP to produkt zrobiony „na odwal si\u0119\u201d, pe\u0142en b\u0142\u0119d\u00f3w. Nic bardziej mylnego. MVP to najbardziej podstawowa wersja Twojej aplikacji, kt\u00f3ra posiada tylko te funkcje, kt\u00f3re s\u0105 absolutnie niezb\u0119dne do rozwi\u0105zania g\u0142\u00f3wnego problemu u\u017cytkownika.<\/p>\n\n\n\n Dlaczego MVP jest tak pot\u0119\u017cnym narz\u0119dziem?<\/p>\n\n\n\n Zastosujmy to do naszej ksi\u0105\u017cki kucharskiej. Tw\u00f3j docelowy plan mo\u017ce zak\u0142ada\u0107 integracj\u0119 z list\u0105 zakup\u00f3w online, modu\u0142 automatycznie robi\u0105cy zakupy w sklepach internetowych, modu\u0142 spo\u0142eczno\u015bciowy do lajkowania przepis\u00f3w znajomych, oraz AI, kt\u00f3re na podstawie zdj\u0119cia lod\u00f3wki wymy\u015bla obiad. Brzmi super, prawda? Ale to nie jest MVP. Twoje MVP ksi\u0105\u017cki kucharskiej powinno pozwala\u0107 na to co jest absolutnie niezb\u0119dne, \u017ceby rozwi\u0105za\u0107 g\u0142\u00f3wny problem u\u017cytkownik\u00f3w. Na przyk\u0142ad konwersja zdj\u0119cia na przepis. Tyle. Wypuszczasz to do ludzi, sprawdzasz, czy w og\u00f3le chc\u0105 z tego korzysta\u0107, i dopiero wtedy decydujesz, czy warto dodawa\u0107 kolejne funkcjonalno\u015bci. To tak zwana p\u0119tla Buduj – Mierz – Ucz si\u0119.<\/p>\n\n\n\n Aby proces od pomys\u0142u do MVP przebiega\u0142 sprawnie, bran\u017ca IT wypracowa\u0142a co\u015b, co nazywa si\u0119 SDLC (Software Development Life Cycle) – cyklem \u017cycia wytwarzania oprogramowania. To nic innego jak mapa drogowa, kt\u00f3ra dzieli proces tworzenia na powtarzalne, ustrukturyzowane etapy.<\/p>\n\n\n\n Standardowo SDLC sk\u0142ada si\u0119 z 7 krok\u00f3w:<\/p>\n\n\n\n Jak to zorganizowa\u0107? Istniej\u0105 dwa g\u0142\u00f3wne podej\u015bcia.<\/p>\n\n\n\n Pierwsze to Waterfall <\/strong>(Kaskada) – podej\u015bcie tradycyjne, gdzie planujesz wszystko od A do Z na samym pocz\u0105tku, a potem krok po kroku to realizujesz. Niestety, jest ma\u0142o elastyczne. Je\u015bli w po\u0142owie projektu uznasz, \u017ce zamiast ksi\u0105\u017cki kucharskiej dla u\u017cytkownik\u00f3w indywidualnych chcesz i\u015b\u0107 w kierunku budowania systemu do obs\u0142ugi catering\u00f3w, z obs\u0142ug\u0105 system\u00f3w magazynowych, integracji z hurtowniami, itp. – zmiana mo\u017ce by\u0107 do\u015b\u0107 problematyczna. Takie podej\u015bcie jednak sprawdza si\u0119 bardzo dobrze przy ogromnych systemach, kt\u00f3re rozwi\u0105zuj\u0105 specyficzny problem, musz\u0105 by\u0107 prawid\u0142owo zaprojektowane od samego pocz\u0105tku, a prawdopodobie\u0144stwo zmian na etapie rozwoju jest minimalne – np. dedykowany system dla wojska.<\/p>\n\n\n\n Drugie podej\u015bcie to Agile <\/strong>(Zwinno\u015b\u0107). Tutaj pracujemy w kr\u00f3tkich cyklach (tzw. sprintach), po kt\u00f3rych pokazujemy dzia\u0142aj\u0105cy kawa\u0142ek aplikacji i zbieramy opinie od u\u017cytkownik\u00f3w. To idealne podej\u015bcie do tworzenia MVP oraz rozwoju produktu, kt\u00f3ry kszta\u0142tuje si\u0119 pod wp\u0142ywem opinii u\u017cytkownik\u00f3w ko\u0144cowych. Pomimo ogromnej popularno\u015bci, Agile jest zaskakuj\u0105co cz\u0119sto b\u0142\u0119dnie interpretowane. Wiele os\u00f3b uwa\u017ca, \u017ce chodzi g\u0142\u00f3wnie, \u017ceby spotyka\u0107 si\u0119 na daily, sprint demo, sprint planning, i tym podobnych – jednak pomijaj\u0105 g\u0142\u00f3wne przes\u0142anie Agile. Je\u015bli masz zapami\u0119ta\u0107 co\u015b na temat Agile, to jego g\u0142\u00f3wnym celem jest przyrost warto\u015bci produktu dla u\u017cytkownika ko\u0144cowego z ka\u017cdym sprintem. Je\u015bli na koniec sprintu u\u017cytkownikowi ko\u0144cowemu nie jest wygodniej lub \u0142atwiej korzysta\u0107 z naszej aplikacji, to znaczy, \u017ce b\u0142\u0119dnie u\u017cywamy Agile.<\/p>\n\n\n\n Jak jest w praktyce? W realnym \u015bwiecie, zw\u0142aszcza przy wi\u0119kszych projektach, rzadko kiedy stosuje si\u0119 czysty Waterfall lub czysty Agile. Cz\u0119sto spotkasz si\u0119 z podej\u015bciem hybrydowym. U\u017cywamy element\u00f3w Waterfalla na samym pocz\u0105tku, aby oszacowa\u0107 bud\u017cet i og\u00f3lny zarys projektu, a nast\u0119pnie prze\u0142\u0105czamy si\u0119 na Agile w fazie faktycznego kodowania, aby zachowa\u0107 elastyczno\u015b\u0107 i szybko reagowa\u0107 na informacje zwrotne z rynku.<\/p>\n\n\n\n Na koniec musimy poruszy\u0107 kluczow\u0105 zasad\u0119 optymalizacji. Niezale\u017cnie od tego, czy tworzysz aplikacj\u0119, budujesz fabryk\u0119, lini\u0119 produkcyjn\u0105 czy optymalizujesz proces w biznesie, jest to bardzo istotna kwestia. Elon Musk, zarz\u0105dzaj\u0105c swoimi gigantycznymi fabrykami, opracowa\u0142 prosty algorytm, kt\u00f3ry rewelacyjnie sprawdza si\u0119 w IT. Prezentuje si\u0119 on nast\u0119puj\u0105co:<\/p>\n\n\n\n Co to oznacza dla Ciebie? Zanim zaczniesz pisa\u0107 skomplikowany kod automatyzuj\u0105cy jaki\u015b proces w Twojej aplikacji, zastan\u00f3w si\u0119, czy ten proces jest w og\u00f3le potrzebny. Kwestionuj ka\u017cde za\u0142o\u017cenie i ka\u017cd\u0105 funkcj\u0119. Usu\u0144 ka\u017cd\u0105 cz\u0119\u015b\u0107 systemu, kt\u00f3ra nie jest absolutnie krytyczna. Powszechnym b\u0142\u0119dem pocz\u0105tkuj\u0105cych tw\u00f3rc\u00f3w jest optymalizowanie i automatyzowanie proces\u00f3w, kt\u00f3re nigdy nie powinny by\u0142y w og\u00f3le powsta\u0107.<\/p>\n\n\n\n Je\u015bli w Twojej ksi\u0105\u017cce kucharskiej proces dodawania przepisu jest zbyt d\u0142ugi i zawi\u0142y, nie pr\u00f3buj pisa\u0107 algorytmu, kt\u00f3ry zgadnie, co u\u017cytkownik chcia\u0142 wpisa\u0107. Najpierw upro\u015b\u0107 sam formularz. Nie automatyzuj ba\u0142aganu. Najpierw pomy\u015bl, posprz\u0105taj, potem koduj.<\/p>\n\n\n\n Teraz wiesz ju\u017c, \u017ce stworzenie doskona\u0142ej aplikacji to nie tylko kwestia szybkiego stukania w klawiatur\u0119 czy generowania kodu przez AI. To proces. Zaczynasz od zrozumienia rzeczywistego problemu (Problem Discovery), sprawdzasz, czy Twoje pomys\u0142y s\u0105 trafione, a nast\u0119pnie budujesz najprostsz\u0105 mo\u017cliw\u0105 wersj\u0119, kt\u00f3ra dostarcza warto\u015b\u0107 (MVP). Robisz to wszystko, korzystaj\u0105c ze zwinnego cyklu \u017cycia oprogramowania, pami\u0119taj\u0105c, by zawsze upraszcza\u0107, zanim zaczniesz cokolwiek automatyzowa\u0107. Nast\u0119pnie zbierasz opinie od u\u017cytkownik\u00f3w ko\u0144cowych i usprawniasz.<\/p>\n\n\n\n Kiedy mamy ju\u017c pewno\u015b\u0107, co i dlaczego chcemy zbudowa\u0107, pojawia si\u0119 kolejne, fundamentalne pytanie: jak to technicznie posk\u0142ada\u0107, \u017ceby si\u0119 nie zawali\u0142o, gdy z Twojej ksi\u0105\u017cki kucharskiej zacznie korzysta\u0107 tysi\u0105c os\u00f3b naraz? O tym, z jakich klock\u00f3w zbudowa\u0107 nasz system, dowiesz si\u0119 w kolejnym rozdziale, gdzie zajrzymy g\u0142\u0119boko pod mask\u0119 i porozmawiamy o architekturze oprogramowania.<\/p>\n\n\n\n Materia\u0142y do samodzielnej nauki zwi\u0105zane z tym tematem:<\/p>\n\n\n\n Po co Budujemy Oprogramowanie? Wyobra\u017a sobie tak\u0105 sytuacj\u0119: stoisz w kuchni, r\u0119ce masz umazane m\u0105k\u0105 i gor\u0105czkowo przeszukujesz szuflad\u0119 w poszukiwaniu po\u017c\u00f3\u0142k\u0142ej kartki z przepisem na popisowe ciasto Twojej babci. Kartki nie ma. Znowu. W Twojej g\u0142owie rodzi si\u0119 genialna my\u015bl: „A gdyby tak stworzy\u0107 aplikacj\u0119 – cyfrow\u0105 ksi\u0105\u017ck\u0119 kucharsk\u0105, w kt\u00f3rej mia\u0142bym wszystkie przepisy […]<\/p>\n","protected":false},"author":2,"featured_media":0,"parent":415,"menu_order":2,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-427","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/nuplo.org\/pl\/wp-json\/wp\/v2\/pages\/427","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nuplo.org\/pl\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/nuplo.org\/pl\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/nuplo.org\/pl\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/nuplo.org\/pl\/wp-json\/wp\/v2\/comments?post=427"}],"version-history":[{"count":8,"href":"https:\/\/nuplo.org\/pl\/wp-json\/wp\/v2\/pages\/427\/revisions"}],"predecessor-version":[{"id":777,"href":"https:\/\/nuplo.org\/pl\/wp-json\/wp\/v2\/pages\/427\/revisions\/777"}],"up":[{"embeddable":true,"href":"https:\/\/nuplo.org\/pl\/wp-json\/wp\/v2\/pages\/415"}],"wp:attachment":[{"href":"https:\/\/nuplo.org\/pl\/wp-json\/wp\/v2\/media?parent=427"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Product Discovery: Oddzielenie Dobrych Pomys\u0142\u00f3w od Z\u0142ych<\/h2>\n\n\n\n
\n
Skup si\u0119 na Tym, co Niezb\u0119dne, czyli MVP<\/h2>\n\n\n\n
\n
Cykl \u017bycia Oprogramowania, czyli z In\u017cynierskiego Punktu Widzenia<\/h2>\n\n\n\n
\n
Z\u0142ota Zasada: Uprz\u0105tnij Ba\u0142agan, Zanim Go Zautomatyzujesz<\/h2>\n\n\n\n
\n
Podsumowanie<\/h2>\n\n\n\n
Materia\u0142y<\/h2>\n\n\n\n
\n