Jak radzić sobie ze współpracownikiem, który obwiniał mnie o błąd, który był jego winą

Niektórzy ludzie mają tendencję do agresywnego obarczania winą innych, aby odwrócić uwagę od siebie. Ponieważ ty też jesteś stosunkowo nowy, musiało mu być bardzo wygodnie robić to, co robił.

Oto moja rada. Napisz maila, opisz jaki był problem, jak dotarłeś do pierwotnej przyczyny, jaka była jego ewentualna korekta i jak można temu zapobiec w przyszłości. Włącz wszystkie zainteresowane strony do tego maila.

Na końcu tego maila napisz coś w tych linijkach,

XYZ,

Czy możesz dodać te kroki do odpowiedniej dokumentacji lub dokumentu Standard-Operating-Procedures dla tego fragmentu kodu?

W ten sposób “nie wskazujesz palcem” na niego, ale wyraźnie wołasz, że jest on właścicielem tego fragmentu kodu i dlatego jest za niego odpowiedzialny. Wołanie jest ważne, ponieważ nie każdy (zwłaszcza wyższe kierownictwo) otworzy jakiekolwiek linki do bazy kodu, aby zobaczyć, czyje to było zaangażowanie.

Trochę szorstkie, ale on na to zasługuje.

Zbudowałem karierę nie grając w grę z obwinianiem, ale prawda jest taka, że ludzie słuchają najgłośniejszego głosu. Jeśli jednak zaangażujesz się w obronę, to on ściągnie cię do swojego poziomu i pobije cię doświadczeniem.

Jeśli możesz go znaleźć, potrzebujesz mistrza. Idealnie byłoby, gdyby to był Twój menedżer, ale czasami jest to kolejny szanowany deweloper. Pójdzie do kija, aby uciszyć tego głośnego. Wszystko co musisz zrobić, to przeprowadzić z nimi prywatną dyskusję o faktach (nie o winie), co zrobiłeś, aby rozwiązać problem i jak chcieliby, abyś postąpił tak, aby następnym razem, gdy coś jest nie tak z serwisem, problem mógł być szybciej znaleziony i naprawiony. Może się to wiązać z napisaniem małego testowego narzędzia, które testuje usługę bezpośrednio (bez użycia kodu innych programistów), albo jakiegoś logowania czy czegoś, więc problem “my kontra oni” może być bardzo szybko rozwiązany. Jeśli wiedzą, kto tak naprawdę zawinił, mogą wyczyścić Twoje imię i nazwisko bez bezpośredniego konfliktu z tym głośnym.

Zawsze pochylałem się do tyłu, aby uniknąć stawiania innych programistów w obronie. Mówiłem takie rzeczy jak: “Mam problem z powielaniem problemu, czy możesz mi powiedzieć, jakie połączenia telefoniczne wykonujesz do serwisu i co dostajesz z powrotem, żebym mógł przetestować serwis poprawnie”? Jeśli programista nie chce podać ci śladów połączeń i odpowiedzi, zapytaj, czego oczekiwał. Jednak przez większość czasu programista po prostu pokaże Ci swój kod. W takim przypadku, czasami można dostrzec problem. Nawet jeśli to zrobisz, i tak ich nie zawołaj. Oni sami muszą znaleźć problem. Niech przepuszczą kod przez debugger i niewinnie zapytają, co dana zmienna zawiera w określonej linii kodu. Mógłbym kontynuować, ale masz pomysł.

To bardzo dobra tradycja w branży IT (a w niektórych innych, jak np. w lotnictwie), że kiedy ktoś znajdzie problem, wszyscy pracują razem nad jego rozwiązaniem, a najlepiej nad znalezieniem pierwotnej przyczyny, aby procesy mogły zostać usprawnione, ale nikt nie ponosi osobistej winy ani nie podlega karze za popełnienie błędu. W rezultacie ludzie są otwarci i uczciwi wobec swoich błędów, zamiast próbować je zatuszować, co jest z korzyścią dla wszystkich.

Wygląda na to, że w Twoim sklepie są ludzie, którzy nie wkupili się w tę kulturę, a to jest coś, co wymaga uwagi kierownictwa.

Uważam, że powinieneś porozmawiać ze swoim przełożonym o tym, w jaki sposób rozwiązywane są problemy, zwłaszcza priorytetowe kwestie, które wpływają na doświadczenie użytkownika.

W tym przypadku masz 2 systemy komunikujące się ze sobą i nagle komunikacja przestaje działać. Kiedy komunikacja zawiedzie, ważne jest, aby obie strony przyjrzały się obu systemom. Każda z nich kładzie nacisk na Twój serwis, prowadząc do tego, aby nie badać rzeczy na swoim końcu. Największą stratą czasu w rozwiązaniu problemu jest próba dowiedzenia się, co jest nie tak z częścią, która faktycznie działa tak jak powinna**.

Są to jednak doświadczenia z nauki. Założę się, że teraz doskonale wiesz, jak rozwiązywać problemy z twoim serwisem. Spróbuj stworzyć plan rozwiązywania problemów w oparciu o swoje doświadczenie i wykonaj jeden z pierwszych kroków, aby upewnić się, że to właśnie Twój serwis zawodzi (“Czy serwis działa, gdy jest wywoływany z innej strony?”, “Czy serwis zawodzi częściowo lub całkowicie?”). Jesteś facetem od serwisów internetowych, możesz mieć trochę zaufania do swojej pracy.

Spróbuj zapomnieć o tym, że to właśnie jego kod zawiódł. Próba wywołania go na to jest trochę małostkowa. Nie powinien był tak bardzo skupiać się na tobie od początku. Potraktuj to jako ogólny problem w firmie z rozwiązywaniem problemów i zajmij się nim jako takim ze swoim przełożonym. Nie wiesz też, czy to rzeczywiście był jego kod, mógł go też skopiować z innej sekcji napisanej przez kolegę.

Myślę, że propozycja rozmowy z twoim przełożonym jest dobra. Twój menedżer musi wiedzieć, że zostałeś niesprawiedliwie obwiniony.

Ale na dodatek, jesteś testowany. Twój początkowy instynkt ma rację; musisz odpowiedzieć, albo będzie gorzej. Wysłałbym mu maila bezpośrednio i dałbym znać, że problem tkwi w jego kodzie, i że przez ten czas nie powiedziałeś nikomu poza swoim menadżerem, któremu musiałeś powiedzieć, aby się chronić. I na koniec daj mu znać, że jeśli zrobi to jeszcze raz, wyjdziesz na jaw.

Jestem trochę spóźniony na to pytanie, ale obok bardzo rozsądnej rady w odpowiedzi Edgara, jest jeszcze druga część.

Jeśli wyślesz komunikat, że znalazłeś problem i zanotujesz gdzie został on rozwiązany, wtedy inni deweloperzy prawdopodobnie będą wiedzieć gdzie leży problem (to jest dobre), ale kierownictwo prawdopodobnie nie.

Robienie tego w ten sposób oznacza, że zrobiłeś temu facetowi przysługę - publicznie cię wezwał, znalazłeś problem, naprawiłeś go i nie wrzuciłeś go do niego z kierownictwem. Budowanie zaufania w ten sposób z Twoimi współpracownikami na dłuższą metę utrzyma Cię w dobrej kondycji.

• *

Niewielka notatka uboczna - to oczywiście zależy nieco od charakteru winy, jaką znajdziesz w ich pracy. Jeśli to, co znajdziesz, jest tak bardzo złe, że wskazuje na niekompetencję z ich strony, możesz po cichu przekazać to swojemu menadżerowi - będzie chciał wiedzieć, a ty również budujesz z nim zaufanie.

Sugeruję, żebyś się na nim przespał, zanim zareagujesz na osobiste aspekty sytuacji. Jeśli naprawiłeś problem i znowu zacząłeś działać, to nadal jesteś “człowiekiem”. Po odpoczynku będzie łatwiej być łaskawym.

Podczas gdy główny problem był już szczegółowo omówiony w innych awserach - ten drugi facet nękający Ciebie - chciałbym zwrócić uwagę na inną perspektywę.

Naprawa została wykonana w kodzie, który był własnością tego drugiego faceta, jednak częściej usługa mogła zapobiec większemu problemowi poprzez bycie bardziej konserwatywnym przy obsłudze zgłoszeń od klientów. Czy sprawdza poprawność danych wejściowych? Czy zgłasza jakieś błędy w czasie rzeczywistym? Czy istnieje środowisko testowe (dotyczy to również konsumentów)? Czasami problem w usłudze tylko czekał, aby się ujawnić, więc powiedziałbym, że tylko dlatego, że poprawka została zrobiona w jednym miejscu, nie oznacza to, że jest to cała historia. Ponadto, w przypadku takich problemów, jest to coś więcej niż tylko kod. Jest też proces.