Znasz to uczucie, kiedy właśnie otrzymałeś/aś zaproszenie do nowego projektu i za moment zacznie się Twoje pierwsze wspólne spotkanie, tak zwane „daily”?

 

Często towarzyszą temu rozmaite pytania, które rodzą się w głowie, jak na przykład:

Czy zespół mnie zaakceptuje?

Czy nie palnę żadnej gafy?

Czy odnajdę się w projekcie, który trwa już od jakiegoś czasu?

Czy mój angielski jest wystarczający, abyśmy wzajemnie się zrozumieli?

Z pewnością takich pytań może zrodzić się cała masa. Wszystko to generuje dodatkowy stres, który wpływa na naszą produktywność. Nie od dziś wiadomo przecież, że różni ludzie, w różny sposób podchodzą do przełamywania barier społecznych. Jedni brylują w towarzystwie niczym Wielki Gatsby, a inni (jakieś 90% społeczeństwa) czują chociażby delikatny stresik przed poznaniem nowego zespołu.  

W tym artykule pokażę Ci, że nie taka komunikacja straszna, jak ją malują!

Say Hello

Czyli, jak zaprezentować się w nowym zespole

Kiedy otrzymałem mój pierwszy projekt i zbliżała się godzina spotkania, mój umysł nastawił się na swego rodzaju „interview” z potencjalnym pracodawcą. Zaprzątałem sobie głowę tym, czy dobrze będę wyglądał w kamerze, czy nagle wszystkie lekcje angielskiego nie pójdą w niepamięć, gdy zatnę się na jakimś słowie. Czy zrozumie technikalia, o jakich może być za chwilę mowa.

No właśnie, masa stresogennych myśli, prawda?

Musimy pamiętać o bardzo ważnej rzeczy, mianowicie: jedna zła myśl, przyciąga drugą. W efekcie czego, rozpoczyna się proces domina i zanim się obejrzymy, będziemy zeżarci przez naszego największego wroga - stres.

Dlatego najlepiej odrzucić podejście „gdybania”, a pytania „co jeśli?” zamknąć w pudełku na klucz i wyrzucić. Cała koncentracja i energia powinna być teraz skierowana na wyczucie odpowiedniej atmosfery towarzyszącej spotkaniu.

Dlaczego?

Ponieważ ludzie najlepiej się czują się z osobami, które wpasowują się w ich mowę, gesty, ton oraz podejście. Jeśli zatem na swoim pierwszym spotkaniu zauważysz, że zespół wita się krótkim:

Siemanko!

przywitaj się w ten sam sposób. A jeśli jest bardziej oficjalnie i usłyszysz krótkie choć stonowane:

Dzień dobry wszystkim

przywitaj się tak samo. To bardzo ważny proces.

Gdy nie będziesz odstawać od reszty, to na 99% zespół będzie Cię traktował tak jakbyście współpracowali ze sobą od zawsze. Tak dobrze przygotowane „wpasowanie” sprawi, że ludzie będą mieli poczucie, jakbyś od samego początku był częścią ich zespołu.

No dobrze, przywitaliście się i właśnie nadeszła Twoja kolej na mównicy, ale przecież nikt Cię o nic nie zapytał, projekt świeży, dziś pierwszy dzień, nie masz nic nowego do dodania, a więc co robić?

Wbrew pozorom to bardzo proste. Podejdź do tego jakbyś poznawał/a właśnie znajomych swojego partnera/partnerki. Nie wiecie nic o sobie, a więc najprostszym sposobem jest pokazanie się innym jako osoba otwarta, która chętnie podejmie dyskusję na dowolny temat.  A najlepiej to zrobić przez opowiedzenie coś o sobie - jakiej muzyki słuchasz, w co grasz, jakie lubisz filmy, książki.

Pamiętaj, że nie musisz nagle opowiadać historii swojego całego życia. Wystarczy króciutkie „podsumowanie”. Może ostatnio zafascynowała Cię jakaś technologia, wpadł Ci w ucho nowy artysta lub polecasz dobry serial na Netflixie?

Ten motyw najlepiej działa na zespoły, które już od jakiegoś czasu współpracują ze sobą. Dla nich informacje jakie podasz, mogą być fajną i ciekawą odskocznią od rutynowych spotkań. Zawsze ktoś coś może dodać, a kto wie - może od razu znajdziecie wspólne zainteresowania i wspólny język.

Natomiast w nowych zespołach jest tak, że i tak wszyscy się poznajecie, więc uchylenie rąbka tajemnicy co do swojej osoby pomoże zjednać do siebie ludzi i wzbudzić ich zaufanie.

Także jeśli dziś jest Twoje pierwsze „daily”, nic się nie bój,  weź głęboki wdech i z uśmiechem staw czoła społecznemu wyzwaniu!

Fix It

Czyli jak zgłosić buga i zrozumieć zespół oraz jego potrzeby

Minęło trochę czasu, coraz lepiej poruszasz się w projekcie i nadszedł TEN moment, w którym czas zgłosić swojego pierwszego buga! No dobrze, ale jak to odpowiednio przekazać?

Od razu mówię, że wszelka frustracja na deweloperów odpada.

Z takim podejściem wytworzysz wokół siebie aurę toksyczności i zostanie Ci przypięta łatka „aferzysty”. Dlatego też bardzo dobrym sposobem jest, nie tylko stworzenie samego zgłoszenia w odpowiednim do tego narzędziu, ale też poinformowanie dewelopera na prywatnym kanale, że znalazłeś/aś taki błąd i w tym miejscu jest on zgłoszony. Dzięki temu może się to łatwo przerodzić w jakąś luźną dyskusję i lepsze poznanie drugiej osoby.

A co, jeśli otrzymasz odpowiedź w stylu „dzięki” bez dalszych komunikatów? Nie zrażać się i pozostawić tę osobę w spokoju. Być może jest teraz zajęta i nie ma czasu? Nic przecież nie stoi na przeszkodzie, aby dopytać się o nasze zgłoszenie później :)
 

Nie samą pracą żyje człowiek

Fajnym motywem jest też wysłanie naszego zgłoszenia z komunikatem kompletnie odbiegającym od niego. Na przykład:

Hej, zrobiłem zgłoszenie odnośnie buga jakiego znalazłem, abyś nie szukał, wysyłam Ci link. A tak swoją drogą widziałeś to?

I tutaj możesz podesłać jakiś fajny, ostatnio znaleziony artykuł (np. Ten) lub wrzucić  artystę muzycznego.

W ten sposób my testerzy, pokazujemy drugiej osobie, że nie jesteśmy tylko ludźmi od zgłaszania defektów (albo o zgrozo od „wytykania błędów”). Pozwala to na stworzenie swego rodzaju więzi koleżeństwa i naturalnego kontaktu z drugą osobą. I dzięki temu jesteśmy zauważani jako komunikatywni, a nie jako odizolowane jednostki mające tylko jeden cel - psuć.

No właśnie, a skoro o psuciu mowa, dobry tester nie powinien tylko szukać błędów, ale nieustannie szukać rozwiązań, które pozwolą usprawnić proces naprawiania usterek i dobrego zarządzania nimi, a co za tym idzie tworzyć.

Tak, dobrze widzisz: od samego psucia nic dobrego nie wyniknie!

Jeśli na przykład widzisz, że nie ma kanału do przekazywania procesów QA, stwórz go! Jeśli nie ma nigdzie miejsca, gdzie ktoś z zespołu deweloperskiego mógłby zadać Ci pytanie, a odpowiedź byłaby widoczna dla wszystkich – może warto byłoby to zaproponować! Dzięki temu zachowasz kontakt i przepływ informacji ze swoim zespołem. Pokażesz im, że bierzesz stały i, co ważniejsze, aktywny udział w tworzeniu produktu.

Zbadaj potrzeby klienta

Równie istotnym co wychodzenie naprzeciw oczekiwaniom klienta, jest też badanie jego potrzeb. Gdy uważasz, że brakuje miejsca do przechowywania przypadków testowych i wszelkiej maści dokumentacji testerskiej jaką udało Ci się stworzyć - zapytaj!

Nic złego się nie stanie jeśli zaproponujesz jakieś ciekawe rozwiązanie, które można byłoby wdrożyć do projektu. Na przykład bardzo fajne narzędzie do zarządzania przypadkami testowymi - TestRail.

Dobrą praktyką jest również odpowiednie przygotowanie przed „rzuceniem” takiej propozycji. Musisz wtedy wyposażyć się w odpowiednią wiedzę na temat danego narzędzia, by w razie pytań móc na nie swobodnie odpowiedzieć. Fajnie jest też wybadać rozmaite „ficzery”, które razem z tym narzędziem można wdrożyć, jak choćby integracja z Jirą.

Na sam koniec porcja oczywistych oczywistości. Jednak warto o nich wspomnieć.

Pamiętaj o najważniejszej rzeczy - my jako testerzy mamy wskazywać defekty i pomagać je rozwiązać, dbać o jakość i szukać sposobów na polepszenie produktu. Począwszy od kolorystyki strony, poprzez jej użytkowanie, aż po użyteczność, dostępność i funkcjonalność jej poszczególnych elementów. Nie oceniajmy drugiej osoby, oceniajmy produkt. A przy tym róbmy to w sposób konstruktywny, nieinwazyjny i przede wszystkim konsekwentny.

Jeśli będziesz się tego trzymać, to każdy zespół Cię doceni, gwarantuję.

Oops! Something went wrong!

Czyli, co zrobić jeśli popełniliśmy błąd
 

Ale jak to? Tester popełnił błąd? Przecież on jest od ich odnajdywania, a nie popełniania!

Cóż, w ogólnym rozrachunku, ciężko się z tym nie zgodzić. Jednak należy pamiętać tutaj prawdę starą jak świat - jesteśmy tylko ludźmi i czy tego chcemy czy nie, błędy będziemy popełniać.

Załóżmy, że zdarzyła się sytuacja, iż na produkcję został wypuszczony build z bardzo poważnym defektem, który nie był tak łatwy do wykrycia, a my z naszym ograniczeniem czasowym, nie byliśmy w stanie go odszukać.

Co teraz?

Cóż - wtopa, nie da się ukryć. Ale spokojnie, przede wszystkim nie chować się pod biurko i nie płakać. Należy jak najszybciej zebrać jak najwięcej informacji na temat danego defektu. Gdy to już uczynimy i przekażemy naszemu zespołowi, wtedy możemy zająć się analizą, dlaczego w ogóle do tego doszło.

Przede wszystkim zapomnij o wytykaniu palcami i krzyczeniu „Ale on mi nic nie powiedział!” To w naszym interesie jest, aby dowiadywać się jak najwięcej na temat tego, co właśnie testujemy.

Być może źle dobraliśmy priorytety? Testowaliśmy rzecz A, ale to rzecz B była najważniejsza? Warto wejść wtedy w otwartą dyskusję i przedstawić swój punkt widzenia. Być może zespół źle Cię poinformował, albo to Ty coś źle zrozumiałeś/łaś?

Bardzo ważnym elementem rozwiązywania tego typu problemów jest zaproponowanie rozwiązania, które w przyszłości pozwoli uniknąć takich sytuacji. Nie możesz też być agresywny/a ani denerwować się na innych. Pokazywanie palcami odpada. Gdy tylko zespół zobaczy, że próbujesz zwalić problem, który Ciebie dotyczy, na kogoś innego - momentalnie straci do Ciebie zaufanie i odbudowanie go będzie graniczyło z cudem.

Dlatego przyjmij na klatę to, co się stało i staw czoła krytyce. Koniec końców, sam/sama robisz to na co dzień, prawda? ;)

Przyznawanie się do porażki

Jeśli jednak nie zawiodła ani komunikacja, ani nasz sprzęt, ani też jakikolwiek inny czynnik zewnętrzny, tylko my sami, to co wtedy? Wiele osób tego nie wie (albo wie, ale tego nie stosuje), ale zwyczajne przyznanie się do porażki i przeproszenie za nią to nie jest nic złego. Wręcz przeciwnie. Pokażemy, że potrafimy wyjść przed szereg i powiedzieć „to mój błąd, nie sprawdziłem tego, gdyż koncentrowałem się na innej rzeczy i kompletnie o tym zapomniałem. Przepraszam, będę robił wszystko co w mojej mocy aby to się więcej nie powtórzyło”.

To jak potrafimy przyznać się do porażki i zrozumieć ją, pokaże tak naprawdę czy potrafimy być więksi od samych siebie i jesteśmy w stanie pracować nad poprawą. Bo jak głosi pewne porzekadło „Istotą rozwiązania problemu - jest jego zrozumienie”.

El Grande Final

Czyli epilog

I tak oto dobrnęliśmy do końca tematu. Mimo, że temat został przeze mnie tylko muśnięty. Relacje międzyludzkie, sposoby komunikacji i tym podobne zagadnienia to temat rzeka, który można wałkować latami.

Ja sam, jako certyfikowany absolwent neurolingwistycznego programowania, zrozumiałem jak obszerny i skomplikowany jest to temat.

Rzeczy takie jak mowa ciała, gesty, ton, podejście, empatia - to wszystko codziennie kreuje nas na ludzi jakimi jesteśmy na co dzień i to jak inni przedstawiciele gatunku Homo sapiens nas postrzegają. Kiedyś pewien profesor przeprowadził badanie polegające na sprawdzeniu, czy ludzie mają wrodzoną gestykulację i mimikę. Okazało się, że osoba niewidząca od narodzin, robi taką samą minę gdy poczuje brzydki zapach jak osoba, która od urodzenia wzrok miała dobry. Osoby te, też robiły podobne gesty gdy kłamały, denerwowały się, były radosne czy smutne.

Pokazuje to, że pomimo dzielących nas granic, narodowości, kolorów skóry, języków i zwyczajów, nadal jesteśmy do siebie bardzo podobni w wielu kwestiach. Dlatego też miejmy na uwadze to, że pomimo iż nasz kolega z zespołu to Anglik, Rosjanin czy też Niemiec, to wszyscy jesteśmy ludźmi.

Tymi samymi, którzy czują, myślą, mają marzenia, popełniają błędy, mają dobre/złe dni, ale nadal ludźmi z krwi i kości. Ludźmi, którzy bez empatii wyginą jak dinozaury. Pamiętajmy o tym, mówiąc następne czy też pierwsze „Siemanko!” w projekcie, zgłaszając buga, czy też przyznając się do winy po popełnionym błędzie. 

Do następnego!