Alternatywa dla Asany w harmonogramie projektu

Kiedy oś czasu w Asanie przestaje być harmonogramem

Większość tekstów o alternatywach dla Asany zaczyna się od zdania, że Asana nie ma wykresu Gantta. To po prostu nieprawda, a od fałszywej przesłanki trudno przejść do sensownej rady. Asana ma widok osi czasu: rysuje paski, łączy je strzałkami, oznacza kamienie milowe rombami i na życzenie podświetla ścieżkę krytyczną. Do kampanii marketingowej, premiery produktu albo procesu rekrutacji to zupełnie rozsądny sposób planowania.

Pytanie brzmi inaczej. Nie o to, czy wykres istnieje, ale czy stoi za nim model harmonogramu, czyli zestaw reguł, które system stosuje, gdy coś się przesunie. Wykres bez modelu jest obrazkiem planu. Wykres z modelem jest planem. Różnicę widać dopiero wtedy, gdy rzeczywistość zaczyna napierać na terminy, a to zwykle dzieje się w trzecim tygodniu, nie w dniu zatwierdzenia planu.

Co Asana robi dobrze

Asana świetnie uwidacznia pracę i skłania ludzi do jej wykonywania. Zadanie ma właściciela, komentarze i czytelny termin, paski na osi czasu łatwo się przesuwa, a zadania zależne idą za poprzednikiem. Zależności opisano językiem, którego nikt nie musi się uczyć, blokuje i jest zablokowane przez, dlatego zespół wdraża się w jedno popołudnie. Dla dziesięciu osób prowadzących ośmiotygodniową kampanię to nie żaden kompromis, tylko dokładnie tyle narzędzia, ile potrzeba.

Warto tylko zobaczyć, czym ta prostota jest opłacona. Każda możliwość, której Asana nie wpuściła na oś czasu, utrudniłaby naukę produktu, a dla większości jej użytkowników to jest właściwy wybór. Zostaje pytanie, co dzieje się z zespołami, dla których nie jest.

Moment, w którym plan przestaje liczyć się sam

Ten moment przychodzi niepostrzeżenie. Dostawca potwierdza dostawę dwa tygodnie później, niż zakładano, więc kierownik projektu przesuwa jedno zadanie. Bezpośredni następnik idzie za nim, bo to powiązanie jest zapisane. Chwilę później okazuje się, że odbiory zaplanowane po obowiązkowym dwutygodniowym okresie dojrzewania zaczynają się teraz za wcześnie, bo odstęp między tymi zadaniami nigdy nie był regułą, tylko pustym miejscem na wykresie. Zadanie w sąsiednim projekcie, które miało ruszyć po tej dostawie, nie drgnęło, bo oba projekty nic o sobie nie wiedzą. Pół godziny później kierownik przeciąga paski ręcznie i sprawdza daty w Excelu.

Właśnie wtedy harmonogram przestaje być modelem. Planu nie pilnuje już system, tylko człowiek, a człowiek jest pojedynczym punktem awarii. Każde przeplanowanie kosztuje godziny, każda z tych godzin nie idzie na rozwiązanie problemu, a po trzeciej albo czwartej rundzie ludzie przestają aktualizować plan, bo wysiłek się nie zwraca. Porzucony harmonogram jest gorszy od żadnego, bo raporty nadal się z niego robi.

Pięć sygnałów, że wyrosłeś z harmonogramu w Asanie

Żaden z tych sygnałów nie ma nic wspólnego z wielkością zespołu ani budżetem. Wszystkie wynikają z charakteru pracy i dlatego dwunastoosobowy zespół inżynierski trafia na nie regularnie, a sześćdziesięcioosobowy marketing nigdy. Jeśli dwa albo więcej opisują Twoje projekty, wąskim gardłem jest harmonogram, a nie liczba funkcji w narzędziu.

Planujesz w dniach roboczych, nie kalendarzowych. Pięciodniowe zadanie rozpoczęte w czwartek powinno skończyć się w kolejną środę, a święto w środku przesuwa koniec o jeszcze jeden dzień. Jeśli czas trwania po cichu wlicza weekendy, każde oszacowanie ma wbudowany błąd, a w planie na kilka miesięcy te błędy się dodają.

Część przerw w planie wynika z technologii, nie z uzgodnień. Beton dojrzewa, powłoka schnie, trwa walidacja, biegnie okres wypowiedzenia, urząd ma trzydzieści dni na odpowiedź. Nikt tego nie wykonuje, to są odstępy, które muszą minąć między dwoma zadaniami. Zespoły, które nie mają jak ich zapisać, dorabiają zadania w rodzaju „oczekiwanie na decyzję”, a potem te atrapy zaśmiecają listę zadań i przekłamują każdy raport.

Harmonogram jednego projektu warunkuje drugi. Jeśli dostawa w projekcie infrastrukturalnym otwiera start projektu migracyjnego, a każdy z nich prowadzi ktoś inny, to ta zależność siedzi w czyjejś pamięci. Pamięć nie wysyła powiadomień i nie przeżywa dwutygodniowego urlopu.

Dostajesz pytanie o odchylenie od pierwotnego planu. Nie o aktualne terminy, ale o to, jak wypadają wobec zatwierdzonych i skąd wzięła się różnica. Bez planu bazowego uczciwa odpowiedź brzmi: nie wiemy, a wersja pokazana na Komitecie Sterującym jest odtworzona z pamięci.

Harmonogram potrzebuje więcej niż dwóch poziomów. Fazy, w nich etapy, w nich zadania, z postępem liczonym w górę i własnymi terminami na każdym poziomie. Płaska lista z nagłówkami sekcji wygląda na ekranie podobnie i zachowuje się zupełnie inaczej, kiedy trzeba coś przesunąć.

Typy relacji i dlaczego decydują o całym planie

Zależność nie jest linią między dwoma paskami. Jest regułą, którą system stosuje za każdym razem, gdy któryś koniec się przesunie, a typ relacji określa treść tej reguły. Ten fragment większość porównań pomija, bo ptaszek przy „zależności między zadaniami” zaciera różnicę między narzędziem, które przerysowuje strzałki, i narzędziem, które przelicza daty. FlexiProject i Asana obsługują te same cztery typy, więc ciekawe jest to, co je otacza.

Precyzja nie jest tu celem samym w sobie. Decyduje o tym, czy na pytanie „jeśli to się przesunie o tydzień, kiedy kończymy” kierownik projektu odpowie w trzy sekundy, patrząc na wykres, czy w trzy godziny, odbudowując plan. Gdy o tych samych ludzi biją się trzy projekty, od tej różnicy zależy, czy przeplanowanie w ogóle nastąpi.

FS, SS, FF i SF w praktyce

Zakończenie-rozpoczęcie jest domyślne i obsługuje większość pracy po kolei: ścianę trzeba postawić, żeby ją pomalować. Rozpoczęcie-rozpoczęcie opisuje prace idące równolegle od wspólnego momentu, na przykład dokumentację, która startuje razem z pracami programistycznymi i trzyma z nimi rytm. Zakończenie-zakończenie opisuje prace, które muszą skończyć się razem, jak szkolenia użytkowników gotowe na dzień uruchomienia systemu, niezależnie od tego, kiedy się zaczęły. Rozpoczęcie-zakończenie jest rzadkie i pojawia się głównie przy przełączeniach, gdy stary system wolno wyłączyć dopiero wtedy, gdy nowy już działa.

Kto planuje serio, sięgnie po co najmniej trzy pierwsze, a dojrzałe organizacje projektowe używają wszystkich czterech, bo dzięki temu plan odwzorowuje rzeczywistość, a nie wciska jej w jeden długi łańcuch. Jeśli potrzebujesz rozwinięcia z przykładami, opisaliśmy osobno rodzaje zależności zadań na wykresie Gantta.

Stałe opóźnienie, czyli dni, które muszą minąć

We FlexiProject do każdej relacji można dopisać stałe opóźnienie w dniach. Zależność znaczy wtedy: zacznij to zadanie cztery dni po zakończeniu poprzedniego. Te cztery dni są częścią reguły, a nie odstępem odmierzonym okiem na wykresie, więc kiedy poprzednik się przesuwa, opóźnienie przesuwa się razem z nim i nikt nie musi pamiętać, że w ogóle było.

Praktycznie znaczy to, że ograniczenia technologiczne wychodzą z ludzkich głów i wchodzą do planu. Okres dojrzewania, termin na decyzję urzędu, kwarantanna między partiami produkcyjnymi, okres wypowiedzenia w umowie z podwykonawcą. Nikt nie zakłada już atrapy, żeby zarezerwować miejsce w harmonogramie, nikt nie tłumaczy koledze, dlaczego dwóch pasków nie wolno do siebie dosunąć, i żadne przeplanowanie nie skasuje po cichu ograniczenia, którego skasować nie można. W projektach, w których pomylona kolejność oznacza poprawki, a nie spóźniony mail, to jest różnica między planem, któremu się wierzy, i planem, który trzeba sprawdzać.

Relacja twarda, czyli kiedy powiązania nie wolno rozerwać

FlexiProject rozróżnia dodatkowo relacje twarde, oznaczone w panelu zadania dwoma splecionymi pierścieniami. Relacja twarda oznacza, że powiązanego elementu nie da się ręcznie oderwać od poprzednika. System nie pozwoli rozerwać sekwencji przeciągnięciem paska, co brzmi restrykcyjnie do momentu, w którym zobaczy się harmonogram rozjeżdżający się przez pół roku pod wpływem drobnych, dobrze intencjonowanych poprawek.

Największe znaczenie ma to tam, gdzie harmonogram jest dokumentem wspólnym, a nie plikiem jednej osoby. W dużym projekcie plan edytuje kilka osób i każda ma swój lokalny powód, żeby coś przesunąć. Relacja twarda zapisuje różnicę między kolejnością, która jest założeniem i podlega dyskusji, oraz kolejnością, która jest twardym ograniczeniem i nie podlega. Kierownik projektu przestaje pilnować planu i zaczyna z niego korzystać, a po to się w ogóle kupuje takie narzędzie.

Relacje między projektami, czyli warstwa, której Asana nie ma

W jednym projekcie zależności są wygodą. Między projektami są różnicą między programem a katalogiem osobnych planów. We FlexiProject relacja może połączyć zadanie z jednego projektu z zadaniem z drugiego, więc dostawa, która otwiera migrację, jest powiązaniem znanym systemowi, a nie zdaniem w protokole ze spotkania. Kiedy termin po jednej stronie się przesuwa, zależne zadania w drugim projekcie zostają przeliczone, a ich właściciele dostają powiadomienie.

Skutek widać nie na wykresie, tylko w decyzjach. Przed zatwierdzeniem zmiany w jednym projekcie kierownik programu widzi, jak rozejdzie się ona po pozostałych, może porównać harmonogram przed i po i ocenić, ile naprawdę kosztuje zgoda. Bez tego koszt wychodzi tygodnie później jako seria osobnych niespodzianek, z których każda wygląda na problem lokalny i tak też bywa załatwiana. W programach rozciągniętych na lata to się kumuluje najmocniej, bo dwutygodniowa decyzja podjęta lekką ręką w trzecim miesiącu potrafi przesunąć uruchomienie w dwudziestym.

Wszystkie zadania programu widać też na jednym wspólnym wykresie Gantta, więc kierownik programu ogląda powiązania w jednym miejscu, zamiast składać je z raportów statusowych. Zespoły, które tego potrzebują, zwykle dowiadują się o tym po fakcie, próbując najpierw ogarnąć to samo cyklicznym spotkaniem. Jeśli Twoja organizacja idzie w tę stronę, nasze oprogramowanie do zarządzania programami projektów pokazuje, jak układa się programy.

Co siedzi pod wykresem Gantta

Relacje to najbardziej widoczna część modelu, ale nie cała. O tym, czy wykres zachowuje się jak plan, decydują jeszcze cztery mechanizmy i to one oddzielają oprogramowanie do wykresów Gantta od widgetu z osią czasu. Żaden z nich nie jest egzotyczny. Każdego zaczyna brakować dopiero w momencie, w którym jest potrzebny.

Nielimitowany WBS i postęp liczony automatycznie

Projekty w jednej firmie różnią się skalą ogromnie, od dwutygodniowego quick winu po wieloletnią inwestycję, i jedna sztywna struktura nie obsłuży obu końców. FlexiProject nie ogranicza liczby poziomów struktury zadań, więc projekt można podzielić na fazy, etapy, zadania i kamienie milowe tak głęboko, jak trzeba. Mały projekt zostaje płaski, z kilkoma zadaniami, duża inwestycja dostaje wielopoziomowy WBS, a interfejs jest ten sam.

Postęp wpisuje się tylko na poziomie pojedynczych zadań. Postęp etapów i całego projektu system liczy sam, więc nikt nie musi pamiętać o zaktualizowaniu agregatów przed wysłaniem raportu. Brzmi jak drobne udogodnienie, a jest mechanizmem jakości danych: status na poziomie portfela bierze się z tych samych liczb, które zespół prowadzi na bieżąco, a nie z podsumowania wklepanego wieczorem przed Komitetem.

Kalendarz dni roboczych zamiast dat kalendarzowych

Harmonogram, który traktuje weekend jako czas pracy, ma błędne daty od pierwszego dnia. FlexiProject liczy czas trwania na kalendarzu dni roboczych, więc zadanie zaplanowane na pięć dni ląduje tam, gdzie faktycznie ląduje, po odjęciu weekendów i dni wolnych. Ta sama logika stoi za szablonami: zadania w szablonie mają czas trwania w dniach roboczych i zależności zamiast sztywnych dat, więc wystarczy podać datę startu projektu, żeby cały harmonogram wyliczył się automatycznie.

W firmie, która prowadzi powtarzalne projekty, właśnie tu znika najwięcej czasu na planowanie. Kierownik projektu nie odtwarza planu od zera i nie wyprowadza każdej daty na nowo, tylko startuje z zatwierdzonej struktury i poprawia to, co w tej odsłonie jest naprawdę inne. Do tego służy nasz moduł szablonów projektów i to również powód, dla którego szablony przygotowane przez doświadczone PMO nie tracą wartości przez lata.

Plan bazowy i odchylenie od planu

Po zatwierdzeniu planu FlexiProject zachowuje go jako plan bazowy. Na wykresie Gantta widać wtedy równolegle plan pierwotny i harmonogram aktualny, więc odchylenie widzi się od razu, zamiast je wnioskować. System pokazuje też prognozę daty zakończenia projektu wobec daty zatwierdzonej, a to zwykle jedyna liczba, o którą naprawdę pyta Zarząd.

Wartość jest tu mniej w samym pomiarze, a bardziej w tym, jak wygląda rozmowa. Kierownik projektu, który pokazuje, co zostało zatwierdzone, jak jest teraz i która decyzja zrobiła różnicę, stoi zupełnie inaczej niż ten, który potrafi zaraportować wyłącznie aktualne terminy. Dyskusja przenosi się z pytania, czy projekt się spóźnia, na pytanie, co zrobić z konkretną przyczyną, a tylko taka rozmowa kończy się decyzją.

Ścieżka krytyczna i zapas

FlexiProject sam wyznacza ścieżkę krytyczną i zaznacza ją na czerwono na wykresie Gantta, więc kierownik projektu od razu wie, czego pilnować. Przydaje się to przy segregowaniu problemów. Dwa dni poślizgu na zadaniu krytycznym to dwa dni poślizgu całego projektu, a dwa dni na zadaniu z dziesięciodniowym zapasem to szum. Bez tego rozróżnienia każde opóźnienie eskaluje się z tą samą pilnością, a to szybko uczy wszystkich, żeby eskalacje ignorować.

Przy kilku równoległych nurtach, na przykład budowie idącej obok instalacji i dokumentacji, ścieżka krytyczna powstrzymuje kierownika od optymalizowania nie tego nurtu, co trzeba. Jeśli pojęcie jest dla zespołu nowe, opisaliśmy szerzej, czym jest ścieżka krytyczna i jak nią zarządzać.

Zasoby na wykresie Gantta, czyli terminy i dostępność razem

Harmonogram, który nie patrzy na dostępność ludzi, jest listą życzeń. FlexiProject pokazuje obciążenie zasobów wprost z wykresu Gantta, więc jednym spojrzeniem widać, kto w danym okresie jest przeciążony, a kto ma jeszcze wolne moce. Zadania da się przesuwać po osi czasu i równocześnie patrzeć, jak zmienia się obciążenie, więc przeplanowanie jest symulacją, a nie zgadywaniem: plan optymalizuje się przed zatwierdzeniem, a nie po tym, jak ktoś zaprotestuje.

Domyka to lukę, którą widać w każdej firmie prowadzącej kilka projektów tymi samymi ludźmi. Żeby zaplanować nowy projekt, trzeba wiedzieć, czy potrzebni specjaliści nie są już zajęci gdzie indziej, a w większości firm sprawdza się to ręcznie, w arkuszu, z opóźnieniem wystarczającym, żeby odpowiedź zdążyła się zestarzeć. Kiedy dostępność jest w tym samym widoku co terminy, wybór między szybszym zakończeniem i przeciążeniem zespołu przestaje być niewidoczny do dnia, w którym ktoś składa wypowiedzenie.

Opóźnienia widać równie wprost. Zadania po terminie podświetlają się na czerwono, więc wystarczy otworzyć projekt, żeby zobaczyć, gdzie potrzebna jest interwencja, bez generowania raportu. Firmom, które chcą pójść dalej i patrzeć na dostępność w całym portfelu, służy nasze oprogramowanie do zarządzania zasobami, obejmujące obciążenie ponad pojedynczym projektem.

FlexiProject a Asana: porównanie możliwości harmonogramowych

Tabela jest celowo wąska. Dotyczy tylko harmonogramu i przyznaje Asanie wszystko, co faktycznie ma, bo zestawienie zaniżające konkurenta jest bezużyteczne dla czytelnika. Współpraca, automatyzacja przepływów i integracje to inna rozmowa, a w części z nich Asana wypada mocniej.

Tabelę warto czytać jako opis zamysłu, nie jako wynik meczu. Asana jest zrobiona tak, żeby każdy zaplanował pracę bez szkolenia, a każda pominięta wyżej możliwość utrudniłaby naukę produktu. FlexiProject godzi się na trudniejszy start w zamian za harmonogram, który wytrzymuje zmiany. Który wybór jest właściwy, zależy wyłącznie od tego, czy Twoje projekty karzą za nieprecyzyjny plan.

Jak przenieść harmonogram z Asany i nie zgubić planu

Mechanika migracji zajmuje mniej czasu, niż się wydaje. Harmonogram importuje się z pliku Excel albo z pliku Microsoft Project, razem z zadaniami, właścicielami, dostępnymi atrybutami i, jeśli są, strukturą zależności, więc firma siedząca na latach starych planów nie musi ich przepisywać. Eksport działa w drugą stronę, do Excela, formatu XML dla Microsoft Project, PDF i PNG, co przydaje się w chwili, gdy wykonawca albo audytor upiera się przy konkretnym formacie.

Przemyślenia wymaga natomiast przemodelowanie planu. Harmonogram zbudowany w Asanie powstawał pod jej ograniczeniami, więc okresy oczekiwania są prawdopodobnie atrapami, kolejność jest jednym długim łańcuchem zakończenie-rozpoczęcie, a fazy to nagłówki sekcji. Przepisanie tego wiernie odtwarza ograniczenie w systemie, który go już nie ma. Lepiej wziąć jeden reprezentatywny projekt, ułożyć jego logikę porządnie, z właściwymi typami relacji, stałym opóźnieniem tam, gdzie odstęp jest obowiązkowy, i relacjami twardymi tam, gdzie kolejność nie podlega negocjacji, a potem zapisać wynik jako szablon dla kolejnych.

Na pierwsze podejście jest skrót. FlexiProject potrafi wygenerować wstępny harmonogram z opisu celów i wymagań projektu, razem z zadaniami, kamieniami milowymi, zależnościami i wykresem Gantta, więc kierownik projektu edytuje gotowy szkielet, a nie buduje od zera. Nie zastąpi to doświadczonego planisty, ale usuwa problem pustej kartki, na którym grzęźnie większość przeplanowań. Jeśli wolisz uporządkowane przejście przez ten proces, opisaliśmy, jak stworzyć harmonogram projektu krok po kroku.

Najczęstsze pytania

Czy Asana obsługuje wszystkie cztery typy zależności?

Tak. Asana obsługuje zakończenie-rozpoczęcie, zakończenie-zakończenie, rozpoczęcie-rozpoczęcie i rozpoczęcie-zakończenie, przy czym pierwszy jest domyślny. Twierdzenie, że Asana ma tylko jeden typ zależności, krąży po wielu porównaniach i jest nieaktualne. Prawdziwe braki w jej harmonogramie leżą gdzie indziej: w stałym opóźnieniu, relacjach twardych, kalendarzu dni roboczych, planie bazowym i powiązaniach między projektami.

Czy w Asanie da się ustawić opóźnienie między zadaniami?

Nie. Asana nie pozwala dopisać stałego opóźnienia do zależności, więc obowiązkowy odstęp trzeba pokazać inaczej, zwykle pustym miejscem na osi czasu albo dorobionym zadaniem. Oba obejścia rozpadają się przy pierwszym przesunięciu poprzednika, bo żadne nie zabiera opóźnienia ze sobą. We FlexiProject opóźnienie jest cechą samej relacji i podaje się je w dniach.

Czy Asana ma plan bazowy projektu?

Nie. Asana nie przechowuje zatwierdzonej wersji harmonogramu, więc nie ma wbudowanego sposobu, żeby sprawdzić, jak daleko aktualny plan odjechał od pierwotnych ustaleń. Zespoły, które tego potrzebują, trzymają zwykle zrzut w arkuszu, co odpowiada na pytanie raz, a potem się starzeje. FlexiProject zachowuje zatwierdzony plan jako plan bazowy i pokazuje go na wykresie Gantta obok harmonogramu aktualnego.

Czy można powiązać zadania z dwóch różnych projektów?

W Asanie nie. Zależności zostają w obrębie jednego projektu, więc kolejność między projektami muszą pilnować ludzie, zamiast trzymać ją system. We FlexiProject relację między zadaniami z różnych projektów da się utworzyć, terminy zależne przeliczają się przy przesunięciu którejkolwiek strony, a właściciele dostają powiadomienie. To warunek zarządzania programem, a nie zbiorem równoległych projektów.

Czy FlexiProject jest trudniejszy w obsłudze niż Asana?

Wymaga więcej na starcie i mniej później. Asanę można ogarnąć pierwszego dnia, między innymi dlatego, że nie ma w niej pojęć opisanych w tym artykule. FlexiProject oczekuje od kierownika projektu rozumienia typów relacji, kalendarza dni roboczych i planu bazowego, a w zamian pilnuje planu, zamiast prosić o to człowieka. Przy prostych projektach Asana będzie szybsza. Przy projektach, w których nieprecyzyjny plan kosztuje, zwykle jest odwrotnie.

Wybór alternatywy dla Asany w harmonogramie projektu nie jest tak naprawdę wyborem między dwoma narzędziami. To decyzja o tym, czy plan ma pilnować człowiek, czy system, a to zależy od ceny błędnego terminu. Jeśli przesunięty termin oznacza przełożone spotkanie, Asana jest dobrą odpowiedzią i dokładanie do niej maszynerii harmonogramowej tylko spowolni zespół. Jeśli przesunięty termin oznacza bezczynnych wykonawców, przegapione okno formalne, poprawki na linii albo karę umowną, to model pod wykresem nie jest szczegółem. To jest właśnie produkt.

Zmiana, jaką daje pełny model harmonogramu, wygląda drobniej niż lista funkcji i waży więcej, niż się wydaje. Relacje niosą stałe opóźnienia, więc obowiązkowe odstępy są w planie, a nie w czyjejś pamięci. Relacje twarde trzymają kolejność, która nie podlega negocjacji. Zależności sięgają między projekty, więc program zachowuje się jak program. Kalendarz dni roboczych sprawia, że czas trwania znaczy to, co mówi, plan bazowy pokazuje odchylenie, a ścieżka krytyczna mówi, które opóźnienia mają znaczenie. Osobno wyglądają jak drobiazgi. Razem są różnicą między przeplanowaniem w kilka minut i przeplanowaniem przez weekend.

Jeśli chcesz zobaczyć oba narzędzia obok siebie w pełnym zakresie, nie tylko w harmonogramie, razem z budżetami, ryzykami, kartą projektu i nadzorem nad portfelem, przygotowaliśmy szczegółowe porównanie FlexiProject i Asany. A jeśli Twoje projekty już ocierają się o opisane wyżej granice, najlepszym następnym krokiem będzie wzięcie jednego z nich, ułożenie harmonogramu od nowa i sprawdzenie, ile ręcznej pracy z niego zniknie.