Odkrywanie i Planowanie Produktu

Po co Budujemy Oprogramowanie?

Wyobraź sobie taką sytuację: stoisz w kuchni, ręce masz umazane mąką i gorączkowo przeszukujesz szufladę w poszukiwaniu pożółkłej kartki z przepisem na popisowe ciasto Twojej babci. Kartki nie ma. Znowu. W Twojej głowie rodzi się genialna myśl: „A gdyby tak stworzyć aplikację – cyfrową książkę kucharską, w której miałbym wszystkie przepisy pod ręką, a na dodatek robiąc zdjęcie produktów z lodówki AI samo generowałoby nowe przepisy, do których posiadasz wszystkie składniki?”.

Gratulacje, właśnie wpadłeś na pomysł stworzenia oprogramowania.

Niezależnie od tego, czy Twoim celem jest zbudowanie wspomnianej książki kucharskiej, stworzenie osobistego trenera na siłownię, czy ogromnej aplikacji dla tysięcy użytkowników, początek zawsze wygląda tak samo. Jesteś pełen entuzjazmu i chcesz od razu siadać do pisania kodu. Zatrzymaj się. Najgorsze, co możesz teraz zrobić, to rzucić się w wir programowania bez przygotowania.

W tym rozdziale dowiesz się, jak krok po kroku przejść od luźnego pomysłu do gotowego planu działania, unikając przy tym najdroższych błędów w świecie IT. Pamiętaj o jednej zasadzie: w świecie tworzenia oprogramowania pomysły i wymagania mogą zmieniać się bardzo szybko, a wszystkie początkowe założenia możemy (i powinniśmy) podważać.

Problem Discovery: Zdefiniuj Problem, Zanim Zaczniesz Go Leczyć

Zanim zaczniesz wymyślać rozwiązania, musisz dokładnie zrozumieć, z czym walczysz. Jeśli pominiesz ten etap, ryzykujesz, że stworzysz świetne rozwiązanie dla problemu, który w ogóle nie istnieje.

Proces ten nazywamy Problem Discovery (odkrywaniem problemu). Polega on na zadaniu sobie serii trudnych pytań, zanim zainwestujesz swój czas i pieniądze. Zastanów się:

Dlaczego rozwiązanie tego problemu jest w ogóle ważne?
Co się stanie, jeśli go nie rozwiążemy?
Czy tego problemu nie da się rozwiązać bez tworzenia oprogramowania?
Jaką konkretnie wartość nam to przyniesie?

W przypadku naszej książki kucharskiej problemem nie jest „brak aplikacji w telefonie”. Problemem jest chaos oraz brak doświadczenia w wymyślaniu nowych potraw. User pain points to frustracje, z którymi spotykasz się na co dzień. Może to być gubienie luźnych kartek z przepisami, trudność w znalezieniu odpowiedniego dania na szybko, albo fakt, że po prostu nie istnieje żaden znany przepis który składa się wyłącznie ze składników jakie mamy w lodówce.

Jeśli na wczesnym etapie zidentyfikujesz te rzeczywiste problemy, łatwiej będzie Ci nadać priorytety funkcjom Twojej aplikacji i uniknąć tworzenia rzeczy, których nikt nie użyje.

Product Discovery: Oddzielenie Dobrych Pomysłów od Złych

Gdy już wiesz, jaki problem chcesz rozwiązać, wkraczasz w kolejną fazę Product Discovery (odkrywania produktu). To proces badawczy, w którym sprawdzasz, czy Twoja wizja rozwiązania (np. cyfrowa książka kucharska) ma w ogóle sens, zanim poświęcisz czas i pieniądze na jej stworzenie.

Celem Product Discovery jest szybkie odfiltrowanie złych pomysłów i pozostawienie tylko tych, które:

Są wartościowe dla użytkownika (chce z nich korzystać).
Są intuicyjne w obsłudze.
Są technicznie możliwe do zbudowania.

Często wydaje nam się, że wiemy, czego chcą ludzie. To pułapka! Rozwijanie aplikacji wyłącznie na podstawie własnych domysłów lub życzeń inwestorów kończy się stworzeniem funkcji, których nikt nie potrzebuje. Według statystyk, około 40% funkcji w gotowych produktach jest używanych rzadko lub wcale. Dlatego tak ważne jest, aby rozmawiać z potencjalnymi użytkownikami i testować założenia (walidować pomysły) za pomocą prostych szkiców, ankiet czy wywiadów, jeszcze przed napisaniem prawdziwego kodu.

Skup się na Tym, co Niezbędne, czyli MVP

Skoro już wiesz, że Twoja aplikacja rozwiązuje realny problem, czas zacząć budować. Ale nie od razu „Wielki Pałac”. Tworzymy MVP – Minimum Viable Product (produkt posiadający tylko kluczowe funkcjonalności).

Wiele osób mylnie uważa, że MVP to produkt zrobiony „na odwal się”, pełen błędów. Nic bardziej mylnego. MVP to najbardziej podstawowa wersja Twojej aplikacji, która posiada tylko te funkcje, które są absolutnie niezbędne do rozwiązania głównego problemu użytkownika.

Dlaczego MVP jest tak potężnym narzędziem?

Oszczędzasz czas i pieniądze: Budując mniej, szybciej trafiasz na rynek.
Zbierasz realny feedback: Nie gdybasz, tylko mierzysz, jak prawdziwi ludzie używają Twojej aplikacji.
Ograniczasz ryzyko: Jeśli pomysł okaże się słaby, stracisz miesiąc pracy, a nie dwa lata.

Zastosujmy to do naszej książki kucharskiej. Twój docelowy plan może zakładać integrację z listą zakupów online, moduł automatycznie robiący zakupy w sklepach internetowych, moduł społecznościowy do lajkowania przepisów znajomych, oraz AI, które na podstawie zdjęcia lodówki wymyśla obiad. Brzmi super, prawda? Ale to nie jest MVP. Twoje MVP książki kucharskiej powinno pozwalać na to co jest absolutnie niezbędne, żeby rozwiązać główny problem użytkowników. Na przykład konwersja zdjęcia na przepis. Tyle. Wypuszczasz to do ludzi, sprawdzasz, czy w ogóle chcą z tego korzystać, i dopiero wtedy decydujesz, czy warto dodawać kolejne funkcjonalności. To tak zwana pętla Buduj – Mierz – Ucz się.

Cykl Życia Oprogramowania, czyli z Inżynierskiego Punktu Widzenia

Aby proces od pomysłu do MVP przebiegał sprawnie, branża IT wypracowała coś, co nazywa się SDLC (Software Development Life Cycle) – cyklem życia wytwarzania oprogramowania. To nic innego jak mapa drogowa, która dzieli proces tworzenia na powtarzalne, ustrukturyzowane etapy.

Standardowo SDLC składa się z 7 kroków:

Planowanie: Określamy cel i zakres projektu.
Analiza: Zbieramy dokładne wymagania.
Projektowanie (Design): Planujemy architekturę systemu i wygląd (UI/UX).
Kodowanie: Programiści wkraczają do akcji i tworzą aplikację.
Testowanie: Wyłapujemy błędy i sprawdzamy, czy wszystko działa jak należy.
Wdrożenie: Aplikacja trafia do użytkowników.
Utrzymanie: Naprawiamy nowe błędy i wypuszczamy aktualizacje.

Jak to zorganizować? Istnieją dwa główne podejścia.

Pierwsze to Waterfall (Kaskada) – podejście tradycyjne, gdzie planujesz wszystko od A do Z na samym początku, a potem krok po kroku to realizujesz. Niestety, jest mało elastyczne. Jeśli w połowie projektu uznasz, że zamiast książki kucharskiej dla użytkowników indywidualnych chcesz iść w kierunku budowania systemu do obsługi cateringów, z obsługą systemów magazynowych, integracji z hurtowniami, itp. – zmiana może być dość problematyczna. Takie podejście jednak sprawdza się bardzo dobrze przy ogromnych systemach, które rozwiązują specyficzny problem, muszą być prawidłowo zaprojektowane od samego początku, a prawdopodobieństwo zmian na etapie rozwoju jest minimalne – np. dedykowany system dla wojska.

Drugie podejście to Agile (Zwinność). Tutaj pracujemy w krótkich cyklach (tzw. sprintach), po których pokazujemy działający kawałek aplikacji i zbieramy opinie od użytkowników. To idealne podejście do tworzenia MVP oraz rozwoju produktu, który kształtuje się pod wpływem opinii użytkowników końcowych. Pomimo ogromnej popularności, Agile jest zaskakująco często błędnie interpretowane. Wiele osób uważa, że chodzi głównie, żeby spotykać się na daily, sprint demo, sprint planning, i tym podobnych – jednak pomijają główne przesłanie Agile. Jeśli masz zapamiętać coś na temat Agile, to jego głównym celem jest przyrost wartości produktu dla użytkownika końcowego z każdym sprintem. Jeśli na koniec sprintu użytkownikowi końcowemu nie jest wygodniej lub łatwiej korzystać z naszej aplikacji, to znaczy, że błędnie używamy Agile.

Jak jest w praktyce? W realnym świecie, zwłaszcza przy większych projektach, rzadko kiedy stosuje się czysty Waterfall lub czysty Agile. Często spotkasz się z podejściem hybrydowym. Używamy elementów Waterfalla na samym początku, aby oszacować budżet i ogólny zarys projektu, a następnie przełączamy się na Agile w fazie faktycznego kodowania, aby zachować elastyczność i szybko reagować na informacje zwrotne z rynku.

Złota Zasada: Uprzątnij Bałagan, Zanim Go Zautomatyzujesz

Na koniec musimy poruszyć kluczową zasadę optymalizacji. Niezależnie od tego, czy tworzysz aplikację, budujesz fabrykę, linię produkcyjną czy optymalizujesz proces w biznesie, jest to bardzo istotna kwestia. Elon Musk, zarządzając swoimi gigantycznymi fabrykami, opracował prosty algorytm, który rewelacyjnie sprawdza się w IT. Prezentuje się on następująco:

Kwestionuj każde zalecenie: Nie przyjmuj wymagań od przełożonych i „najlepszych praktyk” jako nienaruszalnych pewników. Zawsze pytaj „dlaczego?” i weryfikuj sensowność każdego zalecenia – nawet jeśli pochodzi od Twojego przełożonego czy samego właściciela firmy. Każde zadanie musi mieć przypisaną tylko i wyłącznie jedną odpowiedzialną osobę z, którą można dane założenie przedyskutować i ustalić, dlaczego ma to działać tak, a nie inaczej.
Usuń każdą część czy proces, który da się usunąć: Trzeba maksymalnie upraszczać procesy i działanie. Później możesz to przywrócić jeśli zajdzie taka potrzeba. Jednak, jeśli nie przywrócisz 10% z usuniętych wcześniej części i procesów, będzie to oznaczać, że nie usunąłeś wystarczająco dużo.
Upraszczaj i optymalizuj: Rób to dopiero po usunięciu zbędnych elementów. Jednym z największych błędów w IT jest tracenie czasu na optymalizowanie funkcji, które w ogóle nie powinny w systemie istnieć.
Przyspiesz cykl produkcyjny: Każdy proces można przyspieszyć, ale rób to tylko jeśli przeszedłeś przez pierwsze trzy kroki. Elon Musk twierdzi, że w Tesli niepotrzebnie tracił czas na przyspieszanie procesów, które powinny zostać usunięte.
Automatyzuj na końcu: Zautomatyzowanie nieefektywnego procesu daje jedynie szybki, zautomatyzowany bałagan. Zaawansowane rozwiązania wprowadzaj dopiero wtedy, gdy cały proces jest już zweryfikowany i uproszczony.

Co to oznacza dla Ciebie? Zanim zaczniesz pisać skomplikowany kod automatyzujący jakiś proces w Twojej aplikacji, zastanów się, czy ten proces jest w ogóle potrzebny. Kwestionuj każde założenie i każdą funkcję. Usuń każdą część systemu, która nie jest absolutnie krytyczna. Powszechnym błędem początkujących twórców jest optymalizowanie i automatyzowanie procesów, które nigdy nie powinny były w ogóle powstać.

Jeśli w Twojej książce kucharskiej proces dodawania przepisu jest zbyt długi i zawiły, nie próbuj pisać algorytmu, który zgadnie, co użytkownik chciał wpisać. Najpierw uprość sam formularz. Nie automatyzuj bałaganu. Najpierw pomyśl, posprzątaj, potem koduj.

Podsumowanie

Teraz wiesz już, że stworzenie doskonałej aplikacji to nie tylko kwestia szybkiego stukania w klawiaturę czy generowania kodu przez AI. To proces. Zaczynasz od zrozumienia rzeczywistego problemu (Problem Discovery), sprawdzasz, czy Twoje pomysły są trafione, a następnie budujesz najprostszą możliwą wersję, która dostarcza wartość (MVP). Robisz to wszystko, korzystając ze zwinnego cyklu życia oprogramowania, pamiętając, by zawsze upraszczać, zanim zaczniesz cokolwiek automatyzować. Następnie zbierasz opinie od użytkowników końcowych i usprawniasz.

Kiedy mamy już pewność, co i dlaczego chcemy zbudować, pojawia się kolejne, fundamentalne pytanie: jak to technicznie poskładać, żeby się nie zawaliło, gdy z Twojej książki kucharskiej zacznie korzystać tysiąc osób naraz? O tym, z jakich klocków zbudować nasz system, dowiesz się w kolejnym rozdziale, gdzie zajrzymy głęboko pod maskę i porozmawiamy o architekturze oprogramowania.

Materiały

Materiały do samodzielnej nauki związane z tym tematem: