Autorzy Zapostowane przezPatrycja

Patrycja

47 WPISY 0 KOMENTARZE

0 923
scrum team

Od kilku lat wśród programistów dużą popularnością cieszy się Agile Software Development, czyli zwinne wytwarzanie oprogramowania. Popularność tego zjawiska sprawiła, że w nomenklaturze projektowej pojawiło się Agile Project Management, czyli zwinne zarządzanie projektami. O ile pierwsze można z pewnością z powodzeniem zastosować do wykonywania oprogramowania i innych procesów wytwórczych (z dużym powodzeniem można stosować w marketingu), o tyle zwinne zarządzanie projektami jest sprawą dosyć umowną. Metodyki zaliczane do Agile Project Management, wśród nich m.in. Scrum, są mimo wszystko tylko sposobami samej realizacji projektu.

Analizując główne założenia Scruma pod kątem zarządzania projektem, dochodzimy do wniosku, że brakuje w nich wytycznych dotyczących inicjacji oraz zakończenia projektu. I są to elementy, przez które Scruma tak naprawdę nie powinno się stosować dla całego projektu. Scrum bowiem zakłada wykonywanie kolejnych zadań pochodzących z określonego zbioru, w mniejszym lub większym stopniu zdefiniowanych i gotowych do realizacji, w stałych cyklach realizacyjnych. Zazwyczaj na początku realizacji projektu liczba cykli jest znana, dzięki czemu można powiedzieć, że znany jest także czas i budżet takiego projektu. Scrum zakłada także pracę w grupie, której liczba pracowników jest z góry narzucona, a kompetencje pozwalają wykonać cały projekt. Podstawowe założenia realizacyjne Scruma odnoszą się więc do czegoś wcześniej przygotowanego.

Pojawia się więc pytanie, czy zwinne zarządzanie projektem jest tak naprawdę zarządzaniem projektem. Tradycyjne metodyki wyróżniają, w zależności od metodyki, minimum trzy etapy w projekcie. Faza inicjacji, faza realizacji i faza zakończenia – zgodnie ze sztuką prowadzenia projektów takie etapy (fazy) w każdym projekcie muszą się znaleźć. Czy są one w Agile Project Management? Nie, i wątpliwe jest czy można byłoby je w nim zaimplementować. Został on bowiem stworzony z zupełnie innym zamysłem, zupełnie inna idea mu przyświecała. Miał skutecznie poprawić efektywność projektów, miał sprawić, że projekty będą kończone z sukcesem, nie zaś zarzucane w trakcie realizacji bądź planowania. Agile Software Development był, jak się później okazało, w miarę dobrym narzędziem poprawy wydajności projektowej. Agile Project Management nie zawsze musi być skuteczny, jeżeli chodzi o wykonanie projektu jako całości.

Dlaczego więc mówimy o zwinnym zarządzaniu projektami, dlaczego zyskuje ono coraz większe grono zwolenników, które powoli wykracza już poza sferę informatyki i programowania? Odpowiedź na to pytanie znajdziemy w sposobie działania wielu firm wykonujących na zlecenie pewne usługi. Niech przykładem będzie firma świadcząca szeroki zakres usług marketingowych. Przychodzi do niej klient, który zamawia kampanię reklamową swojego produktu/usługi, do wykonania w określonym budżecie i określonym czasie (na określony moment w czasie). A więc inicjacja projektu za nami. Jeżeli po zakończonej kampanii klient będzie chciał tylko faktury, naprawdę niewiele trzeba, by zainicjować i zamknąć projekt. Kwintesencja takiego projektu, czyli realizacja kampanii marketingowej, może być już wykonana przy pomocy Scruma czy innej metodyki zwinnej. Z takim czymś poradzą sobie one z nawiązką.

WŁĄCZENIE INICJACJI I ZAKOŃCZENIA W SCRUMOWE ITERACJE

Czy istnieje sposób „naciągnięcia” założeń Scruma do objęcia nim całego projektu? Chyba najlepszym sposobem jest włączenie fazy inicjacji w cykle „produkcyjne” Scruma. Od samego początku Scrum Master wraz z trzonem zespołu powinien przygotowywać projekt, a efektami kolejnych cykli jego pracy powinny być dokumenty inicjujące projekt (ich liczba i zakres mogą być zaczerpnięte z jednej z tradycyjnych metodyk zarządzania). Także faza zakończenia, wymagająca zazwyczaj testów odbiorczych, może być włączona pod postacią ostatniego cyklu realizacyjnego.

Czy takie rozwiązanie sprawdzi się w rzeczywistości, zależeć będzie od umocowania Scrum Mastera w hierarchii zarządczej firmy oraz dopuszczeniu go do negocjacji z potencjalnym klientem. Duża korporacja, podzielona na działy, wydziały i oddziały pewnie nie będzie w stanie zrobić niczego takiego. W małej firmie natomiast będzie obawa o to, że Scrum Master będzie miał zbyt dużą władzę decydując o danym projekcie. Dobrym przykładem rozwiązania danego problemu byłoby uczynienie Scrum Masterem lub Product Ownerem osoby związanej z negocjacjami projektu z klientem zewnętrznym lub wewnętrznym. Rola Scrum Mastera dałaby jej władzę, Product Ownera kontrolę nad realizacją projektu. Nie jest także złą sytuacją, gdy Scrum Master (jako kierownik przyszłego projektu) będzie pełnił rolę doradczą w negocjacjach z klientem.

We włączeniu fazy inicjacji w cykle scrumowe można zauważyć jeszcze jedno niebezpieczeństwo, ale także ratunek dla projektu. Pracując z projektem, którego zakres jest zmienny i ściśle nieokreślony, będziemy mogli swobodnie pracować między kolejnymi iteracjami. Taka praca będzie dla nas nawet bardziej komfortowa. Inaczej będzie się miała rzecz, gdy klient będzie wymagał dokumentacji podobnej do tej, jaką zna z metodyk tradycyjnych. W tym wypadku należałoby zrezygnować ze Scruma.

Jest jeszcze jeden aspekt, o którym warto pamiętać, chcąc inicjować projekt scrumowo. Praca w Scrumie nastawiona jest na współpracę z klientem i zaspokojenie jego potrzeb. Inicjowanie projektu często musi zostać wykonane poza wiedzą i świadomością klienta. Tutaj może pojawić się konflikt. Ciężko sobie wyobrazić bowiem wspólną pracę nad dokumentami takimi, jak rejestr ryzyk czy plan komunikacji, w których jako ryzyko będziemy traktowali np. duże ryzyko niewypłacalności klienta, albo założymy, że o problemach ze specjalistami nie będziemy informować klienta. Wybierając to rozwiązanie trzeba będzie się z tym zmierzyć.

WŁĄCZENIE SCRUMA W FAZĘ WYKONANIA PROJEKTU

Rozwiązaniem alternatywnym będzie przygotowanie „pod Scruma” całego projektu, czyli przeprowadzenie fazy inicjacji projektu i potem zakończenia projektu przez niezależnych ekspertów, związanych z tradycyjnymi metodykami. Będziemy pewni, że projekt będzie przygotowany zgodnie z prawami sztuki zarządzania projektami, wszystkie dokumenty będą prawidłowe, a scrumowcom pozostanie tylko odpowiednie wykonanie projektu.

No właśnie, czy będzie to przygotowane dobrze dla osoby korzystającej z metodyk tradycyjnych czy dla osoby posługującej się Scrumem? Trzeba bowiem pamiętać, że wykonanie produktu projektu przy pomocy Scruma będzie wymagała odpowiedniego zainicjowania projektu, jak i jego zakończenia. W fazie inicjowania projektu realizowanego przy pomocy Scruma będziemy musieli uwzględnić takie elementy, jak zaangażowanie klienta (przedstawiciela klienta) w bieżące prace, konieczność przygotowania rejestru produktowego zawierającego krótkie opowieści będące podstawą prac zespołu, tworzenie zamkniętego i w miarę samowystarczalnego zespołu realizacyjnego, czy na końcu cykliczność dostarczania produktów i oceniania postępów prac. W fazie zakończenia trzeba będzie zwrócić uwagę na to, że cykliczne oceny wartości produktu dla klienta powinny znacząco skrócić fazę testów odbiorczych, a zmienny w czasie zakres projektu nie będzie pozwalał na porównanie efektu z zamierzeniem. Wymienione wyżej elementy są jedynie tymi, które w sposób zasadniczy rzutują na sposób przygotowania projektu.

Dla osoby tworzącej tradycyjne dokumenty uwzględniające zwinne rozwiązania jest to nie lada wyczyn. Bo jak tutaj przygotować harmonogram, gdy tak do końca nie wiadomo, co będzie robione w danej iteracji? Bo jak określić odpowiedzialność za poszczególne zadania, gdy każdy z członków zespołu może sobie je „wziąć” z tablicy? Dla każdego dobrego planisty będą to tylko kolejne elementy do zaplanowania w sposób, aby dało się je zrealizować. Najlepszy nawet planista nie zaplanuje jednej rzeczy – Kierownika Projektu, który stanie się Scrum Masterem, aby ponownie powrócić do roli Kierownika Projektu. Trudno wyobrazić sobie jedną osobę, która będzie pełniła obie funkcje, jeszcze trudniej, że którejś z nich nie będzie w realizowanym projekcie. Pozostaje więc zrównoleglenie tych ról projektowych na czas wykonania produktów projektu, aby zoptymalizować proces włączenia Scruma w tradycyjne metodyki zarządzania projektami.

0 1154
egzamin pmp

Część 1. Jak zapisać się na egzamin certyfikacyjny z PMP®?

By podejść do egzaminu PMP® trzeba spełnić następujące wymagania:

  • Ukończyć 35-godzinne szkolenie z zarządzania projektami
  • Osoby z wykształceniem średnim – udokumentować minimum 5 lat (60 miesięcy) doświadczenia z zarządzania projektami, z których przynajmniej 7,500 godzin spędziliście w roli lidera projektu
  • Osoby z wykształceniem wyższym (co najmniej poziom licencjata) – udokumentować minimum 3 lata (36 miesięcy) doświadczenia z zarządzania projektami, z których przynajmniej 4,500 godzin spędziliście w roli lidera projektu

Wymóg szkoleniowy

 Szkolenie może być dostarczone przez tzw. PMI-REP, czyli firmy szkoleniowe posiadające akredytację PMI®, ale nie musi. Można zapisać się na szkolenie do dowolnej firmy oferującej taką usługę. Jeśli ukończyliście studia podyplomowe z zarządzania projektami, to zajęcia stricte dotyczące metodyki project managementu również mogą zaliczać się do edukacji wymaganej przed zapisaniem się na egzamin. Zarejestrować można również naukę w ramach działalności tzw. PMI Community of Practice®, szkolenia wewnętrzne w firmach, czy kursy e-learningowe.

Różnica polega na tym, że szkolenia odbyte u REPów sprawnie przechodzą przez część audytową, tzn. nie są sprawdzane, będąc już zarejestrowanymi w bazie PMI®.

Kryterium szkoleniowe nie ma żadnego ograniczenia czasowego, tzn. mogliście wypracować te 35 godzin nauki kiedykolwiek i w różnych odstępach czasowych. Po prostu łącznie ma wyjść 35 godzin.

Wymóg doświadczenia

Uwaga! Godziny doświadczenia udokumentowane w aplikacji muszą być zdobyte w ciągu ostatnich ośmiu lat (nie dalej) od składania aplikacji.

Natomiast warunek pełnienia roli lidera projektu jest spełniony gdy braliście udział we wszystkich fazach projektu: w fazie inicjacji, planowania, realizacji, monitorowania i kontroli oraz zamknięcia i wykonywaliście w tej fazie konkretne zadania, więcej szczegółów znajdziecie pod tym linkiem.

Nie musieliście przez cały czas pełnić roli kierownika/lidera projektu, ale te obowiązki powinny stanowić co najmniej 80% wymaganego doświadczenia (7,500 godzin z 5 lat, 4,500 godzin z 3 lat).

I jeszcze jedna istotna uwaga: udokumentowane doświadczenie projektowe nie może się nakładać. Tzn. jeśli pracowałeś na projektach zawodowo i wolontariacko, to i tak nie zarejestrujesz wszystkich godzin. Możesz zarejestrować maksimum 8 godzin dziennie. Co więcej, jeśli uczestniczyłeś w dwóch projektach na raz, możesz zarejestrować tylko jeden z nich.

Jeśli jednak chodzi o doświadczenie w zarządzaniu projektem (rola lidera), tutaj może się ono nakładać. Wszystkie godziny liczą się do wymaganego limitu (również te spędzone nad projektami wolontariackimi).

Ogólne doświadczenie projektowe będziemy rejestrować w miesiącach. Doświadczenie w kierowaniu projektami będziemy spisywać w godzinach. Co więcej, trzeba będzie rozpisać je na poszczególne fazy projektowe (co robiliście w fazie inicjacji, planowania, realizacji, monitorowania i kontroli i zamykania projektu).

Dla każdego doświadczenia trzeba podać osobę, która je potwierdzi i kontakt do niej. Powinien to być Wasz przełożony, manager. Zdaje się, że wystarczy adres e-mail.

Uwaga! Jeśli Wasz wniosek znajdzie się w puli aplikacji podlegającej audytowi, będziecie musieli przesłać do PMI® dokumenty potwierdzające zarejestrowaną edukację i doświadczenie. Najlepiej jest więc przygotować taką dokumentację na zaś. Będzie to certyfikat ukończenia kursu, czy pisemne oświadczenie osoby potwierdzającej Wasze doświadczenie projektowe.

Rejestracja i opłaty

Na egzamin rejestrujesz się poprzez stronę pmi.org. Bezpośredni link do strony logowania tutaj.  Trzeba przyznać, że sama aplikacja jest dość skomplikowana. Jeśli jednak przygotujecie sobie wcześniej wyżej wspomniane informacje, powinno pójść gładko. Od momentu rozpoczęcia aplikacji macie 90 dni na jej ukończenie. PMI® będzie Wam o tym regularnie mailowo przypominał. Jak już ukończycie rejestrację Waszego wniosku, organizacja będzie miała 5 dni na jego przegląd i akceptację. Odbędzie się to na zasadzie potwierdzenia kompletności informacji zawartych w aplikacji. Po otrzymaniu mailowego potwierdzenia, że Wasz wniosek pozytywnie przeszedł proces weryfikacyjny, możecie podchodzić do egzaminu w ciągu zbliżającego się roku. Macie zarezerwowane w tej puli trzy podejścia. Teraz przyszedł czas na wniesienie opłaty.

Koszt certyfikatu PMP® to 555 USD dla osoby spoza organizacji PMI® lub 405 USD dla członka PMI®. O tym co daje i ile kosztuje członkostwo w PMI® obiecuję napisać za jakiś czas w oddzielnym wpisie. Opłaty dokonujecie kartą płatniczą online. Podobnie jak w wielu liniach lotniczych, nie musi to być karta kredytowa. Po dokonaniu płatności możecie rejestrować się na egzamin. Chyba, że otrzymacie informację, że Wasz wniosek został wybrany do audytu. Oznacza to, że macie 90 dni na przesłanie materiałów potwierdzających Wasze doświadczenie. Następnie PMI® ma 5-7 dni na weryfikację tej dokumentacji. Jeśli znaleźliście się w puli „szczęściarzy” przechodzących przez audyt, od momentu pozytywnego przejścia przez dodatkową kontrolę możecie zapisywać się na egzamin w ciągu zbliżającego się roku.

Terminy egzaminów

Na egzamin trzeba rejestrować się poprzez stronę www.prometric.com/PMI. Po wypełnieniu niezbędnych informacji pojawi się kalendarz z terminami do wyboru. Egzamin w Polsce zdawać można w dwóch miejscach:

  • W Warszawie, w autoryzowanym centrum edukacyjnym Integral Technologies Sp. Z o.o., na ulicy Waliców 11
  • W Krakowie, w Inifinity, Centrum Testowym Prometric, na Alei 29-go Listopada

W kalendarzu zwykle wyświetla się kilka dostępnych terminów w tygodniu. Można zapisać się od razu lub z kilku tygodniowym wyprzedzeniem. Raczej jest w czym wybierać. Choć ze względu na zmieniający się nieco egzamin od listopada b.r., w październiku może zrobić się nieco tłoczniej.

Termin egzaminu można odpłatnie zmienić lub odwołać:

  • Jeśli zrobicie to wcześniej niż 30 dni przed terminem egzaminu, nie zapłacicie nic.
  • Jeśli zrobicie to z co najmniej 30-dniowym i nie krótszym niż 2 dni wyprzedzeniem, zapłacicie 70 USD.
  • Jeśli zrobicie do z 2-dniowym lub krótszym wyprzedzeniem, stracicie całą kwotę wpisowego.

To tyle na temat samej rejestracji na egzamin. Nie da się ukryć, że zabiera ona trochę czasu. Przede wszystkim radzę by wcześniej przygotować sobie wszystkie informacje potrzebne do aplikacji.

0 616
stos książek

Miło mi poinformować, że jest już dostępny nowy kurs dla Scrum Masterów :) Tym razem przechodzimy do omówienia konkretnych narzędzi, które mogą być przydatne w codziennej pracy Scrum Mastera czy Agile Coacha.

Przedstawione narzędzia dotyczą zarówno kwestii miękkich, przykładowo nawigowanie po poziomach konfliktu, etapy procesu grupowego, dynamiki grupy, jak i konkretnych sposobów i porad na temat dzielenia elementów Product Backlogu czy szacowania relatywnego.

Dla czytelników bloga specjalna zniżka pod linkiem poniżej :)

https://www.udemy.com/course/narzedzia-scrum-mastera/?referralCode=B34C732175AB9F13A7C4

0 1901
sponsor projektu

Kim tak naprawdę jest Sponsor w projekcie i jaką rolę odgrywa?

Definicja sponsora w projekcie

Zarówno w polskim, jak i w angielskim języku, definicja Sponsora brzmi mniej więcej: ‘osoba, która płaci’. Tymczasem w projekcie Sponsor może decydować o przeznaczeniu funduszy na projekt, ale (uwaga) niekoniecznie! A jeśli nawet w naszym projekcie Sponsor jednocześnie płaci za projekt, to nie ta cecha asygnuje go na tak ważną osobę dla Kierownika Projektu.

W project managemencie Sponsor to jednostka (osoba, grupa, a nawet i organizacja), która zamawia u nas projekt. Sponsorem projektów często bywa reprezentant biznesu, zarząd, jednostka odpowiadająca w organizacji za strategię, bądź wybrany program. Sponsor to często właściciel pomysłu na Twój projekt. Ktoś, kto zauważył potrzebę wykonania pewnego zadania i potrzebuje kogoś kto ten pomysł zrealizuje.

W ten sposób Sponsor staje się dla Ciebie głównym wsparciem w organizacji a jednocześnie i skarbnicą wiedzy o projekcie. To Jemu będzie zależało na tym by projekt się udał. To on pomoże Ci zaadresować wiele problemów w organizacji. Sponsor będzie łącznikiem między Tobą i zespołem projektowym a całą resztą regularnego biznesu odbywającego się na co dzień w firmie. Uwierz mi, nie przeceniam Jego roli…

Za co odpowiada Sponsor?

Jako swoisty łącznik między Tobą a biznesem, Sponsor będzie Cię wspierał w tak istotnych przedsięwzięciach jak:

  • Ustalenie składu Komitetu Sterującego, czyli ciała decyzyjnego w projekcie
  • Zidentyfikowanie osób, specjalistów, zespołów, które będą wiedziały najwięcej o zagadnieniu Twojego projektu i prawdopodobnie docelowo stworzą zespół projektowy
  • Uzyskanie przychylności jednostek mających w organizacji największy wpływ na Twój projekt
  • Upewnienie się, że projekt, którym zarządzasz jest ważny dla managementu najwyższego szczebla w organizacji
  • Zdobycie funduszy i zasobów niezbędnych do prowadzenia projektu
  • zapewnienie, że informacje o zmieniającym się otoczeniu projektu, warunkach, wymaganiach i strategii firmy na bieżąco napływają do zespołu projektowego
  • I wiele innych problemów, którym będziesz musiał stawić czoła jako Project Manager

Chyba już nie masz wątpliwości, że ze Sponsorem lepiej nie zadzierać?

Relacje sponsora i kierownika projektu

Przede wszystkim poczucie, że masz wszystko pod kontrolą i na bieżąco informujesz Go o istotnych dla projektu kwestiach. Oczywiście, by taka sytuacja miała miejsce na początku projektu powinieneś dokładnie poznać swojego Sponsora, wiedzieć co uważa za najważniejsze w projekcie, jakie ma preferencje co do zakresu decyzji, w które ma być włączany oraz co do decyzji, w których zostawia Ci wolną rękę. Załóżmy, że Twój projekt zacznie się opóźniać. Jaką podejmiesz decyzję? Poprosisz członków zespołu by zostali w nadgodzinach, upewniając się, że projekt będzie postępował zgodnie z planem? Czy może poinformujesz Komitet Sterujący o opóźnieniu w realizacji planu? Warto wiedzieć co wolałby Sponsor projektu. Takich decyzji jest w projektach wiele i nie po to nim zarządzamy by o każdą błahostkę pytać Sponsora. Rozmowa na temat priorytetów w projekcie ułatwiłaby podejmowanie takich decyzji. Wyobraź sobie również komfort z jakim zarządzasz projektem gdy wiesz, że Sponsor w pełni Ci ufa, nie musisz konsultować z nim każdej najmniejszej decyzji, a potem nie będziesz musiał tłumaczyć się z każdego kroku w projekcie. Uwierz mi – ogromny komfort!

Niestety, jednocześnie mam złą wiadomość: o ten komfort wcale nie jest łatwo…
A to dlatego, że najczęściej zaczynając projekt wiesz o nim o wiele mniej od swojego Sponsora. To Sponsor doskonale zna i rozumie cel biznesowy. Ha! Często sam ten cel sformułował. A to oznacza dla Ciebie następujący zestaw faktów:
•    Sponsor prawdopodobnie jest specjalistą w dziedzinie, której dotyczy projekt
•    Możliwe, że projekt dotyczy jedynej dziedziny, na której Sponsor się zna. Robi na niej karierę w organizacji. To jest Jego przysłowiowy konik i nikt nie wie więcej na ten temat niż on sam.
•    Sponsor ma w głowie już swój własny plan co do sposobu w jaki projekt powinien być wykonany i plan ten, płynąc z jednej głowy, nie uwzględnia wielu zależności, okoliczności, czy też ograniczeń, które prawdopodobnie wypłyną podczas planowania projektu z całym zespołem
Któryś z czynników powyżej wystąpi na pewno już na początku projektu. Każdy z nich sprawi, że Sponsor nie będzie Ci ufał. Uzna Cię za kogoś, kto ma zrealizować Jego pomysł nie posiadając wystarczającej wiedzy (czyli takiej jak on).  Co więcej, wyobraź sobie reakcję Sponsora gdy po przeprowadzeniu burzy mózgów z zespołem ustalicie, że najlepiej będzie wykonać projekt w inny sposób niż zaplanował sam Sponsor…  Tak, trochę tu demonizuję, ale te reakcje występują w realnym świecie. Często po prostu nie widać ich gołym okiem. Jednak gdy wyczujesz je jako Project Manager, od razu będziesz wiedział jak taką sytuacją zarządzać. Na przykład w sytuacji, w której zespół projektowy wypracował inny plan na dostarczenie końcowego produktu projektu, zorganizuj spotkanie samego zespołu razem ze Sponsorem i na spokojnie, krok po kroku wyłóżcie mu kolejne rozwiązania i argumenty za nimi przemawiające. Nie rób tego na większym forum, w ten sposób Sponsor może odebrać to jako podważenie jego opinii. Jeśli przekonasz do swojego planu Sponsora, masz już 80% szans, że zatwierdzi go Twój Komitet Sterujący.

Oczywiście, ile projektów, tyle scenariuszy. Może też być tak, że Sponsor odda Ci projekt i uznając, że już się ktoś nim zajmuje, skreśli go z listy swoich priorytetów i kompletnie przestanie się nim interesować, prawdopodobnie planując rozliczenie Cię z projektu na sam jego koniec. My, PMy nie możemy dopuścić do takiej sytuacji. Niewątpliwie trzeba tutaj wykazać się sporą charyzmą, uporem, zawziętością. Kierownik Projektu dość często musi przysłowiowo ‘wejść oknem jeśli nie da się drzwiami’. Co powinno pomóc uniknąć takiej postawy Sponsora? Wystarczy, że zaczynając projekt jasno określimy role poszczególnych osób, również Sponsora. Informacje te zostaną udokumentowane a nawet zaprezentowane przed Komitetem Sterującym, a w ten sposób szybko staną się wiążące. Pamiętaj, że to Ty jesteś odpowiedzialny za Projekt jako całokształt. Odpowiadasz za zbudowanie odpowiedniej struktury, organizacji na czas projektu, za zbudowanie zespołu, za stworzenie planu, za komunikowanie, za sukces projektu. Jednocześnie odpowiadasz za to by właściwe osoby podejmowały decyzje w projekcie.

Zdarzało mi się pracować z różnymi Sponsorami. Byli tacy, którzy wystawiali mnie na próbę. Twierdzili, że nie znam się na dziedzinie, w której prowadzę projekt, a potem zlecali małe zadanka by sprawdzić jak sobie poradzę. Z czasem przekonali się, że potrafię dotrzeć do każdej informacji. Przyznam, że nie było łatwo. Gdy kończyłam jeden z projektów usłyszałam od swojego szefa, że moim największym sukcesem był fakt, iż nawiązałam dobre relacje z dwiema Paniami pełniącymi rolę Sponsora w moim projekcie. Był to sukces, ponieważ Panie nie przepadały za Project Managerami. I muszę przyznać, że mnie również na początku przetestowały na wiele sposobów, postawiły w kilku trudnych sytuacjach.

Project Manager pracuje w różnych organizacjach, a w tych organizacjach i ich działach panuje swoista kultura, odmienne zasady. Najważniejsze dla nas PMów to pamiętać jaka jest nasza rola, jasno komunikować ją wszystkim i tego się trzymać. Jednej ze wspomnianych wyżej Pań zdarzyło się pewnego razu na telekonferencji zapomnieć, że również w niej uczestniczę. Wypowiadając się na temat innego Kierownika Projektu skomentowała: ,… She is stupid… As all project managers are’. W tym spotkaniu wirtualnym brał udział również mój szef, Program Manager. Oczywiście dość szybko Pani Sponsor zorientowała się jaką popełniła gafę. Na końcu przeprosiła wszystkich za swoje słowa. Jednak wrażenie zostało. Wiedziałam co myśli o Project Managerach: była zawiedziona, że nie są specjalistami i nie wykonują prac projektowych sami, w zamian – potrzebują do tego zespołu.  Jak już wcześniej wspomniałam, nasze relacje znacznie się polepszyły po pewnym czasie. Ten proces kosztował mnie wiele asertywności. Musiałam robić dokładnie to co należy do mojej roli i na każdym kroku udowadniać, że robię to doskonale. W innym przypadku groziło mi zostanie sekretarką Pani Sponsor.

Zarządzałam również projektem, w którym Sponsor podjął szereg złych decyzji, widocznych dla mnie od początku. Projekt był bardzo ważny dla strategii firmy, polityczny, wymagał wiele dyplomacji. Polegał na zamknięciu jednego z działów firmy w zachodniej części Europy i otwarciu tegoż działu w Polsce. Jak już się zapewne zorientowaliście, jedni tracili pracę po to, by inni mogli zostać zatrudnieni. Szybko zrozumiałam, że moje główne zadanie w projekcie to wprowadzenie jak najwięcej dyplomacji  i właściwych zachowań. Musiałam mocno hamować zachowania po stronie Sponsora przyjmującego funkcję, uświadamiać managerów, że ludzie po drugiej stronie tracą pracę, że ten projekt dla durgiej strony oznacza coś innego. Oczywiście druga strona była równie trudna do zarządzania, rzucała wiele kłód pod nóg by projekt nie mógł zakończyć się sukcesem. Praca nad projektem wymagała wzajemnego zaufania, co szybko okazało się niemożliwe. Dużą rolę odegrała tutaj postawa Sponsora z Polski: brak zrozumienia drugiej strony, wrogie nastawienie od samego początku projektu, podejrzliwość wobec drugiej strony… Ten projekt prawie się nie udał. Sponsor swoją postawą tak bardzo zepsuł relacje w projekcie, że współpraca między stronami praktycznie nie istniała. Doszło do tego, że gdy projekt zupełnie się nie udawał, Sponsor po polskiej stronie postanowił uznać go za porażkę, oczywiście obwiniając drugą stronę. Taka odpowiedź nie była możliwa do zaakceptowania dla nikogo. Na projekt wydano do tej pory za dużo pieniędzy. Zmieniono Sponsora po polskiej stronie, tzn. zmieniono kompletnie dział, do którego miała zostać przeniesiona dana funkcja. Nowy Sponsor zastosował podejście pokojowe, skłonne do negocjacji. Nie był to środek zaradczy, który natychmiastowo zadziałał na drugą, bardzo wrogo nastawioną stronę, ale udało się. Z półrocznym opóźnieniem zakończyliśmy projekt. Nauczył mnie jak moderować trudne spotkania, jak negocjować, jak ‘sprzedawać’ pewne rozwiązania by tworzyć sytuację win-win w projekcie. Nauczył mnie również, że jako Project Manager nie zmienię kultury organizacyjnej i sposobu myślenia w całej firmie. Muszę zarządzać tym, czym mogę i trzymać stery mocno w swoich rękach!

Podsumowanie roli Sponsora Projektu

  1. Upewnij się, że wiesz kto jest Sponsorem Twojego projektu (pracę często zleca nam pośrednio szef Biura Projektów i wtedy może to nie być oczywiste)
  2. Zbuduj dobre relacje ze Sponsorem na początku projektu.
  3. Zrozum, który cel projektu jest najważniejszy dla Sponsora, co Sponsor zyska gdy projekt się zakończy.
  4. Zdobądź zaufanie Sponsora.
  5. Ustal jasne zasady co do stopnia zaangażowania Sponsora w projekt.
  6. W trakcie trwania projektu na bieżąco informuj Sponsora o postępach prac, pojawiających się problemach, ryzykach, czy zmianach, które planujesz przedyskutować na większym forum.
  7. Na koniec projektu upewnij się, że Twój Sponsor zaakceptował dostarczony produkt, usługę i uznaje status projektu za zamknięty.

To tyle z najważniejszych lekcji, których osobiście doświadczyłam w projektach a propos roli Sponsora

0 1086
ryzyko w projekcie

Aby nie zaczynać tego artykułu od kolejnej, nudnej, akademickiej definicji czym jest ryzyko i dlaczego to takie ważne, posłużymy się dla odmiany pewnym cytatem Winstona Churchila. Brzmi o następująco:

„Zamiast się martwić na zapas, powinniśmy na zapas myśleć i planować”

Te słowa to kwintesencja zarządzania ryzykiem, które występuje w każdej sytuacji w naszym życiu, a w szczególności właśnie w projektach. Nie ma szans na całkowite wyeliminowanie ryzyk w projekcie, ale odpowiednio wczesne ich wykrycie, przemyślenie i zaplanowanie konkretnych działań pozwoli na lepsze wykorzystanie nadarzających się szans oraz zminimalizowanie skutków zagrożeń gdy takowe się pojawią. Warto tutaj też przypomnieć, że ryzyko nie jest tylko sytuacją negatywną, zagrożeniem, ryzyko to także prawdopodobieństwo wystąpienia szansy, która przyniesie dodatkowe, nieplanowane korzyści.

 

Zarządzanie ryzykiem w PRINCE2

Metodyka zarządzania projektami PRINCE 2 składa się z tak zwanych tematów, procesów oraz pryncypiów. Zarządzanie ryzykiem ujęto w jednym z tematów, czyli aspektów zarządzania projektem, którymi należy zajmować się stale i które wymagają określonego traktowania, aby procesy PRINCE 2 były skuteczne. Bazuje ono na pryncypiach Management of Risk (MoR), jest udokumentowane w Strategii Zarządzania Ryzykiem, a poszczególne ryzyka uchwycone są w Rejestrze Ryzyk.

W procedurze zarządzania ryzykiem według PRINCE2 wyróżniamy 5 kroków:

  1. Identyfikuj – wykrycie i spisanie w Rejestrze Ryzyk wszystkich szans i zagrożeń jakie mogą mieć wpływ na określone cele projektu. Opis ryzyka oparty powinien być o schemat: Przyczyna – Zdarzenie – Skutek.
  2. Oceniaj – analiza wymienionych ryzyk, w tym kroku oceniane jest prawdopodobieństwo wystąpienia ryzyk, bliskość ich potencjalnego zmaterializowania się oraz wpływ na cele projektu. Ryzyka nanosi się na tzw. sumaryczny profil ryzyka pokazany poniżej.
  3. Planuj – aby zminimalizować zagrożenia i zwiększyć szanse, w tym kroku przygotowywane są konkretne reakcje zarządzcze na ryzyka, dokonuje się wyboru, rekomendacji jednej reakcji na jedno ryzyko.
  4. Wdrażaj – wcielenie w życie, realizacja konkretnych działań. Właścicielem i wykonawcą reakcj na ryzyko w PRINCE2 na tym etapie jest Kierownik Projektu.
  5. Komunikuj – komunikacja powinna następować ciągle, w całej procedurze zarządzania ryzykiem, jej sposób i zakres natomiast zależy od występujących w projekcie interesariuszy.

 

Zarządzanie ryzykiem w PMBoK Guide 5th

Stanowi ono jeden z 9 obszarów wiedzy w PMBoK-u, pozostałe osiem to zarządzanie integracją, zakresem, czaem, kosztami, jakością, zasobami ludzkimi, komunikacją, zaopatrzeniem. Zarządzaniu ryzykiem poświęcone zostało 6 procesów tej metodyki.

  1. Zaplanowanie zarządzania ryzykiem – proces zdefiniowania sposobów zarządzania ryzkiem, konkretnych metod i narzędzi jakie będą użyte
  2. Identyfikowanie ryzyka – proces, którego celem jest określenie ryzyk wpływających na projekt
  3. Przeprowadzenie jakościowej analizy ryzyka – w tym procesie następuje priorytetyzacja ryzyk oraz wybór, którymi z nich warto dalej się zajmować
  4. Przeprowadzenie ilościowej analizy ryzyka – liczbowa analiza ryzyk opisanych w poprzednim procesie
  5. Zaplanowanie reakcji na ryzyko – przygotowanie określonych działań w przypadku pojawienia się danego ryzyka oraz przypisanie osób odpowiedzialnych za ich wykonanie
  6. Monitorowanie i kontrola ryzyk

PMBoK wskazuje także konkretne techniki, narzędzia zarządzania ryzykiem takie jak: diagram Ishikawy, macierz ryzyka, burze mózgów do identyfikacji ryzyka, struktura podziału ryzyka, pieniężna wartość oczekiwana, drzewo decyzyjne. Szczegóły dotyczące tych technik znajdziecie w odrębnych artykułach podlinkowanych wyżej.

 

0 2499
agile project management course

Drodzy czytelnicy końcówka tego roku to dla nas bardzo intensywny okres. W ciągu ostatnich miesięcy pracowaliśmy nad 3 nowymi produktami i z końcem listopada uruchomiliśmy ich sprzedaż na platformie Udemy:

  • Próbne testy do egzaminu Professional Scrum Master I (wersja z wyjaśnieniami odpowiedzi po polsku)
  • Próbne testy do egzaminu Professional Scrum Master I (wersja z wyjaśnieniami odpowiedzi po angielsku)
  • Agile Project Management (wersja polskojęzyczna)

Zdecydowaliśmy się zająć tymi tematami z uwagi na liczbę pytań, jaką otrzymywaliśmy od uczestników naszych dwóch poprzednich kursów o Scrumie. Co więcej, kurs APM to nasza pierwsza próba połączenia dotychczasowej formy prezentacji opartej o animacje z materiałami wideo, które przygotowaliśmy w naszym domowym studiu nagraniowym. Jesteśmy bardzo ciekawi Waszych wrażeń :)

W listopadzie przekroczyliśmy liczbę 3500 studentów i zakładamy, że w styczniu uda nam się pobić kolejny rekord – magiczną liczbę 4000 osób korzystających z naszych kursów.

  1. Agile Project Management
  2. Professional Scrum Master I – Próbne testy
  3. Professional Scrum Master I – Próbne testy (angielskie odpowiedzi)
  4. Scrum – Podstawy teoretyczne, praktyka, przygotowanie do egzaminu PSM I
  5. Scrum for beginners and intermediate

Korzystając z okazji chcielibyśmy złożyć wszystkim czytelnikom naszego bloga życzenia Wesołych Świąt i Szczęśliwego Nowego Roku :) Do zobaczenia w 2019!

0 797
spotkanie projektowe

Od pewnego czasu sporadycznie prowadzę szkolenia i doradzam z zarządzania projektami. To mnie ekscytuje, ponieważ: po pierwsze – spełniam swoje marzenie (zawsze chciałam prowadzić szkolenia w tym zakresie), po drugie – o zarządzaniu projektami mogłabym mówić bez końca (oj, uczestnicy moich szkoleń coś o tym wiedzą), po trzecie – na szkoleniach poznaję mnóstwo kierowników projektów z doświadczeniem z różnych branż, co niesamowicie mnie rozwija, wreszcie po czwarte – dzięki szkoleniom mogę idealnie połączyć swoje cele zawodowe z życiowymi (pisałam o tym nie jeden raz). Szkolę, obserwuję siebie i widzę jak pięknie spełnia się powiedzenie Konfucjusza: „Wybierz pracę, którą kochasz a nie przepracujesz nawet dnia w swoim życiu.” A zatem wiatr w skrzydełkach jest i to niesamowity. Do tego dochodzi efekt dźwigni motywacyjnej, bo ze szkolenia na szkolenie apetyt na zarządzanie projektami rośnie, że aż trudno się powstrzymać! Dosłownie, gdy zostaję sama w sali szkoleniowej, muszę się uszczypnąć i powiedzieć sobie „Ania, jeszcze nie teraz. Nie taki jest plan. Za chwilkę, jeszcze jakiś rok i znowu poczujesz smak tej przygody”. Ale tyle o sobie w kontekście szkoleń. Bo dziś tak naprawdę chciałam pisać o czymś innym, w moim mniemaniu znacznie ciekawszym. Mianowicie o pewnej obserwacji wiodącej, która towarzyszy mi odkąd szkolę.

Project Manager to przede wszystkim człowiek z charyzmą

O tak, kochani, project manager musi mieć… No wiecie co🙂 Nawet gdy jest kobietą, ten element powszechnie identyfikowany jako męski, musi się w cechach jej charakteru pojawić. Odkąd szkolę słyszę: „tak, to jest fajne narzędzie, ale u nas się tego nie robi”, „tak, warto jest planować, ale w mojej firmie nie ma na to czasu”, „karta projektu? Ciekawe narzędzie, jednak u nas nie powstaje”, „tak, mamy wiele zmian w naszych projektach w trakcie realizacji, ale nie mam na nie wpływu”, „fajnie jest motywować ludzi, ale jako PM w swojej organizacji nie mam do tego narzędzi” itd. Mnożyć by tych przykładów bez liku. Tymczasem moi drodzy, to są tylko wymówki! Tak, z wykrzyknikiem!🙂

Czas wziąć się w garść i zacząć siać ziarenko dobrych praktyk na swoim podwórku. A to będzie wymagało od Was twardego ducha i bez miara charyzmy. Bo to są Wasze projekty i Wy wiecie jak nimi zarządzać.

Wdrażanie dobrych praktyk zarządzania projektami

Kierownik projektu prawie zawsze staje przed wyzwaniem, jakim jest nowe zadanie i nowy zespół ludzi (nie pracujący dotychczas w tym układzie), który będzie je realizował. A więc możesz ten fakt wykorzystać i wprowadzić nowe zasady, nowe narzędzia, zmiany w dotychczasowym procesie zarządzania projektami. Nie mówię, że od dziś masz działać zgodnie ze standardem PMI®, albo metodyką PRINCE2®. Sugeruję, żebyś zastanowił się, które z dobrych praktyk, narzędzi, zachowań, pozwolą Ci lepiej zarządzać Twoim projektem. Żadna z metodyk w pełni nie usatysfakcjonuje potrzeb Twojego projektu, czy zespołu. Wybierz zatem jedno narzędzie, może dwa, maksymalnie trzy i zacznij konsekwentnie wdrażać je ze swoim zespołem projektowym. Zobaczysz jak szybko zaobserwujesz pierwsze efekty. Tak, ludzie będą narzekać, że po co, na co, że więcej pracy. Przekonają się jednak szybko, że było warto, bo zaobserwują te efekty razem z Tobą. Kluczem do sukcesu jest tutaj TWOJA KONSEKWENCJA.

Pokonywanie oporu przed zmianą

Brzmi znajomo? Nie wątpię, że tak🙂 Projekty najczęściej powoływane są do wdrażania zmian. A jeśli bezpośrednio tych zmian ze sobą nie niosą, to same w sobie i tak stanowią zmianę dla członków zespołu projektowego (bo cel nietypowy, bo zadanie nowe, bo zespół się nie zna, bo nowe role…). Jeśli nie posmakowałeś jak to jest zostać liderem czegoś, czego na wstępie nikt nie chce robić, to zapewniam, że niedługo się doczekasz😉 Przygotuj się więc na to. Jak? Zbierz wszystkie informacje, które stoją za powołaniem Twojego projektu, czyli uzasadnienie biznesowe znajdź, zrozum i znaj niemalże na pamięć. Jeśli business case Twojego projektu Cię nie przekonuje, to jest to najlepszy czas by coś z tym zrobić. A konkretnie przeanalizować go ze swoim Sponsorem. Otwarcie kwestionować elementy projektu, które na tym etapie nie mają sensu, czy też wartości dodanej. Gdy już zrozumiesz potrzebę projektu, będziesz w stanie motywować innych do zaangażowania. Nie ma nic gorszego niż PM, który sam nie jest przekonany do przypisanego mu projektu. Jeśli nie widzisz korzyści jakie ten projekt ma przynieść Twojej organizacji, kwestionuj go od razu, a gdy nie uda się go „ubić” na tym etapie, lepiej się go nie podejmuj.

Jeśli jednak nie spełni się czarny scenariusz, zrozumiesz uzasadnienie biznesowe i zaczniesz budować zespół projektowy, rozmawiając z ludźmi skup się na dwóch aspektach:

  1. Why before what (YB4What) – zacznij od uzasadnienia biznesowego, od przyczyn powołania projektu, od wizji nowej rzeczywistości jaką ma stworzyć Twój projekt. Dopiero gdy ludzie zrozumieją dlaczego projekt został powołany i co ma osiągnąć, będą w stanie zdefiniować co trzeba zrobić, żeby zrealizować cel. A zatem teraz przejdź do omawiania najważniejszych zadań projektowych i pierwszych szkiców Twojego planu projektowego. Uwaga! Jeśli z sukcesem zrealizujesz pierwszą część (Why), wkład do kolejnej części (What) dadzą Ci ludzie. A jacy będą zmotywowani, że sami wpłynęli na to, co trzeba w projekcie wykonać.
  2. What is in it for me (WIIIFM) – nikt nie pracuje tylko po to by realizować cel swojej organizacji. Każdego z nas motywuje coś jeszcze, jednych wyłącznie wynagrodzenie, innych nowe zadanie w projekcie, jeszcze innych możliwość współpracy z konkretną osobą…. Takich czynników jest mnóstwo. Zadaniem Twoim, drogi liderze jest zidentyfikować te czynniki u członków Twojego zespołu projektowego i sprawić by mogli je realizować w Twoim projekcie.

Po zaadresowaniu tych dwóch podstawowych kroków opór Twojego zespołu projektowego przed zmianą znacznie zmaleje. Nie mówię, że odejdzie w niepamięć u wszystkich uczestników projektu. Tak nie dzieje się nigdy. Po pierwsze, akceptacja zmiany wymaga czasu i tego nigdy nie przeskoczysz. Uzbrój się więc w cierpliwość, obserwuj i reaguj. Po drugie, znajdą się takie osoby, które nigdy nie zaakceptują zmiany i tych osób będziesz musiał się po prostu pozbyć: czy oddelegować na inny projekt, czy dać im mniej znaczące zadanie, czy po prostu zwolnić.

Zaadresowaliśmy opór przed zmianą w zespole projektowym. Niestety, to nie wszystko: opierało będzie się również otoczenie projektowe. I z tym bezpośrednio zawalczyć się nie da. Za kluczowe uznałabym tutaj następujące czynniki:

  1. Twoja postawa – musisz być przekonany, że realizacja Twojego projektu ma sens i przynosi korzyść biznesową Twojej organizacji.
  2. Wizja projektu – w rozmowach, prezentacjach i innych komunikatach skupiaj się na tym jak ma wyglądać rzeczywistość po realizacji Twojego projektu. Jaki jest końcowy obrazek, do którego dążycie?
  3. Daj czas – pogódź się z tym, że minie trochę czasu zanim ludzie oswoją się z myślą, że ta zmiana się wydarzy. Jak długo to potrwa? Tego zmierzyć się nie da. Zależy to od kultury organizacji oraz postawy, Twojej i kierownictwa wyższego szczebla.
  4. Zaangażuj górę – bez wsparcia kierownictwa wyższego szczebla, bez promocji projektu z ich strony, wiele nie wskórasz. Świadomie wykorzystuj więc ich wsparcie, a jeśli go brak – adresuj jego ogromną rolę na samym początku projektu.
  5. Zbuduj ścianę – w swojej wyobraźni zbuduj cienką jednostronną barierę, błonkę wokół siebie, od której odbijają się wszystkie negatywne komentarze, krytyka tych najbardziej opornych i słowa wiecznie niezadowolonych malkontentów. Trochę będzie tego do Ciebie docierało.
  6. Broń swojego poczucia wartości – bądź świadomy faktu, że niektórym brakuje dystansu i nie będąc przekonanymi do projektu, nie będą przekonani do Twojej osoby. Krytyka, awersja, uszczypliwe żarciki, gesty ironicznego współczucia? Mogą się zdarzać. Na szczęście Ty wiesz po co pojawiłeś się w tej organizacji i jak będą oceniane efekty Twojego projektu za kilka lat.

To tyle w skrócie na temat istoty niezłomności charakteru Project Managera.

Pozdrawiam Was serdecznie, życząc bezkresnego morza charyzmy i niemałej wiary w siebie!

0 3268
ksiazki i tablica

Od premiery naszego anglojęzycznego kursu o podstawach Scruma na platformie e-learningowej Udemy.com minęło prawie równo 12 miesięcy. W tym czasie liczba zapisanych studentów przekroczyła magiczny 1000, co pozwoliło nam uzyskać status bestsellera. Ku naszemu zaskoczeniu, osoby, które zainteresowały się kursem pochodziły z aż 91 różnych krajów z całego świata! 
Idąc dalej za ciosem zdecydowaliśmy się zrobić ukłon w stronę rodzimego rynku i społeczności agile'owej i przygotować kurs w polskiej wersji językowej. Miło nam poinformować, że od kilku dni jest on już dostępny na platofrmie Udemy jako jedyny, polskojęzyczny kurs o tematyce Agile'a i Scruma. Specjalny link z rabatem dla czytelników bloga oraz video promocyjne znajdziecie poniżej.

Czytaj całość…

0 4701

Jedną z najważniejszych zmian, które metodyki zwinne wprowadziły w procesie zarządzania projektem jest sposób, w jaki zarządza się wymaganiami.

 

Podejście do zmienności wymagań w tradycyjnych metodykach kaskadowych

Pierwotnie, jeszcze przed rewolucją, którą wprowadziły Scrum oraz inne metodyki zwinne tradycyjne kaskadowe podejście do zarządzania wymaganiami wymuszało na stronie biznesowej przygotowanie kompleksowej specyfikacji finalnego produktu, na bazie której definiowane były wymagania jeszcze przed startem projektu. Kiedy do tych wymagań zasiadał zespół deweloperski i rozpoczynała się praca wytwórcza na wszelkie zmiany było już za późno. Koszt ich wprowadzenia często przewyższał sens wdrożenia. System, który był już w trakcie budowania mógł nie być gotowy na wprowadzenie zmiany zaproponowanej już kilka tygodni po starcie prac, bo wymagałoby to szeroko zakrojonych zmian w filozofii jego działania oraz w samym kodzie źródłowym.

Sprawa ulegała jeszcze większemu skomplikowaniu kiedy w grę wchodziło wytwarzanie oprogramowania dla klienta zewnętrznego. Firma dostarczająca produkt zgodziła się na określony zakres zdefiniowany w dokumencie, zadeklarowała określony koszt tego rozwiązania i zobowiązała się przygotować je w określonym terminie. A zatem wszelkie zmiany w zakresie, które pojawiłyby się już po podpisaniu dokumentów i rozpoczęciu prac narażały dostawcę na kłopoty.

Ale przecież od zmian nie można uciec. Między innymi z tego powodu metodyki kaskadowe wypracowały ściśle określone procedury na wprowadzanie zmian w zakresie projektu. Tzw. change requesty miały bardzo dokładnie określić zakres zmian, ich koszt oraz wpływ na datę końca prac. Dzięki temu udało się opanować częściowo problem zmienności wymagań. Zmianie nie uległ jednak sposób myślenia – ciągle były one postrzegane jako coś niechcianego, coś, co wybija zespół deweloperski z rytmu i kładzie na szali datę dostarczenia produktu.

 

Nowe rozdanie, czyli metodyki zwinne

Metodyki zwinne zaadresowały ten problem wprowadzając zupełnie inne podejście do zarządzania wymaganiami. Podejście to różniło się nie tylko narzędziami, z których mógł korzystać zespół deweloperski, ale również całościową filozofią podejścia do zmienności. Zamiast się jej bać, zaczęto ją cenić. Nowe wymagania pojawiające się w trakcie trwania projektu mogą przecież pomóc finalnemu produktowi być bardziej aktualnym, odpowiadać na bieżące potrzeby rynku.

 

Sprinty jako odpowiedź na „niekończące się projekty”

Jednym z podstawowych narzędzi, które pozwala zaadresować zmienność wymagań w zwinnym projekcie są tzw. Sprinty, czyli krótkie przedziały czasu, w ramach których zespół deweloperski zobowiązuje się dostarczyć określony zestaw funkcjonalności (często nazywanych historyjkami użytkownika). W tym podejściu zespół nie zamyka się na pół roku sam ze sobą, żeby dostarczyć kompletny produkt, na który składa się długa lista wymagań, tylko „paczkuje” te wymagania w sensowne z biznesowego punktu widzenia kawałki i dostarcza je w krótszych przedziałach czasowych. Dzięki Sprintom strona biznesowa jest w stanie szybciej pozyskać określoną w zakresie Sprintu wartość, zespół deweloperski ryzykuje mniej, bo może szybciej zweryfikować, czy wytworzony produkt odpowiada potrzebom zleceniodawcy, a finalny odbiorca rozwiązania (użytkownik) otrzymuje produkt aktualny, będący odpowiedzią na bieżące wymagania rynkowe.

 

Product backlog

Drugim fundamentem pozwalającym zwinnemu zespołowi adoptować się do ciągłych zmian jest tzw. backlog produktu, czyli miejsce, w którym w sposób ciągły redefiniuje się jego zakres. Praca w Sprintach bez backlogu byłaby możliwa (można na przykład podzielić pierwotny zakres produktu zdefiniowany w specyfikacji na miesięczne interwały), ale byłby to właściwie powrót do prowadzenia projektu w sposób kaskadowy (przynajmniej w aspekcie zarządzania zmiennością wymagań, której to dotyczy ten wpis). Product backlog (angielski odpowiednik pojęcia, którym będziemy się posługiwać) jest tak naprawdę nieodłącznym elementem zwinnego zarządzania projektami, ponieważ służy jako miejsce, w którym agreguje się wszystkie nowe pomysły, zmiany, błędy, itp. które pojawiły się w głowie zleceniodawcy już w trakcie trwania projektu.

Backlog powinien być stale zarządzany przez tzw. właściciela produktu (czyli stronę biznesową), który musi stale dbać o to, żeby na samej górze listy potrzeb biznesowych (backlog często występuje właśnie w formie listy) były elementy aktualne, dokładnie zdefiniowane i dostarczalne w krótkim przedziale czasowym. W świecie metodyk zwinnych często pojawia się akronim INVEST, który ma pomóc stronie biznesowej w tworzeniu historyjek użytkownika.

  • I – Independent (Niezależne) – Historyjki muszą być od siebie odseparowane, a to oznacza, że da się je realizować osobno.
  • N – Negotiable (Negocjowalne) – Kształt historyjki wynika z negocjacji na linii zleceniodawca – dostawca. Historyjka nie jest jednostronnie zdefiniowanym elementem, który może się okazać niemożliwy do wykonania.
  • V – Valuable (Wartościowe) – Każda historyjka powinna dostarczyć końcowemu użytkownikowi określoną korzyść.
  • E – Estimable (Możliwe do oszacowania) – Historyjka nie może być tak obszerna, że nie da się oszacować jej pracochłonności.
  • S – Small (Mała) – Historyjki muszą być na tyle małe, żeby można je było zrealizować w jednym sprincie.
  • T – Testable (Możliwe do przetestowania) – Opis historyjki powinien pozwolić na przeprowadzenie testów i weryfikację, czy gotowe rozwiązanie dostarcza korzyść biznesową.

Warto tutaj wspomnieć, że w Scrumie zespół deweloperski bierze aktywny udział w pracach nad backlogiem. Co prawda właściciel produktu (tzw. Product Owner) finalnie decyduje, co znajduje się na samym szczycie listy (a więc co jest najważniejsze dla produktu w danym momencie), ale sama zawartość tej listy może być często modyfikowania (w porozumieniu z Product Ownerem) przez członków zespołu (np. dodawane są wyceny, historyjki dzieli się na mniejsze taski, aktualizuje się ich opisy).

 

Sprint backlog i planowanie sprintu

Poza pracą w sprintach metodyki zwinne wprowadziły również określony zestaw spotkań, które mają na celu sprawne określenie zakresu danego sprintu, monitoring postępów prac, a także ich podsumowanie. W Scrumie zdefiniowane zostały 4 kluczowe wydarzenia (tzw. eventy):

  • Planowanie
  • Daily
  • Podsumowanie
  • Retrospekcja

Dla procesu zarządzania zmiennością wymagań absolutnie kluczowe znaczenie ma pierwszy element powyższej listy, czyli Planowanie sprintu. To na tym spotkaniu zespół decyduje, co z listy wymagań (Product backlogu) dostarczy w ciągu najbliższego Sprintu. Product Owner sygnalizuje, które historyjki są dla niego najistotniejsze poprzez umieszczenie ich na samej górze listy, ale to zespół decyduje (negocjując z Product Ownerem), jak wiele tematów jest w stanie wziąć na swoje barki.

Wynikiem Planowania jest tzw. Sprint backlog, czyli zakres najbliższego sprintu. Kluczowe założenie, które przyświecało twórcom Scruma, kiedy określali sposób pracy ze Sprint backlogiem to przerzucenie pełnej odpowiedzialności za dostarczenie wyników Sprintu na zespół.

Drugim istotny z punktu widzenia zmienności wymagań wydarzeniem scrumowym jest Podsumowanie sprintu. To w trakcie tego spotkania zespół przedstawia rezultaty pracy z ostatniego Sprintu oraz wysłuchuje uwag od zleceniodawcy. Jest to bardzo dobra okazja do zrewidowania założeń, którymi zespół kierował się do tej pory, wprowadzenia zmian do zakresu projektu (Product backlogu) oraz modyfikacji priorytetów w kontekście planowania kolejnego sprintu.

 

Podsumowanie

Metodyki zwinne, a w szczególności Scrum, wypracowały skuteczny sposób na adaptowanie się do zmiennego środowiska biznesowego, w którym są wykorzystywane. Scrum największą popularność zdobył w branży informatycznej, w której potrzeba elastyczności i otwartości na zmianę jest bardzo duża. Nie oznacza to jednak, że podejście zwinne jest lekarstwem na problemy z zakresem we wszystkich projektach. W pewnych branżach (np. budownictwo) często nie możemy sobie pozwolić na  iteracyjne podejście do projektu. Stawiając wieżowiec, musimy już na starcie projektu znać dokładny zakres potrzebnych prac, ponieważ nie będziemy w stanie modyfikować fundamentów budynku, kładąc 34 piętro. Scrum i zwinne zarządzanie wymaganiami nie jest zatem lekarstwem na wszystkie projektowe bolączki. Może jednak znacząco ułatwić proces wytwórczy oprogramowania, pod warunkiem, że zarówno strona biznesowa, jak i zespół deweloperski w pełni rozumieją jego filozofię.

123...5Następny Podstrona 1 z 5

POLECANE

© 2018 JestemPM.pl