IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

Est-il possible de mesurer la productivité des développeurs ? Oui, selon McKinsey

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 294
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 294
    Points : 194 624
    Points
    194 624
    Par défaut Est-il possible de mesurer la productivité des développeurs ? Oui, selon McKinsey
    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.

    Nom : metriques.png
Affichages : 20445
Taille : 38,9 Ko

    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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éprouvé Avatar de AaâÂäÄàAaâÂäÄàAaâÂäÄ
    Homme Profil pro
    db@
    Inscrit en
    Septembre 2021
    Messages
    424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : db@

    Informations forums :
    Inscription : Septembre 2021
    Messages : 424
    Points : 1 221
    Points
    1 221
    Par défaut
    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.

  3. #3
    Membre éclairé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Décembre 2008
    Messages
    103
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Décembre 2008
    Messages : 103
    Points : 886
    Points
    886
    Par défaut
    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.

  4. #4
    Membre confirmé
    Homme Profil pro
    nope
    Inscrit en
    Décembre 2012
    Messages
    122
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : nope

    Informations forums :
    Inscription : Décembre 2012
    Messages : 122
    Points : 466
    Points
    466
    Par défaut
    Citation Envoyé par pboulanger Voir le message
    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

  5. #5
    Membre expert
    Homme Profil pro
    ingénieur qualité
    Inscrit en
    Mars 2015
    Messages
    1 071
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : ingénieur qualité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mars 2015
    Messages : 1 071
    Points : 3 279
    Points
    3 279
    Par défaut
    Citation Envoyé par Stéphane le calme Voir le message
    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.

  6. #6
    Membre expert
    Profil pro
    programmeur du dimanche
    Inscrit en
    Novembre 2003
    Messages
    760
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : programmeur du dimanche
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2003
    Messages : 760
    Points : 3 190
    Points
    3 190
    Par défaut il serait bon d'évaluer la plus-value des cabinets de conseil, expérimentalement
    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.

  7. #7
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 020
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 020
    Points : 38 158
    Points
    38 158
    Billets dans le blog
    8
    Par défaut
    Citation Envoyé par Fagus Voir le message
    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...

  8. #8
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    136
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 136
    Points : 397
    Points
    397
    Par défaut
    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.

  9. #9
    Expert confirmé
    Avatar de GLDavid
    Homme Profil pro
    Service Delivery Manager
    Inscrit en
    Janvier 2003
    Messages
    2 849
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Service Delivery Manager
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Janvier 2003
    Messages : 2 849
    Points : 4 730
    Points
    4 730
    Par défaut
    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
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  10. #10
    Expert confirmé

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 848
    Points
    4 848
    Par défaut
    Citation Envoyé par Stéphane le calme Voir le message
    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?

  11. #11
    Expert confirmé
    Homme Profil pro
    Responsable des études
    Inscrit en
    Juillet 2014
    Messages
    2 643
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aude (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable des études
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2014
    Messages : 2 643
    Points : 5 754
    Points
    5 754
    Par défaut
    Citation Envoyé par stardeath Voir le message
    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 !
    J'aimerais bien aller vivre en Théorie, car en Théorie tout se passe bien.

  12. #12
    Membre expert
    Homme Profil pro
    ingénieur qualité
    Inscrit en
    Mars 2015
    Messages
    1 071
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : ingénieur qualité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mars 2015
    Messages : 1 071
    Points : 3 279
    Points
    3 279
    Par défaut
    Citation Envoyé par Fagus Voir le message
    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.

  13. #13
    Expert confirmé
    Avatar de GLDavid
    Homme Profil pro
    Service Delivery Manager
    Inscrit en
    Janvier 2003
    Messages
    2 849
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Service Delivery Manager
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Janvier 2003
    Messages : 2 849
    Points : 4 730
    Points
    4 730
    Par défaut
    @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".

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  14. #14
    Membre expert
    Homme Profil pro
    ingénieur qualité
    Inscrit en
    Mars 2015
    Messages
    1 071
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : ingénieur qualité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mars 2015
    Messages : 1 071
    Points : 3 279
    Points
    3 279
    Par défaut
    @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.

  15. #15
    Expert confirmé
    Avatar de GLDavid
    Homme Profil pro
    Service Delivery Manager
    Inscrit en
    Janvier 2003
    Messages
    2 849
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Service Delivery Manager
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Janvier 2003
    Messages : 2 849
    Points : 4 730
    Points
    4 730
    Par défaut
    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

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  16. #16
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : France, Bas Rhin (Alsace)

    Informations forums :
    Inscription : Janvier 2008
    Messages : 16
    Points : 29
    Points
    29
    Par défaut Performance ?
    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.

  17. #17
    Membre actif
    Homme Profil pro
    Architecte technique
    Inscrit en
    Juin 2019
    Messages
    103
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Juin 2019
    Messages : 103
    Points : 230
    Points
    230
    Par défaut
    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

  18. #18
    Membre chevronné
    Avatar de olsimare
    Inscrit en
    Décembre 2006
    Messages
    1 174
    Détails du profil
    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 174
    Points : 1 766
    Points
    1 766
    Par défaut
    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.
    Bon à savoir : la touche F1 ne sert pas à commander des places pour le grand prix de Belgique.

  19. #19
    Membre chevronné
    Avatar de olsimare
    Inscrit en
    Décembre 2006
    Messages
    1 174
    Détails du profil
    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 174
    Points : 1 766
    Points
    1 766
    Par défaut
    Citation Envoyé par GLDavid Voir le message
    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...
    Bon à savoir : la touche F1 ne sert pas à commander des places pour le grand prix de Belgique.

  20. #20
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 452
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 452
    Points : 6 020
    Points
    6 020
    Par défaut
    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 :

    Citation Envoyé par Kent Beck
    “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

Discussions similaires

  1. [2008R2] Est-il possible de mesurer l'impact des triggers ?
    Par Christophe Charron dans le forum Administration
    Réponses: 18
    Dernier message: 05/08/2016, 01h26
  2. Réponses: 2
    Dernier message: 13/08/2008, 11h36
  3. [RichEdit] Est-il possible d'afficher le numéro des lignes ?
    Par Invité dans le forum Composants VCL
    Réponses: 17
    Dernier message: 17/04/2008, 18h56
  4. Réponses: 6
    Dernier message: 02/07/2006, 11h02
  5. Réponses: 5
    Dernier message: 28/04/2006, 10h20

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo