Discussion :

[Patrick Ruiz]

Développeurs : quels facteurs concourent à rendre vos journées pleines de productivité ? Quels sont ceux susceptibles de les ruiner ?
Des travailleurs de la filière font des retours d’expérience

Quels sont les facteurs qui concourent à rendre votre journée de travail productive ? Quels sont ceux susceptibles de vous la ruiner ? L’étude Good Day Project menée sur GitHub sur un échantillon de 40 développeurs apporte des éléments de réponse : les réunions et les interruptions font partie des facteurs susceptibles de ruiner des journées de travail. Les moments de réflexion en solo par contre entrent dans la liste des ingrédients qui participent à l’obtention de plus de productivité et de satisfaction personnelle de la part des développeurs.

Pendant deux semaines, les participants ont été invités à qualifier leur journée de géniale, bonne, correcte, mauvaise ou terrible, puis à la décrire plus en détail à l'aide de questions basées sur le framework de productivité SPACE de GitHub. Les données d'enquête de chaque développeur ont ensuite été mises en correspondance avec leurs données d'activité sur GitHub pour une journée donnée. Il en est ressorti que les meilleures journées des développeurs étaient celles avec le moins de réunions et d'interruptions, tandis que celles où il y avait le plus de réunions et d'interruptions étaient les plus susceptibles d'être ruinées.

En fait, il s'est avéré que les réunions et les interruptions avaient un impact plus important que prévu sur la façon dont les développeurs évaluaient leur journée. Les jours où il y avait peu ou pas d'interruptions, les chances des développeurs de passer une bonne journée étaient de 82 %. Lorsque les développeurs déclarent être interrompus pendant la majeure partie de la journée, ce pourcentage tombe à 7 %.

L'étude a également établi que plus de deux réunions par jour suffisaient à faire dévier les développeurs de leurs objectifs. Lorsque les développeurs avaient en moyenne deux réunions par jour, ils avaient 74 % de chances de déclarer avoir progressé vers leurs objectifs. Mais au-delà de trois réunions par jour, ce pourcentage tombe à 14 %.

La publication souligne que toutes les réunions ne peuvent pas être évitées, mais qu'en les limitant au maximum, les développeurs avaient les meilleures chances de se concentrer et d'atteindre le "flow", c'est-à-dire des périodes de travail productif et ininterrompu. Les développeurs avaient 99 % de chances de faire un travail de qualité lorsque les réunions étaient limitées à une seule par jour, par exemple.

Elle note en sus que les interruptions offraient parfois un répit dans le travail, mais qu'en trop grand nombre, elles fragmentaient les journées des développeurs et les rendaient moins efficaces. « Les changements de contexte sont coûteux sur le plan cognitif et il faut du temps pour s'en remettre », indique l'étude.

Par exemple, les développeurs qui ont le plus procédé à des soumissions de code et créé plus de pull requests ont plus de chances d'avoir l'impression d'avoir passé une bonne journée. Toutefois, ceux qui ont créé le plus de pull requests n'ont pas déclaré avoir passé les meilleures journées. Les chercheurs expliquent ce phénomène par le fait que la création de pull requests distrait les développeurs et introduit des interruptions dans leurs journées.

« En minimisant les distractions et en créant des temps de concentration, nous ne faisons pas que travailler, nous nous créons des journées meilleures et moins stressantes », indique l'étude. La publication a de plus révélé que les périodes de réflexion étaient également efficaces pour stimuler le sentiment de satisfaction des développeurs, réduire le stress et stimuler la productivité. De nombreux développeurs ont choisi de poursuivre avec cette pratique suite à l’enquête de deux semaines.

« Les commentaires des développeurs ont montré que le simple fait de prendre quelques minutes à la fin de chaque journée de travail pour réfléchir faisait une grande différence dans leur ressenti », indique le rapport qui ajoute que « noter les activités clés et leur ressenti sur la journée a aidé les développeurs à clôturer leur journée et à en tirer des enseignements. En d'autres termes, ce petit moment a un impact important pour ceux d'entre nous qui souhaitent faire une pause et réfléchir à leurs journées et à leur travail. Et cela peut être fait par tout le monde et ne nécessite pas de technologie ou d'outils sophistiqués. Un simple carnet ou un fichier markdown peut fonctionner. »

Source : Good Day Project

Et vous ?

Que pensez-vous des chiffres mis en avant par cette étude ? Collent-ils avec la réalité dont vous êtes au fait ?
Quels sont les facteurs qui concourent à rendre vos journées de travail pleines de productivité ? Quels sont ceux susceptibles de vous la ruiner ?

Voir aussi :

« 52 minutes de travail, 17 minutes de pause », la formule idéale pour un bon rendement, selon une étude

Une entreprise passe à la semaine de quatre jours après un test concluant sur l'amélioration de la productivité et la réduction du niveau de stress

Les travailleurs seraient beaucoup plus productifs en travaillant 4 jours au lieu de 5 par semaine selon une étude, qu'en est-il des informaticiens ?

Des experts font la promotion de la semaine de travail de quatre jours au lieu de cinq, pour eux, cela rendrait les travailleurs plus productifs

[smarties]

Je suis tout à fait d'accord que les interruptions nuisent à notre productivité.
Pour les réunions, je suis plutôt d'accord (et ne devraient pas excéder 30-60 minutes) et pour moi il est idéal de les placer à des moments précis (si tout le monde embauche à la même, mettre la réunion en tout début de matinée, ou la mettre en fin de matinée ou la mettre juste après manger)

Ne pas avoir suffisamment le choix de son matériel est un peu limitant (double écran, 21/9 ou 32/9, RAM, CPU, ...)

Être seul dans mon bureau (car j'ai souvent un fond musical) sinon 2 personnes maximum. Ne pas mettre des développeurs avec des commerciaux, chefs de projets (enfin des gens qui ont souvent besoin de communiquer)

[Invité]

Quels sont ceux susceptibles de vous la ruiner ?

Les tâches inutiles en général, par exemple :
* Répondre à des emails où on vient vous reprocher quelque-chose perdre des heures à exposer la situation et à contre-argumenter ;

* Encore pire que les emails : les outils "collaboratifs" type Teams ou Slack qui ne sont rien d'autre que le Twitter des managers, avec le même niveau d'intelligence. Pour une raison inconnue, Teams ne fonctionne pas sur mon poste et c'est très bien comme ça ;

* Préparer des tableaux Excel récapitulatifs parce que le management est paresseux et ne prend pas la peine de s'intéresser au travail des collaborateurs ;

* La réunionite. Heureusement avec le télétravail, on n'est pas obligé d'être attentif. C'est un très gros gain de productivité ;

* Le VPN, parce qu'une bande passante de 30MBps est insuffisante pour y connecter 400 personnes et que l'entreprise ne veut pas payer plus.

[smarties]

* Répondre à des emails où on vient vous reprocher quelque-chose perdre des heures à exposer la situation et à contre-argumenter ;

* Encore pire que les emails : les outils "collaboratifs" type Teams ou Slack qui ne sont rien d'autre que le Twitter des managers, avec le même niveau d'intelligence. Pour une raison inconnue, Teams ne fonctionne pas sur mon poste et c'est très bien comme ça ;

* Préparer des tableaux Excel récapitulatifs parce que le management est paresseux et ne prend pas la peine de s'intéresser au travail des collaborateurs ;

Je n'avais pas penser au mail mais j'ai pris l'habitude d'ouvrir ma boite mail entre 2 tâches

Pour les tableaux Excel je suis d'accord, il y a des outils comme Redmine où l'on peut mettre à jour l'avancement. Le manager à juste à savoir utiliser Redmine donc.

[Pyramidev]

mettre la réunion en tout début de matinée, ou la mettre en fin de matinée ou la mettre juste après manger

+1 sur le fait de placer les réunions à des moments stratégiques pour éviter d'interrompre des développements. À ce sujet, en 2009, Paul Graham avait publié un bon article : Maker's Schedule, Manager's Schedule.
Cela dit, si la réunion est en tout début de matinée, cela peut être gênant si un ou plusieurs participants risquent de ne pas être à l'heure, par exemple des employés qui ne sont pas en télétravail, qui viennent en voiture et qui subissent les aléas du réseau routier.

[Bousk]

Clairement : les meetings. Et les pires d'entre eux : les dailys meetings.
- ça coupe le travail, et pour se remettre à la tâche ça prend du temps pour retrouver où on en était réellement et que tout se remette en ordre dans mon esprit
- les dailys sont en plus totalement inutiles : oui je travaille tous les jours, si tu veux un détail précis tu as déjà un historique sur perforce, jira et autres
- certaines tâches prennent plusieurs jours, c'est utile à personne d'entendre tous les jours "je travaille sur X" quand X ne bouge pas

[dfiad77pro]

pour les daily mettings, faut pas que ça dépasse 15 mins et faut que ça soit le matin à heure fixe sinon c'est vraiment chiant.

de mon coté le matériel fourni par l'entreprise me casse les yeux, core i3 16go de ram (durement négocié) , sdd, mais avec un antivirus qui bouffe 90% du cpu lors des builds...
bref je préférerai payer un pc de ma poche et prêté à l'entreprise

sans compter la désactivation des gestionnaires de mots de passe ( en gros tu passe ta journée à retaper les pass de GIT, SVN, JIRA, etc)

[redbullch]

sans compter la désactivation des gestionnaires de mots de passe ( en gros tu passe ta journée à retaper les pass de GIT, SVN, JIRA, etc)

Quelle bonne idée, comme ça les gens créent un passwords.txt et font des copier coller

[Aurelien.Regat-Barrel]

Clairement : les meetings. Et les pires d'entre eux : les dailys meetings.
- les dailys sont en plus totalement inutiles : oui je travaille tous les jours, si tu veux un détail précis tu as déjà un historique sur perforce, jira et autres

Les dailys ne sont pas fait pour parler de ça. Malheureusement en pratique c'est souvent le cas : c'est un tour de table annuyeux où tout le monde raconte sa journée de la veille, tout en tapotant au clavier pendant que les autres parlent.

Renseigne toi sur à quoi est censé servir un daily et comment le rendre efficace : ça changera ta perception et je l'espère tu verras qu'un daily efficace fait gagner du temps à tout le monde car c'est un moment précieux de synchronisation et d'alignement sur les priorités. C'est d'autant plus nécessaire quand chacun peut travailler seul dans sa bulle le restant de la journée.

Une astuce efficace est de faire une review des tâches en cours / à faire et non pas un tour de table des personnes présentes. Plus on avance dans le sprint, plus le daily se racourci. Et si le blocage d'une tâche revient trop de fois de suite, un warning se lève rapidement pour éviter l'enlisement / la perte de travail.

[Invité]

Les dailys ne sont pas fait pour parler de ça. Malheureusement en pratique c'est souvent le cas : c'est un tour de table annuyeux où tout le monde raconte sa journée de la veille, tout en tapotant au clavier pendant que les autres parlent.

Renseigne toi sur à quoi est censé servir un daily et comment le rendre efficace : ça changera ta perception et je l'espère tu verras qu'un daily efficace fait gagner du temps à tout le monde car c'est un moment précieux de synchronisation et d'alignement sur les priorités. C'est d'autant plus nécessaire quand chacun peut travailler seul dans sa bulle le restant de la journée.

Une astuce efficace est de faire une review des tâches en cours / à faire et non pas un tour de table des personnes présentes. Plus on avance dans le sprint, plus le daily se racourci. Et si le blocage d'une tâche revient trop de fois de suite, un warning se lève rapidement pour éviter l'enlisement / la perte de travail.

Dixit un ancien manager, les réunions journalières servent surtout à faire en sorte que les employés arrivent à l'heure le matin.

[el_slapper]

Dixit un ancien manager, les réunions journalières servent surtout à faire en sorte que les employés arrivent à l'heure le matin.

C'est donc un mauvais manager.

Tu mets la meilleure méthode de l'univers dans les mains de managers ineptes avec une équipe de gnous à la programmation, de testeurs qui aiment l'approximation, d'experts métiers qui ne connaissent pas le métier, et d'ingénieur système qui ne savent même pas faire des sauvegardes, et tu obtiens le même résultat qu'avec toute autre méthode. Tant qu'on devra passer la méthode avant les gens, on aura beaucoup d'horreurs (et parfois des projets qui se passent très bien, parce qu'on est tombé par hasard sur des bons).

Et je ne crois pas que Scrum soit la meilleur méthode de l'univers - mais c'est pas le principal problème. Le principal problème, c'est à qui on confie Scrum.

[lvr]

Préparer des tableaux Excel récapitulatifs parce que le management est paresseux et ne prend pas la peine de s'intéresser au travail des collaborateurs ;

* La réunionite. Heureusement avec le télétravail, on n'est pas obligé d'être attentif. C'est un très gros gain de productivité ;

C'est très instructif comme discussion !! Perso, je suis plutôt du côté Manager que Maker. Et oui, je demande de remplir à mes équipes de remplir des Excel. C'est jamais par paresse. Oui je demande aux mes équipes de remplir (régulièrement) leurs Actuals et Time-To-Complete, et c'est pas pour les faire chier, c'est pour pouvoir faire des projections, détecter des problèmes de dépendances. Oui, je mets souvent des réunions, car j'ai besoin de l'expertise du Maker, et non elles peuvent être toujours à la même heure, car je n'ai jamais un même slot de libre chaque jour, ...

Cette discussion met en évidence que dans le monde de l'IT, comme dans tous les pans de la société, les différentes composantes de la société ne se connaissent pas. Et de cette méconnaissance naissent les difficultés (j'ignorais que que pour les "Makers" l'unité est plutôt à la demi-journée. La mienne est clairement à l'heure), les préjugés, ...

Souvent, je me demande comment tirer le meilleur parti de mes équipes (à ne pas lire de manière péjorative). Comment leur permettre d'être efficace tout en me permettant, moi, d'être efficace dans mon rôle.

Je vais continuer à lire ce forum avec bcp d'intérêt.

[tanaka59]

Bonsoir,

Développeurs : quels facteurs concourent à rendre vos journées pleines de productivité ?

> quand on peut se concentrer
> quand les demandes sont claires
> quand on a pas de surcouches de managers qui se tirent dans les pattes (l'un veut un truc et vous le fait faire, quand un autre décide de vous mettre des bâtons dans roues ... ), genre le coup des données exigées par l'un qu'un autre va couper les vannes d'alim ... Cherchez l'erreur . D'autres vont vous faire les yeux doux et si vous communiquez la data , un autre fera un caca nerveux car cela va pas dans "son sens" ...
> des outils de suivis des problématiques claires (une demande = un numéro de ticket , noter clairement et centraliser les besoins dans un tableur de suivi ou une app dédiée )

Quels sont ceux susceptibles de les ruiner ?

> les décisions contradictoires
> les managers qui se tirent dans les pattes
> le détricotage quand un manager n'est pas content
> les open spaces bruyant
> quand des services marketing ou gestion ne savent pas définir un process informatique d'un process métier
> les réunionites aiguës
> trop de mails
> trop d'appels téléphoniques
> trop de mp sur les outils genre skype et autre ...

[Guilp]

mais avec un antivirus qui bouffe 90% du cpu lors des builds...
etc)

Enlève l'option "scanner les fichiers ouverts par les programmes" dans les paramètres de l'AV. Ça a changé ma vie, et celle de mes collègues qui avaient tous le même soucis particulièrement au niveau des builds.

[dfiad77pro]

mais l'entreprise bloque biensur cette possibilité
je ne suis pas contre le scan de l'antivirus, mais pas quand il se fait en permanence, ou alors si l'entreprise veut vraiment ça qu'elle mette à dispo des pc puissants, c'est pas si cher que ça...

[GreatDeveloperOnizuka]

Quels sont les facteurs qui concourent à rendre vos journées de travail pleines de productivité ?

Si je bosse sur un truc simple (90% du temps) moins je vois de personne, mieux je suis niveau productivité . Le 10% est si je fais un truc un peu chaud, un pair programming avec un mec plutôt bon.

Quels sont ceux susceptibles de vous la ruiner ?

Les tickets sur des demandes à la con. Genre Frédéric qui demande si on peut faire un dev pour exporter son tableau à la con sur Excel avec les colonnes dans l'ordre qu'il veut. Donc t'es énervé et tu prends 5 min pour juste lui écrire comme quoi il peut changer l'ordre des colonnes directement dans Excel.

Dans les faits, tu perds + que 5 min de mail car t'es déconcentré et comme c'est la 10ème fois cette semaine que tu reçois des tickets de merde, t'as plus envie de bosser. Résultat, tu sors prendre l'air et un café soit 30 min de perdu .

[el_slapper]

> les open spaces bruyant

et ça se mesure : https://enigma.swiss/fr/blog/meilleu...-productivite/ - 15% de perte de productivité. D'autres sources parlent de 18%, voire 20% - je suis resté soft.

Mais le bruit n'est pas la seule raison : la perte d'intimité est aussi un facteur puissant (malgré le titre du lien) : https://www.usinenouvelle.com/articl...e-gall.N294525

[Mandotnet]

Point de vue subjectif. Un développeur ne travaille pas pour lui, tout comme un tech qui ne maitrise pas forcément les priorités du moment. Le rôle du manager est d'aligner les équipes sur les objectifs de l'entreprise. C'est comme ça.
J'ai connu des projets ou des devs ont bossé pendant 2 ans dessus et au final tout fini à la poubelle. La vie d'un projet ne se résume pas à la satisfaction personnelle. Bienvenue dans le monde réel.

[Jamatronic]

J'ai connu des projets ou des devs ont bossé pendant 2 ans dessus et au final tout fini à la poubelle.

Alors pourquoi ne leur a-t-on pas fait faire autre chose pendant ces 2 ans ? C'est pas de l'incompétence managériale, ça ? J'appelle cela bosser comme des grosses merdes.

[yildiz-online]

Alors pourquoi ne leur a-t-on pas fait faire autre chose pendant ces 2 ans ? C'est pas de l'incompétence managériale, ça ? J'appelle cela bosser comme des grosses merdes.

Peut-être parce que:

- le marché a changé, le produit n'est plus rentable: la faute au business.
- les choix technologiques/l'architecture ont conduit a un cul-de-sac: la faute au technique.
- le client a coulé: la faute à pas de chance.

Donc non, ce n'est pas forcément de l'incompétence managériale.