Discussion :

[Stéphane le calme]

Est-il possible de mesurer la productivité des développeurs ? Oui, selon McKinsey
qui suggère une approche adaptée au contexte et aux objectifs

La productivité des développeurs logiciels est un sujet qui suscite beaucoup de débats et de controverses dans l’industrie du logiciel. Comment mesurer l’efficacité et la performance des développeurs qui travaillent sur des projets complexes, créatifs et collaboratifs ? Est-il possible de trouver des indicateurs objectifs et fiables qui reflètent la qualité et la valeur du travail accompli ? Quels sont les facteurs qui influencent la productivité des développeurs et comment les optimiser ?

Comparé à d'autres fonctions commerciales critiques telles que les ventes ou les opérations client, le développement de logiciels est constamment sous-évalué. La croyance de longue date de nombreux techniciens est qu'il n'est pas possible de l'évaluer correctement et que, dans tous les cas, seuls les ingénieurs formés sont suffisamment informés pour évaluer les performances de leurs pairs. Pourtant, ce statu quo n'est plus tenable. Maintenant que la plupart des entreprises deviennent (à un degré ou à un autre) des éditeurs de logiciels, quel que soit leur secteur d'activité, les dirigeants doivent savoir qu'ils déploient leurs talents les plus précieux avec le plus de succès possible.

Il est indéniable qu'il est difficile de mesurer la productivité des développeurs. D'autres fonctions peuvent être raisonnablement bien mesurées, certaines même avec une seule métrique ; alors que dans le développement de logiciels, le lien entre les entrées et les sorties est beaucoup moins clair. Le développement de logiciels est également un travail hautement collaboratif, complexe et créatif et nécessite différentes métriques pour différents niveaux (tels que les systèmes, les équipes et les individus). De plus, même s'il existe un véritable engagement à suivre correctement la productivité, les mesures traditionnelles peuvent nécessiter des systèmes et des logiciels configurés pour permettre une mesure plus nuancée et complète. Pour certaines métriques standard, des piles technologiques entières et des pipelines de développement doivent être reconfigurés pour permettre le suivi, et la mise en place des instruments et outils nécessaires pour obtenir des informations significatives peut nécessiter des investissements importants à long terme. De plus, le paysage du développement de logiciels évolue rapidement, car les outils d'IA générative tels que CopilotX et ChatGPT ont le potentiel de permettre aux développeurs d'effectuer des tâches jusqu'à deux fois plus rapidement.

McKinsey estime qu'il est possible de mesurer la productivité des développeurs logiciels

Cependant, le cabinet précise que cela nécessite une approche adaptée au contexte et aux objectifs de chaque entreprise.

Tirer parti des informations sur la productivité

Avec un accès à des données et des informations sur la productivité plus riches, les dirigeants peuvent commencer à répondre à des questions urgentes sur les talents en génie logiciel qu'ils se sont tant battus pour attirer et retenir, telles que les suivantes :

• Quels sont les obstacles qui empêchent les ingénieurs de travailler à leur meilleur niveau ?
• Dans quelle mesure la culture et l'organisation affectent-elles leur capacité à produire leur meilleur travail ?
• Comment savoir si nous utilisons leur temps sur des activités qui génèrent vraiment de la valeur ?
• Comment pouvons-nous savoir si nous avons tous les talents en génie logiciel dont nous avons besoin ?

Comprendre les fondements

Pour utiliser un système suffisamment nuancé de mesure de la productivité des développeurs, il est essentiel de comprendre les trois types de mesures qui doivent être suivies : celles au niveau du système, au niveau de l'équipe et au niveau individuel. Contrairement à une fonction telle que les ventes, où une mesure au niveau du système des dollars gagnés ou des transactions conclues pourrait être utilisée pour mesurer le travail des équipes et des individus, le développement de logiciels est collaboratif d'une manière distincte qui nécessite des lentilles différentes. Par exemple, bien que la fréquence de déploiement soit une mesure parfaitement adaptée pour évaluer les systèmes ou les équipes, elle dépend du fait que tous les membres de l'équipe effectuent leurs tâches respectives et n'est donc pas un moyen utile de suivre les performances individuelles.

Une autre dimension critique à reconnaître est ce que les différentes mesures font et ne vous disent pas. Par exemple, mesurer la fréquence de déploiement ou le délai d'exécution des changements peut vous donner une vision claire de certains résultats, mais pas de savoir si une organisation d'ingénierie est optimisée. Et bien que des métriques telles que les points d'histoire terminés ou les interruptions puissent aider à déterminer l'optimisation, elles nécessitent une enquête plus approfondie pour identifier les améliorations qui pourraient être bénéfiques.

En construisant notre ensemble de métriques, nous avons cherché à développer les deux ensembles de métriques déjà développés par l'industrie du logiciel. Le premier est la métrique DORA, du nom de l'équipe de recherche et d'évaluation DevOps de Google. Ce sont les normes les plus proches du secteur technologique et elles sont excellentes pour mesurer les résultats. Lorsqu'une métrique DORA renvoie un résultat inférieur à la moyenne, c'est un signal pour enquêter sur ce qui s'est mal passé, ce qui peut souvent impliquer une recherche prolongée. Par exemple, si une métrique telle que la fréquence de déploiement augmente ou diminue, il peut y avoir plusieurs causes. Déterminer ce qu'ils sont et comment les résoudre n'est souvent pas simple.

Le deuxième ensemble de mesures développées par l'industrie est constitué des métriques SPACE (satisfaction et bien-être, performance, activité, communication et collaboration, et efficacité et flux), que GitHub et Microsoft Research ont développées pour augmenter les métriques DORA. En adoptant un objectif individuel, en particulier autour du bien-être des développeurs, les métriques SPACE sont très utiles pour clarifier si une organisation d'ingénierie est optimisée. Par exemple, une augmentation des interruptions subies par les développeurs indique un besoin d'optimisation.

En plus de ces mesures déjà puissantes, notre approche cherche à identifier ce qui peut être fait pour améliorer la façon dont les produits sont livrés et ce que valent ces améliorations, sans avoir besoin d'une instrumentation lourde. Compléter les métriques DORA et SPACE avec des métriques axées sur les opportunités peut créer une vue de bout en bout de la productivité des développeurs de logiciels.

Les métriques utilisées par McKinsey

McKinsey s'intéresse à l’optimisation du temps passé par les développeurs de logiciels dans les activités de création de produits (boucle interne) et les tâches nécessaires pour mettre le code en production (boucle externe). Le cabinet a présenté quatre méthodes pour identifier les domaines d’amélioration potentiels :

• analyse du temps passé dans la boucle interne/externe : il s’agit de mesurer la répartition du temps entre les activités de codage, de construction et de test unitaire (boucle interne) et les activités d’intégration, de test d’intégration, de publication et de déploiement (boucle externe). L’objectif est de maximiser le temps passé dans la boucle interne, qui génère de la valeur et motive les développeurs, en automatisant et en améliorant les outils pour la boucle externe ;
• benchmark de l’indice de vélocité des développeurs : il s’agit d’un sondage qui mesure la technologie, les pratiques de travail et l’habilitation organisationnelle d’une entreprise et les compare à celles de ses pairs. Cette comparaison permet de mettre en évidence des opportunités spécifiques, que ce soit dans la gestion du backlog, les tests ou la sécurité et la conformité ;
• analyse des contributions : il s’agit d’évaluer les contributions individuelles au backlog d’une équipe (à partir des données des outils de gestion du backlog tels que Jira) et de normaliser les données pour tenir compte des nuances. Cette analyse peut aider à identifier les tendances qui entravent l’optimisation de la capacité de l’équipe. Elle peut également aider à définir des opportunités de formation ou d’amélioration des compétences individuelles et à repenser la distribution des rôles au sein d’une équipe ;
• score de capacité des talents : Il s’agit d’un résumé des connaissances, des compétences et des aptitudes individuelles d’une organisation, basé sur des cartes de capacité standard de l’industrie. Idéalement, les organisations devraient aspirer à une distribution « en diamant » de la compétence, avec la majorité des développeurs dans la plage moyenne de compétence. Ce score peut révéler des opportunités de coaching et d’amélioration des compétences, et dans des cas extrêmes, appeler à une reconsidération de la stratégie de talents.

Les difficultés et les pièges de la mesure de productivité des développeurs logiciels

Un article paru sur Stack Overflow a souligné les difficultés et les pièges de la mesure de la productivité des développeurs logiciels. L’auteur critique notamment l’utilisation des heures travaillées comme proxy de la performance, qui peut conduire à une culture toxique où la présence au bureau prime sur la qualité du travail. Il met également en garde contre le risque d’ignorer le travail négatif, c’est-à-dire le travail qui réduit la valeur du produit ou qui crée des problèmes à résoudre ultérieurement. Il suggère plutôt de se concentrer sur les résultats concrets et mesurables du travail des développeurs, comme le nombre de fonctionnalités livrées, le taux d’erreurs corrigées, le feedback des utilisateurs ou le retour sur investissement.

Un article paru sur Stackify propose une liste de métriques importantes à suivre pour évaluer la productivité des développeurs logiciels. Parmi ces métriques, on trouve le nombre de lignes de code écrites, le nombre de commits effectués, le temps passé à coder, le temps passé à tester, le temps passé à déboguer, le nombre de bugs détectés, le nombre de bugs résolus, le taux de couverture des tests, le taux d’utilisation des ressources ou encore le niveau de satisfaction des clients. L’article précise toutefois que ces métriques doivent être interprétées avec prudence et qu’elles ne doivent pas être utilisées pour comparer les développeurs entre eux ou pour les sanctionner.

Conclusion

Tous ces différents articles indiquent deux choses : la première est que la mesure de la productivité des développeurs logiciels est possible, la seconde est qu’elle n’est pas simple ni universelle. Elle dépend du type de logiciel, de la structure de l’équipe et de l’organisation, ainsi que des objectifs visés. Elle nécessite également une approche holistique qui prend en compte les différents aspects du travail des développeurs, comme le temps, la qualité, l’impact, l’expérience et la culture. Enfin, elle doit être utilisée avec discernement et dans un but d’amélioration continue plutôt que de contrôle ou de jugement.

Source : McKinsey

Et vous ?

Cette étude de McKinsey est-elle crédible ou pertinente ?
Quelle est selon vous la définition de la productivité des développeurs logiciels ? Est-il possible de la mesurer ?
Sinon, pourquoi ? Si oui, quelles sont les méthodes que vous utilisez ou que vous connaissez pour mesurer la productivité des développeurs logiciels ?
Quels sont les avantages et les inconvénients de ces méthodes ?
Quels sont les facteurs qui influencent positivement ou négativement la productivité des développeurs logiciels ?
Comment améliorer la productivité des développeurs logiciels dans votre entreprise ou votre équipe ?

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

J'ai connu un dev qui était très bien vu parce qu'il était vraiment rapide.
Étonnamment, quand arrivait les tests de validation, on passait du temps majoritairement à débugger son code
Et curieusement son aura de kador auprès des boss ne ternissait pas malgré ce fait assez incriminant.

[pboulanger]

Avant de vouloir mesurer la productivité des développeurs, ils devraient commencer par mesurer la productivité de leurs consultants... Lorsque l'on voit le prix facturé à l'état français et les effets délétères de leurs rapports sur l'économie et l'infrastructure française je m'interroge sur la pertinence de leur réflexion.
Pour faire simple: avant de vouloir l'aiguille dans l'oeil de ton voisin, enlève la poutre dans le tien.

[solstyce39]

Avant de vouloir mesurer la productivité des développeurs, ils devraient commencer par mesurer la productivité de leurs consultants... Lorsque l'on voit le prix facturé à l'état français et les effets délétères de leurs rapports sur l'économie et l'infrastructure française je m'interroge sur la pertinence de leur réflexion.
Pour faire simple: avant de vouloir l'aiguille dans l'oeil de ton voisin, enlève la poutre dans le tien.

haha oui, j'ai vu McKinsey, jme suis dis direct la même chose

[totozor]

Pourtant, ce statu quo n'est plus tenable. Maintenant que la plupart des entreprises deviennent (à un degré ou à un autre) des éditeurs de logiciels, quel que soit leur secteur d'activité, les dirigeants doivent savoir qu'ils déploient leurs talents les plus précieux avec le plus de succès possible.

Je ne suis pas développeur et je travaille pas dans une entreprise dont le développement est le coeur de métier mais je bosse beaucoup avec nos developpeurs internes. Et ma première conclusion est simple : la valeur des développeurs interne ne vient pas de leur productivité mais de leur capacité à s'adapter à un evironnement qui n'est pas forcément son environement de travail naturel, à un client qui ne sait pas ce qu'il veut ou qui ne sait pas l'expliquer clairement etc.

les mesures traditionnelles peuvent nécessiter des systèmes et des logiciels configurés pour permettre une mesure plus nuancée et complète. Pour certaines métriques standard, des piles technologiques entières et des pipelines de développement doivent être reconfigurés pour permettre le suivi

Bonne idée ça, changeons les méthodes de travail pour pouvoir faire un suivi et constater que les dev ne sont pas perfomants, étrangement les clients étaient satisfaits avant et ne le sont plus.
On prétextera à la fin une résistance au changement pour justifier la non adoption des nouvelles méthodes.
Je passe une grande partie des mes journées à faire des indicateurs, ma première ligne de conduite est qu'on ne doit pas dégrader le travail pour réussir à le mesurer. Il faut mieux bien bosser sans être capable de le prouver que d'être capable de prouver qu'on bosse mal.

Avec un accès à des données et des informations sur la productivité plus riches, les dirigeants peuvent commencer à répondre à des questions urgentes sur les talents en génie logiciel qu'ils se sont tant battus pour attirer et retenir, telles que les suivantes*:

• Quels sont les obstacles qui empêchent les ingénieurs de travailler à leur meilleur niveau*?
• Dans quelle mesure la culture et l'organisation affectent-elles leur capacité à produire leur meilleur travail*?
• Comment savoir si nous utilisons leur temps sur des activités qui génèrent vraiment de la valeur*?
• Comment pouvons-nous savoir si nous avons tous les talents en génie logiciel dont nous avons besoin*?

C'est là que je vois l'écart de philosophie entre un cabinet de conseil et une entreprise industrielle. Avant de parler de productivité, ils pensent déjà aux questions que la non performance implique. ils sont déjà en train d'essayer de justifier la non performance.
1 on mesure la performance
2 Si elle est bonne et que personne se plaint on passe à la suite, si elle n'est pas bonne on cherche les sources
3 On arrete de justifier la non performance passé et on commence à agir pour attaindre l'objectif dans l'avenir

Qu'une entreprise ne soit pas capable d'identifier les compétences nécessaire chez un dev est un problème en soit. Les matrices de compétences existent depuis la nuit des temps, à 26 ans j'ai réinventer le truc (pas si bien que ça) pour montrer à mes managers pourquoi je voulais faire monter en compétence les membres de mon équipe. J'étais un gamin, je n'envisage même pas que les RH d'une boite un minimum grande ne s'en charge pas.

Pour la suite je ne comprends pas:
Ils disent que le développement est essentiellement un travail collectif donc que la performance passe par la synchronisation des personnes pourtant aucune des mesures qu'ils proposent de traitent de ce sujet...
Ils parlent de productivité individuelle mais 2/3 des indicateurs proposés ne concernent même pas la productivité. ("la performance de compétence" de ton personnel est avant tout de ta responsabilité, s'il est là depuis longtemps mais qu'il est à la traine c'est probablement parce que tu ne lui a pas donné les formations nécessaire. Je ne parles que de compétence, pas de poil dans la main, ça c'est de la performance)

Je pensais honetement que McKinsey étaient des cadors de l'optimisation et qu'ils étaient donc capables de proposer des vrais indicateurs pertinents ou de dire pourquoi on ne peut pas en avoir facilement, mais en fait ils sont pas si malin que ça...
Je soupçonne que la meilleure conclusion est plutôt qu'on ne sait pas mesurer la productivité individuelle d'un dev de façon précise et réactive et qu'il faut donc soit allonger la période de mesure soit abandonner l'individualisation pour une mesure collective.
Et je penses que dans le dévelopement interne d'une entreprise industrielle quand on mesure la performance de l'équipe on doit intégrer le client (et là je parle de moi et mes confrères) dans "l'équipe" parce qu'il est un des facteur premier de la non performance.

[Fagus]

Je travaille dans le public.

Une fois, la direction a voulu payer un cabinet de conseil pour optimiser le service.

Déjà, j'ai jamais compris l'intérêt d'être audité par des juniors, qui ne sont même pas du métier et comprennent péniblement la nature de notre travail. Logiquement, on devrait apporter des conseils quand on a une grande expérience du sujet...

Finalement, on a obtenu un rapport en français de consultant, qui une fois traduit en français normal était assez creux et éludait les problèmes réels... qui en fait sont bien connus du service (mais la direction a des objectifs... bien différents)

À savoir, les objectifs du gouvernement sont d'économiser de l'argent, donc tous les indicateurs visent l'économie (mais pas intelligemment comme en supprimant les redondances, plutôt par rabot global en amputant autant le critique que l'inutile).

Donc, on a du matériel tout le temps en semi-panne, à la fois par économie matérielle et du personnel de la maintenance.
Comme le but c'est d'économiser autant que possible sur les salaires, plus de la moitié du personnel a démissionné et il y a plus de candidats. C'est d'ailleurs dommage, car on avait essayé d'expliquer à la direction que pas de personnel = 2 mois d'arrêt d'une partie de la production en été et qu'un seul jour de cette prod paye les salaires (sans compter que le travail non fait doit être externalisé au privé à grand frais)

Sans compter les problèmes "normaux" du public (par ex, que le personnel toxique et improductif doit être gardé, et que le seul moyen de diminuer la contagion c'est de les concentrer dans un service... le notre), ou que du personnel diplômé (ex secrétaire) est remplacé par des "agents sachant relativement lire et écrire" parce que c'est le minimum de la grille salariale (mais ça produit peu et le personnel très qualifié se retrouve à abandonner son travail pour faire du secrétariat)

Rien de tout ça dans le rapport des consultants. Vivent les consultants.

[escartefigue]

Rien de tout ça dans le rapport des consultants. Vivent les consultants.

Parfois, les consultants travaillent en toute autonomie, parfois, il ne font qu'écrire sur ordre, ce qu'on attend d'eux, ce qui permet de légitimer des actions (tant qu'à faire un plan social) sous le couvert d'un avis réputé extérieur et donc, à priori, impartial...

[ParseCoder]

Donc en gros pas grand chose de nouveau. On s'en serait douté. Mais ils font parler d'eux et c'est sans doute le plus important.

[GLDavid]

McInsey... je reviendrais pas sur notre bon président et sa lubie avec ces gens-là.
Moi, la boîte pour laquelle je travaille avait demandé à McInsey comment réorganiser la boîte pour qu'elle fonctionne en 'meilleure synergie' (mais si, ce terme de manager...)
De l'argent a été dépensé, des cadres auditionnés par McInsey (pas votre serviteur) et finalement, on a abouti à une idée lumineuse: "Tous ensemble pour demain" !
Wouah, la com' ! Et ca a été le maître mot pendant 1 an et puis... plus rien, les objectifs avaient changé, la boîte avait d'autres orientations et toutes ces belles paroles envolées.

De l'argent jeté par les fenêtres avez-vous dit ? Allons, qu'est-ce qui a bien pû vous faire penser ça

[stardeath]

Conclusion

Tous ces différents articles indiquent deux choses : la première est que la mesure de la productivité des développeurs logiciels est possible, la seconde est qu’elle n’est pas simple ni universelle. Elle dépend du type de logiciel, de la structure de l’équipe et de l’organisation, ainsi que des objectifs visés. Elle nécessite également une approche holistique qui prend en compte les différents aspects du travail des développeurs, comme le temps, la qualité, l’impact, l’expérience et la culture. Enfin, elle doit être utilisée avec discernement et dans un but d’amélioration continue plutôt que de contrôle ou de jugement.

donc la mesure est possible ... MAIS elle dépend de tellement de choses et doit être utilisée avec discernement [...]

de là à dire que la mesure est donc soit ni possible soit ni exploitable, il n'y a donc qu'un pas?

[halaster08]

donc la mesure est possible ... MAIS elle dépend de tellement de choses et doit être utilisée avec discernement [...]

de là à dire que la mesure est donc soit ni possible soit ni exploitable, il n'y a donc qu'un pas?

Mais non, c'est pas impossible mais juste très difficile, et donc pour le faire au mieux tu ne peux pas le faire toi même, il faut faire appel a des experts, comme ceux de chez McKinsey par exemple, ça tombe bien c'est eux qui ont pondu l'article ! Quel coïncidence !

[totozor]

Déjà, j'ai jamais compris l'intérêt d'être audité par des juniors, qui ne sont même pas du métier et comprennent péniblement la nature de notre travail. Logiquement, on devrait apporter des conseils quand on a une grande expérience du sujet...

Mon expérience me dit que le problème ne vient ni de l'âge ni de la connaissance du métier mais de la capacité de l'auditeur à apprendre et de sa volonté d'apprendre.

J'ai un exemple vécu : Je me retrouve chef d'équipe il y a bien longtemps et au bout de quelques semaines je découvre un problème simple : on recoit chaque semaine 50 plans, on en sort que 30. Après moultes efforts non concluant je demande du support à mes managers parce que la situation semble insolvable. Comme ils ne veulent pas renforcer l'équipe ils nous envoient le cador de la qualité de l'entreprise, un gars de 50 piges, 15 ans d'expérience pro en gestion de projet et en gestion qualité. On parle pendant 4h (le temps qu'il me fallait pour sortir 3 plans) pour lui présenter la situation : on rentre 50 plans, on a une capacité théorique d'en sortir 55 mais on dépasse rarement les 30, on ne sait pas exactement combien de plans sont dans notre backog mais on dépasse largement les 200. Sa solution : vous ne produisez rien pendant une semaine et toute l'équipe se concentre sur l'enregistrement de ce qui a été fait, sur l'historisation des versions des outils utilisés. Quand je lui répond que ça ne répond en rien à mes problèmes de productivité il me répond que si à la fin de la semaine suivante on a pas fait le boulot je vais me retrouver en commission devant la direction pour expliquer pourquoi je ne suit pas les consignes du responsable qualité de la boite. Conclusion : vendredi de la semaine suivante, alors qu'on a rien sorti de la semaine, le client me convoque avec mes managers : on a 360 plans de retard en backlog, il exige de nous un plan de rattrapage pour revenuir à la normale dans 3 mois, en attendant le projet est remis en cause chaque semaine : si on atteint pas les objectifs hebdo personne ne revient lundi matin.
Pendant ce plan de rattrapage un jeune sorti d'école d'ingé qualité arrive dans l'équipe, il ne sait pas lire un plan mais est capable de suivre la procédure de controle. Depuis le premier jour il pose des questions sur l'organisation et propose des solutions. Les premières ne sont pas applicables mais il comprend petit à petit le contexte et on lance quelques améliorations d'organisation. En quelques semaines on gagne clairement en productivité. On finira le plan de rattrage avec une semaine d'avance.

Bref un gamin qui s'y interresse peut etre bien plus efficace qu'un "vieux briscard" donneur de lecon.

[GLDavid]

@totozor, ce que je trouve hallucinant dans ton histoire, c'est que le vieux de 50 ans te met le couteau sous la gorge: "Suis mon plan ou alors on te vire".
En même temps, tu dis que c'est quelqu'un qui vient de la qualité.
J'ai eu à faire chez un client à ces gens-là (AQ, assurance qualité). C'est des enc... de mouches. Pour faire simple, toute boîte pharma qu'elle soit qui doit produire le fruit de la science, est maintenant dictée par la qualité. Ce qui fait que le scientifique se résume à être un gratte-papier pour justifier le moindre acte ou décision. Quand à moi, mon projet a connu des retards à cause des procédures qualités de la boîte: tout devait être revu, approuvé par X partis avant de passer à l'étape suivante. Evidemment, aucun moyen de votre serviteur pour que les partis fassent leur travail en temps, heure et lieu.
Bref, je résume la qualité à "Je vais te dire comment tu dois travailler même si j'y connais rien".

@++

[totozor]

@GLDavid : Aïe, je prend la balle... Oui je suis ingénieur qualité dans mon entreprise
Mais je me suis allé à ce poste pour une raison simple : c'est la première entreprise que j'ai cotoyé de près (sur 6) où la qualité à une démarche de "De toute façon on doit faire la paperasse, vous la rédiger, nous la lire donc on vous prépare le travail (format, structure, etc) et on avance petit à petit ensemble dessus" plutôt que l'habituel "Où est le document que vous étiez censé officialisé hier, que nous refuserons de toute façon au trois premières lectures".
La qualité a le rôle (théorique) de "garde fou", raison pour laquelle on est les chieur de la bande mais chez nous la qualité doit autant justifier les retard que le chef de projet.

Je ne dis pas que nous sommes tous blancs, loin de là, mais on essaye sincèrement de faciliter les choses.
Je vois deux autres grosses différences avec mes expériences précédentes:
_ En général, la qualité maitrise un ou deux outils (8D/DMAIC/5 pourquoi/blablabla) et s'en sert toujours pour tout traiter. Nous connaissons beaucoup d'outil mais ne les maitrisons pas, on choisit l'outil en fonction du résultat attendu et on a des experts des outils pour nous accompagner. On évite donc des tournevis pour enfoncer des clous.
_ Nous avons énormément de procédures que nous ne suivons pas toujours : nous ne sommes pas le "flic" qui tappe sur les doigts de celui qui sort des clous mais ceux qui justifient l'écart.

[GLDavid]

Merci totozor de ta réponse et de ta franchise.
Mes mots ont paru bien acerbe envers les AQ, mais tu auras compris qu'elle vient d'une (très) mauvaise expériences avec tes pairs qui se croient tout permis dans une boîte.
Ai-je dit pour autant que je vous mettais tous dans le même panier ? Non, je ne l'ai pas fait.
J'ai côtoyé chez d'autres clients des AQ qui vérifiaient seulement que la procédure était bien suivie et le rôle s'arrêtait là. D'autres s'assurent que la société reste dans les clous de telle ou telle norme/réglementation.
Ma mauvaise expérience vient du fait que l'AQ avait la main mise sur cette boîte pharma, pour ne pas dire le pouvoir (l'ancien directeur AQ a été promu chef de la boîte, renforçant ainsi cette main mise). Certains ont trouvé leurs comptes : des scientifiques quelque peu feignants ont tôt fait leurs documents AQ et plus rien à côté sous prétexte du "je suis saturé de travail!!! Sortez-moi de là !!!"

Et puis, ton serviteur, de par ses activités de validations participent aussi à l'AQ de ses clients

@++

[banitz]

Performance
Pour quel résultat ?
Au profit de qui ?
Avec quel résultat pour l'intérêt général ?
Avec quelles contraintes sur l'humain ?

Voilà les vraies question que l'on devrait se poser.
Mais la motivation de la plupart des entreprises n'est plus là.
Elle est de générer des profits pour les plus riches dont il faudrait évaluer la performance.

[destroyedlolo]

Mouai, ce genre de flicage va surement améliorer le seul truc qu'ils ne mesurent pas : la motivation.

Car, hormis les "pisseurs de codes", tous les métiers créatifs (et le dev en fait parti), c'est sans doute l'aspect le plus important.

PS: puis bon, McKinsey quoi

[olsimare]

Pour mesurer la productivité, d'un dev, d'un concepteur, d'un CP, d'un architecte ou autre, il faudrait déjà que :
1/ Les objectifs soient SMART
2/ Les gens qu'ils les mesurent (du style les managers) sachent ce que produisent les gens.

Sinon, on peut effectivement demander l'avis de consultant qui n'ont jamais développé, conçu, testé quoique ce soit.

[olsimare]

McInsey... je reviendrais pas sur notre bon président et sa lubie avec ces gens-là.
Moi, la boîte pour laquelle je travaille avait demandé à McInsey comment réorganiser la boîte pour qu'elle fonctionne en 'meilleure synergie' (mais si, ce terme de manager...)
De l'argent a été dépensé, des cadres auditionnés par McInsey (pas votre serviteur) et finalement, on a abouti à une idée lumineuse: "Tous ensemble pour demain" !
Wouah, la com' ! Et ca a été le maître mot pendant 1 an et puis... plus rien, les objectifs avaient changé, la boîte avait d'autres orientations et toutes ces belles paroles envolées.

De l'argent jeté par les fenêtres avez-vous dit ? Allons, qu'est-ce qui a bien pû vous faire penser ça

Entièrement d'accord.

En 25 ans, j'en ai vu des projets avec des supers consultants top top facturés 2000 boules par jours pour pondre de la merde et des projets qui se plantent grave au final.

Les boites qui font ça ne savent tout simplement pas où elles doivent aller et de fait sont incapables de donner du sens au travail réalisé.

Ca c'est viable quand la boîte à de la thune, dés que ça ce complique...

[Pyramidev]

Avant-hier, Gergely Orosz et Kent Beck ont publié une réponse à l'article de McKinsey : Measuring developer productivity? A response to McKinsey.

L'idée principale est que, petit à petit, les développeurs privilégieront les comportements qui donneront de bons scores au lieu de faire ce qu'ils jugeront comme le plus productif. On peut résumer cette réponse par la loi de Goodhart : "When a measure becomes a target, it ceases to be a good measure".

Vers le début de l'article, Kent Beck parle de son expérience à Facebook :

“At Facebook we [Kent here] instituted the sorts of surveys McKinsey recommends. That was good for about a year. The surveys provided valuable feedback about the current state of developer sentiment.

Then folks decided that they wanted to make the survey results more legible so they could track trends over time. They computed an overall score from the survey. Very reasonable thing to do. That was good for another year. A 4.5 became a 4. What happened?

Then those scores started cropping up in performance reviews, just as a "and they are doing such a good job that their score is 4.5". That was good for another year.

Then those scores started getting rolled up. A manager’s score was the average of their reports’ scores. A director's score would be the average of their reporting managers’ scores.

Now things started getting unhinged. Directors put pressure on managers for better scores. Managers started negotiating with individual contributors for better survey scores. “Give me a 5 & I’ll make sure you get an ‘exceeds expectations’.” Directors started cutting managers & teams with poor scores, whether those cuts made organizational sense or not.”

Dans la suite de l'article, les auteurs présentent un modèle en 4 étapes : Effort -> Output -> Income -> Impact. Pour les développeurs, la partie "effort" inclut l'analyse du besoin, le code et le déploiement, tandis que la partie "impact" correspond à la valeur ajoutée pour l'utilisateur et aux gains financiers de l'entreprise. Pour plus de détails, je vous laisse lire l'article. Mais je copie ici un passage proche de la conclusion :

Why is McKinsey adding ways to measure effort? One reason is that it’s the easiest thing to measure! But the McKinsey approach ignores an important truth: the act of measurement changes how developers work, as they try to “game” the system.

The earlier in the cycle you measure, the easier it is to measure. And also the more likely that you introduce unintended consequences. Let’s take the extreme of measuring only profits. The good news is that everyone is aligned, across the company! The bad news: attributing who contributed how much to the profit is nearly impossible! You can ‘fix’ the attribution question by measuring outputs, or effort. But the cost is that you change people’s behavior, as it incentivises them to game the system to ‘score’ better on those metrics