Discussion :

[Olivier Famien]

Votre sentiment d’échec vous a-t-il déjà conduit au syndrome d’épuisement professionnel ?
Un développeur donne sa recette pour éviter cette situation

Le syndrome d’épuisement professionnel, appelé burnout en anglais, est un état de fatigue professionnel accentué par un désinvestissement du travail effectué. Il est souvent accompagné d’un sentiment d’échec et une perte de confiance en soi, car le travailleur n’arrive plus à gérer les différentes pressions au travail et à faire face aux exigences de son employeur.

Dans le domaine IT, la pression est quasi permanente lorsqu’il s’agit d’achever les projets dans des délais serrés, de respecter le cahier des charges du client, d’intégrer les nouvelles exigences qui n’avaient pas été définies au départ toujours en respectant les contraintes d’avant-projet.

Et nombreux sont les développeurs qui, sous l’effet de ces différentes pressions, perdent au fil des années le gout pour le travail, car ils n’arrivent plus à s’adapter aux variations et objectifs de l’entreprise dans laquelle ils se trouvent. S’ensuivent alors des échecs et le manque de confiance en soi qui peut finir par le syndrome d’épuisement professionnel.

Un développeur du nom de Karolis Ramanauskas, qui sait trop combien ce phénomène est grandissant dans l’environnement des développeurs, puisqu’il l’a déjà traversé à maintes reprises, a voulu apporter sa contribution en donnant des conseils afin de permettre aux développeurs de ne pas tomber dans cette situation ou pour d’autres de sortir de cet étau.

Pour pouvoir donner des solutions idoines, Ramanauskas s’est d’abord penché sur les causes probables de cet état de fatigue professionnel et a pu dégager 4 facteurs clés à la base de cette situation.


Les causes de l’épuisement professionnel

1. La première est d’ordre physique. En effet, pour le développeur, travailler du matin au soir sur son ordinateur est néfaste pour la santé et conduit à une situation de léthargie qui pourrait avoir comme corolaire de mauvaises habitudes, telles que grignoter pendant la journée, prendre des stimulants ou encore rester éveillé tardivement.

2. La seconde raison énoncée est que la programmation est un métier très stressant qui sollicite beaucoup le cerveau. Cela entraine donc une fatigue mentale.

3. La troisième raison avancée est qu’un développeur peut ressentir un état de burnout lorsque son travail n’est pas gratifiant. Dans ce cas, il lui est recommandé de prendre du recul et de réfléchir sur quelque chose sur lequel il aimerait travailler sans mettre en avant le facteur rémunération.

4. En quatrième position, Ramanauskas cite une source externe expliquant que « le syndrome d’épuisement professionnel est causé par le fait que vous effectuez à plusieurs reprises de grandes quantités de sacrifices ou d’efforts sur les problèmes à haut risque qui échouent. C’est le résultat d’une erreur de prédiction négative dans le noyau accumbens. Vous conditionnez efficacement votre cerveau à associer le travail et l’échec ».

Comme recommandations, le développeur donne deux groupes de solutions. D’une part, celles qui touchent à l’ensemble des travailleurs et d’autre part celles qui sont intimement liées aux développeurs.


Les solutions adressées au grand public

1. Ramanauskas recommande en premier point de bien manger. Cela sous-entend boire de l’eau au lieu de soda, manger régulièrement et intégrer des légumes et hydrates de carbone dans le régime alimentaire.

2. En second point, il recommande de bien dormir. Le développeur recommande d’avoir une quantité et une qualité suffisante de sommeil. Aussi, pour ne pas être absorbé dans son travail et passer les heures de sommeil, Ramanauskas conseille l’installation de l’application Flux qui adapte la couleur de l’écran aux différentes heures de la journée.

3. En troisième point, ne vous surmenez pas. Même s’il est vrai que la durée légale de travail journalier s’élève à 7 heures dans certains pays et 8 heures maximum dans d’autres pays, il est également démontré qu’après 4 heures de travail, la productivité décroit fortement. À long terme, cela devient insoutenable pour le développeur qui doit fournir des efforts de réflexion au quotidien.

4. En quatrième point, utilisez la technique Pomodoro. Elle consiste à déterminer le temps imparti pour effectuer un travail et à faire des pauses régulières après une durée définie. Par exemple, pour 25 minutes de travail, il est recommandé d’avoir 5 minutes de pauses. Cela permet d’évacuer le stress tout en restant concentré sur l’objectif à atteindre et le temps réservé pour le travail.

5. En cinquième point, restez actif. Il n’est nul besoin de se lancer dans un programme de gymnastique que vous ne pourrez pas continuer à long terme. Il suffit juste de changer quelques habitudes. Au lieu d’utiliser l’ascenseur, prenez les escaliers. Au lieu d’utiliser la voiture, utilisez le vélo pour vous rendre au travail, si bien entendu la distance vous le permet. Soyez inventif en intégrant des activités sportives dans votre quotidien.


Les solutions destinées aux développeurs

1. En général, il est recommandé de faire ce que l’on sait faire le mieux. Ce à quoi vous prenez le plus plaisir doit-être la chose avec laquelle vous occupez votre temps. Mais à faire la même chose tous les jours, il est facile de tomber dans la routine et de ne plus y prendre plaisir. C’est pourquoi, si vous développez des logiciels, consacrez 20 % de votre temps à faire tout et n’importe quoi avec d’autres technologies. Cela sous-entend de tester de nouvelles bibliothèques, de créer quelque chose de drôle qui n’a rien à voir avec votre travail, ou encore d'utiliser votre temps pour apprendre quelque chose que vous ne maitrisez pas, tel que la programmation fonctionnelle.

2. La programmation étant un métier qui peut entrainer la solitude, il est conseillé de prendre part à des rencontres, des conférences afin de rencontrer du monde ou encore d'écouter l’expérience d’autres développeurs à travers les podcasts afin de pouvoir surmonter ses propres difficultés.

3. Ne lésinez pas sur vos moyens pour acquérir un bon environnement de travail. Il va falloir mettre la main à la poche pour obtenir un bon PC qui ne rame pas, mais obéit au moindre clic afin de ne pas perdre du temps précieux à attendre gratuitement la fin d’une longue compilation. Si vous travaillez dans un environnement où il y a beaucoup de bruits, achetez un casque de haute qualité afin de vous isoler des bruits extérieurs. Par ailleurs, assurez-vous de disposer d’un fauteuil confortable, d’une table et de moniteurs bien positionnés.

4. Domptez vos outils de travail. Acquérir de bons outils est une chose, mais les maitriser est encore mieux. Si vous avez l’occasion de maitriser les raccourcis de vos outils à savoir votre EDI, votre éditeur de texte, des lignes de commande pour votre système d’exploitation, n’hésitez pas à le faire. En outre, si vous pouvez automatiser les tâches banales ou rébarbatives, faites-le. Cela vous fera avancer bien plus rapidement en cas de pépin et vous permettra d’éloigner le burnout assez loin de vous.

5. Donnez-vous du temps pour d’autres choses que la programmation. Sinon un jour vous vous réveillerez de votre sommeil et certainement vous vous haïrez de n’avoir pas eu de vie autre que la programmation. Prenez donc part à des manifestations culturelles, sportives, à la pêche, à la photographie, etc. En le faisant, vous pouvez même avoir des lumières sur des aspects de votre travail sur lequel vous butez depuis belle lurette simplement parce que vous avez le nez trop plongé dans votre code.

6. Si le travail de développeur que vous avez n’est pas motivant, pensez à changer de carrière en explorant d’autres horizons tels que l’administration systèmes, ou encore l’architecture d’information, etc. Peut-être, vous vous découvrirez une nouvelle passion dans ces différents emplois explorés.

7. Enfin, exécuter les tâches quotidiennes connues comme pouvant vous procurer une sensation de bien-être. Par exemple, achever les activités de tests de code, d’écriture de commentaires, d’amélioration des noms de variables dégagera des endorphines qui aideront à restaurer l’acte de travail. « Ceci est une astuce courte, mais très précieuse, car elle donne à notre cerveau un sentiment plus positif sur le travail que nous effectuons », a conclu Ramanauskas.

Source : Medium.com

Et vous ?

Que pensez-vous de la solution de Ramanauskas pour éviter le burnout ?

Est-elle réaliste ?

Voir aussi
Forum langages de programmation

[Paul TOTH]

ça ce n'est qu'une vision du burnout, il suffit de faire un tour sur WP pour en trouver deux autres !

Vision transactionnelle de Cary Cherniss
... Un travail souvent routinier contraste avec les envies de tâches variées, de stimulations, d’accomplissement. Le manque de coopération entre collègues, voire les conflits interpersonnels, s’ajoutent à ces écarts entre attentes et réalité.
Face à un environnement de travail décevant, la motivation initiale s’étiole et fait place à des attitudes de retrait...

Approche motivationnelle d'Ayala Pines
... Plus ils s’impliquent au départ, plus la probabilité d’être atteint par le syndrome est forte si les conditions de travail sont défavorables...ce n’est pas l’échec en tant que tel qui provoque le syndrome d’épuisement professionnel, c’est plutôt la perception que quels que soient les efforts, le sujet ne peut prétendre avoir un impact significatif.

Dans ces définitions ce n'est pas une question de bien dormir ou de bien manger, c'est une inadéquation entre les motivations du travailleur et la liberté d'action qu'on lui laisse. Exemple, je voudrais corriger des bugs pour rendre le produit meilleurs, mais on me demande de justifier de mon temps de travail, de remplir des tableaux statistiques sur le temps passé au support, sans que jamais aucun retour ne soit donné sur l'intérêt éventuel de ces tâches. J'ai un contrat de développeur et on me demande de remplir des tableaux Excel...au lieu de critiquer mes performances, ou la qualité de mon travail on me réclame un strict respect des horaires, quitte à ce que je sois présent sans travail à accomplir ou que je quitte le travail avec une tâche non terminée.

[eldran64]

Le point numéro 3 est peut être le plus difficile à mettre en œuvre: pour la partie PC, toutes les boites n'acceptent pas le BYOD.

Sinon, je suis d'accord avec le reste.

Globalement il faut aussi savoir accepter qu'on a des périodes de haut et de bas (inutile de se mettre de la pression supplémentaire quand cela ne va pas très fort).

[Traroth2]

Donc en gros, pour travailler sur des trucs intéressants, il faut être prêt à travailler gratuitement, et il ne faut pas hésiter à acheter soi-même un outil de travail performant. Déprimant...

[Uranne-jimmy]

Je suis assez d'accord sur les points qui permettent d'améliorer notre état moral et physique par rapport au travail. Sans parler de burnout, faire ce qu'il dit, dans la mesure où cela nous convient, est un facteur assez sympa pour se sentir mieux.
Ce qui m'amuse c'est qu'un certain nombre des recommandations qu'il propose pour les développeur, je les exécute déjà, simplement en écoutant ce que j'ai envie, dans le mesure où ça ne m'empêche pas d'être performant.

[el_slapper]

le point 1 est de la foutaise pure et simple. Si ma spécialité n'a aucune valeur ajoutée dans l'entreprise, j'ai intérêt à faire autre chose. Je déteste le système, et je ne connais rien à Linux, mais comme on manque de gens pour faire ça, j'ai du m'y coller pour des raisons opérationnelles. ça m'a fait chier, je n'ai pas été très bon, ni très productif, mais je m'en suis sorti, et on a maintenant des environnements de test qui ressemblent à quelque chose.

Je n'aime toujours pas le système, et je reste un pas-très-bon(euphémisme) en Linux.

ça fait partie de la vie professionnelle.

Après, il ne faut pas se contenter de manger du gravier. Mon chef sait que ça me fait chier, et si on arrive à trouver du budget pour une ressource système, il sait que ça me fera grand plaisir, et pourquoi. Rien que le fait de lui dire à quel point je déteste ça(et admire les maitres), ça m'a aidé à passer le cap. Mais j'ai été professionnel, et j'ai fait de mon mieux. En râlant parce que je suis un Français, et parce que ça aide à tenir.

[LSMetag]

Ayant déjà vécu le Burn Out, je trouve cet article de très bonne facture. Il y a beaucoup de points que j'applique déjà désormais. En effet, je vise la reconversion en Architecture de SI, par le biais d'une petite (pour l'instant) entreprise de prestation de service, avec le mode de fonctionnement qui m'a toujours réussi (les rares fois où j'ai pu l'appliquer).

@el_slapper : Malheureusement, râler n'a pas fait bouger mes patrons en ce qui me concerne. Faire ce qu'on sait le mieux faire est effectivement plus facile et rassurant mais il est aussi indiqué qu'il est bon de faire de la veille techno. Après, le travail n'est pas toujours drôle et il faut faire avec, mais quand ça devient récurrent, il est normal de songer à démissioner.

[el_slapper]

(.../...)@el_slapper : Malheureusement, râler n'a pas fait bouger mes patrons en ce qui me concerne. Faire ce qu'on sait le mieux faire est effectivement plus facile et rassurant mais il est aussi indiqué qu'il est bon de faire de la veille techno. Après, le travail n'est pas toujours drôle et il faut faire avec, mais quand ça devient récurrent, il est normal de songer à démissioner.

Pour l'instant, le poste qui me libérerait(moi et deux autres, pour être précis) de ce fardeau est juste une idée qui circule entre les chefs. Certains sont convaincus, d'autres pas. Mais si tu ne râles pas, le chef ne va pas se poser de questions. Peut-être que dans dix ans je continuerait a avoir 25% de mes tâches en système, et je suis aussi doué pour ça que pour être pivot au basket(je mesure 1m64). Mais au moins ils savent que c'est un problème pour moi, et ça change la manière dont ils me donnent cette partie du boulot.

Après, démissionner, c'est à double tranchant, on sais ce qu'on perd, pas ce qu'on gagne. Sur les 75 autres % de ce nouveau job, j'y ai clairement gagné. Il faut savoir ce que l'on veut. Mais le dream job sans contreparties, ça n'existe pas.

[Marco46]

Dans le domaine IT, la pression est quasi permanente lorsqu’il s’agit d’achever les projets dans les délais serrés, de respecter le cahier de charge du client, d’intégrer les nouvelles exigences qui n’avaient pas été définies au départ toujours en respectant les contraintes d’avant-projet.

Ca c'est juste de l'incompétence au niveau de la gestion du projet (proposition commerciale et contrat en particulier).

Si le chiffrage initial c'est 100 jours et que les modifs demandées après coup rajoutent 30 jours de plus il faut facturer 30 jours de plus et augmenter le délai de 30 jours.

C'est délirant de voir que dans l'informatique on puisse faire des choses comme ça. Allez vous faire construire une maison ou n'importe quoi d'autre et changez les plans en cours de route tout en demandant de ne rien payer de plus et le même délai qu'on rigole un peu ...

[Bousk]

Article sympa, qui m'a fait immédiatement pensé à Barney Stinson

[Gort'h]

Ca c'est juste de l'incompétence au niveau de la gestion du projet (proposition commerciale et contrat en particulier).

Si le chiffrage initial c'est 100 jours et que les modifs demandées après coup rajoutent 30 jours de plus il faut facturer 30 jours de plus et augmenter le délai de 30 jours.

C'est délirant de voir que dans l'informatique on puisse faire des choses comme ça. Allez vous faire construire une maison ou n'importe quoi d'autre et changez les plans en cours de route tout en demandant de ne rien payer de plus et le même délai qu'on rigole un peu ...

Oui c'est semble-t-il un élément qu'on trouve beaucoup en informatique.
Pour autant lorsque le client demande on peut difficilement passer outre. Après il y a effectivement des méthodes pour gérer ça.Les avenants commerciaux par exemple mais ce n'est que d'un point de vue financier. Côté délais en revanche...

[Marco46]

Oui c'est semble-t-il un élément qu'on trouve beaucoup en informatique.
Pour autant lorsque le client demande on peut difficilement passer outre.

Ben si, il suffit d'arrêter de faire n'importe quoi. Pour reprendre l'exemple du bâtiment, demande des travaux sur une certaine base puis déboule au milieu en disant bon ben finalement je voudrais que la salle de bain ne soit plus ici mais là pis rajoutez moi 3 m² ici pour la cuisine, etc ... Ca ne passera jamais.

Pourquoi dans l'informatique on voit ce genre d'horreurs ?

Yavait quelqu'un qui avait posté une vidéo sur ce thème assez marrante, ils avaient fait l'analogie avec la restauration. On voyait un client qui se comportait comme les clients dans l'informatique.

client : "Je voudrais un steak mais pas comme sur la carte, un truc simple moins cher vous voyez ?"
serveur : "Vous voulez donc un steak ?"
client : "Non je ne veux pas le steak de la carte, je veux un steak mais différent."
serveur : "C'est quoi un steak simple ?"
client : "C'est un steak. Mais c'est pas le steak de la carte vous comprenez ?"

Je schématise de mémoire mais en gros c'est ça et c'est souvent ce que font les clients.

[Gort'h]

Ben si, il suffit d'arrêter de faire n'importe quoi. Pour reprendre l'exemple du bâtiment, demande des travaux sur une certaine base puis déboule au milieu en disant bon ben finalement je voudrais que la salle de bain ne soit plus ici mais là pis rajoutez moi 3 m² ici pour la cuisine, etc ... Ca ne passera jamais.

Pourquoi dans l'informatique on voit ce genre d'horreurs ?

Yavait quelqu'un qui avait posté une vidéo sur ce thème assez marrante, ils avaient fait l'analogie avec la restauration. On voyait un client qui se comportait comme les clients dans l'informatique.

client : "Je voudrais un steak mais pas comme sur la carte, un truc simple moins cher vous voyez ?"
serveur : "Vous voulez donc un steak ?"
client : "Non je ne veux pas le steak de la carte, je veux un steak mais différent."
serveur : "C'est quoi un steak simple ?"
client : "C'est un steak. Mais c'est pas le steak de la carte vous comprenez ?"

Je schématise de mémoire mais en gros c'est ça et c'est souvent ce que font les clients.

L'analogie avec la restauration est mauvaise à mon avis.
Lorsqu'un client à un projet informatique il n'y a pas de carte où il choisit. Il part d'une feuille blanche et expose son besoin. Il faut l'aider à le faire émerger pour faire réaliser ce qu'il souhaite. Rien à voir avec un choix dans une liste.

Ensuite son besoin peut évoluer avec le temps.A partir du moment où il paie il a droit de faire des modifications dans ce qu'il avait initialement prévu.
Le seul problème selon moi c'est surtout qu'il est difficile de faire bouger les délais en fonction des modifications qui arrivent en cours de projet.

[garn]

Ben si, il suffit d'arrêter de faire n'importe quoi. Pour reprendre l'exemple du bâtiment, demande des travaux sur une certaine base puis déboule au milieu en disant bon ben finalement je voudrais que la salle de bain ne soit plus ici mais là pis rajoutez moi 3 m² ici pour la cuisine, etc ... Ca ne passera jamais.

en fait, si (tant que c'est pas construit, et en payant les suppléments et le temps de rallonge. on a fait ca l'année dernière (en informatique, pas en batiment ) : périodiquement, on jetait quelques semaines de dev par la fenêtre parceque la nouveauté marketing / métier détruisait le modèle de données, les règles de gestion..;
bah, ca a mis plus longtemps, le client a raqué, mais ils ont eu ce qu'ils voulaient

Pourquoi dans l'informatique on voit ce genre d'horreurs ?

Yavait quelqu'un qui avait posté une vidéo sur ce thème assez marrante, ils avaient fait l'analogie avec la restauration. On voyait un client qui se comportait comme les clients dans l'informatique.

client : "Je voudrais un steak mais pas comme sur la carte, un truc simple moins cher vous voyez ?"
serveur : "Vous voulez donc un steak ?"
client : "Non je ne veux pas le steak de la carte, je veux un steak mais différent."
serveur : "C'est quoi un steak simple ?"
client : "C'est un steak. Mais c'est pas le steak de la carte vous comprenez ?"

Je schématise de mémoire mais en gros c'est ça et c'est souvent ce que font les clients.

je vais rajouter à la suite, après que le serveur soit parti se pendre

AMOA : "ok, donc on a dit un steak 300g, saignant, avec frite salade"
Client "mais j'ai pas dis ca"
AMOA : ah? ca vous va pas?
Client : euh ben si en fait, ca sera très bien

> My job
(bon, après on revient avec la photo du futur steak pour être sur et on nous fait changer ca pour du poulet, soit

[eulbobo]

je vais rajouter à la suite, après que le serveur soit parti se pendre

AMOA : "ok, donc on a dit un steak 300g, saignant, avec frite salade"
Client "mais j'ai pas dis ca"
AMOA : ah? ca vous va pas?
Client : euh ben si en fait, ca sera très bien

> My job
(bon, après on revient avec la photo du futur steak pour être sur et on nous fait changer ca pour du poulet, soit

Et quand tu lui sers son poulet parce que effectivement il voulait du poulet (et que tu as réussi à déduire qu'il le voulait pané), il te dit "Bizarre, Je m'attendais à ce que ça ait plus un goût de poisson pané... Y'a moyen de rajouter du ketchup à l'intérieur de la viande maintenant que c'est servi et que j'ai commencé à manger?"

[el_slapper]

en fait, si (tant que c'est pas construit, et en payant les suppléments et le temps de rallonge. on a fait ca l'année dernière (en informatique, pas en batiment ) : périodiquement, on jetait quelques semaines de dev par la fenêtre parceque la nouveauté marketing / métier détruisait le modèle de données, les règles de gestion..;
bah, ca a mis plus longtemps, le client a raqué, mais ils ont eu ce qu'ils voulaient (.../...)

ça, c'est un client sérieux.

Je me rappelle d'une TMA chez un grand compte, ou nous avions une procédure standard pour les modifs, et la modif unitaire, tout compris, coutait 9 heures. Ça marchait assez bien. Jusqu'au jour ou j'ai fait une connerie. Je teste un fichier de 10 enregs en dev, il marche bien, je teste rapidement un seul enreg en recette, il passe conforme aux nouvelles specs, hop, je livre confiant. A cause de différences techniques entre le dev et les autres environnements, plus rien ne marchait en recette et en prod à partir du deuxième enregistrement...une de mes plus grosses conneries, des centaines de courriers règlementaires ont été perdus à cause de ça.

Donc, ils nous ont demandé de faire des tests "complets", avec cahier de tests, traçage systématique des fichiers de test, et explication sommaire de chaque ligne. Et ça a marché. On a plus eu d'erreur du tout. On en avait pas beaucoup avant, mais là, plus du tout. Quand on leur a présenté la facture, à savoir 20 heures au lieu de 9, ils ont fait "gloups"... et payé. Ça, c'est du client sérieux. Qui sait pourquoi il paye et ce qu'il veut.

Mais, la plupart du temps, le client va gueuler que c'est trop cher, qu'il ne faut pas plus de 6 heures pour tout faire, ce retrouve avec de plus en plus de bugs, des prestas(les meilleurs) qui démissionnent, , des cahiers de tests truqués, etc... Et c'est là qu'on retombe sur les soucis précisés dans l'article. Je veux dire, j'étais le seul avec un background de testeur dans l'équipe, les collègues ont fait la gueule de devoir faire "tout ça"... mais ils ont vu les résultats, et qu'on leur donnait les moyens, et sont restés motivés. Alors que quand tout se casse la gueule, même le boulot rigolo devient démotivant. Bon, moi, je trouve ça rigolo aussi, les cahiers de tests, mais je ne suis pas cinglé au point de prendre mon cas pour une généralité...

[garn]

Et quand tu lui sers son poulet parce que effectivement il voulait du poulet (et que tu as réussi à déduire qu'il le voulait pané), il te dit "Bizarre, Je m'attendais à ce que ça ait plus un goût de poisson pané... Y'a moyen de rajouter du ketchup à l'intérieur de la viande maintenant que c'est servi et que j'ai commencé à manger?"

et dieu inventa le lotissement (et la facturation à la journée)

ça, c'est un client sérieux.

Je me rappelle d'une TMA chez un grand compte, ou nous avions une procédure standard pour les modifs, et la modif unitaire, tout compris, coutait 9 heures. Ça marchait assez bien. Jusqu'au jour ou j'ai fait une connerie. Je teste un fichier de 10 enregs en dev, il marche bien, je teste rapidement un seul enreg en recette, il passe conforme aux nouvelles specs, hop, je livre confiant. A cause de différences techniques entre le dev et les autres environnements, plus rien ne marchait en recette et en prod à partir du deuxième enregistrement...une de mes plus grosses conneries, des centaines de courriers règlementaires ont été perdus à cause de ça.

Donc, ils nous ont demandé de faire des tests "complets", avec cahier de tests, traçage systématique des fichiers de test, et explication sommaire de chaque ligne. Et ça a marché. On a plus eu d'erreur du tout. On en avait pas beaucoup avant, mais là, plus du tout. Quand on leur a présenté la facture, à savoir 20 heures au lieu de 9, ils ont fait "gloups"... et payé. Ça, c'est du client sérieux. Qui sait pourquoi il paye et ce qu'il veut.

Mais, la plupart du temps, le client va gueuler que c'est trop cher, qu'il ne faut pas plus de 6 heures pour tout faire, ce retrouve avec de plus en plus de bugs, des prestas(les meilleurs) qui démissionnent, , des cahiers de tests truqués, etc... Et c'est là qu'on retombe sur les soucis précisés dans l'article. Je veux dire, j'étais le seul avec un background de testeur dans l'équipe, les collègues ont fait la gueule de devoir faire "tout ça"... mais ils ont vu les résultats, et qu'on leur donnait les moyens, et sont restés motivés. Alors que quand tout se casse la gueule, même le boulot rigolo devient démotivant. Bon, moi, je trouve ça rigolo aussi, les cahiers de tests, mais je ne suis pas cinglé au point de prendre mon cas pour une généralité...

ca c'est sérieux, oui. ma 1ere mission en CP "recette" était comme ca, une équipe dédiée à des tests automatiques + non regression complete, cas par cas, ligne à ligne sur 2000+ règles de gestion. C'était 3 prestas à temps plein. (1500 / 2K euros pour le client par jour, sur 3 ans de projet, mais au sein d'un SI comptabilité, ca se comprend : si on merdait, c'était un impact financier direct )

Ce dont je parlais, c'était juste du a l'absence totale de gestion de projet correcte et de projection de besoin métier, parceque des fois (trop souvent à mon gout) tu tombes sur des clients qui jusqu'a présent n'ont jamais vraiment eu besoin de gérer un vrai projet informatique

[Escapetiger]

(...)
Ce dont je parlais, c'était juste du a l'absence totale de gestion de projet correcte et de projection de besoin métier, parceque des fois (trop souvent à mon gout) tu tombes sur des clients qui jusqu'a présent n'ont jamais vraiment eu besoin de gérer un vrai projet informatique

Bonjour,
Je me permets de rajouter à cet excellent topic l'article suivant (toute référence à une situation que vous avez déjà vécu est purement fortuite ..) :

Si vous faites partie de ceux qui fournissent des services à des clients (et nous sommes nombreux), vous savez d’expérience qu’il est plus facile de travailler avec certains de vos chers donneurs d’ordre qu’avec d’autres. (...)

http://www.hbrfrance.fr/chroniques-e...ts-impossibles
Comment gérer les clients impossibles ? - HBR

[Glutinus]

J'ai constaté à deux reprises des supérieurs qui foutent une pression monstrueuse pour un rien.

La première personne devait avoir un complexe de supériorité, elle aimait son armée de petits soldats sous ses ordres. Je sais qu'une développeuse a enchainé les arrêts maladie, un développeur a claqué la porte après sa période d'essai. Elle gérait par la terreur, demandaient à certaines de venir à 7h sans raison, forçait d'autres à enchaîner les corrections tant qu'il restait des fiches ouvertes.
Mais ce que l'histoire dit pas, c'est que quand un mec tient tête, elle le sort tout de suite. Y en a un qui l'a pris en porte-à-faux dans les couloirs de chez le client au retour d'une pause clope, que comme quoi elle tenait pas ses promesses, elle a paniqué quand des directeurs passaient, a demandé au mec de baisser le ton, mais il était remonté depuis des jours. Une semaine après, il a eu ce qu'il voulait : changer de projet et d'équipe, chez le même client.

La deuxième sans doute pareille, elle était sa petite reine, elle prenait des décisions malencontreuses, rejetaient la faute sur les autres dans leur dos. Dans mon projet il y avait littéralement du boulot pour 4 personnes (c'est simple, j'avais 4 clients, qui remplissaient des tonnes de demandes). J'ai dit que ce sera un jour pour chaque, ou alors il me faut trois personnes au moins pour contenir le flot d'anomalies. Elle a dit non. Du coup moi aussi j'ai dit non. J'ai dit "Puisque je suis tout seul dessus, ben ce sera comme je peux : 1 client par jour". Elle a voulu dire quelque chose, mais j'étais en position de force : j'étais le seul avec les sachants sur le projet.

Moralité : je ne suis pas dans la peau de tout le monde, ni avec le même niveau de responsabilités. Mais je sais quand il faut dire Niet à quelqu'un qui donne trop de pression. Très vite on se rend compte que ces personnes veulent plutôt satisfaire les autres pour leur propre compte (c'est pas des demandes règlementaires) et que les fleurs seront tamisées et nous retombent dessus. C'est comme ça du moins en tant que développeur ou whatever en informatique.

Sinon quoi dire ?
1/ les conseils de bon sens, bien manger, bien dormir, fractionner le boulot, c'est pareil pour tout, pour maigrir, pour allonger sa durée de vie, pour améliorer ses performances au sport. Une bonne hygiène de vie, c'est nécessaire pour tout.

Et sinon au cas par cas :

1. En général, il est recommandé de faire ce que l’on sait faire le mieux. Ce à quoi vous prenez le plus plaisir doit-être la chose avec laquelle vous occupez votre temps. Mais à faire la même chose tous les jours, il est facile de tomber dans la routine et de ne plus y prendre plaisir. C’est pourquoi, si vous développez des logiciels, consacrez 20 % de votre temps à faire tout et n’importe quoi avec d’autres technologies. Cela sous-entend de tester de nouvelles bibliothèques, de créer quelque chose de drôle qui n’a rien à voir avec votre travail, ou encore d'utiliser votre temps pour apprendre quelque chose que vous ne maitrisez pas, tel que la programmation fonctionnelle.

Oui, évidemment. Continuez à faire ce que vous savez faire, n'évoluez pas. Si vous êtes sur une niche, priez pour qu'elle existe jusqu'au jour de votre retraite. Si vous n'y êtes pas, priez pour que vous retrouviez du boulot à la fin de vos droits au chômage.

2. La programmation étant un métier qui peut entrainer la solitude, il est conseillé de prendre part à des rencontres, des conférences afin de rencontrer du monde ou encore d'écouter l’expérience d’autres développeurs à travers les podcasts afin de pouvoir surmonter ses propres difficultés.

Non, mais vous ne savez pas ? Les programmeurs sont des no-lifes isolés. D'ailleurs c'est pour ça que les SSII les aiment bien, ils rentrent jamais en synapse pour apprendre à se défendre. Donc mettez le nez dehors, et apprenez que vous n'êtes pas redevables de tout envers votre employeur.

3. Ne lésinez pas sur vos moyens pour acquérir un bon environnement de travail. Il va falloir mettre la main à la poche pour obtenir un bon PC qui ne rame pas, mais obéit au moindre clic afin de ne pas perdre du temps précieux à attendre gratuitement la fin d’une longue compilation. Si vous travaillez dans un environnement où il y a beaucoup de bruits, achetez un casque de haute qualité afin de vous isoler des bruits extérieurs. Par ailleurs, assurez-vous de disposer d’un fauteuil confortable, d’une table et de moniteurs bien positionnés.

Et si vous ne pouvez pas demander à votre employeur ?
Quelquefois, les plus intelligents d'entre eux acceptent le dual screen, qui au mon dieu améliore souvent la productivité de plus de 50%. Mais la plupart pensent qu'un PC datant de Mathusalem dans une salle photocopieuse sans fenêtre est parfait pour un développeur.

4. Domptez vos outils de travail. Acquérir de bons outils est une chose, mais les maitriser est encore mieux. Si vous avez l’occasion de maitriser les raccourcis de vos outils à savoir votre EDI, votre éditeur de texte, des lignes de commande pour votre système d’exploitation, n’hésitez pas à le faire. En outre, si vous pouvez automatiser les tâches banales ou rébarbatives, faites-le. Cela vous fera avancer bien plus rapidement en cas de pépin et vous permettra d’éloigner le burnout assez loin de vous.

Haha, à un moment sur une mission, régulièrement j'avais des tâches répététives à faire. J'ai amélioré en faisant une automatisation. Du coup je me suis retrouvé en bore-out.

5. Donnez-vous du temps pour d’autres choses que la programmation. Sinon un jour vous vous réveillerez de votre sommeil et certainement vous vous haïrez de n’avoir pas eu de vie autre que la programmation. Prenez donc part à des manifestations culturelles, sportives, à la pêche, à la photographie, etc. En le faisant, vous pouvez même avoir des lumières sur des aspects de votre travail sur lequel vous butez depuis belle lurette simplement parce que vous avez le nez trop plongé dans votre code.

Bref, développeurs, ne soyez pas no-life.

6. Si le travail de développeur que vous avez n’est pas motivant, pensez à changer de carrière en explorant d’autres horizons tels que l’administration systèmes, ou encore l’architecture d’information, etc. Peut-être, vous vous découvrirez une nouvelle passion dans ces différents emplois explorés.

Ouai, change de boulot espèce de crétin et laisse la part aux autres.
Et au passage, tu seras pas chef de projet, mais architecte (tu sais que c'est généralement mieux payé ?)

7. Enfin, exécuter les tâches quotidiennes connues comme pouvant vous procurer une sensation de bien-être. Par exemple, achever les activités de tests de code, d’écriture de commentaires, d’amélioration des noms de variables dégagera des endorphines qui aideront à restaurer l’acte de travail. « Ceci est une astuce courte, mais très précieuse, car elle donne à notre cerveau un sentiment plus positif sur le travail que nous effectuons », a conclu Ramanauskas.

MON DIEU MAIS VOUS AVEZ LE TEMPS DE COMMENTER ? 1 minute de commentaire = 1 minute de dev perdu mon dieu La livraison La livraison La livraison !

Ironie = off.

[samyaza]

Je me permets d'apporter mon expérience personnelle à ce sujet, afin que démontrer que sa causalité peut tout à fait être inversée.

Je suis diplômé d'une licence professionnelle dédiée au développement web, avec une expérience de presque 5 ans. Au sein de sociétés aux profils bien différents, je n'ai pu que constater des méthodes de management le plus souvent insoutenables et un taux de turn-over élevé. Pour moi, les débuts n'ont pas été faciles. J'ai décroché des postes où je passais plus de temps à administrer le site de vente et la base de données clients qu'à développer, et où les objectifs étaient complètement délirants. J'ai fini par trouver un "vrai" poste auquel je suis resté presque 4 ans. C'était une toute petite start-up, la gestion de projet y était déplorable, aucune notion de workflow, on n'était absolument pas formés, son président se vantait en privé d'avoir été à la tête d'entreprises par le passé ne versant aucun salaire grâce à des stagiaires, mais globalement, on m'a laissé faire mes preuves. J'ai aussi fait du dev Android pendant tout ce temps. Il a tout de suite été impressionné par mes performances, même s'il y a toujours eu des retards de livraison et de nombreuses heures supplémentaires, jamais payées. Petit à petit, j'ai acquis des compétences exclusives sur des projets essentiels. Même si des alternants, des commerciaux et des graphistes ont quitté la boîte parce qu'elle allait mal financièrement, je me savais plutôt en sécurité car nécessaire, même si j'étais déjà épuisé par mon travail, sans toutefois m'en rendre compte. C'est assez difficile de se plaindre, vu l'image idéaliste qu'a l'opinion publique de ce métier.

Un de mes collègues, qui était arrivé en même temps que moi, a changé d'employeur. Il semblait bien plus épanoui. Il vantait la gestion de projet irréprochable, l'entre-aide, la valorisation, le salaire bien plus élevé et la veille technologique qui se pratiquait dans sa nouvelle boîte. Pour lui, tout semblait aller au mieux désormais. J'ai donc décidé moi aussi d'aller voir ailleurs. J'ai passé plusieurs entretiens, avant d'être embauché dans la même entreprise que lui. J'étais particulièrement motivé par ce changement de paradigme et les nouveautés qui s'offraient à moi. Malheureusement, c'est là qu'à commencé ma descente aux enfers. Mon chef de projet n'était pas du tout satisfait de ma manière de développer, il jugeait que je ne m'adaptait pas assez bien et rapidement à ces nouvelles méthodes de travail. Il m'a reproché tout et son contraire, car je tenais bien évidemment compte de ses remarques et faisait tout pour rebondir. Rapidement, on a évoqué l'éventualité du licenciement. S'en sont suivis les symptômes habituels : angoisse, insomnie, irritabilité, troubles gastro-intestinaux, fatigue, perte de l'estime de soi, de l'attention et de la concentration. Cela n'a fait qu'empirer les choses. Mon chef de projet m'a sérieusement pris en grippe et mis en porte-à-faux vis-à-vis du président, au point de mettre en doute mes compétences et de m'humilier en sa présence, face à une tâche en cours de développement, afin de le convaincre de ma fragilité face à la pression. Ça s'est soldé par une rupture conventionnelle au bout de presque 7 mois.

J'ai quand même réussi à trouver un autre poste, bien que s'est été compliqué. Cette fois, je me suis complètement effacé, de peur de laisser paraître quoi que ce soit qui puisse m'être préjudiciable. Je n'arrivais pas à faire confiance à mon nouveau chef de projet, qui paraissait toujours cacher le fond de ses pensées. Rapidement, j'ai perdu toute motivation et je priais pour que ma période d'essai se termine. Malheureusement, mes résultats n'ont sans surprise pas été au rendez-vous. Ma période d'essai a été prolongée, puis on y a mis fin.

Actuellement, je suis au chômage depuis plus de 3 mois. J'ai mis le plus possible mon CV en avant afin d'attirer toute opportunité qui se présenterait, ce qui m'a valu la prospection de nombreuses sociétés de conseil. Là encore, impossible de convaincre. J'ai par ailleurs subi humiliations et accusations diffamatoires.

Au sujet des sacrifices, je peux dire que ce fut le cas pour moi depuis toujours, si l'on considère mon affinité infiniment plus grande pour le végétal que pour l'informatique et mon aversion pour un mode de vie urbain qui m'était jusque là inconnu. Quand travail et passion sont complètement inconciliables, je ne vois pas comment appeler ça autrement. Il y a une différence entre choisir une carrière selon ses facilités et ses résultats scolaires, et ce que l'on fait par passion. Malheureusement, vous n'avez qu'une vague idée du métier qui vous attend tant que vous ne l'avez pas vécu, et l'on a vite fait de vous orienter vers un secteur qui recrute parce que vous en avez le potentiel et qu'il faut "réussir sa vie".