Trójkąt współpracy: produkcja, wdrożenie i sędzia (lub kat)

Nierzadki podczas realizacji projektów jest podział na zespół produkcyjny, czyli programiści zajmujący się aplikacją jako taką, oraz zespół wdrożeniowy, czyli wdrożeniowcy zajmujący się konfiguracją aplikacji na środowisku klienta.

Co złego to nie ja

Podczas jednego z tak prowadzonych projektów byłam kierownikiem od strony produkcji. Tak się bardzo nieszczęśliwie złożyło, że kierownikiem wdrożenia był mój przełożony. Nie życzę nikomu takiego rozłożenia projektów w jego komórce organizacyjnej. Z sytuacji, w której dwa zespoły powinny ze sobą współpracować celem osiągnięcia końcowego efektu rodzi się model zespół przełożony - zespół podwładny. Każda czynność do wykonania, łącznie z wszelkimi konfiguracjami, za które powinien być odpowiedzialny zespół wdrożeniowy, jest przerzucana na coraz to bardziej obciążony zespół produkcyjny a wszelkie problemy istniejące u klienta mają z założenia swoje źródło w zespole produkcyjnym.

U nas zaczęła się pewnego rodzaju nagonka na zespół produkcyjny, nagonka zupełnie niekontrolowana przez kierownika wdrożenia, czyli jednocześnie mojego przełożonego, a wręcz przez niego wzmacniana. Programiści zespołu produkcyjnego byli obwiniani notorycznie za błędy nieogarniętego zespołu wdrożeniowego.

Kat zamiast sędziego

Ponieważ nie ma w takiej sytuacji osoby obiektywnej, mogącej bez emocji ocenić sytuację między dwoma zespołami, przełożony, który w teorii powinien być sędzią i pomagać w sytuacjach konfliktowych, zamienia się w kata: każdy konflikt między wdrożeniem a produkcją przegra naturalnie podwładny (tu: kierownik zespołu produkcyjnego i zespół produkcyjny).

Kierownik produkcji w takim rozłożeniu projektów jest na przegranej pozycji - nie ma się do kogo zwrócić o pomoc. Co więcej - w przypadku, kiedy kierownik produkcji widzi, że część wdrożeniowa projektu przerasta kierownika wdrożenia, co wpływa negatywnie na cały projekt, nie może udać się do przełożonego w celu poinformowania o zagrożeniu, ponieważ właśnie przełożony, jak pamiętamy, jest tym właśnie kierownikiem wdrożenia. Istny absurd.

Konfliktową sytuację zaognił u nas fakt, że kierownik wdrożenia był kompletnie niezaangażowany w projekt, przerzucając całość prac i odpowiedzialność na produkcję, był zbyt optymistyczny i pewny siebie i w momencie, kiedy został przez klienta oczekującego postępów, jak i swojego przełożonego przyparty do ściany przebudził się z letargu i nie do końca jeszcze z tego letargu wybudzony, ale już na tyle, żeby się przestraszyć, jak zaspany człowiek, w popłochu i chaotycznie, zaczął szukać winnego poza sobą.

Programistę batem

Z czasem doszło do patowej sytuacji, kiedy zespół produkcyjny był obarczany błędami zespołu wdrożeniowego, a kierownik zespołu wdrożeniowego będący zarazem przełożonym kierownika produkcji zaczął, zamiast naprawiać własną sytuację projektową we wdrożeniu, proponować szalone pomysły, które miały de facto na celu szukanie winnych wśród produkcji i wytykanie ich palcem.

Pod pretekstem podsumowania dotychczasowych prac, podczas których każdy programista zespołu produkcyjnego miał opisać działanie danej funkcjonalności odbyło się biczowanie programistów, zostali oni zamknięci w psychicznej pułapce przełożonego i smagani batem bezsensownych pytań i bezpodstawnych oskarżeń o niedokładność i brak zaangażowania, ośmieszane były ich mniejsze lub większe decyzje, padały sformułowania, że coś jest "zrealizowane bez sensu" a nawet, że to jest "ch...we". Małe przedstawienie kierownika wdrożenia czyli mojego przełożonego przed jego przełożonym.

Było to bardzo irytujące dla mnie spotkanie (irytujące jest delikatnym słowem - nie byłam zirytowana, byłam wściekła) wiedząc, jak bardzo ci zrugani programiści starali się realizując projekt, ile serca włożyli w swoją pracę, jak chętnie zabierali się za kolejne zadania, wiedząc, że te oskarżenia są zupełnie nieuzasadnione. Po takim spotkaniu musiałam włożyć wiele energii, żeby ponownie zmotywować zespół, wcześniej jednak pooddychać kilkanaście razu licząc do stu, żeby ochłonąć, zarówno po spotkaniu jak i po nastałej po nim awanturze z przełożonym.

Wyjście z sytuacji

Najważniejsze jest uświadomić przełożonemu to, jak sytuacja wygląda z Twojej perspektywy. Jeśli rozmowa nie pomoże radykalnym wyjściem jest poszukanie pomocy u przełożonych wyżej (jest to oczywiście trudne, ale dla dobra projektów i zespołu konieczne) i nagłośnienie problemu tak, żeby ujrzał on światło dzienne. W mojej sytuacji ciśnienie urosło do takich rozmiarów a jednocześnie przełożony zdawał się nadal nie dostrzegać problemu (mimo jednoznacznych przesłanek od klienta, który z czasem poprosił o zmianę kierownika wdrożenia), że z racji braku wyjścia musiałam zacząć szukać pomocy u wyższego przełożonego, który ostatecznie został "sędzią", stawiając dwa zespołu na tym samym poziomie. Prace zaczęły płynąć swoim prawidłowym rytmem w atmosferze współpracy, aż do szczęśliwego odebrania projektu przez klienta. Jeśli u Ciebie dojdzie do takiej konieczności jak u mnie pamiętaj o bardzo ostrożnym rozegraniu tej sytuacji - koniec końców mamy do czynienia z naszym przełożonym. 

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ąć.