Zwinność w projektach. Fakty i mity – czyli jak nie dać się zwariować

Zwinność w projektach. Fakty i mity – czyli jak nie dać się zwariować

Zwinność w projektach

Jak się odnaleźć wśród trudnych słów “Agile, metodyki zwinne, SCRUM-y”. Te terminy robią karierę w ciągu ostatnich kilku lat. Zyskały dużą popularność ze względu na przekonanie wielu osób, że właśnie tak powinno się pracować. Nie dla schematów, dokumentacji, tylko dla prawdziwego efektu i w środowisku, w którym człowiek czuje się przydatny i szanowany. Agile towarzyszy mi od 2003 roku, gdy poprowadziłem mój pierwszy projekt w taki sposób. To pewna filozofia działania, bardzo sensowna zresztą :), która bardzo napędza 12 pytań KISS PM

Skąd się wzięło Agile i o co chodzi?

Podejście zwinne wzięło się od zastanawiania się jak można wytwarzać oprogramowanie lepiej niż do tej pory. Okazało się, że w świecie IT metody zarządzania  wzięte z budownictwa (bo tam zarządzanie projektami było najbardziej rozwinięte) nie sprawdza się tak dobrze! Dlatego, że to inna charakterystyka pracy i wytwarzanego produktu. Dlatego kilku doświadczonych facetów spisało sobie tzw. Agile Manifesto, który DOTYCZYŁ ZWINNEGO WYTWARZANIA OPROGRAMOWANIA, na to warto zwrócić uwagę. Poniżej jego tłumaczenie

Manifest programowania zwinnego

Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy, zaczęliśmy bardziej cenić:

Ludzi i interakcje od procesów i narzędzi
Działające oprogramowanie od szczegółowej dokumentacji
Współpracę z klientem od negocjacji umów
Reagowanie na zmiany od realizacji założonego planu.

Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.

Jak ja rozumiem zwinność?

Gdy pierwszy raz przeczytałem manifest to się zakochałem. W filozofii i podejściu. Wydawało mi się takie inne i świeże wobec tego, co płynęło z innych kierunków dotyczących projektów. Doświadczenie pokazało mi, że trzeba spojrzeć na to z bardziej dojrzałej perspektywy. Większość projektów pracy na świecie to nie wytwarzanie oprogramowania, dlatego tłumaczę te idee na wszystkie projekty, bo jest tu ukryte kilka fundamentalnych elementów, które dotyczą KAŻDEJ DZIAŁALNOŚCI.

Kilkanaście lat doświadczenia pokazuje, że manifest bardzo fajnie ujmuje kluczowe 9 elementów, o które trzeba dbać w projekcie. Tylko te 9 to nie wszystko 🙂

1. Relacje – to ludzie robią projekty. Lubimy fajnych ludzi i dobrą atmosferę, tego nie da się przeskoczyć niczym. Trendy „employer branding”, „CSR”, „pracownik najwyższym dobrem” docierają do tego – relacja to potężny klucz do sukcesu w każdej dziedzinie.

2. Procesy – brzydkie słowo, ale one organizują nam pracę! Sprawiają, że jest bardziej efektywna i przyjemniejsza. Pozwalają oszczędzać czas i nerwy. Oczywiście jak ktoś myśli o nich w kategoriach „mają pomagać osiągać rezultat”, a nie są dla samego bycia. Większość organizacji nie tłumaczy dlaczego tak działa tylko mówi „jesteś za głupi i rób jak każemy”, co powoduje naturalny opór. Bez procesów nic nie istnieje. Nie wszystkie muszą być sformalizowane, ale niektóre wręcz tak! Mówię to jako osoba, która nienawidzi ograniczeń – są bardzo pomocne! Paradoks taki.

3. Narzędzia – oddzielam je od procesów, bo chociaż nie są czynnikiem wystarczającym do odniesienia sukcesu to są koniecznym! Mówiłem moim studentom „nie narzędzia, tylko nad sobą pracujcie!”. I niby mam rację, tylko ja sobie wypracowałem narzędzia przez te lata! Dotarło do mnie, gdy zacząłem trenować strzelectwo. Mogę pracować nad sobą, ale bez broni będę robił tylko „pif paf” przyjmując właściwą postawę. Idealne do kanału „Janusze Strzelectwa” 😉

4. Efekt – tutaj działające oprogramowanie. Chodzi o to, że przede wszystkim mamy zrealizować nasz cel. Mamy dostarczyć coś co działa i jest przydatne. Tutaj kryje się mega pułapka i ograniczenie  zwinnych metod – zakładają, że organizacja dostarczy uzgodnione wymagania (co każdy, kto robił cokolwiek kiedyś z wieloma osobami i działami wie, że nie jest łatwe), dlatego pierwsze 4 pytania z 12 pytań KISS PM mają na celu ustalić kierunek właśnie i zapobiegać robieniu dobrze czegoś, czego nikt nie chce.

5. Koszt utrzymania (Dokumentacja) – nikt nie lubi robić dokumentacji :). Nikt kogo znam :). To nudne strasznie i najczęściej mamy już dość projektu, chcemy robić coś nowego, dlatego dokumentacja to taka „sierotka”. Spisywanie wszystkiego do ostatniej kropki nie ma sensu, ale to nie o dokumentację tu chodzi, tylko KOSZT UTRZYMANIA tak naprawdę! W każdym projekcie, gdy powstanie coś, co trzeba utrzymać konieczne jest przeszkolenie ludzi, którzy będą się tym zajmować. Bo wszystko trzeba serwisować, czasem poprawiać. Trzeba się zastanowić co będzie nam naprawdę potrzebne i to wykonać. Inaczej okaże się, że koszty projektu „po jego zakończeniu” są ogromne.

6. Współpraca z klientem – oj tak! To jest mega punkt ważny i  zapalny. I łatwo powiedzieć, trudniej zrobić. W przypadku SCRUM tę pracę ma wykonać osoba pełniąca rolę Product Ownera. Problem polega na tym, że to bardzo trudna robota! I jest kluczem do ostatecznego sukcesu lub porażki. Bo trzeba umieć przekonać nie tylko klienta, ale całą organizację co ma być wykonane, dlaczego tak, ustalić co ważne. Tytaniczna praca często! Tutaj mamy konflikty, relacje, przywództwo, osobowość. Naprawdę ogromny punkt.

7. Negocjowanie umów – nie robię już projektów bez umowy. Ze względu na relacje właśnie. Jeżeli nie spiszemy na papierze na co się umawiamy to prosta droga do konfliktu, bo w kryzysie nikt nie pamięta co się mówiło. A ja nie chcę psuć sobie relacji. Umowy pisze się na czas wojny, a nie pokoju i naprawdę warto się do nich przyłożyć. Dodatkowo dzięki spojrzeniu na umowę pod kątem ryzyka przez prawników można naprawdę ulepszyć projekt. Ja tam cenię sobie umowy. To, że najprościej jest powiedzieć „prawnicy to darmozjady” nie zmienia faktu, że to lenistwo intelektualne po prostu. Umowy są ważne. Bardzo.

8. Reagowanie na zmiany – oczywiście, że tak! Nie ma projektu, w którym nie pojawiają się zmiany. Zabawa polega na tym, żeby mieć „proces wprowadzania zmian”. Brzmi słabo, ale tak naprawdę w podejściu zwinnym ten proces jest bardzo restrykcyjny! To nie jest tak, że wszystko można w każdym momencie :). Zawsze jest coś za coś plus dodatkowo zamrażamy zmiany na pewien czas (realizacji jednej iteracji), bo inaczej planowanie się rozpada.

9. Realizacja planu – plan to nie tylko produkt! I o tym często zapominają osoby promujące metodyki zwinne! Produkt najczęściej jest częścią większej całości. Trzeba uwzględnić promocję, dystrybucję, sprzedaż, serwis, finanse, controlling. Masę rzeczy! Jeżeli patrzysz tylko na perspektywę wytwarzanie to okazuje się, że świat jest prosty. Ale gdy spojrzysz całościowo widać, że to nie jest takie proste! Trzeba zgrać ze sobą wiele funkcji, czasem firm. Zmiana w jednym aspekcie łańcuchowo ciągnie za sobą zmiany w pozostałych!

Dziś tłumacze sobie manifest – Wszystko jest ważne! Tu chodzi o harmonię tych elementów, a nie stawianie pomiędzy nimi znaku „vs.”. To ślepa uliczka!

Prawdziwa tylko z punktu wygody specjalisty „Nie wrzucajcie mi tutaj umów, dokumentacji. Nie chcę sztywnych procedur ani harmonogramu. Ja tu jestem artystą!”.  Taka ścieżka do niczego nie prowadzi.

Zwinne podejście wymaga:

Zrozumienia zasad – widziałem projekty zabite przez fanatyczne zrozumienie manifestu, słyszałem też ludzi mówiących „Twój projekt nie jest agile, bo nie masz artefaktów agile!”. Święta wojna taka :). Bierz to, co Ci potrzebne i wdrażaj w życie. Metody są wtórne do zasad. Przed SCRUM był RUP i Extreme Programming. Po nim będą nowe. A zasady się nie zmienią. Studiuj zasady.

Dyscypliny w ich stosowaniu – nie wystarczy wiedzieć jak się biega. Trzeba biegać, żęby mieć efekty. Albo trzymasz się zasad albo polegniesz. Pamiętaj też o tym, że nie da się na siłe zastosować pewnych metod w innych miejscach. Coraz więcej organizacji widz

PM cojones – trzeba mieć twarde, żeby umieć się postawić całej organizacji i robić coś inaczej niż wszyscy. W Extreme Programming bardzo podobała mi się zasada „Odwaga” :).

Pracy nad sobą i zespołem – nie wszyscy są gotowi do pracy w ten sposób. Niektórzy nie chcą pracować z zespołem! Naprawdę! Nie wciskaj ich na siłę w metody, które są dynamiczne i mają swoje ograniczenia jednak.

Umiejętności spojrzenia w szerszej perspektywie. Jeżeli znasz moją książkę to wiesz, że bardzo dużo ciepłych słów o metodach zwinnych tam padło i widać tę filozofię na każdym kroku. Jeżeli okazuje się, że próbujesz zastosować SCRUM w organizacji i „nie trybi” to znaczy, że bez wyjścia z poziomu produktu na poziom projektu nie ruszysz.

Niech moc PM-jitsu będzie z wami!

aaa

Mariusz Kapusta
Mariusz Kapusta
Ekspert zarządzania projektami z ponad 17 letnim doświadczeniem, trener i przedsiębiorca. Od prawie 9 lat jest też właścicielem firmy Leadership Center. Autor książki „Zarządzanie projektami krok po kroku” i twórca metody 12 pytań, które w bardzo prosty sposób uczą zarządzania projektami. Z pasją tworzy gry symulacyjne dla managerów. Triathlonista i maratończyk. Wielbiciel Rozwoju Osobistego, czemu daje wyraz na mariuszkapusta.pl

Dodaj komentarz

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