– W Laboratorium EE od samego początku wiedzieliśmy, że chcemy realizować projekty w określony sposób. Zależało nam, żeby robić rzeczy, z których będzie zadowolony nie tylko zleceniodawca, ale i jego wykonawcy, czyli my. A to w dużej mierze zależy od sposobu, w jakim prowadzimy nasze projekty.
Pierwszy artykuł naukowy, który opisywał proces zarządzania projektami ukazał się ponad pięćdziesiąt lat temu. Mówił o sposobie budowania projektów informatycznych i zakładał podział prac w zespole sposób kaskadowy, na kilka niezależnych od siebie sektorów. W przypadku serwisu do obsługi płatności mobilnych, zespół najpierw zająłby się stworzeniem specyfikacji, następnie zaprojektowaniem serwisu, a na samym końcu kodowaniem.
Problem polegał na tym, że niektórzy czytali ten artykuł tylko do połowy. Nie dochodzili więc do momentu, w którym autor pisał o tym, że prowadzenie projektów kaskadowo wcale nie jest proste i że poszczególne fazy nie mogą być w pełni od siebie oddzielone.
Model kaskadowy działa dobrze, jeśli projekt jest powtarzalny i zakłada wykonanie prostego zadania, które jest zdefiniowane w prosty sposób. Teoretycznie, kiedy uznamy za zamknięty etap planowania, np. pisania specyfikacji, nie powinniśmy już do niego wracać. Ale co zrobić, jeśli programista, który przygotowuje program na podstawie specyfikacji zauważy, że danej rzeczy nie da się wykonać albo że konkurencja wymyśliła niedawno lepsze rozwiązanie?
Projekty, nad którymi pracujemy, coraz częściej wymagają szybkiej realizacji i rozwijają się dynamicznie, a model kaskadowy nie zakłada, że coś po drodze może ulec zmianie lub pójść nie po naszej myśli. Jeśli wszystko jest bardzo dokładnie zaplanowane i przemyślane, to model kaskadowy jest użyteczny. Bywa jednak, że to utopijna wizja.
Laboratorium EE stara się realizować projekty w tzw. zwinny (ang. agile) sposób. Na czym polega taki model? Wszystkie etapy projektu są realizowane jednocześnie. Projektowanie, architektura, kod i programowanie postępują równolegle*. Na pierwszy rzut oka może się wydawać, że taki sposób pracy jest pozbawiony sensu – w końcu jak programista miałby np. stworzyć kod do określonej funkcji wspomnianego serwisu bez dokładnej specyfikacji? Okazuje się jednak, że przy określonych założeniach taki sposób pracy jest możliwy.
Ludzie, którzy pracują przy zwinnych projektach muszą być dobrze wyedukowani w kilku dziedzinach. Mają oczywiście swoją główną specjalizację, np. w zakresie projektowania doświadczeń użytkownika, ale ich kompetencje są dużo szersze. Umiejętności osób pracujących nad zwinnymi projektami układają się w kształt litery „T”, gdzie trzonem jest główna umiejętność, a pozostałe tworzą poprzeczny daszek litery.
W modelu kaskadowym zakłada się, że wdrożenie projektu i pokazanie go klientowi to ostatni etap. W przypadku projektów realizowanych w sposób zwinny, iteracja i konsultacje z klientem są częstsze. Kierując np. tworzeniem serwisu do płatności mobilnych w sposób kaskadowy, spędza się pół roku na specyfikacji, pół roku na architekturze, pół na kodowaniu itd. Do momentu pokazania gotowego serwisu nikt dokładnie nie wie, czy realizuje on potrzebę klienta, czy nie. A w projektach zwinnych wszystkie etapy są skumulowane w jednym miejscu, a prezentowanie określonych funkcjonalności jest częstsze.
Zależy nam, żeby jak najszybciej pokazać klientowi to, co stworzyliśmy i zweryfikować, czy zbliżyliśmy się do jego wizji. Wiadomo, że po miesiącu przykładowy serwis internetowy nie działa, ale możemy mieć gotową konkretną funkcjonalność. Chcemy jak najszybciej pokazać działający kod aplikacji (ang. working increment) temu, kto nas zatrudnił. Jeśli coś jest nie tak, będziemy wiedzieć o tym po miesiącu, a nie po roku, kiedy projekt będzie gotowy.
Zwinny model zarządzania ma też inną zaletę. Czasem w trakcie realizowania projektu zmieni się jego cel.
Może się zdarzyć, że w połowie programowania okaże się, że konkurencja wymyśliła podobne rozwiązanie albo że zmieniło się prawo, więc twoja usługa nie będzie już nikomu potrzebna. Musisz więc zaplanować projekt w taki sposób, żeby co pewien czas upewniać się, że wciąż chcesz osiągnąć ten sam cel. Pomaga w tym framework Scrum opisany w drugiej połowie lat 90. Opiera się na tzw. sprintach – odstępach czasu, które dzielą projekt na etapy. Dzięki temu co pewien czas – np. miesiąc albo tydzień – osoby pracujące nad danym rozwiązaniem mogą zastanowić się, czy nadal mają taki sam cel. Zespół zastanawia się, czy w ostatnim czasie zmieniły się warunki projektu i planuje działania na kolejny sprint. Oprócz tego zespół spotyka się codziennie na początku dnia, żeby ustalić cele na najbliższą dobę. – W taki sposób pracuje się szybciej i bardziej systematycznie. Z drugiej strony samo planowanie podczas realizacji zwinnego projektu zajmuje więcej czasu niż przy kaskadowym modelu. Mamy jednak pewność, że to, co stworzy zespół, będzie odpowiadać na potrzebę firmy czy instytucji, nad której projektem pracujemy.
Dowiedz się więcej:
The New New Product Development Game/Harvard Business Review
https://scrum.org/resources
Warsztaty Scrum
Zapraszamy do gry, podczas której nauczymy Was jak projektować doświadczenie zarządzania projektami, jak osiągać biznesowe cele popełniając błędy i jak wyciągać z nich wnioski oraz naukę na przyszłość. To doskonała okazja, by wyzwolić pokłady kreatywności i przekuć je na produktywność - a to wszystko przy użyciu Scruma i klocków Lego.
Chcesz zorganizować warsztaty Scrum w swojej firmie?
Skontaktuj się z nami: kontakt@laboratorium.ee, tel. 734 482 835.
Autor: Michał Durski