8 sprawdzonych kryteriów wyboru
metodyki zarządzania projektami

Artykuły eksperckie | 07.04.2016 | Czas czytania: 4 minuty

Zapewne każdy z czytelników spotkał się z pojęciem metodyki – czyli zbioru ogólnych zasad zarządzania projektami. Opracowanych metodyk jest obecnie bardzo wiele. Stąd też wybór tej właściwiej nie należy do rzeczy łatwych. Jakimi kryteriami kierować się przy wyborze? Czy przy wyborze metodyki należy kierować się modą (patrz popularne marketingowe hasła „Jesteśmy Agile”,  „Mamy Scrum we krwi”)? Czy aby na pewno wszystkie projekty da się zrealizować metodykami zwinnymi? Odpowiedzi na te pytania postaram się udzielić w dalszej części artykułu.

Kryterium 1 – Znajomość rozwiązania

Każda z metodyk zwinnych oraz klasycznych zakłada, że cel projektu jest dobrze zdefiniowany. Metodyki tradycyjne powinny być jednak stosowane w projektach posiadających znane sposoby rozwiązania problemu. Jeżeli sposób nie jest znany, należy użyć metodyk zwinnych. Tłumacząc bardziej obrazowo, znajomość rozwiązania czyli np. tworzenie kolejnej wersji tego samego systemu, wdrażanie kolejnego sklepu internetowego, różniącego się tylko produktami, informatyzacja urzędu z dobrze znaną liczbą systemów i stanowisk jest przesłanką do wykorzystana metodyk tradycyjnych. Natomiast portal typu start-up, ze względu na innowacyjność oraz niepowtarzalność rozwiązania, jest idealnym przykładem wykorzystania metodyk zwinnych.

Kryterium 2 – Wielkość projektu

Zaleca się wykorzystanie metodyk klasycznych do dużych i bardzo dużych projektów. W tym wypadku trudno sobie bowiem wyobrazić, żeby wielomilionowe projekty były realizowane bez znanego celu i sposobu rozwiązania. Metodyki zwinne lepiej nadają się do projektów mniejszych. Nic nie stoi jednak na przeszkodzie, żeby projekt całościowo zarządzany  w sposób klasyczny, posiadał moduły tworzone zwinnie. Jest to tzw. model hybrydowy. W takim wypadku cały projekt dzielony jest na podprojekty, z których każdy może być zarządzany przy użyciu innej metodyki.

Metodologie zarządzania projektami

 Różnice i podobieństwa między modelami tradycyjnymi, zwinnymi i hybrydowymi

Kryterium 3 – Stabilność wymagań

Tradycyjne metodyki wymagają stabilnych wymagań projektowych, gdyż w trakcie prac nie dopuszcza się do ich zmian. W związku z tym, jeżeli wymagania nie są sprecyzowane, bądź też jeżeli z doświadczenia wiemy, że klient ma tendencję do ich modyfikacji, wówczas jedynym wyjściem jest użycie metodyk zwinnych.

Kryterium 4 – Dostępność klienta

Teoretycznie, w przypadku metodyk tradycyjnych, klient może być dostępny dla zespołu projektowego dopiero podczas odbioru oraz testów akceptacyjnych. W praktyce jednak, udział klienta jest wymagany przynajmniej jeszcze na etapie analizy wymagań (patrz często spotykane w Specyfikacji Istotnych Warunków Zamówienia stwierdzenie „poniższy punkt zostanie uszczegółowiony na etapie analizy”). O ile w metodykach klasycznych nie zakłada się potrzeby kontaktu z klientem przez cały czas „życia” projektu, w metodykach zwinnych klient jest integralną częścią zespołu projektowego i cały czas wspiera developerów. Stąd też jego dostępność jest czynnikiem kluczowym do wyboru metodyki. Osobiście znam jednak przypadki, w których w roli product ownera obsadza się pracowników wykonawcy. Są to jednak bardzo rzadkie przypadki, wymagające ogromnego zaufania pomiędzy klientem, a firmą zewnętrzną.

Kryterium 5 – Tolerancja na zmiany w budżecie oraz zakresie

Projekty realizowane w metodykach klasycznych mają zawsze ściśle określony zakres oraz koszt – są wykonywane jako fix-price. W przypadku metodyk zwinnych, ze względu na zmieniające się wymagania oraz priorytety, trudno jest oszacować całkowity koszt projektu. Stąd też, jeżeli budżet klienta jest stały i nie może zostać zwiększony, na koniec projektu dostarczane są funkcjonalności o największych priorytetach. Innymi słowy może zostać zmieniony/zmniejszony zakres prac. Świadomość klienta w tym względzie jest kluczowa, a brak zrozumienia tej kwestii zawsze powoduje problemy.

Kryterium 6 – Czas dostarczenia

Głównym założeniem metodyk klasycznych jest dostarczenie klientowi gotowego rozwiązania dopiero na koniec projektu. W przypadku metodyk zwinnych pełne, działające rozwiązanie, jest efektem końcowym każdej iteracji. Ponieważ iteracje trwają od 1-4 tygodni, istnieje możliwość szybkiego wdrażania produkcyjnego nowych funkcjonalności.

Kryterium 7 – Zespół

Kompetencje zespołu projektowego są jednym z najważniejszych czynników wyboru metodyki. W idealnym świecie każdy zespół składa się z kompetentnych i doświadczonych osób, jednak w dobie ciągłych problemów z zasobami nie jest to wcale takie oczywiste. W przypadku wyboru metodyki, wiedząc, że mamy do dyspozycji słabszy zespół, wybierzmy metodykę klasyczną. W metodykach zwinnych zespól jest tzw. „samoorganizującym się ciałem”,  musi być doświadczony, znać się od dłuższego czasu, posiadać umiejętność estymowania zadań, mieć dobre zdolności komunikacyjne.  W przypadku metodyk klasycznych, braki zespołu mogą zostać zrównoważone przez nadzorujących zespół kierowników. Mogą oni ewentualnie dokonać zmian w przydziale zadań, w składzie zespołu, co z kolei nie powinno mieć miejsca w zespołach pracujących w projektach realizowanych przy użyciu metodologii zwinnych.

Kryterium 8 – Integracja z systemami zewnętrznymi

Punkt ten może początkowo wydawać się niezrozumiały, gdyż obecnie większość systemów integruje się z innymi systemami. Niemniej w przypadku dużych projektów, w których wiele aplikacji tworzonych jest równocześnie i które muszą komunikować się ze sobą, np. przy użyciu szyny danych, lepszym wyborem jest użycie metodologii klasycznej. Dzięki niej będziemy mieli zawsze zdefiniowane sposoby komunikacji i zespól będzie mógł wykonać odpowiednie mock-upy. W przypadku metodyk zwinnych istnieje bardzo duże ryzyko blokowania prac zespołu przez braki po stronie innych modułów. Warto w tym miejscu nadmienić, że często moduły/aplikacje są tworzone przez różne firmy, co tym bardziej nie ułatwia synchronizacji prac.

Kryterium 9 – Preferencje klienta

Znajomość metodyk przez klienta jest kluczem do sukcesu projektu. Realizacja projektu w nieznanej klientowi metodyce spowoduje chaos oraz irytację. Stąd też, ze względu na trudności ze zmianą świadomości klienta (przeszkolenie nie zawsze jest możliwe, zespół projektowy to często kilkanaście osób), warto dostosować się do jego preferencji. Wielokrotnie też nie mamy wyboru – metodyka jest narzucona bezpośrednio w wymaganiach klienta.


Podsumowując, jeżeli tylko istnieje taka możliwość, warto za każdym razem przeanalizować nowy projekt pod kątem opisanych powyżej kryteriów i wybrać najlepszą dla danego przypadku metodykę.

 

Autorem wpisu jest

Tomasz Krupa

Project Manager

Odpowiada za realizację projektów polskich i zagranicznych, zarządzając cyklem projektowym od wyceny, poprzez analizę, aż do wdrożenia i po utrzymanie. Podlegają mu osoby specjalizujące się zarówno w technologiach webowych (ASP.NET MVC), mobilnych (Windows Phone), usługach (Web API, WCF, Web Services) oraz zajmujące się kastomizacją rozwiązań Microsoft (CRM, SharePoint, Biztalk).

Komentarze

  • Aktualnie brak komentarzy.

Skontaktuj się z nami