PMI PMP: Kierowanie zespołem i zarządzanie zasobami — Przewodnik do nauki

By Laurynas Brazys · 21 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Część PMP — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów PMI, albo rozwiąż testy na czas na ExamRoll.io.

Formowanie zespołu, karta i jasność ról

Każdy zespół o wysokiej wydajności rozpoczyna pracę od świadomego rytuału formacyjnego, a nie od pierwszego spotkania statusowego. Karta zespołu to dokument założycielski — współtworzony artefakt, który określa wspólne wartości zespołu, zasady podejmowania decyzji, godziny pracy w różnych strefach czasowych, rytm komunikacji i ścieżki eskalacji. W przeciwieństwie do karty projektu (która autoryzuje projekt i wskazuje sponsora), karta zespołu jest tworzona przez zespół, dla zespołu. Jej siła tkwi we współautorstwie: gdy deweloper później przerywa koledze lub opuszcza spotkanie typu stand-up, kierownik projektu nie powołuje się na swój autorytet, lecz wskazuje na normę, którą zespół sam ustanowił.

Obok karty, zasady podstawowe operacjonalizują codzienną dyscyplinę: włączone kamery podczas przeglądów projektowych, brak wielozadaniowości podczas retrospektyw, dwuminutowa zasada dla ustnych aktualizacji, decyzje dokumentowane w ciągu 24 godzin. Zasady podstawowe powinny być widoczne (wywieszone w pokoju zespołu lub przypięte na kanale do współpracy) i regularnie przypominane na początku każdej iteracji lub bramki fazowej. Karta, która leży w folderze SharePoint, którego nikt nie otwiera, jest tylko ozdobą; karta, do której odwołuje się co tydzień, ma moc regulacyjną.

Jasność ról zamyka trójkąt formacyjny. Macierz RACI (lub jej wariant RASCI), mapująca produkty cząstkowe do stron odpowiedzialnych (responsible), rozliczanych (accountable), konsultowanych (consulted) i informowanych (informed), eliminuje tryb awarii typu „myślałem, że ty się tym zajmujesz”. W nowym zespole, w którym kierownik projektu dziedziczy grupę dryfującą od tygodni bez przywództwa, właściwym pierwszym ruchem nie jest ani agresywne ponowne planowanie, ani natychmiastowa renegocjacja harmonogramu ze sponsorem. Jest nim zwołanie zespołu, wysłuchanie, co postrzegają jako zablokowane, i odbudowanie karty oraz mapy ról. Zespół czuje się zagubiony właśnie dlatego, że brakuje tych punktów zaczepienia.

Dostosowanie stylu przywództwa do dojrzałości

Przywództwo sytuacyjne traktuje styl przywództwa jako zmienną, a nie cechę osobowości. Klasyczny model Herseya-Blancharda dopasowuje styl do gotowości pracownika:

• Niskie kompetencje, wysokie zaangażowanie (nowy)
  • Zalecany styl: Dyrektywny
  • Zachowanie: Mów co, kiedy, jak
• Pewne kompetencje, zmienne zaangażowanie
  • Zalecany styl: Trenerski
  • Zachowanie: Wyjaśniaj, „sprzedawaj” decyzje, zapraszaj do dialogu
• Wysokie kompetencje, zmienne zaangażowanie
  • Zalecany styl: Wspierający
  • Zachowanie: Facylituj, dziel się podejmowaniem decyzji
• Wysokie kompetencje, wysokie zaangażowanie
  • Zalecany styl: Delegujący
  • Zachowanie: Przekazuj odpowiedzialność

Postawa przywództwa służebnego — usuwanie przeszkód, osłanianie zespołu przed „szumem”, priorytetyzowanie ich rozwoju — nakłada się na ten model, ale nie zastępuje sytuacyjnej oceny. Przywództwo służebne nie oznacza przywództwa permisywnego. Kiedy zespół dryfuje, lider służebny wciąż kieruje; robi to po prostu w służbie sukcesu zespołu, a nie własnej widoczności.

Pułapka przywództwa leseferystycznego w zespole bez kierunku jest częstą przyczyną porażki. Wycofanie się, „aby pozwolić zespołowi się samoorganizować”, gdy zespół nie ma wspólnego modelu pracy, prowadzi do zamieszania, pominiętych zależności i demoralizacji. Samoorganizacja jest wynikiem dojrzałości, a nie warunkiem początkowym. I odwrotnie, mikrozarządzanie starszymi inżynierami, którzy pięciokrotnie dostarczali podobne zadania, sygnalizuje brak zaufania, tłumi inicjatywę i prowadzi do rotacji. Sygnałem jest sytuacja, gdy kierownik projektu przegląda szczegóły na poziomie commitów w pracy eksperta domenowego, ignorując jednocześnie rozmowy o ryzyku na poziomie portfolio.

Dołączając do zespołu o zróżnicowanym poziomie doświadczenia, pierwszym krokiem jest seria spotkań jeden na jeden połączona z warsztatem na temat zasad współpracy. Pozwala to określić, gdzie każda osoba znajduje się na spektrum gotowości, umożliwiając dostosowanie stylu do każdej osoby, a nie stosowanie go jednolicie wobec wszystkich.

Coaching, spotkania jeden na jeden i zarządzanie wydajnością

Cykliczne spotkania jeden na jeden — zazwyczaj 30 minut co dwa tygodnie — są głównym kanałem coachingu, wczesnego wykrywania problemów i rozwoju kariery. To nie są spotkania statusowe. Agenda powinna należeć do członka zespołu, a kierownik projektu powinien słuchać przez 70% czasu. Tematy obejmują bieżące blokery, rozwój umiejętności, informację zwrotną w obie strony i morale.

Problemy z wydajnością muszą być poruszane przy pierwszej obserwacji, a nie gromadzone na potrzeby formalnej oceny okresowej. Opóźnianie trudnych rozmów jest jednym z najbardziej szkodliwych wzorców w przywództwie projektowym: osoba o niskiej wydajności niczego się nie uczy, dopóki nie jest za późno na poprawę, osoby o wysokiej wydajności obserwują to i tracą zaangażowanie, a morale po cichu spada. Informacja zwrotna powinna odnosić się do mierzalnych wskaźników — wskaźnika „ucieczki” defektów, czasu cyklu historyjki, czasu realizacji przeglądu kodu, frekwencji na spotkaniach, wiarygodności zobowiązań — a nie do subiektywnych wrażeń („wydajesz się niezangażowany”). Mierzalne wskaźniki zakotwiczają rozmowę w obserwowalnym zachowaniu i dają członkowi zespołu konkretny cel.

Eskalacja do menedżerów funkcyjnych lub ostatecznie prośba o wymianę zasobu jest uzasadniona dopiero po tym, jak coaching, jasne określenie oczekiwań i udokumentowana rozmowa na temat poprawy wydajności zawiodły. Pomijanie tych kroków niszczy zaufanie i często narusza politykę HR.

Rozwiązywanie konfliktów i budowanie zespołu

Nierozwiązany konflikt międzyludzki rozprzestrzenia się i pogarsza. Gdy członek zespołu jest izolowany przez resztę grupy w krótkoterminowym projekcie, kierownik projektu nie powinien ani czekać na samoistne rozwiązanie (projekt zakończy się, zanim dynamika ulegnie zmianie), ani publicznie konfrontować się z grupą (co upokarza i usztywnia stanowiska). Prawidłowy wzorzec działania łączy trzy kroki: odbycie prywatnej rozmowy z osobą dotkniętą problemem, aby zrozumieć jej doświadczenia; indywidualne rozmowy z osobami przejawiającymi zachowania wykluczające, aby nazwać zaobserwowany wzorzec i jego wpływ; oraz wzmocnienie norm dotyczących inkluzywności poprzez kartę zespołu i moderowane zajęcia integracyjne. Dokumentacja interwencji jest kluczowa na wypadek, gdyby konieczna była eskalacja do działu HR.

Pięć trybów rozwiązywania konfliktów Thomasa-Kilmanna — współpraca, kompromis, łagodzenie, wymuszanie, unikanie — pomaga w wyborze odpowiedniej strategii. Współpraca (rozwiązywanie problemów w celu znalezienia sytuacji korzystnej dla obu stron) jest generalnie preferowana w przypadku sporów międzyludzkich i technicznych w stałym zespole, podczas gdy wymuszanie może być uzasadnione jedynie w przypadku decyzji dotyczących bezpieczeństwa, etyki lub nieprzekraczalnych terminów.

Alokacja zasobów, wyrównywanie i planowanie wydajności

Zarządzanie zasobami to w równej mierze negocjacje, co arytmetyka. Wyrównywanie zasobów (resource leveling) niweluje nadmierną alokację poprzez wydłużenie harmonogramu; wygładzanie zasobów (resource smoothing) utrzymuje stałą datę końcową i operuje w ramach dostępnego zapasu czasu (float). Wyrównywanie należy wybrać, gdy kluczowy specjalista jest przeciążony i jakość pracy mogłaby ucierpieć; wygładzanie jest lepsze, gdy data końcowa jest ustalona w umowie.

Gdy manager funkcyjny przenosi współdzielonego architekta w połowie sprintu, kierownik projektu negocjuje, opierając się na danych: bieżących zobowiązaniach, wpływie na ścieżkę krytyczną oraz koszcie opóźnienia dla dalszych etapów. Eskalacja do sponsora lub komitetu sterującego jest właściwa tylko po podjęciu i udokumentowaniu próby bezpośrednich negocjacji. Przedstawianie skarg na wyższym szczeblu bez wcześniejszej próby rozwiązania problemu marnuje kapitał polityczny.

Transfer wiedzy i szkolenia przekrojowe

Zależności jednopunktowe (single-point dependencies) należą do najbardziej przewidywalnych i najczęściej ignorowanych ryzyk projektowych. Gdy jedna osoba jest jedynym właścicielem podsystemu i trafia do szpitala na dwa miesiące, porażką nie jest sam wypadek — jest nią brak wcześniejszych działań mitygujących. Do praktyk zapobiegawczych należą programowanie w parach lub mentoring w parach, rotacyjne dyżury (on-call), obowiązkowa dokumentacja wiedzy plemiennej w formie runbooków, nagrywane sesje transferu wiedzy oraz rotacje w ramach szkoleń przekrojowych, podczas których druga osoba najpierw obserwuje, a następnie wykonuje zadania specjalisty. Plany wdrożeniowe dla nowych pracowników powinny jasno przydzielać opiekuna (buddy) oraz mapę kompetencji na 30-60-90 dni.

Planowanie sukcesji na poziomie zespołu identyfikuje, kto mógłby przejąć każdą z kluczowych ról i jakie luki w kompetencjach należy uzupełnić. Informacje te są zapisywane w macierzy umiejętności, przeglądanej kwartalnie.

Facylitacja spotkań i docenianie

Spotkania pochłaniają najbardziej widoczną część zasobów zespołu. Dyscyplina wymaga jasno określonego celu, agendy z ramami czasowymi rozesłanej z wyprzedzeniem, odpowiedniej (a nie maksymalnej) liczby uczestników, jawnych decyzji i zadań do wykonania z przypisanymi właścicielami i datami oraz działającego „parkingu” na tematy poboczne. Cykliczne spotkania, na których nie zapadają decyzje, powinny być anulowane.

Na koniec, docenianie — terminowe, konkretne i publiczne w przypadku sukcesów zespołu; prywatne w przypadku indywidualnego coachingu — nie jest miłym, ale nieistotnym dodatkiem. Nagrody zgodne z wartościami zawartymi w karcie zespołu wzmacniają zachowania, które do nich doprowadziły. Krótkie wyróżnienie podczas spotkania podsumowującego, premia uznaniowa uzgodniona z managerem funkcyjnym lub pisemna notatka do bezpośredniego przełożonego danej osoby kosztują niewiele, a znacząco procentują w postaci morale i retencji.

Problem praktyczny: Scenariusz użycia

Scenariusz: Priya Kapoor została właśnie przydzielona do prowadzenia projektu modernizacji płatności „Meridian” w średniej wielkości banku regionalnym, z budżetem 4,2 mln USD i 14-miesięcznym harmonogramem. 11-osobowy zespół pracuje w trzech strefach czasowych: pięciu deweloperów w Bangalore, trzech analityków biznesowych w Londynie oraz lider QA, architekt i sama Priya w Toronto. Dwa tygodnie po rozpoczęciu projektu deweloperzy z Bangalore stworzyli prototyp, który analitycy biznesowi z Londynu odrzucili jako niezgodny z wymaganiami dotyczącymi zgodności, o których „zakładali, że wszyscy przeczytali”. Architekt z Toronto twierdzi natomiast, że nikt nie konsultował z nim decyzji dotyczącej stosu technologicznego.

Wyzwanie: Priya musi na nowo ustalić normy operacyjne i przejrzystość ról w zespole, zanim projekt zaliczy dalsze opóźnienia, nie sprawiając przy tym wrażenia, że obwinia którąkolwiek z grup za błędy w komunikacji.

Zalecane podejście:

1. Wstrzymanie aktywnego developmentu na rzecz dwudniowych wirtualnych warsztatów integracyjnych, zaplanowanych we wspólnych godzinach pracy (7:00–10:00 w Toronto / 12:00–15:00 w Londynie / 16:30–19:30 w Bangalore), aby wszyscy członkowie zespołu mogli na żywo wspólnie tworzyć artefakty.
2. Facylitacja wspólnego tworzenia karty zespołu (team charter), obejmującej wspólne godziny pracy, prawa do podejmowania decyzji, definicję ról „Consulted” (konsultowany) vs. „Informed” (informowany), zasadę 24-godzinnego czasu odpowiedzi na decyzje asynchroniczne oraz ścieżkę eskalacji kończącą się na sponsorze projektu.
3. Zbudowanie macierzy RASCI dla 18 głównych produktów projektu zdefiniowanych w WBS, omawiając każdy wiersz z zespołem, tak aby rola „Accountable” była zawsze przypisana do jednej, konkretnej osoby, a rola „Consulted” jawnie wskazywała architekta przy wszystkich decyzjach dotyczących stosu technologicznego.
4. Ustalenie podstawowych zasad — włączone kamery podczas przeglądów projektowych, decyzje rejestrowane w Confluence w ciągu jednego dnia roboczego, cotygodniowa 30-minutowa synchronizacja między strefami czasowymi w ramach wspólnych godzin pracy — i przypięcie ich na kanale zespołu na Slacku.
5. Ponowne opracowanie zakresu prototypu wspólnie z analitykami biznesowymi i deweloperami, wykorzystując nowo sprecyzowaną macierz RASCI do określenia, kto musi zatwierdzić zakres przed rozpoczęciem pisania kodu.
6. Dodanie stałego, 10-minutowego punktu „przegląd karty zespołu” do pierwszej retrospektywy w każdej iteracji, aby weryfikować i dostosowywać normy w miarę dojrzewania zespołu.

Dlaczego to działa: Współautorstwo przekształca kartę zespołu z odgórnego nakazu w partnerskie zobowiązanie, co daje kierownikowi projektu podstawę do egzekwowania norm bez powoływania się na autorytet wynikający ze stanowiska. Macierz RASCI eliminuje lukę w odpowiedzialności typu „myślałem, że ty się tym zajmujesz”, która doprowadziła do niedopatrzenia w kwestii zgodności. Regularne przeglądy norm w każdej iteracji zapobiegają sytuacji, w której karta staje się jedynie dekoracyjnym artefaktem, a nie żywą umową.

← Zaangażowanie interesariuszy i komunikacja · Wszystkie domeny · Agile →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →