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.
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:
Jak to się ma natomiast do dużych, macierzowych organizacji. Można tu znaleźć szereg czynników ograniczających stosowalność filozofii zwinnej:
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.
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.
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!
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:
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.
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 ScaleKolejny 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.
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ć.
Cechą wspólną wszystkich wymienionych frameworków jest:
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.
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:
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!
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ą 🙂
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ą.
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.
AcceloAccelo 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.
ActiveCollabMam 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.
AvazaAvaza 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.
AzendooAzendoo 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.
BacklogBacklog 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.
CasualWyróż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%.
PlanlessBardzo 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ń.
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.
Poniżej znajdziecie podsumowanie narzędzi wspierających zarządzanie małym zespołem projektowym. Utworzyłem prostą tabelkę według kluczowych kryteriów, którą dla wygody można sortować, więc możecie szybko znaleźć najciekawsze systemy z perspektywy różnych kryteriów.
Przedstawione oceny oczywiście są subiektywne, jednak dokonałem ich na podstawie analizy kilkudziesięciu dostępnych w internecie narzędzi. Wydaje mi się, że mam całkiem szeroki ogląd na to, jak można wesprzeć mały zespół.
Poniższe oceny narzędzi do zarządzania projektami są oparte na napisanych wcześniej recenzjach, które można znaleźć tutaj: Przegląd narzędzi do zarządzania małym zespołem projektowym część 1, część 2, część 3.
| Nazwa | Cena dla 1 użytkownika [rocznie zł] | Cena dla zespołu 9 ludzi [rocznie zł] | Cena dla 30 osobowej firmy [rocznie zł] | Ergonomia (1-5) | Użyteczność dla zwinnych (1-5) | Użyteczność dla kaskadowych (1-5) | Użyteczność dla pracy zadaniowej (1-5) | Czas uczenia się [h] |
|---|---|---|---|---|---|---|---|---|
| Kanboard | 0 | 0 | 0 | 3 | 4 | 0 | 2 | 1 |
| Openproject | 1111 | 2227 | 6682 | 3 | 2 | 3 | 1 | 3 |
| Proofhub | 2160 | 4272 | 4272 | 3 | 4 | 2 | 3 | 2 |
| Taiga | 240 | 2160 | 7200 | 4 | 5 | 0 | 2 | 2 |
| Trello | 0 | 4315 | 14385 | 5 | 4 | 0 | 4 | 0.5 |
| Clickup | 0 | 2172 | 12765 | 5 | 5 | 0 | 2 | 1 |
| Wrike | 2350 | 4704 | 35700 | 4 | 3 | 4 | 2 | 4 |
| Asana | 0 | 0 | 594 | 3 | 4 | 3 | 2 | 6 |
| Basecamp | 0 | 4000 | 4000 | 3 | 3 | 1 | 3 | 3 |
| Bitrix | 0 | 0 | 6710 | 3 | 2 | 3 | 1 | 5 |
| Harvest | 518 | 4500 | 15552 | 4 | 3 | 0 | 0 | 1 |
| Monday | 816 | 3792 | 19152 | 4 | 4 | 3 | 2 | 3 |
| Nozbe | 228 | 2388 | 2388 | 4 | 3 | 2 | 4 | 2 |
| Nutcache | 430 | 2880 | 8640 | 4 | 4 | 1 | 3 | 3 |
| Planless | 2100 | 2100 | 2100 | 5 | 3 | 1 | 4 | 0.5 |
| Activecollab | 300 | 2700 | 9000 | 2 | 2 | 1 | 1 | 2 |
| Accelo | – | 33700 | 114000 | 3 | 3 | 3 | 1 | 8 |
| Avaza | 0 | 4300 | 16460 | 4 | 2 | 3 | 0 | 5 |
| Azendoo | 360 | 7290 | 24300 | 3 | 3 | 0 | 3 | 1 |
| Backlog | 0 | 1680 | 4800 | 3 | 3 | 3 | 2 | 3 |
| Casual | 336 | 1680 | 6384 | 4 | 2 | 0 | 2 | 0.5 |
Zapisz się na nasz newsletter