Komunikacja błędów w IT. Mój schemat

Po skończeniu tego postu: „jak się komunikować” stwierdziłem: “komunikacja, głupcze!”. To chyba tekst dla samego siebie. Początkujący koder widzi błędy wiele razy częściej, co jest normalne. A jak przekazać informację o nich swoim doświadczonym kolegom?

 

C…, c…,co się stanęło?

I już, bum. Widzisz czerwone “Error”. Aż w oczy gryzie. Nie uciekaj, tylko bierz się do roboty. Jeśli się zestresujesz, to idź i zrób sobie kawy, herbaty, weź łyk wody. A potem drugi. I oddech. I jeszcze jeden oddech. Nie jest łatwo, ale nie da rady inaczej, bo trzeba kombinować.
Upewnij się, że komunikujesz informację w sposób zrozumiały, bez ozdobników, emotikonek, heheszek, bez zbędnych słów i długiego wprowadzenia. Jeśli piszesz na mail, wiadomość, oczywistym jest, że można dodać zrzut ekranu.
Jeśli wiesz, co się stało – nawet, jak nie wiesz jak to się stało – to podejdziesz do tematu spokojniej i będziesz go mieć pod kontrolą. Na początku warto przeczytać to, co wyświetla się w informacji o błędzie. Zasługa mojego mentora w pracy – czytaj komunikat o błędzie, po to je się pisze. Zwykle najważniejsza rzecz jest zaraz po tym długim opisie z tysiącem cyferek i dziwnych znaczków. Tę informację można skopiować i wrzucić do przeglądarki, najlepiej w cudzysłowie, wtedy zawęża się spektrum.Jeśli jesteś żółtodziobem, to często rozmawiasz z osobami, które oddychają programowaniem od lat. Komunikacja.

 

Coś się, coś się popsuło…

Wróć do sytuacji, w której wszystko pięknie się napisało i na końcu jest błąd. Teraz przeczytaj ten opis:
Się zepsuło, nie działa i utknąłem.
Taki opis nie spełnia podstawowego wymogu. Co z niego rozumiesz? Co nie działa? Jak do tego doszło? Komunikacja w tym wypadku nie zachodzi. Bez sensu rośnie napięcie. Sytuacja wymaga od innych dopytania się Ciebie, otrzymania informacji zwrotnej na temat problemu, niemal dokopywania się do niej. Niektórzy frustrują się szybciej i cała komunikacja idzie na straty, bo przeważają emocje zamiast konkretnej współpracy.
Pracuję teraz, nad …., kiedy próbuję zrobić…, to dzieje się … (wariant: a powinno się dziać….).
Spróbowałem zrobić to… w ten sposób:… i w ten sposób:…, patrzyłem tu… i tu…, ale wciąż dzieje się to… i to….
Sam takie komunikaty pisałem sobie najpierw na kartce, a potem czytałem. Po kilku dniach zacząłem komunikować się bardziej naturalnie, a schemat wszedł do pamięci i się tam zagnieździł: Przykład:
Dostałem informację od klienta, że wyskakuje mu błąd z datą dokumentu. Kiedy powtórzyłem jego kroki, wyświetlił się błąd o treści „brak odpowiedniej daty”.
Próbowałem rozwiązać to zmianą daty pierwotnego dokumentu i zmianą daty wystawienia, ale wciąż otrzymuję informację o nieprawidłowej dacie. Proszę o pomoc.
W ten sposób skracasz drogę do rozwiązania problemu i jednocześnie przekazujesz przydatne informacje. Dodatkowo, podejmując wysiłek samodzielnego sprawdzenia rozwiązania zmniejszasz ilość zapytań, uczysz się i rozwijasz. Co najmniej warto spróbować zrobić coś samemu i nie biec w panice do lidera zespołu. Tym niemniej widać, że seniorzy, choć zajęci zawsze, nie powinni mieć problemu z tym, aby poświęcić dla Ciebie kilka minut. Może nie od razu, ale za chwilę, dwie. Zwykle zasugerują odpowiedź bądź sprawdzenie czegoś w systemie.

 

Warto spędzić kilkanaście minut na próbie rozwiązania problemu.

 

Pracuję z klientem i widzę, że ludzie często od razu po prostu robią zrzut ekranu, bez komentarza wysyłają do pomocy. Ten krok jest rezultatem zmieszania stresu, braku czasu lub umiejętności, doprawionymi kilkoma szczyptami lenistwa i strachu. Z czasem udaje się wypracować wspólną płaszczyznę komunikacji z klientem. W moim przypadku część osób potrafi opowiedzieć mi sytuacji wykorzystując schemat, który opisałem powyżej.

 

Nie pretenduję do bycia mistrzem w komunikacji. To tylko mój schemat. Z pewnością warto wyrobić sobie swój i zmieniać go z czasem, zgodnie ze swoim rozwojem.

Nie bądź jak pan Kazimierz, nie denerwuj się tak bardzo.