Te dwie techniki zarządzania projektami, przez niektórych nazywane metodykami, wypracowane zostały do zarządzania projektami IT. Zarówno zwinne zarządzanie projektami, czyli popularny Agile, jak i klasyczny Waterfall da się jednak bez problemu stosować w projektach z różnorodnych dziedzin. Tworząc je, nikt nie miał jednak na myśli pracy zdalnej. Czy ich założenia na to pozwalają? 

W ostatnim artykule przeprowadziliśmy krótki przegląd podstawowych cech i wymagań różnorodnych stylów zarządzania firmą i możliwości dostosowania ich do pracy zdalnej. Tym razem przyjrzymy się dwóm, bardzo popularnym w tej chwili filozofiom zarządzania projektami.

Na warsztat weźmiemy zwinne zarządzanie projektami oraz Waterfall. Nazywanie ich metodykami nie jest do końca prawidłowe, ponieważ nie oferują Ci szczegółowych wskazówek, jak postępować w takiej czy innej sytuacji projektowej, jak na przykład PRINCE2, nie pozwolą rozpisać szczegółowej mapy drogowej, nie określają np. wymogów odnośnie dokumentacji. 

Czepiamy się słówek, co? No nie do końca. Jeśli bowiem warunki, w których pracujesz, kłócą się z wymogami szczegółowej metodyki, to Ty, obchodząc wymagania i dostosowując postępowanie do możliwości, działasz zwyczajnie niezgodnie z metodyką. Jak wykażemy poniżej, gdyby taki Scrum (jedna z technik zarządzania w nurcie filozofii Agile) był metodyką, nie nadawałby się do stosowania w pracy zdalnej. Jeśli przyjmiemy natomiast – a tak się przyjmuje – że Agile i Waterfall to filozofie, wystarczy, że będziemy trzymać się ich zasad i pryncypiów, dobierając konkretne rozwiązania do sytuacji. W takim przypadku obie te filozofie świetnie sprawdzą się w pracy zdalnej.

Ostatnia uwaga na początek – opisywane filozofie zarządzania mają swój początek w branży IT. Absolutnie nie oznacza to, że nie można ich z powodzeniem stosować w innych branżach. Przeciwnie, z uwzględnieniem specyfiki każdej z nich, sprawdzą się doskonale w każdej branży, w której realizacja projektu oznacza przekazanie klientowi produktu będącego efektem przetwarzania informacji. A więc projektu architektonicznego, katalogu wizerunkowego, księgi znaku itd. Waterfall w dodatku spokojnie nadaje się do realizacji projektów, których efektem jest produkt materialny. Inna sprawa, czy tworzenie takich produktów możliwe jest w warunkach pracy zdalnej.

Waterfall – niezbyt zwinne zarządzanie projektami 

Filozofia Waterfall opracowana została w latach pięćdziesiątych, gdy branża IT zaczęła na poważnie współpracować z wielkim biznesem. Projekty informatyczne miały wówczas wciąż jeszcze charakter laboratoryjny, brak było modeli zarządzania komercyjną produkcją, która miałaby na celu wdrożenie produktu. W celu wypracowania takiego modelu, inżynierowie IT sięgnęli po przykłady do branż, które najłatwiej było im zrozumieć – zaczerpnęli inspirację od innych inżynierów. Czyli skopiowali filozofię zarządzania projektami, efektem których był fizyczny produkt, opracowywany i wdrażany krok po kroku. Tak, jak to ma miejsce w produkcji przemysłowej i budownictwie.

Nazwa Waterfall wywodzi się od “rozpadania się” projektu na poszczególne fazy. Fazy te, jak kaskady, następują jedna po drugiej. Jeśli zespół nie ukończy danej fazy lub też jej rezultaty nie nie są zadowalające, projekt nie przechodzi do następnej fazy – kaskady. Zamiast tego, powtarzana jest ona w kolejnych iteracjach, aż do osiągnięcia założonego celu. Krok po kroku.

Waterfall stawia ogromne wymagania po stronie klienta. Przystąpienie do projektu możliwe jest w praktyce dopiero po sporządzeniu bardzo szczegółowej specyfikacji. Na jej podstawie opracowywany jest szczegółowy plan – sekwencja działań, których efekty są z góry określone. Praca wymaga rygorystycznego trzymania się terminów i prowadzenia szczegółowej dokumentacji każdej kaskady. Oczekiwania klienta od początku muszą być sprecyzowane, ponieważ, kiedy projekt już ruszy, Waterfall nie dopuszcza żadnych zmian. Nie można się też cofnąć do poprzedniej kaskady. Gdyby okazało się, że założenia były wadliwe lub oczekiwania sformułowane nieprawidłowo, cofanie się o kolejne kaskady oznaczałoby właściwie wyrzucenie do kosza efektów wszystkich kolejnych kaskad. Jeśli trzeba by cofnąć się aż do wstępnych założeń, oznaczałoby rozpoczęcie projektu od zera. 

Dodatkowo jakiekolwiek testy działającego oprogramowania (czy też jakiegokolwiek innego produktu) możliwe są dopiero po zakończeniu fazy budowy. 

W filozofii zarządzania Watefall istnieje 8 kaskad:

  1. Faza koncepcyjna
  2. Rozpoczęcie
  3. Analiza
  4. Projektowanie
  5. Budowa
  6. Testy
  7. Produkcja lub wdrożenie
  8. Obsługa

Od tej ścieżki nie ma odstępstw, żadna z faz nie może zostać pominięta lub nieukończona. Jeśli jednak zespół utknie na jednej z kaskad, ryzyko projektu rośnie. Zwinne zarządzanie projektami to to nie jest. 

Waterfall ma również zalety :). Projekt od samego początku stoi na solidnym fundamencie przewidywalności. Na każdej kaskadzie wszystkie działania są bardzo szczegółowo opisane, terminy jasne, można więc w ten sposób realizować bardzo kompleksowe projekty. Klient nigdy nie pozostaje w niepewności co do ostatecznego kształtu dostarczonego mu produktu. Sztywne ramy realizacyjne oznaczają totalną przewidywalność budżetu. Ścisłe trzymanie się specyfikacji, planu oraz dokumentacji dotychczasowych kaskad redukuje nieporozumienia do minimum. Jeśli zaistnieje konieczność zastąpienia członka zespołu, wiedza nie ucieka wraz z człowiekiem, zostaje w organizacji w formie bogatej dokumentacji. Łatwo więc wdrożyć zastępcę.

Waterfall to z pewnością nie jest zwinne zarządzanie projektami. Skrupulatnie przestrzegany, zmienia się jednak w dobrze naoliwioną maszynę, toczącą się do celu w dokładnie określonym tempie i docierającą na czas zgodnie z rozkładem. 

Jasno sprecyzowana, szczegółowo opisana wizja produktu finalnego, sporządzona przez klienta, to wielka rzadkość w świecie IT. W praktyce zdarzyć może się to przy zamówieniach rządowych. IT korzysta z Waterfall, kiedy jest do tego zmuszone, ponieważ tak właśnie wygląda zarządzanie projektami ich klienta. 

W każdej innej branży natomiast, zwłaszcza tam, gdzie do czynienia mamy z materialnym produktem, Waterfall jest dużo popularniejszy i sprawdza się lepiej, niż zwinne zarządzanie projektami. Nic dziwnego, nie da się przy pomocy patcha 1.3 powiększyć schowka pasażera w partii właśnie wyprodukowanych samochodów, lub przesunąć fundamentów nowo budowanej hali fabrycznej. Ponadto, Waterfall opracowany został na użytek IT, jednak wzorem były rozwiązania z przemysłu i budownictwa. 

Jeśli zarządzasz zespołem spoza branży IT i realizujesz skomplikowane projekty, jest spora szansa, że w zarządzaniu projektami kierujesz się tą filozofią. Albo czymś bardzo podobnym, czego podstawową zasadą jest “nie wykonujemy kroku B przed ukończeniem A”. 

W pracy zdalnej

Zwinne zarządzanie projektami, jak zaraz zobaczysz, opiera się na relacjach międzyludzkich i ich bezwzględnie wymaga. Waterfall – już nie tak bardzo. Nie oznacza to oczywiście dystopijnej wizji pracowników odciętych od siebie w cybernetycznych bunkrach :). Jasne, relacje międzyludzkie wymagane są tak w zarządzaniu projektami, jak i na poziomie ogólnego zarządzania firmą. Zwracamy jednak uwagę na to, że w Waterfall pierwsze skrzypce gra szczegółowy plan, procedury, narzędzia i dokumentacja. Przy obecnym poziomie, nawet darmowych, narzędzi wsparcia współpracy online, nie będziesz mieć najmniejszych problemów w zarządzaniu projektami zgodnie z filozofią Waterfall. Jeśli tylko Twoja branża umożliwia, technicznie rzecz ujmując, wytwarzanie produktu bez spotkania się przy taśmie montażowej, na budowie, w warsztacie lub laboratorium.

Co będzie Ci potrzebne? Przede wszystkim, narzędzie do zarządzania projektami. Jeśli tylko nie prowadzisz gigantycznych projektów, wymagających kombajnów typu Microsoft Projects, polecami Asana lub Nozbe. Oba te programy dają Ci ogromną swobodę w doborze filozofii i technik zarządzania projektami – w odróżnieniu od programów takich jak Trello czy Jira, wspierających głównie zwinne zarządzanie projektami.

Wspólną pracę nad dokumentacją umożliwią Ci dyski sieciowe. Komunikacja w zespole to również obecnie żaden problem, zarówno, jeśli chodzi o wideokonferencje, jak i komunikatory biznesowe, umożliwiające ciągłą, jednak nie ingerującą w pracę, komunikację całego Twojego zespołu. Oczywiście ważny jest też dostępny dla wszystkich, zunifikowany kalendarz. 

Jeśli zarządzasz projektem w Waterfall, fundamentem Twojej pracy jest plan, terminy, i dokumentacja. Wszystkie narzędzia, potrzebne do współdzielenia tych kwestii, możesz mieć za darmo. Stosując narzędzie zarządzania projektami, jak Asana czy Nozbe, w połączeniu ze Slack, Zoom, dyskiem sieciowym, jak i zwykłym mailem, dysponujesz wieloma redundantnymi kanałami komunikacji, miejscami składowania danych czy dokumentacji. Jeśli jesteś z branży IT, nie musimy zapewne nawet wspominać o GitHub. 

Jesli tylko sama natura Twojego biznesu to umożliwia, nie istnieją żadne przeszkody do zarządzania Waterfall przy uzyciu narzędzi pracy zdalnej. 

Zwinne zarządzanie projektami – Agile

Skąd wziął się pomysł na Agile? Powstał, kiedy relacje biznesu i IT jasno pokazały, że te dwa światy nie są ze sobą kompatybilne. Projekty IT realizowano wówczas zgodnie z filozofią Waterfall – oprogramowanie powstawało więc długo, testy można było przeprowadzać dopiero na samym końcu procesu, zmian właściwie nie dało się przeprowadzać. Jednym słowem bardzo sztywny proces.

Z drugiej strony, wymagania biznesu zmieniały się co chwila. Nowe pomysły spływały do działów IT wyniku badań rynku, inwencji działów sprzedaży na podstawie feedbacku od klientów lub z inicjatywy działów marketingu. Nic dziwnego zresztą, projekt IT to nie to samo, co budowa, większe i mniejsze zmiany, dodatkowe funkcjonalności i pomysły można spokojnie implementować właściwie w każdym stadium realizacji. 

Biznes oczekiwał więc elastyczności tam, gdzie de facto była ona możliwa. Reżim Waterfall, w którym pracowali wówczas inżynierowie IT, tego akurat jednak nie przewidywał. W efekcie biznes zły był na IT, że nie współpracuje, IT sarkało na biznes, że nie wie, czego chce i tak się to ciągnęło. Dawno temu, zanim Agile stał się filozofią powszechną, sam, na własne oczy, widziałem ogłoszenie, w którym do pracy poszukiwano “normalnego informatyka”, co daje jakieś pojęcie o wzajemnym stosunku biznesu i IT :). 

Trwało to aż do momentu opublikowania przez grupę przedstawicieli świata IT tzw. Agile Manifesto – podstawowego dokumentu filozofii, jaką jest zwinne zarządzanie projektami – i sformułowania 12 zasad Agile. W skrócie sprowadzają się one do kompletnego przewartościowania procesu zarządzania projektem, poprzez postawienie na relacje międzyludzkie i odpowiedź na potrzeby klienta.

Manifest Agile opublikowany został w następującej treści :

“Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy zaczęliśmy bardziej cenić:

ludzi i interakcje od procesów i narzędzi,

działające oprogramowanie od szczegółowej dokumentacji,

współpracę z klientem od negocjacji umów,

reagowanie na zmiany od realizacji założonego planu.

Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.”

Twórcy Manifestu doszli więc do wniosku, że więcej pożytku przynoszą zwykłe relacje nastawionych na realizację celu ludzi po obu stronach układu biznes – IT, niż kurczowe trzymanie się procedur. Co więcej, współpraca powinna zdążać do celu, nie zaś polegać na wytykaniu sobie zapisów umowy. Klient ma prawo zmieniać swoje wymagania, ponieważ ostatecznie to on najlepiej wie, czego potrzebuje do osiągnięcia celu biznesowego, a przecież nie jest informatykiem i niekoniecznie musiał z góry przewidzieć, jak będzie wyglądał zarówno proces tworzenia, jak i samo narzędzie. Ostatecznym celem współpracy jest zaś dostarczenie klientowi działającego programu, nie zaś rozbudowanych specyfikacji. 

Jeśli jesteś, niezależnie od branży, managerem zespołu lub właścicielem firmy, prawdopodobnie czujesz już, jak na karku ostrzegawczo jeży Ci się włos. Cóż, poniekąd słusznie. Fajnie jest, z perspektywy zanurzonego w pracy twórczej inżyniera, radośnie wyrzucić stertę dokumentacji za okno i oddać się słodyczy tworzenia, w tandemie z klientem, zupełnie nie przejmując się ramami kontraktu i przepalaniem nielimitowanych roboczogodzin. Dla właściciela firmy pachnie to bankructwem.

Czas pokazał, że prawda leży pośrodku. To nie tak, że kontrakt jest nieważny. Kontrakt musi przewidywać dużą ilość zmian i powstawanie produktu w iteracjach. Dokumentacja ostatecznie jest ważna, ponieważ można bez niej oddać produkt, nie bardzo jednak można go utrzymać. Interakcje zaś, bez procesów i narzędzi, zmieniają się w pogaduchy. Więc tak, warto być elastycznym, jednak to nie tak, że “elementy wypisane po prawej” są bez znaczenia. Raczej, powinny uwzględniać bardzo mocno prokliencki sposób zarządzania projektem.

Dla pełnego obrazu sytuacji podajmy też 12 uzupełniających zasad Manifestu Agile:

  1. Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.
  2. Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.
  3. Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.
  4. Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.
  5. Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.
  6. Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.
  7. Działające oprogramowanie jest podstawową miarą postępu.
  8. Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.
  9. Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.
  10. Prostota — sztuka minimalizowania ilości koniecznej pracy — jest kluczowa.
  11. Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.
  12. W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.

Na pierwszy rzut oka widać, że zwinne zarządzanie projektami wygląda jak proces wzajemnej nauki i ciągłego testowania rozwiązań cząstkowych przez biznes i IT. Oznacza to, że zaczynając realizację, obie strony nie do końca tak naprawdę wiedzą, jaki będzie efekt. Brzmi nieprofesjonalnie? Takie są jednak jak najbardziej profesjonalne realia w większości niematerialnych realizacji biznesowych – jasny jest cel biznesowy i mniej więcej środki. Dopiero w trakcie współpracy w pełni ujawnia się potencjał tkwiący w pomyśle klienta, a to dlatego, że nie jest on informatykiem i nie wie, jakie tak naprawdę możliwości ma do dyspozycji, IT zaś nie wie od razu, jakie rozwiązania najlepiej przysłużą się celom biznesowym Klienta. Do zupełnej rzadkości należą sytuacje, w których Klient dostarcza szczegółową, do ostatniego przecinka, dokumentację zamawianego produktu. Musiałby ona zostać bowiem stworzona przez ekspertów. Pytanie więc, dlaczego to firma zewnętrzna, nie zaś owi eksperci, mieliby realizować projekt, skoro już tyle czasu poświęcili na zaplanowanie go tak, aby działał dokładnie w przewidziany sposób.

W tym miejscu przypominamy – zwinne zarządzanie projektami wyszło ze świata IT. Możesz jednak kierować się tą filozofią, zarządzając dowolnym projektem, którego efekt polega na przetworzeniu informacji.

W pracy zdalnej

Być może zastanawiasz się, dlaczego podkreśliliśmy w tekście punkt 6 uzupełniających zasad Agile Manifesto. Rozmowa twarzą w twarz. Dlatego właśnie na wstępie zaznaczyliśmy, że zwinne zarządzanie projektami jest filozofią, nie metodyką. Gdyby to była metodyka, nie byłoby sensu pisać tego artykułu, praca zdalna odpada na wstępie. 

Pójdźmy dalej. Jedną z technik zarządzania projektami Agile jest Scrum, o którym być może również napiszemy osobny artykuł. Scrum jest techniką opartą na ścisłej kolaboracji członków zespołu pracujących w danym momencie tylko nad jednym projektem, a jednym z jego ważniejszych elementów jest tzw. Daily Standup. Daily Standup to odbywające się codziennie spotkanie członków zespołu, na którym omawiany jest postęp w realizacji projektu, mierzony konktretnymi efektami, tym, co zostało zrobione dnia poprzedniego. I znów, technika Scrum zakłada, że zespół spotyka się twarzą w twarz.

Na szczęście, to tylko wytyczne. Pamiętaj, nie chodzi o to, czy zobaczysz się z członkami zespołu w jednym pokoju, staniecie w kółku czy usiądziecie przy stole. Istotne jest zachowanie takiego kontaktu, który umożliwi rzetelne przeprowadzenie oceny postępu prac z minionego dnia.

Czy możesz w tym celu przeprowadzić wideokonferencję? Absolutnie tak. Jak najbardziej to polecamy, ponieważ widok twarzy rozmówców, zwłaszcza w sytuacji stresowej, jaką jest – bądź co bądź – ocena postępów prac, jest istotny. Komunikacja nabiera pełnego, emocjonalnego kontekstu, swoją bezcenną rolę odegrać może zachęcający uśmiech prowadzącego spotkanie (Scrum Mastera na przykład, jeśli używasz tej techniki). Atmosfera się rozładowuje.

Zwinne zarządzanie projektami na też to do siebie, że z czasem wszyscy uczestnicy projektu uczą się, jak wykonywać swoją rolę w nim lepiej. Oznacza to, że wszyscy wiedzą coraz lepiej, co mają robić. Z czasem możesz zrezygnować z wideokonferencji i przeprowadzać je tylko przy naprawdę większych okazjach jak  Przegląd produktu, czyli przekazanie, na danym etapie, działającego oprogramowania, z udziałem klienta. Do codziennej komunikacji czy nawet Daily Standupów uzywać możesz komunikatorów firmowych takich jak Slack, czy Microsoft Teams.

Najistotniejsze jednak, tak jak w przypadku Waterfall, będzie dla Ciebie narzędzie w postaci programu do zarządzania projektami. Oczywiście, istnieją tu narzędzia wyspecjalizowane we wspieraniu zwinnego zarządzania projektami. Na przykład Jira. Jira posiada ogromną ilość funkcjonalności wspierających technikę Scrum. Potrzebujesz narzędzia wsparcia do Daily Standup? Nie ma problemu, producenci Jira stworzyli specjalny poradnik, w jaki sposób używać programu, aby efektywnie przeprowadzić codzienną ewaluację postępów prac. Nie wspominając o tym, że społeczność, zgromadzona wokół Jira, również ma na to masę patentów.

Wniosek jest więc taki, że przy obecnym stanie zaawansowania narzędzi do zarządzania projektami i komunikacji, jesteś w stanie efektywniej zarządzać projektami w sposób zwinny, w zdalnym teamie, teraz, niż bez tych narzędzi, w biurze, jeszcze 10 lat temu. Zwinne zarządzanie projektami wymaga interakcji wysoce zmotywowanych, kompetentnych ludzi. Jeżeli masz takich ludzi, interakcja nie jest żadnym problemem, odkąd odległość stała się fikcją.