Jak zakomunikować testerski fuck up?

Artykuły

Wierzę w wartość dodaną pomyłek oraz idee popełniania błędów. W tę niewidoczną moc sprawczą porażek, które nie tylko budują charakter lecz również dają podwaliny postępowi i samodoskonaleniu. Jestem święcie przekonany, że to na ich podstawie buduje się umiejętności, zdobywa cenne doświadczenie oraz przygotowuje się mentalnie do nowych problemów i zadań.

Managerowie, jasna sprawa, inaczej widzą na ten temat.

Dla nich każda nieplanowana porażka to plama na honorze,  a i oznaka pracowniczych wad i niedbalstwa. Pomyłki nie powinny się trafiać, to zło konieczne, którego nie chcemy, a jeśli już zaistnieją to najlepiej szybko pozamiatać sprawę pod dywan co by klient nie dowiedział się o niczym.

Trawa pomalowana na zielono i kryształowy świat bez skaz.

Tyle teorii.

Plany swoje, a życie swoje. Daliśmy ciała, nie dopilnowaliśmy testów, zapomnieliśmy o featurze, nie pokryliśmy danego zagadnienia – lista może być długa, ale skutek jeden – daliśmy ciała. Dopuściliśmy do fuck up’a i mamy bajzel, który należy sprzątnąć.

Co dalej? Jak żyć?

Po pierwsze – nie panikować.

Stało się to stało się. Nie ma co się emocjonować i eskalować problemu. Spokój, chill, profesjonalizm. Na histerię przyjdzie jeszcze pora. Póki co ustal, że NA PEWNO dopuściłeś do problemu. Sprawdź dwa razy czy to co odkryłeś rzeczywiście jest fuck upem czy jedynie nieporozumieniem. Najlepiej zrób to poprzez konfrontację z innym testerem albo osobą, która zna zagadnienie tak samo/lepiej niż ty. Dopiero kiedy w ten sposób potwierdzisz, że doszło do wpadki można wówczas przystąpić do kolejnych kroków.

  • Na początek określ w trzech zdaniach jaki problem stworzyłeś/co się stało. Czy mówimy o sytuacji w środowisku lokalnym, wycieku dokumentacji, problemie z market releasem? Poszła zła labelka, nieprawidłowy build, omyłkowy rezultat testu? Zapomnieliśmy pokryć dany obszar? Zrobiliśmy to na archiwalnej wersji softu? Nie zaktualizowaliśmy test planu?
  • Spisz informacje! Krótko, rzeczowo, w żołnierskich krokach. Rozpisz je dokładnie bo w stresie (i pod gradobiciem pytań) możesz zapomnieć o istotnych szczegółach.
  • Wypunktuj sobie detale dotyczące wersji programu, systemu operacyjnego, serwera i czegokolwiek innego (suche liczby) co mogłoby lepiej wyjaśnić problem. Dałeś ciała, trudno, przynajmniej pokaż, że rzetelnie i profesjonalnie potrafisz zaradzić zaistniałej sytuacji.
  • Wyjaśnij jak najszybciej/najlepiej/najskuteczniej naprawić kłopot. Słowami, które możesz przedstawić klientowi, PMowi, własnej matce. Bez lania wody, bez zbędnego bajkopisarstwa. Punktowo i rzeczowo.
  • Zgraj sobie wszystkie dane w jedno miejsce (cokolwiek niezbędnego jest do wyjaśnień), wydrukuj kwity z informacjami i szykuj się bo czas na najtrudniejszy etap.
  • Idź i poinformuj PM/Product Ownera/Scrum Mastera lub inną osobę decyzyjną o zaistniałej sytuacji. Nie mailowo czy hangoutowo lecz personalnie, w cztery oczy, poza wścibskimi uszami kolegów i koleżanek. Nie zwlekaj z tym, nie szukaj dobrego momentu, nie rozważaj czy ma lepszy/gorszy humor. I tak dostanie Ci się po dupie za dopuszczenie do zaistniałej sytuacji i tak, więc nie oczekuj fanfar tylko czym prędzej skontaktuj się z osobą decyzyjną i wyjaśnij co zaszło.
  • Wiem, że ciężko to będzie wykonać ale… staraj się zachować spokój. Będzie pewno krzyk, będzie pytanie „Jak to? Przecież pytałem się!? Zapewniałeś, że…”. Padną oskarżenia, może i mocniejsze słowa. Podsuń wówczas gotowe rozwiązanie, wyjaśnij dlaczego trzeba je natychmiast wdrożyć w życie i zasugeruj, że potem wyjaśnisz co i jak. Teraz liczy się natychmiastowe załatanie zaistniałej bolączki.
  • Idź i pozamaiataj po sobie 🙂
  • Po wszystkim zorganizuj sobie lessons learned. Najlepiej po raz kolejny z przełożonym. Ustalcie metodę działania na wypadek gdyby sytuacja miała się ponownie powtórzyć. Krótki ale treściwy plan B zrozumiały dla każdego członka zespołu. Wybierzcie dodatkowo osobę, która wspomoże Twoją prace albo będzie pamiętać o specyficznym tasku („Na pewno zrobiłeś…?). Jeśli się da – strzel sobie przypominajkę w kalendarzu. A na koniec przyjmij pokorną minę mówiącą jasno i wyraźnie, że już więcej do takiej sytuacji nie dopuścisz.
  • A skoro napisałem to raz to warto powtórzyć ponownie – nie dopuść do podobnej sytuacji! Szkoda renomy, dobrej opinii i nadszarpniętego już zaufania.

I tyle. Dużo strachu mimo, że nie ma o co.

Powiem wręcz więcej i pocieszę Cię – świat kręci się nadal, a co więcej, mało kto zauważył, że puściłeś bąka. Nie Twój pierwszy, nie ostatni. Zrobiłeś to ty, zrobią to inni po Tobie.

Co prawda, nie należy mieć przez to ani postawy spłoszonego, bojaźliwego kundla ani beznamiętnego Wietnamczyka wypranego z emocji.

Najlepiej nie bierz za mocno jakichkolwiek porażek do serca. Jak mówiłem – zdarzają się one najlepszym, uczą dobrych praktyk na przyszłość i większej dokładności w tym co robimy. Są więc jak najbardziej pożądane mimo, że nikt oficjalnie do nich się nie przyznaje.

A na koniec kwestia opieprzu (bo niektórych ten motyw przeraża najmocniej) – najlepszy i najskuteczniejszy ochrzan to taki, w którym usłyszymy od szefa maksymalnie jedno zdanie pokroju: „zawiodłem się na Tobie”. Oj, boli to dużo mocniej i głębiej niż jakakolwiek inna forma krytyki, uwierz Mi na słowo.


Marcin Sikorski

Twórca wortalu test-engineer.pl. Wieloletni test lead oraz entuzjasta obszaru Internet of Things oraz systemów Embedded.

Leave a Reply

Be the First to Comment!

Notify of
avatar
wpDiscuz