Jak zapewnić dobrą komunikację w zespole projektowym?

Wszyscy wiedzą, że odpowiednia komunikacja w zespole projektowym jest bardzo ważna. Według statystyk „zła komunikacja” jest wymieniana jako jedna z głównych przyczyn opóźnień projektów. Doszło do tego, że pojęcie „dobra komunikacja” stała się frazesem i dla wielu wymówką w przypadku niepowodzeń z projektami. Nie jest to z pewnością trudność obiektywna, na którą nie mamy wpływu, wręcz przeciwnie – to od nas, kierowników projektów zależy jaki schemat komunikacji narzucimy.

Na początku należy zrozumieć, że komunikacja nie występuje tylko poprzez drogę werbalną. Wszystkie stany, procesy, a przede wszystkim opisy zadań powinny być jasne i zrozumiałe dla całego zespołu. Jeśli tak nie jest to mamy do czynienia z przykładem złej komunikacji. Podejrzewam, że każdy z nas był świadkiem sytuacji, w której ktoś nie wiedział, że miał wykonać pewne zadanie lub zrealizował je w niewłaściwy sposób. Przyczyną takich zdarzeń jest niezrozumienie.

Narzucenie odpowiedniego 'flow komunikacyjnego” leży w obowiązkach PM. Każde środowisko projektowe wymaga innych narzędzi. Dobierając je, należy pamiętać żeby uwzględnić preferencje zespołu ponieważ komunikacja oprócz tego, że musi być skuteczna, powinna być też wygodna. Jeśli twój zespół nie jest przekonany do używania konkretnego komunikatora (narzędzie komunikacji), a zostanie on im narzucony to prawdopodobnie wpłynie to negatywnie na skuteczność wymiany informacji. Tego chcemy uniknąć. Niezwykle ważne jest by zespół uznał narzędzia za wygodne dla siebie, to zmaksymalizuje skuteczność przepływu informacji. Warto rozmawiać z zespołem na temat sposobu komunikacji, zbierać feedback co jest według nich pomocne, a co utrudnia swobodną wymianę informacji. Błędem byłoby zmienianie sposobu komunikacji co kilka dni – członkowie nie zdążą się go nauczyć. Pamiętajmy o tym, żeby nie zmieniać metod komunikacji zbyt często (np po usłyszeniu fali krytyki) – dając zbyt krótki czas na sprawdzenie, nie jesteśmy w stanie poznać dogłębnie wad i zalet rozwiązania. Bardzo często zdarza się, że ludzie są negatywnie nastawieni do nowych rzeczy ponieważ potrzeba wysiłku by się ich nauczyć. Nie oznacza to jednak, że wprowadzone metody są nieskuteczne mimo krytyki.

Kiedy możemy mówić o „dobrej komunikacji”?

Według mnie dobra i skuteczna komunikacja jest wtedy, gdy nie trzeba ze sobą rozmawiać. Wszystko jest czytelne po pierwszym rzucie oka w dokumenty/wykresy/tablice. Poniższy mem idealnie oddaje to, co mam na myśli.

Każdy stan zadania, każdy krok procesu powinien być zaprezentowany w klarowny sposób dla członków zespołu – narzędzi, których możemy do tego użyć jest wiele. Doskonale sprawdza się tablica Kanban, która w czytelny sposób prezentuje stany poszczególnych zadań. Pamiętaj, że twoja tablica nie musi składać się z 3 podstawowych stanów – TO DO, In progress i Done. Kanban powinien być dostosowany do specyfiki twojego projektu – możesz rozszerzyć go o dowolną liczbę kolumn. Oczywiście wszystko z umiarem 😉 W perspektywie czasu zauważysz co wstrzymuje taski, co z kolei umożliwi ci wyodrębnienie kolumny na blokujący stan. Każdy projekt jest inny, najlepiej sprawdzi się metoda prób i błędów.

Powyżej znajduje się tablica Kanban składająca się z 5 kolumn.

• Blocked by API – zadania, których nie można zrealizować ponieważ nie mają stworzonych endpointów w API
• To do – zadania, których nic nie blokuje – mogą być zrealizowane
• In progress – zadania w toku (WIP)
• UAT – zadania, które są wrzucone na serwer i oddane do testów. Jeśli zostaną zaakceptowane trafiają do kolumny Done, w przeciwnym wypadku lądują w To Do z komentarzem co jest do poprawy
• Done – zamknięte zadanai

W tym projekcie „wąskim gardłem” był klient, który musiał dostarczyć endpointy w swoim API oraz ostatecznie zatwierdzić zadania. Taski były blokowane w dwóch miejscach w procesie realizacji. Pierwszym miejscem było oczekiwanie na endpoint, przed jego dostarczeniem nie mogliśmy zacząć realizować zadania. Drugim miejscem była ostateczna akceptacja zadań w UAT. Te stany zostały wyodrębnione na tablicy w dodatkowych kolumnach. Rzut oka na tablicę informuje nas o tym:

• jak długo możemy pracować bez dostarczenia od klienta endpointów (TO DO)
• jak bardzo brak dostarczenia endpointów może wpłynąć na opóźnienie (Blocked by API)
• jaka jest aktualnie praca w toku – WIP (work in progress)
• ile zadań „wisi” na kliencie, które musi testować (UAT)
• ile zadań mamy wykonanych (Done). Wpis o raportowaniu stanu projektu, czyli dlaczego nie powinieneś sugerować się tą kolumną.

Tyle zmiennych, które widać „gołym okiem”. Wszystkie stany są czytelne dla całego zespołu. Klient widzi jak bardzo „zalega” z testami i endpointami. Nie musimy go informować o tym, że „task XYZ – czeka na UAT” ponieważ to wynika z tablicy. Wszystko jest czarno na białym – cała historia zmian jest w jednym miejscu – tasku.

Niezwykle ważne jest kontrolowanie WIP, zawsze naciskam na to by w tej kolumnie znajdowało się jedno zadanie dla jednego developera. Jest to ważne głównie z dwóch powodów. Pierwszy z nich to #zlawiel, czyli zła wielozadaniowość, która wpływa negatywnie na wydajność. Zdarza się to gdy łapiemy „wiele srok za ogon”. Drugim powodem, jest zbieranie feedbacku na temat poprawnej konstrukcji zadań. Jeśli zauważymy, że zadania nie są „zamykalne” – czyli żeby zamknąć zadanie A, musimy zrealizować 30% zadania B i 10% zadania C. Jest to dla nas znak, że mają błędną formę i należy je przebudować. O tym jak powinny wyglądać zadania w projektach, pisałem w poście o najczęstszych błędach podczas układania zadań. Warto wspomnieć też o oczywistej rzeczy, czyli nomenklaturze. Używajmy spójnej terminologii do określenia aktorów, funkcjonalności i podmiotów w projekcie. Jeśli terminy są zawiłe dobrze sprawdzi się stworzenie słownika projektowego, który wskazuje różnice między określeniami. Taki dokument powinien być dostępny dla wszystkich w homepage’u projektu.

Jedną z zalet Scrum jest narzucenie komunikacji werbalnej w: daily scrum, retrospekcji, planowaniu i podsumowaniu sprintu. Zespół rozmawia ze sobą podczas spotkań, a to z pewnością zwiększa komunikacje i minimalizuje szansę na niezrozumienia. Wadą obiektywną takiego rozwiązania jest to, że takie spotkania zajmują cenny czas – możemy osiągnąć to samo poprzez odpowiednie narzędzia. Wadą nieobiektywną (według ludzi, którzy niewłaściwie organizują spotkania scrumowe) jest to, że są mało skuteczne. Oczywiście to błędne założenie, które wynika ze złej dobranej metodologii lub niewłaściwego jej zastosowania. To tak jakbyśmy założyli, że rower jest nieskutecznym środkiem poruszania się, ponieważ nie możemy się nim przemieszczać po jeziorach. To znaczy tyle, że dobraliśmy złą metodę rozwiązania naszego problemu, natomiast nie znaczy to, że rower jest nieskuteczny jako środek transportu. Wszystko zależy od tego czy:

• właściwie dobraliśmy metodę rozwiązania
• właściwie zastosowaliśmy tą metodę.

Bywa, że Scrum nie sprawdzi się w naszym projekcie lub nie będzie optymalną metodyką. Może też zdarzyć się, że będziemy niewłaściwie prowadzić spotkania. W obu przypadkach nie uzyskamy pożądanego efektu – dobrej komunikacji i realizacji projektu na czas. O tym jak skutecznie przeprowadzić spotkanie to temat na osobny wpis.

Poniżej krótki sketch o tym, jak (niestety) często wyglądają konferencję online, które utrudniają komunikacje.

Podsumowanie

Możemy stwierdzić, że nie istnieje panaceum na dobrą komunikację w zespole. Musimy ją wypracować – najczęściej metodą prób i błędów, ponieważ w każdym środowisku projektowym, będą sprawdzały się inne metody komunikacji. Warto porozmawiać z zespołem nad tym, czy narzucone metody są dla nich wygodne. Zastanów się nad tym, czy dobrane przez ciebie metody prowadzenia projektu są odpowiednie dla konkretnego przypadku. Warto też odpowiedzieć sobie na pytanie ile czasu zajmuje nam zebranie informacji by poznać zaawansowanie projektu – jest to kilka sekund z tablicy kanban? Czy kilkanaście minut ponieważ musimy odgrzebywać email lub dzwonić do członków zespołu?

Napisz w komentarzu jak usprawniłeś komunikację w swoim zespole projektowym. Natomiast jeśli jesteś developerem, daj znać, co najbardziej utrudnia komunikację między członkami zespołu.