utworzone przez Marcin Żmigrodzki
O czym chcielibyście przeczytać? Czego wam brakowało? O co uzupełnić trzecią edycję Zarządzania projektami dla początkujących? Wczoraj wydawnictwo Helion zaproponowało, aby rozpocząć prace nad nową wersją książki.
Myślałem o rozdziale na temat analizy biznesowej, o motywowaniu zespołu, albo o projektach w startupach. Jeżeli macie propozycje tematów ważnych dla początkującego kierownika projektu, to chętnie się z nimi zapoznam.
W czerwcu prawdopodobnie poszerzony tekst zostanie oddany do druku, przez wakacje będzie trwała jego korekta i skład, a drukiem ukaże się prawdopodobnie na jesień.
Tutaj załączam linka do drugiej edycji książki.
utworzone przez Marcin Żmigrodzki
Zatytułowałbym artykuł na temat zbliżających się zmian w standardach PMI „Nadchodzą wielkie zmiany”, albo „Co nowego szykuje dla nas PMI”, ale bardziej pasuje do całej sytuacji tytuł „Wielka konfuzja”.
Fakty są takie:
- Egzamin PMP zmienia się znacząco od 1 lipca 2020. Połowa pytań ma od tego momentu dotyczyć agile. Terminy takie jak samoorganizujący się zespół, sprint, retrospektywa, motywacja wewnętrzna, backlog, opowiastki użytkownika z pewnością są dobrze znane i wykorzystywane przez kierowników budów, portów, konstruktorów dźwigów, linii wysokiego napięcia, mostów, leków, przezbrajających linie technologiczne w fabrykach aut, mebli i cukierków oraz stawiających nowe fabryki. Sądzę, że to dla was ta zmiana będzie wyzwaniem.
- Zmiana w testach PMP pociągnie za sobą zmianę struktury dziedzin wiedzy na egzaminie. Odnoszę wrażenie, że PMI chce skupić się bardziej na weryfikacji miękkich kompetencji kierownika projektu, a nieco mnie sprawdzaniu znajomości technik i procesów.
- PMI podkreślił, że zakres materiału na egzamin PMP to wiele więcej książek niż tylko PMBOK Guide, publikując je na osobnej stronie. 4 na 10 dotyczą przede wszystkim projektów IT, więc kierunek rozwoju stowarzyszenia wydaje jasny. 5 na tych 10 to encyklopedie zarządzania projektami, w tym samym PMBOK Guide, co oznacza spore rozszerzenie zakresu wiedzy wymaganej na egzaminie.
- Dwa miesiące temu wyszło polskie tłumaczenie książki w wersji 6. Tydzień temu opublikowano draft wersji 7, która jest zupełnie inaczej skonstruowana. Przykładowo zamiast ponad 600 ma 37 stron i zawiera złote rady mówiące, co to znaczy być dobrym kierownikiem projektu. Ciekawe, że PMI nie uznaje polskiego tłumaczenia za oficjalne skoro nie ma go wymienionego na stronie PMBOK Guide. Jest za to 11 innych języków. Jaka będzie rola polskiego PMBOK Guide, jeśli kolejna wersja wyjdzie na koniec tego roku?
- Draft standardu zarządzania projektami wersja 7 zawiera ogólne zalecenia dotyczące bycia wzorowym PMem. Jak chcecie sami możecie się z nim zapoznać, logując się na PMI i przechodząc do edycji draftu. Najlepiej, jak streszczę całego PMBOKa, to będziecie szybciej wiedzieli, o co chodzi. Dowiemy się z niego, że:
- Projekty wchodzą w skład portfeli i programów.
- Projekt kiedyś się kończy i ma dostarczyć cele.
- Zespoły projektowe dostarczają zakres a różne sposoby, dosłownie „a broad range of approaches”.
- Koordynacja zespołu jest bardzo ważna.
- Wśród ról w zespole można wymienić: lider, coach, członek, przedstawiciel biznesu, ekspert, klient, sponsor, komitet.
- Lider może być kierownikiem projektu, scrum masterem lub inną osobą, która napędza projekt. Dalej leci opis na pół strony każdej z powyższych ról.
- Na projekt ma wpływ otoczenie.
- Zaś organizacja może zastosować swój know-how, aby wspomóc projekt.
- Produkt projektu to coś, co projekt dostarcza.
- Dalej lecą przykazania kierownika projektu:
- bądź pilny, pełny szacunku i troskliwy.
- dbaj o szacunek.
- gadaj z udziałowcami.
- skup się na wartości.
- reaguj, jak coś się dzieje.
- motywuj, ucz i wpływaj na innych.
- dostosuj sposób prowadzenia projektu do potrzeb.
- dbaj o jakość.
- używaj swojej głowy.
- analizuj okazje i zagrożenia.
- bądź elastyczny.
- wspieraj zmiany.
- Można by jeszcze dodać: nie słuchaj głośnych i napastliwych swą udręką… A tutaj link, jakbyście chcieli posłuchać PMBOKa na żywo.
- I to jest naprawdę cała książka. Domyślam się, że uzupełnieniem jej mają być owe 10 książek, o których wspominałem wcześniej.
- Ok, trochę przesadziłem w poprzednim punkcie, bo PMI ogłosił, że na koniec roku zamierza opublikować PMBOK Guide 7, którego częścią będzie powyższy 37 stronicowy standard. Jedyne, co wiadomo oficjalne, to to, że reszta tej książki będzie składać się z 8 obszarów wiedzy: zespół, interesariusze, cykl życia, planowanie, niepewność, dostarczanie, efektywność, praca w projekcie. Jest to totalna przebudowa struktury względem PMBOK Guide 6. Jeżeli dobrze rozumiem zapowiedzi, to zrezygnuje się z proponowania procesów projektowych. Pytanie, czy w książce znajdą swoje miejsce techniki i narzędzia?
- PMI miesiąc temu ogłosił, że wkrótce afiliowane firmy szkoleniowe, tzw. REP, będą musiały korzystać z materiałów szkoleniowych przygotowanych przez PMI oraz że trenerzy będą musieli być certyfikowani. Dziś certyfikuje się tylko firmę, a trener musi mieć PMP. Zasugerowano między wierszami, że zmieni się sposób opłacania przez firmę szkoleniową za posiadanie tytułu REP z płaskiego rocznego abonamentu na płatność per szkolenie. Wydaje mi się, że takim model istnieje w PRINCE2, tylko, że tam sam egzamin jest elementem szkolenia. W PMI kandydat może uczyć się dowolnie i sam idzie na egzamin w Pearson/Vue. Zastanawia mnie, na ile bycie REP przestanie być w związku z tym opłacalne dla firm szkoleniowych.
Wniosek
Po pierwsze, jeżeli ktoś akurat ma zebrane odpowiednie doświadczenie i chciałby zdać PMP, to niech się pośpieszy. Szczególnie, jeżeli nie pracuje w środowisku IT. Jest styczeń, do czerwca pozostało pięć miesięcy, więc zdąży jeszcze zdać po staremu.
Po drugie, jeżeli ktoś nie zdąży przez pierwszym lipca, to sugeruję, aby poczekał, aż nowa baza pytań się uleży, aż pojawi się tłumaczenie na polski (dziś nie wiadomo, kiedy to nastąpi). Proponuję poczekać do nowego roku, tj. 2021, bo wtedy wyjdzie nowy PMBOK Guide i będzie wiadomo więcej.
Jestem zagubiony w ocenie, w którą stronę idzie rozwój tej organizacji. Dotychczasowa książka choć trudna w odbiorze, bo napisana suchym językiem, była spójną i uporządkowaną encyklopedią. Teraz jej pierwsza część to charakterystyka kultury organizacyjnej wioski smerfów, a druga jest wielką zagadką wciąż. Rośnie waga projektów IT, ignorując inne sektory. Rośnie ranga samoorganizujących się zespołów, redukując rolę kultury kontroli i dyrektyw. Ma wrażenie, że środowisko zachłysnęło się podejściem zwinnym. Natomiast moim zdaniem ono nie przystaje do każdej sytuacji. W sytuacji kryzysowej przydaje się jednoosobowe kierownictwo i krótkie jasne procesy decyzyjne. Jak gaszę pożar, to chcę znać procedurę i wiedzieć, kto dowodzi.
utworzone przez Marcin Żmigrodzki
Serdecznie zapraszamy chętnych a szkolenie przygotowujące do PMP we Wrocławiu od 9 do 12 marca.
Szkolenie wprowadzi Cię w świat PMBKO Guide 6. Opowiemy o samym procesie uzyskiwania certyfikacji PMP, przebiegu egzaminu. Będziesz miał również możliwość napisania próbnego egzaminu.
Poruszmy również krótko załącznik do PMBOK, czyli Agile Practice Guide.
Tutaj możesz przeczytać więcej o samym szkoleniu
utworzone przez Marcin Żmigrodzki
Scrum zadomowił się już na dobre w polskich organizacjach IT (firmach i działach). Teraz na krzywej hype cycle koncepcji biznesowych wspinają się tzw. frameworki rozszerzające zwinną filozofię na duże przedsiębiorstwa. W jednym z poprzednich wpisów (patrz: Defiliada koncepcji biznesowych) przedstawiłem analizę z 2016 roku koncepcji zarządzania projektami i wówczas Enterprise Agile Frameworks było na samym początku drogi, jeszcze przed dostrzeżeniem przez biznes, w fazie zwanej Innovation Trigger.
Rzut oka na raport State of Agile z 2019 roku (tytułowy wykres kołowy) pokazuje, że na razie jedną trzecią rynku zagarnął SAFe, a po nim Scrum of Scrums. Jednak opcji jest dużo więcej. Przykład rozwoju metodyk zwinnych dowodzi, że po okresie rozkwitu dziesiątków podejść, nastąpiło wymieranie i trzy czwarte rynku zagarnął Scrum z technikami zapożyczonymi z Kanban, XP, czy Lean. Moim zdaniem ten scenariusz powtórzy się również na poziomie enterprise agile. Na placu boju za parę lat pozostaną dwa lub trzy frameworki, przy czym pierwsze z nich zgarnie zdecydowaną większość rynku… Albo cała idea skalowanego agile’a ustąpi miejsca kolejnemu pomysłowi na organizację pracy dużych zespołów.
Poniżej widać diagram z Google Trends dotyczący zapytań o 'Enterprise Agile Framework’ od roku 2004 do dzisiaj. Jak widać nieznaczny trend wzrostowy wystąpił w 2016 roku i od tego momentu zainteresowanie tym hasłem utrzymuje się na stałym poziomie.
Wiele dużych korporacji sięga po różne modele skalowalnego agile. Powodów zainteresowanie może być wiele: chwilowa moda, chęć pochwalenia się przed kolegami z zarządów innych korporacji, naciski ze strony pionu HR, bo chwilowa moda lub chęć pochwalenia się przed kolegami z pionów HR innych korporacji, albo bardziej merytorycznie potrzeba pokazania kandydatom do pracy, że mimo swojej skali organizacja ma przyjazną kulturę organizacyjną lub wreszcie rzeczywiste pragnienie podniesienia efektywności organizacji, w sytuacji, gdy inne, bardziej tradycyjne podejścia nie przyniosły wystarczających owoców. Nie znam raportu Gartnera z 2019 roku (nie jest dostępny za darmo), ale według raportu z 2016 roku faktycznie ta koncepcja była na początku swojej drogi.
Metodyki zwinne świetnie sprawdzają się w niewielkich zespołach. Moim zdaniem oprócz rozmiaru takie zespoły powinny mieć jeszcze kilka cech:
- brak czynników nastawiających negatywnie do pracy, jak frustracja, niechęć do kolegów lub firmy, brak pieniędzy na podstawowe potrzeby,
- brak konfliktów na bazie rywalizacji o lepsze zadania, pensję, wdzięki współpracowników,
- brak próżniactwa społecznego w zespole, czyli „wożenia się” na pracy wykonywanej przez innych,
- conajmniej przeciętne kompetencje w obszarze merotyrycznym projektu, np. w danej technologii. Moim skromnym zdaniem, jeżeli cały zespół jest na poziomie „nie wiem, że nie wiem”, albo innymi słowy na początkowym wzniesieniu wykresu Krugera-Dunninga.
- wstawienie zespołu pod klosz Scruma, w którym mogą mieć poczucie autonomii.
Jak to się ma natomiast do dużych, macierzowych organizacji. Można tu znaleźć szereg czynników ograniczających stosowalność filozofii zwinnej:
- budżetowanie – na ogół w cyklu rocznym planuje się i rozlicza budżety działów, świat projektów jednak nie rządzi się taką kalendarzową dynamiką.
- hierarchia dowodzenia – kadra menadżerska bierze większe pieniądze za to, że jest odpowiedzialna za większy fragment organizacji, to oznacza, że będzie starała się kontrolować działania w podległych obszarach. Szczególnie ważne będą dla niej aspekty organizacji, za które menadżerowie mogą zostać zwolnieni lub dostać większą premię albo awans. Posiadanie władzy i rywalizacja o dostęp do pysznej termitiery, padłego mamuta, stada samic, czy pokoju na dwudziestym piętrze są stałą cechą naszego gatunku.
- raportowanie do zagranicznych właścicieli lub na giełdę – na duże firmy nakładane są rozmaite obowiązki kontrolne, które mogą zaburzać autonomię zwinnych zespołów.
- wielozadaniowość ludzi – macierzowość struktury organizacyjnej oznacza, że pojedynczy specjalista może przynależeć do wielu zespołów realizujących równolegle odmienne zadania. To z kolei prowadzi do błędnego planowania prac i przeciążenia ludzi.
- trudne sytuacje decyzyjne – istnieją sytuacje, których rozwiązywanie wspólnym konsensusem jest najprostszą drogą do wojny domowej. Znajomy opowiadał mi o zwinnym zespole, który stanął przed wyzwaniem podzielenia między siebie premii. Oczywiście pieniędzy było za mało, aby zadowolić wszystkich. Zawsze jest za mało, bo tu włącza się teoria perspektywy. Podwyżka o 10% przestaje cieszyć, gdy ta wredna jędza siedząca biurko obok otrzymała 15%.
Pomocą we wdrażaniu kultury zwinnej starają się być tzw. frameworki. Poniżej krótko jest scharakteryzowałem i dokonałem ich porównania. Najpopularniejsze to SAFe 5.0, Scrum@Scale, Nexus, model Spotify, Large Scale Scrum, DAD 4.
SAFe
Aktualnie najpopularniejszy framework zwinny, ale z pretendentem depczącym mu po piętach (patrz DAD). Obejmuje poziom zespołu, wielu zespołów, portfela, wielu portfeli projektów, w końcu kultury całej organizacji. Zaczyna od definiowania strategii i uzasadnień biznesowych, a następnie przechodzi przez poziom portfela i dochodzi do pojedynczego zespołu.
Na poziomie zespołu SAFe czerpie ze Scrum, wymieniając typowe role, spotkania i cykl życia projektu. Zakłada się, że zespoły zwinne pracujące w swoich obszarach kompetencji mogą łączyć się, aby wspólnie stworzyć funkcjonującą całość, np. zwinny zespół z marketingu może zacieśniać współpracę ze zwinnym zespołem IT.
Z perspektywy zakresu prac na najwyższym poziomie mamy strategię, potem portfolio wspierane przez Kanban, a następnie release’y, które zbierają wykonane funkcjonalności z różnych zespołów. Ciekawie w SAFe ukazana jest perspektywa finansowania strategii. Zakłada się partycypacyjne podejmowanie decyzji o wydatkach, budżetowanie strumieni korzyści, a nie projektów oraz kategoryzowania inwestycji z perspektywy horyzontów zdarzeń.
Typowe techniki to business/lean canvas, epic, agile release trains, design thinking, scrum, kanban i wiele innych.
To króciutkie omówienie może sprawiać wrażenie zbagatelizowania, czym SAFe jest, więc jeszcze raz podkreślę, że jest to rozległy framework wspierający zarządzanie całą organizacją oraz kilkanaście ról i dziesiątki technik. Jednak w przeciwieństwie do DAD, SAFe stara się pełnić rolę metodyki, czyli konkretnych wytycznych działań, które powinny być wykonywane, aby być zgodnym z tym frameworkiem.
Disciplined Agile Delivery
Zbiór wiedzy nazywany DAD adresowany jest przede wszystkim do zespołów produkujących oprogramowanie. Jednak DAD stara się podejść szeroko do tej kwestii. Nie tylko opisuje moment produkowania funkcjonalności, ale również ich projektowanie, utrzymanie, wdrażanie. Stąd twórcy proponują aż 10 ról, 21 procesów zarządzania projektami oraz inspiruje się całym wachlarzem różnych innych metodyk, 6 cyklów życia projektów, technik. Takim podejście przypomina nieco PMBOK Guide, które nie jest metodyką, a encyklopedią. Z resztą na pierwszy rzut oka DAD wygląda, jak groźna konkurencja tegoż w świecie zwinnych projektów… Zaraz, przecież PMI pozbył się tej konkurencji, wykupując ją w sierpniu zeszłego roku :).
Podsumuję krótko, bo DAD jest naprawdę obszerny i wymaga osobnego artykułu. DAD to encyklopedia dobrych praktyk zwinnych projektów poukładana trochę na wzór PMBOK Guide. Z niej dopiero tworzy się firmową metodykę do różnych celów: zwinnego zarządzania całym przedsiębiorstwem, albo poprowadzenia dużego projektu.
Możemy też spodziewać się, albo równoległego body of knowledge wypuszczonego przez PMI (w formie dodatku do PMBOK o nazwie Agile Practice Guide), albo rozszerzenia PMBOK Guide o framework DAD. Tak, czy siak życzę powodzenia na przyszłych egzaminach PMP!
LESS
Robi wrażenie konkretnej metodyki zarządzania wieloma zespołami. Koncentruje się na produkcji oprogramowania w dużych projektach. Podstawową jednostką organizacyjną jest zespół Scrumowy, zakres jest dekomponowany na sprinty z użyciem backlogu itp. To, co pojawia się ponad Scrum, to:
- Planowanie zakresu prac najpierw na poziomie wielu zespołów, a potem dopiero przydzielanie do konkretnego. Mamy też dwie role: product owner i area product owner.
- Product backlog refinement odbywa się również dwupoziomowo, dla wszystkich zespołów razem, a potem każdy indywidualnie.
- Analogiczna sytuacja dwupoziomowego działania ma miejsce przy retrospective.
- W przypadku sprint review sugeruje się dokonywanie tego przez wszystkie zespoły razem ale z użyciem tzw. bazaru. Przypomina to Obeya, postery na konferencji naukowej, albo metodę wernisażową. Klient ma zaprezentowane oddawane funkcjonalności i sam kieruje się tam, gdzie są rzeczy, które go interesują.
Na to została nałożona filozofia myślenia w stylu Lean, w której z konkretów wymienia się: kaizen, 5why, WIP, VA/NVA, rodzaje strat, czas cyklu i wizualizację w zarządzaniu, karty A3. Rola kadry menadżerskiej została zredukowana do komunikacji z właścicielem produktu i zapewniania finansowania, a także usuwania przeszkód administracyjnych. Metodyka LESS adoptuje szereg technik inżynierii oprogramowania, jak TDD, RAD, automatyzację testów.
Scrum of Scrums
Podobną do LESS filozofię skalowania Scruma przyjmuje SOS, czyli Scrum of Scrums. Duży zespół dekomponuje się na mniejsze 5-10 osobowe, różnica polega na tym, że każdy taki mały zespół wybiera przedstawiciela, który komunikuje się i współpracuje na wyższym poziomie. Backlog ma dwa poziomy, codzienne spotkania są dwupoziomowe, product owner ma dwa poziomy.
Z nowych rzeczy sugeruje się utworzenie Enterprise Action Team, czyli zespołu składającego się z kluczowych menadżerów w organizacji, z Chief Product Ownerem w składzie. Ta formuła może okazać się znajoma dla członków zarządów, którzy dotychczas zasiadali w komitetach sterujących projektów.
Scrum at Scale
Kolejny framework i kolejne dwupoziomowe klonowanie Scruma. Obie koncepcje, SoS i S@S używają nawet podobnych terminów: chief product owner, scrum of scrums, EAT. Z nowości jest tutaj nawet Chief Scrum of Scrums Master w skrócie SOSM oraz Executive Meta Scrum Team, taki grupowy product owner na poziomie całej firmy. Koncepcja S@S zakłada fraktalność organizacji, więc jak mamy Scrum of Scrums (SoS), to za chwilę możemy mieć SoSoS, czyli trzy poziomową skalowalność scruma. Z resztą załączam fraktalną strukturę organizacyjną z dokumentacji tej metodyki.
Model Spotify
To właściwie nie tyle jest model zwinnego prowadzenia prac (tu rozległy artykuł na ten temat), co ogólne wytyczne dotyczące kultury organizacyjnej i sposobu formowania zespołów. Same praktyki zwinne w modelu Spotify pozostawione są poszczególnym zespołom. Spotify podkreśla, że właśnie częścią zwinnej kultury jest pozostawienie swobody zespołom, co do sposobu organizacji pracy. A to oznacza, ograniczoną egzystencje standardów.
Techniki, które Spotify promuje to: daily standup, retrospective, fail board, wspólnoty praktyków zwane tu gildiami, małe, autonomiczne zespoły, rola właściciela produktu, dekompozycja strategii na mniejsze, bardziej operacyjne części, które są zarządzane przez owe zespoły.
Plusem Spotify jest to, że skupia się nie tylko na produkcji nowych funkcji i usług przez zespoły IT, ale stara się zapewnić bazę do strategicznego zarządzania firmą. Z mojej perspektywy słabością jest zaś to, że ze względu na niewielką ilość konkretnych reguł, ról, praktyk i technik, nie jest metodyką. To oznacza, że musi polegać na zapale, konsekwencji i osobowości zarządu korporacji. Gdy tego zabraknie, cała układanka może się szybko rozsypać.
Podsumowanie
Cechą wspólną wszystkich wymienionych frameworków jest:
- Silne skupienie się na daniu ludziom autonomii, co jest zgodne z Agile Manifesto, na które się powołują.
- Przyjęcie, że najmniejszą jednostką organizacyjną jest zespół zwinny, zwykle Scrumowy.
- W związku z poprzednim punktem pojawienie się typowo scrumowych ról.
- Conajmniej dwupoziomowa dekompozycja zakresu prac: poziom Scrum of Scrums i poziom podstawowy Scruma.
- Użycie backlogu jako podstawowego narzędzie planowania zakresu.
W mojej osobistej opinii rywalizację wygrają najbardziej rozbudowane frameworki, które skutecznie przekonają zarządy dużych firm, czyli SAFe i DAD. Pozostałe mogą się rozwodnić w krajobrazie różnych mutacji Scruma. Bo, gdy przychodzi do uzwinnienia całej firmy, już nie da się działać lokalnie, trzeba przekonać prezesa.
bizlog
utworzone przez Marcin Żmigrodzki
Jak tylko PMI ogłosił, że zaczyna wysyłkę polskiej wersji PMBOK Guide 6, postanowiłem, że muszę ją mieć. Muszę, bo teraz pokażę, jak fatalną robotę wykonał zespół złożony z naszej konkurencji i ochotników PMI Polska. Zjadę ją z góry na dół za polskawe sformułowania, jakość wydruku, czy zgodnosć z oryginałem. I jakie są pierwsze wrażenia?
Otóż zawiodłem się. Zawiodłem się na własnych oczekiwaniach, bo książka jest po prostu wydana solidnie. Dużo lepiej niż angielski oryginał! Uczestników szkoleń wprost zniechęcam do kupowania angielskiej wersji ze względu na tandetny papier i upiorne szare tło, które powoduje, że literki zlewają się. W przypadku polskiego wydania jest o niebo lepiej. Gratuluję nie popełnienia błędu z amerykańskiej edycji.
Jeżeli chodzi o jakość tłumaczenia, to również stoi na wysokim poziomie. Oprócz paru drobiazgów, które wymieniam poniżej, naprawdę warto docenić włożony wysiłek.
Merytoryczna zawartość książki jest jeden do jeden taka sama, jak wersji amerykańskiej, więc te same krytyczne uwagi przełożyłbym na polską. Ale celem projektu tłumaczeniowego nie było poprawianie PMBOK Guide, więc tutaj również nieuczciwe byłoby krytykowanie.
Z książki PMBOK Guide korzysta się głównie na trzy sposoby:
- W sytuacjach problemowych, jak z encyklopedii
- Podczas przygotowywania się do egzaminu PMP, a czasem CAPM i PgMP.
- W sytuacji zagrożenia zdrowia w czasie bójki w barze.
PMBOK Guide jako encyklopedia
Jak już wspomniałem forma książki jest na dobrym poziomie. Gdybym miał się czepiać, choć nie powinienem, ale gdybym miał, to można by pokusić się o troszkę inaczej wykonany grzbiet, który pozwalałby na szerokie otwieranie bez obawy, że książka się rozpadnie.
Książka, co wynika oczywiście z charakteru projektu tłumaczeniowego, nie wyzbyła się kilku słabości. Ale domyślam się, że polski zespół nie mógł był ingerować w jej merytorykę. Przykładowo nadal niejasne jest rozróżnienie pojęcia portfel i program (strona 13). Obecny jest cykl życia grupy, czy liczenie kanałów komunikacji. Ale to jest uwaga raczej do twórców oryginału.
Niektóre terminy pozostawiają pewien niedosyt, jak na przykład „zarządzanie integracją”, który, wydaje mi się, lepiej brzmiałoby jako „zarządzanie integralnością”. Jeszcze ciekawiej przetłumaczono „servant leader” jako „przywódca służebny”. Jeden ze studentów rzucił kiedyś „lider wspierający” i to wydaje mi się trafniejsze. Albo „Quality function deployment” jako „Rozwinięcie funkcji jakości”, zapomniawszy, że potocznie mówi się w przypadku tej techniki o „domku jakości”. Albo „Rejestr wiedzy nabytej” – termin, którego nigdy nie spotkałem w języku polskim, choć spotkałem termin „Baza wiedzy”. Z drugiej strony nie ma jeszcze w polskim języku ugruntowanych odpowiedników tych terminów, więc może lepiej byłoby zostawić angielską wersję.
Z drugiej strony podoba mi się kilka terminów, których już długo nie umiałem zgrabnie przetłumaczyć, jak „contingency reserve” na po prostu „rezerwa projektowa”. I w punkt!
PMBOK Guide jako wsparcie na drodze do PMP
Tutaj mam nieco więcej wątpliwości. Wynikają one głównie z faktu, że nie mam zupełnie pojęcia, czy polskie tłumaczenia pytań na egzaminie były weryfikowane w zderzeniu z polską wersją książki. Raczej sądzę, że w ogóle nie były, na co wskazywałby fakt, że pytania pojawiły się kilka lat temu, a polska książka dopiero teraz. Doszły mnie słuchy, że PMI udostępnił słownik terminów, jednak brak precyzyjnych informacji w tym względzie powoduje, że kandydat do PMP powinien być czujny. Raczej zachęcałbym do przygotowywania się z oryginału angielskiego, wtedy nie ponosimy ryzyka, że przekład się gdzieś rozjechał.
Przykładowo, jak przetłumaczylibyście Develop Project Charter. Stwórz kartę projektu? Opracuj kartę projektu? Polski przekład mówi Opracowywanie karty projektu. Językowo jest to ładniejsze niż moje propozycje, ale angielska wersja napisana jest w trybie rozkazującym. I ów tryb rozkazujący wprowadzano od kilku wersji intencjonalnie, aby uprościć zapamiętywanie nazw.
Poza tym proces Przeprowadzanie walidacji zakresu nie ułatwia zrozumienia, że chodzi o Odbiory prac. Zaś Zarządzanie jakością w powszechnym rozumieniu już zawiera w sobie Kontrolowanie jakości i Planowanie jakości. Natomiast tutaj mamy trzy odrębne procesy. Dla usprawiedliwienia dodam, że w wersji angielskiej też tak uczyniono.
Konkurs na najdłuższą nazwę, która niestety odbiega od oryginału wygrało Wprowadzanie w życie odpowiedzi na ryzyko. Implement risk responses można wszak było przetłumaczyć jako Wdróż scenariusze ryzyk, albo Wdróż reakcje na ryzyka.
Czepiam się drobiazgów, ale na egzaminie PMP dobre zapamiętanie nazwy decydować o końcowym wyniku.
Z drugiej strony kilka tłumaczeń jest bardzo sprytnych, i zgrabnie i precyzyjnie oddających angielski termin. Przykładowo work performance data przełożono na dane o wykonaniu prac. Fajne 🙂 może przyjmie się w codziennych rozmowach. Piszę to bez ironii, bo warto rozróżniać dane od ich interpretacji, czyli informacji.
W kilku miejscach pozostawiono oryginalne terminy, jak EEF i OPA, albo SS, FS, FF, SIPOC, nazwy typów kontraktów i uważam to za bardzo trafiony pomysł. Ciężko o dobry ich przekład, a na egzaminie może to sporo ułatwić, szczególnie, ze w powszechnym obiegu są skrótowce a nie tylko ich pełne rozwinięcia.
Jednak w kilku miejscach wprowadzono zaskakujące terminy, jak „wykres paskowy”, który po krótkim śledztwie okazuje się być „wykresem Gantta”, co na egzaminie może zaciemnić obraz. Drobiazgi, a cieszą 🙂
Podsumowanie
Jako encyklopedię na temat technik zarządzania projektami, uważam, że warto kupić polskiego PMBOKa. Nawet bardziej warto niż angielskiego. Widać, że włożono sporo wysiłku w piękne tłumaczenie, choć nie zawsze wierne, co tylko świadczy na plus. Książka zestawia dziesiątki technik i być może dotrze teraz do szerszego grona praktyków prowadzenia projektów. Szczere gratulacje dla zespołu.
Jeżeli jednak zamierzacie przygotować się do PMP, to zachęcałbym do zapoznania się z angielską wersją, szczególnie, że członkowie PMI mogą pobrać ją za darmo w postaci PDF. Brak pewności, że polskie tłumaczenia pytań są w 100% zbieżne z polską książką powoduje, że możemy sobie niepotrzebnie podnieść ryzyko.
Ps.
Zastanawia mnie zabawna notatka we wstępie, która raczej mogłaby się znaleźć na opakowaniu fajerwerków, albo paralotni, a nie książki. Chyba, że to księga czarów z Harrego Pottera. „PMI nie daje gwarancji, rękojmi, ani też nie utożsamia się z dokładnością lub zawartością tłumaczenia. Każdy, kto wykorzystuje informacje zawarte w niniejszym tłumaczeniu, czyni to na własne ryzyko…” A już miałem nadzieję, że będę mógł na kogoś zrzucić winę za opóźnienia w moich projektach.
Pps.
Podobnie jak angielska wersja i polska jest groźnym narzędzie w rękach krewkiego kierownika projektów. Ma grubość 3,5 cm i waży 1696 gramów (tak, zważyłem ją!). To oznacza, że na krótkim dystansie może pełnić funkcję zarówno obronną, jak i zaczepną.
utworzone przez Marcin Żmigrodzki
Przedstawiam kolejną paczkę narzędzi pomagających w zarządzaniu małym zespołem. Tym razem na warsztat wziąłem Acelo, ActiveCollab, Axosoft, Avaza, Azendoo, Backlog, Blossom i Binfire.
Accelo
Przeznaczenie
Accelo za punkt wyjścia bierze klienta, dla którego realizujemy projekty i mniejsze zlecenia. Do klienta można dopisywać projekty i zadania, które następnie są obciążane kosztami. W efekcie jest to raczej system do zarządzania firmą projektową niż projektami.
Accelo pretenduje to bycia swego rodzaju ERP dla firmy projektowej małej lub średniej wielkości. Dla korporacyjnych klientów i dużych projektów jest moim zdaniem jednak zbyt ubogie. W mniejszym stopniu jest to jednak narzędzie do zarządzania zespołem projektowym.
To rozwiązanie spisze się przede wszystkim w firmach, które realizują wiele zleceń na rzecz wielu klientów, które są rozliczane w trybie Time&Material, a jednocześnie zarządza projektami w innym narzędziu.
Główne funkcje
- Zarządzanie klientem i kontaktami z nim.
- Rejestrowanie zapytań, kontraktów, rozliczeń z klientem.
- Podstawowa zarządzanie zakresem i czasem w projekcie.
- Przypusywanie ludzi, stawek i kosztów do zadań.
- Wystawianie faktur za prace.
- Zarządzanie zgłoszeniami od klienta.
- Zarządzanie wydatkami w projektach.
- Śledzenie obciążenia zasobów ludzkich.
- Raporty finansowe, np. analiza dochodowości firmy, kosztów ludzi etc.
- Prosty lejek sprzedażowy.
- Tablica Kanban z wieloma funkcjami filtrowania.
- Śledzenie czasu realizacji zadań.
- Monitorowanie zadań wybranego człowieka.
- Prosta tablica ogłoszeniowa.
- Karty pracy ludzi.
- Przesyłanie wiadomości między użytkownikami.
Plusy
- Ciekawie rozwiązane zarządzanie klientami na projekty.
- Monitorowanie kosztów projektów na poziomie firmy.
- Elementy zarządzania portfelem projektów.
- Bardzo ciekawie rozwiązana funkcja kart pracy, można je wyświetlić dziennie, tygodniowo, rejestrować na podstawie deklaracji i czas rzeczywisty. Możemy mieć wiele timerów w jednym zadaniu, włączać je, zawieszać i uruchamiać dowolnie.
Minusy
- System jest dość rozbudowany przez co nauka jego obsługi może trochę zająć.
- System w wymiarze zarządzania zadaniami mógłby być nieco bardziej ergonomiczny.
- Brak wielu typowych funkcji zarządzania projektem kaskadowym i zwinnym. Z obszaru zwinnego jest właściwie tylko tablica Kanban, jednak dość złożona.
- Ze względu na złożoność i konieczność włączenia pracowników z wielu obszarów organizacji raczej nie da się go używać z marszu. Rozwiązanie wymaga wdrażania i szkolenia.
Koszt
- Nie ma sensu używać tego narzędzia w wariancie indywidualnym. W takiej sytuacji całkowicie wystarczy nam arkusz kalkulacyjny lub prosty systemik typu Harvest.
- W wariancie 9-osobowego zespołu system kosztuje w skali roku 33 700 zł.
- Dla firmy posiadającej 30 osób koszt roczny wyniesie ok. 114 000 zł. i jest to całkiem drogie narzędzie w porównaniu do innych.
ActiveCollab
Przeznaczenie
Mam problem z oceną tego pakietu. Nie jest to ani oprogramowania do zarządzania projektem kaskadowym, bo brakuje podstawowych funkcjonalności, jak ustrukturalizowany zakres, wykres Gantta ze ścieżką krytyczną, precyzyjniejsze liczenie budżetu. Nie jest to też narzędzie dla zespołów zwinnych, bo nie ma przejrzystej listy zadań w postaci choćby Kanbana. System niespecjalnie wspiera też po prostu zarządzanie zadaniami. Moje wrażenie jest takie, że twórcy postanowili stworzyć perfekcyjny kompromis, który nie zapewnia żadnego typowego rozwiązania, ale załatwia dużo spraw po trochu. Jest tutaj nawet opcja tworzenia szacunków kosztów projektów, która najwyraźniej nie jest połączona spójnym workflow z normalnym projektem. Jednak, jak na oprogramowanie do zarządzania porfelem projektów brakuje tu mnóstwa narzędzi kontrolnych i planistycznych.
Główną cechą wyróżniającą jest możliwość zaimportowania danych o projektach z bardzo wielu konkurencyjnych platform. Tylko… nie rozumiem, w jakim celu ktoś miałby migrować z tamtych rozwiązań do Activecollaba.
Negatywnie oceniam to narzędzie, bo prawdę mówiąc, nie wiem, dla kogo ono jest adresowane. Być może robię krzywdę Activecollab, bo z opisów na stronie wynika, że to oprogramowanie ma bardzo wiele opcji, ale ja ich nie znalazłem w trialu.
Główne funkcje
- Dwupoziomowa struktura zakresu prac.
- Lista dyskusyjna w projekcie.
- Zarządzanie dokumentami w projekcie.
- Rejestrowanie wydatków w projekcie.
- Widok kalendarza dla zadań pojedynczych ludzi i zespołów.
- Tworzenie faktur do projektu.
- Raport obciążenia ludzi w projektach.
- Tworzenie ofert.
- Migracja danych z innych platform.
Plusy
- Możliwość przeniesienia danych z konkurencyjnych rozwiązań do tego.
Minusy
- Brak precyzyjnie zdefiniowanego odbiorcy i modelu użycia tego narzędzia.
- Dziwnie dobrany zakres funkcjonalności.
Koszt
- Koszt na jednego użytkownika to 300 zł. rocznie, jednak nie widzę powodu, dla którego ktoś miałby z tego korzystać dla osobistych potrzeb.
- Dla małego zespołu to 2 700 zł. rocznie.
- Dla średniej firmy to 9 000 zł. rocznie
Avaza
Przeznaczenie
Avaza to przyjemne w użyciu i całkiem rozbudowane narzędzie do zarządzania firmą projektową. Skupiono się przede wszystkim na funkcjonalności planowania i kontroli projektów z poziomu firmy, a w mniejszym na współpracy zespołu projektowego. System potrafi rejestrować koszty, czas pracy oraz postęp realizacji zadań. Generuje faktury i gromadzi informacje o płatnościach. Na koniec wyświetla kilkadziesiąt raportów głównie finansowych.
Samo prowadzenie projektu zostało sprowadzone do listy zadań, które mogą zostać zgrupowane w sekcje i wzbogacone o informacje na temat dat, kosztów, zużycia ludzi.
Avaza zatem jest adresowana przede wszystkim do średniej wielkości firmy, które zarabiają na projektach.
Główne funkcje
- Dodawanie zadań do zakresu na dwóch poziomach.
- Tablica Kanban, choć nieco ograniczona w dostosowaniu do potrzeb.
- Uproszczony wykres Gantta
- Komentowanie zadań, ustalanie dat, dodawanie załączników, ale brak zależności między zadaniami.
- Planowanie i rozliczanie czasu pracy w zadaniach.
- Podgląd własnych zadań i kalendarza zespołu.
- Timer rejestrujący rzeczywisty czas pracy w zadaniu.
- Rejestrowanie wydatków w zadaniach.
- Generowanie ofert, całkiem przyjemnie zaprojektowane.
- Fakturowanie i rejestrowanie płatności.
- Rozbudowany moduł raportowy!
Plusy
- Bardzo rozbudowane raportowanie.
- Rejestrowanie czasu pracy i kosztów w projektach.
- Podstawowe funkcje zarządzania projektami.
Minusy
- Brak podstawowych funkcji zarządzania projektem zwinnym, jak Sprinty i raporty.
- Bardzo uproszczone zarządzanie projektem kaskadowym, brak na przykład większości typowych funkcji Gantta.
- Niewiele funkcji komunikacji w zespole.
- Brak dokumentowania projektu.
Koszt
- W przypadku indywidualnego korzystania Avaza kosztuje 0 zł.
- Dla małego zespołu będzie to koszt na poziomie 4 300 zł. rocznie.
- Zaś dla średniej wielkości firmy to koszt 16 460 zł. rocznie.
Azendoo
Przeznaczenie
Azendoo to moim zdaniem system dedykowany do zarządzania niewielkim zespołem lub firmą składającą się z kilku małych zespołów. Zawiera głównie funkcje realizujące podejście Kanban do zarządzania pracą zespołu.
Azendoo jest solidnie napisane, choć na rynku można znaleźć wiele takich narzędzi. Nie znajduje tutaj żadnego wyróżnika w stosunku do ofert konkurencji.
Główne funkcje
- Tablica Kanban z możliwością ustawiania deadline zadania, dodawania podzadań, komentowania zadań.
- Tablica aktywności.
- Widok kalendarza.
- Burnup chart.
- Zestawienie obciążenia pracą zespołu.
Plusy
- Prosty interface, choć widziałem bardziej dopracowane GUI.
- Ciekawie opracowany widok aktywności w projekcie.
- Wykres wypalania.
- Śledzenie błędów.
Minusy
- Brak wsparcia projektów kaskadowych.
- Brak raportowania projektów, elementarne raportowanie zespołu.
Koszt
- Dla indywidualnych osób Azendoo kosztuje 360 zł. rocznie.
- Dla małego zespołu koszt tej aplikacji to 7 290 zł. rocznie.
- Dla średniej firmy to roczny koszt 24 300 zł.
Backlog
Przeznaczenie
Backlog niestety dużą część funkcji pokazuje dopiero od poziomu płatnych wersji, więc jedynie mogłem się domyślać. Ogólne wrażenie jest takie, że to system dedykowany do średniej wielkości zespołów pracujących w trybie kaskadowym. Wbrew nazwie aplikacji nie znalazłem nigdzie klasycznego Backlogu takiego, np. jak w Taiga albo chociaż Trello.
Główne funkcje
- Widok Gantta (dostępny tylko w płatnej wersji).
- Zarządzanie zagadnieniami w projekcie.
- Dokumentowanie projektu w formie wikipedii.
- Zarządzanie dokumentami.
- Burndown chart (dostępny w płatnej wersji).
Plusy
- Na poziomie darmowym aplikacja nie oferuje zbyt wiele.
Minusy
- Zgodnie z założeniami powyższych recenzji nie oceniam funkcji, których sam nie widziałem. Więc głównym minusem jest to, że w darmowej wersji po prostu niewiele jest dostępne.
- Funkcji w wersji darmowej jest raczej niewiele i uznałbym Backlog za jedno z mniejszym narzędzi na rynku.
Koszt
- Na poziomie indywidualnym Backlog nic nie kosztuje.
- Dla małego zespołu Backlog kosztować będzie 1 680 zł. rocznie.
- Dla średniej wielkości firmy trzeba zaplanować budżet na poziomie 4 800 zł. rocznie.
Casual
Przeznaczenie
Wyróżniającą cechą Casual jest graficzne przedstawienie listy zadań w formie diagramu sieciowego. System pozwala na zaplanowanie zadań, przypisanie dat i ludzi a następnie ładną prezentację zakresu projektu. Niestety brakuje w nim innych funkcjonalności spotykanych w systemach tej klasy, jak raportowanie, widok kalendarza, Gantta, czy Kanbana.
System raczej nadaje się do pracy indywidualnej lub małego zespołu, gdy konieczne jest przejrzyste zaprezentowanie zakresu prac. Nie przyda się on raczej w sytuacji, gdy potrzebny jest nadzór nad ludźmi lub analiza efektywności prac. Przykładowo zadania można odznaczać tylko albo niewykonane, albo wykonane, bez stanów pośrednich w rodzaju 35%.
Główne funkcje
- Lista zadań.
- Komentowanie zadań.
- Strukturalizacja zakresu za pomocą diagramu sieciowego.
- Alokowanie zasobów do zadań.
- Załączanie dokumentów do zadań.
Plusy
- Silną stroną jest prostota systemu.
- Wizualizacja struktury prac.
Minusy
- Casual robi bardzo niewiele ponad prezentację struktury zakresu.
Koszt
- Dla pojedynczego użytkownika system kosztuje 336 zł. na rok.
- Mały zespół będzie musiał zapłaci rocznie 1 680 zł.
- Średniej wielkości firma musi przygotować się na koszt 6 384 zł. rocznie.
Planless
Przeznaczenie
Bardzo przyjemne narzędzie. Centralnym punktem jest lista zadań, które można przypisać do zespołu i wyświetlić w postaci uproszczonego Gantta. Ciekawym rozwiązaniem obecnym w dużym systemach PMIS jest możliwość przypisania kompetencji do zadania, a dopiero potem konkretnego człowieka. Kompetencja może mieć stawkę kosztową, ale nie mamy na nią limitu dostępności.
Z uwagi na fakt, że Gantt jest faktycznie mocno uproszczony, system nie nadaje się do zarządzania większymi kaskadowymi projektami, jednak plusem jest to, że dzięki temu narzędzie łatwo opanować. Planless to narzędzie adresowane do małych zespołów i małych firm, ale podoba mi się, że bardzo spójnie zaprojektowano funkcjonalność w kontekście celu wykorzystania tego programu. Muszę dodać, że Planless jest ewidentnie zaprojektowany pod małe zespoły pracujące w trybie Time&Material, nie ma tutaj innych kosztów zadań.
Główne funkcje
- Dodawanie zadań, do których można toczyć dyskusje, planować daty i pracochłonność.
- Rejestrowanie czasu pracy.
- Zarządzanie użytkownikami i umiejętnościami.
- Rozliczanie kosztów projektów.
- Dodawania zdarzeń (zadań bez kosztów).
Plusy
- Prostota i wysoka ergonomia narzędzia.
- Płaska taryfa niezależnie od liczby użytkowników.
Minusy
- Mała liczba funkcji związanych ze współpracą.
- Brak funkcji kontroli projektów oprócz jedynie rozliczania kosztów.
- Brak tablicy Kanban.
- Bardzo prosty wykres Gantta.
Koszt
- Dla pojedynczego użytkownika system w skali roku kosztować będzie 2 100 zł.
- Dla zespołu będzie to koszt ok. 2 100 zł. rocznie.
- A dla średniej wielkości firmy to 2 100 zł. rocznie
Jak widać stawka za używanie narzędzia jest płaska, co czyni go atrakcyjnym rozwiązaniem przede wszystkim dla średniej wielkości firm.
Tym kończymy trzecią część przeglądu narzędzi do zarządzania małym zespołem projektowym i nie tylko. Na liście mam jeszcze: Binfire, Freedcamp, Favro, Flowlu, Fluxes, Futuramo, Getflow, Hive, Hygger, Intervals, Jira, Kanbantool, Maistertask, Ntask, Paymo, Productboard, Productive, ProjectManager, Proworkflow, Quire, Redbooth, Reqtest, Resourceguru, Smartsheet, Scoro, Slack, Squidhub, Taskworld, Teamweek, Teamwork, Teamup, Tempo, Testbench, Todoist, Todo, Twist, Upwave, Vabotu, Zenkit, Zoho. Jak widać całkiem dużo mi jeszcze zostało 🙂 Kto by pomyślał, że ten rynek jest tak rozdrobniony.
Równolegle postanowiłem stworzyć tabelkę, która w sposób syntentyczny porówna wszystkie analizowane narzędzie. Możecie ją znaleźć pod tym adresem: Porównanie narzędzi.
