Work Breakdown Structure (WBS), po polsku struktura podziału pracy, to hierarchiczna, zorientowana na produkty dekompozycja zakresu projektu na mniejsze, zarządzalne elementy. PMI definiuje ją jako deliverable-oriented hierarchical decomposition of the work to be executed by the project team. W praktyce oznacza to, że rozbijasz cel na coraz drobniejsze składniki, aż dojdziesz do jednostek, które da się przypisać, oszacować i skontrolować.
WBS opisuje, co ma zostać dostarczone, a nie jak krok po kroku wykonać pracę. Nie zawiera dat ani zależności czasowych. Te informacje trafiają do harmonogramu w postaci wykresu Gantta lub sieci CPM, dlatego sama struktura pozostaje stabilnym punktem odniesienia dla zakresu.
Najniższy poziom struktury tworzą pakiety robocze (work packages). To na nich opierasz dalsze działania planistyczne:
- szacowanie czasu i kosztów realizacji;
- przypisanie odpowiedzialności, na przykład przez RACI Matrix;
- identyfikację kamieni milowych i ścieżki krytycznej, powiązaną z Milestone;
- budowę harmonogramu, na przykład jako Gantt Chart;
- planowanie zarządzania ryzykiem i kontrolę postępów.
WBS znajduje zastosowanie w metodykach tradycyjnych, w tym Waterfall Model oraz PRINCE2, choć elementy techniki sprawdzają się także w podejściach hybrydowych. Branżowym punktem odniesienia jest wydany przez PMI Practice Standard for Work Breakdown Structures, obecnie w trzeciej edycji. Definicję i kontekst opisuje też What Is a Work Breakdown Structure (WBS) – PMI Blog.
Struktura podziału pracy – jak zbudować WBS od podstaw
Budowę zaczynasz od najwyższego poziomu, którym jest cel lub produkt końcowy projektu. Tę całość dzielisz na główne fazy albo obszary dostarczalne, a każdy z nich rozwijasz na coraz drobniejsze elementy. Metoda top-down prowadzi od celu w dół i zwykle zapewnia większą kompletność zakresu. Podejście bottom-up polega na zebraniu znanych zadań i pogrupowaniu ich w strukturę, ale łatwiej prowadzi do luk. Zasady tworzenia opisuje Work Breakdown Structure – Basic Principles, PMI Learning Library.
Reguła 100% – dlaczego zakres musi się domykać
Reguła 100% wymaga, aby elementy każdego poziomu pokrywały dokładnie zakres elementu nadrzędnego, ani więcej, ani mniej. Dzięki temu żadna praca nie zostaje pominięta, a nic spoza zakresu nie wchodzi tylnymi drzwiami. To najprostsze zabezpieczenie przed scope creepem oraz przed lukami, które ujawniają się dopiero na etapie realizacji. Więcej o tym, jak stosować tę zasadę w codziennej pracy, znajdziesz w tekście Reguła 100% w WBS. Czemu wszyscy o niej mówią, a mało kto ją rozumie.
Dekompozycja w WBS – jak dzielić projekt na pakiety robocze
Dekompozycja polega na rozbijaniu każdego elementu nadrzędnego na mniejsze składniki, aż osiągniesz poziom pakietów roboczych. Poprawnie wydzielony pakiet da się przypisać jednej osobie lub zespołowi, jest mierzalny oraz ma kryteria akceptacji i szacunek czasu i zasobów. Powszechna wskazówka 8/80 mówi, że pojedynczy pakiet powinien wymagać od ośmiu do osiemdziesięciu godzin pracy. Podział zatrzymaj, gdy element da się jednoznacznie przypisać i oszacować, bo dalsze dzielenie zwiększa liczbę dokumentów bez realnej wartości.
Product Breakdown Structure – czym różni się od klasycznego WBS
Product Breakdown Structure (PBS) dekomponuje sam produkt na jego fizyczne lub funkcjonalne składniki, czyli opisuje to, co projekt ma wytworzyć. WBS idzie krok dalej i dzieli pracę potrzebną do dostarczenia tych składników. W praktyce PBS bywa punktem wyjścia do budowy WBS, ponieważ najpierw ustalasz produkty, a potem rozpisujesz działania. Praktyczne wskazówki zbiera Work Breakdown Structure (WBS) – Asana Resources.
WBS – przykład struktury podziału pracy w projekcie
Najlepiej zrozumieć WBS na gotowej strukturze. Poniższe przykłady pokazują, jak ten sam schemat drzewa sprawdza się w różnych branżach, zachowując pokrycie całego zakresu przez elementy niższego poziomu.
Jak wygląda WBS w praktyce – przykład krok po kroku
W projekcie systemu CRM poziom pierwszy stanowi cały System CRM. Poziom drugi obejmuje główne fazy, czyli Analizę wymagań, Projektowanie i Implementację, a dalej Testy oraz Wdrożenie. Pod fazą Implementacja poziom trzeci rozwija się na Moduł sprzedaży, Moduł raportowania i Integrację z ERP. Poziom czwarty zawiera już pakiety robocze, na przykład Kodowanie modułu, Testy jednostkowe i Dokumentację kodu. Każdy poziom pokrywa dokładnie zakres elementu nadrzędnego, więc nic nie zostaje pominięte ani zdublowane.
WBS w projektach IT i budowlanych – przykłady branżowe
W projekcie budowlanym poziom drugi obejmuje zwykle Prace przygotowawcze, Konstrukcję i Instalacje techniczne, a dalej Integrację systemów IT oraz Testy i przekazanie. Instalacje techniczne dzielą się na część elektryczną, HVAC i niskoprądową, a integracja systemów IT na sieć LAN, BMS i systemy bezpieczeństwa. Każda gałąź schodzi do poziomu pakietów roboczych. Widać tu tę samą logikę co w projekcie IT, mimo zupełnie innej branży. Skalę zastosowań potwierdza NASA, która traktuje WBS jako obowiązkowy element zarządzania programami i publikuje NASA Work Breakdown Structure Handbook.
WBS w formie diagramu i tabeli – dwa sposoby prezentacji
WBS prezentuje się najczęściej w dwóch formatach. Diagram drzewa to graficzny, hierarchiczny schemat, w którym gałęzie rozchodzą się od celu głównego w dół i który dobrze sprawdza się na warsztatach oraz w komunikacji z zespołem. Format tabelaryczny porządkuje te same elementy w listę z numeracją poziomów, na przykład 1.1 czy 1.1.1, i jest łatwiejszy do edycji w arkuszach oraz narzędziach do zarządzania projektami. Oba warianty przedstawiają identyczną strukturę i różnią się jedynie sposobem odczytu. Kiedy prosty diagram wygrywa z rozbudowaną dokumentacją, pokazuje wpis WBS: kiedy diagram na ścianie znaczy więcej niż 200-stronicowy dokument.
WBS w metodykach zwinnych – czy Agile korzysta ze struktury podziału pracy?
W klasycznym Agile rolę WBS przejmuje backlog produktu zorganizowany wokół epików, funkcjonalności i historyjek użytkownika. Backlog jest celowo niekompletny na starcie i ewoluuje przez cały projekt, co odróżnia go od WBS z podejścia tradycyjnego, gdzie zakres definiujesz z góry. Mimo to WBS zachowuje sens w projektach o stałym zakresie kontraktowym, przy przetargach oraz w podejściach hybrydowych. W takich sytuacjach WBS opisuje zakres na wyższych poziomach, a backlog sprintów zastępuje pakiety robocze na poziomie iteracji.
Rola WBS w zarządzaniu projektami – od planowania do kontroli
WBS pełni rolę wejścia do niemal wszystkich dalszych działań planistycznych. Na jego podstawie budujesz harmonogram, budżet oraz plan zarządzania ryzykiem, a poszczególne pakiety robocze stają się jednostkami rozliczania postępów. Sama struktura nie zawiera zależności czasowych ani dat, bo te trafiają do harmonogramu jako wykres Gantta lub sieć CPM. Dzięki temu WBS pozostaje stabilnym odniesieniem dla zakresu, na którym opierają się kolejne narzędzia kontroli. Praktyczny przegląd znajdziesz w Work breakdown structure (WBS) in project management – Wrike.
Najczęściej zadawane pytania o WBS
Jak zrobić WBS projektu?
Zacznij od celu głównego na poziomie pierwszym, następnie podziel go na główne fazy lub dostarczalne, a te rozwiń na podgrupy i pakiety robocze. Pracuj metodą top-down i pilnuj, aby elementy każdego poziomu w całości pokrywały zakres elementu nadrzędnego. Podział zatrzymaj, gdy pakiet roboczy da się przypisać, oszacować i skontrolować.
Ile poziomów powinien mieć WBS?
Typowy WBS ma od trzech do czterech poziomów dekompozycji. Podział zakończ w momencie, gdy element osiąga postać pakietu roboczego, czyli najmniejszej jednostki możliwej do jednoznacznego przypisania, oszacowania i kontroli. Dalsze dzielenie zwykle nie wnosi wartości, a jedynie zwiększa liczbę dokumentów do utrzymania.
Czym różni się WBS od harmonogramu?
WBS definiuje zakres i odpowiada na pytanie, co ma zostać dostarczone. Harmonogram definiuje czas i kolejność działań, więc odpowiada na pytanie, kiedy i w jakiej sekwencji praca zostanie wykonana. Harmonogram powstaje na podstawie WBS, ale nie jest jego częścią, a mylenie tych dwóch narzędzi to jeden z częstszych błędów planistycznych.
Co to jest pakiet roboczy w WBS?
Pakiet roboczy (work package) to najmniejsza jednostka WBS. Powinien być możliwy do przypisania jednej osobie lub zespołowi, mierzalny oraz opatrzony kryteriami akceptacji i szacunkiem czasu i zasobów. Za jego realizację odpowiada konkretny wykonawca, a wskazówka 8/80 mówi o granicy od ośmiu do osiemdziesięciu godzin pracy na pakiet.
Od czego zacząć tworzenie WBS?
Punktem startowym jest cel projektu lub jego kluczowy deliverable umieszczony na poziomie pierwszym. Możesz pracować top-down, schodząc od celu w dół, albo bottom-up, grupując znane zadania w strukturę, przy czym podejście top-down zapewnia większą kompletność zakresu. Do budowy przydają się narzędzia w rodzaju Microsoft Project, Jira czy Miro, a także prosty arkusz kalkulacyjny z numeracją poziomów.
