Zarządzanie zakresem projektu - moc komunikacji.

Jak poprawić komunikację z klientem?

Podczas pierwszego podejścia do tego artykułu zacząłem rozpisywać się i tworzyć listę X problemów w zarządzaniu projektami. O tym, jak wybranie metodyki Kanban wpływa na projekty, jakie pojawiają się wtedy problemy i tak dalej i tak dalej.

Wróciłem myślami do wszystkich projektów, którymi zarządzałem. Wszystkich historyjek o projektach, które kończyły w koszu lub - co gorsza - bankructwem właściciela. Z każdym kolejnym podpunktem dochodziłem do jednego i to tego samego wniosku. Nie ma czegoś takiego jak X problemów.

Wszystkie te „problemy” są zawsze spowodowane jednym. Złą komunikacją pomiędzy wykonawcą a klientem.

W tym artykule postaram się to udowodnić na przykładach i zacznę od jednego bardzo często przytaczanego „problemu” (który nie zawsze problemem jest i tutaj właśnie komunikacja decyduje, czy to będzie, problem czy nie). Zmian w zakresie projektowym w trakcie pracy.

Czym jest zakres projektowy?

Zakres projektowy jest w dużym uproszczeniu, jest to lista wszystkich funkcjonalności, celów i wartości, które mówią nam, kiedy projekt jest uznany za zakończony zgodnie z oczekiwaniami.

Zmiany w zakresie projektowym w trakcie pracy – moja opinia.

Często spotykamy się z poczuciem, w którym to zmiany projektowe są problemem – nie do końca się z tym zgadzam. Powód jest bardzo prosty. Nie zawsze jesteśmy w stanie zaplanować nasze życie na dwa lub trzy tygodnie w przód - a czasami nawet kilka dni w przód. Tak samo jest z projektami, z dnia na dzień może wydarzyć się bardzo dużo nieprzewidzianych sytuacji, które mogą mieć ogromny wpływ na realizacje zakresu projektowego.

Oczywiście, aby temu zapobiegać stosujemy tzw. „risk management” (zarządzanie ryzykiem). Bierzemy pod uwagę różne wypadkowe, które mogą się wydarzyć w trakcie projektu, takie jak: urlopy, konflikty w zespole projektowym, zmiany w otoczeniu biznesowym czy nawet właśnie zmiany zakresu projektowego.

Zmiany zakresu projektowego są trudne do uwzględnienia w budżecie (pomijając już flow pracy i jakość samej aplikacji), ze względu na ich ogromną „zależność”.

Moje ulubione stwierdzenie „to zależy” pasuje tutaj znakomicie. Weźmy za przykład zmianę, której implementacja zajmie 30 minut pracy, a całe zadanie obejmuje 15 godzin. W takim przypadku jest to bardzo mała zmiana, która będzie miała znikomy wpływ na budżet.

A co, jeśli sytuacja będzie wyglądać inaczej? Gdy wprowadzona zmiana obejmie 10 godzin pracy? Wtedy zwiększamy zakres pracy o 2/3 co znacznie wpłynie na budżet.

Budżety budżetami, ale co w przypadku, gdy dzięki np. User Researchu (jeśli chcesz dowiedzieć się o tym więcej, zapraszam Cię do naszego artykułu) otrzymamy nowe informacje i okaże się, że odbiór jednej z naszych głównych funkcjonalności jest całkiem inna(negatywna), niż zakładaliśmy? Wtedy wprowadzenie zmian może uratować naszą aplikację od wtopy/niezadowolenia klientów.

Czytając powyższe przykłady, możesz dojść do wniosku „Mała zmiana 30 minut jest w porządku, duża już trochę gorzej”. Tylko co to znaczy mała zmiana?

Przechodzimy właśnie do bardzo ważnej kwestii wartej omówienia - komunikacji pomiędzy firmą wykonawczą (na przykład Software Housem), a klientem.

Komunikacja – zapomniany element.

Komunikacja i odpowiednie formułowanie zdań są bardzo bliskie mojemu sercu i jest to coś, do czego przykładam ogromną uwagę – dlaczego?

Dużo problemów, które pojawiają się w projektach, naszym życiu prywatnym czy zawodowym, można było uniknąć, gdyby tylko informacje były zrozumiałe dla obu stron. Kłótnie z naszym partnerem, rodzicami, znajomymi – jeśli spojrzysz wstecz, ile razy pomyślisz „ta kłótnia była całkowicie bez sensu, nie to miałem na myśli, nie zrozumieliśmy się”?

Przełóżmy to na komunikację w projekcie.

Faza UX/UI już została skończona, jesteśmy teraz na fazie implementacji połowa pracy wykonana. Nagle otrzymujemy informację od klienta o „małej zmianie, którą chciałby wprowadzić”. Po czym okazuje się, że ta „mała” zmiana kosztować będzie 40 godzin pracy, klient może poczuć się urażony, oszukany, w końcu według niego to jest coś „małego”. Nie jest to wina klienta, nie ma on przecież obowiązku wiedzieć, jak wygląda praca np. developera.

Dobranie odpowiedniego sposobu komunikacji oraz zrozumiałego dla obu stron języka może zapobiec takim sytuacjom.

Podam kolejny przykład:

Załóżmy, że jesteśmy na spotkaniu zespołu projektowego i wraz z klientem wspólnymi siłami dochodzimy do wniosku, że nasza aplikacja „musi być przyjazna dla osób niewidomych”. W tym momencie każdy się zastanawia „co to znaczy przyjazna dla niewidomych?”. Każdy członek zespołu inaczej spojrzy na tą wytyczną. Designer pomyśli o odpowiednim ułożeniu elementów interfejsu, kontraście itd.. Developer wpadnie na pomysł spisania odpowiedniego kodu i zaimplementowania syntezatora głosowego. Oczywiście w trakcie planowania pracy zespół ustali rozwiązania i spotka się „pośrodku”. Tylko czy klient będzie zadowolony z tego, jak zrozumieliśmy ów wytyczną i naszych rozwiązań?

I tutaj przechodzimy do innego bardzo ważnego elementu – Product Owner po stronie klienta.

Product Owner – dlaczego warto?

Zacznijmy od tego, kim jest Product Owner (PO)?

„Product Owner to osoba, która reprezentuje użytkowników końcowych i właściciela produktu w projekcie IT. Jej zadaniem jest ustalanie priorytetów, tworzenie i zarządzanie listą zadań do wykonania oraz utrzymywanie stałego kontaktu między interesariuszami projektu. Wszystkie decyzje dotyczące funkcjonalności i priorytetów w projekcie IT są podejmowane przez Product Ownera.

Ładna definicja prawda?

Oczywiście wszystko to jest prawdą tylko właśnie, komunikacja zostaje ukazana jako ostatnia, trochę tak jakby była mniej ważna. Ukazana tylko jako „utrzymywanie stałego kontaktu”. Co z tego, że kontakt pomiędzy interesariuszami projektu będzie stały, jeśli będzie on niezrozumiały? Dlatego właśnie kładziemy tak duży nacisk na komunikację i rolę Product Ownera w projekcie.

Product owner, który będzie dbał o to, żeby klient i wykonawca mieli bardzo zbliżone poglądy na konkretną sprawę, potrafi całkowicie odmienić (na lepsze oczywiście) proces developmentu projektu. Najważniejsze „zasady” do ustalenia na samym starcie współpracy:

• Sposób komunikacji – mailowo czy telefonicznie? Spotkania online za pomocą google meets czy spotkania stacjonarne, a może tak i tak?

• Częstotliwość komunikacji – w zależności od podejścia Agile lub Waterfall komunikować możemy się codziennie, raz w tygodniu, raz w miesiącu.

Nie ma tutaj uniwersalnej odpowiedzi i podejmując decyzję, trzeba wziąć pod uwagę wiele czynników takich jak specyfikacja projektu, czas zespołu, Product Ownera, Project Menagera itd.

• Odpowiedni język - umiejętne dobranie języka zrozumiałego dla obu stron. W przypadku klientów z małą wiedzą techniczną, używanie specjalistycznych sformułowań nie będzie dobrym rozwiązaniem i może prowadzić do niezrozumienia wielu kominikatów.

• Otwartość na pytania – zdarzają się sytuacje, że nie do końca zrozumiemy, o co chodzi naszemu rozmówcy. Może pytanie było tak oczywiste, że głupio nam zapytać – błąd. Upewnienie się, czy dobrze zrozumieliśmy komunikat drugiej osoby, zapobiegnie potencjalnym sprzeczkom i zmianom projektowym.

Chcesz zostać Product Ownerem swojego projektu? Skontaktuj się z nami i omówmy Twoją sytuację.
Oświadczam, że wysłanie wiadomości przez formularz kontaktowy jest działaniem potwierdzającym zgodę na przetwarzanie moich danych osobowych na zasadach określonych w Polityce Prywatności
WYŚLIJ

Jak poprawić komunikację z klientem – moja rada.

Częsta komunikacja i wykorzystanie „Daily”, czyli spotkań raz dziennie jest czymś, co ma według mnie wiele zalet, ale zdaję sobie sprawę, że nie zawsze jest to możliwe i dużo zależy od tego, z kim rozmawiamy. Jeśli po stronie klienta brakuje PO i trzeba taką osobę powołać, mogą pojawić się problemy, w postaci braku czasu, dodatkowych kosztów itd.. Dlatego do jak najlepszego wykorzystania czasu, który bardzo często może być ograniczony – nie ma możliwości przeprowadzenia daily i komunikujemy się raz lub kilka razy w tygodniu polecam zastosować pisemne podsumowania spotkań.

Podsumowania spotkań to np. mail z opisem każdego ze spotkań Project Menagera z klientem/PO. W takim podsumowaniu spisujemy to, o czym rozmawialiśmy, do jakich wniosków doszliśmy, plany na przyszłość itd..

Po stronie PO/Klienta jest natomiast potwierdzenie otrzymania takich podsumowań. Dzięki takim podsumowaniom dużo ciężej o nieścisłości w projekcie w przyszłości. Wszystko zostaje zapisane i w razie pomyłek można się do tego odwołać.

Komunikacja telefoniczna/spotkania online – osobiście preferuję komunikację telefoniczną i rozmowę z drugim człowiekiem, ponad formę pisemną. W dużo krótszym czasie jesteśmy w stanie przekazać dużo więcej informacji i upewnić się, że druga osoba zrozumiała to, co do niej mówimy.

Dodatkową wartością rozmów poprzez wykorzystanie Google Meets jest możliwość nagrania ów spotkań (oczywiście za zgodą obu stron). Przede wszystkim zabezpiecza to obie strony na przyszłość oraz daje możliwość powrotu do takich spotkań po dłuższym czasie.

Korzystanie z rozmów telefonicznych nie wyklucza przecież użycia formy pisemnej – suplementujmy ją właśnie podsumowaniami itd..

Podsumowanie

„Moc komunikacji” to coś bardzo niedoceniane przez wiele osób, a niesie za sobą wiele korzyści. Główną zaletą dla zespołu pracującego nad projektem to przede wszystkim – spokój. Dzięki dobrze dobranego sposobu i częstotliwości komunikacji; cała współpraca będzie dużo mniej czasochłonna i mniej stresowa. Poprzez podsumowania spotkań, skuteczniej korzystamy z czasu naszego i klienta i ułatwiamy komunikację w przyszłości – takie podsumowania najlepiej stosować w formie pisemnej na przykład mail. Jeśli jest jedna rzecz, którą chciałbym, żebyś zapamiętał/a z tego artykułu. To to, że potencjalne „problemy” takie jak zmiany zakresu funkcjonalności projektowej w trakcie pracy.

Będą problemem tylko wtedy, gdy komunikacja pomiędzy klientem a wykonawcą zostanie zaniedbana.