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ł?

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?

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.}

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ół.

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.

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.

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ą.

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

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

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?

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 . ”

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.

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ą.

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.

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.

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.

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).

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. "

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.

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” ?!

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)

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!

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.

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.

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.

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).

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.

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.

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).

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.

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.