Come posso smettere di fare errori stupidi sul lavoro?

Tre cose vi aiuteranno ad essere più precisi:

• utilizzate le liste di controllo e le procedure (scrivete le vostre) e seguitele. Includete passaggi come ‘doppio controllo su quale server state puntando’. Quando le conseguenze di un errore sono elevate, stampate la lista e controllate le cose con una penna mentre andate.
• quando la tecnologia vi aiuta, prendetevi un momento per controllare. Dite che il vostro client di posta elettronica riempie la riga To dopo aver digitato la prima lettera. Non limitatevi a digitare la lettera e cliccate su Invia. Fermatevi e guardate cosa ha compilato.
• ogni volta che commettete un errore, chiedetevi perché. Che passo hai saltato? Cosa non hai guardato? Perché la cosa giusta e quella sbagliata erano così simili? Come potrebbe essere più facile essere sicuri di fare la cosa giusta? Aggiorna la tua procedura con quello che hai appena imparato.

Con il tempo, svilupperai abitudini e processi che ti assicureranno di fare le cose correttamente. In effetti, l'esperienza è proprio questo.

Come posso smettere di fare errori stupidi sul lavoro?

Hai un problema di qualità del lavoro e hai bisogno di un sistema per scoprire gli errori al fine di creare un feedback appropriato per improvvisare/sviluppare procedure personali e abitudini lavorative. Il miglioramento della qualità ha a che fare con lo sviluppo di meccanismi per scoprire gli errori e la causa degli stessi, quindi sviluppare un piano d'azione per correggerli.

Fase 1: Riconoscere che gli errori non sono “sciocchi” - sono gravi. Potreste perdere il vostro lavoro a causa di essi. Penso che un grande indicatore del vostro problema sia che queste sembrano cose facili da prevenire, eppure le state ancora facendo. Non prevenendoli, però, avete un problema serio.

Fase 2: Rallentare. Troppo spesso i programmatori e gli ingegneri “rockstar” sono visti come quelli che si muovono veloci e furiosi - niente li ferma! La realtà è che non sono così. Ci sono situazioni in cui questo accade, ma ci sono molte situazioni in cui non è vero. Smettila di sentirti affrettato, fai un respiro e rallenta.

Fase 3: Prima di “finire” qualcosa, fermati e prenditi una pausa, poi torna indietro e ripassa. Prendete un caffè, leggete un'e-mail, o qualcosa di non troppo distraente, per distogliere la vostra mente dal compito a portata di mano, in modo da avere una nuova prospettiva quando ci tornerete. Potreste avere la sensazione che questo vi rallenterà o ridurrà la vostra produttività. Tuttavia, questo approccio vi permette di notare gli errori in anticipo, il che è importante per essere produttivi. Quindi, prima di premere “invia” - andate a leggere un'altra e-mail o a controllare lo stato di un server o qualcosa del genere. Non si tratta solo di scrivere il codice.

Fase 4: Quando trovate un errore, non correggetelo. Prendetevi un momento per cercare di capire perché si è verificato l'errore. Dove vai di fretta? Errore di copia/incolla? Ti affidi al lavoro o all'opinione di qualcun altro? Questo ti aiuterà a essere più consapevole della causa degli errori al momento in cui si verificano. Scoprirlo in seguito non è molto utile, come sapete.

Fase 5: Monitorare i vostri progressi. Fate attenzione all'utilità delle vostre nuove abitudini e pratiche. Conservate un foglio di calcolo per contare gli errori o i problemi che avete trovato dopo una pausa. Inoltre, notate se una scoperta ha impedito qualcosa che avrebbe fatto arrabbiare il vostro capo o che sarebbe stato imbarazzante. Questo sviluppa la vostra capacità di autovalutare meglio l'accettabilità del vostro lavoro e anche di cercare di imparare quali sono le abitudini più efficaci.

Fase 6: Sviluppare procedure e checklist (o aggiornare quelle esistenti) in cui vedete emergere dei modelli dalle vostre osservazioni di cui sopra. Non è possibile sviluppare checklist o procedure per tutto, quindi dopo un po’ di tempo (o anche abbastanza rapidamente) si troveranno modelli di errori in cui è possibile creare un metodo riproducibile per prevenire certi tipi di errori. Questo è utile solo per compiti frequenti e complessi. Altrimenti sarete tentati di non controllare la lista, di non tenerla aggiornata o di fare più liste e procedure di quante possiate gestirne, rendendole obsolete e superate, il che potrebbe portare ad un maggior numero di errori.

Provate diversi approcci per scoprire dove si trovano i vostri errori prima che diventino problemi. Mentre molte delle risposte qui si concentrano sullo sviluppo di processi/procedure/elenchi di controllo (soprattutto per quanto riguarda lo sviluppo del codice), la premessa della “gestione della qualità” o del “miglioramento della qualità” ha a che fare con la rilevazione degli errori come mezzo di feedback per lo sviluppo e/o il miglioramento dei processi. Non si può sviluppare un processo “migliore” se non si conosce la causa degli errori. Lavorate alla scoperta della causa degli errori Molto probabilmente vi state solo affrettando e non “controllando due volte” il vostro lavoro. Questi sono alcuni consigli per rendere più produttivo un ritmo più lento.

Smettila di lavorare. È l'unico modo per smettere di fare errori.

No, seriamente: Farai sempre un certo numero di errori. Questo fa parte dell'essere umano (cosa che credo sia lecito supporre). Qualsiasi sviluppatore professionista produrrà un lavoro con un certo numero di bug, e questo va bene. Questo è il motivo per cui abbiamo cose come Test Driven Development, Unit Testing, e Reparti Qualità. Se il vostro manager si aspetta un software Bug-Free al primo passaggio, allora non avete a che fare con aspettative ragionevoli.

Detto questo, viviamo in un mondo in cui non possiamo smettere di lavorare solo perché gli errori accadono, quindi prendiamo provvedimenti per ridurre il rischio di errore. Io lavoro in un negozio di produzione, quindi lo slogan è Poke-yoke (letteralmente giapponese per Mistake-Proofing); che è un processo automatizzato progettato per eliminare l'errore umano. Questo significa automazione. Io definitamente raccomando di passare ad un processo di costruzione automatizzato per la distribuzione del software in produzione. Questo richiederà il coinvolgimento di più di un singolo sviluppatore, ma vale la pena spingere il più possibile.

Dove non si può automatizzare, prendetevi il vostro tempo. Molti errori possono essere evitati prendendo tempo per la revisione prima di commettere un'azione. Prendetevi un minuto per esaminare il vostro codice prima di commettere modifiche. Trascorrete il minuto in più per rivedere le e-mail prima di premere il fatidico pulsante Invia.

Infine, non abbiate paura di chiedere aiuto. Come sviluppatore, una delle mie prime azioni per trovare un bug è chiedere ad un collega fidato di dare un'occhiata. Un paio di occhi freschi possono vedere ogni tipo di problema che hai inconsciamente filtrato. E se non hai un collega fidato, trova un nuovo lavoro; sembra che tu sia uno sviluppatore di livello junior/medio, e hai bisogno di un sistema di supporto per crescere come Sviluppatore. Avere altri sviluppatori di software da cui far rimbalzare le idee non è una parte opzionale del tuo sviluppo come Sviluppatore Professionale di Software.

In breve: Automatizza dove possibile, prenditi il tuo tempo quando non lo è, e non aver paura di chiedere aiuto.

No, non eliminerete gli errori. Ma potresti riuscire a cogliere i più importanti. È importante essere consapevoli di ciò che si sta facendo e cercare modi per farlo in modo più sicuro.

Identificare gli sforzi rischiosi. Non si può stare in guardia ogni secondo della giornata - ma tutti commettono piccoli errori per tutto il giorno. La maggior parte degli errori possono essere corretti senza sforzo, quindi è meglio notare quando qualcosa ha il potenziale per andare storto in un modo che non può essere risolto così facilmente. Qualsiasi comunicazione con un cliente, qualsiasi distribuzione a un sito, qualsiasi cambiamento globale a un documento, ecc.

Question cosa stai facendo. Capisci cosa stai facendo, perché e come? Questo può essere fatto in modo più sicuro? Siete sicuri che sia meglio farlo che non farlo?

Pausa prima di procedere con iniziative rischiose. Non inviare un'e-mail senza aver controllato i destinatari, l'oggetto, il contenuto e gli allegati. Uno per uno. Prendetevi il vostro tempo. L'invio di un preventivo per il cliente A al cliente B potrebbe perdere entrambi i clienti. Meglio passare un minuto o poco più a controllarlo. Non siate tentati di affrettarvi, anche in caso di “emergenza”.

Avere un piano di recupero. Sappiate in anticipo cosa farete se qualcosa va storto. Preparatevi in modo che, se avete bisogno di correggere il vostro errore, possiate farlo rapidamente - ma senza fretta. Come saprete se avete fatto qualcosa di sbagliato? C'è un modo per scoprirlo prima?

Documento tutto ciò che ha molti passaggi. Se avete una documentazione, seguitela come una lista di controllo per capire se è abbastanza buona o se è obsoleta, incompleta o difettosa. Anche se lo fai solo una volta - prima di scrivere il tuo rapporto, scrivi una lista di tutte le cose che devono essere inserite.

Traccia fino a -dos soprattutto se l'oblio è un problema. Tutto ciò che dovete fare e non state facendo in questo momento dovrebbe andare lì dentro. Rintracciatele tutte in un unico posto e continuate a tornare alla vostra lista delle cose da fare. Non fare affidamento su post-it piegati e nascosti nella tasca posteriore.

Automatizzare dove possibile. Se avete una lista di cinque cose da scrivere, potete scrivere un programma per fare queste cinque cose e poi avete solo una cosa da sbagliare? Se state creando un software, potete eseguire test automatizzati per rilevare quando introducete dei bug? Puntate a una copertura al 100%? Fate test con l'obiettivo di rompere il vostro codice? Avete un'integrazione continua in modo da non dovervi preoccupare di dimenticare di eseguire i test?

Chiedete una seconda opinione se state facendo qualcosa di rischioso che non potete verificare e da cui non potete facilmente riprendervi. È una pratica comune per i software che il codice viene sempre testato da qualcun altro prima di essere accettato.

Imparare. Ogni errore commesso è un'opportunità per rivedere il processo.

Prendersi cura di se stessi. Trova il tempo durante il giorno per schiarirti la mente e avere qualche minuto di silenzio o di relax. Prima del lavoro, dopo il lavoro, pausa pranzo, ecc. Dormire a sufficienza. Mangiare regolarmente e in modo sano.

Naturalmente non sarete mai perfetti, ma ci sono modi per migliorare la precisione. Il corso migliore, a mio avviso, è quello di introdurre procedure aggiuntive che non siano solo un doppio controllo del proprio lavoro, in quanto le persone sono naturalmente inclini a commettere piccoli errori. Non è molto probabile che si possano prendere questo tipo di cose solo “facendo più attenzione” o “controllando due volte”, quindi solo provandoci si rischia di fallire. Alcuni suggerimenti specifici:

1. 1. Test dell'unità. Con i test unitari corretti, ogni volta che si effettua una modifica al codice, si eseguono i test su tutto, e questo controllerà per voi se avete inavvertitamente introdotto un bug.
2. 1. Migliore procedura di implementazione. 2. Prima di andare in produzione, eseguire il deploy su un server di staging, usando i comandi esatti che usereste per il prod, e verificare che il deploy sia corretto. 3. Bloccando i test delle unità, mettete da parte del tempo in ogni schieramento, una volta che credete di aver finito, per passare attraverso la vostra costruzione e testarne il più possibile di nuovo. Non limitatevi a testare quelle aree che pensate di aver cambiato.

Ogni volta che commettete un errore, cercate di pensare a soluzioni in questo senso, di mettere in atto misure di sicurezza contro l'errore umano naturale, e presentate queste idee al vostro capo.

Ho lavorato come ingegnere informatico/architetto per oltre 10 anni, e posso dire con certezza che non eliminerete mai tutti gli errori. Il miglior consiglio che posso darvi è quello di determinare quali sono i compiti più a rischio e di adottare misure per mitigare tale rischio.

1. La maggior parte delle volte, inviare un'e-mail alla persona sbagliata non è un grosso problema. Non saprei dirvi quante volte ho ricevuto un'e-mail destinata a uno degli altri Jennings che lavorano qui. Ma se state inviando un'e-mail che può contenere informazioni sensibili, prendetevi sempre il tempo di ricontrollare i destinatari e il contenuto.
2. Se state scrivendo un documento importante, scrivete una checklist/outline di ciò che deve esserci dentro e ricontrollate il contenuto prima di inviarlo.
3. 3. Per la distribuzione dei build, utilizzare sempre un processo automatizzato e, se possibile, distribuire prima sul server secondario. Il mio team distribuisce i nostri servizi Ruby su un server secondario, testa, e poi capovolge il server secondario in primario. Se ci sono problemi a quel punto, possiamo sempre tornare al vecchio server. Se nessuna di queste due cose è possibile, questo comporta un rischio molto più elevato, quindi il mio consiglio è di dedicare più tempo e attenzione al compito. Controllare due o tre volte tutto per ogni passo che comporta un alto livello di rischio. Per i bug nel codice, assicuratevi di scrivere dei buoni test di unità/integrazione che coprano i normali flussi di lavoro e i casi limite. È una buona idea assicurarsi che il progetto nel suo complesso abbia la più alta copertura di test unitari possibile per assicurare che se si cambia qualcosa che rompe qualcos'altro, un test unitario fallirà e si prenderà il bug in anticipo. Questo non catturerà tutti gli errori, ma è un buon inizio. Una volta che il codice è pronto per il test della blackbox, non limitatevi a testare il flusso di lavoro che il vostro codice tocca, analizzate quali altre parti del progetto il vostro codice può aver influito e testate anche questi flussi di lavoro. Il test della blackbox dovrebbe anche coprire sia i casi normali che quelli marginali.

Al di fuori di questo, direi solo di dedicare più tempo e attenzione alle attività a rischio più elevato di quanto si farebbe normalmente per le attività quotidiane.

Quanto sono ben documentati i processi di cui disponete? Per esempio, distribuire la build sbagliata sul server live suona come se potesse essere un errore importante che dovrebbe essere minimizzato avendo controlli ridondanti in atto per garantire che la build X vada al server Y mentre il software potrebbe avere dei bug nel codice in quanto le cose potrebbero non essere colte così facilmente. Sarei tentato di creare soluzioni e proporle al capo in modo che alcuni errori possano essere evitati in futuro. Siate consapevoli di ciò che potreste voler controllare un paio di volte e di ciò che potrebbe non essere così grande da fare un mucchio di controlli contro.

Purtroppo, siete umani e quindi gli errori accadranno. Raramente si raggiunge la perfezione, perché più di alcuni dei cosiddetti grandi dello sport hanno mancato il tiro vincente come Michael Jordan. Se volete alcune terapie, guardate la Terapia del Comportamento Cognitivo, la Terapia del Comportamento Dialettale, così come la Terapia dell'Accettazione e la Terapia dell'Impegno che verrebbe usata per combattere il modello di pensiero negativo che avete qui di voler essere perfetti. Gli errori accadranno, la chiave è considerare come rispondi ad essi e quanto è buona la tua intelligenza emotiva come autoconsapevolezza e autogestione potrebbe essere qualcos'altro da studiare se vuoi un'altra idea.

Per un po’ documentato, prenderei in considerazione l'aggiornamento della documentazione e l'aggiunta di ulteriori controlli che possono essere utili per le cose importanti. In un certo senso questo è simile alle persone che suggerirebbero di aspettare una manciata di secondi prima di correggere una e-mail che si vuole inviare, in modo che non contenga errori di battitura che in alcuni casi possono essere un utile suggerimento.

In alcuni casi sono nella vostra stessa barca, ma provengo da un ambiente diverso. Quando spingiamo il codice dal vivo nel mio vecchio lavoro, avevamo processi automatizzati. Nel nuovo lavoro, purtroppo, non possiamo mettere in atto processi automatizzati. Come tale, mi mancano piccoli dettagli qua e là che non dovrebbero esserci. Il mio manager è molto più gentile, anche se deluso.

In ogni caso ho migliorato me stesso facendo prima di tutto attenzione a scrivere dei passi su un blocco note. Mi assicuro di avere la lista dei file che voglio spingere verso l'alto, e la ricontrollo prima di farlo. Ho anche una procedura mentale di ciò che ho intenzione di fare prima di farlo. Aiuta. Basta far finta di farlo prima di farlo per essere sicuri di non aver dimenticato nulla.

Vorrei anche aggiungere che dovresti andare dal tuo manager. Uno contro uno, spiegandovi come vorreste migliorare e delineando come vorreste farlo. Spiegate che vi mancano alcuni piccoli dettagli qua e là e che vorreste migliorare. Forse potrebbe dare dei suggerimenti, ma direi che se minaccia di licenziarvi per piccoli dettagli, allora è una cosa che dovrete considerare e prepararvi.