Pytanie:
Jak radzić sobie ze współpracownikiem, który winił mnie za błąd, który był jego winą
Ryan
2018-03-09 10:38:41 UTC
view on stackexchange narkive permalink

Jestem stosunkowo nowy w pracy, ale dałem się poznać jako „facet”, jeśli chodzi o określoną usługę sieciową, z której korzystamy. Nasza własna strona internetowa integruje się z usługą. Tak naprawdę nie pracuję w witrynie, tylko z usługą.

Dzisiaj mieliśmy coś w rodzaju problemu z zatrzymaniem programu, który powodował, że użytkownicy witryny nie mogli korzystać z usługi. Naturalnie wezwano mnie do pomocy, ale jeden z twórców strony był dla mnie osobliwy, insynuując, że nie wykonuję swojej pracy i zarzucając mi słabą komunikację. Później, podczas telekonferencji z co najmniej ośmioma innymi osobami, biernie-agresywnie wezwał mnie do tego, że nie rozwiązałem problemu.

Po długim dniu, pracy do późna iz domu, w końcu ustaliłem korzeń problemu, że nie ma go w usłudze, ale w kodzie na stronie, a konkretnie w kodzie, który napisał chudy programista.

TL; DR: facet, który wskazywał na mnie palcem, był w rzeczywistości przyczyna problemu

Generalnie jestem osobą beztroską i nie muszę mu przeszkadzać; jednak mam nadzieję na kilka sugestii, jak taktownie wyrazić mu, że wolałbym, aby był w 100% absolutnie pewien, że to nie jest jego kod, zanim znów przyjmie ten ton ze mną.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/74530/discussion-on-question-by-ryan-how-to-deal-with-a-coworker-who-blamed-me-for-the).
Jedenaście odpowiedzi:
Edgar
2018-03-09 12:15:02 UTC
view on stackexchange narkive permalink

Po prostu wyślij e-mail do wszystkich zaangażowanych osób z informacją, że po godzinach znalazłeś (i naprawiłeś) błąd. „Tak i tak jest w AB”. Może z linkiem do czegoś. Nie wspominaj o żadnej osobie.

To powinno wystarczyć. Nie musisz nikogo wskazywać palcem.

Inni przyjrzą się temu i wkrótce dowiedzą się, kto był / jest odpowiedzialny za ten błąd , a następnym razem zastanowią się dwa razy, zanim zaczną z Tobą zadzierać.

Zrobiłbym to również, zakładając, że był to jednorazowy incydent.Jeśli jest to część wzorca, eskalacja obronna może być uzasadniona.Na razie chciałbym po prostu zachować notatki z tego, co się stało, tak, że jeśli zdarzy się to kilka razy, mogę skompilować dość cholerny raport o tym, ile czasu spędzasz na sprzątaniu tego bałaganu.
Zgadzam się z tym.Bądź postrzegany jako facet, który zostaje naprawiony i pozwól innym grać w grę z obwinianiem, jeśli chcą - wyślij neutralną wiadomość e-mail wyjaśniającą, gdzie był problem, a ci, którzy znają system, mogą dowiedzieć się, kto go spowodował, nie potrzebujeszżeby to podkreślić
Zgoda też.Z własnego doświadczenia wynika, że zwykle winien jest facet bardziej zainteresowany znalezieniem kogoś, kogo można by obwinić, niż rozwiązaniem problemu.Zakładając, że twoi menedżerowie nie są głupcami, już wiedzą, kto zawalił.
„Ponieważ inni zajmą się tym” zależy, wiele osób, zwłaszcza wyższych, nie patrzy na rozwiązany problem.
W biznesie jest takie powiedzenie - „Własny błąd”.Nawet jeśli tak naprawdę nie był twój, * włożyłeś * wysiłek, aby go rozwiązać, więc absolutnie powinieneś posiadać dodatkowy czas i wysiłek, który włożyłeś, aby to naprawić. Nie musisz przede wszystkim wskazywać palcem na tego faceta, który popełnił błąd - po prostu pamiętaj, że się tym zająłeś.
Zgadzam się z @DonQuiKong.Inni mogą, ale nie muszą, zajrzeć do tego.Ale brzmi to tak, jakby wspomnienie, gdzie był błąd, prawdopodobnie wyjaśni, że zrobił to on, a nie ty.Ale zgadzam się również z innymi uwagami, że kierownictwo / udziałowcy będą pod większym wrażeniem faktu, że poświęciłeś dodatkowy czas na naprawę, niż z czyjej to było winy.
Aby zaspokoić potrzebę zemsty, zignorowałbym "przepraszam za całą przerwę, ponieważ zajęło mi to tak długo, że błąd nie był w kodzie, nad którym pracuję, ale okazało się, że jest w tym innym fragmencie”.
Dobre pytanie, a odpowiedź jest trafna.Chciałbym tylko dodać kilka centów.Z mojego doświadczenia wynika, że kiedy ludzie stają się tak agresywni, zwykle oznacza to, że są winni.Tak więc wszyscy ludzie, którzy byli świadkami tego, wiedzą, że jest to duża możliwość, więc wysłanie komunikatu o tym, jaka była pierwotna przyczyna, jak to zostało naprawione i jak można temu zapobiec w przyszłości bez celowania w jego głowę, byłoby właściwe i wszyscywyciągnęliby właściwe wnioski i odpowiednio dostosowaliby swoje postrzeganie.
Wszystko to było bardzo pomocne, dziękuję wszystkim za wtrącenie się. Myślę, że byłem trochę zdenerwowany tym incydentem, więc niektóre rozsądne reakcje są właśnie tym, czego potrzebowałem.Zrobiłem dokładnie to, co zasugerowałem w tej odpowiedzi (co znajduje odzwierciedlenie w wielu innych odpowiedziach, przepraszam, że mogę zatwierdzić tylko jedną jako „poprawną”): Wysłałem e-mail z linkiem do mojej prośby o wycofanie, więc istnieją dowodydla wszystkich do zobaczenia.Czuję się dobrze, nie wskazując palcami i nie pozwalając innym, jeśli chcą, dowiedzieć się, gdzie leży prawdziwy problem.Jeszcze raz dziękuję.
@Džuris Jeśli używane jest CV, zakończyłbym stwierdzeniem „[...] pracuję nad; zostało wprowadzone w rewizji # 9987”.
Nie możesz tego odpuścić bez wskazania, że to nie był twój kod, ale jego kod.Zrobienie tego bez wskazywania palcem na osobę odpowiedzialną pozostawi na ludziach złe wrażenie.Mój komentarz byłby inny, gdyby drugi facet nie kwestionował twoich umiejętności.
Nikt nie zajmie się tym.Ktoś zostanie przydzielony do naprawy, ale to wszystko.Kierownika nie będzie obchodziło, skąd się wzięło i prawdopodobnie nawet pomyśli, że to Ty jesteś za to odpowiedzialny.Nawet jeśli jest sprawny technicznie, nie będzie miało znaczenia dla tego, kto spowodował problem, tylko, że został on rozwiązany. Najlepsze, co możesz zrobić, to wyjaśnić, kto był za to odpowiedzialny, ale bez wyraźnego użycia jego nazwiska. Inną opcją jest zareagowanie na zachowanie osoby jako głównej kwestii, a następnie odniesienie się do tego, jak obwiniał cię o coś, ale w rzeczywistości to on był tego przyczyną.
Mimo to chciałbym zamienić spokojne słowo z kolegą i dać mu do zrozumienia, że nie jest fajnie zacząć wskazywać palcami i poniżać mnie z przodu, jeśli drużyna, i że następnym razem, gdy to zrobi, może spodziewać się poważnego problemu z rękami.
To, co bym zrobił, to zawrzeć tekst „został wprowadzony w wersji 123 strony internetowej” i połączyć ten tekst z interfejsem sieciowym kontroli źródła, który jasno określa, kto to popełnił.Oczywiście, jeśli masz taki interfejs sieciowy.
@DonQuiKong Absolutnie przyjrzą się temu, jeśli jest to wada powodująca zakłócenia.Biznes prawdopodobnie zamówi przynajmniej raport.
@PieterB Możesz powiedzieć, że to nie był twój kod, bez wyraźnego wskazania, czyj to był kod.Josef sugeruje, jak bym to zrobił osobiście (to znaczy zanotuj i link w narzędziu do śledzenia błędów, która wersja kodu spowodowała problem. - Poza tym jest to po prostu dobra praktyka do celów dokumentacyjnych, tak czy inaczej, nawet jeśli to był kodsam napisałeś.)
Jeśli ta osoba (lub ktokolwiek inny) zachowuje się w ten sam sposób podczas spotkania, możesz po prostu powiedzieć, że zaktualizujesz wszystkich, gdy tylko znajdziesz i naprawisz problem.To oczywiście oznacza, że być może będziesz musiał publicznie przyznać się do popełnionych błędów, ale nie powinno to stanowić problemu.
Aby naprawdę było jasne, nawet dla najbardziej leniwych odbiorców, dołącz coś w stylu „ten błąd został wprowadzony w zatwierdzeniu r456, co spowodowało ”.Facet stawiający fałszywe oskarżenia będzie wiedział, że to jego kod w różnicy, a każdy, kto chce sięgnąć głębiej, może łatwo sprawdzić system kontroli wersji i zobaczyć, kto dokonał tego zatwierdzenia.
user44108
2018-03-09 12:23:45 UTC
view on stackexchange narkive permalink

Unikaj obwiniania

Zawsze będą problemy, zdarzają się błędy, pojawiają się okoliczności, które oznaczają, że usługa X nie jest już zadowolona z usługi Y.

Czego wszyscy potrzebują Skoncentruj się na rozwiązaniu problemu bez wciągania się w obwinianie. Pozwól ekspertowi zajrzeć się i zdiagnozować problem, a następnie rozwiązać problem.

Problem nie dotyczy (oficjalnie) kogoś innego - jest to problem z usługą Y, która ma własnego eksperta w tej dziedzinie aby rozwiązać problem.

Potem są „wyciągnięte wnioski”, aby spróbować dowiedzieć się, co spowodowało problem.

Nie „kto”. To jest kluczowa rzecz. Jeśli ludzie chcą wziąć na siebie winę, to honorowa rzecz.

W takim przypadku nie podejmuj działań odwetowych, nie daj się wciągnąć w grę z obwinianiem, bądź wdzięczny że problem został zidentyfikowany i rozwiązany.

Sugerujesz, aby całkowicie zignorować wskazywanie palcem lub powiedzieć drugiemu facetowi, aby też tego nie robił?
Na tym polega problem z memem „unikaj obwiniania”.Zwykle zdarza się, że jedna osoba kogoś obwinia, a kiedy ktoś mówi „hej, to nie ja”, pierwsza osoba wraca i mówi „nie dajmy się wciągnąć w grę w obwinianie”.Wiele osób głęboko zaprzeczających za pomocą flipchartów mówi miłe i puszyste rzeczy o komunikacji, „wyciągniętych lekcjach” i innych rzeczach, ale w rzeczywistości powinieneś postępować właściwie (nie winić innych za swoje błędy) * ponieważ * tak jest dobrze(nie oczekując nagrody) i wysysaj ją najlepiej, jak potrafisz, gdy inni nie zachowują się, ponieważ praca przynosi ci pieniądze.
@user6697063 Rozumiem, o co ci chodzi.ale wina gry to całkiem niedojrzałe rzeczy na placu zabaw.Kuszące jest obwinianie ludzi za popełnione błędy, ale dojrzała rzecz to skoncentrowanie się na samym problemie i wyciąganie wniosków z każdego błędu, który go spowodował.Ten, kto spowodował problem, powinien być na tyle dojrzały, aby przyznać się do tego (choćby przed sobą) i ruszyć dalej.MÓJ obecny zespół nie przestrzega kultury obwiniania, po prostu się dogadujemy i załatwiamy sprawy.
@Snow Mówisz, że to całkiem niedojrzałe rzeczy na placu zabaw, ale jeśli menedżer OP utkwi w ich głowie, że OP nie może polegać, ma to wpływ na ich karierę.Ogólnie rzecz biorąc, jest to fajna zasada, ale jeśli twoje umiejętności są publicznie kwestionowane, myślę, że musi nastąpić jakiś sprzeciw, w przeciwnym razie może się to powtarzać.
Innym sposobem ujęcia tego, co jest „winą” jest * proces *.Albo * wiele * osób jest „winnych”, albo masz proces, w którym błąd jednej osoby może spowodować poważny problem w produkcji, w którym to przypadku cały zespół jest „winny”.Obwinianie osoby za błąd nie powstrzyma jej (ani nikogo innego) przed popełnieniem kolejnego błędu w przyszłości.Dowiedzenie się, jak ulepszyć proces, aby nieuniknione błędy stały się niepowodzeniem produkcyjnym, jest jednak zarówno konstruktywnym dialogiem, jak i wartością biznesową.
@snow Moje zwykłe podejście, jeśli obwiniają mnie ludzie mający zwyczaj wskazywania palcami, to po prostu powiedzieć, gdzie moim zdaniem leży wina, pozwolić im powiedzieć „nie grajmy w grę w winy”, a następnie żyć dalej.W ten sposób inni mogą decydować.Problem z pozwoleniem na to polega na tym, że możesz w końcu zdobyć reputację wycieraczki wśród ludzi, którzy chcą przekazać swoje błędy, a kiedy osiągnie masę krytyczną, ludzie, którzy nie wiedzą, co się dzieje, zakładają, że praca jest kiepskajakość, nawet jeśli cię nie znają, i staje się legendą.Zwykle wystarczy początkowe wyzwanie, aby zatrzymać tę spiralę.
@DerekElkins Po latach pracy z kimś, kto tak mówił, * nie *.Czasami * to * wina osoby.Ponieważ szczególnie w oprogramowaniu występują poważne wady projektowe, po prostu głupie wiersze kodu oraz pełne i całkowicie błędne zrozumienie napisanego kodu.Chociaż nie potrzebujemy żadnego publicznego zawstydzania, muszą przyznać (przynajmniej mentalnie), że schrzanili sprawę i wyciągnąć z tego wnioski.Żaden proces nie naprawi wszystkiego.Czasami po prostu trzeba mieć kompetentnych ludzi, a ludzie nie stają się kompetentni bez wzięcia odpowiedzialności za swoje złe decyzje.
@Snow to miłe, jeśli działa dla Ciebie, ale to nie działa wszędzie.W sytuacji OP, on / on jest publicznie wywoływany przed osobami spoza zespołu i obwiniony.Jeśli wróci z sekcją zwłok w neutralnym brzmieniu, powszechnym rezultatem jest to, że ludzie niezbyt zaangażowani (np. Menedżer wysokiego szczebla) mogą pomieszać pomysł OP, ale przynajmniej go naprawią.
Winię cię @Snow
Gry z obwinianiem niszczą morale i prowadzą do toksycznej kultury.Nigdy nie baw się z tym.
Akshay Arora
2018-03-09 16:41:44 UTC
view on stackexchange narkive permalink

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

Oto moja rada. Napisz e-maila, opisz, na czym polegał problem, w jaki sposób doszedłeś do pierwotnej przyczyny, jakie było ostateczne rozwiązanie tego problemu i jak można temu zapobiec w przyszłości. Uwzględnij wszystkich interesariuszy w tej wiadomości.

Na końcu tej wiadomości napisz coś w tych wierszach,

XYZ,

Czy mógłbyś 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 wzywasz że jest właścicielem tego fragmentu kodu i dlatego jest za niego odpowiedzialny. Wywołanie jest ważne, ponieważ nie każdy (szczególnie kierownictwo wyższego szczebla) otworzy jakiekolwiek linki do bazy kodu, aby zobaczyć, czyje to było zatwierdzenie.

Trochę surowe, ale zasługuje na to.

Najlepsza odpowiedź do tej pory IMO.Pomysł poproszenia o dokumentację jest całkiem dobry.
Podoba mi się pomysł dodania notatki dla „XYZ ...”
W większości miejsc, w których pracowałem, ktoś rzeczywiście patrzy na kod, zwłaszcza jeśli wystąpiły rzeczywiste problemy / awarie użytkowników.Jeśli nie, zwykle pytają kogoś, kto ma.Nie wydaje mi się, żeby wzywanie było potrzebne i wolałbym tego nie robić, chyba że znowu się pojawi i zacznę się tym przejmować.
Guy Schalnat
2018-03-09 18:58:32 UTC
view on stackexchange narkive permalink

Zbudowałem swoją 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ę siebie, sprowadzi cię na swój poziom i pokona cię doświadczeniem.

Jeśli możesz go znaleźć, potrzebujesz mistrza. W idealnym przypadku powinien to być Twój menedżer, ale czasami jest to inny szanowany programista. Będą bić, żebyś uciszył głośnego. Wszystko, co musisz zrobić, to przeprowadzić z nimi prywatną dyskusję na temat faktów (a nie winy) tego, co zrobiłeś, aby rozwiązać problem i jak chcieliby, abyś postąpił, aby następnym razem coś było nie tak z usługą, problem można szybciej znaleźć i naprawić. Może to wymagać napisania małego narzędzia do testowania, które bezpośrednio testuje usługę (bez użycia kodu innych programistów) lub jakiegoś logowania lub czegoś podobnego, aby problem „my kontra oni” można było bardzo szybko określić. Jeśli wiedzą, kto naprawdę zawinił, mogą oczyścić twoje imię bez bezpośredniego konfliktu z głośnym.

Zawsze stawałem na głowie, aby uniknąć narażania innych programistów na obronę. Powiedziałem na przykład: „Mam problem z powieleniem problemu. Czy możesz mi powiedzieć, jakie połączenia dzwonisz do usługi i co otrzymujesz, abym mógł poprawnie przetestować usługę”? Jeśli programista zadaje sobie trud, aby podać ślady dziennika z rzeczywistych wywołań i odpowiedzi, zapytaj, czego się spodziewał. Jednak w większości przypadków programista po prostu pokaże Ci swój kod. W takim przypadku czasami można zauważyć problem. Nawet jeśli to zrobisz, nadal ich nie wzywaj. Muszą sami znaleźć problem. Niech uruchomią kod za pomocą debugera i niewinnie zapytają, co dana zmienna zawiera w określonej linii kodu. Mógłbym kontynuować, ale masz pomysł.

Najlepsza rada tutaj.Radzenie sobie z kodem jest podobne do rozwiązywania problemów z postami tutaj na SE;jeśli pozwolisz, aby rzeczy zostały spersonalizowane, wszyscy przestaną słuchać innych.
Michael Kay
2018-03-09 22:52:11 UTC
view on stackexchange narkive permalink

To bardzo dobra tradycja w branży IT (i niektórych innych, takich jak lotnictwo), że gdy ktoś znajdzie problem, wszyscy współpracują, aby znaleźć rozwiązanie, a najlepiej, aby znaleźć pierwotną przyczynę, aby usprawnić procesy, ale nikt nie ponosi osobistej winy ani nie ponosi kar za popełnienie błędu. W rezultacie ludzie są otwarci i szczerzy co do swoich błędów, zamiast próbować je ukrywać, co jest korzystne dla wszystkich.

Wygląda na to, że w Twoim sklepie są osoby, które nie kupiły do tej kultury i to wymaga uwagi kierownictwa.

OP twierdzi, że rozmawiano z 8 osobami, a obecnych było co najmniej 2 programistów.Jednym z omawianych tematów była słaba komunikacja, a wszystko to podczas nieudanej produkcji.Dopiero * wieczorem * OP był w stanie skutecznie przeanalizować problem.Obwinianie nie jest najpoważniejszym problemem tej „kultury”.
LVDV
2018-03-09 18:05:33 UTC
view on stackexchange narkive permalink

Uważam, że powinieneś porozmawiać ze swoim przełożonym na temat tego, jak rozwiązywane są problemy, zwłaszcza kwestie priorytetowe, które mają wpływ na wygodę użytkownika.

W tym przypadku masz 2 systemy komunikujące się ze sobą i nagle komunikacja przestaje działać. W przypadku niepowodzenia komunikacji ważne jest, aby obie strony spojrzały na oba systemy. Wszyscy skupiają się na Twojej usłudze, prowadząc ich do tego, aby nie badali spraw po ich stronie. Największą stratą czasu na rozwiązywanie problemu jest próba ustalenia, co jest nie tak z częścią , która faktycznie działa tak, jak powinna .

Są to jednak doświadczenia edukacyjne. Założę się, że teraz doskonale wiesz, jak rozwiązać problem z usługą. Spróbuj skonfigurować plan rozwiązywania problemów w oparciu o swoje doświadczenie i wykonaj jeden z pierwszych kroków, aby upewnić się, że to faktycznie Twoja usługa nie działa („Czy usługa działa, gdy jest wywoływana z innej strony?”, „Czy usługa częściowo zawodzi, czy całkowicie?"). Jesteś serwisantem internetowym, możesz mieć trochę zaufania do swojej pracy.

Spróbuj zapomnieć o tym, że w rzeczywistości zawiódł jego kod. Próba wezwania go do tego jest trochę małostkowa. Od samego początku nie powinien skupiać się tak bardzo na tobie. Postrzegaj to jako ogólny problem w firmie związany z rozwiązywaniem problemów i załatw go jako taki ze swoim przełożonym. Nie wiesz też, czy to faktycznie był jego kod, mógł też skopiować go z innej sekcji napisanej przez kolegę.

Tak, w idealnym świecie ta usługa sieciowa byłaby objęta zestawem testów, a uruchomienie tego pakietu byłoby pierwszym miejscem, do którego należy się zwrócić.Jeśli testy zakończą się pomyślnie, oznacza to, że (a) błąd klienta, (b) błąd usługi nie został przechwycony przez testy, tj. Błąd testowania, (c) usługa działa zgodnie z przeznaczeniem, ale nie zgodnie z oczekiwaniami klienta, tj., błąd dokumentacji.
To dobra rozmowa, będę musiał zajrzeć do jakiegoś stanowiska testowego dla usługi.Jest to dość popularna i solidna usługa, więc szczerze mówiąc, nie sądzę, aby kiedykolwiek był to problem z błędami, a raczej kwestia poprawnej konfiguracji.Niezależnie od tego, to moja domena, więc byłoby wspaniale pokryć moje bazy, gdy następnym razem tak się stanie.Ale z drugiej strony dowiedziałem się więcej o tej domenie, wraz z zestawem kodu „AB”, który współdziała z moją domeną, więc lepiej mi to zrobi.
Kopiowanie kodu, którego nie rozumiesz, jest niewłaściwe, nawet jeśli nie zawiera błędów.A jeśli jest w tym samym projekcie, kopiowanie go zamiast nazywania jest niewłaściwe.
William Jockusch
2018-03-11 17:54:45 UTC
view on stackexchange narkive permalink

Myślę, że propozycja rozmowy z przełożonym jest dobra. Twój przełożony musi wiedzieć, że zostałeś oskarżony niesłusznie.

Ale poza tym jesteś testowany. Twój początkowy instynkt ma rację; musisz zareagować, albo będzie gorzej. Wysyłałem mu e-maila bezpośrednio i informowałem go, że problem tkwi w jego kodzie i że tym razem nie powiedziałeś nikomu poza swoim przełożonym, któremu musiałeś powiedzieć, aby się chronić. I na koniec daj mu znać, że jeśli zrobi to ponownie, ujawnisz się publicznie.

To tylko pogorszy problem, nie zgadzam się z twoją radą
Prywatny atak nadal jest atakiem i tak, zaostrzy sytuację.Działania naprawcze powinny być zgodne ze schematem dowodzenia.
Bardziej „proporcjonalna odpowiedź”.Miałem takie sytuacje;jeśli ktoś nie reaguje, ma tendencję do pogarszania się.Łańcuch dowodzenia może zadziałać.Może, a może nie.To, co mogę powiedzieć, to to, że z własnego doświadczenia widziałem, że zawodziło to dwa razy i raz odniosło sukces.Problem polega na tym, że czekając, aby się dowiedzieć, sytuacja może się pogorszyć.
Korthalion
2018-03-12 15:27:31 UTC
view on stackexchange narkive permalink

Jako tester oprogramowania znam tę sytuację. A także jako tester oprogramowania, dlaczego ten błąd nie został wykryty podczas testowania? Zakładam, że jesteś programistą?

Tak, szkoda, że ​​obwinia Cię facet, który spowodował problem. Jednak to NIE jest to, na czym firma będzie się troszczyć. Jedyne, czego chcą, to rozwiązanie, w którym nie będzie już więcej osób, które przerywają wyświetlanie reklam, na aktywnej stronie.

Poczekałbym do następnej telekonferencji, jeśli masz ich regularnie, i wspomnę, że przeanalizowałeś główną przyczynę problemu i obiektywnie przedstaw swoje ustalenia. Jeśli zapytasz, kto napisał ten kod, powiedz, kto to był, w przeciwnym razie nie wskazuj palcem na faceta, który to zrobił. Powinieneś być bardziej dojrzały / profesjonalny i zdobędziesz dużo więcej szacunku, jeśli poradzisz sobie z sytuacją w taki sposób.

Aby zapobiec ponownemu występowaniu tego problemu, zapytaj, jak to się potoczyło. w sposób nieoskarżający i pracuj z nimi nad wdrożeniem nowego kroku lub testu, który pozwoliłby rozwiązać problem.

Na koniec zgłoś to wszystko swojemu przełożonemu. Wady korka pokazowego to poważna sprawa, a jego wyżsi ludzie również będą oddychać w dół jego szyi.

Paddy
2018-03-14 15:25:16 UTC
view on stackexchange narkive permalink

Trochę spóźniłem się z tym pytaniem, ale obok bardzo rozsądnej rady zawartej w odpowiedzi Edgara jest jeszcze druga część.

Jeśli wyślesz wiadomość, że znalazłeś problem i zauważ, gdzie został rozwiązany, wtedy inni programiści prawdopodobnie będą świadomi, gdzie leży problem (to dobrze), ale kierownictwo prawdopodobnie nie.

Zrobienie tego w ten sposób oznacza, że ​​zrobiłeś temu facetowi przysługa - wezwał cię publicznie, znalazłeś problem, naprawiłeś go i nie wrzucił go do niego kierownictwo. Budowanie takiego zaufania ze współpracownikami zapewni Ci dobrą pozycję na dłuższą metę.


Mała uwaga - to oczywiście zależy w niewielkim stopniu od charakteru błędu, jaki znajdujesz w ich pracy . Jeśli stwierdzisz, że jest tak rażąco błędne, że wskazuje na niekompetencję z ich strony, możesz po cichu przekazać to swojemu przełożonemu - będzie chciał wiedzieć, a Ty również budujesz zaufanie.

Jeśli go nie ujawnisz, inni prawdopodobnie to zrobią.Chyba że oni wszyscy są jego „kumplami”, w takim przypadku jesteś historią pomimo swojej niewinności.
Kevin Olree
2018-03-11 09:17:34 UTC
view on stackexchange narkive permalink

Sugeruję, abyś przespał się z tym, zanim zareagujesz na osobiste aspekty sytuacji. Jeśli rozwiązałeś problem i wszystko działało ponownie, nadal jesteś „człowiekiem”. Po odpoczynku będzie łatwiej być łaskawym.

André Werlang
2019-03-07 05:49:19 UTC
view on stackexchange narkive permalink

Chociaż główny problem został już obszernie omówiony w innych awswersach - inny facet cię nęka - chciałbym zwrócić uwagę na inną perspektywę.

Poprawka została wykonana w kodzie należącym do drugiego faceta , jednak najczęściej usługa mogła zapobiec poważniejszemu problemowi, będąc bardziej konserwatywną w obsłudze wniosków klientów. Czy sprawdza poprawność danych wejściowych? Czy zgłasza jakieś błędy w czasie wykonywania? Czy istnieje środowisko testowe (dotyczy to również konsumenta)? Czasami problem w usłudze tylko czekał na pojawienie się, więc powiedziałbym, że tylko dlatego, że naprawa została wykonana w jednym miejscu, nie oznacza to, że to cała historia. Ponadto w przypadku takich problemów jest coś więcej niż tylko kod. Jest też proces.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...