Kent Beck, twórca programowania ekstremalnego (XP), powiedział kiedyś:
W tłumaczeniu na język polski, brzmi to mniej więcej tak: “Dane z jednej iteracji są warte miesięcy spekulacji”. Ale co to właściwie oznacza?
Idea jest prosta. Zamiast spędzać miesiące na szczegółowym planowaniu, często lepiej jest zbudować wersję MVP (ang. Minimum Viable Product) i zacząć zbierać dane „w terenie” od rzeczywistych użytkowników. Pozwala to zrozumieć, czego naprawdę potrzebują nasi klienci, zamiast tylko spekulować.
Nie tak dawno temu podejście BDUF (ang. Big Design Up Front), czyli szczegółowe, wielomiesięczne projektowanie przed rozpoczęciem jakichkolwiek prac programistycznych, było dość powszechne. Zespoły spędzały znaczną ilość czasu na początkowym planowaniu, w zasadzie zgadując preferencje użytkowników i projektując funkcjonalności, które w praktyce mogły okazać się zupełnie nieprzydatne.
To z kolei płynnie łączy się z filozofią “fail fast” (szybkiego ponoszenia porażki), czyli gotowością do porzucenia pomysłu, jeżeli ten nie spełnia fundamentalnych założeń, a jego dalszy development pociągnie za sobą dodatkowe koszty, nie dając jednocześnie pewności na poprawę sytuacji.
Oczywiście nie chodzi o to, by rezygnować z projektu, gdy tylko natrafimy na pierwsze problemy. Podejście “fail fast” ma raczej na celu zachęcić do szybkiego implementowania podstawowych funkcjonalności, a następnie sprawdzenia ich w praktyce z wykorzystaniem realnych użytkowników. Kluczowe jest oczywiście zbieranie danych oraz informacji zwrotnych od klientów - na ich podstawie będziemy usprawniać produkt i dodawać nowe funkcjonalności. Na tym jednak “fail fast” się nie kończy. Jeżeli produkt nie spełnia oczekiwań i założeń biznesowych, to może się okazać, że zamiast próbować ratować coś, co nie działa, lepiej jest rozpocząć od nowa z nową perspektywą.
Takie podejście jest szczególnie istotne w przypadku startupów, projektów osobistych i małych firm. Spędzanie miesięcy na planowaniu projektu, który może nigdy nie ujrzeć światła dziennego, jest po prostu stratą czasu. Jeżeli podstawowe założenia i koncepcja, nie spotka się z pozytywnym odbiorem użytkowników, to wszelkie dodatkowe funkcjonalności i plany są bez znaczenia.
Oczywiście pewien stopień planowania jest nadal konieczny, jednak nacisk należy położyć na zdefiniowanie podstawowej wartości dla użytkownika. Kolejny krok to zbudowanie i wypuszczenie minimalnej wersji aplikacji. Jeżeli produkt się przyjmie, to przechodzimy do kolejnej iteracji i powtarzamy cały proces - planujemy (jednak tym razem na podstawie produkcyjnych danych), a następnie implementujemy kolejne funkcjonalności.
Jeżeli jednak projekt nie spełnia podstawowych założeń, to udało się uniknąć zainwestowania ogromnej ilości czasu w planowanie na wstępie. Takie podejścia pozwala szybko “ponieść porażkę” i przejść do następnego pomysłu, bogatszym w zdobytą wiedzę.
Uwaga na koniec: “fail fast” nie jest panaceum na każdy projekt. W przypadku systemów wielkoskalowych, gdzie bezpieczeństwo i ochrona są najważniejsze (banki, instytucje przetwarzające wrażliwe dane), obszerne planowanie wstępne pozostaje kluczowe. Tego typu projekty są zazwyczaj realizowane przez ugruntowane firmy z niemal nielimitowanymi budżetami. Jednak w przypadku większości startupów i nowych przedsięwzięć mentalności „fail fast” może być tym, co uchroni Twój projekt przed porażką.