Jak mogę przestać popełniać głupie błędy w pracy?

Trzy rzeczy pomogą Ci być dokładniejszym:

• korzystaj z list kontrolnych i procedur (pisz swoje własne) i przestrzegaj ich. Zawrzeć w nich kroki takie jak “podwójne sprawdzenie, na który serwer jesteś skierowany”. Kiedy konsekwencje błędu są wysokie, wydrukuj listę i sprawdź wszystko za pomocą długopisu.
• kiedy technologia Ci pomoże, poświęć chwilę na sprawdzenie. Powiedz, że Twój klient poczty elektronicznej wypełnia linię To po wpisaniu pierwszego listu. Nie wpisuj tylko listu i nie klikaj przycisku Wyślij. Zatrzymaj się i zobacz, co wypełnił.
• gdy tylko popełnisz błąd, zadaj sobie pytanie dlaczego. Jaki krok pominąłeś? Na co nie spojrzałeś? Dlaczego dobra i zła rzecz wyglądały tak podobnie? Jak może być łatwiej mieć pewność, że robisz to dobrze? Ulepsz swoją procedurę z tym, czego się właśnie nauczyłeś. Prawdę mówiąc, na tym właśnie polega doświadczenie.

Jak mogę przestać popełniać głupie błędy w pracy?

Masz problem z jakością pracy i potrzebujesz systemu, który wykryje błędy, aby stworzyć odpowiednią informację zwrotną dla improwizowania/rozwijania osobistych procedur i nawyków w pracy. Doskonalenie jakości ma związek z opracowaniem mechanizmów odnajdywania błędów i ich przyczyn, a następnie opracowaniem planu działania w celu ich poprawy.

Krok 1: Przyznaj, że błędy nie są “głupie” - są poważne. Możesz stracić nad nimi swoją pracę. Myślę, że dużym wskaźnikiem twojego problemu jest to, że wydają się one być rzeczami, którym łatwo jest zapobiegać, a mimo to nadal je robisz. Nie zapobiegając im, masz jednak poważny problem.

Krok 2: Zwolnij. Zbyt często programiści i inżynierowie “gwiazdy rocka” są postrzegani jako ci, którzy poruszają się szybko i wściekle - nic ich nie zatrzymuje! Rzeczywistość jest taka, że oni nie są tacy. Są sytuacje, w których tak się dzieje, ale jest wiele sytuacji, w których nie jest to prawdą. Przestań czuć się popędzony, weź oddech i luzuj.

Krok 3: Zanim coś “skończysz”, zatrzymaj się i zrób sobie przerwę, potem wróć do tego i przejrzyj. Napij się kawy, przeczytaj maila lub coś niezbyt rozpraszającego, aby oderwać się od zadania, które masz pod ręką, aby po powrocie do niego mieć nową perspektywę. Możesz mieć wrażenie, że to spowolni lub zmniejszy twoją wydajność. Jednak takie podejście pozwala na wczesne zauważenie błędów, co jest ważne dla wydajności. Więc zanim trafisz “wyślij” - przeczytaj kolejną wiadomość e-mail lub sprawdź status serwera lub czegoś takiego. Nie chodzi tu tylko o pisanie kodu.

Krok 4: Kiedy znajdziesz błąd, nie naprawiaj go po prostu. Poświęć chwilę, aby spróbować dowiedzieć się, dlaczego błąd wystąpił. Gdzie się spieszysz? Błąd kopiowania/wklejania? Polegasz na czyjejś pracy lub opinii? Dzięki temu będziesz bardziej świadomy przyczyny błędów w momencie ich wystąpienia. Dowiedzenie się później nie jest zbyt pomocne, jak wiesz.

Krok 5: Śledź swoje postępy. Zwróć uwagę na użyteczność swoich nowych nawyków i praktyk. Zachowaj arkusz kalkulacyjny, aby zliczyć błędy lub problemy, które znalazłeś po przerwie. Zwróć również uwagę, czy odkrycie nie zapobiegło czemuś, co mogłoby rozzłościć Twojego szefa lub być żenujące. Rozwija to Twoją zdolność do lepszej samooceny akceptowalności własnej pracy, a także do spróbowania dowiedzieć się, jakie nawyki są najbardziej efektywne.

Krok 6: Opracuj procedury i listy kontrolne (lub zaktualizuj istniejące), w których widzisz wzorce wyłaniające się z powyższych obserwacji. Nie możesz rozwijać list kontrolnych lub procedur dla wszystkich, więc po pewnym czasie (lub nawet dość szybko) znajdziesz wzorce błędów, gdzie możesz stworzyć powtarzalną metodę zapobiegania pewnym rodzajom błędów. Jest to przydatne tylko w przypadku częstych zadań, które są skomplikowane. W przeciwnym razie będziesz kuszony, aby nie sprawdzać listy, nie utrzymywać jej aktualności lub możesz stworzyć więcej list i procedur, niż jesteś w stanie obsłużyć, czyniąc je przestarzałymi i nieaktualnymi - co może prowadzić do większej ilości błędów.

Wypróbuj różne podejścia do odkrywania, gdzie znajdują się Twoje błędy, zanim staną się problemami. Podczas gdy wiele odpowiedzi skupia się tutaj na rozwijaniu procesów/procedur/list kontrolnych (szczególnie wokół tworzenia kodu), założenie “zarządzania jakością” lub “doskonalenia jakości” ma związek z wykrywaniem błędów jako środka informacji zwrotnej dla rozwoju i/lub doskonalenia procesów. Nie można opracować “lepszego” procesu, jeśli nie zna się przyczyny błędów. Praca nad odkrywaniem przyczyn błędów Najprawdopodobniej po prostu się spieszysz, a nie “podwójnie sprawdzasz” swoją pracę. Oto kilka wskazówek, jak sprawić, by wolniejsze tempo pracy było bardziej produktywne.

Przestań pracować. To jedyny sposób, aby przestać popełniać błędy.

Nie, poważnie: Zawsze będziesz popełniał kilka błędów. To jest część bycia człowiekiem (którą czuję, że mogę bezpiecznie założyć, że jesteś). Każdy profesjonalny programista będzie wykonywał pracę z pewną ilością błędów, i to jest w porządku. To jest powód, dla którego mamy takie rzeczy jak Rozwój Kierowany Testami, Testowanie Jednostkowe i Działy Jakości. Jeśli Twój menedżer oczekuje oprogramowania wolnego od błędów przy pierwszym podejściu, to nie masz do czynienia z rozsądnymi oczekiwaniami.

To powiedziawszy, żyjemy w świecie, w którym nie możemy przestać pracować tylko dlatego, że błędy się zdarzają, więc podejmujemy kroki w celu zmniejszenia ryzyka błędu. Pracuję w zakładzie produkcyjnym, więc hasłem przewodnim jest Poke-yoke (dosłownie po japońsku: Mistake-Proofing); który jest zautomatyzowanym procesem mającym na celu wyeliminowanie ludzkich błędów. Oznacza to automatyzację. Ja definitywnie zalecam przejście na zautomatyzowany proces budowy w celu wdrożenia oprogramowania do produkcji. Będzie to wymagało zaangażowania więcej niż jednego programisty, ale warto posunąć się tak daleko, jak tylko można.

Gdzie nie można zautomatyzować, nie spiesz się. Wielu błędom można zapobiec poprzez poświęcenie czasu na przegląd przed podjęciem działania. Poświęć minutę, aby przejrzeć swój kod przed dokonaniem zmian. Poświęć dodatkową minutę na przeglądanie e-maili przed naciśnięciem tego fatalnego przycisku Wyślij.

Na koniec, nie bój się poprosić o pomoc. Jako deweloper, jednym z moich pierwszych sposobów działania po znalezieniu błędu jest poproszenie zaufanego współpracownika o jego obejrzenie. Świeży zestaw oczu może zobaczyć wszystkie rodzaje problemów, które nieświadomie odfiltrowałeś. A jeśli nie masz zaufanego współpracownika, znajdź nową pracę; brzmi to tak, jakbyś był programistą na poziomie juniora/średnim i potrzebujesz systemu wsparcia, aby rozwijać się jako programista. Posiadanie innych programistów, którzy mogliby rzucać pomysły, nie jest opcjonalną częścią Twojego rozwoju jako Profesjonalnego Programisty.

W skrócie: Automatyzuj tam, gdzie jest to możliwe, nie spiesz się, kiedy nie jest, i nie bój się prosić o pomoc.

Nie, nie wyeliminujesz błędów. Ale może uda ci się złapać te najważniejsze. Ważne jest, aby być świadomym tego, co robisz i szukać bezpieczniejszych sposobów.

Zidentyfikuj ryzykowne przedsięwzięcia. Nie możesz być na straży w każdej sekundzie dnia - ale każdy popełnia drobne błędy przez cały dzień. Większość błędów można naprawić bez wysiłku, więc lepiej zauważ, kiedy coś może pójść nie tak łatwo. Każda komunikacja z klientem, każde wdrożenie na stronie, każda globalna zmiana w dokumencie, itp.

Pytanie co robisz. Czy rozumiesz, co robisz, dlaczego i jak? Czy można to zrobić bezpieczniej? Czy jesteś pewien, że lepiej to zrobić, niż nie robić tego?

Pauza przed podjęciem ryzykownych działań. Nie wysyłaj emaila bez sprawdzenia odbiorców, tematu, treści i załączników. Jeden po drugim. Nie spieszcie się. Wysłanie wyceny dla klienta A do klienta B może spowodować utratę obu klientów. Lepiej poświęć mniej więcej minutę na sprawdzanie ofert. Nie daj się skusić na pośpiech, nawet w ‘nagłych wypadkach’.

Masz plan naprawczy. Wiedz z góry, co zrobisz, jeśli coś pójdzie nie tak. Przygotuj się na to, że jeśli będziesz musiał naprawić swój błąd, możesz to zrobić szybko - ale bez pośpiechu. Skąd będziesz wiedział, czy zrobiłeś coś złego? Czy jest jakiś sposób, aby dowiedzieć się wcześniej?

Dokumenty wszystko, co ma wiele kroków. Jeśli posiadasz dokumentację, postępuj zgodnie z nią jak z listą kontrolną, abyś mógł stwierdzić, czy jest ona wystarczająco dobra, czy też jest przestarzała, niekompletna lub wadliwa. Nawet jeśli zrobisz to tylko raz - zanim napiszesz swój raport, napisz listę wszystkich rzeczy, które muszą wejść.

Śledzenie do zrobienia szczególnie jeśli zapomnienie jest problemem. Wszystko, co musisz zrobić, a czego nie robisz right now, powinno tam wejść. Śledź je wszystkie w jednym miejscu i wracaj do swojej listy rzeczy do zrobienia. Nie polegaj na notatkach post-it złożonych i schowanych w tylnej kieszeni.

Automatyzuj tam gdzie to możliwe. Jeśli masz listę pięciu rzeczy do wpisania, czy możesz napisać program do zrobienia tych pięciu rzeczy i wtedy masz tylko jedną rzecz do zrobienia? Jeśli tworzysz oprogramowanie, czy możesz uruchomić automatyczne testy, aby odebrać, gdy wprowadzisz błędy? Czy dążysz do 100% pokrycia? Czy testujesz z myślą o złamaniu kodu? Czy masz ciągłą integrację, więc nie musisz się martwić, że zapomnisz o uruchomieniu testów?

Poproś o drugą opinię, jeśli robisz coś ryzykownego, czego nie możesz zweryfikować i z czego nie możesz łatwo wyjść. Powszechną praktyką w przypadku oprogramowania jest to, że kod jest zawsze testowany przez kogoś innego zanim zostanie zaakceptowany.

Learn. Każdy popełniony błąd jest okazją do zrewidowania procesu.

Take care of yourself. Znajdź czas w ciągu dnia, aby oczyścić swój umysł i mieć kilka minut ciszy lub relaksu. Przed pracą, po pracy, po przerwie obiadowej, itp. Zasypiaj. Jeść regularnie i zdrowo.

Oczywiście nigdy nie będziecie doskonali, ale są sposoby na poprawę dokładności. Myślę, że najlepszym sposobem jest wprowadzenie dodatkowych procedur, które nie są tylko podwójnym sprawdzaniem własnej pracy, ponieważ ludzie są naturalnie podatni na popełnianie małych błędów. Jest mało prawdopodobne, że złapiesz tego typu rzeczy po prostu przez “bycie bardziej ostrożnym” lub “podwójne sprawdzanie”, więc po prostu próbując to ustawić się na porażkę. Kilka konkretnych sugestii:

1. Testy jednostkowe. Z odpowiednimi testami jednostkowymi, za każdym razem, gdy wprowadzasz zmiany w kodzie, wykonaj testy na wszystkim, a to sprawi, że podwójnie sprawdzisz, czy nie wprowadziłeś przypadkiem błędu.

2. Lepsza procedura wdrożenia. Wdrażaj na serwerze inscenizacyjnym, używając dokładnie tych samych poleceń, których użyłbyś przy testach i sprawdź, czy wdrożenie jest poprawne, zanim przejdziesz do produkcji.

3. Z wyjątkiem testów jednostkowych, odłóż czas na każde rozmieszczenie, kiedy uznasz, że już skończyłeś, aby przejść przez swoją budowę i przetestować jak najwięcej z nich, jak tylko możesz. Nie testuj tylko tych obszarów, które uważasz, że się zmieniły.

Za każdym razem, gdy popełnisz błąd, staraj się myśleć o rozwiązaniach zgodnych z tymi zasadami, aby ustanowić zabezpieczenia przed naturalnym błędem człowieka i przedstawić te pomysły swojemu szefowi.

Pracuję jako inżynier oprogramowania/architekt od ponad 10 lat i mogę powiedzieć na pewno, że nigdy nie wyeliminujesz wszystkich błędów. Najlepszą radą, jakiej mogę Ci udzielić, jest określenie, które zadania są najbardziej ryzykowne i podjęcie kroków w celu ograniczenia tego ryzyka.

1. W większości przypadków wysłanie maila do niewłaściwej osoby to nic wielkiego. Nie mogłem Ci powiedzieć, ile razy otrzymałem maila przeznaczonego dla jednego z pozostałych Jenningsów, którzy tu pracują. Ale jeśli wysyłasz e-maila, który może zawierać poufne informacje, zawsze poświęć trochę czasu na podwójne sprawdzenie odbiorców i treści.
2. Jeśli piszesz ważny dokument, napisz listę sprawdzającą, co musi w nim być i sprawdź jego zawartość przed wysłaniem.
3. Do wdrażania builds, zawsze używaj automatycznego procesu i wdrażaj go najpierw na drugi serwer, jeśli to możliwe. Mój zespół wdraża nasze usługi Rubiego na dodatkowy serwer, testuje je, a następnie przenosi je na serwer główny. Jeśli w tym momencie pojawią się jakieś problemy, zawsze możemy po prostu przerzucić się z powrotem na stary serwer. Jeśli żadna z tych rzeczy nie jest możliwa, niesie to ze sobą znacznie większe ryzyko, więc radzę poświęcić dodatkowy czas i uwagę temu zadaniu. Podwójne i potrójne sprawdzenie wszystkiego dla każdego kroku, który niesie ze sobą duże ryzyko.
4. W przypadku błędów w kodzie, upewnij się, że piszesz dobre testy jednostkowe/integracyjne, które obejmują normalne procesy robocze i przypadki krawędziowe. Dobrym pomysłem jest upewnienie się, że projekt jako całość ma tak wysoki zakres testów jednostkowych, jak to tylko możliwe, aby upewnić się, że jeśli zmienisz coś, co łamie coś innego, test jednostkowy zakończy się niepowodzeniem i wcześnie złapiesz błąd. Nie wykryje to wszystkich błędów, ale jest to dobry początek. Kiedy kod jest już gotowy do testowania czarnej skrzynki, nie tylko testuj przepływy pracy, których Twój kod dotyka, analizuj jakie inne części projektu Twój kod mógł mieć wpływ i testuj również te przepływy pracy. Testy czarnej skrzynki powinny również obejmować zarówno przypadki normalne, jak i skrajne.

Poza tym, powiedziałbym tylko, że więcej czasu i uwagi poświęcasz na zadania o wyższym ryzyku niż normalnie w przypadku codziennych zadań.

Jak dobrze udokumentowane są procesy, które masz? Na przykład, wdrożenie niewłaściwej kompilacji na serwerze na żywo wydaje się być poważnym błędem, który powinien być zminimalizowany poprzez nadmiarowe kontrole, aby upewnić się, że kompilacja X'a trafi do serwera Y, podczas gdy oprogramowanie może mieć błędy w kodzie, ponieważ rzeczy mogą nie być wychwytywane tak łatwo. Byłbym kuszony do tworzenia rozwiązań i proponowania ich szefowi, aby w przyszłości można było uniknąć niektórych błędów. Bądź świadomy tego, co możesz chcieć sprawdzić kilka razy, a co może nie być tak dobre, aby zrobić kilka sprawdzeń przeciwko.

Niestety, jesteś człowiekiem i dlatego błędy pojawią się. Perfekcja jest rzadko osiągana, ponieważ więcej niż kilku tak zwanych wspaniałych w sporcie nie trafiło w zwycięski strzał jak Michael Jordan. Jeśli chcesz, aby niektóre terapie zajęły się Terapią Zachowań Poznawczych, Terapią Zachowań Dialektalnych, jak również Terapią Akceptacji i Zaangażowania, która byłaby wykorzystywana do walki z negatywnymi wzorcami myślowymi, które masz tutaj, chcąc być doskonały. Błędy się zdarzają, klucz jest rozważać jak ty odpowiadasz na one i jak dobry jest twój emocjonalna inteligencja jako samoświadomość i self-management może być coś innego studiować jeżeli ty chcesz inny pomysł.

• *

Dla trochę dokumentującego, rozważałbym aktualizację dokumentację i dodawać więcej czeków które mogą być pożytecznie dla ważnych rzeczy. W pewnym sensie jest to podobne do ludzi, którzy sugerują odczekać kilka sekund przed korektą e-maila, który chcesz wysłać, aby nie zawierał literówek, które mogą być użyteczną wskazówką w niektórych przypadkach.

W niektórych przypadkach jestem na tej samej łodzi co ty, ale pochodzę z innego środowiska. Kiedy pchaliśmy kod na żywo w mojej starej pracy, mieliśmy zautomatyzowane procesy. W nowej pracy, niestety, nie możemy wprowadzić procesów automatycznych. W związku z tym brakuje mi tu i ówdzie drobnych szczegółów, których nie powinno być. Mój menedżer jest w tym dużo milszy, ale rozczarowany.

W każdym razie poprawiłem się samemu, najpierw upewniając się, że zapisuję kroki w notatniku. Upewniam się, że mam listę plików, które chcę popchnąć w górę, i sprawdzam ją podwójnie, zanim to zrobię. Mam też procedurę umysłową dotyczącą tego, co zamierzam zrobić przed jej wykonaniem. To pomaga. Po prostu udawaj, że robisz to zanim to zrobisz, żeby się upewnić, że niczego nie zapomniałeś.

Chciałbym też dodać, że powinieneś dostać się do swojego menedżera. Jeden na jednego i wyjaśnić, że chcesz to poprawić i nakreślić sposób, w jaki chciałbyś to zrobić. Wyjaśnij, że brakuje Ci kilku drobnych szczegółów tu i ówdzie i chciałbyś to poprawić. Być może mógłby podać sugestie, ale powiedziałbym, że jeśli grozi ci zwolnieniem z powodu drobnych szczegółów, to jest to coś, co będziesz musiał rozważyć i przygotować się na to.