Zadanie czeka trzy dni, bo osoba, która ma je wykonać, sama czeka na inne zadanie od kogoś innego. Nikt tego nie zauważył, bo nikt tej zależności nigdy nie zapisał. To najczęstszy scenariusz, przez który zarządzanie zależnościami między zadaniami w projekcie okazuje się ważniejsze niż samo planowanie kolejności pracy.
Zależności między zadaniami istnieją w każdym projekcie, niezależnie od jego wielkości. Problem pojawia się wtedy, gdy zespół ich nie widzi - wtedy blokady wychodzą na jaw dopiero w dniu, w którym miały zniknąć.
W tym artykule pokażę, jakie rodzaje zależności występują w projektach, jak je identyfikować zanim staną się problemem i jak zarządzać nimi na co dzień, żeby jedno opóźnione zadanie nie zatrzymywało całego zespołu.
Czym są zależności między zadaniami w projekcie
Zależność to sytuacja, w której wykonanie jednego zadania jest uzależnione od stanu innego zadania. Najprostszy przykład: programista nie może zacząć testów integracyjnych, dopóki druga osoba nie skończy implementacji API, z którym te testy mają się komunikować.
Zależności bywają oczywiste, jak w powyższym przykładzie, ale często są ukryte - dotyczą decyzji biznesowych, dostępności zasobów albo zewnętrznych dostawców. To właśnie te ukryte zależności najczęściej powodują niespodziewane opóźnienia.
Rodzaje zależności między zadaniami
Koniec-start - najczęstszy typ. Zadanie B może zacząć się dopiero, gdy zadanie A zostanie zakończone. Przykład: projekt graficzny musi być gotowy, zanim zespół frontendowy zacznie implementację interfejsu.
Start-start - dwa zadania mogą ruszyć równolegle, ale jedno musi się zacząć, żeby drugie mogło wystartować. Przykład: testy manualne mogą zacząć się równolegle z pisaniem dokumentacji, o ile obie prace startują od tego samego commita.
Koniec-koniec - dwa zadania muszą zakończyć się w tym samym momencie, choć mogą trwać różnie długo. Przykład: tłumaczenie treści na stronę musi być gotowe dokładnie wtedy, gdy kończy się wdrożenie nowej wersji strony.
Start-koniec - najrzadszy typ, ale zdarza się przy przekazywaniu obowiązków, na przykład stary system może zostać wyłączony dopiero, gdy nowy system zacznie działać.
Dlaczego zależności powodują opóźnienia
Problem nie leży w samym istnieniu zależności - to naturalna część pracy zespołowej. Problem pojawia się, gdy zależność nie jest nigdzie zapisana i zespół dowiaduje się o niej dopiero, gdy zadanie utknie.
Drugi częsty powód to niedoszacowanie czasu na zadanie blokujące. Jeśli zespół zakłada, że przygotowanie środowiska testowego zajmie dzień, a w praktyce zajmuje trzy, wszystkie zadania zależne przesuwają się automatycznie - często bez wcześniejszego ostrzeżenia osób, których to dotyczy.
Jak identyfikować zależności zanim staną się problemem
Mapowanie zależności na starcie projektu
Na etapie planowania warto przejść przez listę większych zadań i zadać jedno pytanie: co musi się wydarzyć, zanim to zadanie będzie mogło się zacząć? Odpowiedzi na to pytanie tworzą pierwszą mapę zależności, jeszcze zanim zespół zacznie pracę.
Przykład: agencja wdrażająca system CRM dla klienta ustala na starcie, że migracja danych musi zakończyć się przed rozpoczęciem szkoleń użytkowników. Ta jedna zależność zmienia całą kolejność prac w harmonogramie.
Oznaczanie zadań blokujących w codziennej pracy
Mapowanie na starcie projektu to za mało - nowe zależności pojawiają się na bieżąco. Dlatego warto, żeby każde zadanie, które blokuje inne, było wyraźnie oznaczone w narzędziu, z którego korzysta zespół, a nie tylko wspominane ustnie na spotkaniu.
Dzięki temu, gdy zadanie blokujące się opóźnia, wszystkie osoby czekające na nie widzą to od razu, zamiast dowiadywać się o problemie dopiero na planowaniu kolejnego sprintu.
Jak wizualizować zależności, żeby zespół je widział
Lista zależności zapisana w osobnym dokumencie szybko traci aktualność, bo nikt nie zagląda do niej na co dzień. Znacznie lepiej sprawdza się oznaczenie zależności bezpośrednio przy zadaniu, na tej samej tablicy, na której zespół pracuje każdego dnia.
Przykład: zespół produktowy oznacza zadanie "Integracja płatności" jako blokujące dla trzech innych kart na tablicy. Gdy ktoś próbuje przesunąć jedną z zablokowanych kart do kolumny "W trakcie", od razu widzi, że zadanie źródłowe nadal jest w kolumnie "Do zrobienia" - zanim zacznie pracę, która i tak utknie.
Wizualne oznaczenie zależności działa też jako naturalny sygnał ostrzegawczy podczas codziennych spotkań zespołu - wystarczy rzut oka na tablicę, żeby zobaczyć, które zadania czekają na inne, bez wypytywania każdej osoby po kolei.
Jak zarządzać zależnościami międzyzespołowymi
Zależności wewnątrz jednego zespołu da się rozwiązać szybką rozmową. Trudniejsze są zależności między zespołami - na przykład zespół frontendowy czeka na endpoint od zespołu backendowego w innym dziale, a każdy z zespołów ma swój własny harmonogram.
W takich sytuacjach pomaga wyznaczenie jednej osoby po każdej stronie odpowiedzialnej za komunikację o statusie zależności - bez potrzeby angażowania całych zespołów w każdą aktualizację. Sprawdza się też ustalenie stałego, krótkiego punktu synchronizacji, zamiast czekania na eskalację, gdy termin już minął.
Przykład: software house realizujący projekt dla dwóch klientów jednocześnie zauważa, że zespół backendowy regularnie opóźnia się względem frontendowego, bo oba zespoły planują sprinty niezależnie, bez wglądu w wzajemne zależności. Rozwiązaniem okazuje się wspólny przegląd zależności na początku każdego sprintu, trwający nie dłużej niż piętnaście minut, w którym udział bierze po jednej osobie z każdego zespołu.
Najczęstsze błędy w zarządzaniu zależnościami
Planowanie sprintu bez sprawdzenia zależności między zadaniami. Zespół bierze zadanie do sprintu, nie sprawdzając, czy wszystko, od czego ono zależy, będzie gotowe na czas.
Brak jasnego właściciela zadania blokującego. Gdy nikt konkretny nie odpowiada za zadanie, od którego zależą inne, łatwo o sytuację, w której nikt nie zauważa opóźnienia, dopóki nie jest za późno.
Traktowanie każdej zależności jako krytycznej. Nie każda zależność zatrzymuje cały projekt - część można obejść, zmieniając kolejność pracy. Zespoły, które oznaczają wszystko jako "blokujące", szybko przestają odróżniać prawdziwe zagrożenie od standardowego elementu planu, co utrudnia też ogólne zarządzanie ryzykiem w projekcie.
Ignorowanie zależności zewnętrznych, na przykład od dostawcy albo klienta. Zależności spoza zespołu są trudniejsze do kontrolowania, ale właśnie dlatego wymagają wcześniejszego zaplanowania bufora czasowego, a nie zakładania, że wszystko dostarczy się na czas.
Odkrywanie zależności dopiero podczas realizacji, zamiast na etapie planowania. Gdy zespół zaczyna zadanie i dopiero wtedy odkrywa, że brakuje danych od innego działu, traci czas, który dało się przewidzieć jednym pytaniem zadanym tydzień wcześniej.
Zależności a estymacja i planowanie sprintu
Zadanie z dużą liczbą zależności prawie zawsze trwa dłużej niż wynikałoby to z samej estymacji pracy do wykonania - trzeba doliczyć czas oczekiwania i ryzyko, że coś po drodze się przesunie. Więcej o samym procesie szacowania czasu pracy znajdziesz w artykule o estymacji zadań w zespole.
Dobrą praktyką jest planowanie zadań blokujących na początku sprintu, a nie na jego końcu. Jeśli zadanie, od którego zależą inne, trafia do sprintu jako ostatnie, ryzyko, że cały sprint zakończy się bez efektu, rośnie. Ta sama logika stoi za ograniczaniem liczby zadań w toku - mniej równoległej pracy oznacza mniej niewidocznych zależności naraz, co szerzej opisałem w artykule o WIP limits.
Zarządzanie zależnościami w Taskello
W Taskello zależność między zadaniami można zaznaczyć bezpośrednio przy zadaniu, wskazując, od czego ono zależy albo co samo blokuje. Dzięki temu osoba przypisana do zadania widzi od razu, czy może zacząć pracę, czy musi poczekać - bez sprawdzania statusu innych zadań ręcznie.
Gdy zadanie blokujące zmienia status, osoby przypisane do zadań zależnych od niego dostają informację o zmianie, zamiast dowiadywać się o tym przypadkiem na spotkaniu. Ułatwia to też pracę zespołom, które dopiero wdrażają bardziej uporządkowany proces - punktem wyjścia może być instrukcja jak zarządzać projektami w Taskello.
Zależności między zadaniami nie znikną z projektu, niezależnie od tego, jak dobrze zespół planuje pracę. Ale gdy są widoczne, zapisane i przypisane do konkretnej osoby, przestają być źródłem niespodzianek - stają się po prostu kolejnym elementem planu, który można kontrolować.