Czy powinniśmy łączyć metodyki zarządzania projektami?

Udostępnij

W pierwszym szkicu wpisu tytuł brzmiał: “czy można łączyć metodyki zarządzania projektami?”. Odpowiedź na to pytanie była zbyt oczywista: jasne, że można! Wielu ludzi tak działa. Właściwe pytanie brzmi czy powinniśmy to robić? Odpowiedź znajdziesz w kolejnych linijkach wpisu – zapraszam!

Doskonale pamiętam, gdy zaczynałem swoją przygodę z zarządzaniem projektami. Udałem się na jedną z konferencji, gdzie odbywał się wykład jednego z kierowników projektu. Był on (wykład) zbiorem bardzo ciekawych doświadczeń, które równocześnie przekazywały wiedzę w tematyce zarządzania projektami. W trakcie wykładu padło pytanie z sali: “czy powinniśmy łączyć metody prowadzenia projektów?”. Odpowiedź w mojej głowie brzmiała: “Oczywiście, że tak. Przecież bierzemy z każdej to, co najlepsze!”. Natomiast prowadzący wykład odpowiedział krótko “nie, nie powinniśmy”. Padła dygresja zmieniająca temat i wątek zniknął. Po wyjściu z konferencji zastanawiałem się długi czas, dlaczego nie powinniśmy łączyć metodyk prowadzenia projektów. Odpowiedź uzyskałem kilka fuckupów później 😉

to powinniśmy, czy nie?

By w pełni zrozumieć ten wpis, przeczytaj moją opinię na temat doboru metodyki i jej właściwego zastosowaniu.
Powracając do meritum, czy powinniśmy łączyć metodyki prowadzenia projektów? Odpowiedzią jest: “to zależy” ;). Łącząc dwie metodyki uzyskujemy wielką niewiadomą. Każda z nich osobno sprawdza się w praktyce. Natomiast czy ich połączenie będzie skuteczne dowiemy się po fakcie (po ukończeniu projektu). Te metodyki działają dlatego, że właśnie wyglądają w taki, a nie inny sposób. Jeśli nie bierzemy wszystkich zasad lub je modyfikujemy możemy trafić na minę.

Jaskrawy przykład: jeśli chcemy usunąć z samochodu wszystkie lusterka (ponieważ uważamy je za zbędne) nasza modyfikacja sprawdzi się tylko w przypadku gdy będziemy poruszali się po bezdrożach. W centrum miasta stłuczka będzie kwestią czasu. Zmodyfikowaliśmy zestaw cech i rezultat może być pozytywny lub negatywny. Pytanie brzmi: dlaczego chcieliśmy je usunąć? Jeśli powodem było to, że nie lubimy widzieć swojej twarzy to nasza modyfikacja będzie miała negatywne skutki. Zwiększyliśmy szansę na stłuczkę. Natomiast jeśli lusterka zostały usunięte bo dobrze radzimy sobie bez nich – jesteśmy w stanie obracać się i doskonale kontrolować sytuację. W takim przypadku nasza modyfikacja będzie miała pozytywny skutek: pojazd będzie lżejszy i bardziej aerodynamiczny bez odniesienia żadnych strat. Nazywamy to optymalizacją. Bardzo jaskrawy przykład, prawda? 😉

Analogicznie jest z łączeniem metodyk. Docelowo uzyskujemy efekt modyfikacji. Pytanie brzmi: dlaczego chcemy je łączyć? Jeśli powodem usunięcia retrospekcji ze Scruma jest to, że uważamy je za niepotrzebne ponieważ nie wiemy o czym na nich mówić to wynik modyfikacji będzie negatywny. Należy nauczyć się przeprowadzać ten fragment metodyki, zamiast z niego rezygnować lub zastępować go czymś innym. Bólu głowy nie leczy się gilotyną.

W związku z tym, że moja odpowiedź na pytanie “czy powinniśmy?”, brzmi: “zależy”,  przedstawię też drugą stronę medalu. W sytuacji gdy mamy doskonale opanowany każdy etap metodyki, rozumiemy ją dogłębnie – warto je łączyć i modyfikować. Właśnie w taki sposób powstają nowe metodyki, stare są optymalizowane i rozwój idzie do przodu. Warto dodać, że praktykowanie metodyki nie równa się jej pełnemu zrozumieniu –  co według mnie jest niezbędne żeby móc eksperymentować.

Podsumowanie

Jeśli nie czujesz się pewnie w danej metodyce – nie modyfikuj jej. Możesz narobić w projekcie więcej szkód niż pożytku. Gdy uważasz, że coś jest nieskuteczne, upewnij się, czy właściwie wykonujesz daną czynność. Natomiast jeśli jesteś ekspertem w stosowaniu danej metodyki i zauważasz, że pomimo perfekcyjnego wykonania można ją usprawnić – modyfikuj. Właśnie w ten sposób powstanie twoja personalna metodyka, która będzie działała w określonych przypadkach. Wnioskiem jest to by kwestionować metodyki i podejmować ryzyko poprzez ich modyfikacje, ale robić to z głową.

Napisz w komentarzu jak wyglądały skutki modyfikacji metodyki w twoich projektach 🙂


Stworzyłem ebook o zarządzaniu projektami, analizie IT i startupach, który możesz bezpłatnie pobrać zapisując się na poniższą listę mailingową.


Na co dzień prowadzę fresh-apps.com.

Jeśli wpis ci się spodobał, udostępnij go lub śledź mnie na facebooku, twitterze, LinkedIn lub subskrybuj mój kanał na YouTube – twoja interakcja motywuje do dalszego pisania! Jeśli interesują cię podobne treści, dopisz się do newslettera (na górze strony) :).


Udostępnij

3 thoughts on “Czy powinniśmy łączyć metodyki zarządzania projektami?

  • 12 kwietnia 2016 at 22:02
    Permalink

    Dla mnie inkrementalne modyfikowanie stylu pracy i metodyki jest czyms naturalnym i postrzegam to zawsze bardzo pozytywnie. Modyfikacji dokonujemy co 2-4 tygodnie. Nie sa to rewolucyjne zmiany ale mniejsze poprawki. Nawet jezeli pewna zmiana bedzie miala negatywny efekt, mozemy szybko nalozyc korekte i zmienic kierunek. Zaangazowany jest caly zespol i mam tez to szczescie ze Prodcut Owner ( CMO ) jest bardzo zrzyty z teamem i zbzikowany na punkcie produktu. Z 2 pmow mam jednego ktory jest bardzo aktywny i chce sie udzielac wiec zawsze sypnie ciekawym pomyslem. Procz dyskusji w teamie mamy tez ogolne dyskusje PMowie, Lead, Product Owner o potencjalnych zmianach problemach ktore mozemy wdrozyc by zwiekszyc skutecznosc zespolu ( poczatki byly trudne bo Product Owner ma ogromne ambicje i komunikacja nie zawsze sie udawala ).

    Co juz przerabialismy:
    – porzucenie scruma na rzecz kanbana (5x w zaleznosci od sytuacji w projekcie)
    – porzuczenie / przywrocenie standupow
    – dodanie / usuniecie grooming session
    – modyfikacje stylu prowadzenia retrospekcji
    – mieszanie srcuma z kanbanem (scrumban)
    – prowadzenie dwoch sprintow jednoczesnie ( kazdy pod innego pma, tutaj akurat byl mega fail 🙂 )

    Moglbys podac pare przykladow modyfikacji, dodatkow jakie przeprowadziles ?

    Reply
    • 20 kwietnia 2016 at 10:06
      Permalink

      Cześć, dzięki za komentarz! 🙂

      większość rzeczy pokrywa się z tymi, które przytoczyłeś czyli rezygnacja z czegoś lub modyfikacja stylu przeprowadzania spotkań. Po każdej rezygnacji z jakiegoś rdzennego elementu scrum (po pewnym czasie) dochodziliśmy do wniosku, że jest bardzo przydatny i przywracaliśmy go. Największą bolączką chyba była mieszanina ról między PM, SM i PO (czasami jedna osoba, była aktorem w więcej niż jednej roli) – to też z perspektywy czasu oceniam na minus 🙂

      Reply
  • 20 maja 2017 at 22:33
    Permalink

    Czy nie za szybko, modyfikujemy sprawdzone na świecie rozwiązania, aby? dosadne -nie leczy się bólu głowy gilotyną, (fajne), zamienił bym na ” są lekarstwa gorsze od choroby”. To temat na duży artykuł. Dwa przykłady – ludzie modyfikują Princa2 (po swojemu) , bo wydaje in się ,że jest zbyt rozbudowany, pomijając jedną z ważniejszych zasad -dostosowanie do warunków projektów i jeszcze się tym chwalą. W Scrumie łączą role SM i PO i jeszcze uważają to za innowacje., a co gorsza dalej nazywają to Princem i Scrumem. “Majsterkowicze” wszystkich maści łączcie się w uwielbieniu.

    Reply

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.