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

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érifiez le serveur que vous ciblez”. Lorsque les conséquences d'une erreur sont importantes, imprimez réellement la liste et cochez les cases au fur et à mesure avec un stylo.
• lorsque la technologie vous aide, prenez un moment pour vérifier. Supposons que votre client de messagerie remplisse la ligne “À” après que vous ayez tapé la première lettre. Ne vous contentez pas de taper la lettre et de cliquer sur Envoyer. Arrêtez-vous et regardez ce qu'elle a rempli.
• chaque fois que vous faites une erreur, demandez-vous pourquoi. Quelle étape avez-vous sautée ? Qu'est-ce que vous n'avez pas regardé ? Pourquoi la bonne chose et la mauvaise chose se ressemblent-elles tant ? Comment pourrait-il être plus facile de s'assurer que vous faites bien les choses ? Mettez à jour votre procédure avec ce que vous venez d'apprendre.

Avec le 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 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écouvrir les erreurs afin de créer un retour d'information approprié pour améliorer/développer les procédures personnelles et les habitudes de travail. L'amélioration de la qualité est liée au développement de mécanismes permettant de découvrir les erreurs et leur cause, puis d'élaborer un plan d'action pour les corriger.

Étape 1 : Reconnaître que les erreurs ne sont pas “idiotes” - elles sont graves. Vous risquez de perdre votre emploi à cause d'elles. Je pense qu'un indicateur important de votre problème est que ces erreurs semblent faciles à prévenir, et pourtant vous continuez à les commettre. Mais en ne les empêchant pas, vous avez un problème grave.

Étape 2 : Ralentissez. Trop souvent, les programmeurs et les ingénieurs “rock stars” sont considérés comme ceux qui vont vite et qui sont furieux - 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é, prenez une respiration et ralentissez.

Étape 3 : Avant de “finir” quelque chose, arrêtez-vous et faites une pause, puis revenez-y et passez en revue. Prenez un café, lisez un e-mail ou quelque chose de pas trop distrayant, pour vous changer les idées et avoir une nouvelle perspective lorsque vous y reviendrez. Vous aurez peut-être l'impression que cela vous ralentira ou réduira votre productivité. Toutefois, cette approche vous permet de remarquer les erreurs à un stade précoce, ce qui est important pour être productif. Donc, avant d'appuyer sur “envoyer”, allez lire un autre courriel ou vérifiez l'état d'un serveur ou autre 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 ? Une erreur de copier/coller ? Dépendance à l'égard du travail ou de l'opinion de quelqu'un d'autre ? Cela vous aidera à être plus conscient de la cause des erreurs au moment où elles se produisent. Le découvrir plus tard n'est pas très utile, comme vous le savez.

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

Étape 6 : Élaborez des procédures et des listes de contrôle (ou mettez à jour celles qui existent déjà) où vous voyez des schémas se dégager de vos observations ci-dessus. Vous ne pouvez pas élaborer des listes de contrôle ou des procédures pour tout, donc au bout d'un certain temps (ou même assez rapidement) vous trouverez des modèles d'erreurs où vous pourrez créer une méthode reproductible pour prévenir certains types d'erreurs. Cette méthode 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 vous risquez de faire plus de listes et de procédures que vous ne pouvez en gérer, ce qui les rendrait obsolètes et dépassées - ce qui pourrait entraîner davantage d'erreurs.

Essayez différentes approches pour découvrir où se trouvent vos erreurs avant qu'elles ne deviennent des problèmes. Bien que la plupart des réponses se concentrent sur le développement de processus/procédures/listes de contrôle (en particulier autour du développement de code), le principe de “gestion de la qualité” ou “amélioration de la qualité” a trait à la détection des erreurs comme moyen de retour d'information pour le développement et/ou l'amélioration des processus. Vous ne pouvez pas développer un “meilleur” processus si vous ne connaissez pas la cause des erreurs. Travaillez à la découverte de la cause des erreurs Il est fort probable que vous vous dépêchiez 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 : Tu vas toujours faire un certain nombre d'erreurs. Cela fait partie de l'être humain (ce que je crois pouvoir supposer que vous êtes). Tout développeur professionnel va produire un travail avec un certain nombre de bugs, et c'est normal. 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 s'attend à un logiciel sans bogues dès le premier passage, alors vous n'avez pas affaire à des attentes raisonnables.

Cela dit, nous vivons dans un monde où nous ne pouvons pas arrêter de travailler juste parce que des erreurs se produisent, alors nous prenons des mesures pour réduire le risque d'erreur. Je travaille dans un atelier de fabrication, donc la phrase d'accroche est Poke-yoke (littéralement, en japonais, “vérification des erreurs”), qui est un processus automatisé conçu pour éliminer l'erreur humaine. Il s'agit d'un processus automatisé conçu pour éliminer l'erreur humaine, c'est-à-dire l'automatisation. Je recommande définiment de passer à un processus de construction automatisé pour le déploiement de logiciels en production. Cela nécessitera l'implication de plus d'un seul développeur, mais cela vaut la peine de pousser 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 les examiner avant d'engager une action. Prenez une minute pour revoir votre code avant de faire des changements. Passez une minute supplémentaire à revoir vos e-mails avant d'appuyer sur le bouton d'envoi fatidique.

Enfin, n'ayez pas peur de demander de l'aide. En tant que développeur, l'une de mes premières actions lorsque je trouve un bogue est de demander à un collègue de confiance d'y jeter un coup d'œil. Un regard neuf permet de voir toutes sortes de problèmes que vous avez filtrés inconsciemment. Et si vous n'avez pas de collègue de confiance, trouvez un nouveau travail ; on dirait que vous êtes un développeur de niveau junior/moyen, et que vous avez besoin d'un système de soutien pour évoluer en tant que développeur. Avoir d'autres développeurs de logiciels pour faire rebondir vos idées n'est pas une partie optionnelle de votre développement en tant que développeur professionnel de logiciels.

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

Non, vous n'éliminerez pas les erreurs. Mais vous pourrez peut-être rattraper les plus importantes. Il est important d'être conscient de ce que vous faites et de chercher 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 tout au long de la journée. La plupart des erreurs peuvent être corrigées sans effort, alors améliorez votre capacité à remarquer quand quelque chose risque de mal tourner d'une manière qui ne peut pas être si facilement corrigée. 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 s'engager dans des entreprises risquées. N'envoyez pas de courriel sans avoir vérifié les destinataires, l'objet, le contenu et les pièces jointes. Un par un. Prenez votre temps. L'envoi d'un devis pour le client A à un client B pourrait faire perdre les deux clients. Mieux vaut passer une minute environ à vérifier. Ne soyez pas tenté de vous précipiter, même en cas d’“urgence”.

Disposez d'un plan de relance. Sachez à l'avance ce que vous ferez si quelque chose tourne mal. Préparez-vous de manière à pouvoir rectifier votre erreur rapidement - mais sans vous précipiter. Comment saurez-vous si vous avez fait quelque chose de mal ? Y a-t-il un moyen de le savoir plus tôt ?

Documentez tout ce qui comporte de nombreuses étapes. Si vous avez des documents, suivez-les comme une liste de contrôle afin de pouvoir dire s'ils sont assez bons ou s'ils sont périmés, incomplets ou défectueux. Même si vous ne le faites qu'une seule fois - avant de rédiger votre rapport, dressez une liste de toutes les choses qui doivent y figurer.

Piste des choses à faire surtout si l'oubli est un problème. Tout ce que vous devez faire et que vous ne faites pas en ce moment devrait y figurer. Suivez-les tous au même endroit et revenez sans cesse à votre liste de choses à faire. Ne vous fiez pas aux post-it pliés et rangés dans votre poche arrière.

Automate 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 ensuite vous n'avez qu'une seule chose à faire ? Si vous créez un logiciel, pouvez-vous effectuer des tests automatisés pour détecter les bogues que vous introduisez ? 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 inquiéter d'oublier de faire des tests ?

Demandez un deuxième avis si vous faites quelque chose de risqué que vous ne pouvez pas vérifier et dont vous ne pouvez pas vous remettre facilement. C'est une pratique courante pour les logiciels que le code soit toujours testé par quelqu'un d'autre avant d'être accepté.

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

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

Bien sûr, vous ne serez jamais parfait, mais il existe des moyens d'améliorer la précision. La meilleure solution, à mon avis, est d'introduire des procédures supplémentaires qui ne se limitent pas à une double vérification de 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 “étant plus prudent” ou en “vérifiant deux fois”, donc essayer cela revient à vous mettre en échec. Quelques suggestions spécifiques :

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

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

3. A l'exception des tests unitaires, réservez du temps dans chaque déploiement, une fois que vous pensez avoir terminé, pour passer en revue votre construction et en tester autant que vous le pouvez vous-même à nouveau. Ne vous contentez pas de tester les domaines que vous pensez avoir changés.

Chaque fois que vous faites une erreur, essayez de penser à des solutions dans ce sens, de mettre en place des protections contre l'erreur humaine naturelle, et présentez ces idées à votre patron.

Je travaille comme ingénieur en logiciel/architecte depuis plus de 10 ans, et je peux dire avec certitude qu'on n'élimine jamais toutes les erreurs. Le meilleur conseil que je puisse vous donner est de déterminer quelles sont les tâches qui présentent le plus grand risque et de prendre des mesures pour atténuer ce risque.

1. La plupart du temps, envoyer un courriel à la mauvaise personne n'est pas un problème. Je ne pourrais pas vous dire combien de fois j'ai reçu un courriel 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, faites une liste de contrôle de ce qu'il doit contenir et vérifiez le contenu avant de le soumettre
3. Pour le déploiement des builds, utilisez toujours un processus automatisé et déployez d'abord sur un serveur secondaire si possible. Mon équipe déploie nos services Ruby sur un serveur secondaire, les teste, puis bascule le serveur secondaire sur le serveur primaire. S'il y a des problèmes à ce stade, nous pouvons toujours revenir à l'ancien serveur. Si aucune de ces deux possibilités n'est possible, le risque est beaucoup plus élevé, c'est pourquoi je vous conseille de consacrer plus de temps et d'attention à cette tâche. Vérifiez deux fois et trois fois tout ce qui comporte un risque élevé à chaque étape.
4. En cas de bogue dans le code, assurez-vous que vous écrivez de bons tests unitaires/intégratifs qui couvrent les flux de travail normaux et les cas limites. 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 garantir que si vous changez quelque chose qui casse quelque chose d'autre, un test unitaire échouera et vous attraperez le bogue plus tôt. Cela ne permettra pas d'attraper 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 vous contentez pas de tester le flux de travail que votre code touche, mais analysez les autres parties du projet que votre code peut avoir influencées et testez également ces flux de travail. Le test de la boîte noire doit également couvrir les cas normaux et les cas limites.

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

Vos processus sont-ils bien documentés ? Par exemple, le déploiement d'une mauvaise version sur le serveur en direct semble être une erreur majeure qui devrait être réduite au minimum en mettant en place des contrôles redondants pour s'assurer que la version X est envoyée au serveur Y, alors que le logiciel peut très bien avoir des bogues dans le code car les choses ne sont pas toujours faciles à détecter. 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 pourriez vouloir vérifier plusieurs fois et de ce qui pourrait ne pas être si génial pour faire un tas de vérifications.

Malheureusement, vous êtes humain et donc des erreurs seront commises. La perfection est rarement atteinte, car plus d'un grand nombre de sportifs ont raté le tir gagnant, comme Michael Jordan. Si vous souhaitez bénéficier de certaines thérapies, vous pouvez vous tourner vers la thérapie comportementale cognitive, la thérapie comportementale dialectale, ainsi que la thérapie de l'acceptation et de l'engagement, qui vous permettront de combattre le schéma de pensée négatif que vous avez ici, à savoir le désir d'être parfait. Des erreurs peuvent se produire, la clé est de considérer comment vous y réagissez et quelle est la qualité de votre intelligence émotionnelle, car la conscience de soi et la gestion de soi pourraient être quelque chose d'autre à étudier si vous voulez une autre idée.

Pour les documents quelque peu documentés, j'envisagerais de mettre à jour la documentation et d'ajouter des contrôles supplémentaires qui pourraient être utiles pour les choses importantes. D'une certaine manière, cela ressemble à ce que font les gens qui suggèrent d'attendre quelques secondes avant de relire un e-mail que vous voulez envoyer afin qu'il ne contienne pas de fautes de frappe qui peuvent être utiles dans certains cas.

Je suis dans le même bateau que vous dans certains cas, mais je viens d'un milieu différent. Quand nous avons fait du push code en direct à mon ancien travail, nous avions des processus automatisés en place. Dans notre nouveau travail, nous ne pouvons malheureusement pas mettre en place de processus automatisés. Ainsi, il me manque ici et là de petits détails qui ne devraient pas l'être. Mon manager est beaucoup plus gentil à ce sujet, mais il est déçu.

En tout cas, je me suis amélioré en m'assurant d'abord que j'écrivais les étapes sur un bloc-notes. Je m'assure que j'ai la liste des dossiers que je veux pousser vers le haut, et je la vérifie deux fois avant de le faire. J'ai également une procédure mentale de ce que je vais faire avant de le faire. Cela m'aide. Il suffit de faire semblant de le faire avant de le faire pour être sûr de n'avoir rien oublié.

J'aimerais également ajouter que vous devriez vous mettre en rapport avec votre responsable. En tête à tête, expliquez que vous voulez vous améliorer et expliquez comment vous voulez le faire. Expliquez qu'il vous manque quelques petits détails ici et là et que vous aimeriez vous améliorer. Il pourrait peut-être vous faire des suggestions, mais je dirais que s'il menace de vous licencier pour de petits détails, vous devrez y réfléchir et vous préparer.