W 2014 zespół 12 programistów dostał zlecenie na system e‑commerce dla średniej wielkości dystrybutora. Projekt manager przyjechał pierwszego dnia z wydrukowanym WBS na 47 stron. Struktura była perfekcyjna: główny moduł, submoduły, work packages, wszystko ponumerowane według PMBOK Guide. Pytanie tylko, kto miał to przeczytać. Po trzech tygodniach wydruk wisiał w kuchni, zasłonięty grafikiem urlopów. Po pół roku klient zmienił zakres, ale nikt nie zaktualizował tych 47 stron.
Work Breakdown Structure to hierarchiczna dekompozycja pracy do wykonania przez zespół projektowy. PMBOK definiuje ją jako deliverable-oriented hierarchical decomposition – koncentrację na dostarczalnych, podzielonych kaskadowo na mniejsze części. Brzmi sensownie. Problem zaczyna się w momencie, gdy WBS przestaje być narzędziem do myślenia, a staje się dokumentem do wyprodukowania. Bo jednego nas uczą metodyki: WBS musi istnieć. Drugiego nikt nie mówi wprost: większość zespołów tworzy go raz, na potrzeby audytu albo kontraktu, i więcej do niego nie zagląda.
Geneza: NASA, lata 60. i marzenie o kontroli
WBS nie wzięło się znikąd. W latach 50. US Department of Defense miał problem: jak zarządzać megaprojektami, w których setki podwykonawców realizują tysiące komponentów. W 1957 w ramach programu Polaris narodził się PERT, a wraz z nim koncepcja rozbijania złożonej pracy na manageable pieces. NASA podchwyciło to w latach 60., bo program Apollo wymagał koordynacji na niespotykaną dotąd skalę. Kiedy masz rakietę złożoną z miliona części, a każda ma własnego dostawcę, potrzebujesz czegoś więcej niż intuicja. Potrzebujesz struktury.
W tamtym kontekście WBS miało sens. Nie chodziło o zarządzanie ludźmi – chodziło o zarządzanie komponentami sprzętowymi. Moduł księżycowy składał się z elementów, każdy element z subkomponentów. To była czysta hierarchia fizyczna. Ale IT nie buduje rakiet. IT buduje kod, który zmienia się co sprint, a wymagania klienta są ruchomym celem. I tu zaczyna się problem.
WBS vs PBS: kiedy dostarczalny nie jest czynnością
PRINCE2 poszło trochę inną drogą. Zamiast Work Breakdown Structure używa Product Breakdown Structure. Różnica jest subtelna, ale istotna. PBS koncentruje się na produktach – rzeczach, które projekt ma dostarczyć. WBS miesza produkty z czynnościami. W PBS mówisz: system logowania, panel admina, API. W WBS mówisz: zaprojektować system logowania, zaimplementować panel admina, przetestować API. Czasowniki vs rzeczowniki.
Który sposób jest lepszy? Zależy od zespołu. Jeśli pracujesz w środowisku kontraktowym, gdzie każda godzina jest fakturowana, WBS z work packages ma sens – pokazuje, kto, co i ile. Jeśli pracujesz w Scrumie, gdzie dostarczalny to user story, PBS jest bliższe rzeczywistości. Ale w obu przypadkach kluczowa jest jedna rzecz: czy ktoś faktycznie używa tego dokumentu, czy tylko go wyprodukował.
Pułapka granularności
Najbardziej powszechny błąd w tworzeniu WBS: zbyt drobne rozbicie pracy. Zasada 8/80 mówi, że work package nie powinien trwać krócej niż 8 godzin ani dłużej niż 80. W praktyce widziałem WBS‑y, gdzie pojedyncze zadanie to review dokumentu – 15 minut. Albo przeciwieństwo: zbudować backend – 6 miesięcy. Obie skrajności są bezużyteczne.
Drugi błąd: traktowanie WBS jak plan wykonania. WBS nie mówi, w jakiej kolejności robić rzeczy. To nie harmonogram. To mapa terenu, nie trasa marszu. Można mieć perfekcyjny WBS i kompletnie chybiony plan, bo WBS nie zawiera zależności czasowych ani zasobowych. To tylko lista tego, co trzeba zrobić – bez kontekstu, kiedy i przez kogo.
Fred Brooks w The Mythical Man-Month (1975) ostrzegał, że rozbijanie pracy na coraz mniejsze kawałki nie przyspiesza dostawy – zwiększa overhead komunikacyjny. Dodawanie ludzi do spóźnionego projektu opóźnia go jeszcze bardziej, bo każdy nowy człowiek wymaga wprowadzenia, a liczba połączeń w zespole rośnie wykładniczo. WBS tej prawdy nie zmieni. Możesz mieć 500 work packages i zero delivery, jeśli zespół goni własny ogon.
Kiedy WBS naprawdę działa
Jest jedna sytuacja, w której WBS ratuje projekty: na początku, gdy nikt nie wie, co trzeba zrobić. Pierwsze spotkanie, flipchart, karteczki. Zaczynasz od góry: system do zarządzania zamówieniami. Co w nim jest? Frontend, backend, integracje, testy. Co w backendzie? API, baza danych, logika biznesowa. Co w API? Endpointy użytkowników, endpointy produktów, autoryzacja. Po godzinie masz 40 karteczek i nagle wszyscy widzą to samo. To jest wartość WBS. Nie dokument na 47 stron – diagram na ścianie, który wszyscy zrobili razem.
Drugi moment: estymacja. Jeśli masz rozbić projekt na etapy kontraktowe, WBS pomaga oszacować, ile czego jest. Nie mówi, ile to zajmie – ale pokazuje, czego w ogóle nie zauważyłeś. Ten moduł raportowania? A kto ma go zrobić? A kto przetestować? A kto wdrożyć na produkcję? WBS wyciąga niewidoczne na pierwszy rzut oka elementy. Ale tylko wtedy, gdy ktoś faktycznie myśli nad każdym elementem, a nie kopiuje szablon z poprzedniego projektu.
Źródła
- Project Management Institute, “PMBOK Guide”, PMI, 2021.
- AXELOS, “PRINCE2 Manual”, 2017.
- Brooks F.P., “The Mythical Man-Month”, Addison-Wesley, 1975.
- Mosaic Project Services, “The Origins of WBS & Management Charts”, 2020.
Zdjęcie: Andrea Piacquadio / Pexels
