Hoe kan ik stoppen met het maken van domme fouten op het werk?

Drie dingen zullen je helpen om nauwkeuriger te zijn:

• gebruik checklists en procedures (schrijf je eigen) en volg ze op. Neem stappen op zoals ‘dubbelchecken op welke server u zich richt’. Als de gevolgen van een fout groot zijn, print dan de lijst uit en controleer de dingen met een pen.
• als de technologie je helpt, neem dan even de tijd om te controleren. Zeg dat je e-mail client de To regel invult nadat je de eerste letter hebt getypt. Typ niet alleen de brief en klik op Verzenden. Stop en kijk wat het heeft ingevuld.
• als je een fout maakt, vraag jezelf dan af waarom. Welke stap heb je overgeslagen? Waar heb je niet naar gekeken? Waarom leek het juiste en het verkeerde zo op elkaar? Hoe kan het makkelijker zijn om er zeker van te zijn dat je het goed doet? Update je procedure met wat je net geleerd hebt.

Na verloop van tijd zul je gewoontes en processen ontwikkelen die ervoor zorgen dat je de dingen correct doet. Dat is eigenlijk zo'n beetje wat ervaring is.

Hoe stop ik met het maken van domme fouten op het werk?

Je hebt een probleem met de kwaliteit van het werk en hebt een systeem nodig om fouten te ontdekken om zo de juiste feedback te creëren voor het verbeteren/ontwikkelen van persoonlijke procedures en werkgewoontes. Kwaliteitsverbetering heeft te maken met de ontwikkeling van mechanismen voor het ontdekken van fouten en de oorzaak ervan, en vervolgens het ontwikkelen van een actieplan voor het corrigeren ervan.

Stap 1: Erken dat de fouten niet “dom” zijn - ze zijn ernstig. Je kunt je baan verliezen door ze te maken. Ik denk dat een grote indicator van je probleem is dat dit dingen lijken die gemakkelijk te voorkomen zijn, en toch doe je ze nog steeds. Door ze niet te voorkomen, heb je echter een serieus probleem.

Stap 2: Rustig aan. Te vaak worden “rockster” programmeurs en ingenieurs gezien als degenen die snel en woedend bewegen - niets houdt ze tegen! De realiteit is dat ze niet zo zijn. Er zijn situaties waarin dit gebeurt, maar er zijn veel situaties waarin het niet waar is. Stop met je gehaast te voelen, adem te halen en slow down.

Stap 3: Voordat je iets “afmaakt”, stop en neem een pauze, ga er dan naar terug en bekijk het nog een keer. Haal koffie, lees een e-mail, of iets wat niet te veel afleidt, om je gedachten van de taak af te halen, zodat je een fris perspectief hebt wanneer je terugkeert naar de taak. U kunt het gevoel hebben dat dit u zal vertragen of uw productiviteit zal verminderen. Deze aanpak stelt u echter in staat om fouten in een vroeg stadium op te merken, wat belangrijk is om productief te zijn. Dus voordat u op “verzenden” drukt - lees een andere e-mail of controleer de status van een server of iets dergelijks. Dit gaat niet alleen over het schrijven van code.

Stap 4: Wanneer u een fout vindt, moet u deze niet alleen repareren. Neem even de tijd om uit te zoeken waarom de fout is opgetreden. Waar haast je je naartoe? Kopieer/plakfout? Vertrouw je op het werk of de mening van iemand anders? Dit zal je helpen om je meer bewust te zijn van de oorzaak van fouten ** op het moment dat ze zich voordoen**. Later uitzoeken is niet erg nuttig, zoals u weet.

Stap 5: Volg uw voortgang. Let op het nut van je nieuwe gewoontes en praktijken. Bewaar een spreadsheet om fouten of problemen te tellen die je hebt gevonden na het nemen van een pauze. Let er ook op of een ontdekking iets heeft voorkomen dat je baas boos zou hebben gemaakt of in verlegenheid zou hebben gebracht. Dit ontwikkelt je vermogen om de aanvaardbaarheid van je eigen werk beter te beoordelen en ook om te proberen te leren welke gewoontes het meest effectief zijn.

Stap 6: Ontwikkel procedures en checklists (of update bestaande) waar je patronen ziet ontstaan uit je waarnemingen hierboven. Je kunt geen checklists of procedures ontwikkelen voor alles, dus na een tijdje (of zelfs vrij snel) zul je patronen van fouten vinden waar je een reproduceerbare methode voor het voorkomen van bepaalde soorten fouten kunt creëren. Dit is alleen nuttig voor frequente taken die complex zijn. Anders zul je geneigd zijn om de lijst niet te controleren, niet actueel te houden of je kunt meer lijsten en procedures maken dan je kunt beheren, waardoor ze verouderd en verouderd zijn - wat mogelijk leidt tot meer fouten.

Probeer verschillende benaderingen om te ontdekken waar je fouten zijn voordat ze problemen worden. Terwijl veel van de reacties hier gericht zijn op het ontwikkelen van processen/procedures/controlelijsten (vooral rond codeontwikkeling), heeft het uitgangspunt van “kwaliteitsmanagement” of “kwaliteitsverbetering” te maken met foutdetectie als een middel tot terugkoppeling voor procesontwikkeling en/of -verbetering. Je kunt geen “beter” proces ontwikkelen als je de oorzaak van de fouten niet kent. Werk aan het ontdekken van de oorzaak van de fouten Waarschijnlijk bent u gewoon aan het haasten en niet aan het “dubbelchecken” van uw werk. Dit zijn enkele tips om een langzamer tempo te maken.

Stop met werken. Dat is de enige manier om te stoppen met het maken van fouten.

Nee, serieus: Je gaat altijd een aantal fouten maken. Dat is een deel van het menselijk zijn (wat ik veilig vind om aan te nemen dat je dat bent). Elke professionele ontwikkelaar gaat werk maken met een aantal bugs, en dat is OK. Dit is de reden dat we dingen hebben als Test Driven Development, Unit Testing en Quality Departments. Als je manager in de eerste plaats Bug-Free software verwacht, dan heb je niet te maken met redelijke verwachtingen.

Dat gezegd hebbende, we leven in een wereld waar we niet kunnen stoppen met werken alleen maar omdat er fouten gebeuren, dus we nemen stappen om het risico op fouten te verminderen. Ik werk in een Manufacturing shop, dus de slogan is Poke-yoke (letterlijk Japans voor Mistake-Proofing); dat is een geautomatiseerd proces dat ontworpen is om menselijke fouten te elimineren. Dit betekent automatisering. Ik **beveel aan om over te gaan op een geautomatiseerd bouwproces voor de inzet van software voor de productie. Dit vereist betrokkenheid van meer dan een enkele ontwikkelaar, maar het is de moeite waard om zo ver mogelijk te gaan.

Waar je niet kunt automatiseren, neem je tijd. Veel fouten kunnen worden voorkomen door de tijd te nemen om te controleren voordat u een actie onderneemt. Neem even de tijd om je code te bekijken voordat je wijzigingen vastlegt. Besteed de extra minuut om e-mails te bekijken voordat je op die noodlottige verzendknop drukt.

Tot slot, wees niet bang om om hulp te vragen. Als ontwikkelaar is een van mijn eerste acties bij het vinden van een bug het vragen aan een betrouwbare medewerker om een kijkje te nemen. Een frisse blik kan allerlei problemen zien die je onbewust hebt uitgefilterd. En als je geen vertrouwde collega hebt, zoek dan een nieuwe baan; het klinkt alsof je een junior/mid-level-ontwikkelaar bent, en je hebt een ondersteuningssysteem nodig om als ontwikkelaar te groeien. Het hebben van andere softwareontwikkelaars om ideeën uit te werken is geen optioneel onderdeel van je ontwikkeling als een professionele softwareontwikkelaar.

In het kort: Automatiseer waar mogelijk, neem de tijd als dat niet het geval is, en wees niet bang om hulp te vragen.

Nee, je elimineert geen fouten. Maar je zou de belangrijkste kunnen vangen. Het is belangrijk om je bewust te zijn van wat je doet en te zoeken naar manieren om het veiliger te doen.

Identificeer risicovolle pogingen. Je kunt niet elke seconde van de dag op je hoede zijn - maar iedereen maakt de hele dag door kleine foutjes. De meeste fouten kunnen moeiteloos worden gerepareerd, dus je merkt beter op wanneer er iets mis kan gaan op een manier die niet zo gemakkelijk kan worden gerepareerd. Elke communicatie met een klant, elke inzet op een site, elke globale verandering in een document, enz.

Vraag wat u doet. Begrijp je wat je doet, waarom en hoe? Kan dit veiliger? Weet u zeker dat het beter is om het te doen dan om het niet te doen?

Pauze voordat u doorgaat met riskante pogingen. Stuur geen e-mail zonder de ontvangers, het onderwerp, de inhoud en de bijlagen te controleren. Een voor een. Neem de tijd. Het sturen van een offerte voor klant A naar klant B kan beide klanten verliezen. Beter is het om een minuut of zo te controleren. Laat u niet verleiden tot haast, zelfs niet in een ‘noodgeval’.

Heb een herstelplan. Weet van tevoren wat je gaat doen als er iets misgaat. Bereid je voor, zodat als je je fout toch moet herstellen, je het snel kunt doen - maar zonder je te haasten. Hoe weet je of je iets fout hebt gedaan? Is er een manier om er eerder achter te komen?

Document alles wat veel stappen heeft. Als je documentatie hebt, volg het dan als een checklist, zodat je kunt zien of het goed genoeg is of dat het verouderd, incompleet of fout is. Zelfs als je het maar één keer doet - voordat je je rapport schrijft, schrijf dan een lijst van alle dingen die erin moeten gaan.

Track to-dos vooral als het vergeten een probleem is. Alles wat je moet doen en niet doet op dit moment moet daar naar binnen gaan. Volg ze allemaal op hun plaats en blijf teruggaan naar je to-do lijst. Vertrouw niet op post-it notities die opgevouwen en verstopt zijn in uw achterzak.

Automaat waar mogelijk. Als je een lijst met vijf dingen hebt om in te typen, kun je dan een programma schrijven om die vijf dingen te doen en dan heb je maar één ding om fout te gaan? Als je software maakt, kun je dan automatische tests uitvoeren om bugs op te pikken wanneer je ze introduceert? Streef je naar 100% dekking? Test je met het doel je code te breken? Heeft u een continue integratie zodat u zich geen zorgen hoeft te maken over het vergeten van tests?

Ask voor een second opinion als u iets riskants doet dat u niet kunt controleren en waarvan u niet gemakkelijk kunt herstellen. Het is een gangbare praktijk voor software dat code altijd door iemand anders wordt getest voordat deze wordt geaccepteerd.

Learn. Elke gemaakte fout is een kans om het proces te herzien.

Zorg voor jezelf. Zoek tijd gedurende de dag om je geest te zuiveren en een paar minuten stilte of ontspanning te hebben. Voor het werk, na het werk, de lunchpauze, enz. Krijg genoeg slaap. Eet regelmatig en gezond.

Je zult natuurlijk nooit perfect zijn, maar er zijn manieren om de nauwkeurigheid te verbeteren. De beste manier is volgens mij om extra procedures in te voeren die niet alleen een dubbele controle van je eigen werk zijn, want mensen zijn van nature geneigd om kleine foutjes te maken. Het is niet erg waarschijnlijk dat je dit soort dingen opvangt door alleen maar “voorzichtiger te zijn” of “dubbel te controleren”, dus gewoon proberen dat is jezelf op een mislukking storten. Enkele specifieke suggesties:

1. 1. Eenheidstesten. Met de juiste unit tests, wanneer je een verandering in de code aanbrengt, voer je de tests op alles uit, en dat zal voor jou controleren of je per ongeluk een bug hebt geïntroduceerd.
2. 1. Betere inzetprocedure. Implementeer eerst naar een staging server, met behulp van de exacte commando’s die je zou gebruiken voor prod, en controleer daar of de implementatie correct is, voordat je naar de productie gaat.
3. 1. Bespaar de unit tests, zet tijd opzij in elke implementatie, zodra je denkt dat je klaar bent, om door je build heen te gaan en test zoveel mogelijk zelf te doen. Test niet alleen die gebieden waarvan je denkt dat je ze veranderd hebt.

Wanneer je een fout maakt, probeer dan oplossingen te bedenken die in deze richting gaan, om beveiligingen op te zetten tegen natuurlijke menselijke fouten, en presenteer deze ideeën aan je baas.

Ik werk al meer dan 10 jaar als software engineer/architect en ik kan met zekerheid zeggen dat je nooit alle fouten zult elimineren. Het beste advies dat ik je kan geven is om te bepalen welke taken het grootste risico vormen en stappen te ondernemen om dat risico te beperken.

1. Meestal is het sturen van een e-mail naar de verkeerde persoon geen probleem. Ik kon je niet vertellen hoe vaak ik een e-mail heb ontvangen die bedoeld was voor een van de andere Jennings’ die hier werken. Maar als je een e-mail stuurt die mogelijk gevoelige informatie bevat, neem dan altijd de tijd om de ontvangers en de inhoud te controleren.
2. 2. Als je een belangrijk document schrijft, schrijf dan een checklist/outline van wat er in moet staan en controleer de inhoud dubbel voordat je het verzendt.
3. 3. Gebruik voor het uitrollen van builds altijd een geautomatiseerd proces en implementeer indien mogelijk eerst naar een secundaire server. Mijn team implementeert onze Ruby services naar een secundaire server, test, en draait vervolgens de secundaire server om naar de primaire. Als er op dat moment problemen zijn, kunnen we altijd gewoon teruggaan naar de oude server. Als geen van beide mogelijk is, brengt dit een veel groter risico met zich mee, dus mijn advies is om extra tijd en aandacht aan de taak te besteden. Controleer alles dubbel en driedubbel voor elke stap die een hoog risico met zich meebrengt.
4. 4. Voor bugs in code, zorg ervoor dat je goede unit/integratietesten schrijft die de normale workflows en randgevallen afdekken. Het is een goed idee om ervoor te zorgen dat het project als geheel een zo hoog mogelijke unit-testdekking heeft om er zeker van te zijn dat als je iets verandert dat iets anders breekt, een unit-test zal falen en je de bug vroeg zult opvangen. Dit zal niet alle fouten opvangen, maar is een goed begin. Als de code eenmaal klaar is voor blackbox testen, test dan niet alleen de workflow die uw code raakt, maar analyseer ook welke andere delen van het project uw code mogelijk heeft beïnvloed en test die workflows ook. Blackbox testen moet ook betrekking hebben op zowel normale als randgevallen.

Buiten dit, zou ik gewoon zeggen om meer tijd en aandacht te besteden aan taken met een hoger risico dan je normaal gesproken zou doen voor de dagelijkse taken.

Hoe goed gedocumenteerd zijn de processen die je hebt? Bijvoorbeeld, het implementeren van de verkeerde build op de live-server klinkt alsof het een grote fout kan zijn die moet worden geminimaliseerd door het hebben van redundante controles om ervoor te zorgen dat build X naar server Y gaat, terwijl software misschien wel bugs in de code heeft omdat de dingen niet zo gemakkelijk te vangen zijn. Ik zou in de verleiding komen om oplossingen te creëren en deze voor te stellen aan de baas, zodat sommige fouten in de toekomst kunnen worden vermeden. Wees je bewust van wat je misschien een paar keer wilt controleren en wat misschien niet zo geweldig is om een hoop controles tegen te doen.

Helaas ben je een mens en dus zullen er fouten** gebeuren. Perfectie wordt zelden bereikt omdat meer dan een paar van de zogenaamde groten in de sport het winnende schot hebben gemist zoals Michael Jordan. Als u wilt dat sommige therapieën kijken naar Cognitieve Gedragstherapie, Dialectische Gedragstherapie, evenals Acceptatie- en Engagementstherapie die zou worden gebruikt om de strijd aan te gaan met het negatieve denkpatroon dat u hier heeft van het willen perfect zijn. Fouten zullen gebeuren, de sleutel is om te overwegen hoe je erop reageert en hoe goed je emotionele intelligentie is, want zelfbewustzijn en zelfmanagement kan iets anders zijn om te bestuderen als je een ander idee wilt.

• *

Voor enigszins gedocumenteerde, zou ik overwegen om de documentatie bij te werken en meer controles toe te voegen die nuttig kunnen zijn voor de belangrijke dingen. Op een bepaalde manier is dit vergelijkbaar met mensen die zouden suggereren om een paar seconden te wachten met het proeflezen van een e-mail die je wilt sturen, zodat er geen typefouten in staan die in sommige gevallen een nuttige tip kunnen zijn.

Ik zit in hetzelfde schuitje als jij in sommige gevallen, maar ik heb een andere achtergrond. Toen we live code pushen bij mijn oude baan, hadden we geautomatiseerde processen op hun plaats. Bij de nieuwe baan kunnen we helaas geen geautomatiseerd proces in gang zetten. Daarom mis ik hier en daar kleine details die er niet zouden moeten zijn. Mijn manager is er veel aardiger in, maar teleurgesteld.

In ieder geval heb ik mezelf verbeterd door eerst stappen op een notitieblokje te zetten. Ik zorg ervoor dat ik de lijst met bestanden die ik wil pushen heb, en controleer het nog even voordat ik het doe. Ik heb ook een mentale procedure van wat ik ga doen voordat ik het doe. Het helpt. Doe net alsof je het doet voordat je het doet om er zeker van te zijn dat je niets vergeten bent.

Ik wil er ook graag aan toevoegen dat je bij je manager moet zijn. Een een op een en leg je uit hoe je het graag zou willen doen en hoe je het zou willen doen. Leg uit dat je hier en daar wat kleine details mist en dat je het graag zou willen verbeteren. Misschien kan hij suggesties geven, maar ik zou zeggen dat als hij je op kleine details dreigt te ontslaan, dat je daar rekening mee moet houden en je erop moet voorbereiden.