fbpx

Zarządzanie projektami – słownik podstawowych pojęć

  • Home
  • Wiedza
  • Zarządzanie projektami – słownik podstawowych pojęć

Czytając i słuchając o zarządzaniu projektami i zespołami na pewno natkniesz się na rozmaity slang. Część określeń będzie całkowicie niejasna. Inne będą brzmiały znajomo, ale zostaną użyte w dziwnym kontekście. Sam miałem ten problem. I to nie tylko w pierwszej pracy, ale i w szeregu kolejnych zespołów, do których dołączałem. Dlatego postanowiłem stworzyć mini słownik podstawowych pojęć, na jakie może natknąć się początkujący (i nie tylko) lider.

Do jego tworzenia chciałbym zaprosić także Was. Jeśli czegoś Ci tutaj brakuje – śmiało daj znam znać, a uzupełnimy tę listę.

SPIS TREŚCI

Co to jest projekt, czym różnią się od projektów działania operacyjne (procesowe)?

Nie-na-wi-dzę definicji, które z uporem godnym lepszej sprawy trzeba wkuwać na przeróżne egzaminy uczelniane i certyfikacyjne. Przeważnie pisane są dziwacznym językiem i wcale w swojej istocie nie tłumaczą, co tłumaczą. Najbardziej znana definicja projektu wygląda mniej więcej tak:

Ograniczona w czasie działalność, podejmowana w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi bądź osiągnięcia unikalnego rezultatu.

Nie jest źle, przynajmniej wszystkie słowa są zrozumiałe. Żeby jednak zrozumiała była treść podszedłbym do tego z zupełnie innej strony i zaczął od odrobiny kontekstu. A więc…

Wszystkie działania każdej firmy można podzielić na dwie główne kategorie:

  • Operacyjne, zwane czasem procesowymi
  • Projektowe

Działania operacyjne to wszystkie te standardowe, powtarzane po wielokroć działania, które nawet w szczegółach można (i warto!) ustandaryzować:

  • produkcja masowa (papieru, śrub, rozpuszczalnika, desek, układów scalonych)
  • sprzedaż (sklep, salon firmowy, internet)
  • obsługa klienta (dodawanie dostępów, rozwiązywanie podstawowych problemów, odpowiadanie na podstawowe pytania)
  • tzw. działalność backoffice, czyli procesy wsparcia firmy: księgowość, obsługa kadr i płac, utrzymanie czystości, utrzymanie sprzętu elektronicznego, ochrona budynku i wpuszczanie tam ludzi itd.

Działania projektowe, to wszystko, co poza te standardy wykracza. Na przykład:

  • W obszarze produkcji: budowa nowej fabryki albo linii produkcyjnej, optymalizacja istniejącej linii
  • W obszarze sprzedaży: otwarcie nowego salonu, nowa strona internetowa, duża kampania sprzedażowa (ale codzienne utrzymanie facebooka podpadnie już bardziej pod działania operacyjne).
  • W obszarze obsługi klienta: projekt mający na celu podniesienie satysfakcji klientów (składający się z badań, wywiadów, testów etc.), zmiana systemu informatycznego obsługującego klientów
  • W obszarze backoffice: masowy projekt rekrutacyjny (musimy zatrudnyć 50 osób), zmiana dużego podwykonawcy, wdrożenie paperless office (obieg dokumentów bez konieczności drukowania), uszczelnienie prodcedur bezpieczeństwa na terenie firmy

Oraz w szczególności realizacja projektów komercyjnych dla klientów zewnętrznych – klient płaci za skomplikowany produkt lub usługę, a my mu ją dostarczamy. Skomplikowaną, czyli nie coś “pudełkowego” (licencja, na oprogramowanie; gotowy domek drewniany w paczkach; standardowe szkolenie), a coś wymagającego więcej pracy i dostosowania pod wymagania klienta. Np.:

  • Budowa budynku mieszkalnego albo biurowca. Niby już robiliśmy kilkadziesiąt podobnych, ale za każdym razem mamy innego klienta z innymi wymaganiami, inny grunt i lokalizację, często innych podwykonawców. Na pewno więc nie można nazwać tego działaniem operacyjnym.
  • Napisanie i/lub wdrożenie systemu informatycznego. Np. masz gotowy, rozbudowany system, ale trzeba go skonfigrować pod klienta i dostosować do jego potrzeb.
  • Przeprowadenie kampanii marketingowej dla klienta.

Teraz, bez żadnych sprytnych definicji rozumiesz już czym różni się projekt od innych działań. A jeśli jeszcze chcesz to utrwalić – przygotowaliśmy dla Ciebie specjalną animację:

Na koniec warto dodać, że granica między tym, czy coś jest działaniem procesowym, czy już projektowym może być cienka. Np. jeśli stawiamy klientom niewielkie strony internetowe. Takie wizytówki, gdzie de facto mają 4-5 szablonów do wyboru i niewiele możliwości do zmiany czy dostosowywania czegokolwiek według swojego widzimisię.

Z jednej strony 97% czynności we wszystkich takich projektach się pokrywa i z pomocą stosownej instrukcji może zrealizować je dowolna osoba z minimum kompetencji i doświadczenia w tym obszarze. Pasuje więc proces. Z drugiej strony zawsze pozostaje te 3% i wszystkie wyzwania związane z zarządzaniem relacją z klientem. Pasuje więc projekt. Co wtedy? To… nieistotne.

Najważniejsze jest nie umiejętność sklasyfikowania każdego przypadku, tylko dobrania najbardziej efektywnych narzędzi do zarządzania. W tym konkretnym wypadku sugerowałbym mieć wszystko ładnie opisane i ustandaryzowane jak w podejściu procesowym, ale jeśli zadanie realizuje osoba mniej doświadczona – zasugerować zostawienie sobie niewielkiego buforu czasowego na niespodzianki i zapewnić jej bliższy nadzór i wsparcie podczas krytycznych etapów realizacji. Dokładnie tak, jak się to robi w projekcie.

Co to jest program, a także pod-projekt, stream, sub-stream?

Kiedy projekt jest większy i bardziej skomplikowany, niż byłby to w stanie dowieźć jeden kilkunastoosobowy zespół, wprowadza się zwykle jakąś strukturę, hierarchię i podział. Jaką? Tutaj właśnie zaczynają się schody. Klasyczne metodyki projektowe wspominają przede wszystkim o tworze nazywanym programem, który definiują następująco:

Program to zbiór różnych projektów, mających wspólnie dostarczyć jeden cel. Na czele poszczególnych projektów stoją Project Managerowie, a na czele programu Program Manager.

Swego czasu jako całkiem dobry przykład (acz do znudzenia) dawano program organizacji Mistrzostw Europy Euro 2012. Całośc to wielki program, który składał się z kilkudziesięciu (jesli nie więcej) projektów, które łącznie miały na celu udaną organizację mistrzostw w Polsce. Tyle teorii, w praktyce klasyczny podział, gdzie program dzieli się na projekty nie jest wcale aż tak częsty. Spotkacie się za to z:

  • Projektami, które dzielą się na pod-projekty.
  • Projektami, które dzielą się na streamy, które czasem dzielą się też na sub-streamy.
  • Inicjatywami, które dzielą się na projekty.

Oraz pewnie jeszcze kilkoma innymi kombinacjami rozmaitych terminów. Dla Ciebie ważne jest, że kiedy słyszysz o programie albo projekcie, który dzieli się na mniejsze składowe – na pewno pachnie to czymś dużym, długim, często drogim i ważnym lub wręcz strategicznym dla organizacji, która go realizuje.

Co to jest portfel (portfolio) projektów?

Portfel to jeszcze więcej niż program. To wszystkie projekty z danego obszaru (np. potfolio sprzedażowe, optymalizacyjne, rozwojowe) albo wręcz wszytskie projekty całej organizacji (portfel projektów firmy XYZ). Skoro mamy pojęcie portfela, to można domyśleć się, że pojawią się pojęcia pokrewne:

  • Zarządzanie portfelem – proces w jaki dana organizacja nadzoruje swoje projekty “z lotu ptaka”. To jest bez wtrącania się w szczegóły (“Marka zadanie spóźnia się dwa dni”), a bardziej na poziomie strategicznym. Na przykład:
    • Mamy 100 projektów w trakcie, ale przestrzeni tylko na 80, które pauzujemy/anulujemy?
    • Mamy 100 projektów, które są najważniejsze? Tam damy najlepszych ludzi i zasoby.
    • W kwartale 2 powinny skończyć się 22 projekty i przynieść łączny zysk 900 tys. EUR
  • Portfolio manager – to oczywiście osoba, która odpowiada za zarządzanie danym portfelem. W praktyce zarządzanie to jest najczęściej rolą administracyjną, czyli manager dba aby dane na temat portfela (budżety, statusy, ilość projektów) były aktualne i można było na ich podstawie decydować. Decyzje na poziomie portfela to zwykle bardzo duże i strategiczne decyzje i podejmowane są w organizacji bardzo wysoko, a portfolio manager pełni tam kluczową, ale wciąż wspierającą rolę. Oczywiście na pewno są organizacje, gdzie wygląda to inaczej. Ja piszę jednak o tym, z czym spotyka się najczęściej.

Co to jest produkt, czym zarządzanie produktem różni się od zarządzania projektem?

W ostatnich latach bardzo mocne jest zarządzanie produktem i rola product managera (ew. product ownera). Czym różnią się to od zarządzania projektem, skoro każdy projekt powinien przecież wytworzyć jakiś produkt..? Zacznijmy od definicji produktu.

Kiedy ktoś używa tego pojęcia, może mieć na myśli jego szersze albo węższe znaczenie:

  • W zarządzaniu projektami tradycyjnie używamy określenia “produkt” w jego szereszym znaczeniu. Produkt to inaczej efekt projektu. Może to być jakiś fizyczny przedmiot albo usługa, z jakiej skorzysta klient (patrz niżej – znaczenie węższe), ale też: zoptymalizowany proces (projekt optymalizacyjny), zatrudnieni ludzie (projekt rekrutacyjny albo transition), zrealizowana konferencja, wybudowany budynek, zainstalowana linia produkcyjna itp. Po prostu to, co dostajemy na koniec projektu.
  • Z kolei w węższym znaczeniu produkt to coś, co po wypuszczeniu na rynek trafi do wielu pojedyńczych użytkowników. My zaś nie zamkniemy wtedy kramu, tylko będziemy starali się ten produkt rozwijać i udoskonalać. Najczęściej jest to albo fizyczny przedmiot albo usługa. Na przykład telefon komórkowy, linia kosmetyków, oferta abonamentu telefonicznego, aplikacja na telefon, czy kurs online. W tym znaczeniu projekt rekrutacyjny, organizacja konferencji, czy budowa nie są projektami produktowymi.

To rozróżnienie jest w miarę intuicyjne. Problemy zaczynają się, kiedy chcemy odróżnić zarządzanie projektem od zarządzania produktem. W najprostszym (czytaj: będzie trochę uproszczeń) możliwym ujęciu:

  • W zarządzaniu projektem chodzi o to, aby zrealizować przyjęte na początku założenia zgodnie z jakimś planem. Skupienie tutaj jest na dowiezieniu uzgodnionego efektu końcowego.  Jeśli chodzi o współpracę – można zaryzykować stwierdzenie, że więcej komunikacji jest “wewnątrz”. Przede wszystkim z zespołem projektowym, który realizuje prace.
  • W zarządzaniu produktem chodzi z kolei o to, aby efekt końcowy jak najlepiej spełniał wymagania klientów. Skupienie jest na tym, by efekt końvowy był jak najlepszy. Jeśli chodzi o współpracę – więcej jest komunikacji na zewnątrz. Z przedstawicielami klientów i rozmaitymi innymi interesariuszami.

Czy w jednym przedsięwzięciu może występować i to i to? Jak najbardziej! Jeśli chcemy wypuścić nową, innowacyjną serię reagujących na komendy głosowe smart-mydelniczek, to:

  • Product Manager będzie badał rynek i testował prototypy mydelniczki z klientami. Rozpisze linie produktowe (podstawowa, premium, deluxe) oraz będzie planował ich kolejne wersje (np. mydelniczka 2025 linii premium uwzględni uwagi klientów do linii z 2024 roku).
  • Z kolei Project Manager dowiezie wytworzenie prototypów wg. dostarczonej specyfikacji, czy potem uruchomienie produkcji masowej. Inny Project Manager może być odpowiedzialny za realizacje kampanii marketingowej.

Wszystko powinno odbywać się przy ścisłej współpracy Project i Product Managerów. A jak jest w praktyce? Oczywiście bardzo różnie.

Czasami współpraca ta układa się kiepsko, ale najgorsze są wypadki, kiedy mamy ewidentnie projekt produktowy, ale bez którejś z kluczowych ról. Czyli np. mamy Product Managera, który musi przemocą lub podstępem zmusić poszczególne działy w firmie, aby ów produkt wypuścić na rynek, a nie ma nikogo, kto by mu w tym pomógł. I analogicznie – mamy Project Managera, który ma zrobić “coś” na podstawie sprzecznych i mętnych życzeń najrozmaiszych grup i nie ma nikogo, kto pomógłby mu te życzenia rozjaśnić, ułożyć w logiczną całość, odsiewając przy okazji te co bardziej debilne.

Kim jest sponsor projektu?

Kluczowa osoba i kluczowe pojęcie w projekcie. Mimo, że określenie “sponsor” jasno wskazuje na stronę finansową, to sponsor to przede wszystkim przełożony lidera projektu w kontekście tegoż projektu. Osoba, która ma władzę aby podjąć kluczowe decyzje. Takie, jak na przykład:

  • Start albo przerwanie projektu.
  • Obcięcie albo przyznanie mu dodatkowego budżetu.

W wypadku projektów realizowanych dla klientów zewnętrznych sponsor to nie to samo, co klient. Klient zamawia projekt i za niego zapłaci. Ale to ktoś z Twojej firmy mówi “tak, bierzemy ten projekt, to się opłaca”. Ta sama osoba będzie mogła podjąć decyzje takie, jak przydzielenie Ci dodatkowych ludzi, co podniesie koszty, ale pozwoli sprawniej skończyć projekt. To właśnie jest sponsor.

W wypadku projektów dla klientów wewnętrznych czasami klient i sponsor to to samo. Są jednak sytuacje, gdzie klientem jest  szef zupełnie innego działu, który przychodzi do Was, abyście coś dla nich zrobili. Wtedy sposorem będzie ta osoba, która autoryzuje to, że Wasz dział zużyje na realizacje tego projektu tyle, a tyle godzin swojego czasu.

Powinieneś wiedzieć kim jest Twój sponsor. Powinieneś go na bieżaco informować o tym co dzieje się w projekcie. W zamian masz pełne prawo prosić go o pomoc, kiedy jesteście w kłopotach.

Czy sponsor może być więcej niż jeden? Ortodoksi twierdzą, że nie. Praktyka pokazuje, że czasem niestety tak się dzieje. Niestety, bo to nie jest dobra, ani komfortowa sytuacja dla lidera projektu. Nawet jeśli jest kilku głównych decydentów, powinno być wiadomo kim jest ten “najgłówniejszy”. Inaczej lider nieuchronnie będzie mieć dodatkowe zadanie w postaci niekończących się uzgodnień i negocjacji, w sytuacji gdy te kluczowe osoby będą miały sprzeczne opinie. Od właśnie takich sytuacji jest jeden sponsor, który powinien mieć na tyle władzy, by móc wtedy podjąć finalną decyzję.

I jeszcze jedno, bardzo ważne – rola sponsora i lidera projektu w kontekście odpowiedzialności za projekt:

  • Sponsor odpowiada przede wszystkim za to, że projekt ma sens biznesowy. Że przyniesie zakładane korzyści.
  • Lider projektu odpowiada przede wszystkim za to, żeby dowieźć projekt w zatwierdzonych ramach.

To nie znaczy, że lider nie powinien zupełnie interesować się uzasadnieniem biznesowym projektu (powinien!). Jednak nie może być osobą, którą wskazuje się jako głównego winowajce w sytuacji, kiedy projekt zostanie dowieziony zgodnie z założeniami i planami, ale nie osiągnie zakładanych celów. Na przykład sprzedaż nie wzrośnie tak bardzo, jak zakładano; koszty nie spadną tak mocno, jak planowano itp.

Kim jest interesariusz / stakeholder projektu?

Polskie słowo interesariusz jest całkiem zgrabnym tłumaczeniem agielskiego terminu stakeholder. Jak można się domyślić, oznacza on osobę “zainteresowaną” projektem, a może jeszcze lepiej – taką osobę, ktorej zdanie lider projektu powinien brać pod uwagę i się nimi zainteresować. Często dzieli się interesariuszy na:

  • Tych, którzy mają wpływ na projekt, ale często niekoniecznie będą korzystać z jego wyników – komitet sterujący (patrz niżej), dyrektorzy, architekci systemu, członkowie zarządu, prawodawcy
  • Tych, na których projekt ma lub będzie miał wpływ (a często formalnie nie mają za dużego wpływu na jego kształt) – użytkownicy końcowi, pracownicy reorganizowanych działów etc.

Mimo, że według definicji i pytań z rozmaitych egzaminów (przynajmniej jakiś czas temu, nie wertowałem najnowszych wersji) zespół projektowy należy do interesariuszy projektu, to w praktyce kiedy ktoś wspomina o interesariuszach, ma w 99% na myśli osoby SPOZA zespołu realizującego projekt.

Czym jest macierz wpływu i zainteresowania interesariuszy?

Jedno z mądrych w teorii, a bezużytecznych w praktyce narzędzi uczonych z uporem godnym lepszej sprawy na rozmaitych studiach i kursach. Wygląda, jak na wydzierganym przeze mnie rysunku obok i jak można się domyślić służy do tego, aby umieścić sobie tam interesariuszy, klasyfikując ich podług wpływu i zainteresowania. Dlaczego twierdzę, że tak fajnie wyglądające narzędzie jest bezużyteczne?

  • PRIMO: na etapie planowania nigdy nie znasz wszytskich interesariuszy, a już na pewno nie wiesz na pewno jaki mają wpływ, a jakie zainteresowanie. Z kolei na późniejszych etapach (gdy już wiesz nieco lepiej), nikt nie ma czasu ani ochoty bawić się w aktualizację jakiejśtam macierzy.
  • SECUNDO: to bardzo fajnie, że zidentyfikowaliście kogoś, jako osobę o dużym wpływie i dużym zainteresowaniu (tu Kapitan Bomba), tylko co z tego? Tabelka ani na milimetr nie przybliży cię do zdobycia przychylności i zaufania tej osoby. Czyli tego, o co naprawdę chodzi, co jest najważniejsze.

Reasumując: to, coś do czego potencjalnie zajrzysz raz, a potem zapomnisz. A w dodatku pomoże ci jak umarłemu kadzidło.

Pod kątem bezużyteczności od Wykresu Gantta różni się tym, że o ile Wykres Gantta w pewnych wypadkach bywa nawet bardzo przydatny, o tyle Macierz Wpływu i Zainteresowania Interesariuszy nie przydaje się nikomu i nigdy.

Co to jest komitet sterujący (STECO, STEERCO, STEKO)?

W większych (dłuższych, droższych, bardziej strategicznych) projektach tworzy się czasem komitet złożony z najważniejszych decydentów. Na przykład, kluczowych dyrektorów, przedstawicieli klienta, członków zarządu. Przewodniczącym takiego komitetu zazwyczaj jest sponsor. Zespół ten ma na celu kolektywne omawianie i podejmowanie kluczowych decyzji, a także śledzenie postępów projektu na wysokim poziomie (tj. czy został osiągnięty dany kamień milowy, a nie dlaczego opóźniło się dane zadanie).

Komitetetem sterującym nazywa się też spotkanie, w którym owi ludzie biorą udział (zwykle nie częściej niż raz na 2-3 miesiące). Jeśli słyszysz w nowej pracy, że “za tydzień masz komitet sterujący” – warto się porządnie przygotować.

Co to jest kamień milowy (milestone) i po co się go używa w projektach?

Mówiąc potocznie – kamień milowy to znaczący, “gruby” punkt w harmonogramie projektu. Coś, co wszyscy zaangażowani dobrze rozumieją i co zamyka pewien etap. Przykłady:

  • Fundamenty, stan surowy otwarty, stan deweloperski (budowa domu)
  • Zamknięta faza anlizy, zamknięty etap wdrożenia, zamknięte testy akceptacyjne (wdrożenie systemu IT)
  • Zatwierdzona specyfikacja, zatwierdzona przez klienta partia próbna (uruchomienie produkcji masowej na zamówienie)

Kamień milowy to świetne narzędzie do komunikacji. Zamiast zanudzać wszystkich na śmierć “spotkaliśmy się…, rozwiązywaliśmy…, pracowaliśmy nad…”. Nudne to i niewiele wynika co tak naprawdę dzieje się w projekcie. Dużo lepiej jest powiedzieć “za trzy tygodnie przypada termin oddania produkcyjnego modułu 2, termin jest lekko zagrożony, ale pracujemy nad tym, a ew. opóźnienie nie wyniesie więcej niż 3 dni”. Od razu wiadomo na czym stoimy.

Czym jest estymacja / estymata?

To potoczne określenie na szacowaną wartość czegoś. Najczęściej chodzi o czas albo pieniądze.

Estymujemy, że realizacja tych wymagań potrwa 3 tygodnie i będzie kosztowała 25 000 CHF.

Jeśli ktoś pyta Cię o estymacje, oczekuje że podasz mu zgadywany samodzielnie (bądź – dużo lepszy pomysł – z zespołem) przedział czasu albo kosztów. Specjalnie napisałem “zgadywany”, bo zgadzam się z hasłem “planning is guessing” – planowanie to zgadywanie. To prawda. Ale póki nie mamy szklanej kuli, względnie machiny czasu, tylko to nam pozostaje.

Czym jest łańcuch krytyczny?

Jest to świetnie brzmiąca w teorii metoda zarządzania harmonogramem i zasobami, której zastosowanie w praktyce trochę przypomina Yeti. Wielu ludzi podobno widziało, ale zdjęć i twardych dowodów brak. Pierwszy raz opisana została w książce E. Goldratta pod tym samym tytułem, która to książka jest… naprawdę dobra! Znakomicie odsłania tłumaczy nie-tak-wcale-oczywiste patologie związane z harmonogramowaniem i estymowaniem projektów, których doświadczony lider projektu powinien być świadomy.

Czy nie przesadam z tym Yeti? Cóż. Napiszę tylko, że zakłada się tam m.in. skupienie członków zespołu tylko na jednym projekcie. Jeśli mają jakiś przestój (bo np. ich praca czeka na zatwierdzenie przez kogoś innego albo potrzebują odpowiedzi na jakieś pytanie), powinni… czekać a nie brać się za zadania z innego projektu. To logiczne, ponieważ dzięki temu mogą brać  się za prace natychmiast, jak tylko dostaną owo zatwierdzenie czy odpowiedź na pytanie. Mogą, bo nie są zagrzebani w zadaniach z innego projektu, za który wzięli się w międzyczasie. Główny projekt idzie więc najszybciej, jak to tylko możliwe. Super. Pytanie tylko – który klient zapłaci za to czekanie..?

Dla mnie lektura książki Goldratta była bardzo cenna, bo uświadomiła katastrofalne skutki realizowania zbyt wielu inicjatyw na raz. Staram się więc u siebie i u klientów minimalizować ilość realizowanych jednocześnie inicjatyw. Ale nie wierzę w utopijne wizje.

Czym jest jest gate model?

Popularną praktyką w większych organizacjach (zwłaszcza inżynieryjnych – produkcja transformatorów, silników, szyb zespolonych etc., ale oczywiście też nie tylko tam) jest stworzenie ustandaryzowanego wewnętrznego ramowego procesu “bramek jakości” wykorzystywanych w zarządzaniu najważniejszymi projektami.

Brzmi skomplikowanie, ale w rzeczywistości jest dość proste. Po prostu masz z góry ustalone ileś etapów – bramek (zwanych w ponglish gejtami) i z góry opisane, że np. na Gate 2 “business case” masz mieć zatwierdzone przez takie a takie działy, takie a takie dokumenty. A z kolei podczas innego Gate’u konieczna jest inspekcja BHP. Prace nad projektem (w teorii, bo w praktyce bywa różnie) nie mogą być kontynuowane póki wymagania na dany Gate nie zostaną spełnione.

Warto wiedzieć również, że:

  • Chociaż np. w ramach jednej branży modele te bywają podobne, to mogą też bardzo różnić się od firmy, do firmy. Nie ma jednego standardu.
  • Najczęściej zatwierdzanie zaliczenia kolejnych gate’ów odbywa się na spotkaniach komitetu sterującego.
  • Najczęściej nie każdy projekt w firmie podpada pod gate model. Może to zależeć od obszaru (np. projekty administracyjne byłoby bez sensu realizować w ten sposób) czy wielkości budżetu. Warto dowiedzieć się jak wyglądają te kryteria.

Jeśli jesteś początkującym liderem projektu, możliwe że Twoje pierwsze projekty nie podpadną pod gate model (za małe, za tanie). Niezależnie jednak od tego, jeśli twoja firm używa gate modelu – warto abyś poprosił o jego dokumentacje i się z nim zapoznał.

Co oznacza skrót FTE?

FTE to skrót od Full Time Employee lub Full Time Equivalent, czyli Jeden Pełen Etat. Używa się go określając ilość osób koniecznych do pracy nad jakimś zadaniem albo projektem. Np. 3,5 FTE to trzy osoby na full i jedna na pół etatu, a czasem oznacza to 7 osób zaangażowanych na 50%. Niestety.

Co to jest OPEX / CAPEX / KAPEKS? Co to znaczy ZAKAPEKSOWAĆ?

Co do zasady:

  • Opex oznacza Operational Expenses, wydatki operacyjne, bieżące. Innymi słowy wydatki, na które patrzy się jak na koszty. Są to m.in. pensje, opłaty za media i biuro oraz inne wydatki bieżące.
  • Capex (z polska zwany kapexem) oznacza Capital Expeneses, czyli wydatki kapitałowe, inaczej inwestycyjne. Czyli coś, co (przynajmniej w teorii) powinno się zwrócić. Zwykle większe wydatki jednorazowe – budynek, maszyna, licencja na oprogramowanie.

Potworkowe słowo “zakapeksować” najpewniej oznacza “wrzucić w koszty z kategorii ‘inwesycyjne'”.

Piszę najpewniej, bo szczerze nie lubię wszystkich tych mądrze-brzmiących finansowych określeń (inny przykład to EBITDA). 75% osób, które je używają nie wie tak naprawdę o czym mówi i używa tych pojęć z dużą dowolnością. Radziłbym Ci więc po prostu zapytać grzecznie co mają na myśli, bo pierwszy raz słyszysz takie określenie (względnie: chcesz upewnić się jak wygląda to w tej firmie / dziale / obszarze).

Jeśli zaczną się z Ciebie śmiać mówiąc coś w rodzaju “no jak możesz tego nie wiedzieć” – nie martw się. Oznacza to, że sami nie mają pojęcia o czym mówią i zgrywają mądrale używając słów, których znaczenia nie znają.

Czym jest trójkat project managerski? Co to są trzy ograniczenia projektowe?

Trójkąt project managerski, zwany również trzema ograniczeniami wygląda tak, jak na ilustracji obok. Jest to symboliczne przedstawienie trzech podstawowych ograniczeń z jakimi mamy do czynienia w każdym projekcie i ich wzajemnego wpływu na siebie. Na przykład jeśli chcemy zwiększyć zakres (ilość i jakość tego, co mamy dostarczyć), muszą wzrosnąć koszty albo wydłużyć się termin.

Czemu służy ten trójkąt? Kiedy ktoś ma wolną stronę w jakiejś książce nt. zarządzania projektami, może tam dać taki obrazek i od razu całość wygląda mądrzej i nie marnuje się miejsce.

A nieco poważniej – to taki kawałek podstawowej wiedzy teoretycznej, który w sumie warto znać, ale jego znajomość nie zrobi kolosalnej różnicy w tym, jak będziesz radzić sobie z projektami w praktyce. Niestety większość książek z nt. zarządzania projektami oraz programów studiów z tej dziedziny składa głównie z takich właśnie informacji.

Co to jest backlog?

Uporządkowana lista wszystkich zadań/funkcjonalności potrzebnych w projekcie/produkcie lub ogólniej: wszystko, co uznajemy za potrzebne do realizacji określonego celu. Używany najczęściej w metodyce Scrum, w zespołach zwinnych (Agile’owych).

Charakterystyczną (i bardzo fajną) cechą backlogu jest prosty, ale brutalny i skuteczny sposób priorytetyzacji. Im coś wyżej – tym ważniejsze. Nie ma (jak w życiu) dwóch rzeczy tak samo ważnych.

Priorytet Właściciel Wymaganie
1 Kasia Angielska wersja językowa
2 Marcin Tryb Nocny w aplikacji
3 Marcin Naprawda błędu #667
4 Igor Synchronizacja danych z Google Calendar

Jak widać nie ma dwóch priorytetów o takiej samej wartości. Bo co ci po tym, że wpiszesz sobie 17 rzeczy z priorytetem “1”, jak i tak musisz tam od czegoś zacząć.

Co to jest sprint? Czym jest praca w sprintach?

Pojęcie sprintu pojawiło się we frameworku Scrum. Generalnie jest to zdefiniowany okres czasu, nie dłuższy niż miesiąc.

Jeżeli zespół korzysta ze Scruma, to sprint rozpoczyna się planowaniem, kończy się przeglądaniem oraz retrospektywą. Ma zdefiniowany cel, istnieje backlog sprintu, a na końcu sprintu powstaje coś, co jest gotowe do użycia. Jak poetycko mówi Scrum Guide: ,,In Sprints ideas are turned into value”.

Z racji tego, że pojęcie to upowszechniło się mocno także poza zespoły pracujące w Scrum, hasło “praca w sprintach” niekoniecznie może oznaczać od razu stosowanie pełnego zestawu scrumowych ról i praktyk. Może to być równie dobrze sytuacja, gdy cały projekt dzielony jest na krótkie (zazwyczaj między 2 a 6 tygodniowe) fazy. Co swoją drogą jest bardzo dobrą praktyką dla dowolnego projektu.

Co to jest staging (stage) a także TEST, DEV, PRODUKCJA, INTEGRACJA?

To nazwy środowisk (serwerów / instalacji systemu) używanych w procesie programowania i wdrażania aplikacji w projektach IT.

PROD / Produkcja to te serwery, z których korzystają normalni użytkownicy (te słowa czytasz na produkcyjnej wersji naszej strony), dlatego trzeba bardzo uważać robiąc tam wszelkie zmiany. Dlatego nowe funkcje i poprawki błędów w systemach tworzy się i tetsuje na takich środowiskach jak:

  • DEV – deweloperka, zazwyczaj pojedyncze środowisko jednego programisty / wdrożeniowca.
  • INT – środowisko integracyjne, gdzie tetsujemy jak zmiany różnych osób działają ze sobą.
  • TEST – tu testujemy m.in. to jak nowe zmiany wpływają na już wcześniej wprowadzone funkcjonalności (tzw. regresja). Dodatkowo TEST zwykle jest już mniej zabałaganiony, niż poprzednie środowiska. Bałagan na DEV i INT powoduje dużo nieskoordynowanych zmian i poprawek wprowadzanych na szybko i na brudno. To normalne, bo gdyby na każdym środowisku chciało się mieć wszytsko czysto i pod linijkę – wdrożenia trwałyby wieki. Coś jak warsztat stolarski, gdzie po wyheblowaniu każdej deski chcielibyście posprzątać wszytskie trociny i odłożyć narzędzia do skrzynek. Bez sensu.

I wreszcie STAGE / STAGING. Zwykle jest to odbicie środowiska produkcyjnego, tzn. aplikacja wygląda i zachowuje się tak, jakby była już gotowa do używania, ale można tam bezpiecznie wprowadzać i zmieniać dane, bez ingerowania w działający produkcyjnie system (czytaj: bez ryzyka, że użytkownikom nagle wszystko padnie i zaczniemy tracić pieniądze). To na STAGE najczęściej odbuwają się testy UAT (User Acceptance Testing), czyli testy gdzie klient akceptuje nowe zmiany i sposób ich działania.

To środowisko powinno już być bardzo czyste (zero partyzanckich zmian), a także bardzo dobrze odzwierciedlać produkcję. Na przykład  w miarę możliwości mieć realne dane z baz systemu produkcyjnego, żeby potem nie okazało się, że to, co działało na danych testowych, powoduje błędy na realnych danych produkcyjnych (np. klient w bazie danych ma egzotyczne nazwisko ze znakiem “/” , co powoduje że zapytania do bazy głupieją).

To, co opisujemy wyżej może się oczywiście nieco różnić od firmy, do firmy (nazwy, ilość środowisk). Na pewno jednak w 99,99% przypadków spotkasz się chociaż z produkcją i jakąś formą środowiska testowego.

Co to jest User Story?

Dawno, dawno temu, kiedy wymagania w IT spisywano w długaśnych dokumentach Kent Beck wymyślił, że byłoby dużo lepiej, gdyby olać te dokumenty i zmusić do bezpośredniej rozmowy użytkowników produktu oraz ludzi, którzy budują ten produkt. Dlaczego historyjka? Bo historie są opowiadane!

Tytuły historyjek zaczęto zapisywać na małych karteczkach. Niektórzy zaczęli używać pewnych konwencji zapisu, na przykład: “As a <role> I can <capability>, so that <receive benefit>”. Niektórzy zaczęli mówić o tym, że w historyjkach mamy 3 literki “C”: kartka (card) która jest inicjatorem (bądź tokenem) rozmowy, sama rozmowa (conversation) oraz potwierdzenie, że się dobrze zrozumieliśmy (confirmation).

A potem, jak każda dobra idea, uległa ona degeneracji. Niektórzy mówią “historyjka” na każdy element pracy do wykonania. Inni upierają się przy stosowaniu magicznych zaklęć i tworzą potworki w stylu “Jako system do liczenia odsetek mogę obliczyć odsetki, żeby odsetki były policzone”. Niemniej u podstaw tego pomysłu leży bardzo dobra idea – niech użytkownik nie mówi JAKIE coś ma być, a PO CO mu coś takiego. Czyli nie “chcę cztery kolumny o szerokości 20 pikseli z białym tłem”, tylko “jako lider zespołu potrzebuję zobaczyć wygodne zestawienie godzin przepracowanych w tygodniu przez zespół w czterech głównych kategoriach”.

Uzyskuje się w ten sposób dwie rzeczy:

  • “Zmusza” użytkownika, aby jego życzenia miały jakiś cel i podstawy.
  • Daje realizatorom pole manewru nt. tego jak zrealizować daną potrzebę. Bo może jest dużo prostsza / tańsza / wygodniejsza / efektywniejsza droga niż to, co zna ze swojego dotychczasowego doświadczenia użytkownik.

Co to jest User Story Map?

Creator: Hannah Pearson-Coats | Credit: Jimmy Consulting Limited

Mapa, którą tworzy się dla większej czytelności, kiedy przytłacza nas ilość wymagań spisanych w formie historyjek. To po prostu zebranie historyjek, które tworzą produkt (lub jego część) i umieszczenie ich na wygodnej macierzy. Jej wymiary  (czyli sposób grupowania) mogą obejmować większe funkcjonalności produktu, kolejność ich dostarczania albo inną cechę, która pomaga wygodniej objąć całość spojrzeniem. Podstawowa książka z tego zakresu to “User Story Mapping” Jeffa Pattona.

Sama mapa historyjek ma ograniczoną wartość, bo zwykle bardzo szybko się dezaktualizuje. Ale ogromną wartość daje sam proces jej towrzenia, bo zmusza wszystkich zaangażowanych do rozmowy o tym, jak wyobrażamy sobie nasz produkt oraz jaką wartość daje on klientom oraz użytkownikom. Czyli tradycyjnie “plan jest niczym, planowanie jest wszystkim”.

Czym jest Epik (Epic) oraz Inicjatywa (Initiative)?

Czasem, dla większego porządku i lepszej czytelności całości pojedyńcze historyjki grupuje się w większe, zwane Epikami (pojedyńcze historie składają się na epicką epopeję). Również czasem szereg epików grupuje się w inicjatywę. Zwykle inicjatywa grupuje Epiki składające się na jeden wspólny cel (np. zmniejszenie kosztów), ale mające różne zakresy (np. zmiany w fakturowaniu klientów, zmiany w ofercie, zmianę dostawcy płatności).

Przekładając te pojęcia na terminy z tradycyjnego zarządzania projekami można (choć w dużym uproszczeniu) przyjąć następującą analogię:

  • historyjka to pojedyńcze wymaganie;
  • epic to zbiór wymagań, czyli projekt;
  • inicjatywa to zbiór projektów mających różne zakresy, ale mających dostarczyć ogólny wspólny cel, czyli – program.

Co to są Story Points?

Jest to jednostka miary wykorzystywana do estymowania historyjek użytkowników (user stories), będących częścią backlogu produktu. Opisuje ona złożoność zadania, stopień niepewności i ryzyka, które się z nim wiążą oraz ilość pracy do wykonania. W przeciwieństwie do jednostki czasu – nie określa ona, ile zajmie wykonanie danego zadania.

Najczęściej do estymaty z wykorzystaniem story points używa się ciągu Fibonacciego lub zmodyfikowanego ciągu Fibonacciego (0,1,2,3,5,8,13,20,40,100). Natomiast popularną metodą estymowania z wykorzystaniem story points jest planning poker.

Co to jest Roadmapa?

To chyba najpopularniejsze określenie na wysokopoziomowy (zwykle w ujęciu kwartalnym, ew. półrocznym i rocznym) plan działania w danym projekcie, produkcie, dziale, obszarze. Chodzi o pokazanie najważniejszych rzeczy, jakie mają się wydarzyć w dłuższym okresie czasu. Przedstawienie długoterminowego planu działania. Najłatwiej pokazać to na przykładzie.

Od opisanego wcześniej backlogu roadmapa różni się przede wszystkim tym, że:

  • Backlog dotyczy najczęsciej jednego produktu / obszaru. Roadmapa może być np. dla danego działu, czy nawet całej spółki.
  • Na roadmapie nie umieszcza się wszystkiego, co chcemy zrobić. Wyłącznie kluczowe i najważniejsze rzeczy.
  • Na roadmapie muszą być daty. W backlogu (zwłaszcza w jego niższych, zaplanowanych na później partiach) takowe nie występują.

Co to znaczy zaadresować?

Przykład jednej z licznych kalek z języka angielskiego. Słownikowe polskie znaczenie słowa “zaadresować” to napisać adres na kopercie. Tu jednak chodzi o jedno ze znaczeń angielskiego to address – “to begin to deal with; To direct the efforts or attention“, czyli zająć się. Kiedy więc słyszysz podczas spotkania projektowego “trzeba to zaadresować”, oznacza to: musimy się tym zająć i to rozwiązać.

Co to jest FIFO i LIFO?

FIFO to skrót od “first in first out”, w dosłownym tłumaczeniu „pierwsze weszło, pierwsze wyszło”. Z kolei LIFO oznacza “last in, first out”. To zasady, zgodnie z którymi pierwsze elementy wprowadzone do systemu, są również pierwszymi, które są wydawane lub używane (FIFO) albo na odwrót – ostatni element wpływający do systemu wychodzi z niego jako pierwszy  (LIFO). Najłatwiej zapamiętać to po nieformalnych nazwach, gdzie:

  • FIFO to kolejka (bo wszystkie elementy czekają grzecznie na swoją kolej).
  • LIFO to stos (bo elementy są rzucane jeden na drugi a potem w tej samej kolejności – idąc od góry – z niego ściągane).

W kontekście zarządzania projektami ta zasada może dotyczyć elementów takich jak:

  • zadania w kolejce do zrobienia;
  • wymagania w kolejce do realizacji;
  • tickety/sprawy do rozwiązania zgłoszone przez klienta.

Obie zasady są banalnie proste i łatwe do zrozumienia. Jednocześnie ich prostota może okazać się nie do końca optymalna w sytuacjach, gdzie priorytety zadań są trochę bardziej zniuansowane i zależą od większej ilości czynników, niż tylko kolejność w jakiej coś do nas wpłynęło.

Czy ryzyko to to samo, co problem? I jaki możemy mieć na nie “apetyt”?

Słowo „ryzyko” kojarzy się z możliwością wystąpienia niepewnych i niekorzystnych zdarzeń, które mogą prowadzić do straty, szkody lub negatywnych skutków. Często mylone jest z pojęciem „problemu”, a to w istocie dwa różne pojęcia, choć mogą być ze sobą powiązane. Ryzyko odnosi się do potencjalnych zdarzeń w przyszłości, podczas gdy problem to już istniejący trudny stan rzeczy, który wymaga rozwiązania. Co więcej najmniej oczywiste jest to, że istnieją ryzyka pozytywne, które zwyczajowo nazywamy szansami. Dla pełniejszego zrozumienia, przytoczę definicję ryzyka w kontekście projektu według PMBOK:

Ryzyko, to niepewne zdarzenie lub stan, który w razie zaistnienia wywoła pozytywne lub negatywne skutki względem jednego lub wielu celów projektu.

Czy te definicje i rozróżnienia są w codziennym życiu specjalnie istotne? Średnio i zaprawdę jesteśmy ostatnimi osobami, które czepiałyby się słówek. Istotne staje się to w wypadku wymiany informacji pomiędzy różnymi działami, czy firmami. Warto wiedzieć co ci drudzy mają na myśli pisząc “problem”, aby uniknąć nieporozumienia.

Co jeszcze warto wiedzieć w tym kontekście? Rozmawiając o ryzyku w projekcie, często możemy natknąć się na termin „apetyt na ryzyko”, który odnosi się do poziomu ryzyka, jaki organizacja lub nasz zespół projektowy jest gotów zaakceptować. W praktyce mówi on to, czy jeśli np. w projekcie zidentyfikujemy 74 ryzyka, to firma będzie naciskać abyśmy porządnie zastanowili się nad większością (niski apetyt na ryzyko i jego tolerancja), czy wybrali i porządnie przyjrzeli się tylko dziesięciu najważniejszym (wysoki apetyt na ryzyko, wysoka tolerancja).

Jeśli już chcemy wyczerpać temat definicji, to warto wspomnieć o strategiach odpowiedzi na ryzyko. Modeli jest kilka, ale w najprostszym wydaniu to, co możemy zrobić z ryzykiem sprowadza się do czterech opcji:

  • UNIKANIE – szukanie sposobów mających na celu wyeliminowanie ryzyka lub ochronę celów projektu przed jego wypływem. Najczęściej zupełna zmiana planów w danym obszarze.
  • AKCEPTACJA – świadoma decyzja o niepodejmowaniu aktywnych działań związanych z zarządzaniem i reagowaniem na ryzyko, czyli zaakceptowanie możliwych konsekwencji wynikających z wystąpienia ryzyka. Wybierane zwłaszcza w obszarach, gdzie ryzyko ma relatywnie niski wpływ i/lub prawdopodobieństwo wystąpienia, a zabezpieczenie się przed nim już na pierwszy rzut oka wyglądałoby na bardzo pracochłonne i kosztowne. Nie opłaca zabezpieczać się przed wszystkim.
  • ŁAGODZENIE – podejmowanie działań mających na celu zminimalizowanie skutków ryzyka lub zmniejszenie prawdopodobieństwa jego wystąpienia do poziomu, który będzie akceptowalny.
  • PRZENIESIENIE – próba przeniesienia potencjalnych skutków wystąpienia danego ryzyka na inne osoby/grupy osób/firmę, wraz z całą odpowiedzialnością za zarządzanie nim.

O sensownym sposobie na zarządzanie ryzykiem więcej piszemy tutaj.

Metoda Earned Value

W tym Actual Costs (AC), Planned Value (PV), Earned Value (EV) oraz metryki takie, jak Budgeted Cost of Work Scheduled (BCWS), Actual Cost of Work Performed (ACWP),  Budget Cost of Work Performed (BCWP)

To akademicko-teoretyczna metoda uczona z uporem godnym lepszej sprawy na kursach przygotowawczych do egzaminu PMP. W skócie chodzi tam o wyliczanie z kilku prostych wzorów różnych wskaźników dla twojego projektu. Wartościami bazowymi podstawianymi do tych wzorów są:

  • Actual Costs – kasa, którą na dany dzień wydaliście, np. 125 000,- USD
  • Earned Value – zrealizowany procent realizacji wytworów projektu na dany dzień razy jego wartość końcowa, np. na dzisiaj macie 37,5% produktu, więc 37,5% * 1 000 000,- USD = 375 000,- USD
  • Planned Value – procent realizacji wytworów projektu na dany dzień wg. planu razy wartość końcowa, np. na dzisiaj planowaliście mieć pół produktu więc 50% * 1 000 000,- USD = 500 000,- USD

Określam tę metodę mianem akademicko-teoretycznej, bo jeśli się bliżej przyjrzeć, szybko można dostrzec jej podstawową wadę. Realny procent “wytworzonej wartości” można jakoś-tam określić kiedy budujesz autostradę. Masz zbudować 100km, masz już 60km, więc masz 60% (chociaż i tutaj można się czepiać – liczymy tylko aslfalt, a infrastruktura która powstanie na końcu?). Jednak w zdecydowanej większości projektów są to wartości oderwane od realiów.

Jak obliczysz “procent dostarczenia wartości” dla projektu wdrożenia nowego systemu rozliczania wynagrodzeń, przygotowania produkcji nowego leku, czy zbudowania i instalacji maszyny na linii produkcyjnej? Raz, że 90% postępu może z powodu nieprzewidzianych trudności utknąć na tym poziomie na cały kwartał (i wtedy czy tamto 90%, to faktycznie było 90%, a może jednak mniej?). Dwa, że system warty milion dolarów (i to też przecież w teorii!) wdrożony w 90% ma najczęściej realną wartość nie 900 tysięcy, a okrągłe ZERO, ponieważ jest bezużyteczny.

Możemy sobie radośnie liczyć potem dowolny wskaźnik, ale jeśli wartości podstawione do wzorów były oderwane od rzeczywistości, to tym bardziej oderwany będzie wynik takich obliczeń.

Czy metoda ta jest całkowicie niepotrzebna i bezużyteczna? Cóż, może się zdarzyć, że będziesz potrzebować jej w jakimś dużym projekcie dla dostarczenia danych do działu finansów lub księgowości. Mogą oni mogą potrzebować ich do rozliczeń podatkowych (co jest kosztem, co inwestycją, co na którym koncie etc.), audytów, czy wskaźników do raportów giełdowych. W kontekście zarządzania projektem jest to nadal jednak głęboka teoria i dużo lepiej wasze postępy sprawdzisz np. porównując ile kamieni milowych mieliście na dany moment dostarczyć, a ile ich już dostarczyliście.

W przygotowaniu:

Gantt, cel, Owner, zespół projektowy, projekt transition, projekt B+R

Autorzy: Igor Mróz, Agata Kozicka, Stanisław Matczak, Maja Żuchowska, Aleksandra Kankowska, to miejsce czeka na Twoje nazwisko 🙂