W pierwszym artykule omówiłem potrzebę właściwego zdefiniowania celu projektu. Kiedy już ten cel zostanie zdefiniowany należy się zastanowić, w jaki sposób go zrealizować. Do tego potrzebni są ludzie, którzy stworzą dobrze działający zespół. Jaki jednak ten zespół powinien być, żeby szanse na powodzenie projektu były jak największe? Co oznacza interdyscyplinarność? Czy jest na to jakaś formuła?

7 nawyków sukcesu projektu
W tym cyklu artykułów chciałbym pokusić się o próbę zdefiniowania tych czynników, które z mojej perspektywy i doświadczeń wpływają na sukces projektów. Uważam, że są w tym przypadku kluczowe. Nie dają one gwarancji sukcesu, jednak każda z takich małych cegiełek pozwala go przybliżyć.

Zespół

Uważam, że mam niezwykłe szczęście, gdyż od długiego czasu pracuję przy projektach zawodowych z grupą osób, która rozumie cele projektowe i jest doświadczona w realizacji złożonych wyzwań informatycznych. To ważne, bo daje to poczucie pewności działań.

Przez blisko 10 lat aktywności zawodowej miałem okazję obserwowania bardzo różnych organizacji, z bardzo różnymi strukturami i hierarchiami. W wielu z nich widziałem zespoły, które realizowały różne wyzwania. Z różnym skutkiem. Czasem wydawałoby się, że proste projekty kończyły się fiaskiem, czasem było wręcz na odwrót – bardzo złożone zagadnienia okazywały się niezwykłym sukcesem.

Zespoły, które znały i rozumiały cele biznesowe najczęściej wygrywały ten projektowy maraton. Pozostałe, no cóż, jeśli czytałaś lub czytałeś mój poprzedni artykuł – te “nadal wdrażały mityczny system ERP”… często przez wiele lat bez skutku.

Jasny cel to tylko część sukcesu. Grono ludzi budujących zgrany zespół to kolejna cegiełka projektowa, która może pomóc Ci w drodze na projektowe szczyty.

Rozprawmy się więc z kilkoma tematami, które dotyczą pracy zespołowej.

Interdyscyplinarny zespół, czyli jaki …?

Zespoły, z którymi pracowałem i odnosiły największe sukcesy były interdyscyplinarne.

Interdyscyplinarny zespół stał się jakiś czas temu popularnym zwrotem w kręgach IT. Dostrzegam jednak bardzo popularny problem, który się z nim wiąże. Ale zacznijmy od tego, jak słownik języka polskiego definiuje słowo interdyscyplinarny:

• dotyczący dwu lub więcej dyscyplin naukowych,
• korzystający z dorobku kilku nauk,
• złożony z naukowców reprezentujących różne gałęzie wiedzy.

Jeśli przełożymy to na świat IT, to interpretacja na poziomie zespołu jest dosyć prosta. Oznacza ni mniej ni więcej, że w jego skład powinni wchodzić ludzie z różnymi kompetencjami. Zbiór tych posiadanych kompetencji powinien zapewnić rozwiązania dla całego spektrum wyzwań w danym projekcie.

Uwaga!

Tutaj pojawia się popularny problem, o którym wspomniałem wcześniej. Bardzo często byłem świadkiem sytuacji, w których interdyscyplinarność rozumiano, jako zespół składający się z jednego doświadczonego programisty i większej liczby początkujących adeptów szkoły kodowania. Wszak jest to zbiór różnorodnych kompetencji. Brak kompetencji też można uznać za pewnego rodzaju kompetencję samą w sobie. Jeśli w Twojej organizacji pokutuje taki model myślenia i zastanawiasz się, dlaczego projekty nie kończą się sukcesem, to dobrze trafiłeś. Wyjaśnienie znajduje się w dalszym tekście, a Ty już teraz zacznij zastanawiać się, czy organizacja, w której pracujesz mogłaby coś zmienić lub zmień po prostu organizację na inną.

Po co ta cała interdyscyplinarność?

Bo chcemy uzyskać jak najlepsze dopasowanie na linii biznes – IT. A to wymaga postrzegania i zrozumienia potrzeb na bardzo wielu płaszczyznach. Dla przykładu:

• Analityk biznesowy będzie budował uzasadnienie projektu (ang. business case), będzie szukał procesów biznesowych, KPI, etc.
• Specjalista od UX będzie zajmował się badaniami użytkowników, badaniem interakcji, zachowania aplikacji, architekturą informacji, czy też końcowym makietowaniem.
• Architekt będzie wiązał kawałki systemu z już istniejącymi elementami, tworzył koncepcję rozwiązania, rozważał podstawy wydajności, czy też niezawodności systemu oraz jego bezpieczeństwo.

Ostatecznie chcemy uzyskać, tu jako IT, taki produkt, którego oczekuje nasza strona biznesowa. Nic więc dziwnego, że różnorodność kompetencji w tym nam pomaga.

Ale jaki powinien być poziom tych kompetencji?

Adekwatny do projektu.

Pamiętaj, że jeden dobry programista, to gwarancja dobrego kodu. I tylko tego. Nikt nie zagwarantuje, że kod ten będzie spełniał oczekiwania biznesowe.

Bo, jak w powiedzeniu, jedna jaskółka wiosny nie czyni…

Dlatego sugerowałbym skupić się na zbudowaniu zespołu składającego się ze specjalistów z obszarów potrzebnych do realizacji danego wyzwania. A wprowadzanie nowych, jeszcze nieopierzonych członków zespołu, potraktować jako dłuższy proces, który stopniowo należy realizować w trakcie życia projektu.

A jak zorganizować im pracę?

Generalnie, jeśli występujesz tu w roli kierownika projektu, to tego nie narzucaj.

Z praktycznego punktu widzenia być może Twoja organizacja realizuje przedsięwzięcia zgodnie z którąś z metod projektowych, a wówczas od razu sprawa jest dosyć jasna, bo ludzie są do takiego stanu rzeczy przyzwyczajeni. Jednak należy zawsze wziąć pod uwagę oczekiwania zespołu.

To, co do tej pory złożyliśmy to zespół składający się ze specjalistów z różnych obszarów kompetencji. W pierwszej części tej serii artykułów pisałem o celu projektowym. Wyznacz zatem mądry cel projektu, a ludzie w zespole sami będą wiedzieli, jak zorganizować wokół niego pracę, co zrobić najpierw, a co na końcu. Cel będzie ich motywował, jeśli w niego uwierzą.

Ale, czy oni mi tu nie rozwalą projektu?

Z tym pytaniem spotykałem się dosyć często na poziomie menadżerskim. Osobiście uważam, że takiego pytanie nie zadają dobrzy menadżerowie.

Dlaczego?

Bo wiedzą, że człowiek nie pracuje wydajnie, jeśli narzuca się mu sposób realizacji zadania.

Nie od dziś wiadomo, że jeśli ludzie w coś wierzą, to są o wiele bardziej zmotywowani, żeby taki cel osiągnąć. Są bardziej produktywni. Nie każdy projekt musi być niesieniem pomocy na drugim końcu świata, ale jeśli ludzie rozumieją, co robią, po co to robią i jednocześnie widzą w tym sens, to już spora część sukcesu będzie po Twojej stronie.

No to chociaż, czy mogę monitorować postępy?

Oczywiście, że tak. Zdziwiłbym się, gdybyś tego nie robił/a? Jasne oczekiwania odnośnie różnych faz projektu należy omówić z zespołem, ustalić listę produktów częściowych i na bieżąco podglądać postęp prac.

Wokół projektu często jest całe spektrum interesariuszy, którzy chcieliby monitorować i kontrolować wykonywaną pracę. Jednak można to robić lepiej lub gorzej.

Jedna mądra zasada, której staram się przestrzegać od pewnego czasu:

Nie pytaj zespołu, jak idzie. To, że tego nie wiesz, to Twój problem, ale rozwiązaniem nie jest chodzenie za ludźmi i pytanie ich o to w kółko. Twórz komunikację tak, żeby ta informacja trafiała do Ciebie samoistnie.

No dobrze, a jak duży powinien być taki zespół?

A jak duży jest Twój projekt? Oczywiście odpowiedź zależna jest od wielu czynników. Pamiętaj jednak, że duże zespoły wykorzystują dużo czasu projektowego.

Osobiście uważam, że projekty łatwiej zaczynać z mniejszym zespołem niż by się wydawało na pierwszy rzut oka i poświęcić jedną, czy dwie iteracje, na zbadanie szybkości pracy, weryfikacji wszystkich wymagań oraz wstępne prace nad prototypem. Pozwala to na utworzenie solidnych fundamentów już na początku. Jednocześnie przy zdrowym zarządzaniu zasobami projektu.

W przypadku większych projektów podzieliłbym je na odpowiednie jednostki w ramach domen problemów i wokół nich budował zespoły. Jest to oczywiście trudniejszy scenariusz, ale moim zdaniem łatwiej jest zarządzać w taki sposób niż np. 30 osobowym zespołem z jednym rejestrem sprintu.

Podsumowanie

Drugi nawyk sukcesu projektowego brzmi:

Drugi nawyk sukcesu projektu
Zbuduj interdyscyplinarny zespół posiadający kompetencje potrzebne do realizacji projektu i dążący do realizacji wspólnego celu.

Na temat budowania zespołów napisano już niejedną książkę. Pamiętaj jednak, że każdy zespół jest inny. Podchodź do tworzenia takiej jednostki indywidualnie. Cały czas dbaj o zrozumienie celu projektowego przez jego członków.

Życzę sukcesów projektowych i głęboko wierzę, że ten artykuł może pomóc Ci w określeniu, czy jesteś na drodze sukcesu, czy też dryfujesz, gdzieś na oceanie projektowym.