Dlaczego organizacje mylą aktywność z postępem

Zespół zamknął wszystkie zaplanowane zadania. Status jest zielony, wykres wygląda dobrze, każdy ma co wpisać do podsumowania tygodnia. Tylko że klient nadal nie może skorzystać z funkcji, bo integracja czeka na decyzję innego działu. Praca została wykonana. Wynik, dla którego ją rozpoczęto, jeszcze nie powstał.

To rozróżnienie łatwo zgubić, szczególnie gdy raportowanie opiera się na tym, co można szybko policzyć. Zadanie ma status, spotkanie datę, a prezentacja liczbę slajdów. Trudniej odpowiedzieć, czy rozwiązaliśmy problem użytkownika i czy po wdrożeniu rzeczywiście pracuje mu się lepiej. Zajętość daje za to natychmiastowy materiał do raportu.

Liczba zamkniętych zadań może pomagać w ocenie zaległości. Kłopot zaczyna się wtedy, gdy zastępuje odpowiedź na pytanie, co firma z tej pracy dostała. Jedno zadanie może odblokować rozliczenia, a dziesięć kolejnych poprawić elementy, których nikt nie używa. Zestawienie pokaże jedenaście zamknięć. Bez znajomości kontekstu trudno z niego wywnioskować nawet to, czy tydzień został dobrze wykorzystany.

Co ma się zmienić po tej pracy

Na początku warto umieć powiedzieć, po czym poznamy rezultat. Klient wykona czynność bez kontaktu z obsługą. Zespół odtworzy usługę po awarii w krótszym czasie. Zniknie ręczne przepisywanie danych, przez które powstają błędy. Tak opisany cel pozwala ocenić, czy kolejne zadania przybliżają nas do potrzebnej zmiany.

W pracach technicznych wynik nie zawsze jest widoczny na ekranie. Aktualizacja biblioteki może ograniczać konkretne zagrożenie, a przebudowa modułu ułatwiać kolejne zmiany. Trzeba jednak wyjaśnić, jaki problem uzasadnia koszt i jak sprawdzimy poprawę. „Porządkowanie architektury” będzie zbyt pojemnym uzasadnieniem, jeśli mieści się w nim każda preferencja autora.

Czasem wynikiem pracy jest odstąpienie od pomysłu. Jeśli próba pokazała, że rozwiązanie nie spełni warunku wydajności, możemy oszczędzić sobie kosztu pełnej implementacji. To wartościowy rezultat, choć nie trafi na demonstrację nowej funkcji. Trzeba jednak wcześniej ustalić pytanie i kryterium zakończenia próby. Bez nich łatwo przedstawiać każdą kolejną analizę jako postęp, mimo że żaden wynik nie zmienia dalszego planu.

Peter Drucker pisał: „Time is the scarcest resource”. W tym kontekście czytam to jako przypomnienie, że godziny wydane na jeden temat są już niedostępne dla innego. Praca może być wykonana bardzo sprawnie i nadal przegrywać porównanie z czymś ważniejszym. (Drucker Institute)

Dlatego koszt alternatywny pracy powinien być częścią rozmowy o priorytetach. Utrzymując mało użyteczny raport czy funkcję bez potwierdzonego zastosowania, rezygnujemy z innego wykorzystania tych samych ludzi. Pełny kalendarz nie zwalnia z pytania, czy zajmujemy się właściwymi rzeczami.

Gdzie wynik utknął

Gdy cel jest jasny, można prześledzić kilka zmian od rozpoczęcia do faktycznego użycia. Czasem większość pracy zajmuje implementacja. Czasem kod powstaje szybko, a później czeka na review, akceptację lub okno wdrożenia. Te sytuacje wymagają różnych działań. Samo oczekiwanie, że programiści będą zamykać więcej ticketów, nie rozwiąże kolejki przed cudzą decyzją.

Dużo rozpoczętej pracy może dodatkowo zaciemniać obraz. Kiedy jeden temat się blokuje, ludzie biorą następny. Każdy jest zajęty, ale rośnie liczba niedokończonych zmian i koszt wracania do kontekstu. W takim przypadku ograniczenie równoległych zadań może pomóc bardziej niż dokładanie kolejnych. Najpierw trzeba jednak sprawdzić, co je zatrzymuje.

Ocena ludzi na podstawie liczby zamknięć uczy ich wybierać pracę dobrze widoczną w zestawieniu. Diagnoza wspólnego problemu może zająć tydzień i dać jedno zamknięte zadanie. W tym samym czasie można wykonać kilkanaście prostych poprawek. Jeśli tylko drugi wynik dostaje uznanie, nie dziwmy się, że trudna przeszkoda nadal czeka. Ludzie dostosowują sposób pracy do tego, za co są rozliczani.

Podobną ostrożność zachowałbym przy ocenie pracy z AI. Więcej wygenerowanego kodu może oznaczać szybsze wykonanie zmiany albo większy materiał do sprawdzenia. Dopóki nie obejrzymy review, poprawek i zachowania wdrożenia, sama liczba nie rozstrzyga. Ten sam problem wraca przy gospodarowaniu budżetem modeli AI: wykorzystanie narzędzia jest kosztem wykonania pracy, nie dowodem jej wartości. Firma może podnieść zużycie tokenów i nadal czekać na tę samą decyzję, która blokowała zespół wcześniej.

Poprawę warto oceniać razem ze skutkami ubocznymi. Krótszy czas wdrożenia będzie słabym wynikiem, jeśli okupimy go większą liczbą awarii. Mniej spotkań niewiele da, jeśli ustalenia przeniosą się do dziesiątek prywatnych rozmów. Metryka ma pomagać zrozumieć pracę, a nie zamykać dyskusję o jej jakości.

Status dla kierownictwa powinien więc pokazywać, co się zmieniło, co nadal blokuje rezultat i jakiej decyzji potrzeba. Gdy przeszkodą jest nierozstrzygnięty priorytet, nie przykrywajmy go listą wykonanych zadań. Osoba czytająca raport musi wiedzieć, gdzie jej działanie może jeszcze pomóc.

W podsumowaniu chcę zobaczyć zmianę względem poprzedniego tygodnia oraz przeszkodę, która nadal oddziela nas od wyniku. Jeśli wszystko utknęło na decyzji, kolejne zlecone zadania mogą tylko powiększyć koszt. Manager musi wtedy rozstrzygnąć blokadę albo ograniczyć rozpoczętą pracę. Pełne wykorzystanie ludzi przy nierozwiązanym problemie bywa bardzo drogim sposobem podtrzymywania dobrego statusu.