Jak sobie radzić ze średnio trudnymi sztukami

Co jednak zrobić, kiedy deweloper "stawia się", jeśli mamy poczucie, że chce nas mniej lub bardziej kulturalnie zbyć.

Dążmy do rozstrzygnięcia na płaszczyźnie merytorycznej.

Nie wdawajmy się w wymiany złośliwości. Postarajmy się wyjaśnić, dlaczego deweloper upiera się przy swoim. Zajrzyjmy w wymagania: czy są jednoznaczne, czy też zostawiają pole do interpretacji? Jeżeli są, naszym zdaniem, jednoznaczne, a deweloper upiera się przy swoim, skontaktujmy się z osobą piszącą wymagania: co ona na ten temat sądzi? Jeżeli nie jest pewna, niech to wyjaśni. Jeżeli jest to wyjaśnione i stwierdzimy, że właśnie my mamy rację, a programista nadal upiera się przy swoim, przestaje być to problem o podłożu merytorycznym, a staje się świadomą odmową programisty wykonania swoich obowiązków. Nie jest rolą testera go dyscyplinować. Opiszmy dokładnie całą sprawę i przekażmy ją przełożonym.

Unikajmy niedomówień i o ile to możliwe dyskutujmy w sposób pozostawiający ślad (np. e-mail).

Należy zmusić programistę, żeby podał powody, dla których nie zgadza się z nami lub wyartykułujmy je sami i zmuśmy go do odniesienia się do nich. Deweloper mruczy nam znad klawiatury: "Problem z aktywacją to nie jest duża rzecz, nie mam teraz czasu". Napiszmy wtedy maila: "W nawiązaniu do naszej rozmowy rozumiem, że twoim zdaniem całkowita niemożność przeprowadzenia jakiejkolwiek aktywacji nie będzie poprawiana w tym cyklu produkcyjnym ze względu na małą wagę problemu. Czy mógłbyś to potwierdzić?". Jeśli nie odpowiada, to należy przesłać to do kogoś wyżej (z cc: do samego zainteresowanego): "Udziel mi, proszę, odpowiedzi, bo muszę podjąć decyzję, co robić z tym pakietem". Zmusza to dewelopera do zajęcia stanowiska i wzięcia odpowiedzialności. Często też pomaga mu zrozumieć skalę problemu.

Jak sobie radzić z trudnymi sztukami

Co robić z deweloperami, którzy są nieprzyjemni i odmawiają współpracy, mimo że staramy się być w stosunku do nich grzeczni i profesjonalni? Czułbym się nieuczciwie, gdybym powiedział, że znam na to stuprocentowo skuteczny sposób. To, jak możemy działać i czy w ogóle możemy coś zdziałać, zależy od wielu czynników: naszej pozycji, pozycji dewelopera, otwartości naszych zwierzchników i oczywiście atmosfery w firmie. Tu już większą rolę odgrywa znajomość mechanizmów relacji międzyludzkich. Pomocne może być również pamiętanie o poniższych wskazówkach:

Bądźmy dobrzy merytorycznie.

Znajmy się na rzeczy. Na tyle, żeby w razie sporu nie dać sobie "wcisnąć kitu".

Nazywajmy rzeczy po imieniu.

"Słuchaj, nie wiem, dlaczego jesteś taki nieprzyjemny. Mam poczucie, że traktujesz mnie jak wroga. Czy masz do mnie o coś jakiś żal?" - zmuszamy wtedy programistę do sprecyzowania i wyartykułowania swojego negatywnego nastawienia. Wiele osób jest gotowych do złośliwych uwag, dużo mniej wyraża wprost swój negatywny stosunek do nas.

Uspokajajmy, że nie jest naszym celem szukanie winnych.

Wielu deweloperów przyjmuje pozycję defensywną: "Wiesz, to nie działa, ale to nie moja wina. Sprawdziłem, ale wtedy Iksiński jeszcze dodał to…", albo "Nie zrobiłem tego, bo dopiero co wróciłem ze spotkania" Mówię wtedy: "OK. Pytam bez pretensji. W porządku. Po prostu powiedz, na kiedy ci się to uda zrobić, bo muszę zaplanować swoją pracę".

Nie zawsze dobro triumfuje

Podczas treningów efektywnej komunikacji jesteśmy przekonywani, że w każdym z nas istnieje chęć porozumienia się z innymi i współpracy dla wypracowania lepszego jutra. Być może. U niektórych jednak te złoża dobrych chęci są tak głęboko ukryte, że koszty ich eksploatacji znacznie przewyższają korzyści.

Trzeba mieć świadomość, że możemy znaleźć się w środowisku, w którym ze względu na nieodpowiednie zarządzanie i brak świadomości ze strony przełożonych sytuacja jest zła i trudno ją zmienić. Nawet DeMarco w swojej książce "The Deadline" (w polskim tłumaczeniu "Zdążyć przed terminem") zauważa, że możemy się czasami znaleźć w sytuacji, w której (po uwzględnieniu naszej pozycji i siły) najlepsze, co możemy zrobić, to po prostu przeczekać. Jeżeli jesteśmy początkującym testerem, może warto zmienić pracę? Pewnie nie mamy dużej pensji, więc strata będzie mała. W przeciwnym razie niewiele się nauczymy, a będziemy poddani silnym stresom i frustracji.

Procedury

Osobiście podchodzę z dużą rezerwą do procedur. Uważam, że często pokłada się w nich zbyt duże nadzieje. Jednak nie ulega wątpliwości, że są sytuacje, w których rozsądne procedury, przestrzegane z żelazną konsekwencją, są bardzo pomocne. Jedną z zalet takich procedur jest to, że tester może zwalić na nie całą winę za swoją nieugiętość.

"Słuchaj, nie mogę puścić tego pakietu. Nie przyjmą go, bo jest w nim błąd x. Musiałbyś porozmawiać z moim przełożonym i zespołem konfiguracji. Poza tym administrator bazy danych o błędach i pakietach musiałby nadpisać status błędu, bo ja nie mam takich uprawnień". Deweloper widzi, że nie chodzi o nasz upór. To procedury utrudniają całą sprawę.

Podsumowanie

Nie poradzimy sobie z problemem, jeżeli dobrze go nie zrozumiemy. Dla testera problemem jest programista. Dlatego tak ważne dla pierwszego jest zrozumieć tego drugiego.

Programiści zwykle nie chcą robić testerom na złość - oni też mają swoje problemy i bolączki.

Przekazywanie złych wiadomości jest podstawowym zadaniem testera. Można to jednak robić w taki sposób, aby bez potrzeby nie wywoływać złych emocji.

Można oczywiście zadać sobie pytanie, czy dobre układy z programistami są na tyle ważne, że warto się o nie troszczyć. Na to pytanie każdy tester musi jednak sam sobie odpowiedzieć. Przy podejmowaniu decyzji warto mieć na uwadze fakt, że programista może naprawdę pomóc. Jego pomoc może być niezastąpiona, kiedy szybko chcemy zrozumieć funkcjonalność testowanego systemu, walczymy z trudnym do odtworzenia błędem, a także w wielu, wielu innych sytuacjach.

<hr>Piotr Kałuski pracuje jako konsultant w firmie CGI, jest analitykiem biznesowym w Polkomtelu.