Mój szef postanowił dodać pole „osoba do winy” do każdego zgłoszenia błędu. Jak mogę go przekonać, że to zły pomysł?

695

W jednym z najnowszych ruchów „WTF” mój szef zdecydował, że dodanie pola „Osoba do winy” do naszego szablonu śledzenia błędów zwiększy odpowiedzialność (chociaż już mamy sposób wiązania błędów z funkcjami / historiami). Moje argumenty, że zmniejszy to morale, zwiększy wskazywanie palcem i nie będą uwzględniać brakujących / źle zrozumianych funkcji zgłoszonych jako błędy, stały się niespotykane.

Jakie są inne mocne argumenty przeciwko tej praktyce, z których mogę skorzystać? Czy jest coś na ten temat, który mogę udostępnić zespołowi i szefowi?

MK_Dev
źródło
79
Cześć, jestem „szefem”, który wprowadził pole WTF. Oto dlaczego dodałem pole „Peson do winy” do naszego systemu śledzenia błędów: news.ycombinator.com/item?id=4179298
Jason
98
„Czy mógłbym nazwać to czymś bardziej politycznie poprawnym, aby uczucie nie doznało urazu? Jasne. Ale co w tym jest fajnego? Chodziło o to, aby uświadomić sobie liczbę błędów produkcyjnych po każdym wydaniu, więc dlaczego nie wrzucić małej dawki publicznego wstydu dla jasności? A dla jasności, celem pola, a ostatecznie celem metryki, nie jest wskazanie przyczyny błędu. Cholera się dzieje i mamy lepsze rzeczy do zrobienia. Ostatecznym celem dane są przypomnieniem, że każdy programista powinien być lepszy każdego dnia ”. --- Myślę, że wszystkie te „powody” są z natury błędne.
ulty4life
31
@Jason zamiast wymyślać pola Jira, rozważ zatrudnienie jednego lub dwóch testerów . BTW w twoim przypadku posiadanie pola przyczyny źródłowej (bez względu na to, jak go nazwiesz) wydaje mi się mało ważne, ponieważ już zasugerowałeś połączenie między nieobecnością testerów a wzrostem błędów produkcyjnych .
komara
68
@Jason Błąd znajduje się w kodzie, a nie u programisty. Musisz być jedną z osób, które uważają, że recenzje kodu służą do recenzowania programistów, a nie kodu.
Danny Varod
81
Twój szef jest „osobą winną”, zawsze wypełniaj jego imię i zobacz, jak mu się podoba;)
dukeofgaming

Odpowiedzi:

676

Powiedz im, że jest to tylko amatorska nazwa pola Przyczyna pierwotna używana przez profesjonalistów (gdy narzędzie do śledzenia problemów nie ma dedykowanego pola, można do tego użyć komentarzy).

Szukaj w internecie na coś takiego analizy błędów oprogramowania korzeń przyczyny , istnieje wiele zasobów, aby uzasadnić to rozumowanie 1 , 2 , 3 , 4 , ... .


... podstawową przyczyną wady nie zawsze jest pojedynczy programista (co jest głównym punktem tego pola) ...

Właśnie dlatego „podstawowa przyczyna” jest profesjonalna, podczas gdy „osoba do winy” jest amatorska. Osobista odpowiedzialność jest świetna, ale zdarzają się przypadki, gdy po prostu leży ona „na zewnątrz” zespołu programistów.

Powiedz swojemu szefowi, kiedy jest winien jednego programistę, pole przyczyny źródłowej na pewno to obejmie ( „błąd kodowy popełniony przez Boba w zatwierdzeniu 1234, pominięty przez Jima w recenzji 567” ). Punktem użyciu termin przyczyny jest pokrycie takich przypadkach, że wraz z przypadkami, które wykraczają poza zakres zespołu dev.

Na przykład, jeśli błąd został spowodowany przez wadliwy sprzęt (osoba obwiniająca jest kimś spoza zespołu, który go kupił i przetestował), pole przyczyny źródłowej pozwala to pokryć, podczas gdy „pojedynczy programista ponosi winę” proces śledzenia problemów .

To samo dotyczy innych błędów spowodowanych przez osobę spoza zespołu programistów - błędy testera, zmiany wymagań i decyzje zarządcze. Powiedzmy, że jeśli kierownictwo zdecyduje się pominąć inwestowanie w sprzęt do odzyskiwania po awarii, „obwinianie jednego programisty” za awarię elektryczności w centrum danych po prostu nie miałoby sensu.

komar
źródło
13
To dobra uwaga. Jednak podstawową przyczyną defektu nie zawsze jest pojedynczy programista (co jest głównym punktem tego pola). W rezultacie zidentyfikowanie jednego dewelopera odpowiedzialnego za wadę wyrządza więcej szkody niż pożytku, IMO.
MK_Dev
326
+1 za przekierowanie pomysłu szefa na coś bardziej produktywnego (zawsze łatwiej wygrać bitwę w ten sposób)
benzado
16
„Przyczyna główna” obejmuje także (mam nadzieję, że większość!) Przypadki, w których nie można winić żadnej osoby, takie jak „awaria oprogramowania dostawcy”, „błąd dokumentacji API”, „wyższy wolumen niż oczekiwano”.
James Anderson
29
Wspaniały. Nawet twój przykład jednej osoby odpowiedzialnej obejmuje dwie osoby, co doskonale ilustruje głupotę ćwiczenia.
Urs Reupke,
15
Nie zapominaj, że „przyczynowe przyczyny” byłyby również przydatne, ponieważ często łatwiej jest coś z tym zrobić. Na przykład, jeśli „podstawową przyczyną” było „błąd kodowania w zatwierdzeniu 5678” i „przyczyna przyczynowa” to, że „zatwierdzenie 5678 nie zostało sprawdzone, ponieważ wymagania pojawiły się zbyt późno”, to nie można uniknąć wszystkich błędów kodowania, ale można być bardziej surowym opóźnienie dostawy następnym razem wymagania są opóźnione.
Jan Hudec
272

Innym prawdopodobnym rezultatem takiej polityki jest to, że ludzie nie zgłaszają błędu, jeśli myślą, że może być „osobą winną”, więc faktycznie zmniejszy to liczbę błędów zgłoszonych przez zespół.

Laurent Parenteau
źródło
300
Cóż, szef będzie szczęśliwy! Będzie mniej zgłoszeń błędów, dlatego jakość musiała wzrosnąć.
nicodemus13
5
Szef prawdopodobnie zarabia na wydajności, a jednym z kluczowych wskaźników wydajności jest liczba zgłoszonych błędów. Mamy nadzieję, że pod koniec roku podzieli się swoją premią z zespołem programistów.
Matt Wilko
54
Z doświadczenia wynika, że ​​nie jest to „prawdopodobny” wynik, jest w 100% absolutnie pewne, że tak się stanie, ponieważ programiści to mądrzy ludzie. Zobaczysz także znaczny wzrost czasu spędzonego na gwałtownym kłótni z testerami, że ich „błędy” nie są błędami.
Joris Timmermans
Osoba zgłaszająca błąd prawdopodobnie nie będzie osobą, o root causektórej myślę, próbując znaleźć błąd we własnym kodzie po 36 godzinach pisania kodu w tym tygodniu?
Malachi
141

Głównym argumentem, którego użyłbym przeciwko niemu, jest pytanie, jaki problem próbuje rozwiązać. Istnieją prawie na pewno lepsze sposoby rozwiązania tego samego problemu.

Po pierwsze, czy naprawdę można winić tylko jedną osobę? Jeśli tak, robisz coś innego źle. Dobry proces wymaga pracy analityka, programisty, recenzenta i testera, zanim trafi do produkcji. Jeśli nie wykonujesz wszystkich tych etapów, być może jest to rozwiązanie problemu, który twój szef próbuje rozwiązać. Jeśli to ty jesteś winien? Może to nie być żaden z nich, może to być winny stary kod.

Nie jest dobrze mieć ludzi gryzących i wskazujących palcami, starających się unikać czarnego znaku, który nie zniknie po ustawieniu. Nic nie rozwiązuje. Bardzo niewiele osób jest złośliwie zaniedbanych. Musisz zrobić odpowiednią retrospektywę , zobaczyć, co poszło nie tak i co możesz zrobić, aby upewnić się, że to się nie powtórzy.

Dzięki temu wyraźnie zobaczysz, czy jedna osoba regularnie ponosi winę i może to być inny problem do rozwiązania.

Sztuką powstrzymania menedżera przed tworzeniem rozliczalności jest zaoferowanie jej za darmo , ale w sposób, który ma dla ciebie sens.

pdr
źródło
5
Naprawdę dobry proces pozwala uniknąć sytuacji, w której analityk i programista są dwiema różnymi osobami - moje doświadczenia z analitykami, którzy nie potrafią programować i programistami, którzy nie potrafią analizować, były naprawdę złe. Niemniej jednak +1 za twoją odpowiedź.
Doc Brown
@DocBrown dobrze moje dotychczasowe doświadczenia z analitykiem i programistą, aby być dwiema różnymi osobami, były raczej pozytywne. Chociaż w moim przypadku raczej analitycy rozumieli logikę programu, a programiści mogli brać udział w analizie :)
gnat
@gnat: IMHO zatrudniające analityka jako jednego z programistów w zespole może poprawić szybkość i jakość programowania o rząd wielkości.
Doc Brown
3
Ta książka pomoże ci znaleźć słowa, które pozwolą ci
przetrwać
2
Link do „oferuj to za darmo” jest zerwany.
Tom Fobear
79

Istnieją co najmniej trzy problemy z tym polem.

Po pierwsze, obwinianie ludzi nie jest dobre dla morale. Dobrze. Ale może nie dba o morale i chce zwalniać złych programistów. Trudno się kłócić.

Drugim jest to, że poprawne ustawienie tego pola będzie trudne i utonie. Jest to bardziej skomplikowane niż tylko ustalenie, kto napisał zły kod. A wszelkie potencjalnie trudne do zrozumienia informacje mogą być worek z piaskiem / oszukiwany. Ale może jest przygotowany na pokrycie tych kosztów i sprawdzenie informacji. W porządku.

Bardziej fundamentalną kwestią jest to, że ta dziedzina nie będzie dobrym miernikiem do podjęcia działań. Jasne, będzie miał dobry ranking, którego kod powoduje najwięcej błędów. Ale zgadnij, kto będzie na szczycie tej listy? Prawdopodobnie założyciel firmy, a może główny programista, który ma bardzo niski wskaźnik wad, ale jest tak produktywny, że pisze nieproporcjonalną część kodu. Więc albo zwolni swojego najlepszego programistę, albo spowolni go tak bardzo, że nie jest już najlepszym programistą. A facet, który pisze miesięczny wiersz kodu - najlepiej komentarze - prawdopodobnie zostanie wynagrodzony za swoje niskie liczby wad.

Kolejna awaria metryki oprogramowania.

ptyx
źródło
16
Dziwi mnie, że nikt inny nie wspominał o tym, że analiza historii błędu w próbach przypisania winy będzie ogromnym pochłaniaczem czasu. Jeśli żadne inne argumenty nie gryzą, to powinno.
CVn
Więc naprawicie błędy, nie próbując poznać historii i przyczyny? W tym momencie naprawiasz objawy i prawdopodobnie ignorujesz uzasadnione podstawowe problemy. Jeśli rzeczywiście jest to problem z osobą, pomaga dowiedzieć się, dlaczego ta osoba popełniła błąd, aby można go było naprawić. Jeśli jest to wadliwy sprzęt, można go zamienić na coś bardziej stabilnego.
Jordan
Nie mam nic przeciwko obwinianiu / chwaleniu osób. Ale należy to zrobić bardzo ostrożnie, ponieważ łatwiej jest powodować gorsze problemy, starając się to zrobić, niż pierwotny problem. Pole „sprawcy” nie wygląda na podejście „bardzo ostrożne”.
ptyx
68

Podstawową przyczyną defektu polowego nigdy nie jest jedna osoba. Doskonale sumienni ludzie popełniają błędy, a proces, który oczekuje, że będą nieomylni, jest nieuzasadniony. Jeśli nie weryfikujesz zmian w systemach produkcyjnych przed wdrożeniem, ręcznie lub za pomocą testów automatycznych, błędy są nieuniknione.

Źle:

Bob zapomniał sprawdzić dane wejściowe, a program zawiesił się dzieląc przez zero.

Dobrze:

Kod podatny na błąd dzielenia przez zero nie został wykryty przed wdrożeniem. Dodano nowe przypadki testowe w celu weryfikacji prawidłowej obsługi nieprawidłowych danych wejściowych. Kod został poprawiony i wszystkie nowe przypadki testowe przechodzą.

Kevin Cline
źródło
6
Jeszcze lepiej: zaktualizowano wytyczne / standardy kodowania i listy kontrolne przeglądu kodu, aby uniknąć tego powtórzenia.
Dziwne,
Co jeśli błędy są nieuniknione? Co jest złego w obwinianiu kogoś za nich? Myślę, że opcja „Wrong:” jest bardziej przejrzysta niż opcja „Right:”. Niewłaściwy jest naprawdę prosty. „Właściwy:” jeden jest trudny.
Adam Bruss,
3
@Adam: czy moja odpowiedź nie odnosi się bezpośrednio do twojego pytania „Co jest złego w obwinianiu kogoś…?”
kevin cline
54

Zmień „Osoba do winy” na „Osoba do chwały”

Główna osoba, która naprawia błędy, otrzymuje swoje imię.

Ciemna noc
źródło
9
Nie sądzę, że to odpowiada na pytanie. To dobry sentyment, ale nie dostarcza argumentów przeciwko takiemu polu.
Bryan Oakley,
21
Plus, wiesz, że jeden facet wprowadzi setki błędów „przypadkowo”, a następnie je naprawi, mając nadzieję, że jakiś idiota będzie na tyle głupi, by myśleć, że jest najlepszym
naprawiaczem
Bardzo często chcesz wiedzieć, kto napisał kod i kto jest najlepiej przygotowany, aby go naprawić, jeśli się nie powiedzie. Częścią reakcji „osoby do winy” jest to, że implikuje to, że ktoś jest winny.
Muz.
49

Prosta odpowiedź.

Pole „Obwinianie” będzie wykorzystywane tylko do kozła ofiarnego i wskazywania palcami, morale spadnie, zaufanie drużyny zostanie zniszczone i wszyscy będą próbowali znaleźć sposoby, aby udowodnić, że coś nie jest ich winą, zamiast to naprawić. Ludzie będą też bardziej skłonni do milczenia na temat błędów zamiast zgłaszania ich, ponieważ nie chcą, aby kolega wpadł w kłopoty. Jest całkowicie nieproduktywny.

Co ważniejsze, prześladowanie kogoś za popełnienie uczciwego błędu lub jak najszybsze naprawienie problemu?

Twój szef uważa, że ​​błędy są oznaką lenistwa lub niechlujstwa. Oni nie są. To fakt z życia. Ile poprawek wypycha Microsoft w ciągu roku?

GordonM
źródło
8
+1, kultura winy zawsze prowadzi do kultury milczenia na temat błędów i nadziei, że nikt inny tego nie zauważy
Carson63000,
45

Jeśli masz ochotę na odrobinę nieposłuszeństwa obywatelskiego, poproś zespół o zgodę na umieszczenie listy wszystkich programistów w tym polu dla każdego błędu. Jeśli to nie pasuje, napisz „Jestem Spartakus!” zamiast. Rzecz w tym, że wszyscy jesteście odpowiedzialni za wszystkie błędy i nie jesteście zadowoleni z konieczności wskazywania osoby, która stworzyła jeden błąd.

Inna opcja: graj razem. Nic szczególnego nie rób - po prostu wykonuj dobrą pracę i wypełniaj pole tak dokładnie, jak to możliwe przez kilka miesięcy. Następnie wyjaśnij szefowi, że przypisywanie winy za każdy błąd powoduje, że wszyscy w zespole są nieszczęśliwi i niewygodni. Powiedz mu, że wszyscy czujecie, że istnieje niewielka korelacja między stworzonymi błędami a czymkolwiek innym (umiejętność, wysiłek, zdrowie psychiczne). (Pomoże to w uruchomieniu liczb, które pokazują, że tak naprawdę nie ma korelacji).

Gandhian Civil Nieposłuszeństwo: umieść swoje imię na każdym polu (chyba że inni programiści wystąpią i podadzą swoje błędy) i zaakceptuj winę za każdy błąd, niezależnie od tego, czy jest on twój, czy nie. Nic nie uczyni tego pola ani pomysłu obwiniania kogoś bardziej bezużytecznym. Jeśli twój szef zapyta, dlaczego masz na imię w każdej dziedzinie, możesz wyjaśnić „ponieważ nie uważam, że rozwój jest grą obwiniającą, jeśli naprawdę potrzebujesz ludzi do obwiniania i ukrzyżowania, to ukrzyżuj mnie za wszystko i pozwól mojemu zespołowi pracować spokojnie . ”

Caleb
źródło
15
Głosowałbym za pierwszym akapitem, ale drugi wydaje mi się wątpliwy. Z mojego doświadczenia wynika, że ​​ludzie, którzy w pierwszej kolejności sugerują pomysły, takie jak pole do winy, nie są ludźmi, którzy martwią się, że ludzie będą czuć się niekomfortowo.
GordonM,
@GordonM To naprawdę zależy od osobowości szefa. Facet bez bzdur, cierpiący, nie głupi, może nie patrzeć uprzejmie na podejście Spartacusa, ale nadal może chcieć przyznać, że pole stwarza więcej problemów niż korzyści. Jeśli OP i zespół wykażą, że szanują szefa na tyle, by wypróbować jego pomysł, może szanować ich na tyle, by wysłuchać, gdy później powiedzą mu, że to nie wydaje się pomocne. Co więcej, może wiedzieć coś, czego OP nie wie, na przykład, że około dwóch dziedziczy kilku przegranych z innego zespołu i chce mieć możliwość zebrania niektórych danych.
Caleb
3
Dodatkowo zespół nadal będzie cierpiał. Wszystko po to, żeby udowodnić, że szef się mylił?
Oleg V. Volkov
29
Zawsze umieszczałem tam nazwisko menedżera. „W każdej organizacji praca spada na dno, a odpowiedzialność spoczywa na górze”.
David Schmitt
3
@David: Zarówno krem, jak i szumowina unoszą się do góry. Z czym masz do czynienia w swojej organizacji?
Donal Fellows
32

Kiedyś miałem szefa, który wdrożył system bardzo podobny do tego i chociaż to nie było programowanie (to był projekt do druku dla codziennej gazety) koncepcja i odpowiednia reakcja są takie same.

To, co zrobiła, to zamiast dodania do naszej dokumentacji pola „osoba obwiniająca”, dała każdemu z projektantów zestaw kolorowych naklejek. Każdy projektant otrzymał naklejkę w innym kolorze i został poinstruowany, że w przypadku każdego projektu opracowanego lub nawet dotkniętego nalepkę należy dodać do dokumentacji tego projektu.

Stwierdzonym przez szefa celem „inicjatywy naklejek” było ustalenie źródła błędów wszystkich naszych działów (błędy w dokumentacji, błędy w dokumentacji, złe kopie, w zasadzie odpowiednik błędów w druku)

To, co zrobiliśmy, dało każdemu z pozostałych projektantów jedną czwartą naszych naklejek, dzięki czemu każdy z nas miał wszystkie kolory, i zamiast nałożyć tylko nasz kolor na każdy projekt, umieściliśmy wszystkie cztery kolory projektantów.

Nie wpisuj po prostu swojego nazwiska w polu [Wina] - wpisz imię wszystkich członków zespołu / projektu i upewnij się, że cały zespół robi to samo.

Pracowaliśmy razem przeciwko jej orwiliowskiej suczce, w wyniku czego ostatecznie złapaliśmy się na błędach i rozmawialiśmy o tym, co ostatecznie doprowadziło do znacznego zmniejszenia błędów. Była jednak kiepskim menedżerem i zamiast uznać, że jej inicjatywa nas zjednoczyła i zwiększyła produktywność, załatwiła sprawę i rozwiązała system naklejek, ogłosiła porażkę i formalnie nas wszystkich upomniała.

fifthestei8ht
źródło
1
Twoja była zabawną historią i prawie odpowiada na pytanie. Możesz rozważyć dostosowanie tonu i języka do bardziej pozytywnego odczytu. W przeciwnym razie będziesz nadal krytykowany. (Poparłem twoją odpowiedź.)
Evik James
20

Skończy się to karaniem jego najbardziej płodnego programisty. Szanse są, jedna lub dwie osoby mogą być najlepszymi pracownikami, którzy pracowali przy większości projektów. Jeśli masz, w 10-osobowym dziale, jednego programistę, który jest tylko fontanną wyników i napisał 60% kodu interfejsu, wówczas 60% błędów będzie w jego kodzie.

Wyjaśnij, że ten system wyglądałby tak, jakby osoba, która pisze najwięcej kodu, była najgorszym programistą, a osoba, która pisze najmniej kodu, jest najlepszym programistą.

Bill B.
źródło
20

To brzmi bardzo podobnie, gdy Scott Adams wskazał na nieudaną mądrość Bount Bounty, gdy Pointy Haired Boss w Dilbert. Wally ogłosił, że zamierza pojechać i „napisz mu nowy Mini Van”.

Komiks Dilberta na 13.11.1995 z oficjalnego archiwum komiksów Dilberta.

Pamiętam raz, gdy Snow Skiing ktoś wskazał, że „nie spadanie” nie było oznaką dobrego narciarza, ale często znakiem tego, że niczego nie próbuje (lub tak naprawdę nie jeździ na nartach).

Błędy mogą być wprowadzane do kodu przez złe programowanie i zły projekt; ale mogą też wynikać z pisania wielu trudnych kodów. Dinging ludzi, którzy produkują najwięcej błędów, jest tak samo prawdopodobne dla Ding słabych programistów, jak i tych bardzo produktywnych.

Wygląda na to, że twój szef może być sfrustrowany liczbą wad. Czy ludzie w Twojej grupie pasjonują się jakością? Utworzenie pola „co” dla przyczyny zamiast pola „kto” mogłoby być bardziej produktywne. Np .: Zmiana wymagań, wada projektu, wada implementacji itp. Nawet to się nie powiedzie, chyba że będzie grupa, która poprawi jakość produktu.

Mark Hancock
źródło
19

Może powinieneś spojrzeć na to jako „Kto jest najlepszy, aby naprawić błąd?” Część mnie też czuje, że to zepsułeś, naprawiłeś. Powinna istnieć pewna odpowiedzialność.

Nie zgadzam się z utrzymywaniem jakiegoś wyniku. Niektóre osoby tworzą więcej błędów, ponieważ pracują nad bardziej złożonymi częściami kodu. Jeśli wiersze kodu nie są użyteczną miarą, wątpię, aby błędy w wierszach kodu były lepsze. Kod nigdy się nie zaloguje.

W pewnym momencie menedżer powinien wiedzieć, kto wykonuje swoją pracę, a kto nie, a także kto robi to lepiej, ponieważ robi to reszta zespołu.

JeffO
źródło
19

Dziwne, że nikt wcześniej o tym nie wspominał: dodanie takiej funkcji do narzędzia do śledzenia błędów motywowałoby pracowników do próby grania w system .

Jest to powszechny problem w podejściach takich jak to, jakie przedstawiano pytanie, wśród innych podobnych pomysłów (płacenie według liczby linii kodu, płacenie według liczby błędów). To zachęci wielu do skoncentrowania się na uzyskaniu dobrego wyniku, zamiast rozwiązywania problemów związanych z oprogramowaniem, nad którym pracują.

Na przykład próba przesłania raportu o błędzie ze sformułowaniem mającym na celu zmniejszenie własnej winy i przekazanie go komuś innemu może doprowadzić do nieporozumienia przez programistę przyczyny problemu (lub pracy powierzonej innemu programistowi, który nie zna tej sekcji kod tak dobry jak ten, który nad nim pracował najwięcej i który był główną przyczyną błędu), co prowadzi do dłuższego czasu i wysiłku w celu rozwiązania problemu.

vsz
źródło
18

Twoje prawdziwe pytanie dotyczyło sposobu zmiany kultury przed odejściem z firmy, przekonując swojego szefa, że ​​dodanie osoby do winy za zgłoszenia błędów jest złym pomysłem. Ale oczywiście zmiana kultury wymaga od niego zrozumienia, dlaczego jest to zły pomysł.

To wysokie zamówienie. Oprócz kwestii oszczędzania twarzy po zmianie zdania, istnieje podstawowy problem, że ludzie, którzy myślą o rozwiązaniach przede wszystkim w kategoriach indywidualnej winy, są zazwyczaj dość nastawieni w tym sposobie myślenia.

Poprosiłeś o napisanie na ten temat, a na myśl przychodzi Peopleware . Jest wysoko ceniony i mówi ogólnie o tym, jak zarządzać ludźmi wykonującymi pracę twórczą, w przypadku których wyniki trudno jest zmierzyć. Problem polega na tym, że czytanie tego niewiele pomoże, twój szef musiałby je przeczytać i uwierzyć przynajmniej w część.

Dziwne, skoro problem dotyczy bardziej ludzi niż zgłoszeń błędów, bardzo prawdopodobne jest, że należy on raczej do Workplace niż do programistów. Ale sukces projektów oprogramowania jest zwykle dość ściśle związany z ludzkimi interakcjami społecznymi, więc prawdziwe odpowiedzi często dotyczą głównie rzeczy wykraczających poza oprogramowanie.

Moją jedyną, na wpół poważną, sugestią jest powiedzenie (lub przekonanie współpracownika do powiedzenia, skoro planujesz odejść), że jesteś gotów wziąć na siebie pełną odpowiedzialność za sukces projektu, a twoje nazwisko powinno zawsze iść w teren , ponieważ nawet jeśli ktoś inny popełnił błąd bezpośrednio, wziąłeś na siebie odpowiedzialność za dopilnowanie, aby wszyscy w zespole wykonali dobrą pracę.

Oczywiście, to bzdura, jak mógłbyś to kiedykolwiek zrobić, ale niektórzy ludzie (szczególnie ludzie, którzy są winni) naprawdę jedzą to. Ronald Reagan publicznie akceptował osobistą odpowiedzialność za każdym razem, gdy jakikolwiek członek jego administracji został złapany w skandal (a było ich całkiem sporo) i za każdym razem działało to całkiem dobrze politycznie. Najlepsze jest to, że odpowiedzialność na ogół nie wiąże się z żadnymi faktycznymi konsekwencjami, po prostu myślą, że jesteś facetem stojącym za wzięciem odpowiedzialności.

A może nie tak to się skończy. Nie ma dla mnie żadnego sensu, więc trudno mi przewidzieć, kiedy to zadziała, ale byłem świadkiem, że działa, kiedy wydawało się, że nie ma w tym interesu (w miejscu pracy, nie tylko w przykładzie Reagana).

psr
źródło
+1 za zasugerowanie pozytywnego wyjaśnienia, jak zarządzać pracownikami informacyjnymi, a nie tylko zaatakowanie tego jednego pomysłu.
Dziwne,
14

Ludzie nie chodzą do pracy z zamiarem popełnienia błędów, a żadna ustanowiona strategia, aby szczególnie obwinić za to, co może być błędem ludzkim, jest absurdalna - nie wspominając o wyjątkowo nieprofesjonalnym.

Przynajmniej „strona odpowiedzialna” wyznaczona do przejęcia i „naprawienia” problemu lub przedstawienia planu śledzenia i / lub zapobiegania podobnym zdarzeniom byłaby dobra. Czasami rozwiązaniem jest nic innego jak dodatkowe szkolenie. Pracowałem dla wielu firm, w których było to częścią twojego opisu stanowiska, aby uzyskać wykształcenie „firma opłacona / czas pracy”. W jednym miejscu zbudowano nawet całe „centrum szkoleniowe”, które miejscowa uczelnia „czasami pożycza” na kursy technologii przemysłowych.

Przez ostatnie 20 lat pracowałem w środowisku produkcyjnym, w którym błędy programistyczne nie tylko powodują błędy, fizycznie niszczą rzeczy i / lub gorzej, powodują krzywdę ludzi. Jednak jedną stałą w każdej dziedzinie produkcji, która jest silna, jest to, że w żadnym wypadku nie można nikogo winić. Ponieważ jest to wada systemu, prosta i prosta - a nie wada ludzi. Spójrz na to w ten sposób - użycie sprawdzania pisowni - wysoce skuteczne narzędzie dla tych, którzy mają mniej szczęścia w dziedzinie tekstowej wirtuozerii, a może tylko tych, którzy są nieco przepracowani ... ale w żadnym wypadku nie jest to metoda winy lub odpowiedzialności.

Środowisko pracy, bez względu na to, jakiego rodzaju lub do jakiego celu służy, to system. System złożony z pojedynczych elementów, które właściwie „dostrojone”, działają w całkowitej harmonii - lub w pewien sposób na pozór.

Sugerowana lektura części szefa: 7 nawyków bardzo skutecznych ludzi

Wygląda na to, że przydałby mu się pokora, jeśli nie sprawdzenie rzeczywistości. Jest tak samo częścią zespołu, jak wszyscy inni, i musi zdawać sobie sprawę, że - albo to po prostu nie zadziała, a ostatecznie będzie trzymał torbę niezależnie od tego.

Sugerowana lektura i / lub badania z twojej strony:

Przyjrzyj się 5, dlaczego analiza, analiza przyczyn źródłowych ... wszystko, co stawia cię w lepszej pozycji do zaoferowania rozwiązania, a nie problemu . A twoje spory z szefem to tylko problem, a nie rozwiązanie. Zaoferuj mu coś lepszego, coś, co ma sens, a nawet bądź przygotowany, by pozwolić mu przypisać sobie ten pomysł.

W tej chwili nie wydaje się, żeby był gotów cokolwiek naprawić, ponieważ nie ma głębokiego zrozumienia tego, co jest zepsute, jeśli coś jest w ogóle zepsute - poza jego mentalnością „jestem szefem”.

Powodzenia! Mam nadzieję, że zdołasz sobie z tym poradzić w sposób, który jest akceptowalny dla wszystkich, szczególnie w obecnych czasach.

EDYCJA: Osobiście, z własnego doświadczenia ... „Śmiało, obwiniaj mnie. Bo na pewno naprawię to i zejdę na dół, kiedy to się powtórzy, kto będzie tam, aby uratować dzień? Tak, ty zgadłem ... z wielkim uśmiechem. "

tahwos
źródło
„stawia cię w lepszej pozycji do zaoferowania rozwiązania, a nie problemu”. - tak, który jest głównym punktem tego postu. Nie spodziewałem się, że tak wybuchnie.
MK_Dev
W końcu będzie to albo sukces zespołu, albo porażka zespołu - i bez względu na to, jak będzie przebiegać postępowanie (w tym gra o winy), nie zadziała, a nawet okaże się złym pomysłem, jeśli nie zostanie zrealizowany owocowanie lub awaria. Innymi słowy, alternatywą dla buntu może być po prostu przestrzeganie planu szefów do listu, z aktywnym udziałem wszystkich - w kierunku nieuchronnego gromadzenia twardych danych, w celu poparcia lub przeciw kontynuacji tej ścieżki powodu.
tahwos
10

Dla odpowiedzialności nie chciałbym person to blamepola, chciałbym Person who knows the codepola lub person who can fixpola, aby wiedzieć, gdzie wysłać bilet pomocy technicznej.

Przyspieszyłoby to proces naprawiania samego błędu i dałoby rozliczalność, jak zabicie dwóch ptaków jednym kamieniem. Osobiście przedstawiłbym mu to i pozwoliłbym mu zdecydować, czy pomogłoby to zwiększyć morale i odpowiedzialność, nie sprawiając, by ktokolwiek poczuł, że poniósł porażkę. Ekstremalne testy nie wychwytują wszystkich błędów, w przeciwnym razie nie byłoby zgłaszania błędów.

Malachiasz
źródło
9

Powiedz mu, że „wina” jest negatywna. Zmień go na „osoba do naprawienia”, a następnie przynajmniej w pozytywny sposób, a ta sama praca będzie nadal wykonywana. Jak ludzie mogą pracować, jeśli są „obwiniani” ?!

José
źródło
2
Nie można „naprawić osoby” ...
SandRock,
1
Mamy pole „osoba do naprawienia”. To nie wystarczy
MK_Dev
9

Gdyby mój szef to zrobił, byłyby następujące, w tej dokładnej kolejności:

1) Natychmiast zacznę szukać nowej pracy.

2) Za każdym razem, gdy ktoś zgłasza błąd, za który winna, pojawia się imię mojego szefa oraz komentarz wyjaśniający, dlaczego odpowiedzialny jest za to zły proces w zespole. I przekaż to swojemu szefowi (najlepiej partią). Czy masz testy jednostkowe? Jeśli nie, oznacza to, że proces tworzenia jest zepsuty, a więc błąd. Czy masz ciągłe automatyczne testy integracji ze wszystkimi systemami zewnętrznymi? Następnie proces tworzenia jest przerywany, a zatem błąd. Czy potrafisz sprawić, by każde środowisko produkcyjne było identyczne za pomocą skryptu, aby nie dopuścić do błędu ludzkiego? Następnie proces tworzenia jest przerywany, a zatem błąd. Czy jeden programista jest okropny? Kryteria zatrudniania są złe, a więc wina szefa. Czy wszyscy programiści popełniają głupie błędy z powodu braku odpoczynku, ponieważ pracują 12 godzin dziennie? Następnie proces tworzenia jest przerywany.

Na marginesie: Każdy dobry menedżer ds. Rozwoju jest świadomy tego, co napisałem powyżej. A strategie zwinne mają na celu wskazanie szefowi lub jego przełożonym, dlaczego deweloper zwalnia: Patrz, spędzamy 50% naszego czasu na naprawianiu błędów. Przyjrzyjmy się strategiom zmniejszania ich, abyśmy mogli spędzić 40% czasu na naprawianiu błędów, a następnie wrócimy do tego problemu, zwiększając go do 30%. itp.

Niestety wygląda na to, że nie masz dobrego menedżera z powodu pola. Sugeruję więc zrobienie (1) i nie przedstawianie tego kierownikowi (z wyjątkiem rozmowy kwalifikacyjnej)

Dmitriy Likhten
źródło
8

Wygląda na to, że twój szef nie ma głębokiego zrozumienia oprogramowania i być może też nie zamierza. Ma więc inny język, inną kulturę.

Rezygnacja z pracy dla takiego problemu, zanim nawet próba rozwiązania problemu jest po prostu rezygnacją. Rzucić palenie. Nie poddawaj się, dopóki nie upewni cię, że nigdy się nie zrozumiesz. Aby się upewnić, powinieneś najpierw spróbować.

Ponieważ nie zna naszego języka i jest szefem, pierwszym krokiem będzie próba rozmowy z nim w jego języku. Co mam na myśli przez język? Pomyślmy razem:

My, ludzie oprogramowania, większość z nas uwielbia pracę, którą wykonujemy, mamy ścisły związek z tym, co robimy. W przeciwnym razie to nie działa i nie można długo zajmować się tym biznesem bez kochania go lub bycia kompletnym ... wypełniasz puste pola ...

On jednak widzi rzeczy zupełnie inaczej. Z każdym raportem o błędzie, podczas gdy większość z nas jest podekscytowana poprawianiem działania (nie, nawet jeśli czasami jest to bardzo stresujące, uwielbiamy problemy, po prostu przyznaj się!), Postrzega to jako porażkę, miarę bycia nieudany. Pierwszą rzeczą, którą powinien zrozumieć, jest to, że błędy są dobre. Błędy sprawiają, że klienci kochają firmę. (Teraz to jest jego język) Gdy klient zgłasza błąd lub gdy sami go znajdziemy, po jego rozwiązaniu jest on znacznie lepszy niż sytuacja, w której się nigdy nie zdarzyło. Błędy tworzą lojalność klientów (poważnie!), Błędy stanowią doskonałą pretekst do komunikacji między konsumentem a producentem oprogramowania.

Aby „zwiększyć zysk z błędów”, powinieneś zaoferować jeszcze bardziej otwarte zgłaszanie błędów. Z każdym zgłoszeniem błędu i jego szybkim, czystym i dobrym rozwiązaniem klienci czują i widzą, że „wow, ci faceci są niesamowici! Pracują naprawdę ciężko. Spójrz na te rzeczy, które rozwiązują. Nie byliśmy nawet świadomi, że oprogramowanie było tak złożone rzecz!" bla bla i bla ...

Ruszaj się, mów w jego języku. Błędy są świetne dla firmy programistycznej, nie stanowią problemu. Zarabiają nam na życie.

Etyka zespołu, wydajność lub każdy inny rodzaj rozmowy może działać w odwrotny sposób niż zamierzałeś. Jeśli chcesz odejść, pomyśli: „aha, moje rozwiązanie zaczęło działać od pierwszego dnia! Złe linki już zaczęły same spadać, zanim zostały ujawnione!” Wierzy w swój pomysł znalezienia złych chłopców w towarzystwie i bardzo trudno jest go przekonać inaczej. Zwłaszcza, gdy możesz być jednym z tych złych chłopców!

Skoncentruj się więc na jego prawdziwym problemie: błędach. Pokaż mu, że błędy mogą być bardzo przydatne. Bez żadnych problemów związek jest nudny. Wszystko, co cię nie zabije, cię wzmocni. Każdy błąd to świetna okazja, którą możesz wykorzystać, aby zwiększyć zadowolenie klienta.

To tylko jedna rzecz, którą możesz powiedzieć. Pomyśl o jego obawach, a znajdziesz wiele innych pozycji do dodania do listy. ZŁOTY KLUCZ ma zaproponować alternatywną rzecz zamiast walczyć ze swoim pomysłem!

hasanyasin
źródło
5
Nie downvoter, ale pytanie wyraźnie mówiło, że podjęto wiele prób przekonania szefa, że ​​to zły pomysł, więc drugi akapit twojej odpowiedzi był niewłaściwy.
Larry Coleman
8
Bardzo nie zgadzam się z opinią, że rezygnacja z pracy, gdy firma robi rzeczy, jest głupia. Naprawianie firmy to nie twój problem. Jeśli moje odejście potwierdzi własną logikę szefa w jego oczach, to jest to jego problem; przestał być mój, gdy tylko wyszłam za drzwi.
Nate CK,
Wolę próbować rozwiązać wszystko, co mogę. W takiej sytuacji, jeśli zrezygnuję, firma pozostanie bez rozwiązania, przynajmniej przeze mnie. Jeśli mogę łatwo coś naprawić, zamiast zaczynać od zera, wolę próbować to naprawić. Dla mnie, w tej konkretnej sytuacji, chodzi przede wszystkim o obliczenie różnicy wysiłku, czasu i stresu / inwestycji psychologicznych, tak czy inaczej, a także wyniku, jaki mogę osiągnąć ... Dziękuję bardzo za komentarz. To piękne, że wszyscy mamy różne poglądy na świat :)
hasanyasin
Oczywiście, jeśli chciałbym rzucić palenie, ten post nie istniałby. Mówiąc to, @hasanyasin, dziękuję za post - interesującą perspektywę. Szef jest jednak specjalistą od technologii / oprogramowania / programisty, co tylko utrudnia ten problem.
MK_Dev
@hasanyasin O dobroci robaka - jest doskonała! Przykro mi, nie mogę wyrazić dwóch pozytywnych opinii! Ja też z niego skorzystam!
Gangnus
8

Jeśli korzystasz z Agile i brzmi to tak, jakbyś komentował funkcje / historie . Człowiek winien byłby osoba QA że niech bug przemknąć lub wyrobów Owner / klienta, który zaakceptował fabularny / historię jako kompletny z błędów w nim.

Pisałem w tamtym dniu, oto moje zdanie na ten temat.

To jest jak obwinianie składu za błędy ortograficzne i inne rzeczy, które korektor powinien znaleźć, ale pominąć. Pisarz popełnił błąd ortograficzny, ale korektor tego nie zauważył, więc to on ponosi winy za błąd w drukowaniu, a nie osoba, która popełniła błąd.

W środowisku zwinnym odpowiedzialność za wyłapywanie błędów (błędów) spoczywa na osobach odpowiedzialnych za kontrolę jakości, a obowiązkiem właścicieli produktu jest nieakceptowanie rzeczy, które nie są prawidłowe. Są to dwa poziomy czytników dowodów, które powinny izolować programistów od rzeczy, które zostaną wydane, i jest to jedyny sposób, w jaki wszystko powinno być klasyfikowane jako błąd w środowisku Agile.


źródło
3
Co gorsza, deweloperzy są teraz również QA. Wiem ...
MK_Dev
Co za niepokojąca postawa.
pdr
1
Działając zwinnie, cały zespół jest „osobą winną”. Zwinny zespół wartości nad jednostkami i cały zespół opracowuje aplikację, więc każdy błąd jest problemem całego zespołu. Pomyśl o sytuacji, w której kompilacja kończy się niepowodzeniem na serwerze CI. Cały zespół powinien przestać działać i sprawdzić, co należy zrobić. Przynajmniej tak powinno być!
Sgoettschkes
@Sgoettschkes teoretycznie zgadzam się z tobą w 100%, zespół jako całość jest odpowiedzialny za wytwarzany produkt. Ale jeśli próbujesz wyodrębnić konkretną osobę, to osoby sprawdzające pracę są bardziej odpowiedzialne za pozwolenie, aby przeszła.
7

Myślę, że twój menedżer próbuje rozwiązać problem z niewłaściwym rozwiązaniem. Wydaje mi się, że może występować problem polegający na tym, że publikowanych jest zbyt wiele błędów, a Twój menedżer chce, aby programiści wzięli na siebie większą odpowiedzialność za kod, który piszą.

Korzystanie z programowania opartego na testach i konfigurowanie serwera ciągłej integracji (takiego jak Jenkins ) pomoże rozwiązać ten problem, bez wprowadzania „gry obwinianej”. Serwer ciągłej integracji jest w tym ważny, ponieważ gdy ktoś popełnia kod, który „psuje kompilację”, e-mail wysyła się do zespołu, pokazując osobę odpowiedzialną. Ponieważ ten kod nie został wydany w środowisku produkcyjnym, ten rodzaj winy jest bardziej proaktywny i zachęcający (i zabawny!).

W rezultacie programiści przejmą większą odpowiedzialność, poczują się pewniej i będzie mniej błędów w kodzie produkcyjnym.

Andrzej
źródło
Zgadzam się z twoim pierwszym stwierdzeniem w 100%. To były moje słowa, kiedy mówiłem o tym problemie.
MK_Dev
7

Zwróć uwagę, że jeśli błąd jednej osoby powoduje błąd w produkcji, oznacza to, że coś jest nie tak z twoją metodologią lub nad całym sposobem tworzenia oprogramowania. Zwróć uwagę, że za zapobieganie dostawaniu się błędów do produkcji odpowiada cały zespół.

Korzystając z jednego z tych dwóch argumentów, sprawdź, czy możesz przekonać swojego szefa, że ​​posiadanie pola „kogo winić” jako pola pojedynczego wyboru byłoby mylące; i dlatego należy upewnić się, że pole „kogo winić” jest polem wielokrotnego wyboru. Gdy to osiągniesz, upewnij się, że dla każdego błędu nazwa każdego znajduje się w terenie. Twój szef w końcu zobaczy, że wszelkie zgłoszenia w terenie są daremne.

Dawood ibn Kareem
źródło
6

Aby dać szefowi trochę uznania, koncepcja „przypisywania winy” jest już wyparta w narzędziach takich jak SVN , a odpowiednie wykorzystanie danych może być konstruktywne dla programistów, którzy „dowiadują się, z kim rozmawiać” podczas debugowania, np .: http: / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

Chociaż zgadzam się z odpowiedzią gnata powyżej, że pole Przyczyna pierwotna jest dobrą rzeczą, nie jest to ta sama informacja i „denormalizacja” pola, aby czasami przypisać poprzednie nazwy programistów do źródła, którego dotyczy problem, a czasami mieć opis techniczny (np. „nie skalowano do 10000 użytkowników”) po prostu zmętni wody. Byłbym zwolennikiem utrzymania głównej przyczynypodać wyraźnie opis techniczny (np. nawet w przypadku wyraźnego błędu programisty, niech przechwytuje szczegóły, takie jak „Wyjątek IndexOutOfRange, gdy fooData = 999”). Może to potencjalnie dostarczyć użytecznych informacji zwrotnych podczas masowej weryfikacji i umożliwić podjęcie pewnych działań naprawczych. do rozwiązywania całych klas problemów ze zmianami architektury lub frameworka (np. ulepszanie niestandardowych klas kontenerów, obsługa wyjątków najwyższego poziomu)

To powiedziawszy, dodanie pola Osoba do winy wyraźnie może wysłać bardzo zły komunikat i destrukcyjny komunikat do zespołu programistów, że kierownictwo chce wyróżnić i ukarać indywidualnych programistów, którzy najczęściej łamią kod. Podejrzewam, że menedżer uważa, że ​​ta publiczna kontrola sprawi, że programiści będą bardziej ostrożni i samoregulujący się, aby uniknąć umieszczania swoich nazwisk na tej „ścianie wstydu”, i nie rozumie, dlaczego programiści czują się zagrożeni, szczególnie jeśli zostanie dodany ogólnie do każdego zgłoszenia błędu.

Problemy z dodaniem tego jako pola błędu / potencjalnej metryki można łatwo wyliczyć:

  1. Błędy mają bardzo różną trudność do rozwiązania, a prosta statystyka liczby błędów / programistów nie odzwierciedla tego.
  2. Programiści są bardzo zróżnicowani pod względem możliwości „” „„ ”„ „” „”
  3. Wiele systemów oprogramowania ma komponenty, które wymagają refaktoryzacji, jednak refaktoryzacja starszych komponentów (szczególnie jeśli starsza baza nie ma / ograniczone możliwości testowania jednostek) początkowo wprowadza błędy. Deweloperzy będą prawdopodobnie zniechęcani do tej „dobrej” aktywności, jeśli istnieje stygmatyzacja / strach związany z generowaniem nowych błędów (nawet jeśli są one trywialne do rozwiązania, a efekt końcowy stanowi znaczną poprawę w systemie).
  4. Testerzy mogą zgłaszać bardzo zmienną liczbę błędów związanych z tym samym problemem, co skutkuje bardzo wypaczoną liczbą błędów / programistą, chyba że przeprowadzona zostanie bardziej szczegółowa analiza.

To tylko wierzchołek góry lodowej. Połącz to z wskazaniem, kto spodziewał się, jakie zachowanie API, niepoprawne oczekiwane wyniki w testach i problemy „wcześniej w łańcuchu” z nieprawidłowymi / brakującymi wymaganiami, i powinno być oczywiste, że taka metryka jest skazana na bezwartościowość (chyba że celem jest zniszczenie morale i masowy exodus).

Wracając do punktu widzenia szefa, jest OK, że chce dowiedzieć się, czy istnieją programiści, którzy wielokrotnie łamią kod, i spróbować zrobić coś (mam nadzieję, konstruktywne) w tej sprawie. Próba uzyskania tych informacji poprzez dodanie pola do raportów o błędach nie zapewni istotnych informacji z powodów wymienionych powyżej. Z mojego doświadczenia wynika, że ​​informacji tych można się nauczyć, podłączając się do zespołu, uczestnicząc w większości spotkań zespołu, integrując (ostrożnie) informacje zdobyte podczas sporadycznych spotkań indywidualnych z członkami zespołu i zapoznając się z podsystemami w kod (nawet jeśli nie mogą odczytać kodu).

holtavolt
źródło
6

Odpuść już. Twój szef sam odkryje, że powoduje problem, jeśli tak się stanie.

Bądźmy szczerzy, masz opinię i on też. On jest twoim menedżerem, a jego opinia wygrywa.

Tak, możesz iść na wojnę w tej sprawie, ale czy naprawdę warto? Wątpię, żeby trwało to ponad 3 miesiące, zanim przestało być używane.

Ale aktywne sabotowanie tego lub krzyczenie na ten temat po prostu zużywa kapitał polityczny, który jest lepiej zaoszczędzony na prośbie o dodatkowy czas wolny, kolejne podwyżki, promocję lub kiedy ma zostać podjęta naprawdę krytyczna decyzja projektowa.

W tym momencie, kiedy to naprawdę się liczy, nie chcesz, żeby szef pamiętał, że to ty aktywnie sabotowałeś swój pomysł na „osobę odpowiedzialną”.

Szanuj biuro, nawet jeśli nie uszanujesz decyzji.

Zaoszczędź stres i walenie przy stole w przypadku decyzji, które będą trwać znacznie dłużej.

Poklepać
źródło
+1 za rozsądne rozwiązanie (mimo że dodałem własną odpowiedź) :-)
Homer6
2
Tego rodzaju ludzie przyjmują uprzejmość i wrażliwość na słabość. Następnym razem przyjdzie z czymś znacznie gorszym. Będzie jeszcze mniej chętny do słuchania opinii. Nawet teraz mówi, że krzywdzenie ludzi to dobra zabawa. Jeśli będziesz współpracować z takimi ludźmi, będziesz musiał zostać sadystą lub masochistą.
Gangnus
5

Powiedz swojemu szefowi, że rozwój w zespole wymaga umiejętności społecznych. Może nawet pokiwać głową.

Problem polega jednak na tym, że jest to coś, z czym programiści są bardzo źli. Dodanie narzędzi sugerujących obwinianie jest ważniejsze niż odpowiednia analiza problemu przynosi efekt przeciwny do zamierzonego.

Zamiast tego potrzebujesz zachęt do podnoszenia umiejętności społecznych, a infrastruktura komunikacyjna, którą masz, powinna to wspierać. Na przykład zrób to pozytywnie: wymień osobę odpowiedzialną za bilet, która się nim zajmie.

Zacznij od recenzji kodu, abyś mógł się od siebie uczyć. To oszczędza później winy.

hakre
źródło
Przypomnij mu, że w większości przypadków to on może być winien. Presja czasu, członek zespołu, zarządzane priorytety, wybrane / zatwierdzone narzędzia ...
BillThor
O rany, znam programistów. Często szukają przyczyny przez kogoś innego. I nie wstydzą się spierać. Powiedziałbym, że programiści muszą aktywnie dążyć do poprawy swoich umiejętności społecznych i odpowiedzialności. Pole winy może być tylko objawem, że w procesie rozwoju coś idzie nie tak. Założę się, że programiści ponoszą odpowiedzialność za ten problem. Menedżer też, wygląda na to, że robaki rosną ponad ich głowami. Dlatego powinni lepiej przeanalizować, dlaczego błąd wyeliminował ich z ukierunkowanego rozwoju.
hakre
4
-1 za zasugerowanie tego developer == no social skills. Oba są całkowicie niezwiązane. Możesz być dobry w jednym lub obu, i być zły w jednym lub obu, i nie ma połączenia.
Daenyth
@Denenyth: To miało być prowokacja, więc miło, że cię prowokuje. Upewnij się, że te korelacje z natury nie są prawdziwe i głupotą jest to mówić (uprzedzenie). Jednak często programiści nie mają umiejętności społecznych. Zwłaszcza ci, którzy pracują w firmie zarządzanej w sposób opisany przez OP.
hakre
@hakre: Jeśli tak jest w przypadku jego pracy, to tylko dlatego, że bardziej zręczni opuścili firmę z powodu zarządzania
Daenyth
2

Wyślij mu to SO pytanie. Jeśli jest otwarty na rozum, komentarze tutaj zapewnią kontrolę rozsądku dla jego uzasadnienia. Jeśli nie jest rozsądny, raczej nie przekonasz go z uzasadnionych powodów. Ponadto będzie w stanie odczytać powody poza rozmową (co czasami może być bardziej przekonujące ze względu na usuniętą motywację do „racji” w trakcie rozmowy).

Możesz także spróbować to odwrócić. Pole może być „możliwym krokiem, aby uniknąć wystąpienia podobnego błędu”, lub czymś krótszym w tym celu. Następnie możesz zebrać rozwiązania i głosować na te, które należy wdrożyć, aby ulepszyć swoje miejsce pracy. Być może podejście zorientowane na rozwiązanie jest bardziej produktywne i prawdopodobnie lepiej odebrane (pod warunkiem, że w trakcie ponownej weryfikacji sugestii nastąpi rzeczywista kontynuacja).

Homer6
źródło
1

Widzę tutaj dwie możliwości: chce być w stanie ukarać ludzi, którzy popełniają błędy, albo po prostu tego nie przemyślał. Poinformuj go, że wszyscy odczują, że zamierza ukarać tych, którzy popełniają błędy. Zapytaj go, czy to kultura, którą chce promować.

mój szef zdecydował, że dodanie pola „Osoba do winy” do naszego szablonu śledzenia błędów zwiększy odpowiedzialność

Z mojego doświadczenia wynika, że ​​kiedy zarząd chce „uczynić ludzi bardziej odpowiedzialnymi”, to znaczy, że chcą być w stanie wymierzyć karę za niepowodzenie. Niezależnie od tego, czy chodzi o zwolnienie słabych wykonawców, czy po prostu pozwolenie im odejść w corocznym przeglądzie wynagrodzeń („Przepraszam, Bob, masz 17 błędów zgłoszonych jako wina, a to przekracza limit 15”), to kara.

Prawdopodobnie powie „Och, nie, nie chcemy tego”, więc zapytaj go, jak te dane zostaną wykorzystane. Przypomnij mu, że nie dodajesz punktów danych do bazy danych, chyba że zamierzasz z niej korzystać. Czy chce wybrać określone kryteria („Pokaż mi wszystkie otwarte błędy w podsystemie twórcy raportów”), abyś mógł pracować nad różnymi rzeczami lub aby uzyskać agregację danych („Który podsystem miał najwięcej błędy ”), dzięki czemu można przeprowadzić sekcję zwłok. Czy wyobraża sobie jakąś tablicę porażek, w której można publicznie upokorzyć?

Więc co on zamierza? Czy chce móc powiedzieć „Pokaż mi wszystkie błędy, które są winą Boba?” Dlaczego? Czy może chce powiedzieć „Pokaż mi, kto jest winny przez większość czasu?” Dlaczego? Pierwszy nie ma znaczenia, a drugi ma charakter karny. Lub trzecią opcją jest to, że nie ma prawdziwego powodu.

Przyznaję, że istnieje możliwość, że mógłby szukać programistów w zespole, którzy potrzebują pomocy w doskonaleniu swoich umiejętności. Jeśli tak, istnieją lepsze sposoby przechwytywania tych informacji, które nie tworzą kultury wskazywania palcami.

Andy Lester
źródło
-3

Uważam, że kluczowym aspektem do obejrzenia tutaj jest otwarta komunikacja w zespole w stosunku do „szefa” i na odwrót. Wskazanie palcem nigdy nie jest dobre z punktu widzenia zarządzania, jeśli jeden z programistów wpadnie kilka razy na ten sam problem, być może nadszedł czas, aby wkroczyć i spróbować pomóc mu rozwiązać ten powtarzalny problem (np. John nie testuje prawidłowo kod: 3 błędy produkcyjne w ciągu ostatnich 3 miesięcy, dajmy mu listę kontrolną, aby pamiętał, jak powinien wyglądać jego kod i jak powinien go przetestować).

Z punktu widzenia programistycznego „obwinianie” jest już włączone do głównego nurtu narzędzia, takiego jak SVN, dlatego naprawdę nie widzę żadnej szkody w pisaniu „John, napraw to bzdury, które napisałeś” i umieszczaniu nazwy obok to. JIRA zawiera również imię i nazwisko osoby podczas zgłaszania błędu (jednak pole to nie jest tak naprawdę przeznaczone dla osoby, która jest za to odpowiedzialna, to raczej po to, aby ktoś go naprawił).

Oto jednak, jak wielu wspomnianych powyżej przez wielu, jeśli pojawi się błąd, jest to wspólna odpowiedzialność: od programisty, przez testerów, przez QA, aż po menedżerów. Jeśli twój szef w pewnym momencie obsługuje przez telefon wściekłego klienta takimi sprawami, jak „ przepraszam, John nigdy nie przetestował tego poprawnie ”, to zdecydowanie szukałbym innej pracy. Dobry szef powinien powiedzieć: „Zajmiemy się tym”. Bez nazwisk, bez wskazywania palcem, tylko rozwiązania.

Ponownie uważam, że chodzi o komunikację. Być może jedyną rzeczą, którą chce zrobić twój szef, jest sprawdzenie, kto ma problemy w zespole deweloperów lub jakie problemy ma zespół (być może podczas sesji treningowych?), Ale nie sądzę, że dowiesz się dokładnie, co kryje się za jego decyzja (lub lepiej mówiąc, my plakaty / czytelnicy), chyba że rozmawiasz z szefem i całym zespołem.

Osvaldo Mercado
źródło