Planowanie projektu? A co to za filozofia? Przecież wystarczy wpisać listę zadań do planera czy aplikacji i zabrać się za działanie! Po co marnować czas, którego i tak już wszyscy mamy zbyt mało?
Jeśli tak myślisz, to poświęć mi kilka minut. Opowiem Ci, dlaczego warto zainwestować czas we właściwe podejście do projektu.
Żyjemy w niepewnych czasach
Niepewność jest wpisana w każdy projekt jak obowiązkowy wątek miłosny w powieści dla nastolatek. Nigdy nie wiesz, co pójdzie nie tak. Jaki będzie efekt końcowy? Czy uda się zrealizować? Czy wykonawcy zrealizują wszystko na czas? A co, jeśli ktoś mnie ubiegnie? Czy choroba moja i rodziny nie położy jutro całej realizacji na łopatki?
Dołóżmy do tego fakt, że obecnie portale do innych światów montowane są już nie w szafach, ale w łóżkach: zasypiasz w jednej rzeczywistości, a budzisz się w zupełnie innej. Trendy, pomysły i technologie pojawiają się i gasną jak fajerwerki na sylwestra. Niektórych tematów nie ma sensu opisywać w książkach, bo nim zdążysz ją wydać, może się już zdezaktualizować. Zaczynasz dzisiaj pisać powieść science fiction, a jutro już musisz ją przemianować na historyczną.
Już nie mówiąc o projektach, które kierujesz do jakiejś grupy odbiorców (jak choćby projekty biznesowe). Dojście do tego, czego ludzie tak naprawdę chcą, to już zadanie zakrawające o domenę wróża Macieja. Zwłaszcza że sami odbiorcy nie zawsze wiedzą, czego dokładnie potrzebują.
Jeśli po przeczytaniu powyższych akapitów masz w głowie kołowrót, to… spokojnie. Zaparz sobie melisy i odetchnij, bo teraz porozmawiamy sobie o tym, jak tę niepewność ujarzmić, a nawet… zaprząc do roboty, by działała na naszą korzyść.
Projekty na dwa sposoby
Żeby nie poruszać się w mgle teoretycznych pojęć, weźmy na warsztat konkretny projekt. Dajmy na to, że dwóch rzutkich młodzieńców, Anzelm i Bazyl, postanowili w tym samym czasie stworzyć aplikację z przepisami kulinarnymi.
Anzelm, doznawszy olśnienia, rzucił pracę i zamknął się w piwnicy, dla pewności zakładając zamek szyfrowy. W wielkiej tajemnicy przeanalizował istniejące portale kulinarne, zrobił listę wymarzonych funkcji. Opracował szczegółowy plan działania, który następnie realizował z podziwu godną konsekwencją.
Po kilku miesiącach mrówczej pracy dokonał wielkiego otwarcia aplikacji, która… zanotowała ogromną klapę. Użytkownicy połowę funkcji uznali za zbędne, a tych, których potrzebowali, w aplikacji po prostu nie było. Ponadto, koczując w piwnicy, Anzelm przegapił trend zdrowego odżywiania i nie pomyślał o tym, że zdrowe przepisy warto jakoś wyróżnić. Zaplanował przebudowę całej aplikacji, które… miały zająć kolejne miesiące.
Bazyl tymczasem zrobił prostą aplikację umożliwiającą dodawanie przepisów i ją opublikował. Zebrał małą, ale zaangażowaną grupę odbiorców, która chętnie dzieliła się w nim wrażeniami.
Okazało się, że odbiorcy potrzebują, aby przy każdym przepisie widoczny był czas przygotowania, bo sam opis nie wystarczał. Po wnikliwym przejrzeniu przepisu użytkownik orientował się bowiem, że „Błyskawiczny przepis na obiad” pani Zdzisi wymagał dwugodzinnego stania przy garach.
Później użytkownicy poprosili o możliwość wyszukiwania przepisów po produktach, bo dojrzałe awokado i otwarty jogurt naturalny domagały się natychmiastowego zużycia. Bazyl dodał i tę funkcję.
I tak dalej, i tak dalej. Wraz z ulepszaniem aplikacji rosło też grono odbiorców. Po paru miesiącach miał już nieźle działającą aplikację oraz zbudowaną wierną społeczność… nim jeszcze projekt Anzelma ujrzał światło dzienne.
Co tu się wydarzyło?
Co w tym przykładzie zdecydowało o sukcesie projektu Bazyla? Omówmy to po kolei:
Interakcje z użytkownikami
Zamiast skupiać się na idealnym dopracowaniu listy zadań, postawił na komunikację i budowanie relacji. To te relacje i rozmowy pomogły mu stworzyć aplikację, której będą chętnie używać.
Współpraca z klientami
Bazyl nie tworzył projektu „sobie a muzom”. Nie chodziło mu o zrealizowanie wyśnionej wizji, a na to, by użytkownicy znaleźli w aplikacji to, czego rzeczywiście potrzebują. A to oznacza także…
Reagowanie na zmiany
Bazyl mógł mieć nawet pomysły na to, co zamieścić w aplikacji. Może wymyślił taką czy inną funkcję. Ale nie trzymał się tej wizji kurczowo – tylko pytał, czy klienci właśnie tego potrzebują. Jeśli w trakcie rozbudowy aplikacji pojawi się nowy trend, Bazyl będzie mógł na niego zareagować. Ale aby to mogło zagrać, potrzebna jest…
Działająca aplikacja
Za każdym razem Bazyl wydawał działającą aplikację, która działała. Aplikacja Anzelma, dopóki nie ujrzała światła dziennego, była do niczego. Nikt nie potrzebuje aplikacji ukończonej w 99%, jeśli nie można jej używać. Bazyl zaczął od zbudowania fundamentu i stopniowo dodawał funkcje. Ale po każdej dodanej funkcji użytkownicy mogli z aplikacji korzystać.
A jeśli zbierzemy to wszystko razem…
…no to mamy Agile, czyli tak zwane „zwinne zarządzanie”. To jest właśnie podejście do projektów, które pomaga zabezpieczyć się przed niepewnością.
Klasyczne podejście, zwane Waterfall, polega na działaniu sekwencyjnym: zaczynasz projekt, tworzysz plan, potem realizujesz. Przechodzisz do kolejnych etapów jak woda przeskakująca na kolejne stopnie kaskady. Zmiany przyjmowane są niechętnie. Dopiero na końcu robisz wielką premierę stworzonych efektów, przecinasz wstęgę i otwierasz szampana.
Czy w rollercoasterze zwanym „naszą codziennością” jest jeszcze miejsce na takie podejście do projektów? Tak, oczywiście! Jeśli budujesz dom, to nim wbijesz łopatę w ziemię, musisz mieć gotowy projekt. Możliwość zmian jest ograniczona – nie możesz położyć fundamentów pod domek jednorodzinny, a potem stwierdzić „a, pierdyknę sobie zameczek”. Tego typu projekty wciąż istnieją i potrzebują właśnie klasycznego podejścia.
Gdzie na linii jest Twój projekt?
Agile powstało po to, by wspierać tworzenie oprogramowania i nie do każdego projektu będzie się nadawać. Zresztą pod parasolką Agile kryje się cała masa mniej lub bardziej skomplikowanych metodologii.
Dla jasności: nie zamierzam tu dyskutować o wyższości sernika bez rodzynek nad tym z rodzynkami (choć w przypadku sernika sprawa jest oczywista!). Nie jestem też zwolenniczką bezmyślnego i ortodoksyjnego stosowania tego czy innego podejścia. Myślę, że każdy projekt osobisty może znaleźć swoje miejsce na spektrum od podejścia w całości klasycznego do totalnie zwinnego.
Jak możesz czerpać z podejścia Agile, by jak najlepiej wzmocnić swój projekt? Oto kilka pytań dla inspiracji:
→ Jak możesz zbudować relacje z odbiorcami tak, aby jak najlepiej poznać ich rzeczywiste potrzeby?
→ Co możesz zrobić, aby jak najszybciej otrzymać informację zwrotną? Jak możesz zadbać o to, by efekty informacji zwrotnej móc wkomponować w tworzony efekt?
→ Jak możesz zadbać o to, aby projekt odpowiadał na pojawiające się zmiany?
→ Czy możesz podzielić swój projekt na “moduły”, które będziesz stopniowo dopracowywać? Jaka jest minimalna “działająca” wersja tego projektu, którą możesz dalej rozbudowywać?
No dobrze, na tym poziomie ogólności pytania mogą brzmieć… niejasno. Dlatego w nadchodzącej już wielkimi krokami serii “Projekt: Projekt” spróbuję pokazać, jak wykorzystałam to podejście na przykładzie projektu, który, na pierwszy rzut oka, do Agile pasuje jak pięść do nosa.
Mogłabym podać tu kolejny zmyślony przykład, ale… może chciałbyś/abyś rozłożyć na czynniki pierwsze jakiś projekt, który chodzi Ci po głowie? Jeśli tak, to daj znać w komentarzu. Wspólnie coś wymyślimy!