Jak uciec z pułapki Excela i przestać tracić dni na ręczne zmiany harmonogramu?

Narzędzie przejęło na siebie ciężar układania harmonogramu, dzięki czemu każda decyzja biznesowa o zmianie priorytetów niemal natychmiast pokazuje realistyczny, przeliczony plan działania. Oto jak przeszliśmy drogę od chaosu w datach do automatyzacji planowania.

Zarządzanie portfelem projektów przypomina często układanie puzzli, których kształty zmieniają się w czasie rzeczywistym. Decyzja zarządu o przyspieszeniu pracy nad innym projektem dla klienta kluczowego to z perspektywy biznesowej jeden prosty komunikat. Z perspektywy Project Managera to jednak często godziny, a nawet dni spędzone na analizowaniu: „Co musimy przesunąć, żeby to zmieścić?”. Nasz klient mierzył się z dokładnie tym wyzwaniem. Posiadając kompetentne zespoły i jasno zdefiniowane cele, tracił mnóstwo energii na administracyjną obsługę zmian, zamiast skupiać się na ich dowożeniu.

Punkt wyjścia: Dlaczego Excel przestał wystarczać?

Zanim wdrożyliśmy zaawansowane mechanizmy automatyzacji, przeprowadziliśmy audyt obecnego procesu. Sytuacja klienta była typowa dla firm, które szybko urosły:

Rozproszona wiedza: Zależności między zespołami były realne i krytyczne, ale "żyły" w głowach kierownictwa lub na lokalnych taskboardach, niewidocznych z poziomu portfela.
Ręczne sterowanie: Harmonogram wszystkich projektów powstawał w rozbudowanym arkuszu Excel lub na ręcznie rysowanej roadmapie w PowerPoint.
Efekt motyla: Każda, nawet drobna zmiana priorytetu wymuszała ręczne przesuwanie komórek w arkuszu i ponowne przeliczanie dostępności ludzi.

Skutki były łatwe do przewidzenia. Plan dezaktualizował się w momencie jego opublikowania. Proces replanowania (dostosowania harmonogramu do zmian) trwał tak długo i był tak frustrujący, że wykonywano go rzadziej, niż wymagała tego rzeczywistość. W efekcie zarząd otrzymywał terminy, które często okazywały się sprzeczne z realiami pracy całej firmy.

2. Dlaczego „zwykła” Jira nie wystarczała?

Często słyszymy pytanie: „Przecież mamy Jirę, mamy backlogi, robimy Sprinty. Dlaczego to nie działa na poziomie firmy?”. Odpowiedź leży w różnicy poziomów zarządzania. Standardowe boardy Scrumowe czy Kanbanowe są doskonałymi narzędziami operacyjnymi. Pozwalają zespołowi zarządzać pracą „tu i teraz” - w obecnym i przyszłym sprincie. Nie zostały jednak zaprojektowane do widoku cross-project (międzyprojektowego) i planowania w perspektywie kwartałów z uwzględnieniem skomplikowanych zależności. Klient potrzebował warstwy wyższej - narzędzia, które agreguje dane z wielu boardów, filtrów i projektów, budując jedną spójną roadmapę portfela. Tutaj do gry wchodzi Jira Advanced Roadmaps. To nie jest po prostu kolejny widok zadań; to silnik, który potrafi przewidywać przyszłość na podstawie danych, które zespoły i tak już wprowadzają do systemu.

3. Architektura wdrożenia: Jak zbudowaliśmy „mózg” operacyjny

Wdrożenie Advanced Roadmaps to nie tylko instalacja czy kliknięcie „włącz”. To proces mapowania procesów biznesowych na funkcje narzędzia. W przypadku tego klienta skupiliśmy się na pięciu filarach.

3.1 Przeniesienie całej pracy firmy do jednego miejsca

Fundamentem wdrożenia była nie tylko techniczna konfiguracja, ale przede wszystkim radykalna zmiana kultury komunikacji: centralizacja. Podjęliśmy decyzję o „wyciągnięciu” ustaleń z prywatnych skrzynek mailowych i przeniesieniu ich tam, gdzie faktycznie toczy się praca - bezpośrednio do zadań w Jira.

Dotyczyło to wszystkich działów zaangażowanych w projekty, nie tylko zespołów IT, ale również marketingu, sprzedaży czy działu prawnego. Wprowadziliśmy twardą zasadę: koniec z łańcuszkami mailowymi i ustaleniami, które giną w czeluściach Gmaila. Każde pytanie, doprecyzowanie wymagań czy akceptacja musiały znaleźć się w sekcji komentarzy konkretnego zadania. Dzięki temu wyeliminowaliśmy silosy informacyjne - kontekst decyzji stał się transparentny i dostępny dla każdego członka zespołu projektowego, a historia ustaleń przestała być zakładnikiem skrzynki mailowej jednej osoby.

3.2 Uporządkowanie hierarchii pracy

Aby plan był czytelny, Jira musi rozumieć strukturę zadań. Wdrożyliśmy ścisłą hierarchię:

Initiative (Poziom strategiczny): Duże cele biznesowe.
Epic (Poziom zarządczy): Konkretne funkcjonalności.
Story/Task (Poziom wykonawczy): Praca zespołów.
Subtask (Poziom operacyjny).

Dzięki wyjściu ponad poziom Epica, zarząd mógł planować inicjatywy strategiczne, a narzędzie automatycznie agregowało postępy z tysięcy zadań podrzędnych.

3.3 Konfiguracja Capacity (Mocy przerobowych)

Harmonogram, który nie uwzględnia realnej dostępności i wydajności naszych zespołów, jest tylko listą życzeń lub, co gorsza, planem skazanym na porażkę. Dlatego kluczowym elementem wdrożenia było określenie, na co realnie stać każdy zespół w danym okresie.

W systemie Plans skonfigurowaliśmy parametr Mocy Przerobowych (Capacity) dla każdego zespołu – nie tylko IT, ale także np. Marketingu czy Wsparcia. Oparliśmy te obliczenia na historycznej, udowodnionej wydajności (np. ile "jednostek pracy" zespół dostarcza w ciągu dwóch tygodni).

Dzięki temu system wie, że np. Zespół Operacyjny jest w stanie obsłużyć 30 zgłoszeń krytycznych w danym miesiącu. Jeśli Management zaplanuje temu zespołowi 50 takich zgłoszeń, Plans natychmiast zasygnalizuje problem kolorem czerwonym 🔴. Otrzymujemy wczesne ostrzeżenie, że plan jest nierealny, jeszcze zanim zasoby zostaną przeciążone, co pozwala na podjęcie decyzji: czy odroczyć część prac, czy przydzielić dodatkowe zasoby. W ten sposób uniknęliśmy tworzenia harmonogramów „na oko”, zastępując je prognozami opartymi na twardych danych historycznych.

3.4 Auto-scheduler: Serce automatyzacji

To był punkt zwrotny dla klienta. Auto-scheduler to algorytm wbudowany w Jira Plans, który buduje harmonogram na podstawie czterech zmiennych:

Priorytetów zadań.
Estymat (czasowych lub punktowych).
Velocity/Capacity zespołów.
Zależności między zadaniami.

Po odpowiedniej konfiguracji, narzędzie potrafi samo rozłożyć zadania na osi czasu w najbardziej optymalny sposób.

4. Zależności jako fundament planu

Jednym z największych problemów klienta, który zdiagnozowaliśmy na początku, nie były same daty (deadline’y), ale zależności. W praktyce wiele elementów pracy nie mogło ruszyć, dopóki inne nie zostały zakończone. Bardzo częsty przypadek. Bez raportowania tych zależności harmonogram w Excelu wyglądał „ładnie” i „zielono”, ale był całkowicie nierealny.

Jak wyglądało to przed wdrożeniem?

Zależności istniały, ale były ukryte. Opisywano je w komentarzach („czekamy na API”), trzymano w głowach architektów albo oznaczano kolorami w Excelu, których znaczenie znali tylko twórcy arkusza. Były rozproszone i trudne do śledzenia. W efekcie prace startowały teoretycznie „na czas”, ale blokowały się w połowie sprintu. Menedżerowie dowiadywali się o poślizgu dopiero, gdy ten już wystąpił. Każda zmiana priorytetu wymagała ręcznego śledztwa: „Jeśli przesunę ten Epic, to co innego się zawali?”.

Nowe podejście: Zależności jako obiekt pierwszej klasy

W Jira zależności przestały być notatką na marginesie. Stały się twardym elementem logiki planowania. Skupiliśmy się na dwóch typach relacji:

Incoming (is blocked by): Zadanie nie może wystartować, dopóki poprzednik nie zostanie zamknięty.
Outgoing (blocks): Zadanie blokuje start kolejnego elementu.

Na osi czasu widać je teraz jako wyraźne linie łączące belki zadań lub specjalne oznaczenia (badges) przy zadaniach. Dzięki temu, patrząc na plan, od razu widać, że dany Epic jest „uwięziony” przez inny element, który ma niższy priorytet.

Raportowanie, które otwiera oczy

Wdrożenie dedykowanego Dependencies Report zmieniło jakość spotkań statusowych. Zamiast pytać „dlaczego stoimy?”, zespół wyświetla mapę zależności. Od razu widać ścieżki krytyczne i „wąskie gardła” (np. jeden zespół blokujący pracę trzech innych). Raporty dla managementu przestały być opisowe („czekamy na X”), a stały się strukturalne: „Epic B jest zablokowany przez Epic A. Jeśli nie przyspieszymy A, prognoza zakończenia B przesuwa się o 3 sprinty”.

5. Kluczowy efekt: Harmonogram liczy się sam

Najbardziej spektakularna zmiana zaszła w samym procesie zarządzania zmianą. Opiszmy to na przykładzie mechanizmu „Przed i Po”.

Scenariusz: Przychodzi CEO i mówi: „Projekt 'Moduł Płatności', który miał być robiony w Q3, musi być gotowy na koniec Q2. To teraz priorytet nr 1”.

Przed wdrożeniem Plans: PM otwierał Excela. Przesuwał „Moduł Płatności” na maj. Następnie ręcznie analizował, co musi zniknąć z maja, żeby zrobić miejsce. Przesuwał inne projekty na czerwiec/lipiec. Potem dzwonił do Tech Leadów pytać, czy przesunięte projekty nie mają sztywnych zależności. Spędzał dwa dni na układaniu „tetrisa”. Po dwóch dniach okazywało się, że jeden z deweloperów ma urlop, a inny projekt jednak był pilniejszy. Plan znów lądował w koszu.

Po wdrożeniu Plans: PM wchodzi w Jira Advanced Roadmaps. Na liście Epików przeciąga „Moduł Płatności” na samą górę listy. Klika przycisk „Auto-schedule”. Dzieje się magia: Algorytm w ułamku sekundy analizuje capacity zespołów i zależności. Układa „Moduł Płatności” w najbliższych wolnych sprintach. Wszystkie inne zadania, które mają niższy priorytet, zostają automatycznie przesunięte w czasie, z zachowaniem ich zależności i blokad.

Dopiero ujęcie zależności w Jira Portfolio sprawiło, że plan stał się prawdziwym harmonogramem, a nie listą życzeń - bo pokazywał, co realnie może się wydarzyć dopiero po zakończeniu wcześniejszych prac blokujących.

6. Co to dało biznesowo? Konkretne korzyści

Wdrożenie nie było sztuką dla sztuki. Przełożyło się na wymierne korzyści operacyjne:

Replan w minutach, nie w godzinach: Oszczędność czasu Project Managerów jest ogromna. To, co zajmowało dni robocze, teraz jest kwestią analizy scenariusza wygenerowanego przez system.
Jedno źródło prawdy o działaniach firmy: Skończyliśmy z debatami „który Excel jest aktualny”. Plan portfelowy agreguje dane z Jiry na żywo. Jeśli zespół zaktualizuje zadanie, plan o tym wie.
Koniec z terminami „na oko”: Dzięki uwzględnieniu historycznego velocity zespołów i realnych zależności, terminy generowane przez Plans są pesymistycznie realistyczne, a nie optymistycznie niemożliwe.
Szybsze decyzje strategiczne: Management widzi wpływ decyzji priorytetowych natychmiast. Widzą „koszt alternatywny” wrzucenia nowej wrzutki, co często chłodzi zapał do nieprzemyślanych zmian kierunku.

7. Lekcje z wdrożenia - o czym warto pamiętać?

Wdrażając Advanced Roadmaps (Plans), nauczyliśmy się (i klienta) kilku ważnych zasad, które decydują o sukcesie takiego projektu:

Jakość danych (Garbage In, Garbage Out): Auto-scheduler działa genialnie, ale tylko wtedy, gdy dane wejściowe są sensowne. Jeśli zespoły nie uzupełniają estymat lub nie zamykają starych sprintów, plan pokaże bzdury. Kultura higieny w Jira jest niezbędna.
Sandbox (Piaskownica): Wielką zaletą Plans jest to, że działa jako „sandbox”. Możemy robić drastyczne zmiany w planie, symulować scenariusze „co by było gdyby”, a zmiany te nie zapisują się w ticketach zespołów dopóki nie klikniemy „Commit changes”. To daje PM-om bezpieczeństwo eksperymentowania bez wprowadzania chaosu w pracy deweloperów.
Zależności to strategia: Zależności trzeba traktować jako element planu strategicznego, a nie tylko techniczną opcję w Jira. To one determinują krytyczną ścieżkę projektu.

Podsumowanie

Wdrożenie Jira Portfolio / Advanced Roadmaps potrafi zrobić z planowania w IT coś, co wreszcie działa. U jednego z naszych klientów oznaczało to prawdziwą zmianę gry: koniec „ręcznego reanimowania harmonogramu” i przejście na model świadomego zarządzania priorytetami. Zespół przestał tracić czas na żmudne przeliczanie zależności i ciągłe replanowanie w Excelu, a zaczął skupiać się na decyzjach, ryzykach i realnym dowożeniu wartości.

W Kodiwo pomożemy Ci poukładać Twoje procesy, ustawić sensowne zasady planowania i - jeśli trzeba - zautomatyzować cały proces tak, żeby plan przestał być chaosem, a stał się przewidywalnym narzędziem do zarządzania rozwojem.

Chcesz zobaczyć jak? Napisz do nas.