Efektywna współpraca i wymiana informacji między zespołem wdrożeniowym a project managerem jest jednym z ważniejszych czynników wpływających na sukces projektu.

Pomijając zalety i wady wynikające ze stosowania różnego rodzaju metodyk prowadzenia projektów podstawowym środkiem osiągania wyznaczonych celów jest dobra komunikacja zespołu, jego zgranie oraz wewnętrzne zaufanie.

Chyba najważniejszą zasadą współpracy zespołu ze sobą oraz zespołu z klientem zewnętrznym jest szacunek. Szacunek dla pracy każdego członka zespołu (nie można na przykład wartościować większej roli projektowania ponad programowaniem i na odwrót) oraz szacunek do klienta/biznesu i na odwrót.

Czasami project managerowie nie spełniają swojej roli  – nie wystarczająco separując zespół od problemów organizacyjnych, niejasnych ustaleń i innych demotywujących czynników. Dzielenie się swoimi żalami z prowadzi czasami wprost do utraty autorytetu oraz sprzyja defetystycznemu nastawieniu pracowników. Osoby nie mające wpływu na organizację projektu – słysząc tylko o wyrwanych z kontekstu problemach wizualizują sobie swoją pracę jako bezcelową i a projekt – być może jako skazany na porażkę. Spada morale. Może też dochodzić do utraty szacunku zespołu do działu biznesowego czy też klienta zlecającego projekt technologiczny. Wtedy bardzo trudno mówić o nastawieniu na jakość i zadowolenie klienta końcowego.

Kluczowe jest aby cały zespół wiedział jaki jest cel projektu i czuł solidarną odpowiedzialność za jego sukces. Project Manager powinien dążyć do tego aby był traktowany jako jego równorzędny członek i ktoś kto pomaga w trudnościach a nie stojący na zewnątrz egzekutor terminów. Posługiwanie się sformułowaniami „to Twoja wina”, „nie zrobiliście mi tego”, „nic nie działa” jest niedopuszczalne w pracy z zespołem i świadczy o braku szacunku do jego pracy.

Trudno odczuć czyjś szacunek do swojej pracy kiedy nikt nie pyta nas o zdanie. Bardzo ważne jest aby wszystkie decyzje w projekcie były konsultowane wpierw z osobami które będą odpowiedzialne za ich realizację. Wyznaczanie terminów, realizowalności danych zadań nigdy nie powinno odbywać się bez estymacji osób zaangażowanych. Kierownicy często mają pokusę wyznaczenia terminu lub czasochłonności w oparciu tylko i wyłącznie o swoje doświadczenie, często takie szacunki są bardzo dobre i bliskie prawdy. Niestety jeśli zawiodą, a nie były poparte konsultacjami – będzie nam bardzo trudno wyciągnąć konsekwencje lub uzyskać większe zaangażowanie w celu naprawy sytuacji. Ludzie czują się odpowiedzialni za swoje deklaracje, jeśli nie – być może nie są odpowiednimi pracownikami do projektu który realizujemy. Nie można traktować innych z góry i nie szanować ich zdania ponieważ prędzej czy później skończy się to takim samym brakiem szacunku skierowanym w przeciwną stronę.

Warto w tym miejscu rozwinąć temat wspominanej odpowiedzialności i wyciągania konsekwencji za porażki  i błędy w projekcie. Nie powinniśmy zapominać o tym, że nie ma ludzi bezbłędnych, a wdrożenia zwłaszcza IT ze względu na poziom skomplikowania są skazane na różnego rodzaju obsunięcia, niedociągnięcia i problemy z którymi będziemy musieli sobie radzić. Radzic – co kluczowe – wspólnie. Wyciąganie zbyt daleko idących konsekwencji względem członków zespołu prowadzi do zmniejszania poziomu zaufania i podejmowania kroków zmierzających do kamuflowania niepowodzeń w przyszłości. To może dać nam złudny obraz projektu i przynieść tragiczne konsekwencje. Jeśli błędy lub problemy nie wynikają stricte ze złej woli lub daleko idących zaniedbań lepiej ograniczyć się do szczerej rozmowy, pokazać jakie problemy dla nas jako kierownika i dla projektu w ogóle wygenerowało dane zdarzenie i liczyć na to, że takie postawienie sprawy wystarczy.

Dobra atmosfera w zespole jest bardzo ważna – oparte na szacunku relacje będą procentowały zaufaniem, podawaniem szczerych danych o postępach prac i możliwości reakcji na problemy które się pojawią w porę. Nie sposób przecenić takie nastawienie do wspólnego przedsięwzięcia zwłaszcza jeśli pracujemy nad zadaniami obarczonymi dużym ryzykiem czasowym lub o dużym znaczeniu dla przedsiębiorstwa.

Zgrany zespół powinien się efektywnie i często komunikować. Praktyka pokazuje, że jedynie cotygodniowe raportowanie i ustalanie zadań na kolejny etap to może być za mało. Oczywiście jest minimum którego nie powinno się zaniedbywać.

Większość metodyk zwinnych zaleca działanie w jedno lub dwu tygodniowych iteracjach podsumowywanych takimi właśnie spotkaniami. Uzyskiwane podczas nich informacje pozwalają kierownikowi projektu ocenić sytuację i wyestymować czas realizacji następnych kroków, ale często nie dają oceny jakości wytwarzanego dzieła, nastrojów zespołu oraz informacji o problemach które się pojawiają lub mogą się pojawić. Dodatkowo rzadkie spotkania nie motywują członków zespołu do efektywnej wymiany wiedzy między sobą, co przy dużych zespołach może mieć negatywne efekty. Warto pomyśleć nawet o codziennych spotkaniach – nie dłuższych niż 15 minut, gdzie omawiane są zrealizowane i planowane zadania. Takie podejście wymaga co prawda większego zaangażowania osób zarządzających ale zdaje się, że pełna kontrola sytuacji jaką w ten sposób nabywają rekompensuje poświęcony czas.

Zespół powinien używać narzędzi do gromadzenia wiedzy oraz kontroli czasu pracy. System ticketowy – np. Redmine (http://redmine.org) lub Basecamp (http://basecamp.com/) sprawdzą się świetnie. Dzięki takiemu narzędziu możemy sprawnie przydzielać zadania konkretnym członkom zespołu, wymieniać informacje co do nich w komentarzach (przez co się nie zgubią) oraz umieszczać pliki, dane testowe, dostępy w postaci stron Wiki lub plików do pobrania. Przez takie podejście nowe osoby dochodzące do zespołu lub zastępujące jego członków podczas urlopów nie tylko mają dostęp do aktualnej informacji o postępach prac i zadaniach ale też do wszystkich danych potrzebnych im do wdrożenia się w prace. Często system ticketowy jest współdzielony z klientem końcowym – zwłaszcza podczas testów i odbioru (klienci zgłaszają w nim swoje uwagi). To chyba najbardziej efektywne i przejrzyste rozwiązanie. Kierownik projektu powinien dbać o to aby wszyscy używali systemu zgłoszeniowego i aktualizowali dane o zadaniach (np. postęp realizacji).

Systemy zgłoszeniowe często posiadają moduł do śledzenia spędzonego nad zadaniami czasu pracy. Niestety funkcje te zazwyczaj bywają dość niewygodne do codziennego używania. Warto rozważyć skorzystanie z narzędzi takich jak Toggl (http://toggl.com) które pozwalają na zasadzie stopera (włączam gdy zaczynam, wyłączam gdy kończę dane zadanie) rejestrowanie czasu poświęconego konkretnym projektom. Trudno przecenić znaczenie narzędzi tego typu przy podsumowywaniu i rozliczaniu projektów a także w ocenie ich rentowności. Zazwyczaj członkowie zespołu odczuwają pewien opór na początku związany z obawą o weryfikowanie na podstawie tych narzędzi czasu jaki pracują (w ogóle, przypomina to karty podbijane przy wchodzeniu do zakładu pracy). Powinniśmy przekonać naszych współpracowników, że nikt z tych zapisów nie będzie rozliczany dyscyplinarnie oraz przedstawić czemu taki monitoring służy. Prawda jest też taka, że zdarza się, że wprowadzenie takich narzędzi faktycznie zwiększa wydajność zespołu i czas jaki jest on w stanie poświęcić na efektywną pracę.

Project manager powinien bardzo dobrze znać projekt którym zarządza. Nie chodzi o znajomość harmonogramów i formalności – choć to też bardzo ważne. Najistotniejsze jest aby project manager miał jasność jak produkt ma wyglądać finalnie i był w stanie  w każdym momencie ocenić jakość funkcji prezentowanych przez programistów a także wskazać kierunek ich rozwoju. Jasne, w projektach są projektanci którzy powinni zajmować się takimi czynnościami. Project manager oczywiście powinien korzystać z ich wiedzy i konsultacji. Nic jednak tak nie psuje autorytetu osoby zarządzającej jak odczucie przez zespół, że w zasadzie nie wie ona nad czym ten zespół pracuje. Praktyka dowodzi, że bardzo dobrze jest gdy project manager współpracuje przy tworzeniu scenariuszy testowych projektu czy też sam bierze co jakiś czas udział w testach. Poznaje on wtedy system, może poczuć na czym stoimy i co jeszcze zostało do zrobienia

Dobra współpraca i jej złote zasady zawsze jest wynikiem doświadczenia i różnie wygląda przy różnych projektach.  Dobre zarządzanie ludźmi – na którym opiera się ta sztuka – nie jest umiejętnością którą można nabyć z lektury książek a nawet ze szkoleń. Konsekwencja, otwartość, szacunek, motywacja, uporządkowanie – to są cechy dobrego PMa które będą szanowane przez zespół.