Zarządzanie projektem IT – komunikacja w zespole

O tym jak ważna jest komunikacja w pracy – nie musimy nikomu mówić. Po prostu jest ważna i tego należy się trzymać. Ten fakt jest oczywisty, ale już mniej oczywista wydaje się „jakość” owej komunikacji, a to od niej w dłuższej perspektywie zależą sukcesy firmy oraz jej efektywność. Komunikacja jest szczególnie istotna w przypadku projektów inżynierskich takich jak np. IT. W grę wchodzą często bardzo duże pieniądze inwestora przeznaczone na dowiezienie projektu w określonym czasie i (jeśli jest to model Fixed Time&Cost) budżecie. Od tego jak projekt będzie prowadzony, na kiedy oddany, z jaką ilością błędów oraz jaką jakością kodu – zależy często forma i jakość komunikacji pomiędzy interesariuszami projektu. W kilku zdaniach postaram się przybliżyć najbardziej „czułe punkty” komunikacji w zespole projektowym tworzącym oprogramowanie dla klienta.

1. Po pierwsze – narzędzia

Istotnym elementem całej komunikacji jest odpowiedni dobór narzędzi projektowych takich jak narzędzia do komunikacji wewnętrznej (np. Slack.com), narzędzia do przechowywania informacji o projekcie, plików graficznych, dokumentacji itd. (np. Basecamp.com), repozytorium z kodem (np. Bitbucket.org) czy wreszcie sam system do zarządzania projektami z tablicą Kanban (np. Jira). Odpowiednie narzędzia to jednak za mało. Muszą być też poprawnie uzupełnione, tak aby żadna osoba zaangażowana w projekt nie musiała męczyć PM’a o tak trywialne sprawy jak: „gdzie mamy pocięte png pod andka?” lub „daj mi dostęp do repo, uprawnienia write bo nie mogę zrobić commita”. Wszystko musi być uporządkowane – dokumentacja, elementy graficzne i inne, muszą znajdować się w odpowiednio opisanych folderach w konkretnym systemie. Repozytorium z kodem musi być stale aktualizowane, na bieżąco powinny być tworzone jego kopie zapasowe, a sama tablica w Jirze musi być aktualna oraz na bieżąco weryfikowana przez Project Managera. Narzędzie do komunikacji wewnętrznej ma służyć do usprawnienia pewnych procesów np. pomysłów na szybsze oprogramowanie danego algorytmu lub w celu zwiększenia postępów w projekcie – nie jest to bynajmniej skupisko internetowych memów.

2. Block’i

Kolejnym elementem wzorowej komunikacji jest eliminacja tzw. „wąskich gardeł” czyli sytuacji, w których nie możemy iść dalej z projektem gdyż coś lub ktoś nas blokuje. Typowym wąskim gardłem jest często sam klient, który opóźnia zespół projektowy np. z powodu niedostarczania konkretnych elementów graficznych do aplikacji (w przypadku gdy design jest w gestii klienta). Tutaj sam project manager musi wykazywać się nie tylko uprzejmością (bo przecież klient nam płaci), ale też stanowczością i zdecydowaniem. Bardzo częstym zjawiskiem są taski oznaczone w systemie do zarządzania projektami, etykietą „Blocked by API”, które są niczym innym jak konkretnymi endpointami w API i często to klient powinien je dostarczyć w określonym czasie. Przecież oprogramowanie trzeba też testować, nie tylko manualnie…

3. Testy i współpraca z działem QA

Odnośnie samych testów i współpracy z testerami można by pisać godzinami. To tutaj dochodzi często do największych opóźnień i najczęściej nie z winy programistów. Brak dobrej komunikacji swoich potrzeb przez testera skutkuje niezrozumieniem tych potrzeb przez programistę co może skutkować (w najlepszym przypadku) niepotrzebnym „dopytywaniem się” co autor miał na myśli lub (co gorsza) niewłaściwą implementacją rozwiązania. Jedynym sposobem na uniknięcie problemów na tym etapie jest skrupulatne i bardzo dokładne opisanie błędów w działaniu danej aplikacji oraz stworzenie odpowiednich ticket’ów w systemie, tak aby programista bez problemu i zadawania zbędnych pytań mógł przystąpić do naprawy bug’ów. Każdy błąd musi mieć swój szczegółowy opis zawierający markę, model telefonu, na którym dokonywano testów manualnych, system i jego wersję oraz inne znaczące elementy ułatwiające programiście diagnozę i naprawę błędu w jak najkrótszym czasie.

4. Świadomość klienta

Kolejnym ważnym elementem jest uświadomienie klienta jak ważny (jeśli mówimy o pracy projektowej na zlecenie klienta) jest on sam w całym procesie tworzenia oprogramowania. Projekty IT są często bardzo skomplikowane oraz ryzykowne – w grę wchodzą zazwyczaj duże budżety, a więc każdy powinien stanąć na wysokości zadania, klient także – mimo, że często jest inwestorem i wykłada pieniądze na stół. Tutaj wysiłek leży po stronie dobrego i stanowczego PM’a, który poprzez skuteczne naciski, uzyska niezbędne informacje od klienta w szybkim czasie, zapewniając tym samym ciągłość pracy swoim inżynierom. Ponadto, musimy zdawać sobie sprawę, że klient nie musi znać się na programowaniu lub zarządzaniu projektem – w tym przypadku to celem biznesu jest odpowiednie wytłumaczenie, że w takiej sytuacji pieczę nad całym projektem klient powinien oddać w ręce doświadczonego zespołu, który poprowadzi projekt (wraz z jego odpowiednim budżetowaniem).

5. Daily stand’upy, weekly demo calls, ustalanie harmonogramu sprint’ów

Zarządzając projektem w oparciu o metodykę Agile/SCRUM i chcąc wyeliminować tym samym sytuacje opóźniające nasz projekt musimy zwrócić szczególną uwagę na strukturę pracy, jej wewnętrzną organizację. I nie mam tu na myśli bynajmniej rozproszenia zespołu czyli pracy zdalnej – ta jest jak najbardziej ok jeśli inne elementy są odpowiednio ustrukturyzowane. Jednym z takich elementów są daily standupy czyli spotkania zespołu organizowane najczęściej rano, po „zalogowaniu” się wszystkich interesariuszy projektu. To moment, w którym podsumowujemy co zostało zrobione wczoraj lub przed weekendem, a jakie zadania czekają na nas dziś. Notatkę ze spotkania, PM powinien umieścić w odpowiednim systemie np. w Basecamp co pozwoli na śledzenie postępów prac przez klienta oraz nada samym spotkaniom pewnego porządku. Weekly demo calls to spotkania, organizowane zazwyczaj w formie wideorozmów z klientem, który na bieżąco, z tygodnia na tydzień, śledzi postęp prac zespołu. Ważnym elementem są także spotkania dot. ustalania harmonogramu sprintów – etapów rozwoju projektów, jego kolejnych kamieni milowych. Do przygotowania takiego harmonogramu potrzebna jest wiedza analityczna oraz doskonała znajomość założeń projektowych.

Powyższe 5 punktów to tylko zalążek tego co spotyka nas w projekcie i wpływa na komunikację, jednak bazując na swoim doświadczeniu przytoczyłem te (w mojej opinii) najważniejsze. Pewnym jest jednak, że wiele problemów projektowych, nie wyrabiania się przez firmy w określonym budżecie (np. niedoskonała komunikacja działu QA z programistami) lub deadline (np. konflikt z klientem, zmiana założeń projektu w trakcie trwania danego sprintu, brak uświadomienia klienta o potencjalnych zagrożeniach) to często powód słabej komunikacji.

Na koniec ostatnia myśl, która przyszła mi do głowy – komunikować się dobrze, nie znaczy często mówić/pisać. Jeśli nikt nie zadaje pytań to znaczy, że każdy wie co ma robić. I to jest chyba najefektywniejsza komunikacja.