Ciężko się dogadać, czyli trzy historie o skomplikowanych ludziach

17 czerwca
Ellina Azadova, QA Lead
Ciężko się dogadać, czyli trzy historie o skomplikowanych ludziach
Ten artykuł będzie wyłącznie o pracy z innymi ludźmi. Wszyscy jesteśmy różni. Każdy z nas ma swoje poczucie humory, temperament, oczekiwania, cele i charakter. To ogromny sukces, a raczej kwestia szczęścia, żeby zebrać idealny zespół do projektu. Zazwyczaj coś pójdzie nie tak. W tym artykule podzielę się kilkoma historiami ze swojej praktyki. Wszystkie wydarzyły się naprawdę i czerpie je z własnego doświadczenia. Od 12 lat pracuję w branży IT, z czego ponad osiem w Quality Assurance. Koordynuje QA talk community w ukraińskim Chersoniu, a także prowadzę lekcje w QA School – w Chersoniu oraz w Sofii.

Historia 1: Pełna kontrola

Trafiłam do zespołu jako QA Lead. To był zupełnie standardowy zespół. Składał się z BA, QA oraz zespołu programistów z dev leaderem na czele. Wszystko byłoby idealnie, gdyby nie fakt, że każda decyzja mogła zapaść dopiero po akceptacji przez dev leadera. Nazwijmy go Piotrek. Piotrek pełnił dodatkowo funkcję project managera, bezpośrednio komunikując się z klientem.

Dodatkowym aspektem, który utrudniał nam współpracę, było miejsce pracy Piotra. Pracował on z USA, a więc znajdowaliśmy się w różnych strefach czasowym. Czas, kiedy w ciągu dnia wszyscy byliśmy przy komputerach, był więc bardzo ograniczony. Zdarzało się, że zespół musiał czekać na podjęcie prostej decyzji do następnego dnia. Musieliśmy za każdym razem przemyśleć, kiedy i w jakiej kolejności zadawać Piotrowi pytania.

Warto dodać, że Piotr wyróżniał się wielkim doświadczeniem technicznym i był kluczową postacią w tym projekcie. Ja byłam odpowiedzialna za testowanie, co sprawiało, że często z nim współpracowałam. Na szczęście, miałam bezpośredni kontakt z klientem, dzięki czemu rozumiałam zadanie i znałam jego oczekiwania.

Historia zaczyna się, kiedy Piotr zdecydował się wziąć miesiąc urlopu, tuż po zakończeniu okresu świątecznego. Nie muszę nikomu tłumaczyć, że jego decyzja wprawiła wszystkich w konsternację. Nikt nit wiedział, jak postępować bez osoby, która do tej pory chciała mieć kontrolę nad każdą decyzją. Każdy zdawał sobie sprawę z ryzyka dla całego projektu.

Z drugiej strony, każdy czuł, że być może to najlepsza okazja, żeby rozwiązać dotychczasową więź, która sprawiała, że zespół nie był samodzielny. Ostatecznie, nie udało się skłonić Piotra do skrócenia swojego urlopu i zostaliśmy sami.

Nieoczekiwanie, nic się nie zepsuło. Posiadałam znaczącą wiedzę o systemie. Poznałam ją, będąc wcześniej na wyjeździe służbowym i komunikując się z klientem bezpośrednio. Dodatkowo, kontakt z nim miał też BA. W zespole programistów pojawił się nowy lider, który brał na siebie odpowiedzialność. W efekcie, mogliśmy kontynuować pracę nad produktem. Nie było łatwo, ale daliśmy radę. Po upływie miesiąca stwierdziliśmy, że możemy pracować samodzielnie.

W dniu, kiedy Piotr miał wrócić z urlopu, dostaliśmy wiadomość, że nasz lider już do nas nie wróci. Z jakich przyczyn, dlaczego tak nagle oraz kto był inicjatorem tej decyzji, pozostaje nam się tylko domyślać.

Tymczasem zespół pracował bardzo dobrze. Uczestnicy byli wobec siebie pomocni, zwłaszcza, gdy ktoś zauważył u innej osoby braki wiedzy lub problem z podjęciem decyzji. Ta przygoda sprawiła, że pozostaliśmy w bliskich relacjach nawet po zakończeniu projektu.

Doświadczenie, które zdobyliśmy:

  • Należy unikać wąskich gardeł.
  • Wiedza powinna krążyć w ramach zespołu i nikt nie powinien być jej jedynym właścicielem.
  • Bliska współpraca łączy ludzi, a to sprawia, że praca staje się przyjemna.
  • Jak najwięcej osób z zespołu powinno komunikować się z klientem. Pośrednicy wprowadzają zamieszanie.

Historia 2: Negatywne nastawienie

Sytuacja, którą teraz opiszę, wydarzyła się w innym projekcie. Pracowaliśmy w ramach kilku małych zespołów. Każdy zajmował się osobnym komponentem tego samego systemu. Ja byłam QA leaderem jednego z zespołów. Naszym celem było stworzenie komponentów oraz złożenie ich w działającą całość. Niestety, część z nas miała problem, żeby uświadomić sobie, jaki był cel zadania. Widzieli oni tylko swój komponent, a nie myśleli o całym systemie.

W pewnym momencie, jeden z komponentów był mniej ważny dla współpracy. W związku z tym, manager zespołu, który zajmował się pracą nad tą częścią systemu, nazwijmy go Juri, stale był w złym humorze. Każda konwersacja z Jurim sprowadzała się do negatywnej oceny innych zespołów lub konkretnych osób, co przeszkadzało współpracy i sprawiało, że wszyscy mieli dość Juria. Kiedy zaś Jurii potrzebował pomocy, nigdy jej nie otrzymywał, nawet jeśli pozostali członkowie zespołu mogli mu ją dać. To tylko potęgowało frustrację.

Przełom nadszedł, kiedy zorganizowano wyjazd teambuldingowy dla całego zespołu. Dodam, że każdy z nas pracował z innego miejsca, przede wszystkim z różnych miast na Ukrainie, i nie tylko. Po osobistym zapoznaniu się, znacząco zmieniliśmy zdanie o każdym z nas. Swoje zdanie zmienił też Juri. Zrozumiał, że inne zespoły pracują w ramach tego samego zadania i tak naprawdę nikt nie kładzie mu kłód pod nogi. W czasie spotkania, wymieniliśmy się szczegółami naszych części zadania i przedyskutowaliśmy, z czym mamy największe kłopoty. Rozmawiając w kawiarni o zarządzaniu emocjami w zespole, zrozumieliśmy, że mamy wspólne cele oraz te same problemy.

Po tym zjeździe, komunikacja stała się o wiele lepsza, a praca bardziej produktywna. Jurii zaczął się częściej uśmiechać, więcej opowiadać o swoim komponencie, mój team ze swojej strony pomagał zbudować pełny scenariusz użytkownika oraz analizować błędy. Ostatecznie, nasz produkt okazał się lepszy niż oczekiwał tego klient.

Doświadczenie, które zdobyliśmy:

  • Emocje (pozytywne i negatywne) każdego z zespołów, a tym bardziej ich liderów, mają duży wpływ na cały zespół.
  • W większości przypadków należy lepiej poznać drugą osobę i zrozumieć jej motywacje. Być może macie wspólny problem i razem znajdziecie jego rozwiązanie.
  • Trzeba się wspierać. Nikt nie lubi litości, ale pomoc od ludzi podobnie myślących zawsze dodaje sił.

Historia 3: Problem online komunikacji

Na pewno każdy z was to zna: zdarzają się osoby, które mogą przeoczyć ważną wiadomość na czacie lub w mailu, a następnego dnia mają mnóstwo pytań. W jednym z moich projektów trafił się również taki pracownik, nazwijmy go Wasilij. Ludzie z technicznym podejściem, naprawdę bardzo często mogą się zanurzyć w kod, starając się nie rozpraszać się na różne bodźce. Dopóki to nie przeszkadza innym uczestnikom projektu, jest to normalnym zachowaniem.

Wyobraźcie sobie standardowy, zespołowy stand-up. Omawiamy status zadań oraz dyskutujemy na temat bieżących problemów. Kiedy następuje kolej Wasilija, on słysząc swoje imię, zaczyna wymieniać wszystkie problemy, które przed chwilą omówiliśmy.

Do dyskusji włącza się BA i miło odpowiada, że oczywiście pomoże z uzyskaniem odpowiedzi i wyśle je wiadomością mailową. Dla pewności, dodaje cały zespół w kopii maila.

Niedługo później spotykamy się na kolejnym stand-upie. Ku zdziwieniu całego zespołu, do głosu wyrywa się Wasilij i ponownie wymienia dawno rozwiązane już problemy. Upewniamy się, dlaczego informacja od BA była niewystarczająca dla bohatera tej opowieści. Okazało się, że nie zauważył on maila.

Doświadczenie, które zdobyliśmy:

  • Powinniśmy dawać ludziom feedback odnośnie ich pracy. Niektóre rzeczy mogą się tylko wydawać oczywistymi.
  • Jeżeli wasza wiadomość jest ważna, wzmocnijcie wasz komunikat poprzez powtórzenie go za pomocą innego kanału komunikacji – na callu, w wiadomości prywatnej, komunikatorze – gdziekolwiek, gdzie będziecie mieli pewność, że wasz kolega ją przeczyta.
  • Odnajdźcie ten sposób komunikacji, na który najbardziej reaguje ten, kto teraz jest wam potrzebny.

Epilog

Często nigdy się nie dowiemy, co stało za danym czynem drugiej osoby. Dopóki nie poznamy całej historii, nie będziemy w stanie jej zrozumieć. Zawsze pamiętajmy o ludzkich relacjach. Ze wszystkimi można znaleźć wspólny język. Wystarczy się postarać.