Projekt IT wymyka się spod kontroli? Dlaczego dokładne timesheety nie wystarczą

Kiedy projekt IT zaczyna się sypać, pierwszą reakcją jest zwykle żądanie dokładniejszych timesheetów – najlepiej codziennych, z komentarzem do każdej aktywności.

Brzmi rozsądnie, ale rzadko coś naprawia. Klient zazwyczaj nie potrzebuje wiedzieć, ile godzin przepracował zespół. Potrzebuje wiedzieć, czy projekt nadal zmierza w dobrą stronę.

W tym artykule wyjaśniamy, dlaczego dokładniejsze timesheety nie ratują projektu, który traci kontrolę, i co dobry dostawca powinien zaproponować zamiast tego.

Timesheet pokazuje aktywność. Nie pokazuje, czy projekt jest zdrowy

W wielu projektach IT szczegółowe rozliczanie czasu wygląda jak naturalne narzędzie kontroli. Klient może zobaczyć:

• kto pracował,
• ile godzin pracował,
• nad jakim zadaniem,
• jakiego dnia,
• z jakim komentarzem.

To daje pewien poziom widoczności. Ale nie odpowiada automatycznie na najważniejsze pytania:

• Czy zespół pracuje nad właściwymi rzeczami?
• Czy budżet idzie na rozwój, czy na gaszenie pożarów?
• Czy zakres jest nadal realny?
• Czy opóźnienia wynikają z zespołu, systemu, procesu czy decyzji biznesowych?
• Czy dług techniczny spowalnia delivery?
• Czy mamy problem z jakością, architekturą, środowiskami, testami albo zarządzaniem backlogiem?
• Czy projekt potrzebuje korekty, czy już pełnego takeoveru?

Timesheet może powiedzieć, że zespół przepracował 160 godzin. Nie powie sam z siebie, czy te 160 godzin przybliżyło produkt do celu.

Można mieć idealnie opisane logi czasu i nadal przepalać budżet na złe priorytety. Można mieć dokładność co do minuty i nadal nie mieć kontroli nad roadmapą. Można widzieć codzienną aktywność zespołu i nadal nie rozumieć, dlaczego projekt nie dowozi.

To dlatego w projektach rescue dokładniejsze raportowanie czasu nie powinno być celem. Powinno być jednym z narzędzi diagnostycznych.

Dlaczego klient zaczyna wymagać raportowania co do minuty?

Warto uczciwie powiedzieć: klient zwykle nie prosi o szczegółowe timesheety bez powodu. Taka potrzeba pojawia się najczęściej wtedy, gdy wcześniej coś poszło źle. Przykładowo:

• budżet został wykorzystany szybciej, niż zakładano;
• zakres nie został dowieziony;
• dostawca mówił, że „wszystko idzie dobrze”, a potem pojawiło się opóźnienie;
• zespół pracował, ale stakeholderzy nie widzieli efektów;
• jakość wdrożeń była niska;
• produkcja generowała ciągłe incydenty;
• backlog był nieczytelny;
• nie było jasne, co jest w zakresie, a co poza zakresem;
• klient nie wiedział, ile płaci za rozwój, a ile za utrzymanie;
• poprzedni dostawca zostawił system bez dokumentacji, testów albo stabilnego procesu delivery.

W takiej sytuacji szczegółowe raportowanie czasu jest próbą odzyskania kontroli. I to jest zrozumiałe.

Problem zaczyna się wtedy, gdy wszyscy udają, że większa liczba danych rozwiąże brak przewidywalności. Nie rozwiąże. Jeżeli projekt jest chaotyczny, to dokładniejszy timesheet pokaże dokładniejszy chaos.

Kiedy szczegółowe raportowanie czasu ma sens?

Szczegółowe logowanie czasu bywa potrzebne. Zwłaszcza na początku współpracy, po trudnym handoverze, w projekcie z ograniczonym zaufaniem albo w sytuacji, gdy klient musi uspokoić własnych stakeholderów.

Ma sens również wtedy, gdy trzeba odpowiedzieć na konkretne pytania:

• ile kosztowały awarie i hotfixy;
• ile czasu zespół poświęca na utrzymanie zamiast rozwój;
• ile kosztuje obsługa scope’u dodatkowego;
• ile czasu pochłaniają wrzutki ad hoc;
• ile budżetu idzie na discovery;
• ile zajmuje onboarding nowego zespołu;
• ile kosztuje przejęcie wiedzy po poprzednim dostawcy;
• ile czasu pochłaniają zależności po stronie klienta;
• ile pracy idzie na stabilizację systemu po przejęciu.

W takich przypadkach timesheet nie jest mikrozarządzaniem. Jest narzędziem diagnostycznym.

Dobry dostawca IT powinien jednak od początku powiedzieć, po co dane są zbierane i jak długo taki poziom szczegółowości ma sens. Inaczej raportowanie bardzo szybko staje się rytuałem.

Problem zaczyna się wtedy, gdy raportowanie staje się rytuałem

Jeżeli każda osoba w zespole codziennie dopisuje rozbudowane komentarze do logów, to nie jest za darmo. Przy kilkuosobowym zespole koszt administracyjny może szybko urosnąć do kilku lub kilkunastu godzin miesięcznie. To czas, który mógłby zostać wykorzystany na analizę, testy, automatyzację, doprecyzowanie wymagań albo realną pracę produktową.

Im bardziej szczegółowy model raportowania, tym większe ryzyko, że zespół zaczyna bardziej skupiać się na opisie pracy niż na samej pracy.

W efekcie projekt niekoniecznie staje się bardziej kontrolowany. Staje się bardziej opisany. To nie to samo.

Moja opinia: szczegółowe raportowanie powinno być etapem, nie systemem docelowym

Moja opinia jest taka: szczegółowe raportowanie czasu ma sens tylko jako narzędzie tymczasowe, a nie jako docelowy model zaufania.

Na początku trudnej współpracy może być potrzebne, bo porządkuje rozmowę, pokazuje fakty i pozwala odróżnić prace rozwojowe od utrzymania, incydentów czy zakresu dodatkowego.

Ale jeśli po kilku miesiącach jedynym sposobem kontroli projektu nadal jest ręczne analizowanie każdej godziny, to znaczy, że problem nie został rozwiązany. Został tylko opakowany w administrację.

Docelowo klient nie powinien płacić za poczucie kontroli tworzone przez coraz bardziej szczegółowe timesheety. Powinien dostawać przejrzysty obraz decyzji: ile budżetu zostało wykorzystane, na jaki typ pracy, jaki efekt to przyniosło i jakie ryzyka wpływają na dalszy koszt.

Ręczne raportowanie może pomóc odbudować zaufanie, ale nie powinno zastępować dobrego backlogu, jasnych priorytetów, Definition of Done i regularnej rozmowy o trade-offach.

Co robi dobry dostawca IT, gdy projekt traci kontrolę?

Dobry dostawca nie powinien powiedzieć: „nie potrzebujecie timesheetów, zaufajcie nam”. To byłoby zbyt wygodne.

Dobry dostawca powinien powiedzieć:

Zobaczmy, jakiego rodzaju kontroli naprawdę potrzebujecie. Jeżeli problemem jest brak widoczności kosztów, uporządkujemy raportowanie. Jeżeli problemem jest brak przewidywalności delivery, sam timesheet nie wystarczy. Potrzebujemy sprawdzić backlog, proces decyzyjny, jakość techniczną, ryzyka i to, gdzie budżet faktycznie znika.

To jest właściwy punkt startu dla project rescue albo takeoveru. Nie od raportu godzin. Od diagnozy systemu pracy.

W idealnym scenariuszu ten model widoczności kosztów jest ustawiony od początku współpracy, a nie odbudowywany po kryzysie – piszemy o tym szerzej w artykule Transparentność kosztów w projekcie software. Czego dostawca nie chce ci pokazać.

1. Dobry dostawca oddziela prace planowane od nieplanowanych

W projektach, które wymagają rescue, bardzo często okazuje się, że roadmapa przegrywa z bieżącym chaosem.

Zespół teoretycznie pracuje nad funkcjonalnościami. W praktyce co kilka dni pojawia się pilne zgłoszenie, incydent, brak danych, problem środowiskowy, zależność od legacy systemu, błąd na produkcji albo decyzja stakeholdera, która zmienia priorytet.

Jeżeli tego nie rozdzielisz, łatwo dojść do złego wniosku: zespół dowozi za mało.

Czasem prawdziwy wniosek brzmi: zespół nie ma warunków, żeby dowozić roadmapę, bo większość pojemności pochłania utrzymanie, stabilizacja i prace nieplanowane.

Dobry dostawca powinien więc osobno pokazywać:

• co było zaplanowane;
• co weszło ad hoc;
• co wypchnęło roadmapę;
• jaki był koszt incydentów;
• które decyzje zmieniły plan;
• które problemy wracają cyklicznie;
• co trzeba naprawić systemowo.

To jest ważniejsze niż informacja, czy konkretna analiza trwała 37 czy 52 minuty.

2. Dobry dostawca raportuje efekt, nie tylko aktywność

Słaby raport mówi: zespół przepracował 160 godzin.

Lepszy raport mówi: zespół wykorzystał 160 godzin – tyle poszło na rozwój, tyle na incydenty, tyle na stabilizację. Funkcja A jest gotowa do odbioru, funkcja B się przesunęła, bo incydenty wypchnęły część planowanej pojemności. W kolejnym tygodniu rekomendujemy ograniczyć nowy scope i domknąć stabilizację.

To jest różnica między raportowaniem czasu a zarządzaniem projektem.

Klient nie potrzebuje samej informacji, że zespół był zajęty. Klient potrzebuje wiedzieć:

• co dostał za budżet;
• czego nie dostał;
• dlaczego;
• co to oznacza dla kolejnych tygodni;
• jaką decyzję trzeba podjąć.

3. Dobry dostawca automatyzuje raportowanie tam, gdzie to możliwe

Ręczne raportowanie powinno wyjaśniać wyjątki, a nie zastępować cały proces zarządzania projektem.

Jeżeli zespół pracuje w Jirze, Linear, Azure DevOps, GitHubie, GitLabie albo innym narzędziu, część danych powinna wynikać automatycznie z procesu.

Dobry dostawca powinien dążyć do tego, aby klient widział:

• status prac;
• przepływ zadań;
• liczbę zadań w toku;
• blokery;
• zakres dowieziony;
• zakres przesunięty;
• koszt typów prac;
• koszt incydentów;
• prognozę wykorzystania budżetu.

Nie ma sensu zmuszać zespołu do ręcznego opisywania tego, co można wiarygodnie wyciągnąć z narzędzi.

Manualny komentarz powinien tłumaczyć kontekst: dlaczego coś się przesunęło, co zmieniło priorytet, jaki trade-off został podjęty, czego potrzebujemy od klienta.

4. Dobry dostawca mówi, kiedy projekt potrzebuje takeoveru

Nie każdy problem z projektem oznacza konieczność zmiany dostawcy. Czasem wystarczy poprawić raportowanie, uporządkować backlog, ustalić Definition of Done i wprowadzić lepszy rytm decyzyjny.

Ale są sytuacje, w których dokładniejsze timesheety będą tylko pudrowaniem problemu. Sygnały ostrzegawcze:

• dostawca nie potrafi wyjaśnić, na co idzie budżet;
• roadmapa stale przegrywa z incydentami;
• zespół nie ma kontroli nad środowiskami;
• deploymenty są ryzykowne i ręczne;
• backlog jest zbiorem przypadkowych zgłoszeń;
• nie wiadomo, co jest w zakresie;
• system nie ma dokumentacji;
• testy nie dają realnego bezpieczeństwa;
• każda zmiana powoduje regresje;
• poprzedni dostawca utracił zaufanie biznesu;
• zespół nie potrafi pokazać przyczyn opóźnień;
• klient musi sam zarządzać dostawcą na poziomie operacyjnym.

W takim przypadku klient nie potrzebuje dokładniejszego rozliczania minut. Potrzebuje przejęcia kontroli nad projektem. To może oznaczać project rescue, audyt techniczno-produktowy, takeover, stabilizację delivery albo wymianę procesu zarządzania produktem i technologią.

Jak powinien wyglądać pierwszy krok w project rescue?

Dobry dostawca IT nie powinien zaczynać od obietnicy, że „dowiezie szybciej”. W problematycznym projekcie to zbyt ryzykowne.

Pierwszy krok powinien obejmować diagnozę:

• przegląd backlogu i roadmapy;
• identyfikację incydentów i prac nieplanowanych, które wypychają plan;
• ocenę procesu delivery;
• ocenę środowisk i deploymentów;
• przegląd długu technicznego i dokumentacji;
• identyfikację kluczowych ryzyk;
• rekomendację planu stabilizacji.

Dopiero po tym można uczciwie powiedzieć:

• co da się uratować szybko;
• co wymaga inwestycji;
• co trzeba zatrzymać;
• co trzeba przepisać;
• co można dowozić równolegle;
• gdzie budżet przecieka;
• jakie decyzje musi podjąć klient.

To jest realna transparentność. Nie kontrola dla kontroli.

Najtańsza wersja takiej diagnozy to ta, której nigdy nie musisz przeprowadzać – bo transparentność kosztów została ustawiona od pierwszego tygodnia współpracy.

O co zapytać dostawcę, gdy projekt zaczyna się sypać?

Jeżeli jesteś po stronie klienta i czujesz, że projekt wymyka się spod kontroli, nie zaczynaj wyłącznie od pytania o dokładniejsze timesheety. Zapytaj:

• Które prace nieplanowane wypchnęły w ostatnich tygodniach roadmapę?
• Co jest największym źródłem opóźnień?
• Czy backlog pokazuje priorytety biznesowe, czy tylko listę zadań?
• Czy zespół ma stabilne środowiska do testów?
• Czy deployment jest przewidywalny?
• Czy dług techniczny zwiększa koszt każdej zmiany?
• Które problemy są objawami, a które przyczynami?
• Jakie decyzje muszę podjąć jako klient, żeby odzyskać kontrolę?
• Co dostawca rekomenduje zatrzymać, zanim przepalimy kolejny budżet?

Jeżeli dostawca odpowiada konkretnie, to dobry znak. Jeżeli odpowiada tylko: „będziemy dokładniej raportować czas”, to prawdopodobnie nie dotyka sedna problemu.

Pełną listę pytań, które warto zadać dostawcy jeszcze przed podpisaniem umowy, zebraliśmy w artykule o transparentności kosztów w projekcie software oraz w tekście Jakie pytania zadać firmie IT przed podpisaniem umowy?

Podsumowanie: klient nie kupuje minut. Klient kupuje kontrolę nad efektem

Rozliczanie czasu pracy zespołu IT co do minuty może być użyteczne. Ale nie powinno być domyślną odpowiedzią na problemy z projektem.

Szczegółowy timesheet może pokazać, ile czasu zostało zużyte. Nie pokaże sam z siebie, czy projekt jest zdrowy, czy budżet jest dobrze inwestowany i czy zespół pracuje nad właściwymi rzeczami.

Jeżeli projekt IT wymyka się spod kontroli, potrzebujesz czegoś więcej niż dokładniejszego raportowania. Potrzebujesz diagnozy: gdzie budżet realnie znika, co wypycha plan, które problemy są objawami, a które przyczynami, i jaką decyzję trzeba podjąć teraz.

Dobry dostawca nie sprzedaje klientowi poczucia kontroli przez coraz dokładniejsze timesheety. Pomaga odzyskać realną kontrolę nad projektem.

Bo klient nie kupuje minut. Klient kupuje postęp, przewidywalność, mniejsze ryzyko i działający produkt.

Czujesz, że Twój projekt zaczyna się wymykać spod kontroli?

Pomagamy odzyskać kontrolę nad projektami, w których budżet ucieka, roadmapa przegrywa z incydentami, a raporty pokazują aktywność zamiast efektów. W kilka dni mówimy, gdzie naprawdę leży problem, co trzeba zatrzymać i czy wystarczy korekta kursu, czy potrzebny jest pełny rescue.

Umów 30 minut rozmowy – bez slajdów, bez prezentacji. Opisz, gdzie projekt zaczyna ci się sypać, my powiemy, od czego zacząć.

Podsumuj ten artykuł za pomocą sztucznej inteligencji

ChatGPT

Claude

Perplexity