Podczas, gdy tradycyjne podejście do zarządzania projektami zakładało ścisłe określenie zakresu prac, metody zwinne skłaniają się ku ustaleniom wykonywanym „na bieżąco”. W jaki sposób organizacje radzą sobie z definiowaniem projektu już w trakcie jego realizacji? Przyjrzyjmy się z jakich narzędzi i zasobów korzystają, aby uszczegóławiać wizję docelowego rozwiązania i gotowego produktu podczas prac.
Jednym z podstawowych wyróżników metod zwinnych, takich jak Scrum czy Kanban, w porównaniu do „tradycyjnego” zarządzania projektami, jest zdecydowanie bardziej elastyczne podejście do definiowania zakresu projektu. Można o tym przeczytać w Manifeście Agile: „Bądźcie gotowi na zmiany wymagań nawet na późnym etapie (…) rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności”. O tym, które podejście jest najwłaściwsze, decyduje charakterystyka realizowanego projektu. Zakres budowy wieżowca nie należy do grona nieprzewidywalnych – stąd świetnie sprawdzi się tam klasyczne zarządzanie projektami. Sytuacja zmienia się jednak, kiedy założenia biznesowe projektu zdefiniowano bardzo ogólnie, a opierają się one głównie na hipotezach. W tym przypadku, będzie można wyraźnie zauważyć zalety metodyk zwinnych.
MVP, czyli klucz do zwinności
Nadrzędnym narzędziem, na którym opiera się zwinny rozwój produktu jest MVP – Minimum Viable Product. To wersja produktu, która zawiera wyłącznie najważniejsze funkcjonalności. Rolą MVP jest jak najwcześniejsze zbieranie informacji zwrotnej z rynku. Dzięki temu zespół odpowiedzialny za rozwój produktu może lepiej identyfikować jego mocne i słabe strony oraz odpowiednio na te informacje reagować, na przykład zmieniając kształt pewnych funkcjonalności. Jednak MVP nie zawsze jest działającym rozwiązaniem. Wielokrotnie organizacje decydowały się na wykonanie pewnego rodzaju zaślepki lub obietnicy wartości. Najlepszym przykładem MVP – „obietnicy wartości” jest kickstarter i bliźniacze mu portale. Znajduje się tam olbrzymia liczba prototypów, które dopiero pokazują potencjalnym przyszłym użytkownikom co mogą zyskać, jeśli projekt zostanie zrealizowany. W identyczny sposób na rynku zadebiutował Dropbox. Drew Houston – twórca startupu – opublikował na portalu Digg film prezentujący możliwości jego technologii, a pozytywny odzew oglądających (wideo w ciągu 24 godzin zyskało 10 tysięcy reakcji, a na listę oczekujących na betę programu zapisało się 70 tysięcy osób) skłonił go do kontynuowania prac nad aplikacją. Innym, dobrym, przykładem jest McSpaghetti. Nowa „potrawa” sieci McDonald’s była wyłącznie pozycją w menu, która miała na celu sprawdzenie ilu klientów będzie skłonnych ją zamówić. Jeśli ktoś zdecydował się na spaghetti dowiadywał się, że niestety chwilowo jest ono niedostępne. Dzięki temu restauracja otrzymała wiarygodny feedback dotyczący rozszerzenia oferty. MVP zawdzięcza swoją popularność temu, że pozwala zespołom na wprowadzanie kolejnych usprawnień do produktu przy ciągłym dostępie do informacji z rynku. Rozwój produktu przy wykorzystaniu minimalnie wartościowego produktu jest często ilustrowany przez przykład samochodu jako rozwiązania problemu przemieszczania się z punktu A do B. Jest to wprawdzie duże uproszczenie, jednak oddaje ideę iteracyjności (Rys. 1).
Taki model rozwoju produktu wspierają między innymi Scrum oraz Lean Startup. Przeanalizujmy jak, przy wykorzystaniu MVP, te dwie metodyki składają się na proces wytwarzania produktów cyfrowych.
Pozyskiwanie informacji z rynku to jedna z miar postępu
Główną koncepcją Lean Startup jest działanie w pętli uczenia się. Składa się ona z 3 kroków: Zbuduj (Build), Zmierz (Measure), Wyciągnij Wnioski (Learn). Podstawowym celem zespołu działającego w takiej pętli jest jak najszybsze pozyskiwanie informacji z rynku i wykorzystanie jej do ulepszenia produktu. Każda iteracja wiążę się z przeprowadzeniem eksperymentów z wykorzystaniem efektów prac powstałych na etapie budowania. Testy są skonstruowane tak, aby dostarczały mierzalnych danych i obserwacji dotyczących produktu. Następnie z zebranych wcześniej informacji wyciągane są wnioski, które stanowią wkład w etap budowania następnej iteracji.
Identyfikacja potrzeb to Lean, implementacja rozwiązań to Scrum
Scrum w tej układance pełni rolę dookreślenia etapu budowania pętli. Jak możemy przeczytać w Scrum Guide: „Cały Scrum Team ponosi odpowiedzialność za wytworzenie wartościowego, użytecznego Incrementu co Sprint” oraz „Sprinty stwarzają warunki dla zaistnienia przewidywalności przez umożliwienie inspekcji i adaptacji postępów w dążeniu do Celu Produktu”. Czym w takim razie jest Increment? Tym, co umożliwia przejście przez kolejne etapy pętli. To użyteczny fragment oprogramowania, dzięki któremu zespół produktowy może uzyskać informacje potrzebne do dalszego rozwoju produktu. To też fragment oprogramowania, który dostarcza swoim użytkownikom rozwiązania ich problemów. To również iteracja MVP. Kluczowe dla Incrementu jest to, aby realnie dostarczał on klientom wartość, a zespołowi informację zwrotną pozwalającą dalej rozwijać produkt.
Zwinność to elastyczność
Powyższe metodyki tworzą system, który pozwala minimalizować ryzyko biznesowe oraz ułatwia pozyskiwanie feedbacku z rynku. Lean Startup jest w nim raczej ogólną definicją procesu – obejmuje cały jego zakres i jest bliższy biznesowej części zespołu. Z kolei Scrum zgłębia część technologiczną procesu i jest mu bliżej do osób technicznych. Co istotne, budowanie takich systemów jest bardzo elastyczne – przykładowo do tego opisanego powyżej można dołączyć Customer Development S. Blanka i B. Dorfa. Wykorzystanie Customer Development będzie, analogicznie do Scruma, precyzowało jeden z kroków pętli uczenia się – w tym przypadku krok wyciągania wniosków. Uzyskamy w nim między innymi systematycznie aktualizowany model biznesowy, czy zbiór hipotez na temat zachowania się potencjalnych klientów. Poszczególne elementy takiego systemu są również zastępowalne. Scrum może być bez większych przeszkód zastąpiony Kanbanem, jeśli charakterystyka tworzonego produktu będzie faworyzować tą metodykę.
Podsumowując, zwinne metodyki przede wszystkim pozwalają organizacjom na szybszy rozwój produktu i minimalizowanie niepewności. W ostatnich latach powstało wiele narzędzi, które wspierają tworzenie produktów w duchu koncepcji agile i lean. Nie są one tak skuteczne, kiedy zespół projektowy jest w posiadaniu wiarygodnych rynkowych danych, jednak w przypadku niepewnego otoczenia biznesowego mogą stanowić one klucz do rynkowego sukcesu przedsięwzięcia.
Student Inżynierii Zarządzania na Politechnice Warszawskiej. Zawodowo działa w szeroko pojętym IT – obecnie wspiera projektowanie cyfrowych procesów biznesowych dla instytucji finansowych. Od niedawna współtwórca bloga opowiadającego o tworzeniu produktów: re-solve.it. Czas wolny spędza w górach, na ściance wspinaczkowej lub na rowerze.