Les entreprises peuvent aider leurs développeurs à maximiser leur productivité de différentes manières, du changement d'espace de bureau à l'acquisition de meilleurs outils et au nettoyage du code source. Mais quelles décisions auront le plus d'impact? En nous appuyant sur la littérature sur le développement de logiciels et la psychologie industrielle / organisationnelle, nous avons identifié des facteurs liés à la productivité et interrogé 622 développeurs de trois entreprises. Nous nous sommes intéressés aux facteurs mentionnés et à la manière dont les gens eux-mêmes évaluent leur propre productivité. Nos résultats suggèrent que l'estime de soi est le plus influencée par des facteurs non techniques: l'enthousiasme au travail, le soutien de vos pairs pour de nouvelles idées et des commentaires utiles sur votre productivité. Par rapport à d'autres travailleurs du savoir,L'évaluation par les développeurs de logiciels de leur productivité dépend davantage de la variété des tâches et de la capacité à travailler à distance.

1. Introduction

L'amélioration de la productivité des développeurs est importante. Par définition, lorsqu'ils terminent leurs tâches, ils peuvent consacrer leur temps libre à d'autres tâches utiles: l'introduction de nouvelles fonctionnalités et de nouveaux contrôles. Mais qu'est-ce qui aide les développeurs à être plus productifs?



Les entreprises ont besoin de conseils pratiques sur les facteurs à manipuler pour maximiser la productivité. Par exemple, un développeur devrait-il passer du temps à rechercher de meilleurs outils et approches, ou devrait-il désactiver les notifications pendant la journée? Un leader doit-il investir dans le refactoring pour réduire la complexité du code ou donner plus d'autonomie aux développeurs? Les patrons doivent-ils investir dans de meilleurs outils de développement ou dans un bureau plus confortable? Dans un monde idéal, nous investirions dans divers facteurs pour augmenter la productivité, mais le temps et l'argent sont limités, nous devons donc choisir.



Cet article traite de l'étude la plus large sur les prévisions de productivité des développeurs de logiciels à ce jour. Comme décrit dans la section 3.1, la productivité peut être mesurée objectivement (par exemple, en lignes de code par mois) ou subjectivement (comme estimé par le développeur lui-même). Bien qu'aucune des deux approches ne soit préférée, nous avons essayé de couvrir le sujet au sens large avec un jugement subjectif afin de répondre à trois questions:

1. Quels facteurs sont les meilleurs prédicteurs de la manière dont un développeur évaluera sa productivité?
2. Comment ces facteurs évoluent-ils d'une entreprise à l'autre?
3. Qu'est-ce qui prédit l'évaluation par un développeur de sa productivité, en particulier, par rapport à d'autres travailleurs du savoir?

Pour répondre à la première question, nous avons mené une étude dans une grande entreprise de logiciels.



Pour répondre à la deuxième question, qui permet de comprendre dans quelle mesure les résultats obtenus peuvent être généralisés, nous avons mené une étude dans deux entreprises de secteurs différents.



Pour répondre à la troisième question, qui permet de comprendre en quoi les développeurs diffèrent des autres, nous avons mené une étude auprès de représentants d'autres professions et l'avons comparée aux résultats obtenus dans l'étude des développeurs.



Nos résultats montrent que dans les entreprises que nous avons étudiées, l'estime de soi pour leur productivité est fortement influencée par l'enthousiasme au travail, le soutien des pairs pour les nouvelles idées et les retours utiles sur leur productivité. Par rapport à d'autres travailleurs du savoir, l'évaluation par les développeurs de logiciels de leur productivité dépend davantage de la variété des tâches et de la capacité de travailler à distance. Les entreprises peuvent utiliser nos résultats pour hiérarchiser les initiatives liées à la productivité (section 4.7).



La section 2 décrit les entreprises que nous avons étudiées. La section 3 décrit la méthodologie de recherche. La section 4 décrit et analyse les résultats obtenus. La section 5 décrit d'autres travaux sur ce sujet.

2. Entreprises étudiées

2.1. Google

Google compte environ 40 bureaux de développement dans le monde, employant des dizaines de milliers de développeurs. L'entreprise valorise une collaboration étroite au sein des équipes et les bureaux sont généralement ouverts pour rapprocher les membres de l'équipe. L'entreprise est relativement jeune (fondée à la fin des années 1990), sa structure organisationnelle est plutôt plate et les développeurs ont une grande autonomie. Le processus de promotion comprend les commentaires des pairs, et les développeurs n'ont pas besoin de passer à des postes de direction pour avancer. Les développeurs planifient eux-mêmes leur temps, leurs calendriers sont affichés sur le réseau de l'entreprise. Google utilise des processus de développement agiles (comme Agile), généralement appliqués à toute l'équipe.



Google valorise l'ouverture. La plupart des développeurs travaillent sur une base de code monolithique commune, et ils sont encouragés à apporter des modifications au code des projets d'autres personnes. L'entreprise a une forte culture de test et de révision de code: le code soumis au référentiel est révisé par un autre développeur, généralement à l'aide de tests. La plupart écrivent du code côté serveur qui est publié fréquemment et facilite le déploiement des correctifs. La boîte à outils de développement est en grande partie unifiée (à l'exclusion des éditeurs) et construite en interne, y compris les outils d'analyse et d'intégration continue, ainsi que l'infrastructure de publication.

2.2. ABB

ABB compte plus de 100 000 employés dans le monde. En tant que conglomérat d'ingénierie, l'entreprise emploie une grande variété de professions. Il existe environ 4 000 développeurs de logiciels courants et plus de 10 000 développeurs d'applications qui construisent des systèmes industriels à l'aide de langages visuels et textuels spécifiques à l'industrie. Pour exploiter sa vaste infrastructure informatique, la société dispose d'un personnel important dont les responsabilités comprennent la rédaction de scripts et la programmation simplifiée.



Bien qu'ABB ait repris un certain nombre de petites entreprises, il dispose d'une organisation centrale chargée d'unifier les processus de développement logiciel. Ainsi, malgré les différences entre les départements, la plupart des outils et des approches sont cohérents. Il en va de même pour la plupart des cheminements de carrière: pour les techniciens du développeur junior au développeur senior, et pour les cadres, du chef de groupe au chef de service et à la direction centrale.

2.3. Instruments nationaux

National Instruments a été fondé dans les années 1970. Le développement logiciel est principalement concentré dans quatre centres internationaux de recherche et développement. Les calendriers des employés sont visibles par toute l'entreprise, n'importe qui peut prendre rendez-vous avec n'importe quel autre employé.



Les responsabilités professionnelles facilitent les processus de développement. Les développeurs ne peuvent pas choisir indépendamment un projet, mais ils peuvent assumer des tâches ou des fonctionnalités spécifiques. La plupart fonctionnent avec une base de code monolithique commune, ses différentes parties logiques ayant des propriétaires spécifiques. Le code saisi doit être approuvé par le «propriétaire». Il est souhaitable que le code soit analysé par des responsables techniques. Cette politique est facultative, mais beaucoup la suivent.



Les développeurs ont une grande liberté dans le choix des outils. Il n'y a pas d'outils génériques, à moins qu'il y ait un avantage immédiat. Par exemple, le choix de l'EDI dépend fortement de la tâche. Il existe un certain nombre d'outils de construction et de test personnalisés disponibles. Différentes parties de l'entreprise ont normalisé différents systèmes de gestion et d'analyse du code source. Les mises à jour logicielles sont généralement publiées trimestriellement ou annuellement, à l'exception de rares correctifs critiques.



Tableau 1. Profils des trois entreprises étudiées:

3. Méthodologie

Notre objectif: découvrir quels facteurs peuvent prédire la productivité des développeurs de logiciels. Pour ce faire, nous avons mené une étude contenant un ensemble de questions, un ensemble de facteurs de productivité et un ensemble de variables démographiques.

3.1 Évaluer votre productivité

Décrivons d'abord comment nous mesurerons la productivité. Ramírez et Nembhard ont proposé une classification des techniques de mesure de la productivité décrites dans la littérature, y compris l'analyse des points de fonction, l'auto-évaluation, l'évaluation par les pairs, la proportionnalité des résultats et des efforts et l'utilisation professionnelle du temps [2]. Ces techniques peuvent être divisées en objectifs (par exemple, combien de lignes de code sont écrites par semaine) et subjectives (par exemple, auto-évaluation ou évaluation par les pairs).



Aucune des deux techniques n'est préférée; les deux catégories présentent des inconvénients. Les mesures objectives manquent de souplesse et de caractère ludique. Prenons le nombre de lignes de code par semaine. Un développeur productif peut écrire un correctif en une ligne pour un bogue difficile à trouver. Et un développeur improductif peut facilement gonfler le nombre de lignes. D'un autre côté, les mesures subjectives peuvent être inexactes en raison de biais cognitifs. Prenez les évaluations par les pairs: ils peuvent ne pas aimer un développeur productif, et obtiendront donc de pires évaluations même si les pairs s'efforcent d'objectivité.



Comme l'équipe de chercheurs dirigée par Meyer qui a analysé la productivité des développeurs de logiciels [3], nous avons utilisé les questions de notre recherche comme mesure subjective de la productivité. Il y a deux principales raisons. Premièrement, comme l'ont noté Ramirez et Nembhardt, la recherche est «un moyen simple et populaire de mesurer la productivité des [travailleurs du savoir]». Deuxièmement, la recherche fournit des réponses de développeurs dans différents rôles et permet également aux répondants d'ajouter différentes informations à leurs évaluations de performances.



Figure: 1. Méthodologie de recherche:





Nous avons demandé aux répondants dans quelle mesure ils étaient d'accord avec l'énoncé:

J'atteins régulièrement une productivité élevée.

Avec lui, nous avons voulu mesurer la productivité le plus largement possible. Nous avons d'abord formulé huit options pour la question, puis nous les avons réduites aux précédentes en discutant de manière informelle avec cinq développeurs Google de leur interprétation de la phrase (Figure 1, en bas à gauche). Nous avons ajouté les mots «élevé» et «régulièrement» à la question pour trois raisons. Premièrement, nous voulions capturer un état avec lequel les gens peuvent se comparer. Deuxièmement, nous voulions que cet état soit élevé afin d'éviter les effets de l'atteinte du plafond des réponses des répondants. Troisièmement, nous voulions que les répondants se concentrent sur deux mesures spécifiques de la productivité: l'intensité et la fréquence. À l'avenir, les chercheurs pourront appliquer des mesures plus détaillées en divisant l'intensité et la fréquence sur deux questions distinctes.



Nous l'avons mis à l'épreuve en demandant à trois dirigeants de Google de l'envoyer à leurs équipes en leur demandant: "Qu'avez-vous pris en compte lorsque vous répondez à une déclaration de productivité?" Nous avons reçu des réponses de 23 développeurs (Figure 1, en bas au centre). L'option a été jugée acceptable pour nos besoins parce que les considérations des répondants correspondaient à nos attentes concernant la valeur de la productivité. Ces considérations couvraient les problèmes de flux de travail, les résultats du travail, le fait d'être dans la zone ou le flux, le bonheur, les objectifs atteints, l'efficacité de la programmation, les progrès et la minimisation des efforts inutiles. Nous n'avons pas analysé ces réponses dans cet article, mais l'étude comprenait quatre mesures supplémentaires et raffinées de la productivité tirées de travaux antérieurs [2], [4], [5].



Nous avons choisi deux mesures pratiques de productivité pour ajouter des données objectives afin de contextualiser l'estime de soi, puis les avons mises en corrélation l'une avec l'autre sur Google. La première mesure objective était le nombre de lignes de code modifiées par un développeur par semaine - une mesure populaire mais difficile de la productivité [6], [7]. La deuxième mesure était le nombre de modifications apportées par le développeur à la base de code Google principale par unité de temps. C'est presque équivalent à la pull request mensuelle utilisée par l'équipe dirigée par Vasilescu [8]. Pour évaluer notre productivité, nous avons utilisé les réponses à une enquête similaire sur Google (n = 3344 réponses). Nous n'avons pas pu utiliser les données de notre étude pour cette analyse car les réponses ne contenaient pas d'identifiant de participant.par lesquelles des mesures objectives de la productivité pourraient être comparées. Dans cette étude, ils ont posé une question similaire: "À quelle fréquence vous sentez-vous très productif au travail?" Les participants pouvaient répondre «Rarement ou jamais», «Parfois», «Environ la moitié du temps», «La plupart du temps» et «Toujours ou presque toujours». Nous avons ensuite créé une régression linéaire avec la performance autodéclarée comme variable dépendante ordinale (codées 1, 2, 3, 4 et 5, respectivement). La régression linéaire suppose une distance égale entre les cotes de productivité. Compte tenu des termes utilisés dans la question, nous considérons cette hypothèse comme justifiée. Pour la régression logistique ordonnée, cette hypothèse n'est pas requise. L'application de cette technique donne ici des résultats fiables: les mêmes coefficients sont significatifs dans un linéaire,et dans un modèle ordonné.



Nous utilisons des mesures objectives logarithmiques comme variables explicatives, car elles sont toutes deux biaisées positivement. Pour le contrôle, nous avons pris le code du poste (par exemple, ingénieur logiciel, ingénieur de recherche, etc.) comme variable catégorielle, ainsi que le rang (junior, moyen, senior, etc.) comme un nombre (par exemple, 3 pour les logiciels ingénieur débutant chez Google). Le code de poste était statistiquement significatif pour deux rôles de travailleur dans chaque modèle linéaire. Il y avait trois modèles au total: deux avec l'une des mesures objectives et un avec les deux mesures objectives.





Figure: 2: Modèles prédisant des estimations de performance subjectives basées sur deux mesures objectives. ns signifie un facteur statistiquement non significatif avec p> 0,05, ** signifie p <0,01, *** signifie p <0,001. Une description complète des modèles est donnée dans les Documents supplémentaires.



Les résultats de la contextualisation sont présentés dans la Fig. 2. Chaque modèle démontre un niveau statistiquement significatif avec une note négative, ce que nous avons interprété comme: les développeurs mieux classés ont tendance à se considérer comme légèrement moins productifs. C'est un argument fort pour le contrôle de rang (section 3.7.). Les deux premiers modèles démontrent une relation positive importante entre les mesures objectives et subjectives de la productivité. Autrement dit, plus il y a de lignes de code écrites ou de modifications, plus un développeur se considère productif. Le modèle combiné et les estimations qui en résultent pour les deux premiers modèles suggèrent que le nombre de changements apportés est un indicateur de productivité plus important que le nombre de lignes écrites. Mais notez que dans tous les modèles le paramètre R ², représentant la proportion de variance expliquée, est plutôt faible - moins de 3% pour chaque modèle.



En général, les résultats obtenus indiquent que le nombre de lignes de code et les modifications apportées affectent l'évaluation par les développeurs de leur productivité, mais pas de manière significative.

3.2. Facteurs de productivité

Ensuite, au cours de l'étude, nous avons interrogé les participants sur les facteurs considérés comme liés à la productivité dans d'autres études. Nous avons recueilli des questions de quatre sources (Figure 1, milieu gauche). Ces sources sont prises parce qu'à notre connaissance, elles représentent les aperçus les plus complets des facteurs de productivité individuels dans la recherche des programmeurs et autres travailleurs du savoir.



Première sourceEst un outil créé par une équipe dirigée par Palvalin pour revoir les mesures de productivité des travailleurs du savoir [4]. L'outil, appelé SmartWoW, a été utilisé par quatre entreprises et couvre les aspects de l'espace de travail physique, virtuel et social, les pratiques de travail personnelles et le bien-être au travail. Nous avons modifié certaines des questions pour mieux refléter la terminologie actuelle des développeurs et mieux correspondre à l'anglais américain. Par exemple, SmartWoW demande:

Je télétravaille souvent pour effectuer des tâches qui nécessitent une concentration ininterrompue.

Nous avons paraphrasé:

Je travaille souvent à distance pour effectuer des tâches qui nécessitent une concentration ininterrompue.

À partir de SmartWoW, nous avons d'abord sélectionné 38 questions pour notre étude.



Une deuxième source est un examen par Hernaus et Mikulić de l'impact des caractéristiques de l'environnement de travail sur la productivité des travailleurs du savoir [9]. Leur travail éprouvé reflète des études de productivité antérieures: un questionnaire de conception de l'environnement de travail [10], une étude diagnostique de l'environnement de travail [11], une évaluation de la collaboration de groupe [12] une évaluation de la «nature des tâches» [13]. Nous avons modifié les questions pour qu'elles soient courtes et cohérentes. Dans le même but, nous avons pris des questions directement du travail [12], qui est consacré à des groupes de travail avec peu de considérations sur la productivité personnelle.



Troisième source- une revue structurée de Wagner et Ruhe des facteurs de productivité dans le développement de logiciels [14]. Contrairement à d'autres sources, ce travail n'a pas été examiné en profondeur par la communauté scientifique et ne contient pas de recherche empirique originale. Mais à notre connaissance, il s'agit de l'enquête la plus complète sur la recherche sur la productivité de la programmation. Les facteurs formulés par Wagner et Rouet sont divisés en facteurs techniques et non quantifiables, puis les facteurs d'environnement, de culture d'entreprise, de projet, d'environnement de produit et de développement, de capacités et d'expérience sont également mis en évidence.



La quatrième sourceEst une étude de développeur Microsoft menée par une équipe dirigée par Meyer. De là, nous avons glané cinq raisons principales des journées de travail productives, y compris l'établissement d'objectifs, les réunions de travail et les pauses de travail [15].



Nous avons également ajouté trois facteurs qui, à notre avis, n'ont pas été correctement pris en compte dans les travaux précédents, mais qui se sont révélés importants dans le contexte de Google. L'un est l'évaluation de la productivité des travailleurs du savoir [16], un précurseur non publié de SmartWoW. Nous l'avons adapté comme ceci:

Les informations qui me sont fournies (rapports de bogues, scripts utilisateurs, etc.) sont exactes.

Le deuxième facteur est tiré du questionnaire de conception de l'environnement de travail et adapté comme suit:

Je reçois des commentaires utiles sur ma productivité au travail.

Et nous avons créé un troisième facteur qui était important dans l'environnement ABB:

J'ai besoin d'un accès direct à certains matériels pour tester mon logiciel.

Tout d'abord, nous avons choisi 127 facteurs. Pour les réduire à un tel nombre de questions auxquelles les répondants peuvent répondre sans fatigue significative [17], nous avons utilisé les critères indiqués au centre de la Fig. 1:

1. Suppression des doublons. Par exemple, dans SmartWoW [4] et Meyer et al. [15], l'établissement d'objectifs est considéré comme un facteur important de productivité.
2. Des facteurs similaires combinés. Par exemple, Hernaus et Mikulich décrivent différents aspects de l'interaction entre les groupes de travail qui augmentent la productivité, mais nous les avons réduits à un seul facteur [9].
3. La préférence a été donnée aux facteurs d'une utilité évidente. Par exemple, SmartWoW [4] a le facteur suivant:

Les employés ont la possibilité de voir les calendriers de chacun.

Chez Google, cela est vrai partout et il est peu probable que cela change, donc le facteur a une faible utilité.



Nous avons appliqué ces critères ensemble et de manière itérative. Tout d'abord, une grande affiche de toutes les questions des candidats à utiliser dans l'étude a été imprimée. Ensuite, nous avons installé une affiche Google à côté de notre bureau. Ensuite, chacun de nous a analysé indépendamment les questions en fonction des critères ci-dessus. L'affiche a été suspendue pendant plusieurs semaines, nous avons périodiquement complété et révisé à nouveau la liste. Enfin, une liste finale de questions a été établie.



Notre étude a inclus 48 facteurs sous forme d'énoncés (Fig. 4, colonne de gauche). Les répondants ont indiqué leur degré d'accord avec ces énoncés sur une échelle de cinq points, de «pas du tout d'accord» à «tout à fait d'accord». Les facteurs peuvent être regroupés en blocs liés à la méthodologie, à l'orientation, à l'expérience, au travail, à l'opportunité, aux personnes, au projet, au logiciel et au contexte. Nous avons également posé une question ouverte sur les facteurs que les répondants estimaient que nous aurions pu manquer. Le questionnaire complet de notre étude est fourni dans la documentation supplémentaire.





Figure: 3: Exemple de question issue de la recherche.

3.3. Démographie

Nous avons posé des questions sur plusieurs facteurs démographiques, comme le montre la figure 1:

• Sol.
• Position.
• Rang.

Les auteurs précédents ont suggéré que le sexe est lié aux facteurs de productivité des développeurs de logiciels, tels que le succès du débogage [18]. Par conséquent, l'étude comportait une question facultative sur le sexe (homme, femme, refus de répondre, la mienne). Les répondants qui n'ont pas répondu à la question ont été affectés au groupe «refuser de répondre» (Google n = 26 [6%], ABB n = 4 [3%], National Instruments n = 5 [6%]). Nous avons traité ces données comme catégoriques.



En ce qui concerne le poste, nous avons pris notre ancienneté chez Google du département des ressources humaines. Ce n'était pas possible avec ABB et National Instruments, nous avons donc ajouté une question facultative à l'étude. Chez ABB, en l'absence de réponses (n = 4 [3%]), nous avons pris 12 ans d'expérience, c'est la moyenne des données collectées. Chez National Instruments, nous avons mis 9 ans pour la même raison (n = 1 [1%]). Cela peut être rendu plus difficile [19], par exemple, en utilisant des substitutions pour prédire les valeurs manquantes sur la base des données disponibles. Disons que les informations de classement manquantes peuvent être remplies assez précisément en fonction de la position et du sexe. Cependant, nous n'avons substitué que des valeurs statistiques moyennes, puisque les facteurs démographiques n'étaient pas d'une importance primordiale pour nous, ils n'étaient que des informations d'accompagnement pour le contrôle. Nous avons traité ces données sous forme de nombres.



En termes de classement, sur Google, nous avons demandé aux participants d'indiquer leur niveau sous forme de nombre. Les réponses manquantes (n = 26 [6%]) étaient la valeur la plus courante.



Chez ABB, les contributeurs pouvaient éventuellement indiquer «développeur logiciel junior ou senior», bien que beaucoup aient indiqué un titre «différent». Si la réponse comprenait les mots:

• plus âgée
• de premier plan
• directeur
• architecte
• chercheur
• principale
• scientifique

puis nous avons renvoyé de telles réponses à des réponses «seniors». Le reste était appelé «junior». Les réponses manquantes (n = 4 [3%]) que nous avons attribuées à la signification la plus courante - «senior».



National Instruments avait des options:

• challenger
• Personnel
• plus âgée
• architecte / ingénieur principal
• architecte / ingénieur en chef
• ingénieur honoré
• participant
• autre

Le seul «autre» s'est avéré être un stagiaire, que nous avons transféré aux «candidats». Les réponses manquantes (n = 3 [4%]) que nous avons attribuées à la signification la plus courante - «senior».



Nous avons codé les rangs de toutes les entreprises par des numéros.

3.4. Comparaison avec des non-développeurs

Ensuite, nous nous sommes intéressés à ce qui nous permet exactement de prédire comment les développeurs évaluent leur productivité. Par exemple, nous avons supposé que la productivité était influencée par l'absence de travail, mais cela pourrait être dit pour n'importe quel travailleur du savoir. Par conséquent, une question naturelle se pose: cela affecte-t-il d'une manière particulière la productivité des développeurs?



Pour répondre à cette question, nous avons choisi des métiers comparables aux développeurs de logiciels. Tout d'abord, nous avons essayé de sélectionner en fonction des positions dans Google. Bien que certains postes aient indiqué qu'ils étaient des travailleurs du savoir, l'indicateur le plus courant et, à notre avis, le plus fiable d'un non-développeur approprié était la présence du mot «analyste» dans le poste. Nous avons décidé de comparer les analystes et les développeurs de Google, plutôt que de comparer les analystes de Google avec les développeurs des trois sociétés. Nous avons décidé que cela nous permettrait de contrôler les caractéristiques de l'entreprise (par exemple, si soudainement les employés de Google sont statistiquement plus ou moins sensibles aux interruptions que les employés d'autres entreprises).



Nous avons ensuite adapté nos recherches pour les analystes. Suppression des questions clairement liées au développement de logiciels, telles que «Mes exigences logicielles changent fréquemment». Nous avons refait d'autres questions spécifiquement pour les analystes. Par exemple, au lieu de «J'utilise les meilleurs outils et techniques pour développer des logiciels», nous avons écrit «J'utilise les meilleurs outils et approches pour faire mon travail».



Les scores de productivité ont été mesurés de la même manière que les développeurs. Il en va de même pour l'évaluation du sexe, de la position et du rang. Nous avons testé la version «analytique» de l'étude sur un échantillon pratique de cinq analystes qui ont déclaré que l'étude était généralement claire et ont apporté quelques modifications mineures. Nous les avons acceptés et avons mené une étude à part entière des non-développeurs.

3.5. contrôle qestion

Pour exclure les réponses données sans réfléchir, après environ 70% du début de l'étude, nous avons inséré une question d'attention [20]: "Répondez à ceci" Je suis plutôt en désaccord. " Nous n'avons pas pris en compte les formulaires qui ne contenaient pas une telle réponse à cette question.

3.6. Part des réponses

Chez Google, nous avons sélectionné au hasard 1 000 employés à plein temps des ressources humaines qui occupaient des postes de développement de logiciels. Nous avons reçu 436 formulaires remplis de leur part, c'est-à-dire que le taux de réponse était de 44%, ce qui est un indicateur de recherche très élevé parmi les développeurs [21]. Après avoir supprimé les formulaires avec la mauvaise réponse à la question de sécurité (n = 29 [7%]), il restait 407 réponses.



Pour une enquête auprès des travailleurs du savoir, nous avons sélectionné 200 employés de Google à plein temps au hasard avec le mot «analyste» dans leurs intitulés de poste. Nous avons décidé de ne pas rechercher trop d'analystes car notre cible était les développeurs de logiciels. 94 personnes, 47%, ont répondu à nos questions. Après avoir supprimé les questionnaires avec une réponse erronée à la question de sécurité (n = 6 [6%]), 88 sont restés.



Nous avons envoyé nos questionnaires à environ 2 200 développeurs de logiciels sélectionnés au hasard chez ABB et avons reçu 176 réponses. C'est 8%, à la limite inférieure pour de telles études [21]. Après avoir supprimé les mauvais questionnaires (n = 39 [22%]), il en restait 137.



Enfin, nous avons envoyé les questionnaires à environ 350 développeurs de logiciels chez National Instruments et avons reçu 91 réponses (26%). Après avoir supprimé les mauvais questionnaires (n = 13 [14%]), 78 sont restés.

3.7. Une analyse

Pour chaque facteur de chaque entreprise, nous avons appliqué des modèles de régression linéaire individuels, en utilisant le facteur comme variable indépendante (par exemple, «Le délai de mon projet est serré») et l'estimation de notre productivité comme variable dépendante. Nous avons exécuté des modèles distincts pour chaque entreprise dans un souci de confidentialité, afin que les données brutes de différentes entreprises ne se mélangent pas. Pour réduire l'effet des variables collatérales, nous avons ajouté des variables démographiques existantes à chaque modèle de régression. Dans l'interprétation des résultats, nous nous sommes concentrés sur trois aspects du ratio des facteurs de productivité:

• Évaluation . Indique le degré d'influence de chaque facteur tout en maintenant une constante démographique. Plus la valeur est élevée, plus l'impact est élevé.
• . . , .
• . p < 0,05. 48 , p -, [22].

Lors de l'interprétation des résultats, nous nous sommes davantage concentrés sur le degré d'influence (évaluation) et moins sur la signification statistique, car elle peut être extraite d'ensembles de données suffisamment grands, même si la signification pratique est faible. Comme nous le verrons ci-dessous, les résultats statistiquement significatifs ont été le plus souvent trouvés sur Google, avec le taux de réponse le plus élevé; le moins important - dans National Instruments, où le taux de réponse était plus faible. Nous avons estimé que cette différence était due en grande partie à la puissance statistique. Nous vous exhortons à être plus confiants dans les résultats statistiquement significatifs.



Pour fournir un contexte, nous avons également analysé la corrélation entre les facteurs démographiques et les cotes de performance. Pour ce faire, nous avons effectué une régression linéaire multiple pour chaque entreprise avec des variables démographiques comme variables indépendantes et une estimation de notre productivité comme variable dépendante. Nous avons ensuite analysé la valeur prédictive globale du modèle résultant, ainsi que l'impact de chaque variable explicative.

3.8. À propos de la causalité

Notre méthodologie nous permet d'évaluer la relation entre les facteurs de productivité et l'évaluation de leur propre productivité, bien que nous nous intéressions essentiellement au degré d'influence de chaque facteur sur l'évolution de la productivité. Dans quelle mesure est-il exact de croire qu'il existe une relation causale entre les facteurs et la productivité?



L'exactitude dépend principalement de la force des preuves de causalité dans les travaux antérieurs. Et ce pouvoir est différent pour différents facteurs. Par exemple, une équipe dirigée par Guzzo a mené une méta-analyse de 26 articles sur l'évaluation et la rétroaction, et les résultats fournissent d'excellentes preuves que la rétroaction augmente la productivité sur le lieu de travail [23]. Cependant, déterminer la force des preuves pour chaque facteur étudié nécessite beaucoup de travail, ce qui dépasse le cadre de cet article.



Pour résumer: bien que notre étude ne permette pas d'établir une relation causale, mais basée sur des travaux antérieurs, nous pouvons croire en toute confiance que ces facteurs affectent la productivité, mais interpréter nos résultats avec une certaine prudence.

4. Résultats

Pour commencer, nous décrivons la relation entre tous les facteurs de productivité et l'évaluation de leur productivité lors du contrôle des caractéristiques démographiques. Ces données seront utilisées pour répondre à chaque réponse à l'enquête, suivies d'une discussion des résultats. Ensuite, nous discuterons de la relation entre les caractéristiques démographiques et la mesure du rendement. Enfin, discutons des implications et des risques.

4.1. Facteurs de productivité

En figue. 4 montre les résultats de notre analyse décrite dans la section 3.7. La première colonne énumère les facteurs qui ont été proposés aux participants sous forme de déclarations; suivi des étiquettes de facteurs (F1, F2, etc.) que nous avons attribuées une fois l'analyse terminée. Le manque de données signifie que ces facteurs sont spécifiques aux développeurs et n'ont pas été suggérés aux analystes (par exemple, F10).



Figure: 4: Relations entre 48 facteurs et comment les développeurs et les analystes évaluent leur propre productivité dans trois entreprises:

Les trois colonnes suivantes présentent les données de trois entreprises, ainsi que les données des analystes de Google. Chacune de ces colonnes est divisée en deux sous-colonnes. Estimation de



sous-colonne(score) contient des coefficients de régression qui quantifient la force de l'association d'un facteur avec une estimation de sa productivité. Plus le nombre est élevé, plus l'association est forte. Par exemple, dans la première colonne de Google, l'estimation est de 0,414. Dans ce cas, cela signifie que pour chaque point de concordance croissante avec l'énoncé sur l'enthousiasme au travail (F1), le modèle prédit une augmentation de la cote de productivité du répondant de 0,414 point avec contrôle des variables démographiques. Les notes peuvent être négatives. Par exemple, dans les trois entreprises, plus le taux de rotation du personnel dans l'équipe (F48) est élevé, plus l'estimation de leur productivité est faible. À côté de chaque score se trouve un indicateur qui reflète clairement le score.



Notez que les scores ne signifient pas des notes plus élevées des facteurs, mais une corrélation plus élevée entre le facteur et l'évaluation de votre productivité. Par exemple, National Instruments (F1) obtient un meilleur enthousiasme que les autres entreprises. Cela ne veut pas dire que les développeurs y sont plus enthousiastes: dans cette entreprise, il est un prédicteur plus fort de l'évaluation de leur productivité. Nous ne fournissons pas les notes elles-mêmes, car cela est interdit par les termes de la coopération. Sans contexte complet, les notations peuvent être mal interprétées. Par exemple, si nous signalons que les développeurs d'une entreprise sont moins enthousiasmés par leur travail que les développeurs d'une autre entreprise, vous pourriez avoir l'impression qu'il vaut mieux ne pas travailler dans cette autre entreprise. Erreur de



deuxième sous-colonne(erreur) contient les erreurs standard du modèle pour chaque facteur. Plus la valeur est basse, mieux c'est. Intuitivement, des valeurs plus faibles semblent indiquer que lorsque les facteurs changent, le modèle prédit ses performances de manière plus fiable. Les valeurs d'erreur globales sont assez stables d'un facteur à l'autre, en particulier sur Google avec un grand nombre de répondants.



Un astérisque (*) indique que ce facteur était statistiquement significatif dans le modèle. Par exemple, l'enthousiasme pour le travail (F1) est statistiquement significatif dans les trois entreprises, tandis que la préparation aux réunions (F17) n'est significative que dans Google.



La colonne suivante contient le score moyen ( μ ) pour les trois entreprises avec l'écart type entre parenthèses ( σ). Le premier indicateur montre clairement la valeur du score moyen, le deuxième indicateur - la valeur de l'écart type. Par exemple, le score moyen pour l'enthousiasme au travail (F1) était de 0,43, l'écart type était de 0,051. Le tableau est trié par note moyenne.



La dernière colonne contient les différences entre les évaluations des développeurs de logiciels et des analystes chez Google. Des valeurs positives signifient des évaluations plus élevées des développeurs, des notes négatives plus élevées des analystes. Par exemple, en termes d'enthousiasme (F1), les scores des analystes sont légèrement inférieurs à ceux des développeurs.

4.2. Quels facteurs sont les meilleurs prédicteurs de la manière dont les développeurs évaluent leur productivité?

Les facteurs prédictifs les plus forts sont les énoncés avec le score moyen absolu le plus élevé. Les facteurs prédictifs les plus faibles sont ceux avec le score moyen absolu le plus bas. En d'autres termes, les facteurs en haut du tableau de la Fig. 4 sont les meilleurs prédicteurs. Pour comprendre quel facteur fournit le plus de confiance dans le résultat, nous avons mis en évidence des résultats statistiquement significatifs pour les trois entreprises:

• Enthousiasme pour le travail (F1)
• Soutien par les pairs pour les nouvelles idées (F2)
• Commentaires utiles sur la performance au travail (F11)

Discussion . Notez que les 10 premiers facteurs de productivité ne sont pas techniques. Cela est surprenant étant donné que, selon notre estimation, la plupart des recherches des développeurs de logiciels portent sur les aspects techniques. Par conséquent, une réorientation active vers le facteur humain peut conduire à une augmentation significative de l'influence des chercheurs sur l'industrie. Par exemple, les réponses aux questions suivantes peuvent être particulièrement utiles:

• Qu'est-ce qui rend les développeurs de logiciels enthousiasmés par leur travail? Qu'est-ce qui explique la différence d'enthousiasme? Quelles interventions peuvent accroître l'enthousiasme? Cet article peut compléter les recherches sur le bonheur [24] et la motivation [25].
• ? , ? ?
• , ? ? ?

Une autre caractéristique importante est le classement des facteurs de la ligne de recherche COCOMO II. Ces facteurs, obtenus au cours d'études empiriques de projets logiciels industriels et vérifiés par l'analyse numérique de 83 projets [26], ont été initialement formulés pour estimer le coût du développement logiciel. Par exemple, les facteurs de productivité de COCOMO II incluent la volatilité de la plateforme de base et la complexité du produit. Il est curieux que les facteurs COCOMO II pris en compte dans notre étude (F5, F10, F14, F16, F24, F26, F28, F32, F33, F34, F36, F38, F39, F43, F44, F46, F47, F48) ont reçu moins valeurs. On peut supposer qu'ils permettent de prédire une pire productivité. La moitié supérieure des facteurs prédictifs (F1 - F24) ne comprenait que 5 des COCOMO II et la moitié inférieure - 14 facteurs. Nous pouvons proposer deux interprétations différentes. Premier:COCOMO II manque de plusieurs facteurs de productivité importants, et les futures itérations de COCOMO II pourraient être plus prédictives si davantage de facteurs que nous avons étudiés, tels que le soutien à l'autonomie des approches de travail, sont introduits dans l'entreprise. Autre interprétation: COCOMO II est adapté à la tâche actuelle - fixer la productivité au niveau du projet [6], [27], [28], [29], [30], [31] - mais moins adapté pour fixer la productivité au niveau du développeur individuel. Cette interprétation met l'accent sur l'importance et la nouveauté de nos résultats.COCOMO II est adapté à la tâche actuelle - fixer la productivité au niveau du projet [6], [27], [28], [29], [30], [31] - mais moins adapté pour fixer la productivité au niveau du développeur individuel. Cette interprétation met l'accent sur l'importance et la nouveauté de nos résultats.COCOMO II est adapté à la tâche actuelle - fixer la productivité au niveau du projet [6], [27], [28], [29], [30], [31] - mais moins adapté pour fixer la productivité au niveau du développeur individuel. Cette interprétation met l'accent sur l'importance et la nouveauté de nos résultats.



En outre, tous les facteurs COCOMO II étaient des facteurs prédictifs de productivité relativement faibles et statistiquement non significatifs dans les trois entreprises. Par exemple:

• Mon logiciel a besoin de beaucoup de puissance de traitement (F39).
• Mon logiciel a besoin d'un vaste magasin de données (F43).
• Ma plate-forme logicielle (par exemple, environnement de développement, logiciel ou pile matérielle) évolue rapidement (F46).

Une explication: au cours des 20 années écoulées depuis la création et les tests de COCOMO II, les plateformes sont devenues moins diversifiées en termes de productivité. Il est probable que les systèmes d'exploitation standardisés protègent désormais les développeurs des pertes de productivité dues aux changements matériels (par exemple, Android dans le développement mobile). De même, les plates-formes cloud peuvent protéger les développeurs contre les pertes de productivité dues à la mise à l'échelle des processus et aux besoins de stockage. Sans oublier, les frameworks modernes et les plates-formes cloud sont faciles à utiliser. De plus, la différence de productivité lors du traitement de grandes et petites quantités de données peut avoir disparu depuis la création de COCOMO II.

4.3. En quoi ces facteurs diffèrent-ils d'une entreprise à l'autre?

Pour répondre à cette question, vous pouvez regarder l'écart-type dans les estimations pour les trois sociétés. Voici les trois facteurs avec le moins de variabilité, c'est-à-dire avec les valeurs les plus stables d'une entreprise à l'autre:

1. Utilisation du télétravail pour la mise au point (F40).
2. Rétroaction utile sur la performance au travail (F4).
3. Soutien par les pairs pour les nouvelles idées (F2).

Nous pensons que la stabilité de ces facteurs en fait de bons candidats à la généralisation. D'autres sociétés devraient voir des résultats similaires sur ces facteurs.



Et voici les trois facteurs avec la plus grande variabilité, c'est-à-dire avec la plus grande répartition des valeurs entre les entreprises:

1. Utiliser les meilleurs outils et approches (F15).
2. Réutilisation du code (F25).
3. Précision des informations entrantes (F6).

Discussion . Les trois facteurs les moins variables (F40, F4 et F2) ont une caractéristique commune - ils ne sont pas liés à la technologie, mais à la société et à l'environnement. Cela suggère peut-être que partout où les développeurs travaillent, ils sont également affectés par le travail à distance, les commentaires et le soutien par les pairs pour les nouvelles idées. La modification de ces trois facteurs peut s'avérer être le plus grand impact.



Pourquoi les facteurs F15, F25 et F6 sont-ils si différents d'une entreprise à l'autre? Pour chacune d'elles, nous avons une explication possible basée sur ce que nous savons de ces entreprises.



L'utilisation des meilleurs outils et approches (F15) est le plus fortement associée au score de performance de Google, mais pas significativement associée à National Instruments. Explication possible: la base de code de Google est beaucoup plus grande. Par conséquent, l'utilisation de meilleurs outils et approches pour naviguer et comprendre efficacement la base de code plus large a un impact significatif sur la productivité. Et chez National Instruments, la productivité dépend moins des outils car la base de code est plus petite et plus claire.



La réutilisation du code (F25) est fortement liée au score de performance de Google, mais pas de manière significative chez ABB. Explication possible: Google facilite la réutilisation du code. La base de code est monolithique et tous les développeurs peuvent examiner pratiquement toutes les lignes de code de l'entreprise, la réutilisation ne nécessite donc pas beaucoup d'efforts. Et ABB dispose de nombreux référentiels auxquels vous devez accéder. Et dans cette entreprise, les gains de productivité (via la réutilisation) peuvent être compensés par des pertes de productivité (liées à la recherche et à la récupération du bon code).



La précision de l'information (F6) est étroitement liée aux scores de performance de National Instruments, mais pas significativement liée à ABB. Explication possible: les développeurs d'ABB sont mieux protégés de l'influence d'informations inexactes. En particulier, chez ABB, plusieurs niveaux de l'équipe de support sont dédiés à l'obtention des informations correctes sur les bogues auprès des clients. Si le développeur reçoit des informations inexactes, sa productivité peut chuter, car il doit déléguer la tâche d'affiner les données à l'équipe de support.

4.4. Qu'est-ce qui permet de prédire l'évaluation d'un développeur de sa productivité, en particulier par rapport à d'autres travailleurs du savoir?

Pour répondre à cette question, passez à la dernière colonne de la Fig. 4. Si nous examinons plusieurs relations entre les notations maximales, nous verrons que l'évaluation par les analystes de leur productivité est plus fortement associée à:

• Perception positive de leurs coéquipiers (F7).
• Autonomie dans l'organisation du temps de travail (F4).

En revanche, l'évaluation par les développeurs de leur productivité est plus fortement liée à:

• Effectuer diverses tâches dans le cadre du travail (F13).
• Travailler efficacement en dehors de leur lieu de travail (F30).

Discussion . Dans l'ensemble, les résultats suggèrent que les développeurs sont quelque peu similaires aux autres travailleurs du savoir et quelque peu différents. Par exemple, la productivité des développeurs est mieux prédite par l'enthousiasme au travail, et les analystes ont à peu près la même chose. Nous pensons que les entreprises peuvent utiliser nos résultats pour sélectionner des initiatives de productivité qui ciblent les développeurs ou choisir des initiatives plus larges.



La boîte à outils de développement unifié de Google peut expliquer pourquoi l'augmentation de la diversité des tâches est associée à des cotes de productivité plus élevées chez les développeurs, et non chez les analystes. La diversité des tâches peut réduire l'ennui et augmenter la productivité des deux groupes, mais les outils de développement unifiés de Google peuvent signifier que les développeurs peuvent utiliser les mêmes outils pour différentes tâches. Et les analystes peuvent avoir besoin d'utiliser différents outils pour différentes tâches, ce qui augmente l'effort cognitif lors du changement de contexte.



Le travail en dehors du bureau peut expliquer pourquoi l'amélioration de l'efficacité du travail en dehors du lieu de travail est plus fortement associée à des gains de productivité pour les développeurs que pour les analystes. Nous pensons que faire une pause dans le travail est plus néfaste pendant la programmation que pendant le travail analytique.



Parnin et Rugaber ont constaté que le retour au travail après une interruption est un problème fréquent et persistant pour les développeurs [32], conduisant au besoin de meilleurs outils pour les aider à se remettre au travail sur un problème [33].

4.5. Autres facteurs de productivité

À la fin du questionnaire, les répondants pouvaient indiquer des facteurs supplémentaires qui, à leur avis, affectent la productivité. Pour la plupart, ces ajouts étaient des descriptions identiques ou plus raffinées de nos 48 facteurs. Nous avons écarté ces ajouts, mais, si nécessaire, créé de nouveaux facteurs. Les documents supplémentaires contiennent des descriptions de nouveaux facteurs, ainsi que des descriptions mises à jour de ceux que nous avions initialement proposés. Les chercheurs potentiels peuvent avoir une nouvelle question d'équipe mixte pour travailler sur un projet, ou affiner ou suggérer des ventilations de questions plus spécifiques pour les facteurs F15, F16 et F19.

4.6. Démographie

Chez Google et National Instruments, ni les modèles démographiques généraux, mais les variables associées individuelles étaient des prédicteurs statistiquement significatifs de leurs scores de performance.



Pour ABB, le modèle démographique s'est avéré significatif ( F = 3 , 406 , df = (5 , 131) , p <0,007). Le sexe s'est également révélé être un facteur statistiquement significatif ( p = 0,007); les femmes estiment leur productivité de 0,83 point de plus que les hommes. Les participants d'autres sexes («autres») ont obtenu un score supérieur de 1,6 point à celui des hommes ( p = 0,03). La position ( p= 0,04), chaque année supplémentaire, l'entreprise a augmenté son estimation de performance de 0,02 point. Pour autant que nous le sachions, les différences entre ABB et les deux autres sociétés n'expliquent pas pourquoi ces facteurs démographiques ne seraient significatifs que dans ABB et nulle part ailleurs.

4.7. Application en pratique et en recherche

Comment utiliser nos résultats dans la pratique? Nous avons fourni une liste classée des facteurs les plus importants dans la prévision de la productivité qui peuvent être utilisés pour prioriser les initiatives. Des exemples d'initiatives peuvent être trouvés dans des documents de recherche antérieurs.



Par exemple, pour accroître l'enthousiasme au travail, Markos et Sridevi ont suggéré d'aider les travailleurs à se développer professionnellement [34] grâce à des ateliers sur la technologie et la communication interpersonnelle. En outre, les chercheurs ont suggéré d'introduire la pratique d'appréciation du bon travail. Par exemple, ABB expérimente l'appréciation du public pour les développeurs qui ont mis en œuvre des outils et des techniques pour naviguer dans du code structuré [35].



Pour accroître le soutien aux nouvelles idées, Brown et Duguid ont proposé des moyens formels et informels de partager les meilleures pratiques [36]. Chez Google, la diffusion à sens unique des connaissances se fait par le biais de l'initiative Toilet Testing: les développeurs écrivent de courtes nouvelles sur les tests ou un autre domaine, puis ces notes sont affichées dans les toilettes de l'entreprise.



Pour améliorer la qualité de la rétroaction sur la productivité du travail, London et Smither suggèrent de se concentrer sur une rétroaction sans jugement, basée sur le comportement, interprétable et axée sur les résultats [37]. Chez Google, de tels retours peuvent être obtenus grâce à des post-mortems inoffensifs: après des événements négatifs importants tels qu'une baisse des services, les ingénieurs rédigent conjointement un rapport sur les actions qui ont influencé la cause profonde du problème, sans blâmer certains employés.



Nous voyons plusieurs directions pour les recherches futures basées sur nos travaux.



Premièrement, une revue systématique des articles qui caractérise l'impact et le contexte des preuves pour chaque facteur de productivité discuté ici améliorera la convivialité de notre travail en créant des relations causales. Là où ils sont faibles, l'applicabilité peut être améliorée en menant une série d'expériences pour établir la causalité.



Deuxièmement, comme mentionné dans les sections 4.5 et 4.6, les chercheurs potentiels peuvent utiliser des facteurs supplémentaires suggérés par nos répondants et examiner l'influence du sexe et d'autres facteurs démographiques sur la productivité des développeurs.



Troisièmement, l'impact de la recherche sur la productivité sur le développement de logiciels peut être amélioré grâce à un ensemble multidimensionnel de paramètres et d'outils qui ont été validés par la recherche empirique et la triangulation.



Quatrièmement, si les chercheurs peuvent calculer le coût de l'évolution des facteurs qui affectent la productivité, les entreprises peuvent prendre des décisions d'investissement plus intelligentes.

4.8. Des risques

Lors de l'interprétation des résultats de cette étude, plusieurs risques pesant sur sa validité doivent être pris en compte.



4.8.1. Risques pour l'exactitude des données



Premièrement, nous n'avons parlé que d'une seule mesure: l'évaluation de votre productivité. Il existe d'autres dimensions, y compris des mesures objectives, comme le nombre de lignes de code écrites par jour, une approche utilisée par Facebook [38]. Comme nous l'avons souligné dans la section 3.1, toutes les mesures de productivité ont des défauts, y compris la mesure de votre propre productivité. Par exemple, les développeurs peuvent être trop frivoles dans l'évaluation de leur productivité ou surestimer artificiellement leur évaluation en raison de préjugés dans la société [39]. Malgré ces lacunes, l'équipe dirigée par Zelenski s'appuie sur des travaux antérieurs pour argumenter la validité de l'évaluation des performances [40], également utilisée dans cet article.



Deuxièmement, nous avons mesuré notre productivité avec une seule question qui couvre à peine tout le spectre de la productivité des développeurs. Par exemple, la question se concentre sur la fréquence et l'intensité, mais ne tient pas compte de la qualité. Nous n'avons pas non plus demandé aux répondants de limiter leurs réponses à un laps de temps spécifique, de sorte que certains participants peuvent répondre en fonction de leurs expériences de la semaine dernière, tandis que d'autres ont évalué leurs expériences de l'année écoulée. Rétrospectivement, l'étude devrait fonctionner avec un intervalle de temps fixe.



Troisièmement, en raison du nombre limité de questions, nous nous sommes uniquement appuyés sur les facteurs qui ont été étudiés dans des travaux antérieurs. Les 48 questions que nous avons sélectionnées pourraient ne pas couvrir tous les aspects des comportements liés à la productivité. Ou, les facteurs que nous avons choisis pourraient être trop généraux dans certains cas. Par exemple, rétrospectivement, le facteur lié aux meilleurs «outils et approches» (F14) pourrait être plus puissant si nous séparions les outils des méthodes.



4.8.2. Risques internes pour la fiabilité



Quatrièmement, comme nous l'avons mentionné à la section 3.8, nous nous sommes inspirés de travaux antérieurs pour établir des relations causales entre les facteurs et la productivité, mais la force des preuves des relations peut varier. Il se peut que certains facteurs n'affectent l'évaluation de leur productivité qu'indirectement, par le biais d'autres facteurs, ou que leur lien a généralement la direction opposée. Par exemple, il est probable que le principal facteur de productivité, un enthousiasme accru pour le travail (F1), soit en fait dû à une productivité accrue.



4.8.3. Risques externes pour la fiabilité



Cinquièmement, bien que nous ayons examiné trois entreprises assez différentes, la généralisabilité avec d'autres types d'entreprises, avec d'autres organisations et d'autres types de travailleurs du savoir est limitée. Dans cet article, nous avons sélectionné des analystes en tant que représentants de non-développeurs, mais cette catégorie comprend plusieurs types de travailleurs du savoir - médecins, architectes et avocats. Un autre risque pour la fiabilité est le biais dû au manque de réponses: les personnes qui ont répondu aux questionnaires ont été auto-sélectionnées.



Sixièmement, nous avons analysé chaque facteur de productivité séparément, mais de nombreux facteurs peuvent s’accompagner. Ce n'est pas un problème d'analyse, mais l'applicabilité des résultats. Si les facteurs sont codépendants, le changement de l'un peut avoir un effet négatif sur l'autre.



4.8.4. Risques pour la



crédibilité constructive Septièmement, en créant cette étude, nous étions préoccupés par la possibilité que les répondants reconnaissent notre méthodologie d'analyse et ne répondent pas honnêtement. Nous avons essayé de réduire cette probabilité en séparant la question de la productivité de ses facteurs, mais les répondants ont peut-être pu tirer des conclusions sur notre méthodologie d'analyse.



Enfin, nous avons reformulé certaines des questions pour adapter l'étude à l'analyste, ce qui pourrait modifier de manière indésirable le sens des questions. Par conséquent, les différences entre les développeurs et les analystes peuvent provenir de différences dans les questions plutôt que dans la profession.

5. Travaux connexes

De nombreux chercheurs ont étudié les facteurs de productivité individuels pour les développeurs de logiciels. Par exemple, Moser et Nierstrasz ont analysé 36 projets de développement de logiciels et exploré l'impact potentiel des technologies orientées objet sur l'amélioration de la productivité des développeurs [41].



Un autre exemple est l'étude réalisée par DeMarco et Lister auprès de 166 programmeurs de 35 organisations effectuant un exercice de programmation d'une journée. Les auteurs ont constaté que le lieu de travail et l'organisation sont associés à la productivité [42].



Un troisième exemple est une expérience en laboratoire de Kersten et Murphy avec 16 développeurs. Il s'est avéré que ceux qui utilisaient l'outil pour se concentrer sur la tâche étaient beaucoup plus productifs que les autres [43].



De plus, l'analyse systématique de Wagner et Rouet donne une bonne idée de la relation entre les facteurs individuels et la productivité [14]. L'équipe dirigée par Mayer a proposé une analyse encore plus récente de la vue d'ensemble des facteurs de productivité [3]. En général, nos travaux se basent sur ces études de facteurs individuels avec une étude plus large de leur diversité.



La revue systématique de Petersen indique que sept articles quantifient les facteurs qui prédisent la productivité des développeurs de logiciels [44]. Dans chaque travail, des méthodes numériques sont utilisées pour la prévision, il s'agit généralement de régression, que nous avons également utilisée dans nos recherches. Les facteurs les plus courants sont liés à la taille du projet et 6 facteurs sur 7 sont explicitement formulés sur la base des facteurs de productivité de COCOMO II ([6], [27], [28], [29], [30], [31]). Le modèle de prévision le plus complexe de l'étude de Petersen utilise 16 facteurs [6].



Notre travail présente deux différences principales. Premièrement, par rapport aux travaux précédents, nous estimons plus de facteurs (48), et leur variété est plus large. Nous avons sélectionné des facteurs basés sur la psychologie industrielle et organisationnelle. Deuxièmement, nous avions un autre sujet d'analyse: les chercheurs précédents ont étudié ce qui pouvait prédire la productivité dans le cadre du projet, et nous nous sommes intéressés à la productivité personnelle des personnes.



Outre le développement de logiciels, des études antérieures comparaient des facteurs prédictifs de productivité dans d'autres professions, en particulier dans le domaine de la psychologie industrielle et organisationnelle. Bien que ces études se soient concentrées sur la productivité au niveau de l'entreprise [45] et le travail physique comme la fabrication [46], le domaine le plus étroitement lié est la productivité des travailleurs du savoir. Autrement dit, les gens utilisent activement les connaissances et les informations dans leur travail, généralement à l'aide d'un ordinateur [47]. Une comparaison des facteurs pour ces professions est présentée dans deux ouvrages principaux. La première est une étude d'équipe dirigée par Palwalin, explorant 38 facteurs que les études précédentes ont comparés à la productivité. Ces facteurs englobent l'espace de travail physique, virtuel et social,approches de travail personnelles et bien-être au travail [4]. Le deuxième travail est une étude de Hernaus et Mikulich sur 512 travailleurs du savoir. Les auteurs ont étudié 14 facteurs, répartis en trois catégories [9]. Nous nous sommes appuyés sur ces deux travaux pour préparer notre étude (section 3.2).



Cependant, les études comparant les facteurs de productivité des travailleurs du savoir n'ont pas prêté attention aux développeurs de logiciels. Il y a deux raisons principales pour cela. Premièrement, on ne sait pas dans quelle mesure les résultats globaux obtenus sont projetés sur les développeurs. Deuxièmement, ces études sont généralement extraites de facteurs spécifiques aux développeurs, tels que la réutilisation des logiciels et la complexité de la base de code [48]. Par conséquent, il existe un manque dans la littérature pour comprendre les facteurs qui permettent de prédire la productivité des développeurs. Combler cette lacune est pratique. Nous avons créé trois équipes de recherche dans trois entreprises pour améliorer la productivité. Combler ce manque de connaissances aide nos équipes à effectuer des recherches et les entreprises à investir dans la productivité des développeurs.

6. Conclusion

De nombreux facteurs affectent la productivité des développeurs, mais les entreprises disposent de ressources limitées pour se concentrer sur l'amélioration de la productivité. Nous avons créé et mené une étude dans trois entreprises pour classer et comparer différents facteurs. Les développeurs et les dirigeants peuvent utiliser nos résultats pour hiérarchiser leurs efforts. Pour faire simple, les articles précédents ont suggéré de nombreuses façons d'améliorer la productivité des développeurs de logiciels, et nous avons suggéré comment vous pouvez hiérarchiser ces façons.

Bloc de questions

Qu'est-ce qui rend un développeur productif?

Cette recherche anonyme d' une page vous prendra 15 minutes et nous aidera à mieux comprendre ce qui affecte la productivité des développeurs. Veuillez répondre ouvertement et honnêtement.



La recherche posera des questions sur vous, votre projet et votre logiciel. N'oubliez pas:



mon logiciel fait référence au logiciel principal que vous développez chez ABB, y compris les produits et l'infrastructure. Si vous travaillez sur différents programmes, répondez uniquement au programme principal.



Mon projet appartient à l'équipe avec laquelle vous créez des logiciels. Veuillez répondre à toute question relative à d'autres développeurs de logiciels chez ABB.



Certaines questions portent sur des sujets potentiellement sensibles. Remplissez les réponses afin que personne ne puisse regarder par-dessus votre épaule, et effacez l'historique de votre navigateur et les cookies après avoir rempli le questionnaire.



Veuillez évaluer votre accord avec les affirmations suivantes.





Ces questions sont conçues pour fournir une évaluation complète des facteurs qui peuvent affecter la productivité. Sommes-nous en train de manquer quelque chose?



Sexe (facultatif)



Quel est votre titre? (facultatif)



En quelle année avez-vous rejoint ABB?

Matériaux additionnels

Facteurs de productivité relevés par les répondants

Dans cette section, nous énumérons les facteurs que les répondants ont décrits dans leurs réponses à la question ouverte. Nous décrirons d'abord plusieurs nouveaux facteurs, puis nous donnerons des descriptions de facteurs liés à ceux déjà dans l'étude. Nous avons complété les commentaires des répondants par des codes en utilisant nos facteurs. Ici, nous ne discutons ni n'évaluons les réponses des personnes, nous ne complétons pas les descriptions existantes de nos facteurs.

Nouveaux facteurs

Dans les commentaires, 4 sujets ont été soulevés qui n'étaient pas reflétés dans notre étude. Six réponses ont soulevé des sujets de l'équipe mixte de projet, en particulier le ratio gestionnaires / développeurs; la présence d'un nombre suffisant d'employés dans le projet; et si la direction est en mesure de maintenir une forte propriété du produit. Un répondant a noté l'impact sur la productivité du type de logiciel (serveur, client, mobile, etc.). Un autre a noté l'influence de facteurs physiologiques tels que le nombre d'heures de sommeil. Un autre a mentionné les possibilités de croissance personnelle.

Facteurs disponibles

F1. Cinq répondants ont mentionné des facteurs liés à l'enthousiasme au travail: deux ont mentionné la motivation et la reconnaissance au travail, l'un - la morale, l'autre - un immeuble de bureaux déprimant.



F3. Quatre des répondants ont noté des facteurs liés à l'autonomie dans le choix des méthodes de travail. L'un évoque l'autonomie au niveau des équipes, un autre la politique qui empêche l'utilisation d'un bon système open source, le troisième les priorités adoptées dans l'entreprise qui limitent l'utilisation de certaines méthodes en équipe.



F4. Un répondant a noté l'autonomie dans la planification des heures de travail, qui est limitée aux priorités dictées par le besoin de promotion.



F5. Trois répondants ont souligné la compétence en leadership. L'un a mentionné le leadership avec une stratégie cohérente, le second - les priorités contradictoires transmises par la direction, le troisième - la gestion de la productivité des employés.



F6. Huit répondants ont déclaré avoir fourni des informations exactes. Trois ont mentionné la communication entre les équipes par le biais de la documentation (et d'autres canaux), et deux ont mentionné la définition claire des objectifs et des plans de l'équipe.



F7. Deux répondants ont noté des sentiments positifs envers leurs collègues à la lumière de la cohésion d'équipe et d'équipe.



F8. Un répondant a souligné l'autonomie dans le travail: la politique de l'entreprise dicte les ressources qui peuvent être utilisées.



F9. Un répondant a noté la résolution des conflits, indiquant que les habitudes personnelles des coéquipiers étaient contraires aux normes sociales.



F10. Quatre répondants ont noté la compétence des développeurs. L'un a mentionné les difficultés de compréhension du code, l'autre - la connaissance du sujet, le troisième - le sérieux de l'attitude envers les tests.



F11. Un répondant a noté des commentaires sur la productivité du travail: obtenir la reconnaissance des collègues et de la direction, promotion.



F12. Un répondant a souligné la complexité de la mise en œuvre du logiciel «de mon cerveau au produit expédié».



F13. Deux répondants ont noté la variété des tâches, en particulier l'interception des tâches au nom de leur équipe et le changement de contexte.



F14 Quatre répondants ont évalué les exigences et les architectes comme compétents. L'un mentionnait une attention insuffisante aux problèmes, un autre - la lisibilité des documents architecturaux, le troisième - la qualité des plans de projet, le quatrième - la présence d'un «support adéquat dans l'élaboration des exigences».



F15. Trente-deux répondants ont déclaré utiliser les meilleurs outils et approches. Douze ont mentionné les performances des outils, en particulier les problèmes de vitesse et de latence lors de la construction et du test. Cinq personnes ont mentionné les fonctionnalités disponibles, trois ont mentionné des problèmes de compatibilité et de migration, deux ont mentionné que même le meilleur outil disponible pourrait ne pas répondre aux besoins. D'autres commentaires sur les outils et l'approche mentionnent le niveau d'automatisation offert par les outils; débogueurs et simulateurs spécialisés; Approches agiles; tests floconneux et outils associés; des outils qui fonctionnent bien à distance; choix des langages de programmation; outils obsolètes; séparation des préférences personnelles dans les outils de celles adoptées dans l'entreprise.



F 16. Dix-neuf répondants ont noté un transfert adéquat des connaissances entre les personnes. Neuf personnes ont évoqué les difficultés de communication avec les autres équipes: trois - s'entendre sur des objectifs entre équipes, une - s'entendre sur des objectifs au sein d'une grande équipe, l'autre - parvenir à un accord entre équipes. Deux ont souligné la difficulté de coordonner le travail dans une équipe internationale ou ponctuelle. Deux autres ont mentionné la nécessité de s'appuyer sur la documentation d'autres équipes. Deux ont commenté la durée de la révision du code. Deux autres ont mentionné la connaissance des installations de travail des coéquipiers. L'un mentionnait la recherche de la bonne personne, l'autre - les retards dans l'interaction, le troisième - la communication entre ingénieurs et spécialistes du domaine. Enfin, on a mentionné l'importance de clarifierquels canaux de communication sont préférables dans certaines situations.



F18. Deux répondants ont mentionné des approches pour la tenue de réunions, l'un d'eux a mentionné que l'efficacité des réunions dépend de la disponibilité des salles de réunion.



F19. Vingt-quatre répondants ont noté des interruptions et des distractions du travail. Dix ont mentionné des environnements bruyants et sept ont indiqué que les bureaux ouverts réduisent la productivité. Quatre ont mentionné les difficultés liées au multitâche et au changement de contexte. Quatre autres ont signalé le besoin de se concentrer soit sur leur emploi principal, soit sur des tâches «facultatives» comme les entretiens. Deux ont mentionné la difficulté à se concentrer lors des trajets domicile-travail.



F25. Un répondant a noté la réutilisation du code, soulignant que les API de 2 à 3 lignes augmentent la complexité avec une contribution minimale à la réduction de la duplication.



F26. Un répondant a commenté l'expérience de la plate-forme logicielle, indiquant que les problèmes s'aggravent lorsqu'un développeur passe d'un projet à l'autre.



F27. Trois répondants ont noté l'architecture logicielle et la réduction des risques. L'un d'eux a souligné «à quel point l'architecture du produit est connue, à quel point elle est interconnectée et comment elle soutient les personnes qui connaissent leurs rôles et sont capables de se concentrer, qui connaissent leurs responsabilités et leurs limites, et ce qu'elles possèdent». Un autre a noté que l'architecture, grâce à la modularité, peut faciliter l'échange entre les composants logiciels. Le troisième a suggéré que l'architecture devrait être cohérente avec la structure de l'organisation.



F32. Quatre répondants ont mentionné la nécessité de changer de contexte. Deux ont mentionné que la commutation est nécessaire lors du déplacement entre les projets. L'un a expliqué que le besoin d'un changement de contexte est différent du plaisir d'un changement. Un autre a mentionné que les «projets de productivité» en eux-mêmes peuvent réduire la productivité.



F34. Cinq répondants ont noté des délais serrés. L'un a souligné que cela contribue à la croissance de la dette technique, l'autre - que de tels délais peuvent conduire à un gaspillage de ressources.



F42. Trois répondants ont fait état de limitations logicielles. Deux ont signalé des restrictions de confidentialité et un des restrictions de sécurité critiques.



F44. Onze répondants ont noté la complexité du logiciel. Deux ont mentionné la complexité particulière du code hérité, deux ont fait référence à la dette technique, et chacun a noté le contrôle des versions, la maintenance du logiciel et



la compréhension du code.

Coefficients:
Estimate     Std. Error     t value     Pr(>|t|)
(Intercept)             2.786969     0.111805     24.927     < 0.0000000000000002 ***
log(lines_changed + 1)     0.045189     0.009296     4.861         0.00000122 ***
level                 -0.050649     0.015833     -3.199     0.00139 **
job_codeENG_TYPE2         0.194108     0.172096     1.128         0.25944
job_codeENG_TYPE3         0.034189     0.076718     0.446         0.65589
job_codeENG_TYPE4         -0.185930     0.084484     -2.201     0.02782 *
job_codeENG_TYPE5         -0.375294     0.085896     -4.369     0.00001285 ***
---
Signif. codes: 0 `***` 0.001 `**` 0.01 `*` 0.05 `.` 0.1 ` ` 1
Residual standard error: 0.8882 on 3388 degrees of freedom
Multiple R-squared: 0.01874, Adjusted R-squared: 0.017
F-statistic: 10.78 on 6 and 3388 DF, p-value: 0.000000000006508

Figure: 5: Modèle 1: Résultats complets de la régression linéaire

Coefficients:
Estimate     Std. Error     t value     Pr(>|t|)
(Intercept)                 2.74335     0.09706     28.265     < 0.0000000000000002
log(changelists_created + 1)     0.11220     0.01608     6.977         0.00000000000362
level                     -0.04999     0.01574     -3.176     0.00151
job_codeENG_TYPE2             0.27044     0.17209     1.571         0.11616
job_codeENG_TYPE3             0.02451     0.07644     0.321         0.74847
job_codeENG_TYPE4             -0.21640     0.08411     -2.573     0.01013
job_codeENG_TYPE5             -0.40194     0.08559     -4.696     0.00000275538534
(Intercept)                 ***
log(changelists_created + 1)     ***
level                     **
job_codeENG_TYPE2
job_codeENG_TYPE3
job_codeENG_TYPE4             *
job_codeENG_TYPE5             ***
---
Signif. codes: 0 `***` 0.001 `**` 0.01 `*` 0.05 `.` 0.1 ` ` 1
Residual standard error: 0.885 on 3388 degrees of freedom
Multiple R-squared: 0.02589, Adjusted R-squared: 0.02416
F-statistic: 15.01 on 6 and 3388 DF, p-value: < 0.00000000000000022

Figure: 6: Modèle 2: Résultats complets de la régression linéaire

Coefficients:
Estimate     Std. Error     t value     Pr(>|t|)
(Intercept)                 2.79676     0.11141     25.102     < 0.0000000000000002
log(lines_changed + 1)         -0.01462     0.01498     -0.976     0.32897
log(changelists_created + 1)     0.13215     0.02600     5.082         0.000000394
level                     -0.05099     0.01578     -3.233     0.00124
job_codeENG_TYPE2             0.27767     0.17226     1.612         0.10706
job_codeENG_TYPE3             0.02226     0.07647     0.291         0.77102
job_codeENG_TYPE4             -0.22446     0.08452     -2.656     0.00795
job_codeENG_TYPE5             -0.40819     0.08583     -4.756     0.000002057
(Intercept)                 ***
log(lines_changed + 1)
log(changelists_created + 1)     ***
level                     **
job_codeENG_TYPE2
job_codeENG_TYPE3
job_codeENG_TYPE4             **
job_codeENG_TYPE5             ***
---
Signif. codes: 0 `***` 0.001 `**` 0.01 `*` 0.05 `.` 0.1 ` ` 1
Residual standard error: 0.885 on 3387 degrees of freedom
Multiple R-squared: 0.02616, Adjusted R-squared: 0.02415
F-statistic: 13 on 7 and 3387 DF, p-value: < 0.00000000000000022

Figure: 7: Modèle 3: Résultats complets de la régression linéaire.