Zarówno Agile jak i tzw. metoda turkusowa wymagają zmiany sposobu myślenia i – tak jak każda zmiana – uwolnienia się od starych przekonań i eksperymentowania z nową wizją rzeczywistości. Oznacza to odejście od kaskadowego i hierarchicznego zarządzania, gdzie bardzo ważny był wcześniej przygotowany plan, a decyzyjność była w rękach szefa. W obu analizowanych przypadkach zespół ma większe uprawnienia niż w tradycyjnym modelu zarządzania, co przekłada się na większą elastyczność i kreatywność, a także zaangażowanie poszczególnych członków zespołu.
Rozmawiamy z Mariuszem Augustyniakiem, Senior Project & Program Managerem w DXC Technology, który opowie, jak radzić sobie z wyzwaniami, pojawiającymi się podczas kierowania projektami, a także przybliży różne style zarządzania.
Zdarza się, że projekty, mimo znajomości dostępnych metodyk zarządzania, upadają lub mijają się z oczekiwaniami interesariuszy. Gdzie szukać przyczyny?
Badania i statystyki nieudanych projektów (w tym The Chaos Report, The Standish Group) wskazują na następujące przyczyny niepowodzeń:
- niepełne i niejasne określenie wymagań oraz brak właściwego zdefiniowania zakresu;
- brak efektywnej komunikacji;
- brak zaangażowania użytkowników końcowych;
- niewłaściwe zarządzanie projektem o dużej skali i złożoności oraz niewystarczające planowanie.
A jaka jest Pana diagnoza tych problemów?
Presja czasu, a także pilnowania kosztów sprawiają, że nie wszystko jest dobrze przemyślane, przedyskutowane i opisane. Dodatkowo dochodzi fakt, że technologia dynamicznie się zmienia, więc coraz trudniej jest określić, jak system ma wyglądać za np. rok. Efektem są niejasne wymagania klienta, co przekłada się na nieprecyzyjne ujęcie zakresu projektu.
Druga sprawa to od lat podstawowy czynnik niepowodzeń projektów, czyli tzw. „czynnik ludzki”. Kultura powierzchownej i jednostronnej komunikacji odbija się w zespołach projektowych jak w lustrze. Brak wielowymiarowej i wielopunktowej rozmowy, prawdziwego słuchania i wzajemnego rozumienia powodują szereg przekłamań i problemów podczas projektu, łącznie z ignorowaniem użytkowników końcowych.
Na koniec tego minikatalogu głównych problemów, dochodzi przekonanie, że małym i prostym projektem każdy może zarządzić. Problem zaczyna się, jak pojawi się duży i złożony projekt. Wtedy wychodzą braki słabo przygotowanych i mało doświadczonych kierowników projektu. Oczywiście, to może być szansa na przyspieszoną naukę, poprzez skoczenie na „głęboką wodę”, albo też ostatni projekt w danej organizacji.
Jak w takim razie można poradzić sobie z takimi wyzwaniami?
Praktyki, które nazywane są zwinnymi, skutecznie adresują wiele powyższych problemów. Jeśli faktycznie nie jest możliwym zdefiniowanie wszystkich wymagań na początku i przełożenie na zakres projektu, ustalmy tyle, ile wiadomo w danym momencie, i to wdrażajmy. Wtedy jednak musimy zakomunikować to wszystkim, aby odpowiednio ustawić oczekiwania, bo ten produkt będzie powstawał „w kawałkach”. Dodatkowo, im szybciej będziemy mogli udostępnić prototyp systemu do oceny, tym szybciej uzyskamy feedback i skorygujemy bieg, czyli kierunek developmentu. W rezultacie wszyscy będą wiedzieć, na czym „stoją” i nie będzie przykrych niespodzianek.
Kwestia „czynnika ludzkiego” to bardziej złożony problem, ale weźmy pod uwagę temat współpracy i komunikacji. W Agile spotkania mają miejsce codziennie. Są krótkie, o prostej formule, ale treściwe i na temat. Bardzo szybko, czasami nawet po kilku tygodniach, tworzy się zgrany i zintegrowany „jeden zespół” projektowy, niezależnie od tego, gdzie, kto i na jakim stanowisku jest faktycznie zatrudniony. W tym zespole jest również przedstawiciel użytkowników końcowych, reprezentujący ich głos. Dodatkowo, w trakcie cyklicznych przeglądów mogą pojawić się przyszli użytkownicy, żeby zobaczyć demo roboczej wersji systemu i zgłosić uwagi na wczesnym etapie powstawania rozwiązań.
Analizując kompetencje i profesjonalizm kierowników projektu, warto podkreślić istotność ciągłego podnoszenia kwalifikacji, zdobywania wiedzy i certyfikatów, uczenia się na własnych doświadczeniach, a także od bardziej doświadczonych kierowników projektu. W tym miejscu chciałbym zwrócić uwagę na wartość mentoringu. Przydzielenie mało doświadczonego kierownika projektu do dużego i skomplikowanego przedsięwzięcia to stres dla tego kierownika, ale także ryzyko i potencjalne koszty oraz utrata reputacji dla managera z nim współpracującego, a także sponsora. Pewne sytuacje można uratować, przypisując kierownikowi o mniejszym doświadczeniu starszego kierownika projektu, który oferuje wsparcie i rozwiązania, szczególnie w gorących momentach pracy.
Skąd wzięło się u Pana zainteresowanie metodami zwinnymi?
Wydawało mi się to bardzo naturalne od momentu, jak tylko zacząłem prowadzić projekty, żeby być blisko klienta, dokładnie rozumieć, co jest do zrobienia, i na każdym etapie to weryfikować, szukając jednocześnie szans i reagując na zmiany. Od zawsze preferowałem interaktywny tryb pracy, angażujący wszystkie strony – zespoły własne, klienta i podwykonawcy. Pracując w Anglii w latach 2006–2008, tak właśnie realizowałem projekty, jeszcze nie znając metodyk Agile i nie słysząc o Manifeście Agile. Jedną z rekomendacji, jaką wystawił mi mój klient w 2008 roku, uważam za swoiste „trofeum”, bo już wtedy Greg Owens z Police Mutual Assurance Society użył słowa „agile” w odniesieniu do określenia mojego stylu pracy. Pracowałem wtedy dla firmy konsultingowo-informatycznej Aspective, będącej częścią Vodafone Enterprise Group UK.
A przyglądając się swojej ścieżce kariery, czy sądzi Pan, że coś jeszcze mogło przyczynić się do tego stylu prowadzenia projektów?
Przez wiele lat byłem zafascynowany koncepcją CRM (Customer Relationship Management), czyli podejściem klientocentrycznym. Uważam, że to była jedna z najlepszych strategii końcówki lat 90. i początku tego stulecia. Wyjście od zrozumienia klienta – tego, co chce zrobić i osiągnąć – jest istotne, a do tego dochodzi zbudowanie relacji, poprzez bliską współpracę i bezpośrednią komunikację.
W taki oto sposób własną ścieżką doszedłem do zinternalizowania wartości zwinnych zanim, lata później, przeczytałem o nich w Manifeście Agile i Scrum Guide:
- ludzie i interakcje ponad procesy i narzędzia
- działające oprogramowanie ponad szczegółową dokumentację
- współpraca z klientem ponad negocjacje umów
- reagowanie na zmiany ponad realizację założonego planu
Coraz większą popularność zdobywa obecnie styl zarządzania turkusowego. Na czym polega to podejście w praktyce?
Ten partnerski styl zarządzania, a właściwie współpracy, osadza się na dążeniu, aby zespół cechował się samozarządzaniem (ang. self managing team). Darząc członków zespołu zaufaniem, przekazuje się im znaczną decyzyjność, a oni odwdzięczają się odpowiedzialnym podejściem do zadań. W tym modelu ludzie starają się w obliczu pojawiających się trudności szukać rozwiązań, a nie winnych. Nie wypatruje się kozła ofiarnego, a adresuje się bieżące problemy i wyciąga naukę z zaistniałej sytuacji. Zaangażowani w przedsięwzięcie, czując się bezpiecznie, śmiało rozwijają swoje skrzydła i realizują się w pracy.
Ludzie, z którymi pracuję, na ogół są bardzo dojrzali i mają dużą wiedzę oraz doświadczenie. Wystarczy wyznaczyć cel, odpowiednio ich ukierunkować i wspierać w razie potrzeby. Wierzę, że takie podejście zwiększa satysfakcję z pracy i zaangażowanie w projekt. Trudno się więc nie zgodzić z tym, co powiedział Steve Jobs:
„To bez sensu: zatrudniać mądrych ludzi, by potem mówić im, co mają robić. My zatrudniamy mądrych ludzi po to, aby to oni mówili nam, co robić”.
A co jeszcze przyczyniło się do wyrobienia w sobie stylu zarządzania turkusowego i zwinnego?
Sądzę, że proces poznania i wejścia w coaching pomaga mi lepiej wykorzystywać potencjał oraz wiedzę grupy i poszczególnych członków, a także budować środowisko polegające na zaufaniu i wsparciu. Coaching jest też pomocny w pracy nad inteligencją emocjonalną, umiejętnym zadawaniem pytań i – co równie ważne – uważnym słuchaniem odpowiedzi. A to elementy pracy, które warto w sobie pielęgnować. Przydadzą się bowiem nie tylko kierownikom projektów, ale także każdemu managerowi.
