Trois choses vous aideront à être plus précis:

• utilisez des listes de contrôle et des procédures (rédigez les vôtres) et suivez-les. Incluez des étapes telles que «vérifier le serveur que vous ciblez». Lorsque les conséquences d'une erreur sont importantes, imprimez la liste et cochez les choses avec un stylo au fur et à mesure.
• lorsque la technologie vous aide, prenez un moment pour vérifier. Supposons que votre client de messagerie remplisse la ligne À après avoir tapé la première lettre. Ne tapez pas simplement la lettre et cliquez sur Envoyer. Arrêtez-vous et regardez et voyez ce qu'il a rempli.
• chaque fois que vous faites une erreur, demandez-vous pourquoi. Quelle étape avez-vous sauté? Qu'est-ce que vous n'avez pas regardé? Pourquoi la bonne et la mauvaise chose se ressemblaient-elles? Comment pourrait-il être plus facile d'être sûr que vous le faites correctement? Mettez à jour votre procédure avec ce que vous venez d'apprendre.

Au fil du temps, vous développerez des habitudes et des processus qui vous permettront de faire les choses correctement. En fait, c'est à peu près ce qu'est l'expérience.

Comment puis-je arrêter de faire des erreurs stupides au travail?

Vous avez un problème de qualité de travail et avez besoin d'un système pour détecter les erreurs afin de créer des commentaires appropriés pour améliorer / développer procédures personnelles et habitudes de travail. L ' amélioration de la qualité concerne le développement de mécanismes pour détecter les erreurs et leur cause , puis développer un plan d'action pour les corriger .

Étape 1: Reconnaissez que les erreurs ne sont pas «stupides» - elles sont graves. Vous risquez de perdre votre emploi à cause d'eux. Je pense qu'un grand indicateur de votre problème est que cela semble être des choses faciles à prévenir, et pourtant vous les faites toujours. En ne les empêchant pas, cependant, vous avez un problème sérieux.

Étape 2: Ralentissez. Trop souvent, les programmeurs et ingénieurs «rock star» sont considérés comme ceux qui bougent vite et furieusement - rien ne les arrête! La réalité est qu'ils ne sont pas comme ça. Il y a des situations où cela se produit, mais il y a beaucoup de situations où ce n'est pas vrai. Arrêtez de vous sentir pressé, respirez et ralentissez .

Étape 3: Avant de "terminer" quelque chose, arrêtez-vous et faites une pause, puis revenez-y et revoyez. Prenez un café, lisez un e-mail ou quelque chose qui ne vous distrait pas trop, pour ne plus penser à la tâche à accomplir afin d'avoir une nouvelle perspective lorsque vous y reviendrez. Vous pourriez avoir l'impression que cela vous ralentira ou réduira votre productivité. Cependant, cette approche vous permet de remarquer rapidement les erreurs, ce qui est important pour être productif. Donc, avant de cliquer sur "envoyer" - allez lire un autre e-mail ou vérifiez l'état d'un serveur ou quelque chose. Il ne s’agit pas seulement d’écrire du code.

Étape 4: Lorsque vous trouvez une erreur, ne vous contentez pas de la corriger. Prenez un moment pour essayer de comprendre pourquoi l'erreur s'est produite. Où vous précipitez-vous? Erreur de copier / coller? Se fier au travail ou à l'opinion de quelqu'un d'autre? Cela vous aidera à mieux connaître la cause des erreurs au moment où elles se produisent . Le savoir plus tard n'est pas très utile, comme vous le savez.

Étape 5: Suivez vos progrès. Faites attention à l'utilité de vos nouvelles habitudes et pratiques. Gardez une feuille de calcul pour compter les erreurs ou les problèmes que vous avez trouvés après une pause. Notez également si une découverte a empêché quelque chose qui aurait irrité votre patron ou qui aurait été embarrassant. Cela développe votre capacité à mieux évaluer l'acceptabilité de votre propre travail et à essayer d'apprendre quelles sont les habitudes les plus efficaces.

Étape 6: Développez des procédures et des listes de contrôle (ou mettez à jour celles existantes) où vous voyez des modèles émerger de vos observations ci-dessus. Vous ne pouvez pas développer des listes de contrôle ou des procédures pour tout , donc après un certain temps (ou même assez rapidement) vous trouverez des modèles d'erreurs où vous pouvez créer une méthode reproductible pour éviter certains types d'erreurs. Ceci n'est utile que pour les tâches fréquentes et complexes. Sinon, vous serez tenté de ne pas vérifier la liste, de ne pas la tenir à jour ou de créer plus de listes et de procédures que vous ne pouvez en gérer, ce qui les rendra obsolètes et obsolètes, ce qui entraînera peut-être plus d'erreurs.

Essayez différentes approches pour découvrir où se trouvent vos erreurs avant qu'elles ne deviennent des problèmes. Alors que beaucoup de réponses ici se concentrent sur le développement de processus / procédures / listes de contrôle (en particulier autour du développement de code), la prémisse de la "gestion de la qualité" ou de "l'amélioration de la qualité" a à voir avec la détection d'erreurs comme moyen de rétroaction pour le développement de processus et / ou amélioration. Vous ne pouvez pas développer un «meilleur» processus si vous ne connaissez pas la cause des erreurs. Cherchez à découvrir la cause des erreurs Il est fort probable que vous vous précipitiez et que vous ne "revérifiez" pas votre travail. Voici quelques conseils pour rendre un rythme plus lent plus productif.

Arrêtez de travailler. C'est la seule façon d'arrêter de faire des erreurs.

Non, sérieusement: vous allez toujours faire un certain nombre d'erreurs. Cela fait partie d'être humain (ce que je pense être sûr de supposer que vous l'êtes). Tout développeur professionnel va produire du travail avec un certain nombre de bogues, et c'est OK. C'est la raison pour laquelle nous avons des services comme le développement piloté par les tests, les tests unitaires et la qualité. Si votre responsable attend un logiciel sans bogue lors de la première passe, alors vous ne faites pas face à des attentes raisonnables.

Cela dit, nous vivons dans un monde où nous ne pouvons pas arrêter de travailler simplement parce que des erreurs se produisent , nous prenons donc des mesures pour réduire le risque d'erreur. Je travaille dans un atelier de fabrication, donc le slogan est Poke-yoke (littéralement japonais pour Mistake-Proofing); qui est un processus automatisé conçu pour éliminer l'erreur humaine. Cela signifie l'automatisation. Je vivement recommande de passer à un processus de création automatisé pour le déploiement de logiciels en production. Cela nécessitera la participation de plus qu'un seul développeur, mais cela vaut la peine d'aller aussi loin que possible.

Là où vous ne pouvez pas automatiser, prenez votre temps. De nombreuses erreurs peuvent être évitées en prenant le temps de passer en revue avant de commettre une action. Prenez une minute pour examiner votre code avant de valider les modifications. Passez une minute supplémentaire à examiner les e-mails avant d'appuyer sur ce fatidique bouton Envoyer.

Enfin, n'ayez pas peur de demander de l'aide. En tant que développeur, l'un de mes premiers plans d'action après avoir trouvé un bogue est de demander à un collègue de confiance de jeter un coup d'œil. Un regard neuf peut voir toutes sortes de problèmes que vous avez inconsciemment filtrés. Et si vous n'avez pas de collègue de confiance, trouvez un nouvel emploi; on dirait que vous êtes un développeur de niveau junior / intermédiaire et que vous avez besoin d'un système de support pour grandir en tant que développeur. Avoir d'autres développeurs de logiciels sur lesquels rebondir des idées n'est pas une partie facultative de votre développement en tant que développeur de logiciels professionnel.

En bref: Automatisez autant que possible, prenez votre temps quand ce n'est pas le cas et n'ayez pas peur de demander de l'aide.

Vous ne serez bien sûr jamais parfait, mais il existe des moyens d'améliorer la précision. Le meilleur cours que je pense est d'introduire des procédures supplémentaires qui ne se contentent pas de vérifier votre propre travail, car les gens sont naturellement enclins à faire de petites erreurs. Il est peu probable que vous attrapiez ce genre de choses simplement en «faisant plus attention» ou en «revérifiant», donc simplement essayer cela vous met en échec. Quelques suggestions spécifiques:

1. Tests unitaires. Avec des tests unitaires appropriés, chaque fois que vous apportez une modification au code, exécutez les tests sur tout, et cela vérifiera à nouveau si vous avez introduit un bogue par inadvertance.

2. Mieux procédure de déploiement. Déployez d'abord sur un serveur intermédiaire, en utilisant les commandes exactes que vous utiliseriez pour prod, et vérifiez que le déploiement est correct, avant de passer en production.

3. À l'exception des tests unitaires, mettez de côté au cours de chaque déploiement, une fois que vous pensez que vous avez terminé, de passer par votre build et de tester à nouveau autant que vous le pouvez vous-même. Ne testez pas seulement les domaines que vous pensez avoir modifiés.

Chaque fois que vous faites une erreur, essayez de penser à des solutions dans ce sens, pour mettre en place des garde-fous contre les erreur humaine, et présentez ces idées à votre patron.

Non, vous n'éliminerez pas les erreurs. Mais vous pourrez peut-être attraper les plus importants. Il est important d'être conscient de ce que vous faites et de rechercher des moyens de le faire de manière plus sûre.

Identifiez les entreprises à risque . Vous ne pouvez pas être sur vos gardes chaque seconde de la journée, mais tout le monde fait de petites erreurs toute la journée. La plupart des erreurs peuvent être corrigées sans effort, alors faites mieux pour remarquer quand quelque chose a le potentiel de mal tourner d'une manière qui ne peut pas être corrigée aussi facilement. Toute communication avec un client, tout déploiement sur un site, toute modification globale d'un document, etc.

Question ce que vous faites. Comprenez-vous ce que vous faites, pourquoi et comment? Cela peut-il être fait de manière plus sûre? Êtes-vous sûr qu'il vaut mieux le faire que de ne pas le faire?

Pause avant de poursuivre des efforts risqués. N'envoyez pas d'e-mail sans vérifier les destinataires, l'objet, le contenu et les pièces jointes. Un par un. Prends ton temps. L'envoi d'un devis pour le client A au client B pourrait perdre les deux clients. Mieux vaut passer environ une minute à le vérifier. Ne soyez pas tenté de vous précipiter, même en cas d '"urgence".

Ayez un plan de récupération . Sachez à l'avance ce que vous ferez en cas de problème. Préparez-vous pour que si vous avez besoin de rectifier votre erreur, vous puissiez le faire rapidement - mais sans vous précipiter. Comment saurez-vous si vous avez fait quelque chose de mal? Existe-t-il un moyen de le savoir plus tôt?

Documentez tout ce qui comporte plusieurs étapes. Si vous avez de la documentation, suivez-la comme une liste de contrôle pour savoir si elle est suffisamment bonne ou si elle est obsolète, incomplète ou défectueuse. Même si vous ne le faites qu'une seule fois - avant de rédiger votre rapport, écrivez une liste de tout ce qui doit être inclus.

Suivi des tâches , en particulier si l'oubli pose un problème. Tout ce que vous devez faire et que vous ne faites pas pour le moment doit y figurer. Suivez-les tous en un seul endroit et revenez à votre liste de tâches. Ne vous fiez pas aux post-it pliés et rangés dans votre poche arrière.

Automatisez dans la mesure du possible. Si vous avez une liste de cinq choses à taper, pouvez-vous écrire un programme pour faire ces cinq choses et alors vous n'avez qu'une chose à vous tromper? Si vous créez un logiciel, pouvez-vous exécuter des tests automatisés pour détecter lorsque vous introduisez des bogues? Visez-vous une couverture à 100%? Faites-vous des tests dans le but de casser votre code? Avez-vous une intégration continue pour ne pas avoir à vous soucier d'oublier d'exécuter des tests?

Demandez un deuxième avis si vous faites quelque chose de risqué que vous ne pouvez pas vérifier et ne peut pas facilement récupérer. Il est courant pour les logiciels que le code soit toujours testé par quelqu'un d'autre avant d'être accepté.

Apprendre . Chaque erreur commise est l'occasion de réviser le processus.

Prenez soin de vous . Trouvez du temps pendant la journée pour vider votre esprit et avoir quelques minutes de silence ou de détente. Avant le travail, après le travail, les pauses déjeuner, etc. Dormez suffisamment. Mangez régulièrement et sainement.

Je travaille comme ingénieur / architecte logiciel depuis plus de 10 ans et je peux affirmer avec certitude que vous n'éliminerez jamais toutes les erreurs. Le meilleur conseil que je puisse vous donner est de déterminer quelles tâches sont les plus risquées et de prendre des mesures pour atténuer ce risque.

1. La plupart du temps, envoyer un e-mail à la mauvaise personne n'est pas grosse affaire. Je ne pourrais pas vous dire combien de fois j'ai reçu un e-mail destiné à l'un des autres Jennings qui travaillent ici. Mais si vous envoyez un e-mail qui peut contenir des informations sensibles, prenez toujours le temps de vérifier les destinataires et le contenu.
2. Si vous rédigez un document important, rédigez une liste de contrôle / un aperçu des besoins pour y être et vérifier le contenu avant de le soumettre.
3. Pour déployer des builds, utilisez toujours un processus automatisé et déployez d'abord sur le serveur secondaire si possible. Mon équipe déploie nos services Ruby sur un serveur secondaire, teste, puis retourne le serveur secondaire en serveur principal. S'il y a des problèmes à ce stade, nous pouvons toujours revenir à l'ancien serveur. Si aucune de ces choses n'est possible, cela comporte un risque beaucoup plus élevé, donc mon conseil est de consacrer plus de temps et d'attention à la tâche. Vérifiez tout deux fois et trois fois pour chaque étape qui comporte un niveau de risque élevé.
4. Pour les bogues dans le code, assurez-vous que vous écrivez de bons tests unitaires / d'intégration qui couvrent les flux de travail normaux et les cas extrêmes. C'est une bonne idée de s'assurer que le projet dans son ensemble a une couverture de tests unitaires aussi élevée que possible pour s'assurer que si vous changez quelque chose qui casse quelque chose d'autre, un test unitaire échouera et vous attraperez le bogue tôt. Cela n'attrapera pas toutes les erreurs, mais c'est un bon début. Une fois que le code est prêt pour le test de la boîte noire, ne testez pas simplement le flux de travail que votre code touche, analysez les autres parties du projet sur lesquelles votre code a pu avoir un impact et testez également ces flux de travail. Les tests Blackbox doivent également couvrir les cas normaux et marginaux.

En dehors de cela, je dirais simplement de consacrer plus de temps et d'attention aux tâches à risque plus élevé que vous ne le feriez normalement pour les tâches quotidiennes.

Dans quelle mesure les processus dont vous disposez sont-ils bien documentés? Par exemple, déployer la mauvaise version sur le serveur en direct semble être une erreur majeure qui devrait être minimisée en ayant des vérifications redondantes en place pour s'assurer que la version X va au serveur Y alors que le logiciel peut bien avoir des bogues dans le code car les choses peuvent ne pas être attrapé aussi facilement. Je serais tenté de créer des solutions et de les proposer au patron afin d'éviter certaines erreurs à l'avenir. Soyez conscient de ce que vous voudrez peut-être vérifier plusieurs fois et de ce qui n'est peut-être pas génial de faire un tas de vérifications.

Malheureusement, vous êtes un humain et donc les erreurs seront fortes > arriver. La perfection est rarement atteint en plus de quelques-uns des grands noms soi-disant dans le sport manqué le jeu gagnant tir comme Michael Jordan. Si vous voulez des thérapies, regardez la thérapie cognitivo-comportementale, la thérapie comportementale dialectale, ainsi que la thérapie d'acceptation et d'engagement qui seraient utilisées pour combattre le schéma de pensée négatif que vous avez ici de vouloir être parfait. Des erreurs vont se produire, la clé est de réfléchir à la manière dont vous y répondez et à la qualité de votre intelligence émotionnelle, car la conscience de soi et l'autogestion pourraient être quelque chose d'autre à étudier si vous voulez une autre idée.

Pour un peu documenté, j'envisagerais de mettre à jour la documentation et d'ajouter plus de contrôles qui pourraient être utiles pour les choses importantes. D'une certaine manière, cela ressemble à des personnes qui suggéreraient d'attendre quelques secondes avant de relire un e-mail que vous souhaitez envoyer afin qu'il ne contienne pas de fautes de frappe qui peuvent être un conseil utile dans certains cas.

Je suis dans le même bateau que vous dans certains cas, mais je viens d'un milieu différent. Lorsque nous transmettons du code à mon ancien travail, nous avions des processus automatisés en place. Au nouvel emploi, nous ne pouvons malheureusement pas mettre en processus automatisé. En tant que tel, je manque de petits détails ici et là qui ne devraient pas être. Mon manager est bien plus gentil à ce sujet, mais déçu.

De toute façon, je me suis amélioré en m'assurant d'abord d'écrire les étapes sur un bloc-notes. Je m'assure d'avoir la liste des fichiers que je souhaite afficher et la revérifier avant de le faire. J'ai aussi une procédure mentale de ce que je vais faire avant de le faire. Ça aide. Faites simplement semblant de le faire avant de le faire pour vous assurer de ne rien oublier.

Je voudrais également ajouter que vous devriez obtenir avec votre responsable. Un à un et expliquez que vous aimez vous améliorer et décrivez comment vous aimeriez le faire. Expliquez que vous manquez quelques petits détails ici et là et que vous souhaitez améliorer. Peut-être pourrait-il donner des suggestions, mais je dirais que s'il menace de vous renvoyer pour de petits détails, c'est quelque chose que vous devrez considérer et vous préparer.