Kulisy formowania zespołu IT w korporacji

Ciężko jest zrobić coś z niczego - projekt informatyczny zespołu potrzebuje a im lepsi profesjonaliści wchodzący w jego skład tym lepiej. Bez zespołu nie ma projektu. Oczywiste? Nie dla wszystkich.

Kto ma wpływ na skład zespołu w korporacjach?

W firmach zatrudniających powyżej określonej liczby pracowników, zwanych pejoratywnie korporacjami, często spotyka się hierarchiczny model zarządzania firmą. Nie jest to zły model pod pewnymi warunkami. Jednym z tych warunków jest doświadczony, rozsądny kierownik komórki organizacyjnej, w której ma być realizowany projekt. Jego decyzje przekładają się bezpośrednio na to, jakim zespołem kierownik projektu dysponuje i będzie kierował, ponieważ to kierownik komórki organizacyjnej, jako przełożony kierownika projektu, przydziela mu zasoby.

Problem 1: Brak wykwalifikowanych zasobów

Jak powiedziane zostało wyżej, zespół jest formowany w korporacjach przez kierownika projektu i kierownika komórki organizacyjnej.

Może się zdarzyć, że  kierownik komórki organizacyjnej nie będzie w stanie ("co ja mogę?") lub nie będzie chciał ("są ważniejsze projekty") zaspokoić wymagań kierownika projektu co do zespołu, jaki jest konieczny do realizacji projektu. Może się zdarzyć tak, że nie będzie on w stanie zadziałać tak, by pozyskać odpowiednie zasoby z firmy. Lub tak, że będzie on przydzielał kierownikowi projektu ludzi dostępnych akurat w tym momencie, niekoniecznie osoby, które przez swoje doświadczenie i umiejętności odpowiadają na zapotrzebowanie wyspecyfikowane przez kierownika projektu, zarówno jeśli chodzi o liczebność zespołu jak i znajomość konkretnych technologii. Będą to po prostu dostępne w tym momencie osoby, nierzadko stażyści lub początkujący programiści, którzy na pieniądzach klientów uczą się dopiero technologii. Jako rezultat tych czy innych przyczyn dostaniesz do realizacji projektu zespół niewykwalifikowany.

Rozwiązanie:

• przy takim rozłożeniu sił, kiedy  kierownik komórki organizacyjnej przydziela zasoby do projektu a dostałeś mniej wykwalifikowane zasoby niż byś mógł należy już użyć nieco polityki, 
• jeśli faktycznie nie ma możliwości uformowania bardziej doświadczonego zespołu uświadom kierownika komórki o poziomie wiedzy tego zespołu i o tym, jak niski poziom jego wiedzy przekłada się na jego wydajność a z tym na przewidywaną datę końcową projektu. Ja w takich sytuacjach zwykłam używać jednostki mandays - programistę na poziomie średnio zaawansowanym liczyłam jako zasób o "wartości" 1MD, programistę-nowicjusza, zależnie od jego umiejętności, w przedziale 0,25-0,5 MD, wydajność zespołu była sumą takich mandaysów. Takie przedstawienie wydajności zespołu uzmysławia kierownikowi komórki, że zespół 5 nowicjuszy jest wart w rzeczywistości około dwóch (1,25 - 2,5) średnio doświadczonych programistów (a czasem nawet i mniej)
• poinformuj kierownika komórki, że realizacja projektu z takim zespołem jest demotywująca - masz prawo mieć szansę projekt zrealizować w terminie i kosztach a z niedoświadczonym zespołem ta szansa jest bliska zeru

Problem 2: Zespół z odzysku

Nie trzeba się silić, żeby wyobrazić sobie wartość zespołu składającego się z przypadkowo dobranych stażystów, wymienianych co chwila na innych stażystów czy nowych, niedoświadczonych pracowników.

Pracowałam kiedyś z zespołem "z odzysku" -  osoby przydzielane były przez kierownika komórki organizacyjnej do projektu na chwilę. Taki zespół nie ma struktury, nie można wyznaczyć konkretnych ról, wszystko pływa. Większość czasu kierownik projektu poświęca w takim przypadku na wdrożenia nowych osób do projektu zamiast na samą realizację celów projektowych. Jest to de facto ciągłe szkolenie nowo przybyłych do projektu osób bez zwrotu kosztów tego szkolenia - całkowity koszt takiego projektu rośnie niewspółmiernie do efektów, a projekt mający na celu spełnienie wymagań klienta zamienia się w centrum szkoleniowe.

U nas, przez takie roszady serwowane kierownikowi projektu przez kierownika komórki organizacyjnej, ani zespół ani kierownik nie byli w stanie pracować i realizować projektu.

Rozwiązanie:

• kiedy kierownik komórki będzie chciał kolejny raz przekazać Ci nowicjusza do projektu odmów z wyjaśnieniem przyczyn tej odmowy - nie masz czasu na ciągłe doszkalanie nowych członków zespołu a każde szkolenie to dodatkowy koszt,
• kiedy kierownik komórki obiecuje Ci pracownika, którego chcesz przyjąć do zespołu, żądaj od  kierownika gwarancji na dostępność tego pracownika na minimum dwa, trzy miesiące - nawet najlepsi potrzebują czasu, żeby się wdrożyć

Problem 3: Współdzielenie zasobów z przełożonym

W korporacjach współdzielenie zasobów w wielu projektach jest normą i nie ma w tym nic wyjątkowego ani niepożądanego. Jeśli w jednym okresie realizowanych jest wiele projektów, które nie wymagają ciągłej obecności osoby o danej rol (dobrym przykładem jest inżynier) można go oddelegować do innych projektów w razie potrzeby.

Jednak okropnym jest współdzielenie zasobów z przełożonym. Kierownik komórki stoi na drabinie organizacyjnej wyżej niż kierownik projektu i zapomina o podstawowych zasadach współpracy i współdzielenia dostępnych zasobów, podbierając kierownikowi projektu bez uprzedzenia i "na jedno zadanie" tych członków zespołu, których mu wcześniej przydzielił (niejednokrotnie tych, których kierownik projektu musiał sam wyszkolić i którzy w końcu zaczynają być wartościowymi, w kontekście zdobytej wiedzy technicznej, członkami zespołu, wnosząc do projektu mierzalny wkład).

W takiej sytuacji każde planowanie kierownika projektu jest bezcelowe, nie wiedząc czy jego przełożony nie zabierze mu za chwilę kluczowej osoby nie jest w stanie określić w harmonogramie ani dat, ani pracochłonności, nie jest też w stanie rozliczać zespołu z powierzonych zadań (bo jak rozliczyć programistę, który nie zrobił nic w projekcie przez ostatni tydzień, ponieważ przełożony kierownika projektu wyrwał go do zupełnie innego zadania nie informując go przy tym, już nie mówiąc, że nie pytał czy nie wpłynie to negatywnie na projekt). W takich okolicznościach kierownik projektu zwyczajnie nie jest w stanie projektu prowadzić.

Rozwiązanie:

• jeśli współdzielisz zasoby z przełożonym powiedz zespołowi, kto jest osobą autoryzowaną do zlecania im zadań, poinformuj o tej decyzji przełożonego i poproś go o zgaszanie zadań do realizacji bezpośrednio do Ciebie (lub kogoś, kogo wyznaczyłeś). Ty najlepiej wiesz, jak skoordynować prace, żeby zdążyć na czas. Jeśli ktoś będzie z pominięciem Ciebie wrzucał zespołowi nowe zadania Twój harmonogram rozsynchronizuje się i najprawdopodobniej za chwilę uwidocznią się opóźnienia),
• naucz zespół, żeby nie przyjmowali zadań od nieautoryzowanych osób. W przypadku, gdy nieautoryzowana osoba będzie chciała zlecić im jakieś zadanie, uczul ich, żeby odsyłali te osoby do Ciebie (nawet jeśli tą nieautoryzowaną osobą będzie ich wyższy przełożony!),
• ustal z przełożonym, jak będziecie się informować, kiedy będziecie chcieli wypożyczyć od siebie kogoś do swojego projektu, niech to będzie uzgodnione na waszym poziomie, programiści niech będą zwolnieni z tego, żeby rozważać, dla kogo dane zadanie wykonać

Zespół a sukces

Słaby kierownik jest w stanie z pomocą mocnego zespołu zrealizować projekt z sukcesem (w terminie, w ramach ustalonych kosztów czy spełniając inne Uzasadnienie Biznesowe). Nawet najlepszy kierownik nie jest w stanie osiągnąć tego sukcesu z kiepskim zespołem. 

Jako kierownik projektu masz prawo mieć własne wymagania odnośnie zespołu, którym zarządzasz. Pomyśl - gdyby trener nie miał wpływu na osoby, które szkoli do mistrzostw, jak można by go rozliczać z postępów? Niestety w korporacjach kierownik projektu nie ma jawnie wpływu na zespół, którym zarządza (dlatego wspomniałam, że czasem należy się uciec do polityki) a mimo to jest rozliczany z rezultatów. 

Jeśli jednak dostaniesz niewykwalifikowany zespół jasno zaznacz przełożonemu, gdzie jest tego zespołu granica, na ile można liczyć mając go do dyspozycji, nie zgadzaj się na cele, których nie będziesz w stanie z ich pomocą osiągnąć.